»ö« | perl6.org/ | nopaste: paste.lisp.org/new/perl6 | evalbot usage: 'perl6: say 3;' or rakudo: / pugs: / std: , or /msg p6eval perl6: ... | irclog: irc.pugscode.org/ | UTF-8 is our friend!
Set by wolfe.freenode.net on 30 October 2009.
00:00 tak11 joined
pmichaud oh, $_, $!, and $/ are sooo easy now 00:04
jnthn :-)
pmichaud we just add them with method finishpad() ...
jnthn ohsocool 00:05
pmichaud yeah
jnthn pmichaud: be careful with $_
pmichaud: In the case that it needs to become a parameter.
pmichaud that's easy too
jnthn Yes, but don't forget to add a signature.
00:05 __ash__ joined
pmichaud yeah, but we already have a contextual telling us what we're declaring 00:05
jnthn nod 00:06
That doesn't mean it doesn't need a signauture added though. ;-)
pmichaud no problem
this will let me see how signatures are done in the new system 00:07
jnthn eek!
;-)_
pmichaud if you hear a scream, you know I don't like it :)
and the block will already have a signature created, yes?
I just need to add a parameter
well, depending on the type of block
jnthn At the moment, no
Well
If it's a pointy for example that woulda done so I guess.
But we didn't do pointies yet. 00:08
pmichaud anyway, I'll fix up the signature creation
jnthn Sure.
pmichaud oh. trivial. 00:09
00:10 Schwern left
jnthn Yes, Perl6::Compiler::Signature makes it fairly easy to add a parameter. ;-) 00:10
pmichaud oh, instead of $signature.add_parameter it might've been more consistent to use .push
jnthn Maybe.
I guess I was a tad nervous about it looking too much like a PAST::Node when it actually isn't one. 00:11
pmichaud it might become one someday :-)
jnthn True.
I guess I won't mind if you rename it. 00:12
I'd argue the current name is more descriptive though. :-)
pmichaud I won't argue that. :)
00:13 quuxx left
jnthn Also, add_parameter isn't quite a "push onto the end" either. 00:13
00:13 payload joined
jnthn We may get away with it in this re-write. 00:13
pmichaud good point.
jnthn But in the previous grammar, I had to be a tad careful about making sure $_ ended up before *@_ and so on.
And it was kinda hard to make us push things in the right order.
pmichaud right
jnthn Just 'cus of the parse tree structure. 00:14
pmichaud PAST::Var( :scope('parameter') ) takes care of ordering them properly for you
jnthn I don't know how that'll fall out here, but since you're talking about handling $_ and .finishpad, I rather suspect we'll hit the same issue.
Which is fine, because I left the code that handled this in place. ;-)
pmichaud well, finishpad is easy
if the block already has a signature, then $_ isn't a parameter.
jnthn erm, I meant *in* finishpad 00:15
pmichaud $_ is only a parameter in blocks that don't have an explicit signature.
(unless of course the explicit signature mentions $_, in which case we aren't adding it anyway :-)
jnthn There's a difference between sig and explicit sig, iirc.
e.g. if I mention @_ and %_ is $_ a param too? 00:16
oh, maybe not
I can't remember if I correct a spectest or was caught out by one that was right or something...
It related to this stuff though.
Ah well, when we can run them we'll find out. :-) 00:17
pmichaud the latest incarnation is that if @_ and %_ are mentioned, then $_ isn't an implicit param
jnthn Isn't. Ok.
That makes sense to me.
pmichaud I'll double-check that, but I'm pretty sure that's the case.
jnthn I'd rather like it to be. :-)
pmichaud er, not if they're mentioned, but if they're params 00:18
pmichaud double-checks
00:22 quuxx joined
pmichaud S06: Note that in this case, C<$_> is not treated as a placeholder because 00:23
there is already the C<@_> placeholder. And C<@_> is a placeholder
only because the sub has no official signature. Otherwise it would
be illegal (unless explicitly declared).
jnthn OK. 00:24
00:24 pointme joined
pmichaud so the @_ will have already given the sub a signature, which suppresses the use of $_ as a parameter 00:24
jnthn That's clean and easy.
pmichaud afk for a bit, errands
anyway, I'll get $_, $!, $/ tonight. Possibly placeholders also. 00:25
carlin IRC::Simple can now respond to PINGs so pointme can be here fulltime :-)
pmichaud oh, what do I need to do to make sure that placeholder variables are in the right order?
I guess I can look at master for clues
jnthn pmichaud: call .add_placeholder_parameter on the signature object rather than .add_parameter 00:28
But I didn't update that one yet to use the Parameter objects.
But that's easy, I'll do it now. :-)
s1n_mini should be studying and not reading 00:29
or lurking
00:29 s1n_mini left, justatheory joined
jnthn pmichaud: done. Note that you only call this for _positional_ placeholders, whose order matters. :-) 00:31
00:33 orafu left, orafu joined 00:42 envi^office joined, envi^office left 00:44 Limbic_Region joined
pmichaud okay. and Signature knows how to order the parameters lexicographically, yes? 00:44
(when using .add_placeholder_parameter) 00:45
that's.... awesome
yay, family finally is home 00:46
now we can go get dinner :)
jnthn pmichaud: yes :-)
pmichaud okay, time for dinner here 00:48
I'll bbl, then work on... lots of stuff :-)
jnthn Cool
I'll post in my blog, and then soon sleep. :-)
pmichaud I think I'll have bunches of pieces of Test.pm running soon 00:49
it'll be interesting to start it on the spectests :-)
I'm sure we'll see EPIC FAIL
jnthn Prepare for epic fail!
pmichaud we need something beyond EPIC 00:50
jnthn APPOCALYPTIC FAIL
pmichaud that's it
jnthn ...cus we failed to implement what was in the appocalypses... ;-)
(which given they're now out of date is actual a partial win, but anywyas... :-)) 00:51
pmichaud okay, gone here
bbl 00:52
jnthn o/
00:54 pnate joined 00:59 __ash__ left 01:03 quuxx left 01:04 quuxx joined, pointme left, nihiliad left
quuxx jnthn++ blogged "A productive weekend in Rakudo land": use.perl.org/~JonathanWorthington/j...9?from=rss 01:06
01:07 pnate2 joined 01:15 nihiliad joined 01:18 Whiteknight left, wknight8111 joined 01:20 pnate2 left 01:21 pnate left 01:26 agentzh joined 01:27 b0nk joined 01:28 JimmyZ joined 01:32 pnate joined 01:33 __ash__ joined 01:35 ihrd joined, ihrd left, b0nk left 01:36 b0nk joined 01:40 mjk joined, IllvilJa left 01:46 icwiener left 01:47 pnate2 joined 01:52 kidd left 01:53 nihiliad left 01:58 JimmyZ left 02:01 pnate left 02:06 mjk left, cognominal joined 02:15 pnate2 left 02:18 JimmyZ joined 02:19 JimmyZ left 02:26 quuxx left 02:51 jferrero left 02:52 justatheory left 02:56 Paks joined 03:04 Limbic_Region left 03:09 nihiliad joined 03:11 tak_ joined, tak_ left 03:13 justatheory joined 03:19 nickgibbon left 03:21 jiing joined 03:26 wknight8111 left 03:47 envi^office joined 03:51 justatheory left, agentzh left 03:57 revdiablo joined 03:59 alester joined 04:10 jerry_ joined
jerry_ hi, guys, can anyone give some advices on perl6 vs python 2.6? 04:11
04:12 pnate joined
revdiablo jerry_: Advice about what? 04:12
jerry_ I have learned python 2.6, and I want to learn perl 6, what will be the new things I need to know？ 04:13
revdiablo jerry_: Take a look at perl6.org/
04:16 astrojp left
revdiablo jerry_: Perl 6 is still a work in progress, so the docs are a bit spotty at the moment 04:16
jerry_ revdiablo : do you have any link which compare the two? 04:17
04:21 meppl left 04:22 jerry_ left 04:23 meppl joined 04:25 pnate2 joined 04:38 pnate left, pnate joined
dukeleto pmichaud: ping! 04:52
04:54 pnate2 left
dukeleto pmichaud: i am slightly concerned that nqp-rx depends on a non-released version of parrot: nopaste.snit.ch/18528 . am I missing something? 04:56
05:03 pnate2 joined 05:06 lidden left 05:08 pnate left
carlin dukeleto: Parrot 42174 is released? run Configure.pl with the --gen-parrot option 05:09
dukeleto carlin: i am concerned that it is pegged to a non-release version of parrot 05:10
carlin ohh, I get you
dukeleto carlin: if it is because that is a non-release version of nqp-rx, then that is fine. But i am not sure that is the case.
carlin I see what you mean - ignore me :-) 05:12
05:17 pnate joined 05:31 pnate2 left, pnate2 joined
pmichaud dukeleto: pong 05:36
it's a non-release version of nqp-rx 05:37
but it's also the case that the latest released version of Parrot is not sufficient to run nqp-rx
05:43 pnate left 05:44 Bzek joined 05:45 pnate joined 05:46 am0c joined 05:56 szabgab joined 05:58 pnate left 06:00 pnate2 left 06:15 rgrau left 06:16 pnate joined 06:28 am0c left 06:33 envi^office left 06:38 nihiliad left 06:39 nihiliad joined 06:54 envi^office joined 07:03 envi^home joined 07:05 pnate left 07:15 nihiliad left 07:44 flip214 joined
flip214 Good morning everybody! 07:45
moritz_ oh hai 07:47
flip214 I'm about to really start developing with perl6 Real Soon Now ...
moritz_ that's great 07:48
flip214 But as the (existing) tests of my application (currently written in C) take some hours, I'd be interested to get my perl6-rewrite compiled.
So, are there any news for FFI, native types like int32 and LLVM integration?
I know that it'll be some time until I can really try to run my tests exhaustively, but if every single test takes a few seconds to start up, it gets a bit tedious. 07:49
moritz_ the parrot folks are working on the JIT compiler 07:50
so far they have a proof-of-concept frame builder with a third-party JIT engine
but nothing to JIT-compile PBC yet
flip214 Well, I'd be happier if it got "compiled" to C, for LLVM
I've started to play with swig a bit 07:51
is there anything done for FFI?
Maybe I could provide some (small) starting point
moritz_ parrot has a NCI (native call interface)
which seems to work, mostly 07:52
there are binding for SDL and SQLite, for example 07:53
see examples/nci/ in the parrot repo
07:53 quuxx joined 07:54 Su-Shee joined
Su-Shee good morning. 07:54
moritz_ good morning Su-Shee
Su-Shee meh. I'll have to swim to the office today :/ 07:56
07:56 baest joined, __ash__ left
moritz_ :( 07:57
07:57 iblechbot joined 08:03 renormalist left 08:16 mariuz joined 08:24 alester left
moritz_ lastofthecarelessmen.blogspot.com/2...alive.html last++ 08:25
I feel his summary is much more spot-on than my dry Tidings post 08:26
Su-Shee I woke up with p6 ideas this morning. I really have to organize work and private projects better :/ 08:31
moritz_ your subconcious tells you to work more on Perl 6 ;-) 08:33
Su-Shee indeed :/ 08:34
if you start thinking about project x, you soon realize how much is still missing.
08:36 mberends left 08:42 rgrau joined 08:49 IllvilJa joined 08:55 am0c joined 09:03 cosimo joined 09:13 quuxx left 09:14 quuxx joined 09:20 ejs joined 09:23 envi^office left 09:26 xp_prg left 09:31 renormalist joined 09:53 meppl left 09:59 Chillance joined 10:00 am0c left 10:05 estrai joined 10:37 quuxx left 11:07 wlan joined 11:10 colomon left 11:20 dakkar joined 11:23 payload left 11:24 wlan_ left 11:29 colomon joined, alester joined 11:33 alester left 11:34 KatrinaTheLamia left, flip412 joined 11:35 ejs left 11:36 flip214 left 11:45 krunen left 11:47 krunen joined 11:51 KatrinaTheLamia joined, flip412 left, flip412 joined 11:52 zaslon joined
carlin Hopefully it'll work ... 11:54
zaslon loljnthnhazblogged! jnthn++ 'A productive weekend in Rakudo land': use.perl.org/~JonathanWorthington/j...9?from=rss
carlin Argh
moritz_ looks like my patches got applied, \o/ 11:55
zaslon lolpmichaudhazblogged! pmichaud++ 'Failure()<0xb76d205c>': Failure()<0xb54b2e4c>
11:55 zaslon left
carlin Or not :( 11:56
Oh yes, moritz_++
11:56 ejs joined
moritz_ carlin: I thought I wouldn't have to test pmichaud's blog separately, because it's the same feed generator (use.perl.org) 11:57
apparently that was a wrong conclusion :-)
12:01 flip412 left
carlin I see what's wrong :-) 12:01
12:01 flip412 joined 12:03 zaslon joined
zaslon lolpmichaudhazblogged! pmichaud++ 'Failure()<0xb76d205c>': Failure()<0xb54b2e4c> 12:03
carlin Or not
jnthn ...did pm actually blog?
jnthn hasn't seen a new post
colomon I just looked and haven't found it yet...
12:04 rgrau left
moritz_ Oct 21 is the newest 12:04
12:05 zaslon left 12:08 charsbar left, charsbar_ joined 12:10 envi^home left, tak11 left, zaslon joined 12:11 rgrau joined
carlin that looks better 12:12
now someone just needs to blog something :-)
jnthn well, I'm sure masak will at some point today ;-) 12:13
12:13 envi^home joined 12:17 pointme joined 12:29 lidden joined 12:32 tak11 joined 12:33 am0c joined 12:40 iblechbot left 12:42 pointme left 12:51 payload joined 12:52 masak joined
masak oh hai, #perl6. 12:53
jnthn yayitsSUPERBLOGGERmasak!
masak it's only been one day :P 12:54
am0c oh hai
jnthn masak: Yes, and 29 to go. \o/ 12:56
13:00 payload left 13:02 rgrau left, payload joined 13:04 takadonet joined
takadonet morning all 13:04
carlin one of zaslon's processes is leaking memory :/ one has sat at 110m, the other has kept going up - now at 228m 13:11
masak takadonet: mornin' 13:12
jnthn :-/
masak carlin: I'm not surprised. I see that all the time.
with long-running Rakudo scripts, I mean.
jnthn My Parrot! It's leaking!
carlin It's rss.pl ... maybe I could run that on a cron 13:14
13:16 pmurias joined, pmurias left
masak hm. I liked this post by lilstevey++: use.perl.org/~lilstevey/journal/39827 13:16
I'm not sure I'm awake enough to reply to it yet, but it sure touches on a lot of steps where I've been involved. 13:17
13:17 tak11 left
masak essentially, I think it's great that he's trying to make things work on win32. I'm not sure many people have tried that before. 13:17
jnthn I "tried" to make proto work on Win32, as in, spent about 15 mins and decided it just wasn't going to because it involved bash scripts. 13:19
I ain't tried again since.
And that was a while ago.
masak the bash script is just an auxiliary thing that creates new projects. 13:20
jnthn Ah, I think that's the thing I wanted to do. ;-)
masak it piggybacks on proto rather than being a part of it.
jnthn Thing is, Rakudo / Parrot on Win32 works very well *if* you have the right compiler/OS version.
masak that sounds like good news.
jnthn (MS VC++ compiler on WinXP is fine.) 13:21
Main reason being, that's where I develop.
Annoyingly, because of some Microsoft bs, the compile that should work out great on Vista and Win7 doesn't right at the very last stage.
13:22 am0c left
jnthn But MS VC++ is probably the best route overall, provided the Vista/Win7 issue can be sorted out. 13:22
I'll have a Win7 laptop in the next month or so anyway, so if nobody beats me to it, I'll sort it out so I cna hack on Rakudo on that. 13:23
13:23 alester joined 13:28 rfordinal joined 13:32 pointme joined 13:33 payload left 13:35 alester left 13:36 payload joined 13:41 pmurias joined, envi^home left 13:43 reid04 joined 13:44 rfordinal left 13:47 hirschnase joined 13:53 riffraff joined 13:54 hirschnase left, hirschnase joined 13:57 alester joined, alester left 13:58 hirschnase left, hirschnase joined 14:00 payload left 14:03 alester joined 14:06 riffraff left
pmichaud good morning, #perl6 14:08
14:08 rfordinal joined
moritz_ \ö/ 14:09
masak \ↂ/ 14:10
pmichaud decides to abandon the set of changes he was working on last night. 14:11
moritz_ speaking of abandoning changes...
jnthn pmichaud: A night of sleep made them look less attractive? :-) 14:12
pmichaud need a bit of a rethink
moritz_ yesterday night I showed the awesome simplifications I made to the reduction methods in JSON::Tiny... that did not work
pmichaud they were less attractive when I worked on them last night, which is why they didn't get "commit"
moritz_ it turns out they almost work
jnthn :-) 14:13
moritz_ the reason they don't work fully is that if <foo>* matches zero times, $<foo> is undef, not Nil
pmichaud that's fixed in ng
moritz_ so $<foo>».ast dies with Method .ast not found for invocant of class Failure
glad to hear that 14:14
pmichaud nqp: grammar ABC { token TOP { <foo>* abc }; token foo { foo } }; my $/ := ABC.parse('abc'); say $<abc>.WHAT;
p6eval nqp: OUTPUT«Confused at line 1, near "say $<abc>"␤current instr.: 'parrot;HLL;Grammar;panic' pc 365 (src/cheats/hll-grammar.pir:197)␤»
moritz_ say()
pmichaud nqp: grammar ABC { token TOP { <foo>* abc }; token foo { foo } }; my $/ := ABC.parse('abc'); say($<abc>.WHAT);
p6eval nqp: OUTPUT«Method 'WHAT' not found for invocant of class 'Undef'␤current instr.: '_block11' pc 0 (EVAL_1:6)␤»
pmichaud nqp: grammar ABC { token TOP { <foo>* abc }; token foo { foo } }; my $/ := ABC.parse('abc'); say($<foo>.WHAT);
p6eval nqp: OUTPUT«Method 'WHAT' not found for invocant of class 'ResizablePMCArray'␤current instr.: '_block11' pc 0 (EVAL_1:6)␤»
pmichaud heh
well, at lest you can see it's an Array :-) 14:15
*least
moritz_ ;-)
pmichaud ETOOEARLYTOTYPE
pmichaud@orange:~/ng$ ./perl6 Test.pm 14:16
No applicable methods.
not the error I was expecting, but it looks like we compile and get to execution 14:17
afk, honeydew
mathw hmm 14:18
what is this 'Nil'
14:18 alester left
moritz_ mathw: it's a thing that is undef in item context, and the empty list in list context 14:18
mathw: it's the thing that an empty return; does in Perl 5
mathw aaah
moritz_ do we have a spec solution for map-on-lists yet? 14:21
14:22 __ash__ joined
moritz_ ( (1, 2).map: {.say } tries to bind $_ as rw, but since lists are immutable, that will fail) 14:22
14:24 rfordinal3643 joined
pmichaud I think it needs a mention on p6l. Or perhaps I can add it as a Pm-# question. 14:24
moritz_ I can write to p6l if you want me to 14:28
pmichaud yes, please.
pmichaud@orange:~/ng$ ./perl6 Test.pm 14:29
No applicable methods.
that's such an annoying error message
masak LTA. 14:30
pmichaud I think it's even below LTA
mathw But above something like 'No'
moritz_ abyssimal
pmichaud goes to fix it. 14:31
masak LTA is a half-open interval. it's the bottom part that's open (and infinite) :)
my $LTA = *..$awesome;
jnthn pmichaud: heh, well, it tells you that it's not a Perl 6 Multi.
pmichaud yeah, it's a parrot multi
jnthn (Perl 6 ones at least report the sub name... ;-)) 14:32
pmichaud but it would be nice if it say "No applicable methods for sub ... "
jnthn Right.
moritz_ masak: *..^$awesome please
pmichaud and why is it "methods"?
masak moritz_: oh, right. of course.
jnthn pmichaud: heck knows
masak and I really should have more whitespace. * ..^ $awesome
jnthn pmichaud: p6ms does "No applicable candidates found to dispatch to for '%Ss'"
pmichaud jnthn: perfect 14:33
pmichaud steals code
mathw hmm
jnthn pmichaud: I did ponder that we could dump a list of signatures that are possibles. ;-)
mathw what about "I'm confused. What did you want me to call? I can't find anything like $thing which fits."
or maybe "unable to fit Str-shaped peg in Int-shaped hole" 14:34
jnthn mathw: It's really not that simple.
mathw Yeah multidispatch makes everything more complicated
fun, though
jnthn mathw: I mean, there's a multitude of reasons why the dispatch may have found no applicable candidates.
mathw and the compiler saying "YOU GOT IT WRONG" isn't necessarily going to be accurate 14:35
moritz_ it would be awesome to have a debug mode
jnthn It may be a fun exercise to write a tool that analyses such things.
moritz_ where the error message contains a list of candidates
mathw It might be good to get a list of candidates
moritz_ and for each of them tells you what part didn't match
mathw Do we have an ambiguous dispatch error? That would be a good place for candidates 14:36
moritz_ we do
jnthn mathw: We do, and it already tells you.
mathw yay
jnthn It actually only shows the ones that were in conflict, not all of them.
mathw I like that we're at the stage where I can suggest things you've already written
14:36 rfordinal left
moritz_ rakudo: multi a(Int $, Any $) { }; multi a(Any $, Int $) { }; a(2, 3) 14:36
p6eval rakudo 33111d: OUTPUT«Ambiguous dispatch to multi 'a'. Ambiguous candidates had signatures:␤:(Int $, Any $)␤:(Any $, Int $)␤in Main (file <unknown>, line <unknown>)␤»
pmichaud jnthn: so, last night I worked on $_ as parameter and placeholders....
moritz_ rakudo: multi a(Any $, Any $) { }; multi a(Int $, Any $) { }; multi a(Any $, Int $) { }; a(2, 3) 14:37
colomon That's such a great improvement over the old message...
p6eval rakudo 33111d: OUTPUT«Ambiguous dispatch to multi 'a'. Ambiguous candidates had signatures:␤:(Int $, Any $)␤:(Any $, Int $)␤in Main (file <unknown>, line <unknown>)␤»
pmichaud jnthn: I'm thinking that the complete separation of signatures from blocks isn't going to quite work out
moritz_ note that the Any, Any didn't end up iin the error message
mathw moritz_: that'll be presumably because the two alternatives with Int in them are narrower, so Any, Any has already been thrown away when it determines ambiguity? 14:38
jnthn pmichaud: Why?
pmichaud several reasons
moritz_ mathw: correct
jnthn It'll mean we have to do a few things a little differently, sure.
pmichaud the first is that if we wait until action routine_def to attach the signature, then blockoid can't report back about attempts to use placeholders in a block that has a signature 14:39
but more generally, we really want the variables to be in place before we get to parsing blockoid, not afterwards
s/variables/parameters
jnthn Hmm.
14:40 ejs left
pmichaud however, I think there are some possibly easy fixes 14:40
jnthn OK, here's what my real drive is here.
pmichaud for one, we could attach a signature to the block only if $*IN_DECL is 'routine' or 'method'
jnthn I don't mind if block creation goes looking to see if we've a signature parsed and ready to pick up and attach do it.
I *do* mind if the action for signature creates a block.
pmichaud well, it's certainly the case that signature won't create a block
jnthn s/do it/to it/
pmichaud that's the function of <.newpad> 14:41
jnthn Right, but it did in the previous actions.pm, and it wasn't nice.
pmichaud right, we're not doing that
jnthn OK.
Provided we don't do that, then I'm happy.
pmichaud <.newpad> creates a new lexpad/block structure
signature just attaches itself to that
jnthn hmm
pmichaud but not always, because we don't want to attach a signature when we're in blokoid
*blockoid 14:42
jnthn OK.
STD does this "fakesignature" thing where it creates a throw-away pad.
pmichaud right
jnthn Which I kinda dislike.
pmichaud that doesn't bother me too much
jnthn It just doesn't feel especially clean.
14:42 xinming left
pmichaud it's not especially clean 14:43
but I've had that feeling about signatures in general anyway
I've been thinking about a contextual that says "attach me"
jnthn Could work.
pmichaud I'm a bit reluctant to add too many contextuals... although I do like them much better than flags 14:44
jnthn tbh though, now I know you're not going to shove block creation into signature, I'm probably going to be happy enough with whatever you do. :-)
pmichaud okay
good to know :)
jnthn I just epicly didn't want to re-do that mistake. :-)
pmichaud right
STD has a lot of little gems for us 14:45
for example, I think the place to generate signature (if we don't have one already) is <.getsig>
jnthn Basically it's that and that the signature action method hands back a Perl6::Compiler::Signature.
Then sigterm becomes trivial too.
pmichaud <signature> definitely gives back a PCS
<signature> definitely does not create blocks
jnthn OK, then I'm probably happy. :-) 14:46
pmichaud okay, I'll rework my $_ patch along those lines.
jnthn Great. 14:47
pmichaud++
pmichaud I do have it generating $/ and $! 14:48
and $_ when it knows that it cannot be a parameter
jnthn OK, nice. :-) 14:53
pmichaud hmmmmmmm...... 14:55
jnthn
.oO( plz let next me "oh nm" )
 14:56
