Geth_ ¦ problem-solving: vrurg assigned to jnthn Issue Loading of custom setting logic is undefined github.com/Raku/problem-solving/issues/213 00:20
00:27 oddp_ left 01:12 Altai-man_ joined 01:15 sena_kun left 03:12 sena_kun joined 03:14 Altai-man_ left 05:12 Altai-man_ joined 05:14 sena_kun left
releasable6 Next release in ≈2 days and ≈11 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 07:00
07:12 sena_kun joined 07:14 Altai-man_ left 08:33 oddp_ joined 08:37 sena_kun left 08:44 sena_kun joined 09:12 Altai-man_ joined 09:14 sena_kun left 10:57 sena_kun joined 10:58 sena_kun left 11:12 sena_kun joined 11:14 Altai-man_ left 11:29 sena_kun1 joined, sena_kun1 left
lizmat Files=1307, Tests=113021, 220 wallclock secs (29.08 usr 8.25 sys + 3072.61 cusr 294.50 csys = 3404.44 CPU) 11:38
11:43 sena_kun1 joined, sena_kun1 left 13:12 Altai-man_ joined 13:14 sena_kun left 14:55 Geth_ left, maggotbrain777 left, nebuchadnezzar left, JJMerelo joined
JJMerelo releasable6: status 14:56
releasable6 JJMerelo, Next release in ≈2 days and ≈4 hours. There are no known blockers. Changelog for this release was not started yet
JJMerelo, Details: gist.github.com/4b61b4158bf0529f9a...b88025bb53
14:57 Geth_ joined, maggotbrain777 joined, nebuchadnezzar joined
JJMerelo raiph has put a (StackOverflow) bounty on this question stackoverflow.com/questions/tagged...b=Bounties 14:59
Also, these questions in StackOverflow still have no answer stackoverflow.com/questions/tagged...Unanswered
15:13 sena_kun joined 15:14 Altai-man_ left
JJMerelo So, what do you think this means? "Defined .Numeric/.Real on type objects of core Numerics" 15:18
It's one of the last 6.d specs to include in the documentation
m: say Rat.Numeric
camelia Use of uninitialized value of type Rat in numeric context
0
in block <unit> at <tmp> line 1
JJMerelo I guess it means exactly that: it's defined, only it throws a warning.
m: say Str.Numeric 15:19
camelia Use of uninitialized value of type Str in numeric context
0
in block <unit> at <tmp> line 1
JJMerelo Or maybe not.
[Coke] m: say Str.not-a-method
camelia No such method 'not-a-method' for invocant of type 'Str'
in block <unit> at <tmp> line 1
JJMerelo m: say Mu.Real 15:20
camelia Use of uninitialized value of type Mu in numeric context
0
in block <unit> at <tmp> line 1
JJMerelo m: say Junction.Real
camelia Use of uninitialized value of type Junction in numeric context
0
in block <unit> at <tmp> line 1
JJMerelo m: say +Int 15:21
camelia Use of uninitialized value of type Int in numeric context
0
in block <unit> at <tmp> line 1
JJMerelo m: say +Any
camelia Use of uninitialized value of type Any in numeric context
0
in block <unit> at <tmp> line 1
JJMerelo So maybe it was defined everywhere but there and then it was defined for core Numerics? 15:22
committable6: say +Int
committable6 JJMerelo, Seems like you forgot to specify a revision (will use “v6.c” instead of “say”)
JJMerelo, gist.github.com/4167e94a708f4f62d0...019088a3da 15:23
JJMerelo It's pretty much the same all over. 15:24
Besides, the spec seems to indicate otherwise 15:25
16:33 JJMerelo left 16:49 patrickb joined
patrickb o/ 16:50
tellable6 2020-07-15T21:03:15Z #raku-dev <rba> patrickb: Sorry my temporary fix was in the way. Now auto-update for rakudo.org should work again.
patrickb rba: Looking very good now. Thanks for your work!
I need some insight when the Compiler objects are initialized during bootup. 16:52
[Coke] rba++
patrickb It seems that on first use of the ModuleLoader `nqp::getcomp('Raku')` returns a valid object, while `nqp::getcomp('nqp')` does not...
I want to do that because I stuffed a method `nqp-home()` into the NQP compiler object that I want to call in the Raku ModuleLoader. 16:54
But that seems to be a null object at that point of boot up... 16:55
Is it possible the NQP Compiler object simply isn't constructed and registered in Rakudo? 17:01
timotimo actually, quite likely now that you mention it 17:02
patrickb Then I need a better place to put my nqp-home and rakudo-home logic.
Open for suggestions
timotimo would HLL::Compiler be bad? 17:03
patrickb That's language independent
kind of wrong to put a `rakudo-home()` and `nqp-home()` method in there
hm... rakudo-home() could actually go into Perl6::Compiler()
still isn't nqp-home() misplaced in the generic HLL::Compiler()? 17:04
timotimo i mean, at the moment we don't really have any other "serious" consumers of HLL::Compiler that would be upset
OTOH 17:05
it can go into the compiler backend objects?
hm perhaps that's even worse
patrickb well I'm not worried about some code breaking, more about not being clean
timotimo yeah, it can't really break code, just be stuff that's not needed in other implementations/users 17:07
patrickb True. But then again every user of HLL::Compiler somehow will be based on NQP. So it's not that far off to assume it'll be interested in nqp-home as well 17:08
it just doesn't make much sense from a logical point of view.
timotimo that may well just be a sacrifice we'd be willing to make 17:09
patrickb tries
looking through the methods in HLL::Compiler my nqp-home() isn't in such a bad company after all! 17:11
17:12 Altai-man_ joined 17:15 sena_kun left
patrickb Seems to be working. Thanks timotimo for thinking this through. 17:18
17:26 sena_kun joined 17:55 patrickb left
timotimo hmmm 18:15
nqp::conditionalcompile :D
just don't iterate its children in optimizer and compiler if whatever predicate doesn't evaluate to true 18:16
any reason not to bump moar and nqp to get "nqp::setthreadname"? 18:34
(passes on a thread's $!name to the OS, at least on linux) 18:35
actually, i'll steal the namelen constant from the pthread man page 18:37
disgusting.
now i get to chop the string's length to 15 unicode bytes 18:39
lizmat bump feels ok to me, if Altai-man_ would run a Blin tonight? 18:48
18:52 patrickb joined
patrickb o/ 18:53
in NQP code there are no submethods, right? So when a subclass defines its own `method BUILD()` is there anything to look out for? 18:54
Like needing to call the parent BUILD() or some such?
18:58 sena_kun left
Geth_ roast: 61146945c2 | (Christian Bartolomäus)++ | 2 files
Add more tests for gather/take

All of these tests are dying with an UnwindException on the JVM backend currently, but they are passing on MoarVM.		 18:59
roast: 8412333799 | (Christian Bartolomäus)++ | 2 files
Run tests on JVM, but use skip and canary test
18:59 AlexDaniel joined
roast: e4e5319f6d | (Vadim Belman)++ (committed using GitHub Web editor) | 2 files
Merge pull request #652 from usev6/gather_tests

Add more tests for gather/take
18:59 AlexDaniel left, AlexDaniel joined 19:11 [TuxCM] joined 19:12 sena_kun joined 19:14 Altai-man_ left 19:37 sivoais_ joined, sivoais left, japhb left, japhb joined
sena_kun timotimo, lizmat can bump, I'll run blin tonight. 19:52
timotimo gimme a few more minutes :) 20:05
OK, i think these changes are wrapped up nicely 20:22
Geth_ nqp: 275e55752f | (Patrick Böker)++ | 4 files
Fix retrieving template.html location

