Parrot 3.0.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: Fix ipv6-related failures | Test imcc_interfaces and annotations-tree branches
Set by moderator on 8 February 2011.
00:15 plobsing joined
KaeseEs i would consider an inability to implement gobject a feature 00:35
imagine someone writing a gobject port, and Clippy(tm) pops up. "It looks like youre trying to write malware..."
plobsing languages and VMs should not be measured by the bad uses the dissallow, but the good ones they facilitate. people will always find a way to write the bad programs anyways. 00:38
00:39 whiteknight joined
Tene You can't design a system that disallows all bad uses without also disallowing many good uses. 00:40
dukeleto ENOCLIPPY 00:44
KaeseEs i'm confident that an is_gobject() function that returns 0 if the current file is something other than an implementation of gobject, and decapitates the user and does not return if the current translation unit is an implementation of gobject, could be written with an acceptly low number of innocents beheaded from false positives 00:46
i;ll go back to messing around with timers :v i wish RDTSC weren't so problematic on recent hw, it would be nice to avoid the overhead of a syscall 00:50
whiteknight good evening, #parrot 01:01
dukeleto whiteknight: wilkommen! 01:02
whiteknight cotto_work: if our object model is pluggable, we should be able to support other implementations like gobject. Also, if we have native gobject support, we suddenly become a scripting option for gnome 01:03
01:30 davidfetter left
dukeleto This must be how bacek_at_work does things : imgur.com/gallery/sw215 01:35
whiteknight I'm surprised if his method has so many steps 01:37
dukeleto yeah, most of the time it was just 0) Write down solution 01:40
plobsing is there a good way to get code included into a PMC's header file? 01:47
my alternative is shoving it into one of the "everybody includes these at the top" header files
bacek_at_work dukeleto, looks familiar :) 01:48
plobsing, patch Pmc2c to support it...
plobsing bacek_at_work: better than the alternative. good idea.
bacek_at_work plobsing, similar to ops: BEGIN_PMC_PREAMBLE/END_PMC_PREAMBLE. For consistency reasons. 02:00
cotto dukeleto, that's great 02:02
dukeleto bacek_at_work: i syndicate :)
cotto I'm actually a little embarrassed about that syntax. It's a trivial concern, but I feel like I could have come up with something less ugly. 02:03
02:10 preflex left 02:20 preflex joined 02:46 kid51 joined 03:03 whiteknight left
kid51 ~~ 03:06
dalek TT #1988 closed by jkeenan++: lib/Parrot/Pmc2c/PMCEmitter.pm: make file match package. 03:13
TT #1988: trac.parrot.org/parrot/ticket/1988
TT #2000 closed by jkeenan++: lib/Parrot/Pmc2c/MethodEmitter.pm: make file match package
TT #2000: trac.parrot.org/parrot/ticket/2000
03:19 ryan left 03:23 adu left 03:24 adu joined
kid51 FWIW, this was a successful build a couple of hours back on the generational_gc branch with --optimize: smolder.parrot.org/app/projects/rep...tails/8587 03:28
03:28 kid51 left
dukeleto ~~ 03:44
dalek rrot/leto/embed_grant: a9e2c65 | dukeleto++ | t/src/extend_vtable.t:
[t] Parrot_PMC_i_concatenate_str
 04:05
rrot/leto/embed_grant: 0786fef | dukeleto++ | t/src/extend_vtable.t:
[t] Parrot_PMC_i_concatenate_str
 04:10
cotto dukeleto, I'm looking through any potentially useful documents I can find that are relevant to m0's design. Do you have any suggestions? 04:38
I want to boil everything I can find into an initial draft of pdd34, then sync with everyone on the arch team and divide up the parts of the spec that need more thought and/or coverage. 04:39
bacek_at_work ~~
cotto hi bacek_at_work 04:40
aloha, clock?
aloha cotto: LAX: Wed, 20:40 PST / CHI: Wed, 22:40 CST / NYC: Wed, 23:40 EST / UTC: Thu, 04:40 UTC / LON: Thu, 04:40 GMT / BER: Thu, 05:40 CET / TOK: Thu, 13:40 JST / SYD: Thu, 15:40 EST
bacek_at_work Good news about gen_gc: rakudo's spectest fails in exactly same bugs with MS2.
So, I did merge something wrongly.
cotto That sounds like an easier problem to fix than a gc bug.
bacek_at_work cotto, exactly. 04:41
just careful review diff with master
cotto yup. Tedious but doable.
04:42 mtk left
cotto great news 04:42
04:49 mtk joined
bacek_at_work cotto, ping 05:52
cotto bacek_at_work, pong 05:55
bacek_at_work cotto, can you look at op copy in set.ops? I've got very bad feelings about it 05:56
cotto eek
bacek_at_work It's only one suspicious diff between gen_gc and master 05:57
"one and only one" 05:58
cotto looks like I get to dig into VTABLE_getprops 05:59
bacek_at_work it digs into everything 06:00
memcpy of PMC isn't great idea
cotto no
06:01 minusnine joined
cotto I'm not sure why that's necessary. 06:01
bacek_at_work I changed it to just clone in gen_gc. And looks like I changed (broken anyway) semantic somehow. 06:02
cotto It reminds me of smalltalk's become 06:03
bacek_at_work .morph?
cotto that too 06:04
06:04 rurban_ joined
cotto copy seems to do the same thing, but without VTABLE_init 06:05
I see what it's doing but not why.
06:06 minusnine left 06:07 rurban left, rurban_ is now known as rurban
cotto bacek_at_work, why change the op in gen_gc? 06:09
bacek_at_work to preserve gen_gc invariant about flags 06:16
cotto what about saving/restoring the flags 06:17
that'd also be cheaper
bacek_at_work "PMC_data(clone) = NULL;"
it's WRONG 06:18
Many our PMCs with auto_attr set doesn't expect NULL for self.data
cotto By that point the PMC has already been destroyed. 06:19
nm
bacek_at_work Rakudo's make spectest is running smoothly now. With "op copy" from master. 06:22
cotto copy is very hacky and I'd love to see a better alternative, but I don't think I'd call it broken. 06:23
bacek_at_work yeah... 06:25
It's kind of "replace in-place"
cotto yes
bacek_at_work, how does it mess up gen_gc? 06:26
is it the case that it might cause issues or is it something more certain?
bacek_at_work It looks very suspicious. And I changed it. In a wrong way
Reading it further: I don't think it will cause any problems. 06:27
cotto ok
dalek rrot/generational_gc: 66a563d | bacek++ | src/ops/ (2 files):
Bring 'op copy' back from master
bacek_at_work don't believe own eyes. 06:28
make spectest is up to S05-mass
without failures.
THE VICTORY
cotto a-freaking-mazing
bacek++ 06:29
bacek_at_work lua test passed
HOORAY!!!!
cotto sweet
does it need a patch?
bacek_at_work yes 06:30
I nopasted it early this morning.
nopaste.snit.ch/31060 06:31
this one
cotto I'm tempted to look for a way around the deprecation policy so that this can go into master sooner. 06:32
that looks like a rakudo patch
bacek_at_work yes 06:33
cotto ok. I thought you were talking about Lua.
bacek_at_work no
lua is clear
cotto nice
Is it only a complex HLL that'll require a patch, i.e. one that does funky things in VTABLE slots that are normally ro? 06:34
bacek_at_work yes 06:35
cotto there aren't too many of those 06:36
bacek_at_work indeed
06:39 theory left
bacek_at_work cotto, actually I'm going to fix master branch, so patch can be commited it into rakudo straight away. 06:40
than we can discuss deprecation policy :)
cotto sure. There's no way we're switching to gen_gc before Rakudo's ready.
bacek_at_work of course not 06:41
cotto How often is Rakudo bumping PARROT_REVISION these days? 06:43
06:43 minusnine_ joined
bacek_at_work t/spec/S12-methods/calling_sets.t (Wstat: 0 Tests: 31 Failed: 1) 06:44
Failed test: 6
Files=544, Tests=27634, 1361 wallclock secs ( 4.62 usr 0.84 sys + 1287.10 cusr 20.77 csys = 1313.33 CPU)
Result: FAIL
1294.01user 22.20system 22:44.33elapsed 96%CPU (0avgtext+0avgdata 849520maxresident)k
Single test from whole spectest!
cotto nice 06:45
bacek_at_work ah 06:46
not actual failure
roast was updated
but I didn't update rakudo
cotto you mentioned that we need heavier gc tests 06:47
did you have something specific in mind?
06:49 estrabd left, estrabd joined
cotto aloha, clock? 06:58
aloha cotto: LAX: Wed, 22:58 PST / CHI: Thu, 00:58 CST / NYC: Thu, 01:58 EST / UTC: Thu, 06:58 UTC / LON: Thu, 06:58 GMT / BER: Thu, 07:58 CET / TOK: Thu, 15:58 JST / SYD: Thu, 17:58 EST
bacek_at_work cotto, just throw a lot of GC load. Preferably with inter-generational links 07:01
make spectest passed 07:02
cotto bacek++
bacek_at_work nopaste.snit.ch/31154 - rakudo build time 07:03
cotto looking good 07:04
bacek_at_work indeed :) 07:05
seen moritz 07:06
aloha moritz was last seen in #parrot 10 hours 28 mins ago saying "bacek: build succeeds, about a third of the spectests returns errors".
cotto I think you'll have a pretty easy time convincing the Rakudo folks to apply that and bump PARROT_REVISION.
bacek_at_work cotto, not yet
I have to fix master little bit
cotto sure. tuning first
dukeleto gen_gc and rakudo are playing nice?
cotto that's why our hard-working coding robot says 07:07
s/why/what/
dukeleto anybody know what kind of performance change it incurs? 07:08
bacek++ 07:09
dukeleto just saw the nopaste
dalek rrot: 84fb245 | bacek++ | / (3 files):
Add GC API write_barrier function
 07:16
