Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6, 2015-02-03

Perl 6 | Reference Documentation | Rakudo

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:02 telex joined #perl6
00:03 [Coke] tried doing just an nqp-parrot build, the config step there was fine; do we need a revision bump on rakudo, I wonder.
00:06 woolfy virtualsue++ and sjn++: thanks for being at the booth and speaking to people with difficult and other Perl questions!
00:06 woolfy I completley forgot to mention Mark Keating.  He has been many many hours at the booth and he was awesome.
00:07 woolfy Pictures of FOSDEM by Bas Bloemsaat: http://imgur.com/a/1ynV7#0
00:07 Peter_R joined #perl6
00:10 hoelzro [Coke]: it's gotten as far as compiling CORE.setting for me
00:10 hoelzro still chugging along...
00:13 hoelzro yup, looks ok to me!
00:18 BenGoldberg joined #perl6
00:19 BenGoldberg joined #perl6
00:32 skids sjn: What's the NativeCall hackathon doing -- making new modules that use it, or improvements to NativeCall itself?
00:40 BenGoldberg joined #perl6
00:41 BenGoldberg joined #perl6
01:09 KCL_ joined #perl6
01:10 virtualsue_ joined #perl6
01:16 yeahnoob joined #perl6
01:42 colomon joined #perl6
02:16 colomon joined #perl6
02:17 Mouq joined #perl6
02:49 isacloud joined #perl6
02:59 colomon joined #perl6
03:18 Patterner joined #perl6
03:30 noganex joined #perl6
03:39 lumimies joined #perl6
04:17 jack_rabbit joined #perl6
04:19 kaleem joined #perl6
04:22 anaeem1_ joined #perl6
04:58 awwaiid joined #perl6
05:01 [Tux] joined #perl6
05:06 Mouq joined #perl6
05:32 mr-foobar joined #perl6
05:45 konsolebox joined #perl6
05:46 fhelmberger joined #perl6
05:54 Ulti joined #perl6
05:55 keenan joined #perl6
06:18 xfix joined #perl6
06:36 * TimToady waiting at BRU...
06:45 * TimToady heading to gate, might or might not pop up in AMS
06:45 TimToady afk &
06:50 [Sno] woolfy and the Perl (6) community: with pleasure
06:55 Rounin joined #perl6
06:56 dayangkun joined #perl6
07:00 Mouq joined #perl6
07:01 dalek doc: 34778bb | moritz++ | util/update-and-sync:
07:01 dalek doc: Fix rebuild
07:01 dalek doc: review: https://github.com/perl6/doc/commit/34778bb4a4
07:12 alini joined #perl6
07:19 gfldex joined #perl6
07:57 FROGGS joined #perl6
07:57 kjs_ joined #perl6
07:59 abraxxa joined #perl6
08:02 nine FROGGS: awesome! Thanks to your NativeCall improvement, I can get rid of my $array = CArray[uint8].new(); for ^$value.elems { $array[$_] = $value[$_]; } p5_buf_to_sv($!p5, $value.elems, $array);
08:03 FROGGS nine: retupmoca++ did that :o)
08:04 FROGGS and raydiak
08:04 FROGGS and raydiak++ also provided a patch
08:04 FROGGS I think, next step would be to allow returning a buffer, after parrot and jvm are fixed
08:05 FROGGS and... I want to implement sizeof() and allow to nativecast with an offset
08:09 nine raydiak++ # seems like I missed that backlogging
08:09 nine Also I got myself a really nasty cold, so my brain is not up to speed :/
08:09 JimmyZ FROGGS: It'd be nice to have: my num $x is global('xxxx.so'); or my num $x is global('xxxx.so', 'x');
08:10 JimmyZ m: say $x.VAR.name
08:10 camelia rakudo-moar bececd: OUTPUT«[31m===[0mSORRY![31m===[0m Error while compiling /tmp/BTL0mY3Ytgâ�¤Variable '$x' is not declaredâ�¤at /tmp/BTL0mY3Ytg:1â�¤------> [32msay $x.VAR.name[33mâ��[31m<EOL>[0mâ�¤    expecting any of:â�¤        method argumentsâ�¤Â»
08:10 JimmyZ m: my $x; say $x.VAR.name
08:10 camelia rakudo-moar bececd: OUTPUT«$x␤»
08:12 _mg_ joined #perl6
08:13 JimmyZ or is Cglobal ?
08:13 trone joined #perl6
08:14 darutoko joined #perl6
08:16 Kristien joined #perl6
08:16 Kristien guten Tag
08:19 FROGGS JimmyZ: probably 'is cglobal', like the sub...
08:19 FROGGS and yeah, I think I like it :o)
08:19 FROGGS not sure that it is easily doable though
08:20 FROGGS Ahoi Kristien
08:22 JimmyZ and nativecast could be used by coerce, methinks.
08:22 Ugator joined #perl6
08:23 zakharyas joined #perl6
08:27 ven .tell raiph maybe you could post jnthn++'s slides to reddit, or are you waiting for the videos
08:27 yoleaux ven: I'll pass your message to raiph.
08:31 sjn skids: it's not a NativeCall hackathon we're doing in Oslo, it's a presentation+some hacking. An "introductory evening" of NativeCall
08:31 nine retupmoca++ # oh man, missed you twice
08:31 FROGGS JimmyZ: that would be sweet I think
08:31 JimmyZ aye
08:32 virtualsue joined #perl6
08:33 _mg_ Hello. Could somebody please point me to where in the rakudo sources the shebang lines are generated, for example for panda?
08:36 _mg_ Hm, never mind, that lives in the panda module.
08:37 _mg_ Hm, could it be that the rakudo installer changes the shebang lines on installation?
08:38 _mg_ https://github.com/tadzik/panda/commit/f4b0f24eee8fe84fa48ea592ee020ece0b8fa2f6 panda used to have /usr/bin/env, but rakudo star 2014.12.1 changes this (in a wrong way). Where does this happen in the code?
08:39 FROGGS _mg_: the scripts in the bin folder in star are not created by panda
08:39 FROGGS they are copied over
08:39 _mg_ FROGGS: ok, but also modified?
08:39 nige joined #perl6
08:41 FROGGS _mg_: we've also a problem with the shebang on osx, and already a solution... we just need to take care of that when we create the next star release
08:42 FROGGS ohh wait, I am talking partially rubbish
08:42 _mg_ FROGGS: that's precisely why I am asking.
08:42 FROGGS for the linux/unix star .tar.gz nothing is copied over, we are only copying stuff for the windows mai
08:42 FROGGS msi*
08:43 FROGGS perhaps something in here needs tweaking: https://github.com/rakudo/star/
08:43 FROGGS ... for the .tar.gz
08:43 _mg_ FROGGS: I try to update/fix the homebrew formula, and upstream wants documentation for the fix.
08:44 _mg_ Well in there modules/panda/bin/panda has the original, correct shebang line. But after installation bin/panda has a modified one.
08:44 telex joined #perl6
08:47 _mg_ I don't see where this could come from
08:54 dolmen left #perl6
08:59 alini joined #perl6
09:03 SamuraiJack joined #perl6
09:08 tadzik _mg_: er, no one generates shebang lines
09:08 tadzik I don't know how star would change this, does it?
09:08 tadzik if it is so, it's beyond me :)
09:09 _mg_ tadzik: It seems so, at least with homebrew.
09:09 tadzik _mg_: what does it change to?
09:09 _mg_ #!/usr/local/Cellar/rakudo-star/2014.12.1/bin/perl6-m, the exact perl location
09:10 _mg_ This fails though because of an issue with bash
09:11 _mg_ tadzik: that's why I'm placing a workaround in the homebrew formula which changes the shebangs back for 2014.12.1.
09:12 KPTN joined #perl6
09:13 tadzik _mg_: ah, so it's homebrew's fault?
09:13 tadzik it's the first time I hear of changing shebangs
09:13 tadzik if Star does it, it's news to me too :)
09:13 _mg_ I wouldn't think so, but I can ask
09:13 nige1 joined #perl6
09:13 tadzik what if you install Star manually on OSX?
09:16 _mg_ tadzik: trying
09:20 lumimies joined #perl6
09:20 Kristien joined #perl6
09:21 _mg_ tadzik: yes, it is modified
09:21 _mg_ #!/tmp/rakudo-star-test/bin/perl6-m
09:21 _mg_ use Shell::Command;
09:21 _mg_ that's bin/panda
09:21 tadzik oh hm
09:21 Kristien Is it possible to customise string interpolation like you can in Scala and ECMAScript 6?
09:22 _mg_ tadzik: it must be somewhere in perl tools/build/bin-install.pl /tmp/rakudo-star-test/bin/perl6-m /tmp/rakudo-star-test/bin m modules/ufo/bin/ufo modules/panda/bin/panda modules/doc/bin/p6doc
09:23 FROGGS Kristien: can you give an example of what you want to achieve?
09:23 tadzik Kristien: how can you do it in scala and ES6? :)
09:26 Kristien FROGGS: e.g. https://gist.github.com/rightfold/7622d00146ed3e9237ad
09:27 Kristien this is immensely useful for XML generation and preventing SQL injection
09:27 _mg_ tadzik: bin-install maybe?
09:27 _mg_ while (<$IN>) {
09:27 _mg_ if ($. == 1 && /^#!/) {
09:27 _mg_ print { $OUT } "#!$p6bin\n";
09:27 _mg_ }
09:27 _mg_ else {
09:27 _mg_ print { $OUT } $_;
09:27 _mg_ }
09:27 _mg_ }
09:27 tadzik :o
09:27 Kristien sql need not return a string, for example
09:27 FROGGS _mg_: please use a nopaste service
09:27 tadzik please don't do this again :)
09:28 tadzik _mg_: but yes, that looks like the guilty code
09:28 AhmadPrince joined #perl6
09:28 _mg_ ok, sorry for that
09:28 _mg_ tadzik: this is still in rakudo/star
09:30 * ven is surprised Kristien++ did not also quote c++'s way of doing it :)
09:30 ven Kristien: that's supposed to be macros and slangs
09:30 FROGGS Kristien: look at rakudo/src/Perl6/Grammar.nqp:4493 and at Slang::Tuxic in the ecosystem... sounds like you want to tweak the quoting language
09:31 Kristien ven: C++ has no string interpolation. Are you referring to UDLs?
09:31 _mg_ tadzik: do you think it is possible to get this fixed?
09:32 Kristien FROGGS: ah I see
09:32 ven Kristien: I'm refering to the sql"" part, not the interpolation part :)
09:32 Kristien I'm confused.
09:33 ven Kristien: yes, I'm refering to UDLs
09:33 Kristien you can't do interpolatino with UDLs :v
09:33 nine Kristien: I'd say having a DSL for SQL queries would be even better than custom string manipulation.
09:34 nine s/manipulation/interpolation/
09:34 Kristien sure, just an example
09:34 ven string are EVILs, let's not do those :P
09:34 Kristien my primary concern is XML generation
09:34 Kristien I'm getting sick of generating XML with as string concatenatino (looking at PHP and Jinja2 in particular) as it scales like a wet sponge in an oven
09:35 nine Kristien: isn't this what templates are for?
09:35 Kristien templates are string concatenation
09:35 Kristien they tend to deal with strings only
09:35 molaf_ joined #perl6
09:35 * JimmyZ want to port drupal's db api to Perl 6, someday
09:35 Kristien I want to deal with actual data structures such as DOMs
09:35 _mg_ tadzik: Homebrew will not accept my patch. So we'd need a new star release that has the relevant fix or wait for the next one.
09:37 nine Kristien: so in pseudocode something like my DOM::Node $node = xml"<foo bar='$baz'>$qux</foo"; that would give you a DOM subtree?
09:37 Kristien yeah, where $baz is a string and $qux is another DOM::Node
09:37 ven Kristien: disagree totally that templates are sting concatenation
09:37 ven just get a real template engine that understands context, it exists in several languages. I think google made one for python, even
09:37 Kristien possibly with an implicit conversino from string to DOM::Node with escaping
09:38 Kristien it's particularly handy when the templates aren't written in a completely different language
09:38 Kristien so I can just define <insert actual programming language here> functions and types and use them in the template
09:40 Kristien I guess an XML slang should work
09:42 Boris joined #perl6
09:45 tadzik _mg_: I'm pretty sure it's possible, can you submit a bug report?
09:45 tadzik on github.com/rakudo/star
09:48 rindolf joined #perl6
09:52 espadrine joined #perl6
09:54 Kristien joined #perl6
09:58 espadrine_ joined #perl6
09:59 _mg_ tadzik: willdo
10:00 coffee` joined #perl6
10:01 moritz m: sub MAIN($x = 42); say $x
10:01 camelia rakudo-moar bececd: OUTPUT«42␤»
10:01 moritz Mouq++
10:02 dakkar joined #perl6
10:06 _mg_ tadzik: https://github.com/rakudo/star/issues/42
10:06 tadzik _mg_++
10:08 Otterpocket joined #perl6
10:08 Otterpocket joined #perl6
10:09 Otterpocket left #perl6
10:13 Otterpocket joined #perl6
10:15 pecastro joined #perl6
10:16 Kristien m: role A { }; class B does A { }; sub f(A $x) { }; f(B.new)
10:16 camelia rakudo-moar bececd: ( no output )
10:16 Kristien excellent
10:17 Kristien m: say B.new ~~ A
10:17 camelia rakudo-moar bececd: OUTPUT«[31m===[0mSORRY![31m===[0m Error while compiling /tmp/ZogTTY5QACâ�¤Undeclared names:â�¤    A used at line 1â�¤    B used at line 1â�¤â�¤Â»
10:17 Kristien m: role A { }; class B does A { }; sub f(A $x) { }; say B.new ~~ A
10:17 camelia rakudo-moar bececd: OUTPUT«True␤»
10:19 moritz would a shebang of the form  #!/usr/bin/env /absolute/path/to/perl6-m work on all our supported platforms?
10:20 Kristien is Windows a supported platform?
10:20 kaleem joined #perl6
10:20 moritz well, yes-ish, but windows doesn't respect shebang lines anyway, no?
10:20 sqirrel_ joined #perl6
10:20 Kristien then no :D
10:20 moritz I should have asked: will it break anything?
10:26 konsolebox joined #perl6
10:28 ab5tract moritz: i will try such a path with my fish shell setup. it exposes edge cases :)
10:28 ab5tract s/path/shebang/
10:29 ab5tract i'm wondering if this is a common error case for the Parsing stage: "Method 'Str<140430866473640>' not found for invocant of class 'X::Undeclared'"
10:29 ab5tract i imagine that it usually results from a specific type of error, which would help me narrow down what is broken about my current patch
10:32 moritz well, it shouldn't be like that, but X::Undeclared gives you a hint that you have an undeclared symbol
10:32 dalek star: 9da6ec4 | moritz++ | tools/build/bin-install.pl:
10:32 dalek star: Fix shebang line on Mac OS X
10:32 dalek star:
10:32 dalek star: hopefully closes #42
10:32 dalek star: review: https://github.com/rakudo/star/commit/9da6ec49d7
10:39 sergot morning o/
10:39 sergot FROGGS: pong :)
10:40 FROGGS sergot: hi, do you use nativecast somewhere to dereference a pointer?
10:40 sergot hmmm, let me see
10:41 sergot this could be the only repo when I might use do so: https://github.com/sergot/openssl/tree/master/lib
10:41 sergot or io-socket-ssl I think
10:41 sergot looking at it
10:42 ab5tract moritz: okay, so a symbol in this case can be ... a term, a var, an anything basically?
10:43 Kristien joined #perl6
10:44 sergot FROGGS: do you mean nativecast from OpaqueuPointer to something?
10:44 sergot Opaque*
10:44 FROGGS sergot: nativecast(OpaqueuPointer, OpaqueuPointer) basically
10:45 kjs_ joined #perl6
10:45 FROGGS sergot: you used it at somepoint, but it seems not the case anymore (which is good)
10:45 tadzik Opaqueue
10:45 FROGGS copy&paste ftw!
10:46 Kristien "opa" is Dutch for "grandpa"
10:46 Kristien an opa queue sounds creepy
10:46 ab5tract (i already took that hint in basically the same way"
10:46 sergot FROGGS: it looks like I don't use it anymore :)
10:48 FROGGS sergot: very good :o)
10:51 rurban joined #perl6
10:52 konsolebox joined #perl6
10:54 zlad joined #perl6
10:55 sergot FROGGS: is there any bug there?
10:58 pmurias joined #perl6
11:00 virtualsue joined #perl6
11:01 pmurias .tell jnthn is there a way to determine if a static block will be used while deserializing closures (as a clone template)
11:01 yoleaux pmurias: I'll pass your message to jnthn.
11:01 FROGGS sergot: no, we just changed what it does.... such a cast won't dereference anymore
11:04 Kristien I'm going to have to write self-modifying code. :(
11:05 FROGGS O.o
11:05 FROGGS are you sure?
11:05 moritz Kristien: what are you trying to do?
11:06 moritz http://www.mercurynie.com.au/mathguys/articles/1998/980311g1.jpg "you have to use calculus and imaginary numbers for this"
11:07 kjs_ joined #perl6
11:07 sergot FROGGS: oh, ok, now I see :)
11:08 FROGGS sergot: so when you have your on pointer type with custom methods you can cast into that without changing the memory address it is about
11:08 Kristien moritz: lazily generate LLVM IR for some functions
11:08 Kristien i.e. the first time they're called
11:08 Kristien but I need to override call instructions for that
11:09 Kristien overwrite*
11:10 arnsholt joined #perl6
11:11 sergot FROGGS: nice :)
11:11 moritz Kristien: sounds like you could use a wrapper, or a separate method mixed into the function
11:12 Kristien I want to optimise out the extra call
11:12 FROGGS make it work first I'd say
11:13 Kristien but maybe I merely have to override some methods from X86JITInfo class
11:13 Kristien it already does that trick but doesn't provide user callbacks
11:18 fhelmberger_ joined #perl6
11:19 moritz ab5tract: I have a local fix for the error reporting in the setting
11:19 kaare_ joined #perl6
11:19 moritz ab5tract: (or at least for one flavor of it :-)
11:20 moritz ab5tract: I'm spectesting now, and if it's all green, push it
11:20 rindolf joined #perl6
11:25 moritz there be fallout :(
11:28 moritz seems at least some of that fallout isn't new
11:29 moritz .tell Mouq t/spec/S32-exceptions/misc.t dies with "Could not find symbol '&Invalid'"; I suspect you were involved
11:29 yoleaux moritz: I'll pass your message to Mouq.
11:30 moritz oh, maybe my rakudo was behind
11:31 moritz .tell Mouq never mind, I mixed up branches
11:31 yoleaux moritz: I'll pass your message to Mouq.
11:31 dalek rakudo/nom: 3f26f91 | moritz++ | src/Perl6/World.nqp:
11:31 dalek rakudo/nom: Fix error reporting of undeclared symbols in the setting
11:31 dalek rakudo/nom:
11:31 dalek rakudo/nom: for ab5tract++
11:31 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/3f26f91665
11:31 Kristien joined #perl6
11:34 xfix joined #perl6
11:35 je5finger joined #perl6
11:39 moritz does t/spec/integration/weird-errors.t fail for anybody else?
11:39 FROGGS I think I've seen that yesterday failing too, aye
11:58 alini joined #perl6
11:58 zakharyas joined #perl6
12:03 virtualsue joined #perl6
12:13 ab5tract moritz: i've rebased my branch against upstream/nom but it still produces the same error message :/
12:18 fhelmberger joined #perl6
12:19 ab5tract i must have broken it good :)
12:21 rurban joined #perl6
12:26 Kristien joined #perl6
12:29 xfix joined #perl6
12:29 xfix joined #perl6
12:31 pierrot joined #perl6
12:33 jferrero joined #perl6
12:33 jferrero joined #perl6
12:36 xfix joined #perl6
12:36 Kristien joined #perl6
12:38 rmgk_ joined #perl6
12:43 KCL joined #perl6
12:48 FROGGS ab5tract: what's your repository/branch?
12:49 ab5tract FROGGS: https://github.com/ab5tract/rakudo/tree/univ-set-ops
12:49 noganex_ joined #perl6
12:49 ab5tract i'm imagining it is a subtle syntax error in there somewhere
12:51 sqirrel_ joined #perl6
12:52 Psyche^ joined #perl6
12:52 pmurias Kristien: what do you need your self modifying llvm functions for?
12:53 fhelmberger joined #perl6
12:53 Kristien replacing call sites
12:53 dagurval_ joined #perl6
12:53 Kristien but nevermind that, I found a much better alternative to my actual problem
12:54 fhelmberger_ joined #perl6
12:54 andreoss joined #perl6
12:56 FROGGS ab5tract: looks like you have to bisect your code by commenting out all changes, and comment them in piece by piece to find the actual problem
12:56 FROGGS I did not spot the error fwiw
12:57 dayangkun joined #perl6
13:02 Kristien pmurias: it makes no semantic difference if I can't do this, luckily
13:02 Kristien But I think the optimisation isn't worth it.
13:04 Kristien what do you do in Perl if someone starts a thread in a BEGIN phaser?
13:04 Kristien does the compiler join it?
13:05 _mg_ joined #perl6
13:05 yeahnoob joined #perl6
13:06 FROGGS Kristien: at shutdown time, yes
13:07 Kristien https://gist.github.com/rightfold/3603bdbd3d366e0cf267
13:08 hoelzro o/ #perl6
13:08 FROGGS hmmmm, jnthn said the VM would join all threads
13:08 FROGGS hi hoelzro
13:12 virtualsue joined #perl6
13:15 muraiki_ joined #perl6
13:17 ven m: BEGIN { await start { say 'hayyy' } }; say 'hi'; END { start { say 'well' } }
13:17 camelia rakudo-moar 3f26f9: OUTPUT«hayyy␤hi␤well␤»
13:18 ven m: BEGIN {start { say 'hayyy' } }; say 'hi'; END { start { say 'well' } }
13:18 camelia rakudo-moar 3f26f9: OUTPUT«hayyy␤hi␤well␤»
13:18 hoelzro ab5tract: I think the problem may be with multi sub infix:<<(>)>>(Any $a, Any $b --> Bool)
13:19 hoelzro working against bececd4, if I remove the code you changed there, it compiles
13:19 lizmat joined #perl6
13:20 psch what hoelzro said, $c and $d aren't declared in that sub
13:20 psch m: END { sleep 4; say "yawn" }
13:20 camelia rakudo-moar 3f26f9: OUTPUT«yawn␤»
13:21 ab5tract hoelzro++, FROGGS++, psch++, moritz++; # thanks!
13:21 ab5tract i knew it would be stupid
13:21 hoelzro the error message itself intrigues me, though
13:25 Kristien I have yet another idea for a new programming languag.e
13:29 psch hoelzro: isn't the error message just a symptom of compiling the SETTING without itself?
13:31 gaston left #perl6
13:31 sqirrel_ joined #perl6
13:33 lizmat .botsnack
13:33 yoleaux :D
13:33 lizmat PSA: the P6 Weekly will be done by me tomorrow
13:34 nine lizmat++ # looking forward to that :)
13:34 lizmat just woke up from a *long* night of sleep after the FOSDEM
13:34 ab5tract lizmat++ && "welcome back!" # :)
13:34 lizmat and tonight's its Amsterdam.PM meeting with the associated travel, dinner and fun  :-)
13:38 pmurias Kristien: so you switched from targeting js to targeting llvm?
13:39 ven lizmat++
13:39 ven pmurias: it's sure nice that llvm targets JS :P
13:40 ven emscripten will rule 'em all
13:44 hoelzro psch: yeah, but it's some crazy message about a method call on X::Declared, right?
13:44 hoelzro it would be nice the original error were allowed to propagate
13:45 pmurias ven: emscripten is a bad target for dynamic languages
13:46 ven it definitely is
13:46 ven I wasn't suggesting a llvm backend for perl6 (though I can guess others proposed it)
13:47 pmurias a lot of people proposed a llvm backend for perl6
13:48 pmurias in reality we would need to use llvm+moarvm
13:49 Mouq joined #perl6
13:49 nine People get confused by llvm's name and think it's a VM.
13:50 rindolf joined #perl6
13:50 geekosaur it "is" one but not in the same sense as they mean
13:51 psch hoelzro: the original error is X::Undeclared.Str, which doesn't exist yet because we're bootstrapping
13:51 hoelzro ahhhh, thanks for the clarification psch
13:51 psch at least that's my understanding...
13:52 psch bbl &
13:52 moritz raydiak, FROGGS: since I've seen you muck with low-level stuff for nativecall: could any of you please add some ops that make it easy to convert from double/Num to Buf and the reverse?
13:52 moritz our pack and unpack routines don't support that yet
13:52 ven nine: I think it *can* be a vm, right?
13:53 FROGGS moritz: that's basically what we are doing
13:53 ven I thought it had jit-like/shaped tools
13:53 moritz and I don't want to parse/recreate floating point formats in Perl 6 code when it's easily available at the C lebel
13:53 moritz FROGGS: you are? where/how?
13:53 FROGGS moritz: since a buffer is a VMArray, and can now cast VMArrays to something else
13:54 moritz FROGGS: also the reverse?
13:54 FROGGS casting to VMArray is in the works, or at least on my todo list :o)
13:55 moritz FROGGS: how would casting from VMArray to Num work?
13:55 FROGGS though, you cannot cast from a single num to something else
13:56 moritz it's fine if I have to to cast to an VMArray of num or so
13:56 FROGGS moritz: it will cast the memory where the VMArray starts to a single Num... but you can also cast to a CArray[Num]
13:56 moritz FROGGS: and how does it look like? is there an op for that?
13:56 FROGGS NativeCall exports sub nativecast(target, source)
13:57 muraiki__ joined #perl6
13:57 FROGGS nativecast(MyClass, $ptr) might be the most used case
13:57 moritz well, pack and unpack are in core
13:57 moritz so I can't rely on NativeCall there
13:57 FROGGS but NativeCall isnt (yet)
13:58 FROGGS some ppl voted already for NativeCall being in core, and I tend to agree because NativeCall is tied to the VM tightly
13:58 geekosaur ven: llvm is more of an abstract representation of real CPUs, with on the fly conversion to the real CPU --- where a VM in your sense is focused on the virtual representation as the main one and optimizes interpretation on the real hardware, LLVM is focused on the real CPU and pushes as much stuff directly onto it as possible. one result isLLVM is much lower level
13:59 ven geekosaur: I know what llvm is. I just think they had some jit-like tools (that were abandoned at some point?)
13:59 FROGGS and TimToady also mentioned that unpack might be just about unpacking a blob using a class definition (like what we do with the CStruct repr)
13:59 geekosaur if you're using a VM to get the additional features you can achieve in a virtualized environment, the way perl 6 implementations do, then LLVM is focused at too low a level
13:59 pmurias ven: it has jit-like tools
13:59 geekosaur you would target something like moarvm to llvm
14:00 geekosaur this is kinda hard to describe meaningfully, Im afraid, which is why people are confused by it. but it comes down to llvm is much lower level and not as suitable
14:00 pmurias ven: in fact it can be used as a jit
14:00 ven pmurias: right, that's probably what I read about once upon a time then, thanks
14:01 geekosaur it hs jit-like tools, yes, because you can compile to llvm and push the program to different CPUs and it will be, in effect, on-the-fly compiled to the real CPU as it runs
14:01 geekosaur which is really nice if you're doing HPC, but not so helpful for perl6
14:01 FROGGS moritz: see this irc snippet: https://gist.github.com/FROGGS/6464777
14:01 Khisanth joined #perl6
14:02 geekosaur now, if you have a perl6 implementation which compiles to a CPU instead of relying on being able to introspect a virtual machine which can provide more features than a real one (jvm, moarvm, parrot, clr, etc.) then llvm is a viable target
14:03 moritz FROGGS: I really like that
14:04 FROGGS moritz: also that NativeCall would become part of rakudo?
14:04 nige joined #perl6
14:04 pmurias ven: it seems to be use in the newish webkit javascript implementation as a jit
14:05 pmurias ven: so it's likely it would be possible to plug it into moarvm
14:05 moritz FROGGS: no objections to that either
14:05 FROGGS awesome
14:05 pmurias ven: not sure how useful that would be
14:06 ven pmurias: oh, that's interesting. What I read said it was real bad, but that's probably outdated information now
14:07 moritz FROGGS: I've recently touched pack (iirc) in rakudo, and it's a stinking pile of mess. Going through the REPR seems so much saner, because we can reuse much more of the existing language, and also get some structured output
14:08 FROGGS moritz: true
14:08 pmurias ven: it's used only for the more longer running code as one of many jits
14:08 ven oh, yeah, webkit.
14:08 FROGGS moritz: otherwise we would have two different (insufficient?) ways to pack/unpack things
14:09 FROGGS moritz: and I really enjoy the NativeCall way
14:11 moritz FROGGS: btw it would be very nice if .pack could take an optional target type, like .pack(Buf[uint32]) or so
14:12 Kristien joined #perl6
14:13 moritz m: say Buf.new().REPR
14:13 camelia rakudo-moar 3f26f9: OUTPUT«VMArray␤»
14:13 moritz m: say Blob.new().REPR
14:13 camelia rakudo-moar 3f26f9: OUTPUT«VMArray␤»
14:13 Kristien pmurias: yes I did
14:14 moritz is there a good reason why nativecall 31f392b4a138f5f2c7e56f76299105a32177af68 checks the type name (!) instead of the REPR?
14:14 Kristien so I can do stackful coroutines
14:16 arnsholt retupmoca: *ping*
14:16 ab5tract (NativeCall --> core/NativeCall)++
14:16 Kristien with Boost.Coroutine
14:16 arnsholt Any particular reason the commit moritz mentioned checks the type, or just a bug?
14:16 ab5tract don't see any reason against it :)
14:16 Kristien I think Emscripten is out of the question
14:17 retupmoca moritz: I did that so I could define a sub like: 'sub foo(Buf) is native'
14:17 retupmoca because I'm pretty sure that's checking the signature, not the values you pass in
14:17 moritz retupmoca: yes, but my question is, all the other checks are for the REPR, not for the type itself
14:17 retupmoca m: say Buf.REPR
14:17 camelia rakudo-moar 3f26f9: OUTPUT«Uninstantiable␤»
14:17 moritz retupmoca: why not this one too?
14:17 moritz oh
14:18 moritz m: say Buf[uint8].REPR
14:18 camelia rakudo-moar 3f26f9: OUTPUT«Uninstantiable␤»
14:18 moritz m: say Buf[uint8].new().REPR
14:18 camelia rakudo-moar 3f26f9: OUTPUT«VMArray␤»
14:18 retupmoca right - I didn't want to put 'new' in all my signatures
14:18 moritz retupmoca: ok. I'll clean it up a bit anyway
14:19 moritz retupmoca: using ~~ Blob looks much saner to me than comparing the type names
14:19 moritz m: say Buf ~~ Blob
14:19 camelia rakudo-moar 3f26f9: OUTPUT«True␤»
14:19 retupmoca yeah, that's cleaner - not sure why I pulled out the name
14:21 FROGGS moritz: aye, I wanted to fine tune that too, though I still struggle with parrot (almost commitable) and jvm (not yet started)
14:21 dalek zavolaj: 27d9263 | moritz++ | lib/NativeCall.pm6:
14:21 dalek zavolaj: Clean up type_code_for
14:21 dalek zavolaj: review: https://github.com/jnthn/zavolaj/commit/27d9263e2c
14:22 yeahnoob joined #perl6
14:23 dalek nqp-js: b12ccd4 | (Pawel Murias)++ | src/vm/js/old-nqp-runtime/ (2 files):
14:23 dalek nqp-js: Remove old runtime module.
14:23 dalek nqp-js: review: https://github.com/pmurias/nqp-js/commit/b12ccd474b
14:23 dalek nqp-js: b4c5d10 | (Pawel Murias)++ | src/vm/js/ (2 files):
14:23 dalek nqp-js: Simple uncatchable exceptions.
14:23 dalek nqp-js: review: https://github.com/pmurias/nqp-js/commit/b4c5d105b0
14:23 dalek nqp-js: 8d4b309 | (Pawel Murias)++ | src/vm/js/QAST/Compiler.nqp:
14:23 dalek nqp-js: Remove dead code.
14:23 dalek nqp-js: review: https://github.com/pmurias/nqp-js/commit/8d4b309e25
14:23 dalek nqp-js: 42b757a | (Pawel Murias)++ | src/vm/js/ (3 files):
14:23 dalek nqp-js: Partial deserialization of closures and contexts (we don't deserialize the lexicals yet).
14:23 dalek nqp-js: review: https://github.com/pmurias/nqp-js/commit/42b757a033
14:23 [Coke] hoelzro: ahhh, think I found my problem: left off a --gen-parrot in my config. :|
14:39 moritz tadzik: does panda do any shebang rewriting?
14:39 tadzik moritz: nope
14:39 moritz tadzik: should it? star does it
14:40 tadzik I don't see why it should
14:40 moritz tadzik: see https://rt.perl.org/Ticket/Display.html?id=123497
14:40 tadzik so, p6doc doesn't have its own shebang, and the question is whether panda should add it for it
14:41 tadzik perhaps
14:41 moritz tadzik: thing is, p6doc could at most write '#!/usr/bin/env perl6', but that won't give me the perl6 that the modules were precompiled with
14:42 tadzik good point
14:42 tadzik yeah, I guess it should then
14:43 tadzik I opened a bug
14:43 moritz tadzik++
14:46 _sri so, is it perl6 1.0, perl6 6.0.0, or perl 6.0.0?
14:46 moritz _sri: we haven't decided anything about that
14:47 moritz _sri: my personal preference is to call it "perl6 2015.12" or so
14:47 _sri just don't make it the last one
14:47 colomon joined #perl6
14:47 chenryn joined #perl6
14:48 moritz well, if we follow semver, we'd need at least one more dot
14:48 moritz because we want to be able to do backwards-incompatible changes without landing us at perl 7.*
14:48 _sri i've seen sentiments along the lines of "i'll never write it as perl6" in the backlog, and i think if that spreads there will be a lot of friction between the perl5 and perl6 communities
14:48 btyler it's more to do with the perl5/perl6 "sister language" thing
14:49 dalek star: 544dd76 | moritz++ | tools/star/Makefile:
14:49 dalek star: Bump rakudo/nqp/parrot/moar versions
14:49 dalek star: review: https://github.com/rakudo/star/commit/544dd764d2
14:49 dalek star: 5a93581 | moritz++ | modules/ (17 files):
14:49 dalek star: Bump module versions
14:49 dalek star: review: https://github.com/rakudo/star/commit/5a9358143a
14:49 dalek star: 52105c5 | moritz++ | / (2 files):
14:49 dalek star: adopt versions in tools/build/Makefile.in and README
14:49 dalek star: review: https://github.com/rakudo/star/commit/52105c5d07
14:49 dalek star: 33346aa | moritz++ | tools/build/panda-state.p6:
14:49 dalek star: Avoid warning in tools/build/panda-state.p6
14:49 dalek star: review: https://github.com/rakudo/star/commit/33346aad72
14:50 colomon joined #perl6
14:50 Peter_R If it is Perl 6.0.0 that will be very confusing, far too similar to the whole Python debacle
14:51 _sri not just confusing, there would be two separate communities claiming the name perl
14:52 Peter_R _sri, still sounds like Python to me ;_
14:52 PerlJam There are *already* two communities claiming the name perl
14:52 Peter_R *;)
14:52 PerlJam (Though I don't think they are quite 'separate' yet)
14:52 Peter_R I don't even think of Perl 6 as being, semantically, the same as Perl
14:52 Peter_R It is like calling an apple and orange
14:53 moritz it's not the same as Perl 5 :-)
14:53 btyler I think _sri's point is that choosing "Perl 6.0.0" will go a long way towards making them quite separate, even antagonistic
14:53 PerlJam Peter_R: no, it's more like calling "homo sapiens" and "homo habilis" both primates.
14:53 moritz but both apples and organes are fruit
14:53 Peter_R PerlJam, that would be calling both programming languages
14:53 moritz can't we identify "Perl" with "fruit", "Perl 5" with "apple" and "Perl 6" with orange?
14:53 NewbiePig joined #perl6
14:54 PerlJam Peter_R: no, that's more like calling H. sapiens and H. habilis "mammals"   ;)
14:54 Peter_R But it isn't a Perl anymore than Ruby is....
14:54 Peter_R Perl 6 that is
14:54 moritz Peter_R: citations needed
14:54 PerlJam heh
14:54 mst if perl6 is released as "Perl 6.0.0" instead of "Perl6 1.0" we're in for another five years of hostility, and making it incredibly hard to recruit perl5 developers because why would we come and try and help something that's actively attempting to kill our preferred programming language?
14:54 Peter_R This is my view as an external observer of course
14:54 btyler (I tend to agree that everything would be easier if perl5 becomes "raptor" and perl6 becomes "camelia", and they're both "perls"...but I'm just the peanut gallery)
14:54 moritz Peter_R: lots of different opinions can exist on this one
14:54 Peter_R Thinking about it logically, that's what I decided anyway
14:54 moritz Peter_R: and since you're in here, you're not an outside observer
14:55 Peter_R moritz, indeed, and I'm sure they do (opinions) :)
14:55 moritz Peter_R: you don't have a monopoly on thinking logically, either
14:55 _sri i guess ideally it would be "Perl 6, version 1, subversion 0 (v6.1.0)", similar to the current perl -v
14:55 kjs_ joined #perl6
14:56 moritz mst, _sri: I appreciate your thoughts on that one, and I kinda agree. I'm happy that my proposal doesn't collide with that :-)
14:56 Peter_R Whatever name gets chosen two things should be made certain: 1) It is clear to people that though their lineage is common, they are incompatible. 2) That it is not possible to accidentally try to run one as another
14:56 Peter_R *name and version system
14:57 psch Peter_R: but that's wrong.  even though it's not planned for 6.0.0, Perl 6 is supposed to backwards compatible where recognizable
14:57 psch at least if S02 didn't change while i wasn't looking
14:57 Peter_R psch, in very basic cases though?
14:57 mst psch: since 2009 both languages have been clear on being sister languages
14:58 moritz psch: it's supposed to, but it isn't
14:58 mst perl6 is not the next version of perl5, it's a NEW perl language
14:58 mst and this is fine
14:58 mst since it's also trying to be a BETTER onde
14:58 * PerlJam bets TimToady didn't realize that the toughest part of Perl 6 would be minutiae about the name.
14:58 Peter_R unless you have realistic aims this is all going to crash and burn...
14:58 Peter_R I mean that in the nicest possible way
14:58 Peter_R I can't wait for 1.0 :)
14:59 psch i phrased that badly i suppose.  moritz' point is the one that matters - we currently don't do perl5 easily and transparently, so the point is valid
14:59 chenryn joined #perl6
14:59 psch i was speaking in "eventually", sorry for friction
15:00 Peter_R psch, and I don't mean that it couldn't be done either. More I was thinking that if we want to attract new, non-perl people, including total beginners we don't want things exploding on them :)
15:00 lizmat commute to Amsterdam&
15:01 mst psch: we'll never get to the eventually if we manage to destroy the community in the now
15:02 huf i know we like to pretend that names matter, but ... nah
15:02 PerlJam Peter_R: indeed.  I can see futuer conversations on #perl *and* #perl6 along the lines of  "Why doesn't my program work?"  "Oh, that's Perl 5, you need to use ..."  (or, "Oh, that's Perl 6, you need to use ...")
15:03 moritz is anybody actually proposing 6.0.0?
15:03 mst huf: you joined -after- the perl5 and perl6 communities nearly ripped each other apart, and masak and I had to mount a co-ordinated campaign across both communities to fix it
15:03 mst moritz: larry called it that in his talk
15:03 PerlJam huf: names do matter in as much as they provide identity to the community
15:03 Peter_R I was just learning to program in other languages when the Python forking occured, and I was totally put off the whole language
15:03 spider-mario joined #perl6
15:04 psch mst: i agree with that.  i don't think releasing as "Perl 6.0.0" would be a good idea
15:04 psch if anything, i'm with moritz on the versioning, "Perl 6 $year.$month"
15:04 mst I sometimes wonder if larry's unaware of just how divisive this stuff is due to even the people on "the other side" being nice to him anyway out of respect (and gratitude for giving us perl5 even if some of those people do sometimes feel like he's trying hard to destroy it)
15:04 moritz mst: so with the exception of TimToady, we're in violent agreement?
15:05 mst moritz: I've not heard any objection voiced apart from something timtoady had in a talk that wasn't specifically about that and therefore shouldn't be assumed to be a binding opinion on his part
15:05 mst (i.e. he might not even be an exception, he might just not have chosen to have a significant opinion)
15:06 anaeem1_ joined #perl6
15:06 mst I wouldn't be surprised if we got pushback from lizmat as well
15:07 mst I can't think of anybody -else- who might be strongly opposed
15:07 huf PerlJam: i think the "war" provides more identity than the names :)
15:08 PerlJam huf: without the names to rally behind, no one knows which side of the "war" they are on  ;)
15:08 huf hah.
15:08 huf sure they do. on one side stand the awk/sedders and on the other the haskelljava people
15:09 moritz mst: http://irclog.perlgeek.de/perl6/2015-02-02#i_10046320 doesn't look a too strong opinion
15:09 PerlJam moritz++ I was just looking that up
15:11 dalek Inline-Perl6: eaf6232 | (Stefan Seifert)++ | / (8 files):
15:11 dalek Inline-Perl6: Get rid of Inline::C to gain more control over the linker
15:11 dalek Inline-Perl6: review: https://github.com/niner/Inline-Perl6/commit/eaf6232cb2
15:11 ugexe is there a way to accept a single NQP type object? If I use '*@args' it will accept an NQP type object, but '$arg' will complain that, for example, expected 'Any' but got 'NQPMatch'?
15:11 ugexe m: use Perl6::Grammar:from<NQP>; use Perl6::Actions:from<NQP>; sub runme1 ($tree) { say $tree.HOW.name($tree); }; sub runme2 (*@trees) { for @trees -> $tree { say $tree.HOW.name($tree) } }; my $code = "my \$x; \$x++;"; my $*LINEPOSCACHE; my $tree = Perl6::Grammar.parse($code, :actions(Perl6::Actions.new())); runme2($tree); runme1($tree);
15:11 camelia rakudo-moar 3f26f9: OUTPUT«NQPMatch␤Type check failed in binding $tree; expected 'Any' but got 'NQPMatch'␤  in sub runme1 at /tmp/CH9BVjgo3y:1␤  in block <unit> at /tmp/CH9BVjgo3y:1␤␤»
15:12 ugexe runme2 takes the NQPMatch type, where runme1 does not
15:13 moritz ugexe: have ouy tried (Mu $arg) ?
15:14 ugexe that works. is that what *@ defaults to then instead of Any?
15:15 moritz ugexe: *@ simply doesn't do any type checking
15:16 huf mst: dunno, i feel like i was present for at least some of this sad pointless affair
15:16 telex joined #perl6
15:16 NewbiePig left #perl6
15:20 lizmat joined #perl6
15:20 geekosaur (backscrolling) ...this might be the first time I've ever seen haskell and java lumped together, even ironically...
15:20 Peter_R joined #perl6
15:22 huf i tried to say something bad about p6 that's on par with calling p5 awk/sed :)
15:22 huf adding "java" to something is a cheap win
15:24 nine Can I somehow nativecall a function that's provided by an already loaded library/the main executable?
15:24 moritz nine: is native(Str) iirc
15:25 FROGGS no, that will default to libc
15:25 nine moritz: that gives me a Cannot locate symbol 'init_call_method' in native library ''
15:26 kaleem joined #perl6
15:26 FROGGS nine: you have to provide the libname again, for every symbol you map
15:26 FROGGS nine: but don't worry, the library will only be loaded once
15:27 nine Or let me rephrase: I'd like to use NativeCall's ability to convert callbacks to C function pointers. Is there a way other than passing the callback to a function called via NativeCall?
15:28 nine FROGGS: I'm not worried about loading multiple times, it's more that I don't know the position of the library. But it's already loaded. And really I want just to have a function pointer that will make a call back into Perl 6 for me.
15:28 FROGGS nine: you have to load the lib via NativeCall, so much do I know
15:30 FROGGS or put differently: NativeCall needs to now the library handle, and you can't provide it in another way
15:44 nine Ok, I think I can get the position of the library from Dynaloader and should be able to pass it as a command line argument to Perl 6
15:44 nine So now there's just this darn libperl6_ops_moar.so problem left
15:45 gfldex joined #perl6
15:50 dalek DBIish: 488b924 | moritz++ | t/41-sqlite-exec-error.t:
15:50 dalek DBIish: Do not fail tests in libsqlite3 cannot be found
15:50 dalek DBIish: review: https://github.com/perl6/DBIish/commit/488b9245df
15:50 lizmat joined #perl6
15:51 dalek nqp: e489b4f | FROGGS++ | src/vm/parrot/6model/ (2 files):
15:51 dalek nqp: [parrot] add repr lookup for use in e.g. nqp_dyncall.ops
15:51 dalek nqp: review: https://github.com/perl6/nqp/commit/e489b4f87c
15:51 dalek nqp: 8d28eb2 | FROGGS++ | src/vm/parrot/ops/nqp_dyncall.ops:
15:51 dalek nqp: [parrot] allow to pass VMArrays (Blob) to native subs
15:51 dalek nqp: review: https://github.com/perl6/nqp/commit/8d28eb2570
15:52 skids joined #perl6
15:58 moritz fwiw I'd propose we drop Math::Model and Math::RungeKutta from start
15:58 moritz *star
15:58 moritz I don't think they are universally useful
15:59 moritz maybe add HTTP::UserAgent
15:59 mr-foobar joined #perl6
15:59 FROGGS +1
15:59 moritz though not for the January release
16:05 konsolebox joined #perl6
16:07 je5finger left #perl6
16:08 dalek rakudo/nom: 21ca410 | FROGGS++ | tools/build/NQP_REVISION:
16:08 dalek rakudo/nom: bump nqp rev for nativecast improvements on parrot
16:08 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/21ca410c5a
16:13 skids btw, FROGGS++, reupmoca++ I tried these changes last night and will be uploading C-bindings for libmhash to Sum within the next couple of days, probably.
16:14 FROGGS \o/
16:15 skids Still have the problem that Sum is supposed to work with or without NativeCall via pure-perl fallback, and that's seemingly hard to do.
16:16 skids But I figure better to have some fast checksumming for Star users.
16:17 FROGGS aye
16:17 FROGGS I guess we will come up with a proper fallback mechanism at some point
16:17 adu joined #perl6
16:17 skids Maybe the NativeCall Hackathon could spend some time on that problem. :-)
16:18 FROGGS that mind be too hard for the first hackathon :o)
16:22 _mg_ joined #perl6
16:24 firefish5000 joined #perl6
16:24 _mg_ Homebrew formula for rakudo-star is now updated to 2014.12.2: https://github.com/Homebrew/homebrew/commit/fe140668f9e8d59a6ede07bfead2324d4e83bd0c. Thanks to everyone involved and especially moritz for creating a new release.
16:24 anaeem1 joined #perl6
16:24 jnthn .oO( That's a bold statement... )
16:24 yoleaux 11:01Z <pmurias> jnthn: is there a way to determine if a static block will be used while deserializing closures (as a clone template)
16:24 _mg_ sorry, that was copy&paste
16:25 _mg_ not intended
16:25 jnthn .tell pmurias Well, you can scan the closures table and see if it shows up in there...
16:25 yoleaux jnthn: I'll pass your message to pmurias.
16:25 moritz you're welcome
16:26 pmurias jnthn: but I would need to load all the serialization contexts to do it
16:26 yoleaux 16:25Z <jnthn> pmurias: Well, you can scan the closures table and see if it shows up in there...
16:26 dalek nqp-js: a3e787a | (Pawel Murias)++ | src/vm/js/QAST/Compiler.nqp:
16:26 dalek nqp-js: Also add params to $*BLOCK.variables.
16:26 dalek nqp-js: review: https://github.com/pmurias/nqp-js/commit/a3e787aa01
16:26 dalek nqp-js: 28c6555 | (Pawel Murias)++ | src/vm/js/ (4 files):
16:26 dalek nqp-js: Pass test 56 roles.
16:26 dalek nqp-js:
16:26 dalek nqp-js: When deserializing contexts also restore values of lexicals.
16:26 dalek nqp-js: review: https://github.com/pmurias/nqp-js/commit/28c6555c9a
16:26 FROGGS jnthn: I solved the issues that I had last night btw (about nqp@parrot and nativecall)
16:27 FROGGS jnthn: this was buggy code that led me on the wrong track: https://github.com/perl6/nqp/commit/8d28eb2570#diff-8930b15bad323ac0e04e12ded5875a7eL888
16:28 jnthn FROGGS: Ah, cool. I was teaching git all day and didn't backlog yet
16:28 FROGGS jnthn: the repr id for P6int etc was zero :/
16:28 pmurias jnthn: in the closure table it's possible to refer to static code refs from other serialization contexts
16:28 jnthn pmurias: oh, yeah
16:29 jnthn pmurias: Your question was probably on the "other side" of the fence...
16:29 jnthn Like you want to avoid doing something 'cus something could never possibly be closured. No, I don't know there's an easy way to do that.
16:31 dalek star: 33df4da | moritz++ | modules/zavolaj:
16:31 dalek star: Downgrade zavolaj to a version that works with 2015.01
16:31 dalek star: review: https://github.com/rakudo/star/commit/33df4dab19
16:31 dalek star: 9f2a9a3 | moritz++ | modules/DBIish:
16:31 dalek star: Bump DBIish version
16:31 dalek star: review: https://github.com/rakudo/star/commit/9f2a9a3f4b
16:31 dalek star: c46312a | moritz++ | docs/announce/2015.01.md:
16:31 dalek star: Add release announcement for 2015.01
16:31 dalek star: review: https://github.com/rakudo/star/commit/c46312ab4f
16:31 moritz feedback on the release announcement very welcome
16:37 dalek nqp-js: 48c3ae9 | (Pawel Murias)++ | t/qast/02-manipulation.t:
16:37 dalek nqp-js: Add a (partial) test for various methods used for handling qasts.
16:37 dalek nqp-js: review: https://github.com/pmurias/nqp-js/commit/48c3ae91aa
16:38 moritz m: say $*VM.name
16:38 camelia rakudo-moar 21ca41: OUTPUT«moar␤»
16:38 moritz p: say $*VM.name
16:38 camelia rakudo-parrot 21ca41: OUTPUT«parrot␤»
16:38 pmurias jnthn: currently I can live with emitting some needless stuf
16:38 pmurias * stuff
16:39 dalek doc: c90029d | moritz++ | t/typegraph.t:
16:39 dalek doc: Skip segfaulting tests on parrot
16:39 dalek doc: review: https://github.com/perl6/doc/commit/c90029d860
16:41 FROGGS moritz: that's not a "D", is it? https://github.com/rakudo/star/commit/c46312ab4f#diff-1b9b836ba8f34e9dd09249182ef77092R41
16:44 dalek star: ab4f6ad | moritz++ | docs/announce/2015.01.md:
16:44 dalek star: Remove accidental use of non-ASCII character, FROGGS++
16:44 dalek star: review: https://github.com/rakudo/star/commit/ab4f6adbb8
16:47 moritz I seem to have problems getting the submodules into a new clone of star
16:47 moritz I've done a git clone --recursive git@github.com:rakudo/star.git
16:48 Guest22147 joined #perl6
16:48 moritz and modules/*/ are all empty directories
16:48 Guest22147 hi @all
16:48 moritz hi Guest22147
16:49 moritz oh, seems I'm missing 'git submodule update'
16:49 Guest22147 I am not familliar with irc
16:49 Guest22147 hmm /help does no longer work. How can I change my nickname?
16:50 moritz Guest22147: /nick <newnickname>
16:50 p6_newbee ha, thanks
16:50 * p6_newbee is dancing
16:50 Rounin joined #perl6
16:51 FROGGS hi p6_newbee :o)
16:52 FROGGS moritz: I can't find anything else to criticize :o)
16:52 moritz FROGGS: thanks, wonderful
16:52 p6_newbee hi FROGGS
16:53 dalek star: 99a2768 | moritz++ | .gitmodules:
16:53 dalek star: Try to complete the renmaing of rakudo-debugger
16:53 dalek star: review: https://github.com/rakudo/star/commit/99a2768f7d
16:54 pmurias jnthn: what is an easy way to turn Perl 6 into QAST? (so I can see how much work nqp-js needs to run simple Perl 6)
16:54 jnthn pmurias: --taret=ast ?
16:54 jnthn uh, target
16:55 pmurias and for an actual QAST object?
16:55 sqirrel_ joined #perl6
16:56 pmichaud moritz/others:  We might need to get some advance notice in to star release notes about moving from parrot to moarvm
16:57 moritz pmichaud: why? people who want parrot still can use the older versions
16:57 dalek star: 7ab973e | moritz++ | docs/announce/2015.01.md:
16:57 dalek star: Remove module update item that was copied from last month
16:57 dalek star: review: https://github.com/rakudo/star/commit/7ab973edf2
16:57 pmurias m: my $c = nqp::getcomp('perl6'); $c.compile(:target<ast>, '1')
16:57 camelia rakudo-moar 21ca41: OUTPUT«===SORRY!===␤compunitmainline requires an MVMCompUnit␤»
16:57 moritz pmichaud: that said, I'm in the progress of releasing star 2015.01. If we want to get some notices in, now would be a perfect time
16:57 pmurias jnthn: the naive approach causes a  MoarVM error
16:57 pmichaud moritz: yes, that's why I'm bringing it up now
16:58 pmichaud I'm currently working on a summary of FOSDEM discussions for publication, but haven't had a chance to complete it yet
16:58 pmichaud the short version is that Rakudo will likely suspend its Parrot support starting with the March release...  i.e., the February Rakudo release may be the last one supporting parrot for a while
16:59 moritz pmichaud: I have planned to wait at least one more day anyway
16:59 jnthn pmurias: If you're after the object then you can pass :target<ast> to .compile, iirc.
16:59 ugexe m: use Perl6::Grammar:from<NQP>; use Perl6::Actions:from<NQP>;  my $code = "my \$x; \$x++;"; my $*LINEPOSCACHE; my $tree = Perl6::Grammar.parse($code, :actions(Perl6::Actions.new())); my $ast = $tree.ast; say $ast.HOW.name($ast);
16:59 camelia rakudo-moar 21ca41: OUTPUT«QAST::CompUnit␤»
17:00 jnthn ugexe++
17:00 moritz pmichaud: I'm interested in the rational for supporting it still in the February release, but I'll be happy to wait for your publication if you don't want to repeat yourself
17:00 pmurias ugexe: thanks
17:00 pmichaud moritz: only that I don't think we should announce we're suspending support without having at least one more release afterwards
17:01 pmurias did you talk with rurban about suspending parrot support?
17:01 moritz pmichaud: on a sentimental level, I can understand that (moer)
17:01 pmichaud also, at least from a GLR perspective, there's no reason to rip things out before the february release.  March and/or April will be the first affected releases.
17:01 moritz pmichaud: 6pe will produce extra work on parrot, afaict
17:02 jnthn moritz: The work is already done...
17:02 moritz jnthn: ok
17:02 jnthn It's the native stuff that will be more painful
17:02 jnthn And that I won't port
17:02 moritz jnthn: and do you think that will block you before the Feb release?
17:02 FROGGS jnthn: leave the non-design stuff for other I'd say
17:02 jnthn Well, not working on it, no.
17:03 pmichaud pmurias: I don't think specific discussions have been started with rurban yet... most of this has just happened within the last 5 days
17:03 jnthn I'm gonna be working on a branch.
17:03 FROGGS others*
17:03 jnthn I can always wait until after Feb release to merge it.
17:03 pmichaud From a Rakudo Star perspective, it's possible that Rakudo Star will want/need to stick with an older version of Rakudo while the ecosystem and end-users migrate
17:04 jnthn In the unlikely event I really have taken care of all the corners way ahead of it, the unmerged branch still doesn't block me from digging into NFG... :)
17:04 pmurias didn't all the users migrate to moarvm already?
17:04 moritz pmichaud: I don't see much need for migration
17:04 nine distro packages?
17:04 moritz pmichaud: most everybody already uses MoarVM, and the start 'modules-test' consistently has better results on moar than on parrot
17:04 pmichaud moritz: how can you say that?
17:04 pmichaud It's not just migrating to moarvm, it's migrating to a post-glr rakudo
17:04 moritz pmichaud: oh yes
17:05 moritz pmichaud: that's a different thing, and migration will be required
17:05 pmichaud right, and rakudo star's philosophy is stability over newness
17:05 pmurias any large planned changes on the lower level that might affect nqp-js?
17:05 FROGGS let's decide to ship an old pre/post-glr rakudo when that time is there I'd say... perhaps it is smoother then we think :o)
17:05 moritz aye
17:05 pmichaud and rakudo star explicitly chooses to stick with older versions of the compiler to emphasize continuity and stability
17:06 [Sno] joined #perl6
17:06 FROGGS at least, we need the right tooling to know about the fallout at that time
17:06 jnthn pmurias: 6pe is not a hard port to nqp-js, I doubt. The native references might be trickier.
17:06 moritz also we can decide to pause post-GLR rakudo star release
17:06 moritz until the ecosystem has caught up
17:06 pmurias jnthn: native references?
17:07 pmichaud yes, we can post post-glr rakudo star release, but it's better if we give an announcement to that effect before doing the actual pause
17:07 jnthn pmurias: References to native lexicals/attributes/array elements.
17:07 pmichaud i.e., if we can say "substantial changes are coming to the rakudo compiler, so rakudo star may lag compiler development after feb 2015"
17:07 pmurias jnthn: is it a rakudo things also also something in nqp?
17:08 moritz pmichaud: +1
17:08 jnthn pmurias: It'll need doing at NQP level
17:08 pmurias s/also also/also something
17:08 jnthn pmurias: Rakudo will use it.
17:08 pmichaud thus I'm working on a recap and announcement about parrot support lagging after february 2015 release
17:09 moritz pmichaud: will you patch the star 2015.01 release announcement too?
17:09 jnthn pmurias: I'll have a better feel for likely nqp-js impact after I've done it.
17:09 moritz pmichaud: I have a feeling that you'll formulate it better than I might
17:09 btyler suggestion from a bystander: it might be a good idea to be a little more aggressive/pushy about introducing big changes into the ecosystem this year compared to previous years
17:09 pmichaud moritz: I'll see if I can do that.  My schedule the next two weeks is really crowded with non-p6 stuff.  :-/
17:10 pmichaud btyler: noted
17:10 moritz pmichaud: ok; if nothing is in by the time I want to release, I'll write somthing myself
17:10 pmichaud moritz: eta to release?
17:10 moritz pmichaud: tomorrow or Thursday
17:10 pmichaud okay.  I'll try to have something in by tomorrow.
17:11 Mouq joined #perl6
17:11 moritz timotimo: your star commit 83c8150c8685cc6582a703ebebcaab56bc679d8c ("rename rakudo-debugger folder to reflect module name change") seems to cause problems. I get No submodule mapping found in .gitmodules for path 'modules/rakudo-debugger when doing a 'git submodule update' after a fresh star clone
17:11 pmichaud on another note, can I caution people about phrasing of "the [6.0] release"?  I'm starting to see a lot of talk and blog posts talking about "the release" that are imprecise and ignore the fact that we already make releases.
17:12 FROGGS[mobile] joined #perl6
17:12 btyler that distinction is a tough one to impress upon people even inside the perl community. outside I think it is hopeless without some pretty serious PR work
17:12 pmichaud In particular, MDK's review of the FOSDEM announcement makes repeated references to "Version 1.0 of Perl 6" and I don't know that there will be any such animal.
17:13 fhelmberger joined #perl6
17:13 FROGGS[mobile] how shall we call it?
17:13 nwc10 "General Availability"
17:13 nwc10 ?
17:13 pmichaud I don't know what to call it yet.  I think "Version 1.0" and "the release" are bad choices.
17:14 pmichaud also, I fear that "Version 1.0 of Perl 6" confuses language spec and compiler implementation again.
17:15 pmichaud it's just a caution at this point -- I don't want us to lapse into adopting the outside world's view of how language/compiler development is to be structured.
17:15 moritz +1
17:15 nwc10 +1 +2 +3 +5
17:16 nwc10 given there is language spec, compiler implementation, link level compatibility (or whatever "binary compatiblity" means), which VM, and VMs have their own idea about versioning.
17:16 mst pmichaud: sure, but larry called it 6.0.0 without making the distinction; mdk was just trying to distinguish between 'perl6' and 'the first complete release thereof'
17:17 mst if we had an official #perl6-sanctioned set of language, I'd be happy to go and smack anybody who didn't use it
17:17 pmichaud mst: we're still developing that language ourselves :)
17:17 mst but I think 'perl6 1.0' is less awful than 'perl 6.0.0'
17:17 pmichaud and no, this isn't intended as a smack on mdk at all.
17:17 mst since while it misses the compiler/spec distinction, it at least makes it clear that perl6 is a language in its own right
17:17 pmichaud it's just a reminder to the perl6 bubble that we really need to get our sanctioned set of language in place
17:18 pmichaud because if we don't, then the outside world will end up defining our terms for us :)
17:18 mst I mean, I'd like to see something like "this is Rakudo $compiler_version, an implementation of the Camelia Perl6 specification version $spec_version"
17:19 mst but exactly which 'something like' is for you guys to decide and then document
17:20 pmichaud mst: +1
17:21 pmichaud in particular, I think we may want to be very careful about tying language releases to a given compiler's release
17:22 mst right. I did worry a little when the keynote seemed to imply that the spec will be defined by the passing rakudo test suite at first release
17:22 * moritz thinks that's a very pragmatic approach as long as we only have one actively-developed compiler
17:23 masak pmichaud: +1 http://irclog.perlgeek.de/perl6/2015-02-03#i_10053434 -- this
17:23 mst however it's also a great way to only ever have one actively-develoiped compiler if you aren't careful
17:23 FROGGS[mobile] it is more like we define the right set of tests that define what a Perl 6.0.0 compatible compiler has to pass
17:26 mst there should never be any such thing as 'Perl 6.0.0'
17:26 mst there should be 'Perl 6 1.0'
17:26 mst otherwise the whole version number drama is going to explode again, and I am going to cry
17:26 FROGGS[mobile] I am looking forward to a bugfixathon btw
17:26 mst and it'll become 10x harder to encourage people invested in perl5 to regard perl6 as a good thing rather than a threat
17:27 pmichaud I think I agree that "6.0.0" isn't a good path for version numbering.
17:27 itz_ 15-12
17:27 pmichaud I'm wondering how often we expect there to be language updates
17:28 FROGGS[mobile] in the next 30+ years?
17:28 jnthn itz_: 3
17:29 MadcapJake joined #perl6
17:29 nine jnthn: I've made some tiny progress using LD_DEBUG=all. Seems like libmoar.so is loaded and tons of symbols are bound but MVM_frame_inc_ref seems to be missing.
17:30 jnthn nine: Oh? Odd...
17:30 Kristien joined #perl6
17:31 nine jnthn: there may be others, but this one is the first missing and then it barfs
17:31 Kristien hi
17:31 mst /* 1 if by land, 2 if by sea, 0 if out of memory, not allowed to barf */
17:32 jnthn nine: Does looking at the libmoar.so symbols (maybe with nm) show it?
17:33 xinming_ joined #perl6
17:34 * japhb catches up with backlog ...
17:35 japhb *If* Larry really wanted a 6.0.0-shaped version number for the spec, I'd push for 6.1.0, for the reasons that _sri, mst, et al. stated.
17:35 nine jnthn: yes, and it has to, since LD_PRELOADing libmoar.so "fixes" the problem. I guess the dynamic loader is just loading the symbols that are needed by the executable loading it unaware of a library dlopen'ed later that would need moar.
17:36 pmichaud I'm wondering if language spec should be more C99/C89/C11 ish
17:36 japhb I'm mildly hesitant about using year.month-style naming for the *spec*, because it gives the impression that the spec will be changing so fast even after Christmas that we'll still be altering it every month.
17:36 pmichaud japhb: year.month doesn't have to imply monthly release.  See ubuntu.
17:36 japhb (Which, for 2016, we actually might ...)
17:36 itz_ 15Q4
17:36 pmichaud I'm wondering if even just doing something like   "Perl6 2015a"
17:36 japhb pmichaud: Yes, but that's a distro, parallel to R*.  I'm talking about the *spec*
17:36 japhb That actually seems reasonable.
17:37 pmichaud more to the point, I think we need to consider that language evolution has (should have) a different speed from compiler/implementation evolution
17:38 japhb Re: Fast conversion between Num and Buf:  Please?  Pretty Please?  With Whipped Cream on Top?  :-)
17:38 japhb pmichaud: yes, that.
17:38 pmichaud or at least a different cadence.
17:38 pmichaud and in that context, the traditional   "6.major.minor" sequence doesn't quite fit the cadence
17:39 japhb pmichaud: I like your "Perl6 2015a" idea.  Possibly in "Perl 6 2015a" form.
17:39 nine nwc10: maybe you have an idea? I'm trying to use libmoar.so in an XS module. MoarVM starts up and dlopens libperl6_ops_moar.so which fails because it cannot find some symbols that are in libmoar.so. LD_PRELOADing libmoar.so makes the error go away.
17:39 virtualsue joined #perl6
17:41 itz_ XmasRoast15
17:41 japhb Re: NativeCall in core: +1.  I understood it being separate during initial development, but now it is deeply tied in at multiple levels of the stack, and necessary for lots of normal things (and is an expected part of the language).  Having it out of core no longer makes a lot of sense, IMO.
17:42 colomon +1 (assuming no major technical objections)
17:44 jnthn japhb: Do you mean "in CORE.setting" or "shipped with Rakudo"?
17:45 virtualsue_ joined #perl6
17:49 moritz fwiw I mean "shipped with Rakudo"
17:49 moritz doesn't need to be CORE.setting, IMHO
17:50 japhb jnthn: I mean shipped with Rakudo.
17:50 jnthn OK, I think I'd be OK with that. It'd still need a "use" decl that way.
17:50 El_Che pmichaud++ for the ansi C inspired for specs
17:51 El_Che pmichaud: on the other hand, don't say spec! ;)
17:51 jnthn dinner &
17:53 japhb jnthn: Oddly, there's a part of me (normally adverse to pointless includes), that *wants* to see a "use NativeCall" declaration ... because this tells me a lot about what to expect in the following code.  Puts me in the right headspace and prepares me to think in C-ish ways.
17:54 pmichaud El_Che: saying "spec" is perfectly valid, as long as one is actually referring to "the spec" and not something else
17:54 PerlJam So ... is there going to be a simultaneous "spec release" with the "official compiler" release?
17:55 * pmichaud throws a million Koosh Balls at PerlJam's head
17:55 japhb .oO( The spec releases on Tuesday on months where it's needed, and the compiler releases on Thursday every month )
17:55 PerlJam ... and because I'm such a good juggler, they are all redirected  :)
17:56 pmichaud I have no clue where this term "official compiler" came from, but it needs to be killed dead Dead DEAD.
17:56 japhb Man, I should practice my juggling.  Been a while.
17:58 Mouq NativeCall seems like an important enough part of Perl 6 that we might want to consider testing it in Roast/spectest
17:58 yoleaux 11:29Z <moritz> Mouq: t/spec/S32-exceptions/misc.t dies with "Could not find symbol '&Invalid'"; I suspect you were involved
17:58 yoleaux 11:31Z <moritz> Mouq: never mind, I mixed up branches
17:59 itz_ reference compiler?
17:59 PerlJam Mouq: S21 may need a little more love too
17:59 pmichaud I don't believe that Rakudo will be the reference compiler.
17:59 moritz itz_: it compiles references to broken links on perl6.org :-)
18:00 pmichaud also, "reference compiler" has all sorts of incorrect interpretations
18:00 Mouq "most popular and feature complete compiler" isn't very catchy though :9
18:01 PerlJam heh
18:01 pmichaud sure, but catchy is good only if it doesn't also imply all sorts of unwanted inaccuracies
18:01 moritz "#perl6 recommended compiler"
18:01 pmichaud if someone says "Rakudo (or Niecza) is the reference compiler", that implies that it's somehow authoritative about the language spec.  And it's not.
18:01 itz_ leastbroken compiler
18:02 PerlJam itz++
18:02 PerlJam pmichaud: but that's what people want.  That's what they are looking for.  That's why no one believes that the monthly rakudo releases are "real"  (IMHO)
18:03 pmichaud PerlJam: Just because people want something doesn't mean we should give it to them, especially if it will lead to problems later.
18:03 moritz or maybe because we continue to label them as "Development Release"
18:04 pmichaud clearly once Rakudo is passing some level of Perl 6 language spec we can remove the "development release" moniker.
18:04 pmichaud I'd even be willing to remove that notion once GLR/NSA/NFG are done.
18:04 moritz (and the star relases as "early adopter")
18:05 dalek doc: 3570802 | moritz++ | lib/Type/Routine.pod:
18:05 dalek doc: remove a done TODO item
18:05 dalek doc: review: https://github.com/perl6/doc/commit/3570802792
18:07 pmichaud I think a lot of people want compiler-and-language-tied-together because that's what they're used to with Perl 5 (and other languages also).  They want to believe that there's an official implementation that they can trust forever and ever.
18:07 nige joined #perl6
18:07 pmichaud if we encourage that belief, we're doing them (and the language and community) a huge disfavor
18:08 japhb What about "leading compiler"?  This has been used in the marketing world both to claim plurality market share, and to intentionally avoid claiming monopoly marketshare.  Both of which actually seem to be sentiments I hear.
18:08 japhb ... regarding Rakudo, I mean.
18:08 PerlJam pmichaud: agreed.  But you still have to communicate with them in ways they understand.
18:09 b2gills #naming I think that "Perl 6.0.0" (or "Perl 6 2015-02" or "Perl 6 2015a" ...*) is the language version, and any implementations are free to use whatever numbering/naming convention they choose ( as long as it can't easily be mistaken for the language version, or being the one true implementation )
18:09 pmichaud PerlJam: but not necessarily by adopting (or promoting) their worldview in the process
18:10 pmichaud b2gills: yes, that's always been the way it's worked.
18:10 pmichaud "Perl 6" is the language, never an implementation.
18:10 japhb .oO( Rakudo, the leading compiler for the Perl 6 language, is proud to present its 2015.12 release, compliant with version 2015a of the Perl 6 language specification. )
18:10 ribasushi pmichaud: while defining the distinction it is also quite important to state upfront what is considered a "camelia-compatile interpreter"
18:10 ribasushi there was a lot of FUD surrounding the python family (python / ironpython /jython / others)
18:11 b2gills japhv: exactly .++
18:11 pmichaud ribasushi: a camelia-compatible interpreter is one that passes the set of tests defining Perl 6
18:11 ribasushi due to not supporting exactly the same set of things when the language itself is concerned (battery-inclusion aside)
18:11 pmichaud this is exactly what Synopsis 1 says :)
18:12 japhb Hmmm, that was a thought bubble, but let me continue to edit ...
18:12 b2gills .oO( I haven't read the Synopsis in a while )
18:12 japhb .oO( Rakudo, the leading compiler for the Perl 6 language, is proud to present its 2015.12 release, compliant with version 2015a of the Perl 6 language specification test suite. )
18:13 ribasushi pmichaud: I meant as part of the announcement / introduction doc / the "perl5/6/11/WAT" FAQ page / stuff like that
18:13 japhb Does that ^^ language actual match peoples' intent?
18:13 moritz .oO( This is Rakudo 2015.12, targetting the Perl 6 2015.12 language )
18:13 japhb moritz: That sounds like a README intro, not a release announcement, which is what I was aiming for.
18:13 pmichaud japhb: yes, that matches the intent.  The harder part is declaring a Perl 6 release
18:13 PerlJam japhb: you could draft the Christmas release announcement with that text and I wouldn't be unhappy  :)
18:13 japhb In order to think about how we would talk to the world outside our echo chamber.
18:14 pmichaud japhb: you gave a compiler release, not a language release.
18:14 japhb Ah, OK, let me try that.
18:14 moritz "This is Perl 6 2015.12, a set of language design documents and tests"
18:14 pmichaud also, per my fosdem talk, we really need to digest the notion that language spec releases need to be retrospective, not future-spective
18:14 moritz maybe with the order reversed
18:15 moritz pmichaud: have you put up the slides somewhere?
18:15 pmichaud not yet, I will do that in ~30m
18:15 japhb .oO( The Perl Foundation is proud to announce the completion of version 2015a of the Perl 6 language specification test suite. )
18:15 PerlJam japhb: "completion"?
18:15 japhb Yeah, that word I don't like either.
18:15 pmichaud publication
18:16 * japhb ruminating on a replacement
18:16 PerlJam japhb: what pm said
18:16 japhb pmichaud: yeah, publication sounds better
18:16 El_Che pmichaud: If ok, i'll put it in the fosdem page (as I wrote in the mail)
18:16 japhb .oO( The Perl Foundation is proud to announce the publication of version 2015a of the Perl 6 language specification test suite. )
18:16 pmichaud El_Che: yes, it's okay.  it's on my laptop and I don't have that in front of me at the moment.
18:16 pmichaud japhb: now, tie it to compilers
18:17 pmichaud .oO( This version of Perl 6 is known to be implemented by the Rakudo-MoarVM compiler...)
18:17 El_Che pmichaud: great
18:17 nwc10 pmichaud: I'm strugging to find a good way to tersely say what I'm nebulously thinking, but I think that the "language spec should be more C99/C89/C11 ish" is $good
18:17 japhb pmichaud: Yeah, that seems close to what I was thinking.
18:17 nwc10 it was close to what I'd been sort of thinking of from another direction
18:17 nwc10 which was how to stop people being afraid of upgrading
18:17 pmichaud let me dig up my laptop and get my slides published
18:18 pmichaud I don't know that my talk was recorded successfully at FOSDEM.  Perhaps I should record it myself
18:18 pmichaud as in re-record and publish for this group
18:18 nwc10 for which I think one needs to decouple the concept/warm fuzzy feeling of "What version of the language did I write my code in?" with "what is going to be able to run it and make money?"
18:19 japhb .oO( Rakudo-MoarVM, the leading Perl 6 compiler, is expected to be fully compliant with this version of Perl 6 in its upcoming 2015.12 release. )
18:19 FROGGS joined #perl6
18:19 El_Che pmichaud: I think you talk was ok. I fear for one of the later talks as the wireless micro battery had to be replaced :(
18:19 nwc10 because currently there's this big fear (I think in all the dynamic languages) that upgrading your compiler-runtime-interpreter (all as one) is a major event, which you don't want to do
18:19 pmichaud japhb: maybe, except that I (now) think that language spec will come after language implementation, not before
18:19 pmichaud I really think we need to break the cycle of believing that specification comes first.
18:19 nine Could someone please have a look at this PR and tell me if it's sane and/or mergeable? https://github.com/rakudo/rakudo/pull/359
18:20 japhb pmichaud: Hmmmm, OK, how about
18:20 japhb .oO( Rakudo-MoarVM, the leading Perl 6 compiler, reached full compliance with this version of Perl 6 in its 2015.09 release. )
18:20 PerlJam japhb++
18:20 El_Che fosdem used a technically better and new video recording system (with a new video team). Sadly there were many problems
18:20 nwc10 how many of the ISO specified languages had the spec come first?
18:21 pmichaud japhb: "reached" is wrong.
18:21 pmichaud japhb: it still implies that language spec came before implementation
18:21 nwc10 the C, C++ and Ruby specs certainly postdate language implementations
18:22 nwc10 (Ruby is technically still a draft spec, isn't it?)
18:22 * PerlJam didn't even know ruby had a spec
18:22 japhb nwc10: I think the usual thing is compilers implement idea, idea becomes draft spec, compilers release with compliance with draft spec, spec gets final tweaks, compiler releases a final compliance release (which may actually be the release they are implementing the *next* draft idea in)
18:22 pmichaud nwc10: basically every (successful) language since ALGOL68 had its spec published after it was implemented
18:22 vendethiel nwc10: I don't even think it exists.
18:22 vendethiel if you'retalking about rubyspecs, it's abandoned
18:22 pmichaud japhb: that's not the usual thing at all
18:22 b2gills We certainly need various ways of describing version numbering/naming depending on how terse/verbose the surrounding context is ( "perl6 -v" vs. Release announcements )
18:23 pmichaud japhb: in particular, "idea becomes draft spec" usually happens 10+ years after "compilers implement idea"
18:23 japhb pmichaud: That's what I've seen as an observer from the outside, never a spec committee member.  Maybe they had poor PR communication as well?  :-)
18:23 nwc10 vendethiel: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=59579
18:23 nwc10 aha, "Preview"
18:23 japhb pmichaud: Oh, I had no intent about timing between stages.
18:24 pmichaud japhb: there's a popular myth that things are specified before they're designed and implemented.  Academically, that's nice.
18:24 nwc10 but it will still cost you CHF 198 to see even that
18:24 japhb And actually, I was thinking about all kinds of technical specs, from WiFi to C++.
18:24 pmichaud In reality, it doesn't happen that way.
18:24 japhb pmichaud: Agree that that's a myth.
18:24 pmichaud Most notably, Internet Specifications happen only after there are two independent implementations of whatever they specify.
18:24 PerlJam nwc10: so the next question is ... when will Perl (5 or 6) get an ISO spec?   :)
18:24 japhb Sadly in some fields, it just seems like who's the biggest bully in the spec committee, pushing the thing they already implemented.
18:25 pmichaud (actually called "Internet Standards")
18:26 japhb Do we want to indicate that Rakudo is special enough that what it implements is used as the basis of the spec?
18:26 pmichaud So, any idea that we've designed a specification first, and there are implementations working to keep up with the specification...  well, that's a model that's proven to fail.
18:26 japhb Nodnod
18:27 pmichaud I have trouble with the "special enough" moniker.
18:27 pmichaud So no, I don't want to indicate that.
18:28 japhb .oO( This version of Perl 6 was first implemented by release 2015.09 of Rakudo-MoarVM, the leading Perl 6 compiler. )
18:28 pmichaud There's no reason that something implemented in a Pugs or Niecza couldn't be used as the basis for spec.
18:28 pmichaud is "first implemented" important?
18:28 pmichaud I don't think it is.
18:28 japhb .oO( This version of Perl 6 is implemented in release 2015.09 of Rakudo-MoarVM, the leading Perl 6 compiler. )
18:29 pmichaud and is it important to talk of a "leading Perl 6 compiler"?
18:29 japhb I actually think that one is.
18:29 pmichaud why is this being viewed in terms of a race, or competition, or ... ?
18:29 pmichaud "popular", maybe.
18:29 japhb For the plurality-but-not-monopoly aspect I was referring to.
18:29 japhb s/leading/most popular/?
18:30 pmichaud why the superlatives?  ("the most popular", "the leading", ...)
18:30 pmichaud it sounds like trying to annoint one compiler over others
18:30 pmichaud might as well just call it "official" if you're going to do that.
18:30 japhb For the reasons that others brought up about marketing communications.
18:30 ugexe perl6 ecosystem seems to be missing MIME::Base64?
18:30 itz_ "suggested"?
18:30 skids Well, you don't want interested people going and somehow managing to download pugs.
18:30 japhb And you wanted to tie the compiler and the spec, yes?
18:31 pmichaud If we're looking at a language release announcement, people are going to want to know where they can go download an implementation.  That's the only reason for the "tie"
18:31 pmichaud I'm fine with "recommended"
18:31 japhb I'm trying to avoid the release announcement making Rakudo sound like the Amaya of Perl 6 compilers.
18:32 japhb .oO( This version of Perl 6 is implemented in release 2015.09 of Rakudo-MoarVM, the recommended Perl 6 compiler. )
18:32 japhb Sounds a little stilted
18:32 FROGGS the language version could be as short as: Perl 6/15
18:32 ugexe yeah no MIME::Base64 anymore in http://ecosystem-api.p6c.org/projects.json
18:32 FROGGS and when there is a sub-year release, it would be Perl 6/15.1
18:33 rindolf joined #perl6
18:33 PerlJam FROGGS: that will morph into 6.15 and 6.15.1 methinks
18:35 * FROGGS .oO( perl6-m --version could be  "Rakudo Perl 6 2015.12 on MoarVM 2015.11 compliant to Perl 6/15" )
18:35 FROGGS a version triplet of not quite version triplets :o)
18:36 dalek Inline-Perl6: 2fc6bde | (Stefan Seifert)++ | / (4 files):
18:36 dalek Inline-Perl6: Clean up unused code and tries to fix linking
18:36 dalek Inline-Perl6: review: https://github.com/niner/Inline-Perl6/commit/2fc6bdeca0
18:36 japhb .oO( This version of Perl 6 is implemented in release 2015.09 of Rakudo-MoarVM and release 3.1415 of FooBarBaz. )
18:36 FROGGS 6/15 looks too much like 08/15 though
18:36 japhb Agreed
18:36 pmichaud I don't know that I'd have a problem with 6.15 as a language spec number, though.
18:36 pmichaud It certainly makes things like 5.22 look more "normal"
18:36 FROGGS ... and we're not sponsored by Stark Industries™ :o)
18:37 pmichaud on the other hand, it might bring about the 6 > 5 issues again, and we should avoid that.
18:37 PerlJam pmichaud: "But which versino of Perl should I use, 5.22 or 6.15?"
18:37 FROGGS I like the way C99 is including a year
18:37 pmichaud well, Perl 5 is essentially doing year numbers now :)
18:37 pmichaud it's just there's a built in offset, and they increment the number by 2 each year
18:37 _mg_ joined #perl6
18:39 pmichaud 2010:  5.12;  2011: 5.14;  2012: 5.16;  2013: 5.18;  2014: 5.20
18:39 b2gills $*VERSION.triplet-str eqv ("Rakudo 2015.09", "MoarVM 2015.11", "Perl 6/15")
18:40 itz_ I think 6.15 and 6/15 look too much like math operations
18:41 PerlJam itz_: that's a feature!  :)
18:41 pmichaud I still prefer "Perl 6 2015a" over "6/15"
18:41 japhb .oO( The Perl Foundation is proud to announce the publication of version 2015a of the Perl 6 language specification test suite.  This version of Perl 6 is known to be implemented in release 2015.09 of Rakudo-MoarVM and release 3.1415 of FooBarBaz. )
18:41 b2gills I was just thinking out loud
18:41 japhb Latest iteration ^^
18:41 moritz pmichaud: any reasons not to use YYYY.MM for the language version?
18:42 pmichaud I don't know that there will be many .MM's in a year.
18:42 pmichaud I think language specification should be slow and deliberate
18:42 pmichaud if we're publishing more than two per year, that'd be... odd.
18:42 * FROGGS .oO( "Moony, Wormtail, Padfoot and Prongs are proud to..." )
18:43 pmichaud Perhaps with a test-suite-based language spec it could be more often than twice per year.
18:43 japhb I think that if we're not doing rapid language releases (for some reason), we really shouldn't imply it -- because it makes people think "OMG churn!"
18:43 japhb FROGGS: EXACTLY
18:43 FROGGS pmichaud: I was about to say that
18:43 b2gills Perhaps the language version could be 2015, '2015a' ... *
18:43 itz_ 2015a is good
18:43 pmichaud but language spec should ratify decisions already made and tested
18:44 pmichaud more to the point, tested by implementations and in "production"
18:44 japhb What about the wording I posted about 3 min ago?
18:44 FROGGS we cant implement without tests, and we cant spec without a proven implementation... there will be spec releases like compiler releases
18:44 pmichaud japhb: it looks okay to me, but I'm not wanting to ratify an announcement today.  Certainly not before we've decided what language spec looks like.
18:44 japhb Oh sure!
18:45 nwc10 I don't think that it will make sense to publish lots of small incremental language specs, as any (good) compiler needs to implement each and every spec, and even if code is mostly re-used, there's O(n) testing per compiler release and O(n²) cumulative
18:45 moritz also it's weird to speak in terms of TPF, when TPF isn't really involved
18:45 FROGGS japhb: but yeah, it has the right announcish character :o)
18:45 japhb I mostly was wanting to get a concrete wording implementation to test our plans.  :-)
18:45 japhb moritz: I thought TPF owned the copyright?
18:45 moritz japhb: of what, exactly?
18:46 japhb The test suite?
18:46 japhb I hadn't actually checked
18:46 itz_ maybe it should be SR? :) http://shire-reckoning.com/calendar.html
18:46 moritz japhb: no
18:46 japhb Who does?
18:46 moritz japhb: the roast contributors
18:46 pmichaud http://pmichaud.com/2015/pres/fosdem-specs/fosdem-specs-1.pdf
18:46 moritz japhb: the former wording was "the pugs contributors" :-)
18:46 japhb Oh, hmmm.
18:47 moritz we don't require a CLA for roast
18:47 japhb That's ... suboptimal at this point, if technically accurate.
18:47 pmichaud there's nothing to prevent TPF from announcing that Perl 6 has been published.
18:47 pmichaud they don't have to own something to issue a press release about it.
18:47 moritz agreed
18:47 japhb True ...
18:48 nwc10 sometimes it's quite hard to coax them into issuing a press release for something that is being published.
18:48 FROGGS and there is nothing against being proud :o)
18:49 japhb OK, am I correct in thinking we have rough consensus now, with possibly an objection or two to '2015a' as the exact form of the version number?
18:49 FROGGS let's sleep over it
18:49 japhb (I *don't* object, FWIW)
18:49 japhb Fair enough.
18:49 pmichaud also, it's possible for TPF to own the "collective work" that is the subset of roast defining Perl 6
18:49 pmichaud without having to own any of roast itself.
18:50 japhb pmichaud: Is that USA-specific, or worldwide agreed?
18:50 japhb (Well, to the extent that anything regarding IP has agreement)
18:50 pmichaud afaik the US follows the Berne copyright convention for the most part
18:50 japhb nod
18:50 pmichaud regardless, one can have copyright on a collective work without having to own copyright on every piece of the collection.
18:51 japhb Fair enough.
18:51 p6_newbee bye @ all
18:51 pmichaud I suspect that's fairly typical of standards-publishing-bodies anyway
18:52 pmichaud http://pmichaud.com/2015/pres/fosdem-specs/fosdem-specs-1.pdf   # my FOSDEM talk slides
18:52 Sqirrel joined #perl6
18:56 moritz pmichaud++ # presentation
18:58 pmichaud I'm afk for 15
18:59 japhb pmichaud++ # preso
19:00 PerlJam I've seen quote on slide 18 quite a bit (or words to that effect)
19:01 jdv79 the "Classes are never "final"" could use some clarification maybe
19:02 moritz also not quite correct, iirc
19:02 moritz there's a conjetural "use oo 'final'" or so
19:05 dalek doc: eac25f0 | moritz++ | / (5 files):
19:05 dalek doc: Try to make update-and-sync more robust
19:05 dalek doc:
19:05 dalek doc: also move sync to util/
19:05 dalek doc: review: https://github.com/perl6/doc/commit/eac25f0362
19:06 dalek Inline-Perl6: e2fe4e0 | (Stefan Seifert)++ | / (2 files):
19:06 dalek Inline-Perl6: Replace a lot of hard coded paths by asking perl6 during build
19:06 dalek Inline-Perl6:
19:06 dalek Inline-Perl6: This is most probably still wrong, but will at least work on UNIX systems
19:06 dalek Inline-Perl6: with a locally installed rakudo
19:06 dalek Inline-Perl6: review: https://github.com/niner/Inline-Perl6/commit/e2fe4e0630
19:08 nwc10 nine: sorry, no clue on dynamic linking pain
19:08 nine nwc10: if this https://github.com/rakudo/rakudo/pull/359 is acceptable the pain is over :)
19:08 Mouq pmichaud++
19:14 dalek perl6-roast-data: 299d096 | coke++ | / (5 files):
19:14 dalek perl6-roast-data: today (automated commit)
19:14 dalek perl6-roast-data: review: https://github.com/coke/perl6-roast-data/commit/299d0965ef
19:17 dalek doc: f23c38f | moritz++ | lib/Type/Signature.pod:
19:17 dalek doc: Try to unbreak the htmlify build
19:17 dalek doc:
19:17 dalek doc: it seems to not like X<> links without a comma
19:17 dalek doc: review: https://github.com/perl6/doc/commit/f23c38fb6a
19:17 dalek doc: 3726d0f | moritz++ | htmlify.p6:
19:17 dalek doc: Remove debugging output
19:17 dalek doc: review: https://github.com/perl6/doc/commit/3726d0fff6
19:17 [Coke] is a Block a Callable? seems to be a Code... a Sub is eventually a Block. what are callables?
19:18 moritz [Coke]: Callable is a role
19:18 moritz m: say $_ ~~ Callable for Block, Code
19:18 camelia rakudo-moar 21ca41: OUTPUT«True␤True␤»
19:19 moritz [Coke]: see http://doc.perl6.org/type/Callable for the type graph
19:21 lizmat joined #perl6
19:22 dalek mu: f27427e | sergot++ | misc/gsoc-2015/ideas.md:
19:22 dalek mu: Im interested in working on the bundling project
19:22 dalek mu: review: https://github.com/perl6/mu/commit/f27427e679
19:23 FROGGS jnthn: nativecasting to a VMArrayInstance is quite tricky on the jvm it seems...
19:23 pmichaud back again
19:23 Kristien oh boy
19:23 dalek Inline-Perl6: 2bc1ad7 | (Stefan Seifert)++ | / (3 files):
19:23 dalek Inline-Perl6: Replace hard coded path to Inline/Perl6.so by asking DynaLoader
19:23 dalek Inline-Perl6: review: https://github.com/niner/Inline-Perl6/commit/2bc1ad731e
19:23 Kristien my LLVM stuff works
19:23 pmichaud Applications can declare things to be final; but classes cannot declare themselves to be final
19:23 FROGGS jnthn: because all I have i a memory address, and the VMArrayInstance has a public long[] slots;
19:25 pmichaud PerlJam: (slide 18)  I've heard or read that sentiment more times than I care to count.
19:26 pmichaud I think our collective delusion of "spec before implementation" was a key contributor to that, though.
19:30 dalek Inline-Perl6: 9836e5f | (Stefan Seifert)++ | t (2 files):
19:30 dalek Inline-Perl6: Beginning of a test suite :)
19:30 dalek Inline-Perl6: review: https://github.com/niner/Inline-Perl6/commit/9836e5fedf
19:30 [Coke] (annoint one compiler over the others) which is something the core team really should do if we're going live this year. As a perosn who wants to use rakudo for code, I don't want to have to switch back and forth between compilers during upgrades. I can see doing it if someone puts out a new version with awesome features that I must have, but we are a limited team with limited resources, most of which are dev
19:30 [Coke] oted to various rakudo backends at this point. I think it's ok to prefer rakudo in 2015.
19:32 moritz [Coke]: cut off after "which are dev"
19:32 lizmat [Coke]: TimToady said as much in his presentation
19:32 [Coke] m: say { $^x } ~~ Callable
19:32 camelia rakudo-moar 21ca41: OUTPUT«True␤»
19:33 [Coke] lizmat: ok. haven't seen it yet, was responding to backscroll, but I think it got there anyway.
19:33 [Coke] moritz: here it shows as a second line: "oted to various rakudo backends at this point. I think it's ok to prefer rakudo in 2015."
19:37 lizmat_ joined #perl6
19:40 pmichaud I don't mind with expressing a temporary preference.
19:40 Hor|zon joined #perl6
19:41 pmichaud I do think any sort of permanent designation is a bad idea.
19:41 dalek Inline-Perl6: af843dd | (Stefan Seifert)++ | / (3 files):
19:41 dalek Inline-Perl6: Allow evaling arbitrary Perl 6 code from Perl 5
19:41 dalek Inline-Perl6: review: https://github.com/niner/Inline-Perl6/commit/af843ddef5
19:41 pmichaud TimToady actually went further than "Rakudo" in his talk; he said "Rakudo on MoarVM".
19:41 atta joined #perl6
19:46 avar In particular he said that if some of the other implementations aren't ready and broken at that time that's fine
19:48 * japhb is uncomfortably excited about this year ... and trying to figure out what he wants to have prepared for Christmas
19:48 japhb One must plan ahead, you see ....
19:48 dalek rakudo/nom: 195b028 | moritz++ | README.md:
19:48 dalek rakudo/nom: Fix news aggregator link
19:48 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/195b028af6
19:48 lizmat avar: which spells bad news for rakudo on parrot
19:48 PerlJam japhb: A good advent article?  :)
19:49 japhb PerlJam: Oh, that's a good point!  I've never done one because my Decembers are always packed to the gills.
19:49 dalek rakudo/nom: f93da64 | (Stefan Seifert)++ | tools/build/Makefile-Moar.in:
19:49 dalek rakudo/nom: Fix missing symbols when loading libperl6_ops_moar.so from a dlopen'ed libmoar.so
19:49 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/f93da64777
19:49 dalek rakudo/nom: 5b49077 | jnthn++ | tools/build/Makefile-Moar.in:
19:49 dalek rakudo/nom: Merge pull request #359 from niner/nom
19:49 dalek rakudo/nom:
19:49 dalek rakudo/nom: Fix missing symbols when loading libperl6_ops_moar.so from a dlopen'ed libmoar.so
19:49 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/5b49077fa7
19:50 ppp joined #perl6
19:52 Hor|zon joined #perl6
19:54 nine jnthn: thanks :)
20:04 dalek Heuristic branch merge: pushed 21 commits to rakudo/newio by lizmat
20:07 dalek doc: 566fa31 | moritz++ | lib/Type/Mu.pod:
20:07 dalek doc: Start to document "is export" on types
20:07 dalek doc: review: https://github.com/perl6/doc/commit/566fa3113c
20:11 alini joined #perl6
20:14 skids .oO(2-year-old perl6 code written before you knew idioms sure tends to get much shorter on a rewrite)
20:14 retupmoca jnthn: could I get you to glance at RT#123702 ? At least point me in the right direction?
20:14 synopsebot Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=123702
20:24 mohij joined #perl6
20:24 FROGGS[mobile] joined #perl6
20:25 _dolmen_ joined #perl6
20:32 dalek rakudo-star-daily: 8f89581 | coke++ | log/ (10 files):
20:32 dalek rakudo-star-daily: today (automated commit)
20:32 dalek rakudo-star-daily: review: https://github.com/coke/rakudo-star-daily/commit/8f89581948
20:34 dalek doc: 7a6e100 | moritz++ | util/update-and-sync:
20:34 dalek doc: Try to fix update-and-sync
20:34 dalek doc: review: https://github.com/perl6/doc/commit/7a6e1005e8
20:35 masak very interesting backlog about versioning and then about the exact role of specification vs implementations.
20:35 dalek doc: c827a80 | moritz++ | CREDITS:
20:35 dalek doc: CREDITS: fix team
20:35 dalek doc: review: https://github.com/perl6/doc/commit/c827a80f21
20:35 masak now I'm eager to leaf through pmichaud++'s presentation.
20:36 masak by the way, I made this: https://gist.github.com/masak/ae7677e5c2ccc7f37f97 -- it's a quick histogram of Rakudo commits over the years, divided into months.
20:36 * sjn sadly missed pmichaud's talk :-(
20:36 masak I made it because I felt that Rakudo activity has been consistently high lately.
20:37 Maddingue joined #perl6
20:37 masak well, it's not that visible in the histogram, but it certainly has been high.
20:37 moritz masak++
20:37 masak mostly the effect is moderated somewhat because (as it turns out), we not only had a good 2014, but a good 2013 and 2012 as well.
20:37 masak 2011 is a bit wonky because that's the only time Rakudo was working in a branch. (ng)
20:38 masak but we *did* just have the best January ever.
20:38 masak I hereby license the code in that gist as cc-by. do cool stuffs with it.
20:39 * masak reads http://pmichaud.com/2015/pres/fosdem-specs/fosdem-specs-1.pdf
20:39 _mg_ joined #perl6
20:41 * masak notices that "Perl 6.0.0" is used on slide 3
20:42 masak regardless of what we might decide to think about that version schema going forward, I think it's clear that's what the "core" Perl 6 people have been using up until now.
20:42 sivoais joined #perl6
20:44 pmichaud masak: "Perl 6.0.0" in the slide predates my "Oh, we probably shouldn't be using 6.0.0 release numbers" thought.
20:44 masak I'm fully aware of that.
20:44 Sir_Ragnarok joined #perl6
20:45 masak my remark just now should be read in light of that.
20:46 masak I must admit that I'm kind of emotionally attached to the "Perl 6.0.0" versioning scheme. but I'm willing to put my feelings on hold and work towards something that heats the coals under Perl 5 people's anger a bit less, if that's what it takes.
20:47 masak pmichaud++ # slide 18
20:47 masak I've always disliked that one, too.
20:48 pmichaud for me, the move against "6.0.0" numbering actually didn't come from a p5 perspective.
20:48 masak oh, innerestin'
20:48 pmichaud it's more about what I think a language spec should be.... I think language evolution is a slower pace than software implementation
20:48 pmichaud or, it should be a slower pace
20:49 pmichaud and 6.0.0, or any    version-major-minor   scheme, implies far more frequent updates than I think healthy for a language spec.
20:50 pmichaud I started thinking about language spec releases, and wondering if we should do periodic releases like we do for the compiler.
20:50 pmichaud and my first counter-thought was "well, perhaps, but certainly not monthly"
20:51 pmichaud and once we start getting into things that happen only a few times a year at best... well, the 6.0.0 scheme really feels like it starts to break down there.
20:51 moritz and people tend to over-interpret three-tuples of numbers
20:52 pmichaud exactly.
20:52 * moritz warms up to YYYY<alpha>
20:52 FROGGS[mobile] also because major.minor.patch has nothing to do with cyclic releases
20:53 pmichaud beyond that, but 6.0.0 just really feels like it _wants_ to be tied to software development releases somehow.  Indeed, I wonder if the whole notion of 6.0.1, 6.0.2, 6.1.0 comes from a feeling that we're looking for compatibility with a particular compiler implementation, as opposed to a language spec -- i.e., a time from when language and compiler were basically synonymous
20:53 sivoais joined #perl6
20:53 Juerd m: say "foo"
20:53 camelia rakudo-moar 5b4907: OUTPUT«foo␤»
20:54 * jnthn back
20:54 pmichaud then, looking at other language specs, you don't see anything approaching x.y.z language specs; we have things like "C89" and "C99" and the like.
20:54 pmichaud even in Internet Standards, they don't version them beyond a simple 1-2-3 numbering scheme.
20:54 jnthn nine: Welcome. iPhone = can merge pull requests at the pub. :)
20:54 Juerd m: my @foo = (-> { 1 }, -> { 2 }, -> { 3 }); say @foo».()
20:54 camelia rakudo-moar 5b4907: OUTPUT«1 2 3␤»
20:54 Juerd m: my @foo = (-> { 1 }, -> { 2 }, -> { 3 }); say @foo»()
20:54 camelia rakudo-moar 5b4907: OUTPUT«===SORRY!===␤Cannot find method 'flat'␤»
20:54 Juerd Ah.
20:55 masak huh.
20:55 * masak suspects rakudobug
20:56 jnthn retupmoca: That's a sorta rightish direction, but subsumed by the 6pe-mop stuff that I'm working on.
20:56 pmichaud so, my whole rethink of "6.0.0" came almost entirely from the perspective of  "is this how we really want to be denoting our language spec versions...?"
20:57 retupmoca jnthn: ah, ok. In that case, I'll just wait for the 6pe-mop stuff
20:57 moritz m: my @foo = (-> { 1 }, -> { 2 }, -> { 3 }); say @foo».()
20:57 camelia rakudo-moar 5b4907: OUTPUT«1 2 3␤»
20:58 masak pmichaud: I'm intrigued. I bet mst will like that, too.
20:59 [Sno] joined #perl6
20:59 jnthn pmichaud: fwiw, my initial gut feeling on the <year><alpha> scheme is a good one.
21:00 kaare_ joined #perl6
21:00 jnthn pmichaud: I think - whatever we do - we're going to have to factor in that a lot of people simply won't have time for subtleties though.
21:00 pmichaud I'm not entirely convinced on <year><alpha>.  Or, if we do, then perhaps we'll want to remove the use of years from Rakudo's version numbers (or Rakudo Star's), to avoid an unwanted correspondence there.
21:01 jnthn pmichaud: We can try our best to shape the narrative, but we should probably come up with one that has non-awful failure modes when people understand about a quarter of it. :)
21:02 pmichaud a lot of people won't make time for subtleties, correct.  We don't have to have everyone understand all of the details... but we do have to have our understanding of the details well enough in place so that others' misunderstanding of the narrative doesn't inadvertently become our narrative.
21:02 jnthn That's very true.
21:02 pmichaud or, more precisely, doesn't become the driving force of our development/narrative.
21:02 masak +1 on "people won't have time for subtleties" -- that's the 3-second version of my whole experience with trying to communicate with the outside of the echo chamber.
21:03 pmichaud I think we can use things like C99 and ANSI C and HTTP to help in the explication
21:03 vendethiel pmichaud++ #specs
21:03 * jnthn notes that HTTP has done OK with major/minor version numbers :)
21:04 pmichaud jnthn: yes, well, two of them.
21:04 dalek Inline-Perl6: bb88ef0 | (Stefan Seifert)++ | / (2 files):
21:04 dalek Inline-Perl6: Allow reading back some ints and strings from EVAL'ed Perl 6 code
21:04 dalek Inline-Perl6: review: https://github.com/niner/Inline-Perl6/commit/bb88ef0310
21:04 jnthn ;)
21:05 mohij Are there plans to start supporting "use v6.0;" once the spec is final? (As in supporting older versions of perl6 in later ones.)
21:05 avar nine: I heard you managed to do some perl embedding via moarvm. I wanted to try embedding moarvm/nqp/rakudo in uwsgi, got anything I can start with?
21:05 pmichaud it's notable that RFC 2068 (HTTP 1.0) wasn't published until 1997.
21:05 avar nine: I can start trying to brute-force the API in moar.c, but starting with something would be easier
21:05 * avar zZzzZ
21:05 jnthn pmichaud: If you feel we can only use a year number in *one* of the lang or compiler version, it'd seem that letting the thing ameanable to time-based releases be the one that gets the year.
21:06 pmichaud jnthn: I'm not sure I agree with that.
21:06 pmichaud I think the thing that happens on longer timescale might want the year.
21:06 nine avar: I've just starting making progress on Inline::Perl6 for Perl 5 :)
21:06 skids 80MB file: sha1sum: 0m1.015s NativeCall+libmhash moving 2048-byte chunks: 0m28.347s  # getting there.
21:07 jnthn (That is, I think the year.month scheme is working rather well for Rakudo, and Moar, and I'd be a little sad to see that go)
21:07 FROGGS[mobile] skids++
21:07 nine avar: have a look at the code at https://github.com/niner/Inline-Perl6
21:07 pmichaud well, rakudo still has the sequential numbering scheme as well :)
21:07 avar nine: cool, thought that was the thing for perl6, will check it out
21:07 jnthn pmichaud: Yeah, but...I've no idea what number we're at. :P
21:07 pmichaud although we definitely think of releases in terms of time-based.  I'm largely to blame for that, I think.  :)
21:08 lizmat m: say $*PERL.version; say $*VM.version
21:08 avar I tried building a rpm for moar/nqp/rakudo but quickly decided that I hate redhat
21:08 camelia rakudo-moar 5b4907: OUTPUT«vunknown␤v2015.1.21.g.4.ee.4925␤»
21:08 FROGGS[mobile] vunkown :p
21:08 lizmat the former would be 6.major.minor in the future  ?
21:08 FROGGS[mobile] I still enjoy that one
21:08 pmichaud I'm thinking we should avoid 6.major.minor for everything
21:09 jnthn *nod*
21:09 pmichaud well, a compiler could eventually get to 6.x.y  after progressing from 1.x.y, 2.x.y, ... , 5.x.y
21:09 masak FROGGS[mobile]: if you pronounce it with a German accent, this even makes sense: `-Ovunknown`
21:10 FROGGS[mobile] masak: I dont get it :o)
21:10 masak FROGGS[mobile]: "optimize for vunknown"
21:10 jnthn pmichaud: To the degree you're to blame for us thinking of Rakudo releases as time-based - thank you. ;)
21:10 telex joined #perl6
21:10 pmichaud jnthn: I'm not sure how concerned I am with the year correspondence.   "Perl 6 2015a" I kind of like.  I could see shortening it to "15a".  Perhaps the use of an alpha instead of a number is sufficient distinction.
21:11 pmichaud I also think we'll definitely need TimToady++ to have some time to weigh in on the discussion; he's given a lot of thought to version schemes.
21:11 pmichaud We'd want whatever we come up with to work with the Version type, also.
21:11 Mouq masak: https://gist.github.com/Mouq/7bc8bf4228176270cb3a
21:11 jnthn pmichaud: Even if people *do* conflate the two, the failure mode - given we intend spec to be descriptive - is not awfully bad, I guess.
21:12 FROGGS[mobile] pmichaud: that just means it has to start with a number
21:12 FROGGS[mobile] m: say v15a
21:12 camelia rakudo-moar 5b4907: OUTPUT«[31m===[0mSORRY![31m===[0m Error while compiling /tmp/6xqVHxp24bâ�¤Undeclared routine:â�¤    v15a used at line 1â�¤â�¤Â»
21:12 pmichaud FROGGS[mobile]: well, and be able to collate/compare properly.
21:12 FROGGS[mobile] ewww
21:12 jnthn pmichaud: That is, you'd expect a spec release declared in 2017 to be supported by some compiler release in 2017.
21:13 pmichaud jnthn: bzzzzt
21:13 jnthn pmichaud: Because if implementation should come first, well... :)
21:13 FROGGS[mobile] m: say v6.2015a
21:13 camelia rakudo-moar 5b4907: OUTPUT«[31m===[0mSORRY![31m===[0m Error while compiling /tmp/dvYY853Sts�Confused�at /tmp/dvYY853Sts:1�------> [32msay v6.2015[33m�[31ma[0m�»
21:13 FROGGS[mobile] pff
21:13 pmichaud I'd expect a spec release declared in 2017 to be supported by compiler releases before 2017 :)
21:14 pmichaud as well as the ones coming later, of course.  :)
21:14 moritz well, adaptiong version literals should be our smallest problem
21:14 jnthn pmichaud: Well, I could imagine a 2017 spec release declared in December to maybe not be fully supported by a compiler release in January, maybe. :)
21:14 jnthn (The January *before*, I mean.)
21:15 moritz if we release languages after they are supported, we have a bootstrapping problem
21:15 moritz the compiler doesn't know the language version yet
21:15 moritz so it can't support 'use v6.$someversion'
21:15 moritz and people won't write 'use v6.$someversion' if v6.$someversion isn't released and supported yet
21:15 pmichaud I figure a compiler will always have some variation between what it implements and any given language spec.
21:16 pmichaud if not, then we're back to "compiler defines/implements exactly language x.y.z"
21:17 pmichaud certainly I'd write   "use v6.2015c"  if I knew that I needed at least that level of language to run my code
21:17 pmichaud oh, with a + on the end
21:18 FROGGS[mobile] that's implicit
21:18 pmichaud Is it?
21:18 FROGGS[mobile] aye
21:18 pmichaud how do I tell the compiler to go back to the 2015a interpretation of things, then?
21:18 FROGGS[mobile] at least. + is implicit
21:18 masak Mouq++ # https://gist.github.com/Mouq/7bc8bf4228176270cb3a
21:18 moritz pmichaud: but if language versions are released retroactively, how does a compiler know if it supports 2015c or not?
21:19 FROGGS[mobile] gar.
21:19 FROGGS[mobile] grr, .+
21:19 FROGGS[mobile] typing is hard
21:19 moritz I mean, it could very well support the language, but not yet know about it
21:19 lizmat Amsterdam.PM shutting down&
21:19 moritz that would suck.
21:19 pmichaud moritz: why would that suck?
21:20 Mouq masak: (it also kind-of works on various other git repos
21:20 gugod joined #perl6
21:20 Mouq )
21:20 moritz pmichaud: because it means that the compiler will give a wrong error message, and refuse to compile a language it actually understands
21:20 FROGGS[mobile] moritz: that be fixed by a compiler release easily
21:20 masak Mouq: didn't think of that :)
21:20 nwc10 aren't you just re-implementing parts of https://www.openhub.net/p/rakudo
21:20 masak Mouq: just need to fetch the start and end points somehow, I guess.
21:20 japhb pmichaud: I have Rakudo 2015.09.  Three months later, 2015c is released, and says 2015.09 supports it.  So I add 'use v2015c' or whatever in my script, and ... it won't run in 2015.09
21:20 nwc10 admittedly, with a current mirror
21:21 [Coke] the version of the spec the compiler supports is like the version of unicode we support. you 'use' a compiler version, not a spec version.
21:21 moritz [Coke]: that will be *very* confusing
21:21 [Coke] note: this level of unicode support is not yet supported.
21:21 [Coke] moritz: it is, honestly, a little late to worry about that. :)
21:21 Mouq masak: Yeah, but I was too lazy to actually do that, it just fudges for when the commits start flowing
21:21 [Coke] this whole environment we've setup -is- confusing. :)
21:22 japhb [Coke]: But I thought that was explicitly something Perl 6 *doesn't* do -- because it allows you to specify which version of the language it should be parsed (and run) as.
21:22 moritz [Coke]: it also breaks any promises of every supporting any other compiler
21:22 japhb moritz: Yes, exactly
21:22 [Coke] japhb: we might support multiple -spec- versions, but not multiple compiler versions of that spec, i would imagine.
21:22 pmichaud that's what makes me wonder about the whole "6.0.0" thing.
21:23 [Coke] moritz: I don't see that.
21:23 masak pmichaud++ # http://pmichaud.com/2015/pres/fosdem-specs/fosdem-specs-1.pdf
21:23 [Coke] pmichaud: is anyone still arguing for 6.00
21:23 masak pmichaud: definitely food for thought.
21:23 [Coke] ?
21:23 pmichaud I wonder if the idea of "specify which version of the language it should be parsed/run as" was actually coming from "language is strongly tied to compiler release"
21:24 pmichaud and, are we asking for a specific language, or for a specific compiler's interpretation?
21:24 moritz pmichaud: I hope the former
21:24 [Coke] we already have a way to specify "run this code in another language" and it's not 'use'.
21:24 japhb pmichaud: Going back to your reference to C specs, compilers regularly let you specify c90 or c99 as your target.
21:24 moritz pmichaud: otherwise, all dreams of multiple, compatible compilers are lost again
21:24 FROGGS[mobile] in an ideal world the former
21:25 pmichaud japhb: do the compilers implemented prior to the release of C90 or C99 allow you to specify them as targets?
21:25 [Coke] I could see that slangs might allow you to run 2 different specs. but there's no guarante that each compiler will support multiple versions. if you're doing that as an end user, you're asking the implementators for a lot.
21:25 japhb ISTR some shenanigans on that front with optimistic compiler authors when the spec wasn't finished, but otherwise, I should think not.
21:25 pmichaud japhb: if it's not an issue for c99/c90, then perhaps it won't be an issue for p6.
21:25 japhb pmichaud: But those specify the version in the compile command, not in the code, yes?
21:26 pmichaud whether it's in the compile command or code doesn't seem like an important distinction to me.
21:26 [Coke] If we want a whole run to require a certain version, I could see something like "use spec <C99>;"
21:26 [Coke] (note: 2 year versions in anything are not boss. don't do that.)
21:26 japhb But in my mind that falls under the "Just because other languages failed to hang the jacket on the right hook, doesn't mean we should."  Expected semantics is a feature of the code, not the makefile.
21:27 [Coke] Note that we don't have to really solve this problem until we have 2 versions of the spec to deal with. :)
21:27 japhb *syntax and semantics
21:27 pmichaud [Coke]: well, we need to plan for it.
21:27 pmichaud [Coke]: more importantly, we need to make these decisions so that others aren't saying "Perl 6 is the 2015.09 release of Rakudo."
21:28 pmichaud or, almost as bad:  "When is version 1.0 of Perl 6 coming out?"
21:28 japhb Actually, [Coke] has a good point.  Perhaps 'use 2015.12' means "Use what was implemented by this compiler as of 2015.12", and 'use spec <2015a>' or so means "Use what was defined in this spec".
21:29 [Coke] pmichaud: people are going to ask those questions, and misframe our stuff. they've been doing it for a decade.
21:29 japhb And a compiler is free to not know the future spec it will be supporting, but it should certainly know its own release ID.
21:29 pmichaud [Coke]: I know.  I'm not saying we can completely solve that problem.  We can do more to prevent that problem from confusing/driving our development.
21:29 [Coke] I agree that we have to have a good story, but we can only say it so much, and, as I said, we've made it pretty complicated. I hope we can find a way to simplify it as part of the marketing with the release.
21:30 japhb [Coke]: That's part of what I've been aiming for today.
21:30 [Coke] japhb: do you have a gist with your lastest suggestions on wordings?
21:30 japhb I think part(!) of the previous communication problem is not enough concreteness to the discussions.  Hence being possibly over-concrete today.
21:30 japhb No, but easy enough to whip up.
21:31 pmichaud our hand-waviness over many aspects of this has definitely created confusion in the past.
21:31 [Coke] *I* have trouble explaining it to people, because it was messy, and we encouraged the mess.
21:32 pmichaud [Coke]: which part is hard to explain, exactly?  (I'm not saying you're wrong, just that knowing details will help.)
21:32 [Coke] I'm not a huge fan of dropping support for parrot, btw. I would treat it just like JVM, either it supports the spec, or not. I don't think we're going to rip it out, though.
21:32 pmichaud [Coke]: I'm writing an article explaining the parrot position
21:32 pmichaud the problem is that Parrot definitely increases the workload needed for GLR, NSA, and NFG
21:33 [Coke] pmichaud: spec vs. implementation; multiple implementations; multiple backends for each of them; "I just want to try perl6, what do I do?" "I want to have some guarantee that if I pick this backend, it'll be supported and not dropped for the new shiny"
21:33 * vendethiel thinks all of this sounds awfully confusing
21:33 vendethiel why would I want some compiler version instead of some spec version? to much with the internals?
21:33 b2gills So far it seems as if there are only two types of versions being discussed: triplet (x.y.z) and year based. Is there another way that hasn't been discussed?
21:33 [Coke] pmichaud: ok. I look forward to the article, thanks.
21:34 [Coke] b2gills: 2 variations of triplet. 6.x based, and 1.x based.
21:34 [Coke] b2gills: for the compiler, or the spec?
21:34 b2gills both
21:34 [Coke] (year based) (what's the sub component?)
21:34 pmichaud vendethiel: when you go to grab a C compiler, do you look at the compiler's version number or the language's version number?
21:34 [Coke] b2gills: right, I'm saying it's more than 2 things.
21:35 [Coke] pmichaud: Both, if you're doing it right.
21:35 vendethiel pmichaud: language's version number. Does it support c++11?
21:35 pmichaud vendethiel: you don't care about which versions of the compiler have XYZ bug and security fixes?
21:35 [Coke] I would agree that's the more important number.
21:35 pmichaud besides, I don't expect people to be downloading just a compiler, ever.
21:35 [Coke] ;(and the later the compiler version, the better, probably, for those reasons)
21:35 vendethiel if I have to specify a compiler version then my tools are broken, I believe
21:36 [Coke] pmichaud: oh, I would.
21:36 vendethiel it's making my code nonportable
21:36 PerlJam vendethiel: do you use Perl 5?
21:36 vendethiel no, I don't
21:36 [Coke] In terms of bundles. I'd always use the compiler and grab the modules I need rather than use something like R*
21:36 pmichaud [Coke]: would you use the version of perl 6 installed with your operating system?
21:36 pmichaud because in answer to the question "I just want to try Perl 6", I'd hope the answer is "type perl6 on your command line"
21:37 vendethiel pmichaud: yes I would
21:37 japhb [Coke]: https://gist.github.com/japhb/ddb3d1a669509a69eaba
21:37 japhb Gah, stupid failed word wrap
21:37 vendethiel if I have specific requirements about which features I need, I certainly don't want to have to look up which version of X compiler is tied to which version of a spec
21:37 [Coke] pmichaud: do you mean the "system perl6" ? like /usr/bin/perl6 ?
21:37 vendethiel and in the process, bind my code to some specific compiler
21:37 vendethiel [Coke]: yes
21:37 pmichaud [Coke]: something like that.
21:38 PerlJam Do other dynamic languages have some equivalent of Perl's  "use v5.20" declarations?
21:38 [Coke] that's about a decade out.
21:38 vendethiel having #?if rakudo\n use rakudo v5.3;#?endif
21:38 vendethiel would make me terribly, terribly sad.
21:38 pmichaud vendethiel: nobody is proposing that at all.
21:38 pmichaud please don't go there.
21:38 vendethiel PerlJam: not that I know of
21:38 vendethiel pmichaud: alright, then i'm misunderstanding something. How do I specify the version of the compiler if I want to support *all* the compilers?
21:39 [Coke] I never use /usr/bin/perl unless I'm doing something sysadminy. Even then, I would strongly consider a way to deploy the specific version of perl and modules I wanted on my system rather than relying on the OS for anything other than the most trivial tasks.
21:39 pmichaud [Coke]: fair enough -- you're talking about a different use case than "I just want to try perl6", which is where my question started.
21:39 [Coke] vendethiel: how on earth can you support all the compilers?
21:39 vendethiel [Coke]: how on earth can I not? why do I have a spec if I'm not about to support all the compilers?
21:40 pmichaud If your answer segues into "well, you need to download a compiler and figure out which modules to install and ...." then yes, your answer is going to be complicated.  :)
21:40 [Coke] pmichaud: I'd use something like rakudobrew to try perl6. But to get to "rakudobrew", an outsider has a long slog to get through to find that.
21:40 [Coke] the compilers support the spec, not the other way around.
21:40 pmichaud compiler implement a spec
21:40 pmichaud I don't think "support" is the right word.
21:40 vendethiel [Coke]: when you release c or c++ code, you can be mostly sure it'll compile under all compilers that implement that spec
21:40 vendethiel (barring language extensions)
21:41 [Coke] so if you want something that is spec compliant, grab the latest version of rakudo that supports that version of the spec.
21:41 vendethiel but what if someone is on another compiler and wants to use my code? which part would be different?
21:41 vendethiel (that seems to be a huge problem in CL, btw. compiler-specific code in a lot of places...)
21:41 [Coke] vendethiel: You have no control over other implementations. As an app author, what are you looking for? perhaps automated testing like colomon does?
21:41 pmichaud vendethiel: nothing would be different, as long as "another compiler" supports the same level of spec as the original one
21:42 japhb vendethiel: Give the user tools: If they declare their code to be spec-compliant, then great, it's portable to spec-compliant code.  But there will always be a need to say "I need to get away from the bugs in this old release," or "I need this experimental feature that I know is in this new compiler release"
21:42 vendethiel pmichaud: right. so you only need to "use v<SPEC-VERSION>", right?
21:42 pmichaud and as long as the code you wrote limits itself to the level of spec that it claims to need
21:42 [Coke] the compiler is compliant with the spec. your code may not be.
21:42 [Coke] and you can figure out if either your code isn't or the compiler isn't with some kind of automated testing.
21:42 PerlJam vendethiel: that works as long as the compiler version and spec version are in sync I think.
21:43 pmichaud PerlJam: NO.
21:43 vendethiel why?
21:43 [Coke] use v is historically implementation version, not spec version.
21:43 vendethiel [Coke]: I really don't understand. if I grab a file of, again, C or C++, I *don't care at all* if the guy used gcc or clang to compile it initially
21:43 vendethiel it'll just work on the other compiler.
21:43 [Coke] I think we need a separte mechanism to declare what version of the -spec- you claim to be using.
21:43 PerlJam Coke: agree.
21:43 pmichaud vendethiel: that's what we expect with Perl 6, fwiw.
21:43 vendethiel *because both compilers "support" the same specs*
21:44 pmichaud vendethiel: it works, but not for exactly that reason.
21:44 geekosaur vendethiel, that would be because clang has been adding various heinous gcc-isms, because people do not understand how much of gcc is stuff that is not valid C
21:44 geekosaur per the standard
21:44 vendethiel geekosaur: that's also true. but most of the gcc extensions like that are deprecated
21:44 japhb geekosaur: Most of it?  ;-)
21:44 vendethiel I don't think we need those extensions in Perl6. .oO( but signature-placed return variable declaration looks so cool!)
21:45 japhb Deprecations in a C compiler are a strange beast.
21:45 Diederich joined #perl6
21:45 geekosaur which, unfortunately, is not a problem you can fix unless you accept that people will decide that what they use is The Standard, by which solaris is not unix because the only real unix is linux because more users
21:45 pmichaud I feel like this conversation has quickly ratholed.
21:45 * japhb bets you can still compile pre-ANSI C declarations on many compilers
21:45 vendethiel japhb: -Wall -Werror might make your program break with time.
21:45 [Coke] in any case, our spec is so much more slushy than that, and there are still gaps, it is STILL possible for multiple implementations to disagree on a particular point, I would expect. Asking for 100% compliance there is nice, but not something a sane implementor would agree to, I don't think.
21:46 geekosaur vendethiel, I already work with one project where -Werror is forbidden because it breaks compatibility
21:46 [Coke] If you write to "the spec", yes, your code should work on every compliant implementation. No one is disagreeing with that.
21:46 japhb [Coke]: Which is why the test suite is the real spec.  You either pass the tests, or you don't.
21:46 japhb It's not like you misinterpret the prose in a big document.
21:47 [Coke] and if your code is doing something not in those tests, good luck on cross-compiler congruence.
21:47 japhb Yes, we could (will, actually) have features that are underconstrained by the test suite, but I think that's a subtly different problem.
21:47 [Coke] (get the test added as a clarification to the spec.)
21:47 japhb [Coke]: Right.
21:47 pmichaud s/clarification/update
21:47 japhb Yes
21:48 [Coke] so, our existing 'use v6;' might need to become 'use v6 <spec version>' ; we also need a way to say 'use at least Rakudo 2012.12 # because I know that fixed the bug I care about"\
21:49 pmichaud I think the "use at least Rakudo version" is a simple module.
21:49 pmichaud i.e., if code says     use Rakudo v2015.01;   that ought to be fairly obvious.  :)
21:50 FROGGS[mobile] that would limit your program to one compiler
21:50 vendethiel but then, it will only work on rakudo :(
21:50 pmichaud it will limit your program to compilers that provide a "Rakudo" module.
21:50 [Coke] be nice if we could say "use Rakudo v2015.01 OR OtherCompiler v10", but that gets complicated. (and we don't have any real use case for that today)
21:50 pmichaud a compiler or environment can certainly lie about it.
21:50 FROGGS[mobile] ohh, pragma 'if' to the rescue :o)
21:50 pmichaud it's not a pragma!
21:51 [Coke] Only working on Rakudo is -just fine- for 2015, unless we have some major suprise.
21:51 FROGGS[mobile] :p
21:51 pmichaud IT'S NOT A PRAGMA!  It's a MODULE!
21:51 pmichaud Rakudo.pm6
21:51 japhb .oO( It's not a TUMOR! )
21:51 FROGGS[mobile] hehe
21:51 vendethiel pmichaud: ugh, that just seems like pain, pain, and more pain. Remember what browsers did to lie about their name?
21:51 [Coke] feature based requirements are better, sure.
21:51 vendethiel their user agent contained ... lies such as "khtml, like gecko". but then, you're considering you can believe it when it's lying!
21:51 pmichaud we also have the entire set of %*VM stuff, or whatever it's called these days
21:51 PerlJam Some people will probably also want "use Rakudo v2015.01 :backend<jvm>";
21:52 pmichaud vendethiel: so, you're proposing that there should not be a way to confirm/check a compiler version?  Is that what you're arguing?
21:52 [Coke] as a future rakudo-jvm user, that's fine with me. I'm not going to switch away from rakudo to blah-java any time soon.
21:52 vendethiel pmichaud: or that you should be able to specify *several* compliant compilers.
21:53 pmichaud vendethiel: okay, I have no problem with doing that.  My point is that it's doable.
21:53 [Coke] I would suggest it's bad form to require a specific compiler, but I would certainly want the ability to do so.
21:53 vendethiel pmichaud: another compiler providing "rakudo v2015.1" is just going to get bad really, really fast, because there's actually gonna be *small changes
21:53 pmichaud and that it's doable using simple modules.
21:53 vendethiel * in the execution that'll break everything.
21:54 pmichaud emulation is a valid mode of operation, and yes, emulators are often imperfect.  but we don't outlaw them.
21:55 vendethiel but then, how do you rule out emulators that are known buggy ? ;-)
21:55 vendethiel you actually didn't make a step forward
21:55 pmichaud This is being very non-productive for me.
21:55 FROGGS[mobile] on an unrelated note, I wanna have 'use Foo if $*PERL.compiler eq 'rakudo''
21:55 [Coke] So, I would really like to have JVM be on the list of supported backends when we go live. I will even write code to help make it happen. Please keep this in mind when working on stuff. :)
21:56 pmichaud [Coke]: I'm expecting that jvm will still have good levels of support.  I don't know where it will be with NSA or NFG, though.
21:56 vendethiel if you specify a compiler version because you know another version have some bug, but then you get another compiler that tries to emulate it but fails, specifying the compiler version was a bit pointless
21:56 [Coke] Let's just take a day or seven to digest vendethiel's concerns. Maybe one of us will think of something clever.
21:56 FROGGS[mobile] would be useful for NativeCall vs. pure perl implementations
21:57 [Coke] pmichaud: perhaps that's something that should be exposed with a feature-based use. "use spec <P62015 NFG>" # Sorry, This backend does nto support NFG.
21:57 PerlJam vendethiel: sounds like the problem of a) whoever made the poor emulator and probably b) the person attempting to use that emulator
21:57 pmichaud [Coke]: perhaps.  I did mention that features have lifetimes in my presentation.  :)
21:58 jnthn pmichaud, [Coke]: I expect I will get get the NSA stuff covered on JVM. NFG...that's further down the line; on Moar I have a strings impl that I've grown up knowing I have to do NFG; on the JVM I just used Java strings for expediency. :)
21:58 pmichaud [Coke]: I'm hoping that the upcoming changes won't have much impact on the jvm backend.
21:58 vendethiel PerlJam: but then, I can argue that I'll only specify the spec version, and if another compiler doesn't comply exactly to it it's the problem of a) whoever made the buggy compiler b) the person attempting to use that buggy compiler
21:58 pmichaud In looking at the rakudo codebase, especially w.r.t. GLR, there's a lot of   #?if parrot     and #?if !parrot
21:58 japhb [Coke]: 'use spec < Perl6:2015a NFG:2015d >'?
21:58 pmichaud but there's very little #?if jvm
21:59 jnthn [Coke]: For everyday use of Rakudo JVM, the NFG is probably the least consequential thing compared to the others.
21:59 pmichaud since   jvm falls into the same side of things as moarvm -- namely   #?if !parrot  --   I'm thinking it's likely to be safe.  :)
22:00 jnthn pmichaud: That's my feeling too :)
22:00 PerlJam vendethiel: I guess I'm saying that these sorts of problem exist at the intersection compilers and users and we can't really hope to solve them as much as provide tools to help the programmers mitigate their circumstances.
22:01 pmichaud PerlJam +1
22:03 retupmoca 'use features < spec-2015a nfg any(rakudo-1.2.3, compiler-4.5.6) >'
22:03 pmichaud I feel like this is all graviting towards premature overspecification, fwiw.
22:04 pmichaud I should just depart now, I think.
22:04 FROGGS_ joined #perl6
22:05 [Coke] jnthn: I'm sure I can work on NFG on JVM if needed.
22:06 [Coke] what perljam said.
22:07 Sqirrel joined #perl6
22:08 PerlJam btw, this discussion has made me think that I don't know what "use v6" means (or should mean) anymore.  At some point I hope to regain the certainty of that knowledge.  :)
22:09 pmichaud PerlJam:  what did you think it meant before, ooc?
22:10 PerlJam I just realized that I'd been conflating "compiler version" and "spec version"
22:10 pmichaud ...and I think I realized this past week (while writing my talk) that a lot of people have been doing that.  :)
22:11 PerlJam honestly, I guess I never gave it much thought because it was "just like Perl 5"
22:13 eternaleye_ joined #perl6
22:18 PerlJam IIRC python only has feature-based "import from future".  There is some wisdom in that.  As we implement new features, they could be enabled/disabled on a per feature basis.  And once we figure out what belongs in a spec, we could build feature-bundles for that particular version of the spec.
22:19 b2gills PerlJam: When I have "use v6;" it means "fail with a decent error on Perl 5"
22:21 PerlJam b2gills: so far, I've never accidentally run a P6 program with a P5 compiler :)
22:22 PerlJam actually, I could use something that goes a little the other way.  Just like P6 parses some of P5 syntax to give you better error messages about what you're donig wrong, I could use the P5 compiler to parse a little P6 syntax for the same reasons
22:23 denis_boyun joined #perl6
22:23 PerlJam (I'm often thinking in P6, but writing P5 and then momentarily confused when something doesn't work right or dies horribly)
22:23 jdv79 which is intersesting since p5 will say that you need Perl v6.0.0:)
22:23 jdv79 will that ever exist now?
22:23 jercos I find it most useful as a guard for modules in mixed projects, or one-liners with -M
22:24 jercos Since .pm is a sane extension for a perl 6 module, yes?
22:24 colomon joined #perl6
22:26 PerlJam anyway, I think shifting the conversation away from "which version of the spec/compiler" and towards "which features do you need" is a good thing.   Reminds me of roles in a way.
22:30 jdv79 sounds like a nightmare.  worked out great for p5;)
22:30 jdv79 i don't like the features pragma stuff
22:33 jercos To me that kinda feels like duplication
22:33 jercos Very Java though.
22:36 b2gills jdv79: most of the time you don't need to use the feature pragma in Perl 5 as it gets loaded for you if you specify the minimum version ( e.g. `use v5.10` or `use 5.010` imports the 'say' feature )
22:37 * TimToady has made it to Seattle
22:37 colomon \o/
22:39 TimToady I worry that having similar date-based version schemes between language spec and implementations could confuse peopel completely
22:39 TimToady people too
22:40 TimToady especially if we decide we need test patches alongside implementation patches
22:40 japhb TimToady: I'm not wedded to '2015a' as a format.  It just felt the best of what we've come up with so far.
22:40 TimToady because there could be bugs in the test suite
22:40 colomon almost certainly are
22:41 TimToady of the sort you just fix because probably nobody's depending on being bug compatible
22:41 japhb colomon: Yes, quite
22:41 * japhb imagines an angry monster-movie mob shouting "Compatible with ALL the bugs!"
22:42 TimToady but I haven't backlogged yet since the wee hours of Brussels time
22:43 TimToady one could possibly even imagine a security fix to the test suite
22:43 TimToady but I'l think about this s'more when I'm not jet-slagged
22:48 TimToady *ll
22:48 [Coke] sleep well, and dream of large version numbers.
22:50 [Coke] Oh, I know what annoying-to-do project I can work on next that will help the release, maybe. Blah.
22:51 [Coke] Down to 713 tickets in RT, btw.
22:51 [Coke] I recommend we start tagging tickets that are required to ship this year.
22:51 [Coke] (though, since we don't have a PM, per se, that's hard to judge)
22:52 [Coke] Let's try this: if ther's a ticket you think must be resolved before we ship, ping me and I'll add it to some document we can then try to manage.
22:59 pmichaud [Coke]: I'm having trouble with the "resolved before we ship" phrasing there.
23:00 pmichaud I know the sense of what you mean and agree with it... but there are tickets for rakudo and tickets for the "spec" and ....
23:06 * masak closes his eyes and a flash of SHA-1 version numbers scares his eyes open again
23:08 * japhb imagines a matrix-style screen saver in which all the falling characters are real commit IDs
23:09 * jnthn saw quite enough SHA-1s today... :)
23:24 Mouq m: sub trait_mod:<is>(Mu:U $parent, |c) {say c.perl}; class Foo is Array[Str] { }
23:24 camelia rakudo-moar 5b4907: OUTPUT«Capture.new(list => (Array, [Str],))␤»
23:28 colomon joined #perl6
23:32 masak parting words before sleep: .classify has a tendency to eliminate a fairly gnarly kind of accumulator for loop. it's like the secret cousin of .map, .grep, and .sort
23:33 masak I wonder if there are more for-loop-eliminating methods out there that we haven't discovered.
23:33 masak 'night, #perl6
23:33 Mouq sleep tight, masak :)
23:34 Mouq m: class Foo { class Bar is Foo { }; method from_foo(Mu $self:) {"Works. Got "~$self.^name}  }; say Foo::Bar.from_foo; # Ok
23:34 camelia rakudo-moar 5b4907: OUTPUT«Works. Got Bar␤»
23:34 Mouq m: class Foo { class Bar is Foo { }; method from_foo($self:) {"Works. Got "~$self.^name}  }; say Foo::Bar.from_foo; # Not ok
23:34 camelia rakudo-moar 5b4907: OUTPUT«Type check failed in binding $self; expected 'Any' but got 'Bar'␤  in method from_foo at /tmp/BmzgVG_Yk4:1␤  in block <unit> at /tmp/BmzgVG_Yk4:1␤␤»
23:34 lsm-desktop joined #perl6
23:34 Mouq (Related, I think, to RT #115278 / #122221 )
23:34 synopsebot Link: https://rt.perl.org/rt3//Public/Bug/Display.html?id=115278
23:42 adu joined #perl6
23:45 lizmat joined #perl6
23:52 tony-o is there something equivalent to lstat on an IO handle yet?
23:52 tony-o or stat
23:54 BenGoldberg joined #perl6

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

Perl 6 | Reference Documentation | Rakudo