<< 23-03-2019 >>
00:00:53*abm quit (Ping timeout: 245 seconds)
00:02:00FromGitter<arnetheduck> fwiw, the first time I tried `Channel` (to simplify testament), it crashed with some memory issue on a trivial usage.. I would not consider it.. stable / ready-for-use
00:02:03*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:03:28FromGitter<mratsim> On my side I tried the "parallel" statement but couldn't prove something so couldn't compile a parallel sum
00:03:38*a__b__m joined #nim
00:07:08*a_b_m quit (Ping timeout: 250 seconds)
00:11:48*NimBot joined #nim
00:12:18ryukopostingpost code?
00:13:46FromDiscord<Avatarfighter> sure one second
00:14:07FromDiscord<Avatarfighter> https://hastebin.com/aguwakosad.js
00:14:57FromDiscord<Avatarfighter> binio is my custom module https://github.com/riderfighter/binio
00:17:34FromDiscord<Avatarfighter> the contents of the file "license.txt" is "ABtleUpoWTNScGRtRjBaV1FpT2lCbVlXeHpaWDA"
00:18:32ryukopostingthe normal way to open a file in nim would be let f = open("license.txt")
00:18:48ryukopostingtry that
00:19:17ryukopostingI've never seen the semantics you're using there, I'll do a little digging
00:19:33FromDiscord<Avatarfighter> I actually saw it used in the tutorial lol
00:19:33FromDiscord<Avatarfighter> https://nim-lang.org/docs/tut2.html#exceptions-try-statement
00:20:14ryukopostinghmm, weird
00:20:31ryukopostingyeah, what you have is definitely valid
00:21:07*a_b_m joined #nim
00:21:24FromDiscord<Avatarfighter> Alrighty a bit more debugging makes it seem as if the license.txt is not found by the compiled binary when ran, which is pretty weird
00:21:38ryukopostingOS?
00:21:57FromDiscord<Avatarfighter> macOS
00:22:09ryukopostinghmm
00:22:54ryukopostingso it is printing "file 'license.txt' not in... right?>
00:23:07FromDiscord<Avatarfighter> specifically its printing "Error: unhandled exception: cannot open: license.txt [IOError]"
00:23:37ryukopostingooooh wat
00:23:39FromDiscord<Avatarfighter> but the thing is, when i run it with "nim c -r FILE_PATH" it works correctly
00:24:28*a__b__m quit (Ping timeout: 250 seconds)
00:24:41ryukopostingcan you give me the stack trace?
00:24:54ryukopostingjust compile without -d:release or anything like that
00:25:01FromDiscord<Avatarfighter> alrighty one second
00:25:13*rnrwashere joined #nim
00:25:46FromDiscord<Avatarfighter> https://hastebin.com/xabujaxore.css
00:26:11*abm joined #nim
00:26:50ryukopostingI'm looking at authenticator.nim right now, yes?
00:26:54FromDiscord<Avatarfighter> yeah
00:27:09FromDiscord<Avatarfighter> i just named it something random lol
00:27:42ryukopostingtry running the executable from a terminal instead, idk how osx deals with path resolution
00:27:50FromDiscord<Avatarfighter> me neither lmao
00:28:11FromDiscord<Avatarfighter> same issue when ran from terminal
00:28:22*a_b_m quit (Ping timeout: 255 seconds)
00:28:36ryukoposting...hmm
00:29:01FromDiscord<Avatarfighter> yeah this is really weird
00:29:03ryukopostingwithout seeing your setup, and having not used osx for more than a 10 minute period in my life, I really can't help a whole lot
00:29:21*rnrwashere quit (Ping timeout: 250 seconds)
00:29:34ryukopostingtry `let f = open("license.txt")` instead, that's what I always do
00:29:45FromDiscord<Avatarfighter> I'll try that right now, last hope lol
00:30:07ryukopostingI know that that way of doing it definitely works on linux and win7
00:30:24FromDiscord<Avatarfighter> What is the way for linux?
00:30:35FromDiscord<Avatarfighter> that might be close to the way for macOS
00:30:40ryukopostingit's the same on all platforms, that's kind of nim's schtick
00:31:09ryukopostingbut I know that the way I showed works on my machines, which mostly run debian
00:31:39FromDiscord<Avatarfighter> ahh
00:31:42FromDiscord<Avatarfighter> ok weird
00:31:57FromDiscord<Avatarfighter> ill do some more research into this, hopefully I find something
00:32:02FromDiscord<Avatarfighter> Thank you for the help!
00:32:05ryukopostingis it working?
00:32:38ryukopostingcause the error you were getting is an IO exception, `open` isn't even returning, it's just throwing an error
00:34:43FromDiscord<Avatarfighter> No its not working sadly, I just tried manually writing the path to look through and even that didn't work
00:35:18ryukopostinghuh, odd. It's just really weird because `nim c -r` compiles and runs the program
00:35:45ryukopostingit's effectively the same thing as if I did `nim c foo.nim; ./foo.nim`
00:35:48FromDiscord<Avatarfighter> yeah, it works when i run it with `nim c -r` but not when i run in terminal lol
00:35:57ryukoposting`nim c foo.nim; ./foo` rather, lol
00:36:31ryukopostingthat's bizarre
00:36:38FromDiscord<Avatarfighter> this is such an interesting issue!
00:36:41FromDiscord<Avatarfighter> lol
00:36:56*krux02 quit (Remote host closed the connection)
00:37:06FromDiscord<Avatarfighter> even if I use os.getCurrentDir() and concat it with "/license.txt" that doesn't work lmao
00:37:19ryukopostingit honestly sounds like some weird macos thing
00:37:38FromDiscord<Avatarfighter> i believe it
00:37:40ryukopostingtry throwing in `echo getCurrentDir` at the top of the file
00:37:48FromDiscord<Avatarfighter> will do!
00:38:16FromDiscord<Avatarfighter> oh my gosh
00:38:20FromDiscord<Avatarfighter> i know what the issue is
00:38:26FromDiscord<Avatarfighter> i have the same issue as this in python
00:38:40ryukoposting?
00:39:22FromDiscord<Avatarfighter> So for some weird reason getCurrentDir actually returns the current directory of the terminal and not the file you're running itself
00:39:30FromDiscord<Avatarfighter> this is also an issue in python sadly lol
00:39:57ryukopostingthat's the normal behavior on linux
00:40:05ryukopostingand im pretty sure that's what windows does too
00:40:42FromDiscord<Avatarfighter> yeah but I believe that linux and windows are smart enough to know that to set the current directory to that of the running file instead of that of the terminal
00:41:02ryukopostingno, they don't do that
00:41:09ryukopostinghere, let me try really quick
00:41:31FromDiscord<Avatarfighter> then thats really, really weird :L
00:42:52FromDiscord<Avatarfighter> Do you know how to get the location of the running script itself instead that of the working directory?
00:45:54ryukopostingjust did a sanity check, the behavior you're seeing is definitely normal https://lewd.pics/p/?i=W4pG.png
00:46:59ryukopostinglemme take a look
00:47:26FromDiscord<Avatarfighter> yeah that's really weird, I know in python I can just do `os.path.dirname(os.path.abspath(__file__))` and voila its fixed but I have no idea about nim
00:47:36*rnrwashere joined #nim
00:47:45ryukopostingyeah that's kind of just the magic of a scripting language
00:48:48*rnrwashere quit (Read error: Connection reset by peer)
00:48:57FromDiscord<Avatarfighter> lol
00:49:21ryukopostingtry reading in command line arg 0
00:49:23*rnrwashere joined #nim
00:49:41ryukopostingif you're calling from a different directory, that will contain ../../foo/bar, for example
00:50:11ryukopostingso if you append arg0 to the current working directory, you can get the location of the currently-running executable
00:50:48Jjp137maybe this? https://nim-lang.github.io/Nim/os.html#getAppDir
00:51:10ryukopostingYES that ^^^^^^
00:51:15ryukopostingI forgot that was a thing
00:51:26FromDiscord<Avatarfighter> oh wow I didn't even see that
00:52:04FromDiscord<Avatarfighter> Yep! That fixed it, thank you both for your assistance!
00:52:37ryukopostingno problem, mate
00:52:42ryukopostingbest of luck!
00:53:33FromDiscord<Avatarfighter> You too!
01:03:07*theelous3_ quit (Ping timeout: 246 seconds)
01:12:34*stefanos82 quit (Remote host closed the connection)
01:14:17*rnrwashere quit (Remote host closed the connection)
01:19:45*rnrwashere joined #nim
01:24:51*rnrwashere quit (Remote host closed the connection)
01:28:58*rnrwashere joined #nim
01:32:35*rnrwashere quit (Remote host closed the connection)
01:33:50*rnrwashere joined #nim
01:38:32*rnrwashere quit (Remote host closed the connection)
01:42:48*rnrwashere joined #nim
01:45:33*rnrwashere quit (Remote host closed the connection)
02:16:04*abm quit (Quit: Leaving)
02:22:27*rnrwashere joined #nim
02:29:17*cgfuh quit (Quit: WeeChat 2.3)
02:42:03*lritter quit (Ping timeout: 246 seconds)
02:42:45*rnrwashere quit (Remote host closed the connection)
02:43:18*rnrwashere joined #nim
02:55:02*dddddd quit (Read error: Connection reset by peer)
03:05:55*banc quit (Quit: Bye)
03:27:49*banc joined #nim
03:27:49*I_Right_I quit (Write error: Connection reset by peer)
03:28:03*I_Right_I joined #nim
03:35:42*noeontheend quit (Ping timeout: 250 seconds)
04:16:19*chemist69 quit (Ping timeout: 252 seconds)
04:18:28*chemist69 joined #nim
04:21:16*rnrwashere quit (Read error: Connection reset by peer)
04:30:33*rnrwashere joined #nim
04:33:18*seni quit (Ping timeout: 244 seconds)
04:57:46*rnrwashere quit (Remote host closed the connection)
05:20:41*kapil____ joined #nim
05:29:25*vlad1777d joined #nim
05:41:24*rnrwashere joined #nim
05:46:44*Jjp137 quit (Read error: Connection reset by peer)
05:47:18*Jjp137 joined #nim
06:15:21*nsf joined #nim
06:15:35*rnrwashere quit (Remote host closed the connection)
06:27:55FromGitter<kdheepak> Hi all. I'm getting some odd behaviour when using SDL2 timers / callbacks when running it using `threads:on`. If I remove `threads:on` everything appears to work fine.
06:28:04FromGitter<kdheepak> Any suggestions for debugging this?
06:28:39FromGitter<kdheepak> The odd behaviour includes hanging and segfaulting.
06:39:45Araqkdheepak: don't use cast/ptr/addr in your threading logic and make Channel and Thread global vars
06:40:20Araqthen it's memory safe. Also ensure your callbacks are .gcsafe
06:47:49*narimiran joined #nim
06:48:05I_Right_IAraq: can you get nim to compile its callbacks with __attribute__((noinline))
06:50:20I_Right_Iif the question make no sense its because I am not at all knowledgeable of how nim is compiled to c
07:00:00*gmpreussner quit (Quit: kthxbye)
07:04:52*gmpreussner joined #nim
07:07:41I_Right_Iso in c __attribute__((noinline)) prevents the compiler from doing some opts that can spell trouble for some threaded applications
07:08:29*jjido joined #nim
07:09:03Araqwell usually callbacks cannot be inlined so .noinline makes no sense
07:11:48I_Right_Iwait so the gcc compiler never inlines a function with a pointer to it?
07:12:48I_Right_I*^ a function that is pointed to by a pointer
07:15:56Araqwell sometimes it does but never if the thing you pass the callback to is in a DLL
07:26:20*solitudesf joined #nim
07:28:08I_Right_II don't understand why some thread libraries have you set the __attribute__((noinline)) opt on functions you pass to them? Isn't like a callback that run in a different thread?
07:28:51I_Right_Ilol that doesnt really get called back....just called
07:31:13Araq"C" is an abbrev for "cargo cult programming", that's why.
07:35:36I_Right_II thought it was for "Crying at Computer"... cc -c mybuggylib.c -o crashmyos.o
07:39:25I_Right_Iso is there a way to make a nim proc compile to c with the __attribute__((noinline)) option set?
07:40:11I_Right_Ilike a pragma or something?
07:46:53*I_Right_I quit (Remote host closed the connection)
07:48:55*kapil____ quit (Quit: Connection closed for inactivity)
08:22:33*vlad1777d quit (Ping timeout: 245 seconds)
08:23:43*vlad1777d joined #nim
08:23:44*Perkol joined #nim
08:31:13*vlad1777d quit (Ping timeout: 250 seconds)
08:32:30ZevvHey araq: please tell me if you get bored or distracted by my PEG stuff. If not, feel free to have a look at the current state. I'm pretty happy with the result, action captures are now in and are a breeze to use.
08:32:56*vlad1777d joined #nim
08:33:48ZevvMy next step is to create native Nim regular expressions built on top of this, which should not be hard to do. The regexp definition will be parsed by NPeg itself, and result in a new Npeg parser parsing the regexp grammar.
08:34:07ZevvI haven't felt this meta in a long time
08:48:18avanderneutI had some trouble with zmq: i am cross compiling from Linux to WIndows, and the version installed on Windows from the installer differs from my locally installed version (4.0.4 resp 4.2.0).
08:48:41avanderneutSince the message width is determined at compile time from the version number an differs (32 vs 64) things would not work.
08:48:51avanderneutAnd I could not find a newer windows installer.
08:49:13avanderneutI got it to work by patching zmq.nim, but I would like to know what is the best approach for a PR
08:50:41avanderneutI think I can use the commandline -d option to pass in some value to nim.zmq but I am not sure if I should provide an option to override the version number (used to lookup the width) or the width, or both
08:50:54avanderneutor should I use a different approach in this case?
08:51:31avanderneut(downgrading my Linux version is not an option nor a very useful way of solving this)
08:53:46avanderneutAre there examples in other libraries used in cross compilation? Can the importing package set something like that when it detects that it is being compiled with -d:mingw?
08:56:48*Vladar joined #nim
09:09:06*stefanos82 joined #nim
09:16:13AraqZevv: I don't know how you could use Pegs for regexes, they are fundamentally different
09:17:00AraqI_Right_I: you can use .noinline in Nim but it doesn't affect the ABI and so it's irrelevant for C interop
09:34:26Araqavanderneut: I haven't used zmq for quite some time. Usually people just use sockets and websockets.
09:39:11avanderneut@araq The application that I am talking to uses zeromq so that is not really an option for this. Is it possible to define something in a program that influences the compile of an import just like the commandline -dSymbol:Value would ?
09:45:12FromGitter<mratsim> nim.cfg only at the moment :/
09:50:38Araqthat would be anti modular programming.
09:50:47Araqbut you can do this:
09:50:56Araq# wrapper.nim:
09:51:03Araqinclude zmq
09:51:14Araqand then import wrapper.nim everywhere instead of zmq
09:52:21avanderneut@araq and then copy all of the relevant stuff in the wrapper and modify if necessary?
09:52:58Araqwell it depends on what you need to do with zmq.nim
09:53:35Araqyou should try to 'include' it before you go all the way into copy&paste
09:55:06avanderneutzmq has a type definition that has a private field with a array that is either 32 or 64 bytes, currently depending on the locally installed zmq headers.
09:55:47avanderneutThat is of course where the real problem is, any program will break if you upgrade the DLL
09:55:59FromGitter<mratsim> @araq I'm tagging this as high priority: https://github.com/nim-lang/Nim/issues/10886
09:56:12Araqso fix the zmq wrapper please
09:56:21AraqPRs are always welcome
09:57:01Araqmratsim: already have a fix but ok
10:02:38avanderneut@araq that would mean loading the DLL, determining the message queue length (32, 48 or 64 bytes). I am not fluent enough in nim to feel confident what would be the correct type for that. Is there something like a sequence with run-time upperbound?
10:04:18Araqit's just array[N, bytes] but where you compute the N at compile-time
10:04:27Araqto be either 32 or 48 or 64.
10:05:20avanderneutThat is what it is now, but depending on DLL used **at runtime** that value (32/48/64) should be determined
10:06:22Araqnah, support the latest DLL and not the others and call it a day
10:07:46Araqalternatively introduce --define:zmq2 switches for old versions of zmq
10:08:29avanderneutThat is probably better especially since a newer version of ZMQ can talk to older ones, it is just a pain that no newer DLL is available as installer for ZMQ
10:09:16avanderneutThanks
10:09:54Araqtypo, it's array[N, byte]
10:13:42FromGitter<mratsim> was there a change in GC allocation in the past 2 months Araq?
10:13:52FromGitter<mratsim> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c9606e0a21ce51a20a9661d]
10:15:02Araqmratsim: markAndSweep GC got changed, refc didn't
10:17:26Araqcompile with -d:useSysAssert -d:useGcAssert to find the bug more quickly
10:19:12Araqcan we make 'nim c -r' cache its binaries and only recompile when something changed?
10:19:24FromGitter<mratsim> same stacktrace with "nim cpp -r -d:useSysAssert -d:useGcAssert --stacktrace:on -d:release -d:openmp -o:build/gemm_f32_omp benchmarks/gemm/gemm_bench_float32.nim"
10:19:40Araqcan't hurt, right?
10:19:41FromGitter<mratsim> I guess I'll try bisecting
10:19:49FromGitter<mratsim> I don't see a problem
10:19:59*lf-araujo joined #nim
10:22:23*nsf quit (Quit: WeeChat 2.4)
10:43:48*lf-araujo quit (Ping timeout: 245 seconds)
10:47:14Araqhttps://github.com/nim-lang/Nim/pull/10897 there you go
10:47:16*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:48:19BaldEagleX02Crystal-lang seems to have a more beginner-friendly documentation (https://crystal-lang.org/reference). If we want to increase the number of Nim users, we should also work to make our docs easier.
10:49:52BaldEagleX02We have dom96's brilliant book but it's not freely available on the Internet obviously. Maybe a good summary of it could be OK.
10:50:40*ng0 joined #nim
10:52:14AraqI fail to see the benefits of "Building and Serving Locally" and npm
10:53:25narimiranit's funny how this documentation stuff frequently comes up and usually it is "we should this", "we should that"
10:53:46narimiranand then i ask "ok, who will help me with it?" and suddenly there is no "we" anymore
10:54:11Araqlooking at these instructions I would never even try Crystal tbh
10:54:23AraqI don't need web-y shit
10:59:59Araqhttps://forum.nim-lang.org/t/4733 this is what we need to address
11:00:19Araqsomebody wants to use 'sleep', finds it and is unable to call it
11:00:29Araqwhy is that?
11:00:51*narimiran quit (Remote host closed the connection)
11:01:34Araqhttps://nim-lang.org/docs/os.html#sleep%2Cint does not expand the pragmas
11:02:01Araqso ... every proc in the stdlib needs to assume that you don't even know the basic function calling syntax
11:02:59AraqI mean, I get it. People have told me this indirectly for years, people don't understand Nim's proc prototypes nor its calling syntax
11:03:41FromGitter<kdheepak> > don't use cast/ptr/addr in your threading logic and make Channel and Thread global vars
11:04:40FromGitter<kdheepak> Araq, did you mean don't use cast AND don't make Channel and Thread global?
11:04:58Araqno, I meant it as I said it.
11:05:05Araq1. don't use cast/ptr/addr
11:05:16Araq2. use Channel and Thread as globals only.
11:05:40*fowl quit (Quit: Connection closed for inactivity)
11:05:53Araqthere are other ways to use them but these are the guidelines for starting with Nim's threading.
11:06:29FromGitter<kdheepak> This is the syntax for the callback ⏎ ⏎ ```proc callback(interval: uint32, param: pointer): uint32 {.cdecl.} =``` [https://gitter.im/nim-lang/Nim?at=5c961335dfc69a1454dffcbb]
11:06:41Araqand yes I know it's terrible, I spend every free minute on documenting and implementing a better memory management and threading model.
11:07:15FromGitter<kdheepak> Because it's a c callback, would you still recommend I add .gcsafe.?
11:08:18Araqyep, especially if it's a C callback
11:08:32FromGitter<kdheepak> So I get a compiler error if I don't use `param: pointer`.
11:08:55FromGitter<kdheepak> How would I do this without using `cast`
11:11:36*narimiran joined #nim
11:11:58FromGitter<kdheepak> This is the syntax for the callback decl: ⏎ ⏎ https://github.com/nim-lang/sdl2/blob/f1f2d147bc32dee2111696483812337e7ec15ed6/src/sdl2.nim#L573
11:13:45FromGitter<kdheepak> Oh you meant "don't use cast/ptr/addr in your threading logic", so I can use it before and after acquiring and releasing the mutex?
11:15:03FromGitter<kdheepak> I'm not using Channel or Thread.
11:18:59FromGitter<mratsim> @Araq bisecting it's not Nim, it's my code that had a regression, though I wonder how it can appear in "removeChunkFromMatrix2"
11:20:12*stefanos82 quit (Remote host closed the connection)
11:21:28FromGitter<mratsim> seems like it's this ... https://github.com/numforge/laser/commit/e898f027e6d08d90542714234629da984d4e4639#diff-5973201203aafa3cefde7c5ef72e3f1cR320 ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c9616b8f3dbbd230ca33700]
11:21:40FromGitter<mratsim> and it crashes even without OpenMP
11:23:50FromGitter<mratsim> commenting things out, I get this: ⏎ [SYSASSERT] dealloc: object header corrupted
11:25:23FromGitter<mratsim> or ⏎ [SYSASSERT] result wrong pointer!
11:33:57FromGitter<mratsim> narrowed down to allocShared
11:34:35FromGitter<mratsim> the second one crashes: https://github.com/numforge/laser/blob/master/laser/primitives/matrix_multiplication/gemm_tiling.nim#L337-L338
11:43:55*jjido joined #nim
11:44:06FromGitter<mratsim> it it crashes only at the 5th iteration of my bench with alloc size 15052863 and 3932223
11:44:22*stefanos82 joined #nim
11:55:13*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:58:31*Perkol quit (Remote host closed the connection)
12:07:03FromGitter<kdheepak> @Araq I think I figured out what I should do to get things to work but I have no idea why this is the case ⏎ ⏎ https://github.com/yglukhov/nimx/blob/bc96abf0ecd879c7aca2a2c6a77610f1a38989d9/nimx/timer.nim#L105
12:07:11*jjido joined #nim
12:07:39*solitudesf quit (Ping timeout: 246 seconds)
12:08:07FromGitter<kdheepak> Every time I come across some issue with threading it seems like @yglukhov has already found a solution to it :)
12:10:08FromGitter<kdheepak> There's a lot going on in that package. 1) the c callback that is passed to SDL2 is wrapped in a {.push stackTrace: off.} {.pop.} macro. 2) 2) there's some additional stuff that appears necessary to do to get it to work on a Mac / iOS: https://github.com/yglukhov/nimx/blob/bc96abf0ecd879c7aca2a2c6a77610f1a38989d9/nimx/perform_on_main_thread.nim
12:10:12*clyybber joined #nim
12:10:37FromGitter<kdheepak> Hopefully @yglukhov can chime in and explain
12:11:10FromGitter<kdheepak> On using what he wrote there, I'm no longer able to cause segfaults / hanging.
12:11:27*neceve joined #nim
12:12:36*dddddd joined #nim
12:31:48FromGitter<mratsim> @Araq, can you echo/debugecho in alloc.nim? The crash happens there on line 211? https://github.com/nim-lang/Nim/blob/e26370268885718c6b48a9fa5e940fdc8b4df090/lib/system/alloc.nim#L208-L215
12:32:11FromGitter<mratsim> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c96274adfc69a1454e0803c]
12:32:16*shashlick joined #nim
12:32:24FromGitter<mratsim> it's quite strange because there is a nil check just before
12:32:26Araqno and the echo won't help you anyway
12:33:47*lritter joined #nim
12:33:51Araqthe bug is not in removeChunkFromMatrix, that code was executed billions of times
12:34:25Araqmost likely you free memory from the wrong thread
12:34:46FromGitter<mratsim> the crash also happens when single threaded though
12:34:51FromGitter<mratsim> and in debug mode
12:35:20FromGitter<mratsim> also that memory allocation is in the main thread, I don't allocate GC memory in threads
12:38:55Araqalloc() also uses the allocator
12:39:25AraqGC memory has little to do with it, every allocation uses the allocator unless you wrapped C's malloc or similar
12:40:16Araqand always keep in mind that memory overcommitment turns out-of-memory into segfaults
12:41:03FromGitter<mratsim> I have 120GB+ memory free
12:47:21Araqrun it in GDB and inspect 'fl', 'sl'
12:48:17Araqyou can also use cprintf for debug output
12:51:26Araqbut it's futile, you corrupt the heap manager's data somehow and then you blame it for crashing
12:57:37FromGitter<mratsim> so apparently this fix my issue: https://github.com/numforge/laser/commit/08057711132b2a2ee7efc94b80d4a18027675989
12:57:49FromGitter<mratsim> I don't understand how though, debugging
12:59:32*nsf joined #nim
13:05:30FromGitter<mratsim> and this reintroduce the bug: https://github.com/numforge/laser/pull/28/commits/1c5410ecf8a507791cc878ab59560dcbef24a7b0#diff-5973201203aafa3cefde7c5ef72e3f1cR326
13:06:00FromGitter<mratsim> I think the tuple destructuring might corrupt something?
13:07:22FromGitter<mratsim> or not, mmmh
13:09:54FromGitter<mratsim> so I can fix the bug by not calling my function that returns a tuple: https://github.com/numforge/laser/pull/28/commits/ef570adcd789b5b85913152db946d874f3373869
13:12:31FromGitter<mratsim> ah I know why
13:12:43FromGitter<mratsim> user error, I messed up in my tuple value order
13:17:13Araqlol
13:22:48FromGitter<mratsim> btw, with the new openmp stepping I improve my perf by 15%
13:23:39FromGitter<mratsim> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c96335ad0133e21e500f148]
13:23:49*sealmove joined #nim
13:24:44FromGitter<mratsim> jump from 1.7 TFlop/s to 2TFlop/s, faster than OpenBLAS and Intel on large matrix multiplication =)
13:25:08FromGitter<mratsim> (and those are using assembly everywhere)
13:42:19*theelous3_ joined #nim
13:43:57clyybber\o/ mratsim you are a wizard
13:52:41FromGitter<danielecook> I am working with the RunningStat object and found that when adding two RunningStat objects together the `min` reported may be wrong if in A min is 0 and B min is 5, min will be reported as 5 in the resulting object.
13:57:19Araqtoo bad :-)
13:57:28Araqbut kudos for using RunningStat
13:58:14*ng0 quit (Remote host closed the connection)
13:59:39*ng0 joined #nim
14:06:38FromGitter<danielecook> So does that sound like an error or is that expected behavior?
14:06:45*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
14:08:23Araqproc `+`*(a, b: RunningStat): RunningStat =
14:08:23Araq ## combine two RunningStats.
14:08:34Araq result.min = max(a.min, b.min) # typo here
14:09:27Araqfixed.
14:14:01FromGitter<danielecook> ah! ok good to know
14:14:15FromGitter<danielecook> Thanks!
14:19:28*seni joined #nim
14:26:00*sentreen joined #nim
14:27:54*sentreen_ quit (Ping timeout: 272 seconds)
14:34:03*edcragg quit (Quit: ZNC - http://znc.in)
14:37:33*sentreen_ joined #nim
14:39:12*sentreen quit (Ping timeout: 245 seconds)
14:46:40clyybberAraq: Whats the reason for `var a, b = 3` being allowed, but `a, b = 3` not?
14:48:16sealmoveyou can do `a = b = 3`, no?
14:50:28sealmoveoh, you can't
14:51:24sealmovewell, declarations are different from assignments, but this could be an RFC
14:51:35*sentreen_ quit (Quit: WeeChat 2.3)
14:51:44*sentreen joined #nim
15:02:05*stefanos82 quit (Remote host closed the connection)
15:15:35sealmoveplanetis: the interface macro turned out to be harder to make than I thought, so it will take a while to implement.
15:22:47federico3why there is no multiprocess module?
15:24:42planetis[m]yep its not easy, but anything you need you can ask
15:26:05sealmovethanks
15:28:07sealmoveplanetis: I realized what you made is actually traits for Nim
15:49:00Araqclyybber: 'var a, b = 3' is allowed because the syntax allows for it but it's very bad style so it wasn't put into ordinary assignment
15:50:00ZevvI assume multiple assignment by tuples gets optimized away to the same as two separate assignments? (a, b) = (3, 5)
15:50:18*Trustable joined #nim
15:51:30Zevvoh it does not :)
15:53:40Araqyeah but it'll move and then the C optimizer kicks in and optimizes it away
15:54:10ZevvThat was my though, but the resulting assembly is not the same it seems
15:54:38sealmoveplanetis: implemented the other one though: https://github.com/sealmove/ease
16:00:45planetis[m]nice, I think `repr` is used for echo only, you can directly pass the symbol to it.
16:01:37planetis[m]or thats intentional? you are creating a hidden variable?
16:02:15sealmoveit's a typed argument, I think I need it to extract identifier
16:03:18sealmoveI use it to create proc signature
16:03:41planetis[m]right I was confused, I mostly use untyped parameters
16:04:26sealmovewell I used an uncommon technique... the parameters' name have to match the code that the user passes (to the 2nd, untyped parameter)
16:04:29planetis[m]btw what is nnkLambda node for?
16:04:38sealmoveanonymous proc
16:04:57sealmoveI think if you read README you'll easily understand what's going on
16:05:18*zyklon quit (Ping timeout: 264 seconds)
16:05:21AraqZevv: please look at lexim if you want to compile regexes at compiletime
16:05:28Araqit's very different from PEGs
16:06:32planetis[m]well I read it but I dont get the usecase :p
16:08:16sealmovethe use case is when you write a long proc which contains parts that have seperate logic. In that case you typically create other procs which are called by that long proc. This macros give you a way to seperate logic without having to create sub-procs.
16:09:43sealmoveessentially creating namespaces within a proc
16:10:43*zyklon joined #nim
16:11:39planetis[m]thanks for explaining, I will give it a try now.
16:11:48sealmovehttps://termbin.com/laiz
16:12:06sealmoveI'll try to explain more in README, thx for feedback
16:14:15planetis[m]you can use a block statement no?
16:14:33sealmoveblock statement doesn't create a new namespace
16:15:18sealmoveso for example this works: https://termbin.com/eiud
16:15:40sealmoveif you want to seperate logic, you want to NOT be able to reference x
16:16:35sealmoveit essentially works like a more strict block statement
16:17:41Araqhmm interesting
16:26:01*solitudesf joined #nim
16:34:31*Cthalupa quit (Ping timeout: 255 seconds)
16:36:36*Cthalupa joined #nim
16:44:10*lf-araujo joined #nim
16:45:18ZevvAraq: I know the difference; I found some papers describing transformations for converting regular expressions to PEGs, which would fit nicely into what I have now - except for back references, and it will break captures in some areas. Both are showstoppers, so the plan is off for now
16:51:20*abm joined #nim
17:05:29*nsf quit (Quit: WeeChat 2.4)
17:10:10*I_Right_I joined #nim
17:10:24*vlad1777d quit (Ping timeout: 246 seconds)
17:10:55*a_chou joined #nim
17:14:41*lf-araujo quit (Read error: Connection reset by peer)
17:16:47sealmovewhat is the equivelant of addr operator for traced referances?
17:20:48*a_chou quit (Quit: a_chou)
17:20:58*lf-araujo joined #nim
17:22:15*neceve quit (Read error: Connection reset by peer)
17:22:50sealmovedoes not exist?
17:35:30FromDiscord<Generic> try pointer(reference), if it doesn't work try cast[pointer](reference)
17:36:35FromDiscord<Generic> though be careful, for example if you want C interop
17:36:46FromDiscord<Generic> you might need GC_ref and GC_unref
17:37:30Araqsealmove: it cannot exist, 'ref' is always a pointer to the heap
17:37:58sealmoveyeah, I see why it can't work
17:38:16sealmovetrying to model the problem differently now
17:40:59sealmovetrying to implement a nice macro for that interface pattern https://github.com/nim-lang/Nim/blob/devel/tests/closure/tclosure.nim#L582
17:41:26sealmoveit can be made nice, with 1 exception, which might or might not be ok, depends on your perspective
17:41:42*cyraxjoe quit (Ping timeout: 272 seconds)
17:41:44*MightyJoe joined #nim
17:41:51sealmovethe limitation is that you won't be able to access the value through the interface variable
17:42:05sealmovegetters won't work
17:42:50sealmovebut you can always implement the interface for a `ref` type, and then change the underlying value using the original variable
17:43:07sealmovethis is because we don't have classes
17:43:15sealmove(probably for the better :P)
17:44:00sealmovein golang you receiver functions so it works..
17:44:27sealmovebut yeah, maybe it's better to use the interface type only for calling procs, and not for accessing values
17:45:45clyybberAraq: I see, so `var a, b = 3` is just syntactic sugar for `var a = 3; var b = a`? Or does it somehow skip creating a temporary?
17:46:06clyybber..or an assignment>
17:46:49Araqno it's sugar for 'var a = 3; var b = 3'
17:47:04clyybberso when 3 would be a proc it would be called two times?
17:47:16Araqtry it, that's how I remember it
17:47:23clyybberok thx
17:47:34Araq(I never use it)
17:48:38clyybberYep, it gets called two times.
17:48:50clyybber(then I won't use it either :P)
17:49:10sealmove(you can change/tinker the internal value through the interface variable, just not return it)
17:51:39sealmovehttps://termbin.com/r71x Error: 'untyped' is not a concrete type
17:52:41Araqhow do you think ' ret: proc(): auto {.closure.}'
17:52:45Araqcan work?
17:53:21sealmovewell it can't :P so interface getters won't work (because you need to implement them for different types)
17:53:34sealmovebut I think they are still useful without getters
17:56:48I_Right_ISo is there a way to get nim to tell the C compiler to use __attribute__((noinline)) for specific functions?
17:57:01sealmovehmm... wait, maybe it can work, just don't have to include the getter in the interface type! Can just auto-generate it!
17:58:14AraqI_Right_I: yes, use proc foo() {.noinline.}
17:58:54Araqsealmove: there is no problem here, in Go the getter's return type is also never inferred
17:58:55I_Right_IAraq: Thank you?
17:59:27AraqI_Right_I: but as I said, it's super unimportant noinline doesn't affect the API/ABI
17:59:40sealmoveAraq: I see. Well, macros can take care of autogenerating the correct type, so it's really cool :)
18:00:09*zyklon quit (Remote host closed the connection)
18:01:11*natrys joined #nim
18:02:24sealmoveargg sorry, I still have issues comprehending this pattern. Not sure if it can be done :S
18:04:39sealmovehttps://termbin.com/ypsf
18:06:17clyybberc ya
18:06:23*clyybber quit (Quit: WeeChat 2.4)
18:06:57sealmoveexample with 2 different types: https://termbin.com/qyk2
18:09:22Araqlol
18:13:31*vlad1777d joined #nim
18:14:38Araqyou hide the Vertex/MyFloat type difference in the closure, done.
18:15:11sealmoveof course, but then the interface type can't return it
18:15:24sealmovebecause you can't have 1 getter that return different types
18:15:54Araqwhat 'getter'? there is no getter in your Go code
18:17:34sealmovebecause the interface variable (a) holds the value. In the Nim pattern the interface variable doesn't hold the value directly, it hides it in a closure, so you can't access it
18:17:53sealmoveyou can't return it I mean
18:17:59sealmoveyou can access it but not return it
18:20:39sealmove`fmt.Println(a)` is not same as `fmt.a.Println` in Go ;p
18:21:19sealmovePrintln(Abser) doesn't exist, a just gives back the concrete value
18:24:07sealmoveif it's possible to hold a type in a variable, then we have a solution
18:24:23sealmovethe interface can hold a tuple of procs AND a type
18:24:30sealmove(typedesc ?)
18:26:06AraqI'm not sure I understand the problem
18:26:30sealmovesorry my bad, I write more than I think, will try to make a useful illustration
18:29:07shashlickwas looking at the hot code reloading docs
18:29:41shashlickit doesn't tell you how the modules get recompiled
18:29:46shashlickor what you need to do for that to happen
18:34:26*Trustable quit (Remote host closed the connection)
18:34:32shashlickmeanwhile, just added double pointer support to nimterop, @data-man - also fixed your comma issue 🙂
18:35:29sealmoveAraq: here is the getter https://termbin.com/ldyb
18:35:37*Trustable joined #nim
18:38:02sealmoveworks for different types: https://termbin.com/uhqe
18:40:00*seni quit (Remote host closed the connection)
18:44:13Araqwell a := fl is an implicit conversion that you need to write down explicitly in Nim but that has nothing to do with getters
18:46:54sealmovei am referring to f := a not a := f
18:47:13sealmovea := f is easy
18:49:11Araqthere is no such thing in your example.
18:49:28sealmovehow do you convert a tuple of procs to a concrete value?
18:49:53Araqyou convert from a concrete type to an interface type, never the other way round.
18:50:01Araqin your example code.
18:50:58*abm quit (Ping timeout: 246 seconds)
18:52:08Araqyou don't convert from an interface to a concrete type but if you really have to you can do cast[RefType](tup[0].rawEnv)
18:52:10sealmoveohhh you are right, I get "cannot use a (type Abser) as type int in assignment: need type assertion"
18:53:39sealmoveso Println does type assertion https://tour.golang.org/methods/15
18:56:59*Perkol joined #nim
18:59:22sealmoveyeah, have to have a way to get the concrete value out of the interface. Then the proper way is to do type assertion and determine if the assignment is valid. I'll try cast[RefType](tup[0].rawEnv), thanks a lot :)
19:02:27Araqwell I doubt it really works out but that's because it's fundamentally flawed
19:02:50Araqand it is in Go too afaict.
19:03:25sealmovetruth is it crossed my mind it might be flawed... maybe I just wanted you to verify it :P
19:03:52Araqwhat you capture over / what you put into an interface is not necessarily a type with reference semantics
19:04:26sealmoveyeah, if you want that u can jus impl the interface for a ref type
19:04:33sealmoveand that works
19:05:57FromDiscord<Avatarfighter> Is there a way to make the nim compiler not reference local machine files in executables
19:05:58FromDiscord<Avatarfighter> ?
19:06:44*nsf joined #nim
19:07:07FromDiscord<Avatarfighter> When I ran `strings EXECUTABLE` I saw that the executable was trying to reference local files with the absolute path to them on my own local machine
19:07:19*noeontheend joined #nim
19:09:44Araqyes, there is a way. Write programs that don't do that.
19:10:14FromDiscord<Avatarfighter> The thing is, the script I wrote doesn't reference any files with the absolute path, the nim compiler includes them :L
19:11:02shashlickwhat files are being referenced
19:11:26FromDiscord<Avatarfighter> `/Users/USERNAME/.choosenim/toolchains/nim-0.19.4/lib/pure/json.nim`
19:12:15FromDiscord<Avatarfighter> actually, like every module that I import has the absolute local path in the executable
19:13:23shashlickthose are source files
19:13:33shashlickprobably references for debugging
19:14:04*stefanos82 joined #nim
19:14:18*Cthalupa quit (Ping timeout: 246 seconds)
19:14:53FromDiscord<Avatarfighter> yup
19:15:03FromDiscord<Avatarfighter> I forgot to add `-d:release`
19:16:22*Cthalupa joined #nim
19:17:29FromDiscord<Avatarfighter> Thank you for the help!
19:18:11*lf-araujo quit (Ping timeout: 250 seconds)
19:19:35sealmovewill look something like that (for anyone interested): https://termbin.com/wf83
19:22:47sealmoveAraq: Last question :3 should interface procs be allowed to have pragmas annotations?
19:23:38*Vladar quit (Remote host closed the connection)
19:25:36sealmoveor better disallow that and only generate the {.closure.} pragma?
19:28:14*Perkol quit (Quit: Leaving)
19:37:09Araqwell ... thinking about it
19:38:00Araqif the interface is a macro why generate a tuple of closures when also can generate an inherited object
19:39:54*lf-araujo joined #nim
19:46:21*noeontheend quit (Ping timeout: 250 seconds)
19:53:15sealmovewhat's the advantage?
19:54:04*lf-araujo quit (Quit: lf-araujo)
19:56:23Araqfaster code
20:01:09sealmoveok I know nothing about that :P have to go now, but tomorrow (or next time anyway) I'll ask for details (what/when to inherit from)
20:04:29sealmoveI assume you mean same pattern right (collection of procs)?
20:07:42*lf-araujo joined #nim
20:22:13*lf-araujo quit (Read error: Connection reset by peer)
20:37:31*theelous3_ quit (Ping timeout: 255 seconds)
20:48:53*rnrwashere joined #nim
20:49:44*rnrwashere quit (Remote host closed the connection)
20:50:23*rnrwashere joined #nim
20:54:49*rnrwashere quit (Ping timeout: 250 seconds)
21:14:30*sz0 joined #nim
21:15:32disruptekAraq: i like nawabs. are you still using it? want features or patches?
21:16:35Araqdisruptek: I thought about simplifying it further and add it to Nim's standard toolchain
21:16:53Araqfeatures and patches are more than welcome
21:20:28*narimiran quit (Ping timeout: 245 seconds)
21:35:22*rnrwashere joined #nim
21:41:07*stefanos82 quit (Remote host closed the connection)
21:44:45*Trustable quit (Remote host closed the connection)
21:48:36*nsf quit (Quit: WeeChat 2.4)
21:56:05*noeontheend joined #nim
22:00:46*vlad1777d quit (Ping timeout: 255 seconds)
22:02:03*vlad1777d joined #nim
22:10:25*jjido joined #nim
22:12:13*vlad1777d quit (Ping timeout: 246 seconds)
22:30:10FromGitter<arnetheduck> ```code paste, see link``` ⏎ ⏎ here's a performance profile of an app we're running - turns out 90% is spent in GC - mainly because we're allocating small seqs.. now, we could of course rewrite the code to not use all those seqs, but one of the reasons to use a GC'd language is to not have to care.. what are alternatives to explore (in nim 0.19, not a future version)? [h
22:30:10FromGitter... ttps://gitter.im/nim-lang/Nim?at=5c96b3726a3d2e230d141c5f]
22:32:47FromGitter<arnetheduck> a typical call stack will look like: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ it's calculating a merkle hash, so all the little short-lived stacks live on a single stack and don't survive past the return of the `merkleHash` function [https://gitter.im/nim-lang/Nim?at=5c96b40f3dd81711493e5f33]
22:39:34ryukopostingis there any way around dealing with the order of default arguments in a proc?
22:39:55ryukopostingsay for example, I have proc foo(x = 2, y = true, z = "asdf"): Thing
22:40:18ryukopostinghow would I give that proc just x and z, leaving y default?
22:42:57*natrys quit (Quit: natrys)
22:46:29solitudesffoo(x=2,z="asdf")
22:46:30solitudesf?
22:46:55ryukopostingI'm getting an error when I do that
22:47:20solitudesfcool
22:48:52ryukopostingit says that argument 2 (which it says is y) is wrong
22:49:14ryukopostingidk if that's a bug or if it's intentional, but it's very annoying
22:49:37solitudesfi literally just ran this, and it works
22:49:43ryukopostingwat
22:50:06ryukopostingmaybe it's because they're wrapped in option types, hmm
22:54:40ryukopostingsolitudesf try this https://dailyprog.org/f/0xoo
22:54:55ryukopostingit's missing an 'import options' at the top but yeah
22:55:01ryukopostingoh shoot, forgot the converters that go with it
22:56:35*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:56:50ryukopostingokay wtf
22:57:11ryukopostingit might be something in codegen, weird. Not sure what I'm missing here
22:57:20ryukopostingit's on my side though definitely
22:59:00*solitudesf quit (Ping timeout: 246 seconds)
23:00:32*uvegbot joined #nim
23:35:51ryukopostingalrighty, posted an issue https://github.com/nim-lang/Nim/issues/10900
23:54:45*theelous3_ joined #nim