Parrot 1.8.0 Zygodactyly released | Priority: define 2010 Roadmap | Priority: trac.parrot.org/parrot/wiki/ClassV...eOverrides | Latest modified TT's: icanhaz.com/parrotbugs | Parrot Languages: icanhaz.com/parrotlang
Set by moderator on 8 December 2009.
chromatic Always use bufstart. 00:00
cotto_work for now, getting it out of code not in src/string would be great
chromatic Fix substr to copy, not COW.
cotto_work are there any other priorities?
It's better to list more than we can do than to have bored hackers. 00:01
Whiteknight japhb: I suspect you would be using some sort of inference engine or topological sort
00:02 darbelo joined
chromatic I'm going to work on compile-time constant exception handlers attached to Subs. 00:02
Coke chromatic: is it safe to consider COW purely an implementation detail?
chromatic Yes.
japhb Whiteknight, it's beginning to look like the current standard is conversion to SAT (Boolean Satisfiability), and running the analysis there.
Coke hokay. that'll do it, then.
Coke wonders if there was any benchmarking done before strings were made COW, or if they appear that way, full formed. 00:03
chromatic I undid COW and did some benchmarking. Deep hurting.
Coke wasn't paying attention to the C back then.
Whiteknight chromatic: that seems like a special case of a much-needed improvement in constants handling
Coke chromatic: ... but if we remove it now, won't it hurt again?
Whiteknight exception handlers aren't the only type that stand to gain
chromatic We only have to remove it for the substr case. 00:04
As far as I know, I fixed a lot of constants.
EHs that are in scope for the entire sub are definitely fixable. 00:05
That applies to a lot of P6-style control exceptions.
We can avoid the cost of creating the exceptions, setting its handled types, and pushing it into the context.
s/exceptions/exception handler/ 00:06
Whiteknight japhb: I've wanted to write a robust rule engine for Parrot since I joined the project
a nice Rete implementation would be nice
00:07 tetragon joined
Whiteknight (and would be a nice building block for adding a prolog compiler, eventually) 00:07
00:07 ascent_ joined
japhb Whiteknight, well ... one of us is probably going to have to do it in the not too distant future 00:07
Plumage needs it. 00:08
I can keep hacking edge cases away, but fperrad++ will keep finding new edges. Or I can just do it right.
00:20 slash left
dalek tracwiki: v12 | cotto++ | AllHackathons 00:25
tracwiki: document what's planned for the hackathon tomorrow
tracwiki: trac.parrot.org/parrot/wiki/AllHack...ction=diff
00:37 Zak joined 00:40 patspam joined
Whiteknight when did the tomorrow hackathon plan get made? 00:40
chromatic You were on diaper duty.
Tene Whiteknight: it's been discussed a few times earlier this week
just casually in IRC
Whiteknight chromatic: I'm always on diaper duty! 00:41
chromatic TMI 00:42
pmichaud Coke: (commit less) No, restructuring won't reduce my commit rate. 00:45
remove cow for substr case.... that will hurt PGE and regexes bigtime
cotto_work Whiteknight, it's on the wiki 00:46
trac.parrot.org/parrot/wiki/AllHackathons 00:47
nm. saw "where"
japhb pmichaud, aren't you dependent on substr to save regex performance for variable-length encodings? 00:50
pmichaud in nqp-rx, we use that as an optimization, yes.
japhb s/you/PGE & NQP-rx/
pmichaud pge doesn't have that optimization
japhb right, that's what I was thinking
pmichaud but we also have to do substr for any sort of literal string match 00:51
as well as case-insensitive matches
chromatic That'll take some clever thinking then. 00:53
pmichaud why the push to eliminate cow for strings? 00:54
chromatic It's a push to slim parrot_string_t by at least two pointers.
pmichaud and that's an advantage because...? 00:55
chromatic You run the GC a lot less.
We're not talking about removing all COW.
It's the specific case where s->bufstart and s->strstart differ due to substr COW that gets hurt if we merge bufstart and strstart. 00:56
Other COW is unaffected.
pmichaud a lot of pge and regex stuff was designed around the knowledge that substr tended to be cow
i.e., that taking a substr of something wasn't going to make a lot of buffer duplicates 00:58
chromatic And it shouldn't.
00:58 he joined
Whiteknight why are we merging buf_start and string_start again? 00:58
chromatic There's probably a way to reduce the size of parrot_string_t while allowing substr COW.
Whiteknight because both have real uses
pmichaud oh, would substr still use the same buffer?
oh, in that case I'm much less concerned.
chromatic It can.
pmichaud -however- 00:59
if this is a quick fix, I say go for it (more)
if it ends up being at all involved, perhaps we should wait for a strings overhaul
we still don't have good unicode support on systems w/o icu
chromatic We're at the point of improving encapsulation right now, so there won't be any removal in the short term.
If we had to, we could make a parrot_substr_string_t with space for the additional pointer. 01:04
01:04 kid51 joined
kid51 posts a question he first posted 12 hours ago ... 01:06
Does anyone know the final plans for the online Roadmap meeting this weekend? 01:07
If so, we should post on list and change the channel topic.
chromatic 19:30 UTC, I believe. 01:08
01:09 mtk joined
kid51 That's on Sunday Dec 13, correct? 01:09
chromatic Correct.
moderator Parrot 1.8.0 Zygodactyly released | Online Parrot Roadmap Meeting: Sunday 13 December, 19:30 UCT 01:12
dalek tracwiki: v131 | jkeenan++ | WikiStart 01:14
tracwiki: trac.parrot.org/parrot/wiki/WikiSta...ction=diff
kid51 time 01:15
clock
purl, clock?
purl kid51: LAX: Fri 5:15pm PST / CHI: Fri 7:15pm CST / NYC: Fri 8:15pm EST / LON: Sat 1:15am GMT / BER: Sat 2:15am CET / IND: Sat 6:45am IST / TOK: Sat 10:15am JST / SYD: Sat 12:15pm EST /
01:21 mtk left
Coke pmichaud: can one do inline regexn in nqp-rx yet? 01:29
pmichaud I think nqp-rx repo has that capability, I'm not sure if it's been imported into parrot trunk yet 01:30
it undoubtedly will be before the evening is out, unless I get tired
cotto_work chromatic, ping 01:41
01:41 ascent joined
chromatic pong 01:41
01:42 DrForr joined
cotto_work chromatic, I'm looking at the callgrind profile when using annotations and PackFile_Annotations_lookup is eating 33% of the time. Is there a way to look up annotations iteratively to lower that overhead? 01:42
(i.e. would PackFiles be amenable to such an approach)
(that's with no output) 01:43
dalek tracwiki: v132 | jkeenan++ | WikiStart 01:47
tracwiki: trac.parrot.org/parrot/wiki/WikiSta...ction=diff
Whiteknight I figured annotations must be expensive, but 33%? 01:50
cotto_work That's just for looking them up.
(and without any output, which takes up about 29% when it's active. 01:51
I'm checking what it'd be with output, but it'll probably be done long after my weekend has started. 01:52
Interestingly, using the iterator interface is pretty cheap. I'll probably switch to messing more directly with the hash, but it's not nearly as expensive as I'd have expected. 01:55
particle what's robert kuo's handle? 02:01
cotto_work bubaflub
purl bubaflub is mailto:bobjkuo@gmail.com
cotto_work is his cla in?
particle yep, today 02:02
cotto_work that'll make him happy
particle i plan to be online for the sunday meeting, text me if i'm not around 02:03
dalek tracwiki: v13 | jkeenan++ | AllHackathons 02:04
tracwiki: Move last month's hackathon to newly renamed Previous Hackathons section
tracwiki: trac.parrot.org/parrot/wiki/AllHack...ction=diff
chromatic Nice list of ->strstart, kid51! 02:06
kid51 Thanks. Any other prep work you can think of? 02:07
grep is my friend :-)
chromatic Might be good to paste them somewhere on the wiki we can check them off, but I don't remember the right page name for that. 02:08
pmichaud just a note that (as posted on parrot-dev) I probably won't make it to the meeting until 20:30 utc 02:09
kid51 How do I start a new page on this wiki? 02:12
chromatic cotto_work, we need to change the way we store annotations to make that faster. 02:13
dalek rrot: r43008 | pmichaud++ | trunk/compilers/pct/src/PAST/Compiler.pir:
[past]: A few more opcode signatures.
kid51 I want to start a new wiki page called: PreDecemberReleaseHackathon 02:14
But simply entering that on trac.parrot.org/parrot/wiki/AllHackathons isn't cutting it.
chromatic Change the URL in place. 02:17
purl chromatic: that doesn't look right
cotto chromatic, do you think this would be helpful enough to other parts of parrot to be worthwhile? It sounds like there'd be a lot of effort involved? 02:21
dalek tracwiki: v14 | jkeenan++ | AllHackathons
tracwiki: trac.parrot.org/parrot/wiki/AllHack...ction=diff
tracwiki: v15 | jkeenan++ | AllHackathons
tracwiki: trac.parrot.org/parrot/wiki/AllHack...ction=diff
cotto gets to upgrade his interwebs to be half as slow 02:22
chromatic It shouldn't be too difficult. We have to change how we store annotations (one place), how we access them within libparrot (one place), and possibly ancillary utilities such as the PBC disassembler and pbc-merge.
cotto That'd be great. How much effort do you think it'd take me to go from zero to understanding Packfiles enough to make the changes? 02:23
it's a bit of yak shaving, but I'm surprised I haven't had to do more of that. 02:24
chromatic It shouldn't be too difficult. 02:25
The only tricky part is choosing the right data structure.
I think we need to switch to an array-based heap store, where we store the annotation by the pointer value in the PBC.
cotto goes offline briefly 02:28
02:32 cotto joined
dalek tracwiki: v1 | jkeenan++ | PreDecemberReleaseHackathon 02:38
tracwiki: Resources for Dec 12 2009 Development Hackathon
tracwiki: trac.parrot.org/parrot/wiki/PreDece...ction=diff
kid51 context_unify3 branch current test failures: See smolder.plusthree.com/app/public_pr...ails/30822 02:41
dalek tracwiki: v133 | jkeenan++ | WikiStart 02:54
tracwiki: trac.parrot.org/parrot/wiki/WikiSta...ction=diff
tracwiki: v2 | jkeenan++ | PreDecemberReleaseHackathon
tracwiki: Add Smolder report on context_unify3 branch at r43007</a>
tracwiki: trac.parrot.org/parrot/wiki/PreDece...ction=diff
tracwiki: v3 | jkeenan++ | PreDecemberReleaseHackathon
tracwiki: trac.parrot.org/parrot/wiki/PreDece...ction=diff
moderator Parrot 1.8.0 Zygodactyly released | December 12 Development Hackathon: tinyurl.com/ybrsgmp | Online Parrot Roadmap Meeting: Sunday 13 December, 19:30 UCT 03:01
colomon joined 03:08 allison joined 03:20 TiMBuS joined
dalek tracwiki: v4 | jkeenan++ | PreDecemberReleaseHackathon 03:28
tracwiki: trac.parrot.org/parrot/wiki/PreDece...ction=diff
rrot: r43009 | jkeenan++ | trunk/src/utils.c:
Replace one instance of '->strstart'. Attempts to replace the other three
 03:35
kid51 1 down, 72 to go! 03:36
dalek tracwiki: v5 | jkeenan++ | PreDecemberReleaseHackathon 03:44
tracwiki: trac.parrot.org/parrot/wiki/PreDece...ction=diff
Coke pmichaud: whee. just moved some more PIR into NQP. 03:48
annoyingly, it was some PIR that I had reverse engineering from NQP previously. =-)
dalek rtcl-nqp: ce11002 | coke++ | (4 files):
move TclString's get_integer definition into NQP from PIR.

  - the :vtable is still in PIR, but it just dispatches to NQP.		 03:49
