viki m: dd <1> 00:17
camelia rakudo-moar e0c0ae: OUTPUT«IntStr.new(1, "1")␤»
viki m: dd <1/2>
camelia rakudo-moar e0c0ae: OUTPUT«0.5␤»
viki m: dd < 1/2 >
camelia rakudo-moar e0c0ae: OUTPUT«RatStr.new(0.5, "1/2")␤»
viki m: dd <1e5> 00:18
camelia rakudo-moar e0c0ae: OUTPUT«NumStr.new(100000e0, "1e5")␤»
viki m: dd <1+42i>
camelia rakudo-moar e0c0ae: OUTPUT«<1+42i>␤»
viki m: dd < 1+42i >
camelia rakudo-moar e0c0ae: OUTPUT«ComplexStr.new(<1+42i>, "1+42i")␤»
viki m: dd <42.1> 00:20
camelia rakudo-moar e0c0ae: OUTPUT«RatStr.new(42.1, "42.1")␤»
viki Hm, apparently it were the same at some point, unless the author just made up half the examples here: docs.perl6.org/language/glossary#i...-Allomorph 00:21
geekosaur those examples used to work, so something changed 00:25
viki k, I'll take a look into it 00:26
geekosaur possibly deliberate to reduce the wat from their being allomorphic... but still leaves the allomorphic behavior in the bug report 00:27
cygx assuming that hasn't been done yet, who volunteers to write automatic testing of all example code from the documentation?
geekosaur which I would consider a doc bug
cygx well, <1> not returning Int might be an actual bug 00:28
viki cygx: there's already effort to do that 00:29
cygx: why Int? I'd say <1/2> not returning RatStr is a bug
hmm 00:30
cygx I remember that <...> without spaces got changed to be the literal form of compound numeric types, eg doesn't got through &infix:<+> for 1+3i 00:31
viki Actually no, that's likely on purpose. So you could indicate a literal and not a division of two ints. IIRC there's a grammar rule for that so you could also do it in sig
b2gills I remember the same thing that cygx remembers 00:47
cygx curious that it apparently only got changed for Complex and Rat, and for the latter only if / is used 00:49
that seems... strangely inconsistent ;)
viki I see the consistency actually and am about just to change the docs.
The consistency being that you get an allomorph in the construct for numerals. The exception is when it's an only thing in the angle brackets and has an operator: / for Rats and + for complex 00:50
cygx exceptional behaviour is not consistent - consistent would be returning plain numeric types instead of allomorphic ones for all single-word constructs that can be parsed as such 00:51
at least that's how I see it
(for 'spaceless' single-word constructs, that is) 00:53
viki Isn't that an exception too? :) 00:54
cygx :) 00:55
it's more of a sliding scale - if the exception is universal enough, it gets to be a rule instead 00:56
TimToady the reasoning is pragmatic; there's good reason to write <1/2> and <1+2i> as literals, and no good reason to write <42>, since you could just write 42 instead 01:21
unless you for some reason wanted to write angles around all your literals, but that'd be pretty silly... 01:22
cygx I'll have to sleep on that one and decide if it still offends my stylistic sensibilities when it's less dark outside 01:32
what would have been the alternative? parsing spaceless expressions like 1+2i or 1/2 as a single literal? 01:34
there's arguably some precedent with floating point literals like 2e-5
TimToady and ignore precedence?
but there the 'e' is not an operator
+ and / are normal operators with normal precedence
what do you do with 1/2 ** 3 and such? 01:35
arguably you can rely on constant folding with (1/2) ** 3, but that doesn't really help for other places you want literals, like in signatures 01:36
cygx m: sub postfix:<e>($v) { say $v }; 2e; 2e+5 # let's see what happens
camelia rakudo-moar e0c0ae: OUTPUT«WARNINGS for <tmp>:␤Useless use of constant floating-point number 200000 in sink context (line 1)␤2␤»
TimToady you probably want an infix instead :) 01:37
cygx m: sub infix:<e+>($a,$b) { say "evil!" }; 2e+5 01:38
camelia rakudo-moar e0c0ae: OUTPUT«WARNINGS for <tmp>:␤Useless use of constant floating-point number 200000 in sink context (line 1)␤»
cygx m: sub infix:<e+>($a,$b) { say "evil!" }; 2 e+ 5
camelia rakudo-moar e0c0ae: OUTPUT«evil!␤»
cygx Obviously, literals should just use +instead of + 01:40
that's what UNicode is for, right? 01:41
tailgate I'm interested in how POD gets processed and put into the $=pod variable. What projects/files should I look into for that? 01:42
viki tailgate: go to github.com/rakudo/rakudo press "t" and type Pod 01:43
tailgate: of notableness there's lib/Pod/To/Text.pm6, src/core/Pod.pm, and src/Perl6/Pod.nqp 01:44
actually along with src/Perl6/DebugPod.nqp those're the only relevant bits in "t" output 01:45
tailgate yeah, those were what I hd found so far with ack
except DebugPod
viki tailgate: you can also run perl6 --target=parse -e 'some code, like Pod' and that will output the tree of tokens it parses. Those will be in src/Perl6/Grammar.nqp usually
( post that involves using that output, even though it's not about Pod perl6.party/post/Perl-6-Core-Hackin...cal-Babble ) 01:46
cygx good night o/ 01:49
[TuxCM] This is Rakudo version 2016.11-70-ge0c0ae5 built on MoarVM version 2016.11-20-g0f7277a 10:38
csv-ip5xs 3.155
test 14.024
test-t 6.544
csv-parser 13.617
lizmat Files=1155, Tests=53795, 209 wallclock secs (12.81 usr 3.69 sys + 1273.93 cusr 122.53 csys = 1412.96 CPU) 10:41
and good *, #perl6-dev!
timotimo o/ 10:42
dalek kudo/nom: 8ca367d | lizmat++ | / (2 files):
We already have shape, so don't fetch it again
10:43
psch so, what's the sanest thing i can do to prevent instantiation of objects with a given HOW 10:56
timotimo look at Uninstantiable HOW? 10:57
i suppose just raise an exception when it's attempted?
maybe in one of its compose methods check some conditions and then throw
psch well, afaik we do the cannot-be-instantiated thing only at REPR level..? 10:58
timotimo oh!
psch at least that's what Nil does, which is why its .new returns self or something
timotimo you're right, that's actually a repr
psch er, not self, Nil
point is, i have a HOW that represents something role-like that can only be mixed in but not punned
timotimo it should have the same effect, though
except if you derive from Nil 10:59
psch and i kinda feel like stuffing a .new into the method cache probably breaks the mixin part
timotimo good Q
lizmat well, depends how paranoid you are 11:00
do you want nqp::create(thattype) to fail as well ?
psch yes
lizmat then it needs to be at REPR level, afaik
m: class A is repr("Uninstantiable") { }; use nqp; nqp::create(A) 11:01
camelia rakudo-moar 8ca367: OUTPUT«You cannot create an instance of this type (A)␤ in block <unit> at <tmp> line 1␤␤»
psch hmm, can i demand a specific repr for all objects with a given HOW?
or, well, predeclare or whathaveyou 11:02
probably, right, that sits in the STable doesn't it
timotimo thing is, we'd normally want to make the HOW distinct from the REPR so you could mix-and-match 11:03
lizmat psch: perhaps doing a "compose_repr(...)" on the .HOW ?
timotimo this is clearly a special case
lizmat I see a lot of that in the bootstrap 11:04
psch hmm 11:06
i suppose i'll leave that for later and try and get the mixin part working first, anyway
...if that's actually easier, at least :)
geez, i think it actually isn't 11:12
i mean, an Interface in Java cannot be instantiated 11:13
timotimo right
psch which, i think, we should mirror when we use that Interface via interop, right?
timotimo otherwise the jvm will just asplode at us for us
psch but, an Interface in Java can have static and/or default methods
timotimo so we don't have to explode it ourselves
psch and, well, to do the whole interop thing, we *already* create an adaptor, which inherits (because the jvm itself doesn't care about the difference between ' 11:14
'implements' and 'extends') the interface
hence:
$ ./perl6-j -e'use lib "java#$*CWD"; use Foo:from<Java>; say Foo.baz ~ " " ~ Foo.HOW.^name'
quux Perl6::Metamodel::JavaInterfaceHOW
but most of why Interfaces cannot be instantiated is actually really just that they don't have <init> 11:15
hence we don't automatically build .new
but the thing is, actually i wouldn't want that .baz call to work at all either 11:16
because the Interface doesn't make sense as an adaptor class, because calling one of the stubbed methods in it complains about "casting interface to class" or summat
soo i suppose i want to forbid *all* invocation on the Interface adaptor 11:17
but when mixing it into a class (or punnable role) i still want to be able to reach the existing static or default methods 11:18
dalek kudo/nom: 13d751e | lizmat++ | / (2 files):
Abstract copying logic into separate sub

We're going to need it later to handle the case of an intX shaped array being copied into an intY shaped array where X and Y differ.
11:22
psch honestly, the easiest thing to do there seems to be to just break callmethod for interface adaptors
which is kind of a really horrible solution, intuitively
oh, i can muck with the InvocationProtocol! 11:26
...i think. does that actually make sense for objects/methods? 11:29
jnthn psch: fwiw, the REPR is selected at the time nqp::newtype is called, which is usually in turn done in the new_type method of the meta-object 11:36
yoleaux2 26 Nov 2016 22:54Z <lizmat> jnthn: some HARNESS_TYPE=6 failures: gist.github.com/lizmat/0bd1a0668a7...c6dffac399
psch j: use java::lang::String:from<JavaRuntime>; say String.HOW.^can('new_type') 11:37
camelia rakudo-jvm 76b061: OUTPUT«0␤»
jnthn SubsetHOW is an example of a meta-object that always uses Uninstantiable: github.com/rakudo/rakudo/blob/nom/...OW.nqp#L28
psch j: say Metamodel::JavaHOW.^can('new_type') 11:38
camelia rakudo-jvm 76b061: OUTPUT«0␤»
jnthn has no idea how JavaHOW is set up... :)
psch i'm pretty sure it's horribly hacky :S
in part because we're not really declaring the types on a HOW level either
jnthn Possibly, though I'd surprised if it's so hack that there's not a call to the underlying nqp::newtype primitive
*hacky 11:39
psch jnthn: i think what new_type would do we do instead via nqp::jvminterop.typeForName 11:40
jnthn j: use java::lang::String:from<JavaRuntime>; say String.REPR 11:43
camelia rakudo-jvm 76b061: OUTPUT«P6opaque␤»
jnthn Curious :) 11:44
I'm guessing P6opaque must be mentioned somewhre in that codepath
timotimo j: use java::lang::String:from<JavaRuntime>; say String.WHAT.perl 11:45
camelia rakudo-jvm 76b061: OUTPUT«Method 'perl' not found for invocant of class 'java.lang.String'␤ in block <unit> at <tmp> line 1␤␤»
timotimo huh.
it's weird to have that as p6opaque
psch j: use java::lang::String:from<JavaRuntime>; say String.WHAT
camelia rakudo-jvm 76b061: OUTPUT«Cannot unbox a type object␤ in block <unit> at <tmp> line 1␤␤» 11:46
psch hm, i thought .gist works
j: use java::lang::String:from<JavaRuntime>; say String.WHAT.Str
camelia rakudo-jvm 76b061: OUTPUT«Cannot unbox a type object␤ in block <unit> at <tmp> line 1␤␤»
jnthn Think it comes all the way from github.com/perl6/nqp/blob/4fd4b48a...r.java#L48 11:48
psch yeah, i'd assume so
neither BootJavaInterop nor RakudoJavaInterop deal with the REPR directly
only access it
jnthn But oddly that seems to use the JavaWrap REPR
So color me confused :)
RabidGravy does anyone have a feeling whether gist.github.com/jonathanstowe/9db3...794be0b19b represents a genuine bug (or just a limitation) 12:46
save the two files and the "perl6 -I. -MBar -e1" 12:47
psch "Bar,om" heh
RabidGravy dodgy typing skillz
psch yeah, slipping to the left or right is terrible 12:48
especially when typing ' but accidentally hitting return :S
dalek kudo/nom: ec7de81 | lizmat++ | / (2 files):
Oops, on Moar we should use multidimref
kudo/nom: 054acab | lizmat++ | src/core/Rakudo/Internals.pm:
Give R:I:ShapeIndexIterator its own implementation

  - using the ShapeLeafIterator turned out to be a less than ideal fit
  - don't need to pass on a dummy arg anymore
  - don't need to P6Opaque the int indices at every iteration anymore
  - will allow ShapeLeafIterator to become smarter
