»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'perl6: say 3;' or rakudo:, niecza:, std:, or /msg camelia perl6: ... | irclog: irc.perl6.org | UTF-8 is our friend!
Set by sorear on 25 June 2013.
gtodd1 TuxCM: so here --> my@x=("1ab");for @x { s{^(\d+)} = sprintf "%3d:", $1; }; @x.say ; you want to format the digit in the list? 02:19
FROGGS pmichaud: about caching only a subset of calls... wouldn't the sanest approach be to only cache only some MMD candidates? 06:52
FROGGS s:2nd/only\s// 06:58
nowadays we can send a signal to a spawned (shell) process, right? 07:04
I'd like to add test for the REPL
tests*
lizmat: I managed to run spectests for all backends over night, gist.github.com/FROGGS/ac4fff2b2d2c815eacb3 07:07
lizmat: looks like parrot need some love still
lizmat good morning, FROGGS 07:08
was going to look at that today as well :-)
FROGGS good morning :o)
lizmat as well as the chdir() issues colomon found
FROGGS ahh, don't know about that one
m: multi foo(Int) is cached { say 'Int' }; multi foo(Str) { say 'Str' }; foo 1; foo 1; foo 'a'; foo 'a' 07:10
camelia rakudo-moar b3331e: OUTPUT«Cannot invoke object with invocation handler in this context␤ in sub foo at /tmp/zWM01_TzeB:1␤ in block <unit> at /tmp/zWM01_TzeB:1␤␤»
FROGGS :/
I feared that
lizmat that's odd, the wrap should only be applied to the first 07:12
FROGGS m: multi foo(Int) is cached { say 'Int' }; foo 1; foo 1;
camelia rakudo-moar b3331e: OUTPUT«Cannot invoke object with invocation handler in this context␤ in sub foo at /tmp/EpBFnacF6n:1␤ in block <unit> at /tmp/EpBFnacF6n:1␤␤»
lizmat that's worthy of a rakudobug
FROGGS m: sub foo(Int) is cached { say 'Int' }; foo 1; foo 1;
camelia rakudo-moar b3331e: OUTPUT«Int␤»
FROGGS yeah
FROGGS masaks that bug 07:13
RT #122899: Cannot apply trait 'is cached' on multi candidate 07:18
synopsebot Link: rt.perl.org/rt3//Public/Bug/Displa...?id=122899
FROGGS would be nice is synopsebot would fetch the title of the bug as well
lizmat m: proto foo(|) is cached { * }; multi foo(Int) { say 'Int' }; multi foo(Str) { say 'Str' }; foo 1; foo 1; foo 'a'; foo 'a' 07:22
camelia rakudo-moar b3331e: OUTPUT«Int␤Str␤»
lizmat putting the "is cached" on the proto seems to be a workaround 07:23
breakfast&
[TuxCM] gtodd1, yes 07:36
masak alohoj, #perl6 08:03
pmurias: irclog.perlgeek.de/perl6/2014-10-03#i_9453701 -- I'm keeping such a list locally. I may or may not be convinced of the merits of making it public. 08:06
pmurias: regardless, I'll be blogging about use cases and implementation choices.
laben ohayo #perl6 08:15
lizmat masak laben o/
laben: panda should be really fixed now
laben mh, it was already fixed for me, at least from Panda tests and compilation of Inline::Perl5 08:17
lizmat: i remember having posted here that
lizmat laben: well, you were the only one :-( 08:18
laben maybe because i'm the only one who does not bootstrap panda
lizmat but it's ok now, was a stupid thinko on my part, uncovered by FROGGS++
laben so, were you able to retain the new specced behaviour? 08:19
carlin heh, my perl6 script made bash explode, can't replicate it though :(
*** Error in `/bin/bash': double free or corruption (out): 0x0000000001bea600 ***
laben gosh, 4 bash updates in a week, damned shellshock
lizmat laben, almost: dir() still returns IO::Path objects 08:20
making that more up to spec, is going to be more involved
laben lizmat: sorry i did not test bootstrapping, it errors out indeed with older rakudo 08:23
lizmat no worries, we found the issue
carlin is anyone else getting test failures installing Inline::Perl5 through panda? 08:31
I'n getting
t/callables.t ............. 1/3 panic: MUTEX_LOCK (22) [op.c:697]
but it doesn't happen with a manual checkout :/
laben just tested, i don't get failures neither manually nor with panda 08:35
carlin: did you update rakudo before using panda?
carlin using rakudo HEAD, and a rebootsrapped panda 08:36
I'll blow away the install directory and try fresh
laben carlin: good idea
lizmat yuck: on parrot, a gather { loop {} } instead of a gather loop {} broke dir() 08:56
carlin strange test failure still happens with a fresh install, doesn't happen with rakudo 230233b3941d2 and panda 51fc726008 08:58
bisecting it down better than that is proving to be difficult as various rakudo commits break panda + various panda commits don't work with older rakudo
nine Where can I find docs about make? 08:59
carlin man make? :)
nine I mean the Perl 6 thing called make that I found in JSON::Tiny::Actions 09:00
like: make $/.values.[0].ast;
carlin doc.perl6.org/routine/make 09:01
nine That's....somewhat terse 09:02
in other words: I have no idea what it's trying to tell me
And how can this be the method from class Match? It looks more like a function call 09:03
lizmat S05:2963 might give you more info 09:04
synopsebot Link: perlcabal.org/syn/S05.html#line_2963
lizmat also, the course materials from last year's NQP workshop
nine Does my action object has to have a method for every token in the grammar? 09:14
jnthn nine: No, we only call action methods that exist. 09:15
jnthn nine: No method = no call. 09:15
Some tokens are too boring/primitive to really deserve an action method (typically, lexer-ish things) 09:16
nine Thanks all! Slowly making progress 09:38
laben mmh, the doc.perl6.org documentation seems a bit incomplete... 10:15
timotimo o/ 10:47
lizmat timotimo \o 10:48
pmurias masak: personally I'm interested in seeing the use cases list, I think putting it on github so people can add their own things they would like to do with macros makes sense 11:06
masak: Implementing the use cases in some of the existing macro systems could also prove a useful exercise to see what are the good/bad points of various approaches 11:08
nine Is SVG::Plot known to work? 11:27
timotimo i've used it like a month ago and it worked 11:31
if you don't use it properly, though, it can fail in mysterious ways 11:32
nine I've found out that SVG.serialize wants svg => $svg instead of just plain $svg and now I get a diagram but without any values.
dalek kudo/nom: 630a729 | (Elizabeth Mattijsen)++ | src/core/IO/Spec/ (2 files):
Add naive IO::Spec::Unix||Win32.basename

Mostly for internal .dir usage, as it doesn't handle edge cases well		 11:36
nine Mysterious indeed. It clearly seems to create SVG for the bars but they are missing in output. 11:46
Is there a variant of .perl that pretty prints? 11:51
masak pmurias: I will give it some thoughts. I can see pros and cons of sharing at this point. 11:55
thought*
pmurias: it will get easier once the way forward is clear and the design "congeals". 11:56
masak pmurias: in the meantime, please propose use cases ;) 11:57
nine timotimo: Seems like it's my old friend again...list interpolation. I really wonder if SVG::Plot still works for you on recent Rakudo 12:01
timotimo i shall find out whether i still have that piece of code.
nine timotimo method linkify returns a [] instead of a list which is why data and x-axis labels are missing from output while y-axis labels are there. 12:03
timotimo: replacing take $.linkify($k, $p) with take $p fixes it for me.
timotimo (and also build a fresh rakudo)
nine take |$.linkify($k, $t); also works 12:08
masak the | in that position always surprises me a little. 12:14
mostly because Perl 6 does not have a prefix:<|> -- it's only valid in siggies. 12:15
timotimo www.pehub.com/wp-content/uploads/2...anilla.jpg ? 12:16
nine I wonder what the real fix would be 12:19
dalek kudo/nom: ae11b53 | (Elizabeth Mattijsen)++ | src/core/IO/Path.pm:
Fix dir() on all backends

  - :test now works as intended
  - :absolute parameter (new spec) also works
  - :CWD parameter doesn't work correctly yet on all backend (todo)
I hope future backends will just work as moar :-)		 12:24
pmurias masak: what are the cons? 12:26
masak pmurias: grep for "A little retrospection" at en.wikiquote.org/wiki/Fred_Brooks 12:29
pmurias that would be a cons against developing the macro specification by committe 12:34
masak pmurias: my time to design this will be limited, and there is a whole lot of prior art and material to process and consider. I'm disinclined to add to that the burden of having to explain and defend early design decisions, time which could be spent on other things. 12:48
having said that, I will try to blog-early-blog-often about thoughts I have and decisions I make. 12:51
dalek kudo/nom: d3622d8 | (Brad Gilbert)++ | src/core/Instant.pm:
Make Instant.perl to produce eval-able code

Instant.new takes one positional argument, not a argument named x		 13:09
kudo/nom: 3af2500 | lizmat++ | src/core/Instant.pm:
Merge pull request #318 from b2gills/nom

Make Instant.perl to produce eval-able code
rurban I'm adding several parrot encoding and cclass fixes. FROGGS++ and usev6++ 13:12
masak rurban++
lizmat moritz: re Instant.pm, is there a reason why the only attribute is called "x" and all internal accesses use the $.x form ? 13:13
rurban++ indeed
masak lizmat: I didn't author the code, but -- analogy with x axis and its coordinate?
lizmat IO::Path.x means executable... so that might be confusing 13:14
masak is there a second question in there about using $.x in methods instead of $!x ? I consider that good, or at least consistent/defendable, style.
IO::Path and Instant are non-intersecting.
lizmat true, but generally browsing code you'd expect .x to mean executable first 13:15
masak I agree that it's a poor name, but not for that reason ;) 13:16
lizmat anyway, if you're subclassing Instant, it feels you would be subclassing methods 13:19
and those methods could use $.x
internally, I would prefer $!x for performance reasons
and I'm pretty sure jnthn is with me on this :-)
masak $!x and $.x for read accesses in OO code have two very different and equally valid intents. 13:20
the former says "I do not intend for the access to $!x to be virtual"
the latter says "the access to $!x is virtual, and can be overridden by subclasses"
lizmat yes, I'm quite aware of this :-) 13:21
masak I was pretty sure you were :)
lizmat cycling&
masak my point is simply that $.x in OO code is not automatically wrong, and should not be knee-jerk replaced.
lizmat that's why I asked moritz if he had a specific reason :-) 13:22
masak if you ask me, knowing when to do $!x and when to do $.x is really hard, as it involves anticipating what subclassers might do with the code. 13:22
which quickly ruins into YAGNI.
masak runs* 13:22
lizmat hence my inclination to always use $!foo in the core for performance, and wait until somebody needs it to change it :-) 13:24
really cycling&
masak I understand that sentiment, but I don't think it's that universal. 13:24
rurban who is usev6? 13:30
vendethiel o/, #perl6. 13:31
masak good univalence, vendethiel 13:32
vendethiel err. thanks, masak, I guess 13:34
masak .oO( note to self: mixing greetings and higher-order type theory confuses people )
vendethiel Kind of. Sorry, I'm really tired, so you'll need to wait for brain cells to connect 13:36
masak no worries :) 13:39
dj_goku timotimo: always fun readding the weekly blog posts! keep it up! 13:50
gtodd1 TuxCM: my @x=("1ab");for @x { s{^(\d+)} = sprintf "%3d :", "$1"; }; @x.say 13:51
m: my @x=("1ab");for @x { s{^(\d+)} = sprintf "%3d :", "$1"; }; @x.say
oops
camelia rakudo-moar ae11b5: OUTPUT« 0 :ab␤»
gtodd TuxCM: hmm so the ^(\d+) bit doesn't work ... with the RHS the as expected? 13:53
m: my @x=("1ab");for @x { s{^(\d+)} = sprintf "%3d :", $1; }; @x.say
camelia rakudo-moar ae11b5: OUTPUT«No such method 'item' for invocant of type 'NQPMu'␤ in method message at src/gen/m-CORE.setting:13332␤␤»
b2gills lizmat: IO::Spec::Win32 should split up paths on both \ and / ( both have worked since DOS 2 ) 14:05
vendethiel masak: where would "is parsed" (or the like) macros be in your macro proposal? (which part, that is) 14:15
vendethiel I'm scared of this one. I know that a lot of people think this is what "killed" CL, because reader macros encouraged a "dead island programming": only you can use stuff you've done, because there's so much other syntaxes going on 14:15
and, while I can see the argument - I don't think it's true, I don't think CL would have won without them - it seems people nowadays care a lot less about those kind of things 14:16
masak vendethiel: here's what I observe: "is parsed" is currently a kind of threshold that people pass in order to get more interesting parsing of the Perl 6 program. as they pass it, they give up all the nice things that come with AST macros.
vendethiel Just look at the operators in scala/haskell. They're definitely too much "sometimes", but we have the same power (actually, a greater one, only agda has a better parsing thingie :P)
masak vendethiel: I don't know exactly how yet, but I'm hoping we can make some use cases that currently need "is parsed" work with Qtrees instead. 14:17
this is partly what I mean with "have the cake and eat it".
vendethiel masak: I guess in a lot of cases, those could be slangs 14:18
masak it will be a slippery slope to slangs, more like. 14:18
vendethiel I'm just... Wondering. It's the "too much power" as usual 14:18
masak as in, debates will happen whether some particular code should've been in a slang, or whether 20 macros are fine :)
Perl 6 thrives on "too much power". 14:19
[Coke] .seen donaldh
yoleaux I saw donaldh 8 Sep 2014 09:40Z in #perl6: <donaldh> according to [Coke]++
[Coke] .ask donaldh if I can "donaldh/perl6-eclipse-plugin for dummies README" 14:20
yoleaux [Coke]: I'll pass your message to donaldh.
[Coke] .ask donaldh (that is, if I can -have- one, not make one) 14:20
yoleaux [Coke]: I'll pass your message to donaldh.
[Coke] has anyone used his perl6 plugin for eclipse ye?
t?
vendethiel masak: it might do, but that doesn't force me to like it everywhere :P 14:35
I know that I think differently on that one (compared to most here 14:36
)
vendethiel masak: (when doing haskell and stuff, I usually explicitly list all the operators I import, to be very sure) 14:43
dalek p: 390f7fa | Carlin++ | src/vm/moar/profiler/template.html:
avoid mixed-content issues in the profiler output

loading the css/js over https in an http page has no negative side-effects but using http in an https page will cause some browsers to not load the assets due to mixed-content restrictions		 14:44
p: 0672e0d | rurban++ | src/vm/moar/profiler/template.html:
Merge pull request #189 from carbin/brought-to-you-by-the-letter-s

avoid mixed-content issues in the profiler output
masak vendethiel: hrm. well, I'm all for listing imports explicitly. 14:49
vendethiel: maybe I didn't completely understand your "too much power" message, then.
vendethiel masak: I don't want people to be absolutely unable to read other people's code.
masak vendethiel: my main point is that the combined power various components in Perl 6 provides is enough rope to shoot yourself in the foot several times over. 14:50
but that doesn't mean... right, that, that people should write unmaintainable code.
vendethiel masak: that might be a stupid idea, though. It seems like the operator power given by Perl6 isn't abused... yet
masak I hope that the Perl 6 code I produce can stand as an example for people that the power inherent in Perl 6 can be used in such a way as to *both* be useful and readable. 14:51
I'm not speaking for anybody else, but I have a feeling many others on #perl6 are guided by a similar sentiment.
vendethiel masak: I see it like editors. The more people are given power, the more they tend to use it for themselves
Which is both normal and scary
masak readability (and all its associated attributes, such as maintainability and semantic clarity) feels like a central tenet in what I do when I produce code.
vendethiel masak: Right. I guess what I'm trying to say is "don't get too cozy" 14:53
masak if macros don't give you the power to do ridiculously inadvisable things to your program, I will consider my mission to have failed. :) 14:54
vendethiel hahaha.
masak but that's not the same as saying we shouldn't have sane defaults and guide people towards safety.
vendethiel Alright - I can agree with that
I just think we should label it "be cautious" as with the ability to add new operators 14:55
it's good to have it, but if you're pondering whether you should use it or not, don't.
masak that much I agree with.
vendethiel (that's the same thing I answer when people ask me if they should use eval "if you're wondering, then don't")
masak but that's not specific to macros in any sense.
vendethiel not even to macros, just to parsed macros.
vendethiel Like, you can go crazy with your classes and be java-ey with pseudo-interfaces and 500 classes for a fizzbuzz, but I'll still be able to "read" your code. I'll know what a specific chunk does 14:56
masak in the choice between a lexical variable or a new class, all other things being equal, I will go with the lexical variable, because it's simpler.
vendethiel (btw, I'm very happy that we have tighter/looser rather than "99" like in haskell0
masak *nod*
I guess what you say comes down to the following: there will be some macros that have a very local, predictable effect on the code. and other macros won't. we prefer the former kind, for the benefit of the reader's sanity. 14:57
[TuxCM] gtodd, why does the $1 have to be quoted???
m: my @x=("1ab");for @x { s{^(\d+)} = sprintf "%3d :", "$1"; }; @x.say 14:58
camelia rakudo-moar 3af250: OUTPUT« 0 :ab␤»
[TuxCM] m: my @x=("1ab");for @x { s{^(\d+)} = sprintf "%3d :", $1; }; @x.say
camelia rakudo-moar 3af250: OUTPUT«No such method 'item' for invocant of type 'NQPMu'␤ in method message at src/gen/m-CORE.setting:13332␤␤»
vendethiel masak: yeah. same as with hygiene, uh?
masak submits rakudobug
[TuxCM] THAT is what I was wondering about
masak vendethiel: yes.
vendethiel masak: I hope you'll find time to read "50 years of lisp". It personally melted my brain :-) 14:59
masak vendethiel: bumping its priority as you've now mentioned it twice. 15:00
vendethiel wow, I almost feel smart now ;)
(the whole book isn't available freely yet, though... But sublexical scope, anaphoric macros, pandoric macros and the others have gotten me wondering) 15:01
masak m: for my @x = "1ab" { s{^(\d+)} = sprintf "%3d :", Nil } 15:02
camelia rakudo-moar 3af250: OUTPUT«No such method 'item' for invocant of type 'NQPMu'␤ in method message at src/gen/m-CORE.setting:13332␤␤»
liztormato TuxCM: $1 is a match object. The "" stringify 15:03
masak m: $_ = "1ab"; s{^(\d+)} = sprintf "%3d :", "$1"; .say
m: $_ = "1ab"; s{^(\d+)} = sprintf "%3d :", $1; .say
liztormato You could also $1.Str 15:04
camelia rakudo-moar 3af250: OUTPUT«use of uninitialized value of type Any in string context in block <unit> at /tmp/Ct_Zoj4ABV:1␤␤ 0 :ab␤» 15:05
rakudo-moar 3af250: OUTPUT«No such method 'Int' for invocant of type 'Any'␤␤»
masak yes, that works locally.
m: $_ = "1ab"; s{^(\d+)} = sprintf "%3d :", $1.Str; .say
camelia rakudo-moar 3af250: OUTPUT«use of uninitialized value of type Any in string context in block <unit> at /tmp/_m6KcgPksb:1␤␤ 0 :ab␤»
masak hm, I'm not getting those uninit warnings locally in the REPL.
liztormato: but why in the world would I need to stringify in this case? 15:06
oh!
$1 !
m: $_ = "1ab"; s{^(\d+)} = sprintf "%3d :", $0; .say
camelia rakudo-moar 3af250: OUTPUT« 1 :ab␤»
masak :)
I think the real bug is that sprintf reacts badly to a Nil.
liztormato Yeah. It was for TuxCM
masak m: sprintf "%d", Nil 15:07
camelia rakudo-moar 3af250: OUTPUT«No such method 'item' for invocant of type 'NQPMu'␤ in method message at src/gen/m-CORE.setting:13332␤␤»
masak that's LTA.
masak submits that
m: sprintf "%s", Nil
camelia rakudo-moar 3af250: OUTPUT«Too many directives: found 1, but no arguments after the format string␤␤»
masak oh...
right, so the problem isn't the Nil as such.
but rather that there's nothing to populate the %d with. 15:08
timotimo liztormato: wouldn't ~$1 do the same as $1.Str and "$1"? 15:09
vendethiel should.
liztormato Yes
masak he's *passing it to sprintf* 15:12
why does he need to cast it at all!?!?
also, the (p5-ism) problem that made that code not work is that it was $1, not $0 -- and he had only one numbered capture group. 15:13
vendethiel
.oO( let's forbid $1! )
masak m: sprintf "%d" 15:17
camelia rakudo-moar 3af250: OUTPUT«No such method 'item' for invocant of type 'NQPMu'␤ in method message at src/gen/m-CORE.setting:13332␤␤»
masak should give the same error as
m: sprintf "%s"
camelia rakudo-moar 3af250: OUTPUT«Too many directives: found 1, but no arguments after the format string␤␤»
bartolin rurban: I'm usev6 on github. I was afk for a while.
liztormato Continuing cycling& 15:31
masak .oO( are the bikes really tiny? the agile methodology favors small cycles! ) 15:37
timotimo m) 15:38
masak vendethiel: just thought of an example. inheritance between classes. has been used in many cases to great effect -- in some domains more clearly a benefit than in others. 15:41
vendethiel: and yet, every time inheritance is used, a little bit of negative readability is introduced, simply by the complete understanding of the system now being spread across more than one class.
masak this is "essential negative readability", in the sense that the physical disconnect between base class and deriving class is also what makes inheritance useful in the first place. 15:42
TimToady now in Maria Alm, Austria 15:43
masak the disconnect can be mitigated by IDE tools, such as "jump to definition".
TimToady s/in/exhausted in/
masak TimToady: welcome to Europe! 15:44
nine TimToady: that's where my father grew up :) 15:46
rurban Oh, Maria Alm is beautiful! 15:48
mst masak: paul graham's On Lisp is excellent as well 15:53
masak mst: and free. so I might start with that one, while the other is being delivered. :) 15:55
mst masak: hence mentioning it :) 15:58
it's also well worth reading about fexprs and operative functions at some point
though those are more interesting in terms of semantic-ish macros rather than syntactic-ish ones
rurban bartolin: can you please recheck rakudo with latest parrot master on a bsd with a non-utf8 locale 16:04
bartolin rurban: yes, will do that 16:05
rurban worked ok for me, but I have no bsd's right now 16:10
[TuxCM] Ouch: if $foo ~~ s{^ "x"} = "" { 16:12
bartolin I'm testing on NetBSD right now. tomorrow I could conveniently test on my daily build on FreeBSD. would that suffice? 16:13
[TuxCM] does not enter the block, as the replacement is false. I expected it to enter the block because the substituation succeeded
rurban sure. 16:16
pmurias masak: from the discussion I'm feeling we are misunderstanding each other ;) What I feel would be usefull if people helped create is something like: gist.github.com/pmurias/46e8a79a1e1d47822dda 16:24
mst pmurias: second one: Test::Simpler by Damian (of course) 16:27
pmurias: third one: not a macro, but Log::Contextual
(more p5 prior art for idea theft purposes) 16:28
(also beware 'optimised out', often you just want to make it really really fast but be able to turn it back on by poking your daemon or something)
masak pmurias: your biological and technological distinctiveness has been added to my own. thank you. :) 16:32
and no, I don't think we are misunderstanding each other. 16:33
I just prefer to "own" some data at this part of the process, is all. 16:34
bartolin rurban: I build latest rakudo with latest parrot master and the two non-ASCII tests from S19-command-line/dash-e.t fail with non-utf8 locale. otherwise both tests run fine now. (that matches behaviour on linux) 16:43
pmurias mst: the third one was taken from a masak++ talk, but I'm not sure if that use case is actually beneficial 16:44
mst pmurias: Log::Contextual being able to only call expensive stuff when that log level is on has been a huge advantage 16:48
mst I use it freaking everywhere 16:48
vendethiel pmurias: for me, those are the "macros generating code" kind of use case 16:50
vendethiel pmurias: I still have other use-cases in mind, i.e. I want to build a "match" statement with macros 16:52
pmurias: I also want a RAII-like `given` version. `given open('file') { .say("foo") } # here the file is closed` 16:53
vendethiel (I have thousands of stuff like that I want to do, like generating coumpound operators or other stuff, but a lot of them do not involve code generationg) 16:54
lizmat is done cycling 18:36
masak vendethiel: another loose thought about the "too much power" stuff: 18:37
masak maybe, just like we tend to favor side-effect-free routines when we can but realize that's not always possible or even desirable, so we'll end up preferring macros with a simple/predictable local mapping from inputs to outputs without messing with the environment 18:38
mst r5rs does this 18:39
in that there are two forms for macro declaration, one fully hygeinic, one less so
masak ...but we also acknowledge that sometimes messing with the environment (as little as we can get away with) is precisely the intent
masak .oO( these are your father's parentheses. elegant weapons -- for a more... civilized age. careful! some of them are very sharp ) 18:42
example of a macro with a side effect: if you use it more than three times in the same compunit, it replaces the entire mainline with an infinite loop that prints "PHP 4EVER!!!" and traps ^C 18:45
masak mst: though looking at Log::Contextual, it seems that it avoids superfluous work through lambdas, not through macro/sourcefilter magic. 18:49
but yes, it's still a good example of when the desired semantics is needed, I guess.
mst masak: yes, I specifically said "not a macro, but Log::Contextual" for that reason :D 18:50
masak ah, yes. missed that line. 18:54
masak "thunk it", i.e. "make it a lambda without it needing braces" is one of the acheived goals in Rakudo macros already. 18:56
lizmat m: say IO::Spec::Win32.split("C:a/b/c/d") # b2gills: it already does so 18:57
camelia rakudo-moar 3af250: OUTPUT«"volume" => "C:" "dirname" => "a/b/c" "basename" => "d" "directory" => "a/b/c"␤»
b2gills m: say IO::Spec::Win32.basename("C:a/b/c/d") 18:58
camelia rakudo-moar 3af250: OUTPUT«C:a/b/c/d␤»
[TuxCM] lizmat, even if d is a directory? 18:58
lizmat b2gills: ah, good point
[TuxCM] i'd expect it to have filename => d
lizmat [TuxCM]: IO::Spec does not inspect the file system, it is like P5's File::Spec 19:02
dalek kudo/nom: 9c807f2 | (Elizabeth Mattijsen)++ | src/core/IO/Spec/Win32.pm:
Fix IO::Spec::Win32.basename

  b2gills++ pointed out that slashes were ok too, since MS-DOS 2		 19:06
lizmat $ 6 'say IO::Spec::Win32.basename("C:a/b/c/d")'
d
lizmat m: say IO::Spec::Win32.basename("C:a\\b\\c\\d") 19:06
camelia rakudo-moar 3af250: OUTPUT«d␤»
psch hi #perl6 o/ 19:29
masak \o 19:30
psch do we want multiple --target's?
RT #73790 made me also add "a multiple $flag are not allowed"
synopsebot Link: rt.perl.org/rt3//Public/Bug/Displa...l?id=73790
psch masak o/
currently that's disallowing target, optimize, encoding, output 19:31
i'm unsure if target belongs on that list
jnthn No, any latter targets are ignored at present, I guess 19:33
I mean, it just says "stop at this stage"
So only makes sense to have it once.
psch jnthn: right, so disallowing is What It Means. i'll push and PR in a bit then 19:35
although there's one other thing i'm unsure about. the code i have checks for multiple flags in HLL::Compiler::command_line. HLL::CommandLine::Parser makes arrays when an option was encountered more than once, and &command_line acts on them. 19:38
i'm not sure if the parser should know that it should treat -e specifically different, although i'm leaning towards "no, because others might want something else allowed" 19:39
vendethiel codon.com/refactoring-ruby-with-monads <- actually good monad tutorial
masak: wow, I saw your initial message instantly, but then you stopped pinging me 19:40
there's a huge trend in the CL community saying "unhygienic macros are okay cause we a lisp-2", which i strongly disagree with
(and that applies to p6's $@&%) 19:41
psch oh duh, my argument for the placement of the check is actually not valid. it's still hard-coded in HLL... 19:42
masak vendethiel: I don't know the details, but that sounds like something I'd disagree with as well. maybe even strongly. 19:46
vendethiel masak: it's just that "we're only introducing values/functions" 19:47
but sometimes, the lisp-2 magic breaks down :) (ie exports/imports)
masak *nod*
masak 'night, #perl6 19:54
lizmat gnight masak 19:55
psch g'nite masak
vendethiel g'night :) 20:00
FROGGS $ perl6-p 20:16
> 42
Null PMC access in get_string()
looks like I'm not yet done with it :/
lizmat FROGGS++ for persevering 20:18
lizmat m: sub a { say CALLER::<$*CWD> }; say $*CWD; a # should this work or not ? 20:55
camelia rakudo-moar 9c807f: OUTPUT«"/home/p6eval".IO␤(Any)␤»
lizmat I would have expected the Any to be an .IO as well 20:56
jnthn m: sub a { say DYNAMIC::<$*CWD> }; say $*CWD; a
camelia rakudo-moar 9c807f: OUTPUT«"/home/p6eval".IO␤(Any)␤»
jnthn Oh...
But there's no lexical $*CWD, iirc 20:57
It comes from PROCESS
lizmat uyp
yup rather
jnthn So yeah, those pseudo-package "look in a scope" thingies ain't going to find it, I guess.
lizmat but PseudoStash is doing a nqp::getlexreldyn afaics 20:57
jnthn Sure 20:58
Which matches what we're seeing
The GLOBAL and PROCESS fallback things are Perl 6 level
lizmat m: sub a { say CALLER::<$*CWD> // PROCESS::<$*CWD> }; say $*CWD; a # should this work or not ? 20:58
jnthn See sub DYNAMIC
camelia rakudo-moar 9c807f: OUTPUT«"/home/p6eval".IO␤(Any)␤»
lizmat m: sub a { say CALLER::<$*CWD> // PROCESS::<$CWD> }; say $*CWD; a # should this work or not ? 20:59
camelia rakudo-moar 9c807f: OUTPUT«"/home/p6eval".IO␤"/home/p6eval".IO␤»
jnthn The * is removed before looking in GLOBAL or PROCESS.
lizmat yeah...
jnthn I guess it's arguable that a pseudo-package lookup involving a * twigil should also look at GLOBAL and PROCESS 21:00
Well, for CALLER and DYNAMIC, anyway...
Something makes me hesitate a little on it, though... 21:01
Not sure what.
:)
Maybe just that dealing with packages or pseudo-packages is generally non-mangly... 21:02
lizmat yeah...
lizmat jnthn: I think we have a chicken / egg problem with visitdir (from the old S32/IO) and chdir (from the new S32/IO) 21:44
chdir(/abspath) is no problem
chdir( /abspath, my $*CWD ) is not a problem either 21:45
chdir( relpath, my $*CWD ) *is* a problem
as it needs the *old* value of $CWD to work from
by the "my $*CWD" is already set to Any by that time 21:46
jnthn lizmat: Well, can you do something with CALLER::CALLER, and fall back to looking in PROCESS? 21:49
Oh but...
lizmat m: say $*CWD; { my $*CWD = $*CWD; say $*CWD }; say $*CWD # the problem in a nutshell
camelia rakudo-moar 9c807f: OUTPUT«"/home/p6eval".IO␤(Any)␤"/home/p6eval".IO␤»
jnthn Hm, why are we passing $*CWD?
lizmat jnthn: to indicate which dynamic to set 21:50
jnthn That's a...weird API design...
lizmat it combines chdir() with the specced visitidir
however, the same problem would exist with: 21:51
jnthn Wasn't visitdir the one that takes a closure to run under a different $*CWD?
lizmat my $*CWD = chdir("foo")
multi sub visitdir(Str:D)
multi sub visitdir(IO::Path:D)
was the old spec 21:52
jnthn oh...
lizmat slushy, I know
jnthn ponders if temp $*CWD works out any better... 21:53
lizmat nope, same problem 21:53
well, what I tried with temp
jnthn It does strike me was rather odd that we are calling chdir *and* updating $*CWD ourselves...
lizmat chdir is really nothing *but* updating $*CWD in the new scheme of things 21:54
which is basically the way the JVM does it
jnthn Me naive expcetation would be that chdir updates $*CWD
lizmat yes, it does
jnthn And since it's contextual then we've no need to pass it
lizmat but what if you want to update it just in a scope ?
lizmat { my $*SPEC = chdir() } 21:55
jnthn And then we have a visitdir 'foo', { ... };
lizmat that's not how visitdir was specced
jnthn Which calls the closure with an updated $*CWD
I know, I'm wondering if it should be that way...
I know Panda has an "indir" or similar for doing exactly this 21:56
lizmat yup, it has...
jnthn I suspect everyone is going to re-invent that...
lizmat how about:
chdir(foo) just changes $*CWD 21:57
chdir(foo, { code })
only changes it inside the code block and executes it ?
jnthn I like the idea of providing both of them, I'm just not sure the second one should be called chdir
BenGoldberg letdir, tempdir, temporarily-dir, maybe? 22:02
jnthn Panda's indir ain't so bad... 22:03
lizmat m: my $*FOO = 42; { my $*FOO = $*FOO.Str; say $*FOO } # expected "42" 22:18
camelia rakudo-moar 9c807f: OUTPUT«use of uninitialized value $*FOO of type Any in string context in block <unit> at /tmp/LGhEbNXreI:1␤␤␤»
lizmat ah, I guess it needs to be temp 22:19
m: my $*FOO = 42; { temp $*FOO = $*FOO.Str; say $*FOO } # expected "42"
camelia rakudo-moar 9c807f: OUTPUT«42␤»
lizmat m: my $*FOO = 42; { temp $*FOO = $*FOO + 1; say $*FOO }
camelia rakudo-moar 9c807f: OUTPUT«43␤»
lizmat m: my $*FOO = 42; { temp $*FOO = $*FOO + 1; say $*FOO } ; say $*FOO
camelia rakudo-moar 9c807f: OUTPUT«43␤42␤»
dalek kudo-star-daily: ffef5fb | coke++ | log/MoarVM-version.log:
today (automated commit)
 22:36
rl6-roast-data: a73c09e | coke++ | / (4 files):
today (automated commit)
lizmat jnthn: it appears that temp doesn't work in the core... 22:38
going to sleep on it
good night, #perl6!
jnthn 'night
timotimo gnite liz 22:42
[Coke] f 23:19
~>

Powered by Cro and the Raku® Programming Language.

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

Thank you!