rrot: r43010 | jkeenan++ | trunk/src/oo.c:
Replace three instances of '->strstart'. Cf.:
 03:52
TT #1370 created by jkeenan++: ->strstart cleanup 03:57
tracwiki: v6 | jkeenan++ | PreDecemberReleaseHackathon 04:01
tracwiki: trac.parrot.org/parrot/wiki/PreDece...ction=diff
04:12 plobsing joined 04:44 darbelo_ joined
Coke bah. I can't seem to move get_bool to getBoolean in tcl string. 04:54
dalek tracwiki: v7 | darbelo++ | PreDecemberReleaseHackathon 05:07
tracwiki: Remove items that we can't be "cleaned up" yet, like GC bookeeping and assertions.
tracwiki: trac.parrot.org/parrot/wiki/PreDece...ction=diff
Coke AIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIGH 05:15
cotto someone needs a hug 05:16
Coke bit again by == working differently in NQP than it does in tcl. 05:19
now I'm trying to figure out why try {} in NQP isn't catching an error. 05:20
Coke adds an empty CONTROL block to resolve the issue. 05:21
ugh. can't return from inside a try with a CONTROL {} block. whee. 05:52
dalek rtcl-nqp: aaf6aba | coke++ | src/ (2 files):
move guts of TclString's get_bool vtable into an NQP method.
 05:54
