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