»ö« 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.
dalek p: 9a7f358 | jnthn++ | src/ (3 files):
A couple of SC write barrier related tweaks.
 00:09
p: f1c2da5 | jnthn++ | src/vm/moar/stage0/ (11 files):
Update MoarVM stage0.
kudo/moar-support: e3f6f22 | jnthn++ | src/Perl6/Metamodel/BOOTSTRAP.nqp:
Implement object -> native parameter binding.
 00:12
dalek kudo-star-daily: bc0118d | coke++ | log/ (5 files):
today (automated commit)
 00:17
rl6-roast-data: 1286d0a | coke++ | / (5 files):
today (automated commit)
rl6-roast-data: 52ef05a | coke++ | / (3 files):
today (automated commit)
dalek kudo/moar-support: 9462664 | jnthn++ | src/core/terms.pm:
Enable a little of the @INC handling.
 00:36
lue moritz: just ooc, as I'm preparing to start writing the P6-based syn generation code, do we really need an index of C formatting codes? :) 00:56
dalek kudo/moar-support: ecde72d | jnthn++ | src/Perl6/Metamodel/BOOTSTRAP.nqp:
Implement sub-signature binding.
 01:08
jnthn sleep; will fix more tomorrow :) 01:31
lue ♞ jnthn o/ 01:34
adu hi all 01:40
lue hi adu o/ as you can see, it's the quiet hours of the channel at the moment :) 01:46
adu :)
japhb preflex: tell lizmat re: irclog.perlgeek.de/perl6/2013-12-17#i_8013218 there are unfortunately strong use cases for at least the options: 1) current behavior, options parsing stops at first non-option, 2) options anywhere are equivalent, order doesn't matter, or 3) exact order matters, options are effectively positional. Huffmanizing or otherwise syntactically relieving those cases is an interesting exercise. 01:51
preflex Consider it noted.
japhb preflex: tell lizmat I've considered a hook of some sort to swap the parser provided by MAIN_HELPER right now, so people could write modules that change that option parsing behavior, but it's not clear to me how to do it without forcing people to *completely* replicate the sometimes fiddly logic (and support val() in the future transparently). 01:53
preflex Consider it noted.
dalek kudo/moar-support: bba075d | moritz++ | t (2 files):
Fix testing running, [Coke]++
 02:29
kudo/moar-support: 2fb5e54 | moritz++ | tools/build/Makefile-Moar.in:
supply missing m-runner-default target (untested)
 02:33
TimToady regreets the world from Seattle 05:27
lue TimToady: that sentence is dangerously close to "regrets the world from Seattle" :) 05:44
TimToady most of the world from Seattle is regrettable :) 05:45
but then much of Seattle is also regrettable, so it all balances out...
at least it's a fairly clean city, being washed continually as it is 05:46
lue
.oO("the world from Seattle" has two interpretations too: "the world as seen from the POV of Seattle" and "the part of the world contributed by Seattle".)
TimToady As long as we're clear that Seattle's Best Coffee is not necessarily Seattle's best coffee... 05:47
I've always found it hilarious that all these northern climes claim to have the best coffee, when none of it comes from there 05:48
lue I've always wondered why Hawai'i's the only state can grow coffee. Don't we have thingys that can emulate favorable climates for the stupid plants? 05:49
TimToady: Perhaps it's the coffee grinders that make the coffee? :) 05:50
TimToady just like organ grinders make organs? 05:51
lue
.oO(Organ beans only grow in places with high divinity, and are helped with the addition of holy water to their environment.)
 05:52
TimToady is that why organic beans are more expensive?
lue Heh, I just got the idea to see if rakudo optimized s/A/A/ and the like (replace occurrence of something with itself). I think the answer's no. 05:56
r: my $a = "☃"; for ^1000 { $a ~~ s/\☃/☄/; $a = "☃" }; say now - BEGIN now; 05:57
camelia rakudo-jvm 413650: OUTPUT«3.23␤»
..rakudo-parrot 413650: OUTPUT«4.1138715␤»
lue r: my $a = "☃"; for ^1000 { $a ~~ s/\☃/☃/; $a = "☃" }; say now - BEGIN now;
camelia rakudo-jvm 413650: OUTPUT«2.984␤»
..rakudo-parrot 413650: OUTPUT«4.07494964␤»
TimToady perl5 is at least smart enough to know when it's replacing something of the same length, and doesn't do any copying 05:58
but then, p5 strings are considered mutable 05:59
lue I realize that optimization gets really difficult the second you move beyond literal chars. I imagine s:g/<alpha>**6/search/ in a many-KiB text file would appreciate that sort of thing though. 06:01
TimToady it's probably not worth optimizing s/A/A/ since nobody in their right mind writes that 06:05
lue TimToady: I wonder if that sort of literals optimization wouldn't be useful for tr/// though. 06:08
timotimo so, what do i hack on during my train ride today? jvm boot interop perhaps? 09:18
moritz +1 09:19
jnthn morning o/ 09:43
timotimo morning jnthn!
moritz: i'm hoping for the magical properties of trains that seem to make everybody properly finish whatever they start when they're on one 09:44
jnthn timotimo: I think the Trans-Sib may have this magical property, 'cus you get 7 days to properly finish :P 09:45
timotimo :D
dalek p: 4165a18 | jnthn++ | src/vm/moar/QAST/QASTOperationsMAST.nqp:
Fix CONTROL handler compilation on Moar.
 10:16
