Parrot 3.3.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today” | Accepted GSoC Students announced! | GSoC student information emails coming out soon
Set by moderator on 26 April 2011.
00:29 GodFather left
plobsing ping cotto, bacek 00:45
cotto plobsing, pong 00:47
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.
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.
thanks
plobsing++ 00:50
dalek TT #1654 closed by plobsing++: ops2c should complain about ops numbering in ranges 00:52
TT #1654: trac.parrot.org/parrot/ticket/1654
00:56 kid51 joined
tcurtis Is plumage broken again? 00:58
whiteknight is it? 01:02
git you update?
did you update? 01:03
nopaste "tcurtis" at 192.168.1.3 pasted "parrot-nqp Configure.nqp # parrot 3.3" (8 lines) at nopaste.snit.ch/42666 01:05
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
and you're getting the new plumage from github? 01:07
tcurtis Github?
cotto yup
tcurtis Nevermind. That's likely my problem. 01:08
cotto We need to take the gitorious version down.
That caught me earlier too.
tcurtis Plumage from github appears to work. 01:12
cotto good news there
whiteknight yay
01:24 mtk left 01:31 mtk joined 01:40 whiteknight left
dalek rrot: a67bfbf | plobsing++ | / (12 files):
remove remaining ops.num support infrastructure
 01:45
cotto conf time 01:49
01:55 cotto left, nopaste left 02:02 nopaste joined 02:10 kid51 left
dukeleto ~~ 02:19
02:42 soh_cah_toa joined, woosley joined
soh_cah_toa anyone familiar w/ rosella? i was wondering if you can use it w/ nqp. it looks like you can 02:43
dukeleto soh_cah_toa: yes, i think it is written in NQP 02:46
soh_cah_toa okay 02:47
dukeleto soh_cah_toa: it is very much designed to be used with NQP
soh_cah_toa hmmm...i am having THE hardest time deciding which language to use for my gsoc project
for a while, i was leaning towards nqp but now winxed is looking a little better 02:48
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
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:49
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
bubaflub soh_cah_toa: you could include the PBCs 02:56
soh_cah_toa: then you wouldn't require winxed to run, just to build the debugger
soh_cah_toa hmmm...that's an idea
but how could someone run the tests then? 02:57
well, the average user probably won't be needing that anyway. only developers who probably have winxed installed 02:58
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
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
dukeleto soh_cah_toa: you don't pay the cost of parsing it every time you run it if you store PBC
soh_cah_toa: something to keep in mind
03:01 woosley left
soh_cah_toa that's true 03:01
03:07 dafrito joined
atrodo coke++ 03:08
03:12 hudnix left 03:24 soh_cah_toa left 03:42 particle1 joined, AzureStone left, plobsing left 03:43 plobsing joined 03:44 particle left 03:47 AzureStone joined 03:50 AzureSto_ joined 03:54 AzureStone left 03:55 bubaflub left 03:56 TonyC left, nopaste left, TonyC joined 04:02 nopaste joined 04:06 nopaste left 04:12 nopaste joined 05:05 theory left 05:09 rohit_nsit08 joined 05:55 plobsing left, rohit_nsit08 left 05:56 cotto joined
cotto ~~ 05:56
06:05 ShaneC joined
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, benabik left, benabik_ is now known as benabik
dukeleto benabik: howdy 06:55
benabik dukeleto: Very sleepy but here. What's up? 06:56
dukeleto benabik: sleepy as well. Last minute hacking on my presentation for the morning 06:58
benabik likes Colloquy's push notifications. Very handy.
cotto 'night 07:02
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:03
dukeleto benabik: yep. saw you jump back in the channel :) 07:10
07:11 fperrad joined
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:12
07:18 dafrito left 07:34 dafrito joined 08:47 ShaneC left 08:52 benabik_ joined, benabik left, benabik_ is now known as benabik 09:39 jrt4__ left
dalek rrot: 75c90bf | allison++ | ports/debian/ (13 files):
Updating Debian packaging files for Parrot 3.3.0 release.
 09:50
