»ö« | perl6-projects.org/ | nopaste: paste.lisp.org/new/perl6 | evalbot usage: 'perl6: say 3;' | irclog: irc.pugscode.org/ | UTF-8 is our friend! Set by moritz_ on 30 July 2009. |
|||
00:01
payload joined,
sevvie left
|
|||
pugs_svn | r28024 | lwall++ | [IO.pod] fix bogon-infested named parameter syntax | 00:08 | |
bpetering | phenny: tell masak we're duplicating effort... and do my dishes. (masak, that last bit's for phenny.) :) | 00:11 | |
phenny | bpetering: I'll pass that on when masak is around. | ||
00:11
davidm123 joined
|
|||
bpetering | You dish-avoiding robot you... | 00:12 | |
00:13
KyleHa joined
|
|||
davidm123 | where's a reference on using coroutines in perl6? does rakudo implement it yet? | 00:14 | |
bpetering | perlcabal.org/syn/S07.html#Coroutines | 00:16 | |
sjohnson | bpetering: just got back, backlogging | 00:17 | |
bpetering | I expect that will work in Rakudo... try, and report back here :) | ||
davidm123 | bpetering: thanks bpetering. will try | 00:18 | |
sjohnson | good advice | ||
i do sneak in Perl whenever I can | |||
even if it's translating an old bash script to Perl, i get much happiness | |||
after learning Perl from doing stuff in sh/bash, i never looked back | 00:20 | ||
davidm123 | bpetering: it fails on the line "$it <== my_coro() <== while 1 { shift(@a) };" with error 'Statement not terminated properly at line 17, near "{ shift(@a"' | 00:21 | |
jnthn | davidm123: While Rakudo does handle gather/take, we can't quite handle this yet...we're missing: | ||
davidm123 | I'm not even sure what "<==" does. | 00:22 | |
jnthn | * Laziness, without which the coros aren't very, well, coro | ||
* The feed operators (<== and ==>) | |||
bpetering | jnthn: roadmap? | ||
jnthn | Laziness is on the roadmap fro certain. | ||
It's required for Rakudo *. | |||
The feed operators are a nice to have, but they're useless without laziness. | 00:23 | ||
bpetering | davidm123: sorry, i need to scroll down further... everything jnthn++ just said | 00:24 | |
davidm123: Rakudo doesn't implement the feed operator, but it does implement gather/take. | 00:25 | ||
davidm123 looks up gather/take | |||
jnthn | bpetering: Yeah, thing is coros rely on gather/take actually being lazy. | ||
bpetering: So you can do stuff in between the takes. | 00:26 | ||
pugs_svn | r28025 | kyle++ | [t/spec] autounfudge --untodo | ||
bpetering | jnthn: thanks. As a #perl6 greeter, I'm in the position of saying, in effect, "I don't understand that, but I think this bit of the spec might help"... :) | 00:28 | |
jnthn | bpetering: It's appreciated. :-) | 00:29 | |
bpetering: We're all learning. :-) | |||
bpetering | davidm123: The short answer is no, you'll have to wait for Rakudo * (or at least some portion of the time between now and then, if you're ok using pre-star rakudo) | 00:30 | |
davidm123 | thanks bpetering, just curious . | 00:31 | |
00:31
japhb joined
|
|||
colomon | rakudo: my Num where { $^n < 10 } $n = 5; say $n; $n = 20; say $n; | 00:31 | |
bpetering | jnthn: No problem, NeoPerl is the coolest thing out there, as hoezlro said "I WANT TO USE THIS IN PRODUCTION... NOW" :) | ||
p6eval | rakudo 0d4fe0: ( no output ) | ||
00:32
davidm123 left
|
|||
jnthn | Hmm? Rakudo? | 00:32 | |
rakudo: my Num where { $^n < 10 } $n = 5; say $n; | |||
p6eval | rakudo 0d4fe0: OUTPUT«Malformed declaration at line 2, near "Num where "in Main (src/gen_setting.pm:3390)» | ||
jnthn | std: my Num where { $^n < 10 } $n = 5; say $n; | ||
p6eval | std 28024: ( no output ) | 00:33 | |
jnthn | std: my Num where { $^n < 10 } $n = 5; say $n; | ||
p6eval | std 28024: OUTPUT«===SORRY!===Malformed my at /tmp/IqEWr4Q7eM line 1:------> my Num ⏏where { $^n < 10 } $n = 5; say $n; expecting any of: declarator multi_declarator typenameFAILED 00:02 37m» | ||
jnthn | Apparently, not valid syntax. | ||
00:35
aindilis left
|
|||
TimToady | std: my (Num $n where { $^n < 10 }) = 5; say $n | 00:36 | |
p6eval | std 28024: ( no output ) | ||
TimToady | std: my (Num $n where { $^n < 10 }) = 5; say $n | ||
p6eval | std 28024: ( no output ) | ||
jnthn | fail | ||
sjohnson | TimToady: do you think you'd ever write a Perl 6 Camelia Book? | ||
TimToady | I don't know what O'Reilly will want to put on a Perl 6 book, but probably not Camelia | 00:37 | |
colomon | rakudo: subset SmallNum of Num where { $^n < 10 }; my SmallNum $a = 5; say $a; $a = 20; say $a; | ||
p6eval | rakudo 0d4fe0: OUTPUT«5Assignment type check failed; expected , but got Intin Main (/tmp/nYtoUtmzVv:2)» | ||
TimToady | std: my (Num $n where { $^n < 10 }) = 5; say $n | 00:38 | |
colomon | rakudo: subset SmallNum of Num where { $^n < 10 }; my SmallNum $a = 5; say $a; | ||
p6eval | std 28024: ( no output ) | ||
rakudo 0d4fe0: ( no output ) | |||
TimToady | server must be overhosed | ||
sjohnson | there's gotta be some die-hard Perl (or TimToady) fans around that would buy it | ||
i used up most of its syntax error quota for the day | 00:39 | ||
colomon | rakudo: subset SmallNum of Num where { $^n < 10 }; my SmallNum $a = 5; say $a; | ||
p6eval | rakudo 0d4fe0: ( no output ) | ||
bpetering | sjohnson: that made me laugh :) | ||
sjohnson | heh. it start working again when we first humble ourselves a bit more and try easier queries :) | 00:40 | |
wayland76 | TimToady: Sorry about bogon-infested syntax. I was confused, as usual. But at least it wasn't Vogons :) | 00:41 | |
sjohnson | rakudo: print "clean the pipes"; | ||
p6eval | rakudo 0d4fe0: ( no output ) | ||
jnthn | tubes! tubes! | ||
sjohnson | pugs: print "i haz a pipe cleaner"; | 00:42 | |
p6eval | pugs: OUTPUT«i haz a pipe cleaner» | ||
sjohnson | rakudo: print "i haz a pipe cleaner"; | 00:43 | |
p6eval | rakudo 0d4fe0: OUTPUT«i haz a pipe cleaner» | ||
sjohnson | there we go | ||
just had to change the oil | |||
TimToady | std: my (Num $n where { $^n < 10 }) = 5; say $n | 00:44 | |
colomon | That "Assignment type check failed" error is what I was looking for. | ||
p6eval | std 28025: OUTPUT«ok 00:03 41m» | ||
colomon | I get it when I work locally as well. | ||
So my first attempt to simplify my failing test was itself a fail. | 00:45 | ||
jnthn | rakudo: my (Num $n where { $^n < 10 }) = 5; say $n | ||
p6eval | rakudo 0d4fe0: OUTPUT«Multiple prefix constraints not yet supported at line 2, near "= 5; say $"in Main (src/gen_setting.pm:1723)» | ||
jnthn | Oh, hmm. | ||
That's a fishy definition of prefix. :-) | |||
TimToady | rakudo: my (Num $n) = 5; say $n | 00:46 | |
p6eval | rakudo 0d4fe0: OUTPUT«5» | ||
jnthn | TimToady: It's probably just counting the constraints and not caring if they're prefix or not. | 00:47 | |
TimToady | std: my ($n where { $^n < 10 }) = 5; say $n | ||
p6eval | std 28025: OUTPUT«ok 00:03 40m» | 00:48 | |
TimToady | rakudo: my ($n where { $^n < 10 }) = 5; say $n | ||
p6eval | rakudo 0d4fe0: OUTPUT«5» | ||
jnthn | std: my (Num where { $^n < 10 } $n) = 5; say $n | ||
p6eval | std 28025: OUTPUT«===SORRY!===Multiple prefix constraints not yet supported at /tmp/BUau9EpDLr line 1:------> my (Num where { $^n < 10 } ⏏$n) = 5; say $n expecting any of: bracketed infix infix stopper standard stopper terminator | ||
..type_constraintFAILED… | |||
TimToady | rakudo: my ($n where { $^n < 10 } where { $^n > 0 }) = 5; say $n | ||
p6eval | rakudo 0d4fe0: OUTPUT«Multiple prefix constraints not yet supported at line 2, near "= 5; say $"in Main (src/gen_setting.pm:1723)» | ||
jnthn | mebbe I'll fix that one tomorrow | 00:50 | |
For now, sleep time | |||
Night all | |||
bpetering | Night jnthn, sleep well, check your privmsg :) | 00:54 | |
sjohnson | see ya | ||
00:58
hercynium left
01:00
hercynium joined
01:05
xomas_ joined
01:18
tak11 left
|
|||
colomon | Aha! Figured out my problem with "where". I accidentally typed 1e10 when I wanted 1e-10 in my constraint. :) | 01:19 | |
01:23
carlin joined
01:27
jauaor left
|
|||
cj wants to do a masters in compling | 01:31 | ||
wayland76 | s/compling/compiling/ ? | 01:36 | |
sjohnson | Computer Language? | ||
01:37
[particle]1 joined
01:41
[particle] left
01:48
Whiteknight left
|
|||
wayland76 | compline? Or complan? | 01:54 | |
01:54
carlin left
|
|||
Patterner | coupling | 01:55 | |
01:56
carlin joined,
nihiliad joined
|
|||
pugs_svn | r28026 | wayland++ | [S32/IO] put in canonpath and realpath, as promised | 01:58 | |
r28026 | wayland++ | [S16] Things including: | |||
r28026 | wayland++ | * Made defaults more sensible (lax vs. strict mode) | |||
r28026 | wayland++ | * Added "use path" pragma | |||
r28026 | wayland++ | * Added :local, :modern, :portable, and :posix | |||
01:58
tak11 joined
01:59
payload left
|
|||
bpetering | cj: computational linguistics? | 02:00 | |
02:10
tann left
02:14
meppl left
02:17
reqamst left
02:19
smash joined
02:21
estrabd_ left,
smash_ left
02:26
rhr_ joined
02:38
rhr left,
carlin left
02:39
hercynium left
03:02
smash left
|
|||
bpetering | That was an intriguing statement. My guess is with your first, wayland76 :) | 03:05 | |
03:07
Limbic_Region left
03:22
sri_kraih_ joined
03:25
justatheory left
03:26
perletc joined
03:33
xomas_ left
03:36
sri_kraih left
03:43
jaldhar joined
04:07
zloyrusskiy joined
04:11
nihiliad left
04:20
Zloy_Russkiy joined
04:21
sevvie joined
04:34
PZt left
04:36
Zloy_Russkiy left
05:05
abra joined
05:34
flip913 joined
05:38
hah joined
|
|||
flip913 | Hello. I've got a C program of about 750k Sources (25k lines), where I have to do major changes. | 05:40 | |
05:40
orafu left,
abra left,
orafu joined
|
|||
flip913 | Now I'm thinking whether to use a high-level language for most things, and only code some small functions in C. | 05:40 | |
I read perlembed, and am now reading perlcall ... | |||
05:40
barney joined
|
|||
flip913 | but that's Perl5, and I'd like to do Perl6 anyway. | 05:41 | |
So, I've got a few questions. | |||
1) is there some way (in Perl6/Parrot) to get a single executable (ELF) from a mixed-source program? | |||
That's because of the startup speed - which is important, as this will be a commandline program, and be called often. | 05:42 | ||
So I don't want to have all kinds of libraries loading and so on ... just a single executable, please. | |||
Of course, that could include the Parrot bytecode internally ... I think that most startup overhead is the library loading and Perl source compiling. | 05:43 | ||
Is there something like this in Parrot yet? | |||
2) As this will handle a big amount of data (1M structures in a tree, with (32bit) ~240 bytes in C) I'd like to use some kind of C structure for storage. | 05:44 | ||
As opposed to a hash - to conserve memory. | 05:45 | ||
hah | rakudo: class A { has $!a is rw; method add (A $a) { $!a += $a.a }; method a { $!a } }; multi sub infix:<+=> (A $a, A $b) { $a.add($b) }; my A $x .= new(a=>10); my A $y.=new(a=>5); say $x.add($y); | ||
p6eval | rakudo 0d4fe0: ( no output ) | ||
Tene | Perl 6 isn't really ready for that, flip913. | ||
You *can* do some of it, though. | |||
hah | .oO( AKA segfault .) ) |
||
flip913 | Well, in Perl5 there are some classes for structure storage and so on ... | ||
Tene | You can't generate native machine code with Parrot. the best you can do is generate compiled parrot bytecode. | 05:46 | |
flip913 | And if it takes a year for Perl6/Parrot/Rakudo to get there, I wouldn't mind ... because I'll have to re-write my code anyway. | ||
Tene | When looking, you'll find 'pbc_to_exe'. This doesn't generate machine code, it simple embeds the pbc (compiled parrot bytecode) into a copy of the parrot executable. | ||
flip913 | Bytecode is ok, if it can be embedded in an executable - along with the bytecode of all needed libraries. Pre-compiled, if you like. | ||
Tene | There currently isn't a way to also embed all the relevant libraries. | 05:47 | |
flip913 | Ok, I'll take a look. | ||
Tene | That's a planned feature, but not yet implemented. | ||
flip913 | About point 2 ... structure packing. Is there already a simple way to get a class with accessors for a packed C structure? | 05:48 | |
Tene | The process of writing some of your code in C is not well-documented. | ||
And there is no way to get a class with accessors for a packed C structure. | 05:49 | ||
flip913 | I'd want to expand that class with methods in Perl6. | ||
Not even in Parrot? | |||
Tene | (beyond writing some native C functions and doing it all yourself) | ||
05:49
Entonian joined
|
|||
Tene | You *can* load and call arbitrary C functions. | 05:49 | |
japhb | flip913, packed structure support exists in Parrot, but it's not perfect yet -- and the interface is rather baroque. | ||
05:50
tann_ joined
|
|||
flip913 | Well, a (perhaps very slow) way would be to call pack()/unpack() ... but that's *too* slow, I think. | 05:50 | |
05:50
finanalyst joined
|
|||
japhb | Perl 6 is specced to have pretty decent support for native typed packed structs, but it's low priority for implementation right now. | 05:50 | |
flip913 | Well, how about using that a hint to improve the documentations? Or, another idea, are there some examples how to do that? Then I could ask here, and perhaps write a HOWTO. | ||
At the YAPC you wanted to get some application developers ... well, here I am! ;-) | 05:52 | ||
05:52
frew__ left
|
|||
japhb | In Parrot, ISTR the SDL bindings using structures. I do some minor packed struct work in examples/opengl/shapes.pir | 05:52 | |
bpetering | flip913: welcome. :) | 05:53 | |
05:53
Entonian left,
tann_ left
|
|||
japhb | Last time I had some tuits, I was working on porting that bit of packed struct magic to the Perl 6 version (shapes.p6), but there were unfortunately some bits of embedded PIR still required. | 05:54 | |
flip913 | To summarize: A) I want to declare and use a C structure for storage - that should be possible, at least with PIR. Correct? | 05:55 | |
B) C functions can be called from Perl6 - even today? | |||
japhb | flip913, yes, that is possible in PIR. It's just very verbose to do so. | ||
flip913, C function calls do work fine. | |||
flip913, I wrote the OpenGL binding. | |||
05:55
perletc left
|
|||
flip913 | C) Bytecode can be put into a single executable, with pbc_to_exe. | 05:56 | |
japhb | flip913, yes. | ||
flip913 | Can the verbose PIR be generated? I'd think so. Is it slow? Maybe today, but not in a year. (?) | ||
05:57
beggars joined
|
|||
Tene | flip913: item C isn't quite correct. | 05:57 | |
japhb | flip913, There was a GSoC project to parse C headers directly, but it did not reach 100% completion. | ||
Tene | You *can* do it, but the bytecode that's put in the executable *will* try to load libraries from the system. | ||
japhb | Tene, right -- I misparsed his statement. | 05:58 | |
Tene | So it will still rely on rakudo/parrot being installed. | ||
flip913 | Loading of shared objects is not a problem ... that's what will happen anyway, for some other parts that will be needed. | ||
I think that most of (eg. svk's) startup overhead is from parsing the source files - and that's what I need to avoid. | 05:59 | ||
05:59
zamolxes left
|
|||
japhb | OK, must disappear. flip913, good luck! | 06:00 | |
flip913 | Would you think that I should start now in Perl6, or that this will be a dead end? | ||
Tene | flip913: 'sec, posting a list of loaded files... | 06:01 | |
bpetering | thankyou japhb++ and Tene++, that was good | ||
flip913 | Should I rather rewrite in C? | ||
lisppaste3 | tene pasted "list of loaded files for flip913++" at paste.lisp.org/display/85633 | ||
Tene | flip913: depends on when you need results and how much work is acceptable before you get results. | 06:02 | |
flip913: I certainly do think that it's possible, though. :) | |||
flip913 | @tene: as fast as possible, and as least as possible ;-) | ||
lambdabot | Unknown command, try @list | ||
flip913 | tene: as fast as possible, and as least as possible ;-) | ||
Tene | Then rakudo isn't going to be a good choice right now. | 06:03 | |
Rakudo doesn't currently have what you need already implemented. | 06:05 | ||
flip913 | But is it on the list for Rakudo* ? | ||
then it would have been done in the next months anyway. | |||
lisppaste3 | flip913 pasted "untitled" at paste.lisp.org/display/85634 | ||
Tene | I don't think that packed C structs are currently on the list for Rakudo*. I recommend talking to pmichaud to see if it can be added to that list, though. | 06:06 | |
flip913 | Regarding the paste: svk => 0.7 seconds just for loading and parsing perl scripts ... no real work done. | ||
With cached scripts, that is. | 06:07 | ||
Tene | I haven't even seen an actual list for *, so I expect it's likely to have some leeway for additions or suggestions. | ||
flip913 | Well, thanks everybody ... I'll do some research, and plan my new data structures | 06:08 | |
that'll take some time anyway. | |||
Tene | If he (or anyone else, really) feels that packed C structs are necessary for *, they'll work on it, and last I heard, there was still an open request for requests for *. | ||
So, i recommend asking on the ML. | |||
flip913 | OK, I'll send a mail there. Thank you. | ||
Tene | I would be very surprised if you didn't have several answers within a day. :) | 06:09 | |
np | |||
Glad to help | |||
flip913 | So I'll go back to the drawing board, and ask again in 1-4 weeks ... maybe that's done in the meantime. | ||
Thanks! | |||
Bye. | |||
06:09
flip913 left
06:13
beggars left
|
|||
bpetering | Tene: there's a "list" in docs/ROADMAP | 06:18 | |
cj | bpetering: yep | 06:20 | |
06:39
szabgab joined
06:40
sevvie_ joined
06:43
jrtayloriv joined
06:44
finanalyst left
06:54
sevvie left
06:56
finanalyst joined
|
|||
hah | perl6: class A { }; multi sub infix:<+=> (A $a, A $b) { $a.add($b) }; say "END"; | 07:01 | |
p6eval | elf 28026, pugs: OUTPUT«END» | ||
..rakudo 0d4fe0: ( no output ) | |||
07:10
jrtayloriv left
07:11
jrtayloriv joined
07:17
kane__ joined
07:23
frederico_ joined
07:36
frederico left
|
|||
Matt-W | Morning | 07:45 | |
07:47
jrtayloriv left
07:55
athomason joined
07:59
kane__ left
|
|||
sjohnson | hey Matt-W | 08:00 | |
08:07
Su-Shee joined
|
|||
Su-Shee | good morning. :) | 08:07 | |
Matt-W | hi su-shee | ||
Su-Shee looks at 700.000 lines of 11 years of perl... | 08:11 | ||
sjohnson | no hi from matt? maybe if i add more pizzaz to my greetings | 08:14 | |
08:14
PZt joined
08:24
azawawi joined
|
|||
azawawi | hi | 08:24 | |
I am happy to report that Perl 5 (perldoc + perlopref) and Perl 6 (App::Grok) Help Search are working now on Padre trunk. perlopref => Perl Operator Reference | 08:25 | ||
08:33
azawawi left
08:37
reqamst joined
|
|||
Matt-W | :) | 08:39 | |
sjohnson | ( `ー´) | ||
ihrd | hi | 08:40 | |
yath | hm, what's wrong with that? | 08:41 | |
rakudo: my $foo = 23; say $foo.infix:<+>(42); | |||
p6eval | rakudo 0d4fe0: OUTPUT«Statement not terminated properly at line 2, near ":<+>(42);"in Main (src/gen_setting.pm:3390)» | ||
ihrd | yath: NYI in Rakudo, I think | 08:45 | |
yath | is there something like inspect in smalltalk? | ||
Matt-W | I don't think Rakudo can handle calling operators like that | ||
yath | hm | 08:46 | |
Matt-W | It might be something we need STD.pm for | ||
ihrd | yes | ||
yath | rakudo: my $foo = 23; say $foo."infix:<+>"(42); | ||
p6eval | rakudo 0d4fe0: OUTPUT«Method 'infix:<+>' not found for invocant of class 'Int'» | ||
08:48
tlb joined,
masak joined
|
|||
Matt-W | the methods as strings thing is something you do in Parrot, not in Perl 6 | 08:48 | |
08:48
ihrd left
|
|||
Matt-W | For now I think you just have to call operators as operators | 08:48 | |
yath | hm | 08:50 | |
hah | rakudo: class A { has $.a is rw; method add (A $b) { $.a ~ $b.a } }; multi sub infix:<+> (A $a, A $b) { $a.add($b) }; my A $a .=new(a=>"foo"); my A $b .= new(a=>"bar"); say $a.a ~ $b.a; say $a + $b; | 08:52 | |
p6eval | rakudo 0d4fe0: OUTPUT«foobarNull PMC access in find_method()in Main (/tmp/ob4k9xGZ9d:2)» | ||
hah | mhh, this should work? | 08:54 | |
Matt-W | well null PMC access is always a bug | 08:55 | |
but it *looks* like you're trying to do something that should work | |||
file a bug report | 08:56 | ||
yath | huh. hm. funny. say Str.HOW.methods(Str) vs. say Str.HOW.methods(Str).perl | ||
Matt-W | that's because methods returns a list of method objects | ||
yath | the latter only reports [{ ... }, { ... }, { ... }, and so on | ||
Matt-W | which stringify to their names, but when you call .perl on them it tries to do something different | ||
yath | ah | ||
Matt-W | it just gives you a yada block instead | ||
hah | Matt-W, just finished the bug report :) | 08:58 | |
Matt-W | excellent | 09:00 | |
09:11
guest_007 left
09:17
tak11 left
|
|||
tlb | hey, any one know what part of locale specifies file name encoding? | 09:19 | |
Su-Shee | tlb: you mean like LC_COLLATE and so on? I don't think you can specify filenames separately. | 09:20 | |
tlb | Su-Shee, It more what LC_* variable I would have to read to know what the default file name encoding is? | 09:21 | |
Su-Shee, LC_COLLATE is guess is about sorting order/comparing of string? | 09:22 | ||
Su-Shee | tlb: yes. I think LC_CTYPE is the things you probably want. but: iconv can tell you the encoding of a filename. | ||
tlb: because: you can have many encodings in filenames not necessarily complying with the setting of LC* | 09:23 | ||
tlb: I have set everything to utf-8 with LC* but I've got old latin1 stuff lying around and some shift-jist... | 09:24 | ||
tlb | Su-Shee, the best iconv can do is give me a guess, as some encodings are overlapping and the same byte will map to different chars. | 09:25 | |
Su-Shee | tlb: and LC would help you how? :) | ||
09:26
cotto left
|
|||
tlb | Su-Shee, I guess as system default of encodings | 09:26 | |
09:27
cotto joined
|
|||
Su-Shee | tlb: if you set LC*, depending on wether or not the filesystem supports the encoding, all new filenames will be set to this encoding. but not old ones and LC* just tells you the environment setting - not the exact "this filename is encoding xy". | 09:27 | |
tlb | The reason in wondering is because I'm thinking about how readdir should work by default. | 09:28 | |
moritz_ | re | 09:30 | |
tlb | Su-Shee, exactly it's up to the filesystem to decide what's a valid file name and on other platforms such as windows and Mac OS X, the file system defaults to unicode and will disallow non unicode data. | ||
masak | tlb: Unicode is not an encoding. | ||
phenny | masak: 00:11Z <bpetering> tell masak we're duplicating effort... and do my dishes. (masak, that last bit's for phenny.) :) | ||
frettled | masak: good pre-afternoon ;) | 09:31 | |
tlb | masak, sorry UTF8/UCS2 | ||
09:31
frettled sets mode: +o masak
|
|||
masak | frettled: oh hai. | 09:31 | |
frettled | I remember when all we Europeans had to worry about was the ISO Latin alphabet soup. | 09:32 | |
*sigh* | |||
masak | frettled: don't idolize those times. we didn't know better. | ||
Matt-W | but we don't have to worry about anything | ||
or at least, we wouldn't if everything was in UTF-8 | |||
tlb | we still kind of have to because filesystems are lax and don't validate input. | 09:33 | |
some filesystems | |||
masak | I'd settle for everything being in UTF-*. | ||
sjohnson | i think all irc programs and terminals and TERM vars should default to UTF-8 | ||
it would end all war and hunger | |||
that and all other things | 09:34 | ||
Matt-W | modern Linux distros tend to UTF-8 by default | ||
tlb | yes, but Perl 5 still defaults to Latin1 | ||
sjohnson | well, putty or puttytraw, still uses latin1 | ||
tray* | |||
moritz_ | sadly some non-utf-* encoding in legally mandatory in china, or so I've heard | ||
Matt-W | putty defaults to it unfortunately | ||
tlb | so how should readdir work? | 09:35 | |
Matt-W has persuaded his otherwise | |||
tlb | what encoding should it expect the filesystem filenames to be in? | ||
and how about prompt? | |||
what should the default input IO be? | 09:36 | ||
Matt-W | you can't ever expect the filesystem to be anything | ||
tlb | I can on windows and Mac OS X | ||
Matt-W | prompt is much easier to deal with | ||
tlb | and if I use JFS on linux | ||
Matt-W | yeah but who uses those? | ||
:P | |||
tlb | why is prompt easier? | ||
filenames are to some degree just another form of user input | |||
frettled | Matt-W: yes, you would have to worry about something in UTF-8 as well, such as locale specific string equality, sorting etc. | 09:37 | |
09:37
masak left
|
|||
Matt-W | because you can look at terminal configuration and see what encoding it thinks it's using | 09:37 | |
frettled: it's a lesser problem than simply not knowing what encoding to use though | |||
tlb | but can't I do the same for with file system names, libc uses locale and uses that for encoding. | 09:38 | |
Matt-W | frettled: a different layer of problems, actually, because it happens in any multilingual encoding to some extent or other | ||
tlb: you don't know what the ones already there were written in | |||
tlb | The same with prompt if I copy paste text from another document | 09:39 | |
frettled | Matt-W: yes, it's a different layer of problems, but it's still a layer of problems :) | ||
tlb | or what about stdin? | ||
echo "ÆØÅ"| perl6script.pl | |||
frettled | tlb: generally speaking, you cannot assume anything about the encoding of filenames | 09:40 | |
tlb | or cat latin1-file.txt | perl6script.pl | ||
frettled | but in the case of user input, you are in (a semblance of) control at the moment the input encoding is relevant. | ||
tlb | frettled, I would not say thats true, on mac and windows we can, and on most modern unixes locale will tell us to some extent. | 09:41 | |
frettled | tlb: you can what? | ||
Matt-W | no | 09:42 | |
tlb | frettled, Windows only allows UCS2 encoding | ||
Matt-W | modern unix will tell you maybe what filename encoding it's using *now* | ||
frettled | tlb: which version of Windows is that? | ||
Matt-W | it can't tell you what filename encoding was used last week when /home/matthew/wiggle.txt was written | ||
tlb | frettled, Windows XP | ||
frettled | tlb: so you know that all files that were created with Windows XP in NTFS (I presume) were probably written with UCS2 encoding. | 09:43 | |
09:43
payload joined
|
|||
tlb | frettled, on MacOS X with HFS+ it even normalizes the UTF8 encoding. | 09:43 | |
frettled | tlb: yes, and it does it in a different way than we normally use Unicode. | 09:44 | |
tlb: for hysterical raisins | |||
tlb: but you _cannot_ know whether the filename was originally written using that method | |||
also, MacOS X with HFS+ is trying to be semi-case-insensitive. | 09:45 | ||
then you have networked filesystems, such as CIFS/samba, … | |||
tlb | frettled, much like a database where I can specify that encoding on a column, I will always know the encoding is valid. | 09:46 | |
frettled | tlb: and what is the default encoding for filenames in VFAT file systems? | ||
tlb | frettled, it's specified in the FAT, it has an attribute for it. | ||
frettled | tlb: per filename? | ||
tlb | frettled, pr. filesystem | 09:47 | |
frettled | there you go. | ||
*boom* | |||
tlb | CIFS and samba also have pr. filesystem encoding | ||
why? | |||
frettled | ISTR that this was a problem pre-XP, and that I've had filename problems converting from VFAT to NTFS, you see. | ||
tlb: because some files may have been created with a different encoding | |||
that means that something that looks like ø in your original locale will be unprintable in the current | 09:48 | ||
I really, really suggest reading Tom Christiansen's article here: archive.netbsd.se/?ml=perl6-languag...;t=9170058 | 09:49 | ||
tlb | yes and this is very much the still the case today when non UTF8 encodings are used, but still most filesystems and container formats support UTF8/USC2. | ||
Matt-W | they support it, sure | ||
tlb | frettled, I just did and thats why I'm thinking about how readdir should work | ||
Matt-W | but that doesn't mean they're using it | ||
frettled | tlb: but you seem to have missed the point that if I have a filename that was created in, say, KOI8-R encoding, that this doesn't magically become a correct filename when the reading locale is UTF-8. | 09:50 | |
tlb | I know, but if my filesystem would tell be it's not correct UTF-8 I would at least know it should be converted first before I can store it. | 09:51 | |
Su-Shee | (windows uses utf-16 with BOM, as far as I know, not utf-8) | ||
tlb | Su-Shee, it's USC-2 | 09:52 | |
Matt-W | how is the filesystem supposed to know? | ||
frettled | tlb: how can you know it's not correct UTF-8? | ||
tlb | frettled, you right it still might be, as there are overlap in encodings. | 09:53 | |
frettled | tlb: no, not because of overlap. | ||
huf | there's just no way to tell what encoding a bytestream is in | 09:54 | |
and trying to guess leads to pain most of the time | |||
Su-Shee | usally, one examines the first n bytes. | ||
huf | and tries iconv a couple times with the most common encodings :) | ||
tlb | huf, yes we can't guess, that's why we should be able to specify what encoding we wan't to use. | ||
frettled, when I say overlap I mean same bytes can be valid in multiple encodings and have different meanings. | 09:55 | ||
frettled | tlb: aha, I thought you meant _same_ meanings. | 09:56 | |
As in the overlap between UTF-8 and US-ASCII | |||
tlb | the best we can do is use locale on Linux/Unix and FS definitions in windows and MacOSX | 09:57 | |
frettled | Asssumption is the mother of all … | 09:58 | |
tlb | for me at least the whole encoding mess does not stop with strings and stdin/stdout, it's exactly the same with file names and paths. | ||
frettled, we do it with input | |||
frettled | Using locale in a Unix means that you assume that it's a single-user system that only has recent files. | ||
tlb | when opening a file in perl 6 should I always have to define encoding? | 09:59 | |
how about stdin? | |||
frettled | No, you probably shouldn't. | ||
tlb | or should we have some sane default? | ||
frettled | The default should probably be UTF-8. | ||
tlb | why not for readdir as well? | ||
because the number of encoded latin1 files is properly going to be equal to the number of encoded latin1 file names? | 10:00 | ||
frettled | I didn't understand that last question, could you please rephrase it? | ||
What I generally think, is that readdir() etc. shouldn't make any assumption regarding the semantics of the filenames. It would probably be best to handle them as «raw», if at all possible, and then allow for a default interpretation later on. | 10:02 | ||
The default interpretation _could_ be either Perl 6's default Unicode worldview, or it could be the locale. | |||
10:03
mj41 left
|
|||
tlb | if we assume unknown files to be utf8, then one might also assume that the file names would be the same encoding as the data, right? | 10:03 | |
frettled | But using the locale could lead to interesting differences in execution when the program is run as different users on the same system, leading to weird and unexpected results for users. | ||
tlb: how do you define the encoding of a PNG file? | |||
(except for «PNG», obviously) | 10:04 | ||
tlb | frettled, I'm talking about text, not binary | ||
frettled | I wouldn't make that assumption even for «text». | 10:05 | |
tlb | frettled, actually not using locale is weird, if I set my locale to latin1 and Perl reads and writes data in UTF8 I will be unhappy, because most other programs will do the right thing. | ||
but you do for stdin? | 10:06 | ||
frettled | At work, we have systems with UTF-8 as the standard locale, but where customers have installed web application frameworks which accept user input from the web, which can be either e.g. Latin-1 or UTF-8, depending on how it is. Some of these store the content as UTF-8, others as Latin-1, but the filename could still be either, independent of the contents. | ||
Then you have mixed-content files. | |||
tlb: for stdin, you're in the here and now, you're not dealing with historical data. | 10:07 | ||
tlb: okay, you can shoot yourself in the foot and insert historical data through a pipe or redirect, but that's a choice. | |||
tlb | frettled, I hope you at least then store whet file names are encoded in. | ||
frettled | It's reasonable to use locale for stdin, stdout, stderr etc. | ||
tlb: huh? | 10:08 | ||
10:08
mj41 joined
|
|||
tlb | frettled, "Some of these store the content as UTF-8, others as Latin-1, but the filename could still be either" | 10:08 | |
frettled | tlb: yes? | ||
tlb: «where customers have installed…» | |||
not we. | |||
tlb | frettled, how do you know what encoding a file name is in? | ||
frettled | we don't have control over the software. | ||
tlb: we don't. | 10:09 | ||
tlb | frettled, so the customer knows what the encoding is. | ||
frettled | that's the point. | ||
tlb: probably not. | |||
tlb: maybe the application framework programmer knows. | |||
but there's no way to know that _after the fact_. | |||
in a plaintext file, there is no POD-style UTF-8 header. | 10:10 | ||
in a HTML file, there is. | |||
tlb | frettled, I still don't see the difference with cating a file or reading it's name and why that should have different defaults. | ||
frettled | But I repeat: a file may have mixed internal encoding. | ||
tlb: in the case of direct input/output, you «know» what you're dealig with. | 10:11 | ||
unless someone is lying | |||
tlb | same with files if you control them. | ||
frettled | In the case of filenames, nobody can tell you what you're dealing with, because there is no Unix internal format for filenames that's magically translated to the current locale. | 10:12 | |
tlb | frettled, and we have the same problem with file content and stdin | ||
frettled | Anyway, it's nearly fifteen minutes into my lunch, so I'll need to get some grub. I think we're just going around in circles, and that we've both made our points well enough, but it seems we can't really agree. | ||
tlb | frettled, thanks for the talk :) | 10:13 | |
frettled, I got at little smarter, so have a nice lunch. | 10:14 | ||
wayland76 | phenny: tell TimToady Next time I mess up the documentation, feel free to tell me to fix it. If I'm in documentation mode, I can usually find the time | 10:21 | |
phenny | wayland76: I'll pass that on when TimToady is around. | ||
wayland76 | Well, everyone, good news and bad news. The good news is, I've got a new computer. The bad news is, that means I'll have less time for P6 for a bit while I set it up. If you need me, you have my e-mail :) | ||
10:22
xinming_ joined,
wayland76 left
10:24
baest left
10:25
baest joined
10:26
payload left
10:35
xinming left
|
|||
yath | hehe, coo | 10:44 | |
l | |||
"0 but true" is not officially in the syntax %-) | |||
moritz_ | rakudo: say "yes" if 0 but True | 10:45 | |
p6eval | rakudo 0d4fe0: OUTPUT«The but operator can only be used with a role or enum value on the right hand sidein Main (/tmp/AVfPBGW5Hx:2)» | ||
yath | hu? | 10:46 | |
Matt-W | rakudo: say "yes" if 0 but Bool::True | ||
p6eval | rakudo 0d4fe0: OUTPUT«The but operator can only be used with a role or enum value on the right hand sidein Main (/tmp/ut78wbiK18:2)» | ||
Matt-W | hmm isn't Bool::True an enum value? | 10:47 | |
moritz_ | it should be. | 10:49 | |
it's a known bug | |||
jnthn | oh morning | 10:50 | |
uh, morning fail | |||
:-) | |||
jnthn 's sleep patterns are really screwed up | 10:51 | ||
moritz_: Heh, "is Bool and Enum" is one of those things that's gone back and forth a whole load of times. :-) | |||
Matt-W | it is, however, a pretty awesome error message | 10:52 | |
moritz_ | jnthn: I remember it being an enum for at least 1.5 years | ||
Matt-W | what would be even better is if it told you waht the thing on the right actually is | ||
cognominal | hi jnthn | 10:56 | |
read your slides about roles, nice. | |||
10:57
masak joined
10:58
KyleHa left
10:59
KyleHa joined
|
|||
moritz_ had this fascinating idea about visualizing match objects with SVG... but it's gone | 11:01 | ||
masak | moritz_: yes, that does sound cool. | ||
and with a fixed-sized font, the compute-the-text-width problem might go away entirely. | 11:02 | ||
jnthn | cognominal: Happy you liked them. | 11:04 | |
11:05
meppl joined
|
|||
jnthn | OK, so, Rakudo day. :-) | 11:06 | |
git pull && make kavu | |||
masak | YaY | 11:10 | |
Rakudo DaY! | |||
jnthn | Sheesh, the IO thread on p6l lives on! | 11:11 | |
masak | neve underestimate people's ability to bikeshed. | ||
jnthn skips reading | |||
11:12
xomas_ joined
|
|||
masak | what's interesting to me is how many lurkers that kind of discussions pull in. | 11:12 | |
jnthn | Thing is, I don't particularly feel a need for anything all that advanced. | ||
Not in core. | |||
moritz_ | aye | ||
masak | +1 | ||
imagine if all those bikeshedders actually sat down and wrote one Perl 6 module each... and put it on github. | |||
jnthn | If people want to try Amazing Ways To Do Things, Perl 6 is probably about the most malleable language going... | ||
tlb | masak, someone's bikeshed, is another ones palace :) | 11:13 | |
masak | tlb: no matter how hard I try, I won't be able to execute their bikeshedding emails. your analogy is flawed. :) | ||
jnthn | Hmm | ||
Surprisingly, RT didn't break the 500 mark yet. | 11:14 | ||
jnthn is actually genuinely surprised by that. | |||
masak | let's just say we're working on it. | ||
moritz_ | right, I have a bug sitting in my TODO file... | ||
yath | hm, should that one work? | ||
rakudo: sub infix:<☃> (Str $a) { "☃"x($a.length) }; my @x = <5 23 42>; say (@x»☃).perl; | |||
moritz_ | but I wanted to ask first if it's know already | ||
p6eval | rakudo 0d4fe0: OUTPUT«Statement not terminated properly at line 2, near "\x{bb}\u2603).perl;"in Main (src/gen_setting.pm:3390)» | ||
moritz_ | rakudo: 1 ?? 1; | 11:15 | |
p6eval | rakudo 0d4fe0: OUTPUT«ResizablePMCArray: Can't pop from an empty array!in Main (src/gen_setting.pm:3390)» | ||
moritz_ | yath: no, you can't use an infix operator as a postfix for method call | ||
yath | argh | ||
yes, thanks | 11:16 | ||
moritz_ | that's a very much less-than-awesome error message | ||
masak: do you happen to know if it's reported already? | |||
masak | no idea. | ||
jnthn | rt.perl.org/rt3/Ticket/Display.html?id=58574 | ||
yath | anyway | ||
rakudo: sub postfix:<☃> (Str $a) { "☃"x($a.length) }; my @x = <5 23 42>; say (@x»☃).perl; | |||
p6eval | rakudo 0d4fe0: OUTPUT«Statement not terminated properly at line 2, near "\x{bb}\u2603).perl;"in Main (src/gen_setting.pm:3390)» | ||
masak | now, that should be an outright bug. | 11:17 | |
moritz_ | rakudo: my @a = 3..5; say @a>>++ | ||
p6eval | rakudo 0d4fe0: OUTPUT«Statement not terminated properly at line 2, near ">>++"in Main (src/gen_setting.pm:3390)» | ||
jnthn | yath: We only currently implement hyperoperators on infixes. | ||
masak | ah. | ||
jnthn | It's just a NYI. | ||
yath | jnthn: ah | ||
masak | a TODO bug then. | ||
yath | jnthn: thanks | ||
masak | rakudo: A::B.new | ||
p6eval | rakudo 0d4fe0: OUTPUT«Null PMC access in invoke()in Main (/tmp/zlpQMkMgEd:2)» | ||
masak | is this one known? :) | ||
jnthn | masak: Yeah. | 11:18 | |
masak | ok. | ||
definitely a pre-April one, by me. | |||
jnthn | std: A::B.new | ||
11:18
ruoso left
|
|||
p6eval | std 28026: OUTPUT«Undeclared name: A::B used at 1 ok 00:02 37m» | 11:18 | |
masak | STD++ | ||
jnthn | Aww. | ||
Well, it warned, but didn't fail. | |||
So we need to fix the runtime issue anyway. | |||
tlb | mberends, hey Martin, still waiting on access to the parrot-module-lib git | 11:19 | |
jnthn | rakudo: grammar A { token ws { 'a' }; rule b {x y}; }; say 'xab' ~~ m/ ^ <a::b> $ / | 11:20 | |
p6eval | rakudo 0d4fe0: OUTPUT«Null PMC access in get_string()in regex PGE::Grammar::_block59 (/tmp/i4WMgDyC6Z:2)called from Main (/tmp/i4WMgDyC6Z:2)» | ||
jnthn | heh | ||
an error that got worse, not better | |||
rakudo: sub test($test is write) { } | 11:21 | ||
p6eval | rakudo 0d4fe0: ( no output ) | ||
masak | 'is write'? o_O | 11:23 | |
no such thing in the spec. I czeched. | 11:24 | ||
jnthn | masak: Yeah, doesn't exist | ||
masak: The ticket complains about the lack of complaint. | |||
masak | ok. no complaints, then. :) | 11:25 | |
jnthn | rakudo: say (*-1).WHAT | 11:26 | |
p6eval | rakudo 0d4fe0: OUTPUT«WhateverCode()» | ||
moritz_ | rakudo++ | 11:27 | |
jnthn | woo, a closable ticket, and KyleHa++ notes we're passing the tests for it. | ||
masak | KyleHa++ | ||
moritz_ | rakudo: say (+*).WHAT | ||
p6eval | rakudo 0d4fe0: OUTPUT«WhateverCode()» | ||
moritz_ grows more and more fond of the Whatever star | |||
KyleHa | One down, hundreds to go... | 11:28 | |
cognominal | rakudo: say (**).WHAT | ||
p6eval | rakudo 0d4fe0: OUTPUT«Statement not terminated properly at line 2, near "*).WHAT"in Main (src/gen_setting.pm:3390)» | ||
moritz_ | a journey thousand closed tickets begins with a single one :-) | ||
jnthn | KyleHa: Thanks for the encouragement. :-P | ||
KyleHa | I'm up too early for $work. | 11:29 | |
jnthn | masak: rt.perl.org/rt3/Ticket/Display.html?id=62732 is the ticket for that A::B issue you menetioned, I think. | 11:30 | |
masak | ok, goodie. | ||
moritz_ | jnthn: so what's your rakudo day today? bug squashing? | ||
jnthn | masak: I see to remember there was some movement on this issue: rt.perl.org/rt3/Ticket/Display.html?id=62738 | ||
moritz_: I haven't been through the RT queue for like over a month, so I'm starting off by reviewing it. I already found one ticket that we can just close because it's already defalt with... | 11:31 | ||
masak | jnthn: there was. | ||
jnthn | moritz_: And I'm keeping open various ones that I'm going to work on squashing today. | ||
So yes, RT review and bug-fixing. | |||
masak: OK. In a way that makes the ticket closable or updatable? | 11:32 | ||
masak | jnthn: I think it can be closed. | ||
jnthn: Rakudo now follows STD pretty closely. | |||
hah | pugs: class A { has $.a is rw; method add (A $b) { $.a ~ $b.a } }; multi sub infix:<+> (A $a, A $b) { $a.add($b) }; my A $a .=new(a=>"foo"); my A $b .= new(a=>"bar"); say $a.a ~ $b.a; say $a + $b; | ||
p6eval | pugs: OUTPUT«foobarfoobar» | ||
jnthn | rakudo: if 5 > my $a = 4 { say $a } | ||
p6eval | rakudo 0d4fe0: OUTPUT«Unable to set lvalue on PAST::Val nodein Main (src/gen_setting.pm:3390)» | 11:33 | |
masak | the p6-autodetect issue is still a bit unresolved, I think. | ||
jnthn | heh, that error is still non-awesome | ||
masak: Is that a blocker to closing the ticket? It seems more spec-issue than Rakudo issue... | 11:34 | ||
oh, wait, I only read half of what you said :-) | |||
masak | jnthn: no, not a blocker. | ||
jnthn | masak: Do you want to close it with an appropriate note? | ||
masak | sure. | ||
jnthn | Great. | ||
masak++ | |||
masak | occasionally, I close tickets, too. :) | 11:36 | |
11:37
wayland76 joined
11:38
dakkar joined,
Front_slash joined
|
|||
jnthn | masak: There's even the very occasional incidence where I open them. ;-) | 11:38 | |
I stopped sending rakudobug emails after I discovered that there's an automated process where if I post code that exposes the bug on #perl6, a rakudobug magically gets filed though. ;-) | 11:39 | ||
masak | funny how that works. | ||
jnthn | rakudo: my @a = 1..4; say @a[1..*].perl | 11:42 | |
p6eval | rakudo 0d4fe0: OUTPUT«[2, 3, 4, undef]» | ||
jnthn | aww, I thought we'd fixed that one. | ||
masak | tell me again why that one's an error. | 11:43 | |
jnthn | masak: Because normally the * in there ends up geting substituted with .elems | ||
@a.elems in this case | |||
lambdabot | Unknown command, try @list | ||
jnthn | Which is one too many | ||
11:44
araujo left
|
|||
moritz_ | jnthn: yes, and @a.elems is out of bounds, so we get an undef | 11:44 | |
seems pretty intuitive the way it is | |||
masak | same here. | ||
moritz_ | rakudo: my @a = 1..4; say @a[*] | ||
jnthn | Ah, in the end it's decided that Rakudo is correct here? | ||
p6eval | rakudo 0d4fe0: OUTPUT«1234» | ||
moritz_ | note that this is a special case | ||
but a specced one | |||
jnthn | Here is the ticket in question: rt.perl.org/rt3/Ticket/Display.html?id=64566 | 11:45 | |
masak | I think there was a spec clarification about this particular issue. | ||
moritz_ | if we want @a[1..*] to DWIM, we need a spec for it | ||
jnthn | Which suggests the undef is an error. | ||
OK. | |||
I know pmichaud did a bunch of work on postcircumfix:<[ ]> since this came up, so I strongly suspect Rakudo follows spec on this issue. | |||
So IIUC, we should reject the ticket, and remove the tests that assume the undef is wrong? | 11:46 | ||
Or correct and unfudge them I guess.. | |||
moritz_ | wait a sec... | ||
jnthn | OK. | ||
moritz_ | S09:614 mentions @data[1..*] | 11:47 | |
As the end-point of a range, a lone "whatever" means "to the maximum | |||
specified index" (if fixed indices were defined): | |||
say @calendar[5..*]; # Same as: say @calendar[5..11] | |||
say @calendar{Jun..*}; # Same as: say @calendar{Jun..Dec} | |||
or "to the largest allocated index" (if there are no fixed indices): | |||
say @data[1..*]; # Same as: say @results[1..5] | |||
so the ticket is valid after all. | |||
jnthn | moritz_: Ah, so it's a spec'd special case. | ||
masak | yep. S09 has lots of instances of ..* meaning .elems()-1 | ||
moritz_ | and we need a special case | ||
jnthn | OK, fine. | ||
jnthn leaves the ticket intact | 11:48 | ||
11:49
wayland76 left
11:50
Front_slash left
|
|||
jnthn | rakudo: class A {}; class B hides A {} | 11:51 | |
p6eval | rakudo 0d4fe0: ( no output ) | ||
jnthn | one more ticket that I can close | ||
3 tickets closed and I didn't even write any code yet today :-) | 11:52 | ||
masak hides A too | |||
jnthn | class Of-2009 hides TeachersPen { } | 11:53 | |
frettled | tlb: Yes, thanks for the talk, although I find all this charset, locale and conversion stuff deeply annoying, it's because of the awfulness of the problem itself, and not because of your opinions. | ||
jnthn: good post-morning | |||
jnthn | rakudo: sub a { "outer" }; { my sub a { "inner" }; say a }; say a | 11:54 | |
frettled: oh hai | |||
p6eval | rakudo 0d4fe0: OUTPUT«innerouter» | ||
jnthn | \o/ | ||
Now, IIRC we have unfudged a test for tha tbug... | |||
moritz_ | ++ | ||
masak | rakudo++ | ||
frettled | w00t | ||
jnthn | Does anyone else remember that? | 11:55 | |
jnthn doesn't like closing tickets without making sure... | |||
moritz_ | jnthn, masak: just replied to the @a[1..*] ticket with CCing p6l | ||
jnthn: assign it to me | |||
jnthn: I'll take care later on | |||
jnthn | moritz_: You're going to seek clarification on spec issue? OK, thanks. | 11:57 | |
tlb | frettled, I totally agree and I really wish the language/implementation would just do the right thing so I as a programmer would not have to understand it, but I guess if you are making the language/implementation you probably would like it to be the other way :) | 11:58 | |
jnthn | moritz_: Oh, wait, which ticket did you mean? | ||
(To assign to you) | |||
moritz_ | jnthn: assign the lexical subs ticket for me | ||
jnthn: for test verification | |||
frettled | tlb: hee-hee, yes! | ||
moritz_ | jnthn: I asked p6l about the whatever-slice | ||
11:59
dakkar left
12:00
rfordinal left
|
|||
jnthn | perl6: say (0,0,0,0,0,0) >>+>> ((1,2) xx *) | 12:00 | |
rakudo: say (0,0,0,0,0,0) >>+>> ((1,2) xx *) | |||
p6eval | elf 28026: OUTPUT«Parse error in: /tmp/swMws3dhw9panic at line 1 column 0 (pos 0): Can't understand next input--giving upWHERE: say (0,0,0,0,0,0) >>+>> ((1,2)WHERE:/\<-- HERE STD_red/prelude.rb:99:in `panic' STD_red/std.rb:76:in `scan_unitstopper' STD_red/std.rb:224:in `comp_unit' | ||
..STD_red… | |||
..pugs: OUTPUT«***  Unexpected ">>+>>" expecting operator, ":" or "," at /tmp/cMA7GAtHar line 1, column 19» | |||
..rakudo 0d4fe0: OUTPUT«Use of uninitialized valueUse of uninitialized valueUse of uninitialized valueUse of uninitialized valueUse of uninitialized valueUse of uninitialized value000000» | |||
rakudo 0d4fe0: OUTPUT«Use of uninitialized valueUse of uninitialized valueUse of uninitialized valueUse of uninitialized valueUse of uninitialized valueUse of uninitialized value000000» | 12:01 | ||
jnthn | say ((1,2) xx *).WHAT | ||
rakudo: say ((1,2) xx *).WHAT | |||
p6eval | rakudo 0d4fe0: OUTPUT«List()» | ||
jnthn | rakudo: say ((1,2) xx *) | ||
p6eval | rakudo 0d4fe0: OUTPUT«» | 12:02 | |
moritz_ | that should be an infinite list, not a WhateverCode | ||
jnthn | moritz_: Yes | ||
moritz_ | and thus likely blocking on laziness | ||
jnthn | Rakudo gets the List part right, but its infinity is a little small. ;-) | ||
jnthn leaves taht ticket for now | |||
frettled | It is correct for sufficiently small values of infinity? | 12:03 | |
tlb | frettled, but anyways I hope to have some time by the end of the year to start working on some of this stuff instead of just talking about it :) | ||
jnthn | rakudo: multi sub a() { 1; }; multi sub a($x) { $x; }; sub b(&x) { &x() }; b(&a); | ||
p6eval | rakudo 0d4fe0: OUTPUT«Parameter type check failed; expected Callable, but got Multi for x in call to bin sub b (/tmp/OBpwcUWK6U:2)called from Main (/tmp/OBpwcUWK6U:2)» | ||
jnthn | Damm, still br0ke. | 12:04 | |
frettled | tlb: I think that if we first get a working implementation that has some support for choosing what to do, the default can be changed after sufficient bikeshedding ;) | 12:05 | |
jnthn is happy to find he can resovle #65568 though | 12:06 | ||
rakudo: class A { method postcircumfix:<( )>() { 42 } }; my $a = A.new; say $a() | 12:07 | ||
p6eval | rakudo 0d4fe0: OUTPUT«42» | ||
jnthn | masak: Did you ever get to writing tests for the above? | ||
masak | no, I eated them. :/ | 12:08 | |
jnthn | Or hmm, maybe there are some. Maybe we even enabled them. | ||
masak: Did they taste like a cheezburger? | |||
moritz_ | spec/S13-overloading/typecasting-long.t contains one | ||
masak | jnthn: remember we talked about how they're not implemented according to spec in Rakudo right now? | 12:09 | |
the spec talks about a capture or something. | |||
jnthn | moritz_: Yes, and I even tweaked that test file. | ||
moritz_: Rakudo passes it fully. | |||
moritz_ | jnthn: time to add it to spectest.data | 12:10 | |
jnthn | moritz_: Only thing is, I didn't added it...right. | ||
masak: I was having a moment of fail. | |||
masak: sub foo(|$cap) { ... } should always be writable. | |||
masak: That is, you can always choose to have the capture instead of having the args unpacked. | |||
12:10
abra joined
|
|||
jnthn | masak: So it's not that it is passed a capture after all. | 12:11 | |
pmichaud++ pointed that out to me at the hackathon. :-) | |||
masak | oh, ah. | ||
jnthn | (Well, not passed a capture any more than anything else is not passed a capture, if you get my point.) | ||
masak | point gotten. | ||
tlb | frettled, I think you are right, but sometimes the bikeshedding turns up some options and insight that we did not think about before. But I guess after reading the old IO thread, plus the new most of the common pitfalls should be known. | 12:12 | |
moritz_ | bike sheds can crash under the weight of having too many layers of paint. | ||
jnthn | Yay, 14 more passing test. | 12:13 | |
And a ticket that is closble. | |||
12:14
takadonet joined,
dakkar joined
|
|||
takadonet | morning all | 12:14 | |
masak | takadonet: o/ | ||
jnthn | hi tako | 12:15 | |
oops | |||
hi takadonet | |||
masak | I think RT #68664 is a duplicate. | ||
frettled | jnthn: are you hungry again? Freudian slip for taco? | ||
jnthn | frettled: Actually...mmm...I have a good tacos place not too far from here ;-) | ||
moritz_: rt.perl.org/rt3/Ticket/Display.html?id=66120 - is "warning emitted" something testable? | 12:16 | ||
takadonet | question... You can use a grammar to parse a file using 'parsefile' but is there or planning to be a way to write to a file using a grammar in conjunction with an action class? | 12:17 | |
moritz_ | jnthn: not today, no | ||
jnthn | moritz_: Opinion on what to do with the ticket? Leave it open for a day we can? | ||
frettled | mañana | ||
dalek | kudo: 352acd2 | jnthn++ | t/spectest.data: Add S13-overloading/typecasting-long.t to spectest.data - passes in full. |
12:18 | |
frettled | Yikes, rt.perl.org has awful Norwinglish | ||
masak | takadonet: 'write to a file using a grammar...'? please be more specific. | ||
moritz_ | takadonet: you mean some kind of transformation process? | 12:19 | |
takadonet | yes | ||
jnthn | masak: I think takadonet wants to do something like that Grammar::Generative module I've been threatening to write for ages would do. ;-) | ||
masak | jnthn: that was what I suspected. :) | ||
12:20
ruoso joined,
rfordinal joined
|
|||
moritz_ has something very simple in mind, once autoload (or CANDO) works | 12:20 | ||
takadonet | Currently I have a fasta parser that works great (extremely slow) and now I'm in the process of creating a fasta writer | 12:21 | |
moritz_ | bascially a universal method foo($/) { take $/ } | ||
ruoso .oO( who needs autoload when you have metaclasses? ) | |||
moritz_ | that is available under arbitrary names | ||
and can be simply overridden with a user defined method | |||
then you can write something along the lines of | |||
say gather { MyGrammar.parsefile($str, :action(MyGrammar::ActionMethods) } | 12:22 | ||
ruoso | does rakudo allows you to use a custom metaclass already" | ||
? | |||
moritz_ | don't think so | ||
jnthn | ruoso: No. | ||
ruoso | meh | ||
;) | |||
ruoso .oO( evil plans frustrated... ) | |||
jnthn | ruoso: We don't have (a) a way to declare new package declarators and (b) a standard way to associate those with a different metaclass. | 12:23 | |
masak | takadonet: it would be interesting to see some code representing what you would like to have working. | ||
jnthn | (a) waits on PGE improvements, (b) I guess is waiting on spec. | ||
ruoso: Once we have those two, I think we're most of the way there. Probably there'll be some quirks to shake out. | |||
ruoso | jnthn, but I guess there should be a way to do it programatically anyway | ||
I mean | |||
takadonet | masak: Do you know anything about bioperl or fasta file format? | 12:24 | |
ruoso | ClassHOW.create_new_class() or something | ||
jnthn | ruoso: I guess. Just needs spec'ing and implemetning I guess. | ||
ruoso | rakudo: say ClassHOW.^methods.map: { ~$_ } | ||
p6eval | rakudo 0d4fe0: OUTPUT«Method 'methods' not found for invocant of class ''» | ||
jnthn | Heh. :-) | 12:25 | |
12:25
abra left
|
|||
ruoso | mildew: say PrototypeHOW.^methods.map: { ~$_ } | 12:25 | |
jnthn | Meta-circularity fail. | ||
moritz_ | ruoso: care to submit that as a rakudobug? | ||
p6eval | mildew: OUTPUT«Undeclared name: PrototypeHOW used at 1 Could not find variable &PrototypeHOW in the lexical scope.» | ||
ruoso | ah... no map | ||
12:26
macroron joined
|
|||
ruoso | moritz_, I think that's already known... | 12:27 | |
moritz_ | ruoso: known != known | ||
ruoso | rakudo: say ClassHOW.HOW.Str | ||
p6eval | rakudo 0d4fe0: OUTPUT«Method 'Str' not found for invocant of class ''» | ||
ruoso | rakudo: say ClassHOW.HOW | ||
p6eval | rakudo 0d4fe0: ( no output ) | ||
ruoso | moritz_, I mean... it's not a bug in specific... it's a feature milestone | 12:28 | |
masak | takadonet: yes. I've used BioPerl, and I read/write FASTA at $work. | ||
hah | pugs: class A { }; class B { }; multi sub infix:<+> (A $a, B $b) | (B $b, A $a) { say $a ~ $b }; say "OK"; | ||
p6eval | pugs: OUTPUT«***  Unexpected "|" expecting bare trait, trait or block at /tmp/H6Ik4Ot8dZ line 1, column 60» | ||
hah | std: class A { }; class B { }; multi sub infix:<+> (A $a, B $b) | (B $b, A $a) { say $a ~ $b }; | 12:29 | |
p6eval | std 28026: OUTPUT«ok 00:03 42m» | ||
ruoso | rakudo: say ClassHOW.new; | 12:30 | |
p6eval | rakudo 0d4fe0: OUTPUT«ClassHOW()<0xb557d730>» | ||
ruoso | rakudo: my $a = ClassHOW.new; $a.add_method(Method.new()) | ||
p6eval | rakudo 0d4fe0: OUTPUT«No applicable methods.in Main (/tmp/STbueEItQU:2)» | ||
masak | std: multi sub infix:<+> (A $a, B $b) | (B $b) {} | 12:31 | |
p6eval | std 28026: OUTPUT«===SORRY!===Invalid typename A at /tmp/Wa0eDInyWy line 1:------> multi sub infix:<+> (A⏏ $a, B $b) | (B $b) {}FAILED 00:03 41m» | ||
masak | std: class A {}; class B {}; multi sub infix:<+> (A $a, B $b) | (B $b) {} | ||
p6eval | std 28026: OUTPUT«ok 00:03 40m» | ||
12:31
KyleHa left
|
|||
masak | TimToady: maybe STD.pm should at least warn here? | 12:32 | |
takadonet | masak: I would want something similar to: fasta::Grammar.writefile($filename,@seq_objects,:action(Actions.new)); | ||
masak | takadonet: yes, I'm with you so far. | ||
takadonet: my feeling is that a grammar doesn't contain enough information to format things. | |||
takadonet: that's what Form.pm is for. | 12:33 | ||
ruoso | jnthn, hmm... it seems ClassHOW only implements the read-only part of the API... | ||
jnthn | ruoso: Right. | ||
Matt-W | masak: Form.pm is only for certain kinds of formatting... | ||
masak | Matt-W: granted. | ||
moritz_ | takadonet: templates and grammars are somewhat inverse concepts - so far I haven't seen a successful unification of both | ||
ruoso | jnthn, so the class building process is happening entirely in low-level? | ||
12:33
wayland76 joined
|
|||
takadonet | moritz_ : yet :) Not saying that I would but one day | 12:34 | |
jnthn | ruoso: Indeed. I've already refactored things so we actually create the metaclass - right at the start of the class declaration. | ||
takadonet looks at jnth | |||
jnthn | ruoso: So now it's mostly a simple matter of refactoring. :-) | ||
ruoso | jnthn, so you still misses refactoring that before being able to have other package_declarators | ||
jnthn | ruoso: Right, but I rather suspect that'll land a while before being able to have other package_declarators. | 12:35 | |
12:35
sri_kraih_ left
|
|||
ruoso | jnthn, I presume that should be a problem on using other representations as type objects | 12:35 | |
12:36
macroron left,
macroron joined
|
|||
jnthn | ruoso: How so? | 12:36 | |
12:36
macroron left,
macroron joined
|
|||
jnthn | Though admittedly, while I'm quite hpoeful of custom metaclasses in Rakudo *, alternative representations may come after that. | 12:36 | |
ruoso | because as you do it in low-level, you can only build one type of object (P6Object, I guess) | ||
12:36
sri_kraih joined
|
|||
jnthn | ruoso: Right, that's why we need to refactor class building to all go through the metaclass. | 12:37 | |
ruoso | if I might say so... metaclasses are a "must have" for rakudo to be really "usefull" | ||
jnthn | Not really. | 12:38 | |
ruoso | people is already too much used to them in Moose | ||
there are already a lot of neat tricks done by metaclasses in CPAN | |||
jnthn | Everyone can pick a feature and say "Rakudo * won't be useful if it doesn't have X". | ||
takadonet | thanks for answering my question guys | ||
ruoso | sure... | 12:39 | |
it's just that this X gets my vote ;) | |||
jnthn | But anyway, as I said, I think we've a good chance of having custom metaclasses in Rakudo *. | ||
12:39
wayland joined
|
|||
jnthn | And certainly, between now and then we'll stop doing class building at the low level. | 12:39 | |
Because it's just, well, messy. | 12:40 | ||
And forces us to write more of Rakudo in PIR rather than in Perl 6. | |||
Which is undesirable. | |||
frettled | jnthn: Rakudo * won't be useful unless I have a well-working Emacs mode for Perl 6 ;) | ||
jnthn | frettled: That might just be out of the scope of Rakudo. :-P | ||
frettled | jnthn: Darnit! | 12:41 | |
12:41
wayland76 left
|
|||
jnthn | ruoso: But anyway, your vote is registered. | 12:41 | |
moritz_ | frettled: renomarlist and another guy have been discussion that recently | ||
takadonet | frettled: I need an Emacs mode! | ||
moritz_ | (forgot the name) | ||
jnthn | I think it was wolverian. | ||
moritz_ | searching the irc logs should help | ||
12:41
wayland is now known as wayland76
|
|||
frettled | jnthn: Then again, I'm of the opinion that it might have been an okay-ish idea to have had a Rakudo RC «published» already, just for the publicity. | 12:41 | |
takadonet: me, too, but I don't know how to fiddle with it. | 12:42 | ||
takadonet | frettled: I do, actually doing it right now, but I don't have the time | ||
frettled | takadonet: I think it was masak who mentioned to me that cperl-mode does a fair job at it, but it's a bit lacking in keywords and some syntax understanding. | ||
takadonet: but you could make MILLIONS (<small>of braincells</small>) happy! | 12:43 | ||
wayland76 | Just a comment, all, about the IO bikeshedding -- this is actually resulting in spec changes. Also bogons, but I try to keep those to a minimum | ||
takadonet | frettled: I been using Padre for my perl6 and it works fine for now. I might just make a plugin with some key binding from emacs for Padre | ||
frettled | wayland76: mm :) Remember, the collective IQ of a group is equal to the lowest IQ of any individual in the group, divided by the number of group members. :D | 12:44 | |
wayland76 | frettled: True. That's why I participate in the discussion, but do the spec modifications myself :) | ||
szabgab | takadonet, talk to TeeJay, he already started working on emacs keybinding | ||
for Padre, that is | 12:45 | ||
takadonet | szabgab: Thanks | ||
jnthn | moritz_: I think 68672 and 58574 are the same issue... | 12:46 | |
Ok to merge? | |||
moritz_ | jnthn: yes | 12:47 | |
(wasn't aware of the older ticket) | |||
jnthn | rakudo: class A { method foo {"A.foo"} }; class C { has A $.a handles *; }; my C $c .= new; say C.foo | 12:50 | |
p6eval | rakudo 0d4fe0: OUTPUT«Null PMC access in find_method()in Main (/tmp/M3jeQnAsqQ:2)» | ||
jnthn | rakudo: class A { method foo {"A.foo"} }; class C { has A $.a handles *; }; my C $c .= new; say $c.foo | ||
p6eval | rakudo 0d4fe0: OUTPUT«A.foo» | ||
jnthn | oh | ||
it's Yet Another Case of trying to get an attribute from a type object. | 12:51 | ||
(already ticketed) | |||
moritz_: Merged, thanks. | 12:52 | ||
OK, so after reviewing the ticket queue, we're now down from 470 to 463 tickets by closing ones for stuff that's already fixed up. | 12:53 | ||
(ticket review)++ | |||
masak | jnthn++ | 12:54 | |
jnthn | OK, now I actually have to do some real work and fix stuff. :-) | ||
12:56
macroron left,
macroron joined
12:59
macroron left
|
|||
bpetering | what is the semantic difference between the parsefile($str, :action(MyGrammar::ActionMethods), e.g., | 13:04 | |
sorry, pastefail | |||
what is the semantic diffence between the colon in foo($bar, :action(blah)) and $str.subst(/.../, '', :g) ? | 13:05 | ||
jnthn | bpetering: Both specify a named parameter; :g is equivalent to :g(True) | ||
13:06
Su-Shee left
|
|||
bpetering | ah, thanks jnthn :) | 13:06 | |
i need to create a list of "syntax bits => spec term" mappings | 13:07 | ||
moritz_ | S02/Literals describe them | ||
"colon pairs" | |||
wayland76 | Question -- when reading filenames-as-Buf from the filesystem, do we need to know the locale, or only the encoding? | 13:12 | |
moritz_ | neither | 13:14 | |
masak | because we're reading bytes. | ||
moritz_ | only when we decode to Str we have to know/assume/guess the encoding | 13:15 | |
bpetering | Buf is a bunch of bytes? ;bbb | ||
wayland76 | Oh, wait, EINCOMPLETEQUESTION | ||
frettled | Hmm, hee-hee: with Rakudo, the following takes a loooong time (long enough that I don't want to wait): my @ascii = ' '..'~'; | 13:16 | |
wayland76 | Yeah, that's the thing. When we want to convert to Str, do we need to know the locale, or just the encoding? | ||
frettled | I have a suspicion that the range may not be ASCII-based, but I've failed to find anything about it in the synopses; my mistake, I guess. | ||
wayland76: perhaps we only need to know when we output from the Str? | 13:17 | ||
wayland76 | frettled: Possibly. But when we need to know that, do we need to know the locale, or just the encoding :) | ||
wayland76 is a stuck record :) | |||
frettled | wayland76: yeah :D | 13:19 | |
wayland76 is an apologetic stuck record, hoping for a useful answer :) | |||
frettled | wayland76: it seems to me that we need a property for strings that specify the encoding | ||
Matt-W | well strings internally are unicode of some sort, so a string range would range over unicode... | ||
moritz_ | frettled: NOOOOEEEZ | ||
frettled | :D | ||
moritz_ | Str objects are encoding unaware | ||
wayland76 | moritz_: I agree | 13:20 | |
frettled | quite :) | ||
moritz_ | so are Buf objects (mostly) | ||
wayland76 | I thought Str were all aware that they were utf-8? :) | ||
moritz_ | the only thing that needs to be aware of encodings is the encoding and decoding process | ||
tlb | wayland76, hmm, only encoding, I guess the only thing locale will add is how we compare and sort the string and we need more than one to do that. | ||
moritz_ | wayland76: you're trying to raise my blood pressure, are you? :-) | ||
wayland76 | tlb: Beautiful! Thanks :) | 13:21 | |
wayland76 is no longer a stuck record | |||
moritz_ | wayland76: perlgeek.de/blog-en/perl-6/strings-...ffers.html if you haven't read that already | ||
wayland76 | moritz_: No, I'm not trying to raise your blood pressure, I'm just confused :) | ||
tlb++ | 13:22 | ||
moritz_ | wayland76: Str's are Unicode text strings. The user doesn't ahve to care how they are stored internally | ||
frettled | moritz_: sorry for not marking it better as a joke, I shouldn't be chatting on IRC while being busy at work. | ||
moritz_ | wayland76: and UTF-8 is just a way to store Unicode, but not the only one | ||
wayland76 | moritz_: That was what I was trying to say, but I was semi-ignorant as usual :) | 13:23 | |
Is it just me, or are others having trouble with with commits to svn.pugscode.org ? | 13:24 | ||
frettled | In particulary, UTF-8 is a way of cramming Unicode into 8-bit entities, which has become popular because of all the code out there working with 8-bit chars or somesuch. | ||
Matt-W | UTF-8 is particularly popular in english-speaking countries because 7-bit ascii sits inside it perfectly | ||
wayland76 | frettled: We need a new channel policy. All jokes should be marked with <joke>Why did the chicken...</joke> from now on :) | ||
frettled | IIRC, there was a rather widespread agreement that UCS-2 or UTF-16 was better suited to the task technically speaking, but someone wanted compatibility with this bytechar-thingy. | 13:25 | |
wayland76: haha | |||
Matt-W | and thus lazy programmers can continue pretending that 1 byte = 1 character, and not care that it blows up when they try to use some other language | ||
frettled | Matt-W: mm, and that's also why it's such a huge PITA, because it crashes horribly with the ISO Latin charsets. | ||
wayland76 | I'm somewhat familiar with UTF-8 and UCS-2, but like not having to worry about them :) | ||
Matt-W | frettled: that's just mixing encodings, never fun and always painful | ||
moritz_ | frettled: basically that turned out to be an illusion too, because UTF-16 isn't a fixed width encoding either. UTF-32 is, though | 13:26 | |
13:26
_jaldhar joined
|
|||
frettled | moritz_: yep, there are mixed blessings with UTF-16, too, but apparently quite a few people though it would be better. I was of the UTF-32 persuation. | 13:27 | |
moritz_: …and considered the possibility of using loss-less compression to handle the wasted memory/storage space, rather than trying to solve it with a chained encoding. | 13:28 | ||
wayland76 | The thing I like about UTF-8 is that it's infinitely extendable :) | ||
frettled | Currently, I'm more of the «meh» persuation. | ||
moritz_ | wayland76: uhm, it's not | ||
tlb | moritz_, how about UCS-2 it's that fixed width, and a subset of what can fit in full Unicode? | ||
wayland76 | moritz_: Well, but it could be easily made that way :) | ||
PerlJam | moritz_: wayland76's idea of infinity is just a little smaller than yours, that's all :) | ||
good morning all | 13:29 | ||
moritz_ | tlb: yes, just like ASCII is a subset of Unicode, in some sense | ||
wayland76 | Can't you keep adding bytes with the high bit set to extend UTF-8? | ||
moritz_ | wayland76: no, each continuation byte uses one less bit to store actual information | ||
wayland76 | moritz_: Ok, so I'm wrong again. Sorry. | 13:30 | |
moritz_ | wayland76: no worries, I'm happy to rectify some wrong ideas about character encodings :-) | ||
wayland76 | I guess that's a good example of why I like to let Perl 6 worry about it for me :) | ||
tlb | moritz_, yes that I understand, but asked in another way, will I in every case be able to convert a UTF-8 string to UCS-2? | ||
moritz_ | tlb: that's not easy to answer... | ||
tlb: because Unicode cheats... | 13:31 | ||
tlb: character larger than 2**16 can be encoded as pairs of surrogates | |||
tlb | moritz_, also in UCS-2? | ||
wayland76 | It's only 11:30, but I think it'd be a good time for me to go to bed. 'night all | 13:32 | |
moritz_ | tlb: surrogates are a concept defined above the encoding level | ||
tlb: there are codepoints reserved for that | |||
frettled | wayland76: sleep tight | ||
moritz_ | tlb: so it's technically even possible to encode surrogate pairs in UTF-8 (but I think that's discouraged or disallowed) | ||
wayland76: good night | |||
13:33
bpetering left,
payload joined
|
|||
moritz_ | tlb: so you can encode every unicode codepoint as either a single UCS-2 double-byte or a pair of surrogates which can represent a single character | 13:34 | |
if you do that, it's effectivly a varying-width encoding again | |||
tlb | moritz_, so It should be possible to represent the same thing in both UTF-8 and UCS-2? | 13:35 | |
moritz_ | tlb: if the software on top of that handles surrogate pairs correctly, yes | 13:37 | |
13:39
jaldhar left
|
|||
jnthn make spectest's fixes for two rakudobugs and makes lunch | 13:39 | ||
tlb | moritz_, ok, thanks :) | 13:40 | |
jnthn | Does anyone else get a fail in t\spec\S02-names\identifier ? | ||
wolverian | frettled: not sure if this was mentioned, but there's a hacked up cperl-mode.el in pugs's util/ directory | 13:41 | |
frettled: all credits to renormalist for it. | |||
moritz_ | jnthn: no, all fine here | 13:42 | |
masak | jnthn: not I. | ||
jnthn | rakudo: use Test; my ($x); sub my($a) { $a + 17 }; $x = 5; is my($x), 23, 'works' | ||
p6eval | rakudo 0d4fe0: ( no output ) | ||
jnthn | rakudo: use Test; my ($x); sub my($a) { $a + 17 }; $x = 5; is my($x), 23, 'works' | ||
masak | jnthn: oh wait. yes, test 15 fails. | ||
p6eval | rakudo 0d4fe0: ( no output ) | ||
masak | but it's a TODO. | ||
jnthn | masak: Yes, but here it really fails. | 13:43 | |
(Null PMC Access) | |||
masak | :-O | ||
not here. | |||
moritz_ | it's fine here (linux amd63, rakudo 352acd26523712507cbb08e636e852d884744688) (ie fail but TODO, not dying) | ||
jnthn | That's really odd. | 13:44 | |
I can't see anything I'd have changed to influence that. | |||
jnthn lets the spectest run complete and maks lunch | 13:45 | ||
frettled | wolverian: thanks, I'll look at that one. | 13:46 | |
moritz_: amd63 seems like an interesting platform ;) | |||
13:47
sri_kraih_ joined
|
|||
moritz_ | frettled: oh, it's actually ++amd63 :-) | 13:47 | |
or maybe the last bit is defect.. :) | |||
frettled | jnthn: I'm running spectest on the Ubuntu system I've got access to, I'll let you know if it fails. | ||
moritz_: it seems like all bits must be defect, i.e. inverted from their expected state. | 13:48 | ||
13:49
finanalyst left
|
|||
frettled | jnthn: seems like it's passing under Ubuntu something, Linux 2.6.24 x86_64 and glibc 2.7 | 13:53 | |
PerlJam | masak: Where did you get the HTTP::Daemon that you are using? I just tried the first command line from use.perl.org/~masak/journal/39475 and rakudo complains thusly: Method 'recv' not found for invocant of class 'Failure' | 13:56 | |
I'm using the HTTP::Daemon from perl6-examples | 13:57 | ||
masak | PerlJam: that one's slightly outdated. | ||
the last one can be had from gitorious, or via proto. | |||
PerlJam | okay, thanks. | ||
masak | hold on, I'll get you an URL. | ||
gitorious.org/http-daemon | 13:58 | ||
PerlJam | I can google faster than whatever you did :) | ||
masak | :) | ||
PerlJam | btw, you might want to mention that URL in the journal entry | 14:00 | |
masak | good idea. | 14:02 | |
masak does that | |||
14:02
sri_kraih left,
unitxt left
14:03
rfordinal left,
sri_kraih joined
|
|||
masak | there, post updated. PerlJam++ | 14:07 | |
PerlJam: so, when do we get to see your cool webapp? :) | |||
14:10
nihiliad joined
14:14
unitxt joined
14:19
sri_kraih_ left
14:22
alester joined
|
|||
pmichaud | Good morning, #perl6 | 14:24 | |
Matt-W | hi pmichaudd | 14:26 | |
jnthn | hi pm | ||
masak | hello pmichaud | 14:27 | |
14:29
zloyrusskiy left
14:30
KyleHa joined
|
|||
pugs_svn | r28027 | jnthn++ | [t/spec] Skip a test that we were todo'ing before - suspect that we got lucky with the register allocator and avoided a Null PMC Access, not emitting two .lex directives for the same variable is just wrong. | 14:39 | |
14:40
dakkar left,
dakkar joined
|
|||
pugs_svn | r28028 | jnthn++ | [t/spec] Unfudge tests for subs with return types being able to fail. | 14:40 | |
r28029 | jnthn++ | [t/spec] Unfudge test for ord('') - now returns a Failure rather than throws an exception. | 14:41 | ||
dalek | kudo: 0bc70da | jnthn++ | src/parser/actions.pm: Initial fix to allow fail() to work in subs with return type constraints. Will need review when we handle lower-cased types, or maybe if we can move ACCEPTS from P6object into Rakudo now after the release and tweak it to do the right thing. Anyway, it's a working solution for now. |
||
kudo: 33e3839 | jnthn++ | src/setting/Any-str.pm: ord should fail if passed a string of zero length, not die. |
|||
KyleHa | Yay for fail()! | ||
jnthn | KyleHa: Heh, I actually tried to do the second of those fixes first, and then realized I also needed to do the other one. ;-) | 14:42 | |
14:43
Psyche^ joined
|
|||
KyleHa | I'm looking for someone to name the new release. | 14:44 | |
14:44
Patterner left,
Psyche^ is now known as Patterner
|
|||
jnthn | KyleHa: Has you not a PM group? | 14:52 | |
KyleHa | jnthn: I named the last release. | 14:53 | |
I figured someone else ought to name this one. | |||
My last resort is to take one of the names in the release guide. | 14:54 | ||
jnthn | Ah, OK. :-) | 14:55 | |
rakudo: package A {}; A::method_that_does_not_exist | |||
p6eval | rakudo 0d4fe0: OUTPUT«Null PMC access in invoke()in Main (/tmp/QCwG0t5Unh:2)» | ||
pmichaud | TimToady: ping | ||
jnthn | Locally I know have that giving invoke() not implemented in class 'Undef' - improvement methinks. :-) | ||
Though we may at some point might want to spot "invoke not implemented" exceptions and re-write the message... | 14:56 | ||
masak | nod. | 14:58 | |
pmichaud | (name) PDX.pm is a good choice. They did a Rakudo hacking session earlier in the year (or maybe even last year) | 14:59 | |
KyleHa | Thank you pmichaud++ | ||
jnthn | rakudo: package Empty { }; &Empty::no_such_sub | 15:00 | |
rakudo: package Empty { }; &Empty::no_such_sub.WHAT | |||
p6eval | rakudo 0d4fe0: ( no output ) | ||
jnthn | rakudo: package Empty { }; &Empty::no_such_sub() | ||
masak | Rakudo PDX. I like. | 15:01 | |
p6eval | rakudo 0d4fe0: OUTPUT«invoke() not implemented in class 'Undef'in Main (/tmp/3ujfGrwkBg:2)» | ||
jnthn | rakudo: package Empty { }; Empty::no_such_sub() | ||
mkelly32 | rakudo: package Empty { }; &Empty::no_such_sub.WHAT.say | ||
p6eval | rakudo 0d4fe0: OUTPUT«Null PMC access in invoke()in Main (/tmp/CfQ9CxZQa8:2)» | ||
rakudo 0d4fe0: OUTPUT«Failure()» | |||
jnthn | heh, the & made it all OK. ;-) | ||
rakudo: package Empty { }; Empty.no_such_sub_or_prop | 15:02 | ||
p6eval | rakudo 0d4fe0: OUTPUT«Method 'no_such_sub_or_prop' not found for non-object» | ||
jnthn | ...wow! | ||
moritz_ | what is a non-object? :-) | ||
pmichaud | afk for a while :-| | 15:03 | |
KyleHa | The release guide says to review the RT queue for tickets that might need resolving. What qualifies? | ||
PerlJam | KyleHa++ good question. | 15:04 | |
[particle]1 | anything by masak O_o | ||
15:04
[particle]1 is now known as [particle]
|
|||
PerlJam | (I'm glad you're asking it before I do the October release :) | 15:04 | |
masak | :) | ||
moritz_ | KyleHa: tickes with sufficiently large impact to be worth making trouble for :-) | 15:05 | |
KyleHa | moritz: So it's a judgement call? | ||
masak | *cough* #58392 *cough* | ||
moritz_ | KyleHa: aye | ||
masak | (don't bother checking that one, it was closed a year or so ago. pmichaud++) | 15:06 | |
moritz_ | KyleHa: RT #68636 might be such a thing. If nobody fixes it up to the release, it's at least worth a mention in README | ||
KyleHa | I was wondering about that one, actually. | ||
moritz_ | maybe we can get pmichaud++ to comment on that one when he's back from AFK (is AFK close to PDX? :-) | 15:07 | |
pmichaud | moritz_: the short answer is that 'make install' creates a perl6 that can be moved. | 15:08 | |
i.e., the issue is that the dynlibs aren't put into the parrot locations until after 'make install' | 15:09 | ||
moritz_ | pmichaud: so the answer is "won't fix"? | 15:10 | |
pmichaud | it's not technically broken :-) | ||
moritz_ | I know | ||
pmichaud | I agree we should have a working --prefix to Configure.pl | ||
moritz_ | good. | ||
15:10
payload left
|
|||
moritz_ | I can change the subject of that bug later on | 15:10 | |
jnthn | rakudo: sub foo { EN::a; }; say "alive"; foo; | ||
p6eval | rakudo 0d4fe0: OUTPUT«aliveNull PMC access in invoke()in sub foo (/tmp/GBBKdYrWkM:2)called from Main (/tmp/GBBKdYrWkM:2)» | ||
jnthn | tests++ | 15:11 | |
pmichaud | it would be good to have a mention in NEWS that people who are relying on moving the perl6 executable to a different location also need to move the dynlibs into the appropriate parrot location | ||
jnthn | I think just telling people to make install now is fine. | ||
moritz_ | pmichaud: moving != using from a different path | ||
pmichaud | moritz_: good point. But it's the same issue. | 15:12 | |
moritz_ | pmichaud, jnthn, KyleHa: ok, we have consensus. That's good :-) | ||
pmichaud | we can also perhaps create a 'make install_dynlibs' target that copies the dynamic libraries into the correct location (more) | ||
jnthn | Yes, it's a change from what people are used to, but it's just a case of people being told (IMO worth noting in the release announcement, or at least noting a pointer to the README). | ||
pmichaud | but I agree with jnthn that recommending 'make install' is good | ||
I definitely think it's worth a mention in the announcement | |||
if someone wants to draft something up I'll review it; if nobody drafts anything I'll write it (but it'll be much later in the day) | 15:13 | ||
bbl | |||
jnthn | pmichaud: Aye, either in full detail or a pointer to where to read the full detail. | ||
pmichaud | okay, I have to run | ||
jnthn | But not in the docs/ directory, or everyone will find my password list^W^W^W^Wread it. | ||
moritz_ | announce + README seems sensible | ||
jnthn | Aye, I think so too. | 15:14 | |
jnthn spectests fixes that he hopes will resolve 3 more RT tickets. | |||
KyleHa | I'm up to translating git log into ChangeLog. | 15:15 | |
I noticed there's already a lot of ChangeLog "stuff". | |||
jnthn | rakudo: class A::C {}; A::B.foo | ||
p6eval | rakudo 0d4fe0: OUTPUT«Null PMC access in invoke()in Main (/tmp/CcuCjZpfNn:2)» | ||
jnthn | s/3/4/ :-) | ||
KyleHa | Does that mean it's done, or should I keep scratching my head? | 15:16 | |
jnthn | KyleHa: Is latest ChangeLog pushed? | ||
KyleHa: I'll take a look at it. | |||
KyleHa | jnthn: The one I'm looking at is. 8-) | ||
jnthn | KyleHa: OK, cool. (I meant to ask if you had local changes to push...) | ||
KyleHa | So far, I just have changes to release_guide.pod. | 15:17 | |
jnthn | masak: Does this one relate to the other ticket you resolved earlier: rt.perl.org/rt3/Ticket/Display.html?id=66394 | 15:18 | |
moritz_ | KyleHa: I did it up to 2009-08-14 | ||
jnthn | masak: Are there still issues here? | ||
masak looks | |||
yep, same thing. should I resolve or mark as duplicate? | |||
jnthn | masak: Resolve | 15:19 | |
masak: If the related one was resolved, which it was, yes? | |||
masak | aye. | ||
jnthn | OK, resolve. :-) | ||
masak: Doing so will bring us down to 460. | |||
(We started the day on 470 :-)) | |||
masak | \o/ | 15:20 | |
KyleHa | 34 tickets resolved since the last release. Does that sound right? | 15:22 | |
I guess I should search for tickets resolved since then and created before then. | |||
jnthn | KyleHa: Heh, yes, but I'm about to resolve 4-5 more of them I think. ;-) | 15:23 | |
KyleHa | jnthn: Yeah, I figured. I just kinda want to get my search down so it's ready to go when I go to document the release. | 15:24 | |
25 earlier tickets resolved in this release. Nice. | 15:25 | ||
15:27
jferrero joined
|
|||
KyleHa | Still-open tickets created since the last release...oh...oh, my. | 15:30 | |
jnthn | lol | 15:31 | |
If I encouraged you to put that number in the release announcement, it'd be rather masakistic. | |||
;-) | |||
KyleHa | Heh. | ||
15:31
hercynium joined
|
|||
masak | :P | 15:32 | |
my Parrot doesn't build :( | |||
[particle] | submit a bug report :P | 15:33 | |
masak | maybe I should. | ||
ISTR I had trouble logging into the Parrot Trac site, though. | |||
something sends me in an infinite redirect loop. | 15:34 | ||
oh well, I could bisect in the meantime, I guess. | 15:36 | ||
15:36
jjore left
|
|||
dalek | kudo: 96f54dd | jnthn++ | t/spectest.data: S29-conversions/ord_and_chr.t needs ICU, so mark it as such. |
15:37 | |
kudo: 9729b05 | jnthn++ | src/parser/actions.pm: Add a few :viviself's to resolve various Null PMC exceptions (4 individual RT tickets closed by this). |
|||
kudo: 201ffc2 | jnthn++ | src/ (4 files): Final push on converting new ['Failure'] to '!FAIL'(). Allows RT#58646 which set out this task to be closed. |
|||
pugs_svn | r28030 | jnthn++ | [t/spec] Four unfudgings for Rakudo thanks to elimination of a bunch of Null PMC Access errors. | 15:42 | |
jnthn | And then there were 455... | 15:44 | |
masak: Parrot had some pretty big changes as a result of a few merges of branches that made some quite big changes. | |||
As in, some of the branches individually changed a bit. | |||
masak | maybe I could ask someone here on #perl6 to submit a Parrot TT for me. I have no idea how to fix my infinite redirect issue in Trac. | 15:47 | |
moritz_ | sure | ||
masak | in a couple of moments I will know the first SVN revision number that causes the build failure for me. | ||
moritz_: thanks. it's r40656. the error is this: gist.github.com/170402 | 15:48 | ||
moritz_ | is that MacOS X? | 15:50 | |
masak | yes. | ||
15:57
mikehh left
|
|||
moritz_ | masak: trac.parrot.org/parrot/ticket/934 | 15:58 | |
masak | moritz_: dziekuje. | ||
jnthn | masak: Which language? | 15:59 | |
masak | jnthn: Polish. | ||
jnthn | masak: Thought it might be. :-) | ||
15:59
carlin_ left
|
|||
jnthn | masak: It looked familiar but not quite right. ;-) | 16:00 | |
masak | jnthn: couple of years ago, I fell in love with a board game, whose major player base was in Poland. I hung out a lot on a Polish play site that summer. | ||
jnthn | rakudo: sub foo ($a where 5) { say "hi" }; foo(42); | ||
p6eval | rakudo 0d4fe0: OUTPUT«Parameter type check failed; expected [Any, { ... }], but got Int for $a in call to fooin sub foo (/tmp/n1TzfjihqM:2)called from Main (/tmp/n1TzfjihqM:2)» | ||
KyleHa | My last spectest run says a couple of TODO tests passed. | ||
jnthn | KyleHa: orly? | 16:01 | |
moritz_ | masak: was that druid? ;-) | ||
KyleHa | I'm looking deeper... | ||
masak | moritz_: no, way before that. same family of games, though. | ||
jnthn | KyleHa: I've been unfuding various things today, but may have missed the odd one. | ||
ooh I fixed a moritzticket. | 16:02 | ||
16:03
justatheory joined,
rfordinal joined
|
|||
KyleHa | rakudo: No::Such::Grammar.parse() | 16:04 | |
p6eval | rakudo 0d4fe0: OUTPUT«Null PMC access in invoke()in Main (/tmp/E9p9Iehavn:2)» | ||
moritz_ | well, I do submit tickets now and then ;-) | ||
KyleHa | That one now says 'invoke() not implemented in class Undef' instead. | 16:05 | |
I'd say that's still kind of a stinky error message, though. | |||
moritz_ | it is ;-) | ||
jnthn | KyleHa: It's a big improvement over Null PMC Access. :-) | ||
KyleHa: And other than s/invoke/postcircumfix:<( )>/ it's essentially correct. | 16:06 | ||
KyleHa | Man, S10-packages/basic.t is quite a snake pit. | 16:08 | |
16:09
jjore joined
|
|||
jnthn | KyleHa: Yeah, I had some fun reading the test output... :-/ | 16:11 | |
16:12
barney left
|
|||
KyleHa | Both of the passing TODO tests are because of error messages that changed from Null PMC to invoke() not for Undef. | 16:15 | |
moritz_ | KyleHa: maybe skip them, with an appropriate comment? | ||
(and with 'noauto') | |||
jnthn | Why skip them? | ||
KyleHa | Skip them because they pass but are not evidence of goodness. | 16:16 | |
jnthn | I can agree that Null PMC Access is always wrong. | ||
KyleHa | Basically, we need better tests for error messages. | ||
...which requires a better spec for error messages. | |||
16:16
masak left
|
|||
jnthn | Right, but in that case we'll want to test those specifically. | 16:17 | |
moritz_ | ... which requires somebody to write them | ||
16:17
masak joined
|
|||
KyleHa | I'm envisioning an analogy. | 16:17 | |
16:17
tak11 joined
|
|||
KyleHa | We could rid ourselves of plague if we had a better sewer system, but someone would have to invent the sewers, and then someone would have to build the sewers. | 16:18 | |
16:18
simcop238 joined,
rfordinal left
|
|||
jnthn | What does skipping the tests win us? Nothing. What does allowing them to pass tell us? That in the future we don't regress back to having a Null PMC Access. | 16:18 | |
16:18
simcop238 left
|
|||
KyleHa | Error messages are like sewers. You really need good ones, but nobody wants to work on them or look at them. | 16:19 | |
jnthn: That's almost convincing. | |||
jnthn | I'm not saying the error it gives is perfect, but if we want to go down that line we could probably go and skip a lot of our dies_ok or eval_dies_ok tests on similar grounds. | 16:20 | |
16:20
tak11 left
|
|||
pmichaud | s/skip/remove/ | 16:20 | |
jnthn | But I'm really not sure we win there. | ||
16:20
simcop238 joined
|
|||
jnthn | pmichaud: There are places where things _should_ die, and it's good that we test that they do so. | 16:20 | |
pmichaud | agreed. | ||
I have no qualm with those. | 16:21 | ||
KyleHa | pmichaud: I tried cleaning out some eval-based tests last weekend. I wondered if you saw those. | ||
pmichaud | KyleHa: I haven't seen them yet, no. I was away all weekend and I'm still catching up. | ||
KyleHa | No urgency. | 16:22 | |
16:22
jjore left,
abra joined
|
|||
pugs_svn | r28031 | kyle++ | [t/spec] Adjust a couple todo tests that were passing | 16:23 | |
moritz_ | why is portland abbreviated PDX? (is it?) | 16:24 | |
16:24
simcop2387 left
|
|||
pmichaud | moritz_: that's the airport designation | 16:24 | |
I don't know why the city adopted it | |||
masak | #p6s tonight. probably the last one. | 16:25 | |
food & | |||
16:25
masak left
|
|||
moritz_ | ah, those are semi random, it seems (at least if there are name collisions, it seems) | 16:25 | |
16:25
simcop238 is now known as simcop2387
|
|||
pmichaud | en.wikipedia.org/wiki/Nicknames_of_...Oregon#PDX | 16:25 | |
moritz_ | wow | 16:26 | |
no wonder that wiki has >2M entries | |||
KyleHa | Quick! Everybody go to Wikipedia and document the five foot radius around you! | 16:27 | |
en.wikipedia.org/wiki/Desk_of_Kyle_...troduction | 16:28 | ||
pmichaud | here's my entry: "At the center of the five foot radius around me is a person. For more details, see en.wikipedia.org/wiki/Patrick_Michaud" | ||
oh, darn, my entry is gone. | |||
16:32
jjore joined
16:33
rfordinal joined
16:41
sirrobert joined,
sirrobert is now known as Guest82957
16:42
Avada joined,
Guest82957 left,
__ash__ joined
16:45
payload joined,
hercynium left
16:46
dakkar left
|
|||
__ash__ | so... anyone seen this error message before? invoke() not implemented in class 'B' | 16:48 | |
jnthn | __ash__: Sure. | ||
__ash__: How did you produce it? | 16:49 | ||
__ash__ | well, i made the changes to methodop to try to get it to call $a.B::foo; | ||
and now it compiles, and the PAST it output is as close as i can tell correct, but when i run it i get that message | |||
jnthn | Can you nopaste the relevant PAST? | ||
__ash__ | sure, one sec | 16:50 | |
gist.github.com/170457 | 16:51 | ||
has the indirect call first, then the direct call second | |||
in this case $b is a class B | |||
one sec, i'll add my test case i am using | 16:52 | ||
okay, i updated the gist, it has the test file i am running it against to see if its working | 16:53 | ||
jnthn | __ash__: Hmm, looking up the method via the namespace isn't quite what we had discussed... | 16:54 | |
The problem in the second node appears to be that the children are in the wrong order though. | |||
In a call node without a name, the first argument should be the sub. | 16:55 | ||
Whereas here you have the code bering generated with the first arguemnt as the first node and the sub second | |||
So it emits code equivalent to $b(A::foo) | |||
Whereas you probably wanted A::foo($b) | |||
But actually | |||
$b.'A::foo'; | 16:56 | ||
__ash__ | hm, i was wondering if that would be a problem, but i couldn't find a way to move them around, not that easily anyway, | ||
16:56
araujo joined
|
|||
__ash__ | $b.'A::foo'; fails too, btw; | 16:56 | |
jnthn | I think in this quoted form, you should not be resolving it anyway. | ||
That is, I don't think $b.A::foo and $b.'A::foo' are equivalent. | |||
The second literally means "give the string 'A::foo' to the dispatcher" | 16:57 | ||
Which it's (most likely) not going to find anything under. | |||
So in fact the indirect form you needn't worry about here. | |||
Just leave that as it was. | 16:58 | ||
16:58
tak11 joined
|
|||
__ash__ | so, what do you think is the correct way to resolve this? | 16:59 | |
jnthn | Suppose you have $x.A::foo($b) | ||
Here, instead of looking up A::foo | 17:00 | ||
You take foo, set it aside for now | |||
Look up A | |||
17:00
rfordinal left
|
|||
jnthn | (or if you have something like A::B::foo then you'd look up A::B) | 17:00 | |
This is the thingy that will tell us how to dispatch. | |||
And with the result of the lookup like that you need to do something like a :inline(' %r = find_method %0, "foo"') | 17:01 | ||
17:01
cdarroch joined
|
|||
jnthn | That is, you ask A's dispatcher to find you a method "foo" | 17:01 | |
So basically you're on the right lines | |||
__ash__ | okay, so i'll be inlining PIR code then? to call the lookup? | 17:02 | |
jnthn | What's in the node [4] is mostly fine overall, it's just the [0] node within that which finds the thingy to invoke that needs to change. | 17:03 | |
Well, we may be able to do is as a :pirop('find_method') too... | |||
But try :inline first, it's the easiest way to make it work. | |||
So you'll still have a PAST::Var node, but it'll have :namespace(), :name('A') | 17:04 | ||
(Or in the base of A::B::foo, :namespace(['A']), :name('B') | |||
And you use that PAST::Var as the 0th child to the inline node. | |||
__ash__ | how would i put it there if at that point the [0] is already generated? | 17:05 | |
jnthn | I don't follow. | 17:07 | |
I'm guessing you have done something to detect that you have A::b? | |||
erm, A::foo in your example? | |||
__ash__ | yeah, | ||
jnthn | OK, so you generate a PAST::Var node, yes? | ||
__ash__ | in methodop #1422, | ||
jnthn | So you just need to generate something a bit different at that point. | 17:08 | |
Like | |||
__ash__ | is where i added my code, but at that point methodop's already created a PAST::Op and called build_call | ||
jnthn | Can you nopaste the diff? | ||
It's probably easier to explain in terms of the changes you've already made. | 17:09 | ||
__ash__ | kk, one sec | 17:10 | |
its in the same gist i sent eariler | 17:11 | ||
gist.github.com/170457 i added another file to it at the bottom with the diff | 17:12 | ||
17:12
sri_kraih left
17:13
sri_kraih joined
|
|||
jnthn | __ash__: OK, awesome | 17:13 | |
So | |||
+ $scope_var := PAST::Var.new( | |||
+ :scope('package'), | |||
+ :namespace(@ns), | |||
+ :name(@ns) | |||
+ ); | |||
I'm thinking you meant here :name($short_name) ? | |||
__ash__ | oh, yeah, sorry i just changed that | 17:14 | |
jnthn | Anyway, this is the bit that you need to change. | ||
__ash__ | the :name(@ns) should be a:name($short_name) | ||
jnthn | Well, not quite... | ||
First | |||
$past.push($scope_var); | |||
That almost certainly wants to be .unshift | 17:15 | ||
17:15
zloyrusskiy joined
|
|||
jnthn | Second | 17:15 | |
What is in $short_name is actually the name of the method. | |||
__ash__ | so, i'd need to do the lookups on the namespaces, right? | 17:16 | |
jnthn | Right | ||
I think you want something like this: | |||
$scope_var := PAST::Op.new( :inline(' %r = find_method %0, "' ~ $short_name ~ '"'), PAST::Var.new( :scope('package'), :name(@ns.pop), :namespace(@ns) ) | |||
); | |||
Erm, formatted a little nicer :-) | |||
17:17
zloyrusskiy left,
zloyrusskiy joined
|
|||
__ash__ | do i need to check if there are enough elements in @ns? | 17:18 | |
jnthn | You already did. | ||
if @ns { | |||
That promises that there is at lesat one thing in there. | |||
__ash__ | alright, didn't know if :namespace could take a blank | ||
jnthn | @ns.pop will grab that one thing | ||
lambdabot | Unknown command, try @list | ||
jnthn | And then if it's empty...yes, that's right. :-) | ||
:namespace(empty thing) will do the Right Thing. | 17:19 | ||
__ash__ | okay, just making sure | ||
jnthn | Now here how the thing that PAST::Var looks up - which should be a proto-object - is what gets used as %0 in the inline. | ||
PerlJam | random question/observation: Is the execution order guaranteed in that call to PAST::Op.new() ? | ||
jnthn | PerlJam: I hope so! ;-) | 17:20 | |
dalek | kudo: 2731d20 | jnthn++ | src/parser/actions.pm: Make sure a multi foo() { ... } gets special variables and other init done properly, just like something that went through routine_declarator does. |
||
jnthn | PerlJam: At least, we're using it in no shortage of other places in actions.pm. :-) | ||
PerlJam | oh good. | ||
pugs_svn | r28032 | jnthn++ | [t/spec] Unfudge a test for subst in a multi. | 17:21 | |
PerlJam | I was thinking that it could be an accident of implementation that we have come to rely upon. But I guess it's okay if we rely on it so much that if it breaks everyone will scream :) | ||
__ash__ | hm... i am still getting 'invoke() not implemented in class 'B'' | 17:22 | |
jnthn | __ash__: I assume just for the $b.A::foo; ? | ||
Did you change the push to unshift? | 17:23 | ||
__ash__ | yeah, here i'll update the gist with the new PAST output | ||
jnthn | Oooh...I think I've fixed two arity-related multi-dispatch bugs. | ||
Two bugs on patch. ;-) | |||
*one | 17:24 | ||
__ash__ | k, the gist is updated | ||
17:25
jferrero left
|
|||
jnthn | __ash__: Can you nopaste updated patch too? | 17:26 | |
__ash__: Oh, hmm | 17:27 | ||
I see exactly what's wrong in the PAST | |||
PerlJam | but what's wrong with the FUTURE? | 17:28 | |
;) | |||
jnthn | The forthcoming Zombie attack. | 17:29 | |
__ash__ | jnthn: updated the gist with the new diff | ||
jnthn | __ash__: Oh! | 17:30 | |
__ash__: moment... | 17:31 | ||
I know what's wrong | |||
17:31
synth left
17:32
synth joined
|
|||
jnthn | __ash__: OK, we need to fix up something else too. | 17:32 | |
__ash__ | alright, what would that be? | 17:33 | |
jnthn | eww | ||
Erm. | |||
__ash__: Actually the thing that flips the args is: | 17:34 | ||
if $<dottyop><methodop><variable> { | |||
$past.name('!dispatch_method_indirect'); | |||
$past.pasttype('call'); | |||
} | |||
That means "if it's an indirect dispatch, flip 'em" | |||
17:34
molaf joined
|
|||
jnthn | Well, call a helper routine to flip them. | 17:34 | |
Thing is, the condition sucks. | |||
17:34
abra_ joined
|
|||
jnthn | So | 17:34 | |
Let's change it to | |||
17:34
abra_ left
|
|||
jnthn | if $past.pasttype() eq 'call' { | 17:34 | |
$past.name('!dispatch_method_indirect'); | 17:35 | ||
} | |||
Then down in methodop, you'll see | |||
elsif $<variable> { | |||
$past.unshift( $<variable>.ast ); | |||
} | |||
After the $past.unshift line, add | |||
$past.pasttype('call'); | |||
__ash__ | k, | 17:36 | |
jnthn | That is, we're using "this is a call pasttype node" to signal that we have an indirect dispatch. | ||
Actually looking at the grammar, our current implementation is broken on $obj.\ $meth() | |||
That is, unspace | |||
So doing this will fix a bug too. ;-) | |||
__ash__ | cool | 17:37 | |
one question | |||
17:37
abra_ joined
|
|||
__ash__ | what is the proper way of doing $a.'Foo::b'(); ? | 17:37 | |
if thats not right | |||
hmm.. compiling and testing that gave: "elements() not implemented in class 'P6Invocation'" | 17:38 | ||
jnthn | I think there's some syntax for namespace interpolation you can put there, I forget exactly... | ||
heh heh. | |||
Yesh, !dispatch_method_indirect has no clue what to do if it's given a P6Invocation. :-) | 17:39 | ||
__ash__ | so, thats not a problem then? (or at least its another step towards getting it right) | 17:40 | |
jnthn | Right, we need to patch !dispatch_method_indirect to know what to do. | ||
But yes, it's a step forward. | |||
It's in guts.pir | 17:41 | ||
See the line | |||
.tailcall methodish(obj, pos_args :flat, name_args :flat :named) | |||
Add a label above it | |||
Then something after the various .param declarations | |||
Do | |||
$I0 = isa methodish, 'P6Invocation' | |||
if $I0 goto whatever_that_label_is_called | |||
__ash__ | found it, so add that after the '.tailcall methodish(obj, pos_args...' ? | 17:42 | |
jnthn | The label to go to wants to go above taht | ||
That is, you want to skip the other checks | 17:43 | ||
Because you already have something you know is good to invoke. | |||
[particle] | rakudo: say 'tr' ~~ rx/:i ^t<*rue>$/ | 17:44 | |
p6eval | rakudo 0d4fe0: OUTPUT«Could not find non-existent sub rue» | ||
[particle] | nyi :( | ||
moritz_ | aye | ||
__ash__ | jnthn: i am a little confused about what needs to change in guts.pir | 17:45 | |
jnthn | __ash__: Needs to end up looking probably like | 17:46 | |
$I0 = isa methodish, 'P6Invocation' | |||
if $I0 goto ready_to_dispatch | |||
$P0 = get_hll_global 'Callable' | |||
$I0 = $P0.'ACCEPTS'(methodish) | |||
unless $I0 goto candidate_list | |||
ready_to_dispatch | |||
.tailcall methodish(obj, pos_args :flat, name_args :flat :named) | |||
17:47
tak__ joined,
abra left
|
|||
__ash__ | okay, i get it now | 17:47 | |
17:47
tak__ left
|
|||
__ash__ | bbl, gonna head to lunch, i'll test these changes in a bit | 17:48 | |
17:48
__ash__ left
|
|||
jnthn | __ash__++ | 17:48 | |
KyleHa | __ash__++ # changes | 17:49 | |
__ash__++ # testing changes | |||
jnthn | Aye, and non-trivial changes at that. :-) | 17:52 | |
[particle] | __ash__++ # not sticking around for karma | ||
...but getting it anyway | |||
dalek | kudo: 2e4bc03 | jnthn++ | src/pmc/perl6multisub.pmc: Make the multi-dispatcher narrowness analysis a little bit smarter about arity. Before, it did not really account for slurpiness and optionals. This keeps all current tests passing, and deals with a couple of the issues in RT where things were being called as tied when they should have been disambiguated. Of note, a non-slurpy now wins over a slurpy if it can bind. |
17:56 | |
moritz_ | jnthn++ | ||
jnthn | We'll see how that patch flies. | 17:58 | |
17:58
zloyrusskiy left
17:59
tak11 left
|
|||
pugs_svn | r28033 | jnthn++ | [t/spec] Tests for a copule of arity based multi-dispatch bugs. | 18:00 | |
KyleHa | In Perl 5, 'perl -c' can execute. Will that be true of Perl 6 too? I get the impression that it can parse and check syntax without executing anything (i.e., what STD.pm does). | ||
18:01
payload left
|
|||
moritz_ | KyleHa: it's like in Perl 5 | 18:01 | |
perl6 -c 'BEGIN { say "foo" }' | |||
KyleHa | Oh right. Duh. | 18:02 | |
moritz_ | -e | ||
KyleHa | Thank you. | ||
moritz_ | code executed at compile time can change the syntax | ||
18:03
abra_ left
18:04
abra joined
|
|||
KyleHa | moritz++ # checking my sanity | 18:04 | |
My Temporal.t seems to be failing a lot lately. The comments say it should fail once in a while. | 18:05 | ||
moritz_ | that's bad. | ||
18:05
DakeDesu joined
|
|||
jnthn | OK, I should go shopping *before* the shops shut today. | 18:08 | |
(Going after they'd shut didn't work out too well yesterday.) | |||
KyleHa | It passed 3/4 of the last times I ran it. | ||
Maybe --jobs 5 is a little slower than it's expecting. | |||
jnthn | bbiab | ||
KyleHa | It also looked like that test (7) is where the harness paused to update the '7/x' indicator too. I wonder if that's a coincidence. | 18:09 | |
18:11
zloyrusskiy joined
|
|||
Tene | jnthn: I hate that too! Almost all the shops here close down at like 21:00 | 18:15 | |
and I live right near the middle of the city. | |||
18:15
hercynium joined
|
|||
KyleHa | I'm not really paying close attention to the Pod spec and what people want from it and why and so on, but I've rarely found vanilla Perl 5 Pod to be wanting. I'm not writing a book with it. | 18:16 | |
[particle] | it's totally lacking tables | ||
and you can't write self-documenting code easily | |||
moritz_ | KyleHa: there's one huge problem with perl 5 POD in Perl 6... | ||
KyleHa: and that is that signatures are so expressive in Perl 6 that you want them in the documentation | 18:17 | ||
KyleHa: but it's bad style to repeat them | |||
KyleHa | Hmm, good point, Moritz. | ||
18:17
__ash__ joined
|
|||
moritz_ | KyleHa: so one needs to find a way to declare something that's both Pod and code | 18:17 | |
and that doesn't look ugly | 18:18 | ||
KyleHa | I do love Perl 6 types. Love them like my boy loves bacon. | ||
[particle] | and try writing pod in a perl 5 regular expression | ||
18:18
Avada left
|
|||
moritz_ coughs loudly | 18:18 | ||
KyleHa | That reminds me. I wanted to learn how Moose does typestuff. | 18:20 | |
18:20
KatrinaTheLamia left
|
|||
[particle] | look at Class::MOP | 18:20 | |
KyleHa | I tell ya, Class::MOP and Moose make a lot more sense since I've been gone a-wanderin' in the land of Perl 6. | 18:22 | |
Am I able to post to rakudo.org, or should I impose upon someone else to announce there? | 18:25 | ||
pmichaud | KyleHa: if you're not able to post to rakudo.org, you should be made to be able. | ||
do you have a rakudo.org account? | |||
KyleHa | I don't think so. I'll go make one. | ||
Heh. "Member for 48 sec" | 18:28 | ||
OK, my new account is named 'kyle'. | 18:29 | ||
pmichaud | you're now a comment maintainer and a content author | ||
so you should be able to post | |||
on the left menu should be "create content" | |||
within that you'll choose to create a "story" | 18:30 | ||
KyleHa | Indeed there is. Very nice. Thank you! | ||
pmichaud | when do you plan to execute the release? | ||
(so I can schedule my day accordingly) | |||
KyleHa | My real time available is about five hours away. | 18:31 | |
Before that, I wanted to pick your brain about the announcement a little. | |||
What's significant about this release? What should I really highlight? I know there was that work on installing... | 18:32 | ||
moritz_ | KyleHa: just start with a simple announcement text, commit it, and we'll work on it collectively | ||
18:32
zloyrusskiy left
|
|||
KyleHa | moritz: Awesome. | 18:32 | |
moritz_ | traits is a really significant area, too | ||
colomon | jnthn++ for non-slurpy winning over slurpy! | ||
__ash__ | jnthn: do you want me to email you my git-diffs? for the stuff i changed? | 18:33 | |
pmichaud | (on phone) | 18:34 | |
KyleHa: normally I review the release announcement before the release itself, which is why I'm curious about when you're planning to do the release :-) | 18:35 | ||
KyleHa | I can hold off on the announce and stuff until tomorrow, but I want to get the grunt work of testing and prep done tonight. | 18:36 | |
pmichaud | are you saying that you won't have much free time to work on it after five hours from now? Or that you can start to work on it five hours from now? | 18:37 | |
KyleHa | I'm starting in five hours. | 18:38 | |
pmichaud | (I'm not sure what "real time available is five hours away" meant.) | ||
okay, starting in five hours is great. | |||
18:38
r0bby left,
r0bby joined
|
|||
pmichaud | I should be able to do some reviewing and announcement making between now and then as well, and I hope/expect to be on #perl6 this evening as well. | 18:38 | |
(in case you have questions or we want to do additional things) | |||
KyleHa | That's good to hear! I've been more nervous than absolutely necessary. | 18:39 | |
pmichaud | two things to know | ||
(1) the release is incredibly easy | |||
(2) it's incredibly easy to fix mistakes if they happen | |||
(3) mistakes aren't life-or-death | 18:40 | ||
(4) I don't know the meaning of "two things" | |||
:-) | |||
KyleHa | *grin* | ||
moritz_ | (5) forgiveness is given freely | ||
(6) we appreciate your work | |||
pmichaud | and yes, what moritz said as well | 18:41 | |
mistakes are acceptable. | |||
__ash__ | how would i leave a message for jnthn? since it seems he may not be here right now | 18:42 | |
moritz_ | phenny: tell __ash__ like this | ||
phenny | moritz_: I'll pass that on when __ash__ is around. | ||
KyleHa | OK, there's the bare bones announcement. | ||
18:43
mikehh joined
|
|||
__ash__ | phenny: tell jnthn do you want me to email you a git-diff for the changes I made? | 18:43 | |
phenny | __ash__: I'll pass that on when jnthn is around. | ||
__ash__: 18:42Z <moritz_> tell __ash__ like this | |||
18:43
jferrero joined,
tlb left,
r0bby left,
r0bby joined
18:44
masak joined
|
|||
dalek | kudo: cf27952 | (Kyle Hasselbacher)++ | docs/ (2 files): [docs] bare bones 2009-08 announcement and release_guide update |
18:45 | |
kudo: c52d1e6 | (Kyle Hasselbacher)++ | : Merge branch 'master' of [email@hidden.address] |
|||
pmichaud | we may want/need to change the release numbers to be "2009.08" instead of "2009-08" | 18:46 | |
so that they can be packaged properly in .rpms and the like | |||
jnthn | lol i'm back | ||
phenny | jnthn: 18:43Z <__ash__> tell jnthn do you want me to email you a git-diff for the changes I made? | ||
18:46
Kentrak joined
|
|||
jnthn | __ash__: No, I'll probably lose them. | 18:46 | |
__ash__: Either send it as a patch (to rakudobug and mark it [PATCH]) if it's ready for application. | 18:47 | ||
__ash__: Or pop it in a gist and I can review. | |||
Kentrak | Q re: object initialization in p6; Should defining a BUILD with a non standard signature imply an implicit declaration of new with the same signature? | ||
moritz_ | KyleHa: no | 18:48 | |
erm sorry, meant Kentrak | |||
tab fail :/ | |||
Kentrak: it's a nice idea, but it seems like too much magic to me | |||
Kentrak | moritz_: I'm aware it doesn't currently, but it seems like it really makes sense | ||
moritz_: in a DWIMmy sort of way | |||
moritz_ | Kentrak: right, but I don't see how it fits in the current system without defining a huge exception | 18:49 | |
18:49
r0bby left,
r0bby joined
|
|||
__ash__ | jnthn: gist.github.com/170571 | 18:49 | |
Kentrak | moritz_: it seems I need to define a new() AND a BUILD() with matching signatures just to get the initialization syntax I want, soI might as well use new(), but then I have to cless... | ||
moritz_ | anyway, I'll think about it | ||
Kentrak | err, bless | 18:50 | |
moritz_ | Kentrak: no, new() is enough, no need for another BUILD | ||
well, maybe we could have a new() with slurpy positional arguments | |||
masak | I override new() when I want magic parameter handling, and BUILD when I want non-standard object initialization. | ||
japhb | moritz_, What are your rules of thumb for when to use the various ways (implicit and explicit) to define constructors? | ||
masak | #p6s in 10, by the way. | 18:51 | |
dalek | kudo: 5a85869 | pmichaud++ | docs/announce/2009-08: Small fix to release announcement. |
||
moritz_ | and have it try to dispatch to a BUILD method, and fail if there's no matching one | ||
jnthn | __ash__: OK, looks sane. | ||
__ash__: Two questions | |||
Kentrak | moritz_: so if I want to add initializer methods to support something like my DateModule $d .= new('2007-03-12'); then I have to define new() submethods and use bless like in p5? | ||
jnthn | 1) Does it make what you wanted to work actually work? | ||
moritz_ | japhb: sorry, I'm involved in too many things at a time, maybe I'll blog later about it | ||
jnthn | 2) Does it still pass the spectests? :-) | ||
japhb | moritz_, nod | ||
masak | Kentrak: basically, yes. | 18:52 | |
moritz_ | Kentrak: roughly, yes | ||
jnthn | Kentrak: You'll generally want new to be method, not submethod, though. | ||
Kentrak | moritz_: actually, I assumed new() calls BUILD(), does it? If it does, can't we just pass the same sig to BUILD after blessing? | ||
masak | Kentrak: .CREATE and .bless is how you create objects in Perl 6. | ||
Kentrak: I think .bless calls BUILDALL, which calls BUILD. | 18:53 | ||
jnthn | .bless will trigger...yes, what masak said. | ||
moritz_ | pmichaud: funny, I had the exact same fixes, byte by byte ;-) | ||
Kentrak | masak: Hmm, I'm finding the Object synopsis to be very lean on what the special methods are and how they are to be used. | ||
japhb | To me, Kentrak's example looks like a coersion, rather than a normal constructor. | ||
masak | Kentrak: I can sympathise with that. | ||
Kentrak: I had to figure it out over a period of weeks! | |||
moritz_ | Kentrak: the problem is propagating the signature of BUILD to the signature of new(), which is defined in Object | ||
but barring that, I like the idea. | 18:54 | ||
jnthn | tbh the spec is kinda non-ideal as a learning resource on this stuff. | ||
We could do with better docs on it. | |||
masak | japhb: it could be either a constructor or a coercion, by me. depends. | ||
__ash__ | jnthn: yeah, it does, in the cases i have test, and i ran the spectest but i kinda forgot to run it before and after the changes to see if there are any differences in the number of spec's past, i do know that there are some specs in S12-class/ something... | ||
Kentrak | moritz_: Hmm, I thought it would be the other way around, but then again I haven't seen anything definitive showing how the special methods all relate | ||
__ash__ | that do work now, they had a rakudo specific thing to avoid them | ||
18:55
r0bby left
|
|||
moritz_ | Kentrak: new() calls bless, CREATE and BUILDALL | 18:55 | |
18:55
r0bby joined
|
|||
moritz_ | Kentrak: and BUILDALL calls each class'es BUILD | 18:55 | |
18:55
diakopter left
|
|||
Kentrak | jnthn: Well, having read through the first 4 so far, I think they work rather well for someone who's already versed in the ideas they propagate. Laters ones may be less ideal though. | 18:55 | |
18:55
TimToady left
|
|||
jnthn | (austrian railways)++ # ich hab mein vorteils card! :D | 18:55 | |
Kentrak: I meant in this specific aspect (object construction) rather than in general. | 18:56 | ||
18:56
DakeDesu is now known as KatrinaTheLamia
|
|||
Kentrak | jnthn: Then yes, I totally agree ;) | 18:56 | |
jnthn | __ash__: OK, it sounds good then. | ||
__ash__ | its, S12-class/inheritance.t | 18:57 | |
moritz_ | it seems that dumpiing match objects to SVG is non-trivial | ||
__ash__ | there are 2 tests that are skipped, my changes fix them | ||
japhb | Kentrak, it looks like the relevant implementation is in Rakudo's src/classes/Object.pir , line 272 and following. | 18:58 | |
Kentrak | moritz_: Is there anything preventing the passing of the signature from new along to each method that's called in turn? Or are they called with different params? | 18:59 | |
sjohnson | afternoon | ||
18:59
justatheory left
|
|||
moritz_ | Kentrak: signatures usually aren't passed along, they are static. | 19:00 | |
masak | moritz_: non-trivial in what way? | ||
moritz_ | Kentrak: the problem is BUILD needs to pass the information to new(), but they are called in reverse order | ||
19:00
r0bby left,
r0bby joined
|
|||
moritz_ | masak: getting a good layout seems non-trivial | 19:01 | |
masak | I can believe that. | ||
Kentrak | moritz_: Does it? If new just calls BUILDALL with the right capture (that's the sig, right?), and BUILDALL just calls BUILD with the right capture, then the correct BUILD will eventually be invoked due to multiple dispatch, right? | ||
moritz_ | maybe my approach is silly | ||
Kentrak: yes. But what signature does new() have? | |||
Kentrak: maybe there's a simple solution that I just don't see right now, I'm doing way too many things at once | 19:02 | ||
Kentrak: so please don't feel discouraged | |||
Kentrak: actually I'd recommend bringing it up on perl6-language | |||
19:03
molaf left
|
|||
jnthn | __ash__: OK, submit the patch! :-) | 19:03 | |
__ash__++ | |||
19:03
tak11 joined
|
|||
Kentrak | moritz_: a generic slurpy one? I guess I'm assuming the parameters could be used and matched to a signature. That seemed one of the puproses of clusures when reading the low specs | 19:04 | |
moritz_: thanks, I think I will | |||
__ash__ | where would i submit it to? | ||
moritz_ | __ash__: [email@hidden.address] | ||
(with a [PATCH] subject) | |||
Kentrak: yes, a slurpy might work | |||
jnthn | Kentrak: The signature for new takes named args and proto-objects. | 19:05 | |
It passes the relevant bits to each BUILD. | |||
moritz_ | jnthn: right now, yes. We were discussing possible enhancements | ||
__ash__ | do i need anything else in the subject other than [PATCH]? and is it an attachment or the contents in the email? | 19:06 | |
19:06
r0bby left,
r0bby joined
|
|||
masak | Kentrak: only the other day, I found out that you can easily create a new() multimethod which does delegation using callsame(|$args) or nextsame(|$args). that might be what you want. | 19:06 | |
Kentrak | jnthn: yes, aware of that, looking for a way to not have to redefine multiple pieces to accomplish what I think should be a simple feat, defining an initializer with custom params | ||
jnthn | __ash__: Just very short description saying what it does in the subject, and if you can reference the file with the spectests it makes pass in the body that's even better. | 19:08 | |
19:11
r0bby left,
r0bby joined
|
|||
moritz_ | std: my $x; $x x= 3 | 19:15 | |
p6eval | std 28033: OUTPUT«ok 00:02 38m» | ||
masak | std: my $对 = 'DUI4'; | 19:16 | |
p6eval | std 28033: OUTPUT«ok 00:02 38m» | ||
jnthn | rakudo: my $对 = 'DUI4'; | ||
p6eval | rakudo 0d4fe0: ( no output ) | ||
jnthn | rakudo: my $对 = 'DUI4'; say $对 | ||
p6eval | rakudo 0d4fe0: OUTPUT«DUI4» | ||
masak | 对! | 19:17 | |
dalek | kudo: bf4976f | moritz++ | docs/announce/2009-08: more release announcement fiddling |
||
kudo: 1c93b6b | moritz++ | docs/ChangeLog: [docs] more ChangeLog updates |
|||
19:17
r0bby left,
r0bby joined
|
|||
__ash__ | hmmmm, jnthn: i did a fresh git pull of rakudo and ran the testspec on it and its not passing all the specs like it should with my patch, so i think i'll look into those a little bit more before i send the patch in | 19:17 | |
jnthn | __ash__: ok, sounds good. | 19:19 | |
w00t my nom is cooked | |||
sjohnson | anyone here read the State of the Onion speeches? some of those are pretty hilarious | 19:20 | |
19:22
r0bby left
|
|||
PerlJam | sjohnson: are you saying that Larry could make it as a comedian should he decide to hang up his hat as language designer? | 19:22 | |
19:22
r0bby joined
|
|||
PerlJam | ;-) | 19:23 | |
sjohnson | i definitely think so | ||
he has a very funny sarcastic sense of humour | |||
... that's probably not news to anyone tho | |||
SOTO 2003: This is the 7th annual State of the Perl Onion speech, wherein I tell you how Perl is doing. Perl is doing fine, thank you. Now that that's out of the way, I'd like to spend the rest of the time telling jokes. | 19:25 | ||
19:27
M_o_C joined
19:28
r0bby left,
r0bby joined
19:29
oozy joined
|
|||
oozy | Hi there | 19:29 | |
I'm playing with Rakudo and experimenting while reading en.wikibooks.org/wiki/Perl_6_Programming | 19:30 | ||
but it's very frustrating to find out that many things are not working as documented | |||
KyleHa | What's an example of something you've run into? | 19:31 | |
oozy | for example $( 0..3 ) is documented as range in scalar context will return number of elements, but in reality it flatens items from range to scalar | ||
KyleHa | rakudo: say $( 0..3 ) | ||
oozy | so instead of 4 it returns 0123 | ||
p6eval | rakudo 0d4fe0: OUTPUT«0123» | ||
oozy | $( 0..3).say | 19:32 | |
ops | |||
rakudo: $( 0..3).say | |||
p6eval | rakudo 0d4fe0: OUTPUT«0123» | ||
__ash__ | rakudo: say $(0..3).WHAT; | ||
masak | hm... not sure that's a bug. | ||
p6eval | rakudo 0d4fe0: OUTPUT«Range()» | ||
19:32
abra left
|
|||
KyleHa | It may be that the spec has changed since the wikibook was updated. | 19:32 | |
oozy | I don't know I would just love to have accurate docs :) | ||
masak | oozy: thing is, flattening to a number or string is Perl 5 behaviour. | ||
sjohnson | rakudo: say 0..3.elems | ||
p6eval | rakudo 0d4fe0: OUTPUT«01» | ||
KyleHa | ...but I don't know one way or the other. | ||
masak | oozy: oh, definitely. | ||
oozy | masak: yep I know, but it's documented in Perl 6 Programming wiki book that way | 19:33 | |
colomon | I have to admit I didn't even know there was a Perl 6 Programming wiki. | ||
masak | oozy: I haven't looked very closely at that wiki book. but I agree with you on principle. | ||
KyleHa | I'd never heard of the P6P wikibook before now. | ||
19:33
r0bby left,
r0bby joined
|
|||
oozy | another example was casting of string this way: +"3" ... this is dicumented as to return integer, but it returns Num type (I already fixed that in wiki) | 19:33 | |
masak | accurate documentation is very important. | 19:34 | |
pmichaud | +"3" will eventually return Int | ||
that's a rakudobug at the moment | |||
masak | rakudo: say (0..3).elems; say +(0..3) | ||
p6eval | rakudo 0d4fe0: OUTPUT«44» | ||
masak | oozy: it should return Int. | ||
pmichaud | and +"3/4" will return Rat | 19:35 | |
oozy | :) | ||
pmichaud | and +"4+5i" will return Complex | ||
19:35
tak11 left
|
|||
PerlJam | and +"3e3.5" ? | 19:35 | |
oozy | so also these basic things are still under development? I was thinking to start write at least some simple script using Rakudo | ||
pmichaud | PerlJam: Num | 19:36 | |
japhb | oozy: A very large amount of stuff works. But things like Rat and Buf have been lower priority than proper OO | 19:37 | |
oozy | so in that case are Synopsis documents best to learn Perl 6? | ||
masak | oozy: I think you'll find enough things in place to write some really non-trivial things. | ||
PerlJam | oozy: Rakudo is perfectly usable if you don't mind a few work arounds sometimes. | ||
dalek | kudo: 112f146 | pmichaud++ | docs/release_guide.pod: A few more release updates. |
||
oozy | as those should descibe exact behaviour? | ||
masak | oozy: the specs are certainly the most accurate. not always the easiest to understand. | ||
pmichaud | simple scripts tend to work fine in Rakudo. But if you're asking for Rakudo to be perfectly correct with respect to the specification in all particulars... we're not there yet. | ||
masak | oozy: have you found moritz_++'s perl5-to-perl6 blog posts? | ||
oozy | I see | ||
pmichaud | afk for a bit | ||
oozy | masak: ee can you give me url? | 19:38 | |
japhb | oozy, the Synopsis (Spec) docs specify expected behavior, yes. But as masak says, sometimes not the best for learning from scratch. And all of the Perl 6 implementations lag the specs in different ways and to different degrees. | ||
masak | oozy: perlgeek.de/blog-en/perl-5-to-6/ | ||
literal | the 5-to-6 stuff is pretty good | 19:39 | |
japhb | oozy, though sometimes the spec is changed to match the implementations, when the implementors discover something turned out to be painful in the spec. | ||
19:39
r0bby left
|
|||
oozy | thanks guys, having in mind some things might change or are not yet implemented I can start to use rakudo | 19:39 | |
japhb: I see | |||
19:39
r0bby joined
|
|||
PerlJam | oozy: the Specs are still in flux though they flux much less than they once did. :) | 19:39 | |
oozy | anyhow it's great work .. I need to go my fiance is waiting ;) | 19:40 | |
cheers | |||
19:41
oozy left
19:42
nihiliad left
|
|||
PerlJam wonders how complicated rakudo's string-to-numberish routine will have to be. | 19:43 | ||
colomon | Just glancing over the Perl 6 Programming wiki-book, it seems to be a bit lacking? Or at least, really simplified. | 19:44 | |
masak | colomon: there's a general dearth of good documentation. and a lot of scattered efforts. and a lot of outdated things. | ||
19:45
r0bby left,
r0bby joined
|
|||
moritz_ | I patched the wikibook for correctness some weeks ago | 19:45 | |
but it's not really complete | |||
19:46
frederico_ left
19:47
hah left
|
|||
PerlJam | there's still some crazy language in there too. "Tokens are like normal regexes." What does *that* mean? | 19:47 | |
Tene | s/normal/p5/ | ||
well, kinda. | 19:48 | ||
Yeah, 'normal' might not be good there. :P | |||
PerlJam | but tokens *aren't * like p5 regex | ||
masak | besides, they're not. | ||
moritz_ | tokens are regexes which don't backtrack. | ||
19:48
__ash__ left
|
|||
moritz_ | feel free to patch it; it's a wiki ;-) | 19:48 | |
PerlJam | indeed, doing so now. | 19:49 | |
19:50
r0bby left
|
|||
pugs_svn | r28034 | fglock++ | mp6 update | 19:50 | |
19:50
r0bby joined
|
|||
moritz_ | literal: I have a Perl 6 file here which confuses perl6.vim (latest from alester's repo) - are you interested in a nopaste? | 19:53 | |
alester | how about a ticket in the bug tracker? | 19:54 | |
moritz_ | sure, can do | 19:55 | |
alester | github.com/petdance/vim-perl/issues | ||
please mention perl6.vim in the title | |||
19:56
nihiliad joined,
r0bby left,
r0bby joined
|
|||
literal | moritz_: sure | 19:56 | |
literal looks at the tracker | 19:57 | ||
hm, I'll have amend it to accommodate the latest Pod changes | |||
19:58
hercynium left
|
|||
moritz_ | literal: github.com/petdance/vim-perl/issues/#issue/13 | 19:58 | |
somehow I can't get github to display the whole thing as code | 19:59 | ||
PerlJam | good issue number :) | ||
literal | heh, it thinks the "s," in "@s," is the start of a substitution | 20:00 | |
alester: btw, can I get a commit bit? or should I just fork? | 20:01 | ||
moritz_ | oh | ||
alester | just fork for now please. | ||
literal | ok then | ||
alester | I don't know how I wanna handle all this | ||
moritz_ | I can temporarily add a # ,, comment ;-) | ||
20:02
r0bby left,
r0bby joined
|
|||
alester | I really need to get these files to bram | 20:02 | |
mkelly32 | heh. now i know who to pester about my syntax gripes... | ||
i mean, send useful patches to | |||
alester | mkelly32: If you like. :-) | 20:03 | |
mkelly32 | i should come up with a list sometime. | 20:04 | |
but just about every time i look to try and just fix something, it's already fixed in git :p | |||
pmichaud | phone | 20:07 | |
20:07
r0bby left,
r0bby joined,
takadonet left
|
|||
masak | walk & | 20:08 | |
20:08
__ash__ joined
20:13
r0bby left,
r0bby joined
|
|||
renormalist | frettled: late answer, and already mentioned: please look at pugs/utils/cperl-mode.el, it's based on upstream v5.20, working quite ok with only minor issues and I currently migrate its home to github.com/jrockway/cperl-mode where already perl5.10/mx-declare variants are living. Please give it a try. | 20:16 | |
jnthn has eated his dinner | 20:17 | ||
__ash__ | jnthn, i think my changes killed { }.() | ||
anon block calling, for some reason | 20:18 | ||
jnthn | __ash__: Ouch. | ||
rakudo: { say 42 }.() | |||
p6eval | rakudo 0d4fe0: OUTPUT«42» | ||
__ash__ | well, i shouldn't say think, it did, (there are other bugs i am looking into, but its not working right now | ||
jnthn | __ash__: Hmm. | ||
__ash__ | too few arguments passed (1) - 4 params expected | ||
in Main (<unknown>:1) | |||
20:18
r0bby left
|
|||
jnthn | I wonder if we actually can't get away with using pasttype eq 'call' | 20:18 | |
20:19
r0bby joined
|
|||
jnthn | oh, damm...yes... | 20:19 | |
__ash__ | thats what i was wondering | ||
jnthn | Because .() probably generates a call node. | ||
Damm. | |||
__ash__ | that seems like the change that that might be causing it | ||
jnthn | Yeah, you're right. | ||
Heh, welcome to Rakudo dev. Sometimes the first idea just doesn't work. :-) | |||
I think trying to detect it from the parse tree is too fragile. | |||
But we can't go on .pasttype eq 'call' 'cus it catches too many things. | 20:20 | ||
I'm wondering, though pm worries about overuse of them, if we should just annotate the past node. | |||
So instead of marking it pasttype call, we just set $past<indirect_call> := 1 | 20:21 | ||
And then test for that. | |||
There's plenty of examples of similar elsewhere in actions.pm. | |||
It's not perfect, but we were inspecting deep into the parse tree before, which is even more unperfect. :-) | |||
__ash__ | what about in the guts file? | ||
can we test anything else there? | 20:22 | ||
jnthn | __ash__: No | ||
__ash__: We are wrongly calling the thing in the guts file in cases where we should not be. | |||
actions.pm is the place to fix this. | 20:23 | ||
__ash__ | alright, i am still learning where things should be resolved to | ||
jnthn | :-) | ||
There's a lot to figure out. | |||
frettled | renormalist: thanks, I'll give it a try! | ||
jnthn | Especialy when adding something non-trivial. | 20:24 | |
20:24
r0bby left,
r0bby joined
|
|||
__ash__ | okay, so, if we set this variable, would we need to set it in methodop? | 20:25 | |
then check it in dotty? | |||
pmichaud | I do worry about overuse of annotations -- they're a lot of the reasons I've run into problems with refactoring variable handling. | 20:28 | |
annotations are like global variables and gotos -- they tend to produce untraceable logic | |||
20:29
sevvie_ left
20:30
r0bby left,
r0bby joined
|
|||
pugs_svn | r28035 | renormalist++ | cperl-mode.el - fix the infamous cut'n'paste carnage for handling rx// | 20:32 | |
r28035 | renormalist++ | | |||
r28035 | renormalist++ | - now use \\(?:\\) to group without capture | |||
r28035 | renormalist++ | - not sure since which emacs version that works | |||
20:35
zloyrusskiy joined
20:36
r0bby left,
zloyrusskiy left,
r0bby joined
|
|||
jnthn | __ash__: Correct. | 20:38 | |
pmichaud: Oh, it's a legitimate concern, just why I hesitated a bit on using them here. | |||
20:39
Kentrak left
|
|||
jnthn | pmichaud: OTOH, I think a lot of them will go away when contextuals support lands. | 20:39 | |
In particular, I think we can re-work this current case __ash__ is working on with contextuals when we have 'em. | |||
pmichaud | agreed, that's why I stopped the task I was on as well :) | ||
and said "oh, perhaps contextuals will be more useful now." | 20:40 | ||
jnthn | I'm really looking forward to having them. | ||
__ash__ | should i hold off and do this another way? | ||
jnthn | __ash__: No. | ||
__ash__: The stuff we need to do it the other way probably is a little way off (I'm not sure how little). | 20:41 | ||
pmichaud | I came into to this late -- what are you trying to do? | ||
s/into/in/ | |||
20:41
r0bby left,
r0bby joined
|
|||
jnthn | pmichaud: Know when we've got an indirect method call | 20:42 | |
pmichaud | example? | ||
jnthn | e.g. $obj.$code() | ||
We currently look at the parse tree. | |||
Which is already a bug. | |||
Because the unspace case with $code is almost certainly broken. | |||
pmichaud | and $code is a Method object? | 20:43 | |
jnthn | But since $obj.A::foo() involves asking A to look up foo, it boils down to us wanting to do an indirect method call too. | ||
pmichaud: Well, something invokable. | |||
pmichaud: We don't enforce that is does Method. Who'd think of doing such a thing? ;-) | |||
.oO( ooh, that was bad of me ) |
|||
pmichaud | oh, so $obj.$code() is the same as $code($obj) ? | ||
jnthn | Right. | 20:44 | |
pmichaud | as in, "always"? | ||
jnthn | Right. | ||
well no | |||
;-) | |||
$obj.@array_of_codes() | |||
At the moment this works: my $foo = [&meth1, &meth2]; $obj.$foo() | 20:45 | ||
Which is like supplying a candidate list. | |||
That is, we go on type rather than syntactic sigil. | |||
pmichaud | okay, I agree it's not syntactic | 20:46 | |
so it has to be dispatch | |||
jnthn | *nod* | ||
I think the spec would call that out more clearly if it was to be syntactic. | |||
pmichaud | actually, the spec indicates it's *not* syntactic | ||
jnthn | Ah, cool. | 20:47 | |
pmichaud | "Note also that the | ||
$obj.$candidates(1,2,3) | |||
form may dispatch to a list of candidates if C<$candidates> is either | |||
a list or a special C<Code> object representing a partial dispatch to a | |||
jnthn | I couldn't remember. I suspect I read the spec before implemetning it. ;-) | ||
pmichaud | list of candidates." | ||
jnthn | Nice | ||
20:47
r0bby left,
r0bby_ joined
|
|||
jnthn | Anyway, __ash__ is working on making $x.A::foo work | 20:47 | |
pmichaud | okay, here are my thoughts on the subject | ||
yath | hm, what am i doing wrong? i expected [["foo, "bla", ["foo, "blubb"] ...: | 20:48 | |
pmichaud | (1) all of argument handling and call dispatch will be receiving a major refactor soon | ||
yath | pugs: say (<foo bar> X <bla blubb>).perl | ||
p6eval | pugs: OUTPUT«(("foo", "bla"), ("foo", "blubb"), ("bar", "bla"), ("bar", "blubb"))» | ||
yath | hm | ||
hä? | |||
$ ./perl6 -e 'say (<foo bar> X <bla blubb>).perl' | |||
["foo", "bla", "foo", "blubb", "bar", "bla", "bar", "blubb"] | |||
moritz_ | yath: .perl is not specced to have a canonical form | 20:49 | |
pmichaud | (2) so anything that ash does at the moment is likely to get totally redone | ||
moritz_ | yath: and rakudo doesn't do captures/parcels yet | ||
jnthn | Hmm? | ||
yath | moritz_: hm, argh | ||
moritz_: i wanted to do rakudo: ;-) | |||
jnthn | pmichaud: methodop and dotty aren't *that* different in STD. | ||
pmichaud | jnthn: but arglist is | 20:50 | |
yath should drink either more or less beer | |||
hm. i tend to more. | |||
pmichaud | args, arglist, etc. are substantially different | ||
jnthn | yath: more. | ||
moritz_ | yath: at the same time ;-) | ||
pmichaud | we also end up having to redo much of circumfix and postcircumfix handling | ||
jnthn | pmichaud: OK, either way I suspect we'll still build a PAST::Op that is call or callmethod + children? | ||
Or something more drastic than that? | 20:51 | ||
pmichaud | it may be more drastic (more) | ||
I tried working on call stuff on the way back from lisbon, and the two days following that, and had to basically give up as it was growing ever more complex and pointing to the need for Major Refactor | |||
I was just trying to get :a[1,2,3] to work properly. | 20:52 | ||
jnthn | :a[1,2,3] is like a => [1,2,3] ? | 20:53 | |
pmichaud | yes. | ||
*but* | |||
yath | btw, i don't get that :foo* syntax in perl6. it's used somewhere as an "attribute" to constructors, but else? :foo<bar> seems to be the same as foo => "bar", a Pair, nor? | ||
20:53
r0bby_ left,
r0bby joined
|
|||
jnthn | yath: Yes, foo => "baz" and :foo<baz> are equivalent. | 20:53 | |
20:53
KyleHa left
|
|||
jnthn | yath: You can just say things like :foo and :!foo which map to :foo(True) and :foo(False) though. | 20:54 | |
Plus various other forms. | |||
pmichaud | prior to July, STD had :a[1,2,3] parsing via <postcircumfix> | ||
we then changed it so that :a[1,2,3] parses as <circumfix> | |||
this is fundamentally more correct | |||
yath | jnthn: ah, so i could call a function with named args both with foo(:bar<baz>) or foo(bar => "baz")? | ||
jnthn | yath: Yes. | ||
yath | cool | ||
moritz_ | and :bar is the same as :bar(Bool::True) | ||
jnthn | pmichaud: checking STD but... | ||
yath | what's the difference between :foo(x) and :foo<x> then? | ||
moritz_ | and :!bar the same as :bar(Bool::False) | ||
jnthn | pmichaud: is that circumfix called from colonpair? | ||
pmichaud | unfortunately, it means that the code we were using for pairs and named arguments (that was looking for PAST::Op) now has to look inside of circumfixes instead | ||
yath | despite x being a Str in the latter case | ||
pmichaud | yes, circumfix is called from colonpair | 20:55 | |
moritz_ | yath: :foo(x) is the same as :foo(x()), ie a call to sub x() | ||
yath | moritz_: ah, so just interpolation.. so returns still a Pair? | ||
pmichaud | :foo<x> is the same as :foo('x') | ||
jnthn: I can summarize it best this way.... | 20:56 | ||
yath | the synopses are somewhat... long to read, TBH ;-) | ||
moritz_ | yath: yes. S02:Literals is your friend here ;-) | ||
pmichaud | at present Rakudo doesn't have separate <semilist> and <statementlist> subrules (more) | ||
jnthn | pmichaud: OK, I can see that in colonpair... | ||
pmichaud | they are substantially different | ||
wait, I said that wrong. | |||
at present Rakudo has a <semilist> that calls <EXPR> | 20:57 | ||
that has to change | |||
yath | moritz_: i get confused by the test cases in the rendered pod on feather.perl6.nl ;) | ||
pmichaud | changing that will fundamentally change everything that relies on semilist | ||
this includes all of the postcircumfixes | |||
moritz_ | yath: you can also download the .pod files and read them locally with 'perldoc' | ||
pmichaud | which means it includes $obj.$code(...) | ||
20:57
hercynium joined
|
|||
jnthn | pmichaud: It includes _every_ method form though. | 20:58 | |
pmichaud | yes | ||
yath | moritz_: and i get even more confused when i want to try them out and rakudo throws a syntax error ;) | ||
moritz_: yeah, well... but i'm lazy... :) | |||
pmichaud | I'm saying that the node type that postcircumfix: currently returns may change. | ||
certainly its structure is likely to change | |||
because the handling of named arguments will have to change | 20:59 | ||
20:59
r0bby left,
r0bby joined
|
|||
jnthn | pmichaud: That's a big refactor, but at the end of the day, we'll still ahve to decide what is a direct and an indirect method call. | 20:59 | |
pmichaud | I agree there. | ||
jnthn | Which isn't a decision based upon the the arguments. | ||
21:00
masak` joined
|
|||
jnthn | So yes that bit of the code probably needs to change in various ways. | 21:00 | |
pmichaud | but an indirect method call is going to be anything that isn't a direct method call, yes? ;-) | ||
jnthn | But not in a way that I think makes it worth holding out on fleshing it out enough to support A::foo | ||
pmichaud | I'm not saying we should hold out | ||
jnthn | Ah, OK. | ||
pmichaud | I'm saying that whatever gets done is likely to get redone | 21:01 | |
21:01
masak left
|
|||
pmichaud | (or that it may add an extra layer of "we have to fix this" when we go to re-do it) | 21:01 | |
in general, every feature we layer on top of a broken feature is something that makes it harder to fix the broken feature later | |||
yath | btw, i still don't get how rakudo is parsing the perl code. i heard of NQP that's used for parsing rules, but is that used by rakudo? i mean, what will happen if i defines my new, say, COBOL grammar and write my code in cobol? | 21:02 | |
or how is STD.pm related to all of that? | |||
jnthn | True. I still think there's some level of orthogonality in deciding whether or not it's a direct vs indirect method call and the args handling. | ||
pmichaud | so, our options are (1) hold off on some features, (2) add the feature and regress on it later, or (3) add the feature and incur the extra work cost later | ||
moritz_ | yath: rakudo uses Perl 6 rules to parse Perl 6 | ||
yath: and so does STD.pm | |||
mikehh | hi - test.pir segfaults on latest perrot | ||
yath | moritz_: but how can rakudo parse perl 6 rules without perl 6? | ||
mikehh | nqp? | 21:03 | |
moritz_ | yath: with PGE, a grammar engine for perl 6 rules | ||
yath | moritz_: hm, but i thought the rules include perl code? | ||
moritz_: for the "actions" to be done | |||
moritz_ | yath: not in Rakudo | ||
yath | ah | ||
moritz_ | well | ||
pmichaud | Rakudo uses a version of the grammar that doesn't require Perl 6 code | ||
jnthn | pmichaud: When are we expecting to do this refactor? | ||
yath | and that's the NQP thing that parses the rules? | 21:04 | |
jnthn | pmichaud: And more to the point, how solid do you think the arglist/parcels/captures thing is? | ||
pmichaud | jnthn: I asked TimToady++ that question specifically, and he said "not yet" | ||
jnthn | Right. | ||
moritz_ | yath: the rules are parsed by PGE... | ||
yath: and the action methods executed by NQP | |||
yath: perlgeek.de/blog-en/perl-6/rakudo-overview.html | |||
21:04
__ash__ left,
r0bby left
21:05
r0bby joined
|
|||
yath | moritz_: ah, so ne PGE is basically the lex and NQP is the yacc? | 21:05 | |
s/ne // | |||
jnthn | In that case, I'm not so keen on holding off features for a refactor that's an arbitary distance into the future and of unknown scope. | ||
pmichaud | jnthn: again, I'm not saying we have to hold off on the feature | ||
moritz_ | yath: no, PGE is lex + yacc | ||
pmichaud | I'm saying don't get too attached to the code or the feature. | ||
moritz_ | yath: NQP is one step further | ||
yath | hm | ||
21:05
justatheory joined
|
|||
moritz_ | it transforms a parse tree into a syntax tree, mostly | 21:05 | |
yath | moritz_: what's PGT in your flow chard? | ||
pmichaud | or, more precisely, I'm saying that if we add it now, we may have to regress it for a bit later, or it may make our job harder later. | ||
yath | err, PCT | 21:06 | |
and chart. damn. | |||
pmichaud | I'm fine with either of those options -- I'm just giving the full story | ||
jnthn | pmichaud: I'm looking at the bits of STD this particular decision / features relates to, and it just doesn't feel to me like it'll give us much extra pain later in this case. | ||
pmichaud | anyway, detecting an indirect method call doesn't seem hard (more) | ||
moritz_ | yath: it's actually a collection of compilers, including the PASt and the POST compiler | 21:07 | |
pmichaud | anything that doesn't match the <longname> or <quote> alternatives of <methodop> looks to me like an indirect method call | ||
yath | moritz_: the "action methods" would be those things that i'd write into my yacc file as the "C output", right? | ||
like do_foo($1) or so | |||
jnthn | pmichaud: longname is direct. | ||
moritz_ | yath: I think so, but I haven't done enough yacc to tell for sure | ||
jnthn | potentially | ||
gah | |||
longname is only indirect if it's actually foo::bar rather than just bar. | 21:08 | ||
pmichaud | okay | ||
jnthn | But the thing is, if we look at the parse tree from dotty, it gets "fun" | ||
Because there's the unspace case to consider too. | |||
pmichaud | need to look at the parse tree from methodop, not from dotty | ||
yath | moritz_: hmm. and what would happen if i'd define my own grammar yathperl6 based on perl6? the PGE would just use that? | ||
jnthn | pmichaud: We do, but the point is that we need to know in dotty what we decided in methodop. | ||
moritz_ | yath: that would work if it produced exactly the same syntax tree as the current grammar | 21:09 | |
pmichaud | jnthn: that seems wrongish | ||
moritz_ | yath: for small scale mutations you might be interested in perlgeek.de/en/article/mutable-gram...for-perl-6 | ||
yath | moritz_: ah, hm | ||
21:10
__ash__ joined
|
|||
jnthn | pmichaud: Well, I'll leave you to work out what rightish is. :-) | 21:10 | |
21:10
r0bby left,
r0bby_ joined
|
|||
yath | moritz_: it's not that i wanted to change perl6's grammar, i was just interested in this AST/NQP/STD.pm stuff :) | 21:10 | |
speaking of the latter.. how is that related to rakudo? | 21:11 | ||
moritz_ | it's separate for now | ||
jnthn has re-arranged that bit of code a few times before | |||
pmichaud | I don't think that dotty should have to be doing that level of introspection | ||
moritz_ | but rakudo strives for convergence | ||
because STD.pm is actually part of the specification | |||
pmichaud | I can see dottyop perhaps doing it, but not dotty | ||
yath | is there an implementation that uses it? | ||
moritz_ | yes, mildew does | ||
yath | i mean, STD.pm is written in perl6, isn't it? | ||
moritz_ | mildew: say 'hi' | ||
p6eval | mildew: OUTPUT«hi» | ||
yath | so the parser needs a working pelr6 parser... | ||
jnthn | pmichaud: dottyop doesn't have much extra info. | ||
moritz_ | yath: yes; it's translated to Perl 5 by a custom script | ||
jnthn | erm, Rakudo's doesn't. | 21:12 | |
nor std's. | |||
moritz_ | yath: which implements a (partial) regex engine on top of Perl 5 | ||
yath | moritz_: and the "code" in STD.pm is NQP or perl6? | ||
jnthn | dottyop is just an alternation. | ||
21:12
synth left
|
|||
moritz_ | yath: it's Perl 6 | 21:12 | |
jnthn | dotty is the one that knows more about the nature of the dispatch we're doing. | 21:13 | |
pmichaud | except in the case of indirect dispatch | ||
unless $obj.*$method($arg) is valid | |||
jnthn | It is. | ||
yath | moritz_: but, er, hm, i maybe don't get it. if perl6 is defined by STD.pm, how can STD.pm then parsed? or is STD.pm used for bootstrapping the compiler? | ||
+be | |||
jnthn | Implemented even. | ||
moritz_ | yath: Larry wrote a Perl 6 script that parses just as much of STD.pm as needed | 21:14 | |
jnthn | (And spec'd.) | ||
pmichaud | pmichaud: in that case, it's still methodop that needs to decide indirect versus direct dispatch | ||
jnthn | moritz_: s/6/5/ ? | ||
pmichaud | s/pmichaud:/jnthn: | ||
moritz_ | erm, yes | ||
yath | moritz_: but the perl6 script is written in perl6 then? | ||
ah | |||
moritz_ | sorry | ||
gah | |||
yath | hm | ||
hm hm. funny. | |||
moritz_ | those keys are too close on the keyboard ;-) | ||
yath | :) | ||
and out of STD.pm comes an AST? | 21:15 | ||
pmichaud | yath: the term for what you're asking about is "self hosting" | ||
moritz_ | yath: yes. And error messages ;-) | ||
yath | pmichaud: mhm, well, maybe, not realy | ||
moritz_ | std: foo(1 | ||
p6eval | std 28035: OUTPUT«===SORRY!===Unable to parse argument list; couldn't find final ')' at /tmp/HnIlwRv3ce line 1 (EOF):------> foo(1⏏<EOL> expecting any of: standard stopper terminator whitespaceFAILED 00:02 37m» | ||
yath | pmichaud: to make perl6 self-hosted, there has to be a perl6 compiler already, not? ;) | ||
jnthn | pmichaud: What dotty does with .*@foo and .@foo is different. | 21:16 | |
moritz_ | a *partial* Perl 6 compiler | ||
pmichaud | and it could be an interpreter | ||
moritz_ | we have several of those | ||
21:16
r0bby_ left,
r0bby joined
|
|||
moritz_ | for some value of "partial" ;-) | 21:16 | |
pmichaud | or it could be a bunch of scripts that perform relatively simple transformations to take the Perl 6 code and make it look like Perl 5 code or some other language | ||
yath | so speaking of fiddling around with the compiler; could i do in perl6 something like: | 21:17 | |
pmichaud | but it doesn't require having a completely working compiler | ||
yath | use COBOL; | ||
01 FOO | |||
02 BAR | |||
FOO DIVISION. | |||
MOVE BLAH TO BAZ. | |||
? | |||
pmichaud | yath: Yes. | ||
moritz_ | yath: if COBOL.pm defines the appropriate grammar + compiler backend, yes | ||
pmichaud | (you can't do that today. But in Perl 6 it's possible.) | ||
jnthn | pmichaud: I might be able to re-organize it. | ||
moritz_ | and if you're masochistic enough | ||
yath | moritz_: the compiler backend would throw out a "perl6" AST? | ||
pmichaud | jnthn: is the parse for .@foo and .*@foo different? | 21:18 | |
jnthn | pmichaud: No. | ||
pmichaud: The difference is that .* and .+ and .? always go through some alternate dispatch mechanism. | |||
pmichaud | I think that @foo gets parsed by methodop in either case | ||
and that the . or .* gets handled by dottyop | |||
moritz_ | yath: yes. Or find some other way to execute stuff | ||
yath | moritz_: i did RPG for a living, i have to be masochistic :P | ||
masak` | yath: there are plenty of Perl 6 compilers. | ||
moritz_ | don't know for sure | ||
21:18
masak` is now known as masak
|
|||
jnthn | pmichaud: Correct. | 21:19 | |
moritz_ | RPG = role play gaming? ;-) | ||
yath | moritz_: well, that was possible with source filters before, too. but that's awkward | ||
moritz_: report program generator | |||
pmichaud | jnthn: yes, and the alternate dispatch mechanism has to be able to handle string, code, and array of code arguments | ||
moritz_ | ah, not quite the same ;-) | ||
jnthn | pmichaud: Correct. | ||
yath | masak: of course, but i wanted to know if there's a general perl6 way to do it | ||
21:19
mikehh left,
BinGOs left
|
|||
yath | masak: awkward AS/400 thing. i could tell stories... | 21:20 | |
jnthn | pmichaud: Though we can manage that (and do now) without having to know whether it's indirect or not. | ||
yath | s/masak/moritz/ | ||
jnthn | The plain .foo vs .@foo OTOH, we need to know about that. | ||
pmichaud | ...why? | ||
jnthn | I can change things in methodop to do the transform that is done now in dotty for plain . calls that are indirect. | ||
But then I'll only have to unpick it again for the .+ and .* ones. | 21:21 | ||
masak | yath: to do self-hosting? no, I don't think so. but you might ask putter, who has written Elf, a self-hosting Perl 6 compiler. | ||
pmichaud | wait, let's back up a second | ||
21:20 <jnthn> The plain .foo vs .@foo OTOH, we need to know about that. | |||
I think that this case should generate $P0.'foo'() vs $P0.$P1() | 21:22 | ||
yath | masak: nah, just to define a totally different syntax and write your program in it and it runs in every perl6 compliant implementation | ||
pmichaud | does that make sense? | ||
21:22
r0bby left
|
|||
jnthn | No. | 21:22 | |
moritz_ | rakudo: 'foo' ~~ m/(o)/; say $/.caps[0].key.WHAT | ||
21:22
r0bby joined
|
|||
p6eval | rakudo 0d4fe0: OUTPUT«Int()» | 21:22 | |
jnthn | indirect dispatch ain't that simple. | ||
moritz_ | hey, I didn't know we could have pairs with non-Str key. Cool. | ||
yath would like to have something like "foo inspect!" as in smalltalk, btw ;-) | |||
moritz_ | (and I even wrote it... ;-) | ||
jnthn | If it's an array (which is not a syntactic distinction) then we need to construct a P6Invocation to hold said candidate list. | 21:23 | |
Thus why we re-write it to a call to '!dispatch_indirect' | |||
pmichaud | are you saying the $P0.$P1() case couldn't/shouldn't be made to work? | ||
masak | yath: I'm not sure I'm following you. | ||
jnthn | We can't make that at a PIR level do what we want too easily. | 21:24 | |
pmichaud | or am I mis-thinking about how we've changed Parrot's dispatch | ||
jnthn | You're probably just thinking Perl 6 dispatch is as straightforward as I wish it was. ;-) | ||
yath | masak: suppose i wanted to write a different syntax for perl scripts, like Lingua::Romana::Perligata does (but without using source filters but a grammar instead). is there a "perl 6 way" to do it? instead of compiler-specific kludges | ||
pmichaud | I don't think that's it | ||
21:24
synth joined
|
|||
pmichaud | (it's entirely possible that it is) | 21:25 | |
moritz_ | yath: yes, there is. | ||
pmichaud | currently, what happens with $P0.'foo'() | ||
? | |||
yath | moritz_: ah, fine | ||
jnthn | That boils down to the args stuff | ||
__ash__ | can i get someone else to test my patch to make sure it works right? | ||
jnthn | But then | ||
__ash__: Sure, can do. | |||
moritz_ | __ash__: yes | ||
jnthn | pmichaud: followed by a $P1 = find_method $P0, 'foo' | 21:26 | |
pmichaud | PIR generates code to do a find_method on $P0, yes? | ||
jnthn | And an invoke $P1 | ||
pmichaud: Correct | |||
pmichaud | right. | ||
what would happen with $P0.$P1() ? | |||
jnthn | For a straightforward $foo.bar in Perl 6, we emit in PIR $P0.'bar' | ||
pmichaud | does it still do a find_method? | ||
jnthn | In PIR? | ||
No. | |||
$P0.$P1() is like $P1($P0 :invocant) | |||
pmichaud | checking. | ||
jnthn | (not that :invocant exists now) | ||
__ash__ | gist.github.com/170656 | ||
jnthn | (but under allison's proposals...) | 21:27 | |
__ash__ | is a gist of the git-patch | ||
jnthn | Note that it is distinct again from | ||
$P0.$S1() | |||
Which will call find_method. | |||
21:27
r0bby left
|
|||
moritz_ | __ash__: does that build on top of other patches? | 21:27 | |
21:28
r0bby joined
|
|||
__ash__ | no, it should be stand alone | 21:28 | |
masak | yath: you should check out S02 for that. | ||
pmichaud | okay, $P0.$P1() does a callmethodcc $P0, $P1 | ||
moritz_ | Applying Updated direct calling for parent methods. | ||
error: patch failed: src/builtins/guts.pir:106 | |||
error: src/builtins/guts.pir: patch does not apply | |||
__ash__ | hmmm maybe i need to update before i make the diff | ||
jnthn | __ash__: I was thinking we'd leave the $past.pasttype('call'); up in if $past<indirect_call> { | ||
21:29
r0bby left
|
|||
yath | masak: hm, i think i have to re-read it then :) thanks | 21:29 | |
__ash__ | jnthn: okay | ||
jnthn | __ash__: Otherwise we're duplicating that. | ||
pmichaud: The thing is that a $foo.$bar in Perl 6 is not so simple | |||
pmichaud: Because $bar could be an array or soemthing we can directly invoke. | |||
pmichaud | jnthn: yes, which is why the dispatcher has to handle it | 21:30 | |
jnthn | pmichaud: Correct. | ||
pmichaud | I understand that. | ||
jnthn | pmichaud: However, for .*@foo, we are already going to call a different dispatcher anyway. | ||
Basically though dispatch goes along several different axes, do it can be some "fun" trying to handle all of the combinations. | 21:31 | ||
s/do/so/ | |||
pmichaud | agreed -- I'm thinking it should be slightly more straightforward than what we have now | ||
21:31
mikehh joined
|
|||
pmichaud | for one, we should move private method calls out of <dotty> | 21:33 | |
jnthn | pmichaud: To give you an idea: | ||
rakudo: my @cands = { say $^s }, { say $^s.abs }; my @a = -1,-2,-3; @a>>.*@cands | 21:34 | ||
p6eval | rakudo 0d4fe0: OUTPUT«-11-22-33» | ||
jnthn | That is, a parallel indirect with multiple candidates dispatch. | ||
pmichaud | jnthn: I have no problem with that (and I'm aware of it) | 21:35 | |
I'm simply saying the current factoring doesn't look right. | |||
I'm not trying to oversimplify it | |||
jnthn | I'm not saying we can't simplify it. I'm just saying that things aren't the way they are because I thought it'd be fun to do something that looks complicated. :-) | ||
21:35
masak left
|
|||
pmichaud | tbh, I never suspect that of you. | 21:35 | |
jnthn | I did struggle with how to handle the combinatoric blow-up. | 21:36 | |
pmichaud | as I'm struggling now :-) | ||
jnthn | Right. | ||
So I'm happy enough to see clean-ups and refactorings here. | |||
pmichaud | afaict, the only place that generates calls to !dispatch_method_indirect is in <dotty> | 21:37 | |
does that sound right? | |||
jnthn | Yes. | ||
pmichaud | okay. I think that should go in <methodop> (more) | ||
because <methodop> is in the best position to decide if something is a direct versus an indirect method call | 21:38 | ||
I think I'm reading that you're saying there are other forms of indirect method calls, though | |||
jnthn | That isn't why it's in dotty. | ||
pmichaud | I'm not sure if I like the label "indirect method call" for the other forms | ||
jnthn | The reason it's in dotty is because we do it for all indirect calls that are a plain "." | ||
But we don't do that for a .*/.?/.+ | 21:39 | ||
Which makes some sense given that $obj.@foo and $obj.+@foo are quite different. | |||
But in methodop we don't know yet what it is. | 21:40 | ||
That's why it's in dotty. | |||
With contextuals, yes, I fully agree we could choose to make that available to methodop | |||
pmichaud | (on phone, on emoment) | ||
alester | emoment must be some startup I haven't heard of before. | 21:41 | |
"What will happen in your eMoment?" | |||
jnthn | The name starts with "e"! CLEARLY WE MUST GIVE THEM VENTURE CAPITAL!!! | 21:42 | |
21:42
kane__ joined
|
|||
PerlJam spins around and generates some emoments of inertia. | 21:42 | ||
jnthn | oh wtf | 21:44 | |
C:\Consulting\rakudo>git push origin mater | |||
error: src refspec mater does not match any. | |||
fatal: The remote end hung up unexpectedly | |||
oh, typo | |||
moritz_ | don't you want to mate rakudo? ;-) | ||
jnthn | git could perhaps learn from Perl 6. | ||
In the error message department. | |||
PerlJam | git'r dun mater. | ||
21:44
BinGOs joined
|
|||
jnthn | __ash__: Just applied your patch locally. | 21:45 | |
21:45
r0bby joined
21:46
wolverian left
21:47
wolverian joined
|
|||
__ash__ | jnthn: i think that patch is messed up, i am doing a new one, apparently git doesn't get along with me | 21:47 | |
21:47
wolverian left
|
|||
jnthn | __ash__: It applied OK here, no worries... | 21:47 | |
21:47
wolverian joined
|
|||
jnthn | __ash__: Doing some minor tweaks, but nothing too drastic. :-) | 21:47 | |
__ash__ | ah, and { say 42; }.() still worked fine? | ||
cool, well then there you go | |||
jnthn | Will tell you in a moment. :-) | 21:48 | |
dalek | kudo: 9520b46 | jnthn++ | docs/ChangeLog: ChangeLog tweaks and additions. |
||
jnthn | __ash__: Oh, hmmm, something is...very not good. | 21:49 | |
Oh, I see... | 21:50 | ||
21:51
r0bby left
|
|||
jnthn | __ash__: Yes, { say 42; }.() works here. | 21:52 | |
moritz_ | MASAK! | 21:53 | |
his XML modules doesn't do any escaping. | |||
jnthn | __ash__: spectesting here. | 21:54 | |
__ash__ | when i ran the spectest here it worked for me, although there were 2 times where it died and had a stack trace but it did that on a fresh install for me | 21:57 | |
jnthn | __ash__: Yeah, these things happen. | 21:58 | |
__ash__ | is there a reason 'is also' works and 'augment' doesn't? is that a recent change to the spec or something? | 21:59 | |
21:59
ruoso left
|
|||
moritz_ | __ash__: it's a spec change, and rakudo hasn't yet caught up | 21:59 | |
and blocks for context variables on it | |||
__ash__ | thats what i thought, just wondering | 22:00 | |
jnthn | Yeah, it's not an easy change to make. | 22:01 | |
22:01
carlin joined
|
|||
jnthn | Well, once we have contextuals it actually isn't hard. | 22:01 | |
moritz_ | rakudo: 'foo' ~~ /o/; say $/.orig.chars | 22:02 | |
p6eval | rakudo 0d4fe0: OUTPUT«No such attribute '$!target'in Main (/tmp/iFFrthghZk:2)» | ||
moritz_ | rakudo: 'foo' ~~ /o/; say $/.orig | ||
pmichaud | back (ish) | ||
p6eval | rakudo 0d4fe0: OUTPUT«No such attribute '$!target'in Main (/tmp/YPZPphWw6E:2)» | ||
pmichaud | 21:39 <jnthn> Which makes some sense given that $obj.@foo and $obj.+@foo are quite different. | ||
22:02
wayland76 left
|
|||
pmichaud | $obj.@foo and $obj.+@foo are different in that they end up in different dispatchers | 22:02 | |
jnthn | Correct. | 22:03 | |
pmichaud | okay | ||
but internally I'm thinking we should have similar ast structures | |||
(more) | |||
<methodop> should produce a callmethod structure that has the method to be called as the first child | 22:04 | ||
__ash__ | jnthn: since you have my patch, do i need to email it to anywhere? | ||
pugs_svn | r28036 | wayland++ | [S16] Documented $*CWD which was mentioned once in S28 | ||
r28036 | wayland++ | [S32] Changed Path to have Buf instead of Str, and an $.Encoding. More spec will be | |||
r28036 | wayland++ | needed when I (or someone) understands better :). | |||
jnthn | __ash__: No. | 22:05 | |
22:05
wayland76 joined
|
|||
pmichaud | <dottyop> should be able to modify that structure (which should be the same for both direct and indirect calls) to switch the dispatch to .+ as needed | 22:05 | |
jnthn | pmichaud: And then if that's just a name, it knows where to shove it? | ||
Hmm | |||
Could be made to wrok. | |||
Oh, hmm | 22:06 | ||
pmichaud | it's entirely possible that PCT's callmethod structure needs to be updated to make this better | ||
jnthn | ...same for direct and indirect? | ||
pmichaud | I don't think dottyop should have to say "do this if it's direct, do that if it's indirect" | ||
jnthn | Well, maybe...for indirect ones though we transform the callmethod into a call. | ||
At the moment .*, .+ and .? dispatchers aren't subs...but I may change that. | 22:07 | ||
So maybe that consistency would get us where we need to be. | |||
pmichaud | I'd be fine with that. | ||
I'm trying to remove as many special cases as we can | |||
jnthn | I think it was you who watned them as methods before. :-P | 22:08 | |
pmichaud | i.e., I want things to be "general case" | ||
I honestly don't remember. | |||
jnthn | But yes, I'll move them to be sub calls to the dispatcher. | ||
pmichaud | I think I moved them to be methods at the time because it added a nice consistency in another way | ||
jnthn | And then see how I can refactor it from there. | ||
That may just make things a whole load more feasible. | 22:09 | ||
And we can eliminate the <indirect_call> flag. | |||
I don't think I can do that re-org tonight though. | |||
pmichaud | that's okay, I'm not in a rush for it | ||
jnthn | I'll do it next Rakudo day. | ||
pmichaud | adn we don't want it pre-release anyway | 22:10 | |
jnthn | Yes, true. | ||
__ash__++'s patch shouldn't be too disruptive, from what I can see. | |||
OK if that one goes in? | |||
pmichaud | sure | ||
jnthn | It's a nice extra little feature for the release. :-) | ||
pmichaud | I'm fine with the patch | 22:11 | |
jnthn | OK. | ||
__ash__ | jnthn: how would i go about getting rid of the rakudo specific test's that are skipped in the test spec? | ||
pmichaud | I've never been against it, I've only been wanting to warn that we might end up redoing it :) | ||
__ash__ | thats in a different repo | ||
pmichaud | where "might" means "are very likely" | ||
jnthn | __ash__: You can get a commit bit on the spectest repo very, very easily. | ||
Any meta-committers about? | 22:12 | ||
moritz_ | jnthn: you are one, too | ||
commitbit.pugscode.org/admin/project/Pugs/people | |||
but I can do it too | |||
jnthn | moritz_: Am I? | ||
moritz_ | jnthn: every pugs committer is also a meta committer ;-) | 22:13 | |
__ash__: just /msg me your email address and desired svn nickname | |||
(or tell them here if you have no fear of spam ;-) | |||
jnthn | moritz_: Oh hey, I didn't know that :-) | ||
moritz_ | jnthn: pugs is kinda viral ;-) | 22:14 | |
pugs_svn | r28037 | moritz++ | Test for RT #68680, Match.orig | ||
jnthn has been seeing a few shifting "test gave non-zero exit code after all subtests completed successfully" all day. :-/ | 22:15 | ||
22:15
tak11 joined
|
|||
moritz_ has some humble visulization of match objects, but blocks on Match.orig not working properly | 22:17 | ||
pmichaud | moritz_: I think I can fix that immediately following the release. | 22:18 | |
(Can't do it before the release because it must be a parrot bug.) | |||
moritz_ | pmichaud: ok, thanks | 22:19 | |
22:19
M_o_C left
|
|||
pmichaud | (yes, it's a PGE bug.) | 22:19 | |
jnthn | pmichaud: Also on the patch that is just about to go in, after the release I'll and find_method knowledge to PAST::Compiler and then we can emit a :pirop instead... | 22:20 | |
s/and/add/ | |||
rather than :inline | |||
jnthn always prefers those | |||
pmichaud | so do I | 22:21 | |
are we doing find_method now in actions.pm ? | |||
22:22
gfldex left,
gfldex joined
|
|||
pmichaud | (looks like "no") | 22:22 | |
so I'm not sure where that'd be needed.... | 22:23 | ||
jnthn | pmichaud: A::foo | 22:24 | |
erm | |||
$obj.A::foo | |||
pmichaud: Looks up A, and uses find_method on that along with "foo" to get the invokable. | |||
pmichaud | we decided that's a syntactic lookup, right? Okay. | ||
jnthn | Right, it's a dispatch from the perspective of A. | ||
So we ask A to dispatch it for us. | 22:25 | ||
pmichaud | in the more general case I think it's | ||
$obj.(A::B)::foo | |||
22:25
Whiteknight joined
|
|||
pmichaud | (modulo syntax) | 22:25 | |
i.e., we take the thing on the left and ask it for 'foo' | |||
jnthn | Right, so look up A::B and the same thingy, IIUC. | ||
Yes, correct. | |||
That's what the patch does. | 22:26 | ||
pmichaud | excellent | ||
(I haven't seen the patch) | |||
jnthn | The imnportant thing about find_method | ||
pmichaud | anyway, agreed on all points | ||
jnthn | I just pushed it...you'll see it soon. | ||
pmichaud | is there a Perl 6 way of saying "ask an object for its 'foo' method"? | ||
jnthn | $obj.can('foo') | 22:27 | |
Well | |||
That gives you an iterator | |||
Well, something that knows how to act like an iterator. | |||
But if you invoke it, it'll dispatch. | |||
But .can today is implemented in terms of find_method. | 22:28 | ||
The reason for find_method is that if you do $obj.A::foo and the foo you call defers, you need to have the candidate list set up; find_method hands you back a P6Invocation rather than just the Method object. | |||
pmichaud | right. I was just wondering if the compiler should then handle $obj.A::foo in terms of .can instead of the PIR find_method :-) | 22:29 | |
i.e., it calls ".can" on A | |||
jnthn | It's probably just a more expensive route to the same answer. ;-) | 22:30 | |
pmichaud | at least until .can changes someday :-P | ||
jnthn | Though I guess from an abstraction POV you ahve a point. | ||
pmichaud | I'm fine with either approach | ||
so, whatever you and ash++ think best | |||
jnthn | I pretty much have figured Parrot's find_method is basically Perl 6's .^can | ||
pmichaud | we should probably start a document somewhere that explains how we map Parrot opcodes and vtable methods into Perl 6 | 22:31 | |
jnthn | That was why the long discussion a while ago with the smop folks to ensure that it was legitimate to hit .^can as the initial way to dispatch. | ||
Aye. | |||
pmichaud | on my todo list | ||
not doing it tonight | |||
jnthn | I'm sure if you start it, I'll feed into it. | ||
pmichaud | "/todo add start document of Parrot and Perl 6 mapping explanation" | 22:32 | |
jnthn | that's shiny... | ||
__ash__ | parrot currently doesn't have any way of doing $a.Foo::bar(); in PIR code, i was considering of looking into that, they had a Super object before, but its been removed since 1.0 | ||
pmichaud | yes, I have an alias for quickly adding things to my hiveminder account :-) | ||
hiveminder++ | |||
jnthn | __ash__: Even if it did, I'm not completely sure it'd be useful to us. | ||
Sorry, I phrased that badly | 22:33 | ||
__ash__ | when i started looking into why $a.Foo::bar() doesn't work i was wondering why not fix it at the PIR level instead of at the compiler level... | ||
pmichaud | __ash__: in general it's an issue that there's not an easy way to get a method from a class object | ||
short of doing inspection | |||
jnthn | I can't see us getting something into Parrot that matches the Perl 6 semantics closely enough to use it directly. | ||
pmichaud | well, P6object does it :-) | ||
22:33
justatheory left
|
|||
jnthn | pmichaud: Well, my point exactly. P6object builds on top of the Parrot semantics to get us what we need. :-) | 22:34 | |
pmichaud | but yes, if you're looking for some PIR syntax to support it, it's not likely to happen. | ||
it would have to be something like obj.['Foo';'bar']() | |||
and of course ['Foo';'bar'] is just (going to be) a ResizableStringArray | 22:35 | ||
__ash__ | well, what i mean is in PIR code you can still have multiple parents but there is no way of calling the parent method explicitly in PIR code, like obj.'Foo::bar'() in PIR, it seemed like it wouldn't be that big of a stretch to translate perl6 method calls into PIR method calls if you could get the PIR way to work | ||
jnthn | __ash__: In my experience, "make Parrot support it" is generally not the way things have actually worked out when implementing a lot of Perl 6 things. | ||
pmichaud | obj.'Foo::bar'() in PIR would have to mean "call a method named 'Foo::bar'" | ||
(i.e., the method name includes the colons) | |||
having PIR or Parrot automatically split the string into ::-separated parts would be Wrong. | 22:36 | ||
jnthn | __ash__: Well, it's not that trivial because then you need a variant of find_method that takes a key and not just a string. | ||
__ash__ | well, it could be obj.'Foo;bar' but i am just throwing out a logical guess, i don't have much working experience with pir | ||
pmichaud | even 'Foo;bar' is wrong. | ||
jnthn | And even then I'm not sure you'd get Perl 6 semantics automatically falling out of it. | ||
pmichaud | Using strings to identify classes is Wrong. | 22:37 | |
moritz_ | moritz.faui2k3.org/tmp/match1.svg small show-off before I go to bed ;-) | ||
pmichaud | oh, that reminds me, I should see about putting in my "don't use string checks for .isa" patch tomorrow | ||
last time I tried it, we got a 11% performance improvement. | |||
moritz_ | and many segfaults? | ||
pmichaud | 0 segfaults. | 22:38 | |
moritz_ | wow | ||
pmichaud | We got a couple of errors in Rakudo's role handling, but jnthn++ and I have since figured that was due to another bug in role handling (which has since been fixed) | ||
__ash__ | well, my point was that when i looked into it it seemed like a useful feature both perl6 and parrot were missing, it seems odd that parrot has inheritence but doesn't support calling a parent method | ||
jnthn | pmichaud: Does it not break roles now? | ||
pmichaud | jnthn: I haven't had a chance to try it since lisbon | ||
jnthn | __ash__: Yes, I agree that's odd in Parrot. | ||
pmichaud: Ah, OK. | |||
pmichaud | __ash__: I agree it's odd as well. I'd like there to be a way to look up a method via a class object. | 22:39 | |
I don't think we need PIR support for it directly | |||
for me: $P0 = class.'find_method'('foo'); obj.$P0(); # this would be sufficient | |||
__ash__ | but doesn't that seem like a practical thing to be able to do? | 22:40 | |
jnthn | pmichaud: Erm, isn't that find_method? | 22:41 | |
$P0 = find_method class, 'foo' | |||
pmichaud | it needs to be different | ||
find_method class, 'foo' looks up the Class PMC 'foo' method | |||
jnthn | oh, yes, you're right. | ||
pmichaud | i.e., classobj is an instance of Class | ||
jnthn | Right. :-) | ||
fail. | |||
pmichaud | so the method name would probably want to be something other than 'find_method' | 22:42 | |
ah, the following works, though: | |||
$P0 = classobj.'methods'(); $P0 = $P0['foo']; obj.$P0() | |||
jnthn | well | ||
yes apart from not looking up the tree. | |||
depends what you want. | |||
22:43
kane__ left
|
|||
pmichaud | oh. it includes role methods but not inherited ones? interesting. | 22:43 | |
jnthn | pmichaud: correct. | ||
pmichaud: Well, it's one area that Parrot matches S12 quite well. :-) | 22:44 | ||
In that methods from roles act as if they'd been defined in the class itself. | |||
__ash__: The patch is pushed so feel free now to test out your Pugs commit bit and unfudge the tests. ;-) | 22:47 | ||
__ash__ | will do | ||
i just thought, does it work with role defined methods as well? i only ever tested class inheritance, hmm... | 22:48 | ||
moritz_ | we're always happy about follow-up patches ;-) | ||
22:48
frederico joined
|
|||
jnthn | __ash__: No, it won't, I doubt. :-| | 22:50 | |
__ash__: But it's a step closer. | |||
__ash__: But feel free to write tests and find out and fudge any that fail. | |||
__ash__ | thats not a pretty error message... | 22:51 | |
get_pmc_keyed() not implemented in class 'Perl6Str' | |||
current instr.: '!dispatch_method_indirect' pc 19799 (src/builtins/guts.pir:119) | |||
called from Sub 'SETTING_INIT' pc 228375 (src/gen_setting.pir:30951) (src/gen_setting.pm:1993) | |||
called from Sub '' pc 306649 (src/gen_actions.pir:24702) (src/gen_setting.pm:3433) | |||
called from Sub 'perl6;Perl6;Compiler;main' pc -1 ((unknown file):-1) | |||
22:52
Limbic_Region joined
|
|||
dalek | kudo: 8924df4 | jnthn++ | src/ (2 files): Implement $obj.Foo::bar() method calls. Patch courtesy of John Harrison (__ash__++). |
22:52 | |
kudo: 9a6eeaa | jnthn++ | CREDITS: Add __ash__++ to the CREDITS file. |
|||
jnthn | __ash__: Yeah, I had to fix that about your patch. :-) | ||
You were a little over-eager scattering the indirect_call marking. ;-) | 22:53 | ||
See above for what I actually comitted. | |||
moritz_ | github.com/moritz/svg-matchdumper/tree/master # result of this evening's hacking | ||
jnthn | pmichaud: I meant to ask you earlier... | 22:54 | |
pmichaud: Do you know why ACCEPTS has to be in P6object? | |||
That is, can you remember why we couldn't move it into Rakudo? | |||
pmichaud | looking | ||
originally I think it's because all type objects were P6protoobject | 22:56 | ||
and so we needed a way to overload ACCEPTS for type objects | |||
(and there wasn't a convenient place to do it otherwise) | 22:57 | ||
pugs_svn | r28038 | moritz++ | [t/spec] tests for RT #65498, lexical subs should take precedence over outer subs of the same name | ||
pmichaud | afaict that's still the case | 22:58 | |
22:58
ihrd joined
|
|||
pmichaud | if we wanted to try moving ACCEPTS into src/parrot/Protoobject.pir, I'd be okay with that | 22:59 | |
jnthn | OK, but we have in Rakudo some extra stuff we poke into...right, there. | ||
I've just got a feeling we tried that once... | |||
pmichaud | "ack ACCEPTS" in the parrot tree doesn't come back with any hits | ||
(except for the P6object one) | |||
although I suspect it doesn't matter, since that's all changing too :-S | 23:00 | ||
jnthn | How so? | 23:01 | |
(What in specific is changing?) | 23:02 | ||
pmichaud | doesn't it become method ACCEPTS(Object:U $self:) # or something like this ? | ||
i.e., we distinguish the method based on the definedness of the invocant ? | 23:03 | ||
since "type object" is not (any longer?) a role | |||
pmichaud does an ack on the docs | 23:04 | ||
jnthn | ah, yes | ||
Provided that becomes non-conjectural. | |||
23:04
frederico left
|
|||
jnthn | But my feeling is that it's probably going to. | 23:04 | |
pmichaud | it's in S12 | ||
23:04
frederico joined
|
|||
pmichaud | at least the :U, :D, :A modifiers are there | 23:05 | |
jnthn | Yes, but that section last I checked was makred as conjectural. | ||
pmichaud | oh, you're correct | ||
jnthn | Which to me is a big "this may well change" warning sign. | ||
pmichaud | okay, so assuming it becomes non-conjectural | ||
jnthn | Yeah | ||
I don't ahve a good intuition of how likely that is. | |||
pmichaud | anyway, I suspect either S12 will become reality, or "type object" will be some form of role | 23:06 | |
jnthn | *nod* | ||
I don't want to do all the changes for that (which will be hard work) until I know we need to. | |||
pmichaud | agreed. | ||
jnthn | I probably will figure supporting them efficiently into the signature stuff though. | 23:07 | |
pmichaud | if you want to try moving .ACCEPTS into src/parrot/ I'd be okay with that | ||
I don't know if we need a deprecation notice for it, though | |||
so it might just be better to leave it for now :-) | |||
jnthn | OK - I would have tried it today but of course release. :-) | ||
pmichaud | here's my suggestion, if you're so inclined... | 23:08 | |
see if you can move .ACCEPTS into src/parrot/ | |||
if so, then put a note into P6object that says that we can move it into src/parrot/ but we're leaving it in P6object for parrot compatibility reasons | |||
23:08
diakopter joined
|
|||
pmichaud | if not, then put a note into P6object that says why it can't be moved | 23:08 | |
either way, we'll know the answer the next time we ask this question :) | |||
jnthn | lol | 23:09 | |
+1 | |||
pmichaud | we might also not want to push it out of P6object just yet -- NQP may want it or something like it | 23:10 | |
jnthn | OK | ||
pmichaud | (not likely, but possible) | ||
23:10
ruoso joined
|
|||
jnthn | It's just that I pondered editing it today and thought, hmm, I'm adding another Perl 6-ism to something in Parrot. | 23:10 | |
(In the end I solve the problem a different way...) | 23:11 | ||
pmichaud | phenny: tell KyleHa I expect to be online around 00:30 UTC tonight to look at Rakudo stuff | ||
phenny | pmichaud: I'll pass that on when KyleHa is around. | ||
pmichaud | well, P6object is all about adding Perl6-isms to Parrot :) | ||
jnthn | True. ;-) | ||
pmichaud | that's why I prefer to keep the name "P6object" | ||
It's unabashedly about saying "this looks like Perl 6" without building it into Parrot guts. | 23:12 | ||
23:14
__ash__ left
23:19
zamolxes joined
|
|||
ruoso just replied to the "custom constructor" thread | 23:22 | ||
ruoso wonders who kevan benson is... | |||
wayland76 | Isn't there a game, "6 degrees of Kevin Benson"? Or is that "Kevin Bacon"? :) | 23:26 | |
jnthn | use.perl.org/~JonathanWorthington/journal/39498 # Rakudo day scribble-up | 23:31 | |
sjohnson | Bacon | 23:33 | |
reqamst | I want to help develop perl 6, but I'm disoriented | 23:38 | |
literal | that's a good sign | 23:40 | |
reqamst | I see tasks on the rakudo roadmap, but how can i help? | ||
patching on my own and waiting for reply or..? | 23:41 | ||
23:41
KyleHa joined
|
|||
KyleHa | Hello #perl6! | 23:41 | |
phenny | KyleHa: 23:11Z <pmichaud> tell KyleHa I expect to be online around 00:30 UTC tonight to look at Rakudo stuff | 23:42 | |
literal | reqamst: as for patches, see this -> wiki.github.com/rakudo/rakudo/steps...te-a-patch | ||
jnthn | reqamst: There's lots of places to get involved, Rakudo hacking is one of them, writing Perl 6 modules and applications is another (very good) way too, then there's the test suite, the documentation project... | 23:45 | |
reqamst: Really it depends what you enjoy doing. :-) | |||
carlin | rakudo: if(1) { say 'Foo'; } | 23:48 | |
p6eval | rakudo 0d4fe0: OUTPUT«Statement not terminated properly at line 2, near "{ say 'Foo"in Main (src/gen_setting.pm:3390)» | ||
carlin | rakudo: if (1) { say 'Foo'; } | 23:49 | |
p6eval | rakudo 0d4fe0: OUTPUT«Foo» | ||
KyleHa | rakudo: if 1 { say 'Foo'; } | ||
p6eval | rakudo 0d4fe0: OUTPUT«Foo» | ||
jnthn | wrong, ok, good. :-) | ||
KyleHa | I think "if(1)" is a call to a sub named 'if'. | ||
jnthn | KyleHa: Correct. | ||
carlin | Should if() not work without the space? | ||
jnthn | carlin: foo() is *always* a sub call. | 23:50 | |
carlin | Oh okay | ||
jnthn | carlin: You get a syntax error writing if(1) { ... } because its' like foo(1) { ... }, which is two terms in a row. | ||
KyleHa | I need to go have dinner, but I will be back as soon as I can, and then for the rest of the night. | 23:51 | |
jnthn | carlin: It's a consistent rule, though different from what you may be used to from other languages. :-) | ||
carlin | such as Perl 5 ;) | 23:52 | |
but it makes sense I guess | |||
23:52
[1]Limbic_Region joined,
[1]Limbic_Region left,
Limbic_Region left
|
|||
jnthn | carlin: Yes, it's different from Perl 5. :_) | 23:53 | |
std: class A { }; my A $x = A(42); | 23:55 | ||
p6eval | std 28038: OUTPUT«ok 00:02 38m» | ||
jnthn | std: class A { }; my A $x .= .(42); | ||
p6eval | std 28038: OUTPUT«===SORRY!===Confused (two terms in a row?) at /tmp/AqwMr3udRJ line 1:------> class A { }; my A $x .= ⏏.(42); expecting any of: dotty method or postfix infix__S_411DotEqualOther potential difficulties: Possible obsolete use of .= | ||
..as ap… | |||
jnthn | std: class A { }; my A $x .= (42); | ||
p6eval | std 28038: OUTPUT«Potential difficulties: Possible obsolete use of .= as append operator; in Perl 6 please use ~= instead at /tmp/6sTBIeJlkg line 1:------> class A { }; my A $x .= ⏏(42);ok 00:02 38m» | 23:56 |