timotimo waves from a train 12:04
jnthn
.oO( Surfing teachers train from a wave... )
 12:05
timotimo they also sometimes wave from a wave
diakopter and train from a train 12:06
timotimo ... i have connectivity in this tunnel?! O_o 12:18
FROGGS is in a tunnel too 12:22
dalek kudo/moar-support: cc3eb74 | (Tobias Leich)++ | tools/build/ (3 files):
rename moar runner generator
 12:31
dalek kudo/moar-support: 64874c1 | (Tobias Leich)++ | tools/build/Makefile-Moar.in:
add rule m-runner-default-install
 12:39
dalek kudo/moar-support: 1e44676 | jnthn++ | src/vm/moar/ops/ (2 files):
Catch up with Moar API change.
 12:57
kudo/moar-support: 01a9052 | jnthn++ | src/vm/moar/ops/perl6_ops.c:
Fix an apparent thinko.
kudo/moar-support: 982e740 | jnthn++ | src/ (4 files):
Implement p6decontrv.
kudo/moar-support: 0115300 | jnthn++ | src/vm/moar/Perl6/Ops.nqp:
Fix p6store code-gen thinko.
timotimo i'm so glad i don't have to rebuild all of rakudo when i change the BootJavaInterop code ... 13:06
FROGGS yeah 13:08
timotimo that doesn't mean i can get it to run properly, though :P 13:09
FROGGS *g*
dalek kudo/moar-support: b0962df | (Tobias Leich)++ | tools/build/Makefile-Moar.in:
fix perl6-m runner
 13:11
timotimo mhhh net connection is getting pretty flaky now :\ 13:23
and i'm not nearing the fix any
dalek kudo/moar-support: df347e3 | (Tobias Leich)++ | t/harness:
prepare for running fudged tests
 13:32
timotimo not sure what's going on; i get a NoSuchElement exception from calling peek, which calls the poll method on the channel object (in channel.t) 13:37
~ 13:45
timotimo do i have to box aninteger into an Integer in jvm bytecode? :\ 13:49
timotimo maybe there's a candidate for a native integer 13:51
timotimo yup 13:53
wait ... could this be a legit failure i'm seeing? 13:56
NoSuchElementException raised when a LinkedBlockingQueue is empty and you poll from it?
nah, it's supposed to return null 13:57
timotimo weird, though, it says "going to call element", but that's not what i'm trying to call? i'm trying to call poll?! 14:02
ooooh crud! :D 14:04
what a dumb mistake ;)
i'm trying to identify the methods by desc, but the desc doesn't contain the method name, just the signature
jnthn away for a bit & 14:05
timotimo Cannot receive a message on a closed channel in throw (gen/jvm/CORE.setting) 14:07
moritz runs m-test for the first in rakudo 14:09
timotimo strange. it calls new, add, add, poll, take and then says "cannot receive a message on a closed channel" ... ?! 14:17
the poll is from tkhe peek to check if closed is true
timotimo oh well. i got at least one step closer to the working dispatcher generator 14:22
and now i have lots of debug code to boot!
dalek kudo/moar-support: 08811f8 | moritz++ | tools/build/Makefile-Moar.in:
HARNESS_WITH_FUDGE always needs --moar
 14:49
PerlJam wonders when "smashing cup" day was ... 15:14
PerlJam Ah, Jul 18 15:15
sjn heh... someone should make some "smashing cups" as perl6 giveaways/swag 15:19
diakopter mugs
sjn "What a smashing mug you have there" 15:20
moritz .u BEER MUG
enounicodebot
moritz exists, as U+1F37A 15:20
tadzik more useful than FRONT FACING BABY CHICK 15:29
jnthn back 15:33
japhb
.oO( "Back where we started, here we go round again" )
 16:00
diakopter jnthn: you mean you're a back facing baby chick? 16:04
jnthn diakopter: That's me :P
japhb MAIN parser replacement syntax idea: If you want to override the parsing for MAIN multis, add an explicit proto MAIN with a trait on it, like so: 'proto MAIN(|) is options-parsed(&subcommand) {*}', where &subcommand is a (possibly imported) options parser routine. 16:06
This proto MAIN trait is noticed by MAIN_HELPER and used instead of its default.
Thoughts? (Aside from bikeshedding the trait name, which I expect a fair amount of. :-) 16:07
diakopter option-sparsed
japhb Basically, does this have the right amount of syntactic weight for what it does, and is the override in the right place? 16:08
My concern about the latter is for building things like busybox, where it may need to emulate lots of different options parsing styles depending on the name it was called with. Though perhaps that's as good a reason as any to collect all that parsing crazy in one place. 16:10
japhb The options-parsed trait could also take a general object or class (as opposed to just a Callable), in which case it could call .parse-options(...) on it. 16:30
dalek kudo/moar-support: 94fd14b | (Tobias Leich)++ | t/fudgeandrun:
prepare for running fudged tests
 17:23
