Parrot 2.6.0 | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | fix 'make html' (talk to Coke), update tutorial (talk to tcurtis)
Set by moderator on 21 July 2010.
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.
(the one that does the int div and then floors) 00:02
it's pretty obviously a bug, I think. 00:03
at least with respect to the docs.
tcurtis pmichaud: And there's no reason to have fdiv do that when div already does that.
cotto_work Sounds like you're advocating nuking a set of ops *and* a VTABLE function. +1 00:04
tcurtis cotto_work: -1 to nuking fdiv. +1 to making it actually do what it's supposed to. 00:05
cotto_work nuke, fix
same diff
Coke cotto_work: sure. are you planning on fixing anything right now?, or just preventative for next release?
pmichaud fdiv should be "floor div"
cotto_work Coke: I want to add that css fix to the docs 00:06
Coke cotto_work: how's that?
cotto_work: ... what, /all/ of them? 00:07
cotto_work Coke: if I can easily script it, sure.
Coke (how's that, in that: I just did chmod -R g+w parrot/)
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
Coke: wfm. Thanks. 00:10
Coke cotto_work: the current version is alrady fixed. 00:11
as the closed ticket mentioned.
cotto_work I noticed when I tried to fix it. coke++
Coke kid51: hurm. those are not the modified files I expected to see. 00:12
I was expecting _2 or _4 files.
cotto_work I wouldn't call the current design great, but the information is at least easy to spot. 00:13
00:13 jsut_ joined
cotto_work plus I shouldn't complain unless it's like something can come of it, which isn't like in this instance 00:13
*likely 00:14
Coke 9 00:21
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:22
The tests had been passing until the release. I don't know what commit caused them to start failing. 00:23
On Darwin/PPC, I got pass as late as r48090 on July 18. The failures appeared in r48151 on July 20. 00:25
Coke hokay. as long as they work on both of those. 00:27
dalek kudo: 245b4fe | Coke++ | docs/announce/2010.07:
Slight mod to verbage, add another entry from Changelog.
 00:28
kudo: afd65e7 | jonathan++ | docs/ChangeLog:
Couple more ChangeLog items.
kudo: 937177e | jonathan++ | docs/ChangeLog:
Also a note in the ChangeLog about enum improvements.
 00:33
00:36 mikehh joined 00:37 elmex joined 00:38 eternaleye joined
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
dalek kudo: 3528a10 | (Solomon Foster)++ | src/core/Int.pm:
Optimize use of .sign in infix:<div>.
 00:45
00:48 eternaleye joined
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.
actually, I'd guess also yes
00:49 lucian_ joined
kthakore moritz++ Loving your post! 00:51
:D
is there a debian package for parrot and rakudo?
dalek kudo: 87e77d0 | Coke++ | docs/announce/2010.07:
add a "we are not star" note to the compiler release announcement
kudo: f2aa8d1 | Coke++ | docs/announce/2010.07:
rerun the contributer script.
tcurtis cotto_work: even though it's arguably a bug?
s/arguably// 00:52
cotto_work That's consistent with the policy. 00:54
though that change doesn't have the potential to break nearly as much as the typical deprecation 00:55
dalek kudo: 5c33c5a | Coke++ | docs/release_guide.pod:
This release is heading out the door soon.
 00:57
kudo: 8a9027a | Coke++ | docs/announce/2010.07:
I am fairly certain that Rakudo is not yet committing code to her own repository
cotto_work not yet
it's a very advanced form of self-hosting
Coke cotto_work: no, the fdiv thing sounds like a bugfix to me. 01:03
01:04 snarkyboojum joined
Coke cotto_work: you're crazy. 01:04
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. =-)
dalek kudo: 3d67b9d | Coke++ | src/ops/perl6.ops:
remove svn fossil
 01:08
01:09 eternaleye_ joined 01:10 pjcj joined
dalek kudo: 5b5c8f5 | Coke++ | docs/announce/2010.07:
I said, WE ARE NOT STAR.
 01:14
