Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets (4 to go), merge branches; profile your favorite PIR for memory leaks with valgrind
Set by moderator on 6 September 2010.
00:01 ascent left 00:09 NotFound left 00:13 ascent joined
dalek TT #1621 closed by jkeenan++: Build errors on Windows 00:18
TT #1621: trac.parrot.org/parrot/ticket/1621
00:20 NotFound joined 00:42 tcurtis joined 00:47 chromatic left 00:49 plobsing2 is now known as plobsing 00:54 Psyche^ joined 00:56 dngor_ joined 00:59 Patterner left, Psyche^ is now known as Patterner 01:00 dngor left 01:04 Infinoid left, Infinoid joined 01:09 aloha left 01:10 bacek left 01:13 dngor_ is now known as dngor 01:16 Paul_the_Greek left 01:29 bluescreen joined 01:45 whiteknight left 01:47 JimmyZ joined
JimmyZ www.parrot.org/scratch/steigender-b...chinesisch . Is it a advertisement? 01:48
GeJ Oh, that's spam alright. 02:01
with an exploit on the top maybe? 02:02
JimmyZ I don't know,heh 02:03
02:06 JimmyZ left 02:21 GodFather joined
GeJ clock ? 02:23
purl GeJ: LAX: Mon 7:23pm PDT / CHI: Mon 9:23pm CDT / NYC: Mon 10:23pm EDT / LON: Tue 3:23am BST / BER: Tue 4:23am CEST / IND: Tue 7:53am IST / TOK: Tue 11:23am JST / SYD: Tue 12:23pm EST /
02:24 GodFather left 02:36 janus left 03:07 theory left
dalek rrot: r48817 | plobsing++ | trunk (3 files):
remove interp.save_func_table field
 03:18
03:23 bluescreen left 03:25 bluescreen joined
dalek rrot: r48818 | plobsing++ | trunk/src/runcore/main.c:
remove unused static function notify_func_table
 03:35
03:51 janus joined 04:11 patspam left
sorear #1163 spam 04:19
bacek_at_work sorear, I already deleted comment 04:21
dalek kudo: 8cf7fcd | pmichaud++ | src/Perl6/Actions.pm:
Switch 'for' statement modifier to use 'map' internally.
 04:29
rrot: r48819 | plobsing++ | trunk (7 files):
allocate evc_func_table lazily and minimally
 05:00
05:09 plobsing left 05:41 chromatic joined 06:02 fperrad joined, chromatic left 06:06 uniejo joined
dalek rrot: r48820 | NotFound++ | trunk/src/pmc/stringbuilder.pmc:
missing return in StringBuilder get_string!!!
 06:07
06:14 he joined, cotto joined
cotto ~~ 06:14
msg dukeleto trac.parrot.org/parrot/wiki/GitMigration - edit away! 06:31
purl Message for dukeleto stored.
06:32 he left
dalek tracwiki: v7 | cotto++ | GitMigration 06:40
tracwiki: add rough timeline and prereqs for review
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
06:44 he joined 07:12 tcurtis left 08:14 NotFound left 08:15 NotFound joined 08:30 bacek joined
dalek p-rx: 237bf91 | moritz++ | src/Regex/P6Regex/Grammar.pm:
introduce "Quantifier quantifies nothing" error message
 08:33
08:33 aloha joined
smash mornin' everyone 08:58
09:07 M_o_C joined 09:17 aloha left 09:18 bacek left 09:28 mikehh left 09:50 fperrad left 09:55 bacek joined 10:01 aloha joined 10:08 jsut joined 10:13 jsut_ left, smash left 10:14 smash joined
bacek aloha, humans 10:31
10:40 fperrad joined 10:58 mikehh joined 11:11 M_o_C left 11:32 contingencyplan left 11:49 M_o_C joined 11:56 mariano__ joined
Coke . 12:00
12:01 bkuhn joined 12:04 dmalcolm joined 12:10 whiteknight joined
Coke Who cleaned up the trac spam? 12:21
Thanks, and : trac.parrot.org/parrot/wiki/TracSpammers . though I suppose it's just more work for us, I do like keeping the list. 12:22
four tickets remaining to hit our goal tomorrow. 12:43
dalek TT #113 closed by rblasch++: [PATCH] sal.h is not included in Visual Studio.NET 2003 12:46
TT #113: trac.parrot.org/parrot/ticket/113
moderator Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets (3 to go), merge branches; profile your favorite PIR for memory leaks with valgrind 12:47
Coke three! three tickets, ha ha ha. 12:51
moritz++ (are you a bot?) 12:52
moritz Coke: hey, rblasch++ closed the ticket, not me :-)
szbalint if the trac timeline would appear on irc that would make the process easier :) 13:02
13:06 aloha left, bacek left
Coke dalek is doing at least part of that, szbalint 13:17
szbalint gah, I'm blind. 13:19
:)
13:35 M_o_C left 13:45 dmalcolm left
dalek TT #1764 reopened by nwellnhof++: Infinite loop in exit handler 13:54
TT #1764: trac.parrot.org/parrot/ticket/1764
13:54 janus left
Coke was that one of the 21 already closed this week? 13:55
moritz I think so
Coke bummer. 13:56
14:00 uniejo left 14:06 Andy joined 14:07 ttbot left 14:09 ttbot joined 14:13 janus joined 14:19 he left 14:23 M_o_C joined 14:33 M_o_C left, M_o_C joined
dalek p-rx: 24b297f | moritz++ | src/Regex/P6Regex/Grammar.pm:
report unrecognized backslash sequences
 14:33
