01:14 [Coke] joined, konobi joined, arnsholt_ joined, leedo joined, sivoais joined 01:25 zostay joined 01:44 SmokeMachine joined 02:48 ilbot3 joined 03:18 dalek joined 06:55 brrt joined
brrt it appears i have found the root cause of the wrong spillage 07:38
contrary to what i want to do, the load is inserted just after the use
brrt should probably ressurrect tile debug dumping 07:39
hmm, that may not be true after all...
samcv brrt, how do i make callgrind give me more data 07:40
it's not giving me any of the functions called by the utf8 stream decoder 07:41
just saying that function is using that, but i know it calls many other utf-8 functions
brrt i'm actually not all that familiar with calgrind 07:43
i know valgrind and i know ASAN
08:22 brrt joined 08:34 btyler joined 08:37 tbrowder joined, ilmari joined, mst joined, camelia joined, nine joined, nebuchadnezzar joined, stmuk joined, japhb joined, nwc10 joined, mtj_ joined, BinGOs joined, moritz joined, jnthn joined, Util joined, JimmyZ joined, ChanServ joined 08:44 sivoais joined 08:56 zakharyas joined 09:18 leego joined
jnthn morning o/ 10:10
yoleaux2 5 Jan 2017 23:45Z <samcv> jnthn: so I am trying to get certain emoji working, and so i made this change here github.com/samcv/MoarVM/commit/a29...bc21b3R579
5 Jan 2017 23:47Z <samcv> jnthn: and oh oops i made a mistake. sorta nvm
05:10Z <MasterDuke> jnthn: if you don't mind taking a look at irclog.perlgeek.de/perl6-dev/2017-..._13865466, do you have an opinion? should we give the same error and suggestion for all Nd's as for [1..9]?
samcv morning jnthn 10:11
also yeah nvm that thing i said. i got it working :)
PR is on moar and ready for merge
jnthn \o/
Review coming shortly then :)
lizmat moarning jnthn :-) 10:12
yoleaux2 05:10Z <MasterDuke> lizmat: if you don't mind taking a look at irclog.perlgeek.de/perl6-dev/2017-..._13865466, do you have an opinion? should we give the same error and suggestion for all Nd's as for [1..9]?
samcv i want only 1 yoleaux2
jnthn hi lizmat
samcv not 2
jnthn samcv: About your calling question in backlog, what flags did you build with? 10:13
You may get more into with --debug=3
samcv --debug
ah. ok :)
jnthn s/calling/callgrind/ # d'oh :) 10:14
samcv i will do that then
jnthn But I don't know whether callgrind can take advantage of that
arnsholt Could be inlining?
jnthn Since it's a dynamic analysis, and inlining means that some frames really don't exist
samcv i don't think the utf-8 stream decode is inlined but
jnthn gdb seems to happily untangle that with --debug=3
samcv ah nice :)
jnthn So I guess that data's there at least. 10:15
arnsholt --debug=3 turns into -g3?
jnthn With gcc I believe so, yeah 10:16
Maybe it's same for clang too, forget these intricacies :)
arnsholt Yeah, I assume it's different for MSVC =)
Anyways, -g3 is really nice
Another *very* useful thing it adds is macro definitions
samcv nice 10:17
i've been using the kcachegrind program to inspect the logs
arnsholt So that you can p OBJECT_BODY(a_thing), rather than figuring out the definition *again*
(Though note that gdb can also be told about macros run-time, so that at least you only have to figure them out once per session =) 10:18
Yeah, kcachegrind is nice
samcv urm yeah this is more in depth for sure 10:19
jnthn Nice :)
PR reviewed
Righty, I was looking into that leak... 10:24
nwc10 Merry Christmas 2.0, jnthn 10:30
jnthn Thanks! :) 10:31
jnthn celebrates with coffee and deleting code :)
samcv jnthn, fixes made 10:33
10:50 Ven joined
brrt my spilling code doesn't break, but does return the wrong value, and i need to figure out why 10:50
to be continued
dalek arVM: ebc4abc | samcv++ | src/strings/normalize.c:
Don't break after ZWJ or for MALE SIGN and FEMALE SIGN
 10:52
arVM: d26f8c0 | samcv++ | src/strings/normalize.c:
use #define’s for the ZWJ, ZWNJ, MALE SIGN and FEMALE sign

