00:01 patrickz joined 00:05 patrickb left
japhb vrurg: I concur that there are some basic playground modules that people almost certainly want, such as JSON::Fast, OO::Monitors, Linenoise, debugger/tracer modules, etc. I expect that eventually there will be better replacements for each, but until that happens, they're pretty basic needs. 00:22
vrurg japhb: The exact set of modules to be called "basic" could be discussible. I don't expect it to be permanent forever. 00:23
Just what is considered to be good at some point in time. 00:24
japhb AlexDaniel: val() is (by design) able to handle a very wide range of different number formats. I could twist your brain with some of the things I was testing when I did the first version of Str.Numeric (which val() was based on).
vrurg: Yeah, with some history so that people who are dabbling don't have to worry their basic scripts will suddenly stop working without much notice.
AlexDaniel vrurg: does it?
Geth rakudo: c24bec1feb | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/templates/NQP_REVISION
[NQP Bump] Brings 7 commits

NQP bump brought: github.com/perl6/nqp/compare/2019....gc85c2adbf c85c2adbf Merge pull request #590 from vrurg/nqp_589 fd6920f50 Make NQP::Configure::NQP take care of jars 15efae732 [jvm] Pass jars as an argument 29215797e [js] Implement '−' (U+2212) minus support in nqp::radix(_I) df9f7c16e Merge pull request #588 from patrickbkr/sub-mod-upd-no-silent-error f994d5ea6 Prevent silently swallowing errors on submodule update 1b5834027 [js] Bump serialization format version		 00:25
vrurg AlexDaniel: This is Rakudo version 2019.11-258-g6c1528263 built on MoarVM version 2019.07.1-403-g9442b1a7c 00:26
AlexDaniel hmmmm 00:27
vrurg AlexDaniel: did you bump MOAR?
pmurias vrurg: re change that should fix that problem
tellable6 2019-12-12T21:12:06Z #raku-dev <vrurg> pmurias Could you pls try and see if github.com/perl6/nqp/pull/591 fixes nqp-runtime.jar problem?
AlexDaniel did I both the release or something…
botch
vrurg AlexDaniel: MOAR_REVISION: 2019.07.1-403-g9442b1a7c 00:28
pmurias vrurg: I have been manually applying a similiar fix on nqp-j to make working on nqp-j not super horrible
AlexDaniel ok I didn't: github.com/perl6/nqp/blob/3e05931f...R_REVISION
vrurg AlexDaniel: seemingly, the release needs minors as it comes with 2019.07 moar
AlexDaniel that's a good start
vrurg Hm...
pmurias: Shall I merge it? 00:29
AlexDaniel: I suspect the moar bump in release did not merge back to the master. 00:30
AlexDaniel vrurg: that's actually correct, I think 00:31
because 2019.07* describe string was actually ahead of the release
(even though it is based off 2019.07) 00:32
so when I merged back I left it intact
but it is surprising that there were several bumps after that
and all of them are of 2019.07…
wait a minute…
00:34 ZzZombo_ joined 00:36 Kaiepi left, ZzZombo left, AlexDaniel left 00:37 ZzZombo_ is now known as ZzZombo, AlexDaniel joined, AlexDaniel left, AlexDaniel joined, pmurias left
AlexDaniel yeah, I see now 00:39
we have a dangling tag in moarvm
ookay 00:41
Geth nqp: 01e1e62773 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/templates/MOAR_REVISION
[MoarVM Bump] Brings 3 commits

MoarVM bump brought: github.com/MoarVM/MoarVM/compare/2...g0bcdda3f2 0bcdda3f2 Merge tag '2019.11' 3a212c9ab Update VERSION for release 019fd77ea Remove extra newlines in ChangeLog
rakudo: 5c00496a70 | (Aleks-Daniel Jakimenko-Aleksejev)++ | tools/templates/NQP_REVISION
[NQP Bump] 01e1e6277 [MoarVM Bump] Brings 3 co […]

