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

Powered by Cro and the Raku® Programming Language.

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

Thank you!