Parrot 0.8.2 "Feliz Loro" Released www.parrot.org/news/2008/Parrot-0.8.2
Set by moderator on 14 January 2009.
pmichaud (and sooner rather than later) 00:00
jonathan I'd like it if that place was rakudo.org becuase it's easy to remember.
pmichaud would rakudoperl.org be an okay substitute if rakudo.org doesn't work out?
jonathan Yes.
cognominal pmichaid, can you twit on rakudoperl with the url of an new entry on parrot planet? 00:01
pmichaud!
purl pmichaud is www.pmichaud.com/ or "Patrick R. Michaud" <mailto:pmichaud@pobox.com> or in charge of toaster experiments
pmichaud cognominal: sure
jonathan But I'd be disappointed if we can't co-operate with whoever owns rakudo.org to make that what we want it to be.
pmichaud whoever owns rakudo.org == Andy
Casan while I do not feel my say is to weigh anything on this, on behalf of users like me I can say ++ to the same sentiments of jonathan, they are in par with my wish list
cognominal twit is my new RSS :)
lathos Worst case you can have *.rakudo.org
jonathan OK, I knew Andy managed it, wasn't sure on ownership. 00:02
pmichaud Andy owns it.
lathos www can be just the blog, other subdomains can be other stuff.
pmichaud it would be better if www is the site, though.
jonathan lathos: No.
pmichaud i.e., not the blog.
jonathan lathos: See comment above.
lathos Sure would, that's why I said worst case.
Casan hummm, but still www.rakudo.org should be the main place, with intro, not blog at first
pmichaud worst case would be no site at all :-) 00:03
Casan think of an official marketing/business site to support customers.
jonathan worst case is that we give up on Rakudo on decide to dedicate our lives to the advancement of LOLCODE instead.
s/on/and/
pmichaud actually, worst case would be that www.rakudo.org goes somewhere promoting the anthesis of Perl.
antithesis, that is.
(can't type.)
Casan jonathan: if you do that I buy you one more beer! :)
pmichaud I should pivovat.
jonathan Anyway, Andy has IIRC suggested rakudo.org may become Drupal-based. 00:04
Which would seem to let us put content there.
pmichaud if Drupal is fine with you, I think it would be okay with me. 00:05
jonathan And I guess that will give us what we want.
pmichaud I'd like it to be easy to give out the ability to edit/update content.
lathos I've been using Drupal for all our sites recently. It's spectacularly flexible.
pmichaud I don't like Drupal's "wiki", though. However, github seems to provide a wiki, so if we host rakudo through github then that could provide us a wiki for a while. 00:06
jonathan Drupal seems fine with me.
pmichaud: We don't massively *need* a wiki on rakudo.org.
IMO.
We need a place where people can come, find what's up with Rakudo, find out how to get hold of it, etc.
pmichaud I think a wiki, or some good way to enable user-contributed content without lots of pre-registration / clearance, is useful.
for example, keeping the "what doesn't work in Rakudo" list up to date. 00:07
jonathan Good point.
What are your thoughts on bug tracing?
er, tracking
;-)
pmichaud we're likely to stay with rt.perl.org, I think.
jonathan Why? (I'm not disagreeing, just curious why.) 00:08
pmichaud it's frustrating at times, but Robert is very responsive in general and hopefully some of those will go away.
jonathan OK.
pmichaud *those frustrations
jonathan The Parrot Trac is...slooooow.
But Trac can be unslow.
pmichaud RT is often slower than trac for me.
jonathan And it's got a decent wiki.
pmichaud I do like Trac's ability to create custom reports and associate everything with milestones.
And the wiki.
purl the wiki is dev.catalyst.perl.org/wiki/
lathos Is it running on mod_parrot?
00:09 AndyA joined
jonathan I use Trac on a couple of other projects. I do like it. 00:09
But yes, Robert++ *is* responsive.
pmichaud But moritz++ said he prefered to stay with rt.perl.org over trac (for some very valid reasons), so I'm biased towards rt.perl.org at the moment. (For that and other reasons also.)
Casan lathos: wishful thinking
jonathan I'm happy staying with RT too.
lathos Someone was telling me the other day that trac does an awful lot of unnecessary module reloads (with an associated doubly awful number of library-path-search stats) if it's not running on mod_parrot.
I mean mod_python of course. Urgh.
pmichaud I'm being called to dinner. 00:10
later, all.
jonathan lathos: There's a *huge* performance difference between running it without and with mod_python.
Later, pm.
lathos Yep.
jonathan lathos: In my experience, anyway.
lathos What do we have at the moment?
jonathan On parrot.org? No idea. But I fear without mod_python... 00:11
lathos Hmm.
jonathan That or something else is making it a *lot* less snappy that any other installations of Trac I have.
Whiteknight Coke here? 00:12
I guess calling himself "coke_away" is a cluse 00:13
s/cluse/clue/
cognominal pmichaud, you need spectcacular twit photo to about parrot saving the world like twitpic.com/135xa :)
On tr... 00:14
s.s..; 00:15
cognominal or at least of the parrot and rakudo tests graphs
dalek r35608 | Whiteknight++ | branches/morph_pmc_type/src/ops (2 files): 00:17
: [morph_pmc_type] update some files in src/ops/*
review: www.parrotvm.org/svn/parrot/revision?rev=35608
r35609 | simon++ | branches/strings/pseudocode: 00:18
: Ironically, I need to get the length of a string.
review: www.parrotvm.org/svn/parrot/revision?rev=35609
coke_away (why move the repository) I am deep in review, but I assume this was covered at the PDS. no? 00:23
dalek r35610 | simon++ | branches (144 files): 00:36
: Merge from trunk
review: www.parrotvm.org/svn/parrot/revision?rev=35610
Whiteknight how are the read-only versions of PMCs named? 00:41
Infinoid well, from the pmc2c output, it looks like Classname => Classname_ro 00:47
but I don't see corresponding enum_class_* definitions to support that. 00:48
Whiteknight yeah, they're defined as "enum_class_X - 1" 00:50
thanks Infinoid++
Infinoid ... really? they don't look spaced out like that in include/parrot/core_pmcs.h 00:51
but if you say "yes", I'll believe you :) 00:52
00:57 ask_ joined 00:58 tetragon joined
Whiteknight I was able to get around having to use the string name, but it's a hackish solution 01:03
I'll have to fix it later
I'm using interp->vtable[enum_class_X - 1]->whoami to get the string name of the mc 01:04
pmc
dalek r35611 | Whiteknight++ | branches/morph_pmc_type/src/pmc (6 files): 01:10
: [morph_pmc_type] convert files in src/pmc/* to use VTABLE_morph_string instead of VTABLE_morph
review: www.parrotvm.org/svn/parrot/revision?rev=35611
01:10 tjh joined
particle3 string, not pmc? 01:12
01:19 TiMBuS joined 01:20 tjh left
dalek r35612 | Whiteknight++ | branches/morph_pmc_type/src (2 files): 01:21
: [morph_pmc_type] one last fix from bigint.pmc and update src/dynpmc/rational.pmc
review: www.parrotvm.org/svn/parrot/revision?rev=35612
r35613 | Whiteknight++ | branches/morph_pmc_type/languages (2 files): 01:35
: [morph_pmc_type] a few stragglers
review: www.parrotvm.org/svn/parrot/revision?rev=35613
Whiteknight particle3, it's just a temp name. I'm going to delete the current morph and rename "morph_string" to "morph" in a minute 01:46
there's method to my madness
although there isn't always a lot of creativity to my method names
01:53 particle1 joined 01:54 LimbicRegion joined 01:55 particle3 joined, particle3 left
dalek r35614 | Whiteknight++ | branches/morph_pmc_type/src (7 files): 01:55
: [morph_pmc_type] remove the old morph VTABLE, everything is now replaced by my dummy morph_string method
review: www.parrotvm.org/svn/parrot/revision?rev=35614
01:57 Limbic_Region joined 02:04 kid51 joined
Coke_away jonathan: ping 02:10
02:18 jimmy joined 02:51 TimToady joined, confound joined, rhr joined, jhorwitz joined 02:58 dngor joined, Limbic_Region joined, bacek joined, TiMBuS joined 03:00 ask_ joined
kid51 must sleep 03:18
purl $kid51->sleep(8 * 3600);
03:35 cognominal joined 03:58 Eevee joined 04:04 samlh joined 04:10 purl joined 04:13 Fayland joined, particle joined 04:26 tetragon joined 04:27 mib_vm25pu joined 04:30 petdance joined 04:33 jhorwitz_ joined
dalek r35615 | pmichaud++ | trunk/languages/perl6/src/parser: 04:56
: [rakudo]: Fix degenerate space before postfix ops. (RT #60148)
review: www.parrotvm.org/svn/parrot/revision?rev=35615
Infinoid so, does trac have a commit rss? 05:08
pmichaud trac.parrot.org/parrot/wiki/TracRss 05:17
05:30 MariachiElf joined
Infinoid hmm, cool. I could probably log ticket events to the channel too, if people consider it useful 05:47
hmm. one problem is, trac rss doesn't include the list of modified files, which means the nifty branch/focus/whatever detecting stuff will no longer work. 05:52
maybe I could do some additional screenscraping to get that info
06:03 GeJ joined 06:16 Tene joined 06:23 shorten joined 06:58 ewilhelm joined
ewilhelm hi all. anyone have input regarding what to tell students about parrot and perl 6 regarding summer of code? 06:59
specifically, what sort of language experience is required or useful (besides perl and C - and how requisite is either of these?)?
07:04 Fayland_ joined
mib_vm25pu ewilhelm: I think verybody is sleeping now. 07:09
ewilhelm perhaps they should move west ;-) 07:10
thanks, I have a fairly good idea of what to say I was just hoping to get some specific advice
07:11 clunker3 joined
mib_vm25pu It's 07:10 07:11
maybe ask it this afternoon. 07:12
ewilhelm so you think eastward would work better then?
07:13 Fayland joined
mib_vm25pu I don't know. 07:14
ewilhelm ah, it must be too early for jokes there 07:15
mib_vm25pu C is required 07:16
actually, I can't understand the jokes.
ewilhelm C is required for parrot, but I thought rakudo was more pir 07:18
mib_vm25pu yes, and Compiler Principles 07:19
ewilhelm ah, good point. thanks 07:21
07:22 masak joined
mib_vm25pu good morning masak 07:22
masak good morning mib_vm25pu
...jimmy. 07:23
moritz ewilhelm: for parrot you need C, and learn PIR; for Rakudo, you need Perl 6 and PIR and a bit of C
ewilhelm: and for Perl 6 hacking you need Perl 6, and patience ;-)
07:23 ChrisDavaz joined
ewilhelm students with perl 6 experience might be slim pickings ;-) 07:24
moritz I know
but they can learn it, provided that they have some perl 5 knowledge
masak I think Perl 6 is easier than Perl 5 in many ways. 07:25
moritz ewilhelm: do you know of a wiki page where we share Perl 6/parrot SOC project ideas? 07:26
ewilhelm moritz, ATM we only have what's left from last year on the perlfoundation.org/perl5 wiki 07:32
jonathan leto is running the TPF effort, but if you want to start a page just send him a link 07:33
jerry (particle) should be in touch with him and I think will be driving the Parrot Foundation bus 07:34
lu_zero there are easy tutorials for perl6 already or everything has to be learnt the usual way?
moritz ewilhelm: did I ever say "thank you" for your effort last year? if not, now would be a very good time ;-)
lu_zero: there are a few tutorials, but most of them don't go very deep
cotto lu_zero, jonathan has several useful presentation slides at www.jnthn.net/articles.shtml 07:36
you can also look at November and a few scripts that people have hacked up (but maybe that's "the usual way") 07:37
ewilhelm has anyone tried to do the qotw in perl 6? 07:39
moritz, I think you did say, and thank you
perl.plover.com/qotw/ 07:40
masak lu_zero: the other day I started a documentation effort for Perl 6. but it doesn't help you yet. use.perl.org/~masak/journal/38279
Tene ewilhelm: looks like that's been abandoned since Oct 2004 07:46
cotto masak++ #more perl6 documentation 07:47
masak I have high hopes for that project. 07:48
cotto "psi"? 07:51
purl "psi" is some pseudo-scientific term for "paranormal studies"
cotto Is that because it's supposed to guess what you're trying to figure out?
masak cotto: among other things, yes.
cotto I'm sure there's a terrible pun in there too. 07:52
masak cotto: no, not really. but Ruby has 'ri' for this, so it's natural that Perl Six should have 'psi'. 07:53
ewilhelm Tene, yes, but none of the quizzes have been done in perl 6. I'm told that the ruby community went through them at some point. 07:56
masak sounds like something that could be done over at perl6-examples, then. 07:59
Tene masak: so you'd be in favor of me spending my Parrot tuits on getting "evaluate using the given lexical environment" working (for repl and eval)? 08:01
I'm pretty sure I know how to do it. 08:02
masak Tene: oh yes.
Tene masak: also, btw, a nice trick in the current rakudo repl is using global vars.
masak Tene: yes, that's a good _short term_ solution, I know.
but don't count on selling the GP on that. 08:03
Tene I don't.
I've been working on lexical invoke in the background for quite a while. I can start trying to implement it RSN. 08:04
08:04 iblechbot joined
masak \\o/ 08:04
moritz www.perlfoundation.org/perl6/index....code_ideas please add ideas for Parrot SOC projects 08:06
shorten moritz's url is at xrl.us/becqk3
Tene I also have a vague idea about getting line continuation and such working.
masak Tene++ 08:07
Tene Involves hacking PGE to emit the right kind of resumable exceptions under the right circumstances, and that's a lot of stuff I'm handwaving over.
And if I pursue it, the likely outcome is me badgering pmichaud into doing at least half of it. ;) 08:08
08:08 mberends joined
moritz sounds really simple *cough* 08:09
cotto ++ to whomever had the idea to get started on gsoc early this year
Tene moritz: you hack on any parrot guts at all? 08:10
moritz Tene: no.
Tene: I hope you heard my irony ;-)
Tene Oh, the really simple. 08:11
I get it now.
That wasn't related to your simple comment. I was just going to show you where I was looking.
moritz ah ok 08:12
08:13 jimmy joined
Tene moritz: if you can harass me about it this weekend, I'll give it a show. 08:14
shot.
moritz Tene: I'm not online this weekend :( 08:37
09:22 wolverian joined 09:24 barney joined 09:28 alvar joined 09:38 Ademan joined 09:40 namenlos joined 10:04 tomyan joined 10:05 braceta joined
dalek r35616 | bernhard++ | trunk/t/oo: 10:22
: [codingstd] file_metadata.t
review: www.parrotvm.org/svn/parrot/revision?rev=35616
r35617 | bernhard++ | trunk/src/pmc: 10:23
: [codingstd] tabs.t
review: www.parrotvm.org/svn/parrot/revision?rev=35617
10:34 bacek joined
jonathan Coke: pong 10:35
10:37 rdice joined 10:38 jimmy left 10:43 gaz joined
dalek r35618 | bernhard++ | trunk/languages/pipp/t/php: 11:15
: [Pipp] Add simple namespace tests.
review: www.parrotvm.org/svn/parrot/revision?rev=35618
r35619 | bernhard++ | trunk (2 files): 11:19
: let SVN ignore *.o in sr/atomic
review: www.parrotvm.org/svn/parrot/revision?rev=35619
r35620 | simon++ | branches/strings/pseudocode: 11:33
: Abstract fixed-width encodings into a base class.
review: www.parrotvm.org/svn/parrot/revision?rev=35620
r35621 | simon++ | branches/strings/pseudocode (2 files): 11:42
: Variable string encodings can have their own base class too.
review: www.parrotvm.org/svn/parrot/revision?rev=35621
r35622 | jonathan++ | trunk/languages/perl6/src/classes (2 files): 11:46
: [rakudo] Implement .does method (Any delegates to the metaclass, and we have the implementation there).
review: www.parrotvm.org/svn/parrot/revision?rev=35622
r35623 | jonathan++ | trunk/languages/perl6/src/builtins: 11:47
: [rakudo] infix:<but> needs to be aware of ObjectRef, otherwise we end up affecting the original object.
review: www.parrotvm.org/svn/parrot/revision?rev=35623
r35624 | jonathan++ | trunk/languages/perl6/config/makefiles:
: [rakudo] Oops, should have checked updated makefile in a couple of commits ago.
review: www.parrotvm.org/svn/parrot/revision?rev=35624
r35625 | jonathan++ | trunk/languages/perl6/t: 11:48
: [rakudo] Add the (now substantially passing) S12-role/basic.t to the spectests. It tests .does in the non-parametric case as well as covering the infix:<but> with ObjectRef bug recently fixed. 11:49
review: www.parrotvm.org/svn/parrot/revision?rev=35625
12:00 rdice joined, pjcj joined
dalek r35626 | bernhard++ | trunk/languages/pipp/src/pct: 12:10
: [Pipp] Rename NAMESPACED_IDENT to name and define it line in Rakudo
review: www.parrotvm.org/svn/parrot/revision?rev=35626
12:24 ruoso joined
sjn wonders if there exists a webpage or tutorial or something that describes all the features available in the bots and such that we can use in the different Perl-related IRC channels 12:25
masak Tene: ping 12:30
12:32 ruoso joined 12:35 lathos joined 12:38 barney joined
moritz sjn: I'm quite sure that such a thing does not exist ;) 12:44
12:46 ruoso joined
Coke jonathan: I should have just asked you the question. =-) 12:49
using the bytecode annotations, they're tied to the context chain, n eh?
jonathan Coke: In what senes? 12:53
Coke: You can look up annotations down the context chain if you wish, via ParrotInterprter.
But the annotations themselves are tied to the bytecode.
*sense
dalek r35627 | bernhard++ | trunk/languages/pipp/docs: 12:56
: [Pipp] note a divergence
review: www.parrotvm.org/svn/parrot/revision?rev=35627
13:01 contingencyplan joined, ruoso joined
sjn moritz: d'oh! 13:05
Coke jonathan: the annotations are... I hate to say lexical... sticky?
so I set (file,a.tcl), and then invoke a sub, and check annotations, (file,a.tcl) is still set.
dalek r35628 | simon++ | branches/strings/docs/pdds: 13:06
: Typo
review: www.parrotvm.org/svn/parrot/revision?rev=35628
Coke and if I set (line,30), and then return from a sub, (line) is ... no longer set? set to whatever it was in the original sub?
jonathan Coke: Not in the sub you invoked, no, but you can look one level down the call stack to get those annotations.
Oh, it's what it was in the original sub then.
Coke jonathan: when I look at the 'backtrace', it seems to be folded in.
Coke checks something. 13:07
jonathan Coke: Beware that annotations have no idea about sub boundaries though.
lathos OK, I don't know when characters are graphemes and when they aren't. Argh. 13:08
13:10 kj joined
Coke jonathan: ... so if I say .sub joe\\n.annottate 'bar,'baz'.end .sub fred .... .end , the annotation is in fred too, even if I dont' call one from teh other? 13:10
jonathan Yes
It's nothing to do with calling.
It's entirely to do with bytecdoe.
*bytecode 13:11
It's possible to introduce a directive that says "clear all active annotations" *if* it's needed. 13:12
Coke um. 13:13
jonathan But I kinda figured that compilers are going to be emitting .line directives pretty much at the start of every sub.
13:14 rurban joined
Coke you mean .annotate 'line', ... ? 13:14
jonathan Oops
Yes.
Coke I am very surprised by this behavior.
jonathan Why?
They are *bytecode* annotations. 13:15
Coke reads the pdd.
kj it's similar to a .namespace directive, which stays in place until you specify a new .namespace
jonathan Right. 13:16
Coke: .annotate is described in PDD19, but there's some lower-level details in PDD13.
13:16 ruoso joined
Coke jonathan: I'm interested in the "user facing" aspect, so pdd19 is better for me. 13:18
jonathan Aye.
Coke: If there's something that could be added to pdd19 that woulda made the behaviour clearer to you, please do add it. 13:19
It's the usual case of "obvious to the implementor" :-)
Coke jonathan: let's say I processing foo.tcl, and then I source bar.tcl; I can add a file annotation at the point where I read in each item.
when I'm done processing bar.tcl, do I have to then explicitly re-annotate with the original file name? 13:20
jonathan What does "source" do?
nopaste "barney" at 84.154.3.98 pasted "--target=parse broken in Rakudo" (30 lines) at nopaste.snit.ch/15324
jonathan (Sorry, I don't know tcl at all)
Coke like .include 13:21
jonathan Ah.
In that case, yes.
Coke ew.
jonathan Do you compile it down to .include?
Coke no. 13:22
jonathan Ah.
Then maybe not.
Coke everything is interpreted. =-)
jonathan Ah. :-)
Coke well, compiled/then/executed.
so source slurps in the source, compiles the tcl to PIR and invokes it, and then returns.
hurm. will every invocation of the PIR compiler have its own annotations?
or does it share annotations with the pbc that invoked the compiler? 13:23
jonathan In that case, you are doing compreg and getting back an Eval PMC and then invoking it, right?
Coke yes.
I do that /a lot/
jonathan So then those annotations will (should!) be in a segment attachted to the bytecode segment in that Eval PMC
And should not have any effect on those of the PBC that invoked the compiler.
So suppose you do source foo.tcl 13:24
Coke ok. then this might just happen to work.
jonathan I'd imagine that when you compile foo.tcl you will insert .annotate directives in the PIR that you are going to compile.
Coke jonathan: [source] is: code.google.com/p/partcl/source/bro...source.pir
shorten Coke's url is at xrl.us/becq22
Coke (compileTcl is defined elsewhere, but basically invokes the PGE/TGE/PIR/PBC chain) 13:25
jonathan Coke: where can I find the source for compileTcl?
Coke: Ah, found what I'm looking for. 13:26
Coke oooh, found a bug. =-)
jonathan Coke: OK, so in the transforms that produce PIR, that's where you'd want to spit out .annotate directives into the PIR you are generating. 13:27
nopaste "coke" at 72.228.52.192 pasted "this code assert fails" (29 lines) at nopaste.snit.ch/15325
jonathan IIUC what is going on.
Coke: Which assert? 13:28
Coke if I comment out the .annotates, that completes with a throw exception.
src/packfile.c:1575: failed assertion 'dir'
jonathan Shit. 13:29
*sigh*
Please file Parrot ticket, I'll look into it.
Coke Sorry. want a t.... k.
jonathan is currently patching up the "fun" that sees Parrot doing PMC_sub all over the place without checking it's actually a sub PMC.
$P0 = new 'Integer'\\ncapture_lex $P0\\n # BOOM 13:30
13:30 tetragon joined
jonathan Coke: It may be something that just shows up in eval... 13:31
That's my first guess.
Coke trac.parrot.org/parrot/ticket/180 13:32
jonathan Thanks. :-)
At lesat it's a nice small example.
Coke if that works as we expect, then I don't have to worry about keeping track of everything, I just have to setup each compilation unit sanely.
jonathan++ 13:33
In advance of it working, I can probably work on a helper method to reformat the backtrace into something more tcl-like.
jonathan I *think* that we have the same expectations of what the backtrace should look like here. 13:34
Just need to fix whatever segvs.
13:36 ruoso joined, Whiteknight joined
nopaste "coke" at 12.111.36.194 pasted "sample tcl backtrace." (29 lines) at nopaste.snit.ch/15327 13:37
Coke jonathan: I'd expect the original backtrace to show a file directive only for the first chunk, and then a file/line for the next chunk.
if I just put the 'joe' sub declaration at the bottom of the file, the line directive is still in effect. 13:38
ah, I also need a 'command' directive.
Coke should put in comment annotations there and follow the logic. 13:39
jonathan Coke: That's what I'd expect, yes.
nopaste "coke" at 12.111.36.194 pasted "faux annotations." (36 lines) at nopaste.snit.ch/15328 13:41
Coke whoops. missed "# command " annotations for the procs.
guess I my PBC is going to get much bigger. =-) 13:42
s/I //
jonathan Coke: Annotations are stored reasonably compactly, so it shouldn't be too bad. 13:43
lathos Can someone look at PDD28 and tell me how Parrot_string_grapheme_copy differs from Parrot_string_append? 13:44
Coke lathos: perhaps string_append is ignoring the charset? 13:46
(or encoding. or something other unicodey thing.)
I dislike all the (was foo) references in that doc. 13:47
lathos That gets you into trouble fast, though.
Coke lathos: oh, I'm not saying it's a /good/ idea.
lathos The (was foo) references are annoying but will be helpful when I start trampling on the old code. 13:48
Coke I was merely pointing out some selections of crack you might which to peruse.
lathos Or I could just get rid of it. 13:50
13:51 ruoso joined
lathos OK, and *this* no longer makes sense: bufused is the amount of the buffer used in bytes, strlen is the length of the string in bytes. Why would they ever be different? 13:52
pmichaud one might chop a string but not want to reallocate the buffer?
(just guessing)
lathos At which point you're not using that bit of the buffer. 13:53
Perhaps it should be bufallocated or something.
Particularly since we don't have anything which actually tells us how big the buffer is. 13:54
dalek r35629 | pmichaud++ | trunk/languages/perl6/docs: 13:55
: [rakudo]: spectest-progress.csv update: 285 files, 6263 passing, 0 failing
review: www.parrotvm.org/svn/parrot/revision?rev=35629
Whiteknight lathos: maybe whoever wrote the documentation (possibly me) didn't fully understand the function
dalek r35630 | simon++ | branches/strings/pseudocode (3 files):
: Get chopn_inplace working, and puzzle over strlen/bufused differences.
review: www.parrotvm.org/svn/parrot/revision?rev=35630
lathos Whiteknight: Actually I wrote the documentation. o_O 13:56
Whiteknight oh, I was only guessing. I've written a lot of documentation around here
the quality's not always great, but my enthusiasm is unbeatable 13:57
lathos I guess the problem was I started with reality (pobj.h), and reality is often nonsensical. 13:58
Oh no, it's worse than that. 13:59
pmichaud jonathan: (r35623) in builtins/guts.pir there's a !DEREF sub that will deref a PMC if it's an ObjectRef
lathos I think strings.c expects strlen to be in characters.
pmichaud it will even handle chains of ObjectRefs
jonathan Should we be able to *get* chains of ObjectRefs?
pmichaud I'm afraid it will happen, yes.
jonathan But feel free to change, or I will.
But currently deep in this subclassable subs "fun" 14:00
pmichaud no need to change immediately, just wanted you to be aware of it.
jonathan Thanks - it should use !DEREF though for sure if chains can happen. 14:01
pmichaud we might get chains, but I'm thinking they'll never be more than two deep. 14:02
jonathan *nod*
Hopefully not. We do try and avoid 'em generally.
pmichaud and we might be able to fix things to avoid them, but I see that as an optimization for now.
a lot of it will depend on how we end up handling cumulative constraint properties
14:05 ruoso joined, namenlos joined
Whiteknight anybody here against changing VTABLE_morph to take a string instead of an intval? 14:08
Coke no. 14:12
kj +1
purl 1
Coke sees the magic partcl fairy didn't commit anything again last night. 14:13
dalek r35631 | bernhard++ | trunk/languages/pipp (2 files): 14:17
: [Pipp] Start to treat constants as package vars.
review: www.parrotvm.org/svn/parrot/revision?rev=35631
PerlJam Coke: that's because you didn't leave snacks out for him 14:18
14:19 ruoso joined 14:22 Lorn joined
pmichaud I'm against it. 14:29
(VTABLE_morph)
I'm not arguing in favor of having VTABLE_morph take an intval, but we should not be using strings to identify classes. 14:30
VTABLE_morph should take whatever arguments are accepted by get_class.
wait, this is the VTABLE. I'll rephrase then.
VTABLE_morph should take a class PMC.
jonathan Hmm. Only 3 spectest fails as a result of the reblessing. That isn't so awful as I feared... 14:31
pmichaud jonathan: and I would carefully check the tests. They may be faux passes.
jonathan pmichaud: I know that I removed one hack where we epicly lied in .WHAT. :-) 14:32
pmichaud heh.
jonathan But I really want to map Sub to Block not Code.
pmichaud our lies are catching up to us?
jonathan That doesn't quite work out though. 14:33
Well, I removed the code that was telling it. :-)
So far I'm only reblessing Sub and Method.
pmichaud yes, Parrot doesn't give us a way to represent code that isn't a Sub.
jonathan Don't know if we should re-bless everything else into Block.
Whiteknight pmichaud, that might be a better solution, yes. I can do that instead if people like it more
jonathan Or just map Sub to Block.
Somehow that didn't quite work out...hmm. 14:34
pmichaud why isn't Sub mapped to Code?
I think it needs to be mapped to Code.
14:34 ruoso joined
jonathan Why though? 14:34
{ 42 }.WHAT # Code or Block?
pmichaud that's a Block. But we should rebless it into Block, I think.
phrased differently, "Block" implies a lexical scope. Not every (Parrot) Sub we encounter has a lexical scope. 14:35
jonathan OK, so we should rebless everything.
Can do.
Actually 5 fails I think. 14:36
pmichaud I don't like the "rebless everything" approach either, but it seems the cleanest overall.
jonathan But still, not awful.
pmichaud in terms of what is really happening.
jonathan It means giving *every* block a loadinit...
But we'll cope. :-)
pmichaud agreed, let me think about it a second more.
every block is getting a loadinit anyway, isn't it?
jonathan Is it? 14:37
purl it's it!
pmichaud can you think of any that don't?
jonathan { 42 } # does that get a loadinit?
pmichaud immediate blocks might be the only exception.
my $sub = { 42 }; # gets a loadinit
jonathan Since you can't reference an immediate block, do we care about reblessing them? 14:38
Is that an immediate or a declaration?
pmichaud that's a declaration.
jonathan Right.
pmichaud good point (reference immediate block)
so no, I don't care about reblessing them for now.
I think all of the others already have loadinit 14:39
(because they have signatures)
jonathan Gah. I fail some Parrot tests anyway.
Whiteknight pmichaud, so you are saying that we should have morph_p_s and morph_p_p opcodes, to create from either a string or a class PMC?
14:40 jhorwitz joined
pmichaud Whiteknight: if the IN argument to morph is intended to represent a type (class), then we need a way to specify the class by its class object 14:40
strings are insufficiently precise.
Whiteknight okay, we can do both
jonathan Or perhaps precisely insufficient. ;-) 14:41
pmichaud I'll accept both. Whatever get_class ultimately ends up with.
but the VTABLE_morph should use a class PMC as its argument, I think.
Whiteknight should I maybe be waiting for get_class to solidify before doing this work then?
pmichaud you could solidify get_class :-)
that would make me very happy. :-)
Whiteknight is there a ticket for that work? I'll get right on it if I have some direction 14:42
pmichaud I'll get you the references.
just a sec
Whiteknight thanks
Coke agreed. resolve get_class first, and then use the /same/ mechanism for VTABLE_morph. 14:43
(where the opcodes may present slightly more variants that map to something sane internally.)
pmichaud my latest post on the subject: lists.parrot.org/pipermail/parrot-d...00872.html 14:44
shorten pmichaud's url is at xrl.us/becq86
Whiteknight oh right, I remember this thread
pmichaud allison says that get_class should accept a Key, String, ResizableStringArray
or NameSpace
purl well, NameSpace is the internal namespace for things like $c->forward and template paths, anyway
pmichaud currently this is not the case.
there's a related trac ticket at TT #8.
Whiteknight do we want it to be able to support any array pmc type as well, or just RSA? 14:45
pmichaud allison has not yet responded positively or negatively to my message, but I'm guessing that since she claims that the opcodes already do certain things it won't hurt for us to make them do what she says they should :-)
I'd like it to support any array type. But that's really allison's call.
Whiteknight I'll write it up to be the most general, but comment out the conversial stuff 14:46
pmichaud works for me.
Whiteknight smells another branch cookin'
pmichaud then morph_p_p can simply do the equivalent get_class operation before passing things to VTABLE_morph
(or VTABLE_morph can do the operation... but I think it's cleaner to say that VTABLE_morph always expects a class PMC) 14:47
14:48 ruoso joined
Whiteknight okay sounds good to me 14:49
jonathan Woo, Parrot passes core tests. 14:54
15:03 ruoso joined 15:12 Casan joined 15:13 Casan left, Casan joined 15:16 particle joined 15:18 ruoso joined 15:34 ruoso joined 15:35 Andy joined 15:47 ruoso joined 15:50 riffraff joined, davidfetter joined 15:53 Casan joined 15:56 gryphon joined 15:57 jan joined
riffraff in my tiny language I implemented lexical scope and anonymous functions, but it seems that if I pass a function to another function then at call time it fails to lookup correctly 16:05
I assume it makes sense because the node I generate is :pasttype('call') :name($name), but I'm not sure how should I invoke the current passed object 16:06
meaning: I tried Op.new($var,:pasttype('call'),:name('invoke')) and it did not work
pmichaud it's just call. 16:07
Whiteknight if you're treating subroutines as first-class objects, you probably don't want :pasttype('Call')
pmichaud no :name('invoke')
Op.new($var, :pasttype('call'))
assuming that $var is the function you want called.
riffraff ok, I'll try thanks 16:08
pmichaud if you say Op.new($var, :pasttype('call'), :name('invoke')) then it will try to call the function "invoke" passing $var as a parameter.
riffraff yes, which is what I assumed shall happen, having $var has a kind of self
this, because I tried a=1; a() and I got "no 'invoke' in Integer" :) 16:09
Whiteknight, well, using :pasttype('call') was the path of least resistance up to now 16:12
now I guess I shall switch my calling action to use what pmichaud said, although I'm slightly worried by what may happen later on this road :) 16:13
Whiteknight ok
16:14 leto joined 16:15 Tene_ joined 16:16 ruoso joined 16:20 hercynium joined
dalek r35632 | Whiteknight++ | trunk (2 files): 16:32
: [morph] Update the morph vtable override to take a class PMC instead. This is how it will be in the final version, so make the API match the intended behavior and cleanup the internals later. Also, update the test for this.
review: www.parrotvm.org/svn/parrot/revision?rev=35632
jonathan pmichaud: Down to just one last Rakudo spectest fail, and a full set of Parrot passes, before I can commit this stuff. :-)
pmichaud jonathan: I'm about to commit a small change to Signature.pir 16:33
(basically testing &foo params for Callable role)
jonathan pmichaud: That's fine, shouldn't get in my way. :-)
pmichaud (actually, it just tests that the argument isa Parrot Sub.)
jonathan Oh, you maybe shouldn't need to do that after my patch. ;-)
(As in, look at it at a Parrot level.)
OTOH, language interop...
pmichaud oh, we'll still end up with subs t... right 16:34
jonathan stares at tspecS12-methodscalling_sets.t and wonders, huh...
16:35 barney joined
Tene_ I realized last night that you can pass data back from an exception handler to the code that threw the exception by stuffing it in the payload. 16:36
pmichaud yes. :-)
jonathan pmichaud: Does capture_lex do something smart with multisubs? 16:37
pmichaud yes. 16:38
Tene_ pmichaud: any idea on the feasability of persuading PGE to match as much of a string as it can, but throw an exception if it gets an unexpected EOF, and let the exception handler pass back more text to continue matching?
jonathan pmichaud: Ah, I see it doing it now, yes...
pmichaud Tene_: if this is in regards to the REPL loop -- the grammar takes care of that.
(as in, STD.pm already says how to handle that.) 16:39
Tene_ Okay.
pmichaud We just haven't done anything with it yet (more)
Tene_ purl: tell masak pong 16:40
purl Tene_: what?
Tene_ purl: msg masak pong
purl Message for masak stored.
pmichaud the line in STD.pm is
| $ { $¢.moreinput }
which says that if we read the end of the string, we call the .moreinput method to go get more input :-)
Tene_ Ah, nice.
Okay. :)
pmichaud granted, we don't have an easy way to do this yet, and PGE does need a few changes to support it, but that's the approach I'm likely to take. 16:41
and that HLLCompiler and PCT will want to use.
Tene_ Can you describe what changes PGE would need for that? I think I could implement it with what's there now. 16:43
pmichaud biggest thing I can think of is that every call to a subrule or closure has to reset the current match's idea of the length of the target string, as it might have changed.
Tene_ Ah. 16:44
pmichaud that might be all that is needed, but there could be other stuff as well. 16:45
Tene_ Hmm. Sounds workable. I feel confident about debugging through that.
pmichaud well, in STD.pm there's also the case that various constructs have to set a contextual variable to indicate when they expect "more input" 16:46
and we don't really have that in place yet.
(nor does STD.pm appear to be setting that contextual variable yet) 16:47
jonathan pmichaud: Ah, found the bug - capture_lex tries to treat multisub as if it's a non-multi a bit too early.
pmichaud jonathan: feel free to fix.
jonathan Doing so.
It was completely fine before.
I've now made it so we blow up with an exception if you PMC_sub something that you can't, and if it can't find an inherited Sub PMC to get one from. 16:48
Tene_ My plan for invoking a sub in the current context is to add a method to the Sub pmc that approximates invoke, but uses the context of its caller instead of creating a new context.
jonathan Rather than blowing up with a segfault further down the line.
dalek r35633 | pmichaud++ | trunk/languages/perl6/src/classes:
: [rakudo]: Require arguments to &foo to be callable.
review: www.parrotvm.org/svn/parrot/revision?rev=35633
pmichaud Tene_: how will you get new lexicals into that context?
jonathan (The fact it tries to find the inherited one means subclassing sub now works.)
Tene_ pmichaud: hm? 16:49
pmichaud Tene_: lexicals in Parrot are intimately tied to the subroutine being invoked
Tene_ Ah, right.
pmichaud it's not just a hash that you can add entries to.
i.e., store_lex if there's no outer lexical already defined produces an error
.lex always creates a lexical in the current sub.
Tene_ Hmm. I had a solution for that last night... 16:50
Bah, should have taken notes. 16:51
16:52 Theory joined
Tene_ No, I think I did create a new context, and then I did something funny with the lexpads... 16:52
pmichaud ...create a new context?
oh, you mean in C. 16:53
Tene_ Right.
pmichaud from your method in the Sub pmc.
Tene_ Eh, we'll see what actually works.
pmichaud wait, let me think a second more.
here's a question: What do we want to happen with 16:54
> my $a = 5;
> my $a = 6; # redeclaration error?
or does the new $a simply hide the previous one?
Tene_ I'd expect a redecl error which becomes just a warning in interactive repl. 16:55
pmichaud okay. That makes things very difficult.
jonathan for (i = 0; i < count; i++)
VTABLE_set_pmc_keyed_int(interp, unsorted, i, VTABLE_clone(interp,
uh, sorry
pmichaud my $a = 5;
Tene_ I wouldn't be disappointed by hiding, though. 16:56
pmichaud { my $a = 6; } # redecl error?
lathos Hopefully not.
Tene_ No.
pmichaud agreed. Detecting the difference is the hard part.
doable, but it makes the problem much more complex.
lathos How so? We're in a different lexical scospe.
pmichaud assuming that each input line is its own lexical scope, that's true for the first case as well. 16:57
> my $a = 5;
> my $a = 6; # different lexical scope
anyway, if we treat it as "hiding" instead of a redecl error, then we might be able to get away with saying that each input line is a nested scope within all of the previous input lines. 17:00
Tene_ ... interesting.
pmichaud i.e., we do a "set_outer" of each eval line.
prior to executing it.
jonathan 10,000 lines of REPL use later we have quite some memory usage, but it sounds quite workable. :-) 17:01
pmichaud the other piece that is needed then is a way to inform the compiler of the current lexicals.
jonathan (Plus anyone doing 10,000 lines in the REPL has bigger issues. ;-))
pmichaud and iirc, it's not possible to currently iterate over a lexpad.
Tene_ pmichaud: why can't we use set_outer for eval? 17:02
pmichaud Tene_: we can.
that's not the problem.
the compiler needs to know which symbols are already defined lexicals. 17:03
either that or we turn off strict/warnings when doing REPL.
Tene_ Ah.
pmichaud but even then we have to have some way of knowing if $a is lexical or package scoped.
so we can generate the correct code.
Tene_ Isn't 'no strict' already specced for -e?
pmichaud (or, we turn all variables in to lexicals, which I've also toyed with.)
*into
It's specced for -e, yes. I don't know what people would expect from the REPL. 17:04
regardless, -e is a somewhat different issue than eval in this respect.
(i.e., knowing which variables have been declared already and which have not) 17:05
17:06 Casan joined
Coke ponders again what it would take to switch from pge/tge to pct. 17:07
Coke has to have written this down at one point. =-) 17:08
Andy Anyone talked to chromatic today? 17:12
pmichaud still only 9am on west coast :-) 17:13
17:15 pdcawley joined
Andy pdcawley++ 17:15
pdcawley Hmm? 17:16
Andy I didn't have any place to use your article and didn't have anything to say about it for a Perlbuzz link
pdcawley What'd'I do?
Ah.
Andy but then the SD Times crank came out with that turd pile
so it was great to have. Thanks.
pdcawley has missed the SD times turd pile.
Andy Oh? 17:19
Perlbuzz.com!
purl somebody said perlbuzz.com was fine
dalek r35634 | bernhard++ | trunk/languages/perl6/src/classes: 17:23
: [codingstd] trailing_space.t
review: www.parrotvm.org/svn/parrot/revision?rev=35634
r35635 | bernhard++ | trunk/languages/pipp/src/common (9 files):
: [Pipp] Eliminate usage of macro GET_CONSTANTS
review: www.parrotvm.org/svn/parrot/revision?rev=35635
17:28 particle1 joined 17:33 tomyan left
dalek r35636 | jonathan++ | trunk (4 files): 17:34
: [core] PMC_sub could not check that we actually had something that was a sub underneath, nor did it handle the case where the Sub PMC had been subclassed by a high level class. Lots of code wanted a Parrot_Sub to be handed back by this, and not getting one could lead to segfaults. So this patch plugs those, and also makes it OK to subclass Sub in a high level class and use those subclasses with, e.g. capture_lex and elsewhere. The couple of other seemingly
review: www.parrotvm.org/svn/parrot/revision?rev=35636
r35637 | jonathan++ | trunk/languages/perl6/src (4 files): 17:35
: [rakudo] Re-bless Parrot subs into Block, (Perl6)Sub or Method, so .WHAT answers correctly on them.
review: www.parrotvm.org/svn/parrot/revision?rev=35637
jonathan Those two were some...fun. 17:36
17:50 ask_ joined 17:57 chromatic joined
dalek r35638 | jonathan++ | trunk/languages/perl6 (3 files): 17:58
: [rakudo] Parse submethods and bless them into the Submethod class (also added here). Don't do the correct dispatch on them yet.
review: www.parrotvm.org/svn/parrot/revision?rev=35638
18:08 slavorgn joined
dalek r35639 | bernhard++ | trunk/languages/pipp/t/php: 18:19
: [Pipp] Add TODO test, const in class not named Foo.
review: www.parrotvm.org/svn/parrot/revision?rev=35639
r35640 | bernhard++ | trunk/languages/pipp/src/common (4 files):
: [Pipp] Use package vars for constants
review: www.parrotvm.org/svn/parrot/revision?rev=35640
18:22 alvar joined 18:23 ewilhelm left 18:24 Lorn joined 18:26 davidfetter joined 18:33 Casan joined 18:46 register joined
dalek r35641 | bernhard++ | trunk/languages/pipp/src/pct (2 files): 18:47
: [Pipp] namespace_statement is now namespace_definition
review: www.parrotvm.org/svn/parrot/revision?rev=35641
r35642 | bernhard++ | trunk/languages/pipp (2 files): 18:48
: [Pipp] track the current class in $?CLASS
review: www.parrotvm.org/svn/parrot/revision?rev=35642
pmichaud works on blessing regexes into Regex
jonathan Woo 18:53
davidfetter john woo? 18:54
Whiteknight pmichaud, before I start to do any serious digging, what happens when you try to pass an RSA to get_class? 18:57
pmichaud right now? 18:58
purl puts on her wizard robe and hat
Whiteknight yeah, right now
pmichaud I don't remember. I think it complains that 'xyz' class isn't found.
Whiteknight I don't have time to look at it really until I get home from work, but I want to know what to expect
pmichaud just a sec.
chromatic I think it works. 18:59
It eventually looks up the namespace per the array.
pmichaud "get_string() not implemented in ResizablePMCArray"
see the example in TT #8
chromatic That's an RPA, but he asked about an RSA. 19:00
pmichaud sorry, ResizableStringARray
TT #8 has an RSA.
I just mistyped it here instead of copy+paste as I should have.
chromatic Okay. There's code to handle that case, but it must not work properly. 19:01
NameSpaces are on My List of Hateful Code.
pmichaud currently it tries to stringify the RSA (Bzzt!) and then look up the name of the class using that string (Bzzt!)
that's part of my "we should not be using strings to look up classes" ongoing tirade. 19:02
chromatic Right.
pmichaud it's bad enough that we allow it from PIR, it's worse that Parrot does it internally.
and that Parrot takes things that aren't strings and turns them into strings so that it can do the wrong thing with them.
19:02 MariachiElf joined
Whiteknight thanks 19:03
19:07 ask_ joined 19:08 ask- joined 19:09 braceta left
pmichaud okay, Regex isn't a one line change. Gotta make a PAST::Compiler fix. 19:10
:loadinit doesn't currently work on :compiler(...) blocks. 19:11
pmichaud imagines a good hacky cheat.
dalek r35643 | pmichaud++ | trunk: 19:18
: [DEPRECATED]: Rakudo is leaving the nest after 0.9.0.
review: www.parrotvm.org/svn/parrot/revision?rev=35643
19:19 ask_ joined, cognominal joined
pmichaud hacky cheat didn't work. 19:19
okay, I'll work on Regex a bit later. 19:20
not hard, but not trivial.
jonathan pmichaud: Nor's the dispatcher, but I'm getting there on having *something* working. :-) 19:21
Not dared to run make test yet. ;-) 19:22
pmichaud ;-)
jonathan Screw it, I'll make test..
huh, it all passed...
pmichaud EPIC FA... oh.
jonathan Wow.
pmichaud maybe "make test" doesn't dispatch anything interesting. :-) 19:23
jonathan Indeed.
make spectest has some fails, but that's because I'm not handling PMC inheritance stuff properly yet.
I think that's the primary reason anyway 19:24
jonathan wonders when he's going to run into the evil problem on this task...
Whiteknight hmm. Parrot_oo_get_class calls Parrot_get_namespace_keyed, which calls internal_ns_keyed (src/global.c:125+) which appears to do The Right Thing 19:25
it doesn't appear to stringify the RSA at all
pmichaud Whiteknight: look what happens if the class doesn't exist, though. 19:29
line 222
I'll grant that Parrot_oo_get_class might be working if the class already exists, as would (presumably) be the case for VTABLE_morph 19:30
Whiteknight ah, I see it now
pmichaud so if you wanted to wait on TT #8 and resume VTABLE_morph, I could accept that.
dalek r35644 | fperrad++ | trunk/src/io:
: [win32] warning gcc 3.4.5
: src\\io\\win32.c:230: warning: passing arg 1 of `string_cstring_free' discards qualifiers from pointer target type
review: www.parrotvm.org/svn/parrot/revision?rev=35644
Whiteknight no, if what's happening is what I think is happening, it should be a relatively quick fix
pmichaud I can add some more tickets for other things that fail with arrays and class identification 19:31
jonathan I/someone so needs to fix Inf/NaN on Win32.
I panic everytime I see those fails thinking "oh no, what'd I break" 19:32
pmichaud jonathan: it's okay with me if you mark them as skip/todo.
yes, it lowers our test count -- otoh, we aren't really passing them.
jonathan pmichaud: It ain't bothering me that much.
pmichaud (at least not for Win32)
jonathan pmichaud: And if they don't bother me at all, I'll just never reach the point of being bothered enough to dig in and fix it.
pmichaud we can fix them when we create our own Num PMCs :-| 19:33
jonathan pmichaud: It'd make sense to fix it at the Parrot level.
19:34 riffraff joined
chromatic We need to fix them at the Parrot level. 19:35
pmichaud jonathan: I don't disagree -- otoh, I don't know which will happen first, Rakudo getting its own PMCs or Parrot fixing the ones it has :-| 19:36
in some sense I think Parrot's design is predicated around each language building its own PMC types.
jonathan pmichaud: Even if we write our own, we'll still need to handle that NaN and Inf work differently on Win32. 19:37
pmichaud jonathan: agreed.
although we do have the luxury of declaring that we only work with certain C compilers. 19:38
which Parrot doesn't have.
(I'm not saying we should head down that route, but it's a possibility.)
jonathan I'd really rather not, but yes, it is a possibility.
Coke you could just fix it rakudo and let parrot know they can steal it. 19:39
jonathan OH YES I DIDN'T BREAK CALLING_SETS.T
jonathan has broken that test on a daily basis this week
pmichaud increases the probability factor on the "randomly break this test for jonathan" code. 19:40
jonathan Wow. My dispatcher on the first full spectest run broke only two of 'em. 19:41
pmichaud yay 19:42
jonathan Ah, and they are cases where we inherit a method from a PMC.
pmichaud yummy.
jonathan: (submethods) btw, I've been wondering if Parrot should support submethods.
as in, directly. 19:43
jonathan Perhaps, but it's a case of how to distinguish them. 19:44
pmichaud I was thinking a flag.
jonathan And, do any other languages need them?
pmichaud if there are any flag bits left.
Whiteknight what type of PMC is interp->class_hash?
pmichaud it wouldn't surprise me if we end up coming up with languages that need them.
it's just something I've been wondering. 19:45
chromatic Whiteknight, a NameSpace.
src/global_setup.c:214
Whiteknight okay, thanks
chromatic ack '>class_hash ' src/ 19:46
Whiteknight okay, I think I have a fix for get_class! testing now... 19:47
or, at least a partial fix
for varying definitions of "fix"
jonathan pmichaud: It wouldn't be too hard to do when we get there.
*if we decide we want it
19:50 particle joined, silug joined
Whiteknight no, I fixed the RSA case, but broke the NameSpace case 19:51
19:51 slu joined
Coke wonders if jonathan's recent hacking fixed TT#132 20:00
jonathan Coke: It *may* have. 20:02
But I wouldn't bargin on it.
Whiteknight okay, this issue really isn't as difficult as I was envisioning it to be 20:03
get_class should be mostly fixed by this evening, if I can keep my mind on it
pmichaud, in TT#8, what outputs should each of your two examples have? 20:11
the first one should be "1\\n1", right? What about the second?
Coke jonathan: sadly, no. 20:13
jonathan Ah. 20:19
Same problem space, different problem.
20:19 ruoso joined
Coke ponders, not for the first time, setting ticket bounties. 20:22
Whiteknight ticket boundaries? 20:23
jonathan No, bounties. 20:24
Coke you mean I won't rust?
Whiteknight AH! bounties
Coke </phil a delphia>
Whiteknight yes, I like bounties
and what would we get for completing important tickets?
Coke (esp for those listed here: code.google.com/p/partcl/wiki/ParrotIssues)
Whiteknight: Iunno. a gift card? =-)
some bucks via paypal? 20:25
something purchased off your amazon wish list?
chromatic Contributions to my 401(k)? 20:26
Whiteknight chromatic: I'm interested in that book you blogged about 20:28
Coke chromatic: that's harder for me to arrange.
chromatic Thanks!
Coke, you're telling me.
Coke but I'll give you a ten spot if you fix trac.parrot.org/parrot/ticket/66 20:30
Whiteknight chromatic: if you need a proof-reader or reviewer or something, I'd be happy to do that too
chromatic Coke, did you ever find a PIR version of that? 20:31
Coke chromatic: nope.
dalek r35645 | jonathan++ | trunk/languages/perl6/src (2 files):
: [rakudo] Refactor dispatch. This now calls .HOW.dispatch, where we have a custom dispatcher, which will be filled out with more functionality in the future. Contains support for submethods, which appears to work (need to find/enable/write some spectests).
review: www.parrotvm.org/svn/parrot/revision?rev=35645
Coke chromatic: I may go through those tickets this weekend (the partcl blockers) and see if I can reproduce them.
chromatic That would be lovely. 20:32
Coke git folks: if I want to use git to manage a local repository, how do I set that up?
I only care if I can get to it from my machine. 20:33
chromatic That should be git init.
Beyond that, git doesn't make sense to me.
Coke wonders which of the N git ports is actually git. =-) 20:35
20:38 nnunley joined
Coke chromatic++ # git help 20:39
macport git is git-core 20:42
Tene_ Coke: chromatic is right. 20:48
Coke has created a local git repository 20:50
jonathan Has anyone had any problems building on x86_64 linux? 20:51
(Someone on #perl6 trying to build Rakudo gets a segv in miniparrot.exe)
Coke there's a ticket about that, neh?
trac.parrot.org/parrot/search?q=x86+64 20:52
chromatic jonathan, Allison ran into that yesterday. 20:53
Something in scheduler initialization.
jonathan Ah. :-S
Whiteknight Infinoid mentioned that issue yesterday, but I couldn't duplicate it on my x86_64 Ubuntu box 20:55
PerlJam Coke: How much do you know about git? 20:56
Coke PerlJam: I was given init, and now have status, add, commit, show, and log. 20:57
Coke just wanted something local so he could track work on some scripts and documents.
Coke figures if he has a .git, he can eventually publish them if that matters.
PerlJam okie. Just be aware that "git add" is not the same as "svn add" at all
Coke: do you grok the index?
Coke nope. 20:58
I presume if I do an add and a commit, it's saved.
am i wrong?
Tene_ That's right. 20:59
Coke if so, how is git add not like svn add. 21:00
?
pmichaud because it's "git"? ;-)
PerlJam Coke: you have to "git add" each change
Coke PerlJam: I can't just 'git commit' changes? 21:01
PerlJam sure .. after you've added them :)
Coke .. so add isn't for /files/ ?
chromatic It's for commits you can believe in.
Coke ... ok, then what's commit? 21:02
chromatic: I also don't git it.
PerlJam you can add files just fine. It's just that people get confused when they've just don't "git add file; git commit" and then make changes to file again and have to "git add file" again too.
s/don't/done/ 21:03
(weird typo that)
Coke ... yes, i'm confused.
Tene_ "git commit -a" is the same as "svn commit"
21:03 masak joined
Infinoid I like stg. it acts a little more like you'd expect svn to act. 21:03
Tene_ If you want to use it like svn, that's all you need to know.
Coke Infinoid: unless you expect it to act like svn.
Tene_: thanks.
PerlJam Coke: the "index" is a staging area for commits. "git add" adds content changes to the staging area. "git commit" commits those changes in the staging area to the repo. 21:04
Tene_ "git commit" on its own will only add changes in files that you've run "git add" on since your last commit.
If you want to use it like that, you can run "git diff --cached" to see what's been added and what will be added to the commit when you run 'git commit'
21:05 Lorn joined
PerlJam svn people are also confused when they do "git add file; git diff" and the diff is empty too 21:05
chromatic Darn tootin'. 21:06
pmichaud jonathan: all method calls now go through dispatch?
Coke svn people?
Coke smacks purl.
purl Hit me again, Ike! And next time put some STANK on it!
jonathan pmichaud: Ish. 21:08
$foo.bar(...) will
pmichaud somehow I really feel bad about that.
jonathan $foo.*bar won't because I'm not sure how to make it do so.
pmichaud: It's spec.
pmichaud what's "spec"? 21:09
purl "spec" is the number of tests in the spectest suite
jonathan That methods go through .^dispatch
pmichaud it's spec that every method call has to go through a ....
is that simply the spec on the perl6 wiki or is that actually in a synopsis somewhere?
jonathan See www.perlfoundation.org/perl6/index....mop_oo_api but as far as I can gather, what's under the HOW API is to be spec. 21:10
It's amongst the bunch of "knowhow" stuff that hasn't made it into S12 yet.
pmichaud it's not part of the "as if" rule?
jonathan has badgered a little bit on that but not too much
The what?
purl The is a few features i love in firefox, i will totally love you so. or an article
pmichaud i.e., an implementation is to behave "as if" that's the spec without necessarily doing exactly that 21:11
chromatic purl, forget The
purl chromatic: I forgot the
jonathan Maybe we can cheat somehow. I don't think of a good way off hand.
But, why cheat?
pmichaud because going through an extra level of dispatch this way is slow? 21:12
(note: I haven't measured it)
dalek r35646 | bernhard++ | trunk/languages/pipp (3 files):
: [Pipp] Put class constants into a namespace.
review: www.parrotvm.org/svn/parrot/revision?rev=35646
r35647 | bernhard++ | trunk/languages/pipp/src/pct:
: [Pipp] get rid of special case in the 'constant' action
review: www.parrotvm.org/svn/parrot/revision?rev=35647
r35648 | bernhard++ | trunk/languages/pipp/src/pct (2 files): 21:13
: [Pipp] standardize on lowercase token names
review: www.parrotvm.org/svn/parrot/revision?rev=35648
r35649 | bernhard++ | trunk/languages/pipp/src/pct (2 files):
: [Pipp] remove trailing spaces
review: www.parrotvm.org/svn/parrot/revision?rev=35649
pmichaud because I don't necessarily buy that what appears on the perl6 wiki is spec, absent a declaration from someone that it's so. 21:14
s/someone/someone like TimToady/
jonathan knowhow is in STD.pm and not S12. 21:15
pmichaud I buy that what is in STD.pm is spec, though.
but I don't see 'knowhow' in the wiki 21:16
(at least, not in that page)
jonathan Yes. As I understood it, what is in the HOW API is what you implement, in a metaclass. 21:17
(e.g. inside the knowhow)
pmichaud okay, so the class has to follow the API, does that automatically imply the objects must do so as well? 21:18
jonathan I don't understand what you mean by that?
pmichaud sorry, the HOW has to follow the API
but do the objects always have to go through the HOW?
jonathan So far as dispatch goes, I believe that's through the HOW. 21:19
pmichaud I already know that parts of the oo API are wrong -- for example, it shows BUILD and DESTROY as being submethod in Object when they're really method.
I just don't want to blindly accept smop's view of how OO should work.
If that is indeed the Perl 6 view, then great, but I'd like to see that specced somewhere (more) 21:20
granted, you're doing that particular part of the spec, so you have some latitude to say "this is how it will work".
I just feel like it _really_ disadvantages Rakudo and Parrot. 21:21
jonathan (smop) I don't either - I've already pointed out at least one buy in the HOW API myself (which has been fixed)
pmichaud I would feel better if dispatch were an opcode or otherwise implemented in C, however.
jonathan Oh, I expected that we could do a chunk of what I'm doing now in PIR in C.
pmichaud or if Parrot gave us a way to override method dispatch.
chromatic <aol>me too</aol> 21:22
<pmichaud> or if Parrot gave us a way to override method dispatch.
(Sorry, just had to get the top posting in there)
pmichaud okay.
if we go from the understanding that this approach to dispatch is going to be heavily optimized at some point, I feel better about leaving it there.
I recognize we're likely to have to override Parrot's dispatch mechanism at some point anyway. 21:23
jonathan I know exactly how well the way I'm doing it now isn't going to perform.
I'd like to get the semantics right _first_ and optimize _later_. 21:24
pmichaud let me summarize it this way: I want to make sure that the spec isn't being unduly influenced by any particular implementation (including Rakudo/Parrot) (more)
however, you (and ruoso) are the people primarily working on this part of the spec, and if you think this is indeed the best way to go from a Perl 6 perspective, that's good enough for me. 21:25
I just want to make sure we don't pessimize ourselves out of a usable implementation.
jonathan Sure, I see where you're coming from. 21:26
pmichaud good enough for me. :-) 21:27
jonathan I'm not coding at the moment with a view to performance.
pmichaud I don't care about performance too much now, as long as we can eventually get it back.
that's what I want to make sure of.
(on another topic) -- that's part of what bugs me about some of the mmd changes that went in -- it's lost performance that I'm not sure we'll ever get back, and as such I wish I had known what was being contemplated before it went in. 21:28
at least to be able to comment on it.
chromatic I think we can get them back. 21:29
We just have to stop treating registers as if they were stacks.
... also stop converting to and from C calling conventions via varargs.... 21:30
PerlJam chromatic: when's that going to happen exactly? :)
chromatic I'm waiting for the calling_conventions branch to land.
jonathan Our calling conventions are, currently, _slow_.
pmichaud from a Rakudo perspective, I haven't seen how the opcode mmd is much help.
jonathan ERm
Our current implementation of the calling conventions...
pmichaud maybe it helps with other HLLs, but for rakudo, it's just unnecessary overhead.
jonathan Aye 21:31
dinner is cooked - back soon
dalek r35650 | bernhard++ | trunk/languages/pipp/src/pct: 21:34
: [Pipp] some reformating
review: www.parrotvm.org/svn/parrot/revision?rev=35650
pmichaud jonathan: thanks for the info and discussion, btw :-)
21:35 On_office joined
jonathan pmichaud: Back :-) 21:46
pmichaud: I do think there will be plenty of room for improvement in performance. 21:48
And on the "as if" thing - yes, we can probably skip actually going to .dispatch 21:49
But I really don't want to such trickery, until we have a pretty complete S12 implementation and tests covering it.
*to do
pmichaud well, as I said earlier, I feel much better about .dispatch if it's not PIR that's doing the dispatch.
I'd feel *really* better if we were also fixing our arguments at the time :-)
jonathan *nod* 21:50
cotto trac.parrot.org/parrot/attachment/...cking.diff
shorten cotto's url is at xrl.us/becsvz
jonathan Yes, but if I go write this in C now it's going to be a lot harder to get a first cut of what we actually need.
pmichaud agreed.
in other words, we're fine, I just needed to work it through in my head.
I do wonder how much we've slowed down Rakudo, though. Probably much less than I fear. 21:51
jonathan My thoughts on this are
pmichaud bravely performs a commit without spectesting after jonathan++'s changes.
PerlJam Was there a "optimize" target on the parrot roadmap?
pmichaud waits for RT to come up so he can report the correct ticket number in the commit. (sigh) 21:52
jonathan 1) The dispatch to .dispatch is not so bad - HOW has it right there without walking the MRO.
2) We were walking the MRO anyway in C. We're not re-doing that work again. 21:53
pmichaud oh, that's another question. Why ClassHOW? Shouldn't dispatch simply be a method on P6metaobject ?
never mind, they are.
I see that now.
jonathan They are.
But I ponder we may or may not want to subclass P6Object.
pmichaud I think I would've picked a name other than ClassHOW. Like Metaobject :-) 21:54
we may want to subclass P6Object at some point, yes.
jonathan I followed a smop precedent on the name, but yes. :-)
I think the thinking was <name of package declarator>HOW
pmichaud it will be interesting to balance between having things in Rakudo and P6object -- I expect us to migrate things back-and-forth there for a bit.
jonathan Yeah.
21:54 Whiteknight joined
jonathan We need to not get in the way of other folks using P6Object. 21:55
pmichaud at any rate, I have no problem with Rakudo adding its methods to P6Object.
jonathan But equally keep it functional enough.
Aye, well, it's not a problem while we don't have a bunch of other languages heavily using and wanting to also customize P6Object.
pmichaud Since P6Object's purpose is to provide a Perl 6 like OO interface, it's okay if Rakudo customizes it with Perl 6 features :-)
jonathan True. I don't know how widely applicable you intend it to be. 21:56
pmichaud I'm waiting to see how widely applicable it becomes.
jonathan e.g. is it in runtime/library for the benefit just of PGE and PCT, or are other languages potential customers for it too?
OK.
pmichaud other languages are potential customers.
jonathan In that case, let's just poke our stuff in as I have here for now.
And if we see it's going to cause issues, we can subclass it. 21:57
pmichaud In many ways P6object is what I would've like to seen Parrot's object system be based on :-)
i.e., prototype-based OO
jonathan see or have seen? 21:58
pmichaud have seen
I doubt it will happen.
which is why P6object exists, so that I can have the object system I prefer :-)
jonathan Doesn't mean we can't PMC-ify P6object if we can see it's going to give us wins. 21:59
pmichaud it's more to do with the interface, actually
but yes.
i.e., things like .isa instead of isa $P0, ...
and being able to call ".new" on a protoobject to get a new instance -- stuff like that.
chromatic That *does* help give a nice metaclass feel to a language. 22:00
pmichaud with the exception of .dispatch, I don't see the methods in P6object as having to be heavily optimized for performance, as they're (1) pretty short and (2) not called too frequently.
jonathan *nod*
pmichaud so, PMC-ifying it doesn't feel like it would be that big a win on its own, unless it evolved to replace the existing Class and Object PMCs 22:01
RT slow again.
jonathan Well, there's an vtable interface to implement. 22:02
The theory goes that if you wrote PMCs that also implement such an interface, then it should all work out.
And you should be able to have interop between different class systems based upon that. 22:03
dalek r35651 | pmichaud++ | trunk/languages/perl6/src/classes:
: [rakudo]: Change Grammar.ACCEPTS to Grammar.parse.
review: www.parrotvm.org/svn/parrot/revision?rev=35651
pmichaud sure, but if someone tries to do $P0 = new ['Something'] then it doesn't make it through our shiny .new interface.
(yes, we could fix it to redispatch to that.)
jonathan Does that not go through VTABLE_instantiate? 22:04
pmichaud sends a message to perlbug-admin@perl.org
22:09 particle1 joined
jonathan procrastinates his journal writing until tomorrow 22:15
Infinoid considers procrastinating, but puts it off 22:18
dalek r35652 | cotto++ | trunk/src/pmc: 22:29
: [pmc] convert unionval to ATTR in the Capture PMC
review: www.parrotvm.org/svn/parrot/revision?rev=35652
22:41 register joined 22:43 Limbic_Region joined 22:45 braceta joined 22:55 iblechbot_ joined
dalek r35653 | cotto++ | trunk/src/pmc: 23:00
: [pmc] convert unionval to ATTRs in TQueue
review: www.parrotvm.org/svn/parrot/revision?rev=35653
Tene_ Hmm. I need to look up that patch Jonathan gave me for examining the loadlib/load_bytecode issues. 23:06
23:18 ruoso joined
dalek r35654 | Whiteknight++ | trunk/src (2 files): 23:19
: [Core] Some quick-hack fixes for TT#8. ResizableStringArray should now be more usable with get_class.
review: www.parrotvm.org/svn/parrot/revision?rev=35654
Whiteknight pmichaud, when you get a chance check out r35654. It might fix your RSA get_class problem 23:21
need to clean it up under the hood, but should be functionally what you need
pmichaud I'll look at it, yes. Thanks! 23:26
dalek r35655 | cotto++ | trunk/src/pmc: 23:27
: [pmc] undoing Capture ATTR conversion, since CallSignature extends it
review: www.parrotvm.org/svn/parrot/revision?rev=35655
23:29 TiMBuS joined 23:44 Whiteknight joined 23:53 kid51 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!