Now that NQP and Rakudo are relocatable we must not rely on a build time path. NQP home is meant to always point to the actual runtime path. For this purpose introduce the home-dir() method on the Compiler object which will determine the current NQP home directory at runtime. This is analogous to a feature Rakudo also has (Rakudo home).
On JVM the necessary vm command line argument needed to enable the VM to know the scripts executable path was not set. Do so now.		 20:27
nqp: 3c3ccd757b | (Patrick Böker)++ | tools/templates/jvm/nqp-j.in
Quote command line arguments on *nix on JVM

This fixes #644.
linkable6 NQP#644 [closed]: github.com/Raku/nqp/issues/644 [JVM][regression] [JVM] nqp-j broken (at least on non-Windows systems)
nqp: 3e5403f161 | (Patrick Böker)++ (committed using GitHub Web editor) | 4 files
Merge pull request #645 from patrickbkr/fix-profile-with-reloc-build

Fix retrieving template.html location. Also add a mechanism to retrieve the nqp-home path.
ShimmerFairy patrickb: to answer your question from earlier, you can look at QAST nodes as an example, which require setter methods for each attribute, and then has a 'set' method in QAST::Node that takes pairs of "method_name" => value which constructors of subclasses call at some point.
patrickb ShimmerFairy: Interesting! Thanks for the hint! I ended up not needing it in this particular case though. 20:30
ShimmerFairy (I should say "for each attribute that wants to be set through a new()", to be more precise) 20:31
bartolin patrickb++
sena_kun Hmm, no bumps? 20:48
Geth_ rakudo: 1b3780f725 | (Patrick Böker)++ | tools/templates/NQP_REVISION
Bump NQP for nqp-home functionality