timotimo Stage parse : 4812.141 / Stage jast : 6309.581 17:32
oh my!
tadzik wow wow 17:34
is that microseconds? :)
jnthn o.O 17:36
timotimo that happens when you suspend during those stages :P 17:44
diakopter timotimo: run it again except change the clock back during 17:53
timotimo :D 17:55
diakopter "STOP IT. Time traveling disturbs the AST generation process." 17:56
lue hello world o/
timotimo hellue
timotimo so, my jvm dispatcher codegen is better now 17:56
but it still runs into trouble :\
timotimo wat. 18:14
i poll an int in the peek method, then i receive a CHANNEL_CLOSE in the receive method?!?
ah, of course 18:15
wow, i'm an idiot, aren't i
diakopter I DIDN'T SAY IT 18:17
timotimo i re-wrote a .'method/peek/.../' to be .poll instead
that's clever
sjn hey, grats to woolfy and lizmat for the white camel award! :) 18:40
blogs.perl.org/users/brian_d_foy/20...amels.html
dalek p/jvm_interop_dispatchers2: efc6d06 | (Timo Paulssen)++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/BootJavaInterop.java:
first working version of the arity-based dispatcher in java-land.
 18:48
p/jvm_interop_dispatchers2: 9db2ddb | (Timo Paulssen)++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/BootJavaInterop.java:
try to make this work. fails spectests.
p/jvm_interop_dispatchers2: 2aecd58 | (Timo Paulssen)++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/BootJavaInterop.java:
fix thinko in the hash storing methods

the desc in this part doesn't contain the actual method name. oops!
kudo/jvm_interop_dispatchers: 68faa9d | (Timo Paulssen)++ | src/vm/jvm/core/ (2 files):
use prettier names for java interop methods
 18:49
timotimo i'm running spectests now 18:51
(although it would be enough to just run S17-concurrency, i guess)
it'll probably fail again due to "no subtests run" >_<
timotimo jnthn: out of curiosity, and not because i want to implement it tomorrow already, what ops do i use to inspect the given arguments for their types? 18:55
and would i limit myself to checking Integer/String/Double/arrays of same? 18:56
well, for a start probably.
diakopter timotimo: istype ?
timotimo hm, yes, that kinda makes sense 18:57
timotimo i wonder how i get to the types that i have to pass to istype to check for the proper builtins 18:57
dalek p/jvm_interop_dispatchers2: ba639c6 | (Timo Paulssen)++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/BootJavaInterop.java:
remove lots of debug output.
 19:00
