Parrot 2.6.0 | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | merge html_cleanup (talk to Coke), merge gc_* branches, fix/replace/optimize hashing
Set by moderator on 10 August 2010.
00:00 Psyche^ joined 00:02 davidfetter joined
Paul_the_Greek ping bacek 00:04
So when a deprecation item says [eligible in 2.4], that means that in 2.4 or later it can be eliminated? 00:06
bacek_at_work Paul_the_Greek, pong
Paul_the_Greek Got a moment, bacek?
cotto_work Yes.
Paul_the_Greek Check out this ticket: trac.parrot.org/parrot/ticket/1207 00:07
bacek_at_work Paul_the_Greek, little bit.
cotto_work It actually means "this can be ripped out as soon as 2.3 has been released".
Paul_the_Greek bacek: Should we deprecate the flag or just document that it is unused?
bacek: The find_lex behavior was deprecated in 2.3 00:08
bacek_at_work Paul_the_Greek, I don't think that we need deprecation for it. But (for safety reasons) just put it into DEPRECATION.pod 00:09
Paul_the_Greek We're talking about the flag: document as unused and add to dep.pod
bacek_at_work yes
Paul_the_Greek Okay, will do. Thanks.
bacek_at_work It's exposed into PIR afaiu. So, proper deprecation is a "good thing" 00:10
Paul_the_Greek Yes, that's why I want to document it as unused, in case someone thinks there's a feature when there isn't. 00:11
bacek_at_work check with cotto about current "best practise" of deprecation. There is some page on wiki about it.
Paul_the_Greek Another question?
bacek_at_work go for it :)
Paul_the_Greek The OVERFLOW_FLAG is documented as "Throw math overflow instead of promoting to BigInt."
However, it is only consulted in the Integer PMC. Native integers never promote. 00:12
bacek_at_work We can't promote INTVAL registers
Paul_the_Greek So I'll improve the documentation to say that.
Right, native stays native.
dalek rrot: r48443 | Chandon++ | failed to fetch changeset:
[gsoc_threads] Merge from trunk.
 00:13
