Parrot 2.4.0 "Sulfur Crest" Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | GSOC Students: trac.parrot.org/parrot/wiki/GSoCersStartHere
Set by moderator on 7 June 2010.
tcurtis How have you been? 00:00
whiteknight chromatic is neither good nor bad. he is precisely how he intends to be 00:01
darbelo What if he intends to be bad?
chromatic I'm chaotic awesome.
tcurtis wishes he had known that was an option. 00:02
chromatic Don't worry about it. Rerolling is hard. 00:03
00:10 GeJ joined
dalek rrot: r47440 | darbelo++ | branches/gsoc_nfg/src/string (2 files):
Clone the grapheme table when cloning the string.
 00:11
rrot: r47441 | darbelo++ | branches/gsoc_nfg/src/string (2 files):
Move a TODO to the place where the fix would go.
rrot: r47442 | darbelo++ | branches/gsoc_nfg/src (3 files):
Destroy the grapheme table when releasing the string header for collection.
rrot: r47443 | darbelo++ | branches/gsoc_nfg/src/string/grapheme.c:
Whitespace police.
purl ALL TAB STOPS AT 8 COLUMNS. LINE UP ENCLOSING BRACES. EVERY COMMA HAS A SPACE AFTER IT. AND THIS MEANS *YOU*, BOY!
ash_ was the 'restrict' keyword added in c99?
sorear yes
tcurtis Do you know if a video and/or transcript of your talk at OSBridge will be posted somewhere? It sounds interesting and might finally motivate me to actually try coding something beyond "Hello, world" in Perl 5. Also, is there any time in the next few days you have free for us to meet and discuss how my project has gone so far? 00:12
chromatic There's audio, but if you read modernperlbooks.com and skim the book in progress on GitHub, you'll know most of it already. 00:13
I can talk some tomorrow before or after #ps too. 00:14
GeJ Good morning again.
darbelo Good tomorrow morning, GeJ.
ash_ what time is #ps? 00:15
cotto_work parrotsketch?
purl parrotsketch is a status meeting for parrot core committers held every Tuesday at 20:30 UTC in #parrotsketch
ash_ is utc the same thing as gmt? I never understand time zones... 00:18
darbelo ash_: Yeah, except when it isnt. 00:20
ash_ sweet, now i get to be more confused
:p 00:21
darbelo GMT can move in the summer. UTC can't.
most of the time UTC == GMT. UTC is the one you want.
cotto_work date --utc will tell you what utc time it is
Tue Jun 8 00:21:59 UTC 2010 00:22
darbelo ... Okay, I need to adjust my clock. 00:23
Tue Jun 8 00:22:45 UTC 2010
cotto_work looks only a little inaccurate
darbelo Amusingly, my local time shows fine. So myt tz must be wrong too. 00:24
cotto_work I'm not seeing the problem. utc should be the same everywhere. That's the point. 00:25
ash_ during this last semester i had to setup a server for a sys admin class and there was some problem with the hardware, it wouldn't keep the date settings between boots, so every time i booted it said half the files were last modified to far in the future since it reset the date to 1904
00:26 tcurtis joined
darbelo But how could such a sane default as 1904 ever go wrong? 00:27
ash_ well it was a ppc from 2004, so... i see the connection, sorta 00:28
darbelo When in doubt, travel back in time 100 years. 00:29
tcurtis chromatic: Is it okay if I tell you whether it would be better for me to talk before or after #ps later tonight? I may be away from my computer for either most of the morning and afternoon prior to #ps or for much of the evening following it, and I won't know until a few hours from now which will be the case. 00:30
ash_ because there were totally computers in 1904
i mean who else was managing when the light bulbs were on?
chromatic That's fine, tcurtis. 00:33
sorear ash_: if you upgrade it to OSX, it will jump to 1970 00:36
ash_ OS X's date doesn't take --utc btw 00:38
darbelo try -u
ash_ ah that did it
darbelo It's probably a BSD derivative, insteda of the GNU one. 00:39
ash_ was reading the man pages for it, hadn't found -u yet
dalek rrot: r47444 | darbelo++ | branches/gsoc_nfg/src (2 files):
Fix non-icu builds. Again.
 00:43
01:00 abqar joined 01:12 jsut joined
ash_ so... the root.in makefile, can you check if something is not defined? 01:16
i see #IF() used, #UNLESS() is the opposite right?
01:23 jsut_ joined
kid51 ash_: yes, see config/gen/makefiles/root.in 01:28
ash_ i am looking at it now, thanks kid51 01:29
01:57 TiMBuS joined, plobsing joined 02:29 gbacon joined 02:31 theory joined 02:45 s1n joined 02:53 s1n joined 02:55 s1n joined 03:00 khairul joined 03:02 s1n joined 03:07 Andy joined
dalek rrot: r47445 | khairul++ | branches/gsoc_instrument (4 files):
Made codetest mostly happy, exposed data attribute of task pmc.
 03:13
cotto Do we have a generic linked list implementation somewhere in Parrot? It seems that the structure gets some use. 03:17
dalek kudo: 0290298 | (Solomon Foster)++ | src/core/Cool-num.pm:
Clean up the Cool versions of the standard Numeric and Real methods.
 03:18
kudo: 34c1ba4 | (Solomon Foster)++ | t/spectest.data:
Turn on new S32-num/cool-num.t test file.
chromatic Not to my knowledge.
khairul hi cotto 03:19
cotto hi khairul 03:20
khairul wanna have that meeting now? 03:21
cotto wfm
dukeleto 'ello 03:40
bacek_at_work cotto, src/gc/list.{h,c} in gc_massacre branch 03:41
cotto but that won't be merged for a while, will it?
03:42 LoganLK joined
dukeleto cotto: a linked list structure would be nice 03:42
chromatic bacek_at_work, does that branch need profiling and tuning? 03:43
cotto bacek_at_work, can you move the code into a more generic place so it can be used once the branch is merged? 03:44
03:45 janus joined
cotto also, what's the eta on the merge (if it's foreseeable)? 03:45
nm. bacek_at_work, do you mind if I make the linked list code more generic? 03:49
bacek_at_work chromatic, a lot. Especially "gc triggering" situation. 03:50
cotto, go for it. 03:51
dalek rrot: r47446 | plobsing++ | trunk/t (2 files):
avoid dynops in one io test and move another to a dynops test
 04:02
