Geth nqp: tbrowder++ created pull request #636:
Improve error message for erroneous <.panic()> syntax		 00:20
06:42 domidumont joined 07:10 jmerelo joined
jmerelo Hey 07:13
releasable6: status 07:18
releasable6 jmerelo, Next release in ≈33 days and ≈11 hours. There are no known blockers. Changelog for this release was not started yet
jmerelo, Details: gist.github.com/f2348988d45525f115...4758c96825
08:06 sena_kun joined
lizmat Files=1306, Tests=111271, 226 wallclock secs (28.56 usr 8.46 sys + 3044.15 cusr 290.01 csys = 3371.18 CPU) 08:24
that's pretty bad, hope it's a fluke
08:26 Altai-man_ joined 08:28 sena_kun left
MasterDuke i just ran three times and they seemed to take about the usual time. but i did consistently get fails in t/spec/S32-str/utf8-c8.t `Non-zero exit status: 255 Parse errors: Bad plan. You planned 66 tests but ran 33.` 08:46
`Unexpected named argument 'bin' passed in block at t/spec/S32-str/utf8-c8.t line 139 in block <unit> at t/spec/S32-str/utf8-c8.t line 106` 08:47
lizmat MasterDuke are you on MacOS ?
MasterDuke linux 08:48
lizmat hmmm.... I thought that error was MacOS specific
I looks like I borked it 08:49
otoh, ":bin" is not a documented parameter to spurt
Geth roast: fd7f927997 | (Elizabeth Mattijsen)++ | S32-str/utf8-c8.t
:bin is not a parameter to spurt

Spurting a Blob implies binary writing. This was previously not caught as the named parameter was just passed on into oblivion.		 08:51
lizmat MasterDuke ^^
MasterDuke lizmat++ all clear now, times look normal 08:54
lizmat ok, then it must be something on my machine that slowed down the spectest 08:55
ahh.... it may have been my image backup running still 08:56
MasterDuke btw, anyone know what the long delay is when starting a spectest before the tests actually start? 09:00
the fudging i assume? 09:01
lizmat precomping a lot ? 09:09
MasterDuke well. it happens even on repeated runs with no code changes
and wow, spectest6 takes 376s for me, but spectest takes 128s 09:10
lizmat how many cores ? 09:11
MasterDuke 8 real, 16 virtual 09:15
TEST_JOBS=12 09:16
2nd run wasn't any faster 09:17
Geth nqp: 97bb3018de | (Tom Browder)++ | 11 files
Improve error message for erroneous <.panic()> syntax

Fix for NQP issue GH #632
The issue was triggered by a parser error after a reformat of file
  "src/HLL/sprintf.nqp" in preparation for sprintf changes. Wrapping
line 21 before the last '>' on the line fired an exception with the ... (29 more lines)		 09:45
nqp: ad3ae529ec | (Tom Browder)++ (committed using GitHub Web editor) | 11 files
Merge pull request #636 from tbrowder/parse-error

Improve error message for erroneous <.panic()> syntax
linkable6 NQP#632 [open]: github.com/Raku/nqp/issues/632 Parse error when a '<.panic(' ending '>' is moved to the next line
lizmat MasterDuke: my benchmarking is always a second run, fwiw 09:53
[Tux] Rakudo version 2020.05.1-137-gcb69cfcee - MoarVM version 2020.05-13-g03c9154e8
csv-ip5xs0.828 - 0.840
csv-ip5xs-207.923 - 7.960
csv-parser23.301 - 24.301
csv-test-xs-200.386 - 0.396
test7.287 - 7.299
test-t1.821 - 1.849
test-t --race0.846 - 0.896
test-t-2030.476 - 31.436
test-t-20 --race9.470 - 9.499
 10:24