Also use a switch for a = MVM_UNICODE_PVALUE_GCB_ZWJ in should_break()
MoarVM: 331a6b4 | jnthn++ | src/strings/normalize.c:
MoarVM: Merge pull request #486 from samcv/emoji
MoarVM:
MoarVM: Don't break after ZWJ or for MALE SIGN, FEMALE SIGN or Glue_After_ZWJ
samcv yey
dalek arVM/work-lifetime: 1d3cdad | jnthn++ | / (12 files):
Eliminate the getregref_ ops.

These meant that we could not rely on ->work no longer being needed after the frame's execution was completed. This implied that, short of static analysis to check these ops were not used, we could not be sure it was OK to throw out ->work right after the frame's dynamic scope ended. The ops were not being used in Rakudo, nor in NQP besides in the code that compiled into them, which was already been removed. They only existed to allow lowering of lexicalref => localref at some point in the future, but an optimization that pessimizes the world is hardly a win. It would also have been a huge pain for the JVM backend, and likely the JS backend too, to implement localref (neither did so).		 11:18
jnthn While I'm killing off unused stuff that costs us... 11:24
Nothing anywhere in Rakudo or NQP, except some tests cases that don't entirely pass anyway, needs multi-shot continuations. 11:25
We only need one-shot ones in Rakudo
But we complicate some hot code-paths by attempting to support them
And I can't see us ever needing them
We only really need co-routine power
Which we get from one-shot 11:26
For both gather/take and in the future for non-blocking await
This comes up now because I'm tidying up the code path in question. 11:27
But also because I suspect we can reduce memory pressure for gather/take along the way
The only reason I put this in was because I was porting the JVM backend continuation tests
arnsholt Sounds sensible enough killing it off, then 11:29
I mean continuations are cool, and all, but if they're costly and unused...
jnthn Right
And given we fail the multi-shot tests anyway (I didn't sink time into them then 'cus we didn't need it) I'm doubtful anyone is using it 11:30
lizmat YAGNI applies, I guess :-)
jnthn *nod* 11:31
Yes, I'd prefer to make things better for all the users I know I have than keep a feature only interesting to users I can imagine might feasibly exist. :)
arnsholt My only use case for continuations is non-deterministic search, and I think one-shot is fine for that too 11:36
dalek arVM/work-lifetime: f2dae67 | jnthn++ | src/core/frame.c:
Re-order/simplify operations in remove_one_frame.

If the frame is on the call stack, we don't need to NULL stuff in it; it's going away anyway. We also eliminate a duplicate call to the function MVM_args_proc_cleanup_for_cache for the callstack case (the MVM_args_proc_cleanup in MVM_frame_destory calls it anyway). We may have continuation tags in a frame that was never promoted, since we may add tags but never actually take a continuation (a `gather` that never does `take` would be such an example), so we take care not to leak those. That duplication can be cleaned up a little later.		 11:39
dogbert17 notices a hive of activity :) 11:52
dalek arVM/work-lifetime: 202c266 | jnthn++ | / (10 files):
Eliminate continuationclone op.

Unused by anything in Rakudo, and in NQP only used in a test case. It was added because nqp-j had the op, and MoarVM continuations were done to the same API. However, we never used it besides that test case, and it didn't really work properly anyway because we didn't need it, so it is a bit hard to imagine any unknown users seriously relying on it. The removal of this will help to simplify ->work lifetime management.		 11:54
dogbert17 does anyone know how to run a single spectest file with the perl6 test harness? TEST_HARNESS=6 does not seems to work
e.g. 'make t/spec/S24-testing/line-numbers.t TEST_HARNESS=6' runs with t/harness5 :( 11:56
dogbert17 notices that this behaviour is hard coded into Configure.pl 12:13
dalek arVM/work-lifetime: 3819e7b | jnthn++ | src/ (2 files):
Enforce one-shot invocation of continuations.

One-shot is all that Rakudo needs for gather/take, and will suffice for non-blocking `await` also. We never really properly handled the multi-shot case anyway, out of not needing it. And our incomplete attempts to support it came with some nasty memory management risks. The only non-trivial test for this in the NQP test suite already was failing, so there's no loss there. This protection will also be useful for catching bugs when we introduce non-blocking `await` in Rakudo, as any double invocation there will surely be a screw-up.		 12:20
jnthn Lunch time, but looks like the next commit - provided spectest passes - brings some nice simplifications :) 12:35
Darn. A couple of fails. 13:10
jnthn re-does it in small steps 13:17
nwc10 but will *you* finish before ilmari remembers to have lunch? 13:18
13:18 FROGGS joined
jnthn hopes so ;) 13:19
dalek arVM/work-lifetime: 8035038 | jnthn++ | src/core/ (3 files):
Simplifications from making continuations 1-shot.

