| 00:00:09 | * | Hideki_ quit (Ping timeout: 268 seconds) |
| 00:00:32 | Araq | not yet, i'm currently not fixing somebody else's codebase |
| 00:00:33 | rayman22201 | valgrind says it doesn't leak |
| 00:00:45 | disruptek | rayman22201: i agree it looks pretty inescapable. |
| 00:00:45 | Araq | used -d:useMalloc? |
| 00:00:50 | rayman22201 | yup |
| 00:01:11 | disruptek | lemme try |
| 00:01:19 | Araq | maybe it's still accessible via the gDispatcher |
| 00:01:40 | Araq | and I dunno if valgrind reports stuff in globals |
| 00:02:20 | Araq | or maybe there is yet another arc bug so that it forgot to update some refcount |
| 00:02:32 | rayman22201 | It does, because I get "possible leaks" from the gDispatcher |
| 00:02:38 | rayman22201 | which I'm ignoring :-P |
| 00:02:48 | disruptek | yep, says no leak. |
| 00:03:09 | disruptek | only two allocs. |
| 00:03:12 | Araq | I would trust my nose. |
| 00:03:31 | Araq | the cycle jumps into your face, something else is going on |
| 00:03:39 | * | krux02__ joined #nim |
| 00:03:46 | disruptek | orc has nothing to say about it. |
| 00:03:54 | rayman22201 | well, that's part of my problem. I don't see the cycle |
| 00:04:04 | rayman22201 | I thought I saw the cycle, and now I don't trust myself |
| 00:04:21 | Araq | .closure --> resFut |
| 00:04:35 | Araq | resFut --> callback seq --> .closure |
| 00:04:36 | Araq | no? |
| 00:05:03 | disruptek | yep. |
| 00:06:27 | rayman22201 | so why doesn't valgrind or orc detect it? |
| 00:06:45 | disruptek | it doesn't even work. |
| 00:06:49 | Araq | check getOccupiedMem() |
| 00:06:52 | rayman22201 | it works for me |
| 00:07:04 | Araq | run it in a loop and see getOccupiedMem's numbers |
| 00:07:25 | Araq | I found that the most reliable way to look for leaks by far |
| 00:07:27 | rayman22201 | I wonder if it's because I short circuit it by completing the Future immediately |
| 00:07:30 | * | krux02_ quit (Ping timeout: 265 seconds) |
| 00:07:38 | Araq | that's possible, sure |
| 00:07:43 | Araq | anyhow |
| 00:07:43 | rayman22201 | that's horrible. we need better tools :-P |
| 00:08:00 | rayman22201 | ok go to sleep. gn Araq. thanks |
| 00:08:14 | Araq | it's excellent, most of my tests use it |
| 00:08:24 | Araq | let mem = getOccupiedMem() |
| 00:08:27 | Araq | crazyStuff() |
| 00:08:35 | Araq | assert getOccupiedMem() == mem |
| 00:08:47 | disruptek | yeah, there's a nice debugging template in golden for this. |
| 00:08:54 | disruptek | spec.nim |
| 00:09:17 | disruptek | actually, iirc it's not that nice. it just collects all the calls i could find. |
| 00:09:27 | Araq | var resFut {.cursor.} = newFuture[string]("asyncProc") |
| 00:09:35 | Araq | should work out |
| 00:09:42 | Araq | then the captures don't harm |
| 00:09:57 | Araq | and we return it anyway, no need to refcount it |
| 00:10:54 | Araq | but same here, have to sleep. good night |
| 00:11:00 | disruptek | peace |
| 00:11:37 | disruptek | that solves the problem here, but it relies on the programmer to break the cycle. |
| 00:12:21 | rayman22201 | https://play.nim-lang.org/#ix=27GU |
| 00:12:25 | rayman22201 | this crashes |
| 00:12:37 | rayman22201 | so it's the `callback=` proc after all |
| 00:12:40 | disruptek | this isn't an .async. proc. |
| 00:12:50 | disruptek | this asyncProc() you gave me. |
| 00:12:55 | disruptek | is defective. |
| 00:13:31 | rayman22201 | lol. I'm building Futures by hand to explore the mechanism |
| 00:13:46 | disruptek | i want my money back. |
| 00:13:51 | rayman22201 | I'm not going to use the macro to see what part of the macro is broken. |
| 00:14:06 | rayman22201 | 100000000 schmecles. here you go |
| 00:14:12 | disruptek | sshh there are people in the back that didn't hear you. |
| 00:14:52 | disruptek | anyway, programmers gonna write stupid code. i have no plans to stop. |
| 00:15:36 | disruptek | we have it solve this properly. |
| 00:15:40 | disruptek | to |
| 00:17:01 | rayman22201 | I don't think this is improper |
| 00:17:04 | rayman22201 | you build this into the macro |
| 00:17:04 | disruptek | first i gotta eat the rest of this box of thin mints. |
| 00:18:13 | rayman22201 | fascinating. Making it .cursor. limits the leak to 72 bytes |
| 00:18:34 | disruptek | so the only futures they use are ours? |
| 00:19:05 | nisstyre | Something odd is going on with my program. I'm expecting to get "19.5" but I get "6.25" https://play.nim-lang.org/#ix=27GV |
| 00:19:17 | nisstyre | I've verified the algorithm is giving the correct output, so it must be some floating point issue |
| 00:22:33 | nisstyre | oh |
| 00:22:35 | nisstyre | nevermind |
| 00:23:12 | nisstyre | derp |
| 00:23:19 | rayman22201 | I bet it's the closure here that's leaking: https://github.com/nim-lang/Nim/blob/devel/lib/pure/asyncfutures.nim#L279 |
| 00:23:33 | rayman22201 | as usual, araq is probably right :-P |
| 00:23:34 | nisstyre | I'm not popping items off the stack |
| 00:25:50 | rayman22201 | but IDK what araq is talking about. removing that closure is a can of worms |
| 00:26:12 | rayman22201 | it makes callSoon not work. |
| 00:26:24 | rayman22201 | callSoon then needs the Future object somehow |
| 00:28:31 | rayman22201 | I get it now |
| 00:28:42 | rayman22201 | both what araq was saying and what I was saying is true |
| 00:28:44 | rayman22201 | ugghhh |
| 00:28:48 | rayman22201 | It's two things |
| 00:28:51 | rayman22201 | both creating cycles |
| 00:29:58 | rayman22201 | so check this out: https://play.nim-lang.org/#ix=27GZ |
| 00:30:00 | rayman22201 | that is leak free |
| 00:31:43 | disruptek | i get it. |
| 00:31:56 | disruptek | i just really wonder if this is safe. |
| 00:32:21 | disruptek | i can't really see how we can prevent people from using the cursor. |
| 00:33:41 | rayman22201 | actually nope. I took out the cursor. still no leak |
| 00:33:48 | rayman22201 | I also did the getOccupiedmem thing |
| 00:33:53 | rayman22201 | still no leak |
| 00:33:54 | rayman22201 | so wat |
| 00:35:03 | rayman22201 | https://play.nim-lang.org/#ix=27H0 |
| 00:35:09 | disruptek | hmm, you're right. |
| 00:35:10 | rayman22201 | no leak |
| 00:35:14 | rayman22201 | bu |
| 00:35:20 | disruptek | what else do you have in your branch? |
| 00:35:38 | rayman22201 | but this leaks: https://play.nim-lang.org/#ix=27H1 |
| 00:35:46 | rayman22201 | nothing |
| 00:36:45 | disruptek | okay, this leaks, but not recursing doesn't? |
| 00:37:02 | rayman22201 | right, the point is not the recursion, but the self reference capture |
| 00:37:16 | rayman22201 | actually it does recurse once |
| 00:37:17 | disruptek | yeah, so we need another half-way point. |
| 00:37:34 | rayman22201 | this is weird. getOccupiedMem says no leaks, but valgrind says yes leaks |
| 00:38:11 | disruptek | i guess that makes sense, right? |
| 00:40:15 | rayman22201 | how? |
| 00:41:01 | disruptek | closureRef doesn't need to refcount it. |
| 00:41:31 | rayman22201 | I took out the .cursor, so it should still refcount |
| 00:44:42 | disruptek | i got no leaks in orc. |
| 00:45:00 | rayman22201 | well yeah, orc can do cycles :-P |
| 00:45:09 | disruptek | i just have too much output. |
| 00:45:31 | rayman22201 | comment out the echos |
| 00:46:41 | * | brainproxy quit (Quit: WeeChat 2.7) |
| 00:47:15 | disruptek | yeah, i have no leaks in arc. |
| 00:47:31 | disruptek | just recursing with a cursor. |
| 00:47:46 | disruptek | but it still feels like a huge ask to me. |
| 00:47:54 | rayman22201 | I'm confused |
| 00:48:14 | disruptek | it feels like a lot to ask of the dfa or of the programmer. |
| 00:48:20 | disruptek | or of the macro, even. |
| 00:48:34 | rayman22201 | but my example doesn't have a cursor |
| 00:48:36 | rayman22201 | I took it out |
| 00:48:44 | disruptek | yeah, i changed it. |
| 00:48:58 | rayman22201 | I can't read your mind. please share |
| 00:49:10 | disruptek | var window {.cursor.}: typeof(closureRef) |
| 00:49:55 | disruptek | so the way we have a weak ref is to make a new ref, weak, and use that instead. |
| 00:50:46 | FromGitter | <aboisvert> compiling code with `--gc:arc`, I'm getting: ⏎ ⏎ /home/boisvert/.choosenim/toolchains/nim-#devel/lib/system/threads.nim(104, 28) template/generic instantiation of `add` from here ⏎ /home/boisvert/.choosenim/toolchains/nim-#devel/lib/system/seqs_v2.nim(117, 21) Error: system module needs: nimDestroyAndDispose [https://gitter.im/nim-lang/Nim?at=5e2256655b81ab262e450320] |
| 00:51:05 | * | fys quit (Remote host closed the connection) |
| 00:51:29 | disruptek | does that make sense? |
| 00:51:46 | FromGitter | <aboisvert> does this point to some sort of missing destructor for one of my types, or is this because --gc:arc is not yet ready for my code? |
| 00:52:08 | rayman22201 | I see. fascinating |
| 00:52:14 | disruptek | it looks like a choosenim problem. |
| 00:52:32 | disruptek | but, i cannot read pastes on gitter. |
| 00:52:51 | disruptek | there was a new choosenim released recently. |
| 00:54:10 | * | tane quit (Quit: Leaving) |
| 00:54:13 | disruptek | so, i'd update choosenim first. then if you still have the problem, please paste the output where we can read it. |
| 00:55:52 | FromGitter | <aboisvert> got it, i'll try that, thanks! |
| 00:57:02 | * | lritter quit (Quit: Leaving) |
| 00:59:04 | rayman22201 | I'm trying to plugin cursor annotations to the macro output, and I'm still leaking |
| 00:59:16 | rayman22201 | this confuses me even more |
| 00:59:51 | voltist | This error is a great moment in my life: "Error: unhandled exception: key not found: intestine [KeyError]" |
| 00:59:52 | disruptek | http://ix.io/27H4/nim |
| 01:00:06 | disruptek | intestines really are key. |
| 01:00:14 | disruptek | don't let no one tell you different. |
| 01:00:27 | FromGitter | <aboisvert> updated choosenim, same error. also compiled nim from source and used latest `devel` branch, same thing. |
| 01:01:19 | rayman22201 | disruptek, yeah I'm with you there. But when I try to go to the next step. plugging it back into the async macro output, it doesn't work |
| 01:01:30 | disruptek | what does it say? |
| 01:02:09 | rayman22201 | https://www.irccloud.com/pastebin/ikVaPDQU/ |
| 01:02:28 | disruptek | well, shit, ray. |
| 01:02:32 | disruptek | that's hardly nothing. |
| 01:02:52 | disruptek | you know how many gigs of memory my machine has? |
| 01:03:16 | FromDiscord | <exelotl> are pattern matching templates a stable feature? |
| 01:03:28 | FromDiscord | <exelotl> I can't see them in the manual anywhere |
| 01:03:31 | disruptek | like what? |
| 01:03:57 | rayman22201 | https://play.nim-lang.org/#ix=27H5 |
| 01:04:07 | rayman22201 | am I missing a cursor? |
| 01:04:14 | rayman22201 | lol, get moar RAM naow!!! |
| 01:04:21 | FromDiscord | <exelotl> in this video |
| 01:04:21 | FromDiscord | <exelotl> https://cdn.discordapp.com/attachments/371759389889003532/667897019490369546/unknown.png |
| 01:04:48 | disruptek | it's, like, impossible to view this image for me. |
| 01:04:54 | rayman22201 | term rewriting macros are experimental |
| 01:04:55 | disruptek | i dunno why discord is so mean. |
| 01:04:58 | rayman22201 | that's what that is |
| 01:05:23 | rayman22201 | it's not really "pattern matching" anyway |
| 01:05:35 | disruptek | it's like scope. |
| 01:06:08 | rayman22201 | https://nim-lang.org/docs/manual_experimental.html#term-rewriting-macros |
| 01:06:38 | FromDiscord | <exelotl> ahh so that's where I've seen it before |
| 01:07:25 | rayman22201 | disruptek: also note, the getOccupiedmem diff shows 0 lol |
| 01:07:40 | disruptek | memory comes, memory goes. |
| 01:07:55 | * | JustASlacker quit (Ping timeout: 265 seconds) |
| 01:07:57 | rayman22201 | you just can't trust your memory these days :-P |
| 01:08:04 | disruptek | i really can't. |
| 01:09:11 | disruptek | what were you expecting? |
| 01:09:37 | disruptek | sorry, i just finally looked at the code. |
| 01:10:02 | rayman22201 | I took what we learned from that simple example, and tried to apply it to the real thing |
| 01:10:10 | rayman22201 | i.e. add cursor in all the right places |
| 01:10:20 | rayman22201 | I failed to get the right places :-P |
| 01:10:33 | disruptek | right. |
| 01:10:34 | rayman22201 | I got friends in low places? |
| 01:10:44 | * | icebattle quit (Ping timeout: 258 seconds) |
| 01:11:31 | rayman22201 | what am I missing here? there is some cursor annotation I'm missing |
| 01:12:08 | disruptek | so we need to call the callbacks with a ref to the closure if they're gonna use it for anything. |
| 01:12:26 | disruptek | so we give them a {.cursor.}. |
| 01:13:08 | rayman22201 | you can see me doing that with "closureWindow" |
| 01:13:54 | disruptek | oh i see. now i think it's the callback= call. |
| 01:14:04 | rayman22201 | and just for grins, I made the ref to the Future a cursor |
| 01:14:20 | disruptek | yeah, that's fine. |
| 01:14:29 | rayman22201 | but callback= happens in the simple example too |
| 01:14:32 | rayman22201 | no leaks there |
| 01:14:42 | disruptek | oh, maybe you did it right. sorry, let me look again. |
| 01:14:44 | rayman22201 | how is this closure different? |
| 01:15:53 | disruptek | so one other thing is that we need to point every reference to the closure at the window. |
| 01:15:53 | rayman22201 | once we fix this, I will try to tell you why I think adding cursor to the macro is good enough :-P |
| 01:16:10 | rayman22201 | I thought I did that too |
| 01:16:15 | rayman22201 | but maybe I missed one? |
| 01:16:19 | disruptek | well you can't threaten me with a good time like that. |
| 01:16:41 | rayman22201 | lol |
| 01:16:59 | disruptek | i don't see recursion here. |
| 01:18:12 | disruptek | the callback should be getting closureWindow as an argument. |
| 01:18:17 | disruptek | 2nd arg. |
| 01:18:38 | disruptek | next_gensym400019 is the first arg; that's the future, baby. |
| 01:18:41 | disruptek | THE FUTURE. |
| 01:20:27 | disruptek | cursor to the macro. |
| 01:21:30 | rayman22201 | GREAT SCOTT! We need 1.21 gigawattz |
| 01:21:41 | * | luis_ quit (Quit: luis_) |
| 01:21:49 | disruptek | is that right? |
| 01:21:52 | disruptek | that doesn't sound right. |
| 01:22:30 | rayman22201 | fun fact. making the closure iterator use the cursor to the promise makes it "leak more clean", as in valgrind has less output. |
| 01:22:46 | rayman22201 | but still 8mb of leakage |
| 01:23:29 | disruptek | there are few things finer than making valgrinds thinner. |
| 01:23:48 | disruptek | but why do you leak? |
| 01:24:05 | disruptek | c'mon i want a victory here. |
| 01:24:24 | rayman22201 | I know I know. I feel sooo close |
| 01:25:39 | disruptek | remember this crash bug? https://play.nim-lang.org/#ix=27H9 |
| 01:30:41 | rayman22201 | lol. I do now |
| 01:32:20 | disruptek | ~return is in prior versions of nim, a reliable method of dumping the compiler's memory to disk. |
| 01:32:21 | disbot | return: 11in prior versions of nim, a reliable method of dumping the compiler's memory to disk. |
| 01:42:22 | rayman22201 | hahaha |
| 01:42:40 | rayman22201 | ok. I have to take off. I am at a loss at this point |
| 01:43:24 | * | Hideki_ joined #nim |
| 01:47:11 | disruptek | alright, have a good one. |
| 01:48:27 | * | Hideki_ quit (Ping timeout: 272 seconds) |
| 01:50:22 | rayman22201 | it's something with closure iterators |
| 01:50:25 | rayman22201 | lol. I lied |
| 01:51:14 | rayman22201 | I think .cursor on closure iterators might be broken? |
| 01:51:49 | disruptek | well, the powers that He are certain that iterators are fine. |
| 01:52:56 | disruptek | ~araq is 👑 the powers that He 👑 |
| 01:52:57 | disbot | araq: 11👑 the powers that He 👑 |
| 01:57:59 | rayman22201 | ok, check this out: https://play.nim-lang.org/#ix=27Hd |
| 01:58:06 | rayman22201 | minimum repro |
| 01:58:14 | rayman22201 | it leaks |
| 02:00:19 | rayman22201 | I think it has something to do with the fact that assignment for iterators is overloaded to give you the "iterator instance" |
| 02:00:45 | rayman22201 | and that is the thing I want a cursor of |
| 02:00:55 | rayman22201 | but because it's implicit magic, I can't do that |
| 02:01:02 | disruptek | ah, that makes sense. |
| 02:01:07 | rayman22201 | or tldr .cursor. doesn't work on iterators |
| 02:01:14 | rayman22201 | and it kind of needs to |
| 02:01:18 | disruptek | but i'm surprised it just overlooks the cursor. |
| 02:01:23 | disruptek | i mean, the pragma. |
| 02:01:35 | disruptek | it makes me think maybe that magic is less likely. |
| 02:01:42 | rayman22201 | well, that's my hand wavy guess |
| 02:01:56 | rayman22201 | I don't actually know what is going on here |
| 02:02:00 | disruptek | yeah, i get it. |
| 02:02:35 | rayman22201 | ok. I have to go for real now. But I think this is good progress. Something to show araq when he wakes up anyway :-) |
| 02:02:36 | rayman22201 | gn |
| 02:02:41 | disruptek | cya |
| 02:03:07 | disruptek | async is leak-free in the lab but not production, basically. |
| 02:03:48 | rayman22201 | lol. yup. |
| 02:11:28 | * | smitop quit (Quit: Connection closed for inactivity) |
| 02:21:23 | * | matti quit (Ping timeout: 265 seconds) |
| 02:22:30 | * | matti joined #nim |
| 02:35:33 | * | Hideki_ joined #nim |
| 02:51:58 | * | Hideki_ quit (Remote host closed the connection) |
| 02:52:45 | * | Hideki_ joined #nim |
| 02:57:18 | * | Hideki_ quit (Ping timeout: 258 seconds) |
| 03:18:49 | * | dddddd quit (Remote host closed the connection) |
| 03:33:04 | * | Hideki_ joined #nim |
| 03:44:55 | voltist | I had a runaway intestine problem https://imgur.com/a/VjgkYkN |
| 03:45:28 | disruptek | those are the worst. |
| 03:45:50 | voltist | Quite |
| 03:46:20 | voltist | Also, I'm quite dissapointed by the lack of good graphing libraries for Nim |
| 03:46:36 | voltist | The best I found works using the browser |
| 03:46:46 | disruptek | plotly? |
| 03:47:07 | voltist | Yeah |
| 03:47:14 | disruptek | yeah, i wish we had a nice svg grapher. |
| 03:47:40 | voltist | It hasn't got a great API either |
| 03:48:05 | voltist | Python's matplotlib is simple but powerful, and its great |
| 03:48:52 | * | seni quit (Quit: Leaving) |
| 03:50:10 | disruptek | someone smart will give us something amazing. |
| 03:50:29 | voltist | Hopefully |
| 03:50:43 | disruptek | i leave cookies out every night. |
| 03:51:30 | voltist | For now I just have to investigate runaway intestine problems with web-based graphs |
| 03:51:56 | disruptek | nimetry is a thing i've used. |
| 03:51:59 | disruptek | !repo nimetry |
| 03:52:00 | disbot | https://github.com/refaqtor/nimetry -- 9nimetry: 11Plotting in Nim 15 0⭐ 1🍴 |
| 03:52:01 | * | Hideki_ quit (Ping timeout: 268 seconds) |
| 03:52:42 | voltist | Huh, I'll check it out |
| 03:53:18 | Yardanico | disbot: and you didn't even star it!11 |
| 03:53:50 | Yardanico | i mean disruptek, sorry |
| 03:53:52 | disruptek | what a jerk. |
| 03:53:54 | * | logand` joined #nim |
| 03:54:10 | disruptek | i think because i pulled it out of golden. |
| 03:55:36 | * | muffindrake quit (Ping timeout: 252 seconds) |
| 03:56:49 | FromDiscord | <mfiano> Hello again |
| 03:57:47 | disruptek | wb mfiano |
| 03:57:53 | * | muffindrake joined #nim |
| 03:58:06 | FromDiscord | <mfiano> I'm still weighing on whether I want to use Nim for new (rare) projects of mine, or scrap what for the most part amounts to my life's work and rewrite it in Nim. |
| 03:58:11 | * | logand quit (Ping timeout: 268 seconds) |
| 03:59:49 | disruptek | i think almost all code is too valuable to delete. |
| 04:00:11 | disruptek | it's one thing to rewrite it, but it's madness to remove/cripple it. |
| 04:01:00 | FromDiscord | <mfiano> This is true, especially since it isn't very possible in many other languages, to this extent anyway, and it's very mature and almost usable at this point. But, it's all I hardly ever work on, and I'm desperately trying to find ways to integrate Nim into my everyday work. |
| 04:01:49 | disruptek | should be able to mix it into your existing stuff. |
| 04:02:06 | disruptek | it's probably worth doing well for both communities. |
| 04:03:38 | FromDiscord | <mfiano> My existing thing is a game engine comparable to Unity, written in CL, with full support for interactive development. Recompile a texture definition DSL to point to a new image on disk with new texture parameters and see it update instantly in game. Change a material definition to see the shader program and uniforms changed instantly. Change an individual shader function and see the entire program and its dependencies rebuilt instantly, etc |
| 04:03:48 | FromDiscord | <mfiano> It has taken my more than 10 years already... |
| 04:03:53 | FromDiscord | <mfiano> It has taken me more than 10 years already... |
| 04:04:32 | disruptek | have you played with hot code reloading yet? |
| 04:06:01 | FromDiscord | <mfiano> Yes, and I think anyone familiar enough with it can admit it has a few limitations, and for me they dissuade me from relying on it at all still. |
| 04:06:20 | disruptek | what are the issues with it? |
| 04:07:52 | FromDiscord | <mfiano> I'd have to open up my notes to answer that, but I noticed they coincided with some videos I watched about reloading things too early to crash everything |
| 04:08:37 | disruptek | i dunno anything about it, but i'm ruminating on trying a repl. |
| 04:11:30 | FromDiscord | <mfiano> I'm actually no longer wishing to find a language offering the level of interactivity of Common Lisp, because I've been looking for years and nothing comes close, in an effort to actually start using something that isn't CL 🙂 |
| 04:12:12 | disruptek | i can understand that. |
| 04:13:35 | FromDiscord | <mfiano> What dissuades me more, is I kinda feel like I should know C before I start using Nim (at least for the type of real-time code I would be writing), and I am accustomed to working in a managed language. Yes, I know Nim has quite a few different GC strategies (or none at all), but in reading a lot of Nim code and listening to others in the community, I feel I ought to be familiar with manual memory management and other C-isms at least somewhat |
| 04:14:09 | disruptek | eh i don't think it's so useful. |
| 04:15:19 | FromDiscord | <mfiano> Like I still can't grasp references and ownership I hear so much about these lower level languages. |
| 04:16:07 | disruptek | it's not really required to understand in order to be productive, though. |
| 04:17:49 | FromDiscord | <mfiano> I bought Nim in Action and found a lot of the projects to be hard to understand, particularly because I'm not very familiar with parallelism abstractions like async/await and promises/futures, among other reasons. |
| 04:18:26 | FromDiscord | <mfiano> So at this point I'm wondering what a real good first step would be |
| 04:18:45 | shashlick | Start with porting something simple over |
| 04:18:56 | disruptek | build something you need. |
| 04:18:56 | shashlick | Less than 50 lines worth |
| 04:19:26 | FromDiscord | <mfiano> I don't really need anything. I program as a hobby, and mostly the same game engine for a decade now :/ |
| 04:19:45 | disruptek | ah i can't help but to write stuff. |
| 04:21:58 | shashlick | am now trying to port px from Python to Nim since I'll never maintain it otherwise |
| 04:23:24 | FromDiscord | <mfiano> Yeah...I will. What I don't know yet. I will say I have studied in great depth several dozen languages, new and old, over the last few years, and Nim is the only one that I can relate to. Gotta hand it to Araq and contributors once more for that. |
| 04:24:20 | disruptek | hard to look at other languages the same way. |
| 04:24:29 | shashlick | how about you share small snippets and we can help you port something |
| 04:24:34 | shashlick | get a feel for stuff |
| 04:27:54 | FromDiscord | <mfiano> Most of my code is heavily macro based to defer evaluation for DSLs and whatnot. I'm not sure I could provide such a contained example so readily |
| 04:29:03 | disruptek | sounds like you're in a tough situation. |
| 04:29:25 | FromDiscord | <mfiano> But how about for starters, pointing me to a library, if one exists, that allows writing GLSL in a Nim DSL, such that I can hot-reload a single shader function to force the recompilation of all shader programs making use of this function...or offering advise on how to do that in Nim. |
| 04:29:45 | disruptek | krux02 is the expert in this. |
| 04:29:47 | FromDiscord | <mfiano> But how about for starters, pointing me to a library, if one exists, that allows writing GLSL in a Nim DSL, such that I can hot-reload a single shader function to force the recompilation of all shader programs making use of this function transitively...or offering advise on how to do that in Nim. |
| 04:29:57 | disruptek | he has a glsl compiler in nim macros. |
| 04:30:25 | disruptek | actually, i think he has a youtube video demonstrating how to port to it. |
| 04:30:43 | FromDiscord | <mfiano> I'd be interested in that video if you can find it 🙂 |
| 04:31:26 | disruptek | https://invidio.us/embed/mcMr142BxtI |
| 04:32:36 | FromDiscord | <mfiano> I guess I would start by writing y own linear algebra library, even though I'm sure one exists. Lots of challenges await writing one that is correct, performant, and with a nice API. It took me years to iterate on the one I use for my game engine anyway. |
| 04:32:42 | FromDiscord | <mfiano> I guess I would start by writing my own linear algebra library, even though I'm sure one exists. Lots of challenges await writing one that is correct, performant, and with a nice API. It took me years to iterate on the one I use for my game engine anyway. |
| 04:35:21 | * | rockcavera quit (Remote host closed the connection) |
| 05:04:38 | FromDiscord | <mfiano> disruptek, while that video was pretty neat, it doesn't do what I was talking about. There is no-reuse of GLSL functions between different shader programs. The entire stage is stored in a constant as a raw string, and just included in this very simple DSL. |
| 05:04:42 | * | jwm224 quit (Quit: WeeChat 2.8-dev) |
| 05:28:09 | * | ptdel quit (Remote host closed the connection) |
| 05:42:11 | * | martinium joined #nim |
| 06:38:03 | FromDiscord | <Rika> hello |
| 06:44:15 | * | narimiran joined #nim |
| 06:56:34 | Zevv | leorize[m]: what was the cause of your 0x555555559ab2 bug the other day? |
| 06:56:44 | * | marmotini_ joined #nim |
| 07:00:51 | * | marmotini_ quit (Ping timeout: 240 seconds) |
| 07:07:13 | shashlick | gosh async is a nightmare |
| 07:07:40 | shashlick | i need to call an async proc in a callback which isn't async |
| 07:08:39 | Zevv | shashlick: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ |
| 07:10:11 | shashlick | tl;dr, will read later 😄 |
| 07:10:32 | shashlick | if i cannot call my async proc, i have to read all this data into memory instead of writing it thru |
| 07:10:41 | * | marmotini_ joined #nim |
| 07:11:38 | * | marmotini_ quit (Remote host closed the connection) |
| 07:11:54 | * | marmotini_ joined #nim |
| 07:15:16 | Zevv | well, you can call it |
| 07:15:18 | Zevv | but you can't wait for it |
| 07:15:26 | FromDiscord | <Rika> async can be waited for |
| 07:15:33 | FromDiscord | <Rika> with `waitFor` |
| 07:15:47 | FromDiscord | <Rika> but it's gonna be treated like a sync function |
| 07:15:53 | Zevv | yeah sure, but it blocks the rest of the callback stuff that is no async :) |
| 07:17:27 | shashlick | ya but it doesn't work correctly |
| 07:17:36 | shashlick | the return value is interpreted incorrectly by the caller |
| 07:17:58 | shashlick | Future[cint] return value |
| 07:18:37 | shashlick | if i remove Future[cint] {.async.} and comment out the proc, return value works fine |
| 07:19:46 | * | martinium quit (Quit: Textual IRC Client: www.textualapp.com) |
| 07:20:46 | FromDiscord | <Rika> ? |
| 07:21:16 | shashlick | that's nice, AsyncSocket has isClosed, but Socket does not |
| 07:23:14 | FromDiscord | <Rika> yeah there's a lot of stuff nim's types have when async but dont when sync |
| 07:23:20 | FromDiscord | <Rika> not sure why |
| 07:23:32 | FromDiscord | <Rika> some make sense though |
| 07:24:25 | FromDiscord | <Rika> Zevv, `I promise the future is better` |
| 07:24:28 | FromDiscord | <Rika> lmao the article |
| 07:24:50 | shashlick | wow the net and asyncnet are totally different APIs, that's really not good |
| 07:26:24 | * | solitudesf joined #nim |
| 07:32:27 | FromDiscord | <Rika> hmm, rfc proposal of unifying the async and sync library APIs? |
| 07:38:26 | * | nsf joined #nim |
| 07:40:42 | FromGitter | <gogolxdong> could not load: avutil-(|55|56|57).dll , have avutil.dll under the same directory. |
| 07:40:59 | * | NimBot joined #nim |
| 07:41:10 | shashlick | it is looking for avutil-xx.dll |
| 07:41:37 | Yardanico | @gogolxdong are you sure the architectures of the DLL and binary match? |
| 07:41:41 | Yardanico | they should both be 32-bit or 64-bit |
| 07:42:42 | FromGitter | <gogolxdong> which does nim need? or depends on cpu arch? |
| 07:49:35 | * | marmotini_ quit (Remote host closed the connection) |
| 07:59:56 | * | marmotini_ joined #nim |
| 08:00:00 | * | gmpreussner quit (Quit: kthxbye) |
| 08:03:00 | skrylar[m] | i'm not sure why you would explicitly need nim macros to compile shaders? really just any old preprocessor would do. especially since you can just {.gulp.} or staticexec the results at build time anyhow... |
| 08:04:50 | * | marmotini_ quit (Ping timeout: 240 seconds) |
| 08:04:56 | * | gmpreussner joined #nim |
| 08:06:21 | * | marmotini_ joined #nim |
| 08:08:25 | Zevv | can anyone with compiler knowledge tell my how this can work? http://ix.io/27HP |
| 08:09:09 | Zevv | oh dang nevermind, too soon again |
| 08:12:17 | * | gmpreussner quit (Ping timeout: 265 seconds) |
| 08:13:06 | Araq | gogolxdong: avutil-(|55|56|57).dll |
| 08:13:10 | Araq | should be |
| 08:13:21 | Araq | avutil(|-55|-56|-57).dll |
| 08:21:16 | * | go|dfish quit (Ping timeout: 265 seconds) |
| 08:23:07 | * | go|dfish joined #nim |
| 08:26:23 | * | Trustable joined #nim |
| 08:29:04 | * | marmotini_ quit (Remote host closed the connection) |
| 08:32:53 | * | filcuc joined #nim |
| 08:36:07 | FromGitter | <gogolxdong> yes, I found that and it's also a 32 bit dll. :) |
| 09:16:25 | * | tane_ joined #nim |
| 09:18:39 | FromGitter | <dawkot> is there a good reason to not add multiple values to the same table key? |
| 09:19:32 | * | tane_ left #nim (#nim) |
| 09:20:09 | * | tane joined #nim |
| 09:20:24 | * | JustASlacker joined #nim |
| 09:29:50 | * | filcuc quit (Ping timeout: 258 seconds) |
| 09:32:51 | * | JustASlacker quit (Ping timeout: 240 seconds) |
| 09:35:02 | Zevv | well that was funny |
| 09:35:05 | Zevv | sometimes alloc is alloc |
| 09:35:08 | Zevv | and sometimes alloc is alloc0 |
| 09:35:14 | Zevv | that makes for nice surprises |
| 09:36:30 | Zevv | and that took me longer then I dare to admit |
| 09:41:20 | zedeus | https://github.com/microsoft/verona |
| 09:41:46 | zedeus | @mratsim seen this? |
| 09:45:40 | * | JustASlacker joined #nim |
| 09:55:52 | FromDiscord | <Recruit_main_70007> What’s the name of the vectors library?? |
| 10:03:09 | FromDiscord | <Rika> what vectors library?? |
| 10:03:14 | FromDiscord | <Rika> @Recruit_main_70007 what do you mean |
| 10:03:23 | * | ng0_ joined #nim |
| 10:03:46 | FromDiscord | <Recruit_main_70007> there was one, but i dont remember |
| 10:03:51 | FromDiscord | <Rika> nimglm? |
| 10:03:56 | FromDiscord | <Recruit_main_70007> i think |
| 10:03:59 | FromDiscord | <Recruit_main_70007> thx |
| 10:04:02 | Zevv | arraymancer? |
| 10:04:57 | Zevv | nah |
| 10:05:52 | * | ng0 quit (Ping timeout: 265 seconds) |
| 10:32:31 | * | Hideki_ joined #nim |
| 10:33:13 | dom96 | hello hello |
| 10:37:32 | dom96 | disruptek, just because choosenim is in the path of an error doesn't mean it's to blame :P |
| 10:37:34 | * | sagax quit (Ping timeout: 265 seconds) |
| 10:39:44 | * | ng0_ is now known as ng0 |
| 10:41:18 | * | dddddd joined #nim |
| 10:41:45 | narimiran | hey dom96, did you see yesterday's pings about nim forum being noticeably slow(er) lately? |
| 10:42:46 | dom96 | narimiran, nope, link? |
| 10:42:56 | narimiran | https://forum.nim-lang.org/ :D :D |
| 10:43:25 | narimiran | it was in the offtopic channel, IIRC |
| 10:44:04 | dom96 | Don't see it in there |
| 10:44:04 | narimiran | long story short: several people (me included) noticed that the forum has been slow in the last 10 days or so |
| 10:44:59 | dom96 | Cool, it's been running for almost 3 months non-stop now |
| 10:45:43 | dom96 | It leaks itself into either slowness or a crash :D https://gist.github.com/dom96/8293bacf49026023f8213ae5a5f4144d |
| 10:46:05 | dom96 | Anyway, I restarted it |
| 10:46:09 | dom96 | Maybe that will help |
| 10:47:06 | narimiran | ok, i'll let you know if i'll still notice the slowdowns |
| 10:47:43 | narimiran | currently it feels much faster, btw |
| 10:48:01 | narimiran | oh yeah, big difference |
| 10:50:30 | * | letto quit (Quit: Konversation terminated!) |
| 10:50:35 | dom96 | great :) |
| 10:53:53 | * | filcuc joined #nim |
| 10:53:55 | * | Trustable quit (Remote host closed the connection) |
| 10:59:35 | * | filcuc quit (Read error: Connection reset by peer) |
| 10:59:49 | * | filcuc joined #nim |
| 11:04:11 | * | voltist quit (Remote host closed the connection) |
| 11:09:51 | * | filcuc quit (Quit: Konversation terminated!) |
| 11:10:09 | * | filcuc joined #nim |
| 11:12:23 | * | letto joined #nim |
| 11:12:42 | * | sagax joined #nim |
| 11:13:09 | * | nsf quit (Quit: WeeChat 2.7) |
| 11:15:01 | * | filcuc quit (Client Quit) |
| 11:15:13 | * | filcuc joined #nim |
| 11:20:11 | * | filcuc quit (Quit: Konversation terminated!) |
| 11:20:24 | * | filcuc joined #nim |
| 11:21:27 | * | Hideki_ quit (Remote host closed the connection) |
| 11:21:45 | * | Hideki_ joined #nim |
| 11:27:03 | FromGitter | <mratsim> @zedeus thanks for Verona, looks very interesting |
| 11:29:14 | * | tane quit (Quit: Leaving) |
| 11:29:15 | * | filcuc quit (Ping timeout: 240 seconds) |
| 11:36:02 | * | letto quit (Read error: Connection reset by peer) |
| 11:38:09 | * | Hideki_ quit (Remote host closed the connection) |
| 11:39:28 | * | Hideki_ joined #nim |
| 11:43:59 | * | Hideki_ quit (Ping timeout: 265 seconds) |
| 11:48:22 | Zevv | woot, down to 2324 bytes |
| 11:54:10 | dom96 | Zevv, what's that? |
| 11:56:39 | shashlick | gosh struggling to get selectRead working |
| 11:56:48 | shashlick | anyone written a select loop with SocketHandle before? |
| 11:57:07 | Zevv | dom96: getting the minimal hello world down for deep embedded systems |
| 11:57:10 | dom96 | shashlick, sure |
| 11:57:18 | Zevv | dom96: throwing out thrash |
| 11:57:45 | dom96 | Zevv, have you seen https://hookrace.net/blog/nim-binary-size/ ? |
| 11:58:15 | shashlick | dom96: I am trying to bridge a net.Socket with a libcurl socket handle |
| 11:58:27 | shashlick | I am getting correct file handle values for both |
| 11:58:44 | dom96 | shashlick, why are you trying to do this? :) |
| 11:58:50 | Zevv | dom96: sure, but this is *with* usable stdlib using --gc:arc |
| 11:59:06 | shashlick | trying to create a an http proxy with libcurl as the backend |
| 11:59:10 | shashlick | to do the auth and what not |
| 11:59:27 | dom96 | Zevv, I see. You should write an article with your experiences :) |
| 11:59:40 | Zevv | nah, I'm just PRing the stuff |
| 11:59:50 | dom96 | shashlick, why is httpclient not enough? |
| 12:00:09 | shashlick | cause i want libcurl to handle NTLM auth |
| 12:00:15 | shashlick | of an upstream proxy |
| 12:00:31 | shashlick | i already have written px in python which works well enough but am trying Nim + libcurl |
| 12:01:04 | shashlick | so please help me bridge the two sockets so that an SSL CONNECT can be bridged |
| 12:01:49 | dom96 | Okay, what's your code look like? |
| 12:03:19 | shashlick | http://ix.io/27Iq/nim |
| 12:03:24 | shashlick | line 85 onwards |
| 12:03:53 | shashlick | i have the curl handle which is talking to an upstream proxy as ssocketH and csocketH is the client connected to my http server |
| 12:04:59 | shashlick | by that point, the client is ready to initiate an SSL handshake with the end site going through my proxy as well as the upstream proxy |
| 12:06:12 | dom96 | I would suggest giving the selectors module a try |
| 12:06:29 | shashlick | i tried that first and that didn't seem intuitive |
| 12:06:32 | shashlick | plus no docs |
| 12:07:20 | shashlick | the weird thing is that selectRead tells me that the upstream proxy is ready to read from (readFds does not contain ssocketH) but at this point, the client should be sending data |
| 12:07:38 | shashlick | I end up trying to read on line 105 and it fails with -1 |
| 12:07:49 | shashlick | sz = -1 |
| 12:08:17 | shashlick | here's the curl client talking to my http server - http://ix.io/27Ir |
| 12:08:20 | dom96 | That is weird, but I doubt this API is used much |
| 12:08:25 | dom96 | It's possible it's broken |
| 12:08:29 | dom96 | Tbh I think we should deprecate it |
| 12:08:56 | dom96 | Selectors is pretty straightforward, just create a new selector, register your FDs on it, then call select |
| 12:09:22 | shashlick | ok but do I need to just register Read events or Write as well? |
| 12:09:26 | * | Hideki_ joined #nim |
| 12:09:35 | dom96 | Then you'll get precisely which FDs are readable/writeable without having to deal with selectRead's weird logic of "if it's not in the list then it's readable" which gets confusing easily |
| 12:09:37 | shashlick | cause this is bidirectional |
| 12:09:48 | dom96 | Do you want to know when the socket is writeable? |
| 12:10:09 | dom96 | note that you will get write events instantly if you're not writing a lot into the socket |
| 12:10:34 | shashlick | okay I see - so I register both sockets for both events |
| 12:10:41 | shashlick | let me try that and see what i get |
| 12:10:58 | shashlick | shouldn't have chucked my older code |
| 12:11:22 | dom96 | At that point you might even be better off using async await, https://nim-lang.org/docs/asyncnet.html#newAsyncSocket%2CAsyncFD%2CDomain%2CSockType%2CProtocol |
| 12:11:53 | shashlick | heh, that's where I started but I cannot run an async proc to write back to the client in curl's callback which isn't async |
| 12:12:10 | dom96 | Why not? |
| 12:12:22 | shashlick | for some reason, the return value gets garbled |
| 12:12:31 | shashlick | Future[cint] where it is the number of bytes written |
| 12:12:43 | FromDiscord | <Recruit_main_70007> how can i make a try connect function? |
| 12:12:44 | FromDiscord | <Recruit_main_70007> |
| 12:12:44 | FromDiscord | <Recruit_main_70007> aka, try to connect my socket, regardless of errors, and exit the function once it has connected |
| 12:12:57 | shashlick | anyway, this is working now in principal, i just want to verify that connect works, if not this is all moot |
| 12:13:00 | dom96 | shashlick, sounds like you were closer to a solution with that approach |
| 12:13:27 | shashlick | well, now HTTP works, i couldn't get that working how I wanted with async |
| 12:13:34 | shashlick | so i'm using threads for now |
| 12:14:29 | dom96 | I tend to steer away from threads if I can help it, more often than not they make things far harder to debug than they should be. |
| 12:15:54 | shashlick | i found the async stack traces impossible to figure out |
| 12:16:14 | shashlick | anway, do you have a selectors sample i can look at? |
| 12:17:05 | dom96 | httpbeast is the only one I have: https://github.com/dom96/httpbeast/blob/master/src/httpbeast.nim#L268 |
| 12:17:09 | FromDiscord | <Rika> @Recruit_main_70007 you just need a while loop and a try except with an empty except statement |
| 12:17:39 | FromDiscord | <Recruit_main_70007> ```proc try_connect*(self: Bot, add: string = "localhost", port: Port) = |
| 12:17:39 | FromDiscord | <Recruit_main_70007> while true: |
| 12:17:39 | FromDiscord | <Recruit_main_70007> try: |
| 12:17:39 | FromDiscord | <Recruit_main_70007> self.rootsocket.connect(add, port) |
| 12:17:42 | FromDiscord | <Recruit_main_70007> echo("Bot: ", self.name, " connected to server on address: localhost, on port: ", port) |
| 12:17:42 | FromDiscord | <Recruit_main_70007> except: |
| 12:17:44 | FromDiscord | <Recruit_main_70007> discard``` like this? |
| 12:17:51 | dom96 | please don't paste code into Discord, use a pastebin |
| 12:18:05 | FromDiscord | <Recruit_main_70007> sorry |
| 12:18:21 | FromDiscord | <Rika> yeah that's pretty much all you need |
| 12:18:41 | FromDiscord | <Rika> feels like you're making a discord/irc bot |
| 12:18:48 | FromDiscord | <Rika> or a chat bot in general |
| 12:18:53 | * | JustASlacker quit (Ping timeout: 258 seconds) |
| 12:18:57 | FromDiscord | <Recruit_main_70007> Rocket league one |
| 12:23:05 | * | krux02 joined #nim |
| 12:27:19 | * | Hideki_ quit (Remote host closed the connection) |
| 12:28:03 | * | Hideki_ joined #nim |
| 12:32:55 | * | Hideki_ quit (Ping timeout: 268 seconds) |
| 12:33:27 | * | Hideki_ joined #nim |
| 12:34:43 | * | Hideki_ quit (Remote host closed the connection) |
| 12:37:14 | * | Hideki_ joined #nim |
| 12:46:08 | * | Trustable joined #nim |
| 12:51:20 | shashlick | dom96: that helped, it is working now but the TLS data sent is being rejected |
| 12:51:40 | shashlick | must be cause i'm treating it as string or something |
| 12:57:08 | * | JustASlacker joined #nim |
| 13:04:50 | FromGitter | <kaushalmodi> @timotheecour Why was nimdoc.css renamed to nimdoc.out.css? https://nim-lang.github.io/Nim/nimdoc.out.css |
| 13:21:18 | * | Hideki_ quit (Remote host closed the connection) |
| 13:22:09 | * | Hideki_ joined #nim |
| 13:26:43 | * | Hideki_ quit (Ping timeout: 260 seconds) |
| 13:30:51 | * | tane joined #nim |
| 13:34:02 | FromGitter | <nothratal> hello together |
| 13:36:40 | FromGitter | <nothratal> is anyone aware of any possibilities building android apps using nim? Through ndk maybe... |
| 13:36:42 | FromGitter | <kaushalmodi> I am stumped with this error: https://github.com/nim-lang/Nim/issues/13191 |
| 13:36:44 | disbot | ➥ Running nim doc give OSError [devel regression] ; snippet at 12https://play.nim-lang.org/#ix=27IK |
| 13:37:34 | FromGitter | <kaushalmodi> I wish that OSError "Error: unhandled exception: No such file or directory [OSError]" gave more info as to which exact file or directory was not found |
| 13:40:03 | FromGitter | <kaushalmodi> I've build nim devel as usual using the same build script.. so wondering how the build could have gone wrong. Assuming my build is fine, it's even more surprising that the Nim CI passed. |
| 13:40:16 | dom96 | nothratal: its been done, look around the forum |
| 13:45:15 | * | rockcavera joined #nim |
| 13:46:55 | * | Vladar joined #nim |
| 13:57:57 | * | Hideki_ joined #nim |
| 14:08:03 | * | Ven`` joined #nim |
| 14:09:41 | * | drewr joined #nim |
| 14:13:05 | disruptek | so i have hand-written async leak-free but we cannot seem to get the macro to produce the same result. |
| 14:13:24 | disruptek | dom96: maybe you want to take a look? |
| 14:13:52 | dom96 | sure |
| 14:14:45 | * | Trustable quit (Remote host closed the connection) |
| 14:15:21 | disruptek | here's a repro: https://play.nim-lang.org/#ix=27IY |
| 14:16:35 | dom96 | do you have the original async proc as well? |
| 14:17:18 | disruptek | https://play.nim-lang.org/#ix=27J1 |
| 14:19:37 | * | dddddd quit (Ping timeout: 265 seconds) |
| 14:19:47 | * | Hideki_ quit (Ping timeout: 268 seconds) |
| 14:19:57 | * | Ven`` quit (Read error: No route to host) |
| 14:20:18 | * | akitoshi joined #nim |
| 14:20:26 | * | Ven`` joined #nim |
| 14:21:29 | dom96 | disruptek, how do you test whether the leak exists or not? |
| 14:21:44 | disruptek | i use valgrind |
| 14:23:54 | disruptek | with various machinations, i can get it down to just one leak, but luckily for us, 1 != 0. |
| 14:24:16 | * | dddddd joined #nim |
| 14:24:38 | dom96 | Here is the valgrind results for both examples: https://gist.github.com/dom96/62dd60239d84d63cf3ce861172ef47d3 |
| 14:24:57 | dom96 | not sure which metrics to look at, but both seem very similar |
| 14:25:28 | disruptek | hmm, that's useful because my results are different on linux. |
| 14:27:05 | disruptek | you're using -d:useMalloc? |
| 14:27:56 | dom96 | just --gc:arc |
| 14:28:08 | dom96 | maybe I should be using something else? |
| 14:29:09 | disruptek | you should use -d:useMalloc. |
| 14:29:28 | dom96 | just -d:useMalloc? or with --gc:arc? |
| 14:29:40 | disruptek | with arc |
| 14:29:55 | disruptek | we're trying to find leaks in arc; the default gc is fine. |
| 14:30:03 | * | ikan-keli_2 quit (Ping timeout: 240 seconds) |
| 14:30:11 | disruptek | so we'll either compare two pieces of code or two gcs. |
| 14:30:26 | disruptek | gc:orc should be leak-free on the leaky code you have. |
| 14:30:41 | disruptek | it's just arc we're trying to fix. |
| 14:30:43 | dom96 | why is -d:useMalloc necessary? |
| 14:30:51 | dom96 | anyway, it shows the leak now |
| 14:31:25 | disruptek | it simplifies the allocs according to the gc logic without any optimizations. |
| 14:32:18 | disruptek | coffee, brb |
| 14:33:53 | Zevv | disruptek: good job dude |
| 14:35:48 | Zevv | I just found an interesting problem with the useMalloc allocShared family, `allocShared` and `allocShared0` have some magic header for keeping track of the allocation size, but `reallocShared` just did a C realloc. *boom* |
| 14:36:33 | dom96 | That sounds like a big problem |
| 14:37:08 | Zevv | *if* someone would use useMalloc together with threads |
| 14:38:17 | Zevv | I've been digging through the undergrowth over the last few days, and what confuses me most is the pleora of possible paths depending on gc and memory options |
| 14:39:07 | dom96 | yeah, there is no way all these combinations are tested even a little |
| 14:39:10 | Zevv | option A does import X, but option B might do 'include Y' where something is when'ed out depending on defined(this) or something == "something" |
| 14:39:30 | Zevv | I guess its the price you pay for portability, but stuff can really need some polishing |
| 14:41:48 | * | jwm224 joined #nim |
| 14:51:10 | * | ikan-keli_ joined #nim |
| 14:52:28 | disruptek | Zevv: ray did the hard part of reducing the problem. |
| 14:53:29 | Zevv | I missed the discussion, does this require async API changes or something like that? |
| 14:55:39 | disruptek | nah. |
| 14:56:32 | Zevv | so what's the status on async+arc now? |
| 14:56:58 | disruptek | honestly? |
| 14:57:09 | disruptek | i think my solution is a hack that doesn't solve the problem. |
| 14:57:26 | Zevv | nwah |
| 14:57:33 | disruptek | but i also think we need to prove that we need a separate weakasgn before we add it. |
| 14:57:43 | * | xet7_ joined #nim |
| 14:57:48 | Zevv | no clue what that is about. |
| 14:58:02 | disruptek | copies that don't +rc. |
| 14:58:07 | Zevv | right |
| 14:58:30 | * | ptdel joined #nim |
| 15:00:07 | disruptek | i guess what i'm saying is that i think i fixed a contrived test but that real code won't work correctly. |
| 15:00:21 | disruptek | but, we don't know yet. |
| 15:01:07 | * | krux02 quit (Remote host closed the connection) |
| 15:01:30 | Zevv | and you wouldn't want to add that unless absolutely necessery |
| 15:01:43 | lqdev[m] | is there a way of passing an object between macro calls? eg. one macro generates an nnkCall that calls another macro, and that macro accepts some compile-time objects with NimNodes |
| 15:01:48 | Zevv | you should make an impementation that zaps you every time you type weakasgn() |
| 15:01:51 | lqdev[m] | :s/objects/object/ |
| 15:01:54 | disruptek | lol |
| 15:02:14 | disruptek | lqdev: macros can call compile-time procs that aren't macros. |
| 15:02:29 | disruptek | it's hard to distance what you wrote from what i wrote. |
| 15:02:42 | lqdev[m] | disruptek: not possible in my case. |
| 15:03:11 | disruptek | i think you understand this better than i do. |
| 15:03:20 | lqdev[m] | see this for example: https://github.com/liquid600pgm/euwren/blob/master/src/euwren.nim#L1010 |
| 15:03:46 | lqdev[m] | it'd be pretty easy if not for the NimNodes |
| 15:04:07 | lqdev[m] | that I want to store in an object |
| 15:04:34 | disruptek | i think you want to separate out the impl from the macro and then you can reach it easily from both pieces of code. |
| 15:05:30 | disruptek | i just don't want to add an escape hatch because i don't want anyone to use it. |
| 15:06:51 | * | xet7 quit (Quit: Leaving) |
| 15:07:44 | lqdev[m] | I wish I could do that. unfortunately, I need to have another helper macro call because I need to run another semantic pass on it |
| 15:07:59 | lqdev[m] | so not really possible to keep it in just one macro |
| 15:08:54 | Zevv | lqdev[m]: can you store it in a global {.compileTime.} var? |
| 15:10:11 | * | filcuc joined #nim |
| 15:10:44 | Zevv | I do something similar in npeg: https://github.com/zevv/npeg/blob/master/src/npeg/grammar.nim#L12 |
| 15:10:51 | lqdev[m] | Zevv: probably, but I wanted to have it in an object to avoid using global compileTime vars :) |
| 15:11:04 | Zevv | yeah, but you can't pass it around over macro's |
| 15:11:14 | Zevv | you can only pass around Nim AST |
| 15:12:47 | * | nsf joined #nim |
| 15:13:10 | * | Hideki_ joined #nim |
| 15:14:32 | * | filcuc quit (Client Quit) |
| 15:15:44 | * | ng0_ joined #nim |
| 15:16:09 | * | ng0_ is now known as n0 |
| 15:18:35 | * | filcuc joined #nim |
| 15:18:40 | * | ng0 quit (Ping timeout: 258 seconds) |
| 15:18:57 | * | n0 is now known as ng0_ |
| 15:19:21 | * | ng0_ is now known as ng0 |
| 15:23:57 | * | pbb_ quit (Remote host closed the connection) |
| 15:25:13 | * | pbb joined #nim |
| 15:29:12 | Zevv | bwah got it all working but now I broke something on 32 bit only :/ |
| 15:29:51 | * | filcuc quit (Quit: Konversation terminated!) |
| 15:32:24 | * | filcuc joined #nim |
| 15:32:59 | * | filcuc quit (Remote host closed the connection) |
| 15:33:07 | * | pbb quit (Quit: No Ping reply in 180 seconds.) |
| 15:38:35 | * | Hideki_ quit (Remote host closed the connection) |
| 15:39:39 | * | Hideki_ joined #nim |
| 15:40:18 | * | Hideki_ quit (Remote host closed the connection) |
| 15:40:31 | * | Hideki_ joined #nim |
| 15:40:42 | dom96 | disruptek, yeah, based on that code it seems like it was gutted far too much to be useable in the async macro |
| 15:40:52 | dom96 | I tried applying just the {.cursor.} pragmas but the leak is still there |
| 15:41:25 | * | filcuc joined #nim |
| 15:41:29 | disruptek | well, the first one can't work because we need futures to outlive the procs that create them. |
| 15:41:49 | * | Hideki_ quit (Remote host closed the connection) |
| 15:42:01 | disruptek | but we might be able to get away with the weak one. |
| 15:42:15 | dom96 | which is "the first one"? |
| 15:42:57 | * | Tyresc joined #nim |
| 15:42:59 | disruptek | `var resFut = newFuture...` |
| 15:43:02 | * | Hideki_ joined #nim |
| 15:43:49 | dom96 | ahh, you're referring to the {.cursor.} annotations |
| 15:44:10 | disruptek | right, i was replying to your comment. |
| 15:44:18 | dom96 | do we have any docs on these pragmas? |
| 15:45:04 | disruptek | maybe, but it's simple: cursor is a read-only view. |
| 15:45:44 | Zevv | ar_q, are you available? |
| 15:46:47 | dom96 | that's not well enforced by the compiler then |
| 15:46:59 | dom96 | since I've marked something with that pragma and it's clearly mutated |
| 15:48:01 | disruptek | no, i mean you're not supposed to rely upon it as you might a normal ref. |
| 15:49:44 | dom96 | I'm not sure what that means |
| 15:50:00 | * | Hideki_ quit (Ping timeout: 265 seconds) |
| 15:50:16 | disruptek | it cannot be sunk. |
| 15:50:31 | dom96 | This seems to have some details https://github.com/nim-lang/RFCs/issues/177 |
| 15:50:32 | disbot | ➥ Unify Nim's GC/memory management options ; snippet at 12https://play.nim-lang.org/#ix=24Ua |
| 15:51:29 | disruptek | yes, that's accurate afaik |
| 15:51:45 | disruptek | that's why i call it `weak`. |
| 15:51:52 | dom96 | it looks like {.cursor.} does nothing in the noleak sample |
| 15:51:56 | dom96 | I removed them and there is still no leak |
| 15:52:48 | dom96 | This sample has been too far stripped down, the closure iterator isn't there at all |
| 15:53:27 | disruptek | right, so this is the problem. |
| 15:54:00 | disruptek | we can't figure out how to produce a weak/cursor on the iterator. |
| 15:54:25 | disruptek | that's where you come in. 😉 |
| 15:54:37 | * | pbb joined #nim |
| 15:55:35 | dom96 | My guess is: there is no compiler support for this :P |
| 15:57:13 | disruptek | right, it's possible. |
| 15:57:55 | disruptek | the code compiles but it doesn't yield the expected behavior. |
| 16:00:55 | * | JustASlacker quit (Ping timeout: 265 seconds) |
| 16:01:01 | * | Hideki_ joined #nim |
| 16:03:44 | disruptek | i think i got it. |
| 16:04:52 | disruptek | we do async work using the cursors but we actually yield the rc'd pointers. |
| 16:05:52 | disruptek | i really don't have to work on this right now, but here's an example of what i mean: |
| 16:05:56 | disruptek | https://play.nim-lang.org/#ix=27JC |
| 16:06:03 | disruptek | ^ don't have time to work on this |
| 16:06:50 | disruptek | more succintly: https://play.nim-lang.org/#ix=27JD |
| 16:07:41 | dom96 | is it a requirement to keep re-creating each variable with {.closure.}? |
| 16:07:56 | dom96 | er, *{.cursor.} |
| 16:08:02 | dom96 | i.e. can't you just mark `future` with {.cursor.}? |
| 16:08:06 | * | Vladar quit (Quit: Leaving) |
| 16:08:22 | disruptek | no, we need the future to outlive the proc. |
| 16:09:54 | * | JustASlacker joined #nim |
| 16:10:48 | * | Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 16:11:50 | * | Hideki_ quit (Ping timeout: 268 seconds) |
| 16:11:58 | disruptek | of course, i still don't know if this will be correct. but it's still leak-free at least. |
| 16:12:20 | dom96 | https://gist.github.com/dom96/bd14faf86a426d9365a95ff49e74e74a |
| 16:12:25 | dom96 | I tried it like this |
| 16:12:26 | dom96 | still leaks |
| 16:13:17 | * | jwm224 quit (Ping timeout: 260 seconds) |
| 16:13:21 | disruptek | next.callback line has to point to the weak closureref. |
| 16:15:22 | * | jwm224 joined #nim |
| 16:15:37 | dom96 | huh? `closureRef` is already weak |
| 16:17:33 | disruptek | you're right. |
| 16:18:04 | disruptek | don't make it a let, maybe a cursor on a let isn't weak (because why should it be?) |
| 16:18:39 | disruptek | proc asyncnimproc... = ... |
| 16:18:54 | disruptek | closureref = asyncnimproc... |
| 16:19:12 | dom96 | changed `asyncProcNimAsyncContinue_404016` to be `var` |
| 16:19:14 | dom96 | still leak |
| 16:19:20 | dom96 | I'll let you try more if you wish |
| 16:19:23 | dom96 | I need to get some work done |
| 16:19:41 | disruptek | yeah, me too. |
| 16:20:39 | * | narimiran quit (Ping timeout: 268 seconds) |
| 16:25:35 | * | JustASlacker quit (Ping timeout: 268 seconds) |
| 16:29:56 | * | akitoshi quit (Quit: Connection closed for inactivity) |
| 16:32:17 | * | narimiran joined #nim |
| 16:38:37 | * | JustASlacker joined #nim |
| 16:43:05 | * | Ven`` joined #nim |
| 16:54:50 | * | filcuc quit (Ping timeout: 240 seconds) |
| 16:57:59 | dom96 | Just found this picture: FOSDEM 2018 https://i.imgur.com/jlSnHog.jpg. Can you guess who's who? :P |
| 16:58:33 | narimiran | i recognise 3 of 6 |
| 17:02:40 | dom96 | Which people are those? :) |
| 17:03:14 | Zevv | I think i've seen the middle guy on the left in a picture somewhere. And the rightmost dude seems fimiliar |
| 17:03:17 | narimiran | you, M. next to you, and A. on the right |
| 17:04:33 | dom96 | Cool. Does that mean I can write I'm famous on my resume? :P |
| 17:04:42 | Zevv | c'mon, you wrote a *book* |
| 17:06:01 | dom96 | In my experience, programming books don't bring much fame, especially ones written about a (for now at least) niche language. |
| 17:06:28 | Zevv | you should have become a rock star then I guess :) |
| 17:07:54 | dom96 | You guys coming to FOSDEM then? :) |
| 17:08:42 | Zevv | disruptek, you've been staring at arc for some time. I have a bug ending with a SIGSEGV in nimDestroyAndDispose because of funny pointers getting derefenrenced, but *only* on 32 bits. Clean valgrind run on 64 bits though. If you have any hunches, let me know |
| 17:08:59 | disruptek | gimme a repro. |
| 17:09:02 | Zevv | dom96: I will. I planned for a flash visit on sunday only, but I changed my mind and booked a room an tickets |
| 17:10:28 | Zevv | disruptek: sweet. https://github.com/zevv/Nim/tree/zevv-allocwork is the branch, https://github.com/nim-lang/Nim/pull/13190#issuecomment-575912348 is the reproduction |
| 17:10:30 | disbot | ➥ Cleanup, remove lib/system/allocators.nim. seqs_v2 and strs_v2 now uses allocShared0. |
| 17:10:31 | dom96 | Zevv, cool, I'll be coming with my girlfriend so I it's unlikely I'll be around full-time for both days, but definitely will be there for the Nim talks. |
| 17:10:56 | Zevv | dom96: and one beer, at least! |
| 17:12:45 | Zevv | disruptek: I'm not sure if I have caused the bug, or merely caused it to surface. It gets triggerd by a test that was once added to fix a similar segfault. The branch is a cleanup of some convoluted allocators and simplifies by always using plain allocs for strs_v2 and seqs_v2 for -d:useMalloc. The funny thing is that this crash does not even occur with -d:useMalloc |
| 17:12:49 | * | Hideki_ joined #nim |
| 17:13:26 | Zevv | I'll do some dining and wining now, well deserved. If you get a chance to take a peek, much obliged |
| 17:13:57 | disruptek | kk, i will look. |
| 17:14:14 | disruptek | but the fact that it doesn't occur with -d:useMalloc is telling. |
| 17:28:41 | * | letto joined #nim |
| 17:31:43 | * | JustASlacker quit (Ping timeout: 260 seconds) |
| 17:36:03 | * | Hideki_ quit (Ping timeout: 240 seconds) |
| 17:37:07 | * | natrys joined #nim |
| 17:44:28 | * | JustASlacker joined #nim |
| 17:47:05 | Zevv | telling what? |
| 17:48:45 | * | Pixeli joined #nim |
| 17:50:09 | * | Pixeli quit (Client Quit) |
| 17:50:22 | * | Pixeli joined #nim |
| 17:57:03 | * | solitudesf quit (Remote host closed the connection) |
| 17:57:21 | * | solitudesf joined #nim |
| 18:08:20 | Zevv | oh refs_v2 was also where you were poking around right |
| 18:22:08 | * | narimiran quit (Ping timeout: 268 seconds) |
| 18:22:27 | * | abm joined #nim |
| 18:23:37 | * | nsf quit (Quit: WeeChat 2.7) |
| 18:25:02 | FromDiscord | <Clyybber> Zevv: found you in a link https://www.youtube.com/watch?v=zevvyp9esIY :p |
| 18:26:08 | Zevv | wut? |
| 18:26:22 | FromDiscord | <Clyybber> look at the link 🙂 |
| 18:26:39 | Zevv | super flu - selee |
| 18:26:49 | FromDiscord | <Clyybber> the link, as in the URL |
| 18:26:54 | Zevv | oooh :) |
| 18:27:40 | Zevv | how do you even *notice* something like that |
| 18:27:45 | Zevv | that's just like, random noise |
| 18:28:03 | FromDiscord | <Clyybber> I'm always on the lookout not to get rickrolled |
| 18:28:32 | FromDiscord | <Rika> what gui library would yall recommend |
| 18:28:44 | * | abm quit (Ping timeout: 268 seconds) |
| 18:28:44 | FromDiscord | <Clyybber> imgui |
| 18:29:02 | FromDiscord | <Clyybber> or do you mean native? |
| 18:29:27 | Zevv | native is dead |
| 18:29:33 | FromDiscord | <Rika> what do you mean by native |
| 18:29:42 | FromDiscord | <Rika> ah |
| 18:29:56 | FromDiscord | <Rika> native's pretty dead yeah but its "easier" at the start |
| 18:30:23 | FromDiscord | <exelotl> Personally I've got my eyes on https://github.com/treeform/fidget |
| 18:31:58 | * | abm joined #nim |
| 18:32:00 | FromDiscord | <Rika> i do too |
| 18:33:51 | FromDiscord | <Clyybber> yeah, it looks amazing |
| 18:35:22 | * | narimiran joined #nim |
| 18:36:14 | Zevv | disruptek: minimized the trigger to http://ix.io/27Kn |
| 18:36:36 | FromDiscord | <Rika> imgui looks game-esque |
| 18:36:51 | FromDiscord | <Clyybber> yeah, its mainly for games |
| 18:36:57 | FromDiscord | <Rika> im not making a game ;; |
| 18:37:18 | FromDiscord | <Clyybber> then I'd say fidget too 🙂 |
| 18:39:14 | FromDiscord | <exelotl> I tried nigui and it's ok, but kinda missing a lot of stuff. I like iup a lot though |
| 18:40:20 | FromDiscord | <exelotl> Don't hear people talking about it much |
| 18:40:26 | FromDiscord | <Rika> iup? |
| 18:40:42 | FromDiscord | <Rika> i'm mainly looking for a lib that can work on windows and linux at lease |
| 18:40:47 | FromDiscord | <Rika> least |
| 18:42:22 | Araq | iup's major issue is the lack of OSX support |
| 18:45:03 | FromDiscord | <exelotl> Same for nigui I think (unless using gtk on osx is really OK) |
| 18:45:47 | shashlick | anyone has experience debugging TLS? |
| 18:45:50 | FromDiscord | <exelotl> My experience using gimp on my work MacBook has been rather painful though |
| 18:47:07 | Zevv | shashlick: some, but it's no fun |
| 18:47:41 | shashlick | okay so I'm working on an http proxy server that is setting up a CONNECT tunnel |
| 18:48:07 | shashlick | and am sending the remote server the TLS hello from the client but the server just disconnects |
| 18:48:41 | shashlick | actually, i'm struggling with how to recv data from a socket without knowing the length |
| 18:48:58 | shashlick | if I set my buffer too big, the recv hangs |
| 18:49:05 | Zevv | async? |
| 18:49:34 | shashlick | no regular sockets cause I couldn't use async in the callbacks |
| 18:49:37 | Araq | gtk on osx is really *not* ok IME |
| 18:50:23 | disruptek | so glad i don't need to be a part of that anymore. no disrespect. |
| 18:50:28 | shashlick | basically I'm reimplementing http://github.com/genotrance/px in Nim but using libcurl to do all the heavy lifting on the remote side |
| 18:50:54 | FromDiscord | <Recruit_main_70007> Shashlik, send a header with the message, and then recv that header number of data |
| 18:51:05 | Zevv | shashlick: for regular sockets, blocking is the expected thing |
| 18:51:16 | disruptek | i think philosophically, i'll be happier in life as a windows-denier. |
| 18:51:37 | shashlick | I started with asyncHttpServer but it didn't go too far |
| 18:51:48 | Zevv | and SSL is nasty under the hood, since a TLS recv/read might require any combination of socket writes or reads |
| 18:51:58 | shashlick | anyway, this is at the point when the connect tunnel is setup so i'm in the select loop just moving data back and forth |
| 18:52:06 | shashlick | and there's no way to know how much each socket will be sending |
| 18:52:09 | shashlick | blind mitm |
| 18:52:25 | Zevv | but you're doing the event loop stuff yourself now? |
| 18:53:08 | Zevv | because that is not trivial with tls. If your socket is indicated as writable, that might indicate that you can do a TLS read, etc |
| 18:53:33 | Zevv | OpenSSL has this api for telling you if it wants to read or write on its socket, that is all abstacted away in asyncnet |
| 18:53:54 | dom96 | yep, and it was a massive pain to fix all the major bugs it had |
| 18:54:11 | Zevv | I did that two times for other languages, and it is a pain indeed |
| 18:54:47 | shashlick | as far as I'm concerned, there is no SSL in my code |
| 18:54:55 | shashlick | the transaction is between the client and end server |
| 18:55:01 | shashlick | i'm just a dumb tunnel talking plain http |
| 18:55:12 | shashlick | created a repo - https://github.com/genotrance/px2/blob/master/curl.nim#L109 - that's where the select loop starts |
| 18:55:44 | shashlick | and by this point, it's not even http, it's just bridging the data |
| 18:56:01 | Zevv | you're doing curl multi in your own event loop? |
| 18:56:14 | Zevv | because curl also has this mechanism, it has a callback for you to tell you which fd's to watch for what events |
| 18:56:28 | FromDiscord | <Recruit_main_70007> You should, in the server, get the length of the message, send that first and then the message, in the client, receive a low amount of data, probably 2 bytes, a first time, then receive a second time that number you have received, then you have a full message |
| 18:56:36 | shashlick | effectively, but it is this way because i need to bridge the end client socket which has nothing to do with curl |
| 18:56:40 | FromDiscord | <Recruit_main_70007> Hold up, I might have a pastebin |
| 18:57:08 | shashlick | if i could include that fd in curl multi, then life will be easier yes |
| 18:57:42 | shashlick | Recruit_main_70007: like I said, this is all encrypted data between client and server, being a proxy I cannot make any sense o fit |
| 18:58:41 | shashlick | I have a similar event loop in the original python version but recv(4096) does not hang |
| 18:58:42 | shashlick | https://github.com/genotrance/px/blob/master/px.py#L900 |
| 19:00:15 | Zevv | dom96 knows a lot about the implementation, maybe you can set the underlying socket to nonblocking and hope that the layers above that handle that properly |
| 19:01:21 | shashlick | I got over the select loop thanks to his input and httpbeast code |
| 19:01:27 | shashlick | even that wasn't working in the first place |
| 19:01:51 | FromDiscord | <Rika> hello i am back |
| 19:02:00 | FromDiscord | <Rika> iup/nigui not having osx support is fine for me |
| 19:02:06 | FromDiscord | <Rika> i'm not targeting osx |
| 19:02:13 | FromDiscord | <Rika> ill look into them |
| 19:03:06 | shashlick | okay that isn't my problem right now - neither fd is ready for read after the connect |
| 19:03:31 | shashlick | let me debug further 😐 |
| 19:04:30 | FromDiscord | <Recruit_main_70007> I had this problem, but I was being sent a header... Idk, receive data 1 character at a time, and have a try each time you receive data, there is an option to make your socket wait for data for only some time, and then in except, break the loop |
| 19:04:58 | Zevv | shashlick: good luck, the pain is real |
| 19:05:00 | lqdev[m] | is there a way of specifying test dependencies in nimble? |
| 19:05:10 | FromDiscord | <Recruit_main_70007> *Some time before raising an error* |
| 19:05:14 | shashlick | at least this isn't dealing with async stack traces |
| 19:05:19 | shashlick | those are almost useless |
| 19:05:27 | shashlick | lqdev: not yet |
| 19:05:35 | shashlick | thanks Recruit, will do |
| 19:06:21 | lqdev[m] | dang it. I have a glm Vec[N, T] specific error I need to check for in euwren's test suite, but then I'd have to add it to the regular deps for everything to work fine |
| 19:09:26 | * | Cthalupa quit (Ping timeout: 258 seconds) |
| 19:11:28 | disruptek | lqdev[m]: no, there's no concept of development dependencies. |
| 19:11:42 | disruptek | !search nimph development dependencies |
| 19:12:39 | disruptek | disbot: awake? |
| 19:12:39 | disbot | yep. 😊 |
| 19:17:03 | * | solitudesf- joined #nim |
| 19:18:38 | * | solitudesf quit (Ping timeout: 258 seconds) |
| 19:19:55 | Zevv | Araq: you got a minute? I could use some hints |
| 19:22:15 | FromDiscord | <Rika> is the iup wrapper maintained? |
| 19:23:40 | Zevv | I get an arc crash that only manifests on i386 and goes away with -d:useMalloc. |
| 19:24:13 | Zevv | The problem is that the bug is in my own Nim branch. It is the only test case that breaks, and I'm not sure if I caused the bug or that it just happens to popup now |
| 19:25:09 | * | Ven`` quit (Ping timeout: 258 seconds) |
| 19:26:02 | * | Ven`` joined #nim |
| 19:33:18 | * | Hideki_ joined #nim |
| 19:36:50 | * | xet7_ quit (Quit: Leaving) |
| 19:37:19 | * | xet7 joined #nim |
| 19:37:59 | * | Hideki_ quit (Ping timeout: 268 seconds) |
| 19:39:56 | lqdev[m] | how do I check if a sym is `typedesc`? not asking for `typeDesc[T]` or any of that crap, just for *literal* `typedesc`. `sym.typeKind == ntyTypeDesc` won't work because it'll also catch `typeDesc[T]`, `sym == bindSym"typedesc"` also doesn't work for some reason |
| 19:41:23 | lqdev[m] | `sym == sym.getTypeInst` seems to work, though I'm afraid it might break at some point |
| 19:41:50 | lqdev[m] | taking that last statement back, no it doesn't work |
| 19:43:36 | lqdev[m] | right now my only idea would be to check if `sym.repr == "typedesc"`, but it's probably horrible af |
| 19:49:22 | * | Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 19:53:30 | FromDiscord | <Clyybber> why do you not want to catch typedesc[T] too? |
| 19:54:17 | FromDiscord | <exelotl> is there a way to mark a variable as write-only? |
| 19:54:18 | * | kungtotte quit (Read error: Connection reset by peer) |
| 19:54:31 | FromDiscord | <Rika> exelotl what do you mean |
| 19:55:16 | FromDiscord | <exelotl> you can do `foo = 10`, but not `let a = foo` or `echo foo` |
| 19:55:22 | * | kungtotte joined #nim |
| 19:55:35 | FromDiscord | <Rika> w-why |
| 19:55:46 | FromDiscord | <exelotl> hehehe |
| 19:55:51 | FromDiscord | <Rika> i legitimately fail to see the reasons to do so |
| 19:56:45 | Yardanico | uhh, how can I debug an OOM crash? :D |
| 19:56:57 | Yardanico | valgrind? |
| 19:58:40 | FromDiscord | <exelotl> it's a "variable" imported from C, to access a memory-mapped IO register on the GBA |
| 19:58:55 | FromDiscord | <exelotl> `#define REG_BG0HOFS *(vu16*)(REG_BASE+0x0010) // Bg0 horizontal scroll` |
| 19:59:23 | FromDiscord | <Clyybber> so if its a register why disallow reading from it? |
| 19:59:31 | FromDiscord | <exelotl> afaik the hardware enforces that it's write only |
| 19:59:43 | FromDiscord | <Clyybber> oh |
| 19:59:59 | FromDiscord | <Rika> make it a function then |
| 20:00:46 | Yardanico | or an object with a function so you can have dot access without () :P |
| 20:01:15 | FromDiscord | <mfiano> Is vmath the go-to library for game linear algebra? |
| 20:01:26 | FromDiscord | <Rika> or a hacky macro |
| 20:01:54 | FromDiscord | <Clyybber> @mfiano never heard of it |
| 20:01:56 | Yardanico | [Heap] string: #2365; bytes: 58943474881 |
| 20:01:57 | Yardanico | jesus |
| 20:01:57 | FromDiscord | <Clyybber> !repo vmath |
| 20:01:58 | disbot | https://github.com/nim-lang/Nim/issues/2365 -- 5Can't access argument in proc from stmt passed in to a template ; snippet at 12https://play.nim-lang.org/#ix=27LM |
| 20:01:59 | disbot | https://github.com/treeform/vmath -- 9vmath: 11Math vector library for graphical things. 15 3⭐ 0🍴 |
| 20:02:11 | FromDiscord | <exelotl> I've used vmath and it's good, I like it |
| 20:02:43 | FromDiscord | <Clyybber> @mfiano hehe, if its made by treeform I guess so |
| 20:02:48 | FromDiscord | <mfiano> I'm particularly looking for something with support for both quaternions and dual quaternions. Looks like I'll have to reinvent the wheel here |
| 20:02:49 | FromDiscord | <exelotl> "glm" seems to be more popular though |
| 20:03:18 | FromDiscord | <exelotl> but I prefer vmath because there's less magic going on under the hood |
| 20:03:45 | FromDiscord | <exelotl> I can read the source without having to enter galaxy brain mode |
| 20:09:09 | * | luis_ joined #nim |
| 20:10:55 | * | Ven`` joined #nim |
| 20:15:25 | * | JustASlacker quit (Ping timeout: 268 seconds) |
| 20:18:26 | * | luis_ quit (Remote host closed the connection) |
| 20:19:13 | * | luis_ joined #nim |
| 20:19:14 | * | Pixeli quit (Read error: Connection reset by peer) |
| 20:19:18 | Yardanico | uhh |
| 20:19:29 | Yardanico | "items" should be okay for iterating over an enum, right? |
| 20:19:41 | Yardanico | seems like it's broken for enums with holes |
| 20:20:30 | Yardanico | https://play.nim-lang.org/#ix=27LT that code executes forever on runtime |
| 20:21:00 | Yardanico | ah I see why, probably coz there are too many values to iterate over |
| 20:23:40 | disruptek | forever is a pretty long runtime. |
| 20:23:46 | Yardanico | well I didn't run it forever |
| 20:23:50 | Yardanico | sadly I don't have such possibilities |
| 20:24:25 | disruptek | i almost ran something for forever. |
| 20:25:00 | FromDiscord | <mfiano> Can someone explain ref types to me as a newbie? |
| 20:25:23 | Yardanico | "ref object" is a managed (by GC) pointer to an object |
| 20:25:26 | FromDiscord | <mfiano> i see `Ref object of foo` and `Ref foo` a lot. No clue what's going on |
| 20:25:41 | Yardanico | so you can pass it between procedures and modify, and modifications will be available everywhere |
| 20:25:57 | Yardanico | if you have "object", you'd have to use "var YourType" in prodecures to pass your object as a reference |
| 20:26:03 | Yardanico | to be able to modify it from other procedures |
| 20:26:11 | * | nsf joined #nim |
| 20:26:14 | disruptek | also, a ref is a managed pointer that points to heap memory. |
| 20:26:25 | Yardanico | https://forum.nim-lang.org/t/1207 has some info about that |
| 20:27:12 | FromDiscord | <mfiano> If I was writing a math library with say a vec3 type and I wanted to write 2 procs for each operation, one that allocates a new result, and one that mutates an existing vec3, how would i do that? |
| 20:28:25 | Yardanico | well, vectors are usually "object" I guess, so you will need to define procs to modify vectors inplace as proc modify(myvec: var vec3) = stuff |
| 20:28:40 | Yardanico | and new result as proc modify(myvec: vec3): vec3 = stuff |
| 20:30:02 | FromDiscord | <mfiano> Ah so i dont use a ref type, ok |
| 20:34:16 | FromDiscord | <mfiano> Does Nim have arity overloading? |
| 20:34:26 | FromDiscord | <mfiano> Or would I need 2 names for those 2 ops? |
| 20:34:29 | Yardanico | what's that? |
| 20:34:40 | FromDiscord | <mfiano> Same function, different number of arguments |
| 20:34:43 | Yardanico | yes, you can |
| 20:34:46 | FromDiscord | <mfiano> Same function name, different number of arguments |
| 20:35:54 | * | luis_ quit (Quit: luis_) |
| 20:36:40 | FromDiscord | <Rika> ah man why is the hardest part of setting up a project thinking of the name of the project |
| 20:36:50 | FromDiscord | <Rika> i need a name then i can start with programming |
| 20:37:58 | solitudesf- | https://nim-lang.org/docs/tut1.html |
| 20:38:03 | * | solitudesf- quit (Quit: Leaving) |
| 20:38:19 | * | solitudesf joined #nim |
| 20:38:51 | solitudesf | ~tutorial is intro to sacred manuscripts: https://nim-lang.org/docs/tut1.html |
| 20:38:52 | disbot | tutorial: 11intro to sacred manuscripts: https://nim-lang.org/docs/tut1.html |
| 20:43:29 | FromDiscord | <mfiano> Can someone explain to me where the precision error is coming from here, since I'm not accumulating anything? https://gist.github.com/mfiano/3c724bf2aab2e75e5dd1118f6391b044 |
| 20:43:41 | Yardanico | that's how floats are represented in hardware |
| 20:43:49 | Yardanico | https://0.30000000000000004.com/ |
| 20:47:00 | * | Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 20:47:48 | Zevv | well, well, that is one *nasty* bug |
| 20:47:55 | FromDiscord | <mfiano> Odd. I can't reproduce that in any other language |
| 20:48:04 | FromDiscord | <mfiano> Only when accumulating values |
| 20:48:07 | Yardanico | @mfiano are you sure? |
| 20:48:18 | Yardanico | maybe your language just converts the string representation to a shorter value |
| 20:48:20 | Zevv | low level realloc allocates 16 bytes blocks when you alloc smaller, and when reallocing bigger it does not memzero the remaining bytes up to 16 |
| 20:48:30 | FromDiscord | <mfiano> Yes. In Common Lisp, Python, and a couple others I just tried. 4.2 is self-referential |
| 20:48:52 | Yardanico | and btw, "f32" is useless |
| 20:48:57 | Yardanico | it's mapped to float64 in nim anyway :) |
| 20:49:27 | FromDiscord | <mfiano> Scientific: 4.2e+0, Decoded: 1.0 * 0.525 * 2^3, Digits: 24, Precision: 24 |
| 20:49:37 | disruptek | Zevv: is that true? |
| 20:49:58 | Zevv | disruptek: https://play.nim-lang.org/#ix=27LZ |
| 20:49:59 | disruptek | looking forward to looking at your code. |
| 20:50:04 | FromDiscord | <mfiano> How can I ensure 32 bit floats then? |
| 20:50:12 | Zevv | let me annotate that and sen da new link, one moment |
| 20:50:25 | Yardanico | @mfiano why would you need to though? |
| 20:50:27 | disruptek | i can read it |
| 20:50:30 | Yardanico | short answer - just don't :P |
| 20:50:42 | disruptek | so this is very interesting. |
| 20:51:06 | FromDiscord | <mfiano> Because when passed as a uniform to GLSL it should be 32 bit. Khronos points out the double precision floats are a real performance trap on the GPU |
| 20:51:32 | Zevv | disruptek: https://play.nim-lang.org/#ix=27M1 |
| 20:51:36 | Zevv | This was pretty nasty |
| 20:52:35 | Yardanico | @mfiano well, i don't really do graphical programming in nim, but I think that it's not really an issue, although I can't really answer |
| 20:53:00 | FromDiscord | <mfiano> IT most certainly is in the type of work I do. doubles are slow for the work I do on the GPU |
| 20:53:03 | FromDiscord | <mfiano> It most certainly is in the type of work I do. doubles are slow for the work I do on the GPU |
| 20:53:14 | Yardanico | btw, your messages are sent yet again when you edit your message ;) |
| 20:53:15 | krux02__ | Zevv, does 'realloc' really zero the memory, because I doubt it does. |
| 20:53:28 | FromDiscord | <mfiano> and casting every shader operation because the inputs are doubles is probably slower |
| 20:54:49 | krux02__ | As far as I know, NVIDIA Gpus are artificially slowed down on double precision, because they can charge extra money for that. |
| 20:55:36 | FromDiscord | <mfiano> > GL_DOUBLE: A 64-bit double-precision floating-point value. Never use this. It's technically legal, but almost certainly a performance trap. Equivalent to GLdouble. |
| 20:55:46 | FromDiscord | <mfiano> That's a quote from Khronos |
| 20:56:02 | Yardanico | well, as I said, people have been making games in nim, even 3D ones, and I think they all solved it somehow |
| 20:57:00 | FromDiscord | <mfiano> Heh, even half floats are common for some buffer types |
| 20:58:26 | Yardanico | you can ask on the forum, more people visit it over the days than watch the real time chat :) |
| 21:00:04 | FromDiscord | <Zachary Carter> I use 32 bit floating point values in Nim all the time |
| 21:00:24 | FromDiscord | <Zachary Carter> specifically when writing code for graphics programming |
| 21:00:49 | FromDiscord | <Zachary Carter> and not doubles |
| 21:01:09 | FromDiscord | <Zachary Carter> so I'm not sure what you're referring to Yardanico |
| 21:01:21 | Yardanico | well, even from system.nim |
| 21:01:22 | Yardanico | "# 'float64' is now an alias to 'float'; this solves many problems" |
| 21:01:32 | Yardanico | hmm wait xd |
| 21:01:35 | FromDiscord | <Zachary Carter> yeah |
| 21:01:36 | FromDiscord | <mfiano> Umm |
| 21:01:39 | FromDiscord | <Clyybber> yes, but float32 is still 32 bit |
| 21:01:42 | FromDiscord | <Zachary Carter> that's if you' dont specify `float32` |
| 21:01:43 | Yardanico | oh |
| 21:01:46 | FromDiscord | <Zachary Carter> float32 is definitely 32 bits |
| 21:01:54 | FromDiscord | <Clyybber> only in the VM we use float64 for everything |
| 21:02:00 | FromDiscord | <mfiano> whew 😅 |
| 21:02:12 | Yardanico | then I misread that line as "float32 is float" or something like that |
| 21:02:14 | Yardanico | sorry :) |
| 21:02:20 | solitudesf | @mfiano thats just how its presented on output, you can just look at the memory |
| 21:12:06 | * | narimiran quit (Ping timeout: 258 seconds) |
| 21:14:54 | * | Ven`` joined #nim |
| 21:14:59 | FromDiscord | <Zachary Carter> https://play.nim-lang.org/#ix=27Ma |
| 21:15:11 | FromDiscord | <Zachary Carter> anyone know why I'm getting: `/usercode/in.nim(38, 1) Error: cannot instantiate: 'path[Spaceship, tuple[x, y: int], float]'` |
| 21:15:12 | FromDiscord | <Zachary Carter> ? |
| 21:23:49 | * | abm quit (Quit: Leaving) |
| 21:25:26 | * | filcuc joined #nim |
| 21:25:43 | * | jjido joined #nim |
| 21:26:41 | * | natrys quit (Quit: natrys) |
| 21:28:31 | FromDiscord | <DeltaPHC> Don't know the answer there, but are `concept`s considered stable enough to use? They're considered an experimental feature at the moment |
| 21:30:50 | dom96 | I still personally avoid them and would recommend for others to do the same. We are still likely to get some new syntax/semantics for them AFAIK |
| 21:35:10 | FromDiscord | <DeltaPHC> They *look* really useful, just that the syntax looks a tad obtuse. Maybe that's just me |
| 21:37:48 | * | Jesin quit (Quit: Leaving) |
| 21:43:38 | FromGitter | <nothratal> good evening |
| 21:44:01 | * | Jesin joined #nim |
| 21:45:57 | FromDiscord | <Avatarfighter> Hello everyone ! |
| 21:46:04 | FromGitter | <nothratal> is there a way to tell the compiler to search the whole source file for procs and not starting at the line number of the occurrence? Do you get what I mean? |
| 21:46:23 | Yardanico | sounds like you need a forward declaration or enable reodering? |
| 21:46:25 | Yardanico | *reordering |
| 21:46:56 | Yardanico | try with {.reorder: on.} at the top of the file |
| 21:47:23 | Yardanico | if it still errors, you'll need to make a forward declaration (basically only the signature of the procedure without it's definition, so the compiler will know that such procedure exists) |
| 21:48:45 | FromGitter | <nothratal> @Yardanico Thank you! That's exactly what I meant |
| 21:48:59 | FromGitter | <nothratal> reorder...didn't think of this word |
| 21:49:22 | Yardanico | well, it won't work if you have a recursive dependency (first proc depends on second proc, and second proc depends on the first proc) |
| 21:49:28 | Yardanico | in that case you'll need forward declarations anyway |
| 21:49:36 | FromGitter | <nothratal> by the way, compiler tells me it's deprecated, please use: ⏎ ```{.experimental: "codeReordering".}``` |
| 21:49:42 | FromGitter | <nothratal> but does the same |
| 21:49:43 | Yardanico | well yeah, do that :) |
| 21:49:49 | Yardanico | it's an experimental feature after all |
| 21:50:05 | FromGitter | <nothratal> @Yardanico good to know! Still learning a lot. |
| 21:50:47 | FromDiscord | <Avatarfighter> Is there a way to allow a proc to potentially return different types based on the input ? |
| 21:51:10 | Yardanico | yes, it's basically same as generic types, lemme show you |
| 21:51:41 | Yardanico | although be aware that the code which checks which type should be used as return value should be compile-time |
| 21:52:06 | Yardanico | you can't return "string" if your proc receives "hello" at runtime, and "int" if it receives "5" |
| 21:52:25 | Yardanico | since nim is not dynamically typed :) |
| 21:52:30 | FromDiscord | <Avatarfighter> yeah 🙂 |
| 21:52:37 | FromDiscord | <Avatarfighter> I guess I'm trying to do the impossible atm |
| 21:52:42 | * | jholland__ quit (Quit: Connection closed for inactivity) |
| 21:52:46 | Yardanico | what are you trying to do though? |
| 21:54:13 | FromDiscord | <Avatarfighter> I was trying to grab the value of a key from a Table but the value of the key is a type that could have an int/string/Table/seq and I wanted to return the type that the value of the key is holding. I hope that makes sense lol |
| 21:54:19 | FromDiscord | <Avatarfighter> I'll send code if it doesnt |
| 21:54:37 | Yardanico | pls send it as a paste though, not in discord, because it'll look ugly in IRC otherwise :) |
| 21:54:49 | FromDiscord | <Avatarfighter> Yeah of course 🙂 |
| 21:55:11 | Yardanico | @Avatarfighter for your task you might be able to use object variants |
| 21:55:20 | FromDiscord | <Rika> tables can only hold one type as value though |
| 21:55:27 | Yardanico | yes, so you can use object variants |
| 21:57:01 | FromDiscord | <Avatarfighter> variants? |
| 21:57:06 | FromDiscord | <Avatarfighter> Never heard of those lol |
| 21:57:13 | Yardanico | https://nim-lang.org/docs/manual.html#types-object-variants |
| 21:57:19 | Yardanico | i'll try to make an example with tables now |
| 21:57:24 | FromDiscord | <Avatarfighter> here is what my code looks like in case you're interested, I removed parts |
| 21:57:25 | FromDiscord | <Avatarfighter> https://dsh.re/13690 |
| 21:57:43 | FromDiscord | <Avatarfighter> Ohh I'm using Variants lmao |
| 21:57:47 | Yardanico | yes you are xD |
| 21:57:50 | FromDiscord | <mfiano> So about that gist, if someone can explain to me what is going on. Particularly, why a f32 is being printed with the precision of a double float, and only when it's in a type? |
| 21:57:52 | FromDiscord | <Rika> https://play.nim-lang.org/#ix=27Mv something like this |
| 21:58:02 | FromDiscord | <Rika> oh |
| 21:58:03 | Yardanico | well, I see what you mean, you can't do that sadly |
| 21:58:04 | FromDiscord | <Rika> i am late |
| 21:58:13 | Yardanico | you might have to pass that object into your other objects |
| 21:58:41 | FromDiscord | <Avatarfighter> Yeah I assumed I couldn't but that's fine 😛 I was just looking to optimize my code by like two characters |
| 21:58:54 | Yardanico | also btw, a small enhacement |
| 21:59:19 | Yardanico | ah nvm, it won't work here anyway, but just in case, for your future code |
| 21:59:38 | Yardanico | https://play.nim-lang.org/#ix=27My |
| 21:59:57 | Yardanico | if all branches in "case" return value of the same type (and that case covers all possible branches), you can do this |
| 22:00:01 | Yardanico | assign it to a variable |
| 22:00:12 | FromDiscord | <Avatarfighter> oh whaaaat |
| 22:00:25 | FromDiscord | <Avatarfighter> I didn't even realize you could do that |
| 22:00:29 | Yardanico | and if one of your branches throws an error, it'll still work, because the compiler knows that after exception there's no chance of survival :P |
| 22:00:35 | FromDiscord | <Avatarfighter> wow |
| 22:00:42 | FromDiscord | <Avatarfighter> That's really cool |
| 22:00:45 | FromDiscord | <Avatarfighter> The more you know 😛 |
| 22:01:01 | Yardanico | https://nim-lang.org/docs/manual.html#statements-and-expressions-case-expression |
| 22:01:07 | Yardanico | its all documented in the manual :) |
| 22:01:21 | FromDiscord | <Rika> i should sleep |
| 22:01:26 | FromDiscord | <mfiano> I just don't understand how I can have 2 printed representations of the same number, with one of them using the precision of the wrong float type: https://play.nim-lang.org/#ix=27Mz |
| 22:01:43 | FromDiscord | <Avatarfighter> Oh uh I definitely haven't actually read the manual, I've been learning via the search index lol |
| 22:01:55 | FromDiscord | <Rika> you should read the manua |
| 22:02:02 | Yardanico | you'll find a looot of features in the manual |
| 22:02:05 | FromDiscord | <Avatarfighter> I probably should lol |
| 22:02:47 | FromDiscord | <Rika> @mfiano https://play.nim-lang.org/#ix=27MA look at this |
| 22:03:24 | FromDiscord | <Rika> aka: it's probably the compiler noticing that you're echoing a literal, so it's just straight up not using a float |
| 22:03:32 | FromDiscord | <Rika> or something so |
| 22:04:37 | * | filcuc quit (Ping timeout: 258 seconds) |
| 22:05:25 | * | nsf quit (Quit: WeeChat 2.7) |
| 22:05:38 | * | SenasOzys joined #nim |
| 22:08:24 | * | filcuc joined #nim |
| 22:24:23 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 22:32:47 | * | jjido joined #nim |
| 22:40:04 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 22:40:31 | FromDiscord | <mfiano> How would I make a type that defines positional argument constructors instead of varargs? |
| 22:41:57 | FromDiscord | <Clyybber> WDYM? |
| 22:43:16 | FromDiscord | <mfiano> Well in my above play link, is it possible to prevent Vec2(x: 1, y: 2), and have a constructor such as Vec2(1, 2)? |
| 22:43:28 | disruptek | proc run(foo: Bar; bif: Zap): Results = ... |
| 22:43:48 | FromDiscord | <mfiano> I want to prevent the type from generating such a constructor |
| 22:44:05 | disruptek | no, you can make a factory function and keep the type private, though. |
| 22:44:13 | FromDiscord | <mfiano> I see. thanks |
| 22:44:41 | disruptek | i could be wrong about that, but i don't think so. |
| 22:46:06 | * | tane quit (Quit: Leaving) |
| 22:46:19 | FromDiscord | <mratsim> proc initVec2(x, y: int): Vec2 = result.x = x; result.y = y |
| 22:46:31 | FromDiscord | <Clyybber> @mratsim Hey, btw whats the reason not to use UFCS in weave? |
| 22:46:39 | FromDiscord | <Clyybber> I'm referring to the last commit/PR |
| 22:46:51 | disruptek | probably template. |
| 22:46:56 | FromDiscord | <mratsim> because UFCS is broken in templates |
| 22:47:14 | FromDiscord | <Clyybber> oh, is there an open issue? |
| 22:47:22 | FromDiscord | <mratsim> @Vindaar managed to trigger some undeclared identifier bug |
| 22:47:24 | disruptek | it is known. |
| 22:47:30 | FromDiscord | <mratsim> it is known |
| 22:47:31 | disruptek | it's in the manual. |
| 22:47:37 | FromDiscord | <Clyybber> ah, right |
| 22:48:00 | * | marmotini_ joined #nim |
| 22:48:34 | FromDiscord | <mratsim> btw I think Weave is pretty much feature complete now |
| 22:49:11 | FromDiscord | <mratsim> well apart from distributed computing and distributing work to GPUs |
| 22:49:18 | disruptek | nice. |
| 22:49:56 | disruptek | time to write something amazing that brings together all this stuff. |
| 22:49:58 | FromGitter | <zetashift> that's really great to hear |
| 22:50:46 | FromDiscord | <mratsim> a ML compiler backed by Weave 😉 |
| 22:51:29 | disruptek | it would definitely turn some serious heads. |
| 22:52:40 | * | marmotini_ quit (Ping timeout: 268 seconds) |
| 22:52:57 | FromDiscord | <mfiano> Man I love Nim so far. It's just so concise and does what I want in little code without bending over backwards |
| 22:54:18 | * | filcuc quit (Ping timeout: 260 seconds) |
| 22:55:16 | disruptek | can't wait to see what macros you cook up. |
| 22:56:10 | * | SenasOzys quit (Read error: Connection reset by peer) |
| 22:56:23 | FromDiscord | <mfiano> Is there a naming convention for a proc that mutates one of its arguments? |
| 22:56:38 | disruptek | m/something/ |
| 22:57:13 | disruptek | actually, that returns a var, usually. |
| 22:58:06 | ptdel | anybody know of any docs or anything around generating random string? for some reason my proc results in the same string each time it's called in rosencrantz :) |
| 22:58:08 | FromDiscord | <mfiano> Ah a prefix won't do here. I can see lots of ambiguities arising and careful api design. I would prefer a suffix |
| 22:59:16 | disruptek | i dunno, but there's a section in the manual about naming conventions. |
| 22:59:17 | FromDiscord | <mratsim> @ptdel are you perhaps calling randomize(seed) before each random function call? |
| 22:59:51 | FromDiscord | <mratsim> no convention @mfiano |
| 22:59:53 | ptdel | @mratsim I have randomize() being called inside the proc, but i'm not sure how to go about making a new seed for it each time |
| 23:00:35 | FromDiscord | <mratsim> I use mfoo when I have both an in-place and an out-of-place unary function |
| 23:00:45 | FromDiscord | <mratsim> the std/algorithm use -ed |
| 23:00:52 | FromDiscord | <mratsim> shuffle shuffled, reverse reversed |
| 23:01:07 | FromDiscord | <mratsim> shuffle is the in-place, shuffled is the out-of-place |
| 23:01:19 | FromDiscord | <mratsim> for non-unary there is no convention though |
| 23:01:46 | FromDiscord | <mfiano> Currently I have a function with nullary, unary, and binary sigs to allocate a fresh vec2 object, but i also want to have versions that modify a vector in place. |
| 23:02:07 | FromDiscord | <mratsim> you can reuse the name if you want |
| 23:02:19 | FromDiscord | <mratsim> Nim accepts overloads of var and non var |
| 23:02:23 | disruptek | change(foo), changed(foo) |
| 23:02:31 | FromDiscord | <mfiano> I'm not sure how i'd do that without introducing an ambiguity. |
| 23:02:46 | disruptek | well, one is var and one is not. |
| 23:02:48 | FromDiscord | <mfiano> https://gist.github.com/mfiano/3c724bf2aab2e75e5dd1118f6391b044 |
| 23:02:51 | disruptek | it's not really ambiguous. |
| 23:02:57 | dom96 | ptdel: call `randomize` only once |
| 23:03:23 | FromDiscord | <mratsim> proc `[]`(myCollection: MyCollection, i: int) is different vrom proc `[]`(myCollection var MyCollection, i: int) |
| 23:03:32 | FromDiscord | <mfiano> So for the first one, for example, I'd like a proc that zeroes out an existing vector, so it'd be unary too. not sure what the sig would look like |
| 23:03:38 | FromDiscord | <mratsim> one is only called on var parameters and the other on let parameters |
| 23:03:59 | ptdel | I think I need to figure out why the value i randomly generate persists between requests in rosencrantz that might be my real problem |
| 23:04:00 | FromDiscord | <mratsim> for zeroing a stack type just call reset() |
| 23:04:14 | ptdel | when i generate random values in other contexts it seems to make new values each time |
| 23:04:24 | FromDiscord | <mratsim> and the out-of-place "zeroes" |
| 23:04:37 | FromDiscord | <mratsim> or "zeros", never sure of the plural |
| 23:04:55 | FromDiscord | <mfiano> and likewise for the second one, it should take a vector and a single number that mutates both of the input vector places with that number |
| 23:04:59 | FromDiscord | <mfiano> etc |
| 23:05:16 | FromDiscord | <mratsim> otherwise in numerical computing the convention is setZero for in-place and zeros for out-of-place |
| 23:06:07 | FromDiscord | <mratsim> and for mutating a vector proc `[]=`(vec: var Vec2, val: int) |
| 23:07:51 | FromDiscord | <mfiano> what is []= ? |
| 23:08:04 | ptdel | solved my problem thanks for the pointers :) |
| 23:08:58 | FromDiscord | <Clyybber> @mfiano Its invoked when you do `a[...] = ...` |
| 23:11:05 | FromDiscord | <mfiano> I'm not sure what that is yet |
| 23:11:16 | FromDiscord | <mfiano> I'll read the manual again |
| 23:11:18 | disruptek | it's a chef. |
| 23:11:22 | FromDiscord | <Clyybber> array indexing |
| 23:11:26 | disruptek | []= |
| 23:11:39 | FromDiscord | <Clyybber> disruptek: lol |
| 23:13:06 | * | arecaceae quit (Remote host closed the connection) |
| 23:13:24 | * | arecaceae joined #nim |
| 23:15:10 | FromDiscord | <mfiano> Can you provide an example of that proc? |
| 23:15:32 | * | solitudesf quit (Ping timeout: 258 seconds) |
| 23:15:32 | * | Ven`` quit (Read error: Connection reset by peer) |
| 23:15:37 | disruptek | you can see them in the tables module. |
| 23:15:48 | disruptek | too many chefs, if you ask me. |
| 23:16:06 | disruptek | i hate to see pot spoiled. |
| 23:19:28 | FromDiscord | <mfiano> i guess i would like a named proc anyway, to have a consistent interface for mutating any number of members |
| 23:19:38 | FromDiscord | <mfiano> so looking for the proper way to do that |
| 23:24:15 | FromDiscord | <mratsim> @mfiano: https://github.com/numforge/laser/blob/master/benchmarks/loop_iteration/tensor.nim#L70-L72 |
| 23:24:30 | * | krux02__ quit (Remote host closed the connection) |
| 23:24:52 | FromDiscord | <mratsim> this allows the notation myTensor[index] = value |
| 23:25:03 | FromDiscord | <mratsim> i.e. overloading array indexing |
| 23:25:29 | FromDiscord | <mratsim> and you can overload multidimensional arrays to have myMatrix[i, j] = value |
| 23:26:40 | FromDiscord | <mfiano> But what if I want to change just the 0th and 2nd index with a consistent interface as everything else, without leaking the array implementation details? |
| 23:28:01 | FromDiscord | <mratsim> either people call []= twice or you provide a proc called for example indexMut |
| 23:29:08 | FromDiscord | <mratsim> proc indexMut[N: static int, T](v: Vec2[T], indexes: array[N, int], values: array[N, T]) = |
| 23:29:31 | FromDiscord | <mfiano> Yeah I'm not quite to the point of parameterized types yet. I literally just wrote my first lines of Nim |
| 23:29:32 | FromDiscord | <mratsim> and it's called v.indexMut([0, 2], [val0, val2]) |
| 23:29:41 | * | FromGitter quit (Read error: Connection reset by peer) |
| 23:29:59 | * | FromGitter joined #nim |
| 23:30:10 | FromDiscord | <mratsim> my first lines of Nim where writing vec and matrix types 3 years ago 😉 |
| 23:30:37 | FromDiscord | <mfiano> I'm not very familiar with the type system yet. Coming from a language without parametric types 🙂 |
| 23:30:49 | FromDiscord | <mratsim> I was not a dev before |
| 23:31:15 | FromDiscord | <mratsim> I did dabble in Haskell and Rust before but it was mostly curiosity |
| 23:31:23 | FromDiscord | <mratsim> (not counting bash and Python) |
| 23:31:54 | FromDiscord | <mfiano> I see. Just about 20 years of Lisp for me |
| 23:32:33 | FromDiscord | <mratsim> proTip, if you start writing macro, you can display the AST in lisp mode with lispRepr |
| 23:32:43 | FromDiscord | <mfiano> Cool |
| 23:33:01 | FromDiscord | <mratsim> but don't start too fast :p |
| 23:34:01 | FromDiscord | <mfiano> Yeah I'm not going to be doing macros any time soon. Starting how I learned Lisp, with my own math library, which I don't expect to be very macro heavy if at all |
| 23:34:32 | * | lritter joined #nim |
| 23:40:07 | FromDiscord | <mfiano> If I use a parameterized type to define an N-length vector, how would I write different procs dependent on the length? |
| 23:42:14 | FromDiscord | <mratsim> proc foo[N: static int; T](v: vec[N, T]) |
| 23:42:25 | FromDiscord | <mratsim> or proc foo(v: Vec) |
| 23:42:40 | FromDiscord | <mratsim> and access N and T via v.N and v.T |
| 23:42:46 | * | FromGitter quit (Read error: Connection reset by peer) |
| 23:42:55 | FromDiscord | <mratsim> (this assusmes that they are called N and T in the type definition) |
| 23:43:05 | * | FromGitter joined #nim |
| 23:43:12 | FromDiscord | <mratsim> i.e. type Vec[N: static int; T] = object |
| 23:43:18 | FromDiscord | <mfiano> I see. Is there a convention for type parameter names? |
| 23:43:57 | FromDiscord | <mratsim> T for types, N for integers |
| 23:44:11 | FromDiscord | <mratsim> T, U, V if you need more |
| 23:44:21 | FromDiscord | <mratsim> and M, N if you need more integers |
| 23:44:59 | FromDiscord | <mratsim> I suggest you have a look in the old unicredit linalg repo, that's basically where I learned to use static and generics: https://github.com/unicredit/linear-algebra/blob/master/linalg/private/types.nim |
| 23:45:11 | FromDiscord | <mratsim> well that + opening 50+ bugs 3 years ago |
| 23:45:41 | FromDiscord | <mfiano> Thanks will do |
| 23:47:31 | FromDiscord | <mratsim> also if you want some code reviews don't hesitate to share a link of your repo in the forum, potentially you can open issues in your own tracker for things you are stuck with |
| 23:48:14 | FromDiscord | <mratsim> there are plenty of people that are using Nim for math/science/graphics writing their own matrix/vector libraries |
| 23:48:45 | FromDiscord | <mfiano> Thanks a lot |
| 23:48:47 | FromDiscord | <mratsim> going to sleep, see you |
| 23:48:51 | FromDiscord | <mfiano> Night |
| 23:51:29 | FromDiscord | <mratsim> btw, if you are only using Vec2, Vec3 and quaternions you can create proc like these: https://github.com/treeform/vmath#proc-xyz-2 |
| 23:51:41 | FromDiscord | <mratsim> xy=, xz=, yz= |
| 23:52:16 | FromDiscord | <mratsim> and they can be used with myVec.xy = (valx, valy) |
| 23:53:18 | FromDiscord | <mfiano> I can't figure out how to construct your types |
| 23:53:25 | FromDiscord | <mfiano> I got some more manual reading to do it seems |
| 23:53:33 | FromDiscord | <mratsim> exact syntax is proc `xy=`(v: var Vec3, tup: tuple[x, y: float32]) |
| 23:54:13 | FromDiscord | <mratsim> you need backquote due to the equal |
| 23:55:11 | FromDiscord | <mratsim> In the manual it's the setter syntax: https://nim-lang.org/docs/manual.html#procedures-properties |
| 23:56:46 | FromDiscord | <mfiano> I see. |
