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«109876543210» | ||
TimToady | m: sub foo ($n) { say $n; samewith $n - 1 if $n; say "foo" }; foo(10) | 15:50 | |
camelia | rakudo-moar 8ca367: OUTPUT«109876543210foofoofoofoofoofoofoofoofoofoofoo» | ||
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. :) |