This is required for an upcoming cleanup of the same functionality in Rakudo.		 21:02
rakudo: e4f020caba | (Patrick Böker)++ | 6 files
Refactor `Rakudo home` and `NQP home` handling

It is now not set as an HLL symbol anymore, but instead can be retrieved via a method on the Compiler object. This deduplicates the logic previously present in both, src/main.nqp and src/rakudo-debug.nqp.
Also NQP now determines and provides the `NQP home` itself in its Compiler object so we don't need to redetermine it in rakudo.
rakudo: 37d58315d6 | (Patrick Böker)++ (committed using GitHub Web editor) | 7 files
Merge pull request #3793 from patrickbkr/fix-profile-with-reloc-build

Refactor rakudo-home and nqp-home handling
sena_kun Thank you! 21:04
lizmat hmmm... build is broken for me 21:05
Missing or wrong version of dependency 'gen/moar/stage2/NQPHLL.nqp' (from 'gen/moar/BOOTSTRAP/v6c.nqp')
patrickb: do I need to nuke something? 21:06
sena_kun tries to build
can confirm 21:07
lizmat which means /me stops hacking today 21:09
21:12 Altai-man_ joined
[TuxCM] Rakudo version 2020.06-72-g85320f466 - MoarVM version 2020.06-29-g953bac6ca
csv-ip5xs0.814 - 0.832
csv-ip5xs-208.038 - 8.087
csv-parser24.827 - 25.435
csv-test-xs-200.386 - 0.386
test7.975 - 8.303
test-t1.841 - 1.873
test-t --race0.813 - 0.820
test-t-2029.424 - 31.640
test-t-20 --race8.968 - 9.059
 21:12
