The topic for #perl6 is: pugscode.org/ planetsix.perl.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, elf: etc.) (or perl6: for all) | irclog: irc.pugscode.org/
Set by TimToady on 25 November 2008.
rakudo_svn r33245 | jonathan++ | [rakudo] We need to be a bit careful to differentiate between Perl6Scalar (which just wraps up an argument) and ObjectRef (which we have when something is actually a reference type). Modify list() to know about this. Resolves RT#60404. 00:00
00:14 stephens left
pugs_svn r24070 | jnthn++ | [t/spec] Another test for passing with lists/scalar interaction that Rakudo currently gets wrong, pointed out by pmichaud++. 00:21
ruoso TimToady, I'd be glad to help with S07, but I would need some help with the general document structure...
00:27 bacek left
wayland76 ruoso: Have you considered structuring it like S29? 00:39
committers++ :) 00:40
00:41 hercynium left
wayland76 ruoso: I'd also suggest the following types of headings: a) The Iterator Role b) default implementation 1 c) default implementation 2... 00:47
00:47 elmex left
ruoso wayland76, wouldn't you like to start the document? 00:49
jnthn TimToady,ruoso: It'd be nice if things like knowhow would make it into S12.
Is there a document that explains this somewhere?
ruoso jnthn, not really... but basically a knowhow is a Pure Prototype 00:50
jnthn What's the relationship between Class and ClassHOW?
And how does it map to the class keyword? 00:51
ruoso the idea is that every package declarator keyword relates to a metainstance (aka HOW)
the mapping is done explicitly in the compiler (at least in mildew)
in mildew, knowhow relates to the PurePrototypeHOW metainstance 00:52
and class relates to ClassHOW metainstance
jnthn OK, that makes sense, and we have something along those lines in Rakudo too. But more concretely, if you wanted to write your own custom metaclass (I guess that's the right word), say knowhow MyAwesomeThingyHOW { ... }, how would you introduce a keyword or something that means we can declare a class using that metaclass?
ruoso jnthn, I'd be glad to have a standard way of doing that 00:53
jnthn Aha, that hasn't been picked yet.
ruoso kind of
it actually have
you need a custom grammar
the custom grammar extends STD
provides an additional package declarator multi token 00:54
with the action that uses the given metainstance
jnthn OK
That much I guessed - it's what you'd write in that action.
00:55 alc joined
ruoso that's something that will probably be standard once the compiler bootstraps STD 00:55
jnthn Sure, we don't need to know now I guess.
ruoso yeah... mildew can just hard-code it for now
I presume rakudo can also
jnthn Yes, we already are.
ruoso the pretty part about knowhow 00:56
is that we can have the default metaclass instance for Perl 6 written in Perl 6
00:56 DemoFreak left
ruoso jnthn, have you ever seen the src-s1p code? 00:56
jnthn The nice thing about Parrot is that it doesn't matter which language we wrote it in. ;-)
URL?
ruoso svn.pugscode.org/v6/smop/src-s1p/ 00:57
er
almost that
svn.pugscode.org/pugs/v6/smop/src-s1p/
jnthn Are you running ClassHOW yet? 01:00
Or is it prototype?
(as in, what you expect it to look like) 01:01
ruoso I'm working towards having it running
jnthn Nice.
wayland76 ruoso: No commit bit; could I create it, and then e-mail it to you?
ruoso feature-by-feature
wayland76, that's cool 01:02
jnthn Is p6opaque something that you define in your "guts" as it were?
ruoso jnthn, yes... p6opaque is something "like" a native type
jnthn OK
ruoso that's why it's called p6"opaque"
jnthn Sure
ruoso (and it's spec)
jnthn Yes, I know.
Likely maps to the Class PMC in Parrot. 01:03
ruoso I'm actually pretty sure we could say p6opaque is a native type
except it isn't really a type
jnthn *nod*
ruoso jnthn, but it doesn't implement any dispatch logic
jnthn I guess how p6opaque is implemented kinda doesn't matter.
ruoso except the logic to call the dispatch logic
jnthn To dispatch the dispatch? ;-) 01:04
ruoso yeah...
jnthn lol
ruoso that's where the REPR api comes in 01:05
the p6opaque intercepts all REPR methods
and call dispatch on it's HOW on everything else
01:05 lichtkind joined
jnthn I guess we need to work out what is standard API (that a Perl 6 programmar can expect to use standardly across implementations) and what isn't. 01:05
lichtkind TimToady: at birth of perl you worked for unisys that was contracted by NSA for blacker project?
jnthn: hello 01:06
ruoso yeah... the REPR API is not standard (at least not yet)... and that's why its use is limited to ClassHOW
jnthn For example, I expect that the list of methods inside knowHOW
Right.
ruoso Object.pm (in that same directory) only use the HOW API (which is spec)
jnthn oops, knowhow
*nod*
ruoso but I'd be very happy if we could share metaclass implementations 01:07
jnthn Sure, we should work towards that.
ruoso jnthn, do you see how the .^! methods in ClassHOW could be mapped in rakudo?
s/methods/method calls/
jnthn We already do have something called P6MetaClass that we do call, when building a class, things like add_method on already. 01:08
ruoso right... that's the HOW API
jnthn Right.
ruoso www.perlfoundation.org/perl6/index....mop_oo_api
lambdabot Title: SMOP OO API / Perl 6
ruoso jnthn, ^
01:08 IRSeekBot joined
jnthn It's encouraging we've converged on something vaguely similarish. 01:08
ruoso yeah... 01:09
jnthn OK, so the HOW API we expect to be shared.
As in, all implementations provide that.
Which other ones? 01:10
ruoso Method, Attribute etc
which are built-in types
jnthn Declaration API looks to me almost like I'd expect it to be part of the HOW API?
That's listed in the knowhow too, right?
ruoso that's how mildew works
ClassHOW has add_method 01:11
add_attribute and so on
jnthn, pugs/v6/mildew$ perl mildew --file t/classhow_add_method_real.t --desugar 01:12
it might look a little cryptic, but it's a pseudo-p6 output that represents how the code will run
including the declaration of the class
and the knohow
*knowhow
jnthn I don't have a checkout of that handy, but will take a look at some point. 01:13
Anyway, the API there looks pretty sane.
For the HOW stuff.
ruoso jnthn, let me paste it then
pasteling "ruoso" at 201.9.45.79 pasted "perl mildew --file t/classhow_add_method_real.t --desugar" (86 lines, 4.6K) at sial.org/pbot/33382 01:14
jnthn so everything below REPR API on that page is, for now, smop specific?
ruoso looking at svn.pugscode.org/pugs/v6/mildew/t/...hod_real.t helps
jnthn, yes 01:15
but it would be really nice of you if you could see if that concepts could be mapped in rakudo
so we could converge on that too
jnthn ruoso: OK, it looks sane.
(The parts above the REPR API)
create/destroy/clone map almost exactly to Parrot PMC vtable methods. 01:16
ruoso jnthn, btw... the title fonts are not very clear... but Declaration API is a subtopic of HOW API 01:17
jnthn Ah, OK
That's fine. :-)
So basically, what comes inside knowhow ClassHOW is free to be implementation-specific? But the interface that is implemented inside the knowhow (e.g. the list of methods), we standardize on? 01:19
Or we're aiming for our knowhow ClassHOW { ... } to look the same too?
ruoso as the spec is today, having the same ClassHOW API is expected 01:20
but I'd be very happy if we could share the knowhow ;)
jnthn OK, but we can do what we need to do inside it.
OK. And to do that we need to standardize on what additional things?
ruoso the REPR api 01:21
jnthn Aha.
OK, let's set meeting what's in the spec in terms of the API happen first.
ruoso cool 01:22
jnthn I'd need to think a bit more about the representation API.
ruoso jnthn, that's actually related to an old conversation we had on #parrot
jnthn I'm very happy to see that the syntax for declaring other metaclasses has been fleshed out.
ruoso that you need to be able to instantiate a Object using a different representatoin 01:23
(that's spec)
like, creating a Perl 6 Object instance with a p5Moose object
that's how I got to the REPR api 01:24
jnthn OK. But to me, since a PMC is essentially defining how a bunch of data is stored and has a common set of vtable methods...
ruoso maybe it's just syntax
jnthn I think that PMCs in reality are our representation.
ruoso they are
jnthn OK.
So maybe Parrot isn't doomed to epic fail implementing Perl 6. ;-) 01:25
literal I think I've asked this before without getting an answer. In the same way that Perl needs to figure out if you're feeding Perl 6 or Perl 5 code (e.g. check for a class declaration), how are Pod tools supposed to distinguish between Perl 6 .pod files and Perl 5 .pod files?
jnthn Parrot already has PMCs for dealing with CStructs. 01:26
ruoso jnthn, I had a conversation later with pmichaud or [particle] about the repr issue...
and they explained to me that it would work that way
(by "they" read "one of them", as I don't remember who it was)
jnthn Aha.
ruoso the big difference between SMOP and Parrot in that sense 01:27
is that SMOP embraces foreign objects naturally
because of the ResponderInterface thingy
while Parrot will need a p5-like strategy to handle foreign objects
jnthn In what sense?
ruoso storing a pointer to the object and implement a mapping of the method dispatch 01:28
jnthn OK, and SMOP instead does?
ruoso SMOP doesn't have a public vtable
then the dispatch is always delegated to the responder interface 01:29
which means that everyone in smop only looks to the first int of any objec
which holds a pointer to its RI
jnthn A bit like a PMC holds a pointer to its vtable?
ruoso this will allow us to have p5 SV* and SMOP__Object* coexisting peacefully 01:30
(a slightly modified SV*)
jnthn, afaiu, parrot access the vtable directly
jnthn Aha, so it's between having to modify the thingy you want a representation of, or having a pointer to the thingy.
ruoso actually about the hability of doing that morph 01:31
jnthn morph?
ruoso because for Gtk, for instance, I won't expect having a modified version
jnthn OK, so how will that be handled?
ruoso the same way p5 does, and the same way parrot does 01:32
but the thing is that I don't have *a* PMC
I have as many as I'd like
jnthn Sounds like a slightly slighter-weight version of PObjs.
ruoso including having two concurrent garbage collectors
jnthn (Both PMCs and STRINGs in Parrot are forms of PObj) 01:33
ruoso can you call arbitrary methods on PObj?
jnthn No 01:34
ruoso that's the difference
as there's no public vtable
every object is really an object
where you can call an arbitrary method
and its up to its responder interface to decide how to handle that 01:35
in fact
the only thing you can do
is calling an arbitrary method
there's nothing else
jnthn Dynamic. :-)
01:36 stephens joined
jnthn It's an interesting design. 01:36
ruoso I got there after some zen trainning with nothingmuch
and it brought me enormous benefits
including being able to replace the interpreter implementation 01:37
and have both interpreters running at the same time
jnthn What do you mean by interpreter?
ruoso the thing that holds a bytecode and evals it)
jnthn Ah.
Parrot has multiple runloop types too. :-)
...more than we really need in any one build, generally... 01:38
jnthn thinks we really don't need to compile every one of them in
But that's a topic for #parrot. :-)
Anyway, thanks for explaining the knowhow and the API 01:39
ruoso the polymorphism in smop got to a point
jnthn Would be great to get that into S12.
ruoso that you don't even need to know the interpreter you're sending the execution to
and it doesn't need to be built-in
jnthn Pluggable. :-)
ruoso that's how we're going to intergrate SMOP and P5
using Coro 01:40
SMOP will receive a Coro and just use it as if it was an interpreter frame
because everything is an object,
jnthn Sounds scary, but feasible.
ruoso including the interpreter
and everything is dispatched the same way
all you need is a standard interpreter API
our next adventure is a "C Coroutine Interpreter" 01:41
so we can call C code and callback to SMOP still being stackless
jnthn Yes, I saw the links to the C coroutine implementations earlier.
ruoso that's how XS is going to work in SMOPP5 01:42
about getting knowhow to S12... I think if TimToady sees that we're converging on that, he'll be very happy to spec it 01:43
jnthn I'm happy enough with it; I may come up with things when implementing it.
I wonder if we could add a trait... 01:44
class Thingy is knowhow(Worrea) { ... }
To make it trivial to create a class based upon a different metaclass without having to do grammar stuff to introduce your own keywords, if you don't want to.
And it defaults to is knowhow(ClassHOW) 01:45
ruoso jnthn, TimToady explained that he expects that to be using a different keyword
it would be more like
knowhow ClassHOW handles_package_declarator_keyword class {}
jnthn That still implies grammar changes, but makes it easier. 01:46
oh
in fact maybe
package_declarator is the standard words plus a | <typename> <?{ is_know_howed($<typename>) }> 01:47
Style thing.
ruoso jnthn, hmm... interesting 01:48
jnthn Where is_know_howed would return true if that name appears on after a handles_package_declarator_keyword
ruoso that really could work
jnthn, but notice that it doesn't need to be a knowhow to be a metaclass 01:49
that's just the choice I made in smop/mildew
jnthn It can be anything that implements the interface, right?
ruoso right 01:50
jnthn That's fine. We don't need to provide an easy way for everything. Just the common things. :-)
ruoso but that actually makes it easier
because you can have any type being used as a package declarator
*package declarator handler 01:51
jnthn ...ouch...
I don't think we can quite get away with that. :-)
Well
ruoso why not?
jnthn We can if you have to *register* your type as expecting to be one.
ruoso sure sure
jnthn OK, with that proviso, it works.
Heck, we could just say you write
knowhow what_the_declarator_will_be_called { ... } 01:52
pugs_svn r24071 | hinrik++ | [util/perl6.vim] highlight nested =end correctly
ruoso you mean...
typename typename { } ?
typename1 typename2 { } ?
jnthn No, I mean the knowhow keyword followed by the name of the declarator we want to introduce
ruoso would make the declaration of typename2 to be handled by typename 01:53
1
jnthn knowhow wob { ... }
wob Foo { ... }
ruoso jnthn, knowhow is not really package_declarator specific
it's just a Pure Prototype implementation
jnthn True. We maybe don't want to tie the two that closely.
I'm just throwing out some ideas. :-)
ruoso sure sure...
it's just because I have some uses for knowhows in my mind 01:54
TimToady knowhow package_declarator:<wob> maybe
ruoso hmm
jnthn Could work.
ruoso indeed 01:55
jnthn I quite like that.
ruoso knowhow package_declarator:<class> { }
class package_declarator:<foo> { }
foo package_declarator:<bar> { } 01:56
and you get haunted by circularity
;)
jnthn Looks more like recursion to me... ;)
TimToady not unless you do foo package_declarator:<knowhow> 01:57
jnthn No no no...we were at something that sounded nice and implementable 30 seconds ago! :-P
ruoso but that's ok
jnthn knowhow package_declarator:<wob> seems nice to me.
ruoso you would simply be hiding the old package_declarator:<knowhow>
that sounds like bootstrap 01:58
jnthn only with 'is instead' ;-)
knowhow package_declarator:<class> is instead { ... } # well, all's fair if you predeclare... 01:59
01:59 PtZ is now known as PZt
ruoso class package_declarator:<controller> { } # and I have my custom catalyst controller 01:59
and I only miss 02:00
jnthn Not knowhow ...
?
ruoso it can be any type, remember?
jnthn I didn't say I thougth *that* part was a good idea... :-)
ruoso too late ;)
jnthn tries to work out what it'd mean
ruoso nothing special, really
jnthn The thing is, that at the end of the day, knowhow has to have something that knows how to interpret the keywords inside it. 02:01
ruoso only that the meta calls on the objects created by that keyword would be handled by that type
TimToady kinda like sub infix:<XYZ> is not terribly special, other than the infixness
jnthn I guess you'd just be declaring a knowhow but with the keywords in *it* defined by how the keywords in class are defined
ruoso I wonder if we can extend that to other multi tokens
jnthn And so on down the chain.
ruoso like... 02:02
jnthn knowhow routine_declarator:<mysub> { ... }
ruoso class routine_declarator:<action> { } # and now I have my catalyst action
jnthn This is sick and wonderful.
TimToady
.oO(make the bad voices go away!!!)
jnthn The problem is that then anything we see could be a something declarator. I'm not sure how much that hurts our ability to parse efficiently. Maybe not at all. 02:03
Well, not anything we see, but any type name we see.
TimToady
.oO(they're telling me to use the /electrocute_remotely irc command)
jnthn ...we out-eviled TimToady?!
Anyway, there's some nice ideas in here. 02:04
So long as we don't do anything that will be an epic pain to implement and that will actually be useful to someone...
ruoso we also need to consider how hard would it be to have the controller and action keywords without that 02:05
to see if its worth the trouble
maybe it's not that hard already
jnthn macros.
ruoso or extended grammar
jnthn Yeah
ruoso with customized actoins
jnthn TMTOWTDI already.
It just depends how easy we want to make it to do such things.
I mean, writing customized actions to me is a bit hairy. 02:06
(Well, of course, not really, I do it all day, but from the point of view of the folks using this stuff...)
ruoso yeah... having a different routine_declarator keyword requires a different HOW api
jnthn Yes.
ruoso or a more abstract HOW api
jnthn Personally, I'd rather restrict this to knowhow and package declarators.
For Perl 6.0.0. 02:07
ruoso I'm fine with that, but for me it doesn't matter if they are knowhows or whatever...
I'm only concerned that having a custom package_declarator doesn't change the HOW api
it only change where to call the methods
jnthn That would be my expectation. 02:08
ruoso so that's fine
having custom routine_declarators is a completely different story
jnthn Yes
I'm not so interested in that.
ruoso I might be very much interested, but macros and custom grammars already solve it 02:09
jnthn Yes.
I can go with the "we can write class package_declarator:<foo> { ... } too
As in, one metaclass defined according to the rules of another. 02:10
That's not hard to implement.
OK, so I think we agree on enough. :-) 02:11
ruoso ok... 02:12
jnthn I'll look at getting knowhow into Rakudo.
ruoso :P
jnthn I spent the day doing bug fixes, I'll be up for some feature implementation again soon. :-) 02:13
I've landed the "fun task" of getting HLL debug info sorted out too, so we can report the right line numbers etc. 02:14
ruoso nice... I'm pretty far from that point ;)
jnthn I'm at the point where I've got a spec that I wrote and hoped someobdy else would implement. ;-) 02:15
jnthn doesn't really blame anyone for not wanting to do it...that part of Parrot is..."fun" 02:16
ruoso: OK, was great to talk...I really should sleep now. 02:18
ruoso too
jnthn If you're in Portugal, it's an hour later here than where you are. :-)
ruoso nah... 02:19
I'm back in brasil
jnthn ...the fact that I'm still concious is thus a very bad thing. :-)
ruoso and my son has born last week
jnthn Ah, congrats! :-)
ruoso which thanks
jnthn That will cost sleep.
ruoso yeah
so... I should be sleeping already...
for some time
jnthn Same. Such is hacking. ;-) 02:20
wayland76 ruoso: How much of the www.perlfoundation.org/perl6/index....p_operator did TimToady bless?
lambdabot Title: SMOP map operator / Perl 6
wayland76 all of it, or just some?
Or none?
ruoso wayland76, I kinda understood that it's the starting point
we would evolve from that
wayland76 Ok, so structure the document so it includes all that info
can do :)
I'll probably e-mail a few followup questions overnight 02:21
(over your night)
What's an ItemIterator again? 02:22
(what's its purpose?)
ruoso to provide a one-by-one view of the iteration 02:23
even if the input is a grep
wayland76 (oh, and congrats on the son)
ruoso (thanks)
or a map
which in slice context are completely different from list context 02:24
wayland76 Hmm. Ok. I'll have to think about that answer for a while, but I'm sure I'll get it :)
Thanks!
So ItemIterator is just a wrapper around Iterator? 02:25
Or wait; is ItermIterator the user-facing mechanism 02:26
...and Iterator is what someone who wants to write their own iterator inherits from?
ruoso ItemIterator is an iterator in item context
wayland76 (btw, feel free to go to bed; I can always e-mail these)
ruoso just realized he has to read some meeting minutes (for some meetings he missed) 02:27
jnthn OH AWESOME the London Perl Workshop pre-workshop-meetup pub is walking distance to my hotel
ruoso so feel free to ask
wayland76 jnthn: That's closer to a Perl Mongers meeting than I've ever been 02:28
(Melbourne-PM is more than an hour from here, but I'm on their mailing list)
ruoso: Ok, will do.
jnthn wayland76: I'm really lucky since I moved to Slovakia. 02:29
I've got Bratislava.pm right here in my city
And Vienna.pm an hour away by train
wayland76 Cool :)
jnthn Yeah.
jnthn loves Bratislava/Slovakia.
wayland76 Does eagerness go in S07-iterators? 02:30
ruoso I think so
wayland76 I love souvlakia too :)
ruoso TimToady has a spreadsheet in google docs somewhere
wayland76 especially a nice lamb souvlaki :)
ruoso that lists S07 as iterators and lazyness/eagerness
wayland76 Ok, cool 02:31
I can do that too then
jnthn wayland76: You made me think I'd done a 3:30am typo then :-P
wayland76 Nah, just me. I deserve PUNisment or something :)
jnthn groans 02:32
ruoso just finished reading the minutes....
ruoso sleep &
wayland76 'night. Enjoy :)
jnthn night
ruoso cya
jnthn I guess given the time I should sleep too. 02:33
jnthn really needs to fix his body clock at some point
wayland76 Rebbot :) 02:34
(sorry, reboot :) )
jnthn :)
Well, night @all
TimToady night
wayland76 Stay up all night one night when you can afford to, and go to bed at 6pm the next day
'night :)
TimToady decommuting & 02:35
wayland76 bye :)
Does anyone know if p6l takes attachments? 02:39
pugs_svn r24072 | hinrik++ | [util/perl6.vim] added preliminary syncing hints 02:49
lichtkind timtoa 03:01
TimToady: seen my question?
pugs_svn r24073 | hinrik++ | [util/perl6.vim] behave accordingly on older vim versions 03:04
wayland76 He's decommuted now 03:05
03:11 lichtkind left 03:31 Psyche^ joined 03:37 slavik joined 03:43 Patterner left, Psyche^ is now known as Patterner 03:45 hercynium joined 04:18 hercynium left 04:36 dukeleto joined
literal what is $Ā¢ ? 04:36
04:37 sri_kraih__ left
slavik ... 04:38
literal I see it all over STD.pm 04:39
slavik no idea
since the second char is missing from my keyboard
literal altgr+c here
slavik altgr is where? 04:40
slavik has a standard 105key keyboard
literal it's the right alt key
slavik or 104, w/e it is
pugs_svn r24074 | hinrik++ | [util/perl6.vim] reorganization 04:42
04:45 aindilis left 04:46 aindilis joined
pugs_svn r24075 | hinrik++ | [util/perl6.vim] add note about modeline 04:47
04:49 dukeleto left
pmichaud $Ā¢ is the current match state -- see S05 04:51
04:52 smallfish joined
literal I see 04:54
I'm curious, are any other non-ascii symbols being used by default? other than Ā¢ and Ā«Ā» 04:56
pmichaud I think those are the only ones at the moment. 04:59
05:01 smallfish left
pugs_svn r24076 | pmichaud++ | [t/spec]: Unfudge tests for ^@list, correct one test. 05:02
r24077 | pmichaud++ | [t/spec]: Correct plan in passing-arrays.t .
rakudo_svn r33257 | pmichaud++ | [rakudo]: Fix ^@list semantics, RT #60828. 05:10
slavik rakudo: say "hello" 05:11
p6eval rakudo 33256: OUTPUT[helloā¤]
pmichaud rakudo: my @list = <a b c>; say ^@list; 05:19
p6eval rakudo 33257: OUTPUT[012ā¤]
pmichaud yay.
wayland76 rakudo: my @list = <a b c>; say @list; 05:32
p6eval rakudo 33257: OUTPUT[abcā¤]
wayland76 (just testing :) )
literal rakudo say ^<a b c> 05:37
rakudo: say ^<a b c>
p6eval rakudo 33257: OUTPUT[012ā¤]
05:55 iblechbot joined 05:56 Entonian joined
pugs_svn r24078 | putter++ | [elf_h] Parenthesized a not(), correcting precedence: (not(...)) && ... 06:06
r24078 | putter++ | STD_red incorrectly treats not() as a function, rather than as a prefix op.
r24078 | putter++ | In this case, that nested improperly.
r24078 | putter++ | The "not(...)" idiom (15 cases) seems likely to breed bugs.
r24079 | putter++ | [STD_blue] Created a STD_blue-specific PrimitivesP5.pm mutant. Also tweaked multis. 06:14
r24079 | putter++ | gimme5 currently requires too much memory to parse elf_h's PrimitivesP5.pm. So now there's a modified copy which works around the problem.
06:14 mncharity joined
mncharity @tell TimToady It looks like viv is having trouble with unicode french quotes. eg, multi infix:symĀ«<Ā» ($a,$b) {33} has mangled text in the tree. 06:18
lambdabot Consider it noted.
mncharity looks like I'll need to teach elf about infix:['<'] or some such. 06:19
another day. 06:20
happy holiday all &
(for whom it's a holiday;)
06:20 mncharity left 06:22 DemoFreak joined 06:45 ashizawa joined 06:53 iblechbot left 07:18 sri_kraih joined
pugs_svn r24080 | lwall++ | [STD] not() etc. is a function call 07:21
r24080 | lwall++ | [S03] prefix:<^> no longer tries to get fancy with lists
07:28 Entonian left
pugs_svn r24081 | hinrik++ | [util/perl6.vim] pick pattern delimiters consistently 07:33
r24082 | bacek++ | [spec] Added todoed test for assing-is-not-binding 07:36
rakudo_svn r33258 | chromatic++ | [Rakudo] Added vtable delegate for get_pmc_keyed_int to Perl6MultiSub, as 07:40
r33258 | chromatic++ | r33253 now allows subclasses of MultiSub to store multis in a NameSpace PMC.
r33258 | chromatic++ | Bacek reported that this broke t/spec/S03-operators/assign-is-not-binding.t.
pugs_svn r24083 | lwall++ | [Spec] undelete some accidentally deleted history 07:46
r24084 | lwall++ | [Spec] delete de-historied files 07:48
r24085 | lwall++ | [Spec] put historied versions back to long names 07:49
TimToady @tell mncharity the Ā« problem is probably just the typical non-dealing of yaml with unicode 07:53
lambdabot Consider it noted.
07:55 aindilis left 07:56 aindilis joined 08:06 pbuetow joined 08:24 bacek_ left
rakudo_svn r33262 | chromatic++ | [Rakudo] Removed debugging code accidentally committed in r32992. 08:30
pugs_svn r24086 | hinrik++ | [util/perl6.vim] map Perl 6 syntax groups more closely to vim's
08:31 DemoPhreak joined 08:33 ejs joined, slavik left
pugs_svn r24087 | hinrik++ | [util/perl6.vim] add todo item for a perl_string_as_statement feature 08:35
08:35 pbuetow left, justatheory joined 08:36 smg left 08:38 iblechbot joined 08:47 DemoFreak left 08:49 adc_penner joined 08:54 jferrero joined 09:06 kanru left 09:07 smallfish joined, kanru joined 09:08 Bzek joined 09:17 alc left 09:18 bacek joined 09:20 adc_penner left 09:29 smallfish left 09:45 elmex joined 09:46 renormalist joined 09:54 alech_ joined, alech left 10:03 iblechbot left 10:06 jferrero left, smg joined 10:10 DemoPhreak left 10:16 justatheory left 10:23 ruoso left
moritz_ wayland76: re "no commit bit", you can easily get one 10:28
10:28 vixey joined
moritz_ wayland76: just /msg me your email address and desired nick 10:28
10:35 smg left 10:41 jferrero joined 10:53 Southen joined 11:12 Southen_ left 12:05 smg joined 12:35 ruoso joined
ruoso wayland76, hi 12:36
the idea of different types for the iterator in each context, is that the behavior depends on the context in which the operator is 12:37
for instance...
my $a = @list.Iterator();
that gets you an "Iterator in Item context"
which basically means that every time you do =$a
you will always get one element, and only one element
until the iterator is over 12:38
my @a = @list.Iterator();
gets you a Lazy List
that will traverse the iterator as needed
but flattening the results of the iterator in the process
but if you do
my @@a = @list.Iterator(); 12:39
then you have a Lazy Slice
where the first dimension is the number of actual iterations
and the second is the elements of each iteration
(btw... the code above is illustrative... 12:40
you won't be calling .Iterator(), most of the time
that's up to the runtime)
the most important problem this solves 12:41
is how to get slices working properly with map 12:42
which is one of the most complicated examples, I think
the interesting point about having different types for each context
is that the non-context-aware Iterator type always return a capture 12:43
and the item iterator, the lazy list and the lazy slice can be generic
we can have a GenericItemIterator
a GenericLazyList
and a GenericLazySlice
where they hold a pointer to the input iterator 12:44
and implement the specifics of turning the "one capture per iteration" into the desired behavior of each context
one point I'm not sure now 12:45
is if this contextualization should happen directly
or if the runtime should explicitly create the generic iterator tyhpes
and just use the plain Iterator 12:46
12:46 iblechbot joined
ruoso after we realized that the lazyness-eagerness control doesn't belong to the List or Iterator object itself, 12:46
but to the runtime
it's fairly reasonable to assume that the Iterator type always return one-capture-per-iteration 12:47
and the runtime should then create the generic-lazy-list or whatever to consume that
TimToady, I think the above reasoning clears it up a little bit... 12:49
13:03 justatheory joined 13:05 lichtkind joined
wayland76 ruoso: I see why that gives us different iterator classes, but why do we need different roles? 13:13
ruoso wayland76, maybe ItemIterator can be a class 13:14
Iterator is certainly a role
because the iterator returned by each list is private to that list
wayland76 ok, that makes sense, and I think it lines up with the document that I sent you 13:15
ruoso wayland76, I'm already working on it 13:16
I'm expanding the first section a little bit
13:16 vixey left
wayland76 oh, ok :). My plan was to get feedback from you, and update it myself, but it's bedtime for me soon, so if you want to do it, wonderful :) 13:17
Hmm, I just ran it through pod2man from perl5; not all formatted nicely :). I didn't actually test the POD yet (I was expecting to do more hacking on it) 13:18
moritz_ both of you, feel free to put it into the pugs repo, then more eyes can see it
wayland76 Yeah, that's the plan, it's just I probably wrote some things that are downright wrong :), so I sent it to ruoso for review first. 13:19
ruoso: I attached the laziness, etc, to the Iterator, but the runtime could set the default, as it were. 13:20
But no doubt that's wrong too :)
pugs_svn r24088 | ruoso++ | [spec] Adding the first sketches on S07, thanks to wayland76++
wayland76 Ooh, I have a karma of one! Excitement plus :). 13:21
moritz_ perlbot: karma wayland76
perlbot Karma for wayland76: 2
ruoso take a look at the first part, I already expanded it a little
moritz_ ruoso: my @a <== grep { ... } <== map { ... } <== grep { ... }, 1, 2, 3 13:25
is completely lazy, even if 1,2,3 is a fairly small known compact list.
ruoso: notice that the first grep (ie the last in the line) is not strictly lazs
13:25 [particle]1 joined
moritz_ *lazy 13:25
ruoso moritz_, oh... I meant a feed there too
wayland76 (btw, thanks to whoever gave me the extra karma :) ) 13:26
ruoso: The improved S07 is good :). Is there a way the laziness can be user-adjustable? 13:30
ruoso wayland76, the syntax indicates the level
13:31 justatheory left
wayland76 Ok; would I be right in saying that the choice (made by the runtime) is decided on by a combination of the operators (or whatever) and the iterators? 13:32
13:32 justatheory joined
ruoso yes 13:32
actually 13:33
not
wayland76 great :)
ruoso the first part yes
the second part not
13:33 justatheory left
wayland76 ok :) 13:33
ruoso it's external to the objects
wayland76 Also, you say "But it's important to notice that eagerness takes precedence over lazyness" -- does that mean that mostly-lazy takes precedence over strictly-lazy?
Ah, the iterators are entirely unrelated to the *decision* about the laziness, and merely feel the *effects* 13:34
ruoso exactly
wayland76 (exactly precedence, or exactly decision/effects?) 13:35
ruoso decision/effects
mostly-lazy wouldn't make a strictly-lazy less lazy, because the lazyness of the input is when the mosltly-lazy stops
wayland76 Ok. I just think we should clarify it either way :) 13:36
ruoso but mostly-lazy is not more eager than strictly lazy
it's less lazy
but it's still not eager
wayland76 Yup :). But because of the use of a "precedence table" in the Operators page, I thought the list of lazinesses could lull people into thinking the other way :) 13:39
13:39 spx2 left 13:40 spx2 joined 13:41 ejs left
wayland76 I think I finally see the advantage of an ItemIterator role; someone creating a new iterator need only create an ItermIterator, and the others will be auto-created for him, right? 13:42
ruoso the opposite
it only needs to create the Iterator
the use in the other contexts will be available
but again, the runtime is the one instantiating this generic objects most of the time 13:43
wayland76 I'm thinking from the point of view of someone who wants to write some tree iterators :) 13:44
ruoso you only need to provide a .Iterator() method in your tree
and return a private object that does Iterator 13:45
the runtime can then use the generic item iterator with your iterator as input
or the generic lazy slice
which probably makes more sense to a tree
wayland76 That sounds reasonable :)
is that .Iterator method documented anywhere? 13:46
ruoso S07 ;) 13:47
wayland76 I have more questions, but I'll await the rest of your S07 revisions
13:47 [particle] left
wayland76 Time for sleep now :) 13:47
although it is only 12:46am :)
'night all :)
moritz_ good night wayland76 :) 13:48
wayland76 sleep &
pugs_svn r24089 | ruoso++ | [spec] general S07 cleanup, I think that can be considered the first version. 13:49
r24089 | ruoso++ | Most of the cleanup is related to accepting that it is runtime s responsability to instantiate the GenericLazyList when needed, and not the Iterator itself
ruoso wayland76, ^
wayland76 (just remembered one last thing before bed, so I'm back for just a mo) 13:53
ruoso: Yeah, I see that :). Will review tomorrow, I hope.
@karma everyone
lambdabot everyone has a karma of 0
wayland76 everyone++
good-night again :) 13:54
pugs_svn r24090 | ruoso++ | [spec] Small text revisions on S07 13:57
13:58 [particle]1 left 14:00 ejs joined 14:03 [particle] joined
pugs_svn r24091 | ruoso++ | [spec] small code examples on how to get the generic item iterator, lazy slice and lazy list 14:07
ruoso moritz_, so... do you think this initial sketch is sane? 14:14
14:15 zamolxes joined
ruoso TimToady, should feed operators be strictly lazy or just mostly lazy? 14:15
14:16 ejs left, ejs joined 14:27 Limbic_Region joined 14:31 LimbicRegion joined, Limbic_Region left, LimbicRegion is now known as Limbic_Region 14:33 ashizawa left 14:47 jferrero left 14:50 rindolf joined 14:51 masak joined
pugs_svn r24092 | ruoso++ | [spec] lazyness applies to every object 14:58
pmichaud Happy U.S. Thanksgiving Day, all. 15:32
moritz_ ruoso: I'm not really involved in the iterator business, but I've found nothing insane in S07 15:58
ruoso moritz_, thanks 15:59
16:01 zamolxes left
ruoso just sent an aggressive-approach message in the "Files, Directories, Resources, Operating Systems" thread... 16:02
16:05 zamolxes joined 16:08 schmalbe joined
masak just read ruoso's mail 16:09
ruoso: your mail essentially means that you have to compile the program on the same type of box as you run it, no? 16:10
at least if you're doing file stuff
ruoso not at all..
hmm.... 16:11
masak then please explain what you mean by "have the POSIX module imported (where chmod would be in the default exports) by the prelude when in a posix machine"
ruoso the prelude is loaded in every runtime
masak ah.
ok, then that's not a problem.
ruoso but if you call chmod in a Win32 machine 16:12
it would probably break...
but I think that'd be expected
masak aye 16:15
still feels a little unnerving to have this done automatically behind-the-scenes
will lead to all kinds of "interesting" FAQs
ruoso well.. it would basically mean that you wouldn't call "perldoc -f open" but "perldoc POSIX" to see how to open a file 16:16
or "perldoc Win32" if you're programming for windows 16:17
16:17 iblechbot_ joined
ruoso but as I said in the email, that doesn't stop anyone from implementing a File class 16:18
masak I mean, a non-portable script written for POSIX will stop working on Windows.
ruoso that implements File.open() in a more abstract way 16:19
masak, hmm... I think that's the definition of non-portable
masak aye
16:19 Limbic_Region left
masak except that here it's not predeclared through a pragma, just assumed 16:19
that's the unnerving part, not the fact that it's non-portable
ruoso yeah.... 16:20
but one could have a Win32::POSIX emulator
and just invoke this same script with -MWin32::POSIX
masak I see.
ruoso but I really don't think it needs to be there by default 16:21
in summary... "open" is no longer a "core built-in operator", it's just a "sub loaded by a module"
masak that part I like. 16:22
ruoso but considering the ration between perl unix/win32 programmers 16:26
I think it probably makes sense to have the Win32::POSIX module loaded by default in Win32 machines
ruoso .oO( we have our own cygwin ) 16:27
16:27 justatheory joined 16:29 sri_kraih_ joined 16:30 iblechbot left 16:33 IRSeekBot left 16:44 sri_kraih left 17:08 jhorwitz_ joined 17:25 zamolxes left, jhorwitz left 17:36 justatheory left 17:42 justatheory joined
ruoso later & 17:46
17:46 ruoso left 17:47 slavik joined 17:49 meppl joined
pugs_svn r24093 | moritz++ | [t] split oo/meths/multi.t into t/spec/S12-methods/multi2.t and 17:52
r24093 | moritz++ | t/unspecced/yaml-eval.t
r24094 | moritz++ | [t/spec] unfudge a test for rakudo 17:56
18:02 lichtkind_ joined, lichtkind_ left
pugs_svn r24095 | moritz++ | [t/spec] ouch, multi2.t contained roughly the same tests as multi.t. 18:06
r24095 | moritz++ | Deleting..
18:08 lichtkind_ joined 18:13 [particle]1 joined 18:20 lichtkind left, aindilis left
pugs_svn r24096 | hinrik++ | [util/perl6.vim] keep contains= at the end of region definitions 18:25
18:27 [particle] left
pugs_svn r24097 | hinrik++ | [util/perl6.vim] fix typo in keyword 18:34
18:35 ejs left 18:38 adc_penner joined 18:45 vixey joined 18:47 Limbic_Region joined, ejs joined 18:50 DemoFreak joined 18:51 Limbic_Region left 18:52 Limbic_Region joined 18:53 pbuetow joined 18:55 LimbicRegion joined 18:56 LimbicRegion left 19:13 Limbic_Region left 19:19 mncharity joined
mncharity TimToady: unicode issue now resolved. fyi. thanks. 19:20
lambdabot mncharity: You have 1 new message. '/msg lambdabot @messages' to read it.
19:20 mncharity left 19:22 justatheory left 19:35 Bzek left 19:48 masak is now known as ca 19:49 adc_penner left, spx2 left, drbean_ left, lambdabot left 19:50 clkao joined, pasteling joined, nothingmuch joined, allbery_b joined, ewilhelm joined, rhr_ joined, lizsac joined, lambdabot joined, drbean_ joined, spx2 joined, adc_penner joined
slavik is there a site with Perl6 sample code? 19:53
moritz_ slavik: github.com/viklund/november/ is a working wiki in Perl 6 19:54
slavik no, I mean, something that shows sample usage of various features
like some code that shows how to create a class and such
but something that works ... heh
moritz_ ;) 19:55
anyway, I've also written perlgeek.de/blog-en/perl-5-to-6/ which contains lots of micro-examples
lambdabot Title: blog | Perlgeek.de Blog :: Category Perl-5-to-6
19:56 lichtkind_ left
slavik yes, many of which don't work :P 19:56
like the grammar example 19:57
since assertions aren't implemented yet
at least in rakudo
moritz_ right 19:58
19:59 justatheory joined
moritz_ the test suite contains much Perl 6 code, and you can find out very easily if it works or not ;-) 19:59
slavik my test suite is rakudo ;)
revision 33172 at the moment 20:00
moritz_: any wiki software you can recommend? 20:04
moritz_ slavik: I haven't set up any
slavik k
moritz_ I just know one that you shouldn't use: socialtext 20:05
slavik how come?
slavik is actually looking at it right now
moritz_ I used the instance at www.perlfoundation.org/perl6/index.cgi?perl_6 ... 20:06
lambdabot Title: Perl 6 / Perl 6 20:07
moritz_ first of all the pages don't display correctly without javascript
then take a look at the "diffs" between revisions - so much text and so little information...
its approach to editing conflicts is "the article has changed in the mean time, go figure it out yourself" 20:08
slavik I see
what does wikipedia use?
I notice that lots of other wikis use it
moritz_ it's called wikimedia
and it's a PHP thing written for wikipedia 20:09
slavik maybe I'll just isntall a CMS ... 20:10
like e107
or something
20:23 ZuLuuuuuu joined 20:35 rindolf left
ca moritz_: actually, "MediaWiki". 20:43
slavik ca: ty
moritz_ ca: ah, right 20:44
ca WikiMedia is something else.
moritz_ yes, the organization
slavik wikimedia is the company
20:44 schmalbe left 20:54 pbuetow left 21:15 pbuetow joined 21:18 pmurias joined, justatheory left
pmurias the synopsis live in the pugs repo now? 21:27
lambdabot pmurias: You have 4 new messages. '/msg lambdabot @messages' to read them.
moritz_ aye
pmurias moritz_: why the move? 21:28
moritz_ pmurias: TimToady wanted them to be easier hackable for others 21:30
21:31 pbuetow left 21:43 ZuLuuuuuu left
wayland76 ...and it's worked. We now have S07 :) 21:49
21:51 ca is now known as masak
moritz_ let's say we have a draft of S07 - but still great ;-) 21:53
wayland76 Yeah, sorry; agreed :) 22:03
masak so the correct behaviour of @a Z @b is to stop as soon as one of the arrays run out, yah?
22:04 apeiron left 22:06 pbuetow joined
wayland76 Btw, whoever was wanting to write S00, I use perlcabal.org/syn/ which isn't as up-to-date as TimToady's spreadsheet, but it loads quicker and has other stuff :) 22:06
lambdabot Title: Official Perl 6 Documentation
masak perl6: say undef ~~ Undef
p6eval pugs: No output (you need to produce output to STDOUT)
..rakudo 33276: OUTPUT[Method 'ACCEPTS' not found for invocant of class 'Undef'ā¤current instr.: 'infix:~~' pc 14285 (src/gen_builtins.pir:8666)ā¤]
..elf 24097: OUTPUT[Can't call method "Str" on an undefined value at ./elf_f line 649.ā¤ at ./elf_f line 3861ā¤]
masak reports rakudobug 22:07
moritz_ where is Undef specced?
masak nowhere, it seems
S02 talks about Undefined types, that's all
moritz_ right
masak ok, the bug is with me 22:08
moritz_ an undefined type is one where the object's .defined method returns false
masak rakudo: say undef.WHAT
p6eval rakudo 33276: OUTPUT[Failureā¤]
masak rakudo: say undef ~~ Failute
p6eval rakudo 33276: OUTPUT[1ā¤]
wayland76 masak: re: @a Z @b -- yes, documented in S29
masak rakudo: say undef ~~ Failure
p6eval rakudo 33276: OUTPUT[1ā¤]
22:08 pjcj joined
wayland76 (as "zip") 22:08
moritz_ it could just as well be Object
masak wayland76: thanks
moritz_: hm. 22:09
moritz_: I'm writing an is_deeply function, post-#58392
moritz_: when I have two undefs in the respective places in the data structures, I want to return True
but how do I detect that something is undef?
do I do !$x.defined ? 22:10
moritz_ two undefined objects aren't always the same
rakudo: say undef === undef
p6eval rakudo 33276: OUTPUT[0ā¤]
masak moritz_: let's just say I want to treat them as 'equivalent' in this particular case.
moritz_ masak: I'd say $a ~~ undef && $b ~~ undef && $a.WHAT eq $b.WHAT 22:11
masak or is there a strong reason I shouldn't?
moritz_: yes, that's good. thanks.
any reason not to say $a & $b ~~ undef ?
moritz_ that'l treat 'my $x' and 'my Int $x' differently - don't know if you want that
masak: no, a junction is fine there
masak only time will tell.
goodie. 22:12
22:12 apeiron joined
masak rakudo: say undef ~~ undef; say undef & undef ~~ undef 22:14
p6eval rakudo 33276: OUTPUT[1ā¤0ā¤]
masak what's going on there?
moritz_ rakudobug! 22:15
masak finally :)
wayland76 Sure?
moritz_ rakudo: say undef ~~ undef; say ?(undef & undef ~~ undef)
p6eval rakudo 33276: OUTPUT[1ā¤0ā¤] 22:16
masak sent.
moritz_ wayland76: sure.
wayland76 I would've assumed that any undef & whatever would always come up 0
masak probably the junction as a whole is tested against the undef
wayland76: why?
moritz_ undef & undef ~~ undef dispatches to (undef ~~ undef & undef ~~ undef)
which again yields (True & True)
masak moritz_: well, two && in the second case
moritz_ masak: only in boolean context 22:17
masak ah, yes.
wayland76 Well, I guess I don't understand junctions properly yet :)
masak wayland76: join the club :)
all tests pass!
\o/
22:18 apeiron left
moritz_ if you understand subcall(junction), all the operators with junctions fall out easily 22:18
wayland76 Question: are (1 & (2 ~~ 3) and (1 & 2 ~~ 3) equivalent?
masak no.
wayland76 moritz_: where do I read about that?
moritz_ wayland76: S03 or S06, I think 22:19
wayland76 [That first one was supposed to be (1 & (2 ~~ 3)) ]
Ok, I'll have a look :)
moritz_ basically foo(a|b|c) is viewed as foo(a)|foo(b)|foo(c)
1 & (2 ~~ 3) is 1 & True 22:20
erm, 1 & False
sorry
and (1 & 2) ~~ 3 is (1 ~~ 3 & 2 ~~ 3), which is (False & False) 22:21
in boolean context both yield False
wayland76 Ah, guess I do understand junctions, and made invalid precedence assumptions :) 22:22
sorry :)
22:24 mtrimpe joined
wayland76 (well, maybe "understand junction basics" would be better :) ) 22:25
jnthn will get rakudo doing subcall(junction) and then we'll likely rip out much of the special case code 22:29
22:29 apeiron joined 22:33 apeiron left 22:39 cognominal left
pugs_svn r24098 | wayland++ | Cleaned up text a little bit, hopefully clarified things. 22:40
wayland76 There we go; now we know my commit bit works :)
(unfortunately, I left out the [S07]; sorry :) 22:41
22:48 cognominal joined 22:51 cognominal left 22:55 cognominal joined 22:59 adc_penner left
wayland76 Unfortunately I'll probably be dropping out of the perl6 community for a week or so; now that Fedora 10 is out, the time has come to reinstall my desktop :) 23:00
masak :)
wayland76 But I'll catch up when that's done :)
masak you can IRC from the command line, you know :) 23:01
wayland76 There is that; maybe I should do that
What client?
masak Emacs ERC.
wayland76 That would do it; how do I do that? :)
masak as far as I know, it comes with Emacs 23:02
just google for it to learn how to get it running
wayland76 Good point :)
moritz_ wayland76: I use irssi from the command line; very good stuff ;)
23:02 apeiron joined
masak yes, I hear that's a good one too 23:02
23:06 pmurias left 23:17 bacek_ joined, bacek left 23:18 wayland joined 23:19 wayland left
rakudo_svn r33278 | masak++ | [rakudo] added is_deeply sub to Test.pm, from the November project 23:20
23:21 wayland joined
wayland76 Hmm. Maybe I have to quit XChat first :) 23:22
23:22 wayland76 left 23:23 wayland left, wayland joined, bacek__ joined 23:24 iblechbot_ left 23:26 mtrimpe left 23:27 elmex left, mtrimpe joined 23:30 mbtrimpe joined, mtrimpe left, wayland left 23:31 wayland joined 23:32 wayland left 23:34 masak left 23:45 mbtrimpe left 23:51 DemoFreak left 23:52 bacek_ left 23:56 vixey left

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!