06:14 cotto joined
dalek rrot: r43011 | cotto++ | trunk/src/utils.c:
[string] one more strstart removal that doesn't break anything. The other two
 06:52
darbelo_ Hm. Speaking of that. Has anyone built a parrot with GC_VERBOSE turned on? It fails in spectacular ways for me. 07:14
s/that/deeper fixes/
cotto My need for deeper fixes has been overruled by my need for sleep. night. 07:18
darbelo_ Night. I should probably sleep too, now that you mention it.
dalek rrot: r43012 | pmichaud++ | trunk (2 files):
[pdd]: Add a proposed new draft for pdd31 -- HLL compiler and library interop
 07:25
rrot: r43013 | pmichaud++ | trunk/docs/pdds/draft/pdd31_hll.pod:
[pdd31]: Improve the text of 'import' a bit.
07:48 chromatic joined 07:58 fperrad joined 08:02 fperrad_ joined 08:06 jsut_ joined 08:29 iblechbot joined 08:55 plobsing joined 09:09 mikehh joined 10:00 jan joined
chromatic Hm, why should Buffer_bufstart() be void *? 10:05
dalek rrot: r43014 | mikehh++ | trunk/src/utils.c:
fix src/utils.c to build with g++ - Buffer_bufstart is of type void *
 10:08
10:24 bacek joined
darbelo chromatic: It's a 'generic pointer' to an amourphous blob of data? 10:26
That and the (whatever *) -> (void *) -> (whatever *) roundtrip gurantee. 10:27
10:50 pjcj joined
dalek rkdown: 43df65a | fperrad++ | markdown/grammar.pg:
now parrot-nqp supports '\\'', so remove \\x27
 10:57
fperrad msg pmichaud when I trying to convert the Markdown grammar to NQP-rx, 11:33
I found that an empty string crashes NQP-rx.
purl Message for pmichaud stored.
fperrad See github.com/fperrad/markdown/blob/ma...rammar.pg, lines 408, 455 & 589.
msg pmichaud when I trying to convert the Markdown grammar to NQP-rx, I found that an empty string crashes NQP-rx. See github.com/fperrad/markdown/blob/ma...rammar.pg, lines 408, 455 & 589. 11:34
purl Message for pmichaud stored.
darbelo Hmm. s->strstart != Buffer_bufstart(s) indeed. If I change Parrot_str_to_cstring to return s->_bufstart everything breaks. 12:02
That's going to need some work to get fixed. But pmc_freeze is uglier, so it goes first. 12:04
12:07 lucian joined
nopaste "mikehh" at 81.149.189.7 pasted "code required to TODO failing tests in t/op/exceptions.t" (32 lines) at nopaste.snit.ch/19055 12:18
darbelo All tests successful. But editing pmc_freeze.c make me paranoid so testing of r43015 is appreciated. 12:23
Also, does anyone know if a PMC frozen in one machine should be able to be thawed on a machione of a different arch. 12:26
?
dalek tracwiki: v8 | darbelo++ | PreDecemberReleaseHackathon 12:34
tracwiki: trac.parrot.org/parrot/wiki/PreDece...ction=diff
rrot: r43015 | darbelo++ | trunk/src/pmc_freeze.c:
Rewrite push_opcode_* to Use the string API. Perform weird PackFile contortions to maintain the stream format. This code will become less ugly after the next deprecation boundary.
 12:35