RabidGravy right, supermarket calls
dalek ast: 276e0c0 | (Zoffix Znet)++ | S16-filehandles/io.t:
Remove trailing whitespace
15:11
viki huh, weird... I wrote a test and the file passes make t/spec/blah, but there's actually a fatal error that makes it crash 15:28
oh nevermind, I forgot to increase the plan :) 15:29
dalek kudo/nom: dd76c9d | (Zoffix Znet)++ | src/core/IO/Handle.pm:
Remove trailing whitespace
15:39
kudo/nom: 8774f24 | (Zoffix Znet)++ | src/core/IO/Handle.pm:
Add IO::Handle.printf
15:40
ast: 46f1f0d | (Zoffix Znet)++ | S16-filehandles/io.t:
Test IO::Handle.printf

Added in commit:
  github.com/rakudo/rakudo/commit/8774f245b2
TimToady m: sub foo ($n) { say $n; samewith $n - 1 if $n }; foo(10) 15:49
camelia rakudo-moar 8ca367: OUTPUT«10␤9␤8␤7␤6␤5␤4␤3␤2␤1␤0␤»
TimToady m: sub foo ($n) { say $n; samewith $n - 1 if $n; say "foo" }; foo(10) 15:50
camelia rakudo-moar 8ca367: OUTPUT«10␤9␤8␤7␤6␤5␤4␤3␤2␤1␤0␤foo␤foo␤foo␤foo␤foo␤foo␤foo␤foo␤foo␤foo␤foo␤»
TimToady I guess that doesn't TCO, though presumably it could be optimized if it were the last thing
dogbert17 seems a bit slow around here 17:22
japhb is just winding up to start his hacking 17:23
dogbert17 still trying to figure out why I get 'Invalid free() / delete / delete[] / realloc()' when running the simplest programs. Only shows up when building Moar with --valgrind. 17:25
japhb Trying to figure out what I want to deal with first: improved visuals, splitting out classes into libs, code review comments, tanking on future directions ... hmm
dogbert17: You're the one on a 32-bit Moar, yes?
dogbert17 indeed 17:27
built moar with: perl Configure.pl --no-optimize --debug --valgrind --prefix=/home/dogbert/repos/rakudo/install/ 17:28
here's a gist if you're interested 17:29
gist.github.com/dogbert17/78118902...cc5f9e4789
psch dogbert17: well, it's clearly valgrind-specific behavior 17:33
dogbert17 psch: some kind of false positive?
psch dogbert17: and, well, VALGRIND_MEMPOOL_FREE has a really wonky looking #define, at least with my C knowledge
nqp/MoarVM/src/memdebug.h:18:#define VALGRIND_MEMPOOL_FREE(pool, addr) do { } while (0)
dogbert17 heh 17:34
psch dogbert17: mind, it might be that that kind of #define is something valgrind can do something with, i'd have no idea about that
dogbert17 my knowledge of C is not much help either 17:35
psch cursory google search turns up bugs.kde.org/show_bug.cgi?id=233298 17:36
no idea if that fits with what we're using, though
actually, it kinda seems wrong anyway
as the ticket is about free()s not showing up in the heap summary, and you've got an extra free() there 17:37
dogbert17 has valgrind-3.10.1 17:38
cygx the do..while thing is just a noop that gets used if MVM_VALGRIND_SUPPORT isn't defined 17:41
normally, you use it to group several statements and still have a function-like macro invocation that can be terminated with a semicolon 17:42
dogbert17 cygx: thanks for the explanation 17:44
since my C-knowledge isn't what it should be I have to ask about lines 46 and 132 in nfg.c. They seem to deal with different types, to my untrained eye. Is that how it's supposed to be? github.com/MoarVM/MoarVM/blob/mast.../nfg.c#L46 17:49
cygx at first glance, that looks suspect to me as well: the variable 'current' has type MVMNFGTrieNode, but sizeof(MVMNGFTrieNodeEntry) gets passed to the function 18:02
dogbert17: you're on 32-bit, correct? On 64-bit systems, MVMNFGTrieNode and MVMNGFTrieNodeEntry just happen to have the same size 18:10
dogbert17 cygx: aha, that's very interesting 18:11
just tried changing line 133 from 'sizeof(MVMNGFTrieNodeEntry)' -> 'sizeof(MVMNFGTrieNode)'
cygx also note that if FSA_SIZE_DEBUG is defined, MVM_fixed_size_free_at_safepoint will perform a sanity check 18:12
dogbert17 tried that with timotimo a few days ago and it screamed like hell :-)
will turn that on now ... 18:13
and suddenly there are no complaints! 18:15
cygx \o/ 18:17
dogbert17 cygx: so possibly we might have found a bug affecting 32 bit systems
cygx indeed 18:19
dogbert17 PR?
cygx note that sizeof also takes expressions, ie tha argument could be written as sizeof(*current) 18:20
that way, the compiler will figure out the type for you
dogbert17 interesing
cygx for consistency, you might explicitly supply the type, though
*might want to 18:21
dogbert17 ok, will run a spectest before going forward :-)
and probably write an RT as well unless one is alredy present 18:24
dalek p: 1212b7d | (Pawel Murias)++ | src/vm/js/ (3 files):
[js] Avoid passing the setup argument to Chunk.new when it's a [].
18:33
p: 3126d69 | (Pawel Murias)++ | src/vm/js/ (4 files):
[js] When building Chunks create less empty and one element arrays.
p: 38c8d8e | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (4 files):
[js] Make hll.slurpyArray take and array as second argument instead of having a weird hll.slurpyArray3 variant.
p: ad633d5 | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (3 files):
[js] Implement nqp::backtracestrings.

