Camelia, the Perl 6 bug

IRC log for #parrot, 2008-11-26

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:04 tetragon joined #parrot
00:09 AndyA joined #parrot
00:31 tak joined #parrot
00:51 japhb joined #parrot
00:59 adu joined #parrot
02:02 jimmy joined #parrot
02:43 rurban_ joined #parrot
03:03 leto_ joined #parrot
03:49 adu_ joined #parrot
03:52 davidfetter joined #parrot
04:03 elmex_ joined #parrot
04:14 Coke kids51++
04:23 adu_ hi Coke
04:31 Coke adu: hi
04:31 purl hola, Coke.
04:31 * Coke stares at a memory leak. :|
04:31 adu memory leak?
04:31 purl well, memory leak is http://blogs.sun.com/roller/pag​e/kto?entry=the_art_of_leaking or http://blog.jrock.us/categories/Catalyst/2007/9/2
04:32 PerlJam the memory leak stares back at Coke
04:32 adu heh
04:32 Coke adu: https://trac.parrot.org/parrot/ticket/5
04:33 adu can I fix it?
04:34 Coke I sure hope so!
04:41 Coke actually, that's a lot of memory leaks
04:42 adu i'm downloading partcl
04:43 Coke whee!
04:43 adu I'm surprisingly good with quick fixes
04:43 Coke I am eager to be surprised. =-)
04:43 adu partly because its the only way I get anything done
04:43 adu if I can't fix it within 24 hours I usually forget and browse wikipedia for the rest of eternity
04:54 adu btw, I browsed the parrot core opcodes last weekend
04:54 adu and overall, I was very pleased with it
04:54 Tene :)
04:54 adu but at the same time, it screamed CISC, and yet I am a big fan of RISC... :(
04:55 adu I'm sure someone will write a microcode vm for it someday...
05:03 adu so Tene, how are you?
05:05 tak joined #parrot
05:06 Coke ->
05:15 Tene adu: backing up a server over USB 1.1
05:15 adu ouch
05:15 adu sounds slow
05:23 tak joined #parrot
05:53 adu Process 17167: 16 leaks for 256 total leaked bytes.
05:57 tak joined #parrot
06:04 tetragon joined #parrot
06:40 Hadi joined #parrot
06:40 Hadi left #parrot
06:43 chromatic joined #parrot
07:06 Hadi joined #parrot
07:08 tak joined #parrot
07:12 Hadi left #parrot
07:18 uniejo joined #parrot
07:26 Alias joined #parrot
07:35 japhb joined #parrot
07:51 Theory joined #parrot
08:09 clunker3 joined #parrot
08:15 alvar joined #parrot
08:30 iblechbot joined #parrot
08:55 barney joined #parrot
09:00 dalek r33213 | fperrad++ | trunk:
09:00 dalek : [Lua]
09:00 dalek : - add test log2
09:00 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33213
09:01 Theory joined #parrot
09:25 Alias joined #parrot
10:00 Hadi joined #parrot
10:02 Hadi left #parrot
10:09 ff-wonko joined #parrot
10:42 rurban_ joined #parrot
10:55 apeiron joined #parrot
10:59 magnachef joined #parrot
11:18 jonathan hi all
11:20 jonathan $jonathan.rakudo_day()
11:30 tetragon joined #parrot
11:54 jimmy joined #parrot
11:58 moritz kewl
12:00 jimmy does lexical var mean local var?
12:00 jimmy or partial var?
12:01 jimmy moritz: hello?
12:01 purl Raise purl's hand in the back if you can't hear me.
12:05 moritz jimmy: lexicals aren't what Perl 5 calls local()
12:06 jimmy moritz: I want translate it to other language, and I can't find a suitable word.
12:06 jimmy err. want to
12:11 moritz jimmy: "lexical variable" is a common term in computer science. There are other terms like "local", "static", "private" etc. but they all mean can mean something different in the context of other programming languages
12:11 moritz afk
12:15 jimmy moritz: got it, thanks
12:28 bacek hi there
12:28 purl hi, bacek.
12:29 bacek jonathan: CAN I HAZ LIST ASSIGNMENT?
12:30 jonathan bacek: Not from me - it needs scary parser changes that I don't understand how to do.
12:30 bacek jonathan: btw, it should be something like "ok($jonathan ~~ RakudoDay, 'WE WILL HAVE MORE FEATURES!')" :)
12:31 bacek jonathan: I've implemented list assignment for pynie when I started to learn parrot. It's not so hard :)
12:34 d4l3k_ joined #parrot
12:35 jonathan bacek: Or we can haz fixes, anyway.
12:35 polyglotbot joined #parrot
12:35 d4l3k_ r33214 | jonathan++ | trunk:
12:35 d4l3k_ : [rakudo] Complex multis for various ops should coerce their maybe-not-Complex argument so we don't run into Parrot MMD errors. Do it by introducing .Complex method on Any and calling that.
12:35 d4l3k_ diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33214
12:36 jonathan bacek: Just fixed one of the bugs you reported. :-)
12:36 bacek jonathan: :)
12:37 dalek joined #parrot
12:46 jimmy http://www.perlfoundation.o​rg/parrot_grant_from_nlnet is unavailable
12:53 Hadi joined #parrot
12:56 jimmy rakudo: say #( embedded comment ) "hello, world!";
13:04 dalek joined #parrot
13:05 dalek r33215 | jonathan++ | trunk:
13:05 dalek : [rakudo] Fix declaration and doing of roles in multi-jointed namespaces. Patch partly courtesy of Chris Dolan.
13:05 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33215
13:07 dalek r33216 | jonathan++ | trunk:
13:07 dalek : [rakudo] Add namespaced roles test file.
13:07 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33216
13:09 alvar joined #parrot
13:10 polyglotbot joined #parrot
13:12 alvar joined #parrot
13:13 jonathan joined #parrot
13:19 TiMBuS joined #parrot
13:32 ruoso joined #parrot
13:34 Hadi joined #parrot
13:35 dalek r33217 | jonathan++ | trunk:
13:35 dalek : [rakudo] Fix bug in enum code generation. When adding a vtable method, you need to mark it anon too, otherwise it'll also appear as a normal method.
13:35 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33217
13:51 dalek r33218 | jonathan++ | trunk:
13:51 dalek : [rakudo] Add a missing null check in !clone_attr.
13:51 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33218
13:53 jonathan rakudo: eval { class A { has $.x } }; say A.new(x=>5).x
13:53 polyglotbot No output (you need to produce output to STDOUT)
13:54 dalek r33219 | bernhard++ | trunk:
13:54 dalek : [codingstd] remove a trailing space
13:54 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33219
14:04 jimmy rakudo: say #( embedded comment ) "hello, world!";
14:04 polyglotbot No output (you need to produce output to STDOUT)
14:05 jonathan rakudo bot here seems broken :-(
14:06 jimmy for several days.
14:25 pmichaud joined #parrot
14:27 pmichaud jonathan: (r33214)   does that assume that the Any is a numeric?  I wonder if we should have a .Complex for Str
14:27 PerlJam joined #parrot
14:27 pmichaud ooooh, even better
14:28 pmichaud just create a complex and assign self to it
14:28 pmichaud don't convert to numeric first
14:29 pmichaud does it need to be 'Complex', or should it be 'Perl6Complex'?
14:30 jimmy I saw /*
14:30 jimmy /*
14:30 jimmy in namespace.pmc
14:31 jimmy duplicate '/*'
14:33 jonathan pmichaud: To do it in Str, you should override the Complex method in the Str class.
14:33 jonathan As in, to make Str coerce differently.
14:34 jonathan I used new 'Complex' because all the other code in the file was.
14:34 jonathan And since I know you'd worked on it, I guessed it should be right. ;-)
14:34 jonathan (Of course, those bits may not have been yours...)
14:38 masak joined #parrot
14:44 masak I've been thinking a bit more about my idea about indexing offsets on Whatever.
14:44 masak it doesn't work in the @a[+*] case
14:44 masak also, @a[*] would mean the wrong thing.
14:44 * jonathan finds a spectest that appears to not comply witht he spec
14:44 DietCoke joined #parrot
14:49 pmichaud the complex bits weren't really my code, no.
14:49 pmichaud at least, I don't think they were.
14:50 pmichaud anyway, I'm thinking Any should not assume "numeric".  It should just do a generic assign.
14:50 jonathan If that works, fine with me.
14:50 jonathan It's more right now than it used to be. :-)
14:51 jonathan See my post on the mailing list about coercion stuff/symbol clash issues.
14:52 Coke irc log?
14:52 purl irc log is http://irclog.perlgeek.de/parrot/
14:53 davidfetter joined #parrot
14:57 jsut|work joined #parrot
14:57 dalek r33220 | jonathan++ | trunk:
14:57 dalek : [rakudo] Should check the parameter passed to eval is a string, in line with S29.
14:57 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33220
14:58 pmichaud (symbol clash issue)   We have to implement postcircumfix:<( )> on protoobjects.
14:58 pmichaud See S13.
14:59 jonathan Oh, it's done like that.
15:01 pmichaud hmmm, but it's also supposed to be multidispatched
15:01 jonathan pmichaud: Any idea why inside EXPR we can't do $/.panic(...)?
15:01 jonathan pmichaud: I think that we'll just have to do in the protoobject's invoke something like
15:02 jonathan .param pmc thingy
15:02 jonathan $S0 = self
15:02 jonathan .return thing.$S0()
15:02 jonathan Apart from invoke doesn't provide the parameters yet, unless that Parrot but has been fixed (I think not)
15:03 pmichaud yes, that hasn't been fixed yet, which is why I hadn't implemented this feature yet.  :-)
15:03 jonathan So that is, we delegate it to the methods, and normal inheritnace etc works it out.
15:03 jonathan (by inside EXPR I mean the action method)
15:03 gryphon joined #parrot
15:03 tomyan joined #parrot
15:03 jonathan (it dies with Method 'panic' not found for invocant of class 'PGE;Match')
15:04 pmichaud for some reason whatever is coming back from EXPR isn't a Perl6::Grammar object.
15:04 pmichaud PGE::Match doesn't have a panic method.
15:04 jonathan Hmm
15:04 jonathan It's not becuse it's in the operator expression parser?
15:04 pmichaud it probably because of that.
15:04 jonathan e.g. invoked from..
15:04 jonathan OK
15:04 jonathan Any workarounds?
15:05 pmichaud I'm wondering why the operator precedence parser is returning Match.
15:06 jonathan pmichaud: Aha. Doing $/[0].panic works.
15:06 pmichaud okay, that's good enough for now.  I think that also tells me where the bug is.
15:06 jonathan So the thingy inside it is a Perl6::Grammar.
15:06 jonathan OK, you don't mind me doing that workaround?
15:06 pmichaud that's fine
15:07 pmichaud it's actually more correct
15:07 jonathan win
15:07 pmichaud OPTable returns a "wrapper" Match object around the actual expression; I suspect that wrapper is of type 'PGE::Match'
15:07 pmichaud it's left over from very early designs of PGE, and I haven't been able to get rid of it because some parsers depend on it being there
15:07 pmichaud ...but it doesn't have to be a PGE::Match :-)
15:08 jonathan Well, since the OpTable stuff may go away after protoregexes...
15:08 pmichaud correct.
15:08 pmichaud ltm, actually.
15:08 jonathan Probably not worth a big investment of time.
15:08 jonathan Oh yes, ltm
15:08 pmichaud agreed.
15:08 jonathan Larry was making my head explode last night by talking about that.
15:09 pmichaud I saw.  :-)
15:09 jonathan I hope you followed the parsing side of that better than me. :-)
15:09 pmichaud in general, yes.  :-)
15:09 jonathan The most reassuring bit was that if I get the parametric roles right for classes etc, the grammar case should fall out fairly naturally.
15:10 pmichaud yes.
15:12 dalek r33221 | jonathan++ | trunk:
15:12 dalek : [rakudo] Call panic on sub-nodes of EXPR nodes, which end up being PGE::Match rather than Perl6::Grammar. This means we show the intended, helpful error.
15:13 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33221
15:14 Hadi left #parrot
15:14 jonathan Ah, down to 154 tickets. :-)
15:14 jonathan Maybe we can get it down to 150 today.
15:17 masak I heard that! >:)
15:17 * masak goes away to knock Rakudo around some more
15:21 tomyan joined #parrot
15:27 dalek r33222 | jonathan++ | trunk:
15:27 dalek : [rakudo] When we fail a type check on a parameter, report the name of the thing we were calling.
15:27 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33222
15:28 * jonathan hates it when svn ci hangs
15:32 PerlJam What's the rm_miniparrot branch all about?
15:34 Lorn joined #parrot
15:34 Coke removing the --miniparrot option to Configure.pl
15:35 Coke (which is not related to the miniparrot executable that is built)
15:36 PerlJam why?
15:39 dalek r33223 | tewk++ | trunk:
15:39 dalek : [NCIGEN] get rid of all the c99 references except the Grammar itself
15:39 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33223
15:42 dalek r33224 | tewk++ | trunk:
15:42 dalek : [ncigen] MANIFEST fixes
15:42 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33224
15:46 jhorwitz joined #parrot
15:48 * Coke has to revert a change to an svn file; is it better conceptually to commit a reverse of the last change to the file, or to svn cp the old version you want to head?
15:49 Coke I would lean towards the latter.
15:54 * Coke does the former out of expediency.
15:54 gryphon joined #parrot
16:09 jhorwitz Coke: i lean towards the former cuz you can test it first.  :)
16:10 dalek r33225 | jonathan++ | trunk:
16:10 dalek : [rakudo] Refactor .= operator so that it now handles having a container looked up from a keyed access on the LHS.
16:10 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33225
16:13 pmichaud ... I wonder if infix:<.=>  could be written as a normal sub
16:14 pmichaud anyway, this works for now.
16:14 Juerd joined #parrot
16:14 jonathan pmichaud: Possibly.
16:16 pmichaud jonathan: I'm looking at refactoring the codegen for enum a bit -- it seems longish to me
16:20 jonathan pmichaud: There's more pressing things...I've still got some bits of enums to get complete straight how we'll do anywya.
16:20 jonathan *completely
16:20 pmichaud okay.  I don't think we should be generating the methods in the PAST, though.
16:20 pmichaud it'd be easier to do with a   !keyword_enum   and !enum_add_value   calls.
16:21 jonathan Maybe.
16:21 jonathan We do need to generate a method that returns a particular value.
16:21 pmichaud we could have a generic method that does it using a property.
16:22 jonathan We could.
16:22 jonathan We'd then have to clone it once per enum value to attach the property.
16:22 pmichaud sure
16:22 pmichaud but since we're having to do add_method anyway, that's not a big deal
16:22 jonathan Making more GC'able objects, rather than having a bunch of methods that are PMC constants.
16:22 Juerd left #parrot
16:22 jonathan OTOH, it'd be vastly less bytecode.
16:23 jonathan Trade-offs.
16:23 pmichaud I'm thinking it can all be hidden behind an !enum_add_value call.
16:23 pmichaud but yes, it would make more gc'able objects.
16:24 jonathan Let's leave it for now.
16:24 pmichaud I'm thinking shorter actions.pm would make for faster compiles, too :-)
16:24 jonathan Getting the parameter stuff done, list assignment etc is much, much better use of your time.
16:24 jonathan Not to mention of more value to Rakudo users.
16:24 pmichaud yeah, I just don't like seeing huge code
16:25 jonathan Sure. I'll put enums in my "things to revisit" list.
16:25 pmichaud I mean, enum_declarator is over 300 lines of code
16:25 jonathan OH RLY?
16:25 * jonathan should delete some line breaks ;-)
16:25 jonathan That is enormous though, point taken.
16:25 pmichaud so much of it could be done via calls instead of in the PAST
16:26 jonathan Aye, if we take the clones with properties approach, yes.
16:26 pmichaud well, even leaving the methods as they are now, !keyword_enum could do the creation of the role and class
16:27 pmichaud and adding the attribute
16:27 pmichaud and attaching the vtable methods
16:27 jonathan If we're getting generationalish GC in the not too distant future, we probably can get away with that approach.
16:27 jonathan Sure.
16:27 jonathan OK, leave it with me, I'll try and get a refactor in the not too distant future.
16:27 pmichaud is the 'enum' property simply signifying that the class is really an enum?
16:27 jonathan Yeah
16:28 pmichaud it might be more useful signifying the name of the enum
16:28 pmichaud (as well as the fact that it is one)
16:28 pmichaud get_string, get_number, etc. could then use that property to dtrt
16:28 pmichaud and we don't need to clone those
16:28 jonathan Hmm.
16:28 jonathan That could work.
16:29 pmichaud the only reason I'm looking at enum is because I want some -Ofun too.  lexicals was not fun.
16:29 pmichaud refactoring to simplify code is -Ofun for me :-)
16:29 * moritz points pmichaud to lexicals+enums, just for completeness sake
16:29 pmichaud ...lexicals+enums?
16:29 jonathan Lexical enums.
16:30 pmichaud ahhhh
16:30 jonathan my enum Blah <Foo Bar>;
16:30 jonathan Shoudln't be hard.
16:30 moritz no, I meant something different
16:30 moritz RT #60826
16:30 tomyan left #parrot
16:30 pmichaud also, the background noise level here at the house today is such that I'll be limited in doing any significant design work.
16:31 pmichaud ah, that's subtypes containing lexical closures
16:31 moritz right
16:32 pmichaud I'm leaving subtypes to jonathan++ for now :-)
16:32 moritz lexical closures are the other TODO item from yesterday night
16:32 jonathan moritz: I pretty much know how to do that - thee's an RT for it, right?
16:32 pmichaud 60826 :-)
16:32 pmichaud closures are already "lexical"
16:32 tak joined #parrot
16:32 * jonathan has a ton of RTs open in his browser
16:32 moritz jonathan: #60822 (lexical subs)
16:33 pmichaud my $x = sub { ... } should work.
16:33 pmichaud can I have a shorter test than the man-or-boy one?
16:34 jonathan I thought that used to work... :-S
16:35 pmichaud yes, it should work.  I can't think of any reason it doesn't.
16:35 jonathan > my $x = sub { say 42 }; $x()
16:35 jonathan 42
16:35 jonathan WFM
16:35 pmichaud WFMT
16:35 * jonathan checks the ticket
16:36 moritz that man-or-boy tests works in pugs, so I'm pretty sure it's not borked
16:36 * jonathan suspects t/spec/integration/man-or-boy.t is doing something else
16:36 pmichaud IN FACT:
16:36 pmichaud > my &foo = sub { say 'hello'};    foo();
16:36 pmichaud hello
16:36 pmichaud >
16:36 purl hi, pmichaud.
16:36 jonathan purl WIN
16:36 purl http://xrl.us/youwin
16:37 leto joined #parrot
16:37 pmichaud and in that case, foo() is lexical.
16:37 jonathan Aye.
16:37 jonathan Making my sub foo work should thus be trivial.
16:37 pmichaud oh wait
16:37 pmichaud no it's not.
16:37 pmichaud it's still going into the package.
16:37 jonathan Oh?
16:38 pmichaud yes, I suspect something with my declarator
16:38 jonathan Hmm.
16:39 jonathan Oh, I have an idea what that may be...
16:41 pmichaud the "for @?BLOCK {...}" meme needs fixing.
16:41 moritz I can't redruce the failure in the man-or-boy test :(
16:42 jonathan pmichaud: I think we're eyeing the same bit of code.
16:42 jonathan Around line 2556?
16:42 pmichaud yes.
16:42 pmichaud I wonder if &foo should simply be doing find_name lookups
16:43 pmichaud instead of lexical/package.
16:43 pmichaud since find_name pretty much dtrt already.
16:44 jonathan Well, it's the storage that is the bug here
16:44 jonathan Ah
16:44 jonathan $?BLOCK.symbol($name, :scope($scope));
16:44 jonathan It sets the scope in scope_declarator - but doesn't update the scope of the thingy being declared
16:45 hercynium joined #parrot
16:45 pmichaud you mean line #2329 ?
16:48 jonathan Adding at line 2327 "$past.scope($scope);" makes it declare it lexical.
16:48 jonathan And then it works.
16:48 jonathan (because it emits foo() which does a find_name, I believe)
16:48 pmichaud foo() does a find_name, yes
16:48 pmichaud but we also have to prevent the sub from being installed in package scope
16:48 jonathan Adding that line fixes that.
16:49 pmichaud no, because the sub still has a name
16:49 pmichaud so PCT will generate   .sub 'foo'
16:49 pmichaud which means it'll go into the package.
16:49 jonathan > my &foo = sub { say "hi" }; foo()
16:49 jonathan No?
16:49 pmichaud oh, I was thinking of the     my sub foo { ... }      case
16:49 jonathan Oh, that case.
16:49 purl hmmm... that case is going to the supreme court
16:49 pmichaud purl, forget that case
16:49 purl pmichaud: I forgot that case
16:49 jonathan Damm right purl!
16:50 pmichaud yes, the my &foo = sub { ... }    will work with that addition.
16:50 jonathan pmichaud: Yes, in that case we gotta strip the name.
16:50 jonathan OK, that's the one I was trying to fix. :-)
16:50 pmichaud I'm wondering why $past.scope(...)  wasn't there in the first place.
16:51 jonathan Same.
16:51 jonathan I think it's a mistake it wasn't.
16:51 Coke 42+580
16:51 purl 622
16:51 jonathan Doing spectest now to see if there was a reason...
16:51 pmichaud no, its not a mistake.
16:51 pmichaud we don't normally set scope on variables.
16:52 pmichaud it's the fact that the other one is setting package scope that is a mistake.
16:52 pmichaud normally we leave the :scope attribute blank, and let the block's symbol table determine the type.
16:52 jonathan Well, it doesn't know at that point that it's in a declaration...
16:52 moritz did anybody change parsing in the last 24H?
16:52 pmichaud what doesn't know?
16:52 jonathan Inside variable
16:52 pmichaud does it need to know?
16:52 jonathan I'm not sure
16:52 pmichaud why do we need to be setting package scope?
16:53 jonathan I'd assume that code is there, to make something work that didn't otherwise.
16:53 jonathan I guess it's because subs aren't registered in any symbol table.
16:53 jonathan Because if they're package ones, they never get put in any block's symbol table.
16:53 pmichaud line #2571 is the incorrect line.
16:53 Coke (adding perl6 to unified languages test harness) - is this rejectable if rakudo is eventually leaving the nest PLUS we have smolder?
16:54 pmichaud Coke: yes, it's rejectable.
16:54 Coke RT #41675
16:54 jonathan if $twigil eq '?' {
16:54 jonathan $past.scope('lexical');
16:54 jonathan }
16:54 jonathan ?
16:54 pmichaud if $<sigil> eq '&' {
16:54 pmichaud $past.scope('package');
16:54 pmichaud we shouldn't force package scope on '&' variables.
16:54 jonathan What happens if we remove that chunk?
16:55 pmichaud it won't know what to do in the general case where &foo isn't scoped.
16:55 jonathan Right, which is why it's there.
16:55 pmichaud but it's wrong.
16:55 pmichaud my &foo = sub { ... };    &foo();
16:55 pmichaud the second &foo has the wrong scope.
16:56 pmichaud because that line is forcing it back to package scope.
16:56 jonathan No, because by then it's go an entry in the block's symbol table?
16:56 jonathan Ok but look what happens in the loop below.
16:56 Coke pmichaud: ah. that ticket also mentions compilers/nqp, which we -do- want as part of 'make test'; retoolting ticket.
16:56 pmichaud ah, yes, the loop below.
16:56 jonathan It's saying "we default to package unless we've got evidence otherwise"
16:56 pmichaud that's still the wrong approach.
16:57 jonathan And the right one is?
16:57 pmichaud I'm still thinking, but I don't like all of the twiddling of scopes.
16:57 pmichaud fix, unfix, refix is wrong.
16:57 pmichaud my best guess is that &foo should be 'name' scope.
16:57 barney joined #parrot
16:58 jonathan OK, but variable_declarator would still have to override that?
16:58 jonathan Wait, what's name scope?
16:58 jonathan Or it doesn't exist yet?
16:58 pmichaud the equivalent of find_name
16:58 pmichaud (doesn't exist yet, perhaps it should.)
16:58 jonathan That'd make this cleaner, I suspect.
16:58 pmichaud and also more correct
16:58 jonathan Aye
16:58 pmichaud so that '&foo' and 'foo' actually refer to the same symbol.
16:59 jonathan But we would still need that line adding in variable_declarator.
16:59 jonathan So the declaration ends up knowing it's a lexical declaration.
16:59 pmichaud no
16:59 pmichaud that's the point
16:59 jonathan Unless you make :isdecl with :scope('name') do the same as lexical.
16:59 pmichaud oh, I see.
16:59 pmichaud hrm.
17:00 pmichaud oh, no!
17:00 pmichaud the PAST tree should default to 'name' scope.
17:00 pmichaud so any variable that doesn't have a :scope defaults to name scope if there's no intervening scope declaration on a block
17:00 jonathan Would that not foil compile time detection of undeclared variables?
17:00 Coke 42+572
17:00 purl 614
17:01 Coke (stalling tickets)
17:01 jonathan As in, we'd have to implement it ourself...
17:01 pmichaud thinking.
17:01 purl Oooh he is soooo fine!!!
17:03 pmichaud I think the real solution is to first refactor the    for @?BLOCK { ... }    meme
17:03 pmichaud there are several places that we do that sort of loop that ought to be cleaned up
17:04 jonathan Refactor as in, pull out the lookup into a subroutine?
17:04 pmichaud yes
17:04 pmichaud or a method somewhere
17:04 TimToady it's quite possible that @?BLOCK is itself a really bad idea
17:05 pmichaud TimToady: it's very useful, though.
17:06 jonathan pmichaud: Like a 'sub find_symtable_entry($symbol_name)'
17:06 jonathan ?
17:06 jonathan That looks through them?
17:06 pmichaud well, I don't want it to be tied to @?BLOCK
17:06 jonathan Ah.
17:06 pmichaud because we may have @?CLASS, @?PACKAGE, etc. as well
17:06 pmichaud but yes, something like that.
17:07 jonathan Well, we can put the lookup in @?BLOCK into it for now, then add the others later on.
17:08 pmichaud I'm not too fond of the 'for now' solutions.
17:08 pmichaud They tend to replicate themselves.
17:08 pmichaud or, as XP says, "refactor mercilessly"
17:10 jonathan OK, but having one place to change later instead of a few that we have now is surely a good refactoring?
17:10 pmichaud right
17:12 jonathan I'm not so sure about defaulting to a name scope if there isn't one. I agree it's a good idea to be able to set it, however.
17:12 jonathan And that we could do it to eliminate the mess we have for subs.
17:12 pmichaud I agree that defaulting to name scope isn't so good.
17:13 jonathan And I'm not so opposed to the combination of name scope and isdecl being the same as lexical declaration.
17:13 jonathan But I don't know we want to make that happen just for this one-off case where it's useful...
17:14 jonathan OTOH, I'm not sure what other useful thing it could do.
17:14 pmichaud I just know that the current approach has a design stink.
17:14 jonathan Yes.
17:14 pmichaud so I'm not in favor of trying to patch it to make it work.
17:14 Coke Andy (or anyone): is it possible to disable warnings in parrot when building a specific file?
17:15 Andy no
17:16 Andy not the way we do make files
17:16 Andy what are you stumpbling on?
17:16 Coke Do you have a recommended approach for dealing with our lex/yacc generated files?
17:16 tewk We have a perl script that actually call the c compiler.
17:17 Coke ew.
17:17 tewk We could add special make rules for lex yacc, or modify the CFLAGS in tools/dev/cc_flags.pl
17:17 Coke (mainly because we're trying to reduce the # of times we invoke perl)
17:18 pmichaud (lost connection for a bit there)
17:18 dalek joined #parrot
17:18 pmichaud also, <variable> will be able to know if it's in a declaration, because the IS_DECL contextual variable will be set.
17:18 pmichaud so maybe I need to add context variables.
17:19 jonathan pmichaud: OK. But you'd rather think over the name scope a bit more first too?
17:19 jonathan (same)
17:19 jonathan Yay! :-)
17:19 tewk Coke: ever wondered why you don't get whole gcc command line when compiling the core parrot c files?
17:19 jonathan Was that going to happen in PCT?
17:19 jonathan Or be special to Rakudo?
17:19 tewk tools/dev/cc_flags.pl is the answer.
17:19 pmichaud I'm not exactly sure where it will go.
17:19 pmichaud It's incredibly useful, so likely PCT somewhere.
17:19 jonathan I guess there's the "do it in Rakudo first and move it later" approach.
17:19 Coke tewk: are we already invoking perl for each compile?
17:19 Coke "ew"
17:19 pmichaud oooh, perhaps it belongs in NQP
17:20 Coke though that file refers to config/gen/cflags/root.in, which doesn't seem to exist.
17:20 jonathan Wouldn't that imply supporting it in PCT?
17:20 pmichaud yes
17:20 pmichaud but being able to say   $+IS_DECL  in NQP would be nice.
17:20 Coke tewk; any chance you could look at RT# 53356?
17:20 jonathan I guess the real question is, how we mark things that are context.
17:20 jonathan Oh, yes.
17:20 jonathan The Rakudo approach is probably with a property.
17:20 pmichaud yes.
17:21 Coke (which basically to avoid getting the 'missing default case' warning for imclexer.c
17:21 tewk Coke: for all c files and pmcs c file yes we invoke perl, dynpmc seem to build without it.
17:21 pmichaud but having PCT support context variables would be very nice.
17:21 tewk I can look at RT# 53356 tonight.
17:21 Coke That seems odd to me that we're doing that.
17:21 Coke (is it gaining us anything other than a quieter build?)
17:22 Coke (wonder if that would speed up our windows build time at all by just using a standard make rule)
17:23 * pmichaud wonders how contextual variables mix with closures.
17:23 tewk grep Makefile for tools/dev/cc_flags.pl, there is a comment there.
17:24 jonathan I think we just set them up as lexicals tagged with the context property
17:24 jonathan And it *should* just fall out of that.
17:25 pmichaud no, because contextuals follow the callers' scopes, not lexical scopes
17:25 jonathan Yes, I know.
17:25 jonathan But your caller will be in the scope that had the correct lexicals, I'd imagine.
17:25 Coke ah. we already have the infrastructure in place for what I want. freaky.
17:26 jonathan As in, I don't think we'd need to do anything special to make this work.
17:26 Coke tewk++
17:26 pmichaud yes we do
17:26 jonathan Oh?
17:26 pmichaud we don't have a way of doing 'find_lex' in anything other than the current scope.
17:26 pmichaud so we have to walk through all of the callers, and then walk through their outer scopes
17:26 kj joined #parrot
17:26 pmichaud and I don't think we have the "walk through their outer scopes" piece
17:27 jonathan Oh, yes, that hadn't occured to me...
17:27 jonathan Hmm.
17:27 Coke tewk: thanks for the pointer there. I'll take 53356 and do some minor cleanup after lunch.
17:27 tewk sounds good.
17:27 jonathan Yes, interpinfo ain't quite powerful enough.
17:28 pmichaud I could probably put together a "works enough" approach.
17:28 pmichaud but have to think about that a bit more also.
17:28 particle joined #parrot
17:28 jonathan It's easy from C. I'm not sure we have a way from PIR.
17:29 pmichaud I've been thinking it might be useful as an opcode.
17:29 pmichaud 'find_context'
17:29 * particle 's cable internet is out, so he's suffering through a mobile phone connection :(
17:30 jonathan find_context?
17:30 jonathan What would that do?
17:30 pmichaud or find_contextual
17:30 pmichaud $P0 = find_contextual '$a'
17:30 jonathan Ah, find_contextual is nicer.
17:30 jonathan That's probably not a hard op to write.
17:30 pmichaud yes, it's easy.
17:30 jonathan Apart from, the op needs to know about the context property.
17:31 pmichaud well, in the general case I don't think Parrot should be bothered with that
17:31 pmichaud so yes, it does beg the question of how we'd handle that
17:31 jonathan OK, so how would we stop it finding things we don't want...
17:31 jonathan Hmm.
17:31 pmichaud we'd probably need a way to do it from PIR
17:31 pmichaud (also)
17:32 pmichaud really there ought to be a way to do it from PIR, so maybe we need to add some introspection for that.
17:32 pmichaud all of which would be easier when Contexts become PMCs :-)
17:32 jonathan Or we write a dynop for Rakudo and have a way of saying "use that one instead"
17:32 jonathan Yeah.
17:32 pmichaud oooh, dynop can work also.
17:32 jonathan But if you want it in NQP, that maybe points away from dynop.
17:33 pmichaud NQP can use the Parrot opcode
17:33 jonathan Unless the NQP one wouldn't require 'is context' and would find worreva.
17:33 pmichaud right.
17:33 pmichaud I'm thinking 'is context' is a Perl 6-specific feature, not a Parrot one.
17:33 jonathan Yes, I think so.
17:33 particle jonathan: going back to an earlier commit today, you marked :vtable subs as :anon
17:34 particle instead, the imcc behavior should change so :vtable subs are automatically :anon
17:34 jonathan particle: I wasn't generating IMCC.
17:34 jonathan particle: erm, PIR
17:34 jonathan I was calling add_method on the Class PMC
17:34 pmichaud add_method need :anon?
17:34 pmichaud why?
17:35 pmichaud shouldn't add_method assume anon already ?
17:35 particle http://www.parrotvm.org/svn​/parrot/revision?rev=33217
17:35 pmichaud particle:  right, those are arguments to 'add_method'
17:35 jonathan pmichaud: Because if you do pass the :vtable flag and don't pass :anon, it enters the thing in the methods table in the Class as well as in the vtable overrides table.
17:35 pmichaud jonathan: so, :anon in this case means "don't make it a method"?
17:35 particle right, it should assume anon. i'm loading the diff (slowly) now
17:36 pmichaud that sound wrong.
17:36 pmichaud instead we should have 'add_vtable'
17:36 jonathan anon means in this use case, just make it a method, it should only be a vtable method.
17:36 jonathan Well, we do as VTABLE methods have two distinct ones.
17:36 pmichaud that sounds like too much overloading of 'anon'
17:37 jonathan pmichaud: Actually my first instinct was the fix the Class PMC, then I thoguht...wait...it's arguably not broken and we should probably have a deprecation cycle or whatever...
17:37 jonathan I'm not sure if Class PMC should change.
17:37 jonathan But yeah, it surprised me that I needed to add :anon.
17:37 pmichaud I think that     class.'add_method'('foo', 'anon'=>1)     is bizarre.
17:37 jonathan You'd never do it like that
17:38 particle ah, now i see the commit.
17:38 jonathan That'd be a no-op
17:38 pmichaud right.
17:38 jonathan You'd do class.'add_method'('get_string', 'vtable'=>1, 'anon'=>1)
17:38 pmichaud and I think that   class.'add_method'('foo', 'vtable'=>1, 'anon'=>1)   is equally bizarre.
17:38 jonathan Personally I'd rather kill off anon
17:38 jonathan If you want it as a vtable and a method you can do two calls
17:38 jonathan One with vtable => 1 and one without
17:39 pmichaud it should be   class.'add_vtable'('foo', $P0)
17:39 pmichaud keep it separate from 'add_method'
17:39 jonathan add_vtable_override probably to match the actual VTABLE method itself
17:39 jonathan But yes, that'd work too.
17:39 pmichaud I don't think we need '_override' -- that's somewhat assumed
17:39 pmichaud even for 'add_method'  we're "overriding"
17:40 jonathan heh
17:40 particle class.'add_vtable'('get_string', $P0)
17:40 jonathan OK, I'm not arguing it's a good name, I'm arguing it should match what the VTABLE method that does the same is called
17:40 particle or add_vtable_entry
17:40 jonathan oh please
17:40 jonathan add_vtable_method :-)
17:40 jonathan It's a method, dammit. :-)
17:40 pmichaud except allison and particle say they aren't.
17:40 pmichaud "vtable function" is the name I was told to use.
17:41 particle that's what the pdd says
17:41 pmichaud a-n-y-w-a-y
17:41 jonathan It has an invocant. They have inheritance semantics. We work pretty hard to make them look like methods.
17:41 jonathan ...but hey, let's call them something else...
17:41 jonathan :-|
17:41 pmichaud jonathan: I made this argument once before -- you're welcome to make it also for me :-)
17:42 particle it's written in C, there are no methods :P
17:42 particle 'entry' is method/function agnostic
17:43 pmichaud anyway, I'd be very much in favor of    'add_vtable_whatever'   being added to the Class PMC
17:43 particle however, there's a good argument to make it match the documentation
17:43 particle yep, me too
17:43 pmichaud then we can use that instead of the 'anon'
17:43 jonathan pmichaud: I'm so going to call it that. :-)
17:43 * tewk prefers _thingy
17:43 jonathan Thing is, the v-table method for adding these is called add_vtable_override
17:44 jonathan ...which suggests they are method ;-)
17:44 * jonathan ponders just writing something to the list and letting someone else decide
17:44 pmichaud jonathan: I'm searching for where I had this exact same discussion :-)
17:44 PerlJam what aren't they "methods"?
17:45 * kj thinks they're messages to objects... where did I leave my smalltalk book :-)
17:45 PerlJam Isn't that more a function of how it's used rather than some intrinsic property of the thing?  Like "w" is a vowel in the word "cwm".
17:45 particle in parrotsketch this spring?
17:45 particle i forget when and where
17:47 pmichaud I think it was much more recent than that.
17:47 pmichaud I'm thinking it was in october sometime.
17:47 pmichaud irclog's search sometimes leaves much to be desired.  :-|
17:47 jonathan Ah, if it was I'd not remember it.
17:51 jonathan OK, so anyway, I guess we want a message to the list to discuss this/get an answer.
17:51 jonathan (Having a separate method. I don't care what it's called...)
17:51 pmichaud I think we should go ahead and create the method.
17:51 pmichaud "forgiveness instead of permission"
17:51 jonathan pmichaud: Let's create it
17:51 jonathan And then deprecate add_method's :vtable and :anon flags
17:51 pmichaud I can't see any reason why    "add_method"('foo', $P0, 'anon'=>1, 'vtable'=>1)   makes more sense.
17:51 jonathan And then rip 'em out after the next release.
17:52 jonathan If 'vtable'=>1 *just* entered it into the vtable, and that was it, I'd be happy.
17:52 jonathan The fact you have to pass anon too puts it on the sucky sdie.
17:52 jonathan *side
17:53 jonathan I'm going to name it consistently with the already-approved vtable method. That way forgiveness might be easier to come by. ;-)
17:53 jonathan And by vtable method, I mean vtable whatever, of course.
17:57 dalek r33226 | bernhard++ | trunk:
17:57 dalek : [Pipp] use 'command_line' instead of 'evalfile', so that
17:57 dalek : the target option is honored and Test.pir will be generated
17:57 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33226
17:57 pmichaud it must not be in the irclogs, or I don't know how to search for it.
17:57 jonathan It's not in parrotsketch, or you were searching that anyway?
18:00 bacek joined #parrot
18:02 jonathan pmichaud: OK, got a patch ready, just testing.
18:03 * barney is reading http://www.stefan-marr.de/art​ikel/rfc-traits-for-php.html
18:08 jonathan barney: Parrot will make that pretty easy to implement. :-)
18:08 jonathan ...much easier than roles in Perl 6...
18:10 barney Sadly there is a mass of unimplemented must haves, that comes first
18:11 barney BTW, is there support for protected class members in PAST ?
18:12 dalek r33227 | jonathan++ | trunk:
18:12 dalek : [core] Deprecate the :vtable and :anon flats on the add_method method in the Class PMC, and create a new add_vtable_override method which you call to add overrides. The overloading of the meaning of anon with other places in Parrot, plus how rarely you'd likely want to enter something as a method under the same name as the vtable method/function/whatever, made it more confusing than useful.
18:12 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33227
18:12 dalek r33228 | jonathan++ | trunk:
18:12 dalek : [rakudo] Use the Class PMC's new add_vtable_override method.
18:12 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33228
18:12 jonathan pmichaud: There you go. :-)
18:12 jonathan pmichaud: And we lose 24 lines from enum_declarator.
18:12 pmichaud yay.
18:12 jonathan barney: What are the semantics of those? Only subclasses can see them?
18:13 barney Yes
18:13 jonathan I don't think we provide anything "out of the box" for that.
18:13 jonathan How were you handling privates?
18:13 jonathan In Rakudo we name-manage them.
18:13 jonathan *mangle
18:14 jonathan A similar scheme could work here.
18:14 barney I don't handle members yet.
18:14 jonathan Apart from in Rakudo we have different syntax for calling our privates, so it's trivial...
18:14 PerlJam barney: the best part about that document is this sentence: Since it isn't a purely academic concepts, there are already languages supporting Traits out there. Squeak, Perl6, Scala, Slate, Fortress and even for C#/Rotor implementation are available.
18:14 jonathan Yay, they mention Perl 6. :-)
18:15 PerlJam :-)
18:15 jonathan pmichaud: So, what to do on the scope/contextuals/lexical subs stuff?
18:15 jonathan Leave it with you?
18:15 jonathan Or is there anything you want me to hack on?
18:16 pmichaud I'm having trouble getting started -- too many distractions around here.  :-|
18:16 pmichaud yes, I'd like to do contextuals -- I'll fix the "my sub" issue.
18:16 pmichaud if you want to go ahead and submit the one-line patch to get it to work that's okay.
18:16 pmichaud I'll just refactor it later.
18:17 jonathan OK.
18:19 jonathan When do you plan to start looking at the parameters changes?
18:19 pmichaud after lunch.
18:19 jonathan I'm going to be offline Mon/Tue next week, FYI.
18:19 jonathan Oh, OK. This week. :-)
18:19 pmichaud yes, this week.
18:19 pmichaud lots of stuff are depending on that.
18:19 jonathan I thought you might want some -Ofun first. :-)
18:19 pmichaud refactoring parameters is -Ofun
18:20 pmichaud it's just also involved.
18:20 pmichaud I'll probably do the PCT updates first to allow String/Integer/Float directly in the PAST tree.
18:20 jonathan OK.
18:23 jonathan Hmm. t/spec/integration/man-or-boy.t give ms a parse error...
18:24 moritz jonathan: same here, but I'm pretty sure it worked yesterday night
18:24 moritz rechecking...
18:24 Tene I remember it failing at least during my day yesterday
18:24 Tene parse error
18:24 purl i guess parse error is not caused by missing files
18:25 moritz oh, indeed
18:26 moritz I wonder what I did wrong
18:26 pmichaud afk, lunch
18:27 jonathan oh, youch
18:27 jonathan If you stick a ; after the final } of sub A
18:27 jonathan Then it works.
18:27 jonathan Erm
18:27 jonathan as in, it compiles
18:28 moritz and then the ^@list bug(?) hits
18:28 jonathan yes
18:29 wolverian joined #parrot
18:29 moritz I've just commited a simplified version
18:29 moritz that dies on the second iteration
18:30 dalek r33229 | bernhard++ | trunk:
18:30 dalek : [codingstd] add a VERSION section to PDD 14
18:30 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33229
18:32 pmichaud make it 0..^@list and it should work :-)
18:32 pmichaud at least that part of it.
18:32 pmichaud afk, lunch
18:34 dalek r33230 | jonathan++ | trunk:
18:34 dalek : [rakudo] Make 'my &x = sub { ... }' store the sub lexically.
18:34 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33230
18:40 moritz jonathan: t/spec/S12-enums/as-role.t fails here ("Method 'add_vtable_override' not found for invocant of class 'Class'")
18:41 moritz jonathan: same for t/spec/S12-enums/basic.t
18:41 moritz jonathan: r33230
18:42 bacek joined #parrot
18:42 rurban_ joined #parrot
18:42 jonathan moritz: You need to update your Parrot.
18:43 moritz jonathan: will do and re-test ...
18:44 moritz ok, all PASS
18:46 particle joined #parrot
18:47 jonathan Great. :-)
18:56 chromatic joined #parrot
18:56 gryphon joined #parrot
18:58 jonathan moritz: Well, I've made it not crash now, but it doesn't get the right answers still...
18:59 jonathan oh, hmm
18:59 moritz jonathan: locally? the repo version still crashes for me
18:59 gryphon joined #parrot
19:00 jonathan locally
19:00 jonathan Something is seriously messed up still though
19:01 jonathan "man-or-boy test for start value -10"
19:01 jonathan !!
19:01 jonathan Oh, might be an "is copy" bug
19:02 * moritz loves integration tests
19:02 jonathan Ah, yes
19:03 jonathan Hmm. It's not an obvious is copy bug if it is that.
19:03 TimToady pmichaud: I want to talk on p6l about how people can hack on S16 in the pugs repo, but I don't know where it's going to end up till your pod refactor is done...
19:05 jonathan moritz: Ah, win.
19:05 jonathan Yes, there's some bug with is copy.
19:05 jonathan But if I work around that, then I make it up to 10 before we hit the 1000 max recursion limit.
19:06 moritz jonathan: better than nothing... do we need that limit?
19:07 moritz or put it this way, do we need such a small limit?
19:08 jonathan moritz: The limit is more for development purposes I guess.
19:09 jonathan So we can see that we're on the way to an infinite recursion rather than doing an out of memory panic when we exhaust the entire heap. :-)
19:09 moritz jonathan: I think it won't hurt for now to execute only the first few tests
19:09 jonathan moritz: We make it through the first 10
19:09 moritz that's what I meant by "first few" ;)
19:09 Whiteknight joined #parrot
19:10 jonathan moritz: Well, we can always stick something in Rakudo to increase the limit too. ;-)
19:10 jonathan OK, fix for the first issue that made us crash is in.
19:10 jonathan Now I need to debug this is copy bug
19:10 moritz jonathan: I don't care either way, I find your point about the recusion limit quite convincing
19:11 dalek r33231 | jonathan++ | trunk:
19:11 dalek : [rakudo] Bug fix for subs that take parameters with the & sigil; we need to register the symbol after we stripped.
19:11 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33231
19:11 jonathan moritz: I think we should ship a production build with something higher than that.
19:11 jonathan Or without a limit. But for a dev one, it's helpful, for sure. :-)
19:13 * moritz doesn't worry about shipment prior to having an installation system ;)
19:14 Whiteknight anybody else here using TortoiseSVN?
19:23 Infinoid I used it briefly... a year ago or so, sorry.
19:25 dalek r33232 | bernhard++ | trunk:
19:25 dalek : [Pipp] Steal code from Rakudo, needed for library loading
19:25 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33232
19:25 jonathan Thief! Thief!
19:25 jonathan ;-)
19:31 * barney hides
19:32 galf left #parrot
19:37 galf joined #parrot
19:39 galf left #parrot
19:39 galf joined #parrot
19:44 jonathan moritz: OK, so just ci'd the second fix needed.
19:44 jonathan moritz: We can do up to the 10th.
19:44 jonathan Want me to remvoe the last two values and add it to spectest.data?
19:44 dalek r33233 | jonathan++ | trunk:
19:44 dalek : [rakudo] A crack at getting is copy to do the right thing. We may need to revisit this again later, as I've still not convinced myself it's going to do the right thing in every case (but didn't work out one where it won't yet). It passes all spectests that already passed and makes the man or boy example's use of is copy work, though.
19:44 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33233
19:45 moritz jonathan: willl do, just a sec
19:45 jonathan I was offering. :-P
19:45 jonathan But fajn. :-)
19:45 jonathan Rakudo just grew up from being a boy to being a man. w00t.
19:45 moritz or you can, I misread (distracted...)
19:45 jonathan If you're distracted, I can...
19:47 * jonathan does it
19:48 jonathan Dares someone to post the Perl 6 example on WikiPedia...then we can see how long before someone does a vapourware troll on the talks page. ;-)
19:48 dalek r33234 | jonathan++ | trunk:
19:48 dalek : [rakudo] Add the man or boy test to spectest.
19:48 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33234
19:48 moritz jonathan: the current wiki page has all the examples removed
19:49 jonathan Ah, OK.
19:49 Coke chromatic++
19:50 Coke (tortoisesvn) iam.
19:51 chromatic Eh?
19:51 purl Speak up, sonny!
19:53 pmichaud TimToady: I'll do the pod migration now.
19:53 pmichaud moving conversation to #perl6
19:55 gryphon joined #parrot
20:01 Coke seen particle?
20:01 purl particle was last seen on #parrot 2 hours, 15 minutes and 56 seconds ago, saying: i forget when and where
20:02 Coke chromatic: in anticipation your next lovely commit.
20:02 Coke anyone here with MSVC that can double check 41218 for me?
20:02 Coke http://rt.perl.org/rt3/Tic​ket/Display.html?id=41218
20:02 Coke (that is, what warnings are showing up on that file.)
20:02 jonathan pmichaud: Just glancing at http://rt.perl.org/rt3/Tic​ket/Display.html?id=60380 - other than maybe moving !CHECK_READONLY to guts.pir where the other similar stuff lives, what do you think?
20:03 jonathan The alternative is to get a new result and then do infix:=, but it's an extra PMC. OTOH this is an extra call...
20:04 jonathan ...but infix:= would be too. Heh. :-)
20:04 pmichaud it's going to be a part of prefix:<++>
20:04 jonathan You mean we'd call !CHECK_READONLY from prefix:<++> too?
20:05 pmichaud no.
20:05 pmichaud back up a second.
20:05 jonathan I was more saying, do you agree with the approach for the op= ?
20:05 pmichaud no.
20:05 pmichaud $x op= $y   is the same as    $x = $x op $y
20:05 jonathan OK.
20:05 pmichaud thus assignment will already take care of the readonly-ness
20:06 pmichaud because the '=' is a metaoperator
20:06 jonathan Thus why I asked, I thought I'd read you mention that somewhere before.
20:06 jonathan Yup.
20:06 pmichaud *if* we decide that we want to optimize some of these -- i.e., define an   infix:<+=>  operator
20:06 jonathan OK, but we should optimize when we know we need to.
20:06 pmichaud then it will be defined as     multi sub infix:<+=>($x is ref, $y) { ... }
20:07 jonathan *nod*
20:07 pmichaud and the "is ref" will take care of the fact that we can't pass a constant.
20:07 pmichaud the same is true for prefix:<++> -- the argument will be an "is ref" or something that doesn't accept constants.
20:07 pmichaud (or that coerces the properly, or whatever)
20:07 pmichaud *them
20:07 jonathan OK.
20:08 pmichaud I plan to re-do the += ops the same way we did junctions
20:08 pmichaud at least until we have the = metapostfix working.
20:08 jonathan OK.
20:08 pmichaud basically, we'll have a Perl 5 script that automatically generates the infix:<+=> subs in PIR
20:08 pmichaud (or perhaps Perl 6)
20:08 pmichaud and we'll do any read checking there.
20:09 jonathan Wait, why do we need to, if they were going to call infix:=?
20:09 pmichaud this is a workaround until we have = metapostfix working.
20:09 jonathan Or you mean, if we do it in PIR we'll emit code to simulate the "is ref"?
20:09 jonathan OK.
20:10 pmichaud we still have to define the +=, -=, etc.   subs until then
20:10 pmichaud but I don't think we should be writing them by hand
20:10 jonathan Makes sense.
20:10 pmichaud we should autogenerate them to do the equivalent of   infix:= and infix:+
20:10 jonathan *nod*
20:10 pmichaud and if we want to put read checking there, we can.
20:10 jonathan What about the ++/-- ops?
20:11 pmichaud they're already working, I think.
20:11 pmichaud maybe not for the simple case, but they already define   ++   as being  $x .= succ
20:11 pmichaud which implies an infix:=
20:11 pmichaud (simple case being ++ on an integer)
20:11 pmichaud overall it's not _really_ a high priority at the moment
20:11 jonathan > sub foo($x) { $x++; say "lived" }; foo(1)
20:12 jonathan lived
20:12 pmichaud we can put things in place to make it work, but we're just going to rip them all out when we write them in Perl 6 anyway.
20:12 jonathan True.
20:12 pmichaud so I've been content to let those tickets pass for now.
20:12 jonathan Well, we could say that about all of the op= ones too. :-)
20:13 pmichaud yes, except that I expect those to stick around just a bit longer.
20:13 jonathan I agree though, let's spend resources getting towards the Perl 6 prelude that'll Just Work for these.
20:13 pmichaud I certainly don't want to put in things that "work" but are also "obviously not the right approach"
20:13 pmichaud such as !CHECK_READONLY
20:13 jonathan Sure.
20:13 jonathan Yeah, I saw it and thought...hmmm.
20:14 GeJ good yesterday everyone
20:14 pmichaud happy tomorrow, Gej
20:15 dalek r33235 | coke++ | rm_miniparrot:
20:15 dalek : Quiet warnings on generated code (RT #53356)
20:15 dalek : Remove reference to obsolete source file
20:15 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33235
20:16 dalek r33236 | coke++ | rm_miniparrot:
20:16 dalek : [docs] Track a (old?) file move.
20:16 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33236
20:17 dalek r33237 | bernhard++ | trunk:
20:17 dalek : [Pipp] Move pipp_defined to guts.pir
20:17 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33237
20:20 Coke ah, crap.
20:22 jonathan pmichaud: Given you r60408 - parameter related.
20:23 pmichaud jonathan: thanks
20:25 * Coke likes how I get extra karma for fixing my svn screwups!
20:25 dalek r33238 | coke++ | trunk:
20:25 dalek : Merge in r33235 and r33236 to trunk: avoid some build warnings and keep our tool up to date.
20:25 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33238
20:26 pmichaud I'm thinking that something puts a spurious @_ parameter on the block.
20:30 jonathan pmichaud: I think so.
20:30 jonathan pmichaud: I expect it's a bit of code you'll want to refactor anyway when you're doing parameters stuff.
20:30 jonathan But just to make you aware the current is buggy.
20:30 jonathan I think it's putting an @_ on any block.
20:31 jonathan When it probably only should put it on routines that are signatureless, IIRTSC.
20:32 pmichaud only on subs that are signatureless
20:32 jonathan Aye. Looks like it's sticking 'em all over.
20:32 pmichaud that's icky.
20:32 jonathan Aye.
20:32 jonathan I *could* fix it if you'd prefer to have something less buggy to refactor.
20:33 pmichaud as you wish.  :-)
20:33 jonathan Well, given you plan to start refactoring like, today...depends what's most useful.
20:33 particle joined #parrot
20:33 pmichaud I'd say leave it for another day or two
20:33 jonathan OK, works for me.
20:33 pmichaud I don't know that my refactor will be done in a day or two, but it's not pressing.
20:34 jonathan Sure
20:34 jonathan You're going to make a branch?
20:38 pmichaud yes.
20:39 jonathan OK
20:39 jonathan How far do you plan to go?
20:39 jonathan Like, will you switch over fully to the signature-based unpacking approach?
20:48 * jonathan -> nom, bbiab
20:53 dalek r33239 | coke++ | rm_miniparrot:
20:53 dalek : Remove miniparrot from remaining tests in the branch. - all tests pass now.
20:53 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33239
20:53 pmichaud jonathan: I'll go until I get to a reasonable stopping point.  Don't know what that is yet.
20:54 pmichaud But I think we're in agreement on the underlying structure.
20:55 masak joined #parrot
20:59 GeJ hej masak
20:59 masak halloj GeJ
21:07 johbar joined #parrot
21:14 dalek r33240 | bernhard++ | trunk:
21:14 dalek : [Pipp] quirky suupport for 'require_once'
21:14 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33240
21:17 dalek r33241 | coke++ | rm_miniparrot:
21:17 dalek : remove references to now-gone init step.
21:17 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33241
21:24 Topic for #parrotis now Parrot 0.8.1 "Tio Richie" Released | http://parrot.org | 611 tx
21:25 Coke chromatic: 11 more tickets to hit 600.
21:25 Coke (well, on RT)
21:27 chromatic Very nice.
21:28 dalek r33242 | bernhard++ | trunk:
21:28 dalek : [Pipp] remove an unnecessary '+', add a test case
21:28 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33242
21:29 dalek r33243 | bernhard++ | trunk:
21:29 dalek : [codingstd] remove trailing space
21:29 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33243
21:37 tak joined #parrot
21:42 masak rakudo: say [].min
21:42 polyglotbot No output (you need to produce output to STDOUT)
21:42 masak bug? :)
21:43 masak oops, didn't show the same here as locally
21:43 masak on my box, it says "Use of iuninitialized value"
21:43 moritz see #perl6
21:43 masak moritz: indeed.
21:43 masak moritz: p6eval seems more truthful than polyglotbot
21:44 Tene is polyglotbot misbehaving?
21:44 masak I don't know
21:44 masak it's not telling, more like it
21:44 moritz masak: it's updated more often, and it captures STDERR reliably :)
21:44 masak moritz: ah.
21:45 moritz oh wait, even then polyglotbot should capture the \n at the end
21:45 masak aye
21:45 masak Tene: so, yes.
21:45 Tene What is it doing?
21:46 * jonathan returns
21:47 jonathan pmichaud: Yes, agree. :-) Happy hacking! ;-)
21:47 moritz 22:42 <@masak> rakudo: say [].min
21:47 moritz 22:42 < polyglotbot> No output (you need to produce output to STDOUT)
21:47 moritz 22:43 < moritz_> rakudo: say [].min
21:47 moritz 22:43 < p6eval> rakudo 33241: OUTPUT[Use of uninitialized value##]
21:48 tewk rakudo: say "hello";
21:48 polyglotbot No output (you need to produce output to STDOUT)
21:48 Tene I don't think it's capturing stderr, maybe?
21:48 moritz Tene: p6eval's output is what you get from the command line as well
21:48 Tene ... bah
21:48 Tene lemme look
21:48 moritz even then it should capture the newline from say()
21:49 Tene It's segfaulting.
21:49 Tene Again.
21:49 Tene feather3 is screwed up.
21:51 Tene Parrot on feather3 was segfaulting a while back, but then it went away.
21:52 tewk feather3?
21:52 purl somebody said feather3 was screwed up.
21:52 Tene vm on feather
21:52 moritz feather3 is also the virtual host on which evalbots run
21:52 purl okay, moritz.
22:10 tak joined #parrot
22:13 Coke kid51+=
22:13 Coke kid51++
22:14 Coke happy thanksgiving to those in the US.
22:29 leto joined #parrot
22:54 ruoso joined #parrot
22:59 tak joined #parrot
23:03 kid51 joined #parrot
23:05 chromatic tewk, RT #49718 and t/pmc/timer.t might be an easy fix for you.
23:08 tak joined #parrot
23:14 kid51 joined #parrot
23:16 dalek r33244 | jkeenan++ | trunk:
23:16 dalek : Delete tests pertaining to Configure.pl --miniparrot option, which has been deactivated.
23:16 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33244
23:17 tak joined #parrot
23:22 pmichaud how long does it take messages to parrot-tickets@lists.parrot.org to show up in trac?
23:22 pmichaud oh, it's being moderated.
23:22 moritz pmichaud: iirc they don't
23:23 moritz "One substantial change to the workflow: Trac won't follow comments
23:23 moritz posted by email, so if you want your comments to be added to the ticket,
23:23 moritz make them through the web interface. "
23:23 pmichaud comments posted through email, yes.
23:23 pmichaud oh, so there's no "mail this address to post a ticket" yet?
23:23 pmichaud perhaps I misunderstood.
23:24 moritz dunno
23:25 pmichaud yes, I misunderstood.  posting only through the web interface.
23:25 * jonathan yawns
23:26 * jonathan wonders if he has the brain power left to do a couple more bits
23:27 * moritz wonders if poering off his brain is a good idea...
23:27 moritz the answer seems to be "yes", so I'm off to bed now ;-)
23:28 jonathan night :-)
23:28 moritz g'night ;)
23:28 bacek_ joined #parrot
23:30 TiMBuS joined #parrot
23:36 tak joined #parrot
23:39 allison joined #parrot
23:39 tak joined #parrot
23:54 dalek r33245 | jonathan++ | trunk:
23:54 dalek : [rakudo] We need to be a bit careful to differentiate between Perl6Scalar (which just wraps up an argument) and ObjectRef (which we have when something is actually a reference type). Modify list() to know about this. Resolves RT#60404.
23:54 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=33245
23:56 pmichaud jonathan: I don't think that's the right fix.
23:56 pmichaud at least for the tests given in the ticket, there shouldn't be any Perl6Scalars involved at all.
23:57 jonathan pmichaud: We always wrap all arguments in Perl6Scalar at the moment to enforce readonlyness.
23:57 pmichaud we shouldn't be doing that.
23:57 jonathan pmichaud: Thus my comment about why it's the Wrong Name.
23:57 pmichaud sub (@a) { ... }    should result in a Perl6Array
23:58 pmichaud (which also has read-onlyness)
23:58 pmichaud not a Perl6Scalar, or whatever we decide to call it.
23:58 jonathan Wouldn't that imply that we make a copy of what was passed in order to do that?
23:58 pmichaud no.
23:59 jonathan We can't just set an extra property on the thingy that was passed.
23:59 kj joined #parrot
23:59 pmichaud oh, I see what you're getting at.
23:59 pmichaud So we still need our "wrapper" thing which we're calling Perl6Scalar
23:59 jonathan Right.
23:59 jonathan Perl6Scalar is majorly the wrong name.
23:59 jonathan It's mostly a EnforcementOfStuffWrappar. :-)
23:59 pmichaud let's just call it a Container
23:59 Tene WetPaperBag

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

Parrot | source cross referenced