% particle has left particle!~particle@c-24-22-165-145.hsd1.wa.comcast.net
% Nicholas has left Nicholas!9z5H6vNQmH@colon.colondot.net
% Nicholas has joined #parrotsketch
% particle has joined #parrotsketch
% mdiep has joined #parrotsketch
% Sartak has joined #parrotsketch
% pmichaud has joined #parrotsketch
% mdiep_ has joined #parrotsketch
% Infinoid has joined #parrotsketch
% barney has joined #parrotsketch
% allison has joined #parrotsketch
% allison has left allison!~chatzilla@sub17-30.member.dsl-only.net
% chromatic has joined #parrotsketch
% Andy has joined #parrotsketch
<pmichaud> Okay, roll call.
<Infinoid> me! :)
<pmichaud> allison was here but disappeared.
* mdiep_ <- here
* particle is here
<chromatic> here
% PerlJam has joined #parrotsketch
* barney is here
% Coke has joined #parrotsketch
<pmichaud> okay, we'll go ahead and begin.  barney?
% Ron has joined #parrotsketch
<barney> been looking at Lisp, continuing with lexicals
% allison has joined #parrotsketch
<barney> catching up after two weeks of vacation
<barney> .eor
<pmichaud> chromatic?
<chromatic> I fixed several bugs, created a few, and then fixed those too.
<chromatic> Next up: fixing src/hll.c, after the release.
<chromatic> EOR
<Andy> I have nothin'.  I'm just listening.
<pmichaud> Coke?
<Coke> * chromatic++ for fixing tcl 2x this week. (helped track down the most recent borkage)
<Coke> * All feature-based failures are now TODOd so we can keep an eye on Tcl going
<Coke> forward.
<Coke> .
<Coke> (er, I think I did something else but am blanking.)
<pmichaud> (seeing the word "blanking" reminds me of "Match Game")
<pmichaud> Infinoid?
<Infinoid> * I've been working on libparrot.dll linking on win32, but its been slow going.
<Infinoid> * I've been working with particle and Ron on it.
<Infinoid> * I see a 45% speedup when I'm also using ccache.  See RT #44809
<Infinoid> * I think I just fixed one half of the problem with a config tweak.
<Infinoid> * Sounds like Ron knows how to fix the other half.
<Infinoid> * Also, found an optimization for pmc2c that should speed builds up quite a lot.
<Infinoid> 1;
<Infinoid>  
<pmichaud> mdiep?
<mdiep_>  - Finished up summer internship, trying to get started back up with Parrot
<mdiep_>  - Very frustrated with Parrot's messy internals
<mdiep_>  - Hoping to get Parrot in a hackable state and figure out what to do with Tcl
<mdiep_> ^D
<pmichaud> particle?
<particle> ~ there are still a number of warnings during compile, which i'll look at today
<particle> ~ fixed bug in compiler attributes probe preventing them from working with msvc
<particle> ~ getting t/src/ tests passing, thanks to infinoid++ and ron++
<particle> ~ kicked around nqp a little bit--it's fun, but i need to spend more time with it
<particle> ~ i owe kid51 a response on reconfigure, which i'll do today
<particle> .end
<pmichaud> pmichaud?
<pmichaud> * Preparing for August release -- plan to do the release tonight.
<pmichaud> * I'm still open for names for the release.
<pmichaud> * Through irc and mailing lists I see reports of failures on various
<pmichaud>   platforms and languages, which makes me a little skittish about
<pmichaud>   pushing the release.
<pmichaud> * I'd to get a list of any outstanding issues that might warrant
<pmichaud>   holding the release so they can be fixed.
<pmichaud> * Updates to NEWS, PLATFORMS, etc. greatly appreciated.
<pmichaud> ----
<pmichaud> * Lots of updates to PCT and NQP this week
<pmichaud> * Many thanks to perlDreamer++, particle++, chromatic++, and others
<pmichaud>   who have been helping with NQP development.  We're very close to
<pmichaud>   having a fully working NQP.
<pmichaud> * Highlights of NQP and PCT updates:
<pmichaud> ** NQP can now handle subroutine *and method* definitions !
<pmichaud> ** NQP and PCT both have much improved handling of lexicals and symbol tables.
<pmichaud> ** Created inlined PIR code for builtin NQP operations
<pmichaud> ** including things like postcircumfix:«< >»
<pmichaud> ** Better handling for parsing and generation of string literals
<pmichaud> ** Fixed NQP's handling of statement enders and whitespace.
<pmichaud> ** Lots of additional tests (perlDreamer++)
<pmichaud> * I also created a sample PAST builder for abc in
<pmichaud>   languages/abc/src/abc-past.pl, written in NQP.
<pmichaud> ** NQP can already parse this abc-past.pl -- we just need to fill out the
<pmichaud>    few remaining constructs.
<pmichaud> ** Namely, we need @(...), 'return', and 'for'
<pmichaud> ** Since PAST already has 'for' (Coke++), we really only need to
<pmichaud>    design/implement the code to handle 'return' statements.
<pmichaud> ** I may implement a cheat on 'return' for now.
<pmichaud> Notably, all of the items implemented for NQP have direct impact
<pmichaud> and bearing on the perl6 implementation, and greatly simplify it.
<pmichaud> EOR
<pmichaud> anyone else here who wants to report?  leo?  tewk?
<allison> allison?
<pmichaud> oh, didn't see you rejoin --- sorry.
<pmichaud> allison?
<allison> yeah, firefox crashed on me
<allison> - I just submitted a mod_perl book to the printer. Half the proceeds are going to the Perl Foundation, so hopefully that'll give us a little more funding for Parrot/Perl 6 development projects.
<allison> - I've gone half-time at O'Reilly, working only on OSCON, so I'll be full-time on Parrot at least through December.
<allison> - Next week I'll be at YAPC::EU and plan to spend the entire time hackathoning. Hopefully Jonathan and I will polish off the last bits of the new object model.
<allison> EOR
<pmichaud> full-time Parrot:  excellent!
<mdiep_> allison++
<pmichaud> oh, one comment I forgot to make -- it will be very likely that in the next couple of days NQP will be able to interface with other libraries written in PIR.  In particular, I'm thinking about things like the PIR-based Test library, and perhaps even SDL
<allison> cool
<pmichaud> it would be neat to have a SDL demo written in NQP.  Details to come.
<allison> patrick, is there anything we can do to help with the release?
<pmichaud> well, releases seem to be fairly turnkey nowadays, which is good.  I just need to know if there are any particular areas that need focus/checking before I start turning the keys
<pmichaud> I'm still looking for a name, of course.  :-)
<pmichaud> but I'm sure I'll come up with one.  This one might be named in honor of chromatic, for the incredible productivity he's had this month.
<chromatic> There's that JIT problem I found with string_bool(), but there are a couple of options there.
<Infinoid> t/src/compiler.t is the only remaining bit for our win32 fixups.  but its skipped right now, so if we don't fix it, I think its still releaseable as-is.
<pmichaud> (for that, I'll try to pick a colorful name :-)
<pmichaud> Because of Andy++'s headerizer and cage cleaning, compiling generates a lot more warnings than it used to generate.  Are we happy to live with that in a release?
<Andy> I am.
<chromatic> We *could* remove the flags for the release.
<Andy> but what's the downside of having them there?
<pmichaud> (downside)  someone installing Parrot from a tarball may get a negative impression
<PerlJam> pm:  cockatiel  :)
<pmichaud> perljam, spinclad: noted!
<Andy> I think we could spin it into a positive.
<Infinoid> any warning-related bug reports we receive should get forwarded straight to Andy :)
<Andy> "We're working to make Parrot take advantage of compiler warnings to make it a safer build."
<Andy> which is completely true.
<pmichaud> I'll put a positive spin on it in the NEWS
<allison> I love the fact that we have the warnings, but we really need a push to get rid of the warnings.
<chromatic> We could just disable them when generating the Makefile if there's no DEVELOPING file.
<Andy> allison: Is that facetious?  I can't tell.
<pmichaud> allison: there's been a big push this week for it
<Andy> Part of the goal of the warnings is to raise the awareness!
<pmichaud> allison: but we still have some ways to go.
<allison> yup, I'm pleased to see the progress :)
<chromatic> Speaking of the warnings though, it sounds like some people would like to remove the floating point comparison warnings.
<spinclad> Andy: i presume allison means fix, not hide
<chromatic> Should we discuss that?
<allison> spinclad: yes :)
<pmichaud> I think if we just got rid of the floating == warnings it would be a huge improvement
<Andy> "remove" or "fix"?
<pmichaud> and as I mentioned on the list, I'm in favor of the -Wno-float-equal approach
<allison> "remove for tarball compiles" or "fix"
<allison> tarball users are a special case
<Andy> pmichaud: I'm concerned that future programmers won't know they're doing the wrong thing.
<pmichaud> I also like the "less warnings if no DEVELOPING", but someone else would probably need to make that patch.
<allison> and that can wait for the next release
<allison> let's call it a 0.5.0 feature
<chromatic> What do we lose if we take out the float warnings?
<pmichaud> Andy: in most all cases I'd agree, in this case (floating ==) I'm not sure that eliminating the warning is worth the workarounds required
<Andy> in this release: Nothing
<Andy> We really have two issues
<Andy> "is it zero" and "everything else"
<Andy> The "is it zero" is 90% of them
<Andy> that should be optimized to an easy way to do it.
<spinclad> we need -Wno-float-equal-zero
<pmichaud> well, the obvious easy way is  "f == 0.0"  :-)
<Andy> okj I have a meeting.
<chromatic> There is no obvious and correct way to do it with a macro, I fear.
<pmichaud> is there a way that we could have a make target that compiles with lots of warnings like this enabled?
<Coke> I am a convert to andy's way of thinking, leave the warnings in, spin it.
<pmichaud> nm, that target wouldn't ever get utilized in a useful way
<pmichaud> coke:  noted for warnings in general, any thoughts on the float warning?
<Coke> ... eh. leave it on until we decide what to do. IANACP, so I don't think I'll vote. =-)
<allison> pmichaud: for the sake of this release, I say leave them
<pmichaud> fair enough, I'm inclined to agree.
<pmichaud> for future consideration, I'll add the thought that the 90% of useless "float ==" warnings will tend to make people not notice or bother to check the 10% that might be useful.
<pmichaud> I think we're done with the warnings issue for today.  Any other comments or questions?
<allison> yeah, that's the problem with our verbose build process in general
* mdiep_ has a question
<pmichaud> mdiep: you're on.
<mdiep_> Parrot's core pmcs (Integer, String, Float, etc.) morph when you assign to them, like Perl 5 scalars. So `$P0 = new 'String'; $P1 = new 'Integer'; $P1 = 2; assign $P0, $P1` leaves you with two Integers.
<mdiep_> Tcl has to override all these because it doesn't morph. I suspect not morphing is the more common case.
% Ron has left Ron!~rblasch@62-99-200-51.sdsl-line.inode.at
<mdiep_> should these pmcs morph? or can they be change to not morph?
<pmichaud> I'm not sure I agree that not morphing is the more common case.
<allison> this has come up before
<mdiep_> a "deal with it" will suffice as long as this is a conscious design choice.
<allison> I'm okay with not morphing by default, but we do need to survey the compiler developers to see what they need
<spinclad> would 'n_assign' deal with it?
<pmichaud> spinclad: it would need a different opcode name, as n_ usually means something else.
<allison> spinclad: you mean something like assign_morph?
<allison> make it a separate vtable entry?
<pmichaud> spinclad: but yes, some sort of "assign_morph" could potentially help
<spinclad> no, like n_add creates a new PMC
<allison> do we have a good sense of how many of our target languages use morphing scalars and how many don't?
<spinclad> where add morphs it in
<pmichaud> spinclad: we already have n_assign for creating a new PMC -- but it's called "set"  :-)
<pmichaud> spinclad: or possibly "clone + set"
<spinclad> ok then
<pmichaud> (I'm still tallying the languages I work with for morphing scalars)
<pmichaud> spinclad: the key feature of morphing assign is that the PMC register still points to the same PMC
<pmichaud> perl6 expects to be able to morph scalars
<pmichaud> nqp doesn't care, because it doesn't support assignment yet -- only binding.  But if it had assignment, it would want morphing scalars
<allison> aye, as will perl5
<pmichaud> I think pynie will want morphing scalars -- but that's at the edge of my understanding for the moment
<Infinoid> if parrot types morph by default, does it mean half of the hll designers are SOL if they don't want that?
<pmichaud> Infinoid: it might need that we want a set of non-morphing base types
<mdiep_> Infinoid: no, they just have to override a vtable method.
<allison> no, it just means they don't get appropriate warnings if they assign incompatible types
<pmichaud> allison: well, it's a bit more than that
<particle> what if we make morphing a role
<mdiep_> I think if non-morphing is the default, language implementors could get morphing by using multiple inheritance (inheriting from both Integer and Scalar for Perl6Int)
<pmichaud> the base types sometimes morph in unexpected ways
<spinclad> mdiep_: would emitting 'set $P0, $P1' work?
<allison> patrick: aye, this is why I still lean toward non-morphing by default
<pmichaud> for example.   "$P0 = new 'Float'   \n   $P0 = 2.0"   leaves $P0 as an 'Integer' type
<spinclad> (or clone + set)
<mdiep_> spinclad: no, set changes the pointer.
<pmichaud> (set changes the pointer, which is also what the n_infix opcodes do.)
<pmichaud> allison: I'd be very happy with non-morphing as long as we have a way to do assignment that morphs.  We need that anyway, to be able to morph to non-base types.
<allison> I'll add this as a question to the PMC PDD
<allison> need to wrap that up soon
<pmichaud> I was originally surprised by the morphing behavior of the base types as well, and originally argued against it.  I'm still not really arguing for it -- just noting that morphing assignment appears to be a big hole in Parrot at the moment.
<pmichaud> and so the morphing scalars is the closest we have to that.
<pmichaud> s/morphing scalars/morphing base types/
<allison> can you summarize the features you need from morphing?
<allison> so I can make sure we cover them
<pmichaud> sure
<spinclad> split 'assign' into 'morph' and 'clobber'
<pmichaud> we want to be able to do assignment where the target retains its existing type
<chromatic> I'm all for an op named clobber, by the way.
<allison> morph keeps the same PMC container, and clobber doesn't?
<pmichaud> we also want to be able to do assignment where the target morphs into the type of the source
<pmichaud> in both cases, the PMC itself needs to remain the same
<pmichaud> i.e., the PMC register needs to continue to reference the same PMC
<pmichaud> this is as opposed to 'set', which changes the value of the PMC register instead of the PMC
<pmichaud> the other item I'm missing is a way to do assignment to keyed indexes in an aggregate
<pmichaud> i.e., it would ideally be an "assign if exists, bind if not exists" operation.  But that can be done in PIR for now.
<pmichaud> (but it's a lengthy sequence of PIR instructions)
<mdiep_> this is turning into a more lengthy discussion than I had intended
<pmichaud> that about covers it from what I've seen.  Anything to add, mdiep?
<allison> so it's three variants on assignment: 'set' throws away the PMC container, 'morph' keeps the same type, and 'clobber' takes on the type of the source?
<pmichaud> I would think morph <-> clobber
<pmichaud> morph changes the type of the target, clobber replaces the target with the new type
<allison> clobber keeps the type and morph takes on a new type?
<allison> okay
<allison> (somehow I expect clobber to be really destructive)
<mdiep_> I'm not sure we need a separate vtable. It's one operation (assignment) that different languages implement differently.
<pmichaud> I think 'morph' is the wrong word here
<allison> mdiep: aye, no decision yet on how to allocate the behaviour, just getting a handle on the variants we need to make possible
<pmichaud> essentially it's the difference between treating the PMC as a scalar (which takes the type of its source) and treating the PMC as an object (which vtables based on the type of the target)
<spinclad> 'morph' conforms to the dest, 'clobber' replaces it with the source
<Coke> (different languages implement differently), which makes me wonder again if putting all the language specific info into the pmcs is the way to go.
<Coke> (if I assign to a PMC in Tcl that I got from Python, I expect it work like Tcl, not Python.)
<allison> coke: not exactly
<mdiep_> that can be handled by converting on language boundaries, I think.
<pmichaud> so I don't agree that it's "one operation".  It's different depending on if we're treating the PMC as a scalar versus as an object with its own 'assign' vtable.  And within a single language there might be need for both.
<allison> coke: you do expect it to conform to a certain interface (that you can assign to it)
<Coke> in which case the language boundaries really need to be defined.
<allison> coke: but whether it keeps the same PMC container or makes a new one you really shouldn't care about
<pmichaud> actually, whether it keeps the same PMC or makes a new one is critical.
<pmichaud> that's the crux of the whole issue, at least for the languages I'm working in
<pmichaud> if a new PMC container is created, it breaks binding.
<Coke> A more concrete example: perl and tcl stringify lists differently. If I call a perl lib, get an array-style PMC back, and then print it... should it print tcl style or perl style?
<allison> coke: and when you really need a variable to act like a native language type rather than an external language type, you just assign the value to a native PMC
<Coke> in my specific example, you can't deep copy containers that way easily, SFAIK.
<allison> by default it acts like a pure perl array
<allison> we don't want to mask different languages' behaviours by default
<Coke> allison: and I think that's going to make using other HLL libs quite annoying.
<allison> because once you mask it, you can't get it back
<Coke> I say that the calling language wins. with PMCs, the callee language wins.
<Coke> I think that's going to surprise a lot of HLL users.
<allison> well, let's leave the decision until we have a large enough subset of interoperating languages to tell
<allison> at the moment, we're just guessing
<Coke> 'sfine.
<Coke> # offline
<pmichaud> okay, to recap my position and perhaps close this out for today
<pmichaud> I'm find with converting the base types to non-morphing by default, and in fact I prefer that, as long as we have some way to do a "morphing assign".
<pmichaud> which I'll call a "scalar assignment" for now.
<allison> okay, and I have a good sense of the parameters we need to cover, so I'll work it into the PDD
<pmichaud> i.e., I'd like to be able to change a PMCs type and value without having to create a new container for it.  Or, if a new container is created, it needs to be in such a way that any references to the old container can now refer to the new one.
<pmichaud> any other comments or questions for today?  It's been one hour.
<spinclad> (allison, pmichaud: re morph <-> clobber: for the record, actually no swap there; iiuc you were talking about different ends of the ops and read past each other.)
<pmichaud> (spinclad:  I think it depends on whether we think of the target or the source as being the thing that morphs.)
<spinclad> (right, that's the different ends)
<allison> (ah, I think of the target as the one that morphs)
<spinclad> (i was meaning morph the source to the target)
<pmichaud> (in my case, for a scalar assignment it's the target that changes type, so I think of that as being the "morphing assignment".)
<pmichaud> if the target doesn't change type, I'd call that a "value assignment".
<chromatic> (car (cdr '(foo bar baz)))
<pmichaud> anyay, I think we're done for today.  Good meeting all!  See you next week.  Send any thoughts about the release to me asap.
<pmichaud> Thanks!
% Infinoid has left #parrotsketch
<allison> thanks all!
% chromatic has left #parrotsketch
% pmichaud has left #parrotsketch
% Sartak has left #parrotsketch
<leo> allison: hi - glad that you'll join us in Vienna
<allison> hi leo
<allison> me too
<leo> I hope the collision with Jonathan's talk isn't a problem or scheduled as such
<allison> I intentionally listed the hackathon as ending just before Jonathan's talk
<allison> I figured we'd all adjourn to see him speak
% Andy has left #parrotsketch
<leo> yep - makes a lot of sense 
<leo> well I'll try to move hackathon part#2 down after Jonathan's talk
<leo> allison: you might place some more words towards http://vienna.yapceurope.org/ye2007/edittalk?talk_id=732
<leo> allison: schedule done
<leo> and http://vienna.yapceurope.org/ye2007/edittalk?talk_id=733
<leo> the 2nd part after Jonathan's talk
% barney has left barney!~bernhard@p549A1C0D.dip0.t-ipconnect.de
% mdiep_ has left mdiep_!~mdiep@c-71-205-39-103.hsd1.mi.comcast.net
% allison has left allison!~chatzilla@sub17-30.member.dsl-only.net
% allison has joined #parrotsketch