bacek_at_work ok
dalek rrot: 7b43ae3 | bacek++ | src/gc/api.c:
Made write_barrier optional in GC Subsystem.
rrot: 78df613 | bacek++ | t/src/misc.t:
Add test that GC_WRITE_BARRIER macro work on all GCs.
bacek_at_work _now_ we can ask rakudo's folks to commit patch. It should work on current master as well.
07:20 fperrad joined 07:24 mikehh left
bacek_at_work yes. Rakudo with patch builds on current master 07:26
time to go home
see you!
cotto 'night 07:27
07:32 mikehh joined 07:49 bacek joined 07:54 cosimo left
dukeleto exciting times, these be. 07:54
07:55 minusnine_ left
dalek rrot/m0-spec: 7d5c222 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add design goals, more stub topics, document scope
 08:08
rrot/m0-spec: b4ff640 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
make stub sections slightly less stubby
cotto dukeleto, if you have a minute, I'd appreciate you taking a look at pdd32 in that branch and making sure there are stubs for all the important topics.
I'm off to bed to dream about shiny new generational gcs. 08:09
'night
bacek night, cotto 08:10
cotto bacek, could you do that too if you have a few minutes? 08:12
bacek Hopefully it will not be nightmares :)
m0?
cotto yes
dalek rrot/generational_gc: 42654c8 | bacek++ | src/gc/gc_gms.c:
Most important commit to docs: s/(GC algorithm) WILL BE/$1 is/
 08:16
bacek I'll do it later
Have few ideas about fixing gen_gc for more than 2 generations.
cotto sure. no rush 08:17
'night (for real)
dukeleto cotto: will do 08:19
bacek What is policy of using tags? 08:20
I want to tag current gen_gc as checkpoint
seen jnthn
aloha jnthn was last seen in #perl6 17 hours 34 mins ago saying "So clearly it's the Perl 6 mojolicious port. ;)".
08:27 bacek left 08:29 lucian_ joined 08:31 lucian__ joined 08:32 lucian left 08:34 lucian__ left 08:35 lucian_ left 08:37 bacek joined
moritz good morning 08:56
bacek: is there a new gen_gc patch for rakudo? or does the old one work with the new commits in the branch? 08:57
bacek moritz, old one is good enough :)
dalek rrot: 0617415 | fperrad++ | runtime/parrot/library/distutils.pir:
[distutils] avoid NQP confusion
 08:58
rrot/generational_gc: da583c8 | bacek++ | src/gc/gc_gms.c:
Obvious optimization: don't check pool for all generations again and
 08:59
rrot/generational_gc: 6c4a878 | bacek++ | src/gc/gc_gms.c:
Optimize is_foo_ptr more: skip objects which will be skipped anyway.
bacek afk # beer celebration time!
09:14 woosley joined 10:22 adu left
moritz \\o/ All tests successful. 10:27
1187 / 60
aloha 19.7833333333333
bacek moritz, hooooray! 10:29
moritz now testing on master, just to be safe 10:30
bacek How it's compared to "master" in terms of performance?
moritz and then I'll bump PARROT_REVISION, and push
jnthn bacek: wow! :D
moritz bacek: not sure, will do a timing as soon as the build finished
jnthn bacek++ # generational gc
bacek moritz, ok :) 10:31
jnthn, just about one year of fixing parrot's GC :) 10:32
10:33 mtk left
jnthn bacek: :) 10:34
bacek: IIUC, the PIR phase got a little slower? But it's a notable win overall? 10:35
bacek jnthn, overall it's a win. Even without any tuning at all.
jnthn bacek: *nod* Just notable that the parse phase got a load faster, the post a little but the PIR phase got slower. 10:36
bacek GenGC collects much more often then MS2.
jnthn Ah, OK
bacek Which cn cause some slowdown when a lot of old objects survived. 10:37
s/ cn / can /
(And my test was made without 2 latest commits for obvious optimizations :) 10:38
jnthn ooh :) 10:40
bacek hmm...
Actually, I think running sweep between phases can help. 10:41
moritz 11:37 <@bacek> Which cn cause some slowdown when a lot of old objects survived. 10:44
I thought the reason for gen gc was that old objects don't have to be reconsidered that often? 10:45
bacek moritz, it's "A LOT". As in rakudo :)
moritz, it's not so simple. Tracing of roots has linear dependency on number of total live objects.
GenGC collects memory about 10 times more often than ms2. 10:46
And selection of generation to collect is brain dead.
moritz I read that as "can be optimized a lot" :- 10:47
)
bacek We need nwellnhof++ magic for gen_gc_dynamic_threshold :)
moritz, yes. gen_gc isn't optimized at all. 10:48
It's barebone implementation.
Which is already faster :)
mikehh bacek: readt for codetest fixes yet? 11:05
bacek mikehh, apart from 2 c++ comments - yes
mikehh bacek: 'k I'll work on it
bacek mikehh, thanks! 11:06
11:06 woosley left 11:14 contingencyplan left
dalek rrot/generational_gc: 312a531 | bacek++ | src/gc/gc_gms.c:
Remove (now) unused function
 11:43
rrot/generational_gc: 6ac827e | bacek++ | src/gc/fixed_allocator.c:
Don't check unaligned 'pointers'
rrot/generational_gc: 1880c15 | bacek++ | src/gc/gc_gms.c:
Small optimizations for is_foo_ptr.
tracwiki: v76 | jkeenan++ | ParrotQuotes 12:08
tracwiki: trac.parrot.org/parrot/wiki/ParrotQ...ction=diff
bacek msg cotto m0 skeleton looks about all right 12:09
aloha OK. I'll deliver the message.
bacek oofib isn't good GC test. Survival rate is about 0.001%. Which is quite different from any real-life usage. 12:13
We need a new one.
Iiiinteresting. All synthetic tests are _slower_ on gen_gc. But rakudo is faster... 12:27
moritz (1629 - 1187) / 1626 * 100 12:40
aloha 27.1832718327183
moritz that's the spectest speedup for rakudo
(just a single measurement for each value, so take with care)
but... wow
12:42 bluescreen joined
bacek moritz, you welcome :) 12:43
12:43 darbelo joined 13:00 kid51 joined
kid51 generational_gc: --optimize: linux/i386 PASS smolder.parrot.org/app/projects/rep...tails/8731 13:00
Coke msg dukeleto : dukeleto-- # github.com/parrot/parrot/commit/42...3#comments 13:08
aloha OK. I'll deliver the message.
Coke bacek++ 13:13
dalek rrot/generational_gc: 71e0c76 | jkeenan++ | src/gc/gc_gms.c:
[codingstd] Fix line length in a DEFINE.
 13:17