01:16 rurban_ joined
cotto ~~ 01:23
Coke, glad to hear it.
01:27 plobsing joined, theory joined 01:33 gbacon joined
dalek rrot: r48168 | gerd++ | branches/tt509_install_files:
Removed "tt509_install_files" branch from the repository. Solved in r48115. The according Ticket #509 is closed.
 01:39
01:40 Chandon joined
dalek TT #1714 created by sng2nara++: in OSX snow leopard, Configure.pl stops on step#29 auto::va_ptr 01:42
TT #1714: trac.parrot.org/parrot/ticket/1714
01:59 s1n joined
dalek kudo: 93ec069 | util++ | (3 files):
Added Ingy to CREDITS; made contributors.pl work with UTF-8 and ignore fake
 02:00
kudo: 40bf707 | Coke++ | docs/release_guide.pod:
stresstest runs spectest also - don't need it 2x.
 02:12
kudo: d1cd713 | Coke++ | (3 files):
Merge branch 'master' of github.com:rakudo/rakudo
Coke blog.chromium.org/2010/07/release-e...often.html #chromium adopting six-week release schedule. 02:22
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:37
atrodo that's not a good sign 02:46
kid51 must sleep 03:09
purl $kid51->sleep(8 * 3600);
03:32 janus joined
dalek rrot: r48169 | Chandon++ | branches/gsoc_threads/t/pmc/task_primes.t:
[gsoc_threads] Now with less blatantly wrong code.
 04:15
website: Chandon++ | Green Threads: A Classic Example 04:21
website: www.parrot.org/content/green-thread...ic-example
Coke rakudo release #31 complete. 04:22
04:54 magnachef joined 04:55 AndyA joined 05:05 darbelo joined 05:46 jsut joined
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:05
06:10 uniejo joined 06:20 fperrad joined
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.
(and yes, major version bumps have varying meaning) 06:24
darbelo Even an 8 bit integer has room to carry them through the next 15 years of development. 06:26
If 64 bit adoption keeps up, they won't have to worry about running out any time soon. 06:27
cotto I'll start to worry if they release v -127.0 06:30
06:50 lucian joined
sorear that would be very worrying, yes 06:54
who uses one's complement anymore?
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, bacek joined 07:43 baest joined, bacek joined 08:13 theory joined 08:21 slavorgn joined 08:40 jsut_ joined 08:41 squeeks joined
nopaste "squeeks" at 192.168.1.3 pasted "Trying to install Rakudo/Parrot, and failing...." (23 lines) at nopaste.snit.ch/22231 08:42
cotto bacek, have you given any thought to how Lorito should support advanced control flow?
moritz is lorito supposed to CPS? 08:47
*to be
cotto that's an open question
sorear Perl 6 needs either CPS or explicit delimited continuations 08:53
cotto Sure. The question is whether Lorito will support it directly or indirectly. 08:54
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.
existing PIR code, that is 08:56
If Lorito doesn't support it directly, it'll be supported by the (or a) PIR->Lorito layer. 08:59
GeJ CPS? 09:04
purl i think CPS is continuation passing style
cotto continuations?
purl continuations are like a two way setjmp
09:04 squeeks left
sorear delimited continuations? 09:04
purl, delimited continuations? 09:05
purl sorear: wish i knew
moritz delimited continuations are likely NYI :-)
cotto sleep?
purl but if I close my eyes they will come and gouge my eyes out with brass plated spoons
cotto I was going to go to sleep, but perhaps that's not a safe option.
night 09:06
GeJ servus cotto. 09:07
09:08 sri joined 09:16 rurban_ joined 09:50 gbacon joined 10:07 hanekomu_9 joined 10:16 JimmyZ joined
dalek kudo: bc3e181 | (Solomon Foster)++ | src/core/Int.pm:
Reimplement infix:<div> to use pir::fdiv. tylercurtis++.
 10:54
11:03 bacek joined 11:19 AndyA joined
dalek kudo: 4bf6c0f | moritz++ | src/core/ (2 files):
return Perl 6 strings from substr and join. Patch courtesy of felliott++
 11:48
