www.parrotcode.org | Last Release: 0.7.0 "Severe Macaw"
Set by moderator on 3 September 2008.
00:09 AndyA joined 00:21 bacek joined
bacek morning everyone 00:21
cotto_work morning, bacek 00:28
szbalint kid51: I had the same experience, installing Moose on my laptop and noticing it depended on half CPAN ;-) 00:33
(for smartlinks) 00:34
bacek I have a question about rt.perl.org/rt3/Ticket/Display.html?id=56468 00:35
E.g. in bigint.pmc I found many lines similar to "bigint_sub_bigint_int(INTERP, SELF, PMC_int_val(value), dest);" (this is from "substract") 00:36
Should we replace PMC_int_val with VTABLE_get_intereg(value) in this case?
dalek r30979 | jkeenan++ | trunk: 00:39
: Applying patch submitted by Balint Szilakszi in RT 46783, deleting comments calling for use of tempfiles where they would be superfluous. szbalint++.
diff: www.parrotvm.org/svn/parrot/revision?rev=30979
kid51 szbalint: Welcome to the ranks of Parrot contributors and cage-cleaners!
szbalint thanks :) 00:41
bacek And all keyed functions (e.g. get_integer_keyed_int) uses PMC_int_val(key)... 00:43
cotto_work szbalint++ 00:49
Whiteknight applauds pmichaud 01:00
cotto_work ? 01:03
Whiteknight he posted his final grant report 01:04
01:13 rurban_ joined
Whiteknight I'm subscribed to a few aggregators, and I got 6 copies of the report in my reader 01:16
cotto_work It's fairly generous to call xlibtest an application, awesome as it is. 01:27
Whiteknight I haven't even seen it yet. What is it, an NCI test app? 01:31
cotto_work examples/nci/xlibtest.pir 01:32
it lets you draw in a window with a mouse in pure pir
there's also an nqp and a perl6 version
Whiteknight is it in trunk? 01:33
cotto_work yup 01:34
read the inline POD before running 01:35
01:35 bacek joined
Whiteknight how do I make xlib.pbc? is there a make target for it? 01:36
Whiteknight demands documentation
cotto_work perldoc xlibtest.pir 01:37
../../parrot -o Xlib.pbc Xlib.pir
;)
Whiteknight you think you're so freaking smart! :)
i have to remake, don't have the right NCI signatures 01:38
cotto_work home & 01:42
01:45 particle joined 02:08 kid51 joined 02:10 AndyA joined 02:26 AndyA joined
cotto_home and home 02:31
02:44 bacek joined 02:55 gmansi joined
cotto_home Does anyone here running windows and have both msvc and gcc working? I'd like a patch tested. 02:57
nopaste "cotto_home" at 96.26.202.243 pasted "file.pmc patch to use strerror_(rs) where available" (211 lines) at nopaste.snit.ch/14016 03:07
cotto_home It doesn't quite dtrt, but it's close enough that testing it will yield useful results. 03:14
to test, apply, build and prove t/pmc/file.t 03:15
03:53 particle joined 03:56 ab5tract joined 04:02 grim_fandango joined
cotto_home particle: ping 04:14
particle, when you have a minute I'd appreciate a review of the patch for rt.perl.org/rt3/Ticket/Display.html?id=52778 04:19
It's a nearly trivial patch, but it changes the behavior of resizable*arrays, so I'd like to make sure it's OK to commit. 04:20
ab5tract i ran 'perl Configure.pl --prefix=~/lang' 04:36
and it installed to ~/parrot-0.7.0/~ 04:37
the second tilde being an actual directory named '~'
actually it did ~/parrot-0.7.0/~/lang 04:38
so it kind of got it right i guess
Hinrik hm, rakudo.de/ 04:53
^--- how big is the entire test suite?
and how much of Perl 6 does it cover? 04:54
04:54 Zaba joined
cotto_home Hinrik, try asking on #perl6 on Freenode 04:57
Hinrik ok
ab5tract !bugs 05:00
GeJ Hinrik: there was a post from pmichaud IIRC, that discussed the subject of the test suite. Summary is not everything is covered yet so even the current number isn't going to tell that much about the final number. 05:01
For comparison, I think moritz wrote a post recently where he said that Pugs had 16k tests passing.
Hinrik hm, ok
GeJ that's for moritz: perlgeek.de/blog-en/perl-5-to-6/22-state.html 05:02
and that's for pmichaud: use.perl.org/~pmichaud/journal/36834 05:04
ab5tract SMOP sounds awesome! 05:16
what is bug repo link for parrot? 05:17
and where can i learn more about smop
diakopter ab5tract: www.perlfoundation.org/perl6/index.cgi?smop 05:20
ab5tract diakopter: thank you.
diakopter wow; that smop wiki has expanded greatly since I last looked at it 05:25
ab5tract it sounds crazy 05:28
but i guess they are right. perl 6 is just a smop.
the object responder interface... that's clean c 05:30
"just a macro to a callback", yeah you know nothin serious
will it connect with parrot? 05:33
diakopter "mutual embedding as p2p" - I can see it now... 05:34
ab5tract: I dunno. ruoso or pmurias on #perl6 on freenode 05:35
05:50 AndyA joined 06:19 uniejo joined 06:40 Zaba joined 07:13 barney joined 07:17 iblechbot joined 07:27 ab5tract joined 07:39 Debolaz joined 07:53 mberends joined 08:13 slavorg joined 08:59 cosimo joined 09:14 rurban_ joined 09:37 kj joined 10:10 xiaoyafeng joined
jonathan hi all 10:22
kj hi jonathan 10:23
jonathan svn up's 10:29
moritz: ping 10:51
moritz: I don't know if I was supposed to set any environment variables to really do parallel testing, but I just did a make spectest_regression with the parallel testing patch applied on Windows and it worked fine. 11:03
oh, damm 11:04
I didn't make makefile
jonathan tries again after that
11:09 bacek joined
jonathan moritz: Works after I actually tested it too. ;) 11:12
11:18 bacek joined
bacek g'localtime 11:19
hi purl ;)
purl? 11:20
purl yes, bacek?
bacek hi purl
hmm... what happened to her?
11:21 uniejo joined, clunker3 joined 11:48 Ademan joined
moritz re 11:55
jonathan: ok, then I'll apply the patch when I'm back home
jonathan moritz: OK, nice. :-) 11:56
dalek r30980 | jonathan++ | trunk: 12:02
: [rakudo] Add argumentless ... stubby exception generator.
diff: www.parrotvm.org/svn/parrot/revision?rev=30980
jonathan stares at patch in RT#58150 12:03
dalek r30981 | jonathan++ | trunk: 12:24
: [core] When slurping an empty file, we should hand back the empty string rather than a NULL, which would suggest an error. Patch courtesy of Ron Schmidt.
diff: www.parrotvm.org/svn/parrot/revision?rev=30981
12:30 bacek joined
dalek r30982 | jonathan++ | trunk: 12:38
: [rakudo] Make split method a little more liberal about the multi parameters it takes, so $*IN.slurp.split(...) will work.
diff: www.parrotvm.org/svn/parrot/revision?rev=30982
12:59 kj joined 13:04 Zaba joined
pmichaud split belongs in any-str . 13:07
jonathan I did wonder that. 13:08
pmichaud and the first param should be _
jonathan If it's going in any-str, then yes.
Is there a list of what belongs in Any somewhere, or is it just an instinctive feeling? :-)
pmichaud there's not a list, but in general any time that we expect a function to "coerce" its invocant into the appropriate type, it belongs in Any 13:09
jonathan OK.
pmichaud thus .abs goes in Any, because it will always treat its invocant as a numeric value
and split goes in Any, since it treats its invocant as a string value
jonathan *nod* 13:10
Will move it.
tewk pmichaud: I didn't create Squaak 13:11
pmichaud tewk: yes, I just got a message from kjs as well
those "k"s got me confused. I'm fixing it now and will re-submit.
(and I was tired and distracted when I wrote the report)
dalek r30983 | jonathan++ | trunk: 13:18
: [rakudo] $(), @() and %() now mean the same as $($/), @($/) and %($/), as per S05.
diff: www.parrotvm.org/svn/parrot/revision?rev=30983
pmichaud okay, fixed the reports online. I'm sending an updated version to mozilla now. 13:24
jonathan pmichaud++ # good report
Makes me realize how far we've come.
pmichaud done. 13:26
jonathan: I think I would much prefer for ... to be term:<...> instead of a special token in the grammar 13:29
and then a builtin-sub rather than part of the AST 13:30
jonathan pmichaud: We can't write term:<...> yet, though?
Thus why we have named_0ary?
pmichaud do it the same as the other 0-ary terms.
jonathan OK, though it's not actually 0-ary. :-)
pmichaud it's not? 13:31
jonathan No
It can take args.
STD.pm has it
token term:sym<...> ( --> List_prefix) { <sym> <args>? }
pmichaud okay, it's 0-ary for now, then. :-)
jonathan But <args> is a special arguments rule that only a few things use, so I didn't pull that in yet.
OK, I can move it there.
pmichaud at any rate, I'd prefer it not to be handled specially in the AST 13:32
jonathan Well, if it's going to be parsed as in STD.pm, we'd only end up emitting a call to term:... rather than a call to fail... 13:34
pmichaud yes
jonathan (Well, with the exception of checking if there's any args)
pmichaud but when we're STD.pm-like it'll probably be a special method in the action grammar anyway (instead of being part of an existing method) 13:35
jonathan Yes.
13:35 masak joined
jonathan But then it will be handled in the AST? So doing it like that now is closer to what we'll eventually want? 13:35
pmichaud I'd prefer it not to be an if-then statement that we have to rip out.
and it's still better for it to be treated as a call to a sub named 'term:...' than a special failure node. 13:36
jonathan True, that'll allow overriding. 13:37
pmichaud and it'll be easier to handle things like 'use fatal'
jonathan *nod*
Yes, I'm sold on it now. :-)
Ah, hmm. It looks like the named_0arys actually call just the name, not term:name 13:39
pmichaud yes.
jonathan so just .sub '...' for now?
pmichaud sure.
that's probably so that we can get things like &rand and the like 13:40
jonathan Yes, I expect so. 13:42
ouch 13:44
token named_0ary { [pi|rand|undef|nothing|time|'...'] >>
}
13:44 davidfetter joined
jonathan Now I get parse fails. 13:44
sub foo { ... }
Missing '}' at line 1, near "... }\\n"
:-S
That's what I was getting with ??? and !!!
pmichaud looking 13:53
jonathan Thanks. 13:54
pmichaud it really shouldn't make a difference (more) 13:55
you had '...' as a specially parsed term in token term, but <named_0ary> is also called from there
jonathan Right. 13:56
pmichaud so if it works in one place, it should work in the other.
jonathan Agree.
Grammar engine bug, maybe?
pmichaud no, it's the >>
there's no word boundary after the '...'
13:56 gryphon joined
jonathan ah. 13:56
pmichaud so, perhaps [pi|rand|undef|nothing|time] >> | '...' | '!!!' | '???' 13:57
(!!! and ??? still might not work, but we might as well stub them in for now.) 13:58
jonathan Will try it
Just trying to work out what is wrong the !OUTER at the moment
if "foo" ~~ /o/ { say $/ } # doesn't work - $/ access gives NULL PMC access 13:59
And removing exception handler in !OUTER gives "No such outer depth"
Ah. I fear it's confusion of static chain and dynamic chain. 14:04
pmichaud in this case they're essentially equivalent, though. 14:05
jonathan Yes, but I fear it may be trying to look for !OUTER's outer.
pmichaud possible, but I doubt it. 14:06
I'll svn up, rebuild, and look a bit also
jonathan In parrotinterpreter.pmc, the usage $P0['lexpad', depth] is not one of the things that's documented as meant to work, either. :-( 14:07
pmichaud it's documented in pdd20, though. 14:08
(line 342)
jonathan "outer" ... return outer sub of this closure
"<item>"; level ... same for caller <level>
"outer"; "<item>" ... same for outer level 1
"outer"; "<item>"; level ... same for outer <level>
So it is. 14:09
purl no it isn't
jonathan stares at the rather opaque implementation 14:10
pmichaud staring at it gives transparency? ;-)
jonathan If only...
jonathan is glad purl doesn't have a comment along the "speaker's so loud" one at this point 14:11
The fact it gives the "no such outer depth" message suggests that it is ending up in the code path that chases down the outer chain. 14:13
Otherwise it would say, "no such caller depth"
pmichaud well, chasing down the outer chain is correct, yes? 14:14
jonathan Wait a moment...this is 'lexpad', depth you're using
not 'outer', depth
jonathan was looking at the wrong thing
s = CONST_STRING(interp, "lexpad");
if (string_equal(interp, item, s) == 0)
return ctx->lex_pad;
That's all of the code that relates directly to saying "lexpad" 14:15
BUT there is code that specially handles the case when there is more than one key supplied!
I still can't see the code-path that would get us to walking the static chain though. (The problem being that !OUTER doesn't have an outer...) 14:18
pmichaud I grant that lexicals are still broken in Parrot. :-)
here's another interesting case: 14:19
> $_ = 'hello'; { say $_; } 14:20
>
jonathan Yes
I did almsot exactly the same
Again, it's !OUTER
pmichaud the !OUTER function is using 'outer', not 'lexpad' 14:22
dalek r30984 | kjs++ | trunk: 14:25
: [NEWS] updated NEWS for next release, adding PIRC news.
diff: www.parrotvm.org/svn/parrot/revision?rev=30984
jonathan pmichaud: Ah, yes, you're right 14:33
Sorry, had phone call
pmichaud: I really don't like that for every immediate block we enter we then have to do three Parrot sub calls for this. 14:34
We could get the required functionality out of a few-line dyn-op.
But ParrotInterpreter PMC does: if (outer) { 14:36
(Which is true if we mention 'outer', it appears)
And if that's true, goes and looks for !OUTER's outer, etc.
dalek r30985 | moritz++ | trunk: 14:38
: Enable parallel testing in rakudo.
: Patch courtesy by Michael Schwern and Ron Schmidt
diff: www.parrotvm.org/svn/parrot/revision?rev=30985
r30986 | moritz++ | trunk: 14:41
: [NEWS] first stab at Rakudo news
diff: www.parrotvm.org/svn/parrot/revision?rev=30986
jonathan pmichaud: May have a fix.
moritz pmichaud: the NEWS entry for rakudo is probably not complete, so extend/edit it before the release 14:42
jonathan pmichaud: Need to spectest_regression it.
pmichaud: I think we should be using lexpad. 14:46
Not outer. 14:47
Doing so gives me two test failures, however.
(But fixes the "if "foo" ~~ /o/ { say $/ }" bug, and"$_ = "hello"; if 1 { say $_ }" too). 14:48
moritz jonathan: what kind of failures?
jonathan t\\spec\\S04-statements\\given.rakudo
t\\spec\\S06-signature\\named-placeholders.t
moritz making that work means *much* easier real-world code 14:49
jonathan moritz: I know. 14:50
I'd rather fix it without causing regressions, though.
Investigating them now.
masak I, for one, like where this is going. hope everything works out. 14:52
jonathan OK, the given is actually now failing in a todo test.
And it's failing when it wasn't before because it now executes some code it should!
moritz that's OK
jonathan Basically it did
(does)
my $x;
given 41 {
when ({ $_ == 49 }) { diag "this really shouldn't happen"; $x = 49 }
when ({ $_ == 41 }) { $x++ }
}
Before, $_ wasn't being taken into the block inside the when test, so we never tried to do $x++ 14:53
masak yes, of course. :)
tests++
jonathan Now we do and get the "increment not implemented in undef"
Which causes the test to bomb out.
moritz jonathan: changing that to 'my $x = 0' should solve the problem 14:54
jonathan Yes. Is that an OK thing to do?
We actually pass the test...
moritz jonathan: since it's not autoincrementation that we test... yes
jonathan OK.
I can un-todo the test as well, otherwise we'll get another unexpected success.
NotFound I think that if the test was passing erroneously, the test must be fixed.
moritz jonathan: I added a test like that in the proper place, and now I simplify such thing whenever I see them
jonathan OK, so that's a WIN. 14:55
NotFound I mean, make it fail before the change. 14:56
jonathan NotFound: It wasn't that it was passing. It was just not failing badly enough before the change.
NotFound Ah, well.
jonathan OK, t\\spec\\S06-signature\\named-placeholders.t...
This could be nastier.
oh, wtf, just ran it outside of the harness and it passes 14:57
jonathan tries spectest_regression again
jonathan suspects that if we fixes this !OUTER thing there may be a couple of RT tickets that can get closed 14:58
masak aye, 14:59
lots of november code will become much more succinct :)
jonathan Yay.
NotFound So given/when will be working now? 15:00
jonathan No
That to work fully needs the control exception stuff
NotFound I just want to use it instead of a chain of if in xlibtest.p6 15:01
jonathan I think it's waiting on PCT refactors, which I'm not 100% comfortable doing.
NotFound I'll wait, then. 15:02
jonathan Hmm. I've got a test that runs fine with perl t/harness, fine when run with perl6.pbc, but fails when run as part of spectest_regression. 15:03
That would seem to suggest a test harness issue rather than a Rakudo issue. 15:04
NotFound Differents flags passed to parrot, maybe?
masak NotFound: you can already use it if you refactor it out into a sub, and end each when { ... } with a return :) 15:05
NotFound masak: if I use a sub for each value, I'll like better to use a hash of subs. 15:06
masak NotFound: nono, just refactor the given into its own sub.
so that you can use return as .leave 15:07
dalek r30987 | jonathan++ | trunk:
: [rakudo] Fix !OUTER, so things like if 'foo' ~~ /o/ { say $/ } will now work. Since !OUTER no longer seems to produce exceptions after this fix, we'll try not wrapping it in an exception handler any more and see what comes of that - none of spectest_regression depends on it.
diff: www.parrotvm.org/svn/parrot/revision?rev=30987
masak jonathan++ # best present ever! 15:08
NotFound masak: I think I understand, but that goes against the idea of showing an example of clean and simple code.
jonathan masak: Report any issues you see as an upshot of this.
masak jonathan: sure thing.
NotFound: ah, didn't know that was a goal. nvm.
masak has been working too long from the gotta-make-this-work-somehow angle 15:09
NotFound masak: well, is my goal for program in examples, at least.
jonathan masak: Also interested to know if there's the odd failure under spectest_regression but not at the command line for you.
moritz jonathan: don't forget to commit your test changes in the pugs repo 15:10
masak jonathan: 'll have to get back to you on that. :)
jonathan moritz: Yes, I have commits hanging to svn.perl.org...committing that one now...
moritz my last two commits did hang on the client, or otherwise reported failure 15:11
jonathan Updates to tests commited. 15:16
moritz thanks 15:17
NotFound If I try rurban suggestion of load_bytecode 'Xlib' instead of 'Xlib.pbc' and have the pbc already compiled if fails: error:imcc:syntax error, unexpected $end ('?') .... Xlib.pbc
Looks like is tring to compile the pbc file. 15:18
I see: the logic is extremely simple in Parrot_load_bytecode, if it has no pbc extension, is source. 15:27
pmichaud sorry for disappearing -- having to book a flight for my dad (and flights are cancelling quickly due to weather) 15:30
bbiab 15:31
jonathan masak: Are there any particular tickets that are really blocking you at the moment, or at least being exceptionally annoying for November?
moritz I think the for/recursion scoping bug 15:32
NotFound We're still in September ;)
jonathan Yeah, but Rakudo loses me for most of October! :-P
So November is virtually close for me. ;-) 15:33
NotFound Strange internet world.
jonathan moritz: #58392: Recursion and for loops interact badly in Rakudo ?
masak jonathan: aye, that one 15:35
it's blocking the branch that replaces a cruddy HTML::Template (using regexes) with a cool one (using grammars)
and it keeps popping up when we want to do cool things, such as recurse correctly 15:36
I'd say that regardless of november, it's the most 'outstanding' bug in Rakudo right now
jonathan youch! 15:37
wtf...
masak kthxbai.
purl kthxbai is www.flickr.com/photos/goopymart/291...362502502/
pmichaud jonathan: the reason for the exception handler was in case someone requested looking at a depth greater than the current caller/outer stack
masak purl: forget kthxbai 15:38
purl masak: I forgot kthxbai
jonathan pmichaud: OK, but since it's an internals function and nothing seems to be doing it...
An exception feels nice to me than it mysteriously not working.
pmichaud well, it's internals *now*, but we do need to eventually support OUTER:: and CALLER:: :-)
yes, we can leave the handler out for now
NotFound Will be better call int 'chain'. We can't talk about stacks while telling people that we are stackless ;)
s/int/it
jonathan pmichaud: OK. I think it'll make it easier to spot problems for now, and we can easily enough add it back in later. :) 15:39
pmichaud I have no good ideas about 58392 and why it's not working.
I've thought about it some but nothing makes sense to me
jonathan It looks...so odd.
pmichaud I'm guessing we may have some reference or lexical issues somewhere.
jonathan My first guess is that it's to do with lexical attachments or something.
pmichaud I haven't convinced myself that the current lexical environment supports recursion yet anyway 15:40
I don't know that we have any tests for recursion, so it may be that some of the "fixes" we put in place over the summer actually broke recursion.
jonathan That would suck. 15:41
pmichaud lexicals in Parrot suck in general.
jonathan www.flickr.com/photos/goopymart/536...362502502/ - but US government said teh internets is not a truck?!
pmichaud: True.
NotFound Did you mean rakudo tests, parrot tests, or both?
pmichaud I know that the last time I dealt with lexicals in parrot it ate up about 10 hours of my life trying to figure out what wasn't working, so I haven't been eager to check it 15:42
NotFound I can take a look at the parrot part.
jonathan I can't even remember the outcome of the whole thing.
pmichaud NotFound: I was referring primarily to rakudo tests, but I don't know that there are any parrot tests either
jonathan: the outcome was that I needed to re-draft a lexicals design, but then oscon and vacations and yapc::eu hit
Ultimately I still think we need to get rid of the Closure PMC 15:43
jonathan Aha, OK. So the re-draft is still pending...
pmichaud correct. #58392 might prompt me to get to work on the re-draft
I needed to get the mozilla foundation report finished first, though. 15:44
jonathan *nod*
NotFound pmichaud: I liked to see the xlib work mentioned in your report :) 15:45
pmichaud NotFound: yes, it was a readily-available example of where rakudo was being used for more than just running tests :-)
jonathan++ # fixing !OUTER to work 15:46
moritz: (rakudo NEWS) since I'm the one doing the Parrot release this month, I'll make sure NEWS gets updated :-) 15:53
moritz pmichaud: ooh, I didn't know that ;) 15:54
15:58 Theory joined
dalek r30988 | moritz++ | trunk: 16:12
: [rakudo] tools/autounfudge.pl: skip a few more files by default
diff: www.parrotvm.org/svn/parrot/revision?rev=30988
16:14 iblechbot joined
jonathan Hmmm. It's more complicated than just lexicals, I fear. 16:18
oh, no it's not 16:19
jonathan has short-ish PIR example
moritz jonathan: chromatic offered to fix it if there was a (pure?) PIR example 16:20
jonathan moritz: Just attached it to the ticket. 16:21
Doesn't depend on Rakudo at all.
masak oh, that's good news
paco NotFound: now, I have the (64b) powah ... : file parrot 16:24
parrot: ELF 64-bit MSB executable, IBM S/390, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux 2.6.0, not stripped
jonathan masak: It's reasonably short too.
masak yay!
swimming & 16:25
particle paco++
jonathan And it's certainly lexical related. Adding a call to newclosure gives the right output. 16:27
paco now I have to prepare a patch to hints, becouse I had to make some hand tuning to the makefile .. 16:30
particle paco: which distro, btw?
paco particle: is a debian one - Linux s390 2.6.18-6-s390x #1 SMP Tue Aug 19 04:50:55 UTC 2008 s390x GNU/Linux 16:31
particle i see, thanks
pmichaud jonathan: seeing r22207 (pugs repo) about autoincrementing Undef reminds me of something -- any way that we can get Scalar (Perl6Scalar) to default to initializing to something other than Undef ? 16:39
like, Failure ?
even better... could we avoid actually initializing the Scalar until it's needed? Right now we create a separate Undef object every time a Scalar is created 16:40
(actually, I guess most of this stuff is in Mutable) 16:41
jonathan pmichaud: It's all in Mutable, and yes, we literally do, if no initialization value is in, pass in Undef. 16:42
We can instantiate whatever we like in there by default.
pmichaud I'd like it to be PMCNULL until needed
particle Undef isn't a singleton?
jonathan Doing it lazily would mean checking if we have a value every time we do something.
particle: If it is, then I expect pmc_new on it returns the same thing every time. :-) 16:43
16:43 jan joined
pmichaud yes, but that won't be the case for Failure objects -- those aren't singletons. 16:43
jonathan Yes.
True.
particle right
jonathan Are you thinking that for different operations we will want to auto-vivify to different things?
So we call increment, and there's nothing in the container, so we create an Int in there? 16:44
moritz or ~=, and create a Str
pmichaud no, it should throw exceptions
same as any other use of an undefined value.
jonathan my $x; $x++; # should throw an exception?
pmichaud I haven't heard that officially, but yes, I think that should be what happens 16:45
particle hrmm
jonathan Is it a warning to do that in Perl 5?
pmichaud not presently.
particle no
undef++ in perl 5 is 1
jonathan OK. 16:46
pmichaud whether it is an exception or not, we need a way to define such operations on "undef" values
moritz it's very useful for counting stuff in a hash
jonathan Aye.
moritz $lines{$key}++
pmichaud which means we can't be using Undef
(the Parrot type)
particle rakudo: my String $x = ''; say ++$x;
polyglotbot OUTPUT[Method 'ACCEPTS' not found for invocant of class 'String'ā¤current instr.: '!DOTYPECHECK' pc 12992 (src/gen_builtins.pir:8185)ā¤called from Sub 'parrot;Perl6Object;infix:=' pc 60 (src/gen_builtins.pir:52)ā¤called from Sub '_block11' pc 80 (EVAL_11:38)ā¤called from Sub
..'parrot;PCT::HLLCompiler;eval' pc 806 (src/PCT/HLLCompiler.pir:481)ā¤called ...
jonathan Yes, that isn't going to fly.
pmichaud Str, not String
jonathan particle: Str :-)
particle oops
rakudo: my Str $x = ''; say ++$x;
polyglotbot OUTPUT[ā¤]
particle rakudo: my Int $x = 0; say ++$x; 16:47
polyglotbot OUTPUT[1ā¤]
pmichaud rakudo: my Str $x = 'a'; say ++$x;
polyglotbot OUTPUT[bā¤]
jonathan rakudo: my Int $x; say ++$x;
polyglotbot OUTPUT[Intā¤]
particle heh
jonathan Ah, of course.
pmichaud I will likely get the protos to throw exceptions if used as values also
jonathan We have an Undef, which is the proto-object. :-)
Yes.
pmichaud sure, that works for my Int $x, but I'm looking at the case of my $x; 16:48
I suppose that $x could be initialized to the Object proto
particle is that my Object $x by default?
right
moritz in the case of signatures it's Any
pmichaud and that wouldn't involve creating Undefs
moritz in the case of 'my' it's Object
jonathan But just sticking the Object proto in there. Which is a singleton. 16:49
Would work.
particle moritz: sounds like a few reasonable tests
pmichaud and we can define prefix:<++> and other operations on Object proto to do what we want
particle indeed
pmichaud okay, I'll live with Undef in the Scalar code for now.
moritz particle: go right ahead ;) 16:50
jonathan pmichaud: We can easily change it to have the Object proto instead of undef.
pmichaud okay, that's fine also (assuming the PMC stays rakudo-specific) 16:51
jonathan Mutable is all in the Rakudo source tree at the moment
If it escapes, we can always generalize and subclass it.
pmichaud well, we were thinking it might graduate to core at one point
right
particle why wait?
jonathan Wait for?
Making it core?
particle yep
pmichaud nobody else is using it yet, or has expressed a need for it
jonathan What Pm said. 16:52
No point adding stuff to core unless it's really being used by more than one langauge, or going to be.
Otherwise it's deprecation cycle stuff to remove it again.
pmichaud: This lexicals bug. It's...not fun. :-( 16:53
pmichaud jonathan: as I've been saying, lexicals are really broken in parrot
jonathan pmichaud: From what I can see, because we write on the sub->outer_ctx, it seems we affect all invocations of the sub
pmichaud should I retarget my focus for the next few days on that? I've been working on getting the arrayref and hashref semantics correct, so that [ [1,2], [3,4] ] will work properly.
jonathan And stuff isn't undone on return. 16:54
Well, it's frustrating to work on, but it's kinda important too.
pmichaud yes, I've seen that it's a big blocker for masak and November 16:55
jonathan Right. The !OUTER seemed to be one big annoyance, which is fixed now. And I gather this is the other.
I don't see any easy fix.
16:56 teknomunk joined 16:57 Andy joined
pmichaud I'll review the relevant threads this afternoon 16:57
and see if I can come up with some ideas for fixing lexical handling 16:58
but yes, Parrot's confusion between outer, caller, and newclosure is a big part of the problem.
jonathan I worry that we do stuff to a sub when we should really be touching the contexts too. 16:59
pmichaud I much prefer S04's notion of "cloning" contexts instead of newclosure
and it very much bugs me that newclosure always produces a Closure PMC. I think Closure PMCs are fundamentally wrong 17:00
jonathan As I mentioned earlier, adding a newclosure worked just great at fixing the problem here.
pmichaud yes, but putting a newclosure on every invocation has already shown to lead to problems
jonathan Yes.
Fixes this, breaks other things.
Just doing a clone doesn't help in this case. 17:01
pmichaud and putting a newclosure on every reference also seems to have difficulty
well, "clone" has a slightly different meaning here than "strictly copy the Sub"
jonathan Yes.
Anyway, the short PIR example is attached to the ticket.
pmichaud okay, that should help. Thanks.
jonathan (58392, just to be clear) 17:02
pmichaud yes, it hasn't hit my inbox yet.
jonathan rt.perl.org/rt3/Ticket/Display.html?id=58392 :-)
jonathan finds a ticket he can probably close thanks to OUTER fix
As in, another one
pmichaud yes, your PIR example is the classic case where a newclosure is needed. 17:03
(from the Parrot perspective, not from the "this is the way it ought to work" perspective) 17:04
jonathan moritz: t\\spec\\S05-match\\blocks....Could not find non-existent sub plan - any clues?
moritz: Oh, was something else - don't worry 17:06
moritz doesn't worry 17:07
jonathan pmichaud/moritz: In that test file: 17:08
if 1 { ok 'a' ~~ /./, 'Can match in an if block'; is ~$/, 'a', '... and can use the match var';
}
#?rakudo todo 'Proper contextual scoping for $/'
is ~$/, 'a', '... even outside the block';
moritz I'm not sure that one is correct
jonathan I think that maybe this is not what contextual scoping actually menas.
Not, looks dubious to me.
moritz I should clean that up 17:09
to ok !$/.defined, '$/ is undef in the outer scope'
done 17:11
jonathan Unfortunately, the while test exposes another, different bug. 17:12
But the if one can be un-todo'd. 17:13
while $str ~~ /b/ {
$count++;
$str = '';
$match = "$/";
}
pmichaud what's the bug in the while block?
jonathan In there, it seems that "$str = ''" ends up affecting what $/ references 17:14
And then you get: Cannot take substr outside string
pmichaud oh, yes.
jonathan (current instr.: 'parrot;PGE::Match;text')
17:14 rurban_ joined
pmichaud currently PGE Match objects reference the target string 17:14
as opposed to cloning it
that will be fixed when PGE gets Cursor objects 17:15
17:15 sjansen joined
jonathan OK 17:15
Can make the test pass by swapping the order of the two lines around! ;-) 17:16
Or is that too naughty? :-)
pmichaud that sounds like it should be a separate test 17:17
jonathan ok
Will swap them
pmichaud although perhaps we're being too naughty all-around there anyway -- perhaps it really should be 'last' :-)
moritz is it the "can't return a match object" bug the we're hitting here? 17:19
jonathan moritz: No, it's that if you do a match on a string, then change the string, the bits of the match then try and index into the changed string. 17:24
moritz ah, 'is rw' by default. Call it a feature ;) 17:25
erm, :rw I mean
jonathan :-)
Methods outside class declarations - only allowed if they're anonymous. :-) 17:26
(with reference to 58138)
moritz should I try to to add some form of quote parsing (like q/.../) that's easy to do with our current setup? 17:27
dalek r30989 | jonathan++ | trunk: 17:31
: [rakudo] Re-work implementation of ... a bit.
diff: www.parrotvm.org/svn/parrot/revision?rev=30989
pmichaud I'm fine with q, qq, qw, qqw
I wouldn't get much more fancy than that :-)
moritz ok, I'll add those
pmichaud qqw would be very useful, as we don't have a good way of testing that at the moment. 17:32
I need to see what's blocking the handling of Ā«
that *should* work.
moritz is qqw :qq :w or :qq :ww? 17:33
pmichaud check the spec? ;-)
moritz I will
pmichaud oh, looks like there's not a qqw 17:34
it's qww
oh, I'm wrong again. 17:35
moritz the short forms are allowed
pmichaud qww, qqww, qqw, and qqww
anyway, we don't need all of those -- just pick the more useful ones 17:36
moritz I'll go for qq qw q now, check that they are properly tested, then return to the others
jonathan wonders how on earth to remember all of the q's and w's!
pmichaud the only other one I'd be interested in is the synonym for Ā« Ā» 17:37
moritz jonathan: it's quite easy, once you've got the nack
*knack
pmichaud note that the grammar can be clever enough to recognize that qw, q:w, and q :w are all identical
17:38 davidfetter joined
cognominal www.lefigaro.fr/economie/2008/09/10...ndial-.php 17:39
trop fort le FMI et le Figaro
jonathan cognominal: l'incorrect channel?
moritz pmichaud: I don't think it makes sense to implement that yet, unless we implement pairs on quotes in general
cognominal oopd
pmichaud moritz, okay, if you wish. 17:40
moritz ouch, rakudo can't parse some unicode stuff in comments 17:42
pmichaud moritz: can you paste an example? It should be able to handle it. :-|
jonathan pmichaud: The "use of uninitialized variables" really makes the spectest_regression output a load longer... :-S 17:43
Is this a temporary thing?
(It appearing in the test output, not the feature)
pmichaud it's temporary until the tests are fixed to not use uninitialized variables :-) 17:44
jonathan Cool.
I guess there will be tests to test the warning too. :-)
pmichaud meaning, when the tests no longer use uninitialized variables, then you won't see the warnings any more :-)
it's permanent in the sense that using uninitialized variables will always issue a warning or exception of some sort :-) 17:45
moritz pmichaud: I just commited t/spec/S02-literals/quoting.t - the parser complains about line 68, even though fudge comment that out
jonathan OK, so it's the tests that need fixing. Thanks for the clarification. 17:46
moritz but the tests can only be fixed sanely if .defined really works
last I looked that was a bit of a blocker
pmichaud I did add .defined to Object already -- are there others?
dalek r30990 | jonathan++ | trunk: 17:47
: [rakudo] Methods written outside of a class, grammar or role should not be allowed unless they are anonymous.
diff: www.parrotvm.org/svn/parrot/revision?rev=30990
jonathan From S04: for =<> {...} 17:49
which is short for
for =$*ARGS {...}
jonathan wonders how on earth to implement that
pmichaud it's a token
jonathan Oh, phew. :-) 17:50
pmichaud =<> is a token in its own right, I think.
moritz that's where LTM really helps ;)
jonathan OK, that's the only sane way I could see it happening.
I'm glad you agree. :-)
In that case, it's really easy.
pmichaud that's the way we discussed it in the design meeting a couple of years ago when that came up :-)
jonathan ...if I can work out what precedence it should have...
pmichaud it's a term. 17:51
jonathan Or is it just a term?
pmichaud it's not in STD.pm yet, though.
jonathan OK, should I send a note about that to somewhere?
moritz just tell TimToady in #perl6 17:52
pmichaud I think TimToady will likely catch it at some point. :-)
dalek r30991 | moritz++ | trunk:
: [rakudo] implement qq qw and q quoting forms
diff: www.parrotvm.org/svn/parrot/revision?rev=30991
pmichaud moritz: fwiw, right now it would be quicker (perhaps much quicker) to factor out the initial q 17:53
moritz pmichaud: not sooo likely, because =<> probably already parses, only differnt 17:54
jonathan hang on - $*ARGS, isn't it @*ARGS? 17:55
pmichaud moritz: I bet =<> is parsing due to prefix:= followed by <> quoter 17:56
moritz yes, that's what I meant
NotFound There is a test in lexicals.t labeled 'find_lex: (Perl6 OUTER::)' that is todo'ed. This is related to the problems you where commenting? 17:57
pmichaud we did discuss that perhaps <> quoter should evaluate to @*ARGS when used in this manner, but we later decided it was better to not try such dwimmery and just use a special term for it
i.e., = followed by <> was just a little "too clever"
moritz pmichaud: re speed difference, it only makes a difference for parsing quote constructs, right? 17:59
jonathan pmichaud: Argh - it actually parses it as =<>!
As in = <>
(prefix:= called on empty list)
pmichaud right 18:00
you mean rakudo or STD.pm?
jonathan Rakudo.
pmichaud it's the same issue that we don't have a good way of mixing prefix operators and terms
i.e., LTM
jonathan Same bug we have as with ??? and !!! and ->
pmichaud it's possible that I could get term:<!!!>, term:<???>, and term:Ā« =<> Ā» to parse, though. 18:01
parsing -> is tricky because more than just the token has to be parsed.
moritz: the speed difference will be there for every time we're matching a term -- i.e., a place that a quote might be (as opposed to where a quote is) 18:02
jonathan Is there not a way we can give the precedence parser a list of things and say, "if you see this sequence of characters, back off and hand back to term"?
pmichaud sure, there's a way to do it
it does that now
moritz pmichaud: I can refactor it, no problem
pmichaud oh, wait, "hand back to term" -- not exactly
let me explain a bit further 18:03
(phone again, sorry) 18:05
moritz rakudo: my $x; say $x.defined 18:06
polyglotbot OUTPUT[set_attr_str() not implemented in class 'Undef'ā¤current instr.: 'parrot;Failure;!exception' pc 8693 (src/gen_builtins.pir:5554)ā¤called from Sub 'parrot;Failure;defined' pc 8747 (src/gen_builtins.pir:5572)ā¤called from Sub '_block11' pc 27 (EVAL_13:17)ā¤called from Sub
..'parrot;PCT::HLLCompiler;eval' pc 806 (src/PCT/HLLCompiler.pir:481)ā¤calle...
moritz pmichaud: (when you're back from phone) that's one of the things that block me from using .defined everywhere in the test suite 18:07
and it's no fun to figure out where I can actually use it, and where not
jonathan I'd expect putting the Object proto instead of Undef woudl help with that. 18:09
moritz isn't there a way to make *everything* accessible from rakudo an Object? 18:11
even foreign data structures that are imported via NCI
dalek r30992 | rurban++ | cygwin070patches: 18:12
: more make cleanup
diff: www.parrotvm.org/svn/parrot/revision?rev=30992
pmichaud moritz: short answer, no. 18:13
yes, when we get "my $a" to initialize to something other than Undef, then ".defined" should work
the other somewhat messier approach would be to add a .defined method to Undef, similar to the way we augment methods in Integer, String, ResizablePMCArray, etc. 18:14
jonathan pmichaud: After using the Object proto instead: 18:15
my $x; say $x.defined;
0
(Instead of undef)
However, Test.pm fails to compile now.
..\\..\\parrot.exe perl6.pbc --target=pir --output=Test.pir Test.pm
get_number() not implemented in class 'Object'
pmichaud I'm guessing an uninitialized value 18:16
jonathan Why would it fail in the compilation, though? 18:17
Adding the get_number v-table method, I then get even stranger things: "Could not find non-existent sub diag"
pmichaud where did you put get_number()? 18:18
diff output, please?
jonathan .namespace ['Perl6Object']
Maybe should abeen ont he proto... 18:19
nopaste?
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
purl somebody said nopaste was at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/
pmichaud I think adding get_number to Perl6Object might be evil -- it might affect Num, Int, Str, etc.
nopaste "jonathan" at 85.216.151.226 pasted "pmichaud - diff" (80 lines) at nopaste.snit.ch/14020
pmichaud at any rate, using get_number on a proto should produce a warning anyway (like Failure), so that's not really a solution
we need to avoid whatever is calling get_number in the first place
jonathan pmichaud: Agree, I did it more out of curiosity if it got us through the compile rather than as a fix. 18:20
oh, that diff is full of =<> stuff too
pmichaud okay, I have four tasks open now. :-| which one would you like me to focus on: getting terms to parse or fixing .defined or ...? 18:22
:-)
moritz some of the uninitialized warnings are triggered by TODO tests 18:23
jonathan All in parallel? :-)
I can investigate this one a bit more.
moritz lambdas would be quite nice
jonathan I'll leave you with the parsing.
The parser scares me.
moritz should I skip the TODO tests that cause warnings?
jonathan Hmm. Interesting. --target=past spits out this error at the end, after all of the output. :-S 18:25
18:25 hercynium joined
rurban svn: Commit failed (details follow): svn: MERGE of '/parrot/branches/cygwin070patches': 200 OK (svn.perl.org) 18:25
dalek r30993 | moritz++ | trunk:
: [rakudo] refactored qq, qw, q parsing to be more efficient
diff: www.parrotvm.org/svn/parrot/revision?rev=30993
jonathan Ah. It's in the END block. 18:26
rurban Is my branch already merged?
pmichaud I'm guessing 'main' is being a little over agressive.
jonathan rurban: No, svn is a tad messed up today. Your patch most likely has been commited.
purl okay, jonathan.
jonathan purl, rurban:, No, svn
purl jonathan: sorry...
rurban 200 OK doesn't look an error to me neither 18:27
jonathan Oh no, what has she saved that one under.
rurban: if you svn up, should find it was checked in
moritz yes, the svn server seems to be a bit b0rked
jonathan Taht's what I've been doing.
rurban everything ok.
pmichaud jonathan: ah, this points out a bigger bug -- @?END_BLOCKS only gets filled in when compiling perl6 source 18:28
jonathan pmichaud: Thing is, the variables are not set in a BEGIN block, but are tested in an END block.
pmichaud: Yes, but this is when we are compiling Test.pm that we get this error.
pmichaud right. exactly.
jonathan if ($testing_started and $num_of_tests_planned != $num_of_tests_run) { ##Wrong quantity of tests
Here, I think.
We do things like
our $num_of_tests_run = 0;
our $num_of_tests_failed = 0;
But not in a BEGIN block.
pmichaud I think you're missing my point 18:29
jonathan Probably. :-)
pmichaud right now, things get added to @?END_BLOCKS during the action methods
jonathan Yes.
pmichaud that's wrong in two ways
(1) we might not be compiling to immediate execution
(2) the PIR that we generate doesn't cause the END block to be added to @?END_BLOCKS when it's run
jonathan Ah. 18:30
pmichaud it needs to be part of a loadinit
jonathan wonders how Test.pm was working anway
pmichaud I'm guessing the END block isn't being run
jonathan Or maybe this bit int he END block never did get run.
We'd not have noticed - ti's just diagnostics.
pmichaud and thus the "diag" message :-)
jonathan :-) 18:31
All makes sense now.
OK, that explains what's wrong.
pmichaud so, first question -- do we need that END block?
jonathan Well, maybe not *need* because we've been doing fine without it for a while. But the diagnostics would probably be good to have. 18:32
pmichaud yes, but should we be getting those diagnostics just because someone decided to do "use Test;" ?
i.e., it's giving us the diagnostics whenever we run a test script directly
(as opposed to doing it with something like 'prove' or from an external harness)
jonathan That, I can't answer 18:33
pmichaud also bear in mind that it's likely that the test functions will become builtins :-)
I suggest the following:
(1) remove END from Test.pm
(2) see if things work with the Undef-->Object switch, and if that solves Moritz's .defined issue, if so, commit
(3) file a ticket that we're not handling END blocks properly :-) 18:34
end
alternate to (3) is to just fix the END block handling :-) 18:35
jonathan Done 1
particle invalid code after 'end'
jonathan Runing tests to determine 2
pmichaud I need lunch.
jonathan This does have the slight issue that
my $x; say $x.WHAT; # Object
:-)
pmichaud ...before it was doing, what?
jonathan Undef
pmichaud Undef is clearly wrong. 18:36
jonathan Or more likely, Failure
I think Failure.
pmichaud oh, it might have been mapped to Failure.
jonathan Yes.
It was Undef PMC, but that was mapped to Failure.
Talking of food...it's time I cooked some too.
pmichaud anyway, TimToady has speculated on #perl6 that perhaps things default to the Object proto, so while we don't have a spec yet, that's good enough for me.
jonathan creates a LolCat proto and defaults to that, hoping it might make it into the spec 18:37
pmichaud oh, that reminds me
moritz not that in 'sub foo ($x?)' $x can't default to Object proto, rather Any (IMHO)
jonathan moritz: Hmm, good point. 18:38
pmichaud that's okay, parameter handling is going to be totally different anyway
we never have an uninitialized param
at least, not in the sense that we do for variable declarations
but parameter initializing code is different from variable declaration code, so it shouldn't be a big issue 18:39
(Object vs. Any)
jonathan Damm. The change makes us fail some tests.
Failed 9/159 test scripts. 35/4859 subtests failed.
:-(
pmichaud probably having to do with definedness and/or object truth
or possibly being able to increment or otherwise use uninitialized values 18:40
anyway, lunch is a requirement now.
bbiaw
particle has the code for november been published? 18:42
pmichaud it's in a git repo, I think.
jonathan is($one, undef, 'two blocks ({} {}) no semicolon after either,.. first block does not execute');
That is one that now fails, for example.
pmichaud sure, because Object != Failure :-)
moritz jonathan: because it stringifies different
ly
particle: github.com/viklund/november/ 18:43
particle thanks
jonathan pmichaud: Aye. But not quite sure what the fix for this is. :-) But anyway, lunch...and for me dinner.
pmichaud the test itself is wrong 18:44
jonathan OK, and it should be?
pmichaud we can't use 'is' to check for undef anymore (at least not as currently defined)
particle nok($one, '...')
pmichaud it should be ok !$one.defined
particle er, right 18:45
pmichaud ....which is why moritz++ wants .defined to work (currently it doesn't -- it gives an error when we attempt to invoke the 'defined' method on an Undef PMC)
so, fixing the code and the test should cause everything to work :-)
it's okay with me to use a stopgap of adding a 'defined' method to the Undef PMC
rurban pdd30_install idea: parrot install.pbc mylib --build --test --installable --test-installable --install 18:46
jonathan Meh, if that's all it will take to get this fixed up, I'll fix the testes now.
rurban --build --test --installable --test-installable --install being optional
jonathan *tests
!!
pmichaud maybe dinner would be better first. :-)
rurban this should be used for parrot languages and libraries (on CPAN6)
jonathan Yes. 18:47
jonathan goes for dinner
moritz jonathan: with your fix, will $stuff ~~ undef work? 18:50
pmichaud we should be able to make it work, yes.
that's really just a matter of defining Failure.ACCEPTS, I think.
moritz then I offer that I'll fixe the broken tests that jonathan's fix reveals 18:51
pmichaud we should be able to make that work even before jonathan's fix
except that he and I apparently both need to eat.
so, food first.
(really gone this time.)
19:09 japhb joined 19:14 Hinrik joined
rurban cpan6? 19:19
purl it has been said that cpan6 is more like a METAPAN
rurban I envision either "cpan6 mylib --download --build --test --installable --test-installable --install"
or cd mylib && parrot Makefile.pir 19:20
Makefile.pir does load_bytecode 'Parrot/Install'
and generates the Makefile 19:21
19:30 japhb joined
dalek r30994 | moritz++ | trunk: 19:36
: [rakudo] allow $stuff ~~ undef
diff: www.parrotvm.org/svn/parrot/revision?rev=30994
19:37 Hinrik joined
moritz pmichaud: t/spec/S04-statements/return.t exhibits some failures after being re-written as ok(!defined(subcall()), ...) 19:41
pmichaud: should I fudge them and open a ticket?
19:42 hercynium joined
dalek r30995 | rurban++ | cygwin070patches: 19:44
: [pdd30] added long-term goals and competing layout variants
diff: www.parrotvm.org/svn/parrot/revision?rev=30995
jonathan returns from The Dinnber 19:49
*dinner
moritz: Will do spectest_regression again with your latest changes to it and Rakudo plus my Object change and see how it goes. 19:50
moritz jonathan: ok. 3 failed tests in return.t are to be expected (if not even better) 19:51
19:52 hercynium joined
dalek r30996 | rurban++ | cygwin070patches: 19:55
: root/Makefile: languages need install_config.fmpc, no circular all-installable deps
diff: www.parrotvm.org/svn/parrot/revision?rev=30996
jonathan Yes, the ones in return.t are new. 19:58
(As in, weren't there before your changes)
I've also got a new failure in t\\spec\\S03-operators\\binding-scalars.raku 1 256 28 2 28
moritz try to run that one again please 19:59
I don't get it in trunk
and I've seen some temporary failures now and then during the last few days
jonathan not ok 27 - bound keyword# TODO List binding 20:00
get_number() not implemented in class 'Object'
20:02 Hinrik joined
jonathan equality.t fails on 20:02
ok($foo == 0, "Undef == 0");
We deleted the END code that did similar. 20:03
But we shouldn't just do that here I suspect.
moritz aye 20:04
dalek r30997 | rurban++ | cygwin070patches: 20:05
: root/Makefile: 58354-installable_parrot_config.patch
diff: www.parrotvm.org/svn/parrot/revision?rev=30997
rurban svn is always locking up today
moritz a Any, Any multi for == that numifies?
jonathan We have that 20:06
The problem is that Object refuses to numify.
The error about get_number() occurs because an Object will not numify.
rurban and stringifiy it and numify the strings? 20:07
particle should Object numify? i think not.
eval_dies_ok(+$foo, "Object does not numify");
jonathan particle: If we're going to stick it in scalars by default instead of Failure (Parrot Undef), however...
Doesn't feel especially Perl-ish. 20:08
particle can you attach a trait that allows it to numify when stuck in a scalar?
jonathan Well, we could stick these in the proto rather than for Object itself perhaps.
The other intresting one will be: my $foo; say $foo; # Object 20:09
Bit surprising.
Maybe if there's a Failure role that gets mixed in, it'd work. 20:10
particle Object but Failure :)
jonathan Right.
So we do that and just stick it somewhere that can be retrieved each time we want to use it in a Scalar. 20:11
dalek r30998 | rurban++ | cygwin070patches:
: [jvm] fix codetest, rm Makefile
diff: www.parrotvm.org/svn/parrot/revision?rev=30998
particle yep
jonathan OK, will get pm's opinion, when he's done with nomming lunch. :-)
dalek r30999 | rblasch++ | trunk: 20:17
: [config] Report MSVC version during Configure.
: The MSVC version is important when looking for issues, but people sometimes
: forget to add this to tickets, but post Configure's output.
diff: www.parrotvm.org/svn/parrot/revision?rev=30999
pmichaud back
dalek Ronald Blaschke | Platforms: 20:18
link: www.perlfoundation.org/parrot/index...?platforms
jonathan pmichaud: w/b - you can haz backscroll 20:19
pmichaud my $foo; if +$foo == 0 { ... } # should be a "use of uninitialized value" warning/error 20:20
jonathan OK, but the test should suceed also, if it's a warning?
dalek r31000 | rurban++ | cygwin070patches:
: [pdd30] quote =>
diff: www.parrotvm.org/svn/parrot/revision?rev=31000
moritz jonathan: yes
pmichaud well, if "use fatal" is in effect it'll die. but yes, in absence of fatality it would numify to 0, the same way that Failure does 20:21
I almost want to create a Perl6Undef role that incorporates these behaviors
then all protoobjects would perform that role, as well as Failure instances
in parrot, do vtable methods in roles compose properly? 20:22
jonathan Not completely sure - I'd think they do.
pmichaud okay
jonathan They can probably be made to without much trouble if not.
pmichaud if nothing else I could do it with class composition 20:23
jonathan Sure, but it's nicer as a role.
pmichaud roles can haz attributes?
jonathan Yes.
But to be composed properly you need to use the Rakudo stuff to do it. 20:24
pmichaud oh, P6object should probably learn to handle roles
jonathan Parrot doesn't handle that. Perl 6's needs are a little interesting.
Probably.
purl Really? Probably? Are you Certain it's not certain? Are you sure it's unsure? I think you need to look harder.
jonathan Perl 6's role composition for attributes actually ties into the Perl 6 type system a bit too.
pmichaud well, I'm thinking it'll be strictly internal, not anything exposed 20:25
20:25 Whiteknight joined
jonathan Sure. 20:25
pmichaud (except for the methods that get composed in)
jonathan Maybe better to wait until we're a bit more complete with roles before working it into P6Object, though?
pmichaud maybe
jonathan Things are almost certainly going to change a lot when I do parametric roles.
pmichaud otoh, protoobjects in P6Object might be a bit better off as roles
instead of the P6protoobject being a class as it is now 20:26
jonathan A Perl 6 role object is going to become something like a multi-sub.
Which itself contains a bunch of Parrot-level roles.
However, that blocks on me finishing Perl 6 multiple dispatch first. :-) 20:27
jonathan has a whole stack of trickyish stuff to worry about.
pmichaud I wonder if protoobjects should really be done with mixins 20:28
jonathan Very possibly.
pmichaud I guess that's kinda what P6object is doing now
jonathan Yeah.
It pretty much is. :-)
pmichaud except it's mixing in a class instead of a role.
jonathan Create an anonymous subclass that inherits from the protoobject class.
pmichaud that's what it does now 20:29
jonathan It's about the same thing as a does
Or a but
pmichaud yeah
jonathan So yes, you could do those quite easily as roles.
(It'd actually once composed perform a tiny bit better too, I expect...) 20:30
OK, so for undefined values, we're going to go with a Perl6Undef role?
pmichaud I need to think about it a little bit more 20:31
jonathan OK
pmichaud I'm pretty certain that P6object will somehow override get_number, etc., in protoobjects
jonathan I really shoudln't commit my patch to switch us to Object instead of Undef. It breaks far too much.
pmichaud it's an easy enough patch -- just hold it, or submit it to RT so several of us can play with it
20:31 contingencyplan joined
jonathan Heh, it's a couple of lines. :-) 20:31
pmichaud we could even work on it in a branch, although I think it's not (yet?) significant enough to warrant a branch 20:32
moritz was asking that we get $foo ~~ undef to work -- that we should be able to do immediately
jonathan I already have one nasty out-dated branch. :-|
I think he checked it in already himself, while we were eating. :-)
moritz pmichaud: I already tried
pmichaud: and comitted, because I thought it worked
> say undef ~~ undef 20:33
0
Tene jonathan: want me to update the lazy branch for you?
pmichaud oh, I didn't see the dalek message for it
jonathan Tene: That would be great.
moritz obviouusly I failed
jonathan is fail at branch management.
Tene I should be able to do that today.
jonathan Thanks!
Don't expect much to pass in that.
Before or after merging.
pmichaud oh, there's the dalek message... just a sec 20:34
jonathan pmichaud: One other issue is that proto-objects need to override .item to just return themselves. And not pass up to the .item of the class itself. Which if it's a list causes oddness. :-) 20:35
I'm going to do that now.
pmichaud for Failure.ACCEPTS, I think I'd recommend $I0 = defined other instead of $I0 = other.defined()
also, the logic seems backwards to me 20:36
the test should return false if other is defined, true otherwise
jonathan: I'm still having to re-think .item a bit as part of arrayref and hashref 20:37
moritz must have been sleeping
pmichaud however, you're correct that .item on protos should return itself. That can be added the same way we did .WHICH, I suspect.
20:37 Hinrik joined
pmichaud (or .WHERE. I forget. Too many interrogative pronouns.) 20:38
moritz pmichaud: I've got a fix now... testing locally...
jonathan pmichaud: Yes, will do. 20:39
20:39 Hinrik joined
jonathan It'll let me close an RT ticket. :-) 20:39
pmichaud jonathan is getting all of the fun of closing rt tickets today :-|
nopaste "jonathan" at 85.216.151.226 pasted "Switching to Object proto from undef" (13 lines) at nopaste.snit.ch/14024
moritz pmichaud: you didn't close the Hash.kv ticket, although you said you'd do
pmichaud I found it it's still broken 20:40
dalek r31001 | rblasch++ | trunk:
: [config] Adjusted tests to config/auto/msvc changes.
diff: www.parrotvm.org/svn/parrot/revision?rev=31001
pmichaud s/it/out/
jonathan pmichaud: There is the patch. But it's going to change notably if we're doing the mixin thing anyway.
pmichaud rakudo: my %a = { b => [1,2] }; say %a.kv.perl;
polyglotbot OUTPUT[["b", 1, 2]ā¤]
jonathan I can re-create it in the same 2 minutes it took the first time if we do want it.
pmichaud it'll change?
jonathan Well, we'll need to stick the object with the role mixed in 20:41
pmichaud that would be Object -- the role would already be mixed in
jonathan Unless you were thining that ProtoObject would just carry the "warn and numify to 0" stuff?
Aha.
20:41 Hinrik joined
pmichaud yes, Protoobject will have it. 20:41
jonathan OK, so it'd not change.
OK.
pmichaud all protoobjects should not be used as values
jonathan *nod*
pmichaud (because they're all undefined)
of course, we'll have a way for a class to override that behavior for its proto, but that's the default 20:42
dalek r31002 | moritz++ | trunk:
: [rakudo] fixed Failure.ACCEPTS, pmichaud++
diff: www.parrotvm.org/svn/parrot/revision?rev=31002
pmichaud that's why I was saying earlier that I may put warnings directly into P6protoobject 20:43
so that we get it for all protos, not just Rakudo ones
jonathan Aha, OK.
pmichaud
.oO( if Failure.ACCEPTS(pmichaud++), then does that mean I'm undefined?)
moritz pmichaud: you're meta-defined 20:44
jonathan .item and .list on a proto are obvious enough - .hash? Exception?
pmichaud I'd leave .hash to its default
(which is generally to try to build a hash from .list)
jonathan my %x = Hash.new.WHAT; # is ok? 20:45
pmichaud that one confuses me. 20:46
jonathan Me too
pmichaud you're assigning a protoobject to %x ?
and isn't that the same as my %x = Hash ?
jonathan Yes.
pmichaud that's likely an error
but that's a type mismatch, unrelated to the proto
oh, it's not a type mismatch 20:47
jonathan OK, but thing is that assigning to %x will call .hash on Hash
pmichaud effectively it's the same as my %x = list(Hash);
jonathan Which for a Hash returns...itself.
Unless you have a type which defines .hash differently, though?
pmichaud my %x = Hash does not call .hash on Hash directly
it calls .hash on list(Hash) 20:48
jonathan OK
pmichaud because my %x = ... is a list assignment
jonathan Aha.
OK
So we just don't bother writing hash method for protos and we should be OK?
pmichaud I think so.
if I'm wrong, we'll find out :-)
jonathan Well, it doesn't error.
my %x = Hash; # runs fine in Rakudo today
pmichaud that's because we don't really implement a good list assignment yet :-) 20:49
jonathan OK.
pmichaud rakudo: my %x = Hash; say %x.WHAT; 20:50
polyglotbot OUTPUT[Hashā¤]
jonathan It calls infix:= on Perl6Hash, which in turn calls .hash on Hash.
Which reads
pmichaud oh, because we've overloaded infix:=
jonathan .sub 'hash' :method .return (self)
.end
Right.
So we never end up making a list, and thus we never see an error. 20:51
pmichaud I think that's an incorrect implementation that works for now.
jonathan Ah.
moritz there's no hash context
dalek r31003 | rblasch++ | trunk:
: [config] Quote $icuheaders in t/steps/auto_icu-01.t.
: For example, the path may contain backslashes on Windows, messing up the
: regex.
diff: www.parrotvm.org/svn/parrot/revision?rev=31003
pmichaud at some point in the future we may want to implement a Perl6Hash PMC that acts more like a list of Pairs 20:52
jonathan OK.
pmichaud with some very good key-indexing
jonathan So for now I should just ignore the problem? :-)
pmichaud sure, or file an RT marker for it :-)
up to you.
jonathan I don't see why we can't die early.
Trying to form a Hash when you only have one element can never work.
pmichaud well, that's what will happen.
jonathan As I understand it anyway. 20:53
OK.
pmichaud it'll be the same as if we had done
rakudo: my %a = 1;
polyglotbot OUTPUT[Odd number of elements found where hash expectedā¤current instr.: 'parrot;List;hash' pc 2872 (src/gen_builtins.pir:2010)ā¤called from Sub 'parrot;Perl6Hash;infix:=' pc 4689 (src/gen_builtins.pir:3222)ā¤called from Sub '_block11' pc 25 (EVAL_11:15)ā¤called from Sub 'parrot;PCT::HLLCompiler;eval'
..pc 806 (src/PCT/HLLCompiler.pir:481)ā¤called from...
jonathan Right.
That's what I'd expect from my %a = Hash;
pmichaud we could fix infix:= so that it first coerces to list context before building the hash 20:54
that would make my %a = Hash; fail properly
jonathan That'd work for me. 20:55
pmichaud but since I'm expecting we'll be revamping contexts yet again in the near future, I'd say let's not worry about it too much
jonathan Yes.
We need to solve the "can't assign match objects" problem at some point too. 20:56
pmichaud when does that occur?
(I've lost track)
moritz for example when returning a match object from PIR from Str.subst 20:57
or the to-be-written Str.comb
no, Str.match (not subst)
Tene Okay, either tomorrow night or saturday during the day I'm going to get some caffeine and crank through the exception issues. 20:58
jonathan Yes, from .match
Tene At the very least do pmichaud's throw API refactor.
jonathan But just try
Tene I'll see if I can eliminate the "disabled exception handlers" issue also
pmichaud Tene: I was wondering if I assign a zero to the exception handler if that would re-enable it. 20:59
jonathan rakudo: "foo123" ~~ /o(\\d+)/; my $x = $/; say $x; say $x[0];
polyglotbot OUTPUT[o123ā¤get_pmc_keyed() not implemented in class 'String'ā¤current instr.: '_block11' pc 82 (EVAL_13:32)ā¤called from Sub 'parrot;PCT::HLLCompiler;eval' pc 806 (src/PCT/HLLCompiler.pir:481)ā¤called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1078 (src/PCT/HLLCompiler.pir:610)ā¤called from Sub
..'parrot;PCT::HLLCompiler;command_line' pc 1257 (s...
Tene pmichaud: yes. can you get the EH in pir, though?
pmichaud Tene: sure
if I build it and register it instead of using push_eh LABEL
$P0 = new 'ExceptionHandler' 21:00
set_addr $P0, label
push_eh $P0
...and then later
$P0 = 0
to reset the handler to being active
Tene Want me to confirm that that works?
pmichaud sure, I was going to write a reply to the rt ticket with a demo (if it worked), but I've been too busy answering questions for little or no karma points :-) 21:01
Tene pmichaud++ # bugging me to do stuff
jonathan pmichaud++ # answering questions for little or no karma points
pmichaud ....but in thinking about gather/take altogether, I've been wondering if resumable exceptions is really the way to go. Coroutines might be better
Tene I thought about that too
dalek r31004 | jonathan++ | trunk:
: [rakudo] Fix assigning a proto-object.
diff: www.parrotvm.org/svn/parrot/revision?rev=31004
pmichaud but I'm not sure how to .yield from a different sub
jonathan A friend was asking me the other day about iterators in Perl 6, so I mentioned gather/take as being a way to implement such things. 21:02
pmichaud for a lot of the builtins we could probably handle iterators using .yield
jonathan And he then asked if you could have an array with that iterator in it, and then shift from it in different threads, so it's like a task queue. :-)
I was like, "hmm...well I'd hope so", then thought about the fun of making that actually work. :-S 21:03
pmichaud but I've been thinking that we might be able to do .yield in the return_pir section of blocks
Tene pmichaud: it runs, but segfaults at the end
pmichaud so, we throw an exception, but instead of doing .return(foo) we do .yield and then re-enable the exception handler
nopaste "tene" at 67.137.148.179 pasted "exception handler re-enable test for pmichaud" (34 lines) at nopaste.snit.ch/14025 21:04
pmichaud I was going to re-enable the handler inside of the handler itself
i.e., just before returning to the continuation
anyway, we still need resumable exceptions for "warn" semantics, but I'm thinking gather/take based on .yield might be a bit better 21:05
I think there is a problem there though that I doubt that Coroutines can contain :outer
(thus my earlier comments that I think we need to eliminate the Closure PMC) 21:06
jonathan Gah, so I'm trying to get the RT queue for Rakudo down to 150 and then moritz goes and files another bug when I get down to 151!
:-P
pmichaud moritz++ # make jonathan *work* for his accomplishments :-)
moritz lol
pmichaud when I last worked on the RT queue, it was down to about 70. I don't know what happened over the summer -- someone messed up my queue :-) 21:07
cotto_work the only bad thing that can happen to the number of tickets is for it to stay the same
jonathan moritz: Hmm. On the latest one you filed...
sub bar { return }; say defined(bar());
moritz pmichaud: I think it was obra, masak and me ;)
21:08 japhb joined
jonathan Gives 1 21:08
oh, wait, that's the problem
duh!
moritz yes
jonathan sub bar { return }; say bar().WHAT # list
Heh.
pmichaud isn't that correct? 21:09
jonathan Perhaps.
But an empty list is defined, right?
pmichaud yes, it is.
jonathan So defined(bar()) is thus 1? 21:10
pmichaud I'm thinkin gyes.
jonathan Which would make sense given the sub was successful.
pmichaud say bar(); evaluates the result of bar() in list context
i.e., bar() returns an empty capture, which becomes an empty list when taken in list context
which is defined
jonathan of coruse, if bar() { say 42 } # prints nothing
But truth is differnet from definedness. 21:11
pmichaud right, becaue an empty list evaluates to false
jonathan If you explicitly return undef, then of course: sub bar { return undef }; say defined(bar()) # 0
OK, so the ticket is wrong?
rt.perl.org/rt3/Ticket/Display.html?id=58770
moritz is quite sure he saw that in the specs, but can't find it now
pmichaud there is the possibility that defined(bar()) should be evaluating bar() in item context 21:12
and that the empty capture in item context should return Failure
or Object
and therefore should be false
jonathan wonders if the spec says that anywhere
pmichaud I suspect that's the case
I don't think it's in the spec yet, I think that's just from TimToady musings 21:13
jonathan OK
Maybe wait until he muses it into the spec... :-)
pmichaud I think the ticket is valid.
jonathan OK
21:25 japhb joined
jonathan notices a bug in Object.pmc and wonders how we survived so long with it 21:28
Or...hmm. 21:30
Khisanth it inherits from cockroach? :) 21:34
jonathan :P 21:35
cotto_work DietCoke, ping 21:36
jonathan Looks almost like things were re-written to work differently, and a chunk of code that did things the original way were left hanging around, and didn't actually do anything by accident. 21:37
pmichaud bring out yer dead (code)! bring out yer dead (code)! 21:48
cotto_work you almost made me lose my drink 21:53
pmichaud "twas a woman that drove me to drink, and I never got to thank her for it."
21:59 davidfetter joined
Tene Hmm. I need to show this little PIr segfault example to chromatic. 22:00
Anyone want to post it to a ticket for me?
moritz he'll be delighted ;) 22:01
cotto_work 'segfault'()
Tene moritz can do it!
nopaste.snit.ch/14025
moritz knows next to nothing about PIR 22:02
Tene moritz: you know how to post tickets and cc chromatic, though.
PerlJam Tene: sounds like you need to learn :)
particle i suspect he's email-inoperable atm
moritz ok, I can do it 22:03
Tene Kinda. Email-inconvenient. I'm trying to concentrate on $job.
And historically, I forget about these tasks pretty quickly.
PerlJam Tene: yeah, me too.
moritz bug report sent 22:05
PerlJam too bad you can't just DCC it to a bot and have the bot proxypost it for you
Tene Hmm. I could write a shell script to do it, actually...
I should do that. That's a great idea. 22:06
PerlJam++
moritz I already thought about an IRC bot that pastes evalbot's output into a stub ticket
Tene It would be pretty simple to make polyglotpot do that.
It can already nopaste.
perl6.pir: say "lol hi" 22:07
nopaste "polyglotbot" at 193.200.132.146 pasted "perl6 pir" (39 lines) at nopaste.snit.ch/14026
moritz Tene: RT #58772 it is
Tene perl6.paste: say "spamming the nopaste" 22:08
nopaste "polyglotbot" at 193.200.132.146 pasted "perl6 paste" (1 line) at nopaste.snit.ch/14027
moritz that nopaste feature would be quite useful for evalbot+STD.pm, because the parse tree never fits into IRC 22:09
Tene It uses tools/dev/nopaste.pl in the parrot tree 22:11
cotto_work that's a very long backtrace
Tene You could jam in support for STD.pm into polyglotbot.
dalek r31005 | jonathan++ | trunk: 22:12
: [rakudo] Fix to new in Perl6Object so we don't blow away PMC instances for PMCs we are inheriting from.
diff: www.parrotvm.org/svn/parrot/revision?rev=31005
moritz Tene: the problem with STD.pm is more the environment, not the code to run it
Tene ah 22:13
moritz but I could integrate nopaste.pl into p6eval 22:14
cotto_work ctx == ctx->caller_ctx == ctx->caller_ctx->caller_ctx ... 22:24
jonathan Reccursion? 22:29
cotto_work yes, in mark_context. I suspect that chromatic will have to figure out why, though. 22:30
I'm looking at that bug Tene nopasted earlier. 22:31
jonathan Well, it comes up naturally if the program is _meant_ to recurse.
Ah.
cotto_work It shouldn't be infinitely recursive, though. ;) 22:32
jonathan No. 22:34
Which was the nopaste you were looking at?
cotto_work nopaste.snit.ch/14025
jonathan can't find it amongst the many in the backscroll
cotto_work Unfortunately it's more fun to try chasing that down that work on what I'm supposed to be working on. 22:36
pmichaud ...that doesn't sound unfortunate to me :-) 22:37
dalek r31006 | jonathan++ | trunk: 22:38
: [rakudo] Clear namespace after we leave one, so later rules don't get attached to earlier grammars.
diff: www.parrotvm.org/svn/parrot/revision?rev=31006
jonathan Woo! Down to 150 tickets! 22:39
pmichaud jonathan: I think that the namespaces should be an array
jonathan Sure, when we do nested stuff.
Whiteknight what's down to 150 tickets?
pmichaud and we should "pop" to the outer namespace
jonathan Yup.
pmichaud okay.
jonathan But I think many other things get in the way of nested classes/grammars etc yet.
Whoever of us gets lucky enough to the package/symbol to match with what STD.pm is doing can have that fun when they reach it. :-) 22:40
cotto_work Whiteknight, looks like perl6 new+open+stalled
jonathan is going on holiday soon ;-)
Whiteknight: what cotto_work said - the Rakudo queue
pmichaud moritz: (unicode in comments) -- what comments are causing rakudo to not parse? 22:41
oh, nm, I think I found it
jonathan pmichaud: I have one uncommited chunk of code left from today, for =<> 22:42
But it doesn't actually work because of the parser issues.
Want me to check it in anyway?
pmichaud oh yes, I was going to explain that earlier but got caught on the phone
in theory, using term:=<> should work even in the present parser
the reason why term:-> can't work yet for pointy blocks is that we have to parse more than just the pointy block 22:43
sorry, more than just the pointy
(we have to grab the block as well)
ideally I'd be able to write term:Ā« !!! Ā» is parsed(&foo) { ... } and then let a 'foo' rule or token do the actual parsing 22:44
unfortunately, the operator precedence parser eats the !!! prior to calling the parsing rule (because that's what audrey and TimToady told me to change it to a couple of years ago) 22:45
for the term tokens that simply need to eat the symbol itself, such as !!!, ???, and =<>, we might be able to get those to work
for the pointy block to parse as a term, I have to go back and undo the change that causes the token to be eaten prior to calling the "is parsed" rule 22:46
unfortunately, that breaks everything that currently uses is parsed on non-empty term: , which include quite a few things in PGE itself
so, it's a bit of a refactor to fix. It's one I have to fix, and that is scheduled to occur in the first couple of weeks of my next grant (which should start this weekend) 22:47
but it's non-trivial.
once I have the fix that doesn't eat the token as part of the parsing, then the pointy block term becomes token term:Ā« -> Ā» is parsed(&pblock) { ... } and everything should "just work" 22:48
and the others become token term:<!!!> { ... }
and all of that can occur before we have the "official" LTM algorithms in place
anyway, I have to run now -- back tomorrow.
jonathan Question on workaround for now. Since when we called something with is parsed, we know what we're calling and thus in turn know what we parsed beforehand...
pmichaud we don't know what was parsed beforehand, in the case of pblock 22:49
because pblock expects to find a '->'
jonathan ...can we not just call something for pointy block that says "OK, I know you swallowed a ->, and now match..."
pmichaud we could workaround it that way, yes, but I prefer not to.
jonathan Oh, sure, but we can have a copy of the rule, pblock_hack, that doesn't look to parse the -> because it was already parsed.
22:50 mberends joined
pmichaud I'd rather fix the term: rule, which has to happen anyway. 22:50
I have to run to kid soccer practice now
bbl
jonathan OK, I will sleep soon too
So, tomorrow. cu :-)
cotto_work hmmm. The fix might be trivial. It'll be interesting to see if chromatic comes up with the same thing. 22:53
22:54 bacek joined
jonathan waves at bacek 22:55
Think I fixed a couple of tickets you filed today. :-)
s1n pmichaud: when you get back, i've gotta grill you about something 23:01
23:09 tetragon joined 23:10 kid51 joined
cotto_work my "fix" still seems to DTWT 23:14
23:27 wknight8111 joined 23:30 cjfields joined
cjfields jonathan++ # for RT 58678 fix 23:31
wknight8111 If I absolutely have to buy a book, a good technical one, does anybody have any recommendations? 23:32
I am to books what my Fiancee is to shoes
particle i hope you have "the pragmatic programmer" 23:33
if not, you must
Hinrik you have the Camel book, I presume
particle no longer has the camel :( 23:34
it's been stolen/lost/"permanently loaned"
PerlJam hasn't had a Camel since they were pink
particle but i have safari via acm
of course, they have 3rd edition of camel, not 5th 23:35
23:35 Limbic_Region joined
wknight8111 I've practically got the whole O'Reilly catalog :) 23:35
I don't have the pragmatic programmer, no
wknight8111 toodles off to amazon
particle get it. NOW.
cjfields Anyone have an idea where to place grammar tests for Rakudo? Couldn't find anything in t/spec.
wknight8111 65 new and used from 18.99$! 23:36
particle t/spec/S05-grammar/foo.t
cotto_work buying books is much easier than reading them
particle code complete is a good book, too
steve mcconnell, microsoft press 23:37
some number of c's, n's, and l's
wknight8111 I've got Code Complete 23:38
wknight8111 is very proud of his library
23:38 Ademan joined
particle have the set from knuth? 23:38
wknight8111 in hardcover 23:39
jonathan used to buy lots of books, then realized he hardly ever read them, so kinda stopped
23:39 Debolaz joined
wknight8111 I reference them all the time 23:39
particle i stopped buying perl books after i met the authors. bums, all of them.
wknight8111 probably more then I should
cotto_work I was quite surprised to find out that Allison edited Programming PHP 23:40
wknight8111 She's an editor at O'Reilly, isn't she?
She probably doesn't make any money if she's snobby or picky
I would like to get a good book about VMs or programming languages or compilers, something in that area 23:42
but there are so few of them available
cjfields thx particle. BTW, agree about 'Code Complete'.
Hinrik they should update Perl 6 & Parror Essentials 23:44
particle i still reference "numerical recipies in fortran 77" more than i'd like :)
Hinrik that's a good book
particle wish i had the c version
hinrik: the source for the book is in the pugs and parrot repos
p6pe, that is
so feel free to update it :) 23:45
Hinrik oh, awesome
Debolaz Good books in general seems to be few and far between these days. Maybe I'm just being nostalgic though..
particle mjd's HOP is a fun book
Hinrik particle: I might actually take you up on that
as soon as I figure out what's missing
cotto_work HOP++
particle hinrik: please do! we need the updates
Debolaz particle: It's probably the only perl related book I actually like. 23:46
cjfields likes HOP as well 23:47
Hinrik I liked Mastering Algorithms with Perl
blog.nix.is/perl-book-mini-reviews
kid51 cotto_work: Do you have any update on rt.perl.org/rt3/Ticket/Display.html?id=43715 ? Thanks. 23:49
cotto_work kid51, nope
particle ok, so what do i do first: parrot i18n? finish mod_parrot configure engine? perl 6 cmdline syntax? 23:50
Hinrik the first thing sounds most important
cjfields msg moritz I would like to add some spec tests for RT #58678, but this is blocking on further clarification on spec per RT#58676. I'll check backlog for your response. 23:51
purl Message for moritz stored.
23:51 cjfields left
Debolaz "Structure & Interpretation of Computer Programs" is another book I like. 23:55
Even though I don't like lisp. :-)
particle yes, and that's available free online from mit 23:56
Debolaz And in video format.

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!