% irc.eggebuh.com has changed the topic of  to: Piper
<purl> i already had it that way, Piper.
<moritz> Piper: where are the logs?
<purl> the logs are in the forest. or useful for recovering that was was lost, or assigning blame
% GeJ has left GeJ!~geraud@edna.nealab.net
<particle> moritz: see /topic
<Coke> moritz: or the mailing list, or the website...
<moritz> ok ok ;)
<svnbotlt> r25533 | petdance++ | trunk:
<svnbotlt> : removed an unnecessary str_dup/free pair.  Adding some ARGIN() and consting to helper functions
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25533
% Limbic_Region has joined #parrot
<moritz> Andy: do you have a multi core mashine? make -j 2 ; make smoke just died for me
<Andy> moritz: Dual processor, yes.
<moritz> weird
<moritz> why does it always work for you, and not for me?
<chromatic> There's something dodgy in our parallel makes.  It looks like the string constants code has a race condition.
<tewk> Andy: so whats the idea with removing sprintf, whats the better replacement.
<Andy> snprintf.  See my mail to the list.
* tewk looking for simple tasks to help parrot in spite of mybusy schedule.
<tewk> Duh make sense.
<chromatic> tewk, how's your Valgrind-fu?
<tewk> It use to be really good, I could dust it off pretty quickly.  I was thinking of helping out with IMCC.
<chromatic> That would be a big help.
% teknomunk has joined #parrot
<tewk> So whats the technique, reason about a str_dup instance, remove it, see if valgrind yells?
<chromatic> Usually removing a str_dup makes a nice segfault.
<moritz> ;)
<moritz> sorry, wrong channel
<chromatic> Unfortunately, not always.
<chromatic> Just about everything that returns STRINGC and the spot that does a str_dup before returning either PARROT_OP or IDENTIFIER (all of these are in imcc.l) are sketchy.
% barney has left barney!~bernhard@p549A2FFC.dip0.t-ipconnect.de
<tewk> ok
<chromatic> If you remove the str_dup() on assignment to valp->s, you get weird failures in PGE about not being able to locate PGE::Match
<Coke> Andy: is snprintf safe for the version of C we're committed to?
<Andy> What version is that?
<purl> i guess version that is current but maximally forward compatible
<tewk> c89 i belive
<Coke> C89? Posix? IANACP. =-)
<chromatic> so there's some assignment somewhere in imcc.y or called from imcc.y that stores the value of valp->s directly that *needs* a str_dup() but isn't getting one.
<Coke> s/posix/ansi/, actually, I think.
<particle> tewk: have you seen the recent progress on cardinal and ecmascript?
<Andy> A question for the list!
<Andy> Andy Bach has notes re: Solaris coming soon.
<tewk> I saw that kjs say he did something.  kjs++
<tewk> I nuked it but haven't gotten back to cardinal.  I'll have to take a look.
<kjs_> tewk: did I steal your project?
<Coke> Andy: I wouldn't see a problem with us probing for it and using it if it's better, if we have a c89 fallback.
<Andy> and we can make a wrapper that ignores the n
<Andy> brb
<tewk> Nope, all help welcome.  I had an old cardinal before PCT.  I nuked it recently, with the idea to redo it with PCT.
<tewk> I excited to see what you'e started.
<kjs_> it's really really easy *and* fun to use PCT
<kjs_> and I found out that lua, perl and python are quite similar to ruby
<kjs_> (i'm not a ruby guy)
<chromatic> "Once you have a virtual machine that can run Perl 6, you have a virtual machine that can run just about any dynamic language."
<Coke> ... except tcl.
<kjs_> let's just hope it's fast enough to do it efficiently
<tewk> well perl is ruby's grandfather, though the community doesn't like to admit that. :)  Matz will tell you the truth though ;) In all fairness Ruby is continuing to mutate farther and farther away from perl.  
<cognominal_> a good thing for us is that the next python will break compatibility
<kjs_> from what I have seen, it's combining perl's and python's syntax
<davidfetter> any word on whether python 3 will be sandbox-able?
<kjs_> cognominal_: we should make sure to have python on parrot earlier than python :-)
<cognominal_> doing so, better make a big step to another languae
<kjs_> python 3 that is
<Andy> OK, back.
<Coke> Andy: http://rt.perl.org/rt3/Ticket/Display.html?id=39117
<cognominal_> learning that the register renaming engine is broken worries me about the parrot state
<Coke> ... register renaming engine?
* cognominal_ made a big fuss about that
<davidfetter> anybody here played w/antlr?
<Andy> thanks, Coke
<cognominal_> I don't know the exact term or I may hae misunderstood the recent thread here
<Coke> Andy: I am the ticketmaster. Are you the lint keeper?
<Andy> If someone asks you if you're the cage cleaner, YOU SAY YES.
<cognominal_> davidfetter: what do you mean by sandboxable?
<Coke> was the thread logged, or did it happen when Piper was gone?
<davidfetter> cognominal_, can be categorically prevented from doing certain operations. think of Safe.pm
<davidfetter> or of a jvm
<cognominal_> oh, we need that for use if we ever want to get into a browser
<davidfetter> or many other places
<davidfetter> <-- gathering resources for plugin languages to postgresql
* Andy cleans up old tickets http://rt.perl.org/rt3/Ticket/Display.html?id=39838
<Coke> Danke.
% gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net
<svnbotlt> r25534 | kjs++ | trunk:
<svnbotlt> : [cardinal] added test file + update manifest.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25534
<Coke> so, 39844 seems to be that we're missing a call to "too_many" in parrot_process_args; but the calling convention code doesn't provide to me an obvious hook to put that check (if ANY args are passed to a no-arg function, it's too many)
<particle> coke: you looking in inter_call?
<Coke> yes.
<Coke> near line 1333
<particle> lemme see if i can help. thx
<Andy> I've committed a snprintf() change.
<Andy> Let's see what shakes loose, if anything.
<particle> andy: i'll try on my c89-compliant msvc
<Andy> tanks
<particle> imclexer.obj : error LNK2001: unresolved external symbol _snprintf
<particle> libparrot.dll : fatal error LNK1120: 1 unresolved externals
<particle> need a wrapper
<Andy> bah
<Andy> That was sooner shaking loose than I'd hoped for.
<svnbotlt> r25535 | petdance++ | trunk:
<svnbotlt> : removed two unnecessary str_dup calls, and switched a sprintf() to snprintf()
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25535
<Andy> ok, try it with 25536
<Andy> and I have a meeting in a few.
<particle> imcc built
<particle> building the rest of parrot now
<particle> done.
<particle> testing
<Coke> particle: I'm thinking that we could just put a thing at the top of intercall that checks to see if dest takes ANY args, if not, and ANY arg is present, immediately call too_many (if we're doing that.)
<particle> nmake coretest # all t/compilers/imcc pass
<Coke> er, top of process_args.
<particle> coke: yep, there's no short-circuit there yet
* Coke can dig in this later tonight, but at the moment, I don't know what 'dest' looks like.
<Coke> ;(if you fix it first, yay)
<particle> did you 'make tags' ?
<particle> if so, then go to the declaration for dest (line 1211)
<particle> put the cursor somewhere on call_state_item, and type <Ctrl>-]
<svnbotlt> r25536 | petdance++ | trunk:
<svnbotlt> : Backed out the snprintf() until we have a wrapper
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25536
<Coke> ... I can *find* it. I don't have time to work on this now. =-)
<particle> when you want to return to where you were, type <Ctrl>-t
<particle> ok
<particle> something like if (dest->n == 0 && src->n > 0) { real_exception(...); }
<Coke> (make tags) and I can't do that: see old discussion about tags, versus ctags, etc.
<particle> you can't use exuberant ctags? rats.
<Coke> I have ctags installed, configure things it's exuberant, it's not.
<Coke> RANT: do not define a structure with elements like "i" and "n" and not put in a (*@&#$# comment to tell me what they are.
<purl> they are intermingled and intertwingled
<particle> ok, well you need exuberant.
<chromatic> No matter how horrible Mac OS X is for development, at least you have candy-like widgits to lick.
<particle> yeah, that struct needs comments.
<chromatic> That struct needs decent names for its elements.
<particle> pshaw. that's not how we do things here.
* Coke ponders instituting a draconian javadoc-like policy.
<chromatic> I'm going to the morgue with a hacksaw, and when I come back I'm going to put another foot down.
<Coke> ... wow, that joke has legs.
<chromatic> Oh sorry.  If anyone's drinking anything now, swallow first, then read what I just wrote.
<particle>     /* Short-circuit if no args are expected and some are passed */
<particle>     if (err_check && dest->n == 0 && src->n > 0) {
<particle>         too_many(interp, st, action);
<particle>     }
<particle> that should do it, coke.
<chromatic> ETOOMANYUNNECESSARYCURLIES
<particle> eek! coding standard police!
<kjs_> i like the curlies. it makes adding code later easier
* particle throws in some trailing whitespace and tabs
* particle considers c99 comments
<chromatic> If you're already adding code, you're already adding code, so adding four more characters doesn't seem too difficult.
<svnbotlt> r25537 | kjs++ | trunk:
<svnbotlt> : [cardinal] make tests pass again.
<svnbotlt> : compilation is slow due to similar subrules. Hope that longest-token matching will improve matters.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25537
<kjs_> well, it just reads easier imho. but if it's a policy, oh well.
<Coke> it is. praise be to chip.
<chromatic> Anything that makes C more concise without making it unreadable is a win!
<kjs_> i think it's dangerous, especially as ";" is a c statement
<particle> chromatic: that's why we name our struct members i and n
<Coke> particle: Bad dog.
<kjs_> ha ha
<Coke> particle: doesn't work.
<purl> doesn't work. is having two has_many rels in one class legal?
<Coke> purl, forget doesn't work
<purl> Coke: I forgot doesn't work
% kjs_ is now known as kj
<chromatic> Yeah, I use the empty block instead of the semicolon if I need a standalone control statement with optional block.
<particle> what doesn't work? it compiles here
<Coke> compiles, sure. doesn't throw an error.
<particle> looks like one cc_state test fails
<particle> hrmm, okay i was doing regression tests before adding the new test case
<Coke> this is why i wanted to know what i & n were for. =-)
<particle> n is number of args, i is index
<particle> at least, that's what the for (; ...) loop suggests
<Coke> ... which args? All of them? just positional?
<particle> all
<Coke> I'm gonna take this ticket; if you want, you can steal it from me. I'll investigate more this pm.
% kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl
% gryphon has joined #parrot
* Coke wonders why allison's blog keeps resetting and marking all her entries as new.
% kj has joined #parrot
% Limbic_Region has left Limbic_Region!www-data@feather.perl6.nl
<svnbotlt> r25538 | kjs++ | trunk:
<svnbotlt> : [lua|pct] update grammar to use subs for infix:== and friends.
<svnbotlt> : + update actions here and there with some bug fixes.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25538
% contingencyplan has left contingencyplan!~contingen@76.186.27.146
% gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net
% tcoppi has left tcoppi!~thisnukes@dhcp-west-76.resnet.nmt.edu
<svnbotlt> r25539 | kjs++ | trunk:
<svnbotlt> : [lua|pct] fix 'and' and 'or' operators by setting pasttype('if') and 'unless'. 
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25539
* Coke rejects his own TODO ticket!
<svnbotlt> r25540 | kjs++ | trunk:
<svnbotlt> : [lua|pct] remove a comment, add a comment.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25540
<kj> anybody knows what "No applicable methods" means? it should have something to do with PAST::Compiler:bind
<Coke> what core does pbc_to_exe use by default?
<Coke> s/by default//
<particle> default core
<purl> default core is the switch core, I think.
<particle> whatever core you're configured to use by default
<particle> s/by default/
<particle> coke: i know how i'm going to implement passthrough params in pct, i just have to get to it
<Coke> ... I don't know what you mean. =-)
<particle> tclsh --some-arg-for-parrot
<Coke> ... I wouldn't put that in PCT.
<particle> you just closed a ticket related to that, mentioning passthrough args
<particle> well, it's going to be a runtime library
<particle> competition for getopt
% tcoppi has joined #parrot
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-201-94.dynamic.mnet-online.de
% buildbot has left buildbot!~buildbot@smtp.matisse.net
% buildbot has joined #parrot
<Coke> hurm. getopt is using integer type ids.
<particle> how did that slip through the cracks?
<kj> there's a lot of integer type ids
<kj> around
<chromatic> I briefly removed them from IMCC last night, but KABLOOIE.
<particle> i thought it was mostly just .const .Sub left over
<kj> what particle says
<kj> not sure if that can be replaced by '.const pmc = "foo" ', assuming foo is a sub
<kj> come to think of it; that'd better not work...
<Coke> particle: (slip through cracks) lack of tests. =-)
<Coke> chromatic: why not create a branch, remove them from IMCC in the branch, and say "tag, you're it!"
<particle> .const 'Sub' foo would work
<kj> would it?
<kj> does imcc eat that?
<particle> if we modify .const
<kj> oh it *would* :-)
<kj> yeah it'd be a good alternative
<chromatic> Would that be the "Big Ball Of Failing Tests Sucky" branch?
% GeJ has joined #parrot
<Coke> chromatic: =-)
<chromatic> ... sort of like just about every branch I've worked on, now that I think about it.
<Coke> So much cruft, so little 'svn rm'
<particle> so, delete the failing stuff
<particle> we can rebuild it.
<kj> kj?
<purl> i guess kj is fixing now.
<kj> kjs?
<kj> purl, kj is Klaas-Jan Stol or mailto:parrotcode@gmail.com
<purl> ...but kj is fixing now....
<kj> purl, forget kj
<purl> kj: I forgot kj
<kj> purl, kj is Klaas-Jan Stol or mailto:parrotcode@gmail.com
<purl> OK, kj.
<svnbotlt> r25541 | kjs++ | trunk:
<svnbotlt> : [lua|pct] improve handling of function names. only works when defining functions now. kinda. with a bit of cheating.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25541
% kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl
<Coke> kj: purl, no, foo is bar.
<Coke> kjs?
<purl> well, kjs is Klaas-Jan Stol <mailto:parrotcode@gmail.com> from The Netherlands or KHTML (read Safari/Koqueror)'s JavaScript engine...
<Coke> kjs is also called kj these days.
<purl> okay, Coke.
% jhorwitz has left jhorwitz!~chatzilla@pool-68-163-25-103.phil.east.verizon.net
% TonyC has joined #parrot
% DarkWolf84 has left DarkWolf84!~dwolf@89.215.234.147
% apple-gunkies has left apple-gunkies!~chatzilla@tx-65-41-69-61.dyn.embarqhsd.net
% Limbic_Region has joined #parrot
<Limbic_Region> piper help
<Limbic_Region> who runs piper?
<chromatic> Robert Spier
<purl> Robert Spier is, like, the head guy. rspier at pobox dot com is where I have him down as
<Limbic_Region> k - will send suggestions and feature requests there
<Limbic_Region> thanks
* moritz could offer logging with a fancy HTML output
<particle> moritz: go ahead and give it a try. there's no policy stopping you now :)
% PacoLinux has left #parrot
<moritz> particle: ok, let's see if my bot connects to irc.perl.org now ;)
<Limbic_Region> my comments were as follows:  1.  It is annoying to have Piper keep /msging me every time I join - let me tell Piper I agree to logging and leave me alone.  2.  Have the /msg indicate where things are logged - not everyone reads the topic.  3.  If there are any options (such as ignore me), then make Piper respond to help
% mgrubb has joined #parrot
% alvar has left alvar!~alvar@sub87-230-120-57.he-dsl2plus.de
<mgrubb> Good afternoon everyone.  I was wondering if anyone might have some more insight as to how to solve the build problem of 0.5.2 on mac os x 10.5.1 on PPC.  I've scoured google and didn't come up with anything.
<tewk> Limbic_Region: amen, I want to beat Tweety every time I logon to #parrotsketch and get told its being logged.
% silug has left silug!~steve@38.104.162.2
<chromatic> mgrubb, there's an environment variable you have to set, but I can't find it at the moment.
<mgrubb> at least that's a starting point, I'll see if I can dig around.  Thanks, chromatic.
% marmic has left marmic!~chatzilla@89-253-66-101.customers.ownit.se
<chromatic> There was a long thread on p6i about it last week I believe.
% peeps[work] has left peeps[work]!~peepsalot@bwext.kpimdp.com
% marmic has joined #parrot
% silug has joined #parrot
% mgrubb is now known as mgrubb-away
<Coke> Limbic_Region: Robert would love to have a volunteer to hack on Piper; Would you care to volunteer?
% Andy is now known as AndyAway
<Limbic_Region> what is it written in?
<Limbic_Region> where's the source?
<purl> it has been said that the source is at svn co svn://erxz.com/bb or see http://erxz.com/svnweb/bb/ for source browsing or hideously evil
<Coke> Perl, methinks; I was just pointing out to Robrt that having it in svn would make this conversation easier.
<Coke> once I get an svn repo, I'll mention it here; we can do pretty much what we want.
<Limbic_Region> well, if it is written in perl [56] and I can get a commit bit, then yes
<Coke> kk.
<Coke> I'll work the svn angle with robert.
<Limbic_Region> technically, that goes for anyone here that needs or wants help with something - if it is in perl [56] and it isn't painful for me to contribute, I would be happy to help out
<Limbic_Region> oh, and if by some odd chance someone needs an example of very poorly written beginner C - I can do that too ;-)
% AndyAway is now known as Andy
<Andy> Hey look, I'm snowed in at work.
<Andy> Or at least, the 1/2 mile out of the industrial park is a parking lot.
<davidfetter> for(fork()){malloc(INT_MAX);}return(0);
<zev> andy: is #49586 a ticket you created for yourself? (http://rt.perl.org/rt3/Ticket/Display.html?id=49586)
<Andy> well, I meant to
<davidfetter> anybody here tried out antlr?
<Andy> but you can have it if you want.
<Coke> ISTR that m4 had an antlr version.
<Coke> and if you have to ask twice and no one answers, time to try the list. =-)
<davidfetter> heh
<zev> ok
* davidfetter looking at better ways to embed SQL
<jonathan> davidfetter: It was Bernhard who was doing something with antlr, I think.
<davidfetter> thanks for the tip, jonathan :)
<svnbotlt> r25542 | jonathan++ | trunk:
<svnbotlt> : [rakudo] Tweaks to inheritance so now we can inherit from Bool, etc.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25542
<Andy> Can someone point me to config magic that I can steal from for snprintf() sniffing?
<Andy> hey wait, what's this config/auto/snprintf.pm?
<davidfetter> heh
* Coke hears trumpets playing in the background.
<Andy> Wow.
<Andy> Just what I ndeed!
* Coke cues up the Cars.
<Andy> The Rhino reissue of that first Cars album is phenomenal.
<Andy> Well worth buying.  It duplicates the first album w/all demos.
* Andy adores the Cars
<davidfetter> o/` just what i needed o/`
<Andy> OK, so what do I call the snprintf wrapper?
<Andy> I can't call it Parrot_snprintf
<davidfetter> why not?
<Andy> because there already is a Parrot_snprintf that creates STRINGs
<Andy> see src/misc.c
<davidfetter> d'oh
<Coke> ... izzit a macro?
<Coke> er, can your thing be a macro?
<Andy> I think ultimately it should be
<Andy> that we #define snprintf() to something else.
<Andy> But we can't have a variadic macro.
<Andy> Iiiii know what I'm gonna do
<Coke> I was thinking an ifdef with a different macro in each path.
<Coke> (one of them would just ignore the len param.)
% HG` has left HG`!~wells@user-514c092e.l1.c5.dsl.pol.co.uk
<Andy> No, because they're variadic.
<Andy> if you did that.
<zev> does rakudo have a way to shell out yet?
<Coke> ah. you mean the end bit, not the fact that each one takes a different # of required params. whooops.
<Coke> zev;don't think so, but parrot does.
<zev> ok
<zev> can I access said functionality from within perl6?
<Coke> that is beyond my ken. =-)
<chromatic> I think all that's necessary is adding support for system() in Rakudo.
<Coke> chromatic: you stay away from that!
<zev> is system actually a builtin?
<chromatic> I believe so, but its return value is sane.
<Coke> chromatic: you listen to pseudopod(cast) ? bizarre, scary, freaky fiction read aloud for your pleasure.
<chromatic> Haven't heard of it.
<zev> ah, it is called "run"
<chromatic> Okay, I haven't looked at S026 lately.  Adding that should be straightforward; it maps onto Parrot's ops pretty easily.
<Andy> is Particle around?  Or any other Windozer?
<Coke> I can be a window person; break glass in case of emergency.
% sjansen has left sjansen!~sjansen@hq-nat2.gurulabs.com
<Coke> pseudopod is http://pseudopod.org/
% Andy is now known as AndyAway
<zev> hrm.  the parrot system() equivilent is spawn().  I don't suppose there is something to capture output?
<chromatic> Something in src/ops/sys.ops maybe.
<zev> nope.  sadness :(
* particle arrives
<svnbotlt> r25543 | jonathan++ | trunk:
<svnbotlt> : [rakudo] Generalize 'is' on classes to call trait_auxiliary:is, and implement a multi-sub that accepts a trait that is a class, which applies the inheritance. Now it's all MMD, as it should be.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25543
* davidfetter puts 2 slits in front of particle to see what happens...
* particle waves
<davidfetter> heh
<jonathan> particle: pmichaud didn't seem sure that the PAST -> POST thing was a bug yesterday, so I'm pondering if it maybe is just best to implement a workaround of sorts...
<jonathan> But will give him a chance to answer first, anyways.
* jonathan doesn't want to make work for himself for nothing.
<chromatic> Yeah, this gives you a chance to work on the bytecode PMCs now :)
<jonathan> chromatic: I forgot C. ;-)
<chromatic> All it takes to forget C is a month in Spain?  Sign me up.
<jonathan> Heh.
<jonathan> Didn't think that excuse would fly.
<jonathan> I've got lots of conferences in languages I don't understand much of this month.
<jonathan> So, hacking time.
<particle> jonathan: it could be a missing feature and not a bug
<particle> in any case, it needs fixing
<jonathan> particle: Sure, thus why I'm waiting for the Official Answer.
<jonathan> It's not like there's a shortage of things for me to be working on. ;-)
* chromatic knows the feeling
* particle too
<jonathan> $jonathan.clone()
<jonathan> $DAYJOB is busy too these days.
<jonathan> Ah well, I'm getting bits done.
<jonathan> I just find Rakudo hacking is more condusive to the times when I have the odd half hour to spare.
<jonathan> Plus now I've volunteered to implement inspect on Sub PMCs too. ;-)
<jonathan> But a lot of it is, I'm giving a Perl 6 tutorial in Ukraine and possibly one in Holland too, and am bored of presenting the objects talk and saying "and one day it'll work in Perl 6 on Parrot".
<chromatic> I like inspect.  It may help us get rid of some of the slowdown in PCC.
<jonathan> chromatic: I'm really tempted to cache the individual results as ints (where applicable) in the Sub PMC's underlying structure.
<jonathan> Then it's dead fast to access them in inter_call.c
<jonathan> In fact, that's probably the only way it can work.
<chromatic> I see the temptation... but encapsulation....
<jonathan> Otherwise inter_call.c is doing...a call...oh, wait...
<jonathan> We'd be implementing inter_call.c in terms of itself though?
<jonathan> Of course, there's the whole trick I pulled with the classes implementation.
<chromatic> Unless we take the PIC approach and trampoline things to the actual sub within the PMC's invoke() methods themselves.
<jonathan> "If it's the same type of class as this, just look at the structure, otherwise use methods"
<jonathan> We could do it like, "if it's a Sub PMC, we can peak as much as we want; otherwise, use the interface"
% zaphod has left #parrot
<chromatic> I get the feeling that we don't have invoke() exactly right in terms of responsibilities though.
<jonathan> For MMD, I really feel we need some changes here too.
<chromatic> Also NCI.
<jonathan> There's no way of finding the applicable method without invoking it.
<particle> PIC++
<jonathan> Or maybe Allison spec'd one now, it was one of my comments on the MMD PDD when it came out. I didn't check back on it.
<particle> i recall the comment, but not the resolution
<chromatic> At (most) points of call, we know at compile time exactly what we're providing to the invocation.
<chromatic> Maybe not specific types, but arity.
<particle> you do know the parrot register types
<particle> but not the core types
<particle> or whatever phrasing we use to distinguish IREG from Integer PMC
<chromatic> primitive types
<particle> and core types? pmc types?
<chromatic> I'm not sure knowing register types helps HLLs much, but knowing the register types may help us dispatch.
<particle> right.
<chromatic> in the PIC sense
% mire has left mire!~Frodo@34-168-222-85.adsl.verat.net
<jonathan> OK, I gotta sleep.
<jonathan> hasta manyana
% AndyA has left AndyA!~andy@82.152.157.85
% mire has joined #parrot
% AndyA has joined #parrot
% mgrubb-away is now known as mgrubb
<mgrubb> chromatic: I figured it out, or at least solved my problem.  Apparently it was trying to build a universal binary for some reason, so I removed the -arch i386 from Makefile manually and recompiled, and it got past the issue.  I haven't been able to find a way to effect this from the configure step without having to manually edit the generated Makefile.
<chromatic> Great!  Can you send a message to the list summarizing it?
<chromatic> Someone might be able to patch the configuration system to fix that.
<mgrubb> sure
<particle> unless you want to build a universal binary, then you need that env var
<particle> mgrubb++
<mgrubb> which list should I send it to?
<chromatic> parrot-porters@perl.org
<mgrubb> Thanks guys, I'll send my findings to the list.
<Coke> at the moment, we're not looking to build a UB; we can jump off that bridge when we get closer to cross-compilation working anywhere.
<mgrubb> i'm not really interested in building a UB either, but apparently that was the "default" behavior for my system, when I ripped out all the -arch i386  stuff and left the -arch ppc  things started working for me
% Ademan has left Ademan!~dan@h-67-101-102-136.snfccasy.dynamic.covad.net
% mgrubb has left mgrubb!~mgrubb@c-68-51-40-88.hsd1.ar.comcast.net
% Partizx has joined #parrot
<Coke> I understand.
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
<zev> is the plan for the rakudo runtime to be continued to be written in pir (as opposed to NQP or some kind of miniperl6)?
<zev> (err, make that be grammatical)
<Coke> I think the plan involves "more perl6"
<Coke> PIR is helpful for bootstrapping, of course.
<zev> ok, but current code is being written in pir
% Andy has joined #parrot
<svnbotlt> r25544 | chromatic++ | trunk:
<svnbotlt> : [IMCC] Renamed some struct members in Instruction.  This makes IMCC slightly
<svnbotlt> : more readable.
<svnbotlt> : There are plenty of other struct members to rename; have at it.
<svnbotlt> : (I tryed rearranging the struct members to reduce padding and memory use, but
<svnbotlt> : segfault city; there's a dodgy "ooh everything is isomorphic" cast somewhere.)
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25544
<chromatic> Why do all of my commit messages have typos?
<rjbs> conservation of typos
<rjbs> means they're not in your code
<chromatic> I find your idea intriguing and wish to subscribe to your newsletter, "Snarky Finger Slicers Anonymous".
<rjbs> I somehow got some kind of dirt into my fingerslice.
<rjbs> So now I have a black line on my right index finger, from the third knuckle to the tip.
<chromatic> It's a gang symbol.
<chromatic> Pennsylvania Dutch Represent
* rjbs hikes up his left cuff.
<rjbs> oh ja, cha dumb bunny, choo doan wanna mess mit me und my crew, ja?
<chromatic> I think you wrote a hip hop song there.
* rjbs eats some scrapple omenously.
<Andy> chromatic: anything I should help you with specifically?
<chromatic> Still trying to find those memory leaks.
<Andy> right, but specifically?
<chromatic> Right now I'm trying to make the code slightly less obfuscated, in the hopes that that helps.
<chromatic> Actually right now I'm removing temp_buffer from the IMCC info struct.
% Theory has left Theory!~Theory@dsl093-038-250.pdx1.dsl.speakeasy.net
<chromatic> In doing so, I can remove the 4k limitation on macro sizes.
<Andy> You rename r to symregs?  WHAT THE HELL FOR?
<Andy> ISN'T r OBVIOUS ENOUGH?
<chromatic> If you have the brainpower to memorize it, yeah.
<chromatic> I'd rather use my brainpower to FIX BUGS and ADD FEATURES.
<Andy> My snprintf trick is coming up
<chromatic> Abutebaris modo subjunctivo
% contingencyplan has joined #parrot
% Theory has joined #parrot
% Theory has left Theory!~Theory@dsl093-038-250.pdx1.dsl.speakeasy.net
<tewk> chromatic: I've got some time and valgrind working, which strdup needs digging into first
<Andy> hmmm, shootout broke for the first time in weeks for me.
<Andy> tewk: If you can look at the stuff emitting opcodes, that would be good.
<Andy> I dont' think c or I have looked at it at all?
<chromatic> I agree.  Those are pretty small ones.
<chromatic> emit_pbc and stuff.
<Andy> smalL?
<purl> "insufficiently endowed" or a C-like embedded scripting language at http://www.compuphase.com/small.htm
<Andy> Oh, you're saying the leftover str_dups are small.
<chromatic> yes
<Andy> So do I worry that shootout failed?
<Andy> It hasn't failed in a while, but now it does with my snprintf thing
<Andy> I don't even know what shootout does
<chromatic> Yes, worry.
<Andy> oh, oops
<Andy> ok, well, do an update and let's see what's what
<Andy> Is shootout passing consistently for everyone else these days?
<chromatic> It is for me.
<chromatic> I know there's some PPC trouble.
<svnbotlt> r25545 | petdance++ | trunk:
<svnbotlt> : Added Parrot_secret_snprintf for systems that lack snprintf, and then changed some sprintf calls to snprintf.  Windows people, try it please!
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25545
<Andy> ok, shootout was a config problem.
<svnbotlt> r25546 | chromatic++ | trunk:
<svnbotlt> : [IMCC] Replaced a static 4096-byte buffer from the imc_info_t struct with
<svnbotlt> : dynamic memory; it's only necessary for processing macros.
<svnbotlt> : It was also the only reason macros had a 4k limit.  Now they can get bigger.
<svnbotlt> : Go crazy.
<chromatic> That's a relief.
<Andy> hey chromatic, can you build a new flex?
<Andy> so we're not flip-flopping between 33 and 34?
<chromatic> What's different between them?
<Andy> Dunno
<Andy> but I'm on 34 you're on 33
<Andy> and the output is different between them
<chromatic> Besides the minor version number, is the difference in the preprocessor checks?
<Andy> Not sure
<Andy> aven't paid attention
<Andy> mine puts out more
<Andy> see how you're reverting me: http://perlsix.org/svn/parrot/revision/?rev=25546#diff__trunk_compilers_imcc_imclexer.c
<shorten> Andy's url is at http://xrl.us/bfqse
<Andy> it's not a big deal
<chromatic> Yeah, I just saw that.
<chromatic> My version spits out more errors.
<Andy> huh
<Andy> errors in what?
<chromatic> I mean warnings.
<Andy> is that a good thign?
<chromatic> compilers/imcc/imclexer.c:55:5: warning: "__STDC_VERSION__" is not defined
<chromatic> It's sort of useless.
<Andy> oh, yes, the output is more robust in 34
<Andy> I see what you mean.
<tewk> Andy: did you compile flex yourself?  34 hasn't hit debian unstable yet.
<Andy> yes, I compiled it myself.
<Andy> It's also not available via yum
<Andy> nothing new enough to pass is.
<chromatic> To pass?
<tewk> It got released Dec 12, 2007
<Andy> Parrot wants .28 or something
<Andy> and the newest available to me in a package was .8 or so
<Andy> I'm looking at free_sym(), and I see four elements not getting freed.
% mire has left mire!~Frodo@150-170-222-85.adsl.verat.net
<chromatic> Yeah, the keychain thing stumped me for a while there.
<Andy> Did you fix it or just comment it?
<chromatic> I couldn't fix it.
% Ademan has joined #parrot
% chromatic has left #parrot
% chromatic has joined #parrot
<zev> rakudo seems confused about list construction:
<zev> > my @a = 'foo', 'bar'; say @a.join(' ')  =>  f o o
<Tene> Heh.
<svnbotlt> r25547 | chromatic++ | trunk:
<svnbotlt> : [IMCC] Removed some warnings from the lexer.
<svnbotlt> diff: http://perlsix.org/svn/parrot/revision/?rev=25547
<zev> does this just need a proto infix:<,> is looser(infix:<=>) {...}  ?
<particle> rakudo doesn't support list context yet
<particle> mainly because past doesn't support it
<zev> ah, ok
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
<svnbotlt> r25548 | petdance++ | trunk:
<svnbotlt> : use mem_sys_free and str_dup instead of free and strdup
<svnbotlt> r25549 | petdance++ | trunk:
<svnbotlt> : use mem_sys_free and str_dup instead of free and strdup
<svnbotlt> r25550 | petdance++ | trunk:
<particle> i see andy wants me to dance for him
<Andy> what, are we avoiding mem_sys_free()?
<particle> no, you want snprintf testers
<Andy> aaaah
<Andy> just one.
<purl> No, 23!
<particle> hang on, i'm getting my tutu
<Andy> God, that's hot.
<particle> well, parrot built.
<particle> now... for my 'make test' dance routine.
<zev> why would I get the error "Method 'unshift_pmc' not found for invocant of class 'ResizablePMCArray'"?  AFAICT, there is an unshift_pmc method in resizablepmcarray.pmc
<particle> perhaps not for the arguments you sent it?
<particle> what does --target=pir show you?
<chromatic> Sounds like invalid bytecode to me.
<zev> the argument should be a Perl6Str
<particle> it does sound funky somewhere.
<chromatic> zev, when did you last make realclean?
<Andy> It's like James Brown is living in your opcodes.
<zev> not recently.   I can try that
<chromatic> I don't think anyone invalidated bytecode on the trunk since the most recent release, but it does sound suspicious.
<chromatic> Wow, I had six gdb sessions backgrounded.  Oops.
<particle> infested with bugs, eh?
<zev> ok, a little better.  now I'm getting a 'null pmc in invoke()'
<particle> aha. you're trying to invoke a null pmc.
<particle> :)
<particle> seriously. check the pir.
<zev> yep.  I can deal with a null pmc
<zev> oh, interesting.  the old error just reappeared
<zev> (to be clear, I'm specifically invoking unshift_pmc)
<Andy> 1did someone break multiarray.t?
<Andy> or is it me?
<particle> andy: everything works here. nice job
<Andy> thank you sir
<particle> &
<Andy> now, I need to tweak it to see if it can detect vnsnrpintf
<zev> something is definitely up.  now it's claiming that it can't find clone() on ResizablePMCArray
<zev> the pir is literally "new lst, 'ResizablePMCArray'\n   lst.clone()"
<chromatic> Do you mean 'clone lst'?
<chromatic> vtable entries are different from methods
<zev> ah, right
<zev> thank you
% mire has joined #parrot
% alvar has joined #parrot
% mire has left mire!~Frodo@150-170-222-85.adsl.verat.net
% Theory has joined #parrot
<chromatic> Hm, I wonder if the STRINGC and USTRINGC str_dup() calls are there because of the desire to remove quotes.
% grim_fandango has left grim_fandango!~matt@bas2-kingston08-1096740991.dsl.bell.ca
% confound has left confound!~hdp@shell.icgroup.com
% alvar has left alvar!~alvar@sub87-230-120-57.he-dsl2plus.de
% Theory has left Theory!~Theory@dsl093-038-250.pdx1.dsl.speakeasy.net
% Daveman has joined #parrot
% Andy has left Andy!~Andy@64.81.227.163
% Daveman has left Daveman!~dave@pool-141-150-16-151.mad.east.verizon.net
% Dave has left Dave!~dave@pool-141-150-43-32.mad.east.verizon.net
% Dave has joined #parrot
% uniejo has joined #parrot
% uniejo has left uniejo!~uniejo@langebro.adapt.dk
% uniejo has joined #parrot
% jisom has joined #parrot
% barney has joined #parrot
% davidfetter has left davidfetter!~davidfett@start.fetter.org