rrot: 1bafbdb | allison++ | / (12 files):
Merge branch 'master' of github.com:parrot/parrot
10:12 mj41 joined 10:23 luben joined 10:27 whiteknight joined
whiteknight good morning, #parrot 10:37
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.
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
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
shit...
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.
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
on 10 younger generation collection. (continued)
aloha OK. I'll deliver the message.
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
hat you have ovserved
aloha OK. I'll deliver the message.
10:56 estrabd left 10:57 estrabd joined
whiteknight luben: At that point, an email might have been easier :) 11:02
luben: although the results look very interesting
luben: so GMS doesn't have adaptive triggering? How hard would that be to implement? 11:03
bacek ~~ 11:23
whiteknight, trac.parrot.org/parrot/ticket/2023
11:23 mj41 left
whiteknight bacek: ah, okay 11:23
dalek rrot/jit_prototype: 9d5bd6c | bacek++ | / (2 files):
Add fetching of ElementType from pointer type
 11:53
11:53 kid51 joined
rrot/jit_prototype: 0fea15f | bacek++ | / (3 files):
Implement fetching of TypeKind
11:57 Patterner left, Psyche^ joined, Psyche^ is now known as Patterner
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 12:12 jsut_ left 12:14 lucian joined 12:29 hudnix joined
nopaste "kid51" at 192.168.1.3 pasted "debug parrot_nci_thunk_gen on darwin/ppc" (13 lines) at nopaste.snit.ch/42718 12:33
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 12:49 sjn joined
nopaste "kid51" at 192.168.1.3 pasted "more debugging output" (31 lines) at nopaste.snit.ch/42719 12:53
"kid51" at 192.168.1.3 pasted "still more debugging output" (85 lines) at nopaste.snit.ch/42720 12:57
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:02
moritz rakudo has some test failures on newest parrot HEAD 13:11
./perl6 t/spec/S03-metaops/hyper.rakudo 13:12
... 13:13
ok 141 - hash - correct result from >>!
Too many positional parameters passed; got 3 but expected 2 in 'hyper' at line 269:CORE.setting in main program body at line 1
now rakudo changes involved
whiteknight that's an extremely strange failure 13:31
can you get a backtrace?
moritz a PIR level backtrace, if that helps you... 13:35
nopaste "moritz" at 192.168.1.3 pasted "PIR backtrace from hyper.t" (12 lines) at nopaste.snit.ch/42722 13:36
moritz I can try to bisect
whiteknight that's a very weird failure. I don't think anything has changed in parrot with regards to compiling or argument parsing 13:40
13:53 JimmyZ joined 14:03 JimmyZ_ joined 14:07 autark left, JimmyZ left 14:08 JimmyZ_ is now known as JimmyZ
dalek rrot: 16933ea | fperrad++ | src/pmc/boolean.pmc:
[PMC] add is_equal for Boolean PMC

needed by LOLCODE		 14:09
tadzik LOL 14:11
whiteknight I wonder how hard it would be to write a bootstrapping LOLCODE compiler 14:17
dalek sella/path_refactor: f7fa5f8 | Whiteknight++ | src/core/Rosella.winxed:
Add in a prototype build_r function to build, calling BUILD in parent classes as well
 14:18
sella/path_refactor: 7a057b6 | Whiteknight++ | s (6 files):
start fleshing out what the new system is goin to look like for Path. Breaking the search algorithm up into searcher classes
14:24 JimmyZ left 14:37 bubaflub joined
bubaflub ~ 14:37
cotto ~~
dukeleto bubaflub: mornin' 14:44
bubaflub mornin' dukeleto 14:50
14:51 ambs joined 14:54 lucian_ joined 14:55 fperrad_ joined
dukeleto is getting ready for LinuxFestNW with cotto++ 14:56
bubaflub: i am giving a talk in 2 hours
bubaflub dukeleto: nice. is it the one on Jitterbug? 14:57
14:58 fperrad left, fperrad_ is now known as fperrad, lucian__ joined, kid51 left 14:59 lucian left
dalek sella: f7fa5f8 | Whiteknight++ | src/core/Rosella.winxed:
Add in a prototype build_r function to build, calling BUILD in parent classes as well
 15:02
sella: 25c805a | Whiteknight++ | s (5 files):
first draft of a new Lazy library. Allows creating lazy proxies, which only instantiate their target objects on demand
sella: 5c3a13a | Whiteknight++ | src/lazy/ (2 files):
fix lazy library so it builds and passes a few ad hoc tests
sella/gh-pages: 56a73af | Whiteknight++ | libraries/future.md:
add short blurb about lazy library
15:02 lucian_ left 15:04 utsl left 15:05 utsl joined
cotto bubaflub, yup 15:05
and he just added a slide
bubaflub cotto: cool
cotto though I'm still editing and polishing, so I'm hardly one to talk
15:06 autark joined
whiteknight cotto: you giving a talk? 15:07
cotto whiteknight, yup 15:08
at 1:30 15:09
whiteknight cotto: what about? Parrot
?
cotto of course
www.linuxfestnorthwest.org/sessions...t-state-vm
whiteknight is it going to be videotaped?
I would love to see that
cotto no idea 15:10
I'll try to find out though
whiteknight okay, awesome
15:19 utsl left, utsl joined 15:24 lucian__ left 15:30 jsut_ joined 15:31 lucian joined 15:32 JimmyZ joined 15:35 jsut left 15:37 mtk left, cotto left
benabik ~~ 15:41
15:41 lucian left 15:42 lucian joined 15:44 mtk joined
luben whiteknight, kid51, I have send extended post with my GC observations to parrot-dev 15:45
whiteknight luben++
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:47
15:54 jsut joined 15:59 jsut_ left 16:07 Coke left, Coke joined 16:12 Coke__ joined 16:13 Coke left 16:15 kid51 joined
kid51 luben, thanks for that post 16:15
16:16 JimmyZ left 16:23 theory joined
whiteknight yes, luben++ 16:23
luben: tunings and exposing some parameters would be awesome
or, just exposing parameters and teaching people how to tune would be fine too 16:24
luben I will work in that direction
some of parameters are hard to expose, e.g. number of generations
whiteknight yes, I imagine that is tricky 16:25
don't kill yourself over it.
16:30 plobsing joined
plobsing ~~ 16:34
whiteknight hello plobsing 16:35
plobsing: I want to set aside some time to chat with you in the coming weeks about packfiles
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:36
my current strategy of praying every day that you don't get hit by a bus is unreliable 16:37
:)
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:38
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:40
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.
whiteknight I don't expect to have the same level of understanding, at east not any time soon 16:43
Im trying to understand better what Rakudo needs, what effort that will take, and what (if anything) I can do to help
plobsing ah, if it is simply delimited serialization you're looking for, that is simpler 16:44
whiteknight that may be it 16:45
see, I don't even know what it is that I don't know about
I'm in a bad place :)
plobsing do you understand what delimited serialization is and how parrot isn't meeting that need? 16:46
whiteknight very very vaguely
plobsing OK, I'll try to give you the coles notes
whiteknight they want to be able to partially serialize without following all pointers, then reassemble when we thaw?
plobsing they want to avoid duplicates in their deserialized object graphs 16:47
whiteknight do they have lots of duplicates now?
plobsing whiteknight: less so now that we de-dup within a single constant table, but issues arise when working with multiple PBCs. 16:48
16:49 cotto joined
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
in fact, the class probably also lives in a separate packfile, so that should also not be stored with the object
cotto ~~ 16:50
plobsing we want to maintain those object graph edges, but also maintain the uniqueness of the nodes.
the proposed solution is to store a reference into a different PBC as a placeholder in such situations 16:52
whiteknight ok
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
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
2) we need the serializer to act on these indications, storing references 16:54
3) we need the deserializer to follow the references appropriately
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.
plobsing 4) we need rakudo/PCT/whatever to generate these hints where it is appropriate
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" 16:56
kid51 (gdb) p err 17:00
$1 = 0x507284 "invalid handle passed to dlsym()"
plobsing well, then I suspect OSX here isn't respecting the SUS spec on dlsym 17:01
which we can work around
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:03
But master is building and testing satisfactorily on this machine right now, compiled with gcc 17:04
17:05 cotto left
nopaste "plobsing" at 192.168.1.3 pasted "[PATCH] OSX PPC dlsym patch" (31 lines) at nopaste.snit.ch/42765 17:06
plobsing kid51: try this ^^^^ 17:07
whiteknight: point (4) will most likely be handled by jnthn/rakudodevs, leaving the first 3 to parrot 17:09
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:11
benabik plobsing: Hopefully by the end of summer generation of PBC will be much better. 17:13
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:15
oops, that patch does nothing. sorry 17:23
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
that's what he means by end of the summer.
we don't need to wait for that, but it is a fixed deadline for the particular deliverable 17:26
so it's something we can plan around 17:27
kid51 plobsing: 'make' failed at same point
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?
plobsing not really. we already have intra-PBC backreferences. inter-PBC crossreferences should follow that pattern fairly closely. 17:29
whiteknight I've been doing a little bit of aimless cleanup following the packfile_wrap branch, but nothing substantial 17:31
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:32
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 nopaste.snit.ch/42766
plobsing kid51: please apply ^^this^^ to the clean HEAD (remove previous patch) and retry
whiteknight: that is probably the best course of action 17:35
afk # run
whiteknight plobsing: later
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
that should be a nice benefit for the JS and Python3 projects, if they both want to use it
should be nice for Cardinal to
too
PerlJam whiteknight: +1 on 6model 17:43
whiteknight PerlJam: you interested in joining the crusade?
PerlJam interested, yes. Lacking in time and knowledge and such though. 17:44
whiteknight blah, if time and knowledge were necessities, you'd never see me around here again 17:49
actually, before 6model I might want to play around with some of my PCC refactor ideas 17:53
17:54 cotto joined
cotto looks like lfnw isn't big on cameras 17:57
whiteknight damnit 18:03
cotto: I'm signing off. I'll talk to you about it later 18:11
18:11 whiteknight left
dukeleto ~~ 18:14
tcurtis ~~ 18:15
dukeleto tcurtis: how is your GSoC stuff going? 18:17
tcurtis dukeleto: I've started reading "Efficient Translators for LR(k) Languages", but haven't done much else yet. 18:20
18:20 theory left
dukeleto tcurtis: ok, good to know. Just checking on you :) 18:23
nopaste "kid51" at 192.168.1.3 pasted "2nd patch problematic" (342 lines) at nopaste.snit.ch/42768 18:26
kid51 plobsing: perhaps missing an include ? 18:27
I have to go afk soo
dukeleto is sitting in a "Life Changing Vim Plugins" talk with cotto++ 18:37
davidfetter which vim plugins have changed your life, dukeleto ? 18:38
kid51 The most *useful* talk I ever heard Damian give was "Everyday Vi" 18:39
18:39 kid51 left
cotto It's living up to its name. 18:40
adammonsen.com/wp-content/uploads/2.../notes.txt
davidfetter not quite enough of a vim devotee to use the irc plugin 18:43
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:44
cotto It's very fancy editing. 18:45
dukeleto++'s talk went well. I'm excited for him to get tuits to work on jitterbug some more. 18:52
bubaflub there is a nice program called vimana - it's basically cpanm for vim plugins 18:54
and it's perl based, hosted on github
cotto the speaker talked about three of those 18:55
time for noms
18:57 mj41 joined 19:01 cotto left
lucian bubaflub: that thing looks awesome 19:09
there was another one, working from the vim command line. sort of crap, though
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
nopaste "plobsing" at 192.168.1.3 pasted "[PATCH] OSX PPC dlsym patch v3" (17 lines) at nopaste.snit.ch/42769 19:25
plobsing msg kid51 please try this patch on a clean HEAD nopaste.snit.ch/42769 19:26
aloha OK. I'll deliver the message.
19:28 theory joined 19:43 pjcj left 19:49 ambs_ joined 19:50 ambs left, ambs_ is now known as ambs 19:57 bluescreen joined 20:04 jrt4__ joined 20:33 dodathome left 20:34 Andy joined 20:38 pjcj joined 20:53 theory left 20:57 mj41 left 21:16 fperrad left 21:18 benabik left 21:22 ShaneC joined 21:23 benabik joined 21:33 theory joined 21:41 ambs left
dukeleto ~~ 21:49
cotto_work: you lie. You are not at work.
dalek TT #542 closed by plobsing++: Setting stdin to unbuffered doesn't seem to work. 21:50
TT #542: trac.parrot.org/parrot/ticket/542
dukeleto yay for closing TT's with 3 digit numbers 21:56
dalek rrot: 2cbb156 | plobsing++ | / (2 files):
eliminate PASM library that has been superceded by PIR equivalent
 22:02