mikehh t/op/integer.t and t/pmc/bigint.t FAIL in make corevm/make coretest - error:imcc:loadlib directive could not find library `sys_ops' 14:44
all other tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48820 - Ubuntu 10.04 i386 (g++)
for some reason this does not seem to happen on amd64, but it fails on i386 with gcc/g++ with or without --optimize 14:45
but only in coretest before sys_ops are built 14:46
switching to amd64 to do further testing 14:48
14:49 plobsing_ joined 14:57 mikehh left 15:03 ash_ joined 15:06 luben_work joined 15:09 mikehh joined 15:25 mariano__ left
NotFound mikehh: Is corevm supposed to build dynops? 15:26
15:26 nwellnhof joined 15:32 theory joined
mikehh NotFound: not as far as I am aware, but the tests pass on amd64, so I am confused 15:34
NotFound mikehh: most probably the test is wrong. 15:35
mikehh NotFound: and again it passes make test, just not make corevm/make coretest on i386 15:36
plobsing_ looking at the test, it only uses sys_ops to get MAX_INT and MIN_INT. why aren't these simply pasm include constants? 15:37
15:38 allison joined
mikehh plobsing: 32 bit/64 bit 15:40
moritz that pasm include file could be written at configure time 15:42
plobsing_ 32 bit machines get the constant as 2**32-1, 64 bit as 2**64-1
the op is still necessary when writting cross-platform PBC, but the constant is nifty (esp. in coretest) 15:43
dalek kudo: d84752d | KodiB++ | / (6 files):
Implemented Instants and Durations.

Signed-off-by: pmichaud <pmichaud@pobox.com>
15:45 jsut_ joined
dukeleto 'ello 15:48
mikehh hi dukeleto 15:49
15:50 jsut left
plobsing_ is also surprised that t/op/integer.t (which also uses sys_ops) isn't also failing. 15:51
dukeleto mikehh: howdy 15:52
purl salut, dukeleto.
NotFound The fix is easy: don't use sysinfo 15:53
Even better: deprecate sysinfo
15:53 mj41_ joined
ash_ anyone else ever notice that there is no --without-readline in parrot's config? 15:54
15:55 chromatic joined
ash_ or is it required by something? 15:55
NotFound I'd like better to not detect readline during config and not link it, using nci at runtime instead.
ash_ that could work too, but it currently doesn't check --without-readline, i'll try to patch that 15:56
NotFound wfm 15:57
15:58 mj41 left, mj41_ is now known as mj41
NotFound mikehh: it fails for me with make corevm ; make coretest in amd64 15:59
16:00 theory left, theory joined 16:03 SingAlong joined
SingAlong hi all 16:03
dalek tracwiki: v8 | dukeleto++ | GitMigration 16:04
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
SingAlong is episode-3 of the PCT tutorial fixed? The last time I used it I wasnt able to do the exercises or even run it (the auto-generated test file had problems). 16:05
anyone? 16:07
purl Somewhere, someplace, in some universe, somebody uses whatever you just asked about.
mikehh All tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48820 - Ubuntu 10.04 amd64 (g++) 16:08
SingAlong purl: was that for me? 16:09
purl singalong: no idea
mikehh NotFound: it should AFAICS, but doesn't for me - after make realclean, so I am not sure, let me test further
SingAlong purl: well did it work for you?
purl singalong: no idea
SingAlong purl: ah. thanks 16:10
purl sure thing SingAlong
SingAlong purl: did the episode-3 work for you? (until the end)
purl SingAlong: huh?
NotFound SingAlong: purl is a bot
SingAlong oh crap!
NotFound SingAlong: Did you opened a ticket about that? 16:11
SingAlong NotFound: nope! tcurtis said he'll check that. It was he who figured out that the test file auto-generated had the mistake.
NotFound SingAlong: better open the ticket, people sometimes forget things 16:12
SingAlong NotFound: sure. but now I forgot the error. I guess it's better to post it with the error in detail than just saying that the test file is wrong. So i'll start the tutorial tomorrow and doing it again 16:13
dukeleto SingAlong: thanks, we appreciate it
NotFound SingAlong: good. Maybe is already fixed.
SingAlong dukeleto: np :) love parrot. i almost did my own language (until the tutorial broke) :) 16:14
was thinking about the Parrot PIR BabySteps tutorial i found on the web. but many advised me to go with PCT instead or PIR, now i know why... dealing with registers etc 16:15
NotFound SingAlong: you can write a language both ways, using PCT or writing a custom lexer/parser. 16:16
With PCT you have the tools and the tutorial, with the custom way you must take care of all.
SingAlong NotFound: I used to do a lot of lex and yacc. But can that be used with PCT? or do I have to use NQP. (any docs would help) 16:17
NotFound SingAlong: the PCT way uses perl6 style grammars with nqp. Don't know if you can mix yacc into it without a lot of work. 16:18
SingAlong NotFound: oh just wanted to know if that's easier. I'll skip using yacc if it's a round-about method. 16:19
NotFound You can make a compiler in C with lex/yacc and generate pir, sure.
mikehh NotFound: my bad - it was pulling the files from an installed parrot on amd64
SingAlong NotFound: oh! thats nice! any doc? 16:20
on how to use lex/yacc to generate pir 16:21
dukeleto SingAlong: it is possible, but not recommended.
NotFound SingAlong: just by writing pir code as output.
dalek tracwiki: v9 | dukeleto++ | GitMigration
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
SingAlong dukeleto: not going to do that unless i try hard to figure out whats wrong with the ep-3 :) 16:22
NotFound: yacc and lex only output .c files. how do i force it to generate pir?
NotFound SingAlong: not sure it you can do it without ugly tricks. What I did was to avoid lex and yacc, and using a hand-coded recursive descent parser instead. 16:24
16:27 SingAlong left 16:29 nwellnhof left 16:37 shockwave left 16:43 davidfetter joined
cotto_work good morning, fellow humans 16:46
16:46 tcurtis joined
cotto_work 1001010101, bots 16:46
dalek kudo: 0d6d574 | moritz++ | docs/ChangeLog:
update ChangeLog
 16:49
cotto_work dukeleto: ping
16:50 whiteknight left 16:54 jhelwig joined
dalek p-rx: 99fe6e2 | moritz++ | src/stage0/ (3 files):
update bootstrap files
 16:54
dukeleto cotto_work: pong 17:14
cotto_work: we should pair on git-related stuff. 17:15
cotto_work +1
purl 1
cotto_work dukeleto: I saw your edits to the git migration page. Are you suggesting using both github and cgit? I like github because it avoides more work for osuosl 17:16
dukeleto cotto_work: cgit is very similar to gitweb. gitweb comes with git
cotto_work: what i am talking about is having the "canonical" git repos on git.parrot.org, and gitweb is a very easy way to access/view them over HTTP 17:17
17:17 whiteknight joined
particle cotto_work: do you have git commit messages working? 17:18
cotto_work Yes. I have a (very slow) demo site set up too.
dukeleto cotto_work: i am thinking that github is where people commit to, but we also have our "canonical" git repo on git.parrot.org, which get synced to the github mirrors via a cron job
17:19 contingencyplan joined
particle cotto_work: saw the demo site, didn't see commit messages. excellent. 17:19
i'd like to have git.parrot.org
dukeleto cotto_work: this will minimize our OSUOSL bandwidth
cotto_work What do you mean by "commit messages"?
particle bandwidth won't be a problem until we exceend 10GB/mo
dukeleto particle: that is the plan. git.parrot.org will be canonical and synced from github via a cronjob
cotto_work They appear when you hover over a commit link. 17:20
particle dukeleto: would you like git.parrot.org to redirect to github?
or to host our own cgit
parrot.org has been designed to host more projects than parrot
eg trac.parrot.org/parrot/... 17:21
however in practice we haven't done that
dukeleto particle: i would like git.parrot.org to be our own cgit/gitweb interface. I don't care which. 17:22
particle: the parrot github org has 2 repos already: parrot.git and pir.git, so I think we should plan on multiple repos
particle: cgit is faster/uses less CPU than gitweb, but has fewer features.
particle: gitweb is probably already installed on parrot.org, just a few conf vars need to be twiddled 17:23
cotto_work, particle: I already have the cronjob to sync github -> git.parrot.org written. It is very simple
particle osuosl prefer cgit 17:24
dukeleto particle: sounds good to me.
particle dukeleto: can you put in a request to support@osuosl.org?
dukeleto particle: sure. what exactly should I ask for? 17:25
particle subject parrot.org: install/configure gitosis/cgit
dukeleto particle: we don't need gitosis
particle oh, no, we don't.
dukeleto particle: no one needs to commit to git.parrot.org
particle right.
dukeleto particle: it will simple act as the canonical mirror
s/simple/simply/ 17:26
particle then explain the github mirroring setup, and ask for a cgit or gitweb setup.
dukeleto particle: ok.
particle and you can find them on #osuosl on freenode to discuss the ticket after it's submitted 17:27
so you might mention your freenode nick if they want to ping you
dukeleto particle: good to know
cotto_work Will git.parrot.org sync both ways or will it be read-only and get changes from github?
17:28 ruoso left
particle prefers two-way, if it's manageable 17:28
dukeleto cotto_work: read-only. it will only pull in changes from github
particle: two-way makes the mirroring a lot more involved
particle yes, i know, i just don't know what the state-of-the-art in git mirroring is 17:29
dukeleto particle: then you have to decide who wins if git.parrot.org diverges from github
cotto_work Then why have it?
particle it's mostly a branding/vanity thing
dukeleto I think many people are concerned that we host our "official" repos on github
particle let's be humble and go with github as canon
17:29 elmex_ joined
dukeleto The perl6 peeps seem to be happy with github as canon 17:30
particle we're free software, we take advantage of free services
cotto_work +1 to particle
moritz the nice things is that everybody has the full repo
dukeleto My $job mirrors all (17) of our github repos to our own servers, in case the bay area falls into the ocean
moritz if githubs decides to shut down their service, it's just a matter of changing URLs 17:31
17:31 elmex left
dukeleto The question boils down to: What is more likely to go down nowadays? parrot.org or github.com ? 17:31
whiteknight There's no reason why git.parrot.org can't redirect to the github page
17:31 elmex_ is now known as elmex
dukeleto whiteknight: agreed. We are decided what is wanted, though. 17:31
Does parrot want to have a read-only mirror on parrot.org ? We already can setup read-only mirrors other places, like git.or.cz and gitorioius 17:32
whiteknight I see no problem with read-only mirrors
dukeleto whiteknight: sure. But do we want to host our own, is the question.
cotto_work -1, mostly because it means more work for osuosl that we can't do ourselves 17:33
whiteknight yes, I should have been more specific: It would be good to host our own read-only mirror, if possible
dukeleto it is a small amount of one-time work. gitweb/cgit needs to get configured, and then a 5 line cronjob needs to run, which is already written.
whiteknight development can always happen offline with git. The more copies we have easily publically available, the more seemlessly we will be able to weather a github outage
cotto_work +0 then 17:34
dukeleto cotto_work: i am not sure that we need to ask osuosl to do it. Can't we do that stuff ourself? We just need them to add the git.parrot.org vhost
whiteknight Assuming that somebody has an up-to-date copy, we can do anything we want while github is down. We could cut a release if we wanted
dukeleto But I hear what y'all are saying. Github as canon is fine with me. 17:35
moritz wfm too
dukeleto whiteknight: we can setup easy read-only mirros on gitorious/git.or.cz, without asking OSUOSL for anything
whiteknight dukeleto: that said, The github feature set is what we want most, not necessarily the github URL
I think we could get our own copy of that code and run our own instance if we absolutely wanted to 17:36
of course we lose out on possibility for mass collaboration
moritz let's ask it the other way: is there are a good reason to host it ourselves?
dukeleto whiteknight: i am only taking about having a read-only mirror on git.parrot.org, not running our own instance of githuby things
moritz apart from NIH, of course :-)
cotto_work moritz++ 17:37
Coke given the amount of work that went into removing the appearance of dependence on perl.org, I have no desire to repeat that with our git server.
dukeleto moritz: I am a newbie. I want to get the official parrot repo. Where do I go?
moritz: git.parrot.org would be my first guess
moritz dukeleto: you start google, and type 'parrot git' 17:38
Coke dukeleto: I'd just google it.
moritz++
moritz dukeleto: and the first hit will either be a parrot wiki page pointing to the github repo
or the github repo itself
having a redirecting subdomain works for me too
(I'd have no problem with a custom hosting solution too, I just think it's more effort to maintain than people assume) 17:39
remember those spiders that follow every link, ask for every changeset, every possible blame at every possible revision?
whiteknight source.parrot.org 17:41
dukeleto moritz: having that as a redirect to github would be fine, though
whiteknight: source is more general, but longer to type ;)
whiteknight the most obvious thing is not always the shortest
17:41 bkuhn left
whiteknight I'm not going to bikeshed here, I'm just pointing it out 17:41
dukeleto We should attempt to paint the smallest bikeshed possible ;)
repo.or.cz/w/parrot.git
17:41 ash_ left, fperrad left, smash left, jan left, GeJ left, Hunger left, atrodo left, sjn left, spinclad left, knewt left, purl left, tcurtis left, theory left, mikehh left, M_o_C left, Andy left, cotto left, Util left, dukeleto left, pjcj left, luben left, PacoLinux left, nopaste left, perlite left, TimToady left, hudnix left, Tene left, KatrinaTheLamia left, elmex left, whiteknight left, jhelwig left, mj41 left, luben_work left, ttbot left, Infinoid left, x3nU left, esskar left, integral left, eternaleye left, p6eval left, bacek_at_work left, wagle left, jjore_ left, dafrito left, particle left, silug left, preflex left, szabgab left, cxreg left, dip left, slavorgn left, Khisanth left, zostay left, snarkyboojum left, athomason left, dzoe left, mikegrb left, frodwith left, Maddingue left, TonyC left, szbalint left, confound left, chromatic left, allison left, plobsing_ left, janus left, NotFound left, bluescreen left, dngor left, Patterner left, ascent left, dalek left, pmichaud left, PerlJam left, AzureSto_ left, s1n left, edenc left, autark left, baest left, rblackwe left, slavorg left, kthakore left, sorear left, estrabd left, jnthn left
davidfetter parrotsketch? 17:41
Coke in several hours. 17:42
little under 3.
davidfetter k
17:42 ttbot joined
davidfetter i guess purl got netsplit or something 17:42
Coke how many tickets left to close before then?
oh. 17:43
missed that. ;)
cotto_work 3 according to the topic, though there's at least one I still need to review
Coke particle - I can't login to trac.parrot.org
betting the overeager cache is back.
Coke tries to find osu. 17:44
17:45 jnthn joined, estrabd joined, sorear joined, slavorg joined, rblackwe joined, baest joined, autark joined, edenc joined, kthakore joined, s1n joined, AzureSto_ joined, PerlJam joined, pmichaud joined, dalek joined, ascent joined, Patterner joined, dngor joined, bluescreen joined, NotFound joined, janus joined, plobsing_ joined, allison joined, chromatic joined, ruoso joined, knewt joined, spinclad joined, sjn joined, atrodo joined, Hunger joined, GeJ joined, jan joined, smash joined, fperrad joined, ash_ joined, elmex joined, whiteknight joined, jhelwig joined, tcurtis joined, theory joined, mj41 joined, mikehh joined, luben_work joined, M_o_C joined, Andy joined, cotto joined, Infinoid joined, x3nU joined, esskar joined, Util joined, dukeleto joined, integral joined, eternaleye joined, pjcj joined, luben joined, PacoLinux joined, p6eval joined, bacek_at_work joined, nopaste joined, wagle joined, jjore_ joined, dafrito joined, perlite joined, particle joined, silug joined, preflex joined, TimToady joined, szabgab joined, hudnix joined, cxreg joined, Tene joined, dip joined, KatrinaTheLamia joined, slavorgn joined, Khisanth joined, zostay joined, purl joined, mikegrb joined, snarkyboojum joined, TonyC joined, dzoe joined, Maddingue joined, frodwith joined, szbalint joined, athomason joined, confound joined 17:46 plobsing_ left, plobsing_ joined
cotto_work It's a good thing I love brittle protocols. 17:46
chromatic Oh, set_bool. No idea. 17:47
dukeleto will be back in a few 17:48
Coke pinged osuosl folks about trac.parrot.org login. 17:50
anyone able to login?
atrodo Coke> I was able to 17:51
cotto_work wfm 17:52
18:09 davidfetter left 18:10 tadzik joined
dalek rrot: r48821 | NotFound++ | trunk/t/pmc/orderedhashiterator.t:
test OrderedHashIterator clone
 18:15
dukeleto is back 18:26
dukeleto updated the git migration plan, removed git.parrot.org stuff, for now 18:28
it can be setup at any time, and isn't necessary for the svn -> git switch
mikehh: i added you as a committer to github, as well. 18:31
18:32 nwellnhof joined
dukeleto migrates. be back soon. 18:33
cotto_work clones and forks dukeleto
Coke thanks dukeleto for taking over the git documentation. 18:34
Coke volunteered back in the dark ages.
cotto_work dukeleto++ for git docs
18:38 fperrad left
dalek tracwiki: v10 | dukeleto++ | GitMigration 18:38
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
TT #1774 created by ash++: Adding without-readline support 18:44
TT #1774: trac.parrot.org/parrot/ticket/1774
TT #1749 closed by nwellnhof++: readall method on open FileHandle is inefficient
TT #1749: trac.parrot.org/parrot/ticket/1749
18:46 tadzik left
ash_ i submitted a patch to the trac for --without-readline for the Configure.pl script 18:47
tcurtis nwellnhof: does r48824 create the right encoding for the produced string? When I tried a change that was, iirc, about the same as yours, it failed some tests due to wrong encodings.
nwellnhof tcurtis: yes, see the previous commit 18:48
dalek rrot: r48822 | plobsing++ | trunk/compilers/imcc (3 files):
remove imc_info_t.allocated (was always 0)
 18:49
rrot: r48823 | nwellnhof++ | trunk (2 files):
[pmc] Various fixes to StringBuilder PMC

  - Use Parrot_str_clone again, it should be safe now
  - Keep encoding if all strings have the same encoding
rrot: r48824 | nwellnhof++ | trunk/src/pmc/filehandle.pmc:
[pmc] Use StringBuilder in FileHandle.readall
nwellnhof the problem was that concatenating utf8 strings wouldn't necessarily produce an utf8 string 18:50
the string_rep_compatible logic was simply *too* smart 18:51
cotto_work That doesn't sound like "smart". 18:52
nwellnhof it does the right thing. but it can be surprising that the concatenation of utf8 strings produces an ascii string. 18:55
dukeleto is back 18:56
pmichaud nwellnhof: your patch fixes the readall problem, but what about the general problem of concatenating strings?
are long string concatenations always doomed to be slow in Parrot?
nwellnhof pmichaud: that's what StringBuilder is for
pmichaud nwellnhof: you expect a HLL compiler to figure out when there are long sequences of string concatenations and switch to StringBuilder?!
dukeleto cotto_work: no worries. I am enjoying it 18:57
nwellnhof pmichaud: it's a consequence of the immutable string changes. that wasn't my idea but i think immutable strings are a good thing. 18:58
pmichaud I think immutable strings are a good thing also.
My question is about GC.
It's the GC that causes the problem.
the example program I gave (before your patch) resulted in 1700+ mark-and-sweep runs. 18:59
nwellnhof not really, the actual problem is that str_concat has to allocate a new string every time.
chromatic Are you sure my patch to that caused the problems? I can't reproduce it.
nwellnhof that results in a lot of GC pressure, of course.
pmichaud nwellnhof: and lots of large string allocs result in many mark runs, apparently. 19:00
chromatic: I had a fresh checkout -- I can try again, if you wish.
NotFound Conatenating two string to a new string causing the allocation of a new string is no big surprise.
dukeleto cotto_work: what needs doing with github-trac? Are there any time-consuming things that need to be done close to the actual transition?
nwellnhof pmichaud: the old readall code allocated a string of average length (0.5 * filesize) for every line read. 19:01
pmichaud NotFound: but the 1740+ mark runs is way too expensive, especially when we have to mark-the-world.
dalek TT #1771 closed by NotFound++: Cannot hll_map in parrot HLL
TT #1771: trac.parrot.org/parrot/ticket/1771
chromatic I'm happy to argue that running the GC when a fixed-sized pool is full (or too full) is a bug.
That seems like a recipe for quadratic disaster.
pmichaud ...which is what we saw. 19:02
chromatic Exactly.
NotFound Wasn't that fixed?
pmichaud nwellnhof: I'm not arging against your patch, I'm arguing that it doesn't solve the underlying problem (for Rakudo)
chromatic I deleted a lot of code.
cotto_work dukeleto: the code that handles post-receive hooks needs to be tested, but my additions there are trivial.
chromatic There might be a 64-bit problem there, but I'm not sure.
nwellnhof pmichaud: the old code allocated 2.5 GB for reading unixdict.txt if my quick calculation is right 19:03
pmichaud nwellnhof: that doesn't surprise me.
cotto_work Installing the plugin requires the output from git log. Slurping the log into the db shouldn't take more than 30s.
pmichaud does readall still do a line-by-line read?
nwellnhof pmichaud: yes
pmichaud ...why?
tcurtis Could it be rewritten to use Parrot_io_reads like the unopened case? 19:04
nwellnhof pmichaud: i don't know. it probably shouldn't
pmichaud I think it should just do reads in, say, 4k byte chunks until exhaustion.
then for unixdict.txt instead of doing 25000 concatenations we end up doing 50
(or, if it's using StringBuffer, intead of reading in 25000 strings we read only 50) 19:05
chromatic line-by-line reading here is definitely suboptimal.
nwellnhof pmichaud: the funny thing is that readall does that if reads from a filename
whiteknight memory map the file, memcopy into a buffer, viola
chromatic My memcopy if we have mmap? 19:06
pmichaud this case is the one of reading from an already opened filehandle
the filehandle may be something that can't mmap
whiteknight well, if you want to assume that we're not going to close the mmap when we close and destroy the filehandle, that's fine
pmichaud I already switched rakudo's slurp() function to use the readall('filename') approach, that gave us a 30x speedup on slurp()
but that doesn't help with .slurp on already-opened-file 19:07
moderator Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets (2 to go), merge branches; profile your favorite PIR for memory leaks with valgrind 19:07
nwellnhof there are definitely a lot of possibilities for optimizing the IO code 19:07
dukeleto we have 1.5hrs left to close 2 tickets before #ps, to meet our goal 19:08
cotto_work: do we have an instance of the github-trac plugin running somewhere already?
cotto_work dukeleto: mksig.org/trac/wiki/WikiStart (super slow though) 19:09
running on postgres, same as trac.parrot.org
ash_ if someone wants to apply the patch from ticket 1774 that might be a quick ticket to close :P, or if i need to add more to the patch/make a better patch, let me know 19:10
dalek rrot: r48825 | moritz++ | trunk/ext/nqp-rx/src/stage0 (3 files):
[nqp-rx] update bootstrap files from (sha1 99fe6e22); adds improved error reporting for regex parsing
19:12 cotto_work left, cotto_work joined
dukeleto cotto_work: have you contacted the upstream author of the github-trac plugin at all? Is he open to merging your changes? 19:13
cotto_work: and do we care about having those changes merged upstream before converting parrot from svn to git?
cotto_work I haven't contacted him yet. I would prefer to have the changes merged upstream. 19:14
19:15 tadzik joined
dukeleto cotto_work: " * this will require the output from git log, as documented in the README for that plugin " 19:15
19:15 Paul_the_Greek joined
cotto_work I'll send him a message berore #ps. He's active on github (though not on the plugin atm) so he should see it soon. 19:15
*before
dukeleto cotto_work: how long will that step take?
cotto_work++
Paul_the_Greek Afternoon, Parrotheads.
dukeleto Paul_the_Greek: good localtime()
Paul_the_Greek The time of day is to be shifted appropriately in each reader's brain. 19:16
cotto_work merging upstream? It depends on davglass (the current maintainer)'s comments.
Don't consider it a blocker though. 19:18
dukeleto cotto_work: no, how lnog with the "output from git log" step take? 19:20
s/lnog/long/
cotto_work 20 seconds +/- 19:22
actually, it looks more like 3 on my local machine 19:23
luben hello everyone 19:24
what functions are subject of deprecations - those marked PARROT_EXPORT or those marked PARROT_API? 19:25
cotto_work That said, there's a fairly large difference between the number of commits that git log returns and the number of svn revisions we have.
API only 19:26
luben nice
dukeleto cotto_work: awesome. just making sure it is not going to take hours or something 19:31
cotto_work: git log operates on master by default 19:32
cotto_work: what kind of difference are you seeing?
19:32 mj41_ joined
cotto_work 39764 lines containing git-svn-id, whereas we have ~48800 commits. 19:33
dukeleto cotto_work: that could be something to do with branches and tags 19:35
cotto_work: and i don't think svn started on rev 1, since it was converted from CVS
cotto_work: but that is a guess 19:36
cotto_work we have a git-svn-id line for r1
19:36 mj41 left, mj41_ is now known as mj41
dukeleto cotto_work: does github-trac know about branch names? 19:37
cotto_work: what happens if a sha1 prefix is ambiguous?
cotto_work currently it'll pick the first one 19:38
no
I sense that perhaps I'm not as done as I'd thought.
dukeleto cotto_work: i wrote something very similar for a ticket tracking system at my $old_job 19:40
cotto_work: it would accept things like repo:branch or repo:sha1
cotto_work Oh good. Then you'll be familar with the pitfalls.
dukeleto cotto_work: yes, i am familiar with some of the pitfalls 19:41
cotto_work: what is the minumum length sha1 that you accept? i found 5 was reasonable
cotto_work: if not, you will be checking lots of english words that could maybe be a SHA1
cotto_work 5 19:42
Paul_the_Greek Like deadbeef? 19:43
cotto_work It'll check that and ignore it when it doesn't find a matching git id.
dukeleto Paul_the_Greek: yes, but deadbeef is >5 chars :) 19:44
Paul_the_Greek Okay, then just dead and beef. 19:46
cotto_work too short
purl too short is bad as well
dukeleto Paul_the_Greek: yes, that is the point of requiring >= 5 chars. 19:47
cotto_work: i just made the gitmigration wiki page more specific. please add any bullet points that you can think of under the github-trac plugin 19:48
cotto_work Hamburger discussions will not be adversely affected.
Paul_the_Greek Why would you be confused that a sha1 might be a word? 19:49
dukeleto cotto_work: we need a better definition of "well-tested"
cotto_work s/better //
dukeleto Paul_the_Greek: this is the situation. You have a wiki page with 5000 words on it. We only check words >= 5 chars to see if they are SHA1's
Paul_the_Greek Why do you check that at all?
dukeleto Paul_the_Greek: it is expensive to see if something is a SHA1, usually. Unless it is cached
cotto_work It makes me sad that trac extensions don't come with their own built-in tests like perl 5 modules do. 19:50
dukeleto Paul_the_Greek: to autolink SHA1's to the commit that refer to
Paul_the_Greek: like the way trac links r1234 to the changeset of r1234
Paul_the_Greek I don't have to code something around the sha1 to say it's a sha1?
Oh, right, like that.
cotto_work Paul_the_Greek: they can appear anywhere in a body of text.
dalek tracwiki: v11 | dukeleto++ | GitMigration 19:51
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
tracwiki: v12 | dukeleto++ | GitMigration
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
tracwiki: v13 | dukeleto++ | GitMigration
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
Paul_the_Greek So why not have to write at least 'sdecaf' ?
dukeleto Paul_the_Greek: what ?
Paul_the_Greek Why not some indicator like the 'r' ?
cotto_work That's for svn revisions. 19:52
Using it for both would add ambiguity to number-only git ids.\\
Paul_the_Greek Right, but why not something similar for sha1s?
Like an 's'.
cotto_work laziness on the part of the implementer ;) 19:53
tcurtis People are used to just saying the sha1 for git sha1s and it's easier to handle them without a prefix that train everyone to use a prefix, possibly.
dukeleto tcurtis++
Paul_the_Greek Hmm.
dukeleto Paul_the_Greek: don't bikeshed unless you want write the code and train everyone ;) 19:54
cotto_work Allowing git ids directly also seems to be the least surprising thing to me. Other people may be differently surprised.
Paul_the_Greek It's good to live in an age where trying to save the lookup of every word >= 5 letters composed of a--f is considered bikeshedding. 19:56
dukeleto It allows people to cut and paste emails that refer to SHA1's and all kinds of other use cases. It also allows copy+paste into git commands.
Paul_the_Greek: yes, I agree.
Paul_the_Greek I hereby renounce the fact that I grew up in the late '60s and '70s and throw efficiency to the wind.
All hail naked SHA1s! 19:57
dukeleto Paul_the_Greek++
cotto_work Welcome to the 21st century.
We have fast CPUs and we know how to keep them busy.
Paul_the_Greek You mean the century where all my spare cycles go to running dynamic icons? Huzzaaa!
dukeleto ponders making a film called "SHA1's gone wild"
nwellnhof paul: there aren't many words with more than 5 letters consisting only of letters A-F 19:58
Paul_the_Greek Ooh, let's find out how many ...
cotto_work smells a perl script in the making.
luben chromatic, ping
nwellnhof git hashes also have at least 7 characters, AFAIK 19:59
dukeleto nwellnhof: you are wrong about that
nwellnhof: any unique prefix works
nwellnhof: 7 characters will usually be unique for smallish repos, though
The number of characters needed, on average, grows logarithmically with the number of commits in the repo, if anyone cares. 20:00
pmichaud chromatic: I tried that patch from the mailing list again -- same result.
cotto_work i.e. slowly
dukeleto how does parrot-commits happen, currently? 20:01
cotto_work Oh. Good question.
purl Yeah, it is. I'm stumped.
Coke dukeleto: happen?
purl /kick Coke enough with the aybabtu already
Coke presumably a post-commit hook. 20:02
probably right in the trac guts.
dukeleto Coke: just wondering how we will do parrot-commits in the github age. I added it to the migration wiki page
nopaste "nwellnhof" at 192.168.1.3 pasted "grep '^[a-f]*$' unixdict.txt" (66 lines) at nopaste.snit.ch/23252
cotto_work thanks, nerd 20:03
;)
Coke dukeleto: one possible option: don't. 20:04
(just have people sub to the RSS commit feed.)
pmichaud RSS feed seems reasonable
cotto_work I like getting it by email.
pmichaud github allows commits to go to a mailing list 20:05
it's, like, easy.
dukeleto Coke: yep, that is possible. It is simple to get emails sent, but I think it is slightly more challenging to get commit diffs emailed
Coke so do I, but it's not worth any time on my effort to support. ;)
Paul_the_Greek There are only 33 words! What the hell was I worried about?
dukeleto pmichaud: commits yes, commit diffs, not so much
pmichaud: but the link to the diff is in the email, of course
pmichaud ah, yes, it doesn't include the diff.
Paul_the_Greek You could allow four letters and it still doesn't much matter. 20:06
dukeleto facade and decade <-- high class deadbeef cousins
Paul_the_Greek acceded, defaced, effaced
bedded should be useful, too. 20:07
Coke abacab
pmichaud abba
Paul_the_Greek Yagh.
nwellnhof not to forget 0xcafebabe
dalek tracwiki: v14 | dukeleto++ | GitMigration 20:08
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
cotto_work is surprised not to have seen a place called the Ox Cafe.
Paul_the_Greek Or the joint run by the confused brother-in-law: 0cafe 20:09
20:10 whiteknight left
Paul_the_Greek 0xc0ffeebabe 20:10
GeJ Bonjour everyone. 20:11
Paul_the_Greek Howdy GeJ.
20:11 bluescreen left
dukeleto would love if some peeps took a look at github.com/parrot/parrot/blob/leto%...nology.pod and gave feedback 20:13
20:14 bacek joined
dukeleto bacek: GOOD DAY, HUMAN MEAT 20:15
Paul_the_Greek dukeleto: "SHA1 sum" should be "SHA1 hash"? 20:16
moritz it's a "check sum"
GeJ G'Day bacek.
moritz so "sum" isn't all that bad
20:16 shockwave joined
GeJ Servus moritz. 20:16
shockwave pmichaud: ping
moritz hi GeJ 20:17
pmichaud shockwave: pong
Paul_the_Greek moritz: But doesn't it make you think that it is the sum of something?
dukeleto Paul_the_Greek: SHA1 hash seems to be much more common, thanks
moritz Paul_the_Greek: it is
Tene Paul_the_Greek: also notice that the command-line tool used to verify that is named "sha1sum" 20:18
dukeleto Paul_the_Greek: i hear a lot of people use SHA1 sum, but hash seems to be the more common phrase
Paul_the_Greek Standing for "secure hash algorithm" after all.
shockwave pmichaud: Hey. I gave some thought about that field caching thing we were talking about yesterday. Basically,
Tene and, fwiw, the algorith *does* involve quite a few additions. 20:19
chromatic luben, pong
Paul_the_Greek Should have been called 'verifysha1'.
Tene Sure.
20:19 ash_ left
pmichaud maybe it's really "sha1 <sumthing>" :-P 20:19
Paul_the_Greek True, but then we could also call it sha1 xor. 20:20
Tene "sha1sum" is already quite well-established. Using "sum" in that sense is not going to confuse anyone.
Paul_the_Greek: :)
dukeleto is it 10mins to #ps already?
luben chromatic, I have finished the hash refactor to inline hash functions and compare functions.
shockwave pmichaud: The $P0 = assign $P1 ; works really nice, because not only does it stop the need to box a value prior to assign it to a field, which is obviously expense, but it also has the side effect that it works when a field is cached, another method is called and that field is set, and the method returns. But,
chromatic How was it?
Paul_the_Greek Wait, are there XORs? Maybe sha1 shift.
luben 2-3% speedup
it's worth 20:21
chromatic Definitely. 20:22
shockwave Fields of non-scalar types break the whole deal. There are infinite ways in which those fields are can be changed. Every time a function is called, those types of fields have to be invalidated, unless one has a very detailed call-graph as to who changes whom.
pmichaud shockwave: correct.
20:22 aloha joined
luben coretest passes but I have to chase more bugs in make test 20:22
20:23 tadzik1 joined
shockwave pmichaud: Some caching can still be possible. I guess something is better than nothing. And that something may turn out to be substantial in some cases. 20:23
chromatic luben, is this worth doing in a public branch? 20:24
luben yes, I will try to create one in the svn
20:25 cognominal left, cognominal joined
luben here is my working repo if you are interested in the code: luben.spnet.net/gitweb/?p=parrot/.git;a=summary 20:26
dukeleto luben: do you have a gitub id? 20:27
20:27 tadzik left
luben let me see 20:28
pmichaud have to run here... bbiaw
tadzik1 how is threading in Parrot going? I think I remember someone working on it for GSoC, is it soon-to-be-working in Parrot?
chromatic #ps in 1 20:29
tcurtis Chandon implemented green threads, but I think actual parallel execution is blocking on deciding how to approach data sharing and synchronization. 20:30
luben I have just created github account
chromatic wants to change all of the PackFile functions to use STRINGs, not the random blobs of memory C thinks are strings. 20:32
dalek kudo: 19a8b71 | pmichaud++ | src/core/Any-list.pm:
Add Match workarounds for .[] and .{} to (temporarily) allow match objects to do something sane. Addresses RT #75868.
 20:39
dukeleto luben: what is your github username? 20:40
luben: have you sent a CLA?
chromatic luben sent his CLA and has his commit bit. 20:41
luben dukeleto, username: luben, CLA: yes,
dukeleto luben: have you gotten a commit bit to svn yet? just wondering 20:42
luben chromatic, the refactor passes make test again.
dukeleto, yes, since yesterday
chromatic Fantastic.
dukeleto luben: awesome. 20:43
20:44 tadzik1 is now known as tadzik
dukeleto luben: ok, you have a commit bit on github now 20:44
luben dukeleto, thanks 20:46
NotFound Someone fluent with blizkost source here? 20:51
20:53 M_o_C left
tcurtis ns_func_cleanup was merged in r47678. 20:55
mikehh t/op/integer.t and t/pmc/bigint.t FAIL in make corevm/make coretest - error:imcc:loadlib directive could not find library `sys_ops'
all other tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48825 - Ubuntu 10.04 amd64 (g++ with --optimize)
moderator Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets; merge branches; review Git conversion plan 20:56
tcurtis msg whiteknight ns_func_cleanup appears to have been merged into trunk at r47678. Can it be deleted? 20:56
purl Message for whiteknight stored.
aloha OK. I'll deliver the message.
dukeleto cotto_work: i just added some import stuff to the migration wiki 20:58
s/import/important/
dalek rrot: r48826 | tcurtis++ | branches/pct_multi_support:
Delete branch pct_multi_support, which was merged into trunk at r46785.
cotto_work so you did 20:59
tcurtis purl, msg tcurtis Remember to address a specific bot with msgs until purl goes bye-bye.
purl Message for tcurtis stored.
dalek tracwiki: v15 | dukeleto++ | GitMigration
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
dukeleto cotto_work: we need to make sure basic things in tools/ know about git
cotto_work: and the release manager guide is important to have done as well 21:00
cotto_work very good catch 21:02
dukeleto++
21:02 dafrito left
Coke an svn branch to work on the git-support would be a good idea. 21:03
21:04 dafrito joined
dukeleto Coke: i am working in git branches, because they will be able to get merged after the switch. Not so much for svn branches. 21:05
Coke hokay 21:07
dukeleto Coke: but your point is taken
cotto_work We won't be able to merge current svn branches after the git migration?
That sounds important.
dukeleto cotto_work: they are all already git branches
cotto_work and those can be merged fine? ok
dukeleto cotto_work: yeah, i guess you are right. svn branches are all in git, so what I just said was wrong 21:08
chromatic Whew.
dukeleto meant to say "i am going to work in git branches, because I loath svn"
cotto_work ditto
nwellnhof tcurtis: just the "definitely lost" reports for ./perl6 -e -1 21:09
21:15 whiteknight joined
dalek rrot: r48827 | chromatic++ | trunk/src/packfile.c:
[pf] Fixed some compiler warnings.
 21:15
tcurtis nwellnhof: so, leave out the errors it reports?
chromatic Please do. 21:16
nopaste "tcurtis" at 192.168.1.3 pasted "valgrind --leak-check=full ./perl6 -e -1" (48 lines) at nopaste.snit.ch/23253 21:17
chromatic Only two leaks there then.
tcurtis was treating lots of leaks in terms of the amount of memory leaked. 21:19
That second leak would account for most of the leaking that showed up in the spectest run.
chromatic I'm not seeing those leaks. 21:20
The only leak I see is the weird Valgrind/dlerror leak.
Paul_the_Greek Is github.com/parrot our repository? 21:21
cotto_work dukeleto: we should also make sure that the first person to cut the release after our git migration will be knowledgeable enough to deal with any holes in the release manager guide. 21:22
nwellnhof i'm not seeing any leaks for 'perl6 -e -1' either
on 32bit debian
cotto_work github.com/parrot is our organization 21:23
dukeleto cotto_work: yes, 1st release manager after the switch should be very confident with git
Paul_the_Greek cotto_work: Should we all have an account there? 21:24
cotto_work yes 21:25
Paul_the_Greek What would my password be? Why do I only see 5 members?
cotto_work sign up for github and dukeleto will add you to the Parrot org once he knows your github username
nwellnhof dukeleto: how can i find out if i have a commit bit on guthub?
Paul_the_Greek So I just create one of the free accounts? 21:26
cotto_work yup 21:27
pay your $0 and you're good to go
21:27 tadzik left
tcurtis Valgrind says that it is searching for pointers to the not-freed blocks. Is there any reason why, if Rakudo did skip global destruction, that wouldn't find any memory that would have been freed if Rakudo hadn't skipped global destruction? Is Parrot doing some pointer magic that will confuse valgrind? 21:28
Paul_the_Greek msg dukeleto My account name on github is Paul-C-Anagnostopoulos. (Note that doesn't exactly match my Parrot name.) 21:29
purl Message for dukeleto stored.
aloha OK. I'll deliver the message.
nwellnhof tcurtis: afaik, the memory not freed by global destruction would only show up under 'possibly lost' 21:30
dukeleto nwellnhof: when you look at github.com/parrot/parrot, if you are a committer, you will see a SSH clone URL
nwellnhof tcurtis: the real memory leaks are the ones 'definitely lost'. they should show up regardless of global destruction. 21:31
dukeleto nwellnhof: i just added you
Paul_the_Greek Oh, dukeleto, I just messaged you.
21:31 kid51 joined
dukeleto Paul_the_Greek: you have been added 21:31
nwellnhof dukeleto: i see it on github.com/parrot
thanks
dukeleto nwellnhof: no worries 21:32
nwellnhof dukeleto++ # for all the git work
Paul_the_Greek Do you think there will be any confusion due to different usernames on Parrot/svn and git?
dukeleto Paul_the_Greek: we may need to fiddle with AUTHORS for karma to work correctly 21:33
tcurtis chromatic: gc_threshold_tuning appears to have been merged at r48485, can it be deleted now?
chromatic Go ahead. 21:34
Paul_the_Greek I was thinking that things with "Paul C. Anagnostopoulos" in the svn repository won't match up with "Paul-C-Anagnostopoulos" in git.
kid51 tcurtis: My approach is: delete branches immediately after merging. That way, you're not tempted to do further revisions in branch. 21:35
21:35 perlite left
nwellnhof tcurtis: yes, gc_threshold_tuning can be deleted 21:37
tcurtis kid51: seems sensible, but I'm hesitant to delete branches, even if they are merged into trunk and haven't since been worked on, without making sure that there's not some reason that they were kept around. 21:38
dalek rrot: r48828 | tcurtis++ | branches/gc_threshold_tuning:
Delete branch gc_threshold tuning, which was merged in r48485.
 21:39
21:40 perlite joined 21:42 ash_ joined 21:45 ash_ left
chromatic Hm, the NCI thunk generator seems to have a memory leak. 21:50
Or at least generates potentially leaky code.
21:51 Paul_the_Greek left
dalek tracwiki: v16 | dukeleto++ | GitMigration 21:54
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
chromatic See, for example, the Parrot_str_to_cstring calls in pcf_p_tiB3P. 21:56
If something updates the char pointer in place in the called function, kablammo.
kthakore chromatic: or more like 'sqish' .... I thought you were talking about a mem leak 22:01
chromatic That too. 22:03
kthakore so sqish_blammo
chromatic: oh hai btw
chromatic hello
kthakore chromatic: how is life? 22:04
chromatic Busy! Giving a talk tomorrow at PDX.pm on Modern Perl.
kthakore ooh! Good Luck!
Not that you need it! 22:05
tcurtis dl.dropbox.com/u/1277662/reallycleanbts is the backtraces from the Rakudo spectest run under valgrind if anyone else wants to look at them. That file is 705K and contains only the backtraces and the line in front of each backtrace that describes how much was lost.
kthakore tcurtis: how much is the total lost?
chromatic Is that 64-bit Parrot trying to load a 32-bit PBC? 22:07
dukeleto THE HORRRO 22:08
THE HORROR, even
dukeleto slaps forehead
tcurtis I don't think so. I did build gen/core.pir on my 32-bit OS X and transfer it to the 64-bit linux vm, but I'm fairly certain I did all compilation to pbc in the VM. 22:10
dalek tracwiki: v17 | cotto++ | GitMigration 22:11
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
22:12 ash_ joined
chromatic Aha. 22:13
NotFound Done my first pull request in github. I'm near the "master of git" status now ;)
tcurtis kthakore: average of about 132k lost in main, iirc. The total amount definitely lost varies from about 125k to nearly 170k, at a glance. (k in this message is metric, not binary). 22:14
plobsing_ coverage? 22:16
purl coverage is cv.perl6.cz or tapir2.ro.vutbr.cz/cover/cover-results/
dukeleto msg cotto_work how much do we care about our svn -> git author map?
purl Message for cotto_work stored.
aloha OK. I'll deliver the message.
dukeleto NotFound++ # your git-fu is strong, grasshopper 22:19
NotFound I'm ruminating about doing a simple gui library using perl5 Gtk2, with the idea of making the backend pluggable later. 22:25
22:26 cotto_work2 joined
cotto_work2 dukeleto: I don't care as long as there's a reasonable way to manually map between them. 22:27
ttbot Parrot trunk/ r48832 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/386067.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 22:29
kid51 afk
22:30 tcurtis left, cotto_work left
nwellnhof i just benchmarked the charset_massacre branch... 22:35
rakudo build: 3m16s after, 3m 17s before
22:35 dalek left
chromatic +1 22:36
purl 1
nwellnhof callgrind perl6 -e -1: 1.619B Ir after, 1.625B Ir before
22:37 dalek joined
whiteknight is starting to get excited about the github switchover 22:45
cotto_work2 good time to get excited 22:46
dalek tracwiki: v18 | cotto++ | GitMigration 22:47
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
nwellnhof i'm ready to merge charset_massacre right now. all tests PASS, with and without optimize on debian 32bit. 22:55
cotto_work2 Do it.
22:55 cotto_work2 is now known as cotto_work
cotto_work Yeah. What cotto_work2 said. 22:56
nwellnhof incoming...
purl duck!
chromatic Ah, IMCC tailcalls leak SymReg structures.
nwellnhof git-svn++ 22:57
ii makes svn almost fun to work with 22:58
dukeleto nwellnhof: you have not yet begun to feel the pain, grasshopper 23:00
nwellnhof i said "almost fun" 23:01
ttbot Parrot trunk/ r48833 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/386136.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 23:05
dalek rrot: r48833 | nwellnhof++ | trunk (66 files):
Merge branch charset_massacre
dukeleto nwellnhof: don't expect "make fulltest" to act the same under a git-svn clone, FYI 23:06
nwellnhof: svn-specific tests don't work properly with a git-svn clone
nwellnhof what does "make fulltest" do? 23:08
kid51 make fulltest runs the regular make test through alternate runcores; runs tests of examples, coding standards; etc. 23:14
It's the most thorough regularly run result.
The release manager must get it to PASS before each release. 23:15
Others amongst us run it periodically.
23:15 patspam joined
kid51 So, if anyone wants to construct another make target that averts svn-specific tests, I welcome that. 23:16
But we'll eventually have to write git-specific tests as well (my hunch)
23:17 kid51 is now known as kid51_at_dinner
dukeleto nwellnhof: i meant that you can't truse the output of "make fulltest" with a git-svn clone 23:17
I don't know that we will need git-specific tests. There are no svn properties in git. 23:18
We will need to remove svn-specific tests in a branch, and have it ready to merge in when we switch to git. I've added this to the migration checklist
The more things we can do before the switch, and have ready, the better. 23:19
NotFound src/extra_nci_thunks.c contains control codes
src/extra_nci_thunks.c:2857: error: stray ‘\\260’ in program 23:20
mikehh NotFound: It says that it is a generated file? 23:21
NotFound mikehh: it is
23:21 bluescreen joined
NotFound Trying make corevm 23:22
mikehh NotFound: there are changes in r48831 that look like they are from testing (also fails codetest) 23:23
NotFound corevm builds. Let's hope coretest says something interesting
No, only the expeced integer and bigint 23:25
mikehh NotFound: see line 2672/2674 23:27
NotFound mikehh: were? 23:28
purl or used for plural past tense which this sentence obviously it.
cotto_work forget were
purl cotto_work: I forgot were
mikehh NotFound: src/nci/extra_thunks.c 23:29
NotFound Oh, nice, source files without svn properties...
cotto_work probably generated
NotFound cotto_work: yes, generated by human things. 23:30
cotto_work * !!!!!!! DO NOT EDIT THIS FILE !!!!!!! 23:31
looks machine-generated to me
NotFound cotto_work: I talked about codetest results 23:32
The shit in the generated file is probably the result of a bug, doesn't happen on i386 23:33
Great optimization work, boys.
ttbot Parrot trunk/ r48834 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/386163.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 23:35
dalek rrot: r48834 | nwellnhof++ | trunk/src/string/encoding (5 files):
[str] Use str_copy in to_encoding
 23:36
rrot: r48835 | mikehh++ | trunk/src/string/encoding (6 files):
add svn properties
tracwiki: v19 | dukeleto++ | GitMigration 23:40
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
NotFound Keeps failing in amd64 with --optimize, it builds and pass most tests without --optimize 23:44
ttbot Parrot trunk/ r48835 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/386185.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ )
mikehh NotFound: I think that the file needs to be regenerated 23:48
NotFound in pcre.t output there are some "Freeing t_..." messages 23:49
chromatic Hm, that's probably my fault. 23:50
r48831?
NotFound r48836
chromatic Is r48831 the culprit? 23:51
23:52 dngor_ joined
NotFound ack "Freeing " 23:52
src/nci/extra_thunks.c
luben on amd64 I can't even finish the build with --optimize=-O3
NotFound 2672: if (!STRING_IS_NULL(ts_0)) { fprintf( stderr, "Freeing t_0\\n" ); Parrot_str_free_cstring(t_0); }
2674:if (!STRING_IS_NULL(ts_2)) { fprintf( stderr, "Freeing t_2\\n" ); Parrot_str_free_cstring(t_2); }
dalek rrot: r48836 | mikehh++ | trunk/src/string/encoding/ascii.c:
fix codetest failure - line length
 23:53
NotFound luben: I can't even without the =-O3
23:53 dngor left
rrot: r48837 | nwellnhof++ | trunk (26 files):
[str] Switch most users of string_make to Parrot_str_new_init
rrot: r48838 | chromatic++ | trunk/compilers/imcc (3 files):
[IMCC] Plugged tailcall compilation memory leak.
ttbot Parrot trunk/ r48836 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/386214.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ )
luben it's not charset masacre merge fault - it was the same before
and I spent 2 hours debugging my hash reorganization before I found that trunc merge was causing the failing test 23:55
NotFound chromatic: trac.parrot.org/parrot/changeset/48831/ shows it, looks like the commit included the generated file from a previous test
chromatic Testing a patch now.
luben NotFound, It depends on the compiler, with gcc-4.5 it build and fails on make test, with gcc-4.4 it does not build 23:56
ttbot Parrot trunk/ r48837 MSWin32-x86-multi-thread make error tt.taptinder.org/file/cmdout/386220.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 23:57
whiteknight you guys are on fire today 23:58
NotFound Let's fire missiles!

Powered by Cro and the Raku® Programming Language.

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

Thank you!