github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
01:27
MasterDuke left
03:53
frost-lab joined
04:20
frost-lab left
04:28
frost-lab joined
05:38
frost-lab left
05:41
frost-lab joined
|
|||
nwc10 | good *, #moarvm | 05:55 | |
06:36
MasterDuke joined
|
|||
MasterDuke | long *, #moarvm | 06:46 | |
nine: github.com/Raku/nqp/blame/master/s...T.nqp#L154 is what you think is wrong? | 06:49 | ||
06:50
domidumont joined
|
|||
MasterDuke | fwiw, removing that line entirely causes `Arg count 1 doesn't equal required operand count 2 for op 'isnull'` in the nqp build | 06:51 | |
07:27
zakharyas joined
|
|||
nine | MasterDuke: I think I've misread the code a bit. After all there's this $num_args == $num_operands - 1 condition. But it's clear that there's an off-by-one somewhere in that method | 07:35 | |
MasterDuke | agreed, but i haven't spotted it yet either | 07:38 | |
nine | Oh, and now I understand it. It may actually be a feature | ||
What the code does is for ops that write into a register, add that result register automatically to the operand list if it's missing. This implies that the write register can be specified explicitly, like nqp::iseq_i($result_reg, 1, 2) | 07:40 | ||
MasterDuke | hm, is that feature ever used? | ||
nine | Good question. You could make that automation mandatory by removing the `&& $num_args == $num_operands - 1` and see where it breaks | 07:41 | |
MasterDuke | lets see. nqp builds and passes its tests... | 07:43 | |
rakudo builds... | 07:45 | ||
and passes its tests and a spectest | 07:49 | ||
nine | I'm not terribly surprised | ||
MasterDuke | nor i | ||
nine | So, does this change fix the issue? | 07:51 | |
MasterDuke | `./nqp-m -e 'for nqp::split(",", "abc,def", "ghasdfi") { say($_) }'` now dies with `Arg count 3 doesn't equal required operand count 2 for op 'split'` | ||
which i think is a much better result than printing "ghasdfi" | 07:52 | ||
any reason not to PR that change? | 07:55 | ||
speaking of PRs, with a week before the release, i think github.com/MoarVM/MoarVM/pull/1467 and github.com/MoarVM/MoarVM/pull/1464 are pretty non-controversial | 07:56 | ||
any thoughts from the channel? | 07:57 | ||
08:02
patrickb joined
08:06
patrickb left
|
|||
nine | Please PR the change :) | 08:18 | |
MasterDuke | github.com/Raku/nqp/pull/714 | 08:36 | |
08:51
Altai-man_ left
08:53
sena_kun joined
|
|||
nwc10 | www.csl.cornell.edu/~cbatten/pdfs/...go2020.pdf -- Theseadditional operations indeed hurt the interpreter perfor-mance. However, in practice the interpreter executes fora fraction of the overall execution time for many bench-marks. Thus, the overhead induced by the extra logicwe added could be considered as not significant | 09:18 | |
optimised for benchmarks? :-) | 09:19 | ||
jnthn | My own experience tells that real applications are less kind than benchmarks in terms of time spent in the interpreter. | 09:34 | |
The more one relies on that, the larger the warm-up time gets | |||
nwc10 | and if you take this too far you ship a JIT that can run an NES emulator very well, but can't help Rails. | 09:38 | |
kind of the same with Pyston and LLVM, I suspect. "Oh pants, we need a baseline JIT too". And Safari? | 09:39 | ||
anyway, the approach in that paper shipped as part of the PyPy release a few days ago | 09:41 | ||
jnthn | iirc the CLR (at least initially, maybe still) never did interpret, it just went straight for a quick baseline JIT | 09:45 | |
(quick as in quick to produce the machine code) | |||
I guess initially they cared only for x86 (maybe x64) and itainc | 09:46 | ||
10:00
frost-lab left
10:03
frost-lab joined
11:39
Kaeipi joined
11:40
Kaiepi left
11:43
zakharyas left
12:02
frost-lab left
|
|||
nwc10 | I believe that this is not entirely off-topic... :-) | 12:34 | |
So, the ongoing story of hot beverage fail | 12:35 | ||
I went round to Andrea's parents to change her mum's car to summer tyers | |||
tyres | |||
[This is OK. One person visiting relatives] | |||
but before I started, I wanted a cup of tea. OH NOES - where is the kettle? | |||
so the kettle was unplugged, because it had to go back under guarantee, because it was dysfunctional | 12:36 | ||
so, she tried using it | |||
it's a fancy kettle - a button to pick 60Ā°C, 70Ā°C ... 100Ā°C and a light to show which and beep to acknowledge input | 12:37 | ||
kettle starts in a "disco mode" - beeping and cycling the temerature lights | |||
then it deigns to heat water at 80Ā°C for a bit. Then more disco. Then 70Ā°C. Then I give up and use a pan | |||
This has triggered Andrea to descale our kettle. | 12:38 | ||
jnthn | Did it ever make anything close to 70 or 80? | ||
nwc10 | Not really. Got some way there. | ||
jnthn | Ah. That's pretty useless for tea. :) | ||
nwc10 | So boiling water in a pan here during this descaling | ||
[yep] | |||
first failure - yesterday - water from pan pours out much mroe quickly than a kettle - so comes out of the top of the Aeropress and everywhere onto the kitchen work surface | 12:39 | ||
today, thinking that I was going to recount this story and how I'd not F'd up | |||
I managed to make the coffee, but then drop the slug of squashed coffee grounds from the Aeropress *into* the cup of coffee | 12:40 | ||
(And onto the worksurface) | |||
recovered from this with a tea infuser as a sieve and another mug | |||
I'm going to make more coffee - what could possible go wrong *this* time? | |||
jnthn | At least you had coffee before making this coffee, so it might go better? | 12:41 | |
nwc10 | I hope so. | ||
nine | Why a pan, not a pot? | 12:42 | |
jnthn | I only just remembered to order more beans in the latest grocery delivery. Forgetting that would have led to an unfortunate morning in several day's time. | ||
12:43
zakharyas joined
|
|||
nwc10 | oh my. Catastrophe averted | 12:43 | |
jnthn | The one I used to have at home needed putting ground coffee into it for each cup, so I noticed I was running out. Now it's just a 500g beans container and all too easy to forget about. | ||
It has a really silly failure mode where it will 1. grind beans, 2. realize its water tray is full, 3. just dump the ground but unused beans out, thus wasting them. I dunno why it can't figure out 2 before it does 1. | 12:44 | ||
nwc10 | nine: unclear if you're using "pan" and "pot" for the same things as I am - Andrea picks different words from me. In each case wanted the smallest cooking vessel that can go on the hob in which I could boil water | 12:45 | |
nine | nwc10: I was wondering if it may be just a vocabulary issue, so I did an image search of pot duckduckgo.com/?q=pot&iax=imag...;ia=images vs pan duckduckgo.com/?q=pan&iax=imag...;ia=images | 12:59 | |
nwc10 | I have coffee. I have drunk some. However, opportunities remain for spilling the rest | 13:02 | |
nine | At least you only slipped water. Our filter coffee machine has a timer. You put water and coffee in, set the timer for next morning and are good to go. Except that you need to ensure that the pot is also in place. Otherwise you wake to that delicious coffee smell just to find that you first have to remove it from the kitchen counter and set up a new pot... | 13:05 | |
nwc10 | how cruel | 13:06 | |
and how design fail! - one more microswitch | |||
nine | indeed | ||
14:39
dogbert11 joined
14:42
dogbert17 left
|
|||
timotimo | cdn.discordapp.com/attachments/348...nknown.png | 14:59 | |
[Coke] | I went from drinking k-cup coffee at home to driving a vehicle to a bakery a few miles away to get an Americano today. Bad Coke. | 15:22 | |
nwc10 | This is awesome. It's quite readable. I'm only halfway through, but so far, to circumvent the GIL, it's "we link the entire Python runtime statically into our shared object, and use a linker script to hide *all* its symbols" and then "we copy our shared library to different names in a temp directory so that we can load it more than once" -- arxiv.org/pdf/2104.00254.pdf | 15:33 | |
before that part there's quite a good summary of why Python is a sodbag to JIT. | |||
their citations are screwed up and they don't seem to have noticed. | 15:34 | ||
also, I assume that the publication date is only a coincidence | |||
MasterDuke | timotimo: second life? | 15:49 | |
timotimo | MasterDuke: bill wurtz music videos | 15:50 | |
MasterDuke | huh, don't recognize the name | 15:51 | |
timotimo | he just recently pivoted to blender from what i assume to have been Flash | ||
www.youtube.com/watch?v=xuCn8ux2gbs if you want to see something he made that got almost 120 million views | 15:55 | ||
but this is only partially music | 15:58 | ||
nwc10 | "Both the extensions and code size issues can be resolvedby writing custom dynamic library loading code rather thanrelying on OS primitives likedlopen." | 16:29 | |
17:27
domidumont left
|
|||
nwc10 | the number of hoops that they are having to go through to work around GIL limitations makes me wonder how long until a language that can thread (R or Julia)? starts to eat into this | 17:31 | |
also, oh my, the security and even just software engineering chalenges of "we package up models as Python code" | 17:32 | ||
18:09
patrickb joined
|
|||
nwc10 | $ perl -le 'printf "%a\n", 3.1414999999999935' | 18:17 | |
0x1.921cac083126p+1 | |||
$ perl -le 'printf "%a\n", 3.1415' | |||
0x1.921cac083126fp+1 | |||
Is it actually possible to do that in NQP? :-) | |||
anyway, github.com/MoarVM/MoarVM/pull/1385 oh my | |||
they differ in the last 4 bits of the mantissa. That seems rather too sloppy to be acceptable | 18:18 | ||
patrickb: if t/hll/06-sprintf.t is run on "this week"'s MoarVM is it still producing the same failure output? | 18:20 | ||
patrickb | It should. The fix I was writing about is not upstream. | 18:22 | |
nwc10 | OK, but I can't remember offhand when a fix went into MoarVM that might be relevant | 18:23 | |
oh Dec 11 | |||
that's so last year | |||
18:27
zakharyas left
|
|||
nwc10 | Offhand, for this expression: | 18:28 | |
my $float_str := ~$float; | |||
where does that land in MoarVM? | |||
(what's the route into the C code for that stringification) | 18:29 | ||
patrickb | give me a mome t | 18:31 | |
hm. need to reboot into windows | 18:32 | ||
18:32
patrickb left
|
|||
MasterDuke | probably coerce_ns or smrt_strify | 18:33 | |
18:35
patrickb joined
|
|||
patrickb is back on Windows | 18:35 | ||
nwc10 | thanks, but "there might be a delay" until the next question | 18:36 | |
oh wait, I realise I did have one. | 18:39 | ||
I think that the code in `scientific` will hit nqp::pow_n(10.0, $exp) | |||
so in that test $exp was 20 | |||
so | |||
m: nqp::say(nqp::pow_n(10.0, -20.0)) | 18:40 | ||
camelia | 5===SORRY!5=== Error while compiling <tmp> Could not find nqp::pow_n, did you forget 'use nqp;' ? at <tmp>:1 ------> 3nqp::say(nqp::pow_n(10.0, -20.0)7ā5) |
||
nwc10 | n: nqp::say(nqp::pow_n(10.0, -20.0)) | ||
m: use nqp; nqp::say(nqp::pow_n(10.0, -20.0)) | |||
camelia | This type cannot unbox to a native number: P6opaque, Rat in block <unit> at <tmp> line 1 |
||
nwc10 | aargh | ||
MasterDuke | nqp: nqp::say(nqp::pow_n(10.0, -20.0)) | ||
camelia | 1e-20 | ||
nwc10 | thanks | ||
MasterDuke | heh, np | ||
nwc10 | patrickb: so my only current question is does MinGW get the same value? | 18:41 | |
(and did I have it wrong - should my question be about nqp::pow_n(10.0, 20.0) ? | |||
patrickb | currently compiling | ||
nwc10 | thanks | ||
I stuck a breakpoint on dtoa_grisu3 | 18:58 | ||
only call was from src/core/interp.c:888 | |||
OP(coerce_ns): | |||
888 is supposed to be lucky, isn't it? :-) | |||
MasterDuke | jnthn: in the examples in github.com/rakudo/rakudo/pull/4320, why does MVM_SPESH_INLINE_LOG have no mention of either succeeding or failing to inline `infix:<**>`? things get inlined into it, but no other mention | 19:00 | |
nwc10: time to buy a chinese lottery ticket i guess? | 19:02 | ||
nwc10 | patrickb: not that you've got there yet, but I'm asking the wrong question. my num $exp := nqp::iseq_n($float, 0.0) ?? 0.0 !! nqp::floor_n(nqp::div_n(nqp::log_n($float), nqp::log_n(10.0))); | 19:03 | |
patrickb builds CORE.c atm... | 19:04 | ||
nwc10 | oops, I think that all these questions can be answered in NQP | ||
actually, it is 10 and 20 | 19:07 | ||
er, -20 | |||
Starting program: /home/nick/Sandpit/moar-g/bin/moar --execname=/home/nick/Perl/nqp/nqp-m --libpath=/home/nick/Perl/nqp nqp.moarvm -e nqp::say\(nqp::sprintf\(\"\<%7.3e\>\",\ \[-3.1415e-20\]\)\) | |||
... | |||
810 pow(x, y); | |||
x is 10, y is -20 | |||
here, of pow, gdb said | 19:08 | ||
Value returned is $3 = 9.9999999999999995e-21 | |||
if pow(10, -20) is something else on MinGW, then this is the problem | |||
patrickb | nqp::say(nqp::sprintf("<%7.3e>", [-3.1415e-20])) -> <-3.141e-20> | 19:10 | |
that's on mingw | |||
nwc10 | OK good, bug still present | ||
<-3.142e-20> on x86_64 linux, but I think that that's the only correct answer. As in, there should be no ambiguity. | 19:11 | ||
does "nqp::say(nqp::pow_n(10.0, -20.0))" report 1e-20 ? | 19:12 | ||
patrickb | 1.0000000000000022e-20 | 19:13 | |
nwc10 | oh my | ||
thanks | |||
that's our problem. | |||
you can reboot to $other (linux?) whenever you need to | |||
patrickb | it's a linux :-) | 19:14 | |
nwc10 | I'm not yet sure whether the easier fix is dammit, just to redo the NQP code to trust the output of the stringification, and then do the rounding as decimal maths with character operations | ||
this is, I believe, the long term right answer | 19:15 | ||
and might even be faster than trying to bodge round the problem by "emulating" pow_n with multiply | |||
patrickb | rebooting is not that much of a hastle. So just ping me when you need more testing. | ||
nwc10 | I'm not confident on a "when", but hiding in the cellar looks like a plan for the next few days: www.bbc.co.uk/weather/2761335 | 19:16 | |
but there are other things to do (including tidying the cellar, and possibly also "encourage my son to actually do his school work") | 19:17 | ||
oh my, if I'm not careful I will get a stroke-by-stroke commentary on writing letters. | |||
Unicode eat your heart out - you can decompose ASCII further if you really want to :-) | |||
nine | MasterDuke: there is just one code path where optimize_call won't even make an entry about inlining: when it can't even identify the static frame to inline | 19:21 | |
patrickb reboots | |||
19:22
patrickb left
19:24
patrickb joined
|
|||
japhb | Since there are more folks here at this hour -- we *may* have found a problem with the libuv bump that happened a couple months ago. I and ugexe have both been seeing "Failed to open dir: Too many open files" errors when doing a `zef uninstall`. ugexe is on MacOS and I'm on Linux, so it doesn't appear to be platform-specific. When I rolled back to just before the libuv bump, I couldn't recreate it. | 19:31 | |
nwc10 | japhb: yes, erk, seems important but no immediate idea | 19:32 | |
ugexe | i scanned the libuv changelog but nothing jumped out at me | 19:33 | |
japhb | ugexe: Gah. Thanks for taking a look. | 19:36 | |
ugexe | github.com/libuv/libuv/blob/v1.x/C...og#L1-L112 | 19:41 | |
japhb | ugexe: Yeah, the only one that triggered something for me is github.com/libuv/libuv/blob/v1.x/ChangeLog#L67 | 19:48 | |
It's also the only change to mention fd at all since github.com/libuv/libuv/blob/v1.x/ChangeLog#L419 | 19:49 | ||
ugexe | fwiw testing a given commit is the problem would involve going to the libuv subdirectory of a moarvm installation, reverting the commit, then running `make install` inside the moarvm dir. then running rakudo should have those changes. its unfortunate there isnt a golf to trigger the issue | 20:01 | |
20:11
zakharyas joined
20:19
patrickb left
20:55
zakharyas left
21:07
dogbert17 joined
21:09
dogbert11 left
21:22
dogbert11 joined,
dogbert11 left
21:23
dogbert11 joined
21:24
dogbert17 left
21:56
dogbert17 joined
21:59
dogbert11 left
22:01
dogbert17 left
22:02
Geth joined,
dogbert17 joined
|