Camelia, the Perl 6 bug

IRC log for #parrot, 2011-02-09

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:16 dalek parrot/generational_gc: b20e86a | bacek++ | src/gc/gc_gms.c:
00:16 dalek parrot/generational_gc: Use different stats to trigger GC
00:16 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/b20e86af16
00:16 dalek parrot/generational_gc: f7ed1db | bacek++ | t/op/gc-leaky- (2 files):
00:16 dalek parrot/generational_gc: Increase number of iterations in gc test
00:16 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/f7ed1db4ca
00:16 dalek parrot/generational_gc: e19f4cf | bacek++ | src/gc/api.c:
00:16 dalek parrot/generational_gc: Add GMS to gc_sys_name.
00:16 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/e19f4cf2c1
00:16 dalek parrot/generational_gc: 34ef135 | bacek++ | t/op/gc-leaky- (2 files):
00:16 dalek parrot/generational_gc: Check mem_since_last_alloc for GMS in GC test
00:16 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/34ef1359b7
00:18 whiteknight nwellnhof: yeah, several failures are expected
00:18 bacek_at_work make test passed on gen_gc branch now.
00:19 whiteknight bacek++
00:20 cotto_work bacek++
00:20 cotto_work How do you debug that so quickly?
00:21 whiteknight magic. coding. robot.
00:22 whiteknight say it with me
00:22 Hackbinary Magic. Coding. Robot.
00:24 * cotto_work decommutes
00:32 nwellnhof left #parrot
00:33 Tene I'd lean more towards "put a lot of hard work in over a long time", which is rather more admirable to me than "magic".
00:41 bacek_at_work Tene, about 1.5 years actually. gen_gc for last 6 month.
00:43 bacek_at_work jnthn, ping
00:45 whiteknight it looks like many of the remaining failures in imcc_compreg_pmc are because I'm not throwing exceptions properly on error
00:46 cotto Tene++
00:47 cotto and bacek++ for being a hard-working coding robot
00:51 vmspb left #parrot
01:01 benabik_ joined #parrot
01:01 benabik_ left #parrot
01:02 benabik_ joined #parrot
01:09 dalek parrot/generational_gc: a00a78b | bacek++ | src/string/api.c:
01:09 dalek parrot/generational_gc: Clean more flags in ugly hack in str_copy.
01:09 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/a00a78b27e
01:09 dukeleto ~~
01:09 bacek_at_work cotto, we do need some "very heavy GC test". Allocating a lot of PMC/STRINGs. In different generations.
01:11 davidfetter left #parrot
01:13 kid51 joined #parrot
01:14 whiteknight bacek: what does performance look like on that branch? improvement?
01:14 arnsholt left #parrot
01:14 arnsholt joined #parrot
01:15 GeJ left #parrot
01:16 GeJ joined #parrot
01:16 particle1 joined #parrot
01:16 allison left #parrot
01:16 Hunger left #parrot
01:16 wagle left #parrot
01:16 allison joined #parrot
01:16 wagle joined #parrot
01:17 particle left #parrot
01:17 [hudnix] left #parrot
01:17 [hudnix] joined #parrot
01:18 Hunger joined #parrot
01:18 dukeleto bacek_at_work: don't we have a gc stress test in examples/benchmarks ?
01:21 freeksh0w86 joined #parrot
01:23 dmalcolm_ left #parrot
01:31 whiteknight nwellnhof++ I would never have found that GC bug, because I was only looking at code I had changed
01:31 whiteknight now that I'm past that, I feel like I can really make some progress on this damn brnch
01:34 benabik_ left #parrot
01:40 dalek website: jkeenan++ | "Do It for Python!"
01:40 dalek website: http://www.parrot.org/content/do-it-python
01:55 freeksh0w86 left #parrot
02:01 sECuRE left #parrot
02:06 ryan joined #parrot
02:08 autark left #parrot
02:15 * whiteknight is apparently a total n00b
02:15 whiteknight I was passing a STRING* instead of a char* to Parrot_ex_throw_from_c_args
02:15 whiteknight and I was wondering why my error messages were all b0rkd
02:16 kid51 Didn't your mother warn you about that?
02:17 whiteknight my mother and her compiler
02:18 Tene my only fail on the generational_gc branch was t/pmc/socket_ipv6.t
02:18 Tene I think it's uploading a smoke report right now?
02:18 Tene yeah, uploaded.
02:18 Tene http://smolder.parrot.org/app​/projects/report_details/8352
02:18 rurban left #parrot
02:21 dalek parrot/whiteknight/imcc_compreg_pmc: c747815 | Whiteknight++ | / (5 files):
02:21 dalek parrot/whiteknight/imcc_compreg_pmc: be better about communicating success/failure from the guts of IMCC. throw a non-stupid exception on failure. This fixes some test failures, but not as many as I had hoped
02:21 dalek parrot/whiteknight/imcc_compreg_pmc: review: https://github.com/parrot/parrot/commit/c747815509
02:21 whiteknight it bugs me how much text IMCC dumps out to stderr
02:22 plobsing 2>/dev/null # problem solved!
02:22 plobsing right?
02:22 autark joined #parrot
02:22 whiteknight rm -rf compilers/imcc/*
02:23 whiteknight that command makes me so happy, I could marry it
02:23 Tene exec 2>/dev/null # all problems solved
02:23 plobsing rm -rf compilers/imcc; git checkout compilers
02:24 plobsing do it as many times as you like
02:25 whiteknight git rm compilers/imcc/*; git commit -a -m"HAHAHAHAA"; git push
02:25 whiteknight better than cocaine
02:25 whiteknight well, I assume so anyway
02:26 rurban joined #parrot
02:33 whiteknight left #parrot
02:34 kid51 whiteknight/imcc_interfaces PASS http://smolder.parrot.org/app​/projects/report_details/8351
02:34 nopaste "bacek" at 192.168.1.3 pasted "gen_gc vs master "ops2c --core" "benchmark"" (65 lines) at http://nopaste.snit.ch/30922
02:35 cotto That's exciting news.
02:35 cotto bacek++
02:35 cotto thanks for all the work you're putting into that branch
02:35 bacek_at_work We just have to fix our HLLs...
02:36 bacek_at_work I have initial patch for rakudo (at home)
02:36 kid51 bacek++
02:36 bacek_at_work But we'll need a lot of help from fperrad++ for Lua. I don't understand LuaFunction code at all.
02:36 plobsing bacek_at_work: did you cook up some scheme involving switching around vtables to avoid requiring modifications?
02:37 plobsing s/did/didn't/
02:37 bacek_at_work plobsing, I got rid of it
02:37 kid51 whiteknight/imcc_compreg_pmc branch:     FAIL http://smolder.parrot.org/app​/projects/report_details/8356
02:37 bacek_at_work I changed original VTABLE generation to put write barrier after call.
02:43 plobsing bacek_at_work: how come some vtables get barriered and others not? eg: init vs init_int
02:43 bacek_at_work plobsing, I put write_barrier in :write vtables only.
02:44 bacek_at_work but both init and init_int are marked with :write
02:44 plobsing init is not getting the barriering AFAICT
02:45 Drossel left #parrot
02:46 plobsing although arguably, neither should get barriered because we can assume they operate on objects that will be in the nursery.
02:47 Kulag joined #parrot
02:47 bacek_at_work plobsing, nope. It's barriered.
02:48 bacek_at_work commit 5b175bb2e2cea067aa4f784c409966ac4d9dd6b4
02:48 bacek_at_work Mark .init* functions with :write.
02:48 bacek_at_work
02:48 bacek_at_work During initilization of PMC we can trigger GC. In this case we have to
02:48 bacek_at_work put freshly allocated PMC into dirty_list to preserve old-to-young
02:48 bacek_at_work pointers.
02:48 plobsing generational_gc failures on x86_64 linux: t/op/gc-leaky-box.t[1,3] t/op/gc-leaky-call.t[3], t/op/gc.t[segfaulted]
02:48 bacek_at_work plobsing, I fixed it few commits ago...
02:49 bacek_at_work can you re-run them with verbose output?
02:51 plobsing rebuilding with latest changes. will re-run.
02:56 plobsing bacek_at_work: t/op/gc.t passes 123 tests before segfaulting (no plan, last test was "ok 123 - leaving write_barrier_1")
02:56 plobsing on latest
03:01 bacek_at_work plobsing, shit...
03:01 plobsing t/op/gc-leaky-{box,call}.t appear to be fine now
03:03 plobsing it is happening outside of gc, in Parrot_Hash_get_pointer(), for a PMC with a null ->data
03:04 bacek_at_work it's GC...
03:04 bacek_at_work Hash keys collected prematurely. Somehow.
03:06 plobsing it is an optimized build fwiw. I'll try unoptimized in a sec.
03:10 nopaste "bacek" at 192.168.1.3 pasted "test patch for plobsing++" (17 lines) at http://nopaste.snit.ch/30923
03:10 bacek_at_work plobsing, can you try optimized build with nopasted patch?
03:12 Kulag left #parrot
03:12 Kulag joined #parrot
03:12 plobsing bacek_at_work: unoptimized build passes
03:13 ryan left #parrot
03:19 plobsing bacek_at_work: with patch, still segfaults
03:19 bacek_at_work plobsing, it's bad...
03:22 plobsing if I give you some GC parameters (please advise which ones), do you think you'd be able to reproduce the error?
03:23 kid51 generational_gc linux/i386 no optimize: one file FAIL: http://smolder.parrot.org/app​/projects/report_details/8362
03:23 kid51 Sorry, 8362 was --optimize
03:25 bacek_at_work plobsing, yes. At least I can try.
03:25 bacek_at_work kid51, there is no failures in smolder...
03:27 kid51 Strange
03:28 bacek_at_work plobsing, I did reproduce it. We collect Hash prematurely.
03:28 bacek_at_work (gdb) up
03:28 bacek_at_work #1  0xb7e642e0 in Parrot_set_p_kc_p (cur_opcode=0x811bd58, interp=0x8052020) at src/ops/core_ops.c:21949
03:28 bacek_at_work 21949    VTABLE_set_pmc_keyed(interp, PREG(1), PCONST(2), PREG(3));
03:28 bacek_at_work (gdb) p _self->flags & b_PObj_on_free_list_FLAG
03:28 bacek_at_work $28 = 131072
03:29 kid51 bacek_at_work: I got this:  t/op/gc.t  (Wstat: 11 Tests: 123 Failed: 0)    Non-zero wait status: 11    Parse errors: No plan found in TAP output
03:29 plobsing kid51: that's the same error we're debugging
03:29 bacek_at_work kid51, same failure as plobsing.
03:29 plobsing and by we, I mean bacek++. I'm just the peanut gallery
03:30 bacek_at_work :)
03:30 kid51 t/op/gc.t ...................................
03:30 kid51 All 123 subtests passed
03:30 bacek_at_work plobsing, it's freshly allocated Hash PMC. At least it's from Gen0.
03:31 bacek_at_work but CallContext is from Gen1.
03:31 bacek_at_work ookey.
03:32 bacek_at_work CallContext is sealed. Which means I missed update of PMC register somehow.
03:32 bacek_at_work Gotcha!
03:32 plobsing wait. do we WB on every set register?
03:33 bacek_at_work In optimized builds REG_PMC/REG_NUM are accessing ctx directly.
03:33 kid51 meanwhile, without --optimize I get PASS on that branch: http://smolder.parrot.org/app​/projects/report_details/8365
03:33 bacek_at_work plobsing, on every access. But after triggering WB it's disabled.
03:33 benabik G'evening
03:37 nopaste "bacek" at 192.168.1.3 pasted "Another patch." (14 lines) at http://nopaste.snit.ch/30927
03:37 bacek_at_work plobsing, can you try it?
03:37 bacek_at_work (nopasted patch)
03:37 bacek_at_work old one can be wiped off
03:39 Drossel joined #parrot
03:41 Kulag left #parrot
03:43 bacek_at_work plobsing, yes. Looks like patching ops2c to emit WB is slightly better option.
03:43 bacek_at_work I'll commit current workaround and fix it properly later
03:44 bacek_at_work karma jkeenan
03:44 aloha jkeenan has karma of 289.
03:45 dalek parrot/generational_gc: 500ddf6 | bacek++ | src/gc/gc_gms.c:
03:45 dalek parrot/generational_gc: Rerun headerizer
03:45 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/500ddf6608
03:45 dalek parrot/generational_gc: 3917979 | bacek++ | src/gc/gc_gms.c:
03:45 dalek parrot/generational_gc: Put whole validate_objects into ifndef NDEBUG.
03:45 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/39179797b2
03:45 dalek parrot/generational_gc: f14c1a6 | bacek++ | include/parrot/context.h:
03:45 dalek parrot/generational_gc: Temporary workaround to enable write barriering of CallContexts. plobsing++ and jkeenan++ for testing.
03:45 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/f14c1a624f
03:45 bacek_at_work kid51, plobsing, can you retest optimized build with latest commit?
03:46 simcop2387_ joined #parrot
03:48 simcop2387 left #parrot
03:48 simcop2387_ is now known as simcop2387
03:48 Kulag joined #parrot
03:49 Drossel left #parrot
03:51 plobsing bacek_at_work: no more segfaults
03:51 simcop2387 left #parrot
03:51 plobsing running fulltest
03:51 bacek_at_work plobsing++ # Yay!
03:52 simcop2387 joined #parrot
03:53 * bacek_at_work wander why do we have t/op/jit.t?
03:55 plobsing they were tests originally created to test the jit, but are useful for testing any runcore
03:56 plobsing they are the most basic of tests. if one were creating a runcore from scratch, those would be the ones that should be focused on to get off the ground.
03:57 Kulag left #parrot
03:58 Kulag joined #parrot
04:02 kid51 left #parrot
04:02 rurban_ joined #parrot
04:04 plobsing bacek_at_work: failures in codetest: c_arg_assert, c_function_docs, c_cppcomments
04:05 rurban left #parrot
04:05 rurban_ is now known as rurban
04:07 Kulag left #parrot
04:08 mikehh plobsing: I fixed the first two in master, bacek uses c++ comments as markers for later removal
04:08 plobsing I know. those failures merely indicate that the tests got to there.
04:08 plobsing which is more or less pass
04:09 mikehh plobsing: they were fixed after bacek merged master into generational_gc
04:11 benabik Woo!  make test on gen_gc now only fails on checkdepend, which also fails in master.  (src/platform.c).  Now onto Rakudo.
04:12 plobsing bacek_at_work: any ideas to improve the "temporary workaround"?
04:14 mikehh generational_gc fails on g++ build: src/gc/gc_gms.c:1061:9: error: cannot convert ‘STRING*’ to ‘PMC*’ for argument ‘2’ to ‘void gc_gms_set_gen_flags(parrot_interp_t*, PMC*, int)’
04:15 benabik Still segfaults building Perl6::Grammar in Rakudo.  :'(
04:15 plobsing benabik: rakudo requires a patch for this. I beleive bacek has a patch.
04:15 benabik plobsing: OIC
04:17 mikehh I have no idea how to put casts into a macro :-{
04:18 benabik mikehh: Like you put everything else in a macros: Very carefully.
04:18 mikehh benabik: hee - I hate macros in C
04:19 plobsing mikehh: you like macros elsewhere? m4? lisp?
04:19 benabik mikehh: Some tools let you shoot yourself in the foot.  Some tools start aimed at the floor.  :-D
04:19 plobsing OHAI I IS IMG MACRO
04:20 mikehh benabik: one of the reasons I started using C++ (years ago) was to avoid macros
04:20 benabik mikehh: So you get to deal with templates instead...
04:30 Tene bacek_at_work: do you have a rakudo fork on github, perhaps, or could I commit patches to a branch in rakudo for you?
04:31 * mikehh seriously needs sleep - it's 4:30am for me
04:38 adu joined #parrot
04:45 bacek_at_work Tene, it will be helpful. But I have patch at home.
04:45 Tene bacek_at_work: Ah.
04:46 Tene You mean not everyone leaves their home workstation available over ssh constantly? ;)
04:47 dalek lorito: 4f737d2 | atrodo++ | internal_pmc/context.c:
04:47 dalek lorito: Remove debugging information
04:47 dalek lorito: review: https://github.com/atrodo/lorito/commit/4f737d2cc9
04:47 dalek lorito: ad6297f | atrodo++ | / (2 files):
04:47 dalek lorito: Convert the ptrs struct in a PMC to an array of pointers
04:47 dalek lorito: review: https://github.com/atrodo/lorito/commit/ad6297f512
04:47 dalek lorito: 0208700 | atrodo++ | / (5 files):
04:47 dalek lorito: Make the plunge so that names of the internal PMCs are Lorito_Str's
04:47 dalek lorito: review: https://github.com/atrodo/lorito/commit/0208700346
04:47 dalek lorito: 8c2a2d7 | atrodo++ | core.c:
04:47 dalek lorito: Correct a typo where the wrong variable was being used
04:47 dalek lorito: review: https://github.com/atrodo/lorito/commit/8c2a2d74aa
04:47 dalek lorito: 8f0e31f | atrodo++ | / (4 files):
04:47 dalek lorito: Add internal_pmc/file as the code base for the file PMCs
04:47 dalek lorito: review: https://github.com/atrodo/lorito/commit/8f0e31f0ba
04:47 dalek lorito: e6ff0a0 | atrodo++ | loader.c:
04:47 dalek lorito: Correct a few bugs in the searching to load bytecode
04:47 dalek lorito: review: https://github.com/atrodo/lorito/commit/e6ff0a0e0d
04:47 dalek lorito: 80ac662 | atrodo++ | loader.c:
04:47 bacek_at_work Tene, yeah :)
04:47 dalek lorito: Don't increment the fileid until after the file has been opened
04:47 dalek lorito: review: https://github.com/atrodo/lorito/commit/80ac662cec
04:47 dalek lorito: 7976f50 | atrodo++ | Makefile:
04:47 dalek lorito: Make the makefile a little more useful in showing errors
04:47 dalek lorito: review: https://github.com/atrodo/lorito/commit/7976f50110
05:30 mtk left #parrot
05:36 mtk joined #parrot
06:02 rurban_ joined #parrot
06:04 adu left #parrot
06:05 rurban left #parrot
06:05 rurban_ is now known as rurban
06:13 adu joined #parrot
06:17 dukeleto ~~
06:18 cotto hi dukeleto
06:31 woosley joined #parrot
06:33 * Tene rather pleased about generational gc branch
06:33 adu left #parrot
06:40 adu joined #parrot
07:21 * dukeleto hears that gen_gc is passing "make test" ?
07:22 Tene dukeleto: WFM
07:22 Tene dukeleto: you should submit a smoke report :)
07:26 dalek parrot/generational_gc: a38436e | bacek++ | / (4 files):
07:26 dalek parrot/generational_gc: Add GC flags combinations and use them instead of specifing individual
07:26 dalek parrot/generational_gc: flags.
07:26 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/a38436e580
07:26 dalek parrot/generational_gc: ad5a1f3 | bacek++ | / (2 files):
07:26 dalek parrot/generational_gc: Use macro instead of function to set generation flags
07:26 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/ad5a1f3148
07:26 dalek parrot/generational_gc: 8cdd27a | bacek++ | src/gc/gc_gms.c:
07:26 dalek parrot/generational_gc: Remove now unused function
07:26 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/8cdd27a4ee
07:28 cosimo left #parrot
07:29 theory left #parrot
07:33 dukeleto Tene: hah, I don't sent single reports. Only relentless waves of reports
07:34 * dukeleto switches to the gen_gc branch on his darwin smoker
07:35 dukeleto ok, i got a darwin smoker on the gen_gc branch
07:36 dukeleto what we really need are performance benchmarks for gen_gc
07:36 bacek_at_work msg mikehh c++ build should be fixed now
07:36 aloha OK. I'll deliver the message.
07:37 bacek_at_work dukeleto, http://nopaste.snit.ch/30922 this one os good enough for me :)
07:37 cotto We know it's awesome, but it's important to quantify how awesome it is.
07:39 bacek_at_work isparrotfastyet.com?
07:41 bacek_at_work Anyway gen_gc isn't tuned (yet). We can make it faster.
07:44 dukeleto bacek_at_work: exciting!
07:46 fperrad joined #parrot
08:15 cotto Is there a better place in the repo to do m0 planning than a pdd in docs/pdds/draft?
08:15 cotto dukeleto, ^
08:22 dalek parrot/m0-spec: 92f8218 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
08:22 dalek parrot/m0-spec: add initial pdd for m0, completely composed of stubs for now
08:22 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/92f82180d6
08:25 ttbot Parrot c34f278b i386-linux-thread-multi make error http://tt.taptinder.org/cmdinfo/6733
08:25 dukeleto cotto: i think that is a fine place
08:26 dukeleto cotto++ # giving the m0 spec a home
08:26 adu left #parrot
08:28 mj41 sorry, not sure what ttbot is reporting ... trying to start building generational_gc branch
08:28 dukeleto mj41: no worries. sometimes things go bump in the night
08:28 dukeleto mj41: good to see you around :)
08:47 adu joined #parrot
08:48 mj41 dukeleto: It's morning here. I just came to work :-)
09:18 nopaste "bacek" at 192.168.1.3 pasted "Initial patch for rakudo." (79 lines) at http://nopaste.snit.ch/30955
09:35 mj41 http://tt.taptinder.org/build​status/parrot/generational_gc ... starting/configuring other clients
09:36 bacek mj41++ # Hooray! tt is even more useful now!
09:46 lucian joined #parrot
10:23 nwellnhof joined #parrot
10:27 ttbot Parrot 117c0c1c i386-freebsd-64int make error http://tt.taptinder.org/cmdinfo/7110
10:28 dalek parrot/generational_gc: a02c83d | bacek++ | src/gc/gc_ (2 files):
10:28 dalek parrot/generational_gc: Split print_stats into 2 functions to make it available in optimizied builds
10:28 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/a02c83d110
10:28 dalek parrot/generational_gc: 6ef2023 | bacek++ | src/call/context.c:
10:28 dalek parrot/generational_gc: Add assert to CallContext PMC accessor. Object must be alive.
10:28 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/6ef20232e2
10:28 dalek parrot/generational_gc: d862ee4 | bacek++ | src/pmc/callcontext.pmc:
10:28 dalek parrot/generational_gc: Add assert to CallContext.push_pmc. Object must be alive.
10:28 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/d862ee4601
10:34 ttbot Parrot d862ee46 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/7146
10:37 lucian left #parrot
10:39 contingencyplan left #parrot
10:42 nwellnhof bacek: i get a segfault when building runtime/parrot/library/nqp-setting.pbc with a GC threshold of 128K
10:42 nwellnhof (generational_gc branch, of course)
10:43 bacek nwellnhof, sigh... It's probably good thing if I can replicate it on my box.
10:44 bacek (If it's not in PBC_unpack)
10:44 nwellnhof bacek: looks like it's related to TT #1990
10:45 bacek nwellnhof, indeed. It's crashed in do_sub_pragmas
10:46 nwellnhof i think we should block GC in Parrot_pf_execute_bytecode_program except for the final Parrot_pcc_invoke_sub_from_c_args
10:52 bacek nwellnhof, doesn't help...
10:52 bacek I'm trying it right now
10:53 bacek Problem is: critical stuff was already collected.
10:53 nwellnhof maybe this helps: https://github.com/parrot/parrot/commit/​73c0355d32f815cbcd3ca44c3baac3f0e4dc78ae
10:54 nwellnhof (my fix to whiteknight/imcc_compreg_pmc from yesterday)
10:54 bacek ookey
10:54 bacek let me try it
10:55 nwellnhof no, it doesn't help. i just tried.
10:58 bacek sigh
10:58 bacek no, it doesn't
11:09 nopaste "nwellnhof" at 192.168.1.3 pasted "GC block diff" (29 lines) at http://nopaste.snit.ch/30967
11:10 nwellnhof that patch does the trick for me. but we should really fix TT #1990.
11:13 bacek nwellnhof, we should switch to Packfile PMC to properly fix it...
11:14 nwellnhof yes, indeed
11:58 mikehh bacek: get one failure - t/pmc/key.t - Failed 10/13 subtests - Non-zero wait status: 11 - segfaults after ok 3
12:01 mikehh bacek: also painfully slow - make test TEST_JOBS=4 -> real    15m4.460s, user    27m17.194s, sys     0m34.082s
12:02 mikehh bacek: presume it is because of the debug stuff
12:04 dd070 joined #parrot
12:04 adu left #parrot
12:04 dd070 left #parrot
12:20 lucian joined #parrot
12:26 mikehh bacek: much better with --optimize - Result: PASS - real    4m58.117s, user    8m20.595s, sys     0m30.366s
12:28 mikehh bacek: thats on Ubuntu 10.10 i386 (g++-4.5 with --optimize) previous result no optimize
12:34 lucian left #parrot
12:35 bluescreen joined #parrot
12:43 Kulag joined #parrot
13:17 mtk left #parrot
13:23 mtk joined #parrot
13:47 benabik_ joined #parrot
13:56 whiteknight joined #parrot
13:56 whiteknight good morning, #parrot
14:03 benabik_ left #parrot
14:04 rurban_ joined #parrot
14:07 rurban left #parrot
14:07 rurban_ is now known as rurban
14:15 plobsing left #parrot
14:26 GodFather joined #parrot
14:31 bluescreen left #parrot
14:57 mikehh left #parrot
15:11 whiteknight msg NotFound can we change Parrot_ext_try so that the try function can return a value?
15:11 aloha OK. I'll deliver the message.
15:14 NotFound whiteknight: pong
15:14 NotFound whiteknight: What kind of value?
15:15 whiteknight NotFound: nevermind, I think I will pass a data struct with a ->result field
15:15 NotFound whiteknight: yes, the idea was thas this is the more flexible way.
15:16 whiteknight okay
15:17 Hackbinary good afternoon #parrot
15:18 Hackbinary is there a 'glossary' of parrot-ish terms  and acronyms?
15:19 NotFound Hackbinary: docs/glossary.pod
15:20 Hackbinary thanks
15:21 Coke someone on #perl6 asking if they/we have nonblocking IO yet.
15:23 nwellnhof no, we don't
15:25 NotFound We have poll in handles, but limited to one handle each time is not very useful.
15:25 Coke if we had it, we might have another user. Just a data point.
15:28 theory joined #parrot
15:29 PerlJam Coke: I think it's more like  "we might have another user that could leverage bunches of other users"
15:32 mikehh joined #parrot
15:40 theory left #parrot
15:43 mtk left #parrot
15:44 particle1 left #parrot
15:50 mtk joined #parrot
15:50 particle joined #parrot
15:54 plobsing joined #parrot
15:57 dukeleto ~~
16:00 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#8501) fulltest) at 3_0_0-509-gc6fa8b7 - Kubuntu 10.10 amd64 (g++-4.5 with --optimize)
16:16 cotto_work ~~
16:17 Patterner left #parrot
16:17 Psyche^ joined #parrot
16:17 Psyche^ is now known as Patterner
16:20 Coke PerlJam: that's implied for all our users.
16:20 Coke but yah.
16:21 woosley left #parrot
16:25 simcop2387_ joined #parrot
16:25 simcop2387 left #parrot
16:25 simcop2387_ is now known as simcop2387
16:27 dukeleto cotto_work: mornin'
16:27 * dukeleto submits some talks to LinuxFestNW
16:27 * Coke ponders submitting a talk to the local CF user's group to show them how much their regexes suck.
16:28 Coke doesn't think it would go over too well.
16:34 whiteknight I've had occasion to use CF at $dayjob. Can't say I disagree with your sentiment
16:34 whiteknight s/regexs/everything/
16:35 plobsing if ops2c generated different code to access 'in' GCable registers than for 'inout' and 'out' GCable registers we could WB only on the latter case, eliminating useless WB checks (which add to code size and amount of branching) on register reads.
16:35 plobsing (the above is in the context of gen_gc)
16:36 Andy joined #parrot
16:36 simcop2387_ joined #parrot
16:37 benabik Morning, all!
16:37 simcop2387 left #parrot
16:37 simcop2387_ is now known as simcop2387
16:39 Coke whiteknight: using CF9.0.1 and cfscript for as much as possible makes it much more palatable. as does using something like Framework/1
16:39 dukeleto benabik: howdy!
16:39 Coke but I still cringe whenever I have to deal with nested subcaptures.
16:46 plobsing ping whiteknight
16:46 mikehh rakudo (03380cd) - builds on parrot (3_0_0-509-gc6fa8b7) - make test, make spectest_smolder[(#8512), roast (b3ef08d)] PASS - Kubuntu 10.10 amd64 (g++-4.5 with --optimize)
16:46 mikehh 27,634 ok, 0 failed, 610 todo, 1,847 skipped and 0 unexpectedly succeeded
16:48 cotto_work dukeleto: when do LinuxFest NW talks need to be submitted by?
16:48 whiteknight plobsing: pong
16:49 cotto_work also, what are you talking about there?
16:50 plobsing whiteknight: how close is your IMCC work. there are changes I'd like to make to packfiles, but they'd involve changes to IMCC, and I'd like to avoid stepping on toes.
16:51 whiteknight plobsing: nwellnhof fixed my GC problems yesterday, and exposed some "real" test failures that I'm debugging right now. I have some pretty major changes coming in later today to the IMCC interface. I'm not going to be touching any code deeper than compilers/imcc/main.c
16:51 whiteknight Actually, I'm adding a new file compilers/imcc/api.c to implement a embedding API friendly interface to IMCC, and I'm rewriting frontend/parrot/main to use that instead
16:52 whiteknight plobsing: What work are you doing? What's your timeline? This IMCC branch is at least 2-3 weeks from merging.
16:52 cotto_work I'm curious about that too.
16:53 plobsing whiteknight: I'd like to get started on packfiles being fully managed by PMCs. this of course involves changes to how IMCC handles things.
16:54 plobsing I want to start on a base that already works, so starting from your branch in its current state is not an option. But, there are already changes on that branch that will almost certainly conflict with my changes should I work from master.
16:54 whiteknight plobsing: Okay, what changes does that require? In IMCC right now we generate a PackFile*, then at the last moment we're wrapping it up in an Eval/UnManagedStruct. Are you thinking about adding the PMC component earlier in the process?
16:55 plobsing whiteknight: IMCC will work with a PMC the whole time
16:55 dukeleto cotto_work: not for a while
16:55 whiteknight that's awesome news
16:55 cotto_work indeed
16:55 dmalcolm joined #parrot
16:55 dukeleto i just submitted a failing smoke report on generational_gc
16:55 plobsing even if it treats it as structy sometimes, it will always pass around a PMC handle and dereference from there.
16:56 dukeleto cotto_work: actually, they are due tonight. hurry!
16:56 whiteknight plobsing: how long do you expect this to take? If it's going to take the same 2-3 weeks, maybe we work together on this IMCC branch. Give me a day or two to work out some of the bigger instabilities
16:56 cotto_work dukeleto: heh
16:56 whiteknight otherwise, I'm happy to incorporate your work into my branch later
16:56 plobsing whiteknight: this isn't going to be a break-the-world type branch. I'm hoping to make a sprint sometime in the next week and get say all but 5 tests passing.
16:58 arnsholt Is there a recommended way to move from "Configure.pl fetches from SVN" to "Configure.pl fetches from git" for my HLL?
17:00 mikehh winxed (803) - builds on parrot (3_0_0-509-gc6fa8b7) - make test/test1/test2 PASS, some examples ok - Kubuntu 10.10 amd64 (g++-4.5 with --optimize)
17:00 whiteknight plobsing: I'm making a hard push on the IMCC branch now, and want to get most of the major kinks worked out. You pick where you want to start working from, and I'll accomodate
17:00 whiteknight plobsing: of course, if there's a conflict during a merge, I may ask for some help to correct it :)
17:01 plobsing my opinion is that we cannot afford to remain blocked on this much longer if we intend to meet our 3.3 targets.
17:01 whiteknight right
17:01 plobsing so I'll be branching master.
17:02 plobsing and begin work immediately
17:02 whiteknight okay. I'll keep close eye on your branch
17:06 lucian joined #parrot
17:16 jsut_ joined #parrot
17:19 plobsing :qa
17:19 plobsing ENOTVIM
17:20 cotto_work That explains why my files keep disappearing.
17:21 jsut left #parrot
17:22 plobsing actually I may have to shave yet another yack before I get to the packfiles. there is no acceptable builtin pointer type for what I want to do.
17:27 nwellnhof left #parrot
17:27 ryan joined #parrot
17:28 plobsing we have unmanagedstruct, managedstruct, and pointer. yet we still feel the need to implement custom pointer-ish pmcs from scratch like bigint, bignum, sockaddr, mappedbytearray, nci, nativepccmethod.
17:28 mj41_ joined #parrot
17:29 GodFather left #parrot
17:29 Coke perhaps make them children of *struct?
17:30 plobsing *struct are poorly designed. the custom types are a symptom.
17:31 plobsing the whole concept that the lowest level pointer objects carry around their representation for all to see (and dynamically calculate their own offsets) is wrong. we need to decouple the concept of "pointer" from the concept of "view"
17:31 mj41 left #parrot
17:31 mj41_ is now known as mj41
17:33 plobsing My view is that a pointer is a pointer. nothing more. above that you can have managed pointers which have length, as well as optional free, mark, and clone functionality. on top of that you can have skins.
17:36 dalek TT #2002 created by kEAxTtHPsoXdTfX5++: Business cards
17:36 dalek TT #2002: http://trac.parrot.org/parrot/ticket/2002
17:37 plobsing 911! spam police!
17:38 cotto_work I don't see any spam.
17:38 plobsing should we have a captcha for account creation?
17:40 cotto_work It's tempting to move to manual account creation or verification.
17:42 cotto_work dukeleto: what are you talking about at LinuxFest NW?
17:42 vmspb joined #parrot
17:43 Coke raising the bar on reporting bugs not necessarily a good thing.
17:43 cotto_work Coke: that's a significant concern.
17:43 Coke (though you can report bugs anonymously via email, which is nice.)
17:44 cotto_work if only trac didn't format such messages so uselessly
17:46 theory joined #parrot
17:46 Coke cotto_work: easy to fix, just wrap in {{{}}}
17:53 kid51 joined #parrot
17:53 whiteknight plobsing: fixing the pointer-related PMC fiasco would definitely be a good thing
17:53 whiteknight hardly high priority enough to end up on the roadmap however
17:53 whiteknight if somebody can put together a nice design for a replacement, that would be a great first step
17:55 nopaste "kid51" at 192.168.1.3 pasted "generational_gc: failures in t/pmc/key.t" (15 lines) at http://nopaste.snit.ch/31037
17:55 kid51 left #parrot
17:55 plobsing whiteknight: that's what I'm doig right now. then I'll reimplement all the pointerish stuff in terms of it.
17:55 whiteknight plobsing: I thought you were working on IMCC and packfiles?
17:56 benabik Was that a drive-by bug report?
17:56 plobsing whiteknight: like I said, it looks like I'll have to shave this yack first.
17:56 whiteknight ah, I missed that part
17:56 whiteknight okay
17:56 whiteknight power to you
17:56 plobsing none of the pointer types currently built in provide all of the functionality I want
17:56 plobsing and the last thing I want to do is compound the problem by creating yet another custom purpose struct-pointer PMC type.
17:57 whiteknight managedstruct, unmanagedstruct, pointer, and mappedbytearray can probably all be merged together without too much hassle
17:57 whiteknight I think there's benefit in keeping nci as a separate type, however
17:57 whiteknight maybe that's just me
17:59 plobsing whiteknight: it should also inherit properly to indicate that it is just another pointer
17:59 plobsing it can skin on top of that as much as it likes
17:59 whiteknight okay, I see what you are saying
17:59 whiteknight yes, I'm in favor of that
18:01 whiteknight I've been unhappy with managedstruct and unmanaged struct for a long time now. I would be very happy to see those two be overhauled
18:01 whiteknight pointer is completely useless. I think it's only used inside PCC
18:02 plobsing I actually see pointer as more like what I want, with a separate "pointer-view" type which can be used to skin pointers from managed code
18:03 plobsing but pointer has a bunch of flat out stupid functionality attached
18:03 cotto_work plobsing: how close is this to 6model?
18:03 plobsing Pointer.get_string == segfault me harder
18:04 plobsing cotto_work: quite possibly fairly close. they overlap in some areas. but 6model is much bigger than what I want.
18:04 plobsing and will probably take much longer to land
18:04 whiteknight plobsing: yes, pointer probably is a good base type, minus the crap. Like I said, it's mostly used in PCC so some of that crap is for that purpose
18:04 cotto_work sure.  I was just noticing that this sounds like a subset of that.
18:05 plobsing if I do things right, 6model could be implemented somewhat in terms of this
18:05 whiteknight do it right
18:05 whiteknight :)
18:06 plobsing whiteknight: I'm always right ;)
18:06 plobsing but sometimes the rest of the world is wrong ;(
18:11 whiteknight well that's reassuring. Now we know that this project is in the correct hands :)
18:14 contingencyplan joined #parrot
18:15 whiteknight ripping out crufty old code and replacing it with new and good things is very fun
18:21 dukeleto cotto_work: anything and everything
18:21 whiteknight urg, I updated some software on my Ubuntu VM, and now things are hella broken
18:23 plobsing left #parrot
18:28 cotto_work dukeleto: dairy farming and interstellar travel?
18:28 nwellnhof joined #parrot
18:29 dukeleto cotto_work: that too
18:29 dukeleto i have at least 5 talk ideas to submit
18:29 dukeleto I really hope they don't accept them all
18:30 dukeleto cotto_work: would you be interested in doing some kind of "Parrot for Beginners" talk together?
18:30 dukeleto cotto_work: i am not sure they allow that, but i don't like following rules anyway
18:30 whiteknight "Parrot 4 t3h n00bz"
18:31 dukeleto we can bring cluesticks with us and beat knowledge into peoples knuckles
18:31 cotto_work dukeleto: sure.  I asked because I'd like to give a talk, but not talk about the same thing as you.
18:32 cotto_work In the event that my oscon talk gets accepted, I want to get as much practice as I can.
18:32 dukeleto cotto_work: of course. I am going to submit a PL/Perl6 talk, definitely.
18:32 dalek parrot/whiteknight/imcc_compreg_pmc: e7ac3d3 | Whiteknight++ | / (2 files):
18:32 dalek parrot/whiteknight/imcc_compreg_pmc: remove a hack to support IMCC the old way
18:32 dalek parrot/whiteknight/imcc_compreg_pmc: review: https://github.com/parrot/parrot/commit/e7ac3d300d
18:32 dalek parrot/whiteknight/imcc_compreg_pmc: 83b1708 | Whiteknight++ | / (4 files):
18:32 dalek parrot/whiteknight/imcc_compreg_pmc: add in some API functions for IMCC so we can move some logic out of the front-end and into IMCC where it belongs. using the extending API is much more concise in these cases than using the embedding API, so we can cut down on a lot of bloated code.
18:32 dalek parrot/whiteknight/imcc_compreg_pmc: review: https://github.com/parrot/parrot/commit/83b1708910
18:32 dalek parrot/whiteknight/imcc_compreg_pmc: db1fa87 | Whiteknight++ | / (6 files):
18:32 dalek parrot/whiteknight/imcc_compreg_pmc: many changes to the new IMCC API. We're building again and doing about as well on the test suite as we were
18:32 dalek parrot/whiteknight/imcc_compreg_pmc: review: https://github.com/parrot/parrot/commit/db1fa87fc1
18:32 cotto_work PL/Perl6 is pretty cool.
18:32 * dukeleto needs to make it work again on modern stuff.
18:32 whiteknight sorry, I had to push to get work off this infernal VM
18:33 * dukeleto also needs to setup CI for it, so this junk doesn't happen again
18:36 nwellnhof regarding the whole pointer thing: i think it would make sense to add a "nativ2e pointer slot directly to the PMC header. so we wouldn't have to allocate attributes for many PMCs like strings.
18:36 nwellnhof *native
18:40 whiteknight we used to do that. The pmc->data field used to be used for other things
18:42 whiteknight that raised hell with inheritance and subclassing for instance. Plus it made the allocator complicated as hell
18:42 whiteknight adding a new field to every PMC header might be expensive
18:42 whiteknight although we could use a flag and have "extended" PMC headers which contain a few more optional fields when needed
18:44 whiteknight if our GC were smarter, we could have multiple PMC pools of various sizes, and have the attributes allocated right in line with the PMC header
18:44 nwellnhof but then we wouldn't be able to "morph" PMCs.
18:45 whiteknight we really can't do that now with most types. morph probably needs to die
18:45 nwellnhof it's a useful feature for some languages. Rakudo relies on it afaik.
18:47 nwellnhof btw, the inital gc_ms2 implementation added two words to every PMC header. now it's down to one.
18:48 benabik nwellnhof: The only ref to morph I see in rakudo.git is a VTABLE entry with an empty body.
18:48 whiteknight which two?
18:49 nwellnhof prev/next for a linked list
18:49 whiteknight right, okay
18:49 benabik Although I suppose it could rely on something that uses morph and I wouldn't be wiser.
18:51 whiteknight unlikely. Very few things use morph because it isn't consistently implemented throughout the codebase
18:52 whiteknight CallContext.morph, as an example I learned about recently, doesn't morph at all. It acts like a clear/reset
18:53 whiteknight If you don't see any instances of the morph opcode, or VTABLE_morph in the rakudo codebase, it probably doesn't use it
18:53 whiteknight and NQP too
18:53 benabik If morph is being (mis-)used as other things, it seems likely it should be murdered and replaced with something more to the point.
18:53 whiteknight thank you!
18:53 whiteknight yes, that's exactly what should happen
18:54 whiteknight murdered with a sharp stick
18:55 benabik Only rakudo code ref to morph: src/pmc/objectref_pmc.template:    VTABLE void morph(PMC *type) {}
18:55 nwellnhof Rakudo plays some games with PMC attributes directly.
18:56 benabik But when the spot meant for one thing starts getting used for other things, it means the original meaning was useless...  And when it's something like a VTABLE slot, that could be tricky.  Encouraging people to mis-use VTABLEs can lead to funny errors.
18:56 dukeleto benabik: make sure you are looking at perl6/nqp as well
18:57 benabik Funny "uh-oh", not funny "ha-ha".
18:57 nwellnhof all i'm saying is that having an indirection for PMC attributes is what makes them dynamic compared to the JVM for example.
18:58 lucian i've been thinking about gobject lately
18:58 benabik dukeleto: I don't see any use of morph in NQP, actually.
18:59 whiteknight I strongly suspect it isn't used
18:59 whiteknight and if that's the case, I say it gets ripped out and we maybe replace it with the kinds of vtables that we actually need
18:59 whiteknight and without morph, We can add some non-trivial optimizations to the PMC allocator
19:00 dukeleto i am +1 to removing the morph vtable with a few, more-specific, vtables
19:00 dukeleto which hopefully will be much easier to optimize
19:01 dukeleto benabik: good, just wanted to make sure you were checking :)
19:01 benabik whiteknight: If people (like rakudo) are playing with attributes directly, then we'd still need to be a little conservative.
19:01 benabik dukeleto: I wasn't, but I'm pretty fast with ack and git-grep.  :-D
19:01 nwellnhof a VM for dynamic languages should have the ability to change the types of object dynamically.
19:01 dukeleto benabik: as long as we deprecated appropriately, there should be an issue
19:01 dukeleto nwellnhof: i agree. I just think the morph vtable is a bad design decision to get that feature
19:01 whiteknight benabik: that's true, but if we can find out what they are doing to the attributes maybe we can provide better solutions to their problems
19:02 dukeleto s/should/shouldn't/g
19:02 dukeleto benabik: rakudo is almost always amenable to "here, we made this less broken, please use the new shiny"
19:03 whiteknight nwellnhof: Maybe. I'm not sure I agree. It's certainly a bit of a hassle to change the PMC type on the fly without causing memory leaks or other weird crap. This is all not to mention the problem of mapping data between two arbitrary PMC types
19:03 benabik Is morph the only way to cast a PMC?
19:03 whiteknight at the moment
19:03 benabik :-/
19:04 whiteknight a Class.map method might be a better alternative
19:04 whiteknight just switching the ->vtable and some flags on the PMC header, which is what we do now for the most part, is worthless. It's mapping of data that's the real problem
19:04 benabik So a C-ish "x = (int) float_var" is "x = float_var; x.morph(int)"?
19:05 whiteknight more or less
19:05 nwellnhof what i'm talking about is essentially smalltalk's "become"
19:05 NotFound C is not a bad example for morphing-alike things.
19:05 whiteknight nwellnhof: yeah, I suspect that's the primary inspiration behind our morph situation
19:05 NotFound I mean, *is* a bad
19:06 plobsing joined #parrot
19:06 benabik NotFound: I meant C-ish more for the syntax than anything else.
19:07 tadzik I'd like Close to work well
19:07 whiteknight nwellnhof: the real problem is mapping data. If you don't preserve the data in some way, there's no real benefit to using morph. Mapping data could become a huge pain in the ass
19:07 whiteknight you would need to add a per-class routine to handle mapping, and maybe per-class classes of mapper objects
19:07 whiteknight it could all get out of control very quicklt
19:07 whiteknight quickly
19:07 NotFound IMO is more problem when you morph objects that maybe other parts are using for its own purposes
19:08 whiteknight That said, there are some wins to be had if we can come up with a general solution to mapping data between HLL types, including types based on completely different object models
19:08 whiteknight THAT would be quite nifty
19:09 lucian whiteknight: i don't think that can be solved generally
19:09 dukeleto whiteknight: that seems like a white whale right now
19:09 benabik An analogue to Smalltalk's become is actually not bad.  But that's not what morph appears to be doing.  Morph swaps type, become swaps type _and data_.
19:09 dukeleto whiteknight: i would love to see it, but i think we might want to focus on baby steps for now
19:10 whiteknight right, that's my point
19:10 dukeleto whiteknight: with that end goal in mind
19:10 plobsing become has nothing to do with the types in question. it should be implemented by the GC.
19:10 plobsing in fact, IIRC, rakudo already does something similar manually in the binder
19:10 plobsing (it's really ugly)
19:11 benabik plobsing: With a base object class, you can do something like swap the data in-place instead of change all references to the object.
19:11 whiteknight a real, usable, flexible morph solution would look something like "morph(PMC *self, PMC *dest_class, PMC *mapper)", and we would need to add some standard methods to class
19:11 benabik (Assuming there's enough memory at the destination, which might be an issue, I'll admit.)
19:11 lucian i think morphing objects is a hard problem that can be solved with copying very quickly and inefficiently
19:12 plobsing benabik: (at a simplified level) become should swap the vtable and the data pointers in the PMC pointer.
19:12 plobsing no need to switch all instances
19:13 plobsing all instances point to the same header
19:13 benabik plobsing: Right.  That's about what I meant.  :-)
19:13 lucian plobsing: won't vtable functions operate that operate on instance data possibly break? (i may be misunderstanding pmcs)
19:14 plobsing lucian: if I swap the data and vtables of PMC1 with those of PMC2, neither PMC has vtables that are inconsistent with the data representation of the PMC they represent
19:15 lucian plobsing are PMC1 and PMC2 instances?
19:15 whiteknight and the flags
19:15 whiteknight actually, not all the flags, only the ones which are tied to the type
19:16 plobsing lucian: (re: attr-less pointer PMCs suggested in backscroll) I'm working on a pointer type that has a notion of skinny vs. fat and manages both representations internally
19:16 NotFound Note that we have funny things like hash backpointing to the pmc that owns it.
19:16 whiteknight NotFound: yes, that's something that we should probably fix eventually
19:16 plobsing lucian: yes, PMC1 and PMC2 are instances of some type. I fail to see how that changes things.
19:16 lucian plobsing: it doesn't. i thought you meant swapping the properties of the types
19:17 plobsing types are instances too
19:17 lucian sure, but don't instances point to their type?
19:18 plobsing yes. and if you swap out the type object from under instances, you get to deal with the fallout. with great power comes the ability to be left with an unmaintainable mess.
19:18 plobsing same problem if you swap objects in under a type constraint. all of a sudden, then constraint is violated after the check.
19:19 whiteknight These are all reasons why I think in-place morphing is a bad idea
19:19 lucian i see
19:19 lucian i don't think hlls should have to deal with this
19:20 plobsing but, the ability to harm yourself should not lead to an outright ban on stapplers (guns is such an overused analogy)
19:20 dukeleto in-place morphing seems to be very similar to in-place modifying opcodes, which we got rid of
19:20 whiteknight plobsing: it's not just that there's the potential for harm. We lose a lot of optimization potential by having to support in-place morph
19:20 dukeleto what are the implications of morph to our future JIT ?
19:20 lucian plobsing: but is this particular stapler very useful?
19:20 whiteknight we're hurting people who aren't even using morph
19:21 lucian why not just copy?
19:21 plobsing lucian: you *CAN'T* fully implement smalltalk without it.
19:21 plobsing lucian: one use case is transparent lazy types
19:21 lucian plobsing: i don't know smalltalk all that well, but i don't see how morphing can't be done with copying
19:22 plobsing become != morph, but the argument is similar
19:22 whiteknight if we want to support the smalltalk becomes feature, we're still hardly doing it right
19:22 NotFound If morph is something acepted to happen to any object, we risk to go to the same situation we had with strings before immutability: every time you return a PMC from anywhere you must return a copy just in case.
19:22 whiteknight in that case, the PMC* header should be much thinner, and should point to an attributes structure which contains the vtable too
19:23 whiteknight actually, that's probably still not the best way
19:23 nwellnhof lucian: you can't copy because you might have other references to the object.
19:23 Coke (getting rid of morph) how will you swap out vtables, then?
19:24 lucian nwellnhof: right, so for that to work with copy you'd need another indirection?
19:24 * Coke sees he missed a bit of discussion after that note.
19:25 whiteknight plobsing: in Smalltalk, is becomes a common operation? That is, should it be fast or can it be slow?
19:26 plobsing morph/becomes is powerful and it is expected to be used by users who *understand* the feature and its ramifications
19:26 Coke as usual, when planning to rip something out, please ask around (especially to rakudo) HLL devs to see if they actually need that bit you're annoyed at.
19:26 plobsing if you morph/become and it breaks, you get to keep both halves
19:26 whiteknight Coke: we're not planning anything yet
19:27 Coke 13:54 <@whiteknight> murdered with a sharp stick
19:27 lucian btw, i'm sort of confused and annoyed with parrot's object system(s) in general
19:27 nwellnhof lucian: i'm not sure if i understand your question but you need at least one level of indirection.
19:27 whiteknight Coke: We *are* discussing it, but we're not planning it
19:27 Coke I can see where folks reading backscroll might not realize that.
19:27 Coke k.
19:28 jan left #parrot
19:28 whiteknight Coke: and my personal wishes hardly qualify as official Parrot developer team plans, I'm sorry to say
19:28 lucian nwellnhof: and if you had a second level of indirection, you could copy and swap the pointers
19:28 nwellnhof lucian: one indirection is enough
19:28 NotFound plobsing: Who many people in earth understand Smalltalk? ;)
19:28 Coke whiteknight: given that you're a core developer and on the board, again, I can see where people reading the backscroll or your blog might not get that.
19:28 NotFound S/Who/How
19:28 whiteknight nwellnhof: it's worth noting that properly separating out a PMC header from it's attributes and data is a key component for a copying/compacting garbage collector
19:29 plobsing whiteknight: traditionally, smalltalks had an "object table", and become was fast (just update the table entry). most modern smalltalks omit the object table in favour of more pre-dereferenced objects, and become is slow.
19:29 whiteknight so there's a chance we could support that as well if we properly implement morph
19:29 NotFound So become became a different thing?
19:29 whiteknight plobsing: Okay, because I'm thinking that if we need to re-allocate the attributes struct and call some kind of map/update routine it could become pretty slow indeed
19:29 plobsing Parrot has an analogue to the object table - the PMC headers. For *other* reasons, we're not moving to more dereferenced objects. There is no reason why become should be slow
19:30 jan joined #parrot
19:30 whiteknight I don't know how we would be able to define the data mapping in PIR either, since we would need to be able to have two PMCs to copy data between. That's quite the tricky problem
19:30 plobsing whiteknight: why do we need to reallocate?
19:31 whiteknight plobsing: because the two types might have different sized attributes structures
19:31 whiteknight if we don't at least resize the attributes structure, we're basically creating a segfault engine
19:31 plobsing NotFound: if the interblags are to be beleived, most every Ruby hacker (despite the fact that they don't program in SmallTalk)
19:32 plobsing whiteknight: become takes two *already* allocated objects. all references to the first now point to the second. all references to the second now point to the first.
19:32 NotFound I think there are a lot more big mouths than small talks.
19:32 whiteknight plobsing: oh, that's very different from morph then.
19:33 whiteknight I'm not sure at all how we would implement that, except maybe to turn the first into a transparent pointer object for the second
19:33 NotFound In Ruby, and in any other language blogecosystem.
19:33 plobsing whiteknight: yes, but the argument of "we don't want to be swapping things out from ourselves" apply to both equally, and I'm arguing it is a poor argument that dissallows useful functionality.
19:33 whiteknight plobsing: I'm far less concerned about that point than I am concerned about the ramifications for the internal implementation
19:34 whiteknight I would be perfectly happy providing a becomes operation for Parrot
19:34 whiteknight but our current in-place morph routine is really...bad
19:34 NotFound Don't even talk about pmc_reuse
19:34 plobsing I agree morph is LTA.
19:35 whiteknight NotFound: no, pmc_reuse is terrible also
19:38 nwellnhof whiteknight: i don't see why a separate PMC header is necessary for a copying/compacting GC
19:38 whiteknight nwellnhof: so that you can copy/compact the actual guts of the PMC without having to update every single reference to that PMC throughout the system
19:38 whiteknight PMC header can come out of a small header slab, the guts can be moved around the system to wherever
19:39 plobsing don't we already do that?
19:40 whiteknight sort of, but not to the degree that we would need for a compacting GC
19:40 plobsing why do we separate struct Parrot_TYPE_attributes from struct PMC?
19:40 nwellnhof whiteknight: a real compacting GC also has to compact the PMC headers
19:40 whiteknight the PMC header would really need to be much lighter, like a single pointer, for that to really be a benefit
19:41 whiteknight the alternative is to add in some pretty invasive read barriers to update references on the fly
19:41 bacek ~~
19:41 nwellnhof plobsing: we do that with strings currently, PMC attributes are never copied/compacted
19:41 bacek Good morning, humans.
19:41 dukeleto bacek: i submitted a bunch of smoke reports for gen_gc on darwin. t/pmc/key.t had some failures
19:41 dukeleto bacek: also, top of the morning, meatbag
19:42 bacek dukeleto, gen_gc is wrong. There is major problem with handling of dirty_list.
19:44 whiteknight bacek: another problem?
19:44 bacek whiteknight, yes
19:45 plobsing bacek: I have an idea of how to get optimized register-access back. Ops2c needs to generate different code for 'in' register access vs. 'inout'/'out' register access.
19:45 dukeleto bacek: i only noticed it failing intermittently or only with certain compile flags. Not sure which.
19:45 bacek plobsing, yes. But ops2c doesn't parse op body.
19:46 dukeleto maybe it should.
19:46 bacek plobsing, which means I can't emit different code for $1, etc.
19:46 bacek dukeleto, I don't want to implement good half of C parser.
19:47 plobsing bacek: arguments to ops are declared in the signature (which ops2c *is* responsible for parsing)
19:47 cotto_work That was one of then negative goals of opsc
19:47 cotto_work (not parsing C)
19:47 bacek plobsing, yes. But accessors are always same - $n
19:48 plobsing bacek: and they shouldn't decode to the same thing, depending on whether the argument was declared 'invar PMC' or 'out PMC'/something else
19:48 plobsing it already makes different output based on these signatures
19:48 bacek plobsing, oh. I did implement parsing of op body.
19:48 plobsing 'in INT' vs 'in STR'. they get translated to different C code (obviously)
19:49 bacek so yes. We can emit different code for in vs inout agrs
19:50 plobsing in *most* cases (I think), we only read from the register
19:50 dukeleto cotto_work: guess we failed at that negative goal ;)
19:52 davidfetter joined #parrot
19:54 dalek parrot/generational_gc: 973a7ff | bacek++ | src/gc/gc_gms.c:
19:54 dalek parrot/generational_gc: Explanation about flaw in GC algorithm.
19:54 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/973a7ff94d
19:54 bacek plobsing, yes. I can work on it. Later. After fixing main algo.
19:54 bacek whiteknight, https://github.com/parrot/parrot/commit/973a7ff94d
19:54 luben NotFound, hash does not backpoint to PMC anymore
19:55 NotFound luben: glad to hear that
19:56 whiteknight bacek: ouch
19:56 whiteknight bacek: Are we going to need to compile inter-generational pointer lists?
19:57 dalek parrot/generational_gc: 1205bb4 | bacek++ | src/gc/gc_gms.c:
19:57 dalek parrot/generational_gc: Move "constant" objects into next generations.
19:57 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/1205bb45b1
19:57 dalek parrot/generational_gc: 7683330 | bacek++ | src/gc/gc_gms.c:
19:57 bacek whiteknight, I'm thinking about how to fix it...
19:57 dalek parrot/generational_gc: Limit number of generations to 2 to workaround bug in algo.
19:57 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/7683330a35
19:57 NotFound Note that ops files lack a revision about the validity of the signatures. I've see invar being modified more than one time.
19:59 ttbot Parrot 1205bb45 i386-linux-thread-multi make error http://tt.taptinder.org/cmdinfo/8196
19:59 plobsing NotFound: iff ops2c generated different code for invar registers, we could mark such pointers const and get the compiler to dissallow such usage
19:59 dukeleto plobsing: +1 to that
19:59 NotFound plobsing: that will be great.
20:00 plobsing otherwise the annotations are useless and good luck trying to do lifetime analysis for eg: a register allocator
20:02 bacek plobsing, changing way of handling in vs inout regs will be great.
20:02 theory left #parrot
20:07 lucian left #parrot
20:09 lucian joined #parrot
20:11 arnsholt Does the error "PARROT VM: Could not load bytecodeCONSTANT_ext/nqp-rx/src/stage0/NQP-s0.pir: Size in directory 23652 doesn't match size 0 at offset 0x16862" ring any bells for anyone?
20:12 plobsing arnsholt: suggests that PBC_COMPAT should have been bumped some time in the past but was not
20:12 plobsing the solution is to recompile
20:12 nopaste "bacek" at 192.168.1.3 pasted "Updated patch for rakudo" (86 lines) at http://nopaste.snit.ch/31060
20:12 bacek msg moritz "bacek" at 192.168.1.3 pasted "Updated patch for rakudo" (86 lines) at http://nopaste.snit.ch/31060
20:12 aloha OK. I'll deliver the message.
20:14 whiteknight bacek: Does that gc write barrier function exist in master?
20:14 bacek whiteknight, function - no, macro - yes.
20:15 whiteknight bacek: okay, I'm just trying to make sure the merge goes smoothly
20:15 moritz bacek: does it build now?
20:15 bacek moritz, yes. On my box.
20:15 moritz I'll try it here
20:16 dalek parrot/generational_gc: 09bae79 | bacek++ | src/gc/gc_gms.c:
20:16 dalek parrot/generational_gc: Tune the Moon: use 1/100 of available memory for gc_threshold
20:16 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/09bae79da6
20:19 bacek Why MMD_Cache is hash, not Hash PMC?
20:21 cotto_work bacek: have you added a noop write barrier to trunk?
20:21 whiteknight bacek better performance, right?
20:21 whiteknight cotto_work: yes, he says it's a macro in master
20:22 cotto_work ok.  I'm behind on code review.
20:22 bacek cotto_work, I forgot to add function definition...
20:22 whiteknight left #parrot
20:22 whiteknight joined #parrot
20:23 bacek cotto_work, but it can be cherry-picked from branch.
20:23 cotto_work I don't care if it's a function or a macro as long as HLLs continue to work.
20:23 bacek moritz, make spectest fails (not epically)
20:24 tadzik heh, will there be generational_gc_dynamic_treshold one day? :)
20:24 moritz bacek: compiling core.pm segfaults here
20:24 bacek cotto_work, I'll fix it tonight.
20:24 bacek moritz, can you get backtrace from gdb?
20:25 bacek moritz, and you should use "bleeding edge" version of branch
20:25 moritz bacek: when my daughter stops screaming, I'll try
20:25 bacek moritz, ok.
20:26 bacek moritz, how old is she?
20:26 moritz rakudo: say DateTime.today - DateTime.new('2011-01-14), ' days'
20:26 p6eval rakudo 03380c: OUTPUT«===SORRY!===␤Unable to parse postcircumfix:sym<( )>, couldn't find final ')' at line 22␤»
20:26 moritz rakudo: say Date.today - Date.new('2011-01-14'), ' days'
20:27 p6eval rakudo 03380c: OUTPUT«26 days␤»
20:27 bacek moritz, wow. Congratulations! :)
20:27 moritz bacek: thanks
20:27 moritz that's on RELEASE_3_0_0-845-g7683330
20:28 tadzik LTA error message btw :)
20:29 bacek moritz, my git-fu is weak. How I can get this tag?
20:29 moritz bacek: git describe --tags
20:29 bacek RELEASE_3_0_0-846-g09bae79
20:30 moritz .oO( the git foo is weak in this one... )
20:30 * moritz pulls again
20:30 benabik BTW: That means RELEASE_3_0_0 tag + 846 commits, current rev is 09bae79.
20:30 bacek moritz, unlikely that it will help.
20:35 moritz bacek: hasn't segfaulted yet, still compiling core.pm
20:35 nwellnhof left #parrot
20:35 bacek moritz, optimized build?
20:36 dalek parrot/generational_gc: a7d4bdc | bacek++ | include/parrot/context.h:
20:36 dalek parrot/generational_gc: Disable shortcuts for setting CallContext fields. We do need write barriers.
20:36 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/a7d4bdc3e6
20:37 moritz bacek: yes
20:38 moritz bacek: build succeeds, about a third of the spectests returns errors
20:39 bacek moritz, same here.
20:39 dalek TT #2003 created by arnsholt++: Configure.pl from tools/dev/create_language.pl doesn't play nice with git
20:39 dalek TT #2003: http://trac.parrot.org/parrot/ticket/2003
20:42 benabik left #parrot
20:48 lucian left #parrot
20:48 lucian joined #parrot
20:53 vmspb left #parrot
20:55 plobsing left #parrot
21:00 plobsing joined #parrot
21:01 dalek parrot/generational_gc: d9497e3 | bacek++ | src/embed/api.c:
21:01 dalek parrot/generational_gc: Apply patch from nwellnhof++ to disable GC during Packfile loading. Wallpapering problems ftw.
21:01 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/d9497e3fc5
21:01 whiteknight what is the real problem there with packfile loading?
21:01 whiteknight why are we having to apply this wallpapering?
21:02 bacek whiteknight, because it's creating PackFile_* structs. Which aren't handled during GC.
21:02 bacek For example, unpacked Sub PMC will be collected.
21:02 bacek Etc, etc, etc
21:03 bacek We can remove this workaround after switching to PMCs internally,
21:03 bacek Actually, we can create GSoC task - switch parrot internals to use PMCs only.
21:03 bacek MMD_Cache, Packfiles, etc.
21:04 bacek I suspect there is a _lot_ of places where we can simplify and improve things.
21:04 perlite_ joined #parrot
21:05 bacek afk # dayjob
21:06 whiteknight bacek: plobsing is doing that right now
21:06 whiteknight no GSoC project needed
21:08 perlite left #parrot
21:08 perlite_ is now known as perlite
21:08 theory joined #parrot
21:14 plobsing whiteknight: well I'm not doing that immediately. a few more yacks to shave. but it is my goal.
21:15 whiteknight plobsing: I can't keep track. I'm a poor Yak herder
21:16 whiteknight we need a little status feed, so we can see what developers are working on right now
21:16 whiteknight "plobsing current status: GCable packfiles in IMCC"
21:16 whiteknight "whiteknight current status: MURDER IMCC"
21:17 plobsing speaking of GC tasks, can we pare down BigProjectIdeas a bit? I'm fairly sure we would *not* accept an independantly developped JIT system. too many people have too much invested in Lorito
21:19 plobsing people reading that page might get the wrong idea about that
21:20 cotto_work plobsing: good idea
21:24 whiteknight yes, that probably is a good idea
21:24 whiteknight we would accept it if it was high quality and was compatible with Lorito
21:25 whiteknight but since Lorito is still mostly in a few people's heads and an outside developer probably isn't aware of all the details, that's unlikely
21:25 cotto_work anyone making a jit would most likely need to drop by here
21:25 NotFound And now... winxed C++ backend first steps: https://github.com/NotFound/winxedxx
21:25 plobsing my take on that page is that it is a list of RFIs. for people that just want to hack something up without widely consulting the community beforehand.
21:25 plobsing because there are people who work like that (rare as they may be)
21:27 plobsing If I showed up tommorrow and asked about creating a JIT and you explained what Lorito was and the timeframe, I'd take that as "thanks, but come back later" and feel somewhat lied to
21:28 atrodo I agree, the JIT is a task that needs Lorito figured out before someone can reasonably be able to work on it
21:29 cotto_work volunteers?
21:29 dalek tracwiki: v24 | plobsing++ | BigProjectIdeas
21:29 dalek tracwiki: Remove JIT-related tasks. Adding a new JIT for the current system is not desirable. Lorito is the future.
21:29 dalek tracwiki: http://trac.parrot.org/parrot/wiki/BigP​rojectIdeas?version=24&amp;action=diff
21:29 cotto_work or that
21:30 whiteknight left #parrot
21:40 adu joined #parrot
21:45 dalek tracwiki: v25 | whiteknight++ | BigProjectIdeas
21:45 dalek tracwiki: remove generational GC. We're doing that in-house
21:45 dalek tracwiki: http://trac.parrot.org/parrot/wiki/BigP​rojectIdeas?version=25&amp;action=diff
21:47 fperrad left #parrot
21:48 plobsing I'm not entirely sure we want i18n for internal error messages. The platform-encoding changes I made a while ago had the accidental effect of exposing localized C library error messages. NotFound protested vehemently.
21:49 plobsing but that's a project policy decision.
21:49 Tene What was his objection?
21:50 NotFound We shouldn't do that without a deprecation period.
21:50 plobsing All I remember is "DO NOT WANT"
21:50 NotFound Lots of code depend on the text of the error messages.
21:59 wknight-phone joined #parrot
22:04 rurban_ joined #parrot
22:07 rurban left #parrot
22:07 rurban_ is now known as rurban
22:14 cotto_work msg whiteknight What was the GObject metamodel entry on BigProjectIdeas about?
22:14 aloha OK. I'll deliver the message.
22:15 bacek_at_work cotto_work, probably from GNOME
22:17 cotto_work sure, but I'm curious why he picked that.
22:17 cotto_work maybe just because it was a C-based object model
22:18 bacek_at_work probably
22:18 bacek_at_work "Perhaps the most profound difference is GObject’s emphasis on signals (called events in other languages). This emphasis derives from the fact that GObject was specifically designed to meet the needs of a GUI toolkit."
22:18 cotto_work I'm reasonably sure that we can drop the idea in favor of a 6model-like implementation.  I just want to check with him first since he added it.
22:18 bacek_at_work I don't particularly like it...
22:19 bacek_at_work And 6model is little bit more preferable.
22:19 cotto_work It'd be helpful for all the gui code we have in Parrot.
22:21 bacek_at_work we can implement GObject on top of 6model (I think)
22:27 wknight-phone left #parrot
22:29 Andy left #parrot
22:33 theory left #parrot
22:51 dalek parrot/generational_gc: 016bd2c | bacek++ | src/call/context.c:
22:51 dalek parrot/generational_gc: Fix get_PMC_get assert to skip NULLs.
22:51 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/016bd2cd15
22:59 cosimo joined #parrot
23:06 cosimo left #parrot
23:06 cosimo joined #parrot
23:10 Coke (signal/events) absolutely need a decent event loop to handle tcl.
23:25 plobsing left #parrot
23:26 dmalcolm left #parrot
23:28 bacek left #parrot
23:28 plobsing joined #parrot
23:29 theory joined #parrot
23:33 plobsing if we aren't able to host GObject on top of 6model, I'd call that a failure
23:45 plobsing left #parrot
23:46 dukeleto sounds like a good litmus test to me
23:55 cotto_work The only problem is finding someone interested in Parrot who knows GObject and wants to implement a 6model version.
23:55 cotto_work but it'd be an interesting test case

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

Parrot | source cross referenced