<< 11-09-2018 >>

00:00:51FromGitter<bung87> I'm also wondering the results.
00:03:38FromGitter<gogolxdong> I didn't think futher for object constructor and new operator in Nim. destructors are not called for objects allocated with new, machenism of object constructor is unknown yet for me.
01:00:49FromGitter<kayabaNerve> Why do cuchar's no longer match SomeInteger?
01:02:58*brainproxy joined #nim
01:13:40*cyraxjoe joined #nim
01:20:25*brainpro1 joined #nim
01:21:22*brainproxy quit (Ping timeout: 246 seconds)
01:40:54*captainkraft quit (Ping timeout: 252 seconds)
01:42:22*captainkraft joined #nim
01:52:52*cspar_ quit (Ping timeout: 246 seconds)
01:55:12zestyrSo I've managed to make an alternative `post` function for sending files that reduces the allocated memory by 2xfilesize, but the code isn't pretty. I'll open an issue soon
01:55:34zestyrSending a 46 MB file went from using 248MB down to 148MB, definitely an improvement
02:00:08*voice_ftp_ joined #nim
02:02:33*voice_ftp quit (Ping timeout: 245 seconds)
02:04:09FromDiscord<Shield> can we see the code please
02:08:37*endragor joined #nim
02:09:42*endragor quit (Remote host closed the connection)
02:11:57*endragor joined #nim
02:15:11zestyrhttps://gist.github.com/zestyr/38eae7ceeebbe81aaecd9b96f36ffa63
02:15:33zestyrit's an ugly hack that probably breaks some stuff, but it works in my case
02:21:32zestyrunfortunately the contents are allocated/duplicated 3 times, but I couldn't find a simple way to reduce that further
02:21:59zestyrwithout this hack it gets allocated 5 times
02:24:35zestyr6*
02:25:21FromGitter<gogolxdong> how do you profile allocation?
02:25:40zestyr`getOccupiedMem` and `getTotalMem`
02:25:52zestyrthis is when using the markAndSweep gc btw, the others seem to perform worse here
02:25:59FromGitter<gogolxdong> and the times?
02:26:24zestyrwell, reading the code and looking at the memory usage
02:29:43zestyrhmm got some contradictory results, it seems to be 5 times. Using a 76 MB file, calling `post` results in 377 MB used, while `postFile` results in 252 MB used. Roughly 5 and 3 times respectively
02:30:29zestyrI'll post some more detailed results in the issue
02:32:33zestyrah yeah, using the default GC or boehm results in 461 MB occupied, ie. 6 allocations, with markAndSweep I get 377
02:35:17shashlickYou really need to figure out a way to upload in chunks
02:38:27shashlickPerhaps extend httpclient to accept an open stream or something
02:39:20shashlickImagine if YouTube read every video file into memory before playing
02:39:46FromDiscord<Shield> isn't this a related issue https://github.com/nim-lang/Nim/issues/5589
02:40:16*cspar_ joined #nim
02:40:37zestyrYeah I get what you're saying. There's a TODO in the post proc about accepting a "FutureStream", I guess this is why
02:42:37zestyrShield: that's an async thing, which somehow works far worse for me. All this has been with the non-async HttpClient
02:42:41shashlickI ran into a similar issue in the past
02:42:42shashlickhttps://github.com/nim-lang/Nim/issues/6031
02:43:34zestyryeah I've seen that issue
02:43:37shashlickBut I agree that expecting a GC to free this responsibly even without leaks is unreasonable
02:43:53shashlickI've since updated my algorithm to work in chunks
02:44:43shashlickEven if you manually malloc and free, there will be size limitations - i.e your ram
02:44:54zestyrAll I'm doing is uploading a file to an API using http post. If that can somehow be done in chunks I'd be happy to know
02:45:12shashlickRan into this on my python proxy server as well
02:46:54shashlickPerhaps extend httpclient or consider curl
02:47:16FromDiscord<Shield> wouldn't a GC_fullCollect at least release the memory reserved for reading the file
02:48:37shashlickIt doesn't since GC could reuse that memory later
02:49:11shashlickAt least back when I tried, maybe it has changed but doubt it
02:50:14zestyrCalling that right after reading the file into the sequence doesn't seem to change anything
02:59:01*dddddd quit (Remote host closed the connection)
02:59:29FromGitter<gogolxdong> @zacharycarter does your port work with material design?
03:00:40FromGitter<gogolxdong> Don't know whether --gc:regions help. Have a try.
03:04:25*Tanger joined #nim
03:05:16zestyrNope. With regions I get 330MB, markAndSweep 252MB
03:07:34FromGitter<gogolxdong> Did you check withScratchRegion, we are using this with --gc:regions
03:08:15FromGitter<gogolxdong> gc:regions and gc:stack seems the same thing.
03:16:45zestyrhmm, I tried it in a few places but it either results in the same mem usage or the upload failing
03:19:30FromGitter<gogolxdong> sad.
03:24:16FromGitter<gogolxdong> we use regions to allocate thread pool ,it's a good fit in this case, regarding post file scenarios , you need a more radical memory management solution,which we are seeking for our public resource too.
03:24:18*cspar_ quit (Ping timeout: 252 seconds)
03:27:48FromGitter<gogolxdong> We need to release the memory http response holding right after being parsed into json, and release the memory json object holding right after being written into database.
03:34:21zachcartergogolxdong: material design is just a styling thing right? I don't see why it wouldn't
03:34:42zachcartersorry - I've been out for most of the evening
03:50:34FromGitter<wsdjeg> I just post a link in nim's reddit channel. SpaceVim adds nim support now. feeling free to have a try. any feedback is welcome :
03:50:36FromGitter<wsdjeg> https://www.reddit.com/r/nim/comments/9etzht/develop_nim_in_spacevim_language_layer_for_nim/
03:50:53FromGitter<gogolxdong> take a rest. Becaue I didn't implement it in virtual DOM.
03:52:59FromGitter<gogolxdong> the html tag generated by macro can be used in hyperHtml concept, <> is tedious.
04:15:10FromDiscord<Shield> tried to make an async test, it takes 6 times the file size to send it, markandsweep takes 5x, gc_fullcollect seems to have no effect so i guess there is no way to free the memory, anybody tried with pointers?
04:45:18FromGitter<alehander42> http://cs242.stanford.edu/assets/projects/2017/parastoo-gdietz44.pdf
04:46:18FromGitter<alehander42> The strong effect of inline errors is interesting
04:47:01FromGitter<alehander42> I guess having the error and the source (the context) nearby is always more useful
04:47:42FromGitter<alehander42> is there a reason the context for nim errors is behind a flag
04:47:58FromGitter<alehander42> (I know it's the CLI but still important)
05:01:31*darithorn quit (Quit: WeeChat 2.2)
05:12:27*miran joined #nim
05:35:16*nsf joined #nim
05:46:24FromGitter<Grabli66> Hi! Is the new runtime with destructors ready for using?
05:52:07*kapil___ joined #nim
05:59:52FromGitter<DanielSokil> https://youtu.be/XzYaw8hfqEE
06:03:55FromGitter<gogolxdong> https://github.com/nim-lang/Nim/issues/7041
06:06:48FromGitter<Grabli66> Thanks
06:08:11FromGitter<Grabli66> Nim will be transformed to Rust? :)
06:09:41FromGitter<gogolxdong> you can do that.
06:16:42*NimBot joined #nim
06:24:47*miran quit (Ping timeout: 240 seconds)
06:48:29*jxy quit (Read error: Connection reset by peer)
06:48:41*jxy joined #nim
06:58:38FromGitter<bung87> question about mathematics: do I need check the params before calculate or just catch OverflowError ?
07:11:16FromGitter<gogolxdong> anyone knows Time-based One Time Password (TOTP) algorithm defined by IETF RFC 6238
07:16:40*couven92 quit (Ping timeout: 252 seconds)
07:17:58*PMunch joined #nim
07:25:01*TheLemonMan joined #nim
07:25:31FromGitter<xmonader> is there any change of behavior between 0.18 and devel when it comes to index errors?
07:26:05FromGitter<narimiran> @xmonader what do you mean?
07:26:23FromGitter<narimiran> IIRC, you cannot do `string[^0]` anymore
07:26:47FromGitter<xmonader> i switched from 0.18 to devel and my code is havng lots of indexError unhandled..
07:26:57FromGitter<xmonader> do i require that for any slicing operation?
07:28:22FromGitter<narimiran> if you have those `^0`, change them to `^1` (as `^0` is the nul-character, not the last element) and see if it helpt
07:28:27FromGitter<narimiran> *helps
07:28:47FromGitter<xmonader> i'll check thanks
07:28:59FromGitter<narimiran> i'm not aware of any other changes
07:40:03FromGitter<xmonader> damn my tests passed on 0.18 and now i've to worry again about finished work to fix :(
07:54:26FromGitter<xmonader> @narimiran so main problem was [i..len(s)] was valid somehow in 0.18 and it was inclusive
07:54:33FromGitter<xmonader> but now i need to do ^1 or len(s)-1
07:54:42FromGitter<Bennyelg> why is it crying ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5b9774c20fb4232e38a86915]
07:55:18FromGitter<Bennyelg> oh
07:55:22FromGitter<Bennyelg> fixed sorry ;]
07:55:46TheLemonManyou forgot the constructor call
07:55:49FromGitter<narimiran> @xmonader yeah `[len(s)]` is beyond the last element
07:55:58FromGitter<Bennyelg> yea :D
07:56:19FromGitter<narimiran> @xmonader you can do `i ..< len(s)`
07:56:53FromGitter<xmonader> yea but i think ^1 (first last) more intuitive a bit :D
07:57:19FromGitter<xmonader> but i'm correct, it was valid and it'd return the upper bound instead of failing
07:57:47FromGitter<narimiran> yeah, you can do `^1`, but please don't do `len(s) - 1` — it is ugly! :)
08:03:24FromGitter<mratsim> @exelotl: it really depends, VTable dispatch like in C++ is a guaranteed cache miss while methods use if dispatch and since Haswell branch predictor have reeeealllly improved and take full account of history: ⏎ ⏎ You can look into this: http://www.emulators.com/docs/nx25_nostradamus.htm ⏎ ⏎ Now, it’s true that even with 7 refs methods becomes super slow. If you don’t want static dispatch you can use: ...
08:03:24FromGitter... [https://gitter.im/nim-lang/Nim?at=5b9776cca04db554a70b5cfb]
08:03:30*gmpreussner_ quit (Ping timeout: 252 seconds)
08:03:56FromGitter<mratsim> or each entity carries a proc closure that serve as handler
08:03:57*gmpreussner joined #nim
08:04:08FromGitter<mratsim> You have timings of each strategy at the bottom
08:05:20FromGitter<mratsim> I would avoid closure especially for short-lived objects because they are heap allocated
08:05:38FromGitter<mratsim> and there is no way to write a memory-pool for closure
08:07:17*couven92 joined #nim
08:12:04FromGitter<xmonader> https://github.com/xmonader/nim-redisclient any feedback is appreciated, still need to do real test suite,
08:30:35*Vladar joined #nim
08:37:48*couven92 quit (Ping timeout: 252 seconds)
08:46:07*couven92 joined #nim
09:01:08*stefanos82 joined #nim
09:02:52*druonysus quit (Read error: No route to host)
09:03:31FromGitter<timotheecour> hi @Araq are you here? may be faster to discuss here instead of on PR
09:04:30FromGitter<Grabli66> How to build DLL with nimble? I don't see any settings for nimble file to do that.
09:05:29FromGitter<mratsim> create a task or replace the nimble build task with your DLL settings
09:05:48leorizeor add a <projectname>.nims file with the relevant flags
09:11:48PMunchGrabli66, have you figured out a way to actually create DLLs that won't crash or have crazy behavior?
09:12:43FromGitter<Grabli66> PMunch, i'll try don't use referrences :)
09:12:54FromGitter<Grabli66> And set gc:none
09:12:59PMunchAh, so just avoid the GC..
09:13:03PMunchThat's a shame
09:13:29FromGitter<Grabli66> I think it's the only way.
09:14:12PMunchYeah, until the DLL/GC stuff is fixed
09:17:10FromGitter<xmonader> Anyone using docopt? or is there some better way?
09:17:34FromGitter<Grabli66> PMunch, I think Nim in future will be like Rust. Language with no GC.
09:19:42PMunchxmonader, I played around with it at some point
09:20:38PMunchYou do have parseopt and parseopt2
09:21:41PMunchAnd you have https://github.com/fenekku/commandeer
09:22:27FromGitter<xmonader> @PMunch they dont support subparsers by default no?
09:22:43PMunchsubparsers?
09:23:16FromGitter<xmonader> subcommands ⏎ proj new --opt1 --opt2 ⏎ proj save --opt1 --opt2 ⏎ ..etc [https://gitter.im/nim-lang/Nim?at=5b97898445318b2dfe913c6a]
09:24:08PMunchYes they do
09:24:12PMunchOr commandeer does
09:24:32PMunchhttps://github.com/fenekku/commandeer#documentation
09:25:32PMunchparseopt2 can probably do it with some manual help
09:25:53FromGitter<xmonader> ah never heard of commandeer I was just checking cligen
09:26:49PMunchI wanted to make a better version of docopt when I first started using Nim, but my macro-foo wasn't quite good enough
09:27:03PMunchIt's the perfect candidate for macro-magic
09:27:26PMunchHaving a small terminal program spend most of it's time parsing your doc-string is just silly :P
09:28:30FromGitter<xmonader> maybe u should do it now :D because docopt just failed me a while ago :(
09:28:59PMunchFailed you?
09:34:45FromGitter<xmonader> @PMunch yeah basic usage didn't work that's why i'm checking for another thing, and now cligen doesn't work with devel too
09:47:49PMunchcligen?
09:47:58*dddddd joined #nim
09:48:21FromGitter<xmonader> @PMunch this one https://github.com/c-blake/cligen
09:48:35FromGitter<xmonader> I remember it was promoted here in the chat
09:54:38PMunchHmm, cligen looks interesting
09:55:48FromGitter<xmonader> It's, i'm afraid i'll have to fallback for std parseopt
09:56:52PMunchDid you try comandeer?
09:59:08FromGitter<xmonader> not yet, apparently working on the bleeding edge works for cligen, this is too bad now i've to work with devel to make nimble work and that made my 0.18 test suite fails so i had to fix it, and now i need to move to devel branch for 3rd party packages because they're committed to 0.18
09:59:16PMunchAh, compiling cligen with --nilseqs:on makes it work on devel
09:59:32PMunchThat should be an easy fix
10:00:46FromGitter<xmonader> Didn't even know the nilseqs option existed.. :(
10:02:17PMunchIt's to easy the transition to non-nilable seqs and strings
10:04:21FromGitter<Bennyelg> cligen is awesome
10:04:24FromGitter<Bennyelg> Im using it
10:11:00FromGitter<xmonader> @Bennyelg I kinda like it too!
10:15:04PMunchNever seen it before, but it looks cool
10:29:13*zachcarter quit (Ping timeout: 245 seconds)
10:29:24FromGitter<mratsim> @PMunch, are you calling the DLL from Nim or from C?
10:29:36FromGitter<mratsim> from C I think just NimMain() before anything does the trick
10:29:44FromGitter<mratsim> from Nim well I don’t know
10:30:41PMunchThis was trying to write Nim DLLs for use in Nim
10:30:50*zachcarter joined #nim
10:35:31*zachcarter quit (Ping timeout: 272 seconds)
11:23:35*xet7 joined #nim
11:25:52FromGitter<kaushalmodi> PMunch, @xmonader : cligen is fixed in its master branch
11:26:02FromGitter<kaushalmodi> Just git clone and nimble install
11:26:20FromGitter<kaushalmodi> The dev will cut a release when the next Nim release is cut.
11:26:40FromGitter<kaushalmodi> @xmonader cligen supports subcommands
11:27:11FromGitter<kaushalmodi> I had created a PR to use cligen for your nstow package ;)
11:27:23FromGitter<narimiran> continuing with my macro journey from yesterday. is there a better way of doing this: http://ix.io/1msC/ ? i don't like the looks of the if-else the way it is now, but couldn't make it work any other way
11:36:46FromDiscord<exelotl> @mratsim: thanks, that gives me some faith that I'm heading in the right direction. Definitely want to avoid closures in the main update/draw loops
11:45:58*ven473 quit (Remote host closed the connection)
11:47:19*ven473 joined #nim
11:52:54*noonien joined #nim
12:02:27*PMunch quit (Ping timeout: 240 seconds)
12:07:24FromGitter<tim-st> @dm1try I tested the code on linux now, there it works (the occupied memory goes down to what is actually used) the total amount stays high but I found a github issue where Araq said it's known that the total amount doesnt go down
12:13:02FromGitter<dm1try> @tim-st could you point to the issue link?
12:15:57FromGitter<tim-st> https://github.com/nim-lang/Nim/issues/5589#issuecomment-350467569
12:17:05FromGitter<tim-st> and here: https://github.com/nim-lang/Nim/issues/6031#issuecomment-351083338
12:24:44*PMunch joined #nim
12:32:07FromGitter<Vindaar> @miran: well, in principle I guess you can iterate over the `Shape` type, get the field names for each variant. Then in your example iterate over `idents[2]` and capture the corresponding values for each variant field, store them in a `seq[NimNode]`. Then add the `nnkExprColonExpr` to the `nnkObjConstr`, which you get from the ```Shape(kind, `kind`)``` call.
12:32:45FromDiscord<Shield> the minimum memory usage i managed was 3x the file size, which makes sense (memory used for readFile, the variable to hold it, and the socket making its own copy), none of it is freed and gc isn't reusing any of it, not sure how to deal with it
12:32:58FromGitter<Vindaar> @narimiran should ping you on gitter I guess
12:34:32FromGitter<mratsim> mmm there is no way to popFirst and popLast in OrderedTableRef :/
12:34:35*hoijui joined #nim
12:39:12FromGitter<narimiran> thanks @Vindaar, will try it to do that way
12:39:45FromGitter<Vindaar> I haven't tested it, so I hope it actually works :D
12:40:26FromGitter<Vindaar> The main issue I see is that you might need a second macro working on `typed` to even get the tree of your `Shape`. Not sure
12:41:18FromGitter<narimiran> i haven't used `typed` yet. i've seen only the examples with `untyped` so i'm using that, without too much understanding why :D
12:42:31FromGitter<Vindaar> I guess you can also just hand the type creation tree to the macro, which assigns the field and get the variants from there. You're just creating them after all
12:43:12FromGitter<Vindaar> With a `typed` macro you could do `myMacro(Shape)` and then use `getImpl` to get the tree that defines the type
12:44:41FromGitter<narimiran> "yeah, yeah, i understand some of these words".jpg
12:45:31FromGitter<Vindaar> You know, I'm just throwing around random things too :D
12:46:30FromGitter<Vindaar> so don't trust anything I say, hehe. Just my experience so far :)
13:00:08*hoijui quit (Ping timeout: 250 seconds)
13:01:27FromDiscord<PusiteGA> hmm how to play sound with nim , do i have to use ffmpeg or something like that
13:01:36FromDiscord<PusiteGA> just want to play alarm beep
13:02:19PMunchDepends
13:02:22PMunchCross platform?
13:02:33FromDiscord<PusiteGA> not really just linux
13:02:45FromDiscord<PusiteGA> i dont use windows at all
13:02:49PMunchOn Linux you could always set up your terminal to make a sound on the bell character and print out one of those
13:03:24FromDiscord<PusiteGA> i know i can make bash script just wanted to practice little nim
13:03:48FromDiscord<PusiteGA> just wasent shure what to use for play sound , meybe some C sound lib
13:05:18FromDiscord<Shield> you can use sdl2_mixer if you want to play audio files
13:06:18PMunchThis might work: https://github.com/yglukhov/sound
13:08:04FromDiscord<PusiteGA> even better
13:08:49FromDiscord<PusiteGA> 1 question tought , how do i nimble it form github
13:09:17FromDiscord<PusiteGA> or can just nimble install sound
13:09:37FromDiscord<PusiteGA> ok it works
13:09:49FromDiscord<PusiteGA> sorry next time will try then ask xD
13:10:26PMunchIf it's in the nimble repository you can install it simply by using "nimble install <name>", but you can also install directly from the git repo
13:11:37*cspar_ joined #nim
13:13:45FromDiscord<PusiteGA> i installed it whit nimble , but duno how to install from repo, just download it and extract or install whit nimble
13:13:52FromDiscord<PusiteGA> *git repo
13:14:20PMunchI think you can just do "nimble install
13:14:30PMunchUhm, "nimble intsall <url>"
13:14:45PMunchThat is the URL to the git repo, not the github page
13:15:30*Vladar quit (Remote host closed the connection)
13:20:00FromDiscord<PusiteGA> ok will try that in future
13:26:13FromGitter<xmonader> @kaushalmodi oh! it was you! :D why didn't u continue that PR? it'd be nice to have cligen ^_^
13:26:52FromDiscord<Shield> what happen if you try to dealloc memory managed by the gc?
13:27:21FromDiscord<Shield> the gc seems to print a message about it but memory usage is unchanged
13:27:36FromGitter<kaushalmodi> @xmonader I wasn't sure if you wanted nistow to be minimal or if would be fine with external dependencies with cligen.
13:27:43FromGitter<kaushalmodi> I use cligen in all my toy projects
13:36:54FromGitter<Bennyelg> Any thoughts about Julia 1.0 performance?
13:39:49*hoijui joined #nim
13:40:17FromDiscord<PusiteGA> hmm i imported import sound.sound and did nimble install sound
13:40:40FromDiscord<PusiteGA> but var snd:Sound = newSoundWithPath(fPath) gives me RandomWorkout.nim(10, 19) Error: undeclared identifier: 'newSoundWithPath'
13:41:46FromGitter<narimiran> try to do just `import sound` and see if anything changes
13:41:54FromGitter<bung87> `import sound.sound` ??
13:43:44FromDiscord<PusiteGA> its writed like that on github page , ok will try just sound
13:44:21FromDiscord<PusiteGA> nah cant import just sound
13:44:23FromDiscord<PusiteGA> RandomWorkout.nim(1, 8) Error: cannot open 'sound'
13:44:53FromGitter<bung87> you have dir or file named sound?
13:45:23FromDiscord<PusiteGA> nothing of those
13:45:24FromDiscord<PusiteGA> https://github.com/yglukhov/sound
13:45:48FromDiscord<PusiteGA> i have a sound file s1.ogg
13:46:20FromDiscord<PusiteGA> in getCurrentDir() & /sfx/s1.ogg
13:47:21FromGitter<bung87> this package didn't specify `src` dir in nimble file.
13:48:27FromGitter<bung87> I don't think it's ready for public, if you use it fork and modify it
13:48:59FromDiscord<PusiteGA> oh i am too newbie to do that for now
13:49:23FromGitter<bung87> mk new dir and `nimble init` see whats the default package constructure.
13:51:09*kapil___ quit (Quit: Connection closed for inactivity)
13:52:03FromDiscord<PusiteGA> i think i found issue
13:52:14FromDiscord<PusiteGA> by browsing trought code
13:53:55FromDiscord<PusiteGA> i got it working tought i get AL lib: (EE) alc_cleanup: 1 device not closed when i terminate app
13:54:46*voice_ftp_ quit (Remote host closed the connection)
13:55:06FromGitter<bung87> without modify the package?
13:55:07*PMunch quit (Quit: Leaving)
13:55:09*voice_ftp_ joined #nim
13:55:16FromGitter<xmonader> @kaushalmodi for the book bare minimal, but for usable app I'd rather lift as many pieces from my thinking ^_^
13:57:26*Vladar joined #nim
14:02:58*vivus joined #nim
14:08:25*vivus quit (Remote host closed the connection)
14:09:34*endragor quit (Remote host closed the connection)
14:14:08*Senketsu quit (Quit: WeeChat 2.2)
14:16:26*Senketsu joined #nim
14:25:12*Vladar quit (Read error: Connection reset by peer)
14:28:19*endragor joined #nim
14:32:33*endragor quit (Ping timeout: 245 seconds)
14:41:27*hoijui quit (Ping timeout: 240 seconds)
14:51:27*miran joined #nim
15:13:03*jxy quit (Ping timeout: 252 seconds)
15:13:31*cspar_ quit (Ping timeout: 252 seconds)
15:13:41*nsf quit (Quit: WeeChat 2.2)
15:15:55*Trustable joined #nim
15:16:33*askatasuna joined #nim
15:16:43*Vladar joined #nim
15:17:25FromGitter<alehander42> hm it seems nimpretty isn't stable yet, i wanted to run it on some stuff
15:17:50FromGitter<alehander42> is there anything blocking it, or does it just require a bunch of smaller improvements?
15:18:50*askatasuna left #nim (#nim)
15:26:53*cspar_ joined #nim
15:29:45*leorize quit (Ping timeout: 252 seconds)
15:32:58*hoijui joined #nim
15:39:53*darithorn joined #nim
15:48:51*nsf joined #nim
16:04:47FromGitter<Bennyelg> what the hack is this uninformative error ⏎ ``` Error: tabulators are not allowed```
16:05:19TheLemonMandon't use tabs
16:06:42FromGitter<arnetheduck> @alehander42 fundamentally, I think nimpretty takes the wrong approach by working with the AST and just printing from that - there are two formatters I've seen that work well, `yapf` and `clang-format` - they both work on a different level and come with a scoring / penalty system to determine what an optimal formatting for a particular construct would be
16:12:04FromGitter<arnetheduck> ie a dogmatic rendering will rarely end up "beautiful", and the ast-based approach works poorly with partially invalid code - the workflow I have when working with a formatter is that I type some randomly formatted code and expect it to clean up the mess even if it's not perfectly valid syntax yet.. there's a really good presentation on it by chandler carruth, I think it's this one:
16:12:05FromGitter... http://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s-Dragons
16:26:10FromGitter<Varriount> @arnetheduck How do those tools parse/internally represent the input?
16:33:21FromGitter<arnetheduck> tokenized lines, basically.. tokenizes according to language rules, with some leniency, then turns that into "unconstrained lines", then takes those lines and applies penalties to various options when formatting ("how expensive in terms of beauty would it be to wrap the line before parens? after? what's the cost of going over the column limit due to some freak name?"), then chooses the least costly option
16:34:50FromGitter<arnetheduck> what's nice about it is its ability to deal with "difficult" situations.. this is where dogmatic renderers break down
16:39:07FromGitter<Araq> @arnetheduck nimpretty doesn't work from the AST anymore, it uses the lexer and some semantic info
16:40:02FromGitter<arnetheduck> @Araq ooh, that sounds like the right building blocks then, nice!
16:41:49FromGitter<Araq> yeah, time will tell if the remaining bugs are just bugs or inherent flaws in the approach
16:43:32FromGitter<bung87> @Araq last time you talk about a new feature seems could make easy handle large amount of strings, does it ready for use now?
16:44:09FromGitter<arnetheduck> does it come with a scoring system too? is it still the version in the main nim repo? the nimpretty I see there works with PNode and seems to just use `renderTree`
16:46:46FromGitter<Araq> @bung87 sorry, no.
16:48:52FromGitter<Araq> @arnetheduck played a bit with dynamic programming to figure out where to put the line breaks but it didn't work well at all and it's of lower priority. so no.
16:49:22FromGitter<Araq> and the code is now a parser patch, ``` ⏎ when defined(nimpretty2): ⏎ ⏎ `````` [https://gitter.im/nim-lang/Nim?at=5b97f212e6e309365e398f9c]
16:51:20FromGitter<bung87> hmm then I just continue prepare to make some package wait for optimization in future or learn to how handle it without gc :)
16:56:45FromDiscord<Shield> currently testing mofuw library to serve a 1mb string, the memory usage keeps growing with each request, it's going beyond 500mbs currently
16:57:22FromDiscord<Shield> i guess the problem isn't just sending files, but sending anything at all
16:59:13FromGitter<Araq> report it properly
16:59:36FromGitter<Araq> ideally without the `mofuw` dependency
17:01:47FromGitter<Araq> https://xkcd.com/2044/
17:07:21FromDiscord<Shield> i think it was already reported, people were talking yesterday about sending a big files online consumes memory without freeing it, the problem happens regardless if it's async or sync
17:07:53FromDiscord<Shield> this may be the GC not freeing/reusing memory
17:08:27FromGitter<Araq> I've looked are more "GC leaks" than everybody else and it never was a "GC leak"
17:08:49FromGitter<Araq> it was fragmentation, stdlib bugs or wrong caching
17:09:28FromGitter<Araq> *looked at
17:10:34FromGitter<Bennyelg> How I can get the database error when tryExec gives false
17:10:44FromGitter<tim-st> it's not a leak, the occupied mem is stable (on linux, not on windows) the problem is only the total gc amount increases
17:10:51*Trustable quit (Remote host closed the connection)
17:13:04FromGitter<Araq> what does that mean? "total GC amount increases"?
17:14:12FromGitter<tim-st> it goes to the max that was needed once and stays there (for example at 1 gb) when this 1 gb is not needed anymore it still uses 1gb in ram although it doesnt occupy any memory anymore
17:14:31FromGitter<tim-st> I have not seen this at other gc'ed languages
17:14:51FromDiscord<Shield> is this a problem with long strings or big objects in general? i'm mainly using nim to learn gamedev, handling creating/destroying thousands of objects was never a problem, memory usage was stable
17:15:11FromGitter<Araq> returning RAM back to the OS is hard. the allocator doesn't try hard to do that
17:15:17FromGitter<tim-st> it's only a problem with very big data at once
17:15:24FromGitter<Araq> and iirc Python doesn't do that either
17:15:31FromGitter<tim-st> because of this I wrote the example: https://gist.github.com/tim-st/abbb86a591172a7b997c853fcda5cff9
17:15:35FromGitter<Araq> it's definitely not unique to Nim.
17:16:00FromGitter<tim-st> I tested a python http server it goes up and down exactly how it's needed
17:16:28FromGitter<Araq> the bigger problem here seems to be "why the fuck does it need to allocate 1 GB just to serve a 1 GB big file?"
17:16:37FromGitter<Araq> it should stream it...
17:16:55FromGitter<tim-st> no, I created this code to prove there is something wrong
17:17:08FromGitter<tim-st> it's not about the question how one should send data
17:17:53FromGitter<Araq> yes, it's about that.
17:18:16FromGitter<Araq> otherwise I can argue "you needed 1 GB once, you might need it again, there is no reason to give it ever back to the OS"
17:18:41FromGitter<tim-st> there is, an os become extremely unstable when much ram like 80% is used
17:18:51FromGitter<Araq> swap?
17:19:07FromGitter<Araq> but hey, what do I know.
17:19:28FromGitter<tim-st> so it's not a bug, it's a feature?
17:19:49FromGitter<Araq> and if you wanna serve 10GB and only have 2 GB of RAM you are fine with a dying server?
17:20:09FromDiscord<Shield> it's normal that reading the whole file to memory would consume a lot of it, but here i'm sending 1mb string repeatedly, still running the server, it's using 700mb and growing, it's odd that the data and its copies aren't reused or freed
17:20:29FromGitter<tim-st> yes, that's the problem I saw too
17:20:58FromDiscord<Shield> if 1mb is enough to cause the problem, then how big can an object be without triggering this problem
17:21:31FromGitter<tim-st> probably every object does, but it develops the problem very slowly
17:22:11FromGitter<Araq> well, one problem is "doesn't return mem back to the OS", the other "something leaks"
17:22:13*ofelas quit (Remote host closed the connection)
17:22:27FromGitter<Araq> these problems are completely different.
17:22:41FromDiscord<Shield> isn't that really awful for servers and any applications that runs for a long time
17:23:31*ofelas joined #nim
17:23:37FromGitter<Araq> yeah, probably, but I need real reproducible examples
17:24:04FromGitter<tim-st> this reproduces on windows and linux devel: https://gist.github.com/tim-st/abbb86a591172a7b997c853fcda5cff9
17:24:10FromGitter<Araq> and not just code that allocates 10GB of RAM for serving a 10GB file
17:24:23FromGitter<tim-st> it's 100mb not 10gb
17:24:45FromDiscord<Shield> the http module doesn't seem to do any leaking by accident, it takes a copy of the data, send it then gc_unref it, yet none of the variables are freed
17:24:55FromGitter<Araq> if it depends on the file size, it's wrong.
17:26:49FromGitter<tim-st> it seems java does it: https://stackoverflow.com/questions/30458195/does-gc-release-back-memory-to-os
17:27:09FromGitter<Araq> oh ffs
17:27:13FromGitter<tim-st> go does it not
17:27:16FromGitter<Araq> yes, some do, some don't.
17:27:20FromGitter<kayabaNerve> Is the comment Nim doesn't or Nim rarely doesn't?
17:27:38*leorize joined #nim
17:28:29FromDiscord<Shield> i think somebody tried the same with go and it worked normally
17:28:40FromGitter<kayabaNerve> And does this behavior change between the different GCs?
17:28:51FromGitter<tim-st> yes, go fixed it, I read now
17:31:59FromDiscord<Shield> markandsweep helps but barely, when you have to read a file and format the request, it took 7x the file size, with markandsweep it takes 6x, fullcollet seems to have no effect, the memory usage will keep growing
17:32:55FromGitter<Araq> give me a real program. `let blob = repeat('X', size)` is bullshit code
17:34:44FromGitter<alehander42> @arnetheduck sounds interesting, does it achieve the same quality as ast-based formatters for valid code though?
17:35:05FromGitter<alehander42> i am not so interested in formatting invalid code (but i can see the pro-s)
17:36:28FromDiscord<Shield> you can literally hardcode a string and asign it to the blob, this will only cut down 1x size because you don't use readFile
17:36:39*arnetheduck joined #nim
17:45:27FromGitter<Araq> I used `let blob = repeat('X', 40_000)` and don't get any leak
17:45:27FromGitter<dm1try> @Araq maybe a super stupid question but, ⏎ is returning memory to OS /getting it back again very expensive? and if I will try to decrease allocator memory pool using this param -> https://github.com/nim-lang/Nim/blob/e7d404340628ef2ca6170744a7df33e20cd0fc1a/lib/system/alloc.nim#L25 ⏎ the drawback is that I will have more expensive operations for allocations that does not fit allocator memory pool?
17:46:00FromGitter<dm1try> or I should not even try to change it =)
17:46:36FromGitter<Araq> it's not expensive, the problem is that the OS's APIs make it super hard to do reliably
17:46:38FromGitter<arnetheduck> @alehander42 better, typically - because it deals with tradeoffs closer to the way a coder would do it .. consider for example the decision to split proc args over multiple lines - do you do it? do you put them aligned with `(`? etc - depending on the length of parameter names, you'll make different decisions here.. in nim for example, a declaration might be `a, b: int` - where do you linebreak that? there's a few
17:46:38FromGitter... ways to do it and some of them depend on your other preferences - how much do you care that you fit 80 chars etc? what's the surrounding code? how deeply nested are we already etc
17:47:47FromGitter<Araq> split block A into (B, C), eventually unmap(C) and you're in a world of pain.
17:48:03FromGitter<Araq> and it might work on x86 but fail on PowerPC.
17:48:39FromGitter<Araq> `unmap(pointer, size)` is a lie, you can not "unmap" memory, only what was once returned to you as a block start
17:50:06FromGitter<dm1try> ok, thx =) I'll try to investigate this topic later
17:51:06FromGitter<Vindaar> I'm confused. What do I have to do to assign the value of a `compileTime` var to a const? My const just ends up empty
17:51:23*stefanos82 quit (Quit: Quitting for now...)
17:55:49FromGitter<Vindaar> ahh
17:56:31FromGitter<Vindaar> to answer my own question: define compile time var outside `static`, do stuff in `static`, assign to const outside of static!
17:58:20FromGitter<Araq> when I try `40_000_000` I get "Error: unhandled exception: Protocol wrong type for socket [OSError]"
17:59:01FromGitter<Araq> so I look into `sockets.nim`
17:59:04FromGitter<Araq> and see
17:59:15FromGitter<Araq> "## *Warning:* Since version 0.10.2 this module is deprecated. ⏎ ⏎ ##Use the `net <net.html>`_"
17:59:36FromGitter<tim-st> sure, because of this I wrote a sync and async version
17:59:38FromDiscord<Shield> i tried 40_000_000 it works fine
17:59:49FromGitter<Araq> so yeah, as I said, give me a real program
17:59:52FromGitter<arnetheduck> btw, when doing generics, why is that that `static` is needed, as in the following example? `type X[x: static[int]] = array[x, byte]`..?
18:00:10*arnetheduck quit (Quit: Leaving)
18:00:10FromGitter<Araq> because the `x` is not a type, it's a value
18:01:17FromGitter<Araq> and it sucks IMO, the original Nim used `range[a..b]` to turn values into types and I like it much more
18:01:33FromGitter<arnetheduck> can you elaborate? is there some what that it could be interpreted as a type? ie `X[x:int]`?
18:02:13FromGitter<Araq> `X[T: int]` means it's a generic parametrized with a type placeholder `T ` that needs to be an int
18:02:42FromGitter<arnetheduck> ah, it's to constrain what T can be?
18:03:02FromGitter<Araq> yes
18:03:11FromGitter<arnetheduck> ok, that was what I was missing
18:04:11*sz0 joined #nim
18:08:59FromGitter<Araq> https://travis-ci.org/nim-lang/Nim/jobs/427301319 any ideas?
18:09:08miranis it intentional that i can concat two seq[array[2, int]] but i cannot seq[seq[int]]?
18:09:47TheLemonManshithub website was a bit flakey for me today so maybe they're having problems
18:10:29miran`proc concat[T](seqs: varargs[seq[T]]): seq[T]` but it raises `type mismatch: got <seq[seq[int]], seq[seq[int]]>`
18:10:32FromGitter<Araq> ok
18:10:51FromDiscord<Shield> this is driving me crazy, i think it may be related to the speed of allocating memory, when requesting large files using tim-st's code it won't free the memory but at least it'll reuse it, granted you don't spam requests, while the problem can happen in my code on a far more smaller file size
18:11:35FromDiscord<Shield> if it's an os problem, how can you deal with fast requests when it is the purpose of the server in the first place
18:11:53FromGitter<Araq> Shield: is this on Windows?
18:12:40FromGitter<tim-st> Shield: yes, I think fast request are more of a problem
18:13:36FromGitter<Araq> on Windows with `async` we never found the leak :-)
18:14:05FromDiscord<Shield> yeah it is on windows using 0.18.0
18:14:06FromGitter<Araq> and it was OS specific too iirc, Windows 8 leaked, Windows 10 didn't, or something like that
18:14:07*arecaceae quit (Remote host closed the connection)
18:14:08FromGitter<tim-st> I thought async was the problem, because of this I wrote the deprecated code too
18:14:17FromGitter<Vindaar> @miran: you can hand it as `concat([s1, s2])` instead of `concat(s1, s2)`. Not sure though why it doesn't work the other way
18:14:18FromGitter<tim-st> the non async is problematic too
18:14:25*arecaceae joined #nim
18:14:33FromDiscord<Shield> i'm running windows 7
18:14:43FromGitter<Araq> try windows 10 :-)
18:14:44FromGitter<tim-st> I'm also on win7
18:14:57miran@Vindaar that indeed works, thanks!
18:18:58FromGitter<Araq> https://github.com/nim-lang/Nim/pull/8949 tada
18:19:00FromDiscord<Shield> well, I intend to run the server on a vps so if it wouldn't have the same problem it's fine by me
18:19:51FromDiscord<Shield> I really don't want to use another language
18:19:56FromGitter<tim-st> I think so too, when it runs on linux with low occupied memory it's good
18:20:56FromGitter<Vindaar> miran: If one constrains `T` to be a `seq` in `concat`s definition (which is of course stupid in general), there's no type mismatch even without that workaround
18:21:05FromGitter<Vindaar> hmm
18:39:55*cspar joined #nim
18:40:44*xet7 quit (Ping timeout: 250 seconds)
18:41:47*cspar_ quit (Ping timeout: 240 seconds)
18:43:45*xet7 joined #nim
18:48:01TheLemonManhmm, JS's cstring is an array of uint16 and `[]` for it returns `char`, that sounds wrong
19:01:07FromGitter<Araq> there are only bad solutions for this, [] returning char was the best option
19:01:30FromGitter<timotheecour> Hey @araq, I’d like to get https://github.com/nim-lang/Nim/pull/8903 merged ; if that makes it easier I can comment out `defineSymbol("nimHasComment”)` ; would you be ok with that? I need the comment field for my use cases
19:01:43FromGitter<Araq> yeah, no.
19:01:52FromGitter<timotheecour> why not
19:02:08FromGitter<Araq> because it's a bad design.
19:02:28FromGitter<timotheecour> Nim lacks compile time reflection, I can’t see another way to reflect on comment fields without this.
19:02:58FromGitter<Araq> you should have noticed by now that I'm completely immune to words
19:03:56FromGitter<Araq> "Nim lacks compile time reflection on comments" is just a fancy way of saying "I cannot access the comment field"
19:04:23FromGitter<Araq> and yes, I know. the comment field is misdesigned if we make it accessible we have to live with this misdesign
19:04:24FromGitter<timotheecour> how is exposing comments (when passing `-d: nimHasComment`) in any way a problem ?
19:05:33FromGitter<timotheecour> You don’t have to use it yourself if you don’t need this use case, but I do.
19:05:33FromGitter<Araq> the use cases may be ok, the mechanism is not.
19:05:54FromGitter<timotheecour> so what other mechanism do you have in mind
19:06:41FromGitter<timotheecour> FWIW, `owner` also isn’t in the AST; yet, it’s useful for my use case.
19:07:00FromGitter<Araq> I fought against `owner` too
19:07:20FromGitter<timotheecour> and yet I’m glad it’s there, it solves a problem I had.
19:08:13FromGitter<timotheecour> more generally, `nim` should be powerful enough that `nim doc` should be doable in library code.
19:09:01FromGitter<Araq> because you say so? that's not listed as a requirement for any PL out there that's ever been designed
19:09:23FromGitter<Araq> but anyway, here is how to do it.
19:09:43FromGitter<Araq> only `##` comments end up in the AST. only at special positions.
19:09:59FromGitter<Araq> apart from the obvious `nkStmtList` where it can come up
19:10:45FromGitter<Araq> it can be part of an `nkIdentDefs` as the last node, reflecting `var x, y: int = value ## comment`
19:10:48FromGitter<timotheecour> > only at special positions. ⏎ ⏎ does that include all the comments that end up in nim doc?
19:11:19FromGitter<Araq> yes, eventually, it's a rather large cleanup we have to do
19:12:43FromGitter<timotheecour> so, this change under the hood can be done transparently while exposing a stable API as I did in this PR
19:12:52FromGitter<Araq> no.
19:13:01FromGitter<Araq> the AST structure needs to be changed.
19:14:11FromGitter<timotheecour> I have in my code (depending on this PR) a `proc getComment(a:NimNode)` that does the right thing for all kinds, dispatching the correct sub-node; that’s teh function that’d have a stable API.
19:14:27*Jesin quit (Quit: Leaving)
19:20:19FromGitter<Araq> I don't think we can do this reliably before we cleaned up the internal AST
19:21:50FromGitter<timotheecour> It works reliably currently on everything I mentioned in above comment, I’m happy ot share the code if you want to try it out; it works reliably for everything except var/let/const, for which somehow there’s no `comment` field in subtree.
19:25:15FromGitter<timotheecour> As an example, with this we could show the doc comment field for each hint in nim `—hints:list` , replace https://github.com/nim-lang/Nim/pull/8625/files (which is not DRY!) etc
19:30:26FromGitter<timotheecour> also, I dont’ think accessing `comment` via `n[^1]` is a better design that accessing it via `n.comment`, accessing it via a field is more type-safe/less error-prone.
19:36:13FromGitter<unreadable> did you guys considered using immix gc with the nim compiler?
19:37:43FromGitter<zetashift> quick googling gets me an irc log were Araq said: 'requires the ability to move things around. that pretty much means it's unusable for Nim.'
19:37:55FromGitter<zetashift> fwiw nim's current gc is great!
19:38:50FromGitter<unreadable> indeed, saw the benchmarks
19:42:16FromGitter<Araq> @unreadable I'm looking at the JVM's latest GC
19:42:35FromGitter<Araq> it uses read barriers instead of write barriers
19:42:53FromGitter<Araq> "ZGC" I think it's called. pretty impressive
19:45:23FromGitter<unreadable> hahaha, I was just reading this article right now
19:52:23*sagax joined #nim
19:52:49*zachcarter joined #nim
19:57:03*Vladar quit (Remote host closed the connection)
20:11:33*nsf quit (Quit: WeeChat 2.2)
20:16:25*hoijui quit (Ping timeout: 246 seconds)
20:42:30*miran quit (Ping timeout: 252 seconds)
20:45:26*Jesin joined #nim
20:52:34FromGitter<Bennyelg> ```Unhandled exception: Failed to parse '"2018-08-08 22:00:00"' with format 'yyyy-mm-dd hh:mm:ss'. Failed on pattern 'yyyy' [ValueError]```
21:29:55FromGitter<arnetheduck> I for one welcome what @timotheecour is trying to achieve - happy that someone is taking on `nim doc`whatever the practical solution for extracting the info from nodes might be.. one excuse less why the nim docs can't match https://doc.rust-lang.org/std/ ;)
21:31:52FromGitter<Vindaar> @Bennyelg works fine for me. Are you on devel or v0.18.0?
21:43:03FromDiscord<Shield> does the removal of pure pragma breaks any existing code? are there any changes with backward compatibility issues? some modules are already using devel while others weren't updated for months
21:48:34FromGitter<Araq> Shield: I haven't found any breakages wrt this feature
21:49:10FromGitter<Araq> @arnetheduck you mean like I am doing in my better-docgen branch?
21:52:48FromGitter<arnetheduck> @Araq haven't seen that one - what I do miss is good examples of how to write nice docs attached to the source code.. ideally the docs would pass a compile stage that would validate their sanity just as much as regular code.. ie examples compiled, parameter names and types matching, and there being a logical place for every type, field, proc etc etc where to put them
21:53:20FromGitter<arnetheduck> I guess RST is here to stay? it was nice 10 years ago, but hasn't.. uh, caught on
21:54:17FromGitter<Araq> I prefer RST over markdown but there is no reason we can't add the most important markdown features
21:54:36FromGitter<Araq> which seems to amount to "different link syntax"
21:56:57FromGitter<Araq> at least it doesn't have significant trailing whitespace *cough*
22:03:23FromGitter<arnetheduck> oh, quoting is different also.. ie single-backticks means something else which is annoying to remember, when the amount of ratio of md:rst in the world is 100:1.. ie both syntaxes do the same things mostly, but in subtly different ways.. in some ways I prefer rST also because of its well-defined extensibility - but from a pragmatic point of view.. *sigh*.. if it ends up being both, you'd have to have something that
22:03:23FromGitter... explicitly says which one it is, akin to <triple quotes+language> to do code blocks with syntax highlight in md
22:04:21*gangstacat quit (Quit: Ĝis!)
22:18:56*gangstacat joined #nim
22:21:50*Senketsu_ joined #nim
22:23:30*Senketsu_ quit (Remote host closed the connection)
22:23:52*gangstacat quit (Quit: Ĝis!)
22:24:08dom96https://nim-lang.org/blog/2018/09/11/nim-is-hiring.html
22:25:50FromGitter<kayabaNerve> Is it possible to make a macro that works as follows: ⏎ ⏎ ```type obj = ref object of RootObj ⏎ x: int {.singleAssignment.}``` [https://gitter.im/nim-lang/Nim?at=5b9840ee51a02e2a2617c3da]
22:27:47FromGitter<kayabaNerve> Throws an error if x is set to more than once?
22:28:57TheLemonManno, but you can use an accessor instead and record the number of times it's been set in the object itself
22:29:48FromGitter<kayabaNerve> Accessor as in `.x`(o: obj): int ?
22:30:53TheLemonManyeah
22:31:00FromGitter<kayabaNerve> Thanks
22:36:23*druonysus joined #nim
22:36:23*druonysus quit (Changing host)
22:36:23*druonysus joined #nim
22:38:34*TheLemonMan quit (Quit: "It's now safe to turn off your computer.")
22:38:57FromDiscord<2vg> hiring!!
22:43:35FromGitter<kayabaNerve> What do you mean "hiring!"?
22:44:25FromDiscord<2vg> kayabaNerve: https://nim-lang.org/blog/2018/09/11/nim-is-hiring.html
22:46:05*noonien quit (Quit: Connection closed for inactivity)
22:51:05*xet7 quit (Quit: Leaving)
22:52:27FromGitter<rayman22201> super tempting...
22:54:15FromDiscord<2vg> yeah...
22:59:22*gangstacat joined #nim
22:59:59*cspar_ joined #nim
23:01:47*cspar quit (Ping timeout: 240 seconds)
23:14:56AlexMaxzachcarter: I think I'm doing this wrong
23:15:14AlexMaxI got your example rendering okay
23:16:09AlexMaxBut it's a little laggy and "behind the cursor"
23:16:18AlexMaxdunno if it's supposed to be like that or not
23:16:30AlexMax(I'm talking about your nim nuklear bindings, sorry)
23:16:57AlexMaxbut anyway, I didn't see any obvious way to build the example, and it seemed to want imports from....places
23:17:33AlexMaxI also didn't want to install nuklear-nim to build the example, I wanted to build the example using the in-place nim file
23:18:46AlexMaxI guess where I'm going with this is - if I contribute patches, I presume you want the example to build without relative import paths?
23:25:46AlexMaxactually, hrm, it doesn't appear that I can add flags to the "build" task by defining a "build" task in the nimble file
23:27:18AlexMaxNot really sure how I'm supposed to build the example as it stands, then - it depends on a "roboto_regular" import that's actually in the parent directory, and there's no ../ by the import
23:28:17AlexMaxIf I pass --path:. to a normal 'nim c' invocation, it works just fine, of course
23:40:42AlexMax..but if I know where the library is, why bother with trying to pass -path:whatever to the compiler
23:48:01FromDiscord<exelotl> something small I figured out today https://gist.github.com/geckojsc/03c23322c4237b873a68f018516dfaae
23:51:54AlexMaxhrm, every time I `nimble build` it asks me if I want to overwrite glfw 3.2.1
23:52:07AlexMaxand if I say "no" it backs out
23:52:14AlexMaxand doesn't build