00:00:51 | FromGitter | <bung87> I'm also wondering the results. |
00:03:38 | FromGitter | <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:49 | FromGitter | <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:12 | zestyr | So 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:34 | zestyr | Sending 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:09 | FromDiscord | <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:11 | zestyr | https://gist.github.com/zestyr/38eae7ceeebbe81aaecd9b96f36ffa63 |
02:15:33 | zestyr | it's an ugly hack that probably breaks some stuff, but it works in my case |
02:21:32 | zestyr | unfortunately the contents are allocated/duplicated 3 times, but I couldn't find a simple way to reduce that further |
02:21:59 | zestyr | without this hack it gets allocated 5 times |
02:24:35 | zestyr | 6* |
02:25:21 | FromGitter | <gogolxdong> how do you profile allocation? |
02:25:40 | zestyr | `getOccupiedMem` and `getTotalMem` |
02:25:52 | zestyr | this is when using the markAndSweep gc btw, the others seem to perform worse here |
02:25:59 | FromGitter | <gogolxdong> and the times? |
02:26:24 | zestyr | well, reading the code and looking at the memory usage |
02:29:43 | zestyr | hmm 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:29 | zestyr | I'll post some more detailed results in the issue |
02:32:33 | zestyr | ah yeah, using the default GC or boehm results in 461 MB occupied, ie. 6 allocations, with markAndSweep I get 377 |
02:35:17 | shashlick | You really need to figure out a way to upload in chunks |
02:38:27 | shashlick | Perhaps extend httpclient to accept an open stream or something |
02:39:20 | shashlick | Imagine if YouTube read every video file into memory before playing |
02:39:46 | FromDiscord | <Shield> isn't this a related issue https://github.com/nim-lang/Nim/issues/5589 |
02:40:16 | * | cspar_ joined #nim |
02:40:37 | zestyr | Yeah 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:37 | zestyr | Shield: that's an async thing, which somehow works far worse for me. All this has been with the non-async HttpClient |
02:42:41 | shashlick | I ran into a similar issue in the past |
02:42:42 | shashlick | https://github.com/nim-lang/Nim/issues/6031 |
02:43:34 | zestyr | yeah I've seen that issue |
02:43:37 | shashlick | But I agree that expecting a GC to free this responsibly even without leaks is unreasonable |
02:43:53 | shashlick | I've since updated my algorithm to work in chunks |
02:44:43 | shashlick | Even if you manually malloc and free, there will be size limitations - i.e your ram |
02:44:54 | zestyr | All 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:12 | shashlick | Ran into this on my python proxy server as well |
02:46:54 | shashlick | Perhaps extend httpclient or consider curl |
02:47:16 | FromDiscord | <Shield> wouldn't a GC_fullCollect at least release the memory reserved for reading the file |
02:48:37 | shashlick | It doesn't since GC could reuse that memory later |
02:49:11 | shashlick | At least back when I tried, maybe it has changed but doubt it |
02:50:14 | zestyr | Calling 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:29 | FromGitter | <gogolxdong> @zacharycarter does your port work with material design? |
03:00:40 | FromGitter | <gogolxdong> Don't know whether --gc:regions help. Have a try. |
03:04:25 | * | Tanger joined #nim |
03:05:16 | zestyr | Nope. With regions I get 330MB, markAndSweep 252MB |
03:07:34 | FromGitter | <gogolxdong> Did you check withScratchRegion, we are using this with --gc:regions |
03:08:15 | FromGitter | <gogolxdong> gc:regions and gc:stack seems the same thing. |
03:16:45 | zestyr | hmm, I tried it in a few places but it either results in the same mem usage or the upload failing |
03:19:30 | FromGitter | <gogolxdong> sad. |
03:24:16 | FromGitter | <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:48 | FromGitter | <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:21 | zachcarter | gogolxdong: material design is just a styling thing right? I don't see why it wouldn't |
03:34:42 | zachcarter | sorry - I've been out for most of the evening |
03:50:34 | FromGitter | <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:36 | FromGitter | <wsdjeg> https://www.reddit.com/r/nim/comments/9etzht/develop_nim_in_spacevim_language_layer_for_nim/ |
03:50:53 | FromGitter | <gogolxdong> take a rest. Becaue I didn't implement it in virtual DOM. |
03:52:59 | FromGitter | <gogolxdong> the html tag generated by macro can be used in hyperHtml concept, <> is tedious. |
04:15:10 | FromDiscord | <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:18 | FromGitter | <alehander42> http://cs242.stanford.edu/assets/projects/2017/parastoo-gdietz44.pdf |
04:46:18 | FromGitter | <alehander42> The strong effect of inline errors is interesting |
04:47:01 | FromGitter | <alehander42> I guess having the error and the source (the context) nearby is always more useful |
04:47:42 | FromGitter | <alehander42> is there a reason the context for nim errors is behind a flag |
04:47:58 | FromGitter | <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:24 | FromGitter | <Grabli66> Hi! Is the new runtime with destructors ready for using? |
05:52:07 | * | kapil___ joined #nim |
05:59:52 | FromGitter | <DanielSokil> https://youtu.be/XzYaw8hfqEE |
06:03:55 | FromGitter | <gogolxdong> https://github.com/nim-lang/Nim/issues/7041 |
06:06:48 | FromGitter | <Grabli66> Thanks |
06:08:11 | FromGitter | <Grabli66> Nim will be transformed to Rust? :) |
06:09:41 | FromGitter | <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:38 | FromGitter | <bung87> question about mathematics: do I need check the params before calculate or just catch OverflowError ? |
07:11:16 | FromGitter | <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:31 | FromGitter | <xmonader> is there any change of behavior between 0.18 and devel when it comes to index errors? |
07:26:05 | FromGitter | <narimiran> @xmonader what do you mean? |
07:26:23 | FromGitter | <narimiran> IIRC, you cannot do `string[^0]` anymore |
07:26:47 | FromGitter | <xmonader> i switched from 0.18 to devel and my code is havng lots of indexError unhandled.. |
07:26:57 | FromGitter | <xmonader> do i require that for any slicing operation? |
07:28:22 | FromGitter | <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:27 | FromGitter | <narimiran> *helps |
07:28:47 | FromGitter | <xmonader> i'll check thanks |
07:28:59 | FromGitter | <narimiran> i'm not aware of any other changes |
07:40:03 | FromGitter | <xmonader> damn my tests passed on 0.18 and now i've to worry again about finished work to fix :( |
07:54:26 | FromGitter | <xmonader> @narimiran so main problem was [i..len(s)] was valid somehow in 0.18 and it was inclusive |
07:54:33 | FromGitter | <xmonader> but now i need to do ^1 or len(s)-1 |
07:54:42 | FromGitter | <Bennyelg> why is it crying ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5b9774c20fb4232e38a86915] |
07:55:18 | FromGitter | <Bennyelg> oh |
07:55:22 | FromGitter | <Bennyelg> fixed sorry ;] |
07:55:46 | TheLemonMan | you forgot the constructor call |
07:55:49 | FromGitter | <narimiran> @xmonader yeah `[len(s)]` is beyond the last element |
07:55:58 | FromGitter | <Bennyelg> yea :D |
07:56:19 | FromGitter | <narimiran> @xmonader you can do `i ..< len(s)` |
07:56:53 | FromGitter | <xmonader> yea but i think ^1 (first last) more intuitive a bit :D |
07:57:19 | FromGitter | <xmonader> but i'm correct, it was valid and it'd return the upper bound instead of failing |
07:57:47 | FromGitter | <narimiran> yeah, you can do `^1`, but please don't do `len(s) - 1` — it is ugly! :) |
08:03:24 | FromGitter | <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:24 | FromGitter | ... [https://gitter.im/nim-lang/Nim?at=5b9776cca04db554a70b5cfb] |
08:03:30 | * | gmpreussner_ quit (Ping timeout: 252 seconds) |
08:03:56 | FromGitter | <mratsim> or each entity carries a proc closure that serve as handler |
08:03:57 | * | gmpreussner joined #nim |
08:04:08 | FromGitter | <mratsim> You have timings of each strategy at the bottom |
08:05:20 | FromGitter | <mratsim> I would avoid closure especially for short-lived objects because they are heap allocated |
08:05:38 | FromGitter | <mratsim> and there is no way to write a memory-pool for closure |
08:07:17 | * | couven92 joined #nim |
08:12:04 | FromGitter | <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:31 | FromGitter | <timotheecour> hi @Araq are you here? may be faster to discuss here instead of on PR |
09:04:30 | FromGitter | <Grabli66> How to build DLL with nimble? I don't see any settings for nimble file to do that. |
09:05:29 | FromGitter | <mratsim> create a task or replace the nimble build task with your DLL settings |
09:05:48 | leorize | or add a <projectname>.nims file with the relevant flags |
09:11:48 | PMunch | Grabli66, have you figured out a way to actually create DLLs that won't crash or have crazy behavior? |
09:12:43 | FromGitter | <Grabli66> PMunch, i'll try don't use referrences :) |
09:12:54 | FromGitter | <Grabli66> And set gc:none |
09:12:59 | PMunch | Ah, so just avoid the GC.. |
09:13:03 | PMunch | That's a shame |
09:13:29 | FromGitter | <Grabli66> I think it's the only way. |
09:14:12 | PMunch | Yeah, until the DLL/GC stuff is fixed |
09:17:10 | FromGitter | <xmonader> Anyone using docopt? or is there some better way? |
09:17:34 | FromGitter | <Grabli66> PMunch, I think Nim in future will be like Rust. Language with no GC. |
09:19:42 | PMunch | xmonader, I played around with it at some point |
09:20:38 | PMunch | You do have parseopt and parseopt2 |
09:21:41 | PMunch | And you have https://github.com/fenekku/commandeer |
09:22:27 | FromGitter | <xmonader> @PMunch they dont support subparsers by default no? |
09:22:43 | PMunch | subparsers? |
09:23:16 | FromGitter | <xmonader> subcommands ⏎ proj new --opt1 --opt2 ⏎ proj save --opt1 --opt2 ⏎ ..etc [https://gitter.im/nim-lang/Nim?at=5b97898445318b2dfe913c6a] |
09:24:08 | PMunch | Yes they do |
09:24:12 | PMunch | Or commandeer does |
09:24:32 | PMunch | https://github.com/fenekku/commandeer#documentation |
09:25:32 | PMunch | parseopt2 can probably do it with some manual help |
09:25:53 | FromGitter | <xmonader> ah never heard of commandeer I was just checking cligen |
09:26:49 | PMunch | I 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:03 | PMunch | It's the perfect candidate for macro-magic |
09:27:26 | PMunch | Having a small terminal program spend most of it's time parsing your doc-string is just silly :P |
09:28:30 | FromGitter | <xmonader> maybe u should do it now :D because docopt just failed me a while ago :( |
09:28:59 | PMunch | Failed you? |
09:34:45 | FromGitter | <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:49 | PMunch | cligen? |
09:47:58 | * | dddddd joined #nim |
09:48:21 | FromGitter | <xmonader> @PMunch this one https://github.com/c-blake/cligen |
09:48:35 | FromGitter | <xmonader> I remember it was promoted here in the chat |
09:54:38 | PMunch | Hmm, cligen looks interesting |
09:55:48 | FromGitter | <xmonader> It's, i'm afraid i'll have to fallback for std parseopt |
09:56:52 | PMunch | Did you try comandeer? |
09:59:08 | FromGitter | <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:16 | PMunch | Ah, compiling cligen with --nilseqs:on makes it work on devel |
09:59:32 | PMunch | That should be an easy fix |
10:00:46 | FromGitter | <xmonader> Didn't even know the nilseqs option existed.. :( |
10:02:17 | PMunch | It's to easy the transition to non-nilable seqs and strings |
10:04:21 | FromGitter | <Bennyelg> cligen is awesome |
10:04:24 | FromGitter | <Bennyelg> Im using it |
10:11:00 | FromGitter | <xmonader> @Bennyelg I kinda like it too! |
10:15:04 | PMunch | Never seen it before, but it looks cool |
10:29:13 | * | zachcarter quit (Ping timeout: 245 seconds) |
10:29:24 | FromGitter | <mratsim> @PMunch, are you calling the DLL from Nim or from C? |
10:29:36 | FromGitter | <mratsim> from C I think just NimMain() before anything does the trick |
10:29:44 | FromGitter | <mratsim> from Nim well I don’t know |
10:30:41 | PMunch | This 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:52 | FromGitter | <kaushalmodi> PMunch, @xmonader : cligen is fixed in its master branch |
11:26:02 | FromGitter | <kaushalmodi> Just git clone and nimble install |
11:26:20 | FromGitter | <kaushalmodi> The dev will cut a release when the next Nim release is cut. |
11:26:40 | FromGitter | <kaushalmodi> @xmonader cligen supports subcommands |
11:27:11 | FromGitter | <kaushalmodi> I had created a PR to use cligen for your nstow package ;) |
11:27:23 | FromGitter | <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:46 | FromDiscord | <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:24 | FromGitter | <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:02 | FromGitter | <dm1try> @tim-st could you point to the issue link? |
12:15:57 | FromGitter | <tim-st> https://github.com/nim-lang/Nim/issues/5589#issuecomment-350467569 |
12:17:05 | FromGitter | <tim-st> and here: https://github.com/nim-lang/Nim/issues/6031#issuecomment-351083338 |
12:24:44 | * | PMunch joined #nim |
12:32:07 | FromGitter | <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:45 | FromDiscord | <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:58 | FromGitter | <Vindaar> @narimiran should ping you on gitter I guess |
12:34:32 | FromGitter | <mratsim> mmm there is no way to popFirst and popLast in OrderedTableRef :/ |
12:34:35 | * | hoijui joined #nim |
12:39:12 | FromGitter | <narimiran> thanks @Vindaar, will try it to do that way |
12:39:45 | FromGitter | <Vindaar> I haven't tested it, so I hope it actually works :D |
12:40:26 | FromGitter | <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:18 | FromGitter | <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:31 | FromGitter | <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:12 | FromGitter | <Vindaar> With a `typed` macro you could do `myMacro(Shape)` and then use `getImpl` to get the tree that defines the type |
12:44:41 | FromGitter | <narimiran> "yeah, yeah, i understand some of these words".jpg |
12:45:31 | FromGitter | <Vindaar> You know, I'm just throwing around random things too :D |
12:46:30 | FromGitter | <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:27 | FromDiscord | <PusiteGA> hmm how to play sound with nim , do i have to use ffmpeg or something like that |
13:01:36 | FromDiscord | <PusiteGA> just want to play alarm beep |
13:02:19 | PMunch | Depends |
13:02:22 | PMunch | Cross platform? |
13:02:33 | FromDiscord | <PusiteGA> not really just linux |
13:02:45 | FromDiscord | <PusiteGA> i dont use windows at all |
13:02:49 | PMunch | On Linux you could always set up your terminal to make a sound on the bell character and print out one of those |
13:03:24 | FromDiscord | <PusiteGA> i know i can make bash script just wanted to practice little nim |
13:03:48 | FromDiscord | <PusiteGA> just wasent shure what to use for play sound , meybe some C sound lib |
13:05:18 | FromDiscord | <Shield> you can use sdl2_mixer if you want to play audio files |
13:06:18 | PMunch | This might work: https://github.com/yglukhov/sound |
13:08:04 | FromDiscord | <PusiteGA> even better |
13:08:49 | FromDiscord | <PusiteGA> 1 question tought , how do i nimble it form github |
13:09:17 | FromDiscord | <PusiteGA> or can just nimble install sound |
13:09:37 | FromDiscord | <PusiteGA> ok it works |
13:09:49 | FromDiscord | <PusiteGA> sorry next time will try then ask xD |
13:10:26 | PMunch | If 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:45 | FromDiscord | <PusiteGA> i installed it whit nimble , but duno how to install from repo, just download it and extract or install whit nimble |
13:13:52 | FromDiscord | <PusiteGA> *git repo |
13:14:20 | PMunch | I think you can just do "nimble install |
13:14:30 | PMunch | Uhm, "nimble intsall <url>" |
13:14:45 | PMunch | That is the URL to the git repo, not the github page |
13:15:30 | * | Vladar quit (Remote host closed the connection) |
13:20:00 | FromDiscord | <PusiteGA> ok will try that in future |
13:26:13 | FromGitter | <xmonader> @kaushalmodi oh! it was you! :D why didn't u continue that PR? it'd be nice to have cligen ^_^ |
13:26:52 | FromDiscord | <Shield> what happen if you try to dealloc memory managed by the gc? |
13:27:21 | FromDiscord | <Shield> the gc seems to print a message about it but memory usage is unchanged |
13:27:36 | FromGitter | <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:43 | FromGitter | <kaushalmodi> I use cligen in all my toy projects |
13:36:54 | FromGitter | <Bennyelg> Any thoughts about Julia 1.0 performance? |
13:39:49 | * | hoijui joined #nim |
13:40:17 | FromDiscord | <PusiteGA> hmm i imported import sound.sound and did nimble install sound |
13:40:40 | FromDiscord | <PusiteGA> but var snd:Sound = newSoundWithPath(fPath) gives me RandomWorkout.nim(10, 19) Error: undeclared identifier: 'newSoundWithPath' |
13:41:46 | FromGitter | <narimiran> try to do just `import sound` and see if anything changes |
13:41:54 | FromGitter | <bung87> `import sound.sound` ?? |
13:43:44 | FromDiscord | <PusiteGA> its writed like that on github page , ok will try just sound |
13:44:21 | FromDiscord | <PusiteGA> nah cant import just sound |
13:44:23 | FromDiscord | <PusiteGA> RandomWorkout.nim(1, 8) Error: cannot open 'sound' |
13:44:53 | FromGitter | <bung87> you have dir or file named sound? |
13:45:23 | FromDiscord | <PusiteGA> nothing of those |
13:45:24 | FromDiscord | <PusiteGA> https://github.com/yglukhov/sound |
13:45:48 | FromDiscord | <PusiteGA> i have a sound file s1.ogg |
13:46:20 | FromDiscord | <PusiteGA> in getCurrentDir() & /sfx/s1.ogg |
13:47:21 | FromGitter | <bung87> this package didn't specify `src` dir in nimble file. |
13:48:27 | FromGitter | <bung87> I don't think it's ready for public, if you use it fork and modify it |
13:48:59 | FromDiscord | <PusiteGA> oh i am too newbie to do that for now |
13:49:23 | FromGitter | <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:03 | FromDiscord | <PusiteGA> i think i found issue |
13:52:14 | FromDiscord | <PusiteGA> by browsing trought code |
13:53:55 | FromDiscord | <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:06 | FromGitter | <bung87> without modify the package? |
13:55:07 | * | PMunch quit (Quit: Leaving) |
13:55:09 | * | voice_ftp_ joined #nim |
13:55:16 | FromGitter | <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:25 | FromGitter | <alehander42> hm it seems nimpretty isn't stable yet, i wanted to run it on some stuff |
15:17:50 | FromGitter | <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:47 | FromGitter | <Bennyelg> what the hack is this uninformative error ⏎ ``` Error: tabulators are not allowed``` |
16:05:19 | TheLemonMan | don't use tabs |
16:06:42 | FromGitter | <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:04 | FromGitter | <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:05 | FromGitter | ... http://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s-Dragons |
16:26:10 | FromGitter | <Varriount> @arnetheduck How do those tools parse/internally represent the input? |
16:33:21 | FromGitter | <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:50 | FromGitter | <arnetheduck> what's nice about it is its ability to deal with "difficult" situations.. this is where dogmatic renderers break down |
16:39:07 | FromGitter | <Araq> @arnetheduck nimpretty doesn't work from the AST anymore, it uses the lexer and some semantic info |
16:40:02 | FromGitter | <arnetheduck> @Araq ooh, that sounds like the right building blocks then, nice! |
16:41:49 | FromGitter | <Araq> yeah, time will tell if the remaining bugs are just bugs or inherent flaws in the approach |
16:43:32 | FromGitter | <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:09 | FromGitter | <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:46 | FromGitter | <Araq> @bung87 sorry, no. |
16:48:52 | FromGitter | <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:22 | FromGitter | <Araq> and the code is now a parser patch, ``` ⏎ when defined(nimpretty2): ⏎ ⏎ `````` [https://gitter.im/nim-lang/Nim?at=5b97f212e6e309365e398f9c] |
16:51:20 | FromGitter | <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:45 | FromDiscord | <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:22 | FromDiscord | <Shield> i guess the problem isn't just sending files, but sending anything at all |
16:59:13 | FromGitter | <Araq> report it properly |
16:59:36 | FromGitter | <Araq> ideally without the `mofuw` dependency |
17:01:47 | FromGitter | <Araq> https://xkcd.com/2044/ |
17:07:21 | FromDiscord | <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:53 | FromDiscord | <Shield> this may be the GC not freeing/reusing memory |
17:08:27 | FromGitter | <Araq> I've looked are more "GC leaks" than everybody else and it never was a "GC leak" |
17:08:49 | FromGitter | <Araq> it was fragmentation, stdlib bugs or wrong caching |
17:09:28 | FromGitter | <Araq> *looked at |
17:10:34 | FromGitter | <Bennyelg> How I can get the database error when tryExec gives false |
17:10:44 | FromGitter | <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:04 | FromGitter | <Araq> what does that mean? "total GC amount increases"? |
17:14:12 | FromGitter | <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:31 | FromGitter | <tim-st> I have not seen this at other gc'ed languages |
17:14:51 | FromDiscord | <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:11 | FromGitter | <Araq> returning RAM back to the OS is hard. the allocator doesn't try hard to do that |
17:15:17 | FromGitter | <tim-st> it's only a problem with very big data at once |
17:15:24 | FromGitter | <Araq> and iirc Python doesn't do that either |
17:15:31 | FromGitter | <tim-st> because of this I wrote the example: https://gist.github.com/tim-st/abbb86a591172a7b997c853fcda5cff9 |
17:15:35 | FromGitter | <Araq> it's definitely not unique to Nim. |
17:16:00 | FromGitter | <tim-st> I tested a python http server it goes up and down exactly how it's needed |
17:16:28 | FromGitter | <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:37 | FromGitter | <Araq> it should stream it... |
17:16:55 | FromGitter | <tim-st> no, I created this code to prove there is something wrong |
17:17:08 | FromGitter | <tim-st> it's not about the question how one should send data |
17:17:53 | FromGitter | <Araq> yes, it's about that. |
17:18:16 | FromGitter | <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:41 | FromGitter | <tim-st> there is, an os become extremely unstable when much ram like 80% is used |
17:18:51 | FromGitter | <Araq> swap? |
17:19:07 | FromGitter | <Araq> but hey, what do I know. |
17:19:28 | FromGitter | <tim-st> so it's not a bug, it's a feature? |
17:19:49 | FromGitter | <Araq> and if you wanna serve 10GB and only have 2 GB of RAM you are fine with a dying server? |
17:20:09 | FromDiscord | <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:29 | FromGitter | <tim-st> yes, that's the problem I saw too |
17:20:58 | FromDiscord | <Shield> if 1mb is enough to cause the problem, then how big can an object be without triggering this problem |
17:21:31 | FromGitter | <tim-st> probably every object does, but it develops the problem very slowly |
17:22:11 | FromGitter | <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:27 | FromGitter | <Araq> these problems are completely different. |
17:22:41 | FromDiscord | <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:37 | FromGitter | <Araq> yeah, probably, but I need real reproducible examples |
17:24:04 | FromGitter | <tim-st> this reproduces on windows and linux devel: https://gist.github.com/tim-st/abbb86a591172a7b997c853fcda5cff9 |
17:24:10 | FromGitter | <Araq> and not just code that allocates 10GB of RAM for serving a 10GB file |
17:24:23 | FromGitter | <tim-st> it's 100mb not 10gb |
17:24:45 | FromDiscord | <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:55 | FromGitter | <Araq> if it depends on the file size, it's wrong. |
17:26:49 | FromGitter | <tim-st> it seems java does it: https://stackoverflow.com/questions/30458195/does-gc-release-back-memory-to-os |
17:27:09 | FromGitter | <Araq> oh ffs |
17:27:13 | FromGitter | <tim-st> go does it not |
17:27:16 | FromGitter | <Araq> yes, some do, some don't. |
17:27:20 | FromGitter | <kayabaNerve> Is the comment Nim doesn't or Nim rarely doesn't? |
17:27:38 | * | leorize joined #nim |
17:28:29 | FromDiscord | <Shield> i think somebody tried the same with go and it worked normally |
17:28:40 | FromGitter | <kayabaNerve> And does this behavior change between the different GCs? |
17:28:51 | FromGitter | <tim-st> yes, go fixed it, I read now |
17:31:59 | FromDiscord | <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:55 | FromGitter | <Araq> give me a real program. `let blob = repeat('X', size)` is bullshit code |
17:34:44 | FromGitter | <alehander42> @arnetheduck sounds interesting, does it achieve the same quality as ast-based formatters for valid code though? |
17:35:05 | FromGitter | <alehander42> i am not so interested in formatting invalid code (but i can see the pro-s) |
17:36:28 | FromDiscord | <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:27 | FromGitter | <Araq> I used `let blob = repeat('X', 40_000)` and don't get any leak |
17:45:27 | FromGitter | <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:00 | FromGitter | <dm1try> or I should not even try to change it =) |
17:46:36 | FromGitter | <Araq> it's not expensive, the problem is that the OS's APIs make it super hard to do reliably |
17:46:38 | FromGitter | <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:38 | FromGitter | ... 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:47 | FromGitter | <Araq> split block A into (B, C), eventually unmap(C) and you're in a world of pain. |
17:48:03 | FromGitter | <Araq> and it might work on x86 but fail on PowerPC. |
17:48:39 | FromGitter | <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:06 | FromGitter | <dm1try> ok, thx =) I'll try to investigate this topic later |
17:51:06 | FromGitter | <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:49 | FromGitter | <Vindaar> ahh |
17:56:31 | FromGitter | <Vindaar> to answer my own question: define compile time var outside `static`, do stuff in `static`, assign to const outside of static! |
17:58:20 | FromGitter | <Araq> when I try `40_000_000` I get "Error: unhandled exception: Protocol wrong type for socket [OSError]" |
17:59:01 | FromGitter | <Araq> so I look into `sockets.nim` |
17:59:04 | FromGitter | <Araq> and see |
17:59:15 | FromGitter | <Araq> "## *Warning:* Since version 0.10.2 this module is deprecated. ⏎ ⏎ ##Use the `net <net.html>`_" |
17:59:36 | FromGitter | <tim-st> sure, because of this I wrote a sync and async version |
17:59:38 | FromDiscord | <Shield> i tried 40_000_000 it works fine |
17:59:49 | FromGitter | <Araq> so yeah, as I said, give me a real program |
17:59:52 | FromGitter | <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:10 | FromGitter | <Araq> because the `x` is not a type, it's a value |
18:01:17 | FromGitter | <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:33 | FromGitter | <arnetheduck> can you elaborate? is there some what that it could be interpreted as a type? ie `X[x:int]`? |
18:02:13 | FromGitter | <Araq> `X[T: int]` means it's a generic parametrized with a type placeholder `T ` that needs to be an int |
18:02:42 | FromGitter | <arnetheduck> ah, it's to constrain what T can be? |
18:03:02 | FromGitter | <Araq> yes |
18:03:11 | FromGitter | <arnetheduck> ok, that was what I was missing |
18:04:11 | * | sz0 joined #nim |
18:08:59 | FromGitter | <Araq> https://travis-ci.org/nim-lang/Nim/jobs/427301319 any ideas? |
18:09:08 | miran | is it intentional that i can concat two seq[array[2, int]] but i cannot seq[seq[int]]? |
18:09:47 | TheLemonMan | shithub website was a bit flakey for me today so maybe they're having problems |
18:10:29 | miran | `proc concat[T](seqs: varargs[seq[T]]): seq[T]` but it raises `type mismatch: got <seq[seq[int]], seq[seq[int]]>` |
18:10:32 | FromGitter | <Araq> ok |
18:10:51 | FromDiscord | <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:35 | FromDiscord | <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:53 | FromGitter | <Araq> Shield: is this on Windows? |
18:12:40 | FromGitter | <tim-st> Shield: yes, I think fast request are more of a problem |
18:13:36 | FromGitter | <Araq> on Windows with `async` we never found the leak :-) |
18:14:05 | FromDiscord | <Shield> yeah it is on windows using 0.18.0 |
18:14:06 | FromGitter | <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:08 | FromGitter | <tim-st> I thought async was the problem, because of this I wrote the deprecated code too |
18:14:17 | FromGitter | <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:18 | FromGitter | <tim-st> the non async is problematic too |
18:14:25 | * | arecaceae joined #nim |
18:14:33 | FromDiscord | <Shield> i'm running windows 7 |
18:14:43 | FromGitter | <Araq> try windows 10 :-) |
18:14:44 | FromGitter | <tim-st> I'm also on win7 |
18:14:57 | miran | @Vindaar that indeed works, thanks! |
18:18:58 | FromGitter | <Araq> https://github.com/nim-lang/Nim/pull/8949 tada |
18:19:00 | FromDiscord | <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:51 | FromDiscord | <Shield> I really don't want to use another language |
18:19:56 | FromGitter | <tim-st> I think so too, when it runs on linux with low occupied memory it's good |
18:20:56 | FromGitter | <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:05 | FromGitter | <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:01 | TheLemonMan | hmm, JS's cstring is an array of uint16 and `[]` for it returns `char`, that sounds wrong |
19:01:07 | FromGitter | <Araq> there are only bad solutions for this, [] returning char was the best option |
19:01:30 | FromGitter | <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:43 | FromGitter | <Araq> yeah, no. |
19:01:52 | FromGitter | <timotheecour> why not |
19:02:08 | FromGitter | <Araq> because it's a bad design. |
19:02:28 | FromGitter | <timotheecour> Nim lacks compile time reflection, I can’t see another way to reflect on comment fields without this. |
19:02:58 | FromGitter | <Araq> you should have noticed by now that I'm completely immune to words |
19:03:56 | FromGitter | <Araq> "Nim lacks compile time reflection on comments" is just a fancy way of saying "I cannot access the comment field" |
19:04:23 | FromGitter | <Araq> and yes, I know. the comment field is misdesigned if we make it accessible we have to live with this misdesign |
19:04:24 | FromGitter | <timotheecour> how is exposing comments (when passing `-d: nimHasComment`) in any way a problem ? |
19:05:33 | FromGitter | <timotheecour> You don’t have to use it yourself if you don’t need this use case, but I do. |
19:05:33 | FromGitter | <Araq> the use cases may be ok, the mechanism is not. |
19:05:54 | FromGitter | <timotheecour> so what other mechanism do you have in mind |
19:06:41 | FromGitter | <timotheecour> FWIW, `owner` also isn’t in the AST; yet, it’s useful for my use case. |
19:07:00 | FromGitter | <Araq> I fought against `owner` too |
19:07:20 | FromGitter | <timotheecour> and yet I’m glad it’s there, it solves a problem I had. |
19:08:13 | FromGitter | <timotheecour> more generally, `nim` should be powerful enough that `nim doc` should be doable in library code. |
19:09:01 | FromGitter | <Araq> because you say so? that's not listed as a requirement for any PL out there that's ever been designed |
19:09:23 | FromGitter | <Araq> but anyway, here is how to do it. |
19:09:43 | FromGitter | <Araq> only `##` comments end up in the AST. only at special positions. |
19:09:59 | FromGitter | <Araq> apart from the obvious `nkStmtList` where it can come up |
19:10:45 | FromGitter | <Araq> it can be part of an `nkIdentDefs` as the last node, reflecting `var x, y: int = value ## comment` |
19:10:48 | FromGitter | <timotheecour> > only at special positions. ⏎ ⏎ does that include all the comments that end up in nim doc? |
19:11:19 | FromGitter | <Araq> yes, eventually, it's a rather large cleanup we have to do |
19:12:43 | FromGitter | <timotheecour> so, this change under the hood can be done transparently while exposing a stable API as I did in this PR |
19:12:52 | FromGitter | <Araq> no. |
19:13:01 | FromGitter | <Araq> the AST structure needs to be changed. |
19:14:11 | FromGitter | <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:19 | FromGitter | <Araq> I don't think we can do this reliably before we cleaned up the internal AST |
19:21:50 | FromGitter | <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:15 | FromGitter | <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:26 | FromGitter | <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:13 | FromGitter | <unreadable> did you guys considered using immix gc with the nim compiler? |
19:37:43 | FromGitter | <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:55 | FromGitter | <zetashift> fwiw nim's current gc is great! |
19:38:50 | FromGitter | <unreadable> indeed, saw the benchmarks |
19:42:16 | FromGitter | <Araq> @unreadable I'm looking at the JVM's latest GC |
19:42:35 | FromGitter | <Araq> it uses read barriers instead of write barriers |
19:42:53 | FromGitter | <Araq> "ZGC" I think it's called. pretty impressive |
19:45:23 | FromGitter | <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:34 | FromGitter | <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:55 | FromGitter | <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:52 | FromGitter | <Vindaar> @Bennyelg works fine for me. Are you on devel or v0.18.0? |
21:43:03 | FromDiscord | <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:34 | FromGitter | <Araq> Shield: I haven't found any breakages wrt this feature |
21:49:10 | FromGitter | <Araq> @arnetheduck you mean like I am doing in my better-docgen branch? |
21:52:48 | FromGitter | <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:20 | FromGitter | <arnetheduck> I guess RST is here to stay? it was nice 10 years ago, but hasn't.. uh, caught on |
21:54:17 | FromGitter | <Araq> I prefer RST over markdown but there is no reason we can't add the most important markdown features |
21:54:36 | FromGitter | <Araq> which seems to amount to "different link syntax" |
21:56:57 | FromGitter | <Araq> at least it doesn't have significant trailing whitespace *cough* |
22:03:23 | FromGitter | <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:23 | FromGitter | ... 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:08 | dom96 | https://nim-lang.org/blog/2018/09/11/nim-is-hiring.html |
22:25:50 | FromGitter | <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:47 | FromGitter | <kayabaNerve> Throws an error if x is set to more than once? |
22:28:57 | TheLemonMan | no, but you can use an accessor instead and record the number of times it's been set in the object itself |
22:29:48 | FromGitter | <kayabaNerve> Accessor as in `.x`(o: obj): int ? |
22:30:53 | TheLemonMan | yeah |
22:31:00 | FromGitter | <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:57 | FromDiscord | <2vg> hiring!! |
22:43:35 | FromGitter | <kayabaNerve> What do you mean "hiring!"? |
22:44:25 | FromDiscord | <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:27 | FromGitter | <rayman22201> super tempting... |
22:54:15 | FromDiscord | <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:56 | AlexMax | zachcarter: I think I'm doing this wrong |
23:15:14 | AlexMax | I got your example rendering okay |
23:16:09 | AlexMax | But it's a little laggy and "behind the cursor" |
23:16:18 | AlexMax | dunno if it's supposed to be like that or not |
23:16:30 | AlexMax | (I'm talking about your nim nuklear bindings, sorry) |
23:16:57 | AlexMax | but anyway, I didn't see any obvious way to build the example, and it seemed to want imports from....places |
23:17:33 | AlexMax | I 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:46 | AlexMax | I 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:46 | AlexMax | actually, 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:18 | AlexMax | Not 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:17 | AlexMax | If I pass --path:. to a normal 'nim c' invocation, it works just fine, of course |
23:40:42 | AlexMax | ..but if I know where the library is, why bother with trying to pass -path:whatever to the compiler |
23:48:01 | FromDiscord | <exelotl> something small I figured out today https://gist.github.com/geckojsc/03c23322c4237b873a68f018516dfaae |
23:51:54 | AlexMax | hrm, every time I `nimble build` it asks me if I want to overwrite glfw 3.2.1 |
23:52:07 | AlexMax | and if I say "no" it backs out |
23:52:14 | AlexMax | and doesn't build |