11:53 khairul joined 12:06 whiteknight joined 12:13 cognominal joined 12:16 snarkyboojum joined
whiteknight good morning, #parrot 12:28
12:35 Casan joined 13:00 macroron joined 13:16 bacek joined
kthakore whiteknight: morning 13:17
morning bacek
atrodo good morning 13:23
purl Lies!
dalek kudo: 8c8b656 | Coke++ | docs/release_guide.pod:
add perl6-compiler, which masak++ noted was missing.
 13:31
kudo: b2af272 | Coke++ | src/core/ (3 files):
Merge branch 'master' of github.com:rakudo/rakudo
13:34 [1]Casan joined 13:54 [1]Casan joined 14:00 bubaflub joined, bubaflub left 14:02 bacek joined 14:53 gbacon joined 15:04 bubaflub joined
sri does parrot support non blocking sockets these days? 15:06
15:07 bubaflub joined 15:09 Casan joined 15:25 [1]Casan joined 15:26 bubaflub joined 15:29 Casan joined
dalek tracwiki: v138 | gerd++ | Languages 15:30
tracwiki: trac.parrot.org/parrot/wiki/Languag...ction=diff
15:31 davidfetter joined 15:45 zostay joined 16:14 eternaleye joined 16:24 theory joined 16:29 whiteknight joined
moritz rt.perl.org/rt3/Ticket/Display.html?id=76692 16:31
16:33 bacek joined 16:40 PacoLinux joined 16:41 davidfetter joined
atrodo gist.github.com/487681 # Hurray! Lorito can now have and pass tests 16:47
16:47 bacek joined 17:10 theory joined 17:16 rurban_ joined
cotto It'd good to be capable of test-have. 17:26
atrodo test-have? 17:27
17:27 preflex joined 17:31 tcurtis joined 17:37 japhb joined
cotto_work ~~ 17:50
hrwiki.org/wiki/imaginary#Transcript (look for friend-have if you feel the reference is worth figuring out) 17:52
18:00 macroron joined
atrodo :D homestarrunner++ 18:01
18:08 theory joined
particle atrodo: i'd call the lorito files whatever.ito instead of whatever.lor 18:12
sounds, well, more onomatopoetic. but that's just me. 18:13
cotto_work gets flashbacks to the OJ Simpson trial
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:15
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:18
particle thinks. 18:19
cotto_work thanks
atrodo particle> I've got no problem with ito files. I may just start doing that by default 18:20
cotto_work ridiculousfish.com/blog/archives/20...-optimize/ (happy fun quiz time) 18:22
18:30 AndyA joined
whiteknight there's no reason the file extension needs to be 3 characters 18:39
.lorito would be just fine in my book
atrodo it's also, i'd imagine, be temporary 18:40
moritz you mean, like IMCC?
atrodo touche
cotto_work A three letter extension appeals to my laziness though. 18:41
but this is another bikeshed that's best painted by the person building it 18:42
Tene There are some filesystems where extensions are special, iirc. 18:45
Is "old-school DOS" a supported parrot platform? ;)
18:47 chromatic joined
chromatic Lorito should be able to get away with a branch op, and that's what it needs to support CPS. 18:47
cotto_work That'd explain why allison didn't mention anything further. 18:50
18:51 bacek joined
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
We can do that.
cotto_work I guess so. That makes sense if we're trying to have Lorito be equivalent to C.
chromatic M0 needs to be sufficient to replace C. 18:53
cotto_work How many other levels do you see?
chromatic Our existing ops are M1. 18:55
Some combo ops (such as fetch/vivify) can be M2.
From the perspective of the runloop, everything is M0. 18:56
From the perspective of the JIT, everything is M0.
cotto_work that fits the mental model I've been using
chromatic From the perspective of people writing code, everything is M1 .. Mn, where n is "Whatever's most convenient."
atrodo What about the idea of having M1 be composed M0 ops? 18:57
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?
cotto_work inner runloops happen becase we have both PIR and C. If everything's M0, that problem goes away. 18:59
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:00
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?
chromatic sets the curtains on fire
atrodo Fire! Fire!
cotto_work atrodo: we
'll need a way to call C functions. 19:02
chromatic I'd rather have some sort of coroutine system for embedders. 19:03
chromatic sets the ceiling on fire
atrodo Water! Water!
moritz sing an auld irish drinking song in which a burning ceiling plays a certain part
cotto_work wonders
also, lunchtime
moritz www.thebards.net/music/lyrics/Old_Dun_Cow.shtml 19:04
atrodo how feasible are coroutines in c? 19:05
19:05 fperrad joined
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
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.
... without having to start a new runloop.
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
Coke chromatic: you follow the rakudo speedup that occurred before the release yesterday? 19:07
(all in rakudo. no parrot)
moritz it was more of an un-slowdown than a speedup :/
chromatic I backlogged.
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?
or something?
purl something is really wrong out there :)
moritz forget something
purl moritz: I forgot something
tcurtis Coke: and then another one today thanks to fdiv_n_n_n.
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.
Something like:
1) fire and forget
2) fire and get callbacks
19:09 theory joined
chromatic 2) fire and get callbacks which call back into Parrot 19:09
I mean 3) fire and get callbacks which call back into Parrot
4) Launched from Parrot, then call back into Parrot
5) Launched from Parrot, call into C
6) Launched into Parrot, called into C, calls callbacks into Parrot, may call into C again 19:10
7) a pony
tcurtis Coke: changing Rakudo to use it was a hll-only speedup.
particle ponies aren't dynamic enough. we want magic unicorns! 19:11
atrodo The new white meat!
tcurtis particle: unicorns aren't dynamic enough either. They have to be able to shape-shift.
particle MAGIC! 19:12
atrodo clearly, unicorns can shape-shift. Have YOU ever seen one?
chromatic Unicorns must have ninja powers.
Coke tcurtis: ah, I thought it involved changing the op. 19:14
just a functional chameleon circuit.
tcurtis Coke: fdiv_n_n_n works fine. fdiv_i_i_i is the broken one.
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?
chromatic Essentially.
particle exceptions are also like snowflakes 19:16
purl okay, particle.
atrodo so to catch an exception, you insert a continuation object into the continuation stack?
or am i making stuff up?
chromatic You're making stuff up. 19:17
atrodo Hurray!
chromatic I don't like the current mechanism of exception handlers.
(and CPS means that there's no stack of continuations; it's a graph) 19:18
atrodo How would you do it instead?
atrodo goes to read more CPS info
chromatic Every context has an optional slot for "If there's an exception, try catching it with *this*."
(in my ideal world) 19:19
That *this* is an exception handler, which is itself a continuation.
atrodo so, do context != continuations?
chromatic If it declines to handle that exception, it walks up its own chain of exception handlers until it finds the right one.
conexts and continuations could be the same thing; I haven't thought enough about that yet 19:20
If no exception handler can handle the exception, KAPOW 19:21
execution ends
If an exception handler handles the exception and decides to resume, YOING
YOINK
execution resumes at the appropriate point by invoking the exception's RESUME somehow
chromatic waves his hands and puts out the flaming ceiling
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
chromatic If an exception handler handles the exception and decides to resume execution elsewhere, MEH
execution resumes elsewhere.
Now things get complicated if you need to do CPS unchaining (or, as they like to call it in the Lisp world, stack-unwind).
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
So you have to keep track of the right information and you have to exit all of those contexts for cleanup or something.
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.
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
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.
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
I'm fairly sure Perl 5 on Parrot will need it.
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
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:26
if it can't, it continues down the exception chain 19:27
how far from that is what we're trying to do here?
chromatic Similar ideas. 19:28
dalek kudo: 4195e9a | moritz++ | src/Perl6/ (2 files):
disallow parsing of adverb form in quotes that we can't handle yet
 19:34