We no longer need the `in_continuation` flag, which eliminates the code to set it, the storage (though due to alignment we won't really save anything) and the code to check it. It was checked every time a callframe was taken off the stack, which adds up over a program's lifetime. Furthermore, we can now unconditionally clear up any continuation tags.		 13:25
jnthn That part seems innocent :)
dalek arVM/work-lifetime: 0ed5e11 | jnthn++ | src/core/frame.c:
Avoid duplicate continuation tag cleanup check.

This was harmless, but a waste of a few cycles on frame destruction. Given that only frames that were on the call stack will ever have had opportunity to run a `continuationreset`, there unconditional cleanup of them in `remove_one_frame` should suffice. (Deserialized contexts of closures will never have any continuation_tags and no means to get them.)		 13:33
jnthn And that one.
Umm 13:41
If I read the numbers right, CORE.setting compilation mighta just got somewhat faster. :)
ilmari nwc10: I have now finished lunch 13:43
jnthn I'm slower. :) 13:44
nwc10 :-)
dalek arVM/work-lifetime: 5c1ecc0 | jnthn++ | src/core/frame.c:
Always release ->work at end of a frame's scope.

This is safe to do unconditionally now that continuations are one-shot and register references are no more. This brings forward when memory can be released, and also prevents things from lingering in the inter-generational set for so long (we now really only ever do that when the frame is still in dynamic scope - for very long-lived and heap-promoted frames - since we don't enforce write barriers on registers).		 13:51
arVM/work-lifetime: 3398380 | jnthn++ | src/core/exceptions.c:
Use ->work as our "in dynamic scope" test.

It now reliably provides this information.		 14:09
arVM/work-lifetime: 5918061 | jnthn++ | src/ (3 files):
Eliminate `tc` field in MVMFrame.

We used to use it to track whether a frame is in dynamic scope, but now the `work` field can be reliably used for that. This shaves a memory write off every frame setup, but more significantly cuts the size of every MVMFrame by 4 (32-bit) or 8 (64-bit) bytes, which will reduce memory pressure.
timotimo cool, that also means more frames fit into our callstack regions :)
jnthn Aye 14:11
timotimo i wonder when other people get the pedantic anti-warning warning problem 14:18
dalek arVM/work-lifetime: fdfe07b | jnthn++ | src/core/args. (2 files):
Simplify args cleanup functions.

Reduce to one function, removing the confusingly-named "for_cache" form that did only part of the work.		 14:19
arVM/work-lifetime: e592dbc | jnthn++ | src/gc/roots.c:
Reduce number of checks in GC frame marking.

If the frame is no longer in dynamic socpe, we can't possibly have any args to care about.		 14:22
jnthn I...what...number did I just see for CORE.setting parse? 14:39
timotimo oooh, spill the beans!
jnthn will have to do some measuring after testing the upcoming patch
brrt ohoooh 14:40
we need to know
dalek arVM/work-lifetime: 275c9b5 | jnthn++ | src/gc/roots.c:
Fix typo in comment; MasterDuke17++.
 14:41
timotimo wow, that commit made core setting parse so much faster? 14:45
interesting, because this patch makes it do more
SCNR :)
dalek arVM/work-lifetime: c7dcce5 | jnthn++ | src/core/frame.c:
Only need to NULL ->work on return now.

  Thanks to GC using this to guard against all scanning of things that
are only alive in dynamic scope, there's no reason to also NULL out cur_args_callsite.		 14:47
arVM/work-lifetime: 6605510 | jnthn++ | src/core/args.c:
No need to zero the nameds used buffer size.