NQP bump brought: github.com/perl6/nqp/compare/2019....g01e1e6277		 00:42
AlexDaniel I'll write a short explanation on #moarvm
AlexDaniel vrurg: thanks! 00:43
00:44 Kaiepi joined, Kaiepi left 00:45 Kaiepi joined
AlexDaniel sena_kun: interesting release situation: colabti.org/irclogger/irclogger_lo...-12-13#l21 00:45
vrurg welcome! :)
tellable6 AlexDaniel, I'll pass your message to sena_kun
AlexDaniel sena_kun: this can never happen on nqp/rakudo side because the sakefile makes sure it can push everything and then it pushes 00:46
tellable6 AlexDaniel, I'll pass your message to sena_kun
AlexDaniel sena_kun: so it's not a big problem, just something to keep in mind maybe 00:47
tellable6 AlexDaniel, I'll pass your message to sena_kun
00:59 patrickb joined 01:03 patrickz left 01:27 lucasb left 01:58 patrickb left 02:32 Kaiepi left, Kaiepi joined 02:46 ZzZombo_ joined 02:47 ZzZombo left, ZzZombo_ is now known as ZzZombo 04:31 reportable6 left, bisectable6 left, releasable6 left, statisfiable6 left, quotable6 left, notable6 left, nativecallable6 left, bloatable6 left, shareable6 left, committable6 left, sourceable6 left, coverable6 left, greppable6 left, benchable6 left, unicodable6 left, squashable6 left, releasable6 joined, shareable6 joined, notable6 joined, nativecallable6 joined, bisectable6 joined, greppable6 joined, quotable6 joined 04:32 unicodable6 joined, committable6 joined, coverable6 joined, sourceable6 joined 04:33 bloatable6 joined, squashable6 joined, benchable6 joined, reportable6 joined, statisfiable6 joined 08:44 sena_kun joined 08:54 sena_kun left 09:10 sena_kun joined 09:15 robertle joined 09:21 sena_kun left 09:25 ufobat_ joined 09:28 ufobat left 09:58 robertle left 10:00 robertle joined 10:11 robertle left 10:13 robertle joined 11:13 patrickb joined
lizmat m: m: dd <4/5*2**9>, 4/5*2**9 # is this to be expected ? Or is val processing getting it wrong ? 12:00
camelia RatStr.new(0.0015625, "4/5*2**9")
409.6
lizmat m: dd 4/(5*2**9) 12:01
camelia 0.0015625
12:01 robertle left
jnthn I'm a bit surprised val attempts such a complex expression at all... 12:02
lizmat fwiw, in my refactor, that would be 409.6, as it would be in an ordinary expression
it's in the spec, and it does
jnthn OK
lizmat are you saying that it shouldn't? It would make things a *lot* simpler :-)
jnthn Then I'd assume the spec would want ordinary precedence rules to be followed. 12:03
lizmat indeed... ok...
it will :-)
jnthn Well, not sure without looking into the history of it, but I'm a bit surprised
I thought val was meant to handle, well, values.
e.g. things that full beneath <value>
lizmat I guess we agree on that, it's just the definition of what constitutes a value, I guess 12:04
jnthn I guess I can see the use of it
lizmat m: BEGIN @*ARGS = "2*10**3"; sub MAIN(Int:D $a) { dd $a } # YIL I learned that this actually works
camelia IntStr.new(2000, "2*10**3")
lizmat would be one reason it is nice to have :-) 12:05
AlexDaniel not really?
allowing some math but not other
12:06 robertle joined
nine 2*10**3 looks like some poor man's scientific notation 12:08
AlexDaniel m: BEGIN @*ARGS = "-1/-2*-10**+10"; sub MAIN(Rat:D $a) { dd $a } 12:09
camelia RatStr.new(0.00000000005, "-1/-2*-10**+10")
AlexDaniel m: BEGIN @*ARGS = "-2*-10**+3-2*-10**+3i"; sub MAIN(Complex:D $a) { dd $a } 12:10
camelia ComplexStr.new(<2000+2000i>, "-2*-10**+3-2*-10**+3i")
AlexDaniel that last one I'm not too worried about because honestly how often have you seen complex numbers in real code :) 12:11
jnthn Yeah, I figured it's there as a way to put an exponent on it 12:12
AlexDaniel m: dd val("-1/-2*-10**+10") 12:17
camelia RatStr.new(0.00000000005, "-1/-2*-10**+10")
AlexDaniel m: dd -1/-2*-10**+10
camelia -5000000000.0
AlexDaniel jnthn: what's the use for it?
because I don't really see it 12:18
12:28 lucasb joined 12:52 sena_kun joined 12:56 robertle left 13:00 robertle joined 13:14 pmurias joined
pmurias vrurg: line that causes the error: github.com/rakudo/rakudo/blob/mast...RO.nqp#L77 13:53
vrurg: when $_ is nqp::null on the JVM .HOW throws an exception
vrurg: and $_ is nqp::null in that case when building on the JVM 14:05
|Tux| Rakudo version 2019.11-260-g5c00496a7 - MoarVM version 2019.11-90-g0bcdda3f2
csv-ip5xs0.708 - 0.711
csv-ip5xs-206.330 - 6.467
csv-parser22.667 - 22.995
csv-test-xs-200.420 - 0.430
test7.156 - 7.441
test-t1.720 - 1.736
test-t --race0.789 - 0.796
test-t-2029.858 - 30.406
test-t-20 --race9.348 - 9.393
 14:11