kid51 msg bacek generational_gc has some more codingstd errors 13:18
aloha OK. I'll deliver the message.
kid51 msg bacek generational_gc --optimize on Darwin/PPC gets failures in t/op/gc-non-recursive.t (unexpected) and t/op/number.t (expected) 13:19
aloha OK. I'll deliver the message.
nopaste "kid51" at 192.168.1.3 pasted "generational_gc: darwin/ppc: -O3: failures in two tests" (21 lines) at nopaste.snit.ch/31224 13:20
13:23 kid51 left 13:27 lucian joined 13:28 lucian_ joined 13:29 lucian_ left, lucian__ joined
lucian__ damned university proxy 13:29
13:32 lucian left
tadzik don't tell me, I can't pull generational_gc here :( 13:33
13:42 whiteknight joined
whiteknight good morning, #parrot 13:42
moritz \\o 13:43
tadzik good morning whiteknight
whiteknight good morning moritz, tadzik. How are you gentlemen doing today? 13:44
tadzik I'm waiting for my exam results, and avoiding learning physics
moritz whiteknight: for the next few months, always expect me to be tired :-) Apart from that, I'm fine :-)
glad about gen_gc speedups 13:45
whiteknight moritz: trust me, I know what to expect
moritz but it's well worth it
whiteknight yes it is
I'm testing generational_gc right now. I suspect there is going to be a lot of tuning and optimizing still to do on it 13:46
but if we're seeing a 25% improvement on Rakudo timings, that's a great start
moritz indeed
lucian__ whiteknight: do you have some docs describing its design?
tadzik so my joke about generational_gc_dynamic_treshold came out to be serious business :)
moritz it might mean we should start looking for different bottlenecks :-) 13:47
whiteknight lucian__: bacek has been laying out his algorithm in pod comments on his branch
moritz: yes. plobsing has been working hard on packfile bottlenecks and those have decreased lately
and with GC bumped up, I think our next area of concern is PCC
tadzik pcc?
moritz I guess PCC comes.. right
tadzik: calling conventions 13:48
whiteknight tadzik: Parrot Calling Conventions
basically, method dispatch and parameter marshalling
moritz ie how continuations and routines receive their arguments
whiteknight we create at least two PMCs for every invocation which is needlessly wasteful
not to mention that we create a signature PMC for every call site 13:49
actually, that signature might be a STRING literal 13:50
I can't remember what it looks like right now
Coke we really need something other than C++ comments to indicate TODO. ;) 13:54
whiteknight Coke: Why's that?
lucian__ whiteknight: github.com/parrot/parrot/blob/1880...c/gc_gms.c is indeed informative
whiteknight it causes a clear test failure 13:55
13:55 lucian__ is now known as lucian
whiteknight lucian: yes, that's the one 13:55
Coke whiteknight: because it makes testing a PITA.
lucian whiteknight: interesting how many generations it has. i'm curious how it stacks up to a semispace generational gc 13:56
whiteknight lucian: yes, it would be nice to see side-by-side comparisons. I don't suspect we'll have that for a long time
Coke was going to do a fulltest run on the bacek's branch, but it's going to fail. 13:57
lucian whiteknight: i'm curious because most research shows gen semispace to be second only to immix for general code
whiteknight Coke: ah, I see what you are talking about
Coke ugh. why is fulltest defined as invoking make instead of just depending on the other targets? 13:58
whiteknight msg bacek t/op/gc-non-recursive.t is either hanging for me or taking a *very* long time to complete on the generational_gc branch. Ubuntu x64. I'm trying to submit a smoke report now 13:59
aloha OK. I'll deliver the message.
13:59 lucian left
whiteknight Immix GC does look like a pretty interesting algorithm. I don't think I've ever read this paper before 14:01
It always bugs me when these researcher people are doing their work on the JVM 14:02
14:04 rurban_ joined
whiteknight hmm...the printer here is taking it's sweet time on this Immix paper 14:06
14:07 rurban left, rurban_ is now known as rurban 14:11 plobsing left
whiteknight msg bacek: nevermind, the gc-non-recursive.t test did pass, just took a very long time 14:16
aloha OK. I'll deliver the message.
14:31 plobsing joined
whiteknight msg bacek t/pmc/key.t segfaults on my machine (generational_gc) after test 3. 14:48
aloha OK. I'll deliver the message.
whiteknight it wouldn't surprise me in the least if keys were creating problems with respect to the Gc
actually, looking at that file, it looks like the first test always passes no matter what. Bad test 14:50
14:59 mtk joined
whiteknight msg bacek sorry, false alarm about t/pmc/key.t. All tests pass for me again after a realclean. 15:09
aloha OK. I'll deliver the message.
15:10 mtk left
dalek rrot: 5cb57d1 | Whiteknight++ | t/src/embed/api.t:
remove a small debugging thing where I was writing test temporaries to a local file instead of a temp file
 15:11
15:14 mtk joined 15:17 benabik joined
benabik Morning, #parrot! 15:18
15:22 minusnine_ joined
whiteknight good morning, benabik 15:32
how are you doing todaY?
benabik Sleepy. Spent too much time last night implementing a simple worker thread pool for a school project. :-D 15:33
whiteknight ouch
benabik Technically, the project doesn't even need threads, but I'm not going to waste CPU cores when I have to test 2000 numbers for primality.
15:33 lateau joined
benabik Wish I could say I was using parrot, but C++ and boost help when I'm trying to get speed. 15:34
whiteknight no, Parrot doesn't scale well to multiple CPU cores yet 15:35
our threading model is....not good
sorear How big are these numbers?
benabik sorear: 81000-83000. Big problem is that for every number n, I have to test it n times. (Finding experimental error for Miller-Rabin.)
dalek nxed: r804 | NotFound++ | trunk/winxedst (2 files):
new predefined function typeof
 15:39
