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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!