rrot: 23f3d6a | plobsing++ | examples/library/ncurses_life.pir:
update references to point to files that *exist*
22:05 lucian_ joined 22:09 lucian left 22:20 Andy left 22:29 lucian joined 22:33 lucian_ left 22:48 sjn left 22:53 soh_cah_toa joined 22:54 cotto joined
cotto ~~ 22:55
23:06 lucian_ joined 23:11 lucian left 23:13 whiteknight joined
whiteknight good evening, #parrot 23:18
lucian_ whiteknight: i commented on one of your blog posts 23:20
whiteknight lucian_: yes, I just replied
thanks!
lucian_ whiteknight: what i didn't say is that i have high hopes for async IO for cooperative systems 23:24
23:24 lucian_ is now known as lucian
whiteknight yes, async IO is a big ticket item that I think falls out of the proposed architecture quite nicely 23:24
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
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"
lucian nods
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
we can just keep stringing them together
lucian of course, you'll hit OS limitations pretty soon
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
lucian the only solution for general async IO that really works is what gio does, thread pool
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
callbacks, including library callbacks become trivial
callback function creates a task continuation and inserts it into the stream
lucian yes, and greenlet can be implemented trivially for pynie :)
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
especially since you can safely deschedule at IO boundaries
the next scheduling might be on a different thread
that brings problems too though, especially on NUMA
whiteknight that's why I stress that data updates are not immediately visible 23:29
lucian i meant about cache locality 23:30
whiteknight how so?
lucian on NUMA, cpus get their own big cache and memory
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
meh, that bridge is likely to be crossed later
but there are indeed many things that can happen with schedulers interacting (OS and parrot schedulers)
23:31 mtk joined
whiteknight well that's true with all sharing systems 23:32
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
if you want the most out of any particular architecture, you have to tailor your software to it
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 :)
if i had my way, all of parrot's data structures would be persistent (in the immutable sense) 23:34
whiteknight PyPy 1.5 is looking pretty impressive 23:35
lucian: there's no way we can go all-immutable data with some of the languages we want to support 23:36
immutable strings is enough of a stretch for some applications that expect them to be easily mutable
lucian persistent data structures can very easily appear mutable
they just use structural sharing instead of cloning 23:38
the biggest benefit is again with concurrency
clojure is a great success story
the one big problem is GC 23:39
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
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
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
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
I don't think it will be so complicated
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
but yeah, explicit sharing is a must i think
whiteknight instead of stopping the world, we stop each thread in turn with tricolor state
lucian w/e else happens
and other threads block if they try to access this thread through the explicit sharing channels?
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
if the message is synchronous, the sender thread blocks. Otherwise, it doesn't
actually, only the sender Task blocks. Other tasks on that thread can still run 23:45
lucian true
if you guarantee soft real-time for the gc, you shouldn't get deadlocks because of this
i do think canonical did make a serious mistake with unity, though 23:47
they used Qt for the 2d version, totally ignoring kde's plasma 23:48
seems a waste
wrong channel
whiteknight heh 23:49
lucian anyway, this was a bit of a long break
i might just go straight to bed
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
lucian i've looked at concurrent collectors, they seem like dark magic 23:52
whiteknight no, that's only because they are deceptively simple
it's a tradeoff. algorithmic simplicity at the cost of a dedicated thread 23:53
also, most algorithms end up having "checkpoints" where other threads need to pause shortly
so they aren't perfect, but they do tend to be simple 23:54
lucian hmm
one paper i looked at did concurrent gc in the same thread
whiteknight I don't think I've seen a paper like that 23:57
I have too many papers, I need to go dig back through them
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
if that happened, would it influence your decision about whether or not to use it for Pynie?

Powered by Cro and the Raku® Programming Language.

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

Thank you!