mikehh darbelo: had to add a couple of casts for g++ but after that it passes all tests inc fulltest 12:46
darbelo Agh. I keep forgetting about the c++ build. 12:47
mikehh++ # fixing the stuff I break.
12:52 Whiteknight joined
darbelo Whiteknight: ping 12:52
Whiteknight pong! 12:53
darbelo Do you know anything about building parrot with GC_VERBOSE turned on?
It causes all sorts of 'splosions for me. 12:54
13:06 riffraff joined
dalek rrot: r43016 | mikehh++ | trunk/src/pmc_freeze.c:
fix src/pmc_freeze. for g++ build
 13:08
13:13 payload joined
Whiteknight darbelo: never tried it 13:16
i'ts very old, probably needs to come out
13:18 colomon__ joined
darbelo I can do that. Old, bitrotten, #ifdefs are my favourite deletion targets. 13:18
dalek rkdown: 9cabe0a | fperrad++ | markdown/Compiler.pir:
refactor (closer to NQP/Compiler.pir)
 13:28
darbelo Damm. the shift_opcode_* functions are tricker than the push_opcode* ones 13:37
13:38 kid51 joined
darbelo Also, if we push() them in, why couldn'te pop() them out? 13:38
13:45 colomon__ joined
dalek tracwiki: v9 | jkeenan++ | PreDecemberReleaseHackathon 13:56
tracwiki: credit mikehh for one revision
tracwiki: trac.parrot.org/parrot/wiki/PreDece...ction=diff
tracwiki: v10 | jkeenan++ | PreDecemberReleaseHackathon
tracwiki: credit cotto for one revision
tracwiki: trac.parrot.org/parrot/wiki/PreDece...ction=diff
tracwiki: v11 | darbelo++ | PreDecemberReleaseHackathon
tracwiki: Tick another strstart use from the list.
tracwiki: trac.parrot.org/parrot/wiki/PreDece...ction=diff
rrot: r43017 | darbelo++ | trunk (6 files):
Remove unused and bitrotted GC_VERBOSE debugging output.
 13:57
13:57 fperrad joined
kid51 darbelo ping 14:03
dalek tracwiki: v12 | jkeenan++ | PreDecemberReleaseHackathon 14:13
tracwiki: trac.parrot.org/parrot/wiki/PreDece...ction=diff
14:15 colomon___ joined
darbelo kid51: pong 14:16
kid51 Are you still looking at src/pmc_freeze.c? 14:18
I tried the Buffer_bufstart replacement in the 2nd of 4 groups, but it didn't work. 14:19
darbelo Not really, got sidetracked wth non-parrot stuff. 14:20
kid51 k
pmichaud ...is it noted somewhere that one cannot simply do a blind replacement of strstart with Buffer_bufstart ?
at least, not until we refactor the substr opcode
kid51 pmichaud: Could you add your thoughts on that to TT #1370? 14:21
pmichaud well, my thoughts on that are basically what I just wrote bove :)
*above
kid51 If that is so, then we should stop where we are.
darbelo src/pmc_freeze.c is probably the hardest part to cleanup, since it plays scary tricks with strstart.
kid51 I'll have to check moritz's log.
pmichaud iiuc, one can replace uses of ->strstart with Buffer_bufstart when it's known that the given string isn't a substring 14:22
I'm not sure one can always know when that's the case. Otherwise we get to issues noted in the thread surrounding r42961. 14:23
darbelo pmichaud: 'external' strings can bring problems too.
pmichaud darbelo: yes, that also
darbelo pmichaud: But that's not the only replacements we're doing. 14:24
look at r43015 for example.
mikehh pmichaud: your docs/pdds/draft/pdd31_hll.pod is failing t/examples/pod.t
pmichaud darbelo: sure, r43015 doesn't fit the pattern I just mentioned, though. 14:25
mikehh pmichaud: all except the last examples fragment - the other PIR_FRAGMENTs appear to be more specifications rather than code
nopaste "kid51" at 70.85.31.226 pasted "src/pmc/eval.pmc: This strstart replacement passes 'make coretest'" (13 lines) at nopaste.snit.ch/19056
pmichaud i.e., it's not a blind replacement of ->strstart with Buffer_bufstart
darbelo I also plan on looking if there's a way we can make substr() work with _bufstart == strstart when I'm done with pmc_freeze.c 14:27
pmichaud just be careful that the solution doesn't end up being "create a new string buffer". That will likely kill PGE and NQP performance (and everything that depends on them)
darbelo pmichaud: Yeah, other than that. The whole point of killing strstart is reducing gc pressure, creatings strings all over the place doesn't hep ther. 14:29
*help there.
kid51 pmichaud: Could you test whether the replacements of strstart we have made in the last 15 hours have had negative effects onn PGE or NQP? 14:30
pmichaud kid51: not easily
darbelo goes afk
kid51 Well, then, is Parrot's 'make test' inadequate for that purpose -- even though it's the only thing we have? 14:31
pmichaud I don't know how many operations are being tested using substring operands as opposed to whole strings.
that's how I ended up with the failure case in r42961 -- the original change was assuming that substrings would never be used as an argument to that function 14:33
it's not common to test every function for use with every possible type of string, at least not yet
anyway, I wouldn't expect most of the changes made thus far to seriously impact PGE or NQP, but since (by necessity and design) they make heavy use of substrings, and they tend to produce a lot of substring results, it's entirely possible that some of the changes would cause things to break that we aren't testing. 14:34
(substrings being the primary case where ->strstart != bufstart ) 14:35
kid51 Do you mind if I quote what you've just said in TT #1370? 14:38
pmichaud not at all
I'm by no means authoritative on this point, though. :) 14:39
mikehh: when does t/examples/pod.t get run? (what make target runs it?) 14:47
oh.... does pod.t run the PIR examples? 14:48
ick
14:50 cconstantine joined
kid51 needs to reboot 14:55
14:57 colomon___ joined
dalek rrot: r43018 | pmichaud++ | trunk/docs/pdds/draft/pdd31_hll.pod:
[pdd31]: Remove PIR_EXAMPLES pod directives from things that aren't examples.
 15:03
