Camelia, the Perl 6 bug

IRC log for #parrot, 2010-07-23

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:01 tcurtis Should fdiv_i_i_i and fdiv_n_n_n give different results as in Pmichaud's gist?
00:01 pmichaud apparently that particular interpretation of fdiv_i_i_i has been there for a LOOOOOOOONG time.
00:02 pmichaud (the one that does the int div and then floors)
00:03 pmichaud it's pretty obviously a bug, I think.
00:03 pmichaud at least with respect to the docs.
00:03 tcurtis pmichaud: And there's no reason to have fdiv do that when div already does that.
00:04 cotto_work Sounds like you're advocating nuking a set of ops *and* a VTABLE function.  +1
00:05 tcurtis cotto_work: -1 to nuking fdiv. +1 to making it actually do what it's supposed to.
00:05 cotto_work nuke, fix
00:05 cotto_work same diff
00:05 Coke cotto_work: sure. are you planning on fixing anything right now?, or just preventative for next release?
00:05 pmichaud fdiv should be "floor div"
00:06 cotto_work Coke: I want to add that css fix to the docs
00:06 Coke cotto_work: how's that?
00:07 Coke cotto_work: ... what, /all/ of them?
00:07 cotto_work Coke: if I can easily script it, sure.
00:07 Coke (how's that, in that: I just did chmod -R g+w parrot/)
00:08 Coke meh. ok. In general, I don't wish to mess with the old versions of the docs, but given the nature of ths fix, sure.
00:08 cotto_work at least the current version
00:10 cotto_work Coke: wfm.  Thanks.
00:11 Coke cotto_work: the current version is alrady fixed.
00:11 Coke as the closed ticket mentioned.
00:11 cotto_work I noticed when I tried to fix it.  coke++
00:12 Coke kid51: hurm. those are not the modified files I expected to see.
00:12 Coke I was expecting _2 or _4 files.
00:13 cotto_work I wouldn't call the current design great, but the information is at least easy to spot.
00:13 jsut_ joined #parrot
00:13 cotto_work plus I shouldn't complain unless it's like something can come of it, which isn't like in this instance
00:14 cotto_work *likely
00:21 Coke 9
00:22 kid51 Coke:  I simply ran tools/dev/mk_native_pbc, then made sure that the tests that had failed got PASS on both darwin/ppc and linux/i386.
00:23 kid51 The tests had been passing until the release.  I don't know what commit caused them to start failing.
00:25 kid51 On Darwin/PPC, I got pass as late as r48090 on July 18.  The failures appeared in r48151 on July 20.
00:27 Coke hokay. as long as they work on both of those.
00:28 dalek rakudo: 245b4fe | Coke++ | docs/announce/2010.07:
00:28 dalek rakudo: Slight mod to verbage, add another entry from Changelog.
00:28 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/2​45b4feca5dac0a9613dcda58697455f459fdd01
00:28 dalek rakudo: afd65e7 | jonathan++ | docs/ChangeLog:
00:28 dalek rakudo: Couple more ChangeLog items.
00:28 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​fd65e79d25dc03977f9cb65a95990e7c6e0583c
00:33 dalek rakudo: 937177e | jonathan++ | docs/ChangeLog:
00:33 dalek rakudo: Also a note in the ChangeLog about enum improvements.
00:33 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​37177eeaa1c229428717f935f5680ed46b8ebf2
00:36 mikehh joined #parrot
00:37 elmex joined #parrot
00:38 eternaleye joined #parrot
00:41 Coke seen ingy?
00:41 purl ingy was last seen on #perl 2 days, 8 hours, 25 minutes and 19 seconds ago, saying: PerlJam: other ideas?  [Jul 20 16:15:59 2010]
00:44 eternaleye_ joined #parrot
00:45 dalek rakudo: 3528a10 | (Solomon Foster)++ | src/core/Int.pm:
00:45 dalek rakudo: Optimize use of .sign in infix:<div>.
00:45 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​528a10e67ff3ef1ab70c5faad33ef8c3b66a6ff
00:48 eternaleye joined #parrot
00:49 tcurtis So... if we've been shipping a fdiv_i_i_i for a long time that doesn't do what it's supposed to, would be have to do a deprecation cycle before fixing it?
00:49 cotto_work technically, yes.
00:49 cotto_work actually, I'd guess also yes
00:49 lucian_ joined #parrot
00:51 kthakore moritz++ Loving your post!
00:51 kthakore :D
00:51 kthakore is there a debian package for parrot and rakudo?
00:51 dalek rakudo: 87e77d0 | Coke++ | docs/announce/2010.07:
00:51 dalek rakudo: add a "we are not star" note to the compiler release announcement
00:51 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​7e77d0f757279a62d6b218d693bba10c2dd31ce
00:51 dalek rakudo: f2aa8d1 | Coke++ | docs/announce/2010.07:
00:51 dalek rakudo: rerun the contributer script.
00:51 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​2aa8d1545aa616cc2ee45cea2633600ddce24d2
00:51 tcurtis cotto_work: even though it's arguably a bug?
00:52 tcurtis s/arguably//
00:54 cotto_work That's consistent with the policy.
00:55 cotto_work though that change doesn't have the potential to break nearly as much as the typical deprecation
00:57 dalek rakudo: 5c33c5a | Coke++ | docs/release_guide.pod:
00:57 dalek rakudo: This release is heading out the door soon.
00:57 dalek rakudo: Also note broken step. :(
00:57 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​c33c5aaf2e7e096d5cbed018b357c5e8bc6f5eb
00:57 dalek rakudo: 8a9027a | Coke++ | docs/announce/2010.07:
00:57 dalek rakudo: I am fairly certain that Rakudo is not yet committing code to her own repository
00:57 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​a9027a8fcc97e59599af9bd4a4ae58aed0716ce
00:57 cotto_work not yet
00:57 cotto_work it's a very advanced form of self-hosting
01:03 Coke cotto_work: no, the fdiv thing sounds like a bugfix to me.
01:04 snarkyboojum joined #parrot
01:04 Coke cotto_work: you're crazy.
01:04 Coke if the docs say "does this" and it doesn't, and we make it do what we say in the docs, that is the OPPOSITE of a deprecation. =-)
01:08 dalek rakudo: 3d67b9d | Coke++ | src/ops/perl6.ops:
01:08 dalek rakudo: remove svn fossil
01:08 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​d67b9ddcebb09e804da5aff4ac6a572cd1f9d03
01:09 eternaleye_ joined #parrot
01:10 pjcj joined #parrot
01:14 dalek rakudo: 5b5c8f5 | Coke++ | docs/announce/2010.07:
01:14 dalek rakudo: I said, WE ARE NOT STAR.
01:14 dalek rakudo: (emphasize by moving up to 2nd paragraph). pmichaud++
01:14 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​b5c8f5f72a148a1edfddca6571d6970c77433f6
01:16 rurban_ joined #parrot
01:23 cotto ~~
01:23 cotto Coke, glad to hear it.
01:27 plobsing joined #parrot
01:27 theory joined #parrot
01:33 gbacon joined #parrot
01:39 dalek parrot: r48168 | gerd++ | branches/tt509_install_files:
01:39 dalek parrot: Removed "tt509_install_files" branch from the repository. Solved in r48115. The according Ticket #509 is closed.
01:39 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48168/
01:40 Chandon joined #parrot
01:42 dalek TT #1714 created by sng2nara++: in OSX snow leopard, Configure.pl stops on step#29 auto::va_ptr
01:42 dalek TT #1714: http://trac.parrot.org/parrot/ticket/1714
01:59 s1n joined #parrot
02:00 dalek rakudo: 93ec069 | util++ |  (3 files):
02:00 dalek rakudo: Added Ingy to CREDITS; made contributors.pl work with UTF-8 and ignore fake
02:00 dalek rakudo: "Rakudo Perl" name
02:00 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​3ec06999ea1ba442aee48dae8bb95c9348f7cc4
02:12 dalek rakudo: 40bf707 | Coke++ | docs/release_guide.pod:
02:12 dalek rakudo: stresstest runs spectest also - don't need it 2x.
02:12 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​0bf7075870621f0333f6beb20368264c028daa7
02:12 dalek rakudo: d1cd713 | Coke++ |  (3 files):
02:12 dalek rakudo: Merge branch 'master' of github.com:rakudo/rakudo
02:12 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​1cd713b50ef0e0a16444ca75789897f4ecc98ad
02:22 Coke http://blog.chromium.org/2010/07/​release-early-release-often.html #chromium adopting six-week release schedule.
02:37 kid51 It's scary when you google some abstruse technical point about which you think you know little, and google's first result is ... one of your very own posts!
02:46 atrodo that's not a good sign
03:09 * kid51 must sleep
03:09 purl $kid51->sleep(8 * 3600);
03:32 janus joined #parrot
04:15 dalek parrot: r48169 | Chandon++ | branches/gsoc_threads/t/pmc/task_primes.t:
04:15 dalek parrot: [gsoc_threads] Now with less blatantly wrong code.
04:15 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48169/
04:21 dalek website: Chandon++ | Green Threads: A Classic Example
04:21 dalek website: http://www.parrot.org/content/​green-threads-classic-example
04:22 Coke rakudo release #31 complete.
04:54 magnachef joined #parrot
04:55 AndyA joined #parrot
05:05 darbelo joined #parrot
05:46 jsut joined #parrot
06:05 cotto Coke, Yeah.  It's nuts.  I guess they can get away with it given the resources that Google can put behind Chrome though.
06:10 uniejo joined #parrot
06:20 fperrad joined #parrot
06:23 darbelo cotto: We ship a new parrot every ~4 weeks, and with less resources at hand. It's not that nutty, really.
06:23 cotto It's not a major version bump, though.
06:24 cotto (and yes, major version bumps have varying meaning)
06:26 darbelo Even an 8 bit integer has room to carry them through the next 15 years of development.
06:27 darbelo If 64 bit adoption keeps up, they won't have to worry about running out any time soon.
06:30 cotto I'll start to worry if they release v -127.0
06:50 lucian joined #parrot
06:54 sorear that would be very worrying, yes
06:54 sorear who uses one's complement anymore?
07:05 * darbelo tires of feeling lost and confused.
07:05 * darbelo decides to cd out of src/string and go to sleep.
07:22 fperrad joined #parrot
07:22 bacek joined #parrot
07:43 baest joined #parrot
07:43 bacek joined #parrot
08:13 theory joined #parrot
08:21 slavorgn joined #parrot
08:40 jsut_ joined #parrot
08:41 squeeks joined #parrot
08:42 nopaste "squeeks" at 192.168.1.3 pasted "Trying to install Rakudo/Parrot, and failing...." (23 lines) at http://nopaste.snit.ch/22231
08:42 cotto bacek, have you given any thought to how Lorito should support advanced control flow?
08:47 moritz is lorito supposed to CPS?
08:47 moritz *to be
08:47 cotto that's an open question
08:53 sorear Perl 6 needs either CPS or explicit delimited continuations
08:54 cotto Sure.  The question is whether Lorito will support it directly or indirectly.
08:55 sorear I hope by "indirectly" you don't mean "force Rakudo to CPS all generated code"
08:55 cotto PIR shouldn't need any changes post-Lorito.
08:56 cotto existing PIR code, that is
08:59 cotto If Lorito doesn't support it directly, it'll be supported by the (or a) PIR->Lorito layer.
09:04 GeJ CPS?
09:04 purl i think CPS is continuation passing style
09:04 cotto continuations?
09:04 purl continuations are like a two way setjmp
09:04 squeeks left #parrot
09:04 sorear delimited continuations?
09:05 sorear purl, delimited continuations?
09:05 purl sorear: wish i knew
09:05 moritz delimited continuations are likely NYI :-)
09:05 cotto sleep?
09:05 purl but if I close my eyes they will come and gouge my eyes out with brass plated spoons
09:05 cotto I was going to go to sleep, but perhaps that's not a safe option.
09:06 cotto night
09:07 GeJ servus cotto.
09:08 sri joined #parrot
09:16 rurban_ joined #parrot
09:50 gbacon joined #parrot
10:07 hanekomu_9 joined #parrot
10:16 JimmyZ joined #parrot
10:54 dalek rakudo: bc3e181 | (Solomon Foster)++ | src/core/Int.pm:
10:54 dalek rakudo: Reimplement infix:<div> to use pir::fdiv.  tylercurtis++.
10:54 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​c3e1810ec19fdcd7d88fe6b651fc57101329e72
11:03 bacek joined #parrot
11:19 AndyA joined #parrot
11:48 dalek rakudo: 4bf6c0f | moritz++ | src/core/ (2 files):
11:48 dalek rakudo: return Perl 6 strings from substr and join. Patch courtesy of felliott++
11:48 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​bf6c0f7bd4fe3be4df2f2f11a8d09147a172ad6
11:53 khairul joined #parrot
12:06 whiteknight joined #parrot
12:13 cognominal joined #parrot
12:16 snarkyboojum joined #parrot
12:28 whiteknight good morning, #parrot
12:35 Casan joined #parrot
13:00 macroron joined #parrot
13:16 bacek joined #parrot
13:17 kthakore whiteknight: morning
13:17 kthakore morning bacek
13:23 atrodo good morning
13:23 purl Lies!
13:31 dalek rakudo: 8c8b656 | Coke++ | docs/release_guide.pod:
13:31 dalek rakudo: add perl6-compiler, which masak++ noted was missing.
13:31 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​c8b6569f0aeb5ff418eab6b17f1a2c24b56c54a
13:31 dalek rakudo: b2af272 | Coke++ | src/core/ (3 files):
13:31 dalek rakudo: Merge branch 'master' of github.com:rakudo/rakudo
13:31 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​2af272545f0f269144080d73004278e05185e69
13:34 [1]Casan joined #parrot
13:54 [1]Casan joined #parrot
14:00 bubaflub joined #parrot
14:00 bubaflub left #parrot
14:02 bacek joined #parrot
14:53 gbacon joined #parrot
15:04 bubaflub joined #parrot
15:06 sri does parrot support non blocking sockets these days?
15:07 bubaflub joined #parrot
15:09 Casan joined #parrot
15:25 [1]Casan joined #parrot
15:26 bubaflub joined #parrot
15:29 Casan joined #parrot
15:30 dalek tracwiki: v138 | gerd++ | Languages
15:30 dalek tracwiki: http://trac.parrot.org/parrot/wiki/L​anguages?version=138&amp;action=diff
15:31 davidfetter joined #parrot
15:45 zostay joined #parrot
16:14 eternaleye joined #parrot
16:24 theory joined #parrot
16:29 whiteknight joined #parrot
16:31 moritz http://rt.perl.org/rt3/Tic​ket/Display.html?id=76692
16:33 bacek joined #parrot
16:40 PacoLinux joined #parrot
16:41 davidfetter joined #parrot
16:47 atrodo http://gist.github.com/487681 # Hurray! Lorito can now have and pass tests
16:47 bacek joined #parrot
17:10 theory joined #parrot
17:16 rurban_ joined #parrot
17:26 cotto It'd good to be capable of test-have.
17:27 atrodo test-have?
17:27 preflex joined #parrot
17:31 tcurtis joined #parrot
17:37 japhb joined #parrot
17:50 cotto_work ~~
17:52 cotto_work http://hrwiki.org/wiki/imaginary#Transcript (look for friend-have if you feel the reference is worth figuring out)
18:00 macroron joined #parrot
18:01 atrodo :D  homestarrunner++
18:08 theory joined #parrot
18:12 particle atrodo: i'd call the lorito files whatever.ito instead of whatever.lor
18:13 particle sounds, well, more onomatopoetic.  but that's just me.
18:13 * cotto_work gets flashbacks to the OJ Simpson trial
18:15 particle i know onomatopoeia isn't the right word, but i don't know what the right word is.  lorito is a tiny parrot core, not ancient parrot history.  .ito seems to fit better than .lor. *shrug*
18:18 cotto_work particle, do you know of some papers I could read that'd help me understand how Lorito would need to support advanced control flow (exceptions, cps, leave semantics, etc)?
18:19 * particle thinks.
18:19 * cotto_work thanks
18:20 atrodo particle> I've got no problem with ito files.  I may just start doing that by default
18:22 cotto_work http://ridiculousfish.com/blog/arc​hives/2010/07/23/will-it-optimize/ (happy fun quiz time)
18:30 AndyA joined #parrot
18:39 whiteknight there's no reason the file extension needs to be 3 characters
18:39 whiteknight .lorito would be just fine in my book
18:40 atrodo it's also, i'd imagine, be temporary
18:40 moritz you mean, like IMCC?
18:40 atrodo touche
18:41 cotto_work A three letter extension appeals to my laziness though.
18:42 cotto_work but this is another bikeshed that's best painted by the person building it
18:45 Tene There are some filesystems where extensions are special, iirc.
18:45 Tene Is "old-school DOS" a supported parrot platform? ;)
18:47 chromatic joined #parrot
18:47 chromatic Lorito should be able to get away with a branch op, and that's what it needs to support CPS.
18:50 cotto_work That'd explain why allison didn't mention anything further.
18:51 bacek joined #parrot
18:52 chromatic pmichaud and I talked about it the other night.  He said "As long as you can support the equivalent of longjmp, you should be okay."
18:52 chromatic We can do that.
18:52 cotto_work I guess so.  That makes sense if we're trying to have Lorito be equivalent to C.
18:53 chromatic M0 needs to be sufficient to replace C.
18:53 cotto_work How many other levels do you see?
18:55 chromatic Our existing ops are M1.
18:55 chromatic Some combo ops (such as fetch/vivify) can be M2.
18:56 chromatic From the perspective of the runloop, everything is M0.
18:56 chromatic From the perspective of the JIT, everything is M0.
18:56 cotto_work that fits the mental model I've been using
18:56 chromatic From the perspective of people writing code, everything is M1 .. Mn, where n is "Whatever's most convenient."
18:57 atrodo What about the idea of having M1 be composed M0 ops?
18:58 cotto_work atrodo: I think that's what he's saying is the plan.
18:58 atrodo And, if we just have longjmp, won't inner runloops jack with that?
18:59 cotto_work inner runloops happen becase we have both PIR and C.  If everything's M0, that problem goes away.
19:00 atrodo Maybe I should clarify.  Composed ops as in M1 gives the interpreter an op that's actually a reference to a series of M0 ops
19:01 chromatic The implementation of Mn is still fuzzy.  I think templates are a useful approach.
19:01 atrodo Won't we still be able to drop into C, say in the case of embedders, and they start an inner runloop?
19:01 * chromatic sets the curtains on fire
19:01 atrodo Fire! Fire!
19:01 cotto_work atrodo: we
19:02 cotto_work 'll need a way to call C functions.
19:03 chromatic I'd rather have some sort of coroutine system for embedders.
19:03 * chromatic sets the ceiling on fire
19:03 atrodo Water! Water!
19:03 * moritz sing an auld irish drinking song in which a burning ceiling plays a certain part
19:03 * cotto_work wonders
19:03 cotto_work also, lunchtime
19:04 moritz http://www.thebards.net/mus​ic/lyrics/Old_Dun_Cow.shtml
19:05 atrodo how feasible are coroutines in c?
19:05 fperrad joined #parrot
19:05 whiteknight atrodo: depends by what you mean by "coroutine", "in c", and "feasible"
19:05 atrodo coming for the guy that hasn't done too much with coroutines
19:06 atrodo What, no how or are?
19:06 chromatic Coroutines aren't that feasible in C, but if we only interrupt Lorito runloop execution at sane sequence points and store that context in the relevant interpreter, any embedders can use thet interpreter and we'll still remember the appropriate execution context.
19:06 chromatic ... without having to start a new runloop.
19:06 whiteknight It depends what you mean by "coroutine", again. It would be trivial to simulate the effect in C with a handful of static variables and some boilerplate
19:07 Coke chromatic: you follow the rakudo speedup that occurred before the release yesterday?
19:07 Coke (all in rakudo. no parrot)
19:07 moritz it was more of an un-slowdown than a speedup :/
19:07 chromatic I backlogged.
19:08 Coke now, in an ideal world, that wouldn't have been that slow to begin with, but it was nice to see an hll-only speedup. =-)
19:08 atrodo chromatic> so basically, the C would never be in the stack trace?  Embedders would call the runloop, get a result that could be a call, do it's magic and re call the runloop?
19:08 atrodo or something?
19:08 purl something is really wrong out there :)
19:08 moritz forget something
19:08 purl moritz: I forgot something
19:08 tcurtis Coke: and then another one today thanks to fdiv_n_n_n.
19:09 Coke right, but that's parrot. =-)
19:09 chromatic I'd have to see a table representing all of the ways embedders could call Lorito, but something like that.
19:09 chromatic Something like:
19:09 chromatic 1) fire and forget
19:09 chromatic 2) fire and get callbacks
19:09 theory joined #parrot
19:09 chromatic 2) fire and get callbacks which call back into Parrot
19:09 chromatic I mean 3) fire and get callbacks which call back into Parrot
19:09 chromatic 4) Launched from Parrot, then call back into Parrot
19:09 chromatic 5) Launched from Parrot, call into C
19:10 chromatic 6) Launched into Parrot, called into C, calls callbacks into Parrot, may call into C again
19:10 chromatic 7) a pony
19:10 tcurtis Coke: changing Rakudo to use it was a hll-only speedup.
19:11 particle ponies aren't dynamic enough. we want magic unicorns!
19:11 atrodo The new white meat!
19:11 tcurtis particle: unicorns aren't dynamic enough either. They have to be able to shape-shift.
19:12 particle MAGIC!
19:12 atrodo clearly, unicorns can shape-shift.  Have YOU ever seen one?
19:12 chromatic Unicorns must have ninja powers.
19:14 Coke tcurtis: ah, I thought it involved changing the op.
19:14 Coke just a functional chameleon circuit.
19:14 tcurtis Coke: fdiv_n_n_n works fine. fdiv_i_i_i is the broken one.
19:15 atrodo chromatic> do you know, at a high level, how exceptions work in parrot now?
19:15 moritz aren't exceptions just continuations + a bit of payload?
19:15 chromatic Essentially.
19:16 particle exceptions are also like snowflakes
19:16 purl okay, particle.
19:16 atrodo so to catch an exception, you insert a continuation object into the continuation stack?
19:16 atrodo or am i making stuff up?
19:17 chromatic You're making stuff up.
19:17 atrodo Hurray!
19:17 chromatic I don't like the current mechanism of exception handlers.
19:18 chromatic (and CPS means that there's no stack of continuations; it's a graph)
19:18 atrodo How would you do it instead?
19:18 * atrodo goes to read more CPS info
19:18 chromatic Every context has an optional slot for "If there's an exception, try catching it with *this*."
19:19 chromatic (in my ideal world)
19:19 chromatic That *this* is an exception handler, which is itself a continuation.
19:19 atrodo so, do context != continuations?
19:19 chromatic If it declines to handle that exception, it walks up its own chain of exception handlers until it finds the right one.
19:20 chromatic conexts and continuations could be the same thing; I haven't thought enough about that yet
19:21 chromatic If no exception handler can handle the exception, KAPOW
19:21 chromatic execution ends
19:21 chromatic If an exception handler handles the exception and decides to resume, YOING
19:21 chromatic YOINK
19:21 chromatic execution resumes at the appropriate point by invoking the exception's RESUME somehow
19:21 * chromatic waves his hands and puts out the flaming ceiling
19:22 atrodo It seems to me that as the runloop runs, it would have a stack of context's
19:22 moritz very dramatic effect. /me impressed
19:22 chromatic If an exception handler handles the exception and decides to resume execution elsewhere, MEH
19:22 chromatic execution resumes elsewhere.
19:22 chromatic Now things get complicated if you need to do CPS unchaining (or, as they like to call it in the Lisp world, stack-unwind).
19:23 chromatic If you handle but do not resume your exception, you may need to do something to exit every context between the new point of execution and the point of execution of the exception.
19:23 chromatic So you have to keep track of the right information and you have to exit all of those contexts for cleanup or something.
19:23 chromatic This implies that contexts may need the VM equivalent of human-sized windows in their restrooms in case vampires break in the front door looking for us.
19:24 chromatic I recommend distracting them with the flaming curtains, but we can't always rely on that.
19:24 atrodo i was going to ask a question, but i can't right now while i'm laughing about vampire windows
19:24 chromatic Mostly we need to figure out all of the ways we can leave a context and what kind of information we need to do so successfully.
19:25 chromatic I *believe* Rakudo needs some variant of stack-unwind, and I think we can have better GC hints if we take advantage of that.
19:25 chromatic I'm fairly sure Perl 5 on Parrot will need it.
19:25 atrodo okay.  So, in the static world I come from, you have two stack frames.  The regular one and the exception one.  When an exception happens, it looks at the last exception stack, and jumps to it
19:25 theory joined #parrot
19:26 atrodo it undoes a portion of the regular stack frame (essentially, just destroys it) that happened after it was installed, and tries to handle the exception
19:27 atrodo if it can't, it continues down the exception chain
19:27 atrodo how far from that is what we're trying to do here?
19:28 chromatic Similar ideas.
19:34 dalek rakudo: 4195e9a | moritz++ | src/Perl6/ (2 files):
19:34 dalek rakudo: disallow parsing of adverb form in quotes that we can't handle yet
19:34 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​195e9a26e1841c80b999303a81d4706f456e2bb
19:34 dalek rakudo: f196e88 | moritz++ | src/ (3 files):
19:34 dalek rakudo: Merge branch 'subst_adverbs'
19:34 dalek rakudo: This implements s:g/// and s:!g///. Nothing more, nothing less.
19:34 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​196e88d617bacff05e68b28487c52aefd5fad3c
19:35 [1]Casan joined #parrot
19:38 atrodo I suspect we can do something much cleaner and simpler in lorito than we have now in parrot
19:40 chromatic Indeed.
19:40 Andy joined #parrot
19:40 cotto_work Lorito wouldn't be worthwhile otherwise.
19:41 atrodo And as I read the CPS wikipedia, I understand why CPS is a graph, not a stack
19:41 chromatic If the only thing Lorito does is fix the inferior runloop problem, it's a huge improvement.
19:42 cotto_work chromatic, have you given any thought to how Lorito's longjmp equivalent would be implemented?
19:42 cotto_work Does it imply a stack-based Lorito?
19:42 chromatic As far as I can tell, it's just "invoke this invokable"
19:43 Coke chromatic: here's hoping it does at least one more thing.
19:43 chromatic No stack just necessary.
19:43 dalek tracwiki: v65 | moritz++ | ParrotQuotes
19:43 dalek tracwiki: escape routes if vampires are approaching
19:43 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=65&amp;action=diff
19:45 chromatic invoke may have to switch bytecode segments, but that's just pointer swapping
19:46 chromatic Otherwise it's "Okay, the runcore goes over here for a while then"
19:47 cotto_work Is there something that works similarly that I can read up on?
19:47 chromatic Which part of it is confusing?
19:48 cotto_work How invoking an invokable is sufficient to implement all the types of control flow we need to simulate.
19:49 cotto_work nm.  That's cps.
19:50 chromatic Yeah, if we use CPS pervasively we're good.
19:50 cotto_work Do you have time to answer some subset of the questions on http://trac.parrot.org/parro​t/wiki/LoritoDesignQuestions ?
19:50 atrodo Does that solve exceptions?
19:51 cognominal joined #parrot
19:51 Chandon The way Parrot works now I can swap green threads between arbitrary instructions. How does that work in Lorito?
19:52 cotto_work atrodo: CPS allows exceptions
19:52 chromatic Chandon, pmichaud and I think we need to find sequence points in M0.
19:52 Chandon (I can, conceptually, swap green threads between arbitrary instructions. In practice there's some weirdness in some cases.)
19:53 Chandon Coming up with sequence points that break all potential compute loops is sort of annoying.
19:54 atrodo cotto_work> that's a part that I'm fuzzy on right now
19:54 cotto_work Yeah.  It took me a while to wrap my head around continuations and CPS.
19:55 atrodo so, in CPS, do you pass a "if you have an exception, use this continuation"?
19:57 chromatic I'd attach it to the context, but effectively yes.
19:58 atrodo so, effectively, we'd have a continuation graph and an exception graph?
19:59 chromatic Yeah, everything we might need to invoke to leave the current execution context needs a graph.
20:02 atrodo so, when you call a new context, would the context have multiple continuations that it can return with in it, plus any number of exception continuations?  Or would the extra continuations come as parameters?
20:03 chromatic Invoke passes a return continuation as a parameter (in bound or out of bound)
20:04 chromatic exception handlers probably get inherited from the calling context (unless it's a return... though how do we detect that?) and any static handlers for the current scope.
20:05 bacek joined #parrot
20:05 theory joined #parrot
20:05 atrodo so all continuations are parameters?  Or is there a special default return continuation?
20:06 whiteknight there is a return continuation in a call
20:06 whiteknight It's stored in the current context, I believe
20:06 chromatic By "return continuation", we mean "Invoke this when you want to return normally"
20:06 whiteknight right. It's the thing that the .return() directive invoktes
20:06 whiteknight invokes
20:07 atrodo okay, that makes sense
20:07 whiteknight you could invoke anything you wanted at that point to leave the current Sub, however
20:07 whiteknight (though another Sub call would attempt to return back there)
20:07 atrodo right
20:08 whiteknight Lorito is going to have to pass the return continuations explicitly, unlike current PIR which assumes their use internally
20:08 chromatic Right.
20:08 whiteknight if lorito can communicate directly with C functions, then we can't just blindly be passing return continuations to every function we call
20:09 whiteknight Though I do advocate for some sort of shorthand to differentiate, for sanity
20:09 whiteknight "call this Parrotish function" as opposed to "call this Cish function"
20:10 cotto_work callcc vs call?
20:10 atrodo whiteknight> try that again?  As in, return continuations are pass as paramaters and not inside the context?
20:10 whiteknight atrodo: in classic CPS, all functions are called as foo(retcont, args)
20:10 whiteknight where the return continuation is the first argument to the function
20:11 atrodo no "default' return
20:11 whiteknight the HLL can do that silently, and not require the programmer to do it manually, but it always happens
20:11 whiteknight atrodo: what is "default"?
20:11 purl "default" is "-net 0.0.0.0"
20:12 atrodo return continuation that is set in the context
20:12 cotto_work forget "default"
20:12 purl cotto_work: I forgot "default"
20:12 whiteknight atrodo: where does the return continuation know to return to, if it hasn't been constructed in the Caller's context?
20:12 whiteknight you need to construct the return continuation in the caller's context, and pass it to the callee
20:12 chromatic atrodo, there is no "return" operation which pops an address off of the stack then branches there.
20:12 whiteknight in Parrot, the PCC system does this automatically for "normal" sub calls, but that's just a nicety
20:13 whiteknight the invokecc opcode is short for "invoke this CPS function, but automatically create a return continuation for me"
20:13 whiteknight the invoke opcode requires you to explicitly pass the continuation, and is more like "normal" CPS
20:16 atrodo so when you call invoke, the continuation that you pass gets stored in the context that you're calling, right?
20:16 chromatic We could store it anywhere, as long as it's available for the return.
20:17 whiteknight but yes, in this case it's the context
20:17 atrodo okay.  Had me confused there for a little bit
20:18 atrodo so, to recap my understanding of how this works, there is a stack of continuations, but there's no guarantee that any of them will be called
20:18 chromatic s/stack/graph/ but yes
20:19 atrodo so you can give a context a list of possible continuations to call?  Or are the rest of the continuations for the graph passed as parameters?
20:21 chromatic There's always one return continuation passed in.
20:21 chromatic A function may take one or more continuations as regular arguments (from the HLL perspective).
20:22 atrodo so the graph is composed with the one return continuation plus the rest of the continuation pass as regular arguments?
20:23 chromatic The graph is the control flow up to the current invocation.
20:23 chromatic It's like stack frames in a stack based language.
20:24 Coke "will lorito have a stack". Oh, the hilarity that will ensue.
20:26 cotto_work The longjmp analogy threw me off.
20:26 whiteknight longjmp basically is a continuation
20:26 whiteknight a stupid, limited continuation in C
20:27 atrodo s/C/asm/
20:27 whiteknight yeah, you can do it from asm too
20:27 whiteknight I was talking about the stdlib function mostly, since it saves processor state
20:28 atrodo huh, C has a longjmp feature.  I never knew
20:28 whiteknight you never knew because you never used it. Because it's shitty and should never be used
20:29 cotto_work atrodo: you can use it as a pessimization: http://thedailywtf.com/Articl​es/Longjmp--FOR-SPEED!!!.aspx
20:29 whiteknight ha, I loved that article
20:30 atrodo haha, nice
20:31 atrodo Yea, when longjmp was mentioned, all I could think of was my 16-bit dos days in asm using longjmp
20:31 chromatic It was a metaphor, but it would have been better if I'd said "invokecc".
20:32 chromatic maybe we need a do-nothing sequence point op.
20:32 chromatic or at least a flag
20:32 whiteknight I'm not sure I understand why we would want sequence points at all
20:33 whiteknight I guess I would have to see the speed differential between checking a flag periodically or calling an op that does nothing most of the time
20:34 whiteknight we could do something like instruction rewriting: When we want to do something out of normal flow we rewrite the next op, do our think, write the op back how it was and then continue from there
20:34 chromatic I'm thinking we don't want to interrupt certain composed Mn ops, like fetch/vivify.
20:35 atrodo whiteknight> first time I did that on my 386, i discovered the cache
20:38 whiteknight chromatic: depends on the op
20:39 cotto_work We have space for a flag.
20:39 whiteknight anyway, I've got to head home. Later
20:40 tcurtis CLI/STI?
20:41 atrodo tcurtis++
20:41 tcurtis Alternately "do_not_interrupt_me_now; body_of_op; you_can_interrupt_me_again_it_is_​totally_fine_dont_worry_about_it"
20:43 cotto_work That's a lot of potential extra ops.
20:44 cotto_work good names though
20:44 tcurtis Well, body_of_op is a place-holder. :)
20:45 chromatic Or maybe we don't have a runloop for M0 and our runloop is only M1 .. Mn.
20:53 cotto_work chromatic: wouldn't that preclude optimizing across M0 ops?
20:53 atrodo you can still unroll
20:55 chromatic I don't know.
20:55 Coke I thought part of the point was having our runloop be at M0.
20:55 Coke (what does M stand for?)
20:56 atrodo (Magic)
20:56 chromatic microcode layer
20:56 cotto_work I like that.  At M0, there's no magic.  At M1, there's a little.  At M5, there's Rakudo.
20:57 chromatic Magic Level
20:57 chromatic That means Fireball is in M3, and Minor Wish is M7.
21:02 particle what level is The Flying Dutchman?
21:02 chromatic That's a Unicode character, not an op.
21:03 atrodo Wait, Rakudo is only level 5?  that can't be right
21:03 cotto_work chromatic: what do you picture M0 ops looking like in bytecode?  1 byte for the op + 3*2 bytes for the args?
21:03 lucian joined #parrot
21:03 cotto_work atrodo: it gets exponentially more magical.
21:03 cotto_work M6 is dtrt
21:03 tcurtis I presume that at Mn for some n, there is only a DWIM op with no arguments?
21:03 atrodo Ah ha!  Makes perfect sense now
21:04 cotto_work M7 is dtrt without me even asking
21:04 Coke sadly, the magic scale was recalibrated during Parrot:TNG, and exceeding M10 was possible.
21:05 cotto_work It has no ops.  It doesn't need them.
21:05 cotto_work It's the Chuck Norris of dynamic languages.
21:06 chromatic cotto_work, sounds right to me.
21:06 cotto_work Having a 7-byte op rubs me the wrong way.  I want it to be 8 or 4.
21:07 chromatic At M6 I get to ride a magical flying T-Rex to work... and my commute is only TWO FLIGHTS OF STAIRS.
21:07 chromatic Clearly M6 and up are fanfic ops.
21:13 cotto_work 65536 registers ought to be enough for anybody
21:15 Andy joined #parrot
21:16 particle so add a byte for magic!
21:16 particle store security info there, or other metadata
21:17 particle or compress the args in bytecode to one byte only, and put the args in an arg segment O_o
21:17 chromatic Now there's an idea.
21:19 dolmen joined #parrot
21:21 cotto_work It's an idea.  I can't disagree with that.
21:21 Coke cotto_work: you ever look at my bug report of bizarre reports from the profiling setup?
21:21 cotto_work TT?
21:21 purl i heard TT was template toolkit or http://www.template-toolkit.org/ or #tt or usually n0t Text::Template or TrueType (usually: TTF) or toula toukarev
21:22 Coke #1127
21:23 cotto_work I've put it on my todo list.  Thanks.
21:23 Coke note that that ticket was assigned to you. you may have others. =-)
21:24 Coke danke. Now that I have a linux box that I can run *grind on, I'd like to start profiling rakudo a bit.
21:26 ilia joined #parrot
21:29 cotto_work Coke, if you can come up with a reasonably small snippet that's broken, I can add a test case.
21:30 cotto_work (for profiling)
21:32 cotto_work (and now that I've been away from that code for a while, I'll be better able to see its warts)
21:46 cotto_work chromatic, just to be really clear, you're saying that all control flow (including CPS) will be implemented on top of simple constructs like goto and call?
21:48 chromatic That's how I see it, yes.
21:48 cotto_work wfm
21:50 atrodo huh, not the road i had started down
21:50 cotto_work Is there something like a consensus on that?
21:51 chromatic Apart from "Call this C function", what other control flow is necessary?
21:51 whiteknight joined #parrot
21:55 cotto_work atrodo: what do you mean?
22:02 ilia joined #parrot
22:10 gbacon joined #parrot
22:14 dalek tracwiki: v11 | cotto++ | LoritoDesignQuestions
22:14 dalek tracwiki: CPS et. al. will be on top of Lorito, not part of it
22:14 dalek tracwiki: http://trac.parrot.org/parrot/wiki/LoritoD​esignQuestions?version=11&amp;action=diff
22:26 cotto_work Coke: is there a nice way to whittle down bugs exposed by partcl?
22:28 cotto_work An empty tcl program shows the bug nicely, but it's not clear how to cut partcl down.
22:28 cotto_work also, pbc_dump segfaults on tcl.pbc
22:28 cotto_work might need to fix that
22:29 cotto_work probably a dynop thing
22:29 cotto_work nm.  works fine without -d
22:44 tcurtis chromatic: I'm about to leave for a party(I'm already late, in fact), but I want to update you on what I've been doing on my GSoC the last few days(yesterday and today, specifically, since internet & power failures Wednesday interfered with researching LLVM's PassManager).
22:44 tcurtis I've been trying to implement an API where you make PAST::Optimizer a parent of your compiler class, and then addstage "optimize-past" and call a register-past-optimization method to add new passes. This turns out to be not very pleasant to use(in addition, I'm having weird method not found errors for the optimize-past stage even though the parent was added and it has the method).
22:44 tcurtis Tomorrow I'm going to start trying to implement instead an API where the equivalent of PassManager and of FunctionPass, etc. are indepedent of PCT compilers
22:44 tcurtis So, a compiler-writer will just add an optimize-past method to their compiler class that creates a PAST(or even PCT or Tree, since its less PAST-specific)::Optimizer, registers appropriate optimization passes, and calls the run method on it. I'm also going to write a blog post with some examples of how I expect code using the API to look.
22:46 chromatic The new approach sounds more reasonable.
22:52 * tcurtis leaves.
23:10 bacek joined #parrot
23:38 cotto ~~
23:40 snarkyboojum joined #parrot
23:53 Coke cotto_work: I thought one line of tcl was pretty small. :P
23:55 Coke old school partcl is even less amenable to "convert this to a standalone PIR snippet." than current partcl-nqp
23:55 Coke I'll see what I can do.
23:55 cotto zero lines of tcl is small too.
23:57 Psyche^ joined #parrot

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

Parrot | source cross referenced