<< 11-12-2018 >>
00:00:35*krux02 quit (Read error: Connection reset by peer)
00:00:36*krux02_ joined #nim
00:01:54FromGitter<mratsim> you can use write only locks
00:02:50FromGitter<mratsim> there are plenty of more fine-grained locks: https://en.wikipedia.org/wiki/Readers–writer_lock
00:03:04FromGitter<mratsim> without going into lock-free and wait free data structure
00:03:23FromGitter<mratsim> (please note that I have absolutely no experience in those, everytime I tried I failed miserably :D)
00:03:32*krux02_ quit (Remote host closed the connection)
00:04:39*krux02 joined #nim
00:14:05FromGitter<arnetheduck> queues (lock-free or not) are harder to shoot yourself in the foot with thus better for most people, but even if you know how to use locking (which is rare), you'll quickly run into fundamental limitations like the lack of synchronization, the need to cover more than only the collection with the same lock etc.. take a hint from `java` that started strong with `Vector` only to go back to unlocked collections
00:14:47FromGitter<arnetheduck> lock-free queues are not that tricky once you learn the general principle of how they operate - they're just a little unusual compared you your everyday programming tasks
00:21:10*fthe joined #nim
00:24:40FromGitter<zacharycarter> gotcha - thank you for the explanations
00:30:35ftheany of you use nim-mode in emacs?
00:34:32FromGitter<zacharycarter> maybe krux02
00:34:52FromGitter<zacharycarter> https://www.schneems.com/2017/06/28/how-to-write-a-lock-free-queue/ - article I just stumbled upon while googling
00:44:50*abm quit (Quit: Leaving)
00:52:38*jakob0094 quit (Remote host closed the connection)
00:54:11*ftsf joined #nim
00:57:22*zachk quit (Quit: Leaving)
01:06:21FromGitter<zacharycarter> took a look at the hcr stuff - still not sure how to use it all :P looks neat though
01:06:37FromGitter<zacharycarter> if anyone needs a guinea pig to play around with the feature - I'd be more than willing :D
01:06:48FromGitter<zacharycarter> I just would need a little bit of hand holding initally
01:09:45*Tyresc quit (Remote host closed the connection)
01:13:14*krux02 quit (Remote host closed the connection)
01:16:40FromGitter<zacharycarter> can't get it to compile anymore either - get some strformat cannot 'importc' variable at compile time error
01:24:38*fthe quit (Ping timeout: 250 seconds)
01:59:00*gangstacat quit (Ping timeout: 252 seconds)
02:15:06*gangstacat joined #nim
02:36:59*snowolf quit (Ping timeout: 268 seconds)
02:37:41*snowolf joined #nim
02:52:47*kapil____ joined #nim
03:08:44*banc quit (Quit: Bye)
03:11:38*sagax joined #nim
03:12:08*snowolf quit (Ping timeout: 268 seconds)
03:18:13*d10n-work quit (Quit: Connection closed for inactivity)
03:18:54*snowolf joined #nim
03:25:36*banc joined #nim
03:45:27*dddddd quit (Remote host closed the connection)
03:53:16*literal quit (Ping timeout: 250 seconds)
03:58:23*ghost64 quit (Ping timeout: 245 seconds)
04:01:10*literal joined #nim
04:03:52FromGitter<gogolxdong> I found nim extension of vscode could format code layout automatically by accident. When did it take effect?
04:04:10FromGitter<gogolxdong> or I missed it all the time?
04:05:36*ghost64 joined #nim
04:15:45*endragor joined #nim
04:24:09*nsf joined #nim
04:38:30FromGitter<gogolxdong> Html compiled with karax hints ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c0f3f468b656e2b04f60d4d]
04:39:12FromGitter<gogolxdong> which used to work
04:50:14FromGitter<gogolxdong> new compiled js has this issue .
04:58:33*lritter quit (Ping timeout: 244 seconds)
04:59:14*lritter joined #nim
05:01:45*kapil____ quit (Quit: Connection closed for inactivity)
05:13:25*gangstacat quit (Ping timeout: 246 seconds)
05:28:59*gangstacat joined #nim
05:35:54FromGitter<gogolxdong> ah, karax plays with Nim stable version
05:49:05*lritter quit (Remote host closed the connection)
05:50:59*miran joined #nim
06:18:12FromGitter<zacharycarter> this works with the c backend, but not the cpp backend - https://gist.github.com/zacharycarter/cc0e1f40fd5f7df6c8d683c1543f7fdc
06:18:26FromGitter<zacharycarter> tried changing the importc pragma to an importcpp pragma
06:18:33FromGitter<zacharycarter> still not working
06:18:37FromGitter<zacharycarter> just segfaults
06:19:38FromGitter<zacharycarter> guessing it has something to do with 2 Nim GC's running
06:21:51FromGitter<zacharycarter> can't use `-d:useNimRtl` with the cpp backend either - I get some error about `getMemCounters`
06:47:40*shpx joined #nim
06:49:49*snowolf quit (Ping timeout: 268 seconds)
06:54:03*snowolf joined #nim
07:03:32*miran quit (Remote host closed the connection)
07:07:03*krux02 joined #nim
07:07:05*snowolf quit (Ping timeout: 268 seconds)
07:07:37*snowolf joined #nim
07:11:47*snowolf quit (Ping timeout: 250 seconds)
07:14:12*snowolf joined #nim
07:33:43Araqgogolxdong: can you report this regression?
07:50:11*snowolf quit (Ping timeout: 260 seconds)
07:53:08FromGitter<gogolxdong> ok
07:59:22*ftsf quit (Read error: Connection reset by peer)
07:59:48*ftsf joined #nim
08:05:40*ftsf quit (Ping timeout: 268 seconds)
08:08:30*zama_ joined #nim
08:09:11FromGitter<alehander42> Araq, I remember you agreed that adding `if` to variants would be a good solution for https://github.com/nim-lang/Nim/issues/3629
08:10:35*zama quit (Ping timeout: 250 seconds)
08:10:51*zama_ quit (Changing host)
08:10:51*zama_ joined #nim
08:10:58*zama_ is now known as zama
08:11:24ZevvFunny, I've been using Nim for a few months, but AoC is really getting me all through the language and touch parts I never touched before. Never needed 'parallel/spawn' before
08:13:09FromGitter<alehander42> AoC 11?
08:16:39Zevvyeah
08:17:04Zevv"needed"
08:17:54Zevvbrute forcing goes faster on a lot of cpus :)
08:25:44*shpx quit (Ping timeout: 244 seconds)
08:26:45FromGitter<narimiran> hah, i didn't even thought about using parallel — i've been thinking how to solve it in less brutish way :)
08:28:14FromDiscord_<technicallyagd> My first attempt was just brute forcing it while going to pee
08:28:25FromDiscord_<technicallyagd> it took 140s in total
08:28:54FromGitter<narimiran> hey @technicallyagd! i've been waiting to tell you yesterday — i've used 'unpack' for day10! it was such a joy to just do `<-`
08:29:07FromDiscord_<technicallyagd> Noice!
08:29:15FromGitter<narimiran> hmm, my brute force day11 takes 22 seconds!?
08:29:26FromDiscord_<technicallyagd> I am glad it's actually useful in some way
08:29:45FromGitter<narimiran> [spoilers] see here: https://github.com/narimiran/AdventOfCode2018/blob/master/nim/day10.nim
08:30:44FromDiscord_<technicallyagd> yeah that's how I used it as well.
08:32:26FromDiscord_<technicallyagd> I wished I had nested unpacking for day10 though
08:37:52FromDiscord_<technicallyagd> @narimiran hmm, I wonder what made your day11 solution so much faster than mine o.o? did you go from 1x1 to 300x300?
08:42:03FromGitter<narimiran> @technicallyagd yes, that's my outer-most loop, followed by ys, then xs
08:45:37FromDiscord_<technicallyagd> @narimiran haha, I think I found the culprit of mine.
08:48:07FromDiscord_<technicallyagd> yeah, now it finishes in 40s.
08:48:22FromGitter<narimiran> do tell
08:49:24FromDiscord_<technicallyagd> I was accidentally constructing sequence of indices within the inner most loop
08:51:09FromDiscord_<technicallyagd> not a good idea at all
09:02:44*floppydh joined #nim
09:15:43Zevvbut you're still brute forcing, right?
09:17:11ZevvAh ok, my flat version runs in 26 seconds, adding parallel/spawn reduces to 5
09:22:59*PMunch joined #nim
09:23:43Zevvnarimiran: I like the [x, y, vx, vy] <- line.findAll(re"-?\d+").map(parseInt)
09:28:47*ng0 joined #nim
09:35:50*whaletechno quit (Quit: ha det bra)
09:40:54*voice_ftp joined #nim
09:52:41PMunchYay, my AoC repo is up: https://github.com/PMunch/aoc2018
09:56:40ldlework:)
09:58:23FromGitter<narimiran> @Zevv yeah, i like it too :) we can use it thanks to @technicallyagd
09:59:36FromGitter<narimiran> @PMunch why are you separating the parts in two different files?
09:59:48PMunchWhy not?
10:00:28PMunchI've noticed that part2 often requires changes to what I did in part1, so to keep both I copy the file :)
10:06:34FromGitter<narimiran> ok, i get the logic. mine is reversed: ok, let's improve my initial code so now it works for both parts.
10:06:47*Vladar joined #nim
10:07:06FromGitter<narimiran> and for some tasks, all it takes is to add 3 lines to the original code
10:07:24PMunchYeah that's fair
10:20:40*sagax quit (Ping timeout: 250 seconds)
10:24:42FromGitter<gogolxdong> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c0f906a26de6f0822b80fd1]
10:27:30FromGitter<gogolxdong> http://ix.io/1vMD
10:27:43FromGitter<gogolxdong> Is this going to work?
10:52:29*snowolf joined #nim
10:55:14*dddddd joined #nim
11:15:40*stefanos82 joined #nim
11:16:31*nc-x joined #nim
11:29:18nc-xAraq: you there?
11:31:00Araqnc-x, hi
11:31:26nc-xThe reason for https://github.com/pragmagic/karax/issues/80 is the change in this function https://github.com/nim-lang/Nim/pull/9411/files#diff-255aac99e5eed78cd98b01e25c647f86L870
11:32:01nc-xI have a fix https://github.com/nc-x/Nim/commit/685a5544c4f319667c811b04128dc3f8f33a4230 but I have no idea if that is correct or not. Can you please take a look before I create a PR.
11:32:22Araqlooks good
11:32:26nc-xMy fix does fix the problem though and also does not fail any js tests.
11:32:34nc-xOkay thanks. I will create a PR then.
11:32:43Araqok, thank you
11:33:15Araqyay git does a GC run. and that hangs
11:33:41Araqinteresting how a man with a hate for GCs can come up with a system that collects garbage
11:34:36nc-xDone https://github.com/nim-lang/Nim/pull/9929
11:34:42*nc-x quit (Quit: Page closed)
11:35:20FromGitter<alehander42> :D
12:27:12FromGitter<zacharycarter> I've given up (again) on trying to get any type of plugin system working
12:27:37FromGitter<zacharycarter> `useNimRtl` doens't work - and I can get shard libs compiled in cpp using the custom namespace option to work either
12:27:40PMunchzacharycarter, with Nim <-> nim plugins?
12:27:46FromGitter<zacharycarter> yes
12:27:55PMunchYeah, it's been broken for a while
12:28:50PMunchgithub.com/nim-lang/Nim/issues/6886
12:29:59FromGitter<zacharycarter> think I'm going to pause on working on any project until hot code reloading / destructors are in working order
12:30:36FromGitter<zacharycarter> can't implement some of the things i wanted to try this time around
12:33:38FromGitter<zacharycarter> time to dust off C :P
12:33:44FromGitter<zacharycarter> or maybe I'll play with scheme some more
12:34:41PMunchSo no more zeal :( I was looking forward to play with it
12:35:51FromGitter<zacharycarter> I'm just not looking forward to writing it without destructor support then having to add destructor support later
12:36:12FromGitter<zacharycarter> and if I can't find a way to load plugins / hot load code - I can't make the compile server idea work
12:36:21FromGitter<zacharycarter> or user plugins either
12:36:45FromGitter<zacharycarter> I guess there's a lot of it I can still write - but I seem to be fighting the language more than anything else right now
12:40:59Araqplugin systems are like distributed systems.
12:41:10Araqthe trick is to not build them.
12:42:29FromGitter<zacharycarter> I know you don't like them :P
12:42:35FromGitter<zacharycarter> but we should still be able to build them
12:43:20FromGitter<zacharycarter> will the destructor runtime help alleviate the troubles Nim shared libs have with the gc Araq?
12:43:33FromGitter<zacharycarter> or does there need to be still another solution figured out for thoat
12:43:48AraqI dunno, the DLL tests are green
12:43:57Araqand use the GC.
12:44:11FromGitter<zacharycarter> well - I can get my example code to work using the C backend
12:44:16FromGitter<zacharycarter> it's the CPP backend where things fallapart
12:44:35Araqdestructors will help but bugfixes are always easier
12:44:41Araqbbs
12:44:43FromGitter<zacharycarter> and I was using the CPP backend - because of the C backend and the issue with static methods that rely on the GC
12:49:08FromGitter<zacharycarter> most modern game engines have plugin systems that users extend the engine in some way, and many of the engines use plugins internally
12:49:16FromGitter<zacharycarter> UE4 does this - I know Unity and Godot at least offer support for use plugins
12:49:17FromGitter<arnetheduck> @mratsim @zacharycarter http://www.1024cores.net/home/lock-free-algorithms and Dmitry Vyukov is the go-to resource for lock-free stuff
12:49:41FromGitter<zacharycarter> thanks @arnetheduck !
12:51:08FromGitter<mratsim> For lock-free inspiration I always look into the Crossbeam repo: https://github.com/crossbeam-rs/crossbeam
12:51:53FromGitter<mratsim> For example: https://aturon.github.io/blog/2015/08/27/epoch/
12:53:29FromGitter<mratsim> but it seems like they are back to using a GC :P - https://github.com/crossbeam-rs/rfcs/blob/master/text/2017-05-23-epoch-gc.md
12:53:43FromGitter<mratsim> (and a thread local one)
12:54:41FromGitter<arnetheduck> ah yeah, seen that.. the 1024 site is more educational, in the sense that it classifies and goes over the problems you typically have to deal with..
12:54:53FromGitter<mratsim> cool.
12:55:26FromGitter<mratsim> That’s one thing I’ve been always wondering to do distributed tree data structure updates.
12:55:49FromGitter<arnetheduck> that's possible? :)
12:55:59FromGitter<mratsim> In go (the game) they are dozens of papers about “leaf parallelism”, “tree paralellism”, “trunk parallelism"
12:56:06FromGitter<mratsim> depends on what your tree is used for
12:56:36FromGitter<mratsim> I was talking about monte-carol tree search, which builds a tree of probability that some play is a good play.
12:56:41FromGitter<mratsim> So it’s append only.
12:56:50FromGitter<mratsim> carlo*
12:57:04FromGitter<arnetheduck> well yeah, specially for probabilistic approaches, anything goes :)
12:57:23FromGitter<zacharycarter> searching for examples of `gc:none` on github - there are very few
12:57:24FromGitter<mratsim> and even if they are concurrent update, as long as it’s not in the exact same part of the tree, it does not matter.
12:57:44FromGitter<zacharycarter> and I don't see many - if any - of them doing much as far as memory allocation goes
12:57:47FromGitter<alehander42> are traditional go engines still heavily used, or neural network-based ones are the new mode?
12:57:53FromGitter<mratsim> people are always asking about gc:none, gc:regions ad c:stack, maybe write a wiki article about it ;)
12:58:09FromGitter<mratsim> @alehander42 ugh, NN go engine are the plague now.
12:58:31FromGitter<mratsim> People at the top amateur level started cheating so you cannot hold online competitions anymore.
12:58:38*Vladar quit (Remote host closed the connection)
12:58:41FromGitter<alehander42> I see, so it's like chess: we have an alphazero open source copy, called leela which is the most promising one
12:58:53FromGitter<mratsim> and you can have a bot in your phone, so now in live competition, you have to leave yourphone on the table if you get up.
12:59:00*Vladar joined #nim
12:59:10FromGitter<zacharycarter> @mratsim - well gc:regions and stack are the same thing
12:59:19FromGitter<mratsim> before you could just rise, walk around, take a coffee, and come back
12:59:20FromGitter<alehander42> hm, doesn't go have something like blitz? in online chess, people play mostly blitz and its harder to cheat for a very limited control
12:59:29FromGitter<zacharycarter> and I've gone through those now to try to work through the issues I've been running into
12:59:43FromGitter<mratsim> Blitz is usually seen as cheap and I agree
12:59:48FromGitter<zacharycarter> resorting to trying gc:none now - and everyone points to nimkernel
12:59:53FromGitter<zacharycarter> but I don't see much of anything there
13:00:34FromGitter<mratsim> I probably should give about 6 initial moves as handicap to my Blitz selft to balance the chance of victory :P
13:00:36FromGitter<alehander42> in traditional chess competitions too, but online the strongest playerbase is usually on blitz(exactly because of that): the other options are paid sites where you can make sure you play with actual humans/GM-s etc
13:00:57FromGitter<alehander42> but those are mostly for excellent players
13:01:29FromGitter<mratsim> In go you usually have fast time settings, about 1min/move, 30s is quite fast, 15s and below/move is blitz
13:01:58FromGitter<alehander42> yeah, blitz is problematic, but even the world championship is resolved by rapid(a bit slower blitz) last two times, so its getting more and more important
13:02:08FromGitter<alehander42> (rapid tiebreak)
13:03:52FromGitter<alehander42> in chess blitz you have usually 5min+3sec increment on move, so thats even less (around 10s for avg 40move game). but classical can take 7 hours
13:05:30PMunchAraq, krux02 actually disabled the GC part of the DLL test 13 days ago
13:07:06FromGitter<mratsim> In the past Go games used to be done over days or even months
13:07:21FromGitter<mratsim> You even had “best-of-30” games :P
13:08:51FromGitter<alehander42> yeah, it was the same with chess, later they became mostly containable in a day, but you had first-with-6 wins: and many draws. ⏎ so kasparov and karpov played like 40 games and finally karpov was too exhausted to continue
13:10:04*fthe joined #nim
13:10:53FromGitter<alehander42> actually he didn't want to stop, but the federation put a halt to it, however basically today you can have max 12 games and the last one had 12 draws: so this is prob'ly the biggest issue with it, go is better at the draw thing :D
13:17:26*dom96_w joined #nim
13:24:09FromDiscord_<technicallyagd> @Zevv yeah, that was my first attempt. I then found out about https://en.wikipedia.org/wiki/Summed-area_table on reddit
13:24:40FromDiscord_<technicallyagd> https://www.reddit.com/r/adventofcode/comments/a53r6i/2018_day_11_solutions/ebjogd7/
13:25:14FromDiscord_<technicallyagd> now my taks2 finishes in 8ms with `-d:release`
13:36:35stefanos82this latest update with hash 9bc4208706495a84808f779e3da58583328a112c is so slow
13:36:39stefanos82I wonder why
13:39:04FromGitter<arnetheduck> I use gc:none extensively while developing nlvm - just to get rid of that blob of gc code when analyzing bugs in generated code :) also, I've got 32gb of ram, 95% of all little command line applications I run would actually work fine without any deallocation
13:39:53FromGitter<zacharycarter> I think I'm just going to simplify my project to better fit Nim's default GC
13:40:10FromGitter<zacharycarter> so no plugins and will toss away the job / threading / hot code reloading stuff for now
13:40:15stefanos82this simple program http://paste.debian.net/1055328/ takes 3.50 seconds to execute
13:40:17stefanos82why?!
13:40:40FromGitter<zacharycarter> are you compiling in release mode?
13:40:47stefanos82no, in debug mode
13:40:53FromGitter<arnetheduck> > as long as it’s not in the exact same part of the tree, it does not matter ⏎ ⏎ that's cheating :)
13:41:36PMunchstefanos82, on my machine it was instant..
13:41:42PMunchIn debug mode as well
13:41:50*fthe quit (Ping timeout: 246 seconds)
13:42:01stefanos82PMunch: I have no idea why this happens...
13:42:23PMunchNim version?
13:42:31*endragor quit (Remote host closed the connection)
13:42:59stefanos82PMunch: the latest HEAD with hash 9bc4208706495a84808f779e3da58583328a112c
13:45:42*endragor joined #nim
13:46:27PMunchHmm, I'm on devel as well. Not quite that new though (and I'm afraid to try it now :P)
13:49:14FromGitter<zacharycarter> I'm about to try
13:49:43FromGitter<zacharycarter> I just updated to latest devel via choosenim
13:49:53*endragor quit (Ping timeout: 246 seconds)
13:49:57FromGitter<zacharycarter> ran instantly
13:50:49stefanos82I have no idea what's going on...
13:51:44FromGitter<zacharycarter> what os are you on?
13:52:01FromGitter<zacharycarter> and you're using the C backend - correct?
13:52:02stefanos82Debian testing 64-bit
13:52:06stefanos82yep
13:52:16FromGitter<zacharycarter> very strange...
13:52:17stefanos82it used to run instantly
13:52:26*snowolf quit (Ping timeout: 260 seconds)
13:52:31FromGitter<zacharycarter> have you tried restarting your machine?
13:52:43stefanos82nope
13:53:01stefanos82I have never had this issue before
13:53:11FromGitter<zacharycarter> not sure - it doesn't really make sense
13:53:19FromGitter<zacharycarter> you can always look at the C code that was generated
13:53:31FromGitter<zacharycarter> to make sure nothing fishy is going on - but it sounds like it's an environment specific hting
13:54:07FromGitter<zacharycarter> Araq: I'm focusing on strategy games for this engine btw
13:54:28FromGitter<zacharycarter> and I'm going to go with your suggestion - at least initially - and make the editor in-game
13:54:40FromGitter<alehander42> stefanos82, profile it
13:54:54stefanos82I have tested a simple echo "hello" in https://play.nim-lang.org/
13:54:56stefanos82Hint: operation successful (11716 lines compiled; 1.471 sec total; 22.293MiB peakmem; Debug Build) [SuccessX]
13:54:58FromGitter<zacharycarter> good idea
13:55:11FromGitter<zacharycarter> that's using a super old version of Nim I'm pretty sure
13:55:24FromGitter<zacharycarter> like 0.18.0
13:55:37stefanos82how to profile it then?
13:55:46stefanos82I have tried --hints:on --verbosity:2
13:55:50FromGitter<zacharycarter> https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html
13:55:55FromGitter<zacharycarter> you can use nimprof - if it works
13:56:01FromGitter<zacharycarter> or install valgrind and use that
13:56:12FromGitter<alehander42> oh man, i've used for i, e in children in Python and wondering 10 minutes why doesnt it work.. starting to forget I need `enumerate` there
13:56:55FromGitter<alehander42> @zacharycarter I've only used perf(not very experienced at profiling), is valgrind nicer for that? (i mostly know of its memory stuff)
13:57:16*snowolf joined #nim
13:59:05stefanos82I got this ../../../../../GIT_CODES/Nim/lib/system/profiler.nim(91, 23) Error: undeclared identifier: 'framePtr'
13:59:19FromGitter<zacharycarter> @alehander42 - I'm not sure - I just know it can profile
13:59:37FromGitter<zacharycarter> valgrind doesn't work well for me on macOS - and I haven't really been profiling much, mostly debugging memory issues with asan etc
13:59:58FromGitter<zacharycarter> valgrind might work fine for profiling on mac - memcheck doesn't work well though
14:00:14FromGitter<zacharycarter> stefanos82: you got that now? by using nimprof?
14:00:20stefanos82yes
14:00:26FromGitter<zacharycarter> okay so try valgrind
14:00:31FromGitter<zacharycarter> I'm not sure if nimprof works currently
14:12:55FromGitter<zacharycarter> so I know Nim has no `goto` - but how do you achieve the pattern where you have a set of common calls
14:13:07stefanos82@zacharycarter: any example to share if you don't mind about how to use valgrind?
14:13:28FromGitter<zacharycarter> like for instance in some init code - multiple if / else branches could potentially casuse you to want to terminate the app and call some cleanup logic
14:13:43FromGitter<zacharycarter> and traditionally - in C/C++ - you'd use a `goto` potentially
14:13:52PMunchblock and break might help
14:14:14FromGitter<zacharycarter> PMunch: but those can only be used inside some sort of looping construct right?
14:14:21PMunchNope
14:14:55FromGitter<zacharycarter> stefanos82: sure - step 1) compile the program you want to profile like so: `nim c --debugger:native --compileOnly foo.nim`
14:15:18FromGitter<zacharycarter> `valgrind --tool=callgrind -v ./foo`
14:15:43stefanos82@zacharycarter: I used nim --d:debug --lineDir:on --debuginfo --debugger:native c src/foo.nim
14:15:47PMunchzacharycarter, http://ix.io/1vNS/Nim
14:16:08FromGitter<zacharycarter> well --debugger:native I'm pretty sure takes care of --debuginfo and lineDir:on
14:16:16stefanos82cool
14:16:38FromGitter<zacharycarter> PMunch: I'm more interested in something like this though -
14:18:36FromGitter<zacharycarter> https://gist.github.com/zacharycarter/bde2ea52c99be079214ff6e374ce38c5
14:19:00FromGitter<zacharycarter> stefanos to inspect valgrind output, you may also want to install KCacheGrind
14:19:57FromGitter<zacharycarter> PMunch: I think Nim could use something like this
14:20:48FromGitter<zacharycarter> I guess I can just importc setjmp?
14:21:52PMunchThis is how you do that in Nim: http://ix.io/1vNU/Nim
14:22:14PMunchI asked Araq about this once, he said that it would make control-flow analysis much harder
14:22:23FromGitter<alehander42> but the point is that you'll get to after bar anyway
14:22:30PMunchWhich is (at least one of the reasons) why Nim doesn't have it
14:22:40FromGitter<alehander42> but I agree with Araq, flow analysis sucks with goto, so happy I didnt have to fight it
14:22:44PMunchalehander42, so? You do that with goto as well..
14:23:05stefanos82@zacharycarter: I have generated a callground.out.<xxxx> file and opened it with kcachegrind
14:23:12stefanos82I have no idea what to look lol
14:23:13FromGitter<alehander42> yeah, my point is that you porbably also set a flag in both cases anyway
14:24:33FromGitter<alehander42> and if you think about it, in this case, why use block and break at all..
14:24:43FromGitter<alehander42> I think the point of block/break is when you have several nested loops
14:24:59FromGitter<alehander42> to easily break on top
14:25:02FromGitter<zacharycarter> yeah - that's where I see it being useful
14:25:05FromGitter<zacharycarter> breaking out of a nested loop
14:25:15FromGitter<zacharycarter> I'm looking for like - you have a bunch of init logic
14:25:48FromGitter<zacharycarter> and certain calls during that init logic can produce unrecoverable errors - and when one of those is encountered - you want to go to a common section of code to execute some shutdown logic - like closing file handles or something
14:26:05PMunchWell you can use defer
14:26:07FromGitter<zacharycarter> and you don't want to have to re-write that shutdown logic in every place where you've encountered an unrecoverable error
14:26:16FromGitter<zacharycarter> never
14:26:17FromGitter<zacharycarter> :P
14:26:22FromGitter<alehander42> well, you can always .. raise a custom exception which you only handle on top level I guess?
14:26:28PMunchOr do something like this: http://ix.io/1vNY/Nim
14:27:31FromGitter<zacharycarter> I guess I need to get on board with exceptions
14:27:35FromGitter<zacharycarter> the template idea isn't bad either
14:28:00FromGitter<narimiran> @stefanos re: "Error: undeclared identifier: 'framePtr'" this is because of some .nims file you have in that folder
14:28:27FromGitter<alehander42> @PMunch that's nice
14:28:30FromGitter<narimiran> see here: https://github.com/nim-lang/Nim/issues/8991
14:28:37FromGitter<alehander42> but still what about different calls
14:28:51FromGitter<alehander42> is there a reason to not use exceptions for your usecase @zacharycarter
14:28:58stefanos82@nariniran: ah I see
14:29:06FromGitter<zacharycarter> I just am not used to / don't like them
14:29:23FromGitter<alehander42> you want to bubble up an error and do stuff on top level based on it: that's literally where they excell
14:29:24FromGitter<zacharycarter> I'm used to handling errors in a C style
14:29:33FromGitter<zacharycarter> yeah - sounds like I need them
14:29:50*snowolf quit (Ping timeout: 250 seconds)
14:29:53FromGitter<zacharycarter> I used them when I programmed in Java - which I try to actively not do anymore
14:29:54FromGitter<alehander42> well, you can still use error results, but use an exception only for "fatal" errors
14:30:00FromGitter<alehander42> similar to go
14:30:03FromGitter<zacharycarter> good idea
14:30:59*krux02_ joined #nim
14:31:36*krux02 quit (Read error: Connection reset by peer)
14:34:07stefanos82@narimiran: the .nims file contains switch("out", "bin/foo"), but I used to generate "bin/foo" with nim.cfg; can you remind me the option please?
14:34:14stefanos82so I can remove the .nims file?
14:39:51stefanos82nevermind, I figure it out
14:40:07stefanos82now, how to profile based on the generated .ndi files?
14:43:25stefanos82lol I'm losing my mind here...be right back
14:47:59FromGitter<zacharycarter> stefanos82: might be a good idea to read a tutorial on valgrind
14:48:12FromGitter<zacharycarter> it's not the easiest of tools to use - especially if you're new to software profiling
14:49:50*krux02_ is now known as krux02
14:56:27*snowolf joined #nim
14:57:24stefanos82@zacharycarter: yeah, I haven't profiled anything before
14:58:04stefanos82anyway, I'm off for now with Nim; I cannot figure out what's going on
14:59:03FromGitter<zacharycarter> stefanos82: ping me when you're back around and maybe I can help some more
14:59:25FromGitter<zacharycarter> might be difficult without access to a debian box but I can always create a vm
14:59:27FromGitter<zacharycarter> maybe...
14:59:29FromGitter<narimiran> @stefanos82: doesn't it work when you remove .nims file? what is the problem?
15:00:51*snowolf quit (Ping timeout: 252 seconds)
15:03:17stefanos82@narimiran: I have managed to generate ndi files but profiling them generates an empty results text file
15:04:05stefanos82all I want is to see what causes delay on compilation and execution of a binary file
15:04:12stefanos82it used to do such thing instantly
15:04:53PMunchIs there a way to have overlap between two branches of an object variant?
15:04:56FromGitter<narimiran> wait, are you using nimprof or something else?
15:06:12PMunchI have three cases, which are almost a standard Venn diagram of fields
15:06:59FromGitter<alehander42> @PMunch what is your usecase
15:08:00PMunchTrying to represent this: web3js.readthedocs.io/en/1.0/glossary.html#glossary-json-interface
15:09:36PMunchSo function and constructor share all but the "name" field, and event share type and name, but is otherwise different
15:09:49FromGitter<alehander42> @PMunch, honestly I think shared fields might be the best solution(if I understand correctly)
15:10:09PMunchSo function and event share the type and name field
15:10:16PMunchShared fields?
15:10:45FromGitter<alehander42> https://github.com/nim-lang/Nim/issues/3629
15:10:58FromGitter<alehander42> I just asked Araq today about it, I also want to have it for other goals
15:13:52FromGitter<alehander42> so e.g. you'll define `type` for the three of them, `name` for function and event, and the other fields for function and constructor
15:14:31FromGitter<alehander42> (I prefer the other way, where you define `function`: fields `event`: fields(some overlapping) etc , but Araq doesnt like it for some reason )
15:14:53PMunchI prefer Araq's syntax
15:15:13PMunchBut Varriount has a point that it diverges from the normal case statement..
15:16:24stefanos82@narimiran: I used both nimprof and then valgrind
15:16:32FromGitter<alehander42> yes, also if you think about how adt-s work in most languages, the other syntax makes more sense, e.g. its almost like Function(type, name, b) Event(type, name, c) Other(type, other, e)
15:17:18FromGitter<alehander42> but I don't care, Araq's ordering is fine (one can always have a custom macro for that)
15:17:20FromGitter<zacharycarter> is there any way to get targetOS and targetCPU at compile time? like inside of a nimble file?
15:17:43FromGitter<alehander42> @PMunch also, he proposed to use `if` instead of `case` for such shared cases for that reason
15:17:51FromGitter<alehander42> but not in the issue
15:18:02FromGitter<mratsim> @zacharycarter there are hostCPU const
15:18:12FromGitter<mratsim> and for OS you have to use when defined
15:18:25FromGitter<mratsim> there are wiki pages about it but incomplete
15:18:37FromGitter<mratsim> for example I couldn’t find how Nim detects iOS
15:18:53FromGitter<zacharycarter> thank you @mratsim
15:19:54*snowolf joined #nim
15:24:43*tribly is now known as und
15:25:11*und is now known as tribly
15:26:58dom96_wSomeone just sent me a lot of Nim stickers because they didn't need them :O
15:27:50PMunchDidn't need them? Where did they get them from in the first place :P
15:29:34FromGitter<mratsim> Just in time for FOSDEM
15:31:15stefanos82in other words, they are rejecting the language?
15:33:13FromGitter<alehander42> I just imagine dom96 going back in his home and opening the door to be smashed by a mountain of stickers (like the old "letters after 5 years" scenes in movies)
15:33:34stefanos82lol
15:33:38stefanos82that was a good one
15:34:45*nsf quit (Quit: WeeChat 2.3)
15:38:31PMunchHmm, I should start looking at plane tickets to FOSDEM
15:39:19FromGitter<mratsim> I should start to look for train tickets but with my French luck there will be a strike :D
15:40:25PMunchHmm, I wish we had trains
15:40:35PMunchThey really are the most comfortable way to travel
15:40:43PMunchWould take forever to get anywhere from here though :P
15:41:20Araqalehander42: again, if we support sum types like the others, we can use the same syntax.
15:41:35Araqbut we don't support them like the others so the syntax should be different
15:42:02FromGitter<alehander42> @mratsim french trains were great, jealous!
15:42:16FromGitter<alehander42> Araq, is this only because of no full compile time field checking?
15:42:38FromGitter<mratsim> how do you do compile-time type checking with run time types? :D
15:43:28FromGitter<alehander42> eh, you require `.<kindField> == ` or `<kindField> in ` or `init with this kind`
15:43:35FromGitter<alehander42> and narrow the type in the branch
15:43:42FromGitter<alehander42> the same as with nilable types
15:43:42Araqyes, "only because" we do it completely differently
15:44:05Araqunguarded field access is bad but the compiler uses it *everywhere*
15:44:54*kapil____ joined #nim
15:46:18FromGitter<alehander42> Araq, eh, I guess it mostly uses it when it passes a node to another function which doesn't check the field again?
15:48:15Araqwho knows. your words make sense but it could also be more complex invariants
15:51:25Araqand I don't mind {.fixCaseObjects: on.} or {.notNilWorksNow: on.} but fixing what we have is more important than adding more of the broken stuff like "if in object declarations"
15:52:23FromGitter<alehander42> well, fixing notnil or similar is "fixing what we have"
15:52:34Araqyes, exactly
15:52:40Araqbut we don't have "if in objects"
15:53:06FromGitter<alehander42> well, it can be just `case`
15:53:17FromGitter<alehander42> one can always argue that case objects also require fixing
15:53:36FromGitter<alehander42> everybody that uses them sooner or later tries to share fields
15:54:00Araqreally? how so? Rust doesn't support field sharing
15:54:07Araqnor ML, Haskell...
15:54:16Araqor any other language with ADTs
15:54:49FromGitter<mratsim> Haskell allows fields of th same name
15:54:49FromGitter<alehander42> eh, they all do
15:54:54FromGitter<alehander42> but its like
15:55:03FromGitter<alehander42> they usually dont require actual field names
15:55:27Araqfield of the same name != field sharing
15:55:54dom96_wPMunch: mratsim: now that I live in London I'll be able to take the train too :D
15:55:56FromGitter<alehander42> ah, so by field sharing, you mean literal field memory sharing
15:56:07FromGitter<alehander42> I never `reset` so I don't care for that one
15:56:08Araqthis discussion suffers from a total confusion of terminology
15:56:09FromGitter<mratsim> I think people requested to be able to use the same name
15:56:16FromGitter<mratsim> fields of*
15:56:20dom96_wstefanos82: no, they aren't rejecting Nim. They just bought a lot of stickers and didn't have a need for them all
15:56:24FromGitter<mratsim> I didn’t see any mention of field sharing
15:56:37stefanos82dom96_w: ah I see
15:56:42Araqmratsim: The original RFC was about real field sharing iirc
15:56:46FromGitter<alehander42> Araq, you said `you can easily see the "shared" aspect of the fields.`
15:56:56FromGitter<alehander42> so I probably used sharing incorrectly after that
15:56:59FromGitter<alehander42> but that's what I meant
15:57:10dom96_wStrangely the stickers look higher quality than the ones I bought a while ago... and they are from the same company
15:57:18Araqwell I always assumed people want real field sharing, not merely using the same name for different field offsets
15:57:41FromGitter<alehander42> hm, I doubt it
15:57:54Araqotherwise it's just a minor annoyance, you have to come up with unique names
15:58:03FromGitter<alehander42> but this sucks so much
15:58:08FromGitter<alehander42> why would the language make me do it
15:58:14FromGitter<alehander42> when it's very easy to support it
15:58:22Araq^^ becaues the field accesses can be unguarded
15:58:35Araqecho obj.ambiguousFieldNameHere
15:58:48AraqI dunno what's hard to understand about it
15:59:22Araqand what is easy to support about that? we have to change how obj.field works
15:59:46dom96_wDidn't we already decide what will happen with this?
16:00:03dom96_wi.e. same names are allowed as long as their types don't change between branches
16:00:07Araq"You can only use 'field' in a pattern matching context here because it is ambiguous. Too bad we don't have pattern matching in the language."
16:00:10FromGitter<alehander42> well, if there is ambuguity AND the field is unguarded, this is an error
16:00:19FromGitter<alehander42> and you require the user to guard it
16:00:37FromGitter<alehander42> this wouldnt affect the compiler
16:00:41FromGitter<alehander42> for example
16:00:46FromGitter<alehander42> and all existing variant objects
16:01:04FromGitter<mratsim> I agree with dom, same name as long as the same type is used.
16:01:15FromGitter<mratsim> though in terms of memory layout I don’t know what is happening.
16:01:20PMunchHow do you get the string name of an identifier in a template again?
16:01:30AraqastToStr(), PMunch
16:01:45PMunchAh thanks
16:01:53FromGitter<mratsim> only works in template by the way, otherwise you get your parameter ident
16:02:59FromGitter<alehander42> Araq, you dont have to include `pattern matching` in the error message, `have to check for <kind field name> before using it with if` is sufficient
16:03:19Araqdom96_w, following this path implies never to have ML-like union types
16:03:31Araqso the discussion is open again
16:03:34FromGitter<alehander42> or another option is to share it directly in the object indeed:
16:03:50FromGitter<alehander42> is the issue here that it might make the object size bigger
16:03:55dom96_wAraq: is that what we want? Nim hasn't been designed to be ML-like and it might be too late to steer it that way
16:04:29Araqdom96_w, well many people seem to really want that.
16:04:37dom96_wSurely some clever macro can be created to get ML-like unions ;)
16:05:11Araqyeah but that arguments cuts both ways
16:05:11Zevvdom96_w: should I file a new issue for the "let a = [ int ]" -> Unhandled exception
16:05:33dom96_wZevv: if the compiler crashes then of course
16:05:51*narimiran joined #nim
16:05:53AraqI can also say "If you need field name sharing, use a macro"
16:08:08Araqand why would I want to use the same name for two different things?
16:08:10PMunchhttp://ix.io/1vOm/Nim <- "Solution"
16:08:29dom96_wIt's never two different things
16:08:55dom96_wThere are often cases where I want a field to be part of multiple "kinds" except one
16:08:58dom96_wI can't do that
16:09:11dom96_wI can only share it with one kind or all of them
16:09:24Araqok but then you argue for field sharing, not merely field *name* sharing
16:09:46dom96_wfield name sharing is a good compromise, for now at least
16:09:55Araqbut how so? :-)
16:10:21AraqI think it only leads to confusing code
16:11:38krux02arnetheduck: process killing is a form of GC
16:12:02krux02eh, again, wrong scrolling and I made an out of context comment
16:12:04krux02sorry
16:12:23FromGitter<alehander42> so basically field sharing wouldn't be optimal for a: A only if for all unions ⏎ A > sizeof(A_Union_with_A) - size(A) ⏎ A > sizeof(A_Union_other)
16:13:59FromGitter<alehander42> no, bollocks, it's always optimal
16:14:19FromGitter<alehander42> well in this case I agree, direct field sharing might be also ok
16:24:07*floppydh quit (Quit: WeeChat 2.3)
16:27:36FromGitter<alehander42> well obviously there is some overhead in some cases, i am horrible at math
16:27:49FromGitter<alehander42> btw Araq: I have another idea
16:28:34FromGitter<alehander42> does the compiler optimize away some branches at least locally (I guess maybe gcc does it?)
16:29:11FromGitter<alehander42> so e.g. if you have ⏎ if a.kind == ..: ⏎ .. ⏎ .. # not touching a.kind ⏎ ..... if a.kind == the same: ... [https://gitter.im/nim-lang/Nim?at=5c0fe5d728907a3c7b034db3]
16:30:05FromGitter<alehander42> (the same with case a.kind / switch in C)
16:31:52FromGitter<alehander42> if such an optimization happens somewhere, one can have a template that expands `aSharedName` to `aSharedName<id>` which will actually be equally fast in most cases (and if it's not, it will be equivalent to a much needed assert)
16:35:04Araqthe C backends do these optimizations
16:36:22FromGitter<alehander42> if that's so, I can have a macro which maps `aFieldName` to several internal fields and exposes a template for accessing it
16:42:26Araqyup
16:43:44Araqbut where is the fun in that? Let's instead push for more RFCs, more language features and more regressions
16:43:51Araq;-)
16:45:55FromGitter<alehander42> well, I always knew that, but I didn't realize in many cases it wouldn't actually lead to slower access
16:46:33FromGitter<alehander42> it still seems as a feature that should be builtin tho: but that's always a subjective language design decision
16:48:23PMunchHmm, issue with my "fix" it won't see the field as a var. And as such can't call eg. add on it..
16:49:53*PMunch quit (Remote host closed the connection)
16:55:54FromGitter<zah> I think the preferences of the ML-crowd are misguided. The extra flexibility in case objects is useful sometimes
16:58:03FromGitter<alehander42> what is extra flexible in case objects?
16:59:38FromGitter<zah> the shared fields you were discussing
17:01:14FromGitter<alehander42> I love shared fields, I think the original issue was for "partially" shared fields tho: fields that are available e.g. only in A and A0 cases, but not in A1
17:01:38FromGitter<zah> that's what I meant too
17:02:08FromGitter<alehander42> well, this is not directly possible right now
17:02:51FromGitter<alehander42> that's less flexible
17:03:53FromGitter<zah> yes, and I meant that allowing these partially shared fields is useful
17:04:47FromGitter<alehander42> ah, I always thought this is the more ML-like opinion
17:08:44*Ven`` joined #nim
17:13:12*Ven`` quit (Ping timeout: 250 seconds)
17:13:15*Trustable joined #nim
17:19:39*nc-x joined #nim
17:20:10FromGitter<arnetheduck> what's the status of `{.pure.}` and enums? manual says they make a difference but @mratsim mentioned they had been.. made noops?
17:23:38FromGitter<alehander42> something like this(adapted patty's macro, but applicable to more traditional case-like macro) would be the metaprog alternative for shared names https://gist.github.com/alehander42/0ca59871568568540a899bfac4a0adfc
17:24:05*Tyresc joined #nim
17:25:14FromGitter<mratsim> @arnetheduck https://github.com/nim-lang/Nim/issues/8066#issuecomment-415323980
17:25:18FromGitter<mratsim> enjoy the read
17:26:11FromGitter<mratsim> oh maybe it does something: https://github.com/nim-lang/Nim/commit/2f7b979e384ff6cc750e123939401a72c3f59093#diff-8af935b2312d6a0974d7f32b58bda4f2R981
17:26:23FromGitter<mratsim> but that something changed and I thought it was removed altogether?
17:26:24nc-xnarimiran: all the known issue regarding the nims file would be fixed soon. The problem was that when you have a nims file compiler adds the define for nimscript and tries to execute the nims file. But along with it, it also passed other arguments like --profiler:on to the nimscript execution. Now the codebase is filled with when defined(nimscript) and when defined(profiler) and both are mostly exclusive cases that is can't be run togethe
17:27:11nc-xSo the compiler was choking on the nims file and never reached to compile the nim file
17:27:29nc-xsame case is with -d:nodejs as reported on some github issue
17:27:40nc-xnodejs and nimscript can't be together
17:28:47nc-xSo the best fix I found is to undefine these problematic defines if they are passed as arguments while processing nimscript and later during processing of nim file use those arguments
17:29:07nc-xI have a fix almost ready. Will complete it tomorrow.
17:30:08nc-xAraq: does the fix sound good to you? or is there a better way it should/could be done?
17:30:49FromGitter<arnetheduck> @mratsim I'm kind of not a fan of every enum value being prefixed (`abcXxx`, `abcYyy`) - which is the practical outcome of enums not having their own scope - though in truth, I put `pure` there yesterday because the surrounding code had it :)
17:31:53FromGitter<mratsim> you only have to qualify if it’s unclear now. In the past {.pure.} forced qualifications
17:32:13FromGitter<mratsim> I still think it should be renamed to {.qualified.} or removed.
17:32:34FromGitter<mratsim> and import qualified foo is clearer than from foo import nil
17:32:50FromGitter<mratsim> when we want to force module namespace
17:33:51FromGitter<arnetheduck> yeah, but that stinks because it means if I add an import, code breaks.. more importantly, if someone adds something to their unrelated module, my code breaks.. not a good situation if you want a thriving eco-system of library code reuse
17:35:27*snowolf quit (Ping timeout: 264 seconds)
17:37:10narimiran[m]nc-x great to hear you already have the fix!
17:37:53*vlad1777d joined #nim
17:45:38*stefanos82 quit (Remote host closed the connection)
17:47:17*jjido joined #nim
17:53:51Araqnc-x, sounds good. We could also give nimscript its own system.nim ...
17:56:23Araqarnetheduck: a new version of a library always means some effort on your part. I don't see a way around it that doesn't amount to fooling oneself.
17:57:05Araqfor example, the proc foo that used could have grown a new default parameter. Not too bad, right? Except when you used the proc as a first class object.
17:57:32FromGitter<arnetheduck> no it doesn't, as long as it only adds stuff (which is a pretty common scenario). unless of course, the language makes it impractical to insulate yourself from additions
17:57:40Araqsolution: Remove default parameters from the language (?)
17:58:27Araqoverloading has similar problems. so lets better remove that feature too.
17:59:22Araqand if I add new public fields to an object that too can break user's code
18:00:20FromGitter<arnetheduck> well, what you're basically saying is "there are no safe spaces in nim that allow frictionless upgrades" - which is in line with what I said: it hampers the development of a thriving library eco-system
18:01:51Araqa property that Nim shares with most other languages out there.
18:02:05FromGitter<arnetheduck> but for enums, it's kind of minor.. I find it more annoying with `import`
18:05:21*nc-x quit (Ping timeout: 256 seconds)
18:07:07AraqI have yet to experience any problems with it.
18:20:04*nsf joined #nim
18:33:53*kapil____ quit (Quit: Connection closed for inactivity)
18:46:01*dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:12:17*zachk joined #nim
19:13:03*zachk quit (Changing host)
19:13:03*zachk joined #nim
19:35:20*jjido quit (Ping timeout: 250 seconds)
19:39:36*snowolf joined #nim
19:44:21*PMunch joined #nim
19:50:08*nsf quit (Quit: WeeChat 2.3)
20:04:47*voice_ftp quit (Ping timeout: 240 seconds)
20:06:13*voiceftp joined #nim
20:06:38*Trustable quit (Remote host closed the connection)
20:34:17*shpx joined #nim
20:35:32*banc quit (Quit: Bye)
20:37:16*snowolf quit (Ping timeout: 260 seconds)
20:39:05*snowolf joined #nim
20:45:26ZevvWhy does asyncHttpServer demand my handle proc is gcsafe, even when threads are not enabled?
20:45:52Araqmostly because we want --threads:on to become the default
20:45:55Zevvit's a bit of a nuisance, either I get warnings all of the time, or I have to declare any data that is used by the http handler as thraedvar
20:46:12Araqwell yes. or you pass your data around via parameters
20:46:12ZevvI understand, but the semantings of handling things like http in a threaded context is a pita
20:46:24Araqwhich is almost universally regarded good style
20:46:33*banc joined #nim
20:47:33*narimiran quit (Ping timeout: 245 seconds)
20:47:55Zevvgood style if you are doing threads. But in a context where I know everything is single threaded async, isn't it bettery style to just have things the obvious and simple way?
20:48:49ZevvI'm getting tangled up mixing channels and async stuff
20:49:06*lritter joined #nim
20:49:33Zevvanywas, having threads enabled by default is indeed a good reason
20:49:38Zevvso I'll have to cope with that.
21:02:45*Snircle_ joined #nim
21:03:28*Snircle quit (Read error: Connection reset by peer)
21:05:08*snowolf quit (Ping timeout: 268 seconds)
21:18:55*Vladar quit (Remote host closed the connection)
21:23:09*voiceftp quit (Read error: Connection reset by peer)
21:23:30*voiceftp joined #nim
21:26:32FromGitter<arnetheduck> @Zevv https://github.com/nim-lang/Nim/issues/9878 is the place to raise concerns.. I'm almost surprised it got that much support ;)
21:28:24ZevvI'm all for it. If there are any issues arising from using threads it is better to catch and solve those early then to postpone and hide them in single threaded systems.
21:28:57Zevv:thumbs-up:++
21:29:15*PMunch quit (Remote host closed the connection)
21:30:23ZevvFunny side note: I wondered how handling shared data is done in Jester, so I took Dom's example from the Nim book. Guess what warning came up :)
22:09:18dom96heh, just replied to your issue :)
22:09:28dom96Delegating to Araq, nothing interesting :P
22:11:23*ng0 quit (Remote host closed the connection)
22:49:53*noonien joined #nim
22:58:24*snowolf joined #nim
23:00:02*shpx quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:05:11*ftsf joined #nim
23:09:59*fthe joined #nim
23:13:16*shpx joined #nim
23:21:26*fthe quit (Ping timeout: 246 seconds)
23:39:13*fthe joined #nim
23:46:36*krux02 quit (Remote host closed the connection)