Camelia, the Perl 6 bug

IRC log for #parrot, 2010-08-13

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 Psyche^ joined #parrot
00:02 davidfetter joined #parrot
00:04 Paul_the_Greek ping bacek
00:06 Paul_the_Greek 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
00:06 Paul_the_Greek Got a moment, bacek?
00:06 cotto_work Yes.
00:07 Paul_the_Greek Check out this ticket: http://trac.parrot.org/parrot/ticket/1207
00:07 bacek_at_work Paul_the_Greek, little bit.
00:07 cotto_work It actually means "this can be ripped out as soon as 2.3 has been released".
00:07 Paul_the_Greek bacek: Should we deprecate the flag or just document that it is unused?
00:08 Paul_the_Greek bacek: The find_lex behavior was deprecated in 2.3
00:09 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
00:09 bacek_at_work yes
00:09 Paul_the_Greek Okay, will do. Thanks.
00:10 bacek_at_work It's exposed into PIR afaiu. So, proper deprecation is a "good thing"
00:11 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.
00:11 Paul_the_Greek Another question?
00:11 bacek_at_work go for it :)
00:11 Paul_the_Greek The OVERFLOW_FLAG is documented as "Throw math overflow instead of promoting to BigInt."
00:12 Paul_the_Greek However, it is only consulted in the Integer PMC. Native integers never promote.
00:12 bacek_at_work We can't promote INTVAL registers
00:12 Paul_the_Greek So I'll improve the documentation to say that.
00:12 Paul_the_Greek Right, native stays native.
00:13 dalek parrot: r48443 | Chandon++ | failed to fetch changeset:
00:13 dalek parrot: [gsoc_threads] Merge from trunk.
00:13 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48443/
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.
00:16 cotto_work +1.  We don't want our documentation to be any more deceptive than absolutely necessary.
00:19 Paul_the_Greek Agreed. Sarcastic perhaps, but not deceptive.
00:31 Paul_the_Greek Procedure question: So let's say I have a pending patch that has not been committed. It hangs around for awhile.
00:31 Paul_the_Greek Meanwhile someone else changes one of the files I changed.
00:31 Paul_the_Greek When it comes time to commit my patch, mismatch problems.
00:31 Paul_the_Greek How is that resolved?
00:32 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 cotto_work if not, you (as the submitter) get to do it
00:32 Paul_the_Greek Sounds about right.
00:33 Paul_the_Greek 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
00:33 dalek TT #1738: http://trac.parrot.org/parrot/ticket/1738
00:33 cotto_work push for the commit
00:33 Paul_the_Greek How/to whom?
00:33 cotto_work I suspect that this isn't merely a theoretical question.
00:34 cotto_work 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.
00:35 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.
00:35 cotto_work sure
00:35 Paul_the_Greek Ooh, oh my. Yes, I sent it in. Not sure I want to commit yet.
00:35 Paul_the_Greek Okay, here goes.
00:35 cotto_work We only force commit bits on people about 45% of the time.
00:36 Paul_the_Greek I'll take it eventually.
00:36 Paul_the_Greek msg bacek You might want to commit http://trac.parrot.org/parrot/ticket/1605 before long, since it affects files like pobj.h
00:36 purl Message for bacek stored.
00:38 Paul_the_Greek Is jkeenan a committer?
00:39 sorear yes
00:39 sorear but we call him kid51 here
00:39 sorear seen kid51
00:39 purl kid51 was last seen on #parrot 22 hours, 28 minutes and 10 seconds ago, saying: must sleep
00:39 Paul_the_Greek Oh, kid51.
00:39 Paul_the_Greek msg bacek Reminder that I will on vacation starting Aug. 14.
00:39 purl Message for bacek stored.
00:40 Paul_the_Greek msg kid51 You might want to commit http://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.
00:41 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
00:41 Paul_the_Greek purl,messages
00:42 Paul_the_Greek Time to pack for the beach.
00:44 whiteknight Paul_the_Greek++
00:46 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.
00:46 * cotto_work wonders if purl truncates messages
00:46 cotto_work 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.
00:46 purl Message for cotto_work stored.
00:46 cotto_work ~~
00:47 cotto_work looks like that one wasn't too long
00:50 cotto_work 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.
00:55 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
00:55 sorear you may have better luck sending the messages off-channel, PRIVMSG purl : uses up less of the quota than PRIVMSG #parrot:
00:56 cotto_work It's not been a limitation I've run into so far, but that might come in handy in the future.
01:06 sorear If you really want to push it, consider using a proxy with no rdns mapping
01:15 luben does out GC have some knowledge about hash memory layouts?
01:16 bacek_at_work luben, nope
01:17 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:26 plobsing joined #parrot
01:30 Chandon Why does no file in the entire parrot distribution fail to access Hashes through an abstract interface?
01:31 payload1 joined #parrot
01:31 Chandon Sorry, every file.
01:31 Chandon I was going for a triple negative there and failed.
01:32 luben yes, every file pokes with hash internals
01:32 cotto_work probably a (misguided|carefully optimized) attempt to increase performance
01:36 luben and the bad part is that the most performance critical paths use hash.pmc but still poke with hash.c internals
01:39 rurban_ joined #parrot
01:43 cotto_work We have that on ItsABugHunt.  Too bad nobody's gotten to it.
01:45 cotto_work I wonder how expensive it'd be to go through the proper layers.
02:08 Chandon The basic problem is iterating through a hash, so the "proper" solution would be to make a new HashIterator PMC.
02:29 cotto ~~
03:00 janus joined #parrot
03:09 luben wow, i have succeeded to split allocations for hash bucket/index, after 2h in gdb
03:15 luben it's not heavy performance hit. now it's time for some optimizations that this change makes possible
03:26 chromatic joined #parrot
03:44 aloha joined #parrot
04:02 darbelo joined #parrot
04:36 bubaflub joined #parrot
04:46 dduncan joined #parrot
04:55 Chandon joined #parrot
05:00 LoganLK joined #parrot
05:04 Coke msg cotto "talk to particle about that. he was pursuing it."
05:04 purl Message for cotto stored.
05:04 cotto ok
05:10 LoganLK joined #parrot
05:11 plobsing msg Whiteknight based on http://wknight8111.blogspot.com/​2010/01/parrot-test-matrix.html, can you confirm that TT #332 is no longer a problem?
05:11 purl Message for whiteknight stored.
05:42 LoganLK joined #parrot
06:02 uniejo joined #parrot
06:05 darbelo bacek_at_work: ping
06:15 dduncan left #parrot
06:16 jsut_ joined #parrot
06:19 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 /
06:20 cotto Happy Friday, bacek
06:20 darbelo Friday's old news to him by now.
06:21 cotto wolfram alpha wins: http://www.wolframalpha.com/inp​ut/?i=calories%20in%20a%20bagel
06:22 bacek_at_work darbelo, ping
06:23 cotto Watch out!  It might be a Ping of Death!
06:25 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:26 darbelo 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)
06:27 darbelo Sorry, I think I meant block.
06:29 darbelo 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
06:32 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.
06:36 darbelo Okay, I think I have all the data I need for now.
06:36 darbelo bacek++
06:37 cotto tcurtis, not that, just all the extra info that is displayed
06:41 tcurtis ah, yes. That is quite nice.
06:51 dalek parrot: r48444 | NotFound++ | trunk/src/pmc/capture.pmc:
06:51 dalek parrot: Don't set custom mark flag on empty Capture
06:51 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48444/
06:54 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.
06:54 moritz (1447 - 1414) / 1447
06:54 purl 0.022805805114029
07:00 darbelo moritz: For gc stuff rakudo startup is also a significant benchmark.
07:01 darbelo chromatic also likes callgrind instruction counts a whole lot more than wallclock for performance measurements.
07:02 darbelo (for rakudo startup, anything else takes just too long.)
07:07 dalek parrot: r48445 | NotFound++ | trunk/t/op/string.t:
07:07 dalek parrot: test string split with null args
07:07 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48445/
07:08 cotto If that measurements is an average, that's good news.
07:09 moritz it's an average over 527 test files each
07:10 sorear it sounds like make spectest is mostly a startup time benchmark
07:12 cotto Sure.  There wouldn't be many long-running tests.
07:13 moritz there are
07:13 moritz for regexes and trig functioins
07:13 sorear hrm.  that gives me an idea
07:14 * sorear wonders how much faster the spectest harness would be if it did App::Persistant-like forking instead of reloading perl6 500 times
07:19 fperrad joined #parrot
07:21 dalek plparrot: d1c5346 | (Jonathan "Duke" Leto)++ | Makefile:
07:21 dalek plparrot: PERL6PBC no longer needs to be specified
07:21 dalek plparrot: The home of perl6.pbc is now automagically inferred from parrot_config
07:21 dalek plparrot: variables. jhelwig++
07:21 dalek plparrot: review: http://github.com/leto/plparrot/commit/d​1c5346d7f4fd9eac05f64649a0fb6c09fec40ef
07:22 dukeleto sorear: considerably faster
07:38 mj41 joined #parrot
07:40 dalek parrot: r48446 | NotFound++ | trunk/src/pmc (2 files):
07:40 dalek parrot: Don't set custom mark flag on empty RPA/FPA
07:40 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48446/
07:40 dalek parrot: r48447 | plobsing++ | trunk/src/pmc (2 files):
07:41 dalek parrot: avoid creating useless packfile objects when performing freeze/thaw operations on packfiles
07:41 dalek parrot: also avoids generating PBC headers for each constant in the const table
07:41 dalek parrot: improves rakudo hello world by 0.586%
07:41 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48447/
07:43 mikehh t/perl/Parrot_Test.t - Failed test:  70 in make corevm/make coretest, test and perl_tests in fulltest
07:43 mikehh all other tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48445 - Ubuntu 10.04 i386 (g++ with --optimize)
07:44 mikehh working on fixin' the test for Test::Simple/Builder 0.96
07:51 mj41 joined #parrot
07:57 dalek parrot: r48448 | NotFound++ | trunk/src/pmc/fixedstringarray.pmc:
07:57 dalek parrot: Don't set custom mark flag on empty string arrays
07:57 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48448/
08:14 simcop2387 joined #parrot
08:23 cosimo joined #parrot
08:37 AndyA joined #parrot
09:07 lucian joined #parrot
09:21 mikehh gah that was horrible - think that the test - t/perl/Parrot_Test.t has been sorted out, some more tests before committing :-{
09:41 rurban_ joined #parrot
09:45 luben_work joined #parrot
09:54 dalek parrot: r48449 | mikehh++ | trunk/t/perl/Parrot_Test.t:
09:54 dalek parrot: incorporate changes necessary for test to pass with Test::Builder post version 0.94
09:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48449/
10:17 dalek TT #1739 created by mikehh++: Latest CPAN Module Test::Builder caused test failure
10:17 dalek TT #1739: http://trac.parrot.org/parrot/ticket/1739
10:44 jsut joined #parrot
12:03 whiteknight joined #parrot
12:04 AndyA joined #parrot
12:08 whiteknight good morning, #parrot
12:18 luben_work good localtime()
12:18 luben_work it's late afternoon here
12:27 ruoso joined #parrot
12:45 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.
12:46 dalek TT #332 closed by whiteknight++: icc-10.0 32bit imcc crash
12:46 dalek TT #332: http://trac.parrot.org/parrot/ticket/332
13:02 vino_bot joined #parrot
13:03 vino_bot joined #parrot
13:10 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 #parrot
13:19 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.
13:37 mikehh whiteknight: query how did you submit a smolder report?
13:37 dalek lua: c71335e | fperrad++ | dynext/pmc/luastring.pmc:
13:37 dalek lua: Parrot_find_global_s() is gone,
13:37 dalek lua: see http://trac.parrot.org/parrot/changeset/48435
13:37 dalek lua: review: http://github.com/fperrad/lua/commit/c7​1335e0ac95d2ee775fe5a17cf253a03f102243
13:48 whiteknight mikehh: ah, I didn't know the smolder server was down
13:49 whiteknight 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 bubaflub joined #parrot
13:52 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:54 Paul_the_Greek joined #parrot
13:54 Paul_the_Greek Good morning folks.
13:55 dalek lua: b2d2f85 | fperrad++ | doc/running.pod:
13:55 dalek lua: with setup.pir (distutils)
13:55 dalek lua: review: http://github.com/fperrad/lua/commit/b2​d2f8573a3c04f7d8f710474285569a1c30b056
13:56 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.
13:56 particle i'm sorry, i thought that was done already.  am i wrong?
13:57 particle i could certainly ask... he doesn't bite.
13:58 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 mikehh I thought that someone else had taken it up, but have not been in touch with him since
13:58 particle ok, well, volunteers.
13:58 purl volunteers are FRESH MEAT! MUAHAHAHAHA
13:59 mikehh I can send him another email asking him to contact you
14:00 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
14:01 mikehh I don't see how they can support that patent - previous art - eg Lisp Machine
14:02 atrodo The title is usually overly broad, so, out of curiosity, i'm going to go read the claims of the patent
14:03 dalek parrot: r48450 | mikehh++ | trunk/src/pmc/fixedstringarray.pmc:
14:03 dalek parrot: fix codetest failure - line length
14:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48450/
14:04 TiMBuS http://www.scribd.com/doc/35811761/Oracle-s-compl​aint-against-Google-for-Java-patent-infringement
14:04 TiMBuS for the full text
14:04 particle mikehh: if you would, send him an email asking for a status update and copy me (particle@parrot.org)
14:05 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:06 TiMBuS um
14:06 Paul_the_Greek Can someone give me the URL for DEPRECATED.pod?
14:06 atrodo Patent doesn't sound good.  But, it was filed 2002.
14:08 particle oracle wants to destroy all computers?
14:08 atrodo More than likely
14:09 fperrad joined #parrot
14:11 bubaflub Paul_the_Greek: what specifically are you looking for?
14:12 Paul_the_Greek The link to deprecated.pod from the Support Policy page is broken. I'm trying to view the page.
14:13 bubaflub Paul_the_Greek: ah, i see it now
14:13 bubaflub lemme check what the link should be
14:13 bubaflub i can patch the docs
14:14 Paul_the_Greek Great, thanks. I'm submitting a patch to DEPRECATED.pod, which is why I noticed.
14:15 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:16 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.
14:16 bubaflub Paul_the_Greek: yep.
14:16 plobsing joined #parrot
14:16 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:18 particle Paul_the_Greek: received your CLA yesterday.
14:18 Paul_the_Greek Wonderful. Now I be official.
14:18 Coke Paul_the_Greek: I'm not sure there is a URL. (which would probably suck). why do you need it?
14:19 bubaflub Coke: there is a link to DEPRECATED.pod from http://docs.parrot.org/parrot/latest/ht​ml/docs/project/support_policy.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.
14:19 bubaflub Coke: ah, makes sense.  i'll update the ticket.
14:20 Coke ok. please open a ticket and assign it to me so that doesn't get lost.
14:20 Coke oir update, perfect, danke.
14:20 Paul_the_Greek bubaflub: Here's the ticket: http://trac.parrot.org/parrot/ticket/1738
14:22 Paul_the_Greek 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.
14:22 Coke Paul_the_Greek: you could mark it as of type "deprecation", but no one really cares.
14:22 bubaflub Coke: updated TT #765
14:22 Coke bubaflub: danke.
14:22 Paul_the_Greek I guess dep.pod acts as the official list.
14:23 Coke yes.
14:25 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:27 robin-gvx joined #parrot
14:28 dalek TT #1738 closed by Paul_the_Greek++: Improve documentation of PARROT_ERRORS_*_FLAG
14:28 dalek TT #1738: http://trac.parrot.org/parrot/ticket/1738
14:28 dalek TT #1738 reopened by Paul_the_Greek++: Improve documentation of PARROT_ERRORS_*_FLAG
14:28 dalek TT #1738: http://trac.parrot.org/parrot/ticket/1738
14:28 Paul_the_Greek Great, thanks bubaflub.
14:29 Coke bubaflub?
14:29 purl i think bubaflub is Bob Kuo, mailto:bobjkuo@gmail.com
14:29 Coke botsnack
14:29 purl :)
14:30 * 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.
14:31 Paul_the_Greek Thanks!
14:31 bubaflub Coke: wadda ya mean?
14:33 Coke bubaflub: regarding karma?
14:34 bubaflub regarding "beverage"
14:34 Coke http://www.coke.com/ ?
14:34 bubaflub ahhhhhh
14:34 bubaflub *that* beverage
14:34 Coke the eponymous one and only.
14:35 bubaflub Coke II: Coke with a vengeance
14:36 dalek parrot: r48451 | bubaflub++ | trunk (2 files):
14:36 dalek parrot: [TT #1738] Improve docs of PARROT_ERROR_*_FLAG Paul_the_Greek++
14:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48451/
14:44 theory joined #parrot
14:44 dalek TT #1738 closed by bubaflub++: Improve documentation of PARROT_ERRORS_*_FLAG
14:44 dalek TT #1738: http://trac.parrot.org/parrot/ticket/1738
14:53 dalek parrot: r48452 | plobsing++ | trunk/t/native_pbc (7 files):
14:53 dalek parrot: native_pbc platform updates
14:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48452/
14:56 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:57 Coke (so, adding a fresh "eligible in 2.7" is wrong)
14:59 dalek rakudo: 938b133 | moritz++ | src/core/Match.pm:
14:59 dalek rakudo: be explicit about .keys, .values, .kv and .pairs in Match
14:59 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​38b133fb25a98d6e2342a63115376c5edbed263
15:00 bubaflub Coke: should i update that last commit to say 2.9 instead?
15:01 allison joined #parrot
15:05 mikehh t/pmc/pmc.t - Failed test:  3 with Segmentation fault
15:07 chromatic joined #parrot
15:07 bubaflub mikehh: i'm seeing that same error on r48451
15:19 fperrad joined #parrot
15:20 allison joined #parrot
15:20 Coke bubaflub: 2.10
15:21 bubaflub Coke: ok, i'll fix that.
15:21 Coke it's eligible for removable in "the first release after the next supported release"
15:21 Coke (which practically means 'rip from svn as soon as the next supported release is tagged')
15:25 bubaflub Coke: fixed in 48453
15:25 Coke bubaflub: danke.
15:26 dalek parrot: r48453 | bubaflub++ | trunk/DEPRECATED.pod:
15:26 dalek parrot: the first release after the next supported release would be 2.10, not 2.7
15:26 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48453/
15:31 bacek joined #parrot
15:37 aloha joined #parrot
15:40 Coke jnthn++ # signature talk
15:43 dalek parrot: r48454 | fperrad++ | trunk/t/op/calling.t:
15:43 dalek parrot: add test for TT#1733
15:43 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48454/
15:43 Coke I thought notfound already added a test for that.
15:45 Coke huh
15:48 jan joined #parrot
15:51 dalek TT #1733 closed by fperrad++: calling convention broken
15:51 dalek TT #1733: http://trac.parrot.org/parrot/ticket/1733
15:59 Coke oh, notfound said we needed a test, he didn't write one. ;)
16:05 chromatic t/pmc.t #3 segfaults for me
16:08 chromatic ImageIO PMC changes... I can fix that.
16:20 mikehh chromatic: got a backtrace and # src/packfile.c:590: failed assertion 'pf'
16:20 chromatic Yeah, it's r48447.
16:20 chromatic I'm going to put in a quick fix, then give plobsing some suggestions to improve things.
16:20 chromatic My Right Fix isn't.
16:23 chromatic msg plobsing Please see r48455.
16:23 purl Message for plobsing stored.
16:26 particle try the left one
16:27 * Coke gives up on #perl6 again for a while.
16:31 chromatic Hm, someone sped up Rakudo again.
16:32 jnthn \o/
16:32 luben_work chromatic, yes
16:32 jnthn someone++
16:33 dalek parrot: r48455 | chromatic++ | trunk/src/pmc/imageio.pmc:
16:33 dalek parrot: [PMC] Fixed segfaults in ImageIO PMC's destroy().
16:33 dalek parrot: In certain (yet undiagnosed) cases, the "You can destroy the PackFile
16:33 dalek parrot: attribute" flag is on but there's no PackFile attribute.  This makes C sad.
16:33 dalek parrot: The culprit is r48447.
16:33 dalek parrot: A better approach is to use PObj_custom_destroy_SET() only when it's okay to
16:33 dalek parrot: destroy this attribute, but that fix will take longer.  In the meantime, this
16:33 dalek parrot: works at the expense of a bit of extra work.
16:33 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48455/
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?
16:35 chromatic I'm not sure.  I think that may have been noise.
16:35 luben_work ok, I do not see a difference either
16:36 luben_work next thing to try is paged allocation for hash->buckets
16:39 luben_work chromatic, do we use macros of that type: http://pastebin.com/Ph4UrqJQ
16:40 luben_work I am not sure about the compilers support, coding standards etc.
16:41 chromatic Seems reasonable to me.
16:42 luben_work I have replaced all copy/paste code in the tree with this macro
16:42 luben_work so if I change hash internals, the only place that I have to update is this macro
16:43 chromatic I like it.
16:44 luben_work I could send a patch
16:44 Coke wouldn't an inline function theoretically DTST?
16:45 particle and be better for PARROT_EXPORT?
16:47 particle 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.
16:48 Coke (that does NOT look extractable into an function)
16:48 chromatic Yeah, those concerns don't apply to this macro.
16:51 particle yeah.  do we have a coding convention for macro names?  case, prefix, etc?
16:54 allison joined #parrot
17:00 dalek rakudo: c41bcd7 | moritz++ | src/core/Match.pm:
17:00 dalek rakudo: Match.new roundtrips from Match.perl
17:00 dalek rakudo: Implements named and positional subcaptures
17:00 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​41bcd77824b8b12a1de018cb130b07b2e9a5b53
17:07 darbelo allison: Hi.
17:19 luben_work I have sent a patch to parrot-dev list, for evaluation and discussion of proposed macros and their usage
17:21 luben_work time to go home...
17:23 dalek parrot: r48456 | darbelo++ | branches/unshared_buffers/src/gc/mark_sweep.c:
17:23 dalek parrot: Remove misleading comment.
17:23 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48456/
17:23 dalek parrot: r48457 | darbelo++ | branches/unshared_buffers/​src/gc/alloc_resources.c:
17:23 dalek parrot: Turn speculative comment into action. Harms nothing.
17:23 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48457/
17:23 dalek parrot: r48458 | darbelo++ | branches/unshared_buffers/​src/pmc/stringbuilder.pmc:
17:23 dalek parrot: Update stringbuilder to the new substr semantics.
17:23 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48458/
17:23 dalek parrot: r48459 | darbelo++ | branches/unshared_buffers/​src/gc/alloc_resources.c:
17:23 dalek parrot: Remove a check for a condition that can't be true.
17:23 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48459/
17:23 dalek parrot: r48460 | darbelo++ | branches/unshared_buffers/src/gc (2 files):
17:23 dalek parrot: Prune the Variable_sized_pool struct of members that were only useful with cow.
17:23 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48460/
17:23 dalek parrot: r48461 | darbelo++ | branches/unshared_buffers/​src/gc/alloc_resources.c:
17:23 dalek parrot: Make sure we keep the free mem counters up to date in the buffer_pools.
17:24 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48461/
17:24 dalek parrot: r48462 | darbelo++ | branches/unshared_buffers/include/parrot/pobj.h:
17:24 dalek parrot: Remove a macro with a misleading name and some obsolete pointer masking.
17:24 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48462/
17:24 dalek parrot: r48463 | darbelo++ | branches/unshared_buffers/​src/gc/alloc_resources.c:
17:24 dalek parrot: Add a function to free just one block and swith compact_pool to use it.
17:24 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48463/
17:24 dalek parrot: r48464 | darbelo++ | branches/unshared_buffers/​src/gc/alloc_resources.c:
17:24 dalek parrot: Properly nest checks.
17:24 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48464/
17:24 dalek parrot: r48465 | darbelo++ | branches/unshared_buffers/​src/gc/alloc_resources.c:
17:24 dalek parrot: There is no point in calling compact_pool() after calling Parrot_gc_mark_and_sweep(). The pools are already compacted by then.
17:24 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48465/
17:25 chromatic Is r48465 a cherry pick to trunk?
17:33 allison joined #parrot
17:33 allison darbelo: flakey conference network
17:33 allison darbelo: hi
17:33 purl hi, allison.
17:38 cotto_work ~~
17:40 darbelo allison: I'm still working on unshared_buffers, which has kinda turned into gc refactor work by now.
17:41 allison darbelo: sounds like a case of creature feep :)
17:41 allison (feature creep)
17:41 rurban_ joined #parrot
17:42 allison darbelo: how's the general progress otherwise? is unshared_buffers a blocker, or mostly on the side?
17:43 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:44 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.
17:45 darbelo That sped up our string becnhmarks by a solid 10%, but chews through our string pools faster, which causes trouble for Rakudo.
17:46 darbelo And PCT parsers in general, really.
17:46 allison because we're creating more string copies?
17:46 chromatic Substrings, to be specific.
17:46 allison yah, that was the risk we predicted
17:47 allison (specifically, in removing the last traces of the COW code)
17:48 darbelo AFAICT, most are small and fairly short lived, but they fragment our pools more and tickle compact_pools in the wrong way.
17:49 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.
17:49 chromatic darbelo, can you annotate STRING creation to see the sizes of these substrings?
17:50 allison so what have you been focusing on in the GC refactors?
17:51 darbelo allison: Yeah, I'm trying to add some smarts to compact_pool now, make it more 'precise'.
17:51 allison darbelo: good start
17:51 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.
17:51 allison hush, purl
17:51 purl o/` don't you cry o/`
17:53 whiteknight purl forget good start
17:53 purl whiteknight: I forgot good start
17:55 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:58 darbelo 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 #parrot
18:03 davidfetter joined #parrot
18:04 AndyA joined #parrot
18:06 dalek TT #1740 created by ild++: pbc_dump crashes on certain inputs
18:06 dalek TT #1740: http://trac.parrot.org/parrot/ticket/1740
18:09 darbelo Compiling rakudo's Actions.pm with annotated substr now.
18:10 cotto_work is ild in here by some other name?
18:11 cotto_work I'm not sure how I feel about playing with a pbc file named exploit_0_0
18:12 darbelo 690237 total calls, 436821 made with lenght=1
18:12 darbelo purl: 436821 / 690237
18:12 purl 0.63285654057954
18:13 cotto_work though having a bunch of broken pbcs for debugging is nice. ild++
18:14 luben joined #parrot
18:15 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.
18:16 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.
18:16 darbelo It's likely.
18:17 darbelo 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."
18:18 darbelo What, the witespace?
18:18 chromatic Right.
18:18 chromatic Although within the non-capturing ws rule....
18:22 nopaste "darbelo" at 192.168.1.3 pasted "ack for pir::substr in rakudo's src/Perl6/Actions.pm" (8 lines) at http://nopaste.snit.ch/22758
18:23 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.
18:23 purl No it doesn't, shut your hole!
18:24 darbelo Even with shared buffers it strikes me as a questionable thing to do.
18:25 chromatic It could chew through STRING headers in a hurry.
18:27 chromatic We need something more like streq_at
18:28 darbelo I wonder if a index variant that 'stops after this much' is the right thing to use here.
18:30 chromatic That comparison API we worked out a while back might do the trick.
18:32 chromatic The question is "Does this string at this position contain exactly this substring?"
18:32 brianwisti joined #parrot
18:37 robin-gvx joined #parrot
18:41 dalek rakudo: 44f0ec0 | (Kyle Hasselbacher)++ | docs/ (2 files):
18:41 dalek rakudo: [docs] Misspellings caught by ispell
18:41 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​4f0ec0cd95b0fb257946dc7dd9c33aefc7ff882
19:01 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:04 allison joined #parrot
19:04 darbelo chromatic: Okay, I'll mail parrot-dev later today.
19:04 chromatic +1
19:04 purl 1
19:05 chromatic It does tickle my intuition as something PCT could do better for great speed.
19:06 AndyA_ joined #parrot
19:08 darbelo Also, I think I've found a "leak" in our pool compaction scheme.
19:09 lucian joined #parrot
19:11 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:12 allison darbelo: that's nutty
19:12 chromatic Seems like it'll never get freed.
19:16 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:17 darbelo That means we will be performing a really big, possibly unneeded, allocation on the next compaction run.
19:18 LoganLK joined #parrot
19:18 chromatic How fixable is it?
19:22 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?
19:23 dalek rakudo: 0839993 | (Patrick Abi Salloum)++ | src/core/MAIN.pm:
19:23 dalek rakudo: Added short arguments parsing to MAIN
19:23 dalek rakudo: Signed-off-by: Moritz Lenz <moritz@faui2k3.org>
19:23 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​839993ed01c816dc8b3459fa7b79608be4fbf3a
19:24 darbelo There's a todo in alloc_resources.c
19:24 darbelo * TODO - Big blocks
19:24 darbelo *
19:24 darbelo * Mark the block as big block (it has just one item)
19:24 darbelo * And don't set big blocks as the top_block.
19:25 chromatic Ah, so that's what it meant.
19:25 darbelo It's the part of mem_allocate that creates the 'big block'
19:25 chromatic I must have read that code several dozen times while trying to decipher it.
19:26 darbelo The other parts of the riddle were inside compact_pool and free_old_mem_blocks
19:32 darbelo 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:38 darbelo I think we might need a threshold system to make compacting tamer or more aggressive as needed.
19:41 Coke pmichaud: ping.
19:41 chromatic That's the idea of the gc_threshold branch, or whatever its name is.
19:43 darbelo I thought that was for the header pools.
19:44 chromatic Oh, right.  I thought you meant more broadly than you did.
19:48 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:49 chromatic If we know the sizes, yeah.
19:49 moritz maybe just compact on every 5th mark?
19:50 tewk_ darbelo: only compact when you are going to regain at least some % of the space.
19:52 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)
19:56 Paul_the_Greek Does the VM store the same string more than once?
19:57 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.
19:57 chromatic Yes.
19:57 darbelo Also, in order to make sure 'big blocks' eventually die. We ocasionally have to do a "more aggressive" run.
19:57 Paul_the_Greek Boy, that really makes me think that 1-character strings should be preallocated.
19:58 chromatic Preallocation does seem useful.
19:58 Paul_the_Greek Consider the overhead for each 1-character string.
19:58 Paul_the_Greek About 32 to 1 or something.
19:59 chromatic That and the GC pressure.
19:59 Paul_the_Greek I'd love to see benchmarks of interning vs. not interning.
19:59 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?
19:59 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.
20:00 Paul_the_Greek Yes, it would. And it's related to whether the assembler optimizes substr(,,1).
20:06 Paul_the_Greek Consider also the possibility of a substr1 opcode.
20:07 Paul_the_Greek Or an optimization to chr(ord()).
20:09 Paul_the_Greek 61 uses or chr() in the various PIR files; 504 uses of substr , , 1
20:09 dafrito joined #parrot
20:12 darbelo Paul_the_Greek: See http://irclog.perlgeek.de/p​arrot/2010-08-13#i_2700241
20:14 Paul_the_Greek No thought shall go unrecorded.
20:15 Paul_the_Greek It would be relatively easy to preallocate 1-character strings and then see if we get any improvement.
20:15 Paul_the_Greek Are strings ASCII or Unicode by default?
20:15 chromatic It's feasible with immutable strings.
20:16 chromatic The default encoding is ascii.
20:17 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.
20:17 Paul_the_Greek In fact, even with strings as they are, the preallocated ones could be fat, since they are pinned.
20:18 dafrito purl, fat strings?
20:18 purl dafrito: i haven't a clue
20:18 darbelo .oO(a rope?)
20:18 Paul_the_Greek dafrito: A string whose data is stored right after the header, rather than in the variable-sized memory areas.
20:19 dafrito Paul_the_Greek: ah, okay
20:31 bluescreen joined #parrot
20:34 luben it does not seep a good idea to hand edit a patch file :)
20:35 Paul_the_Greek Unless you do it very very carefully.
20:39 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)
20:40 Paul_the_Greek Okay, I'm convinced. Don't do it.
20:40 luben chromatic, I am still new in handediting diffs :)
20:41 luben purl, git mirror?
20:41 purl luben: wish i knew
20:41 luben purl, git?
20:41 purl git is like svn but not a braindamaged amoeba or http://perl5.git.perl.org/perl.git or at http://git-scm.com/ or the source of all SCM happiness in the world. or the Emacs of source code management systems or easy!
20:42 luben purl, git-svn
20:42 purl i think git-svn is amazingly great or https://trac.parrot.org/pa​rrot/wiki/git-svn-tutorial
20:43 mikehh joined #parrot
20:43 luben is this the official git mirror: http://github.com/leto/parrot
20:44 dafrito luben: AFAIK, yes
20:45 luben nice :)
20:45 bubaflub luben: that mirror is managed by dukeleto
20:46 luben I am lost in half a dozen svn checkouts here :( And you could not locally commit :( So, its everything or nothing
20:47 luben dukeleto++
20:56 tcurtis joined #parrot
21:02 davidfetter joined #parrot
21:48 whiteknight joined #parrot
21:51 masak joined #parrot
21:52 masak I have a ByteBuffer question. how do I say "get a ByteBuffer from this string using this encoding"?
21:52 masak I have a feeling my question is slightly ill-posed, because I seem to recall that Parrot strings have an encoding in themselves.
21:53 darbelo masak: Yes.
21:53 darbelo You can transcode the string if it isn't in the encoding you need.
21:53 masak so maybe what I want is "turn this string to use that encoding, and then turn it into a ByteBuffer"?
21:53 masak right.
21:53 masak how?
21:54 darbelo $I0 = find_encoding 'Your Encoding'
21:54 darbelo $S0 = trans_encoding $S0, $I0
21:55 masak thank you.
21:55 masak where can I find a list of the available encodings?
21:56 darbelo fixed_8, utf8, utf16, ucs2, ucs4
21:57 masak ok.
21:57 masak let's say I wanted latin-1 to be in that list. what are my options?
21:57 cotto_work files in src/string/encoding/
21:57 dukeleto luben: is it not official, but it is a mirror
21:57 NotFound masak: ByteBuffer works the other way, it provides way to encode strings from  raw data.
21:57 darbelo masak: That would be a charset, in the current scheme.
21:58 dukeleto luben: check the git-svn wiki page on parrot.org for a git-svn mirror
21:58 masak ah, ok.
21:58 dukeleto luben: gotta go, good luck!
21:58 masak NotFound: I think I'm using ByteBuffer to go in both directions in Rakudo currently.
21:59 masak 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.
21:59 NotFound masak: yeah, but it takes the string as is, without ability to recoding.
21:59 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
21:59 masak ah, src/str/charset, of course.
21:59 darbelo ascii, iso-8859-1, unicode and binary.
22:00 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++
22:02 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.
22:03 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 cotto_work Do you mind filing a ticket?
22:05 luben cotto_work, thanks, I'l file a tiket. May be parrot_hash_iterator_advance is a better name.
22:06 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.
22:08 darbelo masak: Yep.
22:08 masak \o/
22:12 jsut_ joined #parrot
22:17 whiteknight In NQP, how do I register a built-in PMC type with P6metaclass?
22:18 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?
22:19 jnthn whiteknight: Easiest way is just to .HOW something you know uses it.
22:19 jnthn (In Rakudo we just do that and cache it somewhere.)
22:21 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 whiteknight and I was hoping NQP would include a reference to P6metaclass somewhere in the generated
22:21 whiteknight PIR, but it doesnt
22:22 jnthn whiteknight: Are you in the Parort namespace?
22:22 whiteknight jnthn: I guess? I haven't specified any other namespace
22:22 jnthn If P6object.pbc is loaded then you should just have P6metaclass available.
22:23 jnthn See the synopsis in P6object.pir.
22:26 whiteknight P6object.pbc. I think that's what I'm looking for
22:26 whiteknight thanks
22:35 dalek TT #1741 created by luben++: Macro abstraction for hash iterations
22:35 dalek TT #1741: http://trac.parrot.org/parrot/ticket/1741
22:35 dalek TT #1742 created by nwellnhof++: Skip compact_pool if all blocks are almost full
22:35 dalek TT #1742: http://trac.parrot.org/parrot/ticket/1742
22:41 kid51 joined #parrot
22:57 whiteknight is there any way to unload a library from Parrot?
22:58 whiteknight I don't see an "unloadlib" opcode, and no methods on the ParrotLibrary PMC
23:00 darbelo Ending your progrma?
23:02 whiteknight no, trying to clear things out for tests
23:06 darbelo Well, they are not singletons, so the gc should collect them, eventually. Unless it comes from the constant pool.
23:07 darbelo 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 parrot-linear-algebra: 07879a6 | Whiteknight++ |  (4 files):
23:07 dalek parrot-linear-algebra: add a new file src/nqp/pla.nqp, which is a bootstrap file which helps to setup
23:07 dalek parrot-linear-algebra: PLA for use in NQP programs. It loads the library and registers the types with
23:07 dalek parrot-linear-algebra: P6metaclass. Add a quick example of it's use in examples/nqp.nqp
23:07 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/07879a67ef2aeecc0d96b29e40d9c84bb24a56e7
23:07 dalek parrot-linear-algebra: 7695a74 | Whiteknight++ | examples/nqp.nqp:
23:07 dalek parrot-linear-algebra: rename the example to something a little better
23:07 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/7695a7477477f113611dd3be6e92f4530040586f
23:07 dalek parrot-linear-algebra: bc1d869 | Whiteknight++ | src/nqp/pla.nqp:
23:07 dalek parrot-linear-algebra: load linalg, expecting it to be installed. Don't load it from a relative address
23:07 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/bc1d869ad9ad734a2b291eca737985eaecf38c96
23:08 dalek parrot-linear-algebra: 65bf0ac | Whiteknight++ | src/nqp/pla.pir:
23:08 dalek parrot-linear-algebra: remove a generated file from the repo
23:08 dalek parrot-linear-algebra: review: http://github.com/Whiteknight/parrot-linear-algebr​a/commit/65bf0ac04f01a89bad79a84b7f40e453474281b0
23:08 chromatic Hm, Rakudo's sort_candidates() is spendy.
23:08 chromatic ... mostly because is_narrower() is super spendy.
23:09 chromatic StringBuilder's append_format() is worse.
23:10 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.
23:10 chromatic Yeah, that looks like the culprit.
23:11 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.
23:12 chromatic purl (649406 - 70250 ) / 649406
23:12 purl 0.89182422090341
23:12 jnthn chromatic: The thing is, just about all the calls it does are to an ACCEPTS method and it's always two args.
23:13 chromatic Wouldn't it be nice to be able to cache that signature somehow?
23:13 jnthn Yes. :-)
23:13 jnthn Do you know how to do that?
23:13 chromatic Without changing the current API?
23:14 jnthn Ah, OK
23:14 jnthn Parrot_ext_call is maybe not so ideal in this case. :-)
23:14 chromatic It isn't.
23:14 jnthn But I'm not sure what API I want.
23:14 jnthn s/want/should be using/
23:14 jnthn (if it exists)
23:14 chromatic I think we have to separate signature from context, if we haven't finished that already.
23:15 jnthn The binder also does loads of ACCEPTS calls
23:16 jnthn So we can improve that too.
23:16 chromatic If that means we can have immutable signatures, we're mostly there.
23:17 chromatic Immutable signatures helps PIR too.
23:20 jnthn *nod*
23:26 kthakore hi chromatic
23:32 Paul_the_Greek purl,messages
23:47 dalek parrot: r48466 | darbelo++ | branches/unshared_buffers/​src/gc/alloc_resources.c:
23:47 dalek parrot: Apply nwellnhof's patch from TT #1742.
23:47 dalek parrot: review: http://trac.parrot.org/parrot/changeset/48466/
23:52 Paul_the_Greek How do people decide which patches to commit when?
23:54 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:56 cotto_work deprecations that break compatibility are treated more formally and significant refactors usually go into a branch
23:56 cotto_work but there's not much more than that
23:58 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 http://trac.parrot.org/parrot/ticket/1605
23:58 purl Message for cotto stored.
23:59 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.

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

Parrot | source cross referenced