Camelia, the Perl 6 bug

IRC log for #parrot, 2011-02-10

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:15 plobsing joined #parrot
00:35 KaeseEs i would consider an inability to implement gobject a feature
00:35 KaeseEs imagine someone writing a gobject port, and Clippy(tm) pops up. "It looks like youre trying to write malware..."
00:38 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:39 whiteknight joined #parrot
00:40 Tene You can't design a system that disallows all bad uses without also disallowing many good uses.
00:44 dukeleto ENOCLIPPY
00:46 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:50 KaeseEs 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
01:01 whiteknight good evening, #parrot
01:02 dukeleto whiteknight: wilkommen!
01:03 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:30 davidfetter left #parrot
01:35 dukeleto This must be how bacek_at_work does things : http://imgur.com/gallery/sw215
01:37 whiteknight I'm surprised if his method has so many steps
01:40 dukeleto yeah, most of the time it was just 0) Write down solution
01:47 plobsing is there a good way to get code included into a PMC's header file?
01:47 plobsing my alternative is shoving it into one of the "everybody includes these at the top" header files
01:48 bacek_at_work dukeleto, looks familiar :)
01:48 bacek_at_work plobsing, patch Pmc2c to support it...
01:48 plobsing bacek_at_work: better than the alternative. good idea.
02:00 bacek_at_work plobsing, similar to ops: BEGIN_PMC_PREAMBLE/END_PMC_PREAMBLE. For consistency reasons.
02:02 cotto dukeleto, that's great
02:02 dukeleto bacek_at_work: i syndicate :)
02:03 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:10 preflex left #parrot
02:20 preflex joined #parrot
02:46 kid51 joined #parrot
03:03 whiteknight left #parrot
03:06 kid51 ~~
03:13 dalek TT #1988 closed by jkeenan++: lib/Parrot/Pmc2c/PMCEmitter.pm:  make file match package.
03:13 dalek TT #1988: http://trac.parrot.org/parrot/ticket/1988
03:13 dalek TT #2000 closed by jkeenan++: lib/Parrot/Pmc2c/MethodEmitter.pm: make file match package
03:13 dalek TT #2000: http://trac.parrot.org/parrot/ticket/2000
03:19 ryan left #parrot
03:23 adu left #parrot
03:24 adu joined #parrot
03:28 kid51 FWIW, this was a successful build a couple of hours back on the generational_gc branch with --optimize:  http://smolder.parrot.org/app​/projects/report_details/8587
03:28 kid51 left #parrot
03:44 dukeleto ~~
04:05 dalek parrot/leto/embed_grant: a9e2c65 | dukeleto++ | t/src/extend_vtable.t:
04:05 dalek parrot/leto/embed_grant: [t] Parrot_PMC_i_concatenate_str
04:05 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/a9e2c6533f
04:10 dalek parrot/leto/embed_grant: 0786fef | dukeleto++ | t/src/extend_vtable.t:
04:10 dalek parrot/leto/embed_grant: [t] Parrot_PMC_i_concatenate_str
04:10 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/0786fef759
04:38 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:39 cotto 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 ~~
04:40 cotto hi bacek_at_work
04:40 cotto aloha, clock?
04:40 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
04:40 bacek_at_work Good news about gen_gc: rakudo's spectest fails in exactly same bugs with MS2.
04:40 bacek_at_work So, I did merge something wrongly.
04:40 cotto That sounds like an easier problem to fix than a gc bug.
04:41 bacek_at_work cotto, exactly.
04:41 bacek_at_work just careful review diff with master
04:41 cotto yup.  Tedious but doable.
04:42 mtk left #parrot
04:42 cotto great news
04:49 mtk joined #parrot
05:52 bacek_at_work cotto, ping
05:55 cotto bacek_at_work, pong
05:56 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
05:57 bacek_at_work It's only one suspicious diff between gen_gc and master
05:58 bacek_at_work "one and only one"
05:59 cotto looks like I get to dig into VTABLE_getprops
06:00 bacek_at_work it digs into everything
06:00 bacek_at_work memcpy of PMC isn't great idea
06:00 cotto no
06:01 minusnine joined #parrot
06:01 cotto I'm not sure why that's necessary.
06:02 bacek_at_work I changed it to just clone in gen_gc. And looks like I changed (broken anyway) semantic somehow.
06:03 cotto It reminds me of smalltalk's become
06:03 bacek_at_work .morph?
06:04 cotto that too
06:04 rurban_ joined #parrot
06:05 cotto copy seems to do the same thing, but without VTABLE_init
06:05 cotto I see what it's doing but not why.
06:06 minusnine left #parrot
06:07 rurban left #parrot
06:07 rurban_ is now known as rurban
06:09 cotto bacek_at_work, why change the op in gen_gc?
06:16 bacek_at_work to preserve gen_gc invariant about flags
06:17 cotto what about saving/restoring the flags
06:17 cotto that'd also be cheaper
06:17 bacek_at_work "PMC_data(clone)        = NULL;"
06:18 bacek_at_work it's WRONG
06:18 bacek_at_work Many our PMCs with auto_attr set doesn't expect NULL for self.data
06:19 cotto By that point the PMC has already been destroyed.
06:19 cotto nm
06:22 bacek_at_work Rakudo's make spectest is running smoothly now. With "op copy" from master.
06:23 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:25 bacek_at_work yeah...
06:25 bacek_at_work It's kind of "replace in-place"
06:25 cotto yes
06:26 cotto bacek_at_work, how does it mess up gen_gc?
06:26 cotto is it the case that it might cause issues or is it something more certain?
06:26 bacek_at_work It looks very suspicious. And I changed it. In a wrong way
06:27 bacek_at_work Reading it further: I don't think it will cause any problems.
06:27 cotto ok
06:27 dalek parrot/generational_gc: 66a563d | bacek++ | src/ops/ (2 files):
06:27 dalek parrot/generational_gc: Bring 'op copy' back from master
06:27 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/66a563d9dc
06:28 * bacek_at_work don't believe own eyes.
06:28 bacek_at_work make spectest is up to S05-mass
06:28 bacek_at_work without failures.
06:28 bacek_at_work THE VICTORY
06:28 cotto a-freaking-mazing
06:29 cotto bacek++
06:29 bacek_at_work lua test passed
06:29 bacek_at_work HOORAY!!!!
06:29 cotto sweet
06:29 cotto does it need a patch?
06:30 bacek_at_work yes
06:30 bacek_at_work I nopasted it early this morning.
06:31 bacek_at_work http://nopaste.snit.ch/31060
06:31 bacek_at_work this one
06:32 cotto I'm tempted to look for a way around the deprecation policy so that this can go into master sooner.
06:32 cotto that looks like a rakudo patch
06:33 bacek_at_work yes
06:33 cotto ok.  I thought you were talking about Lua.
06:33 bacek_at_work no
06:33 bacek_at_work lua is clear
06:33 cotto nice
06:34 cotto 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:35 bacek_at_work yes
06:36 cotto there aren't too many of those
06:36 bacek_at_work indeed
06:39 theory left #parrot
06:40 bacek_at_work cotto, actually I'm going to fix master branch, so patch can be commited it into rakudo straight away.
06:40 bacek_at_work than we can discuss deprecation policy :)
06:40 cotto sure.  There's no way we're switching to gen_gc before Rakudo's ready.
06:41 bacek_at_work of course not
06:43 cotto How often is Rakudo bumping PARROT_REVISION these days?
06:43 minusnine_ joined #parrot
06:44 bacek_at_work t/spec/S12-methods/calling_sets.t                            (Wstat: 0 Tests: 31 Failed: 1)
06:44 bacek_at_work Failed test:  6
06:44 bacek_at_work Files=544, Tests=27634, 1361 wallclock secs ( 4.62 usr  0.84 sys + 1287.10 cusr 20.77 csys = 1313.33 CPU)
06:44 bacek_at_work Result: FAIL
06:44 bacek_at_work 1294.01user 22.20system 22:44.33elapsed 96%CPU (0avgtext+0avgdata 849520maxresident)k
06:44 bacek_at_work Single test from whole spectest!
06:45 cotto nice
06:46 bacek_at_work ah
06:46 bacek_at_work not actual failure
06:46 bacek_at_work roast was updated
06:46 bacek_at_work but I didn't update rakudo
06:47 cotto you mentioned that we need heavier gc tests
06:47 cotto did you have something specific in mind?
06:49 estrabd left #parrot
06:49 estrabd joined #parrot
06:58 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
07:01 bacek_at_work cotto, just throw a lot of GC load. Preferably with inter-generational links
07:02 bacek_at_work make spectest passed
07:02 cotto bacek++
07:03 bacek_at_work http://nopaste.snit.ch/31154  - rakudo build time
07:04 cotto looking good
07:05 bacek_at_work indeed :)
07:06 bacek_at_work 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".
07:06 cotto I think you'll have a pretty easy time convincing the Rakudo folks to apply that and bump PARROT_REVISION.
07:06 bacek_at_work cotto, not yet
07:06 bacek_at_work I have to fix master little bit
07:06 cotto sure.  tuning first
07:06 dukeleto gen_gc and rakudo are playing nice?
07:07 cotto that's why our hard-working coding robot says
07:07 cotto s/why/what/
07:08 dukeleto anybody know what kind of performance change it incurs?
07:09 dukeleto bacek++
07:09 * dukeleto just saw the nopaste
07:16 dalek parrot: 84fb245 | bacek++ | / (3 files):
07:16 dalek parrot: Add GC API write_barrier function
07:16 dalek parrot: review: https://github.com/parrot/parrot/commit/84fb245364
07:16 bacek_at_work ok
07:16 dalek parrot: 7b43ae3 | bacek++ | src/gc/api.c:
07:17 dalek parrot: Made write_barrier optional in GC Subsystem.
07:17 dalek parrot: review: https://github.com/parrot/parrot/commit/7b43ae36e7
07:17 dalek parrot: 78df613 | bacek++ | t/src/misc.t:
07:17 dalek parrot: Add test that GC_WRITE_BARRIER macro work on all GCs.
07:17 dalek parrot: review: https://github.com/parrot/parrot/commit/78df613e0a
07:17 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 #parrot
07:24 mikehh left #parrot
07:26 bacek_at_work yes. Rakudo with patch builds on current master
07:26 bacek_at_work time to go home
07:26 bacek_at_work see you!
07:27 cotto 'night
07:32 mikehh joined #parrot
07:49 bacek joined #parrot
07:54 cosimo left #parrot
07:54 dukeleto exciting times, these be.
07:55 minusnine_ left #parrot
08:08 dalek parrot/m0-spec: 7d5c222 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
08:08 dalek parrot/m0-spec: add design goals, more stub topics, document scope
08:08 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/7d5c222b85
08:08 dalek parrot/m0-spec: b4ff640 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
08:08 dalek parrot/m0-spec: make stub sections slightly less stubby
08:08 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/b4ff640acc
08:08 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.
08:09 cotto I'm off to bed to dream about shiny new generational gcs.
08:09 cotto 'night
08:10 bacek night, cotto
08:12 cotto bacek, could you do that too if you have a few minutes?
08:12 bacek Hopefully it will not be nightmares :)
08:12 bacek m0?
08:12 cotto yes
08:16 dalek parrot/generational_gc: 42654c8 | bacek++ | src/gc/gc_gms.c:
08:16 dalek parrot/generational_gc: Most important commit to docs: s/(GC algorithm) WILL BE/$1 is/
08:16 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/42654c8122
08:16 bacek I'll do it later
08:16 bacek Have few ideas about fixing gen_gc for more than 2 generations.
08:17 cotto sure.  no rush
08:17 cotto 'night (for real)
08:19 dukeleto cotto: will do
08:20 bacek What is policy of using tags?
08:20 bacek I want to tag current gen_gc as checkpoint
08:20 bacek seen jnthn
08:20 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 #parrot
08:29 lucian_ joined #parrot
08:31 lucian__ joined #parrot
08:32 lucian left #parrot
08:34 lucian__ left #parrot
08:35 lucian_ left #parrot
08:37 bacek joined #parrot
08:56 moritz good morning
08:57 moritz 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 :)
08:58 dalek parrot: 0617415 | fperrad++ | runtime/parrot/library/distutils.pir:
08:58 dalek parrot: [distutils] avoid NQP confusion
08:58 dalek parrot: review: https://github.com/parrot/parrot/commit/0617415aca
08:59 dalek parrot/generational_gc: da583c8 | bacek++ | src/gc/gc_gms.c:
08:59 dalek parrot/generational_gc: Obvious optimization: don't check pool for all generations again and
08:59 dalek parrot/generational_gc: again.
08:59 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/da583c897f
08:59 dalek parrot/generational_gc: 6c4a878 | bacek++ | src/gc/gc_gms.c:
08:59 dalek parrot/generational_gc: Optimize is_foo_ptr more: skip objects which will be skipped anyway.
08:59 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/6c4a87846f
08:59 bacek afk # beer celebration time!
09:14 woosley joined #parrot
10:22 adu left #parrot
10:27 moritz \o/ All tests successful.
10:27 moritz 1187 / 60
10:27 aloha 19.7833333333333
10:29 bacek moritz, hooooray!
10:30 moritz now testing on master, just to be safe
10:30 bacek How it's compared to "master" in terms of performance?
10:30 moritz and then I'll bump PARROT_REVISION, and push
10:30 jnthn bacek: wow! :D
10:30 moritz bacek: not sure, will do a timing as soon as the build finished
10:30 jnthn bacek++ # generational gc
10:31 bacek moritz, ok :)
10:32 bacek jnthn, just about one year of fixing parrot's GC :)
10:33 mtk left #parrot
10:34 jnthn bacek: :)
10:35 jnthn 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.
10:36 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.
10:36 jnthn Ah, OK
10:37 bacek Which cn cause some slowdown when a lot of old objects survived.
10:37 bacek s/ cn / can /
10:38 bacek (And my test was made without 2 latest commits for obvious optimizations :)
10:40 jnthn ooh :)
10:40 bacek hmm...
10:41 bacek Actually, I think running sweep between phases can help.
10:44 moritz 11:37 <@bacek> Which cn cause some slowdown when a lot of old objects survived.
10:45 moritz 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 :)
10:45 bacek moritz, it's not so simple. Tracing of roots has linear dependency on number of total live objects.
10:46 bacek GenGC collects memory about 10 times more often than ms2.
10:46 bacek And selection of generation to collect is brain dead.
10:47 moritz I read that as "can be optimized a lot" :-
10:47 moritz )
10:47 bacek We need nwellnhof++ magic for gen_gc_dynamic_threshold :)
10:48 bacek moritz, yes. gen_gc isn't optimized at all.
10:48 bacek It's barebone implementation.
10:48 bacek Which is already faster :)
11:05 mikehh bacek: readt for codetest fixes yet?
11:05 bacek mikehh, apart from 2 c++ comments - yes
11:05 mikehh bacek: 'k I'll work on it
11:06 bacek mikehh, thanks!
11:06 woosley left #parrot
11:14 contingencyplan left #parrot
11:43 dalek parrot/generational_gc: 312a531 | bacek++ | src/gc/gc_gms.c:
11:43 dalek parrot/generational_gc: Remove (now) unused function
11:43 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/312a53103b
11:43 dalek parrot/generational_gc: 6ac827e | bacek++ | src/gc/fixed_allocator.c:
11:43 dalek parrot/generational_gc: Don't check unaligned 'pointers'
11:43 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/6ac827ee50
11:43 dalek parrot/generational_gc: 1880c15 | bacek++ | src/gc/gc_gms.c:
11:43 dalek parrot/generational_gc: Small optimizations for is_foo_ptr.
11:43 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/1880c15da7
12:08 dalek tracwiki: v76 | jkeenan++ | ParrotQuotes
12:08 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=76&amp;action=diff
12:09 bacek msg cotto m0 skeleton looks about all right
12:09 aloha OK. I'll deliver the message.
12:13 bacek oofib isn't good GC test. Survival rate is about 0.001%. Which is quite different from any real-life usage.
12:13 bacek We need a new one.
12:27 bacek Iiiinteresting. All synthetic tests are _slower_ on gen_gc. But rakudo is faster...
12:40 moritz (1629 - 1187) / 1626 * 100
12:40 aloha 27.1832718327183
12:40 moritz that's the spectest speedup for rakudo
12:40 moritz (just a single measurement for each value, so take with care)
12:40 moritz but... wow
12:42 bluescreen joined #parrot
12:43 bacek moritz, you welcome :)
12:43 darbelo joined #parrot
13:00 kid51 joined #parrot
13:00 kid51 generational_gc: --optimize: linux/i386 PASS http://smolder.parrot.org/app​/projects/report_details/8731
13:08 Coke msg dukeleto : dukeleto-- # https://github.com/parrot/parrot/commit/42654​c81225499a08ca12369e98f33323ee22583#comments
13:08 aloha OK. I'll deliver the message.
13:13 Coke bacek++
13:17 dalek parrot/generational_gc: 71e0c76 | jkeenan++ | src/gc/gc_gms.c:
13:17 dalek parrot/generational_gc: [codingstd] Fix line length in a DEFINE.
13:17 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/71e0c767a0
13:18 kid51 msg bacek generational_gc has some more codingstd errors
13:18 aloha OK. I'll deliver the message.
13:19 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.
13:20 nopaste "kid51" at 192.168.1.3 pasted "generational_gc: darwin/ppc: -O3: failures in two tests" (21 lines) at http://nopaste.snit.ch/31224
13:23 kid51 left #parrot
13:27 lucian joined #parrot
13:28 lucian_ joined #parrot
13:29 lucian_ left #parrot
13:29 lucian__ joined #parrot
13:29 lucian__ damned university proxy
13:32 lucian left #parrot
13:33 tadzik don't tell me, I can't pull generational_gc here :(
13:42 whiteknight joined #parrot
13:42 whiteknight good morning, #parrot
13:43 moritz \o
13:43 tadzik good morning whiteknight
13:44 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
13:44 moritz whiteknight: for the next few months, always expect me to be tired :-) Apart from that, I'm fine :-)
13:45 moritz glad about gen_gc speedups
13:45 whiteknight moritz: trust me, I know what to expect
13:45 moritz but it's well worth it
13:45 whiteknight yes it is
13:46 whiteknight 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 whiteknight but if we're seeing a 25% improvement on Rakudo timings, that's a great start
13:46 moritz indeed
13:46 lucian__ whiteknight: do you have some docs describing its design?
13:46 tadzik so my joke about generational_gc_dynamic_treshold came out to be serious business :)
13:47 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
13:47 whiteknight moritz: yes. plobsing has been working hard on packfile bottlenecks and those have decreased lately
13:47 whiteknight and with GC bumped up, I think our next area of concern is PCC
13:47 tadzik pcc?
13:47 moritz I guess PCC comes.. right
13:48 moritz tadzik: calling conventions
13:48 whiteknight tadzik: Parrot Calling Conventions
13:48 whiteknight basically, method dispatch and parameter marshalling
13:48 moritz ie how continuations and routines receive their arguments
13:48 whiteknight we create at least two PMCs for every invocation which is needlessly wasteful
13:49 whiteknight not to mention that we create a signature PMC for every call site
13:50 whiteknight actually, that signature might be a STRING literal
13:50 whiteknight I can't remember what it looks like right now
13:54 Coke we really need something other than C++ comments to indicate TODO. ;)
13:54 whiteknight Coke: Why's that?
13:54 lucian__ whiteknight: https://github.com/parrot/parrot/blob/1880c15da​798dae10cde05af63cb74d2ec6135a8/src/gc/gc_gms.c is indeed informative
13:55 whiteknight it causes a clear test failure
13:55 lucian__ is now known as lucian
13:55 whiteknight lucian: yes, that's the one
13:55 Coke whiteknight: because it makes testing a PITA.
13:56 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
13:57 * 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
13:57 whiteknight Coke: ah, I see what you are talking about
13:58 Coke ugh. why is fulltest defined as invoking make instead of just depending on the other targets?
13:59 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 #parrot
14:01 whiteknight Immix GC does look like a pretty interesting algorithm. I don't think I've ever read this paper before
14:02 whiteknight It always bugs me when these researcher people are doing their work on the JVM
14:04 rurban_ joined #parrot
14:06 whiteknight hmm...the printer here is taking it's sweet time on this Immix paper
14:07 rurban left #parrot
14:07 rurban_ is now known as rurban
14:11 plobsing left #parrot
14:16 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 #parrot
14:48 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.
14:48 whiteknight it wouldn't surprise me in the least if keys were creating problems with respect to the Gc
14:50 whiteknight actually, looking at that file, it looks like the first test always passes no matter what. Bad test
14:59 mtk joined #parrot
15:09 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 #parrot
15:11 dalek parrot: 5cb57d1 | Whiteknight++ | t/src/embed/api.t:
15:11 dalek parrot: remove a small debugging thing where I was writing test temporaries to a local file instead of a temp file
15:11 dalek parrot: review: https://github.com/parrot/parrot/commit/5cb57d1174
15:14 mtk joined #parrot
15:17 benabik joined #parrot
15:18 benabik Morning, #parrot!
15:22 minusnine_ joined #parrot
15:32 whiteknight good morning, benabik
15:32 whiteknight how are you doing todaY?
15:33 benabik Sleepy.  Spent too much time last night implementing a simple worker thread pool for a school project.  :-D
15:33 whiteknight ouch
15:33 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 #parrot
15:34 benabik Wish I could say I was using parrot, but C++ and boost help when I'm trying to get speed.
15:35 whiteknight no, Parrot doesn't scale well to multiple CPU cores yet
15:35 whiteknight our threading model is....not good
15:35 sorear How big are these numbers?
15:35 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.)
15:39 dalek winxed: r804 | NotFound++ | trunk/winxedst (2 files):
15:39 dalek winxed: new predefined function typeof
15:39 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=804
15:40 cotto_work ~~
15:45 plobsing left #parrot
15:48 ambs joined #parrot
15:55 contingencyplan joined #parrot
15:56 minusnine_ left #parrot
15:59 bluescreen left #parrot
16:01 theory joined #parrot
16:05 cotto_work bacek: why is 6ac827ee (Don't check unaligned 'pointers') needed?
16:11 plobsing joined #parrot
16:11 Andy joined #parrot
16:15 whiteknight yes, I was wondering about that myself
16:15 whiteknight I suspect it may have to do with stack scanning
16:16 Psyche^ joined #parrot
16:17 Patterner left #parrot
16:17 Psyche^ is now known as Patterner
16:38 whiteknight NotFound: ping
16:39 whiteknight q
16:40 NotFound whiteknight: pong
16:41 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.
16:41 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
16:43 whiteknight Parrot_pcc_get_handlers is returning PMCNULL
16:44 NotFound whiteknight: do you know were the exception comes from?
16:45 whiteknight inside IMCC somewhere
16:45 NotFound whiteknight: is easy to reproduce?
16:47 nopaste "Whiteknight" at 192.168.1.3 pasted "Program to reproduce for NotFound++" (3 lines) at http://nopaste.snit.ch/31229
16:47 cotto_work dukeleto: ping
16:47 whiteknight that's in the imcc_compreg_pmc branch, so things are a little different there from master
16:47 NotFound Is that branch in origin?
16:48 whiteknight yessir
16:48 whiteknight The first exception being thrown is "No handler to delete" from Parrot_ext_try, line 356
16:51 whiteknight okay, I think I figured out part of the problem. It's a different context.
16:51 whiteknight the context where we set the handler is calling a new context
16:52 NotFound What does :postcomp do? I never used that.
16:53 whiteknight it's the same as :immediate, I think
16:53 whiteknight it either is, or probably should be, deprecated
16:54 whiteknight okay, that is the problem. IMCC calls into a new CallContext because it needs to run ops for the optimizer
16:54 whiteknight 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
16:55 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
16:55 whiteknight Parrot_cx_delete_handler_local only looks in the current context
16:57 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
16:57 whiteknight the problem is trying to delete the handler as a local handler, when it's from a caller context
16:57 NotFound But not with the context one may expect.
16:58 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.
17:00 NotFound But maybe doing the same as finalize is a better way, more consistent with pir handlers....
17:00 dalek parrot/whiteknight/imcc_compreg_pmc: 780beef | Whiteknight++ | compilers/imcc/ (3 files):
17:00 dalek parrot/whiteknight/imcc_compreg_pmc: Don't show the 'included from file' message in debug output if we aren't compiling from a file. Add some TODO notes
17:00 dalek parrot/whiteknight/imcc_compreg_pmc: review: https://github.com/parrot/parrot/commit/780beef9d0
17:00 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?
17:01 NotFound whiteknight: I think so, let me take some look at it.
17:01 whiteknight okay
17:01 whiteknight there are a few ways I think we can fix this. We just need to pick a good one
17:03 whiteknight if we add another "cleanup first" function pointer to Parrot_ext_try, I can manually pop my own context
17:04 cotto_work left #parrot
17:04 whiteknight though that's probably not the most flexible way to do it
17:04 whiteknight 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 #parrot
17:05 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.
17:05 whiteknight ok
17:05 cotto_work left #parrot
17:06 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 #parrot
17:07 cotto_work left #parrot
17:07 arnsholt NotFound: Winxed is independent of NQP for parsing and such, isn't it?
17:07 cotto_work joined #parrot
17:07 NotFound arnsholt: yes, it has a hand written parser.
17:08 cotto_work left #parrot
17:08 cotto_work joined #parrot
17:09 cotto_work left #parrot
17:09 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 arnsholt So I'm starting to consider replacing at least parts of it
17:10 cotto_work joined #parrot
17:10 whiteknight arnsholt: what syntax is giving you headaches?
17:10 arnsholt Operators as terms, essentially
17:10 NotFound arnsholt: I just discovered that, as I expected, it was easier for me to write my own parser than fight with nqp ;)
17:10 arnsholt Stuff like X = (=)
17:11 arnsholt Which should unify X with the atom '='
17:11 whiteknight oh yes, I can imagine that being touble
17:11 plobsing arnsholt: Ωη + http://tinlizzie.org/ometa​/ometa-js-old/prolog.html
17:12 arnsholt Yeah, that was another thought I've been considering
17:12 arnsholt Since O-Meta is PEG-based and Prolog is essentially all operator precedence grammar it should be a good fit
17:14 dalek parrot/m0-spec: dddb51c | cotto++ | docs/pdds/draft/pdd32_m0.pod:
17:14 dalek parrot/m0-spec: add concurrency, expand FFI stub a bit
17:14 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/dddb51c551
17:16 jan left #parrot
17:17 cotto_work left #parrot
17:17 cotto_work joined #parrot
17:17 cotto_work left #parrot
17:18 arnsholt NotFound: I've found NQP to be pretty pleasant to work with though
17:18 arnsholt Although considering all my previous experience has been with C and flex/bison that might not be saying much =)
17:19 mj41 left #parrot
17:20 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:21 moritz and to be fair, NQP was never well documented
17:22 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.
17:22 arnsholt I found a page on TT the other day that explained the whole EXPR business pretty well though
17:23 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-)
17:23 arnsholt Exactly!
17:23 whiteknight yeah, all the cool kids are using bison now
17:23 whiteknight :)
17:23 moritz *cough*
17:24 NotFound Mistake, bison is from the '80, yacc is even older.
17:24 arnsholt Yeah. yacc is mid-70ies IIRC
17:25 lateau left #parrot
17:25 NotFound Nah, the cool kids must use Ωη these days.
17:25 whiteknight I can't even type that
17:25 NotFound No? You're not cool, then ;)
17:25 whiteknight oh no! This is like high-school all over again!
17:26 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.
17:26 whiteknight :) hello darbelo
17:26 darbelo hi
17:26 arnsholt Yeah, that's the hardest part. My philologer side cringes a bit every time I think about it =)
17:27 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 #parrot
17:27 darbelo Ampere had it easier, typographically speaking.
17:28 arnsholt He didn't get his own codepoint though =)
17:28 * pmichaud wants a camelia codepoint :-)
17:29 arnsholt moritz++ just discovered that Ω is in fact U+2126 OHM SIGN, not a capital omega
17:29 pmichaud maybe 蜨 is close enough
17:30 pmichaud or 蝶
17:31 dmalcolm joined #parrot
17:31 cotto_work left #parrot
17:31 cotto_work joined #parrot
17:32 cotto_work apparently now trying to connect to #perl6 kills xchat
17:34 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
17:35 whiteknight 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 #parrot
17:35 cotto_work left #parrot
17:35 cotto_work joined #parrot
17:35 cgaertner *appears*
17:35 cgaertner 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."
17:35 cgaertner *disappears*
17:35 cgaertner left #parrot
17:35 ambs left #parrot
17:36 ambs joined #parrot
17:36 whiteknight ....lolwat?
17:36 tadzik :D
17:37 * Coke is so glad so much energy is focused on that instead of the language itself.
17:38 arnsholt Coke: Not to worry. I'll probably end up porting my grammar to it =)
17:39 darbelo Unicode, like klingons, make anything better.
17:39 darbelo Better, and more prone to otherwise avoidable violence.
17:41 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:43 darbelo <∑/>
17:43 mj41 joined #parrot
17:44 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?
17:44 NotFound whiteknight: yes, before Parrot_cx_delete_handler_local
17:45 ambs left #parrot
17:45 Hackbinary good evening #parrot
17:45 whiteknight okay, I'm going to have to write a custom try/catch routine for IMCC, for now
17:45 whiteknight We can consolidate later when we figure out a better way to resolve it
17:46 ambs joined #parrot
17:46 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?
17:46 plobsing whiteknight: isn't a custom try/catch in IMCC one of the things you hated the most aabout the old way?
17:47 arnsholt Hackbinary: http://trac.parrot.org/parrot/wiki/NQP​-rx%20Operator%20Precedence%20Parsing
17:47 Hackbinary arnsholt, cheers
17:47 arnsholt No problem. See also http://trac.parrot.org/parrot/wiki/HLL%20Resources (which includes the EXPR stuff)
17:48 whiteknight plobsing: No, I wouldn't say I hate it "the most". It's not too wide-spread really
17:48 cotto_work left #parrot
17:48 cotto_work joined #parrot
17:48 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
17:48 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
17:48 whiteknight I will be using Parrot's exceptions system, just setting up my own custom C handler
17:49 whiteknight NotFound: The real solution is still to use something like finalize here
17:49 whiteknight or something else to consolidate contexts
17:50 whiteknight 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 #parrot
17:50 whiteknight IMCC is still central enough that we can't treat it like an extension yet
17:50 cotto_work2 left #parrot
17:50 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:51 whiteknight 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.
17:51 whiteknight okay, in that situation, yes.
17:51 whiteknight I could cache a copy of the first context in Parrot_ext_try, and pop back to it
17:52 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.
17:52 whiteknight ok
17:53 whiteknight 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 whiteknight it would be nice to have a single error-handling mechanism in IMCC for once
17:54 NotFound I guess it may be better to first locate why the context isn't restored by imcc.
17:55 whiteknight that is actually a very good question
17:55 whiteknight I will have to look through and see where I am setting that
17:55 whiteknight er, where IMCC is doing that
17:55 Coke cotto_work: you mean »ö« ?
17:56 plobsing haven't they had that since forever?
17:56 cotto_work Coke: yes
17:57 cotto_work I'd be surprised if that were the problem, but I can connect to other channels just fine.
17:57 ambs left #parrot
17:57 ambs_ joined #parrot
17:57 arnsholt If xchat barfs on the mini-camlia, I suspect it's an encoding issue
17:58 Topic for #parrot is now »ö«  Parrot 3.0.0 Released | http://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?
17:58 NotFound whiteknight: or maybe a simple way is to always finish imcc via exception, throwing a control return or something like that on success.
17:59 cotto_work I'll another instance of xchat, but that's a good idea.
17:59 cotto_work2 joined #parrot
17:59 cotto_work2 seems to work
17:59 sjn »ö«
17:59 Coke so, I'll call off the hounds.
17:59 cotto_work2 left #parrot
17:59 benabik »ö« ?
18:00 tadzik it's Camelia, the Perl 6 butterfly
18:00 sjn in utf8 \o/
18:00 Coke unicode-art butterfly.
18:00 Topic for #parrot is now Parrot 3.0.0 Released | http://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:01 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
18:01 sjn then all is fine! \o/ :)
18:02 NotFound Perl6 Unicode Rorschach tests X-)
18:02 sjn heheh
18:03 benabik Perhaps we should register that at unicodeart.com.  :D
18:03 benabik Anyway, back to $work
18:04 Topic for #parrot is now Parrot 3.0.0 Released | http://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 ambs_ left #parrot
18:05 cotto_work wacky
18:06 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.
18:06 Topic for #parrot is now Parrot 3.0.0 Released | http://parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: Fix ipv6-related failures
18:06 whiteknight imcc_interface branch is old-hat
18:07 darbelo whiteknight: That sounds kind of achievable.
18:07 darbelo The parrot-powered IRC client, I mean
18:07 whiteknight yeah
18:08 whiteknight 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 whiteknight plus, that wouldn't help xchat not barf on channel topics
18:08 whiteknight I would use an IRC-on-Parrot client if it existed
18:08 darbelo I was thinking of something irssi-ish, but simpler.
18:09 whiteknight yeah, that would be awesome
18:09 Tene iirc x-chat can have different encoding settings per-network
18:09 whiteknight if it's separated out into a library + frontend, we could easily add in a proper GUI later
18:09 Tene If it's fine with that in the topic here but not there, you may want to check that
18:10 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..
18:11 Tene 'k
18:11 Coke we had, at one point, an irc bot written in partcl.
18:11 Coke sadly, it was killed by parrot.
18:11 whiteknight parrot the destroyer
18:13 whiteknight I bet it would be pretty easy to put together the basics of an IRC client in NQP
18:13 whiteknight I don't have a good reference for the protocol though
18:13 Hackbinary almost a silly question, is the PIRC work still going on?
18:14 whiteknight Hackbinary: no, but not because we don't want it to
18:14 whiteknight no active developers
18:14 Hackbinary okay, I'm going to add the pirc to the glossary then
18:14 Hackbinary :D
18:14 benabik whiteknight: http://www.irchelp.org/irchelp/rfc/index.html
18:15 Hackbinary pirc is the next generation of the compiler, yes?
18:16 lucian joined #parrot
18:16 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.
18:17 Coke but it was never really integrated with the parrot, so it was never really tested.
18:17 Coke s/the//
18:18 jsut joined #parrot
18:18 Coke It was not /un/wanted.
18:20 mikehh still getting intermittent failures with t/pmc/threads.t - see smolder reports # 8788 vs #8789
18:21 whiteknight eventually we are going to need to simply nuke that test from orbit
18:22 mikehh got a failure in the smoke test #8788 , reran #8789 - no failure
18:22 dalek parrot: 8bf9b75 | NotFound++ | src/extend.c:
18:22 dalek parrot: restore initial context in Parrot_ext_try
18:22 dalek parrot: review: https://github.com/parrot/parrot/commit/8bf9b75c82
18:22 dukeleto ~^~
18:23 cotto_work dukeleto: have you played with fugitive?
18:23 jsut_ left #parrot
18:23 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?
18:24 cotto_work dukeleto: https://github.com/tpope/vim-fugitive/
18:24 cotto_work supposed to be awesome for git-vim integration
18:27 mikehh cotto_work: looks good, have you tried it?
18:28 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.
18:29 cotto_work dukeleto: I'll look forward to hearing your thoughts. http://mshared.tumblr.com/post/3215710879/brows​ing-commits-in-vim-with-an-unimpaired-fugitive was the article that pointed it out, though I saw it previously on hacker news.
18:36 M_o_C joined #parrot
18:37 davidfetter joined #parrot
18:39 M_o_C left #parrot
18:39 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:40 mikehh with the caveat I am still getting intermittent failures with t/pmc/threads.t (not that often but still getting them)
18:42 dukeleto cotto_work: looking at your m0 spec stuff now
18:42 dukeleto cotto_work: shall i branch off of your branch? Or shall I commit directly to it and we can hash stuff out?
18:43 cotto_work dukeleto: commit directly and we can hash it out
18:47 mtk left #parrot
18:48 mtk joined #parrot
18:54 cotto_work dukeleto: what are you thinking?
18:58 atrodo cotto_work> Any value in me filling out a copy of the m0 spec with what I've done in my prototype?
19:00 dalek parrot/m0-spec: 42ed456 | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
19:00 dalek parrot/m0-spec: Start the list of M0 ops and add a not about CPS
19:00 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/42ed456ff3
19:00 dukeleto atrodo: what do you mean?
19:01 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
19:01 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.
19:03 dukeleto cotto_work: anything in my recent commit that worries you?
19:04 dukeleto atrodo: how do you allocate or free memory in your lorito prototype? I don't seem to see opcodes for that
19:05 cotto_work "context" isn't defined.
19:06 whiteknight .
19:07 dukeleto cotto_work: indeed
19:07 * dukeleto fixes that
19:07 whiteknight is now known as wknight8111
19:10 cotto_work atrodo: did I ever find out from you if the M0 concall time would work?
19:11 darbelo dukeleto: Out of curiosity, have you built/tested plumage lately?
19:11 dukeleto darbelo: i think i did about a month ago
19:11 dalek parrot/m0-spec: d4fd03c | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
19:11 dalek parrot/m0-spec: Attempt to define a Lorito context
19:11 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/d4fd03c925
19:11 dukeleto darbelo: are you noticing some problems?
19:12 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?
19:13 darbelo parrot/plumage.git
19:13 ttbot Parrot 71e0c767 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/8707
19:14 darbelo setup.pir is calling "$S0 = get_nqp()" which isn't defined anywhere.
19:14 wknight8111 is now known as whiteknight
19:15 darbelo then it assigns it to the prove_exec  key of the config hash.
19:15 darbelo I commented it out and it worked fine, tested fine too.
19:16 darbelo But it seems too trivial a mistake to have gone unnoticed.
19:18 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 atrodo cotto_work> We talked about time, nut not about day
19:19 dalek Heuristic branch merge: pushed 600 commits to parrot/lorito by leto
19:19 lucian_ joined #parrot
19:19 dukeleto atrodo: lack of gc?
19:19 dukeleto atrodo: M0 will need to know about the GC
19:20 atrodo dukeleto> Right, but my prototype hasn't done anything with GC
19:21 dukeleto darbelo: i just built and tested plumage successfully
19:21 cotto_work atrodo: ok.  That's what I thought.
19:21 darbelo dukeleto: From a clean checkout?
19:21 dukeleto darbelo: i did a "parrot setup.pir clean"
19:22 dukeleto darbelo: updated plumage.git, then did "parrot setup.pir test" and all tests passed
19:22 dukeleto cotto_work: we need to know what lives inside a Lorito Context PMC
19:22 lucian left #parrot
19:23 darbelo dukeleto:  can you ack for ''get_nqp" in your checkout.
19:23 darbelo ?
19:23 dukeleto darbelo: i only see it in setup.pir. It might be a function that distutils.pbc provides
19:24 dukeleto darbelo: what version of parrot are you using?
19:24 lucian joined #parrot
19:25 darbelo The wrong one, apparently. I'll look into that.
19:25 jsut_ joined #parrot
19:25 whiteknight get_nqp is defined in distutils, I think
19:26 cotto_work dukeleto: indeed we do
19:27 lucian_ left #parrot
19:29 whiteknight .
19:30 jsut left #parrot
19:30 cotto_work ...
19:30 whiteknight (sorry, I'm checking out the IRC messages in my packet sniffer to see what they look like)
19:31 benabik It's called get_nqp_rz now, I think. 0617415: "[distutils] avoid NQP confusion"
19:31 benabik s/rz/rx
19:31 whiteknight this all looks extremely easy to implement
19:31 cotto_work ok
19:31 atrodo whiteknight> IRC is not a complicated protocol.  Most of the complexities are in the conveniences clients add
19:32 whiteknight atrodo: my new client will have no conveniences
19:32 lucian left #parrot
19:33 atrodo whiteknight> I'm excited to see it
19:33 whiteknight it may never happen
19:34 atrodo I hope it does
19:35 whiteknight what I don't know how to do really is the polling IO
19:35 whiteknight we don't really have an event-based functionality in Parrot to use
19:36 whiteknight we really need a Poll PMC
19:36 Tene what?  async IO?  who uses that?
19:36 Tene They can just use threads instead... oh wait...
19:36 whiteknight Tene: :)
19:36 atrodo Tene++
19:36 whiteknight Tene: you interested in working on a Poll PMC?
19:37 whiteknight some kind of eventloop PMC would be nice
19:37 arnsholt Implementing this eval business is kinda hard. Who'da thunk it =)
19:38 Tene whiteknight: a Select PMC has been on my task list for... three years?
19:38 Tene So, yes, theoretically.
19:39 whiteknight Tene: Async IO is still on my tasklist, but there are other priorities that I am working on first
19:39 whiteknight and my list of priorities keeps growing
19:40 lucian joined #parrot
19:40 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?
19:40 Tene it even got patches by two newly-contributing people that were mostly ignored
19:41 whiteknight Tene: yeah, the threads situation has been terrible for as long as I remember
19:41 whiteknight I don't remember seeing any patches, but I wasn't focusing on that system for much of my time
19:42 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.
19:42 whiteknight cotto_work: people would rather have something that doesn't work than have nothing at all
19:43 benabik people--
19:43 whiteknight Tene: There were more problems than just interpreter cloning, I think
19:43 tadzik left #parrot
19:43 whiteknight we didn't have any way to share data. STM wasn't working
19:43 tadzik joined #parrot
19:43 tadzik :)
19:44 whiteknight we don't have working locks
19:44 benabik tadzik: lawl
19:44 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.
19:44 Tene iirc
19:44 PerlJam whiteknight: so ... where is this list of priorities kept?  :)
19:45 cotto_work in a heavily guarded vault far underground beneath PaFo HQ
19:45 whiteknight PerlJam: tatooed on the bottom of my foot
19:46 PerlJam Opacity is not an asset in this instance unless it's set to 0  :)
19:47 arnsholt Does Sub.set_outer set the outer dynamic or lexical context?
19:48 whiteknight lexical
19:48 lucian left #parrot
19:49 whiteknight Tene: that sounds like a pretty big limitation
19:50 whiteknight 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?
19:50 arnsholt Or interp, perhaps
19:50 whiteknight ansholt: I don't know if there is a "right" way, but that does look like as good a method as any
19:51 arnsholt Right. Then I've done something else wrong
19:52 * arnsholt keeps on digging
19:53 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 Tene I failed at understanding what was going on in the interpreter cloning guts.
19:53 Tene Maybe I should try again someday.
19:54 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
19:55 whiteknight 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 whiteknight if it's not :immediate and you return the sub out of IMCC to invoke it, your method should probably work
19:55 arnsholt Oooh. That's probably it
19:56 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.
19:56 whiteknight Tene: threads for the general case may have worked fine, but I do know there were some significant design problems relating to callbacks
19:57 arnsholt 'blocktype' => 'declaration' was simpler =)
19:57 arnsholt Thanks! whiteknight++
19:57 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
19:57 whiteknight it would certainly be better than nothing
19:58 whiteknight 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:59 Tene Sure.
19:59 Tene and that's a very simple PMC
19:59 whiteknight is it? I haven't thought about it in a while
19:59 Tene Yeah, it is.
19:59 Tene afk lunch
20:02 whiteknight okay
20:04 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:06 PerlJam (I assume that true async IO is blocking on bigger issues though)
20:07 PerlJam (like no threads :)
20:09 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 whiteknight 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
20:10 whiteknight but what we should be doing now, pre-Lorito, is anybody's guess
20:10 PerlJam Bummer
20:10 whiteknight yeah, tell me about it
20:13 lucian joined #parrot
20:13 dalek parrot/generational_gc: a1b7b24 | mikehh++ | src/gc/gc_gms.c:
20:13 dalek parrot/generational_gc: fix codetest failures
20:13 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/a1b7b24146
20:14 allison whiteknight/PerlJam: async io is something that should work even wihout full heavyweight threads
20:15 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
20:16 allison PerlJam: just a sec, poking to see how bare the current PDDs are
20:17 lucian_ joined #parrot
20:18 allison PerlJam: so, PDD 22 is a pretty good overview
20:18 allison PerlJam: the general idea that async io is the same as sync io, but with callbacks will hold true
20:19 allison PerlJam: it's at least a good seed to start with
20:19 PerlJam thanks.
20:20 * 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 #parrot
20:22 whiteknight allison: thanks for the input!
20:22 PerlJam indeed.  allison++
20:23 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?
20:24 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:25 allison whiteknight: keeps me pretty busy, though. I'm happy to see Parrot accelerating with the new teams
20:26 allison whiteknight: it will certainly require scheduling of some sort, but not necessarily the "one true" central scheduler
20:27 allison whiteknight: looking at other implementations will provide a good source of ideas on possible avenues to choose from
20:28 allison whiteknight: (it'll also probably provide sources of horror and amusement :D)
20:32 cotto_work We have plenty of those already.
20:35 allison cotto_work: yah, the world is full of them
20:36 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 whiteknight in the near term, it's hard to figure out what we want to be doing in this area
20:36 whiteknight I do hate to put all our eggs into the Lorito basket
20:36 cotto_work which proposal?
20:36 lucian_ left #parrot
20:37 jan joined #parrot
20:37 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 http://tt.taptinder.org/cmdinfo/8755
20:37 atrodo whiteknight> I love putting all my eggs in one basket, that way I know where they all are
20:38 cotto_work allison: ok.  I'll have to remind myself to look at it when I get home.
20:38 bacek ~~
20:39 bacek Good morning humans.
20:39 cotto_work msg cotto Take a look at allison's phd proposal when you get home.
20:39 aloha OK. I'll deliver the message.
20:39 cotto_work hi bacek
20:40 nopaste "bacek" at 192.168.1.3 pasted "gen_gc vs gen_gc performance :)" (23 lines) at http://nopaste.snit.ch/31241
20:40 bacek aloha, cotto_work
20:41 tadzik shit, bacek, what happened? :)
20:42 bacek tadzik, shit happened :) More than 2 generations.
20:42 tadzik so it's not a workaround anymore?
20:42 bacek nope
20:42 bacek I fixed algo
20:42 tadzik supersweet
20:43 tadzik now it seems as if the gc was the mother of all the performance evilness
20:44 * cotto_work sets MAX_GENERATIONS to 8 and waits for the fireworks
20:44 dalek parrot/generational_gc: a7373f4 | bacek++ | src/gc/gc_gms.c:
20:44 dalek parrot/generational_gc: Attach strings and dirty children to youngest generation calculation.
20:44 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/a7373f414a
20:44 dalek parrot/generational_gc: 5ef6322 | bacek++ | include/parrot/gc_api.h:
20:44 dalek parrot/generational_gc: Don't shortcut mark_STRING_alive function. We are using real function in GMS to calculate youngest child.
20:44 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/5ef6322a61
20:44 fperrad left #parrot
20:44 dalek parrot/generational_gc: 547b58c | bacek++ | src/ops/ (2 files):
20:44 dalek parrot/generational_gc: Preserve GC flags from original GC in 'op copy'
20:44 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/547b58c9da
20:44 dalek parrot/generational_gc: 7cd7f05 | bacek++ | src/gc/api.c:
20:44 dalek parrot/generational_gc: Don't call mark_pmc_header for NULLs from GC API wrapper.
20:44 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/7cd7f05f5a
20:44 dalek parrot/generational_gc: 5ba2e0c | bacek++ | src/gc/gc_gms.c:
20:44 dalek parrot/generational_gc: Fix algorithm of handling dirty objects.
20:45 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/5ba2e0c519
20:45 dalek parrot/generational_gc: 053b464 | bacek++ | src/gc/gc_gms.c:
20:45 dalek parrot/generational_gc: Bump number of generations to 8.
20:45 dalek parrot/generational_gc:
20:45 dalek parrot/generational_gc: We are totally like Smalltalk VM from 80s now...
20:45 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/053b464ac4
20:45 bacek cotto_work, I did it already :)
20:45 tadzik :O
20:45 tadzik bacek++
20:45 dukeleto Oh, the dirty children...
20:45 cotto_work bacek: I see
20:45 bacek dukeleto, with strings attached
20:45 * tadzik pulls furiously
20:46 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..."".
20:47 whiteknight ha! I like the line about attaching dirty children
20:47 bacek msg moritz can you rerun spectest on bleeding edge gen_gc?
20:47 aloha OK. I'll deliver the message.
20:47 bacek whiteknight, :)
20:47 moritz bacek: sure, will do
20:51 cotto_work bacek: what's that smalltalk comment about?
20:52 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
20:52 whiteknight that's no small feat. They had a lot of good, full-time programmers working on that system
20:52 bacek cotto_work, original Smalltalk VM has GenGC. With 8 generations.
20:52 dukeleto Or, in other words, we have now caught up to only being 30 years behind the quality of the Smalltalk GC.
20:53 bacek moritz, thanks!
20:53 cotto_work booyah
20:53 whiteknight but 10 years ahead of the current Parrot GC
20:53 dukeleto indeed.
20:53 dukeleto these are exciting times.
20:54 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
20:54 whiteknight lucian pointed me to a paper this morning about a GC called immix that looks pretty impressive
20:56 moritz aren't modern GCs concurrent?
20:56 mikehh bacek: t/op/gc-leaky-box.t is failing
20:56 cotto_work For now, I'm happy to technology from the '80s.  If they call and want their gc back, tough.
20:56 bacek mikehh, non-optimized build?
20:57 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
20:57 mikehh both
20:57 whiteknight moritz: on a single-core system, a concurrent collector is no good
20:58 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
20:58 moritz bacek: parrot build on gen_gc fails
20:58 moritz with --optimize
20:58 moritz $ ./parrot-nqp --target=pir --output=compilers/opsc/gen/Ops/Compiler.pir  compilers/opsc/src/Ops/Compiler.pm
20:58 moritz make: *** [compilers/opsc/gen/Ops/Compiler.pir] Error 1
20:59 tadzik strange, works for me
20:59 tadzik running spectests now
20:59 * moritz git clean -xdf's
20:59 cotto_work pessmized build seems ok so far
20:59 moritz tadzik: the first rebuild worked, but rakudo's spectest failed
20:59 tadzik hmm
20:59 moritz so I cleaned, and rebuilt parrot
20:59 moritz this time it failed
20:59 cotto_work (It add an O(2^n) algorithm, just because.)
21:00 cotto_work ;)
21:00 bacek moritz, hmmm... It's bad...
21:00 moritz second rebuild worked again
21:00 * moritz tries rakudo again
21:01 tadzik non-deterministic!
21:01 benabik Huh.  Just had a failure in t/dynpmc/os.t (OS.lstat)...  But running the test again worked.
21:01 tadzik maybe there should be a generational algorithm growing new generations of GC algorithms :)
21:02 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 http://tt.taptinder.org/cmdinfo/8823
21:02 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.
21:02 moritz WIAT
21:02 whiteknight generation 1: segfault. generation 2: segfault. generation 3: segfault
21:02 moritz i'm on the wrong rakudo branch
21:02 tadzik :D
21:02 moritz still doesn't explain the parrot build failures
21:03 bacek moritz, can you build parrot without optimize? (Only parrot, not rakudo)
21:03 lucian joined #parrot
21:07 whiteknight it looks like there is an implementation of immix for GHC, implemented as a GSOC project in '09
21:08 whiteknight so, it becomes feasible for us if we want to look into that kind of system
21:08 lucian_ joined #parrot
21:08 dukeleto msg kid51 this is relevant to your recent blog post http://www.meetup.com/pdxpython/events/16518482/
21:08 aloha OK. I'll deliver the message.
21:11 lucian immix isn't that hard to implement
21:11 lucian harder than gen semispace, though
21:11 * lucian has just read the paper and related
21:12 dalek parrot/generational_gc: c5393c7 | luben++ | src/gc/gc_gms.c:
21:12 dalek parrot/generational_gc: fix couple of compiler warnings
21:12 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/c5393c79f3
21:12 dalek parrot/generational_gc: a36c56c | luben++ | / (5 files):
21:12 dalek parrot/generational_gc: Merge branch 'generational_gc' of github.com:parrot/parrot into generational_gc
21:12 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/a36c56c9f6
21:13 whiteknight lucian: I'm going to be reading the paper tonight or tomorrow morning
21:13 whiteknight We definitely need to focus on getting bacek's new collector merged and tuned before we start talking about anything else
21:14 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
21:14 lucian sure. and my c-fu is low anyway
21:14 lucian copying, yes. is that so problematic?
21:15 whiteknight I think so, yes. We don't really have any way to update pointers to a PMC if the PMC moves
21:15 whiteknight we could have pointers to it in registers, in other PMCs, on the stack, etc
21:17 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.
21:18 whiteknight *if*, yes
21:19 whiteknight if we reimplement the top 1/2 of Parrot in lorito, and never store PMCs on the stack, that does become feasible
21:19 whiteknight or, any PMC that was put onto the stack could be manually anchored
21:19 whiteknight but that would be a huge hassle because that happens throughout the codebase
21:19 lucian you could have a mechanism for unusually placed objects
21:20 lucian stack objects, objects that aren't allowed to move, huge objects, etc
21:20 lucian a mechanism beside the gc. i dont know if it makes sense in parrot
21:21 plobsing left #parrot
21:22 whiteknight lucian: something like a "pin" would work
21:22 whiteknight but you would have to manually pin any PMC that wasn't in an accepted "safe area"
21:22 tadzik damn, close's code is full of old-style PD
21:22 tadzik POD
21:23 Tene whiteknight: alternately, a method to mark a pmc as relocatable/compactable is feasible.
21:23 Tene everything is pinned by default, but you can un-pin individual PMCs.
21:23 whiteknight Tene: yeah, but how would you ever know that it was relocatable?
21:23 lucian sure, but a pin is needed anyway for some c apis
21:23 benabik left #parrot
21:24 whiteknight lucian: any C api with callbacks
21:24 whiteknight or any C api that takes a data pointer
21:25 lucian yep
21:25 lucian i think there were more cases, but the point is that it's needed
21:25 whiteknight I assume extensions in Lorito world are going to have the same problem, unless they are written themselves in Lorito
21:25 NotFound A data pointer might be kept constant even if the PMC that owns the pointer moves.
21:25 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.
21:26 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
21:26 Tene whiteknight: I can vaguely imagine that as the first part of a gradual parrot refactor that eventually enables large amounts of copying/compacting
21:27 Tene 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
21:27 moritz bacek: unoptimized parrot build succeeds
21:28 NotFound Now that you said that, maybe a context's registers alike structure will be a good support for PMC attributes.
21:29 * whiteknight has to pack up and go home. later
21:29 whiteknight left #parrot
21:38 tadzik bacek: one spectest failed
21:39 ttbot Parrot 5ef6322a MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/8896
21:39 darbelo left #parrot
21:39 dukeleto Tene: The plan for Lorito is that every operation asks the current context for the interp object. There is no global interp.
21:43 bacek_at_work ~~
21:43 bacek_at_work tadzik, which one? gc-non-recursive?
21:44 nopaste "luben" at 192.168.1.3 pasted "Gen_GC number of generations comparisson" (8 lines) at http://nopaste.snit.ch/31242
21:44 bacek_at_work moritz, hmm.. Looks like I missed some shortcuts.
21:44 tadzik bacek_at_work: rakudo spectest
21:45 bacek_at_work luben, yeah something like 3-4 generations is enough actually.
21:45 bacek_at_work tadzik, which one?
21:45 luben yes
21:45 tadzik t/spec/S05-mass/properties-derived.rakudo                    (Wstat: 0 Tests: 256 Failed: 3)
21:45 bacek_at_work tadzik, linux/i386?
21:46 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.
21:46 nopaste "tadzik" at 192.168.1.3 pasted "polar bears are left-handed" (100 lines) at http://nopaste.snit.ch/31243
21:51 bacek_at_work tadzik, reproduced on i386...
21:56 bacek_at_work (148 - 86) / 148 * 100
21:56 aloha 41.8918918918919
21:56 wknight-phone joined #parrot
22:04 rurban_ joined #parrot
22:07 rurban left #parrot
22:07 rurban_ is now known as rurban
22:08 ttbot Parrot a36c56c9 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/8906
22:11 lucian left #parrot
22:11 lucian_ is now known as lucian
22:14 plobsing joined #parrot
22:33 bacek_at_work lucian, same failure on parrot master. Something non-gc related changed.
22:34 bacek_at_work oops
22:34 lucian bacek_at_work: i'm not sure you meant me :)
22:34 bacek_at_work tadzik, same failure on parrot master. Something non-gc related changed.
22:35 tadzik I see
22:37 tadzik gc-related parrot tests pass
22:37 tadzik sockets fail, but that's known I think
22:37 dalek parrot: 2bf77f5 | NotFound++ | src/dynpmc/os.pmc:
22:37 dalek parrot: temptative fix for win build (don't have win available ATM)
22:37 dalek parrot: review: https://github.com/parrot/parrot/commit/2bf77f5814
22:42 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 http://nopaste.snit.ch/31246
22:42 tadzik bacek_at_work: ^ tests results
22:46 bacek_at_work tadzik, can you rerun pcre test with verbose?
22:48 tadzik I think so
22:49 nopaste "tadzik" at 192.168.1.3 pasted "I ran out of silly sayings" (28 lines) at http://nopaste.snit.ch/31248
22:53 dalek ohm-eta-wink-kzd: 9b39b96 | plobsing++ | bootstrap/ometa-base.winxed:
22:53 dalek ohm-eta-wink-kzd: drop hand-rolled typeof() in favour of new Winxed builtin
22:53 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/9b39b96bf6
22:53 dalek ohm-eta-wink-kzd: b09429c | plobsing++ | src/OMetaWinxed (2 files):
22:53 dalek ohm-eta-wink-kzd: rebootstrap
22:53 dalek ohm-eta-wink-kzd: review: https://github.com/plobsing/ohm​-eta-wink-kzd/commit/b09429c0f7
22:55 dukeleto Hackbinary: pull request?
22:56 dukeleto Hackbinary: refer to docs/project/git_workflow.pod if you have questions, and if that doesn't answer them, ask me :)
22:56 cosimo joined #parrot
23:03 plobsing left #parrot
23:06 cotto_work We love pull requests.
23:10 wknight-phone left #parrot
23:10 plobsing joined #parrot
23:13 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:17 wknight-phone joined #parrot
23:20 kid51 joined #parrot
23:21 plobsing left #parrot
23:25 wknight-phone left #parrot
23:49 whiteknight joined #parrot
23:55 tadzik bacek_at_work: auto::pcre -          Does your platform support pcre...............yes, 8.02.
23:57 tadzik but this is interesting: auto::llvm -          Is LLVM installed....................................no.
23:57 tadzik it's installed and running. Hm

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

Parrot | source cross referenced