For now returns the raw js LTA backtrace.
stmuk_ rakudo.org/2016/11/27/announce-raku...e-2016-11/ 19:06
dalek ar: 67a60b7 | (Steve Mynott)++ | tools/star/release-guide.pod:
note 2016.11 release in release-guide.pod
19:10
cygx
.oO( Ja, is' denn heut’ scho’ Weihnachten? )
19:12
dalek p: 95134e4 | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
[js] Fix using QAST::WVals in CompUnit.pre_serialize.
19:23
p: c479170 | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
[js] Fix bug.
p: 41d50d5 | (Pawel Murias)++ | src/vm/js/nqp-runtime/runtime.js:
[js] Stop printing out the stack trace when wrapping an exception.
p: 10daa77 | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (2 files):
[js] When slurpy_array is not defined used a special bootstraping array type.
kudo/nom: e94725a | lizmat++ | / (4 files):
Refactor R:I:ShapeLeafIterator to only take list

And if that list is a native array, take the shape directly from that instead of first needing to HLLize it
19:26
kudo/nom: 331c2e2 | lizmat++ | / (2 files):
Copying a shaped 1+dimmed array upto 1.5x faster

By making the shape check a lot faster. Benchmark was for a 2x2. The "eqv" that we had before, needed to HLLlize the native int arrays as given by nqp::dimensions first. Perhaps we should have an nqp:::eqv for these types of checks.
19:46
dogbert17 cygx: PR sent 19:52
cygx dogbert17++ 19:53
lizmat merged 19:56
and dogbert17++
and cygx++ :-) 19:57
dogbert17 lizmat++ :-) 19:59
dogbert17 should of course have noticed that the name of the function is twiddle_trie_node and not MVMNFGTrieNode :( 20:05
lizmat dogbert17: should I revert ? 20:06
dogbert17 it's the commit message itself which contains an error
the fix is correct though
lizmat ah, we can live with that :-) 20:07
cygx and on the shoulder, a tiny red figure with horns on its forehead whispers: "Just use push -f. You know you want to, and what can it hurt doing it just this onnce..." 20:12
dalek kudo/nom: 7c1f5e1 | lizmat++ | src/core/native_array.pm:
Only set name of new type if not correct yet

Saves another 10% in a 2x2 matrix copy
20:23
ugexe is there a way to get at %*PRAGMAS outside of Perl6/[Actions|Grammar|World].nqp ? 20:55
FROGGS yes, inside of sub EXPORT and inside of traits 20:57
because these get invoked from P6G / P6A
viki m: .::
camelia rakudo-moar 8ca367: OUTPUT«===SORRY!===␤MVMArray: Can't pop from an empty array␤»
viki So where would I look for the code that handles that bit?
jnthn --ll-exception should be revealing 20:59
viki oh right
ugexe FROGGS: ah thanks, that worked. but I guess what I should have asked was how to get the list of all possible pragmas, not just the ones being used (github.com/rakudo/rakudo/blob/6bb8....nqp#L895) 21:11
FROGGS hmmm 21:14
I know that the pragmas 'variables' and 'parameters' are missing from that list
not sure what else
[Coke] we don't currently have an anticipated date for 6.d, do we? 21:46
I am not aware of one, but if we have one, advent writers should be aware so they don't overpromise. :)