dalek p: cea29a3 | (Zoffix Znet)++ | docs/ops.markdown:
Fix broken example
 00:02
ast: 13a41ba | usev6++ | S03-metaops/reduce.t:
Unfudge passing tests on JVM (RT #126899)
 06:19
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126899
FROGGS o/ 06:59
bartolin \o 07:19
[Tux] This is Rakudo version 2016.09-148-g6977b87 built on MoarVM version 2016.09-34-g082c989 07:55
csv-ip5xs 3.207
test 16.439
test-t 7.390
csv-parser 19.802
dalek p: 1a37f62 | FROGGS++ | tools/build/MOAR_REVISION:
bump moar for num->bigint fix
 11:02
kudo/nom: 228cbc3 | FROGGS++ | tools/build/NQP_REVISION:
bump nqp/moar for num->bigint fix
 11:03
lizmat Files=1146, Tests=53276, 220 wallclock secs (13.30 usr 3.87 sys + 1339.82 cusr 126.48 csys = 1483.47 CPU) 11:28
psch hm, NQP_VERBOSE_EXCEPTION makes this leaking unwind another bit less comprehensible :l 11:39
yoleaux2 8 Oct 2016 23:49Z <Zoffix> psch: we do have the .tell bot. It just got stuck behind the netsplit
psch apparently the EX_CAT_RETURN leaks from the &last call itself
which is weird, i think? because, should we even return from there when we throw a CX::Last in the first place..?
r: say +(gather do for ^4 { .take; last if $++; CONTROL { default { .perl.say; $_ } } }).cache; 11:49
camelia rakudo-moar 228cbc, rakudo-jvm 2a1605: OUTPUT«CX::Take.new␤CX::Take.new␤CX::Take.new␤CX::Take.new␤0␤»
psch everything is weird /o\
r: say +(gather do for ^4 { .take; last if $++; CONTROL { default { .perl.say; .rethrow } } }).cache;
camelia rakudo-jvm 2a1605: OUTPUT«CX::Take.new␤Error in socket connection:org.perl6.nqp.runtime.UnwindException␤ at org.perl6.nqp.runtime.ThreadContext.<init>(ThreadContext.java:125)␤ at org.perl6.nqp.runtime.GlobalContext.getCurrentThreadContext(GlobalContext.java:340)␤ at org.perl…»
..rakudo-moar 228cbc: OUTPUT«CX::Take.new␤Trying to unwind over wrong handler␤»
psch r: say +(gather do for ^4 { .take; last if $++; CONTROL { when CX::Last { .perl.say; .rethrow } } }).cache; 11:54
camelia rakudo-moar 228cbc: OUTPUT«Trying to unwind over wrong handler␤»
..rakudo-jvm 2a1605: OUTPUT«Error in socket connection:org.perl6.nqp.runtime.UnwindException␤ at org.perl6.nqp.runtime.ThreadContext.<init>(ThreadContext.java:125)␤ at org.perl6.nqp.runtime.GlobalContext.getCurrentThreadContext(GlobalContext.java:340)␤ at org.perl6.nqp.runtime.G…»
psch i mean, is that such a weird thing to do..?
dogbert17 o/ anyone there who can answer a valgrind question or have everyone grown tired of them? 12:38
there seems to be files with the extension '.S', what kind of files are those? 12:39
moritz dogbert17: assembler code 12:42
(before running them through the preprocessor) 12:43
dogbert17 moritz: thanks 12:45
the thing is that sometimes when valgrinding spectests I get the error 'Syscall param write(buf) points to uninitialised byte(s)' and then it looks like valgrind restarts 12:56
if I rerun the test where this happened the error is gone, just wondering if it's something which should be reported? 12:57
if anyone feel like giving it a once over a gist can be found here: gist.github.com/dogbert17/3f9cfcee...9ff49134ae 13:00
Zoffix \o :) 15:27
cowens Okay, I don't want to be an asshole about this, so you can tell me to shut up about it and I will. But I read the discussion about my issues with the Str type being stored as NFC and I wanted a chance to clarify some points.
Zoffix Sure, go ahead. Don't worry about being an asshole.
timotimo yup, go ahead, it's fine 15:28
though i'm AFK as of right now
cowens I say unicode.org/faq/normalization.html#1 being used as justification for throwing away user's data. That FAQ covers comparison not storage.
psch NFG is not NFC, for the record 15:29
cowens I completely agree that "e\x[0301]" and "e\xe9" should compare as the same
nine cowens: I don't know if you've red the channel log. So, in short the sentiment seems to be: yes, there are use cases dealing with broken systems where the normalization hurts and those cases need better support. The default an prirority however should be to support people who want to deal with texts. 15:30
cowens: when you talk about "throwing away data", you mean the exact representation of characters at a byte level. Whether this representation actually represents data could be disputed. For many people and many cases it won't matter. The actual data is the text, whether it's represented as bytes in UTF-8 encoded Unicode on a hard drive, or spoken, or written down by hand. 15:32
FROGGS cowens: read this and the following few lines: irclog.perlgeek.de/perl6-dev/2016-...i_13363590
cowens: TL;DR: it might not be "coming soon", but it will come some day 15:33
nine cowens: in other cases, it will of course matter if the exact same representation is still available. The question is, how common this really is.
psch uhm, this feels a bit like "ganging up" to me? i was under the impression cowens was refering to exactly that linked discussion
and, just maybe, we should wait for the clarification? 15:34
FROGGS waits :o)
cowens Sorry, I lost connection somehow 15:35
Yes I read those logs
The Unicode document being used to justify forcing NFC does not recommend storing the data as NFC 15:37
it recommends comparing the data as the NFC
it has a FAQ that even covers whether or not you should normalize unnormalized data automatically 15:38
nine If I understood jnthn++ correctly, we store strings in NFG, because it makes accesses O(1) instead of O(n). Something that will matter to many users.
cowens and it says to make it behave like it is in NFC, but it does not say to normalize it
amortized O(1) indexing can be achieved without throwing away data 15:39
FROGGS by duplicating data?
cygx cowens: have you seen www.reddit.com/r/perl/comments/557...ks/d8jlxji ? 15:40
nine cowens: did you get my remarks about "throwing away data" before you lost connection?
cygx in a perfect Unicode-aware world, the Perl6 behaviour is ok
the problem is that the p6 story is still lacking in the non-perfect world we live in 15:41
cowens There will never be a perfect Unicode-aware workd
world
And even in such a world, the string "e\x[301]" is a valid string. 15:42
but it isn't in Perl 6
FROGGS m: say "e\x[301]" 15:43
camelia rakudo-moar 228cbc: OUTPUT«é␤»
cygx cowens: semantically, p6 thinks of strings not as codepoint sequences, but equivalence classes of such
that's perfectly ok in my book as long as we still have a good story for the real-world problems 15:44
cygx is going to gist something
FROGGS well, usually you are not interested in codepoints either
psch a Str consists of graphemes, an Uni consists of codepoints
FROGGS *I* think the exact bytes of source and NFG strings are interesting
cowens Let me approach this form a different angle.
psch so, yes, Uni is what wouldn't ever throw away data, and it's underimplemented
but a Str is about what can be read on the screen 15:45
that's how i understand jnthn++'s explanation yesterday
cowens Is there a reason to discard the user's data for strings? Shouldn't the only goal be treating comparisons as equal?
cygx psch: from what I can gather, jnthn prefers generating synthetic codepoints over Uni
psch cygx: but that's what Str does, isn't it?
nine cowens: I already wrote that reason?
cowens: I start to think, you're not getting my messages, as you don't react to them in any way :/ 15:46
cowens which was what? O(1) indexing? You don't need to throw away data for that
nine Does anyone else read me?
FROGGS nine: I do :o)
nine cowens: and how not?
cowens simplest implementation would be an array and a sparse array
cygx psch: generating synthetics for non-canonical codepoint sequences which can then be round-tripped
cowens one code point graphemes go in the array 15:47
psch cygx: i have no idea what you are trying to tell me, sorry :)
FROGGS cowens: problem is when you split texts or do other stuff, you'd have to operate on two "strings", rather than one
cowens multi code point graphemes are stored in the array as a sentinel value
then stored in the sparse array at that point. 15:48
Split should work on the grapheme level in Str
FROGGS the implementation of Str is meant to be fast, and you cant be fast when you have two copies of the string data to work with
cowens You have to have a lookup table now don't you? 15:49
FROGGS to split something? no
psch m: say Uni.new(0x65, 0x301) [&($_)] Uni.new(0xe9) for &[==], &[eq]
camelia rakudo-moar 228cbc: OUTPUT«False␤True␤»
cowens You don't in that array + sparse array either 15:50
I mean to print the data back out
FROGGS to print a Str we turn it back to NFC or something, yes 15:51
but still, all string operations deal with a single stream of one element things
nine cowens: split right now can work on an array of 32 bit ints where each element is a grapheme. Same as all other string operations. I don't see how you could achieve the same performance when using two data structures? Wouldn't that at least give you worst cache locality, not to speak of the additional operations necessary?
cowens Hey, I was talking about O(1) which is what I saw people talking about. 15:52
Yeah, it won't be as performant, but it would be better than Uni and it wouldn't throw away data 15:53
Given that the choice was to go with Rat over floating point as the default, I assumed Perl 6 was supposed to favor integrity over speed. 15:54
nine cowens: but now we're talking about trade offs. You want to make all string operations in Perl 6 slower for covering some use cases. That's totally ok, but you got to admit, that as with all judgement calls, opinions may differ :)
psch i don't think Rat is about integrity over speed 15:55
Rat is about doing the obviously right thing
because, well, 0.1 + 0.2 *is* equal to 0.3
and in the same vein, é is equal to, well, the other one that also looks like é
nine Which for texts means keeping the integrity of texts, not necessarily the integrity of byte code level representations of texts.
psch (i'm not sure which of those two i'm typing with my locale, hence my phrasing :) ) 15:56
cowens Well, my file contains "re\x[301]sum\x[301]" the obvious thing to happen when I append "Chas's" with Perl is that it should be "Chas's re\x301]sume\x[301]"
FROGGS cowens: why do you need the original bytes ooc? 15:57
cowens Many reasons: legacy systems, audit controls, etc.
cygx rfc: gist.github.com/cygx/b545c206a0f7c...4b26afccf6
cowens If I round trip a file in Perl 6 strings, it might not get the same md5sum even if nothing changed 15:58
FROGGS cowens: well, if you just want to write it from a to b without modification and you know that checksums are involved than perhaps use Buf 15:59
I mean, for now at least
cowens It might not have no modification
FROGGS what I usually do with text is interaction with humans
psch Buf will not normalize
FROGGS and they dont care about byte orderings 16:00
cowens say you have a process that needs to change names in a file
but if the names aren't present, no changes should be made
FROGGS cowens: Buf is meant to be string like
having subbuf instead of substr etc
cowens the typical way of doing that is a filter
FROGGS but I guess not being able to regex match can be a showstopper 16:01
cowens Perl 6 changes things even when the user didn't ask for them to be changed if he or she uses a string
psch except Perl 6 doesn't write that if you don't tell it to?
FROGGS yes, and in >95% of the cases the user wont care
cowens Also, Buf is bytes. I want to work at the grapheme level
psch i mean, are you memmapping the file..?
FROGGS but (s)he will be more happy with faster string ops
cowens But I don't want working at the grapheme level to force me into normalized data 16:02
that goes back to the Rat vs floating point argument
I don't mind there being an optional lossy string type
that is faster
psch that's not the Rat vs floating point argument 16:03
cowens But the default being lossy is very surprising
psch that's the reason why the Rat vs floating point argument was made
we pick Rat because it does the right thing with the representation
cowens NFC isn't the right thing for strings
It is an optional thing for strings 16:04
psch if you cannot visually distinguish them, they are identical
that is what text means
i understand that you disagree with assertion
but it's the one the core devs arrived at, and why Str defaults to NFG
*with this assertion
cygx what psch said: any system that does treat canonically equivalent text as different is arguably broken
timotimo psch: so I and l are the same thing? :P
cygx as there are a lot of broken system, you need a good fallback story 16:05
psch timotimo: they look different here :)
cygx Perl6 curretnly lacks such a story
psch cowens: now, the concern that absolute byte level integrity is hard currently is absolutely valid
timotimo i can visually distinguish the one ê from the other ê by looking at the bytes in the file with a hex editor :P :P
FROGGS cowens: there will be a solution... but it most likely wont be the default
cowens Yeah, I can tell that there is some cool aid I haven't drunk 16:06
cygx FROGGS: it's entirely possible to echive something like open(:compat) and
psch oh come on
cygx *achieve
FROGGS yes, or have a pragma or something else
cygx ...and have it do the mostlyright thing
psch "your arguments are bad because i don't like the tradeoff" isn't reasonable
FROGGS or a mixed in role that keeps the original bytes or a string
cowens psch that cuts both ways 16:07
FROGGS there are several ways of doing it, and I'm not the one proposing a good solution here :o)
cowens Performance is being given more importance than correctness for strings, but not for numbers
That is the trade off. And it is very odd to outsiders 16:08
Zoffix But the string are "correct". The trade off is in their representation.
cygx cowens: but normalization is the correct approach in a perfect Unicode-aware world
FROGGS cowens: do operations on stuff that cannot be normalized to a single codepoint in all the languages you know
cygx (or rather treating equivalent things as equivalent)
cowens No, the graphemes are correct, but the underlying data is lost
FROGGS cowens: and than count these that dont split in the middle of a grapheme
Zoffix The underlying data is bytes, so the string operations are correct :) 16:09
psch but the graphemes *are* the relevant data in a Str
if you care about bytes, use Buf
or maybe Uni, eventually
Zoffix And once we have user-land encoders, I imagine this type of stuff would be even more convenient, no?
psch or maybe some up-and-coming prgama
*pragma
FROGGS strings in general are not about bytes... they are about visible characters, whatever that means
psch is getting too heated 16:10
sorry, clinking myself out here :S
FROGGS yeah, a break sounds sane :o)
dinner &
cygx FROGGS: user-perceived characters as approximated by equivalent grapheme clusters, if you want to get technical
;) 16:11
cowens On a more positive note: should all of the string functions be in stringy?
Zoffix Don't think so, considering:
m: say Buf ~~ Stringy
camelia rakudo-moar 228cbc: OUTPUT«True␤»
cowens Should string functions for Uni be on the grapheme level, code point level, or take an adverb with a default
Zoffix And, I mean, .match is a string function, etc 16:12
I'd imagine on grapheme level, though I'm not familiar with Uni.
timotimo there's still the possibility of giving every grapheme that would be changed by normalization a synthetic that writes back what it once was. problem solved forever.
cygx generic functions should operate on codepoints, string-specific ones might want to aoerce
timotimo that will, however, make things like string comparison a bit more complicated 16:13
cowens Yeah, that was one of my O(1) solutions
cygx *coerce
cowens But it has complexity attack issues and isn't as performant
timotimo i don't really remember what the particular arguments against that were that were brought forth
cowens What does NFG do when it runs out of synthetics? 16:14
cygx die because you've exhausted your RAM ;)
timotimo at the moment we don't have a mechanism for that, but we can GC through existing strings and throw out unused synthetics
but yeah, you'll need a lot of input data to get to that point, and later you'll need all of that data to stick around in memory so GC won't free it up 16:15
cowens So, the table is interpreter level, not string level?
timotimo that's right
we have a lock-free datastructure that does that stuff
i haven't looked closely at that yet
cowens I had assumed string level because of a comment in the docs, but I guess you just reserve the right to have it at string level
timotimo btw, we currently have an entirely real attack based on NFG, compared to the pretty difficult-to-pull-off attack of exhausting the table space 16:18
m: say "a" ~ "\c[COMBINING ACUTE]" xx 100000000
camelia rakudo-moar 228cbc: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Unrecognized character name COMBINING ACUTE␤at <tmp>:1␤------> say "a" ~ "\c[COMBINING ACUTE⏏]" xx 100000000␤»
timotimo .u combining
yoleaux2 U+0300 COMBINING GRAVE ACCENT [Mn] (◌̀)
U+0301 COMBINING ACUTE ACCENT [Mn] (◌́)
U+0302 COMBINING CIRCUMFLEX ACCENT [Mn] (◌̂)
timotimo m: say "a" ~ "\c[COMBINING GRAVE ACCENT]" xx 100000000
camelia rakudo-moar 228cbc: OUTPUT«Memory allocation failed; could not allocate 800000000 bytes␤»
timotimo oh, hehe
m: say "a" ~ "\c[COMBINING GRAVE ACCENT]" xx 10000
camelia rakudo-moar 228cbc: OUTPUT«à ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀…»
timotimo no, actually, that won't do it
m: say "a\c[COMBINING GRAVE ACCENT]" ~ "\c[COMBINING GRAVE ACCENT]" xx 10000 16:19
camelia rakudo-moar 228cbc: OUTPUT«à̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀ ̀…»
timotimo how do i ...
probably have to go via Uni?
anyway. trying to add that kind of thing to our trie datastructure exhausts the C stack
FROGGS thinks that synthetics have to be kept at interpreter level because otherwise you could not compare strings 16:22
timotimo you can, you just have to compare synthetics that you come across
if we have different synthetics for the same character but different normalizations, we'd have to do some extra work anyway 16:23
cowens_ So, if I were to start implementing string functions for Uni, where should I put them? Should we have parallel functions in the different classes (Buf/Uni/Str)?
FROGGS how so? their made up negative number certainly wont be the same
timotimo i meant compare the underlying data for the synthetics when their indices don't match
and even if the indices match, if the table is per-string, same index doesn't mean same character
FROGGS well, that'd be slower again :o)
aye 16:24
timotimo honestly, i'd be okay with a flag on strings that says "uses normalization-conserving synthetics"
and only compare underlying synthetic data if that flag is set on one or both of the strings 16:25
and we'd probably also want some kind of support for strings with different normalizations in code as literals
cowens_ I think S15 covers that
qq:nfd"e\x[301]" 16:26
timotimo ah
i was thinking of a way to write "this string has mixed normalizations in it"
cowens_ That is called Uni 16:27
Based on what people have been saying
timotimo not easy to type, though :)
cowens_ Oh, yeah, I hate that syntax
timotimo well, you can type it Uni.new(<1 2 3 4>), can't you?
cygx "foo{ Uni.new(...).non-normalized-synthetic-Str }bar"
cowens_ Yeah, that is even worse 16:28
timotimo if you just call it .nnsS ... :P
cowens_ Or .SaneStr (half kidding) 16:29
timotimo should we consider people would expect code like 'say "asdf"' piped through xxd to have the same bytes as the part between the " in the code?
cowens_ Seriously, If I start implementing string functions for Uni, where should I put them: in Uni or stringy?
p3rln00b m: 7 ~ "\x[308]" x 150_000
camelia rakudo-moar 228cbc: OUTPUT«(signal SEGV)»
timotimo for now, i'd just put them into Uni 16:30
they can probably be moved up later, right?
p3rln00b: thank you
cowens_ Should they share names with Str or have some sort of prefix? 16:31
there was talk of subbuf instead of substr 16:32
timotimo subuni? :P
cowens_ Yeah, that one is easy
timotimo does the AFK-dance again
cygx o/ 16:35
cowens_ A parting thought: It feels to me like Str is changing "consumed" to "ate" and people are saying I shouldn't be upset because they mean the same thing. 16:42
p3rln00b hah. Debuggin something and dumping things and apparently we have something with 73 multi candidates for it :} 17:28
(unless I'm misinterpreting my data) 17:29
m: &postcircumfix:<[ ]>.candidates.elems.say 17:32
camelia rakudo-moar 228cbc: OUTPUT«65␤»
geekosaur is noodling something re strings... 17:44
I kinda want to reflavor things. Str -> UI string, Uni -> unified string (may not be unicode any more), Buf8 -> octet string. files and streams are Buf8 when raw or Uni when not. Uni lets you define ranges (including "from X until further notice") with encodings (and, in a more general implementation, encoding can include compression and/or encryption) 17:46
also reinterpretations, as needed for IRC where the command framing is an ISO8859 but the payload may be a different ISO8859 or UTF8, or when an HTTP stream sends a Content-Type and/or Content-Encoding 17:47
people kinda want to believe "string is string" but that has not been true since people finally realized the world is not US ASCII carrying US English 17:48
nine English has never been ASCII only
geekosaur ...but the computer representation was 17:49
basically the thing I'm thinking about is that perl 5 had IO layers on filehandles; that's the wrong place since stream interpretations need to change as they go. I want layers on *streams*, where a stream is a generalized notion of "string" 17:50
Zoffix m: sub foo (int $x) { $x.say }; my Int $b = 2; foo $b; 17:54
camelia rakudo-moar 228cbc: OUTPUT«2␤»
Zoffix Would you say that's a bug?
lucasb that's expected unboxing, no? 17:56
otherwise 'my int $x = $an-Int' would also have to be a bug 17:57
Zoffix Fair enough. What about this one:
m: sub foo (Int $x) { $x.say }; my int $b = 2; foo $b;
camelia rakudo-moar 228cbc: OUTPUT«2␤»
Zoffix Would you say that is a bug?
lucasb and that is expected boxing 17:58
geekosaur auto(un)boxing should probably be a thing unless you want to go the strict typing route a la Haskell
Zoffix Fair enough. Now, with the above in mind, which multi should this call; the native or or the Int?: multi foo (Int $x) { $x.say }; multi foo (int $x) { $x.say }; foo 2; 17:59
Or to mix it up: multi foo (Int $x, Int $y) {}; multi foo (int $x, int $y) {}; my int $b = 2; foo 2, $b; 18:01
geekosaur if a multi matches the boxing state, use it, otherwise if a multi matches the type but different box/unbox, use it, otherwise if you have a coercion you can use, box and coerce. 18:02
there might be a pragma for strict boxing if someone wants to write haskell in perl6
java's had autoboxing for some time now, it's not an unexplored concept 18:03
Zoffix Is literal 2 a "boxed state"? 18:05
geekosaur maybe a restatement of that which-to-call: if you have an unboxed value, first try to match the unboxed type exactly. if no multi matches, box it and do normal multi resolution
the one hard rule is that the only "coercion" available for an unboxed value is to box it
that question makes me think I need to restate that again 18:06
because that question does not make sense...
Zoffix Well, is literal 2 "boxed"? 18:07
geekosaur I am inclined to consider it boxed, and unbox it if needed
mostly because in perl6 literal 2 can coerce to various types, and coercion is only possible for boxed values
Zoffix OK 18:08
geekosaur (yes, technically you can pretend otherwise but you're really just manipulating a separate box to do so)
lucasb I think this question, wether a literal integer is native or not is a very relevant question that should be answered in the FAQ 18:09
I think a reasonable approach would be for it to be a native, if it fits the native range of values, otherwise it would be Int 18:10
Zoffix I think that's already how it is in the optimizer.
lucasb but this thinking doesn't work for strings, right? is a literal string a 'str' or Str?
geekosaur: haskell has something like polymorphic constant, right? do you think this concept describes what we are talking about? 18:12
I read about it in that book learn haskell for great good
geekosaur yes and no. haskell also has strict typing and full type inference, so you can give a meaning to a polymorphic constant more easily 18:13
"polymorphic constant" has to do something else in a perl6-like type world
lucasb 5 :: Int
5 :: Integer
5 :: Float
this enforces the type in the constant, no? 18:14
(in Haskell)
geekosaur when you write "5" in Haskell, the compiler sees (as specified by the language definition): fromInteger (5 :: Integer) 18:15
if you write "5 :: Int" this becomes "fromInteger (5 :: Integer) :: Int" so the instance (fromInteger :: Integer -> Int) is selected 18:16
lucasb hmm, interesting. thanks for clarifying
geekosaur one complication in the boxing/unboxing discussion is that in haskell an unboxed value is never polymorphic, because if you do not know the type statically you can't know what the value actually is --- or even how large it is. 18:19
perl 6 "unboxed" values are actually boxed, in that sense 18:20
but in an OO language "unboxed" means "not an object", not "does not have a type witness" 18:22
so perl6 can actually do some polymorphism there... the problem being that coercions are object methods, so you still really want an object to do a coercion 18:23
nine [</win 13 18:40
2016.10 release is next weekend, isn't it?
Zoffix Right 18:41
NeuralAnomaly, status
NeuralAnomaly Zoffix, [✘] Next release will be in 5 days and 9 hours. Since last release, there are 41 new still-open tickets (38 unreviewed and 0 blockers) and 149 unreviewed commits. See perl6.fail/release/stats for details
nine Ok, then I won't bother sumbmitting 2016.09 for openSUSE. Rakudo fails the tests on i586 and this issue should be fixed in 2016.10 anyway 18:42
dalek p: af751d3 | FROGGS++ | tools/build/MOAR_REVISION:
bump moar for better error messages
 19:18
lizmat m: sub a(&b) { b(); b() }; a sub{ say "foo" } # I'm surprised this works
camelia rakudo-moar 228cbc: OUTPUT«foo␤foo␤»
lizmat I'd expect an error because of the lack of whitespace between "sub" and "{"
dalek kudo/nom: a92f092 | FROGGS++ | / (2 files):
improve nativecall error messages, fixes RT #129353
 19:19
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129353
lizmat m: sub c(\sub) { sub{"foo"} }; say c(my %h) # expected Any here 19:23
camelia rakudo-moar 228cbc: OUTPUT«sub () { #`(Sub|61604456) ... }␤»
lizmat m: sub c(\sup) { sup{"foo"} }; say c(my %h) # any other name than "sub" does 19:24
camelia rakudo-moar 228cbc: OUTPUT«(Any)␤»
lizmat is this a bug or a DIHWIDT ?
geekosaur I think unless a prototype is mandatory, it's not really possible to distinguish whether it's an anon sub or a hash? 19:26
or you want to require a brace between sub and { to indicate an anon sub
er, a sspace
lizmat yeah, I expected the space to be mandatory, like lack of it is mandatory with calling foo() 19:27
to distinguish itself from a hash lookup
Zoffix ISAGN for nqp version of dd :/ 20:51
Spent about 30 compilations already trying to dump a simple array, just to be greeted with one error or another after parse stage heh 20:54
dalek kudo/nom: f4a8a69 | lizmat++ | src/core/Str.pm:
Looks like we don't need 'try' here any more

First stab at making Str.match faster		 21:19
kudo/nom: 13f4798 | lizmat++ | src/core/CompUnit/RepositoryRegistry.pm:
Don't use regexp based split for pathspec

Use fast str based split, and just trim the whitespace fastly later, without needing to start up the whole regex engine.
Found this when I broke Str.split with my work on Str.match		 21:27
lizmat this should have a visible effect on "make spectest" I hope
good night, #perl6-dev 21:39
Zoffix__ night 21:41
Zoffix m: sub foo (int $x) { $x.say }; foo 2 21:48
camelia rakudo-moar 13f479: OUTPUT«2␤»
Zoffix m: multi sub foo (int $x) { $x.say }; foo 2
camelia rakudo-moar 13f479: OUTPUT«Cannot resolve caller foo(Int); none of these signatures match:␤ (int $x)␤ in block <unit> at <tmp> line 1␤␤»
Zoffix ^ adding to previous discussion. The latter is a bug then?
m: multi sub foo (int $x) { $x.say }; foo my int $ = 2 22:04
camelia rakudo-moar 13f479: OUTPUT«2␤»
Zoffix m: multi sub foo (Int $x) { $x.say }; foo my int $ = 2
camelia rakudo-moar 13f479: OUTPUT«2␤»
Zoffix m: multi foo (int $x) { $x.say }; my Int $x = 2; foo $x 22:05
camelia rakudo-moar 13f479: OUTPUT«Cannot resolve caller foo(Int); none of these signatures match:␤ (int $x)␤ in block <unit> at <tmp> line 1␤␤»
Zoffix Stresstest is floppy as hell... 5 runs so far, only the first one succeeded. Different failures on each of the following runs :/ 22:11
t/spec/S05-substitution/subst.rakudo.moar (Wstat: 256 Tests: 183 Failed: 1) 22:16
ZOFVM: Files=1194, Tests=129672, 137 wallclock secs (21.65 usr 3.14 sys + 2425.60 cusr 195.67 csys = 2646.06 CPU) 22:26

Powered by Cro and the Raku® Programming Language.

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

Thank you!