tcurtis chromatic: Talking before #ps would be better for me. 04:13
dalek rrot: r47447 | plobsing++ | trunk/t (2 files):
avoid dynop use in 1 io test, move another to dynop tests.
 04:18
cotto stdout? nobody ever writes to that. 04:23
04:35 integral joined
dalek rrot: r47448 | plobsing++ | trunk/t/pmc/io.t:
fix a few more io coretests, converting PASM to PIR at the same time
 04:36
04:51 tcurtis_ joined 05:13 eternaleye joined
cotto bacek_at_work, howcome LIST_APPEND and LIST_REMOVE are macros? Is there really that much of a speed improvement? 05:21
dalek rrot: r47449 | plobsing++ | trunk/t (2 files):
move io tests away from dynops and PASM towards methods and PIR
 05:26
bacek_at_work cotto, they are in hot path in GC 05:32
poor-man templates...
cotto wfm then 05:34
dalek rrot: r47450 | tcurtis++ | branches/gsoc_past_optimization (2 files):
Refactor the way matching works and hopefully implement capturing attributes and children of the matched nodes(this part isn't yet tested).
 05:43
05:45 jan joined 06:11 uniejo joined
dalek rrot: r47451 | plobsing++ | trunk (2 files):
more io coretest dynop => method conversion
 06:16
rrot: r47452 | plobsing++ | trunk/t (2 files):
move stat test to dynop tests and avoid getstderr dynop in another test
 06:32
bacek_at_work plobsing, ping. 06:35
plobsing, I did move getstd* ops back to core in r47392 (temporary) 06:36
plobsing bacek_at_work: hmmm... that's news to me 06:37
probably better off this way anyways 06:38
bacek_at_work plobsing, it was quicker than implementing methods on FileHandle/Interpeter 06:39
plobsing what's wrong with stdhandle? 06:40
06:42 aukjan joined
bacek_at_work plobsing, nothing actually. 06:45
plobsing so there wouldn't be objections if I moved them back to dynops after converting all core instances to method calls? 06:47
(not that that is particularily high in my priorities) 06:48
chromatic Seems like busy work to me. 06:49
plobsing which is why its at the bottom of my list
06:53 aukjan joined
bacek_at_work plobsing, we still need reliable way to get stderr/stdlog handled. 06:53
handlers
purl handlers are neato
plobsing fair enough. if this works, it's not worth arguing over. 06:54
cotto testing gc_massacre makes my lappy sad 07:20
dalek rrot: r47453 | cotto++ | branches/gc_massacre (5 files):
[list] move linked list code out of gc (function renaming still to come)
 07:22
07:25 jsut joined
chromatic It's difficult to create a local branch tracking the gc_massacre branch when you always spell it gcc_massacre. 07:30
Apparently I secretly root for clang.
cotto having 'make' eat my ram and make my computer nearly unusable for a minute is really good training for using corevm. 07:33
corevm++
also, sed++ for doing most of my editing for me 07:34
dalek rrot: r47454 | cotto++ | branches/gc_massacre (5 files):
[list] function renaming to make the list code look more separate from gc
 07:38
chromatic You're not kidding about eating RAM. 07:40
cotto The code needs love and tries to fill the void by eating memory. 07:44
chromatic Just like me and pie.
Part of the slowdown on gc_massacre (8.91% of runtime) is gc_ms2_free_fixed_size_storage() and gc_ms2_free_pmc_attributes() eventually calling free(). 07:48
25% of the runtime is the use of the corresponding malloc()s.
If you want a 33% speedup, it's pool time. 07:49
bacek_at_work, ping
cotto headerizer++
moritz I thought bacek_at_work wanted to remove the pools? 07:51
chromatic Removing the pools is fine, as long as we don't replace them with the system malloc/free, which appears to manage free lists with some sort of cloud-based serializationn. 07:52
As in SMOKE SIGNALS
moritz with what else could they be replaced? a custom malloc?
chromatic Those are the two options, a custom malloc or pools. 07:53
(and a custom malloc may indeed use pools anyway)
The good news is that we can get faster than trunk by ~8-10% if we use a better strategy there. 07:54
dalek rrot: r47455 | cotto++ | branches/gc_massacre (2 files):
fix and rerun headerizer
rrot: r47456 | chromatic++ | branches/gc_massacre/config/gen/makefiles/root.in:
[config] Added root Makefile deps for src/list.c.
rrot: r47457 | cotto++ | branches/gc_massacre (2 files):
[list] change int return type to INTVAL, add PARROT_EXPORT, reheaderize
 07:55
moritz chromatic: so how are pools managed in trunk, if not by a malloc-like routine?
chromatic It's basically a malloc-like routine. 07:56
You should have heard me trying to answer the question "Does Parrot use the stack?" in a BOF last week.
moritz "yes, but not like you think it does"?
chromatic I'm trying to figure out how much I can lie to you to answer your question honestly.
moritz let me rephrase my question 07:57
in trunk, we have pools managed by a malloc-like routine
in the branch, you want pools managed by a malloc-like routine 07:58
what's the big difference? "just" the internal management of those pools?
chromatic Yeah.
From the point of view of using these routines, the interface is "I want some free memory of size n" and "I'm done with this memory, so recycle it." 07:59
The GC could malloc a pool of m items of size n, or it could call malloc() for each item. 08:00
moritz or it could re-use an existing pool, if applicable
chromatic Exactly.
moritz \\o/ I'm just as dumb as I look, not more :-) 08:01
bacek pong 08:02
chromatic I profiled the slowness of gc_massacre. 08:03
bacek chromatic, there is todo list on GCMassacre wiki. PMC_Allocator is first priority.
chromatic Okay, good.
There's little reason to profile much until after that point. 08:04
bacek actually after StringPool
Which is second priority :) 08:05
chromatic The existing hotspots are too hot to get good information on anything else. 08:06
bacek strings are currently using same malloc/free. 08:07
chromatic I only used the fib.pir benchmark; that's all integers. 08:08
bacek I did test it on examples/benchmarks/stress_strings.t 08:10
And added similar stress_integers
dalek rrot: r47458 | mikehh++ | trunk/t/dynoplibs/io.t:
fix codetest failure - trailing whitespace
 08:11
