Camelia, the Perl 6 bug

IRC log for #parrot, 2008-02-26

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:19 slightlyoff joined #parrot
00:23 gryphon joined #parrot
01:15 slightlyoff joined #parrot
01:15 mire joined #parrot
01:15 cj joined #parrot
01:15 kid51 joined #parrot
01:15 wknight8111 joined #parrot
01:15 Limbic_Region joined #parrot
01:15 arbingersys joined #parrot
01:15 parrot-poke joined #parrot
01:15 grim_fandango joined #parrot
01:15 Ademan joined #parrot
01:15 teknomunk joined #parrot
01:15 Theory joined #parrot
01:15 po_boy joined #parrot
01:15 Coke joined #parrot
01:15 mncharity joined #parrot
01:15 integral joined #parrot
01:15 Maddingue joined #parrot
01:15 nopaste joined #parrot
01:15 marmic joined #parrot
01:15 dwave_ joined #parrot
01:15 c9s_ joined #parrot
01:15 klapperl_ joined #parrot
01:15 jq joined #parrot
01:15 dalek joined #parrot
01:15 cognominal_ joined #parrot
01:15 skv_ joined #parrot
01:15 mj41_ joined #parrot
01:15 bgeron_ joined #parrot
01:15 Alias_ joined #parrot
01:15 jjore joined #parrot
01:15 lbr joined #parrot
01:15 diakopter joined #parrot
01:15 amoore joined #parrot
01:15 buildbot joined #parrot
01:15 svnbotl joined #parrot
01:15 cotto joined #parrot
01:15 cotto_ joined #parrot
01:15 particle joined #parrot
01:15 silug joined #parrot
01:15 Dave joined #parrot
01:15 avar joined #parrot
01:15 GeJ_ joined #parrot
01:15 cout joined #parrot
01:15 nnunley joined #parrot
01:15 bphillips joined #parrot
01:15 ewilhelm joined #parrot
01:15 jdv79 joined #parrot
01:15 arcady joined #parrot
01:15 kismet joined #parrot
01:15 peepsalot joined #parrot
01:15 Crassworm joined #parrot
01:15 shamu joined #parrot
01:15 TimToady joined #parrot
01:15 lidden joined #parrot
01:15 rblackwe joined #parrot
01:15 rhr joined #parrot
01:15 slavorg joined #parrot
01:15 cognominal joined #parrot
01:15 clunker joined #parrot
01:15 Khisanth joined #parrot
01:15 confound joined #parrot
01:15 spinclad joined #parrot
01:15 purl joined #parrot
01:15 workbench joined #parrot
01:15 leo joined #parrot
01:15 Piper joined #parrot
01:15 pmichaud joined #parrot
01:15 PerlJam joined #parrot
01:15 jonathan joined #parrot
01:15 jrockway joined #parrot
01:15 Sartak joined #parrot
01:15 rjbs joined #parrot
01:15 Tene joined #parrot
01:15 BitPoet joined #parrot
01:15 tewk joined #parrot
01:15 zostay joined #parrot
01:15 zev joined #parrot
01:15 drforr_ joined #parrot
01:15 pfig joined #parrot
01:15 cxreg joined #parrot
01:15 dngor joined #parrot
01:15 wolverian joined #parrot
01:15 Juerd joined #parrot
01:15 TonyC joined #parrot
01:15 MagNET joined #parrot
01:15 pjcj joined #parrot
01:15 szbalint joined #parrot
01:15 shorten joined #parrot
01:24 nopaste "kid51" at 70.107.2.179 pasted "from: http://svn.perl.org/parrot/branches/tci​f/lib/Parrot/Configure/Options/Test.pm" (24 lines) at http://nopaste.snit.ch/12395
01:24 shorten nopaste's url is at http://xrl.us/bgrbk
01:25 kid51 Hmm, wrong channel for that paste.
01:43 Andy joined #parrot
02:20 Theory joined #parrot
02:48 DarkWolf84 joined #parrot
02:49 svnbotl r26063 | petdance++ | trunk:
02:49 svnbotl : a little consting
02:49 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=26063
02:49 Andy 3yay me!
03:30 Tene yay andy!
03:33 Tene For c99, we can steal the locally installed C preprocessor.  We don't care about supporting platforms with no C preprocessor, right? ;)
03:53 cj joined #parrot
04:04 Patterner joined #parrot
04:06 slightlyoff joined #parrot
04:14 mire joined #parrot
04:23 cotto Hmmm.  I'm noticing that my PHPArray PMC has more loc than the biggest of the built-in PMCs, and I've still got about 20 methods to implement.
04:23 cotto Something's not quite right.
04:29 Andy Is anyone doin' work in Eclipse?
04:39 grim_fandango joined #parrot
05:00 x joined #parrot
05:01 nina29 joined #parrot
05:10 mire_ joined #parrot
05:38 Theory joined #parrot
05:53 svnbotl r26064 | petdance++ | trunk:
05:53 svnbotl : Modified some function parameter modifiers
05:53 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=26064
06:07 Theory joined #parrot
06:13 Ademan joined #parrot
06:39 mire_ joined #parrot
07:14 uniejo joined #parrot
08:05 dduncan joined #parrot
08:08 dduncan I don't know if this is a known problem, but with the new Parrot 0.5.3 on CPAN, I find that the make is just stopping at certain times, where a ctrl-c unsticks it ... the first place is in perl Configure where it is checking for exuberant ctags ... system is Mac OS X Intel 10.5.2
08:08 dduncan I didn't have any such problems with Parrot 0.5.1 on slightly older OSs
08:08 dduncan 10.5.1 I think
08:09 dduncan is this known or should I try and narrow down a test case?
08:09 dduncan it also froze at a point during make
08:09 dduncan froze as in CPU usage is none, either case
08:11 iblechbot joined #parrot
08:21 cognominal_ dduncan, I get that problem wen I get parrot with git, another when I get it with svk, it runs fine when I use rsync or svn.
08:22 cognominal_ I have so much to read to get in speed that I don't bother to investigate right now.
08:22 dduncan in my case, I'm using the CPAN package
08:22 dduncan no worries
08:23 dduncan still if the cause is yet unknown, I could help more by trying 0.5.1 again under the current OS, to help rule out that the OS change was the problem
08:23 cognominal_ also the prompt when using rakudo interactively has disappeared
09:15 lathos How's Parrot at cross-compiling?
09:15 lathos Or being cross-compiled.
09:21 lathos Oh, heck, looks like I'm going to need a native compiler anyway. Stupid stuff time.
09:30 ruoso joined #parrot
09:37 contingencyplan joined #parrot
09:42 cognominal_ lathos: parrot is VM that can be JITted, I don't understand where cross-compiling fits here
09:42 wknight8111 joined #parrot
09:57 lathos I know what Parrot is. I don't know how to compile it for a machine I'm not currently running.
09:59 AndyA joined #parrot
10:02 lathos Ah well, here we go: Links are now set up to build (on i386-apple-darwin9.0.0) a native compiler for arm-apple-darwin.
10:02 lathos This can only end in tears.
10:11 mire_ joined #parrot
10:12 dduncan left #parrot
10:25 svnbotl r26065 | fperrad++ | trunk:
10:25 svnbotl : [WMLScript]
10:25 svnbotl : - add a pod coda
10:25 svnbotl r26066 | fperrad++ | trunk:
10:25 svnbotl : [Lua]
10:32 svnbotl r26067 | fperrad++ | trunk:
10:32 svnbotl : [Lua]
10:32 svnbotl :  - PCM LuaThread : add getfenv/setfenv methods
10:32 svnbotl r26068 | fperrad++ | trunk:
10:32 svnbotl : [emacs]
10:55 mire__ joined #parrot
11:20 mire_ joined #parrot
11:29 mire__ joined #parrot
11:41 svnbotl r26069 | jonathan++ | trunk:
11:41 svnbotl : [rakudo] Make it so you can write expressions such as my $x = <-> $y { ... }. Note that it should work for -> as well as <->, but at the moment the first is a parse error; my guess is that it's going for prefix:- rather than the longer token ->.
11:41 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=26069
11:54 svnbotl r26070 | jonathan++ | trunk:
11:54 svnbotl : [rakudo] Make .foo call $_.foo.
11:54 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=26070
12:01 kid51 joined #parrot
12:12 lbr lathos: iphony parrot?
12:20 GeJ joined #parrot
12:42 dwave joined #parrot
12:49 svnbotl r26071 | fperrad++ | trunk:
12:50 svnbotl : [Lua]
12:50 svnbotl :  - fix PMC LuaThread (sorry)
12:50 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=26071
12:54 cognominal_ jonathan, in grammar.pg,   is :name('$def'), some kind of placeholder?
12:54 lathos iphony parrot indeed.
12:55 lathos And my native-compiler build didn't work. Not sure why not though, but I don't have much more time to play with it.
13:00 wknight8111 joined #parrot
13:13 kj joined #parrot
13:38 anna30 joined #parrot
13:50 cognominal_ joined #parrot
13:59 Coke lathos: thank you for not abusing the young ones. =-)
14:00 Coke I think you're the first person who's tried to cross compile. or at least, all the others failed and ran away never to be heard from again.
14:00 Andy joined #parrot
14:00 cj joined #parrot
14:00 arbingersys joined #parrot
14:00 diakopter joined #parrot
14:00 buildbot joined #parrot
14:00 cotto joined #parrot
14:00 cotto_ joined #parrot
14:00 bphillips joined #parrot
14:00 ewilhelm joined #parrot
14:00 peepsalot joined #parrot
14:00 shamu joined #parrot
14:00 rhr joined #parrot
14:00 purl joined #parrot
14:00 workbench joined #parrot
14:00 Piper joined #parrot
14:00 pfig joined #parrot
14:01 Piper joined #parrot
14:01 Piper Hi there.  I am Piper.  I am now publicly logging this channel.  If you don't want to be logged, please leave now.
14:04 jhorwitz joined #parrot
14:05 gryphon joined #parrot
14:12 lathos Coke: It's not possible with Configure in its current form, since it tries to run the C programs it compiles. Which obviously won't work on a cross-compiler.
14:15 kj anybody who knows what this means: "positional inside named args at position 2" ?? I keep getting this when trying to parse string literals.
14:29 silug joined #parrot
14:34 particle kj: it's a pcc error
14:35 particle lathos: i believe you can manually create a Parrot::Config::Generated with the values you want... but you may also need to create config.fpmc and config.h
14:35 kj I thought so; I have a language that has a rule quote, generated by the mk_language_shell script
14:36 kj but somehow it's failing on that. If i replace <string_literal: "> by <-["]>, it goes away
14:36 kj obviously, I just want to use the built-in string_literal rule
14:38 kj it seems there's something wrong with string_literal, but OTOH, that's hard to imagine, as it's so widely used, and apparently noone else has had problems
14:42 particle this is before pir is generated?
14:43 kj yeah
14:44 particle do you mean to use quote_expression?
14:45 kj ehm. not sure what you mean.
14:45 kj I just used mk_language_shell
14:45 kj and then extended that generated grammar
14:45 particle <quote_expression: ...> .... ah.
14:45 kj (trying to implement the example language for the DLR, ToyScript)
14:46 kj mostly done, butthe operator table doesn't like me today, and string handling doesn't work
14:46 pmichaud good morning
14:46 purl Is it morning again?  YAWN...
14:46 kj morning
14:50 ruoso joined #parrot
14:57 pmichaud particle++ # removing fudge-deprecated compiler directives
14:58 particle i'd like to have the time to do real work on rakudo :(
14:59 pmichaud me too.  I'm hoping things clear up this week.  But it's not looking promising :(
15:00 kj ah. note to self: DO NOT name a rule "new"
15:01 kj *i knew it*
15:01 pmichaud yes, I need to get PGE to use MMD for the rules it generates
15:02 kj I was planning to check out the DLR, but I got distracted by their example language, toyscript. figured it'd be nice to know what is easier to use: PCT or DLR's stuff
15:03 Andy joined #parrot
15:04 cognominal_ joined #parrot
15:09 wknight8111 have the parrot group applied to google's summer of code?
15:09 wknight8111 or would that be through the perl foundation?
15:09 particle tpf
15:09 pmichaud in the past we've done it via tpf
15:10 wknight8111 that's what
15:10 wknight8111 i've figured
15:10 purl That's *WRONG!*
15:10 wknight8111 sorry purl
15:15 camgirl29 joined #parrot
15:15 lola22 joined #parrot
15:16 lathos Whoa, who made this #spambot?
15:22 iblechbot joined #parrot
15:28 Tene Aw, lathos scared away the camgirl.
15:39 particle jhorwitz: poke
15:39 jhorwitz particle: ouch
15:40 particle I CAN HAZ MOD_LOLCODE??
15:41 Tene A friend that I'm visiting in Detroit is trying to persuade me to give a presentation on Parrot at penguicon.
15:41 jhorwitz I CAN HAZ TUITS?  :)
15:41 pmichaud presentation++
15:42 particle VISIBLE TUITS
15:42 kj pmichaud: when running a langauge on a command line, would it be useful to have a special TOP rule for that?
15:42 pmichaud kj:  I don't quite understand
15:42 jhorwitz particle: thanks!
15:43 kj well, when you run a language on a commandline, so in interactive mode...
15:43 jhorwitz particle: i can slap together a registry-style lolcode pretty quickly
15:43 kj there's usually some special rules available
15:43 kj for instance, handling line-oriented languages
15:43 kj and some languages print the result
15:43 kj so for instance, python, when entering "42", it will print the result
15:43 pmichaud languages/abc does that
15:44 pmichaud so does languages/APL
15:44 kj let me check if that's what i'm thinking of.
15:44 pmichaud well, the real tricky part to interactive mode is being able to deal with multi-line inputs
15:45 kj right, handling for instance the "\", (to continue on the next line)
15:45 pmichaud well, in some interactive modes there isn't even a \
15:45 pmichaud (for some languages)
15:45 kj yeah. right.
15:45 particle jhorwitz: registry-style is enough for now
15:45 pmichaud they just know based on context that there's more to get
15:45 kj right. for instance, Lua i think will print the 2nd commandline prompt, which is "..." instead of ">>" (or somehting like that)
15:46 pmichaud at the moment I'm encouraging such things to be handled in hll-specific subclasses of HLLCompiler, rather than try to get HLLCompiler to handle it.  At least until we have an idea of a generic way of doing it.
15:46 Tene How possible would it be to implement something like "This text started to match this rule, but ran out of input" and throw a resumable exception that can be resumed when there is more input to continue matching?
15:47 pmichaud might be able to do something in the <ws> rule
15:53 Tene I might have hacking time tonight... was too exhausted last night when I finally got back to my hotel.
15:54 pmichaud essentially I think that <ws> could detect end-of-input and throw an exception that gets caught by the interactive mode of HLLCompiler.  The interactive mode could then get more input, add it to the source string (this part might be tricky), and then resume the match from where it left off.
15:54 pmichaud actually, as I'm thinking about it, this is a *really* good idea
15:55 pmichaud in fact, we might not even need the exception, since matching is resumable
15:55 pmichaud although the exception makes it a bit easier to track
15:59 peeps[work] joined #parrot
16:12 marmic joined #parrot
16:35 svnbotl r26072 | kjs++ | trunk:
16:35 svnbotl : [c99] minor grammar fixes.
16:35 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=26072
16:49 Coke Folks, I will be in meetings this afternoon and will have to miss parrotsketch.
16:51 Coke pmichaud: HLLCompiler stuff ; that's basically what tcl is doing now.
16:51 Coke real tcl (not sure about partcl) goes further and changes the prompt for secondary input.
17:01 Theory joined #parrot
17:25 * Coke yawns.
17:26 * Tene props Coke's mouth open with a blue marker.
17:26 cotto__ joined #parrot
17:26 * Coke yawns totorically.
17:27 parrot-poke joined #parrot
17:34 cotto_ joined #parrot
17:44 Theory joined #parrot
17:49 Theory joined #parrot
17:50 kjs_ joined #parrot
17:53 Psyche^ joined #parrot
17:53 kj joined #parrot
18:06 sjansen joined #parrot
18:07 TimToady pmichaud: I've just added a <vws> rule to STD that makes it possible to capture control at the vertical whitespace boundary via either context var or method override.
18:09 Theory_ joined #parrot
18:20 barney joined #parrot
18:26 pmichaud TimToady: excellent
18:27 jonathan hi all
18:27 pmichaud hello, jonathan.  some terrific patches to rakudo this week -- thanks
18:29 jonathan pmichaud: Welcome, it's fun.
18:29 jonathan Am sure some will need tweaks...
18:30 spinclad #ps?
18:30 purl i guess #ps is where I can say "okay, these issues are really troubling/annoying/blocking"
18:30 jonathan I'm pondering working towards refactoring the type hierarchy so we have stuff under Any.
18:30 pmichaud well, when I first looked at most of them I thought "oh, that's not quite right -- need some tweaks"... then after starting to add the "tweak" I said "oh, it's right after all."
18:30 spinclad purl, #ps is also #parrotsketch, where committers can talk and bystanders can listen
18:30 purl okay, spinclad.
18:31 jonathan I've been meaning to do that for a while, and keep putting it off in favor of easier stuff. :-)
18:32 pmichaud there's quite a bit of object/class refactoring that needs to be done
18:33 jonathan Aye.
18:33 pmichaud I looked at .HLL mapping on the trip to brussels, and decided we can't really do it effectively until we get all of the class stuff cleaned up
18:33 pmichaud so, getting classes implemented more properly is high on my list
18:33 chromatic joined #parrot
18:33 jonathan Examples of what needs cleaning up?
18:34 jonathan I may be able to do some bits of that.
18:34 pmichaud well, I don't like having the "!keyword_has" methods in Object.  They work for now, but class construction really needs a more holistic view
18:34 pmichaud in particular, we need to make sure that protoobjects are created after each of the attributes are added
18:34 pmichaud (or after all of the attributes are added)
18:34 pmichaud maybe that's happening already, but it didn't look like it on my first scan
18:35 chromatic #ps time
18:35 jonathan I had to make sure instantiation was after attributes.
18:35 jonathan oops
18:35 jonathan I had to make sure the protoobject was created after all the attributes where added.
18:35 jonathan If you add more after the call to make_proto, you get a "class already instantiated" error.
18:36 pmichaud correct
18:36 jonathan OK, that's what I *think* I've implemneted.
18:36 pmichaud I want to clean up make_proto to be able to handle that more cleanly also
18:36 pmichaud anyway, Object/Any just need a re-think
18:36 jonathan Any isa Object, and Any is what things inherit from by default?
18:37 jonathan Other than Junction?
18:37 pmichaud yes, but I also mean for the private methods
18:37 pmichaud i.e., what methods exist for creating new classes, adding attributes, establishing protoobjects, etc.
18:37 jonathan Ah, the !has_keywords and make_proto stuff?
18:37 pmichaud yes
18:38 Tene orite, it's tuesday.
18:41 jonathan I was going on S12's mentioning that the meta-class was responsible for evaluating the keywords in a class definition.
18:41 jonathan But it felt a bit hand-wavey.
18:41 pmichaud oh, I hadn't seen that.  Is it newish?
18:41 jonathan Don't think so.
18:42 pmichaud I'll have to go and look for that.
18:42 jonathan "In either case, the code represented by ... executes at compile time as the body of a method of the metaclass, which is responsible for interpreting the keywords of the class definition. (And since a class is also a module, it also handles any module-oriented keywords. You can export subs from a class at "use" time, for instance.)"
18:42 jonathan In the Classes section, really near the start.
18:42 pmichaud ah
18:42 jonathan Well, the classes section is near the start. That paragraph is towards the middle/end of the classes section.
18:43 jonathan I can't find anything more specific, but I figure that this is the way that you get to implement your own class system.
18:43 pmichaud my reading caught the "executes at compile time" part but missed the "as the body of a method of the metaclass"
18:43 pmichaud "executes at compile time" is the same for module bodies as well
18:45 chromatic (Broke MANIFEST) -- he's one of us now!
18:45 Theory joined #parrot
18:45 jonathan I'm not entirely sure what the "as the body of the metaclass" really means.
18:46 pmichaud as the body of a method of the metaclass :-)
18:46 particle i'm sure TimToady's lurking and will help clear up the spec
18:47 jonathan Ah, a method of...
18:47 jonathan Which method? :-)
18:47 pmichaud we get to define that :-)
18:47 jonathan Aha.
18:47 pmichaud at least, so far we get to define it :-)
18:47 jonathan I say we define some worker methods like keyword_worreva too. ;-)
18:48 pmichaud I see now where you came up with "!keyword_has" though
18:48 pmichaud that clears things up for me a bit, so I can review with that in mind
18:48 jonathan Sure. It's one of my "it may not be right, but it should be in the right kinda direction" things.
18:48 pmichaud anyway, I need to refactor Object and Protomaker and a few other items in order to work well with .HLL, so I'll probably tackle Any at the same time
18:49 pmichaud also I want to get rid of Perl6Str and just make it Str
18:49 particle need hll for that
18:49 TimToady really, all that's trying to say is that somebody somewhere has to decide what words like "has" mean, and that's probably the metaclass somehow
18:49 TimToady since, for instance, a role provides a different meaning of "has" that delays interpretation to composition
18:50 * particle wonders if trait_auxiliary:is can be easily made to support 'is export'
18:50 pmichaud which means that jonathan's implementation is following the spec
18:50 pmichaud so, jonathan++, again
18:50 pmichaud TimToady: your explanation makes sense, thanks
18:50 IllvilJa joined #parrot
18:51 TimToady and in theory a user can define a "myclass" keyword that redefines even the keywords that are recognized inside, but then we're actually tweaking syntax, not just retargeting semantics
18:51 jonathan particle: I think is export is not hard; I demonstrated how it can be done before.
18:51 TimToady and, in fact, in the current grammar, "has" is recognized everywhere, but just has no meaning outside of class/role
18:52 pmichaud TimToady: would "has" outside of a class or role toss an exception?
18:52 jonathan I guess compile time error?
18:52 TimToady yes
18:52 pmichaud same for things like "method"?
18:53 TimToady and sub, and pretty much all declarators
18:53 jonathan TimToady: Should you be able to write "self" and $.foo outside of a class or role definition?
18:53 pmichaud well, "sub" is good inside of any block, isn't it?
18:53 jonathan Like, $x = -> { self.bar(); }; $obj.$x();
18:53 TimToady sure, but that just means there's always a way to interpret it
18:54 TimToady something is doing the declarational semantics at compile time somewhere
18:54 chromatic vague!
18:54 spinclad but precisely vague
18:55 TimToady jonathan: sure, you can write self outside of a method, if you want an error :)
18:55 jonathan A compile time one?
18:56 TimToady we know the signature of the current &?ROUTINE, so we know whether it has an invocant parameter
18:56 jonathan Ah, good point.
18:56 TimToady so I would think it would be detectable at compile time pretty easily
18:56 jonathan OK.
18:57 TimToady I don't think we want to go down the route of self being so smart it outsmarts the optimizer
18:57 jonathan Agree.
18:57 jonathan I need to re-do the way "self" works.
18:57 pmichaud well, PCT needs a good representation of "self", also
18:57 jonathan The current way I implemented it is...very...wrong.
18:58 pmichaud I haven't decided if "self"  is  a ::Val,  ::Var, or ::Op
18:58 jonathan Though I only just realized that.
18:58 TimToady and $.foo is just rewritten to $(self.foo)
18:58 jonathan Sure, that's what I implemented it as; both should make the same PAST.
18:58 jonathan But $.foo(...) doesn't work yet.
18:59 jonathan Need to peek at STD to see how it's parsed.
18:59 TimToady on export, with pugs we found it convenient to simply alias the exported item into a subpackage with the same name as the export tag
18:59 TimToady then importing a tag is simply reading the symbols out of the subpackage
19:00 TimToady and aliasing those into the current context
19:01 TimToady besides being simple, makes it really easy to introspect the subpackage
19:01 TimToady perhaps we could refine that
19:01 Tene parrot-poke?
19:02 TimToady given the tweak I just made to S11
19:02 chromatic parrot-poke 53280, 0
19:02 TimToady all tagsets could alias to Interface::TAG
19:02 pmichaud mmmmm
19:02 TimToady so that the Interface subpackage is all of the collected external interface in one spot
19:03 TimToady much like Ada separates into externals and internals
19:03 TimToady but Ada forces this on the user
19:03 TimToady whereas we just distribute the info via "is export"
19:03 TimToady and let the compiler pull out the interface for us
19:03 pmichaud I like
19:04 TimToady maybe Export::MyTag and such
19:04 TimToady or better, export::MyTag
19:04 * jonathan thinks there is more to "is export" than creating a multi-sub from a method
19:04 TimToady to not conflict with user-define subpackages that are generally capitalized
19:05 TimToady I suspect multies are automatically exported
19:06 TimToady probably...
19:06 TimToady is export is for other stuff that wouldn't automatically be exported
19:06 jonathan Aha, OK.
19:06 particle to prevent that, you'd do is !export??
19:06 jonathan I only remember the reference to it in S12.
19:07 TimToady there's no spec about autoexporting multis
19:07 chromatic It depends on how multi the multi is.
19:07 jonathan "However, you may use is export on a method definition to make it available also as a multi sub."
19:07 TimToady lemme think about that a bit more
19:07 TimToady yes, ordinarily a method is not exported
19:08 TimToady so it falls into the "ordinarily not exported" case
19:08 TimToady methods don't need to be exported to another symbol table
19:08 TimToady since the dispatcher can find them right where they are
19:08 TimToady (given appropriate typology)
19:09 particle only my method (...) { ... }
19:09 Tene Does anyone think that diagrams like http://pleasedieinafire.net/~tene/perl6.png are useful enough that it would be a good use of time to write a script to generate directly from grammar definitions?
19:10 pmichaud depends on how hard it is to write the script :-)
19:10 TimToady it's possible we shouldn't overload "is export" on methods
19:10 particle shouldn't be too hard to write
19:11 TimToady and use "is multi" or some such
19:11 pmichaud there are some rule calls that aren't "obvious" from a simple reading of grammar.pg
19:11 TimToady but we probably want to discourage aliasing of methods into other classes
19:11 pmichaud for example, rules written in PIR
19:11 pmichaud but if there's a way to have those manually added to the ones automatically found in grammar.pg, it'd probably work
19:11 particle approximations are better than nothing
19:11 TimToady people should use roles to write generic methods, not method aliases
19:12 TimToady biab &
19:12 particle pmichaud: and the pir rules could be colored or have a dashed border to show that they may be incomplete
19:12 parrot-poke Tene: question for me? I'm just a hanger-on so far who only plays with stuff, but very interested in parrot and rakudo
19:12 Tene parrot-poke: I was just curious about who you were.  The name seemed to suggest a utility bot of some sort.
19:13 particle ...until there's a better parser.
19:13 Tene particle: that would be completely possible, especially if they're manually added.
19:14 * particle has created DAGs from free-form data before
19:14 pmichaud there aren't that many "manually added" ones
19:14 pmichaud mostly having to do with quote rules
19:15 Tene I have three or four hours per day while I'm teaching class that I'm just idly sitting around while students work on labs.  I haven't been able to do real parrot work then, though, as I always have to have some minimal concentration focused on watching for signals from students.
19:19 TimToady oh, hey, it's already specced to use the EXPORT module, so some earlier me already thought of this. :)
19:19 TimToady s/module/subpackage/
19:20 jonathan TimToady: Which synopses?
19:21 particle tene: you should probably weight TOP so it shows up first
19:22 TimToady S11 "Exportation"
19:29 jonathan Thanks, will try and get that stuff into my head.
19:30 pmichaud me too
19:30 particle *phew* then i can ignore it for a while
19:30 particle :)
19:30 pmichaud I have to figure out how to match it with what we're doing in Parrot
19:30 pmichaud but that just takes a bit of thinking time
19:31 pmichaud oh, I had a STD.pm question
19:31 pmichaud any particular reason that  anglewords and shellwords aren't using quotesnabber?
19:44 svnbotl r26073 | kjs++ | trunk:
19:44 svnbotl : [docs] update pct docs to mention 'infix:<<' as a way of writing instead of french quotes, which are hard to write.
19:44 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=26073
19:45 jonathan pmichaud: Did you see my commit message about the -> parse issue?
19:46 jonathan No hurry on it, just wanted to make sure you'd spotted it, because I think you'll be able to deal with it much more easily than i could.
19:48 wknight8111 joined #parrot
19:57 svnbotl r26074 | bernhard++ | trunk:
19:57 svnbotl : [Plumhead]
19:57 svnbotl : Update notes about Plumhead antlr3.
19:57 svnbotl : Regenerate Java classes with antlr.3.0.1
19:57 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=26074
20:00 dngor joined #parrot
20:01 cognominal_ joined #parrot
20:07 schmalbe joined #parrot
20:13 TimToady pmichaud: just removed anglewords and shellwords entirely; quotesnabber(":qq",":ww") and such should be supplying the proper split semantics
20:13 TimToady thanks
20:14 workbench joined #parrot
20:20 TimToady (also, the circumfix defs were redundant with the quote defs)
20:23 pmichaud TimToady:  yay!
20:23 pmichaud you have no idea how happy that makes me :-)
20:24 svnbotl r26075 | chromatic++ | trunk:
20:24 svnbotl : [src] Improved performance of utf8_set_position() by about ten percent.
20:24 svnbotl : Avoided calling it from the two hottest paths in NQP when unnecessary.
20:24 svnbotl : The result is that generating Rakudo's parser actions is a whopping 2.5%
20:24 svnbotl : faster.  Further improvements may have to come from upgrading to fixed-width
20:24 TimToady pmichaud: yes I do :P
20:25 chromatic Can you kill variable-width encodings too?
20:25 pmichaud he did -- see S02.
20:25 chromatic and I quote: yay
20:25 pmichaud Parrot just hasn't caught up with it yet. :-P
20:25 pmichaud chromatic: what files changed for your utf8 patch -- was it encodings/utf8 ?
20:26 chromatic Yes.
20:26 pmichaud okay, good, we shouldn't conflict then
20:26 chromatic A quarter of the time we spend generating PIR from NQP when building Rakudo goes into skipping ahead in UTF-8 strings.
20:28 chromatic ... but now it's time to try to profile PIR.
20:30 pmichaud well, I'm not surprised at the skipping-ahead cost -- every 'substr' operation essentially requires a skip
20:30 chromatic I tried to reduce the need for some of those.
20:30 pmichaud converting to fixed with should be a huge improvement
20:30 chromatic Definitely.
20:30 purl Absolutely!
20:30 pmichaud *width
20:31 chromatic I even unrolled a loop by hand to see if there were any possible improvements there.
20:31 chromatic (made things worse)
20:54 Coke chromatic++
20:57 chromatic For making things worse?
20:57 chromatic We'll call that the Tcl syndrome.
21:01 Coke no, for the speed improvements.
21:01 Coke I despair of tcl ever passing all tests in two concurrent releases.
21:02 chromatic It's a huge wad of code right now.
21:02 Coke yesssss?
21:05 chromatic I just have an easier time profiling and fixing bugs that Rakudo or Pheme tickle than I do Tcl or Lua bugs is all.
21:06 Coke ah. yup.
21:06 Coke chromatic: when I get [oops; continuation 0x75a3f8 of type 23 is trying to jump from runloop 530 to runloop 1]
21:06 Coke ... what does this mean to me, the HLL implementor.
21:06 chromatic Something's wrong in Sub, Continuation, or RetContinuation.
21:07 Coke so, I'm tcling a bug in parrot, then?
21:07 chromatic Almost certainly.
21:07 purl somebody said almost certainly was likely probably causing some problems, maybe
21:07 chromatic Unless you have a TclSub PMC or something.
21:07 jonathan I see that in Rakudo occasionally, too.
21:07 Coke chromatic: ... i do1
21:07 chromatic rgrjr's probably the best one to ask, then leo.
21:08 chromatic I looked at the context code and fled for the relative safety of the GC.
21:08 chromatic ... which should scare even you.
21:08 Coke it's a PIR subclass of Sub.
21:08 chromatic No fiddling with the gooey pink innards of the C data structure inside Sub?
21:08 Coke nope. just adding attributes to a sub.
21:09 chromatic That's probably not it then.
21:09 Coke (like "here's my HLL source".)
21:09 Coke Ok.
21:09 jonathan If it's any help, I only ever saw it in Rakudo on an exception throw.
21:09 chromatic For annotation on a wiki or in documentation somewhere: the easiest way to debug Parrot problems from an HLL is to dump the HLL source to PIR, then cut down the test case based on that.
21:10 chromatic Yeah, exceptions do weird things with contexts.
21:10 jonathan I suspect that'll be where the bug is.
21:11 Coke chromatic: for HLL's that use the PCT, sure. =-)
21:11 chromatic For all HLLs.
21:11 chromatic Unless the HLL calls Parrot's C functions directly, it has to generate PASM or PIR somehow.
21:12 Coke yes, but if they're not using PCT's, it no longer is the "easiest" way, necessarily, from the HLL tsandpoint.
21:12 Coke But yes, certainly, if we can provide a PIR example, surely.
21:14 chromatic Sure, I'm sympathetic to that point of view.
21:14 kj any lolcode developers around?
21:15 Coke vaguely.
21:15 kj i'm missing a file builtins/math.pir
21:15 kj is it me, or is it just missing
21:16 Coke I blame Tene!
21:16 Coke (yes, I don't see it in src/builtins/math.pir here on a recent update)
21:16 kj i just updated. nothing.
21:17 * Tene looks
21:17 cotto__ joined #parrot
21:18 Tene I guess I forgot to commit it?
21:18 Tene That doesn't seem likely.
21:18 kj RLY
21:18 kj well. it's not here :-)
21:18 Tene I thought I remembered seeing it...
21:18 Coke perhaps you forgot to svn add it?
21:19 Coke (in which case the commit would happily ignore it.)
21:19 Tene Looks like.
21:19 purl looks like is a type of verb
21:19 Coke purl, forget looks like
21:19 purl Coke: I forgot looks like
21:19 Coke chromatic: if I use tcl's --pir option, I can't seem to regenerate my runloop error.
21:20 Tene 'kay, I'll commit it shortly.  Thanks, kj.
21:20 chromatic Those are the ones I hate the msot.
21:20 chromatic most
21:22 particle where's our disassembler?
21:22 kj tene: istr lolcode had a try/catch using "oh noes" or whatever syntax. guess I'm wrong
21:24 Coke wtf. I had, apparently, an unneeded clone that was screwing me up.
21:24 chromatic Or it could be that.
21:28 jonathan Hmm. We have...
21:28 jonathan INTVAL does(STRING* method)
21:28 jonathan But not a does_pmc variant of that.
21:28 jonathan Like isa and isa_pmc
21:28 svnbotl r26076 | bernhard++ | trunk:
21:28 svnbotl : [Plumhead]
21:28 svnbotl : Slight beautification of GenPastPir.g
21:28 svnbotl : Regenerate Java code with antlr
21:28 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=26076
21:36 Tene http://pleasedieinafire.net​/~tene/generated_perl6.png
21:36 Tene generated by:
21:36 Tene http://pleasedieinafire.net/~tene/gg.pl
21:37 Tene Someone propose a syntax for comments to indicate a PIR call to a rule.
21:40 Coke chromatic: found another place where I'm getting the runloop error.
21:40 Coke (same error, found another way to trigger it.)
21:40 chromatic It's because you're calling clone too many times again.
21:40 svnbotl r26077 | bernhard++ | trunk:
21:40 svnbotl : [Rakudo]
21:40 svnbotl : Rakudo does not use PAST-pm, so don't mention it in ROADMAP.
21:40 svnbotl r26078 | tene++ | trunk:
21:40 svnbotl : Oops.  Forgot to add builtins/math.pir for lolcode.
21:40 svnbotl : kj++
21:40 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=26078
21:41 Coke but I can only trigger it in interactive mode, or when using tcl.pbc; if I generate the pir and run that, I get the expected exception.
21:41 chromatic Curious.
21:41 * purl gives the small curious key to Bilbo. Thorin sits down and starts singing about gold.
21:41 Coke most curious.
21:42 chromatic One difference between PBC and PIR is that what we thaw out of PBC may not always completely match what's in memory as PIR.
21:42 chromatic ... if we don't restore as constant.
21:42 jonathan On Rakudo, it only ever occurs in interactive mode too.
21:43 chromatic The way to debug that is to catch the exception in gdb, figure out which thing is getting called incorrectly, and then trace whatever creates that PMC to figure out where it gets created and why.
21:43 chromatic My guess is that it'll get created from thawing PBC and it should be constant.
21:43 chromatic But that's just a guess.
21:44 Coke good thing I use a custom op to throw my exception. should make it easy to gdb.
21:46 nopaste "coke" at 72.228.52.192 pasted "?" (4 lines) at http://nopaste.snit.ch/12401
21:47 Coke ah. should have stepped instead of nexted.
21:48 chromatic A cast to nothing?
21:48 chromatic or is the expression on the next line?
21:48 leo chromatic: I'd recommend to just for now ignore that constant flag on PMC/String creation and sort out other (maybe) bugs first
21:48 leo hi all btw
21:48 Coke chromatic: it was on teh next line.
21:48 chromatic leo, that should prove if we're marking all PObjs appropriately anyway...
21:49 Coke Ok. the issue is in throw_exception (src/exceptions.c:567) address = VTABLE_invoke(interp, handler, exception);
21:49 Coke run that line in this scenario, and I get the runloop error.
21:49 chromatic handler may be wrong
21:49 leo the state of current constant pools is just adding another level of complexity, which isnÄ'tpropriate at this time
21:50 leo it's an optimization anyway
21:50 Coke anything in particular I could poke at in handler?
21:50 leo ignoring the flag for now is easy
21:50 leo just keep the code and fix it later
21:51 leo my 2 c
21:51 chromatic See what creates handler, and what it should be, and if it looks invalid.
21:51 chromatic leo, I'll try that.
21:51 svnbotl r26079 | bernhard++ | trunk:
21:51 svnbotl : Set svn properties for new file.
21:51 svnbotl diff: http://parrotvm.org/svn/parrot/revision/?rev=26079
21:53 leo well, some PMCs might need mark vtables which they don't have yet, because these PMCs where all constant now - but as mailed - the mark vtable is really needed (except when the marking is defaulted inside dod.c)
21:53 leo s/where/where/
21:53 leo arg were
21:54 chromatic What did you think of rgrjr's purify() idea?
21:55 cotto__ purl, karma for bernhard
21:55 purl bernhard has karma of 1489
21:55 leo as he said  their are more levels of the term "constant"
21:55 cotto__ purl, karma for Coke
21:55 purl coke has karma of 1745
21:55 leo currently just the GC issue is interesting for me
21:55 cotto__ purl, karma for purl
21:55 purl A hell of a lot more than you cotto__, that's for sure!
21:55 leo constant_pool allocation that is
21:56 leo nothing else
21:56 purl nothing else is that big
21:56 Coke purl, forget nothing else
21:56 purl Coke: I forgot nothing else
21:56 leo immutable or not doesn't change that
21:56 cotto__ purl--
21:56 purl cotto__: what?
21:56 leo _but_ a constant (GC-wise) PMC _shall_ not have non-constant items#
21:57 svnbotl r26080 | bernhard++ | trunk:
21:57 svnbotl : [lolcode]
21:57 svnbotl : Make PIR coda codingstd happy.
21:57 svnbotl r26081 | jonathan++ | trunk:
21:57 svnbotl : [rakudo] Implement smart-match for classes.
21:57 leo when it's impractical then don't allocate constant PMCs
21:57 chromatic It's the two-phase header allocation and initialization that makes this troublesome.
21:57 leo but for internal structures you know what you are doing, then you _might_ allocate _all_ children as constants too
21:58 leo if this isn't given then don't allocate constant items - of if later some shorter-lived stuff might be added or ...
21:59 chromatic Yeah, but everything that allocates children within a PMC has to check if the parent is constant and use a different allocator/initializer for the children.
22:00 leo nope - if children are added the 'adder' (inside parrot core code) has to know, if the parent is a _true_ parrot constant PMC
22:01 chromatic I think we're saying the same thing.
22:01 leo no checking and such IMHO
22:01 leo that's a matter of internal structure policies
22:01 chromatic The Sub PMC doesn't create all its children as constant right now.
22:01 chromatic Maybe that's a bad example.
22:02 chromatic The String PMC doesn't create its STRING as constant now by default.
22:02 leo last when I checked Namespace inside Sub was such a thingy
22:02 leo oh ...
22:02 leo yep
22:02 chromatic If the String PMC gets created as constant, it has to contain a constant STRING.
22:02 leo STRINGs aren't constant
22:02 leo yep
22:04 chromatic If we used rgrjr's idea, we could take a PObj we know needs to be constant and, after constructing it fully, promote it and all of its PObj children recursively to constants.
22:04 leo if there ist the slightest chance that a non-constant item might be added to a const PMC, then don't allocate that PMC as a constant - my advice
22:04 chromatic Exactly.
22:05 leo you can't prmote it - that would change the address of that PMC which is a nono
22:05 chromatic You can promote it if you're the one who created it and you know nothing else has a pointer to it yet.
22:05 Coke (tangent) (strings aren't constant) there was a proposal at one point to eliminate strings and just have Strings. Is that still on the table?
22:05 leo not without another indirection in PObj structures
22:06 leo yes, just in that case - but are still constructing that PMC and haven't returned the address of it
22:07 chromatic This would be after the construction.
22:07 chromatic When storing a Sub into the packfile structure, for example.
22:07 leo then the next instruction might have already "published" the address
22:08 chromatic PIR instruction or C instruction?
22:08 leo this looks rather error-prone to me
22:08 leo opcode
22:08 chromatic I agree, we can't do it reliably between opcodes.
22:08 chromatic I meant from the C level.
22:09 leo from C code level, the C code has to know, if a constant object shall be constructed or not - by delivering on the constant flag
22:09 leo that's it IMHO
22:10 chromatic Yes, but that pushes the responsibility of allocating all children PObjs as constant to every place in every PMC that might allocate children.
22:10 chromatic That includes dynpmcs.
22:11 leo siteds of construction of internal structures should know that policy
22:12 leo if not then just don't use constant PMCs ;)
22:12 chromatic Sure, we can publish the policy... but I don't want to debug dozens of dynpmcs that accidentally get that wrong.
22:12 chromatic I'd like to make it so easy to do the right thing that people don't even have the temptation to do the wrong thing even by accident.
22:12 leo you can check that with GC_DEBUG, if these PMCs have a mark vtable, which is walking the children
22:13 chromatic Sure, I know how to debug this type of problem.  I don't want to have to think about having to debug it though.
22:13 chromatic If we can design the system such that these types of problems never occur, even better.
22:14 leo with refcounting you got this problem on each allocation, with our GC system the problem is minimized to crate a proper mark vtable
22:14 leo but it can't reduced beyond that IMHO
22:14 particle no constants, no problem.
22:15 chromatic Or only constants in places where you *know* that it's safe to promote a PObj to a constant.
22:15 leo except performance and space troubles later - yes ;)
22:15 particle yes, when we get to 0.50+ we'll need performance and space optimizations
22:15 particle then constants++
22:16 leo chromatic: yes, indeed - that might need some changes in e.g. Sub internals to fix current problems
22:17 chromatic I'm sure it will.
22:17 spinclad (but we're already at 0.5+?)
22:17 chromatic 5 < 50
22:17 leo *g*
22:17 chromatic With regard to getting mark() right, I think we can almost always autogenerate it from the new PDD 17 attribute declarations.
22:17 spinclad (will we *ever* hit 50?)
22:18 spinclad (before we jump to 1?)
22:18 chromatic 0.50 is probably the point TPF rents me for a month and locks me in a room with various snack foods and won't let me out until I either say "We need to fix these things" or "Where's Leo?  He needs to fix this one."
22:19 leo I'll take a sabbatical then a dayjob ;)
22:20 spinclad (ah.  0.50: the boundary between the first two 80%s)
22:20 leo anyway - roger has brought up a point of the term constant:
22:20 * leo is seeing these defs:
22:21 leo constant PMC: allocate in constant pool - a GC tern
22:21 leo term
22:21 leo immutable: contents doesn't change - is sharable threadwise
22:21 leo these 2 concepts are orthogonal
22:22 leo .
22:22 leo some interna�l parrot structure have both properties - some don't
22:23 chromatic Aren't constants also immutable?
22:23 chromatic But not vice versa.
22:23 leo no
22:24 leo you can add as many constant items to a constant PMC as you like, as long as these items are constant too
22:24 leo it's just a GC term
22:25 leo as long as     PObj_constant_FLAG          = POBJ_FLAG(12),
22:25 leo ... involved
22:25 chromatic Oh.  I was thinking of swapping to the RO vtable when purifying a constant.
22:26 leo this would be ok for immutable := r/o constants, yes
22:26 chromatic That's what I had in mind.
22:26 leo but as said, currently it's a matter of not considering these PMCs during GC, not more
22:27 chromatic Right.
22:27 leo it's a policy thingy what is long living in the interpreter that it might be constat
22:28 leo e.g. the packfile with all the Subs
22:28 leo but not the 'eval'ed code
22:28 chromatic Right.
22:29 chromatic Probably Class PMCs.
22:29 leo yep
22:29 leo but what about dynamically built clases
22:29 leo and so on
22:29 leo this needs a clear policy
22:30 leo reflected in C-structures and code
22:30 chromatic and lots of revising the PackFile code.
22:30 leo Sub was ok some time ago, then Namespaces arrived and the first breakage did happen
22:30 chromatic Which is kind of a mess anyway.
22:30 leo yep
22:31 leo packfile code the started marking Sub structs
22:31 leo then
22:31 chromatic I looked at mark_1_sub or whatever it is.
22:31 leo so some C structures aren't yet capable of dealing with constant PMCs
22:31 chromatic I can't convince myself that it's getting all constants in all PackFile segs.
22:31 leo yep that one
22:31 chromatic mark_1_seg
22:31 leo yep
22:32 chromatic If walking the pointer from the first packfile really works... maybe.
22:32 leo well, subs are marked from context code too
22:32 chromatic True.
22:33 chromatic and I suppose we could walk the constant pools during sweep and flip the live flag back to zero, but why have constant pools then?
22:33 leo and should be cleaned up if the context vanishes because of some eval-ish code
22:34 chromatic Anyone want to write a Scheme VM instead?
22:34 leo chromatic: indeed  - if it's not totally clear that these PMCs are persistent for the interpreter lifetime then don't create these constant
22:34 chromatic I can live with that rule.  I can't live without some food now though.
22:34 chromatic Thanks for the thoughts, leo.
22:34 leo welcome
22:43 jonathan .oO(WTF?)
22:45 particle ...riffing on chromatic's nick...
22:55 jonathan ...
22:55 jonathan :-)
22:57 jonathan Hmm. Looks like vtable method does isn't implemented anywhere.
23:02 Andy joined #parrot
23:04 zaphod joined #parrot
23:08 x joined #parrot
23:10 peeps[work] joined #parrot
23:17 kid51 joined #parrot
23:26 Limbic_Region joined #parrot
23:32 Theory joined #parrot
23:36 zaphod I haven't been able to find anything in the docs or tests about this so far.  How is :multi(...)  in PIR supposed to interact with inheritance?
23:37 DarkWolf84 joined #parrot
23:43 chromatic Right now it uses Manhattan distance, so... not well.
23:45 zaphod right now I'm getting that when a subclass declares a multi of the same name as the superclass the super's versions of the method are not in the subclass
23:46 chromatic Probably because of how we store them in namespaces.
23:46 chromatic Yick.
23:46 chromatic I could give you a workaround, but you probably don't want it.
23:47 jonathan This comes back down to the issue of, we do the real dispatch on invoke.
23:47 zaphod is the workaround to make a copy of the parent's Multisub for the child class?
23:47 chromatic Yep.
23:47 zaphod ugh
23:47 chromatic Could be worse.
23:47 purl Could be Java.
23:48 jonathan purl++
23:48 chromatic You don't want to know what it takes to make exporting multis into a namespace where you already have variants of that multi.
23:50 zaphod I tried getting around it by putting a default multi in the child class and then calling to the super with callmethodsupercc...then I discovered that callmethodsupercc wasn't implemented :P
23:52 zaphod Then I found the Super PMC (and then discovered that it is deprecated) which solves it as well
23:57 iblechbot joined #parrot

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced