Parrot 0.8.2 "Feliz Loro" Released www.parrot.org/news/2008/Parrot-0.8.2
Set by moderator on 23 December 2008.
pmichaud yes, I'm reviewing/refactoring other stuff as well 00:00
it ends up affecting almost all aspects of variable handling, so that includes things like 'has' and the like.
jonathan *nod* 00:01
A good review now and then can't hurt.
pmichaud one thing I did yesterday that I hope will help is to turn traits into things that we can easily make roles/properties from.
i.e., so that is xxx can really turn into the appropriate invocation of the xxx role. 00:02
jonathan Invocation of the xxx role?
pmichaud sorry, mixin, whatever.
jonathan It should be a multiple dispatch.
to trait_auxiliary:is
pmichaud so that it can become a call to trait_auxiliary:is(xxx, $obj, $arg)
yes, that.
jonathan The more we can make stuff happen that way and not special-case it in the compiler, the better.
pmichaud I did go ahead and special-case readonly, rw, and copy for now. 00:03
but they're special-cased in the signature binder, not in the compiler.
jonathan That's fine, I don't expect we can do 100% of them without specail-casing.
is also and is instead will likely for now want to stay special-cased.
pmichaud yes, they will as well. 00:04
jonathan Um, we don't do is instead yet.
pmichaud the point being that the generic trait nodes are there.
jonathan OK, that sounds good.
And inheritance is still handled through a dispatch to trait_auxiliary:is?
pmichaud so I have a general approach in place I'm comfortable with, and special-casing takes place in the sections where it makes sense :-)
I haven't gotten to classes/inheritance yet, but I'm sure they will be.
jonathan They are at the moment (in trunk at least)
pmichaud then they undoubtedly will be in the refactor :-) 00:05
jonathan OK, good. It'd be nice to keep things that are done right-ish right. :-)
pmichaud one of my goals is to get things that look like subroutine calls out of the compiler and into subroutines :-) 00:06
jonathan Any thoughts on breaking some of the various subs actions.pm has within it out into some modules?
So we get an even leaner actions.pm?
pmichaud most of the 1500 line savings has been from getting rid of those subs :-) 00:07
jonathan Then we have less to re-compile during development.
Ah. Where are they now?
pmichaud at the moment they don't exist. In many cases we no longer need them.
jonathan OK.
pmichaud (because the work they do is in one place)
(and is short enough to be reasonably inline)
jonathan guesses actions.pm compiles rather faster now.
pmichaud I haven't timed it. I have noticed that I'm not bugged by compile time like I once was. 00:08
I'm not sure where that speedup comes from.
chromatic_away I did speed up PGE by about a third with some STRING optimizations last week.
pmichaud but as an example, much of the work that was being done for setting up parameter traits in the various subs is gone and now part of the binding. 00:09
even better, the traits get precompiled as part of the signature.
00:09 AndyA joined
pmichaud so it's now just "attach this already-compiled trait to my caller's lexical variable" 00:09
jonathan *nod* 00:10
Doing stuff once at compile time on that stuff is certainly a win.
pmichaud it may become an even bigger win
in some cases we may actually be able to do a setprophash to get them all at once.
jonathan Did that op already get implemented? 00:11
pmichaud no, and it's not enough of a win yet to warrant it
(there are still some places where it won't be enough)
jonathan OK.
pmichaud if I need it, I think I can implement it :-) 00:12
I'm _also_ toying with the idea that instead of having a 'readonly' property to indicate "don't write to this variable" that we have a "rw" property that says "this is a writable container" 00:13
that will probably work great for scalar vars; I haven't quite figured out how to handle it for aggregate elements.
so that will likely come after merging the refactor back to trunk. 00:14
anyway, I'm being called to dinner.
(chromatic): Yes, your PGE speedup is likely the cause of the speed improvement, then. Thanks, that's very helpful.
00:14 kid51 joined
jonathan should sleep 00:15
00:19 jq joined 00:20 ask_ joined
nopaste "chromatic" at 69.64.234.10 pasted "pmichaud: Patch to add :ignore_rest parameter (first cut, unclean, but worth profiling)" (10425 lines) at nopaste.snit.ch/15123 00:30
GeJ I'm working on t/oo/mro-c3.t, and at some point new class creation switched from "A = new 'Class'" to "A = newclass 'A'". 00:37
00:40 jq joined
GeJ I understand that the later registers the 'A' class at a global level. 00:41
chromatic_away Right.
jhorwitz chromatic: does :discard make more sense than :ignore_rest? 00:42
GeJ Since I now run everything inside a :main sub, calling "newclass 'A'" twice (even in two separate subs) breaks the run. 00:43
So my question is : should I replace the "newclass 'X'" with anonymous classes (and be consistent within the file) or change the class names? 00:44
like MI{A,B,C} for multiple inheritance and DI{A,B,C,D} for diamond inheritance 00:45
third possible option: "You're overthinking it, just make it work." 00:46
nopaste "GeJ" at 202.22.229.231 pasted "[perl-to-pir conv] First attempt at converting t/oo/mro-c3.t" (305 lines) at nopaste.snit.ch/15124 00:49
00:53 cognominal_ joined
chromatic_away jhorwitz, that's not bad. 00:59
dalek r34595 | allison++ | branches/pdd22io_part3/src/pmc: 01:31
: [pdd22io] Store the StringHandle mode converted to integer flags too.
review: www.parrotvm.org/svn/parrot/revision?rev=34595 01:32
r34596 | pmichaud++ | branches/rvar/languages/perl6/src/classes: 02:05
: [rakudo]: Adjust Scalar method on Object.
review: www.parrotvm.org/svn/parrot/revision?rev=34596
GeJ in PIR, labels are local to the current sub, right? 02:15
pmichaud yes.
GeJ thank you. 02:16
Coke kicks off an --optimized run of partcl's spec tests. 02:19
GeJ hum, converting perl to pir is actually fun. 02:37
02:43 kid51 joined
dalek r34597 | jkeenan++ | trunk/lib/Parrot: 02:55
: Deleting one inline comment; rejecting rt.perl.org/rt3/Ticket/Display.html?id=43751.
review: www.parrotvm.org/svn/parrot/revision?rev=34597
r34598 | allison++ | branches/pdd22io_part3/src/pmc: 03:01
: [pdd22io] Keep the string data of a StringHandle around even after it's closed,
: so can be read later. Make 'read' smarter about reading the specified number of
: bytes, so it mocks the behavior of a filehandle better.
review: www.parrotvm.org/svn/parrot/revision?rev=34598
r34599 | allison++ | branches/pdd22io_part3/t/pmc: 03:06
: [pdd22io] Start to remove real temp file creations, since StringHandle doesn't
: interact with real files. Add code to write dummy text to the StringHandle
: objects, since it won't be reading from real files.
review: www.parrotvm.org/svn/parrot/revision?rev=34599
r34600 | tene++ | branches: 03:07
: Delete old unused branch
review: www.parrotvm.org/svn/parrot/revision?rev=34600
r34601 | tene++ | branches: 03:09
: Delete experimental branch.
review: www.parrotvm.org/svn/parrot/revision?rev=34601
r34602 | allison++ | branches/pdd22io_part3/t/pmc:
: [pdd22io] Reuse the stringhandle we wrote to, rather than creating a new empty one.
review: www.parrotvm.org/svn/parrot/revision?rev=34602
Tene pmichaud: check out www.parrotvm.org/svn/parrot/revision?rev=29089 03:10
pmichaud Tene: niiiiice 03:16
Tene pmichaud: That never made it into trunk... should it have?
dalek r34603 | tene++ | branches:
: Remove unneeded branch.
review: www.parrotvm.org/svn/parrot/revision?rev=34603
pmichaud it would be fine with me if it does. 03:17
we already had approval for it during parrotsketch, iirc.
(or maybe it was PDS)
anyway, it looks much nicer as a method than an opcode.
Tene Any idea why we needed it? 03:18
pmichaud it (can) make some operations easier in P6object, iirc. 03:20
Tene Ah.
yeah, rt #56616 03:25
testing, then committing
needs a docs update too I suspect, though 03:26
pmichaud++ 03:29
dalek r34604 | tene++ | trunk (2 files):
: [core]: Add 'make_namespace' method to NameSpace PMC (RT #56616)
review: www.parrotvm.org/svn/parrot/revision?rev=34604
r34605 | tene++ | branches: 03:30
: Create a branch for working pn HLL issues with PCT.
review: www.parrotvm.org/svn/parrot/revision?rev=34605
r34606 | pmichaud++ | branches/rvar/languages/perl6/src/pmc: 03:31
: [rakudo]: ObjectRef automatically intializes to Object proto.
review: www.parrotvm.org/svn/parrot/revision?rev=34606
Tene pmichaud: .HLL 'Perl6' or .HLL 'perl6' ? 03:32
I'm pretty sure the latter... 03:33
pmichaud I think the pdds say 'perl6'
and I wonder if it should perhaps be 'rakudo' :-P
we'll go with 'perl6' for now
dalek r34607 | allison++ | branches/pdd22io_part3/src/pmc:
: [pdd22io] Make StringHandle smarter about 'readline' so it really only reads a
: line at a time.
review: www.parrotvm.org/svn/parrot/revision?rev=34607
Tene So is the HLL supposed to import the P6Object and PCT stuff into its own namespace, is the HLL supposed to get it from the Parrot namespace, or are the libraries supposed to export to the loading HLL? 03:35
I know I've asked this a dozen times. I can never remember which you want.
pmichaud My initial approach is going to be HLL imports into its own namespace
eventually I expect it to import into its own private namespace... but that comes later 03:36
dalek r34608 | allison++ | branches/pdd22io_part3/t/pmc: 03:37
: [pdd22io] Write to and read from the same StringHandle in test.
review: www.parrotvm.org/svn/parrot/revision?rev=34608
Coke (whoops. accidental repaste on my last send.) 03:38
Huh. partcl is /slower/ with recent updates to parrot and partcl. whee! =-)
03:40 silug joined
Coke .HLL 'Perl6' is equivalent to .HLL 'perl6' 03:43
dalek r34609 | allison++ | branches/pdd22io_part3/src/pmc: 03:44
: [pdd22io] StringHandle check for end-of-file needs to take offset into account.
review: www.parrotvm.org/svn/parrot/revision?rev=34609
GeJ PIR tests are way faster...
Or did I screw up something again?
Tene they're way faster 03:45
nopaste "GeJ" at 202.22.229.231 pasted "[perl-to-PIR conv] conversion of t/oo/composition.t" (619 lines) at nopaste.snit.ch/15127 03:46
tewk PIR tests make it very hard to test one test in isolation, 03:47
dalek r34610 | allison++ | branches/pdd22io_part3/t/pmc: 03:49
: [pdd22io] Caught an untested failure case in FileHandle's tests when porting to
: StringHandle, succeded when no lines were read.
review: www.parrotvm.org/svn/parrot/revision?rev=34610
chromatic_away GeJ, I just skimmed it but it looks good to me. 03:51
GeJ Did you had a look at the first one as well? nopaste.snit.ch/15124 03:52
03:52 rurban_ joined
chromatic_away Also seems sane. 03:53
GeJ not sure I'll have time to do t/oo/new.t right now. Got some shopping to do. Probably tonight, tomorrow at the latest.
I actually enjoyed the try: catch: finally: trick... 03:56
oh shoot, I left my folding markers on. 03:58
04:01 elmex_ joined
Tene pmichaud: the 'parent' list passed to 'register'... should it be presumed that if it's strings, they're in the same HLL as the class being created? 04:08
That's what I'm assuming, and so I'm going to add an optional :hll named param to a few functions on P6object. 04:13
Maybe. Still looking at options.
Hmm. No, not sure that's right... 04:17
The problem is that add_parent uses get_parrotclass to look up the names, and get_parrotclass does get_hll_namespave on strings. 04:29
Which is unlikely to be useful when the caller is in a different HLL
Oh, ew. 04:35
'parent'=>'Boolean Any'
'Boolean' there refers to the core pmc 'Boolean'
I guess we can first try in the hll namespace and then in the parrot namespace if that fails... 04:36
04:39 petdance joined
pmichaud at some point 'parent'=> should expect an array of classes instead of a string. 04:47
i.e., I don't necessarily want P6object to guess too much about the caller's intent. If it's not clear, the caller has a way to make it clear.
I also don't want :hll spreading itself too far throughout P6object 04:48
Tene I was able to get it working with just adding it to get_parrotclass
pmichaud looking up classes by string should be a convenience, but not one that is guaranteed to understand every possible nuance of how things might be named or organized. 04:49
because strings just aren't that smart. 04:50
Tene right
get_parrotclass is a convenience method. 04:51
I could also rewrite the 'parent' option in new_class if you'd prefer.
pmichaud to do...? 04:52
Tene Right now new_class passes 'parent' on unchanged to 'register'. I could modify 'new_class' to change the 'parent' option from a string to an array of classes. 04:53
pmichaud I would think that we should be doing that in register 04:54
Tene Okay.
pmichaud (if we do it at all)
Tene That's where it's currently handled. I'll leave it that way.
pmichaud unless it's _trivially_ easy to get 'parent'=>'Boolean Any' to do the right thing, I think I'd prefer to make the caller explicitly provide the array of classes. 04:55
and leave the existing code as-is.
Tene I now have to figure out why 'register' is returning undef.
It currently DTRT with about four or five lines.
if TRT is 'check HLL then parrot' 04:56
pmichaud patch?
purl We don't need no stinking patch!
pmichaud or diff?
purl diff is that a burned cat is not as attractive as scarlett johannsen that a burned cat is also more likely to get its kit off
Tene Sure. I'll need to trim... justasec
lathos purl, you are quite weird.
purl ...but purl is a she. or captain obvious...
nopaste "tene" at 166.70.38.237 pasted "hll for get_parrotclass" (45 lines) at nopaste.snit.ch/15128 04:58
04:59 chromatic_away joined
dalek r34611 | allison++ | branches/pdd22io_part3 (3 files): 04:59
: [pdd22io] Change the 'readline' op to call a public interface, which calls the
: 'readline' method.
review: www.parrotvm.org/svn/parrot/revision?rev=34611
Tene add_parent also calls get_parrotclass, which then just returns the class, so little suboptimal. 05:00
pmichaud I wonder if a better approach is to use the hll class as part of the string name
i.e., 'parent'=> 'parrot;Boolean perl6;Any' 05:01
dalek r34612 | allison++ | branches/pdd22io_part3/t/pmc:
: [pdd22io] Remove more of the old temp files, and write 10,000 lines to a
: StringHandle for testing.
review: www.parrotvm.org/svn/parrot/revision?rev=34612
Tene that would be a bit nicer, but that's not necessary to get a working behavior right now.
pmichaud in general that 'hll' option feels very wrong to me. 05:02
Tene Agreed.
pmichaud (not only for this, but also in other places where we've used it.)
Tene Many places are still not HLL-friendly. 05:03
Although the other influence is not asking HLL authors to keep repeating themselves. 05:04
pmichaud how do you mean?
Tene 'parent'=>'perl6;Foo perl6;Bar perl6;Baz' seems awkward to me. 05:05
pmichaud thinking.
purl www.terrybisson.com/meat.html
chromatic_away Meat. They're made of meat. 05:06
pmichaud currently when we call new_class or register, P6object adopts the caller's view of hll, yes?
Tene in 'new_class' we could add the 'hll;' if it's not there.
Right.
pmichaud 'parent' should do the same.
so then it would be 'parent'=>'Foo Bar Baz' 05:07
and if the hll wants something out of the parrot hll, it should explicitly say so
Tene and in the Bool class do we still want to try to support 'Boolean Any' or require 'parrot;Boolean Any'?
pmichaud but ultimately I still believe that strings are the wrong way to do this 05:08
I want:
$P0 = get_class 'Boolean'
$P1 = get_hll_global 'Any'
$P2 = new 'ResizablePMCArray'
push $P2, $P0
push $P2, $P1
'parent'=> P$2
er, $P2
yes, that's a pain for the HLL person. But it's part of what happens from wanting to mix Parrot classes into your HLL. 05:09
it's also the most technically correct.
lathos That only needs to be done once, when the class is set up, right? 05:10
Tene lathos: right
pmichaud correct.
lathos Phew. Looks good, then.
chromatic And that's in PIR, which is assembly code.
Tene pmichaud: should 'new_class' optionally deconstruct a string into that, to offer a more convenient option for the common case? 05:11
pmichaud Tene: you mean register?
because 'new_class' doesn't care.
because 'new_class' shouldn't care.
lathos chromatic: The NCI discussion has made me wonder: why don't we just use C function signatures to represent C function signatures? 05:12
chromatic I can't think of any good reason.
Tene You're right. I was remembering new_class as a more friendly wrapper around 'register'. That was wrong. I understand better now.
chromatic I mean, I can't think of any good reason not to do just that.
Tene chromatic: I thought that's what you were implying but avoiding saying explicitly the entire time. 05:13
is that the case?
pmichaud new_class is a friendly "create a class and then register it" wrapper :-)
lathos Other than "parsing is hard", but we have Convert::Binary::C.
chromatic We have tewk's SoC project as well.
lathos Did that succeed? If so it will have been the only 2008SoC project I've found that did. 05:14
chromatic Yes, it did. 05:15
pmichaud Tene: thinking.
purl www.terrybisson.com/meat.html
lathos Excellent.
Tene pmichaud: mostly, I'm wanting to keep this branch as small and short-lived as possible. I want to avoid rewriting all the class definitions in all of the languages in this branch if possible.
pmichaud Tene: the branch should only make it possible to convert languages to hll. The branch itself shouldn't convert them all. 05:16
that's up to the language implementors to decide if/when to do.
chromatic I can't see how merging C and PCC calling convention parsers and converters makes sense though.
lathos chromatic: Also, I think we now have all the bits in place we need to port File::Temp. (Apart from mkdir in P6 but we can fudge that in PIR for now.)
chromatic To Perl 6 or PIR?
Tene pmichaud: so you want all existing langauges to still work without specifying .HLL? 05:17
lathos Well, we could port it to PIR but that's painful. I was going to do it in P6.
chromatic Seems reasonable.
lathos Once I've done that there's a program that'll convert it to PIR for me. :)
pmichaud Tene: existing languages should continue to work in 'parrot' if that's where they're defined. It's not up to us to change them. 05:18
chromatic I seem to have written a few of those.
pmichaud but when they want to switch to .HLL 'language', then there should be a path to do that.
I'm just wanting to make sure that path exists, not force them onto it :-)
Tene pmichaud: if I drop the 'parent'=>'...' interface in this branch, that will break all P6Object-using languages. 05:19
even ones that are in 'parrot'
pmichaud I wasn't saying eliminate the existing 'parent'=>'...' meme -- I'm just saying "don't extend it"
Tene Ah.
Okay. :)
pmichaud still thinking. there's a solution/refactor for all of this percolating in my mind somewhere and I'm trying to bring ti to the surface 05:20
what I _think_ I want is a way to convert a string or array of strings into its namespaces, not its classes 05:21
chromatic Parrot::Embed needs that too.
pmichaud we can then get to the classes from the namespaces, if/when needed
Tene That's easy.
pmichaud namespaces are what we end up passing along to newclass (the opcode) anyway
Tene: yes, but I want that string to be able to specify the hll's also. 05:22
so "Foo Bar::Baz" means the ['Foo'] and ['Bar';'Baz'] namespaces in the caller's hll 05:26
lathos Is there any reason not to rewrite the PIR File::Spec in Perl 6?
pmichaud lathos: the Perl 6 version would likely require the Perl 6 runtime. 05:27
lathos So?
purl No, se!
pmichaud the PIR File::Spec doesn't require that. You asked for "any" reason. :-)
lathos Sorry, I meant a good reason. :) 05:28
Tene 'The existing implementation works.'?
lathos Sorry, I meant a good and accurate reason. :)
pmichaud heh.
dalek r34613 | allison++ | branches/pdd22io_part3/src/pmc: 05:29
: [pdd22io] Store full set of options for buffer_type.
pmichaud From a P6 perspective, having a P6 version of File::Spec will be excellent.
dalek review: www.parrotvm.org/svn/parrot/revision?rev=34613
lathos % grep not_yet_implemented runtime/parrot/library/File/Spec/*.pir | wc -l
21
chromatic There are more valuable things to do?
lathos You said a File::Temp port would be a handy thing, and this is a first step to that.
pmichaud From a Rakudo perspective, a P6 version of File::Spec will be a very good test to see what other features we need.
From a "will other people use it" perspective, requiring a working copy of P6 might be a minor bump.
chromatic I prefer not to require a working copy of Rakudo to run Parrot's core tests. 05:30
pmichaud but that's the only disadvantage I can think of.
lathos My view is that one of the aims of Parrot was to be able to share code between languages and thus it doesn't matter what language stuff is written in.
05:31 TiMBuS joined
lathos We could always have a bootstrappy thing that checks in a --output=pir version for common use. 05:31
pmichaud ...except that --output=pir version still needs the runtime.
chromatic Rakudo won't always be in the Parrot repository.
lathos That's why I said "bootstrappy"
chromatic I don't mind checking in a pure-PIR generated version, if it makes tests easier to write.
pmichaud I'm confused by what "pure-PIR" generated version means, but okay. 05:32
chromatic I prefer that it doesn't require PGE/PCT.
lathos pmichaud: Right now we have a magic program that turns Perl 6 code into PIR code. We can use that to produce code which does not rely on Rakudo to run. 05:33
pmichaud lathos: have you seen the PIR code that gets generated?
it dependson having the Rakudo classes
lathos Ah.
That is unfortunate, then.
Tene Is there ever a case where the 'new' op should be returning null? 05:34
pmichaud i.e., it's hard for us to say "make a List" if the List type is only defined in Rakudo.
Tene PMCNULL, that is?
chromatic Tene, if something goes agly, I expect an exception not PMCNULL.
Tene Me too.
pmichaud or if the generated PIR call makes a call to .say, it's Rakudo's runtime that supplies that method.
(in fact, if one looks at the output of --target=pir from Rakudo, the second sub is one that does `load_bytecode "perl6.pbc"` in order to make sure the runtime library is present :-) 05:39
dalek r34614 | allison++ | branches/pdd22io_part3/t/pmc: 05:40
: [pdd22io] Alter buffer size tests to match actual behavior.
review: www.parrotvm.org/svn/parrot/revision?rev=34614
pmichaud Tene: how about 'parent'=>'parrot;Boolean Any' ? 05:41
I'm looking for something p6-ish
but it can also be parrot-ish
Tene pmichaud: I like it. 05:42
That's what I would have suggested.
pmichaud either that or we start looking at other special character markers
e.g. '*parrot::Boolean Any'
Tene I like that rather less. 05:43
pmichaud well, the nice thing about that approach is that we continue to split on '::'
and then a leading * on the first element returned indicates "hey, this is a hll"
otherwise we have to look explicitly for a ';' somewhere.
Tene split on spaces for items, split on ; for hll, split on :: for HLL namespace 05:44
pmichaud oh, that might not be so bad.
let's go with that for now. 05:45
so, names passed to P6object are relative to the caller's hll, and use "parrot;" to grab things from a different hll namespace.
I think the "split and convert to namespace" can be abstracted into its own private function, and it's okay with me if *that* function has a :hll option. 05:46
dalek r34615 | allison++ | branches/pdd22io_part3/t/pmc: 05:47
: [pdd22io] Fix UTF-8 test to use the same StringHandle object it wrote to.
review: www.parrotvm.org/svn/parrot/revision?rev=34615
pmichaud get_parrotclass wasn't really intended to be user-facing; if it ends up being that way then I may want to rethink it.
Tene There's going to be at least one commit with that patch I showed you earlier until i get that that, though. I need to get things working before I make them nice.
pmichaud you're committing to a branch, yes?
chromatic pmichaud, did you see my patch from earlier? 05:48
Tene Yes.
pmichaud Tene: commit as often as you like in the branch.
I don't mind if branches break things.
chromatic: I did see the patch, yes. it'll be at least a day or two before I can play with it.
I have it saved away for now.
(I'm in the midst of a huge parameter-and-variable refactor in rakudo and that's a branch that can easily get separated from trunk if not done quickly.) 05:49
chromatic Okay. It's just a quick proof of concept that needs cleanup, but it should be sufficient to let you experiment.
pmichaud that's exactly what I want. I can do the experiment and we can see how much it improves things. 05:50
I can even make it "switchable" so that we can try both approaches.
and easily time between them.
(or whatever other statistics we wish to run.)
I'll probably make an experiment branch for us to play with. 05:51
GeJ Anyone could point me to some documentation about Key PMCs? I'm not quite sure to understand what they do and how to use them.
pmichaud gotta run for a bit -- bbiaw
chromatic GeJ, I'm not sure anyone really understands them either. 05:52
The problem is that it could represent a string, an array, or a linked list.
lathos Flattening parameters in Perl 6 doesn't work yet? 05:53
Oh wait, I need to read the exegesis closer.
Still doesn't work though. :) 05:54
pmichaud flattening arrays works
Tene rakudo: sub foo { say +@_ }; foo(1, 2, 3);
pmichaud foo(|@x)
polyglotbot OUTPUT[3ā¤]
pmichaud slurpy parameters "kinda work".
that's what I'm fixing in the branch now.
lathos | ?! 05:55
Tene rakudo: sub foo { say +@_ }; my @a = 1..10; foo(|@a);
polyglotbot OUTPUT[10ā¤]
Tene rakudo: sub foo { say +@_ }; my @a = 1..10; foo(@a);
polyglotbot OUTPUT[1ā¤]
Tene sure looks like it works ot me.
pmichaud my @x = <a b>; foo(@x); # same as foo('a', 'b');
oops
Tene lathos: what doesn't work?
purl Look buddy, doesn't work is a strong statement. Does it sit on the couch all day? Is it making faces at you? Does it want more money? Is it sleeping with your girlfriend? Please be specific!
pmichaud my @x = <a b>; foo(|@x); # same as foo('a', 'b');
lathos The exegesis doesn't work. :)
[Update: We had better uses for a "splat" operator, so this flattening is now performed by the [,] reduce operator, which pretends the values passed on the right were originally separated by actual commas. See S03 for more about reduce operators.] 05:56
pmichaud Tene: those are "slurpy params" :-)
Tene rakudo: sub foo { say +@_ }; my @a = 1..10; foo(@a); foo(|@a);
polyglotbot OUTPUT[1ā¤10ā¤]
lathos So first it was *@a but that was re-jigged to be [,] @a.
Tene pmichaud: that doesn't demonstrate flattening?
lathos I couldn't find |@a
pmichaud Tene: yes, that's demonstrates flattening _and_ slurpy :-) 05:57
lathos: S06
Tene It's more typing to demonstrate flattening without slurpy. :)
lathos I'm looking at S06.
pmichaud foo(|@onetothree); # okay: @onetothree flattened to three args
lathos Hm. 05:58
No, I'm looking at E06. Fair enough.
Tene sub f { say $^b; say $^a }; my @a = <one two>; f(|@a);
pmichaud rakudo: sub foo($a, $b) { say "$a $b"; }; my @c = <1 5>; say foo(|@c);
polyglotbot OUTPUT[1 5ā¤1ā¤]
Tene perl6: sub f { say $^b; say $^a }; my @a = <one two>; f(|@a);
pmichaud rakudo: sub foo($a, $b) { say "$a $b"; }; my @c = <1 5>; foo(|@c);
polyglotbot OUTPUT[twoā¤oneā¤]
OUTPUT[1 5ā¤]
Tene perl6: sub f { say $^b; say $^a }; f(|<one two>); # I wonder... 05:59
polyglotbot OUTPUT[twoā¤oneā¤]
pmichaud are placeholders allowed in a "sub" definition? That looks wrong to me.
Tene huh. didn't expect that to work.
pmichaud: yes, only if there's no signature.
pmichaud Tene: sure -- S06 has
|(1..2, 3); # List, becomes \\(1,2,3)
anyway, I _gotta_ leave. bbl 06:00
dalek r34616 | allison++ | branches/pdd22io_part3/t/pmc: 06:15
: [pdd22io] Modify 'readall' tests to read from the same StringHandle they printed to.
review: www.parrotvm.org/svn/parrot/revision?rev=34616
r34617 | allison++ | branches/pdd22io_part3/src/pmc: 06:16
: [pdd22io] Modify StringHandle's 'readall' to create an empty UTF-8 string when
: the encoding is set to 'utf8'.
review: www.parrotvm.org/svn/parrot/revision?rev=34617
nopaste "GeJ" at 202.22.229.231 pasted "RFC: On proper use of Key PMCs when instantiating new objects." (69 lines) at nopaste.snit.ch/15129 06:26
GeJ also there may be a more PIR-ish version of "push $P3, $P4" 06:27
And again, I have almost no idea of what I'm doing. I'm currently pseudo-randomly pushing keys on my keyboard until I only see 'ok' lines in my terminal. :) 06:30
dalek r34618 | allison++ | branches/pdd22io_part3: 06:33
: [pdd22io] Updating the manifest with new files for StringHandle PMC.
review: www.parrotvm.org/svn/parrot/revision?rev=34618
lathos OK, I'm going mad. 06:34
perl6: use Test;
polyglotbot OUTPUT[Can't find ./Test in @INCā¤current instr.: 'die' pc 14740 (src/builtins/control.pir:204)ā¤called from Sub 'require' pc 15110 (src/builtins/eval.pir:111)ā¤called from Sub 'use' pc 15172 (src/builtins/eval.pir:134)ā¤called from Sub 'parrot;Perl6;Grammar;Actions;_block598' pc 109940 06:35
..(src/gen_actions.pir:1962)ā¤called from Sub 'parrot;Perl6;Gramma...
lathos Ah well.
is(1,1, "foo") is giving me "No applicable candidates found to dispatch to for 'is'"
Tene Okay, something weird is going on... getting PMCProxy objects when .HLL is set and Class objects when .HLL is not set... not sure from where yet... 06:36
Hmm... it might not be seeing the 1s as objects... 06:37
which would be weird, but possible.
lathos svn's up just to be sure.
Tene lathos: does it do the same thing if you assign the 1s to variables and call is() on the variables?
lathos Oh this is hideous. 06:39
Tene orly?
purl YA RLY.
lathos is(1,1, "Foo"); # Works, of course
is (1,1, "Foo"); # Fails
Tene yeah 06:40
no space is allowed between the sub name and the opening (
lathos Ah.
Funny way to say it, though. :)
Tene well, it's trying to call 'is' with no args.
there's no multi defined for is() that has 0 params. 06:41
lathos I'm still not convinced this is a feature. 06:42
Tene It makes the grammar more regular and predictable. This is a good thing.
GeJ synopsis 06:43
purl synopsis is git.jrock.us/?p=Bot-Synopsis.git;a=summary
lathos It's a good thing for the developer, but I actually want to use this language.
Tene A regular and predictable grammar is a feature for the user, not the developer.
It has to do with differentiating between postfix, infix, postcircumfix, etc. 06:44
iirc
lathos We have wildly different understandings of user-friendly. 06:45
Tene perlcabal.org/syn/S03.html#Minimal_...e_DWIMmery
lathos But something is still wrong because Rakudo accepts "foo (1,2)" as a valid statement consisting of a zero-arg sub call and then some data which it completely ignores. foo() (1,2) is a syntax error, and so should "foo (1,2)" be. 06:48
Tene That's right. 06:49
lathos Ah, OK, so when you're saying that it's a feature you actually agree with me that it's a bug. :)
Tene "Disallow space before the opening bracket of a postcircumfix operator" is a feature 06:50
lathos Here's another fun bug that just got turned up by an svn up:
% ./perl6 -e 'say eval ""'
Null PMC access in isa()
Tene "Don't throw an error message on a grammatical error" is a bug.
rakudo:
pmichaud is(1,1,"Foo") has three arguments 06:53
is (1,1,"foo") has one. 06:54
Tene Ah, right.
><
pmichaud (and there's no multi for "is" that takes only one param) 06:56
dalek r34619 | allison++ | branches/pdd22io_part3/t/pmc: 06:57
: [pdd22io] Add tests for 'read', 'print', and 'close' opcodes on StringHandle.
review: www.parrotvm.org/svn/parrot/revision?rev=34619
GeJ in PIR, is there a method I could use to list all the methods that a PMC ca do?
lathos Oh my this is so confusing.
perl6: sub foo { say +@_ ~ " arguments, which are: "; for @_ { say $_ }}; foo(1,2,3)
polyglotbot OUTPUT[3 arguments, which are: ā¤1ā¤2ā¤3ā¤]
lathos perl6: sub foo { say +@_ ~ " arguments, which are: "; for @_ { say $_ }}; foo (1,2,3)
polyglotbot OUTPUT[1 arguments, which are: ā¤1ā¤2ā¤3ā¤]
Tene GeJ: inspect
pmichaud lathos: I wouldn't completly trust @_ in subs yet, or any parameter starting with @ 06:58
that's a known long-standing bug in Rakudo.
in particular, that second version you just wrote should've said "1 arguments, which are\\n1 2 3\\n" 06:59
oh, wait. maybe not.
at any rate, the second one is wrong.
lathos OK, I see that foo (1,2,3) is a one-argument sub call, but should it be? Shouldn't it just be an error? The synopsis says it's "not allowed".
pmichaud ...synopsis says it's not allowed? 07:00
Tene Not quite, just that it parses differently
perlcabal.org/syn/S03.html#Minimal_...e_DWIMmery
lathos Whitespace is no longer allowed before the opening bracket of an array or hash subscript, or the opening parenthesis of an argument list.
I read that as meaning it's no longer allowed.
GeJ Tene: Method 'inspect' not found for invocant of class 'Key' :-/
Tene GeJ: look at the inspect opcode, iirc 07:01
pmichaud lathos: ah. I suspect that's a typo in the spec. (more)
technically, the paren in "foo (1,2,3)" is the opening paren of an argument, not the argument list :-)
i.e., foo (1,2,3), 4 has two arguments. 07:02
lathos Ah yes:
# XXX this one is wrong, it's parsed as code( (5) ) # STD.pm agrees on that.
lathos hits ^C on parrotbug and looks for larrybug instead. :) 07:04
dalek r34620 | allison++ | branches/pdd22io_part3/src/pmc: 07:09
: [pdd22io] Change compile-time strings to actual string constants.
review: www.parrotvm.org/svn/parrot/revision?rev=34620
r34621 | pmichaud++ | branches/rvar/languages/perl6/t/pmc: 07:11
: [rakudo]: Update t/pmc/objectref.t tests to not rely on 'assign' op.
review: www.parrotvm.org/svn/parrot/revision?rev=34621
r34622 | pmichaud++ | branches/rvar/languages/perl6/src/parser: 07:25
: [rakudo]: A different refactor for variables, introduces 'itype'.
review: www.parrotvm.org/svn/parrot/revision?rev=34622
Tene i'm doing something very wrong here, but I can't quite find it. 07:26
It looks like the parents aren't being set up quite right?
dalek r34623 | allison++ | branches/pdd22io_part3 (270 files): 07:29
: [pdd22io] Bringing the pdd22io_part3 branch up-to-date with trunk r34621.
review: www.parrotvm.org/svn/parrot/revision?rev=34623
Tene pmichaud: rakudo question, if you have a minute. 07:38
pmichaud yes.
Tene How exactly does P6protoobject get into the class hierarchy for rakudo's protoobjects? 07:39
pmichaud rakudo's protoobjects _are_ P6protoobjects
Tene Ah, that's what's going on! 07:40
rakudo extends P6protoobject through languages/perl6/src/classes/Protoobject.pir
pmichaud it doesn't actually "extend" it -- it just adds more methods.
Tene I'm getting a failure on calling .'!IMMUTABLE'() because that function is now defined in the perl6 HLL 07:41
so should Protoobject.pir be set .HLL 'parrot' or something?
pmichaud yes.
actually, each .pir probably needs to set its .HLL 07:42
(it's okay if only a few do it for now.)
Tene For now I'm just putting .HLL 'perl6' at the end of Protoobject.pir 07:48
pmichaud wfm 07:49
Tene Hmm... 'parent'=>'PGE::Match Any'... 07:50
Should that be parrot;PGE::Match ?
pmichaud yes.
Tene yay, segfaults! 07:52
Program received signal SIGSEGV, Segmentation fault. 07:55
0x0000003fcb07c605 in calloc () from /lib64/libc.so.6
from mem_sys_allocate_zeroed
very nice
oh, infinite loop 07:56
purl see infinite regress
Tene infinte regress?
from Parrot_oo_get_class_str 07:57
dalek r34624 | allison++ | trunk (11 files): 08:09
: [pdd22io] Merging the pdd22io_part3 branch into trunk for r34353 to r34623.
review: www.parrotvm.org/svn/parrot/revision?rev=34624
r34625 | allison++ | branches:
: Removing third I/O development branch from the repository
review: www.parrotvm.org/svn/parrot/revision?rev=34625
Tene allison: around? 08:13
08:14 iblechbot joined
allison Tene: yup 08:14
Tene Hmm. Maybe nevermind. I'm trying to debug an infinite loop with HLL stuff. I don't have a specific question anymore, though. 08:15
Something in rakudo tried to create a Hash and it hits an infinite loop of PMCProxies being created for PMCProxies, afaict 08:16
allison Tene: hmmm... it should only create it once, and then use the cache'd one. 08:17
Tene I think it might be in Parrot_oo_get_class_str
allison Tene: but then, if you structured it just right, it would be possible to have it attempt to do a look up of PMCProxy while it's in the middle of creating the cache'd proxy for PMCProxy 08:18
Tene Interested in helping me debug this?
allison Tene: I have a few spare cycles, where's the code? 08:19
Tene Lemme commit.
pct_hll branch 08:21
dalek r34626 | tene++ | branches/pct_hll (15 files):
: Start of support for HLL in PCT. Doesn't work.
review: www.parrotvm.org/svn/parrot/revision?rev=34626
r34627 | pmichaud++ | branches/rvar/languages/perl6/src/parser: 08:22
: [rakudo]: Refactor to hold attributes on the PAST::Var node directly
: instead of the block's symbol table. This uses a big-time cheat with
: PCT's currently implementation, but I'll think about ways to make
: something like it official.
review: www.parrotvm.org/svn/parrot/revision?rev=34627
Tene You can reproduce by trying to start rakudo.
nopaste "tene" at 166.70.38.237 pasted "Here's the start of the bt I get" (32 lines) at nopaste.snit.ch/15130 08:23
Tene I'm not certain that I'm not doing something stupid here. It's quite possible. 08:26
allison Tene: building now
Tene: what's changed in the branch? or, what were you working on?
Tene .HLL 'perl6'
purl hmmm... .HLL 'perl6' is equivalent to .HLL 'perl6'
Tene purl: forget .HLL 'perl6' 08:27
purl Tene: I forgot .hll 'perl6'
Tene The last line in parrot -t is returncc... unsure if that's going to be the op it segfaults on or the one before that. 08:31
pmichaud btw, my "rule of thumb" these days is that segfaults are often related to .tailcall in the wrong places. 08:32
_especially_ if they seem to occur in/around returncc
Tene pmichaud: any idea on getting parrot to tell me the file/line it's on in a trace? 08:33
pmichaud Tene: no, haven't seen that, sorry.
did you try -t5 ?
allison Tene: doesn't look like you changed much
Tene allison: I haven't yet.
pmichaud: much nicer. thanks. 08:34
allison Tene: and my money is on runtime/parrot/library/P6object.pir as the source of the problem, possibly in parent_loop 08:35
(just scanning diffs now, while I wait for the compile)
Tene It comes from trying to instantiate an 'IO' 08:37
pmichaud ...wow, that's actually a good ways into initialization then. 08:40
Tene looks like Object.pir:294
$P0 = p6meta.'get_parrotclass'(self)
$P1 = new $P0
pmichaud be aware that tracing and segfaults don't always play well together
Tene confirms 08:41
pmichaud sometimes the segfault halts the program before the trace buffers have flushed.
Tene Hmm. You might be right.
Still a good ways into initialization, though. 08:42
Definitely in that function.
Yeah, looks lke it's Object.pir:351, which is "init_attribs = new 'Hash'" and matches with what I thought was going on. 08:46
08:47 gaz joined
Tene and "new 'Hash'" reproducably dies earlier in the process. 08:48
pmichaud is that in Perl6Object's "new" method? 08:49
Tene Yes.
Called from globals.pir:60
pmichaud it wouldn't surprise me if that's not completely right.
Tene Well, "new 'Hash'" dies if I call it from globals.pir earlier
allison Tene: looks like it does call 'Parrot_oo_get_class_str' from within PMCProxy's 'init_pmc', but only when it encounters 'scalar' as a classname
Tene allison: the classname there is 'Hash' according to gdb 08:50
allison ah, wait, it's that reversed string_equal logic
Tene That's != 0, which is "does not encounter scalar"
allison it's for all classnames except 'scalar'
Tene yeah
allison this is when I wish I had git, to quickly see when those lines were added 08:51
Tene I can check. justasec. 08:52
lathos Hm, I used parrotbug but now I can't see if it got through. 08:53
Tene jonathan
purl i guess jonathan is mailto:jnthn@jnthn.net or trying to put together a grant application.
dalek r34628 | pmichaud++ | branches/rvar/languages/perl6/src/parser:
: [rakudo]: Bring ordinary variable declarations in line with the way
: parameters are being declared from r34627.
review: www.parrotvm.org/svn/parrot/revision?rev=34628
Tene r33520
"[core] PMCProxy wasn't yet building and keeping an MRO nor a parent list. Th
..."
allison it's the "skip ourself" part that doesn't seem to be working 08:56
and, there's not any code to ensure it skips itself
pmichaud ...maybe because it starts at i = 1 instead of i = 0 ? 08:57
(i.e., it thinks "ourself" is element 0?) 08:58
Tene Also, if I remove the 'name'=>'Hash' part of Hash.pir, it doesn't die like this. 08:59
pmichaud that's odd.
that really shouldn't have an impact.
out of curiosity, did you try with -G ?
Tene P6object uses the name parameter to decide the namespace it's stored in, if present. 09:00
Parrot-oo_get_class_str looks in the current HLL's namespace.
-G makes no difference.
pmichaud oh. 09:01
that's definitely a problem.
Tene Which part?
purl the IMPORTANT part!
Tene purl: forget which part
purl Tene: I forgot which part
pmichaud 'name'=>'Hash' means that p6object will create a protoobject at set_hll_global 'Hash' 09:02
Tene Is that not what P6Object should do?
pmichaud yes, it is what P6Object should do
Tene Okay.
pmichaud but then Parrot_oo_get_class_str will get confused if it expects to find something else there.
Tene Right. This is the sort of thing I expected to run into doing this before the class registry stuff was sorted out. The meaning of new_*_sc and friends. 09:03
pmichaud i.e., Parrot_oo_get_class_str is being asked to find "Hash" based on its name.
and if it's doing that by trying to look up the namespace in the current hll (as opposed to the hll where "Hash" is really stored), then kaboom. 09:04
Tene Well, it still shouldn't be segfaulting after an attempt at an infinite loop. :)
pmichaud of course, imo it's very wrong that init_pmc is trying to use class*names* to set up the MRO
Tene I've never looked at the MRO stuff at all. 09:05
pmichaud mro = method resolution order
allison pmichaud: yes, it should be using types
pmichaud apparently what init_pmc is doing is "get me the next mro type as pclass" 09:06
then "okay, give me the name corresponding to pclass"
then "okay, look up the proxy based on the name"
there ought to be a way to go from pclass to proxy without having to get a name to look it up.
allison though, it's worse than that, it pulls the class object from the MRO array, then asks it for its name, then looks it up by name. huh?
pmichaud class object != proxy, perhaps?
but yes, I find that weird also. 09:07
Tene I also don't know what PMCProxies are for, or why 'new "Hash"' needs to create one. 09:09
Many parts of Parrot I still don't understand well yet.
allison Tene: PMCProxies allow PIR classes to have C PMCs as their direct parents 09:11
Tene Ah.
09:13 kj joined
allison why 'new "Hash"' needs to create one is an important question, though :) 09:14
pmichaud I suspect that somewhere along the way the "Hash" got looked up wrong also.
Tene does each instance of a PIR class get one?
allison pmichaud: yes, very possibly
pmichaud Tene: normally no
allison Tene: no, only C classes get a proxy
pmichaud it's one per class, not one per instance 09:15
allison which is why this code is very wrong
pmichaud I bet I can come up with a shorter test... just a sec. 09:16
nope, apparently not. 09:20
Tene pmichaud: yeah, ->mro is [this class, parent1, parent2, ...] 09:22
so starting at 1 is skipping self
allison whoami usually only reports the basename, not the hierarchy 09:23
Tene allison: so it gets the basename and then re-looks it up in the current hll namespace? That sounds broken...
allison yes, it is broken
(experimenting with a few fixes now) 09:24
pmichaud why do we have to do a lookup at all?
oh dear 09:25
pmichaud looks at Parrot_oo_get_class_str 09:26
allison does the Perl 6 'Hash' inherit from the C PMC 'Hash'?
pmichaud yes, but the Perl 6 'Hash' is named 'Perl6Hash' 09:27
i.e., it has a Parrot name of 'Perl6Hash'
(unless Tene changed it in the branch)
Tene But stored in ['perl6';'Hash'] in the branch
pmichaud ....?
purl dot dot dot *yawn* dot
allison pmichaud: I did try cutting the lookup out entirely, and just storing the class object from the MRO directly, I got a lot of test failures about a missing 'parents' method
pmichaud what do you mean "stored in ['perl6';'Hash'] in the branch?
allison pmichaud: which tells me, that other code was expecting a Proxy object in the inheritance hierarchy and finding some other kind of object 09:28
nopaste "tene" at 166.70.38.237 pasted "'stored in [hll;:name]' for pmichaud++" (15 lines) at nopaste.snit.ch/15131 09:29
pmichaud allison: what bugs me about Parrot_oo_get_class_str is that it's going to end up creating a Proxy object in every hll namespace.
that is, "creating a _new_ Proxy object..."
allison pmichaud:?
pmichaud Parrot_oo_get_class_str looks for a proxy object 09:30
in the current hll namespace root
sorry, let me rephrase more precisely
allison pmichaud: it shouldn't. it should only create them in the HLL namespace of the C PMC
pmichaud PMC * const hll_ns = VTABLE_get_pmc_keyed_int(interp, interp->HLL_namespace,
CONTEXT(interp)->current_HLL);
PMC * const ns = Parrot_get_namespace_keyed_str(interp, hll_ns, name);
looks like it's in the hll of the interpreter.
allison yes, that's true 09:32
looks like an overzealous conversion to use HLL namespaces
pmichaud if I call Parrot_oo_get_class_str to look up "Hash" from a hll other than parrot 09:33
then the lookup for the class will look in the wrong namespace
and it will fail, so it will then create a new PMCProxy for "Hash" and give me that. 09:34
and every call to obtain "Hash" will end up with a different PMCProxy
allison yes, I agree with that assessment 09:35
this needs to be fixed along with other changes to use real hierarchical namespaces
09:37 alvar joined
pmichaud Tene: you _might_ be able to get away with replacing $P0 = new "Hash" with 09:38
$P0 = get_root_namespace ['parrot';'Hash']
$P0 = get_class $P0
$P0 = new $P0
thus avoiding the string lookup altogether.
nopaste "tene" at 166.70.38.237 pasted "This avoids the crash. Don't know how correct it is." (16 lines) at nopaste.snit.ch/15132
pmichaud Tene: that works if we assume that all string class lookups are in the "parrot" namespace. 09:39
Tene Isn't that what you wanted to presume? I really need to start keeping notes on what's planned so I can stop asking you to repeat yourself. 09:40
Yeah, not a good fix. 09:41
pmichaud you mean presume at the opcode level? no, that wasn't what I proposed.
Tene Right, that wouldn't work. I get it now.
pmichaud I would want a lookup by string to look in the class registry.
and not check namespaces at all.
allison pmichaud: that fix won't work, because it's always looking in the parrot namespace 09:43
pmichaud allison: I think that's what I said.
allison so, all class lookups in the entire system will only look in the parrot namespace
Tene which isn't the right behavior for that function. Yes, that's what he said.
allison yeah
really, that should be a search, rather than a single lookup in a single place 09:44
pmichaud allison, did you see my proposal for fixing class lookups yesterday?
pmichaud searches
allison pmichaud: no, in email? 09:45
pmichaud no, on irc. irclog.perlgeek.de/parrot/2008-12-27#i_788597 09:46
basically it divorces the class registry from namespaces, and says that looking up a class by string always grabs things from the registry (and only the registry) 09:49
but it avoids a "search for a class" step, which I think would likely be a source of long-term problems. 09:51
allison pmichaud: actually, it should go the other way around, and only lookup in the namespace 09:58
pmichaud allison: huh?
allison but you're absolutely right that having two locations to look up classes is what's snarling us up
09:59 barney joined
allison well, the registry is on the way out 09:59
pmichaud if I want to lookup in the namespace, there's a good syntax for doing that
$P0 = get_class ['Foo';'Bar']
or
$P0 = get_class ['Foo']
that should mean "look up in the namespace"
10:00 TiMBuS joined
allison yes, nothing should be looking up a class in the registry 10:00
pmichaud to the extent that the class registry exists, it should be there to make it easier to grab the types that aren't in a local namespace
i.e., so that I can still get a Parrot Integer without having to do a get_root_global first.
allison no, that's not it's purpose, it's just a unique id store
looking up classes that aren't in your local namespace should always go through the other namespace 10:01
pmichaud that will truly be a pain.
allison really, it's much simpler
pmichaud how is
$P0 = get_hll_namespace ['parrot';'Integer']
$P1 = new $P0
simpler than
$P1 = new 'Integer'
?
allison remember HLLs can subclass the namespace object, and have their own custom namespace 10:02
oh, no, no, no, you misunderstand me
$P1 = new 'Integer' # does a lookup in the namespace, not the registry
pmichaud that's not a big improvement over 10:03
allison everything does a lookup in the namespace, not the registry
all the backend code
pmichaud $P1 = new ['Integer']
allison well, those two should be isomorphic
pmichaud being able to use 'Integer' as a shortcut for ['Integer'] isn't very helpful
allison huh?
pmichaud especially since there's not really a good isomorph for ['Foo';'Bar']
allison I don't follow 10:04
pmichaud you're saying that $P1 = new 'Integer' should look up my HLL's Integer class
yes?
purl yes is that a trick question? :)
Tene purl: forget yes
purl Tene: I forgot yes
allison yes
pmichaud I'm saying that $P1 = new ['Integer'] does exactly this
allison yes
pmichaud and that there's no need to have $P1 = new 'Integer' do this function. 10:05
allison adding brackets to a single string doesn't do anything different
the brackets just group the strings
pmichaud I thought they created keys
i.e., new ['Integer'] and new 'Integer' would in fact be different opcodes.
allison yes, which in this case acts as a constant array of strings 10:06
or a list
so '
so ['Integer'] is a single element list
pmichaud is it really that way internally?
allison which is equivalent to 'Integer' without the brackets
pmichaud if I do $P0 = get_namespace ['Integer'], that's identical to $P0 = get_namespace 'Integer' ?
allison yes, that's the way it's implemented
pmichaud: yup
pmichaud checks. 10:07
dalek r34629 | kjs++ | trunk/compilers/pirc/new (3 files):
: [pirc] count :named parameters twice; 1 for the argument, 1 for the :named flag value (name)
: + add commments
review: www.parrotvm.org/svn/parrot/revision?rev=34629
pmichaud there is no get_namespace_p_sc opcode. 10:08
allison well, you were asking about 'new'
pmichaud I'm saying that 'new' ought to act like get_namespace in this respect. 10:09
just a sec, still checking.
allison it drills down to 'internal_ns_keyed_key' in src/global.c 10:11
pmichaud so, which opcode does $P0 = new ['Foo'] call? Does it call new_p_sc or does it call n_p_pc ?
sorry, new_p_pc 10:12
allison p_pc
pmichaud right, so it's not really the same as $P0 = new 'Foo'
allison becaue it's a pmc constant
dalek r34630 | kjs++ | trunk/compilers/pirc/new:
: [pirc] count :named arguments twice as well; once for the argument itself, once for the :named() flag value.
review: www.parrotvm.org/svn/parrot/revision?rev=34630 10:13
pmichaud right, that's my point.
allison yes, but they both call the same code
pmichaud but they don't have to.
(more)
allison which ultimately calls 'internal_ns_keyed_key' , which iterates over each string in the key
doing exactly the same thing as a string
dalek r34631 | kjs++ | trunk/compilers/pirc/new (2 files): 10:14
: [pirc] slightly more efficient code for parameter counting.
review: www.parrotvm.org/svn/parrot/revision?rev=34631
pmichaud they don't do the same thing, though.
allison and then they both call 'internal_ns_maybe_create' with the string
pmichaud looks. 10:15
allison whether you pass a string or a key, they ultimately call the same function
TiMBuS if i provide an 'invoke' vtable method with a parrot class, it says i need to pass it an argument when i try to call it. erm. what is it expecting?
pmichaud new_p_pc calls Parrot_oo_get_class
new_p_sc calls Parrot_oo_get_class_str
I'm saying that Parrot_oo_get_class should always grab a class based on the hll namespace 10:17
which is what it does now.
that's the new_p_pc ($P0 = new ['Integer']) form 10:18
allison okay, yes, that is what it should do, and so should new_p_sc 10:19
pmichaud so then how do I make a new Parrot Integer from another HLL?
allison by an excessively long route of looking up the namespace of the other language, and doing a lookup on that namespace object 10:20
pmichaud I'm saying new_p_sc can avoid that excessively long route
allison but, you have to pick one for the short form, and looking up a class in the same HLL is the more common of the two
pmichaud: that'd be terribly confusing
pmichaud because we don't need new_p_sc to do the equivalent of the common form
because there's already a convenient way to do the common form 10:21
allison because the string form is the more common of the two
pmichaud but it shouldn't be.
allison well, it's easier to type
pmichaud we're talking generated code.
and it's only one set of brackets.
allison yes, but PIR is both generated and hand written
and really, generated code should just use the fully-specified path all the time 10:22
it's easier
(and safer)
pmichaud I think hand-written code should do the same, for the same reasons.
allison now, if lookups were searches, rather than just hitting one namespace, we could always check if the first item in the key is an HLL name 10:23
but, that has some problems with portability
pmichaud -1
purl -1
pmichaud because then we have to worry about "what if there's a namespace that matches an HLL name", etc. 10:24
allison your code that works fine breaks when you suddenly install a language named, say "Hash"
pmichaud exactly.
allison right
pmichaud I don't mind doing the namespace lookups for other HLLs
allison and, there's the option of adding a special character before HLL names
like '*parrot';'foo';'bar'
pmichaud where "other HLLs" is "other HLLs other than parrot"
allison and '*parrot;foo;bar' 10:25
pmichaud going the excessively long route is fine there
allison yes, but any automated searching we do of the parrot namespace just pollutes the HLL namespace
pmichaud right, so I'm saying no searching at all.
allison that is, if you search for 'Hash' and always find the parrot 'Hash', then you've effectively filled that space in the HLL namespace, even though it's empty 10:26
pmichaud that's my point!
allison then I have no idea what we're debating :)
pmichaud if we break the connection between 'Hash' and ['Hash'], then we get both. 10:27
allison no, we don't
pmichaud because ['Hash'] is the HLL namespace version of Hash, and 'Hash' can be something else.
allison that just moves the problem to another location
pmichaud how so?
I'll phrase it a different way, and then I should get to bed (4:30am here) 10:28
allison because then you have people horribly confused trying to figure out why 'foo;bar' does something completely different than ['foo';'bar']
pmichaud I think that 'foo;bar' is equivalently bad, fwiw.
actually, even worse.
allison I originally implemented it so the bracketed namespace always had to be fully specified 10:29
pmichaud because I can't tell if 'foo;bar' means ['foo';'bar'] or ['foo;bar']
allison so ['parrot';'foo';'bar']
pmichaud that's also bad.
allison yeah, it drove people nuts
I mean, namespaces are already pretty messy
pmichaud I'm not aware of anywhere else where we allow 'xyz' to be a shortcut for ['xyz'] 10:30
I can't do get_hll_global $P0, 'xyz', 'name'
I don't think I can do (anymore) .namespace 'xyz'
allison well, anywhere it iterates over a key one at a time performing an action on the string will have the same result as performing an action on a string
I'm happy to remove the bare string version entirely 10:31
pmichaud so the argument that $P0 = new 'xyz' is somehow superior to $P0 = new ['xyz'] doesn't fit with the rest of parrot
allison but completely different behavior for two characters difference is just bad design
pmichaud heh 10:32
allison the bare string is just a convenience
pmichaud by that argument, "string" and 'string' should be the same :-)
allison that one bites me all the time 10:33
but, it's pretty fixed in the culture at this point
pmichaud okay. 10:34
I'll leave with this summary then
(1) removing the bare string version entirely is fine with me
that's where I was thinking we'd ultimately head anyway
10:34 tomyan joined
pmichaud (2) in the meantime, using the bare string version to mean "look up via class registry only" is an awfully convenient migration shortcut. 10:35
allison as long as it doesn't do anything special, the bare string version is pretty unoffensive
people will start depending on it though, and the class registry is definitely going away
I really don't want the registry exposed to PIR at all
I can see adding a 'new_from_root' or something like that 10:36
pmichaud to be honest, whenever I've used the bare string version I've always thought of it as being "special" and not the same as a class-by-namespace lookup.
allison that takes a fully-specified namespace path instead of hll namespace path
which is probably why this solution occurs to you. but it is doing a class-by-namespace lookup 10:37
pmichaud yeah, I wouldn't think of it as being a class-by-namespace lookup because to me "namespace in pir" has brackets. 10:38
allison well, a string name containing ';' characters splits out into an array 10:39
pmichaud that's icky.
allison yeah, probably so, but it was a necessary part of the migration
kj jonathan: ping 10:40
pmichaud this whole identifying a class by a string is just something we need to eliminate.
allison there's a fair bit of ickyness there, and I'm cringing right now because it looks like a lot more ickyness has crept in since we did the OO refactor
allison sighs
pmichaud: yes
pmichaud okay.
allison classes should be identified by class object 10:41
and only by class object
pmichaud namespace if the class object isn't immediately available?
allison yes, namespace object is an acceptable alternative
pmichaud okay.
PGE, PCT, and Rakudo will now evolve to eliminate all instances of new_p_sc
allison music to my ears :) 10:42
pmichaud but we need a short-term solution.
to the registry problem.
allison I'm not sure what the registry problem is
(other than the fact that it needs to die) 10:43
pmichaud I still can't create same-named classes across multiple HLLs
and you just saw the issue with Parrot_oo_get_class_str
that's going to be a HLL blocker, unfortunately.
allison yeah, that's a stupidity of looking up classes by string name :( 10:44
how about if we just replaced the registry with the namespace tree
each namespace object gets a unique id that it stores
dalek r34632 | kjs++ | trunk/compilers/pirc/new (4 files): 10:45
: [pirc] insert the value of a :named flag as an extra argument. +Do some magic with flags.
review: www.parrotvm.org/svn/parrot/revision?rev=34632
10:45 AlexLibman joined
pmichaud that would probably work. Ultimately the problem is fixing all of the code that currently uses Parrot_oo_get_class_str, I suspect. 10:46
I think that function ought to just go away also, if we only look up classes by namespace. 10:47
(or class object, or whatever else we're using besides strings)
allison what it used to do was just call Parrot_oo_get_class 10:48
but that was considered slow, because it created a PMC String
dalek r34633 | bernhard++ | trunk (2 files):
: [codingstd] set SVN properties
review: www.parrotvm.org/svn/parrot/revision?rev=34633
pmichaud yes, but if I pass a Key or String to Parrot_oo_get_class, I kind of assume that it's relative to my HLL. 10:49
allison and I think the code has diverged since the two were split
pmichaud Existing code likes to use Parrot_oo_get_class_str as a quick way to find, say "Integer"
allison that's fine as long as Parrot_oo_get_class_str and Parrot_oo_get_class do the same thing
it's only bad if they do different things 10:50
hmmm... looks like they do the same thing 10:51
(lookup the name relative to the HLL root, create a proxy if it's not found)
10:52 masak joined
pmichaud okay, so what's the correct workaround for something like src/pmc/capture.pmc:529 ? 10:55
lathos You want to workaround a workaround? 10:56
pmichaud lathos++
what's the correct approach for doing what src/pmc/capture.pmc is currently working around? ;-)
(point to example is fine :-) 10:57
allison pmichaud: what's it trying to do?
pmichaud: just instantiate a Capture object?
pmichaud that's an old (possibly outdated) pattern
if someone subclasses the Capture PMC, then we needed a way to get back to the non-proxied PMC instance 10:58
(I didn't write this code -- I just did a search for places using Parrot_oo_get_class_str and this popped up) 10:59
I guess it just needs to be using the GET_ATTR_array macro?
oh, no.
oh, yes. 11:00
allison I'm not sure why that code doesn't just create a 'pmc_new(INTERP, enum_class_Capture)'
lathos It's not instantiating anything.
pmichaud it's not creating a Capture, it's creating the array portion of the capture
lathos It's turning an existing capture into a list.
pmichaud it's adding a list component to a capture
allison lathos: it is, with CAPTURE_array_CREATE
pmichaud Capture objects create their list and hash components lazily, on demand.
instead of always creating a list and/or hash PMC when the Capture itself is created.
allison though, what it's instantiating there is a resizable array 11:01
lathos Yeah, that create is more of a check AFAICS.
if (!PARROT_CAPTURE(obj)->array) { make one } 11:02
pmichaud the list part is a resizablepmcarray, yes
lathos But the issue is not the array bit of the capture, the issue is when the capture itself is a proxied object.
pmichaud what the workaround is (was?) doing was making sure that "capt" was correctly pointing at the PMC that contains the array and hash slots
which isn't (wasn't?) the case for a subclassed instance of Capture 11:03
allison if I read that right, it's instantiating a resizable array, and storing it as the 'array' attribute on an instance of Capture
pmichaud that's what CAPTURE_array_CREATE does, yes.
lathos allison: We're talking about the bit before that. (Are your line numbers up to date?) 11:04
allison (though it looks like it should be storing it on the 'array' attribute of a PMCProxy of Capture, but it can't possibly be doing that because PMCProxies don't have an array attribute
lathos So what it does instead is get the real underlying capture and store on that instead. It's how it should get at the underling Capture that we're wondering. 11:05
allison lathos: yes, but I can't say how to eliminate the work around until I can say for sure what the workaround is doing
pmichaud if I have $P0 = subclass 'Capture', 'MyCapture'
allison is this code actually tested anywhere?
pmichaud $P1 = new 'MyCapture'
$P2 = $P1.'list'()
then this method is called 11:06
lathos Yes, look in t/pmc/capture.t
pmichaud however, SELF is an instance of MyCapture, not a Capture PMC
allison and $P2 should be what?
lathos Specifically pir_output_is( <<'CODE', <<'OUTPUT', 'list method delegation' );
pmichaud ($P2 will end up being an empty ResizablePMCArray in this instance)
(but what $P2 ends up with is somewhat irrelevant to what I'm asking about.)
so, as part of the 'list' method, a new ResizablePMCArray should be created if it doesn't exist, and placed in the Capture PMC's array slot 11:07
allison Okay, well either way, what it should be doing instead is either a straight lookup of the Capture PMC
pmichaud where "straight lookup" is...?
allison (which will lookup the Capture namespace and return the class) 11:08
lathos Which is basically what we are asking how to do.
allison or, it should be instantiating enum_class_Capture
pmichaud note that I'm not creating a Capture PMC in this method.
allison A straight lookup is 'PMC *classobj = Parrot_oo_get_class_str(INTERP, classname);'
pmichaud that's not what we're doing.
mypoint is that this is *wrong* 11:09
allison that whole business with the proxy is a red herring
pmichaud we can't use Parrot_oo_get_class_str here.
allison why not?
is it not relative to the current HLL?
lathos You have to deal with the proxy somehow if someone calls list() on a Capture subclass.
allison it's a class in the 'parrot' hll?
pmichaud only if the interpreter was somehow set to Parrot prior to calling this method
allison yes, but get_class returns a proxy for C-level classes 11:10
so, the code here shouldn't have anything to do with the proxy
okay, I get it
this isn't a 'proxy' as in a PMC proxy for the class 11:11
dalek r34634 | bernhard++ | trunk/languages/pipp/t/php:
: [Pipp] untodo a test case
review: www.parrotvm.org/svn/parrot/revision?rev=34634
allison this is the delegate object
lathos Yes!
pmichaud right.
sorry, I didn't know/remember the term "delegate object"
allison which should be named 'delegate' or something sane
so, those sick delegate objects go away if you use GET_ATTR_* 11:12
pmichaud okay, that was what I was hoping.
so I'll switch things to use GET_ATTR_*
allison so, if you need the 'foo' attribute of the parent C class, just declare one of the same type and name in the child class 11:13
in the child PIR class
pmichaud yeah, I don't have any instances of those.
allison ultimately this will be automated by simply calling 'subclass', but I don't think it's automated yet
lathos Incidentally, would it be useful to allow both relative and absolute access (think pathnames) to namespaces? 11:14
allison lathos: that's what we were talking about
pmichaud lathos: we do that with the get_hll_namespace and get_namespace opcodes
also with get_hll_global and get_global 11:15
(and get_root_* variations of these as well)
allison lathos: and the answer is yes, but to reserve the short form for the relative namespaces
lathos: that is, short form as relative to hll root
pmichaud allison: iiuc, the 'new' opcode doesn't use relative namespaces, though, yes? or it's just relative to hll root
okay.
relative to hll root is fine with me. 11:16
allison pmichaud: yeah, only relative to hll root
pmichaud the other is easily done with get_namespace :-)
allison yeah
lathos Ack, I forgot the HLL/Parrot root dance too.
Perhaps we need pathnames with drive letters. ;)
allison lol :)
pmichaud I want to reserve the Z: drive for Rakudo, then :-) 11:17
allison: doing a quick search for Parrot_oo_get_class_str doesn't turn up too many instances, so I think we're in okay shape.
we do need to fix that pmcproxy.pmc case at some point. 11:18
allison pmichaud: that's good
pmichaud there's a bunch in the delegate.pmc code, though.
the rest look pretty sane to me.
allison delegate.pmc is in desperate need of a refactor anyway 11:19
needs to be using class objects
pmichaud I can fix the instances in capture.pmc, and there's one in class.pmc that is probably suspicious.
allison and then there's this one in pmcproxy.pmc that we know is broken 11:20
(the start of this conversation)
pmichaud yes -- maybe jonathan can do something with thatl.
(since he wrote it, I think :-)
okay, I need sleep. 11:21
thanks for the excellent discussion and for helping to resolve some key issues.
allison and thanks for raising key issues 11:22
11:23 ruoso joined
dalek r34635 | bernhard++ | trunk/languages/pipp/src/pct: 11:30
: [Pipp] Use a list of strings for declarung the superglobals
review: www.parrotvm.org/svn/parrot/revision?rev=34635
barney found another Parrot: www.featherweightaltimeters.com/Parrot.php 11:49
11:51 rurban_ joined 12:00 register joined
Coke If we have a series of ops that just dispatch to methods... why don't we just eliminate the ops and have the users call the methods? 12:10
12:11 pdcawley joined
dalek r34636 | kjs++ | trunk/compilers/pirc/new (4 files): 12:17
: [pirc] fix :named parameters. works for simple cases (non-aggregate).
review: www.parrotvm.org/svn/parrot/revision?rev=34636
12:18 gmansi joined
Tene kjs++ 12:23
12:26 kid51 joined
Coke after the run of the last attempt at tcl's spec test, I'm now running 4 times slower and passing about 1/2 the number of tests I was. this is after about 400 parrot revs and about 30 partcl revs. 12:26
(this with no regressions in the normal 'make test') 12:27
dalek r34637 | bernhard++ | trunk/languages/pipp/src/pct:
: [Pipp] clean up trailing spaces and unused register $P2
review: www.parrotvm.org/svn/parrot/revision?rev=34637
Coke most of the failures are from losing entire files, presumably due to eventual memory panics.
Coke sighs.
->
Tene Coke: Ew. That's horrid. Us-- 12:28
kid51 What are we doing wrong?
Tene Partcl's spectests are running four times slower and passing half as many, possibly due to parrot OOMing. 12:29
kid51 OOMing?
Tene out of memory
purl hmmm... out of memory is at www.negativland.com/audio/memory1.wav
kid51 purl OOMing is running out of memory 12:30
purl OK, kid51.
dalek r34638 | bernhard++ | trunk/docs/user/pir (3 files): 12:35
: [docs] add lines with svn-keyword $Id$
review: www.parrotvm.org/svn/parrot/revision?rev=34638
12:37 flh joined
flh hi everyone 12:38
purl Howdy, flh, you fantastic person you.
12:45 TonyC joined
dalek r34639 | bernhard++ | trunk/docs/user/pir: 12:47
: [docs] use 'say' instead of 'print' in two code examples
review: www.parrotvm.org/svn/parrot/revision?rev=34639
r34640 | kjs++ | trunk (9 files): 12:48
: [pirc] refactor PCC related functions in a new file. svn props are set. MANIFEST is updated.
review: www.parrotvm.org/svn/parrot/revision?rev=34640
r34641 | kjs++ | trunk/compilers/pirc/t: 12:52
: [pirc] fix syntax error in test file.
review: www.parrotvm.org/svn/parrot/revision?rev=34641
r34642 | bernhard++ | trunk/languages/pipp/src/common: 13:02
: [Pipp] Remove unused sub
review: www.parrotvm.org/svn/parrot/revision?rev=34642
justin \\ 13:04
dalek r34643 | kjs++ | trunk/compilers/pirc/new (2 files):
: [pirc] disallow users to write full signatured ops; it's not practical, not necessary, and would add a lot of complexity to PIRC. Just don't do it. Stick to 'set' as opposed to e.g. 'set_i_ic'
: + whitespace
review: www.parrotvm.org/svn/parrot/revision?rev=34643
justin 7887
788730-12 13:38.12 <+purl> Howdy, flh, you fantastic person you.
30-12 13:42.25 -!- TiMBuS [~Hurf@123-243-167-27.static.tpgi.com.au] has quit [Quit: Leaving]
oops
ignore that ;-)
dalek r34644 | bernhard++ | trunk (2 files): 13:18
: [docs] Add languages/README, pointing to the wiki
review: www.parrotvm.org/svn/parrot/revision?rev=34644
Coke tene: it is possible that changes to partcl are responsible for all of that. I have no easy way to tell with continuing deprecations and no profiling. 13:24
barney: if we have the README and the wiki, can we now kill LANGUAGES.STATUS?
I started to go through and verify that the wiki wasn't missing anything from the .STATUS file, but it took a while. 13:25
that is, I got distracted. 13:27
I really think both parrot and partcl could benefit from parrot folks digging through partcl and saying "why the HELL are you doing it this way?" 13:29
barney Coke: I wouldn't mind killing LANGUAGES.STATUS 13:36
Coke barney: there's a ticket for it.
TT #46 13:37
barney++ 13:38
13:39 ChrisDavaz joined
barney claimed TT #46 13:43
13:48 ask_ joined
dalek r34645 | bernhard++ | trunk/languages/pipp/src (2 files): 13:53
: [Pipp] Store the new class in the register 'def'
review: www.parrotvm.org/svn/parrot/revision?rev=34645
r34646 | kjs++ | trunk/compilers/pirc/new: 13:56
: [pirc] fix some iteration code; however, this messes up the result registers for get-params. They're now in reversed order. Will fix this later.
review: www.parrotvm.org/svn/parrot/revision?rev=34646
14:04 jimmy joined
dalek r34647 | kjs++ | trunk/compilers/pirc/new: 14:08
: [pirc] rename some stuff, so I can understand what's going on.
review: www.parrotvm.org/svn/parrot/revision?rev=34647
r34648 | kjs++ | trunk/compilers/pirc/new: 14:25
: [pirc] some comments updates.
review: www.parrotvm.org/svn/parrot/revision?rev=34648
14:27 tetragon joined 14:31 apeiron joined
Coke anyone familiar with parrot guts who can tell me all the C functions which are responsible for invoking things with the PCC? 14:33
partcl? 14:34
purl rumour has it partcl is tcl on parrot or code.google.com/p/partcl or slow, help make it go faster
Coke no, partcl is tcl on parrot or code.google.com/p/partcl or slow and a memory pig and pretty much not usable.
purl okay, Coke.
masak Coke: I know the feeling. 14:36
November?
purl November is at www.november-wiki.org/ or use.perl.org/~masak/journal/37212 or github.com/viklund/november/
Coke ah. i had heard that rakudo was zippy enough. 14:37
no?
masak Coke: define 'enough'.
Coke "better than partcl", I suppose. 14:38
masak Coke: precompiling to PIR turns unusable to just sluggish, I'd say.
Coke whee. I cannot even /run/ append.test on feather. 14:39
masak :/
Coke PANIC: out of memory
purl it has been said that out of memory is at www.negativland.com/audio/memory1.wav
dalek r34649 | kjs++ | trunk/compilers/pirc/new: 14:42
: [pirc] small refactoring, dedenting some code. + some function doc.
review: www.parrotvm.org/svn/parrot/revision?rev=34649
Coke so much crap, so little time. 14:45
masak pmichaud: #61838 was a bit of a surprize. both that and #61842 show that there are still spectests that need to be written. 14:55
also, crashing Parrot with (0,)[*-1..*] was fun. 14:56
rakudo: (0,)[*-1..*]
polyglotbot OUTPUT[src/inter_call.c:390: failed assertion 'PObj_is_PMC_TEST(sig_pmc)'ā¤Backtrace - Obtained 32 stack frames (max trace depth is 32).ā¤ (unknown)ā¤ Parrot_confessā¤ Parrot_init_arg_opā¤ Parrot_init_ret_nciā¤ (unknown)ā¤ (unknown)ā¤ Parrot_NCI_invokeā¤
.. Parrot_pcc_invoke_sub_from_sig_object...
masak sort of like a secret code that opens up an impenetrable machinery. 14:57
Coke Aoogha. We have a "64-bit tell"? 15:01
dalek r34650 | fperrad++ | trunk/languages/lua/src/lib: 15:10
: [Lua] io
: - refactor io.tmpfile() with a StringHandle PMC
review: www.parrotvm.org/svn/parrot/revision?rev=34650
15:19 jhorwitz joined
masak fperrad? 15:20
purl rumour has it fperrad is mailto:francois.perrad@gadz.org
15:21 gryphon joined
Coke if someone is bored, they could probably find a few more tickets like TT #102 that involve the "don't touch" opcodes. 15:24
Coke wonders what "TOTAL_COPIED" means in interpinfo. 16:04
register whos is the parrot commiter under the pseudo of leo? 16:08
Coke leo? 16:11
purl leo is possibly leo lapworth eq ranguard or one of parrot's older contributers.
Coke leo is also Leopold Toetsch 16:12
purl okay, Coke.
Coke he hasn't committed in some time. why do you ask?
(when in doubt, check the CREDITS file.)
register because i see that he was one of the committer in the jit.c file 16:13
Coke whee. anyone think 3 million active PMCs for a dozen lines of tcl is a bit much? 16:25
masak it does sound a bit on the high side, yes. 16:32
pmichaud masak: I'm working on #61838 in the rvar branch. 16:35
tewk daniel grunblatt?
masak pmichaud: nice.
tewk purl daniel grunblatt is daniel@grunblatt.com.ar 16:36
purl OK, tewk.
pmichaud #61842 is the same issue whereby slices think that any empty list mean "return the full array"
I might be able to fix it quickly.
masak pmichaud: aye, I just realized that. 16:37
Coke I pick up about 3K pmcs a shot each time through a while loop.
pmichaud I think it depends on the dozen lines of tcl :-)
16:38 register_ joined
pmichaud rakduo: for 1..3000000 { .say }; # 3 million active PMCs in one line :-) 16:38
Coke hurm. I seem to be creating exception handlers in loops now. I blame tene. =-) 16:39
pmichaud #ps in 110 16:40
Coke added trac.parrot.org/parrot/wiki/ParrotBestPractices 16:46
16:52 mberends joined
masak a perl6 process running the above loop takes a few minutes to start printing numbers on my machine. after that it takes about half a gigabyte of RAM while it prints numbers in spurts of a couple of tens of thousands. 16:55
pmichaud masak: (few minutes) it's building the 1..3000000 range :-)
ranges aren't lazy in Rakudo yet
masak aye, I realize that. :)
pmichaud I'm kinda surprised it even makes it 16:56
masak me too :)
16:58 hercynium joined 16:59 Zaba joined
Coke imagine my surprise when i started being able to tcl's spec tests. 17:01
masak that sentence no verb.
pmichaud "imagine" is a verb. :-P
masak right. not enough verbs. 17:02
pmichaud plays "guess the missing verb"
masak "eat tcl's spec tests"?
"harass tcl's spec tests"? 17:03
pmichaud "delete"
masak *lol*
mberends "grok"
pmichaud "pass"
masak "test"
nopaste "Coke" at 65.91.151.195 pasted "This prints 1807" (16 lines) at nopaste.snit.ch/15133
masak "fail" 17:04
"see"
mberends "tickle"
masak "entertain"
Coke run.
mberends "imagine"
purl i heard "imagine" was a verb. :-P
masak Coke: totally didn't see that one coming.
purl: you are so corny sometimes.
purl ...but purl is a she. or captain obvious...
masak purl is also so corny sometimes 17:05
purl okay, masak.
Coke if I just jump to done, i get 1735 pmcs.
so with no pmc creation on my own, I still end up with nearly 2K pmcs. 17:06
dalek r34651 | pmichaud++ | trunk/languages/perl6/docs: 17:11
: [rakudo]: spectest-progress.csv update: 264 files, 5912 passing, 0 failing
review: www.parrotvm.org/svn/parrot/revision?rev=34651
masak
.oO( almost 6k )
 17:12
pmichaud yes. I don't think we'll make 6k in december, though, unless the parameter refactor passes a bunch of spectests, or someone finds a nice cache of tests that we can pass quickly. 17:13
still, december has been a very good month. 17:14
5912-4689
purl 1223
pmichaud 1223 new passing tests in december. What's more, some of them are really good things to be passing, like slices and list assignment. :-)
I have a fix for the @a[2..1] bug, running spectest now. 17:15
masak \\o/ 17:18
Infinoid wow, that means more than 20% of our current passes are new 17:21
masak that explains why some things aren't 100% stable yet. :) 17:22
pmichaud do we have a test for @a[2..1] ? 17:23
masak doesn't know 17:24
dalek r34652 | pmichaud++ | trunk/languages/perl6/src (2 files): 17:27
: [rakudo]: Fix empty slice -- e.g., @a[2..1] . Resolves RT #61842.
review: www.parrotvm.org/svn/parrot/revision?rev=34652
masak the script reached 3000000 now. 17:29
took about half an hour.
pmichaud say '\\o/' xx 3000000
masak heh 17:30
Coke ps in 60. 17:32
is there a way to say "free this pmc"? 17:33
(the opposite of "new") ? 17:34
Infinoid are you sure it isn't being pointed to by anything else?
pmichaud you want ordered destruction? ;-)
Coke Infinoid: no, and SFAIK, I have no way to see what is pointing at a given PMC.
if I trusted the GC (see recent email thread) I wouldn't ask. =-) 17:35
Infinoid :)
pmichaud GC is scheduled to be fixed this month, see roadmap. :-) :-)
Coke yahhh. 17:36
Infinoid I've got a fun problem. 17:37
charsets and encodings are registered by init functions when parrot starts. first encodings are registered, and then charsets are.
it looks to me like if any strings are created before this init phase finishes, their encoding/charset pointers are NULL
but, of course, the encoding init function tries to create a string (the name of the encoding) which ends up with a NULL charset pointer 17:38
this violated the ARGIN() check because the pointer was null, which is why I'm looking at it.
allison Infinoid: Sounds like it needs a two-stage process, first register the charsets, then set their names 17:39
charsets/encodings
nopaste "Infinoid" at 75.5.247.153 pasted "charset=0x0. do I need to worry about this?" (11 lines) at nopaste.snit.ch/15134
Infinoid well, parrot has obviously been working fine for months, so it doesn't seem like a big deal. but I'm not sure changing ARGIN to ARGIN_NULLOK is the right solution 17:40
allison: that sounds doable
allison where did you encounter the problem? 17:41
Infinoid miniparrot
purl hmmm... miniparrot is not working yet, is it?
Coke purl, forget miniparrot
purl Coke: I forgot miniparrot
17:41 Wknight8111 joined
Coke what were you using miniparrot for? 17:41
allison Infinoid: just in trunk? with no changes?
Infinoid I'm adding asserts to enforce NONNULL pointer semantics. see trac #105
Coke just the normal build bit?
Infinoid yeah
this is one of the issues my patch caught, and I wasn't sure what the best fix is 17:42
Coke allison: made a slight improvement to partcl's memory pressure woes. need more. =-)( 17:43
er, =-)
allison Infinoid: well, if it worked just fine with a null charset, that means it's setting a sane default somewhere, so probably safe to leave it 17:44
Infinoid so I can change ARGIN to ARGIN_NULLOK to skip the check?
allison Infinoid: yup, try that
Infinoid thanks.
allison Coke: excellent! I saw something about 3M PMCs for a few lines of code? 17:45
Coke yes.
allison Coke: yeah, that'll bite
Coke I think i shaved off about 500,000; no clue why the ones I avoided creating were not getting freed, however.
allison Coke: in a program that's only a few lines, it may never be running GC at all 17:46
Coke allison: uh.. 17:47
allison though, with 3M PMCs, it must
pmichaud (few lines of Tcl code, not a few lines of PIR, IIUC)
Coke it's a few lines of tcl; that involves PGE, TGE, the tcl runtime...
the output showed over 100 DOD runs, IIRC. 17:48
allison well that's a relief
Coke (and 8M of memory)
if I have a global *Array, and I pop a hash off the end of it, should everything in that hash (barring other references) get collected? 17:50
Wknight8111 I have a suspicion that the GC is not accurately counting the number of PMCs it's freed 17:51
Coke or, because it's a container, would the hash and its contained PMCs keep each other alive?
Wknight8111 if nothing points to the hash or it's children, they would all get collected 17:52
allison Coke: nope, as long as there are no other references to the container, it will die
Coke k. just looking for potentially obvious places where things might not be getting collected.
allison Coke: if there are other references to some of the children, they will live, even though the container dies
Coke be nice if I had a way to dump the chart generated by a dod run. 17:53
allison Coke: yes, I've often wished for that
Coke otherwise I'm (still) shooting in the dark. =-)
Wknight8111 A dump of that wouldn't be too too hard to create, algorithmically. But if you had 3M PMCs, the output would be hell to read. 17:54
Coke Wknight8111: I'd trim up my sample code first. 17:55
there were some loops in that code. =-)
here's a scenario that tcl uses: i create an anonymous sub. I create a pir subclass of Sub, assign the anon sub into it. Does the anonymous sub go away? 17:56
Wknight8111 no, it shouldnt
Coke why not? nothing refers to it, right?
Wknight8111 the pir subclass object refers to it 17:57
pmichaud it does? why?
Coke it doesn't have a copy of it.
it's not a has-a, it's a is-a.
Wknight8111 i must not be understanding the question
pmichaud create an anonymous sub ('X'), create an instance of a subclass of Sub, assign X into the instance, does X go away? 17:58
Coke code.google.com/p/partcl/source/bro...n/proc.pir
shorten Coke's url is at xrl.us/bea3cs
pmichaud Coke: I suspect it depends on how your subclass of Sub handles assignment
Coke (about line 213)
pmichaud: whatever the default is. 17:59
Wknight8111 then no, the instance of the subclass would contain a reference to X
Coke subclass: code.google.com/p/partcl/source/bro...clproc.pir
ok. is there a way to keep the subclass that doesn't keep a copy of the thing I assigned to it? 18:00
(the only reason I have the subclass atm is to easily add attributes to .Sub's, but that class will do more eventually)
pmichaud Coke: it may be a moot point -- istr jonathan mentioning something about compiled subs going into the constant PMC table
allison if it's stored anywhere that's reachable from the root-set, it'll be kept
Coke Ok; how do I force it to go away, then? 18:01
Wknight8111 take away all references to it
Coke ... where are those references?
pmichaud however, assigning to a Sub does _not_ appear to create a reference.
Coke if it's in the root set and I didn't put it there...
pmichaud so "the instance of the subclass would contain a reference to X" isn't correct at first blush 18:02
Wknight8111 I'm not sure about this, the sub may be constant and never disappear
pmichaud that would be consistent with what jonathan said, I think.
18:02 chromatic joined
Coke pmichaud: so if I use this approach, I basically get two subs for the price of one? 18:02
Wknight8111 i would need to do a lot more digging to find the real answer
Coke er, one sub for the price of two, I mean. 18:03
rurban Why is compilers/imcc/imclexer.c [main] in the MANIFEST.generated?
shorten Coke's url is at xrl.us/bea3c6
Coke wow, shorten. keep up.
pmichaud Coke: if compiled subs are gc-able objects, then I would suspect that X would eventually be collected in your scenario
Infinoid rurban: isn't it generated by flex? 18:04
pmichaud if compiled subs are not gc-able (i.e., constant PMCs), then assigning to a TclSub would leave you with two PMCs (one gc-able, one not)
rurban I assume all compilers/* files can be deleted from this MANIFEST, or maybe getting installed into the runtime library
chromatic You should probably install PGE, PCT, and NQP files.
pmichaud what MANIFEST are we referring to here? 18:05
rurban Infinoid: yes, but I thought only files which should get installed should be kept there. But I see. To clean up generated files it must be there also.
pmichaud the MANIFEST for the download/build tarball?
iiuc, MANIFEST is the list of files that should be present in the tarball.
rurban MANIFEST.generated on wihc I'm working right now. I completely generate it now at build-time
Coke I wonder if not managing my own lexpads would help ease the pressure. 18:06
rurban RT#40817 MANIFEST-generated.patch
18:06 ruoso joined
rurban But many interim pir's are also generated, and these are not kept in MANIFEST.generated. Should they be added? 18:08
Coke in rakudo, you're storing subs as 'subname' in the ns, and variables as (e.g.) '$variable' ? 18:09
18:09 Zaba joined
pmichaud PGE and PCT already put their installable components into runtime/parrot/library 18:09
Coke (not '&subname')
rurban okay. I added them for consistency
pmichaud so there's not a need to install their generated .pir components
Coke: yes.
rurban I have now tge and json, the top of MANIFEST.generated
Coke json probably isn't worth installing. 18:10
pmichaud json would be a good candidate for rewriting in p6 :-)
or nqp
Coke plus there's a languages/ variant.
18:11 ask_ joined
Coke I do wish we had a better solution than sigils to avoid allow different types in a NS. 18:12
s/avoid//
(string manipulation sucks) 18:13
pmichaud rakudo doesn't do much in the way of string manipulation to manage this, though.
i.e., it all just falls out naturally 18:14
nopaste "rurban" at 212.183.50.193 pasted "40817-MANIFEST-generated.patch" (1463 lines) at nopaste.snit.ch/15135 18:16
rurban Is a compiler the same as a language (from the installation pov)? nqp e.g. Should I make an excemption in install_files for the to be installed compilers, or should I add make install targets to their makefiles? 18:22
pmichaud there was a long discussion about where they should go 18:23
rurban Sorry, I missed that
pmichaud but yes, they should be treated the way as language installs
(imo)
*same way 18:24
rurban I assume into runtime/parrot/library
as pir and as pbc.
pmichaud actually, allison specifically rejected that
and I wouldn't install the pir, just the pbc
rurban okay.
pmichaud #ps in 5 18:25
18:25 frodwith joined
pmichaud rurban: irclog.perlgeek.de/parrotsketch/200...9#i_559123 18:27
#ps in 0 18:30
dalek r34653 | allison++ | trunk/src/io: 18:31
: [io] Setting append mode also sets write mode.
review: www.parrotvm.org/svn/parrot/revision?rev=34653
18:33 Zaba joined
chromatic Does anyone else find the GET_ATTR_foo in-place modification confusing? 18:40
allison chromatic: yes, but it was the only way to make those macros work. Feel free to refactor. 18:42
chromatic Will try. 18:43
Coke what about the remaining mmd function to be removed? 18:59
chromatic_away axe them 19:01
Coke it's actually invoked, though.
just don't call it? 19:02
chromatic_away What invokes it? 19:03
Coke Parrot_mmd_get_cached_multi_sig
dalek r34654 | fperrad++ | trunk/languages/lua/src:
: [Lua]
: - revert r34355 for luap.pir
review: www.parrotvm.org/svn/parrot/revision?rev=34654
Coke which in turn is called by mmd_distance 19:04
(why doesn't that have a Parrot on it?)
chromatic_away It's not external. 19:05
I'll take a look.
Coke but Parrot_mmd_get_cached_multi_sig is?
odd.
chromatic_away Yeah. 19:06
Coke allison: can you do a quick run through the RTs in deprecated.pod and see if they trail off with "I need direction on this one"?
the one for get_mro, for example, does.
(from some time ago)
allison Coke: ok 19:07
19:07 brunoV joined 19:08 brunoV left
Coke allison: Danke. 19:09
dalek r34655 | coke++ | trunk: 19:10
: This ticket was closed by tene on December 10, 2008.
review: www.parrotvm.org/svn/parrot/revision?rev=34655
Coke as i recall, new_from_string was also chip's, and also tricky. 19:11
tene__
tene++
allison Coke: you can kill the 'new_from_string' deprecation item and the associated ticket. It's just not important, and won't happen anytime soon 19:13
Coke: it may never happen, but if it does, we can figure it out then. 19:14
Coke: oh, I see someone merged in a ticket about 'new_from_string' being broken 19:16
Coke ayup. so if we don't kill it, we have to fix it. =-)
allison okay, well the task of removing it is to add an 'init_str' vtable function 19:17
and corresponding 'pmc_new_str' C functions 19:18
and corresponding new_p_x_sc opcodes
Coke 's eyes glaze over. 19:21
allison :)
that is to say, it's actually a pretty simple task, probably take a couple of hours, a day at most
but, that won't fix the problem with FixedIntegerArray 19:22
Coke I have no idea what is involved in scope based on your comments there.
<weasel> if you could just update the ticket... </weasel>
allison basically, we've got about 3 completely unrelated tickets here all bundled into one 19:24
pmichaud trac tickets are cheap 19:25
unbundle the rt ticket into trac tickets, then mark the ones that are needed for the milestone :-)
Coke allison: remove_pic doesn't even /build/ for me. =-)
allison Coke: which platform? 19:26
purl I'm running on OS/2 on an Atari, can you help?
Coke feather.
purl well, feather is feather.perl6.nl/ or a perl6 community development server
Coke tries again without -j
allison I don't know what feather is, some linux variant
masak pmichaud: I have a question. is merging the p5 and Rakudo runloops on a roadmap somewhere?
Coke src/jit.c:1624: error: 'PARROT_OP_pic_callr___pc' undeclared (first use in this
pmichaud it's not officially on a roadmap at the moment, no. 19:27
Coke allison: Linux feather 2.6.18-6-xen-686 #1 SMP Sun Feb 10 22:43:13 UTC 2008 i686 GNU/Linux
pmichaud that is the likely ultimate outcome, however.
allison Coke: ah, okay that's the last remaining piece of the old system I mentioned
pmichaud I feel we need a roughly working p6 implementation before I bog down too much in figuring out p5
masak pmichaud: understood.
purl understood. are you on schedule?
Coke ah. probably a makefile dep, then. 19:28
allison Coke: it's an actual indirect call to an opcode that doesn't exist anymore
Coke ah.
Coke wonders how this built, then. 19:29
allison Coke: it passes over that on OSX, because of dynamic loading
masak pmichaud: I think p5 runloop access is now somewhere very high on my wish list. but OTOH, it's not urgent.
just very, very desirable. :)
dalek r34656 | particle++ | trunk/t/compilers/imcc/syn: 19:30
: [t] correct regex in expected output causing unexpected failure
review: www.parrotvm.org/svn/parrot/revision?rev=34656
allison Coke: I can look at that tonight 19:32
Coke hokay.
I have no idea how to fix it. =-)
allison Coke: I suspect it's just a matter of creating a simplified variant of the opcode that doesn't use PIC 19:33
19:38 ask_ joined
Coke pmichaud: can branches/rt59410 be removed? 19:40
pmichaud yes. 19:41
Coke (I assume it's related the RT ticket of that number which is closed.)
dalek r34657 | coke++ | branches: 19:42
: The ticket that this branch corresponds to was closed on October 01, 2008
: Ok to delete, per pmichaud++
review: www.parrotvm.org/svn/parrot/revision?rev=34657
19:44 chromatic_away left, chromatic joined
Coke pmichaud: the deprecation notice for 60384 is still around; the ticket is resolved, I presume it's safe to remove the deprecation note? 19:44
19:45 justin joined
pmichaud Coke: yes. 19:45
Coke particle: ok, I cleaned up most of the DEPRECATION notes; you can get the rest. =-) 19:49
dalek r34658 | coke++ | trunk:
: This ticket was resolved on December 15th, 2008 by pmichaud++
review: www.parrotvm.org/svn/parrot/revision?rev=34658
Coke tewk: is 60590 still on your list? 19:50
er, s/still//
19:51 rurban_ joined
tewk Coke: its done. 19:52
dalek r34659 | pmichaud++ | branches/rvar/languages/perl6/src (2 files): 19:57
: [rakudo]: Fix my ($s, @a) assignment.
review: www.parrotvm.org/svn/parrot/revision?rev=34659
Coke tewk: woot. 20:00
dalek r34660 | coke++ | branches:
: starting over...
review: www.parrotvm.org/svn/parrot/revision?rev=34660
r34661 | coke++ | trunk: 20:01
: This ticket was resolved on December 30, 2008 by tewk++
review: www.parrotvm.org/svn/parrot/revision?rev=34661
20:10 alvar joined
dalek r34662 | coke++ | trunk/runtime/parrot/library: 20:13
: Avoid [DEPRCATED] opcodes. yaml tests still pass.
review: www.parrotvm.org/svn/parrot/revision?rev=34662
20:22 gmansi joined 20:26 ask_ joined 20:28 desertmax joined
dalek r34663 | coke++ | trunk/runtime/parrot/library/Tcl: 20:29
: avoid [DEPRECATED] opcodes. avoid a keyed lookup since we're already in this NS.
review: www.parrotvm.org/svn/parrot/revision?rev=34663
Coke bah. we have a lot of stuff in runtime/ that is still using flat namespaces with ::'s in them. 20:30
dalek r34664 | pmichaud++ | branches/rvar/languages/perl6/src/parser: 20:31
: [rakudo]: Remove $?SIGNATURE_BLOCK after grabbing signature as a declarator.
review: www.parrotvm.org/svn/parrot/revision?rev=34664
Tene okay, time to dive into PGE in pct_hll... 20:33
Coke question; when loading libraries, we should be telling people to get at them with get_root_global, not get_global, neh? 20:34
(since get_global is probably going to fail if they're in a HLL?)
chromatic Makes sense.
Coke s/HLL/some other namespace/ 20:35
chromatic One nasty IMCC/MMD hack goes away....
Coke if I change t/library/sort.t to lookup data/sort/simple with get_root_global instead of get_global, all tests fail. 20:36
desertmax SDL is currently broken. Here is a patch that fixes (at least) some parts of it, including the basic examples in examples/sdl. Minesweeper, Tetris and LCD however are still broken. stud3.tuwien.ac.at/~e0625243/parrot.../sdl.patch Should I post this to the mailing list / file a bug report first?
Coke definitely open a ticket. 20:37
thanks!
dalek r34665 | chromatic++ | trunk/compilers/imcc: 20:38
: [IMCC] Rearranged some struct members (hopefully to minimize their size due to
: padding and alignment).
review: www.parrotvm.org/svn/parrot/revision?rev=34665
Coke do we desire AUTHOR blocks? 20:39
I suspect no.
chromatic What's that? 20:40
Coke pod sections in file that says "I'm chromatic, and I maintain this file. but don't email me, email the list." 20:41
chromatic You can wipe them out. 20:43
I have those in Parrot::Embed because I intended to put it on the CPAN, but ... okay, maybe that one needs it.
20:44 s1n joined
particle the road to cpan is paved with good intentions. 20:44
chromatic It wasn't an issue when we uploaded Parrot to the CPAN, but it might be an issue in the future when we don't. 20:45
dalek r34666 | chromatic++ | trunk (3 files): 20:47
: [IMCC] [PIRC] [MMD] Fixed generation of multi signatures with no arguments,
: removing a nasty hack in the process (RT #45951).
review: www.parrotvm.org/svn/parrot/revision?rev=34666
r34667 | coke++ | trunk/runtime/parrot/library: 20:49
: Use the pmc's builtin sort method (C) instead of the library (PIR)
review: www.parrotvm.org/svn/parrot/revision?rev=34667
r34668 | tewk++ | trunk/src/pmc (2 files): 20:51
: [core] added get_repr to FixedStringArray and added get_repr to String
review: www.parrotvm.org/svn/parrot/revision?rev=34668
Coke if there's a parrot module that needs to get uploaded to the CPAN, I wonder if that belongs in the parrot repo. 21:01
wouldn't it be separate?
chromatic Why would it be? 21:02
Coke ... ok. 21:04
dalek r34669 | coke++ | trunk/runtime/parrot/library:
: take advantage of calling conventions and an opcode that probably didn't exist when this written.
review: www.parrotvm.org/svn/parrot/revision?rev=34669
Coke (it's author block should probably not be "you", though.)
bah, its.
dalek r34670 | chromatic++ | trunk (2 files): 21:05
: [MMD] [IMCC] Optimized MMD signature generation where dispatch types are known
: at compile time.
review: www.parrotvm.org/svn/parrot/revision?rev=34670
chromatic We do need a cohesive copyright policy.
Coke allison's got an open RT on that.
chromatic Any thoughts on the other MMD functions marked DEPRECATED? 21:07
GeJ Good morning everyone 21:08
chromatic is tempted to throw an exception when declaring a multi with an unknown type name. 21:11
barney desertmax: Please file a bugreport, including the patch 21:12
pmichaud chromatic: perhaps the type hasn't been created yet.
desertmax barney: rt.perl.org/rt3/Public/Bug/Display.html?id=61858 21:13
pmichaud Tene: why is PGE affected by hll?
barney desertmax: Sorry, I didn't scroll down in my IRC client 21:14
chromatic I know, but I'm still tempted.
Coke chromatic: the others?
purl the others is best left to offline processing
21:14 clunker9__ joined
Coke there's only one left, isn't there? 21:14
chromatic Coke, several more have {{**DEPRECATE**}} in their documentation.
Of course, they're static functions, so nothing else used them.
AHA
21:15 ask_ joined
dalek r34671 | coke++ | trunk: 21:16
: [docs] "not me!"
review: www.parrotvm.org/svn/parrot/revision?rev=34671
Coke chromatic: ?
if nothing is using them, and they are internal...
they doesn't require a deprecation cycle, duzzit?
dalek r34672 | bernhard++ | trunk/languages/pipp/src (2 files): 21:17
: [Pipp] Use a plain 'Class' pmc for PHP classes.
: Work on public class members.
: Fail with setting up a default values of member variables.
review: www.parrotvm.org/svn/parrot/revision?rev=34672
chromatic Nope, removing now. 21:18
Coke chromatic++
chromatic Hm, the core tests seem about 10% faster now, for some reason.
We're not going to be able to get rid of mmd_cvt_to_types anytime soon unless we make really big changes to how we do MMD. 21:21
dalek r34673 | bernhard++ | trunk (8 files):
: RT #61858: SDL library bindings and examples broken
: Courtesy of Markus Mayr.
review: www.parrotvm.org/svn/parrot/revision?rev=34673
r34674 | chromatic++ | trunk/src: 21:22
: [MMD] Removed deprecated static functions no longer used within this file and
: not visible externally (so that they need no public deprecation cycle).
review: www.parrotvm.org/svn/parrot/revision?rev=34674
21:24 TiMBuS joined
barney Is there a HLL in Parrot, that support default values of class attributes ? has $x = 'default' ? 21:24
PerlJam barney: doesn't rakudo do that now? 21:25
particle coke: put File/Spec.pir on the remove list 21:28
barney I haven't checked. '!keyword_has' didn't look like it 21:29
particle rakudo: class Foo { has $bar = 'default'; }; my Foo $x .= new; $x.bar.say; 21:30
polyglotbot OUTPUT[Method 'bar' not found for invocant of class 'Foo'ā¤current instr.: '_block14' pc 150 (EVAL_12:71)ā¤called from Sub '!UNIT_START' pc 16073 (src/builtins/guts.pir:327)ā¤called from Sub 'parrot;PCT;HLLCompiler;eval' pc 892 (src/PCT/HLLCompiler.pir:508)ā¤called from Sub
..'parrot;PCT;HLLCompiler;evalfiles' pc 1217 (src/PCT/HLLCompiler.pir:669)ā¤cal...
particle probably forgot a necessary twigil there...
21:33 ask_ joined
barney rakudo: class Foo { has $.bar = 'default'; }; my Foo $x .= new; $x.bar.say; 21:34
polyglotbot OUTPUT[ā¤]
barney Yes, it parses, but the default is not stored in Foo
particle i thought jonathan had that implemented, but it seems i'm mistaken. 21:35
PerlJam too
Coke chromatic: can you add a note to that effect to the ticket? 21:40
perhaps we can resolve it as is; I think allison did the initial request on that, neh? 21:41
chromatic Yes.
Coke particle: what replaces it?
particle nothing uses it. it's half-implemented on win32 and abandoned. 21:42
(and not implemented on any other platforms)
GeJ lastlog GeJ 21:44
Coke particle: done. 21:45
particle coke++
chromatic GeJ, I'll check in your patches from yesterday soon. 21:47
GeJ chromatic: thanks... I'm working on t/oo/new.t so I can get the whole directory "pir_output_is"-free 21:48
Also, I posted a request for comments last night, but I guess almost everybody in the US was long gone.
nopaste.snit.ch/15129
Just to know if it's worth putting in the test suite 21:49
chromatic I'm surprised I didn't think of it. That should make the test non-TODO.
GeJ Good, Well, I'm going to finish this last file and will paste results when I'm done. 21:51
21:52 Whiteknight joined
particle related to that nopaste, should we be converting all $Px = new 'Foo' to ['Foo'] ? 21:54
dalek r34675 | chromatic++ | trunk (6 files):
: [ops] Removed deprecated infix and n_infix ops.
review: www.parrotvm.org/svn/parrot/revision?rev=34675
jonathan (attribute init) I thought I knot only had it implemented, but also unfudged related spectests. 21:57
particle jonathan: agreed
PerlJam jonathan: perhaps on a branch that didn't get merged?
particle there are several spectest failures for me, but they seem to be io and inf/nan-related
jonathan I rarely work in branches, and I'm almost certain I didn't do that in one. 21:58
Plus if there were unfudges...
rakudo: class Foo { has $.x = 42; }; say Foo.new.x
polyglotbot OUTPUT[42ā¤]
jonathan rakudo: class Foo { has $.x = 'default'; }; say Foo.new.x 21:59
polyglotbot OUTPUT[defaultā¤]
jonathan rakudo: class Foo { has $.x = 'default'; }; my $x = Foo.new; say $x.x
polyglotbot OUTPUT[defaultā¤]
jonathan rakudo: class Foo { has $.x = 'default'; }; my Foo $x .= new; say $x.x
polyglotbot OUTPUT[ā¤]
jonathan ...odd...
Why on earth would that make a difference. :-S 22:00
Tene pmichaud: I'm not sure yet.
particle odd is right. 22:01
--target=pir to the rescue, i hope!
Tene pmichaud: did we need to harass Jonathan about that crash I found last night? 22:02
I was only partially awake for its discussion.
barney needs to add !ADD_TO_WHENCE to Pipp, tomorrow 22:05
jonathan Uh-oh...what else have I done? :-)
rakudobug? 22:06
purl rumour has it rakudobug is mailto:rakudobug@perl.org
jonathan (filed ticket on that default issue) 22:07
Tene jonathan: I'm getting a crash in my pct_hll branch in the second hunk of www.parrotvm.org/svn/parrot/revision?rev=33520
When it calls Parrot_oo_get_class_str, Parrot_oo_... makes a new PMCProxy, which ends up infinite loop 22:08
jonathan I'm probably a reasonable person to harrass about that. 22:09
Tene nopaste.snit.ch/15130 is a backtrace
jonathan Have you a relatively compact PIR example to reproduce it?
Tene Nope! Trying to run rakudo in the branch triggers it, though. 22:10
There was a lot of disucssion on IRC last night about it...
purl: parrot log?
purl parrot log is probably probably irc log
Tene purl: irc log?
purl irc log is irclog.perlgeek.de/parrot/
pmichaud jonathan: the problem is that calling Parrot_oo_get_class_str doesn't work if we're not in the same HLL
i.e., looking up a class by name is problematic.
just a sec...finding reference. 22:11
Tene It started here: irclog.perlgeek.de/parrot/2008-12-30#i_793387
nopaste "pmichaud" at 72.181.176.220 pasted "problem code in pmcproxy.pmc" (10 lines) at nopaste.snit.ch/15136
Tene The instruction that triggered it was "new 'Hash'" 22:12
jonathan Tene: When there's a .HLL in force?
And when the .HLL is removed, it goes away?
pmichaud yes.
new 'Hash' is equivalent to new ['Hash'] 22:13
Tene Also when we don't store Perl6Hash in ['perl6';'Hash'], it goes away.
jonathan Ah.
pmichaud that part doesn't make much sense to me, fwiw. 22:14
jonathan So it's confusing the PMC with the Perl 6 one?
pmichaud it gets into an infinite loop.
or at least a nasty loop
at any rate, pmcproxy.pmc should not be looking up the proxy by name.
jonathan How should it be looking it up? 22:15
Tene pmichaud: I saw about 150k stack frames in gdb before I stopped holding down 'enter'
jonathan (Because if you have an answer it's an easy patch... ;-))
Tene so probably infinite
pmichaud I don't have an easy answer.
jonathan OK.
pmichaud because I don't completely understand how proxy pmcs are created/stored/managed
jonathan Question is where PMCs live.
Namespace wise.
pmichaud pmcs? or classes?
jonathan PMCs. 22:16
PMCProxy doesn't apply for non-PMC classes.
I mean, if I write a
pmichaud note that new 'Hash' and new ['Hash'] will no longer work when Rakudo moves to its own HLL
jonathan pmclass Foo { ... }
Is that going be looked up under parrot; Foo
Or will there be/is there a way to say "this PMC goes in this HLL?"
pmichaud isn't hll one of the options to pmclass ?
jonathan Maybe. 22:17
pmichaud i.e., to create a PMC in a different hll? I'm pretty sure Tcl must be doing something like that.
jonathan If so, that implies the default is parrot
Tene pmichaud: they will work, they'll just get a Perl6Hash instead of a pmc hash.
pmichaud Tene: no, because what is at 'Hash' in the root namespace isn't a class object.
purl okay, pmichaud.
pmichaud *hll root namespace 22:18
new "Hash" means "get the class associated with the ['Hash'] namespace in the current HLL"
Perl6Hash is in the ['Perl6Hash'] namespace. 22:19
(implies the default is parrot) that sounds very wrong to me.
depending on what you're intending it to mean.
dalek r34676 | chromatic++ | trunk/src/pmc (2 files): 22:20
: [PMC] Added "mro" as an inspectable attribute of PMCs (inherited from default
: PMC now; overriders may need to work on this). See RT #47976.
review: www.parrotvm.org/svn/parrot/revision?rev=34676
pmichaud the question I have for the pmcproxy code: Why/when do we need to look up pproxy if we already have pclass ? 22:22
dalek r34677 | chromatic++ | trunk (7 files): 22:23
: [ops] Removed deprecated get_mro opcode (RT #47976).
review: www.parrotvm.org/svn/parrot/revision?rev=34677
Coke chromatic++ 22:24
pmichaud i.e., why aren't we simply pushing pclass as a parent directly?
dalek r34678 | pmichaud++ | branches/rvar/languages/perl6/src/parser: 22:26
: [rakudo]: Restore @_ and %_ slurpy params.
review: www.parrotvm.org/svn/parrot/revision?rev=34678
22:28 TonyC joined
Tene pmichaud: whatever pclass is, it isn't the right thing. The errors we get when we do that are 'can't find method 'parents'' and such. 22:34
I haven't checked what it actually is, though.
22:34 davidfetter joined
pmichaud what kind of thing is it, then? 22:35
22:40 Theory joined
pmichaud excellent. rvar branch is down to 63 spectest files failing, most in the oo stuff (which I'd expect, since I haven't put those back in yet). 22:41
...and some of those failures are errors in the test files. :-) 22:45
Tene pmichaud: is pclass the class where we need the proxy instead? 22:50
pmichaud Tene: I don't know.
I don't understand the whole class/proxy relationship yet.
particle pmichaud: wrt new 'Foo' becoming new ['Foo'], what does new $P0 become? 22:51
pmichaud that's unchanged
particle great.
how do i convince bash not to hate me? 22:52
pmichaud and it's really already the case that new 'Foo' means the same as new ['Foo']
Cyndi just wanted to say "hi" Patrick. Tell Paula I said "hi" too.
pmichaud I didn't find that out until discussion with allison++ last night
particle ack '\\$P\\d+\\s+=\\s+new\\s+[\\'"]' t
GeJ particle: threaten it to use zsh instead.
particle gives me a >
pmichaud Hiya Cyndi! Happy New Year! Hope CRP is treating you and your family well!
particle: you've got an extra quote there 22:53
the \\ doesn't escape the '
Tene particle: \\ doesn't work in ''s
particle so how do i search for ['"] ?
Tene use " instead with more \\s
pmichaud maybe \\x37 ?
er, \\x27 22:54
'\\$P\\d+\\s+=\\s+new\\s+[\\x27"]'
particle pmichaud++
pmichaud but I would actually just search for '\\snew\\s+[\\x27"]' 22:55
and similar considerations hold for subclass and isa
particle something like: ack '=\\s+(new|subclass|isa)\\s+[\\x27"]' 22:57
anyway, i'm on my way now 22:58
Tene pmichaud: should I be passing NameSpace objects, classes, protoobjects, etc. as parsegrammar and parseactions to hllcompiler? 23:01
looks like you can't run 'new' on a namespace. 23:03
23:08 tetragon joined 23:15 cognominal joined
pmichaud strings to hllcompiler is okay 23:36
hllcompiler can parse the string into a namespace
i.e., what it's doing now should be okay.
oh. hllcompiler is going to get a hll option.
to tell it what hll to work in. 23:37
TiMBuS i know i asked this yesterday but i cant seem to get it. if you override the 'invoke' vtable method using a parrot class, you need to pass the class to itself to run it. like if your class in in $P0 you need to go $P0($P0) for it to work. 23:42
is there a workaround for this or do i just need to make a PMC instead
23:48 ruoso joined
particle TiMBuS: there is no workaround i know of 23:56
TiMBuS oh 23:57
:<
so i'd have to turn it into a pmc 23:58
particle at least, you'd have to write a pmc with the overridden invoke vtable function, but you could write the rest in pir 23:59
TiMBuS i could? :o

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!