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 00:37
00:40 ispy_ joined 00:46 meppuru left 01:04 bsb joined 01:09 ispy_ left 01:12 nipotaway is now known as nipotan 01:14 cnhackTNT joined 02:01 [particle1 joined 02:05 jjore-m left, devogon left 02:17 japhb joined
japhb Is Perl6-on-Parrot mostly discussed here or on #parrot@irc.perl.org? 02:18
02:19 [particle] left
allbery_b the latter, mostly 02:19
02:20 spacechicken joined
japhb allbery_b: OK, thank you 02:20
02:21 spacechicken left 02:22 dvorak left, Andrew__ joined, cmarcelo left 02:26 jferrero left 02:28 kanru joined 02:39 Limbic_Region joined 02:49 c9s left 03:07 lyokato_ joined 03:18 Limbic_Region left 03:22 alester joined 03:23 polettix left 03:29 sjansen joined 03:30 sjansen left 03:44 Andrew__ left 03:46 DaGo left 04:01 Psyche^ joined 04:09 fridim_ joined 04:18 Patterner left, Psyche^ is now known as Patterner 04:35 alc joined 04:49 drbean joined 05:09 drbean left 05:16 lyokato_ left 05:32 stevan__ left 05:35 stevan_ joined 05:37 lyokato_ joined 05:46 drbean joined 05:51 lyokato_ left 05:53 Auzon joined 06:09 lyokato_ joined 06:11 Alias_ joined, xinming left 06:21 fridim_ left 06:23 drbean left 06:42 xinming joined
pugs_svn r19353 | rhr++ | [Unicode.pm] process PVA, implement most of the is* and in* tokens 06:44
06:52 jjore joined 07:11 stevan_ left, stevan_ joined 07:15 devogon joined
pugs_svn r19354 | Darren_Duncan++ | ext/Muldis-DB/ : in SeeAlso.pod, added new prospective item MuldisX::DB::Simple, high priority 07:20
07:23 iblechbot joined 07:25 zgh joined 07:26 zgh left 07:30 jjore left 07:37 drbean joined 07:46 alc left 07:53 lyokato_ left 07:54 Schwern joined 08:00 drbean left 08:02 Auzon left 08:16 franck___ joined, Jamtech joined 08:22 Jamtech left, Jamtech joined 08:32 Jamtech left 08:33 IllvilJa joined 09:00 drbean joined 09:07 lyokato_ joined 09:19 rindolf joined 09:24 drbean left, penk joined 09:38 Aankhen`` joined 09:40 rindolf left 09:44 Jamtech joined 09:52 Jamtech left 10:02 Daveman left 10:03 pen1 joined 10:06 ebassi joined 10:23 cnhackTNT left 10:24 penk left, IllvilJa left 10:25 kanru left, drbean_ joined, drbean__ joined 10:32 drbean__ left 11:04 drbean_ left 11:14 masak joined 11:25 luqui joined 11:35 luqui left 11:36 mj41 left, ruoso joined 12:00 araujo left 12:11 pen1 left 12:22 Limbic_Region joined 12:24 iblechbot left 12:30 ebassi is now known as ebassi|lunch, IllvilJa joined 12:34 ispy_ joined 12:36 nipotan is now known as nipotaway 12:37 lorn joined 12:52 lyokato_ left 13:08 thoughtpolice joined 13:10 Limbic_Region left 13:12 meppuru joined 13:16 cmarcelo joined 13:19 lorn is now known as Lorn
ruoso I think I have it clear now... I still need to write it down, but I'll design YAP6 using the concepts from the Stackless project. 13:20
YAP6 will hold a "current frame" object that will be passed through all around 13:21
the "current frame" is the call stack
the last node of the call stack, actually
avar is this in a state where it can be used with kp6? 13:22
13:22 Daveman joined
ruoso avar, I've gone into a major refactoring in YAP6 13:22
but implementing the frame stack in YAP6 would put it into position of being a kp6 backend 13:23
take a look at the include/yap6*.h
but continuing...
the current frame would contain the reference to which message should be sent to which object 13:24
and two references
the outer frame
and the continuation frame
then yap6 would have a simple loop where the top-most frame would be executed 13:25
and popped
while putting the continuation frame (if any) as the top-most frame
and going again
when something wants to call another code
it would just add another frame on the top and return 13:26
and that's it
avar, btw... take a look at the NOTES_BOOTSTRAP.txt file
it explains a lot
13:30 iblechbot joined 13:31 stevan_ left, stevan_ joined 13:40 dlocaus joined 13:46 xyxu joined 13:48 xyxu left
pugs_svn r19355 | dlo++ | [kp6] Added YAML to the PREREQ_PM 13:49
r19356 | dlo++ | [kp6] minor typo correction 13:52
13:53 alester left 13:55 Aankhen`` left 14:04 aindilis left, aindilis joined
pugs_svn r19357 | ruoso++ | [yap6] NOTES_STACKLESS.txt on how to implement YAP6 without being bitten by the C stack. 14:08
14:10 rindolf joined
ruoso @tell fglock please take a look at svn.pugscode.org/pugs/v6/yap6/NOTES...CKLESS.txt 14:10
lambdabot Consider it noted.
14:16 IllvilJa left
ruoso TimToady, if you have some time, could you please take a look at svn.pugscode.org/pugs/v6/yap6/NOTES...KLESS.txt? I think this solves the C stack problem... 14:19
14:26 acmoore left, jhorwitz joined 14:30 rindolf left 14:32 dmq left 14:35 drbean joined 14:41 chacha_chaudhry joined 14:46 ebassi|lunch is now known as ebassi 14:53 chacha_chaudhry left 15:01 alester joined 15:04 ivas joined
pugs_svn r19358 | dlo++ | [kp6] Added Perl5V6 to kp6-mp6-OBJ for Win32 systems 15:08
15:09 TJCRI joined 15:10 chris2 joined
pugs_svn r19359 | dlo++ | [kp6] Bottomed out some code, improved code clarity a tiny bit :) 15:11
15:18 alc joined 15:19 drbean left 15:32 thoughtp1lice joined 15:41 jferrero joined 15:45 thoughtpolice left, IllvilJa joined 15:46 ferreira joined, mj41 joined
pugs_svn r19360 | ruoso++ | [yap6] some advances in defining the stack. 15:57
16:00 rhc left 16:09 Aankhen`` joined 16:21 schmalbe joined 16:25 Psyche^ joined 16:41 Patterner left, Psyche^ is now known as Patterner
pugs_svn r19361 | ruoso++ | [yap6] the YAP6 stack now seems ok. See NOTES_STACKLESS.txt to see how it will work. 16:47
r19362 | ruoso++ | [yap6] The "outer" reference is kept only on the currently selected node. 16:51
16:56 ozy` joined 17:01 masak left, jferrero left
pugs_svn r19363 | ruoso++ | [yap6] Note about return values. 17:04
17:16 ting left 17:28 Lorn left 17:29 alc left 17:37 araujo joined 17:40 franck___ left 17:45 ozy` left 17:48 DaGo joined
pugs_svn r19364 | ruoso++ | [yap6] Defines how to use the result from past nodes on other calls. 17:55
17:57 ispy_ left
ruoso home & 17:57
17:58 jjore joined 18:08 tobeya joined 18:13 rdice joined 18:14 kane_ joined 18:16 ruoso left 18:18 bwisti joined 18:22 Jedai left 18:26 ebassi left
TimToady @tell ruoso you seem to be assuming the stack is unwound to a fixed jail while propagating exceptions; p6 requires the stack to stay there while the exception handlers decide dynamically which one to unroll to (if any). at most a static jail flag can tell you that an exception handler *might* handle it 18:31
lambdabot Consider it noted.
18:37 kane__ joined 18:38 kane_ left 18:39 tobeya left 18:48 fridim joined 18:49 ivas left 18:52 Muixirt joined 18:56 hexmode joined 19:03 Botje joined 19:05 TJCRI left 19:19 barney joined 19:20 polettix joined 19:21 Auzon joined 19:26 TJCRI joined 19:28 amnesiac joined 19:31 dlocaus left, dlocaus joined 19:34 schmalbe left 19:39 jferrero joined
Botje Hello everyone, I'm trying to get pugs to build on GHC 6.8 19:39
19:41 marmic left 19:44 tobeya joined 19:45 marmic joined, fridim left 19:46 pmurias joined
pmurias Botje: lots of people try and fail... 19:46
Botje apparently :( 19:48
I'm currently figuring out a way to hack out the parrot embedding
19:48 jisom joined 19:51 ruoso joined
ruoso back 19:53
lambdabot ruoso: You have 1 new message. '/msg lambdabot @messages' to read it.
ruoso TimToady, re dynamic jail: This means that what I've called "jail" is not a flag, but a value to which the exception can ask something to decide if it stops there or continues unwinding... 19:55
Botje how do I tell pugs not to build the embedded parrot interpreter? 19:58
ruoso Interesting is that the exception would manipulate the stack to be able to call the jail check and continue afterwards...
20:00 japhb left
ruoso hmm... svn seems down... 20:05
pmurias, are you following YAP6 last developments?
Khisanth Botje: remove parrot from your $ENV{PUGS_EMBED} 20:06
pmurias ruoso: i read NOTES_STACKLESS, haven't looked at the code 20:08
20:08 Maddingue left 20:09 Maddingue joined
TimToady ruoso: you say "or continues unwinding", but it's not unwinding while it's deciding where to unwind to. unwinding is a separate operation afterward 20:10
20:11 pjcj left, pjcj joined
TimToady (assuming by "unwinding" you mean deallocating frames) 20:11
20:11 Muixirt left, BinGOs left
pugs_svn r19365 | ruoso++ | [yap6] low-level operations will actually be methods in some special metaclasses and available to the high-level. Changing the "jail" description as suggested by TimToady++ 20:11
ruoso TimToady, yes... actually the exception is the one that manipulates the stack anyway 20:12
TimToady but maybe unwinding is rather more nebulous in the presence of continuations anyway
ruoso it can decide how to do it
20:13 Muixirt joined, BinGOs joined
ruoso the stack only have few operations 20:13
TimToady it's just easy for warnings to be implemented in terms of continuations if we can most of the time just do a return from the thrower
assuming that's more efficient than resurrecting a continuation, which it probably isn't when we have real continuations
20:14 tobeya left
ruoso I'm not sure I got what you mean 20:14
TimToady nevermind, with real CPS it probably doesn't matter 20:15
ruoso CPS?
TimToady continuation passing style
ruoso hm
TimToady if unwinding is really just letting the GC harvest no longer referenced frames, and not something active, than it's already going to run the exception handlers before unwinding 20:16
20:17 jisom left
TimToady assuming anything that wants the possibility of resuming like a warning has taken a continuation to the resumption 20:17
ruoso hmmm... now I got it... 20:18
TimToady throwing an exception without a resumable contination still wants to be done in the context of the error so that we can harvest any debug info from the call stack before unwinding
unlike p5 where we unwind before running handlers, so that info is gone 20:19
p6 does it more like Lisp
ruoso looking at the ascii art in the NOTES_STACKLESS, the warning case would be something like: 1 -> 2 -> 3 (frame saved as an argument to warning instead of being destroyed, then the frame is dropped, a new frame is created to invoke warning, which instead of dropping to the original frame, replaces the saved frame and the execution continues..) -> 4 -> 5 20:21
pmurias ruoso: will yap6 be a stack based or a register based vm? 20:22
ruoso pmurias, well... I'm not sure how to call it... 20:23
pugs_svn r19366 | dlo++ | [kp6] Added copyright information
ruoso it doesn't seem to be neighter one of them in the canonical sense
I mean...
it's stack based
but not in the same sense as p5 20:24
20:24 tobeya joined
pmurias ruoso: why isn't struct frame {frame* prev;...}; enough? i don't fully understand what do you need the stack for 20:24
ruoso pmurias, the stack is necessary so you can freely manipulate the stack 20:25
if you just received the pointer to the frame, you wouldn't be able to manipulate
pugs_svn r19367 | dlo++ | [kp6] Added some documentation 20:26
ruoso the stack defines which one is the "currently selected" node
pmurias ruoso: i would be a single linked list
20:27 japhb joined, Schwern left
pmurias so i would be able to navigate it using the prev pointer 20:27
ruoso but how would you add a frame on top?
pmurias prev being outer
ruoso: is it possible to navigate from the outer frame to the inner one? 20:28
ruoso no, but an inner frame may have been saved before
20:28 thoughtp1lice is now known as thoughtpolice
ruoso and you may want to restore it 20:28
I mean... 20:29
a frame** would probably be sufficient
instead of a plain frame*
but that's what the stack is
pmurias why frame**?
ruoso because you need to know which one is the current active frame
and you need to be able to change that 20:30
without counting on the C stack
pmurias where do you keep the active frame?
ruoso in the stack
pmurias and the stack?
ruoso the stack is in the C stack
but the C stack doesn't recurse 20:31
you keep returning in every call
pmurias the stack is in the current thread?
ruoso the yap6 stack isn't even a global
in the case of a new thread
it would be possible to create a new stack
that wouldn't return to the current context
async { } #for intance 20:32
pmurias async creates a new thread
ruoso and a new stack
which is not connected to the current stack 20:33
ruoso notes that the lexical scopes continues to be conected...
even if the stack isn't
and when the stack is empty, the interpreter just finish doing its job 20:34
and in the async case, the thread would exit
pmurias ruoso: i think the frame** would be better
ruoso but with the stack, I can expose it to the high-level
and I then can have a AST->StackNodes transformer written in P6 20:35
The Code implementation would point to AST,
and when called, create a new stack frame and transform the first level of ast to stack nodes
pmurias ruoso: can't the high-level use frames?
ruoso but frame** is not an object 20:36
while stack is
pmurias frame could be an object
ruoso frame is an object
but frame** wouldn't be
in yap6 *everything* is an object 20:37
20:37 ferreira left
pmurias you can use a wraper around frame** 20:37
ruoso that's precisely what stack is
ruoso is very happy because the concept seems to be bullet-proof so far... 20:39
pmurias i think it would work, i don't like it at all but it's your choice 20:41
ruoso pmurias, what you don't like about it 20:42
?
pmurias it's over complicated 20:43
ruoso I'm honestly open for suggestions... 20:44
please, explain :)
pmurias trying to figure why the python folks do it that way 20:47
dlocaus @tell fglock I have looked at the Makefile.PL, I was able to factor some code out into a YAML file, which reduced the "intimidation" factor of the Makefile.PL by quite a bit. I also made a few other "misc" changes, that improved the file. However, I was unable to find any way to fix any of the "FIXME"s in the file. In regards to the "all :: " setting, it seams that the way it was done in there is the only way to do it. 20:48
lambdabot Consider it noted.
ruoso pmurias, python mainstream didn't adopt the stackless thing 20:49
it seems that they didn't like the idea of having coroutines and continuations in python
too "guru" thing
(as saw in an article somewhere that I don't recall) 20:50
pmurias the push the function on the stack,and execute it in the next loop iternation thing dosn't seem logical to me
ruoso pmurias, take a look at www.stackless.com/stackless.htm . It might help 20:51
lambdabot Title: stackless
pmurias looking at it 20:52
i think the do it for internals comability 20:53
20:53 barney left
pmurias * compability 20:53
ruoso: have you looked at parrot internals?
ruoso pmurias, I've tried to... but wasn't able to really understand much 20:54
pmurias i haven't looked at it much myself, but from the "Playing With Bird Guts" talk at the yap6 i remember it is also stackless 20:56
ruoso pmurias, oh yeah... parrot is register-based 20:57
but it's register based on the high-level
yap6 is only stackless in the C level
and just that
it's stack based for the high-level
btw... funny to notice that yap6 is a good name :) being used in the place for yapc ;) 20:58
and parrot is a real vm
while yap6 is just a runtime library... 20:59
this puts everything in different perspective
pmurias ruoso: i got an impression from stackless.html that python wasn't a real vm either 21:00
;)
ruoso: i don't know how the high-level stuff will look like in yap6 21:01
i have a vague idea how to do it with registers and computed goto's 21:03
ruoso: is it ok for you to use a computed goto(it would be possible to fake it with switch) 21:06
ruoso pmurias, search for STACK__Stack__Init in the NOTES_STACKLESS
pmurias, got would manipulate the stack to put some other node as the selected one
s/got/goto/
[particle1 computed goto is gcc only, no? 21:07
21:07 [particle1 is now known as [particle]
pugs_svn r19368 | dlo++ | [kp6] Added documentation to the Makefile.PL & perltidy'd it. 21:07
ruoso [particle], I think pmurias was talking about it in the high-level
[particle] ah, well, fine then 21:08
pmurias [particle]: yes 21:09
pugs_svn r19369 | ruoso++ | [yap6] adding an example of stack manipulation for continuation passing style. 21:10
pmurias ruoso: if yap6 is a runtime library the high level is c code
ruoso pmurias, but if you mean in the low-level... why would I need it?
pmurias, not really
the high-level is a mix of C code and a lot of objects
I mean... 21:11
not necessarly code generation
we may have a plain interpreter
that parses the code, gets an AST and transform the AST to stack frame and run it in the interpreter loop
Like if you took B::Generate to feed the Perl interpreter with the operators 21:12
but in yap6, even the operators are object oriented 21:13
pmurias ruoso: wan't it be a bit slow? 21:14
ruoso maybe, but there's room for optimizations
pmurias i thought about generating stackless c 21:15
ruoso well... generating stackless C means generating the code that builds a data structure
there's no point in doing that
better to generate the data structure and serialize it 21:16
pugs_svn r19370 | dlo++ | [kp6] Added more documentation to the Makefile.PL 21:17
pmurias ruoso: i'm tired know i'll code an example of what i mean tomorrow
&
ruoso seeya
pmurias * now
seeya
21:17 pmurias left
pugs_svn r19371 | dlo++ | [kp6] updated the MANIFEST file 21:20
ruoso @tell pmurias actually there's a point in generating the code that builds the AST and Stack, it makes the build process easier...
lambdabot Consider it noted.
ruoso and the interpreter boot too, actually
21:21 F left 21:22 Aankhen`` left 21:34 Schwern joined 21:39 rdice left 21:41 Squern joined
pugs_svn r19372 | ruoso++ | [yap6] declaring the low-level operator modules as proto-object-metaclasses, 21:41
21:42 Squern left 21:43 Schwern left
pugs_svn r19373 | ruoso++ | [yap6] new ROADMAP... 21:51
21:52 jferrero left
pugs_svn r19374 | ruoso++ | [yap6] item missing in ROADMAP. 21:54
TreyHarris I asked an aside question in my earlier post to p6-l: could you create a two-arg sub that ignored its args? -> (undef, undef) { ... } or -> (Any, Any) or -> (*, *) or somesuch? 22:24
or do you have to name them, even if you're just going to never use the names? 22:25
22:25 zgh joined
rhr I think you can use a sigil without a name ($, $) 22:26
TreyHarris hmm. 22:27
ok
22:29 chris2 left 22:31 jferrero joined 22:34 cmarcelo left 22:45 TJCRI left 22:49 ebassi joined 22:58 dlocaus left 23:02 alester is now known as AndyAway 23:18 cmarcelo joined, jhorwitz left 23:19 iblechbot left 23:27 ebassi left 23:29 cmarcelo left
TimToady yes, you can even name them without giving variable names: (:foo($),:bar($)) 23:37
(I dunno if pugs supports that though)
23:39 mncharity joined
TimToady hmm, looks like I botched STD so it doesn't handle :foo(:bar($baz)) 23:42
[particle] how about (:$) ? is that an anonymous named variable? is that then the same as an optional unnamed? 23:44
TimToady :$ isn't allowed, I don't think 23:49
23:49 jferrero left
TimToady it's certainly disallowed as an rvlaue, and I don't see much use for it in a declaration 23:50
[particle] no, i don't see much use. i do see much confusion. same for $! for example, which shouldn't be allowed to mean a required anonymous non-named parameter 23:52
TimToady well, bare $ is already required 23:55
$? wouldn't be though
(if allowed)
can always force $ ! and $ ? 23:57
[particle] right. with non-named, ! is default, and with named, ? is default. that's not to say you can't use it to be explicit, though. 23:58
it's only a problem when defining sigs without names, so those are ambiguities that are in the current spec. 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!