% allison has joined #parrotsketch
% chromatic has joined #parrotsketch
% pmichaud has joined #parrotsketch
% jonathan has joined #parrotsketch
<obra> hi gang
<allison> hi
<leo_> hi
<obra> Parrot sketch roll call!
<pmichaud> here
<jonathan> here
* particle waves
<chromatic> here
* obra pokes chip
<obra> (7 days and 9 hours idle ;)
<obra> thanks very much for wrangling things in my absence. let's get cracking
<obra> allison: how's things?
<allison> good
<allison> This week I had a revelation. It's not an entirely new idea, but it is a new "zen" focus for me. 
<allison> The most important thing for Parrot right now is not elegant theory, but cold, hard functionality.
<pmichaud> .oO( Amen! )
<allison> To take the IO subsystem as an example: while it's an elegant solution to implement synchronous IO as a layer over asynchronous IO or vice versa, all we really need for a 1.0 release is a working set of synchronous and asynchronous IO opcodes. The two sets of opcodes can be implemented entirely independently for now. We're defining the interface, and can refine the guts later, as long as we...
<allison> ...keep the same interface.
<obra> Woo
<allison> Which leads to the I/O PDD I'm about to check in.
<particle> pragmatism++
<pmichaud> .oO( yippee! )
<allison> It resolves some open questions.
<allison> But mainly I want to fill in any remaining missing opcodes and then just implement it.
<allison> EOR
<obra> What are you hacking on for the next week?
<allison> The next PDD
<allison> Exceptions/Events
<obra> Neat.
<allison> I mean Events/Threads
<obra> chromatic: what's new in your world?
<chromatic> I checked in some thoughts on the external API.
<chromatic> Most of them are philosophical, but there are some API changes.
<chromatic> I'm not sure precisely how to accomplish them from C; I wonder if there's a good way to shadow functions.
<chromatic> It seems like what Parrot needs internally and what embedders need may start to diverge, at least in terms of providing a sane interface to the rest of the world.
<chromatic> I'll keep working on it though.
<chromatic> That's it.
<obra> ok.
<obra> pmichaud: what's new in your world? I know you were working hard to start getting to easily parallelizable tasks.
<pmichaud> Yes, and still working on that.
% smash has joined #parrotsketch
<pmichaud> This week $job caught most of my time; the folks I work for have asked me to join them on a (highly likely) grant proposal that will be very lucrative if funded
<pmichaud> (i.e., lots of $$$ for relatively little time expenditure)
<pmichaud> so, since the proposal deadline is this week, I had to prioritize a bit on that.  We're finishing
<pmichaud> up the proposal today/tomorrow
<pmichaud> Some decisions have been made about where to go with PAST and PGE stuff, for one, we'll be starting by using a lot of traits in the .pg files to specify PAST compilation
<pmichaud> it turns out to be very convenient to compiler writers to be able to specify those items in the .pg files directly, yet doesn't interfere too much with extensibility or parseability in perl 6
<pmichaud> we're also going to be putting a lot of smarts into PAST itself, to minimize the amount of work needed by language implementers
<pmichaud> of course, any language will be able to break out of the defaults and implement its own translation components; the idea is to take care of the common things that lots of languages deal with and leave the special cases to special cases
<pmichaud> EOR
<obra> what could be done tobest help accelerate things?
<obra> (sorry my net had died)
<pmichaud> I just need time at the moment :-(
<pmichaud> as soon as I can get the initial PAST in perl6 there will be a ton for others to do
<pmichaud> (and by initial I mean *initial*)
<obra> ok
<obra> jerry?
<particle> ~ stole perl5 sprintf tests for parrot sprintf (t/op/sprintf.t.) many failures, todo, and skip remain. need to classify these tests a bit better.
<particle> ~ applied many small patches to get our source closer to the new coding standards (thanks goes mostly to paul cochrane)
<particle> ~ continuing discussion with pmichaud about PAST, etc.
<particle> ~ next: continuing sprintf test improvements, and reviewing, modifying, and applying the win32 patch for Parrot::Embed submitted by Francois Perrad
<particle> .end
<obra> having fun?
<particle> YES
<obra> woot
<obra> leo?
<leo_> * tried to used threads in sdl/mandel.pir - no answer so far on the errors I got
% Coke has joined #parrotsketch
<leo_> * sent out another design proposal re classes based on native C structures
<leo_> * I'm sorry to mention that $designer response is currently approaching zero
<leo_> * I've started hacking the postgres interface:
<leo_> - created tests (there was no test at all, and even load_bytecode failed)
<leo_> - fixed most of NCI interface
<leo_> - created OO interface with Pg, Pg;Conn and Pg;Result classes
<leo_> - implemented also NoteiceReceiver callbacks ;-)
<leo_> * hacking postgres shows some current shortcomings of parrot:
<leo_> - constant handling (how to create these from C headers)
<leo_> - can't subclass C structures to parrot classes
<leo_> - need object finalizers for e.g. Pg;Result objects - should call PQclear() on object destruction - I've implemented that, but it needs more thoughts
<leo_> * I'm still not aware of any policy regarding parrot library namespaces, that is, which namespace should PGE, Pg et al actually populate
<leo_> * fixed event handler invocation, mainly reentrancy problems
<leo_> * cleaned up most of CGP core regarding unneeded/unwanted pointer casts
<leo_> ^D
* pmichaud reserves one question/comment.
<chromatic> Ditto.
<obra> what's next for you?
<leo_> likely more core cleanup like the CGP one
<leo_> switch core needs same treatment
<leo_> .
<obra> nod
<obra> jonathan? what's new?
<jonathan> Not been a good week for finding time to do stuff, but...
<jonathan> * I'm going to the Chicago Hackathon, to hack on Parrot stuff for 3 whole days. May sleep now and then too. ;)
<jonathan> * Did some fixes in the .Net translator
<jonathan> * Now passes all the tests it does on Win32 on Linux/x86 too
<jonathan> * Found and RT'd a packfile code segfault, hope to investigate soon if nobody beats me to it
<jonathan> Blocking on...
<jonathan> * Feedback on the bytecode PDD
<jonathan> * Feedback on my two new reference PMCs proposal
<jonathan> Going to be in Spain with work for the next 3 weeks, but will try and find time for Parrot and to make #parrotsketch.
<jonathan> </report>
<obra> Nice.
<obra> Once you're back, what's the top of your hitlist?
<jonathan> If the new reference PMCs are approved, implementing those and switching .Net translator to use them.
<jonathan> Want to get more .Net translator stuff done too.
<obra> *nod*
<jonathan> If bytecode PDD stuff is approved, I'd quite like to start hacking on the fallout of that too.
<obra> Coke: you around?
<Coke> real life intruded this weeek, but I'm currently working on moving any build steps out of custom perl scripts and back into the makefile. (this basically means moving perl to run the build steps to perl to *generate* the build steps. same amount of code, but easier to maintain). working on ops at the moment, hope to have a commit within a week or so, as real life allows. Current goal is "make -j 2".
<Coke> (that's it)
<obra> Cool
<obra> Who'd I miss?
<chromatic> Kevin?
<obra> idle for 4+ days
<obra> So. question time. First one from me.
<obra> Allison, what sort of ETA should Jonathan and Leo expect for responses to their current round of proposals?
<allison> I'll work on them this week.
<allison> I've been pouring all my brain energy into IO
<allison> I'd like to schedule a phone call with both of them.
<allison> (separate phone calls)
<obra> *nod* I suspect that even very preliminary "This looks good / this looks crazy" would help get things going.
<allison> I've done that much, but it needs more detail.
<obra> *nod* jonathan/leo: poke allison out of band to figure out good times?
<leo_> sure
<jonathan> Will do.
<obra> ah. ok. leo's comment suggested otherwise. *nod*
<obra> ok. next up, I think was patrick
* pmichaud wonders if it's the "looks good" or "looks crazy" part that needs more detail ;-)
<pmichaud> re: namespaces for pge and pg -- my understanding at the moment is that pge at least belongs in its own namespace
<obra> "looks crazy. recommend ditching the dark sunglasses and shaving regularly"
<pmichaud> and I've been working toward that end.  The primary item is being able to import things out of the pge hll namespace, but I think we know how to do that now (based on discussions of last week)
<pmichaud> I suspect that many libraries that are expected to be used by multiple hll's will have to do a similar thing
<pmichaud> so, pg probably falls into that case
<pmichaud> I'm also a little concerned about potential naming confusion between pg, pge, and .pg files -- but not enough to do anything more than mention it here :-)
<leo_> pmichaud: parrot or root namespace ?
<pmichaud> eoc
<pmichaud> pge is going to go into a pge hll namespace
<pmichaud> I still don't know how we're dealing with classnames in that instance, but I'm going to go ahead and move pge and if things break we'll have more reasons to resolve that particular issue
<leo_> I'm using [foo;bar] class syntax and it's working
<pmichaud> is that [parrot;foo;bar] or [foo;bar] ?
<allison> is pg something different than pge?
<particle> postgres
<pmichaud> leo introduce some postgress stuff this week, named (IIUC) 'pg'
<pmichaud> s/ss/s/
<leo_> Pg := postgrs
<leo_> Pg := postgres
<leo_> perldoc Pg
<allison> ah, I saw that, I was just thinking of it as postgres
<allison> probably best to make it postgres
<leo_> Pg is known in perl5
<obra> If we're stuck with a single top level namespace, it's gonna get awfully crowded.
<leo_> indeed
<obra> . o O { Better port RT before parrot gets realtime extensions }
<allison> db::pg?
<obra> DBD::?
<chromatic> DBD implies something related to DBI.
<leo_> yep, something like this
<obra> DB implies debugger ;)
<allison> well, talk it over on the dbi2 list
<obra> "naming is hard"
<chromatic> For the low level interfaces, I wonder if [NCI;Pg] is better.
<obra> allison: I believe this is 100% unrelated to DBI
<leo_> DB;Pg and yep
<pmichaud> database::relational::postgress   :-)
<obra> this is dan's old native call wrapper around libpg?
<particle> s/::/;/g
<allison> if it's NCI, then NCI::Postgres
<leo_> obra: yes, but I fixed it
<allison> NCI::Pg is too confusing
<obra> I'd sort of expect NCI::lib_nameofwrappedlib_
<obra> but really, I don't care what color this bikeshed is 
<pmichaud> nci::lib_++
<chromatic> It's not always libpg; it could be pg.dll or something depending on platform.
<leo_> the color doesn't matter as long as there's a color policy
<pmichaud> .oO ( what color should the color policy be?  ;-)
<obra> pmichaud: pulsing neon stripes
<leo_> $designer says green
<leo_> or $othercolor
<allison> let's go with [NCI;lib_postgres] / postgres.dll, etc.
<obra> ok. next up was chromatic
<leo_> libpq is the documented name for it
<chromatic> Leo, I haven't seen any mail about your NCI problems; were these in commit messages, or did I miss a message?
<allison> Q?
<leo_> and the NCI abstracts the .so / .dll whatever thingy
<leo_> yep
<leo_> that's confusing
<leo_> chromatic: which NCI problems?
<allison> oh, pg is "postgres query"
<chromatic> The C structure and constants problems.
<allison> pq, that is
<leo_> C structures are in a design .pod sent to allison 
<chromatic> Oh, that one.  Thanks.
<leo_> constants was discussed recently, e.g. how to get constants from libpq-fe.h into .pasm
<allison> if c has time, I'll go over it with him this afternoon
<leo_> I've posted sock_gen.c to deal with socket constants
<leo_> but any interface needs some C constants (defines or enums)
<leo_> ## .include 'postgres.pasm'
<leo_> .const int CONNECTION_OK = 0
<leo_> (from t/library/pg.t)
<leo_> I've a remark re IO pdd 
<obra> ok. go for it. then we should probably break
<leo_> I'm against IO opcodes - I prefer methods.
<leo_> E.g. HTTP;Daemon;ClientConn ought to inherit from ParrotIO/ParrotSocket
<leo_> I can't do that with opcodes - method would work fine
<leo_> or IOW - opcodes are only nice with PMCs, if the vtable virtualizes
<leo_> the call, which isn't the case with I/O
<chromatic> There's an interesting interaction between IO layers and PMCs... seems like that may still be up in the air a bit.
<leo_> see also other quirks like in the first io test: t/pmc/io.t
<leo_> layers are orhogonal to that IMHO
<allison> we'll do opcodes for the common operations, and methods for anything more complex
<allison> (also methods for the simple pieces, as an alternative)
<leo_> $P0 = new .Undef / read $S0, $P0, 42
<leo_> bang
<allison> my question is, should we even have layers or should we move to more straightforward inheritance
<leo_> inheritance would work fine 
<allison> re "$P0 = new .Undef / read $S0, $P0, 42"
<allison> fine, but you shouldn't have to do the new first
<leo_> ?
<leo_> read only works with existing ParrotIO objects
<leo_> above crashes
<allison> as it should
<leo_> nope
<allison> 2 alternates
<allison> one takes a PIO object
<leo_> $S0 = $P0.'read'(len) # works or gives method not found
<leo_> $S0 = read $P0, len just segfaults
<allison> that's fine
<allison> make the opcode call the method
<leo_> and it doesn't work at all with:
<leo_> cl = subcölass 'ParrotIO', 'MyIO'
<leo_> allison: why the opcode then?
<allison> sanity
<leo_> I don't see any sanity with that
<allison> Parrot is an object oriented assembly language, but it also has a procedural interface for common operations
<leo_> that would create method call wrappers, disguised as opcodes
<allison> yup
<allison> exactly
<chromatic> Seems pretty consistent with existing Parrot to me.
<leo_> tons of code duplication for argument passing
<allison> nothing wrong with that
<leo_> it might be consitent with existing praxis, which doesn't mean that it is sane ;)
<allison> you're focusing on the code, but the primary measure of sanity is that of the users
<leo_> indeed - and no compiler will use io opcodes - they will use methods or functions
* obra wonders if this might be better on the list.
<allison> it is important to take the step of not entirely reimplementing I/O operations in the opcodes
<allison> but adding a shim of code to emulate method calls as opcodes is worth the cost
<allison> it's too early to say "X will be used in Y way and not in Z way"
<allison> we'll move it into discussion of the I/O pdd after I check it in this afternoon
<obra> ok. anyone else have anything on fire? if not, I'll see y'all next week
<leo_> the opcode would first have to sanity-check each IO pmcs (if it doesn 'ParrotIO' - then setup argument/result pointers - the call a method - no thanks ;)
<allison> later discussion
<obra> See you all next week. 
<leo_> see you - thanks
<jonathan> cya
% chromatic has left #parrotsketch
<pmichaud>  /part
% pmichaud has left #parrotsketch
% smash has left #parrotsketch
% Coke has left #parrotsketch
% obra has left obra!~jesse@diesel.bestpractical.com
% obra has joined #parrotsketch
% jonathan has left #parrotsketch
% allison has left allison!~chatzilla@sub17-30.member.dsl-only.net
% allison has joined #parrotsketch