Perl 6 language and compiler development 2.0 | Logs at irclog.perlgeek.de/perl6-dev/today | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by moderator on 28 April 2018.
japhb Zoffix: Does your new numify code still handle arbitrary Unicode digits in the num string? Or does it fall back to the old code for that? 00:01
AlexDaniel El_Che: do you know anything about these failures on alpine? travis-ci.org/perl6/rakudo-pkg-can.../372476216 00:20
japhb Zoffix: Realized that was unclear. I meant "does it handle arbitrary Unicode digits *directly*, or does it fall back?" 00:41
AlexDaniel El_Che: otherwise it looks good, hmm 00:43
BeastieBot: all
BeastieBot [freebsd] Running complete Rakudo build and tests (this will take a while)...
01:00 Zoffix joined
Zoffix japhb: directly: github.com/MoarVM/MoarVM/blob/mast....c#L18-L37 01:00
01:19 Zoffix left
BeastieBot [freebsd] Failed to build Rakudo and run all tests... See the output at fpaste.scsys.co.uk/577333 01:19
01:32 BenGoldberg joined
AlexDaniel BeastieBot: source 01:35
BeastieBot AlexDaniel, github.com/Kaiepi/p6-RakudoBot
01:41 FROGGS_ joined 01:57 ilbot3 joined
moderator Perl 6 language and compiler development 2.0 | Logs at irclog.perlgeek.de/perl6-dev/today | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
02:03 Kaiepi joined
Kaiepi ok the tmp files weren't being removed because i had to kill make while it was running once 02:19
but it still leaves 2 files behind if you let it finish 02:20
testing a fix for it now
06:10 ufobat joined
Geth rakudo: ufobat++ created pull request #1784:
X::NYI uses optional $.feature in method message		 06:25
rakudo: a7c031012c | (Martin Barth)++ (committed using GitHub Web editor) | src/core/Exception.pm6
X::NYI uses optional $.feature in method message

Methods `message` checks wether $.feature is set and returns slightly different error texts. But there are still other exceptions that use variables that might not have been set. I dont know wether some of those variables are ment to have a `is required` on them or not.		 06:36
rakudo: ed740406e8 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/core/Exception.pm6
Merge pull request #1784 from ufobat/patch-1

X::NYI uses optional $.feature in method message
samcv good * everyone 06:49
Geth rakudo: 9e2dacd460 | (Zoffix Znet)++ | src/core/Int.pm6
Make Int.lsb 2x faster
 06:56
rakudo: 775a42eeb8 | (Zoffix Znet)++ | src/core/Int.pm6
Make Int.msb 2x faster
07:45 brrt joined
brrt .tell Zoffix lsb (lowest-set-bit?) can be implemented better by the underlying architecture 07:46
yoleaux brrt: I'll pass your message to Zoffix.
Geth nqp: 6e53dcd811 | (Samantha McVey)++ | 2 files
JVM: Use <surrogate> <private-use> <unassigned> and <reserved> for cp names

This fixes the return for > 0x10FFFF codepoints so it returns
  <unassigned> like it does on MoarVM. It also returns <surrogate-XXXX>
for surrogates instead of the JVM's normal output which is not the same as we now do for MoarVM fitting with the Unicode recommendations.
This also returns <private-use-XXXX> for private use areas. Returns <reserved-XXXX> for codepoints that have don't have a name yet in the Unicode version used by the running JVM.		 09:19
nqp: 635eb7da33 | (Samantha McVey)++ | tools/build/MOAR_REVISION
Bump MoarVM

Changes: 2018.04-36-g28f7fe7..2018.04-37-gae36d60f9 ae36d60f9 Use <private-use-XXXX> and <surrogate-XXXX> for Uni names
nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...gae36d60f9
790f0a6832 | (Samantha McVey)++ | tools/build/MOAR_REVISION

