Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
00:09 lizmat_ joined 00:12 lizmat left 02:31 vrurg joined 04:45 lizmat_ is now known as lizmat
lizmat is this a known issue on HEAD? 04:56
$ perl6 -e 'use Inline::Perl5'
===SORRY!===
Cannot unbox a type object (int64) to int.
04:57 vrurg left 05:23 lizmat left 05:54 lizmat joined
MasterDuke lizmat: oh, i didn't have Inline::Perl5 installed, that's probably because of my default-int merges 05:58
lizmat which is post-release, right ?
MasterDuke yeah 05:59
06:00 [TuxCM] left 06:01 brrt joined 06:11 lizmat left 06:17 krunen left, krunen joined 06:38 lizmat joined
lizmat hopes MasterDuke will be able to fix Inline::Perl5 soon 06:45
MasterDuke lizmat: making progress 06:50
lizmat MasterDuke++
fwiw, this also affects zef, at least for me: 06:52
$ zef upgrade
===SORRY!===
Cannot unbox a type object (NQPMu) to int.
MasterDuke yep, saw that too
lizmat ok :-)
06:53 patrickb joined
lizmat MasterDuke: do you have any rollback suggestions at this time ? 06:53
MasterDuke ? 06:54
if you rollback to right before the nqp bump it should be fine
Kaiepi .tell timotimo can we talk about whether or not i need to rebootstrap nqp for my nativecall wide string support pullreq again? i ran into an issue that may require it
yoleaux Kaiepi: I'll pass your message to timotimo.
lizmat git checkout d4ceb97e06cd01babdd34356140 and a reconfigure, does not even build :-( 06:56
MasterDuke lizmat: using --gen-nqp ? 06:59
lizmat perl Configure.pl --gen-moar --gen-nqp --make-install
to be exact
I actually nuked the nqp dir, but it didn't refetch not recompile it 07:00
guess I need to nuke more
MasterDuke the install directory probably
is there a way to pass --ll-exception through all the calls zef makes? 07:01
if not, definitely ++ to ugexe's suggestion of a LL_EXCEPTIONS env variable 07:02
lizmat I think you can call zef as "perl6 --ll-exception .../zef ?
MasterDuke yep, but it doesn't pass that through
===> Testing: Inline::Perl5:ver<0.40>:auth<github:niner>===SORRY!===Cannot unbox a type object (int64) to int. in block <unit> at t/argv.t line 8 07:03
lizmat well, I have Inline::Perl5 already installed
and I can give you a trace of 'use Inline::Perl5
?
MasterDuke please
lizmat gist.github.com/lizmat/83476091b86...05bab53986 07:04
lizmat hopes that is helpful 07:11
MasterDuke got farther, but new error 07:12
==> Testing: Inline::Perl5:ver<0.40>:auth<github:niner>This type cannot unbox to a native number: P6opaque, Int===SORRY!===Serialization Error: missing static code ref for closure '' (core#sources/947BDAB9F96E0E5FCCB383124F923A6BF6F8D76B (NativeCall):531) in block <unit> at t/argv.t line 8This type cannot unbox to a native number: P6opaque, Int 07:13
unfortunately, i gotta afk for a bit
lizmat MasterDuke: ok, I'm nuking all of my install and rebuild from before the NQP bump 07:18
annoying, but that's life on the edge :-)
07:19 [TuxCM] joined 07:43 brrt left 07:54 lizmat_ joined 07:57 lizmat left
patrickb .tell ugexe Putting a space in the appveyor build path sounds good! But note that non-Windows currently does not work in a path with spaces (the dyncall build currently doesn't support that on Linux). 08:07
yoleaux patrickb: I'll pass your message to ugexe.
patrickb .tell ugexe On a related note. There are many different build setups that we support and don't want to break, but that do break time and time again. (Windows: cl/mingw/clang, 1/3 prefixes, non-reloc/reloc, Linux: gcc/clang, 1/3 prefixes, non-reloc/reloc) 08:08
yoleaux patrickb: I'll pass your message to ugexe.
patrickb .tell ugexe I do like to have a way to automatically test all of these when making changes to the build system. But I don't like inflating the CI. Do you know whether it's possible to have travis/appveyor/circleci jobs that don't run automatically, but can be triggered?
yoleaux patrickb: I'll pass your message to ugexe.
patrickb .tell ugexe Also, do you intend to get rid of Travis, now that we have CircleCI up and running? 08:09
yoleaux patrickb: I'll pass your message to ugexe.
08:15 lizmat_ is now known as lizmat
Kaiepi so i'm starting my work on the changes to CStr's REPR needed for wide string support 09:04
should i add a variable to storage specs containing the native type of whatever they contain or should it stay separate? 09:05
since P6int and P6num already have native type variables in their state as well
MasterDuke nine: ping 09:49
lizmat: think it's fixed. just running a spectest to make sure it didn't cause any other regressions 10:09
10:27 brrt joined
Geth rakudo: cf6f6d926f | (Daniel Green)++ | 3 files
Default-int fixes for zef and Inline::Perl5
 10:30
MasterDuke lizmat: can you pull and try at current HEAD?
Kaiepi .tell timotimo never mind, i didn't end up needing to rebootstrap after all 10:55
yoleaux Kaiepi: I'll pass your message to timotimo.
[TuxCM] Rakudo version 2019.03.1-672-g669a3b9f3 - MoarVM version 2019.05-99-g729303de7
csv-parser33.645 - 34.349
csv-test-xs-200.426 - 0.432
test-t1.701 - 1.735
test-t --race0.787 - 0.858
test-t-2027.922 - 28.614
test-t-20 --race8.975 - 10.169
 11:03
BUT
===SORRY!===
Cannot unbox a type object (int64) to int.
.===SORRY!===
Cannot unbox a type object (int64) to int.
.===SORRY!===
Cannot unbox a type object (int64) to int.
.===SORRY!===
Cannot unbox a type object (int64) to int.
.===SORRY!===
Cannot unbox a type object (NQPMu) to int. 11:04
.===SORRY!===
Cannot unbox a type object (NQPMu) to int.
Those are new
11:08 squashable6 left 11:10 brrt left, reportable6 left, shareable6 left, greppable6 left, committable6 left 11:11 greppable6 joined, squashable6 joined, ChanServ sets mode: +v squashable6 11:12 reportable6 joined, ChanServ sets mode: +v reportable6, committable6 joined, ChanServ sets mode: +v committable6 11:14 shareable6 joined, ChanServ sets mode: +v shareable6
MasterDuke [TuxCM]: those are hopefully fixed on the very next commit after the one you're at. mind pulling and trying again? 11:15
[TuxCM] rrrrrunnnnninggggg 11:16
MasterDuke thanks 11:17
11:54 brrt joined 11:57 brrt` joined 11:59 brrt left
[TuxCM] Rakudo version 2019.03.1-673-gcf6f6d926 - MoarVM version 2019.05-99-g729303de7
csv-ip5xs0.684 - 0.694
csv-ip5xs-205.259 - 5.299
csv-parser33.031 - 33.629
csv-test-xs-200.431 - 0.436
test7.387 - 7.414
test-t1.707 - 1.708
test-t --race0.791 - 0.815
test-t-2028.206 - 28.660
test-t-20 --race8.801 - 8.990
 12:37
(and it was clean)
MasterDuke glad to hear it 12:40
masak MasterDuke: it strikes me that the issue cf6fd926 fixes could have been detected statically. I feel strangely inclined to put together something that would check for that, maybe as early as tonight. what's your opinion? 12:41
MasterDuke masak: that seems possible. i was just concerned with getting the bugs fixed (and getting something merged at all) 12:47
i'd be very curious to see what you come up with
masak hey, no criticism implied at all -- great work on fixing the direct problem! :+1: 12:49
I'm thinking a quick-and-dirty approach might use Perl 5, regexes, and Text::Balanced 12:50
a longer-term fix could maybe hook into the AST stage of the nqp compiler
MasterDuke no worries, didn't think that was criticism 12:54
13:01 brrt` left, brrt` joined
masak it's just that I've gotten attuned lately to issues of the type "this could have been prevented by a machine that can double-check the code on a structural level" 13:04
linting-ish stuff
13:29 brrt` left 13:32 vrurg joined
AlexDaniel Geth: ver github.com/rakudo/rakudo/commit/f077f57c 13:45
Geth AlexDaniel, version bump brought in these changes: github.com/perl6/nqp/compare/2019....g25114a3f1
nine MasterDuke: pong 14:07
yoleaux 28 Jun 2019 23:50Z <patrickb83> nine: I'd appreciate a look: colabti.org/irclogger/irclogger_lo...06-28#l257
AlexDaniel Geth: ver github.com/rakudo/rakudo/commit/f077f57c 14:12
Geth AlexDaniel, version bump brought in these changes: github.com/perl6/nqp/compare/2019....g25114a3f1
nqp: Kaiepi++ created pull request #562:
Add a note about the JVM and ulimit to the README		 15:02
patrickb vrurg: Ping 15:14
15:37 patrickb left
Kaiepi when should REPRs have a storage spec? 15:41
15:48 [TuxCM] left
MasterDuke nine: sorry, think i solved it (problem with inline::perl6 and my default-int merge) 16:16
nine MasterDuke: all the better :) 16:17
16:23 llfourn joined
MasterDuke heh, i've gotten used to typing a 6, that was supposed to be inline::perl5 16:28
17:06 vrurg left 17:21 vrurg joined 18:03 lizmat left 18:07 vrurg left 18:39 vrurg joined 18:43 brrt` joined 18:51 lucasb joined 19:16 [TuxCM] joined
vrurg m: my $*AAA; { my $*BBB; for DYNAMIC::.keys { say $sym, " dyn? ", ( try { DYNAMIC::{$sym}.VAR.dynamic } || "NO" ) } }' 19:16
yoleaux 4 Jul 2019 22:12Z <patrickb> vrurg: I'd be grateful for testing on MacOS of these branches. There are changes and respective PRs in MoarVM, nqp-configure, nqp and rakudo. All necessary to get it to work.
camelia 5===SORRY!5=== Error while compiling <tmp>
Variable '$sym' is not declared
at <tmp>:1
------> 3A; { my $*BBB; for DYNAMIC::.keys { say 7ā5$sym, " dyn? ", ( try { DYNAMIC::{$sym}.
yoleaux 4 Jul 2019 22:13Z <patrickb> vrurg: No hurry, this is for post release anyways.
19:35 patrickb joined 19:37 vrurg left 19:50 vrurg joined
vrurg m: my $*AAA; { my $*BBB; for DYNAMIC::.keys { say $_, " is dynamic? ", try { DYNAMIC::{$_}.VAR.dynamic } || "No" } } 19:56
camelia $_ is dynamic? No
$*DISPATCHER is dynamic? No
$*BBB is dynamic? True
vrurg Isn't it supposed to have $*AAA in the output? 19:57
my $*AAA; { my $*BBB; my $bbb; for DYNAMIC::.keys { say $_, " is dynamic? ", try { DYNAMIC::{$_}.VAR.dynamic } || "No" } }
evalable6 $bbb is dynamic? No
$_ is dynamic? No
$*BBB is dynamic? True
$*DISPATCHER is dynamic? No
vrurg And I wouldn't expect $_ and $bbb in the list. 19:58
20:22 brrt` is now known as brrt 20:41 lizmat joined 21:10 brrt left 21:12 b2gills joined 21:13 Kaiepi left 21:24 Kaiepi joined
Kaiepi i asked before, but what are storage specs used for with reprs? would it be a good idea to add a variable stating the type of what's being stored to it? 21:28
timotimo storage spec is for a lower-level thing than types are 21:29
a storage spec will, for example, allow P6opaque to inline a native int inside of its parent object
so that a class with has int8 $.foo; int8 $.bar; int8 $.baz; int8 $.bloop; will actually only use 4 bytes for that piece of data 21:30
Kaiepi ohh
neat
timotimo almost everything that "holds a type" will have a reference, though 21:31
Kaiepi why do P6int and P6num copy members between their repr data and the storage spec though?
on moar at least 21:32
timotimo not sure what you are refering to; do you have a link? 21:33
Kaiepi my dns is shitting itself, check mk_storage_spec and type_object_for in src/6model/reprs/P6int.c 21:35
nvm fpaste.scsys.co.uk/585208 21:36
timotimo i'm looking at it locally 21:37
that's less "what does it store", that's more of "what am i"
Kaiepi so it specifies what's getting inlined? 21:39
timotimo every ST has a WHAT in it 21:41
you can get from a type object to the STable and from the STable to its type object
Kaiepi STABLE(typeobj), st->WHAT right? 21:45
last question, does CStr need a storage spec in its REPR data when i'm storing a type, number of bits, and its sign in it? 21:48
timotimo yep, though STABLE goes with every object 21:50
storage spec is for the other types to use, whereas the repr data is for the type itself to use 21:51
the storage spec is basically a unified API that is the same across all 6model objects
whereas the REPR_data can be freely defined by the type using it
Kaiepi so it sounds like no since afaik strings can't be inlined in REPRs like CStruct/CPPStruct/CUnion 21:57
timotimo we do have support for CArray inlined in CStruct/CPPStruct at least 21:58
but strings have even less theoretical support for a specified length
Kaiepi making that possible sounds out of the scope of what i'm doing 22:03
22:05 squashable6 left, squashable6 joined
timotimo aye 22:07
i'm still not sure i understand how the inlining of arrays inside of structs actually worked
22:10 lucasb left 22:12 vrurg left, epony left 22:14 vrurg joined 22:34 epony joined 22:36 patrickb left
vrurg Anyboudy with good understanding what is supposed to be visible in pseudo-packages? 22:50

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!