Parrot 3.0.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: Fix ipv6-related failures | Test imcc_interfaces and annotations-tree branches
Set by moderator on 8 February 2011.
dalek rrot/generational_gc: b20e86a | bacek++ | src/gc/gc_gms.c:
Use different stats to trigger GC
 00:16
rrot/generational_gc: f7ed1db | bacek++ | t/op/gc-leaky- (2 files):
Increase number of iterations in gc test
rrot/generational_gc: e19f4cf | bacek++ | src/gc/api.c:
Add GMS to gc_sys_name.
rrot/generational_gc: 34ef135 | bacek++ | t/op/gc-leaky- (2 files):
Check mem_since_last_alloc for GMS in GC test
whiteknight nwellnhof: yeah, several failures are expected 00:18
bacek_at_work make test passed on gen_gc branch now.
whiteknight bacek++ 00:19
cotto_work bacek++ 00:20
How do you debug that so quickly?
whiteknight magic. coding. robot. 00:21
say it with me 00:22
Hackbinary Magic. Coding. Robot.
cotto_work decommutes 00:24
00:32 nwellnhof left
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:33
bacek_at_work Tene, about 1.5 years actually. gen_gc for last 6 month. 00:41
jnthn, ping 00:43
whiteknight it looks like many of the remaining failures in imcc_compreg_pmc are because I'm not throwing exceptions properly on error 00:45
cotto Tene++ 00:46
and bacek++ for being a hard-working coding robot 00:47
00:51 vmspb left 01:01 benabik_ joined, benabik_ left 01:02 benabik_ joined
dalek rrot/generational_gc: a00a78b | bacek++ | src/string/api.c:
Clean more flags in ugly hack in str_copy.
 01:09