vrurg pmurias: thanks! I'll workaround it. Though the problem with nulls in JVM is better be fixed at some point. :( 14:21
14:21 Kaiepi left, Kaiepi joined 14:23 TreyHarris left 14:24 Kaiepi left 14:25 Kaiepi joined 14:27 pmurias left, pmurias joined
pmurias vrurg: is a nqp::null expected to be there? 14:32
vrurg pmurias: actually, no. Two lone bugs meet each other and annihilated... Copy-paste brought in $_ instead of correct $c. 14:33
vrurg is rebuilding jvm to see if it's fixed now. 14:35
14:36 TreyHarris joined
vrurg pmurias: does it make sense to merge github.com/perl6/nqp/pull/591? 14:37
14:40 patrickb left
Geth nqp: 9e582e24dc | (Vadim Belman)++ | 2 files
An attempt to fix nqp-runtime.jar dependency

Don't send it into gen/jvm but only use the `base_dir` to keep a single copy of it. Still, not the best solution but we keep all the jars there anyway for now.		 14:42
nqp: c073b0ce08 | (Paweł Murias)++ (committed using GitHub Web editor) | 2 files
Merge pull request #591 from vrurg/nqp_589_runtime-fix

An attempt to fix nqp-runtime.jar dependency
vrurg Ok, serves as an answer. :D
pmurias vrurg: yes, that's how stuff was before the changes, likely not the best spot to generate the .jar in but that can be fixed later 14:43
vrurg And rakudo-jvm builds again. pmurias++ for spotting the bug location! 14:44
pmurias vrurg: re fixing nqp::null, the way the JVM handles those is not good, but I strongely belive that the truffle one is the future not the old bytecode one so I don't want to spend a lot of time doing large changes to the old JVM backend 14:46
vrurg pmurias: makes sense. After all, most of the nullish problems are easily workaroundable. 14:47
Geth rakudo: vrurg++ created pull request #3350:
Fix a copy/paste bug		 14:48
14:54 sena_kun left 15:07 sena_kun joined 15:28 robertle left
pmurias vrurg: on the old jvm backend they are stored as jvm null 15:35
Geth rakudo: ee66a6b1c5 | (Vadim Belman)++ | src/Perl6/Metamodel/C3MRO.nqp
Fix a copy/paste bug

  $_ instead of correct $c		 15:45
rakudo: 0f49ba1918 | (Vadim Belman)++ (committed using GitHub Web editor) | src/Perl6/Metamodel/C3MRO.nqp
Merge pull request #3350 from vrurg/problem-solving-103-jvm-null-fix