10:26 sena_kun joined 10:28 Altai-man_ left
nine Funny: depending on some hash order I either get a bogus "Semicolon form of 'perl5class' without 'unit' is illegal (scope is our)." error, or "Serialization Error: missing static code ref for closure '' (gen/moar/World.nqp:3395)" 10:41
10:41 ufobat_ left 10:43 Kaeipi joined, Kaiepi left
[Tux] Do I need anything specific to make "class 🍎 {" a legal statement? 11:21
lizmat a slang, probably 11:22
m: dd "🍎".uniprop # that's unacceptable in identifiers 11:24
camelia "So"
lizmat otoh, perhaps with meta-programming
jnthn You can write `class ::('�') {` I think 11:26
To give it that name 11:27
Though you'll likely need to do similar at teh point of usage
lizmat m: class ::("🍎") { }; dd 🍎.new # indeed
camelia 5===SORRY!5=== Error while compiling <tmp>
Bogus term
at <tmp>:1
------> 3class ::("🍎") { }; dd 7⏏5🍎.new # indeed
expecting any of:
argument list
infix
infix stopper
postfix
…
lizmat I guess changing the .ident token should be enough ? 11:28
or the identifier token, probably
jnthn identifier 11:29
well, or ident I guess
[Tux] I wanted to add raku to a quest in FB, and I thought this would be showing the power of raku
class 🍎 {
method BUILD { say "Hi, I am a 🍎 class" }
method green { say "I support🍏 too" }
}
$a = 🍎.new;
$a.green;
lizmat alas 11:30
notable6: weekly 11:32
notable6 lizmat, 9 notes: gist.github.com/d4bf688fb95500a48d...be889c55a3 11:33
lizmat sena_kun: that was Patrick Böker's work, right ? 11:37
sena_kun lizmat, "that" being?
Azure integration?
lizmat the AzureCI pipeline ?
yes 11:38
sena_kun lizmat, yes.
lizmat oki
sena_kun I think it will be helpful to present it so that core devs wouldn't be too surprised or unpleasantly surprised. 11:39
lizmat yeah, it's going to be the main article :-) 11:40
doesn't AzureCI also make releasing Rakudo easier ?
in that it produces build artefacts ? 11:41
sena_kun lizmat, I don't think so.
lizmat ah, ok
sena_kun lizmat, it mean _possible_ providing of nightly builds for people, but release is Serious Business. 11:42
lizmat ok :-)
sena_kun s/mean/can mean/
11:47 patrickb joined
patrickb lizmat, sena_kun: AzureCI makes it easier for me to create the precompiled binary builds (the ones that can be downloaded on rakudo.org) as now not only MacOS and Linux files can be built on the CI (as was the case with CircleCI), but now also Windows is covered. The work to create the source release is unaffected alas. 11:52
tellable6 hey patrickb, you have a message: gist.github.com/8387e537a9a27ec1fe...3c12af1bd0
sena_kun lizmat, ignore me then, ^ is truth
lizmat :-) 11:54
patrickb Btw. I'm in search of a backup person that can also create the precompiled release files. I tend to not be available every day which often caused a delay of some days of the release of the binaries. 11:55
sena_kun patrickb, if building is automated (or will be), I can discuss doing that next weekend. 11:56
patrickb The work is comprised of triggering the the build on the CI, downloading the results, sanity checking the files (unzip works, archives have a sane size, ...) and uploading to the rakudo.org server. 11:57
sena_kun patrickb, sounds sane, can try doing it myself next release given there are instructions or you around. 11:58
releasable6, status
releasable6 sena_kun, Next release in ≈33 days and ≈7 hours. There are no known blockers. Changelog for this release was not started yet
sena_kun, Details: gist.github.com/863b2ba69a8620707a...eca7d3989c
patrickb It's documented in github.com/rakudo/rakudo/blob/mast...-binary.md
sena_kun patrickb, do I need something special to test out archives? A windows box or something, or gnu/linux one is enough? 12:00
patrickb sena_kun: Depends on how much more manual testing you want to give the packages. 12:01
sena_kun Fair enough...
Ok, will look closer after $dayjob 12:02
patrickb I myself don't have access to a MacOS box, so never manually tested those either.
The files get tested during the creation process. No spec tests though.
lizmat notable6: weekly reset 12:17
notable6 lizmat, Moved existing notes to “weekly_2020-05-18T12:17:00Z”
12:26 Altai-man_ joined 12:28 sena_kun left 12:31 cognominal left 12:33 cognominal joined 12:37 jmerelo left 12:38 cognominal left 12:52 cognominal joined
Geth rakudo: tbrowder self-assigned Handle expanded values for run option "--doc" github.com/rakudo/rakudo/issues/3701
44b270196e | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/MethodContainer.nqp

Spotted by nine++		 12:53
lizmat and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/05/18/2020-...-upgraded/ 13:03
nine lizmat: that for loop doesn't do anything github.com/rakudo/rakudo/blob/mast...er.nqp#L81 13:28
13:35 cognominal left 13:37 cognominal joined
Kaeipi for a while now, my comments on problem-solving have been kinda off the cuff. i'll try and put more careful consideration into things before posting there 13:53
lizmat afk for a few hours& 14:07
14:09 jjatria left, jjatria joined 14:11 jjatria left 14:27 sena_kun joined 14:28 Altai-man_ left 15:15 jmerelo joined
nine lizmat: it wasn't actually superfluous. Before github.com/rakudo/rakudo/commit/1d...5ff10363a7 the hllize was part of the push calls 15:18
It just didn't work the way it was written :) 15:24
16:07 patrickb left 16:26 Altai-man_ joined 16:28 sena_kun left
lizmat nine: the removal was spectest and make test clean... do you have a piece of code that would break because of the removal ? 16:39
nine Custom meta classes are not that well tested unfortunately 16:40
I'm sure I found this when working on Inline::Perl5 and did the fix, but didn't write tests and left workarounds in Inline::Perl5 as I want it to support older rakudos as well :/
Geth nqp/new-disp: db7f2692d2 | (Jonathan Worthington)++ | t/moar/53-dispatch.t
Add tests (only half passing) for boot-constant
 16:45
