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.
pugs_svn r19213 | ruoso++ | [yap6] some more work in hash. YAP6_MEM_TRACE now warns about leaking variables in the end... 10:07
fglock [particle]: ping 12:14
pmurias fglock: did some experiments with caching get_method_from_object, dosn't seem to make a big difference 15:30
fglock pmurias: most methods are not inherited, i guess 15:31
and Perl 5 calls are expensive anyway 15:32
pmurias: i have a couple of ideas on kp6/perl6
fglock if we replace mp6 code in kp6 with perl6 code, it might work 15:33
except for the Pad, which perl6 doesn't implement
this could give some speedup with minimal reprogramming
it would still emit Perl 5,
this could be fixed later
avar gimme p6 pad.pm :) 15:39
fglock avar: you will have that :) 15:40
s/emit Perl 5/emit Perl 5 and Lisp/ 15:41
avar yay lithp 15:43
avar fglock: in general more stuff being handled for free will make things easier for me 15:43
The last time it worked I stopped on signatures, protoobjects and objects, methods etc 15:44
stuff like $::Class = ::DISPATCH() should be do-able in the emitter if the backend implements namespaces/stashes for example
fglock I'm trying to figure out the next short-term plan for kp6 15:48
things changed in the last few weeks
our next roadmap milestone would be to integrate the STD grammar 15:51
fglock the most visible change would be to have a precedence parser 15:51
the Perl 5 backend is nearly bootstrapped, but it is way slow 15:53
ruoso fglock, I continue to think it would be better to work on more high-level kp6 runtime
implemengint Scope, Closure as kp6 objects 15:54
that would be usable in any backend
pmurias fglock: what does "replace mp6 code in kp6 with perl6 code means" mean exactly? 15:55
fglock ruoso: agreed
ruoso pmurias, means what I've just said
fglock but we have to figure out how to follow the roadmap in the meanwhile
ruoso stopping depending on p5 runtime
and implement more runtime in kp6-level
fglock no, i mean "perl6", not "Perl 6"
ruoso ah 15:56
ok
perl6 as perl 6 in parrot?
fglock it would run either with MiniPerl6, or "perl6" - yes
we'd have an alternate backend
[particle] btw we expect to have all sanity tests passing today 15:58
ruoso fglock, anyway 15:59
[particle] (only end blocks remain)
ruoso this would mean implementing more high-level
in kp6
ruoso because for you to use the same base for both backends, you need to compatibilze the runtimes 15:59
fglock [particle]: i have a grammar request: class X { ... } - is this doable?
ruoso and you do that by implementing more in kp6-level
fglock ruoso: yes 16:00
[particle] fglock: perl6 or nqp?
yes, it's doable
fglock [particle]: perl6 - I don't see a reason for using nqp if we can use perl6
fglock unless there is one? 16:00
[particle] closer to the emulated hardware? 16:01
i can get class blocks implemented
fglock hmm - but kp6 is meant as a Perl6-in-Perl6
is nqp really faster? 16:02
[particle] i haven't benchmarked perl6 vs nqp
it has no runtime, so it's smaller
ruoso fglock, kp6-perl6 would still require the kp6 runtime
so using nqp will be faster 16:03
as nqp doesn't have a runtime in itself
right, [particle] ?
[particle] yes, but you may need to create your object model, so you may end up with a small runtime lib
ruoso [particle], the point is that kp6 is already a runtime
[particle] anyway, why worry about speed yet?
true, kp6 is a runtime 16:04
ruoso the point is that it must be fast enough to have a practical use
[particle] so is perl6
ruoso kp6-kp6 doesn't
fglock [particle]: speed is the main reason to leave the perl5 runtime
our alternate option is plain-C
ruoso yap6
[particle] fglock: understood, but i don't think the speed diff between nqp and perl6 is significant compared to the diff between perl5/nqp
ruoso [particle], the point is that, if kp6 is a runtime in itself, and perl6 is other runtime 16:05
pmurias [particle]: is nqp much slower?
[particle] and where nqp/perl6 has much optimization potential, perl5 has little
ruoso there's no point in stacking them
ruoso because, as nqp is not a runtime, 16:06
[particle] i expect nqp will be faster than perl5
ruoso it would be kp6-parrot directly
while using perl6 would stack to runtimes
kp6-perl6-parrot
s/stack to/stack two/
fglock wait - we are talking about two different things
using perl6 to run kp6, as in "kp6-in-perl6" 16:07
ruoso which in turn is kp6-in-perl6-in-parrot
fglock using the code emitted by kp6 to run kp6, as in "kp6-kp6"
pmurias ruoso: the perl6 runtime has to eventually evolve into something we can use
ruoso pmurias, the point is that then kp6 has no point in being there at all 16:08
we just need to work on perl6 directly
[particle] eventually, perl6 runtime will be able to support everything that kp6 runtime does 16:08
ruoso exactly... but both kp6 and perl6 are *runtime* projects
that happens to have a grammar parser
[particle] yes, once perl6 runtime supports everything kp6 runtime does, ku6 runtime can be removed 16:09
ruoso so there's no point in stacking kp6-in-perl6
better to work in perl6 directly
fglock exactly 16:09
ruoso nqp, otoh, 16:10
[particle] so, are you suggesting that you help extend perl6 now?
fglock if you can run kp6 over perl6, you are emulating a bootstrapped compiler
next step, you fix it to be a real bootstrapped compiler
ruoso [particle], that was always an option and still is 16:11
[particle] fglock: agreed
ruoso what I don't get is how you deal with three different levels of runtime
parrot, perl6 and kp6
all at the same time
[particle] it's not at the same time
it's chained emitters
fglock perl6 and kp6 runtimes will be unified 16:12
it doesn't mean it's easy
ruoso fglock, ok... that's a point
if perl6 and kp6 become compatible
it makes sense
fglock unified = the Parrot backend
[particle] yes
pmurias ruoso: they have to 16:13
ruoso pmurias, not necessarly
they can be two different Perl 6 runtimes on top of parrot
ruoso or even on top of other runtimes 16:13
fglock there is a single thing we must find consensus,
about the Pad structure
which perl6 doesn't need, and kp6 uses a lot 16:14
ruoso is the calling convention already consensual?
fglock Parrot abstracts that
ruoso kp6 doesn't
pmurias fglock: want they need it once they do BEGIN block?
fglock [particle]: re help extend, yes - we have to :) 16:15
ruoso I think it makes more sense to work in perl6 directly if that's where we head to
fglock pmurias: no idea, we need to talk more about that
[particle] where do you implement 'use'? i wanna do it for perl6 now, so i can start testing 02-test-pm
fglock [particle]: "use" is a BEGIN block 16:16
which reads more source code
ruoso but I still think kp6 have a point which is to implement a vm-independent Perl 6 runtime
[particle] urk. we still don't have end/begin blocks
i think for now i can implement use without begin
fglock [particle]: we could work on that
[particle] fglock: we hope to have END support by end of day 16:17
pmurias [particle]: kp6 dosn't implement use correctly too
[particle] yeah, i figured kp6 needed to cheat
fglock pmurias: "use" was implemented before we had BEGIN :(
i've been meaning to fix that...
[particle] fglock: there's various ways to implement END, so we need to figure out the best way, then just do it 16:18
pmurias fglock: having Test.pm, killing the GLOBAL hack, and use strict would be great benefits
fglock the way we implement END is to build a stack of BEGIN blocks, which get executed after the main compilation
[particle]: do you have string eval, or AST eval? 16:19
[particle] perl6: 'die'("eval unimplemented") 16:20
fglock ruoso: re vm-independent, it can continue to be
exp_evalbot kp6: RESULT[error in Block at compiled/perl5-kp6-mp6/lib/KindaPerl6/Grammar/Sub.pm line 753, <> line 1.␤*** Syntax Error in Block: missing closing curly bracket ␤]
..pugs: OUTPUT[*** Cannot cast from VStr "die" to Pugs.AST.Internals.VCode (VCode)␤ at /tmp/BK6S8SD7og line 1, column 1 - line 2, column 1␤]
..p6: OUTPUT[Method 'viviself' not found␤current instr.: 'parrot;PAST::Compiler;keyed' pc 4822 (src/PAST/Compiler.pir:1194)␤called from Sub 'parrot;PAST::Compiler;post_children' pc 1057 (src/PAST/Compiler.pir:133)␤called from Sub 'parrot;PAST::Compiler;post' pc 1252
exp_evalbot ..(src/PAST/Compiler.pir:217)␤called from Sub 'parrot;PAST::Compiler;post_children' pc 1... 16:21
ruoso fglock, the thing is that it still isn't
fglock, kp6 still have a way to go to become a vm-independent runtime 16:22
today it is a p5-dependant runtime
[particle] oh, you stupid bot!
fglock ruoso: re way to go, yes - but it's a matter of adding more AST transformation modules 16:23
ruoso fglock, not only that... 16:24
ruoso implementing Scope, Closure, Method etc 16:24
is part of that
all of these are p5-dependant today
fglock [particle]: re END blocks and my discussion with ruoso - END blocks need to be executed in the scope where they were compiled 16:29
and the Perl 6 definition of scope is not easily represented in Perl 6 16:30
kp6 cheats by using closures to build scopes
phone & 16:33
fglock /phone 16:35
fglock the END block AST contains a pointer to the scope where it will be executed 16:43
oops 16:46
[particle] we're thinking about using coroutines to register blocks as END, START, etc, and yielding
fglock [particle]: i'm wrong,
I'm talking about CHECK blocks 16:47
cjfields I'm a bioperl programmer. We have been giving serious thought towards reimplementing bioperl via perl6. What would be the best place to start (kp6,parrot,pugs)? 17:25
jcpiza download cpan 17:26
cjfields Hmm? 17:27
jcpiza and reuse the existent libraries
many are from perl5
cjfields checking cpan... 17:29
fglock cjfields: you can start with pugs, if you don't need speed for now
cjfields Yeah, tried getting pugs to compile (using ghc 6.8.1), kerplooey.
fglock it depends on which Perl 6 features you are mostly interested 17:30
cjfields Saw there is a diff included, but still problematic.
fglock cjfields: i'm using ghc 6.6.1
cjfields fglock: Might need to downgrade to ghc 6.6.1 to get it running. 17:32
I think we would be interested in getting the core modules set up; parsers to follow, so I/O, exceptions, etc. 17:33
Then we would worry about parsers for various formats.
Auzon ok 17:58
Oops.
cjfields Well, that's a pain. I'm using Leopard, which ghc 6.6.1 apparently has problems on. ghc 6.8.1 works, though, but doesnt seem to play with pugs very nicely. 18:06
May have to play with the diff'd files. I also noticed ghc 6.8.2 is out already. 18:07
fglock gives up C-- 18:30
barney Is rubinus next?
fglock barney: it doesn't seem to be useable yet, but I'll take a closer look later 18:36
barney cool 18:39
pugs_svn r19214 | ruoso++ | [yap6] Hash and List now have ELEMS. YAP6_ELEMS(value) returns a YAP6__CORE__int* 18:48
ruoso fglock, which type have the response to WHAT? 18:55
is it WHAT?
hmm
ruoso with memory problems...
ruoso figured out.... 18:57
WHAT will return the dispatcher in yap6
it's good when the things just fit :)
pugs_svn r19215 | ruoso++ | [yap6] hash_proxyscalar_dispatcher_FETCH 18:59
r19216 | ruoso++ | [yap6] YAP6_WHAT(value) implemented 19:04
pugs_svn r19217 | ruoso++ | [yap6] typecasts in YAP6_WHAT 19:07
fglock ruoso: .WHAT is a prototype object, it's of the same type as the object 19:11
pugs_svn r19218 | fglock++ | [kp6-perl5] "but" doesn't modify the original value 19:37
fglock kp6: my $x = 0; $y = $x but True; my $z = ($y.WHAT).new; say ( $z ?? 1 !! 0 ); 19:49
exp_evalbot r19218: OUTPUT[0␤]
fglock is this correct? # does "but" alter the prototype or not 19:50
ferreira open for suggestions and corrections: feather.perl6.nl/~ferreira/perl6-op...fault.html 20:31
lambdabot Title: default.pod6
ferreira This is a micro-article on the // operator
avar ferreira: 'use 5.10' is recommended 20:39
also, I'd mention right away that C<x // y> = C<defined(x) ? x : y> 20:41
ferreira sounds like a good idea
Auzon Would it be worth mentioning the low precedence version? (That still exists, right?) 20:42
[particle] err 20:43
ferreira Not sure. I thought of introducing it in another article about "and", "or" and "orelse" (or whatever name it has) 20:44
avar: $ perl -e 'use 5.10' gives me Perl v5.100.0 required (did you mean v5.10.0?)--this is only v5.10.0
[particle] yes, you want 5.010 20:45
perl 5.8.1 aka perl 5.008_001
avar urgh, wth 20:48

Powered by Cro and the Raku® Programming Language.

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

Thank you!