timotimo hm, the tap test seems to hang 19:05
timotimo same for the Thread test, is that known? 19:06
jnthn Not to me...I guess see the last daily run. 19:11
jnthn timotimo: Type wise, there's a couple of cases: "primitive" types (int/double, etc) where we'd want to look for the relevant Perl 6 type being passed (Int, Num, ...) 19:16
timotimo: Then there's Java object types which are boxed up
timotimo: And for those you want to unbox them and use the instanceof JVM ops or something like that I guess.
timotimo unbox them with SMOToJavaObject? 19:24
jnthn Something like that 19:25
Or I thin there's a javaWrap/unwrap or so...
timotimo mhm
ah yes, unboxClass 19:26
that'll be a crapton of work i fear
something got wrong with the winner syntax 19:40
moritz woolfy++ lizmat 19:42
timotimo github.com/perl6/roast/blob/master...nner.t#L30 - this line is certainly wrong
moritz woolfy++ lizmat++ # congratulations to the white camel award!
timotimo i *think* to make it correct, i'd just have to change the ) to a }, remove the , from the line before? 19:43
moritz also congratulations to the other two winners, whom I don't know yet 19:44
moritz perladvent.org/2013/2013-12-18.html that sounds nice 19:46
arnsholt Congrats, indeed. I was amused by ballot-stuffing to *not* get a prize =) 19:48
timotimo j: my $test; winner $test { more * => { say "test" }; done * => { say "test2" } }
camelia rakudo-jvm 413650: OUTPUT«===SORRY!=== Error while compiling /tmp/cm1SupKUIL␤Missing block␤at /tmp/cm1SupKUIL:1␤------> winner $test { more * => { say "test" }⏏; done * => { say "test2" } }␤ expecting any of:␤ postfix␤ …»
timotimo oh of course 19:49
j: my $test; winner $test { more * -> { say "test" }; done * -> { say "test2" } }
camelia rakudo-jvm 413650: OUTPUT«Got a Any, but expected a Channel or Promise.␤ in block at gen/jvm/CORE.setting:18028␤ in block at gen/jvm/CORE.setting:7303␤ in block at gen/jvm/CORE.setting:7167␤ in method gimme at gen/jvm/CORE.setting:7585␤ in sub WINNER at gen/jvm/COR…»
timotimo great
lue moritz: Interesting module. I just wish we had a slurp_utf8 method in Perl 6, that sounds like the best thing ever! 19:53
masak blog.plover.com/prog/Moonpig.html is full of interesting stuff.
mjd++ 19:54
I especially enjoyed the "main points" of date-and-time handling.
they deeply remind me of the "main points" of strings-vs-bufs
arnsholt Yeah, I liked the Moonpig presentation 19:55
Or, reading it that is
masak me too. 19:56
but the post goes more into detail than the talk notes.
arnsholt Oooh, long post. Not sure how I missed that one 19:57
timotimo i didn't follow the changes, what's the new syntax for Publish.for(1..4)?
Supply.for(1..5)?
j: Supply.for(1..5); 19:58
camelia ( no output )
timotimo r: (do "hello").WHAT.say 20:00
camelia rakudo-parrot 413650, rakudo-jvm 413650: OUTPUT«(Str)␤»
moritz lue: perl 6's slurp sub and method assume UTF-8 by default 20:02
lue :) I know, I was slyly pointing out that Perl 6 comes with the functionality already included.
timotimo there we go. much better.
dalek ast: 8842267 | (Timo Paulssen)++ | S17-concurrency/winner.t:
bring winner.t up to latest spec and unfudge
lue should refrain from going smiley-less on sarcastic comments in the future. 20:03
TimToady \o/ first time evar! completed make with all 3 backends 20:04
lue \o/
TimToady quick, someone add in the JS backend
masak \o/
lue still has to get through Test.pm on MVM
masak .oO( Model... VievModel? ) 20:05
View*
TimToady no, I think MVM makes movies
lue 1995, right? 20:06
TimToady Metro Voldwyn Meyer or some such
masak Metro Voldemort Meyer
lue Metropolis Voltage Meter
TimToady Mountain View Megatherium 20:07
lue Is it just me, or do the L<> references to the spec in roast/ vary a bit too much in their format for comfort? I'm not in the mood to write a very detailed grammar for them right now :P
timotimo i'd like to merge the jvm_interop_dispatchers branches into master and nom respectively. thoughts? 20:08
TimToady knows a pretty good language for writing grammars...
colomon TimToady: is it…. C++? 20:09
TimToady did I hear a buzzing in the air?
lue Well, I know XML is good for everything, so...
or am I supposed to interpret the /fragment> portion as though it were a in a «» (complete with shell-quoting semantics)? That feels like what's happening here. 20:11
moritz TIL about "Astroid Lindgren": en.wikipedia.org/wiki/Astrid_Lindg...indgren.22 20:15
lue At some point the grammar will probably match L<S\d\d/[stuff]/[stuff]>, with me feeding each of those "stuff"s into eval("«" ~ $stuff ~ "»") :) 20:17
timotimo moritz: suggestions for going ahead with the jvm interop branch? it runs all the spectests for concurrency, which is apparently the only place we use the jvm boot interop. 20:19
even after replacing all the long methods with short methods 20:20
jnthn timotimo: Did you put this stuff in the Rakudo subclass of the core interop stuff?
Or in the NQP one?
timotimo ah, good point
it's still in the NQP one.
you said you didn't want that
jnthn Well, it's going to become an issue I think when we get to the type based dispatch.
'cus then we may well want to be able to talk about Rakudo types as part of the decision making. 20:21
timotimo mhm
timotimo i'm not sure how to properly tear the code in nqp apart so that rakudo can properly replace the stuff 20:22
short of putting a method in there that does nothing in nqp and then implement it in rakudo 20:23
jnthn Could do that.
GenerateDispatchers(...); which does nothing by default
timotimo well, i guess i should
jnthn Well, it's now or later :) 20:24
timotimo can the analysis logic stay in nqp-land or should it move over to rakudo, too?
jnthn What's it doing?
Looking for the duplicates?
So long as it won't need anything Rakudo specific in it, I guess it's OK in NQP... 20:25
timotimo hold on, i'll analyze what i wrote in my ... well not drunken, but ... :P
timotimo in createAdaptorMethod I sort all the methods into buckets for their arities 20:27
that's not type-based, that's only for arities
timotimo but on rakudo it'll also need a bit of analysis to stash away the types, if we inspect them at that point 20:28
i *think* the inspection could happen at a later point, too 20:30
jnthn: should i dream up some extra tests for the bootinterop? 20:31
jnthn timotimo: Yeah, tests would be great. 20:33
In t/jvm/ or so
timotimo *sigh* 20:34
timotimo can you suggest classes to bootinterop so that i have a good approach? 20:34
timotimo a good thing to approach* 20:35
jnthn StringBuilder has some methods that vary only in arity, I think 20:37
Yeah, looking at docs...indexOf
Also substring
timotimo thanks, that's a good start i hope
itz_ hmm I don't seem to be able to build nqp-m anymore .. is that my fault or just how things are? 20:41
moritz itz_: it needs an up-to-date MoarVM, probably newer than the configure script requires/checks 20:43
I've built it successfully today, though I'm not sure if it was with the very latest versions 20:44
itz_ ok ty I'll try again 20:45
This is MoarVM version 2013.10-233-g67d0815
moritz that's the newest, yes 20:48
masak the slots for 23rd and 24th are still unclaimed. 20:49
moritz if somebody has a good for what to write, I'll take the 23rd 20:50
timotimo masak: i thought about maybe claiming a slot, but i couldn't think of a good topic yet
moritz: if you can say something interesting about it, maybe an article about what exactly in rakudo is slow, why it isn't fast yet and what needs to happen for things to get fast?
moritz timotimo: I'm not sure I'm the right person to talk about that 20:51
moritz still kinda hopes that raydiak++ will write about his ray tracer 20:51
timotimo oh yes :) 20:52
raydiak good chance that'll still happen :)
timotimo jnthn: should it be 00-jvm or 03-jvm? or just jvm?
timotimo questhub.io/realm/perl/quest/529dec...a311000030 - feel free to give me thumbs up to ease my pain :P 20:56
jnthn timotimo: Just jvm works for me, I think... 20:59
masak timotimo: you'll get a thumbs-up from me here on channel -- I'm too lazy/busy to log in...
timotimo sure
j: my Mu $iop := nqp::jvmbootinterop(); my \StringBuilder := $iop.typeForName('java.util.StringBuilder'); my $foo := StringBuilder.new(); 21:01
camelia rakudo-jvm 413650: OUTPUT«java.lang.ClassNotFoundException: java/util/StringBuilder␤ in block at /tmp/G2YSSVPuso:1␤ in any eval at gen/jvm/stage2/NQPHLL.nqp:1086␤ in any evalfiles at gen/jvm/stage2/NQPHLL.nqp:1292␤ in any command_eval at gen/jvm/stage2/NQPHLL.nqp:1196…»
timotimo j: my Mu $iop := nqp::jvmbootinterop(); my \StringBuilder := $iop.typeForName('java.lang.StringBuilder'); my $foo := StringBuilder.new();
camelia rakudo-jvm 413650: OUTPUT«No such method 'new' for invocant of type 'BOOTJavaObject'␤ in block at /tmp/b4fvlX9Wiy:1␤ in any eval at gen/jvm/stage2/NQPHLL.nqp:1086␤ in any evalfiles at gen/jvm/stage2/NQPHLL.nqp:1292␤ in any command_eval at gen/jvm/stage2/NQPHLL.nqp:1196…»
timotimo mhm mhm
ah, that would be because there's multiple arities
i don't think i do constructors properly yet
or look at them at all 21:03
itz_ hmm I can only build nqp-m with 2 directories nqp and MoarVM at the same level .. not the structure moar-support defaults to 21:04
timotimo my local structure has ~/perl6 with nqp/, MoarVM/, rakudo/ and install/ - which is the --prefix for the three before that 21:05
also parrot/
i like that much better than on my desktop where i have ~/build/rakudo/ with nqp/, nqp/parrot/ and nqp/moarvm/ 21:06
lue Huh. I could swear there was a Str.slurp method... 21:22
TimToady why would a Str know how to do IO? 21:23
you can do slurp(Str) though
lue there's slurp(Str), so I guess I was expecting a Str.slurp
TimToady or Str.IO.slurp
lue Since it's originally an IO::Path, I'll just do IO::Path.IO.slurp 21:25
japhb_ Anyone have any thoughts on my 'proto MAIN(|) is options-parsed(PARSER) {*}' idea? 21:30
PerlJam japhb_: just "interesting" and a generally positive feeling about it. :) 21:35
japhb_ Well, that's good at least. 21:36
PerlJam I know I've been annoyed at the current behavior and having a relatively easy way to switch it out would've been nice. 21:37
japhb_ I keep expecting someone (TimToady?) to come back with a "That's a horrible idea, because *good reasons*."
Yeah.
Some of the common parser variants are probably small enough (or similar enough, so that the differences can be factored out), that I might just include ~3 variants in core. 21:38
lue japhb_: not sure how I feel about a trait. Perhaps just a ARGPARSE sub? MAIN already magically calls a USAGE sub upon malformed args, so why not magically call another sub? 21:39
skids also, should it be a sub, or a grammar? 21:40
japhb_ lue: Definitely a possibility; it fits the rest of the MAIN design. Makes it harder to write a single module that provides multiple parser variants, though.
lue japhb_: same could be said for a module that would like to provide multiple USAGE message templates :) 21:41
japhb_ skids, I was going to go with DWIM: Callable, Grammar, or object/class.
lue: Yes, I completely agree. I'm not convinced the current design WRT USAGE, etc. is sufficiently general, but it does have the huffmanization down for doing small utilities. 21:42
lue All I know is that using a trait here feels wrong to me, and that's likely because of how USAGE happens. 21:43
PerlJam Hmm. MAIN magically calls USAGE ... does that mean that the replacement arg-parser will be "required" to do the same? (or, switching out the arg parser with arbitrary code seems to work against some of the magic) 21:44
japhb_ skids, One small issue is that a grammar expects a single block of text. On some platforms, the args are indeed a huge block of text. On others the args come in as an array of blobs, and on still others they are strings of same native variety.
skids If it would be possible in the body of MAIN with comparibly many charaters, why do it?
lue PerlJam: that's what I was thinking about. Presumably there are situations where malformed args are supposed to do everything except print a message, so perhaps USAGE could lose some of its magic there. 21:45
PerlJam lue: oddly, having another auto-magic sub feels wrong to me and I don't have a strong opinion about using a trait.
lue The whole idea of a main sub, looking at C for a moment, that requires the sub to accept certain arguments and return certain values tends to make for weird design choices. 21:46
Moral: MAIN subs are really weird.
japhb_ PerlJam, I think it is relatively common that people will want to replace &USAGE, and a large (but not total) overlap with those that would want to replace the parser.
lue I think weird magical behavior for the MAIN sub is justified, because MAIN itself is a bit odd. 21:47
japhb_ MAIN has quite a bit of magic, it's true. 21:48
And yes, it does feel at least partially justified.
Because MAIN serves as an interface to a special input that nothing else directly touches. 21:49
PerlJam If the arg-parser were just a grammar, then the USAGE magic could stay easy enough (and maybe be improved)--when the grammar fails, that's what trigger's the USAGE call (possibly with a parse fragment to aid in better usage messages)
japhb_ "In unix, everything is a stream of bytes ... except the command line arguments."
lue But yeah, how to make USAGE and ARGPARSE relate is interesting. Even if ARGPARSE is implemented as a trait, there *will* be people who want to disable the use of USAGE in their argparsers.
japhb_ lue: That feels like a mini-protocol. Returning Failure from ARGPARSE should send you to USAGE. 21:50
But remember that USAGE is also triggered by --help
lue For the record, I can see the argparse-as-trait argument favorable, seeing as the idea the USAGE is highly specialized, where ARGPARSE is highly generalized, therefore traits work better as a way to share parsers. 21:51
(meanwhile USAGE so rarely is shared in such a way) 21:52
japhb_ I think right now we're doing a poor job with USAGE (and I say that as one of the primary implementors of the current version of it). 21:53
skids japhb_: good point. I guess before thinking on this problem having a good survey of what MAIN is actually handed from the OS across various platforms would be helpful. 21:54
lue japhb_: --help only triggers USAGE by way of normal "adverb not defined" rules. If you define a :$help, you need to be explicit.
(with a USAGE if $help line)
japhb_ lue: Not so. Look at the implementation
(re: poor job with USAGE) Basically, for MAIN signatures of moderate complexity or non-trivial number, it becomes a hard to read wall of text mess. 21:55
skids e.g. platforms exist where the argv contains strings with nulls in the middle, or not, or might? 21:56
timotimo now i wish for duck typing in java
japhb_ I want the default to be much smarter about formatting and documentation (and have a better default parser, which affects where options can be displayed in the usage info), so that this becomes much more readable.
timotimo all the methods i need from Method are also in Constructor
lue japhb_: you talking about the $n<help> at the end of Main.pm?
timotimo but i don't think i have a common superclass i can use
japhb_ lue: yes. Though I admit I haven't checked whether that code is still *reachable* since last I worked on it. 21:57
timotimo oh, but i can try casting. that'd be good enough
lue while we're on the subject of MAIN, I'm not entirely convinced that P6's named/positional arguments system maps exactly to commandline args.
(for example, I'm pretty sure I can't define a -? option) 21:58
japhb_ lue: I think you *can* define -?, but I forget the exact syntax, and it's probably not pretty. :-/
But I think when you have 'positional options', it gets rather fuzzy. 21:59
Think about implementing the imagemagick command line.
lue :h($help) is how you get short and long form, right?
japhb_ Yeah.
lue so how do you generate *just* the short form? :$x would get me --x, when I'd prefer -x 22:00
dalek p: b22f11f | jnthn++ | src/vm/moar/QAST/QASTOperationsMAST.nqp:
Fix a bunch of wrong constants.
japhb_ lue: You can always have the short form if the name has only 1 character
lue come to think of it, an ARGPARSE function would have to be forced to return a Signature(?) matching sub MAIN's. Just like how C's main is forced to return an integer :) 22:01
japhb_ The usage generator is strict about - versus --, though I think in fact the current parser is more lax, and will accept either - or -- for any length option anme
lue quickly tests short form stacking... 22:02
nope. 22:03
japhb_ lue: I don't think so. process-cmd-args() inside MAIN_HELPER just returns the positional and named arguments, and lets the outer code try to match against MAIN candidates.
lue: Nope, no short form grouping.
That might even be spec, come to think of it.
lue japhb_: *that* would explain why your proposal idea is written with a proto sub :) 22:04
japhb_ "that"?
lue <japhb_> lue: I don't think so. process-cmd-args() inside MAIN_HELPER just returns the positional and named arguments, and lets the outer code try to match against MAIN candidates
masak 'night, #perl6
lue ♞ masak o/
japhb_ Wow, masak was here and didn't paint the bikeshed? Awww .... 22:05
o/ masak
lue japhb_: basically, you reminded me that multi sub MAIN was a thing right there :)
japhb_ heh
lue r: proto sub foo(|) { say "A" }; multi sub foo(Str $a) { say $a }; multi sub foo(Int $b) { say $b * 2 }; foo("bar"); foo(12); 22:06
camelia rakudo-parrot 413650, rakudo-jvm 413650: OUTPUT«A␤A␤»
japhb_ lue: Yeah, that dispatcher never dispatches. ;-)
japhb_ r: proto sub foo(|) { say "A"; * }; multi sub foo(Str $a) { say $a }; multi sub foo(Int $b) { say $b * 2 }; foo("bar"); foo(12); 22:06
camelia rakudo-parrot 413650, rakudo-jvm 413650: OUTPUT«A␤A␤»
japhb_ Ah, maybe it detects onlystar 22:07
jnthn japhb_: {*}
lue japhb_: I was thinking for a moment that proto sub MAIN(|) is ARGPARSE {*} could be replaced with proto sub MAIN(|) { ARGPARSE; nextsame} or something :)
r: proto sub foo(|) { say "A"; {*} }; multi sub foo(Str $a) { say $a }; multi sub foo(Int $b) { say $b * 2 }; foo("bar"); foo(12);
camelia rakudo-parrot 413650, rakudo-jvm 413650: OUTPUT«A␤bar␤A␤24␤»
japhb_ Oh, is {*} a token and not a block containing Whatever? 22:08
skids lue: that's what I meant by "done inside of MAIN"
lue japhb_: that `say "A"` place is where ARGPARSE stuff could go, perhaps? :) [likely not]
japhb_ lue: Hmmm, I'm not sure how it would communicate that the arguments are already parsed (or are going to be manually parsed), so that MAIN_HELPER can detect this. 22:09
dalek kudo/moar-support: 0df06cf | jnthn++ | src/vm/moar/ops/perl6_ops.c:
A little extra validation.
 22:10