21:14 sena_kun left
patrickb Argh! 21:17
sena_kun: I'm totally stumped on this one! This builds fine locally and all the tests are green. No idea why nuking should be necessary, but did you try that? 21:24
tellable6 patrickb, I'll pass your message to sena_kun
patrickb lizmat: Sorry for the breakage! Rakudo builds fine in a `make realclean`ed rakudo on my machine. Did you try cleaning out nqp? 21:33
Altai-man_ Can confirm it builds after a purge. 21:35
patrickb Phew. 21:36
Does this mean everything is fine or is there still something that needs to be fixed? 21:37
Altai-man_ Well, such breakage is not desired for sure, I think. 21:39
OTOH with amount of issues we have this is probably not the worst of them.
patrickb But has this anything to do with my changes or is this an unrelated issue that just got triggered? 21:41
lizmat so, what needs to be done where ?
Altai-man_ make realclean and then build again? 21:42
lizmat Altai-man_: in which dir?
Altai-man_ lizmat, rakudo?
lizmat still have the issue after a "make realclean" :-( 21:43
Altai-man_ :S
Well, I just rm -rf for the whole directory and did `z init R; z z`, so.
patrickb lizmat did you try in nqp?
lizmat decides to nuke install and re-install all modules she had installed later 21:44
*sigh* 22:02
$ zef install Inline::Perl5
===> Searching for: Inline::Perl5
===> Searching for missing dependencies: perl:from<native>, Distribution::Builder::MakeFromJSON:ver<0.6+>
===> Failed to find dependencies: perl:from<native>
Failed to resolve some missing dependencies
latest version of zef :-( 22:03
timotimo huh 22:07
lizmat github.com/ugexe/zef/issues/364 22:12
Altai-man_ lizmat, do you have perl-devel package? I assume you have, but I just installed all that 20 minutes ago and it was ok. 22:14
Or perl-dev, whatever is it called which gives a native library. 22:15
lizmat which perl-devel package are you talking about?
It *used* to work, now it doesn't?
Altai-man_ Oh, then you have it.
ugexe it only used to work because of a rakudo regression that stopped that dependency check from working
lizmat well, latest zef doesn't install Inline::Perl5 with latest Rakudo 22:16
ugexe presumably is native(libperl.so) doesn't work on your system
lizmat guess I'm the only one on MacOS then
ugexe i am on osx 22:17
inline::perl5 installs for me
lizmat it installs for me with 0.8.4, it does *not* install for me with 0.8.5 22:19
I've uninstalled zef, git checkout on the 0.8.4 version, then let zef install itself again, then install Inline::Perl5 fine 22:20
ugexe yes, because it is doing a dependency check using code that rakudo had a regression in. thus the check just doesnt happen
v0.8.5 does not use that regressed rakudo code, so the check occurs
lizmat if I understand this correctly: 22:21
so it does the check, which gives a negative, so it fails 22:22
ugexe you can --exclude=perl to avoid checking for that dependency
lizmat in the old code, the check was not done, but the install then works fine?
feels to me the check code is broken then
ugexe NativeCall is broken then
lizmat well, if NativeCalll is borked, it doesn't show in any "make test" or "make spectest" as these are both clean 22:24
ugexe then how do i check if a native dependency is available using nativecall that works?
because i obviously have to write code that does e.g. `is native(...)` 22:25
lizmat I have no idea, I'm just the messenger who goes to bed& 22:26
22:29 patrickb left
ugexe raku -e 'use NativeCall; sub foo is native($*VM.platform-library-name("perl".IO)) { }; foo()' 22:29
this is essentially the check
lizmat $ raku -e 'use NativeCall; sub foo is native($*VM.platform-library-name("perl".IO)) { }; foo()'
Cannot locate native library '/Users/liz/Github/rakudo.moar/libperl.dylib': dlopen(/Users/liz/Github/rakudo.moar/libperl.dylib, 10): image not found
looks to me it's looking in the wrong place 22:30
ugexe right, which means NativeCall doesn't find your libperl.dylib that does probably exist onyour system
lizmat it's basically looking at ./libperl.dylib
that can't be right ?
timotimo maybe we need to do stuff like on windows 22:31
where you don't have to be in any particular folder
you can always just "open('COM')" and get the COM port
lizmat perl -v tells me it is 5.28 22:32
but I don't appear to have a libperl.dylib for that version 22:33
22:34 leont left, leont joined
lizmat yet, "use Inline::Perl5; { use v5-inline; print $] }" gives me 5.028000 22:35
ok, that's it, I've had enough for today&
ugexe perl6 -e 'use NativeCall; sub foo is native($*VM.platform-library-name("perl".IO).basename) { }; foo()'
i was missing that .basename on there
that gets rid of the cwd path parts
you could probably `locate libperl.dylib` and then set it in LD_LIBRARY_PATH=. No clue what Inline::Perl5 code is doing to find the library without that 22:45
Geth_ rakudo/rakuast: 210db5868b | (Jonathan Worthington)++ | 5 files
RakuAST for race/hyper/lazy/eager
23:12 sena_kun joined 23:15 Altai-man_ left 23:16 Geth_ left, maggotbrain777 left, nebuchadnezzar left 23:23 Geth_ joined, maggotbrain777 joined, nebuchadnezzar joined 23:40 sena_kun left

Powered by Cro and the Raku® Programming Language.

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

Thank you!