Changes: 2018.04-37-gae36d60f9..2018.04-39-gc702f4c66 c702f4c66 Use strtol instead of strtoll since MSVC doesn't define strtoll b3e7dd36b Make sure getstrfromname will resolve generated names
samcv AlexDaniel: as of the latest NQP changes the unicode names should be correct for the private use, surrogates etc now. on both moarvm and nqp 09:22
and also fixed other things which had previously been fixed a while ago on moarvm but hadn't yet changed on jvm
chansen_ samcv++
samcv like returning <reserved-XXXX> for reserved (JVM used to return <unassigned> which is what we used to do on MoarVM)
well on moarvm we had *both* unassigned and reserved. which had no meanning for the unicode database and was reflected just in the querying of our unicode database 09:23
El_Che AlexDaniel: mm; it looks like it hasn't the fix I added
AlexDaniel: it's the sh -> bash thing
I'll rerun it
samcv but now we return <unassigned> only for ones > 0x10FFFF since literally they are unassigned to unicode
while the other ones are actually reserved 09:24
ugh i'm getting Invocant of method 'path-spec' must be an object instance of type 'CompUnit::Repository::Locally', not a type object of type 'CompUnit::Repository::Staging'. Did you forget a '.new'? 09:26
chansen_ Is somewhat confusing because unassigned is specified by Unicode (complement of DerivedAge.txt) 09:28
samcv chansen_: we could change what we do for > 0x10FFFF if you think that makes sense 09:29
ah Age=Unassigned yeah that exists 09:30
chansen_ I think it would be a good idea to avoid any confusions with Unicodes definition
Brainstorming: <super-XXXX> or <non-unicode-XXXX> 09:31
samcv but similarly unicode hasn't assigned it a name
while for reserved it's <reserved-XXXX> since that's what unicode says you should return. well recomends
you could return something else but they recommend that
and we could do <unassigned-XXXX> but idk if that should be done because it hasn't been assigned. all the <foo-XXXX> ones are actually supposed to have that name for example 09:32
09:36 PufferBot joined 09:37 PufferBot joined
chansen_ <reserved> should be returned for any code point that is unassigned within the Unicode Codespace, the problem with <unassigned> for code points above Unicode is that it's not related with Unicodes definition of unassigned. 09:42
[Tux] Rakudo version 2018.04-29-g775a42eeb - MoarVM version 2018.04-37-gae36d60f9
csv-ip5xs0.871 - 0.873
csv-ip5xs-208.661 - 8.732
csv-parser36.659 - 37.130
csv-test-xs-200.445 - 0.453
test9.268 - 9.397
test-t2.427 - 2.466
test-t --race1.003 - 1.025
test-t-2043.455 - 43.608
test-t-20 --race15.012 - 15.753
 09:47