kudo/moar-support: c5ecb99 | jnthn++ | src/core/GatherIter.pm:
A cheating, eager gather/take.

Gets us by for the basic things for now, until MoarVM has continuation support implemented.
lue japhb_: yeah, not the best place to intercept input :/ . At least I know how to have common operations carried out in a multi sub now :D 22:11
dalek kudo/moar-support: 632da41 | jnthn++ | src/vm/moar/ops/perl6_ops.c:
Fix p6var op.
 22:12
kudo/moar-support: c5008b2 | jnthn++ | src/vm/moar/ops/perl6_ops.c:
Harden p6decontrv.
skids Maybe proto sub MAIN exists as a default unless you specify it, and if you do, you have to call MAIN_HELPER manually...
lue
.oO( proto sub MAIN(Int argc, Array[Uni] argv) {*} )
 22:13
FROGGS uhh
FROGGS pulls
lue 💡 I wonder if one could write a post on that proto { prestuff; {*}; poststuff } trick... 22:14
japhb_ A nice idea, that. :-) 22:15
lue idly wonders if &uniname should be called &uname ... 22:16
lue japhb_: In general, though, I don't think I would mind a reworking of the MAIN setup. 22:17
japhb_ Yeah, it feels like time. 22:18
lue What's the thing that lets you see the raw arguments, again? 22:19
PerlJam lue: you mean like sub foo(|args) { } ? 22:20
lue no, I was thinking of @*ARGS
FROGGS jnthn++ # t/spec/S16-io/say.t ........................................... ok 22:24
jnthn FROGGS: Um...but we don't have Test.pm loading working yet. 22:25
FROGGS: Does that test file not use it?
lue japhb_: I keep on thinking that an ARGPARSE mechansim needs syntax that clearly illustrates its injective nature, i.e. <outside world> <custom ARGPARSE> <MAIN>
FROGGS jnthn: it doesn't use it, right
jnthn: it just say()'s the tap :o) 22:26
jnthn FROGGS: Hm, so how many tests is it? :) 22:27
FROGGS jnthn: that is the only one that passes... 8 single tests
jnthn heh, 8 :) 22:28
lue If you tilt your head (y'know, to read jnthn's smiley properly), that's ∞ tests! 22:28
jnthn r: say 8 / 28238 22:29
camelia rakudo-parrot 413650, rakudo-jvm 413650: OUTPUT«0.000283␤»
jnthn 0.03% ;)
That's infinitely better than 0.00%
FROGGS I that the time when it goes into nom? :o) 22:30
lue jnthn: I just tried to do 'panda install Rakudo::Debugger', and got 'sh: nqp: command not found' as the first line. 22:31
FROGGS ohh
it should run nqp-somthing instead
japhb_ Way back when I think I wrote a sanity test for Rakudo that just spit out the TAP. Did that go away at some point?
jnthn japhb_: I think all of t/01-sanity does. 22:32
lue FROGGS, jnthn: then there's a stat failure and "Unable to open filehandle from path 'perl6-debug.pbc': No such file or directory(2)", so it seems to require nqp-p, at least for now?
jnthn japhb_: Except one of them.
FROGGS lue: yeah, looks like
jnthn FROGGS, lue: If somebody does the appropriate build love, it works on JVM too, fwiw.
FROGGS dunno how we make these kind of modules multi backend aware
lue I could just set up a symlink to nqp-p for now :P 22:33
japhb_ lue, "illustrating the injective nature" is a large part of why I thought decorating the proto worked well -- because normally the proto would be hidden, but with this you show "I'm about to override how dispatch to MAIN happens"
jnthn, Ah, right, because the last sanity test would see if it could get Test.pm to work, but all of the previous sanity tests (the ones I wrote, anyway), were just trying to see if enough functionality existed that Test.pm could *possibly* run.
dalek kudo-star-daily: f9bd147 | coke++ | log/ (5 files):
today (automated commit)
 22:34
