Camelia, the Perl 6 bug

IRC log for #parrot, 2011-04-30

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:29 GodFather left #parrot
00:45 plobsing ping cotto, bacek
00:47 cotto plobsing, pong
00:48 plobsing can we eliminiate TT #1654? I don't see ops.num anywhere and I suspect recent changes to opsc have eliminated it.
00:48 cotto It's definitely gone.
00:49 plobsing and now, so is the ticket
00:49 cotto It was one of those things where when I asked "Why do we have this?", nobody had a good answer.
00:49 cotto thanks
00:50 cotto plobsing++
00:52 dalek TT #1654 closed by plobsing++: ops2c should complain about ops numbering in ranges
00:52 dalek TT #1654: http://trac.parrot.org/parrot/ticket/1654
00:56 kid51 joined #parrot
00:58 tcurtis Is plumage broken again?
01:02 whiteknight is it?
01:02 whiteknight git you update?
01:03 whiteknight did you update?
01:05 nopaste "tcurtis" at 192.168.1.3 pasted "parrot-nqp Configure.nqp # parrot 3.3" (8 lines) at http://nopaste.snit.ch/42666
01:06 tcurtis whiteknight: it appears to fail to configure for me. I haven't yet looked into the details of the problem.
01:06 whiteknight did you update plumage? That looks like an old error message
01:07 whiteknight and you're getting the new plumage from github?
01:07 tcurtis Github?
01:07 cotto yup
01:08 tcurtis Nevermind. That's likely my problem.
01:08 cotto We need to take the gitorious version down.
01:08 cotto That caught me earlier too.
01:12 tcurtis Plumage from github appears to work.
01:12 cotto good news there
01:12 whiteknight yay
01:24 mtk left #parrot
01:31 mtk joined #parrot
01:40 whiteknight left #parrot
01:45 dalek parrot: a67bfbf | plobsing++ | / (12 files):
01:45 dalek parrot: remove remaining ops.num support infrastructure
01:45 dalek parrot: review: https://github.com/parrot/parrot/commit/a67bfbfb1b
01:49 cotto conf time
01:55 cotto left #parrot
01:55 nopaste left #parrot
02:02 nopaste joined #parrot
02:10 kid51 left #parrot
02:19 dukeleto ~~
02:42 soh_cah_toa joined #parrot
02:42 woosley joined #parrot
02:43 soh_cah_toa anyone familiar w/ rosella? i was wondering if you can use it w/ nqp. it looks like you can
02:46 dukeleto soh_cah_toa: yes, i think it is written in NQP
02:47 soh_cah_toa okay
02:47 dukeleto soh_cah_toa: it is very much designed to be used with NQP
02:47 soh_cah_toa hmmm...i am having THE hardest time deciding which language to use for my gsoc project
02:48 soh_cah_toa for a while, i was leaning towards nqp but now winxed is looking a little better
02:48 soh_cah_toa but a BIG disadvantage is that winxed isn't include w/ parrot. anyone wishing to use the debugger would need winxed and i don't like dependencies
02:49 soh_cah_toa i was kinda hoping i could package the debugger w/ parrot like it is now. but if i use winxed, that's not possible
02:50 dukeleto soh_cah_toa: yeah, that is why using NQP is probably a better idea, but talk with your mentor
02:50 soh_cah_toa yeah we have. he's the one who turned me onto winxed
02:56 bubaflub soh_cah_toa: you could include the PBCs
02:56 bubaflub soh_cah_toa: then you wouldn't require winxed to run, just to build the debugger
02:56 soh_cah_toa hmmm...that's an idea
02:57 soh_cah_toa but how could someone run the tests then?
02:58 soh_cah_toa well, the average user probably won't be needing that anyway. only developers who probably have winxed installed
02:59 dukeleto soh_cah_toa: you could just generate the PIR from the winxed source, and distribute that with Parrot, i guess
02:59 soh_cah_toa ah....that's not a bad idea
03:00 dukeleto soh_cah_toa: any parrot language can generate the corresponding PIR or PBC and you can just store that
03:00 soh_cah_toa right
03:00 dukeleto soh_cah_toa: you don't pay the cost of parsing it every time you run it if you store PBC
03:00 dukeleto soh_cah_toa: something to keep in mind
03:01 woosley left #parrot
03:01 soh_cah_toa that's true
03:07 dafrito joined #parrot
03:08 atrodo coke++
03:12 hudnix left #parrot
03:24 soh_cah_toa left #parrot
03:42 particle1 joined #parrot
03:42 AzureStone left #parrot
03:42 plobsing left #parrot
03:43 plobsing joined #parrot
03:44 particle left #parrot
03:47 AzureStone joined #parrot
03:50 AzureSto_ joined #parrot
03:54 AzureStone left #parrot
03:55 bubaflub left #parrot
03:56 TonyC left #parrot
03:56 nopaste left #parrot
03:56 TonyC joined #parrot
04:02 nopaste joined #parrot
04:06 nopaste left #parrot
04:12 nopaste joined #parrot
05:05 theory left #parrot
05:09 rohit_nsit08 joined #parrot
05:55 plobsing left #parrot
05:55 rohit_nsit08 left #parrot
05:56 cotto joined #parrot
05:56 cotto ~~
06:05 ShaneC joined #parrot
06:06 dukeleto ~~
06:06 * dukeleto just had a nice dinner with cotto++ and now we are planning to take over the world
06:52 benabik_ joined #parrot
06:52 benabik left #parrot
06:52 benabik_ is now known as benabik
06:55 dukeleto benabik: howdy
06:56 benabik dukeleto: Very sleepy but here. What's up?
06:58 dukeleto benabik: sleepy as well. Last minute hacking on my presentation for the morning
06:58 * benabik likes Colloquy's push notifications. Very handy.
07:02 cotto 'night
07:03 benabik dukeleto: Presentations are awesome. Looking back, I guess the howdy was from my login? I think the network hiccuped and my laptop relogged...
07:10 dukeleto benabik: yep. saw you jump back in the channel :)
07:11 fperrad joined #parrot
07:12 benabik dukeleto: Nice to feel welcome, even if I'm not actually there. :-D I'm going to hit the sack. Break a leg with the presentation. :-)
07:18 dafrito left #parrot
07:34 dafrito joined #parrot
08:47 ShaneC left #parrot
08:52 benabik_ joined #parrot
08:52 benabik left #parrot
08:52 benabik_ is now known as benabik
09:39 jrt4__ left #parrot
09:50 dalek parrot: 75c90bf | allison++ | ports/debian/ (13 files):
09:50 dalek parrot: Updating Debian packaging files for Parrot 3.3.0 release.
09:50 dalek parrot: review: https://github.com/parrot/parrot/commit/75c90bf3ba
09:50 dalek parrot: 1bafbdb | allison++ | / (12 files):
09:50 dalek parrot: Merge branch 'master' of github.com:parrot/parrot
09:50 dalek parrot: review: https://github.com/parrot/parrot/commit/1bafbdba38
10:12 mj41 joined #parrot
10:23 luben joined #parrot
10:27 whiteknight joined #parrot
10:37 whiteknight good morning, #parrot
10:51 luben msg pmichaud  I think I know what causes the performance differences that you have observed regarding GC and execution of rakudo testsuite. Improved tri-colour MS2 GC has landed in parrot 3.0. It does not have adaptive triggering - it kicked out every 1/8 of system memory allocated. It wasted a lot of memory and had long pauses. For example, on my system compiling rakudo used 700+ M. In parrot 3.1 Nick Wellnhofer have ported GC adaptive triggeri
10:51 aloha OK. I'll deliver the message.
10:51 luben ng system from MS to MS2 GC core. It compiled rakudo in in 400M but somewhat slower because it kicked more frequently. It also had improved on interactive loads - there were no long pauses. GMS also landed at the same time in master - it does not have adaptive triggering - it kicks minor collection on every 1/100 of system memory allocated. Older generation GC is started on 10 younger generation collection. It has 8 generations. So it wastes a l
10:51 luben ot less memory - it could compile rakudo in 256M of RAM and have further improved interactive behaviour. It does so with the performance of 1/8 bounded MS2 GC. My preliminary experiments show that 3-4 generations are enough and there also a lot other variables to tune - I have not done the extensive test in order to change the current defaults. This is my account of the performance differences that you have ovserved
10:51 luben shit...
10:53 luben msg pmichaud I think I know what causes the performance differences that you have observed regarding GC and execution of rakudo testsuite. Improved tri-colour MS2 GC has landed in parrot 3.0. It does not have adaptive triggering - it kicked out every 1/8 of system memory allocated. It wasted a lot of memory and had long pauses. For example, on my system compiling rakudo used 700+ M. (continued)
10:53 aloha OK. I'll deliver the message.
10:53 luben msg pmichaud In parrot 3.1 Nick Wellnhofer have ported GC adaptive triggering system from MS to MS2 GC core. It compiled rakudo in in 400M but somewhat slower because it kicked more frequently. It also had improved on interactive loads - there were no long pauses. GMS also landed at the same time in master - it does not have adaptive triggering - it kicks minor collection on every 1/100 of system memory allocated. Older generation GC is started
10:53 luben on 10 younger generation collection. (continued)
10:53 aloha OK. I'll deliver the message.
10:54 luben msg pmichaud It has 8 generations. So it wastes a lot less memory - it could compile rakudo in 256M of RAM and have further improved interactive behaviour. It does so with the performance of 1/8 bounded MS2 GC. My preliminary experiments show that 3-4 generations are enough and there also a lot other variables to tune - I have not done the extensive test in order to change the current defaults. This is my account of the performance differences t
10:54 luben hat you have ovserved
10:54 aloha OK. I'll deliver the message.
10:56 estrabd left #parrot
10:57 estrabd joined #parrot
11:02 whiteknight luben: At that point, an email might have been easier :)
11:02 whiteknight luben: although the results look very interesting
11:03 whiteknight luben: so GMS doesn't have adaptive triggering? How hard would that be to implement?
11:23 bacek ~~
11:23 bacek whiteknight, http://trac.parrot.org/parrot/ticket/2023
11:23 mj41 left #parrot
11:23 whiteknight bacek: ah, okay
11:53 dalek parrot/jit_prototype: 9d5bd6c | bacek++ | / (2 files):
11:53 dalek parrot/jit_prototype: Add fetching of ElementType from pointer type
11:53 kid51 joined #parrot
11:53 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/9d5bd6c9d9
11:53 dalek parrot/jit_prototype: 0fea15f | bacek++ | / (3 files):
11:53 dalek parrot/jit_prototype: Implement fetching of TypeKind
11:53 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/0fea15f8d0
11:57 Patterner left #parrot
11:57 Psyche^ joined #parrot
11:57 Psyche^ is now known as Patterner
11:59 kid51 msg luben Can you put your GC findings in a post to parrot-dev?  Thanks.
11:59 aloha OK. I'll deliver the message.
12:07 jsut joined #parrot
12:12 jsut_ left #parrot
12:14 lucian joined #parrot
12:29 hudnix joined #parrot
12:33 nopaste "kid51" at 192.168.1.3 pasted "debug parrot_nci_thunk_gen on darwin/ppc" (13 lines) at http://nopaste.snit.ch/42718
12:34 kid51 msg plobsing nopaste 42718 is what I get on your branch
12:34 aloha OK. I'll deliver the message.
12:41 sjn left #parrot
12:49 sjn joined #parrot
12:53 nopaste "kid51" at 192.168.1.3 pasted "more debugging output" (31 lines) at http://nopaste.snit.ch/42719
12:57 nopaste "kid51" at 192.168.1.3 pasted "still more debugging output" (85 lines) at http://nopaste.snit.ch/42720
13:02 whiteknight apparently I had a copy of libparrot2.6.0 in my /usr/lib folder that I wasn't aware of. All programs were using 3.3.0 *except* winxed, which was using the old versions
13:11 moritz rakudo has some test failures on newest parrot HEAD
13:12 moritz ./perl6 t/spec/S03-metaops/hyper.rakudo
13:13 moritz ...
13:13 moritz ok 141 - hash - correct result from >>!
13:13 moritz Too many positional parameters passed; got 3 but expected 2 in 'hyper' at line 269:CORE.setting in main program body at line 1
13:13 moritz now rakudo changes involved
13:31 whiteknight that's an extremely strange failure
13:31 whiteknight can you get a backtrace?
13:35 moritz a PIR level backtrace, if that helps you...
13:36 nopaste "moritz" at 192.168.1.3 pasted "PIR backtrace from hyper.t" (12 lines) at http://nopaste.snit.ch/42722
13:36 moritz I can try to bisect
13:40 whiteknight that's a very weird failure. I don't think anything has changed in parrot with regards to compiling or argument parsing
13:53 JimmyZ joined #parrot
14:03 JimmyZ_ joined #parrot
14:07 autark left #parrot
14:07 JimmyZ left #parrot
14:08 JimmyZ_ is now known as JimmyZ
14:09 dalek parrot: 16933ea | fperrad++ | src/pmc/boolean.pmc:
14:09 dalek parrot: [PMC] add is_equal for Boolean PMC
14:09 dalek parrot:
14:09 dalek parrot:
14:09 dalek parrot: needed by LOLCODE
14:09 dalek parrot: review: https://github.com/parrot/parrot/commit/16933ea6dc
14:11 tadzik LOL
14:17 whiteknight I wonder how hard it would be to write a bootstrapping LOLCODE compiler
14:18 dalek Rosella/path_refactor: f7fa5f8 | Whiteknight++ | src/core/Rosella.winxed:
14:18 dalek Rosella/path_refactor: Add in a prototype build_r function to build, calling BUILD in parent classes as well
14:18 dalek Rosella/path_refactor: review: https://github.com/Whiteknig​ht/Rosella/commit/f7fa5f8baa
14:18 dalek Rosella/path_refactor: 7a057b6 | Whiteknight++ | s (6 files):
14:18 dalek Rosella/path_refactor: start fleshing out what the new system is goin to look like for Path. Breaking the search algorithm up into searcher classes
14:18 dalek Rosella/path_refactor: review: https://github.com/Whiteknig​ht/Rosella/commit/7a057b669e
14:24 JimmyZ left #parrot
14:37 bubaflub joined #parrot
14:37 bubaflub ~
14:37 cotto ~~
14:44 dukeleto bubaflub: mornin'
14:50 bubaflub mornin' dukeleto
14:51 ambs joined #parrot
14:54 lucian_ joined #parrot
14:55 fperrad_ joined #parrot
14:56 * dukeleto is getting ready for LinuxFestNW with cotto++
14:56 dukeleto bubaflub: i am giving a talk in 2 hours
14:57 bubaflub dukeleto: nice.  is it the one on Jitterbug?
14:58 fperrad left #parrot
14:58 fperrad_ is now known as fperrad
14:58 lucian__ joined #parrot
14:58 kid51 left #parrot
14:59 lucian left #parrot
15:02 dalek Rosella: f7fa5f8 | Whiteknight++ | src/core/Rosella.winxed:
15:02 dalek Rosella: Add in a prototype build_r function to build, calling BUILD in parent classes as well
15:02 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/f7fa5f8baa
15:02 dalek Rosella: 25c805a | Whiteknight++ | s (5 files):
15:02 dalek Rosella: first draft of a new Lazy library. Allows creating lazy proxies, which only instantiate their target objects on demand
15:02 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/25c805ac25
15:02 dalek Rosella: 5c3a13a | Whiteknight++ | src/lazy/ (2 files):
15:02 dalek Rosella: fix lazy library so it builds and passes a few ad hoc tests
15:02 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/5c3a13a9a4
15:02 dalek Rosella/gh-pages: 56a73af | Whiteknight++ | libraries/future.md:
15:02 dalek Rosella/gh-pages: add short blurb about lazy library
15:02 dalek Rosella/gh-pages: review: https://github.com/Whiteknig​ht/Rosella/commit/56a73af257
15:02 lucian_ left #parrot
15:04 utsl left #parrot
15:05 utsl joined #parrot
15:05 cotto bubaflub, yup
15:05 cotto and he just added a slide
15:05 bubaflub cotto: cool
15:05 cotto though I'm still editing and polishing, so I'm hardly one to talk
15:06 autark joined #parrot
15:07 whiteknight cotto: you giving a talk?
15:08 cotto whiteknight, yup
15:09 cotto at 1:30
15:09 whiteknight cotto: what about? Parrot
15:09 whiteknight ?
15:09 cotto of course
15:09 cotto http://www.linuxfestnorthwest​.org/sessions/parrot-state-vm
15:09 whiteknight is it going to be videotaped?
15:09 whiteknight I would love to see that
15:10 cotto no idea
15:10 cotto I'll try to find out though
15:10 whiteknight okay, awesome
15:19 utsl left #parrot
15:19 utsl joined #parrot
15:24 lucian__ left #parrot
15:30 jsut_ joined #parrot
15:31 lucian joined #parrot
15:32 JimmyZ joined #parrot
15:35 jsut left #parrot
15:37 mtk left #parrot
15:37 cotto left #parrot
15:41 benabik ~~
15:41 lucian left #parrot
15:42 lucian joined #parrot
15:44 mtk joined #parrot
15:45 luben whiteknight, kid51, I have send extended post with my GC observations to parrot-dev
15:45 whiteknight luben++
15:47 luben I will have some time these weeks to benchmark GMS and try to tune it for general case. Also I could expose some of its parameters as parrot runtime options
15:54 jsut joined #parrot
15:59 jsut_ left #parrot
16:07 Coke left #parrot
16:07 Coke joined #parrot
16:12 Coke__ joined #parrot
16:13 Coke left #parrot
16:15 kid51 joined #parrot
16:15 kid51 luben, thanks for that post
16:16 JimmyZ left #parrot
16:23 theory joined #parrot
16:23 whiteknight yes, luben++
16:23 whiteknight luben: tunings and exposing some parameters would be awesome
16:24 whiteknight or, just exposing parameters and teaching people how to tune would be fine too
16:24 luben I will work in that direction
16:24 luben some of parameters are hard to expose, e.g. number of generations
16:25 whiteknight yes, I imagine that is tricky
16:25 whiteknight don't kill yourself over it.
16:30 plobsing joined #parrot
16:34 plobsing ~~
16:35 whiteknight hello plobsing
16:35 whiteknight plobsing: I want to set aside some time to chat with you in the coming weeks about packfiles
16:36 whiteknight plobsing: I want to do everything I can to push forward the things Rakudo needs, but I also need to understand them all a little better first
16:37 whiteknight my current strategy of praying every day that you don't get hit by a bus is unreliable
16:37 whiteknight :)
16:38 plobsing kid51: can you get the output of Parrot_dlerror()? You can do that either by turning on PARROT_WARNINGS_UNDEF_FLAG (don't ask me how, I don't know), or by printing out the value of 'const char  * const  err = Parrot_dlerror();' in Parrot_dlfunc_p_p_sc_sc().
16:40 plobsing whiteknight: I beleive I've expressed in the past my belief that the size of our packfiles does not significantly contribute to any runtime costs. I have yet to see benchmarks (on a recent parrot, we used to have issues) that contradict this view.
16:42 whiteknight plobsing: no, not those issues. The other things Rakudo wants about partial serialization
16:42 plobsing also, I know about packfiles by having read through and understood the code and having hex edited PBCs a sufficient number of times. I do not know of any quicker way of comming to this level of understanding.
16:43 whiteknight I don't expect to have the same level of understanding, at east not any time soon
16:43 whiteknight Im trying to understand better what Rakudo needs, what effort that will take, and what (if anything) I can do to help
16:44 plobsing ah, if it is simply delimited serialization you're looking for, that is simpler
16:45 whiteknight that may be it
16:45 whiteknight see, I don't even know what it is that I don't know about
16:45 whiteknight I'm in a bad place :)
16:46 plobsing do you understand what delimited serialization is and how parrot isn't meeting that need?
16:46 whiteknight very very vaguely
16:46 plobsing OK, I'll try to give you the coles notes
16:46 whiteknight they want to be able to partially serialize without following all pointers, then reassemble when we thaw?
16:47 plobsing they want to avoid duplicates in their deserialized object graphs
16:47 whiteknight do they have lots of duplicates now?
16:48 plobsing whiteknight: less so now that we de-dup within a single constant table, but issues arise when working with multiple PBCs.
16:49 cotto joined #parrot
16:49 plobsing for example, rakudo always has the default perl 6 object metaclass loaded. so when I freeze a perl 6 object, I shouldn't store that bit.
16:49 plobsing in fact, the class probably also lives in a separate packfile, so that should also not be stored with the object
16:50 cotto ~~
16:50 plobsing we want to maintain those object graph edges, but also maintain the uniqueness of the nodes.
16:52 plobsing the proposed solution is to store a reference into a different PBC as a placeholder in such situations
16:52 whiteknight ok
16:53 * cotto is about to watch dukeleto give his jitterbug talk
16:53 plobsing there are a few distinct things we need for this to work
16:53 plobsing 1) we need a way of signaling the serializer that an object should be stored as a reference and indicating what that reference should be
16:54 plobsing 2) we need the serializer to act on these indications, storing references
16:54 plobsing 3) we need the deserializer to follow the references appropriately
16:54 kid51 plobsing: I don't know how to do any of what you're requesting.  My knowledge of gdb is minimal and general and less re parrot.
16:54 plobsing 4) we need rakudo/PCT/whatever to generate these hints where it is appropriate
16:56 plobsing kid51: one of your debug lines shows '14143           const char  * const  err = Parrot_dlerror();'. Please run one step beyond that line and print the "err" variable with "p err\n"
17:00 kid51 (gdb) p err
17:00 kid51 $1 = 0x507284 "invalid handle passed to dlsym()"
17:01 plobsing well, then I suspect OSX here isn't respecting the SUS spec on dlsym
17:01 plobsing which we can work around
17:03 kid51 FYI, I'm failing to build on this branch regardless of whether I use cc=gcc or cc=g++.  Right now, I have cc=gcc (but g++ for ld and link).
17:04 kid51 But master is building and testing satisfactorily on this machine right now, compiled with gcc
17:05 cotto left #parrot
17:06 nopaste "plobsing" at 192.168.1.3 pasted "[PATCH] OSX PPC dlsym patch" (31 lines) at http://nopaste.snit.ch/42765
17:07 plobsing kid51: try this ^^^^
17:09 plobsing whiteknight: point (4) will most likely be handled by jnthn/rakudodevs, leaving the first 3 to parrot
17:11 plobsing but I'm not sure how immediate that need is going to be. Before they need this, they need to be able to store arbitrary constants to bytecode. PIR is not going to cut it there, so they'll need HLL generation of PBC, most likely POST->PBC. POST->PBC and NQP generation of arbitrary constants in bytecode are not even close, SFAIK. So the delimited serialization is not a pressing concern.
17:13 benabik plobsing: Hopefully by the end of summer generation of PBC will be much better.
17:15 plobsing the end of the summer is a long ways away. I'll work on things closer to when they stand a chance of being used as opposed to bitrotting.
17:23 plobsing oops, that patch does nothing. sorry
17:24 plobsing give me a minute to bootstrap the ops
17:24 whiteknight plobsing: benabik is doing the newPOST conversion for GSoC, so we will be generating bytecode directly from PAST/POST
17:24 whiteknight that's what he means by end of the summer.
17:26 whiteknight we don't need to wait for that, but it is a fixed deadline for the particular deliverable
17:27 whiteknight so it's something we can plan around
17:27 kid51 plobsing: 'make' failed at same point
17:28 plobsing whiteknight: I understand that. My point remains that rakudo/nqp-nom cannot make use of the feature until that (and a few other related things) happen. If that's not happening until July/August, efforts in April/May seem premature.
17:28 whiteknight plobsing: right. So is there anything we can do beforehand? Any other cleanups/refactors in packfile-land that we can do to make life easier in september?
17:29 plobsing not really. we already have intra-PBC backreferences. inter-PBC crossreferences should follow that pattern fairly closely.
17:31 whiteknight I've been doing a little bit of aimless cleanup following the packfile_wrap branch, but nothing substantial
17:32 whiteknight if packfiles are going to wait until the end of the summer, maybe I rearrange my priorities list and start working on 6model now instead
17:33 whiteknight I'm very keen on that
17:33 nopaste "plobsing" at 192.168.1.3 pasted "[PATCH] OSX PPC dlsym patch v2" (107 lines) at http://nopaste.snit.ch/42766
17:33 plobsing kid51: please apply ^^this^^ to the clean HEAD (remove previous patch) and retry
17:35 plobsing whiteknight: that is probably the best course of action
17:35 plobsing afk # run
17:35 whiteknight plobsing: later
17:36 whiteknight I bet we can get 6model in place and working well, at least in parallel with our current MOP, by the end of the summer
17:36 whiteknight that should be a nice benefit for the JS and Python3 projects, if they both want to use it
17:36 whiteknight should be nice for Cardinal to
17:36 whiteknight too
17:43 PerlJam whiteknight: +1 on 6model
17:43 whiteknight PerlJam: you interested in joining the crusade?
17:44 PerlJam interested, yes.  Lacking in time and knowledge and such though.
17:49 whiteknight blah, if time and knowledge were necessities, you'd never see me around here again
17:53 whiteknight actually, before 6model I might want to play around with some of my PCC refactor ideas
17:54 cotto joined #parrot
17:57 cotto looks like lfnw isn't big on cameras
18:03 whiteknight damnit
18:11 whiteknight cotto: I'm signing off. I'll talk to you about it later
18:11 whiteknight left #parrot
18:14 dukeleto ~~
18:15 tcurtis ~~
18:17 dukeleto tcurtis: how is your GSoC stuff going?
18:20 tcurtis dukeleto: I've started reading "Efficient Translators for LR(k) Languages", but haven't done much else yet.
18:20 theory left #parrot
18:23 dukeleto tcurtis: ok, good to know. Just checking on you :)
18:26 nopaste "kid51" at 192.168.1.3 pasted "2nd patch problematic" (342 lines) at http://nopaste.snit.ch/42768
18:27 kid51 plobsing: perhaps missing an include ?
18:27 kid51 I have to go afk soo
18:37 * dukeleto is sitting in a "Life Changing Vim Plugins" talk with cotto++
18:38 davidfetter which vim plugins have changed your life, dukeleto ?
18:39 kid51 The most *useful* talk I ever heard Damian give was "Everyday Vi"
18:39 kid51 left #parrot
18:40 cotto It's living up to its name.
18:40 cotto http://adammonsen.com/wp-cont​ent/uploads/2011/04/notes.txt
18:43 * davidfetter not quite enough of a vim devotee to use the irc plugin
18:44 benabik I wouldn't want to use Vim for anything other than editing.  If I wanted everything and the kitchen sink, I'd use emacs.
18:45 cotto It's very fancy editing.
18:52 cotto dukeleto++'s talk went well.  I'm excited for him to get tuits to work on jitterbug some more.
18:54 bubaflub there is a nice program called vimana - it's basically cpanm for vim plugins
18:54 bubaflub and it's perl based, hosted on github
18:55 cotto the speaker talked about three of those
18:55 cotto time for noms
18:57 mj41 joined #parrot
19:01 cotto left #parrot
19:09 lucian bubaflub: that thing looks awesome
19:09 lucian there was another one, working from the vim command line. sort of crap, though
19:10 lucian i really need to fix my vim install, komodo edit's vi emulation has some sharp corners (although it is awesome)
19:10 tcurtis Typographical errors in the statements of theorems about parsing can be somewhat confusing.
19:18 dodathome joined #parrot
19:25 nopaste "plobsing" at 192.168.1.3 pasted "[PATCH] OSX PPC dlsym patch v3" (17 lines) at http://nopaste.snit.ch/42769
19:26 plobsing msg kid51 please try this patch on a clean HEAD http://nopaste.snit.ch/42769
19:26 aloha OK. I'll deliver the message.
19:28 theory joined #parrot
19:43 pjcj left #parrot
19:49 ambs_ joined #parrot
19:50 ambs left #parrot
19:50 ambs_ is now known as ambs
19:57 bluescreen joined #parrot
20:04 jrt4__ joined #parrot
20:33 dodathome left #parrot
20:34 Andy joined #parrot
20:38 pjcj joined #parrot
20:53 theory left #parrot
20:57 mj41 left #parrot
21:16 fperrad left #parrot
21:18 benabik left #parrot
21:22 ShaneC joined #parrot
21:23 benabik joined #parrot
21:33 theory joined #parrot
21:41 ambs left #parrot
21:49 dukeleto ~~
21:49 dukeleto cotto_work: you lie. You are not at work.
21:50 dalek TT #542 closed by plobsing++: Setting stdin to unbuffered doesn't seem to work.
21:50 dalek TT #542: http://trac.parrot.org/parrot/ticket/542
21:56 dukeleto yay for closing TT's with 3 digit numbers
22:02 dalek parrot: 2cbb156 | plobsing++ | / (2 files):
22:02 dalek parrot: eliminate PASM library that has been superceded by PIR equivalent
22:02 dalek parrot: review: https://github.com/parrot/parrot/commit/2cbb156147
22:02 dalek parrot: 23f3d6a | plobsing++ | examples/library/ncurses_life.pir:
22:02 dalek parrot: update references to point to files that *exist*
22:02 dalek parrot: review: https://github.com/parrot/parrot/commit/23f3d6a49a
22:05 lucian_ joined #parrot
22:09 lucian left #parrot
22:20 Andy left #parrot
22:29 lucian joined #parrot
22:33 lucian_ left #parrot
22:48 sjn left #parrot
22:53 soh_cah_toa joined #parrot
22:54 cotto joined #parrot
22:55 cotto ~~
23:06 lucian_ joined #parrot
23:11 lucian left #parrot
23:13 whiteknight joined #parrot
23:18 whiteknight good evening, #parrot
23:20 lucian_ whiteknight: i commented on one of your blog posts
23:20 whiteknight lucian_: yes, I just replied
23:20 whiteknight thanks!
23:24 lucian_ whiteknight: what i didn't say is that i have high hopes for async IO for cooperative systems
23:24 lucian_ is now known as lucian
23:24 whiteknight yes, async IO is a big ticket item that I think falls out of the proposed architecture quite nicely
23:25 lucian eventlet and gevent are interesting in python-land
23:25 whiteknight because if all Tasks are basically just Continuations, they become extremely cheap to churn through
23:25 mtk left #parrot
23:25 lucian with explicit continuations (greenlets/stackless) you can re-compose the control flow around the async IO
23:25 whiteknight so async IO means basically "fire off an IO request, take a continuation, abandon the current task"
23:25 * lucian nods
23:26 lucian for most applications, you might not even need explicit posix thread support
23:26 whiteknight all synchronous operations can be defined in terms of async operations and continuations
23:26 whiteknight we can just keep stringing them together
23:26 lucian of course, you'll hit OS limitations pretty soon
23:26 whiteknight that's what I'm saying. For the first round of implementation, we can get tasks pretty easily and that will be enough for a whole class of programs
23:26 lucian the only solution for general async IO that really works is what gio does, thread pool
23:27 whiteknight then when we open up to threads, we take all those same tasks and simply say "spread out on multiple threads", and a lot of programs will get that essentially for free
23:27 whiteknight callbacks, including library callbacks become trivial
23:27 whiteknight callback function creates a task continuation and inserts it into the stream
23:27 lucian yes, and greenlet can be implemented trivially for pynie :)
23:28 whiteknight and it can happen on the thread where the call was originated, or on a different thread
23:28 lucian yes, it would be interesting
23:28 lucian especially since you can safely deschedule at IO boundaries
23:28 lucian the next scheduling might be on a different thread
23:28 lucian that brings problems too though, especially on NUMA
23:29 whiteknight that's why I stress that data updates are not immediately visible
23:30 lucian i meant about cache locality
23:30 whiteknight how so?
23:30 lucian on NUMA, cpus get their own big cache and memory
23:31 lucian if a task gets scheduled on a different CPU, it'll get huge costs by losing the cache on the previous cpu and accessing memory slowly
23:31 lucian meh, that bridge is likely to be crossed later
23:31 lucian but there are indeed many things that can happen with schedulers interacting (OS and parrot schedulers)
23:31 mtk joined #parrot
23:32 whiteknight well that's true with all sharing systems
23:32 whiteknight we get around that by having several tasks operating on a single core, which makes data sharing between them cheap, and passing fewer messages betwen threads
23:32 whiteknight if you want the most out of any particular architecture, you have to tailor your software to it
23:33 whiteknight A big boon is keeping bytecode immutable so we don't need to worry about that
23:33 lucian yes, i vow to never pull&checkout parrot again if it embraces mutable bytecode :)
23:34 lucian if i had my way, all of parrot's data structures would be persistent (in the immutable sense)
23:35 whiteknight PyPy 1.5 is looking pretty impressive
23:36 whiteknight lucian:  there's no way we can go all-immutable data with some of the languages we want to support
23:36 whiteknight immutable strings is enough of a stretch for some applications that expect them to be easily mutable
23:36 lucian persistent data structures can very easily appear mutable
23:38 lucian they just use structural sharing instead of cloning
23:38 lucian the biggest benefit is again with concurrency
23:38 lucian clojure is a great success story
23:39 lucian the one big problem is GC
23:40 lucian if you introduce OS-scheduled threads, GC gets complicated
23:40 whiteknight with GC, we have two options: Either we move to a concurrent algorithm, or we give each thread its own GC and disable direct sharing entirely
23:41 whiteknight if all data sharing happens through local read-only proxies and message passing, we can give each thread its own mini-GC core
23:41 lucian you can't do a stop-the-world realistically, so each thread would have to have its own gc
23:41 whiteknight in the degenerate case with only one thread, we can go GMS like normal. If we can spread out to multiple threads, we can devote one to a concurrent GC
23:42 lucian but even then and even with just reads, it's quite complicated
23:42 whiteknight I have found a handful of concurrent GC algorithms that are very attractive
23:42 whiteknight I don't think it will be so complicated
23:43 whiteknight I suspect that a good tricolor algorithm could be used with multiple threads.
23:43 lucian perhaps i'm being pessimistic, but i'm not sure
23:43 lucian but yeah, explicit sharing is a must i think
23:43 whiteknight instead of stopping the world, we stop each thread in turn with tricolor state
23:43 lucian w/e else happens
23:43 lucian and other threads block if they try to access this thread through the explicit sharing channels?
23:44 whiteknight if the only sharing channels are messages, the blocked thread won't check messages during GC. They just sit in the mailbox
23:44 whiteknight if the message is synchronous, the sender thread blocks. Otherwise, it doesn't
23:45 whiteknight actually, only the sender Task blocks. Other tasks on that thread can still run
23:45 lucian true
23:45 lucian if you guarantee soft real-time for the gc, you shouldn't get deadlocks because of this
23:47 lucian i do think canonical did make a serious mistake with unity, though
23:48 lucian they used Qt for the 2d version, totally ignoring kde's plasma
23:48 lucian seems a waste
23:48 lucian wrong channel
23:49 whiteknight heh
23:49 lucian anyway, this was a bit of a long break
23:49 lucian i might just go straight to bed
23:49 whiteknight if we have a concurrent collector, there are no explicit pauses. If we go the tricolor route, we can keep pauses low with generations and dynamic triggering
23:52 lucian i've looked at concurrent collectors, they seem like dark magic
23:52 whiteknight no, that's only because they are deceptively simple
23:53 whiteknight it's a tradeoff. algorithmic simplicity at the cost of a dedicated thread
23:53 whiteknight also, most algorithms end up having "checkpoints" where other threads need to pause shortly
23:54 whiteknight so they aren't perfect, but they do tend to be simple
23:54 lucian hmm
23:54 lucian one paper i looked at did concurrent gc in the same thread
23:57 whiteknight I don't think I've seen a paper like that
23:57 whiteknight I have too many papers, I need to go dig back through them
23:58 whiteknight lucian: I'm thinking about pushing forward my plans for 6model. I bet I can get it integrated into Parrot, at least in parallel to the current MOP, by midsummer
23:58 whiteknight if that happened, would it influence your decision about whether or not to use it for Pynie?

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

Parrot | source cross referenced