mikehh make corevm/coretest has 1/4 failure(s) remaining - t/pmc/io.t - Failed tests: 25, 27, 29, 31 08:16
all subtests fail with - error:imcc:loadlib directive could not find library `io_ops' 08:17
08:18 preflex joined
mikehh make test PASS 08:20
make corevm/make coretest - t/pmc/io.t - Failed tests: 25, 27, 29, 31 08:52
t/compilers/imcc/syn/clash.t - Failed test: 13 in testr see: nopaste.snit.ch/20983
all other tests PASS (pre/post-config, make corevm/make coretest, smoke (#34251), fulltest) at r47458 - Ubuntu 10.04 amd64 (g++)
t/op/annotate-old.t - TODO passed: 1 in testf
09:07 dalek joined 09:43 dngor joined 10:44 clinton joined 10:59 Myhrlin_ joined 11:00 whiteknight joined 11:21 cognominal joined
mikehh make corevm/make coretest - t/pmc/io.t - Failed tests: 25, 27, 29, 31 11:36
t/compilers/imcc/syn/clash.t - Failed test: 13 in testr see: nopaste.snit.ch/20983
all other tests PASS (pre/post-config, make corevm/make coretest, smoke (#34254), fulltest) at r47458 - Ubuntu 10.04 amd64 (g++ with --optimize)
t/op/annotate-old.t - TODO passed: 1 in testf
11:43 ruoso joined
bacek *incoming* 11:47
dalek rrot: r47459 | bacek++ | branches/gc_massacre/src/gc/pool_allocator.c:
Comment-out assert in PoolAllocator.free. It's way too heavy even for debug builds
 11:51
rrot: r47460 | bacek++ | branches/gc_massacre (3 files):
Add skeleton for Fixed_Allocator.
rrot: r47461 | bacek++ | branches/gc_massacre/src/gc (2 files):
Implement Fixed_Allocator (not tested)
rrot: r47462 | bacek++ | branches/gc_massacre/src/gc/gc_ms2.c:
Use Fixed_Allocator for allocating fixed size storage.
rrot: r47463 | bacek++ | branches/gc_massacre/src/gc/pool_allocator.c:
Fully initialize Pool_Allocator
rrot: r47464 | bacek++ | branches/gc_massacre/src/gc/gc_ms2.c:
Use Fixed_Allocator for PMC Attributes.
mikehh rakudo (e3153ad) builds on parrot r47458 - make test PASS, spectest_smolder -> #34257 (pugs r31179) PASS - Ubuntu 10.04 amd64 (g++ with --optimize) 12:04
19 TODO PASSes in 4 files
moritz does the parrot NCI support any form of callbacks? 12:12
bacek moritz, unlikely 12:18
moritz will the future NCI support it?
it would be extremely useful for wrapping GUI toolkits, for example
arnsholt I'd go so far as to say callbacks are necessary for GUI toolkits 12:19
bacek moritz, no idea... It's one dark parrot's sides for me 12:21
moritz as opposed to the bright GC? :-) 12:22
bacek purl, (2332524536 - 2837195584) / 2332524536 * 100
purl -21.6362589207936
bacek moritz, no... GC is even darker
That's why I'm implementing new GC with blackjack and hookers! :) 12:23
dalek rrot: r47465 | mikehh++ | branches/gc_massacre/MANIFEST:
re-generate MANIFEST
 12:24
rrot: r47466 | bacek++ | branches/gc_massacre (56 files):
Merge branch 'master' into gc_massacre
rrot: r47467 | mikehh++ | branches/gc_massacre/src/gc (2 files):
add svn properties
bacek msg chromatic It's still slow. We can merge fixed_allocator.{c,h} and pool_allocator.{c,h} and use common static functions to avoid function calls. 12:30
purl Message for chromatic stored.
bacek msg chromatic ... and probably swap their names... 12:32
purl Message for chromatic stored.
mikehh bacek: will it mees you up if I add ASSERT_ARGS to src/gc/fixed_allocator.c 12:36
mess
bacek mikehh, go ahead
mikehh bacek: gc_massacre branch codetest is passing except for c++ comments :-} 12:44
bacek :)
dalek rrot: r47468 | mikehh++ | branches/gc_massacre/src/gc/fixed_allocator.c:
add ASSERT_ARGS and fix line length
 12:56
13:01 whiteknight joined
whiteknight good morning, #parrot 13:03
Coke morning. 13:06
whiteknight hello Coke, how are you today? 13:07
dalek nxed: r490 | julian.notfound++ | trunk/examples/ajax.winxed:
improve example ajax
 13:10
13:10 cognominal joined 13:11 atrodo joined 13:41 JimmyZ joined 13:49 gbacon joined, whiteknight joined 13:54 lucian joined
Coke whiteknight: not bad, althoguh I am frustrated with this work project. it's interesting, but the research is taking too long. =) 14:07
you?
purl you is a wave
14:07 plobsing joined
dalek rrot: r47469 | bacek++ | branches/gc_massacre (8 files):
Merge pool_allocator and fixed_allocator files
 14:19
rrot: r47470 | bacek++ | branches/gc_massacre/src/gc (4 files):
Rename PoolAllocator functions and made them consistent in accepting interp
rrot: r47471 | bacek++ | branches/gc_massacre/src/gc (2 files):
Split PoolAllocator methods into public and static part
rrot: r47472 | bacek++ | branches/gc_massacre/src/gc/fixed_allocator.c:
Use static pool functions in Fixed_Allocator
rrot: r47473 | bacek++ | branches/gc_massacre/src/gc/fixed_allocator.c:
Add ASSERT_ARGS
14:35 bubaflub joined 15:36 fperrad joined 15:45 contingencyplan joined 15:46 patspam joined 15:58 theory joined
Coke wants an irc proxy. 16:21
(so I can stay connected from a single server, but just connect to that server to play back everything since the last time I connected with whatever my local client is.
16:22 gbacon joined 16:23 Andy joined
whiteknight Coke, that would be nice 16:26
tewk Coke: search.cpan.org/~hinrik/App-Bondage-0.4.4/
dalek kudo: 7821618 | (Solomon Foster)++ | src/core/Real.pm:
[t/spec] Add "our" to infix:<mod> definition so [mod] works.
 16:32
Coke tewk: nifty. danke. 16:33
whiteknight Oh those crafty perl people.
Coke tewk: I also want parrot_debugger to work. 16:35
Andy This gives me a kick in the ass for the restrict keyword: lbrandy.com/blog/2010/06/you-cant-b...d-compile/ 16:37
16:42 tcurtis joined
Andy In Trac, if I'm logged in, does it somehow indicate that? 16:43
cotto top of the page "logged in as x" 16:44
Andy ok, so I'm not crazy
it's not logging me in
Coke where is HLL::Compiler defined. nqp-rx? 16:46
moritz Coke: yes
src/HLL/Compiler.pm
Coke apparently that .eval() is now eating my CONTROL_RETURN. 16:48
and that is PCT::HLLCompiler's .compile...
s/is/uses/
Coke gets dizzy trying to find things under the covers. 16:49
Andy Is anyone else able to log in to Trac?
Coke Andy: yes. 16:51
Andy i cleared all my cookies, reset PW.
Still no happy.
particle flush browser cache?
try RT 16:52
Coke ISTR andy had problems ages ago getting started on trac.
wonder if this is the same or related bug. 16:53
Andy yeah, me too
Coke (CONTROL_RETURN) it would be most helpful to me if someone could figure out why Partcl::Compiler.eval is eating CONTROL_RETURN exceptions. (that eval isa HLL::Compiler, which in turn seems to use PCT::HLLCompiler, and then it gets into stages, and I get a little lost. 16:55
dalek nxed: r491 | julian.notfound++ | trunk/winxedst (2 files):
predef constants true and false
Andy No longer going thru a proxy, now it's happy. 16:56
Coke Andy: I'm using a proxy here (squid), no worries.
proxy cache, perhaps? 16:57
Andy right 16:58
could be
so my cache seems to be overly aggressive. 16:59
dalek nxed: r492 | julian.notfound++ | trunk/examples/ajax.winxed:
method HEAD and command line options in example ajax
 17:00
cotto_work GOOD MORNING 17:01
purl For you maybe.
Andy well, bah, my squid proxy at home is messing it up, but the work proxy does it right. 17:06
cotto_work nice to see that the build in gc_massacre works now 17:07
bacek++
Coke sighs. I'm going to have to do another bisect to figure out when partcl-nqp died. =| 17:11
17:15 szabgabx joined 17:16 dmalcolm joined 17:21 ambs joined 17:22 ambs joined 17:23 estrabd joined
Coke ambs: ho 17:25
ambs Coke: hellows.
17:26 estrabd joined 17:50 tcurtis_ joined 17:52 estrabd joined 17:54 chromatic joined
dalek tracwiki: v62 | cotto++ | ParrotQuotes 17:54
tracwiki: it's a vicious cycle
tracwiki: trac.parrot.org/parrot/wiki/ParrotQ...ction=diff
chromatic gc_massacre is just a touch faster than my most recent trunk measurement now.
17:54 estrabd joined 17:56 gaz joined
dalek kudo: acecb97 | moritz++ | src/core/Match.pm:
remove some clutter from Match.perl output
 17:59
whiteknight chromatic: awesome. Any faster is welcome faster 18:02
I haven't spoken to bacek today, though I have seen some of his commits. What's the status of that branch? 18:03
chromatic corevm builds for me 18:04
cotto_work coretest still gets stuck on t/op/string_mem.t
the full build seems to work nicely though
chromatic That test hangs for me too. 18:06
make: *** [src/dynoplibs/math_ops.c] Error 1
too few positional arguments: 1 passed, 2 (or more) expected
current instr.: 'parrot;Ops;Trans;C;getop' pc 25824 (compilers/opsc/gen/Ops/Trans.pir:397)
cotto_work Hmmm. nothing like that for me 18:08
18:08 davidfetter joined
cotto_work it does look like runtime/parrot/library/distutils.pbc needs to depend on io_ops though 18:10
tcurtis got his GSoC payment card and welcome package today! 18:17
bubaflub tcurtis: nice! i haven't been home to check my mail yet.
cotto_work I got my not a GSoC payment card today. It comes with not $500.
bubaflub cotto_work: can't forget your not google shwag 18:18
18:26 mikehh joined
Coke pmichaud: can I barter for some of your time? =-) 18:28
pmichaud Coke: very possibly, yes.
mikehh gc_massacre branch - make corevm/make coretest (parallel running) hangs on t/op/string_mem.t, make world ok, make test - grabs all my memory - towards the end 18:30
Coke Trying to figure out why, in partcl-nqp, puts [catch {return}] is printing 0, not 2 (the one failing test). looks like return is throwing a CONTROL_RETURN, but the eval() in catch is eating it.
cotto_work Coke, can you ping that osuosl ticket about a trac/git test site for parrot.org? 18:31
Coke (so the catch sees that as a normal parrot .return() instead.)
pmichaud: let me know if there's something I can help you with. =-) 18:32
pmichaud Coke: will do. I'm fairly booked today, but tomorrow is very likely (and I'll reserve some time for it) 18:33
Coke k. I may figure it out by then, but so far am stymied. 18:34
Tene Coke, I vaguely remember telling you that I'd clean up a lot of the exceptions stuff in PCT, including that. Did I actually say that, that you recall, or am I misremembering? 18:35
chromatic You said that. 18:38
Coke I vaguely remember you working on hll stuff. I don't remember anything recent.
I don't mind if YOU fix my problem. =-)
I think I'm just at the point where I need a really good step through debugger or an svn bisect. 18:39
Tene Okay. Sorry for ignoring this for so long.
Coke cotto_work: pinged it. 18:40
Tene: I only found this bug this week. 18:41
Tene Coke: Well, *something* has been mistreating return exceptions for a long time, and PCT doesn't expose a way to make it not broken.
cotto_work coke, thanks 18:45
Coke Tene: any help you can provide appreciated. 18:48
18:50 Andy_ joined
dukeleto 'ello 18:53
cotto_work 'hi 18:54
#ps in 93 18:57
chromatic Want another 5% performance improvement from gc_massacre? Allocate the pool structs from a fixed-size pool themselves. 19:02
atrodo Anyone know how much work and thought has gone into the design of the embedding interface? 19:13
I'm trying to decide if the problems I'm having are because of me 19:14
PerlJam atrodo: about -->this<-- much.
atrodo PerlJam> So good, sounds like it's not all me 19:19
chromatic There are likely bugs and certainly infelicities. 19:20
whiteknight atrodo: design of the embedding interface is driven by users, and so far we have very very few users
atrodo: if you want something, you can ask or you can submit a patch
chromatic There's a special case of Warnock's dilemma when discussing GC and performance improvements. 19:21
GeJ Bonjour tout le monde.
purl salut tout seul
whiteknight chromatic: no warnock, I just haven't read the gc_massacre code enough to know what you mean 19:22
NotFound atrodo: Problems when trying to improve the design, or when trying to use it? 19:23
atrodo whiteknight> That's what I was guessing, but wasn't real sure
NotFound> Using it. It hasn't been easy for me to use, and I've actually found the easiest way to work with it was to just pass it PIR I create on the fly 19:25
whiteknight Chandon: ping 19:26
tcurtis chromatic: Are you busy at the moment? 19:28
NotFound atrodo: we need use cases to provide, or maybe just document, ways of doing the required things. If you can provide some, will be a great help.
Tene chromatic: what's special re Warnock there? 19:29
dalek rrot: r47474 | tcurtis++ | branches/gsoc_past_optimization (3 files):
Added .from() to PAST::Pattern::Constant. Added tests for matched attributes and children subpatterns($/[0], $<name>, etc.).
 19:32
chromatic tcurtis, I have a few moments free. 19:37
Tene, I think you have to add a special case. People don't respond because they're doubly horrified. 19:38
Tene Ah.
whiteknight GC isn't so bad anymore. I think our collective understanding of it has increased significantly 19:39
There are certainly more people now willing and able to hack on it should the need arise
tcurtis chromatic, shall we talk about my project's status so far now, then?
chromatic Yes, let's do that. 19:40
How much work remains to be able to do simple constant folding of integers? 19:42
tcurtis That was achievable(although inconvenient) starting May 25(see trac.parrot.org/parrot/browser/bran...?rev=46970 ). 19:44
Very little remains to be able to do it using PAST::Pattern. 19:45
chromatic Will it be more convenient now? 19:47
tcurtis Two things left to implement for that: global matching(started working on it last night but ended up refactoring the way match results were created first), and a .transform method that takes a pattern and a sub or PAST::Transformer and uses it to transform the matching subtrees.
Yes.
chromatic Do you have work estimates for those? 19:48
mikehh make corevm/make coretest - t/pmc/io.t - Failed tests: 25, 27, 29, 31 19:49
t/compilers/imcc/syn/clash.t - Failed test: 13 in testr see: nopaste.snit.ch/20983
all other tests PASS (pre/post-config, make corevm/make coretest, smoke (#34261), fulltest) at r47473 - Ubuntu 10.04 i386 (g++)
t/pmc/packfile.t - TODO passed: 34 in coretest, smoke, testb, testf and testr
t/op/annotate-old.t - TODO passed: 1 in testf
t/op/exit.t - TODO passed: 6 in testf
tcurtis Estimates of when I'll have them implemented? The former either tonight or tomorrow, I expect. The latter I think Friday or sooner. It's less certain in part because I haven't yet decided on the best way to implement it. 19:52
19:52 khairul joined, allison joined
chromatic How does that fit with your proposed schedule which I have failed, so far, to find? 19:53
June 7-June 12: implement the pattern matcher using the AST traversal library. 19:54
tcurtis I got ahead early on, which turned out well, because pattern matching has taken longer than expected, but I should still finish implementing it on schedule. 19:56
chromatic How are you choosing what to work on next? 19:58
NotFound allison: ping 20:03
20:03 Psyche^ joined
allison NotFound: pong 20:05
tcurtis In the general sense of whether to work on traversal or matching or integrating transformations with PCT, orc.: I mostly followed the schedule. In the specific sense of what order to implement various parts of pattern matching(for example), partially by starting with the simpler parts(e.g., implementing exact matching of attributes and children before implementing smart matching or implementing matching of a specific node before implementing matching any su
of the node), partially based on what I think might depend on what else(.transform could potentially benefit from global matching, so I'll implement it first), and arbitrarily when there's no particular reason for one to precede the other.
dalek rrot: r47475 | NotFound++ | trunk/t/pmc/packfile.t:
make packfile test 'pack produced same result twice' independant of platform/config and untodo it
NotFound allison: please take a look at TT #1659 20:07
chromatic If I were doing this, I'd order my optimizations from simplest to most complex, then try to get them working straight through.
allison NotFound: ok
20:10 ambs joined
allison NotFound: the patch looks good 20:11
NotFound: did you have another question?
NotFound allison: the question is at the bottom of the last comment.
"I'm not sure if this change can affect some non deprecated feature" 20:12
allison NotFound: whether it affects a non-deprecated feature?
chromatic Can we reliably reuse the CallContext returned from set_args?
NotFound allison: doing two invokes with the same set_args
allison NotFound: since get_results is now called after the invocation is complete, it's safe to remove the reference there 20:13
NotFound: though, I'm not sure manually setting it to NULL is the best way
cotto_work khairul, ping
khairul cotto_work: pong
cotto_work khairul, have you taken a look at bacek++'s linked list code in gc_massacre? 20:14
khairul yea, i have.
saw it during our meeting.
cotto_work is it something that'd work for your purposes too?
or could be made to work
Coke I will likely miss #ps today due to $dayjob
NotFound allison: suggestion welcomed
khairul yup. its similar.
allison NotFound: if it passes all tests now, I'm inclined to say go for it, and we 20:15
'll think about interface later
NotFound Ok
tcurtis I'm not sure if that would have really changed my order of implementing things so far. Essentially any optimization would need most of the things I've implemented so far(PAST::Walker::Dynamic and PAST::Transformer::Dynamic excluded). 20:17
chromatic Okay.
My concern is to make sure that whatever happens, we have something usable -- if incomplete.
How much work is it to document writing an optimization stage, at least after you get this week's work done? 20:18
20:18 smash joined
smash hello everyone 20:18
ambs hello, smash 20:22
tcurtis I could probably do that in the day or two following finishing implementing it. Although I haven't implemented a convenient way to integrate it into a PCT compiler yet. After .transform() is implemented, that and writing example optimizations with it will be my main priorities for the next couple of weeks. 20:23
chromatic I'd like other people to be able to write stages as soon as possible. This'll make you more productive and get more feedback on design issues. 20:24
#ps in 5, please report 20:26
allison tcurtis: pretty much anything that takes one PMC as input and returns another PMC as output can be easily integrated into PCT
tcurtis: it's very generic 20:27
tcurtis I'll write some docs this weekend. 20:28
allison: How easily? I haven't really looked into that part much yet. 20:31
allison tcurtis: I'll pull up a code example for you, it's basically add one "stage" to HLL::Compiler's list, then add method with the name of the new stage 20:32
bubaflub i think we flooded #ps 20:33
chromatic I didn't get your blockers, bubaflub.
darbelo Nor me. 20:34
Tene that's right, you just need a method on the compiler class, and then there are methods to modify the list of stages.
.'add_stage' iirc
$P0.'add_stage'('optimize', 'after' => 'PAST')
is approximately what I remember. 20:35
nopaste "allison" at 192.168.1.3 pasted "An example of an HLL::Compiler stage method for tcurtis" (6 lines) at nopaste.snit.ch/21088 20:36
dalek kudo: 4df5081 | pmichaud++ | docs/release_guide.pod:
Tentative name for June release.
allison tcurtis: that's a method for a stage called 'irt'
pmichaud I've been hoping that we could make the staging less "linear", but never got around to implementing it.
darbelo allison: Will you be staying about after #ps? I have some questions. 20:37
tcurtis In that case, any potential especial PCT integration wouldn't really be necessary(I suppose it might be nice to be able to eventually do $P0.'add_optimization',(someSubOrTransformer), but hardly a priority).
allison tcurtis: in that case, the transformer was written in straight PIR, and registered as a compiler for the language IRT (an intermediate tree form), but you can call any arbitrary code in the stage method
darbelo: yes, I'll be around
darbelo Good to hear.
dalek rrot: r47476 | NotFound++ | trunk (5 files):
clear current context siganture in get_results, TT #1659
 20:38
rrot: r47477 | NotFound++ | trunk/t/pmc/filehandle.t:
untodo filehandle timely destruction test, TT #1659
allison tcurtis: there's no need for a separate method name, it's best to call all of them "stages" in the compiler, and name the stage "optimize" or something like that
mikehh make corevm/make coretest - t/pmc/io.t - Failed tests: 25, 27, 29, 31 20:39
t/compilers/imcc/syn/clash.t - Failed test: 13 in testr
all other tests PASS (pre/post-config, make corevm/make coretest, smoke (#34262), fulltest) at r47475 - Ubuntu 10.04 i386 (gcc with --optimize)
t/op/annotate-old.t - TODO passed: 1 in testf
t/op/exit.t - TODO passed: 6 in testf
tcurtis Can you have multiple stages of the same name, though? 20:40
My idea of the .'add_optimization' method is that you could have just one 'optimize' stage that would run each optimization that you added, possibly with some constraints on order, without require you to have named each of them uniquely. 20:41
s/require/requiring/ 20:42
20:42 luben_k joined
allison tcurtis: you can add one stage named 'optimize' and have it run multiple different blocks of code 20:44
tewk tcurtis: Eventually you are going to want a optimzation pass manager, that I would forsee you just adding the optimization pass manager as a stage to the HLLCompiler.
allison tcurtis: it's really up to you what that stage does 20:45
20:45 dmalcolm joined
Tene tcurtis: that would be a very normal sort of thing to do. 20:45
nopaste "allison" at 192.168.1.3 pasted "A couple of code examples for adding a stage to an HLLCompiler" (6 lines) at nopaste.snit.ch/21089 20:46
Tene allison: don't you want a before or after named param to addstage?
allison Tene: yes, you do, for a particular ordering 20:48
dalek TT #1675 created by dukeleto++: Cannot load perl6.pbc from PIR 20:50
TT #1675: trac.parrot.org/parrot/ticket/1675
moderator Parrot 2.4.0 "Sulfur Crest" Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | GSOC Students: trac.parrot.org/parrot/wiki/GSoCersStartHere | Priorities: fix io_ops mess in corevm/coretest, review and update documentation before release 20:50
bacek aloha, humans 20:56
GeJ G'Day bacek.
chromatic bacek, want another 5% performance improvement from gc_massacre? Allocate the pool structs from a fixed-size pool themselves.
bacek chromatic, really? I don't think that we have _so_ many pool structs... 20:57
nopaste "tcurtis" at 192.168.1.3 pasted "chromatic, an example of how constant folding of Integer add with PAST::Pattern will look once I have .transform()" (11 lines) at nopaste.snit.ch/21091 20:58
chromatic bacek, reviewing the profile again.
GeJ mikehh: Can't reproduce your failures with `make coretest` on FreeBSD 7 here. 21:02
chromatic tcurtis, that looks reasonable for now. 21:03
mikehh Gej: did you do a make realclean, make corevm, make coretest - it passes in make test
GeJ mikehh: I was one revision behind you (r47474). realcleaning and updating now. 21:04
21:05 whiteknight joined
mikehh Gej: i got the failures as far back as r47458 21:06
21:07 jjore joined
mikehh GeJ: it important to do a make realclean first, configure and then make corevm, make coretest otherwise some of the dynoplibs etc are already built 21:07
GeJ mikehh: Ok, I usually do a make && make test. 21:10
21:10 theory joined
GeJ mikeh: at r47477 with `make corevm && make coretest` I confirm the errors in t/pmc/io.t 21:12
And t/compilers/imcc/syn/clash.t looks ok.
tcurtis cotto_work: I'm interested in Lorito, and may look over it and offer thoughts and such on it, although I'm still not very knowledgeable about parrot, especially about the internals. 21:13
whiteknight cotto_work: I was working on a big blog post about Lorito last week with tons of feedback, but I never finished it
GeJ bbl & 21:14
cotto_work tcurtis, that's great. You'll have a different perspective.
whiteknight, post that thing!
dalek tracwiki: v1 | chromatic++ | LoritoPurpose 21:15
tracwiki: created page skeleton
tracwiki: trac.parrot.org/parrot/wiki/LoritoP...ction=diff
tracwiki: v1 | chromatic++ | LoritoOpBalance
tracwiki: created skeleton page
tracwiki: trac.parrot.org/parrot/wiki/LoritoO...ction=diff
tracwiki: v2 | chromatic++ | LoritoOpBalance
tracwiki: trac.parrot.org/parrot/wiki/LoritoO...ction=diff
tracwiki: v16 | bacek++ | GCMassacre
tracwiki: Remove one TODO item
tracwiki: trac.parrot.org/parrot/wiki/GCMassa...ction=diff
tracwiki: v17 | bacek++ | GCMassacre
tracwiki: trac.parrot.org/parrot/wiki/GCMassa...ction=diff
ambs darek-- #spammer 21:16
:D
21:17 Andy joined
chromatic gc_massacre is 1.483% faster than trunk right now with oofib. 21:20
mikehh GeJ: t/compilers/imcc/syn/clash.t is onlt failing in testr which compiles it to pbc and runs the pbc (part of fulltest) it seems ok elsewhere 21:24
only
21:27 cognomore joined
whiteknight chromatic: that's promising. I bet we can improve that 21:28
bacek here?
darbelo Both here and there. 21:29
At least he was a bit ago.
bacek whiteknight, yes
whiteknight bacek: what's going on with that gc branch? what help do you need?
bacek whiteknight, StringAllocator, .get_info method 21:30
there is TODO list on wiki
whiteknight okay, I'll take a look at that tonight 21:33
darbelo allison: ping 21:35
bacek chromatic, I suspect branch is faster because we are doing less collects. 21:36
chromatic Entirely possible. 21:37
bacek ms2 should be slower than ms. It's algorithmically more complex. 21:38
chromatic It's not sweep-free yet, is it?
bacek It's just very good foundation for GenGC. Or Incremental TriColour.
chromatic, we can't have sweep-free. We have to paint live objects back to white. 21:39
chromatic I must run an errand, but I don't think we do. 21:40
I had a flash of insight a moment ago but I must think about it more.
bacek ok.
dalek rrot: r47478 | NotFound++ | trunk/examples/embed/cotorra.c:
stop using deprecated functions in example cotorra
 21:45
allison darbelo: ping 21:47
darbelo I have a question about NFG semantics, regarding character classes. 21:48
allison okay
dalek tracwiki: v16 | chromatic++ | LoritoRoadmap 21:49
tracwiki: trac.parrot.org/parrot/wiki/LoritoR...ction=diff
darbelo Should we 'fake' unicode data for our dynamic graphemes?
allison darbelo: it will certainly be desirable to have access to the attributes of the characters contained within the dynamic grapheme 21:50
darbelo: but, what do you mean by 'fake'?
darbelo: for example, when matching a string, and looking for characters that are word-forming characters
darbelo: you'd want to match a dynamic grapheme that contains an 'a', even if it also contains a diacritic 21:51
dukeleto chromatic: you were correct about "parrot load.pir" not working, where load.pir loads perl6.pbc 21:52
darbelo allison: Ok, And how wrong would it be, as a first approximation to delegate to the base character. 21:53
allison darbelo: that sounds like a reasonable first approximation 21:54
darbelo Excellent. I'll try to fit into our unicode charset this week. 21:55
allison great! 21:56
darbelo One sticky point I'm running into is the interactions of COW and our grapheme tables.
NotFound Easy solution: kill COW
darbelo I'm not sure how to make two strings properly share grapheme tables without having to either disable COW, or writing a lot of code to fit this into the gc. 21:57
And writing gc code that is going to get rewritten when gc_massacre lands doesn't sound very good to me. 21:59
cotto_work there was a prpopsal to kill cow
sounds like it'd make life nicer for you
darbelo I'm all for killing cow. I can probably do it myself, but that'd be a 2 week detour from my main gsoc goals. 22:00
Maybe I can do it in one week. 22:03
dalek tracwiki: v18 | bacek++ | GCMassacre 22:05
tracwiki: Add TODO.
tracwiki: trac.parrot.org/parrot/wiki/GCMassa...ction=diff
bacek darbelo, COW?? 22:08
22:08 mikehh joined
bacek darbelo, do you change string behind the scene? 22:09
darbelo bacek: Right now, I don't do anything :) I just give each string it's own grapheme table, without caring wether the buffer is shared or not. 22:10
bacek "COW"ed string can just share same table.
NFG normalisation will produce new string. With own table. 22:11
And we share buffers only between immutable strings.
pmichaud (from #parrotsketch) :load subs are run when something is loaded via load_bytecode. :init subs are run when something is compiled from PIR. 22:12
darbelo Yes, but a substring won't really need all of it's superstring's table.
pmichaud (although :init subs also get run when a .pbc is loaded via the parrot command line, iirc) 22:13
bacek darbelo, you just share pointer. 22:14
22:15 bubaflub joined
darbelo bacek: That would mean that I have to bind the table to the lifetime of the buffer, and not the string header. 22:17
bacek darbelo, ah... Yes. Than implement .clone. You'll need it anyway. 22:18
dalek rrot: r47479 | bacek++ | branches/gc_massacre/src/gc (2 files):
Start extracting Variable_Size_Pool into own files.
darbelo ".clone"?
rrot: r47480 | bacek++ | branches/gc_massacre (2 files):
Add skeleton file for Variable_Size_Pool.
 22:19
rrot: r47481 | bacek++ | branches/gc_massacre/src/gc (4 files):
Extract GC_Statistics from Memory_Pools.
rrot: r47482 | bacek++ | branches/gc_massacre/src/gc/gc_ms2.c:
Use GC_Statistics
bacek Actually, in gc_massacre I already made str_copy alias for str_clone.
bacek darbelo, perl6ish style of methods :). "GraphemeTable.clone"
darbelo I have that already :)
I can create, clone, and (later today) merge tables. 22:20
22:20 eternaleye joined
darbelo bacek: Wait, in gc_massacre most of COW is gone then? 22:22
bacek darbelo, last bit. It's not "gone". It's just NYI. But I'm not sure do I want to implement it :) 22:23
darbelo AFAICT, all of our COWs are substr's and copy's. 22:24
bacek darbelo, it's not "COW". We just share same immutable buffer. 22:25
22:25 kid51 joined
bacek So, there is no "W" part. So no "C" part. Only "O" or even "o_O" part. 22:25
NotFound Moo 22:26
darbelo True, but it's still shorter to type, than 'Shared buffers'
And it makes for better jokes.
I'm not sure how we could have real COW without playing unportable mprotect() games anyway. 22:28
NotFound We can make lot of jokes until people gets so bored that like to kill it.
22:29 lucian_ joined 22:30 davidfetter joined
bacek I don't mind killing "shared buffers". We just have to ask sorear to build rakudo without them. 22:31
NotFound But maybe they want to kill *me* instead of the cow
darbelo "Like sahred buffers to the slaughter..."
bacek feels like a butcher cutting pigs, sheeps and COWS 22:32
cotto_work suddenly wants a COWburger 22:33
as soon as I take a bite, it gets cloned
darbelo . o O( Copy On Bite ) 22:34
davidfetter likes his COW done rare
mikehh that would be corny
dalek rrot: r47483 | NotFound++ | trunk (4 files):
initial incomplete implementation of ByteBuffer PMC
 22:35
rrot: r47484 | bacek++ | branches/gc_massacre/src/gc (2 files):
Extract Parrot_gc_get_info from gc_ms_get_gc_info with statistics
rrot: r47485 | bacek++ | branches/gc_massacre/src/gc/gc_ms2.c:
Expose some statistics from MS2. Make t/op/gc-leaky.t test happy.
kid51 Getting massive packfile-related failures in 'make test' in trunk: smolder.plusthree.com/app/projects/...ails/34264 22:38
NotFound kid51: about to regenerate native pbc 22:39
dalek tracwiki: v19 | bacek++ | GCMassacre
tracwiki: GC_Statistics is done.
tracwiki: trac.parrot.org/parrot/wiki/GCMassa...ction=diff
bacek mikehh, t/op/string-mem.t is unlocked in branch. 22:41
kid51 Ah, I see: PackFile_unpack: This Parrot cannot read bytecode files with version 6.20 22:42
mikehh bacek: 'k testin' now
dalek rrot: r47486 | bacek++ | branches/gc_massacre/t/op/string_mem.t:
Temporary disable Strings collecting test.
 22:55
rrot: r47487 | NotFound++ | trunk (2 files):
fix c++, codingstd and metadata in bytebufer
rrot: r47488 | mikehh++ | branches/gc_massacre/MANIFEST:
re-generate MANIFEST
rrot: r47489 | mikehh++ | branches/gc_massacre/src/gc (2 files):
add svn properties
rrot: r47490 | NotFound++ | trunk/t/native_pbc (4 files):
native_pbc upadte to 6.21
bacek NotFound++ # ByteBuffer ftw! 22:56
NotFound WTF? packfile test still failing 23:02
darbelo The regeneration got separated into two scripts, IIRC. 23:04
bacek NotFound, which one?
NotFound bacek: all 23:05
bacek not ok 26 - FixupEntry name preserved
?
it's... weird 23:06
NotFound scripts? 23:07
purl scripts are for methadone, vicodin etc
bacek NotFound, hang on. 23:08
NotFound This makes no sense. That tests are supposed to test packfiles, not foreign pbc readability.
bacek I've updated build_native_pbc to make correct files.
It's prefixless files. 23:09
Bah... I didn't update docs...
It's tools/dev/mk_packfile_pbcs
tools/dev/mk_packfile_pbc
NotFound, fixed. 23:11
NotFound, hey! I did add comment into PBC_COMPAT! :) 23:12
dalek rrot: r47491 | bacek++ | branches/gc_massacre/src/string/encoding/utf8.c:
Fix assert to avoid buffer overrun in next-after-last character.
rrot: r47492 | bacek++ | branches/gc_massacre/src/string/api.c:
Fix recalculating buffer length in str_join.
rrot: r47493 | bacek++ | trunk/t (5 files):
Rebuild PBCs for packfile testing. Add bit of doc in t/pmc/packfile.t
NotFound bacek: will not be a lot simpler to use for those tests pbc files built in the current system instead of the ones stored in the repo? 23:13
23:13 arnsholt joined
bacek NotFound, makes sense now. 23:13
mikehh bacek: the t/compilers/opsc test seem to grab all the memory on my machine particularly 02, and I stopped 07 after my swapfile grew to 4GB 23:19
kid51 mikehh: I noticed something similarly weird. My drive which is normally 80% full is now 100% full. 23:27
kid51 must reboot
23:31 eternaleye joined 23:37 kid51 joined 23:38 szabgabx_ joined
kid51 okay, my disk full problem was probably not Parrot-related 23:43
A test in File-ReadBackwards test suite fills up disk.
Blame Uri!
ttbot Parrot trunk/ r47494 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/340671.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 23:54
cotto_work mikehh: r47495 looks like it got cut off before
mikehh cotto_work: let me check 23:58

Powered by Cro and the Raku® Programming Language.

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

Thank you!