Camelia, the Perl 6 bug

IRC log for #parrot, 2011-02-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:01 Andy left #parrot
00:02 bacek_at_work auto::pcre -          Does your platform support pcre...............yes, 8.02.
00:02 bacek_at_work on my box
00:02 bacek_at_work linux/i386/c++ with optimize
00:02 bacek_at_work test passed...
00:02 cotto_work ship it
00:02 bacek_at_work cotto_work, it's "shipped"
00:02 whiteknight chromatic pwnd my github dashboard
00:03 cotto_work It's not on a ship.  It's not shipped.
00:07 davidfetter left #parrot
00:09 cotto_work github's new file browser is really nice
00:14 mikehh left #parrot
00:14 tadzik slp &
00:17 janus left #parrot
00:19 dukeleto cotto_work: i dig it
00:33 cotto they're going nuts hiring recently
00:33 cotto makes me wish I lived in sf and cared about ruby
00:34 Tene cotto: The company I'm working for in mountain view is hiring, and doesn't use ruby.
00:34 Tene I expect the other condition also applies, though
00:35 cotto very much so, and I already have a job I'm happy with
00:35 Tene If anyone here happens to know any sysadmins in the bay area that want work, we very much need another good sysadmin.
00:36 cotto I love hearing about tech companies that are hiring.
00:37 Tene Our operations code is all in perl.  The original ops people treated it like an awkward bash, though, so I've been doing a lot of cleanup.
00:38 Coke left #parrot
00:38 cotto allison, I don't see your PhD paper in my inbox.  Could you re-send it?
00:52 mikehh joined #parrot
00:53 whiteknight my company is hiring like crazy. C# devs in philly
00:54 cotto mine too, though most PHP folks probably aren't hanging out on #parrot
00:59 cotto statistically there'll only be one, so I'm it
00:59 NotFound left #parrot
00:59 Tene cotto: we've had other php guys in the past, I thought
01:00 NotFound joined #parrot
01:02 cotto I haven't seen barney in a while.
01:02 whiteknight me either
01:09 plobsing joined #parrot
01:11 lucian left #parrot
01:13 nopaste "kid51" at 192.168.1.3 pasted "generational_gc branch no longer builds on darwin/ppc" (825 lines) at http://nopaste.snit.ch/31256
01:14 kid51 ... which is surprising, because up until today it was building there, albeit with some test failures when configured with --optimize
01:19 kid51 Trying again ...
01:20 kid51 I think the failure was with "all gcc", which is not the way I usually configure on darwin/ppc
01:24 whiteknight is there any reason why interp->ctx would be 0x200?
01:27 whiteknight oh nevermind, my mistake
01:30 whiteknight blah. this imcc branch is a huge pain in the ass
01:45 dmalcolm left #parrot
01:52 jsut joined #parrot
01:54 Hackbinary I have  a question about pod linking in the documentation: how should it be done?
01:54 Hackbinary because the generators are autolinking it cpan
01:55 Hackbinary should I just code it to go github, or to parrot.org?
01:56 jsut_ left #parrot
01:58 whiteknight github, I think
01:58 kid51 whiteknight: I feel your pain.  It's not building even on plain vanilla linux/i386 (or, at least it wasn't several hours ago)
01:59 whiteknight kid51: my branch?
01:59 Hackbinary github it is :)
01:59 kid51 the compreg branch
02:10 kid51 Is it no longer possible to configure Parrot with g++?
02:10 kid51 Was it ever?
02:10 kid51 In master, if I say:
02:10 kid51 CXX='g++';echo $CXX
02:10 kid51 perl Configure.pl --cc=$CXX
02:11 kid51 ... I get massive failures before I'm even out of configuration
02:11 kid51 And, where did our --cxx option go to?
02:11 kid51 I can no longer find any place in the configuration system where it is assigned from
02:15 whiteknight kid51: yeah, the branch is in flux. You may want to avoid testing it for the next few days
02:26 Coke joined #parrot
02:29 mtk left #parrot
02:36 dalek parrot/whiteknight/imcc_compreg_pmc: b7dac65 | Whiteknight++ | / (4 files):
02:36 dalek parrot/whiteknight/imcc_compreg_pmc: in Parrot_ext_try, cache the current context, and make sure to go back to it when we are done. This solves an infinite loop problem I was seeing earlier. In inter_create, set interp->ctx to NULL because PMCNULL hasn't been initialized yet so it's just garbage.
02:36 dalek parrot/whiteknight/imcc_compreg_pmc: review: https://github.com/parrot/parrot/commit/b7dac6530e
02:36 dalek parrot/whiteknight/imcc_compreg_pmc: 93a0088 | Whiteknight++ | / (3 files):
02:36 dalek parrot/whiteknight/imcc_compreg_pmc: use the same callin/callout mechanism for the IMCC API as for the normal embedding API. This makes correct error handling much easier. Also, remove the Parrot_x_jump_out_error function. IMCC can jump out now by throwing a normal exception. Through the API it has the API error handling mechanism. Through the compreg it has the normal Parrot exception handling system
02:36 dalek parrot/whiteknight/imcc_compreg_pmc: review: https://github.com/parrot/parrot/commit/93a00888be
02:36 dalek parrot/whiteknight/imcc_compreg_pmc: 6620d5f | Whiteknight++ | / (5 files):
02:36 dalek parrot/whiteknight/imcc_compreg_pmc: fix the frontend to use the new IMCC API functions. almost build again
02:36 dalek parrot/whiteknight/imcc_compreg_pmc: review: https://github.com/parrot/parrot/commit/6620d5f035
02:36 whiteknight left #parrot
02:36 mtk joined #parrot
02:38 wknight-phone joined #parrot
02:38 dalek TT #2004 created by jkeenan++: Where did Configure.pl option '--cxx' go to?
02:38 dalek TT #2004: http://trac.parrot.org/parrot/ticket/2004
02:40 mikehh kid51: I am not sure I follow that - I use it
02:40 mikehh kid51: base config -> date && time perl Configure.pl --test --cc=g++ --cxx=g++ --link=g++ --ld=g++ (plus maybe other options)
02:48 kid51 mikehh:  Yes, on Darwin/PPC, I've used '$CX=g++;perl Configure.pl --cxx=g++' for years
02:48 kid51 But where does that option get used inside the configuration system?
02:48 Tene kid51: what shell is that?
02:48 kid51 bash
02:48 Tene that... won't do anything to influence the run of Configure.pl
02:49 kid51 Tene: Set aside that shell question.
02:49 Tene except probably error, unless $CX is already set to something
02:49 kid51 I'm getting this on Linux/i386 were I simply use perl Configure.pl
02:49 Tene 'k
02:49 Tene I haven't been following anything else going on; that just stood out as notable to me.
02:50 kid51 Show me where (right now) we take that command-line option and use it to say "Use this value as your c++ compiler"
02:56 allison cotto: yah, I composed an email message to resend, just in case I didn't CC you when I sent it to whiteknight a few months ago... sending now
02:59 wknight-phone left #parrot
03:01 dukeleto ~~
03:02 dukeleto kid51: i may be able to attend the python event, don't remember the exact time
03:04 wknight-phone joined #parrot
03:05 kid51 dukeleto:  Appears to be a day-long event starting at 9:00 am.
03:07 dukeleto kid51: i don't do 9am
03:08 dukeleto kid51: if you know what you want me to say to prospective python devs, I can orate that
03:15 kid51 dukeleto:  Just pass along what I posted on parrot.org.
03:15 kid51 or consult with Allison
03:19 dukeleto kid51: that doesn't really cut it
03:19 dukeleto kid51: there is no infrastructure
03:20 dukeleto kid51: there is no plan
03:20 dukeleto kid51: who is the goto person for python-on-parrot ?
03:20 dukeleto kid51: is there a spec ?
03:20 dukeleto kid51: which repo does python on parrot live in?
03:20 dukeleto kid51: without those things figured out before that meeting, nothing will happen
03:21 kid51 dukeleto:  Fine, then don't go.
03:22 kid51 It's up to the python people who want to build on parrot to formulate their own plan of action
03:22 kid51 I'm just trying to encourage them.
03:22 kid51 I spent two hours with a Python developer Tuesday night.
03:23 kid51 He was already ahead of me.  He had been IMing with Allison and Lucian the previous night ... on this channel!
03:33 dukeleto kid51: i didn't say I wasn't going to go. I am just telling you that not having some basic infrastructure setup is going to seriously hamper stuff happening
03:33 dukeleto kid51: who is this person you are talking about?
03:42 benabik joined #parrot
03:45 particle1 joined #parrot
03:50 particle left #parrot
03:54 cotto kid51, I've been configuring for a c++ build with --cc=g++ --link=g++ --ld=g++ and it's definitely using g++ as the compiler.
03:54 cotto I don't remember --cxx ever being required.  It might be a fossil from the bad old days when icu was included in svn.
03:55 kid51 cotto: Back in late 2006, I was having problems compiling on Darwin/PPC
03:55 kid51 coke gave me this shell script which I've used ever since
03:57 kid51 It assigns: $CX="/usr/bin/g++", and then calls perl Configure.pl --cc="$CC" --cxx="$CX" --ld="$CX" --link="$CX"
03:57 kid51 So, I assume from that -- and from the presence of 'cxx' in the Options modules -- that at one point it was meaningful
03:58 kid51 The only thing that prompted me was the problems I'm having today on generational_gc on darwin/ppc ...
03:58 kid51 ... when by accident I called 'perl Configure.pl' by itself once, outside of my shell script
04:00 kid51 I believe that in 'master', I can simply run 'perl Configure.pl' on Darwin/ppc ... but that isn't working in generational_gc
04:00 kid51 ./parrot-nqp --target=pir runtime/parrot/library/YAML/Tiny.pm > runtime/parrot/library/YAML/Tiny.pir
04:00 kid51 src/gc/gc_gms.c:2177: failed assertion '!PObj_on_free_list_TEST(pmc)'
04:00 kid51 make: *** [runtime/parrot/library/YAML/Tiny.pir] Error 134
04:00 * kid51 must sleep
04:01 cotto 'night
04:05 dukeleto cotto: are you thinking about m0 stuff?
04:09 cotto usually
04:09 cotto dukeleto, did you have an idea?
04:11 cotto seen chromatic
04:11 aloha chromatic was last seen in #parrot 9 days 6 hours ago leaving the channel.
04:14 hercynium joined #parrot
04:15 kid51 left #parrot
04:15 dukeleto cotto: i saw chromatic last night :)
04:15 dukeleto cotto: yes, i did have an idea. It hurt.
04:15 dukeleto cotto: have you looked at my lorito branch
04:16 cotto not recently
04:16 dukeleto cotto: i need help with defining the internals of LoritoContextPMC
04:17 cotto dukeleto, What's your current sticking point?
04:19 dukeleto cotto: needing a way forward
04:19 dukeleto cotto: do you remember our meeting when allison said that implementing "print 42" in M0 is our first prototype?
04:19 dukeleto cotto: what do we need in M0 to implement "print 42" ?
04:20 cotto I'm glad you remembered that.  For some reason it didn't stick with me.
04:22 cotto op definition, op encoding, parser for textual M0, basic runloop, set of registers, pc
04:22 cotto way to deal with int constants
04:24 cotto default (or explicit) entry point for ops
04:25 cotto Is there anything else you can think of?
04:26 dukeleto cotto: lets ignore encoding for now. It will be simple to add later
04:26 dukeleto cotto: what do you mean by "op definition" ?
04:26 cotto "When you see 'print', here's what you do with the arguments."
04:27 cotto i.e. what lives in .ops files currently
04:27 wknight-phone left #parrot
04:28 dukeleto cotto: so we need a "print" M0 op, correct?
04:31 cotto definitely
04:33 * dukeleto will add it
04:35 dalek parrot/m0spec: 2e1618c | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
04:35 dalek parrot/m0spec: Add print and set as M0 ops
04:35 dalek parrot/m0spec: review: https://github.com/parrot/parrot/commit/2e1618c55c
04:39 dukeleto cotto: arg, i accidentally created a new branch. fixing.
04:40 dalek parrot/m0-spec: 2e1618c | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
04:40 dalek parrot/m0-spec: Add print and set as M0 ops
04:40 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/2e1618c55c
04:40 dukeleto cotto: fixed.
04:41 dukeleto cotto: define "basic runloop"
04:42 cotto read an op and args, lookup/run the right bit of code, increment the pc if it hasn't changed, repeat
04:44 dukeleto cotto: that is our killer feature for lorito right now. We need a functioning runloop
04:44 dukeleto cotto: can you add details about what a functional runloop is to the spec?
04:44 cotto dukeleto, yes I can.
04:45 cotto dukeleto, what magic do I need to invoke so that git will pull the current branch when I say git pull?
04:46 dukeleto cotto: i will humbly suggest git pull --rebase
04:51 cotto dukeleto, that still asks which branch I want to pull from
04:53 sorear cotto: fix your .git/config
04:54 cotto do I need to do that for each branch I'm playing with?
04:55 sorear no
04:55 sorear you can edit .git/config with wildcards
04:57 dukeleto cotto: gist the error that you get
04:57 dukeleto cotto: which version of git?
04:57 cotto https://gist.github.com/821942
04:58 cotto 1.7.1
04:59 dukeleto cotto: what does this mean ? https://gist.github.com/821943
04:59 dukeleto cotto: you forgot --rebase
04:59 dukeleto cotto: git pull does a merge
04:59 dukeleto cotto: git pull -rebase does a rebase
04:59 dukeleto cotto: you can also do "git fetch --all"
04:59 dukeleto cotto: then a git rebase origin/master
04:59 dukeleto cotto: or whatever branch it is
04:59 dukeleto cotto: you can also do "git fetch origin"
04:59 dukeleto cotto: fetch only operates on the index
05:00 dukeleto cotto: pull operates on the working copy
05:00 cotto dukeleto, looks like you need to include the generated pmc header somewhere
05:01 cotto is that in your lorito branch
05:01 cotto ?
05:03 cotto if the lorito ops are dynops, nothing that links into libparrot should be using its attr accessors directly
05:03 * cotto got confused
05:05 cotto looks like some pmc2c lameness
05:06 dukeleto cotto: yes, that is in my lorito branch
05:06 dukeleto cotto: i am trying to make it compile
05:07 dukeleto baby steps...
05:07 cotto the code is trying to access ATTRs that aren't defined
05:08 cotto e.g. there's no ATTR declaration for to_ctx
05:08 dalek parrot/lorito: 385209c | dukeleto++ | src/pmc/loritocontext.pmc:
05:08 dalek parrot/lorito: Make stuff compile. Linking still fails
05:08 dalek parrot/lorito: review: https://github.com/parrot/parrot/commit/385209c9a5
05:08 dukeleto cotto: yes, i am cargo culting
05:08 cotto that's the best kind of cult
05:09 cotto though to be fair, the other kinds aren't very good at all
05:13 dalek parrot/luben/gc_gms_dyn_threshold: 6f6c95b | luben++ | src/gc/gc_ (2 files):
05:13 dalek parrot/luben/gc_gms_dyn_threshold: port dynamic threshold to gc_gms
05:13 dalek parrot/luben/gc_gms_dyn_threshold: review: https://github.com/parrot/parrot/commit/6f6c95b3ff
05:14 dukeleto cotto: where am I supposed to put ATTR definitions?
05:14 cotto dukeleto, after the pmclass declaration
05:14 cotto you've already got a bunch there
05:15 cotto starting at line 55
05:16 bacek_at_work luben, this is wrong:
05:16 bacek_at_work -    interp->gc_sys->stats.mem_used_last_collect             = 0;
05:16 bacek_at_work 833
05:16 bacek_at_work +    interp->gc_sys->stats.mem_used_last_collect             = interp->gc_sys->stats.memory_used;
05:16 bacek_at_work (for GenGC)
05:17 luben stats.memory_used is not the whole memory?
05:18 bacek_at_work luben, it is
05:18 bacek_at_work But for triggering nursery collections we don't have to know it
05:18 bacek_at_work we need size of _nursery_
05:19 bacek_at_work stats.memory_used can be trigger for collecting oldest generation
05:19 dukeleto cotto: i think you didn't create a tracking branch
05:19 dukeleto cotto: when creating a new branch, do "git checkout -b foo origin/foo"
05:20 cotto hmmm.  I thought I was in the habit of doing that.
05:20 luben as it is now it is triggered by the total alocated size
05:20 dukeleto cotto: and then git will know that local branch foo is supposed to push to foo on origin
05:20 dukeleto cotto: cat .git/config and gist it
05:20 bacek_at_work dukeleto, of just use modern git which will do it automatically :)
05:20 bacek_at_work luben, in MS2 - yes, in GMS - no.
05:20 dukeleto cotto: that is what i am doing. modern gits don't need -t
05:20 dukeleto cotto: but you do need to tell it that you are trackign origin/foo when you branch :)
05:21 dukeleto bacek_at_work: ^^^
05:21 * dukeleto misfired
05:21 dukeleto cotto: you should have : [branch "m0-spec"] remote = origin merge = refs/heads/m0-spec
05:21 dukeleto cotto: in your .git/config, with the appropriate newlines
05:22 dalek parrot/lorito: f75b446 | dukeleto++ | src/pmc/loritocontext.pmc:
05:22 dalek parrot/lorito: Make LoritoContext PMC compile
05:22 dalek parrot/lorito: review: https://github.com/parrot/parrot/commit/f75b446b45
05:22 cotto dukeleto, thanks.  That worked.
05:22 dukeleto cotto: cool.
05:22 cotto dukeleto++
05:22 dukeleto cotto: LoritoContext PMC now compiles.
05:23 cotto dukeleto, so it does
05:24 dalek parrot/lorito: 8cbccce | dukeleto++ | / (2 files):
05:24 dalek parrot/lorito: Add a basic LoritoContext PMC test
05:24 dalek parrot/lorito: review: https://github.com/parrot/parrot/commit/8cbccce296
05:24 dukeleto cotto: we need the M0 spec to exactly spell out what a LoritoContext contains
05:24 dukeleto cotto: it is the secret sauce of M0
05:25 dukeleto cotto: we are close to getting "print 42" to work. I can smell it.
05:25 cotto dukeleto, I'm thinking about how important it is to maintain a distinction between M0 (ops and vm) and Lorito as a whole.
05:28 cotto M0 will be implemented several times for different purposes, but the higher-level pieces will only need to be implemented once.
05:29 dukeleto cotto: the spec is the most important thing
05:29 dukeleto cotto: my lorito branch is just a prototype usign dynops. That might be how we end up doing Lorito, or we may go another route
05:29 cotto right.  I'm thinking how (and if) the specs for M0 and Lorito should be separated.
05:29 dukeleto cotto: but the hammering out the spec is the most valuable thing right now
05:30 dukeleto cotto: i think M0 is the most important part of Lorito right now
05:30 cotto yes
05:30 dukeleto cotto: Lorito can't exist without M0
05:30 cotto that's the first thing we need to get right
05:30 dukeleto cotto: so we concentrate on the spec of M0 now
05:30 dukeleto cotto: and when we are in a position to worry about M1, we deal witht that
05:30 cotto It's also important to define what's not part of M0 though.
05:30 dukeleto cotto: for now, Lorito and M0 are essentially the same thing, until we figure enough stuff out
05:30 cotto and how those parts interact with M0
05:31 dukeleto cotto: yes, i agree. I think we can start an M1 spec document now, and add stuff to it that we know we don't want in M0
05:31 dukeleto cotto: it can be in the same PDD in another section
05:31 cotto wfm.
05:42 cotto dukeleto, I wonder if we should just say that M0 implementations need to do some hard-coding of Contexts.
05:44 hercynium left #parrot
05:47 dukeleto cotto: please explain
05:47 minusnine_ joined #parrot
05:49 cotto dukeleto, I'm thinking about how to get out of the "turtles all the way down" problem where eventually, something needs to be hard-coded.
06:00 bacek_at_work guys, invoke_cc is wrong for M0.
06:00 bacek_at_work It's better to be explicit on this level of what to invoke
06:01 bacek_at_work E.g. "Subs are identified by :subid"
06:01 bacek_at_work "invoke ctx, sub, continuation"
06:01 bacek_at_work etc
06:02 bacek_at_work otherwise will have same situation as now with "foo"("bar", "baz") in pir.
06:02 dukeleto bacek_at_work: i don't understand. Why shouldn't M0 have a invoke_cc ?
06:03 bacek_at_work cc stands for "current continuation"
06:03 bacek_at_work which is some magical variable stored somewhere
06:03 bacek_at_work E.g. interp->ctx->ccont
06:04 bacek_at_work and invokecc now set it to -1. And then Sub.invoke allocate Continuation if ctx->ccont == -1
06:04 bacek_at_work This is kind of magic we should avoid in M0.
06:04 bacek_at_work otoh, it can be implemented in M1+
06:05 dukeleto bacek_at_work: we get the current interp by looking at the current context in lorito, not the other way around
06:06 dukeleto bacek_at_work: LoritoContext PMC basically has everything that M0 needs
06:06 rurban_ joined #parrot
06:06 bacek_at_work dukeleto, it doesn't really matter. I want _explicit_ usage of everything on M0 level.
06:06 benabik left #parrot
06:06 dukeleto bacek_at_work: no global interp in M0
06:06 bacek_at_work dukeleto, replace interp->ctx->ccont with ctx->ccont.
06:07 dukeleto bacek_at_work: current context isn't a magic global
06:07 bacek_at_work it is
06:07 dukeleto bacek_at_work: there is an opcode to return the current context
06:07 bacek_at_work "current context" and "current continuation" are different :)
06:07 dukeleto bacek_at_work: yeah, i am conflating them a bit
06:07 bacek_at_work invoke_cc is invoke with current _continuation_
06:08 dukeleto bacek_at_work: isn't a context also a continuation ?
06:08 bacek_at_work dukeleto, I don't now. Maybe
06:08 cotto that's been part of the plan
06:08 bacek_at_work Can we have different "Continuations" for same context?
06:09 rurban left #parrot
06:09 rurban_ is now known as rurban
06:09 dukeleto bacek_at_work: we have a "new context" opcode
06:09 dukeleto bacek_at_work: that is a good question
06:09 bacek_at_work dukeleto, yes. But it's new context, not new current context
06:09 dukeleto bacek_at_work: our current problem is "how do we do 'print 42' in M0 ?
06:09 cotto bacek_at_work, you mean like an exception handler or something more generic?
06:09 bacek_at_work yes, exception handlers are good example
06:10 bacek_at_work "push_eh something". What is "something"?
06:10 bacek_at_work How many "somethings" we allow per context?
06:11 cotto what about either a sub or a label
06:11 bacek_at_work "sub" is?
06:11 bacek_at_work "label" is?
06:11 dukeleto bacek_at_work: currently, my LoritoContext is an invokable Context, with some extra junk
06:13 bacek_at_work dukeleto, it is one of the possible solutions.
06:15 dukeleto bacek_at_work: i am just trying to get the prototype to do something useful, so we can hone the spec
06:15 dukeleto bacek_at_work: i know I am doing hacky things
06:15 bacek_at_work indeed :)
06:15 dukeleto bacek_at_work: but i just want to get some basic functionality so we can make sure the spec is implementable
06:15 dukeleto bacek_at_work: ;)
06:15 bacek_at_work What if we split "invoke_cc" to Context.set_continuation + Context.invoke?
06:16 dukeleto bacek_at_work: i guess that is reasonable
06:16 bacek_at_work So, we can have something like:
06:17 bacek_at_work $ctx = new_ctx
06:17 dukeleto bacek_at_work: i was assuming that every opcode gets passed the current context, in addition to 3 arguments
06:17 bacek_at_work set_sub $ctx, subid
06:17 bacek_at_work set_cont $ctx, <offset>
06:17 bacek_at_work invoke $ctx
06:17 bacek_at_work dukeleto, we don't want to invoke current context
06:18 dukeleto bacek_at_work: sure, sounds fine to me. You want to update the m0-spec branch with that?
06:19 dukeleto bacek_at_work: the most important thing right now is improving our spec
06:19 dalek parrot/m0-spec: af8ae5e | cotto++ | docs/pdds/draft/pdd32_m0.pod:
06:19 dalek parrot/m0-spec: add a runloop definition
06:19 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/af8ae5e222
06:19 dalek parrot/m0-spec: 99d71f5 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
06:19 dalek parrot/m0-spec: add section for non-M0 topics
06:19 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/99d71f598e
06:24 cotto If every op gets the current context, what about using that for i/o?
06:24 cotto er, to determine what print prints to
06:29 cotto bacek_at_work, the role of :write in src/vtable.tbl in gen_gc should be documented.
06:29 bacek_at_work cotto, go for it :)
06:30 cotto d'oh
06:34 cotto bacek_at_work, can you think of someplace better than vtable.tbl?
06:35 bacek_at_work gs_gms.c also
06:35 cotto ok
06:38 dalek parrot/generational_gc: 6a76796 | cotto++ | src/ (2 files):
06:38 dalek parrot/generational_gc: add some docs on :write
06:38 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/6a76796239
06:44 ttbot Parrot 6a767962 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/8994
06:47 dalek parrot/generational_gc: dddb4ba | bacek++ | src/gc/gc_gms.c:
06:47 dalek parrot/generational_gc: Revert "Small optimizations for is_foo_ptr."
06:47 dalek parrot/generational_gc:
06:47 dalek parrot/generational_gc: Looks like it broke win32.
06:47 dalek parrot/generational_gc:
06:47 dalek parrot/generational_gc: This reverts commit 1880c15da798dae10cde05af63cb74d2ec6135a8.
06:47 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/dddb4ba9fc
06:55 cotto dukeleto, do you have any plans for yapc::na?
06:58 bacek_at_work Yay, green taptinder on ge_gc branch!
06:58 cotto good times
06:59 minusnine_ left #parrot
07:00 lateau joined #parrot
07:12 dalek parrot: 464fa68 | NotFound++ | src/ops/core (2 files):
07:12 dalek parrot: delete unused variable ccont in get_results op
07:12 dalek parrot: review: https://github.com/parrot/parrot/commit/464fa685b6
07:17 dalek parrot: b03561f | NotFound++ | src/extend.c:
07:17 dalek parrot: initialize curctx in the catch part of Parrot_ext_try
07:17 dalek parrot: review: https://github.com/parrot/parrot/commit/b03561f824
07:18 fperrad joined #parrot
07:26 jsut_ joined #parrot
07:31 jsut left #parrot
07:35 dalek parrot: 7055f69 | fperrad++ | runtime/parrot/library/distutils.pir:
07:35 dalek parrot: [distutils] restore get_nqp (for compat)
07:35 dalek parrot: review: https://github.com/parrot/parrot/commit/7055f69d0f
08:00 cosimo left #parrot
08:32 dukeleto cotto: yes, i plan on going to YAPC::NA, but haven't made tickets yet
08:33 cotto dukeleto, cool.  What about?
08:33 dukeleto cotto: also planning on YAPC::EU as well. so many confs
08:33 dukeleto cotto: you mean what talks will I submit?
08:33 cotto me too
08:33 cotto yeah
08:34 cotto pl/perl6, I'm sure
08:34 dukeleto i haven't given any talks about bioinformatics with open source tools
08:34 dukeleto but yeah, PL/Perl6 and some parrot talks too :)
08:34 dukeleto bioperl is pretty big
08:34 dukeleto in terms of the number of scientists that depend on it
08:35 cotto I have a dim idea of that.
08:35 dukeleto i think parrot has a lot of potential in the bioinformatics world, because biologist don't give a shit about programming languages
08:35 dukeleto they all re-implement the world in every dynamic language to do the same stuff
08:36 dukeleto so the potential to use a ruby or perl module from PHP would be huge to them
08:37 dukeleto they just want publications, and whatever is the fastest way to do that, that is what they will migrate to
08:38 moritz we need a new language, "biology paper generator", short bpg
08:39 dukeleto lulz
08:39 cotto There's no way I'm missing this years OS Bridge.
08:39 cotto I have a good excuse for making that a priority, especially since I don't need to fly there.
08:39 dukeleto cotto: you shouldn't. It is usually the best conf I go to each year.
08:40 cotto even over yapc?
08:40 dukeleto cotto: i have actually never been to a YAPC
08:40 * dukeleto has never been to a Perl conference, amazingly
08:40 cotto serious?
08:40 dukeleto cotto: dead serious.
08:40 cotto That's deeply surprising.
08:40 * moritz very much liked the perl conferences he has attended so far
08:40 dukeleto Indeed. It surprises even me.
08:41 dukeleto I was planning on YAPC::NA last year, but had to cancel.
08:43 cotto I'm excited to hit YAPC::EU this year.  There's a good-sized batch of Rakudo folks who don't usually make it stateside.
08:45 cotto "All" we need to do is have something to show for M0 and Lorito by then.
08:46 lucian joined #parrot
08:48 dukeleto slowly but surely. At least we have a spec now.
08:48 cotto Yes.  and I'm motivated to beat it into something awesome.
08:48 dukeleto things are starting to come together
08:49 dukeleto cotto: what kind of M0 ops do we need to interact with the runloop and pc ?
08:49 cotto what kind of interaction with the runloop are you thinking about?
08:49 dukeleto cotto: we could just have hard-coded indexes into the LoritoContext PMC do stuff
08:50 cotto if the PC is just another register we don't need anything special for it
08:50 dukeleto cotto: well i am thinking of incrementing the pc and exception handling in the runloop
08:50 theory left #parrot
08:50 dukeleto cotto: we can't be sure that a register won't get stomped on due to flying yaks
08:51 fperrad left #parrot
08:51 cotto If something's stomping on the PC, we've got issues.
08:51 dukeleto cotto: it needs to be in some kind of protected memory that is not accessible other than M0 ops
08:51 dukeleto indeed, we do. I guess I am paranoid
08:51 cotto dukeleto, that sounds magical
08:52 dukeleto cotto: so, if I understand you, we say "the PC is always in $I42". But what happens when generated code assigns to $I42 ? Do we have lexical registers or something?
08:53 dukeleto cotto: that is what I don't understand
08:54 cotto dukeleto, I'm thinking of the PC as being a special but otherwise unprotected register.
08:55 cotto different from [INSP]\d+
08:55 cotto We may be saying the same thing.
08:56 cotto I'm thinking that add $PC, $PC, 43 or set $PC, $I2 would be valid
08:57 dukeleto cotto: ah, so you are saying that the PC is some kind of "symbolic register" ?
08:58 dukeleto register means on of INSP in all our docs, so that is a bit confusing
08:58 dukeleto but I see that we are talking about the same thing
08:58 cotto I like it when that happens.
08:58 cotto yes
08:59 dukeleto cotto: how do we actually using the "$PC" from PIR ?
08:59 dukeleto cotto: these lorito dynops will be used from PIR, at first
08:59 dukeleto cotto: how do we actually use, rather
09:00 cotto dukeleto, Indirectly.  goto X can be sugar around setting $PC, same as ops2c does with C.
09:00 dukeleto cotto: do we want an op to retrieve and set the PC ?
09:00 cotto PIR can be a little bit magical.
09:00 dukeleto cotto: an M0 op, that is.
09:01 cotto dukeleto, That brings up the question of how M0 ops will deal with registers.
09:01 dukeleto cotto: perhaps when we want a JIT, having an op to get/set the PC will be better for optimization?
09:02 dukeleto cotto: yes. I assume we want set/get opcodes for each register type
09:02 cotto If an op is hard-coded to work with a certain register type, then we'd need separate instructions for dealing with the PC.
09:02 dukeleto i don't like that
09:03 cotto me neither
09:03 dukeleto and ops at M0 must be hard-coded per-register, for performance
09:03 dukeleto we don't want unnecessary indirection at M0
09:04 cotto indirection is slightly magical
09:04 cotto (and expensive when used in large quantities)
09:04 lucian cotto: i disagree with your terminology
09:05 dukeleto lucian: welcome
09:05 dukeleto lucian: which terminology?
09:05 lucian "indirection is slightly magical"
09:05 lucian i'd rather say "implicit indirection is slightly magical"
09:05 lucian if it's explicit, it's just an explicit abstraction
09:06 cotto I need a better word than "magical".
09:06 lucian cotto: :)
09:06 dukeleto pony-like
09:06 cotto wfm
09:06 cotto lucian, indirection is slightly pony-like
09:06 lucian cotto: much better :)
09:07 * lucian apologises for the intrusion
09:07 dukeleto cotto: so the current context has an interp object in it, right ?
09:07 cotto lucian, I mean that indirection adds a little bit of complexity.  M0 should be as simple as practical.
09:07 lucian it just sort of bugs me when people use "magic" for any abstraction
09:07 cotto lucian, no intrusion.
09:07 dukeleto cotto: we index into the interp object to modify the PC
09:08 dukeleto cotto: and provide an M0 "opcode" that is really just sugar for that
09:08 cotto lucian, I'm always glad when people feel welcome to jump into a discussion.
09:08 dukeleto cotto: i sense that we will have "primitive" M0 ops and some "derived" M0 ops
09:09 dukeleto cotto: in the sense that we could get by with only primitive M0 ops but for the sake of carpel-tunnel-syndrome, we provide some sugar
09:09 cotto dukeleto, we need a clear distinction between context and interp
09:09 dukeleto cotto: but generated code would never use the sugar
09:09 dukeleto cotto: a context has a single interp. What more do you want?
09:09 cotto dukeleto, maybe
09:10 dukeleto cotto: such as "what happens when i create 2 interp objects?"
09:10 dukeleto cotto: each context has a single interp which is the interp that the context was created with
09:11 dukeleto cotto: other created interps are part of the list of PMCs that are alive in that context
09:11 dukeleto cotto: make sense?
09:11 cotto dukeleto, what's the interp responsible for and what's the context responsible for?
09:11 lucian dukeleto: i still think there should only be primitive ops
09:11 lucian then you get back to something like PIR
09:12 cotto that's what needs definition, especially since we're changing some of the assumptions that hold in Parrot now.
09:12 dukeleto lucian: yeah, we shall see. We can make something macro-like that is expanded before compile-time
09:12 dukeleto lucian: i am just trying to save our poor wrists
09:12 lucian dukeleto: i may have made this point before, but the best way to save wrists is to use a higher level system language for parrot, like winxed or close
09:13 cotto dukeleto, It's a balance between not getting CTS and staying motivated to generate M0.
09:13 dukeleto cotto: everything always defers to the current context to do anything. The current context is the arbiter of all information
09:13 cotto lucian, absolutely.
09:13 cotto I hope we eventually have a gc implemented mostly in nqp.
09:14 dukeleto cotto: i am not sure that will happen. Maybe after a JIT
09:14 cotto eventually
09:14 lucian cotto: i'm not sure that's feasible
09:14 cotto for now, definitely not
09:14 lucian like, ever
09:14 dukeleto cotto: NQP is just too slow for the GC, which needs to run all the time
09:14 cotto or some other hll
09:15 lucian cotto: i meant any HLL on top
09:15 dukeleto cotto: perhaps we can come up with DSL for the GC that compiles to C, that might be feasible
09:15 dukeleto cotto: to make the code easier to understand and maintain
09:15 bacek ~~
09:15 cotto We'll see what becomes possible.  For now, apologies for the distraction.
09:15 lucian if C is that problematic, you might want to use one of the many languages that compile to mostly readable C
09:15 dukeleto but one yak at a time.
09:15 cotto hio bacek
09:16 cotto happy Friday
09:16 cotto aloha, clock?
09:16 aloha cotto: LAX: Fri, 01:16 PST / CHI: Fri, 03:16 CST / NYC: Fri, 04:16 EST / UTC: Fri, 09:16 UTC / LON: Fri, 09:16 GMT / BER: Fri, 10:16 CET / TOK: Fri, 18:16 JST / SYD: Fri, 20:16 EST
09:16 bacek cotto, aloha
09:16 dukeleto bacek: happy beer drinking day
09:16 bacek dukeleto, it's exactly what I'm doing right now
09:16 bacek seen mikehh
09:16 aloha mikehh was last seen in #perl6 5 hours 15 mins ago joining the channel.
09:16 cotto my $dayjob just got a new beer fridge.  It'll be great.
09:16 bacek cotto, congratulations! :)
09:17 dukeleto lucian: i think you are right. only primitve ops in M0, evertying else is a macro
09:17 cotto Apparently you can put other things in there, but I'm not sure why you would.
09:17 dukeleto bacon
09:17 lucian dukeleto: or bootstrap Close/Winxed early and have no need for macros :)
09:17 dukeleto A fridge full of bacon and beer is a happy fridge indeed.
09:17 lucian actually, there isn't even any need for bootstrapping, since a parrot system language has no core types or stdlib
09:18 dukeleto lucian: sounds nice, but M0 will be in C for the time-being
09:18 dukeleto lucian: definitely and interesting thing to experiment with, though
09:18 lucian dukeleto: sure, what i mean is that maybe you should avoid writing any M0 by hand. just like people almost never write java bytecode/ass
09:18 cotto For anyone reading xkcd, )
09:19 dukeleto lucian: sure, that is a fine idea
09:19 cotto You're welcome.
09:19 dukeleto lucian: i don't plan to write M0 by hand, but I have to write the C code implementation of M0 by hand :)
09:19 lucian dukeleto: sure, the implementation. but actual M0 code needn't be written by humans
09:20 dukeleto lucian: yes, i agree
09:20 bacek lucian, +1
09:20 cotto lucian, exactly
09:20 dukeleto i expect parrot devs will code in M1 which is transformed automagically to M0
09:20 lucian dukeleto: that i also disagree with, looking at PIR vs PASM
09:21 dukeleto not sure if that is at compile-time or run-time, yet
09:21 dukeleto could be either
09:21 dukeleto lucian: what do you agree with?
09:21 lucian dukeleto: writing in a higher level language
09:21 dukeleto lucian: that is the whole design of M0, M1, .. MN
09:21 lucian but i don't agree with this language being assembly-like
09:21 dukeleto lucian: each level is implemented in the previous level
09:21 lucian dukeleto: right, scheme
09:23 lucian do you have this design written down somewhere? i may be missing something
09:24 cotto lucian, that's what the m0-spec branch is about.  Other materials are rather dispersed.
09:25 lucian right. what i had hoped for parrot was to get rid of writing assembly (PIR) altogether, and just write winxed/close for *everything* above the C level
09:25 dukeleto cotto: is there an M0 op for selecting a runcore? or is that just an index into the interp object?
09:25 dukeleto lucian: that is what we are calling M1
09:26 lucian dukeleto: ah, ok. sorry. i had assumed M1 was superset of M0, but otherwise still assembly
09:26 dukeleto lucian: PIR is just the first implementation for M0 and M1. We plan on having other, better languages to interact with M0 and M1 in the future
09:26 cotto dukeleto, I haven't thought about that.
09:26 dukeleto lucian: M0 and M1 are orthogonal to PIR
09:26 lucian dukeleto: ok
09:26 dukeleto lucian: currently, we are implementing M0 as C dynops
09:27 cotto M1 corresponds somewhat to where PIR lives now
09:27 dukeleto lucian: and using PIR to interact with them. But we could really choose any Parrot language to interact with M*
09:27 lucian dukeleto: right
09:27 dukeleto lucian: we are concentrating on the spec of M0 now
09:28 lucian sure, sorry i digressed
09:28 dukeleto lucian: and not worrying too much about M1 or the fact that we are using PIR
09:28 lucian i see
09:28 dukeleto lucian: no worries, these are good questions
09:28 lucian so you're trying to move away from PIR by changing the backend from under it
09:29 cotto I had pictured the runcore living below M0 (i.e. the runcore implements M0).
09:29 dukeleto cotto: i don't parse that
09:29 dukeleto cotto: we need to know our runcore to execute bytecode
09:29 dukeleto cotto: which is what happens after we increment the PC, iirc
09:30 cotto dukeleto, the runcore is what executes bytecode.  You give it a PC and it knows what to do.
09:31 cotto (this is how I see the world, not necessarily how it is)
09:31 dukeleto cotto: how do you give the runcore the PC from M0? I am not seeing it.
09:32 cotto The PC is a register that the runcore knows to look at in order to determine which op to execute.
09:32 bacek Guys.
09:32 dukeleto Gals.
09:32 bacek Treat every op as sub program.
09:33 dukeleto bacek: explain a bit more
09:33 bacek Then execution of of is "Context.invoke(op, pc+2)
09:33 bacek if Context is continuation
09:33 bacek then PC is just where it's point to
09:33 dukeleto bacek: that is the plan
09:34 bacek Than we don't need separate handling (logically) of m0 ops
09:35 bacek So, execution of _current_ op is equal to Context.invoke(op_sub, pc+1)
09:36 lucian left #parrot
09:36 bacek call of real sub is "$P0 = <fiind_sub_some_how>; $P1 = new_ctx; $P1.invoke($P0, pc + 1)"
09:37 bacek even better
09:37 bacek (partially joking)
09:38 bacek Subs are indexed. In something like "ExecutionUnit" (similar to packfile)
09:38 bacek M0 ops have indexes [0...N]
09:38 bacek Other subs (including M1 ops) numbered [N+1...M]
09:39 bacek Runloop become trivial
09:39 mikehh bacek: you was lookin' fo me
09:40 bacek mikehh, can you retest gen_gc?
09:40 dukeleto bacek: shouldn't that be current_ctx ?
09:41 cotto I really need to sleep.  Please add any ideas to m0-spec.
09:41 cotto 'night
09:41 bacek dukeleto, yes.
09:41 dukeleto cotto: take it easy
09:41 bacek cotto, night
09:41 * dukeleto was right for once!
09:42 dukeleto bacek: why do we want to pass the pc to invoke?
09:42 dukeleto bacek: seems like it should know how to get it
09:42 bacek dukeleto, goto
09:43 dukeleto bacek: GET_ATTR_ADDRESS in Continuation PMC gets the PC
09:44 bacek dukeleto, we are passing _next_ address
09:44 mikehh bacek: sure, looked ok about 8 hours ago
09:44 dukeleto bacek: ah, yes
09:44 bacek mikehh, I did small fix. It was some failures on amd64
09:44 bacek mikehh, what about merging it for 3.1? :)
09:45 mikehh bacek: had 1 failure on rakudo on amd64/none on rakudo i386
09:45 bacek mikehh, gc-leaky?
09:46 dalek parrot: d5a6bc6 | (Gerd Pokorra)++ | NEWS:
09:46 dalek parrot: add a news about NQP
09:46 dalek parrot: review: https://github.com/parrot/parrot/commit/d5a6bc669b
09:46 mikehh bacek: bumped to 4e7 but failed on 2e7 on both
09:47 mikehh bacek: did not commit it though
09:47 bacek mikehh, I think it's safe to commit. We can put check into loop to exit it early.
09:50 mikehh bacek: we need to incorporate a check for available memory, what if someone had 12GB or more
09:51 mikehh bacek: and tune it on that basis
09:52 mikehh bacek: anyway I will run some tests now (on amd64 at the moment)
09:54 dukeleto bacek: i have a darwin/x86 smoker on gen_gc running now
09:58 contingencyplan left #parrot
10:03 cotto left #parrot
10:06 dalek parrot/generational_gc: 2d0471f | bacek++ | t/op/gc-leaky- (2 files):
10:06 dalek parrot/generational_gc: Made tests more tolerant to big amount of available memory
10:06 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/2d0471f3bc
10:07 bacek mikehh, latest commit into branch should solve it
10:08 dalek parrot/lorito: 246f4f3 | dukeleto++ | / (2 files):
10:08 dalek parrot/lorito: Improve LoritoContext init and tests
10:08 dalek parrot/lorito: review: https://github.com/parrot/parrot/commit/246f4f340b
10:11 mikehh bacek: had started testing, but will stat again
10:11 mikehh start
10:11 bacek mikehh, it's just t/op/gc-leaky-*.t
10:11 bacek amd64/c++?
10:12 mikehh bacek: yes
10:12 bacek mikehh, good.
10:13 bacek seen kid51
10:13 aloha kid51 was last seen in #parrot 6 hours 12 mins ago saying "make: *** [runtime/parrot/library/YAML/Tiny.pir] Error 134".
10:13 bacek msg kid51 Can you retest gen_gc? I hope this bug is fixed.
10:13 aloha OK. I'll deliver the message.
10:17 mtk left #parrot
10:23 dalek parrot/generational_gc: 8669daa | bacek++ | src/gc/gc_gms.c:
10:23 dalek parrot/generational_gc: Remove c++-commented code.
10:23 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/8669daadb5
10:23 dalek parrot/generational_gc: 5244700 | bacek++ | src/ (2 files):
10:23 dalek parrot/generational_gc: Remove c++-comment. Put normal comment instead and made code more obvious about semantics
10:23 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/5244700f6a
10:23 mikehh bacek: ok that seems to work - make corevm/make coretest PASS, but, api_t_test.pir is still not removed
10:24 mtk joined #parrot
10:24 bacek mikehh, I didn't touch this test at all in branch.
10:25 bacek I think it's from whiteknight's api branch
10:26 ttbot Parrot 5244700f i386-freebsd-64int make error http://tt.taptinder.org/cmdinfo/9160
10:29 dalek parrot/generational_gc: 5eec12f | bacek++ | src/string/api.c:
10:29 dalek parrot/generational_gc: Restore previous behaviour of setting GC flags in str_copy.
10:29 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/5eec12ff8f
10:32 mikehh bacek: t/src/embed/api.t has an extra line comparing to master
10:34 bacek mikehh, git diff master -- t/src/embed/api.t doesn't give anything...
10:36 bacek mikehh, may be you have POSTMORTEM environment variable set (or how it's called)?
10:36 bacek no
10:36 bacek this file is actually handled wrong in test
10:37 bacek but it should be same in master
10:40 nopaste "mikehh" at 192.168.1.3 pasted "git diff master -- t/src/embed/api.t" (15 lines) at http://nopaste.snit.ch/31331
10:41 mikehh bacek: does for me see nopaste - http://nopaste.snit.ch/31331
10:42 bacek mikehh, ah
10:42 bacek it was fixed in master recently
10:42 bacek Test was added on 7th
10:42 bacek Let me merge master to branch
10:44 mikehh bacek: ok once done will build and run to fulltest and test rakudo
10:44 bacek mikehh, ok, thanks!
10:46 dalek parrot/generational_gc: 0c03f7e | bacek++ | / (9 files):
10:46 dalek parrot/generational_gc: Merge branch 'master' into generational_gc
10:46 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/0c03f7e240
10:46 bacek mikehh, pushed
10:48 mikehh bacek: building and testin' now
10:52 bacek dukeleto, how is your testing on Darwin?
10:58 dalek parrot/generational_gc: 8802115 | mikehh++ | src/pmc.c:
10:58 dalek parrot/generational_gc: fix codetest failure - trailing space
10:58 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/880211526a
11:02 mikehh bacek: codetest now PASSes
11:02 bacek mikehh, hooray!
11:02 bacek Merge party? Or wait until after 3.1?
11:02 tadzik :)
11:10 tadzik s/party/madness/
11:13 bacek tadzik, not at all. Diff with master is quite small :)
11:15 tadzik :)
11:15 tadzik well, thursday, friday, little difference :)
11:16 lateau left #parrot
11:17 tadzik Your branch is behind 'origin/master' by 879 commits, and can be fast-forwarded.
11:17 tadzik /o\
11:18 bacek go-go-go!!! :)
11:27 woosley joined #parrot
11:28 mikehh bacek: all tests PASS up to fulltest - Kubuntu 10.10 amd64 (g++-4.5)
11:28 bacek mikehh, excellent!
11:28 mikehh bacek: now for with --optimize and rakudo
11:29 * bacek little bit nervous :)
11:29 tadzik ;)
11:29 * tadzik taps bacek's back
11:29 tadzik Everything's gonna be alright ;)
11:29 bacek of course!
11:29 bacek I've got 3 more beers to fix everything.
11:30 fperrad joined #parrot
11:44 adu joined #parrot
11:50 darbelo joined #parrot
11:50 clunker3_ joined #parrot
11:53 clunker3 joined #parrot
11:54 clunker3_ left #parrot
11:57 mikehh generational_gc branch:
11:57 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#8971) fulltest) at 3_0_0-886-g8802115 - Kubuntu 10.10 amd64 (g++-4.5 with --optimize)
11:58 adu left #parrot
12:04 mikehh bacek: rakudo date && time make -j -> real    5m42.895s, user    6m55.790s, sys     0m6.460s
12:04 mikehh vs last build on master -> real    8m15.501s, user    10m1.750s, sys     0m5.180s
12:07 mikehh bacek: running spectest_smolder now
12:10 eternaleye joined #parrot
12:15 adu joined #parrot
12:17 clunker3 left #parrot
12:18 clunker3 joined #parrot
12:32 mikehh bacek: rakudo alltests PASS - spectest_smolder #8982
12:33 bacek mikehh, hooray!
12:33 mikehh bacek: merge it - we can fix any bugs over the weekend
12:33 bacek As you wish! :)
12:36 dalek parrot: 2d0471f | bacek++ | t/op/gc-leaky- (2 files):
12:36 dalek parrot: Made tests more tolerant to big amount of available memory
12:36 dalek parrot: review: https://github.com/parrot/parrot/commit/2d0471f3bc
12:36 dalek parrot: 8669daa | bacek++ | src/gc/gc_gms.c:
12:36 dalek parrot: Remove c++-commented code.
12:36 dalek parrot: review: https://github.com/parrot/parrot/commit/8669daadb5
12:36 dalek parrot: 5244700 | bacek++ | src/ (2 files):
12:36 dalek parrot: Remove c++-comment. Put normal comment instead and made code more obvious about semantics
12:36 dalek parrot: review: https://github.com/parrot/parrot/commit/5244700f6a
12:36 dalek parrot: 5eec12f | bacek++ | src/string/api.c:
12:36 dalek parrot: Restore previous behaviour of setting GC flags in str_copy.
12:36 dalek parrot: review: https://github.com/parrot/parrot/commit/5eec12ff8f
12:36 bacek hmmm....
12:36 dalek parrot: 0c03f7e | bacek++ | / (9 files):
12:36 dalek parrot: Merge branch 'master' into generational_gc
12:36 dalek parrot: review: https://github.com/parrot/parrot/commit/0c03f7e240
12:36 dalek parrot: 8802115 | mikehh++ | src/pmc.c:
12:36 dalek parrot: fix codetest failure - trailing space
12:36 dalek parrot: review: https://github.com/parrot/parrot/commit/880211526a
12:36 dalek parrot: b55f22f | bacek++ | / (44 files):
12:36 dalek parrot: Generational GC enters the building. Merge generational_gc branch
12:36 dalek parrot: review: https://github.com/parrot/parrot/commit/b55f22f675
12:38 bacek mikehh, done-done
12:39 adu left #parrot
12:40 mikehh bacek: winxed also builds and PASSes tests
12:41 clunker3 left #parrot
12:41 mikehh bacek: will check out master and tests and then on i386
12:41 bacek mikehh, ok, thanks!
12:42 bacek It's bed time for me now.
12:42 bacek G'Night, folks
12:42 mikehh bacek++
12:42 clunker3 joined #parrot
12:45 dalek plumage: d6ce79d | darbelo++ | setup.pir:
12:45 dalek plumage: Update setup.pir to use get_nqp_rx() instead of get_nqp(). Needed after parrot commit 0617415a.
12:45 dalek plumage: review: https://github.com/parrot/​plumage/commit/d6ce79d78a
12:46 bluescreen joined #parrot
13:26 dalek nqp: 7387a66 | bacek++ | src/metamodel/reprs/P6opaque.c:
13:26 dalek nqp: Insert write barrier after compute of allocation strategy.
13:26 dalek nqp: review: https://github.com/perl6/nqp/commit/7387a662f7
13:26 dalek TT #2005 created by jkeenan++: Parrot no longer builds on Darwin/PPC
13:26 dalek TT #2005: http://trac.parrot.org/parrot/ticket/2005
13:30 whiteknight joined #parrot
13:31 whiteknight bacek++
13:31 whiteknight ...and, good morning #parrot
13:34 bacek whiteknight, can you join #perl6? masak have some problems with gen_gc. And I'm almost felt asleep
13:38 mikehh bacek: can you check TT #2005, I will understand if you need sleep first
13:40 bacek mikehh, ouch...
13:40 bacek seen kid51
13:40 clunker3 kid51 was last seen on #toolchain 5 months, 12 days, 13 hours, 30 minutes and 8 seconds ago, saying: So today is 29 Aug.  Which germans broke what?
13:40 aloha kid51 was last seen in #parrot 9 hours 40 mins ago saying "make: *** [runtime/parrot/library/YAML/Tiny.pir] Error 134".
13:40 whiteknight that quote is hilarious
13:47 Coke bacek++
13:48 bacek Coke, not yet.
13:50 whiteknight msg cotto_work any preference on what function naming should be for src/interp/*? I need to add at least one new function in there for the IMCC branch, and I'll be damned if I'm not going to use a proper name for it
13:50 aloha OK. I'll deliver the message.
13:53 fperrad_ joined #parrot
13:53 fperrad left #parrot
13:53 Coke bacek++ #don't you tell me what to do!
13:53 fperrad_ is now known as fperrad
13:56 clunker3 left #parrot
13:56 clunker3_ joined #parrot
14:02 * Coke tries to build partcl after months of neglect.
14:02 whiteknight I sense much fail in your future
14:03 whiteknight I feel a great disturbance in the force, as if many trac tickets were suddenly created and then assigned to me
14:04 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#9001) fulltest) at 3_0_0-887-gb55f22f - Kubuntu 10.10 amd64 (g++-4.5)
14:06 * mikehh got to go out for a bit
14:06 rurban_ joined #parrot
14:06 mikehh will test on Ubuntu i386 when I get back
14:06 mikehh left #parrot
14:06 dalek parrot: 77b57cc | bacek++ | include/parrot/gc_api.h:
14:06 dalek parrot: Disable shortcutting of mark_PMC_alive. It's needed for calculating of youngest child.
14:07 dalek parrot: review: https://github.com/parrot/parrot/commit/77b57cc513
14:09 rurban left #parrot
14:09 rurban_ is now known as rurban
14:13 plobsing left #parrot
14:27 Coke looks like one of the changes is in dealing with named function params.
14:28 whiteknight yeah, there was a special case for a while where we weren't doing error checking on named parameters in certain situations. We removed the special case
14:28 whiteknight I don't remember what it was or why, but I know it's gone
14:29 Coke good night, magical coding robot.
14:30 mikehh joined #parrot
14:32 Hackbinary good afternoon #parrot
14:33 mikehh hay Hackbinary
14:33 mikehh Hackbinary: it was mentioned somewhere that you are in Scotland
14:34 Hackbinary it's true
14:34 Hackbinary I'm in Edinburgh
14:34 mikehh I am in Aderdeen
14:34 bacek night humans
14:34 Hackbinary g'night bacek
14:34 mikehh cheers bacek
14:35 Hackbinary Aberdeen is the only large city in Scotland that I haven't been to yet
14:36 mikehh Hackbinary: whatcha ya doin' in Edinburgh
14:36 Hackbinary right now, looking for work
14:37 Hackbinary :(
14:37 mikehh ah, sad way to spend time
14:37 Hackbinary yah it's not the best
14:39 Hackbinary what you doing in aberdeen?
14:40 mikehh generally I work from home, doing various development for clients, none actually here in Aberdeen
14:42 mikehh in fact only one client in Scotland at the moment.
14:43 Hackbinary perlish type stuff?
14:45 mikehh Linux based usually, c++, c, perl and others, some Web type stuff as well, I also do sys admin for a couple of websites, although how I got into that I have no idea
14:50 * mikehh fresh out of milk and other things, really need to get some stuff - bbl
14:57 Hackbinary okay, see you in awhile
15:04 dalek TT #2006 created by masak++: Problem compiling Rakudo's Test.pm on Debian x64
15:04 dalek TT #2006: http://trac.parrot.org/parrot/ticket/2006
15:04 benabik joined #parrot
15:05 whiteknight yay! I think I just fixed a large number of the test failures in the imcc branch
15:08 whiteknight I wish Parrot's test harness would give a final count of number of test failures, so I could compare progress quickly
15:10 Coke isn't that a function of whatever perl test harness we're using?
15:14 rurban_ joined #parrot
15:14 cotto joined #parrot
15:16 whiteknight Coke: yeah, I don't know the details
15:17 whiteknight I seem to remember seeing a short totals summary table at one point, but it isn't there now
15:19 rurban left #parrot
15:19 rurban_ is now known as rurban
15:19 lateau joined #parrot
15:25 theory joined #parrot
15:27 woosley left #parrot
15:28 Andy joined #parrot
15:40 cotto_work ~~
15:41 darbelo ~~
15:42 plobsing joined #parrot
15:42 whiteknight on the bright side, I think fixing all the test failures in my imcc branch is going to require me to completely rip out the hack-job homebrew exception handling that IMCC uses
15:43 atrodo That's a good thing, right?
15:44 cotto_work whiteknight: that will the new function do?
15:44 whiteknight cotto_work: Get an Interp* from a ParrotInterpreter PMC, without having an Interp* around already for calling vtables
15:45 whiteknight necessary for the API
15:45 cotto_work I can see where you might want to do that.
15:48 cotto_work What name were you thinking?  Also, how would that work?  You need an Interp* before you can do anything.
15:50 whiteknight in the branch now, I'm calling it "Parrot_int_get_interp_some​thing_something_something"
15:50 whiteknight I don't remember what I called it
15:50 whiteknight the API renaming page on the wiki says "Parrot_int_*", but clearly no functions in that folder follow that naming scheme
15:50 contingencyplan joined #parrot
15:50 cotto_work "int"?
15:50 cotto_work do not want
15:51 cotto_work That's too ambiguous.  "int" has a very different meaning from "interp".
15:52 cotto_work imcc_interp_code branch?
15:54 cotto_work I don't see "Parrot_int_*" in either imcc_ branch.
15:56 whiteknight cotto_work: the whiteknight/imcc_compreg_pmc branch. I haven't pushed this change yet
15:56 whiteknight what would you prefer, Parrot_interp_*?
15:57 whiteknight I ask because there is no prior art here, so we can pick whatever we want and get it right
15:57 cotto_work I'd prefer Parrot_interp_*.  Names don't need to be artificially short if it hurts readability.
15:58 cotto_work We have modern compilers.  They can deal with long function names.
15:58 whiteknight that's true, but at the same time we start ending up with unnecessarily large prefixes on function names
15:58 PerlJam left #parrot
15:58 whiteknight Parrot_interp_ is fine
15:58 PerlJam joined #parrot
16:01 cotto_work wfm
16:11 Hackbinary hello everyone, the smolder server for cardinal doesn't seem to work anymore, has it been migrated?
16:11 Hackbinary http://smolder.plusthree.com/app/​public_projects/smoke_reports/16
16:12 darbelo Hackbinary:  check smolder.parrot.org
16:15 Hackbinary I don't see cardinal on there?
16:16 cotto_work I love the gen_gc branch, but I'm not thrilled that it was merged into master without even a mention at #ps.
16:17 Patterner left #parrot
16:17 Psyche^ joined #parrot
16:17 Psyche^ is now known as Patterner
16:18 plobsing gen_gc got merged?
16:18 cotto_work especially since it's clear that nqp didn't get sufficient testing
16:18 cotto_work plobsing: yes
16:19 plobsing this close to a release? when there were still hacky workarounds?
16:19 plobsing are we insane?
16:20 cotto_work It's also a violation of our support policy since some languages may need to add write barriers.
16:20 plobsing sure, there were significant speedups in some very common use cases, but I am 99% sure I can find a case where the ctx-dirty/register workaround makes things notably slower
16:21 Coke bacek got approval from the release manager. Also, I hear we have the ability to undo things. ;)
16:21 cotto_work I saw that, but this is more than a feature addition.
16:22 Coke speedups in the common case but slowdowns in uncommon cases is not a reason not to merge. (the write barriers might be.) - but in that case, cotto, the merge will have to wait 2 more months. (not arguing, just pointing out.)
16:22 whiteknight we do not want to wait 2 months on this
16:22 whiteknight 2 weeks, there's an argument to be made. 2 months is out of the question
16:22 cotto_work whiteknight: I agree, but this was too fast.
16:23 Coke I suspect just after the release with a big note in the news saying "Sorry, but this is really worth it" (re: the write barriers changes) is a good compromise.
16:23 cotto_work Coke: that would have been preferable.
16:24 Coke especially since you we can leave the macros in master even if we rollback the code.
16:24 cotto_work yes
16:24 Coke cotto_work: so make it work that way. the release hasn't happened yet.
16:25 cotto_work Coke: indeed
16:25 cotto_work dukeleto: ping
16:26 plobsing Coke: the "uncommon" case is more common than you think. Every register access is slower.
16:26 darbelo Ouch.
16:26 whiteknight plobsing: what's the story there? I wasn't aware of a slowdown on register accesses
16:26 plobsing look at REG_INT
16:27 plobsing it used to be, in optimized builds, registers were accessed through a couple of pointer dereferences and an array lookup.
16:27 Coke plobsing: I took you at your word when you said uncommon.
16:27 Coke that sounds like it might actually be what we call common.
16:28 plobsing with gen_gc, that meant that the ctx could be updated without marking it dirty. the workaround was to always go through accessor functions (which we already had for debug builds), which marked the ctx.
16:28 plobsing these accessor functions are in a separate file and not inlinable
16:29 whiteknight that does sound like something we could optimize in-place
16:29 NotFound Marking int registers?
16:29 plobsing the *correct* solution is to get ops2c to generate different code for accesses that could actually make the CTX dirty (either call the accessors or WB inplace)
16:30 whiteknight plobsing: right, I thought it was agreed yesterday to do that very thing?
16:30 plobsing 90% of register accesses are not this
16:30 plobsing whiteknight: there was a sense that this should be done. my opinion is that should have happened before the merge.
16:31 whiteknight we know that gen_gc brings about a 25% speedup to Rakudo in most tests. reverting that because there is a slowdown on certain accesses hardly seems prudent
16:31 whiteknight Either we revert the gen_gc merge now because it has problems, or we stick with it and use it as the new basis for future optimizations
16:32 whiteknight at least, that 25% number is what I have been told. I haven't done the testing myself
16:32 plobsing my concern is that this regression never gets adressed
16:33 Coke well, if it stays in master, step 1: open a ticket so it doesn't get lost.
16:33 whiteknight how hard would it be to address it? I've never monkeyed around in ops2c, but I can't imagine it's uber-difficult to generate different accessors
16:33 Coke (or as soon as it gets back in master.)
16:34 cotto_work whiteknight: it depends on how accustomed you are to nqp.
16:35 plobsing whiteknight: my past attempts at modifications to ops2c have resulted in nothing but frustration. IMHO, it is a ball of spaghetti Perl 5 which was ported to NQP nearly verbatim. I have no desire to touch it again.
16:35 NotFound Also, while doing that it will be good to get rid of generating the current context var in ops that doesn't use it.
16:35 whiteknight NotFound: yes, that is another good optimization
16:36 cotto_work I'm still on the fence about reverting the merge.
16:37 NotFound Alternative approach: create a branch from a point before the merge and cut the release from it.
16:38 cotto_work NotFound: I like that idea if mikehh feels comfortable enough with git to do it.
16:38 whiteknight if the merge causes a problem, that's not a bad idea
16:39 whiteknight I wish we weren't having this conversation while bacek was sleeping
16:41 cotto_work Awesome.  Take a look at support_policy.pod and look for "<<<<<<<".
16:42 cotto_work fixing now
16:42 Coke SWEET
16:42 Coke most awesome that it's from our git master. ;)
16:44 NotFound And none of the alternatives is correct.
16:44 dalek parrot: ad9c8a0 | cotto++ | docs/project/support_policy.pod:
16:44 dalek parrot: fix some unresolved conflicts from deprecations as data
16:44 dalek parrot: review: https://github.com/parrot/parrot/commit/ad9c8a039e
16:45 NotFound cotto_work: Isn't api.yaml now?
16:45 * Coke misses the diffs-in-email.
16:46 cotto_work d'oh
16:46 dalek parrot: cd7619c | cotto++ | docs/project/support_policy.pod:
16:46 dalek parrot: refer to the right file
16:46 dalek parrot: review: https://github.com/parrot/parrot/commit/cd7619c330
16:47 NotFound TODO: add a test that verify docs refered to in pod do exists.
16:48 cotto_work NotFound: are you volunteering?
16:48 * NotFound whistles
16:52 nopaste "coke" at 192.168.1.3 pasted "segfault in partcl." (3 lines) at http://nopaste.snit.ch/31363
16:52 bluescreen left #parrot
16:53 cotto_work Coke: is that new since the gen_gc merge?
16:54 Coke cotto_work: partcl has been so broken for so long I have no idea how long it's been there.
16:54 Coke trying to get it back to passing again as time permits.
16:54 Coke bisecting to identify changes is, IME, useless, so I won't volunteer it.
16:55 dalek partcl-nqp: 9b45b77 | coke++ | build/PARROT_REVISION:
16:55 dalek partcl-nqp: lie so we can build with latest parrot
16:55 dalek partcl-nqp: (need to incorporate a fix to work with git)
16:55 dalek partcl-nqp: review: https://github.com/partcl/p​artcl-nqp/commit/9b45b775ce
16:55 dalek partcl-nqp: 34a4df4 | coke++ | src/Partcl/commands/time.pm:
16:55 dalek partcl-nqp: Avoid "TclString doesn't have set_string_native" error.
16:55 dalek partcl-nqp: I have no idea *why* this error started occurring, but
16:55 dalek partcl-nqp: this avoids it. :(
16:55 dalek partcl-nqp: review: https://github.com/partcl/p​artcl-nqp/commit/34a4df4ebe
16:55 dalek partcl-nqp: d0fa4e9 | coke++ | src/Partcl/commands/string.pm:
16:55 dalek partcl-nqp: parrot now complains about this extra arg
16:55 dalek partcl-nqp: (we didn't seem to be using it anyway)
16:55 dalek partcl-nqp: review: https://github.com/partcl/p​artcl-nqp/commit/d0fa4e933d
16:56 Coke happy to provide backtrace, etc.
16:57 Hackbinary notfound / cotto_work, I'm happy to work on some of the documentation
16:59 nopaste "coke" at 192.168.1.3 pasted "2 segfaults..." (11 lines) at http://nopaste.snit.ch/31366
17:01 whiteknight awesome
17:01 cotto_work Hackbinary: thanks.  The idea is to make sure that anything in F<...> in Pod is a real file.  You could probably copy/modify t/codingstd/pod_syntax.t as a starting point.
17:02 whiteknight Hackbinary: send in a CLA
17:02 plobsing for a tangible example of the slowdown I complained about earlier, examples/pir/md5sum.pir /usr/lib/libc.a went from ~3.25s to ~7.75 seconds for me
17:03 whiteknight plobsing: okay, that is pretty substantial
17:03 plobsing I'd say. heavy math getting >2x slower is not acceptable IMO.
17:03 cotto_work aloha: clock?
17:03 aloha cotto_work: LAX: Fri, 09:03 PST / CHI: Fri, 11:03 CST / NYC: Fri, 12:03 EST / UTC: Fri, 17:03 UTC / LON: Fri, 17:03 GMT / BER: Fri, 18:03 CET / TOK: Sat, 02:03 JST / SYD: Sat, 04:03 EST
17:03 atrodo cotto_work> https://github.com/atrodo/parrot/blob​/m0-spec/docs/pdds/draft/pdd32_m0.pod
17:05 cotto_work plobsing: how many cases like that do you expect there to be?
17:05 dip left #parrot
17:06 cotto_work atrodo: I gauss I cant spel
17:06 Hackbinary http://www.parrot.org/files/parrot_cla.pdf --> 404
17:07 atrodo cotto_work> ?
17:07 plobsing cotto_work: I expect nearly anything that isn't PCT-based to suffer. This is an example chosen to highlight the issue, so the magnitude of the slowdown experienced in the average case will likely be less.
17:08 NotFound plobsing: you mean winxed, for example?
17:08 cotto_work atrodo: nm.  I didn't realize which parts were yours.
17:08 cotto_work NotFound: there's an easy way to find out.
17:08 plobsing NotFound: certainly some code written in winxed could suffer from the issue. Not sure about the compiler. How much garbage does it churn through?
17:09 NotFound cotto_work: yes, but I'm short of time right now, I should be on the road now.
17:09 plobsing I use PCT-based as a first-order approximation for "generates a lot of garbage"
17:09 cotto_work NotFound: ok
17:14 plobsing I also see a slowdown on examples/hexdump.winxed
17:15 cotto_work seen mikehh
17:15 clunker3_ mikehh was last seen on #parrot 2 hours, 29 minutes and 59 seconds ago, saying: Linux based usually, c++, c, perl and others, some Web type stuff as well, I also do sys admin for a couple of websites, although how I got into that I have no idea
17:15 aloha mikehh was last seen in #parrot 2 hours 30 mins ago saying "Linux based usually, c++, c, perl and others, some Web type stuff as well, I also do sys admin for a couple of websites, although how I got into that I have no idea".
17:16 cotto_work msg mikehh It's becoming clear that gen_gc was merged too early and without enough discussion and testing.  Are you comfortable making a branch from before the merge and cutting the release from that?
17:16 aloha OK. I'll deliver the message.
17:17 dmalcolm joined #parrot
17:19 cotto_work I'm leaning toward either that or reverting and re-merging after the release.
17:20 whiteknight the two options are basically equivalent
17:20 whiteknight creating a new branch from before the merge saves the effort of unmerging
17:25 bluescreen joined #parrot
17:27 mikehh cotto_work: if necessary - however I wass testing the branch and we got it passing everything as well as rakudo and winxed
17:28 cotto_work mikehh: yes but there are performance concerns
17:28 cotto_work It's much faster for Rakudo but slower for other kinds of programs.
17:29 mikehh possibly, but it builds rakudo much faster, spectest did not take much longer
17:29 cotto_work It also was merged without much discussion, which is bad because it breaks our support policy.
17:30 mikehh we can optimize it a lot, however I have never been too happy with the gc, this has much better potential
17:31 mikehh that is probably my fault (merging that is) because we got everything passing and rakudo works with it
17:33 mikehh in what way does it breask the support policy - gc is internal?
17:33 mikehh break
17:34 cotto_work mikehh: some HLLs need to add write barriers to some VTABLE slots.
17:34 mikehh really, which working ones?
17:34 Coke rakudo
17:34 cotto_work Rakudo at least, possibly nqp
17:35 mikehh tested that - spectest smolder passes
17:35 Coke obviously, rakudo is already fixed, there, but if our main language needed it...
17:35 cotto_work mikehh: that's because bacek gave them a patch
17:36 mikehh sure I saw it
17:39 mikehh everything was passing (on parrot) before the merge, so I can probably pick it up there if absolutely necessary
17:43 mikehh I was hoping to test everything over the weekend, with some help of course, and fix any outstanding bugs
17:45 mikehh there is a lot of room for optimization in gen_gc as it stands, but that can come over the course of the next couple of months
17:46 plobsing gen_gc is a good idea. the problem is it isn't ready yet. this is experienced in the form of large performance regressions.
17:46 mikehh I don't really want to go forward with the old gc and wait until 3.3  or 3.6 to put it in
17:46 cotto_work mikehh: I'm not suggesting that.  I'm just saying 3.1 is too soon.
17:47 mikehh cotto_work: it's probably your decision, but I don't really agree with that
17:47 cotto_work We can occasionally go against our support policy if we believe that the trade-off will benefit users, but I never want that to happen without some discussion at a #ps.
17:48 cotto_work My preference would be to merge shortly after 3.1 (or cut 3.1 from a pre-merge branch) and optimize from there, along with adding a proper deprecation notice.
17:48 ryan joined #parrot
17:48 mikehh cotto_work: I thought we had agreed to put it in as soon as possiblky, I could be wrong though
17:51 chromatic joined #parrot
17:52 chromatic How about fixing the non-PMC register accesses instead of reverting everything?
17:52 chromatic See include/parrot/context.h line 35.
17:52 mikehh chromatic: good idea
17:52 cotto_work also an option if we can make it work within the next day or so
17:53 mikehh I'll create a branch from just before the mergem just in case
17:53 chromatic Let me try something quick.
17:53 cotto_work mikehh: thanks
18:01 Coke (releasing from branch) this may also mess up rakudo, temporarily. not sure how smart their configure.pl script is yet.
18:01 nopaste "chromatic" at 192.168.1.3 pasted "Re-enable register access optimizations" (41 lines) at http://nopaste.snit.ch/31376
18:02 plobsing chromatic: also need WB on string registers
18:02 chromatic Really? Should be easy to add.
18:02 plobsing true. just pointing it out.
18:03 chromatic I don't have time at the moment; anyone who wants to take over is welcome to do so.
18:04 mtk left #parrot
18:05 chromatic All of the core tests did pass for me, FWIW.
18:06 chromatic left #parrot
18:06 plobsing the problem is that the corner-case is very small. it is quite likely the core tests don't show the problem
18:07 Coke it is hard to not break things we have no tests for.
18:09 plobsing I'm trying to come up with something that demos it.
18:09 Coke \o/
18:10 Hackbinary whiteknight, where should I send in the cla?  and do you need a scan of page 2 as well?
18:11 cotto_work Hackbinary: you can scan and email if you prefer.
18:11 Coke Hackbinary: parrot.org/foundation should have details
18:11 whiteknight Hackbinary: both pages. Address and fax number should be on the CLA itself I think
18:11 mtk joined #parrot
18:11 Hackbinary sorry, I need an email address
18:12 Hackbinary i'm blind, legal@
18:16 Hackbinary okay, I've sent in page 1 and page 3; if you need me to send in page 2, just let me know.  (There was nothing to fill in on page 2)
18:17 Hackbinary =)
18:27 minusnine_ joined #parrot
18:28 dukeleto ~~
18:29 cotto_work good morning, dukeleto
18:30 dukeleto why was gen_gc merged to master?
18:30 dukeleto cotto_work: mornin'
18:30 cotto_work dukeleto: welcome to the madhouse
18:30 cotto_work It shouldn't have been.
18:30 dukeleto we didn't do any benchmarking
18:31 lateau left #parrot
18:32 dukeleto running rakudo spectest and looking at build times is not the same as doing real run-time benchmarking of various nontrivial stuff
18:34 cotto_work plobsing pointed out that there are cases that are substantially slower due to the write barrier
18:35 cotto_work they can be improved, but it was the first I've heard of those cases
18:37 dukeleto so we need benchmarks that constantly modify many long-lived PMCs
18:37 cotto_work dukeleto: the md5sum test is slowed down measurably
18:37 cotto_work the PMCs don't need to be long-lived
18:39 lateau joined #parrot
18:39 cotto_work (according to plobsing.  I haven't tested it myself.)
18:39 plobsing you just need to do more work with registers than is made up for by GC churn. PCC generates considerable churn, so any "well factored" code improves, whereas more straightforward imperative code suffers
18:40 dukeleto cotto_work: how much has md5 slowed down?
18:40 plobsing dukeleto: >2x
18:40 plobsing on large files
18:45 dukeleto so, do we want generational_gc to stay merged? Do we care about un-even performance changes in a dev release?
18:45 dukeleto This does not bode well: http://trac.parrot.org/parrot/ticket/2006
18:45 dukeleto I don't think this branch merge followed the merge guidelines
18:46 cotto_work stupid inability to join #perl6
18:46 lateau_ joined #parrot
18:47 dukeleto cotto_work: what irc client are you using?
18:47 cotto_work xchat
18:47 cotto_work 2.8.8
18:47 dukeleto something is borked
18:47 cotto_work clearly
18:47 plobsing dukeleto: I wouldn't be averse to uneven performance if it were *discussed* beforehand. but this is a result of a quick *hack* to get gms working. there is a correct solution, which I feel should have been implemented *before* gen_gc was mereged.
18:48 cotto_work plobsing: that's a big part of my problem with the way this merge was done too.
18:49 dukeleto We have https://github.com/parrot/parrot/blob/maste​r/docs/project/merge_review_guidelines.pod for a reason.
18:49 plobsing also note that before, we were only 100 times worse than C for md5 (on my system), which is nothing to scoff at. now we're between 200 and 250 times worse.
18:50 dukeleto Performance characteristics
18:50 dukeleto How does your branch affect performance on our selected benchmarks? For hosted languages? Does it have memory leaks? Does it affect memory use or startup time? We have traditionally let these questions go unanswered, but we can be more disciplined here.
18:50 dukeleto generational_gc did not get enough testing for these things
18:51 dukeleto i expected it to get merged just after 3.1, and then it would have a month for tuning
18:51 dukeleto merging a huge branch a few days before a release is bad ju-ju
18:52 plobsing what does "selected benchmark" mean? does that mean only the benchmarks which the branch targets or all parrot benchmarks? the use of only the former is what caused this regression to go unnoticed.
18:53 dukeleto plobsing: we need very specific guidelines, such as "these 10 benchmark programs must not show regressions" or something like that
18:53 dukeleto that is how we can move forward, instead of in circles
18:53 dukeleto We keep going in circles of performance. Tweaking, tuning, failing to test, making it waaaay slower, then rinse and repeat.
18:53 moritz real programs > benchmarks
18:54 dukeleto moritz: real benchmarks :)
18:54 plobsing moritz: md5 is a real program
18:55 dukeleto plobsing: can you send a quick email to parrot-dev about exactly how you ran the md5 benchmarks and what you found?
18:55 plobsing dukeleto: I don't think a fixed set of benchmarks is necessarily a good choice. I selected this benchmark because I already "knew" about the potential for regression using common sense.
18:56 plobsing dukeleto: sure thing
18:56 dukeleto plobsing: having no gauntlet of benchmarks to test stuff against is worse, in my opinion
18:56 whiteknight okay, let's come up with a plan right now. Based on what we are seeing, I suggest the generational_gc should not be in the release branch
18:56 dukeleto plobsing: sure, our gauntlet could be found to be not good enough, but then we add things to the guantlet
18:56 cotto_work whiteknight: +1
18:56 whiteknight I don't think we can do enough testing and benchmarking between now and tuesday, along with the necessary tweaking and tuning
18:57 dukeleto whiteknight: +1
18:57 whiteknight so we can unmerge it, or we can take a new branch as the basis for 3.2 and keep master "dirty" with gen_gc
18:57 whiteknight I don't care which strategy is used
18:57 dukeleto whiteknight: let me suggest an easier way
18:57 whiteknight dukeleto: you have the floor
18:57 dukeleto whiteknight: create a new branch from where master is right now. gen_gc2 or whatever
18:58 dukeleto whiteknight: then, go back to the commit before gen_gc was merged, and branch from there
18:58 dukeleto whiteknight: call that new_master or something
18:59 dukeleto whiteknight: then merge new_master into master, which should wipe out the gen_gc merge,
18:59 dukeleto and then we still have the gen_gc2 branch pointed at what is master right now
18:59 dukeleto i am not sure if other stuff has been added to master since the gen_gc merge. I assume not much.
19:00 whiteknight that's fine. Like I said, I don't care about the mechanism, only the fact that the release-making branch does not include generational_gc
19:00 whiteknight whoever fixes it first gets to pick how it gets fixed
19:00 dukeleto joy to the world.
19:00 dukeleto works for me, that is just one possible way to skin that yak
19:00 whiteknight that said, we *need* generational_gc in some capacity. The performance benefits to Rakudo are not ignorable
19:01 dukeleto whiteknight: rakudo already bumped their parrot_revision to get gen_gc, so this needs coordination with them
19:01 whiteknight so we should immediately start new work (possibly a new branch) to start properly addressing the write-barrier nonsense
19:01 cotto_work whiteknight: I absolutely agree.  It just wasn't merged with due diligence.
19:01 dukeleto moritz: what are your thoughts?
19:01 whiteknight that means we need to identify (or create) some key benchmarks that show different aspects of the performance changes
19:02 dukeleto the md5 and sha examples are probably pretty decent benchmarks. We obviously need more, though.
19:02 whiteknight the MD5 one is probably a great candidate. We do need things that are garbage hungry to emulate PCT and NQP applications
19:02 whiteknight everything in the middle
19:02 dukeleto we need benchmarks written in NQP
19:03 whiteknight that should definitely be a set of them, yes
19:04 lateau_ left #parrot
19:04 whiteknight Okay, action list. I'm going to start spitting out steps. Speak up if you want to volunteer for them:
19:04 [hudnix] left #parrot
19:04 whiteknight 1) Unmerge/move generational_gc
19:04 whiteknight 2) identify benchmarks that demonstrate the performance changes (both good and bad)
19:05 whiteknight 3) Start working on a way to make register accesses cheaper
19:05 whiteknight any takers?
19:05 lucian joined #parrot
19:06 moritz dukeleto: I don't really care; we won't base a Star release on this parrot + rakudo
19:06 moritz I too was surprised at the early merge
19:07 minusnine_ left #parrot
19:07 hudnix joined #parrot
19:07 lateau_ joined #parrot
19:08 lucian i was thinking whether java could possibly be coaxed into being a parrot system language/ http://jikesrvm.org/MMTk
19:08 mikehh I think bacek and I were both a bit tired and we all the tests to pass and rakudo and winxed I said go ahead and merge it
19:08 mikehh we got all
19:09 mikehh and rakudo built a lot quicker
19:09 whiteknight mikehh: that's fine. Like I said, we do want this
19:09 whiteknight we just want to make sure it's right, and with some effort it can be right
19:10 plobsing lucian: Java is coaxable to be a Parrot system language, sure. But just try to get most Parrot developers to spend their volunteer time writing Java.
19:11 lucian plobsing: well, they wouldn't have to. it would only be useful if it was compatible with existing java code
19:11 plobsing lucian: there was even a paper written about integrating Jikes w/ Parrot. Not sure how far they went.
19:11 plobsing lucian: Java-the-language is fairly easy. It is Java-the-kitchen-sink which is tricky. And yes, I've looked at GNU Classpath
19:12 lucian plobsing: i'll look for that paper. at least jikes doesn't assume the kitchen sink
19:13 lateau_ left #parrot
19:14 lucian plobsing: i think classpath is reasonably tame in that the VM-specific bit is small. classpath itself is a bit crap, though
19:15 plobsing lucian: the main issue highlighted by classpath is incremental implementation does not see incremental benefit because the whole thing is so highly self-referential
19:16 dalek parrot: 6e5cd4a | dukeleto++ | tools/dev/headerizer.pl:
19:16 plobsing it's kinda like your "need python core objects to implement python core objects" issue taken to the nth degree.
19:16 dalek parrot: Remove a remnant of the dark days of Subversion
19:16 dalek parrot: review: https://github.com/parrot/parrot/commit/6e5cd4ac6f
19:16 lucian plobsing: yeah, i get it
19:16 lucian mostly i'd like to steal jikes' gcs
19:18 mikehh I think we are looking at commit d5a6bc669b77742316cac48b23cb6fd0a708b773 as pre-merge
19:18 whiteknight I read that immix paper this morning. Very interesting stuff
19:19 whiteknight There are some things I think we can easily steal from there for our fixed-size allocators and our PMC/STRING allocators
19:19 whiteknight line-based allocations and lazy sweep could each be implemented relatively quickly for some gain
19:20 whiteknight if GC pauses are a problem, lazy sweep would shrink those significantly
19:21 whiteknight line-based allocators with bump-pointer allocations would be an improvement over our current free-list allocator in most counts
19:21 whiteknight there's a question about how much extra memory bloat and fragmentation we would suffer
19:21 dalek Heuristic branch merge: pushed 19 commits to parrot by leto
19:22 Coke dukeleto: you might want to run "ack -Q '$Id$'" - there's more than one there.
19:22 lucian whiteknight: i think there's been research about how most mallocs are bad for gcs for a while now
19:23 whiteknight lucian: we already don't use malloc much. Only to allocate the initial arenas
19:23 lucian whiteknight: i see
19:23 Coke um, we shouldn't be making our docs point to github.
19:23 whiteknight once we have the arenas, we're doing slab allocations and management
19:24 Coke msg dukeleto you might want to run "ack -Q '$Id$'" - there's more than one there.
19:24 aloha OK. I'll deliver the message.
19:24 sri left #parrot
19:24 Coke msg dukeleto - -1 on making all those links point to github. we should be making them work with "make html".
19:24 aloha OK. I'll deliver the message.
19:24 plobsing why do we use malloc for arenas? those are large allocations. shouldn't we be using mmap or sbrk directly?
19:24 lucian whiteknight: slabs within the arenas, right
19:24 whiteknight plobsing: maybe, yes
19:24 Coke msg hackbinary - -1 on making all those links point to github. we should be making them work with "make html".
19:24 aloha OK. I'll deliver the message.
19:24 sri joined #parrot
19:24 lucian it wasn't clear to me from reading the docs what sizes the arenas are
19:25 whiteknight lucian: in Parrot's GC, "slab == arena". Pools contain multiple arenas
19:25 lucian in the gengc
19:25 whiteknight we should probably update the terminology one day
19:26 dalek parrot: 93710cd | dukeleto++ | tools/dev/merge_pull_request.pl:
19:26 dalek parrot: [tools] Script to make merging pull requests easier
19:26 lucian whiteknight: a "legend" would probably be enough
19:26 dalek parrot: review: https://github.com/parrot/parrot/commit/93710cd7ab
19:26 lucian i do understand that docs aren't written yet because the code's so new
19:26 dukeleto Coke: feel free to fix stuff, but I merged that stuff already
19:27 * dukeleto would like feedback on tools/dev/merge_pull_request.pl
19:27 dukeleto it just saved me about 5 minutes, using it for one pull request
19:28 dukeleto i hope it makes peoples lives a bit easier
19:28 dukeleto it will even stash working copy changes if you have them
19:28 dukeleto it requires wget and autodie right now, but we can fiddle with that. I just wanted something that worked *right now*
19:30 dalek parrot: 56df0ae | dukeleto++ | docs/glossary.pod:
19:30 dalek parrot: [doc] Make the link point to the canonical repo
19:30 dalek parrot: review: https://github.com/parrot/parrot/commit/56df0ae0d7
19:32 lucian plobsing: i keep coming back to the same issue, the lack of a good system language that isn't C
19:32 plobsing winxed is unacceptable for some reason?
19:32 lucian plobsing: i mean lower than parrot, for implementing parrot itself
19:33 lucian jikes has nice gcs because the language is nicer
19:33 lucian partly, i mean
19:33 Coke dukeleto: I'll open a ticket.
19:33 dukeleto Coke: danke
19:33 lucian plobsing: for pynie, winxed does indeed look like the best option
19:33 lateau_ joined #parrot
19:34 whiteknight lucian: One thing not to overlook is that we have several extremely competent C coders on the team right now
19:34 whiteknight lucian: on a different language, maybe not so much expertise
19:34 lucian whiteknight: sure, and they do awesome work
19:34 whiteknight damn straight
19:34 whiteknight :)
19:34 lucian whiteknight: on a higher level language though, i'm pretty sure these great C coders would keep doing great work
19:35 lucian cyclone, bitc or something else
19:36 whiteknight we certainly can't use cyclone. We need pointer arithmetic for the GC, and we need setjmp/longjmp for exceptions
19:37 whiteknight other than that, I like the concept
19:37 lucian D is very nice, it's just kinda immature right now
19:37 plobsing cyclone, bitc, and c-- are decent options from a certain perspective
19:37 Coke D++
19:37 Coke er, I like D.
19:37 lucian Coke: sure, let's not do another C++ :)
19:38 plobsing I kinda agree with Linus' exclusion argument against C++ for C++ and Java
19:38 whiteknight what argument is that?
19:39 plobsing we don't want the contributions of those that require such languages to acheive results in stead of C
19:39 lateau_ left #parrot
19:39 plobsing such languages can enable great power. but they can also be used as a crutch.
19:39 whiteknight from everything I've read, I've always thought Linus's attitude towards certain languages is a bit assinine
19:40 lucian plobsing: no offence, but i think that's elitist and silly
19:40 whiteknight C++ isn't a great language, but choice of C++ does not a bad programmer make
19:40 lateau_ joined #parrot
19:40 whiteknight choice of Java? maybe. :)
19:40 GodFather joined #parrot
19:40 plobsing no, but the requirement of C++ to get results does.
19:40 whiteknight no, that's true. If you can do it in C++ you should be able to do it in C
19:41 whiteknight personally, if we had a language that was basically "C with thin classes", I would take it
19:41 lucian then you can do it in assembly too
19:41 lucian whiteknight: vala?
19:41 AzureSto_ joined #parrot
19:41 whiteknight lucian: right. It's a matter of trading off and getting results in a timely manner
19:41 plobsing vala for parrot would be cool
19:41 whiteknight deep down we all want to be writing assembly. We just can't find the time
19:41 lucian plobsing: you mean like a HLL?
19:42 plobsing no, like Vala, but swap PMC for GObject
19:42 lucian whiteknight: except for me, who'd rather write the highest level possible langauge :)
19:42 lucian plobsing: right. well, that's not too far from Close
19:42 benabik whiteknight: No, I've been very very happy with writing C++ for school.
19:42 lucian s/write/write in/
19:42 plobsing lucian: that's similar to what Close promised. I think it diverged somewhat from that.
19:43 lucian plobsing: it's dead now anyway
19:44 whiteknight I still do think that a GObject-based MOP for Parrot as one option would be a very good thing
19:44 AzureStone left #parrot
19:44 lucian whiteknight: in fact, gobject interop is a requirement for gtk. and with gobject-introspection it's not bad at all
19:44 whiteknight right
19:45 plobsing wait? I thought the GObject-based MOP was to create an optional GObject repr, not to base all parrot objects off of GObject.
19:45 whiteknight no, I wanted to use gobject as our underlying object system. At least as one pluggable option
19:45 plobsing isn't GObject single-inheritance?
19:45 whiteknight 6model should probably be our default still
19:45 cotto_work whiteknight: I thought the same thing as plobsing
19:46 whiteknight we wouldn't need to base all parrot objects off a GObject MOP. It could be separate and distinct from our normal PMCs and from Class/Object system now
19:46 whiteknight or 6model
19:46 whiteknight But we could have a GObjectClass type, which manages and instantiates GObject PMCs
19:46 plobsing ah, so the PMC/Object dichotomy all over again
19:47 whiteknight parrot should be able to support multiple pluggable MOPS. At least eventually
19:47 whiteknight and a good GObject interface will be a major boost to Parrot getting integrated to gtk applications
19:48 lucian whiteknight: i don't see how that'll work
19:48 plobsing mono is used for a lot of Gtk stuff. It's base objects aren't GObject are they?
19:48 lucian the pluggable MOPs i mean
19:49 plobsing as is python. same deal.
19:49 whiteknight I'm sure mono has wrappers or mappers between it's objects and GObject
19:49 whiteknight same with python. There's got to be a translation step, or a wrapper type
19:49 plobsing zomg heating up these benchmarks takes so long
19:50 mj41_ joined #parrot
19:50 lucian whiteknight: wrappers. there's a mono/python-level GObject you get that all GObject objects inherit
19:50 lucian and it's rather foreign much of the time
19:50 dalek TT #2007 created by coke++: documentation now links offsite
19:50 dalek TT #2007: http://trac.parrot.org/parrot/ticket/2007
19:50 dukeleto plobsing: if you describe exactly how you are running benchmarks, i can put them in a cron job on the gcc compile farm or something
19:50 dukeleto plobsing: hint hint
19:51 plobsing dukeleto: I'm nearly done. I just have to run hexdump.winxed 3 more times on libc.a
19:51 whiteknight lucian: In Parrot, if I do a "$P0 = new ['Foo']", we look up a class object with that key and instantiate it. There's no reason why that class object we find has to be a Class PMC. It could be registered as any other type of PMC
19:51 whiteknight then there's no reason why it couldn't be a GObjectClass object, without the user ever having to know
19:52 whiteknight so long as we implement the necessary interfaces, we should be able to use any kind of class object we want for instantiating a class. And as long as we use methods and vtables at the parrot level, anybody can communicate with it
19:52 lucian whiteknight: right, then it's nothing too fancy
19:52 mj41 left #parrot
19:52 whiteknight it doesn't need to be fancy
19:52 mj41_ is now known as mj41
19:52 plobsing I can see why that would be cool. I'm not convinced it would be desirable. It has the potential to create a set of mutually slightly incompatible parrots and affiliated libraries.
19:53 whiteknight it certainly doesn't need to be disruptive or even obvious
19:53 lucian i thought it was something like CLOS's MOP, which is a tad insane
19:53 bluescreen left #parrot
19:54 lucian plobsing: i'd also rather see something like $P0 = GObject.new ['Bla'] and $P1 = Python.new ['bla']
19:54 benabik I would think that it could be done inside 6model's idea of HOW/REPR.  GObjectClassHOW and GObjectREPR.
19:54 cotto_work I'd really like to see something like that.
19:55 cotto_work that has the potential for some shiny interop between disparate systems.
19:55 lucian yeah, as long as all object systems define how they can be used
19:55 lucian in terms of native parrot types/operations
19:55 benabik lucian: Couldn't the translation layer (HOW) handle that?
19:56 lucian benabik: i don't know, i'm not familiar with 6model
19:56 lucian but i don't think a translation is possible in general, N to N
19:56 whiteknight if i have a type registered, I shouldn't need to know what object system that type uses
19:56 whiteknight get an object, use the object, never worry about how it's implemented
19:57 lucian whiteknight: but how do you use it? even between python and ruby (which are quite similar in many ways) that wouldn't work
19:57 lucian ruby has only methods and no attributes or functions
19:57 lucian python has no methods and only attributes and functions (for methods)
19:58 lucian how do you fetch a method?
19:58 benabik Look up an attribute and see if it's a function?
19:59 lucian benabik: and if it's a ruby object?
19:59 whiteknight what does a method call look like in python?
19:59 lucian what if you set an attribute
19:59 lucian in python, that could mean replacing a method
20:00 whiteknight lucian: for any object, you still have to know it's interface
20:00 lucian whiteknight: the attribute is fetched, if it's a function it gets called with self as the first argument
20:00 whiteknight but the interface is the only thing you need to know. Not the internal representation
20:00 plobsing dukeleto: benchmarks sent
20:00 lucian whiteknight: that's what i'm saying, the interface can only give a lowest common denominator, which is useless
20:00 dukeleto plobsing++
20:01 whiteknight I could make a class in NQP that has no methods, but can return functions through the get_attr_str vtable
20:01 whiteknight lucian: and there's no reason that python-on-parrot objects can't implement VTABLE_find_method, to search for attributes and return PMCNULL if the attribute it finds is not invocable
20:02 lucian whiteknight: sure, but i don't think a general interface can be made
20:02 whiteknight lucian: the vtable is the general interface
20:02 lucian whiteknight: how would inheritance work?
20:02 whiteknight however you want it to work. that's a problem for the object designer, not the object consumer
20:03 whiteknight if the question is "can a python class inherit from a ruby class" the answer might be "no"
20:03 lucian whiteknight: yeah, i meant inheritance by the consumer
20:03 plobsing lucian: classes implement 'add_method'. in python that's equivalent to 'add_attribute'. in other languages it may not be.
20:03 lucian some APIs require inheritance
20:04 whiteknight well, if I do find_method on a python object, it could ask it's class to find the attribute. When the class can't find it, it delegates up the chain of inheritance. That asks the ruby parent class for a method, which it can return
20:04 whiteknight so long as everybody respects the vtable interface, no harm no foul
20:04 lucian whiteknight: hmm
20:04 lucian plobsing: how would that work for purely functional languages?
20:04 bluescreen joined #parrot
20:04 whiteknight right now the linearization routine (C3) is provided by Parrot and is not pluggable, but that could be changed
20:05 lucian whiteknight: that's not a big deal, most multiple inheritance languages use C3 anyway
20:05 whiteknight right, that's why nobody has bothered to make it pluggable yet
20:05 plobsing lucian: purely functional language implementers have mapping their ideal math into an imperative world down to a fine art.
20:06 lucian plobsing: heh, nice way of putting it
20:06 lucian so the interface is the PMC's vtable? that's exceedingly simple
20:06 lucian i wonder if it'll work
20:07 lucian my brain keeps bugging me that something doesn't quite fit
20:07 lucian i probably just need to read more
20:07 lateau_ left #parrot
20:08 whiteknight lucian: that said, the vtable interface is clearly not perfect right now, so it does need some teaks
20:08 whiteknight tweaks
20:08 whiteknight but there are a lot of commonalities in operations between objects and metamodels
20:14 lateau_ joined #parrot
20:16 atrodo is rakudo not building a known issue?
20:19 cotto_work there's tt #2006 that masak++ filed
20:20 atrodo Yep, that looks like the error that isparrotfastyet is getting
20:25 lateau left #parrot
20:28 whiteknight Hackbinary: ping
20:30 dalek nqp-rx: 14741af | moritz++ | src/HLL/Grammar.pm:
20:30 dalek nqp-rx: change error reporting in <charspec>
20:30 ryan left #parrot
20:30 dalek nqp-rx:
20:30 dalek nqp-rx: This makes no difference in nqp itself, but in rakudo the old way caused a
20:30 dalek nqp-rx: "Method 'paniuc' not found for invocant of class 'Regex;Match'
20:30 dalek nqp-rx: review: https://github.com/perl6/nqp-rx/commit/14741af69c
20:30 dalek nqp-rx: e18bf4e | moritz++ | src/stage0/ (3 files):
20:30 dalek nqp-rx: update bootstrap files
20:30 dalek nqp-rx: review: https://github.com/perl6/nqp-rx/commit/e18bf4e643
20:37 cotto_work dukeleto: do you have the tuits to put gen_gc into its own branch?
20:41 dukeleto cotto_work: hmm
20:41 dukeleto cotto_work: what exactly do you want me to do?
20:42 dukeleto cotto_work: has no one volunteered to fix the mess yet?
20:42 cotto_work dukeleto: nope
20:42 whiteknight dukeleto: pick whatever strategy you prefer
20:42 * dukeleto doesn't understand why he isn't smart enough yet to not volunteer for this stuff
20:43 whiteknight I can do it myself, but it would have to happen later tonight
20:45 AzureStone joined #parrot
20:45 lateau_ left #parrot
20:46 dalek parrot: 2d62367 | plobsing++ | / (4 files):
20:46 dalek parrot: macro hygiene
20:46 dalek parrot: review: https://github.com/parrot/parrot/commit/2d62367d32
20:46 dalek parrot: 2ee7af9 | plobsing++ | include/parrot/context.h:
20:46 dalek parrot: dedup macros
20:46 dalek parrot: review: https://github.com/parrot/parrot/commit/2ee7af9178
20:46 dalek parrot: 5829c74 | plobsing++ | include/parrot/context.h:
20:46 dalek parrot: optimize non-gcable register access (somewhat mitigates WB issues)
20:46 dalek parrot:
20:46 dalek parrot: chromatic++ for idea
20:46 dalek parrot: review: https://github.com/parrot/parrot/commit/5829c741fc
20:47 dukeleto BLARG
20:47 dukeleto can everyone stop committing to master right now?
20:47 dukeleto plobsing: ^^^
20:48 AzureSto_ left #parrot
20:48 plobsing I'm done. I was just trying chromatic's gen_gc regression mitigation. Sorry.
20:50 whiteknight plobsing++
20:50 dukeleto plobsing: save those commits locally, 'cause i am stomping on them right now
20:50 darbelo How much does it mitigate?
20:51 whiteknight we should be able to add in dummy read/write macros for string and pmc types right now.  When we're ready to update ops2c we can make use of them
20:51 dukeleto plobsing: can you push those to the gen_gc2 branch ?
20:52 dalek parrot: b1d3cb5 | dukeleto++ | / (44 files):
20:52 dalek parrot: Revert "Generational GC enters the building. Merge generational_gc branch"
20:52 * dukeleto does a force push, hopefully nobody notices
20:53 dalek parrot:
20:53 dalek parrot: This reverts commit b55f22f6757b9f77fb851a07f69ddec1a708f329, reversing
20:53 dalek parrot: changes made to d5a6bc669b77742316cac48b23cb6fd0a708b773.
20:53 dalek parrot: review: https://github.com/parrot/parrot/commit/b1d3cb567d
20:53 dalek parrot/gen_gc2: 2d62367 | plobsing++ | / (4 files):
20:53 dalek parrot/gen_gc2: macro hygiene
20:53 dalek parrot/gen_gc2: review: https://github.com/parrot/parrot/commit/2d62367d32
20:53 dukeleto plobsing: nm, did it already
20:53 dalek parrot/gen_gc2: 2ee7af9 | plobsing++ | include/parrot/context.h:
20:53 dalek parrot/gen_gc2: dedup macros
20:53 dalek parrot/gen_gc2: review: https://github.com/parrot/parrot/commit/2ee7af9178
20:53 dalek parrot/gen_gc2: 5829c74 | plobsing++ | include/parrot/context.h:
20:53 dalek parrot/gen_gc2: optimize non-gcable register access (somewhat mitigates WB issues)
20:53 dalek parrot/gen_gc2:
20:53 dalek parrot/gen_gc2: chromatic++ for idea
20:53 dalek parrot/gen_gc2: review: https://github.com/parrot/parrot/commit/5829c741fc
20:54 dukeleto ok, generationa_gc branch is unmerged, now lives in the gen_gc2 branch, with plobsing++'s recent tweaks
20:54 dukeleto You all owe me beer.
20:54 whiteknight dukeleto: I'll put one in the mail right now
20:54 cotto_work dukeleto: sure.  Catch me at YAPC::EU.
20:54 cotto_work (or sooner)
20:54 dukeleto i didn't test stuff, i just unmerged, so master might be borked right now
20:54 dukeleto please test
20:55 whiteknight I've been squirreling away extra change in my "buy dukeleto a beer" jar for a while now
20:55 cotto_work deal
20:55 * dukeleto hopes it is a very large jar
20:55 whiteknight not nearly as big as my "buy bacek more computer chips" jar, but still pretty big
20:55 plobsing left #parrot
20:56 darbelo left #parrot
20:58 cotto_work msg bacek We've reverted the gen_gc branch merge.  There are some performance regressions that need to be addressed (plobsing++ started on these), and the branch was merged without nearly enough discussion beforehand.  We'll most likely re-merge just after 3.1 is kicked out and continue work from there.
20:58 aloha OK. I'll deliver the message.
21:01 * dukeleto just sent an email to parrot-dev as well
21:03 dukeleto You are all very lucky that you didn't have to read http://www.kernel.org/pub/software/scm/g​it/docs/howto/revert-a-faulty-merge.txt
21:03 cotto_work It took 4 seconds for my eyes to glaze over.
21:04 cotto_work To be fair, I'm definitely feeling how late I stayed up last night.
21:05 dukeleto git revert -m 1 is all I did, and that seemed to work
21:06 arnsholt "In such a situation, you would want to first revert the previous revert" Oh god, it sounds like redo in Emacs...
21:11 dalek TT #451 closed by cotto++: Anticipated changes to bytecode
21:11 dalek TT #451: http://trac.parrot.org/parrot/ticket/451
21:12 Hackbinary whitenight: pong
21:12 pmichaud good afternoon, #parrot
21:13 pmichaud gc_gen branch discussion is .... interesting.  :-)
21:14 fperrad left #parrot
21:15 whiteknight Hackbinary: we received your CLA. At the next #ps meeting somebody can nominate you to become a committer now
21:15 dukeleto pmichaud: howdy
21:15 Hackbinary ah, okay cool
21:16 whiteknight Hackbinary: Somebody will nominate you, and somebody will offer to mentor you, and if there's a positive vote you get the commit bit
21:16 dukeleto pmichaud: we unmerged the generational gc due to performance regressions
21:17 dukeleto pmichaud: but we just need to tweak a few things and it will mostly likely be merged just after 3.1 goes out
21:17 Hackbinary cool
21:17 pmichaud dukeleto: yes; I'm fine with whatever you all decide to do.  I think it points to continued difficulty with the deprecation policy, though
21:17 whiteknight pmichaud: yeah, don't worry. We are definitely going to merge it, we just don't want to rush
21:18 pmichaud I totally agree it had to be unmerged
21:18 Hackbinary whiteknight:  I promise not to break anything ... I'm pretty conservative about changes
21:18 whiteknight Hackbinary: good. If you break something we take away your birthday
21:19 pmichaud I'm very eager for its performance benefits for Rakudo, but (1) not within 5 days of a Parrot release, and (2) not without a mention in the deprecations file, and (3) not at the expensive of huge performance regressions elsewhere, and ...
21:19 Hackbinary hmm ..... would that mean I stop aging?
21:19 Hackbinary ;)
21:19 pmichaud *expense
21:20 atrodo The revert made my building of rakudo work again
21:20 whiteknight pmichaud: definitely after the release. I think we're all willing to "bend" the deprecation policy because this change is so fundamentally important
21:20 whiteknight we don't want to wait until after 3.3 for it
21:20 pmichaud it doesn't matter that much to Rakudo anyway at this point -- the next rakudo Star isn't slated until April
21:20 whiteknight still, we want to have a lot of experience with the performance changes
21:21 pmichaud although if gen_gc lands in 3.2 we might issue a special R* to grab it
21:21 pmichaud but we're kind of hoping that by then R* will be using the new 6-model based NQP
21:21 whiteknight it will definitely be in place shortly after 3.1
21:21 pmichaud yeah, that's the other reason it shouldn't be in 3.1 -- I suspect it broke the new nqp
21:21 pmichaud I don't think anyone's tested that
21:22 whiteknight I wasn't aware it was ready for testing
21:22 pmichaud that's kind of not the point, though
21:23 pmichaud the point is that it would be a huge example of a non-deprecated/non-noticed change breaking a HLL
21:23 Hackbinary seen coke
21:23 clunker3_ Coke was last seen on #parrot 1 hour, 46 minutes and 8 seconds ago, saying: er, I like D.
21:23 clunker3_ coke was last seen on #parrot 2 years, 5 months, 21 days, 18 hours, 2 minutes and 51 seconds ago, saying: I'll get you an answer on that one by Friday.
21:23 aloha coke was last seen in #parrot 1 hours 46 mins ago saying "er, I like D.".
21:23 whiteknight pmichaud: so what is your suggestion, wait until 3.3?
21:24 pmichaud no
21:24 pmichaud (more)
21:24 pmichaud I'm not arguing for/against any specific action, other than what you've already done (revert until after 3.1).  I just find it interesting from a process perspective.
21:24 pmichaud something still isn't right somewhere if this could happen again
21:24 Hackbinary coke, that's cool, I'll fix it.  I asked lastnight about it, but not very many people where online
21:25 whiteknight pmichaud: Everybody here knows that I would like to light the deprecation policy on fire, snort the ashes, and dance a happy dance about it. I'm trying not to make many decisions about this whole issue
21:26 pmichaud anyway, I agree with whatever parrot decides to do.  If it were me, I'd probably do what you propose -- i.e., say "it's too big an improvement to wait until 3.4"  (which is how long it would have to wait in order to follow the deprecation policy, and 3.6 would be the next supported release with the improvement)
21:26 pmichaud I'm just really glad we're on 3-month deprecation cycles instead of 6-month
21:26 pmichaud 6-month would've been... horrible
21:26 plobsing joined #parrot
21:27 whiteknight I do forsee the argument being made that GC write barriers aren't covered by the deprecation policy. I'm not saying it, but I expect it will be said before the issue is resolved
21:27 whiteknight fair warning
21:28 pmichaud I think they have to be considered part of the dep policy (more)
21:28 pmichaud if we expect HLLs and other users to create custom PMCs (and that's been a core component of Parrot's design since day 1), then the requirement to add GC write barriers is part of the API.
21:28 pmichaud we can't say "custom PMCs aren't part of the API" -- they have to be.
21:29 whiteknight I will say that this represents a weird case. It's difficult to deprecate something we don't have, so that it can be safely added. It's also not like there is any real way we could have both solutions available simulaneously
21:29 whiteknight that is, we can't really have a release where we both have and do not have write barriers so the users can safely migrate
21:30 whiteknight in any case, I have to catch a train. Later
21:30 pmichaud later
21:30 plobsing I'll point out that I mentioned the dep policy WRT read/write barriers back in *September*
21:30 pmichaud plobsing++  :-)
21:30 whiteknight left #parrot
21:31 moritz don't we have pluggable GCs?
21:32 plobsing we do. so it should be possible to use ms2 even after gms lands.
21:32 pmichaud would it be possible to keep ms2 as the default, and let a HLL switch to gms?
21:33 plobsing but that does not resolve the issue that gms is the default GC, and that the optimizations that were removed (the perf regressions) were removed universally
21:33 moritz so why not make gen_gc available via a command line option, so that people can test the deprecation that way?
21:33 moritz ok, the optimizations are a good point
21:33 pmichaud agreed fully
21:34 nwellnhof joined #parrot
21:34 nwellnhof ~
21:35 pmichaud anyway, we'll all manage it as best we can.  plobsing++ on noticing the performance regressions for non-GC heavy code
21:35 pmichaud I completely agree that's a problem that needs addressing before the merge
21:36 pmichaud tbh, I wasn't expecting gc_gen to be able to merge (because of deprecation/policy issues) until well after 3.1.
21:36 pmichaud and only in 3.2 or 3.3 with a policy exception
21:36 cotto_work It's not so much a problem of the deprecation policy as of that policy being ignored.
21:36 mtk left #parrot
21:36 pmichaud cotto_work: yes, I think that's what I'm trying to say
21:36 pmichaud it's a process and cultural issue
21:37 cotto_work yes
21:38 pmichaud afk, kid pickup from school
21:38 pmichaud see you all later
21:38 pmichaud also, I'll be largely afk for the next 5 days -- we're taking a last-minute vacation this weekend
21:38 pmichaud the folks on #perl6 can answer any critical questions you might have, or email me.
21:38 cotto_work pmichaud: have fun!
21:48 Coke pmichaud: be well.
22:01 benabik master builds, passes tests, and builds rakudo on Darwin/x86
22:02 wknight-phone joined #parrot
22:05 lucian i don't mean to be insulting, but how many parrot users are there?
22:05 lucian i don't think deprecation matters at this point
22:05 lucian everyone outside #parrot thinks parrot's getting rewritten the 3rd or 4th time, and avoiding it until someone announces "the fresh new parrot has arrived"
22:06 plobsing lucian: 5. I know because we phone home with usage stats.
22:07 rurban_ joined #parrot
22:08 lucian plobsing: parrot phones home? cool
22:09 rurban left #parrot
22:09 rurban_ is now known as rurban
22:10 Hackbinary I'm also using parrot to run my l33t 16 node bbc, running pcboard 16, customized to the max
22:10 plobsing but, all jokes aside, even if we do not have a lot of users, a conservative approach is likely the best approach for *attracting* users and retaining them
22:10 lucian plobsing: sure, after you can say "lorito is done, we have pluggable gc and jit"
22:11 lucian before that, it's unlikely people will care much
22:11 plobsing parrot has historically taken the other approach "full ahead, consequences be damned" and burned out a lot of depending projects
22:11 lucian right
22:11 plobsing partcl is a recent, and perenial (it seems), example of this
22:13 ryan joined #parrot
22:14 Coke of course, considering partcl an actual "user base" would be overselling it, but yes, it's certainly a PITA to keep up, even with the deprecation policy.
22:14 Coke but for some time, it was the canary in the coal mine.
22:15 plobsing you do that to enough developers, you'll build up a reputation, and no amount of shiny will attract the good developers.
22:16 lucian plobsing: well, parrot already has a reputation of not delivering
22:16 lucian i would think shiny, quick could be more attractive
22:16 Coke at this point, I would think "keeping rakudo happy and not breaking lua" is our best bet.
22:17 plobsing I'll take "well thought out" over "runs fast for me" any day. A conservative approach to improvement encourages the former.
22:18 ambs joined #parrot
22:18 lucian plobsing: hopefully. from the extreme skepticism i've been hearing, i'm not so sure
22:18 plobsing I'm not saying the dep policy is perfect. But having standards we hold ourselves to is a Good Thing (TM), even if they may be annoying in the small.
22:20 plobsing and in many cases, we at least have the opportunity to put the notices in. this includes gen_gc.
22:26 dukeleto lucian: i question the fact that HLL's want a pluggable GC. They want a fast GC that works.
22:26 dukeleto lucian: just about 0% of HLL authors want to write their own GC
22:27 lucian dukeleto: of course no one really wants to write one
22:27 dukeleto lucian: so pluggable GC is just abstraction for abstractions sake
22:27 lucian but having several gcs selectable at runtime is a good idea
22:27 dukeleto lucian: i question that
22:27 dukeleto lucian: choosing at compile-time, sure. Run-time? I haven't seen a good sales pitch yet.
22:27 lucian works pretty well for the jvm
22:28 dukeleto lucian: the jvm can switch GC's at run-time ? I wasn't aware.
22:28 lucian you need about 3 classes of gcs
22:28 lucian dukeleto: yeah, it has 4-5 gcs you can select
22:28 dukeleto lucian: i see. It seems more convenient, but when do you actually need to choose a GC at runtime?
22:29 dukeleto lucian: if I am on a real-time OS, i know I need a real-time GC at compile time
22:29 dukeleto lucian: if I am on a phone, I know I want the mobile-friendly-gc
22:29 lucian many music processing apps choose a real-time gc on the jvm
22:29 dukeleto lucian: when do you not know which GC you want until runtime?
22:29 lucian applications might want different gcs
22:29 dukeleto lucian: sure, which they can choose at compile-time. Why would they wait until run-time ?
22:30 dukeleto lucian: i agree. I just don't see the need to work on the engine of a car while driving it 90mph on the highway.
22:30 lucian compile-time of what?
22:30 lucian compile-time of the app, run-time of parrot
22:31 dukeleto lucian: well, a GC can already be chosen with command line arguments to the parrot binary
22:31 lucian dukeleto: sure, that's what i meant
22:31 dukeleto lucian: but once you choose, that is it. No changing it half-way through execution
22:31 ambs left #parrot
22:31 lucian of course, the jvm can't do that either
22:31 dukeleto lucian: ah, ok. We are back on the same boat.
22:31 lucian yeah :)
22:32 * nwellnhof notes that JIT can help a lot with pluggable GCs
22:32 plobsing still, until you've exhausted all other avenues, you really shouldn't be doing that
22:32 lucian when i listed that as shiny, i meant a few pluggable gcs
22:32 dukeleto lucian: let's concentrate one making *one* really good first, but I agree.
22:32 lucian so your app could choose the slow-but-low-memory or the fast-but-high-memory or the slow-but-incremental gc
22:32 lucian dukeleto: yes, of course
22:33 lucian but the potential to do this would be enough "shiny" i think
22:33 wknight-phone left #parrot
22:33 dukeleto lucian: we already have that. You can choose a gc now.
22:34 plobsing you could of course have multiple parrots sitting around to provide that functionality. that way, you have the benefits of knowing the GC statically and being able to eliminate read/write barriers for the GCs that don't require them.
22:34 lucian plobsing: i think that's what the jvm does, to some extent
22:34 lucian dukeleto: yes, and it's nice
22:35 nwellnhof you can plug in another mark and sweep GC right now, but that's it. Parrot doesn't support any other type of GC yet.
22:36 plobsing nwellnhof: there is the infinite memory GC. that's something else...
22:36 plobsing and it works great on real turing machines
22:36 nwellnhof it's a mark and sweep GC without marking and sweeping ;)
22:36 lucian plobsing: i'll get you one for your birthday
22:37 lucian btw, i forgot to list http://tachyon.in/clay/ when i was ranting about nicer system languages
22:38 plobsing lucian: great. now I just have to get someone to buy me pushable rope. and some frictionless, massless pulleys.
22:39 lucian plobsing: don't forget the ideal point mass
22:41 ryan Hello,  I'm looking for GSOC ideas and Dukeleto++ informed me that I should speak to some people in the IRC.  Does any one have any ideas?
22:42 nwellnhof ryan: a copying garbage collector
22:44 plobsing ryan: have you looked at http://trac.parrot.org/parrot/wiki/BigProjectIdeas
22:44 vmspb joined #parrot
22:45 ryan no I'll look at that now thanks
22:47 nwellnhof what does "context-threaded runcore" mean?
22:48 ryan I saw this "GObject Metamodel",  this is to work with GTK right?
22:49 ryan is there a project like this for qt?
22:49 lucian ryan: you could implement a SMOKE binding, i guess
22:49 lucian smoke is the qt equivalent of gobject-introspection
22:51 whiteknight joined #parrot
22:53 ryan lucian: sounds cool
22:54 lucian ryan: for example, RubyQt is made with SMOKE
22:54 lucian perhaps you could implement a QObject metamodel with SMOKE, but i don't really know
22:55 ryan thanks
23:00 sorear ryan: before implementing something, make sure it's actually wanted
23:00 whiteknight what is ryan implementing?
23:01 sorear whiteknight: nothing, yet
23:01 * whiteknight has some backloggin' to do
23:01 kid51 joined #parrot
23:02 whiteknight nwellnhof: a context-threaded runcore is a type of runcore
23:02 whiteknight it's a way to dispatch ops
23:03 lucian whiteknight: btw, i think runcores are an awesome feature of parrot
23:04 lucian a way to market parrot would be to look at existing mainline vms and see what they can't do
23:05 plobsing we've already neutered the most interesting aspect of runcores for practical reasons
23:05 plobsing op-dispatch strategy is fixed
23:06 lucian ah. oh well
23:06 plobsing because otherwise we need separate oplibs and supporting stuff for every runcore
23:06 plobsing I'd like to see op-dispatch strategy re-introduced as a compile-time-fixed option
23:07 plobsing what our runcores currently provide is orthogonal to op-dispatch strategy
23:09 vmspb left #parrot
23:11 plobsing they're still really cool though. just less cool than the name implies
23:11 whiteknight a context-threaded runcore could easily be added to parrot as-is
23:11 whiteknight because we could still be using the op function bodies
23:12 lucian right
23:12 nwellnhof is context-threading some kind of poor man's JIT?
23:13 sorear no
23:13 sorear context threading is basically just a reinvention of subroutine-threaded-code
23:13 lucian is it this? http://en.wikipedia.org/wiki/Threaded_code
23:14 sorear check out any Forth book for an explanation of that term
23:15 plobsing it is a JIT in some sense. it has all of the requirements with fewer advantages.
23:17 plobsing IIUC, you need to deal with W^X and generate machine code.
23:17 lucian it's pretty cool. i do think it's named horribly
23:17 lucian plobsing: python's threaded interp is pure C
23:17 plobsing lucian: is it context threaded?
23:18 plobsing op-dispatch strategy is commonly refered to as "threading" regardless of what type it is
23:18 lucian plobsing: don't think so
23:19 lucian plobsing: http://bugs.python.org/issue4753
23:19 lucian nothing fancy at all, just a compiler trick
23:20 Andy left #parrot
23:20 plobsing that's what cgoto (also cgp) did
23:20 arnsholt Does anyone know why PAST::Op(:pasttype<try>) doesn't pop_eh until the end of the recovery clause?
23:21 plobsing and it was worth it sometimes. for some workloads our branch mispredict went from 100% (which it is effectively all the time right now) to 5%.
23:21 plobsing but most workloads aren't dominated by op dispatch
23:21 sorear plobsing: "generate machine code" is not boolean
23:22 sorear plobsing: the x86 instruction encoding is incredibly complex, and I don't fancy writing a full JIT (even non-optimizing), ever
23:22 plobsing sorear: anything that generates machine code at runtime can be classified as JIT in some sense.
23:22 tadzik is amd64 any better?
23:22 sorear but remembering 9F xx xx xx xx where *(int*)(ip+1) = dest - (ip + 5) isn't that hard
23:22 lucian i think a llvm jit would be more useful
23:22 tadzik or is it just extended x86?
23:22 sorear and yes, I know that by heart
23:23 sorear tadzik: amd64 is almost a compatible extension of x86
23:23 lucian i think if you use amd64 in 64 more it's better
23:23 sorear tadzik: they axed setalc to make room for a new encoding form
23:23 tadzik axed setalc?
23:23 lucian you have to put in x86 mode for full compat
23:30 plobsing left #parrot
23:31 nwellnhof left #parrot
23:34 nwellnhof joined #parrot
23:35 plobsing joined #parrot
23:35 whiteknight the benefit to context-threading is that it's not the same weight as a JIT, and you end up with huge cache benefits. opdispatch costs drop down to zero
23:35 whiteknight admittedly our op dispatch costs are not high right now
23:35 whiteknight at least not comparitively
23:36 plobsing cgoto had effectively the same advantage. see how many people cared.
23:36 whiteknight in Lorito world we will conceivably have to execute many more ops to perform the same operations
23:36 whiteknight plobsing: cgoto was a completely different architecture and wasn't supported on one of our key target platforms
23:37 whiteknight context threading will be perfectly supported, requires no fancy features from C99, and can reuse the fast/slow core op libraries and op bodies
23:37 plobsing yes Lorito might make op dispatch important. we should address this when it happens or when it become clear that it is imminent
23:37 plobsing whiteknight: at the cost of dirtying PBC with a direct-threading equivalent.
23:38 whiteknight I don't think runcore improvements are high-priority right now in any case
23:39 whiteknight if somebody implemented it and delivered it to us on a silver platter, awesome.
23:39 sorear whiteknight: now that W^X et al exist I don't think the benefit of context-threading is as big as it once was
23:39 whiteknight what do you mean "W^X"
23:39 whiteknight ?
23:39 sorear write xor execute
23:39 plobsing Write XOR eXecute
23:40 plobsing memory access modes
23:40 whiteknight ah, okay
23:40 plobsing modern OSen often enforce that at any given time only one of these can be set
23:41 sorear whiteknight: ten years ago, when everybody who could run real software ran 32-bit x86 and execute protection wasn't used, you could write a decent context threader in 200 lines of C since JMP, CALL, RET are a tiny subset of the complexity of an assembler
23:41 sorear nowadays:
23:41 whiteknight it's still no so bad with mmap. And we have a PMC for mmapping
23:41 sorear - x86_64 and ARM exist on the desktop
23:41 sorear - a lot of OSes implement execute protection in mutually incompatible ways
23:44 plobsing not to mention, from the explanations I've seen, CTT (context threaded), like DT (direct threaded), requires writting into the op stream. this means the mmapped pages are dirty and cannot be shared.
23:44 Tene arnsholt: you don't pop_eh until the end of the handler because for many situations you want to leave the handler active; anything with resuming the exception, basically
23:44 Tene arnsholt: Let me know if you want more information or examples of that
23:45 arnsholt Resuming the exception is a good point
23:46 Tene arnsholt: when providing flow control support to loops, you don't want to be pushing and popping the eh over and over
23:46 Tene afk meeting
23:46 dalek parrot: 9dadd29 | jkeenan++ | / (19 files):
23:46 dalek parrot: Per TT #2004: Remove remaining references to former '--cxx' option to Configure.pl.
23:46 dalek parrot: review: https://github.com/parrot/parrot/commit/9dadd29c29
23:50 arnsholt Indeed a good point. But it's a bit annoying in my case, which is essentially try { function() } catch { /* Complicated recovery and condition checking goes here. */ }
23:53 arnsholt Ideally, I'd have the pop_eh at the top of the recovery, but if I add pop_eh at the top of my recovery PAST it'll blow up on the automatic pop_eh at the end if it gets through the recovery without a rethrow
23:54 dalek TT #2004 closed by jkeenan++: Where did Configure.pl option '--cxx' go to?
23:54 dalek TT #2004: http://trac.parrot.org/parrot/ticket/2004
23:54 whiteknight arnsholt: you can create a new mini-handler in the try section, to catch errors from your error handler
23:54 whiteknight then do pop_eh\npop_eh
23:56 ryan left #parrot
23:56 arnsholt Hmm. That'd work
23:56 arnsholt A bit hacky, but working and hacky beats clean and broken
23:59 lucian hmm, i might play with writing bits of parrot with clay
23:59 lucian i mean, in clay
23:59 lucian can the gc be plugged in if written in something other than C?
23:59 lucian like plugin in a .so?

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

Parrot | source cross referenced