weekly meeting at 18:30 UTC, Tuesday
Set by moderator on 3 September 2008.
07:19 particle1 joined 12:04 kid51 joined
kid51 Pre-posting report, then off to $job 12:05
* Had a couple of Perl 5-ish tasks that I thought were delegatable to others, so I posted on the list. 12:06
* Got 6 responses, 5 from completely new people -- which > number of tasks I had!
* Balint Szilakszi studied smartlinks-related tickets -- which forced me to do likewise. 12:07
* As result of this and Moritz's comments, I think we can yank smartlinks code from the distro. 12:08
* What we have is undocumented and doesn't work. Have proposed patch.
* Anyone who sees a role for that code in our distro should speak up now. 12:09
* pmichaud et al: Do you have Rakudo tasks that could be delegated to people like B�lint?
* EOR
12:10 kid51 left 13:32 davidfetter joined 15:40 pmichaud joined 15:44 PacoLinux joined 16:10 Wknight8111 joined 16:18 contingencyplan joined 16:28 cotto_work joined 16:33 isop joined 16:37 barney joined 17:10 kj joined 17:39 jhorwitz joined
kj I don't have internet access at home, and leaving office now, so this is my report: 18:12
* cleanups, documentation and optimized (a bit) of pirc
* played with the idea of converting pirc's data structures to PMCs, but think it wouldn't be as efficient 18:13
* thanks to moritz++ for providing me with access to a linux box to test pirc there. 18:14
.eor
18:20 NotFound joined 18:25 jonathan joined 18:30 chromatic joined
chromatic Hello everyone. 18:30
18:30 allison joined
Wknight8111 hello 18:30
moritz hi
jhorwitz yo
moritz (kid51 and kj pre-posted their reports) 18:31
NotFound H
barney hi
allison waves
chromatic Alright, let's go in order.
allison?
18:31 rurban joined
pmichaud yhere. 18:31
allison - Fixed a number of failing tests on the pdd17mmd branch. We're down to 2 failing tests on Linux and 6 failing tests on Mac OS X. Remaining test failures appear to be GC-related. 18:32
whoops, pdd27mmd
- Removed deprecated functions.
- Updated tests to match the new MMD semantics (no more n_*, signature of an MMD vtable function matches the vtable function)
- Will work on initial language testing next.
EOR
chromatic barney?
barney fixed a couple of codingstd glitches 18:33
.eor
chromatic I fixed a couple of bugs, and then I fixed a couple of problems on the MMD branch.
Most importantly I found a better workaround for the HLL mapping problem. 18:34
cotto_work?
cotto_work * briefly broke rakudo by "fixing" get_*_keyed_int on reizable*array
* will try again after the release
* also fixed a few bug and closed a few ticket 18:35
* tried to remove pioctl from trunk, but that will have to wait until after the IO milestone
.eor
chromatic japhb?
18:35 smash joined
chromatic jhorwitz? 18:36
jhorwitz branched mod_parrot to simplify the HLL layer. These layers (mod_perl6, PHP, etc.) are now first-class Apache modules and can manage their own server and directory configurations. still needs work before merging back into trunk 18:37
EOR
chromatic jonathan?
jonathan * Spent my Rakudo day mostly fixing various little bugs here and there
* Also spent more time on the MMD grant
* Switched Rakudo over to using Perl6MultiSub PMC
* Gets us much closer to being what the Perl 6 spec asks for - we can now dispatch based upon roles and have refinement types as tie-breakers
* Good enough to pass all of current spectest_regression, plus a couple of extra tests that were TODO'd started to pass also
* However, some bugs; one of them is something that passes in the PIR tests for the PMC, but fails when doing something similar from Rakudo; need to investigate why.
* Badly behind on writing up Rakudo day - will try and fix that tonight/tomorrow.
EOR
chromatic moritz?
moritz * enabled parallel testing in rakudo (mostly let others do the work for me; works fine) 18:38
* I think we should try to attract even more Perl 5 developers by handing out cage tasks that are easy to do without much parrot knowledge (like kid51++ did)
* implement a few trivial parsing constructs (m/../, qw/.../) that enabled a few more tests
* Somebody should really fix the svn server.
.end
chromatic NotFound?
moritz s/implement/implemented/ actually
NotFound * Added command line options -I and -L
* fix some bugs
EOR
chromatic particle? 18:39
pmichaud?
pmichaud ** Rakudo spectest_regression: 153 files, 3370 passing tests
== Release management
: 0.7.1 release will happen a little later this afternoon
: get any NEWS, PLATFORMS, etc. commits in soon
: let me know if there are any release blockers
== Overall
: Been answering questions on IRC and email 18:40
: Been provoking questions on p6l
== PCT stuff
: Added 'newclosure' as a valid :pirop for the PAST::Compiler
: Added note about changing current behavior of P6object .new_class method
== NQP stuff
: Fixed a bug where it didn't handle null values from RPA properly
== Rakudo stuff
: Answered lots of Rakudo and Perl 6 questions
: Fixed the .kv method on Mapping/Hash
: Fixed 'defined' to be a named unary
: Cleaned up the grammar somewhat
: Fixed statement modifiers occurring after listops
== Queue 5 items
eor
chromatic rurban?
rurban * just moved from graz to mainz for a month. super-luxus flat, but no stable internet yet.
* more work on pdd30_install: Now I have 5 layout suggestions 1a-c, 2a-b
* work on make test with already installed shared libparrot
* cygwin070patches up2date
* no time for jvm, but plans for perl5 B::PIR
EOR
chromatic smash? 18:41
smash no report
chromatic Tene, are you back yet?
Tene I am!
Just barely.
I implemented gather/take for rakudo
18:41 mberends joined
Tene Little bit more work on cardinal, nothing interesting. 18:42
I made a branch to implement pmichaud's exceptions api proposal.
I proposed an ExceptionHandler enhancement on the list.
I'd like feedback on both of those. 18:43
That's probably all.
.eor
moritz Wknight8111?
Wknight8111 *Worked on /docs/book a little bit 18:44
*Got a pugs commit bit, going to be working on the Perl 6 essentials book in there
*Applied for a Perl 6 microgrant to work on these two books
*Refactored Parrot_PCCINVOKE and friends for the pdd27mmd branch
*More refactoring to do for it still, hoping to unify some things
EOR
chromatic Wknight8111?
Let's go to question time then. I'll start: what do we need to finish before the release?
pmichaud you mean the 1.0 release 18:46
?
allison the 0.7.1 release, I'm guessing
chromatic 0.7.1
pmichaud oh. I figured we'd just release with whatever we have today -- didn't know that we had any specific milestones
I'll look for deprecation items and see if they're available for removal 18:47
chromatic I mostly meant "What do you need us to do to help you?"
pmichaud ahhhhh
just the standard release sorts of things -- update PLATFORMS, NEWS, AUTHORS, etc.
smash i'll do the debian packages after release, i've been tring to keep them up to date 18:48
pmichaud I don't know of any specific blockers or things that need to be addressed
chromatic Okay, good.
Any other questions?
pmichaud (if I'm wrong about that, please tell me :-)
I have a bunch of items
#1: How can I stringify a Float for use as a PIR literal such that 18:49
we don't lose a ton of precision? Related: Is C<get_repr> the correct
opcode for this?
currently the methods I have available seem to only provide about 6 or 7 digits of precision
allison seems like a format print where you choose the precision would be sensible 18:50
sprintf-like
pmichaud do we have such a beast?
allison hmmm...
pmichaud and how would I chose the precision such that it works for both things like .00000000000001 and 2.7E+34 ?
NotFound The precision wanted may depend on the C type FLOATVAL maps to. 18:51
allison there is an sprintf opcode in src/ops/string.ops
pmichaud yes, but what specifier should I use?
allison can't say how reliable it is yet
pmichaud: can you make that a ticket and I'll attach it to the Strings milestone? 18:52
Tene queue one question from me.
pmichaud allison: okay. Rakudo number processing and some tests are blocking on this issue, though.
allison pmichaud: unless it's something you're blocking on right now
pmichaud go ahead with Tene's question, because I think it's actually my question #2 :-) 18:53
Tene It isn't.
pmichaud go ahead anyway :-)
Tene NO U FIRST
Fine.
Does returning from a throw_from_c ever actually make sense? Is that something we need to support? 18:54
allison you mean resumable exceptions at the C level?
Tene Because the docs claim that we can continue at the level of a C instruction, but I don't think we can make a parrot continuation that does that.
Right.
At the very least, we might want to support automatically resuming non-fatal unhandled exceptions, which I think might be possible. 18:55
allison at the moment there's some code in place to prevent it from returning, it restarts the runloop instead
NotFound If the C stack is dropped, can't be restored by a continuation. 18:56
allison it is desirable, but may not be possible under the current set up
NotFound: the C stack isn't dropped, because the handler is always invoked with the current C stack in place
Tene Is that something that's worth me trying to investigate, then? 18:57
allison NotFound: the C stack is only dropped after the handler is finished
Tene: It's worth looking into it, but feel free to report that it's something we'll need to delay until 2.0
Tene Okay.
Thanks.
chromatic pmichaud, #2/3?
Tene goto pmichaud
pmichaud #2 is related to Tene's :-P 18:58
chromatic longjmp pmichaud env
pmichaud in general, can we get some feedback on the exceptions proposals he and I have made? We'd like to know if we can consider merging his branch into trunk. (My messages were subject "throw oddities in pdd23")
don't need feedback immediately (unless it's available), but didn't want it to be warnocked
Tene chromatic responded in #parrot, but if anyone else comments, that's great too. 18:59
pmichaud ah, I didn't see the #parrot response
#3 is for allison: In the pdd27mmd branch, does C< add $P0, $P1 > still do the
same as before?
allison do you mean add_p_p? 19:00
pmichaud yes.
allison or add_p_p_p
pmichaud add_p_p
allison yes, no change there
pmichaud okay, good.
last question from me
this probably needs longer discussion, perhaps on list, but any initial reactions ("yes that's right" or "no way!") would be appreciated on this one 19:01
allison (I'll take a look at the throw proposals on the list)
pmichaud #4
For rakudo, it appears as though we will have to implement arrays
and hashes such that each element is a Scalar container that
then references the corresponding value. In other words, a
(non-lazy) array of <n> values will require 2*n+1 gc-able elements.
Comments?
allison so the Scalar container will be a pmc pointer to a scalar value? 19:02
Wknight8111 have fun with that :)
allison is this because of some additional metadata needed for scalars?
pmichaud allison: yes, and it delegates all method calls and vtable methods (except a few) to its value
metadata is part of it, but primarily it's in order to get the value and reference semantics correct
allison hmmm... it sounds highly inefficient
pmichaud in PIR there doesn't seem to be a way for me to refer to an array element by reference 19:03
allison it's worth talking through the value and reference semantics to see if we can make it possible to do it with one PMC
pmichaud yes, it sounds inefficient to me also, which is why I've been trying to avoid it, but I think I'm at a dead-end
allison what do you mean by "refer to an array element by reference"? 19:04
NotFound pmichaud: returning a proxy in [ ] can be a way.
pmichaud sub foo($x is ref) { ... }; my @a = 1, 2, 3; foo(@a[1])
jonathan pmichaud: Maybe we can have a reference PMC that refers to an array element.
pmichaud: And only create it when the array is indexed into.
particle shows up with no new status to report
pmichaud jonathan: I've thought about that, but that seems to just degenerate to having a Scalar for every element
jonathan Depends how you're using the array. 19:05
pmichaud I'd rather create the Scalar object once (for the array) than once-per-indexed-access
jonathan If you're iterating over it in a non-rw way, you'd probably never need to make any.
allison so that would pass an array element by reference, so changes to $x would modify the [1]th position in the array, but would not modify whatever element was originally in the array?
pmichaud allison: partially, but I also need to know about any type constraints that are on the Array 19:06
e.g., if I had done my Int @a = 1,2,3;
Tene So, I saw mention on the list of some parrot developer conference, hosted by google? What's likely to happen there? Is there any vague plan, or just throw a bunch of parrot devs together and see what happens?
pmichaud also, it appears that Perl 6's value and reference semantics are dependent on values being immutable 19:07
allison Tene: it's specifically planning the final stages to the 1.0 release
pmichaud so, something as simple as $x = @a[$y] causes the Scalar $x to refer to the value in @a[$y]
if we then increment @a[$y], then we have to re-bind it to a new value -- we can't just increment the value that's there (because $x is referring to it)
moritz pmichaud: no, that copies it 19:08
pmichaud moritz: see the discussion on p6l :-)
moritz pmichaud: it's most likely wrong anyway :/
19:08 rurban joined
allison There are several ways to do it aside from adding a layer of indirection to every array element 19:09
pmichaud it does not cause the symbol $x to refer to @a[$y], it causes the container $x to refer to the value referenced by @a[$y]
allison largely, it seems to be a custom Array type
pmichaud part of the issue seems to be that once I do set $P0, $P1[key] there's not really a way for $P0 to keep its association with $P1
allison That could be fixed 19:10
add an additional attribute to the scalar types
Wknight8111 I don't see why $x = @a[$y] should be a reference, unless you were trying to extend lazy array semantics to scalars too
allison but, a scalar could be stored in multiple arrays at the same time
pmichaud I do know that I've been asking about this since at least 2005, but nobody seems to come up with any concrete answers :-| 19:11
moritz Wknight8111: I don't think it actually is, but there's some confusion floating around that. However $x := @a[$y] does create a reference
Wknight8111 right, so the "=" should create a copy instead
pmichaud no, $x := @a[$y] causes the symbol $x to bind to the container given by @a[$y]
allison pmichaud: well the semantics do seem rather odd
pmichaud allison: they're really just traditional perl semantics, afaict 19:12
allison perl 5 is much simpler
pmichaud (except for binding, yes, I agree.)
so, how do I move this forward? 19:13
rurban btw: I had cygwin blockers for 0.7.1 but no ticket. just reports on irc
pmichaud rurban: are they still blockers -- i.e., should I hold the release?
rurban i don't have enough time now, and I can fix it afterwards also 19:14
allison pmichaud: I don't really have a good answer for you at the moment. if you have to go to a dual layer for scalars, do it, and we'll try to refactor it out later
rurban it's cygwin only I guess.
moritz pmichaud: I think that Darren's reply is the best so far, and it does say taht stuff is copied, but it's usually references that are copied
allison pmichaud: really, it'll probably take us a couple of passes on implementing the feature anyway, so might as well implement one that's intended as a throw-away
pmichaud moritz: "reference" is effectively the same as saying "scalar"
moritz: i.e., a reference is an object that contains a pointer of some sort to another object 19:15
moritz: which brings me back to where I started -- an array has to have a reference object for each element in addition to the value object (in order for Darren's reply to work in Parrot)
moritz pmichaud: I don't think it makes sense to discuss Perl 6 semantics in #ps... 19:16
rurban pmichaud: irclog.perlgeek.de/parrot/2008-09-14#i_567329 src/string.c:2241: failed assertion '(s)->encoding' in loadlib (cygwin has no $ENV{LANG})
moritz pmichaud: and it's a much too convoluted topic to be settled here
pmichaud it does because I'm saying the Parrot model doesn't really support the semantics we need
allison moritz: well, we're discussing how to implement it in Parrot
moritz ok
pmichaud or, what I'm saying is that the only way I have found to implement Perl 6 semantics in Parrot is to have the extra layer of indirection, and that seems inefficient to me (and allison too) 19:17
so that's a potential deficiency in Parrot at the moment that we have to figure out how to resolve.
allison could you do it with a special Scalar PMC that acts as both container and value?
pmichaud wouldn't it also have to have a type for the value?
i.e., you mean I should have ScalarInt, ScalarNum, ScalarStr ? 19:18
allison well, perl 5 has only SV, that contains storage for all possible types
pmichaud yes, I know
allison and, being "typed" in perl 6 is not necessarily the same thing as a Parrot PMC type 19:19
pmichaud it might be possible to do it if Integer/Float/String could morph into a Scalar container (and vice-versa)
NotFound rurban: What is the relation between LANG and the encoding of a string?
pmichaud but it's not just Integer/Float/String, it's bascially anything that is an immutable type
19:20 rurban_ joined
allison you'd probably have to handle the morphing externally, unless you're dealing with Perl6Integer/Perl6Float/Perl6String, etc 19:20
pmichaud there is an advantage to using the all-containers-as-scalars approach, however, and that is that simple assignment no longers involves making copies of objects (so we do get a gain in gc-able objects there)
i.e., right now $x = 'foo' involves making a Str object for the constant 'foo' and then copying it into $x 19:21
(and the copy involves cloning foo)
spinclad could you use a special Scalar PMC that references to the array (for type...) and the array cell, so when you aren't talking about it, it needn't be there?
pmichaud spinclad: possibly, but again, that degenerates to creating a PMC on every indexed access instead of once on first reference
19:21 rurban__ joined
pmichaud I'd rather create it once at the beginning than once on every access 19:22
allison once on first reference is better than once on array creation (since many/most array elements will never be used in this fashion)
pmichaud I'm not talking about array creation
chromatic memoized on first reference
pmichaud Im saying once on first refernce 19:23
i..e, having a PMC that references the array and index is not much better than creating the Scalar container the first time I have a keyed access
allison so, the first time an array element is used as a reference, it's element gets replaced by a Scalar that points to the original array element
that seems like a tolerable first stab at the problem
pmichaud yes, except we don't have any way of knowing "used as a reference" 19:24
so it's really on first access
allison less tolerable
pmichaud there's not an opcode that tells me "get a reference" -- all I have is get_pmc_keyed
allison get_ref_keyed_int?
pmichaud since I don't know how that pmc will be used (i.e., if it will be modified), I have to assume it will be referenced
allison I'm not sure we have a general use for get_ref_keyed, 19:25
pmichaud note that everything I'm writing for arrays applies to hashes as well.
(and yes, these are the same issues that led us to implement a 'copy' opcode late last year. I'm now reaching the limitations of 'copy'.) 19:27
NotFound rurban: I don't see the road between not having LANG env var and a string lacking encondig.
allison ah.... this is that weird Perl semantics where modifying a variable that was stored in the array modifies the element in the array
rurban pmichaud: The encoding error came in the last four days, so I should find it by my own also. Another new language problem is src/pmc_freeze.c:814: failed assertion '(int)io->image->bufused >= 0'
pmichaud that's a part of it, yes.
allison but, isn't that what 'morph' was intended to implement?
rurban NotFound: Just wild uninformed guessing
allison that you keep the same container, but change the value it points to? 19:28
pmichaud yes, but morph was broken in that way
allison in what way?
pmichaud i.e., as morph is implemented, every type has to know how to morph itself into every other type
NotFound rurban: Can't you do a backtrace on cygwin?
pmichaud that's why we implemented 'copy'
allison yes, that is broken
pmichaud 'copy' keeps the same PMC but changes its value
rurban I can, but not now. 19:29
allison okay, well in order to implement a true generational gc we may have to add an extra layer of indirection to PMCs themselves, that may solve your problem
pmichaud it may. my overall feeling is that parrot's current set of opcodes aren't sufficient to handle references in aggregates 19:30
allison (we can't currently ever move PMCs)
rurban indirect PMC++
very important also for compating gc
spinclad (compacting)
allison pmichaud: that's certainly true, but the current set of opcodes are all that the current PMC implementation can support anyway
Wknight8111 gc covers more then just PMCs though, you would have to add similar indirection to strings and other pobjs too 19:31
allison Wknight: yes
pmichaud well, at one time I had played with an assign_p_k_p opcode, to augment set_p_k_p
Wknight8111 not to mention objects that aren't isomorphic with pobjs, like PMC_EXT, which I've been trying to have managed
rurban pin-pointed PMC's on the other hand are nice to have for nci callbacks (gtk2 e.g.) 19:32
pmichaud right now the only operation we can perform on aggregates is "bind" and "lookup". There's not a way to assign to an aggregate value.
er, assign to an aggregate element
(except via 'copy')
allison pmichaud: I'm happy to add the opcode, if you implement an aggregate type that uses it
pmichaud: it'll probably need additional vtable functions too
pmichaud yes, it might
anyway, I'll give one last crack at trying to make things work within the current implementation 19:33
(i.e., without the extra Scalar PMCs)
particle a patch to the pmc pdd is probably the first step for assign_* 19:34
pmichaud a proposed patch, perhaps. But I'd prefer to see if it'll even work first.
particle yes, proposed patch, not commit.
pmichaud anyway, eoq for me (#5 I'll take up on #parrot later)
19:38 jhorwitz left
spinclad (chromatic is away? gavel?) 19:39
allison that's a wrap, thanks everybody! 19:40
pmichaud thanks, all
moritz ciao 19:41
chromatic Yep, thanks all. 19:42
19:42 pmichaud left, chromatic left 19:49 PacoLinux left 19:52 rurban left 19:53 mberends left 19:55 Wknight8111 left 20:01 cotto_work left 21:07 NotFound left 23:23 jonathan left

Powered by Cro and the Raku® Programming Language.

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

Thank you!