<< 03-12-2018 >>
00:08:29*sz0 joined #nim
00:18:27FromGitter<yyyc514> what is the proper way to write out multiple simple pragmas?
00:20:46*fthe quit (Ping timeout: 250 seconds)
00:33:21FromGitter<Varriount> @yyyc514 Are the pragmas in the function signature?
01:03:55cavariux@zacharycarter I googled image/file to hex and use the first result :p. And to read it I used stb_image read from memory
01:06:00FromGitter<yyyc514> {.blah,.blah2}
01:06:12FromGitter<yyyc514> i didn't understand {. was the bracket :)
01:06:36*jakob0094 quit (Remote host closed the connection)
01:07:56FromGitter<zacharycarter> gotcha - thanks cavariux :) - I'll have to ask the bgfx author what DOS program he was using again
01:14:21*lritter quit (Ping timeout: 246 seconds)
01:15:10*lritter joined #nim
01:22:39*matti joined #nim
01:42:00FromGitter<gogolxdong> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c0489e8500e8e37284ea486]
01:43:43FromGitter<gogolxdong> Have no idea why the result differs.
01:43:58*smitop quit (Quit: Connection closed for inactivity)
01:44:48FromGitter<gogolxdong> with other implementation
01:50:03*ftsf joined #nim
01:52:39*vlad1777d quit (Ping timeout: 252 seconds)
02:13:18*sz0 quit (Quit: Connection closed for inactivity)
02:21:47*ng0_ joined #nim
02:24:51*ng0 quit (Ping timeout: 256 seconds)
02:52:30FromGitter<yyyc514> so are there any details docs on where the type is stored for dynamic dispatch? i could probably just flip the type and it'd just work as long as the memory allocatiosn were the same
03:07:42*banc quit (Quit: ZNC - http://znc.in)
03:21:53FromGitter<yyyc514> ok are refs just dumb pointers?
03:22:02FromGitter<yyyc514> they seem to be stacked back to back and i can't find any type information hidden there
03:25:53*banc joined #nim
03:46:24*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
04:00:49*lritter quit (Ping timeout: 252 seconds)
04:54:46*narimiran joined #nim
04:57:55*endragor joined #nim
04:59:13narimiran1 minute to go, who's here? :)
04:59:24FromGitter<Vindaar> yup
04:59:36narimiranof course :)
04:59:49FromGitter<Vindaar> :D
05:10:14*nsf joined #nim
05:17:52FromGitter<kdheepak> This one was fun.
05:18:21FromGitter<kdheepak> I think the pressure of getting the result quickly has me making mistakes that I would have otherwise not have made.
05:21:35FromGitter<yyyc514> i thought refs were supposed to be kind of automatic? i need to dereference all the time?
05:25:00FromGitter<kdheepak> @yyyc514 you probably don't need to. Are you using `ptr`?
05:25:10FromGitter<yyyc514> nope, ref
05:25:25FromGitter<kdheepak> If you use `ref` I don't think you need to deference.
05:25:54FromGitter<kdheepak> You do need to use `new`, but the garbage collector will take care of deallocation.
05:27:34FromDiscord_<technicallyagd> Damn. I was going to write some utility procs for working with grids yesterday
05:28:23FromGitter<kdheepak> Haha.
05:28:24FromDiscord_<technicallyagd> but decided to put it off for later
05:28:38narimiran:)
05:28:48FromDiscord_<technicallyagd> damn Murphy's law
05:29:15FromDiscord_<technicallyagd> I ended up with a really inefficient solution
05:29:28narimiran@technicallyagd what are you planning to do today, but you will put it off? asking for a friend
05:29:30FromDiscord_<technicallyagd> took about 1 second to run
05:30:00FromDiscord_<technicallyagd> @narimiran sorry, I don't quite understand the question
05:30:25narimiranah, i wanted to know what will be tomorrow's task ;)
05:30:31FromDiscord_<technicallyagd> LOL
05:32:04FromDiscord_<technicallyagd> Will, it's actually kind of a confirmation bias. I think I decided to put off writing a lot of things yesterday.
05:33:08FromDiscord_<technicallyagd> But I think parsing today's instruction took me a lot of time also.
05:33:50FromDiscord_<technicallyagd> the # and : and NUMxNUM are quite atypical for all the tasks I have seen so far
05:33:56narimiranparsing was the easy part for me (just one mistake :P), but later on i've made some typos which have cost me two failed attempts
05:34:44narimirani don't want to spoil/help for the guys who are still solving, but there's an easy way to parse inputs like this one
05:34:46FromDiscord_<technicallyagd> lol I was tripped up by mgetOrPut
05:35:53FromDiscord_<technicallyagd> I definitely wish I knew, have you used it in your solutions in earlier years?
05:36:11FromDiscord_<technicallyagd> maybe I could find them myself
05:38:52narimirani've used it in AoC 2015, days 6 and 15
05:39:27FromDiscord_<technicallyagd> I thought mgetOrPut returns a mutable reference to the entry
05:39:37FromDiscord_<technicallyagd> @narimiran Thank you!
05:40:37FromDiscord_<technicallyagd> but assigning the returned value to a new variable seems to copy the content though
05:40:56FromGitter<Vindaar> oh damn, I wasted more than 10 minutes at the end, because I forgot to skip the part I was looking at when comparing it to others, duh
05:40:57narimiranyeah, i never used `mget`, not my cup of tea
05:42:38FromDiscord_<technicallyagd> it's actually quite convenient while working with a table of seq's
05:43:35FromDiscord_<technicallyagd> @Vindaar lol I think we've all been there
05:44:53FromDiscord_<technicallyagd> @narimiran THANK YOU! this is exactly what I was looking for.
05:46:38narimiran:)
06:02:00FromGitter<yyyc514> can you forward-declare types across multiple files? i have a recursive dependency
06:08:40leorizeno, unfortunately
06:09:00leorizethere's package-level declaration for that, but personally I rarely find it useful
06:10:35FromGitter<yyyc514> package level declaration?
06:12:19leorizehttp://nim-lang.github.io/Nim/manual.html#types-package-level-objects
06:29:47*fredrik92 quit (Read error: Connection reset by peer)
06:30:14*fredrik92 joined #nim
06:54:44*kapil____ quit (Quit: Connection closed for inactivity)
06:59:00*narimiran quit (Ping timeout: 250 seconds)
07:08:57*krux02 joined #nim
07:42:06FromGitter<AchalaSB> What this error represent with `gc:stack or gc:region` ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c04de4dbc1a693e3a4a1b0a]
07:42:16TangerHey folks, anybody know of any references for migrating macros over from v0.18 to v0.19?
07:53:18*navin joined #nim
07:56:28*kapil____ joined #nim
08:02:41*tribly quit (Quit: WeeChat 2.3)
08:03:50*ftsf quit (Quit: Leaving)
08:08:12leorizeTanger: https://nim-lang.org/blog/2018/09/26/version-0190-released.html
08:08:18leorize^ the changelog would be a good start
08:08:48leorizebut looks like there weren't any breaking changes related to macros
08:09:15Tangerleorize, Thanks. I had a look at that and the macros module as well. I wasn't a fan of the "Deprecated since version 0.18.1; All functionality is defined on NimNode." deprecation message
08:09:31TangerBut now it makes sense (ie, replace all ident nodes with NimNodes and voila!)
08:14:08FromGitter<alehander42> Araq: do you use strformat inside the compiler
08:20:30Araqno and I don't like it
08:20:45AraqI was against strformat before we added it
08:31:20FromGitter<alehander42> eh, ok `shrugs`
08:38:29*navin quit ()
08:39:06*PMunch joined #nim
08:39:24*PMunch quit (Remote host closed the connection)
08:39:29*PMunch_ joined #nim
08:42:48*PMunch_ quit (Read error: Connection reset by peer)
08:48:49*PMunch joined #nim
08:52:52FromGitter<alehander42> Araq: this is my (mostly) last week's prototype for nil ref
08:52:52FromGitter<alehander42> https://github.com/alehander42/Nim/commit/60bf30d374fe9214ff7530f11f2e482d8baa328f
08:53:27FromGitter<alehander42> on the top are the rough rules of what I was planning (some or implemented)
08:54:16*Gertm left #nim ("Leaving")
08:56:11FromGitter<narimiran> could `ns = line[0 ..< i] & '_' & line[i+1 ..< line.len]` be optimized, or should i just manually do `ns[0 ..< i] = line[0 ..< i]` etc.?
09:03:24FromGitter<narimiran> nvm, next time i should figure out that my second version had an error, and that's why it was 4x faster than the first (working) version :)
09:05:15*floppydh joined #nim
09:24:36*dom96_w joined #nim
09:24:38Araqalehander42: seems useful but I would make every ref parametet not-nil implicitly
09:28:09Araqthen to be able to call f(myvar) myvar must be provably not-nil
09:28:46Araqand for this in 'var myvar = g()' g must also return a not-nil ref
09:29:57Araqthen you have to prove that all paths lead to a 'result = ...' assignment
09:32:39FromGitter<narimiran> Araq: is there a reason why we have `break <label>` but not `continue <label>`?
09:33:07Araqyes. labels only exists for 'block' not for loops
09:33:28Araqand continue only works with loops
09:34:10FromGitter<narimiran> ok, i thought so. i'll use break
09:47:27PMunchHmm, interesting: gcc: error: /home/peter/.cache/nim/nimlsp_d/linenoise.c.o: No such file or directory
09:47:46PMunchSomething seems to have missed a file..
09:57:43PMunchHmm, switching to devel seemed to fix it
10:18:18*tribly joined #nim
10:48:37*ng0_ quit (Ping timeout: 256 seconds)
10:50:12FromGitter<alehander42> Araq: but what if your `g` can return nil?
10:50:22*ng0_ joined #nim
10:51:16FromGitter<alehander42> yeah, that's correct about result, I forgot about that: I wanted that especially because i already had such a nil bug in my prototype itself, haha
10:52:44FromGitter<alehander42> i'd love to have non-nil ref by default
10:53:19FromGitter<alehander42> but I can't see how this can work with the other more unsafe code around (e.g. stdlib/other existing libs)
10:56:26FromGitter<alehander42> otherwise you have ref being `not nil` by default in checked procedures and `maybe nil` by default in unchecked procedures
10:56:54Araqwell 'g' would then say returns 'ref T or nil'
10:57:02Araqor 'nil ref T'
10:57:11AraqI think that syntax already exists
10:57:27FromGitter<alehander42> huh, I didn't know of `nil ref`
10:59:38FromGitter<alehander42> but my point is, checked procedures have to assume that they might call unchecked procedures
10:59:57FromGitter<alehander42> and e.g. the stdlib is unchecked, it's not an edge case
11:00:45FromGitter<alehander42> and the stdlib `g` currently says `ref T`, not `nil ref T`
11:02:22FromGitter<alehander42> tl;dr the existing unchecked code(e.g. stdlib) uses the opposite default, how do i deal with that
11:19:29FromGitter<alehander42> also, notice that `not nil` args infect the caller: we have to check(& change) all unchecked callers of functions with `not nil` too, so if this is the default, we have to change a lot of the stdlib, we can't just say "dont check this"
11:43:24*dom96_w quit (Ping timeout: 268 seconds)
11:57:07*jakob0094 joined #nim
12:06:48*btbytes_ joined #nim
12:14:59FromGitter<zacharycarter> everyone finish their ld entries?
12:15:07FromGitter<zacharycarter> I guess there's an extra day or something for the 72 hour jam
12:15:45FromGitter<zacharycarter> looking forward to playing some
12:26:06*Vladar joined #nim
12:34:36*stefanos82 joined #nim
12:44:29*dddddd joined #nim
12:44:31Araqalehander42: Think about how this feature should work ideally, we can always patch the stdlib
12:48:45FromGitter<alehander42> Araq: well, ideally I agree it should be the default, I am just saying it breaks a lot of existing code (3rd party libs too): ⏎ I think we can for now we can have a global flag that changes the default everywhere , but make it off by default: fix existing code to use correctly `nil ref` / `ref` and when it's mature enough, the global flag can be turned on by default
12:48:52*fthe joined #nim
12:50:59*fthe quit (Remote host closed the connection)
12:53:18*ng0_ quit (Quit: Alexa, when is the end of world?)
12:55:23*ng0 joined #nim
13:07:21*vlad1777d joined #nim
13:09:23*dom96_w joined #nim
13:19:19*btbytes_ quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:21:17*Snircle joined #nim
13:26:52Araqalehander42, yeah sure, we will find a migration path
13:34:26FromGitter<arnetheduck> +1 not nil default.. also, +1 on having it check that a function that should return a value returns a value / assigns a result.. akin to how you have an expression if, and all branches must return something
13:36:38FromGitter<alehander42> @arnetheduck I absolutely agree with Araq here, I was only pointing out that a lot of code should be fixed (even the current check doesn't accept many third party libs/modules in my codebase)
13:38:04FromGitter<alehander42> ok, I'll continue with the other cases later today or tomorrow
13:38:42FromGitter<mratsim> How does that work with partial object initialisation?
13:39:18FromGitter<arnetheduck> just voicing general support for the idea @alehander42 :) happy to see it
13:40:30FromGitter<arnetheduck> also, because I spent quite some time on a bug yesterday in nlvm where an early return failed to set the result correctly in one of the branches
13:42:19FromGitter<arnetheduck> it's specially useful with the last-expression-is-the-return-of-the-block idea and would provide nice closure to the feature - right now, if you write an expression without using it, there's an error, and if you write a let without an expression, there's also an error, but it would be really nice to have these errors extend to function definitions as well so that you can rely on that pattern
13:43:33*btbytes joined #nim
13:45:50FromGitter<arnetheduck> @mratsim not sure what the question is, but the idea is that you always have to say something, even if it's an empty init.. (`result = MyType()` or actually just `MyType()` at the end and you save some noise)
13:46:39FromGitter<alehander42> I don't think this is required
13:46:49FromGitter<alehander42> ```if a: ⏎ result = .. ⏎ else: ⏎ result = ..``` [https://gitter.im/nim-lang/Nim?at=5c0533c93f503110361b8633]
13:46:53FromGitter<alehander42> should be ok
13:47:08FromGitter<alehander42> (maybe I misunderstood you too)
13:48:55FromGitter<mratsim> it’s the error `cannot prove that foo has been initialized` that prevents some optimisations as well
13:49:44FromGitter<mratsim> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c053477464b6c0fd6847014]
13:50:19FromGitter<mratsim> ^ i.e. Nim would now be able to rely on all objects being fully constructed.
13:52:34FromGitter<alehander42> ah, initialization
13:53:10FromGitter<alehander42> I think your ideally example should still produce an error?
13:53:16FromGitter<alehander42> ideally your*
13:56:21FromGitter<alehander42> absent-minded, you actually want
13:56:47FromGitter<zacharycarter> OSX is annoying... By default gcc maps to clang so that means to debug memory leaks, I should be able to use address sanitizer
13:56:49FromGitter<mratsim> I don’t know, I don’t care either way ;)
13:57:05FromGitter<alehander42> let a = Foo(baz: true) ⏎ .. ⏎ (a.bald not used ) # bald ... really ... we are people too ⏎ .. ⏎ a.bald = .. ... [https://gitter.im/nim-lang/Nim?at=5c053630500e8e372852afde]
13:57:05FromGitter<zacharycarter> but XCode / the clang osx ships with, has a bunk asan distributed with it
13:57:22FromGitter<zacharycarter> so now I'm resorting to building llvm and clang on my machine
13:57:26AraqI wrote an RFC about the initialization problem
13:57:38FromGitter<zacharycarter> I wonder - if I just compiled with gcc instead of clang - if valgrind might work
13:57:46FromGitter<mratsim> @zacharycarter yeah I know, put that in your nim.cfg: https://github.com/numforge/laser/blob/master/nim.cfg#L10-L15
13:59:04FromGitter<zacharycarter> thanks @mratsim
14:29:50*ng0 quit (Quit: Alexa, when is the end of world?)
14:36:44*gangstacat quit (Remote host closed the connection)
14:37:06*gangstacat joined #nim
14:43:57*nsf quit (Quit: WeeChat 2.3)
14:50:54*btbytes quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
14:51:33*btbytes joined #nim
14:51:33*btbytes quit (Client Quit)
14:52:41*ng0 joined #nim
14:59:09*lritter joined #nim
15:00:40FromGitter<Varriount> Araq: Where's the RFC?
15:01:21*endragor quit (Remote host closed the connection)
15:03:08*shadowbane joined #nim
15:07:19Araqhttps://github.com/nim-lang/Nim/issues/7917
15:09:45Araqit can be made to work if passToVarT(uninitVar) is transformed into uninitVar = default(T); passToVarT(uninitVar)
15:10:36Araqwell then it starts to work for objects/inheritance and arrays but 'case' objects remain problematic
15:11:34FromGitter<Clyybber> Araq Is anybody currently working on default values for object fields?
15:12:51FromGitter<mratsim> I think the question is: do we agree that we should do it and this is the proper way.
15:14:28AraqClyybber: No but the feature is rather "easy". Initializers have to be values
15:14:41*ng0 quit (Quit: Alexa, when is the end of world?)
15:14:59Araqdon't allow function calls for it and then it breaks none of Nim's invariants
15:15:13Araq(construction cannot fail in Nim)
15:15:31*kapil____ quit (Quit: Connection closed for inactivity)
15:15:37*endragor joined #nim
15:15:58*PMunch quit (Remote host closed the connection)
15:16:11FromGitter<Clyybber> Nice, so that means no real performance impact either?
15:16:45Araqit has a bit of an impact as we cannot use memset() for these
15:17:33Araqbut then currently we would do memset(x, 0); x.field = 1 instead so that cannot be better
15:18:36Araqwe also cannot allow it for fields in a 'case' section as that would be hard to support
15:19:47*endragor quit (Ping timeout: 240 seconds)
15:20:49*floppydh quit (Quit: WeeChat 2.3)
15:21:59FromGitter<alehander42> btw @jacereda , did you take a look at case objects with if?
15:31:21*masquino quit (Ping timeout: 244 seconds)
15:40:00*nsf joined #nim
15:41:29*endragor joined #nim
15:41:31*kapil____ joined #nim
15:42:40*vlad1777d quit (Ping timeout: 268 seconds)
15:48:10*endragor quit (Remote host closed the connection)
15:48:27*endragor joined #nim
15:51:09*dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:55:54*xet7 quit (Ping timeout: 250 seconds)
15:58:26*xet7 joined #nim
15:58:30*Amun_Ra quit (Ping timeout: 250 seconds)
15:58:46*vlad1777d joined #nim
15:59:22*dom96_w joined #nim
15:59:24*Amun_Ra joined #nim
16:11:11*narimiran joined #nim
16:17:39*Trustable joined #nim
16:20:10FromGitter<Clyybber> Is there a way to get the identifier of a function without importing the macros module?
16:21:19Araqno
16:22:04FromGitter<alehander42> get or quote
16:23:19FromGitter<alehander42> Araq, is there a reason `substrEq` isn't exposed
16:23:34*masquino joined #nim
16:23:55*btbytes joined #nim
16:24:11*ajibade joined #nim
16:24:32Araqalehander42: wanted to use a TR macro for it
16:24:34FromGitter<alehander42> i want to compare a substring without `[]`'s allocation
16:26:42*Trustable_2 joined #nim
16:26:42*Trustable quit (Read error: Connection reset by peer)
16:26:46FromGitter<alehander42> for substrEq ?
16:31:52*btbytes quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:34:40*endragor quit (Remote host closed the connection)
16:34:54*endragor joined #nim
16:35:00*btbytes joined #nim
16:36:15*vlad1777d quit (Ping timeout: 246 seconds)
16:39:20Araqsure
16:40:21*theelous3_ joined #nim
16:40:23FromGitter<arnetheduck> oh, btw @Awaq, another self-assignment bug, just for you :) https://github.com/nim-lang/Nim/issues/9844
16:41:24Araqif only we could construct stuff and then move it to where it belongs
16:41:50FromGitter<arnetheduck> actually, that makes me wonder if the cgen wouldn't be better served by sticking to SSA form completely - that's what it essentially ends up in anyone, in most modern compiler pipelines
16:42:01FromGitter<arnetheduck> *anyway
16:42:04Araqbut oh no, move semantics are just for crappy destructors :P
16:43:43AraqSSA is one solution, the other is aliasing checking
16:44:41*endragor quit (Remote host closed the connection)
16:45:02*endragor joined #nim
16:47:29FromGitter<arnetheduck> latter sounds complicated, specially to do at the nim level - too many moving pieces
16:47:37*endragor quit (Remote host closed the connection)
16:48:42FromGitter<arnetheduck> ie even though it's gone through several simplifying transformations already, the ast that arrives to the cgen (or the other backends) is still fairly high-level and complicated
16:54:29Araqwe have alias analysis though and that's what we use already in the other cases
16:55:45FromGitter<iffy> @yglukhov Now I'm getting `JNI DETECTED ERROR IN APPLICATION: thread Thread[24 ... ] using JNIEnv* from thread` errors (using jnim). Does jnim require `--threads:on`? I get a different failure with threads on.
16:57:45Araqthat the AST remains fairly high-level is a feature to allow the generation of high-level C(++) code
17:03:30*ajibade quit (Ping timeout: 250 seconds)
17:04:06*kumul joined #nim
17:08:11*btbytes quit (Quit: Textual IRC Client: www.textualapp.com)
17:12:39*kumul left #nim ("Leaving")
17:13:45FromGitter<arnetheduck> yeah, that's a good point - not sure what a good solution here is, but for `nlvm` it kind of means a lot of duplicate work - ie some analysis could be carried out in a shared step between them (ie the cgen modifies the ast in some significant ways, adding flags and TLoc's and other stuff that it finds - this looks a bit out of place)
17:17:52FromGitter<xmonader> I can't find the part 3 of the official tutorial? it's merged here https://github.com/nim-lang/Nim/pull/9588
17:18:04FromGitter<xmonader> but can't see it in the site, maybe i'm missing something?
17:18:18FromGitter<SolitudeSF> https://nim-lang.github.io/Nim/tut3.html
17:18:39FromGitter<xmonader> thank @SolitudeSF
17:19:20*endragor joined #nim
17:20:08*endragor quit (Remote host closed the connection)
17:24:41FromGitter<alehander42> Araq, is there a reason `undefined` is not nil in the JS backend
17:42:04*dom96_w quit (Changing host)
17:42:04*dom96_w joined #nim
17:42:09dom96_wpossibly because it's literally not nil? :)
17:43:28*nsf quit (Quit: WeeChat 2.3)
17:43:33FromGitter<alehander42> hehe, that's what I thought for a long time
17:44:07FromGitter<alehander42> but it's for Nim, it's exactly as invalid as nil
17:45:27FromGitter<alehander42> but `if a.isNil` doesn't check if `a` is undefined
17:45:52FromGitter<alehander42> => either `isNil` should do this too .. then undefined becomes kinda `==` nil
17:46:12FromGitter<alehander42> => or we need a isUndefined magic too
17:46:40Araqwell 'nil' is 'null' in JS
17:47:06Araqbut I never thought about it much, 'undefined' for me was just a design bug of JS
17:47:10FromGitter<alehander42> ok, let me rephrase it, should nil == JSUndefined be true
17:48:34FromGitter<alehander42> (we should still have isUndefined, but it can be just a simple importcpp proc)
17:52:20FromGitter<alehander42> it will be actually exactly what JS itself does: `null == undefined // true`
17:52:50FromGitter<alehander42> (`===` is false iirc, in our case we can just have isJSNull / isJSUndefined for those rare cases)
17:59:22Araqbootstrapping works with incremental compilation, yay
18:00:25FromGitter<rayman22201> woot
18:01:14Araqwell it's still super-slow
18:01:31Araqneed to profile it
18:01:45Araqthen the backend also needs to implement caching
18:02:13Araqand then we can make the dependency analysis more precise and do lazy loading
18:05:58FromGitter<rayman22201> still, good progress. :-D
18:07:02*elrood joined #nim
18:14:43*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
18:28:41FromGitter<zacharycarter> woot! congrats!
18:31:30*Snircle joined #nim
18:33:05*rockcavera quit (Remote host closed the connection)
18:33:16*Perkol joined #nim
18:35:32*kapil____ quit (Quit: Connection closed for inactivity)
18:36:35PerkolI'm trying to make a function which overwrites everything in file with zeroes and then deletes it. https://bpaste.net/show/e617a4f3044e
18:37:07PerkolBut instead it truncates the file to empty and then deletes it
18:38:53PerkolHow do i properly overwrite it?
18:40:19*rockcavera joined #nim
18:42:11oprypinPerkol, usually there's an "append" mode as opposed to "write". i'd guess in nim that would be fmAppend ?
18:42:32oprypinalso you have to reset to the beginning after that
18:43:14oprypinalso there's an r+ file mode which wouldnt require you to reset but probably easier to just reset. https://www.google.com/search?q=r%2B+python
18:47:12*dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:01:54*endragor joined #nim
19:02:31*endragor quit (Remote host closed the connection)
19:02:49xacehmm, i find myself using nim c --debugger:native frequently for small programs, is there a quick way i can create a alias for this? e.g. nim d <my other parameters>
19:04:31*julien joined #nim
19:04:54*julien is now known as Guest37486
19:04:56*Guest37486 quit (Client Quit)
19:06:14*PMunch joined #nim
19:06:54*Guest4874 joined #nim
19:09:51xaceoh, also, sometimes stepping through code in GDB with `step` and `next` can result in the debugger staying on the same line. is there a way I can reconfigure GDB to deal with this better for nim?
19:11:58xaceor if there is a more appropriate debugger for nim, i'd be interested. main appeal for me atm is CLI tool as I only have access to a simple terminal 99% of the time
19:16:51leorizewell, gdb is the best one atm
19:17:05leorizexace: create a `.nims` file
19:17:09FromGitter<arnetheduck> it's not really ready for prime time, but you can give `nlvm` a spin if you're running linux - lets you step through nim code and see nim variables etc
19:17:13leorizexace: look up for nimscript documentation
19:17:18xacereading https://forum.nim-lang.org/t/3076 krux mentions that you can edit nim.cfg, how do i make --debuger:native default?
19:17:49xaceleorize: yeah, thing is i'd rather have it on the machine config, as i create small programs in the spur of the moment...
19:18:14xacei use .nims for better planned projects
19:18:32leorizea global `config.nims` is possible with the latest release now
19:19:03FromGitter<timotheecour> u can use when `defined(with_debug): switch(“debuger”, “native”)` in ur ~/.config/nim/config.nims
19:19:41leorizeor... `task d: switch("debugger", "native"); selfExec("c")`
19:19:47FromGitter<timotheecour> also, u can try lldb, works fine too (neither gdb nor lldb are perfect)
19:20:40xaceleorize, timotheecour: this is perfect for my needs now :) thank you
19:22:49elroodwhy not use a simple alias for your shell though? alias nimd='nim c -debugger:native' and you're all set
19:23:36xaceelrood: hmm, figured i might aswell start getting familiar with the nim.config stuff
19:24:04xaceas I feel like there are more things i need in the future. e.g. --threads:on and --ssl:on. some aliases for them would be cool too
19:29:19*endragor joined #nim
19:29:50*endragor quit (Remote host closed the connection)
19:32:53xacetimotheecour i cant get the defined(with_debug): working, it complains about illformed AST
19:38:06*Vladar quit (Remote host closed the connection)
19:38:25Araqtimotheecour: I never saw "encodeType: tyForward", what small program triggers it?
19:38:35*Vladar joined #nim
19:43:49xacefixed it, it was missing `when defined...`
19:47:58*NimBot joined #nim
19:57:02*shpx joined #nim
20:03:20*endragor joined #nim
20:08:53PMunchHmm, does nimble handle submodules?
20:09:42*endragor quit (Remote host closed the connection)
20:12:27FromGitter<mratsim> one module_name.nim and module_name/ folder at the project/src root
20:12:32FromGitter<mratsim> per submodule
20:12:46PMunchOh no, I meant git submodules
20:13:19FromGitter<mratsim> normally it pulls them automatically on nimble install but we had some issues with that in the CI like 3 months ago
20:13:44FromGitter<mratsim> example: https://github.com/status-im/nim-secp256k1/tree/master/secp256k1_wrapper
20:14:21Perkolhttp://rgho.st/8Ty7b8kC8
20:14:29*Perkol quit (Quit: Leaving)
20:14:41*endragor joined #nim
20:14:42PMunchAh, so it should work without anything extra?
20:14:49dom96it does, it should init the submodules
20:15:56Araqwow of all the files in the compiler guess what module has the most symbols
20:15:57*endragor quit (Remote host closed the connection)
20:16:05dom96ast
20:16:24Araqthat's on position 5
20:16:28Araqbut good guess
20:16:41Araq2nd place is sem.nim
20:16:46dom96why are you measuring this btw?
20:16:54Araqbut the first goes to system.nim
20:17:16*Trustable_2 quit (Remote host closed the connection)
20:17:18Araqthe very file every Nim program uses is also the biggest. yay :-(
20:17:32PMunchKinda makes sense though
20:17:50FromGitter<timotheecour> @araq is there a way to mark a PR as “good to merge” pending CI passes? (And, to automatically merge as soon as it passes)
20:17:57dom96oh, I was considering the compiler modules only
20:18:05Araqdom96, looking for how to optimize IC
20:18:12dom96timotheecour: not on GitHub without some sort of bot
20:18:22dom96(GitLab does support this)
20:18:36FromGitter<timotheecour> that’d be very useful right? would streamline things quite a bit
20:19:00dom96yeah
20:19:05Araqnarimiran starts in January as our community manager
20:19:30Araqand will also be responsible for pushing PRs through
20:19:59*endragor joined #nim
20:20:13dom96great
20:20:44dom96hrm, should I do AoC or not
20:20:51dom96I gave up on Ludum Dare
20:21:06dom96sooo tired after work though :/
20:21:06Araqyou could fix stdlib bugs...
20:21:22dom96That's significantly more difficult
20:21:28Araqlol
20:21:30dom96and likely less fun
20:21:54AraqI wish I could fix stdlib bugs instead :P
20:24:36*Tyresc joined #nim
20:25:27*endragor quit (Remote host closed the connection)
20:26:38*nsf joined #nim
20:27:07*endragor joined #nim
20:28:28*Amun_Ra quit (Ping timeout: 250 seconds)
20:28:38*endragor quit (Remote host closed the connection)
20:34:02TyrescHi, I am trying to send a http post request but the site I want to interact with doesn't seem to work with multipart data as shown in the tutorial
20:34:42TyrescI think I need to replace the multipartData part in the postContent call but I am not really sure how I am supposed to replace it
20:34:44Tyrescor rather what
20:34:59Tyrescwould appreciate if someone could point me in the right direction
20:42:47Tyrescwell, nevermind already got it working
20:43:38*ng0 joined #nim
20:44:52FromGitter<arnetheduck> @Araq, sometimes it's efficient to clear the table before starting a new project on it :)
20:45:52FromGitter<arnetheduck> for system.nim, https://github.com/nim-lang/Nim/issues/9208 is a good way to constructively start making it smaller
20:49:48PMunchJust updated nimlsp to use the nimsuggest as a library which should make it more stable. I'd say it's now ready for use, so let the bug-reports flow!
20:50:00*narimiran quit (Remote host closed the connection)
20:50:26PMunchI also updated the readme
20:54:43*krux02 quit (Remote host closed the connection)
20:55:15*nsf quit (Quit: WeeChat 2.3)
20:57:20FromGitter<zacharycarter> whoa - physx is OS now
20:57:21FromGitter<zacharycarter> https://news.developer.nvidia.com/announcing-physx-sdk-4-0-an-open-source-physics-engine/
21:09:49*kungtotte quit (Quit: leaving)
21:20:22*zachk joined #nim
21:20:53*eduarch joined #nim
21:21:04*zachk quit (Changing host)
21:21:04*zachk joined #nim
21:23:49Araqhmmm full recompile: 12s, cached recompile: 18s
21:26:22dom96eduarch: all non-registered users are muted in this channel
21:27:06dom96I'm undoing this setting (I think the spam has stopped)
21:27:17Araqdom96, we will regret this decision
21:27:27*dom_t joined #nim
21:27:30dom96Araq: https://github.com/nim-lang/Nim/wiki/IRC-guidelines#quiet-every-unregistered-user
21:27:35dom96Save this somewhere you'll remember it
21:27:42dom96and you can enable the mute again
21:27:47dom_ttest
21:27:55*dom_t quit (Client Quit)
21:27:55AraqI know about our wiki
21:28:31dom96eduarch: as far as your question goes, I don't know if the arch wiki owners would like an article about Nim in there, but if they are then go for it
21:31:01shashlickis nimprof still broken? https://github.com/nim-lang/Nim/issues/8991
21:31:31*Guest4874 quit (Remote host closed the connection)
21:31:58Araqdunno
21:33:08*Vladar quit (Remote host closed the connection)
21:34:10shashlickugh, so no easy way to identify slow procs
21:34:22shashlickare closures slower than regular procs
21:34:37dom96You can still profile with Valgrind: https://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html#profiling-with-valgrind
21:39:05shashlickhmm, well I'll wait since I am bothered by performance in debug mode - release is still reasonable
21:39:20Araqclosures are slow
21:39:28shashlickbut having nimprof work is crucial
21:39:32xacePMunch: i use vim as my main editor and i'm not ready to edit my config for nimlsp yet. I dont mind trying it out in vscode everynow and then, do you know how to add it to vscode?
21:39:48shashlickAraq: any ballpark on how much slower?
21:42:50PMunchxace, I think LSP is built into VSCode
21:42:52Araqfactor of 2 for the calling overhead but when they capture stuff then can trigger GC collections
21:43:06PMunchBut I'm not entirely sure how to configure it
21:43:12xacehttps://nim-lang.org/blog/2017/10/02/documenting-profiling-and-debugging-nim-code.html#listing_1_5 how are you suppose to interpret these results?
21:43:24PMunchIt's really not that intrusive in Vim though
21:43:27xacePMunch: yeah, thats the part im trying to figre out, googling didnt hlep yet
21:43:53xacePMunch: yeah, i agree, thing is im using YCM and meddling with that would destroy my current working autocompletion for other languages
21:44:01xaceYCM doesnt play nice with other tools
21:44:09PMunchAh right
21:44:25*Amun_Ra joined #nim
21:45:12shashlickAraq: okay thanks I can avoid them, no good reason to use it in my case
21:45:58*eduarch quit (Ping timeout: 268 seconds)
21:54:03FromGitter<arnetheduck> @shashlick you can just use `gprof` or `perf` instead
21:55:08shashlick@arnetheduck: can you use them on Windows?
21:55:42FromGitter<arnetheduck> I'd assume so, yes.. `gprof` at least, assuming you're compiling with `gcc`
21:57:31FromGitter<arnetheduck> or just go with any c profiler from the list: https://stackoverflow.com/questions/67554/whats-the-best-free-c-profiler-for-windows
21:59:24*eduarch joined #nim
22:00:35*eduarch quit (Remote host closed the connection)
22:01:32*Jesin quit (Quit: Leaving)
22:03:24FromDiscord_<j$>
22:03:24FromDiscord_<j$> https://cdn.discordapp.com/attachments/371759389889003532/519272466921816064/unknown.png
22:03:38FromDiscord_<j$> has any one encountered this before?
22:04:35xaceyes, I forgot what I did about it though
22:05:48FromDiscord_<j$> darn
22:05:55xaceiirc in my case it had to do with a old version of nim running
22:06:26xacethat nimble was running on newer tech than the nim that was installed in $PATH
22:07:06FromDiscord_<j$> well I installed nim today
22:08:15xacesee if: nimble --version && nim --version
22:08:55xaceshould be v0.9.0 and v.0.19.0 respectively
22:08:56FromDiscord_<j$> nimble v0.9 and nim v0.19
22:09:02*stefanos82 quit (Remote host closed the connection)
22:10:48FromDiscord_<j$> do I need python2 installed?
22:13:09xacepython isn't required by nim... https://forum.nim-lang.org/t/1011 # not sure if this is relevant in your case
22:14:06xacedoes `nimble --refresh --debug` show anything more that could be relevant?
22:14:25FromGitter<zacharycarter> valgrind's memcheck just doesn't seem to work at all well on osx
22:14:36FromGitter<zacharycarter> even when using gcc as the compiler
22:15:00*Jesin joined #nim
22:15:06shashlickwhat is a double in nim, and what about uchar
22:17:11FromGitter<zacharycarter> `float64` = `double` in C
22:17:21xaceshashlick: im guessing it depends on which architecthure you compile for, but it's going to be bigger or equal to a float...
22:17:32FromGitter<zacharycarter> https://nim-lang.org/docs/system.html#cuchar
22:19:07FromGitter<zacharycarter> which = `char` in Nim
22:19:26FromGitter<zacharycarter> https://github.com/nim-lang/Nim/blob/ab38c075f8864a8ddc129e3a4490f11f48d79d38/lib/system.nim#L1765 & https://github.com/nim-lang/Nim/blob/ab38c075f8864a8ddc129e3a4490f11f48d79d38/lib/system.nim#L1771
22:21:11shashlickN I F T
22:21:26FromGitter<timotheecour> @Araq ⏎ ⏎ > I never saw "encodeType: tyForward", what small program triggers it? ⏎ ⏎ sorry what’s the context where I would’ve mentioned that? [https://gitter.im/nim-lang/Nim?at=5c05ac6643c68b3727f5c0f9]
22:22:05*ng0 quit (Quit: Alexa, when is the end of world?)
22:32:14*craigger_ joined #nim
22:33:43*craigger quit (Ping timeout: 246 seconds)
22:38:04*PMunch quit (Remote host closed the connection)
22:41:25*shpx quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:44:21*shpx joined #nim
22:53:45Araqtimotheecour --incremental:on
22:57:24FromGitter<timotheecour> oh i see, it was in gitter (https://gitter.im/nim-lang/Nim?at=5bf5bb03c6cf4524d156c276) ; IIRC that might’ve happened when I had a dirty nimcache; if it ever happens again I’ll file a github issue; for now good to ignore
22:57:54Araqwell that bug can't be caused by nimcache
22:58:11Araqbut since then I fixed plenty of bugs with --incremental:on, so ok
22:58:16FromGitter<timotheecour> ok
22:58:29FromGitter<timotheecour> 1 question though, right now there’s no efficiency gains right? last I checked, —incremental:on gave slowdowns
22:58:55Araqthat's what I'm trying to figure out
22:59:09Araqwell, yes, you right. currently it makes things worse
22:59:50Araqwhich is "almost" impossible, how can reading from a db be slower than building the AST via semcheck and overload resolution...
23:01:10FromGitter<timotheecour> ok; what about caching? seems to me nim could be smart about figuring out avoiding to re-process (either codegen or parsing) a nim file (or generated c file), assuming compiler options are identical (part of the hash) and file is same (using a 2 step strategy: 1st, lastModificationTime, then, use md5hash to be robust to `git checkout branch`)
23:01:39Araqthat is what I implemented
23:02:10Araqexcept that I skip the lastModificationTime step, never found it reliable on Posix's time resolution
23:02:48Araqand I'll compute 2 checksums eventually. once for the interface part of a module, one for the full file contents
23:03:20Araqclients of a module don't have to be recompiled if the interface hasn't changed
23:04:27FromGitter<timotheecour> r u also hashing compiler options (including implicit ones from config files) so any change in these will pickup the right cached data or recompute
23:04:29FromGitter<timotheecour> ?
23:04:52*shpx quit (Quit: Textual IRC Client: www.textualapp.com)
23:05:34Araqyeah, I do
23:07:01Araqbut I'm a bit lost. plenty of stuff is unimplemented but loading the freaking ASTs from DB should be faster than lexing+parsing+sem'check
23:07:21FromGitter<timotheecour> cool; regarding performance, could a memcached frontend help ? eg: https://stackoverflow.com/questions/3084789/memcached-vs-sql-server-cache
23:07:43Araqhave to profile it properly
23:08:04*endragor joined #nim
23:08:14FromGitter<timotheecour> ya obviously having a good idea of where time is spent is needed before any optimization…
23:08:18Araqbut since --incremental:writeOnly (fill the DB) is faster than --incremental:readonly (read from the cache)
23:08:38Araqit implies to me that sqlite is not the bottleneck. unless writing in sqlite is faster than lookups
23:09:12FromGitter<timotheecour> U mean slower ?
23:09:29Araqno, as I wrote it
23:10:46Araqbut we also perform millions of BTree lookups
23:11:07FromGitter<timotheecour> how about for debugging adding —incremental:off_but_still_write_to_sqlite
23:11:21Araqthat is --incremental:writeOnly
23:11:56FromGitter<timotheecour> likewise with —incremental:off_but_still_read_from_sqlite_and_discard_result
23:12:06Araqthat is --incremental:readOnly
23:12:13FromGitter<timotheecour> Lol ok...
23:12:16Araqwell no
23:12:22AraqreadOnly means "read and use it"
23:12:27*endragor quit (Ping timeout: 246 seconds)
23:12:44Araqanyhow, writing costs us rougly 4s. reading 8s.
23:13:20Araqthe DB is 33MB in size
23:13:44Araqand yeah, mongo or arangodb will probably be faster
23:13:55Araqor memcache.
23:14:20Araqbut as long as reading is more expensive than writing there are other problems IMO
23:14:21FromGitter<timotheecour> > it implies to me that sqlite is not the bottleneck. unless writing in sqlite is faster than lookups ⏎ ⏎ wait, is that conclusion correct? eg what if u have many more lookups than writes? maybe sqlite access still is a bottleneck after all?
23:14:47AraqI only have a lookup if my own memory caching fails
23:14:57Araqwhich I do with BTrees
23:15:13Araqwhich might not be as good as I like
23:15:44FromGitter<timotheecour> Get we add a perfromance counter (for each read, and each write) using getTicks (highest precision counter; shd be enough resolution)
23:17:27FromGitter<timotheecour> (and each Btree lookup too; generating for eg 3 counters)
23:19:45Araqsure, will do that tomorrow
23:21:40FromGitter<timotheecour> another application of —incremental would be a real repl (unlike inim which recompiles all code), based on compile+dlopen the added line
23:22:53FromGitter<timotheecour> meanwhile https://github.com/nim-lang/Nim/pull/9846 is green. :)
23:27:18FromGitter<zacharycarter> @timotheecour - not sure if you've seen this or not, but - https://github.com/nim-lang/Nim/issues/8927
23:27:30FromGitter<zacharycarter> RE: Nim having a proper REPL
23:28:06FromGitter<timotheecour> i have, but I have no idea what would be ETA for something usable
23:28:13*elrood quit (Remote host closed the connection)
23:28:21FromGitter<zacharycarter> well
23:28:35FromGitter<zacharycarter> from my understanding, the grant needs to be completed by a certain date
23:28:39FromGitter<zacharycarter> and I think that's sometime in Feb or March?
23:29:04FromGitter<zacharycarter> `Oct 2018 - Feb 2019` is what the issue says
23:29:36FromGitter<timotheecour> I’ve tried the dlopen approach (in D) and it worked quite well, so dlopen-based approach could be used in meantime (and parts of it could be replaced once that grant proposal approach is completed)
23:29:39FromGitter<zacharycarter> so I imagine - sometime b/w now and Feb of 2019 we'll have hot code reloading available to us
23:30:13FromGitter<zacharycarter> well - there have already been experiments with dlopen / hot reloading Nim code
23:30:13FromGitter<timotheecour> hot code reloading being only a part of what a REPL has to do
23:30:21FromGitter<zacharycarter> sure - but it's the first step
23:30:38FromGitter<zacharycarter> I don't think dlopen alone - is going to get you to where you need to be to make a repl work
23:30:42FromGitter<timotheecour> (thinking Matlab-like interface, with access to variables in top-level scope etc)
23:30:50FromGitter<zacharycarter> you have to deal with state
23:31:13FromGitter<zacharycarter> and you have to also deal with https://nim-lang.org/docs/nimc.html#dll-generation
23:32:15FromGitter<zacharycarter> and there are a ton of other complexities I don't have enough understanding about - to fully explain why it's more difficult than just slapping dlopen onto your existing solution
23:32:41FromGitter<zacharycarter> sorry if you already know all of this already - I think you probably do more C/C++ programming than I do
23:34:06FromGitter<timotheecour> at least in D I was able to work out something quite usable; in Nim a difference is thread-local GC but I don’t see it as a blocker; eager to try
23:34:27FromGitter<zacharycarter> I'd love to play around with whatever you come up with
23:34:54FromGitter<zacharycarter> this is where I started with the whole thing - https://16bpp.net/page/hot-loading-code-in-nim - but that falls apart as soon as you need to handle state
23:35:16FromGitter<zacharycarter> and I spoke with Araq about going further - and he brought up the nimrtl thing
23:35:32FromGitter<zacharycarter> and that's when I was like - well I'm out of my wheelhouse now and someone else can probably figure this out faster than I could potentially
23:36:03FromGitter<zacharycarter> tbh - i'm more excited about hot code reloading than a repl
23:36:20FromGitter<zacharycarter> being able to use Nim as a scripting language inside another Nim process - sounds very appealing
23:36:43FromGitter<timotheecour> Well ya, hot code reloading can be used in lots of places indeed
23:52:51FromGitter<yyyc514> with about 20 lines of code i was able to create a dynamic newInstance() that allows you to make any instances previously registered with it
23:53:10FromGitter<yyyc514> to make working with dynamic object dispatch easier
23:56:01FromGitter<yyyc514> works for my use case at least