cotto_work ~~ 15:40
15:45 plobsing left 15:48 ambs joined 15:55 contingencyplan joined 15:56 minusnine_ left 15:59 bluescreen left 16:01 theory joined
cotto_work bacek: why is 6ac827ee (Don't check unaligned 'pointers') needed? 16:05
16:11 plobsing joined, Andy joined
whiteknight yes, I was wondering about that myself 16:15
I suspect it may have to do with stack scanning
16:16 Psyche^ joined 16:17 Patterner left, Psyche^ is now known as Patterner
whiteknight NotFound: ping 16:38
q 16:39
NotFound whiteknight: pong 16:40
whiteknight NotFound: in my imcc_compreg_pmc branch, I'm running into a problem with Parrot_ext_try 16:41
benabik IRC table tennis. Not the fastest moving sport in the world.
whiteknight Parrot_cx_delete_handler_local is throwing an exception, saying there is no handler to delete. Then it jumps back to the handler in Parrot_ext_try for some reason and starts again. Infinite loop
Parrot_pcc_get_handlers is returning PMCNULL 16:43
NotFound whiteknight: do you know were the exception comes from? 16:44
whiteknight inside IMCC somewhere 16:45
NotFound whiteknight: is easy to reproduce?
nopaste "Whiteknight" at 192.168.1.3 pasted "Program to reproduce for NotFound++" (3 lines) at nopaste.snit.ch/31229 16:47
cotto_work dukeleto: ping
whiteknight that's in the imcc_compreg_pmc branch, so things are a little different there from master
NotFound Is that branch in origin?
whiteknight yessir 16:48
The first exception being thrown is "No handler to delete" from Parrot_ext_try, line 356
okay, I think I figured out part of the problem. It's a different context. 16:51
the context where we set the handler is calling a new context
NotFound What does :postcomp do? I never used that. 16:52
whiteknight it's the same as :immediate, I think 16:53
it either is, or probably should be, deprecated
okay, that is the problem. IMCC calls into a new CallContext because it needs to run ops for the optimizer 16:54
so Parrot_ext_try is looking for handlers in that context when the error is thrown, not looking in the context where the handler was set
NotFound Maybe the problem is in handling C exception handlers, then. 16:55
whiteknight I think what we need to do is create a new Parrot_ex_delete_c_handler() that looks up recursively
Parrot_cx_delete_handler_local only looks in the current context
NotFound Maybe, but if we have a problem with C handlers we should fix that. Or at least, document how they are invoked. 16:57
whiteknight it's not a problem with the C handler. That handler is being found and invoked fine
the problem is trying to delete the handler as a local handler, when it's from a caller context
NotFound But not with the context one may expect.
whiteknight oh, so you're saying the C handler should unwind the call graph? 16:58
NotFound Given that it has no way to resume, the throw context is uninteresting.
But maybe doing the same as finalize is a better way, more consistent with pir handlers.... 17:00
dalek rrot/whiteknight/imcc_compreg_pmc: 780beef | Whiteknight++ | compilers/imcc/ (3 files):
Don't show the 'included from file' message in debug output if we aren't compiling from a file. Add some TODO notes
whiteknight NotFound: so if we refactor the logic of finalize_p out into a function, like Parrot_ex_finalize, we could reuse that inside Parrot_ext_try?
NotFound whiteknight: I think so, let me take some look at it. 17:01
whiteknight okay
there are a few ways I think we can fix this. We just need to pick a good one
if we add another "cleanup first" function pointer to Parrot_ext_try, I can manually pop my own context 17:03
17:04 cotto_work left
whiteknight though that's probably not the most flexible way to do it 17:04
I still like the idea of Parrot_ex_delete_c_handler, that takes a jump_buf and removes it from the list
17:05 cotto_work joined
whiteknight that's not the best solution here either, but I think it would be useful 17:05
NotFound whiteknight: Parrot_ext_try is a helper, if someone needs more flexibility he can set its handler on its own way.
whiteknight ok
17:05 cotto_work left
whiteknight I would like to try to use Parrot_ext_try here instead of creating a new version just for stupid IMCC 17:06
NotFound whiteknight: I also like the idea of a more controlled way of deleting handlers, both for C and for pir handlers.
17:07 cotto_work joined, cotto_work left
arnsholt NotFound: Winxed is independent of NQP for parsing and such, isn't it? 17:07
17:07 cotto_work joined
NotFound arnsholt: yes, it has a hand written parser. 17:07
17:08 cotto_work left, cotto_work joined 17:09 cotto_work left
arnsholt Are there any general tips or pitfalls you discovered while doing that which I should know? I'm finding some corner cases in Prolog's syntax that turn out to be surprisingly hard to get right in NQP-rx 17:09
So I'm starting to consider replacing at least parts of it
17:10 cotto_work joined
whiteknight arnsholt: what syntax is giving you headaches? 17:10
arnsholt Operators as terms, essentially
NotFound arnsholt: I just discovered that, as I expected, it was easier for me to write my own parser than fight with nqp ;)
arnsholt Stuff like X = (=)
Which should unify X with the atom '=' 17:11
whiteknight oh yes, I can imagine that being touble
plobsing arnsholt: Ī©Ī· + tinlizzie.org/ometa/ometa-js-old/prolog.html
arnsholt Yeah, that was another thought I've been considering 17:12
Since O-Meta is PEG-based and Prolog is essentially all operator precedence grammar it should be a good fit
dalek rrot/m0-spec: dddb51c | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add concurrency, expand FFI stub a bit
 17:14
