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.
00:02 ebassi left 00:07 theorb joined 00:17 Limbic_Region left, jhorwitz left 00:18 theorbtwo left 00:36 rdice joined 00:50 lorn joined 00:52 DaGo left 00:59 chris2_ left 01:02 Jamtech joined 01:07 alester joined 01:08 felipe joined
meppuru good night 01:08
01:09 justatheory left 01:16 Auzon joined 01:18 jedai joined 01:19 tobeya left 01:20 meppuru left 01:26 __Ace__ joined 01:27 cnhackTNT joined 01:30 devogon left 01:36 |Jedai| left 01:37 thoughtpolice joined 01:39 seablue100 joined 01:52 Schwern left, han_ left 01:53 dlocaus left 01:57 bwisti left 02:32 Jamtech left, Coke joined 02:36 Coke left, _sprocket_ joined 02:52 _sprocket_ left 02:55 jedai left 03:06 kanru joined 03:15 c9s left, jjore-m joined 03:32 c9s joined 03:36 rdice left 03:41 diakopter joined 03:43 ChanServ sets mode: +o diakopter, diakopter sets mode: +o TimToady 03:48 _sprocket_ joined 03:56 [particle] left 03:59 [particle] joined, pen1 joined 04:00 penk left 04:03 jferrero left 04:06 cnhackTNT left 04:14 Auzon left 04:15 cnhackTNT joined 04:19 jjore-m left, lorn left 04:43 pen1 left 04:45 theorb left 05:20 xinming joined 05:27 Jamtech joined 05:28 Jamtech left 05:30 seablue100 left 05:32 _sprocket__ joined, _sprocket_ left 05:33 _sprocket__ left, BinGOs_ joined 05:34 Jamtech joined 05:49 BinGOs left 05:54 BinGOs joined
pugs_svn r19311 | duff++ | Tests for while and until loops 05:56
06:00 BinGOs_ left 06:05 BinGOs_ joined 06:13 BinGOs left 06:23 Hez joined 06:24 Hez left 06:25 lambdabot joined 06:45 Jamtech left 06:49 Jamtech joined 06:54 Jamtech left 07:11 Aankhen`` joined 07:24 c9s left 07:32 BinGOs joined 07:34 devogon joined 07:35 dmq left 07:46 lyokato_ joined 07:47 BinGOs_ left 08:01 Jamtech joined 08:04 Jamtech left 08:11 penk joined 08:13 penk left 08:15 penk joined, c9s joined 08:24 dmq joined 08:27 alester left 08:32 shachaf left 08:34 moritz is now known as moritz_ 08:36 iblechbot joined 08:40 franck___ joined 08:41 drbean joined 08:48 pen1 joined 09:00 shachaf joined
diakopter howdy 09:09
09:09 penk left
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
09:14 jisom joined 09:34 idiotmax left 09:39 ruoso left 09:57 meppuru joined 10:04 ruoso joined 10:08 b_jonas joined 10:10 cnhackTNT left 10:31 chris2 joined 10:39 marmic left
pugs_svn r19312 | ruoso++ | [yap6] NOTES_AUTOVIVIFY.txt now have a very structured summary of my doubts... 10:41
10:41 marmic joined
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
10:48 Alias_ joined, Schwern joined
Schwern Is there a "negative smart match" operator? 10:48
Ahh, !~~ 10:49
10:55 theorbtwo joined 11:01 Kattana left, Kattana joined 11:04 masak joined 11:31 ebassi joined 11:32 jferrero joined 11:37 masak left 11:43 pmurias joined 11:45 jisom left 11:54 meppuru left 11:56 blindfish_ joined 12:02 pmurias left 12:12 fglock_ joined, fglock_ is now known as fglock, chris2 left 12:18 jferrero left 12:24 theorbtwo left 12:35 franck___ left 12:41 franck___ joined 12:43 ivas joined 12:55 cmarcelo joined 12:59 ebassi is now known as ebassi|lunch, ebassi|lunch left, ebassi joined 13:00 ispy_ left 13:13 lyokato_ left, Limbic_Region joined 13:23 Alias__ joined 13:34 alester joined 13:35 masak joined 13:41 ispy_ joined 13:42 alester left 13:43 jhorwitz joined 13:52 pmurias joined
pmurias ruoso: foo(%a<b><c>) shouldn't autovivify 13:55
13:55 njbartlett__ joined 13:56 njbartlett left
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
14:02 rdice joined
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
14:24 pmurias left 14:39 drbean left, pen1 left 14:44 rdice left
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
14:53 kanru left
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
14:55 jferrero joined
ruoso and not the binding 14:55
14:58 b_jonas left
ruoso moritz_, I bet on the yap6 runtime for a faster bootstrapped kp6 15:00
moritz_ ruoso: I hope it is (and works ;)
15:01 TJCRI joined
ruoso fglock, I think I'll consider the capture as the autovivifier 15:02
I can't think in anything more appropriate right now
15:02 gaal joined
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
15:04 Alias_ left
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
15:10 Alias__ left 15:13 rdice joined
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
15:16 c9s left, c9s joined 15:17 ludan joined
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
15:22 pmurias joined
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
15:44 rdice left
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
15:50 seablue100 joined
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
15:56 polettix is now known as poletti, poletti is now known as polettix
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
16:03 seablue100 left, rindolf joined 16:10 c9s left 16:12 masak left
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
16:22 theorbtwo joined 16:27 tewk_ left
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,
16:34 F joined
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
16:40 acmoore joined
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
16:46 mtve joined
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
16:48 corneliu1_ joined
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
16:54 Psyche^ joined
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
17:05 barney joined
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
17:12 Patterner left, Psyche^ is now known as Patterner
[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
17:17 franck___ left
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
17:45 rindolf left
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
17:56 skids joined 17:57 theorbtwo left
fglock btw, Capture and Signature are there too 17:59
(the high-level methods) 18:00
18:01 corneliu1_ is now known as c9s, dlocaus joined
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 :)
18:17 REPLeffect joined
fglock dlocaus: we've been adding even more experimental backends 18:18
dlocaus Perl5v6 and Perl5Cache I believe.
18:19 pmurias left
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
18:22 ivas left
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)...
18:26 __Ace__ left
dlocaus Ok, I think I figured it out (again), the AST produces C code which can compile kp6. 18:26
18:26 meppuru joined
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
18:33 rindolf joined 18:35 ebassi left
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
18:39 tewk joined
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, ^
18:41 meppel-san joined, cognominal_ left
ruoso kp6 will be the compiler forever 18:41
yap6 is just a kp6 backend
as perl5 is
dlocaus (sorry, phone call). 18:44
18:44 bwisti joined
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.
18:45 tobeya joined
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...
18:48 thoughtp1lice joined
fglock dlocaus: fine 18:49
18:49 cognominal_ joined
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
19:05 thoughtpolice left 19:07 meppuru left, c9s left
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
19:19 skogs joined
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
19:24 IllvilJa left 19:25 theorbtwo joined
pugs_svn r19320 | particle++ | [t]: refactoring radix conversion tests for hexadecimals 19:28
19:32 gaal left, jisom joined 19:34 skogs left, Auzon joined
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
19:48 theorbtwo left 19:56 pmurias joined
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.
20:05 fglock left 20:16 jisom left
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
20:17 Limbic_Region left
pugs_svn r19324 | dlo++ | [kp6] made the code neater, minor chagnes 20:21
20:23 Schwern left 20:33 Schwern joined
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
20:43 TJCRI left 20:44 TJCRI joined 20:46 rdice joined 20:47 gaal joined
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
20:58 Schwern left 21:04 REPLeffect left, REPLeffect joined 21:05 Schwern joined 21:15 JTECH_1840 joined, Schwern left, Schwern joined 21:40 pmurias left 21:59 cmarcelo left 22:01 ispy_ left 22:02 BinGOs_ joined, BinGOs left, BinGOs_ is now known as BinGOs 22:16 IllvilJa joined 22:19 rdice left 22:24 Aankhen`` left 22:26 bnjmn-- joined
bnjmn-- perl6!!! do want! 22:26
pbuetow hehe
22:27 barney left 22:38 xdg joined 22:49 rindolf left 22:52 justatheory joined 22:54 Auzon left 22:59 Limbic_Region joined 23:01 blindfish_ left 23:06 sri_ left, sri_ joined 23:07 TJCRI left 23:12 acmoore left 23:20 xdg left 23:21 skids left 23:22 Auzon joined 23:28 Schwern left 23:32 JTECH_1840 left 23:33 bnjmn-- left 23:34 BinGOs left 23:35 polettix left 23:36 BinGOs joined 23:38 Auzon left, ebassi joined 23:41 polettix joined 23:52 ruoso_ joined 23:58 lorn joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!