We never look at this number to decide anything except how much memory to free, which only happens once. a83f7f7 | jnthn++ | src/core/args.c: Remove unrequired NULLing of flattend arg buffers.
The ->work flag prevents us ever looking at these in GC after the lifetime of a frame is over, so this isn't needed.
timotimo yay, not as much memset!
(i think?)
jnthn timotimo: No, this was just assigning a zero in this case
Clarity around ->work lifetime allows quite a lot of cleanups. 14:49
arnsholt [Event "Let's Play!"]
[Site "Chess.com"]
[Date "2016.12.27"]
[White "arnsholt"]
[Black "Garoof"]
[Result "1-0"]
[ECO "C60"]
[WhiteElo "1109"]
Whoops!
notviki c-c-c-combobreaker!
JimmyZ jnthn: maybe a good read for you www.inf.puc-rio.br/~roberto/docs/MCC15-04.pdf ,and others 14:53
brrt that's from the lua dudes innit 14:56
JimmyZ yeah
timotimo ohai JimmyZ 14:57
JimmyZ timotimo: hello timotimo
jnthn Some numbers coming soon 14:59
JimmyZ jnthn++ said we need one shot continuations to implement coroutines, this pdf said full coroutines is easy to implement, which makes me think it may be a good read 15:01
jnthn JimmyZ: Thanks, will take a look over that 15:02
gist.github.com/jnthn/de0c1b39fd17...5f93541cfb 15:05
timotimo *nice* 15:06
stage mast and stage optimize were also very happy
JimmyZ nice improvement
jnthn m: say 1375456 - 1244512
camelia rakudo-moar dd5759: OUTPUT«130944␤»
jnthn Also 130MB less RAM to build CORE.setting 15:07
m: say 1244512 / 1375456
camelia rakudo-moar dd5759: OUTPUT«0.904800␤»
jnthn Given this is a notable chance, it'd be nice do give it at least an ASAN run and perhaps a GC stress run too 15:09
nwc10 at a83f7f7cbcc4f81f0672e5462f2637b6db9f5c70 ASAN was happy 15:12
but t/spec/S15-nfg/emoji-test.rakudo.moar fails a lot of subtest 15:13
jnthn Yeah, I branched earlier than the merge of that work
Just reviewing the changes, I suspect I've introduced a leak for continuations that are taken and never invoked. 15:14
(Thankfully, easily fixed.)
15:20 dalek joined
dogbert17 what nursery size do you recommend? 15:28
dogbert17 goes for 128k 15:30
jnthn That'll do it, I'd think 15:31
dogbert17 using this combo: his is Rakudo version 2016.12-230-g3c52aa096 built on MoarVM version 2016.12-83-ga83f7f7c
dalek arVM/work-lifetime: 88adca5 | jnthn++ | src/core/continuation.c:
Remove dead variable/assignment.
 15:35
arVM/work-lifetime: 74a6125 | jnthn++ | src/core/frame.c:
GC-destroying a frame still must check work, etc.

Since if the frame was taken as part of a continuation that was then never invoked, its work and tags need cleaning up.		 15:43
dogbert17 the emoji test can be ignored here I think 15:46
jnthn dogbert17: yes 15:50
jnthn hurls github.com/MoarVM/MoarVM/pull/487
dogbert17 ok, spectest clean with 128k nursery, FSA_SIZE_DEBUG 1 and MVM_GC_DEBUG 2 15:54
jnthn \o/
Very nice. 15:55
dalek arVM/even-moar-jit: a4b3f46 | brrt++ | src/jit/compile. (2 files):
Tile for compiling breakpoints

For debugging purposes only		 16:45
arVM/even-moar-jit: 0e66a23 | brrt++ | src/jit/linear_scan.c:
Implement spilling and loading of live ranges

This fixes the NQP test case moar/50-jit-register-alloc.t, and paves the way for the correct implementation of function calls etc.
16:46 brrt joined
brrt ^ my eastern-orthodox christmas present 16:47
we can now actually, as in really, as in literally, spill and load registers
and it works.... correctly
dalek arVM/more-pressure: 539346d | jnthn++ | src/io/ (3 files):
Take into account actual allocated of I/O buffers.

It seems libuv suggest we allocate 64KB sometimes, even when the input we get is tiny. While I'm not sure second-guessing it is wise, we should at least be honest internally about what's allocated. By storing the actual allocated size, the GC can track it as part of the gen2 promotion statistics, and be smarter about triggering full collections. This reduces memory overhead.		 16:48
brrt jnthn++ has to outdo me, as usual :-P 16:49
jnthn brrt++ :)
brrt i'm actually very, very, very happy that this works 16:54
i've been scheming on how to make the register allocator for the better part of a year 16:55
dalek arVM/heap-prof-tweaks: 8bfbb0e | jnthn++ | src/gc/orchestrate.c:
Tweak full collection criteria in heap profiling.