mikehh pmichaud: It is part of make fulltest as well as make examples_tests as you no doubt found out 15:10
15:12 JimmyZ joined, JimmyZ left 15:13 JimmyZ joined, kid51 joined 15:14 Jimmy joined
Jimmy good evening, #parrot 15:14
15:24 slash joined 15:41 Psyche^ joined 15:44 patspam joined 16:19 theory joined 16:25 mikehh joined
darbelo WTF? 16:32
pmc_freeze keeps the suprises! I've just removed a big part of the image_io structure and everything works. 16:33
nopaste "kid51" at 70.85.31.226 pasted "Replacement of strstart in src/dynext.c -- passes make coretest and make test." (24 lines) at nopaste.snit.ch/19057 16:34
darbelo WTF is that packfile even there for?
16:34 mikehh_ joined
kid51 darbelo: If you get a chance, could you look at that paste? 16:35
although it's a "blind replacement", it passes make test
so, other things being equal, we would commit it.
darbelo looking now... 16:36
16:37 mikehh joined
darbelo It seems subject to pmichaud's usual objection. If we don't solve the substr() issue we can't do that. 16:37
kid51 Alright, I'll put the patch in the ticket but won't apply it. 16:38
darbelo But, I think we can safely use Parrot_str_to_cstring() there.
mikehh I keep dropping the internet connection - it's driving me crazy - gibber, gibber
kid51 Yeah, I was thinking, "mikehh - why not stick around for 60 seconds?" ;-) 16:39
darbelo Parrot_str_to_cstring() uses ->strstart to build the cstring.
mikehh certainly try :-}
kid51 Hmm, I just realized that in src/dynext.c, the instances are in locations specific to Win32 or Cygwin -- which I can't test. 16:43
darbelo kid51: That's the reason they survived my first "kill strstart" push some time ago ;) 16:45
kid51 Am making note of that on wiki page: trac.parrot.org/parrot/wiki/PreDece...eHackathon 16:46
nopaste "kid51" at 70.85.31.226 pasted "src/io/socket_unix.c: Replacement of strstart passes 'make test'" (13 lines) at nopaste.snit.ch/19058 16:56
kid51 darbelo: There's another one for you to look at.
dalek p-rx: d851756 | pmichaud++ | (4 files):
Add some HLL::Compiler capabilities, tests.
 16:57