17:16 jan left 17:17 cotto_work left, cotto_work joined, cotto_work left
arnsholt NotFound: I've found NQP to be pretty pleasant to work with though 17:18
Although considering all my previous experience has been with C and flex/bison that might not be saying much =)
17:19 mj41 left
NotFound arnsholt: I'm not fluent with perl-alike syntax and, at the time I started winxed, nqp and its grammars were a moving target. 17:20
moritz and to be fair, NQP was never well documented 17:21
arnsholt Yeah, I've spent a fair amount of time spelunking in the NQP and Rakudo sources, and bugging pmichaud and others 17:22
NotFound And I have a strong personal bias towards hand written parsers.
arnsholt I found a page on TT the other day that explained the whole EXPR business pretty well though
darbelo Say, is plumage working for anyone right now? 17:23
NotFound Also, yacc is from the '80, we aren't even in the same millenium X-)
arnsholt Exactly!
whiteknight yeah, all the cool kids are using bison now
:)
moritz *cough*
NotFound Mistake, bison is from the '80, yacc is even older. 17:24
arnsholt Yeah. yacc is mid-70ies IIRC
17:25 lateau left
NotFound Nah, the cool kids must use Ī©Ī· these days. 17:25
whiteknight I can't even type that
NotFound No? You're not cool, then ;)
whiteknight oh no! This is like high-school all over again!
arnsholt I can't type it either. But I do have copy-paste =D 17:26
darbelo The trick is not confusing the initial Ohm with an Omega.
whiteknight :) hello darbelo
darbelo hi
arnsholt Yeah, that's the hardest part. My philologer side cringes a bit every time I think about it =)
moritz sounds like a cooking receipt: "you start with a unit, and add a greek small letter..." 17:27
NotFound The next unicode revision should have an ometa codepoint.
17:27 cotto_work joined
darbelo Ampere had it easier, typographically speaking. 17:27
arnsholt He didn't get his own codepoint though =) 17:28
pmichaud wants a camelia codepoint :-)
arnsholt moritz++ just discovered that Ī© is in fact U+2126 OHM SIGN, not a capital omega 17:29
pmichaud maybe čœØ is close enough
or č¶ 17:30
17:31 dmalcolm joined, cotto_work left, cotto_work joined
cotto_work apparently now trying to connect to #perl6 kills xchat 17:32
NotFound whiteknight: looks like the problem was not what I expected. The problem happens while deleting the handler in try part, not in the catch one. 17:34
whiteknight NotFound: i've seen it happen in both
it gets thrown deleting the handler in the try part, then infinite loops in the catch part 17:35
NotFound Yeah, but in starts in the try.
17:35 cgaertner joined, cotto_work left, cotto_work joined
cgaertner *appears* 17:35
Unicode 4.0, chapter 7.2: "The ohm sign is canonically equivalent to the capital omega, and normalization would remove any distinction. Its use is therefore discouraged in favor of capital omega."
*disappears*
17:35 cgaertner left, ambs left 17:36 ambs joined
whiteknight ....lolwat? 17:36
tadzik :D
Coke is so glad so much energy is focused on that instead of the language itself. 17:37
arnsholt Coke: Not to worry. I'll probably end up porting my grammar to it =) 17:38
darbelo Unicode, like klingons, make anything better. 17:39
Better, and more prone to otherwise avoidable violence.
arnsholt Since XML is like violence in that if it doesn't solve your problem, you're not using enough, does that mean XML is a corollary of Unicode? 17:41
darbelo <āˆ‘/> 17:43
17:43 mj41 joined
NotFound whiteknight: a quick fix is to do pop_context while the current context is not the same as the initial 17:44
whiteknight NotFound: where to pop_context? In Parrot_ext_try?
NotFound whiteknight: yes, before Parrot_cx_delete_handler_local
17:45 ambs left
Hackbinary good evening #parrot 17:45
whiteknight okay, I'm going to have to write a custom try/catch routine for IMCC, for now
We can consolidate later when we figure out a better way to resolve it
17:46 ambs joined
NotFound In that particular case, I suppose that imcc returning without restoring the initial context is wrong. 17:46
Hackbinary arnsholt, do you have link the <EXPR> information?
plobsing whiteknight: isn't a custom try/catch in IMCC one of the things you hated the most aabout the old way?
arnsholt Hackbinary: trac.parrot.org/parrot/wiki/NQP-rx%...%20Parsing 17:47
Hackbinary arnsholt, cheers
arnsholt No problem. See also trac.parrot.org/parrot/wiki/HLL%20Resources (which includes the EXPR stuff)
whiteknight plobsing: No, I wouldn't say I hate it "the most". It's not too wide-spread really 17:48
17:48 cotto_work left, cotto_work joined
whiteknight and plus, this is a problem with Parrot_ext_try that I need to work around, not a permanent solution 17:48
plobsing ok
NotFound The problem with the pop approach is that I don't know what to do if popping the context reaches a null context. You can't delete the handler but you can't return leaving a handler that can longjmp to a lost stack frame
whiteknight I will be using Parrot's exceptions system, just setting up my own custom C handler
NotFound: The real solution is still to use something like finalize here 17:49
or something else to consolidate contexts
or have ExceptionHandler unwind the context graph when we invoke a C handler, though that may have repercussions elsewhere 17:50
NotFound Well, I think that in the context of a extension aborting is an option.
17:50 cotto_work2 joined
whiteknight IMCC is still central enough that we can't treat it like an extension yet 17:50
17:50 cotto_work2 left
whiteknight plus, we can't abort when IMCC has an error. We have hundreds of tests for that behavior already that I need to preserve 17:50
we do need to be able to handle syntax and compilation errors 17:51
NotFound whiteknight: yeah, but if gets fucked up to the point of being unable to locate the initial context, aborting is the only option.
whiteknight okay, in that situation, yes.
I could cache a copy of the first context in Parrot_ext_try, and pop back to it
cotto_work Could someone in #perl6 see if they mind taking the funny characters out of the topic? I suspect they may not be xchat's friend. 17:52
NotFound I can add that to master, and emit a warning in that case to not silently ignore possible problems.
whiteknight ok
Another solution I could use is to stop using Parrot_ex_throw_from_c_args directly in IMCC, and use a custom wrapper routine which always cleans up the context first 17:53
it would be nice to have a single error-handling mechanism in IMCC for once
NotFound I guess it may be better to first locate why the context isn't restored by imcc. 17:54
whiteknight that is actually a very good question 17:55
I will have to look through and see where I am setting that
er, where IMCC is doing that
Coke cotto_work: you mean Ā»Ć¶Ā« ?
plobsing haven't they had that since forever? 17:56
cotto_work Coke: yes
I'd be surprised if that were the problem, but I can connect to other channels just fine. 17:57
17:57 ambs left, ambs_ joined
arnsholt If xchat barfs on the mini-camlia, I suspect it's an encoding issue 17:57
moderator Ā»Ć¶Ā« Parrot 3.0.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: Fix ipv6-related failures | Test imcc_interfaces and annotations-tree branches 17:58
cotto_work or that 17:58
Coke or, we could try here ;) can you quit and rejoin?
NotFound whiteknight: or maybe a simple way is to always finish imcc via exception, throwing a control return or something like that on success.
cotto_work I'll another instance of xchat, but that's a good idea. 17:59
17:59 cotto_work2 joined
cotto_work2 seems to work 17:59
sjn Ā»Ć¶Ā«
Coke so, I'll call off the hounds.
17:59 cotto_work2 left
benabik Ā»Ć¶Ā« ? 17:59
tadzik it's Camelia, the Perl 6 butterfly 18:00
sjn in utf8 \\o/
Coke unicode-art butterfly.
moderator Parrot 3.0.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: Fix ipv6-related failures | Test imcc_interfaces and annotations-tree branches 18:00
benabik Ahhhh.... 18:00
sjn benabik: if you can't see something that vaguely reminds of a butterfly, then update your irc client to something that handles utf8 :) 18:01
benabik sjn: I can see it, I just didn't see it. :-D
sjn then all is fine! \\o/ :)
NotFound Perl6 Unicode Rorschach tests X-) 18:02
sjn heheh
benabik Perhaps we should register that at unicodeart.com. :D 18:03
Anyway, back to $work
moderator Parrot 3.0.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: Fix ipv6-related failures | Test imcc_interfaces branch 18:04
plobsing annotations-tree was merged 18:04
18:04 ambs_ left
cotto_work wacky 18:05
whiteknight if we wrote an IRC client on top of Parrot, it would handle unicode just fine 18:06
cotto_work I wonder what those crazy #perl6 folks are doing that's making xchat sad.
moderator Parrot 3.0.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: Fix ipv6-related failures 18:06
whiteknight imcc_interface branch is old-hat 18:06
darbelo whiteknight: That sounds kind of achievable. 18:07
The parrot-powered IRC client, I mean
whiteknight yeah
I was working on a parrot plugin for xchat at one point, but I gave up because I had better things to do 18:08
plus, that wouldn't help xchat not barf on channel topics
I would use an IRC-on-Parrot client if it existed
darbelo I was thinking of something irssi-ish, but simpler.
whiteknight yeah, that would be awesome 18:09
Tene iirc x-chat can have different encoding settings per-network
whiteknight if it's separated out into a library + frontend, we could easily add in a proper GUI later
Tene If it's fine with that in the topic here but not there, you may want to check that
darbelo ā€¦ I was thinking of something irssi-ish because I don't like 'proper GUIs' :) 18:10
cotto_work Tene: I tried with several likely-looking charsets and got the same result..
Tene 'k 18:11
Coke we had, at one point, an irc bot written in partcl.
sadly, it was killed by parrot.
whiteknight parrot the destroyer
I bet it would be pretty easy to put together the basics of an IRC client in NQP 18:13
I don't have a good reference for the protocol though
Hackbinary almost a silly question, is the PIRC work still going on?
whiteknight Hackbinary: no, but not because we don't want it to 18:14
no active developers
Hackbinary okay, I'm going to add the pirc to the glossary then
:D
benabik whiteknight: www.irchelp.org/irchelp/rfc/index.html
Hackbinary pirc is the next generation of the compiler, yes? 18:15
18:16 lucian joined
cotto_work Hackbinary: no. PIRATE is, but we're doing our best to make sure that it can use the PIR that imcc uses 18:16
Coke pirc was an experimental attempt to replace imcc.
but it was never really integrated with the parrot, so it was never really tested. 18:17
s/the//
18:18 jsut joined
Coke It was not /un/wanted. 18:18
mikehh still getting intermittent failures with t/pmc/threads.t - see smolder reports # 8788 vs #8789 18:20
whiteknight eventually we are going to need to simply nuke that test from orbit 18:21
mikehh got a failure in the smoke test #8788 , reran #8789 - no failure 18:22
dalek rrot: 8bf9b75 | NotFound++ | src/extend.c:
restore initial context in Parrot_ext_try
dukeleto ~^~
cotto_work dukeleto: have you played with fugitive? 18:23
18:23 jsut_ left
mikehh whiteknight: I can only see it as a timing problem, don't know how to fix it though 18:23
dukeleto cotto_work: nope. what does it do?
cotto_work dukeleto: github.com/tpope/vim-fugitive/ 18:24
supposed to be awesome for git-vim integration
mikehh cotto_work: looks good, have you tried it? 18:27
cotto_work not yet 18:28
dukeleto cotto_work: i've tried other git+vim integration things, which I haven't used much. Will check it out.
cotto_work dukeleto: I'll look forward to hearing your thoughts. mshared.tumblr.com/post/3215710879/...d-fugitive was the article that pointed it out, though I saw it previously on hacker news. 18:29
18:36 M_o_C joined 18:37 davidfetter joined 18:39 M_o_C left
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#8789) fulltest) at 3_0_0-514-g5cb57d1 - Ubuntu 10.10 i386 (g++-4.5) 18:39
with the caveat I am still getting intermittent failures with t/pmc/threads.t (not that often but still getting them) 18:40
dukeleto cotto_work: looking at your m0 spec stuff now 18:42
cotto_work: shall i branch off of your branch? Or shall I commit directly to it and we can hash stuff out?
cotto_work dukeleto: commit directly and we can hash it out 18:43
18:47 mtk left 18:48 mtk joined
cotto_work dukeleto: what are you thinking? 18:54
atrodo cotto_work> Any value in me filling out a copy of the m0 spec with what I've done in my prototype? 18:58
dalek rrot/m0-spec: 42ed456 | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
Start the list of M0 ops and add a not about CPS
 19:00