lue japhb_: true. The trait on its own doesn't illustrate that, meanwhile the proto on its own can/does. I'm not sure of the net effect of those two together :)
jnthn japhb_: Right. And I'm at this point passing all but the final one on Moar :)
japhb_ Back when I first wrote them, there was a big gap between the last sanity test I completed, and Test.pm. But ISTR others filled in the functional gap there with more test files.
[Coke] oooh, good news.
japhb_ jnthn, AWESOME! \o/ 22:35
lue cheated with an 'nqp' symlink for now :) .
lue &
dalek kudo/moar-support: 7c7dc29 | jnthn++ | src/Perl6/Metamodel/BOOTSTRAP.nqp:
Attributive parameter binding.
 22:36
kudo/moar-support: ff6397c | jnthn++ | src/core/terms.pm:
Support $*CWD on Rakudo on Moar.
[Coke] from the daily run that hasn't been pushed:
[Coke] "total", 8, 26551, 0, 0, 26559, 28250 22:37
and it looks like jnthn++'s been busy since then. :)
jnthn [Coke]: Yeah, but all the busy is "get Test.pm to run" :)
[Coke] and, and looks like the 8 was already mentioned. well, it'll be "official" soon. :) 22:38
[Coke] can't push until jvm finishes. slow, slow, jvm. 22:40
I have 2 weeks of time to do some (amongst other things) sixperl, before 2014. yay.
timotimo \o/ 22:42
dalek kudo/moar-support: 90fec0a | jnthn++ | src/core/terms.pm:
Uncomment the remaining @*INC support bits.

