perl6-projects.org/ | nopaste: sial.org/pbot/perl6 | evalbot: 'perl6: say 3;' | irclog: irc.pugscode.org/ | ~280 days 'til Xmas Set by mncharity on 18 March 2009. |
|||
00:01
mikehh joined
|
|||
cspencer | jnthn: you still around? | 00:10 | |
00:12
Diederich joined
00:16
lichtkind_ joined
00:25
Tene left
00:34
lichtkind left
00:35
gdonald joined
00:36
gdonald left
00:37
Whiteknight joined
00:41
kate21de left
|
|||
pugs_svn | r25969 | lwall++ | clarify (we hope) how the top-level lexical, package, and dynamic scopes interact | 00:41 | |
00:56
alc joined
01:16
Whiteknight left
01:25
gdonald joined
01:26
Entonian joined
|
|||
skids | @tell ruoso www.abrij.org/~bri/S07-tempurl.diff S07 edits + new coro section | 01:26 | |
lambdabot | Consider it noted. | ||
pugs_svn | r25970 | lwall++ | clarifications to .caps and .chunks requested by moritz++ | 01:27 | |
01:33
gdonald left
01:34
dukeleto joined
01:35
gdonald joined
01:39
jferrero left
01:41
gdonald left
|
|||
cspencer | S32-setting-library/Numeric.pod seems to indicate that some of the functions/methods we're currently putting into Any-*.pm will be located elsewhere at some point - is Any.pm just a temporary repository for them? | 01:51 | |
dukeleto | cspencer: seems that way | 01:52 | |
cspencer | dukeleto: any idea why that's the case for the momen | ||
t? | |||
moment, rather? :) | |||
dukeleto | cspencer: the whole setting ideas is somewhat new, and I think that I was thinking of the any-*.pir files | 01:53 | |
but in general, I think S29 and S32 are still in flux | |||
cspencer | alrighty | 01:54 | |
01:58
Entonian left
|
|||
mikehh | rakudo (1c263b0) builds on parrot r37843 - make test PASS, make spectest FAIL 1/327 test programs. 1/9577 subtests failed. - t/spec/S05-capture/caps.t - failed test 6 | 01:59 | |
02:01
Entonian joined
02:07
Limbic_Region left
|
|||
pugs_svn | r25971 | leto++ | Tests for roots() of a Complex | 02:07 | |
02:07
Entonian left
|
|||
TimToady | Any is a place for methods that (as a language policy) redirect to some more specific type, such as the various operators that coerce to list | 02:10 | |
02:12
cspencer_ joined
|
|||
cspencer_ | TimToady: I'd just seen a reference in S32::Numeric to a Num role which seemed (to me at least) to include many of the methods currently in Any, and was wondering how that'd work | 02:14 | |
02:15
cspencer left,
jyy joined
|
|||
TimToady | In general methods should be defined in the class they make the most sense, with the assumption that their invocant is already of the right type. | 02:25 | |
any extra coercion is presumably in the Any version of it that delegates to the List (or Num, or whatever) version of it | |||
but we do have to think about the cases where the type of the invocant is specified | 02:26 | ||
esp where exported as a multi | |||
and if there's a mechanism for using the same def in all those places, it's probably worthwhile not having the extra indirection overhead | 02:27 | ||
but I'd rather have correct first... | |||
cspencer_ | ok. so in the case of something like "exp" or "log10", where would you suggest they end up? | ||
dukeleto | or roots()? currently I have a version in any-num.pir that calls out to math.pir | 02:28 | |
TimToady | if there's a method version of them, in the package of their invocant, first of all | 02:29 | |
additional aliases are gravy | |||
dukeleto | TimToady: there is a method version and a non-method version of roots | ||
TimToady | what is the invocant of the method version? | 02:30 | |
dukeleto | TimToady: Complex or Num or Int | ||
TimToady | if defined in their respective classes, and then exported to CORE, is there any reason they can't multi dispatch based on the same type? | 02:31 | |
and the Any version of it can decide how to coerce and call one of the others, if it wants to be a function that will coerce its first arg from, say Str | 02:32 | ||
dukeleto | TimToady: i have single PIR function that works for Num and Int currently and is very close to working for Complex | ||
TimToady | we could probably arrange to be able to import methods from one class to another via use :has<> or some such | 02:33 | |
but for now I'd just say put it into one class or another and have the other call it | 02:34 | ||
or dup the code, we can refactor later | |||
but if someone calls Num::foo() it'd be nice to actually have something there, and not just shadowed in another class, I suppose | 02:35 | ||
but whatever | |||
if the interfaces are right, we can factor out commonalites later | 02:36 | ||
and presumably we can even do some tailcalls for delegation; I think parrot supports those... | |||
could be wrong... | 02:37 | ||
dukeleto | TimToady: currently S32 does not mention that roots() works on Complex numbers, do you have any comments on that? | ||
TimToady | I try to stay out of mathematical debates :) | ||
I are a lingrist | |||
family & | 02:38 | ||
meppl | good night | ||
dukeleto | wasn't trying to debate so much as clarify | 02:39 | |
02:40
meppl left
|
|||
lichtkind_ | what is \q in p6? | 02:41 | |
02:41
lichtkind_ is now known as lichtkind
02:45
cspencer_ left
|
|||
skids | \q in an interpolated string allows nesting of general quote operators | 02:46 | |
www.perlfoundation.org/perl6/index....ch_littleq | |||
pugs_svn | r25972 | hinrik++ | [util/perl6.vim] remove int routine, add iterator routine, highlight PIR code in Q:PIR// strings | 02:47 | |
frooh | rakudo: "\q"frew"" | ||
p6eval | rakudo 1c263b: OUTPUTĀ«Statement not terminated properly at line 1, near "frew\"\""ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤Ā» | ||
skids | Not sure if it's implemented yet. | 02:48 | |
frooh | I'd assume it isn't :-) | ||
skids | rakudo: "\q'frew'" | ||
p6eval | rakudo 1c263b: RESULTĀ«"q'frew'"Ā» | ||
skids | rakudo: qq(\q(frew)) | 02:49 | |
p6eval | rakudo 1c263b: OUTPUTĀ«Syntax error at line 1, near ")"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤Ā» | ||
pugs_svn | r25973 | hinrik++ | [util/perl6.vim] only catch block labels when there's nothing but whitespace or a newline before it, so as not to catch invocant markers as well | 02:55 | |
02:56
Kisu left
|
|||
msmatsko | I'm trying to build rakudo on cygwin under Vista-64 and get a link error for perl6_group.dll: undefined references to '__imp__Parrot_str_new_constant' among others. The g++ path seems to be set to the right place. Does anyone have any experience with this? | 02:58 | |
02:59
kimtaro joined
03:02
frooh is now known as frooh_away
03:05
nbrown04 joined
03:06
nbrown04 left
03:08
Kisu joined
|
|||
lichtkind | skids: thanks a lot | 03:19 | |
03:28
disismt left
03:33
FurnaceBoy left
04:19
tarbo2 left
04:34
tarbo2 joined
04:40
orafu left
04:41
orafu joined
05:01
msmatsko left
05:02
msmatsko joined
05:42
japhb left
05:44
japhb joined
05:51
amoc joined
05:56
kate21de joined
06:05
r0bby_ is now known as r0bby
06:09
msmatsko left
|
|||
pasteling | "szabgab" at 192.117.127.193 pasted "cannot build rakudo" (10 lines, 477B) at sial.org/pbot/35656 | 06:21 | |
dukeleto | I got roots() of complex numbers work, yay | 06:23 | |
s/work/working/ | |||
szabgab | sirry, after make realclean I could build it | ||
sorry too | |||
06:38
parduncia joined
|
|||
pugs_svn | r25974 | leto++ | Tests for cube roots() | 06:40 | |
szabgab | jnthn, bug report with Segmentation fault from yesterday night sent to rakudobug | 06:57 | |
07:01
Kisu left
07:15
ejs joined
07:24
nihiliad left
07:25
ejs1 joined,
nihiliad joined
07:26
nihiliad left
|
|||
moritz_ | good morning | 07:29 | |
rakudo: my @a = 1, 2; say @a.pairs.perl | 07:30 | ||
p6eval | rakudo 1c263b: OUTPUTĀ«[0 => 1, 1 => 2]ā¤Ā» | ||
07:31
mberends joined
07:32
ejs left,
DemoFreak joined
|
|||
dukeleto | moritz: mornin' | 07:33 | |
moritz; i have my roots() working nicely for everything I can throw at it | 07:34 | ||
moritz_ | dukeleto: did you modify it to make the method do all the work? | 07:36 | |
07:36
disismt joined
|
|||
pugs_svn | r25975 | lwall++ | [STD] handle .caps on list assoc; nibble text is now match object | 07:38 | |
r25975 | lwall++ | [Cursor] add keys into .caps pairs | |||
dukeleto | moritz: what exactly do you mean by that? I deleted one of the multi subs that I had before, now one multisub in math.pir does all the work, with a wrapper in any-num.pir that calls out to roots(x,n) to make x.roots(n) work | ||
moritz_ | dukeleto: all the other builtins are just done the other way round: for example $s.split($delim) does all the work, split($delim, $s) calls this method - I would prefer it if it worked the same way for roots | 07:40 | |
dukeleto | moritz: that seems doable | 07:41 | |
moritz: i have mostly been squashing bugs, adding docs and tests | 07:43 | ||
moritz: but it seems pretty solid now, so I will convert it so that roots(x,n) calls x.roots(n) | 07:44 | ||
moritz_ | dukeleto: great | ||
dukeleto: I might not have time for a thorough review today, but I should be able to do it tomorrow | |||
dukeleto | moritz: currently all 40 tests in roots.t are passing | ||
moritz: no prob, I don't know how long it will take me to convert the calling method, but hopefully not long | 07:45 | ||
moritz_ | dukeleto: ok, just ping me when you're done | ||
dukeleto | moritz: sounds good | ||
pugs_svn | r25976 | leto++ | Tests for cube roots() of negative numbers | 07:58 | |
moritz_ | can anybody reach rt.perl.org? | 08:05 | |
rakudo: class Match is also { method t { say %(self).pairs.[0].value.WHAT; } }; "a" ~~ /<xdigit>/; $/.t; say $<xdigit>.WHAT | 08:06 | ||
p6eval | rakudo 1c263b: OUTPUTĀ«Strā¤Matchā¤Ā» | ||
moritz_ | rakudo: class Match is also { method t { say %(self).{"xdigit"}.WHAT; } }; "a" ~~ /<xdigit>/; $/.t; | 08:10 | |
p6eval | rakudo 1c263b: OUTPUTĀ«Matchā¤Ā» | ||
08:15
disismt left,
disismt joined
|
|||
mberends | rt.perl.org (netlabs.develooper.com (63.251.223.170)) and www.nntp.perl.org (63.251.223.163) seem to be down | 08:22 | |
08:27
bacek_ left
08:40
cognominal left
08:46
disismt left
08:47
DemoFreak left
08:48
alc left
08:53
masak joined,
disismt joined,
disismt left,
disismt joined
08:56
pmurias joined
|
|||
mberends | jnthn++ # excellent slides www.jnthn.net/articles.shtml | 09:01 | |
pugs_svn | r25977 | leto++ | Fix typo in roots() test descriptions | ||
09:09
Caelum is now known as Caelum[Shootme]
09:10
broquaint joined
09:14
araujo left
|
|||
masak | trapping signals in Perl 6? how, where, when? | 09:31 | |
oh, and good morning, people. | |||
here's how Ruby does it. looks OK to me. gist.github.com/83484 | 09:32 | ||
mberends | gm masak, that was IPC in p5, so probably NYI | ||
masak | mhm | 09:33 | |
mberends | those progress dots, huh? | ||
09:33
ejs2 joined
|
|||
masak | mberends: yes -- you want them? :) | 09:33 | |
mberends | can live without. it's eye candy. | ||
masak | I'm sitting in a local branch called 'dogfood' in proto as we speak. | 09:34 | |
mberends | ...although free candy is welcome | ||
masak | will add private github repo download, so I can start using proto myself in my everyday work. | ||
I don't think the progress dots are such a hard problem, so I might throw them in while I have the momentum. | |||
mberends: did you see viklund++'s cleanup of the Perl 5 bootstrapper? | 09:35 | ||
mberends | masak: yes, it was an almost total rewrite | ||
masak | aye. | ||
mberends | p2t1a :) | ||
masak | indeed. :) | 09:36 | |
mberends is preparing 2 throw Pod::Parser v1 away... | |||
masak | why? | ||
mberends | that {*} appeals to me | 09:37 | |
and the scalability results were disappointing | |||
09:38
Caelum[Shootme] is now known as Caelum
|
|||
moritz_ | aye, {*} rocks | 09:38 | |
mberends | and Matt-W++ showed an excellent architecture in form | ||
masak | {*} is indeed appealing. as if Perl 6 wasn't good enough already at hiding complexity. :) | ||
mberends: oh? need to check it out again. | |||
moritz_ | but I'm regularly fighting small bugs in Match objects | ||
masak | moritz_: such as? | ||
mberends | moritz_, you're doing great stuff with Match objects | 09:39 | |
moritz_ | masak: for example %($/).pairs and .kv stringify the values | ||
masak | I must say that being part of a language community that's just forming is one of the best things that has happened to me as a programmer. | ||
literal | I'm curious. What does {*} do? | ||
masak | moritz_: is there a rakudobug for that? | ||
moritz_ | masak: and und some condition there's a Null PMC access in get_bool when doing 'if %(sefl)' | ||
masak: yes | 09:40 | ||
masak | and the second one too? :) | ||
moritz_ | literal: it tells the grammar engine to execute a method of the same name as rule from a supplied object | ||
masak: sure | |||
masak | moritz_: great. | ||
literal | ok | 09:41 | |
moritz_ | rakudo: grammar A { rule TOP { (\d+) '+' (\d+) } }; say A.parse('3 + 4') | ||
p6eval | rakudo 1c263b: OUTPUTĀ«3 + 4ā¤Ā» | ||
moritz_ | rakudo: grammar A { rule TOP { (\d+) '+' (\d+) {*} } }; class B { method TOP($/) { make $/[0] + $/[0] } } say A.parse('3 + 4', :action(B.new)).ast | 09:42 | |
p6eval | rakudo 1c263b: OUTPUTĀ«Statement not terminated properly at line 1, near "say A.pars"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤Ā» | ||
09:42
ejs1 left
|
|||
moritz_ | rakudo: grammar A { rule TOP { (\d+) '+' (\d+) {*} } }; class B { method TOP($/) { make $/[0] + $/[0] } }; say A.parse('3 + 4', :action(B.new)).ast | 09:42 | |
p6eval | rakudo 1c263b: OUTPUTĀ«6ā¤Ā» | ||
moritz_ | literal: that's a nice example of what the reduction methods can do | 09:44 | |
literal: and part of a potential GSOC project would also be to extensively test that facilty (hint, hint :-) | |||
literal | heh | 09:45 | |
moritz_ | speaking of which, applications must be done by April 3rd, iirc | ||
literal | yeah | 09:46 | |
mberends | moritz_: does it only make sense to call make once in a .parse (in TOP)? when I tried several others, only the last make argument was returned. | 09:47 | |
moritz_ | mberends: I think it's specced that way... $/ has only one .ast, so there's nothing else it could do | 09:48 | |
mberends | that's ok then, my expectations were unsure | ||
moritz_ | but you can always make [@( $/.ast ), $new_value] | 09:49 | |
mberends needs a cuppa to ponder that one | 09:50 | ||
moritz_ | that's basically the same as $/.ast.push($new_value), but it should atually work :-) | ||
mberends | that's slightly more grokkable, but .ast is beyond by ken | 09:51 | |
*my | |||
moritz_ | .ast is the same as $(), ie the payload that you put onto the Match object by calling make | 09:52 | |
mberends | .oO( lightbulb ) |
09:53 | |
09:56
amoc left
09:57
ejs1 joined
10:04
ejs2 left
|
|||
masak | mberends: I'm looking at www.webrick.org/ -- do you think that a HTTP server in Perl 6 would be of use? | 10:12 | |
10:14
araujo joined
|
|||
jnthn | morning all | 10:15 | |
masak | jnthn: morning! | ||
mberends | masak: been there, done that autoexec.demon.nl:8888/ | ||
masak | mberends: oh, so HTTP::Demon already is such a server? | 10:16 | |
mberends | yep | ||
for Druid too | |||
masak rushes to read source | |||
mberends | just needs netcat -> socat swap for BSD | 10:17 | |
masak tries | 10:18 | ||
mberends: I think I'll try and plug some Web.pm things I'm writing into HTTP::Server during the day. | 10:19 | ||
this is exactly what I need. | |||
mberends++ | |||
10:20
kate21de left
|
|||
masak | mberends: 'make help' doesn't contain the target 'podserver'. | 10:21 | |
mberends | oops :) | 10:22 | |
masak | mberends: wouldn't you know, the server works on the first attempt! | ||
it's slow, but it works. | 10:23 | ||
mberends | \o/ | ||
10:23
bacek joined
|
|||
jnthn | Rakudo can haz web server?! :-) | 10:23 | |
You folks scare me. :-) | 10:24 | ||
masak | I hope to have a lobster ready by this afternoon. | ||
github.com/chneukirchen/rack/blob/m...lobster.rb | |||
mberends: I'll probably have to copy HTTP::Server to the web repo, creating a temporary duplication. | 10:31 | ||
mberends | cool | ||
masak | it's not a good long-term solution, but might be worth it to create a nice working example without an inter-project req. | 10:32 | |
s/req/dependency/ | |||
mberends | fine | ||
masak is glad he introduced the LICENSE file in the root of the perl6-examples repo :) | |||
mberends: I've been thinking of ways to introduce pseudoprojects in proto to handle the different projects residing in perl6-examples. | 10:34 | ||
mberends | copy -r /projects/lib ;) | ||
masak | -bash: syntax error near unexpected token `)' | 10:35 | |
mberends: it might be possible to find a solution that doesn't depend on copying things. part of the "problem" is that the modules in perl6-examples are highly interdependent. | 10:36 | ||
in anthropomorphic terms, they like to live together. | 10:37 | ||
mberends | the perl6-examples/lib is a mini PERL6LIB of the future | 10:38 | |
masak | aye. | ||
10:38
disismt left
10:39
disismt joined
|
|||
masak | ooh, things have indeed changed in Form since I last looked at it. | 10:40 | |
Matt-W++ | |||
mberends | aye | ||
10:42
pmurias left
10:50
cognominal joined,
cognominal left
10:51
cognominal joined
10:55
jyy left
10:56
frooh_away left,
[particle]2 left,
rgs left,
PerlJam left,
plu_ left,
Woody4286 left,
bacek left,
japhb left,
buu left,
TimToady left,
frioux left
10:57
TimToady joined,
bacek joined,
japhb joined,
buu joined,
frooh_away joined,
Woody4286 joined,
[particle]2 joined,
rgs joined,
PerlJam joined,
frioux joined,
plu_ joined,
ingy joined,
charsbar joined,
miloux joined,
cotto joined,
irc.freenode.net sets mode: +o TimToady
11:00
amoc joined
|
|||
masak | lunch & | 11:04 | |
mikehh | rakudo (1c263b0) builds on parrot r37846 - make test PASS, make spectest FAIL 1/327 test programs. 1/9577 subtests failed. - t/spec/S05-capture/caps.t - failed test 6 | 11:10 | |
11:42
ruoso joined
|
|||
ruoso | Hello! | 11:44 | |
lambdabot | ruoso: You have 1 new message. '/msg lambdabot @messages' to read it. | ||
11:49
disismt left,
disismt joined
11:51
Grrrr left
|
|||
ruoso | @tell skids the changes you sent are mostly ok, but ideally the item iterator returns one item at a time, not one capture at a time, which implies that if a capture contains more than one item, it will be stored and each of its values is consumed one by one. As well as doing additional calls if an empty capture is returned... At least that was my original intent | 11:51 | |
lambdabot | Consider it noted. | ||
11:51
Grrrr joined
|
|||
Matt-W gets a big grin on his face | 11:52 | ||
11:53
Caelum left,
Caelum joined,
orevdiabl joined
11:54
SamB left
|
|||
ruoso | @tell skids but maybe I'm wrong and no flattening should be done in contexts other than list... | 11:54 | |
lambdabot | Consider it noted. | ||
ruoso | masak, I'd suggest leaving a Perl 6 HTTP::Daemon as a different project... most people don't mind using apache... | 11:57 | |
12:00
SamB joined
|
|||
mberends | Matt-W: is the hubris getting to you? we do eventually want running code ;) | 12:13 | |
Matt-W | it's hard to be overproud about code when the compiler keeps throwing new ways to break it at you | ||
12:14
bacek left
12:15
bacek joined
|
|||
mberends | nm, I like the way you've structured you project. I'm taking memes into Pod::Parser. | 12:16 | |
*your | 12:17 | ||
Matt-W | it's thrown up a few bugs in rakudo :) | ||
still not sure why my fourth test file won't work | 12:18 | ||
sometihng to do with instantiating objects of classes made with roles in multilayer namespaces or something | |||
I intend to do a test case later | |||
mberends | how about just pushing it and let me pull and also look. the user base can tolerate some downtime. | 12:20 | |
Matt-W | it's already up there | ||
just pull it and make test | 12:21 | ||
I know 03 fails, that's algorithmic | |||
04 looks like rakudo though | |||
mberends | ok, it may then be pulled already. I did see fails late last night as you signed off. | ||
Matt-W | I pushed it because it was preferable to the infinite loop that was there before :) | 12:22 | |
mberends | indeed, did that one here too :) | 12:23 | |
masak | ruoso: well, considering that the code is already written... | ||
Matt-W | I'm currently operating no rules about code pushed in form requiring to work :) | ||
masak | ruoso: I think there's certainly a use case for running your web stuff without Apache as a dependency. | 12:24 | |
Matt-W | rails shows that having an easy way to start up a project in a web server is really nice | ||
just... let's not have the bit where it's really hard to get a rails project running in apache :) | |||
masak | agreed. | 12:25 | |
Rack does this wonderfully, it seems. | |||
it has some kind of "middleware" adapters. | |||
and all of them work with the same interface. | |||
Matt-W | cool | 12:26 | |
masak | yes; it's a bit funny that I discovered Rack after specifying Web.pm -- they share many things, from goals to specific design points | 12:27 | |
Matt-W | great minds thinking alike? | ||
masak | must be. :P | 12:28 | |
mberends | Matt-W: suggest commenting out all failing tests and looking at them one at a time (in any order) | ||
masak | but there are also plenty of things that Rack does which I never thought about. that's ok, they're still stealable. | ||
RT down. :/ | 12:29 | ||
did I overload it yesterday, perhaps? :P | 12:30 | ||
jnthn | masak: Yeah, too many tickets. :-P | ||
masak | I;d say sorry, but I'm not. :P | ||
mberends | perhaps a network outage, other hosts also affected | ||
12:32
kimtaro_ joined
|
|||
Matt-W | mberends: yeah I will | 12:32 | |
mberends: I'm only worried about the apparent lack of ability to construct a TextField in 04 | |||
moritz_ | log.perl.org/2009/03/downtime-move-...g-now.html | ||
masak | moritz_: ahoj! | ||
12:33
kimtaro_ left
|
|||
moritz_ | hi masak :-) | 12:33 | |
12:34
unobe left
|
|||
masak | moritz_: weekend good? | 12:35 | |
moritz_ | masak: weekend good, but ended with $girlfriend sick :/ | ||
masak | :/ | 12:36 | |
12:36
pmurias joined
|
|||
pmurias | ruoso: hi | 12:36 | |
mberends | Matt-W: is this blocking you? 'Could not find non-existent sub left' | 12:39 | |
ruoso | hi pmurias | ||
Matt-W | mberends: where did you get that from? | ||
mberends | bypass 'prove' and run 'perl6 t/04yada.t' | 12:40 | |
masak | jnthn, moritz_: I'm still slightly unsatisfied with the way Parrot won't reveal byte information of strings. it feels silly to have to recreate this information on the Rakudo level. but if there's no other short-term solution, that's what I'll implement in Rakudo for now. | ||
pmurias | ruoso: do you think doing OO and multis would be appropriate for GSoC? | 12:41 | |
moritz_ | masak: did you send a mail to parrot-dev asking for help? | ||
masak: that might be worth a try | |||
masak | moritz_: good idea. | ||
ruoso | pmurias, what do you mean by OO? | ||
masak | I'll start with that. | ||
ruoso | pmurias, ah... OO in mildew | ||
pmurias | yes | 12:42 | |
ruoso | pmurias, yes... I think so... | ||
moritz_ | oh, rt status improved... before it was unreachable, now I get a ssh connection and "bad gateway" | ||
mberends | Matt-W: the 'left' identifier never occurs standalone, always before an underscore. maybe try camelCase instead of underscores. | ||
12:43
FurnaceBoy joined
12:44
kimtaro left
|
|||
pmurias | ruoso: "implementing S12 in smop" seems a neat way to sum up what i intend to do | 12:44 | |
moritz_ | pmurias: remeber that the meta-object stuff you're doing is quite far off from what the average programmer already knows... | 12:46 | |
ruoso | pmurias, yes... but that's a bit ambitious | ||
moritz_ | so it might not be ideal for a student | ||
ruoso | pmurias, try to be a bit more specific on what you plan to do... | 12:47 | |
remember that it's a time-limited project | |||
moritz_, he is the student | |||
szabgab | anyone read the blog entry about embedding Perl 6 into Perl 5 ? szabgab.com/blog/2009/03/1237797959.html | 12:48 | |
where should I put the source code of that module and how should I call it? | |||
pmurias | on CPAN? | 12:49 | |
12:49
skids left
|
|||
szabgab | I mean vcs | 12:49 | |
moritz_ | szabgab: github, if you are happy with git | ||
szabgab | and I wonder if it should be just any version control | ||
moritz_ | or pugs svn, if you prefer svn | ||
szabgab | I am new to git but that could be ok | 12:50 | |
and what name to use ? Inline::Rakudo ? | |||
moritz_ | From Inline::* modules I expect a similar interface as Inline::C | 12:51 | |
mberends | szabgab: Nicely written. I had watched the conversation in #perl6. | ||
moritz_ | but maybe I'm a bit off here | ||
12:51
disismt left
|
|||
szabgab | moritz_, that's why I am not really happy with the name | 12:52 | |
12:52
disismt joined
|
|||
szabgab | thought probably I should be unhappy with the API | 12:52 | |
mberends | szabgab: github names do not support punctuation or uppercase letters | ||
moritz_ | szabgab: maybe Rakudo::Inline? | ||
szabgab | so on github I can just call it perl6_in_perl5 | ||
12:53
kane_ joined
|
|||
mberends | even the underscore might be on thin ice, and that's risky in Israel. | 12:53 | |
szabgab | and the real package name can be decided once and if the code is actually useful | ||
mberends | true | 12:54 | |
masak | szabgab: or use dashes; that's nicer :) | ||
Matt-W | mberends: I see nothing about not being able to find a nonexistent sub | 12:56 | |
masak | Matt-W: have you committed and pushed everything? | ||
Matt-W | ah I just rebuilt from scratch | 12:57 | |
now I see it | |||
the disadvantage of precompiling modules | |||
mberends | there's a utility called 'make' ;-) | ||
Matt-W | yeah it doesn't seem to be getting the dependencies right | 12:58 | |
I'll have to check my makefile.in | |||
duh | |||
bash bash bash | |||
stupid stupid stupid | |||
masak | Matt-W: I've learned to write 'make; perl t/testfile.t' as a reflex | ||
mberends | er, perl6 ? | ||
pmurias | ruoso: the GSoC proposal has to specify a list of task with a schedule? | ||
masak | mberends: ah, right. :) | ||
Matt-W: as a rule, build .pm files bottom-up according to the dep tree. | 12:59 | ||
Matt-W | mberends: right, now I'm back to "Null PMC access in invoke() | ||
" | |||
masak: yes I realise that :) | |||
masak | Matt-W: we should have a utility that builds Makefile.in for us :) | 13:00 | |
ruoso | pmurias, yes | ||
I think | |||
mberends | masak: who gets that job? | 13:01 | |
moritz_ | the one who asks | ||
masak | d'oh! | ||
Matt-W | masak does! | ||
go go go! | |||
masak | it's not that hard, really. | ||
assumind 'use' statements are at the top of the file. | 13:02 | ||
I'll see what I can throw together in five minutes :) | |||
Matt-W pushes to form | 13:03 | ||
now we have the fun part | |||
13:03
PZt joined
|
|||
mberends | I preferred the previous error message :) | 13:04 | |
Matt-W | yes so did I | 13:05 | |
the trick will be figuring out what circumstances trigger that and filing a bit | |||
bug* | |||
Matt-W goes to experiment | |||
doh | 13:07 | ||
again | |||
stupid stupid stupid | |||
oh maybe not | |||
that was a bug I hadn't triggered yet that I just fixed :) | |||
13:10
kimtaro joined
|
|||
Matt-W | interesting | 13:10 | |
the bug is to do with enums | |||
mberends | enums are a bit... incomplete | 13:11 | |
jnthn | Aye, enums need work. | 13:12 | |
moritz_ submitted a few enum tickets as well | |||
rakudo: say Bool::True.perl; say True.perl; | |||
jnthn | Basically they want a re-write. | ||
p6eval | rakudo 1c263b: OUTPUTĀ«Bool::Trueā¤.new()ā¤Ā» | ||
moritz_ | in the second case it picks up the method from Object | 13:13 | |
even though True and Bool::True should be aliases | |||
jnthn | Heh, and then there's the whole "is Bool really an enum" thing. ;-) | ||
moritz_ | and the "is an enum really a role as well" thing | 13:14 | |
Matt-W | and the whole 'why do I have to say Bool::True' thing | ||
masak | ta-daa! gist.github.com/83545 | ||
mberends | Matt-W: moritz_++ clarified earlier today that only one 'make' per .parse actually produces output. The makes in Actions will clobber each other as the nested matches unwind. Is that how you see it? | 13:15 | |
13:15
pmurias left
|
|||
Matt-W | mberends: yes | 13:15 | |
mberends | ok, looking elsewhere | ||
szabgab | jnthn hi | ||
Matt-W | it should be pulling the result from the previous make, doing something to it, then make()ing that | 13:16 | |
the bug is using an enum in another module somehow | |||
szabgab | yesterdays helpwas rally great! | ||
Matt-W | just trying to boil it down as much as possible | ||
szabgab | and I should type slower | ||
13:16
PerlJam left,
PerlJam joined
|
|||
Matt-W | right | 13:17 | |
do we have this bug already | |||
rakudo: module A { enum B<a b c>; }; my $e = A::B::b; | |||
szabgab | any idea why do I get an error t/01-simple...."load_bytecode" couldn't find file 'PCT.pbc' if I run my script from any other place than the parrot root directory ? | ||
p6eval | rakudo 1c263b: OUTPUTĀ«Null PMC access in invoke()ā¤current instr.: '_block21' pc 63 (EVAL_25:41)ā¤Ā» | ||
jnthn | szabgab: Glad yesterday helped. ;-) I suspect issue is Parrot is having...issues...locating PCT.pbc. I'm not sure where it's trying to look though. | 13:18 | |
Which would be interesting to know. | |||
Matt-W | oh do we have no RT at the moment | 13:19 | |
jnthn | I'm not sure if it's possible to specify extra places to look... | ||
szabgab | ok, I just called load_bytecode path/to/PCT.pbc | 13:21 | |
which then complained about another thing | |||
I am not sure it's a good idea to add them one by one | |||
mberends | Matt-W: move the enum out of the module for a slight loss of encapsulation but a working result. | 13:22 | |
Matt-W | mberends: multiple modules require the enum | 13:23 | |
putting it in any of them would be wrong | |||
other than the one it's in | |||
I could duplicate for the time being I suppose | 13:24 | ||
mberends | rakudobug now; refactor later | ||
masak | mberends++ | ||
mberends | running code wins every time ;) | 13:25 | |
Matt-W | pfft | ||
it wouldn't work at all if they didn't translate into numbers | |||
but I don't like thinking of them like that | 13:27 | ||
they're new unique values that don't translate into any other domain | |||
(in this context, anyway) | |||
mberends | and then there's reality | ||
Matt-W | it's overrated | ||
masak likes lines($file) | 13:28 | ||
Matt-W | does Rakudo understand $match_object.ast yet? | 13:29 | |
moritz_ | it does | ||
Matt-W | excellent | ||
I can tidy up a bit then | |||
I do prefer it to having to do $( $match_object ) | |||
moritz_ | it just proxies $( $/ ) for now, but that might change in future | ||
Matt-W | don't care :) | ||
moritz_ | :-) | 13:30 | |
Matt-W | that's what encapsulation is for | ||
I don't *have* to care | |||
moritz_ | aye | ||
Matt-W | all I know is that I get the result object | ||
in a way that makes a bit more sense | |||
moritz_ | I had to care at the time I implemented .ast | ||
Matt-W | well yes | ||
Matt-W ticks off one more passing test in form | 13:31 | ||
found another one that doesn't though | |||
boooooooo | |||
the result object seems to be a Str, not a TextField | 13:34 | ||
boooo | |||
ahah | 13:35 | ||
(half-finished new features)-- | 13:36 | ||
masak | do we have an equivalent of Ruby's String#ljust ? | 13:39 | |
gist.github.com/83548 | |||
mberends | just the job for Form | 13:41 | |
masak | :) | ||
Matt-W | okay, if I have a rule that's like /(a)*/ and I've got its match object, can I get a list of captured subpatterns? | ||
masak | mberends: I was hoping not to have to include another module to do this. | 13:42 | |
PerlJam | eval: sprintf(":%-20s:", "foo"); | ||
er ... do that right | |||
and that's it. | |||
masak | PerlJam: thanks. | ||
PerlJam | rakudo: printf(":%-20s:\n", "foo"); | ||
p6eval | rakudo 1c263b: OUTPUTĀ«:foo :ā¤Ā» | ||
Matt-W | masak: we will, when I write it for Form :) | ||
masak | rakudo: say sprintf("%-20s", "foo") | 13:43 | |
p6eval | rakudo 1c263b: OUTPUTĀ«foo ā¤Ā» | ||
Matt-W | and it'll be in Form::TextFormatting | ||
masak | Matt-W: cool. | ||
13:43
xinming left
|
|||
Matt-W | every time there's a gust of wind, the lamppost outside the window wobbles in a most alarming manner | 13:43 | |
13:43
riffraff joined
|
|||
jnthn | Matt-W: Forthcoming lamppost fail? :-) | 13:44 | |
Matt-W | jnthn: I hope not, it's in a good position to break a great deal of my landlord's glass | ||
Matt-W consults S05 | 13:45 | ||
13:45
xinming joined
13:46
skids joined
|
|||
amoc | is it right that Perl6 is based on MetaObjectProtocol ? | 13:49 | |
moritz_ | it is | 13:50 | |
PerlJam | only time will tell if it's right or not ;-) | ||
masak | we're also based heavily on operators. | ||
amoc inserts perl6 link at see also entry in Metaobject wiki page.. | 13:51 | ||
masak | is there a method form of .() ? | 13:52 | |
ruoso | masak, postcircumfix:<( )>($capture) | 13:53 | |
jnthn | Matt-W: Would make a create failblog entry though. ;-) | ||
s/create/great/ | |||
jnthn can't type anything right today | |||
ruoso | masak, but supposedly, .() is a multi that happens to call that method at some point in the default implementation | ||
Matt-W | maybe by somebody who didn't live in the house it crushes :) | ||
PerlJam | jnthn: step away from the rakudo then! ;-) | ||
masak | ruoso: I'm asking, because Ruby's Rack ducktypes on .call methods, making it possible to supply a Rack application with a closure. | 13:55 | |
jnthn | PerlJam: I comitted nothing today. :-P | ||
ruoso | masak, but you can simply say $foo.() | 13:56 | |
and it will consider $foo to be a callable | |||
masak | ruoso: yes, sure. but I meant on the callee side. | 13:57 | |
ruoso: in Ruby, one simply defines a 'call' method. | |||
ruoso | ah... | ||
you define postcircumfix:<( )>($capture) | |||
it's in Ssomething | |||
moritz_ | so $x.foo calls $x.call('foo') ? | ||
masak | yeah. | ||
ruoso | ah... | ||
in that case it's a bit more complex | 13:58 | ||
moritz_ | masak: rakudo implements 'handles' | ||
ruoso | since that's made through HOW | ||
bacek | good night | ||
masak | ruoso: do you agree that postcircumfix:<( )> is slightly less pretty than 'call'? | ||
ruoso | masak, it's not the same thing... | ||
masak | moritz_: I don't see how that helps me. | ||
PerlJam | perl6 has call() too, doesn't it? Or am I conflating memories ? | ||
ruoso | masak, postcircumfix:<( )> is the API of callable | ||
bacek reading parrot's documentation on localhost:1234 using httpd.pir | |||
masak | ruoso: well, so is 'call' for Ruby lambdas. | 13:59 | |
bacek | localhost:1234 of casue :) | ||
ruoso | masak, what you want is $foo.dispatch('foo', $catpure); | ||
masak, er... that's not what moritz_ pointed and you agreed | |||
masak | buubot: spack \bdispatch\b | ||
buubot | masak: S02-bits.pod:5 S03-operators.pod:22 S04-control.pod:1 S05-regex.pod:4 S06-routines.pod:16 S09-data.pod:1 S12-objects.pod:35 S13-overloading.pod:7 | ||
moritz_ | masak: it allows you for example to turn all calls of the form $x.is_something into calls to $x.attrib.your_method() | ||
Matt-W | gargh | ||
masak is 100% confused now | 14:00 | ||
jnthn | bacek: You got Parrot sockes working?! | ||
*sockets | |||
Matt-W | everything is fine until I get to the action method for TOP, which is suddenly only seeing strings as match objects from the subpattern | ||
nnnnrgh | |||
bacek | jnthn: unix version | ||
jnthn | bacek++ | ||
moritz_ | Matt-W: there's a bug that .kv and .pairs stringify matches... | ||
Matt-W | moritz_: not using those | ||
bacek | jnthn: It took little bit more than I expected... | 14:01 | |
ruoso | masak, sorry... $foo.^dispatch('method', $capture) | ||
but in that case $foo is a regular object that implements 'method'\ | |||
moritz_ | Matt-W: and that usually also occurs when you forgot to add {*} to the subrules that TOP calls | ||
masak | ruoso: I think we're talking across purposes. | ||
Matt-W | moritz_: they're there, I can see the action methods being called | ||
moritz_ | Matt-W: if it's neither of those, file a bug report once RT is back up | ||
masak | ruoso: I'm not looking to do dispatch. | ||
ruoso | masak, what are you looking for? | 14:02 | |
Matt-W | moritz_: I haven't yet convinced myself I'm doing this right | ||
masak | ruoso: I'm looking to emulate Ruby's ducktyping on the 'call' method for objects sent into Rack. | ||
ruoso: where the nice thing is that lambdas (Rubese for 'closures') already have such a method. | 14:03 | ||
ruoso | I don't really see what you mean... | ||
ruoso going to look what "call" does in Ruby | |||
masak | ruoso: given a closure, it invokes that closure. | ||
ruoso | masak, thats .() | 14:04 | |
moritz_ | ruoso: if you find a nice explanation let me know | ||
masak | ruoso: aye. | ||
moritz_ | so what's the problem now? | ||
ruoso | masak, $foo.() assumes $foo is Callable | ||
jnthn | masak: If the closure is in $foo, just $foo() would call it | ||
ruoso | Callable defines method postcircumfix:<( )>($capture) | ||
masak | ruoso: so my conclusion is that doing the equivalent of defining 'call' in Perl 6 is slightly less elegant than in Ruby. | ||
ruoso likes the extra dot ;) | 14:05 | ||
masak, I don't get it... how is ".()" less elegant than ".call()" | |||
masak | ruoso: it's not, on the caller side. | ||
14:05
alester joined
|
|||
moritz_ | I think what masak wants to do is turning an object into something callable | 14:05 | |
masak | moritz_: more or less. | ||
ruoso | you just need to implement Callable | ||
what's wrong about that? | |||
moritz_ | masak: what's the "less" part? | ||
masak | moritz_: well, for one postcircumfix:<( )>() is longer than call() | 14:06 | |
14:06
parduncia_ joined
|
|||
masak | moritz_: I'd also guess that it's harder to remember. | 14:06 | |
14:06
parduncia_ left
|
|||
moritz_ | aye | 14:07 | |
masak | oh well. | ||
ruoso | masak, the syntatical category of the ops is already used by a lot of objects... | ||
Positionals need to implement postcircumfix:<[ ]> | 14:08 | ||
and so on | |||
masak | ruoso: I'm not proposing we change anything :) | ||
ruoso: I'm just designing Web.pm out loud. | |||
ruoso | masak, alright then ;) | 14:09 | |
masak | rakudo: class A { method postcircumfix:<( )>() {} } | 14:11 | |
p6eval | rakudo 1c263b: OUTPUTĀ«Malformed method definition at line 1, near "postcircum"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤Ā» | ||
14:11
nihiliad joined
|
|||
moritz_ | treating things as callable is a cool idea, because it means you don't have to come up with a standardized method name :-) | 14:11 | |
[particle] | rakudo doesn't understand foo:<bar> syntax yet | 14:12 | |
masak | moritz_: another cool idea stolen from Rack. :) | ||
[particle]: I suspected that. | |||
ruoso | masak, remember it is important that the action processing takes at least two different stages... | 14:13 | |
execute happens from least specific to most specific | 14:14 | ||
end happens from most specific to least specific | |||
(that assuming chains....) | |||
masak | ruoso: I'm not the guy with that abstraction level. | 14:15 | |
ruoso: I'm doing requests and responses. | |||
ruoso | ah... ok... | ||
Matt-W pushes form: all current parsing tests now work | |||
14:16
ZuLuuuuuu joined
|
|||
masak | Matt-W++ | 14:16 | |
Matt-W | finally figured out what was going on | ||
Might try and write it up right now, actually | |||
masak | Matt-W: do it! | ||
14:18
Exodist joined
14:21
zamolxes joined
14:24
parduncia left
|
|||
pmichaud | good morning #perl6 | 14:28 | |
masak | oh hai pmichaud | ||
moritz_ | hi there | ||
PerlJam | morning pm | ||
14:29
xinming_ joined
|
|||
jnthn | morning pmichaud | 14:30 | |
14:33
ejs1 left
14:35
disismt left
14:36
disismt joined
14:39
hercynium joined
14:41
xinming left
|
|||
moritz_ | pmichaud: currently .kv and .pairs on Match objects stringify their values... could you take a look at it sometimes soon? things I'm working on in Match.chunks etc. are blocking on it | 14:48 | |
I could also use some very ugly workarounds... | |||
14:49
ruoso left
|
|||
pmichaud | moritz_: yes, I can take a look at it very soon. Much of Match is set to be refactored soon anyway. | 14:50 | |
e.g., to set up .ast and eliminate .item and the like. | |||
masak | and .text | 14:52 | |
moritz_ | pmichaud: great | ||
jnthn | pmichaud: Planning a Rakudo day this week. Thu is not so good (Slovak class), Fri neither (flying in the evening), but tomorrow or Wed would work for me. How about you? | 14:53 | |
pmichaud | either tomorrow or Wed should be fine. Wed _might_ be a little better because I'm finding there's a lot of other things I'm having to catch up on. | 14:54 | |
jnthn | (I've got a huge task list of stuff if you're not going to be about anyway...) | ||
Ah, Ok. | |||
OK, Wed it is. | |||
pmichaud | I should be about all week. | ||
jnthn | I'm away weekend + Monday. | ||
pmichaud | but I might have to work on non-Parrot/Rakudo stuff while I'm here. | ||
jnthn | (Mostly or entirely offline away) | 14:55 | |
pmichaud | for example, right now I have to take my car back into the shop to find out why the wheels are making a funny noise. | ||
jnthn | :-S | ||
pmichaud | also have to get our taxes done this week :-| | 14:56 | |
jnthn | Ugh. | ||
jnthn got his out of the way in January. Then, his deadline was end of Jan... | 14:57 | ||
pmichaud | yes, this year is slightly challenging for taxes in many respects -- both Paula and I had significant events in 2008 | ||
jnthn | Yes. And from what I've heard, the US tax system is optimized for consuming people's time and providing potential to make mistakes... | 14:58 | |
Since the UK developed online filing, the whole thing became scarily efficient... | |||
Unfortunately, I've now left the UK. | 14:59 | ||
Well, unfortunate it that sense. | |||
Fortunate in others. :-) | |||
pmichaud | well, "potential to make mistakes" also leaves lots of room for tax evasi.... er, creative accounting. :-) | ||
14:59
Kisu joined
|
|||
jnthn | Tax *optmization*. ;-) | 14:59 | |
dotax -Otax_payable | 15:00 | ||
pmichaud | it's a time-honored tradition among many high-ranking government officials in the U.S. | ||
(or "wannabe high-ranking officials") | |||
jnthn | ;-) | ||
15:01
nihiliad left
15:02
ruoso joined
|
|||
pmichaud | okay, off to take my car back to the shop, visit the bank, the post office, etc. bbiah | 15:02 | |
TimToady | moritz_: I did clarify your .caps yesterday, but perl.org hasn't coughed up the email yet | 15:03 | |
ruoso | TimToady, I was backlogging and see you comment on @@ and slices... that reminded me of the idea of replacing '@@' by Ā¢, replacing "slice context" by "capture context"... do you think that change is going to happen? | 15:05 | |
TimToady | we could just make @@ the Texas form of Ā¢ | 15:06 | |
ruoso | right... but you do remember that the idea was to make it clear that it's not just about lists, right? | 15:07 | |
moritz_ | TimToady: I've seen it, thanks | ||
TimToady | I'm not big on clarity at this time of morning :) | ||
moritz_ | TimToady: at least I saw the commit | ||
TimToady | also a commit about top-level namespaces | ||
which should also imply some tests | 15:08 | ||
ruoso | TimToady, ok... I just wanted to bring it on again, so that doesn't hurt us too much in the future (as the last change in captures did ;) | ||
TimToady | UNIT::OUTER == SETTING, for instance | ||
moritz_ | when I have a regex like /[ (\d) \s*]+/, then $0 is List - can I assume that this will flatten? | ||
TimToady | ruoso: I can understand that :) | ||
moritz_ | so that $/.caps will have two pairs 0 => Match.new(...) when the bracket matched twice | ||
ruoso | moritz_, it should only flatten if you assign it to a list... | 15:09 | |
TimToady | moritz_: correct, there can be dup keys | ||
moritz_ | ruoso: the question is if $/.caps flatten it... which TimToady just answered :-) | ||
TimToady: ok, then I understood it correctly... will update the tests soon | |||
TimToady | and STD/Cursor has a prototype implementation of .caps, but of course the P5 version of it just pushes keys and values in alternation | 15:11 | |
ruoso | TimToady, is it sane to define as a general policy that flattening only happens in list assignment? | 15:12 | |
TimToady | assignment? | 15:13 | |
or context? | |||
15:13
PacoLinux joined
|
|||
ruoso | TimToady, I was thinking that maybe a bind to a list could keep it unflattened | 15:13 | |
my @a := foo(); | 15:14 | ||
so... | |||
my @a := (((1,2,3),2,3),2,3); say @a[0].per; #prints "((1,2,3),2,3)" | |||
TimToady | seems like map {...}, list foo() should flatten | ||
ruoso | ok... | 15:15 | |
point taken | |||
TimToady | course, map is already list context, but that's the point | ||
ruoso | it might be a bit tricky to get the above example to work | 15:16 | |
TimToady | but then what about slice map {...}, foo() | ||
ruoso | i.e. to amke it flatten... (I mean the example I wrote) | ||
TimToady, the signature of map causes the flattening... | |||
but I'm not sure how that works... | 15:17 | ||
maybe there's an explicit coercion going on before the bind | 15:19 | ||
TimToady | hmm, map seems more like a factory factory that takes a closure and a capture and generates a factory that generates a filter when it actually knows the whether its context is list/slice/eager/hyper whatever | 15:20 | |
or something like that... | 15:21 | ||
ruoso | hmm... I'm not sure it is map-specific | ||
my @a := (((1,2,3),2,3),2,3); | |||
15:22
gdonald joined
|
|||
ruoso | exposes the same issue | 15:22 | |
pugs: my @a := (((1,2,3),2,3),2,3); say @a.perl; | 15:23 | ||
p6eval | pugs: OUTPUTĀ«\(1, 2, 3, 2, 3)ā¤Ā» | ||
ruoso | pugs: my @@a := (((1,2,3),2,3),2,3); say @@a.perl; | ||
p6eval | pugs: OUTPUTĀ«\(1, 2, 3, 2, 3)ā¤Ā» | ||
ruoso | ok... pugs is not building the list lazily | ||
15:23
kane__ joined
|
|||
ruoso | er... unflattened, actually | 15:24 | |
TimToady | I sense that if we get too fancy here we'll turn into Haskell :) | ||
15:24
gdonald left
|
|||
ruoso | TimToady, right... but... do we have a choice? | 15:24 | |
I mean | |||
we support unflattened lists... | 15:25 | ||
that flatten automatically | |||
this is "too fancy" | |||
PerlJam | ruoso: my @a = flatten (((1,2,3),2,3),2,3); # :-) problem "solved" | 15:26 | |
masak | rakudo: my $a = "foobar"; $a ~~ /foo/; say $a.substr($/.to) # emulating $' | ||
p6eval | rakudo 1c263b: OUTPUTĀ«barā¤Ā» | ||
masak | Rakudo++ | ||
ruoso | PerlJam, while making the flattening explicit is completely unexpected... It's not that all a bad idea... | 15:27 | |
PerlJam | well, I don't know that I made it explicit really. I just changed one syntax for another. | 15:28 | |
ruoso | because in fact, all the "flattening" process is very much obscure yet... | 15:31 | |
15:31
kane___ joined
|
|||
ruoso | we all agree that @a = (((1,2,3),2,3),2,3); should result in (1,2,3,2,3,2,3) | 15:31 | |
but... | |||
PerlJam | yes. Perhaps it needs to be "louder" than happen en passant in certain contexts | 15:32 | |
ruoso | my @a = map { ($_,$_),$_) }, 1,2,3 | 15:33 | |
what defines the flattening... is it the use of "(" ")"? | |||
15:33
ejs joined
|
|||
ruoso | my @a = map { (($_,$_),$_) }, 1,2,3 | 15:34 | |
the line before that was wrong | |||
masak | in a 'when' expression, can I match against either of two regexes somehow? an or-junction, perhaps? | ||
ruoso | masak, yes... that's one of the primary uses for junctions... | 15:35 | |
TimToady | seems like binding a capture into @x causes the binding to happen to generator of @x, not the array container itself | ||
masak | rakudo: my $a = "foo"; given $a { when /foo/ | /bar/ { say "OH HAI" } } | ||
p6eval | rakudo 1c263b: OUTPUTĀ«OH HAIā¤Ā» | ||
masak | cool. | ||
TimToady | or looking at it the other way, when a capture finds itself being bound into a container of a certain type, it transforms itself into something suitable to be bound to that container | 15:36 | |
ruoso | the problem is that binding doesn't really touch the rvalue | ||
TimToady | which in the case of an array is an empty array fed by the flattened capture list | ||
ruoso | at least until now | ||
TimToady | doesn't have to, just provides a different iterator, I think | 15:37 | |
[particle] | so, captures are amorphous solids, they are not rigid, and given proper conditions, *eventually* take the shape of their containers. | ||
ruoso | that sounds weird | ||
TimToady | well, time travel is usually weird, but that's the whole point of captures | 15:38 | |
ruoso | the problem is that this works fine for assignemnt... but sounds strange for binding | ||
TimToady | they're an entanglement of arguments that don't collapse until observed | ||
PerlJam | masak: though, I don't see Junction explicitly mentioned in the smart match table in S03, so maybe that needs more documentation. | ||
TimToady | forget assignment, it's a second-order operation | 15:39 | |
masak | PerlJam: maybe it simply autothreads. | ||
[particle] | i'm trying to stay with classical mechanics here--you just can't resist going quantum :) | ||
TimToady | you of all people... | ||
masak | PerlJam: though I'm a bit uncerain what would happen in the face of several simultaneous matching regexes. | ||
15:39
kane_ left
|
|||
[particle] waves | 15:40 | ||
PerlJam | heh | ||
masak | TimToady: maybe he's both classical and quantum, depending on one's perspective. :) | ||
PerlJam | so ... a capture is a quantum of uncertainty? | ||
TimToady | well, we're emulating quantum with classical, of course, just as we are with junctions | ||
[particle] | i'm moving slowly this morning, like timtoady | ||
ruoso | hmm... | ||
masak | saving relativistic for the evening. | ||
TimToady | it's an entanglement that has not yet been observed | ||
ruoso | that means 1 of 2 things... | 15:41 | |
TimToady | context is the observation | ||
15:41
pmurias joined
|
|||
ruoso | 1) every value has the chance of modifying itself for a bind operation | 15:41 | |
2) the runtime checks to see if that's a capture, which might need to modify itself for a bind operation | |||
TimToady | more like | ||
1) capture has the chance to modify itself as soon as it knows the context | 15:42 | ||
2) binding is one way of providing context | |||
ruoso | right... right... but in order to "capture" to have a chance, we either make it an exception, or provide that to every object... | 15:43 | |
hmm... can we know syntatically when we're dealing with captures? | |||
TimToady | I believe so | 15:44 | |
though of course $x could contain one without knowing it | |||
[particle] | or an anonymous closure | 15:45 | |
TimToady | but that's the difference between \ and not \ | ||
ruoso | but it doesn't perform as a capture unless you de-reference it | ||
TimToady | right, so basically yes, wrt naked captures | ||
we've tried to keep that an invariant | |||
ruoso | ok... so the only way of getting a capture as-is is to use the capture sigil | 15:46 | |
or use the capturize opertor | |||
TimToady | or binding to an appropriate thingie | ||
ruoso | like? | 15:47 | |
TimToady | we currently have |$x and @@x which we're thinking how to unify | ||
possibly using Ā¢ | |||
15:48
kane__ left
|
|||
TimToady | e=mĀ¢Ā² | 15:48 | |
ruoso | so... "my $a := \foo()" is the same as "my Ā¢a = foo()" | 15:49 | |
actually | |||
"my $a = \foo()" is the same as "my Ā¢a = foo()" | |||
"foo(|$a)" is the same as "foo(Ā¢a)" | 15:50 | ||
TimToady | funny that Ā¢ can be taken to mean "no context" | ||
ruoso | yes... precisely... | ||
skids | ...or french \( | 15:51 | |
lambdabot | skids: You have 2 new messages. '/msg lambdabot @messages' to read them. | ||
[particle] | ahem. that's E, not e. | ||
TimToady | that would be precisement | ||
ruoso | my $a = \foo() is an explicit request to "enclose the capture in a scalar" | 15:52 | |
TimToady | sorry, git doesn't support uppercase | ||
ruoso | my Ā¢a = foo() is simply "don't do anything with the return of foo" | ||
TimToady | I can see some styles of programming where that turns into my a = foo(), but nevermind | 15:53 | |
[particle] | Ā¢grammar | ||
there's only one reasonable thing that variable can contain. | |||
TimToady | not C#? | 15:54 | |
[particle] | :) | ||
skids | But if it's also @@ that means it indexes, right, ōæ½xA2a[0]? In fact you have to index it? | 15:56 | |
TimToady | nature abhors a naked Ā¢ingularity, but that will confuse the phone people... | ||
ruoso | skids, the question is not if you index it or not... but if you flatten it or not... | ||
TimToady | which is to say [0] produces something different on the capture than on the flattened list | 15:57 | |
15:57
nihiliad joined
|
|||
TimToady | well, depending on whether the first positional is itself a capture... | 15:57 | |
[particle] | captures are as confusing as soap envelopes | ||
ruoso | captures are more unstable matter than junctions | 15:58 | |
Matt-W | All I've done with captures is rather akin to a Perl 5 reference - stopping a hash interpolating into a list | ||
15:58
meppl joined
|
|||
ruoso | Matt-W, except that it holds both positional and named... | 15:59 | |
ruoso .oO( that looks like a php array ;) | |||
TimToady | php confuses the two | ||
captures keep them separate | |||
Matt-W | yeah well I just did a very simple thing, I know they can do a whole load of weird stuff I don't understand yet | ||
TimToady | in Perl 5 terms, they let us defer the decision on the context of (@array,1,2,3) until we know whether we're calling push or say | 16:01 | |
masak | rakudo: 'class A { has %!env; method new(%env) { return A.bless({ env => %env }); }; method foo { return %!env<foo> } }; say A.new({ "foo" => "OH HAI"}).foo | 16:02 | |
p6eval | rakudo 1c263b: OUTPUTĀ«Syntax error at line 1, near "'class A {"ā¤ā¤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)ā¤Ā» | ||
masak | rakudo: class A { has %!env; method new(%env) { return A.bless({ env => %env }); }; method foo { return %!env<foo> } }; say A.new({ "foo" => "OH HAI"}).foo | ||
p6eval | rakudo 1c263b: OUTPUTĀ«Use of uninitialized valueā¤ā¤Ā» | ||
masak | what am I doing wrong? | ||
ruoso | masak, iirc, bless receives the candidate object as first argument... | ||
so it seems you're reblessing the hash as A | 16:03 | ||
masak | isn't that what I want? | ||
I took the syntax out of S12. | |||
skids | Anyway a question I sent ruoso yesterday still stands for @@a = (1,foo(),2;3,4,5); # given special capture meaning of @@, does @@a[0] call foo or only @@a[0;1]? | ||
masak | this is the first new method I try to write. | ||
ruoso | masak, that's actually a point I always forgot to ask for clarification... | 16:04 | |
masak | ok, so let's do it now. :) | ||
ruoso | masak, in SMOP that is implemented through the REPR api | ||
TimToady hides | |||
masak | :D | ||
ruoso | in my head, we need to add a special cast there... | ||
because as you can create an actual hash, | 16:05 | ||
Matt-W | Here we go: the results of the last couple of hours of writing, testing code and fighting Wordpress: alledora.co.uk/wordpress/archives/2009/03/23/377 <- some gushing over grammars and action methods, probably containing mistakes. | ||
masak | TimToady: come back! we need to ask you something. | ||
ruoso | masak, the usual way of doing it is bless(::p6opaque.^!CREATE()) -- if we assume the REPR API | 16:06 | |
[particle] brews a pot of coffee for timtoady | |||
TimToady | what .bless does may certainly be type dependent | ||
masak | TimToady: but in the above case...? | ||
ruoso | TimToady, hmm... if the candidate to bless is a hash... hmm.... | 16:08 | |
I'm not sure how that could be done without the REPR API | 16:10 | ||
but... | |||
TimToady | skids: .[0] of a slice is supposed to produce the list before the first ; | ||
ruoso | TimToady, but the call to foo() happens at accessing time? | 16:11 | |
masak | jnthn: is it possible to override 'new' in Rakudo today? | 16:12 | |
TimToady | no, functions are called when the capture is evaluated, but may return lazy lists themselves | ||
ruoso | with the REPR API, that hash could be enclosed into ::blessedHash, which implements the REPR API using the candidate hash as storage... | ||
ok that was what I expected... and the actual question skids asked ;) | |||
TimToady | $x = \(1,2,3,die "oops"); # dies before $x is assigned | ||
16:13
sri_kraih joined
|
|||
TimToady | I don't see how it could possible get [0;1] when the first slice starts with 1 | 16:13 | |
*possibly | |||
masak | jnthn: more precisely, if I want to override the 'new' method as I did above, how would I go about it? | 16:14 | |
TimToady | biab & | 16:15 | |
ruoso | masak, last time I checked, rakudo don't support representation polymorphism... and no plans on supporting it yet... | 16:16 | |
masak | ruoso: is that answer an answer to my question? :) | ||
ruoso | yes... | ||
masak | I was asking about the 'new' method. | ||
not about 'representation polymorphism'. | |||
ruoso | ah... sorry... I thought it was about your earlier question | ||
masak | which one? | 16:17 | |
jnthn | masak: (sorry, bit distracted on $other_thing atm) | ||
masak | jnthn: ok. | ||
jnthn | masak: I think new should be overridable | ||
ruoso | the A.bless({ env => %env }) questin | ||
jnthn | Yes, basing things on other representations we don't support just yet | ||
masak | ruoso: the 'bless' was just a means to an end; creating a 'new' method. | ||
jnthn: do you see what it is I want to do? | |||
(and that it doesn't work) | 16:18 | ||
jnthn | rakudo: class Foo { method new { say 42 } }; Foo.new | ||
p6eval | rakudo 1c263b: OUTPUTĀ«42ā¤Ā» | ||
ruoso | you need jnthn to expose p6object to Perl 6 | ||
(is that how it is called?) | |||
masak | jnthn: well, saying 42 is nice and all... | ||
jnthn: I'd like .new to return a new object. :P | |||
jnthn | Damm, awkward ain't you. :-P | ||
masak | aye. | ||
jnthn | masak: I think the answer involves create...can you give me some moments to finish up the other thing I'm working on, and I'll get back to you? | 16:19 | |
masak | jnthn: absolutely. | ||
jnthn | Thanks. | ||
masak | you make it sound as if I'm doing you the favour. :P | ||
16:21
FurnaceBoy is now known as FurnaceBoy|afk
|
|||
jnthn just found one comment written in English amongst a sea of Swedish comments in a file. | 16:21 | ||
The comment? | |||
'Do tha' stuff | |||
...useful... | |||
masak | åå | ||
those Swedes... | 16:22 | ||
jnthn sometimes wonders when reading some code if a brain isn't a pre-requisite for programming... | |||
Matt-W celebrates | 16:25 | ||
all Form tests now pass | |||
no, I didn't take any of them away to achieve that | |||
mberends | Matt-W++ # also for the gushing blog | ||
masak | Matt-W: time to write more tests! :) | ||
Matt-W | masak: no, time to make dinner, but in principle yes more tests | 16:26 | |
ruoso | Matt-W, btw, you don't need the gather/take to get lazyness in "for" | 16:27 | |
16:28
sri_kraih_ left
16:30
ejs left
|
|||
szabgab | is there a perl 5 module that can read/read perl 6 data structures (aka .perl stringifications) ? | 16:31 | |
mberends | szabgab: eval() | ||
szabgab | and I mean read/write of course | ||
hmm | |||
masak | szabgab: read: eval. write: .perl | 16:32 | |
szabgab | thta's the perl 6 side | ||
and on perl 5 side that would be Data::Dumper I guess | |||
and eval | |||
pmurias | v6.pm | ||
Matt-W | ruoso: I don't?? | ||
16:33
blongden joined
|
|||
ruoso | Matt-W, for is lazy | 16:33 | |
Matt-W | oooh | ||
okay | |||
still, gather/take is cool | |||
ruoso | Matt-W, you need to use "loop" if you really want imperative-style | ||
pmurias | szabgab: to read perl6 code you need a perl6 implementation | ||
Matt-W | ruoso: no thankyou :) | ||
szabgab | pmurias, I am only interested in data structues that perl5 can understand | 16:34 | |
BTW I put my code here: github.com/szabgab/perl6-in-perl5/tree/master | |||
ruoso | pmurias, btw... I realized the refactoring in smop is going to make it clearer on how to implement SMOPP5 | ||
SMOPP5 will just need to replace the "interpreter" module | 16:35 | ||
(in the smop side, that is) | |||
mberends | szabgab: language independent data structures would be YAML. Perl 5 libs are stable, Perl 6 ones are in development. | 16:36 | |
szabgab | yeah, that might be one way to pass parameters | 16:37 | |
pmurias | szabgab: if you are doing language interop stringifing stuff is not a good idea | 16:39 | |
16:39
blongden left
|
|||
pmurias | unless you are interfacing with tcl | 16:39 | |
szabgab | I am trying to allow calling perl 6 code running in rakudo from perl 5 | ||
pmurias | i guessed that ;) | 16:40 | |
you should wrap the pmc as a sv and the sv as pmcs | |||
jnthn | szabgab: I guess you'd need to transform the P5 variables into PMCs. | ||
I don't know a great deal of p5guts, though... | 16:41 | ||
ruoso | rakudo: say Object.CREATE; | ||
p6eval | rakudo 1c263b: OUTPUTĀ«Object<0xb609ce80>ā¤Ā» | ||
ruoso | masak, that's what you need | ||
:) | |||
masak | ruoso: ah. | ||
pmurias | szabgab: i did something similiar for smop as my uni C course task | ||
diakopter | it takes guts to learn guts | ||
ruoso | p5 guts is not that complicated... | 16:42 | |
szabgab | pmurias, for now the simple case of passing individual scalar works | ||
and it is not clear to me yet how should other things work | 16:43 | ||
ruoso | szabgab, the trick is implementing a P5V PMC | ||
*P5SV | |||
szabgab | what is that ? | ||
masak | ruoso: and if I want to CREATE the object with one attribute set? (as in my original one-liner) | ||
szabgab | ah an SV ? | 16:44 | |
don't know anything about those, but it works :-) | |||
ruoso | masak, then you need the REPR API | 16:45 | |
masak, but... | |||
masak | ah, a glimmer of hope! | ||
ruoso | BUILDALL accepts a set of protoobjects | ||
I don't know if that is implemented in rakudo | |||
masak | ruoso: maybe I can CREATE, and then use the accessors on the object? | 16:46 | |
that'd work for me. | |||
ruoso | rakudo: say Int.CREATE; | ||
p6eval | rakudo 1c263b: OUTPUTĀ«0ā¤Ā» | ||
ruoso | rakudo CREATE is a bit smarter than expected | ||
it doesn't simply create a storage of that representation... I don't think you even need to call bless.. | 16:47 | ||
masak | rakudo: class A { has %.env is rw }; my $a = A.CREATE; $a.env = { foo => 'bar' }; say $a.env<foo> | ||
ruoso | but that's not exactly the way it's specced | ||
p6eval | rakudo 1c263b: OUTPUTĀ«Null PMC access in getprop()ā¤current instr.: 'infix:=' pc 13848 (src/builtins/assign.pir:21)ā¤Ā» | ||
masak | wohoo! | ||
masak submits rakudobug | |||
rakudo: class A { has %.env is rw }; my $a = A.CREATE; $a.env = { foo => 'bar' }; | |||
p6eval | rakudo 1c263b: OUTPUTĀ«Null PMC access in getprop()ā¤current instr.: 'infix:=' pc 13848 (src/builtins/assign.pir:21)ā¤Ā» | ||
masak | rakudo: class A { has %.env is rw }; my $a = A.CREATE; | 16:48 | |
p6eval | rakudo 1c263b: RESULTĀ«A.new()Ā» | ||
masak | that assignment should work, right? | ||
ruoso | rakudo: class A { has %.env is rw }; my $a = A.CREATE; $a.BUILDALL(env => {foo => 'bar'}); | ||
pmurias | are there any TPF application guidelines/templates | ||
p6eval | rakudo 1c263b: OUTPUTĀ«too many named arguments - 'env' not expectedā¤current instr.: 'parrot;Perl6Object;BUILDALL' pc 1272 (src/classes/Object.pir:331)ā¤Ā» | ||
ruoso | rakudo: class A { has %.env is rw }; my $a = A.CREATE; $a.BUILDALL(A{ env => {foo => 'bar'}}); | ||
p6eval | rakudo 1c263b: OUTPUTĀ«too few arguments passed (2) - 4 params expectedā¤current instr.: 'parrot;Perl6Object;BUILDALL' pc 1272 (src/classes/Object.pir:331)ā¤Ā» | ||
ruoso | rakudo: class A { has %.env is rw }; my $a = A.CREATE; $a.BUILDALL((env => {foo => 'bar'})); | 16:49 | |
p6eval | rakudo 1c263b: OUTPUTĀ«too few arguments passed (2) - 4 params expectedā¤current instr.: 'parrot;Perl6Object;BUILDALL' pc 1272 (src/classes/Object.pir:331)ā¤Ā» | ||
ruoso | masak, you can submit that as a rakudobug also... | ||
ah wait... | |||
masak waits | |||
ruoso | rakudo: class A { has %.env is rw }; my $a = A.CREATE; A.BUILDALL($a, (env => {foo => 'bar'})); | ||
p6eval | rakudo 1c263b: OUTPUTĀ«too few arguments passed (3) - 4 params expectedā¤current instr.: 'parrot;Perl6Object;BUILDALL' pc 1272 (src/classes/Object.pir:331)ā¤Ā» | ||
ruoso | rakudo: say Object.BUILDALL.signature | 16:50 | |
p6eval | rakudo 1c263b: OUTPUTĀ«too few arguments passed (1) - 4 params expectedā¤current instr.: 'parrot;Perl6Object;BUILDALL' pc 1272 (src/classes/Object.pir:331)ā¤Ā» | ||
jnthn | rakudo: class A { has %.env is rw }; my $a = A.CREATE; A.BUILDALL(A, $a, (env => {foo => 'bar'})); | ||
ruoso | rakudo: say Object.^can('BUILDALL').signature | ||
p6eval | rakudo 1c263b: OUTPUTĀ«shift_pmc() not implemented in class 'Perl6Pair'ā¤current instr.: 'parrot;Perl6Object;BUILDALL' pc 1341 (src/classes/Object.pir:363)ā¤Ā» | ||
rakudo 1c263b: OUTPUTĀ«Method 'signature' not found for invocant of class 'Integer'ā¤current instr.: 'parrot;P6metaclass;dispatch' pc 637 (src/classes/ClassHOW.pir:161)ā¤Ā» | |||
16:51
Psyche^ joined
|
|||
ruoso | rakudo: class A { has %.env is rw }; my $a = A.CREATE; A.BUILDALL(A, $a, A{env => {foo => 'bar'}}); | 16:51 | |
p6eval | rakudo 1c263b: OUTPUTĀ«argument doesn't hashā¤current instr.: 'parrot;Perl6Object;BUILD' pc 1142 (src/classes/Object.pir:281)ā¤Ā» | ||
masak | that's a reported parrotbug, methinks. | ||
ruoso | jnthn, but why does BUILDALL receives A twice? | ||
jnthn | ruoso: I dunno. ;-) | 16:52 | |
ruoso: I haven't really looked at the object initialization stuff. | |||
ruoso | rakudo: class A { has %.env is rw }; my $a = A.CREATE; A.BUILDALL(A, $a, {env => {foo => 'bar'}}); | ||
p6eval | rakudo 1c263b: OUTPUTĀ«argument doesn't hashā¤current instr.: 'parrot;Perl6Object;BUILD' pc 1142 (src/classes/Object.pir:281)ā¤Ā» | ||
ruoso | interesting... | ||
jnthn | It's managing to call a BUILD and then blowing up. Hmm. | ||
rakudo: class A { has %.env is rw }; my $a = A.CREATE; my %h = env => { foo => 'bar' }; A.BUILDALL(A, $a, %h) | 16:53 | ||
p6eval | rakudo 1c263b: OUTPUTĀ«argument doesn't hashā¤current instr.: 'parrot;Perl6Object;BUILD' pc 1142 (src/classes/Object.pir:281)ā¤Ā» | ||
jnthn | rakudo: class A { has %.env is rw }; my $a = A.CREATE; my %h = env => { foo => 'bar' }; A.BUILDALL(A, $a, env => { foo => 'bar' }) | 16:54 | |
p6eval | rakudo 1c263b: OUTPUTĀ«too many named arguments - 'env' not expectedā¤current instr.: 'parrot;Perl6Object;BUILDALL' pc 1272 (src/classes/Object.pir:331)ā¤Ā» | ||
jnthn | meh | ||
I'll have to look at the spec/source. | |||
ruoso | BUILDALL was supposed to have *%_ as args | ||
jnthn | Yeah, I thought so too. | ||
(I actually thought it did...) | |||
(As in, did in Rakudo.) | 16:55 | ||
ruoso | it's $proto.BUILDALL($candidate, *@protoobjects, *%attributes) IIRC | ||
masak | it would be good if I could define my own 'new' method... | 16:58 | |
mberends | masak: it's supposed to be possible, if you make it bless your $object ... somehow | 16:59 | |
read that on #perl6 | |||
jnthn | masak: The problem isn't writing your own .new, it's just what to write in there. :-) | ||
masak: I'll look into it. | |||
masak | jnthn: thank you. | 17:00 | |
ruoso | basically the problem seems to be in BUILDALL... all the rest seems to be working just fine | ||
jnthn | Just trying to get some other bits polished off so I can spend the evening on Rakudo stuff. | ||
pmichaud | I suspect that Rakudo's BUILD/BUILDALL isn't completely following the SMOP OO API yet | ||
jnthn | pmichaud: Feel free to beat me to investigating; I need to finish some stuff up and then do dinner yet... | ||
pmichaud | I'm still working through my backlog here -- but yes, one of us should get to it soon. | 17:01 | |
jnthn | Aye. | ||
pmichaud | I don't have a problem with refactoring the existing BUILD/BUILDALL to be more "correct" | ||
(i.e., I don't have a problem if someone else works on it) | |||
jnthn | Sure. I just don't want to make it less correct in the process. ;-) | ||
pmichaud | what's there now was simply attempting to get us through the parameter refactor earlier in the year. | ||
TimToady | bless is supposed to call BUILDALL for you automatically | 17:02 | |
but only if the metaclass needs it :) | |||
17:02
masak left
|
|||
jnthn | pmichaud: Ah, OK. I feel less bad about hacking on it in that case. | 17:02 | |
17:02
zamolxes left
|
|||
ruoso | while not spec, the implementation in pugs_repo/v6/smop/src-s1p/*.pm is a result of a deep process of trying to understand S12 | 17:02 | |
jnthn | Well, I didn't feel bad anyway, but... :-) | ||
ruoso | specially ClassHOW.pm and Object.pm | 17:03 | |
jnthn | ruoso: Thanks, I've glanced at those before, I'll take another look. | ||
ClassHOW I already did look at a bit and followed somewhat on the dispatch thingy. | |||
But now I'm less sure dispatch's interface is really enough. | 17:04 | ||
ruoso | jnthn, I really wish we could promote the REPR API to spec someday | 17:05 | |
jnthn | (e.g. for implementing .*, .?, .+ and so forth) | ||
ruoso | jnthn, I was assuming .* .? and .+ were external to the object | ||
jnthn | Built through the introspection interface? | 17:06 | |
ruoso | yes... | ||
but... | |||
jnthn | Since how a metaclass does the storage of its method table is stuff that only it knows. | ||
ruoso | maybe it works as adverbs to the dispatch method | ||
jnthn | Yeah | ||
I also pondered .WALK | |||
ruoso | :quantifier | ||
jnthn | Because surely the metaclass needs to help with that too... | ||
Or is that already in the HOW API? | 17:07 | ||
ruoso | if it's not, it should be written | ||
17:07
Patterner left,
Psyche^ is now known as Patterner,
pmurias left
|
|||
jnthn | Aye. But the another bit of me though, well, if we have WALK, do we really need .dispatch, or could we give .WALK an adverb saying "just the first matching one akshually" | 17:08 | |
s/the/then/ | |||
Which would provide our method lookup. And then it's just invoking it... | |||
ruoso | jnthn, I actually wasn't thinking in WALK as a real type... | ||
I was thinking of it more like an abstract idea | |||
jnthn | ruoso: Type? You mean method? | 17:09 | |
ruoso | er... the method is ^can | ||
jnthn | OK, but my point is that if we've got all these, do we really need ^dispatch too? | ||
17:09
pmurias joined
|
|||
ruoso | jnthn, I see your point... | 17:10 | |
jnthn | ruoso: (BTW WALK is listed as a method in S12) | 17:11 | |
ruoso: I'm just thinking that it feels like it'd be duplication of code. | |||
ruoso | hmm... | ||
baest | hello, I've found a test file in t/spec which isn't used in rakudo, but 14 out of 17 tests passes fine (with a single error correction in the test). I've added 'rakudo skip' for the failed tests for now. Can I submit a patch and if yes where to? | ||
ruoso | I missed that.. | ||
jnthn, I think this represents different levels of abstraction | 17:12 | ||
jnthn | baest: You can likely just have a commit bit to the Pugs repo to update the spectest. | ||
ruoso | .^dispatch being the most opaque | ||
.WALK being the most transparent | |||
17:12
gdonald joined
|
|||
jnthn | baest: But patches can go to [email@hidden.address] | 17:12 | |
baest | jnthn: I think I've have a commitbit for pugs, but I've misplaced it (never used it and got 2 years ago) | 17:13 | |
17:13
gdonald left
|
|||
baest | jnthn: great thanks, just a update to t/spectest.data so I'll post that | 17:14 | |
jnthn | OK, great. | ||
ruoso | jnthn, I think I assumed WALK is a type becuase of "Unlike in Perl 5 where .can returns a single Code object, Perl 6's version of .^can returns a "WALK" iterator for a set of routines that match the name" in S12 | ||
jnthn | Yeah | ||
I'm not thinking...hmm, so what is the difference between can and WALK other than that WALK lets you walk in different orderings... | 17:15 | ||
Oh, and gives a list rather than an interator. | |||
Hmm. | |||
Oh, or maybe it is an iterator that gets fully evaluated on the binding. | 17:16 | ||
ruoso | jnthn, it can be just a lazy list, can't it? | ||
jnthn | Yeah, for sure. | ||
Well | |||
If we want to assume lazy lists exist at that kinda level | 17:17 | ||
(I'm thinking bootstrapping stuff.) | |||
ruoso | I think .WALK shouldn't really be spec... | ||
it looks too much implementation specific | |||
ok... spec yes, | |||
but not required on every object... | 17:18 | ||
that's a different thing... | |||
like... if HOW does Walkable | |||
because not all object systems will have this information available | |||
that's where I think the different levels of abstraction play an important role | 17:19 | ||
for instance... | |||
jnthn | Hmm. | ||
ruoso | it might be possible that a HOW knows how to implement .^dispatch | ||
jnthn | But what about .can in that case? | ||
ruoso | but doesn't know how to implement .^can | ||
can is a in-between | |||
jnthn | Since it would seem to need to return an interator of the same info. | ||
Just with less options for getting at it. | |||
ruoso | but it doesn't support a lot of stuff WALK does | ||
jnthn | OK, but the point is that the first result of the iterator can hands back is enough to dispatch, no? | 17:20 | |
I can see why we'd not want to mandate WALK | |||
ruoso | but even .^can... one object could live a long life only providing .^dispatch | 17:21 | |
17:21
amoc left
|
|||
jnthn | (To be fair, part of my point behind all of this is that while .^dispatch really doesn't fit well into the Parrot model, .^can does) | 17:21 | |
ruoso | .^dispatch simply provides the most opaque abstraction to call an arbitrary method in that object | 17:22 | |
for instance... | |||
.^can returns a list of the candidates | 17:23 | ||
jnthn | (If we say that it's allowable to implement . by taking the first thing .^can hands back or by calling .^dispatch and that's an implementation specific decision and the meta-class should make sure it is smart enough about that, I'm happy enough.) | ||
ruoso | jnthn, that doesn't make much difference while you don't think about representation polymorphism | 17:24 | |
but if you take repr into account... it makes a big difference... | |||
jnthn | If you're saying that .^can should always be available, even if not .^WALK or whatever is behind WALK, I don't see how that follows. | 17:25 | |
ruoso | so... I'd say that you're free to optimize however you like for the known case... | ||
17:25
khisanth_ joined
|
|||
ruoso | I say that we can even make .^can optional | 17:25 | |
and provide several layers of abstraction to the metaclass implementation to choose | 17:26 | ||
(of course you can't use multiple dispatch if it doesn't provide WALK) | |||
jnthn | Can you give me a concrete situation when this makes sense? | ||
(Not providing ^can, but providing ^dispatch) | |||
ruoso | hmm.. | 17:27 | |
I'm mostly thikning about foreign object systems | |||
and allowing a low-barrier for the implementation of such interoperability | 17:28 | ||
for instance... | |||
a kinda-oo implementation in C | 17:29 | ||
pugs_svn | r25978 | baest++ | Adding myself to AUTHORS | ||
ruoso | that defines a pattern on the name of the methods | ||
Matt-W | like GObject? | ||
17:29
NordQ joined
|
|||
ruoso | yeah... for instance... (but GObject is powerful enough to provide the introspection) | 17:29 | |
Matt-W | true | ||
I'm hoping one day we can get a GTK+ binding autogenerated for Perl 6 using introspection | 17:30 | ||
pugs_svn | r25979 | baest++ | Fixing a minor bug and adding rakudo skips | ||
jnthn | Hmm. | ||
Matt-W | but even if it didn't have that ,it's always had a strong name patter | ||
n | |||
jnthn | Yeah, perhaps you're right there will be cases. | 17:31 | |
ruoso | jnthn, so simply implementing .^dispatch would allow me to use that oo system in Perl 6 | ||
jnthn | Of course, ^can could always hand back an iterator of something that when you invoke it will attempt to do a call by that name. | ||
e.g. just thunk it. | |||
ruoso | right... but why fake it? | ||
jnthn | So there are solutions for those systems in .^can too. | ||
To be able to avoid .^dispatch. | 17:32 | ||
17:32
Khisanth left
|
|||
jnthn | e.g. the need for .^dispatch | 17:32 | |
ruoso | what's so bad about it? | ||
jnthn | Parrot's model for method invocation is two-step. Lookup, then invoke what the lookup returns. | ||
ruoso | (remember, if you know the HOW and you know the REPR... you're free to optimize it) | ||
jnthn | .^dispatch adds a layer of indirection. | ||
17:32
khisanth_ is now known as Khisanth
|
|||
jnthn | Sure, but it's nice if it doesn't need optimizing. ;-) | 17:33 | |
ruoso | jnthn, in SMOP, for instance, .^can is considerably more expensive than .^dispatch | ||
jnthn | Hmm. :-) | ||
I guess if it's optimizable for the default meta-class it's less of a concern. | 17:34 | ||
ruoso | jnthn, but actually... I don't think we need to spec one way or another | 17:35 | |
jnthn | Well, we do if ^can is meant to be optional. ;-) | 17:36 | |
ruoso | right... | ||
TimToady | it would be nice if nextsame were not implementation dependent though | ||
at least for P6 objects | |||
point taken about foreign methods | |||
ruoso | my point was actually just about that | 17:37 | |
I mis-expressed myself | |||
jnthn, in SMOP every invocation is internal to the object... that's the fundamental difference in our pov | 17:38 | ||
jnthn | ruoso: Clarify what you mean by "internal to the object" | ||
17:39
kolibrie joined
|
|||
ruoso | it means that $obj.foo in Perl 6 turns out to be $obj.foo in the low-level as well | 17:39 | |
the invocation is equal in low-level or high-level | |||
jnthn | Right, which I'd kinda like to be true in Parrot. ;-) | ||
ruoso | but that means I have no public vtable | ||
every invocation is the high-level invocation... receiving a caputre | 17:40 | ||
jnthn | Thing is that the lookup of what to call is internal to the object. | ||
(In Parrot) | |||
That's what find_method does | |||
ruoso | but the invocation itself is external | 17:41 | |
jnthn | find_method hands back what to invoke | ||
And we it's invoked | |||
s/we/then/ | 17:42 | ||
ruoso | where find_method is in the vtable, is it? | ||
jnthn | Or put another way, ^can and postcircumfix:{ } map quite neatly down to Parrot | ||
Yes, find_method is in the PMC vtable. | |||
ruoso | having dispatch in the PMC vtable would be too bad? | ||
jnthn | Where as ^dispatch maps less neatly. | ||
It would be. The point is that vtable calls are pretty "low-level" things. | 17:43 | ||
You perform larger operations by building them up from smaller ones. | 17:44 | ||
dispatch is built up from find_method and invoke. | |||
ruoso | but can't it be installed in the same level? | ||
jnthn | No. | ||
ruoso | because of re-entrancy/ | 17:45 | |
? | |||
because I mean... find_methods can be something not really low-level | |||
like... it might require traversing a WSDL | |||
(considering a SOAP Object System) | |||
jnthn | Sure, and we can re-enter, but it's costly. | 17:46 | |
A dispatch v-table method is *doable*. | |||
But it's not making good use of Parrot's architecture. | |||
pmichaud | ...but it doesn't sound very perlish to me. | ||
ruoso | the vtable must have the same entries for every PMC? | 17:47 | |
17:47
eternaleye_ left
|
|||
jnthn | The vtable is per-class. | 17:47 | |
Per type of PMC | |||
ruoso | Ok... | 17:48 | |
jnthn | Depends if you're using PMC in that sentence to mean pMC instance or not. | ||
But basically it boils down to | |||
If you want to make a call in a v-table method, you have to then do it in another run-loop. | 17:49 | ||
That is, make a call back to high-level stuff. | |||
And that's expensive. | |||
We'd like to be able to make the common case - $object.method - fast. | |||
If we have to keep ^dispatch, then as you note, we can probably optimize it away in a lot of cases. | 17:50 | ||
ruoso | right... can $object.method behavior be dependent on the pmc type of $object? | ||
jnthn | Yes. | ||
pmichaud | welll..... | ||
ruoso | so the question is solved | ||
pmichaud | I'm not so sure I agree with jnthn's answer | ||
jnthn | OK, it depends what you mean by "type of $object" | 17:51 | |
ruoso | which answer? | ||
jnthn | If you mean the type of the PMC, then yes, it can be. | ||
ruoso | "PMC Type" of $object | ||
pmichaud | iiuc, $object.method at parrot's normal level actually translates into two operations | ||
jnthn | In that case, yes, find_method can be implemented per PMC. | ||
pmichaud | find_method and invoke | ||
jnthn | Right. That's what I've been saying, essentially. | ||
ruoso | ok... that was not what I asked ;) | ||
pmichaud | find method can be dependent on the type of the pmc.... invoke is less so. | 17:52 | |
jnthn | So in Perl 6 terms, that's a bit like ^can and postcircumfix:{ } | ||
pmichaud | I think you mean postcircumfix:<( )> | ||
jnthn | Huh? | ||
Oh, angles. :-) | |||
pmichaud | invoke is postcircumfix-parens, not postcircumfix-braces | ||
jnthn | Oh! | ||
Yes. | |||
Sorry. | |||
what pm said :-) | 17:53 | ||
ruoso | but.... | ||
find_method, invoke | |||
happens independent of the PMC type | |||
pmichaud | the fact that obj.'method'(...) translates to find_method and invoke is independent of the PMC type, yes. | ||
ruoso | no matter how each of them are implemented | ||
pmichaud | what find_method returns is polymorphic on the PMC | 17:54 | |
and what invoke does is polymorphic on the PMC | |||
(in the case of invoke, it's based on the PMC returned by find_method) | |||
jnthn | Note that what invoke does is polymorphic on _the PMC returned by find_method_. | ||
ruoso | right... | ||
pmichaud | so, obj.'method'(...) becomes essentially: | ||
$P1 = find_method obj, 'method' | |||
$P1(obj, ...) | 17:55 | ||
ruoso | pmichaud, you use obj.'method', but I assume obj.method (without the quotes) is the same | ||
pmichaud | ruoso: in PIR the quotes are required around a method name. | ||
ruoso | ah... ok | ||
pmichaud | (that's relatively recent) | 17:56 | |
ruoso | how hard would it be to pessimize on unknown PMC types? | ||
pmichaud | what's an "unknown PMC type", though? | ||
[particle] | otherwise it looks for a named register (.pmc local method) and calls get_string on that, and tries to invoke that | ||
ruoso | not in the parrot core | 17:57 | |
pmichaud | at runtime the PMC types are known. | ||
at compile-time, all PMC types look the same. | |||
i.e., registers aren't "typed" | |||
[particle] | ruoso: all pmcs have an invoke vtable, so any pmc can be invoked. | ||
ruoso | right... let me rephrase | ||
[particle] | if the pmc doesn't implement invoke vtable, it inherits one | 17:58 | |
it may inherit from Null PMC, which throws an exception | |||
pmichaud | (actually I think it inherits from 'default' PMC) | ||
jnthn | Or the default pMC, which throws a different exception. | ||
[particle] | ah, right, default. | ||
so you can catch that exception, and realize it's not Invokable | 17:59 | ||
ruoso | I assume every PMC needs to implement find_method as well | ||
pmichaud | it's inherited from the default if not implemented. | 18:00 | |
jnthn | No, but there is a default one that is inherited. | ||
ruoso | yes... that's what I mean... | ||
[particle] | there are 140+ vtable entries, every pmc has an entry of each | ||
pmichaud | every PMC has a vtable entry, yes. | ||
every PMC has a vtable entry for find_method, yes. | |||
ruoso | so the vtable is static | ||
that's a better way of putting that question... | |||
the vtable access is static, that is | 18:01 | ||
[particle] | the vtable is the api. | ||
TimToady | the RI? | ||
jnthn | Right. The vtable is a set of operations that something might know how to do. | ||
ruoso | kinda... but SMOP RI has only one entry... (besides the gc stuff) | ||
jnthn | (Or might not know how to do, in which case you'll get an exception.) | ||
ruoso | jnthn, so it wouldn't be so hard to pessimize with a TryCallingDispatchInstead.... | 18:02 | |
*TryCallingDispatchInsteadException.... | |||
TimToady | an I'm-Really-Prototype-Based exception :) | 18:03 | |
ruoso | jnthn, but then I guess you can get the HOW without having to call find_method, right? | ||
jnthn | ruoso: I don't quite see what your suggesting... | 18:04 | |
18:04
rafl_ joined
|
|||
ruoso | if that HOW can't implement .^can | 18:04 | |
it will throw an exception in find_method | |||
TryCallingDispatchInsteadException ;) | |||
jnthn | Ah | ||
ruoso | does it fit? | 18:05 | |
jnthn thinking | |||
Possibly. | |||
pmichaud | it still bugs me that all of our method dispatch is having to go through the HOW | ||
that's "overhead" to Parrot. | |||
TimToady | the I-can't-can exception :) | ||
[particle] | yep, can't use parrot's can | ||
pmichaud | I should say "that's additional overhead" to Parrot. | ||
jnthn | pmichaud: Aye, thus this discussion. | ||
pmichaud | okay. | 18:06 | |
jnthn's the lead for the Parrot side of this discussion :-) | |||
jnthn | Gah! Responsibility?! | ||
;-) | |||
ruoso | pmichaud, not all method dispatch needs to go through the HOW | ||
TimToady cheers loudly for both teams!!! | |||
ruoso | if you know the low-level for every involved | ||
you can cheat | |||
[particle] wonders who the referee is | 18:07 | ||
...and boos him loudly | |||
moritz_ | ceiling cat ;-) | ||
pmichaud | at compile-time I don't think we know the low-level for everything involved. | ||
perhaps we can do that... but it seems 'iffy' | |||
ruoso | that's what JIT is for, isnt' it? | ||
jnthn | sub foo($x) { $x.bar(); } # we don't know about $x | ||
PerlJam | TimToady: just like IBM backed both ASCII and EBCDIC at one point? | ||
[particle] | iffy is taken, you need a new term :) | ||
TimToady is fortunately to have gathered players who need cheering more than they need to have fouls called on them. | |||
s/ly// | 18:08 | ||
pmichaud | as far as "that's what JIT is for..." I'm not exactly sure what you're referring to there. | ||
ruoso | pmichaud, check if $x is P6Object, if its how is ClassHOW, then call this optimized version | 18:09 | |
(actually, you don't even need JIT to do that) | |||
pmichaud | that's still "overhead" | ||
TimToady | more like trace optimizatoin | ||
pmichaud | ideally we'd like to just generate x.'method'(...) and not have to do the checks. | ||
ruoso | yeah... I'm not really aware of most of those techiniques... but nothingmuch convinced me that some people know how to make it be fast ;) | ||
pmichaud | if we have to do the checks, then it becomes '!dispatch'(x, 'method', ...) and we get the overhead | 18:10 | |
18:10
Kisu left
|
|||
[particle] | unless there's a super-lightweight check, like a 'nativeobject' flagbit | 18:10 | |
ruoso | [particle], that's what I'm talkign about... that's what I mean for "known pmc types" | 18:11 | |
pmichaud | I still don't understand 'known pmc types'. at compile-time, we don't know the type. | ||
at runtime, we know all of the types. | |||
[particle] | 'known' as in 'i know how to dispatch this, no need to check' | 18:12 | |
18:12
M_o_C joined
|
|||
ruoso | by known I mean the ones you can assume the internal low-level layout | 18:12 | |
pmichaud, but I think we lost a point here... | |||
pmichaud | I already know the low-level layout of a PMC. That's what a PMC defines. | 18:13 | |
TimToady | checking a bit sounds wrong | ||
[particle] | yeah, to me too, it's just an example | ||
ruoso | pmichaud, is the ICantCanException still overhead? | ||
TimToady | any VM is going to have native thingies, and other things that are proxied through the native thingies | ||
18:13
Woody4286 left
|
|||
pmichaud | ruoso: depends on what you want to be doing the 'canning' ? | 18:13 | |
ruoso | TimToady, er... SMOP supports completely unknown things... | ||
18:14
Woody4286 joined
|
|||
[particle] | smop is a collection of vm's | 18:14 | |
:) | |||
moritz_ | in 2009 you write meta-VMs | ||
18:14
xinming_ is now known as xinming
|
|||
pmichaud | in the phrase ICantCanException, what is the "I" ? | 18:14 | |
ruoso | pmichaud, the PMC | ||
18:14
rafl_ is now known as rafl
|
|||
pmichaud | you're asking if a PMC can throw an exception for methods it doesn't understand? | 18:15 | |
ruoso | pmichaud, the point here is making $object.^can optional | ||
jnthn | pmichaud: This comes down to, ruoso thinks that ^can should be optional. | ||
ruoso | so foreign implementations can go straight for .^dispatch | ||
so, as parrot always do a two-step invocation | |||
pmichaud | okay, I'm missing a point then. | ||
ruoso | I was considering that if find_method raised an exception for the cases where .^can is not implemented | 18:16 | |
it could use a different invocation mechanism | |||
jnthn | pmichaud: I think that I'd rather do away with ^dispatch, and ^can in the event that you have a metaclass that doesn't know without trying what methods it can dispatch will hand back something that you can then invoke, and it will then fail when you try to invoke it. | ||
pmichaud | jnthn: what are you envisioning as the invocation sequence for $x.bar() ? | 18:17 | |
i.e., the PIR code generated? | |||
jnthn | $P0 = find_lex '$x' | ||
$P0.bar() | |||
pmichaud | okay, that's what I want also. | ||
jnthn | pmichaud: And we'd not use Parrot's Object PMC, but our own that does the Right Thing in the find_method vtable. | ||
pmichaud | so where does ^can fit into this? | ||
ruoso confused... | |||
jnthn | pmichaud: ^can maps down more to find_method than Parrot's idea of can. | 18:18 | |
TimToady | how does nextsame work? | ||
pmichaud | jnthn: no problem, I got that. | ||
but I don't see ^can in the $P0.bar() sequence. | |||
18:18
eternaleye joined
|
|||
jnthn | pmichaud: find_method *is* our ^can | 18:18 | |
pmichaud | okay. thinking. | 18:19 | |
jnthn | (And anything that isn't based on our default - optimized - P6Opaque will have a find_method that actually calls the metaclass' can) | ||
ruoso | jnthn, not only P6Opaque, but the HOW also | ||
pmichaud | actually, anything that isn't based on our P6Opaque would end up doing Parrot's normal find_method semantics, yes? | ||
jnthn | pmichaud: Yes. | ||
pmichaud: Apart from in Perl 6 you might have written a knowhow | 18:20 | ||
And want to call its ^can | |||
pmichaud | jnthn: so then our P6Opaque's find_method would do any needed HOW checking and pessimizing? | ||
ruoso | exactly... you have to look both at the representation *and* the HOW | ||
jnthn | pmichaud: I was proposing we have a P6Opaque PMC that doesn't need to pessimize at all, and another one that is the basis for the other representations. | 18:21 | |
pmichaud | jnthn: I don't understand "other representations" | ||
ruoso | jnthn, that doesn't fit... you need to pessimize on the HOW | ||
jnthn, you can use different metaclasses with the same representation | |||
jnthn | ruoso: Instances of an object can be used to find a HOW. | ||
Right? | |||
ruoso | I didn't see what you mean | 18:22 | |
jnthn | So find_method for anything other than P6Opaque would look up the HOW, then find and call ^can | ||
pmichaud | jnthn: what else is there besides P6Opaque, though? | ||
(more) | |||
because to me, "anything other than P6Opaque" includes Parrot objects | |||
ruoso | pmichaud, in theory anything the user wants | ||
pmichaud | and those Parrot objects already have a find_method | ||
that doesn't look up the HOW | 18:23 | ||
jnthn | pmichaud: Which is completely fine. | ||
pmichaud: I'm talking about the third case | |||
ruoso | jnthn, I didn't see what you mean... P6Opaque also needs to look up the HOW... | ||
pmichaud | jnthn: I don't understand the third case. | ||
jnthn | ruoso: Ah, because you could have a different HOW also using P6Opaque? | 18:24 | |
ruoso | yes | ||
jnthn | Ah. | ||
pmichaud | jnthn: I see the case where we have things that are P6Opaque, and we have things that aren't P6Opaque (i.e., Parrot objects). What's the third case? | ||
ruoso | P6Opaque using ClassHOW | ||
vs P6Opaque using SomeOtherHOW | |||
18:24
muideen joined
|
|||
jnthn | pmichaud: When you have written a knowhow specifying a ^can yourself. | 18:24 | |
pmichaud | I don't have a problem with that.... SomeOtherHOW can override find_method also. | 18:25 | |
ruoso | er... | ||
SomeOtherHOW is not the one receiving the find_method call | |||
is it? | |||
jnthn | pmichaud: Yeah, it's just that we're confusing representation and HOW a bit. | ||
ruoso | P6Opaque => REPR | ||
ClassHOW => HOW | |||
nativeint => REPR | |||
p5blessedhash => REPR | 18:26 | ||
RoleHOW => HOW | |||
you can interchange them at will | |||
pmichaud | I'll rephrase. | ||
I don't have a problem with that -- find_method in P6Opaque can check the HOW easily enough | 18:27 | ||
ruoso | right... and that's it | ||
pmichaud | there's lot of cheating available there. | ||
jnthn | Right. | ||
ruoso | if you have P6Opaque with ClassHOW you can cheat as long as you want | ||
lichtkind | jnthn: hello | ||
18:27
muideen is now known as goksie,
goksie is now known as muideen
|
|||
jnthn | lichtkind: hi! | 18:27 | |
18:28
muideen is now known as goksie
|
|||
TimToady lazily appreciates that you guys are doing the Hard Work | 18:28 | ||
jnthn | But our ability to do that cheat all depends on us being able to emit $P0.'bar'() where $P0 contains the object. | ||
pmichaud | jnthn: and yes, your idea of returning an invokable PMC that then calls the correct dispatcher (for non-standard HOWs) sounds fine to me. | ||
jnthn | Oh hey! We could return a curried invocation of dispatch... | 18:29 | |
pmichaud | it does make me wish that the name by which a Sub PMC was invoked was available to the Sub itself. | ||
I've often wanted that in Parrot and can't find a way to do it. | |||
jnthn | pmichaud: It's not available because of the 2-step find_method/invoke that we're talking about here. :-) | 18:30 | |
TimToady | ln -s sendmail mqueue | ||
ruoso | so... we're all happy with optional .^can? | ||
jnthn | I guess we can deal with it. | ||
pmichaud | ruoso: I'm happy if jonathan's happy, and if we're aiming again at the $P0.'bar'(...) sort of dispatch. | 18:31 | |
ruoso | cool... | ||
ruoso brb & | |||
pmichaud | I have to run to the post office (went by earlier... line was too long) | ||
so, bbiab | |||
TimToady | thanks everyone | ||
jnthn | ruoso: So long as it's OK that Parrot does the equivalent of trying .^can first, rather than promsing a $x.bar() actually really calls .^dispatch. | ||
Which I think we are agreeing that it can. | 18:32 | ||
Because we'll fall back to .^dispatch in the cases that it can't. | |||
18:32
riffraff left
|
|||
jnthn | And I might find we can promise something stronger than that, even. | 18:33 | |
Anyway, me & too - need dinner | |||
18:35
NordQ left
18:39
schmalbe joined
18:41
protorom joined
18:42
eternaleye left
19:02
FurnaceBoy|afk is now known as FurnaceBoy
|
|||
szabgab | I'd appreciate your comments on the code and the docs of Inline::Rakudo | 19:10 | |
github.com/szabgab/perl6-in-perl5/tree/master | |||
19:11
pmurias left
|
|||
szabgab | and if anyone know why o I need to chdir that would be great | 19:11 | |
19:12
Schnueff joined
19:20
rindolf joined
19:23
goksie left
|
|||
mberends | szabgab: I think this is one of those inventions whose time has not yet come. You are probably pushing for this kind of functionality for Padre-related reasons, which are quite sophisticated. I think the majority of developers will only start to appreciate this facility when Rakudo nears completion, because then the demand for 5 <-> 6 integration will increase. For myself, pure Perl 6 is currently an adequate playground to explore. | 19:25 | |
19:26
disismt left
19:27
disismt joined
19:34
protorom left
19:37
kidd joined
|
|||
mberends | szabgab: does interop in the reverse direction already exist, or is that coming next? I have no idea about the chdir puzzle btw, sorry. | 19:40 | |
szabgab | do you mean embedding perl5 in perl 6 ? | 19:41 | |
I have no idea about that | |||
mberends | yes. Pugs did a bit of that for regexes, afair. | ||
szabgab | no, I don't understand that kind of C level stuff | 19:42 | |
19:44
[particle] left
|
|||
mberends | too bad. the demand for both 5->6 and 6->5 will get bigger as people start porting their existing code to Rakudo, which will probably start happening in late 2009 when a 'Beta' is officially completed. | 19:45 | |
did you write that you were resuming Padre work without the pressure of a grant? | 19:47 | ||
szabgab | oh I was working on Padre anyway | 19:48 | |
just not on this part | |||
but now that I have this started I'll where does it lead me | |||
19:51
netsquire joined
|
|||
mberends | cool. it will lead to the most satisfying result. | 19:51 | |
looking forward to meeting you at NPW next month | 19:52 | ||
jnthn back from dinner | 19:56 | ||
japhb | jnthn: two part question: a) any movement on the 'use Foo:from<parrot>;' front yet, and b) do you think it would be difficult for someone else to work on? | 19:58 | |
I'm thinking of trying my hand at it, but I don't have a huge amount of time to spare. :-( | |||
jnthn glances around for pmichaud | 19:59 | ||
japhb: On my part, no movement since you last asked, and I didn't see any other commits related to that. | |||
Really I'm blocking more on pmichaud's input on how he wants that to look. | 20:00 | ||
I'm happy to write the code if I know that. | |||
(To be fair, I haven't exactly asked for said input. But I'll try and pursue it more actively now.) | |||
japhb | What is there to decide? (That's an honest question -- I mean, is it because there are a couple possible implementation paths?) | 20:01 | |
20:02
M_o_C left
|
|||
japhb | jnthn: much appreciated re: active pursuit. The official OpenGL bindings for Perl 5 are currently quite broken, and I can't get my fix. ;-) | 20:02 | |
Besides, no time like the present to switch to Perl 6 development for new gfx code. | |||
I'm taking the death of the P5 bindings as a sign. | 20:03 | ||
;-) | |||
jnthn | I just am aware that pm has thought it through somewhat, or maybe quite a lot, and I really haven't. | ||
I think that it may be a case of trying to do something at a PCT level. | 20:04 | ||
Rather than just some Rakudo-specific thing. | |||
japhb | nodnod | 20:05 | |
szabgab | mberends, me too it will be cool in Oslo | ||
jnthn | Oslo will be The Awesome. :-) | 20:07 | |
20:31
[particle] joined,
ujwalic joined
|
|||
ruoso | jnthn, yes... it is ok to try .^can first... | 20:33 | |
Diederich | was there ever any consensus about what the CPAN for Perl6 would look like? | 20:35 | |
ruoso | Diederich, not really... there are some sketches in the spec | ||
Diederich | there was some talk about it on Perlbuzz a while back | ||
ruoso | one thing we do know is: | 20:36 | |
Diederich | I think there should be something, no matter how primitive, | ||
as the canonical Perl 6 module repo | |||
ruoso | we have three different issues | ||
1) source file format | |||
Diederich | it can just be a github thing | ||
ruoso | 2) installation process | ||
3) distribution software | |||
Diederich | those need to be solved, | ||
but having an 'official' place for the modules to exist is a lot simpler than that | |||
(tied together to be sure..) | |||
but some place should be selected far sooner than later, even if it changes later | 20:37 | ||
if such a place existed, the chances of me working on some P5->P6 modules right now would be higher | |||
ruoso | Diederich, that is the distribution software... there's work by markov about it | ||
Diederich | and I think that's true of everyone | ||
s/everyone/many people/ | 20:38 | ||
ruoso | www.cpan6.org | ||
mberends | Diederich: have you looked at pugs/misc/sixpan ? | ||
Diederich | #doesn't want to get too far ahead of things | ||
I have looked at pugs... | |||
not that URL | |||
The CPAN6 network | |||
* can be used to collect any kind of data: software, publications, photos, ...anything into archives; | |||
cool...got it in one, Mr. Garabaldi. | |||
alester | Diederich: There will be no consensus. | ||
Diederich | there may be | 20:39 | |
alester | It will be created by the people who make it happen first. | ||
Diederich | there may be after it's already there | ||
ruoso | specially because the network is *a network* | ||
Diederich | see CPAN... | ||
ruoso | it depends on people getting along | ||
Diederich | that's an amazing thing...that could happen again | ||
the current CPAN, in my opinion, is the biggest reason that Perl5 is still relevant | 20:40 | ||
Perl6 the language will be awesome by itself...and highly relevant | 20:41 | ||
alester | We all agree that CPAN is good. | ||
Diederich | Perl6 + CPAN6 (or whatever it is) will be way over the top | ||
alester | We all agree that Perl 6 will need a way to distribute code. | ||
There is nothing else that can be said. | |||
There is no Perl 6 toolchain. | |||
ruoso | alester, I consider even that there shouldn't be *a* Perl 6 toolchain | 20:42 | |
alester | ruoso: THere you go. | ||
Diederich | yeah, with multiple implementation, that gets tricky | ||
ruoso | multiple implementations | ||
alester | So, again: There will be no consensus. | ||
ruoso | multiple architectures | ||
alester | There will be no advance planning. | ||
People will do what works for them and will accrete momentum. | 20:43 | ||
Diederich | hm..that's kind of dour | ||
ruoso | that's why, I insist, the only thing we know so far... | ||
alester | Dour? How? | ||
ruoso | is that the three problems are completely separated | ||
Diederich | there certainly will be advanced planning! | ||
ruoso | 1) source file format | ||
Diederich | perhaps most of it will be wrong | ||
ruoso | 2) installation process | ||
alester | Certainly? | ||
ruoso | 3) distribution software | ||
alester | Who's doing the planning? | ||
Diederich | well, in a very very limited way, I guess I am | ||
ruoso | alester, actually there is some planning... | ||
Ssomething | |||
mberends | the bazaar will beat the cathedral, in the words of Eric Raymond | ||
Diederich | it looks like [email@hidden.address] is doing some planning too | ||
ruoso | there's a DRAFT spec | 20:44 | |
I think one thing needs spec | |||
in the "cathedral" sense | |||
which is the "source file format" | |||
alester | So much "It needs this, it needs that" | ||
and yet, precious little JFDI. | |||
Diederich | I agree that it'll be impossible to predict what the many 'it's' will look like in a few years | ||
ruoso | alester, sure sure... but we're still quite far from facing that problem... | 20:45 | |
we need Perl 6 out first | |||
alester | Which problem? | ||
ruoso | then we bother on how to distribute it | ||
alester | ruoso: I suspect that someone will have the CPAN part worked out well before Perl 6 is "out", whatever that means. | ||
Diederich | well, I'm going to mail the cpan6 person and talk to him about what's on his mind | ||
and maybe help over there | |||
which leads to some small 'JFDI' I guess | 20:46 | ||
alester | "The" CPAN6 person? There's not a single cpan6 person. | ||
ruoso | alester, currently, mostly there is | ||
Diederich | I'm looking at the web page | ||
ruoso | markov is mostly behind cpan6 | ||
alester | "the" web page? | ||
Diederich | www.cpan6.org/ | ||
that was mentioned earlier | |||
I'm sure there are more than that around | |||
it's a place to start..instead of being negative about it | |||
alester | That's great, but it's irrelevant if nobody uses it. | 20:47 | |
Diederich | it's unlikely it'll be nobody! | ||
ruoso | alester, I'm not quite getting your point.. | ||
alester | I think you might be surpirsed. | ||
Diederich | such carelessly used absolutes are a very good way to discourage many people from doing anything | ||
alester | What aboslutes? | ||
Diederich | thus causing your predictions to be true | 20:48 | |
alester | I said it's irrelevant if nobody uses it. | ||
mberends | significantly, pugs/misc/sixpan is by a different group of developers | ||
alester | My point is that the first solution to get to relased will win. | ||
mberends | aye | ||
alester | cpan6.org has not been released. | ||
ruoso | are there other initiatives going on? I'm not aware of any... | 20:49 | |
alester | Doesn't matter if there are or not. | ||
20:49
sri_kraih_ joined
|
|||
ruoso | so... what's the point? | 20:49 | |
alester | My point is that just because this placeholder exists doesn't mean that it's what will happen. | ||
ruoso | agreed... but it is *something* | 20:50 | |
alester | I guess, for some value of "something" | ||
ruoso | and certainly not a "placeholder" | ||
alester | It's a lot of planning and something is started. | ||
See also: Pugs. | |||
Diederich | alester, I have a firm understanding of your perspective, thanks. | ||
ruoso | alester, I really don't understand why you're so angry about it... | ||
alester | I'm not angry at all. | ||
mberends | suggestion: let's develop many pilots and apply natural selection ;) | 20:52 | |
alester | That's what's going to happen, whether you suggest it or not, mberends ; | ||
People will do what works for them. | |||
ruoso | jnthn, what do you think about making a role hierarchy for the HOW API? to specify the features each one implements? | 20:54 | |
jnthn | ruoso: I guess that implies RoleHOW has to exist in order to define ClassHOW? (Which is probably fine...) | ||
ruoso | I guess so... specially because the built-in types are roles anyway | 20:55 | |
but which roles does RoleHOW do? | |||
;) | |||
jnthn | Yes, true. | ||
No, don't go there. :-P | |||
I've got enough issues just trying to extract List and Array out to be pure Perl 6... | 20:56 | ||
alester | If I had any sort of software to release under P6, I'd probably host it on github and make a toolchain of my own until another came along. | ||
ruoso | alester, er... that's what people already do... | 20:57 | |
alester | what is out there in Perl 6 now? | ||
ruoso | november | ||
jnthn | druid | ||
Form | |||
alester | I oughta put up a page of it. | ||
20:58
gdonald joined
|
|||
jnthn | alester: See also www.perl6-projects.org/ | 20:58 | |
ruoso | jnthn, but have you realized that (1,2,3) is not a List? | ||
jnthn | ruoso: Erm...? | ||
ruoso | it is a capture | 20:59 | |
jnthn | That's be \(1,2,3) surely? | ||
ruoso | that's a capture enclosed in a scalar | ||
I've just realized that, after trying to figure out how to deal with flatten vs unflatten | |||
20:59
awwaiid joined
|
|||
ruoso | (((1,2,3),2,3),2,3) | 20:59 | |
jnthn | Is this spec, or the results of your ponderings? | 21:00 | |
ruoso | results of my ponderings... | ||
jnthn | Ah. | ||
ruoso | which usually are more dangerous than spec ;) | ||
jnthn | That's different. | ||
Yeah | |||
;-) | |||
ruoso | anyway... | ||
jnthn | The thing that makes me suspect otherwise is that | ||
my $x = (1,2,3); # $x holds a capture now | |||
I think ti's the item context that makes it beomce a capture. | |||
That changed recently-ish (before, it became an Array). | 21:01 | ||
alester | anyone got a URL for Form? | ||
ruoso | jnthn, an capture in item context returns itself, unless it contains only one parameter (named or positional) | 21:02 | |
and capture implements both .[] and .{} | |||
ruoso decommute & | |||
21:02
ruoso left
21:03
DemoFreak joined
|
|||
jnthn | alester: You may also find github.com/masak/proto/tree/master interesting. | 21:03 | |
alester | Interesting how? | ||
What is it | |||
jnthn | See README but basically a lightweight module installer. | 21:04 | |
That knows where to find from github a bunch of Perl 6 related proejcts. | |||
github.com/masak/proto/blob/e8627fc...dules.list actually tells you where Form is too ;-) | |||
21:05
ejs joined
|
|||
jnthn | (github.com/mattw/form/tree/master) | 21:05 | |
21:05
sri_kraih left
|
|||
alester | rakudo.org/perl-6-projects started | 21:06 | |
21:09
Whiteknight joined
21:14
gdonald_ joined
21:16
gdonald left
21:25
mj41 left
21:29
gdonald joined
21:30
schmalbe left,
mj41 joined
|
|||
moritz_ | rakudo: Q<< foo < ' > bar >>.say | 21:31 | |
p6eval | rakudo 1c263b: OUTPUTĀ« foo < ' > bar ā¤Ā» | ||
21:36
ejs left
21:39
gdonald_ left
21:48
ujwalic left
|
|||
moritz_ | github.com/moritz/json/tree/master very early grammar for JSON | 21:50 | |
21:54
gdonald left
|
|||
frioux | moritz_: that's really cool! | 21:55 | |
moritz_ | frioux: thanks | ||
it's still a *very* early version | 21:56 | ||
Matt-W | So much exciting stuff going on these days | ||
22:01
skids left,
bacek left
22:02
pmurias_ joined
|
|||
moritz_ | rakudo: rule a { '[' ~ ']' A? }; say '[ ]' ~~ /<a>/ | 22:02 | |
p6eval | rakudo 1c263b: OUTPUTĀ«Unable to parse a, couldn't find final ']'ā¤current instr.: 'parrot;PGE;Match;FAILGOAL' pc 2927 (compilers/pge/PGE/Regex.pir:456)ā¤Ā» | ||
moritz_ | a bug? | 22:03 | |
moritz_ wants LTM | 22:04 | ||
jnthn | rakudo: rule a { '[' ~ ']' A? }; say '[]' ~~ /<a>/ | ||
p6eval | rakudo 1c263b: OUTPUTĀ«[]ā¤Ā» | ||
jnthn | rakudo: rule a { '[' ~ ']' [ A? ] }; say '[ ]' ~~ /<a>/ | 22:05 | |
p6eval | rakudo 1c263b: OUTPUTĀ«[ ]ā¤Ā» | ||
22:05
wknight8111 joined
|
|||
jnthn | moritz_: Dubious. | 22:05 | |
moritz_ | jnthn: probably up for debate | ||
jnthn | moritz_: It's to do with whether there's a <.ws> see either side of the A? | ||
22:05
Whiteknight left
|
|||
jnthn | s/'?'/./ | 22:06 | |
moritz_ | jnthn: I know | ||
22:06
rindolf left
|
|||
jnthn | But hard to call, what the answer on that is. | 22:06 | |
moritz_ | the current behaviour makes kind of sense | ||
because ~ acts on the next two atoms | |||
jnthn | Right. | ||
moritz_ | and if you count implicit <.ws> as atoms, then DWIM is in trouble | ||
jnthn | Aye. | 22:07 | |
moritz_ | so not ticket ;-) | ||
jnthn | Phew! ;-) | ||
moritz_ | anyway, the <.ws> thing usually *really* dwims | 22:08 | |
for the JSON grammar I'm writing that's cool | |||
22:09
ejs joined
22:10
pmurias joined,
Schnueff left,
pmurias_ left,
pmurias left
22:11
ejs left
|
|||
moritz_ | and it's so nice that $somebody already wrote tests | 22:11 | |
22:15
gdonald_ joined,
gdonald_ left
22:18
Diederich left
22:22
hercynium left
22:26
[particle] left
|
|||
moritz_ | all JSON parsing tests pass. Nice. | 22:34 | |
22:34
wknight8111 left
|
|||
moritz_ | that was... not too hard | 22:34 | |
I'll wait with the action methods und .caps and .chunks are updated in Rakudo... | 22:35 | ||
which I plan to do as soon as %($/).pairs stops to stringify its value | |||
22:39
alester left
|
|||
dalek | kudo: 7487710 | (Moritz Lenz)++ | t/spectest.data: Add S05-metasyntax/repeat.t to t/spectest.data |
22:43 | |
22:44
Diederich joined
22:47
netsquire left
22:50
fridim_ joined
22:51
skids joined
23:09
nihiliad left
23:11
frioux is now known as frioux_Away
23:13
Exodist left
|
|||
frooh_away | moritz_: what are all the {*}'sin the JSON grammar? | 23:15 | |
23:15
frooh_away is now known as frioux,
frioux is now known as frooh
23:20
Whiteknight joined
|
|||
moritz_ | frooh: they are hooks for action methods (soon to come) | 23:21 | |
frooh | ooh | ||
cool | |||
so I can make a SAX-like parser with this. | |||
23:26
kidd left
23:29
ludan joined
23:40
hercynium joined
|
|||
meppl | good nightz | 23:42 | |
23:43
meppl left
23:45
gdonald joined
23:47
frooh left,
frioux joined
23:48
gdonald left
|