13:52 -!- leo [~lt@feather.perl6.nl] has joined #parrotsketch
14:01 The hour is upon us
14:01 meatspace meating will take me away for first 5min or so, sry
14:01 -!- pmichaud [~chatzilla@c-24-1-26-255.hsd1.tx.comcast.net] has joined #parrotsketch
14:03 -!- chromatic [~chromatic@nat-147-140.oreilly.com] has joined #parrotsketch
14:03 Apologies for the delay.
14:03 Shall we start?
14:03 -!- mdiep [~matt@bursley-221-209.reshall.umich.edu] has joined #parrotsketch
14:03 okay with me :-)
14:04 Autrijus, what have you been doing this week?
14:05 (present)
14:05 Okay, chip you go then!
14:06 OK then
14:07 I've unconscionably delayed the lexical spec, but the good news is that having learned a lot about what's
known about lexicals (and, separately, about Tcl variables *rimshot*), I've planned the points of inflection
required to support p6 and tcl both
14:08 So it'll be better when it finally emerges
14:09 What's blocking you this week?
14:09 And I've looked over matt's namspace spec and found it a good direction, albeit with some false notes
14:09 (but I'll let him talk further if he likes)
14:09 EOT
14:10 What's blocking you this week?
14:10 blocking this week? .... nothing external :/
14:10 time is all. Oh, and
14:11 ... meatspace friends regaining patience with seeing me having a laptop on my lap :-
14:11 :-)
14:11 EOT2
14:11 Thanks, chip. Leo?
14:11 - continued variable-sized register frame patches
14:12 - almost done, OTOH amd64 behaves strangely, can't gdb it yet (no bt, ...)
14:12 (I've to chat with ^conner - it's his machine where I'm testing amd64)
14:12 - recent stuff isn't checked in yet because of a few test failures on ppc
14:12 - spent the weekend in Budapest/Hungary, nice Perl workshop
14:12 - talked with Larry about magic pairs, junctions and possible implications
14:12 e.g. with respect to MMD
14:12 (runtime param binding due to named arguments can currently cause MMD
14:12 redispatch, ...)
14:13 - fixed a nasty x86/JIT bug in mandel.pir, where due to 80-bit precision
14:13 (caused by keeping intermediates in the x86 FP regstack) wrong 'pixels'
14:13 were calculated see also: $ svn log -v -r 9514
14:13 4 actual patch lines (+ comments, test) done in 8 hrs :-(
14:13 :wq
14:14 What's blocking you this week?
14:14 nothing parrot related
14:14 Thanks, Leo. Matt?
14:15 spent some time this week waiting for chip to give me feedback on my namespace spec
14:15 * chip whistles
14:16 he's getting back to me now, so I shouldn't be blocking on that any longer
14:16 there are also a few points I haven't fully considered
14:17 (namespaces are also variables in python)
14:17 but I think I'm headed in the right direction
14:17 tcl still has failures - some from unimplemented unicode functions
14:17 others from lexical pad issues
14:18 I'm hoping to come up with a fix for the latter, but it means understand all the changes that coke has made
and understanding the current lexical pad implementation
14:18 so the new lexical pad implementation and unimplemented unicode functions are blocking
14:18 ^D
14:19 Thanks, Matt. Is that all that's blocking you?
14:19 yes
14:20 Great. Nicholas?
14:20 I got less done last week than I hoped. (basically nothing after Monday) because $work's $work consumed
more of my time and energy than I initially suspected
14:20 things might be different this week. however
14:21 I tried out your patch for auto-generating extend.c, and mailed an improved version back to the list, but
to date I don't think that anyone has commented. They're not *all* writing books, are they?
14:21 and I got some today, but have hit a question about parrot hashes for Chip and Leo that might want to wait
until a questions section.
14:21 If so, that's it
14:22 What's blocking you?
14:22 well
14:22 1: answer to today's question
14:22 2: figuring out how hash iterators work from the C API level, as the docs are thin.
14:22 (that's just brute force work on my part I think)
14:22 indireectly
14:23 1: I'd hoped that someone would take your patch further
14:23 2: last week Chip intimated that my question about events and parrot currently grabbing SIGHUP had an easy
interim solution, but I don't remember any further comment on that solution
14:23 and
14:24 3: longer term, I'm wondering about how parrot will do threading, and how long it will to take to get
right, as ponie will have to implement/emulate ithreads and ithread cloning atop it
14:24 oh, and I had some other design questions that are in the queue
14:24 so, I think that's it. Nothing short term. But medium term things are not getting resolved
14:24 oops, nothing external short term.
14:25 Okay, thanks Nicholas. I don't know if Jesse's here, so Patrick?
14:25 < I'm continuing to forge ahead on the shift/reduce parser
14:25 I finally found a PIR interface that I think I can live with
14:26 and I'm getting the parser to handle significant whitespace issues
14:26 after finishing that I'll be updating the PGE milestones document
14:26 I expect to have all of that done by Wednesday
14:26 I'm only blocking on time+energy at the moment
14:27 I'm a little apprehensive about upcoming changes to the :w flag in p6 rules, but will deal with whatever
comes from the language side of things
14:27 EOT
14:27 Thanks, Patrick. Is Autrijus or Jesse here to report?
14:27 I have nothing to report; I had a lot of distractions last week, but hope to review Nicholas' comments on
my patch in the next day or two.
14:28 Okay, let's move on to questions. Chip had one for Leo.
14:30 leo: argument pairs
14:30 yes?
14:30 * pmichaud may have the same question as chip
14:30 leo: last I heard from autrijus, all named parameter pairs can be known to _be_ named argument pairs at
compile time. Obvoiusly the key values may not be known until runtime. This is true?
14:31 (In other words, it's isomorphic to the Python named param model)
14:31 I think so, yes
14:32 Eeexcelent. That's it for now
14:32 (Modifying the calling convention to support that is eminently doable, but isn't blocking anyone AFAIK.)
14:32 chromatic: I'm good
14:33 Nicholas also had a question.
14:33 chip: first we need lexicals anyway then we can bind named args
14:33 quite. can't assign by name without names.
14:34 wrt Nicholas' Qs:
14:34 1 [extend.c]
14:34 if it works, just commit it
14:34 I don't use extend.c ;-)
14:34 * chip concurs on extend patch, having read the mail
14:35 no, there was more than that. including a quesiton about whether/how to remove the old names for some of
the APIs
14:35 chip?
14:35 it works, but as is it's still a bodge
14:35 Oh.
14:35 and I have no good idea how many external bits of code are relying on those API names. Or even a good way
to find/test anything live inside the parrot source tree
14:35 Policy is as Linus:
14:36 When you change an API, it's your responsibility to see to it that consumers of the API are fixed ... as long
as they're in the same source control tree.
14:36 Out-of-tree projects fend for themselves.
14:36 I'll mail to p6i on that now
14:36 OK
14:37 Timing wise parrot hacking proves problematic for me, in that the ponie project timescales were envistaged
based on not needing to work on parrot, and I think that we got 'em wrong - ponie is bigger than we
estimated.
14:37 my POV: patch it, 'make test', if ok mail to p6i and ci
14:37 So having to do any parrot hacking is
14:37 a: it's eating into ponie's time budget
14:38 b: "my brain hurts" - there's already rather too much I'm trying too keep in it at once, and having to
also implement bits of parrot that I need just makes the job longer, and hurts my morale
14:38 ok fair enough
14:38 so whilst in theory I can work on parrot, in practice it will kill ponie
14:39 I think extend.c is a bit different, as ponie is using it I presume heavily
14:39 it's using parts. but it finds more parts that it needs. it's trail blazing there
14:39 We have source control. If the patch breaks things on some platforms, won't we get test results?
14:40 because ponie is coming at parrot from a totally odd direction, compared with all the bytecode using
projects
14:40 testing extend is a bit tedious, as a) there are just a few extend tests b) ther may be a lot of code outside
our tree
14:41 I'm not convinced that make test ran tests on everything in our tree, but I've not checked
14:42 Patrick also had a question.
14:43 I actually haven't asked mine yet :-)
14:43 Nicholas: the extend code are very thin wrappers around vtables, not much can break there
14:43 I think my question was answered by chip+leo's exchange, which was about named argument handling in
parrot. I see what the plan is, like it, and don't have a pressing need for it
14:43 it's changing the names of the wrapper functions that will break things. fortunately at link time I think.
14:43 I was just curious about how it would work and eta to implementation so that I could perhaps take
advantage of it from pge. But I'll wait on it for now.
14:44 (afk 5min sry)
14:44 Nicholas: just keep the old interfaces for a while then
14:44 eoq
14:45 Alright. Anything else?
14:45 my quesiton was about the parrot hash code
14:45 I got some more answers for nich
14:45 2 [hash iter from C]
14:45 seems to be untested and underdoced
14:46 but straight forward: it's tested from pasm/pir
14:46 I could see iterator.pod whcih gave a PASM interface
14:46 just run the vtables which are called from PASM
14:46 but digging briefly into iterator.pmc, I saw that it actually uses VTABLE methods on key.pmc to get the
next key
14:46 yes
14:47 so I wondered if I could skip having an interator PMC and manipulate the key directly
14:47 the Key holds the state for iteration
14:47 so if I can create a key that is at the start, I only need it to move through the hash?
14:47 I can put together a t/src/hash.t that iters over a hash
14:48 that would be useful, if you can do that easily, beacuse that would make it easier for me to translate to C
14:49 that would be C already - you probably need translation to extend.c only
14:49 ah right
14:49 3 [sighup]
14:49 I'll disable it RSn
14:49 great
14:49 thanks
14:49 (back)
14:49 4 [threads] too early to ask ;-)
14:49 :-(
14:49 that's what I feared
14:50 a ParrotThread isa ParrotInterpreter
14:50 which is created by ParrotThread.clone of an interpreter
14:50 but they are evil and pervade everything, hence why the sooner we get the the prototype, the sooner we can
throw it away and make the real thing :-)
14:51 it's the cloning that's the faff I'm scared of. Threads running are steady state
14:51 and only the ithreads threads::shared needs replacing, and it's a bit pants currently, so whatever
replaces it will probably actually be an improvement
14:51 the problem currently is that we don't have shared PMCs (except TQueue)
14:52 mmm, shared PMCs. and shared GC.
14:52 eek.
14:52 is cloning actually necessary?
14:52 shared PMCs need some vtable tweaking
14:52 * chip would prefer a spawn model for threads, rather than a fork model
14:52 I can't see how cloning can be avoided to correctly implement 5.8.x ithread semantics
14:53 brute force, then? iterate through all namespaces looking for an honest man^W^W^Wshared PMCs?
14:54 no
14:54 it's just the details. the devil being in the details. and how to replace all the clone code from the
bottom of sv.c with something that does PMCs
14:55 [and I've still not asked my question about hases]
14:55 Nicholas: In short we can't answer it yet. But you have added a use case
14:55 (use cases. slowly I turn...)
14:56 * chip suggests moving on to the answerable
14:56 :-)
14:56 OK. Leo kindly wrote an address registry PMC. and I used it.
14:56 And then I noticed that I already had a hash implenmeted using the itreads ptr_table code to track all
SVs, as step 1 of eliminating arenas
14:57 and I thought "this duplicates the address registry. If I can iterate over the address registery, I can
kill this ptr_table hash"
14:57 and then I realised/remembed the pain it copes with
14:57 sv.c wants to iterate over all remaining SVs
14:57 and "do stuff" to them.
14:57 if you're going to meet SVs A and B in that ortder during iteration
14:57 the fun comes because
14:58 you can process A, which can cause B to be deleted
14:58 alternatively, processing A can add more SVs, by creating new ones
14:58 so the ptr_table hash code had to be hacked about until it could cope with
14:58 1: things being deleted mid iteration
14:58 2: things being added mid iteration. (it doesn't actually matter if you meet them during the iteration)
14:59 IIRC, Leo said that the current src/hash.c implementation can cope with things being deleted mid iteration
14:59 yes
14:59 but before I try to work out from understanidn the source
14:59 can it cope with things being added?
14:59 that depends
14:59 and secondly, is this an "implementation side effect", or is either/both the deletion/addition stuff
guaranteed in its "spec"
14:59 you probably want to see these PMCs later in iteration?
15:00 I don't mind if I don't see the added PMCs
15:00 then iteration should still work
15:00 because the existing perl 5 SV iteration code had no idea if it was going to meet newly created PMCs
immediately
15:00 I can add to a hash mid iteration, and still see all the keys that were in it before I started iterating?
15:01 [I don't mind it being unspecified whether I see keys I added mid-iteration]
15:01 untested but I thimk yes
15:01 [I do mind that I mustn't "see" keys that I delete prior to reaching them]
15:01 think even
15:01 but I faked that in ptr_table by replacing keys with NULL, and then running a cleanup afterwards to
actually delete the NULLs
15:02 does the hash do a "split" if it gets full buckets?
15:02 that's not necessary with parrot hashes as the bucket storeage is inside the hash and not malloced
15:03 ponie has this:
15:03 if (!empty && tbl->tbl_items > tbl->tbl_max && !tbl->iteration_nesting)
15:03 Iptr_table_split(tbl);
15:03 where !tbl->iteration_nesting is the check to disable any split mid-iteration
15:03 if it's getting full it resizes, bucket storage is expanded and bucket pointers are recalced
15:03 (gotta run, see you all next week)
15:03 but an iterator would still be valid across that resize?
15:04 I think so yes
15:04 -!- pmichaud [~chatzilla@c-24-1-26-255.hsd1.tx.comcast.net] has left #parrotsketch []
15:04 even if hte iterator is valid, the list of 'future' notes changes with the resize, I should think
15:04 OK. Good. It's not so in perl5, either in hv.c or the ptr_table code before I bodged it
15:04 so some nodes will no longer be visited
15:04 gah. that's not going to suit me. need to visit everything that I started with
15:04 I suspect you'll want to swap hashes. Union hash, so to speak
15:04 yes. :-(
15:05 I was starting to think that I'd need a second hash of "things I added"
15:05 union the two during the iteration
15:05 merge it in afterwards
15:05 seems so
15:05 not necssarily
15:05 if chip's answer is "the answer", then that's OK.
15:06 I know that I need to do the work. Rather than wondering
15:06 if delete puts in a DELETED_pmc, all added pmcs go to the end and wil be seen
15:06 I don't mind if the added PMCs don't get seen
15:06 but a few tests can easily verify how it works
15:06 but I do mind if a resize causes some PMCs not to be seen
15:06 leo, it's growth making preexisting entries rearrange to behind the iterator that's the problem
15:06 as said, resize shouldn't cause any problems
15:07 having seen A and B but not C, adding D can put C behind the iterator when it used to be ahead, so C will not
be visited.
15:07 not as far as I know
15:07 but the buckets get recalculated.
15:07 bucket pointers
15:07 oh well. I haven't read the code.
15:08 just working on first principels
15:08 * chip bows out
15:08 I need to take off in a few minutes.
15:08 I prefer to understand the code. As my ability to write evil controlled tests is far less than the ability
of the perl regression tests to throw up unpredictable corner cases that I never envisaged a test for, and
so spend some hours (or days)(or weeks once) head scratching
15:08 Is there anything else?
15:08 for (b = hash->bu.bs-i-1; i < (INTVAL)N_BUCKETS(hash->mask + 1); ++i, --b)
15:08 chip,leo: thanks
15:08 that runs through the bucket store
15:09 Leo, can you add tests for that to the iteration tests in hash.t you mentioned earlier?
15:09 yup, I'll do
15:09 Chip had another question, though I'm not sure it was a public one.
15:09 chromatic: not Parrot-related
15:10 Go ahead.
15:10 er, I meant, not for this channel. I was just wanting you not to run off post-meeting
15:10 until I could ask it
15:10
