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

Powered by Cro and the Raku® Programming Language.

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

Thank you!