»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'p6: say 3;' or rakudo:, std:, or /msg camelia p6: ... | irclog: irc.perl6.org | UTF-8 is our friend!
Set by moritz on 25 December 2014.
00:00 telex left 00:02 telex joined
[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:03
woolfy virtualsue++ and sjn++: thanks for being at the booth and speaking to people with difficult and other Perl questions! 00:06
00:06 Peter_R left
woolfy I completley forgot to mention Mark Keating. He has been many many hours at the booth and he was awesome. 00:06
Pictures of FOSDEM by Bas Bloemsaat: imgur.com/a/1ynV7#0 00:07
00:07 Peter_R joined 00:08 rurban left
hoelzro [Coke]: it's gotten as far as compiling CORE.setting for me 00:10
still chugging along...
yup, looks ok to me! 00:13
00:18 BenGoldberg joined 00:19 BenGoldberg left, BenGoldberg joined 00:22 gfldex left 00:31 _dolmen_ left
skids sjn: What's the NativeCall hackathon doing -- making new modules that use it, or improvements to NativeCall itself? 00:32
00:40 BenGoldberg left, BenGoldberg joined 00:41 BenGoldberg left, BenGoldberg joined 01:09 KCL_ joined 01:10 virtualsue_ joined 01:11 Ugator left 01:13 virtualsue left, virtualsue_ is now known as virtualsue 01:16 yeahnoob joined 01:26 alini left 01:33 virtualsue left 01:39 colomon left 01:42 colomon joined 02:16 colomon left, colomon joined 02:17 Mouq joined 02:49 isacloud joined 02:54 colomon left 02:59 colomon joined 03:18 Patterner joined 03:22 Mouq left 03:30 noganex joined 03:33 noganex_ left 03:38 lumimies left 03:39 lumimies joined 04:03 muraiki_ left 04:17 jack_rabbit joined 04:19 kaleem joined 04:22 anaeem1_ joined 04:31 jack_rabbit left 04:46 awwaiid left 04:57 BenGoldberg left 04:58 awwaiid joined, mr-foobar left 05:01 [Tux] joined 05:06 Mouq joined 05:11 Mouq left 05:32 mr-foobar joined 05:45 konsolebox joined 05:46 fhelmberger joined 05:48 lumimies left 05:51 mr-foobar left 05:54 Ulti joined 05:55 keenan joined 05:59 keenan left 06:18 xfix joined
TimToady waiting at BRU... 06:36
TimToady heading to gate, might or might not pop up in AMS 06:45
afk &
[Sno] woolfy and the Perl (6) community: with pleasure 06:50
06:55 Rounin joined 06:56 dayangkun joined 07:00 Mouq joined
dalek c: 34778bb | moritz++ | util/update-and-sync:
Fix rebuild
 07:01
07:12 alini joined 07:14 dayangkun left 07:18 FROGGS_ left 07:19 gfldex joined 07:21 andreoss left 07:31 Mouq left 07:44 gfldex left 07:49 xfix left 07:57 FROGGS joined, kjs_ joined 07:58 abraxxa left 07:59 abraxxa joined
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:02
FROGGS nine: retupmoca++ did that :o) 08:03
and raydiak 08:04
and raydiak++ also provided a patch
I think, next step would be to allow returning a buffer, after parrot and jvm are fixed
and... I want to implement sizeof() and allow to nativecast with an offset 08:05
08:06 alini left 08:07 kjs_ left
nine raydiak++ # seems like I missed that backlogging 08:09
Also I got myself a really nasty cold, so my brain is not up to speed :/
JimmyZ FROGGS: It'd be nice to have: my num $x is global('xxxx.so'); or my num $x is global('xxxx.so', 'x');
m: say $x.VAR.name 08:10
camelia rakudo-moar bececd: OUTPUT«===SORRY!=== Error while compiling /tmp/BTL0mY3Ytg␤Variable '$x' is not declared␤at /tmp/BTL0mY3Ytg:1␤------> say $x.VAR.name⏏<EOL>␤ expecting any of:␤ method arguments␤»
JimmyZ m: my $x; say $x.VAR.name
camelia rakudo-moar bececd: OUTPUT«$x␤»
08:12 _mg_ joined
JimmyZ or is Cglobal ? 08:13
08:13 trone joined 08:14 darutoko joined 08:16 Kristien joined
Kristien guten Tag 08:16
FROGGS JimmyZ: probably 'is cglobal', like the sub... 08:19
and yeah, I think I like it :o)
not sure that it is easily doable though
Ahoi Kristien 08:20
JimmyZ and nativecast could be used by coerce, methinks. 08:22
08:22 adu left, Ugator joined 08:23 zakharyas joined
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.
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
FROGGS JimmyZ: that would be sweet I think
JimmyZ aye
08:32 virtualsue joined
_mg_ Hello. Could somebody please point me to where in the rakudo sources the shebang lines are generated, for example for panda? 08:33
Hm, never mind, that lives in the panda module. 08:36
Hm, could it be that the rakudo installer changes the shebang lines on installation? 08:37
github.com/tadzik/panda/commit/f4b...ce0b8fa2f6 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:38
FROGGS _mg_: the scripts in the bin folder in star are not created by panda 08:39
they are copied over
_mg_ FROGGS: ok, but also modified?
08:39 nige joined
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:41
ohh wait, I am talking partially rubbish 08:42
_mg_ FROGGS: that's precisely why I am asking.
FROGGS for the linux/unix star .tar.gz nothing is copied over, we are only copying stuff for the windows mai
msi*
perhaps something in here needs tweaking: github.com/rakudo/star/ 08:43
... for the .tar.gz
_mg_ FROGGS: I try to update/fix the homebrew formula, and upstream wants documentation for the fix.
08:43 telex left
_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
08:44 telex joined
_mg_ I don't see where this could come from 08:47
08:53 Kristien left 08:54 dolmen left, kaleem left 08:59 alini joined 09:03 SamuraiJack joined
tadzik _mg_: er, no one generates shebang lines 09:08
I don't know how star would change this, does it?
if it is so, it's beyond me :)
_mg_ tadzik: It seems so, at least with homebrew. 09:09
tadzik _mg_: what does it change to?
_mg_ #!/usr/local/Cellar/rakudo-star/2014.12.1/bin/perl6-m, the exact perl location
This fails though because of an issue with bash 09:10
tadzik: that's why I'm placing a workaround in the homebrew formula which changes the shebangs back for 2014.12.1. 09:11
09:12 KPTN joined
tadzik _mg_: ah, so it's homebrew's fault? 09:13
it's the first time I hear of changing shebangs
if Star does it, it's news to me too :)
_mg_ I wouldn't think so, but I can ask
09:13 nige1 joined
tadzik what if you install Star manually on OSX? 09:13
_mg_ tadzik: trying 09:16
09:16 nige left 09:20 lumimies joined, Kristien joined
_mg_ tadzik: yes, it is modified 09:21
#!/tmp/rakudo-star-test/bin/perl6-m
use Shell::Command;
that's bin/panda
tadzik oh hm
Kristien Is it possible to customise string interpolation like you can in Scala and ECMAScript 6?
_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:22
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? :)
Kristien FROGGS: e.g. gist.github.com/rightfold/7622d00146ed3e9237ad 09:26
this is immensely useful for XML generation and preventing SQL injection 09:27
_mg_ tadzik: bin-install maybe?
while (<$IN>) {
if ($. == 1 && /^#!/) {
print { $OUT } "#!$p6bin\n";
}
else {
print { $OUT } $_;
}
}
tadzik :o
Kristien sql need not return a string, for example
FROGGS _mg_: please use a nopaste service
tadzik please don't do this again :) 09:28
_mg_: but yes, that looks like the guilty code
09:28 AhmadPrince joined
_mg_ ok, sorry for that 09:28
tadzik: this is still in rakudo/star
ven is surprised Kristien++ did not also quote c++'s way of doing it :) 09:30
Kristien: that's supposed to be macros and slangs
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
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?
Kristien FROGGS: ah I see 09:32
ven Kristien: I'm refering to the sql"" part, not the interpolation part :)
Kristien I'm confused.
ven Kristien: yes, I'm refering to UDLs 09:33
09:33 virtualsue left
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.
s/manipulation/interpolation/ 09:34
Kristien sure, just an example
ven string are EVILs, let's not do those :P
Kristien my primary concern is XML generation
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
nine Kristien: isn't this what templates are for? 09:35
Kristien templates are string concatenation
they tend to deal with strings only
09:35 molaf_ joined
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
_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.
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
ven Kristien: disagree totally that templates are sting concatenation
just get a real template engine that understands context, it exists in several languages. I think google made one for python, even
Kristien possibly with an implicit conversino from string to DOM::Node with escaping 09:38
it's particularly handy when the templates aren't written in a completely different language
09:38 molaf left
Kristien so I can just define <insert actual programming language here> functions and types and use them in the template 09:38
I guess an XML slang should work 09:40
09:42 Boris joined
tadzik _mg_: I'm pretty sure it's possible, can you submit a bug report? 09:45
on github.com/rakudo/star
09:48 rindolf joined 09:50 Kristien left 09:52 yeahnoob left, espadrine joined 09:54 Kristien joined 09:58 espadrine_ joined, espadrine left
_mg_ tadzik: willdo 09:59
10:00 coffee` joined
moritz m: sub MAIN($x = 42); say $x 10:01
camelia rakudo-moar bececd: OUTPUT«42␤»
moritz Mouq++
10:02 dakkar joined
_mg_ tadzik: github.com/rakudo/star/issues/42 10:06
tadzik _mg_++
10:08 Otterpocket joined, Otterpocket left, Otterpocket joined 10:09 Otterpocket left 10:11 _mg_ left 10:12 AhmadPrince left 10:13 Otterpocket joined 10:15 pecastro joined
Kristien m: role A { }; class B does A { }; sub f(A $x) { }; f(B.new) 10:16
camelia ( no output )
Kristien excellent
m: say B.new ~~ A 10:17
camelia rakudo-moar bececd: OUTPUT«===SORRY!=== Error while compiling /tmp/ZogTTY5QAC␤Undeclared names:␤ A used at line 1␤ B used at line 1␤␤»
Kristien m: role A { }; class B does A { }; sub f(A $x) { }; say B.new ~~ A
camelia rakudo-moar bececd: OUTPUT«True␤»
moritz would a shebang of the form #!/usr/bin/env /absolute/path/to/perl6-m work on all our supported platforms? 10:19
Kristien is Windows a supported platform? 10:20
10:20 kaleem joined
moritz well, yes-ish, but windows doesn't respect shebang lines anyway, no? 10:20
10:20 sqirrel_ joined
Kristien then no :D 10:20
10:20 Kristien left
moritz I should have asked: will it break anything? 10:20
10:25 konsolebox left 10:26 konsolebox joined
ab5tract moritz: i will try such a path with my fish shell setup. it exposes edge cases :) 10:28
s/path/shebang/
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
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
moritz well, it shouldn't be like that, but X::Undeclared gives you a hint that you have an undeclared symbol 10:32
dalek ar: 9da6ec4 | moritz++ | tools/build/bin-install.pl:
Fix shebang line on Mac OS X

hopefully closes #42
sergot morning o/ 10:39
FROGGS: pong :)
FROGGS sergot: hi, do you use nativecast somewhere to dereference a pointer? 10:40
sergot hmmm, let me see
this could be the only repo when I might use do so: github.com/sergot/openssl/tree/master/lib 10:41
or io-socket-ssl I think
looking at it
ab5tract moritz: okay, so a symbol in this case can be ... a term, a var, an anything basically? 10:42
10:43 Kristien joined, Otterpocket left
sergot FROGGS: do you mean nativecast from OpaqueuPointer to something? 10:44
Opaque*
10:44 alini left
FROGGS sergot: nativecast(OpaqueuPointer, OpaqueuPointer) basically 10:44
10:45 kjs_ joined
FROGGS sergot: you used it at somepoint, but it seems not the case anymore (which is good) 10:45
tadzik Opaqueue
FROGGS copy&paste ftw!
Kristien "opa" is Dutch for "grandpa" 10:46
an opa queue sounds creepy
ab5tract (i already took that hint in basically the same way"
sergot FROGGS: it looks like I don't use it anymore :)
10:48 rindolf left
FROGGS sergot: very good :o) 10:48
10:51 rurban joined, konsolebox left 10:52 konsolebox joined 10:54 zlad joined
sergot FROGGS: is there any bug there? 10:55
10:58 pmurias joined, zakharyas left 11:00 virtualsue joined
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.
FROGGS sergot: no, we just changed what it does.... such a cast won't dereference anymore
Kristien I'm going to have to write self-modifying code. :( 11:04
11:05 kjs_ left
FROGGS O.o 11:05
are you sure?
moritz Kristien: what are you trying to do?
www.mercurynie.com.au/mathguys/arti...0311g1.jpg "you have to use calculus and imaginary numbers for this" 11:06
11:07 kjs_ joined
sergot FROGGS: oh, ok, now I see :) 11:07
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
i.e. the first time they're called
but I need to override call instructions for that 11:09
overwrite*
11:10 arnsholt joined
sergot FROGGS: nice :) 11:11
moritz Kristien: sounds like you could use a wrapper, or a separate method mixed into the function
Kristien I want to optimise out the extra call 11:12
FROGGS make it work first I'd say
Kristien but maybe I merely have to override some methods from X86JITInfo class 11:13
it already does that trick but doesn't provide user callbacks
11:14 Kristien left 11:16 SamuraiJack left, espadrine_ is now known as espadrine 11:18 fhelmberger_ joined 11:19 kaare_ left, sqirrel_ left
moritz ab5tract: I have a local fix for the error reporting in the setting 11:19
11:19 kaare_ joined
moritz ab5tract: (or at least for one flavor of it :-) 11:19
ab5tract: I'm spectesting now, and if it's all green, push it 11:20
11:20 rindolf joined, fhelmberger left
moritz there be fallout :( 11:25
11:27 rurban left
moritz seems at least some of that fallout isn't new 11:28
11:29 rindolf left
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:29 virtualsue left
moritz oh, maybe my rakudo was behind 11:30
.tell Mouq never mind, I mixed up branches 11:31
yoleaux moritz: I'll pass your message to Mouq.
dalek kudo/nom: 3f26f91 | moritz++ | src/Perl6/World.nqp:
Fix error reporting of undeclared symbols in the setting

for ab5tract++
11:31 Kristien joined, Kristien left 11:34 xfix joined 11:35 je5finger joined
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, zakharyas joined 12:03 virtualsue joined 12:05 virtualsue left 12:13 fhelmberger_ left
ab5tract moritz: i've rebased my branch against upstream/nom but it still produces the same error message :/ 12:13
12:18 fhelmberger joined
ab5tract i must have broken it good :) 12:19
12:21 rurban joined 12:26 Kristien joined 12:27 Kristien left 12:28 xfix left 12:29 xfix joined, xfix left 12:30 xfix joined 12:31 pierrot joined 12:33 jferrero joined, jferrero left, jferrero joined 12:35 xfix left 12:36 xfix joined, Kristien joined 12:38 rmgk_ joined, rmgk left, rmgk_ is now known as rmgk 12:43 KCL joined 12:46 KCL_ left
FROGGS ab5tract: what's your repository/branch? 12:48
12:49 fhelmberger left
ab5tract FROGGS: github.com/ab5tract/rakudo/tree/univ-set-ops 12:49
12:49 noganex_ joined
ab5tract i'm imagining it is a subtle syntax error in there somewhere 12:49
12:51 sqirrel_ joined, kaare_ left 12:52 Psyche^ joined
pmurias Kristien: what do you need your self modifying llvm functions for? 12:52
12:53 fhelmberger joined
Kristien replacing call sites 12:53
12:53 dagurval_ joined
Kristien but nevermind that, I found a much better alternative to my actual problem 12:53
12:54 fhelmberger_ joined, andreoss joined, fhelmberger left
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
I did not spot the error fwiw
12:56 anaeem1_ left 12:57 noganex left, Patterner left, dagurval left, dayangkun joined 12:58 dayangkun left 13:00 nige1 left
Kristien pmurias: it makes no semantic difference if I can't do this, luckily 13:02
But I think the optimisation isn't worth it.
what do you do in Perl if someone starts a thread in a BEGIN phaser? 13:04
does the compiler join it? 13:05
13:05 _mg_ joined, yeahnoob joined
FROGGS Kristien: at shutdown time, yes 13:06
Kristien gist.github.com/rightfold/3603bdbd3d366e0cf267 13:07
hoelzro o/ #perl6 13:08
FROGGS hmmmm, jnthn said the VM would join all threads
hi hoelzro
13:10 zlad left 13:12 virtualsue joined 13:15 muraiki_ joined
ven m: BEGIN { await start { say 'hayyy' } }; say 'hi'; END { start { say 'well' } } 13:17
camelia rakudo-moar 3f26f9: OUTPUT«hayyy␤hi␤well␤»
ven m: BEGIN {start { say 'hayyy' } }; say 'hi'; END { start { say 'well' } } 13:18
camelia rakudo-moar 3f26f9: OUTPUT«hayyy␤hi␤well␤»
hoelzro ab5tract: I think the problem may be with multi sub infix:<<(>)>>(Any $a, Any $b --> Bool)
working against bececd4, if I remove the code you changed there, it compiles 13:19
13:19 lizmat joined
psch what hoelzro said, $c and $d aren't declared in that sub 13:20
m: END { sleep 4; say "yawn" }
camelia rakudo-moar 3f26f9: OUTPUT«yawn␤»
ab5tract hoelzro++, FROGGS++, psch++, moritz++; # thanks! 13:21
i knew it would be stupid
hoelzro the error message itself intrigues me, though
13:25 virtualsue left
Kristien I have yet another idea for a new programming languag.e 13:25
13:29 sqirrel_ left
psch hoelzro: isn't the error message just a symptom of compiling the SETTING without itself? 13:29
13:31 gaston left, sqirrel_ joined 13:32 skids left
lizmat .botsnack 13:33
yoleaux :D
lizmat PSA: the P6 Weekly will be done by me tomorrow
nine lizmat++ # looking forward to that :) 13:34
lizmat just woke up from a *long* night of sleep after the FOSDEM
ab5tract lizmat++ && "welcome back!" # :)
lizmat and tonight's its Amsterdam.PM meeting with the associated travel, dinner and fun :-)
13:35 _mg_ left 13:37 Kristien left
pmurias Kristien: so you switched from targeting js to targeting llvm? 13:38
ven lizmat++ 13:39
pmurias: it's sure nice that llvm targets JS :P 13:40
emscripten will rule 'em all
hoelzro psch: yeah, but it's some crazy message about a method call on X::Declared, right? 13:44
it would be nice the original error were allowed to propagate
13:45 Sqirrel left
pmurias ven: emscripten is a bad target for dynamic languages 13:45
ven it definitely is 13:46
I wasn't suggesting a llvm backend for perl6 (though I can guess others proposed it)
pmurias a lot of people proposed a llvm backend for perl6 13:47
in reality we would need to use llvm+moarvm 13:48
13:49 Mouq joined
nine People get confused by llvm's name and think it's a VM. 13:49
13:50 rindolf joined
geekosaur it "is" one but not in the same sense as they mean 13:50
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
psch at least that's my understanding...
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?
our pack and unpack routines don't support that yet
ven nine: I think it *can* be a vm, right?
FROGGS moritz: that's basically what we are doing 13:53
ven I thought it had jit-like/shaped tools
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
FROGGS: you are? where/how?
FROGGS moritz: since a buffer is a VMArray, and can now cast VMArrays to something else
moritz FROGGS: also the reverse? 13:54
FROGGS casting to VMArray is in the works, or at least on my todo list :o)
moritz FROGGS: how would casting from VMArray to Num work? 13:55
FROGGS though, you cannot cast from a single num to something else
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]
moritz FROGGS: and how does it look like? is there an op for that?
FROGGS NativeCall exports sub nativecast(target, source)
13:57 muraiki__ joined
FROGGS nativecast(MyClass, $ptr) might be the most used case 13:57
moritz well, pack and unpack are in core
so I can't rely on NativeCall there
FROGGS but NativeCall isnt (yet)
13:58 Mouq left
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
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)
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
pmurias ven: it has jit-like tools
13:59 Khisanth left
geekosaur you would target something like moarvm to llvm 13:59
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 muraiki_ left
ven pmurias: right, that's probably what I read about once upon a time then, thanks 14:00
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
which is really nice if you're doing HPC, but not so helpful for perl6
FROGGS moritz: see this irc snippet: gist.github.com/FROGGS/6464777
14:01 Khisanth joined
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:02
moritz FROGGS: I really like that 14:03
FROGGS moritz: also that NativeCall would become part of rakudo? 14:04
14:04 nige joined
pmurias ven: it seems to be use in the newish webkit javascript implementation as a jit 14:04
ven: so it's likely it would be possible to plug it into moarvm 14:05
moritz FROGGS: no objections to that either
FROGGS awesome
pmurias ven: not sure how useful that would be
ven pmurias: oh, that's interesting. What I read said it was real bad, but that's probably outdated information now 14:06
14:06 sqirrel_ left
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:07
FROGGS moritz: true 14:08
pmurias ven: it's used only for the more longer running code as one of many jits
ven oh, yeah, webkit.
FROGGS moritz: otherwise we would have two different (insufficient?) ways to pack/unpack things
moritz: and I really enjoy the NativeCall way 14:09
moritz FROGGS: btw it would be very nice if .pack could take an optional target type, like .pack(Buf[uint32]) or so 14:11
14:12 Kristien joined
moritz m: say Buf.new().REPR 14:13
camelia rakudo-moar 3f26f9: OUTPUT«VMArray␤»
moritz m: say Blob.new().REPR
camelia rakudo-moar 3f26f9: OUTPUT«VMArray␤»
Kristien pmurias: yes I did
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
arnsholt retupmoca: *ping* 14:16
ab5tract (NativeCall --> core/NativeCall)++
Kristien with Boost.Coroutine
arnsholt Any particular reason the commit moritz mentioned checks the type, or just a bug?
ab5tract don't see any reason against it :)
Kristien I think Emscripten is out of the question
retupmoca moritz: I did that so I could define a sub like: 'sub foo(Buf) is native' 14:17
because I'm pretty sure that's checking the signature, not the values you pass in
moritz retupmoca: yes, but my question is, all the other checks are for the REPR, not for the type itself
retupmoca m: say Buf.REPR
camelia rakudo-moar 3f26f9: OUTPUT«Uninstantiable␤»
moritz retupmoca: why not this one too?
oh
m: say Buf[uint8].REPR 14:18
camelia rakudo-moar 3f26f9: OUTPUT«Uninstantiable␤»
moritz m: say Buf[uint8].new().REPR
camelia rakudo-moar 3f26f9: OUTPUT«VMArray␤»
retupmoca right - I didn't want to put 'new' in all my signatures
moritz retupmoca: ok. I'll clean it up a bit anyway
retupmoca: using ~~ Blob looks much saner to me than comparing the type names 14:19
m: say Buf ~~ Blob
camelia rakudo-moar 3f26f9: OUTPUT«True␤»
retupmoca yeah, that's cleaner - not sure why I pulled out the name
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
14:21 yeahnoob left
dalek volaj: 27d9263 | moritz++ | lib/NativeCall.pm6:
Clean up type_code_for
 14:21
14:22 yeahnoob joined
dalek p-js: b12ccd4 | (Pawel Murias)++ | src/vm/js/old-nqp-runtime/ (2 files):
Remove old runtime module.
 14:23
p-js: b4c5d10 | (Pawel Murias)++ | src/vm/js/ (2 files):
Simple uncatchable exceptions.
p-js: 8d4b309 | (Pawel Murias)++ | src/vm/js/QAST/Compiler.nqp:
Remove dead code.
p-js: 42b757a | (Pawel Murias)++ | src/vm/js/ (3 files):
Partial deserialization of closures and contexts (we don't deserialize the lexicals yet).
[Coke] hoelzro: ahhh, think I found my problem: left off a --gen-parrot in my config. :|
14:33 Kristien left 14:34 kaleem left 14:37 colomon left
moritz tadzik: does panda do any shebang rewriting? 14:39
tadzik moritz: nope
moritz tadzik: should it? star does it
tadzik I don't see why it should 14:40
moritz tadzik: see rt.perl.org/Ticket/Display.html?id=123497
tadzik so, p6doc doesn't have its own shebang, and the question is whether panda should add it for it
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 kjs_ left
tadzik good point 14:42
yeah, I guess it should then
I opened a bug 14:43
moritz tadzik++
_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
_sri: my personal preference is to call it "perl6 2015.12" or so 14:47
14:47 konsolebox left
_sri just don't make it the last one 14:47
14:47 colomon joined, chenryn joined
moritz well, if we follow semver, we'd need at least one more dot 14:48
14:48 Rounin left
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
btyler it's more to do with the perl5/perl6 "sister language" thing
14:49 colomon left
dalek ar: 544dd76 | moritz++ | tools/star/Makefile:
Bump rakudo/nqp/parrot/moar versions
 14:49
ar: 5a93581 | moritz++ | modules/ (17 files):
Bump module versions
ar: 52105c5 | moritz++ | / (2 files):
adopt versions in tools/build/Makefile.in and README
ar: 33346aa | moritz++ | tools/build/panda-state.p6:
Avoid warning in tools/build/panda-state.p6
14:50 colomon joined
Peter_R If it is Perl 6.0.0 that will be very confusing, far too similar to the whole Python debacle 14:50
_sri not just confusing, there would be two separate communities claiming the name perl 14:51
Peter_R _sri, still sounds like Python to me ;_ 14:52
PerlJam There are *already* two communities claiming the name perl
Peter_R *;)
PerlJam (Though I don't think they are quite 'separate' yet)
14:52 KCL left
Peter_R I don't even think of Perl 6 as being, semantically, the same as Perl 14:52
It is like calling an apple and orange
14:53 chenryn left
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
PerlJam Peter_R: no, it's more like calling "homo sapiens" and "homo habilis" both primates.
moritz but both apples and organes are fruit
Peter_R PerlJam, that would be calling both programming languages
moritz can't we identify "Perl" with "fruit", "Perl 5" with "apple" and "Perl 6" with orange?
14:53 NewbiePig joined
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....
Perl 6 that is
moritz Peter_R: citations needed
PerlJam heh
Peter_R This is my view as an external observer of course
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?
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)
moritz Peter_R: lots of different opinions can exist on this one
Peter_R Thinking about it logically, that's what I decided anyway
moritz Peter_R: and since you're in here, you're not an outside observer
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
_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
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
*name and version system
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
at least if S02 didn't change while i wasn't looking
Peter_R psch, in very basic cases though?
mst psch: since 2009 both languages have been clear on being sister languages
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
and this is fine
since it's also trying to be a BETTER onde
PerlJam bets TimToady didn't realize that the toughest part of Perl 6 would be minutiae about the name.
Peter_R unless you have realistic aims this is all going to crash and burn...
I mean that in the nicest possible way
I can't wait for 1.0 :)
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
14:59 chenryn joined
psch i was speaking in "eventually", sorry for friction 14:59
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
15:00 kjs_ left
lizmat commute to Amsterdam& 15:00
15:01 lizmat left
mst psch: we'll never get to the eventually if we manage to destroy the community in the now 15:01
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 ...")
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
moritz: larry called it that in his talk
PerlJam huf: names do matter in as much as they provide identity to the community
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
psch mst: i agree with that. i don't think releasing as "Perl 6.0.0" would be a good idea 15:04
if anything, i'm with moritz on the versioning, "Perl 6 $year.$month"
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)
moritz mst: so with the exception of TimToady, we're in violent agreement?
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
(i.e. he might not even be an exception, he might just not have chosen to have a significant opinion)
15:06 anaeem1_ joined, anaeem1_ left
mst I wouldn't be surprised if we got pushback from lizmat as well 15:06
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 :)
PerlJam huf: without the names to rally behind, no one knows which side of the "war" they are on ;) 15:08
huf hah.
sure they do. on one side stand the awk/sedders and on the other the haskelljava people
moritz mst: 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
dalek line-Perl6: eaf6232 | (Stefan Seifert)++ | / (8 files):
Get rid of Inline::C to gain more control over the linker
 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'?
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);
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␤␤»
ugexe runme2 takes the NQPMatch type, where runme1 does not 15:12
moritz ugexe: have ouy tried (Mu $arg) ? 15:13
15:14 telex left
ugexe that works. is that what *@ defaults to then instead of Any? 15:14
moritz ugexe: *@ simply doesn't do any type checking 15:15
15:15 muraiki__ is now known as muraiki_
huf mst: dunno, i feel like i was present for at least some of this sad pointless affair 15:16
15:16 telex joined, NewbiePig left 15:19 Peter_R left 15:20 lizmat joined
geekosaur (backscrolling) ...this might be the first time I've ever seen haskell and java lumped together, even ironically... 15:20
15:21 Peter_R joined
huf i tried to say something bad about p6 that's on par with calling p5 awk/sed :) 15:22
adding "java" to something is a cheap win
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
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
FROGGS nine: you have to provide the libname again, for every symbol you map 15:26
15:26 chenryn left
FROGGS nine: but don't worry, the library will only be loaded once 15:26
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:27
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:29
or put differently: NativeCall needs to now the library handle, and you can't provide it in another way 15:30
15:41 lizmat left
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
So now there's just this darn libperl6_ops_moar.so problem left
15:45 gfldex joined 15:49 MadcapRusso left
dalek Iish: 488b924 | moritz++ | t/41-sqlite-exec-error.t:
Do not fail tests in libsqlite3 cannot be found
 15:50
15:50 lizmat joined, kaleem left
dalek p: e489b4f | FROGGS++ | src/vm/parrot/6model/ (2 files):
[parrot] add repr lookup for use in e.g. nqp_dyncall.ops
 15:51
p: 8d28eb2 | FROGGS++ | src/vm/parrot/ops/nqp_dyncall.ops:
[parrot] allow to pass VMArrays (Blob) to native subs
15:52 skids joined 15:54 yeahnoob left
moritz fwiw I'd propose we drop Math::Model and Math::RungeKutta from start 15:58
*star
I don't think they are universally useful
maybe add HTTP::UserAgent 15:59
15:59 mr-foobar joined
FROGGS +1 15:59
moritz though not for the January release
16:05 konsolebox joined, lizmat left 16:07 je5finger left
dalek kudo/nom: 21ca410 | FROGGS++ | tools/build/NQP_REVISION:
bump nqp rev for nativecast improvements on parrot
 16:08
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:13
FROGGS \o/ 16:14
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:15
But I figure better to have some fast checksumming for Star users. 16:16
FROGGS aye 16:17
I guess we will come up with a proper fallback mechanism at some point
16:17 konsolebox left, adu joined
skids Maybe the NativeCall Hackathon could spend some time on that problem. :-) 16:17
FROGGS that mind be too hard for the first hackathon :o) 16:18
16:22 _mg_ joined 16:24 firefish5000 joined
_mg_ Homebrew formula for rakudo-star is now updated to 2014.12.2: github.com/Homebrew/homebrew/commi...d4e83bd0c. Thanks to everyone involved and especially moritz for creating a new release. 16:24
16:24 anaeem1 joined
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)
_mg_ sorry, that was copy&paste
not intended 16:25
jnthn .tell pmurias Well, you can scan the closures table and see if it shows up in there...
yoleaux jnthn: I'll pass your message to pmurias.
moritz you're welcome
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...
dalek p-js: a3e787a | (Pawel Murias)++ | src/vm/js/QAST/Compiler.nqp:
Also add params to $*BLOCK.variables.
p-js: 28c6555 | (Pawel Murias)++ | src/vm/js/ (4 files):
Pass test 56 roles.

When deserializing contexts also restore values of lexicals.
FROGGS jnthn: I solved the issues that I had last night btw (about nqp@parrot and nativecall)
jnthn: this was buggy code that led me on the wrong track: github.com/perl6/nqp/commit/8d28eb...875a7eL888 16:27
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 :/
pmurias jnthn: in the closure table it's possible to refer to static code refs from other serialization contexts
jnthn pmurias: oh, yeah
16:29 _mg_ left
jnthn pmurias: Your question was probably on the "other side" of the fence... 16:29
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.
dalek ar: 33df4da | moritz++ | modules/zavolaj:
Downgrade zavolaj to a version that works with 2015.01
 16:31
ar: 9f2a9a3 | moritz++ | modules/DBIish:
Bump DBIish version
ar: c46312a | moritz++ | docs/announce/2015.01.md:
Add release announcement for 2015.01
moritz feedback on the release announcement very welcome
dalek p-js: 48c3ae9 | (Pawel Murias)++ | t/qast/02-manipulation.t:
Add a (partial) test for various methods used for handling qasts.
 16:37
moritz m: say $*VM.name 16:38
camelia rakudo-moar 21ca41: OUTPUT«moar␤»
moritz p: say $*VM.name
camelia rakudo-parrot 21ca41: OUTPUT«parrot␤»
pmurias jnthn: currently I can live with emitting some needless stuf
* stuff
16:39 zakharyas left
dalek c: c90029d | moritz++ | t/typegraph.t:
Skip segfaulting tests on parrot
 16:39
FROGGS moritz: that's not a "D", is it? github.com/rakudo/star/commit/c463...ef77092R41 16:41
dalek ar: ab4f6ad | moritz++ | docs/announce/2015.01.md:
Remove accidental use of non-ASCII character, FROGGS++
 16:44
moritz I seem to have problems getting the submodules into a new clone of star 16:47
I've done a git clone --recursive [email@hidden.address]
16:48 Guest22147 joined
moritz and modules/*/ are all empty directories 16:48
Guest22147 hi @all
moritz hi Guest22147
oh, seems I'm missing 'git submodule update' 16:49
Guest22147 I am not familliar with irc
hmm /help does no longer work. How can I change my nickname?
moritz Guest22147: /nick <newnickname> 16:50
16:50 Guest22147 is now known as p6_newbee
p6_newbee ha, thanks 16:50
p6_newbee is dancing
16:50 Rounin joined
FROGGS hi p6_newbee :o) 16:51
moritz: I can't find anything else to criticize :o) 16:52
moritz FROGGS: thanks, wonderful
p6_newbee hi FROGGS
dalek ar: 99a2768 | moritz++ | .gitmodules:
Try to complete the renmaing of rakudo-debugger
 16:53
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 ?
uh, target
pmurias and for an actual QAST object? 16:55
16:55 sqirrel_ joined
pmichaud moritz/others: We might need to get some advance notice in to star release notes about moving from parrot to moarvm 16:56
moritz pmichaud: why? people who want parrot still can use the older versions 16:57
dalek ar: 7ab973e | moritz++ | docs/announce/2015.01.md:
Remove module update item that was copied from last month
pmurias m: my $c = nqp::getcomp('perl6'); $c.compile(:target<ast>, '1')
camelia rakudo-moar 21ca41: OUTPUT«===SORRY!===␤compunitmainline requires an MVMCompUnit␤»
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
pmurias jnthn: the naive approach causes a MoarVM error
pmichaud moritz: yes, that's why I'm bringing it up now
I'm currently working on a summary of FOSDEM discussions for publication, but haven't had a chance to complete it yet 16:58
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
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.
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);
camelia rakudo-moar 21ca41: OUTPUT«QAST::CompUnit␤»
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
pmurias ugexe: thanks
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 nige left
pmurias did you talk with rurban about suspending parrot support? 17:01
moritz pmichaud: on a sentimental level, I can understand that (moer)
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.
moritz pmichaud: 6pe will produce extra work on parrot, afaict
jnthn moritz: The work is already done... 17:02
moritz jnthn: ok
jnthn It's the native stuff that will be more painful
And that I won't port
moritz jnthn: and do you think that will block you before the Feb release?
FROGGS jnthn: leave the non-design stuff for other I'd say
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
jnthn I'm gonna be working on a branch.
FROGGS others*
jnthn I can always wait until after Feb release to merge it.
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
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?
moritz pmichaud: I don't see much need for migration
nine distro packages?
moritz pmichaud: most everybody already uses MoarVM, and the start 'modules-test' consistently has better results on moar than on parrot
pmichaud moritz: how can you say that?
It's not just migrating to moarvm, it's migrating to a post-glr rakudo
17:04 [Sno] left
moritz pmichaud: oh yes 17:04
pmichaud: that's a different thing, and migration will be required 17:05
pmichaud right, and rakudo star's philosophy is stability over newness
pmurias any large planned changes on the lower level that might affect nqp-js?
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)
moritz aye
pmichaud and rakudo star explicitly chooses to stick with older versions of the compiler to emphasize continuity and stability 17:06
17:06 [Sno] joined
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.
moritz also we can decide to pause post-GLR rakudo star release
until the ecosystem has caught up
pmurias jnthn: native references?
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.
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"
pmurias jnthn: is it a rakudo things also also something in nqp?
moritz pmichaud: +1 17:08
jnthn pmurias: It'll need doing at NQP level
pmurias s/also also/also something
jnthn pmurias: Rakudo will use it.
pmichaud thus I'm working on a recap and announcement about parrot support lagging after february 2015 release
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.
moritz pmichaud: I have a feeling that you'll formulate it better than I might
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
pmichaud moritz: I'll see if I can do that. My schedule the next two weeks is really crowded with non-p6 stuff. :-/
btyler: noted 17:10
moritz pmichaud: ok; if nothing is in by the time I want to release, I'll write somthing myself
pmichaud moritz: eta to release?
moritz pmichaud: tomorrow or Thursday
pmichaud okay. I'll try to have something in by tomorrow.
17:11 Mouq joined
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, fhelmberger_ left
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
FROGGS[mobile] how shall we call it? 17:13
nwc10 "General Availability"
?
17:13 FROGGS left
pmichaud I don't know what to call it yet. I think "Version 1.0" and "the release" are bad choices. 17:13
also, I fear that "Version 1.0 of Perl 6" confuses language spec and compiler implementation again. 17:14
17:14 pmurias left
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
nwc10 +1 +2 +3 +5
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'
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 fhelmberger left
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.
mst since while it misses the compiler/spec distinction, it at least makes it clear that perl6 is a language in its own right
pmichaud it's just a reminder to the perl6 bubble that we really need to get our sanctioned set of language in place
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"
but exactly which 'something like' is for you guys to decide and then document 17:19
pmichaud mst: +1 17:20
in particular, I think we may want to be very careful about tying language releases to a given compiler's release 17:21
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
masak pmichaud: +1 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
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
mst there should never be any such thing as 'Perl 6.0.0' 17:26
there should be 'Perl 6 1.0'
17:26 espadrine left
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
mst and it'll become 10x harder to encourage people invested in perl5 to regard perl6 as a good thing rather than a threat
pmichaud I think I agree that "6.0.0" isn't a good path for version numbering. 17:27
itz_ 15-12
pmichaud I'm wondering how often we expect there to be language updates
FROGGS[mobile] in the next 30+ years? 17:28
jnthn itz_: 3
17:29 MadcapJake joined
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:29
jnthn nine: Oh? Odd... 17:30
17:30 Kristien joined
nine jnthn: there may be others, but this one is the first missing and then it barfs 17:31
Kristien hi
mst /* 1 if by land, 2 if by sea, 0 if out of memory, not allowed to barf */
jnthn nine: Does looking at the libmoar.so symbols (maybe with nm) show it? 17:32
17:33 xinming_ joined 17:34 alini left
japhb catches up with backlog ... 17:34
*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
17:35 xinming left
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:35
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.
pmichaud japhb: year.month doesn't have to imply monthly release. See ubuntu.
japhb (Which, for 2016, we actually might ...)
itz_ 15Q4
pmichaud I'm wondering if even just doing something like "Perl6 2015a"
japhb pmichaud: Yes, but that's a distro, parallel to R*. I'm talking about the *spec*
That actually seems reasonable. 17:37
17:37 KPTN left
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:37
japhb Re: Fast conversion between Num and Buf: Please? Pretty Please? With Whipped Cream on Top? :-) 17:38
pmichaud: yes, that.
pmichaud or at least a different cadence.
and in that context, the traditional "6.major.minor" sequence doesn't quite fit the cadence
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
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 trone left
colomon +1 (assuming no major technical objections) 17:42
17:43 sqirrel_ left
jnthn japhb: Do you mean "in CORE.setting" or "shipped with Rakudo"? 17:44
17:45 virtualsue_ joined 17:47 virtualsue left, virtualsue_ is now known as virtualsue
moritz fwiw I mean "shipped with Rakudo" 17:49
doesn't need to be CORE.setting, IMHO
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.
El_Che pmichaud++ for the ansi C inspired for specs
pmichaud: on the other hand, don't say spec! ;) 17:51
jnthn dinner &
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:53
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?
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 )
PerlJam ... and because I'm such a good juggler, they are all redirected :)
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.
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
11:31Z <moritz> Mouq: never mind, I mixed up branches
itz_ reference compiler? 17:59
PerlJam Mouq: S21 may need a little more love too
pmichaud I don't believe that Rakudo will be the reference compiler.
moritz itz_: it compiles references to broken links on perl6.org :-)
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
PerlJam heh 18:01
pmichaud sure, but catchy is good only if it doesn't also imply all sorts of unwanted inaccuracies
moritz "#perl6 recommended compiler"
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.
itz_ leastbroken compiler
PerlJam itz++ 18:02
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)
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"
pmichaud clearly once Rakudo is passing some level of Perl 6 language spec we can remove the "development release" moniker. 18:04
I'd even be willing to remove that notion once GLR/NSA/NFG are done.
moritz (and the star relases as "early adopter")
dalek c: 3570802 | moritz++ | lib/Type/Routine.pod:
remove a done TODO item
 18:05
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
18:07 nige joined
pmichaud if we encourage that belief, we're doing them (and the language and community) a huge disfavor 18:07
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
... regarding Rakudo, I mean.
PerlJam pmichaud: agreed. But you still have to communicate with them in ways they understand.
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
b2gills: yes, that's always been the way it's worked. 18:10
"Perl 6" is the language, never an implementation.
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. )
ribasushi pmichaud: while defining the distinction it is also quite important to state upfront what is considered a "camelia-compatile interpreter"
there was a lot of FUD surrounding the python family (python / ironpython /jython / others)
b2gills japhv: exactly .++ 18:11
pmichaud ribasushi: a camelia-compatible interpreter is one that passes the set of tests defining Perl 6
ribasushi due to not supporting exactly the same set of things when the language itself is concerned (battery-inclusion aside)
pmichaud this is exactly what Synopsis 1 says :)
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 )
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:12 dakkar left
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?
moritz
.oO( This is Rakudo 2015.12, targetting the Perl 6 2015.12 language )
japhb moritz: That sounds like a README intro, not a release announcement, which is what I was aiming for.
pmichaud japhb: yes, that matches the intent. The harder part is declaring a Perl 6 release
PerlJam japhb: you could draft the Christmas release announcement with that text and I wouldn't be unhappy :)
japhb In order to think about how we would talk to the world outside our echo chamber.
pmichaud japhb: you gave a compiler release, not a language release. 18:14
japhb Ah, OK, let me try that.
moritz "This is Perl 6 2015.12, a set of language design documents and tests"
pmichaud also, per my fosdem talk, we really need to digest the notion that language spec releases need to be retrospective, not future-spective
moritz maybe with the order reversed
pmichaud: have you put up the slides somewhere? 18:15
pmichaud not yet, I will do that in ~30m
japhb
.oO( The Perl Foundation is proud to announce the completion of version 2015a of the Perl 6 language specification test suite. )
PerlJam japhb: "completion"?
japhb Yeah, that word I don't like either.
pmichaud publication
japhb ruminating on a replacement 18:16
pmichaud: yeah, publication sounds better
PerlJam japhb: what pm said
El_Che pmichaud: If ok, i'll put it in the fosdem page (as I wrote in the mail)
japhb
.oO( The Perl Foundation is proud to announce the publication of version 2015a of the Perl 6 language specification test suite. )
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.
japhb: now, tie it to compilers
.oO( This version of Perl 6 is known to be implemented by the Rakudo-MoarVM compiler...)
 18:17
El_Che pmichaud: great
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
japhb pmichaud: Yeah, that seems close to what I was thinking.
nwc10 it was close to what I'd been sort of thinking of from another direction
which was how to stop people being afraid of upgrading
pmichaud let me dig up my laptop and get my slides published
I don't know that my talk was recorded successfully at FOSDEM. Perhaps I should record it myself 18:18
as in re-record and publish for this group
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?"
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
18:19 FROGGS joined
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
pmichaud japhb: maybe, except that I (now) think that language spec will come after language implementation, not before
I really think we need to break the cycle of believing that specification comes first.
nine Could someone please have a look at this PR and tell me if it's sane and/or mergeable? github.com/rakudo/rakudo/pull/359
japhb pmichaud: Hmmmm, OK, how about 18:20
.oO( Rakudo-MoarVM, the leading Perl 6 compiler, reached full compliance with this version of Perl 6 in its 2015.09 release. )
El_Che fosdem used a technically better and new video recording system (with a new video team). Sadly there were many problems
PerlJam japhb++
nwc10 how many of the ISO specified languages had the spec come first?
pmichaud japhb: "reached" is wrong. 18:21
japhb: it still implies that language spec came before implementation
nwc10 the C, C++ and Ruby specs certainly postdate language implementations
(Ruby is technically still a draft spec, isn't it?) 18:22
PerlJam didn't even know ruby had a spec
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)
pmichaud nwc10: basically every (successful) language since ALGOL68 had its spec published after it was implemented
vendethiel nwc10: I don't even think it exists.
if you'retalking about rubyspecs, it's abandoned
pmichaud japhb: that's not the usual thing at all
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 )
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? :-)
nwc10 vendethiel: www.iso.org/iso/iso_catalogue/catal...mber=59579
aha, "Preview"
japhb pmichaud: Oh, I had no intent about timing between stages.
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
japhb And actually, I was thinking about all kinds of technical specs, from WiFi to C++.
pmichaud In reality, it doesn't happen that way.
japhb pmichaud: Agree that that's a myth.
pmichaud Most notably, Internet Specifications happen only after there are two independent implementations of whatever they specify.
PerlJam nwc10: so the next question is ... when will Perl (5 or 6) get an ISO spec? :)
japhb Sadly in some fields, it just seems like who's the biggest bully in the spec committee, pushing the thing they already implemented.
pmichaud (actually called "Internet Standards") 18:25
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.
japhb Nodnod
pmichaud I have trouble with the "special enough" moniker. 18:27
So no, I don't want to indicate that.
There's no reason that something implemented in a Pugs or Niecza couldn't be used as the basis for spec. 18:28
japhb
.oO( This version of Perl 6 was first implemented by release 2015.09 of Rakudo-MoarVM, the leading Perl 6 compiler. )
pmichaud is "first implemented" important?
I don't think it is.
japhb
.oO( This version of Perl 6 is implemented in release 2015.09 of Rakudo-MoarVM, the leading Perl 6 compiler. )
pmichaud and is it important to talk of a "leading Perl 6 compiler"? 18:29
why is this being viewed in terms of a race, or competition, or ... ?
japhb I actually think that one is.
pmichaud "popular", maybe.
japhb For the plurality-but-not-monopoly aspect I was referring to.
s/leading/most popular/?
pmichaud why the superlatives? ("the most popular", "the leading", ...) 18:30
it sounds like trying to annoint one compiler over others
might as well just call it "official" if you're going to do that.
japhb For the reasons that others brought up about marketing communications.
ugexe perl6 ecosystem seems to be missing MIME::Base64?
itz_ "suggested"?
skids Well, you don't want interested people going and somehow managing to download pugs.
japhb And you wanted to tie the compiler and the spec, yes?
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
I'm fine with "recommended"
japhb I'm trying to avoid the release announcement making Rakudo sound like the Amaya of Perl 6 compilers.
18:32 pecastro left
japhb
.oO( This version of Perl 6 is implemented in release 2015.09 of Rakudo-MoarVM, the recommended Perl 6 compiler. )
 18:32
Sounds a little stilted
FROGGS the language version could be as short as: Perl 6/15
ugexe yeah no MIME::Base64 anymore in ecosystem-api.p6c.org/projects.json
FROGGS and when there is a sub-year release, it would be Perl 6/15.1
18:33 rindolf left, rindolf joined
PerlJam FROGGS: that will morph into 6.15 and 6.15.1 methinks 18:33
FROGGS .oO( perl6-m --version could be "Rakudo Perl 6 2015.12 on MoarVM 2015.11 compliant to Perl 6/15" ) 18:35
a version triplet of not quite version triplets :o)
dalek line-Perl6: 2fc6bde | (Stefan Seifert)++ | / (4 files):
Clean up unused code and tries to fix linking
 18:36
japhb
.oO( This version of Perl 6 is implemented in release 2015.09 of Rakudo-MoarVM and release 3.1415 of FooBarBaz. )
FROGGS 6/15 looks too much like 08/15 though
japhb Agreed
pmichaud I don't know that I'd have a problem with 6.15 as a language spec number, though.
It certainly makes things like 5.22 look more "normal"
FROGGS ... and we're not sponsored by Stark Industries™ :o)
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?"
FROGGS I like the way C99 is including a year
pmichaud well, Perl 5 is essentially doing year numbers now :)
it's just there's a built in offset, and they increment the number by 2 each year
18:37 _mg_ joined
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")
itz_ I think 6.15 and 6/15 look too much like math operations 18:40
PerlJam itz_: that's a feature! :) 18:41
pmichaud I still prefer "Perl 6 2015a" over "6/15"
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. )
b2gills I was just thinking out loud
japhb Latest iteration ^^
moritz pmichaud: any reasons not to use YYYY.MM for the language version?
pmichaud I don't know that there will be many .MM's in a year. 18:42
I think language specification should be slow and deliberate
if we're publishing more than two per year, that'd be... odd.
FROGGS .oO( "Moony, Wormtail, Padfoot and Prongs are proud to..." )
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!"
FROGGS: EXACTLY
FROGGS pmichaud: I was about to say that
b2gills Perhaps the language version could be 2015, '2015a' ... *
itz_ 2015a is good
pmichaud but language spec should ratify decisions already made and tested 18:44
more to the point, tested by implementations and in "production"
japhb What about the wording I posted about 3 min ago?
FROGGS we cant implement without tests, and we cant spec without a proven implementation... there will be spec releases like compiler releases
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.
japhb Oh sure!
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
FROGGS japhb: but yeah, it has the right announcish character :o)
japhb I mostly was wanting to get a concrete wording implementation to test our plans. :-)
moritz: I thought TPF owned the copyright?
moritz japhb: of what, exactly?
japhb The test suite? 18:46
I hadn't actually checked
itz_ maybe it should be SR? :) shire-reckoning.com/calendar.html
moritz japhb: no
japhb Who does?
moritz japhb: the roast contributors
pmichaud pmichaud.com/2015/pres/fosdem-specs...pecs-1.pdf
moritz japhb: the former wording was "the pugs contributors" :-)
japhb Oh, hmmm.
moritz we don't require a CLA for roast 18:47
japhb That's ... suboptimal at this point, if technically accurate.
pmichaud there's nothing to prevent TPF from announcing that Perl 6 has been published.
they don't have to own something to issue a press release about it.
moritz agreed
japhb True ...
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)
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
japhb (I *don't* object, FWIW)
Fair enough.
pmichaud also, it's possible for TPF to own the "collective work" that is the subset of roast defining Perl 6
without having to own any of roast itself.
japhb pmichaud: Is that USA-specific, or worldwide agreed? 18:50
(Well, to the extent that anything regarding IP has agreement)
pmichaud afaik the US follows the Berne copyright convention for the most part
japhb nod
pmichaud regardless, one can have copyright on a collective work without having to own copyright on every piece of the collection.
japhb Fair enough. 18:51
p6_newbee bye @ all
18:51 p6_newbee left
pmichaud I suspect that's fairly typical of standards-publishing-bodies anyway 18:51
pmichaud.com/2015/pres/fosdem-specs...pecs-1.pdf # my FOSDEM talk slides 18:52
18:52 Sqirrel joined
moritz pmichaud++ # presentation 18:56
pmichaud I'm afk for 15 18:58
japhb pmichaud++ # preso 18:59
PerlJam I've seen quote on slide 18 quite a bit (or words to that effect) 19:00
jdv79 the "Classes are never "final"" could use some clarification maybe 19:01
moritz also not quite correct, iirc 19:02
there's a conjetural "use oo 'final'" or so
19:05 FROGGS[mobile] left, _mg_ left
dalek c: eac25f0 | moritz++ | / (5 files):
Try to make update-and-sync more robust

also move sync to util/		 19:05
line-Perl6: e2fe4e0 | (Stefan Seifert)++ | / (2 files):
Replace a lot of hard coded paths by asking perl6 during build

This is most probably still wrong, but will at least work on UNIX systems with a locally installed rakudo		 19:06
nwc10 nine: sorry, no clue on dynamic linking pain 19:08
nine nwc10: if this github.com/rakudo/rakudo/pull/359 is acceptable the pain is over :)
Mouq pmichaud++
dalek rl6-roast-data: 299d096 | coke++ | / (5 files):
today (automated commit)
 19:14
c: f23c38f | moritz++ | lib/Type/Signature.pod:
Try to unbreak the htmlify build

it seems to not like X<> links without a comma		 19:17
c: 3726d0f | moritz++ | htmlify.p6:
Remove debugging output
[Coke] is a Block a Callable? seems to be a Code... a Sub is eventually a Block. what are callables?
moritz [Coke]: Callable is a role 19:18
m: say $_ ~~ Callable for Block, Code
camelia rakudo-moar 21ca41: OUTPUT«True␤True␤»
moritz [Coke]: see doc.perl6.org/type/Callable for the type graph 19:19
19:21 lizmat joined
dalek : f27427e | sergot++ | misc/gsoc-2015/ideas.md:
Im interested in working on the bundling project
 19:22
FROGGS jnthn: nativecasting to a VMArrayInstance is quite tricky on the jvm it seems... 19:23
pmichaud back again
Kristien oh boy
dalek line-Perl6: 2bc1ad7 | (Stefan Seifert)++ | / (3 files):
Replace hard coded path to Inline/Perl6.so by asking DynaLoader
Kristien my LLVM stuff works
pmichaud Applications can declare things to be final; but classes cannot declare themselves to be final
FROGGS jnthn: because all I have i a memory address, and the VMArrayInstance has a public long[] slots;
19:24 rindolf left
pmichaud PerlJam: (slide 18) I've heard or read that sentiment more times than I care to count. 19:25
I think our collective delusion of "spec before implementation" was a key contributor to that, though. 19:26
19:27 abraxxa left
dalek line-Perl6: 9836e5f | (Stefan Seifert)++ | t (2 files):
Beginning of a test suite :)
 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
oted to various rakudo backends at this point. I think it's ok to prefer rakudo in 2015. 19:31
moritz [Coke]: cut off after "which are dev" 19:32
lizmat [Coke]: TimToady said as much in his presentation
[Coke] m: say { $^x } ~~ Callable
camelia rakudo-moar 21ca41: OUTPUT«True␤»
[Coke] lizmat: ok. haven't seen it yet, was responding to backscroll, but I think it got there anyway. 19:33
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, lizmat left 19:38 lizmat_ is now known as lizmat
pmichaud I don't mind with expressing a temporary preference. 19:40
19:40 Hor|zon joined
pmichaud I do think any sort of permanent designation is a bad idea. 19:41
dalek line-Perl6: af843dd | (Stefan Seifert)++ | / (3 files):
Allow evaling arbitrary Perl 6 code from Perl 5
pmichaud TimToady actually went further than "Rakudo" in his talk; he said "Rakudo on MoarVM".
19:41 atta left, atta joined 19:45 Hor|zon left
avar In particular he said that if some of the other implementations aren't ready and broken at that time that's fine 19:46
japhb is uncomfortably excited about this year ... and trying to figure out what he wants to have prepared for Christmas 19:48
One must plan ahead, you see ....
dalek kudo/nom: 195b028 | moritz++ | README.md:
Fix news aggregator link
lizmat avar: which spells bad news for rakudo on parrot
PerlJam japhb: A good advent article? :)
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 kudo/nom: f93da64 | (Stefan Seifert)++ | tools/build/Makefile-Moar.in:
Fix missing symbols when loading libperl6_ops_moar.so from a dlopen'ed libmoar.so
kudo/nom: 5b49077 | jnthn++ | tools/build/Makefile-Moar.in:
Merge pull request #359 from niner/nom

Fix missing symbols when loading libperl6_ops_moar.so from a dlopen'ed libmoar.so
19:50 ppp joined 19:51 ppp left, rurban left 19:52 Hor|zon joined
nine jnthn: thanks :) 19:54
dalek Heuristic branch merge: pushed 21 commits to rakudo/newio by lizmat 20:04
c: 566fa31 | moritz++ | lib/Type/Mu.pod:
Start to document "is export" on types
 20:07
20:11 alini joined 20:13 darutoko left
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?
synopsebot Link: rt.perl.org/rt3//Public/Bug/Displa...?id=123702
20:18 sivoais left 20:24 mohij joined, FROGGS[mobile] joined 20:25 _dolmen_ joined
dalek kudo-star-daily: 8f89581 | coke++ | log/ (10 files):
today (automated commit)
 20:32
c: 7a6e100 | moritz++ | util/update-and-sync:
Try to fix update-and-sync
 20:34
20:35 Rounin left
masak very interesting backlog about versioning and then about the exact role of specification vs implementations. 20:35
dalek c: c827a80 | moritz++ | CREDITS:
CREDITS: fix team
masak now I'm eager to leaf through pmichaud++'s presentation. 20:36
by the way, I made this: gist.github.com/masak/ae7677e5c2ccc7f37f97 -- it's a quick histogram of Rakudo commits over the years, divided into months.
sjn sadly missed pmichaud's talk :-(
masak I made it because I felt that Rakudo activity has been consistently high lately.
20:36 anaeem1 left 20:37 Maddingue joined
masak well, it's not that visible in the histogram, but it certainly has been high. 20:37
moritz masak++
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.
2011 is a bit wonky because that's the only time Rakudo was working in a branch. (ng) 20:38
but we *did* just have the best January ever.
I hereby license the code in that gist as cc-by. do cool stuffs with it.
masak reads pmichaud.com/2015/pres/fosdem-specs...pecs-1.pdf 20:39
20:39 _mg_ joined
masak notices that "Perl 6.0.0" is used on slide 3 20:41
20:41 atta left
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
20:42 sivoais joined
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
masak my remark just now should be read in light of that. 20:45
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:46
20:47 sivoais left
masak pmichaud++ # slide 18 20:47
I've always disliked that one, too.
pmichaud for me, the move against "6.0.0" numbering actually didn't come from a p5 perspective. 20:48
masak oh, innerestin'
pmichaud it's more about what I think a language spec should be.... I think language evolution is a slower pace than software implementation
or, it should be a slower pace
and 6.0.0, or any version-major-minor scheme, implies far more frequent updates than I think healthy for a language spec. 20:49
I started thinking about language spec releases, and wondering if we should do periodic releases like we do for the compiler. 20:50
and my first counter-thought was "well, perhaps, but certainly not monthly"
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
pmichaud exactly. 20:52
moritz warms up to YYYY<alpha>
FROGGS[mobile] also because major.minor.patch has nothing to do with cyclic releases
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
20:53 sivoais joined
Juerd m: say "foo" 20:53
camelia rakudo-moar 5b4907: OUTPUT«foo␤»
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.
even in Internet Standards, they don't version them beyond a simple 1-2-3 numbering scheme.
jnthn nine: Welcome. iPhone = can merge pull requests at the pub. :)
Juerd m: my @foo = (-> { 1 }, -> { 2 }, -> { 3 }); say @foo».()
camelia rakudo-moar 5b4907: OUTPUT«1 2 3␤»
Juerd m: my @foo = (-> { 1 }, -> { 2 }, -> { 3 }); say @foo»()
camelia rakudo-moar 5b4907: OUTPUT«===SORRY!===␤Cannot find method 'flat'␤»
Juerd Ah.
masak huh. 20:55
masak suspects rakudobug
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...?"
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».()
camelia rakudo-moar 5b4907: OUTPUT«1 2 3␤»
20:58 [Sno] left
masak pmichaud: I'm intrigued. I bet mst will like that, too. 20:58
20:59 [Sno] joined
jnthn pmichaud: fwiw, my initial gut feeling on the <year><alpha> scheme is a good one. 20:59
21:00 kaare_ joined
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.
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:01
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.
pmichaud or, more precisely, doesn't become the driving force of our development/narrative.
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.
pmichaud I think we can use things like C99 and ANSI C and HTTP to help in the explication 21:03
vendethiel pmichaud++ #specs
jnthn notes that HTTP has done OK with major/minor version numbers :)
pmichaud jnthn: yes, well, two of them. 21:04
dalek line-Perl6: bb88ef0 | (Stefan Seifert)++ | / (2 files):
Allow reading back some ints and strings from EVAL'ed Perl 6 code
jnthn ;)
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?
pmichaud it's notable that RFC 2068 (HTTP 1.0) wasn't published until 1997.
avar nine: I can start trying to brute-force the API in moar.c, but starting with something would be easier
avar zZzzZ
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.
pmichaud jnthn: I'm not sure I agree with that. 21:06
I think the thing that happens on longer timescale might want the year.
nine avar: I've just starting making progress on Inline::Perl6 for Perl 5 :)
skids 80MB file: sha1sum: 0m1.015s NativeCall+libmhash moving 2048-byte chunks: 0m28.347s # getting there.
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++
nine avar: have a look at the code at github.com/niner/Inline-Perl6
pmichaud well, rakudo still has the sequential numbering scheme as well :)
avar nine: cool, thought that was the thing for perl6, will check it out
jnthn pmichaud: Yeah, but...I've no idea what number we're at. :P
pmichaud although we definitely think of releases in terms of time-based. I'm largely to blame for that, I think. :)
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
camelia rakudo-moar 5b4907: OUTPUT«vunknown␤v2015.1.21.g.4.ee.4925␤»
21:08 xfix left
FROGGS[mobile] vunkown :p 21:08
lizmat the former would be 6.major.minor in the future ?
FROGGS[mobile] I still enjoy that one
pmichaud I'm thinking we should avoid 6.major.minor for everything
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
masak FROGGS[mobile]: if you pronounce it with a German accent, this even makes sense: `-Ovunknown`
21:09 telex left
FROGGS[mobile] masak: I dont get it :o) 21:10
masak FROGGS[mobile]: "optimize for vunknown"
jnthn pmichaud: To the degree you're to blame for us thinking of Rakudo releases as time-based - thank you. ;)
21:10 telex joined
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:10
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
We'd want whatever we come up with to work with the Version type, also.
Mouq masak: gist.github.com/Mouq/7bc8bf4228176270cb3a
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.
FROGGS[mobile] pmichaud: that just means it has to start with a number 21:12
m: say v15a
camelia rakudo-moar 5b4907: OUTPUT«===SORRY!=== Error while compiling /tmp/6xqVHxp24b␤Undeclared routine:␤ v15a used at line 1␤␤»
pmichaud FROGGS[mobile]: well, and be able to collate/compare properly.
FROGGS[mobile] ewww
jnthn pmichaud: That is, you'd expect a spec release declared in 2017 to be supported by some compiler release in 2017.
pmichaud jnthn: bzzzzt 21:13
jnthn pmichaud: Because if implementation should come first, well... :)
FROGGS[mobile] m: say v6.2015a
camelia rakudo-moar 5b4907: OUTPUT«===SORRY!=== Error while compiling /tmp/dvYY853Sts␤Confused␤at /tmp/dvYY853Sts:1␤------> say v6.2015⏏a␤»
FROGGS[mobile] pff
pmichaud I'd expect a spec release declared in 2017 to be supported by compiler releases before 2017 :)
as well as the ones coming later, of course. :) 21:14
moritz well, adaptiong version literals should be our smallest problem
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. :)
(The January *before*, I mean.)
moritz if we release languages after they are supported, we have a bootstrapping problem 21:15
the compiler doesn't know the language version yet
so it can't support 'use v6.$someversion'
pmichaud I figure a compiler will always have some variation between what it implements and any given language spec.
moritz and people won't write 'use v6.$someversion' if v6.$someversion isn't released and supported yet
pmichaud if not, then we're back to "compiler defines/implements exactly language x.y.z" 21:16
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
oh, with a + on the end
FROGGS[mobile] that's implicit 21:18
pmichaud Is it?
FROGGS[mobile] aye
pmichaud how do I tell the compiler to go back to the 2015a interpretation of things, then?
FROGGS[mobile] at least. + is implicit
masak Mouq++ # gist.github.com/Mouq/7bc8bf4228176270cb3a
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.
grr, .+
typing is hard
moritz I mean, it could very well support the language, but not yet know about it
lizmat Amsterdam.PM shutting down&
moritz that would suck.
21:19 lizmat left
pmichaud moritz: why would that suck? 21:19
Mouq masak: (it also kind-of works on various other git repos 21:20
)
21:20 gugod joined
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
masak Mouq: didn't think of that :)
nwc10 aren't you just re-implementing parts of www.openhub.net/p/rakudo
masak Mouq: just need to fetch the start and end points somehow, I guess.
nwc10 admittedly, with a current mirror
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
[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
[Coke] note: this level of unicode support is not yet supported.
moritz: it is, honestly, a little late to worry about that. :)
Mouq masak: Yeah, but I was too lazy to actually do that, it just fudges for when the commits start flowing
[Coke] this whole environment we've setup -is- confusing. :)
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
japhb moritz: Yes, exactly
[Coke] japhb: we might support multiple -spec- versions, but not multiple compiler versions of that spec, i would imagine.
pmichaud that's what makes me wonder about the whole "6.0.0" thing.
[Coke] moritz: I don't see that. 21:23
masak pmichaud++ # pmichaud.com/2015/pres/fosdem-specs...pecs-1.pdf
pmichaud: definitely food for thought.
[Coke] pmichaud: is anyone still arguing for 6.00
?
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"
and, are we asking for a specific language, or for a specific compiler's interpretation? 21:24
moritz pmichaud: I hope the former
[Coke] we already have a way to specify "run this code in another language" and it's not 'use'.
japhb pmichaud: Going back to your reference to C specs, compilers regularly let you specify c90 or c99 as your target.
moritz pmichaud: otherwise, all dreams of multiple, compatible compilers are lost again
FROGGS[mobile] in an ideal world the former
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.
japhb ISTR some shenanigans on that front with optimistic compiler authors when the spec wasn't finished, but otherwise, I should think not.
pmichaud japhb: if it's not an issue for c99/c90, then perhaps it won't be an issue for p6.
japhb pmichaud: But those specify the version in the compile command, not in the code, yes?
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>;"
(note: 2 year versions in anything are not boss. don't do that.)
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.
[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
pmichaud [Coke]: well, we need to plan for it.
[Coke]: more importantly, we need to make these decisions so that others aren't saying "Perl 6 is the 2015.09 release of Rakudo."
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".
[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.
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.
[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.
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?
japhb I think part(!) of the previous communication problem is not enough concreteness to the discussions. Hence being possibly over-concrete today.
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.
[Coke] *I* have trouble explaining it to people, because it was messy, and we encouraged the mess.
21:31 _mg_ left
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.
pmichaud [Coke]: I'm writing an article explaining the parrot position
the problem is that Parrot definitely increases the workload needed for GLR, NSA, and NFG
[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
why would I want some compiler version instead of some spec version? to much with the internals?
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?
[Coke] pmichaud: ok. I look forward to the article, thanks.
b2gills: 2 variations of triplet. 6.x based, and 1.x based. 21:34
b2gills: for the compiler, or the spec?
b2gills both
[Coke] (year based) (what's the sub component?)
21:34 Kristien left
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.
pmichaud: Both, if you're doing it right. 21:35
vendethiel pmichaud: language's version number. Does it support c++11?
pmichaud vendethiel: you don't care about which versions of the compiler have XYZ bug and security fixes?
[Coke] I would agree that's the more important number.
pmichaud besides, I don't expect people to be downloading just a compiler, ever.
[Coke] ;(and the later the compiler version, the better, probably, for those reasons)
vendethiel if I have to specify a compiler version then my tools are broken, I believe
[Coke] pmichaud: oh, I would. 21:36
vendethiel it's making my code nonportable
PerlJam vendethiel: do you use Perl 5?
vendethiel no, I don't
[Coke] In terms of bundles. I'd always use the compiler and grab the modules I need rather than use something like R*
pmichaud [Coke]: would you use the version of perl 6 installed with your operating system?
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
japhb [Coke]: gist.github.com/japhb/ddb3d1a669509a69eaba
Gah, stupid failed word wrap
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
[Coke] pmichaud: do you mean the "system perl6" ? like /usr/bin/perl6 ?
vendethiel and in the process, bind my code to some specific compiler
[Coke]: yes
pmichaud [Coke]: something like that.
PerlJam Do other dynamic languages have some equivalent of Perl's "use v5.20" declarations? 21:38
[Coke] that's about a decade out.
vendethiel having #?if rakudo\n use rakudo v5.3;#?endif
would make me terribly, terribly sad.
pmichaud vendethiel: nobody is proposing that at all.
please don't go there.
vendethiel PerlJam: not that I know of
pmichaud: alright, then i'm misunderstanding something. How do I specify the version of the compiler if I want to support *all* the compilers?
[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.
[Coke] vendethiel: how on earth can you support all the compilers?
vendethiel [Coke]: how on earth can I not? why do I have a spec if I'm not about to support all the compilers?
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.
the compilers support the spec, not the other way around.
pmichaud compiler implement a spec
I don't think "support" is the right word.
vendethiel [Coke]: when you release c or c++ code, you can be mostly sure it'll compile under all compilers that implement that spec
(barring language extensions)
[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
21:41 Diederich left
vendethiel but what if someone is on another compiler and wants to use my code? which part would be different? 21:41
pmichaud vendethiel: nothing would be different, as long as "another compiler" supports the same level of spec as the original one
vendethiel (that seems to be a huge problem in CL, btw. compiler-specific code in a lot of places...)
[Coke] vendethiel: You have no control over other implementations. As an app author, what are you looking for? perhaps automated testing like colomon does?
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?
pmichaud and as long as the code you wrote limits itself to the level of spec that it claims to need
[Coke] the compiler is compliant with the spec. your code may not be.
and you can figure out if either your code isn't or the compiler isn't with some kind of automated testing.
PerlJam vendethiel: that works as long as the compiler version and spec version are in sync I think.
pmichaud PerlJam: NO. 21:43
vendethiel why?
[Coke] use v is historically implementation version, not spec version.
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
it'll just work on the other compiler.
[Coke] I think we need a separte mechanism to declare what version of the -spec- you claim to be using.
PerlJam Coke: agree.
pmichaud vendethiel: that's what we expect with Perl 6, fwiw.
vendethiel *because both compilers "support" the same specs*
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
per the standard
vendethiel geekosaur: that's also true. but most of the gcc extensions like that are deprecated
japhb geekosaur: Most of it? ;-)
vendethiel I don't think we need those extensions in Perl6. .oO( but signature-placed return variable declaration looks so cool!)
japhb Deprecations in a C compiler are a strange beast. 21:45
21:45 Diederich joined
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.
japhb bets you can still compile pre-ANSI C declarations on many compilers
vendethiel japhb: -Wall -Werror might make your program break with time.
[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.
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.
japhb [Coke]: Which is why the test suite is the real spec. You either pass the tests, or you don't.
It's not like you misinterpret the prose in a big document.
[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.
[Coke] (get the test added as a clarification to the spec.)
japhb [Coke]: Right.
pmichaud s/clarification/update
japhb Yes
[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:48
pmichaud I think the "use at least Rakudo version" is a simple module. 21:49
i.e., if code says use Rakudo v2015.01; that ought to be fairly obvious. :)
FROGGS[mobile] that would limit your program to one compiler 21:50
vendethiel but then, it will only work on rakudo :(
pmichaud it will limit your program to compilers that provide a "Rakudo" module.
a compiler or environment can certainly lie about it.
[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)
FROGGS[mobile] ohh, pragma 'if' to the rescue :o)
pmichaud it's not a pragma!
[Coke] Only working on Rakudo is -just fine- for 2015, unless we have some major suprise. 21:51
pmichaud IT'S NOT A PRAGMA! It's a MODULE!
FROGGS[mobile] :p
pmichaud Rakudo.pm6
japhb
.oO( It's not a TUMOR! )
FROGGS[mobile] hehe
vendethiel pmichaud: ugh, that just seems like pain, pain, and more pain. Remember what browsers did to lie about their name?
[Coke] feature based requirements are better, sure.
vendethiel their user agent contained ... lies such as "khtml, like gecko". but then, you're considering you can believe it when it's lying!
pmichaud we also have the entire set of %*VM stuff, or whatever it's called these days
PerlJam Some people will probably also want "use Rakudo v2015.01 :backend<jvm>";
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.
vendethiel pmichaud: or that you should be able to specify *several* compliant compilers.
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.
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
pmichaud and that it's doable using simple modules.
vendethiel * in the execution that'll break everything.
pmichaud emulation is a valid mode of operation, and yes, emulators are often imperfect. but we don't outlaw them. 21:54
vendethiel but then, how do you rule out emulators that are known buggy ? ;-) 21:55
you actually didn't make a step forward
pmichaud This is being very non-productive for me.
FROGGS[mobile] on an unrelated note, I wanna have 'use Foo if $*PERL.compiler eq 'rakudo''
[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:55 colomon left
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
[Coke] Let's just take a day or seven to digest vendethiel's concerns. Maybe one of us will think of something clever.
FROGGS[mobile] would be useful for NativeCall vs. pure perl implementations
[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
pmichaud [Coke]: perhaps. I did mention that features have lifetimes in my presentation. :)
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.
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
pmichaud In looking at the rakudo codebase, especially w.r.t. GLR, there's a lot of #?if parrot and #?if !parrot
japhb [Coke]: 'use spec < Perl6:2015a NFG:2015d >'?
pmichaud but there's very little #?if jvm
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. :)
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 Ugator left
pmichaud PerlJam +1 22:01
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.
I should just depart now, I think. 22:04
22:04 FROGGS_ joined
[Coke] jnthn: I'm sure I can work on NFG on JVM if needed. 22:05
22:05 skids left 22:06 FROGGS_ left
[Coke] what perljam said. 22:06
22:07 Sqirrel left, Sqirrel joined, FROGGS left
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:08
pmichaud PerlJam: what did you think it meant before, ooc? 22:09
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. :)
PerlJam honestly, I guess I never gave it much thought because it was "just like Perl 5" 22:11
22:11 FROGGS[mobile] left 22:13 eternaleye_ joined, eternaleye_ is now known as eternaleye
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:18
b2gills PerlJam: When I have "use v6;" it means "fail with a decent error on Perl 5" 22:19
PerlJam b2gills: so far, I've never accidentally run a P6 program with a P5 compiler :) 22:21
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:22
22:23 denis_boyun joined
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:)
will that ever exist now?
jercos I find it most useful as a guard for modules in mixed projects, or one-liners with -M
Since .pm is a sane extension for a perl 6 module, yes? 22:24
22:24 colomon joined
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:26
jdv79 sounds like a nightmare. worked out great for p5;) 22:30
i don't like the features pragma stuff
jercos To me that kinda feels like duplication 22:33
Very Java though.
22:33 denis_boyun left
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:36
22:36 gfldex left
TimToady has made it to Seattle 22:37
colomon \o/
TimToady I worry that having similar date-based version schemes between language spec and implementations could confuse peopel completely 22:39
people too
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.
TimToady because there could be bugs in the test suite
colomon almost certainly are
TimToady of the sort you just fix because probably nobody's depending on being bug compatible 22:41
japhb colomon: Yes, quite
22:41 adu left
japhb imagines an angry monster-movie mob shouting "Compatible with ALL the bugs!" 22:41
TimToady but I haven't backlogged yet since the wee hours of Brussels time 22:42
one could possibly even imagine a security fix to the test suite 22:43
but I'l think about this s'more when I'm not jet-slagged
*ll 22:48
[Coke] sleep well, and dream of large version numbers.
Oh, I know what annoying-to-do project I can work on next that will help the release, maybe. Blah. 22:50
Down to 713 tickets in RT, btw. 22:51
I recommend we start tagging tickets that are required to ship this year.
(though, since we don't have a PM, per se, that's hard to judge) 22:52
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:58 colomon left
pmichaud [Coke]: I'm having trouble with the "resolved before we ship" phrasing there. 22:59
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:00
masak closes his eyes and a flash of SHA-1 version numbers scares his eyes open again 23:06
japhb imagines a matrix-style screen saver in which all the falling characters are real commit IDs 23:08
jnthn saw quite enough SHA-1s today... :) 23:09
23:09 mohij left
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:25 _dolmen_ left 23:28 colomon joined 23:29 virtualsue left
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:32
I wonder if there are more for-loop-eliminating methods out there that we haven't discovered. 23:33
'night, #perl6
Mouq sleep tight, masak :)
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␤»
Mouq m: class Foo { class Bar is Foo { }; method from_foo($self:) {"Works. Got "~$self.^name} }; say Foo::Bar.from_foo; # Not ok
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
Mouq (Related, I think, to RT #115278 / #122221 ) 23:34
synopsebot Link: rt.perl.org/rt3//Public/Bug/Displa...?id=115278
23:42 adu joined 23:45 lizmat joined 23:47 adu left
tony-o is there something equivalent to lstat on an IO handle yet? 23:52
or stat
23:54 nige left, BenGoldberg joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!