Fix a copy/paste bug
15:51 ExtraCrispy left 15:54 unclechu left 16:11 pmurias left 16:40 ExtraCrispy joined 16:41 ExtraCrispy left, ExtraCrispy joined 16:43 ExtraCrispy left, ExtraCrispy joined 16:44 ExtraCrispy left, ExtraCrispy joined 16:46 ExtraCrispy left, ExtraCrispy joined 16:47 ExtraCrispy left 16:53 ufobat_ left 16:55 sena_kun left 16:56 ExtraCrispy joined 17:08 sena_kun joined 17:44 AlexDani` joined 17:46 AlexDaniel left 18:02 ExtraCrispy left 18:41 ExtraCrispy joined 18:44 ExtraCrispy left
tobs vrurg++ # closing my open issues! 18:51
18:54 sena_kun left
vrurg tobs: welcome :) 19:03
19:09 sena_kun joined 19:28 TreyHarris left
lizmat m: dd :1(123) # are base-1 numbers a thing ? :-) 19:35
camelia This call only converts base-1 strings to numbers; value 123 is of type Int, so cannot be converted!
(If you really wanted to convert 123 to a base-1 string, use 123.base(1) instead.)
in block <unit> at <tmp> line 1
19:48 TreyHarris joined
lizmat m: dd :2<10*10**10>, 2*2**2 # the first feels wrong to me, as they 20:18
camelia 20000000000
8
lizmat parsed the multiplier and the exponent in base 10, rather than base 2? 20:19
ah, the specs are explicit about that: multiplier and exponent are always in base 10 20:20
Geth rakudo: vrurg++ created pull request #3351:
Don't use client core rev to determine class language version		 20:32
20:54 sena_kun left 21:08 sena_kun joined
lizmat wow, a bare start of raku calls val() 24x 21:49
looking at the strings it's been given, I wonder why val() is called at all 21:50
I can't imagine path names ever making sense for val() processing
hmm... seems to be a side-effect of using <> 21:52
m: my %h; dd %h<a> # even in this case, "a" is pulled through val() 21:53
camelia Any %h{'a'} = Any
21:57 pmurias joined
lizmat so can we have something in an environment variable that does not start with a digit or a period ? 22:12
that would create a valid allomorph ?
dogbert17 lizmat: accessing hash elements is very slow, any opts there would be more than welcome :-) 22:13
lizmat dogbert17: I think I've done what I could there already :-(
FOO=.123 raku -e 'dd %*ENV<FOO>' # RatStr element = RatStr.new(0.123, ".123") 22:14
dogbert17 argh, I get the impression that it can be orders of magnitude slower than P5
lizmat well, when you consider that Raku hashes are basically like tied hashes in Perl, I think Raku is doing pretty well
dogbert17 is there a way to 'avoid' that using some clever syntax? 22:15
lizmat use nqp 22:17
m: FOO= raku -e 'dd %*ENV<FOO>' # TIL why empty env variable wind up as 0 in numeric context 22:19
camelia 5===SORRY!5=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> 3FOO= raku -e7⏏5 'dd %*ENV<FOO>' # TIL why empty env v
expecting any of:
infix
infix stopper
postfix
state…
lizmat FOO= raku -e 'dd %*ENV<FOO>' # TIL why empty env variable wind up as 0 in numeric context
IntStr element = IntStr.new(0, "")
22:19 pmurias left
lizmat looks like my 29 ENV entries are responsible for about 14 msecs for each raku startup 22:21
afk for a bit&
japhb lizmat: Woah -- that's around 10-15% of startup on my machines. Is that true for all hash lookups via <key>, only for lookups in dynamic hashes, or only lookups in %*ENV? 22:34
Depending on the answer to that, there's a metric ton of optimization I can go and do in some of my modules .... 22:35
(Tempted to go and test it now, excpet I've got $dayjob tasks to complete. :-/)
22:36 pmurias joined
japhb realizes (again) how important it is to test assumptions -- I always assumed hash lookup by compile-time short string constant would be about as fast a hash lookup as you could get. 22:43
22:54 sena_kun left 23:10 sena_kun joined 23:11 pmurias left, pmurias joined
lizmat it can't be compile time, because hash lookups are methods and late bound 23:15
Geth rakudo: 15a5580164 | (Vadim Belman)++ | src/Perl6/Metamodel/LanguageRevision.nqp
Don't use client core rev to determine class language version

It doesn't play well with precompilation where `CompUnit` can be detected as the client.		 23:24
rakudo: f722715c1e | (Vadim Belman)++ (committed using GitHub Web editor) | src/Perl6/Metamodel/LanguageRevision.nqp
Merge pull request #3351 from vrurg/class-lang-ver-bug

Don't use client core rev to determine class language version
lizmat japhb: looks like the 10 msecs where mostly from parsing the test code 23:26
val("a") for ^29 was about 14 msecs extra 23:27
m: val("a") for ^29; say now - INIT now # but actual execution was much less 23:28
camelia 0.0028296
lizmat will look at making this smarter tomorrow
sleep& 23:29
23:34 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!