El_Che AlexDaniel: I need to go out, alpine is still problematic, but that's the sh->bash thing. Will try to fix it later. The only thing relevant for the dot release are the i386 builds
lizmat Files=1239, Tests=76246, 320 wallclock secs (15.93 usr 5.40 sys + 2205.82 cusr 224.15 csys = 2451.30 CPU) 09:49
10:18 Kaiepi joined 10:22 BeastieBot joined
AlexDaniel El_Che: sure 11:38
yoleaux 04:18Z <Tison> AlexDaniel: how can I figure out which libs depend on a special lib? say for URI, Pod::To::HTML depends on URI
11:41 PufferBot joined
AlexDaniel grr toaster segfaulted while I was sleepingā€¦ (that's ok because I'm using some old rakudo version to run it) 11:44
quotable6: 02-qast-rewrites 11:45
quotable6 AlexDaniel, OK, working on it! This may take up to three minutes (4567377 messages to process)
AlexDaniel, gist.github.com/841e29791598b5e033...430fe02ed5 11:46
AlexDaniel quotable6: ā€˜02-qast-rewritesā€™
quotable6 AlexDaniel, OK, working on it! This may take up to three minutes (4567377 messages to process)
AlexDaniel, 4 messages (2018-02-07āŒ2018-02-11): gist.github.com/5ae812da9774ec2d3d...5b29e8c12e 11:47
nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...gc702f4c66
19e936b6f1 | pmurias++ | t/nqp/074-nfa.t
12:18 Kaiepi joined 12:30 Ven`` joined
AlexDaniel quotable6: ā€˜02-qast-rewritesā€™ 12:41
quotable6 AlexDaniel, OK, working on it! This may take up to three minutes (4582161 messages to process)
AlexDaniel, 6 messages (2018-02-07āŒ2018-04-28): gist.github.com/e050b1f7ea6bde3cd9...b6fdfa17cd 12:43
AlexDaniel it just flopped in the pkg canary: travis-ci.org/perl6/rakudo-pkg-can...8411#L3708
looks like it's a fairly new flopper 12:44
13:33 evalable6 joined 13:50 Ven`` joined 14:42 cognominal joined 15:06 stmuk_ joined
AlexDaniel uh, can anybody try installing GTK::Simple on release/2018.04.1+ branch? 15:08
that was working on 2018.03 I'm pretty sure, and it was good right before 2018.04 releaseā€¦ 15:10
Geth rakudo: eac5ae1d50 | (Samantha McVey)++ | tools/build/NQP_REVISION
Bump NQP

Changes: 2018.04-15-g62550f3..2018.04-19-g19e936b6f 19e936b6f Add test for fate ordering during NFA matching 790f0a683 Bump MoarVM 635eb7da3 Bump MoarVM 6e53dcd81 JVM: Use <surrogate> <private-use> <unassigned> and <reserved> for cp names		 15:11
rakudo: version bump brought these changes: github.com/perl6/nqp/compare/2018....g19e936b6f
a1aa1b62a0 | (Samantha McVey)++ | t/09-moar/UnipropCheck.pm6