p-rx: 73f3c37 | pmichaud++ | (2 files):
Update HLL::Compiler.get_exports, add t/hll/03-exports.t .
p-rx: 5fa7530 | pmichaud++ | (2 files):
Update HLL::Compiler.import, add tests.
p-rx: 227aaf6 | pmichaud++ | build/PARROT_REVISION:
Bump PARROT_REVISION.
p-rx: 31f41ef | pmichaud++ | src/ (12 files):
Update copyright information to The Perl Foundation.
p-rx: 9a9ea3d | pmichaud++ | README:
Update copyright information to The Perl Foundation.
p-rx: 782d140 | pmichaud++ | src/Regex.pir:
Update copyright information to The Perl Foundation.
p-rx: e2dd357 | pmichaud++ | src/stage0/ (4 files):
Update bootstrap.
tracwiki: v13 | jkeenan++ | PreDecemberReleaseHackathon 16:59
tracwiki: trac.parrot.org/parrot/wiki/PreDece...ction=diff
tracwiki: v14 | jkeenan++ | PreDecemberReleaseHackathon
tracwiki: trac.parrot.org/parrot/wiki/PreDece...ction=diff
tracwiki: v15 | jkeenan++ | PreDecemberReleaseHackathon
tracwiki: trac.parrot.org/parrot/wiki/PreDece...ction=diff
kid51 afk 17:03
nopaste "darbelo" at 190.136.175.208 pasted "Wait, why isn't this failing?" (78 lines) at nopaste.snit.ch/19059 17:04
darbelo Both parrot and rakudo report "All tests successful" with nopaste.snit.ch/19059 17:06
Even the decnum-dynpmcs freeze-thaw test pass without a hitch.
17:09 payload joined 17:41 brooksbp joined
brooksbp hello 17:42
purl hola, brooksbp.
brooksbp is parrot based of any well-known virtual machine like SECD or CEK?
allison brooksbp: no, it's a new concept. SECD and CEK were both targeting functional languages 17:59
brooksbp so what is parrot based off?
moritz C :-)
allison brooksbp: the behavior of parrot is inspired by things like the Perl and Python interpreters, but it's not really like any of them
brooksbp So there's no close theoretical machine? 18:00
allison brooksbp: nope, it's a new idea
brooksbp Is there an explanation for how the machine works?
brooksbp is hoping for anything but a pointer to the dev docs
allison brooksbp: no academic papers yet 18:01
brooksbp: what specifically are you interested in? it will help guide us in writing the papers
brooksbp Just a simple description of the parrot vm...
I've been implementing SECD, SECD hybrid that operates on AST, ECD abstract machine, CEK, and looking into tail calls 18:02
allison brooksbp: in terms of what features it implements? or the architectural philosophy?
brooksbp just wondering what 'type' of vm/abstr-machine parrot is... or how it operates
both, any, all
allison it's register-based, continuation-based, dynamic 18:04
garbage-collected, concurrent, supports exceptions, closures, continuations, coroutines
it has a global symbol table like Perl/Python 18:05
it natively runs a bytecode format and a low-level assembly language
brooksbp What are the main advantages over a simple machine like SECD?
allison tools for building dynamic languages, and a runtime that already includes most of the behavior needed for a dynamic language runtime 18:06
so, less development time needed to new dynamic languages up and running 18:07
(because less needs to be developed for a specific language)
18:07 mj41 joined
brooksbp Are there any ways to make the machine faster at the evaluation/transformation 'close to the metal' level? 18:08
allison tools to optimize a language during compilation, or optimizations for the virtual machine itself? 18:09
brooksbp the vm
18:33 chromatic joined
darbelo chromatic: ping 18:41
Whiteknight brooksp: we have optimization work yet to be done. Many of our systems are still young 18:43
chromatic pong 18:44
18:44 mikehh joined
darbelo Do you have any idea why is there a packfile in the imageio struct? 18:45
eh, image_io
the one that dirves freeze/thaw. 18:46
plobsing darbelo: its not really a packfile
chromatic I don't *know* for certain. I've written some of the freeze/thaw code in PMCs, but I can't say that I understand the design or implementation.
darbelo I removed it (nopaste.snit.ch/19059) and nothing failed.
Whiteknight I don't think anybody really understands that system right now 18:48
darbelo It's a quick hack, but from what I see it's only there to put a 'header' at the start of the string.
Whiteknight not entirely
darbelo And it can do that by living in the initialization function instead of a persistant data structure. 18:49
Whiteknight darbelo: where should I be looking if I wanted to learn more, pmc_freeze.c? 18:50
darbelo Whiteknight: unfortunately, yes.
It's slightly less chtulian nowadays, but you should strill tread carefuly. 18:51
Whiteknight where is the entry point? All the functions I see there are static 18:52
oh nevermind, I found the public functions all the way at the bottom of the file 18:53
We really need to come up with a good duplicates detector, like what the freeze code uses (but more general for other places) 18:55
chromatic Isn't there a CPD plugin for C? 18:56
Whiteknight CPD? 18:59
purl CPD is probably Commission on Presidential Debates, www.debates.org/, which controls all Presidential debates or cut-and-paste detector pmd.sourceforge.net/cpd.html or run by the former chairs of the DNC and RNC with explicit purpose to exclude third-party candidates
darbelo Oh, and from the bad news department: the strstart removal blocks on a way to substr() that keeps _bufstart == strstart but doesn't totally suck performance-wise. 19:00
chromatic We need to figure out how to have slim STRINGs while still allowing for cheap substr() without buffer copies. 19:01
Whiteknight a second string header with an IS_SUBSTR flag pointing into the buffer of the first header 19:02
nevermind, you'd need a pointer back to the original header to prevent it from getting GC'd 19:03
darbelo Whiteknight: And a pointer to the first header, so we can mark it.
Whiteknight: exactly. 19:04
Whiteknight exactly, bad idea
darbelo Otherwise you would be able to implement it with the 'external' PObj flag.
Whiteknight parrot_string_representation_t 19:05
chromatic You don't need a pointer to the first header; it uses reference counts for COW.
Whiteknight I'm sure there are very limited numbers of combinations of encoding/charset, we could create objects to store those combinations together
we could also separate out the notion of a "string" and a buffer 19:06
where the buffer is storage, and strings point into it
it's an idea that would be able to save us more in terms of string constants than runtime strings though 19:07
darbelo That would make for smaller structs, but with more bookeeping.
chromatic Unless we have a clever duplicate buffer detector.
Whiteknight a build-time duplicate detector for CONST_STRINGs would be a major win, I think 19:08
at least in terms of memory footprint
but I've kicked that dead horse before
what's the difference between bufused and strlen? 19:09
chromatic Suppose your substr doesn't use the entire buffer. 19:10
I don't think we allow duplicate CONST_STRINGs now.
Whiteknight what if strings could have an attached "->window" object, that would provide a window on the buffer in the case of a substr?
if ->window != null, we have a substring and act accordingly 19:11
so we would have one pointer in place of strstart and strlen
chromatic I'd rather use polymorphism. 19:12
Whiteknight including the parrot_string_representation_t idea, STRING is down in size by 2 pointers, and only a little slower for the incommon cases
how would that work, if "$S0 = substr $S0..." would we create a new header or have to copy over the existing one? 19:13
chromatic That's an easy case; create a new parrot_string_substr_t and set a flag in the header. 19:14
Whether it's desirable to create a new struct for that case... meh.
19:14 mj41 joined
Whiteknight I was looking for literature in support of immutable strings, but most of what I found was against them 19:15
so I stopped looking 19:16
chromatic Really?
Whiteknight I'm reasonably sure I didn't google for "immutable strings are TEH SUXXOR", but those are the kinds of results I seem to remember seeing
probably need to search more
my memory is made of fail 19:17
chromatic Profile almost anything and see how many Parrot_str_new_COW() calls we have for cases where we know we shouldn't modify anything (such as getting the name of a class). 19:18
Whiteknight a case to be made for enforcing certain strings to be considered constant 19:20
create the COW reference only after we try to modify the constant string 19:21
chromatic Oh, did I mention that we have to analyze every STRING passed to subs?
If they're constant, we have to create COWs and pass those instead.
Whiteknight what do you mean by that?
chromatic STRINGs, even stored in registers, always have reference semantics. 19:22
We have no intrinsic string type with value semantics.
Whiteknight so what's the way to do all this right, if we had the opportunity to throw it out and start fresh? 19:24
chromatic Do not allow string modification in place.
19:25 bacek joined
chromatic Always return a new string header for operations which mutate. 19:25
Whiteknight without inplace modification you end up with a tonne of copies
chromatic Behind the scenes, play whatever buffer games you like.
Whiteknight </british for some reason>
chromatic We already have a ton of copies to *avoid* in-place modification.
When you find yourself working around your optimization because it breaks things, it's time to reconsider that optimization. 19:26
Whiteknight immutable strings seems to just be a more consistent COW scheme
chromatic If you need in-place modification, use a String PMC which can hide the fact that the STRING primitive is immutable. 19:27
Whiteknight that's a decent rule of thumb, but it really hides the idea that String should just be a boxed version of STRING
a StringBuilder would be better in my estimation
chromatic PMCs have reference semantics.
Whiteknight but that's nitpickery on my part
darbelo Except that we try to fake value semantics at the PIR level for PMCs 19:29
chromatic For fun, remove lines 614-619 of src/call/args.c.
Watch tests fail.
Debug.
darbelo, that's because we don't have intelligible lvalue semantics for PMCs. 19:30
(also because we can't store primitives in certain places such as lexpads)
19:32 mj41 joined
darbelo (args.c) That's... ugh. 19:32
chromatic See also key_string() and src/pmc/class.pmc +587 19:33
darbelo Ouch. 19:34
Whiteknight I guess I really dont understand the lvalue semantcs problem
chromatic For PMCs?
Whiteknight yeah 19:35
darbelo Whiteknight: It's easy, what happens to a PMC on the left side of a '=' ?
Whiteknight I never looked into it, only saw what was said on list
darbelo If you can't tell, then you don't have clear semantics.
Whiteknight well "=" is a syntax issue. we have set and assign ops 19:36
darbelo And what does each one do? Is the PMC a value or a reference? 19:39
chromatic What if the PMC is an aggregate?
Whiteknight ok, point illustrated. 19:41
again, how do we make it sane?
chromatic The best idea I've heard is to figure out the appropriate vtable entries for the behaviors we want to support. 19:42
bacek Good morning 19:46
Whiteknight hello bacek
bacek aloha Whiteknight
darbelo Is it tomorow morning already? Damm. 19:47
bacek++ # Time travel.
Whiteknight so what lvalue semantics do we even want to support? I can think of two classes: "overwrite storage with new pointer", and "set value" 19:53
the former wouldn't be a vtable at all
chromatic pmichaud will know better.
Whiteknight so many things like this I think would benefit from being written down 19:55
chromatic Lots of failures still in context_unify3... not to the point of debugging yet. 19:56
bacek chromatic, I just added all this failures.
chromatic Oh, I thought we were removing failures today. 19:57
darbelo Well, we can't remove them if nobody add them, right?
dalek rrot: r43019 | bacek++ | branches/context_unify3 (2 files):
Add Parrot_pcc_allocate_empty_context to allocate new context without
purl registers is better www.theregister.co.uk/2005/10/18/wi...y_problem/
rrot: r43020 | bacek++ | branches/context_unify3 (2 files):
Expose init_context function.
rrot: r43021 | bacek++ | branches/context_unify3/src (2 files):
First naive try to avoid creating of many useless CallContext objetcs
kid51 wakes up and reads 3 hours of backscroll
moritz purl: forget registers
purl moritz: I forgot registers
bacek chromatic, no you have a lot of opportunities to remove them!
s/no/now/ 20:00
kid51 Is this instance of replacement of strstart valid? nopaste.snit.ch/19058 20:05
20:05 mikehh joined
pmichaud Whiteknight: (assignment versus bind) trac.parrot.org/parrot/wiki/WhyDoes...icientCode 20:11
chromatic What's next on the branch, bacek? 20:16
bacek chromatic, figure out how to pass args/results...
chromatic Do you have a list of tasks we can help? 20:17
Whiteknight's not doing anything interesting at the moment.
cotto me too
darbelo is doing something frustrating at the moment. 20:18
I welcome any excuses to get away from this goddam file. 20:19
bacek Ok, I'm dcommiting current code from my local branch. 20:20
Main "task" is to understand clearly where we should push new context, how argument passing should work, etc.
Next task - fix tailcall. 20:21
chromatic Let's take the context pushing out of Sub.invoke. 20:25
I can't think of anything that breaks if the new context is already in place when we call invoke. 20:26
bacek chromatic, I tried it. 20:28
"invokecc"
op invokecc.
If Sub.invoke doesn't push context, than invokecc has to push it
chromatic Why not the *param ops?
bacek set_params? 20:29
It's called way too early to push created context.
allison bacek: too early to push it, yes but not too early to create it 20:31
chromatic Where do we store it if it's created but not pushed?
bacek allison, it's actually created in set_args
dalek rrot: r43022 | bacek++ | branches/context_unify3/src/call/args.c:
clone_key_arg can accept NULL
rrot: r43023 | bacek++ | branches/context_unify3/src (2 files):
Move pushing of context into Sub.invoke instead of invoke_from_sigobject
rrot: r43024 | bacek++ | branches/context_unify3/src/ops/core.ops:
Update passing of args/results to use current context
bacek chromatic, ctx->current_sig 20:32
same as in trunk
allison chromatic: same place we store the signature object now
bacek t/op/calling.t (Wstat: 2560 Tests: 97 Failed: 10)
Failed tests: 23, 37-39, 52, 61-62, 91, 96-97
Non-zero exit status: 10
oookey. Much better now
chromatic Oh, I thought we removed that. Easy enough for now. 20:33
bacek Ok, tailcall is broken.
nopaste "kid51" at 70.85.31.226 pasted "What we've committed to trunk since in last 18 hours" (613 lines) at nopaste.snit.ch/19060
bacek Looks like simple args/results passing works
(my family waking up) 20:34
chromatic kid51, I don't think nopaste.snit.ch/19058 is right. 20:36
./src/pmc/sub.pmc:390: warning: ignoring return value of ‘Parrot_pcc_init_context’, declared with attribute warn_unused_result 20:39
bacek chromatic, fixed 20:40
chromatic When building PCT: src/call/context_accessors.c:301: failed assertion 'ctx' 20:42
tailcalls? 20:43
purl tailcalls are borked
bacek tailcalls 20:45
purl tailcalls are borked
dalek rrot: r43025 | bacek++ | branches/context_unify3/src/pmc/sub.pmc:
Initialize context before pushing.
 20:47
rrot: r43026 | bacek++ | branches/context_unify3 (2 files):
Update Parrot_pcc_init_context guards
kid51 chromatic: That warning: Are you getting it in 'make coretest' or 'make test'? 20:51
kid51 is not getting that warning on Linux/i386
Correction: During 'make corevm' or 'make'?
bacek kid51, it's on context_unify3 branch
dalek tracwiki: v16 | jkeenan++ | PreDecemberReleaseHackathon
tracwiki: trac.parrot.org/parrot/wiki/PreDece...ction=diff
bacek fib.pir is passing on r43027 20:52
kid51 Alright, then; chromatic, what problem do you see in paste 19058
chromatic kid51, if the string used in IO is the result of a substr() operation, the logical string will not start at the start of the buffer. 20:53
bacek have to go. I'll try to fix tailcalls if no-one beat me
chromatic Any advice on what to do next, bacek?
Hm, we can get rid of ->buflen. 20:55
Probably ->bufused too.
By which I mean "move them into the buffer *before* the memory location to which ->bufstart points." 20:56
Yes, that does mean the macros to access those values have to use negative offsets... but that's acceptable C black macro magic. 20:57
darbelo chromatic++ # black macro magic 20:59
21:00 Zak joined
dalek rrot: r43027 | bacek++ | branches/context_unify3/src/call/context.c:
Clear registers after allocation.
 21:04
21:25 bacek joined
chromatic Oh, I see. Create the signature (which implies a context), then fetch and push that later. 21:27
21:34 naypalm joined
Whiteknight "black macro magic" <- my favorite santana song 22:26
bacek chromatic, indeed
chromatic For the buffer we store { INTVAL refcount; INTVAL buflen; INTVAL bufused; void *bufstart; } and in the STRING we point to bufstart. 22:28
Whiteknight that doesnt decrease overall memory usage 22:29
chromatic We have to do some compile-time calculations in the header to figure out the appropriate math for the offsets to avoid any struct padding/alignment issues on weird platforms, but the macros are trivial.
Sure it does.
Whiteknight just makes accessing those fields harder
chromatic We don't have to have four bytes for buflen and four bytes for bufused in parrot_string_t. 22:30
We shrink that from 36 bytes to 28.
We fit 22% more STRING headers in the same amount of space and we don't hurt substr. 22:31
Whiteknight we can do that now inplace 22:32
chromatic Our buffer allocations get 8 bytes larger apiece, but we have the same number of allocations overall.
Combine that with compile-time combinations of encoding/charset, and we can fit 33% more STRING headers in the same amount of space. 22:33
That's like making the GC 33% more efficient.
Hah, and we could take a trick from the old tile-based video games. 22:39
Store all of the constant string text in the constant segment of the object file.
Make one buffer pointing to that.
All constant strings point to that buffer but have a different ->strstart and ->strlen. 22:40
Try to modify a constant string in place? BLAM!
<crickets>C'mon, someone appreciate my evil brilliance.</crickets> 22:41
pmichaud +1 22:42
purl 1
Tene +1
purl 1
pmichaud chromatic: we've come to always expect such brilliance from you
Tene pmichaud: it's still nice to express appreciation.
pmichaud Tene: oh, absolutely! 22:44
purl Oh my, yes.
pmichaud I was waiting to see it in code first :-)
chromatic It's difficult to tell if I've dazzled everyone with bad ideas, with ideas fully-formed in my own mind, or if you're all at the grocery store or changing diapers. 22:47
pmichaud Ah. I think it makes excellent sense that the buffer information be stored along with the buffer. I'm a little surprised it wasn't that way already :-) 22:51
chromatic Yeah, we have to access it all in the same spot, and there aren't many of those. 22:52
Tene chromatic: I think it's a great idea.
22:56 colomon___ joined
pmichaud afk, time to take the family to dinner 22:56
(no diapers here anymore, fortunately.)
23:05 davidfetter joined
chromatic The goodnews is that ->bufstart and ->buflen have macro encapsulation. ->bufused does not. 23:08
23:21 colomon joined 23:47 mikehh joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!