dukeleto atrodo: what do you mean?
cotto_work atrodo: It will be worthwhile to have a clear description of how your prototype address those concerns. 19:01
dukeleto s/not/note/ # grumble
cotto_work As long as there's a clear indication that something's being done by your prototype (as opposed to being part of the proposed final spec), go for it.
dukeleto cotto_work: anything in my recent commit that worries you? 19:03
atrodo: how do you allocate or free memory in your lorito prototype? I don't seem to see opcodes for that 19:04
cotto_work "context" isn't defined. 19:05
whiteknight . 19:06
dukeleto cotto_work: indeed 19:07
dukeleto fixes that
19:07 whiteknight is now known as wknight8111
cotto_work atrodo: did I ever find out from you if the M0 concall time would work? 19:10
darbelo dukeleto: Out of curiosity, have you built/tested plumage lately? 19:11
dukeleto darbelo: i think i did about a month ago
dalek rrot/m0-spec: d4fd03c | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
Attempt to define a Lorito context
dukeleto darbelo: are you noticing some problems?
darbelo The setup.pir looks broken now. But I've been away from both parrot and plumage that it could be something in my environment. 19:12
dukeleto darbelo: did you clone from the new github home of plumage?
darbelo parrot/plumage.git 19:13
ttbot Parrot 71e0c767 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/8707
darbelo setup.pir is calling "$S0 = get_nqp()" which isn't defined anywhere. 19:14
19:14 wknight8111 is now known as whiteknight
darbelo then it assigns it to the prove_exec key of the config hash. 19:15
I commented it out and it worked fine, tested fine too.
But it seems too trivial a mistake to have gone unnoticed. 19:16
atrodo dukeleto> The new opcode is an allocate, and I don't do any freeing of memory because of the lack of GC 19:18
cotto_work> We talked about time, nut not about day
dalek Heuristic branch merge: pushed 600 commits to parrot/lorito by leto 19:19
19:19 lucian_ joined
dukeleto atrodo: lack of gc? 19:19
atrodo: M0 will need to know about the GC
atrodo dukeleto> Right, but my prototype hasn't done anything with GC 19:20
dukeleto darbelo: i just built and tested plumage successfully 19:21
cotto_work atrodo: ok. That's what I thought.
darbelo dukeleto: From a clean checkout?
dukeleto darbelo: i did a "parrot setup.pir clean"
darbelo: updated plumage.git, then did "parrot setup.pir test" and all tests passed 19:22
cotto_work: we need to know what lives inside a Lorito Context PMC
19:22 lucian left
darbelo dukeleto: can you ack for ''get_nqp" in your checkout. 19:23
?
dukeleto darbelo: i only see it in setup.pir. It might be a function that distutils.pbc provides
darbelo: what version of parrot are you using? 19:24
19:24 lucian joined
darbelo The wrong one, apparently. I'll look into that. 19:25
19:25 jsut_ joined
whiteknight get_nqp is defined in distutils, I think 19:25
cotto_work dukeleto: indeed we do 19:26
19:27 lucian_ left
whiteknight . 19:29
19:30 jsut left
cotto_work ... 19:30
whiteknight (sorry, I'm checking out the IRC messages in my packet sniffer to see what they look like)
benabik It's called get_nqp_rz now, I think. 0617415: "[distutils] avoid NQP confusion" 19:31
s/rz/rx
whiteknight this all looks extremely easy to implement
cotto_work ok
atrodo whiteknight> IRC is not a complicated protocol. Most of the complexities are in the conveniences clients add
whiteknight atrodo: my new client will have no conveniences 19:32
19:32 lucian left
atrodo whiteknight> I'm excited to see it 19:33
whiteknight it may never happen
atrodo I hope it does 19:34
whiteknight what I don't know how to do really is the polling IO 19:35
we don't really have an event-based functionality in Parrot to use
we really need a Poll PMC 19:36
Tene what? async IO? who uses that?
They can just use threads instead... oh wait...
whiteknight Tene: :)
atrodo Tene++
whiteknight Tene: you interested in working on a Poll PMC?
some kind of eventloop PMC would be nice 19:37
arnsholt Implementing this eval business is kinda hard. Who'da thunk it =)
Tene whiteknight: a Select PMC has been on my task list for... three years? 19:38
So, yes, theoretically.
whiteknight Tene: Async IO is still on my tasklist, but there are other priorities that I am working on first 19:39
and my list of priorities keeps growing
19:40 lucian joined
Tene I still feel slightly grumpy about threads having *never* worked for HLLs. When I opened tt 757, as far as I could tell, it had always been that badly broken 19:40
arnsholt Is there a mechanism that lets me attach an Eval PMC to a new lexical context?
Tene it even got patches by two newly-contributing people that were mostly ignored
whiteknight Tene: yeah, the threads situation has been terrible for as long as I remember 19:41
I don't remember seeing any patches, but I wasn't focusing on that system for much of my time
Tene whiteknight: as I remember, it should have worked fine if interpreter cloning didn't crash 19:42
cotto_work I'm still not entirely sure why it didn't get ripped out wholesale.
whiteknight cotto_work: people would rather have something that doesn't work than have nothing at all
benabik people-- 19:43
whiteknight Tene: There were more problems than just interpreter cloning, I think
19:43 tadzik left
whiteknight we didn't have any way to share data. STM wasn't working 19:43
19:43 tadzik joined
tadzik :) 19:43
whiteknight we don't have working locks 19:44
benabik tadzik: lawl
Tene whiteknight: I had several test programs that worked just fine, as long as I didn't make any namespaces with more than one component.
iirc
PerlJam whiteknight: so ... where is this list of priorities kept? :)
cotto_work in a heavily guarded vault far underground beneath PaFo HQ 19:45
whiteknight PerlJam: tatooed on the bottom of my foot
PerlJam Opacity is not an asset in this instance unless it's set to 0 :) 19:46
arnsholt Does Sub.set_outer set the outer dynamic or lexical context? 19:47
whiteknight lexical 19:48
19:48 lucian left
whiteknight Tene: that sounds like a pretty big limitation 19:49
Tene: we definitely do want threads obviously. I think the general concensus is that the current design is not the one we are staying with 19:50
arnsholt whiteknight: And iterp['context';1] is the right way to get my caller's context?
Or interp, perhaps
whiteknight ansholt: I don't know if there is a "right" way, but that does look like as good a method as any
arnsholt Right. Then I've done something else wrong 19:51
arnsholt keeps on digging 19:52
Tene whiteknight: I've just been a bit frustrated that I pointed out "Threads work fine, except there's this one bug where interpreter cloning crashes if you have the wrong kind of namespaces or classes", and then new people even came in and submitted patches, and then they were ignored and nobody cared. 19:53
I failed at understanding what was going on in the interpreter cloning guts.
Maybe I should try again someday.
arnsholt A find_lex in my Eval which has had its outer set to interp['context';1] should find a lexical in an outer of the interp[...] scope, no? 19:54
whiteknight Tene: I can understand that frustration. Things would probably be different in current Parrot, but who knows
arnsholt: probably, but it depends how you do it. If the evaled sub is set to :immediate it will probably execute in IMCC which creates it's own context 19:55
if it's not :immediate and you return the sub out of IMCC to invoke it, your method should probably work
arnsholt Oooh. That's probably it
whiteknight inside an :immediate in IMCC, interp["context";2] might work. Or 3 19:56
Tene whiteknight: To be clear, the only real thing I'm saying here is "I'm a little bit frustrated", not "you guys are doing it wrong". I certainly understand and agree.
whiteknight Tene: threads for the general case may have worked fine, but I do know there were some significant design problems relating to callbacks
arnsholt 'blocktype' => 'declaration' was simpler =) 19:57
Thanks! whiteknight++
whiteknight Tene: yeah, I know what you are saying. The question now is where we go from here. I think that maybe a better designed system is where we are heading, but if we fix the current system in place, we will use that for a while at least
it would certainly be better than nothing
Something that would allow us to handle input IO events from multiple sources, like a Select PMC, would be a a next-best-thing as far as most people are concerned 19:58
Tene Sure. 19:59
and that's a very simple PMC
whiteknight is it? I haven't thought about it in a while
Tene Yeah, it is.
afk lunch
whiteknight okay 20:02
PerlJam If I happened to know someone who might be able to help with async or nonblocking IO, what resources should I point him at to come up to speed? 20:04
(I assume that true async IO is blocking on bigger issues though) 20:06
(like no threads :) 20:07
whiteknight PerlJam: That's a good question. The real problem we have with Threads is that we don't know what kind of design we want to go with for them 20:09
Threading is supposed to be part of the Lorito design process, and I know Allison has put a lot of thought into the general topic
but what we should be doing now, pre-Lorito, is anybody's guess 20:10
PerlJam Bummer
whiteknight yeah, tell me about it
20:13 lucian joined
dalek rrot/generational_gc: a1b7b24 | mikehh++ | src/gc/gc_gms.c:
fix codetest failures
 20:13