Paul_the_Greek Also, some flags are documented as default on when they are default off and vice versa. I'll change the documentation to match the defaults.
cotto_work +1. We don't want our documentation to be any more deceptive than absolutely necessary. 00:16
Paul_the_Greek Agreed. Sarcastic perhaps, but not deceptive. 00:19
Procedure question: So let's say I have a pending patch that has not been committed. It hangs around for awhile. 00:31
Meanwhile someone else changes one of the files I changed.
When it comes time to commit my patch, mismatch problems.
How is that resolved?
cotto_work if it's a simple problem, the person who wants to commit the patch figures it out and resolves the conflicts 00:32
if not, you (as the submitter) get to do it
Paul_the_Greek Sounds about right.
So if I'm suspicious that this will happen, do I push for my patch to be committed, or play it cool? 00:33
dalek TT #1738 created by Paul_the_Greek++: Improve documentation of PARROT_ERRORS_*_FLAG
TT #1738: trac.parrot.org/parrot/ticket/1738
cotto_work push for the commit
Paul_the_Greek How/to whom?
cotto_work I suspect that this isn't merely a theoretical question.
depends on who knows the code and who's available 00:34
Paul_the_Greek Heh. No, it's not. But I'm playing it cool, being a newbie and all.
cotto_work Have you sent in a cla? I suspect you'll have a commit bit pretty soon if you want one. 00:35
Paul_the_Greek So perhaps a msg to the ticket reporter or the last person who looked at it.
cotto_work sure
Paul_the_Greek Ooh, oh my. Yes, I sent it in. Not sure I want to commit yet.
Okay, here goes.
cotto_work We only force commit bits on people about 45% of the time.
Paul_the_Greek I'll take it eventually. 00:36
msg bacek You might want to commit trac.parrot.org/parrot/ticket/1605 before long, since it affects files like pobj.h
purl Message for bacek stored.
Paul_the_Greek Is jkeenan a committer? 00:38
sorear yes 00:39
but we call him kid51 here
seen kid51
purl kid51 was last seen on #parrot 22 hours, 28 minutes and 10 seconds ago, saying: must sleep
Paul_the_Greek Oh, kid51.
msg bacek Reminder that I will on vacation starting Aug. 14.
purl Message for bacek stored.
Paul_the_Greek msg kid51 You might want to commit trac.parrot.org/parrot/ticket/481 before long, since it affects files like set.ops and float.pmc. I will be on vacation starting Aug. 14. 00:40
purl Message for kid51 stored.
Paul_the_Greek purl,help 00:41
purl #perl is not a help channel, and I'm not a help bot. If you want Perl help, try #perl-help or #metallica. or (see the 'help channel' factoid as well) or
Paul_the_Greek purl,messages
Time to pack for the beach. 00:42
whiteknight Paul_the_Greek++ 00:44
cotto_work msg Paul_the_Greek I wouldn't be too worried about the changes in #481. Merging is only tricky when a line that your patch modifies gets changed. In your case where the patch is mostly additions to a file that doesn't get changed often, the patch is not likely to become stale any time soon. 00:46
purl Message for paul_the_greek stored.
cotto_work wonders if purl truncates messages
msg cotto_work I wouldn't be too worried about the changes in #481. Merging is only tricky when a line that your patch modifies gets changed. In your case where the patch is mostly additions to a file that doesn't get changed often, the patch is not likely to become stale any time soon.
purl Message for cotto_work stored.
cotto_work ~~
looks like that one wasn't too long 00:47
msg cotto_work Lorem ipsum dolor sit amet, consectetur adipiscing elit. In lacinia dictum sapien vehicula tincidunt. Praesent in ligula lorem, ut venenatis arcu. Fusce et suscipit felis. Donec vitae sem at dolor commodo sagittis eget pellentesque lacus. Sed sed dui in justo malesuada egestas. Quisque vestibulum pulvinar quam sed viverra. Vestibulum tincidunt. 00:50
purl Message for cotto_work stored.
sorear cotto_work: I don't see why it should, IRC guarantees to silently truncate your message packet (including the addressing and command data) to 510 characters before purl even sees it 00:55
cotto_work how convenient
sorear you may have better luck sending the messages off-channel, PRIVMSG purl : uses up less of the quota than PRIVMSG #parrot:
cotto_work It's not been a limitation I've run into so far, but that might come in handy in the future. 00:56
sorear If you really want to push it, consider using a proxy with no rdns mapping 01:06
luben does out GC have some knowledge about hash memory layouts? 01:15
bacek_at_work luben, nope 01:16
luben ok, thats good :) I am trying to work on hash.c and I am getting some malloc errors. I'll check for errors in my code 01:17
01:26 plobsing joined
Chandon Why does no file in the entire parrot distribution fail to access Hashes through an abstract interface? 01:30
01:31 payload1 joined
Chandon Sorry, every file. 01:31
I was going for a triple negative there and failed.
luben yes, every file pokes with hash internals 01:32
cotto_work probably a (misguided|carefully optimized) attempt to increase performance
luben and the bad part is that the most performance critical paths use hash.pmc but still poke with hash.c internals 01:36
01:39 rurban_ joined
cotto_work We have that on ItsABugHunt. Too bad nobody's gotten to it. 01:43
I wonder how expensive it'd be to go through the proper layers. 01:45
Chandon The basic problem is iterating through a hash, so the "proper" solution would be to make a new HashIterator PMC. 02:08
cotto ~~ 02:29
03:00 janus joined
luben wow, i have succeeded to split allocations for hash bucket/index, after 2h in gdb 03:09
it's not heavy performance hit. now it's time for some optimizations that this change makes possible 03:15
03:26 chromatic joined 03:44 aloha joined 04:02 darbelo joined 04:36 bubaflub joined 04:46 dduncan joined 04:55 Chandon joined 05:00 LoganLK joined
Coke msg cotto "talk to particle about that. he was pursuing it." 05:04
purl Message for cotto stored.
cotto ok
05:10 LoganLK joined
plobsing msg Whiteknight based on wknight8111.blogspot.com/2010/01/pa...trix.html, can you confirm that TT #332 is no longer a problem? 05:11
purl Message for whiteknight stored.
05:42 LoganLK joined 06:02 uniejo joined
darbelo bacek_at_work: ping 06:05
06:15 dduncan left 06:16 jsut_ joined
cotto clock? 06:19
purl cotto: LAX: Thu 11:19pm PDT / CHI: Fri 1:19am CDT / NYC: Fri 2:19am EDT / LON: Fri 7:19am BST / BER: Fri 8:19am CEST / IND: Fri 11:49am IST / TOK: Fri 3:19pm JST / SYD: Fri 4:19pm EST /
cotto Happy Friday, bacek 06:20
darbelo Friday's old news to him by now.
cotto wolfram alpha wins: www.wolframalpha.com/input/?i=calor...0a%20bagel 06:21
bacek_at_work darbelo, ping 06:22
cotto Watch out! It might be a Ping of Death! 06:23
darbelo bacek_at_work: I may be confused by the many pools and arenas in the gc, but is there a sane way to know when I've move the last 'live' buffer from a given pool? 06:25
For the unshared_buffers branch. 06:26
bacek_at_work darbelo, strings are allocated from string_pool only. Constant strings from constant_string_pool but we don't compact it (afair)
darbelo Sorry, I think I meant block. 06:27
I want to free blocks earlier in compact_pool, rather than have that as a separate step. 06:29
bacek_at_work without shared buffers you can just check block->freed + block->free == block->size
tcurtis cotto: What's so remarkable about the number of calories in a bagel? 06:32
darbelo Right, I can make move_one_buffer() update that, and discard the block after the last move.
Okay, I think I have all the data I need for now. 06:36
bacek++
cotto tcurtis, not that, just all the extra info that is displayed 06:37
tcurtis ah, yes. That is quite nice. 06:41
dalek rrot: r48444 | NotFound++ | trunk/src/pmc/capture.pmc:
Don't set custom mark flag on empty Capture
 06:51
moritz purl, msg chromatic the gc_tuning branch gives rakudo a modest speedup, 1414 vs. 1447 wallclock secs on spectest 06:54
purl Message for chromatic stored.
moritz (1447 - 1414) / 1447
purl 0.022805805114029
darbelo moritz: For gc stuff rakudo startup is also a significant benchmark. 07:00
chromatic also likes callgrind instruction counts a whole lot more than wallclock for performance measurements. 07:01
(for rakudo startup, anything else takes just too long.) 07:02
dalek rrot: r48445 | NotFound++ | trunk/t/op/string.t:
test string split with null args
 07:07
cotto If that measurements is an average, that's good news. 07:08
moritz it's an average over 527 test files each 07:09
sorear it sounds like make spectest is mostly a startup time benchmark 07:10
cotto Sure. There wouldn't be many long-running tests. 07:12
moritz there are 07:13
for regexes and trig functioins
sorear hrm. that gives me an idea
sorear wonders how much faster the spectest harness would be if it did App::Persistant-like forking instead of reloading perl6 500 times 07:14
07:19 fperrad joined
dalek parrot: d1c5346 | (Jonathan "Duke" Leto)++ | Makefile:
PERL6PBC no longer needs to be specified