The recording of heap snapshots will of course use memory, which will throw off the RSS heuristic and make us a *lot* less likely to ever do a full collection, distorting the profiles. This is also a bit of a distortion (to more regular heap profiles being taken), but it's an improvement. (To do better, we could try tracking RSS before/after snapshots and excluding that memory from the calculation. Patches welcome if anyone tries it and finds that a viable appraoch.)
MoarVM/heap-prof-tweaks: 68b5e35 | jnthn++ | src/profiler/heapsnapshot.c:
MoarVM/heap-prof-tweaks: Null-check the *correct* thread's ->cur_frame.
MoarVM/heap-prof-tweaks:
brrt anyway, decommute & 16:56
nwc10 jnthn: ASAN finds work-lifetime unworthy of comment 17:02
dalek MoarVM/free-spesh-log-slots: 4d87b1c | jnthn++ | src/spesh/candidate.c: 17:03
MoarVM/free-spesh-log-slots: Free up spesh log slots after specialization.
MoarVM/free-spesh-log-slots:
MoarVM/free-spesh-log-slots: Spesh logging keeps values alive, preventing the GC from collecting
MoarVM/free-spesh-log-slots: them. It logs values to sample what types show up, which is fine, but
MoarVM/free-spesh-log-slots: we should not hang on to them beyond the point the specializer has
MoarVM/free-spesh-log-slots: used them in its analysis. This reduces memory overhead, perhaps
MoarVM/free-spesh-log-slots: quite notably in some applications that have large objects (for
MoarVM/free-spesh-log-slots: example, RT #130494 leaked many objects in this way). On CORE.setting
MoarVM/free-spesh-log-slots: compilation it saves ~3MB - not much in the scheme of things, but nice
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130494
dalek MoarVM/free-spesh-log-slots: to win.
jnthn So, post yesterday or so's discussion on review, I've put my work today into PRs for review! github.com/MoarVM/MoarVM/pulls :) 17:04
Feedback encouraged. Though I note nine++ who thought this was a good idea has gone on vacation. :P :P
nwc10: Glad ASAN is happy :-) 17:05
I'm off to relax :) 17:09
17:16 geekosaur joined
japhb Holy shazbot, that's a heck of a day's output! 17:31
japhb looks forward to building a fresh Rakudo with changes like these. :-)
[Coke] jnthn++ 17:34
japhb .ask brrt Now that you have a working register allocator, what's left before you can merge that branch? 17:39
yoleaux2 japhb: I'll pass your message to brrt.
diakopter shazbot 17:42
yoleaux2 11:11Z <samcv> diakopter: why did you lol wut notviki’s commit???
diakopter samcv: oh, I was just lolwut about the long messages
notviki That's it? 17:43
heh
And I layed awake at night, thinking my code was off :)
17:45 domidumont joined 17:48 domidumont joined
diakopter notviki: I guess I was surprised dalek survived the long message 17:51
notviki heh 17:52
[Coke] .u { .uniname ~~ / 'DOUBLE-STRUCK'/ } 17:58
yoleaux2 U+0020 SPACE [Zs] ( )
U+0027 APOSTROPHE [Po] (')
U+002D HYPHEN-MINUS [Pd] (-)
[Coke] u: { .uniname ~~ / 'DOUBLE-STRUCK'/ }
whoops, not the best window for that. sorries 17:59
timotimo i could have sworn we already cleaned up log slots in spesh ... 18:16
diakopter lizmat: another thing that could use p6ified (last I checked) is the dalek 18:23
and it's definitely not performance-constrained, so it's not like it's a serious risk of becoming unusable (like a prospective port of ucd2c.pl might be) 18:24
notviki Yeah, I can p6ify dalek 18:25
dalek you hear that! People are talking about replacing you!
18:27 TimToady joined
diakopter ohai 18:27
geekosaur .oO { P6-IN-ATE! }
diakopter notviki: I'm pretty sure looking at dalek's source wouldn't help you any; but do you know where it is? 18:32
notviki Yeah 18:33
@hack:/home/dalek/dalek 18:34
dalek: karma 18:35
dalek: help
Well, I guess I'm not looking to reinvent all of possible features it has, but just what we need. I'm guessing watching for commits and reporting them is one... anything else?
[Coke] we have so many bots, I think we've already decided one-feature-per-bot is fine. :) 18:36
and yes, I think that's dalek's one thing.
notviki OK. Then Tuesday we'll have a new dalek 19:02
19:10 Zoffix_ joined
notviki Excep I'll call it "Geth" :) 19:12
masseffect.wikia.com/wiki/Geth
timotimo that's a cute idea
i know that reference
geekosaur or go with the similar thing in the original universe... cybermen >.> 19:15
timotimo cyber cyber cyber cyber 19:17
samcv notviki, the diakopter’s mystery is over 19:29
yoleaux2 18:24Z <notviki> samcv: what do you think of github.com/rakudo/rakudo/pull/990 can you merge it if it looks fine?
samcv will look
i don't really like how we specify all the zero value glyphs :\ but otherwise i am not opposed to it at all 19:34
notviki samcv: yeah me neither :)
samcv: MasterDuke .ask'ed TimToady for an opinion too... via the bot
samcv m: "0٠۰߀०০੦૦୦௦౦೦൦෦๐໐༠၀႐០᠐᥆᧐᪀᪐᭐᮰᱀᱐꘠꣐꤀꧐꧰꩐꯰０𐒠𑁦𑃰𑄶𑇐𑋰𑑐𑓐𑙐𑛀𑜰𑣠𑱐𖩠𖭐𝟎𝟘𝟢𝟬𝟶𞥐".comb.».unival.say 19:35
camelia rakudo-moar dd5759: OUTPUT«(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0)␤» 19:36
samcv m: "a".unival.say
camelia rakudo-moar dd5759: OUTPUT«NaN␤»
samcv still i don't like that part. at all specifying them
notviki m: "༳".unival.say 19:37
camelia rakudo-moar dd5759: OUTPUT«-0.5␤»
notviki neat
m: say "༳" ~~ /\d/ 19:38
camelia rakudo-moar dd5759: OUTPUT«Nil␤»
samcv also why don't we just check unival on it… or create some character class internally for one number value? 19:40
idk i don't really like having to specify all those values. i think that's the wrong way to do it 19:41
dogbert17 jnthn: about the free-spesh-log-slots branch, I checked it out and tried both htmlify.p6 and the RT code example. Maybe that's not the right way to do it because I can't see any improvements in memory usage. 19:57
I'm still unable to build the docs with htmlify.p6 :( MoarVM panic: Memory allocation failed; could not allocate 1880616 bytes 20:02
samcv dogbert17, can't build it at all? or can't build unless you set the thread level to 1?
dogbert17 samcv: isn't 1 the default? 20:03
samcv maybe
brb gonna logout login my laptop is slowing down 20:04
dogbert17 running htmlify under /usr/bin/time gives: 616.96user 27.90system 8:55.10elapsed 120%CPU (0avgtext+0avgdata 2576668maxresident)k ; 17904inputs+200680outputs (17major+7320835minor)pagefaults 0swaps 20:05
samcv: did you manage to speed up your laptop? 20:13
samcv no. i am going to reboot ;\
burb
20:21 nebuchadnezzar joined 20:30 zakharyas joined
samcv OpenGL compositing (the default) has crashed KWin in the past. 20:33
This was most likely due to a driver bug.
If you think that you have meanwhile upgraded to a stable driver,
you can reset this protection but be aware that this might result in an immediate crash!
Alternatively, you might want to use the XRender backend inst
ok so that is why it was acting so crappy :P
timotimo oh, instead of turning compositing off completely, it just fell back to software rendering 21:31
that's one way to do it ...
samcv uh it may have done it completely… cause it was pretty horrible 21:41
timotimo if you don't have compositing, it'll usually be fine 22:33
[Coke] dogbert17: yes, building the docs is a dog and has been for ages. 22:54
dogbert17 [Coke]: slow as a dog I can live with, a crash not so much 23:00
[Coke] works fine on my 16G laptop? (sheepish grin) 23:04
dogbert17 I only have 8 gigs on my six year old desktop but I suspect the problems occur because I'm running this stuff in a 32 bit VM 23:11

Powered by Cro and the Raku® Programming Language.

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

Thank you!