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

Powered by Cro and the Raku® Programming Language.

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

Thank you!