All that it depends on is now fixed. With this, we now mostly pass 99-test-basic.t (around 5 failing test cases).		 22:44
japhb_ I am quite excited about that last commit message. 22:52
jnthn++ and (moarvm team)++ 22:53
lue [Coke]: what is sixperl, again? 22:54
timotimo what, it works?!
dalek p/jvm_interop_dispatchers2: e81dec4 | (Timo Paulssen)++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/BootJavaInterop.java:
allow us to dispatch arity-based constructors
 22:56
jnthn It seems we can now attempt spectest runs. Naturally a lot fails. More problemaitc, various things hang.
jnthn Presumably as a product of gather not being properly lazy yet. 22:57
timotimo likely, yeah
just make it abort after 50 items or something :P
jnthn Yes, I'm actually seriously considering that :) 22:58
There are some positives amongst the massive fail, mind...
Failed 108/108 subtests
t\spec\S03-operators\basic-types.t ............................ ok
oops, that wasn't the lines I meant to copy :)
ah well, some things do pass :)
timotimo that's pretty darn cool :) 22:59
FROGGS wow, it is passing a lot of tests it seems 23:00
jnthn Can be curious to see what passes... 23:01
t\spec\S05-grammar\protoregex.rakudo.moar ..................... ok
:)
japhb_
.oO( Today, the daily run shows infinite growth in tests passing for rakudo-moarvm, but tomorrow it will merely be thousands of percent growth. Clearly jnthn is slacking off! )
jnthn :P 23:02
FROGGS gnight!
timotimo i'm going to bed, too
japhb_ o/ FROGGS and timotimo
timotimo having made constructors arity-dispatch as well, i've surpassed my daily goal \o/
jnthn timotimo++ 23:03
That's awesome.
japhb_ indeed
lue A minor nitpick, I notice that nqp-m installs a <prefix>/languages directory? I'd prefer something like <prefix>/share/MoarVM/languages, for when the <prefix> is /usr/local :) 23:05
jnthn lue: I suspect there'll be various things that'll want improving with regard to install stuff. 23:13
lue :) Not too big a deal, I just dislike when programs add directories to /usr or /usr/local for no clear can't-put-it-in-one-of-the-existing-dirs reason. 23:14
jnthn Oh my...I think we may have been having slower spectest runs on JVM for no good reason... 23:15
On Parrot, we pre-compile Test.pm and put Test.pir in lib 23:16
So we find it when running spectest
For JVM we put it in blib, don't, and thus re-compile Test.pm for every test case.
japhb_ Oh, shazbot.
lue Come to think of it, <prefix>/languages might fit better as <prefix>/lib/MoarVM/... 23:17
jnthn Discovered 'cus I coudln't believe MoarVM was a bit tardy with spectest, then figured it wasn't either...
dalek kudo/moar-support: 2873438 | jnthn++ | src/core/GatherIter.pm:
Try to avoid hangs due to gather not being lazy.
 23:28
kudo/moar-support: 61c62b1 | jnthn++ | tools/build/Makefile-Moar.in:
Ensure pre-compiled Test.pm is in the right place.

Powered by Cro and the Raku® Programming Language.

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

Thank you!