17:32 jjatria joined 17:40 domidumont left
Geth rakudo: 95f7d34e86 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/MethodContainer.nqp
HLLize method objects correctly

Spotted by nine++		 17:50
17:57 lucasb joined 18:04 brrt joined 18:10 jmerelo left
nine This is odd... after establishing that my 2 possible error messages depend on hash order, I audited all our code (yet again). As that yielded nothing, I simply added a die; to all of Map's iterating methods except for .sort. That tripped several places (most of which harmless for sure, the others probably) 18:10
Fixing all those gave me a working build and program and....it really changed it to always fail in the same way. 18:11
So, now I've just got to find the part of my patch that changed this, right? But when I remove the die; it reverts to giving one of two errors.
Despite all the .sort fixes still being in place 18:12
lizmat is it really a die, or throwing an X::AdHoc? 18:13
there's nqp::bindcurhllsym('P6EX' with a hash of exception mapping ?
nine Just a die; and sometimes a die unless $*ALLOW-ITERATION, so e.g. .sort can actually do something
lizmat perhaps exception throwing somehow uses a hash ? 18:14
18:14 Kaeipi left
nine Btw it's not just the message that's different. I either get a bogus "Semicolon form of 'perl5class' without 'unit' is illegal (scope is our)." error, or "Serialization Error: missing static code ref for closure '' (gen/moar/World.nqp:3395)" 18:14
Including sensible back traces
lizmat reverts to the rubber duck role 18:16
18:17 Kaiepi joined
lizmat sanity check: files written with utf16-le and utf16-be should also have a BOM, right? 18:20
nine thinks so 18:21
lizmat well, it currently doesn't 18:23
I guess it was overlooked when implementing the -le / -be varianrs
variants
18:26 sena_kun joined 18:28 Altai-man_ left
lizmat j: use nqp; dd nqp::backendconfig<be> 18:33
camelia Any
lizmat *sigh*
nine lizmat: why do you need that anyway? 18:36
It would make sense for the JVM to miss that bit. After all hardware abstraction was one of the major selling points of JAva
lizmat to be able to write the correct BOM for utf16-le and utf16-be
nine But how does that depend on the platform endianess? 18:37
lizmat well, "utf16" uses the platform endianness, so I guess I want to be able to correctly write that one, indeed :-)
Geth ¦ problem-solving: lizmat assigned to jnthn Issue Only allow IO::Path.open to create an IO::Handle github.com/Raku/problem-solving/issues/196 19:31
19:37 brrt left
lizmat nine: The standard also allows the byte order to be stated explicitly by specifying UTF-16BE or UTF-16LE as the encoding type. When the byte order is specified explicitly this way, a BOM is specifically not supposed to be prepended to the text, and a U+FEFF at the beginning should be handled as a ZWNBSP character. Most applications ignore a BOM in all cases despite this rule. 20:06
from en.wikipedia.org/wiki/UTF-16 20:07
I guess that's another few hours wasted to learn that :-( 20:09
nine A rather odd feature of the standard if you ask me 20:11
lizmat well, yeah, since you can write a file with "utf16" and then read it with "utf16-le" on most hardware 20:13
so the utf16-le *will* ignore the BOM in that case
vice-versa: writing with utf16-be and then reading with utf16 will *not* see a BOM, and thus read garbage on most hardware 20:14
whereas it *would* have written a BOM, it could have complained 20:15
looks like nqp::decode will throw away any BOM regardless of endianness? 20:19
no, it actually "does the right thing" 20:21
m: dd buf8.new(254,255,0,97,0,98).decode("utf16") 20:22
camelia "ab"
lizmat m: dd buf8.new(254,255,0,97,0,98).decode("utf16be")
camelia "ab"
lizmat m: dd buf8.new(254,255,0,97,0,98).decode("utf16le")
camelia "\x{FFFE}愀戀"
lizmat well, not the right thing in this last case: it should have complained about finding a BE BOM when asked to do a LE decoding
m: dd buf8.new(0,97,0,98).decode("utf16") 20:23
camelia "愀戀"
lizmat aka not doing the right thing 20:24
20:25 Altai-man_ joined 20:28 sena_kun left
lizmat m: dd buf8.new(255,254,0,97,0,98).decode("utf16be") # wrong BOM 20:34
camelia "\x{FFFE}ab"
Geth ¦ problem-solving: lizmat assigned to jnthn Issue Writing BOMs for *all* utf16 encodings github.com/Raku/problem-solving/issues/197 20:42
21:56 raku-bridge2 joined, raku-bridge2 left, raku-bridge2 joined, raku-bridge left 21:57 raku-bridge2 is now known as raku-bridge 22:06 Kaiepi left, Kaiepi joined 22:25 Altai-man_ left 22:55 pochi_ left, pochi joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!