<< 03-01-2019 >>
00:00:24*cozachk joined #nim
00:01:35*zachk quit (Ping timeout: 246 seconds)
00:05:47FromGitter<arnetheduck> @Clyybber that's nice as it fixes compiling `nlvm` itself, but perhaps a better option would be to make sure that option is always added to any linking that nlvm does? otherwise, anything you compile with `nlvm` will still fail with this annoying error that's hard to google for
00:13:44*cozachk quit (Read error: Connection reset by peer)
00:14:39*zachk joined #nim
00:15:03*endragor quit (Remote host closed the connection)
00:15:31*zachk quit (Read error: Connection reset by peer)
00:16:26*zachk joined #nim
00:33:44*d10n-work quit (Quit: Connection closed for inactivity)
00:36:21*zachk quit (Changing host)
00:36:21*zachk joined #nim
00:43:31FromGitter<timotheecour> @kaushalmodi you’re welcome :)
00:43:56FromGitter<timotheecour> @dom96 quick question if you’re here
00:45:19dom96yes?
00:46:09FromGitter<timotheecour> for https://github.com/nim-lang/Nim/pull/10150 I’d like to be able to test in on testament (otherwise it’ll bitrot) ; however it requires `nimble install libffi` ; I have some ideas for how to address this but what would u suggest
00:49:08*rockcavera joined #nim
00:56:54*d10n-work joined #nim
01:00:04dom96Hrm, I would create a separate test that you compile after running `nimble install libffi`
01:00:15dom96AFAIK `koch test` runs before any `nimble install`s
01:00:20dom96good night
01:02:12FromGitter<timotheecour> hmm so maybe simplest is to run `nimble install libffi` before `./koch tests`?
01:06:08shashlick@Clyybber: i'll check it out
01:06:39shashlickalso saw plibsys which looks interesting
01:07:00shashlickthere's nothing cross-platform i found for pipes
01:30:27*vlad1777d quit (Ping timeout: 240 seconds)
01:33:29*Ven`` quit (Ping timeout: 268 seconds)
02:00:37*cspar quit (Ping timeout: 268 seconds)
02:10:09*kinkinkijkin quit (Remote host closed the connection)
02:34:35*vivus quit (Remote host closed the connection)
02:35:53*Tyresc quit (Quit: WeeChat 2.4-dev)
02:36:51*zachk quit (Quit: Leaving)
02:43:21*krux02 quit (Remote host closed the connection)
02:45:14*Geezus42 quit (Quit: WeeChat 2.3)
02:56:01*wildlander quit (Ping timeout: 246 seconds)
03:00:34*banc quit (Quit: Bye)
03:13:36*wildlander joined #nim
03:18:15*dddddd quit (Remote host closed the connection)
03:19:02*banc joined #nim
03:39:04*wildlander quit (Ping timeout: 246 seconds)
03:45:23*ChristianWitts joined #nim
04:01:34*ChristianWitts quit (Ping timeout: 272 seconds)
04:34:51*nsf joined #nim
04:35:10*Ven`` joined #nim
04:39:43FromGitter<gogolxdong> a mysql db query returns null in CLI, and db_mysql getRow raised an error , is this expected? ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c2d920f6649aa1f8210bb71]
04:41:43*Ven`` quit (Ping timeout: 245 seconds)
04:41:45FromGitter<gogolxdong> select sum(out_amount) from billings WHERE user_id=? and (time REGEXP ?)
04:42:11FromGitter<gogolxdong> got attempt to read from nil.
04:52:21leorizedo you have a stack trace?
04:53:51*kapil____ joined #nim
05:14:53*nc-x joined #nim
05:16:37*gmpreussner_ quit (Ping timeout: 250 seconds)
05:17:38nc-xAraq: regarding `--genMapping` only works with `--compileOnly` because of https://github.com/nim-lang/Nim/blob/devel/compiler/extccomp.nim#L496-L501, would you accept a patch that shows an error message when `--genMapping` used without `compileOnly` that says that it can only be used with compile only
05:24:43FromGitter<gogolxdong> Traceback (most recent call last) ⏎ cmpthreads.nim(59) initWorker ⏎ cmp.nim(50) alarm ⏎ db_mysql.nim(339) getValue ⏎ db_mysql.nim(306) getRow ... [https://gitter.im/nim-lang/Nim?at=5c2d9c9bab910e7d3a13c0fb]
05:26:33*nc-x quit (Ping timeout: 256 seconds)
05:53:29*gmpreussner joined #nim
05:54:36*leorize quit (Ping timeout: 252 seconds)
05:56:30*leorize joined #nim
05:59:13*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
05:59:33*narimiran joined #nim
06:13:20*nc-x joined #nim
06:13:46nc-xis forward declaration not supported for iterators?
06:22:39*nc-x quit (Ping timeout: 256 seconds)
06:46:38*kinkinkijkin joined #nim
06:56:05*cspar joined #nim
07:17:28*theelous3 quit (Ping timeout: 250 seconds)
07:19:58*kinkinkijkin quit (Remote host closed the connection)
07:20:10*ripspin joined #nim
07:22:41*theelous3_ joined #nim
07:32:52*kapil____ quit (Quit: Connection closed for inactivity)
07:35:27Araqnc-x: yeah but I would simply undocument --genMapping instead.
07:36:57FromGitter<timotheecour> I intend to add: `nim c —dump:foo.json main.nim` so we can get the info for symbol mapping in a way that’s machine/human readable (useful for tooling in many places)
07:54:37*theelous3_ quit (Ping timeout: 244 seconds)
08:00:22*kapil____ joined #nim
08:17:21*Vladar joined #nim
08:28:50*rect0x51 joined #nim
08:34:47*rect0x51 quit (Ping timeout: 240 seconds)
08:36:34*floppydh joined #nim
08:37:02*rect0x51 joined #nim
08:38:13leorizeAraq: this commit was reverted due to test failures it cause https://github.com/nim-lang/Nim/commit/7beea1642ddf7845a9a0034c7a93ccbe15894c36. Can I create a PR based on version-0-19 branch to re-add the fix with a compatible test?
08:46:28*sz0 joined #nim
08:46:33Araqtimotheecour: The compiler can generate "ndi" files that contain the mangled names
08:47:20Araqleorize, ok
08:47:58*jjido joined #nim
08:48:11FromGitter<gogolxdong> any suggestion on the db error? @leorize
08:49:53FromGitter<timotheecour> i know, but it’s a lot easier to get it via a json dump, to avoid having to do any parsing, and avoiding issues with stale ndi’s from past runs that shouldn’t ve been generated, etc
08:50:38FromGitter<timotheecour> Same rationale as why whe have `nim dump --dump.format:json`
08:51:36FromGitter<timotheecour> (eg, makes it fwd compatible in case we need to add fields; whereas with ndi files, existing parsers would break)
08:54:42Araqyeah, 'nim dump' is an excrescent too, just embrace SQLite
08:56:29rect0x51Araq: Yesterday did you mean the whole C/C++ backend was a bad idea? Like... choosing llvm from the get-go would've been better? Or did I misunderstand completely?
08:56:49FromGitter<timotheecour> not quite as universal for tooling compared to json; anyway tooling can add sqlite wrapper or alternate output if/when necessary
08:58:21FromGitter<timotheecour> I guess `emit: “”” some C++ code”””` could also work with nlvm; that’d require libclang though
09:03:09FromGitter<gogolxdong> Is this a bug?
09:03:31leorizegogolxdong: could be
09:03:39leorizehere's the segfaulting line: https://github.com/nim-lang/Nim/blob/7c5ae008874e7bb76214bca96267bcb400a723d1/lib/impure/db_mysql.nim#L306
09:04:03leorizemaybe `row[i]` should be checked for `nil`?
09:06:01FromGitter<gogolxdong> http://ix.io/1xps minimal reproductable snippet.
09:07:17FromGitter<gogolxdong> given an existing table and any non-existing id.
09:10:57FromGitter<gogolxdong> @Araq, will you have a look at skype, we have an issue which prevents project approching.
09:11:39*rokups joined #nim
09:21:11Araqok, sorry, updating
09:33:07Araqrect0x51, the grass is always greener on the other side
09:33:22AraqI don't regret targetting C, it gives us some advantages too
09:34:37Araqbut for a REPL it's bad.
09:36:13*abm joined #nim
09:50:46rect0x51Araq: was worried for a moment
09:50:49*PMunch joined #nim
09:53:06*vlad1777d joined #nim
09:57:48*vlad1777d quit (Ping timeout: 250 seconds)
10:13:21narimiranshare your thoughts about (improvements for) nim documentation: https://forum.nim-lang.org/t/4523
10:14:16*rect0x51 quit (Ping timeout: 250 seconds)
10:18:37*rect0x51 joined #nim
10:18:49*dddddd joined #nim
10:19:07*stefanos82 joined #nim
10:36:02FromGitter<timotheecour> Woohoo! `c_printf("foo:%g:%s:%d\n", 0.03, "asdf", 103.cint)` now works at CT … need to update PR
10:36:59FromGitter<timotheecour> (yesterday, procs with varargs only worked so long there was no vararg argument)
10:50:19rect0x51CT is abbreviation for?
10:50:30FromGitter<mratsim> compile-time
11:04:00rect0x51Is it different than using {.importc.}? What's the catch?
11:04:20FromGitter<timotheecour> importc didn’t work at CT until my PR
11:05:25*sz0 quit (Quit: Connection closed for inactivity)
11:08:15rect0x51ok I think I am following. so... what exactly does it mean to "work at CT"? I mean, printf is in some binary (.so or .dll) and Nim just calls it, right?
11:10:13FromGitter<timotheecour> see https://github.com/nim-lang/Nim/issues/9253 for more details
11:12:04rect0x51I follow your PR, it's very interesting :) I understand the point is to call C function before compiling the Nim source file (static evaluation). I just my question is how does it work? Does the VM emit something in Nim AST form?
11:12:36FromDiscord_<PusiteGA> anyone know how to do fibonacy in binary meybe 😃
11:13:34rect0x51I guess*
11:13:36FromDiscord_<PusiteGA> am doing some puzzle its so fun, just dont want to waste whole day learning, or at least thats the hope 😃
11:14:17FromDiscord_<PusiteGA> i need to do binary from 10.000 place fibonaci
11:15:22FromDiscord_<PusiteGA> so duno if i get exactly, but do i have to supply how much time too right? or it goes to 0
11:15:44FromDiscord_<PusiteGA> i have read it goes to zero bit kinda dont get it
11:15:49*dom96_w joined #nim
11:16:20FromGitter<timotheecour> it works by calling dlopen/dlsym to get a function pointer, then converting VM arguments (known at CT while VM is running) to something libffi can understand, then calling that function pointer (libffi taking care of calling convention)
11:16:39rect0x51PusiteGA: If you are seriously asking, I would suggest you write it in C, then translate it to assembly, then to binary.
11:18:33FromDiscord_<PusiteGA> i am, issue is i dont really get concept i understood normal fibonaci but didet got binary one
11:18:54rect0x51timotheecour: Ok so after (say printf) is called... where does the result go? and in what form? (sorry for the noob questions...)
11:19:02FromDiscord_<PusiteGA> why not write in NIm a proc that will give me output
11:20:53FromGitter<timotheecour> VM registers (TFullReg) are converted to libffi types, then function pointer (obtained via dlsym) is called, then the result is converted back to VM register
11:21:44FromGitter<alehander42> PusiteG do you want binary numbers (0100 etc) input and output?
11:22:02rect0x51timotheecour
11:22:56FromDiscord_<PusiteGA> yep want 01001001
11:23:07FromDiscord_<PusiteGA> output
11:23:19FromGitter<alehander42> well, you need to convert your int number with
11:23:21FromGitter<alehander42> toBin
11:23:23FromGitter<alehander42> from strutils
11:23:25rect0x51PusiteGA: Lol I thought you wanted to write a fibonacci program in binary xD
11:25:55FromDiscord_<PusiteGA> rect0x51 owerthinking gats moste of us xD
11:26:00FromDiscord_<PusiteGA> rect0x51 owerthinking gets moste of us xD
11:26:23FromDiscord_<PusiteGA> will try alehander42
11:26:49FromDiscord_<PusiteGA> tough this confused me
11:26:50FromDiscord_<PusiteGA> https://en.wikipedia.org/wiki/Fibonacci_coding
11:31:30rect0x51timotheecour: One last question... From what I understand, one of VM's main uses is to evaluate Nim macros and emit Nim AST. Is NimScript a seperate story from that?
11:32:13FromGitter<timotheecour> VM is for CTFE
11:33:42rect0x51Need to read more on that... thanks
11:33:57FromGitter<timotheecour> and can also be used for running nimscript as i understand (and nim secret uses it too i believe also)
11:34:39rect0x51I see, I see. Just don't understand how CTFE works. Just need to read on that.
11:36:44FromGitter<timotheecour> here’s a good picture: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c2df3ccf6166a3027b1b432]
11:39:40*zahary joined #nim
11:40:44FromGitter<timotheecour> the code is intepreted at CT and converted into `opCode ra rb rc` (3 registers max per instruction), then is executed by the VM in a loop (similar to the way your CPU goes through instructions, except in software instead of hardware, and using custom instruction set); see `rawExecute`
11:40:51rect0x51timotheecour: It finally clicked to me, thanks!!
11:41:13FromGitter<timotheecour> cool :)
11:42:18FromGitter<timotheecour> what would be cool though, is if we could JIT it for faster compile times
11:43:38FromGitter<timotheecour> nlvm could help for that but no idea how far that’d be
11:43:40rect0x51how extensively does Nim do CTFE?
11:43:50rect0x51in general
11:45:06FromGitter<timotheecour> totally depends on type of program you’re writing; but it could be a lot even if you have a single call to `const foo = bar()` depending on how complex `bar` is
11:45:34FromGitter<timotheecour> (ie, doesn’t even require a macro to trigger it)
11:46:00rect0x51JIT it for faster compile times... Would this work by JIT the statically evaluated stuff so that nim compiler has less work to do?
11:48:21FromGitter<timotheecour> say you have: ⏎ `static: for i in 0..<1000: foo(i)` ; without JIT, it’d have to interpret `foo(i)` for every iteration; with JIT, it could detect that it’s a hotspot, compile it, and run it on hardware instead of software
11:51:04rect0x51Ahh I see, if you have non-trivial static calculations in your code, then compile times can be a nightmare
11:51:34FromGitter<timotheecour> the FFI PR I’m doing could potentially enable some kind of JIT; say by compiling each `proc` we see during CTFE if that proc is called > N times, then calling the compiled proc via importc instead of via VM
11:55:15narimiranfor those of you who have missed it when it was originally posted: https://old.reddit.com/r/programming/comments/ac4g03/overthetop_optimisations_with_nim/
11:56:16*lritter joined #nim
11:56:38FromGitter<Clyybber> @timotheecour Do you happen to know where the compiler invokes the linker?
11:56:44FromGitter<Clyybber> I can't seem to find it
11:57:30FromGitter<Clyybber> nvrmind, thats gcc's job right?
11:58:07*dddddd quit (Remote host closed the connection)
11:58:14leorizeare you trying to tweak something?
11:58:30FromGitter<Clyybber> Trying to make --passL:-no-pie a builting default
11:58:50FromGitter<Clyybber> in nlvm, but it shouldn't differ too much
11:59:20FromGitter<qqtop> Warning: Deprecated since version 0.20 since its semantics are unclear; isDigit is deprecated ⏎ Ok, is it replaced by something else or will it go to nim heaven ?
11:59:53leorizeClyybber: add `gcc.options.linker = "-no-pie"` to your nim.cfg
12:00:22FromGitter<Clyybber> Thought about that, but that would be per project, right?
12:00:25rect0x51timotheecour: So it's either faster to interpret or to compile, depending on how many times that proc gets called, right?
12:00:43leorizeClyybber: you could add it to the global nim config file
12:00:51FromGitter<timotheecour> `execLinkCmd`
12:01:05FromGitter<timotheecour> @Clyybber => `execLinkCmd`
12:01:10FromGitter<Clyybber> Thank you
12:01:48FromGitter<Clyybber> @leorize I want to make nlvm work out of the box on distributions where PIE is enabled by default
12:02:00leorizeqqtop: isDigit on string is deprecated
12:02:02FromGitter<Clyybber> But mabye I can get LLVM to generate PIE instead.
12:02:23FromGitter<alehander42> rect0x51 you have to also add the time needed to "compile" the hotspot code: if it's only invoked once, it might be not worth it
12:02:58FromGitter<timotheecour> @qqtop just use isDigit on individual chars, the meaning is less subject to debate
12:03:23rect0x51alehander42: yup I see now
12:03:41FromGitter<qqtop> Fine , thank you all.
12:05:13FromGitter<timotheecour> @alehander42 what do u think of feasibility of using JIT strategy based on compiling to C code a proc (where we’ve timed it to be a bottleneck) , and then using importC FFI ?
12:06:01FromGitter<timotheecour> seems doable, no? also would avoid/mitigate this limitation: `Error: interpretation requires too many iterations;`
12:06:41FromGitter<Clyybber> @leorize You are called differently on github, right?
12:06:52leorizetimotheecour: I believe Araq once talked about doing so for IC
12:06:57leorizeClyybber: yes
12:07:03FromGitter<timotheecour> ```code paste, see link``` ⏎ ⏎ already on this simple program I’m reaching the limit with `n = 3000`, and CTFE is 6X slower than RT [https://gitter.im/nim-lang/Nim?at=5c2dfae76649aa1f82132248]
12:09:22rect0x51Not sure if trying to leverage LLVM is more interesting. Building features on current VM is certainly appealing in many ways.
12:09:32FromGitter<timotheecour> the other question is what’d be overhead of doing JIT compilation via `clang` (system call) vs doing it the standard way (but hard for us, without nlvm) via LLVM?
12:10:04FromGitter<Clyybber> doing it via LLVM without nlvm being upstream is not a good idea
12:11:01FromGitter<Clyybber> rect0x51 I dont think so, it requires a lot of code duplication AFAIK
12:18:43rect0x51but trying to make nimVM work with llvm JIT would require a lot of redesigning right?
12:19:01rect0x51or even a different VM?
12:20:37FromGitter<timotheecour> i believe that’s what nlvm was after, no?
12:24:39rect0x51wait, can nim compiler use the normal C/C++ backend while the VM uses nlvm?
12:24:57leorizewhy not?
12:27:14FromGitter<alehander42> @timotheecour I am not a big expert in JIT-ting, but do you propose to generate simple C files and invoke clang on them initially?
12:27:54FromGitter<alehander42> I suspect this might be a huge overhead: this is what ruby 2.6's experimental JIT does and it invoked a lot of mixed opinions
12:28:40FromGitter<timotheecour> actually in phase 1, yes; (just generate .do / .dylib files)
12:28:53FromGitter<alehander42> (of course, I think they plan to improve their JIT, so it's just a PoC now)
12:30:55FromGitter<alehander42> well, I guess for some situations it would be useful, but we need to benchmark carefully when: executing a full clang invocation seems as a huge amount of instructions/nontrivial IO sys calls
12:31:28FromGitter<alehander42> so probably it would make sense for a "very very hot" spot
12:33:55FromGitter<timotheecour> well currently most of time is in semantic, not in cgen (but the part that’s unclear is how much of it is CTFE); I’m pretty sure at least some types of programs could be sped up at CT via this naive approach
12:36:09FromGitter<timotheecour> phase 2 could leverage a caching compiler (eg reusing types across invocations of JIT) , eg based on libclang / llvm; so the data structures would be kept in memory (eg the C types and procs we are generating) during the whole nim compilation process
12:36:55FromGitter<Clyybber> @alehander42 With a fast C compiler such as TCC or a c interpreter, it might make sense for the whole VM
12:39:08FromGitter<timotheecour> note (for naive approach) that with proper used of shared libraries, we wouldn’t need to rebuild procs we’ve already built; these could be kept in memory, so it’s probably not too bad, eg: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ when building fun_generated2, we don’t need to rebuild fun_generated1. ... [https://gitter.im/nim-lang/Nim?at=5c2e026c33e089363b3a633d]
12:39:57FromGitter<timotheecour> we’ll if we’re gonna use a c interpreter, might as well just use the VM we have; the whole point is to run JIT in hardware, not in interpreter
12:41:59rect0x51if the sole reason for a JIT is to speed up compilation of .nim files, should choose a direct approach
12:42:35FromGitter<timotheecour> Meaning?
12:43:10rect0x51not sure if it's effecient to have C code as an intermediate step
12:43:49rect0x51for nim it has many benefits, for nimvm I don't see any
12:44:03FromGitter<Clyybber> Depends. Projects like Clang/Cling have the advantage of having years of development and as such many optimizations
12:44:22FromGitter<timotheecour> check the example I’ve posted above: it’d benefit there for sure.
12:44:24rect0x51but then again, so does llvm. so maybe nlvm is the way to go?
12:44:56FromGitter<Clyybber> @rect0x51 Yes, nlvm is the way to go IMO.
12:45:16FromGitter<Clyybber> And llvm has advantages for nimvm
12:45:32FromGitter<Clyybber> Its probably faster than the current nimvm
12:45:36rect0x51timotheecour: oh, I see your idea; interesting. this get's too complicated maybe though.
12:45:38FromGitter<timotheecour> the point is with what we have (+ that FFI PR), we’re actually quite close to being able to JIT by calling clang, without having to modify the entire backend
12:47:34rect0x51yeah, well... if it turns out to be so easy to implement a JIT by calling clang, maybe we can try it, but if it needs a lot of work, should consider putting the effort in another direction.
12:49:29rect0x51but I think eventually the backend will have to change... Araq believes it's a dead-end too.
12:50:39FromGitter<timotheecour> i’m interested in what we can do realistically in the next 1-4 months though. NLVM can move forward in parallel.
12:51:51FromGitter<timotheecour> but what this CT FFI opens up in very near future potentially is: ⏎ ⏎ 1) JIT ⏎ 2) REPL ⏎ 3) a lot of code simplification [https://gitter.im/nim-lang/Nim?at=5c2e0567d945b968823ad5a3]
12:54:43rect0x51Having a working REPL soon would be cool yes. Not sure about JIT, I think the long game is more appropriate there.
12:55:28FromGitter<alehander42> @timotheecour I also think CT FFI is cool
12:55:41FromGitter<Clyybber> Yeah it's amazing
12:55:57FromGitter<alehander42> and maybe there is no harm in having an "example" C source clang-based JIT
12:56:01FromGitter<alehander42> if it's simple enough
12:56:21FromGitter<alehander42> but I also think nlvm would surely lead to a better JIT
12:57:01FromGitter<alehander42> I just don't think a c-source-based JIT will offer a big speedup for 80% of nim codebases
12:57:06FromGitter<alehander42> compilation time
12:57:35FromGitter<Clyybber> OTOH it could perhaps replace the VM.
12:57:36FromGitter<alehander42> but this is very subjective, requires benchmarks again, but I'd really suggest people to check carefully discussions around the ruby jit
12:57:46FromGitter<alehander42> before doing anything like that
12:58:35FromGitter<alehander42> my point is: we shouldn't spend too much effort on something like a JIT right now (pre 1.0), if it's not offering obvious huge benefits
12:58:44FromGitter<alehander42> that's something that easily can be done after 1.0
12:58:46FromGitter<Clyybber> I agree
12:59:08*jjido quit (Quit: Connection closed for inactivity)
12:59:45FromGitter<alehander42> but otherwise ffi on ct is awesome
13:09:49FromGitter<arnetheduck> jit / rtti via llvm would not be trivial (well, on the llvm side it's trivial) - the current nim vm is quite.. er.. strongly integrated in the compiler codebase - it has crossed my mind to use the llvm jit as a replacement for it, but that would take some rearchitecting of the compiler itself to make the vm pluggable
13:11:12FromGitter<timotheecour> hence, my suggestion to generate C code for JIT
13:11:15FromGitter<alehander42> but this would be still easier than making similar-speed JIT from scratch
13:12:38FromGitter<arnetheduck> I can't really predict if it would be faster or not - one advantage would be that the same bytecode would be used for both runtime and compile-time, meaning that compatibility would be very good - another is that the bytecode generation pass would only have to be done once - this in turn would make it easier to do aggressive ctfe
13:13:47FromGitter<Clyybber> @arnetheduck Regarding the PIE issue, where does nlvm invoke llvm? It might make more sense to have llvm compile PIE by default.
13:14:36FromGitter<arnetheduck> I haven't really looked too much at those parts of the nim compiler, but I assume there's an interplay between semantic checking and the vm - to nail that interplay in a clean api would take some work, but probably a prereq for using llvm (given that it has a different set of types etc)
13:15:32*Snircle joined #nim
13:16:02FromGitter<arnetheduck> @Clyybber somewhere around https://github.com/arnetheduck/nlvm/blob/master/nlvm/llgen.nim#L6214
13:16:20FromGitter<Clyybber> Ah just found that too, thanks
13:16:22FromGitter<alehander42> another very interesting example is terra , afaik it uses lua for metaprogramming, specifically so it can reuse the LuaJIT ( @zacharycarter probably knows more)
13:16:33FromGitter<Clyybber> Terra is pretty cool
13:18:05FromGitter<arnetheduck> so basically, what llvm does is take one moving part out of the process.. when you generate C code, it's basically `nim -> c -> IR (gcc or llvm) -> machine code` - it might look like less work, but looking at it holistically, it's a more complex solution
13:18:07FromGitter<timotheecour> actually…. here’s a thought: ⏎ during VM, we generate C code using same codegen, but then feed it to llvm/libclang as text input (as opposed to via a C AST); but we don’t shell out to `clang`, instead we call the libclang as library; that way we can stiill reuse generated types/procs across subsequent invocations of libclang
13:19:46FromGitter<arnetheduck> what's the advantage of involving `c`, in that pipeline?
13:19:53FromGitter<Clyybber> No VM
13:20:37FromGitter<timotheecour> advantage: reusing what we have (all our codegen targets C/C++ directly), so it can work in near future without full rewrite to add a llvm backend
13:20:43FromGitter<arnetheduck> no, but.. if you already have `llvm` at your fingertips, what's the advantage of also depending on `clang`?
13:21:02FromGitter<Clyybber> It's actually the reason Araq wants to allow nested statics, because one of his plans was to make the VM use the backend to generate C snippets that can be fed to a fast C compiler
13:21:05FromGitter<Clyybber> Or interpreter
13:22:20FromGitter<arnetheduck> yeah, to a fast c compiler of the user's choice (so it can work on platforms llvm does not yet cover), but not to llvm/clang specifically - there's simply nothing to be gained by that more complicated way of doing things..
13:22:47rect0x51so as arnetheduck pointed out ("one advantage would be that the same bytecode would be used for both runtime and compile-time") this seems to be the only advantage to involve C. The question is how significant it is.
13:22:48FromGitter<timotheecour> nested statics would still work w llvm backend; that’s not a limitation; the limitation I see is it requires a lot of rewrite (shd prob be done eventually, but I’m interested in what we can do in near future, not in 2 years)
13:23:35FromGitter<arnetheduck> well.. have fun :)
13:23:55FromGitter<Clyybber> @timotheecour Nlvm is pretty advanced
13:24:37FromGitter<alehander42> @timotheecour however, again, does it make sense to do it in the near future? there are much more important areas for improvement before 1.0
13:24:57FromGitter<timotheecour> haven’t checked it in a while; is there a doc describing how much works/how much is left to be done for feature parity with nim?
13:25:40*Trustable joined #nim
13:28:12FromGitter<mratsim> CT FFI, so exciting!
13:28:38FromGitter<mratsim> finally we can do const foo {.importc.} ?
13:29:14FromGitter<timotheecour> ironing out edge cases, but ya, a lot of things work, eg: ⏎ ⏎ 1) malloc ⏎ 2) ` let j = snprintf(buffer2, n, "s1:%s s2:%s age:%d pi:%g", s, s, age, 3.14)` [https://gitter.im/nim-lang/Nim?at=5c2e0e2a33e089363b3aac64]
13:29:41FromGitter<timotheecour> i even got `alloca` to work via some hack :)
13:30:34*nsf quit (Quit: WeeChat 2.3)
13:30:58FromGitter<mratsim> Regarding JIT I’m quite interested as well but probably lower level than some JIT like what is done in Julia and more like OrcJIT, asmjit or xbyak. ⏎ ⏎ The main issue is that LLVM brings hundreds of megabytes of dependencies and is the complete opposite of lean.
13:31:16*troido joined #nim
13:32:43FromGitter<alehander42> @mratsim do you want to use it somehow for your ML libs
13:32:58FromGitter<mratsim> Yeah
13:33:21rect0x51eh, JIT is difficult topic. we can either use ready solutions or try to be Mike Paul :D
13:34:05FromGitter<mratsim> I don’t need a general purpose JIT for ML.
13:34:26FromGitter<mratsim> basically I need to be able to compose loops over an array
13:34:39FromGitter<mratsim> similar to zero-functional
13:34:47Araqmratsim: const foo {.importc.} is not possible with libFFI either
13:35:16FromGitter<mratsim> but it should also generate the proper SIMD code depending on your CPU supports (say SSE, AVX on x86 or Neon on ARM).
13:36:52FromGitter<mratsim> I’m fine with static code generation as well, similar to what I do here: https://github.com/numforge/laser/blob/master/laser/primitives/matrix_multiplication/gemm_ukernel_avx_fma.nim and https://github.com/numforge/laser/blob/master/laser/primitives/matrix_multiplication/gemm_ukernel_sse.nim
14:01:18*rokups quit (Quit: Connection closed for inactivity)
14:06:30*ChristianWitts joined #nim
14:18:35FromGitter<zacharycarter> For game engine dev - any route to achieve functionality akin to scripting - whether it be working shared libs via dlopen (useNimRTL) or more VM support for the stdlib to make using Nimscript realistic or hot code reloading being finished
14:18:59*dddddd joined #nim
14:23:15rect0x51what does vmmarshal.nim do? does it emits VM's results in nim code?
14:23:57rect0x51nim ast*
14:31:08*craigger quit (Quit: bye)
14:32:45*Ven`` joined #nim
14:34:13*craigger joined #nim
14:34:46FromGitter<zacharycarter> first line at the top - `## Implements marshaling for the VM.` :P
14:35:12FromGitter<zacharycarter> looks like JSON marshaling
14:35:42rect0x51oh JSON
14:38:00rect0x51I am trying to find where/how the VM exposes its results
14:43:49federico3https://github.com/ixy-languages/ixy-languages pity Nim is not here
14:46:57*kungtotte quit (Remote host closed the connection)
14:48:30rect0x51The VM runs at CT, calculates something, the result is in some VMregister. How does nim compiler know about the CT-calculated result?
14:53:10FromGitter<alehander42> rect0x51 the vm runs inside the compiler
14:53:36FromGitter<alehander42> it shares data structures & everything with it
14:53:45FromGitter<alehander42> afaik
14:55:23rect0x51so it's like... the compiler compiles, and when it sees something that must be evaluated statically it triggers the VM?
14:55:49rect0x51ok I see, I thought the process was more modular
14:57:48rect0x51like a preprocessor of some kind
14:59:57FromGitter<alehander42> I am really not an expert in nim's vm/macro internals
15:00:27leorizerect0x51: the process seems to be tightly integrated with the sem pass
15:00:46FromGitter<alehander42> I guess that's because of macros with typed args
15:01:21FromGitter<alehander42> but probably const expressions and others too?
15:01:21FromGitter<mratsim> @rect0x51 it’s not just a preprocessor, it has a proper stack and registers
15:02:36rect0x51i meant preprocessor in the big picture, like running before even the compiler begins to compile, but that's the opposite of how it works apparently
15:03:22FromGitter<alehander42> well, it wouldn't be possible, as at least macros require AST objects
15:03:41FromGitter<mratsim> it runs before GCC/Clang run
15:03:43FromGitter<alehander42> so even if you had a simpler untyped macros-only kind of metaprogramming
15:03:53FromGitter<alehander42> you'd need to parse the source first
15:04:12FromGitter<alehander42> don't really try to think of it as similar to C macro preprocessors
15:06:57FromGitter<alehander42> basically, I imagine it is parse(string) => PNode => expand(run) untyped macros => sempass => run other ctfe & typed macros => sempass again results of typed macros => other analyses => codegen
15:07:15FromGitter<alehander42> very roughly
15:07:56FromGitter<alehander42> but i am not sure if this is entirely true
15:10:19rect0x51ok so it basically produces AST and works with the semantic part of the compiler to validate it, right?
15:10:53*ChristianWitts quit (Ping timeout: 246 seconds)
15:20:57rect0x51Typed macros (AST) => VM IR => AST
15:24:39*nsf joined #nim
15:25:53leorizeI don't think there's any VM IR
15:26:16leorizethe VM works directly on the AST IIRC
15:27:57FromGitter<arnetheduck> I'd generally agree that llvm is a bit too heavy as well for integration purposes (scripting engine in game).. there's some things you can strip down in it, but it's really not a design goal
15:27:57*stefanos82 quit (Ping timeout: 252 seconds)
15:28:11FromGitter<arnetheduck> vm has an ir (see vmdef.nim)
15:30:21*sheerluck joined #nim
15:34:31FromGitter<zacharycarter> if hot code reloading materializes - scripting languages for gamedev will be a lot less of an attractive option
15:35:44dom96_wthe VM used to work directly on the AST
15:35:53dom96_wthat was before it was a VM :)
15:36:03FromGitter<arnetheduck> yeah, but it's not without reason projects switch away from the llvm jit: https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/
15:36:35FromGitter<arnetheduck> ie it's a good jit, but not necessarily for every occasion out there
15:37:56FromGitter<zacharycarter> right
15:38:52*stefanos82 joined #nim
15:39:16FromGitter<zacharycarter> need to motivate myself to get back to working on the pbr rendering code for my project today - I have all of the shell code written and it's now just implementation and then refactoring
15:39:57FromGitter<zacharycarter> all of the pipeline creation logic and draw pass related logic is in place though (for a forward renderer anyway - I'll tackle deferred afterwards)
15:42:49rect0x51arnetheduck: do you know how the VM IR is converted back to AST? can you point me to a .nim file or a proc?
15:43:32FromGitter<arnetheduck> the vm ir is not converted back.. it just executes stuff that builds more ast oblivious of it being executed by an ir
15:44:25rect0x51ok so which procs build the ast?
15:45:18FromGitter<arnetheduck> all over the codebase.. parser, macros, transformations, cgen sometimes..
15:47:57shashlickI am also looking for nim as an embedded scripting language
15:47:59FromGitter<arnetheduck> for macros and vm, basically the macro runs and creates a subtree in memory, then the compiler plucks that subtree into the place where the macro was, and keeps going
15:48:05shashlickso the ffi support is really great
15:48:23shashlickbut i don't see the point in llvm for such a use case, becomes too heavy
15:48:29shashlickplus on windows, it is mainly gcc
15:51:05FromGitter<zacharycarter> looks like the HCR branch just got rebased - https://github.com/onqtam/Nim/commit/643391b26a3081f4340f1fbc155b81f8dd4981d7
15:51:09FromGitter<zacharycarter> I wonder if it could be played with now
15:51:15FromGitter<zacharycarter> with 0.19.2
15:51:41FromGitter<zacharycarter> has anyone had any communiation with @onqtam lately?
15:52:43shashlicki wonder how they are working in isolation
15:52:54shashlickwill get hard to integrate changes if it is one gigantic blob
15:53:03FromGitter<zacharycarter> I have no idea
15:53:26FromGitter<zacharycarter> I assume he's working with Zahary wo works closely with Araq and other core devs
15:53:32FromGitter<zacharycarter> but I'm just making assumptions
15:54:02FromGitter<zacharycarter> either way - I'm eager to get my hands on / play with this new feature
15:54:31FromGitter<zacharycarter> even if it's in an unfinished state - as long as it's somewhat close, which from my following of the commit history over the past month(ish) - it seems to be
15:54:32shashlicki've tried big PRs in the past and they aren't easy to review or get accepted
15:54:42shashlickand by big I mean less than 100 lines
15:54:45*PMunch quit (Remote host closed the connection)
15:54:47FromGitter<zacharycarter> heh
15:55:01FromGitter<zacharycarter> yeah - no idea on how that goes - I'm not a core dev / even really a contrib
15:55:16shashlickthat's my strategy going forward, split into small piecemeal PRs which are easy to push through
15:55:30FromGitter<mratsim> @zacharycarter yes He is working with Zah, and I think his changes are additive instead of replacing core logic.
15:55:41FromGitter<zacharycarter> ah sweet
15:55:57FromGitter<zacharycarter> I think this is a problem inherent with git flow anyway - big PRs are always messy
15:55:59FromGitter<zacharycarter> and slow
15:56:22*xet7 joined #nim
15:56:24shashlick@dom96: i've broken my choosenim PR into smaller ones - here's #1 - https://github.com/dom96/choosenim/pull/100
15:56:38FromGitter<zacharycarter> thanks @mratsim
15:56:50shashlicknext in line is replacing untar with nimarchive so that we can extract zip, 7z, xz or gz seamlessly
15:57:09shashlickgoal being that the same .xz file can be used on windows and osx as well since it is so much smaller
15:57:38shashlickand we can use the same dlls.zip mingw32.7z, etc that are on the website
16:02:18shashlickDon't need the powershell hack for windows zip
16:03:31Araqcan people please test the nightlies releases? we're about to use them for 0.19.4
16:07:22FromGitter<alehander42> Araq: is incremental:on ready to at least experiment with
16:08:22leorizeAraq: where can we get the nightlies?
16:08:59Araqalehander42: it's a good 50-50 chance
16:16:33Araqhttps://github.com/nim-lang/nightlies/releases leorize
16:35:37dom96_wshashlick: thanks. I'll take a look when I'm home.
16:50:25*theelous3 joined #nim
16:51:37*theelous3_ joined #nim
17:03:29*rect0x51 left #nim ("WeeChat 2.3")
17:06:29*Ven`` quit (Read error: Connection reset by peer)
17:12:51*ripspin quit (Quit: Leaving)
17:15:45*cspar_ joined #nim
17:18:23*cspar quit (Ping timeout: 245 seconds)
17:19:36*thomasross_ joined #nim
17:19:36*thomasross quit (Killed (cherryh.freenode.net (Nickname regained by services)))
17:19:36*thomasross_ is now known as thomasross
17:20:27*thomasross quit (Max SendQ exceeded)
17:26:27*abm quit (Ping timeout: 240 seconds)
17:42:53*kapil____ quit (Quit: Connection closed for inactivity)
17:50:42*floppydh quit (Quit: WeeChat 2.3)
17:51:46*Trustable quit (Remote host closed the connection)
17:59:54FromGitter<xmonader> is the preview button broken in nim forum?
17:59:57*dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:00:09FromGitter<xmonader> also is there a possibility to allow markdown along with rst?
18:03:26narimiranpreview works for me
18:03:44narimirancurrently forum uses some mix between rst and markdown
18:04:13narimirani know that dom96 once said he has nothing against making forum markdown-only
18:04:30FromGitter<xmonader> @narimiran can you verify that my account is working? i still can't post i use `aredirect`
18:05:01FromGitter<xmonader> I just can't remember RST and i've to look at the guide unlike markdown
18:05:08narimirani can see your post, if that is what you're asking
18:06:03FromGitter<xmonader> oh! i wasn't redirected don't know why i thought the buttons were hanging
18:07:13narimiranif you want to edit your post, you can use > for quotations (it looks like you didn't use it)
18:08:07narimiranmost of the people are much more familiar with markdown, and i think using markdown would be a step forward
18:08:36*stefantalpalaru joined #nim
18:08:40FromGitter<xmonader> nim is tightly integrated with github which uses markdown as default. I agree
18:08:53FromGitter<xmonader> or at least provide the option so we don't break the other posts
18:10:21narimiranbtw, thank you very much for writing your reply! detailed and on-point! much appreciated!
18:12:46FromGitter<xmonader> sure thing! I believe it's community focus time :)
18:13:11*vivus joined #nim
18:13:37stefantalpalaruNew compiler bug in HEAD, possibly related to a loss of type information for a `defer` inside nested templates: https://github.com/nim-lang/Nim/issues/4567#issuecomment-451228961
18:13:47*Sembei joined #nim
18:13:58*Pisuke quit (Ping timeout: 250 seconds)
18:16:26narimiranworks fine on 0.19.2, fails on devel
18:17:16FromGitter<arnetheduck> @Araq that's one of the bugs I was referring to the other day when noting that ast nodes lack `typ` sometimes.. it's still a problem for `nlvm` for example
18:20:23*Jesin quit (Quit: Leaving)
18:23:31*nsf quit (Quit: WeeChat 2.3)
18:23:54Araq"sometimes" is not a bug report :P
18:26:38*wildlander joined #nim
18:28:17FromGitter<arnetheduck> it's very specific in that bug report
18:28:45FromGitter<arnetheduck> there's another which is more complicated as well, which is why it doesn't yet have a bug report
18:30:21FromGitter<arnetheduck> chances are fix 4567 will fix it by accident so might as well wait ;)
18:46:32*sheerluck quit (Quit: Leaving)
18:50:10*Geezus joined #nim
18:51:57*Ven`` joined #nim
19:05:24*seni joined #nim
19:07:37*Geezus is now known as Geezus42
19:24:18shashlick@dom96: on forum, would help if it remembered my login longer, I have to log in every time I want to post
19:26:21FromGitter<alehander42> yes, please, very unpleasant
19:26:50FromGitter<alehander42> maybe we can add a "remember me" option ?
19:27:05*nsf joined #nim
19:49:50*abm joined #nim
19:50:32*zachk joined #nim
19:58:28*ChristianWitts joined #nim
19:59:44dom96shashlick: it should remember your login
20:00:13dom96but yeah, I've noticed that it logs me out sometimes too
20:00:20dom96Not sure what the cause is
20:01:57*nsf quit (Quit: WeeChat 2.3)
20:03:27*ChristianWitts quit (Ping timeout: 240 seconds)
20:04:12*ChristianWitts joined #nim
20:05:23*ChristianWitts quit (Remote host closed the connection)
20:11:23shashlickwell it stays logged in but for a very short time
20:12:36FromGitter<kaushalmodi> dom96: aren't you using some location based login remembering?
20:13:07FromGitter<kaushalmodi> that doesn't work for mobile access. Every time I change location (home <-> work), I am signed out from the forum on my phone
20:13:49dom96It used to be like that but I fixed this
20:13:57dom96But maybe I didn't deploy it yet
20:14:05FromGitter<kaushalmodi> hmm, but I still keep getting signed out
20:14:05shashlickthat's probably it, typically have this happen on my phone
20:14:20shashlicknot as often on laptop
20:18:54FromGitter<zacharycarter> MD was designed for web content
20:18:58FromGitter<zacharycarter> RST was designed for technical docs
20:19:01FromGitter<zacharycarter> just adding to the convo above
20:21:48FromGitter<Clyybber> @arnetheduck I can't seem to find a way to make `-no-pie` a default option for the linker in nlvm without copying more of Nim's procedures.
20:22:05dom96Don't worry, MD will happen for the forum eventually
20:22:52FromGitter<Clyybber> @arnetheduck Perhaps its better to make llvm generate PIE/PIC binaries by default instead.
20:23:01FromGitter<kaushalmodi> dom96: You are probably aware of https://github.com/soasme/nim-markdown
20:23:23FromGitter<kaushalmodi> may be that can be leveraged for markdown parsing
20:24:25dom96Looks beautiful :)
20:25:38narimiranbut for not breaking the existing post, markdown and rst should co-exist? :/
20:26:24narimiran*posts, plural
20:27:02FromGitter<kaushalmodi> narimiran: may be run pandoc through all posts database to convert from rst to md? :P
20:27:13*seni_ joined #nim
20:27:21FromGitter<kaushalmodi> .. but the problem is that folks are typing in md by default already
20:27:41dom96I would be happy to support both
20:27:52dom96I'm sure it would keep Araq happy :)
20:27:55narimiranheh, i think it is easier than that. italic and bold are already ok, as are code blocks
20:28:15narimiranand for verbatim text, people are already using single backticks most of the time
20:28:42Zevvdom96: I just hunted down unexpected memory usage for my app. +40Mb seems to be reserved for fds in epoll selector because my rlimit_open files happens to be quite hight. Is this normal behaviour?
20:28:50narimiran(un)numbered lists are also ok
20:29:04narimirantables are not, but i don't see anybody using them.
20:29:31narimiranand links currently support only rst syntax
20:29:36*seni quit (Ping timeout: 250 seconds)
20:29:58Zevvlove dumpN
20:30:05ZevvumberOfInstances, btw
20:30:05narimiranso basically: allow [text](url) and `verbatim`, and that's it :)
20:30:38dom96Zevv: yes, that's by design AFAIK
20:31:04dom96there is an issue about it somewhere
20:31:32Zevvoh sorry I should have looked first
20:33:09Zevvfound it: having high ulimits is your own fault, use setrlimit if the memory is a problem. fair enough
20:34:50AraqZevv, IMO it should be fixed
20:35:07Araqbut other frameworks use the same speed hack
20:35:26Araqso there is some general lesson to learn here... maybe.
20:35:39FromGitter<Clyybber> Make it configurable?
20:35:52*kungtotte joined #nim
20:36:32Zevvthe problem is that you dont know about the memory usage until you dig all the way in
20:37:12dom96I think it should be fixed too FWIW :)
20:37:37ZevvI'm trying to introduce Nim in my company. People are sceptic and critical, so I had to explain this away.
20:37:50dom96I bet it can be made to allocate in chunks and not lose too much efficiency
20:38:11dom96Zevv: Cool. If you don't mind saying, what company is it?
20:38:12ZevvI guess so, just start with a sane amount and increase in powers of two, something like that
20:38:36dom96hehe, that's precisely the behaviour that `seq` has
20:38:55FromGitter<Clyybber> And the GC
20:39:47FromGitter<Clyybber> nvrmind, dumb statement
20:41:18Zevv1024 file descriptors should be enought for everyone
20:41:35Zevvoh, wait, I use 128k
20:41:52FromGitter<Clyybber> Yeah, 1024 is a *bit* limited
20:42:09Zevvstill the default on lot of os'es
20:43:43FromGitter<arnetheduck> @Clyybber that's fine by me. just drop a note why.
20:43:56FromGitter<Clyybber> @arnetheduck Alright, will do
20:49:52FromGitter<zacharycarter> FD's get opened for a lot
20:50:21FromGitter<zacharycarter> and if you're doing recursive FS ops, you'll run out quickly
20:50:23FromGitter<Clyybber> How can I revert commits with the Github interface?
20:50:33FromGitter<zacharycarter> not sure you can...
20:51:10FromGitter<zacharycarter> https://ohshitgit.com/
20:51:20Zevvhehe
20:51:59FromGitter<Clyybber> @zacharycarter Yeah I'll just push it from my local clone I guess
20:52:09dom96narimiran: still no tweet?
20:52:32*endragor joined #nim
20:52:35FromGitter<Clyybber> Boggles me though. Github attracts so many people that use "Add files via upload...", yet has no builtin way to revert a commit :P
20:52:48FromGitter<zacharycarter> git in general is too complicated
20:53:18FromGitter<Clyybber> Better than subversion :P
20:53:23FromGitter<zacharycarter> soooo 0.19.4 will become the new stable right? Is this some emergency bugfix?
20:53:43FromGitter<zacharycarter> @Clyybber - true - mercurial may be the simplest / best bet
20:54:07FromGitter<zacharycarter> unless you want people t find your project :/
20:56:34narimirandom96: we're putting that on hold until 0.19.4 is out
20:57:53dom96But it's been released...:/
21:00:05dom96It's a bit dishonest to not tweet about it because it was a "bad release"
21:00:16FromGitter<Clyybber> Website still shows 0.19.2?
21:00:29FromGitter<Clyybber> Why are we skipping 0.19.3?
21:00:40FromGitter<Clyybber> Sorry for all my misconceptions :P
21:00:49dom96Clyybber: odd releases are devel
21:00:52dom96they are never released
21:01:11FromGitter<Clyybber> Huh, has it always been that way?
21:01:25dom96yep
21:01:54FromGitter<Clyybber> Never noticed, am on devel anyways
21:01:55FromGitter<zacharycarter> I don't see any 0.19.4 on github releases page
21:05:16FromGitter<Clyybber> @arnetheduck Should I remove RelocDefault as well? It has been removed/deprecated in LLVM since 3.9 ?
21:05:38dom96Well I'm going to tweet about it. Any release is publicity, even if a new one is coming soon
21:06:24FromGitter<Clyybber> @dom96 Wether or not publicity is good for a project, depends heavily on the phase its currently in
21:06:48FromGitter<zacharycarter> where does the release reside?
21:07:05FromGitter<Clyybber> Its not on the website
21:07:26FromGitter<zacharycarter> or github releases page
21:09:37dom96?
21:09:42dom96Where did we say that 0.19.4 is out?
21:12:04FromGitter<Clyybber> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c2e7aa45a0a8058be23d73c]
21:12:11FromGitter<Clyybber> got confused by that
21:15:13*zachk quit (Changing host)
21:15:13*zachk joined #nim
21:17:18shashlick@dom96 any luck with the choosenim pr
21:17:35shashlickIt's small, should be quick
21:17:58shashlickI need it in for the next one
21:19:52narimirandom96: there are some problems with 0.19.2, so Araq said we should wait with announcements
21:20:04narimiranbut i guess it is too late now, it is already on twitter
21:23:39*theelous3_ quit (Ping timeout: 268 seconds)
21:25:54dom96It's a bit strange to wait now, after it's already been announced in the forum and on the Nim website
21:26:48dom96Also, the problems with this release don't affect a significant portion of people IMO
21:26:58dom96Based on what Araq has told me it's just the `koch test` issue
21:29:48narimiranok, but i'll wait with reddit/HN until 0.19.4 is out
21:30:19dom96Sure, but somebody else already submitted to HN
21:30:27dom96(it didn't get onto the front page)
21:32:08dom96shashlick: Regarding your choosenim PR, won't this fail if the user doesn't have `gcc` in their PATH?
21:36:36shashlickThat's already covered in build()
21:36:55shashlickI'll move the gcc code when it is needed in the next pr
21:37:05dom96alright
21:37:32shashlickNeed it earlier in download() where we have to detect the right windows zip to download
21:37:44shashlickBut that's next
21:38:27shashlickI'm also wondering how many people want 32 and 64 bit to coexist
21:38:42shashlickBut that's for another day
21:40:13shashlick@dom96 do you create tar.gz only for choosenim windows?
21:41:06dom96yeah, I think so
21:41:30shashlickI hope to migrate to xz so we can use the same smaller archive
21:41:53shashlickWill benefit osx
21:42:13dom96that would be great, as long as you can omit a DLL
21:42:22dom96AFAIK macOS already uses xz as long as `unxz` is in PATH
21:42:25shashlickAbsolutely
21:42:37shashlickDidn't look like from the code
21:44:15*narimiran quit (Quit: Leaving)
21:44:23FromGitter<arnetheduck> likely, the 32-bit edition of the compiler is faster on any platform
21:46:52Calinouis the difference significant enough?
21:47:22Calinouby the way, that reminds me, would compiling the Nim compiler with LTO enabled be beneficial to the compiler speed? I just did that here but I haven't benchmarked it
21:47:46Calinoualso, last time I checked, you need a 32-bit Nim compiler to compile for 32-bit platforms (mostly Windows, these days)
21:47:56Calinouotherwise, you get a "Nim and C compiler disagree on target architecture"
21:48:11Calinoubut that might be PEBKAC from my side, I don't know :)
21:52:32FromGitter<Varriount> dom96: What's this have regarding fd limits?
21:53:38Calinoudom96: most Docker images I've used don't bundle xz-utils, so they can't decompress xz archives until you install `xz-utils`. It's still a small package (~80 KB in Debian)
21:53:51Calinouunlike gzip which is almost always present by default
22:03:00*craigger quit (Quit: bye)
22:04:40shashlickI'm planning on using nimarchive
22:04:45FromGitter<Clyybber> @arnetheduck PR is up https://github.com/arnetheduck/nlvm/pull/10 ; still running CI because travis is slow af, but it works on my setup (and should work everywhere).
22:04:51shashlickNeed to add liblzma though
22:06:23*craigger joined #nim
22:17:41*stefanos82 quit (Remote host closed the connection)
22:43:17*lritter quit (Ping timeout: 244 seconds)
22:46:19Araqshashlick, pushed a different 'koch testinstall'
22:47:03Araqdecided to change what we already have. Nightlies might work with that.
22:47:13FromGitter<timotheecour> @araq is there a proc in stdlib that aligns a string (representing a table) in csv/tsv/(or custom delimiter) ?
22:47:19Araqwe can backport it later
22:47:48Araqtimotheecour: strutils.align or fmt ?
22:47:49FromGitter<timotheecour> eg: ⏎ `abc\tdefghi\t123\nac\thi\t12332232` => shall produce aligned columns
22:48:19FromGitter<timotheecour> i searched but couldn't find it; it’d be very useful and was gonna do it if it’s not there
22:49:29FromGitter<timotheecour> strutils.align is definitely not it ; the alignTable I’m thinking of will automatically compute column width for each column
22:51:05Araqin the ideal world you would output abc\tdef\txyz and your terminal would render it as a table
22:52:20FromGitter<timotheecour> except not, because it’s TAB only aligns up to a max tab size and it breaks down; eg here’s code listing: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c2e92242863d8612bd3d78c]
22:53:02FromGitter<timotheecour> it uses tabs and aligns at discrete intervals of, but with what i’d suggest, it’d align perfectly.
22:53:11Araqplease read again what I wrote. I wrote it exactly for you.
22:53:50FromGitter<timotheecour> does ur terminal render it as a table? mine doesn’t (on OSX using most popular terminal, iterm2)
22:54:04Araqno, it doesn't.
22:54:47FromGitter<timotheecour> Ok; then I can add `alignTable(s:string, delim=‘\t’): string` to strutils
22:54:57shashlickAraq: I'll try out the new testinstall and see if it works any faster - presume it is still just for linux/osx cc @kaushalmodi
22:55:49Araqobviously not, timothee ;-) it would be std/asciitables.nim
22:56:03Araqor maybe ... unicode tables?
22:56:10FromGitter<timotheecour> Ok; so PR accepted?
22:56:24Araqand then you need to fight for why it should be in the stdlib and not a nimble package...
22:57:26FromGitter<timotheecour> eg use case: i wanna use it in above code listing(vmgen.codeListing)
22:57:50Araqyeah that's what I thought
22:58:25AraqI think compiler/asciitables.nim is ok, we can later move it to a nimble package
22:58:27FromGitter<timotheecour> btw trying to figure out a bug where a register gets wronlgy free’d for the FFI CT PR
22:58:39Araqonce the compiler is allowed nimble packages.
22:58:46Araqor we move it over to std/
22:59:04FromGitter<timotheecour> how about experimental/std as in diff ? that’d make most sense
22:59:21FromGitter<timotheecour> then other ppl can use, with idea that they shouldn’t complain in case of breaking changes
22:59:30AraqI don't like 'experimental' at all.
22:59:58Araqit guarantees we will break code and assumes we're too stupid to get simple APIs right and have no .deprecate feature
23:00:58Araqand yeah, we did indeed get the API wrong for diff.nim, but that's only because I couldn't use it and got distracted in discussions about it
23:02:19FromGitter<timotheecour> i’ll put it in compiler/asciitables.nim and we can bikeshed later then
23:02:28Araqok thanks
23:10:05*ofelas joined #nim
23:19:05*endragor quit (Remote host closed the connection)
23:26:18*dom96_w joined #nim
23:32:30*Vladar quit (Remote host closed the connection)