Parrot 4.1.0 "Black-headed Parrot" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 28 February 2012.
00:15 sri joined 00:17 jsut_ joined 00:34 wagle joined 00:36 losinggeneration joined 00:50 losinggeneration joined 01:07 PacoAir_ joined
whiteknight is working on packfile code today 01:21
too bad I don't have anything to push yet
01:53 losinggeneration joined
dalek rrot/remove_sub_flags: 4a1968f | Whiteknight++ | / (10 files):
Drop the bomb on do_sub_pragmas, PackFile_fixup_subs and related machinery. IMCC now handles :immediate and :postcomp. :load and :init are NOT automagically triggered on packfile load. Parrot exe builds but predictably doesn't run right
02:32
whiteknight BAM
so much work left to do for this transition. It's almost depressing 02:40
dalek rrot/remove_sub_flags: 019116f | Whiteknight++ | / (8 files):
Remove :init and :load flags from the IMCC grammar, with associated bookkeeping
02:47
rrot/kill_props_vtables: e40e72a | bacek++ | t/pmc/namespace.t:
Update test to latest list of vtables.
rrot/kill_props_vtables: 6f6d7d0 | bacek++ | t/src/extend_vtable.t:
Update test to remove prop VTABLEs testing.
02:52
02:54 losinggeneration joined 02:57 travis-ci joined
travis-ci [travis-ci] parrot/parrot#95 (remove_sub_flags - 019116f : Whiteknight): The build is still failing. 02:57
[travis-ci] Change view : github.com/parrot/parrot/compare/4......019116f
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/790047
02:57 travis-ci left
whiteknight dukeleto: ping 02:58
dalek rrot/remove_sub_flags: daad65b | Whiteknight++ | / (139 files):
[ci skip] replace :init and :load with :tag('init') and :tag('load') respectively
03:12
rrot/remove_sub_flags: c7934d0 | Whiteknight++ | .travis.yml:
[ci skip] Don't run travis builds on this branch yet, it's not in a buildable state
03:20 travis-ci joined
travis-ci [travis-ci] parrot/parrot#97 (kill_props_vtables - 6f6d7d0 : Vasily Chekalkin): The build passed. 03:20
[travis-ci] Change view : github.com/parrot/parrot/compare/e......6f6d7d0
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/790083
03:20 travis-ci left 03:43 jsut joined
dalek rrot/remove_sub_flags: d54121c | cotto++ | / (12 files):
[ci skip] fix results of an overeager search and replace
06:00
bacek cotto, ping 06:58
cotto bacek, pong 06:59
bacek cotto, I want to merge my branch soon. E.g. now 07:00
any objections? :)
cotto no hll prolems?
yes, if so. It's a good branch.
bacek ok 07:01
There is additional branch in nqp. I'll merge it as well.
cotto and no test failures?
bacek One-line patch for rakudo required.
Nope, all tests are fine
dalek rrot: c662128 | dukeleto++ | .travis.yml:
[ci] Tell Travis to use a perl worker and test under perl 5.10 and 5.14
07:02
bacek (parrot, nqp, and rakudo)
cotto good times
bacek seen moritz 07:03
aloha moritz was last seen in #perl6 4 hours 54 mins ago saying "r: constant fib = 0, 1, *+* ... *; say fib[100]".
bacek aloha, clock?
aloha bacek: LAX: Sat, 23:03 PST / CHI: Sun, 01:03 CST / NYC: Sun, 02:03 EST / UTC: Sun, 07:03 UTC / LON: Sun, 07:03 GMT / BER: Sun, 08:03 CET / TOK: Sun, 16:03 JST / SYD: Sun, 18:03 EST
cotto tests look good for me too
apart from some unexpected passes on select.t
*one unexpected pass
bacek cotto, yes. It was passing for me for quite few times already. 07:04
But not on all my boxes.
benabik select.t is problematic
bacek seen jnthn
aloha jnthn was last seen in #perl6 7 hours 12 mins ago saying "Time for sleep...'night".
bacek ookey. 07:05
cotto I'm happy. merge whenever you're ready. 07:06
07:06 travis-ci joined
travis-ci [travis-ci] parrot/parrot#98 (master - c662128 : Jonathan "Duke" Leto): The build was broken. 07:06
[travis-ci] Change view : github.com/parrot/parrot/compare/0......c662128
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/790769
07:06 travis-ci left, fperrad joined
dalek rrot: 47bfa1f | bacek++ | / (20 files):
Merge branch 'kill_props_vtables'
07:09
p/kill_props_vtables: cc387d7 | bacek++ | tools/build/PARROT_REVISION:
Bump parrot revision to kill_props_vtables marge commit.
07:13
07:14 travis-ci joined
travis-ci [travis-ci] parrot/parrot#99 (master - 47bfa1f : Vasily Chekalkin): The build is still failing. 07:14
[travis-ci] Change view : github.com/parrot/parrot/compare/c......47bfa1f
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/790801
07:14 travis-ci left 07:15 dukeleto joined
cotto It's nice to finally use all_hll_test to test a merge 07:15
hio dukeleto
though all languages won't pass before the nqp and rakudo patches get merged 07:16
dalek rrot: 5555d82 | dukeleto++ | .travis.yml:
[ci] Perl versions must be quoted because they are strings
dukeleto cotto: coolio
bacek: i accidentally messed up our travis.yml, which is why your branch merge tests failed. just ignore that 07:17
bacek dukeleto, I do. Travis is too noisy and unreliable.
07:21 travis-ci joined
travis-ci [travis-ci] parrot/parrot#100 (master - 5555d82 : Jonathan "Duke" Leto): The build is still failing. 07:21
[travis-ci] Change view : github.com/parrot/parrot/compare/4......5555d82
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/790821
07:21 travis-ci left
dukeleto blarg. 07:22
No good deed goes unpunished.
dalek rrot: 86ddac4 | dukeleto++ | .travis.yml:
[ci] Specify a dummy install command so cpanminus is not invoked, since it doesn't know what to do with Parrot
07:27
07:45 travis-ci joined
travis-ci [travis-ci] parrot/parrot#101 (master - 86ddac4 : Jonathan "Duke" Leto): The build is still failing. 07:45
[travis-ci] Change view : github.com/parrot/parrot/compare/5......86ddac4
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/790845
07:45 travis-ci left
dalek rrot: d82182c | dukeleto++ | .travis.yml:
[ci] Submitting smoke tests requires LWP::UserAgent as a dependency
07:52
dukeleto bacek: if you have useful criticisms, I am all ears. But I am allergic to negativity. If you want me to turn of travis notifications, put it to a vote on parrot-dev
s/turn of/turn off/ 07:53
bacek dukeleto, yes, I do. Check latest builds. About 80% of failures was travis failures, not parrot's. 08:00
and less-than-awesome handling of branches is really really disturbing... 08:01
dukeleto bacek: what?
bacek "I do want it switched off" 08:02
dukeleto bacek: that is because I am hacking on our travis config and I am testing it live instead of trying to install a local travis instance and test that way
bacek: put it to a vote
bacek: and describe exactly what you want turned off: mail notification, irc notification, etc 08:03
bacek dukeleto, mail notifications. IRC, CI, etc are fine
dukeleto bacek: and i have no clue what you mean by "LTA handling of branches"
bacek: i can make it only run on master, but that seems suboptimal. We can put that to a vote too, though. 08:04
bacek dukeleto, there is no distinguish between failed build in branch and failed build in master.
sorear fwiw I unsubscribed from parrot-dev when travis started posting
cotto I'd like to see it do master by default and opt-in for branches
dukeleto cotto: how does opt-in work? 08:05
cotto dukeleto, opposite of [ci skip]
dukeleto sorear: well that is pretty curmudgeonly, since parrot-dev has been pretty quiet lately
but alas, to each their own
sorear when it was quiet I could handle it 08:06
dukeleto "I like the sound of a dead baby, it is so quiet"
Over the line, smokey.
dukeleto goes back into his cave
bacek dukeleto, there is too much of ad crap in travis' mail. A LOT of it. 08:09
dalek rrot: c7f99d7 | dukeleto++ | .travis.yml:
[ci] Only run Travis on the master branch and only on 5.14 for now
08:10
cotto the plaintext version isn't bad
the html version is a little noisy
08:10 travis-ci joined
travis-ci [travis-ci] parrot/parrot#102 (master - d82182c : Jonathan "Duke" Leto): The build is still failing. 08:10
[travis-ci] Change view : github.com/parrot/parrot/compare/8......d82182c
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/790905
08:10 travis-ci left
dalek kudo/nom: 943e4c5 | moritz++ | src/core/Cool.pm:
correct the sub form of comb
08:19
p: 572970e | bacek++ | src/ (2 files):
Update to latest parrot with replaceing prop VTABLEs with standalone functions
08:20
p: cc387d7 | bacek++ | tools/build/PARROT_REVISION:
Bump parrot revision to kill_props_vtables marge commit.
kudo/nom: 3ce70e6 | moritz++ | / (2 files):
bump NQP revision, and get rid of VTABLE_getprop
08:24
08:25 travis-ci joined
travis-ci [travis-ci] parrot/parrot#103 (master - c7f99d7 : Jonathan "Duke" Leto): The build is still failing. 08:25
[travis-ci] Change view : github.com/parrot/parrot/compare/d......c7f99d7
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/790940
08:25 travis-ci left
dalek kudo/nom: 42695ea | moritz++ | docs/ChangeLog:
add :ex and :nth adverbs to ChangeLog
09:01
09:34 d0as8 joined, d0as8 left 10:33 mj41 joined 10:57 ascent joined 11:39 whiteknight joined
nine good morning, whiteknight 11:41
whiteknight hello nine.
nine whiteknight: I'm currently reading up on how a method invokation in Parrot actually works. I think/hope this is the only place left where thread memory separation does not yet work as it should, tripping up GC. 11:43
whiteknight That wouldn't surprise me
nine This stuff is....complicated 11:45
whiteknight yeah, unnecessarily so in some places 12:04
If you have any questions about it I can probably help 12:05
nine I do have questions for sure...but have to clear the table right now, lunch is calling 12:08
whiteknight ok 12:25
12:29 jsut_ joined
nine whiteknight: my current approach is to copy interp->vtables and replace all PMCs in those vtables by proxies. This way find_method returns a proxy to the method in question. invoke therefore runs proxied. But then the method gets executed with the interp of the main thread not the current one. If I change that to run invoke with the thread's interp, it trips up stuff like inspect_str used to get at the class 13:38
whiteknight: I wonder if it might be better to just copy all the class stuff as well...but copying is what we want to get away from. 13:39
whiteknight: maybe you have some idea for a completely different approach? Fixing problems just to turn up new ones usually means I'm overlooking something fundamentally different. 13:40
13:43 benabik joined 13:49 benabik joined
whiteknight nine: that's a great question. bytecode is read-only and methods on a class shouldn't change much. I don't think we need to proxy methods 13:51
benabik Good morning, #parrot
whiteknight hello benabik
nine: The underlying problem, I think, is that Sub PMC contains way too much state. Eventually we need to cut that down so Sub PMC is essentially a read-only interface around read-only bytecode 13:52
13:52 PacoAir joined
whiteknight then it won't matter where it's invoked from 13:52
benabik Oh, that reminds me. I met someone at the University of Rochester who tried to do threading in Parrot for a while. He seemed glad someone was getting farther with it than he did. 13:54
whiteknight Fixing Sub is going to have to be my next big project, after these :load/:init shenanigans 13:55
blah, PGE is a gigantic hassle of weird dependency chains 14:27
and double-blah, it looks like parrot is executing :tag('load') subs out of order now 14:44
that's even worse
benabik :load subs are supposed to be done in-order? 14:45
whiteknight yeah 15:24
during packfile serialization we sort the list of tags so that finding a range of them by name can be done with a simple binary search 15:25
so I suspect that mechanism is mixing them up
So I'm going to have to re-sort them according to idx in the constants table 15:26
It actually won't be so bad. I'll create an RIA of constant indices, sort that, and then use it as a lookup into the constants table 15:28
15:49 Psyche^ joined
nine whiteknight: read only subs sound great. But still they'd have to be proxied because the GC must not find any PMCs belonging to a different interp. 15:52
whiteknight nine: Okay, that's fine too. If Subs are much smaller and much thinner, copying them won't be an issue
benabik If they're read only, can we assign them to "no GC" or something?
whiteknight right now Sub.clone is the best we have and it isn't free
benabik: in the future when they are read-only, yes. Right now Sub has way too much state 15:53
benabik Or, "no/all interp" rather
copying thin ones might be better anyway
Was just a random idea.
nine To be precise: currently I run mark_code_segment(interp) only on the main thread. But I know much too little about code segments to say if that suffices to share code between all threads. My guts say no. 15:54
whiteknight: any idea how I may hack it into some runnable state so I can conduct benchmarks for the final chapter of my paper? 15:55
whiteknight nine: I'm trying to make sure I understand the problem completely. So you are running into conflicts and GC shenanigans when invoking methods on a different thread? 15:56
nine whiteknight: worse: the problems arise when I try to run methods on the current thread. Just because the meta data (class objects, namespaces and such) come from a different thread (the main thread)
whiteknight does the object exist on the current thread or on the main thread? 15:57
nine the current one. To be precise, when executing task = interp.'current_task'() 15:58
It does not get more local than that :) 15:59
whiteknight and what's the error you're getting? 16:01
nine It very much depends on which version of the code. Have tried different things. The original problem is that the GC finds these method objects in the method cache and marks them though they belong to a different interp. I tried to create proxies but then the methods themselves still get called with the other interp. I added an exception to Proxy so invoke would still use the thread's interp, but this leads to paste.scsys.co.uk/185049 16:06
I added an origin_interp field to the PMC base struct and an assertion to Parrot_gc_mark_PMC_alive checking if the PMC marked belongs to the current interp. 16:07
That's what I meant by fixing one problem turns up another one :) 16:09
dalek rrot/remove_sub_flags: 811fd6e | Whiteknight++ | / (17 files):
[ci skip] Update several uses of the load_bytecode op to use the new loading sequence
16:18
whiteknight nine: is there any way to tell GC not to mark method caches if you're not on the main thread? 16:20
or add an ->owner_interp param to Sub, and in Sub.mark don't do anything unless INTERP == self->owner_interp 16:21
brb, roof 16:28
benabik roof? 16:53
nine roof? 17:32
whiteknight: method caches are certainly possible. But still GC could very well kick in during method execution so it would for sure find Subs elsewhere. owner_interp is a nice hack for me to debug threading, but I'm sure we don't want to keep it. It's enlarging every single PMC. We may keep it on Subs though till a better solution is possible 17:36
whiteknight: even if I do not mark the Subs, I'd still have to keep the GC of the main thread from collecting them... Many places in which things can go wrong. 17:42
whiteknight yeah, GC has always been a hassle 17:57
benabik: roof is that thing that keeps the rain out
benabik whiteknight: Is it not doing it's job?
whiteknight it is, mostly. I need to take down the rest of the xmas lights and check a few places to make sure it's not leaking 17:58
17:58 brambles joined
whiteknight most of the christmas lights helpfully took themselves down, with a combination of wind and gravity 17:58
benabik The wind's been killer here this weekend.
Was driving the snow so hard I thought it was hail.
whiteknight our roof is a year or two away from end-of-life, so I am trying to keep a close eye on it 18:01
benabik Probably a good idea. 18:02
whiteknight Since we've only been in the house for a few months, every weather-related event is the first time, and we need to see how the house handles it 18:04
first snow, first ice storm, first freezing rain, first driving rain, first wind over 20mph, etc
benabik Our house had had most of that work done recently before we moved in so I didn't have to worry too much. 18:07
whiteknight This house had a lot of things replaced recently (windows, A/C, plumbing, kitchen, etc) but the roof was not one of them 18:08
18:09 jsut joined
aloha (parrot/parrot) Issues opened : 723 (ops2c doesn't handle ':deprecated' op pragma.) by bacek : github.com/parrot/parrot/issues/723 20:41
dalek rrot: 4a482c7 | bacek++ | src/ops/pmc.ops:
Add new getprop variant and deprecate old one. Part of #351
20:44
rrot: a8dd597 | bacek++ | / (4 files):
Rebootstrap ops
20:59 travis-ci joined
travis-ci [travis-ci] parrot/parrot#104 (master - a8dd597 : Vasily Chekalkin): The build is still failing. 20:59
[travis-ci] Change view : github.com/parrot/parrot/compare/c......a8dd597
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/794192
20:59 travis-ci left 21:04 jsut_ joined
whiteknight bacek++ 21:14
dalek rrot/remove_sub_flags: c3cb390 | Whiteknight++ | / (7 files):
[ci skip] several library load_bytecode fixes, including some to generated code in ext/ to get the build further along. Runs coretest with results not as bad as might be expected
21:33
rrot: 675a804 | petdance++ | config/auto/byteorder.pm:
remove capture from match
22:03
tadzik make: *** [pbc_to_exe] Segmentation fault 22:10
cool :)
it went away after 'make clean' luckily 22:13
22:18 travis-ci joined
travis-ci [travis-ci] parrot/parrot#105 (master - 675a804 : Andy Lester): The build is still failing. 22:18
[travis-ci] Change view : github.com/parrot/parrot/compare/a......675a804
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/794556
22:18 travis-ci left
whiteknight tadzik: what brachw as that? 22:36
bacek_at_work ~~ 22:56
aloha (parrot/parrot) Issues closed : 722 (Properties related VTABLEs are deprecated) by bacek : github.com/parrot/parrot/issues/722 23:02