allison whiteknight/PerlJam: async io is something that should work even wihout full heavyweight threads 20:14
PerlJam allison: great! Where do I point my friend to bring him up to speed? :) 20:15
allison whiteknight/PerlJam: it can even be implemented in terms of the underlying OS, though the semantics vary from one platform to the next
PerlJam: just a sec, poking to see how bare the current PDDs are 20:16
20:17 lucian_ joined
allison PerlJam: so, PDD 22 is a pretty good overview 20:18
PerlJam: the general idea that async io is the same as sync io, but with callbacks will hold true
PerlJam: it's at least a good seed to start with 20:19
PerlJam thanks.
PerlJam crosses his fingers and hopes something good comes of this email he's about to send :) 20:20
allison PerlJam: then, it partly depends on their background. A survey of other implementations would be a good exercise for the volunteer, and good input for the architecture team
20:21 lucian left
whiteknight allison: thanks for the input! 20:22
PerlJam indeed. allison++
whiteknight implementing an async io request with a callback is definitely going to need to involve the scheduler, something I know from recent experience is under-used, under-tested and has some bugs because of that 20:23
PerlJam allison: btw, how's ubuntu going for you?
allison whiteknight: going well, thanks. in many ways it's the same role I played as architect of parrot, just on a larger scale 20:24
whiteknight: keeps me pretty busy, though. I'm happy to see Parrot accelerating with the new teams 20:25
whiteknight: it will certainly require scheduling of some sort, but not necessarily the "one true" central scheduler 20:26
whiteknight: looking at other implementations will provide a good source of ideas on possible avenues to choose from 20:27
whiteknight: (it'll also probably provide sources of horror and amusement :D) 20:28
cotto_work We have plenty of those already. 20:32
allison cotto_work: yah, the world is full of them 20:35
whiteknight I want to make sure we end up with a really good threading system eventually. Allison's PhD proposal and some of the Lorito plans give me hope in the long term 20:36
in the near term, it's hard to figure out what we want to be doing in this area
I do hate to put all our eggs into the Lorito basket
cotto_work which proposal?
20:36 lucian_ left 20:37 jan joined
allison cotto_work: I think I sent you a copy. I was supposed to link it from the Parrot wiki, but haven't yet 20:37
ttbot Parrot a1b7b241 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/8755
atrodo whiteknight> I love putting all my eggs in one basket, that way I know where they all are
cotto_work allison: ok. I'll have to remind myself to look at it when I get home. 20:38
bacek ~~
Good morning humans. 20:39
cotto_work msg cotto Take a look at allison's phd proposal when you get home.
aloha OK. I'll deliver the message.
cotto_work hi bacek
nopaste "bacek" at 192.168.1.3 pasted "gen_gc vs gen_gc performance :)" (23 lines) at nopaste.snit.ch/31241 20:40
bacek aloha, cotto_work
tadzik shit, bacek, what happened? :) 20:41
bacek tadzik, shit happened :) More than 2 generations. 20:42
tadzik so it's not a workaround anymore?
bacek nope
I fixed algo
tadzik supersweet
now it seems as if the gc was the mother of all the performance evilness 20:43
cotto_work sets MAX_GENERATIONS to 8 and waits for the fireworks 20:44
dalek rrot/generational_gc: a7373f4 | bacek++ | src/gc/gc_gms.c:
Attach strings and dirty children to youngest generation calculation.
rrot/generational_gc: 5ef6322 | bacek++ | include/parrot/gc_api.h:
Don't shortcut mark_STRING_alive function. We are using real function in GMS to calculate youngest child.
20:44 fperrad left
dalek rrot/generational_gc: 547b58c | bacek++ | src/ops/ (2 files):
Preserve GC flags from original GC in 'op copy'
 20:44
rrot/generational_gc: 7cd7f05 | bacek++ | src/gc/api.c:
Don't call mark_pmc_header for NULLs from GC API wrapper.
rrot/generational_gc: 5ba2e0c | bacek++ | src/gc/gc_gms.c:
Fix algorithm of handling dirty objects.
rrot/generational_gc: 053b464 | bacek++ | src/gc/gc_gms.c:
Bump number of generations to 8.

We are totally like Smalltalk VM from 80s now...
bacek cotto_work, I did it already :)
tadzik :O
bacek++
dukeleto Oh, the dirty children...
cotto_work bacek: I see
bacek dukeleto, with strings attached
tadzik pulls furiously
bacek seen moritz 20:46
aloha moritz was last seen in #parrot 3 hours 19 mins ago saying "sounds like a cooking receipt: "you start with a unit, and add a greek small letter..."".
whiteknight ha! I like the line about attaching dirty children 20:47
bacek msg moritz can you rerun spectest on bleeding edge gen_gc?
aloha OK. I'll deliver the message.
bacek whiteknight, :)
moritz bacek: sure, will do
cotto_work bacek: what's that smalltalk comment about? 20:51
benabik Good, I thought I was the only one who didn't get it. 20:52
dukeleto cotto_work: we are catching up to the smalltalk VM and now have a gc as good as Smalltalk's in the 80's
whiteknight that's no small feat. They had a lot of good, full-time programmers working on that system
bacek cotto_work, original Smalltalk VM has GenGC. With 8 generations.
dukeleto Or, in other words, we have now caught up to only being 30 years behind the quality of the Smalltalk GC.
bacek moritz, thanks! 20:53
cotto_work booyah
whiteknight but 10 years ahead of the current Parrot GC
dukeleto indeed.
these are exciting times.
cotto_work So what's a current state of the art gc? 20:54
whiteknight Semispace Generational GC looks like one of the better performers
lucian pointed me to a paper this morning about a GC called immix that looks pretty impressive
moritz aren't modern GCs concurrent? 20:56
mikehh bacek: t/op/gc-leaky-box.t is failing
cotto_work For now, I'm happy to technology from the '80s. If they call and want their gc back, tough.
bacek mikehh, non-optimized build?
whiteknight moritz: they can be. A concurrent approach works best on a multi-core or multi-cpu system 20:57
mikehh seems to be bots g++ with and withiout --optimize
both
whiteknight moritz: on a single-core system, a concurrent collector is no good
bacek mikehh, I'll try to check. Later. $dayjob time 20:58
mikehh bacek: although I haven't tesated with --optimize on the latest push
moritz bacek: parrot build on gen_gc fails
with --optimize
$ ./parrot-nqp --target=pir --output=compilers/opsc/gen/Ops/Compiler.pir compilers/opsc/src/Ops/Compiler.pm
make: *** [compilers/opsc/gen/Ops/Compiler.pir] Error 1
tadzik strange, works for me 20:59
running spectests now
moritz git clean -xdf's
cotto_work pessmized build seems ok so far
moritz tadzik: the first rebuild worked, but rakudo's spectest failed
tadzik hmm
moritz so I cleaned, and rebuilt parrot
this time it failed
cotto_work (It add an O(2^n) algorithm, just because.)
;) 21:00
bacek moritz, hmmm... It's bad...
moritz second rebuild worked again
moritz tries rakudo again
tadzik non-deterministic! 21:01
benabik Huh. Just had a failure in t/dynpmc/os.t (OS.lstat)... But running the test again worked.
tadzik maybe there should be a generational algorithm growing new generations of GC algorithms :)
whiteknight tadzik: I shudder to think what the mutator routine for that generational algorithm would look like 21:02
ttbot Parrot 053b464a MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/8823
NotFound If someone wants a new toy to play a bit, winxedxx is starting to be able to compile thing a bit more advanced than helloworld.
moritz WIAT
whiteknight generation 1: segfault. generation 2: segfault. generation 3: segfault
moritz i'm on the wrong rakudo branch
tadzik :D
moritz still doesn't explain the parrot build failures
bacek moritz, can you build parrot without optimize? (Only parrot, not rakudo) 21:03
21:03 lucian joined
whiteknight it looks like there is an implementation of immix for GHC, implemented as a GSOC project in '09 21:07
so, it becomes feasible for us if we want to look into that kind of system 21:08
21:08 lucian_ joined
dukeleto msg kid51 this is relevant to your recent blog post www.meetup.com/pdxpython/events/16518482/ 21:08
aloha OK. I'll deliver the message.
lucian immix isn't that hard to implement 21:11
harder than gen semispace, though
lucian has just read the paper and related
dalek rrot/generational_gc: c5393c7 | luben++ | src/gc/gc_gms.c:
fix couple of compiler warnings
 21:12
