% coke has joined #parrotsketch
% coke is now known as Coke
% obra has joined #parrotsketch
% allison has joined #parrotsketch
% pmichaud has joined #parrotsketch
<obra> Hello
<particle> hiya
<allison> hi
<obra> We're chipless today
<Coke> hio
<pmichaud> hello, all
<obra> . o O { Parroteer roll call }
<Coke> I refuse to wear the beak.
<obra> leo_, tewk, you around?
<particle> leo's probably not available. did you see his paste from yesterday?
<obra> I did not. (we had a server outage)
% davidfetter has joined #parrotsketch
% mdiep has joined #parrotsketch
<obra> can you repaste it for posterity, particle?
<particle> sure.
<particle> please let me paste mine first, as it's in my copy buffer :)
<particle> it's been a quiet parrot week. i applied a cage cleaners patch, and skipped a couple win32 threads tests post scm-merge. i haven't gotten to anything on my todo list.
<particle> .end
<particle> 1013:19| leo_: 01I don't know yet, if I can report from Birmingham, so just in case I paste
<particle> 1013:19| leo_: 01a few items today:
<particle> 1013:19| leo_: 01* [stm] add native atomic support to x86_64
<particle> 1013:19| leo_: 01* [String] implement S.to_int(base) method
<particle> 1013:19| leo_: 01* was generally thinking about paarrot (PMC) structures re sharing (in the presence of STM/threading) - this needs a lot more braneinput
<particle> 1013:19| leo_: 01^D
<obra>   thanks
<obra> ok. particle, coke, pmichaud, then allison
* mdiep is here now too
<Coke>   - add some more (contested) syntax to our makefile.in files.
<Coke> that's it. slow week
<obra> sorry. "particle, then pmichaud, then allison, then mdiep"
<allison> particle already reported
<pmichaud> slow week for me, also.  Did more work on converting pge and tge, but still little to show publicly for it.
<pmichaud> should have that rectified soon
<pmichaud> end of report
<obra> sorry. I missed particles's above leo
<allison> - Between travel, conferences, meetings, and getting sick, it's been a light couple of weeks on the Parrot side for me.
<allison> - On Saturday I spent some time talking to Miguel de Icaza about Mono and Parrot. His comment: Architecting a virtual machine is much harder than simply implementing one. My response: It's also more fun.
<allison> He thinks the register-based virtual machine is a mistake, and slower than a stack-based one. I disagreed, and he suggested writing a paper on it. I'll add that to my todo list. :)
<allison> I also talked with him a bit about the I/O PDD. His thought was the same as mine several months ago ("Why not do async I/O with threads?"), but in the intervening months I've come to the conclusion that threads are far too heavyweight for I/O.
<allison> - At the moment I'm wrapping up my slides for a YAPC::EU talk on PGE & TGE tomorrow afternoon.
<allison> .end
<obra> mdiep: how's things?
<mdiep> Spent a lot of time thinking about PMCs and about variables in Tcl. Not much to report besides that. I do have a couple questions though.
<mdiep> ^D
<obra> ok. and with that. question time. Matt: what's on your mind?
<mdiep> First, I'd love to get feedback on the message I sent to the list a couple nights ago
<mdiep> Second, it's been said that writing PMCs sucks. I'd like to hear how people feel that that could be improved.
<pmichaud> mdiep:  what was your message about -- I don't seem to have it in my inbox...?
<mdiep> pmichaud: http://www.nntp.perl.org/group/perl.perl6.internals/34780
<pmichaud> mdiep:  is it possible for an implementation that wants to hide the builtins to just implement null stubs?
<pmichaud> for the Ruby example, could it turn 'mergesort' into an error somehow?
<mdiep> pmichaud: I don't know if that's possible with PMCs right now, but it's definitely an option
<allison> hmmm... methods on the default base class doesn't seem like the right place for quicksort and mergesort
<pmichaud> presumably it's already going to grab things from AbstractPMCArray, doesn't seem like too much of a stretch to also say that mergesort throws an exception
<mdiep> FixedPMCArray already has a sort method, so I was looking at extending that to support different algorithms. I don't have a problem with taking a different route though.
<Coke> (writing PMCs sucks) documentation, the fact that it's mostly C, except not: pmc2c.pl could do a lot more to simplify things, I think.
<pmichaud> seems to me that the easier approach is to have an easy way to import generic methods into a class space
<allison> well, how about a sort method, with alternate base classes that do 'sort' as a quicksort or mergesort?
<pmichaud> rather than building them into the base class
<mdiep> Coke: if you have any examples of things you think pmc2c.pl could do for you, I'd like to hear them
<allison> patrick, composition, yes that's on the wishlist
<allison> we keep coming back to it
<Coke> simplify syntax. allow mixins from other subs. have a better build system that integrates with make instead of avoiding it.
<Coke> "from other PMCs"... which I think is what patrick is saying.
<pmichaud> wishlist -- as in, we can't really do it now?
<allison> not AFAI
<allison> K
<pmichaud> if I have a method PMC, and I install it as a symbol in a class' namespace, does it not become a method for that class?  I guess not
<allison> it's a dynamic VM, so dynamic additions to PMCs make sense
<mdiep> I guess what I'm trying to say is, I'm willing to put some work into pmc2c.pl and try to make PMCs suck less. but I'm not sure what they'd look like ideally.
<allison> but, PMCs, at least the low-level ones, are statically compiled C code
<pmichaud> yes, I see (at some level)
<pmichaud> if I did a find_method for a C-compiled method, what do I get?  And can I then install that thing into another class space?
<allison> mdiep: you could start by pulling together a list of all the things people don't like at the moment
<allison> mdiep: that'll give us a better idea what problems we're trying to solve
<pmichaud> mdiep: (writing PMCs)  To date I have only written one PMC class, and I thought it was pretty painless.  But it was also a very simple PMC.
<mdiep> perhaps now that I've got people thinking about it a bit, I can send a message to the list and get some responses
<allison> aye
<allison> do you have any old messages/IRC threads where people said writing PMCs sucks?
<pmichaud> BTW, I know of two PMC classes that might be useful to have written
<pmichaud> er, three
<pmichaud> (1) Capture   (combination of array+hash)   
<pmichaud> (2) CodeString
<pmichaud> (3) Scalar
<mdiep> (2) can't be done as of now because PMCs can't handle :slurpy, :optional, or :named.
<mdiep> I'll be sure to add that to the list of "things that suck"
<mdiep> allison: Dan S. used to say it and I've heard chromatic quote him from time to time
<particle> i believe pmc's now handle :slurpy and :flat, thanks to woggle. but i may be mistaken
<allison> mdiep: aye, it's the "why" we're looking for
<allison> chromatic is on a train at the moment, but I'll pick his brain later this week
<mdiep> my last question: we're thinking about starting to use a lot of dynamic opcodes in Tcl for things like variable access. is that the route that the compilers should take?
<allison> more detail?
<particle> seems better than macros, at this stage
<allison> as in, defining your own opcodes?
<mdiep> allison: yes
<Coke> which we've already done with 5 or 6 of them.
<allison> huh... and that works better than methods on Tcl PMCs?
<mdiep> this handles all the error checks that we have to do at every stage
<mdiep> allison: this is for things like looking up variables -- versions of find_lex and get_*_global that throw Tcl specific errors
<allison> oh, hmmmm
<allison> not something I anticipated
<allison> I can see why you're doing it though
<mdiep> for looking up an element in a hash, we have three different errors: if the hash doesn't exist, if the variable isn't a hash, and if the element doesn't exist
<allison> the implication is that you're going to be wrapping quite a few opcodes with your own error throwing versions
<mdiep> it's a lot of PIR
<allison> yeah, it seems like way too much work for writing a compiler
<Coke> and at the moment, "a lot of PIR" tends to be slow. =-)
<allison> it'd be nice if we could abstract it away
<pmichaud> (speaking of slow, how is the pge-version of the tcl grammar coming along -- any results to report?)
<mdiep> so one Tcl operation is sometimes equivalent to 30-40 lines of PIR
<allison> well, if it's generated PIR, that's not a big deal
<Coke> allison: yes, it is, because it's slow.
<mdiep> we are using PGE completely. it's slower than our old parsing method (85s vs. 140s here)
<allison> is the opcode library significantly faster than the PIR operations?
<allison> at least notionally, they're doing the same thing under the hood
<pmichaud> perhaps I should look at the grammar a bit and see if I see any optimizations
<mdiep> allison: I haven't written this up as an opcode yet, so I don't have a benchmark. but I could try to put one together.
<allison> that would be useful
<allison> so to answer your question: it's not what I would have expected compiler writers to need to do
<pmichaud> PIR methods are pretty slow at the moment
<allison> if it's really necessary to load new opcodes to implement Tcl, we may need to re-examine some basic assumptions
<particle> perhaps more fine grained exception classes and handling are needed
<allison> yeah, I think that's the right way to head
<allison> it sounds like our exception mechanism isn't really what the HLLs need yet
<allison> but go ahead and experiment, because we'll never know until we try it
<mdiep> okay. I'll try to get a benchmark and send it to the list
<allison> however you implement the opcodes may give us an idea of how the core opcodes should work
<mdiep> and allison can think some more about exceptions :-)
<allison> :)
<obra> Ok. What's next?
<pmichaud> . o O { that's all this week }
<obra> If not, I'll catch y'all next week
<obra> have fun, everyone. thanks
<mdiep> thanks all
% pmichaud has left #parrotsketch
<allison> thanks
% allison has left allison!~chatzilla@host81-138-173-237.in-addr.btopenworld.com
% mdiep has left mdiep!~matt@pool-71-115-179-176.gdrpmi.dsl-w.verizon.net
% mdiep has joined #parrotsketch
% mdiep has left mdiep!~matt@pool-71-115-179-176.gdrpmi.dsl-w.verizon.net
% Coke has left #parrotsketch
% PerlJam has joined #parrotsketch
% davidfetter has left davidfetter!~davidfett@start.fetter.org
% allison has joined #parrotsketch
% mdiep has joined #parrotsketch
% mdiep has left mdiep!~matt@c-71-205-191-164.hsd1.mi.comcast.net
% mdiep_ has joined #parrotsketch
% mdiep_ has left mdiep_!~matt@c-71-205-39-103.hsd1.mi.comcast.net
% mdiep_ has joined #parrotsketch
% mdiep_ has left mdiep_!~matt@c-71-205-39-103.hsd1.mi.comcast.net
% mdiep_ has joined #parrotsketch
% mdiep_ has left mdiep_!~matt@c-71-205-39-103.hsd1.mi.comcast.net