dukeleto ~~
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 01:13 kid51 joined
whiteknight bacek: what does performance look like on that branch? improvement? 01:14
01:14 arnsholt left, arnsholt joined 01:15 GeJ left 01:16 GeJ joined, particle1 joined, allison left, Hunger left, wagle left, allison joined, wagle joined 01:17 particle left, [hudnix] left, [hudnix] joined 01:18 Hunger joined
dukeleto bacek_at_work: don't we have a gc stress test in examples/benchmarks ? 01:18
01:21 freeksh0w86 joined 01:23 dmalcolm_ left
whiteknight nwellnhof++ I would never have found that GC bug, because I was only looking at code I had changed 01:31
now that I'm past that, I feel like I can really make some progress on this damn brnch
01:34 benabik_ left
dalek website: jkeenan++ | "Do It for Python!" 01:40
website: www.parrot.org/content/do-it-python
01:55 freeksh0w86 left 02:01 sECuRE left 02:06 ryan joined 02:08 autark left
whiteknight is apparently a total n00b 02:15
I was passing a STRING* instead of a char* to Parrot_ex_throw_from_c_args
and I was wondering why my error messages were all b0rkd
kid51 Didn't your mother warn you about that? 02:16
whiteknight my mother and her compiler 02:17
Tene my only fail on the generational_gc branch was t/pmc/socket_ipv6.t 02:18
I think it's uploading a smoke report right now?
yeah, uploaded.
smolder.parrot.org/app/projects/rep...tails/8352
02:18 rurban left
dalek rrot/whiteknight/imcc_compreg_pmc: c747815 | Whiteknight++ | / (5 files):
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
whiteknight it bugs me how much text IMCC dumps out to stderr
plobsing 2>/dev/null # problem solved! 02:22
right?
02:22 autark joined
whiteknight rm -rf compilers/imcc/* 02:22
that command makes me so happy, I could marry it 02:23
Tene exec 2>/dev/null # all problems solved
plobsing rm -rf compilers/imcc; git checkout compilers
do it as many times as you like 02:24
whiteknight git rm compilers/imcc/*; git commit -a -m"HAHAHAHAA"; git push 02:25
better than cocaine
well, I assume so anyway
02:26 rurban joined 02:33 whiteknight left
kid51 whiteknight/imcc_interfaces PASS smolder.parrot.org/app/projects/rep...tails/8351 02:34
nopaste "bacek" at 192.168.1.3 pasted "gen_gc vs master "ops2c --core" "benchmark"" (65 lines) at nopaste.snit.ch/30922
cotto That's exciting news. 02:35
bacek++
thanks for all the work you're putting into that branch
bacek_at_work We just have to fix our HLLs...
I have initial patch for rakudo (at home) 02:36
kid51 bacek++
bacek_at_work But we'll need a lot of help from fperrad++ for Lua. I don't understand LuaFunction code at all.
plobsing bacek_at_work: did you cook up some scheme involving switching around vtables to avoid requiring modifications?
s/did/didn't/ 02:37
bacek_at_work plobsing, I got rid of it
kid51 whiteknight/imcc_compreg_pmc branch: FAIL smolder.parrot.org/app/projects/rep...tails/8356
bacek_at_work I changed original VTABLE generation to put write barrier after call.
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.
but both init and init_int are marked with :write 02:44
plobsing init is not getting the barriering AFAICT
02:45 Drossel left
plobsing although arguably, neither should get barriered because we can assume they operate on objects that will be in the nursery. 02:46
02:47 Kulag joined
bacek_at_work plobsing, nope. It's barriered. 02:47
commit 5b175bb2e2cea067aa4f784c409966ac4d9dd6b4 02:48
Mark .init* functions with :write.
During initilization of PMC we can trigger GC. In this case we have to
put freshly allocated PMC into dirty_list to preserve old-to-young
pointers.
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]
bacek_at_work plobsing, I fixed it few commits ago...
can you re-run them with verbose output? 02:49
plobsing rebuilding with latest changes. will re-run. 02:51
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
on latest
bacek_at_work plobsing, shit... 03:01
plobsing t/op/gc-leaky-{box,call}.t appear to be fine now
it is happening outside of gc, in Parrot_Hash_get_pointer(), for a PMC with a null ->data 03:03
bacek_at_work it's GC... 03:04
Hash keys collected prematurely. Somehow.
plobsing it is an optimized build fwiw. I'll try unoptimized in a sec. 03:06
nopaste "bacek" at 192.168.1.3 pasted "test patch for plobsing++" (17 lines) at nopaste.snit.ch/30923 03:10
bacek_at_work plobsing, can you try optimized build with nopasted patch?
03:12 Kulag left, Kulag joined
plobsing bacek_at_work: unoptimized build passes 03:12
03:13 ryan left
plobsing bacek_at_work: with patch, still segfaults 03:19
bacek_at_work plobsing, it's bad...
plobsing if I give you some GC parameters (please advise which ones), do you think you'd be able to reproduce the error? 03:22
kid51 generational_gc linux/i386 no optimize: one file FAIL: smolder.parrot.org/app/projects/rep...tails/8362 03:23
Sorry, 8362 was --optimize
bacek_at_work plobsing, yes. At least I can try. 03:25
kid51, there is no failures in smolder...
kid51 Strange 03:27
bacek_at_work plobsing, I did reproduce it. We collect Hash prematurely. 03:28
(gdb) up
#1 0xb7e642e0 in Parrot_set_p_kc_p (cur_opcode=0x811bd58, interp=0x8052020) at src/ops/core_ops.c:21949
21949\t VTABLE_set_pmc_keyed(interp, PREG(1), PCONST(2), PREG(3));
(gdb) p _self->flags & b_PObj_on_free_list_FLAG
$28 = 131072
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
bacek_at_work kid51, same failure as plobsing.
plobsing and by we, I mean bacek++. I'm just the peanut gallery
bacek_at_work :) 03:30
kid51 t/op/gc.t ...................................
All 123 subtests passed
bacek_at_work plobsing, it's freshly allocated Hash PMC. At least it's from Gen0.
but CallContext is from Gen1. 03:31
ookey.
CallContext is sealed. Which means I missed update of PMC register somehow. 03:32
Gotcha!
plobsing wait. do we WB on every set register?
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: smolder.parrot.org/app/projects/rep...tails/8365
bacek_at_work plobsing, on every access. But after triggering WB it's disabled.
benabik G'evening
nopaste "bacek" at 192.168.1.3 pasted "Another patch." (14 lines) at nopaste.snit.ch/30927 03:37
bacek_at_work plobsing, can you try it?
(nopasted patch)
old one can be wiped off
03:39 Drossel joined 03:41 Kulag left
bacek_at_work plobsing, yes. Looks like patching ops2c to emit WB is slightly better option. 03:43
I'll commit current workaround and fix it properly later
karma jkeenan 03:44
aloha jkeenan has karma of 289.
dalek rrot/generational_gc: 500ddf6 | bacek++ | src/gc/gc_gms.c:
Rerun headerizer
 03:45
rrot/generational_gc: 3917979 | bacek++ | src/gc/gc_gms.c:
Put whole validate_objects into ifndef NDEBUG.
rrot/generational_gc: f14c1a6 | bacek++ | include/parrot/context.h:
Temporary workaround to enable write barriering of CallContexts. plobsing++ and jkeenan++ for testing.
bacek_at_work kid51, plobsing, can you retest optimized build with latest commit?
03:46 simcop2387_ joined 03:48 simcop2387 left, simcop2387_ is now known as simcop2387, Kulag joined 03:49 Drossel left
plobsing bacek_at_work: no more segfaults 03:51
03:51 simcop2387 left
plobsing running fulltest 03:51
bacek_at_work plobsing++ # Yay!
03:52 simcop2387 joined
bacek_at_work wander why do we have t/op/jit.t? 03:53
plobsing they were tests originally created to test the jit, but are useful for testing any runcore 03:55
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:56
03:57 Kulag left 03:58 Kulag joined 04:02 kid51 left, rurban_ joined
plobsing bacek_at_work: failures in codetest: c_arg_assert, c_function_docs, c_cppcomments 04:04
04:05 rurban left, rurban_ is now known as rurban 04:07 Kulag left
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.
which is more or less pass
mikehh plobsing: they were fixed after bacek merged master into generational_gc 04:09
benabik Woo! make test on gen_gc now only fails on checkdepend, which also fails in master. (src/platform.c). Now onto Rakudo. 04:11
plobsing bacek_at_work: any ideas to improve the "temporary workaround"? 04:12
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:14
benabik Still segfaults building Perl6::Grammar in Rakudo. :'( 04:15
plobsing benabik: rakudo requires a patch for this. I beleive bacek has a patch.
benabik plobsing: OIC
mikehh I have no idea how to put casts into a macro :-{ 04:17
benabik mikehh: Like you put everything else in a macros: Very carefully. 04:18
mikehh benabik: hee - I hate macros in C
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
plobsing OHAI I IS IMG MACRO
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...
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:30
mikehh seriously needs sleep - it's 4:30am for me 04:31
04:38 adu joined
bacek_at_work Tene, it will be helpful. But I have patch at home. 04:45
Tene bacek_at_work: Ah.
You mean not everyone leaves their home workstation available over ssh constantly? ;) 04:46
dalek rito: 4f737d2 | atrodo++ | internal_pmc/context.c:
Remove debugging information
 04:47
rito: ad6297f | atrodo++ | / (2 files):
Convert the ptrs struct in a PMC to an array of pointers
rito: 0208700 | atrodo++ | / (5 files):
Make the plunge so that names of the internal PMCs are Lorito_Str's
rito: 8c2a2d7 | atrodo++ | core.c:
Correct a typo where the wrong variable was being used
rito: 8f0e31f | atrodo++ | / (4 files):
Add internal_pmc/file as the code base for the file PMCs
rito: e6ff0a0 | atrodo++ | loader.c:
Correct a few bugs in the searching to load bytecode
rito: 80ac662 | atrodo++ | loader.c:
Don't increment the fileid until after the file has been opened
bacek_at_work Tene, yeah :)
rito: 7976f50 | atrodo++ | Makefile:
Make the makefile a little more useful in showing errors
05:30 mtk left 05:36 mtk joined 06:02 rurban_ joined 06:04 adu left 06:05 rurban left, rurban_ is now known as rurban 06:13 adu joined
dukeleto ~~ 06:17
cotto hi dukeleto 06:18
06:31 woosley joined
Tene rather pleased about generational gc branch 06:33
06:33 adu left 06:40 adu joined
dukeleto hears that gen_gc is passing "make test" ? 07:21
Tene dukeleto: WFM 07:22
dukeleto: you should submit a smoke report :)
dalek rrot/generational_gc: a38436e | bacek++ | / (4 files):
Add GC flags combinations and use them instead of specifing individual
 07:26
rrot/generational_gc: ad5a1f3 | bacek++ | / (2 files):
Use macro instead of function to set generation flags
rrot/generational_gc: 8cdd27a | bacek++ | src/gc/gc_gms.c:
Remove now unused function
07:28 cosimo left 07:29 theory left
dukeleto Tene: hah, I don't sent single reports. Only relentless waves of reports 07:33
dukeleto switches to the gen_gc branch on his darwin smoker 07:34
ok, i got a darwin smoker on the gen_gc branch 07:35
what we really need are performance benchmarks for gen_gc 07:36
bacek_at_work msg mikehh c++ build should be fixed now
aloha OK. I'll deliver the message.
bacek_at_work dukeleto, 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.
bacek_at_work isparrotfastyet.com? 07:39
Anyway gen_gc isn't tuned (yet). We can make it faster. 07:41
dukeleto bacek_at_work: exciting! 07:44
07:46 fperrad joined
cotto Is there a better place in the repo to do m0 planning than a pdd in docs/pdds/draft? 08:15
dukeleto, ^
dalek rrot/m0-spec: 92f8218 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add initial pdd for m0, completely composed of stubs for now
 08:22
ttbot Parrot c34f278b i386-linux-thread-multi make error tt.taptinder.org/cmdinfo/6733 08:25
dukeleto cotto: i think that is a fine place
cotto++ # giving the m0 spec a home 08:26
08:26 adu left
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
mj41: good to see you around :)
08:47 adu joined
mj41 dukeleto: It's morning here. I just came to work :-) 08:48
nopaste "bacek" at 192.168.1.3 pasted "Initial patch for rakudo." (79 lines) at nopaste.snit.ch/30955 09:18
mj41 tt.taptinder.org/buildstatus/parrot...ational_gc ... starting/configuring other clients 09:35
bacek mj41++ # Hooray! tt is even more useful now! 09:36
09:46 lucian joined 10:23 nwellnhof joined
ttbot Parrot 117c0c1c i386-freebsd-64int make error tt.taptinder.org/cmdinfo/7110 10:27
dalek rrot/generational_gc: a02c83d | bacek++ | src/gc/gc_ (2 files):
Split print_stats into 2 functions to make it available in optimizied builds
 10:28
rrot/generational_gc: 6ef2023 | bacek++ | src/call/context.c:
Add assert to CallContext PMC accessor. Object must be alive.
rrot/generational_gc: d862ee4 | bacek++ | src/pmc/callcontext.pmc:
Add assert to CallContext.push_pmc. Object must be alive.
ttbot Parrot d862ee46 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/7146 10:34
10:37 lucian left 10:39 contingencyplan left
nwellnhof bacek: i get a segfault when building runtime/parrot/library/nqp-setting.pbc with a GC threshold of 128K 10:42
(generational_gc branch, of course)
bacek nwellnhof, sigh... It's probably good thing if I can replicate it on my box. 10:43
(If it's not in PBC_unpack) 10:44
nwellnhof bacek: looks like it's related to TT #1990
bacek nwellnhof, indeed. It's crashed in do_sub_pragmas 10:45
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:46
bacek nwellnhof, doesn't help... 10:52
I'm trying it right now
Problem is: critical stuff was already collected. 10:53
nwellnhof maybe this helps: github.com/parrot/parrot/commit/73...f0e4dc78ae
(my fix to whiteknight/imcc_compreg_pmc from yesterday) 10:54
bacek ookey
let me try it
nwellnhof no, it doesn't help. i just tried. 10:55
bacek sigh 10:58
no, it doesn't
nopaste "nwellnhof" at 192.168.1.3 pasted "GC block diff" (29 lines) at nopaste.snit.ch/30967 11:09
nwellnhof that patch does the trick for me. but we should really fix TT #1990. 11:10
bacek nwellnhof, we should switch to Packfile PMC to properly fix it... 11:13
nwellnhof yes, indeed 11:14
mikehh bacek: get one failure - t/pmc/key.t - Failed 10/13 subtests - Non-zero wait status: 11 - segfaults after ok 3 11:58
bacek: also painfully slow - make test TEST_JOBS=4 -> real 15m4.460s, user 27m17.194s, sys 0m34.082s 12:01
bacek: presume it is because of the debug stuff 12:02
12:04 dd070 joined, adu left, dd070 left 12:20 lucian joined
mikehh bacek: much better with --optimize - Result: PASS - real 4m58.117s, user 8m20.595s, sys 0m30.366s 12:26
bacek: thats on Ubuntu 10.10 i386 (g++-4.5 with --optimize) previous result no optimize 12:28
12:34 lucian left 12:35 bluescreen joined 12:43 Kulag joined 13:17 mtk left 13:23 mtk joined 13:47 benabik_ joined 13:56 whiteknight joined
whiteknight good morning, #parrot 13:56
14:03 benabik_ left 14:04 rurban_ joined 14:07 rurban left, rurban_ is now known as rurban 14:15 plobsing left 14:26 GodFather joined 14:31 bluescreen left 14:57 mikehh left
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.
NotFound whiteknight: pong 15:14
whiteknight: What kind of value?
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.
whiteknight okay 15:16
Hackbinary good afternoon #parrot 15:17
is there a 'glossary' of parrot-ish terms and acronyms? 15:18
NotFound Hackbinary: docs/glossary.pod 15:19
Hackbinary thanks 15:20
Coke someone on #perl6 asking if they/we have nonblocking IO yet. 15:21
nwellnhof no, we don't 15:23
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
PerlJam Coke: I think it's more like "we might have another user that could leverage bunches of other users" 15:29
15:32 mikehh joined 15:40 theory left 15:43 mtk left 15:44 particle1 left 15:50 mtk joined, particle joined 15:54 plobsing joined
dukeleto ~~ 15:57
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:00
cotto_work ~~ 16:16
16:17 Patterner left, Psyche^ joined, Psyche^ is now known as Patterner
Coke PerlJam: that's implied for all our users. 16:20
but yah.
16:21 woosley left 16:25 simcop2387_ joined, simcop2387 left, simcop2387_ is now known as simcop2387
dukeleto cotto_work: mornin' 16:27
dukeleto submits some talks to LinuxFestNW
Coke ponders submitting a talk to the local CF user's group to show them how much their regexes suck.
doesn't think it would go over too well. 16:28
whiteknight I've had occasion to use CF at $dayjob. Can't say I disagree with your sentiment 16:34
s/regexs/everything/
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
(the above is in the context of gen_gc)
16:36 Andy joined, simcop2387_ joined
benabik Morning, all! 16:37
16:37 simcop2387 left, simcop2387_ is now known as simcop2387
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!
Coke but I still cringe whenever I have to deal with nested subcaptures.
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)
27,634 ok, 0 failed, 610 todo, 1,847 skipped and 0 unexpectedly succeeded
cotto_work dukeleto: when do LinuxFest NW talks need to be submitted by? 16:48
whiteknight plobsing: pong
cotto_work also, what are you talking about there? 16:49
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:50
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
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
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.
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:53
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?
plobsing whiteknight: IMCC will work with a PMC the whole time 16:55
dukeleto cotto_work: not for a while
whiteknight that's awesome news
cotto_work indeed
16:55 dmalcolm joined
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.
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
cotto_work dukeleto: heh
whiteknight otherwise, I'm happy to incorporate your work into my branch later
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.
arnsholt Is there a recommended way to move from "Configure.pl fetches from SVN" to "Configure.pl fetches from git" for my HLL? 16:58
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
plobsing: of course, if there's a conflict during a merge, I may ask for some help to correct it :)
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
plobsing so I'll be branching master.
and begin work immediately 17:02
whiteknight okay. I'll keep close eye on your branch
17:06 lucian joined 17:16 jsut_ joined
plobsing :qa 17:19
ENOTVIM
cotto_work That explains why my files keep disappearing. 17:20
17:21 jsut left
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:22
17:27 nwellnhof left, ryan joined
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
17:28 mj41_ joined 17:29 GodFather left
Coke perhaps make them children of *struct? 17:29
plobsing *struct are poorly designed. the custom types are a symptom. 17:30
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
17:31 mj41 left, mj41_ is now known as mj41
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:33
dalek TT #2002 created by kEAxTtHPsoXdTfX5++: Business cards 17:36
TT #2002: trac.parrot.org/parrot/ticket/2002
plobsing 911! spam police! 17:37
cotto_work I don't see any spam. 17:38
plobsing should we have a captcha for account creation?
cotto_work It's tempting to move to manual account creation or verification. 17:40
dukeleto: what are you talking about at LinuxFest NW? 17:42
17:42 vmspb joined
Coke raising the bar on reporting bugs not necessarily a good thing. 17:43
cotto_work Coke: that's a significant concern.
Coke (though you can report bugs anonymously via email, which is nice.)
cotto_work if only trac didn't format such messages so uselessly 17:44
17:46 theory joined
Coke cotto_work: easy to fix, just wrap in {{{}}} 17:46
17:53 kid51 joined
whiteknight plobsing: fixing the pointer-related PMC fiasco would definitely be a good thing 17:53
hardly high priority enough to end up on the roadmap however
if somebody can put together a nice design for a replacement, that would be a great first step
nopaste "kid51" at 192.168.1.3 pasted "generational_gc: failures in t/pmc/key.t" (15 lines) at nopaste.snit.ch/31037 17:55
17:55 kid51 left
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?
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.
whiteknight ah, I missed that part
okay
power to you
plobsing none of the pointer types currently built in provide all of the functionality I want
and the last thing I want to do is compound the problem by creating yet another custom purpose struct-pointer PMC type.
whiteknight managedstruct, unmanagedstruct, pointer, and mappedbytearray can probably all be merged together without too much hassle 17:57
I think there's benefit in keeping nci as a separate type, however
maybe that's just me
plobsing whiteknight: it should also inherit properly to indicate that it is just another pointer 17:59
it can skin on top of that as much as it likes
whiteknight okay, I see what you are saying
yes, I'm in favor of that
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
pointer is completely useless. I think it's only used inside PCC
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:02
but pointer has a bunch of flat out stupid functionality attached 18:03
cotto_work plobsing: how close is this to 6model?
plobsing Pointer.get_string == segfault me harder
cotto_work: quite possibly fairly close. they overlap in some areas. but 6model is much bigger than what I want. 18:04
and will probably take much longer to land
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
cotto_work sure. I was just noticing that this sounds like a subset of that.
plobsing if I do things right, 6model could be implemented somewhat in terms of this 18:05
whiteknight do it right
:)
plobsing whiteknight: I'm always right ;) 18:06
but sometimes the rest of the world is wrong ;(
whiteknight well that's reassuring. Now we know that this project is in the correct hands :) 18:11
18:14 contingencyplan joined
whiteknight ripping out crufty old code and replacing it with new and good things is very fun 18:15
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
cotto_work dukeleto: dairy farming and interstellar travel? 18:28
18:28 nwellnhof joined
dukeleto cotto_work: that too 18:29
i have at least 5 talk ideas to submit
I really hope they don't accept them all
cotto_work: would you be interested in doing some kind of "Parrot for Beginners" talk together? 18:30
cotto_work: i am not sure they allow that, but i don't like following rules anyway
whiteknight "Parrot 4 t3h n00bz"
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.
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.
dalek rrot/whiteknight/imcc_compreg_pmc: e7ac3d3 | Whiteknight++ | / (2 files):
remove a hack to support IMCC the old way
rrot/whiteknight/imcc_compreg_pmc: 83b1708 | Whiteknight++ | / (4 files):
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.
rrot/whiteknight/imcc_compreg_pmc: db1fa87 | Whiteknight++ | / (6 files):
many changes to the new IMCC API. We're building again and doing about as well on the test suite as we were
cotto_work PL/Perl6 is pretty cool.
dukeleto needs to make it work again on modern stuff.
whiteknight sorry, I had to push to get work off this infernal VM
dukeleto also needs to setup CI for it, so this junk doesn't happen again 18:33
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
*native
whiteknight we used to do that. The pmc->data field used to be used for other things 18:40
that raised hell with inheritance and subclassing for instance. Plus it made the allocator complicated as hell 18:42
adding a new field to every PMC header might be expensive
although we could use a flag and have "extended" PMC headers which contain a few more optional fields when needed
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.
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.
btw, the inital gc_ms2 implementation added two words to every PMC header. now it's down to one. 18:47
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?
nwellnhof prev/next for a linked list 18:49
whiteknight right, okay
benabik Although I suppose it could rely on something that uses morph and I wouldn't be wiser.
whiteknight unlikely. Very few things use morph because it isn't consistently implemented throughout the codebase 18:51
CallContext.morph, as an example I learned about recently, doesn't morph at all. It acts like a clear/reset 18:52
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
and NQP too
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.
whiteknight thank you!
yes, that's exactly what should happen
murdered with a sharp stick 18:54
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.
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
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.
lucian i've been thinking about gobject lately 18:58
benabik dukeleto: I don't see any use of morph in NQP, actually.
whiteknight I strongly suspect it isn't used 18:59
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
and without morph, We can add some non-trivial optimizations to the PMC allocator
dukeleto i am +1 to removing the morph vtable with a few, more-specific, vtables 19:00
which hopefully will be much easier to optimize
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.
dukeleto: I wasn't, but I'm pretty fast with ack and git-grep. :-D
nwellnhof a VM for dynamic languages should have the ability to change the types of object dynamically.
dukeleto benabik: as long as we deprecated appropriately, there should be an issue
nwellnhof: i agree. I just think the morph vtable is a bad design decision to get that feature
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
dukeleto s/should/shouldn't/g 19:02
benabik: rakudo is almost always amenable to "here, we made this less broken, please use the new shiny"
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?
whiteknight at the moment
benabik :-/
whiteknight a Class.map method might be a better alternative 19:04
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
benabik So a C-ish "x = (int) float_var" is "x = float_var; x.morph(int)"?
whiteknight more or less 19:05
nwellnhof what i'm talking about is essentially smalltalk's "become"
NotFound C is not a bad example for morphing-alike things.
whiteknight nwellnhof: yeah, I suspect that's the primary inspiration behind our morph situation
NotFound I mean, *is* a bad
19:06 plobsing joined
benabik NotFound: I meant C-ish more for the syntax than anything else. 19:06
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
you would need to add a per-class routine to handle mapping, and maybe per-class classes of mapper objects
it could all get out of control very quicklt
quickly
NotFound IMO is more problem when you morph objects that maybe other parts are using for its own purposes
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
THAT would be quite nifty
lucian whiteknight: i don't think that can be solved generally 19:09
dukeleto whiteknight: that seems like a white whale right now
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_.
dukeleto whiteknight: i would love to see it, but i think we might want to focus on baby steps for now
whiteknight right, that's my point 19:10
dukeleto whiteknight: with that end goal in mind
plobsing become has nothing to do with the types in question. it should be implemented by the GC.
in fact, IIRC, rakudo already does something similar manually in the binder
(it's really ugly)
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
benabik (Assuming there's enough memory at the destination, which might be an issue, I'll admit.)
lucian i think morphing objects is a hard problem that can be solved with copying very quickly and inefficiently
plobsing benabik: (at a simplified level) become should swap the vtable and the data pointers in the PMC pointer. 19:12
no need to switch all instances
all instances point to the same header 19:13
benabik plobsing: Right. That's about what I meant. :-)
lucian plobsing: won't vtable functions operate that operate on instance data possibly break? (i may be misunderstanding pmcs)
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:14
lucian plobsing are PMC1 and PMC2 instances? 19:15
whiteknight and the flags
actually, not all the flags, only the ones which are tied to the type
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.
whiteknight NotFound: yes, that's something that we should probably fix eventually
plobsing lucian: yes, PMC1 and PMC2 are instances of some type. I fail to see how that changes things.
lucian plobsing: it doesn't. i thought you meant swapping the properties of the types
plobsing types are instances too 19:17
lucian sure, but don't instances point to their type?
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
same problem if you swap objects in under a type constraint. all of a sudden, then constraint is violated after the check.
whiteknight These are all reasons why I think in-place morphing is a bad idea 19:19
lucian i see
i don't think hlls should have to deal with this
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
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
dukeleto what are the implications of morph to our future JIT ?
lucian plobsing: but is this particular stapler very useful?
whiteknight we're hurting people who aren't even using morph
lucian why not just copy? 19:21
plobsing lucian: you *CAN'T* fully implement smalltalk without it.
lucian: one use case is transparent lazy types
lucian plobsing: i don't know smalltalk all that well, but i don't see how morphing can't be done with copying
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
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.
whiteknight in that case, the PMC* header should be much thinner, and should point to an attributes structure which contains the vtable too
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.
Coke (getting rid of morph) how will you swap out vtables, then?
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.
whiteknight plobsing: in Smalltalk, is becomes a common operation? That is, should it be fast or can it be slow? 19:25
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.
plobsing if you morph/become and it breaks, you get to keep both halves
whiteknight Coke: we're not planning anything yet
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
nwellnhof lucian: i'm not sure if i understand your question but you need at least one level of indirection.
whiteknight Coke: We *are* discussing it, but we're not planning it
Coke I can see where folks reading backscroll might not realize that.
k.
19:28 jan left
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
nwellnhof lucian: one indirection is enough
NotFound plobsing: Who many people in earth understand Smalltalk? ;)
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.
NotFound S/Who/How
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
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
NotFound So become became a different thing?
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
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
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?
whiteknight plobsing: because the two types might have different sized attributes structures 19:31
if we don't at least resize the attributes structure, we're basically creating a segfault engine
plobsing NotFound: if the interblags are to be beleived, most every Ruby hacker (despite the fact that they don't program in SmallTalk)
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.
whiteknight plobsing: oh, that's very different from morph then.
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.
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.
whiteknight plobsing: I'm far less concerned about that point than I am concerned about the ramifications for the internal implementation
I would be perfectly happy providing a becomes operation for Parrot 19:34
but our current in-place morph routine is really...bad
NotFound Don't even talk about pmc_reuse
plobsing I agree morph is LTA.
whiteknight NotFound: no, pmc_reuse is terrible also 19:35
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
PMC header can come out of a small header slab, the guts can be moved around the system to wherever
plobsing don't we already do that? 19:39
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?
nwellnhof whiteknight: a real compacting GC also has to compact the PMC headers
whiteknight the PMC header would really need to be much lighter, like a single pointer, for that to really be a benefit
the alternative is to add in some pretty invasive read barriers to update references on the fly 19:41
bacek ~~
nwellnhof plobsing: we do that with strings currently, PMC attributes are never copied/compacted
bacek Good morning, humans.
dukeleto bacek: i submitted a bunch of smoke reports for gen_gc on darwin. t/pmc/key.t had some failures
bacek: also, top of the morning, meatbag
bacek dukeleto, gen_gc is wrong. There is major problem with handling of dirty_list. 19:42
whiteknight bacek: another problem? 19:44
bacek whiteknight, yes
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.
bacek plobsing, yes. But ops2c doesn't parse op body.
dukeleto maybe it should. 19:46
bacek plobsing, which means I can't emit different code for $1, etc.
dukeleto, I don't want to implement good half of C parser.
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
(not parsing C)
bacek plobsing, yes. But accessors are always same - $n
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
it already makes different output based on these signatures
bacek plobsing, oh. I did implement parsing of op body.
plobsing 'in INT' vs 'in STR'. they get translated to different C code (obviously)
bacek so yes. We can emit different code for in vs inout agrs 19:49
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
dalek rrot/generational_gc: 973a7ff | bacek++ | src/gc/gc_gms.c:
Explanation about flaw in GC algorithm.
 19:54
bacek plobsing, yes. I can work on it. Later. After fixing main algo.
whiteknight, github.com/parrot/parrot/commit/973a7ff94d
luben NotFound, hash does not backpoint to PMC anymore
NotFound luben: glad to hear that 19:55
whiteknight bacek: ouch 19:56
bacek: Are we going to need to compile inter-generational pointer lists?
dalek rrot/generational_gc: 1205bb4 | bacek++ | src/gc/gc_gms.c:
Move "constant" objects into next generations.
 19:57
rrot/generational_gc: 7683330 | bacek++ | src/gc/gc_gms.c:
Limit number of generations to 2 to workaround bug in algo.
bacek whiteknight, I'm thinking about how to fix it...
NotFound Note that ops files lack a revision about the validity of the signatures. I've see invar being modified more than one time.
ttbot Parrot 1205bb45 i386-linux-thread-multi make error 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
dukeleto plobsing: +1 to that
NotFound plobsing: that will be great.
plobsing otherwise the annotations are useless and good luck trying to do lifetime analysis for eg: a register allocator 20:00
bacek plobsing, changing way of handling in vs inout regs will be great. 20:02
20:02 theory left 20:07 lucian left 20:09 lucian joined
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:11
plobsing arnsholt: suggests that PBC_COMPAT should have been bumped some time in the past but was not 20:12
the solution is to recompile
nopaste "bacek" at 192.168.1.3 pasted "Updated patch for rakudo" (86 lines) at nopaste.snit.ch/31060
bacek msg moritz "bacek" at 192.168.1.3 pasted "Updated patch for rakudo" (86 lines) at nopaste.snit.ch/31060
aloha OK. I'll deliver the message.
whiteknight bacek: Does that gc write barrier function exist in master? 20:14
bacek whiteknight, function - no, macro - yes.
whiteknight bacek: okay, I'm just trying to make sure the merge goes smoothly 20:15
moritz bacek: does it build now?
bacek moritz, yes. On my box.
moritz I'll try it here
dalek rrot/generational_gc: 09bae79 | bacek++ | src/gc/gc_gms.c:
Tune the Moon: use 1/100 of available memory for gc_threshold
 20:16
bacek Why MMD_Cache is hash, not Hash PMC? 20:19
cotto_work bacek: have you added a noop write barrier to trunk? 20:21
whiteknight bacek better performance, right?
cotto_work: yes, he says it's a macro in master
cotto_work ok. I'm behind on code review. 20:22
bacek cotto_work, I forgot to add function definition...
20:22 whiteknight left, whiteknight joined
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.
bacek moritz, make spectest fails (not epically)
tadzik heh, will there be generational_gc_dynamic_treshold one day? :) 20:24
moritz bacek: compiling core.pm segfaults here
bacek cotto_work, I'll fix it tonight.
moritz, can you get backtrace from gdb?
moritz, and you should use "bleeding edge" version of branch 20:25
moritz bacek: when my daughter stops screaming, I'll try
bacek moritz, ok.
moritz, how old is she? 20:26
moritz rakudo: say DateTime.today - DateTime.new('2011-01-14), ' days'
p6eval rakudo 03380c: OUTPUT«===SORRY!===␤Unable to parse postcircumfix:sym<( )>, couldn't find final ')' at line 22␤»
moritz rakudo: say Date.today - Date.new('2011-01-14'), ' days'
p6eval rakudo 03380c: OUTPUT«26 days␤» 20:27
bacek moritz, wow. Congratulations! :)
moritz bacek: thanks
that's on RELEASE_3_0_0-845-g7683330
tadzik LTA error message btw :) 20:28
bacek moritz, my git-fu is weak. How I can get this tag? 20:29
moritz bacek: git describe --tags
bacek RELEASE_3_0_0-846-g09bae79
moritz
.oO( the git foo is weak in this one... )
 20:30
moritz pulls again
benabik BTW: That means RELEASE_3_0_0 tag + 846 commits, current rev is 09bae79.
bacek moritz, unlikely that it will help.
moritz bacek: hasn't segfaulted yet, still compiling core.pm 20:35
20:35 nwellnhof left
bacek moritz, optimized build? 20:35
dalek rrot/generational_gc: a7d4bdc | bacek++ | include/parrot/context.h:
Disable shortcuts for setting CallContext fields. We do need write barriers.
 20:36
moritz bacek: yes 20:37
bacek: build succeeds, about a third of the spectests returns errors 20:38
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
TT #2003: trac.parrot.org/parrot/ticket/2003
20:42 benabik left 20:48 lucian left, lucian joined 20:53 vmspb left 20:55 plobsing left 21:00 plobsing joined
dalek rrot/generational_gc: d9497e3 | bacek++ | src/embed/api.c:
Apply patch from nwellnhof++ to disable GC during Packfile loading. Wallpapering problems ftw.
 21:01
whiteknight what is the real problem there with packfile loading?
why are we having to apply this wallpapering?
bacek whiteknight, because it's creating PackFile_* structs. Which aren't handled during GC. 21:02
For example, unpacked Sub PMC will be collected.
Etc, etc, etc
We can remove this workaround after switching to PMCs internally, 21:03
Actually, we can create GSoC task - switch parrot internals to use PMCs only.
MMD_Cache, Packfiles, etc.
I suspect there is a _lot_ of places where we can simplify and improve things. 21:04
21:04 perlite_ joined
bacek afk # dayjob 21:05
whiteknight bacek: plobsing is doing that right now 21:06
no GSoC project needed
21:08 perlite left, perlite_ is now known as perlite, theory joined
plobsing whiteknight: well I'm not doing that immediately. a few more yacks to shave. but it is my goal. 21:14
whiteknight plobsing: I can't keep track. I'm a poor Yak herder 21:15
we need a little status feed, so we can see what developers are working on right now 21:16
"plobsing current status: GCable packfiles in IMCC"
"whiteknight current status: MURDER IMCC"
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:17
people reading that page might get the wrong idea about that 21:19
cotto_work plobsing: good idea 21:20
whiteknight yes, that probably is a good idea 21:24
we would accept it if it was high quality and was compatible with Lorito
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
NotFound And now... winxed C++ backend first steps: github.com/NotFound/winxedxx
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.
because there are people who work like that (rare as they may be)
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:27
atrodo I agree, the JIT is a task that needs Lorito figured out before someone can reasonably be able to work on it 21:28
cotto_work volunteers? 21:29
dalek tracwiki: v24 | plobsing++ | BigProjectIdeas
tracwiki: Remove JIT-related tasks. Adding a new JIT for the current system is not desirable. Lorito is the future.
tracwiki: trac.parrot.org/parrot/wiki/BigProj...ction=diff
cotto_work or that
21:30 whiteknight left 21:40 adu joined
dalek tracwiki: v25 | whiteknight++ | BigProjectIdeas 21:45
tracwiki: remove generational GC. We're doing that in-house
tracwiki: trac.parrot.org/parrot/wiki/BigProj...ction=diff
21:47 fperrad left
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:48
but that's a project policy decision. 21:49
Tene What was his objection?
NotFound We shouldn't do that without a deprecation period. 21:50
plobsing All I remember is "DO NOT WANT"
NotFound Lots of code depend on the text of the error messages.
21:59 wknight-phone joined 22:04 rurban_ joined 22:07 rurban left, rurban_ is now known as rurban
cotto_work msg whiteknight What was the GObject metamodel entry on BigProjectIdeas about? 22:14
aloha OK. I'll deliver the message.
bacek_at_work cotto_work, probably from GNOME 22:15
cotto_work sure, but I'm curious why he picked that. 22:17
maybe just because it was a C-based object model
bacek_at_work probably 22:18
"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."
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.
bacek_at_work I don't particularly like it...
And 6model is little bit more preferable. 22:19
cotto_work It'd be helpful for all the gui code we have in Parrot.
bacek_at_work we can implement GObject on top of 6model (I think) 22:21
22:27 wknight-phone left 22:29 Andy left 22:33 theory left
dalek rrot/generational_gc: 016bd2c | bacek++ | src/call/context.c:
Fix get_PMC_get assert to skip NULLs.
 22:51
22:59 cosimo joined 23:06 cosimo left, cosimo joined
Coke (signal/events) absolutely need a decent event loop to handle tcl. 23:10
23:25 plobsing left 23:26 dmalcolm left 23:28 bacek left, plobsing joined 23:29 theory joined
plobsing if we aren't able to host GObject on top of 6model, I'd call that a failure 23:33
23:45 plobsing left
dukeleto sounds like a good litmus test to me 23:46
cotto_work The only problem is finding someone interested in Parrot who knows GObject and wants to implement a 6model version. 23:55
but it'd be an interesting test case

Powered by Cro and the Raku® Programming Language.

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

Thank you!