Make sure private use and surrogates test the correct string.
AlexDaniel that's what I see in toaster, and the result is pretty much identical locally: gist.github.com/AlexDaniel/bbf9451...a3e854f63c
15:57 stmuk joined
stmuk AlexDaniel: just compiling your new release branch 15:59
GTK::Simple worked fine for me on 2018.04
dogbert17 lizmat: are you around? 16:02
.tell lizmat the last two fields in your TimeStruct are in the wrong order 16:03
yoleaux dogbert17: I'll pass your message to lizmat.
dogbert17 the build is still broken, 'Cannot look up attributes in a CompUnit::Repository::Staging type object' 16:10
stmuk AlexDaniel: passes tests on 2018.04-3-gc317d22e7 built on MoarVM version 2018.04-2-g43f9dcfe8 16:11
www.youtube.com/watch?v=ZUV53Nn3PhA 16:36
16:49 Ven`` joined
stmuk like the Star release Blue Origin is on hold :) 16:56
timotimo i don't think i've heard of blue origin yet 16:57
stmuk its Mr Amazon's rocket 17:00
timotimo oh, i see 17:01
AlexDaniel OK, data from toaster looks good 17:03
but that precomp issue is really annoyingā€¦
it flies! 17:07
timotimo it's supposed to land, too?
this is the one that's supposed to transport people from A to B on earth? 17:08
no, that was also Mister Tesla
beautiful 17:14
AlexDaniel \\o/
timotimo no explosion, either
stmuk @D
:D 17:15
timotimo the parachutes look beautiful
hey look they made sure the earth looks curved so the truth about the flat earth doesn't come out! 17:24
El_Che timotimo: what region is the border of a flat earth, I wonder 18:06
timotimo actually, what we call earth is just a circular spot on a gigantic ball that's almost entirely covered in ice 18:07
El_Che so the poles may be the border region
timotimo well, one pole is in the center
El_Che and people that claimed they crossed them liers 18:08
being a flatearther takes a lot of science effort
timotimo yeah, it really does
El_Che like the guy building his own rockets 18:10
timotimo did he have a successful launch yet? 18:12
El_Che he flew
but didn't proof the flat earth thingie
timotimo probably some "scientist" have sabotaged it 18:13
El_Che yeah, those illuminati guys are the worst 18:16
18:20 ufobat joined
lizmat . 19:00
yoleaux 16:03Z <dogbert17> lizmat: the last two fields in your TimeStruct are in the wrong order
lizmat dogbert17: hmmm... my local man localtime says otherwise 19:04
19:14 Kaiepi joined
dogbert17 lizmat: have you tried? 19:22
lizmat yes
dogbert17 so did I and it worked :) 19:23
lizmat great :-(
I guess you're not on MacOS ?
dogbert17 nope 19:24
lizmat I actually found documentation online that swapped the last two indeed
dogbert17 yay 19:25
El_Che lizmat: I installed openbsd and freebsd yesterday so I could check, but their X setup was so painful that I removed them already :)
lizmat hehe
El_Che had instant flashbacks to my first linux installs end 90s 19:26
dogbert17 I also read that the two last fields are not necessarily present on all OS'es. What happens if you remove them?
El_Che and they where waaaaaaaaaay more advanced than 2018 openbsd en freebsd setups :)
lizmat I now get TimeStruct type objects returned
dogbert17: same
El_Che does multi work in such case? guess not 19:27
lizmat dogbert17: gist.github.com/lizmat/61cd573e2a0...379a9fd7af # gives me Cannot look up attributes in a TimeStruct type object 19:28
timotimo so it returned null?
lizmat No, a TimeStruct type object 19:29
timotimo yeah, a null pointer on the C side
FROGGS_ lizmat: your example works on my ubuntu box 19:30
lizmat the fact that localtime() returns a pointer to the struct, shouldn't matter, right ?
FROGGS_: thanks for trying
FROGGS_ no, actually the printed value makes no sense... 19:31
lizmat ah, that's something :-)
FROGGS_ lizmat: C functions usually return pointers to structures, and your code fits that 19:32
lizmat well, at least it doesn't segfault anymore 19:33
FROGGS_ I bet the problem is about time_t 19:34
hmmm, time_t should probably be an int64 on my box 19:36
lizmat hmmm
FROGGS_ but even then, I did set the $epoch to a literal value, but the tm_sec changes on every program run 19:37
lizmat with int64 is rw as time_t * it segfaults for mew 19:38
*me
aaaaaa
lose the last two elements in the struct *and* use int64 and it works for me 19:39
FROGGS_ confirmed 19:41
I forgot to adjust the parameter too -.-
lizmat and if I add the last two fields in the order dogbert17 suggested, it now completely works 19:42
whee!
FROGGS_ and the output looks quite valid as well: TimeStruct.new(tm_sec => 24, tm_min => 42, tm_hour => 21, tm_mday => 29, tm_mon => 3, tm_year => 118, tm_wday => 0, tm_yday => 118, tm_isdst => 1)
(for my timezone) 19:43
dogbert17 this localtime question uncovers a problem unless I've missed something. On 32 bit the fields in TimeStruct should e.g. int32 but on a 64 bit system they should probably be int64. 19:56
so how should the code be written so that it works on both 32- and 64-bit systems?
lizmat indeed :-( 20:04
however, in this case, I think only the time_t pointer differs in size 20:05
dogbert17: you have access to a 32bit machine, right? what does 'say $?BITS' say there ? 20:07
dogbert17 it says 64 unfortunately 20:16
lizmat grrr... :-) 20:17
dogbert17 bug?
lizmat and int.Range ?
dogbert17 -9223372036854775808..9223372036854775807
lizmat also 64bit 20:18
hmmm...
dogbert17 dogbert@dogbert-VirtualBox ~ $ perl6 -V | grep 32
kernel::bits=32
lizmat and this: 20:19
m: my int $a = 0xffffffff; say $a; $a++; say $a
camelia 4294967295
4294967296
dogbert17 I get the same result as Camelia 20:20
dogbert@dogbert-VirtualBox ~ $ uname -a 20:26
Linux dogbert-VirtualBox 3.19.0-32-generic #37~14.04.1-Ubuntu SMP Thu Oct 22 09:37:25 UTC 2015 i686 athlon i686 GNU/Linux
AlexDaniel is back 20:39
20:39 dct joined 20:47 Kaiepi joined
AlexDaniel I guess we should go ahead and cut the point release 20:48
precomp issue will be in, unfortunately, but that's probably not a big deal 20:49
depends reallyā€¦
lizmat I think it's mainly an issue for developers
but then again, Rakudo * *is* for developers :-(
AlexDaniel samcv: you there? :) 20:50
lizmat FWIW, I'm being bit by it at this moment again :-(
make install: Invocant of method 'path-spec' must be an object instance of type 'CompUnit::Repository::Locally', not a type object of type 'CompUnit::Repository::Staging'. Did you forget a '.new'?
in block <unit> at tools/build/install-core-dist.pl line 17
AlexDaniel yeah it's annoying AF
lizmat do we have a fix when it is in this state ? 20:51
AlexDaniel yeah, just purge your .precomp directory?
El_Che AlexDaniel: I disabled alpine from the canary for now. I tried 17 variation on starting the compile script, but no luck
AlexDaniel El_Che: ok, thank you for your effort
El_Che it worked interactively though 20:52
weird
AlexDaniel BTW this time at least we tested the prerelease on i386, so that's some progress :)
El_Che I'll fix it when I have more time, but it will suffice for now :)
AlexDaniel El_Che++
El_Che funny thing I never hit the bug with rakudo-pkg because I was building nqp, moarvm and rakudo separate 20:53
bbl
20:58 Zoffix joined
Zoffix "try installing GTK::Simple" That was a bug in the module exposed by new zef. Fixed 4 hours ago: github.com/perl6/gtk-simple/commit...9b446ed4db 20:59
And workaround for the precomp bug: `rm -fr **/.precomp`
AlexDaniel oh 21:00
thanks for letting me know
I feel better now :)
FROGGS_ dogbert: about int32 vs int64 in timestruct... cant we use size_t as an alias to time_t? 21:04
dogbert17: ^^
Zoffix echo "alias nukeprecomp='rm -fr **/.recomp'" >> ~/.bash_aliases # save yourself the grief from typing `rm -fr */<ACCIDENTAL ENTER>` :)
21:14 Zoffix left
dogbert17 FROGGS: does that mean that size_t is 32 bit on a 32 bit system and 64 on a 64 bit one? 21:14
ilmari FROGGS_: I'm pretty sure that will break on x32 21:23
I'm pretty sure it has 64bit time_t and 32bit size_t 21:24
Geth rakudo: 0de80523c5 | (Elizabeth Mattijsen)++ | src/core/Exception.pm6
Fixish for GH R#1747
 21:28
synopsebot R#1747 [open]: github.com/rakudo/rakudo/issues/1747 [LHF][LTA] X::TypeCheck::Argument could use a minor wording tweak
ilmari FROGGS_: confirmed by cross-compiling printf("size_t: %zd\\ntime_t: %zd\\n", sizeof(size_t), sizeof(time_t)); using x86_64-linux-gnux32-gcc-7 21:48
size_t: 4, time_t: 8 21:49
FROGGS_ :/
so, best would be to check time_t at moarvm build time
lizmat FROGGS_: but isn't that just the size of "int" in Perl 6 ? 21:59
FROGGS_ I'm not sure 22:00
lizmat well, atm using "int" gives a warning
In 'get-localtime' routine declaration - Not an accepted NativeCall type for parameter [1] : int
still works, though
ilmari int is 32 bits on x32 22:08
timotimo C int yes, perl6 int no 22:09
but you probably know that
22:40 Kaiepi 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!