dalek ast: d8650f2 | usev6++ | S32-num/int.t:
Test for X::Numeric::Overflow passes on JVM
 05:27
roast: 0981b4b | usev6++ | S05-mass/charsets.t:
roast: Unfudge tests that require Java 8 (unicode 6.1)
roast:
roast: The tests in question require unicode 6.1 and therefore
roast: fail with Java < 8. On the other hand we already have
roast: unfudged tests that require Java 8 elsewhere.
roast:
roast: Java 8 was released 2014-03-18 so it seems reasonable
roast: to unfudge those tests.
[Tux] This is Rakudo version 2016.09-144-g2285d35 built on MoarVM version 2016.09-27-g0bdbd6e 07:36
csv-ip5xs 3.169
test 16.171
test-t 7.026
csv-parser 17.886
psch hm, i'm not too happy about unfudging tests needing java 1.8 08:45
mostly 'cause hack is only 1.7.0_111 :l 08:46
s/only/on/
although that seems to be a distro version thing. 1.8 isn't in apt-cache 08:47
bartolin psch: I have no strong opinion about that. but I would prefer to keep it consistent. so, if we revert the above commit we should also fudge some other tests which don't pass with jdk 1.7 08:50
nine I guess hack could also be updated
bartolin (or do I remember that wrong? I'm mostly testing with jdk 1.8 now)
psch bartolin: well, i'd prefer we make 1.8 a hard-ish requirement on the spectest-side
as in, let people build with 1.7 if they want to, and only force 1.7 on the compiler as well 08:51
bartolin even better
psch but failing tests due to 1.7 are eh
although we probably should note in roast that those *are* 1.7 failures
maybe even skip if we can fudge that somehow...
nine: yes please :)
j: $*VM.properties<java.version>.say 08:54
camelia rakudo-jvm 2a1605: OUTPUT«1.7.0_79␤»
psch camelia is also some 30 minor patches behind hack
nine psch: I don't even have an account on hack ;) But you could have one on my server.
nine goes off to update camelia
Should I install jdk 1.8 on camelia instead?
psch nine: thanks, i'll just bugged moritz about hack though :)
yeah, if only for unicode 08:55
i'm not sure we have anything else that depends on 1.8, but it might be somewhat faster too i hope :)
bartolin I'm afraid we have some kind of a structural problem with regard to the unicode version on JVM anyway. with moarvm we know which unicode version we support -- with jvm that depends on the locally installed java version 08:58
so, I think it would be nice to have a way to fudge according to the java version (or the supported unicode version)
bartolin doesn't know about a simple way to do that 08:59
errands & 09:00
psch well, whatever the harness does to test for jvm or moar could probably be extended to $*VM.properties<java.version> if $backend eq 'jvm' or something
although i'm not sure about the fudge syntax, that'd have to be something relative which means more parsing for the fudger 09:01
s/harness/fudger/
hm, although we could probably go with a min version 09:02
hm, the java 9 RC is planned for 2017-01-26 09:03
ohh, the process control changes look pretty neat 09:06
not sure we want to build Proc::Async on that, but it'd probably be easier than on 1.7 heh 09:07
but yeah, probably a bad idea, considering release is supposed to be on 2017-03-23 and there'll probably be a few months for distros etc to fully catch up and all... 09:08
nine j: $*VM.properties<java.version>.say 09:09
camelia rakudo-jvm 2a1605: OUTPUT«1.8.0_101␤»
psch nine++
nine Oh, it didn't even have to rebuild? 09:10
psch well, the build targets 1.7
rakudo build that is
r: say gather do for ^4 { next if $_ < 2; .take } 09:20
camelia rakudo-moar 2285d3, rakudo-jvm 2a1605: OUTPUT«(2 3)␤»
psch r: say gather do for ^4 { redo if $_ < 2 && $++ == 0; .take }
camelia rakudo-moar 2285d3, rakudo-jvm 2a1605: OUTPUT«(0 1 2 3)␤»
psch r: say gather do for ^4 { .take; redo if $_ < 2 && $++ == 0; }
camelia 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…»
..rakudo-moar 2285d3: OUTPUT«(0 0 1 2 3)␤»
psch r: say gather do for ^4 { .take; redo if $_ < 2 && $++ == 0; 1 }
camelia rakudo-moar 2285d3: OUTPUT«WARNINGS for <tmp>:␤Useless use of constant integer 1 in sink context (line 1)␤(0 0 1 2 3)␤»
..rakudo-jvm 2a1605: OUTPUT«WARNINGS for <tmp>:␤Useless use of constant integer 1 in sink context (line 1)␤Error in socket connection:org.perl6.nqp.runtime.UnwindException␤ at org.perl6.nqp.runtime.ThreadContext.<init>(ThreadContext.java:125)␤ at org.perl6.nqp.runtime.GlobalCo…»
psch humm
that's kinda extra weird 09:21
'cause CX::Next and CX::Redo handlers are somewhat linked during codegen
as in, we handle codegen for them together
but CX::Last gets its own code path for handler generation 09:22
so the fact that redo and last don't work but next does..?
oh geez 09:45
shoulda probably checked that earlier...
ah nvm bad test case
r: 'my \x := gather do for ^3 { .take; last }; use nqp; say nqp::getattr(List.from-iterator(x.iterator), List, q[$!todo]).reify-until-lazy 09:56
camelia rakudo-moar 2285d3: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Unable to parse expression in single quotes; couldn't find final "'" ␤at <tmp>:1␤------> ator), List, q[$!todo]).reify-until-lazy⏏<EOL>␤ expecting any of:␤ single quotes␤ …»
..rakudo-jvm 2a1605: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Unable to parse expression in single quotes; couldn't find final "'" ␤at <tmp>:1␤------> ator), List, q[$!todo]).reify-until-lazy⏏<EOL>␤ expecting any of:␤ single quotes␤ t…»
psch r: my \x := gather do for ^3 { .take; last }; use nqp; say nqp::getattr(List.from-iterator(x.iterator), List, q[$!todo]).reify-until-lazy
camelia rakudo-moar 2285d3: OUTPUT«1␤»
..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 that seems to be the most gutsy way to get that error afaict
as in, the UnwindException probably comes from reify-until-lazy on a List::Reifier that was build with gather/take *and* last..? 09:57
r: my \x := gather do for ^3 { .take; last }; use nqp; say nqp::getattr(List.from-iterator(x.iterator), List, q[$!todo]).reify-at-least(2)
camelia rakudo-moar 2285d3, rakudo-jvm 2a1605: OUTPUT«1␤»
lizmat Files=1146, Tests=53274, 235 wallclock secs (13.55 usr 4.08 sys + 1408.17 cusr 137.00 csys = 1562.80 CPU)
bartolin just another thought wrt fudging and unicode support: *if* we are going to do that, wouldn't it be useful to have some optional condition like 'unicode >= 6.1' for the fudge syntax? that way roast wouldn't be polluted with checks for specific backend versions -- that infomation could be kept in the fudger 10:17
psch i suppose it depends on whether we to fudge specifically for unicode or for backend versions 10:18
i'm somewhat sure jvm doesn't bump unicode during minor patches, but not completely
FROGGS we could let the backends expose their supported unicode version 10:25
jnthn fwiw, I suspect to do NFG and other Perl 6 Unicode features right we may well end up shipping our own Unicode database on the JVM anyway 10:37
Which'd give us control over it
psch oh, right, that's a thing 10:40
FROGGS yes, that's the only sane way to go 10:45
also, IIRC we are meant to let the user lexically choose the unicode version 10:46
that too means we have do ship it ourselfs
jnthn is happy to kick that particular can a little way down the road :) 10:47
Unicode's only stability policy is relatively strong, so I'm curious if such a thing would be overkill 10:48
timotimo own*
ownly? :)
jnthn uh, yes :)
Maybe I shoulda done coffee instead of tea this morning :) 10:49
ShimmerFairy jnthn: for what it's worth, I believe I wrote in the "set Unicode version" stuff into the spec more for telling old perl6's if your expectation of Unicode is too new for them. And even if that wasn't my intent at the time, such a feature is probably most useful for that :) 12:29
(e.g. a newly-added script with properties that don't match what they defaulted to in previous Unicode versions) 12:30
an even better example would be brand new properties, which are kinda hard to work around with an old Unicode version :P 12:34
nine Isn't that just something for the Perl 6 version? 12:38
ShimmerFairy nine: not unless we want to tie specific Unicode versions to Perl 6 versions, which we don't currently do. (That is, MoarVM's UCD is updated as new versions come out IIRC) 12:39
(not that a minimum Unicode version would be bad, I'm just not sure about "and no newer") 12:44
jnthn Maybe given the Unicode stability policy, something like "`use 6.c` promises a minimum of Unicode 8, `use 6.d` promises a minimum of Unicode 9" etc. 14:51
Would be sufficient. 14:52
dogbert17 o/ 18:11
FWiW, sometimes the test t/spec/S17-supply/start.t, i.e throwing a lot of 'Invalid read of size 4', must run it many times to get that effect 18:12
it looks quite suspicious 18:13
looks like this 18:14
==4344== Invalid read of size 4
==4344== at 0x416EA53: MVM_sc_get_object (sc.c:178)
==4344== by 0x416EBD1: MVM_sc_get_sc_object (sc.c:199)
==4344== by 0x40D5B3F: MVM_interp_run (interp.c:3013)
==4344== by 0x40F8B0F: start_thread (threads.c:77)
==4344== by 0x41E4756: uv__thread_start (in /home/dogbert/repos/rakudo/install/lib/libmoar.so)
==4344== by 0x45EAF71: start_thread (pthread_create.c:312)
==4344== by 0x44DAF8D: clone (clone.S:129)Y
==4643== Address 0x5aff1f0 is 24 bytes inside a block of size 108 free'd 18:18
==4643== at 0x402B3D8: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==4643== by 0x414E8DD: MVM_free (alloc.h:29)
==4643== by 0x414F806: gc_free (SCRef.c:114)
==4643== by 0x411A11F: MVM_gc_collect_free_nursery_uncopied (collect.c:580)
==4643== by 0x411520E: MVM_gc_global_destruction (orchestrate.c:511)
==4643== by 0x41C8CCF: MVM_vm_destroy_instance (moar.c:391)
==4643== by 0x8048EB8: main (main.c:194)
dalek p: d06cbaf | (Pawel Murias)++ | t/nqp/019-file-ops.t:
Fix bug cause by refactoring.
 18:28
nqp: 4c697e3 | (Pawel Murias)++ | src/vm/js/ (3 files):
nqp: [js] Get and set attributes using accessors.
dogbert17 my ramblings above have now been transformed to rt.perl.org/Public/Bug/Display.html?id=129832 18:53
dalek kudo/nom: 8f14219 | MasterDuke17++ | src/Perl6/Metamodel/CurriedRoleHOW.nqp:
Add shortname() method to CurriedRoleHOW

Fixes RT #129830		 18:58
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129830
dalek kudo/nom: 3ca0f8b | lizmat++ | src/Perl6/Metamodel/CurriedRoleHOW.nqp:
Merge pull request #899 from MasterDuke17/RT129830

Add shortname() method to CurriedRoleHOW
raiph .tell lizmat Please read www.reddit.com/r/perl/comments/557...ks/d8ha7sd for a summary regarding Chas Owens' fears/assertions re NYI Uni and Str roundtripping. Perhaps everyone has already heard enough about it already but if not, maybe it's worth mentioning this sub-thread as a topic completely distinct from books in the 19:16
weekly. Also, do you think an RT and/or doc patch are warranted?
dalek kudo/more_sizeof_tests: 7c11722 | FROGGS++ | t/04-nativecall/12-sizeof. (2 files):
add more tests for nativesizeof()
 19:51
psch raiph++ 19:56
that interaction seems to have been handled very gracefully
i'm not deep enough into Unicode to offer technical feedback though
arnsholt It's not at all clear to me *why* this is a problem 20:05
jnthn Str roundtrips *Unicode* just fine in so far as if you ask any other Unicode-aware program if the input and output are equivalent, they should answer yes (reference: unicode.org/faq/normalization.html#1 )
arnsholt Except possibly in the case where you're forced to interact with other programs that don't handle Unicode correctly
Yeah, that's the thing. Str is Unicode; if you're relying on exact code point sequences you're a) doing it wrong, and b) not actually Unicode-compliant 20:06
jnthn What's being asked for is a way to roundtrip the exact codepoints that were read in, while at the same time actually wanting to work with them as codepoints rather than bytes. Compared to working with Unicode and working with bunches of bytes, that's a rather more niche use-case. 20:07
(Thus why it's not been prioritized.) 20:08
And yes, I think you'd generally want to do it when dealing with other things with "interesting" Unicode handling.
psch jnthn: iiuc we're doing what Unicode demands, but the poster demands backwards compat with not-quite Unicode compliant programs, without wanting to fall back to byte-like handling? 20:09
jnthn psch: Something like that 20:10
It's not an unreasonable request, but it would be an unreasonable default.
psch right, so it does exactly fall into the propose/speculated 'use Uni' space 20:11
jnthn Well, the Uni data type
Which will get more attention with time
psch oh, i'm not trying to push for it, don't get me wrong. i just wanna understand the concerns raised in the post
well, and maybe also the "what we're gonna do about it" 20:12
...considering that jvm is so far behind on NFG i might have to learn this stuff eventually anyway :)
(although maybe bartolin++ picks it up instead, they've been doing a hell of a job on things i couldn't figure out :) )
jnthn :-) 20:13
jnthn is happy to see folks hacking on the JVM bits
psch i *still* have a big "are there giant performance snags nobody noticed" thought running around in my brain 20:14
but i'm fairly sure i don't know the architecture well enough to judge that in the first place
nevermind the jvm itself, sooo
anyway, yeah, the problem in the reddit post is sort of "my app is bad at unicode, and rakudo isn't. fix that in rakudo please" 20:15
if i understood this correctly at least
...unfortunately i think we cannot reach a consensus there, basically at all 20:16
because "well if you use this pragma" it already makes it seem like you need "this pragma"
and using the pragma when you don't need it doesn't hurt either, because apps that do unicode right still deal with it correctly
feels somewhat faustian 20:17
jnthn I'd not say "doesn't hurt"
psch ...no, that's the wrong word. "faustian" that is
jnthn "Turns O(1) things into O(n) things" hurts.
Which will be a side-effect
.chars on a Uni is O(n), not O(1) like on Str
psch oh, okay. so that's the big gain when you know you're dealing with Unicode compliant apps 20:18
timotimo so we're not going to be creating synthetics for "ä in NFG", "ä in NFC", "ä in NKFC", ... ?
jnthn No
timotimo hm 20:19
jnthn We'll just keep an array of codepoints.
Uni is actually a VMArray today REPR-wise
timotimo and we'll offer stringy operations on top of that, yeah?
right
jnthn Yeah, though some are kinda hard-ish to define
timotimo so it's theoretically mutable ... do we allow it to be mutated?
jnthn No
timotimo OK, so string-y in that way, too
jnthn In fact we could base it on MultiDimArray to take advantage of fixed-width 20:20
timotimo ah
not that that's an advantage at the moment :P
jnthn Not yet, though will be in the future
timotimo performance-wise, i mean
right
psch .tell raiph check irclog.perlgeek.de/perl6-dev/2016-...i_13363563 for more input re: that reddit post 20:21
oh wait
we still don't have that kinda bot here
geez
anyway, thanks for the explanation jnthn++ :) 20:22
psch gets themselves bedwards
jnthn :) 20:23
Rest well
timotimo good bed, psch
jnthn: any clue about if we should make positional sizes unsigned across the board? 20:24
hm, maybe those repr ops predate us having real unsigned integers in our bytecode?
jnthn timotimo: I considered going down that path and didn't
It seems nice until you consider that pretty much all index calcs are done with Int/int anyway 20:25
timotimo mhm 20:26
also, we're not in reach of having even int8 arrays with 2**64 slots
jnthn m: say 2 ** 63 20:29
camelia rakudo-moar 3ca0f8: OUTPUT«9223372036854775808␤»
timotimo m: say (2 ** 63) / (1024 * 1024 * 1024 * 1024), " terabyte" 20:30
camelia rakudo-moar 3ca0f8: OUTPUT«8388608 terabyte␤»
timotimo m: say (2 ** 63) / (1024 * 1024 * 1024 * 1024 * 1024), " petabyte"
camelia rakudo-moar 3ca0f8: OUTPUT«8192 petabyte␤»
cygx_ put in his own 2 cent: www.reddit.com/r/perl/comments/557...ks/d8jlxji 20:40
timotimo jnthn: will we move toward using Uni for path names and such? 20:42
jnthn timotimo: Doubt it 20:43
cygx_ what's the perl6 story on how to handle non-normalized filenames? 20:44
or rther, what is it supposed to be :p
jnthn cygx_: The utf8-c8 encoding is meant to play that role by mapping things that would either fail to decode or be changed by normalization to synthetic codepoints, then back. 20:45
Moar already uses it in the applicable places 20:47
timotimo ah, so we'll get support for normalization changes there
jnthn Yeah
The thing already needs a doing over
cygx_
.oO(what about utf-16-ish things like windows)
timotimo windows has unicode awareness built into the FS 20:48
so we don't have that problem there, right?
like, you can't have a file ä.txt and a file ä.txt (with the other thing) as two separate files in the same dir?
jnthn
.oO(WideCharToMultiByte/MultiByteToWideChar)
 20:49
geekosaur yes, it normalizes. So does OS X HFS+ 20:50
cygx_ geekosaur: according to a 2011 stackoverflow answer, Windows at the very least did not use to... 20:51
"the file system treats path and file names as an opaque sequence of WCHARs." 20:52
from msdn.microsoft.com/en-us/library/w...s.85).aspx 20:53
geekosaur the complete version of that sentence (including the initial part) makes no sense though 20:57
"There is no need to perform any Unicode normalization on path and file name strings for use by the Windows file I/O API functions" can only be true if it *does* normalize
cygx_ the formulation is misleading, but the rest of the paragraph clarifies it 20:59
you do not 'need' to normalize because all strings are non-normalized 21:00
you 'only' have to treat them as opaque
geekosaur soooo, windows acts like native unicode except when it doesn't and introduces all the problems that unnormalized names give you. wonder how many people have stolen data that way so far. (also wonder how many windows programs explode if you have both versions of a compose-able letter) 21:01
dalek p: 916b2fd | FROGGS++ | tools/build/MOAR_REVISION:
bump moar for nativecall improvements
 21:11
kudo/nom: 677db95 | FROGGS++ | t/04-nativecall/12-sizeof. (2 files):
add more tests for nativesizeof()
 21:12
kudo/nom: 6977b87 | FROGGS++ | tools/build/NQP_REVISION:
bump nqp/moar for nativecall improvements
lizmat m: 42 R= my $a; say $a # wheeee :-) 21:36
camelia rakudo-moar 6977b8: OUTPUT«42␤»
dalek ast: 7d6ddc6 | MasterDuke17++ | S12-class/attributes.t:
Test .gist for attribute types

Requires github.com/rakudo/rakudo/pull/899
Tests for RT #129830		 23:21
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129830
Zoffix .tell psch we do have the .tell bot. It just got stuck behind the netsplit 23:49
yoleaux2 Zoffix: I'll pass your message to psch.

Powered by Cro and the Raku® Programming Language.

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

Thank you!