% iblechbot has joined #parrot
% IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk
% ruoso has left ruoso!~ruoso@85.138.47.186
% Psyche^ has joined #parrot
% bradleh has joined #parrot
% Patterner has left Patterner!~Psyche@e177237179.adsl.alicedsl.de
% Psyche^ is now known as Patterner
% IllvilJa has joined #parrot
% uniejo has left uniejo!~uniejo@langebro.adapt.dk
% uniejo has joined #parrot
% DarkWolf84 has joined #parrot
% Zaba has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% mire has joined #parrot
% dakkar has joined #parrot
% wknight8111 has joined #parrot
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% DarkWolf84 has left DarkWolf84!~dwolf@89.215.234.147
% bradleh has left bradleh!~chatzilla@c210-49-142-28.kelvn1.qld.optusnet.com.au
% ruoso has joined #parrot
% Zaba_ is now known as Zaba
% rdice has joined #parrot
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% iblechbot has left iblechbot!~iblechbot@19.16-dial.augustakom.net
% wknight8111 has joined #parrot
<dalek> r27156 | coke++ | trunk:
<dalek> : [docs]
<dalek> : Remove deleted items from the list of deprecation notices.
<dalek> : Note in the NEWS file that some of these were removed ahead of schedule.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27156
% skids has left skids!~bri@c-71-233-204-100.hsd1.ma.comcast.net
% Zaba_ has joined #parrot
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
<Coke> group hug is <reply>get off me!
<nopaste> "dakkar" at 85.45.142.2 pasted "trying classes in rakudo" (20 lines) at http://nopaste.snit.ch/12800
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<nopaste> "dakkar" at 85.45.142.2 pasted "output from 12800" (10 lines) at http://nopaste.snit.ch/12801
% Zaba_ is now known as Zaba
<dakkar> what am I doing wrong?
<nopaste> "dakkar" at 85.45.142.2 pasted "PIR for 12800" (164 lines) at http://nopaste.snit.ch/12802
<dakkar> looks like the parameter to Bar::set does not get its value, and that assigning the resulting undef is a bad idea...
<GeJ> dakkar: shouldn't that be    Line 11  method set(:$v) { $.x=$v }
<GeJ> ?
<dakkar> uh
<GeJ> .o0(Just a guess, I don't have a rakudo near me)
<dakkar> no, that marks $v as an optional parameter
<dakkar> that's what I infer looking at the generated PIR
<dakkar> this is reminding me of the times I tried to understand what gcc was doing by looking at the assembly output :)
% iblechbot has joined #parrot
% UltraDM has joined #parrot
% tetragon has left tetragon!~seneca@216.126.67.44
% MagNET has left MagNET!MagNET@Hunger.hu
% Zaba_ has joined #parrot
% rdice has left rdice!~richarddi@CPE001ff33cb98b-CM00159a01d44c.cpe.net.cable.rogers.com
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% skids has joined #parrot
% Zaba_ is now known as Zaba
% MagNET has joined #parrot
% gryphon has joined #parrot
% rdice has joined #parrot
<Coke> "remember that time you tried to drill a hole in your own head?"
<jalbo> Nast
<jalbo> Uh, sorry.
<Tene> I remember the time I tried to drill a hole in *your* head...
<Coke> ... clearly no ghostbusters afficionados.
<Tene> None, or one?
<Coke> ... pedant.
<japhb> I didn't get the Ghostbuster's reference.  I just immediately thought of a Stargate episode involving trepanning.
<Coke> ... I am a rabid stargate fan and am trying to remember which episode this is.
<Coke> ... though I did miss season five.
* japhb goes to look it up
% DarkWolf84 has joined #parrot
<japhb> Looks like season 3, episode "Demons": http://www.rdanderson.com/stargate/database/databas3.htm
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
% uniejo has left uniejo!~uniejo@langebro.adapt.dk
<Infinoid> Stargate SG-1 is one of the things on my watch-queue.
<jalbo> http://en.wikipedia.org/wiki/List_of_Stargate_SG-1_episodes
<japhb> Ah, I see there is a release date for Stargate: Continuum.  Cool.
% UltraDM has left UltraDM!~george@dasapass.avira.com
<Tene> Hm.  Looks like I'm not scheduled to teach the week of yapc::na.
<Tene> I might even have the week off.
<Tene> Now I have to actually consider going.
<Coke> dooooo it
<Tene> Is there a list of talks posted anywhere yet?
<pmichaud> Tene: I haven't seen one
<Tene> Hmm.  I wonder if I could arrange to teach in Chicago the week before, and then just stay there.
<pmichaud> parrot hackathon on sat and sunday before the conference :-)
<Tene> Although, I could just get my employer to schedule my return flight to go to Chicago instead of SLC.
<Tene> That's friday, though.
* particle arrives friday night
* pmichaud arrives saturday morning
<Tene> I also need to arrange for a place to stay.
<particle> everybody stays in the dorms
<particle> i don't know rates yet, but you can't book it anyway until next week
<Tene> Oh.
<particle> ~$40/night iirc
<Tene> Hm.
<particle> http://yapcchicago.org
<Tene> That should be possible.
<particle> the hackathon is in the dorms' common area
% dakkar has left dakkar!~dakkar@host2-142-static.45-85-b.business.telecomitalia.it
<particle> I found your resume online from awhile back. Please let me know if you’re and interested in a 6month config mgmt project in Brazil.
<particle> ...tempting...
<particle> why on earth, in a south american city of 18M people, they're looking internationally, i have no idea
* Coke arrives friday night, and is staying at the dorms, if they ever open up reg on that.
<particle> here's hoping
<particle> i'd like to get a block of rooms together, and near a common room, for us parrot hackers
<particle> pinged josh about it, but no response
<pmichaud> that would be great, yes
<Coke> I especially like the part where someone else handles that. =-)
<particle> my god, my soccer game *starts* at 9:15p tonight
<particle> anyone here use the kate editor?
* particle wonders if there's a directive syntax for kate like vim and emacs
<particle> ...similar to # vim: shiftwidth=4 expandtabs:
<pmichaud> my soccer scrimmage starts at 8:30p tonight
% ambs has joined #parrot
<particle> so, we'll start at about your halftime
<particle> er, no
<pmichaud> nope
<pmichaud> I'll be home before you even start :-)
<particle> right
<pmichaud> afk # lunch
% gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net
% gryphon has joined #parrot
<particle> can't decide if it's better as a tpf grant or microgrant
<particle> oops
% dakkar has joined #parrot
<Tene> http://conferences.mongueurs.net/yn2008/talks
<dalek> r27157 | fperrad++ | trunk:
<dalek> : [crypto]
<dalek> : - minor improvement
<dalek> : Courtesy of Jim Keenan
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27157
* Coke ponders how nice it would be to have an expansion for $Coda$ (along with the long awaited $Copyright$)
<particle> i'd settle for $Year$
% Theory has joined #parrot
<particle> since svn 1.1 i've been waiting
<dalek> r27158 | chromatic++ | trunk:
<dalek> : [src] Tidied code; no functional changes.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27158
<dalek> r27159 | chromatic++ | trunk:
<dalek> : [GC] Consolidated duplicate flag tests into a single path.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27159
<Coke> particle: I think this last release was "close".
<Coke> (to having that feature.)
<particle> so was 1.3.
<particle> svn--
<Zaba> hmm..
<Tene> Hmm... perhaps it's time for me to play with mod_parrot.
<Zaba> what will be the next parrot release? 0.6.2? 0.7?
<particle> zaba: depends on which features are implemented
<particle> we don't know the release number until near the release date
<Zaba> hm, I see.
<particle> releases are date-based, release numbers are feature-based
<Tene> Zaba: what release would you like it to be?
* particle would like 1.5
<Zaba> Tene, I don't know how exactly they are numbered.. so I can't say..
<Tene> purl: roadmap
<purl> roadmap is http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2004-11/msg00115.html
<Tene> purl: you lie!
<purl> Tene: huh?
<particle> there's a wiki page....
<Zaba> purl, that's for perl 5.10!
<purl> Zaba: huh?
<Tene> purl: parrot roadmap
<purl> Tene: excuse me?
<particle> http://www.perlfoundation.org/parrot/index.cgi?release_planning
<Zaba> Tene, I'll stick with trunk anyway :>
* Tene pondering mod_lolcode
<Zaba> Tene, a good idea
<Zaba> (except I don't use apache)
* particle thinks jhorwitz started mod_lolcode, and dropped it
<particle> you should ping him for his work so far
<particle> shouldn't be hard to do from scratch though, registry-style
<Debolaz> People who use apache for anything except maintaining legacy applications needs to be mutilated and killed. Not neccesarily in that order. Imho. :)
<Zaba> I run lighty on my server
<Zaba> since I need nothing but static content
* Debolaz uses lighty for dynamic content as well.
<jalbo> I use HTTP::Daemon
<Zaba> Debolaz, it has some problems with cgi, for example checking for extension '.cgi' instead of executable bit
<Zaba> and well I don't need anything but static stuff anyway
<Debolaz> I mostly use FastCGI.
% Ivatar has joined #parrot
% Ademan has left Ademan!~dan@h-67-101-42-224.snfccasy.dynamic.covad.net
% gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net
% donaldh has joined #parrot
% gryphon has joined #parrot
% PJMODOS has joined #parrot
<PJMODOS> e
<Tene> f
% PJMODOS has left PJMODOS!~PJMODOS@88.103.48.48
<davidfetter> heh
% itz has joined #parrot
<itz> I've found what appears to be an odd bug in perl6
<pmichaud> there are probably many of those :-)
<Tene> itz: details?
<purl> Where's the beef??
<itz> what was the paste url?
<pmichaud> nopaste?
<purl> i heard nopaste was at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://paste.husk.org/ or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or don't bother me while I'm eating
<Tene> purl: parrot roadmap is http://www.perlfoundation.org/parrot/index.cgi?release_planning
<purl> OK, Tene.
<shorten> Tene's url is at http://xrl.us/7nmt
<itz> http://nopaste.snit.ch/12804
% sjansen has joined #parrot
<Tene> purl: sjansen?
<purl> no idea, tene
* sjansen is a riddle wrapped in a mystery inside an enigma
<pmichaud> itz:  does it simply output nothing, or ... ?
<itz> maximum recursion depth exceeded
<Tene> itz: can you nopaste the PIR dump?
<pmichaud> are you actually creating an object of type Foo and invoking .print() somewhere?
<itz> yeah should have put that in the original sorry
<itz> http://nopaste.snit.ch/paste
<pmichaud> it might be a problem of having a method named 'print'
<itz> sorry there is a missing line Foo.print();
<itz> ah
<pmichaud> I think the print @foo.elems() line is acting as a recursive call
<pmichaud> (whether it *should* act that way is something I'd need to check the synopses for)
<Tene> itz: run it with parrot perl6.pbc --target=pir foo.pl
<Tene> and nopaste the output
<dakkar> is inheritance working in rakudo?
<dakkar> http://nopaste.snit.ch/12800 and http://nopaste.snit.ch/12801 and http://nopaste.snit.ch/12802 for reference
<nopaste> "Infinoid" at 96.238.213.50 pasted "error output and pir for itz's test script" (128 lines) at http://nopaste.snit.ch/12806
<pmichaud> I think there may be a bug in the way that rakudo is currently handling attribute definitions
<dakkar> pmichaud: oh
<pmichaud> I'm not sure that "is Foo" is picking up the appropriate class object, especially since the way attributes are currently handled is creating a new class object for each attribute
<itz> http://nopaste.snit.ch/12807
<pmichaud> (i.e., I'm not sure the protoobject gets updated to a new instance.)  It may be -- I haven't checked completely yet
<pmichaud> itz:  rakudo methods might be defaulting to "is export"
<dakkar> the "is Foo" maybe work, but what does not work (and I noticed just now) is that $x is made a *private* attribute
<pmichaud> has $.x always creates a private attribute
<dakkar> at least, that's what I read from the PIR (and I'm not sure I can read it correctly)
<dakkar> oh
<dakkar> with a public accessor method?
<pmichaud> yes
<dakkar> ok, so that part works as expected
<dakkar> http://nopaste.snit.ch/12802 at the end: that's the code that sets up my classes, right?
<pmichaud> yes
<pmichaud> and in looking at it here, it appears that it is doing inheritance as I would expect
<pmichaud> (not the actual code I would use, but good enough to produce what I think are correct results)
<dakkar> hmmm
<Infinoid> itz: so, it looks like the problem is that Foo.print() method is calling itself rather than the "print" builtin, right?
<pmichaud> dakkar: it's probably worthwhile to send this example to rakudobug 
<itz> is there a way of calling the "print" builtin more explicit?
<pmichaud> itz:  I don't know if it works yet, but one could conceivably do   &*print
<pmichaud> (i.e., grab the "global" print)
<dakkar> pmichaud: I'll do another couple of checks, then submit it as a bug
<pmichaud> dakkar:  that would be great, thanks
<Infinoid> I think itz's bug might be a parrot namespace issue, rather than a rakudo one
<Infinoid> comparing a standalone script's PIR to his test script's PIR, the op is the same 
<pmichaud> Infinoid: I know that at one time Parrot would automatically stick methods into the namespace
<pmichaud> Infinoid: then there was a time when it wouldn't, and I complained
<Infinoid> its just "print"($P15)  in both cases
<pmichaud> there does need to be a way to create methods that don't automatically appear in the namespace.  Last I checked that was parrot's default, but perhaps that default changed again.  I don't know how/if it was resolved.
<Infinoid> &*print plays some weird games with get_hll_global.  it seems to work, but it does require parens to be added to the test script too
<pmichaud> I think parens may be required when the & is used.  I'd have to check STD.pm and the synopses for that
<Infinoid> so, &*print(@foo.elems()) is a valid workaround
<Infinoid> and ... it prints newlines, despite being print() instead of say()
<Infinoid> pmichaud: I'd gladly add a test for the namespace thing.  any pointers on how to go about it?
<pmichaud> in pir?  I'm not sure we ever resolved what the correct behavior would be.
* Infinoid adds pdd21_namespaces.pod to his reading queue
% gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net
<pmichaud> actually, I think the question is how the :method flag is being handled in Parrot
<pmichaud> from S02:  Unlike in Perl 5, the notation &foo merely stands for the foo function as a Code object without calling it. You may call any Code object with parens after it (which may, of course, contain arguments):
<Infinoid> that's getting into IMCC territory, right?
<pmichaud> Infinoid: yes.
<pmichaud> Infinoid: anyway, I'd be curious to know how Parrot is working now
<pmichaud> so, create a class, define a method in the class, then do a lookup of the method name in the class' namespace
<pmichaud> if it returns PMCNULL, then :method isn't automatically placing the method into the namespace (good)
<pmichaud> if it returns a Sub object, then :method is placing the method into the namespace
<particle> didn't we have some discussion about :method :anon ?
<Infinoid> it pretty obviously is being added to the namespace, based on my reading of http://nopaste.snit.ch/12806
<pmichaud> particle:  discussion, yes; decision -- I don't remember
<pmichaud> I remember advocating that :method :anon would be the standard mechanism for "method not in namespace"
<Infinoid> hmm.  but the print method didn't get :anon
<pmichaud> however, we could also do that the default is method not in namespace, and :export puts it into the namespace
<pmichaud> Infinoid: right -- I don't think rakudo has dealt with the issue of exporting (or not exporting) methods yet
<particle> http://rt.perl.org/rt3/Ticket/Display.html?id=48631
<Infinoid> does there need to be a special syntax to differentiate methods from functions?
<Infinoid> (or builtins, in this case)
<pmichaud> in PIR?  We have one -- it's  :method
<particle> right.
<Infinoid> so if I hack it to add :anon, this will suddenly work? :)
<Coke> this reminds me: did we ever have a decision on class methods other than "no, we don't have those" ?
<particle> pmichaud: as per that ticket, you requested that :method also be entered in the namespace. it is.
<pmichaud> Coke:  I think it's "no, we don't have those".
<Coke> pmichaud: any idea how we're going to support languages that have that OO model?
<pmichaud> Coke:  it will depend on the language (more)
<particle> coke: derive your class from Object
<pmichaud> In the case of Perl 6, I would end up creating a protoobject for the class, and then adding the class methods to that specific instance (possibly via roles or some other)
<pmichaud> or, just use the protoobject as the invocant for a "class method"
<pmichaud> at any rate, my understanding of protoobjects and Perl 6 evolved beyond having to worry about class methods, at least for now :-)
<Infinoid> $P54 = $P53."print"()  is supposed to call a method, but  "print"($P37)  is supposed to call a standalone.  But  Foo.print :method  ends up being called in both cases here, causing the recursion exception.  That tells me :method didn't work
<Infinoid> sounds like a parrotbug
<pmichaud> Infinoid: it depend on how :method is defined
<pmichaud> Infinoid: and that's what we're saying hasn't been resolved yet
<Infinoid> ok, thanks
<pmichaud> or perhaps I'm misunderstanding what you're pointing out -- just a sec
<Infinoid> I'm mostly PIR-clueless
<pmichaud> okay, here's my guess
<pmichaud> :method "worked" in the sense that it created a method for 'print' in the class 'Foo'
<pmichaud> however, it also added 'print' into Foo's namespace.  (This is the part that is unresolved.)
<pmichaud> so, $P53."print"()   does exactly the correct thing by calling the print method
<particle> pmichaud: it's not unresolved.
<pmichaud> inside of that method we have "print"($P37)
<particle> "Kevin Tew started investigating this ticket, and he discovered
<particle> that :method subs are already being placed as entries in the
<particle> namespace by default, which is the behavior I was looking for.
<particle> So, the issue turns out to be a non-issue (for me at least),
<particle> unless we decide to make it one." --pmichaud
<pmichaud> particle:  ah.  I just hadn't gotten to the end of that post.
<pmichaud> particle:  you're correct, we resolved it as the current behavior being okay for now.  But it's no longer okay for now -- we need a way to create methods that aren't in the namespace
<pmichaud> and I'm now going to switch my position and ask that :method not place methods in the namespace by default, and that we have an explicit :export flag to get it to do so
<particle> try :method :anon. see if that works today
% Zaba_ has joined #parrot
<Infinoid> pmichaud: sorry, I'm still just trying to catch up with you guys and understand what's going on.  In the PIR for a method, if you call "foo"($P37), is that obviously a non-method invocation, or will it be translated to $P37."foo"()?
<pmichaud> Infinoid: method can be invoked in two ways
<pmichaud> $P37."foo"()  is always a method
<pmichaud> sorry
<pmichaud> $P37."foo"()  is always a method call
<pmichaud> however
<pmichaud> methods can also be treated as subs, where the first argument is the invocant
<pmichaud> thus  "foo"($P37) can also be used to invoke a method
<Infinoid> that sounds a lot like p5 :)
<Infinoid> ok, and "isa"($P37, "foo") will end up calling the isa vtable method on whatever class P37 belongs to?
<pmichaud> no
<particle> please don't use the words "vtable method". there's no such thing.
<pmichaud> not precisely
<particle> it's "method" and "vtable function"
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
<pmichaud> for "isa"($P37, "foo"), Parrot does
<pmichaud>     $P99 = find_name "isa"
<pmichaud>     $P99($P37, "foo")
<pmichaud> the (Sub) object associated with "isa" can be either a normal sub or a method -- the caller doesn't care
<pmichaud> however, the "isa" method that gets invoked depends strictly on the symbols in the current and global namespaces -- it doesn't depend on the class of $P37 at all
<pmichaud> this is different from  $P37."isa"("foo"), in which case we would grab the "isa" method that is associated with $P37
<pmichaud> in other words   "isa"($P37, "foo")   doesn't look at the type of $P37 at all (unless "isa" is defined with mmd/:multi), while $P37."isa"(foo)  never looks in the namespaces
<Infinoid> ok, thanks.  if I'm understanding correctly, that sounds like a strong argument for not listing methods in namespaces
<pmichaud> at this point I agree.
<pmichaud> particle++ # finding the earlier thread on the topic
% allison has left allison!~chatzilla@dsl-241-112-110.telkomadsl.co.za
<pmichaud> wow, :anon seems to work :-)
<pmichaud> nopaste coming up
% gryphon has joined #parrot
% gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net
% ruoso has left ruoso!~ruoso@195.23.92.2
<particle> ...as i suspected.
<pmichaud> I'm thinking that better would be to switch the default
% gryphon has joined #parrot
% contingencyplan has joined #parrot
<particle> i don't understand why you wanted it the other way around in the first place.
<particle> but, we have something that works today. should be easy to modify the code generator to support that, no?
<particle> ...then argue your case to have it flipped.
<pmichaud> I wanted it the other way because otherwise it was difficult to get a method into a namespace  (basically it involved the use of :load :init subs and some very bizarre lookups)
<pmichaud> yes, we can fix the code gen immediately
<pmichaud> ideally what I'm after now is
<pmichaud> .sub 'foo' :method                   #  creates a method, no namespace entry
<pmichaud> .sub 'bar' :method :export          # creates method, also entry as 'foo' in namespace
<pmichaud> .sub 'baz' :method :export('abc')      # creates 'baz' method, entered as 'abc' in namespace
<particle> yep
<particle> .sub 'baz' :method :export('abc') :vtable('def')
<pmichaud> although all I need for the moment is the :export flag
<cognominal> pmichaud, speaking of namespace, I am not familiar to the compilation chain to add it to regexen
<nopaste> "pmichaud" at 76.183.97.54 pasted ":anon does what we need for now (particle++)" (37 lines) at http://nopaste.snit.ch/12808
<pmichaud> uh oh, no it doesn't
<purl> oh yes it does!
<pmichaud> :anon also means it's not a method
<nopaste> "pmichaud" at 76.183.97.54 pasted ":anon doesn't do what we need for now :-( :-(" (44 lines) at http://nopaste.snit.ch/12809
<pmichaud> I'll re-open #48631 with the new recommendation
<pmichaud> or I can make a new ticket
<PerlJam> good afternoon 
<PerlJam> What's new in parrot-land today?
<pmichaud> exporting methods as subs (or not exporting them)
<Coke> pmichaud: new ticket with a see also is probably best, since you're asking for something else. =-)
<pmichaud> Coke++ # thanks
% Zaba has joined #parrot
% allison has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
<ambs> Anybody knows what means: sengsv?relse ?
<Debolaz> ambs: If danish, it means bedroom.
<ambs> yes, danish
<ambs> strange
<ambs> one room type is "standard class"
<ambs> the other is "standard 4 sengsvaerelse"
<Debolaz> Hmmm.. Yeah, that didn't quite add up.
<ambs> hehehe
* Debolaz is a norwegian, danish not the first language. :)
<ambs> hehehe
<ambs> thanks
<ambs> asking on #perl :)
<Debolaz> It seems to simply mean number of beds.
<donaldh> single bed
<donaldh> dobbelværelse 
<donaldh> presumably means double
<ambs> yes, somebody on #perl said it was a room with four beds
<ambs> although that is kind of strange
<ambs> :)
% wknight8111 has joined #parrot
* ambs sent an email to the hotel asking for information
<ambs> Debolaz, and donaldh, thanks for your help
<nopaste> "donaldh" at 213.123.171.12 pasted "definition of seng" (1 line) at http://nopaste.snit.ch/12810
<donaldh> oops http://da.wiktionary.org/wiki/seng
% lichtkind has joined #parrot
<ambs> :)
% lichtkind has left lichtkind!~chatzilla@d90-135-235-67.cust.tele2.de
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
% Theory has joined #parrot
% allison has left allison!~chatzilla@dsl-241-112-110.telkomadsl.co.za
% ambs has left ambs!~ambs@255.92.54.77.rev.vodafone.pt
% donaldh has left donaldh!~chatzilla@host213-123-171-12.in-addr.btopenworld.com
% jalbo has left jalbo!~julian@50.Red-213-96-228.staticIP.rima-tde.net
% mj41 has left mj41!chatzilla@pc-jurosz.ro.vutbr.cz
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-196-220.dynamic.mnet-online.de
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
% mj41 has joined #parrot
% skids has left skids!bri@charon.clarku.edu
% dakkar has left dakkar!~dakkar@88-149-251-148.dynamic.ngi.it
% ewilhelm has left ewilhelm!~ewilhelm@pool-71-111-48-138.ptldor.dsl-w.verizon.net
% ewilhelm has joined #parrot
% rdice has left rdice!~richard_d@CPE0014bfafbbd5-CM0011e6ecf48a.cpe.net.cable.rogers.com
<cotto_work> does anyone know offhand the revision when the perl6 fakecutable was introduced?
<cotto_work> I'm becoming increasingly certain that it never worked with c's mmd example
% particle has left particle!~particle@c-24-19-3-148.hsd1.wa.comcast.net
<pmichaud> well, the mmd stuff is quite recent
<pmichaud> I think it might have worked for a couple of revisions, and then something broke in the perl6 executable
<cotto_work> bwt, my definition of "worked" is "didn't cause a backtrace"
<pmichaud> right
<pmichaud> I think something happened to parrot that causes the fakecutable to not function properly in some cases
<pmichaud> I haven't had a chance to track it down yet, though.
<cotto_work> I'm trying to bisect it
<pmichaud> find the revision where mmd was introduced
<pmichaud> it will be on or about the date that c posted the article
<pmichaud> I have to run to dinner, bbiaw
<cotto_work> I've been trying to find the first revision where the example doesn't cause a bt
% sjansen has left sjansen!~sjansen@hq-nat2.gurulabs.com
% Juerd has left Juerd!juerd@feather.perl6.nl
% particle has joined #parrot
<cotto_work> this is beyond my skill to heal
% Limbic_Region has joined #parrot
<Infinoid> cotto_work: what does your test look like?
% skids has joined #parrot
<cotto_work> pick a revision, apply http://www.parrotvm.org/svn/parrot/revision?rev=26173, make perl6, check if it pukes on chromatic's mmd example
<cotto_work> repeat
% ruoso has joined #parrot
<cotto_work> I'm getting the impression that I'm missing something
% particle has left particle!~particle@c-24-19-3-148.hsd1.mn.comcast.net
<Limbic_Region> looks like the Win32/Cygwin and Win32/MinGW build is broke again - unless someone invalidated the bytecode - in which case.....make reaclean now
% Ivatar has left Ivatar!~graham@tu055.demon.co.uk
% ruoso has left ruoso!~ruoso@a81-84-237-159.cpe.netcabo.pt
<Infinoid> Limbic_Region: pmichaud has been removing ops, which I'm pretty sure will invalidate the bytecode
% particle has joined #parrot
% mire has left mire!~Frodo@148-169-222-85.adsl.verat.net
% gryphon has left gryphon!~gryphon@dsl-209-221-185-54.zipcon.net
<Limbic_Region> Infinoid - yeah, it built fine after the realclean
<dalek> r27160 | pmichaud++ | trunk:
<dalek> : [core]: more dead code elimination
<dalek> : * Remove STACK_ENTRY_INT, STACK_ENTRY_FLOAT, STACK_ENTRY_STRING,
<dalek> :   and STACK_ENTRY_POINTER, as they are no longer used after
<dalek> :   eliminating stack.ops .
<dalek> : * Resolves RT#52842.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27160
<Limbic_Region> any oracle gurus about that would mind answering a question in /msg ?
* davidfetter not a guru, but i've worked with the beast. what's up?
<Limbic_Region> will /msg since it is completely OT
<Limbic_Region> ok, /msg(s) sent
% DarkWolf84 has left DarkWolf84!~dwolf@89.215.234.147
% purl has left purl!purl@sentient.life
% kid51 has joined #parrot
% purl has joined #parrot
% Zaba has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% davidfetter has left davidfetter!~davidfett@start.fetter.org
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
% wolverian has left wolverian!wolverian@feather.perl6.nl
% wolverian has joined #parrot
% DarkWolf84 has joined #parrot
% Theory has joined #parrot
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.mn.comcast.net
% DarkWolf84 has left DarkWolf84!~dwolf@89.215.234.147
% zarchne has left zarchne!~michael@209.40.67.38
% cotto_work has left cotto_work!~cotto@tide536.microsoft.com
% cotto_work has joined #parrot
% DarkWolf84 has joined #parrot
% Theory has joined #parrot
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.or.comcast.net
% Ademan has joined #parrot
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
% guru has joined #parrot
% tetragon has joined #parrot
% kid51 has left kid51!~jkeen@pool-70-107-13-18.ny325.east.verizon.net
% AndyA has left AndyA!~andy@82.152.157.85
% guru has left guru!~guru@bas3-toronto02-1279723558.dsl.bell.ca
% AndyA has joined #parrot
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% contingencyplan has joined #parrot
% Psyche^ has joined #parrot
% Patterner has left Patterner!~Psyche@e177237170.adsl.alicedsl.de
% Psyche^ is now known as Patterner
<Infinoid> japhb++ # very elegant code
<Infinoid> but what's the darwin case for?  I haven't read kid51's patch in detail, but your addition seems to suggest some additional changes elsewhere
% iblechbot has joined #parrot
<japhb> Infinoid: thank you!
<japhb> Infinoid: auto::opengl needs to handle darwin separately from other *nix variants because of the '-framework' flags that are darwin-specific.  Most other library detection steps seem to be able to treat darwin as a generic *nix (or so I gather)
% Theory has joined #parrot
<Infinoid> it never seemed very clear to me whether the -framework flags were actually necessary
<Infinoid> it sounded like it worked without any linker flags at all, and decided at runtime which library to use
<Infinoid> ~the -framework option was just a way of forcing the issue
<Infinoid> -~
% zarchne has joined #parrot
<japhb> Last I heard, they weren't ... but I never saw a patch or commit from an OS X person confirming that.
<Infinoid> tetragon would know, I wouldn't.
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.or.comcast.net
<japhb> But even so, we still have to treat darwin as an exception, because I remember saying that the normal *nix -l flags *wouldn't* work.
<Infinoid> anyway, if what we have now works, I don't see any real reason not to stick with it
<japhb> so darwin would just get nothing added, I suppose.
<japhb> I don't treat it as high priority, but I'd like to confirm if the -framework flags can be dropped across all OS X & XCode releases, for two reasons:
<japhb> 1. because I don't like having flags that are known to serve no purpose; it obfuscates the truth about what is happening
<japhb> 2. The next time we have a library that gets treated as a framework in OS X, we will want to do the right thing (and save ourselves some effort trying to find the right flags)
<Infinoid> I wonder if your modification means the config plugins which don't care about darwin have to copy their "default" stuff to "darwin" now
<japhb> Nope, that's why I had the || in the my $libs line
<Infinoid> but I'm too lazy to read the patch and find out. :)
<Infinoid> great!
<Infinoid> goodnight
<japhb> You never have to specify anything other than default, actually.  :-)
<japhb> you too!
<purl> ohhh oh oh, the sweetest thing...
% Zaba_ has joined #parrot
% Zaba has left Zaba!~zaba@ip102.148.adsl.wplus.ru
% uniejo has joined #parrot
% Zaba_ has left Zaba_!~zaba@ip102.148.adsl.wplus.ru
% Zaba has joined #parrot