variables. jhelwig++		 07:21
dukeleto sorear: considerably faster 07:22
07:38 mj41 joined
dalek rrot: r48446 | NotFound++ | trunk/src/pmc (2 files):
Don't set custom mark flag on empty RPA/FPA
 07:40
rrot: r48447 | plobsing++ | trunk/src/pmc (2 files):
avoid creating useless packfile objects when performing freeze/thaw operations on packfiles

improves rakudo hello world by 0.586%
mikehh t/perl/Parrot_Test.t - Failed test: 70 in make corevm/make coretest, test and perl_tests in fulltest 07:43
all other tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48445 - Ubuntu 10.04 i386 (g++ with --optimize)
working on fixin' the test for Test::Simple/Builder 0.96 07:44
07:51 mj41 joined
dalek rrot: r48448 | NotFound++ | trunk/src/pmc/fixedstringarray.pmc:
Don't set custom mark flag on empty string arrays
 07:57
08:14 simcop2387 joined 08:23 cosimo joined 08:37 AndyA joined 09:07 lucian joined
mikehh gah that was horrible - think that the test - t/perl/Parrot_Test.t has been sorted out, some more tests before committing :-{ 09:21
09:41 rurban_ joined 09:45 luben_work joined
dalek rrot: r48449 | mikehh++ | trunk/t/perl/Parrot_Test.t:
incorporate changes necessary for test to pass with Test::Builder post version 0.94
 09:54
TT #1739 created by mikehh++: Latest CPAN Module Test::Builder caused test failure 10:17
TT #1739: trac.parrot.org/parrot/ticket/1739
10:44 jsut joined 12:03 whiteknight joined 12:04 AndyA joined
whiteknight good morning, #parrot 12:08
luben_work good localtime() 12:18
it's late afternoon here
12:27 ruoso joined
whiteknight purl msg plobsing you are correct, TT #332 was closable. It is now done. I submitted a smolder report this morning on that platform to prove the case 12:45
purl Message for plobsing stored.
dalek TT #332 closed by whiteknight++: icc-10.0 32bit imcc crash 12:46
TT #332: trac.parrot.org/parrot/ticket/332
13:02 vino_bot joined 13:03 vino_bot joined
luben_work purl msg chromatic I have tested separate allocation of buckets with differend sized and I have done some optimizations on it: lazy buckets allocation, do not rehash until numbre of buckets reaches index size. The results are not optimistic rakudo startup went from 630 to 690ms. I have made a separate function parrot_create_sized_hash but I do not where it could be used in order to boost performance 13:10
purl Message for chromatic stored.
13:15 bluescreen joined
luben_work purl msg chromatic Actually the optimizations (lazy alloc and n<m) do not shave a lot of execution time - from 696 to 690ms. It seems that the cost of separate buckets allocation could not be regained. 13:19
purl Message for chromatic stored.
mikehh whiteknight: query how did you submit a smolder report? 13:37
dalek a: c71335e | fperrad++ | dynext/pmc/luastring.pmc:
Parrot_find_global_s() is gone,
whiteknight mikehh: ah, I didn't know the smolder server was down 13:48
when I ran "make smoke", it gave me the same timeout error that it always does. I just assumed that it was actually working 13:49
13:49 bubaflub joined
particle i've put a ticket in with osuosl to get us smolder. actually, i put it in ten days ago, with no response. i sent a follow-up yesterday, with no response yet. i'll make sure to get a response today, with a date. 13:52
13:54 Paul_the_Greek joined
Paul_the_Greek Good morning folks. 13:54
dalek a: b2d2f85 | fperrad++ | doc/running.pod:
with setup.pir (distutils)
 13:55
mikehh particle: mpeters has been providing smolder services for us, maybe you could contact him and see if he has any updates, etc - Michael Peters <mpeters@plusthree.com> 13:56
Paul_the_Greek Can someone give me the URL for DEPRECATED.pod? All the links to it are broken.
particle i'm sorry, i thought that was done already. am i wrong?
i could certainly ask... he doesn't bite. 13:57
mikehh particle: I emailed him and he replied: Sorry, I'm having some problems with that machine. I'm going to have to move smolder some place else. Please bear with me as I find the time to do that. 13:58
I thought that someone else had taken it up, but have not been in touch with him since
particle ok, well, volunteers.
purl volunteers are FRESH MEAT! MUAHAHAHAHA
mikehh I can send him another email asking him to contact you 13:59
TiMBuS Woah. Oracle are suing Google over the dalvik VM. Apparently one software patent they infringed was: “Interpreting Functions Utilizing A Hybrid Of Virtual And Native Machine Instructions” 14:00
atrodo Uh oh
mikehh I don't see how they can support that patent - previous art - eg Lisp Machine 14:01
atrodo The title is usually overly broad, so, out of curiosity, i'm going to go read the claims of the patent 14:02
dalek rrot: r48450 | mikehh++ | trunk/src/pmc/fixedstringarray.pmc:
fix codetest failure - line length
 14:03
TiMBuS www.scribd.com/doc/35811761/Oracle-...fringement 14:04
for the full text
particle mikehh: if you would, send him an email asking for a status update and copy me (particle@parrot.org)
TiMBuS Oracle America prays for judgment as follows: [...] C) An order that all copies made or used in violation of Oracle America’s copyrights, and all means by which such copies may be reproduced, be impounded and destroyed or otherwise reasonably disposed of; 14:05
um 14:06
Paul_the_Greek Can someone give me the URL for DEPRECATED.pod?
atrodo Patent doesn't sound good. But, it was filed 2002.
particle oracle wants to destroy all computers? 14:08
atrodo More than likely
14:09 fperrad joined
bubaflub Paul_the_Greek: what specifically are you looking for? 14:11
Paul_the_Greek The link to deprecated.pod from the Support Policy page is broken. I'm trying to view the page. 14:12
bubaflub Paul_the_Greek: ah, i see it now 14:13
lemme check what the link should be
i can patch the docs
Paul_the_Greek Great, thanks. I'm submitting a patch to DEPRECATED.pod, which is why I noticed. 14:14
bubaflub Paul_the_Greek: well, we can get that patch in first. point me to the ticket and i'll apply it for ya. 14:15
Paul_the_Greek I'm about to attach the patch. Will you be around in 5 minutes? 14:16
bubaflub Paul_the_Greek: that's strange. DEPRECATED.pod.html isn't giving a 404, but it's just returning nothing. perhaps we need to regenerate it on the website.
Paul_the_Greek: yep.
14:16 plobsing joined
Paul_the_Greek Note that the first link to it (done with L) is broken. The other two links (done with F) are giving blank pages. It's rather odd. 14:16
particle Paul_the_Greek: received your CLA yesterday. 14:18
Paul_the_Greek Wonderful. Now I be official.
Coke Paul_the_Greek: I'm not sure there is a URL. (which would probably suck). why do you need it?
bubaflub Coke: there is a link to DEPRECATED.pod from docs.parrot.org/parrot/latest/html/...y.pod.html that goes nowhere 14:19
Coke also, "make html" is broken. look for a ticket about zero sized files being generated, adn add that one to the pile.
bubaflub Coke: ah, makes sense. i'll update the ticket.
Coke ok. please open a ticket and assign it to me so that doesn't get lost. 14:20
oir update, perfect, danke.
Paul_the_Greek bubaflub: Here's the ticket: trac.parrot.org/parrot/ticket/1738
Should I do something special to a ticket to note that there is a pending removal of a deprecated feature? 14:22
Coke ... that's not the ticket for the html, just to be clear to those logging.
Paul_the_Greek: you could mark it as of type "deprecation", but no one really cares.
bubaflub Coke: updated TT #765
Coke bubaflub: danke.
Paul_the_Greek I guess dep.pod acts as the official list.
Coke yes. 14:23
bubaflub Paul_the_Greek: I've applied your patch, i'm going to run all the codingstd tests. I'll fix any errors and then commit it. 14:25
14:27 robin-gvx joined
dalek TT #1738 closed by Paul_the_Greek++: Improve documentation of PARROT_ERRORS_*_FLAG 14:28
TT #1738: trac.parrot.org/parrot/ticket/1738
TT #1738 reopened by Paul_the_Greek++: Improve documentation of PARROT_ERRORS_*_FLAG
TT #1738: trac.parrot.org/parrot/ticket/1738
Paul_the_Greek Great, thanks bubaflub.
Coke bubaflub? 14:29
purl i think bubaflub is Bob Kuo, mailto:bobjkuo@gmail.com
Coke botsnack
purl :)
Coke wonders how much of his karma is freebies from the beverage. 14:30
bubaflub Paul_the_Greek: committed in r48451. i'll update and close the ticket.
Paul_the_Greek Thanks! 14:31
bubaflub Coke: wadda ya mean?
Coke bubaflub: regarding karma? 14:33
bubaflub regarding "beverage" 14:34
Coke www.coke.com/ ?
bubaflub ahhhhhh
*that* beverage
Coke the eponymous one and only.
bubaflub Coke II: Coke with a vengeance 14:35
dalek rrot: r48451 | bubaflub++ | trunk (2 files):
[TT #1738] Improve docs of PARROT_ERROR_*_FLAG Paul_the_Greek++
 14:36
14:44 theory joined
dalek TT #1738 closed by bubaflub++: Improve documentation of PARROT_ERRORS_*_FLAG 14:44
TT #1738: trac.parrot.org/parrot/ticket/1738
rrot: r48452 | plobsing++ | trunk/t/native_pbc (7 files):
native_pbc platform updates
 14:53
Coke note: things are eligible only after a supported release. if you're adding a note for something to be removed NOW, it's not eligible until just after 2.9 14:56
(so, adding a fresh "eligible in 2.7" is wrong) 14:57
dalek kudo: 938b133 | moritz++ | src/core/Match.pm:
be explicit about .keys, .values, .kv and .pairs in Match
 14:59
bubaflub Coke: should i update that last commit to say 2.9 instead? 15:00
15:01 allison joined
mikehh t/pmc/pmc.t - Failed test: 3 with Segmentation fault 15:05
15:07 chromatic joined
bubaflub mikehh: i'm seeing that same error on r48451 15:07
15:19 fperrad joined 15:20 allison joined
Coke bubaflub: 2.10 15:20
bubaflub Coke: ok, i'll fix that. 15:21
Coke it's eligible for removable in "the first release after the next supported release"
(which practically means 'rip from svn as soon as the next supported release is tagged')
bubaflub Coke: fixed in 48453 15:25
Coke bubaflub: danke.
dalek rrot: r48453 | bubaflub++ | trunk/DEPRECATED.pod:
the first release after the next supported release would be 2.10, not 2.7
 15:26
15:31 bacek joined 15:37 aloha joined
Coke jnthn++ # signature talk 15:40
dalek rrot: r48454 | fperrad++ | trunk/t/op/calling.t:
add test for TT#1733
 15:43
Coke I thought notfound already added a test for that.
huh 15:45
15:48 jan joined
dalek TT #1733 closed by fperrad++: calling convention broken 15:51
TT #1733: trac.parrot.org/parrot/ticket/1733
Coke oh, notfound said we needed a test, he didn't write one. ;) 15:59
chromatic t/pmc.t #3 segfaults for me 16:05
ImageIO PMC changes... I can fix that. 16:08
mikehh chromatic: got a backtrace and # src/packfile.c:590: failed assertion 'pf' 16:20
chromatic Yeah, it's r48447.
I'm going to put in a quick fix, then give plobsing some suggestions to improve things.
My Right Fix isn't.
msg plobsing Please see r48455. 16:23
purl Message for plobsing stored.
particle try the left one 16:26
Coke gives up on #perl6 again for a while. 16:27
chromatic Hm, someone sped up Rakudo again. 16:31
jnthn \\o/ 16:32
luben_work chromatic, yes
jnthn someone++
dalek rrot: r48455 | chromatic++ | trunk/src/pmc/imageio.pmc:
[PMC] Fixed segfaults in ImageIO PMC's destroy().

attribute" flag is on but there's no PackFile attribute. This makes C sad. The culprit is r48447. A better approach is to use PObj_custom_destroy_SET() only when it's okay to destroy this attribute, but that fix will take longer. In the meantime, this works at the expense of a bit of extra work.		 16:33
luben_work chromatic, do you want a patch that reverts the constant_pmc checks in fill_params, that I have introduces with last patch?
chromatic I'm not sure. I think that may have been noise. 16:35
luben_work ok, I do not see a difference either
next thing to try is paged allocation for hash->buckets 16:36
chromatic, do we use macros of that type: pastebin.com/Ph4UrqJQ 16:39
I am not sure about the compilers support, coding standards etc. 16:40
chromatic Seems reasonable to me. 16:41
luben_work I have replaced all copy/paste code in the tree with this macro 16:42
so if I change hash internals, the only place that I have to update is this macro
chromatic I like it. 16:43
luben_work I could send a patch 16:44
Coke wouldn't an inline function theoretically DTST?
particle and be better for PARROT_EXPORT? 16:45
embedders will want to take advantage of this, and macros polluting the global namespace is bad. 16:47
Coke Oh. I just reread the macro. nevermind.
(that does NOT look extractable into an function) 16:48
chromatic Yeah, those concerns don't apply to this macro.
particle yeah. do we have a coding convention for macro names? case, prefix, etc? 16:51
16:54 allison joined
dalek kudo: c41bcd7 | moritz++ | src/core/Match.pm:
Match.new roundtrips from Match.perl
 17:00
darbelo allison: Hi. 17:07
luben_work I have sent a patch to parrot-dev list, for evaluation and discussion of proposed macros and their usage 17:19
time to go home... 17:21
dalek rrot: r48456 | darbelo++ | branches/unshared_buffers/src/gc/mark_sweep.c:
Remove misleading comment.
 17:23
rrot: r48457 | darbelo++ | branches/unshared_buffers/src/gc/alloc_resources.c:
Turn speculative comment into action. Harms nothing.
rrot: r48458 | darbelo++ | branches/unshared_buffers/src/pmc/stringbuilder.pmc:
Update stringbuilder to the new substr semantics.
rrot: r48459 | darbelo++ | branches/unshared_buffers/src/gc/alloc_resources.c:
Remove a check for a condition that can't be true.
rrot: r48460 | darbelo++ | branches/unshared_buffers/src/gc (2 files):
Prune the Variable_sized_pool struct of members that were only useful with cow.
rrot: r48461 | darbelo++ | branches/unshared_buffers/src/gc/alloc_resources.c:
Make sure we keep the free mem counters up to date in the buffer_pools.
rrot: r48462 | darbelo++ | branches/unshared_buffers/include/parrot/pobj.h:
Remove a macro with a misleading name and some obsolete pointer masking.
rrot: r48463 | darbelo++ | branches/unshared_buffers/src/gc/alloc_resources.c:
Add a function to free just one block and swith compact_pool to use it.
rrot: r48464 | darbelo++ | branches/unshared_buffers/src/gc/alloc_resources.c:
Properly nest checks.
rrot: r48465 | darbelo++ | branches/unshared_buffers/src/gc/alloc_resources.c:
There is no point in calling compact_pool() after calling Parrot_gc_mark_and_sweep(). The pools are already compacted by then.
chromatic Is r48465 a cherry pick to trunk? 17:25
17:33 allison joined
allison darbelo: flakey conference network 17:33
darbelo: hi
purl hi, allison.
cotto_work ~~ 17:38
darbelo allison: I'm still working on unshared_buffers, which has kinda turned into gc refactor work by now. 17:40
allison darbelo: sounds like a case of creature feep :) 17:41
(feature creep)
17:41 rurban_ joined
allison darbelo: how's the general progress otherwise? is unshared_buffers a blocker, or mostly on the side? 17:42
darbelo It's mostly on the side by now. The NFG is pretty much all there now, and it allowed some cleanups on the charset/encoding side, that are in the branch as well. 17:43
allison darbelo: excellent 17:44
darbelo I thought I would get a sizable benefit from reducing the string header size, which I did separately in unshared_buffers.
That sped up our string becnhmarks by a solid 10%, but chews through our string pools faster, which causes trouble for Rakudo. 17:45
And PCT parsers in general, really. 17:46
allison because we're creating more string copies?
chromatic Substrings, to be specific.
allison yah, that was the risk we predicted
(specifically, in removing the last traces of the COW code) 17:47
darbelo AFAICT, most are small and fairly short lived, but they fragment our pools more and tickle compact_pools in the wrong way. 17:48
allison more heavily exposing our need for copying and compacting GC 17:49
darbelo We also do some questionably-timed string compacting along the way. Which doesn't help.
chromatic darbelo, can you annotate STRING creation to see the sizes of these substrings?
allison so what have you been focusing on in the GC refactors? 17:50
darbelo allison: Yeah, I'm trying to add some smarts to compact_pool now, make it more 'precise'. 17:51
allison darbelo: good start
purl good start is probably the perldoc for files in compilers/PGE - but I feel my pain. documentation comes last after code, tests, and then maybe examples, it seems.
allison hush, purl
purl o/` don't you cry o/`
whiteknight purl forget good start 17:53
purl whiteknight: I forgot good start
darbelo I've also noticed that we do call substr with a constant 1 as 'length' argument, which is probably better handled by ord and an integer compare, but that's a separate thing. 17:55
chromatic: I can annotate the calls to substr() fairly easily. Not sure about other codepaths. 17:58
chromatic That should give us PCT information.
18:01 dafrito joined 18:03 davidfetter joined 18:04 AndyA joined
dalek TT #1740 created by ild++: pbc_dump crashes on certain inputs 18:06
TT #1740: trac.parrot.org/parrot/ticket/1740
darbelo Compiling rakudo's Actions.pm with annotated substr now. 18:09
cotto_work is ild in here by some other name? 18:10
I'm not sure how I feel about playing with a pbc file named exploit_0_0 18:11
darbelo 690237 total calls, 436821 made with lenght=1 18:12
purl: 436821 / 690237
purl 0.63285654057954
cotto_work though having a bunch of broken pbcs for debugging is nice. ild++ 18:13
18:14 luben joined
chromatic ord and compare it is! 18:15
darbelo To be fair, not all of thse are *constant* 1s, since I annotated the C side.
chromatic I wonder if they correspond to whitespace checks. 18:16
darbelo Also, each of those is taking up sizeof(void *) + the char itself + alignment in the pool, which is still smaller than the string header.
It's likely.
I'm not familiar enough with nqp internals to say for sure, but it's the most likely option. 18:17
chromatic Maybe we need an op for "Skip whitespace". pmichaud will know better, but I suspect he may say "In some cases we want to capture that."
darbelo What, the witespace? 18:18
chromatic Right.
Although within the non-capturing ws rule....
nopaste "darbelo" at 192.168.1.3 pasted "ack for pir::substr in rakudo's src/Perl6/Actions.pm" (8 lines) at nopaste.snit.ch/22758 18:22
darbelo The code "pir::substr(~$<typename>, 0, 2) eq '::'" will create two GC-ables, and do a string compare, right? 18:23
chromatic Looks like it.
purl No it doesn't, shut your hole!
darbelo Even with shared buffers it strikes me as a questionable thing to do. 18:24
chromatic It could chew through STRING headers in a hurry. 18:25
We need something more like streq_at 18:27
darbelo I wonder if a index variant that 'stops after this much' is the right thing to use here. 18:28
chromatic That comparison API we worked out a while back might do the trick. 18:30
The question is "Does this string at this position contain exactly this substring?" 18:32
18:32 brianwisti joined 18:37 robin-gvx joined
dalek kudo: 44f0ec0 | (Kyle Hasselbacher)++ | docs/ (2 files):
[docs] Misspellings caught by ispell
 18:41
