Camelia, the Perl 6 bug

IRC log for #parrot, 2008-05-12

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:15 cjfields added the odd test failures (as well as the example script problem) to RT under perl6.
00:20 * DietCoke finally looks at the paper that allison posted on her blog. it's a .ps file. open it in preview on the mac. Converts to PDF... backwards. page 1 is the last page in the doc.
00:28 tetragon Caught the Intel failure in gdb
00:28 tetragon While using a debugging malloc library
00:29 wknight8111 joined #parrot
00:30 wknight8111 left #parrot
00:32 nopaste "tetragon" at 216.126.67.44 pasted "Yay, gdb" (62 lines) at http://nopaste.snit.ch/12943
00:34 tetragon (and "p obj" gives me "$1 = (Parrot_Object * const) 0x1f8f1000")
00:55 cjfields looks like r27448 (changes to languages/perl6/src/parser/grammar-oper.pg) is the source of the test script seg fault
01:01 cjfields stepped up revisions and reran tests until it failed
01:02 * cjfields calling it a night
01:02 cjfields bye!
01:17 Andy joined #parrot
01:42 teknomunk joined #parrot
02:02 Andy joined #parrot
03:27 particle joined #parrot
03:53 slightlyoff joined #parrot
04:01 teknomunk joined #parrot
04:36 Robrt joined #parrot
04:36 Robrt left #parrot
04:37 particl1 joined #parrot
04:50 Zaba_ joined #parrot
04:54 Patterner joined #parrot
04:56 Tene DietCoke: you need to open your case and flip the endian switch on the cpu.
05:50 AndyA joined #parrot
06:34 particle joined #parrot
07:17 Zaba joined #parrot
08:00 Zaba_ joined #parrot
08:05 masak joined #parrot
08:45 andy753421 joined #parrot
08:45 andy753421 Does anyone know how to pass arguments when invoking a subroutine with 'invokecc P\d'?
09:22 Ademan joined #parrot
09:50 barney joined #parrot
10:03 IllvilJa joined #parrot
10:33 barney joined #parrot
10:33 rdice joined #parrot
11:13 ptman joined #parrot
11:14 ptman 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?
11:17 barney I started reading, but I'm out of tuits today
11:28 iblechbot joined #parrot
11:46 masak joined #parrot
11:50 Zaba joined #parrot
11:55 Patterner rant url?
11:56 ptman http://steve-yegge.blogspot.com/2008/​05/dynamic-languages-strike-back.html
11:56 shorten ptman's url is at http://xrl.us/bkfpp
11:56 Patterner ptman++
12:29 Zaba joined #parrot
13:03 gryphon joined #parrot
13:04 kj joined #parrot
13:09 UltraDM joined #parrot
13:34 DietCoke ptman++ # thanks for the link.
13:35 ptman np =D
13:42 rdice joined #parrot
13:46 Andy joined #parrot
13:48 jhorwitz joined #parrot
14:24 ruoso_ joined #parrot
14:37 barney joined #parrot
14:46 sjansen joined #parrot
14:50 Tene ~lart sjansen
14:50 DietCoke I'll lart you, buddy.
14:50 Tene Wow, mischan.  That was cool.
14:50 * DietCoke ~~
14:55 sjansen ~haha Tene
15:05 davidfetter joined #parrot
15:15 particle ptman++ indeed
15:15 particle i had no idea ruby interprets ast directly
15:15 particle i wonder if we can make a faster ruby than ruby!
15:17 DietCoke can you make a faster partcl than partcl? :|
15:17 Topic for #parrotis now Devel: 0.6.1 | http://parrotcode.org/ | 696 new/open tix
15:18 particle heh
15:30 AndyA joined #parrot
15:33 Tene 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.
15:34 Tene I guess that's a motivation for me to work faster.
15:34 paco joined #parrot
15:35 particle FASTER!
15:35 Tene I'd love to know what approach I could take to make cardinal's grammar parse faster.
15:36 DietCoke the problem with partcl is that tclsh is pretty fast already; switching to parrot isn't going to be a win in that regard.
15:36 DietCoke 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. =-)
15:45 Tene DietCoke: don't the $IX registers use native ints, and so not handle numbers of sufficient size?
15:50 DietCoke ... so does integer keyed access.
15:50 DietCoke If you want integer-like pmc keyed access on bigints... you need to have a smarter pmc keyed access, I think.
15:51 DietCoke (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."
15:52 Tene DietCoke: Okay.
15:52 particle use MMD with PMCs
15:52 particle don't use native ints
15:53 Tene DietCoke: specifically, the problem was trying to access integer-indexed members of a past node with a variable in nqp.
15:54 Tene I think pmichaud++ was going to fix that to use $IX anyway.
15:55 pmichaud for the time being I'm planning to use $IX
15:55 pmichaud but the fact that code generators (pct) have to keep track of all of these register types and convert between them is a pain
15:55 pmichaud I think I'm going to formalize my request for a "box" opcode
15:56 DietCoke like autobox except manual?
15:56 pmichaud yes.
15:56 particle wait.
15:56 particle write yourself a function!
15:56 particle it's *tiny*
15:57 pmichaud except that (1) function call overhead is relatively high
15:57 particle let the calling conventions do the autoboxing for you
15:57 pmichaud (2) every HLL would have to have its own "box" function
15:57 pmichaud i.e., I don't think I can write a single function that works for all HLLs.
15:57 particle sub 'box' ; .param pmc foo ; .return foo; .end
15:57 pmichaud particle:  that sub will only work for whatever HLL it happens to be defined in.
16:00 particle so put it in pct
16:00 DietCoke putting into .... right.
16:00 pmichaud that doesn't help, unless you want pct to generate a 'box' function for every output
16:01 particle well, heck, an experimental opcode isn't that hard
16:01 pmichaud we *could* have PAST take options that says how to do each of the conversions.... but that feels like a violation of DRY
16:02 pmichaud otoh, perhaps PAST/PCT is going to be generating .HLL output anyway, so then it might make sense there.  Hrm.
16:02 davidfetter joined #parrot
16:02 particle well, you already tell the compiler what hll type handles the parrot core types
16:03 particle *types
16:03 pmichaud that statement is a little imprecise :-)
16:03 particle TclInt handles Integer
16:03 pmichaud right, I know that
16:04 pmichaud but how does one tell the compiler this?
16:04 particle .HLL
16:04 pmichaud and what generates .HLL ?
16:04 particle i wish it was more introspectable
16:04 particle does anything generate hll? i thought it was in your main compiler file.
16:04 pmichaud my point exactly.
16:04 particle i'm missing your point
16:05 pmichaud so if we want to have PCT generate standalone PIR....
16:05 pmichaud i.e.,  --target=pir
16:05 pmichaud then that pir output has to include the .HLL directives
16:05 pmichaud 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
16:05 pmichaud otherwise the PIR compiler will happily stick it in the 'parrot' hll namespace
16:06 pmichaud which means the PAST will have to be told the HLL mappings (in order to be able to generate them)
16:07 pmichaud which means it already knows everything it needs to convert I/S/N to P
16:07 particle ok, this is very far away from where this discussion started. obviously, i've been missing some context to the discussion of keyed access
16:07 pmichaud no, I took a couple of leaps
16:07 Theory joined #parrot
16:07 pmichaud that haven't been documented since yesterday
16:08 pmichaud PCT has an ongoing pain in converting register types
16:08 particle yes
16:08 particle that i'm aware of.
16:08 pmichaud the issue with keyed access is that not everything is necessarily a PMC
16:08 pmichaud for example, if someone writes   @array[4] := 3
16:08 pmichaud then PCT generates    set $PX[4], $PY
16:08 pmichaud and not
16:08 DietCoke pmichaud: I just dodged the whole issue of register types when doing tcl (way before pct): everything is a pmc.
16:09 pmichaud $PZ = new 'Integer'
16:09 pmichaud $PZ = 4
16:09 DietCoke so if you can allow us to keep track of that, I could imagine, say, [expr] would get much faster.
16:09 pmichaud set $PX[$PZ], $PY
16:09 DietCoke pmichaud++_
16:09 DietCoke pmichaud++ # underscore, what was that?
16:09 pmichaud i.e., PCT is smart enough to know that 4 is a valid constant as a key
16:10 pmichaud in that case, we really don't want to change it to be
16:10 pmichaud $I0 = 4
16:10 pmichaud set $PX[$I0], $PY
16:10 DietCoke pmichaud: I would argue that having the explicit $I0 there isn't a problem; that's what imcc optimization are for.
16:11 DietCoke (granted, if you can avoid them, great.)
16:11 pmichaud DietCoke: well, it goes beyond that
16:11 pmichaud for example, for string comparisons
16:11 pmichaud $S0 = $PX
16:11 pmichaud $S1 = $PY
16:11 pmichaud $I0 = iseq $S0, $S1
16:11 pmichaud $P0 = new 'Integer'
16:11 pmichaud $P0 = $I0
16:11 pmichaud is really stupid if we're just going to turn around and use $P0 in an 'if' statement
16:12 pmichaud because then we generate
16:12 lichtkind joined #parrot
16:12 pmichaud if $P0 goto ...
16:12 ruoso__ joined #parrot
16:12 pmichaud when it would be a lot better to simply avoid the boxing into an integer
16:12 pmichaud and write
16:12 pmichaud if $I0 goto ...
16:12 lichtkind pmichaud: hello hello
16:12 purl o/` Hello hello? Is there anybody in there? o/`
16:12 DietCoke into an "Integer", you mean? yup. I can see that.
16:13 pmichaud so, I've been working on ways of having PCT be able to do its own "smart" boxing
16:13 DietCoke that isn't one that imcc could be expected to optimize away.
16:13 pmichaud but the sticky point has been that it's awfully hard to know what to box into
16:14 pmichaud because that information is (or was) in the .HLL directives, which we can't easily get at from PIR
16:14 pmichaud but I've just convinced myself that information belongs in the PAST somewhere
16:14 pmichaud so that it can generate .HLL directives
16:14 particle i didn't realize that .HLL needs to be in every generated pir file.
16:15 pmichaud we'll have to have at least   .HLL 'perl6', ''
16:15 DietCoke particle: depends on how you do the includs.
16:15 particle i figured it'd be in the main compiler file, which isn't generated
16:15 pmichaud for dynamically compiled subs, it's not "include"
16:16 pmichaud consider:  when rakudo sees something like    sub foo { say "hello"; }
16:16 pmichaud we're already at "runtime" as far as the perl6.pbc compiler is concerned
16:16 pmichaud that gets turned into a PAST structure, when is then converted to PIR and then compiled using IMCC
16:16 pmichaud when .sub "foo" gets compiled by IMCC, we have to have something that tells IMCC to stick it in the "perl6" hll namespace
16:17 particle i bet we can optimize away the $P0 = $I0 ; if $P0 thing
16:17 Zaba_ joined #parrot
16:17 pmichaud i.e., the code that PCT generates has to include a .HLL directive
16:18 pmichaud 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
16:18 particle i didn't mean imcc
16:18 pmichaud oh.  I'm already doing that for PCT
16:18 particle i meant by using static single assignment and other past-level optimization strategies
16:19 pmichaud PCT already has to know about available register types -- it's not a significant increase to get it to understand boxing
16:19 pmichaud or, more precisely, coercions
16:20 pmichaud (er, "available register types for each instruction")
16:21 pmichaud 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.
16:21 pmichaud *point
16:21 particle too bad parrot's pasm opcode names don't contain enough info to precisely determine basic types for each instruction
16:21 particle ...that is, they don't tell you in, in/out, out info
16:22 pmichaud that's partially it, but it's also that some opcodes only work with specific register types
16:22 particle sorry, that's arity.
16:22 pmichaud i.e., there's no   $P0 = iseq $P1, $P2    opcode
16:22 particle yes, right. but there's a table of all opcodes
16:23 pmichaud we'd still have to do the coercions :-)
16:23 particle so i'm thinking if you can do lookup in that table, you'll know precisely what coersions you have available
16:23 pmichaud no, it would simply tell me the things I could coerce to
16:23 pmichaud I still have to generate the coercions and figure out the mapping
16:24 particle ok, so let's figure out the mapping
16:25 pmichaud right, that's what I'm working on
16:25 pmichaud the mapping part isn't too difficult, it's the boxing that was the blocker
16:26 particle and as soon as the hll type mapping is in the past, boxing is not a problem
16:26 pmichaud correct.
16:26 purl no, it's not!
16:26 pmichaud I just had been trying to avoid putting the hll type mapping into the past
16:26 pmichaud figuring it was already in the compiler code.  But I've convinced myself it's not.
16:27 pmichaud (or that simply having it in the compiler code may not be sufficient.)
16:27 particle can pct take the info from the compiler and stick it in the past?
16:27 pmichaud I wish.  I don't know that there's a way to introspect the HLL mapping
16:27 particle i mean, is it intro...
16:27 particle right.
16:27 particle if there isn't, we *need* that.
16:28 particle if there's a Compiler PMC that you're using
16:28 particle then it's likely just adding some code to the 'inspect' vtable function
16:28 pmichaud ...compiler PMC?
16:28 pmichaud seems like it ought to be a property of an hll namespace
16:29 particle er, yeah, right.
16:29 pmichaud where does it get stored now?
16:30 particle what actually gets the hll directive?
16:30 particle i'll have to look
16:30 pmichaud I don't know (both questions :-)
16:32 particle the answers are likely in src/hll.c
16:32 ptman left #parrot
16:32 NotFound joined #parrot
16:32 NotFound Hello.
16:34 DietCoke NotFound: hi
16:34 purl hey, DietCoke.
16:35 NotFound Someone can take a look at #45503?
16:37 nopaste "pmichaud" at 76.183.97.54 pasted "expected code generation with register coercion available" (48 lines) at http://nopaste.snit.ch/12944
16:38 pmichaud NotFound:  (#45503)   very interesting
16:39 NotFound I know ;)
16:39 pmichaud NotFound: that sounds eerily similar to a proposal I've had to allow PMCNULL to return false for opcodes
16:40 NotFound Don't know about that, I was only haunting the bug.
16:40 pmichaud what does the op for    if $PX, label    look like, I wonder?
16:43 NotFound op if(invar PMC, labelconst INT) {
16:43 NotFound if (VTABLE_get_bool(interp, $1))
16:43 NotFound goto OFFSET($2);
16:43 NotFound }
16:43 NotFound This one?
16:43 purl it has been said that This one is bugged too now
16:43 pmichaud right, no check for nullness there.
16:43 particle ouch.
16:43 pmichaud well, what we do get is "Null PMC"
16:43 pmichaud i.e., it does throw a normal exception
16:44 pmichaud because VTABLE_get_bool() throws an exception on PMCNULL
16:44 pmichaud my proposal was to let VTABLE_get_bool() return false for PMCNULL
16:44 pmichaud currently in PIR there are a few places where I have
16:45 pmichaud unless_null $P0, label
16:45 pmichaud if $P0, label
16:45 pmichaud er...
16:45 pmichaud no, I mean
16:45 pmichaud if_null $P0, falselabel
16:45 pmichaud unless $P0, falselabel
16:45 pmichaud because I have to explicitly check for PMCNULL before checking the value of the PMC
16:46 pmichaud anyway
16:46 NotFound Is not the same isuue, because in string case the opcode already return false, just fails when jitted.
16:47 pmichaud back to #45503....   approx how many places is the check for null done before the call to string_bool ?
16:47 pmichaud (not the same issue... right -- just sounds very familiar.)
16:48 NotFound Yes, and the principle of less surprise will recommend the same behaviour in both cases, i think.
16:48 jhorwitz_ joined #parrot
16:48 NotFound A fast check counts 14
16:49 NotFound Several of them with ugly casts around.
16:49 pmichaud I only found 2.
16:49 pmichaud ah, there's more
16:50 NotFound Several may be repetitions in generated code.
16:50 pmichaud one in string.pmc,  one in core.ops
16:50 pmichaud (the rest are generated)
16:50 pmichaud oops, two in core.ops
16:51 NotFound src/pmc/boolean.pmc
16:51 NotFound src/pmc/string.pmc
16:51 pmichaud the one in boolean.pmc doesn't do the check for null first
16:51 NotFound And those that does not have the check can be bugs.
16:52 pmichaud correct, they might.
16:53 pmichaud anyway, I like the proposal.
16:53 pmichaud so, +1 from me
16:53 DietCoke .
16:54 DietCoke would it also make sense to declare that it must not be null with directives and remove the checks in our code?
16:55 pmichaud what does   "null S1"  produce?
16:55 pmichaud more precisely, is this legal PIR...?
16:55 pmichaud null S1
16:55 pmichaud if S1, foo
16:56 NotFound DietCoke: yes, but in that case all jit generators will take that into account.
16:56 DietCoke pmichaud: a NULL string.
16:56 purl 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
16:56 DietCoke $1 = NULL in the opdef.
16:56 pmichaud a NULL string as in  "", or as in the null pointer?
16:56 DietCoke here's the opdef:
16:56 DietCoke inline op null(out STR) :base_core { $1 = NULL;
16:56 DietCoke }
16:57 pmichaud ah, the null pointer
16:57 DietCoke so, literal NULL
16:57 pmichaud that tells me that null is valid to the <if> opcode
16:58 NotFound s/will/must
16:58 DietCoke depends on which if.
16:58 pmichaud so "not null directives" would be incorrect, since that would cause the (C) compiler to carp when a null string is passed to <if>
16:58 DietCoke if (STR) vs. if (PMC)
16:59 DietCoke but I was talking about the internal call, not the opcode itself.
16:59 DietCoke we can't do that on opcodes yet, I don't think.
16:59 pmichaud that's kidna my point
16:59 pmichaud the internal call to <if>, or the internal call to string_bool ?
17:01 NotFound The opcodes for string actually cheks for NULL, both op unless(invar STR, labelconst INT) and op if (invar STR, labelconst INT)
17:03 pmichaud I'll argue it this way
17:03 pmichaud many of the other string_* functions in src/string.c check for null prior to performing the function
17:04 pmichaud for example, string_equal, string_set, string_concat, etc.
17:04 pmichaud it makes sense that string_bool should do so also, rather than having the opcode do it.
17:04 NotFound Interestingly, the jit core segfault with if, but works with unless.
17:05 pmichaud I'll reply with that to the ticket.
17:05 NotFound Ups, no, I was testing with my patched version, sorry :D
17:07 NotFound Fails the same way with if and unless.
17:08 pmichaud Added my comment to #45503.  Forgot to cc: the list, though, sorry.
17:09 NotFound I will work on the patch, then.
17:09 pmichaud 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.
17:10 DietCoke pmichaud: I do that all the time and end up duplicating the comment to get the cc.
17:10 pmichaud Thanks.
17:10 pmichaud DietCoke: I should do that here, then?
17:10 DietCoke up to you. just how I deal with my forgetfulness.
17:11 NotFound Is some headerization required?
17:11 pmichaud I don't know anything about headerization, sorry.
17:13 NotFound string_bool is declared in include/parrot/string_funcs.h, that does not have any comment of be generated.
17:52 NotFound Patch sended, all test pass here.
17:53 andy753421 left #parrot
17:57 NotFound Ups, forgot to add [PATCH] in the subject.
17:58 DietCoke np.
17:58 DietCoke ticket #?
17:58 NotFound #45503
17:59 DietCoke that magic only works on new tickets, I think.
17:59 NotFound But can help list readers.
18:00 DietCoke true. updated the ticket.
18:00 Andy <burp>
18:01 Andy Scuse me
18:01 Andy So, #ifdeffed function defs
18:07 contingencyplan joined #parrot
18:18 spinclad 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]>
18:22 NotFound Is'nt simpler to copy the P1 to an S.
18:22 NotFound ?
18:24 pmichaud 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
18:24 NotFound An integer, I mean.
18:24 pmichaud however, at the code generation level we don't always have that information available
18:25 pmichaud at any rate, PGE has been able to make the existing system work just fine since at least 2005.
18:25 NotFound The solution, then, is at key index level in the capture.
18:25 pmichaud so I'm not looking for any radical overhauls at this point.
18:25 pmichaud I feel like I should just close the ticket as it's causing far more discussion than it's worth (to me).
18:25 NotFound As we talked yesterday.
18:25 Tene +1
18:25 purl 1
18:26 spinclad re 'information not available', no longer know if it was .[] or .{}?
18:27 pmichaud correct.
18:27 purl no, it's not!
18:27 pmichaud 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
18:28 pmichaud and then the PAST compiler will make sure that the argument is explicitly cast to an 'int'
18:28 pmichaud we're going to have to re-think the entire thing anyway once we get to something like   @array[1,@b,3]
18:28 NotFound An alternative parrot: http://www.theiling.de/projects/parrot.html
18:29 spinclad or %hash{1} with a key of Int 1
18:29 pmichaud oh, that's not a problem
18:29 pmichaud since the aggregate is a hash (as opposed to a capture), both *_keyed and *_keyed_int do the same thing.
18:30 spinclad well, $capture{1} then
18:30 pmichaud at least the way that match objects are defined,   $match{1} and $match[1] are the same
18:30 pmichaud I don't know about catpures, but I suspect they may be the same.
18:31 pmichaud 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.
18:32 spinclad ah. weird, but sobeit. ok.
18:33 pmichaud I didn't write the spec, I just implement it.  :-)
18:33 spinclad re specify :scope('keyed_int'), sounds like a way to preserve the information and pass it along.  +1
18:33 spinclad right
18:35 pmichaud ENODALEK
18:36 DietCoke pmichaud++
18:37 spinclad pmichaud++  # metoo
18:40 Ivatar joined #parrot
18:48 davidfetter joined #parrot
18:53 Zaba joined #parrot
19:07 Tene Okay, this is a bit weird...
19:07 Tene [sweeks@kweh cardinal]$ c --target=parse f.rb
19:07 Tene "parse" => PMC 'cardinal::Grammar' => "def fact(n)\n  f = n\n  puts(f)\nend\n\nfact(1)\n" @ 0
19:07 Tene That's all I can get cardinal to emit with --target=parse, a single "parse" => ... => "the entire program text"
19:07 pmichaud might need to load_bytecode 'PGE/Dumper.pbc'
19:08 Tene It worked fine a couple of days ago, though.
19:08 pmichaud oh. hm.
19:08 pmichaud does it work for NQP or others?
19:08 pmichaud (--target=parse, that is)
19:08 Tene works for rakudo, at least
19:09 pmichaud is cardinal using PCT ?
19:09 pmichaud specifically, PCT::HLLCompiler ?
19:09 Tene PGE/Dumper isn't present anywhere in languages/cardinal...
19:09 pmichaud PGE/Dumper.pbc is in runtime/parrot/library
19:09 Tene Yes, uses HLLCompiler
19:10 Tene That is to say, "PGE/Dumper" isn't present anywhere in the text of any files in ...
19:10 pmichaud it's not in rakudo, either
19:10 pmichaud hrm
19:10 pmichaud okay, that's not it then
19:11 paco 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)
19:11 DietCoke paco: wrong window?
19:11 purl So I told him that DietCoke is a fucktard who can't be trusted... oh, hi DietCoke!
19:11 DietCoke purl, forget wrong window
19:11 purl DietCoke: I forgot wrong window
19:12 paco DietCoke: I need Storable to build parrot ..
19:12 pmichaud (parrot build relies on Stor.... right)
19:12 DietCoke which version of perl are you using?
19:12 Tene pmichaud: should I check before the pgeupdates merge?
19:12 paco DietCoke: svn from 3 days ago ..
19:12 DietCoke Storable was first released with perl 5.007003
19:13 DietCoke paco: not which version of parrot, perl.
19:13 paco amm
19:13 pmichaud Tene:  if you can do that easily, that'd be great
19:13 pmichaud but since it's working for rakudo (and I presume nqp and others), I don't know that the pgeupdates merge affects it much
19:14 paco I have Storable installed, but fails  compilig parrot .. so Im istalling (trying) the last Storable
19:14 Tene Oh, true.  Just looking for potentially relevant changes in the log.
19:14 paco DietCoke: This is perl, v5.8.2 built for aix-thread-multi
19:15 Tene Hm.  Yeah, it works before pgeupdates merge.
19:15 DietCoke paco: that should come with storable.
19:15 DietCoke why are you rebuilding it?
19:15 DietCoke oh.
19:16 DietCoke no one else is having the storable problem. You have a nopaste lying about of the original build failure?
19:16 DietCoke (and did you do the obligatory realclean ?)
19:16 paco DietCoke: the version of Storable that comes with the system fails to build parrot, and the solution is install a more recent Storable
19:16 DietCoke (just because I might be able to help with that, where I can't help with building anything on AIX these last 12 years. =-)
19:17 paco DietCoke: Ok, trying the build with broken Storable ..
19:18 DietCoke (realclean first?)
19:18 pmichaud Tene: I'm not sure what's happening in cardinal's case.
19:18 particle weak refs weren't added to perl until some 5.8.x
19:18 NotFound I have had several problemas with oudated perl modules, but always for testing, not for buliding.
19:18 Tene pmichaud: Okay, I'll investigate more.  Thanks.
19:18 particle i mean, what storable needs to use weak refs properly
19:18 particle let's check the storable docs...
19:20 paco DietCoke: http://rafb.net/p/xlUKF111.html
19:20 Tene Yes, it's definitely that commit that breaks it.
19:20 pmichaud Tene:  have you done a top-level make and/or realclean since then?
19:20 Ademan_ joined #parrot
19:20 Tene pmichaud: just about to do that.
19:20 pmichaud Tene: It sounds as though the PGE/Dumper.pbc didn't get rebuilt.
19:20 Tene Oh, could be.
19:21 pmichaud since it has the "@ 0" in the output line, that leads me to believe that it's calling the correct method.
19:21 paco DietCoke: this is with the old Storable ..
19:21 pmichaud 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.
19:21 Tene I'm surprised i didn't think of doing that.
19:22 particle paco: perl -MScalar::Util -MData::Dumper -e 'print Dumper(\%INC)'
19:22 Tene pmichaud: if that was the problem, why would it work for perl6 and not cardinal?
19:22 particle also, perl -MScalar::Util -e 'print $Scalar::Util::VERSION'
19:22 Tene pmichaud: no, full rebuild doesn't change anything.
19:22 pmichaud oh wait, duh.
19:23 pmichaud that can't be the problem because I'm seeing the same thing with cardinal on my sys.
19:23 Tene heh :)
19:23 pmichaud okay, let me close some other windows
19:23 pmichaud and focus on this for a bit.
19:23 Tene pmichaud: this isn't urgent.
19:23 pmichaud well, I'm on it now, and I'd like to make sure the pgeupdates merge didn't break anything.
19:23 * Tene nods.
19:24 particle paco: you probably need to upgrade your Scalar::Util package from cpan
19:24 paco particle: http://rafb.net/p/17uXG740.html
19:24 pmichaud since --target=past and --target=pir still seem to work, that implies that the parse tree is still being built correctly.
19:25 pmichaud ah, but I wonder if the parse is failing somewhere.
19:25 pmichaud (like, at the end of the source)
19:26 particle paco: we have the same version of scalar::util, but perhaps you can reinstall from cpan?
19:26 paco particle: Ok
19:30 Coke joined #parrot
19:31 pmichaud uh oh
19:31 pmichaud I see the problem
19:31 pmichaud Cardinal has a rule named 'hash' which is conflicting with the 'hash' on Match objects.
19:32 Tene Ahh.
19:32 pmichaud the long term fix will be to turn all of the rule methods into :multi's
19:32 pmichaud (in PGE)
19:32 NotFound You can rename to something related to cardinal, like 'pope', for example.
19:33 pmichaud either that or move the rule methods out of the Match objects, which will require a bit of PGE redesign
19:33 pmichaud if PGE redesign, I'm planning to wait to do that as part of implementing longest-token-matching in the summer
19:33 pmichaud ...so, would it hurt for the time being to call the rule something other than 'hash'?  ;-)
19:33 Tene Nope.
19:34 particle does ruby call it a hash, even?
19:34 particle associative array, dictionary, tuple... so many names
19:34 Tene Looks like it does.
19:34 pmichaud for the moment it would be best to avoid rulenames of 'hash', 'item', 'list', 'chars', and 'text'
19:35 pmichaud or maybe I just need to bite the bullet and make PGE compile its rules to MMD.  I wonder if that will slow things down any.
19:36 particle how many parameters is the dispatch keyed on? 1?
19:36 pmichaud two  (self + argument)
19:36 pmichaud it'll be  :multi(_,_) for the time being.
19:36 particle that's any,any
19:36 pmichaud right
19:37 particle which will be the default case
19:37 pmichaud the other methods would all be  :multi(_)
19:37 paco particle: forcing the install of scalar::util, now  t/weak..................ok , so I have a good Storable .. thanks ..
19:37 particle ah, ok. it shouldn't take much time at all
19:37 particle paco++ # good news
19:38 pmichaud I might go ahead and fix things to be :multi, but in the meantime I recommend avoiding 'hash', 'list', 'item', etc. as rule names.
19:40 particle pmichaud: is self not always the same type?
19:41 pmichaud same type as...?
19:41 Tene Okay, it looks like languages/lua implements return statements through a PAST::Op with a pasttype of 'return'.
19:41 pmichaud I think lua must implement its own special pasttype then
19:42 Tene Ahh, okay.
19:42 pmichaud as 'return' isn't implemented in PCT yet
19:42 Tene Right.
19:42 pmichaud it will be, though, which might cause a conflict.
19:42 Tene That was the confusion.  I couldn't find any evidence that was supported yet.
19:43 particle pmichaud: same type as each other
19:43 pmichaud PGE doesn't always know what grammar it's compiling the rule in
19:43 particle ah, ok.
19:46 * Coke tries to resurrect Albany.pm
19:46 particle pm: btw...
19:47 particle =item C<INTVAL Parrot_get_HLL_type>
19:47 particle Get an equivalent HLL type number for the language C<hll_id>.  If the given HLL
19:47 particle doesn't remap the given type, or if C<hll_id> is the special value
19:47 particle C<PARROT_HLL_NONE>, returns C<core_type> unchanged.
19:47 particle so, it's available in C
19:48 pmichaud still using type id, though.  :-)
19:48 pmichaud but yes, that's good to know.
19:48 Zaba_ joined #parrot
19:48 pmichaud now if we just had a method on hll namespaces to do a similar thing :-)
19:48 Coke need to delete that in my branch! =-)
19:48 pmichaud for a first cut I'm just going to hard-code conversion of I, S, N to Integer, String, and Float PMC types.
19:49 pmichaud and deal with .hll mapping a bit later.
19:49 particle ...and the info is stored in interp->HLL_info
19:49 particle so, looks like i can add something to the interpinfo op
19:50 pmichaud mmmmm, bonus!
19:50 pmichaud I likey.
19:52 particle something like $P1 = interpinfo .CURRENT_HLL look good to you?
19:53 pmichaud depends on what $P1 has in it :-)
19:54 particle basically:
19:54 particle @HLL_info = [
19:54 particle [ hll_name, hll_lib, { core_type => HLL_type, ... }, namespace, hll_id ],
19:54 particle ...
19:54 particle ]
19:54 pmichaud where core_type and HLL_type are type ids?
19:54 particle yes
19:54 particle for now
19:55 pmichaud only works if there's a way for me to convert type ids to class names
19:56 pmichaud (and possibly vice-versa)
19:56 Tene Oh, ew, cardinal generates a PAST::Op for its <args> rule, and then everything that uses args unshifts things into it.
19:56 particle yes, i'm looking up that registration now
19:57 Tene Hm.  I'm not sure if that's goint o be awkward in the future or not.
19:58 Coke be nice if we could do that conversion to FQ names now before exposing that interface.
19:58 Coke so anyone using this interpinfo gets back the class names instead of the ids, then we can rip out the conversion later when the guts are all non-ints.
19:58 particle sure, that's what i'd like too
19:59 particle let's see if it can be done!
19:59 pmichaud ideally:
20:00 pmichaud oh, wait
20:00 pmichaud .CURRENT_HLL doesn't help me
20:00 pmichaud I need to be able to look it up for any HLL
20:00 pmichaud (because PCT is always running in the 'parrot' HLL)
20:01 particle Parrot_get_HLL_id(PARROT_INTERP, ARGIN_NULLOK(STRING *hll_name))
20:01 particle pmichaud: yes, it'll be .INTERPINFO_HLL_INFO
20:01 particle once i noticed it'll return an array type pmc
20:01 pmichaud so, given $S0 = 'perl6'
20:01 pmichaud how do I get from there to knowing that 'Integer' ==> 'Int'  ?
20:02 particle well, that'll give you perl6 = 42
20:02 particle then you can get the entry from the array for perl6
20:02 particle next, i'm looking for the type id conversion functions
20:02 pmichaud okay
20:02 pmichaud I'll let you work it out -- I've given the use case above.  :-)
20:03 particle yes, thanks
20:03 pmichaud (or, instead of $S0 = 'perl6', it can also work if we have some sort of PMC or object that a compiler could pass to indicate the HLL)
20:04 pmichaud (for example,  the 'command_line' method of HLLCompiler could look up the HLL of its caller and use that.)
20:04 Coke msg chromatic http://chezkazrak.blogspot.com/2008/0​5/things-i-hate-about-you-1-perl.html :: I know this guy and was very sad to see his perl6 comments. Figured you might want to work your magic in the comments.
20:04 purl Message for chromatic stored.
20:04 shorten Coke's url is at http://xrl.us/bkgad
20:08 Psyche^ joined #parrot
20:09 particle pmichaud: looks like HLL_info stores both the integer id for the HLL *and* a String PMC with the name
20:09 pmichaud mmmmmm
20:09 pmichaud that works :-)
20:10 particle i'm still tracking down the type mappings, though
20:10 particle i just can't find where they're set yet
20:10 paco joined #parrot
20:10 pmichaud well, they're set by the .HLL_map directive, yes?
20:11 particle yes
20:11 particle vim -t Parrot_register_HLL_lib
20:11 pmichaud isn't Parrot_register_HLL_type the thing that does the type mapping?
20:12 particle yes, but by then, they're ints
20:12 particle INVALs
20:12 particle grr
20:12 pmichaud where does the HLL_info have the String PMC type?
20:13 particle line 172
20:13 pmichaud oh
20:13 cotto_work joined #parrot
20:14 pmichaud I was looking at something different.  This maps the HLL name to its type id
20:14 pmichaud got it.
20:14 particle i wonder, perhaps we could also store the mappings as String => String
20:14 particle put another entry in the hll_info struct
20:14 particle it can parallel the type id mapping entry, until that one disappears
20:15 pmichaud that would be fine with me
20:15 particle i think that's what i'll do. now, just need to figure where the strings become ints.
20:15 particle time to check imcparser.c
20:15 pmichaud alternatively, how to get the ints back into strings.
20:18 particle ok, well ,the conversion is done in the parser
20:18 particle type = pmc_type(interp, name)
20:18 pmichaud how does that work for bytecode, then?
20:18 pmichaud i.e., if perl6.pir creates a mapping, how does perl6.pbc know about it?
20:23 particle imcc parses the .HLL_map directive in perl6.pir
20:23 particle imcparser converts 'Perl6Int' to a type id via pmc_type
20:23 particle etc
20:23 particle then imcparser calls Parrot_register_HLL_type
20:23 particle that puts the info in the interp's HLL_info struct
20:25 pmichaud okay, I understand about imcc.  but that's not my point.
20:25 pmichaud when we run perl6, we do   parrot perl6.pbc hello.pl
20:25 pmichaud so imcc is never called.
20:25 particle isn't it, after the pir is generated?
20:26 particle oh, i see. you mean inside perl6.pbc
20:26 particle currently, HLL_map is called inside perl6.pir, yes?
20:26 particle so that info is in perl6.pbc
20:36 particle pmichaud: you're gonna love this, from src/pmc.c:
20:36 particle INTVAL
20:36 particle pmc_register(PARROT_INTERP, ARGIN(STRING *name))
20:36 particle {
20:36 particle PMC *classname_hash;
20:36 particle /* If they're looking to register an existing class, return that
20:36 particle class' type number */
20:36 particle INTVAL type = pmc_type(interp, name);
20:37 particle the only way to get the type id from the type name is by trying to register the pmc type
20:37 particle if it exists, it'll return the id
20:37 particle if not, it'll register a new one, and return the type id.
20:38 particle so, don't make a mistake in your .HLL_map directive!
20:38 pmichaud oh, that part makes sense to me.  Basically it makes sure every name gets registered only once.
20:39 pmichaud HLL_map is inside of perl6.pbc, yet.  But that means we can't rely on imcc to tell us what the names are.
20:39 particle it's too tightly coupled
20:40 ambs joined #parrot
20:40 pmichaud I'm confused... what's too tightly coupled?  type names and type ids?
20:44 particle no, registration and converting name -> id
20:44 pmichaud internally Parrot still keeps track of classes using id, I think
20:44 particle yes
20:44 pmichaud so, the first time a name is used, it's given an id
20:44 pmichaud and every subsequent time that name is encountered, the same id is returned
20:44 particle so how do i check if a type name is invalid?
20:45 pmichaud because the id won't correspond to a valid object/type
20:45 particle wrong.
20:45 particle there's no way to check, currently.
20:45 particle the only way to convert type name to type id, is by calling the register function
20:45 particle if the type exists, it returns the type id
20:46 particle if the type doesn't exist, it registers it and gives you a new id
20:46 pmichaud you're saying that get_class always calls the register function?
20:46 wknight8111 joined #parrot
20:46 ambs purl, seen dietcoke
20:46 purl dietcoke was last seen on #parrot 1 hour and 29 minutes ago, saying: (realclean first?)
20:46 ambs nice, still alive.
20:47 Coke yes?
20:47 DietCoke yes?
20:47 japhb joined #parrot
20:47 ambs DietCoke, nothin'important
20:49 particle pmichaud: get_class consults the namespace
20:49 particle actually, it takes a pmc, not a string.
20:49 pmichaud okay, you've totally lost me.  When you say "there's no way to check for a valid type", what sort of op are you imagining?
20:49 pmichaud If I want to check for a valid type, I use get_class
20:50 pmichaud and it returns NULL if the requested type doesn't exist.
20:51 pmichaud and since it doesn't use pmc_register....
20:51 pmichaud ...there's no problem.
20:51 particle ok, i can use get_class, then.
20:51 particle wait
20:51 particle i need the type id, not the class
20:52 pmichaud I'm really and thoroughly confused by what you're wanting to do
20:52 pmichaud we already have the type id in Parrot_register_HLL_type
20:52 pmichaud what we really want is the name
20:52 particle sorry, i need lunch
20:52 particle right,
20:52 particle given type id, return name
20:52 pmichaud so, how do we convert from a type id to a name?
20:52 particle does get_class work with type ids?
20:52 pmichaud no
20:53 particle here's what i'm saying:
20:53 particle the parser converts the names in .HLL_map to ids
20:54 particle everything after that wrt hll type maps uses the ids
20:54 particle i can't find a way to get the type name given the id
20:54 pmichaud I think there used to be an op to do it
20:54 particle the name of the type seems to me to be lost in the parser
20:54 pmichaud for example, one used to be able to do
20:55 pmichaud $P0 = new $I0
20:55 pmichaud $S0 = typeof $P0
20:55 pmichaud which of course has the nasty side effect of creating a throwaway object
20:55 pmichaud but the problem *isn't* in the parser
20:55 pmichaud i.e., the name still sticks around even after parsing is done, because otherwise the typeof opcode can't work
20:56 pmichaud and, given any class object, we can always use the .name() method to gets its name, yes?
20:56 PerlJam $S0 = typeof $I0  # works afaik
20:56 pmichaud PerlJam: deprecated, though.
20:57 pmichaud however, the internal function is likely available, yes.
20:57 PerlJam oh. bummer.
20:57 PerlJam why was that usage deprecated?
20:57 pmichaud we're eliminating type ids from the API
20:57 particle because we're getting rid of type ids
20:57 pmichaud *however*
20:57 pmichaud PerlJam++ for leading me to:
20:58 pmichaud $1 = Parrot_get_datatype_name(interp, $2);
20:58 pmichaud and even
20:58 pmichaud $1 = interp->vtables[$2]->whoami;
20:58 pmichaud (from src/ops/pmc.ops:184)
21:00 pmichaud and from src/datatypes.c:67 :
21:00 pmichaud STRING *
21:00 pmichaud Parrot_get_datatype_name(PARROT_INTERP, INTVAL type)
21:00 pmichaud but I suspect the interp->vtables[..] line is what we really want.
21:01 pmichaud at any rate,   $S0 = typeof $I0 still exists, yes, and that does what we want.
21:01 PerlJam so ... there used to be an op called "valid_type" that worked on type ids (at least).  I assume that usage is deprecated as well, but maybe it works on strings?
21:01 PerlJam $I1 = valid_type $S0
21:02 pmichaud well, for my need I'm not worried about whether or not I have a valid type.
21:02 pmichaud I can pretty much assume the types involved are valid.
21:10 NotFound Again on string bool, I noted now tha his perldoc item says: A string is true if it is equal to anything other than 0, "" or "0"
21:11 NotFound So it was already described as accepting a NULL.
21:13 PerlJam #parrot and #perl6 continually speak words that seem like english, but the meaning seems lost to me.  One day maybe I'll "get it"
21:13 pmichaud which words are those?  ;-)
21:14 PerlJam all of them!
21:15 spinclad perl6 is a mirror world
21:15 NotFound PerlJam: better join some japanese ruby forum X-)
21:18 PerlJam NotFound: I've actually been playing with ruby more lately because of rails.  I think I finally understand something about those people that dislike perl in favor of languages like python or ruby:  they're balking at the syntactic "weight" of all that punctuation.
21:18 PerlJam It's not the punctuation itself that's the problem.
21:18 PerlJam It's just that there is so much of it.
21:19 PerlJam It's almost like having to know all sorts of OOP concepts to write Hello World in Java vs. writing it in Perl
21:19 NotFound PerlJam: and here is a mix of perl, pir, C, and others, to much more fun.
21:21 NotFound And it this is not enough, you can join some group about esotheric languages.
21:21 PerlJam of course, perl6 adds even more punctuation to the mix, so no doubt the dividing line will be very clearly drawn there :)
21:22 NotFound By the way, I'm toying of the idea of writing an Intercal implementation in parrot, that does ABSTAIN ... by modifying his own bytecode.
21:24 NotFound That can be extreme introspection.
21:47 gryphon joined #parrot
22:02 vixey joined #parrot
22:04 vixey hi, where do you get a list of the possible target stages for the --target=[stage] flag of a binary made by pbc_to_exe?
22:04 pmichaud it's part of the parrot compiler toolkit
22:05 pmichaud the standard ones are
22:05 pmichaud parse, past, post, pir
22:05 vixey cool thanks a lot
22:05 pmichaud (that's not really part of pbc_to_exe, fwiw)
22:06 NotFound Mmmm... but the mission of pbc_to_exe is after all this pass, is'nt?
22:06 pmichaud all pbc_to_exe does is try to convert a .pbc file into a standalone executable.
22:07 pmichaud so that one can do  "./foo.exe"  instead of "./parrot.exe foo.pbc"
22:07 NotFound A little to late to target pir ;)
22:07 NotFound s/to/too
22:08 NotFound vixey: maybe you mean a created compiler?
22:08 vixey yes
22:09 NotFound Ah, in that case yes, the compilar can have all those targets.
22:11 pmichaud afk, dinner
22:20 Zaba joined #parrot
22:24 * bgeron_ wonders if pbc_to_exe creates .exe files in unix and falls asleep
22:39 rdice joined #parrot
22:52 Limbic_Region joined #parrot
22:56 tetragon joined #parrot
23:19 AndyA joined #parrot
23:50 teknomunk joined #parrot

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced