FROGGS cool, that unicode stuff seems to do something 00:08
jnthn :)) 00:12
jnthn not having much fun finding this exception reporting regression
FROGGS gnight 00:21
jnthn Got it... 00:22
'night, FROGGS
timotimo \o/ 00:24
00:32 FROGGS[mobile] joined
jnthn Pushed the various bits I've done. 01:08
Got my cleanest spectest run yet 01:09
Didn't hang anywhere \o/
timotimo that's darn cool! :)
jnthn If anybody wants something to look into: wordcase seems busted, affecting a couple of test files. S32-str/capitalize.rakudo.moar is probably the best one to see
Time for some rest; night o/ 01:26
timotimo gnite! 01:27
02:23 FROGGS joined
diakopter hi 03:26
04:13 cognominal__ joined 05:40 brother joined
moritz S32-str/lc.t has an interesting failure 05:54
not ok 13 - lower-casing of greek Sigma respects word-final special case
# got: 'ĻƒĻƒĻƒ'
# expected: 'ĻƒĻƒĻ‚'
is 'Ī£Ī£Ī£'.lc, 'ĻƒĻƒĻ‚', 'lower-casing of greek Sigma respects word-final special case';
who decided that implementing Unicode things without a library in moarvm was a good idea? :-) 05:55
06:41 FROGGS[mobile] joined
arnsholt moritz: At least we have tests that tell us that things broke =) 07:30
07:43 FROGGS joined 08:11 lizmat joined 08:33 odc joined
nwc10 jnthn: I attempted to make an ƶl pun on the shopping list a few weeks ago 09:09
09:29 FROGGS[mobile] joined
nwc10 slow thing is still slow 09:33
7977 nicholas 30 10 285m 262m 14m R 99.6 0.3 1444:05 moar
JimmyZ jnthn: re github.com/MoarVM/MoarVM/commit/c1ab28dd1a, I thought MVM_gc_root_add_permanent is not needed after MVM_gc_allocate_gen2_default_set? 09:39
09:43 FROGGS[mobile] joined
FROGGS ENODALEK 10:14
nwc10 write a new one in Perl 6? 10:15
FROGGS :/ 10:16
ETOOMUCHTODO
jnthn JimmyZ: They do orthogonal things. 10:34
eeks, the code-gen wasn't doing anything with void context really 11:10
Checking for it in various places, but not passing it on.
omgz 11:14
Fixing that seems to have meant we generate sufficiently better code that CORE.setting compilation goes measurably faster 11:15
Aww, darn. Didn't get me sink context, though...
Ah...I see...I think. 11:18
FROGGS :o) 11:25
jnthn Clears up various failures. 11:37
nwc10 questhub.io seems to be for things one proposed to do oneself 11:39
is there anything for "SEP projects"? :-)
jnthn "Somebody Else Please..."? 11:40
nwc10 that's somewhat politer than what I was really meaning 11:41
hitchhikers.wikia.com/wiki/Somebody...blem_field
also, for some reason I've been comparing various things to "lemon-soaked paper napkins" recently -- hitchhikers.wikia.com/wiki/Frogstar_World_B 11:42
timotimo hah 11:44
on questhub you can create a quest and "drop out" and say "someone else can do it"
jnthn perl6-m -e "say Bool.roll(30)" 11:52
True True True True True True True True True True True True True True True True True True True True True True True True True True True True True True
...unlikely :P
The roll tests on various types fail. 11:53
timotimo i could look into that for a little bit
need to build current things first, though
did the void context thing make a drastic difference? 11:54
jnthn Seems it fixed a range of things 11:55
timotimo ah, test fixes
jnthn And stage parse fell to 68s here
timotimo that's good, too
jnthn Was around 78s before
nwc10 is that a MoarVM only improvement? Or all backends?
timotimo oh that's not bad :D
moarvm only
jnthn nwc10: MoarVM only. The other backends are already doing sink context right...otherwise we'd know about it :)
nwc10 ah OK 11:56
slow thing is still somewhere in stage parse, after about 27 hours 11:57
jnthn r: say 2.rand for 1..10
camelia rakudo-parrot f614e5: OUTPUTĀ«0.365268836910161ā¤0.564055266866738ā¤1.92259827227635ā¤0.438273427333264ā¤1.58254501732878ā¤0.272373119642616ā¤1.36210254308587ā¤1.01151375424235ā¤1.94483478239408ā¤0.506384388110369ā¤Ā»
..rakudo-jvm f614e5: OUTPUTĀ«1.0080365396270556ā¤0.29770801268032865ā¤1.6501561681619104ā¤1.9817874191804223ā¤1.8108484226410284ā¤0.7550679563410723ā¤0.8563296906474187ā¤1.9931871459625206ā¤1.1211630444843945ā¤1.656239266223772ā¤Ā»
jnthn On MoarVM, those all come out between 0 and 1 :)
Uh, < 1
nwc10 so, unscaled
jnthn nqp-m: say(nqp::rand_n(2)) while 1 11:58
camelia nqp-moarvm: OUTPUTĀ«(signal XFSZ)0.406725ā¤0.878274ā¤0.947417ā¤0.207722ā¤0.03578ā¤0.900015ā¤0.675006ā¤0.574342ā¤0.845325ā¤0.645564ā¤0.128721ā¤0.357287ā¤0.668499ā¤0.265478ā¤0.664169ā¤0.446007ā¤0.102744ā¤0.772941ā¤0.677871ā¤0.035837ā¤0.231929ā¤0.737316ā¤0.69049ā¤ā€¦Ā»
jnthn Ah, there we are
timotimo /home/timo/build/rakudo/install/bin/nqp-m --target=mbc --output=blib/Perl6/BOOTSTRAP.moarvm --encoding=utf8 \ --vmlibs=dynext/libperl6_ops_moar.so=Rakudo_ops_init src/gen/m-BOOTSTRAP.nqp 11:59
Segmentation fault (core dumped)
well, that's not good :\
jnthn :/
Oh, darn...the MoarVM rand op doesn't actually scale at all 12:01
As in, doesn't even take an arg
timotimo %) 12:03
this is a --optimize=3 moarvm 12:04
so i don't actually have any debug symbols >_>
jnthn Ah, maybe that's the issue...
jnthn heard some other mumbling about "bust on -O3" recently...
timotimo i'll try -O1 instead 12:05
well, that immediately helped 12:06
nwc10 aliasing? 12:07
does -O3 enable aliasing based optimisations on gcc?
timotimo don't know
Stage parse : 75.045 - oh well :\ 12:08
oh wait, you meant the compile time for stage mast, didn't you?
jnthn timotimo: No, it was stage parse that shrunk here 12:09
timotimo Stage mast : 69.475 - i remember it being this slow before as well :\
OK
jnthn timotimo: You did build latest NQP?
timotimo yeah
jnthn hm
timotimo wait, maybe i didn't give it the right prefix
jnthn Well, if your resulting perl6-m doesn't sink, you know you missed my fix :)
timotimo hm. i built moarvm -o3 again and it segfaulted at the same point again :| 12:15
-O2 dies, too
jnthn Could be aliasing based opts...I'm quite sure we're not safe in that regard.
timotimo OK 12:16
i'm not sure how you would have to treat C code to make sure those opts are safe
Stage parse : 78.873 - hum 12:18
timotimo is not fully awake yet and not sure how to try to sink something 12:20
jnthn r: 42 but role { method sink() { say 'sunk' } }; say 42 12:21
camelia rakudo-parrot f614e5, rakudo-jvm f614e5: OUTPUTĀ«sunkā¤42ā¤Ā»
jnthn If it doesn't say "sunk", you're missing the fix
timotimo sunk 12:22
42
i got the fix, but no happy performance yet
there'll be plenty performance improvements in the future, though :)
jnthn bah, all the reduce tests we fail are involving && 12:23
uh
^^
not ok 324 - |"10"| reduce [^^] true string variable test #8
not ok 325 - |"10"| reduce [^^] true string variable test #9
etc
timotimo so maybe it's our ^^ and not our reduce that's busted?
did i ask this already? should i look into making rand scale on moar?
jnthn r: say ([^^] 0, 42)
camelia rakudo-parrot f614e5, rakudo-jvm f614e5: OUTPUTĀ«42ā¤Ā»
timotimo it's not much more than multiplying the result with the scale, right? 12:24
jnthn timotimo: I already fixed rand scaling :)
timotimo oh! :)
jnthn damm, miss dalek...
timotimo: Yes, I'm very sure it's our &&
dammit
^^
timotimo :)
jnthn Yeah, we get Nil 12:25
oh...it's a silly one 12:26
timotimo is looking forward to the diff :)
jnthn yeah 12:27
It just doesn't decont for testing for truth in the code-gen.
So it ends up checking if the Scalar itself, which is true by virtue of not being a type object.
timotimo hehe :)
jnthn yeah, 'twas that 12:43
timotimo i may not ever have the necessary intuition to figure out when a thing we get needs to get decont'd or not 12:44
jnthn Well, when you use nqp::ops they largely do the right thing for you 12:47
timotimo right. but if i *implement* nqp::ops, i have to do the right thing for them :) 12:48
jnthn timotimo: I'll be heading out soon, but if you want something to look at that probably clears up a couple of other tests too: S32-num\rounders.t 13:07
Down to around 90 test files that need attention in my latest run. 13:11
timotimo wow :) 13:13
i can have a quick look, sure
jnthn oh, also that spectest run happened in 1261s, while last night's took 1568s... 13:19
timotimo \o/ 13:34
now i can have a look at those tests
... except i'm still struggling to get randscale_n up and running >_< 13:38
jnthn bbl &
timotimo now it works and i can look at the tests 13:48
[Coke] slept instead of doing a night time moar run. daily run will kick off shortly anyway. 13:53
timotimo i think the rounding trouble has to do with Rats 13:54
this could be due to div behaving like parrot 13:56
-9 div 10 is 0 on moar
AIUI that's wrong 13:57
moritz yes
timotimo i'll fix it in moar if i can.
moritz parrot has the same bug, it seems
timotimo yes
see also src/core/Rational.pm where it explicitly complains about parrot's div being wrong 13:58
though trying to work around it in the rational implementation of floor rather than special-casing negative div on parrot feels iffy to me
13:58 FROGGS[mobile] joined
timotimo moar just implements that as result = operand_1 / operand_2 14:00
so i suppose that should be (operand_2 < 0 ? operand_2 - 1 : operand_2)?
how big do i need to go to get a big int? above 64 bits i think? 14:02
r: say (2 ** 70)
camelia rakudo-parrot f614e5, rakudo-jvm f614e5: OUTPUTĀ«1180591620717411303424ā¤Ā»
timotimo r: say (2 ** 70 - 1) div (2 ** 70)
camelia rakudo-parrot f614e5, rakudo-jvm f614e5: OUTPUTĀ«0ā¤Ā»
timotimo maybe that's already correct, due to being implemented by libtommath?
hm. just subtracting 1 may go wrong if the number is right at the edge of becoming a big integer 14:04
oops, i need to check if the *numerator* is < 0, not the denominator 14:07
silly me
still getting some Not OKs, huh 14:34
14:37 FROGGS[mobile] joined
timotimo that test above was bogus, aha! 14:37
r: say (-(2 ** 70)) div (2 ** 70 - 1)
camelia rakudo-jvm f614e5: OUTPUTĀ«-2ā¤Ā»
..rakudo-parrot f614e5: OUTPUTĀ«-1ā¤Ā»
timotimo r: say (-(2 ** 70)) div ((2 ** 70) - 1) 14:38
camelia rakudo-jvm f614e5: OUTPUTĀ«-2ā¤Ā»
..rakudo-parrot f614e5: OUTPUTĀ«-1ā¤Ā»
timotimo ... huh
i suppose i could MVM_bigint_cmp the numerator to 0 and if it comes up negative (-1, that is) i need to subtract one with MVM_bigint_sub? 14:40
ah, there's MP_EQ and such
Cannot call 'Real'; none of these signatures match: 14:45
:(Mu:U \v: Mu *%_)
wow, i must have done some pretty impressive mistake
diakopter moritz: jnthn did, but I agreed. yep need to add that special case if it's part of Unicode 14:56
otherwise shoukd be in hll 14:57
timotimo i made -0.5 not work any more >_< 14:58
ah, maybe because i didn't change div_In 15:00
... nope 15:02
i need to take a nap. if somebody would like to investigate the negative_integer_division branch of MoarVM against t/spec/S32-num/rounders.t, be my guest 15:10
15:37 grondilu joined
FROGGS holds his breath while rakudo compiles 15:43
moritz tickles FROGGS 15:44
FROGGS (>.<) 15:45
damn, I made it worse... 15:50
FROGGS tries again
16:47 FROGGS[mobile] joined
[Coke] feather.perl6.nl/~coke/moar.out updated with today's run. 16:50
r: say 26962 / 28454 16:51
camelia rakudo-parrot f614e5, rakudo-jvm f614e5: OUTPUTĀ«0.947564ā¤Ā»
[Coke] r: say 28454*.95-26962 16:52
camelia rakudo-parrot f614e5, rakudo-jvm f614e5: OUTPUTĀ«69.3ā¤Ā»
diakopter heh. 16:55
again, as jnthn pointed out, I did un-skip some in properties-derived, so that'll skew the vs-parrot numbers some 16:56
[Coke] diakopter: you keep saying that, but you unskipped them for -moar-. if anything, moar should be doing better. 16:58
diakopter FROGGS[mobile]++ FROGGS++ reading my baby Perl code in ucd2c.pl
[Coke] (and today it was. doesn't explain the weird drop eysterday) 16:59
FROGGS diakopter: one test file only fails three tests now (>100 before), but the others fail more...
diakopter [Coke]: right, but jnthn meant it skews the vs-parrot numbers if we're wanting to track progress toward matching parrot
haha {"Ancient_Greek_Numbers",6},{"AncientGreekNumbers",6},{"ancientgreeknumbers",6}, {"Ancient_Greek_Numbers",6},{"AncientGreekNumbers",6},{"ancientgreeknumbers",6} 17:01
FROGGS: seems you need some de-duping
[Coke] gist.github.com/coke/8250608 updated. 17:02
we have a segfault again.
no timeouts, though!
diakopter halting problem solved!
[Coke] biggest source of moar failures is now S05-mass/* 17:03
diakopter everyone marvel at the beautiful generated binary search algorithm in MVM_codepoint_to_row_index in raw2.github.com/MoarVM/MoarVM/0098...icode_db.c 17:04
[Coke] r: say 720/1176 # %age of failures in S05 total. 17:05
camelia rakudo-parrot f614e5, rakudo-jvm f614e5: OUTPUTĀ«0.612245ā¤Ā»
diakopter ouch
FROGGS I am working on that and hope that I can push in a few hours 17:06
[Coke] FROGGS++
r: say (26962+720)/28454 # if FROGGS++ fixes all the s05 bugs: 17:07
camelia rakudo-parrot f614e5, rakudo-jvm f614e5: OUTPUTĀ«0.972868ā¤Ā»
[Coke] I wish I had time to actually fix bugs rather than cheer from the sides here. :)
diakopter: there's actual code in that file? ... oh, there it is.
diakopter [Coke]: yeah lots of recursively generated code 17:08
[Coke] all I see is a giant set of data, then about 40 lines at the end. 17:09
diakopter well, a few hundred
[Coke] oh, there's more above that.
diakopter manually bit-packed columns 17:10
[Coke] that segfault seems dodgy. I was golfing it down, and it's vanished. (even where it was segfaulting before) 17:16
ooh, and then I got: Internal error: Unwound entire stack and missed handler 17:21
FROGGS [Coke]: you are a great help though 17:34
I have a problem... ASCIIHexDigit has a property_code of 25, but it fails to resolve the property_value_code 17:49
and later, when it gets the value code of the code point to compare it against the property_value_code, the value code is 1 so the cmp fails 17:50
:/
it can resolve the property_value_code of ASCII though 18:00
hmmm, so ASCIIHexDigit is just missing in unicode_property_value_keypairs? 18:03
I guess that is another place where we need to care about aliases... 18:04
/home/froggs/dev/MoarVM/UNIDATA/PropertyAliases.txt:130:AHex ; ASCII_Hex_Digit
/home/froggs/dev/MoarVM/UNIDATA/PropertyValueAliases.txt:57:# ASCII_Hex_Digit (AHex)
okay, I think I understand, though, need more brane to fix it 18:37
diakopter throws you three brane 18:38
grondilu notices that perl6-m returns creates Blob wih negative values: 18:43
./perl6-m -e 'say Blob.new: (^256).roll: 5;'
Buf:0x<-3a 73 -1 -14 -33>
benabik grondilu: Well, that makes sense if Buf is full of signed 8bit values. 18:47
jnthn I think it just doesn't handle uint8 righ tyet 18:50
Just an NYI
grondilu ok
jnthn We've a handful of those still :) 18:51
19:11 ssutch joined
FROGGS that is my diff btw, with debug output, but one should see how it looks up blocks like in <:InArabic> 19:11
gist.github.com/FROGGS/b39bb6ed35370d763c91
though, <:Digit> drives me nuts atm 19:12
bbiab
diakopter FROGGS: yeah, I kinda deferred much of Digit iirc
er 19:13
maybe I didn't
FROGGS[mobile] the problem seems to be that the property value code for Digit is resolved as the one of Numeric 19:27
but Digit is just a part of Numeric
19:56 jnap joined 20:10 dalek joined 20:23 jnap left
timotimo no one had a look at my integer division code? i bet it's easy to figure out if you've seen the multiprecision arithmetic code a few times before :| 20:27
20:31 FROGGS[mobile] joined 20:44 jnap joined 20:56 FROGGS[mobile] joined
jnthn eliminates 2 more of the errors from the [Coke] gist 21:38
[Coke] \o/ 21:49
FROGGS: any luck with unicode? 21:50
jnthn btw, I probably won't have many tuits at all during the next 5-6 days. 21:52
(But tuit supply looks good again after that.) 21:53
21:55 FROGGS[mobile] joined
timotimo jnthn: if you have just a moment, want to check out my integer division branch? 22:04
it makes code like -0.5 fail :( 22:05
timotimo gotta run 22:09
[Coke] moar: 94.76% 22:22
jnthn timotimo: Will take a look 22:29
wait, which repo?
timotimo i hope the mistake is simple and silly
mvm
22:29 jnap left
jnthn mp_sub_d(ib, 1, ib); 22:31
Here you are mutating the original (supposedly immutable) Int
Need to put the ib - 1 into another temporary, use it in the calc, then clear it 22:33
timotimo oh! 22:34
i canbfix that inbabout half an hour
got enough code in the vicinity to cargo-cult
23:23 FROGGS[mobile] joined
timotimo meh. after that change i still get Cannot call 'Real'; none of these signatures match: 23:23
oh, wait. i'm not even using temp_b for the calculation %) 23:27

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!