chromatic darbelo, that's one I think we should take to the list to figure out what PCT could really use and what Parrot should provide. 19:01
19:04 allison joined
darbelo chromatic: Okay, I'll mail parrot-dev later today. 19:04
chromatic +1
purl 1
chromatic It does tickle my intuition as something PCT could do better for great speed. 19:05
19:06 AndyA_ joined
darbelo Also, I think I've found a "leak" in our pool compaction scheme. 19:08
19:09 lucian joined
darbelo In order to cut down on copying we skip all pool blocks over 80% full. But, when creating storage for buffers bigger than the top block's free count we give that buffer a block all on it's own, 100% full. 19:11
allison darbelo: that's nutty 19:12
chromatic Seems like it'll never get freed.
darbelo Also, whenever we create one of this blocks we put it into the pool as the top block, regardless of the free size of the previous top block. 19:16
That means we will be performing a really big, possibly unneeded, allocation on the next compaction run. 19:17
19:18 LoganLK joined
chromatic How fixable is it? 19:18
darbelo I can fix the second part fairly easily, by passing in a "Don't put the new block at the top' to the block allocator. The 'leak' I have to think about. 19:22
chromatic Create a block of double that size?
dalek kudo: 0839993 | (Patrick Abi Salloum)++ | src/core/MAIN.pm:
Added short arguments parsing to MAIN
 19:23