kudo: f196e88 | moritz++ | src/ (3 files):
Merge branch 'subst_adverbs'
19:35 [1]Casan joined
atrodo I suspect we can do something much cleaner and simpler in lorito than we have now in parrot 19:38
chromatic Indeed. 19:40
19:40 Andy joined
cotto_work Lorito wouldn't be worthwhile otherwise. 19:40
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.
cotto_work chromatic, have you given any thought to how Lorito's longjmp equivalent would be implemented? 19:42
Does it imply a stack-based Lorito?
chromatic As far as I can tell, it's just "invoke this invokable"
Coke chromatic: here's hoping it does at least one more thing. 19:43
chromatic No stack just necessary.
dalek tracwiki: v65 | moritz++ | ParrotQuotes
tracwiki: escape routes if vampires are approaching
tracwiki: trac.parrot.org/parrot/wiki/ParrotQ...ction=diff
chromatic invoke may have to switch bytecode segments, but that's just pointer swapping 19:45
Otherwise it's "Okay, the runcore goes over here for a while then" 19:46
cotto_work Is there something that works similarly that I can read up on? 19:47
chromatic Which part of it is confusing?
cotto_work How invoking an invokable is sufficient to implement all the types of control flow we need to simulate. 19:48
nm. That's cps. 19:49
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 trac.parrot.org/parrot/wiki/LoritoD...nQuestions ?
atrodo Does that solve exceptions?
19:51 cognominal joined
Chandon The way Parrot works now I can swap green threads between arbitrary instructions. How does that work in Lorito? 19:51
cotto_work atrodo: CPS allows exceptions 19:52
chromatic Chandon, pmichaud and I think we need to find sequence points in M0.
Chandon (I can, conceptually, swap green threads between arbitrary instructions. In practice there's some weirdness in some cases.)
Coming up with sequence points that break all potential compute loops is sort of annoying. 19:53
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.
atrodo so, in CPS, do you pass a "if you have an exception, use this continuation"? 19:55
chromatic I'd attach it to the context, but effectively yes. 19:57
atrodo so, effectively, we'd have a continuation graph and an exception graph? 19:58
chromatic Yeah, everything we might need to invoke to leave the current execution context needs a graph. 19:59
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:02
chromatic Invoke passes a return continuation as a parameter (in bound or out of bound) 20:03
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:04
20:05 bacek joined, theory joined
atrodo so all continuations are parameters? Or is there a special default return continuation? 20:05
whiteknight there is a return continuation in a call 20:06
It's stored in the current context, I believe
chromatic By "return continuation", we mean "Invoke this when you want to return normally"
whiteknight right. It's the thing that the .return() directive invoktes
invokes
atrodo okay, that makes sense 20:07
whiteknight you could invoke anything you wanted at that point to leave the current Sub, however
(though another Sub call would attempt to return back there)
atrodo right
whiteknight Lorito is going to have to pass the return continuations explicitly, unlike current PIR which assumes their use internally 20:08
chromatic Right.
whiteknight if lorito can communicate directly with C functions, then we can't just blindly be passing return continuations to every function we call
Though I do advocate for some sort of shorthand to differentiate, for sanity 20:09
"call this Parrotish function" as opposed to "call this Cish function"
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?
whiteknight atrodo: in classic CPS, all functions are called as foo(retcont, args)
where the return continuation is the first argument to the function
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
atrodo: what is "default"?
purl "default" is "-net 0.0.0.0"
atrodo return continuation that is set in the context 20:12
cotto_work forget "default"
purl cotto_work: I forgot "default"
whiteknight atrodo: where does the return continuation know to return to, if it hasn't been constructed in the Caller's context?
you need to construct the return continuation in the caller's context, and pass it to the callee
chromatic atrodo, there is no "return" operation which pops an address off of the stack then branches there.
whiteknight in Parrot, the PCC system does this automatically for "normal" sub calls, but that's just a nicety
the invokecc opcode is short for "invoke this CPS function, but automatically create a return continuation for me" 20:13
the invoke opcode requires you to explicitly pass the continuation, and is more like "normal" CPS
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.
whiteknight but yes, in this case it's the context 20:17
atrodo okay. Had me confused there for a little bit
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
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:19
chromatic There's always one return continuation passed in. 20:21
A function may take one or more continuations as regular arguments (from the HLL perspective).
atrodo so the graph is composed with the one return continuation plus the rest of the continuation pass as regular arguments? 20:22
chromatic The graph is the control flow up to the current invocation. 20:23
It's like stack frames in a stack based language.
Coke "will lorito have a stack". Oh, the hilarity that will ensue. 20:24
cotto_work The longjmp analogy threw me off. 20:26
whiteknight longjmp basically is a continuation
a stupid, limited continuation in C
atrodo s/C/asm/ 20:27
whiteknight yeah, you can do it from asm too
I was talking about the stdlib function mostly, since it saves processor state
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
cotto_work atrodo: you can use it as a pessimization: thedailywtf.com/Articles/Longjmp--F...ED!!!.aspx 20:29
whiteknight ha, I loved that article
atrodo haha, nice 20:30
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".
maybe we need a do-nothing sequence point op. 20:32
or at least a flag
whiteknight I'm not sure I understand why we would want sequence points at all
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:33
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.
atrodo whiteknight> first time I did that on my 386, i discovered the cache 20:35
whiteknight chromatic: depends on the op 20:38
cotto_work We have space for a flag. 20:39
whiteknight anyway, I've got to head home. Later
tcurtis CLI/STI? 20:40
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"
cotto_work That's a lot of potential extra ops. 20:43
good names though 20:44
tcurtis Well, body_of_op is a place-holder. :)
chromatic Or maybe we don't have a runloop for M0 and our runloop is only M1 .. Mn. 20:45
cotto_work chromatic: wouldn't that preclude optimizing across M0 ops? 20:53
atrodo you can still unroll
chromatic I don't know. 20:55
Coke I thought part of the point was having our runloop be at M0.
(what does M stand for?)
atrodo (Magic) 20:56
chromatic microcode layer
cotto_work I like that. At M0, there's no magic. At M1, there's a little. At M5, there's Rakudo.
chromatic Magic Level 20:57
That means Fireball is in M3, and Minor Wish is M7.
particle what level is The Flying Dutchman? 21:02
chromatic That's a Unicode character, not an op.
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
cotto_work atrodo: it gets exponentially more magical. 21:03
M6 is dtrt
tcurtis I presume that at Mn for some n, there is only a DWIM op with no arguments?
atrodo Ah ha! Makes perfect sense now
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.
cotto_work It has no ops. It doesn't need them. 21:05
It's the Chuck Norris of dynamic languages.
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.
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
Clearly M6 and up are fanfic ops.
cotto_work 65536 registers ought to be enough for anybody 21:13
21:15 Andy joined
particle so add a byte for magic! 21:16
store security info there, or other metadata
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
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?
cotto_work TT?
purl i heard TT was template toolkit or www.template-toolkit.org/ or #tt or usually n0t Text::Template or TrueType (usually: TTF) or toula toukarev
Coke #1127 21:22
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. =-)
danke. Now that I have a linux box that I can run *grind on, I'd like to start profiling rakudo a bit. 21:24
21:26 ilia joined
cotto_work Coke, if you can come up with a reasonably small snippet that's broken, I can add a test case. 21:29
(for profiling) 21:30
(and now that I've been away from that code for a while, I'll be better able to see its warts) 21:32
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:46
chromatic That's how I see it, yes. 21:48
cotto_work wfm
atrodo huh, not the road i had started down 21:50
cotto_work Is there something like a consensus on that?
chromatic Apart from "Call this C function", what other control flow is necessary? 21:51
21:51 whiteknight joined
cotto_work atrodo: what do you mean? 21:55
22:02 ilia joined 22:10 gbacon joined
dalek tracwiki: v11 | cotto++ | LoritoDesignQuestions 22:14
tracwiki: CPS et. al. will be on top of Lorito, not part of it
tracwiki: trac.parrot.org/parrot/wiki/LoritoD...ction=diff
cotto_work Coke: is there a nice way to whittle down bugs exposed by partcl? 22:26
An empty tcl program shows the bug nicely, but it's not clear how to cut partcl down. 22:28
also, pbc_dump segfaults on tcl.pbc
might need to fix that
probably a dynop thing 22:29
nm. works fine without -d
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
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).
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
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.
chromatic The new approach sounds more reasonable. 22:46
tcurtis leaves. 22:52
23:10 bacek joined
cotto ~~ 23:38
23:40 snarkyboojum joined
Coke cotto_work: I thought one line of tcl was pretty small. :P 23:53
old school partcl is even less amenable to "convert this to a standalone PIR snippet." than current partcl-nqp 23:55
I'll see what I can do.
cotto zero lines of tcl is small too.
23:57 Psyche^ joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!