masak rot13 in Perl 6. not as simple as I'd hoped... gist.github.com/224204 14:57
maybe I'm missing something.
pmichaud masak: ...trans? 14:58
moritz_ aye
masak there you go. :)
14:58 iblechbot joined
masak that's what I missed. 14:58
masak makes a new, better version
pmichaud oh nm 14:59
jnthn phew, I'm not in trouble. :-)
pmichaud no, it wasn't going to be you anyway. I was thinking that there was something in S02 that indicated that --> was coercion instead of constraint 15:00
a second reading shows that S02 is correct (if perhaps unclear)
jnthn masak++ # implemneting strong encryption mechanisms in Perl 6.
masak here's the improved version: gist.github.com/224204 15:01
looks a lot better :)
pmichaud why not
mathw double ROT13 is such a secure encryption that the text doesn't even look like it's encrypted
pmichaud 'A..Za..z' => 'N..ZA..Mn..za..m' # ?
masak ooh! 15:02
masak does that
gist.github.com/224204 15:03
pmichaud++
mathw now using placeholders
that's just showing off
masak :) 15:04
mathw also, my style sensor's going off
because surely you want a nice explicit signature to help people call it properly
pmichaud masak: so, is perl 6 redeemed?
masak pmichaud: sure. even from the start, I assumed that I was missing something, not Perl 6.
mathw: but it's one line!
jnthn masak: It still has a signature. :-) 15:05
er
masak surely this is the perfect time to use placeholders.
jnthn mathw: ^^
masak aye. though admittedly not an explicit one.
pmichaud it's even explicit :-)
it's just not in pill form
jnthn Interestingly they boil down to exactly the same Signature object being created. 15:06
masak pmichaud: we have different definitions of 'explicit'.
15:06 alester joined
Juerd masak: sub rot13 ($_) { .trans(...) } 15:06
Juerd loves having $_ in a signature. 15:07
mathw jnthn: oh, do placeholders cause signatures to be generated?
masak Juerd: I like. I'll go with that.
mathw Juerd: yes I rather like that too
masak gist.github.com/224204 15:08
Juerd Does the whole CALLER:: thing work? You could even let it default perhaps :D
pmichaud there's even
sub rot13 { $^_.trans(...) }
masak o.O
pmichaud actually, that probably fails at the moment
Juerd Style question: sub name (...) { ... } or sub name(...) { ... }, which makes more sense?
pmichaud TimToady tends to use the first form 15:09
Juerd pmichaud: Wha-wow.
pmichaud I've tended to use the second
mathw I tend to use the second in all other languages which have () around signatures
Juerd The former feels more natural to me, but I've seen mostly the latter.
masak Juerd: an argument for the first form arose in a discussion with mberends++.
mathw Except in C++ operator overloads
Juerd masak: Could you summarize it please?
15:09 Exodist left
mathw because things like operator ()() get a bit eye-bending 15:09
masak Juerd: because space is not allowed in the call, it's more consistent not to use it in the declaration. 15:10
[particle]1 isn't $_ set as an implicit placeholder if none are mentioned, but one is passed?
pmichaud ...what masak said
Juerd Hm
15:10 [particle]1 is now known as [particle]
pmichaud [particle]: not in a routine 15:10
[particle] ah
Juerd masak: Isn't that an argument for the *second* form?
mathw masak: yes, that was the second form
[particle] so you can't do sub rot13 { .trans(...) }
masak Juerd, mathw: oh. right. the second form. 15:11
pmichaud [particle]: you *can*, but it doesn't do what you want, unless what you want is a "use of undefined value" warning
:-)
Juerd Maybe it's that it *isn't* a call, that makes me want to use whitespace. Exactly to make the difference clear.
But I'm just guessing now.
jnthn mathw: yes, place holders just cause generation of a signature.
mathw Juerd: it could be argued like that, yes 15:12
jnthn: unfortunately you have to look in the body of the routine to find the things, so it could easily become non-obvious
pmichaud actually, placeholders are just an alternate mechanism for declaring a signature. we always generate a signature.
mathw I would hope people largely stick to using them for little blocks passed to map etc.
pmichaud even { say(4); } has a signature. :-)
mathw rather than in their subroutines
yay! signature democracy! 15:13
jnthn mathw: Yes, I'd hope so too.
15:13 flip412 left
mathw or is that signature communism 15:13
jnthn mathw: They're nice for small things.
Juerd masak: It's interesting to read the revisions of your rot13 thingy. How you've made it elegant in 4 steps :)
jnthn mathw: The nice thing is that if you have an editor that has loaded the code and introspects the signature of a routine, it'll show up though.
(e.g. if it's doing auto-complete style thingies for sigs) 15:14
mathw mmm
but if you use vim...
masak Juerd: yes. I just tweeted to that effect. :)
moritz_ then you need to make vim smarter ;-)
mathw heh
need to get vim to be able to ask a Perl 6 runtime for help syntax highlighting
jnthn I'm not convinced vim users are the target audience for code completion... 15:15
mathw no probably not :)
I mostly dislike it, actually
it tends to get in my way
visual studio's interpretation of it for C# programming is infuriating, that dropdown thing always appears on top of something I want to look at
jnthn I do like being able to grab a class, do Class.new. and then I have a list of the methods.
Su-Shee too much gui action for my programming taste.
Juerd masak: What's your twitter username? 15:16
jnthn mathw: I quite like Visual Studio's doing of it, fwiw.
Juerd (Mine is Whreq, but I tweet mostly in Dutch)
Su-Shee jnthn: yes. in a menu right or left for example, keeping the main code area visual.
jnthn mathw: Though I then installed Resharper.
Juerd (Oh, and Whreq is rot13("Juerd") ;))
jnthn mathw: And that REALLY annoyed me. :-)
15:17 zaslon left
pmichaud ETOOMUCHLHF 15:17
[particle]: when might you want to chat briefly about S19?
Juerd Too much Let's Have Fun?
Long Haired Freaks? :)
pmichaud Juerd: that, and also "low hanging fruit"
Juerd Ah :) 15:18
jnthn mathw: Guy who tried to get me to install it was like "it makes you more productive! install it!". A couple of days later, I told him that so far it'd lost a couple of hours of productivity to getting mad at it's constant interfering.
pmichaud I have too many things I want to work on at once, most of which are very useful but not very difficult
15:19 xinming joined
Juerd pmichaud: In that case, redesign for imperfection so most of those things will become very difficult. 15:19
moritz_ pmichaud: in that case hide the IRC window ;-) 15:20
[particle] pmichaud: seems i'm caught up enough at work that now (or soon) is good
Juerd moritz_: Or what moritz_ said :D
Su-Shee excellent idea. an ide which can "irc window close on code" ;)
pmichaud [particle]: okay, my question of the moment is about using the type constraints in MAIN to determine the argument parsing
S06:2994 has the following: 15:21
15:21 zaslon joined
pmichaud # Long names 15:21
--name :name # only if declared Bool
--name=value :name<value> # don't care
--name value :name<value> # only if not declared Bool
I don't thik that second choice can be "don't care" 15:22
*think
at least, not if we're following standard Perl 6 semantics
in particular, in Perl 6, mysub(:name<value>) won't bind to sub mysub(Bool :$name) { ... } 15:23
moritz_ unless TimToady continues to magicify the types of <...> quote contents 15:24
pmichaud moritz_: that doesn't help with mysub(:name('value'))
(which is really what this is, in any case)
it could be made to work if we say that the command line option processor looks at the signature of main and chooses to treat a Bool constraint as a coercion... but that seems a little inconsistent to me somehow. 15:25
moritz_ note that it would help with Int :$name
because <3> now produces an Int
Juerd Oh, signatures are going to be used for CLI arguments? Perlfect! :)
[particle] so if you pass --name=True it might coerce to Bool? 15:26
moritz_ that's the question
Juerd asked about that in 2005 but the question remained unanswered :)
masak a good question.
[particle] but not --name=1
pmichaud Juerd: oh yes, and they're multidispatch
masak [particle]: why not? Bool::True == 1
pmichaud but 1 is not a Bool
[particle] --log-level=1
--log-level=2 15:27
masak rakudo: say 1 ~~ Bool
[particle] it's a slippery slope
p6eval rakudo 33111d: OUTPUT«0␤»
masak aye.
[particle] we're already guessing here
masak enums are hard. :/
pmichaud rakudo: sub xyz(Bool :$x) { say $x; }; xyz(:x(1));
p6eval rakudo 33111d: OUTPUT«Nominal type check failed for parameter '$x'; expected Bool but got Int instead␤in Main (file src/gen_setting.pm, line 324)␤»
jnthn If it's just a bool, why not --foo = Bool::True, --foo=... = something else?
Juerd --not-foo 15:28
pmichaud jnthn: right now S06/S19 claim that the parsing of the arguments is based on the signature of MAIN
the problem is handling something like
$ mycmd --switch something
jnthn If MAIN is a multi, that gets more fun too. :-)
[particle] jnthn: correct.
pmichaud according to the current spec, if :$switch is not Bool, the above is parsed like "$ mycmd --switch=something" 15:29
15:30 Chillance left
jnthn Part of me wonders if while we'd use the signature(s) of MAIN to generate usage info and so on, defining a transformation from command line arguments => capture and then letting normal dispatch take over would work out better. 15:30
pmichaud whereas if :$switch is Bool, the above is parsed like "$ mycmd --switch=<True> something"
15:30 Psyche^ joined
jnthn pmichaud: This gets really fun if I declare 15:30
[particle] i'm trying to think of a case that forcing booleans to be passed with --name or --/name (or :name or :/name) doesn't work for
jnthn multi MAIN(Bool :$switch) { ... }; multi MAIN(Int :$switch) { ... } 15:31
:-)
[particle] because adding that constraint isn't onerous
pmichaud [particle]: I think the difficulty is in trying to support "--option xyz" as being the same as "--option=xyz"
15:32 Patterner left, Psyche^ is now known as Patterner
pmichaud if we eliminate that possibility, things get a lot simpler 15:32
[particle] pmichaud: you mean that xyz could be an option value or an argument?
pmichaud [particle]: yes, that's the way the current spec reads
we can't tell if xyz is an option value or argument without knowing the type of :$option
(and in multidispatch, :$option might have multiple types, as jnthn++ points out) 15:33
15:33 pointme left
pmichaud I think that perhaps --option should always mean --option=TRUE 15:33
15:33 __ash__ left
jnthn nod 15:33
[particle] yes, that's what i'm thinking about now
Juerd pmichaud: --option value is very common and I'd dislike having to explain to users that a = is mandatory. 15:34
[particle] yes, that too. sigh.
Juerd It'd also be an upgrade blocker for Getopt::Long users
[particle] de facto standard cmdline syntax suggests --option value means --option=value
jnthn It feels weird to say that signatures influence how we interpret the command line arguemnts, but we also use multi-dispatch to decide which signature matches the arguments we were given.
pmichaud Juerd: "--option value" is common? hmmmm.... I'm trying to remember where I've seen that
[particle] perl -e 1 15:35
Juerd jnthn: That's how it's always been done with gnuish getopts, though.
pmichaud that's "-option", not "--option"
15:35 crazed joined
Juerd perl's command line is ungnuish anyway 15:35
[particle] perl --exeucute 1 # if only perl had long opts
pmichaud single-hyphen means something different from double-hyphen
Juerd It's execute? I reda it as eval :)
s/reda/read/
[particle] i can't spell either 15:36
pmichaud I'm trying to remember if I've seen command line options where the double-hyphen accepts a space-separated argument
[particle] i prefer --option value to mean --option=value
Juerd pmichaud: ls --sort size
[particle] because there's no syntactic difference between -o and --option in perl 6 cmdline
Juerd pmichaud: With GNU ls.
tar --file foo.tar 15:37
etc
[particle] every option has double dash form, and optionally has single dash form
pmichaud [particle]: oh. S06 doesn't demonstrate a single-dash form that accepts "-e 1"
[particle] hrmm, gotta consult the log for S06 on that one, it may have been removed for good reason 15:38
Juerd hopes it's an accidental omission 15:39
Especially in the windows world it's very uncommon to leave out the space
[particle] i'm thinking that Bool sigs can only be specified with -n or --name or --/name, never with equals or space then value 15:41
pmichaud perhaps the best approach is for the option processor to look at a Bool constraint as a coercion, then
moritz_ +1
[particle] then there is no ambiguity that can't be undone
pmichaud moritz_: +1 to which ?
moritz_ pmichaud: to coercion
[particle] will the coercion happen before multi selection? 15:42
pmichaud it has to
because multi selection won't do it
but we still have jnthn's case, where multis could cause the same commandline to be interpreted entirely differently
masak how does infix:<as> square with multi dispatch? 15:43
pmichaud although I suppose the command line argument handler could equally complain about ambiguous dispatch when it tries to figure out the option meaning
15:43 nihiliad joined
moritz_ masak: afaict it works after the dispatch 15:44
Juerd pmichaud: Is type based mmd useful anyway, for cli arguments?
pmichaud Juerd: it might be
Juerd Essentially they're all strings...
pmichaud for example, if we follow TimToady's latest <...> trickery
then --name=3 would result in :name(3 but Str('3'))
masak moritz_: that kinda makes sense. I think. 15:45
pmichaud which means one could use mmd to distinguish between integers passed on the commandline and other strings
jnthn masak: as doesn't play into the dispatch.
masak: It's a signature binding level issue.
masak oki.
jnthn Which is post-dispatch.
Well
heh
ish.
:-)
masak :)
why ish?
jnthn Depends if the signature needs a bindability check, but an "as" won't force one.
pmichaud i.e., one could have MAIN(Int :$name) { ... } and MAIN(Rat :$name) and be able to dispatch based on --name=3 and --name=3/4
masak pmichaud: will one have to provide escaped quotes for Str values? 15:47
pmichaud masak: if one needed to distinguish a Str 3 form an Int 3 on the command line, yes.
masak jnthn: could the 'as' make a bindability check fail somehow?
pmichaud but that's getting pretty esoteric
masak pmichaud: just thinking about how strings would be parsed. 15:48
Juerd pmichaud: But you can't explicitly indicate that your 42 is supposed to be a string, then?
jnthn masak: Heh. I guess if the coercion threw an exception. ;-)
masak: But that's a super evil thing to do.
masak jnthn: well, you know me. :)
jnthn masak: Since it won't just fail the binder, it'll throw the exception back to the caller too.
pmichaud Juerd: one could use ":name('42')" 15:49
jnthn That is, we'll fall out of the binder as well.
masak sounds like fun.
pmichaud (and would have to include the outer quotes on the command line)
jnthn Well, it's the same as if a constraint throws an exception I guess.
pmichaud jnthn: yes, I was about to point that out :)
I think an <as> coercion can throw an exception, but it doesn't happen by default 15:50
it's up to the coercer
jnthn Anyway, I suspect coercers that want to say "oh noes wtf" should give back a Failure that will explode on use.
masak jnthn: it's like constraints have a certain 'purity' to them, which expects you not to start throwing exceptions. I smell a Best Practice falling out of this.
jnthn masak: Correct, and it's the same rule for coercers I suspect.
masak jnthn: espectially because people have to be careful not to implicitly throw exceptions.
jnthn masak: Sure, but a lot of things in Perl 6 are failsoft. 15:51
masak they are. that definitely helps a lot.
moritz_ rakudo: say Complex.new('a', 'b').perl 15:52
Su-Shee "fail save, fail soft - perl 6!" I can see it on tv!
p6eval rakudo 33111d: OUTPUT«Complex.new(a, b)␤»
pmichaud o_O
jnthn wow 15:53
That may just be a fail.
pmichaud That's seriously broken.
moritz_ Complex doesn't do any type checks on its two slots
pmichaud it should at least do coercions, though
moritz_ it should check for Numeric, probably 15:54
which is NYI
pmichaud and if not that, then it should at least .perl its re and im parts
and not just stringify them
it should probably .perl its re/im parts anyway
moritz_ agreed
pmichaud relying on stringification for .perl is probably an anti-pattern
moritz_ spectesting the fix... 15:55
15:57 Chillance joined
pmichaud [particle]: anyway, if you come up with any ideas for resolving the boolean argument conundrum, let me know. I may start prototyping a command line argument processor in NQP this week (will need it for the new hll compiler object) 15:57
15:57 Chillance left, Chillance joined
[particle] my grant has me working on tests first, before the arg processor 15:58
but i think those can be developed side-by-side
pmichaud right
that's generally easier anyway
[particle] and i have some time this week to work on an arg processor
i only need to unblock one thing... i can't build rakudo
this has blocked me for a few weeks 15:59
pmichaud A couple of weeks ago I figured out a syntax to use for the argument processor
[particle] but i'll fix it by changing platforms to ubuntu
"fix" that is.
pmichaud [particle]: oh, I think there should be a version written in nqp
so then it works for all of parrot, not just rakudo
15:59 zloyrusskiy joined
[particle] that'll work. nqp-rx. 15:59
pmichaud anyway, I'll be very happy to prototype one up and then let you take over from there :) 16:00
[particle] my idea was to prototype in p6, port to parrot, then rewrite in p6
but nqp will fix the prototyping bill nicely
pmichaud I think write one in nqp-rx, and the write another for rakudo based on the nqp-rx one
[particle] yep
pmichaud (but we'll keep the nqp-rx one for other compilers and tools to use)
anyway, as I said, I figured out how I think an interface should/could look, and started to write it in PIR, then said "I really want nqp-rx regexes to do this" and got back to work on nqp-rx :) 16:02
[particle] :)
pmichaud but then ran into the "Bool is a constraint, not a coercion" problem.
[particle] i'll let the bool conundrum rattle around a bit
pmichaud okay
for now I'll start with the idea that bool arguments can't have = 16:03
[particle] okay
16:03 jsut|work joined
[particle] i think it'll become more clear by writing tests. i like to see the syntax in action to determine how best an api should be designed 16:03
so, i'll likely scribble some down 16:04
16:12 REPLeffect_ joined 16:13 pnate joined 16:14 astrojp joined, KyleHa joined 16:18 wlan left
pmichaud particle++ # some quick answers on S19/S06 16:21
moritz_ [particle]: for test writing Test::Util might be useful, which spawns another perl6 program\ 16:22
[particle]: though you might need to extend it a bit to allow custom options/ARGS to be passed to the script
pmichaud although the more I think about it, the more it starts to feel like introspect-and-coerce might be the better approach 16:23
or if we come up with a syntax that specifies coercion and constraint at once, that can work also. (I'm not yet convinced the Any(Bool) syntax is going to work.) 16:24
moritz_ neither am I
jnthn Especially given the last discussion on this had it just as sugar anyway, iirc.
pmichaud pmichaud@orange:~/ng$ ./perl6 Test.pm 16:26
No applicable candidates found to dispatch to for '&infix:<=>'
okay, much more helpful.
moritz_ ship it! 16:27
or so :-)
jnthn Parrot. Learning from Rakudo. :-)
[particle] moritz_++ didn't know about T:U 16:28
moritz_ (it's stored in t/spec/packages/)
and KyleHa++ for writing it
pugs_svn r28973 | lwall++ | [S06] correct $_ placeholder binding from "rw" to "ref", moritz++ 16:31
moritz_ reads up on 'is ref'
pmichaud I didn't think 'is ref' would be sufficient either, I need to re-read also 16:32
masak I always associated 'is ref' with 'alias'. 16:33
jnthn Same.
pmichaud oh, it looks okay.
TimToady well, it can't be rw, or you can't bind 1,2,3
pmichaud right
moritz_ Unlike C<is rw>, the 16:34
corresponding argument must already be a suitable lvalue
pmichaud I know it can't be rw... but S06:2001 says that 'is ref' requires an lvalue
TimToady if you modify it
pmichaud okay, unclear spec
moritz_ right, that's what I was just looking at
masak so, 'is ref' is the in-between DWIMmy cousing of 'is rw' and 'is readonly'. 16:35
pmichaud 'is ref' basically means "it's the exact same object, no aliases or proxies involved"
so you get the exact same rw-ness as the argument itself 16:36
masak nod.
moritz_ so that part of the spec should probably read "Unlike C<is rw>, the corresponding argument must already be a suitable lvalue if an attempt is made to modify it" 16:37
jnthn that means "it blows up at the point you modify it" yes? 16:38
moritz_ yes
16:38 cotto_work joined
jnthn Amusingly, that probably means that Rakudo's current impl of "is rw" is actually the correct semantics for "is ref" ;-) 16:39
16:39 rfordinal3643 left
pmichaud jnthn: does "is rw" do a direct bind at the moment? 16:40
jnthn pmichaud: yeah
:-)
pmichaud yeah, that's "is ref"
jnthn pmichaud: I didn't do anything for is rw because I was waiting on the rw flag to exist. ;-) 16:41
pmichaud "is rw" needs to create a new container (same as readonly), set the "rw" flag and check the rw-ness of the thing it's binding to
pugs_svn r28974 | lwall++ | [S06] clear up definition of 'is ref'
jnthn pmichaud: huh? why the container?
pmichaud jnthn: it needs a type
jnthn oh
16:41 hirschnase left
jnthn hmm. 16:41
pmichaud sub mysub(Int $x is rw) { ... }
jnthn Really?
16:42 hirschnase joined
jnthn Doesn't that just mean "the thing coming in must be an Int"? 16:42
pmichaud "does Int"
jnthn heh, netiher
ACCEPTS Int. :-)
pmichaud right
anyway, if I have
sub mysub($x where { $_ / 2 == 0 } is rw) { ... } 16:43
I not only have to do the check at binding time, but also for all subsequent assignments to $x
jnthn orly?
16:43 frodwith joined
jnthn Spec reference? 16:43
moritz_ it's the same as
pmichaud isn't it the same as my $x where ....
moritz_ declaring a subset type
rakudo: my $x = 3; sub f(Int $y is rw) { $y = 5; }; f($x); say $x 16:44
jnthn It's not implemented like that now...
p6eval rakudo 33111d: OUTPUT«5␤»
moritz_ rakudo: my $x = 3; sub f(Int $y is rw) { $y = 'foo'; }; f($x); say $x
p6eval rakudo 33111d: OUTPUT«foo␤»
moritz_ rakudo: my Int $x = 3; sub f(Int $y is rw) { $y = 'foo'; }; f($x); say $x
p6eval rakudo 33111d: TIMED_OUT 16:45
pmichaud jnthn: it needs to be. Type constraints on containers in a signature need to be considered in addition to the constraints of the thing they reference
jnthn pmichaud: I still want to see a spec reference for that.
I don't recall reading one.
pmichaud I think it falls out of the simple fact that parameters are like my-scoped variables 16:46
jnthn It depends whether you interpret the type constraints in the signature as a part of the signature or also as influencing the resulting variable declaration.
It isn't obvious to me that they should be both.
pmichaud I see it as being no different than my (Int $x) .... 16:47
clearly the type is influencing the variable declaration.
but we can add it as a Pm-## question 16:48
adding.
jnthn Given that we already know the fact that we parse a signature there doesn't actually imply signature semantics in any wider sense doesn't really make that a sure-fire precedent.
pmichaud fair enough, we'll just get clarification from the TimToady oracle
jnthn Sure.
Note that if we do need to implement this, it's not just setting the current constraint on the container. 16:49
It's anding it with any other constraints already on the incoming thing.
pmichaud right
that's what "need to be considered in addition to the..." means
jnthn Which I guess we can do, but then we gotta start building up a type junction or something per rw we bind.
pmichaud I figure it's just an and Junction
TimToady I'm inclined towards pm++ish view, but let me think about performance a bit, and the relationship to single-assignment semantics 16:50
jnthn Yeah, but do we really want to be building up that every binding?
pmichaud is it that expensive?
just create a new 'and' junction with the two candidates
TimToady sounds more like a derived anonymous subset type to me
jnthn Well, if we approach everything as "is this individually expensive", I guess we could argue for a lot of things. 16:51
Then we end up being slow overall.
TimToady well, part of the reasoning for adding the constraints in multisigs is that checking is factored back into the dispatcher 16:52
so doesn't need to be repeated in the body
and for readonly parameters, that's the end of it
rw parameters are fairly rare, actually
pmichaud and creating a junction is really not that expensive 16:53
TimToady rw my vars are much more common, of course
16:53 zaphar_ps joined
pmichaud (creating an anonymous subtype is likely a bit more expensive) 16:53
TimToady well, presumably one leg of a junction can be an outer junction 16:54
pmichaud right
jnthn Well, true, your spec change did just make rw's more rare.
pmichaud thus I'm thinking all( $var_constraint, $arg_constraint)
where $arg_constraint could itself be a junction of constraints
jnthn OTOH that means that :(Int $x is ref) and :(Int $x is rw) will have different semantics on what you can assign, unless we're going to wrap that one too.
16:54 PerlPilot joined
pmichaud I'm not sure about the "Int $x is ref" case 16:55
jnthn pmichaud: That'll get hilarious for deep recursion with rw parameters...
TimToady well, the fact that there's a subtype is known at declaration time, so it's not anonymous in that sense
pmichaud TimToady: yes, but we don't necessarily know the full details of the subtype until we have the argument we're binding with. Or perhaps I'm misunderstanding how subtypes would work here.
16:56 zloyrusskiy left
pmichaud aborts writing a new pm.txt question for now, since TimToady++ is engaged on the topic. :-) 16:56
jnthn TimToady: We don't know the constraints already on the container that is getting passed in.
So we'd have to derive the subtype each time I guess.
16:56 PerlPilot left 16:57 PerlJam joined
jnthn Doesn't really work out any better than the junction. 16:57
TimToady the junction already has dedup logic, presumably 16:58
jnthn Yeah, true.
I guess it'd not get too huge.
Or could be made OK. 16:59
17:00 justatheory joined
TimToady seems like 'is ref' doesn't commit to whether it's expecting an Int object or Scalar[Int] 17:01
whereas 'is rw' requires Scalar[Int] 17:02
or at least Container[Int] 17:03
17:03 eternaleye left, NorwayGeek left
pmichaud I somehow think of "Int $x is ref" as being a bindability check but not a subsequent assignment check (like what Rakudo's "is rw" is doing now) 17:03
17:03 NorwayGeek joined
TimToady and Scalar[Int] happens to be ACCEPTED by Int 17:04
17:04 NorwayGeek left
jnthn I guess that's just because the container is transparent in that case. 17:04
pmichaud in particular, "is ref" isn't making a new container
17:04 NorwayGeek joined
jnthn pmichaud: Right. My issue is whether is rw should be making a new container also. 17:05
TimToady rw is what drives autoviv
jnthn That is, I'd seen is rw as is ref + rw-ness check
pmichaud TimToady: so does autoviv imply that rw makes a new container? 17:06
17:06 px3tado joined
pmichaud (apologies if I'm missing the obvious answer) 17:06
TimToady if you get a WHENCE object Scalar[Int]{ #`{stuff to insert into array/hash} }
17:07 am0c joined
TimToady which is what the array/hash ref returns for a non-existent element unless it knows for sure that it's only an rvalue 17:07
in which case it can return the failure directly
in the case of a multidimensional array you can get cascading WHENCEs 17:08
17:08 NorwayGeek left
pmichaud hmmm, ng is currently doing this in terms of a proxy type. Hadn't considered the possibility of WHENCE 17:09
17:09 NorwayGeek joined
TimToady each of which adds the new element for that dimension 17:09
pmichaud that makes good sense
TimToady WHENCE *is* a proxy type, kinda
pmichaud right
I see that now
cool
when we have WHENCE working again I'll convert to that :-)
TimToady it's not just for lazily BUILDing role components
in fact, in S12:2084 it's called an "autovivifying closure" directly 17:10
pmichaud TimToady: right, I hadn't made the connection to autovivifying in a aggregate 17:11
but that makes excellent sense
anyway, 'is rw' semantics isn't something that I think we have to resolve today -- at least not for the things I'm working on 17:12
Test.pm now parses and gets to execution, failing on "Could not find non-existent sub &END 17:13
TimToady another thing I'm going to have to rethink is that CANDO in packages seems a bit useless now, given we don't look in packages for multis
17:13 px3tado left
TimToady maybe lexical CANDO will work for that 17:13
moritz_
.oO( somehow CANDO always looks like the name of a nuclear reactor to me )
 17:14
TimToady though how that differs from a redispatching only, I'm not sure...
that's DU
moritz_ right
pmichaud not to be confused with MANDU, MANCHU, or CHOOCHOO :-) 17:15
jnthn mmmmm...mandu...
pmichaud is there a canonical method for obtaining a package namespace from a type object?
jnthn gah, I want Korean/Chinese food now. :-)
TimToady I suspect that lexical CANDO might be a rather strong pessimization, at least for the tails of candidate lists
pmichaud as in, something that I could do TypeObject.method
TimToady but the tail includes CORE 17:16
jnthn TypeObject.WHO iirc
pmichaud ooh 17:17
TimToady so you wouldn't be able to optimize builtins
pmichaud .WHO it is!
that's getting added to p6object, like, now.
jnthn
.oO( class Doctor { ... } )
 17:18
pmichaud I think I'll add .WHERE while I'm at it, too. 17:19
TimToady maybe a CANDO only registers a routine to call if the normal dispatch (all the way out to CORE) fails
pmichaud .WHERE will be useful for people writing nqp-rx 17:20
jnthn pmichaud: Rakudo already had at least one of those two, fwiw.
If not both.
pmichaud WHERE
jnthn (no object to them going into p6object, just mentioning)
If you can find WHERE it is, you can just copy paste. :-) 17:21
pmichaud I also want something like a PARROTHOW
TimToady note that WHERE doesn't guarantee conversion to Int <evilgrin>
pmichaud although I suppose now it's just get_class $obj.WHO
jnthn TimToady: Show me the hardware with non-integral memory addresses. :-P
TimToady NUMA 17:22
jnthn OK, you win.
:-P
TimToady
.oO(I'm getting a real tongue-lashing)
 17:23
.(etymologically speaking, after a tongue-lashing one should be tongue-tied) 17:25
17:28 Patterner left 17:29 Psyche^ joined 17:30 Psyche^ is now known as Patterner, KyleHa left
TimToady (actually, the two meanings of lash probably have different etymologies, though they're not entirely sure) 17:32
masak swimming & 17:33
jnthn masak: ...to Riga? ;-)
masak jnthn: I'd better start now, haven't I? :P 17:34
(hm... "hadn't I"? English is hard for us non-natives...) 17:35
pmichaud "eh?"
as in "I'd better start now, eh?" :P
masak I said 'English', not 'Canadian'. :P
& # really 17:36
17:36 stephenlb joined
eiro hello all 17:37
takadonet pmichaud is Canadian?
pmichaud nope
japhb He's Terran. We think. 17:38
alester mmm, not so sure on that.
japhb Actually, nobody's completely sure.
alester He said Texan, so all bets are off.
japhb He could have a zipper on his forehead we just don't know about yet.
pmichaud I'm American. Or Californian.
I'm a Texas immigrant.
er, immigrant to Texas.
japhb I used to work with a Swiss German Texan. A drawl with a Swiss German accent is an amazing thing. 17:39
pmichaud there are quite a few germanic pockets in Texas
17:42 meppl joined, dakkar left 17:47 zloyrusskiy joined, zloyrusskiy left
TimToady I've got a few Texan pockets on some of my shirts... 17:47
jnthn Ok...finally, @task done. I can probably spend the rest of the day on Rakudo. :-) 17:50
17:55 xinming left 17:56 pmurias left, mariuz left 17:58 am0c left 17:59 icwiener joined, cdarroch joined 18:00 kidd` joined 18:07 Su-Shee_ joined
pugs_svn r28975 | lwall++ | [S10] install note about rapid fossilization of package CANDO section 18:08
jnthn ooh, sometimes deying the existence of sections of the spec that I didn't yet figure out how to implement does pay off... 18:10
18:11 Su-Shee left
pmichaud jnthn: that's been my experience :) 18:13
jnthn pmichaud: What're you hacking on at the moment, out of curiosity?
pmichaud END blocks
jnthn (i'm just building stuff...)
OK, cool.
Last hurdle for Test.pm? 18:14
TimToady it would be easy to install CANDOs as failovers, but overrides of core subs/methods is more problematic
pmichaud (last hurdle) might be.
jnthn TimToady: I'd been sorta expecting it was going to be a failover mechanism. Hmm.
pmichaud compiling Test.pm is a bit slow, so we may need some profiling soon
jnthn pmichaud: Aww. OK.
18:15 quietfanatic left
pmichaud anyway, it's something that we can easily sic the parrot profilers on :) 18:15
jnthn Yes.
At least we have a profiler now!
pmichaud especially since rakudo-ng is not so big that it takes hours to profile
jnthn Yes.
pmichaud (and profiling nqp is equally useful)
jnthn Our startup time is kinda nice.
Well
Compared to master.
I wonder how well we can keep it down. 18:16
OK, what do you need most from me?
pmichaud we'll figure out how to keep it manageable
moritz_ by not doing more stuff? ;-)
jnthn If the answer is "nothing", I'll work on package decls.
pmichaud I don't have anything I need most at the moment. my guess would be class decls
jnthn Oh, did you want the Code classes putting back in too?
pmichaud oh, that would definitely be useful, yes.
either of those would be great 18:17
jnthn OK, here's what I'll do.
18:17 Su-Shee_ left
jnthn I'll scribble a plan for what I want to do with package decls. 18:17
Then at least the mentally challenging part is done before it gets much later into the day. :-)
pmichaud wfmvm (very much)
jnthn Then I'll do the code types, and then the package delcs bits, which by then should just be a case of writing code. :-)
18:17 Su-Shee joined
jnthn pmichaud: ouch, something seems to have caused a regression in 07-simple-multisubs.t 18:25
pmichaud possible
I don't think I committed any of my experiments last night, but it's possible I did 18:26
jnthn it's a simple test file, it should be easy to work out why it's broken
I'll look in a moment.
pugs_svn r28976 | lwall++ | [eigenstates.t] fix parsefail
pmichaud yeah, afaict I left the <signature> stuff alone.
I changed a few other things dealing with blocks, though. 18:27
but I don't think I touched anything that impacts signatures
(although obviously I did :-)
jnthn The multi generation still looks correct. 18:28
pmichaud perhaps something else changed somewhere, then
jnthn Hmm, the sig doesn't look wrong. 18:29
oh hmm 18:30
oh f**k
.lex "$arg1", $P72 18:31
.lex "$arg2", $P73
I didn't put back the vivification of the parameter lexicals.
Which is fine in theory for now.
But in practicel Parrot-- is probably giving those two the same underlying register. 18:32
Since $arg1 and $arg2 are ending up with arg2's value.
:-|
18:32 KyleHa joined
pmichaud oh, I noticed that <default_value> always ends up generating a closure 18:32
does it have to be that way?
jnthn Only if there's a default value.
pmichaud yeah, but having a closure for every $x = 4 seems awfully icky 18:33
jnthn It shouldn't generate anything if there's not.
pmichaud the previous version did it w/o closures
jnthn It needs to be a closure.
Not since the new binder landed.
You can't really avoid it.
Well, not easily...
I guess if it's just a PAST::Val we could store that directly in the signature...
TimToady you can presumably optimize away the outer closure if the inside is constant
jnthn Yeah 18:34
I guess could do that.
Well, optimization later...
pmichaud it needs to be a closure because we have to do the binding checks after binding the defaults...?
jnthn It needs a little care to make sure that :($x = { ... }) doesn't end up doing the wrong thing. 18:35
pmichaud well, sure, but in that case we already have a closure
jnthn pmichaud: If it's not a literal value, it needs to be a closure so the binder can run the code.
pmichaud: Well yes but we shouldn't run it then.
:-)
pmichaud and the binder has to run the code because...
jnthn ...what else is going to?
18:36 mberends joined
pmichaud previously it was being done as the prologue of the subroutine 18:36
jnthn isn't really understanding where this is going
Yes, apart from we unpack the args ourselves now.
Also it was kinda wrong-ish.
pmichaud well, as far as default values is concerned, we were doing that level of unpacking ourselves also
jnthn Anyway, we can optimize it for literals later on. 18:37
pmichaud okay
jnthn Before we were doing two passes over the sig and handling some aspects of the binding in one phase and some in another.
Whereas really the signature is menat to be bound left to right.
pmichaud you mean bound and checked 18:38
or you're including checking as part of binding
jnthn Yes.
pmichaud okay
I agree that's different
jnthn What I'm trying to get at is, in ($a, $b) we need to do all the wrok for $a and then the work for $b really.
pmichaud yes, okay, np 18:39
jnthn Since if the binding of $a somehow affects it, and we use it in $b's default value...
pmichaud that's the way it worked pre-binder as well, except that the typechecks were performed all at the end instead of after each argument 18:40
at least, that's the way I had imagined it working
anyway, if we optimize the constant case later, I'm happy 18:41
jnthn Well, the issue is that type checks maybe aren't just checks, if you have a modifying constraint.
pmichaud right
jnthn But bigger deal was we were applying context in the second stage.
pmichaud it's the same sort of issue we have with initializing attributes, btw 18:42
jnthn Yeah, they need to be done in order.
pmichaud so if we could somehow use the signature binder to initialize our attributes.... that migth be a big win
jnthn ooh, evil.
Kinda in an amusing way
Given signatures already support attributive parameters ;-)
pmichaud :($!a, $!b, $!c) := @_;
jnthn ooh
pmichaud or actually := %_
jnthn Hmmm...mmm... :-)
pmichaud then BUILD and new become much less expensive :-) 18:43
jnthn Like!
pmichaud and we just keep a signature for the class that we use in the binding
jnthn Well yes, if you do it as :(:$!a, :$!b, :$!c) you can just have a hash over there on the right. :-)
pmichaud and has declarations just build the signature object
jnthn Mmm. 18:44
jnthn updates his notes
pmichaud and their default values are just the same default values that we use in a signature bind, and constants can be optimized but everything else is a closure
okay, WIN
jnthn Well, nearly.
We have a slight issue.
In that if a BUILD did init the attribute, we can't go and stomp on it with a default. 18:45
pmichaud (if the caller did supply the parameter, we can't go stomp on it with a default)
jnthn That's a bit different though.
pmichaud why?
oh, I think I see 18:46
still, I think it can be handled
jnthn class Foo { has $!a; has $!b = 42; has $!c; submethod BUILD { if moon_phase_check { $!b = 42 } } }
oh fail 18:47
class Foo { has $!a; has $!b = 42; has $!c; submethod BUILD { if moon_phase_check { $!b = 41 } } }
pmichaud when do the attributes get initialized there?
jnthn Foo.new() # $!b should sometimes end up as 41
pmichaud i.e., relative to BUILD
jnthn S12 says something like "if the BUILD method init'd it, we don't update it"
pmichaud right, but when does that happen?
jnthn Post-BUILD. 18:48
We call a custom BUILD if there is one.
pmichaud so, don't initialize any attributes that are non-null
jnthn heh heh
Well, no, not non-null I guess.
Because $!b = 42 # $!b really best not be null, but rather an empty scalar 18:49
pmichaud we can always check it for emptiness, same as we have to do for @Foo::bar = 5
jnthn Yeah, true.
Then non-null works.
pmichaud or let it default to a scalar with a WHENCE
(that then does the binding)
jnthn Oh, that's interesting.
pmichaud or we could initialize attributes to PMCs that mean "I'm not initialized yet" 18:50
jnthn Or that.
pmichaud seems like there are a lot of possibilities.
jnthn Yeah, it's just picking the best / most efficient one. :-) 18:51
pmichaud but having the binder take care of defaults on attributes just feels like a huge win
because it replaces our slowish code with fastish code for object creation/initialization
jnthn Yeah, agree. 18:52
18:52 SmokeMachine joined
jnthn Plus whenever we optimize the binder, that gets faster too. 18:52
pmichaud right
bbiab 19:00
19:14 lollan joined 19:19 jferrero joined
pmichaud (b) 19:20
pmichaud switches venues 19:22
it's mind-bogglingly beautiful weather outside today, so I'm working outside. 19:23
(coding, yes, but at least outside)
19:28 abra joined
zaslon lolpmichaudhazblogged! pmichaud++ 'Failure()<0xb53b19a8>': Failure()<0xb53b0bd4> 19:28
jnthn ...orly? 19:29
pmichaud I have no clue. 19:30
jnthn Apparently if you did, your post was a failure in more than one way. ;-)
zaslon lolpmichaudhazblogged! pmichaud++ 'Hague grant work: the new regex engine and NQP': use.perl.org/~pmichaud/journal/39779?from=rss
jnthn btw, envious of the outside coding. 19:31
Also, I think I have a way forward on package decls that I don't hate too much.
19:31 lichtkind joined
pmichaud yeah, about 22degC here. No wind. 19:31
jnthn ooh, nice.
pmichaud well, just slight breeze
no clouds
19:32 Bzek left
pmichaud sun is autumn sun so it's not blindingly bright 19:32
jnthn Texas. Perfect weather, a few days a year. ;-)
Here it's already winter, practically. 19:33
pmichaud This year has been exceptional weather, at least for me
cold weather from last winter lasted until late may, got hot over the summer but only for a short period of time, we're back to mild weather here in autumn, and lots of rainfall in Sep + Oct 19:34
jnthn Wow
That almost sounds nice. :-)
Just need to escape during the really hot bit. :-)
OK, I've got enough decided that I'm going to go ahead and implmenet it. :-) 19:35
pmichaud \o/
jnthn But after code blocks.
pmichaud wait till you see what I've got :)
(it'll be another hour or two)
jnthn Oh man, the suspense!
I'm actually making an attempt at defining how people can (later) do custom meta-classes, and building our package support in that same way. 19:36
moritz_ regex assertion not terminated by angle bracket at line 152, near "($*IMPLICI"
pmichaud moritz_: need to update nqp-rx, probably
jnthn moritz_: ENQPRXTOOOLD
Yes, that fixed the same error for me.
19:37 jferrero left
pmichaud I need to figure out a good way to get revision numbers into nqp-rx. I'm still thinking "$release.$commitcount" 19:37
jnthn So once there's a way to derive a slang, and add a new scope_declarator, we'll be in business. :-)
Even better, I'm arranging it as something I'll be able to add in docs/, where everyone can ignore it. ;-) 19:38
OK, code types and dinner cooking now... 19:39
19:39 pyrimidine joined
jnthn oh, and apparently a new Parrot. 19:39
pmichaud just realizes that with the vivify opcode he can simplify a ton of his other code 19:40
I guess I need to do vivify next :-) 19:41
19:41 abra left
pmichaud actually, I think I'll write it now 19:43
I guess there's not a way to have static functions in a *.ops file? 19:46
jnthn pmichaud: yes 19:47
pmichaud yes there's not a way, or yes it can be done?
jnthn I think just put it between BEGIN_OPS_PREAMBLE and END_OPS_PREAMBLE
And it should work fine. 19:48
pmichaud ohhh
okay
I see
jnthn afaik that code is just grabbed and shoved as-is into the generated C file.
19:52 TimToady sets mode: +vv hugme iblechbot, TimToady sets mode: +vvvv ilbot2 ilogger2 IRSeekBot lambdabot, TimToady sets mode: +vvvv lisppaste3 p6eval phenny pugs_svn 19:54 TimToady sets mode: +v zaslon
diakopter sortof awakens 19:56
19:57 alester left
mberends hi diakopter 19:59
diakopter mberends: howdy 20:00
E2MANYIDEASGOODANDBAD 20:01
mberends heh
20:04 xp_prg joined 20:18 masak left 20:20 pyrimidine left
pugs_svn r28977 | kyle++ | [t/spec] fudge junction test Rakudo no longer runs 20:23
20:30 nihiliad left 20:33 nihiliad joined 20:34 TSa joined
TSa HaloO 20:36
mberends Oh HaI
PerlJam greetings
TSa how does one make an object an lvalue? 20:37
I mean one that is assigneble in an is ref param
moritz_ I'd like to know that too 20:38
TSa Ohh 20:39
jnthn is ref doesn't enforce assignability anyway - is rw is what does the "can we assign to it" check. 20:43
I know what the "in Rakudo" answer to flag something rw, but I don't know the "in Perl 6" one. 20:44
20:44 Su-Shee left
TSa Can we write an infix;<=> ala the C++ assignment op and than autogenerate e,g, ++ from it? 20:45
moritz_ I somehow don't think overloading infix:<=> will be the way to go 20:46
we discussed FETCH and STORE methods instead
where STORE is called by infix:<=>
jnthn Oh, if it's "how do we implement something that is assignable" - yes, FETCH and STORE. 20:48
I'd understood the question more as, how do we flag something as being valid for assignment. 20:49
moritz_ how
s/how/oh/
maybe I just projected my own questions onto TSa's :) 20:50
jnthn :-) 20:54
TSa Well, now :($x is ref) is very much like :(Object $x) 20:55
jnthn ...erm. 20:56
No.
:(Object $x) means "$x is readonly, and has an Object type constraint on it"
:($x is ref) means "$x has whatever the default type constraint is depending on how the signature is used, and is exactly the thing that is passed" 20:57
TSa yes, but you can call any modifying method on it
jnthn Yes, but you can't assign to it.
TSa but isn't STORE just another method? 20:58
jnthn It's a method on the container rather than the value.
20:58 simcop2387 left 21:02 simcop2387 joined
TSa So you can implement STORE in a class but it is called only when a param is ref? 21:04
PerlJam idly wonders if #parrot is making progress 21:18
21:18 NorwayGeek left
jnthn PerlJam: Frankly, it sucks that those of us who have experience implementing languages on Parrot have to have arguments like these to get things we need in place, thus blocking us from actually getting stuff done. 21:18
*like this
21:19 synth joined
PerlJam jnthn: indeed. From an interested-party-watching-on-the-sidelines, I've seen virtually this same discussion at least 3 times (maybe more) 21:20
not exactly the same, but the same nonetheless
jnthn Yeah. Some days Parrot is as much a liability and an asset.
s/and/as/
diakopter as is every dependency with high fork-aversion... 21:24
TSa Was that interested-party-watching-on-the-sidelines me? Sorry if I disturbed the flow of things. 21:25
PerlJam TSa: no, no, I was referring to chatter in another channel that's intimately related to language dev with parrot. 21:26
(and since Rakudo is parrot-based it's relevant here obliquely :)
jnthn: perhaps you can answer this since pmichaud is occupied: what's the minimum neede for an "empty" compiler using parrot + nqp-rx? 21:27
jnthn "minimum need"? 21:28
moritz_ parrot and nqp-rx ;-)
jnthn If you just mean what do I need to download and install, just those two, yes. :-)
PerlJam moritz_: :-P
jnthn I'm suspecting you maybe meant something else, but I don't quite get what, sorry.
PerlJam jnthn: If I were building a compiler, and I have an ueber simple grammar and actions and I can compile them with nqp, what else is needed to make a compiler out of it? 21:29
21:30 hercynium joined
jnthn PerlJam: A file like Compiler.pir that subclasses the HLL class, and is just the little bit of startup code/entry point. 21:30
PerlJam: Soon you'll be able to do that in NQP too.
PerlJam: And beyond that, just any language built-ins you have.
PerlJam maybe I'll go write a small language later and then come back with more specific questions about stuff I can't get to work ;) 21:31
jnthn (I refer to Compiler.pir in src/Perl6/Compiler.pir btw)
That one contains a bunch of Rakudo bits that you won't need - the NQP equivalent file is probably much simpler.
PerlJam: Yes it's *way* simpler in NQP. 21:33
github.com/perl6/nqp-rx/blob/master...mpiler.pir
21:33 hirschnase left
PerlJam ah, I think that points me in a useful direction. 21:34
thanks.
jnthn diakopter: Saying "let's fork!" is simple. Making that lead to anything that is an overall win is far from that, and needs a lot of energy and resources. 21:36
KyleHa jnthn: Are you talking about software? 21:37
jnthn KyleHa: lol! 21:38
21:38 masak joined
jnthn KyleHa: I actually was this time... ;-) 21:38
PerlJam I know when I said to my wife "let's fork!", she always wanted to spoon afterwards ;> 21:39
TimToady then there are the husbands that get knifed afterwards... 21:40
diakopter or beforehand 21:44
jnthn Or during. 21:45
masak or just in general.
TimToady PerlJam: you should try "Let's spork!" and see what happens.
PerlJam We used the knife about 9 months later on the umbilical cord
diakopter jnthn: I wasn't making a comment as to whether I thought a fork was a good idea... but I was pointing out the level of fork aversion (and you pointed out one of the reasons)
jnthn can't quite bear to watch #parrot right now 21:47
PerlJam someone needs to use a knife to cut out some of the emotion and figure a better way to communicate
diakopter considers looking at it on perlgeek.de
masak jnthn: could you please summarize the situation? I'm coming in late.
diakopter oh. started off with llvm 21:48
jnthn masak: pmichaud++ wants a couple of new opcodes in Parrot that will make some very, very common operations we do both much shorter in PIR and a tad faster the boot. 21:49
masak nod.
jnthn It'll make code-gen massively easier and be a minor performance win.
masak I think I've read about those opcodes.
diakopter pir_eval?
jnthn allison is getting in the way, and showring a massive fail of understanding between binding and assignment along the way.
As well as proposing something that would create more problems we don't already have as a "solution" that would actually be completely useless for us. 21:50
masak ouch.
21:51 xp_prg left, __ash__ joined, PZt left 21:53 pnate2 joined 21:59 TSa left 22:06 pnate left
Juerd toons.gotblah.com/archive/geekandpo...-22:01.jpg 22:10
jnthn lol
masak ceci n'est pas une pipe.
pmichaud I totally cannot believe how much time I feel like I've wasted on talking about lvalue semantics 22:11
I totally cannot believe that allison had no clue how scalar assignment works in Perl (5)
TimToady we all have our blind spots from time to time 22:12
PerlJam being a dispassionate observer, I couldn't believe it either, but if you accept it, perhaps you can see where she is coming from?
pmichaud thanks, good perspective. I've certainly had mine.
jnthn pmichaud: Yes, it's silly. 22:13
And frustrating.
pmichaud PerlJam: I think I can see where she's coming from. What's bothersome is how long it's taken me to convince allison that there's a problem. 22:14
my comments (and others') have often been handwaved away with "you don't understand, we already support this"
jnthn The lack of understanding of assignment sematnics vs binding semantics is probably part of what the rest of the mis-understanding comes from.
PerlJam Pick some other, non-perl languages to illustrate the problem and perhaps the multiple examples will trigger whatever part of her brain that needs triggering.
pmichaud the python example was helpful
but I'm having trouble coming up with languages that don't have these particular semantics, at least somewhere 22:15
jnthn pmichaud: PIR? ;-)
PerlJam so maybe that's allison's problem. This is only a problem for perl and no other langauge that parrot will support.
(that's how she might see it)
jnthn pmichaud: btw, I'm getting on with the code types stuff. 22:16
pmichaud jnthn: even PIR has this semantic, if you leave PMCs
jnthn pmichaud: Yes, I know. I wsan't being entirely serious. :-)
22:21 lollan left 22:38 pnate joined, xabbu42 joined 22:45 lichtkind left
sjohnson jnthn: www.xkcd.com/627/ 22:50
22:51 pnate2 left 22:52 KyleHa left
masak phew. 28 days left. :) 22:53
zaslon lolmasakhazblogged! masak++ 'November 2 2009 -- fighting servers and giant squids': use.perl.org/~masak/journal/39833?from=rss 22:55
22:56 pnate2 joined 23:00 Whiteknight joined 23:01 PZt joined
jnthn pmichaud: For when you're back - I've put in the code to wrap subs in Perl 6 code objects. Regexes shouldn't be so hard to put back now. Let me know of any problems. 23:03
Also, the regression in 07-simple-multi-subs.t was what I feared. And it's also fixed. 23:07
pmichaud jnthn++ # yay, a bright spot in my afternoon 23:08
jnthn masak: Nice post. :-)
pmichaud: Happy I can provide one. 23:09
masak thanks. lots of gory details today.
jnthn: your new binder keeps finding new bugs in my code. :)
jnthn masak: Heh. The old binder was so fail.
masak so is my code. :/ 23:10
jnthn Well, it's an easy issue to fix.
23:11 pnate left
masak yes, luckily. 23:11
jnthn And happily, not too bad an error. :-)
masak indeed. short and to the point. 23:12
jnthn "I'm very sorry to report that you failed to pass a required named parameter. The missing named parameter is called 'projects-dir'. You can rectify this situation by passing it." 23:14
...nah, it can stay short and to the point. :-)
moritz_ you forgot to start with "Good $localtime Ladies and Gentlement" ;-)
masak jnthn: :)
now I'm going home to study carlins++' rssbot to see if I can use code from it to implement gist.github.com/189041 23:15
jnthn moritz_: Where we compute $localtime based on the current localtime?
;-)
moritz_ sure.
jnthn masak: wow, that's...beautiful... 23:16
masak jnthn: it's just an idea. :)
jnthn Yes, but if you can make it work... :-)
masak we'll see.
23:16 pnate joined
masak I'd like to have something like that. 23:16
anyway, sleep. 23:17
good night, #perl6.
see y'all tomorrow.
diakopter 'night
23:17 masak left 23:23 iblechbot left 23:29 pnate2 left 23:32 xinming joined 23:33 __ash__ left 23:43 pnate2 joined
japhb Wow, masak's IRC client idea really is beautiful. 23:47
jnthn japhb: Yeah, it'd make writing IRC clients like, so easy. 23:49
23:55 pnate left, Exodist joined 23:56 bpetering joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!