darbelo There's a todo in alloc_resources.c 19:24
* TODO - Big blocks
*
* Mark the block as big block (it has just one item)
* And don't set big blocks as the top_block.
chromatic Ah, so that's what it meant. 19:25
darbelo It's the part of mem_allocate that creates the 'big block'
chromatic I must have read that code several dozen times while trying to decipher it.
darbelo The other parts of the riddle were inside compact_pool and free_old_mem_blocks 19:26
OTOH, as long as we compact unconditionally on every mark and sweep (which is triggered on every mem_allocate call) the mis-handling of big blocks isn't our biggest problem. 19:32
I think we might need a threshold system to make compacting tamer or more aggressive as needed. 19:38
Coke pmichaud: ping. 19:41
chromatic That's the idea of the gc_threshold branch, or whatever its name is.
darbelo I thought that was for the header pools. 19:43
chromatic Oh, right. I thought you meant more broadly than you did. 19:44
darbelo As it stands now, every mark and sweep run is a full compact run. I want to sometimes skip it, or maybe even run a 'lazy' compact. 19:48
chromatic If we know the sizes, yeah. 19:49
moritz maybe just compact on every 5th mark?
tewk_ darbelo: only compact when you are going to regain at least some % of the space. 19:50
chromatic Lazy compact only when you can reclaim enough for the next allocation. 19:52
mikehh All tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48465 - Ubuntu 10.04 i386 (g++ with --optimize)
Paul_the_Greek Does the VM store the same string more than once? 19:56
chromatic That depends what you mean by "the same". There's no string interning at runtime. 19:57
Paul_the_Greek Okay, so the same content can show up more than once.
chromatic Yes.
darbelo Also, in order to make sure 'big blocks' eventually die. We ocasionally have to do a "more aggressive" run.
Paul_the_Greek Boy, that really makes me think that 1-character strings should be preallocated.
chromatic Preallocation does seem useful. 19:58
Paul_the_Greek Consider the overhead for each 1-character string.
About 32 to 1 or something.
chromatic That and the GC pressure. 19:59
Paul_the_Greek I'd love to see benchmarks of interning vs. not interning.
chromatic I'm curious to hear what pmichaud says about darbelo's findings though. If we can avoid the creation and disposal of substrings for that part of PCT, what happens?
cotto_work How often do we create 1-character strings? It sounds like a good idea but it'd be a good idea to profile first.
Paul_the_Greek Yes, it would. And it's related to whether the assembler optimizes substr(,,1). 20:00
Consider also the possibility of a substr1 opcode. 20:06
Or an optimization to chr(ord()). 20:07
61 uses or chr() in the various PIR files; 504 uses of substr , , 1 20:09
20:09 dafrito joined
darbelo Paul_the_Greek: See irclog.perlgeek.de/parrot/2010-08-13#i_2700241 20:12
Paul_the_Greek No thought shall go unrecorded. 20:14
It would be relatively easy to preallocate 1-character strings and then see if we get any improvement. 20:15
Are strings ASCII or Unicode by default?
chromatic It's feasible with immutable strings.
The default encoding is ascii. 20:16
darbelo For the record, the rakudo build passes --encoding=utf8 to parrot-nqp. 20:17
Paul_the_Greek So preallocate 256 (128?) ASCII strings and 128 Unicode strings. Fat strings would be good.
In fact, even with strings as they are, the preallocated ones could be fat, since they are pinned.
dafrito purl, fat strings? 20:18
purl dafrito: i haven't a clue
darbelo
.oO(a rope?)
Paul_the_Greek dafrito: A string whose data is stored right after the header, rather than in the variable-sized memory areas.
dafrito Paul_the_Greek: ah, okay 20:19
20:31 bluescreen joined
luben it does not seep a good idea to hand edit a patch file :) 20:34
Paul_the_Greek Unless you do it very very carefully. 20:35
chromatic I've done it. The trick is not to forget to delete trailing newlines. 20:39
luben Paul_the_Greek, yes, but half of the changes are gone, another unrelated changes are in, I have missed them (about the patch I sent with hash iteration macros proposition on the mailing list)
Paul_the_Greek Okay, I'm convinced. Don't do it. 20:40
luben chromatic, I am still new in handediting diffs :)
purl, git mirror? 20:41
purl luben: wish i knew
luben purl, git?
purl git is like svn but not a braindamaged amoeba or perl5.git.perl.org/perl.git or at git-scm.com/ or the source of all SCM happiness in the world. or the Emacs of source code management systems or easy!
luben purl, git-svn 20:42
purl i think git-svn is amazingly great or trac.parrot.org/parrot/wiki/git-svn-tutorial
20:43 mikehh joined
luben is this the official git mirror: github.com/leto/parrot 20:43
dafrito luben: AFAIK, yes 20:44
luben nice :) 20:45
bubaflub luben: that mirror is managed by dukeleto
luben I am lost in half a dozen svn checkouts here :( And you could not locally commit :( So, its everything or nothing 20:46
dukeleto++ 20:47
20:56 tcurtis joined 21:02 davidfetter joined 21:48 whiteknight joined 21:51 masak joined
masak I have a ByteBuffer question. how do I say "get a ByteBuffer from this string using this encoding"? 21:52
I have a feeling my question is slightly ill-posed, because I seem to recall that Parrot strings have an encoding in themselves.
darbelo masak: Yes. 21:53
You can transcode the string if it isn't in the encoding you need.
masak so maybe what I want is "turn this string to use that encoding, and then turn it into a ByteBuffer"?
right.
how?
darbelo $I0 = find_encoding 'Your Encoding' 21:54
$S0 = trans_encoding $S0, $I0
masak thank you. 21:55
where can I find a list of the available encodings?
darbelo fixed_8, utf8, utf16, ucs2, ucs4 21:56
masak ok. 21:57
let's say I wanted latin-1 to be in that list. what are my options?
cotto_work files in src/string/encoding/
dukeleto luben: is it not official, but it is a mirror
NotFound masak: ByteBuffer works the other way, it provides way to encode strings from raw data.
darbelo masak: That would be a charset, in the current scheme.
dukeleto luben: check the git-svn wiki page on parrot.org for a git-svn mirror 21:58
masak ah, ok.
dukeleto luben: gotta go, good luck!
masak NotFound: I think I'm using ByteBuffer to go in both directions in Rakudo currently.
where can I find a list of the available charsets? :) 21:59
darbelo We call it, iso-8859-1 and it uses fixed_8 as it's encoding.
NotFound masak: yeah, but it takes the string as is, without ability to recoding.
luben dukeleto++ thanks a lot, it seems that I have made myself a workflow with git in the last 1-2 years, and I miss some freatures with svn
masak ah, src/str/charset, of course.
darbelo ascii, iso-8859-1, unicode and binary.
luben I'll try git-svn page 22:00
masak thanks. this is a lot of information, but it's things I need to know anyway. darbelo++ NotFound++
NotFound masak: it can be added, but I'm not sure if it will give a measurable performance gain. 22:02
masak NotFound: no, me neither.
cotto_work luben: From its name, it's not clear what the parrot_hash_iterator macro does. Maybe parrot_hash_iterator_advance would be clearer. There are also some codingstd issues, but overall your patch looks like an improvement. 22:03
Do you mind filing a ticket?
luben cotto_work, thanks, I'l file a tiket. May be parrot_hash_iterator_advance is a better name. 22:05
masak is there a find_charset and trans_charset just like there's a find_encoding and trans_encoding? 22:06
cotto_work We might have a naming convention that says what the name should be.
darbelo masak: Yep. 22:08
masak \\o/
22:12 jsut_ joined
whiteknight In NQP, how do I register a built-in PMC type with P6metaclass? 22:17
jnthn Think that's the .register method 22:18
whiteknight jnthn: ok, let me move back a step: Where do I get a reference to P6metaclass?
jnthn whiteknight: Easiest way is just to .HOW something you know uses it. 22:19
(In Rakudo we just do that and cache it somewhere.)
whiteknight I'm trying to make basically something like a shared header in NQP that I can include into other NQP programs (by compiling it down to pbc and loading it). So I have a small file with basically one INIT block and no classes 22:21
and I was hoping NQP would include a reference to P6metaclass somewhere in the generated
PIR, but it doesnt
jnthn whiteknight: Are you in the Parort namespace? 22:22
whiteknight jnthn: I guess? I haven't specified any other namespace
jnthn If P6object.pbc is loaded then you should just have P6metaclass available.
See the synopsis in P6object.pir. 22:23
whiteknight P6object.pbc. I think that's what I'm looking for 22:26
thanks
dalek TT #1741 created by luben++: Macro abstraction for hash iterations 22:35
TT #1741: trac.parrot.org/parrot/ticket/1741
TT #1742 created by nwellnhof++: Skip compact_pool if all blocks are almost full
TT #1742: trac.parrot.org/parrot/ticket/1742
22:41 kid51 joined
whiteknight is there any way to unload a library from Parrot? 22:57
I don't see an "unloadlib" opcode, and no methods on the ParrotLibrary PMC 22:58
darbelo Ending your progrma? 23:00
whiteknight no, trying to clear things out for tests 23:02
darbelo Well, they are not singletons, so the gc should collect them, eventually. Unless it comes from the constant pool. 23:06
Either somthing is keeping it alive, in which case you could null out the reference and the gc will take care of it, or it's a constant and you are hosed. 23:07
dalek rrot-linear-algebra: 07879a6 | Whiteknight++ | (4 files):
add a new file src/nqp/pla.nqp, which is a bootstrap file which helps to setup

P6metaclass. Add a quick example of it's use in examples/nqp.nqp
rrot-linear-algebra: 7695a74 | Whiteknight++ | examples/nqp.nqp:
rename the example to something a little better
rrot-linear-algebra: bc1d869 | Whiteknight++ | src/nqp/pla.nqp:
load linalg, expecting it to be installed. Don't load it from a relative address
rrot-linear-algebra: 65bf0ac | Whiteknight++ | src/nqp/pla.pir:
remove a generated file from the repo
 23:08
chromatic Hm, Rakudo's sort_candidates() is spendy.
... mostly because is_narrower() is super spendy.
StringBuilder's append_format() is worse. 23:09
jnthn chromatic: Does lots and lots of method calls. 23:10
chromatic ... thanks to Parrot_pcc_fill_params_from_varargs via Parrot_pcc_fill_params_from_c_args.
Yeah, that looks like the culprit.
jnthn The good news is that the sorting is static so one day we can do it at compile time and serialize it. 23:11
chromatic Allocating an RIA for parameter flags is expensive.
purl (649406 - 70250 ) / 649406 23:12
purl 0.89182422090341
jnthn chromatic: The thing is, just about all the calls it does are to an ACCEPTS method and it's always two args.
chromatic Wouldn't it be nice to be able to cache that signature somehow? 23:13
jnthn Yes. :-)
Do you know how to do that?
chromatic Without changing the current API?
jnthn Ah, OK 23:14
Parrot_ext_call is maybe not so ideal in this case. :-)
chromatic It isn't.
jnthn But I'm not sure what API I want.
s/want/should be using/
(if it exists)
chromatic I think we have to separate signature from context, if we haven't finished that already.
jnthn The binder also does loads of ACCEPTS calls 23:15
So we can improve that too. 23:16
chromatic If that means we can have immutable signatures, we're mostly there.
Immutable signatures helps PIR too. 23:17
jnthn *nod* 23:20
kthakore hi chromatic 23:26
Paul_the_Greek purl,messages 23:32
dalek rrot: r48466 | darbelo++ | branches/unshared_buffers/src/gc/alloc_resources.c:
Apply nwellnhof's patch from TT #1742.
 23:47
Paul_the_Greek How do people decide which patches to commit when? 23:52
chromatic If it applies cleanly, passes tests, and looks sane to someone who knows something about the relevant code, it's safe enough to apply. 23:54
cotto_work deprecations that break compatibility are treated more formally and significant refactors usually go into a branch 23:56
but there's not much more than that
chromatic A couple of days before the release, the month's release manager asks people to stop committing code changes. 23:58
cotto_work msg cotto trac.parrot.org/parrot/ticket/1605
purl Message for cotto stored.
Paul_the_Greek There are many on the New Patches list that have been around for many days, which is what prompted my question. 23:59
cotto_work It's a matter of tuits.

Powered by Cro and the Raku® Programming Language.

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

Thank you!