Camelia, the Perl 6 bug

IRC log for #parrot, 2010-05-12

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:03 kid51 joined #parrot
00:04 kid51 Did this pastebot show up just now?  http://nopaste.snit.ch/20532
00:09 davidfetter nom nom nom
00:09 purl I eat your head!
00:13 nopaste "kid51" at 192.168.1.3 pasted "codestring branch: build failure: Darwin/PPC: r46524" (700 lines) at http://nopaste.snit.ch/20533
00:13 kid51 okay, it worked that time.  back to dinner
00:14 sorear tcurtis: dynpmcs are identified by name
00:14 sorear tcurtis: corepmcs are actually created by number, so if you add a new one, you break PBC compat
00:19 sorear darbelo: I find this notion of switching to fixed width coding vaguely disturbing
00:20 sorear PIR and Perl6 really want variable width codes
00:20 sorear they're 99.9% ASCII with a few « thrown in...
00:21 sorear do you think that changing 1-byte-per-character to 1-pointer-per-character will be a win?
00:22 * sorear quits before he bikesheds too much
00:28 Casan joined #parrot
00:36 darbelo sorear: I'm changing what to what?
00:37 darbelo sorear: Also, where are you getting this ideas about characters and pointers?
00:38 darbelo sorear: Are you sure it's me you wanted to talk to?
00:38 sorear I'm trying to understand the NFG campaign.
00:39 darbelo It's about adding a new Unicode encoding.
00:39 sorear You and allison were talking earlier about fixed width encodings
00:39 darbelo NFG is one, yes. But it doesn't store pointers to characters.
00:42 abqar joined #parrot
00:48 sorear bacek_at_work: Does SweepFreeGC mean 2 more pointers _per object_ in order to maintain the lists?
00:48 darbelo sorear: NFG is about adding a new Unicode encoding that is more graceful about some edge cases with composing characters.  It's been specified in PDD28 for ages, and it's not going to change the way parrot strings work.
00:49 sorear Oh.
00:51 darbelo Also, doing regex matching on non-fixed size encodings is horribly slow. If NFG pans out the way we expect it to it'll probably improve PGE and NQP's performance on Unicode strings.
00:53 darbelo The idea is based on one of the old plan 9 papers, the one describing 'Runes'. Which is the plan 9 solution to utf8's speed issues.
00:55 sorear Unfortunately....plan9 is very old.
00:55 sorear Plan9 dates from the days when the BMP was all there was
00:55 sorear 2 byte Runes
00:56 sorear NFG Runes have to be as big as a pointer
00:57 cotto ~
00:57 sorear (Why does our regex code index into strings anyway?  Why can't it just use abstract positions?)
00:58 sorear a clonable string iterator, aka a byte offset
01:00 chromatic Hey look, more GCables!
01:00 plobsing joined #parrot
01:05 sorear chromatic: the regex compiler would generate $Is for them
01:05 sorear not $Ps
01:08 chromatic That sounds like a great way to cause bugs.  Sure, we have Unicode-aware strings, but you can access individual characters by byte offset, just like every Unicode tutorial in existence tells you never, ever, ever to do.
01:10 chromatic Worse than that, your integer iterator positions do not compare across strings, if their encodings can vary.
01:10 chromatic Even if a portion of one string is a portion of another, you need an all-new iterator.
01:12 sorear I'm talking about *generated code* here
01:12 sorear this isn't any more repugnant than a compiler using pointer arithmetic to implement collections
01:13 chromatic Until your compiler changes the size of pointers and the layout of memory.
01:13 sorear The compiler knows it's changed the layout of memory
01:13 sorear So it can just generate the correct code
01:14 tcurtis NFG has other benefits beyond constant-time indexing.
01:14 sorear I am *not* advocating the use of byte offsets in handwritten PIR.
01:15 chromatic Then why suggest multiplying entities?
01:15 Tene Occam beat him up for lunch money when he was a kid?
01:15 sorear Because, if darbelo goes through with this and uses 32 bits per character for strings in the regex engine, the Rakudo setting is going to be larger than my L2 cache
01:16 sorear I don't think this makes any sense, if the goal is optimization
01:16 sorear tcurtis: right, there are two issues here
01:16 sorear tcurtis: NFG and fixed pitch strings
01:17 sorear tcurtis: I wholeheartedly support NFG but think fixed string pitch is hopelessly naive
01:17 chromatic Neat trick you have there, profiling code that hasn't been written.
01:18 sorear chromatic: learning to recognize dead ends before I walk down them is one of the best things I ever did
01:19 sorear feel free to ignore me.  but I'll be waiting with the "told you so" card.
01:20 chromatic Do you have something more helpful to contribute?
01:23 jsut_ joined #parrot
01:24 sorear No.
01:27 tcurtis sorear, what sort of encoding for NFG do you think would be a better choice? Something similar to UTF-8 or UTF-16?
01:28 chromatic If it's an array, it's going to have fixed-width elements.
01:28 plobsing joined #parrot
01:28 chromatic An integer array, I mean.
01:28 cotto How do I make something installable?
01:29 Tene cotto: "installable"?
01:29 chromatic That doesn't mean every integer array has to have 32-bit integers, though.  Latin-1 can use 8-bit integers.
01:29 cotto installed as part of make install
01:30 Tene Hmm.  Don't remember, sorry. :(
01:31 chromatic Look at the installable rule in the Makefile.
01:32 bacek_at_work cotto: tools/dev/install_dev_files.pl
01:32 purl rumour has it tools/dev/install_dev_files.pl is simpler than install_files.pl and may help you to get an overview of what we're trying to achieve codewise
01:33 bacek_at_work cotto: Looks like you have to edit few MANIFEST* files.
01:34 cotto looks reasonable
01:35 tcurtis darbelo, do you have any clue as to how many possible graphemes that don't have Unicode codepoints there might be?
01:35 Tene infinite.
01:35 purl infinite is never sensible
01:35 Tene iirc, you can continue to add combining characters without bound.
01:36 bacek_at_work cotto, and Parrot::Manifest._get_special
01:37 chromatic Wiki incoming!
01:37 sorear Ok, I've finally figured out what my real issue is
01:38 sorear I subscribe to the "change one thing at a time" school of optimizing
01:38 tcurtis Does adding the same combining character multiple times produce different graphemes?
01:38 sorear NFG seems to violate this - we're switching to fixed width and switching to one-element-per-grapheme
01:38 Tene afk, going home.
01:39 sorear tcurtis: NFG/(whatever our main encoding is now)
01:41 tcurtis Can you represent codepoints outside of Unicode in UTF-8 or UTF-16, though, sorear?
01:41 bacek_at_work chromatic, I wanna break GC API. Change Parrot_gc_mark_foo_alive to accept pointer-to-pointer.
01:41 chromatic To enable compacting?
01:41 bacek_at_work chromatic, It's almost necessary for compacting
01:42 bacek_at_work yeah :)
01:42 chromatic It's probably inevitable, but I'd like to get sweep-free in first before we go too far down other options.
01:43 bacek_at_work sweep-free will require 2 more pointers per GCable...
01:43 chromatic Unless we can optimize it somehow.
01:44 rurban joined #parrot
01:44 bacek_at_work chromatic, yes. But I couldn't figure out how.
01:45 bacek_at_work Actually, compacting gen GC looks like good optimisation
01:46 chromatic If we know we only ever have 256 items per arena, then we only need 8 bits for from and 8 bits for to, and we don't need pointers.
01:46 chromatic Granted, we probably want arenas up to 64k items per, but that's still only 16 bits for from and 16 bits for to, and that's the same size on 32- and 64-bit platforms.
01:47 chromatic That requires us to be able to manage a series of pools, but we can probably manage that.
01:49 bacek_at_work way too complex from my pov...
01:49 chromatic Saves at least 4 bytes per GCable and possibly 12.
01:52 bacek_at_work We can store bitmask for arena. 2 bits per object for colour
01:52 chromatic Then we have to sweep.
01:53 bacek_at_work We have to sweep anyway. But we don't have to iterate pool for it.
01:53 chromatic We don't have to sweep for the sweep-free.
01:54 chromatic Although getting rid of pool iteration on its own is useful.
01:55 sorear True or false: The point of sweep-free is to not waste time looking at objects that aren't free.
01:55 bacek_at_work sorear, it's true from pov and it holds with "arena bitmask"
01:56 chromatic That's not the only point though.
01:56 bacek_at_work afk # $dayjob, lunch, world domination
01:57 chromatic bacek_at_work, I'd like the arena bitmask idea more if it didn't seem like a lot more work to find a free header.
02:18 bluescreen joined #parrot
02:24 Tene tcurtis: According to the friend I always go to for unicode-savvy questions, the space of distinguishable unicode grapheme clusters is unbounded.
02:25 Tene 19:42 < clsn> There're rules about how the signs are re-ordered canonically, based on their combining class.
02:25 Tene 19:43 < clsn> And there are tricks to keep certain rearrangements from happening, with class-zero characters.  I think that's part of the COMBINING GRAPHEME JOINER's purpose in life.
02:25 Tene 19:46 < clsn> Hm.  So is the set of unicode grapheme clusters *really* infinite?  At least from a data perspective, I think so.  E-CIRCUMFLEX-CIRCUMFLEX kind of has to be distinct in some way from E-CIRCUMFLEX whether or not it's rendered  that way.
02:34 tcurtis Interesting, Tene. Good thing darbelo's dynamically assigning codepoints for non-Unicode-codepoint graphemes.
02:39 darbelo_ joined #parrot
02:39 * darbelo_ is back and fed.
02:40 * darbelo_ backlogs.
02:41 janus joined #parrot
02:42 darbelo_ Ok. For the record: NFG does not change a whole lot of things.  First and foremost, it does not change, the way parrot strings operate. Parrot has support for a big bag of different encodings so that the implementor can choose the one best suited to his problem.
02:43 darbelo_ NFG is another encoding that you can choose. It does not *remove* any features, and I intend to do my best to assure that it will not add overhead when not in use.
02:44 LoganLK joined #parrot
02:44 darbelo_ Put simply, it should only be used if it's teh right tool for the job. We think that it is the right tool for a few jobs. If it turns out it isn't... Hey, at least we've learned something.
02:45 sorear darbelo++ that's the spirit
02:48 darbelo_ Just making sure the intent of the project was clear.
02:50 darbelo_ Just in the last two weeks, I've come across stuff that's made me rethink a few of the approaches I had in mind. The details for a lot of it are in flux in my head right now.
02:51 darbelo_ When not all of the plan is in a readily accesible form it's easy to get the wrong idea.
02:52 darbelo_ That said, please keep you spoons out of my brain. I'll document it all eventually.
02:52 sorear But it's so tasty!
02:53 sorear opbots names
02:53 sorear huh.
02:53 sorear oh, deferred
02:53 purl well, deferred is non-standard (not default)
03:07 bacek_at_work chromatic, I did implement custom fixed-size allocator with bitmask back 2005. And I beat google's tcalloc in terms of performance.
03:15 chromatic I'd like to see more details.
03:17 kurahaupo joined #parrot
03:23 Coke email sent on branches/codestring . feedback me.
03:23 Coke I'll get the merge ready. =-)
03:23 chromatic I'm checking.
03:23 Coke bacek++
03:23 sorear I'm checking.
03:24 sorear (unfortunately, I'll have to test under trunk to get a fair comparison.
03:24 sorear )
03:29 Coke aaaaaaaargh.
03:30 Coke svn merge --reintegrate ^/branches/codestring barfed.
03:30 Coke (which is sad, because the merges from trunk to that branch in the new style were going so well.
03:30 chromatic I'm sure we could make it work with git-svn.
03:30 bacek_at_work chromatic, I don't have this code (it was on my previous $job). But I can reimplement it.
03:30 Coke lemme poke for a bit. :|
03:31 bacek_at_work chromatic, don't try to merge branches with git if they were merged with svn already. It will not work...
03:31 darbelo_ I'm partially convinced that out svn server is partially corrupt, somewhere.
03:32 chromatic That's an indictment of SVN still though.
03:32 Coke darbelo_: I highly doubt that. I do not doubt that people are using 1.4 and 1.6 style merging, though.
03:32 chromatic bacek_at_work, I don't need to see code, but I'd like to see a description of the algorithm.
03:33 darbelo_ Coke: I geuss it's possible, but I've seen the server barf on textbook trivial merges, and it routinely gives out nonsensical props on files.
03:33 chromatic Branch is 1.834% faster for me.
03:34 bacek_at_work chromatic, 4k pages (arenas), every arena has bitmask for used objects, index of next free object. Allocating is set one bit and find another byte != 0xFF.
03:35 chromatic That's not as cheap as bumping a pointer, but it might be more cache friendly.
03:35 chromatic 4k pages is a nice thought too.
03:35 chromatic Checking a byte at a time might be more expensive than checking a word at a time, or 32 bits at a time.
03:35 chromatic Let me think about that a little bit.
03:36 Coke darbelo_: "gives out nonsensical props" . uhh, when?
03:36 bacek_at_work Semantically checking byte or word are same. (I actually checked double words)
03:36 chromatic At the assembly level, we might be able to take advantage of handling 32 bits at a time.
03:36 Coke do you mean the mergeinfo crap?
03:36 Coke that's the 1.4 vs. 1.6 merging, I think.
03:36 chromatic Though that depends on the packing of live/free objects.
03:36 Coke ... which, looking at http://blogs.open.collab.net/sv​n/2008/07/subversion-merg.html, is the reason I can't use --reintegrate.
03:36 darbelo_ Coke: Whe it twiddles mergeinfo on files that have changed neither in trunk nor the branch being merged.
03:37 Coke yah. that's because we never really converted to using 1.6-style merging.
03:37 chromatic Coke, that's happened to me.  That was the precise point at which I gave up on SVN merges.
03:37 chromatic That was before 1.6, by the way.
03:37 bacek_at_work chromatic, no, it's not related to packing.
03:38 Coke I may be mis-guessing when this was added.
03:38 * Coke tries a POM.
03:38 chromatic The speedup on the branch is running compact_pool about 25% less.
03:38 chromatic Sorry, Parrot_gc_sweep_pool.
03:39 Coke chromatic: that would do it, given bacek's last commit.
03:39 TiMBuS joined #parrot
03:39 chromatic Yep, makes sense to me.
03:41 Coke Ok. Perhaps someone with git-svn can make the merge work.
03:41 Coke I'd say let's fix the repo and the mergeinfo borkedness, but it's probably easier to just wait it out.
03:42 hercynium joined #parrot
03:42 Coke I think there might be a spurious change in src/gc/*.c - double check that before committing back to trunk.
03:48 darbelo_ joined #parrot
03:54 sorear impressive... 41s to compile Grammar.pm
03:54 sorear opbots, darbelo_ joined and you trust him, what's taking you so long?
03:56 bacek_at_work opbots names
03:56 sorear I thought that was automatic on join.
03:56 sorear They never seem slow to op me.
03:57 darbelo_ I'm not sure why they trust me, I have an underscore.
03:57 sorear opbots, trust darbelo_
03:57 slavorgn But I already trust darbelo_
03:57 slavorg But I already trust darbelo_
03:57 darbelo_ darbelo is the trustworthy one. Even if I can't ssh into the box running that tmux sesion right now.
03:59 sorear bacek_at_work: your magic has made POST::Compiler ~6 times faster
04:00 sorear it now accounts for ~10% of rakudobuilds
04:00 sorear Coke: trunk: 12m40s  codestring: 7m7s
04:00 bacek_at_work sorear, I did expect some speed-up from branch :)
04:03 JimmyZ joined #parrot
04:22 Coke sounds like it's an improvement. someone ship it
04:22 Coke -> zzz
04:25 kurahaupo joined #parrot
04:27 ash_ joined #parrot
04:27 plobsing joined #parrot
04:34 jsut joined #parrot
04:35 dukeleto joined #parrot
04:37 dukeleto is feather down?
04:38 sorear yes
04:38 sorear so don't push any changes ;)
04:45 dukeleto msg Coke thanks for volunteering me for git stuff. I forgot about #ps today
04:45 purl Message for coke stored.
04:46 Coke hopefully not a problem.
04:47 Coke ... ok, bed really. laters.
04:47 sorear git is for real now?
04:47 sorear night
04:47 Coke we just need a plan.
04:47 Coke which we mostly have. just need to write it down.
04:47 Coke dukeleto: if you want even more brownie points, merge codestring back to trunk.
04:47 Coke perhaps git-svn will make it magically work.
04:48 ash_ Coke: github supports svn writes now (if you haven't already been told)
04:48 Coke msg allison FYI, merging back branches/codestring is an example where our existing repository is borked. merge --reintegrate fails.
04:48 purl Message for allison stored.
04:49 Coke msg allison (the stray mergeinfos are borking things, methinks)
04:49 purl Message for allison stored.
04:49 dukeleto Coke: yes, we have much to do
04:50 chromatic The only interesting part of the merge is a series of conflicts on NQP-rx.
05:07 bacek_at_work chromatic, branch using no-codestring-target branch of nqp-rx
05:07 cotto Would runtime/parrot/opsc.pbc be the right place to install that file?
05:15 cotto warnock means yes.
05:15 cotto I'll do that.
05:17 bacek_at_work cotto, grep -A3  Warnock CREDITS
05:19 cotto He must be so proud.
05:46 snarkyboojum joined #parrot
06:00 plobsing I get segfaults when I trigger a GC run in IMCC. Am I not allowed to create GCables in IMCC?
06:06 uniejo joined #parrot
06:07 fperrad joined #parrot
06:11 fperrad_ joined #parrot
06:28 jan joined #parrot
06:44 cotto bacek_at_work, opsc needs to either stop using the settings-based nqp-rx or the settings stuff needs to get merged upstream.  Which is easier?
06:44 cotto or better
06:44 bacek_at_work better - merge upstream
06:45 bacek_at_work easier - either of them will require some work.
06:45 bacek_at_work Or we can have parrot-specific Setting inside runtime/parrot/library
06:45 bacek_at_work (And this is probably fastest way to get ops_pct merged)
06:46 cotto I suppose getting it merged upsteam means finding some pmichaud tuits.
06:48 bacek_at_work yes. He did agreed on some kind of Setting for nqp. But we definitely need his review.
06:48 cotto Is the setting just some extra runtime stuff?
06:49 Coke joined #parrot
06:50 sorear you're back early
06:50 aukjan joined #parrot
06:50 bacek_at_work cotto, no. They are "free" if you are not using them.
06:52 cotto I'll have to take a look at them when I'm not in a near-zombie state.
06:52 cotto night
06:52 cotto If you feel like some opsc hacking, ops2c.nqp needs to not use ops.num and ops.skip for dynops.
06:52 iblechbot joined #parrot
06:53 bacek_at_work cotto, night. I'll try to some tonight after work.
06:55 cotto oic.  It'll be less than simple getting substr out of opsc.  better to merge
07:10 fperrad joined #parrot
07:39 fperrad joined #parrot
08:07 fperrad joined #parrot
08:24 bakkdoor joined #parrot
08:46 arnsholt joined #parrot
09:15 bacek ~~
09:19 jsut_ joined #parrot
09:32 JimmyZ joined #parrot
09:41 Util joined #parrot
09:42 PerlJam joined #parrot
09:42 dalek joined #parrot
09:43 rurban_ joined #parrot
09:46 dukeleto joined #parrot
09:46 pmichaud joined #parrot
09:57 mikehh codestring branch: I am getting the same build error kid51++ got - http://nopaste.snit.ch/20533 - src/gc/api.c:205: failed assertion 'PObj_is_string_TEST(obj)' - my last tests were with --optimize
09:58 mikehh this was without
10:01 mikehh furthermore although I got an inprovement in rakudo build with codestring branch real    3m16.076s vs real    3m58.972s on trunk
10:02 mikehh the make spectest results were nat better real    15m36.319s vs real    14m30.080s on trunk
10:03 mikehh s/nat/not/
10:04 JimmyZ NQP of codestring branch is not same as trunk.
10:06 mikehh the failing build was on Ubuntu 9.10 i386 (g++) the rakudo tests were with g++ with n--optimize
10:07 mikehh s/n--/--/
10:08 * JimmyZ would like to see another result by coping NQP of codestring to trunk
10:15 nopaste "JimmyZ" at 192.168.1.3 pasted "Rakudo Test Summary Report" (81 lines) at http://nopaste.snit.ch/20535
10:20 mikehh JimmyZ: I got something similar when I ran the tests - I was looking at the timings
10:21 JimmyZ mikehh: hi, mikehh, Could you copy NQP of codestring to trunk and test rakudo build time again?
10:23 mikehh JimmyZ: unfortunately not at the moment - have got to go out - bbl
10:24 JimmyZ bbl
10:24 mikehh be back later
10:24 JimmyZ bye
10:25 mikehh cul8r
10:26 mikehh also need to switch to amd64 for other tests and $work
10:33 bakkdoor joined #parrot
11:04 dalek parrot: r46530 | bacek++ | branches/codestring/src/pmc/stringbuilder.pmc:
11:04 dalek parrot: Add more flags to internal buffer to enforce contract with other string api.
11:04 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46530/
11:08 mikehh joined #parrot
11:16 lucian joined #parrot
11:21 dalek parrot: r46531 | bacek++ | branches/codestring/src/pmc/stringbuilder.pmc:
11:21 dalek parrot: Clone created string in StringBuilder.substr_str to separate mutable world from immutable.
11:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46531/
11:22 bacek sigh...
11:22 bacek My last commit made codestring branch slower...
11:36 moritz question about Configure.pl: masak has two perls installed; the one he uses for configuring parrot comes without pod2man; the other installation has pod2man in $PATH
11:36 moritz parrot's Configure.pl doesn't detect the pod2man executable
11:36 moritz is that correct?
11:37 moritz (or better, intended?)
11:42 clinton joined #parrot
11:45 JimmyZ joined #parrot
12:01 bluescreen joined #parrot
12:10 ruoso joined #parrot
12:17 JimmyZ I update trunk to use the NQP-rx of codestring branch, then trunk is faster too.
12:22 tetragon joined #parrot
12:22 mikehh JimmyZ: why are there differences with NQP-rx in trunk vs codestring branch
12:23 JimmyZ codestring branch use NQP-rx's no-codestring-target brach, it's faster.
12:24 JimmyZ err, branch
12:24 mikehh JimmyZ: nqp-rx is in ext and comes from rakudo
12:24 JimmyZ yes.
12:24 moritz it does not come from rakudo
12:24 moritz it comes from... *drumroll*... nqp-rx
12:24 JimmyZ but trunk uses master of nqp-rx and codestring uses no-codestring-target bracnh of nqp-rs
12:25 whiteknight joined #parrot
12:27 mikehh damnit I have a serious $work problem - will be tied up for a while
12:32 bacek mikehh, no worries. Btw, JimmyZ was right about nqp-rx
12:35 kendle joined #parrot
12:38 whiteknight bacek is a magician? I thought he was a robot?
12:38 JimmyZ trunk with old nqp-rx            real:8m5.546s    user:7m37.561s   sys:0m10.281s
12:38 JimmyZ trunk with new nqp-rx          real:7m48.292s  user:7m11.795s   sys:0m10.585s
12:38 JimmyZ codestring with new nqp-rx  real:6m58.873s  user:6m22.732s   sys:0m6.356s
12:38 whiteknight can robots perform magic?
12:39 bacek magic is just not obvious form of managing matter
12:40 * moritz wouldn't know why it should be a human privilege
12:40 bacek JimmyZ, yeah. Thanks for benchmark. Branch is still faster :)
12:42 JimmyZ bacek++, he is a magic robot
12:49 bacek msg Coke ship it! I probably fixed last bug in branch.
12:49 purl Message for coke stored.
12:56 Coke bah, I have to ship it? =-)
12:56 Coke I thought I dodged that bullet.
12:57 Coke the ext/nqp-rx stuff doesn't have to be merged, just copied.
12:58 Coke though i wonder if we even need it with bacek's latest magic.
12:58 bacek Coke, we do need it.
12:59 bacek When I tested codestring branch with nqp-rx master I've got way too high memory usage.
13:00 bacek Didn't investigate why, though.
13:00 tetragon joined #parrot
13:01 Coke bacek: presumably for the reason sorear branched. =-)
13:01 Coke ok.
13:02 whiteknight What is "new nqp-rx"?
13:02 Coke msg pmichaud I'm going to merge sorear's nqp-rx changes back to master so we can merge back parrot's codestring branch, fyi.
13:02 purl Message for pmichaud stored.
13:02 Coke whiteknight: nqp-rx's no-codestring-target branch.
13:02 Coke which exists in parrot's branches/codestring.
13:02 whiteknight ok
13:02 pmichaud Coke: I'm confused.
13:03 Coke it avoids taking a String copy of a CodeString every time some <common operation> occurs now that Codestring ISA StringBuilder.
13:03 bacek pmichaud, aloha
13:03 Coke pmichaud: so say we all.
13:03 pmichaud what nqp-rx changes?
13:03 Coke pmichaud: let me find the relavanent commit that needs cherry picking...
13:03 bacek topic/no-codestring-target branch
13:04 Coke pmichaud: http://github.com/perl6/nqp-rx/commit/d​a4749de3943d8a113682fa8d145927c0e09992b
13:04 pmichaud (I'm working on nqp-rx right now, as it turns out)
13:04 Coke ah. then if you could cherry pick this, we can merge back parrot's codestring branch too.
13:04 Coke which gives us some pretty good speed boosts building rakudo.
13:05 pmichaud ugh, I don't like this patch
13:05 kurahaupo joined #parrot
13:06 Coke Ok. Any suggestions on a different approach?
13:06 pmichaud Not at the moment.
13:07 pmichaud But I don't like that it keeps two copies of the source around.
13:07 pmichaud since CodeString has become more of a StringBuffer, it no longer makes sense to have the lineno method there.
13:08 pmichaud oh, and we were going to eliminate CodeString from that part of the regex anyway
13:08 * moritz suggested a separate line finder that just keeps a reference to the original (now immutable) source string
13:08 pmichaud just a sec
13:09 pmichaud *sigh*
13:09 Coke Sorry for any inconvenience. Just trying to improve build times here.
13:09 pmichaud yes, I agree
13:10 pmichaud it's just that making CodeString expensive to use as a String has some serious repercussions throughout PCT
13:10 Coke moritz: ... isn't that what sorear's patch is doing?
13:10 pmichaud because PCT really expects CodeString objects to be Strings with a few very useful utility methods attached
13:10 bacek Coke, not exactly.
13:10 moritz Coke: pmichaud meant it keeps a second copy of the string - I might have misunderstood something
13:10 pmichaud yes, it maintains a second parallel copy of the string
13:11 pmichaud which might be problematic if substitutions take place mid-match
13:11 Coke strings are immutable now, if that matters.
13:11 pmichaud strings "little 's'", yes.
13:12 pmichaud but a String PMC might not be.
13:12 pmichaud (and these are PMCs)
13:12 Coke Anyhoo, if you can suggest a benchmark that might perform worse with Codestring ISA StringBuilder, we can certainly profile trunk vs. branches/codestring.
13:13 pmichaud didn't sorear's patch indicate what the "worse performance" is?
13:13 pmichaud it says it's a memory issue.
13:13 Coke (note tha branches codestring contains the nqp-rx patch in question.)
13:13 Coke pmichaud: yes.
13:13 pmichaud right, so that's a benchmark that performs worse :-)
13:13 Coke AIUI, something is coercing the CodeString to an actual string (via get_string vtable).
13:14 pmichaud Yes
13:14 pmichaud because all of the string operations are on string registers, not PMCs
13:14 pmichaud ...wait, you mean that get_string vtable isn't caching the result?
13:15 PerlJam joined #parrot
13:16 pmichaud ugh, I really despise svn.parrot.org's  "svn browser"
13:16 pmichaud it always reports files as "binary" :-(
13:16 pmichaud so I can't easily view them in my browser
13:16 Coke http://trac.parrot.org/parrot/browser/branch​es/codestring/src/pmc/stringbuilder.pmc#L115
13:17 pmichaud ...why is clone needed there?
13:17 pmichaud oh, nm
13:17 pmichaud I know why.
13:17 bacek pmichaud, we are changing buffer behind the scene
13:17 Coke pmichaud: (that's mentioned in the comment.)
13:18 pmichaud yes, I wasn't thinking of the possibility that the CodeString itself would change
13:18 Coke so, we could cache and invalidate.
13:18 Coke but then /we're/ keeping a copy all the time, even though we don't know that someone will ever ask for it again.
13:18 pmichaud well, it sounds to me like the problem is that CodeString ends up serving too many purposes here and it ought to be broken up a bit
13:19 Coke pmichaud: We can certainly do that after 2.6
13:19 pmichaud (keeping a copy) -- yes, but get_string is likely to occur fairly often on CodeString
13:19 pmichaud Coke: We can do that now.
13:19 Coke (or provide alternate ways now for early adopters)
13:19 pmichaud we simply move the StringBuffer functionality out of CodeString and into a new PMC type
13:19 pmichaud and leave the existing CodeString alone.
13:19 moritz pmichaud: you're aware of the new stringbuilder PMC?
13:20 Coke that get_string is not in codestring but the parent stringbuilder.
13:20 pmichaud my point remains
13:20 pmichaud if we leave the existing CodeString alone and simply provide a new faster string builder PMC, then PCT can start switching to using the new one
13:20 pmichaud without having to wait a deprecation cycle
13:21 Coke there is already a new, faster, stringbuilder pmc.
13:21 Coke (in trunk, even.)
13:21 pmichaud you're avoiding my point, or not seeing it.
13:21 Coke not seeing it.
13:21 pmichaud okay.  the new stringbuilder provides an 'emit' method?
13:21 Coke I feel the same way from my side, so I guess we're even.
13:21 Coke no.
13:21 pmichaud can it?
13:21 purl NO!  IT CAN'T!
13:22 Coke pmichaud: I would rather not put that on SB.
13:22 pmichaud (I apologize that I haven't been able to keep up with all of the permutations of codestring mutations.)
13:22 pmichaud Can we derive a new PMC type from SB that provides 'emit'?
13:22 Coke Instead of CodeString, sure.
13:22 pmichaud then PCT can use that for when it's generating code.
13:23 Coke I was trying to avoid having to rewrite everything else or support 2 PMCs. And we pretty much have done that.
13:23 pmichaud except that now the complexity is being pushed into PCT and the HLLs
13:23 Coke ok. So, let's say we have CodeBuilder instead of CodeString. Is this new CB going to work just like CS in the branch?
13:24 pmichaud it probably shouldn't have the 'lineno', 'unique', 'escape', etc. methods
13:24 Coke pmichaud: there's no change required to PCT or the HLLs in the branch (and the one benchmark we've been doing is improved.)
13:24 pmichaud Coke: okay, I'm considering NQP to be part of PCT/HLL
13:25 pmichaud and sorear's patch indicates that there *is* a change required
13:25 Coke ok. It sounds like your plan requires even more changes.
13:26 pmichaud I'm saying the fundamental factoring of CodeString (both old and new) is wrong.  We can fix it now, or pay for it later.
13:26 bacek +1 for pmichaud. It's much cleaner to have 2 PMCs for different semantics.
13:26 pmichaud If we're just after the short-term fix and willing to incur the technical debt, then...
13:26 Coke So, I'm screwed for trying to NOT break the old API. =-)
13:26 whiteknight how long will it take to fix it now?
13:26 atrodo joined #parrot
13:26 whiteknight if the proper fix can get in before the release, everybody would be most happy
13:26 bacek OTOH, let's add C<emit> into StringBuilder
13:27 bacek http://msdn.microsoft.com/en-us/library/system.t​ext.stringbuilder.appendformat%28v=VS.71%29.aspx
13:27 pmichaud I don't think it should take long at all.  But I can't speak to it at the moment because this caught me a little cold this morning and so I haven't had a chance to even learn what all of the new PMCs are.
13:27 Coke we'll call it something other than emit, though.
13:28 pmichaud I'm fine if it's called something other than emit.  The number of instances of 'emit' is very small.
13:28 bacek Coke, "AppendFormat" :)
13:28 pmichaud Coke: (break API)  -- yes, I'm saying that whoever designed the old API was insufficiently advanced.  :-)
13:30 bacek Anyway, salvaging "CodeString.emit" from branch is valuable. We can move it into StringBuilder and make CS "has-a" SB.
13:30 pmichaud more to the point, nqp-rx needs to be doing its matching against a HLL-supplied string object, and not coercing it into a Parrot String PMC
13:30 pmichaud bacek: no, I think we can just leave CodeString alone
13:31 pmichaud if we just switch POST::Compiler to build using a StringBuilder instead of a CodeString, then all should be fine.
13:31 bacek pmichaud, what about .emit?
13:31 pmichaud (and that's a easy switch)
13:31 pmichaud we can deprecate the .emit in CodeString
13:31 Coke pmichaud: there's no reason not to speed up Codestring if it's easy.
13:31 pmichaud Coke: I'm not saying we shouldn't do the speedups.
13:31 dalek parrot: r46532 | bacek++ | branches/codestring/src/pmc/stringbuilder.pmc:
13:31 bacek pmichaud, but .emit is quite useful.
13:31 dalek parrot: Rearrange comments in StringBuilder.get_string
13:31 Coke well, some reason. but little.
13:31 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46532/
13:31 pmichaud wait
13:31 pmichaud stop
13:31 pmichaud you all are confusing me.
13:32 Coke right back atcha. :P
13:32 pmichaud bacek:  do you propose adding a .emit-like method to StringBuilder?
13:32 bacek pmichaud, yes
13:32 pmichaud okay.  If we do that, then PCT can switch to using StringBuilder for generating its code
13:32 Coke s/like/identical/ Unless you have a new proposed interface for that method.
13:32 pmichaud no, same interface, please.
13:33 Coke (ignoring how the guts are implemented)
13:33 bacek than "identical"
13:33 pmichaud okay.  If we do that, then PCT (POST::Compiler) can switch to using StringBuilder, and we get the speed improvement.
13:33 pmichaud Existing users of CodeString then do not pay the string-cloning penalty that would otherwise occur everytime get_string is called on it.
13:34 bacek They will...
13:34 pmichaud generally CodeString gets used in one of two modes
13:34 pmichaud the first mode is to generate PIR code, via .emit
13:34 pmichaud the second mode is to analyze a string, e.g. via   .lineno and .escape
13:35 pmichaud they really belong in different types or classes
13:35 bacek agreed
13:35 moritz and the regex engine only uses the second, right?
13:35 bacek Let's move .emit into SB.
13:35 bacek Made CS isa String.
13:35 pmichaud actually, the regex engine uses none of that
13:35 pmichaud which is why this particular patch bugs me.
13:35 pmichaud *none* of what CS does is important to the regex engine.
13:35 bacek and it will help with migration to "brand new world"
13:36 moritz so why does it use CS?
13:36 moritz technical debt?
13:36 purl i guess technical debt is the debt you build up of stuff you have to do later. http://c2.com/cgi/wiki?TechnicalDebt or http://www.media-landscape.co​m/yapc/2006-06-26.AndyLester/
13:36 pmichaud because the regex engine is commonly used on source code, and the resulting source code generation needs .lineno and .unique and .escape
13:36 pmichaud i.e., the regex engine doesn't want CodeString, but the the that consumes the parse tree it produces often does
13:36 moritz oh
13:36 pmichaud *the thing
13:37 pmichaud so patching the regex engine to keep a parallel codestring and String PMC is Just Wrong.
13:37 pmichaud because the regex engine should be agnostic to that.
13:38 pmichaud folks, I need about a 15 minute break here, then I'll be back to discuss further.
13:39 Coke bacek: ok. in branch: 1) move .emit() over to SB and call it .someNewMethod(). revert changes to ext/nqp-rx in branch. revert changes to codestring in branch. add deprecation notice for CS .emit() (SB is already covered by existing experimental notice, presuming one was added for trunk)
13:39 Coke then someone needs to figure out which uses of CodeString in core need updated to SB.
13:39 bacek Coke, yes.
13:40 bacek any volunteers?
13:40 purl any volunteers are welcome and get beer and pizza.
13:40 Coke I'm at $DAYJOB, I can try it out this evening if you don't beat me to it.
13:41 bacek .append? .append_format? .concat_format?
13:41 plobsing joined #parrot
13:41 moritz appendf? (like printf)
13:41 bacek It's 21st century! Everyone use code completion in editors :)_
13:42 * moritz doesn't really care either way
13:43 * bacek like "append_format"
13:45 bacek Coke, ok. I can do it tomorrow morning. (About +7 hours from now() )
13:45 bacek And it's 15 minutes till tomorrow already...
13:47 iblechbot joined #parrot
13:51 bacek Good night, humans. Time to recharge.
13:53 moritz have the appropriate amount of refill
13:54 pmichaud (existing uses of CodeString in core)... ack seems to indicate that the only current CodeString user that needs updating is PCT
13:55 pmichaud the other components are deprecated
13:57 pmichaud okay, back from my other errand...  can I elaborate a bit on things I was saying before?  (might help to chart a slightly different path forward)
13:58 JimmyZ +1
13:58 purl 1
13:58 pmichaud Truly, I think that what currently exists as CodeString PMC perhaps ought to be renamed into something like "PIRBuilder"
13:59 pmichaud because it's really an object designed to make it easier to generate PIR.  Yes, it can be very much used for other purposes, but some of its methods are fairly PIR-specific.
14:00 pmichaud this is particularly true of .emit, .escape, .key, and .unique
14:02 pmichaud the other methods -- .lineno and .charname_to_ord ended up in CodeString primarily because it was a convenient place to hang things that somewhat needed to be done in C
14:03 pmichaud I'm fine if we move .lineno out of CodeString and directly into PCT (as PIR).  Since we're using a different caching algorithm for computing line numbers now, doing it in PIR might not be as time-costly as it was before.
14:04 pmichaud that just leaves .charname_to_ord, which really doesn't use CodeString at all other than as a place to hang a method.  Ideally I suspect it should become an opcode, or a dynop.
14:06 pmichaud so, my proposal at this point would be
14:07 pmichaud 1.  Leave existing CodeString PMC alone, deprecate it
14:07 pmichaud 2.  Add a PIRBuilder isa StringBuilder that has .emit, .escape, .key, .unique
14:07 pmichaud 3.  Update PCT to use PIRBuilder instead of CodeString, add .lineno capability to PCT
14:08 pmichaud 4.  create a charname_to_ord opcode
14:09 pmichaud I'd also be fine if we
14:09 pmichaud 1.  Leave existing CodeString PMC alone, deprecate it
14:09 pmichaud 2.  Add .emit to StringBuilder
14:09 pmichaud 3.  Update PCT to use PIRBuilder instead of CodeString, add .lineno, .key, .escape to PCT   (PCT already has a .unique)
14:10 pmichaud 4.  create a charname_to_ord opcode
14:10 pmichaud I should have time over the next couple of days to do the PCT changes.
14:11 pmichaud Indeed, I could trivially switch PCT to subclass "CodeString", "PIRBuilder"  and get it to work there
14:11 pmichaud then when the PIRBuilder PMC is ready, we simply eliminate the CodeString line :-)
14:11 pmichaud (the one that subclasses :-)
14:12 * pmichaud thanks all of the crickets who remained throughout this presentation.
14:13 moritz pmichaud: ilbot2 is patient and calm :-)
14:14 Themeruta joined #parrot
14:14 whiteknight I like the idea of PIRBuilder isa StringBuilder
14:15 whiteknight there's quite a lot we could do with it, if we were clever enough
14:16 pmichaud I think I'll go ahead and switch PCT to avoid using .key and .escape from CodeString
14:16 pmichaud they made sense at the time, but the way the toolkit has evolved since then argues for them being in PCT proper instead of Parrot core PMCs
14:17 pmichaud (they made more sense when PGE *and* PCT were doing codegen.  But PGE is on its way out.)
14:17 ash_ joined #parrot
14:19 pmichaud anyone have objection to a charname_to_ord opcode?
14:19 pmichaud it just accepts a unicode character name and returns the corresponding codepoint
14:20 pmichaud (via ICU)
14:21 pmichaud if the opcode isn't acceptable, I'd be happy for .charname_to_ord to live in PIRBuilder
14:22 NotFoundB pmichaud: I object the name, is not consistent with other string ops.
14:23 pmichaud I'm fine with a name change also :-)
14:23 NotFoundB chr_from_name, find_cname, something like that will fit better.
14:23 pmichaud needs to be ord_from_name
14:23 pmichaud it needs to return the codepoint, not a string
14:24 NotFoundB pmichaud: ord is used only in the ord opcode.
14:24 Coke just chunk it into experimental.ops, doesn't need to be a dynop then.
14:24 moritz so codepoint_from_name ?
14:24 pmichaud find_codepoint
14:24 Coke I would rather avoid the name "PIRBuilder". There is nothing inherently PIRish about .emit()
14:24 JimmyZ much bettor
14:25 Coke and if we're just adding .emit(), I don't see a problem with that living on SB.
14:25 JimmyZ +1 to find_codepoint
14:25 NotFoundB pmichaud: What must it do when name not found?
14:25 pmichaud NotFoundB: returns -1, same as it does now.
14:25 NotFoundB Ok
14:26 pmichaud Coke: yes, that's my alternate approach above  (add .emit to StringBuilder, put other methods into PCT)
14:27 NotFoundB pmichaud: In experimental.ops for a now?
14:27 pmichaud yes, find_codepoint is consistent with the other string ops   (find_charset, find_encoding)
14:27 pmichaud experimental.ops would be great, yes.
14:27 NotFoundB I'll do it.
14:27 pmichaud NotFoundB++
14:28 pmichaud having find_codepoint as an op will be a very good help to NQP, Rakudo, and other things that need to deal with Unicode codepoint names
14:29 pmichaud currently they tend to create empty CodeString objects just for the purpose of looking up a codepoint (somewhat wasteful :-)
14:30 pmichaud see src/pmc/codestring.pmc:299 for the existing find_codepoint code
14:30 pmichaud (under the name charname_to_ord)
14:30 pmichaud it's very short and simple
14:30 NotFoundB Was looking, yes,
14:31 Coke NotFoundB: should probably do this in branches/codestring.
14:31 pmichaud if it's in trunk, I can start switching nqp to use it immediately :-)
14:31 pmichaud (PCT doesn't use it.)
14:32 * NotFound back to desk
14:34 Coke The one issue I have with something like .emit() on SB is that you then cannot get the formatting without a newline. Adding an optional parameter to say "no newline" would cover that.
14:35 Coke reasonable?
14:35 purl reasonable is, like, definitely not sungo
14:35 pmichaud I'm not sure where the optional parameter would go, though.
14:35 pmichaud we already have slurpy args and slurpy hash
14:36 pmichaud maybe .emit and .emitnl
14:36 pmichaud maybe .printfmt and .sayfmt :-)
14:37 moritz that's better
14:38 Coke I can split them up, sure, and kill the optional newline appending.
14:39 pmichaud having it as an optional named parameter might work, since all of the other items in the slurpy hash tend to be single-character keys
14:39 pmichaud but slipping it in that way feels icky somehow.
14:39 pmichaud printfmt/sayfmt seems more consistent, at least on a Perl 6 and Pascal level :-)
14:40 moritz pascal6++
14:40 pmichaud also, it would no longer bother me if we just had .emit that didn't add the newline.  In PCT (unlike PGE) there are so few instances of .emit that it wouldn't be at all problematic to add \n's to the fmt string
14:40 Coke as long as it's not actually print and say, sure. =-)
14:41 Coke pmichaud: ah. in that case, I'll just drop it. =-)
14:41 pmichaud PGE had tons of .emit calls, and having to remember to add the \n's was a pain.
14:41 pmichaud (yes, looks like PCT has a total of eight .emit calls)
14:43 bubaflub joined #parrot
14:43 atrodo pascal6++
14:46 pmichaud looks like PCT's use of .escape is already somewhat reasonably factored
14:46 pmichaud so moving it out of CodeString shouldn't be difficult
14:48 Coke ok. but we can't cutover until it's done, ja. I suspect that a PIR version of that in place where PCT calls codestrings would be just fine.
14:48 Coke (as that would then avoid a PCC invocation.)
14:48 pmichaud well, again my proposal says to completely leave CodeString alone
14:48 pmichaud (but deprecated)
14:49 pmichaud so that tools and libraries have a few months to switch over to the new items
14:49 Coke ... I'm not suggesting changing codestring.
14:49 pmichaud right
14:49 pmichaud but we can start moving PCT to not use the codestring versions now :-)
14:49 pmichaud and nqp, and ...
14:50 Coke I'm saying, make pct's escape() not a dispatch but the actual work, in place, in pir, right there.
14:50 pmichaud exactly
14:50 pmichaud that was my nefarious plan
14:50 pmichaud s/was/is/ :-)
14:50 Coke ok. then I'm not sure why you're correcting me about leaving codestring alone. =-)
14:50 pmichaud "we can't cutover..."
14:51 pmichaud I think my head is a little fogged this morning; pay little attention to me except for the parts where I need you to pay attention.  :-)
14:52 Coke we can't s/CodeString/StringBuilder/ in PCT until all the other bits are done.
14:52 pmichaud we shouldn't s/CodeString/StringBuilder/  in the first place :-)
14:52 Coke in PCT?
14:52 pmichaud it really needs to just be rewritten a bit
14:52 Coke I thought that was, forgive me, the plan.
14:52 pmichaud well, it's a little more than just s/CodeString/StringBuilder/
14:53 Coke ARGH.\
14:53 pmichaud not much more -- it's easy
14:53 Coke please stop telling me I'm wrong and then agreeing with me. =-)
14:53 Coke it's very frustrating.
14:54 pmichaud sorry, I keep thinking you're looking for a simple search+replace answer where I think there's a bit more work to be done here
14:54 Coke dear god, man. That is what I am saying.
14:54 Coke (as an atheist, I need a better catch phrase.)
14:54 pmichaud right, but s/CodeString/StringBuilder/  looks like a search+replace answer.  Ignore me, I'm obviously just confusing things unnecessarily.
14:55 Coke again, correct me if I'm wrong, but at the end of this exercise, we want PCT to not be using Codesting.
14:55 pmichaud Correct.
14:55 Coke so we clearly have to make that substitution at some point.
14:55 Coke but we can't right now, because <few other bits of work>
14:56 NotFound r46533
14:56 pmichaud the only place that should have  s/CodeString/StringBuilder/  is in src/POST/Compiler.pir
14:56 Coke Yes.
14:56 pmichaud all other instances of CodeString ought to be removed.
14:56 pmichaud (all other instances in PCT ... )
14:57 pmichaud and the .lineof  part of POST::Compiler needs a refactor
14:58 * Coke just shelves this for now.
14:58 Coke reboot.
15:04 pmichaud NotFoundB: there are some tests for charname_to_ord in t/pmc/codestring.t -- perhaps those could be migrated into t/op/stringu.t
15:04 NotFound pmichaud: looking
15:04 ttbot Parrot trunk/ r46533 i386-linux-thread-multi make error http://tt.taptinder.org/file/cmdout/306720.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
15:05 NotFound Uh...
15:05 Coke s/migrated/copied/
15:06 Coke s/INTERP/interp, perhaps?
15:06 NotFound Yes, but maybe one more...
15:07 bakkdoor joined #parrot
15:08 uniejo joined #parrot
15:08 ttbot Parrot trunk/ r46534 i386-linux-thread-multi make error http://tt.taptinder.org/file/cmdout/306747.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
15:12 dalek parrot: r46533 | NotFound++ | trunk (3 files):
15:12 dalek parrot: experimental op find_codepoint
15:12 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46533/
15:12 dalek parrot: r46534 | NotFound++ | trunk/DEPRECATED.pod:
15:12 dalek parrot: reference find_codepoint trac ticket
15:12 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46534/
15:14 dalek TT #1629 created by NotFound++: find_codepoint experimental op
15:14 dalek TT #1629: http://trac.parrot.org/parrot/ticket/1629
15:16 dalek tracwiki: v2 | allison++ | GitMigration
15:16 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Gi​tMigration?version=2&amp;action=diff
15:29 dalek parrot: r46535 | NotFound++ | trunk/src/ops/experimental.ops:
15:29 dalek parrot: fix no ICU branch of find_codepoint, ttbot++
15:29 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46535/
15:29 dalek parrot: r46536 | gerd++ | trunk/docs/book/pct/ch02_getting_started.pod:
15:29 dalek parrot: add missing brackets; change to the correct executable name of nqp at parrot
15:29 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46536/
15:29 dalek parrot: r46537 | NotFound++ | trunk/t/op/stringu.t:
15:29 dalek parrot: port codestring charname_to_ord tests to find_codepoint
15:29 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46537/
15:30 Mokurai joined #parrot
15:32 dalek tracwiki: v3 | allison++ | GitMigration
15:32 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Gi​tMigration?version=3&amp;action=diff
15:45 dalek parrot: r46538 | gerd++ | trunk/docs/book/pct/ch02_getting_started.pod:
15:45 dalek parrot: remove the not working bolds in verbatim text
15:45 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46538/
15:49 dalek tracwiki: v4 | allison++ | GitMigration
15:49 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Gi​tMigration?version=4&amp;action=diff
15:55 the_irrational_one joined #parrot
16:10 theory joined #parrot
16:13 cotto_work '
16:23 jsut joined #parrot
16:25 dukeleto_ joined #parrot
16:45 jsut_ joined #parrot
16:56 dalek tracwiki: v5 | cotto++ | GitMigration
16:56 dalek tracwiki: add some concrete dates
16:56 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Gi​tMigration?version=5&amp;action=diff
17:06 Andy joined #parrot
17:15 davidfetter joined #parrot
17:18 hercynium joined #parrot
17:20 ash__ joined #parrot
17:30 preflex joined #parrot
17:33 sorear pmichaud: Breaking up CodeString was my original proposal.  bacek dissuaded me... adding new core PMCs is not something that a newbie like me should be doing
17:35 pmichaud sorear: well, you were on the right track then :)
17:35 pmichaud as it is we're only adding StringBuffer, and otherwise eliminating CodeString
17:37 sorear pmichaud: the regex engine uses lineno for "panic" and to set the "pos" attributes of match objects
17:37 pmichaud looking.
17:38 pmichaud I suspect we'll write a PCT::LineCounter object then.
17:39 pmichaud or something like that.
17:39 pmichaud anyway, PCT will be providing the line-counting mechanism somewhere.
17:40 pmichaud I just need to figure out a good place to stash the line counts.
17:40 pmichaud s/stash/cache
17:41 sorear regarding things which are only used in one place:
17:42 sorear the Capture PMC is used (outside PGE/TGE; are these deprecated yet?) only in PCT::Node
17:42 pmichaud it's also used in Regex::Match in nqp-rx
17:42 pmichaud it's also used in Rakudo.
17:43 rurban_ joined #parrot
17:43 sorear huh, I thought rakudo was using an independant implementation nowadays
17:43 pmichaud (and Rakudo also has its own Capture, which is a bit separate)
17:43 pmichaud anyway, the regex engine uses Capture fairly directly.
17:44 sorear anyways, the other day I was trying an experiment to replace Capture in PCT::Node with 'real' objects
17:44 iblechbot joined #parrot
17:44 sorear since the named fields are always bounded statically
17:44 pmichaud ?
17:44 pmichaud bounded statically?
17:44 sorear it didn't quite work out, subclasses of RPA don't make sense to me yet
17:45 pmichaud if you mean that the hash portion of PCT::Node is static, it's not.
17:45 sorear pmichaud: a PAST::Block can have - blocktype, source, pos, pirflags, ..., outer.  Nothing else
17:45 pmichaud Rakudo makes heavy use of the ability to stash extra attributes inside of PAST nodes via the hash interface
17:45 pmichaud sorear: no, in Rakudo there are lots of other fields that are accessed via the hash interface
17:46 pmichaud (I've tried to discourage jnthn++ from making use of it; it gets used far more heavily than I'd like.)
17:46 sorear Ah
17:46 sorear Thank you
17:46 sorear (this is precisely why I asked you)
17:46 pmichaud but anyway, at present PCT explicitly allows HLLs to hang their own attributes off of PAST nodes without going through a method interface.
17:47 pmichaud (with the caveat that there may be conflicts with the existing PAST entries)
17:47 pmichaud besides, using the hash access is far more efficient speed-wise than going through object attributes.
17:47 sorear (Yes.  I support all the redesigning of codestring.)
17:48 sorear ...what?
17:48 sorear that sounds... broken
17:48 pmichaud object attributes are slow.
17:48 pmichaud well, if you think about it, object attributes also require hash lookups
17:49 pmichaud so you still have the cost of a hash lookup, *plus* the cost of then fetching the attribute
17:49 pmichaud if that sounds broken... I don't disagree.  But I didn't design Parrot's object system.  :-)
17:49 pmichaud and if we then go through a method accessor to get the attribute, it's slower still.
17:50 pmichaud (and if it's via a PCC method, I think its still even slower than that.)
17:51 sorear What's a PCC method?
17:51 pmichaud methods on PMC classes that are written in C
17:51 pmichaud e.g., the 'emit' method on CodeString PMC :-)
17:57 whiteknight how should Parrot's object system do attributes differently?
17:59 hercynium joined #parrot
18:05 dalek tracwiki: v6 | allison++ | GitMigration
18:05 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Gi​tMigration?version=6&amp;action=diff
18:09 pmichaud whiteknight: I don't know.  Just because I can point out the difficulties with the existing system doesn't mean I know how to construct a better one.  :-)
18:09 pmichaud I just know that parrot's notion of what is efficient doesn't always jibe with what users expect.
18:10 pmichaud for example, there was a change added last year that converted hash vtable lookups into PCC method calls under the theory that this was "more efficient"  (when it is in fact anything but that)
18:12 hercynium joined #parrot
18:13 patspam joined #parrot
18:14 allison joined #parrot
18:21 allison Anyone here willing to answer a completely bizarre question not related to Parrot?
18:21 Tene I am!
18:21 sorear I am!
18:21 Tene No, ME!
18:22 allison If you went to a conference and they had marketing slogans printed on the toilet paper, how would you react?
18:22 allison a) offended
18:22 allison b) laugh it off
18:22 allison c) who cares
18:23 Tene "marketing slogans"?
18:23 davidfetter depends whose marketing slogans, i suppose
18:24 davidfetter might grab bunches of such rolls if they were the right marketing slogans
18:24 allison "Your Wasteful Dedicated Server" visit booth #111
18:24 davidfetter "move to the cloud", e.g.
18:25 allison davidfetter: aye
18:25 Tene allison: I would not care at all, and be very surprised if anyone cared.
18:26 allison Tene: that's helpful
18:27 pmichaud I suppose it depends on what is being marketed.  :-)
18:27 pmichaud in some ways, one could say "I'm going to put your product exactly where it belongs."
18:28 bubaflub joined #parrot
18:28 pmichaud one of my favorite quotes:  "I'm in the most used room in the house.  I have your manuscript in front of me.  Soon it will be behind me."
18:28 allison it looks like they carefully avoided putting any reference to the company on the paper
18:28 allison hah :)
18:29 pmichaud (actually I think it's  "I'm stitting in ... "
18:32 whiteknight hash vtable lookups are PCC method calls?
18:33 pmichaud whiteknight: no
18:34 pmichaud but the hash iterator interface was changed under the assumption that doing    hashkey.'key'(key)   was faster than hash[key]
18:34 whiteknight ah
18:35 pmichaud (I don't have that exactly right, but yes, it assume that PCC method calls were faster than vtable functions)
18:35 pmichaud it assumed  that    hashkey.'value'() was faster than hash[key]
18:35 pmichaud for looking up iterated values of a hash
18:37 whiteknight hmmm, that's certainly not correct
18:38 whiteknight PCC method calls would be faster in most cases, I think, thank vtable overrides of PIR-defined types
18:40 pmichaud I don't know about that, since PCC method calls involve creating a new runloop (iirc)
18:40 pmichaud although perhaps vtable overrides involve the same.
18:40 pmichaud sorry, have to run
18:40 pmichaud bbl
18:41 athomason joined #parrot
18:45 whiteknight new runloops are created in vtable overrides, but not in a normal method or a PCC method call
18:46 NotFound If you call a pir method from C you need a runloop.
18:48 whiteknight right
18:48 whiteknight so PIR vtable overrides are slower than PIR methods
18:51 pmichaud makes sense
18:52 pmichaud still, this all goes to show that what seems intuitively faster is not necessarily so in Parrot.
18:52 NotFound But the cost is to slowing down the not overriden usage, that in cases like hash may be much more frequent.
18:55 NotFound BTW, the Handle dance implies calling a method, but inside C functions called from opocdes, wich loses the possible advantange of the pir-pir method call.
18:58 whiteknight yeah
19:01 cotto_work msg cotto remove pmc/pmc_callcontext.h from compilers/opsc/src/Ops/Trans/C.pm
19:01 purl Message for cotto stored.
19:03 cotto_work anyone need some easy karma?
19:04 whiteknight ?
19:05 cotto_work check out ops_pct and make the above change
19:05 whiteknight ops_pct branch?
19:05 purl rumour has it ops_pct branch is coming along nicely
19:05 cotto_work run make bootstrap-ops and check it in
19:06 cotto_work no, ops_pct is where bacek and cotto are working on an nqp compiler for ops
19:06 purl okay, cotto_work.
19:24 fperrad joined #parrot
19:24 bakkdoor joined #parrot
19:26 whiteknight cotto_work: no can do. At least, not till I get home
19:26 cotto_work same here.  It's not a huge deal either way.
19:37 fperrad_ joined #parrot
19:37 darbelo cotto_work: I can remove whatever you wanted cotto to remove ;)
19:37 cotto_work thanks
19:37 cotto_work I don't really trust that guy.
19:38 darbelo He's ok.  Sometimes.
19:38 bubaflub hahaha
19:46 nopaste "darbelo" at 192.168.1.3 pasted "Like this? Or is there anything more?" (13 lines) at http://nopaste.snit.ch/20537
19:47 cotto_work That and make bootstrap-ops
19:48 darbelo Hah, maybe that's why my build just failed.
19:49 darbelo No, it isn't. Looks like a missing rule...
19:49 darbelo make: don't know how to make compilers/opsc/gen/Ops/Compiler.pir.
19:52 joeri joined #parrot
20:00 TimToady phone
20:01 theory joined #parrot
20:01 cotto_work The dependencies might be goofy.
20:05 theory joined #parrot
20:05 cotto_work I need to fix that.  It'll work if you run make first.
20:11 cotto_work joined #parrot
20:20 tcurtis joined #parrot
20:53 cotto_work where's the testexceptions_refactor branch?
20:54 bacek Good morning, my biological friends.
20:55 Tene cotto_work: there's a testexceptions_refactor branch?
20:56 cotto_work There's one mentioned in the topic.
20:56 bacek Tene, at least in channel topic
20:56 cotto_work hio bacek
20:56 bacek aloha cotto_work
20:56 Topic for #parrotis now Parrot 2.3.0 Released | http://parrot.org/ | Channel log: http://irclog.perlgeek.de/parrot/today | Priority: apply deprecations, merge branches, test exceptions_refactor branch | GSoC students, please read http://trac.parrot.org/par​rot/wiki/GSoCersStartHere
20:56 Tene I think that's what was meant.
20:57 Tene I don't know why, though.  It's not suitable for testing ATM.
20:57 Topic for #parrotis now Parrot 2.3.0 Released | http://parrot.org/ | Channel log: http://irclog.perlgeek.de/parrot/today | Priority: apply deprecations, merge branches, finish exceptions_refactor branch | GSoC students, please read http://trac.parrot.org/par​rot/wiki/GSoCersStartHere  
20:57 cotto_work while pmichaud is around, do you plan on bringing up your nqp-rx + settings branch?
20:58 cotto_work ^ at bacek
20:58 bacek cotto_work, ah, yes.
21:03 darbelo cotto_work: My digging indicates my breakage is related to the use of '%' in makefile rules.
21:03 cotto_work does your os not think that awesome?
21:04 darbelo My make finds it insuficiently tasty.
21:04 darbelo Hence, it refuses to swallow it.
21:04 darbelo I'm trying with GNU make now.
21:04 cotto_work I thought I saw something else in parrot that used that.  I'll have to fix it.
21:06 cotto_work or you can if you feel like it
21:07 cotto_work Having a bunch of repetition in the makefile won't be so bad now that new files aren't being added regularly
21:09 cotto_work msg cotto also take % out of compilers/opsc/Rules.mak
21:09 purl Message for cotto stored.
21:12 bacek msg pmichaud I'm going to add .emit (as .append_format) to StringBuilder (as part of second version of your proposal)
21:12 purl Message for pmichaud stored.
21:12 pmichaud bacek++
21:13 pmichaud note that there are tests in t/pmc/codestring.pmc that can be stolen for this :-)
21:13 bacek pmichaud, when you'll have time to discuss nqp Setting? I've created initial version in my nqp-rx fork.
21:14 pmichaud bacek: I don't know for sure.  Now isn't a good time (too much else already on my plate); my best guess is either tomorrow about this time or friday
21:14 bacek pmichaud, ok.
21:14 pmichaud I should be around much more often from now on
21:14 pmichaud what's the url of the nqp-rx fork?
21:14 pmichaud I might get a chance to look at it later
21:15 pmichaud (I suspect I could go searching.. but easier if you point me at it directly :)
21:15 bacek github.com/bacek/nqp-rx
21:15 pmichaud excellent
21:15 darbelo cotto_work: I was wrong. gmake: *** No rule to make target `compilers/opsc/gen/Ops/Compiler.pir', needed by `runtime/parrot/library/opsc.pbc'.  Stop.
21:15 sjn o/
21:15 bacek darbelo, make; make bootstrap-ops
21:15 dalek parrot: r46539 | gerd++ | trunk/docs/book/pct/ch03_compiler_tools.pod:
21:15 dalek parrot: remove not working bold
21:15 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46539/
21:15 GeJ Good morning everyone.
21:16 darbelo bacek: that fails too, with the same message ;)
21:16 bacek pmichaud, what about "automatically add new line" in .emit?
21:16 bacek pmichaud, create 2 methods? Optional flag?
21:16 pmichaud I think we decided not to automatically add the newline
21:16 pmichaud .emit is used only eight times in PCT, so easy enough to add the newlines manually
21:16 bacek pmichaud, ok.
21:16 moritz darbelo: are there any parrot built-ins for converting between Unicode normal forms?
21:17 pmichaud (different from PGE, which called .emit a bunch of times and newlines would've been a pain)
21:17 bacek And we are deprecating CodeString with PGE all together?
21:17 darbelo moritz: Not really. The best you can do is transcode IIRC.
21:18 pmichaud bacek: I don't have any plans to update PGE, no.
21:18 pmichaud so yes, CodeString needs to live until PGE goes away
21:18 pmichaud but I think PGE is already deprecated-ish
21:18 moritz darbelo: reason is, Perl 6 has a bulit-in function that transfers marking characters from one string to another
21:19 moritz and in perl 5 I implemented that by decomposing, copying marks, and then composing the result
21:19 darbelo What do you mean "transfers marking characters"?
21:20 moritz 'ö'.sameaccent('a') yield 'ä'
21:20 * darbelo boggles.
21:21 moritz so it copies the diacritics on a character-by-character basis
21:21 moritz and same with other markings, like accents
21:22 moritz not sure if this function makes any sense, but it had a nice symmtrie to 'samecase'
21:23 darbelo I can't come up with a use case, but I think we can support that. I'd have to look a bit more into our uses of ICU, but it sounds doable.
21:24 moritz it's not a high priority either
21:25 moritz just thought I'd ask you, because you seemed to have more hands-on knowlege with Unicode+parrot stuff than I do
21:25 bacek pmichaud, StringBuilder.append_format added in codestring branch. Should I go ahead and update PCT?
21:26 bacek pmichaud, in all 8 places :)
21:26 * moritz thought nqp-rx needs updating, not PCT
21:26 pmichaud bacek: I'm working on a number of PCT changes in trunk
21:26 moritz maybe I'm confuse
21:26 pmichaud nqp-rx will want some updating too, but can live with what's being currently changed
21:27 moritz and certainly ripe for bed
21:27 moritz good night
21:27 pmichaud moritz: we ultimately decided to keep the existing CodeString for a while for deprecation
21:27 bacek pmichaud, let me check diff with trunk.
21:27 pmichaud bacek: if you want to start updating PCT, that's fine.
21:28 pmichaud at least, POST::Compiler
21:28 pmichaud you shouldn't need to update anything else for the switch
21:28 bacek pmichaud, looks like I can copy new StringBuilder into trunk.
21:28 pmichaud bacek: yes, that's what I was hoping/expecting
21:28 bacek pmichaud, there is one usage of .emit in POST::Node
21:28 pmichaud I'm getting rid of that one.
21:28 pmichaud although if you want to just switch it to StringBuilder as well, that's fine too.
21:29 pmichaud that's probably easiest for now.
21:29 bacek ok
21:30 kurahaupo joined #parrot
21:30 bacek I'm moving to trunk and bringing new StringBuilder there
21:30 pmichaud \o/
21:31 bacek Wow. git checkout master; git checkout --their codestring -- src/pmc/stringbuilder.pmc t/pmc/stringbuilder.t
21:31 bacek Too easy :)
21:32 Whiteknight joined #parrot
21:32 dalek parrot: r46540 | bacek++ | branches/codestring (2 files):
21:32 dalek parrot: Add StringBuilder.append_format method (copyed from CodeString.emit method without adding newline
21:32 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46540/
21:33 Coke bacek: I have a working copy with some of these changes for CS/SB
21:34 bacek Coke, sigh... Too late. r46541
21:34 pmichaud note that POST won't quite work with s/CodeString/StringBuilder/   because it currently expects  the built-up-string to have a .escape method
21:34 pmichaud I'm fixing that now.
21:34 bacek But you can commit it. I'll cherry-pick it to trunk.
21:34 Coke bacek; at $DAYJOB; you win. =-)
21:35 bacek Coke, :)
21:36 * pmichaud svn ups, builds
21:36 bacek pmichaud, you can use new StringBuilder.append_format. It's in trunk already.
21:36 pmichaud bacek: sure, but I don't have a StringBuilder.escape
21:36 pmichaud and POST::Compiler was using CodeString.escape
21:36 pmichaud I'm getting rid of that now.
21:37 pmichaud (it's now going to be POST::Compiler.escape)
21:37 bacek pmichaud, ok.
21:37 * bacek wait patiently.
21:37 pmichaud (it was using CodeString.escape on the strings that contained the being-built PIR)
21:38 pmichaud running 'make test'
21:42 Coke pmichaud: are you writing the PIR-based escape?
21:42 pmichaud Coke: already written, yes.
21:43 Coke ... wow, by the time I get home, this will all be done. excellent. =-)
21:43 pmichaud Coke: yes, should be pretty close to done.
21:43 cotto_work joined #parrot
21:43 Coke pmichaud: especially since there is a detour for poker. =-)
21:48 dalek parrot: r46541 | bacek++ | trunk (2 files):
21:48 dalek parrot: Bring new StringBuilder from codestring branch.
21:48 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46541/
21:48 kj joined #parrot
21:49 davidfetter joined #parrot
21:51 bacek pmichaud, (side question) Is there any docs on how to upgrade from PGE's "oplib" to NQP-RX?
21:51 pmichaud I don't understand "PGE's 'oplib'"
21:52 pmichaud do you mean "'oplib' written in PGE"?
21:52 bacek sorry, "optable"
21:53 pmichaud they're quite different
21:53 pmichaud in fact, changing the optable was part of the reason why nqp-rx had to be a rewrite
21:53 pmichaud but the best example of how to do optables in nqp is nqp's grammar
21:53 bacek Ok.
21:53 pmichaud src/NQP/Grammar.pir
21:54 pmichaud the INIT block (line 422) sets up the precedence levels, the token statements below that define the operator tokens
21:54 pmichaud for example
21:55 pmichaud NQP::Grammar.O(':prec<t=>, :assoc<left>',  '%additive');
21:55 bacek I just don't grok how 'infix:..' and other proto regexes works.
21:55 pmichaud oh
21:55 bacek They are not mentioned in NQP grammar
21:55 pmichaud right
21:55 pmichaud they're inherited from HLL::Grammar
21:55 pmichaud as part of the <EXPR> subrule
21:55 bacek ah. makes sense
21:55 snarkyboojum joined #parrot
21:56 pmichaud basically, HLL::Grammar already takes care of understanding infix:, prefix:, postfix:, circumfix:, etc.
21:56 pmichaud what your derived grammar needs to do is to define precedence levels and tokens
21:56 pmichaud (which is what NQP grammar does)
21:56 bacek Hooray!
21:57 bacek Looks like I can try to migrate squaak to nqp-rx.
21:57 bacek pmichaud++
21:57 pmichaud definitely worthwhile
21:57 pmichaud I'll be happy to help
21:58 darbelo Aha! Found it.
21:58 bacek thanks. I probably will have some questions later today. Time to prepare for $dayjob.
21:59 bacek pmichaud, proto 'term:'          is tighter('prefix:-')  is parsed(&term)      { ... }
21:59 bacek (from squaak grammar)
21:59 bacek Any guidelines how it's expressed in nqp-rx?
21:59 pmichaud bacek:  that's now just
22:00 pmichaud ... a term protoregex
22:00 pmichaud see the tokens marked with   term:
22:00 bacek so I can just remove it?
22:00 pmichaud starting line 220
22:00 pmichaud right
22:00 pmichaud HLL::Grammar defines the term protoregex for you
22:01 pmichaud (just like infix:, prefix:, etc.)
22:01 bacek ok.
22:01 pmichaud it
22:01 pmichaud it's worth looking at HLL/Grammar.pm to see what is already predefined for you :-)
22:02 darbelo Damm are this bootstraps lengthy.
22:02 pmichaud you can of course overload them in your own grammar, but it's nice to inherit the defaults to start with
22:02 * pmichaud really wishes he was using git for Parrot instead of svn.
22:03 darbelo pmichaud: Now only a matter of time ;)
22:04 pmichaud having an equivalent of http://trac.parrot.org/parrot/wiki/GitCookbook-Pm but using Parrot's svn repository would be very helpful.
22:05 darbelo Coke and dukeleto got volunteered for that effort ;)
22:05 pmichaud well, I meant before parrot converts to git
22:05 pmichaud i.e., if I wanted to use git-svn on the existing parrot svn repo
22:06 cotto_work August 18 +/- (right after 2.7 and GSoC) looks promising
22:06 Tene pmichaud: something kind of like this: http://trac.parrot.org/par​rot/wiki/git-svn-tutorial ?
22:07 Tene Looks like there's some repetition there, could probably use some organization.
22:07 pmichaud Tene: something like that.  How do I make my local repo track the parrot svn repo directly, instead of going through leto's (which might be out-of-sync?)
22:07 pmichaud or am I guaranteed it'll be in sync?
22:07 bacek pmichaud, without branching it's quite easy. git svn clone -s -r 46541 https://svn.parrot.org/parrot (once only); git pull == git svn rebase; git push == git svn dcommit
22:08 pmichaud ...and the clone step takes a long time, iirc :)
22:08 bacek -r 46541 is latest commit in trunk
22:08 bacek (Yes, you will not have history...)
22:09 pmichaud ah, I get it.
22:09 pmichaud okay, makes more sense.  I may try that shortly.
22:09 bacek Or choose some different recentish commit
22:10 Tene pmichaud: you will only be able to see branches that have happened since the revision you started from.
22:10 pmichaud I'm not too worried about following branches
22:10 pmichaud I typically follow branches in separate svn checkouts anyway
22:10 Tene pmichaud: I have a git svn checkout from the very beginning.  I could tar it up and send it to you, if you'd like.
22:11 Tene Ah, OK.  You can use git-svn like that as well.
22:11 pmichaud using https://svn.parrot.org/parrot grabs all of the tags and branches?
22:11 bubaflub joined #parrot
22:11 Tene Yes.
22:11 Tene the -s is for --std-layout
22:11 pmichaud can I grab just the trunk?
22:11 pmichaud or does "something magic" happen
22:11 pmichaud with -s ?
22:12 bacek -s == std layout
22:12 Tene --std-layout is short for -T trunk -b branches/ I think
22:12 Tene something like that
22:12 bacek git-svn reconstruct branches from commits.
22:12 Tene Yes, you can grab just trunk, you just pass different args
22:12 bacek (or something similar)
22:12 cotto_work darbelo++
22:13 Tene I'm a bit too busy at work right now to look it up.
22:13 pmichaud I'll give it a try real quick
22:13 darbelo I'm wholly in favor of opsc , but if this is going to happen often I'll need a faster box.
22:13 darbelo Those bootstraps are loooong.
22:14 * davidfetter knots the bootstraps
22:14 cotto_work Fortunately I don't expect that they'll be frequent.
22:14 bacek darbelo, about 40-60 seconds on my box.
22:14 cotto_work Commits that modify ops are relatively rare
22:14 bacek darbelo, + time to rebuild parrot
22:14 cotto_work and the generated C code is checked in
22:14 darbelo It's the rebuild parrot part that took too long.
22:15 darbelo And it failed near the end too until I caught that stray 'make'
22:15 cotto_work Does the ops2c perl code need a deprecation?  I'd like to get around that and rip it all out if possible.
22:16 bacek You can hijack ops2c.pl to invoke opsc
22:16 pmichaud Rakudo uses ops2c.pl
22:16 pmichaud as does anything that creates dynops, I suspect.
22:17 cotto_work yup
22:17 cotto_work but that's just Rakudo and the old partcl afaict.
22:17 darbelo (hijack ops2c.pl)++
22:17 pmichaud sounds to me like it'll need a deprecation, unless you're certain that the new one will be exactly right
22:17 cotto_work we can test that.
22:17 pmichaud yes.
22:17 cotto_work It seems to work for Rakudo
22:18 bacek we _must_ test that :)
22:18 pmichaud then it's good enough for me!  :)
22:18 darbelo I think we've deprecated all of the bits that were different ;)
22:18 cotto_work if partcl builds without asploding I can test that too (though I'd be very surprised if it broke anything further)
22:18 pmichaud I'd think it'd be easier to simply create a new wrapper and deprecate the old one
22:19 darbelo IIRC partcl builds ok. And then it segfaults.
22:19 cotto_work This is me not being surprised.
22:21 dalek parrot: r46542 | darbelo++ | branches/ops_pct/config/gen/makefiles/root.in:
22:21 dalek parrot: [Makefile] Update root.in to reflect the fact that $(MAKE) can be something other than 'make'.
22:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46542/
22:21 dalek parrot: r46543 | darbelo++ | branches/ops_pct (2 files):
22:21 dalek parrot: [opsc] Remove a redundant include from compilers/opsc/src/Ops/Trans/C.pm
22:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46543/
22:29 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33804), fulltest) at r46541 - Ubuntu 10.04 amd64 (g++)
22:35 * pmichaud tries 'git svn dcommit'
22:36 pmichaud Ahem.  "Yay."   bacek++ Tene++
22:38 dalek parrot: r46544 | pmichaud++ | trunk/compilers/pct/src/PAST/Compiler.pir:
22:38 dalek parrot: [pct]:  Move .escape to PAST::Compiler, part 1.
22:38 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46544/
22:38 dalek parrot: r46545 | pmichaud++ | trunk/compilers/pct/src/POST/Compiler.pir:
22:38 dalek parrot: [pct]:  Switch POST::Compiler to use PAST::Compiler.escape instead of CodeString
22:38 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46545/
22:41 GeJ Make test PASS at r46545 on FreeBSD 8 amd64
22:45 bacek pmichaud, r46546 (use StringBuilder in POST::Compiler)
22:45 GeJ lost about on the wallclock seconds count during `make test` (123s to 114s) between r46541 and r46545 if that's any useful information.
22:46 bacek GeJ, try r46546 :)
22:47 pmichaud bacek++
22:47 pmichaud I'm working on .key now
22:47 pmichaud but I'm being called to dinner, so bbiab
22:51 GeJ bacek: 116s, `make test` PASS
22:51 sorear What is Setting NQP?
22:52 cotto_work It's nice to have our friendly local pmichaud back in action.
22:54 dalek parrot: r46546 | bacek++ | trunk/compilers/pct/src/POST/Compiler.pir:
22:55 dalek parrot: Use StringBuilder instead of CodeString in POST::Compiler
22:55 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46546/
22:55 dalek parrot: r46547 | pmichaud++ | trunk/compilers/pct/src/POST/Node.pir:
22:55 dalek parrot: [pct]:  Deprecate PCT::Node.escape, switch it to avoid CodeString.escape.
22:55 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46547/
22:55 sorear bacek: So all the stringbuildery goodness is in trunk now and I can forget about codestring?
22:57 bacek sorear, pretty much
22:57 sorear bacek++
22:57 Psyche^ joined #parrot
22:58 kid51 joined #parrot
22:58 bacek sorear, (Settings) It's a slim runtime library for nqp-rx. (fsvo "runtime")
22:59 darbelo bacek: Do I kill the branch or is there going to be a salvage operation?
22:59 sorear bacek: where does it live?
22:59 bacek darbelo, not yet. Check with Coke, he has something more.
22:59 bacek sorear, github.com/bacek/nqp-rx
23:00 theory joined #parrot
23:00 sorear git log master...bacek/master only shows a bunch of merge commits and one commit that's related to immutability
23:00 sorear is it lying to me?
23:01 bacek sorear, it is.
23:01 bacek just browse sources
23:01 bacek it's all in src/settings/
23:02 bacek http://github.com/bacek/nqp-rx/commit/d​82d6cbcaf3d6f6c4473140082797dc2e7f0228b
23:02 sorear These methods extend the native NQP Array class to support more of the basic functionality expected for Perl 6 Hashes.
23:03 bacek yes
23:03 bacek All of it is just small sugar for parrot's PMCs
23:04 sorear is it a lexical setting?
23:04 pmichaud bacek: how are the settings to be loaded?
23:05 pmichaud sorear: I suspect it's more like a library than a setting
23:05 pmichaud NQP doesn't have a "native NQP array class" :-)
23:05 sorear reading this is reminding me of a few of the little changes I wanted to make to NQP
23:05 bacek pmichaud, pir::load_bytecode('nqp-settings.pbc' );
23:06 pmichaud bacek: and the .pbc would be in a runtime directory somewhere?
23:06 bacek pmichaud, yes.
23:07 bacek I didn't work on install part (yet). afair cotto did something about installing it.
23:08 eternaleye joined #parrot
23:08 cotto_work I didn't do anything.  I just manually copied nqp-settings.pbc into the runtime dir to see if that was what was preventing an installed ops2c fakecutable from working.
23:09 cotto_work (punchline: no)
23:09 cotto_work not the only thing, at least
23:09 bluescreen joined #parrot
23:10 cotto_work It'd be pretty simple to make it installed though.
23:10 pmichaud yes, just compile the settings to .pir, stick that in ext/nqp-rx/stage0
23:10 pmichaud that seems easiest
23:10 cotto_work that'd work too
23:10 pmichaud well, it's consistent with the rest of the nqp-rx install sequence
23:11 pmichaud in theory one could just copy the settings files directly as well, and then let parrot compile them using the newly-built parrot-nqp
23:11 cotto_work I don't care either way as long as something works.
23:11 dalek parrot: r46548 | darbelo++ | branches/ops_pct (2 files):
23:11 dalek parrot: [Makefile] Move opsc cleanups out of their own target and into the general 'clean' one.
23:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46548/
23:11 dalek parrot: r46549 | darbelo++ | branches/ops_pct/compilers/opsc/Defines.mak:
23:11 dalek parrot: [Makefile] Remove empty lines from definitions.
23:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46549/
23:11 dalek parrot: r46550 | darbelo++ | branches/ops_pct/compilers/opsc/Rules.mak:
23:11 dalek parrot: [Makefile] Remove '$<' from non-suffix rules to help dumb(er) makes cope.
23:11 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46550/
23:12 cotto_work darbelo++
23:13 bacek afk # $dayjob
23:13 pmichaud how does bacek++'s settings compare with kakapo (or however it's spelled)
23:13 pmichaud ?
23:13 bacek it's much-much simpler
23:13 cotto_work a couple of orders of magnitude smaller
23:13 * kid51 is now getting codestring branch to build successfully on darwin/ppc
23:14 pmichaud and with japhb's version of utils?  similar deal?
23:14 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33805), fulltest) at r46547 - Ubuntu 10.04 amd64 (gcc with --optimize)
23:14 cotto_work idk about that one
23:15 cotto_work where does it live?
23:15 pmichaud not sure at the moment -- it was being done with the module installer work iirc
23:15 pmichaud I'm forgetting the names and stuff
23:15 cotto_work It might be a good idea to see how nqp's setting plays with kakapo
23:16 cotto_work though if it's loaded as a pbc it won't matter
23:16 pmichaud it wouldn't surprise me if there are method-name conflicts, though.
23:16 pmichaud or slight semantic differences among common methods.
23:16 cotto_work yes
23:16 cotto_work seen austin
23:16 purl austin was last seen on #parrot 8 days, 17 hours, 16 minutes and 59 seconds ago, saying: http://gitorious.net/kakapo/kak​apo/blobs/master/src/Syntax.nqp  [May  4 05:59:49 2010]
23:17 pmichaud my initial inclination is that I like bacek++'s version and the way it's organized
23:17 pmichaud there are a few changes to be made here and there, but overall it'd be a good start
23:18 pmichaud for one, I'd be a bit careful of calling things e.g.  "NQP arrays".  NQP has no such thing :-)
23:18 pmichaud what this setting is actually doing is augmenting Parrot's base PMC classes with additional methods :)
23:20 pmichaud the methods are written in nqp, yes.
23:21 pmichaud but they're not nqp-specific
23:25 kid51 codestring branch now PASS make test on darwin/ppc:  http://smolder.plusthree.com/ap​p/projects/report_details/33806
23:25 pmichaud new topic:  I wonder if it would be worthwhile to have things like exists_i_p_i and exists_i_p_s
23:25 pmichaud in addition to the current  exists_i_p_ki
23:26 pmichaud i.e., so that I could do     "exists $I0, $P0, $I1"   instead of    "exists $I0, $P0[$I1]"
23:27 pmichaud generating the keyed versions of the opcodes is a bit of a royal pain for pct
23:27 pmichaud because they don't fall into the typical   arg, arg, arg  syntax
23:27 sorear really, this is an argument for removing imcc from the pipeline
23:28 sorear pir is a decent language for human-written bootstrap code
23:28 pmichaud that also, but that's a bigger project than I'm likely to get to anytime soon
23:28 sorear POST::Compiler should be changed to generate pbc directly
23:28 sorear ok
23:28 sorear (where directly probably means Packfile*)
23:28 pmichaud POST::Compiler is designed to make it possible to choose pbc as an alternate output medium
23:29 pmichaud (indeed, so is POST itself)
23:30 pmichaud that'd be a nice gsoc project, if it could fit in a single summer
23:34 darbelo cotto_work: ping
23:34 cotto darbelo, ping
23:34 cotto er, pong
23:35 darbelo cotto: Are the opsc test ready to be incorporated into the test harness?
23:35 cotto I haven't given that much thought.
23:36 darbelo Also, shouldn't they live in t/compilers/opsc/ instead of compilers/opsc/t ?
23:36 cotto they should be ready
23:36 cotto they'll only need to have the load_bytecode ops updated
23:37 darbelo Okay, I'm putting them into the harness as they are, they can be moved later if it's needed.
23:37 cotto let's see what happens
23:38 darbelo Running make test now :)
23:38 bacek_at_work pmichaud, I stole quite few bits from japhb's utils.
23:39 japhb *rez*
23:39 japhb Oh, just referenced in passing, I see
23:39 cotto . o 0 (my evil plan to get darbelo to work on ops_pct is coming to fruition)
23:40 darbelo I'm jumpng into as many distractions as I can now so that tere won't be any left when the GSoC coding period begins.
23:40 darbelo git diff
23:40 purl i heard git diff was 1700 lines
23:51 sorear What if POST::Compiler generated PASM?
23:51 sorear purl, forget git diff
23:51 purl sorear: I forgot git diff
23:51 pmichaud pasm isn't sufficient to represent everything needed
23:51 pmichaud there's not a way to put flags on subs, iirc
23:52 pmichaud (put another way, there are things in PIR that can't be represented in PASM)
23:52 bubaflub pmichaud: i didn't know that
23:52 darbelo PASM should be round-trip able to pbc, but isn't.
23:54 darbelo PASM needs more love.  But it lives inside IMCC, and you already know what we all think of *that* one .
23:54 cotto Why do we still have PASM around?
23:54 darbelo Removing it would need IMCC hacking?
23:55 pmichaud "It lives inside IMCC, and ... "
23:55 sorear PASM, if it worked, would be a much better POST::Compiler target?
23:55 pmichaud it'd be much better to go directly to pbc, I think
23:55 darbelo Also, having a low-level textual representation of bytecode can be very useful.
23:55 pmichaud avoid string generation/parsing altogether
23:56 pmichaud POST nodes are essentially  "opcode, argument, argument, argument"
23:56 pmichaud and even in the places where the arguments are strings, we could make POST much smarter about that (if we only knew what we need to store instead)
23:57 * PerlJam makes the obligatory mention of lorito
23:58 * pmichaud looks for unicode daggers to throw at PerlJam
23:58 * darbelo tries to make unicorns relevant to the discussion.
23:59 pmichaud darbelo ftw
23:59 pmichaud .oO( for my future reference,  U+2020 )

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

Parrot | source cross referenced