rrot/generational_gc: a36c56c | luben++ | / (5 files):
Merge branch 'generational_gc' of github.com:parrot/parrot into generational_gc
whiteknight lucian: I'm going to be reading the paper tonight or tomorrow morning 21:13
We definitely need to focus on getting bacek's new collector merged and tuned before we start talking about anything else
lucian it's interesting. actually, i think it's partly an endorsement of gen semispace 21:14
whiteknight lucian: the problem with either algorithm is that they are going to require copying/compacting, which Parrot really isn't set up to do yet
lucian sure. and my c-fu is low anyway
copying, yes. is that so problematic?
whiteknight I think so, yes. We don't really have any way to update pointers to a PMC if the PMC moves 21:15
we could have pointers to it in registers, in other PMCs, on the stack, etc
lucian hmm. would a second indirection be acceptable? that'd make this easy 21:17
cotto_work If contexts are the only way that PMCs can be accessed in Lorito, copying/compacting suddenly becomes feasible.
whiteknight *if*, yes 21:18
if we reimplement the top 1/2 of Parrot in lorito, and never store PMCs on the stack, that does become feasible 21:19
or, any PMC that was put onto the stack could be manually anchored
but that would be a huge hassle because that happens throughout the codebase
lucian you could have a mechanism for unusually placed objects
stack objects, objects that aren't allowed to move, huge objects, etc 21:20
a mechanism beside the gc. i dont know if it makes sense in parrot
21:21 plobsing left
whiteknight lucian: something like a "pin" would work 21:22
but you would have to manually pin any PMC that wasn't in an accepted "safe area"
tadzik damn, close's code is full of old-style PD
POD
Tene whiteknight: alternately, a method to mark a pmc as relocatable/compactable is feasible. 21:23
everything is pinned by default, but you can un-pin individual PMCs.
whiteknight Tene: yeah, but how would you ever know that it was relocatable?
lucian sure, but a pin is needed anyway for some c apis
21:23 benabik left
whiteknight lucian: any C api with callbacks 21:24
or any C api that takes a data pointer
lucian yep 21:25
i think there were more cases, but the point is that it's needed
whiteknight I assume extensions in Lorito world are going to have the same problem, unless they are written themselves in Lorito
NotFound A data pointer might be kept constant even if the PMC that owns the pointer moves.
Tene whiteknight: If any systems that generate notable quantities of PMCs was refactored to only access PMCs through contexts, etc, it could be possible to identify PMCs that could be safely relocated/compacted, I suppose.
lucian pypy's gc does something about this which i don't fully understand 21:26
whiteknight Tene: yes, that would be a great thing. Accessing values in a context would need to become much less expensive
Tene whiteknight: I can vaguely imagine that as the first part of a gradual parrot refactor that eventually enables large amounts of copying/compacting
But, I'm capable of imagining many impossible things. 21:27
whiteknight Tene: yes. I sincerely hope these kinds of changes are included in the Lorito work
moritz bacek: unoptimized parrot build succeeds
NotFound Now that you said that, maybe a context's registers alike structure will be a good support for PMC attributes. 21:28
whiteknight has to pack up and go home. later 21:29
21:29 whiteknight left
tadzik bacek: one spectest failed 21:38
ttbot Parrot 5ef6322a MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/8896 21:39
21:39 darbelo left
dukeleto Tene: The plan for Lorito is that every operation asks the current context for the interp object. There is no global interp. 21:39
bacek_at_work ~~ 21:43
tadzik, which one? gc-non-recursive?
nopaste "luben" at 192.168.1.3 pasted "Gen_GC number of generations comparisson" (8 lines) at nopaste.snit.ch/31242 21:44
bacek_at_work moritz, hmm.. Looks like I missed some shortcuts.
tadzik bacek_at_work: rakudo spectest
bacek_at_work luben, yeah something like 3-4 generations is enough actually. 21:45
tadzik, which one?
luben yes
tadzik t/spec/S05-mass/properties-derived.rakudo (Wstat: 0 Tests: 256 Failed: 3)
bacek_at_work tadzik, linux/i386?
tadzik bacek_at_work: amd64 21:46
bacek_at_work tadzik, oookey. I'll try to reproduce it on i386. I don't have amd64 around.
nopaste "tadzik" at 192.168.1.3 pasted "polar bears are left-handed" (100 lines) at nopaste.snit.ch/31243
bacek_at_work tadzik, reproduced on i386... 21:51
(148 - 86) / 148 * 100 21:56
aloha 41.8918918918919
21:56 wknight-phone joined 22:04 rurban_ joined 22:07 rurban left, rurban_ is now known as rurban
ttbot Parrot a36c56c9 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/8906 22:08
22:11 lucian left, lucian_ is now known as lucian 22:14 plobsing joined
bacek_at_work lucian, same failure on parrot master. Something non-gc related changed. 22:33
oops 22:34
lucian bacek_at_work: i'm not sure you meant me :)
bacek_at_work tadzik, same failure on parrot master. Something non-gc related changed.
tadzik I see 22:35
gc-related parrot tests pass 22:37
sockets fail, but that's known I think
dalek rrot: 2bf77f5 | NotFound++ | src/dynpmc/os.pmc:
temptative fix for win build (don't have win available ATM)
Hackbinary hello, I have a rather small update to docs/glossary.pod in my fork & branch, hackbinary/parrot --> branch hackbinary/doc-updates 22:42
nopaste "tadzik" at 192.168.1.3 pasted "Drunk ants always fall to the left" (14 lines) at nopaste.snit.ch/31246
tadzik bacek_at_work: ^ tests results
bacek_at_work tadzik, can you rerun pcre test with verbose? 22:46
tadzik I think so 22:48
nopaste "tadzik" at 192.168.1.3 pasted "I ran out of silly sayings" (28 lines) at nopaste.snit.ch/31248 22:49
dalek m-eta-wink-kzd: 9b39b96 | plobsing++ | bootstrap/ometa-base.winxed:
drop hand-rolled typeof() in favour of new Winxed builtin
 22:53
m-eta-wink-kzd: b09429c | plobsing++ | src/OMetaWinxed (2 files):
rebootstrap
dukeleto Hackbinary: pull request? 22:55
Hackbinary: refer to docs/project/git_workflow.pod if you have questions, and if that doesn't answer them, ask me :) 22:56
22:56 cosimo joined 23:03 plobsing left
cotto_work We love pull requests. 23:06
23:10 wknight-phone left, plobsing joined
bacek_at_work tadzik, pcre tests are failing not because of GC (or I couldn't imaging why). Did you try to reconfig parrot? What it says about PCRE in Configure.pl? 23:13
23:17 wknight-phone joined 23:20 kid51 joined 23:21 plobsing left 23:25 wknight-phone left 23:49 whiteknight joined
tadzik bacek_at_work: auto::pcre - Does your platform support pcre...............yes, 8.02. 23:55
but this is interesting: auto::llvm - Is LLVM installed....................................no. 23:57
it's installed and running. Hm

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!