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.
avar eval: 3e4 00:57
kp6: 3e4
exp_evalbot r19571: OUTPUT[no method 'APPLY' in Class 'Undef'␤ at compiled/perl5-kp6-mp6/lib/KindaPerl6/Runtime/Perl5/MOP.pm line 345␤ KindaPerl6::Runtime::Perl5::MOP::__ANON__('HASH(0x824be84)', 'APPLY') called at compiled/perl5-kp6-mp6/lib/KindaPerl6/Runtime/Perl5/MOP.pm line 169␤
..main::DISPATCH('HASH(0x824be84)', 'APPLY') called at compiled/perl5-kp6-mp6/lib/Kin...
avar kp6: 3000 00:58
exp_evalbot r19571: RESULT[3000]
Juerd_ How do captures work in regexes, with & or ~~? 01:08
Are both the LHS and RHS used, in that order, or is one of both sides ignored? 01:09
TimToady captures are numbered sequentiall across & as if it weren't there, I think 01:27
a ~~ is a submatch that just happens to call our own rule, so it should be the same as an ordinary <foo> submatch
oh wait
you're not asking about <~~> 01:28
TimToady I think captures are probably number across ~~ as well 01:28
*numbered 01:29
since ~~ is really a funny way to write an & anyway
but my brain is in sideways currently, so I could be looking out my earhole 01:30
Juerd_ TimToady: Okay, no surprises there. That's great :) 01:52
What's the easy way to start using grammars? 01:53
Parrot's perl6?
pugs_svn r19572 | putter++ | [kp6] some scattered progress. a few t/kp6/ tests pass. 03:55
ruoso @tell TimToady After I got home, I realised what my problem was. I reminded nothingmuch's "less is more" mantra, and noticed that what is making things weird is that I'm defining too much API. If I leave the stack API simpler, I can simply substitute the implementation at any time for a more optimized one, or even have more than one implementation at the same time... I don't need to make it right in the first time... 10:21
lambdabot Consider it noted.
ruoso @tell TimToady I can even start working with my lame stack implementation now, as it's simple to implement, and replace it later by a saner one... 10:35
lambdabot Consider it noted.
nothingmuch ruoso++ # very zen of you =) 11:58
ruoso nothingmuch++ # you're my zen master ;) 12:01
Juerd_ Does the non-capturing <.foo> work hierarchically? 12:13
If so, is there a way to "include" a rule, while capturing what it captures as if it were literally in the regex? 12:14
Juerd_ If not yet, I suggest the possibility for having a null alias: /<=foo>/ 12:23
pugs_svn r19573 | ruoso++ | [smop] Problem Solved!!!! now we have the "interpreter instance" which holds a reference to the continuation. The continuation is the "current state of an interpreter implementation", and the "interpreter instance" delegates to the current continuation the interpreting methods... 12:26
..the default implementation in smop will be my lame stack for now, and sm0p is a language to specify it. sm0p2C.txt updated to reflect what it means.
ruoso does perl5 have a way to make it eval only one node of the optree? 12:27
ruoso really believe there will be ways to integrate the run loop of smop and p5 12:28
agentzh oh my god... 12:31
lambdabot agentzh: You have 1 new message. '/msg lambdabot @messages' to read it.
agentzh @messages
lambdabot fglock said 1m 7d 21h 11m 5s ago: there is a v6.pm cpan-testers report with "t/01-sanity/02-counter...............greediness control not implemented: [ '\»' | . ]" - is this PCR related?
agentzh ......
fglock it never forgets :)
agentzh *nod*
nothingmuch ruoso: look at Runops::Switch etc 12:32
you can overload the optree with a custom optype
that switches to the smop loop on the fly
and then just embed smop optrees in the p5 one 12:33
*handwaving*
ruoso scared... :)
nothingmuch i think OP_CUSTOM can do it 12:34
hmm
you don't even need to override the run loop
ruoso In fact, I only need to call it one step at a time 12:35
nothingmuch as long as perl's runloop is reentrant you can recurse back into it
ruoso nothingmuch, I'm starting this question in #p5p... rgs is starting to answer me
nothingmuch *nod*
i noticed 12:36
pugs_svn r19574 | ruoso++ | [smop] it is SMOP_DISPATCH and not SMOP_MESSAGE. 12:59
r19575 | ruoso++ | [smop] porting the tests to the new interpreter model... 13:11
ruoso for the record... p5 <-> smop runloop integration will be absolutely transparent, where smop will hand the execution to the p5 optree as CPS and vice-versa... this is important as to smop implement interrupts using CPS even if the interrupting code is a p5 optree execution... 15:16
bphillip1 CPS? 15:28
(for the uninitiated)...
ruoso Continuation-Passing-Style
can I count on wiki.pugscode.org for some long term? or is it kinda deprecated and subject to removal? 15:29
diakopter ruoso: what kind of things do you want to wikify? 15:33
ruoso smop development info
diakopter probably I'd suggest using TPF's Perl 6 wiki(s)
and add an implementation
ruoso yeah... fglock told me the same 15:34
ruoso signing in
[particle] yep, www.perlfoundation.org/perl6
lambdabot Title: Perl 6 / Perl 6
fglock [particle]: would you have some time later, to help me hack eval() in rakudo? 15:40
[particle] yes, in a few hours 15:42
fglock nice
[particle] i'm currently looking at adding exceptions to rakudo, to support warn, die, return, etc 15:43
diakopter will pmichaud/rakudo require committers to sign TPF's contributor agreement (to bind to the AL2, if nothing else)? 15:50
[particle] it's currently under that license, in tpf repo, so yes
diakopter I mean when it's not in that repo
[particle] unknown 15:51
diakopter I assume it will still be packaged/released under the AL2
[particle]: unknown to you, or unknown to the decider(s)? 15:52
unknown to you [only], I mean
[particle] definitely unknown to me
i don't know who else it's unknown to, except you :) 15:53
diakopter :D
diakopter ponders "known to" versus "known by"
ruoso www.perlfoundation.org/perl6/index.cgi?smop 15:58
:)
lambdabot Title: SMOP / Perl 6
[particle] ruoso++ # btw i edited for spelling 16:02
ruoso [particle], thx 16:03
TimToady ruoso: if you take a smop continuation and some of the state is on the p5 stack, how is the p5 stack managed? 16:29
lambdabot TimToady: You have 2 new messages. '/msg lambdabot @messages' to read them.
TimToady what if you return to p5, peel up some of the stack there, then resume the smop continuation? 16:31
ruoso TimToady, we are going to intercept the p5 loop, interfacing it with the smop loop 16:33
change the default p5 runloop
to one that interfaces with smop
TimToady you might have to dup the p5 stack and bump the refcnts when you take a continuation 16:34
japhb ruminates on the fact that the CS discussed in IRC these days is *way* more advanced than what he got in college ....
TimToady runloop is easy, I'm worried about the p5 stack
ruoso TimToady, you mean, for the case that I call a method twice with the same continuation?
TimToady which is single-threaded
ruoso is it legal?
TimToady I mean, if you save a continuation somewhere for later use, and then return to p5 16:35
p5 will merrily blow away some of its stack that the smop continuation might be relying on
ruoso why would it? 16:36
TimToady because when you pop an ordinary stack and then put something else on it, you don't have what you had before 16:37
ruoso TimToady, I wouldn't pop it
TimToady p5 pops its own stack every time you return
ruoso everytime I "eval" an op
yes
the thing is I would only eval one op at a time
using the smop runloop to that 16:38
interfacing *directly*
TimToady then you need to emulate the p5 stack for those ops
ruoso I think I got what you mean... 16:39
ruoso but no, I don't expect the integration to avoid the typemapping 16:39
you still need a both-ways typemapping
TimToady most p5 ops assume they can operate directly on an SV** tha tis the stack
ruoso exactly, you'll need to encapsulate the SV** s in the SMOP__Object* and vice-versa 16:40
typemapping is mandatory
when I say transparently is not about how to transfer data from one side to another...
TimToady 'kay, sounds like you've thought about it 16:41
ruoso that's the whole thing in the ResponderInterface stuff
this is actually, one of the features of Perl6 that I have intentionally overlooked. I strongly don't believe that there's a way to interoperate without explicit typemapping 16:42
TimToady you'll have to capture control of stack reallocations that p5 can do any time it pushes 16:42
that's currently just a macro
so you're probably talking about compiling your own p5 to go with smop 16:43
but compiling it "funny"
you should probably talk to Nick about the problems in getting ponie going
you may run into some of the same issues 16:44
ruoso I still didn't got into the specifics on how to implement it... and will probably do it after having something more in smop... but my feeling is that this kind of problem is work-aroundable, at least... 16:45
TimToady @seen nwc 16:46
lambdabot I haven't seen nwc.
[particle] sounds like the "inferior runloops" problem 16:58
TimToady [particle]: not quite, we're trying to keep the runloops mutually "stackless", so they're not inferior in that sense 17:20
the problem is that the two different kinds of opcodes have two very different notions of how to run a stack 17:21
TimToady so the p5 that comes with smop is unlikely to be a stock libperl.so 17:21
it probably needs to be compiled with different definitions for its stack manipulation macros 17:22
TimToady and there are likely to be opcodes that need some rewriting in any case 17:23
[particle] TimToady: (mutually stackless) gotcha. 17:24
ruoso TimToady, I'll be close to #p5p when I start thinking about it in more details... Considering the latest op manipulations I've been seeing, I'm more and more impressed with perl5 flexibility... 17:27
TimToady well, I did try to design it stackless, but there was also some element of clueless in there at the time. 17:36
the main problem is going to be leaky abstractions; C macros aren't very good at encapsulation... 17:37
but perhaps you could convince p5p that smop should be the default runloop for 5.12...nah... 17:38
ruoso heh... that would be pretty 17:39
TimToady but you should at least get it blessed as "alternate core" so it gets maintained
TimToady just make it good enough and let darwin sort it out. :) 17:40
ruoso :P
pugs_svn r19576 | ruoso++ | [smop] All SMOP documents and information resides now in www.perlfoundation.org/perl6/index.cgi?smop . Cleaning up svn repository a little bit.
lambdabot Title: SMOP / Perl 6
TimToady Note to posterity: I am not claiming to not still be somewhat clueless. :) 17:41
ruoso hehe
ruoso feels much better in maintaining docs such as ROADMAP in a wiki than in plain text... 17:43
ruoso TimToady, perl5 stacklessness: but isn't fixing the non-stackless things to be considered wishlist bugs? 17:46
TimToady yes, but anything that could break backward comptibility is hard to push through p5p, even at a major version change like 5.12. 17:55
ruoso hmm.. sure.. I actually have no clue on the severity of the possible problems... 17:58
TimToady but I think that pugs has adequately demonstrated that we can at least bridge the two interpreters successfully even if we can't manage the integrated runloop semantics. 18:00
I think it's definitely worth a shot though 18:01
TimToady bbl & 18:03
pugs_svn r19577 | ruoso++ | [smop] starting to prepare the autotools... 18:19
r19578 | ruoso++ | [smop] autotools in better shape... still not ready... 18:31
Juerd_ One of the reasons I really liked open source software 10 years ago was that there wasn't the license fuss. 18:40
Little did I know.
Khisanth 10 years later you like it because of the license fuss? 18:42
ispy_ haha 18:45
Juerd_ Khisanth: No 18:57
I've grown fond of the "Do What The Fuck You Want To Public License" 18:58
sam.zoy.org/wtfpl/
lambdabot Title: WTFPL - Do What The Fuck You Want To Public License
pugs_svn r19579 | ruoso++ | [smop] autotools ready... the code already compiles.. the test does not compile because of still undefined symbols... but that is what it was supposed to happen now 19:08
pugs_svn r19580 | ruoso++ | [smop] Ok, now nothing compiles again... smop_lowlevel.c is already counting on the sm0p preprocessor (there is some sm0p code inside the C code). 19:25
[particle] zomg! your shoelace broke! 19:26
ruoso heh 19:27
now I neeed the sm0p preprocessor
pugs_svn r19581 | ruoso++ | [smop] more preparations to the sm0p preprocessor. 19:40
tewk_ 20:39
ruoso home & 20:43

Powered by Cro and the Raku® Programming Language.

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

Thank you!