Camelia, the Perl 6 bug

IRC log for #parrot, 2008-07-11

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:08 dalek r29271 | jkeenan++ | parallel:
00:08 dalek : Extract most object methods from Parrot::Configure and place them in
00:08 dalek : Parrot::Configure::Base, whence they can be inherited by new class
00:08 dalek : Parrot::Configure::Parallel as well.  The latter has the same structure as the
00:08 dalek : Parrot::Configure object.
00:08 purl i guess : parrot::configure object is now a singleton.  So most tests have been put in a
00:08 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29271
00:09 AndyA joined #parrot
00:13 cotto_work joined #parrot
00:21 Whiteknight hah! i just got my first core dump!
00:27 cotto_work take a picture!
00:27 purl It'll last longer!
00:29 Limbic_Region joined #parrot
00:36 bacek joined #parrot
00:36 dalek r29272 | Whiteknight++ | gsoc_pdd09:
00:36 dalek : [gsoc_pdd09] A few changes:
00:36 dalek : * fix problem where sized pools are getting double-swept
00:36 dalek : * improve (maybe not fix) card setting function to avoid overlapping
00:36 dalek : * fix bounds-checking on cards in pool sweep code.
00:36 dalek : * Update comments and readme
00:36 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29272
00:37 Whiteknight slowly but surely, I'm getting this to work right
00:40 Limbic_Region Whiteknight: when does SoC end?
00:40 Whiteknight too soon
00:40 purl too soon is http://www.encyclopediadrama​tica.com/index.php/Too_soon
00:41 Whiteknight i dont know when exactly\
00:41 Whiteknight it doesn't matter, i plan to parrot for a long time
00:41 Limbic_Region well, that's good
00:41 particle aug17 iirc
00:41 Limbic_Region I was just wondering if there were required deliverables by a certain time frame
00:41 particle soccer &
00:57 Ademan joined #parrot
01:05 petdance joined #parrot
01:26 Ademan joined #parrot
01:42 TimToady there is no bool type in Perl 6, nor is there a true or false value.  The type name is Bool, and its enum is False,True
01:43 TimToady you can say .Bool, but that's just a type coercion like .Int
01:45 dalek r29273 | cotto++ | trunk:
01:45 dalek : [codingstd] wrap macro args in src/jit/mips/jit_emit.h
01:45 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29273
01:49 pmichaud TimToady: so, S12 is incorrect about the built-in "bool" enum?
01:55 dalek r29274 | cotto++ | trunk:
01:55 dalek : [codingstd] wrap macro args in src/jit/ia64/jit_emit.h
01:55 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29274
02:10 teknomunk joined #parrot
02:28 particle1 joined #parrot
02:30 rdice joined #parrot
02:40 wknight8111 joined #parrot
02:51 dalek r29275 | jkeenan++ | parallel:
02:51 dalek : Create pcfreeze() and replenish() as wrappers around Storable::nfreeze and
02:51 dalek : thaw.  Combine two test files into one, replenishing the Parrot::Configure
02:51 dalek : object to do so.
02:51 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29275
02:53 * kid51 must sleep
02:53 purl $kid51->sleep(8 * 3600);
03:32 dalek r29276 | cotto++ | trunk:
03:32 dalek : [codingstd] ignore token concatenation when looking for unwrapped macro args
03:32 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29276
04:01 dalek r29277 | cotto++ | trunk:
04:01 dalek : [codingstd] Wrap macro args in src/jit/i386/jit_emit.h.  Yes, all of them.
04:01 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29277
05:10 bacek moritz: around?
05:10 purl nope.
05:20 baest joined #parrot
05:21 Psyche^ joined #parrot
05:21 baest identify spade
05:21 baest whoops
05:56 uniejo joined #parrot
06:05 dalek r29278 | cotto++ | trunk:
06:05 dalek : [codingstd] wrap macro args in src/jit/hppa/jit_emit.h
06:05 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29278
06:28 dalek r29279 | cotto++ | trunk:
06:28 dalek : [codingstd] wrap macro args in src/jit/arm/jit_emit.h
06:28 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29279
06:46 barney joined #parrot
06:46 Ademan joined #parrot
07:07 dalek r29280 | cotto++ | trunk:
07:07 dalek : [codingstd] wrap macro args in src/jit/amd64/jit_emit.h
07:07 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29280
07:09 moritz bacek: now I'm around
07:09 moritz good morning ;)
07:09 bacek moritz: I already started my friday night beer :)
07:09 bacek moritz: I actually want to ask for  apache rewrite rules for ilbot.
07:14 moritz bacek: aren't they in the repo?
07:15 moritz http://svn.pugscode.org/pug​s/misc/irclog/cgi/.htaccess
07:16 dalek r29281 | cotto++ | trunk:
07:16 dalek : [codingstd] wrap macro args in src/jit/alpha/jit_emit.h
07:16 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29281
07:16 bacek moritz: OSHI...
07:17 moritz perhaps I should have named it just htacess in there ;)
07:17 bacek moritz: good idea :) I didn't realize that it already here...
07:27 mire joined #parrot
07:34 dalek r29282 | cotto++ | trunk:
07:34 dalek : [codingstd] wrap macro args in various files
07:34 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29282
08:01 dalek r29283 | chromatic++ | trunk:
08:01 dalek : [OO] Made get_class and typeof return the same PMCProxy PMC.  See RT #56816.
08:01 dalek : There may be a further performance improvement available by caching the
08:01 dalek : PMCProxy as needed for each built-in PMC, but it's only useful if you extend a
08:01 dalek : built-in PMC from PIR.
08:01 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29283
08:01 mj41 hi, 29277, 2008-07-11 06:00:54, cotto - breaks trunk? .... http://tt.ro.vutbr.cz/report/pr-Pa​rrot/diff?trun-1665=on&trun-16​63=on&Submit=Compare+selected
08:03 mj41 or anything odd with TapTinder?
08:04 iblechbot joined #parrot
08:06 jq joined #parrot
08:08 cotto_home mj41, I'll look into it.  Thanks for noticing.
08:12 nopaste "mj41" at 147.229.5.124 pasted "to cotto, make error" (30 lines) at http://nopaste.snit.ch/13557
08:14 cotto_home how did you run Configure.pl?
08:16 nopaste "mj41" at 147.229.5.124 pasted "configure output" (88 lines) at http://nopaste.snit.ch/13558
08:17 mj41 $make_cmd = 'make';
08:17 mj41 $conf_cmd = 'perl Configure.pl';
08:20 cotto_home I'm not getting that failure.
08:21 cotto_home I'll look through the diff for something obviously broken I missed the first time.
08:22 * moritz gets and error in t/tools/dump_pbc.t
08:23 cotto_home Something tells me my karma's not going to look very good in the morning.
08:28 mj41 imho it's ok, many commits, but only one broken and probably only for one/my machine configuration :-)
08:33 cotto_home found something suspicious
08:34 cotto_home try lowercasing sTI on line 1141 of src/jit/i386/jit_emit.h and see if that fixes the break
08:36 cotto_home or just svn up
08:37 dalek r29284 | cotto++ | trunk:
08:37 dalek : [jit] fix a capitalization bug
08:37 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29284
08:37 cotto_home you still there?
08:39 cotto_home mj41++ #for finding and reporting the break
08:41 moritz captilization bug => captital punishment? ;-)
08:41 cotto_home It's almost 2:00 here and I need sleep.  If it's still broken msg me via purl and I'll take care of it in the morning.
08:42 cotto_home moritz, is your t/tools/dump_pbc.t failure related to mj41's?
08:43 moritz cotto_home: don't know, but don't think so
08:43 mj41 cotto, good night, see http://tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk at the morning
08:43 moritz cotto_home: go get some sleep ;-)
08:44 cotto_home sleep &
08:49 nopaste "mj41" at 147.229.5.124 pasted "r29284 - make error (broken in 29277)" (74 lines) at http://nopaste.snit.ch/13559
09:34 dalek r29285 | bernhard++ | trunk:
09:34 dalek : [Rekudo] Some tidbits in docs/compiler_overview.pod and README
09:34 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29285
10:01 dalek r29286 | bernhard++ | trunk:
10:01 dalek : [Pipp] Steal the quote-parsing code from Rakudo.
10:01 dalek : But don't use it yet.
10:01 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29286
10:14 Whiteknight joined #parrot
10:19 donaldh joined #parrot
10:21 Auzon joined #parrot
10:23 skv_ joined #parrot
11:01 dalek r29287 | bernhard++ | trunk:
11:01 dalek : [Pipp] Use 'quote_expression' for single and double quoted strings.
11:01 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29287
11:03 idemal joined #parrot
11:27 dalek r29288 | bernhard++ | trunk:
11:27 dalek : [Pipp PCT] Merge the rules 'array_assign' and 'scalar_assign' into 'var_assign'.
11:27 dalek : Support interpolation of keyed variables in a string.
11:27 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29288
11:39 ruoso joined #parrot
11:40 uniejo joined #parrot
11:40 Whiteknight joined #parrot
11:46 dalek r29289 | julianalbo++ | trunk:
11:46 dalek : Fix a typo in i386 jit_emit.h
11:46 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29289
12:10 Infinoid joined #parrot
12:43 iblechbot joined #parrot
12:54 rurban joined #parrot
13:05 dalek r29290 | pmichaud++ | trunk:
13:05 dalek : [rakudo]: spectest-progress.csv update:  95 files, 1691 passing tests
13:05 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29290
13:14 Ademan joined #parrot
13:15 dalek r29291 | kjs++ | trunk:
13:15 dalek : [docs] update pct docs a bit.
13:15 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29291
13:25 dalek r29292 | kjs++ | trunk:
13:25 dalek : [pdd19] add :lexid, but description not complete yet (not sure about details).
13:25 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29292
13:26 dalek r29293 | kjs++ | trunk:
13:26 dalek : [chitchat] add more action methods.
13:26 dalek : * made some assumptions/guesses from memory about semantics because lack of internet access and thus no access to reference.
13:26 dalek : * grammar might need some tweaks.
13:26 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29293
13:41 gryphon_ joined #parrot
13:46 rdice joined #parrot
13:51 dalek r29294 | bernhard++ | trunk:
13:51 dalek : [Pipp PCT] Try to add support for complex string interpolation with curlies.
13:51 dalek : But on input like
13:51 dalek :   echo "{}";
13:51 dalek : an infinnite loop may happen.
13:51 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29294
13:57 Whiteknight joined #parrot
14:01 NotFound joined #parrot
14:01 NotFound Hello
14:03 Whiteknight hello
14:03 purl salut, Whiteknight.
14:09 pmichaud hello
14:09 purl hola, pmichaud.
14:11 NotFound hello
14:11 purl hola, NotFound.
14:11 NotFound Doesn't like caps?
14:11 pmichaud too lazy to shift this morning ;-0
14:15 jonathan *groan*
14:17 dalek r29295 | Whiteknight++ | gsoc_pdd09:
14:17 dalek : [gsoc_pdd09] updating to trunk r29294
14:17 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29295
14:20 pmichaud jonathan: how hard would it be to get an outer Sub PMC to maintain a list of all of the (inner) Closure PMCs that reference it via :outer ?
14:20 ron joined #parrot
14:21 jonathan pmichaud: To maintain it, or to build it at compile time?
14:22 pmichaud (phone)
14:24 pmichaud well, primarily build at compile time, but I suppose it's also possible for a Closure PMC to be GCed
14:24 pmichaud (still on phone -- bbiab)
14:26 jonathan Hmmm...which could be a problem, because if it's on a list that we scan, it'll never get GC'd.
14:28 Whiteknight in my branch, it's not really possible for anything to get GC'd yet
14:39 jhorwitz joined #parrot
14:40 tewk Does parrot support weak references?
14:43 cognominal tewk, you don't need them
14:44 cognominal weak references is are kludge because reference counting has problem with  structures that contains loops.
14:45 * Infinoid volunteers to port weaken() to rakudo
14:53 cognominal that would be a noop? :)
14:53 Infinoid yep!
14:53 Infinoid we could implement it in lolcode
14:53 Infinoid hmm.  since we have pluggable GCs, is a refcounting GC an option?  so far it sounds like the API prevents that
14:54 Infinoid (an answer of "there's no way you would ever want to do that" is also acceptable.)
14:55 cognominal in our communauty, we want to do whatever we want
14:57 Andy joined #parrot
14:57 Whiteknight Infinoid, I suspect that true reference counting is not currently possible, no
14:58 Whiteknight at least, not without major modifications
14:58 Infinoid thought so, thanks
14:59 Infinoid it occurs to me that there's a huge amount of code that simply drops a pointer and expects things to be cleaned up automatically.  that does keep the code a *lot* cleaner.
14:59 cognominal community! # I always trip on that one
15:08 rdice_ joined #parrot
15:10 pmichaud (off phone)
15:10 pmichaud I was thinking that we wouldn't need to follow the inner_sub list to mark its members as live
15:11 pmichaud just that when a Closure PMC was destroyed, it removed itself from it's outer_sub's list
15:11 pmichaud *its
15:12 jonathan pmichaud: I haven't had chance to read your mails to the list yet, which probably give some context to this discussion. :-)
15:12 pmichaud I think only the last one is worth reading :-)
15:13 jonathan That aside - we statically know within a compilation unit what references a sub as being one of its outers. So it's possible.
15:13 pmichaud but essentially the bottom line is that we need to make sure that every inner sub has a newclosure performed on it at the time the outer sub is invoked
15:14 jonathan Can we not turn it around and lazily newclosure it if the outer sub has been invoked since we last were?
15:14 pmichaud apparently newclosure on invoke is a real problem
15:15 pmichaud for one, we can't always know that we're invoking the inner directly from its outer
15:15 barney joined #parrot
15:16 pmichaud the sub might be invoked several levels deep, which means we have to chase up the call stack to hopefully find the sub that this was intended to be newclosured in
15:17 pmichaud s:1st/the sub/the closure/;
15:17 jonathan Ah, you're saying newclosure is transitive?
15:17 pmichaud from what I gather from what I think rgrjr is saying, newclosure at the point of invoke is an issue.
15:17 jonathan OK.
15:18 pmichaud I'm not certain he's absolutely right about that or that it's unfixable, but I'm looking for other options.  :-)
15:18 jonathan So, to answer your question - it's messy, but possible, particularly handling it from a GC perspective.
15:18 jonathan As far as I can see, anyway.
15:18 pmichaud okay, that's good enough for me.
15:18 jonathan But I'm answering without reading this in any kind of context.
15:18 pmichaud yes, no problem.  I just wanted to know if I was overlooking anything obvious before I investigated it further.
15:19 jonathan After my last attempt at trying to fix closure stuff up for you, and the fallout of it, I kinda got fed up of it and wanted to do something else for a while...
15:19 pmichaud again, I think my latest post summarizes the issues fairly well and concisely describes how I think we can solve it
15:19 jonathan Parrot guts, at times, can be highly frustrating.
15:19 pmichaud and yes, I agree with the frustration, which is why I was looking into possibly doing this myself instead of shoving the frustration off to you :-)
15:19 Whiteknight agreed!
15:20 Whiteknight (Parrot guts can be highly frustrating)++
15:20 pmichaud your latest changes for lexid and closures gave me enough "oh, here's how it works" details that I think I could make the changes myself if necessary, or at least do an experimental branch with them.
15:20 jonathan OK, that's something at least.
15:21 jonathan And lexid is something we needed anyway and I guess is here to stay.
15:21 pmichaud oh, definitely -- it was very informative and helpful for me.
15:22 pmichaud on another topic (Bool versus bool) -- very interesting conversation with TimToady on #perl6 last night
15:22 pmichaud http://irclog.perlgeek.de/perl6/2008-07-11
15:23 pmichaud I don't things are entirely resolved yet, but it did help me to understand .Bool, .true, prefix:<?>, etc., or at least the way the spec is leaning at this point
15:23 jonathan Ah, I saw his commit and not the discussion; the commit didn't to me look to address all of the issues.
15:24 pmichaud yes, the discussion is exactly because to me the commit didn't look to address all of the issues :-)
15:24 jonathan In fact, it confused me more - I'll read the conversation log though.
15:24 pmichaud i.e., the conversation was a result of the commit, not vice-versa
15:24 jonathan Oh, OK. What came first... :-)
15:24 pmichaud (commit was at 2:03, conversation started at 3:00 :-)
15:27 dalek r29296 | Whiteknight++ | gsoc_pdd09:
15:27 dalek : [gsoc_pdd09] rearrange marking for child objects to account for pointer dependencies. Add a few break statements where GC and DOD blocking might need to be tested.
15:27 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29296
15:30 jonathan pmichaud: Too distracted with $otherjob to read it properly now, but will look later; thanks.
15:30 pmichaud no problem, just wanted to make sure you were aware of it
15:47 Theory joined #parrot
15:50 dalek r29297 | cotto++ | trunk:
15:50 dalek : [codingstd] fix macro args test, making it catch all token concatenations
15:50 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29297
15:58 sjansen joined #parrot
16:10 AndyA joined #parrot
16:11 gryphon_ joined #parrot
16:16 dalek r29298 | cotto++ | trunk:
16:16 dalek : [codingstd] whitespace fix and line length fix
16:16 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29298
16:26 dalek r29299 | Whiteknight++ | gsoc_pdd09:
16:26 dalek : [gsoc_pdd09] fixed bad ordering in sweep code. hdrs swept front-to-back, corresponding to cards from back-to-front. Fixed premature freeing of some PMCs, but now exposes random segfault in hash code.
16:26 uniejo joined #parrot
16:26 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29299
16:37 cotto_home can anyone see http://tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk ?
16:37 jhorwitz cotto_home: no
16:37 jhorwitz timeout
16:38 cotto_home thanks.
16:38 cotto_home work &
16:42 barney cotto_home: I see it
16:49 jonathan pmichaud: Just read the discussion and not feeling like it really answers much. :|
16:50 pmichaud it doesn't yet, other than to say that it's not answered yet :-)
16:51 jonathan Think it's worth me mailing p6l?
16:51 pmichaud Larry's aware of it, I suspect we'll see an update soon.
16:51 jonathan OK.
16:51 rurban joined #parrot
16:51 pmichaud I'm looking at namespace interpolations for jhorwitz -- unfortunately we've got a lot of changes to make to existing code in actions.pm
16:52 jonathan I can imagine that classes in some places ain't handling namespaces the Right Way.
16:52 jonathan And likely the same for roles too.
16:52 pmichaud it's not just namespaces, but also method names and routine declarators
16:52 pmichaud and enums
16:53 jonathan We need to be able to stick namespaces on these too?
16:53 pmichaud $foo.XYZ::method(...)
16:53 jonathan sub foo::bar::baz() { ... }
16:53 * jonathan wonders how $foo.XYZ::Mehotd() parses
16:54 pmichaud <methodop> takes a <longname> which takes a <name> which can contain namespaces
16:54 pmichaud <name> is anything with colons
16:54 pmichaud as opposed to <ident>
16:54 jonathan Ah
16:54 pmichaud quite a bit of existing code wants to treat <name> like ident
16:54 jonathan Yes
16:55 jonathan Aye
16:55 pmichaud I'm not worried about  sub foo::bar::baz()   as much as I am     sub foo::($bar)::baz() --- if such a thing is even legal.
16:55 jonathan Ah, longname includes colo pairs.
16:55 jonathan *colon
16:55 pmichaud well, for now it's sufficient to get <name> to work
16:55 jhorwitz pmichaud: fyi, that namespace interpolation patch is now broken ($past.name(undef) no longer works for call nodes).  i'll update the ticket with a working patch.
16:55 jonathan morename?!
16:56 pmichaud jhorwitz: don't worry about it too much
16:56 pmichaud jhorwitz: since STD.pm now says how interpolations get parsed, we'll want to go that way
16:56 jhorwitz what, me worry?  ;-)
16:56 pmichaud I just have to figure out how to represent run-time namespace interpolations in the PAST nodes
16:57 jhorwitz ok, if it's getting the proper treatment, i'll leave it to you guys  :)
16:57 jonathan pmichaud: Another thing to handle that I am pretty sure will be wrong now, is nested classes.
16:57 jonathan I did some work in that direction.
16:57 pmichaud oh, I know nested classes are likely wrong.  I'd like to get basic namespaces working first, though.
16:57 jonathan (Making sure attributes and methods ended up in the right class, or role, etc)
16:57 jonathan But the namespace side of them is almost certainly wrong. It was on my "we'll worry about that later" things.
16:58 dalek r29300 | bernhard++ | trunk:
16:58 dalek : [Pipp PCT] Rename token 'circumfix' to 'curly_interpolation'.
16:58 dalek : Remove support for Q:w, Q:ww, and Q:regex in quote_expression(),
16:58 dalek : as these aren't PHP features.
16:58 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29300
16:58 jonathan I think that it'd be good to review namespace stuff in general though.
16:58 ruoso joined #parrot
16:58 jonathan There are times when I've been writing stuff that I've thought, "hmmm...might have to re-visit that for namespace issues later".
16:58 pmichaud I'm thinking that the namespace attribute in PAST nodes will need to be updated
16:59 pmichaud as well as name, for that matter.
16:59 jonathan To be able to take a PAST tree rather than just a list?
16:59 pmichaud yes, to take a PAST tree.
16:59 jonathan OK
16:59 pmichaud that either returns an array or a namespace (haven't decided)
16:59 jonathan namespace may give more flexibility, but array may be easier to code-gen.
17:00 jonathan (As in, easier for compilers to generate)
17:00 jonathan (Not easier for PCT)
17:00 pmichaud well, given an array, one can always do  PAST::Op.new('get_namespace', $array_past)
17:00 pmichaud er
17:00 pmichaud :pirop('get_namespace')
17:00 barney Yes, i probably need PAST nodes for 'name',   for supporting  ${ $name_of_var }   in PHP
17:01 jonathan We can probably do MY:: with them too.
17:01 jonathan For Rakudo.
17:01 jonathan So yes, name as PAST tree in PAST::Var sounds good.
17:01 pmichaud MY:: ?  I figured that was going to have to return the LexPad
17:02 jonathan Perhaps.
17:02 pmichaud yes, there is always the option of always treating namespaces as hashes
17:02 jonathan I meant a lookup within that.
17:02 pmichaud instead of using the get_*_global opcodes
17:03 jonathan We still have to use one of them to get at the namespace in the first place, I guess.
17:03 pmichaud I'm pretty sure that the get_*_global opcodes require a NameSpace PMC
17:03 pmichaud anyway, I figured that MY:: would have to be special cased to return a Hash and we use a :keyed PAST::Var node for it
17:04 pmichaud I don't know that we can do pseudo-namespaces using the get_*_global opcodes.
17:05 pmichaud we could always do namespace lookups with get_*_namespace, and then use those as the base for :keyed nodes
17:06 jonathan nod
17:06 jonathan Yeah, I think you're right.
17:06 pmichaud which one?  ;-)
17:07 jonathan That we probably have to have MY:: returning a hash and keyed index into it.
17:07 pmichaud same for OUTER::, CALLER::, etc.
17:07 jonathan Aye.
17:07 jonathan CALLER:: may be a little more fun. :-)
17:08 jonathan Becuase it'll have stuff in from many lexical scopes (all those in the caller)
17:08 cotto_work NotFound++ #cleaning up the build
17:08 jonathan On the upside, at least we now have a way to know what is a Routine and what is a Block. :-)
17:09 jonathan What's your kinda "work plan" / priorities at the moment?
17:10 pmichaud I'm increasingly concerned that we're putting in too many 'advanced' features before the basics are in yet
17:11 pmichaud lexicals are still broken
17:11 pmichaud closure support is broken
17:11 pmichaud namespaces are broken
17:11 pmichaud parameter passing is broken
17:11 NotFound pmichaud: me also.
17:11 pmichaud HLL support is broken
17:12 NotFound pmichaud: unicode is broken
17:12 pmichaud actually, unicode I can deal with.  It's relatively isolated and pluggable
17:12 NotFound Well, it's not unicode, is the encoding system in general.
17:13 pmichaud still, it's quite pluggable.  it's not as if a change to Parrot's string handling system is going to force huge code changes in the HLL stuff we're doing
17:13 jonathan Of those, a bunch of them appear to be as much Parrot level issues as high level ones. Which gives resolving them that extra bit of difficulty.
17:13 pmichaud yes, they are Parrot level issues also.
17:14 NotFound That's the problem I see, a fail in a HLL can come from a variety of sources and is difficult to diagnose.
17:14 pmichaud but I've had too much experience (e.g., S05/PGE) where changes to the underlying model has caused huge rewrites in the code that depends on it
17:16 jonathan parameter passing - because the Parrot model doesn't give the Perl 6 semantics?
17:16 pmichaud and is broken on its own, as well.
17:16 jonathan And not especialy fast.
17:17 NotFound jonathan: because is broken, there are a lot of unresolved tickets about it.
17:17 pmichaud allison has already approved the design for a new param passing model that supports Perl 6 semantics better
17:17 pmichaud we just need an implementation :-)
17:17 NotFound A not broken one, preferably ;)
17:17 jonathan "just" :-(
17:18 NotFound pmichaud: What about the return values?
17:18 jonathan I've not read the details of what Allison suggested, but I'm fearful of putting any more features into the current implementation.
17:18 jonathan Not to mention trying to understand it in the first place.
17:19 pmichaud I don't think it is (or should be) "adding features" as much as "rethinking the implementation altogether"
17:19 pmichaud the syntax and basic semantics are backwards-compatible with what we have now
17:19 jonathan I dived in there last night for a while and saw things like structs in structs in structs...
17:19 pmichaud (with one minor exception that I don't believe anyone can possibly be using)
17:19 pmichaud yes, the new approach is likely much simpler
17:19 NotFound I completely fail to understand the current implementation when looking at some of the related tickets.
17:20 pmichaud I think the existing code suffered from a bit of premature optimization (that really wasn't)
17:20 jonathan branch and re-write would appear to be one option
17:20 pmichaud I think branch and re-write is likely the only viable option.
17:20 pmichaud NotFound: return values are handled basically the same as subroutine invocation -- i.e., it's the same code
17:20 jonathan The other "fun" in it is handling NCI and arguments from C.
17:21 NotFound pmichaud: there is a problem with the return values when doing a tailcall, as a recent ticket exposed.
17:21 pmichaud NotFound: I think that's an implementation bug more than a design problem
17:21 pmichaud and if we re-implement the parameter passing altogether, we can likely solve that bug
17:22 NotFound The problem seems to be that the C level call depends that the return values are exactly that it expects to be, and the tail call broke that assumption.
17:23 pmichaud anyway, as to my priorities:   they are (in no specific order)    HLL support, namespaces, lexicals, list assignment
17:23 NotFound But I'm not completely sure. As I say, I don't understand well the implementation.
17:23 pmichaud next tier would be signatures, parameter passing
17:23 pmichaud oh, first tier also includes pre-compiled modules
17:24 jonathan OK.
17:24 Zaba joined #parrot
17:24 pmichaud HLL support, lexicals, parameter passing are blocked on fixes or updates to Parrot
17:24 jonathan My (small) issue is that my MMD grant is for July/August.
17:24 jonathan And explicitly non-extendable.
17:24 pmichaud yes, I know.
17:25 pmichaud that's why I'm a bit frustrated and concerned that we can't get Parrot issues resolved quickly enough.
17:25 jonathan I don't want to distract from important things; equally, I don't want to let a donor down by not delivering.
17:25 NotFound By the way, will be nice if the pir or pbc generated by rakudo will be capable of autoloading the required libs and autostart himself.
17:25 pmichaud NotFound: this is explicitly planned.  In order for that to work I have to resolve the :load/:init issues
17:25 pmichaud which is yet another Parrot bug.
17:26 cotto-work joined #parrot
17:26 pmichaud (:load/:init doesn't play well with lexicals.)
17:26 jonathan pmichaud: Isn't that fixed in Allison's branch?
17:26 pmichaud yes, but when will that branch merge?
17:26 Zaba I'm back!
17:27 jonathan Heck knows, but I have a hard time believing that this particular fix is related to the concurrency things that are the subject of the branch.
17:27 pmichaud actually, I think it is related (more)
17:27 jonathan Has Allison said it would be hard to port it back into trunk?
17:27 pmichaud because the problem has to do with the separate runloops that occur for :init/:load versus the mainline code
17:27 jonathan Oh.
17:28 pmichaud and in the branch we don't have those runloop issues
17:28 pmichaud (if I understand what Allison has said about it)
17:28 pmichaud it shouldn't be hard to port back into trunk.  The problem is that Allison is the primary one doing it, and she's overloaded with non-Parrot work until at least the 25th
17:28 pmichaud (OSCON)
17:29 jonathan Right, I was about to say, progress on that branch will be slow for a while.
17:29 NotFound I've also seen a runloops related problem in the way pdb step code.
17:29 pmichaud so, unless/until everything starts magically working in the branch, the merge likely won't occur until the 25th
17:29 NotFound Someone is actually using pdb?
17:30 pmichaud anyway, as far as your MMD grant goes, I think we can go ahead and plan to reserve hacking days at YAPC::NA for you and I to focus on it intensely, if need be
17:30 pmichaud sorry, YAPC::EU
17:30 jonathan Yes, there is that option too.
17:30 jonathan In terms of Parrot stuff
17:30 pmichaud i.e., if we haven't made progress on signatures by then, then that's what we're doing in August to the exclusion of all else :-)
17:30 pmichaud signatures/MMD, I mean
17:31 jonathan How serious are the various issues as blockers?
17:31 pmichaud lexicals: serious
17:32 pmichaud HLL:  not too serious, we can continue to live in the 'parrot' namespace for a while and get incorrect types back from time to time
17:33 pmichaud using precompiled modules:  not serious, but profoundly beneficial in numerous respects -- most notably, the time needed to run 'make spectest_regression'
17:34 pmichaud we can cut approx 6 minutes out of the time needed to run spectest_regression if we get precompiled modules working
17:34 pmichaud also it allows us to start writing builtins in perl 6
17:34 pmichaud but precompiled modules depends on load/init depends on lexicals
17:34 pmichaud so I'm looking at a workaround for that
17:35 pmichaud parameter passing:  livable for now, but we need signatures resolved soon for mmd issues and because I don't like the way they're current factored in actions.pm
17:36 pmichaud namespaces:  increasing in importance, because we need to make sure that PCT supports all of the funky ways in which we deal with namespaces
17:36 pmichaud (and because a lot of actions.pl depends on being able to grab names)
17:37 jonathan You have Parrot bugs relating to namespaces filed too, or that's mostly PCT work?
17:37 pmichaud it's PCT work
17:37 jonathan OK
17:37 pmichaud mostly design, since I first started thinking about it in depth in the context of jhorwitz' patch
17:37 jonathan Just trying to get a sense of, if I'm going to throw some time at Parrot guts, where is it best spent.
17:38 pmichaud lexicals continue to be -- by far -- the biggest headache.  Nothing works without them.
17:38 pmichaud well, very little works right without them.  It's all a bunch of workarounds.
17:39 jonathan I don't want to do anything more on those from a code point of view until something that works for us, bob and others is worked out design wise, though.
17:39 pmichaud agreed.  I don't know who needs to bless a design, though.
17:39 jonathan I need to throw a lot more brain cycles at the thing to realy understand what both of you are saying.
17:40 jonathan Well, Allison, I'd think.
17:40 NotFound At least, that the code matches the design documents.
17:40 jonathan I don't really feel like I should be saying "yes we can change the design", even if I think we should, without her OKing it.
17:40 pmichaud NotFound: I believe the design documents are incorrect here.
17:40 pmichaud NotFound: there's no point in implementing a defective design.
17:41 NotFound Or even, that the code matches his own comments and pods.
17:41 pmichaud jonathan: I don't think it would be you saying "yes we can change the design".  I think it would be more of "Pm, jonathan, Bob, and chromatic all agree that this is a workable design for now (where the existing one is broken), so we're going to implement it and if Allison wants to change it later then we'll revisit it later)
17:42 NotFound pmichaud: yes, but in that case the document must be changed.
17:43 jonathan pmichaud: If we can get that kind of consensus on it, then I think that's OK.
17:44 pmichaud I just know that every time I go to fix something relatively fundamental, lexical bugs keep getting in the way
17:44 jonathan As NotFound says, we should fix the design doc and patch that, and I think ahead of the code changes, so there's a clear spec.
17:44 pmichaud I'm not sure we can a-priori know that a particular design works, given our collective experience levels.
17:45 pmichaud I'd rather tinker with an implementation until we get one that works, and then document that.
17:45 pmichaud :lexid being a prime example
17:45 pmichaud (because pdd20 makes absolutely _no_ mention or inkling that something like :lexid is needed)
17:46 jonathan OK, but let's at least try and get a consensus on what we can work out.
17:46 NotFound Maybe a good solution is: cd docs/pdds ; mv *.pod draft ; ;)
17:46 pmichaud right now I have a consensus of one that I like what I just proposed.  :-)
17:47 jonathan I'll read your and bob's mailing list posts at the weekend and try and feed into this.
17:47 pmichaud I'm eagerly waiting to see what rgrjr has to offer
17:47 jonathan Yes, I think he has a good understanding of these things.
17:47 pmichaud the first part of my proposal doesn't seem radical at all
17:47 jonathan Certainly, he's done stuff in that area of the code.
17:48 pmichaud the second part is more radical (where outer subs maintain lists of their inner closures), but I can completely live without it if we just do the first part
17:48 Ivatar joined #parrot
17:48 pmichaud if we try to stick with the existing newclosure design, either as implemented or as documented in pdd20, then we have a _lot_ of other design changes we have to start making.  Most notably we have to completely re-think multisubs
17:49 pmichaud also, after I wrote what I did last night, it occurred to me that it seems to match very closely many of the statements about closures in S04
17:50 pmichaud even down to the notion of "cloning closures"
17:50 jonathan Which part? The first part?
17:50 pmichaud the whole design
17:50 purl the whole design is sketchy as fuck.
17:51 pmichaud purl, what the hell do you know?!?
17:51 purl i don't know, pmichaud
17:51 pmichaud the basic concept is that inner closures have to capture their lexical environment at the time the outer sub is invoked
17:51 pmichaud the first part provides us with an explicit way to do that
17:51 pmichaud the second part provides a way to have Parrot do that automatically
17:52 jonathan pmichaud: "So, I propose that we add a "capture" method to Closure PMCs
17:52 jonathan to set the outer_ctx for that PMC."
17:52 jonathan So basically, it sets the outer_ctx of that closure to the current context?
17:53 pmichaud as well as checks that the current context is in fact the outer_sub
17:53 pmichaud i.e., you can only capture from the outer sub itself.
17:53 pmichaud (the check is optional, but probably useful)
17:53 jq joined #parrot
17:54 pmichaud invoking a closure then *never* performs a capture
17:54 pmichaud because that capture must have been already done
17:54 jonathan Yes, we should do the check, for sanity and to prevent weird hard to find bugs!
17:54 pmichaud i.e., the invoke vtable for captures becomes trivial.
17:55 pmichaud it checks for an outer context, throws an exception if one hasn't been set, otherwise it proceeds to do the sub
17:55 jonathan Right.
17:55 jonathan Hmm. Things could work.
17:55 jonathan *this
17:55 pmichaud if parrot doesn't implicitly set the outer context for all of its inner subs, then compilers (i.e., PCT) will have to generate code at the beginning of each sub to do it explicitly
17:56 pmichaud I'd prefer not to generate that code, but will do it if need be
17:56 pmichaud what I really like is that we can potentially eliminate 'newclosure' altogether
17:56 pmichaud because we just clone the Closure after its outer context has been set (whether implicit or explicit)
17:57 jonathan Yes, I get that bit.
17:57 pmichaud and that matches exactly what is written in S04
17:57 jonathan Can you explain your statement starting "if parrot doesn't implicitly set the outer context" a bit more to me?
17:57 pmichaud ideally (assuming it works), when I invoke an outer_sub I'd like it to automatically do a capture for all of its inner closures
17:58 pmichaud i.e., it iterates through all closures that have the sub listed as :outer, and sets the outer context directly
17:58 jonathan Ah, and *that* is why you want to know what all of the inner ones are...
17:58 pmichaud yes.
17:58 pmichaud if we don't have that
17:58 pmichaud then the code generator needs to do a lot of
17:58 pmichaud $P0 = get_hll_global 'inner'
17:58 pmichaud $P0.'capture'()
17:58 pmichaud $P0 = get_hll_global 'inner2'
17:58 pmichaud $P0.'capture'()
17:59 pmichaud at the beginning of each outer sub
17:59 pmichaud the code generator can fairly easily generate this, though, since it knows all of the inner subs
17:59 spinclad will this clobber existing closures of those inner subs?
17:59 pmichaud spinclad:  uncloned ones, yes.
18:00 pmichaud spinclad: but this is what rgrjr has been indicating needs to happen
18:01 slightlyoff joined #parrot
18:01 slightlyoff left #parrot
18:01 pmichaud note that this approach means that the example in http://dev.perl.org/perl6/doc/design/syn/​S04.html#When_is_a_clsoure_not_a_closure works naturally
18:01 pmichaud because assignment makes a copy (clone)
18:04 uniejo joined #parrot
18:04 spinclad ok, need to read the thread.  (rereading S04 section now)
18:04 pmichaud correct url is http://dev.perl.org/perl6/doc/design/syn/​S04.html#When_is_a_closure_not_a_closure
18:05 jonathan pmichaud: I suggest wait for feedback on what Bob says.
18:05 pmichaud I agree.  :-)
18:05 jonathan If he agrees it's a good idea, maybe we create a branch and try this out.
18:05 pmichaud but if it works, this proposal seems much simpler and more straightforward than the existing implementation
18:06 jonathan The first part of the mail looks like it may well be easily workable.
18:06 jonathan The keeping a list of inners bit worries me.
18:06 pmichaud I agree
18:06 jonathan And this may not play too wonderfully with MMD right off.
18:06 pmichaud oh?
18:06 jonathan But I can likely fix that up.
18:07 jonathan Well, the problem is that what are you invoking .capture() on?
18:07 pmichaud oh.
18:07 jonathan You're doing a get_.*global
18:07 jonathan Which looks in the namespace, ands hands you make a MultiSub
18:07 jonathan Which you then will call .capture on.
18:07 pmichaud in the mail I actually did a .const 'Sub'
18:08 jonathan Hmm, OK.
18:08 jonathan But does that distinguish different multis?
18:08 pmichaud but yes, we'd need a way to get the explicit cub
18:08 pmichaud er, sub
18:08 jonathan I'd be more inclined
18:08 jonathan (hmm...maybe, this may not make sense...)
18:09 jonathan To have .capture on a MultiSub go through the options, and any closures with an outer sub that matches that currently being executed get the outer context set.
18:09 jonathan Hmm...or would that break things...
18:09 pmichaud ooh, I think that would work wonderfully.
18:09 jonathan Yeah, but what if you update the outer of multiple variants?
18:09 pmichaud that's okay
18:09 jonathan OK
18:10 pmichaud because it would mean that all of those multiple variants are inner closures of the outer sub
18:10 jonathan I haven't convinced myself of that yet, but you've thought this through a lot more than I.
18:10 jonathan OK, that reasoning makes some sense to me.
18:10 pmichaud and so they all need to have captures taken
18:11 pmichaud that's far better than what I was thinking
18:11 pmichaud jonathan++
18:11 jonathan It's also the most natural.
18:11 pmichaud yes, very natural.
18:11 jonathan As in, the most natural from an implementation point of view.
18:11 pmichaud that's also what convinces me that this approach is pretty good -- things fall out naturally without a lot of funky stack or context manipulation (other than possibly the need to identify the inner closures)
18:12 jonathan OK, if Bob isn't disagreeable, let's try and get the first part of this implemented in a branch soon.
18:12 jonathan I'm still not convinced the second part will fly.
18:13 jonathan Certainly, holding a list of GC-able items without making sure they are marked, feels scary to me.
18:13 spinclad .oO { 'inner closures of outer sub' or '.. of outer closure (ie, call?)'? }
18:13 jonathan But if we need to do that, we can maybe work out another way.
18:14 pmichaud I may decide that I prefer having a method on outer subs that takes a list of inner closures and performs captures on each
18:14 pmichaud i.e.,   outer.'make_captures'(inner1, inner2, inner3, ...)
18:14 dalek r29301 | julianalbo++ | trunk:
18:14 dalek : Allow concat of utf8 and iso-8859-1 without icu
18:14 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29301
18:15 pmichaud but either way works for me
18:15 pmichaud if inner.'capture'() is implemented, it's trivially simple to create outer.'make_captures'(...)  :-)
18:16 pmichaud or even just  '!make_captures'()     since we can infer outer
18:16 jonathan If you know what outer's inners are...
18:16 pmichaud I'd still have to do the inner lookups, yes
18:16 pmichaud I don't see a way around that, unless outer somehow has a way of automatically getting the list itself
18:19 jonathan OK, so you're saying if the first part of your proposal is implemented, then you've got enough to work with and it will unblock things?
18:19 pmichaud yes.
18:19 pmichaud assuming it works.  :-)
18:19 jonathan OK. That gives me some hope we might be able to resolve this soon.
18:19 pmichaud the only thing I'm not sure of is the :load/:init issue with lexicals, but I think I can work around that.
18:20 pmichaud at least far enough to keep progress moving until the branch comes in.
18:20 jonathan OK.
18:21 jonathan So we have a plan from here to try and get lexicals/closures sorted out.
18:22 jonathan For HLL - are there tickets for the current issues you have with it?
18:23 jjore joined #parrot
18:23 julian_ joined #parrot
18:24 pmichaud (have to run for about 15-20 mins... bbiab)
18:24 pmichaud yes, there are hll tickets.  There's even a meta ticket.
18:24 jonathan OK, good.
18:24 jonathan I need to go for a bit too, to eat...back later
18:33 pmichaud meta ticket is #49812.  current outstanding bug is #56650
18:33 pmichaud Whiteknight++ was working on #56650, and there's information in the irc logs about how I proposed to fix it
18:34 dalek r29302 | Whiteknight++ | gsoc_pdd09:
18:34 dalek : [gsoc_pdd09] Remove some unnecessary garbage and cruft that I added for debugging, for problems which have since been resolved.
18:34 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29302
18:36 Whiteknight Yeah, I'm probably not going to be able to get a solid patch up and running for that until sunday night
18:36 pmichaud I may go ahead and do it if I do any work on p6object, then.
18:37 Whiteknight I'm knee-deep in this damned GC. I fix one segfault and expose two more!
18:37 pmichaud are there any blessed GCs?
18:38 pmichaud or are all GCs inherently the spawn of the underworld?
18:41 Whiteknight i'm starting to wonder
18:50 uniejo joined #parrot
18:57 NotFound pmichaud: after my last commit related to #39930 I'm testing to delete the workaround mentioned in #50092 and all looks good. Wan't to look at it?
18:58 pmichaud if it works and tests pass, feel free to commit a fix for #50092.  I'll review the commit and if I see anything wrong I'll fix/revert.
18:59 NotFound Ok, I go to commit when some more test finish.
19:00 purl joined #parrot
19:09 dalek r29303 | bernhard++ | trunk:
19:09 dalek : [Pipp PCT] Avoid infinite loop for curly string interpolation,
19:09 dalek : but break some tests.
19:09 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29303
19:13 Tene ICFP contest just announced.
19:19 dalek r29304 | julianalbo++ | trunk:
19:19 dalek : Deleted PCT grammar workaround, RT#50092
19:19 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29304
19:25 * jonathan returns
19:27 cotto-work icfp?
19:27 purl icfp is probably international conference on functional programming or at http://pauillac.inria.fr/pli/icfp/ or sponsoring a programming contest at http://www.cs.virginia.edu/~jks6b/icfp/ or (see:icfp2007)
19:29 davidfetter joined #parrot
19:48 dalek Jeff Horwitz | mod_parrot:
19:48 dalek link: http://www.perlfoundation.org​/parrot/index.cgi?mod_parrot
19:53 Zaba_ joined #parrot
19:55 uniejo joined #parrot
20:39 NotFound Whiteknight: ping
20:39 spinclad icfp2008?
20:41 dalek r29305 | coke++ | trunk:
20:41 dalek : [punie] resolve RT#56670 with an explanatory comment
20:41 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29305
20:42 cotto-work NotFound, is there any reason to keep RT#50092 open?
20:43 NotFound cotto-work: waiting for pmichaud take a look on it.
20:43 pmichaud it looks fine to me.
20:43 pmichaud I think the ticket can be closed.
20:43 pmichaud NotFound++
20:43 NotFound I will close both tickets, then.
20:44 Z2Z joined #parrot
20:45 cotto-work tickets--
20:45 cotto-work NotFound++
20:45 spinclad just include 'Closes: #56670' in the changelog, it will autoclose.  oh, wait.  this isn't debian, is it?  never mind.
20:46 NotFound ++ for who added the blue box on the public interface
20:49 NotFound karma tickets
20:49 purl tickets has neutral karma
20:55 NotFound I'm wondering why the const_cstring_hash is not marked, and supposing there is no reason why it does not brokes horribly.
20:57 jonathan NotFound: I don't think constants can get collected.
20:57 jonathan opes
20:57 jonathan *can't* get collected
20:58 NotFound jonathan: but the headers are, it isn't?
20:59 NotFound Ah, no, I was confused.
20:59 jonathan pmichaud: Read Bob's message?
21:00 pmichaud yes.  I'm confused.  Or he is.
21:00 jonathan I need to think it over more.
21:00 pmichaud I'm writing a response now.
21:00 jonathan OK.
21:00 pmichaud I think he misinterpreted what I wrote.jA
21:01 NotFound And the hash itself is not an object, I see now.
21:01 jonathan I'm writing a crappy evil ASP.NET output filter to translate .png to .gif to work around IE6 being unable to handle alphas transparency in PNGs. For a site that's meant to go production at the weekend. *sigh*
21:02 pmichaud yes, IE is horrible.
21:03 Tene jonathan: have you looked at pngfix?  a solution in javascript?
21:03 Tene http://homepage.ntlworld.com/bobosola/
21:07 pmichaud although, I'm a little tired of Bob writing things like "I would remove all use of autoclose from PCT and Rakudo, replacing it with a general solution"  when he doesn't even tell me what the "general solution" is.
21:07 jonathan Tene: I looked at SuperSleight, which is a JavaScript solution also. It didn't help so much. And looking at pngfix, it's trying the same trick.
21:07 pac1 joined #parrot
21:07 pmichaud that's all I'm asking for -- "what's the damn general solution?"
21:07 particle the gloves are off!
21:07 particle the texan is mad!
21:08 jonathan Tene: But thanks the suggesting. :-)
21:08 particle quick... where's the dr pepper and doritos?
21:09 particle pmichaud: sorry i haven't paid close enough attention to help you more with that closure problem
21:09 pmichaud All I have been doing from the beginning is trying to get PCT and Rakudo to work with a general solution.  I have no idea if I'm using autoclose or not -- that word means next-to-nothing to me.  I'm just trying to follow the stupid documentation (which is wrong) or ask folks to tell me what the compiler is supposed to be generating so that things will work.
21:09 pmichaud I'm just writing to write standard PIR code that makes lexicals work, and nothing I try works.
21:10 pmichaud and the solution he offers also doesn't work.
21:10 pmichaud (for multisubs)
21:10 particle mmd is yet to be redesigned
21:11 particle 'course that doesn't help you today
21:11 jonathan particle: Huh? The spec isn't marked draft any more.
21:11 pmichaud or this month.  or likely this summer at the rate things are being done.
21:12 donaldh joined #parrot
21:12 particle jonathan: but the implementation isn't done
21:12 cotto-work best line of code EVAR
21:12 cotto-work #include <shellapi.h></shellapi.h>
21:12 * Tene laughs.
21:12 Tene editor autocompletion gone wrong?
21:12 Tene cotto-work: where's that from?
21:13 cotto-work http://forums.thedailywtf.com/f​orums/p/9243/172728.aspx#172728
21:14 jonathan particle: Last time I read the PDD, I found it vague enough that it seemed too incomplete to implement. And I posted some issues I had with the draft on the mailing list, and I don't think any of them were addressed in the final.
21:16 jonathan The useful bit in there is that you can subclass the MultiSub PMC to get your language's semantics. Which is what I will do for Rakudo.
21:16 jonathan But it doesn't state the standard multiple dispatch algorithm for Parrot, etc.
21:18 jonathan ...let alone does it mention anything about closures and multis...
21:24 pmichaud and based on what Bob Rogers is saying in his thread, the idea that we can have a single symbol pointing to a MultiSub PMC is itself a problem.
21:24 pmichaud because there's not a way to replace that symbol with the result of a newclosure
21:25 pmichaud so, we have to have a MultiSub PMC that allows us to replace a specific entry with a newclosured one
21:25 pmichaud which means we need a way to *locate* that specific entry so that it can be replaced
21:26 pmichaud all of which says (to me) that for a vm that is supposed to make dynamic languages easier to implement, Parrot spectacularly fails at this aspect of it.
21:26 pmichaud if Parrot's defaults can't handle standard closures and lexicals without HLL compilers having to go through a lot of hoops and symbol table manipulations to make it work, then it's really b0rken.
21:27 NotFound I fail to understand why a closure has to be treated like a stand-alone function. Is not an already binded thing?
21:28 jonathan pmichaud: If we make newclosure a method, then it can be implemented on MultiSub, just the way I specified for Capture (which maybe from what Bob says won't work), but replacing the entries that match.
21:28 jonathan Or the newclosure op changes to recognize multis.
21:29 pmichaud "replacing the entries that match" sounds very tricky.
21:29 pmichaud I suppose one could determine "match" from lexid
21:29 jonathan That match = that have an outer that is the current sub.
21:29 jonathan Just as for newclosure on one closure.
21:30 jonathan (If we want to forbid calling newclosure when not in the outer)
21:30 pmichaud I don't think the problem that bob is referring to has to do with calling newclosure when not in outer
21:31 jonathan No.
21:31 * jonathan thinks
21:31 pmichaud Bob's recommended solution to the closure issue is to do
21:31 pmichaud .const 'Sub' inner_sub = 'inner_sub'
21:31 pmichaud $P0 = new_closure inner_sub
21:31 pmichaud set_global 'inner', $P0
21:31 pmichaud ....and then later
21:31 pmichaud 'inner'()     # invoke inner sub
21:33 pmichaud ....so, each time the outer sub is invoked, we do a newclosure of inner_sub and store that in the namespace as 'inner'
21:33 pmichaud (of course, if the inner_sub happens to be a method, then we need to replace a method)
21:34 NotFound pmichaud: What is the problem with that approach? Too much code?
21:34 pmichaud (and if the inner_sub happens to be a :multi, we have to make sure that 'inner' refers to a MultiSub and then replace whatever MultiSub (if any) was there from the previous invocation of outersub with the newly created closure)
21:35 jonathan Replacing a method would imply replacing it in the class vtable!
21:35 jonathan That *can't* be the right thing to do.
21:35 pmichaud I totally agree.  But since methods are lexical as well, I can certainly come up with an example that uses methods instead of strict sub calls.
21:35 pmichaud and so whatever we do for subs we'd have to do for methods
21:36 pmichaud and thus my frustration that he keeps saying "use a general solution" but doesn't give one that is at all workable in Parrot.
21:36 NotFound What is the reason to have to store the closure in a global named var?
21:36 pmichaud NotFound:  I'll no paste an example
21:39 jan joined #parrot
21:39 nopaste "pmichaud" at 76.183.97.54 pasted "example of global symbol table" (7 lines) at http://nopaste.snit.ch/13562
21:40 jonathan pmichaud: I think S04 is helpful where it says, "In particular, named subroutines in any scope do not consider themselves closures unless you take a reference to them."
21:40 pmichaud I pointed that out to Bob in an earlier message, yes.  I have no clue what that exactly means.
21:40 jonathan And in that case, newclosure - the clone - is what the reference becomes.
21:41 pmichaud yes, that's what I had been thinking, but apparently Bob disagrees.
21:41 jonathan Ah, OK. I *think* I understand it...let me just make sure, before I confuse things more...
21:41 pmichaud NotFound: in my example, foo()   is a global sub
21:41 pmichaud (actually, global to the namespace -- a package-scoped sub)
21:42 NotFound pmichaud: Is global, or is scoped in the enclosing block?
21:42 pmichaud NotFound:  the symbol itself is global
21:43 pmichaud 'sub foo'  is equivalent to    'our sub foo'
21:43 pmichaud if we wanted to limit it to the enclosing block, it would be 'my sub foo'
21:43 NotFound pmichaud: ok, but that applies to the sub, not the closure taken, it isn't?
21:44 pmichaud if we take a closure and expect 'foo()' to find it, then that closure has to be stored in the symbol table under 'foo'
21:45 jonathan pmichaud: I think what S04 is saying is that the only type a named sub needs to be newclosure'd, is if a reference is made to it.
21:45 jonathan only *time*
21:45 pmichaud jonathan: that's what I thought S04 was saying as well.
21:45 pmichaud let me rephrase
21:46 pmichaud when I read S04, that's what I think it's saying as well.
21:46 jonathan And that means that the result of the clone is _not_ replacing anything in the symbol table. Instead, it's what you get if you write &sub.
21:46 pmichaud agreed
21:46 NotFound That looks the reasonable thing to me.
21:47 jonathan Now, if it's an immediate block *that you're taking a reference to*, it always needs to be newclosure'd.
21:47 pmichaud and that's why I think I shouldn't have to be doing newclosure at all for the Perl 6 examples I've been doing
21:47 jonathan Note: taking a reference to. *not* invoking.
21:47 jonathan I wonder if that is the confusion here.
21:48 NotFound But that reference has to be taken inside the block, to have a correct context, I suppose.
21:48 jonathan Now it's just considering what happens under recursion.
21:49 pmichaud btw, I think that the existing implementation of newclosure is suspect, also.
21:49 pmichaud I was very surprised to see how it's implemented
21:50 dalek r29306 | fperrad++ | trunk:
21:50 dalek : [Pipp] doc
21:50 dalek : - fix some links to PHP reference manual
21:50 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29306
21:50 jonathan .sub 'foo' $P0 = whocares() .lex '$a', $P0 bar()
21:50 jonathan .end
21:50 jonathan .sub 'bar' :outer('foo') find_lex '$a' bar()
21:50 jonathan .endGrr
21:50 jonathan ...wow, no newlines
21:50 pmichaud hint:  nopaste :-)
21:50 jonathan Yeah, I wanted to have it in front of me while I talked about it!
21:51 NotFound .endGrr ? Nice way to end rant comments X-)
21:51 nopaste "jonathan" at 85.216.151.226 pasted "example" (9 lines) at http://nopaste.snit.ch/13563
21:51 dalek r29307 | fperrad++ | trunk:
21:51 dalek : [install]
21:51 dalek : - fix lolcode test
21:51 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29307
21:52 jonathan In this case, when we invoke bar the first time, from foo, we want bar to capture (have it's outer set to) foo's current outer context.
21:53 jonathan I guess a call on bar.capture() inside bar would then want to be a no-op, since the outer hasn't changed
21:53 jonathan Or would you have not been emitting a capture there?
21:53 pmichaud we would never call bar.capture there
21:53 pmichaud we call capture from the _outer_ sub.
21:53 jonathan Right.
21:53 jonathan So we'd just never emit it.
21:53 jonathan So that recursive example works with your scheme.
21:53 pmichaud all invocations of bar would end up using the same foo as an outer context
21:53 jonathan Right. Which is, I believe, correct.
21:56 nopaste "pmichaud" at 76.183.97.54 pasted "lexicals and recursion" (5 lines) at http://nopaste.snit.ch/13564
21:57 shamu joined #parrot
21:57 pmichaud 13564 is a more interesting recursive example
21:57 pmichaud (that I gave in the mail thread)
22:00 jonathan I think the key thing in Bob's example is here
22:00 jonathan my $recur = sub {
22:00 jonathan Note - he takes a reference to an (anonymous) sub
22:01 NotFound pmichaud: but following the rule of taken a reference, it's still not a closure.
22:01 jonathan That captures the current outer - the clone of the way things are now.
22:01 jonathan And that's the point of the newclosure.
22:01 pmichaud so, you're saying his example actually works under my proposal?
22:01 pmichaud or...?
22:02 pmichaud I don't immediately understand his example.
22:02 jonathan I'm saying that if we are doing what you suggest *and* we are doing newclosure when a reference is taken to a block/sub (anything that compiles down to a .sub in Parrot), then yes.
22:02 jonathan Or at least, I think so.
22:02 pmichaud I already mentioned that 'newclosure' is effectively a clone.
22:03 jonathan nod
22:03 pmichaud and that assignment takes a clone
22:03 NotFound I don't know perl6 rules, but looks logical to me.
22:03 pmichaud (since assignment copies its rhs anyway)
22:04 NotFound pmichaud: it takes a sub and returns a closure, it isn't?
22:06 jonathan pmichaud: At this point, since we both think this may work, I wonder if it's worth us just making a branch, implementing your suggestion, along with making sure we put newclosure in the right place (when a sub/block gets referenced), then translating Bob's example to Perl 6 to actually try it...
22:06 pac1 left #parrot
22:06 pmichaud I'd rather see it translated to PIR, personally.
22:06 pmichaud even a hand translation
22:06 NotFound But if is as you say in the thread just a synonym to call capture on the sub, the only reason for his existence is as optimization, I think.
22:06 pmichaud if you're correct, then my guess is that Bob doesn't recognize that  my $recur = sub { ... }    results in a newclosure
22:07 pmichaud (or a clone)
22:07 jonathan pmichaud: working on it
22:07 jonathan (hand translation)
22:08 NotFound pmichaud: at pir level the anonymous is still anonymous, or must have a name assigned?
22:08 pmichaud NotFound: it has an internal name
22:08 pmichaud but that name doesn't really mean anything, and we can even keep it from appearing in the symbol table
22:08 NotFound pmichaud: then I think it must be the same than a named one.
22:09 NotFound That is, taken a new closure on it at usage.
22:09 pmichaud jonathan: if you really need to be doing your $otherjob stuff, this can wait.
22:10 NotFound Maybe the problem is that Bob thinks that the sub is already a closure, not a sub.
22:10 jonathan Meh, $otherjob already got over 8 hours of me today
22:10 jonathan And I'll be doing stuff for them at the weekend.
22:10 pmichaud notfound:  in Parrot, any sub that accesses its outer lexical context is a Closure PMC
22:10 pmichaud in effect, all nested subs are Closure PMCs
22:11 pmichaud er, all nested blocks are Closure PMCs
22:11 jonathan If I wasn't doing this I'd only be drinking beer and looking at lolcats...
22:11 pmichaud jonathan: okay, just wanted to let you know my sense of priority/urgency.
22:11 NotFound pmichaud: but that is at execution, not at declaration, I suppose.
22:11 pmichaud NotFound: no, it's at declaration in PIR
22:12 pmichaud a nested block in PIR has an :outer(...) flag.  That causes it to be created as a Closure PMC instead of a Sub PMC
22:12 pmichaud of course, when the Closure PMC is created this way it doesn't have an outer context -- i.e., it hasn't captured its lexical environment yet
22:12 NotFound Mmmmm.... So a declared and an active one are the same type of object?
22:13 pmichaud so the discussion centers around "when does the inner closure captures its lexical environment?"
22:13 pmichaud Closure PMC and Sub PMC really differ only in type
22:13 pmichaud (and the implementation of invoke/freeze/thaw/etc.)
22:14 pmichaud and the fact that a Closure PMC has a value for outer_sub
22:14 pmichaud (outer_sub is NULL in a Sub PMC)
22:15 paco joined #parrot
22:16 paco left #parrot
22:17 jonathan I'm really glad we have compilers, because translating HLL code to PIR gets really tedious...
22:17 pmichaud well, I don't think it needs to be a literal translation -- just enough to show the same thread of execution
22:18 pmichaud I'm going ahead and sending a message pointing out the my $recur = sub point, and then I'm done for the evening (dinner here and need to spend time with kids)
22:18 jonathan OK, 2 mins and I have a translation.
22:18 pmichaud Feel free to add it as a response to my previous message.  :-)
22:19 NotFound Looks to me, according that explanation, that the problem is to distinguish between the static closure and the dinamic one.
22:19 pmichaud I'll look at the translation a bit later tonight
22:19 pmichaud gotta run
22:20 NotFound If you don't make the newclosure thing, you don't have the dynamic context stored on it.
22:20 paco joined #parrot
22:24 teknomunk joined #parrot
22:48 kid51 joined #parrot
22:52 * jonathan has got Bob's example to work in PIR by just taking newclosure whenever a reference is taken to a block.
22:57 NotFound I think I'm starting to understand... When calling directly, the context is taken directly by the current one. When taking the reference, is captured by the newclosure operation for later usage.
22:58 NotFound If that is correct, maybe having two different types will make things clearer.
23:02 dalek r29308 | jkeenan++ | parallel:
23:02 dalek : P::C::Base, P::C::Parallel: YAGNI.  No need for parallel object at this time,
23:02 dalek : as two wrappers around Storable functions will suffice.  Eliminate one test
23:02 dalek : file whose tests have been moved to another file.
23:02 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29308
23:02 dalek r29309 | julianalbo++ | trunk:
23:02 dalek : Reanme disassemble to pbc_disassemble by Reini Urban, RT#56542
23:02 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29309
23:04 NotFound Nice typo.
23:13 jonathan Nah...nice typos are the ones that accidentally lead to rude words. :-)
23:13 jonathan NotFound: See my post to the list, which I hope helps clear things up a bit.
23:15 dalek r29310 | jkeenan++ | parallel:
23:15 dalek : Consolidate multiple test files per configuration step into a single file.
23:15 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29310
23:17 NotFound jonathan: yes, that confirms whay I was starting to understand.
23:18 NotFound $P0 = find_global 'anon_1' | $P1 = newclosure $P0
23:19 NotFound Maybe a help from the parrot side to the hll writers can be to make an operation that combines those two.
23:21 jonathan I'd rather leave it as two. You might not be doing find_global.
23:22 jonathan find_hll_global and all manner of other things are possible.
23:24 NotFound We can just expect to see what the more frequent usage will be, an then maybe add an operation to shorten it.
23:26 * tewk is up over his eyebrows in parrot calling convention innards (src/inter_call.c)
23:27 tewk I used to know this stuff by heart, two years later and I can't remember a thing.
23:27 jonathan tewk: I looked in there just a couple of days ago and...hate.
23:28 jonathan I'm sure I saw stuff like src.sig.sig->c[0]....
23:28 NotFound tewk: that's a clear sign of too complex code.
23:29 NotFound Well, not, the sign is clear when is just two monts X-)
23:29 jonathan tewk: You are working on the GSoC project doing NCI things, right?
23:29 tewk Well I think I got enough of it back in my head now.
23:31 tewk Yeah I'm getting ready to jit nci calls, it really isn't going to be that bad. I just have to call a bunch of functions in assembly (src/jit_emit.h:build_call)
23:31 NotFound The jit is also a less than ideal example of clean code X-)
23:31 purl okay, NotFound.
23:32 NotFound jit?
23:32 purl jit is a Just In Time compiler.  Or just more Java hype. or new Parrot hype! or a less than ideal example of clean code X-)
23:33 tewk the current Parrot_jit_build_call_func is at least 2 or 3 refactors out of date.
23:34 jonathan tewk: pmichaud and I were pondering changes to inter_call.c - I guess touching it now would be disruptive to what you are doing?
23:34 tewk NotFound: inter_call.c makes all the cool calling convention stuff work.
23:34 NotFound tewk: for some values of 'all'
23:37 tewk You should have seen inter_call.c two years ago.  I did a major refactor to get it to look as good as it does.  Chromatic has cleaned it up quite a bit more too.
23:37 tewk jonathan: I'm not changing anything, just remembering how it works.
23:38 tewk There are a lot of helper functions, and I'm just going to use those.
23:38 NotFound tewk: I don't say that is all bad, but is very hard to diagnose the known bugs.
23:39 tewk I know what you mean, I always say to my self that it doesn't need to be that complex.
23:40 tewk But once I remember all the things it does, its hard to reduce the complexity.
23:42 tewk It does boxing, unboxing, INSP conversion, slurpy, named, flat, NCI, PCCMETHOD,   I just need a few more acronyms :)
23:43 tewk jonathan: what were you goint to change, the optional vs named stuff?
23:48 jonathan Apparently there are some changes too.
23:48 jonathan Or maybe they are optional vs named related. I'm not completely sure.
23:49 jonathan I haven't been thinking about it much, pmichaud just mentioned it was something that needed doing.
23:49 jonathan And both of us find that chunk of the codebase more than a little hard to get into.
23:52 dalek r29311 | jkeenan++ | parallel:
23:52 dalek : [configure] Refactor code from within runstep() into _handle_exec_protect(),
23:52 dalek : then test it.
23:52 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29311
23:54 kid51 Oooh, that last commit message was wrong.
23:56 dalek r29312 | jkeenan++ | parallel:
23:56 dalek : Consolidate multiple test files per configuration step into a single file.
23:56 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=29312

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

Parrot | source cross referenced