pugscode.org/ | nopaste: sial.org/pbot/perl6 | ?eval [~] <m oo se> | We do Haskell, too | > reverse . show $ foldl1 (*) [1..4] | irclog: irc.pugscode.org/
Set by diakopter on 11 July 2007.
meppuru good night 01:08
pugs_svn r19311 | duff++ | Tests for while and until loops 05:56
diakopter howdy 09:09
moritz_ hi diakopter 09:10
happy new moose!
erm, year
whatever ;)
diakopter each year ever always gets less new. Therefore, happy Newest Year to you! 09:13
pugs_svn r19312 | ruoso++ | [yap6] NOTES_AUTOVIVIFY.txt now have a very structured summary of my doubts... 10:41
ruoso any help with the problem described in svn.pugscode.org/pugs/v6/yap6/NOTES...VIVIFY.txt 10:42
is very much appreciated
pugs_svn r19313 | ruoso++ | [yap6] fixing a small confused writing. 10:44
Schwern Is there a "negative smart match" operator? 10:48
Ahh, !~~ 10:49
pmurias ruoso: foo(%a<b><c>) shouldn't autovivify 13:55
pmurias ruoso: i'm not sure S06 appears to be contradictory 13:59
1161 14:00
avar should p6 autovify anything at all? I thought that was explicitly dropped
pmurias avar: see S06:1161 14:01
avar: i think only formats were droped everything else was just changed 14:02
pmurias with changed being improved 14:02
avar magic was dropped
moritz_ ... except implementation speed ;)
pmurias avar: no it isn't 14:03
avar although now presumably everything will now have magic slowness ...
or maybe not, since we have :=
pmurias moritz_: wait till we implement static typing and translate to C ;) 14:04
moritz_ pmurias: but static typing is optional, no? ;-)
pmurias moritz_: yes
avar: the implementating speed drop in kp6-MOP was caused by reimplementing everything on *top* of the existing runtime 14:05
avar MOP is p6 now?
moritz_ so is there a hope of making a faster, bootstrapped kp6?
avar I'm still waiting for more MOP/PAD stuff to be bootstrapped until I hack lisp again:) 14:06
pmurias avar: i mean kp6-MOP as the perl5 backend as opposed to the perl5v6 backend 14:07
avar is perl5v6 generally faster now?
pmurias avar: it's incomplete 14:08
avar but for the stuff it works for?
pmurias it's similar to perl5
that is if you do *not* use := 14:10
moritz_ so does a 'perl Makefile.PL; make' build and test kp6-mp6 or kp6-kp6? 14:11
pmurias moritz_: kp6-mp6
kp6-kp6 dosn't work
moritz_: it only builds kp6-mp6 if you changed it (it's prebuild in the repo) 14:12
avar: := is not avalibe in perl5 so it's done with Data::Bind 14:13
i mean := is only avalible for globals (typeglob manipulation) 14:14
ruoso pmurias, S09 makes me uncertain 14:49
utovivification will only happen if the vivifiable path is used as a container, by binding, assigning, or capturing into an argument list. 14:50
ruoso meant quotes aroud it
but I'm not sure if "capturing into an argument list" only means \%a<b><c> and not foo(%a<b><c>) 14:51
because in theory
foo(%a<b><c>) is the same as my $c = \%a<b><c>; foo(|$c);
and \%a<b><c> autovivifies 14:52
ruoso the thing is... if \%a<b><c> didn't autovivify, 14:54
the autovivification could be in the binding
and than
foo(%a<b><c>) would autovivify only if the signature was readwrite
the same as
my $a is ro; $a := %a<b><c>; wouldn't autovivify 14:55
but considering \%a<b><c> autovivifies,
it means that the capture is the one who triggers the autovivification
ruoso and not the binding 14:55
ruoso moritz_, I bet on the yap6 runtime for a faster bootstrapped kp6 15:00
moritz_ ruoso: I hope it is (and works ;)
ruoso fglock, I think I'll consider the capture as the autovivifier 15:02
I can't think in anything more appropriate right now
fglock ruoso: how about write some actual tests 15:03
in pugs/t 15:04
ruoso let me see something
fglock so we can submit more easily to @larry
ruoso pugs: my %a; my $b := %a<b><c>; say %a.elems 15:04
exp_evalbot OUTPUT[1␤]
ruoso pugs: my %a; my $b = \%a<b><c>; say %a.elems 15:05
exp_evalbot OUTPUT[1␤]
ruoso sub foo { 1 }; my %a; foo(%a<b><c>); say %a.elems
pugs:sub foo { 1 }; my %a; foo(%a<b><c>); say %a.elems
pugs: sub foo { 1 }; my %a; foo(%a<b><c>); say %a.elems 15:06
exp_evalbot OUTPUT[1␤]
ruoso pugs: my %a; my $b = %a<b><c>; say %a.elems
exp_evalbot OUTPUT[1␤]
ruoso hmm
moritz_ pugs: my %a; my $b = %a<b><c>; say %a.keys.elems
exp_evalbot OUTPUT[1␤]
moritz_ pugs: my %a; my $b = %a<b><c>; say %a.perl
exp_evalbot OUTPUT[{("b" => {}),}␤]
ruoso fglock, actually I just need a clarificatoin of the spec... 15:07
does the "capturing into an argument list" includes "foo(%a<b><c>)"?
I would think so
fglock ruoso: writing a test is a great way to formulate the right questions, just show the test 15:08
fglock re asking the right questions, I'm going to give a short talk today about the Perl 6 project 15:16
pasting...
pasteling "fglock" at 81.193.158.177 pasted "Perl 6 talk - draft" (84 lines, 959B) at sial.org/pbot/29561
pugs_svn r19314 | ruoso++ | [pugs/t] autovivification test. Needs checking against the specs 15:20
ruoso fglock, take a look at pugs/t/autovivification.t 15:21
fglock ok
pmurias ruoso: dosn't exists bind to a capture object? 15:24
ruoso pmurias, in fact... exists is a method 15:25
but, it's differn
different
because exists takes the hash as invocant and the key as argument 15:26
pmurias so exists is a macro? 15:27
fglock ruoso: how about adding a subroutine with readonly parameters - I think it doesn't autovivify, or does it? 15:28
ruoso fglock,
the thing is
if \%a<b><c> autovivifies
it doesn't matter to what it is bound to
because my $a = \%a<b><c> is not a binding
fglock I mean, if you add a test for it, you can get an "official" ruling on it 15:29
ruoso fglock, but the problem is before that 15:30
how is foo(%a<b><c>); different from my $b = \%a<b><c>; foo(|$b); ? 15:31
that is the question right now 15:32
fglock a possible difference is, in "foo(%a<b><c>)", the "capturization" can be optimized out 15:33
ruoso fglock, no, it can't
because you only bind to the signature at that exact time
you must create a cature, so you can bind to the signature
s/cature/capture/
fglock, at least, if it can, it can't change the behaviour 15:34
the capture is the thing you pass to the method call 15:35
if foo(%a<b><c>) doens't autovivify... \%a<b><c> must be a special kind of capture 15:36
like... anonymous capture, for instance...
and then this special capture would trigger the autovivification in advance 15:37
even before the binding 15:38
and the regular capture would only autovivify if bound to a rw value...
it actually makes sense 15:39
ruoso pmurias, I think you raised the key issue 15:45
foo(%a<b><c>) can't autovivify in advance
because if so, exists would autovivify also
the only option left, is to treat \%a<b><c> as special
so the prefix:<\> would create a special capture 15:46
that triggers the autovivification in advance, even before bind
while the normal capture won't do anything, and the triggering is made only during binding
and only if the signature points to a rw variable
ruoso will change that test to reflect that 15:47
ruoso and I think I'm calling it anon capture 15:50
heh
pugs_svn r19315 | ruoso++ | [pugs/t] autovivification test for the autovivication on bind and on anon capture.
ruoso then a ruling is needed on the anon capture thing... 15:52
does prefix:<\> triggers the autovivification?
it actually makes much sense 15:53
fglock, so, what do you think? 15:54
fglock on one hand, you could assume that the Capture attributes bind to the variables, which makes them autovivify 15:56
fglock but you can also consider Capture a low-level thing, so that binding doesn't apply there 15:56
Capture attributes == .positional, .named, .invocant 15:57
ruoso fglock, the thing is that Capture is both low-level and high-level, it's present in all levels
pugs_svn r19316 | ruoso++ | [yap6] I think the problem is solved now. see NOTES_AUTOVIVIFY.txt 16:14
ruoso fglock, TimToady, I think I got to the solution... please take a look at svn.pugscode.org/pugs/v6/yap6/NOTES...VIVIFY.txt 16:16
pugs_svn r19317 | ruoso++ | [yap6] giving the text a little title 16:17
mncharity fglock: ping? 16:29
fglock mncharity: pong 16:31
estou? # Portuguese phone greeting 16:33
mncharity re "What can we do about it?"/"unblock", 16:34
lol # re estou?
and apropos ruoso's questions,
mncharity it seems like there is a body of knowledge in between what is in the sNN, and what an implementer needs to write an implementation. 16:35
knowledge which is not in sNN because it is speculative, 16:36
or just haven't gotten around to including it??,
fglock some things are implementation details, but they are high-level enough that all implementations need to worry about 16:37
mncharity or ... I don't know why.
ah, right
fglock such as, there are some compile-time structures that you need to have, in order to implement blocks that run at compile-time 16:39
mncharity interesting 16:40
once upon a time, the story was that the hs pugs code would be so clear, it would be the "reference" implementation, the documentation, for such things
pmurias ;) 16:41
fglock I did use the pugs source for kp6 ast
PerlJam mncharity: you sure have an active imagination :)
fglock I think it was the ast proposed by gaal, not the actual pugs ast 16:42
mncharity re imagination, I'm not sure re what, but :) 16:44
fglock mncharity: I believe it could be the reference implementation,
but it never got the required cleanup
ruoso mncharity, the thing is that some data structures are too important and interfere in all the language behaviour... like the capture...
mncharity re ast, and kp6 as the current reference implementation, right.
ruoso capture is something which is used from bottom-up in all levels 16:45
mncharity re required cleanup, ?
re capture, i'm wondering if there might be a "block" there. that it is still too hard for potential implementers to sit down and say "ok, I have the spec here, so I can now 'mindlessly' churn out a new implementation in language X". 16:46
mncharity one has to do a lot of research, search the mailinglist, learn the pugs and kp6 code, ask questions, ... 16:47
fglock cleanup: regex engine, object system - and then macros and such (as in the pugs roadmap) 16:48
mncharity ah, right
fglock I understand you are talking about new contributors, but we already have a good number of "old" contributors that could be driven in some useful (same) direction 16:51
mncharity good point 16:53
mncharity I guess it feels like "it shouldn't be this hard". 16:56
when the spec was missing key bits, implementation required an exploratory dialog with TimToady. 16:57
but it seems like at least most of that got filled in, no? 16:58
at least for something "perl6-like" rather than "perl 6 official spec".
sure, p6 is big and complex, but... so are lots of other things which get written. 16:59
fglock yes, Perl 6 is much easier to implement now 17:00
and one can start with the kp6 framework and rewrite just what he doesn't agree with :P
we are mostly blocking on VM features right now 17:01
VM == Parrot | Perl5 | C | Lisp 17:03
mncharity phone, bbiab 17:04
fglock "perl6" is exploring the t/ space - "what can we implement without blocking?"
pmurias fglock: is it possible to turn of vivification in perl5? 17:05
fglock kp6 has been exploring the work-arounds - "what can we emulate?" 17:05
[particle] those are complimentary exploration spaces 17:06
fglock pmurias: I don't know - look in CPAN?
pmurias s/of/off/
fglock [particle]: they are, and that's why we can profit from working together 17:07
[particle] i agree completely
fglock actually, "perl6" needs to push Parrot to unblock, and kp6 needs even more emulation layers 17:08
[particle] did you see set_outer is implemented now? 17:09
fglock I didn't - cool :)
is there a test? 17:10
[particle] i'm not sure
i'll check the log, find the rev, and let you know
fglock nm, I'll look 17:11
[particle] yes, t/pmc/sub.t
svn diff -c 24453
[particle] it's not tested, but you should be able to get a sub from another namespace, too 17:14
fglock very nice - I have some test code already, I'll try it out later 17:15
[particle] let me know how it goes
i'm doing some test refactoring today 17:16
fglock hmm - my test doesn't try an eval() yet 17:17
[particle]: I added a parrot/ inside the kp6 repo, so that I can have my patches there - it mirrors the parrot directory structure 17:19
[particle] ah, yes, i remember that 17:20
how do you merge?
fglock (but ignore the current content, it's obsolete)
[particle] ok
mncharity sorry. back 17:21
fglock I wrote a merge script
(I don't have a parrot commit bit)
I'll tell you if I come up with anything useful :) 17:22
mncharity re "yes, Perl 6 is much easier to implement now", 17:24
would it help if it was even easier?
[particle] of course it would help :) 17:25
fglock mncharity: no, we need some challenge :P
mncharity lol
[particle] :D
mncharity oy
mncharity finally stops laughing 17:26
almost
fglock mncharity: ok, I give up - how would you make it easier? 17:27
mncharity I mean, if there was a page somewhere saying "this is all you need to know about implementing a Signature object",
[particle] "far more than everything you wanted to know about lexical pads"
mncharity it might make new implementations easier, but if the problem is finishing existing implementations which already have a Sig object, 17:28
then it's not clear it would really help.
?
re how,
a page on Signature objects? ;)
fglock yes, we have some of these docs - it's just not properly organized
[particle] the organization would help, surely 17:29
just like we're reorganizing tests to make implementation easier
fglock such as svn.pugscode.org/pugs/docs/notes/
lambdabot Title: Revision 19317: /docs/notes
[particle] there's a wealth of information out there, thanks mostly to pugs but also to kp6 and perl6 implementations. getting it organized so the various in-progress impls can help each other and learn from each other better is helpful 17:30
fglock and the "misc" docs under v6/
[particle] would also make a new impl easier to write
(technical debt)-- 17:31
fglock we even have some Perl6-in-Perl6 source code svn.pugscode.org/pugs/v6/v6-KindaPe...ime/Perl6/ 17:32
lambdabot Title: Revision 19317: /v6/v6-KindaPerl6/src/KindaPerl6/Runtime/Perl6, tinyurl.com/2q4n24
fglock and STD 17:33
.set_outer unblocks kp6-parrot development for some time 17:34
[particle] yay!
fglock we will then need to find out how to freeze the compile-time lexical environment until run-time 17:35
actually, we need some way to specify the lexical environment in the PAST 17:37
hmm
{ my $x; BEGIN { $x=3 } print "$x\n" } # we need a PAST representation for this 17:40
{ my $x; INIT { $x=3 } print "$x\n" } # this would do, but it's hard to implement - and that's what kp6 does 17:41
the alternative is to just freeze *everything* - smalltalk and some lisps do it this way 17:43
[particle] i think pmichaud has figured out what to do for that part 17:44
but i'm not certain of that
fglock I'd like to know 17:45
[particle] he should be back to #parrot soon 17:46
fglock I'm afraid I have a talk in a while - and I should be formatting it 17:47
[particle] oh, right. the notes looked good 17:49
fglock if we can figure the lexical thing, I think I can draft a plan
[particle] do you have subs written in perl 6 for kp6? where?
fglock the kp6 runtime at: svn.pugscode.org/pugs/v6/v6-KindaPe...ime/Perl6/ 17:51
lambdabot Title: Revision 19317: /v6/v6-KindaPerl6/src/KindaPerl6/Runtime/Perl6, tinyurl.com/2q4n24
fglock where perl 6 == kp6 17:52
it compiles most of it's own runtime
Range and Pair are interesting 17:53
[particle] good examples, thanks! 17:56
fglock btw, Capture and Signature are there too 17:59
(the high-level methods) 18:00
pugs_svn r19318 | particle++ | [t]: refactoring radix conversion tests for octals 18:11
dlocaus fglock: is there any code that needs to be documented or refactored? 18:14
fglock looking
dlocaus: can you try to refactor Makefile.PL into something maintainable? 18:16
dlocaus ok
fglock cool :)
fglock dlocaus: we've been adding even more experimental backends 18:18
dlocaus Perl5v6 and Perl5Cache I believe.
dlocaus After coming back from X'mas break, I find I'm a bit rusty on my kp6 (which wasn't all that good to being with :) 18:19
fglock Perl5v6 (added recently) and yap6 (not added to Makefile yet) 18:23
dlocaus I thought yap6 was a C based Perl6 compiler?
fglock re rusty, nevermind - most of us are
dlocaus: it is, 18:24
it's kp6 compiled to C, with a C runtime
will be 18:25
dlocaus I hate these onion layers (self bootstrapping)...
dlocaus Ok, I think I figured it out (again), the AST produces C code which can compile kp6. 18:26
fglock yes 18:29
dlocaus brb, quick snack & 18:31
skids Without IO.fileno implemented, any "back door" way to get a file descriptor out of a pugs IO object? 18:32
dlocaus back 18:35
fglock: How do you feel about extracting the target make parameters into a YAML file? 18:36
fglock dlocaus: not sure, the thing we need most right now is flexibility 18:38
keeping the params as plain code might be easier
fglock dlocaus: I've been thinking about splitting the makefile, but there are also arguments against that 18:39
dlocaus (phone) 18:40
[particle] skids: iunno, i'm not familiar with that part of pugs
ruoso dlocaus, actually yap6 is not a compiler
fglock, ^
ruoso kp6 will be the compiler forever 18:41
yap6 is just a kp6 backend
as perl5 is
dlocaus (sorry, phone call). 18:44
dlocaus That is what I was thinking about the YAML file, we could get the parameters out of the Makefile.PL which would remove some of FUD when looking at the document. 18:45
Let me write it up and then you can take a look at it.
dlocaus Extracting the parameters out of the YAML file could "fake a split" of the Makefile :) 18:45
skids wonders about future asynch IO api versus coro 18:46
IO.read(&callback_to_this_function); yield; 18:47
...but how to ensure the callback doesn't happen before the yield...
fglock dlocaus: fine 18:49
fglock skids: sorry, what are you trying to do? 18:49
skids (hypothetically, since there is no async api yet) write coros that get woken up when their IOs complete -- which of course would be useless if you didn't have more than one of them at a time. 18:52
fglock makes sense 18:57
pugs does have async
skids yep. But regular expressions crash asyncs.
fglock hmm - they call perl5 18:58
skids In either case not sure which would be better -- several thousand asyncs or several thousand in-progress coros... 18:59
fglock it's implementation-dependent, I don't think you will know in advance 19:00
skids has the return value of yield been formally specced? 19:13
[particle] return value? i assume yield returns the results you pass it 19:16
yield($foo, $bar);
skids no that's the return value of the function in the place where the coro was called. I'm talking about $foo = yield(*) inside the coro. 19:17
pugs_svn r19319 | particle++ | [t]: refactoring radix conversion tests for decimals 19:21
skids My druthers would be that should return an argument capture of the params to the "second" call to the coro, which are currently discarded. 19:22
pugs_svn r19320 | particle++ | [t]: refactoring radix conversion tests for hexadecimals 19:28
pugs_svn r19321 | dlo++ | [kp6] 19:36
r19321 | dlo++ |
r19321 | dlo++ | fglock suggested I make Makefile.PL more maintainable. I believe that the first step should be to extract the
r19321 | dlo++ | configuration settings for each build out of the Makefile.PL to reduce FUD. The code is fairly long and difficult to
r19321 | dlo++ | read; by extracting the code into a YAML (targets.yml) file, this simplifies the code and makes it easier to read.
r19321 | dlo++ |
r19321 | dlo++ | The next step will be to sort out the pod creation.
r19321 | dlo++ |
r19321 | dlo++ | dlocaus @ #perl6 irc.freenode.net
dlocaus Lots of documentation for lots of brownie points.
fglock: pmurias: moritz_: does anyone read the kp6 man pods? I'm wondering if they should just be removed entirely from the Makefile.PL 19:38
fglock dlocaus: I read it once :P 19:42
pugs_svn r19322 | particle++ | [t]: refactoring radix conversion tests for binary, and fractions
pmurias dlocaus: Perl5Cache has been removed 19:57
dlocaus pmurias: ok
pmurias dlocaus: re man pods the only make sense if you intall them 20:00
dlocaus Ok, I'll comment that line out in the next revision.
pugs_svn r19323 | dlo++ | [kp6] 20:17
r19323 | dlo++ |
r19323 | dlo++ | I have refactored the code into subroutines. This has improved readability.
r19323 | dlo++ | I have also run perltidy over the Makefile.PL.
r19323 | dlo++ | I have also by default elimated the MAN3POD variable, man pages, as no one appears to be reading them. I do not
r19323 | dlo++ | think there is even all that much documentation in there. :)
r19323 | dlo++ |
r19323 | dlo++ | dlocaus @ #perl6 irc.freenode.net
pugs_svn r19324 | dlo++ | [kp6] made the code neater, minor chagnes 20:21
pugs_svn r19325 | dlo++ | [kp6] 20:42
r19325 | dlo++ |
r19325 | dlo++ | Refactored the code, removing unnecessary variables.
r19325 | dlo++ | Cleaned up the code some more.
r19325 | dlo++ | Put the licencing back end. (accidently removed it).
r19325 | dlo++ |
r19325 | dlo++ | dlocaus @ #perl6 irc.freenode.net
pugs_svn r19326 | dlo++ | [kp6] Added licening and cleaned up the code 20:47
dlocaus lunch &, I will resume refactoring Makefile.PL when I get back. 20:48
bnjmn-- perl6!!! do want! 22:26
pbuetow hehe

Powered by Cro and the Raku® Programming Language.

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

Thank you!