Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2009-01-06

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

All times shown according to UTC.

Time Nick Message
12:08 Whiteknight joined #parrotsketch
12:21 Whiteknight joined #parrotsketch
12:39 cotto joined #parrotsketch
12:41 Whiteknight joined #parrotsketch
12:50 damianc joined #parrotsketch
13:29 kid51 joined #parrotsketch
13:32 kid51 Pre-posting since I'll be at $job during meeting.
13:32 kid51 Infrastructural concerns:
13:33 kid51 1.  http://parrot.org has many dead links.  See:  https://trac.parrot.org/parrot/ticket/45.
13:33 kid51 2.  Trac system zaps contributor accounts when you set Preferences.  See:  http://rt.perl.org/rt3/Tic​ket/Display.html?id=61870.
13:33 kid51 EOR
15:49 davidfetter joined #parrotsketch
15:59 masak joined #parrotsketch
16:02 masak here's my report, since I won't be able to make it to the meeting today:
16:02 masak * finding and submitting rakudobugs, about 8 since last week
16:03 masak * writing documentation to be added to S29
16:03 masak * started implementing C<unpack> in Rakudo. passes a few tests -- still much work to do
16:03 masak .eor
17:15 davidfetter joined #parrotsketch
17:21 kj joined #parrotsketch
17:22 pmichaud joined #parrotsketch
17:40 contingencyplan joined #parrotsketch
17:53 mberends joined #parrotsketch
17:57 jhorwitz joined #parrotsketch
18:07 PacoLinux joined #parrotsketch
18:23 allison joined #parrotsketch
18:26 barney joined #parrotsketch
18:27 jonathan joined #parrotsketch
18:28 tewk joined #parrotsketch
18:29 Infinoid joined #parrotsketch
18:29 Infinoid *lurk*
18:30 kj hi there
18:30 Whiteknight hello
18:31 chromatic joined #parrotsketch
18:31 chromatic Good $localtime.
18:31 kj yo
18:31 pmichaud hello.
18:32 barney hi
18:32 jonathan hi
18:32 Infinoid hi.  (turns out I don't have a meeting after all, so I can report.)
18:32 chromatic allison?
18:32 allison - Finished integrating from the pdd30install branch, will delete the branch after Reini extracts the patches that need further work.
18:33 allison - Continued work on the calling conventions branch, should be able to merge that today or tomorrow.
18:33 allison - Reviewed and closed some tickets.
18:33 allison EOR
18:34 barney [Pipp]
18:34 barney - Worked on scoping of variables
18:34 barney - Worked on member access in methode
18:34 barney - fiddled with superglobals
18:34 barney [Parrot]
18:34 barney -Started reviewing LANGUAGES_STATUS.pod, before moving all of it into the Wiki.
18:34 barney .eor
18:34 chromatic I'm refactoring the garbage collector into a more coherent organization of functions and files in a branch.
18:34 chromatic It's mostly boilerplate work, but that should leave things clearer.
18:34 chromatic I hope to reach a good merging point today.
18:34 chromatic cotto?
18:35 chromatic Infinoid?
18:35 Infinoid I broke everything by adding headerizer-generated assert()s to NONNULL pointer arguments.
18:35 Infinoid Then I hopefully fixed everything again (at least for gcc, it's disabled for MSVC).  If you see a warning or error about ASSERT_ARGS(), let me know.
18:36 Infinoid This exposed several cases of mis-marked arguments.  See http://lists.parrot.org/pipermail/p​arrot-dev/2009-January/000840.html for the list.
18:36 Infinoid If you see an assert failure from this during parrot execution, that's another one that needs to be fixed up.  Let me know *loudly*.
18:36 Infinoid 1;
18:36 chromatic japhb?
18:37 Coke joined #parrotsketch
18:38 chromatic Coke?
18:38 Coke tcl is slow; might have ripped some things out of parrot.
18:38 Coke .
18:38 chromatic jhorwitz?
18:38 jhorwitz thanks to allison++'s merge of pdd22io_part3, i was able to create a ModParrotHandle PMC that ties Parrot I/O to Apache I/O.  with the new PMC i was able to resurrect mod_perl6 registry scripts, mod_pipp and mod_lolcode.
18:39 jhorwitz released mod_parrot 0.5
18:39 jhorwitz finalizing our accounting setup for the foundation, should be all set this week.
18:39 jhorwitz EOR
18:39 chromatic jonathan?
18:39 jonathan * Didn't do much at all over Christmas/New Year's break
18:39 jonathan * Since I came back, got bytecode annotations done (including IMCC, packfile level stuff and exceptions integration) and ready to merge
18:39 jonathan * Also sent a mail to the list for some input on further related things
18:39 jonathan * Now digging back into Rakudo again, to help with the rvar branch
18:39 jonathan * Overall it looks like a big clean-up and big improvement - pmichaud++. :-)
18:39 jonathan * However, a bunch of the type-related stuff needs to be restored and so forth. Not sure how bad it's going to be yet - some of it was hard enough to get right the first time. :-| But I'm blocked on doing much else until the branch goes in, so will try and help us get it ready to merge in ASAP.
18:39 jonathan * Overall, rvar branch is a good step and worth the pain, just frustrating to have to re-do stuff I got to work already.
18:39 jonathan * Once rvar merges, I'll dig back into all of the other things under my Hague Grant.
18:40 jonathan .end
18:40 chromatic kj?
18:40 kj == work on PIRC
18:40 kj * lots of bytecode emission progress
18:40 kj -- :immediate subs are run, which includes returning values and storing them in the constants table (implemented in Parrot, not IMCC/PIRC)
18:40 kj -- the PCC work mostly
18:40 kj -- only NCI calls need more work
18:40 kj * very happy with fast progress
18:40 kj EOR
18:40 chromatic particle?
18:40 particle i'm looking for work. it's windy here.
18:40 particle .end
18:41 chromatic PerlJam?
18:42 chromatic pmichaud?
18:42 pmichaud ** Rakudo spectests (r35013): 279 files, 6170 passing, 0 failing
18:42 pmichaud +268 passing tests since last #ps.
18:42 pmichaud Mostly been working on refactoring variable and parameter handling in Rakudo.
18:42 pmichaud So most of my changes are in the rvar branch, will merge to trunk this week.
18:42 pmichaud == Parrot stuff
18:42 pmichaud : Discussion about inspect_str on Class PMCs, updated in branch
18:42 pmichaud to be less clone-y.
18:42 pmichaud == PGE stuff
18:42 pmichaud : Now avoid creating duplicate classes instead of creating the class
18:42 pmichaud and catching exception.
18:42 pmichaud == PCT stuff
18:42 pmichaud : Added a way to attach extra flags and attributes to PAST::Nodes.
18:42 pmichaud : PAST::Block can now specify :subid
18:42 pmichaud : added "get_proto" method to obtain a protoobject.
18:42 pmichaud : "Scope not found for var" message now tries to indicate the block in which
18:42 pmichaud the error occurs.
18:42 pmichaud : Added 'null' and 'stmts' :pasttype to PAST::Op.
18:43 pmichaud : Added 'clone' method to PCT::Node
18:43 pmichaud == Rakudo stuff
18:43 pmichaud : Fixed slices (RT #61842)
18:43 pmichaud : Fixed some junction autothreading.
18:43 pmichaud : Lots of fixes in rvar branch.
18:43 pmichaud - parameters work
18:43 pmichaud - initialization of arrays and hashes now work
18:43 pmichaud - created bless/BUILD/BUILDALL/CREATE
18:43 pmichaud - clean up trait handling
18:43 pmichaud - much much more
18:43 pmichaud EOR
18:43 chromatic Tene?
18:44 chromatic tewk?
18:44 tewk * class registry round one got merged. you can now have HLL classes with the same name ascore classes.
18:44 tewk * class registry lookup has been fully deprecated in DEPRECATED.POD
18:44 tewk * do we have a way of saying which namespace dynpmcs get placed in?  we should if we don't
18:44 tewk * nsentry branch - removing :method and :vtable from namespace by default is bit rotting.rakudo needs fixes to work with it.
18:45 tewk * +1 for [ ''; 'ns1' ; 'ns2' ], ''  means relative to root namespace.
18:45 tewk * :multi() needs something ['' ]  to support something like :multi([''; 'rakudo'; 'Array'], [''; 'ruby' ; 'Array' ])
18:45 tewk * +1 for an official git mirror and gitois installation at parrot.org so committers cancooperatively experiement with distributed version controll
18:45 tewk * EOR
18:45 chromatic Whiteknight?
18:45 Whiteknight GC
18:45 Whiteknight - pulled out some unneeded configuration options
18:45 Whiteknight - fixed a segfault. Ran into another error with string handling that I haven't dug into
18:45 Whiteknight - pulled out some unnecessary code to improve encapsulation
18:45 Whiteknight BOOK
18:45 Whiteknight - Added stuff about annotations from jonathan++'s work
18:45 Whiteknight - expanded on string literals and included information about encodings/charsets
18:45 Whiteknight - Wrote sections about OO, classes, subclasses, attributes
18:45 Whiteknight - wrote about compilers, compreg, and HLLs
18:45 Whiteknight - Did some updating on the PVM Wikibook with suggestions from kid51++
18:45 Whiteknight JIT
18:45 Whiteknight - worked on moving executable JIT code out of header files in the jit_h_files branch
18:45 Whiteknight - hoping to wrap that up this week (thankfully)
18:45 Whiteknight EOR
18:46 chromatic Coke addendum, then anyone else?
18:46 Coke I have one report addendum; I added a test for examples to verify that all examples at least parse, even if we can't test them per se.
18:47 Coke t/examples/catchall.t ; there are still some failures. have fun. =-)
18:47 Coke ..
18:47 chromatic Questions?
18:48 kj yes 1.
18:48 Infinoid q1q
18:48 particle q1q
18:48 particle q1c
18:48 chromatic kj?
18:48 kj does anybody have knowledge about bytecode representation of keys? I think I'm *very* close, but I don't understand where I go wrong
18:49 kj if not, I can understand that :-)
18:49 jonathan kj: Are they not just PMC constants, so far as the bytecode stream itself knows?
18:50 kj yes, that's correct.
18:50 chromatic That's my impression too.
18:50 kj and actually, I tweaked IMCC to output every integer
18:50 kj and except for index values in the constant table
18:50 kj (as they're created in different order)
18:51 kj it's exactly the same as what PIRC's generating
18:51 kj but still, doesn't work
18:51 kj well, I guess it's just a matter of more playing and experimenting before I find the error
18:52 kj A more robust disassembler would help.
18:52 jonathan kj: Are you using the functions in packfile.c to actually produce the bytecdoe itself?
18:52 jonathan ERm
18:52 jonathan I mean, the packfile overall?
18:53 kj jonathan: it's a 2-step thing. First bytecodes into a private buffer, then Packfile takes that and generates a Key thingy, which is added to the const talbe, and that returns the index, which is thenwritten to the bytecode as an operand
18:54 kj I guess we can take this to #parrot, just wanted to check whether people happen to know details.
18:54 chromatic Infinoid?
18:54 Infinoid Do we have someone working on the latest round of trac account-permission issues?  Is there an official parrot-trac admin?  (ulterier motive: I'm wondering if I can bribe someone to look at http://trac-hacks.org/wiki/GitPlugin when we switch from svn.perl.org.)
18:55 particle enter a trac ticket for that
18:55 allison we have several trac admins, and are open to trac admin volunteers
18:55 particle we don't have a special queue for parrot.org requests
18:56 Infinoid I'd volunteer, but I don't think I speak the language it's written in.
18:56 particle it may be worth setting one up
18:56 allison I do have a ticket submitted to our hosting providers about the permissions issues, but the holidays meant little availability for a response
18:57 Infinoid ok, thanks.  EOQ
18:57 chromatic particle?
18:57 particle is everyone reviewing and updating https://trac.parrot.org/parrot/wiki/ParrotRoadmap ?
18:57 particle just make sure you are.
18:58 particle now, my comment:
18:58 particle it looks like great progress has been made in several independent branches,
18:58 particle and many are ready or almost ready for trunk merge,
18:58 pmichaud oh!
18:59 particle but please do coordinate the merges to make sure we continue to pass tests successfully on core platforms
18:59 pmichaud Since Tene++ isn't here, I'll pass along that we now have the :lang option working to Rakudo's eval
18:59 pmichaud i.e.,   eval('2+3', :lang(APL))   now works.
18:59 Infinoid ok.  I'm planning to get jonathan's bcanno branch merged into trunk tonight.
18:59 pmichaud this closes the milestone item of having PCT honor hll's
19:01 particle Infinoid: is there a reason it needs to wait?
19:02 tewk any comments about [''; 'adf' ; 'adfa' ] meaning root relative ?
19:02 Whiteknight isn't the root namespace called "parrot"?
19:02 chromatic I wish I had something better to '' to suggest.
19:03 Infinoid particle: just because I'm at $work currently
19:03 particle no, parrot is a namespace under the root
19:03 barney Can then 'get_hll_global' and 'get_root_global' be unified?
19:03 * Whiteknight is stupid at namespaces
19:03 particle if we accepted non-strings, [ROOT;'foo'] would work
19:03 particle or [/;'foo']
19:03 allison how about ['root'; 'whatever'; 'whatever']
19:03 particle languages/root can screw that up
19:04 allison it means we reserve the word 'root', but I'm okay with that
19:04 chromatic Enoch'll be upset.
19:04 particle or, we use uc, since all language namespaces are lc
19:05 allison chromatic: this is me not being concerned about the feelings of fictional characters
19:05 particle in effect, we've already reserved all uc names
19:05 allison ok, ['ROOT'; 'foo'; 'bar']
19:05 particle however, '' is not a valid language name, and is quite short
19:05 chromatic I could live with '', but it feels sort of magical girl show.
19:05 particle 'ROOT' is somewhat uglier
19:06 allison particle: yes, but it has the disadvantage of being magic that doesn't tell you what it's doing
19:06 tewk particle: why are all uc reserved?
19:06 allison 'ROOT' is ugly, but it's screamingly obvious what it's doing
19:06 barney how about ['/'; 'foo'; 'bar']
19:06 particle how about '/'
19:06 allison barney: too unix-centric
19:07 particle tewk: because language namespaces are always lc
19:07 pmichaud the problem I have with 'ROOT' or 'root' is that it seems very likely that someone could have a 'root' namespace in their HLL.
19:07 pmichaud e.g., in Perl 6:     package root;
19:07 particle ah, of course.
19:08 particle so it's '' or a non-string then, as i see it
19:08 allison so, we're proposing syntax that will always unambiguously refer to the unrelative root namespace in contexts that allow relative root namespaces?
19:08 barney There are probably languages that support a namespace ''
19:08 particle [/;'foo']
19:08 pmichaud if I may back up a bit
19:08 Whiteknight [0 ; "whatever"] would work, and wouldn't bork key syntax too badly
19:08 allison we've been down this path before, and decided not to allow it at all
19:08 particle [\0;'foo]
19:08 pmichaud allison: yes, but :multi(...) means we really need a way to do that
19:08 tewk allison :multi() is the problem.
19:08 pmichaud either that or we have to implement :multi_root(...)
19:09 pmichaud if we can find a way to resolve it in the key syntax, that simplifies a lot of things in newclass, subclass, isa, etc.
19:09 pmichaud instead of having all of these workarounds.
19:09 chromatic Agreed.
19:09 allison i.e. you want to multidispatch on another language's types
19:10 pmichaud the most obvious case being   ['parrot';'Class']
19:10 tewk allison: or core PMCs
19:10 allison we could just say that all namespace keys everywhere are relative to the root
19:10 allison that's what Perl does
19:10 pmichaud that's what Perl *5* does :-)
19:10 particle perl doesn't deal with other languages well
19:10 chromatic You still need a way to refer to Parrot PMCs.
19:11 allison it would mean generating the language name in the key everywhere, but would clean up a lot of our namespace problems
19:11 allison chromatic: yeah, that would always be ['parrot'; 'Foo']
19:11 Whiteknight Why do we need to put anything there? [ ; "whatever"]
19:11 pmichaud allison:  you and I just had a discussion where you disliked the ['foo'] versus 'foo' because of typing the brackets.  Now you propose to make it ['parrot';'foo']   instead?   1/2 :-)
19:11 Whiteknight just use a null key
19:11 chromatic Null key is still magical girl show.
19:11 allison pmichaud: just exploring the possibilities :)
19:11 tewk parrot pmcs will lookup via [ 'parrot' 'RPA' ]
19:12 pmichaud I'm somewhat against the idea of full namespace everywhere.
19:12 pmichaud the common case should be the easy one.
19:12 allison pmichaud: the fact that we keep coming up with hackish additions says that we still haven't got the base semantics right yet
19:12 particle i don't like full ns 4evar
19:12 allison this is definitely a hackish addition
19:12 pmichaud I did propose that string could be different from key
19:13 particle ['lang';;'ns';'ns';'ns']
19:13 pmichaud i.e.,   'Integer'   could be different from ['Integer']
19:13 barney With internals in ['_hll'] there is a lot of access in ['hll'] . So this should be easy.
19:13 particle ['lang':'ns']
19:13 allison debating on whether the fictional character at the front is an empty string, a null character or something ugly like 'ROOT' is just painting the bikeshed on something that's fundamentally unpleasant
19:13 particle if 'lang' not specified, current hll is assumed
19:14 allison particle: but that requires checking if lang is a valid name, and lang may not be a valid name at first (since languages can be created dynamically)
19:14 pmichaud allison:  he chose a ':' instead of ';'
19:14 particle it's a string, there's no checking until it's used
19:14 pmichaud i.e., using a : to indicate name.
19:14 Whiteknight maybe we need a more general, hash-based key system: [hll => "lang" ; ns => "whatever" ; "whatever2"]
19:14 allison pmichaud: which involves fundamentally changing how keys work
19:14 pmichaud particle:  ['lang';...]  isn't a string, it's a key.
19:15 pmichaud allison: yes, I agree -- I'm not a fan of changing the Key syntax.
19:15 pmichaud allison: I was just pointing out how particle's proposal was differentiating languages.
19:15 allison yes, good point
19:15 particle the current syntax sucks, but it's better than the alternatives?
19:16 pmichaud fwiw, I don't have a problem with any of the magical girl show alternatives.
19:16 barney how about ['..', 'foo', 'bar'] ?
19:16 tewk another option is add syntax, :multi_root and say keyed namespaces are always hll relative.
19:16 particle [':lang';...]
19:16 barney s/,/;/g
19:16 allison particle: mainly, if we change the syntax for keys, it needs to be in a way that makes sense for keys, not because we want to hack in a feature for namespaces
19:16 pmichaud for that matter, I don't mind if we do   [ '*root*'; 'parrot'; 'Foo' ]
19:16 chromatic That one doesn't bother me for some reason.
19:17 pmichaud I just don't want that leading key to be a standard identifier.
19:17 allison pmichaud: or various other ways of marking it off as "not a standard identifier"
19:17 pmichaud I mean I don't want that first component to match ^\w+$
19:17 particle pmichaud: agreed
19:17 Whiteknight ['\n' ; 'parrot' ; 'Foo' ]
19:18 pmichaud 'root'  fails because it matches ^\w+$
19:18 allison I'm still not convinced that providing a way of specifying an absolute path within a context that expects a relative path is a good idea
19:18 chromatic That's an unfair characterization though.
19:18 pmichaud we're not really saying "relative path" here.
19:18 particle :multi doesn't expect anything
19:18 chromatic We don't *know* what kind of path we specify anywhere.
19:18 tewk :multi_root()++
19:19 tewk chromatic: that is changinge see DEPRECATED.
19:19 allison if :multi is the place that needs it, then maybe we should extend the multi syntax to accept a :modifier on the key argument
19:19 pmichaud allison: we need it for :multi, newclass, subclass, isa, and does.
19:19 particle it's not just... right.
19:19 tewk allison: more work, but probably the right decision.
19:19 allison like :mulit(['Foo', 'Bar']:root)
19:20 particle how about we derive a new pmc from Key for this? are you with me? !!! :/
19:20 pmichaud does that mean I could do:    $P0 = get_class ['Foo', 'Bar']:root      ?
19:20 chromatic That's not just ugly.  That's C++ template ugly.
19:20 tewk pmichaud: no we don't, newlcass has a PMC varient, just use get_root_global and then call newclass.
19:20 allison :mulit(['Foo', 'Bar']:hll_root('python'))
19:21 pmichaud tewk: but why require two different ways of saying the same thing?  Just to avoid having a special first component in the key?
19:21 allison tewk: right, the problem is already solved in other cases, because you have a way of getting a namespace PMC for any namespace that exists
19:21 Coke isn't :hll_root implied by .HLL ?
19:21 pmichaud but even "getting the namespace PMC" is really a workaround.
19:21 chromatic Coke, we're talking about referring to symbols in other HLL namespaces.
19:21 allison Coke: I meant for accessing a different hll
19:21 particle :hll_root('...') is still an annotation on the key, isn't it?
19:21 pmichaud oh!  How about:
19:21 pmichaud particle: no, it's an adverb to :multi, as allison is proposing it.
19:22 allison pmichaud: no, it's not, the namespace object is *the* canonical way of referring to a namespace, just like a class object is *the* canonical way of referring to a class
19:22 particle so it affects *all* the keys in the sig, not just one?
19:22 allison pmichaud: all the various syntax for shortcutting to a namespace is just syntactic sugar
19:22 allison pmichaud: and we want as little of it as possible
19:22 pmichaud how about:    [ ':parrot'; 'Foo' ]   (using leading colon instead of leading *)
19:23 chromatic I can live with that too.  Non ^^ \w+ $$++
19:23 allison :multi is tricky because we don't have runtime access to the namespace object when the multi is being declared
19:23 particle works until a language starts using a : sigil
19:23 allison anything we put there can potentially conflict with a given language
19:24 tewk I don't like telling a hll that certain characters are reserved, sigils
19:24 pmichaud we want as little of "what" as possible?
19:24 particle unless it's not a string at all
19:24 pmichaud syntactic sugar?
19:24 allison tewk: yup
19:24 particle [ ROOT ; 'foo' ; 'bar' ]
19:25 pmichaud [ ROOT ; 'foo' ; 'bar' ] would work for me if imcc can change the ROOT part into something other than a standard string.
19:25 allison pmichaud: aye, so in the most common cases hand-written PIR code doesn't have to use a separate step for looking up the namespace object
19:25 chromatic Remember that when debugging PIR or inspecting PBC, we have to finish the round trip for this syntax.
19:25 allison particle: that's a hack to key syntax again
19:25 particle ok, so annotate the key to say it's absolute pathing rather than relative
19:25 pmichaud it's not so bad if [ ROOT ; 'foo'; 'bar']   becomes [ 0 ; 'foo' ; 'bar']   internally.
19:26 particle \0
19:26 pmichaud no, 0
19:26 Whiteknight I vote 0
19:26 pmichaud integer keys are distinguished from string ones.
19:26 allison particle: except that keys can't currently be annotated, because they're constants
19:26 kj ROOT would become the first magical keyword... IMHO, that's ugly
19:26 pmichaud bah, we have lots of magical keywords
19:26 pmichaud 'self' is one.
19:26 particle allison: right, so we *need* a hack of some sort
19:26 pmichaud we already have magical keywords -- this is by no means the first.
19:27 allison particle: we *need* to fix :multi, that doesn't mean we need a hack
19:27 particle use .ROOT, it's a macro, then
19:27 pmichaud I think that we should make the key syntax smart enough to distinguish root-relative versus hll-relative namespaces.
19:27 pmichaud then it works for :multi, newclass, subclass, isa, and everything.
19:28 pmichaud anything else to me feels like we're increasing hack level instead of decreasing it.
19:28 Coke I'd love to see a writeup of this to list, as I've no clue what problem we're trying to solve anymore.
19:28 allison I think we're running in circles. Any volunteers to summarize this discussion and take it to the list?
19:28 Coke ha!
19:28 allison heh :)
19:28 pmichaud I'll summarize, but it'll be a very biased summary.
19:28 Whiteknight we have too much necessary magic and too little syntax to describe it all. Short of making all namespaces root-relative we're going to have to modify something
19:28 allison pmichaud: that's okay
19:29 Tene q1q
19:29 allison pmichaud: even just a clear summary of your perspective would be a good starting point
19:29 Coke pmichaud: if you take the time to write it up, you get to be biased. =-)
19:29 Infinoid or you can say: if you want root-relative namespaces, start with a get_root_namespace op or somesuch, and then do lookups on that
19:29 pmichaud Infinoid: but we can't do that for :multi
19:29 particle Infinoid: need to use key *constants*
19:29 pmichaud Infinoid: beyond that, it means we're generating extra instructions
19:30 chromatic ... which have to execute at :load or :init time.
19:30 allison Infinoid: right, that's the usual solution, but as pmichaud says, :multi can't do that
19:30 pmichaud Infinoid: beyond that, we can't always look up a namespace that doesn't exist
19:30 pmichaud here's the case I came up with a day or so ago:    newclass ['parrot';'MyClass']
19:30 Infinoid right.  its obvious I don't know what I'm talking about. :)
19:30 pmichaud we can't just do    get_root_namespace ['parrot';'MyClass'], because it might not exist yet.
19:30 pmichaud So really the code becomes:
19:30 pmichaud $P0 = get_root_namespace
19:31 allison Infinoid: no, you're right
19:31 pmichaud actually, let's consider the example of
19:31 pmichaud newclass ['parrot';'Foo';'Bar'][
19:31 pmichaud to do this becomes:
19:31 pmichaud $P0 = get_root_namespace ['parrot']
19:32 Infinoid it just seems to me like different HLLs might want to do this in different ways.  so from that perspective, forcing them all to use the same nomenclature seems problematic
19:32 pmichaud $P1 = split '::', 'Foo::Bar'
19:32 pmichaud $P2 = $P0.'make_namespace'($P1)
19:32 pmichaud $P3 = newclass $P2
19:32 allison Infinoid: they will all do things differently in their language, we're just defining the syntax they'll translate to
19:32 pmichaud somehow    $P3 = newclass [ ROOT; 'parrot'; 'Foo'; 'Bar' ]    seems much more straightforward
19:33 pmichaud same thing goes for subclass, or anything else where the namespace might not exist yet.
19:33 Whiteknight having ROOT be an integer and not a string would make it obvious internally that it was an absolute and not a relative namespace
19:33 pmichaud and taking a single op and replacing it with 4 instructions just seems weird.
19:33 allison Infinoid: but you have a good point there, we should be trying to minimize the impact of Parrot's multiple HLL namespaces on compiler writers
19:33 chromatic Some of us crazy nuts write PIR by hand, too.
19:33 allison Infinoid: and it feels like we're hitting them over the head with it
19:34 allison chromatic: that too
19:34 tewk hll relative is the common case, huffman encode it.
19:34 pmichaud hll relative is already huffman encoded.  We're missing a root-relative case.
19:34 allison tewk: yes, that's why hll-relative is the default
19:34 particle yep
19:34 tewk but the rest should be possible
19:35 tewk right, just making that clear.
19:35 particle and currently *isn't* possible
19:35 allison yes, and the Huffman-coding principle is that the hard things should be possible, but they can also be ugly :)
19:35 particle because :multi uses the wrong default? i don't think so, since the common case is still hll-relative
19:35 pmichaud I don't understand what is "ugly" or wrong with  [ ROOT ; 'parrot' ; 'Foo' ]
19:36 particle i don't find it ugly
19:36 particle but i'm happy with .ROOT, too
19:36 jonathan It looks fine to me.
19:36 allison to the list
19:36 chromatic Let's wrap up.
19:36 chromatic Tene?
19:36 Tene I had an issue with load_bytecode on a .pbc whose .pir has .loadlib
19:36 Tene It wasn't loadlib-ing
19:37 Tene Who should I talk to about this?
19:37 Tene Or just post to the list?
19:37 allison Tene: the list or a ticket
19:37 particle post to list, write a test, etc
19:37 Tene 'k
19:42 allison any other questions?
19:43 allison Okay, let's call that a wrap. Great discussion, thanks everybody!
19:44 Infinoid thanks, guys
19:44 Infinoid left #parrotsketch
19:45 chromatic left #parrotsketch
19:45 pmichaud left #parrotsketch
19:48 jonathan left #parrotsketch
19:50 Coke left #parrotsketch
19:57 cotto left #parrotsketch
20:24 mberends left #parrotsketch
20:46 Whiteknight joined #parrotsketch
20:55 cotto joined #parrotsketch
21:17 PacoLinux left #parrotsketch
21:54 jhorwitz left #parrotsketch
21:56 kj left #parrotsketch
22:09 particle joined #parrotsketch

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