% jjore is now known as zz_jjore % zz_jjore is now known as jjore % Zaba has joined #parrot % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru % Zaba_ has joined #parrot % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % masak has joined #parrot % andy753421 has joined #parrot Does anyone know how to pass arguments when invoking a subroutine with 'invokecc P\d'? % Ademan has joined #parrot % IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk % barney has joined #parrot % masak has left masak!~user@nl119-196-100.student.uu.se % IllvilJa has joined #parrot % barney has left barney!~bernhard@p549A39B8.dip0.t-ipconnect.de % barney has joined #parrot % rdice has joined #parrot % ptman has joined #parrot Hi! Just wanted to check: Anybody read Steve Yegge's newest rant? All those optimizations he keeps talking about, they are possible in parrot, right? Without changing the interface to the compilers? And broader optimizations in the future? I started reading, but I'm out of tuits today % iblechbot has joined #parrot % masak has joined #parrot % Zaba has joined #parrot % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru rant url? http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html ptman's url is at http://xrl.us/bkfpp ptman++ % rdice has left rdice!~richarddi@CPE001ff33cb98b-CM00159a01d44c.cpe.net.cable.rogers.com % tetragon has left tetragon!~seneca@216.126.67.44 % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru % Zaba has joined #parrot % AndyA has left AndyA!~andy@c-68-33-170-161.hsd1.md.comcast.net % gryphon has joined #parrot % kj has joined #parrot % UltraDM has joined #parrot % barney has left barney!~bernhard@p549A39B8.dip0.t-ipconnect.de ptman++ # thanks for the link. np =D % rdice has joined #parrot % Andy has joined #parrot % jhorwitz has joined #parrot % ruoso_ has joined #parrot % ruoso has left ruoso!~ruoso@201009086089.user.veloxzone.com.br % barney has joined #parrot % sjansen has joined #parrot ~lart sjansen I'll lart you, buddy. Wow, mischan. That was cool. * DietCoke ~~ ~haha Tene % UltraDM has left UltraDM!~george@dasapass.avira.com % davidfetter has joined #parrot % barney has left barney!~bernhard@p549A097E.dip0.t-ipconnect.de % masak has left masak!~user@elector.medsci.uu.se ptman++ indeed i had no idea ruby interprets ast directly i wonder if we can make a faster ruby than ruby! % davidfetter has left davidfetter!~chatzilla@start.fetter.org can you make a faster partcl than partcl? :| % DietCoke has changed the topic of #parrot to: Devel: 0.6.1 | http://parrotcode.org/ | 696 new/open tix heh % AndyA has joined #parrot particle: I'd love for someone else to work on cardinal... although it might be nice if they wait until I've picked all the low-hanging fruit. I guess that's a motivation for me to work faster. % paco has joined #parrot FASTER! I'd love to know what approach I could take to make cardinal's grammar parse faster. the problem with partcl is that tclsh is pretty fast already; switching to parrot isn't going to be a win in that regard. I think I'm just going to have to knuckle down and work on speed imprvoments, since the magic compiler fairy hasn't shown up yet. =-) DietCoke: don't the $IX registers use native ints, and so not handle numbers of sufficient size? ... so does integer keyed access. If you want integer-like pmc keyed access on bigints... you need to have a smarter pmc keyed access, I think. (given the current system). I'm not trying to argue for a particular design, btw, just trying to say "this is how I think it works today." DietCoke: Okay. use MMD with PMCs don't use native ints DietCoke: specifically, the problem was trying to access integer-indexed members of a past node with a variable in nqp. I think pmichaud++ was going to fix that to use $IX anyway. for the time being I'm planning to use $IX but the fact that code generators (pct) have to keep track of all of these register types and convert between them is a pain I think I'm going to formalize my request for a "box" opcode % kj has left kj!~IceChat7@193.1.100.110 like autobox except manual? yes. wait. write yourself a function! it's *tiny* except that (1) function call overhead is relatively high let the calling conventions do the autoboxing for you (2) every HLL would have to have its own "box" function i.e., I don't think I can write a single function that works for all HLLs. sub 'box' ; .param pmc foo ; .return foo; .end particle: that sub will only work for whatever HLL it happens to be defined in. so put it in pct putting into .... right. that doesn't help, unless you want pct to generate a 'box' function for every output well, heck, an experimental opcode isn't that hard we *could* have PAST take options that says how to do each of the conversions.... but that feels like a violation of DRY otoh, perhaps PAST/PCT is going to be generating .HLL output anyway, so then it might make sense there. Hrm. % davidfetter has joined #parrot well, you already tell the compiler what hll type handles the parrot core types *types that statement is a little imprecise :-) TclInt handles Integer right, I know that but how does one tell the compiler this? .HLL and what generates .HLL ? i wish it was more introspectable does anything generate hll? i thought it was in your main compiler file. my point exactly. i'm missing your point so if we want to have PCT generate standalone PIR.... i.e., --target=pir then that pir output has to include the .HLL directives in fact, as soon as we start using .HLL we'll have to include the .HLL directives for all of the code that PCT generates otherwise the PIR compiler will happily stick it in the 'parrot' hll namespace which means the PAST will have to be told the HLL mappings (in order to be able to generate them) which means it already knows everything it needs to convert I/S/N to P ok, this is very far away from where this discussion started. obviously, i've been missing some context to the discussion of keyed access no, I took a couple of leaps % Theory has joined #parrot that haven't been documented since yesterday PCT has an ongoing pain in converting register types yes that i'm aware of. the issue with keyed access is that not everything is necessarily a PMC for example, if someone writes @array[4] := 3 then PCT generates set $PX[4], $PY and not pmichaud: I just dodged the whole issue of register types when doing tcl (way before pct): everything is a pmc. $PZ = new 'Integer' $PZ = 4 so if you can allow us to keep track of that, I could imagine, say, [expr] would get much faster. set $PX[$PZ], $PY pmichaud++_ pmichaud++ # underscore, what was that? i.e., PCT is smart enough to know that 4 is a valid constant as a key in that case, we really don't want to change it to be $I0 = 4 set $PX[$I0], $PY pmichaud: I would argue that having the explicit $I0 there isn't a problem; that's what imcc optimization are for. (granted, if you can avoid them, great.) DietCoke: well, it goes beyond that for example, for string comparisons $S0 = $PX $S1 = $PY $I0 = iseq $S0, $S1 $P0 = new 'Integer' $P0 = $I0 is really stupid if we're just going to turn around and use $P0 in an 'if' statement because then we generate % lichtkind has joined #parrot if $P0 goto ... % ruoso__ has joined #parrot when it would be a lot better to simply avoid the boxing into an integer and write if $I0 goto ... pmichaud: hello hello o/` Hello hello? Is there anybody in there? o/` into an "Integer", you mean? yup. I can see that. so, I've been working on ways of having PCT be able to do its own "smart" boxing that isn't one that imcc could be expected to optimize away. but the sticky point has been that it's awfully hard to know what to box into because that information is (or was) in the .HLL directives, which we can't easily get at from PIR but I've just convinced myself that information belongs in the PAST somewhere so that it can generate .HLL directives i didn't realize that .HLL needs to be in every generated pir file. we'll have to have at least .HLL 'perl6', '' particle: depends on how you do the includs. i figured it'd be in the main compiler file, which isn't generated % ruoso_ has left ruoso_!~ruoso@201009121164.user.veloxzone.com.br for dynamically compiled subs, it's not "include" consider: when rakudo sees something like sub foo { say "hello"; } we're already at "runtime" as far as the perl6.pbc compiler is concerned that gets turned into a PAST structure, when is then converted to PIR and then compiled using IMCC when .sub "foo" gets compiled by IMCC, we have to have something that tells IMCC to stick it in the "perl6" hll namespace i bet we can optimize away the $P0 = $I0 ; if $P0 thing % Zaba_ has joined #parrot i.e., the code that PCT generates has to include a .HLL directive I think it's easier/better for PCT to solve its generic register handling than to try to figure out how imcc can do it all i didn't mean imcc oh. I'm already doing that for PCT i meant by using static single assignment and other past-level optimization strategies PCT already has to know about available register types -- it's not a significant increase to get it to understand boxing or, more precisely, coercions (er, "available register types for each instruction") % Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru my poing being that once it does that, then figuring out how to coerce the key of set $PX[...], $PY into an integer is not an issue. *point too bad parrot's pasm opcode names don't contain enough info to precisely determine basic types for each instruction ...that is, they don't tell you in, in/out, out info that's partially it, but it's also that some opcodes only work with specific register types sorry, that's arity. i.e., there's no $P0 = iseq $P1, $P2 opcode yes, right. but there's a table of all opcodes we'd still have to do the coercions :-) so i'm thinking if you can do lookup in that table, you'll know precisely what coersions you have available no, it would simply tell me the things I could coerce to I still have to generate the coercions and figure out the mapping ok, so let's figure out the mapping right, that's what I'm working on the mapping part isn't too difficult, it's the boxing that was the blocker and as soon as the hll type mapping is in the past, boxing is not a problem correct. no, it's not! I just had been trying to avoid putting the hll type mapping into the past figuring it was already in the compiler code. But I've convinced myself it's not. (or that simply having it in the compiler code may not be sufficient.) can pct take the info from the compiler and stick it in the past? I wish. I don't know that there's a way to introspect the HLL mapping i mean, is it intro... right. if there isn't, we *need* that. if there's a Compiler PMC that you're using then it's likely just adding some code to the 'inspect' vtable function ...compiler PMC? seems like it ought to be a property of an hll namespace er, yeah, right. where does it get stored now? what actually gets the hll directive? i'll have to look I don't know (both questions :-) the answers are likely in src/hll.c % ptman has left #parrot % NotFound has joined #parrot Hello. NotFound: hi hey, DietCoke. Someone can take a look at #45503? "pmichaud" at 76.183.97.54 pasted "expected code generation with register coercion available" (48 lines) at http://nopaste.snit.ch/12944 NotFound: (#45503) very interesting I know ;) NotFound: that sounds eerily similar to a proposal I've had to allow PMCNULL to return false for opcodes Don't know about that, I was only haunting the bug. what does the op for if $PX, label look like, I wonder? op if(invar PMC, labelconst INT) { if (VTABLE_get_bool(interp, $1)) goto OFFSET($2); } This one? it has been said that This one is bugged too now right, no check for nullness there. ouch. well, what we do get is "Null PMC" i.e., it does throw a normal exception because VTABLE_get_bool() throws an exception on PMCNULL my proposal was to let VTABLE_get_bool() return false for PMCNULL currently in PIR there are a few places where I have unless_null $P0, label if $P0, label er... no, I mean if_null $P0, falselabel unless $P0, falselabel because I have to explicitly check for PMCNULL before checking the value of the PMC anyway Is not the same isuue, because in string case the opcode already return false, just fails when jitted. back to #45503.... approx how many places is the check for null done before the call to string_bool ? (not the same issue... right -- just sounds very familiar.) Yes, and the principle of less surprise will recommend the same behaviour in both cases, i think. % jhorwitz_ has joined #parrot A fast check counts 14 Several of them with ugly casts around. I only found 2. ah, there's more Several may be repetitions in generated code. % jhorwitz has left jhorwitz!~chatzilla@96.245.16.45 % jhorwitz_ is now known as jhorwitz one in string.pmc, one in core.ops (the rest are generated) oops, two in core.ops src/pmc/boolean.pmc % davidfetter has left davidfetter!~chatzilla@start.fetter.org src/pmc/string.pmc the one in boolean.pmc doesn't do the check for null first And those that does not have the check can be bugs. correct, they might. anyway, I like the proposal. so, +1 from me . would it also make sense to declare that it must not be null with directives and remove the checks in our code? what does "null S1" produce? more precisely, is this legal PIR...? null S1 if S1, foo DietCoke: yes, but in that case all jit generators will take that into account. pmichaud: a NULL string. i think a null string is a hold over from C where a string is a char* and the addr that pointer references is 0 $1 = NULL in the opdef. a NULL string as in "", or as in the null pointer? here's the opdef: inline op null(out STR) :base_core { $1 = NULL; } ah, the null pointer so, literal NULL that tells me that null is valid to the opcode s/will/must depends on which if. so "not null directives" would be incorrect, since that would cause the (C) compiler to carp when a null string is passed to if (STR) vs. if (PMC) but I was talking about the internal call, not the opcode itself. we can't do that on opcodes yet, I don't think. that's kidna my point the internal call to , or the internal call to string_bool ? The opcodes for string actually cheks for NULL, both op unless(invar STR, labelconst INT) and op if (invar STR, labelconst INT) I'll argue it this way many of the other string_* functions in src/string.c check for null prior to performing the function for example, string_equal, string_set, string_concat, etc. it makes sense that string_bool should do so also, rather than having the opcode do it. Interestingly, the jit core segfault with if, but works with unless. I'll reply with that to the ticket. Ups, no, I was testing with my patched version, sorry :D Fails the same way with if and unless. Added my comment to #45503. Forgot to cc: the list, though, sorry. I will work on the patch, then. NotFound: I've gone ahead and taken ownership of #45503. If you can submit the patch, I'll apply it in a day or so after we give others an opportunity to comment. pmichaud: I do that all the time and end up duplicating the comment to get the cc. Thanks. DietCoke: I should do that here, then? up to you. just how I deal with my forgetfulness. Is some headerization required? I don't know anything about headerization, sorry. string_bool is declared in include/parrot/string_funcs.h, that does not have any comment of be generated. Patch sended, all test pass here. % andy753421 has left #parrot Ups, forgot to add [PATCH] in the subject. np. ticket #? #45503 that magic only works on new tickets, I think. But can help list readers. true. updated the ticket. Scuse me So, #ifdeffed function defs % contingencyplan has joined #parrot a thought re captures, and does $P0[$P1] mean array/index or hash/key: if it's hard or impossible (as istm it will be) to distinguish which is meant just from C<$P0[$P1]>, then perhaps one should preserve information by C<$P2 = $P0.array; $P2[$P1]> v. C<$P2 = $P0.hash; $P2[$P1]> ; perhaps inlined to C<$P2 = $P0[0 for array, 1 for hash]; $P2[$P1]> Is'nt simpler to copy the P1 to an S. ? whenever PCT or other tools need to explicitly grab from the list or hash component of a capture, they first call .'list' or .'hash' on it An integer, I mean. however, at the code generation level we don't always have that information available at any rate, PGE has been able to make the existing system work just fine since at least 2005. The solution, then, is at key index level in the capture. so I'm not looking for any radical overhauls at this point. I feel like I should just close the ticket as it's causing far more discussion than it's worth (to me). As we talked yesterday. +1 1 re 'information not available', no longer know if it was .[] or .{}? correct. no, it's not! so the solution is going to be that PAST nodes will specify :scope('keyed_int') if they really want to force it to the integer side and then the PAST compiler will make sure that the argument is explicitly cast to an 'int' we're going to have to re-think the entire thing anyway once we get to something like @array[1,@b,3] An alternative parrot: http://www.theiling.de/projects/parrot.html or %hash{1} with a key of Int 1 oh, that's not a problem since the aggregate is a hash (as opposed to a capture), both *_keyed and *_keyed_int do the same thing. well, $capture{1} then at least the way that match objects are defined, $match{1} and $match[1] are the same I don't know about catpures, but I suspect they may be the same. from S05: The numbered captures may be treated as named, so $<0 1 2> is equivalent to $/[0,1,2]. This allows you to write slices of intermixed named and numbered captures. ah. weird, but sobeit. ok. I didn't write the spec, I just implement it. :-) re specify :scope('keyed_int'), sounds like a way to preserve the information and pass it along. +1 right ENODALEK pmichaud++ pmichaud++ # metoo % Ivatar has joined #parrot % davidfetter has joined #parrot % Zaba has joined #parrot % Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru Okay, this is a bit weird... [sweeks@kweh cardinal]$ c --target=parse f.rb "parse" => PMC 'cardinal::Grammar' => "def fact(n)\n f = n\n puts(f)\nend\n\nfact(1)\n" @ 0 That's all I can get cardinal to emit with --target=parse, a single "parse" => ... => "the entire program text" might need to load_bytecode 'PGE/Dumper.pbc' It worked fine a couple of days ago, though. oh. hm. does it work for NQP or others? (--target=parse, that is) works for rakudo, at least is cardinal using PCT ? specifically, PCT::HLLCompiler ? PGE/Dumper isn't present anywhere in languages/cardinal... PGE/Dumper.pbc is in runtime/parrot/library Yes, uses HLLCompiler That is to say, "PGE/Dumper" isn't present anywhere in the text of any files in ... it's not in rakudo, either hrm okay, that's not it then Hi, I have a little problem with Storable, Now Im compiling 2.18 but I have a dubious test . (t/weak..................Weak references are not implemented in the version of perl at t/weak.t line 28) so I need some advice, force ? (the platform is aix 5.3 with native compiler) paco: wrong window? So I told him that DietCoke is a fucktard who can't be trusted... oh, hi DietCoke! purl, forget wrong window DietCoke: I forgot wrong window DietCoke: I need Storable to build parrot .. (parrot build relies on Stor.... right) which version of perl are you using? pmichaud: should I check before the pgeupdates merge? DietCoke: svn from 3 days ago .. Storable was first released with perl 5.007003 % iblechbot has left iblechbot!~iblechbot@110.18-dial.augustakom.net paco: not which version of parrot, perl. amm Tene: if you can do that easily, that'd be great but since it's working for rakudo (and I presume nqp and others), I don't know that the pgeupdates merge affects it much I have Storable installed, but fails compilig parrot .. so Im istalling (trying) the last Storable Oh, true. Just looking for potentially relevant changes in the log. DietCoke: This is perl, v5.8.2 built for aix-thread-multi Hm. Yeah, it works before pgeupdates merge. paco: that should come with storable. why are you rebuilding it? oh. no one else is having the storable problem. You have a nopaste lying about of the original build failure? (and did you do the obligatory realclean ?) DietCoke: the version of Storable that comes with the system fails to build parrot, and the solution is install a more recent Storable (just because I might be able to help with that, where I can't help with building anything on AIX these last 12 years. =-) DietCoke: Ok, trying the build with broken Storable .. (realclean first?) Tene: I'm not sure what's happening in cardinal's case. weak refs weren't added to perl until some 5.8.x I have had several problemas with oudated perl modules, but always for testing, not for buliding. pmichaud: Okay, I'll investigate more. Thanks. i mean, what storable needs to use weak refs properly let's check the storable docs... DietCoke: http://rafb.net/p/xlUKF111.html Yes, it's definitely that commit that breaks it. Tene: have you done a top-level make and/or realclean since then? % Ademan_ has joined #parrot pmichaud: just about to do that. Tene: It sounds as though the PGE/Dumper.pbc didn't get rebuilt. Oh, could be. since it has the "@ 0" in the output line, that leads me to believe that it's calling the correct method. DietCoke: this is with the old Storable .. But since it's not doing anything else, that leads me to believe that PGE/Dumper.pbc is still looking in the old places for subnodes. I'm surprised i didn't think of doing that. paco: perl -MScalar::Util -MData::Dumper -e 'print Dumper(\%INC)' pmichaud: if that was the problem, why would it work for perl6 and not cardinal? also, perl -MScalar::Util -e 'print $Scalar::Util::VERSION' pmichaud: no, full rebuild doesn't change anything. oh wait, duh. that can't be the problem because I'm seeing the same thing with cardinal on my sys. heh :) okay, let me close some other windows and focus on this for a bit. pmichaud: this isn't urgent. well, I'm on it now, and I'd like to make sure the pgeupdates merge didn't break anything. * Tene nods. paco: you probably need to upgrade your Scalar::Util package from cpan particle: http://rafb.net/p/17uXG740.html since --target=past and --target=pir still seem to work, that implies that the parse tree is still being built correctly. ah, but I wonder if the parse is failing somewhere. (like, at the end of the source) % Ademan has left Ademan!~dan@h-69-3-235-19.snfccasy.dynamic.covad.net paco: we have the same version of scalar::util, but perhaps you can reinstall from cpan? particle: Ok % DietCoke has left DietCoke!~coke@cpe-72-228-52-192.nycap.res.rr.com % Coke has joined #parrot uh oh I see the problem Cardinal has a rule named 'hash' which is conflicting with the 'hash' on Match objects. Ahh. the long term fix will be to turn all of the rule methods into :multi's