| 00:00:15 | disruptek | i'm not. i've been sitting here, same as always. |
| 00:00:37 | shashlick | good - what do you think of the conversation above |
| 00:00:58 | disruptek | i think i'm glad i spent 3hrs working on this today. |
| 00:01:09 | disruptek | it's 3hrs less someone else will need to spend. |
| 00:01:17 | * | mofeng joined #nim |
| 00:01:52 | disruptek | i think you're getting closer to implementing nimph, and that's cool. |
| 00:05:10 | disruptek | i think you have the patience of a saint and the heart of a lion. |
| 00:05:19 | disruptek | better? |
| 00:05:26 | * | disruptek 🤣 |
| 00:05:51 | * | krux02 quit (Ping timeout: 246 seconds) |
| 00:08:13 | shashlick | with those qualities, i might even make a collaborator out of you, beware! |
| 00:08:51 | disruptek | accidents happen, i guess. |
| 00:09:47 | shashlick | I'll take it |
| 00:10:30 | * | krux02 joined #nim |
| 00:15:21 | * | krux02 quit (Ping timeout: 265 seconds) |
| 00:18:10 | * | krux02 joined #nim |
| 00:22:37 | salotz[m] | someone should make a nim implementation of these protocols: https://github.com/nanomsg/nng |
| 00:23:11 | disruptek | i believe that's been done. |
| 00:23:34 | disruptek | https://github.com/def-/nim-nanomsg |
| 00:24:12 | salotz[m] | excellent |
| 00:26:48 | salotz[m] | it is a wrapper and not an implementation |
| 00:27:54 | rayman22201 | why does that matter? |
| 00:28:27 | shashlick | that is a nanomsg wrapper |
| 00:28:30 | shashlick | https://github.com/genotrance/feud/blob/master/wrappers/nng.nim is an nng wrapper |
| 00:35:48 | salotz[m] | rayman: it doesn't just pointing it out |
| 00:47:46 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
| 00:53:43 | * | rockcavera quit (Ping timeout: 268 seconds) |
| 00:54:19 | * | rockcavera joined #nim |
| 00:54:19 | * | rockcavera quit (Changing host) |
| 00:54:19 | * | rockcavera joined #nim |
| 01:13:54 | FromDiscord | <Bub_Lite_63_Jr> Can anyone help me troubleshoot a failed Nim install? |
| 01:14:11 | * | kevin joined #nim |
| 01:14:24 | * | kevin is now known as Guest45311 |
| 01:14:32 | * | Guest45311 is now known as kevin- |
| 01:15:06 | FromDiscord | <Rika> Errors? |
| 01:18:02 | FromDiscord | <Bub_Lite_63_Jr> Yeah |
| 01:18:13 | FromDiscord | <Bub_Lite_63_Jr> Let me set this up. I had Nim installed prior |
| 01:18:54 | FromDiscord | <Bub_Lite_63_Jr> I don't know which version, but I had it installed (on Mac). I read online on how to manually uninstall nim from one of the main devs in their forum. They said to delete .nimble and .chosenim from the home folder. |
| 01:18:56 | FromDiscord | <Bub_Lite_63_Jr> So I did that |
| 01:19:17 | FromDiscord | <Bub_Lite_63_Jr> Now, I want to reinstall, but I can't get it to work. |
| 01:19:28 | FromDiscord | <Bub_Lite_63_Jr> using this command `curl https://nim-lang.org/choosenim/init.sh -sSf | sh` |
| 01:19:47 | FromDiscord | <Rika> What does it say |
| 01:19:58 | FromDiscord | <Bub_Lite_63_Jr> ``` |
| 01:19:58 | FromDiscord | <Bub_Lite_63_Jr> Downloading Nim 1.0.2 from nim-lang.org |
| 01:19:58 | FromDiscord | <Bub_Lite_63_Jr> Info: /Users/josephlyons/.choosenim/downloads/nim-1.0.2.tar.gz already downloaded |
| 01:19:58 | FromDiscord | <Bub_Lite_63_Jr> Extracting nim-1.0.2.tar.gz |
| 01:19:59 | FromDiscord | <Bub_Lite_63_Jr> Building Nim 1.0.2 |
| 01:19:59 | FromDiscord | <Bub_Lite_63_Jr> Exception: Execution failed with exit code 1 |
| 01:20:00 | FromDiscord | <Bub_Lite_63_Jr> ... Command: sh build.sh |
| 01:20:02 | FromDiscord | <Bub_Lite_63_Jr> ... Output: # OS: macosx |
| 01:20:04 | FromDiscord | <Bub_Lite_63_Jr> ... # CPU: amd64 |
| 01:20:06 | FromDiscord | <Bub_Lite_63_Jr> ... clang -w -O3 -fno-strict-aliasing -Ic_code -c c_code/1_2/stdlib_assertions.nim.c -o c_code/1_2/stdlib_assertions.nim.o |
| 01:20:09 | FromDiscord | <Bub_Lite_63_Jr> ... clang -w -O3 -fno-strict-aliasing -Ic_code -c c_code/1_2/stdlib_dollars.nim.c -o c_code/1_2/stdlib_dollars.nim.o |
| 01:20:12 | FromDiscord | <Bub_Lite_63_Jr> ... c_code/1_2/stdlib_dollars.nim.c:7:10: fatal error: 'string.h' file not found |
| 01:20:13 | FromDiscord | <Bub_Lite_63_Jr> ... #include <string.h> |
| 01:20:14 | FromDiscord | <Bub_Lite_63_Jr> ... ^~~~~~~~~~ |
| 01:20:16 | FromDiscord | <Bub_Lite_63_Jr> ... 1 error generated. |
| 01:20:17 | FromDiscord | <Bub_Lite_63_Jr> Cleaning failed build |
| 01:20:19 | FromDiscord | <Bub_Lite_63_Jr> Tip: 7 messages have been suppressed, use --verbose to show them. |
| 01:20:21 | FromDiscord | <Bub_Lite_63_Jr> Error: Build failed |
| 01:20:22 | FromDiscord | <Bub_Lite_63_Jr> ``` |
| 01:20:24 | FromDiscord | <Bub_Lite_63_Jr> string.h |
| 01:20:25 | FromDiscord | <Bub_Lite_63_Jr> A cpp file? |
| 01:20:28 | FromDiscord | <Bub_Lite_63_Jr> A cpp header? |
| 01:30:35 | shashlick | did you remove .chosenim or .choosenim |
| 01:30:45 | shashlick | looks like it didn't really get removed |
| 01:30:59 | shashlick | anyway, i don't think that's the issue here |
| 01:31:22 | shashlick | how did you install clang |
| 01:38:39 | FromDiscord | <Bub_Lite_63_Jr> I’ll have to recheck on which I removed, as for clang, it was downloaded when I brew installed Zig-lang |
| 01:39:53 | shashlick | you might need to install xcode tools or something |
| 01:40:35 | shashlick | check this out https://railsapps.github.io/xcode-command-line-tools.html |
| 01:41:19 | FromDiscord | <Bub_Lite_63_Jr> I’ve installed it many times but I think I usually have to re-install it every time I do a major Xcode download and I haven’t done it since I’ve last upgraded |
| 01:41:36 | FromDiscord | <Bub_Lite_63_Jr> Thanks, I’ll give that a try |
| 01:41:52 | FromDiscord | <Bub_Lite_63_Jr> And come back after with an update |
| 01:41:57 | * | eys quit (Quit: eys) |
| 01:49:13 | shashlick | Ok good luck |
| 02:11:05 | * | GordonBGood joined #nim |
| 02:23:21 | rayman22201 | anybody know the flag to use NimStringV2 off the top of their head? |
| 02:23:43 | nisstyre | is it not legal in nim to treat a numeric literal like 0x30 as a char? |
| 02:23:58 | nisstyre | or is that a C-ism I should unlearn? |
| 02:24:14 | nisstyre | is there a byte type or something? |
| 02:25:10 | nisstyre | I guess uint8 works just as well |
| 02:25:18 | FromDiscord | <Bub_Lite_63_Jr> Just for clarification, I removed .choosenim |
| 02:26:17 | * | kevin- quit (Ping timeout: 240 seconds) |
| 02:26:36 | GordonBGood | rayman22201: it's --seqsv2, but it currently only works with "-gc:destructors" and "--newruntime", both of which turn it on themselves, and both of them incomlete in its use |
| 02:26:57 | rayman22201 | hrmmmm.... |
| 02:27:10 | rayman22201 | thansk @GordonBGood |
| 02:27:13 | rayman22201 | thanks even |
| 02:27:35 | FromDiscord | <Bub_Lite_63_Jr> Also, I have command line tools installed, but I dont have the absolute most recent Xcode installed |
| 02:28:00 | FromDiscord | <Bub_Lite_63_Jr> I have 11.1 and 11.2 is the newest |
| 02:28:09 | GordonBGood | Araq has given me the project to port it's use to other GC's, but I'm want to see it working properly where it was first designed in those two before proceeding... |
| 02:28:23 | FromDiscord | <Bub_Lite_63_Jr> But I feel Nim shouldn't be failing from a single minor version update on Xcode |
| 02:28:28 | GordonBGood | So now trying to trace memory leaks related to this |
| 02:28:30 | FromDiscord | <Bub_Lite_63_Jr> But I feel Nim installation shouldn't be failing from a single minor version update on Xcode |
| 02:28:43 | rayman22201 | my project is getting async to work with newruntime |
| 02:29:08 | rayman22201 | I am leaking a string, and I thought it might be related to the old string implementation |
| 02:29:13 | rayman22201 | but I don't think so anymore |
| 02:29:16 | GordonBGood | rawman22201: I noticed that you are reported finding memory leaks yesterday too, may be related |
| 02:29:22 | rayman22201 | I'm not sure |
| 02:29:36 | * | nif quit (Quit: ...) |
| 02:29:46 | * | nif joined #nim |
| 02:30:06 | GordonBGood | No, there is a good chance it is related to the new implementation of seqsv2 (which includes stringsv2, too) |
| 02:31:08 | GordonBGood | If you are leaking a string in --newruntime, it is already a new destructor based string as there is no other kind there |
| 02:32:41 | GordonBGood | So far, I have found that when calling dested destructors (`=destroy`), it isn't recognizing that seqs/strings already have custom versions and it is generating no-op versions itself instead |
| 02:32:45 | rayman22201 | I'm actually using this: https://github.com/nim-lang/Nim/pull/12512 |
| 02:32:53 | rayman22201 | so it's not fully --newruntime |
| 02:32:56 | GordonBGood | "it" means the compiler magic |
| 02:33:37 | GordonBGood | No, there is something commin related to this between --newruntime and --gc:destructors |
| 02:34:12 | rayman22201 | the thing is, I'm not actually sure which string I'm leaking |
| 02:34:26 | rayman22201 | I would love to see which string it is, but I'm not sure how to find it lol |
| 02:34:45 | rayman22201 | I'm using --gc:boehm actually |
| 02:35:07 | rayman22201 | the "dispose" calls, are slightly different thing |
| 02:35:48 | GordonBGood | You are leaking with -gc:boehm? That is usually fairly reliable |
| 02:36:05 | rayman22201 | you misunderstand what I'm doing. I am actually working on a competing project to you |
| 02:36:23 | rayman22201 | it is also known as "araqGC" |
| 02:36:29 | GordonBGood | But dispose and deepDispose are new and tacked on, so I wouldn't be surprised if their use is problematic |
| 02:36:49 | rayman22201 | boehm + dispose and deepDispose is the entire point of the exercise |
| 02:37:35 | GordonBGood | Ah, but araqsgc is a form of --gd:destructors just with GC hooks taked on |
| 02:37:51 | rayman22201 | I think "tacked on" doesn't give Araq enough credit |
| 02:38:15 | rayman22201 | my project is to make async work with dispose. At which point any GC with dispose support with work. |
| 02:38:47 | GordonBGood | Oh, I credit him with trying to unify the code base, just in there hasn't been enough testing done to qualify attempting the back-port |
| 02:38:47 | rayman22201 | put another way, I'm trying to make async free memory in a deterministic / GC free way |
| 02:39:26 | rayman22201 | this is the whole point of my project though. Araq asked me to do this. I'm not just doing it randomly |
| 02:39:40 | rayman22201 | if I prove this works, we can put more effort into back-porting |
| 02:40:02 | GordonBGood | Yes, I suggested making all GC's work through GC hooks, if you can make it work then it would unify a lot of things |
| 02:40:54 | rayman22201 | which brings me back to my question. I am able to collect everything except a single string. And I'm really stuck trying to find where this damn leak is :-P |
| 02:41:01 | GordonBGood | But we need a fully working seqsv2 before you can test using those |
| 02:41:08 | rayman22201 | so It's good progress |
| 02:41:25 | rayman22201 | collect == "dispose" lol |
| 02:41:37 | rayman22201 | dispose / destruct, depending on what's appropriate |
| 02:41:53 | GordonBGood | Araq has given me some guidance on where to start looking for the memory leak problem but I got blocked; I have some new ideas I'll be looking into today |
| 02:42:29 | GordonBGood | I'll ping you if I find anything |
| 02:42:39 | rayman22201 | 👍 |
| 02:42:54 | GordonBGood | I think it has to do with this issue I filed: https://github.com/nim-lang/Nim/issues/12588 |
| 02:42:57 | disbot | ^ Nested `=destroy` call for "seqsv2" doesn't seem to find its custom `=destroy` imlementation... |
| 02:42:57 | disbot | ^ snippet at https://play.nim-lang.org/#ix=20WG 😏 |
| 02:45:02 | rayman22201 | that's very possible |
| 02:45:35 | GordonBGood | disbot: you robo dummy, you didn't read the issue: it doesn't fail on release versions, only on the latest devel branch :) |
| 02:45:57 | rayman22201 | lol. cute |
| 02:46:26 | GordonBGood | I don't know, but it might help you to consider this in your investigations |
| 02:46:32 | rayman22201 | It may also be related to a cycle that I have. |
| 02:48:08 | GordonBGood | Yes, async implementation has a data cycle, but for --gc:destructors (using ref counting), @Araq has patched it to make the cycle like a weak ref (I think) |
| 02:48:25 | rayman22201 | async produces a closure and a closure Iterator. (Really they are both just closures, for all I care... but I digress). The problem is, they keep refs to each other... this means `dispose(closure)` and `dispose(closureIterator)` work, but `deepDespose(closure)` and `deepDispose(closure)` explode. |
| 02:48:47 | GordonBGood | Con't remember to what other GC's that patch applies |
| 02:49:53 | GordonBGood | IIRC, he made one of the internal ref's into a ptr, which fixed the cycle for the quicky test we did showing ref counting can work with async |
| 02:49:55 | rayman22201 | it may be that the offending string is inside one of those closures. Since I can't `deepDispose` I loose it :/ |
| 02:50:16 | GordonBGood | But I wondered at the time whether the patch might break something else |
| 02:50:59 | GordonBGood | Yup, I suspect that is the problem with losing your (new v2?) string |
| 02:51:17 | rayman22201 | I'm still unsure if I have V2 or V1 strings |
| 02:51:23 | rayman22201 | how can I check? |
| 02:52:12 | rayman22201 | It's also possible that the string is some associated debug information attached to the Future. If that is the case, then dispose is broken in some more fundamental way that I don't understand. |
| 02:55:44 | * | GordonBGood quit (Ping timeout: 276 seconds) |
| 02:59:28 | * | mofeng quit (Quit: Textual IRC Client: www.textualapp.com) |
| 02:59:43 | * | shashlick[m] joined #nim |
| 03:01:05 | * | GordonBGood joined #nim |
| 03:04:03 | * | lritter quit (Ping timeout: 240 seconds) |
| 03:05:06 | * | lritter joined #nim |
| 03:05:36 | * | shashlick_ joined #nim |
| 03:05:51 | * | krux02 quit (Remote host closed the connection) |
| 03:06:52 | * | GordonBGood quit (Quit: Few women admit their age. Few men act theirs.) |
| 03:07:08 | * | GordonBGood joined #nim |
| 03:07:37 | * | GordonBGood quit (Client Quit) |
| 03:08:27 | * | GordonBGood joined #nim |
| 03:08:47 | GordonBGood | rayman22201: Sorry, my ISP dropped |
| 03:08:54 | GordonBGood | To see if seqsv2: when defined (nimSeqsV2): echo "version 2 seqs/strings" else: echo "legacy seqs/strings" |
| 03:09:36 | rayman22201 | Np |
| 03:09:57 | * | shashlick_ left #nim (#nim) |
| 03:10:17 | rayman22201 | I have to go unfortunately. Bbl |
| 03:10:46 | GordonBGood | Ok, chat later |
| 03:16:31 | * | lritter quit (Quit: Leaving) |
| 03:20:49 | * | dddddd quit (Remote host closed the connection) |
| 03:21:20 | * | rockcavera quit (Remote host closed the connection) |
| 04:12:10 | disruptek | nimble can't run nimph's tests. ah, the irony. |
| 04:18:58 | * | abm quit (Quit: Leaving) |
| 04:19:19 | * | Romanson joined #nim |
| 04:23:12 | * | u0_a215 joined #nim |
| 04:23:16 | * | u0_a215 is now known as kevin |
| 04:23:45 | * | kevin is now known as Guest64866 |
| 04:25:04 | * | ponyrider joined #nim |
| 04:25:42 | * | nixfreak joined #nim |
| 04:32:06 | * | kevin_ joined #nim |
| 04:32:37 | * | kevin_ quit (Client Quit) |
| 04:36:21 | * | Guest64866 quit (Ping timeout: 265 seconds) |
| 04:53:23 | * | chemist69 quit (Ping timeout: 276 seconds) |
| 04:55:09 | * | chemist69 joined #nim |
| 04:58:12 | * | nsf joined #nim |
| 05:20:18 | FromGitter | <zacharycarter> huh |
| 05:20:29 | FromGitter | <zacharycarter> just found out you could do `const uint32_t png_ihdr = 'HELO`; in GCC |
| 05:20:44 | FromGitter | <zacharycarter> not sure what that tarnslates to in Nim |
| 05:21:33 | * | theelous3 quit (Ping timeout: 246 seconds) |
| 05:21:35 | FromGitter | <zacharycarter> ```The resulting constant (in GCC, which implements this) has the value you get by taking each character and shifting it up, so that 'I' ends up in the most significant bits of the 32-bit value. Obviously, you shouldn't rely on this if you are writing platform independent code.``` |
| 05:44:53 | * | theelous3_ joined #nim |
| 05:52:01 | FromGitter | <zacharycarter> is there any proc for converting a sequence of bytes to a uint32? |
| 05:52:42 | FromGitter | <zacharycarter> or should I just author one since it's a fairly simple task |
| 06:28:13 | Zevv | kind of depends on *how* to convert them, no? |
| 06:35:12 | * | kevin joined #nim |
| 06:35:36 | * | kevin is now known as Guest56307 |
| 06:39:24 | Araq | endians.nim can do it iirc |
| 06:39:57 | Araq | so ... how am I supposed to reply to the Nimble discussion? |
| 06:41:52 | * | narimiran joined #nim |
| 06:45:52 | * | Guest56307 is now known as kevin- |
| 06:45:57 | * | kevin- quit (Remote host closed the connection) |
| 06:46:40 | * | kevin- joined #nim |
| 06:47:28 | FromGitter | <zacharycarter> Araq: thanks |
| 06:51:20 | * | Araq sighs |
| 06:56:47 | * | solitudesf joined #nim |
| 07:01:15 | FromGitter | <mratsim> Wow I'm happy Nim VM works so much better than C++ https://thephd.github.io/sol3-compile-times-binary-sizes |
| 07:08:20 | * | Romanson quit (Quit: Connection closed for inactivity) |
| 07:17:47 | * | filcuc joined #nim |
| 07:33:19 | * | theelous3_ quit (Ping timeout: 268 seconds) |
| 07:35:43 | FromGitter | <zacharycarter> endians worked - https://play.nim-lang.org/#ix=20X7 |
| 07:37:43 | * | filcuc quit (Quit: Konversation terminated!) |
| 07:38:07 | FromGitter | <zacharycarter> I forgot to remove the last `uint32(...)` |
| 07:40:03 | * | PMunch joined #nim |
| 07:43:15 | * | solitudesf quit (Ping timeout: 240 seconds) |
| 07:48:15 | * | sedfox quit (Quit: leaving) |
| 08:00:00 | * | gmpreussner quit (Quit: kthxbye) |
| 08:04:42 | * | gmpreussner joined #nim |
| 08:31:18 | FromGitter | <zaphodef> the `$` format function doesn't work with `FileIndex`, bug or feature? ^^ |
| 08:31:42 | GordonBGood | Araq: it seems that now rayman22201 and still myself are fighting similar memory leak problems with destructor based seq's and strings... |
| 08:32:35 | GordonBGood | His is with strings, so I looked into the implementation: new v2 strings don't have destructors, and whatever they do seems to be done with compiler magic? |
| 08:32:42 | * | floppydh joined #nim |
| 08:33:53 | GordonBGood | whereas seq's do have destructors, but in the current code, they are disabled by "nimv2", which is now turned on by both "--gc:destructors" and "--newruntime"... |
| 08:34:35 | GordonBGood | I think there are also problems still with moving/copying/destroying captured things with closures... |
| 08:35:55 | GordonBGood | So my question is: why do we keep messing around with ptr T and special casing everything, when if we just got ref's working properly, we could just make anything that points to heap a ref by default |
| 08:38:02 | GordonBGood | Then instead of a ptr StringPayLoad in strings, it would be a ref StringPayLoad, and instead of a ref SeqPayLoad, it would be a ref SeqPayLoad |
| 08:38:52 | GordonBGood | So as long as we made sure everything respected move/copy/destroy semantics, everything should work... |
| 08:39:22 | GordonBGood | And the only special treatment would be for ref's to be sure they obey the semantics |
| 08:39:59 | GordonBGood | That would then also include closures, whose environment is already a ref |
| 08:44:17 | * | uu91 joined #nim |
| 08:46:09 | * | nif quit (Quit: ...) |
| 08:46:18 | * | nif joined #nim |
| 08:47:52 | * | solitudesf joined #nim |
| 08:51:22 | Araq | I fail to see the advantage, a ref points to a fixed size object, only 'seq' are variable sized |
| 08:51:39 | Araq | so you end up with exactly all the special cases that we already have |
| 08:52:12 | Araq | except that you change even more of the implementation in an attempt to "fix" more. |
| 08:52:43 | Araq | this is hard stuff, I only know how to tackle it one by one, big rewrites only reintroduce all the bugs we already fixed |
| 08:53:07 | Araq | it's always shiny and simple in theory, the implementation is always ugly |
| 08:53:29 | Araq | or maybe I'm simply a bad programmer :P |
| 08:53:50 | GordonBGood | Well, maybe, but I'm just getting frustrated with it as there seems to be so many things interacting with each other: closures containing ref's as environments that wrap any of them, differences between strings and seq's etc |
| 08:54:10 | Araq | btw rayman22201 uses the old seqs and has different problems |
| 08:54:59 | GordonBGood | rayman22201 and I never got to what kind of seqs/strings he was using as he had to leave just as we were getting to it |
| 08:55:14 | Araq | well but I know. V1 strings and seqs. |
| 08:55:30 | GordonBGood | Okay, different problems |
| 08:56:02 | Araq | anyway, I'm hunting a codegen bug that happens with |
| 08:56:09 | GordonBGood | I'm not very concerned with legacy seqs strings as my objective is to not have to use them as quickly as I get get my project licked |
| 08:56:13 | Araq | nim c --gc:destructors tests\async\tasyncawait |
| 08:56:54 | Araq | seems like the logic for 'tyRef' is off and it follows the refs where it should delegate it to a =destroy call, I wonder what's up with that... |
| 08:57:34 | GordonBGood | I've dropped back to using --gc:destructors as the simplest case using seqsv2, and until they fully work there, I can't proceed with getting them to work with other GC's |
| 08:58:20 | GordonBGood | Yes, I think that's exactly the problem I'm fighting, but I don't have your knowledge of the compiler code |
| 08:58:32 | Araq | want me to stream about it? |
| 09:00:24 | GordonBGood | Also, the reason for the current frustration is that I noticed that while new seqs have destructors that can be turned on, it seems core/strs.nim doesn't, meaning that there must be "compiler magic/cruft" making them work, meaning that I'm going to have to dig even deaper when I move from seq's to |
| 09:01:15 | GordonBGood | stream? bether than me screaming I suppose :) |
| 09:01:16 | GordonBGood | string's |
| 09:03:14 | Araq | well of course it's frustrating, it is for me too, but it's in development |
| 09:03:54 | Araq | we split our resources between bugfixes and feature development |
| 09:04:18 | Araq | feature development is more fun so that's why I'm eager to outsource it to you and clybber etc |
| 09:04:30 | Araq | and rayman22201 of course |
| 09:04:59 | * | GordonBGood quit (Read error: Connection reset by peer) |
| 09:05:11 | Araq | my apologies for not mentioning all the others in #nim |
| 09:05:31 | * | GordonBGood joined #nim |
| 09:05:33 | GordonBGood | I don't mind if it has problems, I just want it working so then we can build and experiment with the rest of the features we discussed on top of that |
| 09:06:20 | Araq | so what do you want me to show you? |
| 09:06:24 | GordonBGood | problems = speed/no cycle detection/etc |
| 09:07:29 | GordonBGood | I seem to still have problems where things moved into closures aren't calling the destructor hooks properly |
| 09:08:06 | GordonBGood | So ref counts are either lower than they should be and things are destroyed prematurely or to high when they are never destroyed |
| 09:09:30 | Araq | https://github.com/nim-lang/Nim/issues/12588 this one? |
| 09:09:32 | disbot | ^ Nested `=destroy` call for "seqsv2" doesn't seem to find its custom `=destroy` imlementation... |
| 09:09:32 | disbot | ^ snippet at https://play.nim-lang.org/#ix=20WG 😏 |
| 09:09:37 | GordonBGood | So I guess I need to understand when the environment ref determines when custom destructofs for the given objects exists and calls their destructors as necessary |
| 09:10:17 | Araq | disbot? what's this? |
| 09:10:51 | GordonBGood | disbot is a robo dummy that seems to keep moving code it finds into an example playground |
| 09:11:08 | GordonBGood | code it finds in links |
| 09:12:52 | GordonBGood | On the link, I actually today think I see why it doesn't find the seq destructors: it seems that the destructors are turned off for "nimV2" and now "gcDestructors" include defining "nimV2" |
| 09:13:41 | GordonBGood | Which means that what destruction for seq's is normally happing (but not for nested) is being triggered by something outside the destructors |
| 09:13:58 | GordonBGood | ^happening |
| 09:15:00 | GordonBGood | That's my frustration: I understood that for --gc:destructors, everything would be destructor based without magic, but now I'm thinking I'm seeing that isn't the case |
| 09:15:36 | FromDiscord | <Rika> Is disbot new |
| 09:16:01 | Araq | GordonBGood, it's without *much* magic ;-) |
| 09:16:03 | GordonBGood | Rika: only just noticed it today |
| 09:16:24 | Araq | consider that const c = @["a", "b", "c"] still needs to compile, for example |
| 09:16:34 | GordonBGood | But why disable destructors for --gc:destructors? |
| 09:16:53 | Araq | we don't do that |
| 09:17:12 | Araq | but we still need some help from the C backend |
| 09:17:20 | PMunch | Is there a way to define an enum to be a cint? |
| 09:17:43 | Araq | PMunch, not really and please use 'distinct cint' for C interop |
| 09:17:55 | PMunch | distinct cint? |
| 09:18:02 | PMunch | Instead of the enum? |
| 09:18:03 | Araq | Nim's enums are more efficient than C's but don't map to C all that well as we found out |
| 09:18:09 | GordonBGood | commands.nim line 460 and seqs.nim line 47 |
| 09:18:47 | PMunch | I have it defined as "type module_ev* {.size: 4.} = enum <values>" and that seems to work just fine |
| 09:19:07 | PMunch | But you reccomend doing a series of consts with a distinct cint type instead? |
| 09:19:16 | Araq | generally yes, PMunch |
| 09:19:33 | Araq | GordonBGood, that's because they didn't work |
| 09:19:38 | PMunch | Hmm, not as pretty though :( |
| 09:20:26 | GordonBGood | Araq: Ah, so where are the "destructors" in "--gc:destructors"? |
| 09:20:39 | Araq | it's effectively in a 'when false' yes, because it doesn't work. |
| 09:20:54 | Araq | Hint: I started with this clean solution before I had to abandon it. |
| 09:21:33 | GordonBGood | Darn, I love clean solutions ;) |
| 09:22:49 | GordonBGood | So far, --gc:destructors works for simple code, but fails as soon as one starts to "mix it up" |
| 09:22:50 | Araq | liftdestructors.nim line 326 |
| 09:23:07 | Araq | # destroy all elements: |
| 09:23:07 | Araq | forallElements(c, t, body, x, y) |
| 09:23:07 | Araq | body.add genBuiltin(c.g, mDestroy, "destroy", x) |
| 09:23:30 | Araq | so the mDestroy is delegates to the C backend |
| 09:23:44 | Araq | but by then the elements itself should have been destroyed |
| 09:28:40 | GordonBGood | Okay, I'll try to follow it from there |
| 09:29:33 | GordonBGood | I am in process of trying to create some simple examples that don't seem to work as expected to try to trace to see where there are failing |
| 09:30:38 | GordonBGood | I've been trying to trace with destructor "hooks" on objects as per the issues related to this, but I'm still not getting destruction when expected |
| 09:31:20 | GordonBGood | for instance, an object created in an iterator doesn't seem to be getting destroyed |
| 09:31:56 | Araq | proc injectDestructorCalls*(g: ModuleGraph; owner: PSym; n: PNode): PNode = |
| 09:31:56 | Araq | if sfGeneratedOp in owner.flags or (owner.kind == skIterator and isInlineIterator(owner.typ)): |
| 09:31:56 | Araq | return n |
| 09:31:59 | Araq | :P |
| 09:31:59 | GordonBGood | when it is also captured in a closure; I am trying to see if the closure capture is the reason |
| 09:32:13 | Araq | however the reason is that it's been inlined already |
| 09:32:32 | Araq | and so will be destroyed in the proc it was inlined into |
| 09:32:55 | Araq | the capture extends its lifetime, what's mysterious about it |
| 09:33:20 | GordonBGood | Yes, I though of that, so I inlined it into a main proc and it isn't destroyed at the end of that either |
| 09:33:40 | Araq | as I said, we do tyRef wrong |
| 09:33:46 | Araq | and closures are tyRefs too |
| 09:34:01 | Araq | so it's probably the bug I'm hunting |
| 09:34:28 | GordonBGood | Nothing mysterious, but the closure should be getting destroyed before the variable and therefore not affecting it |
| 09:34:46 | GordonBGood | Yes, that's what I'm thinking since you mentioned it |
| 09:35:38 | GordonBGood | Since I can't likely help you on that, I'll just try to refine my testing while you fix it and watch the commits :) |
| 09:37:10 | GordonBGood | I use closures all the time and rely on them, so just about always use them - they are one of Nim's best features when they work |
| 09:37:35 | GordonBGood | And all the async stuff can't work without them as we have discussed |
| 09:39:13 | GordonBGood | Is the tyRef just wroing for --gc:destructors or elsewhere? |
| 09:40:20 | * | thomasross quit (Remote host closed the connection) |
| 09:40:36 | GordonBGood | and are destructor hooks usable in --gc:destructors, just not for seqs and strings? |
| 09:40:45 | * | thomasross joined #nim |
| 09:41:20 | Araq | I think it's wrong for --gc:destructors, maybe for --newruntime too |
| 09:41:36 | Araq | hooks are usable but are tied to nominal types, as before |
| 09:42:13 | GordonBGood | Not too concerned with --newruntime for now, want to see --gc:destructors work first |
| 09:42:47 | Araq | me too. most simple programs I tried work with --gc:destructors |
| 09:42:56 | Araq | most complex programs don't |
| 09:43:13 | GordonBGood | Yes, understood on the nominal types and not ref T or ptr T; so seq and string v2 are nominal types, why did they not work? |
| 09:46:09 | Araq | they are special builtin types |
| 09:46:26 | Araq | and need to stay builtin see my 'const' example. |
| 09:48:41 | GordonBGood | Okay, I saw the attempt to cast seq to NimSeqV2 and kind of see why that woudn't work |
| 09:50:20 | * | thomasross quit (Remote host closed the connection) |
| 09:50:31 | GordonBGood | the seqsv2 project you've given me gets more involved than I thought - that means that "hooks" likely won't work for them across the other GC's either |
| 09:50:45 | * | thomasross joined #nim |
| 09:51:23 | PMunch | Anyone feel up for adding a feature to choosenim? https://github.com/dom96/choosenim/issues/146 |
| 09:51:24 | * | Vladar joined #nim |
| 09:54:12 | GordonBGood | Araq: I had assumed that they were converted from pointers to payloads just objects containing pointers to payloads in order to make nominal type "hooks" work; when that doesn't work, one needs to ask "why are we doing it"? |
| 09:56:59 | GordonBGood | Perhaps it is because it is easier to trigger things on objects that contain some idea of the size of the payload than on pointers relying on RTTI? |
| 10:06:09 | Araq | I don't understand the question |
| 10:08:45 | GordonBGood | Now that I see that seqsv2 can't work as nominal type destructor "hooks" I was wondering their advantage over legacy seqs/strings, but I see that they don't rely on RTTI attached via an invisible header, am I right? |
| 10:11:08 | * | krux02 joined #nim |
| 10:11:16 | * | ng0 joined #nim |
| 10:11:36 | Araq | yes |
| 10:12:52 | * | solitudesf quit (Ping timeout: 252 seconds) |
| 10:12:57 | GordonBGood | Okay, I back to gung ho for them then; is it your plan to eliminate the RTTI hidden headers once we have fullly working --gc:destructors and/or --newruntime? |
| 10:13:27 | * | dddddd joined #nim |
| 10:13:29 | GordonBGood | ^i'm back to gung ho |
| 10:14:39 | PMunch | Hmm, is there no toHex for array[byte]? |
| 10:15:27 | * | uu91 quit (Read error: Connection reset by peer) |
| 10:15:42 | * | uu91 joined #nim |
| 10:16:12 | Araq | GordonBGood, there are no hidden RTTI headers left in the new implementation |
| 10:16:23 | Araq | well there none left we can eliminate. |
| 10:16:26 | GordonBGood | Araq: great |
| 10:18:52 | * | uu91 quit (Read error: Connection reset by peer) |
| 10:19:07 | * | uu91 joined #nim |
| 10:21:47 | * | tdc joined #nim |
| 10:44:24 | * | tklohna quit (Read error: Connection reset by peer) |
| 10:48:03 | * | xet7_ is now known as xet7 |
| 10:54:23 | * | xet7 quit (Quit: Leaving) |
| 10:55:02 | * | xet7 joined #nim |
| 11:13:53 | * | venk quit (Remote host closed the connection) |
| 11:18:37 | * | tklohna joined #nim |
| 11:18:47 | * | rockcavera joined #nim |
| 11:37:20 | * | krux02_ joined #nim |
| 11:39:23 | * | krux02__ joined #nim |
| 11:40:56 | * | krux02 quit (Ping timeout: 276 seconds) |
| 11:42:40 | * | krux02_ quit (Ping timeout: 264 seconds) |
| 11:45:40 | * | krux02__ quit (Ping timeout: 264 seconds) |
| 11:53:27 | FromDiscord | <mratsim> so is gc:hook a GC where the uses can redefine the allocator? |
| 11:53:40 | FromDiscord | <mratsim> @PMunch, there is on in stew/byteutils |
| 11:54:03 | FromDiscord | <mratsim> https://github.com/status-im/nim-stew/blob/master/stew/byteutils.nim |
| 12:04:50 | Araq | mratsim: as I said, allocators are a deadend, write a custom 'seq' that uses the allocator that you need |
| 12:09:03 | FromGitter | <alehander92> but this doesnt help when you use all the existing code with normal seq |
| 12:16:23 | FromGitter | <alehander92> sorry, nvm |
| 12:17:05 | FromGitter | <alehander92> hm, i want to play with some unknown nim lib codebase |
| 12:18:17 | FromGitter | <alehander92> with a lot of file/network io |
| 12:18:38 | FromGitter | <alehander92> what would be a good example? something http related? |
| 12:25:29 | * | fanta1 joined #nim |
| 12:30:47 | PMunch | mratsim, I figured there was one in nimcrypto as well. And I'm already using hmac so I've already got that imported |
| 12:31:28 | * | gangstacat quit (Ping timeout: 252 seconds) |
| 12:46:18 | * | abm joined #nim |
| 12:48:32 | * | tklohna quit (Ping timeout: 276 seconds) |
| 12:59:39 | * | gangstacat joined #nim |
| 13:07:03 | FromDiscord | <mratsim> tbh it's very hard to follow because every monday there is a new thing |
| 13:12:52 | * | ng0 quit (Ping timeout: 260 seconds) |
| 13:15:05 | * | ng0 joined #nim |
| 13:16:36 | * | tklohna joined #nim |
| 13:23:30 | disruptek | Araq: thanks for the merge. |
| 13:24:56 | * | kevin- quit (Remote host closed the connection) |
| 13:46:03 | Araq | disruptek: waiting for your --nimblePathOverride PR. or maybe it's --nimblePathReset --nimblePath:foobar |
| 13:46:21 | disruptek | up to you. |
| 13:46:30 | Araq | seems cleaner. you reset it first and then you can add dirs to it again |
| 13:46:35 | disruptek | okay. |
| 13:51:54 | Araq | mratsim: I'm writing an RFC outlining the plan. |
| 13:51:56 | * | Vladar quit (Quit: Leaving) |
| 13:54:25 | * | GordonBGood quit (Quit: First shalt thou take out the Holy Pin. Then, shalt thou count to three. No more. No less.) |
| 13:55:09 | lqdev[m] | is there any good tutorial on how locks work in threading? afaik they work like semaphores, but I want more details |
| 14:05:54 | Araq | Nim uses the OS primitives |
| 14:14:09 | * | tklohna quit (Ping timeout: 268 seconds) |
| 14:17:09 | * | fanta1 quit (Quit: fanta1) |
| 14:18:12 | disruptek | ah, excludePath also works on nimblePath! |
| 14:18:22 | disruptek | 👏 |
| 14:18:33 | Araq | we have excludePath? |
| 14:18:38 | disruptek | apparently. |
| 14:18:47 | Araq | never used it, good to know |
| 14:18:59 | disruptek | do you still want resetPath? |
| 14:19:39 | Araq | not if excludePath already works |
| 14:19:52 | Araq | needs better documentation then |
| 14:20:30 | disruptek | okay. i will see if i can fix that. |
| 14:21:07 | disruptek | i'll also test that this solves the problem. 😉 |
| 14:27:21 | FromGitter | <kaushalmodi> disruptek: how? |
| 14:27:28 | FromGitter | <kaushalmodi> in config.nims? |
| 14:27:32 | FromGitter | <kaushalmodi> or that's a switch? |
| 14:28:12 | * | solitudesf joined #nim |
| 14:28:46 | narimiran | can somebody enlighten me why this example would fail on 32-bits? https://play.nim-lang.org/#ix=20Yz |
| 14:28:53 | disruptek | it's a switch, but it's processed after the config file has already expanded all the paths, so it's not exactly pain-free. |
| 14:29:00 | * | clyybber joined #nim |
| 14:29:07 | narimiran | because it is failing on our 32-bit CIs and i don't understand why |
| 14:30:00 | FromGitter | <kaushalmodi> disruptek: wouldn't we need to excludePath every pkg from the ~/.nimble? |
| 14:30:10 | disruptek | yes, that's the "pain" part. |
| 14:30:16 | FromGitter | <kaushalmodi> please no :) |
| 14:30:30 | FromGitter | <kaushalmodi> that's no different than specifying each `path` manually in config.nims |
| 14:30:49 | disruptek | i know. i will fix this one way or another today. |
| 14:30:56 | FromGitter | <kaushalmodi> thanks |
| 14:31:05 | FromGitter | <kaushalmodi> I like --nimblePathReset |
| 14:31:33 | disruptek | just trying to find the most correct solution... probably it will be a reset. i'd like to name it `Empty`, actually. |
| 14:32:36 | FromGitter | <kaushalmodi> reset makes more sense to me |
| 14:32:52 | * | Hideki_ joined #nim |
| 14:33:14 | FromGitter | <kaushalmodi> as reset reads like a *verb* |
| 14:33:17 | * | eys joined #nim |
| 14:33:40 | disruptek | fair point. |
| 14:33:42 | FromGitter | <kaushalmodi> well, empty can be read as a verb to |
| 14:33:44 | FromGitter | <kaushalmodi> too |
| 14:33:59 | FromGitter | <kaushalmodi> but somehow reset makes more sense, probably, because it's used more in this sense |
| 14:34:02 | disruptek | reset makes it sound like it might revert to a state that has contents. |
| 14:34:18 | disruptek | reset... to what? is the obvious question. |
| 14:34:33 | disruptek | how about `Clear`? |
| 14:34:44 | FromGitter | <kaushalmodi> that's better |
| 14:35:00 | disruptek | 👍 |
| 14:37:22 | Araq | --clearNimblePath |
| 14:37:31 | disruptek | okay. |
| 14:38:37 | disruptek | should be a 6-line patch. 😁 |
| 14:40:16 | Araq | ikr, too bad I always have to work on the hard problems |
| 14:40:40 | disruptek | i feel for you. giving all the fun features to others. |
| 14:42:42 | disruptek | do we test any of this stuff? |
| 14:42:59 | disruptek | i put it in the docs, but... |
| 14:43:26 | FromGitter | <kaushalmodi> narimiran: I tried your snippet with `nim c --cpu:i386 --passC:-m32 --passL:-m32 -r t1.nim`.. works fine |
| 14:43:48 | FromGitter | <kaushalmodi> I am on RHEL 6.8.. does it fail 32-bit on all OSes? |
| 14:44:08 | narimiran | thanks for testing it! it fails on 32-bit linux on our CIs |
| 14:44:31 | narimiran | both nighties and now in version-1-0 branch too |
| 14:44:52 | FromGitter | <kaushalmodi> btw, I get this hint: (unrelated) ⏎ ⏎ > /home/kmodi/sandbox/nim/colors/t1.nim(13, 3) Hint: 'col' should be: 'Col' [Name] |
| 14:45:04 | FromGitter | <zetashift> I can test it on Manjaro too, can I just run kaushalmodi's command on x64? |
| 14:45:05 | FromGitter | <kaushalmodi> should use capital for types |
| 14:45:14 | FromGitter | <kaushalmodi> @zetashift yes |
| 14:45:27 | FromGitter | <kaushalmodi> https://scripter.co/notes/nim/#compiling-in-32-bit-mode |
| 14:46:12 | narimiran | @zetashift i'm on manjaro (64-bit) and it works for me, as it does for CIs on other arches |
| 14:46:25 | narimiran | but if you have 32-bit manjaro, that would be helpful |
| 14:46:40 | FromGitter | <kaushalmodi> link to failure log? |
| 14:46:50 | FromGitter | <zetashift> I don't have 32 bit, weird stuff |
| 14:46:55 | disruptek | maybe the playground should have an architecture switch. |
| 14:47:05 | FromGitter | <kaushalmodi> I am no expert in 32-bit stuff but someone here might make something out of that log |
| 14:47:07 | narimiran | https://api.travis-ci.org/v3/job/607508914/log.txt at the very very bottom (it takes some time to load the whole file) |
| 14:48:01 | FromGitter | <kaushalmodi> narimiran: to test it, do you want to add `echo extractRGB(a)` to see why it didn't match? |
| 14:49:11 | FromGitter | <kaushalmodi> and also `echo $type(extractRGB(a))` |
| 14:50:18 | narimiran | https://play.nim-lang.org/#ix=20YH |
| 14:50:50 | FromGitter | <kaushalmodi> right.. but do that on the code run on CI |
| 14:53:18 | narimiran | ok, i might do that |
| 14:53:36 | * | NimBot joined #nim |
| 14:58:24 | disruptek | well, that was easy. package local deps and nim.cfg config impl'd in like 3hrs. |
| 15:02:17 | Araq | mratsim: https://github.com/nim-lang/RFCs/issues/177 |
| 15:04:12 | * | solitudesf quit (Ping timeout: 265 seconds) |
| 15:05:00 | disruptek | cursor seems pretty painless, plus we can report on them, too. |
| 15:08:03 | FromGitter | <alehander92> hm, why do we want to remove |
| 15:08:06 | FromGitter | <alehander92> the other gc- |
| 15:10:37 | FromGitter | <alehander92> i was left with the impression that we want to be able to add gc-s as lib |
| 15:10:42 | FromGitter | <alehander92> as with araqgc |
| 15:11:34 | FromDiscord | <mratsim> thanks @Araq will look |
| 15:16:12 | * | PMunch quit (Quit: Leaving) |
| 15:23:53 | * | solitudesf joined #nim |
| 15:25:26 | rayman22201 | Araq: could your tyRef destructor bug be related to why deepDispose is acting weird for me? |
| 15:26:50 | * | floppydh quit (Ping timeout: 240 seconds) |
| 15:32:39 | narimiran | another test for y'all, does this work on your machines (if you're using devel, at most one week old)? https://play.nim-lang.org/#ix=20YZ |
| 15:33:17 | disruptek | works for me on 64-bit linux. |
| 15:33:53 | narimiran | disruptek: fails for me on 64-bit linux ;) |
| 15:34:18 | narimiran | and it sometimes work sometimes not on CIs |
| 15:35:15 | FromGitter | <kaushalmodi> narimiran: I get ⏎ ⏎ > Error: unhandled exception: int128.nim(552, 9) `arg < 0x47E0000000000000'f64` out of range [AssertionError] |
| 15:35:23 | narimiran | if somebody wants to take a look/guess, the offending line is in compiler/int128.nim:552 (assert(arg < 0x47E0000000000000'f64, "out of range")) |
| 15:35:27 | FromGitter | <kaushalmodi> (and I just rebuilt nim from devel few mins back) |
| 15:35:28 | narimiran | yep, that one :) |
| 15:35:52 | FromGitter | <kaushalmodi> I am on RHEL 6.8, 64-bit |
| 15:38:01 | narimiran | @kaushalmodi what is more interesting, on my system doing `static: assert not compiles(int64(NaN))` (unrolling the template) doesn't trigger the same error |
| 15:39:19 | disruptek | it breaks with a release compiler, not a dangerous one. |
| 15:39:25 | shashlick | @disruptek @Araq, instead of a new flag, why not fix the existing flags |
| 15:39:38 | disruptek | it would disrupt the behavior. |
| 15:39:47 | shashlick | --noNimblePath + --NimblePath => use just the nimble path provided |
| 15:40:05 | disruptek | --noNimblePath disables the nimble path globally. |
| 15:40:16 | disruptek | --clearNimblePath just empties it. |
| 15:40:31 | FromGitter | <kaushalmodi> shashlick: I also thought about that |
| 15:41:01 | FromGitter | <kaushalmodi> but then wanted the --noNimblePath if present in nim.cfg/config.nims to have absolute precedence over anything else |
| 15:44:39 | narimiran | disruptek: but why does it fail inside of a template, but it doesn't when i unroll it as written above? |
| 15:45:52 | FromGitter | <kaushalmodi> this works fine: ⏎ ⏎ ```template reject(y) = ⏎ static: assert(not compiles(y)) ⏎ ⏎ reject: ⏎ int64(NaN)``` [https://gitter.im/nim-lang/Nim?at=5dc2eab0bbdf5f17b420b8fa] |
| 15:46:08 | FromGitter | <kaushalmodi> I think that the `const x=.` part is causing problem |
| 15:46:28 | narimiran | huh, thanks for pinpointing it! |
| 15:47:32 | FromGitter | <zetashift> succesfully for me latest devel |
| 15:47:40 | narimiran | btw, according to git-bisect, this is the offending commit: https://github.com/nim-lang/Nim/commit/a2ad7d4883a450d66d1657c3550 |
| 15:47:58 | FromGitter | <kaushalmodi> @zetashift did you try narimiran's snippet or mine? |
| 15:48:06 | FromGitter | <zetashift> narimirans |
| 15:48:35 | narimiran | @zetashift and is your compiler compiled with `-d:danger`? if so, it might work (as disruptek says), without it it might fail |
| 15:49:05 | FromGitter | <zetashift> I'm not sure I just did, choosenim update devel |
| 15:49:17 | narimiran | what does the `nim -v` say? |
| 15:49:18 | disruptek | --version |
| 15:54:14 | * | Hideki_ quit (Remote host closed the connection) |
| 15:54:52 | * | Hideki_ joined #nim |
| 15:59:48 | FromGitter | <zetashift> Nvm it crashes on devel, when doing choosenim update devel, it prompted `Updated to devel`, which I thought it switched to devel but it was still on stable |
| 16:00:50 | * | Hideki_ quit (Ping timeout: 268 seconds) |
| 16:02:44 | * | oculux joined #nim |
| 16:02:50 | * | oculuxe quit (Ping timeout: 240 seconds) |
| 16:03:06 | * | Vladar joined #nim |
| 16:09:15 | * | theelous3 joined #nim |
| 16:09:24 | FromDiscord | <yewpad> ```nim |
| 16:09:25 | FromDiscord | <yewpad> import typetraits |
| 16:09:25 | FromDiscord | <yewpad> |
| 16:09:25 | FromDiscord | <yewpad> template typeNameOf(t: untyped): string = t.type().name() |
| 16:09:25 | FromDiscord | <yewpad> |
| 16:09:25 | FromDiscord | <yewpad> type Foo = object |
| 16:09:26 | FromDiscord | <yewpad> name: string |
| 16:09:27 | FromDiscord | <yewpad> primitive: bool |
| 16:09:28 | FromDiscord | <yewpad> |
| 16:09:30 | FromDiscord | <yewpad> proc main() = |
| 16:09:31 | FromDiscord | <yewpad> let x = 1 |
| 16:09:33 | FromDiscord | <yewpad> let foo = Foo(name: "Foo", primitive: false) |
| 16:09:34 | FromDiscord | <yewpad> |
| 16:09:35 | FromDiscord | <yewpad> echo typeNameOf(x) |
| 16:09:37 | FromDiscord | <yewpad> echo typeNameOf(foo) |
| 16:09:38 | FromDiscord | <yewpad> |
| 16:09:39 | FromDiscord | <yewpad> when isMainModule: |
| 16:09:41 | FromDiscord | <yewpad> main() |
| 16:09:42 | FromDiscord | <yewpad> ``` |
| 16:09:44 | FromDiscord | <yewpad> `Error: object constructor needs an object type` |
| 16:09:46 | FromDiscord | <yewpad> What am I missing here? Can't get this to compile |
| 16:09:51 | FromDiscord | <yewpad> ```nim |
| 16:09:51 | FromDiscord | <yewpad> import typetraits |
| 16:09:51 | FromDiscord | <yewpad> |
| 16:09:52 | FromGitter | <kaushalmodi> yeypad: please use a code scratchpad like ix.io |
| 16:09:53 | FromDiscord | <yewpad> template typeNameOf(t: untyped): string = t.type().name() |
| 16:09:54 | FromDiscord | <yewpad> |
| 16:09:56 | FromDiscord | <yewpad> type Foo = object |
| 16:09:57 | FromDiscord | <yewpad> name: string |
| 16:09:58 | FromDiscord | <yewpad> primitive: bool |
| 16:10:00 | FromDiscord | <yewpad> |
| 16:10:01 | FromDiscord | <yewpad> proc main() = |
| 16:10:02 | FromDiscord | <yewpad> let x = 1 |
| 16:10:04 | FromDiscord | <yewpad> let foo = Foo(name: "Foo", primitive: false) |
| 16:10:05 | FromDiscord | <yewpad> |
| 16:10:07 | FromDiscord | <yewpad> echo typeNameOf(x) |
| 16:10:08 | FromDiscord | <yewpad> echo typeNameOf(foo) |
| 16:10:09 | FromDiscord | <yewpad> |
| 16:10:11 | FromDiscord | <yewpad> when isMainModule: |
| 16:10:12 | FromDiscord | <yewpad> main() |
| 16:10:13 | FromDiscord | <yewpad> ``` |
| 16:10:15 | FromDiscord | <yewpad> `Error: object constructor needs an object type` |
| 16:10:17 | FromDiscord | <yewpad> What am I missing here? Can't get this to compile |
| 16:10:32 | disruptek | and don't edit your messages when you're on discord. |
| 16:10:33 | FromGitter | <zetashift> @yewpad can you pastebin your error and code? |
| 16:10:59 | clyybber | yewpad: Use play.nim-lang.org |
| 16:11:07 | FromGitter | <zetashift> ^ |
| 16:11:13 | FromGitter | <kaushalmodi> yes :) |
| 16:11:49 | FromDiscord | <yewpad> https://play.nim-lang.org/#ix=20Z9 |
| 16:12:17 | disruptek | don't call name(); just name. |
| 16:12:31 | disruptek | er, type. |
| 16:12:41 | FromDiscord | <yewpad> is "name" a field or proc |
| 16:12:46 | disruptek | doesn't matter. |
| 16:13:17 | FromGitter | <brentp> hi, i am trying to understand some simd stuff (I know there are wrappers in laser and other places). what is wrong with this code? https://play.nim-lang.org/#ix=20Za |
| 16:13:17 | FromGitter | <kaushalmodi> the issue is with using `name` as a field |
| 16:13:29 | FromGitter | <kaushalmodi> rename the `name` field in Foo to something else |
| 16:13:55 | FromDiscord | <yewpad> oof, aight. those error messages need to be improved imho |
| 16:14:22 | FromGitter | <kaushalmodi> also, you do not need typetraits |
| 16:14:24 | FromGitter | <kaushalmodi> this works: https://play.nim-lang.org/#ix=20Zb |
| 16:15:05 | FromDiscord | <yewpad> cool! still a newbie so bear with me |
| 16:15:18 | FromGitter | <kaushalmodi> no worries |
| 16:15:41 | FromDiscord | <krab4t> https://i.imgur.com/BbIUlen.png what is "nimproject" (qt-creator ide) |
| 16:17:17 | FromDiscord | <yewpad> are there any advantages using the cpp backend over let's say the c one? |
| 16:17:47 | FromGitter | <brentp> defers are much faster with cpp backend |
| 16:18:28 | disruptek | some exception misbehavior is impossible to replicate on the c backend. |
| 16:18:53 | lqdev[m] | that's not specific to defers, but rather to exceptions |
| 16:19:08 | FromDiscord | <yewpad> so i plan on writing an server orchestration software in nim. i know premature optimization is the devil but do i have to be mindful of whether I compile to the cpp backend or not |
| 16:19:32 | disruptek | if you have to ask, don't. |
| 16:19:37 | lqdev[m] | I wonder when will the cpp backend become default/considered stable |
| 16:19:40 | FromDiscord | <yewpad> i do like the 34kb hello world with the c backend 😅 |
| 16:20:49 | * | fredrik92 joined #nim |
| 16:21:37 | FromDiscord | <yewpad> are there any examples i can look at what the difference between exceptions from c and cpp backend is? |
| 16:21:59 | FromGitter | <alehander92> do you prefer |
| 16:22:05 | FromGitter | <alehander92> exceptions or error types |
| 16:22:13 | FromDiscord | <yewpad> i can't tell the difference |
| 16:22:33 | FromGitter | <alehander92> me too in detail hehe |
| 16:22:44 | clyybber | brentp: Hmm, looks correct to me |
| 16:22:44 | FromDiscord | <yewpad> i'd rather choose cpp if that means that may end up being able to fix something in my codebase |
| 16:22:45 | rayman22201 | I keep getting more confused. If I call deepDispose inside the async macro directly, it doesn't work. But if I make a wrapper proc that literally just calls deepDispose, it works... |
| 16:22:47 | FromGitter | <alehander92> but mostly like Result types |
| 16:22:49 | FromGitter | <alehander92> or something |
| 16:23:00 | clyybber | brentp: No idea why that would failr |
| 16:23:37 | FromGitter | <brentp> yeah. i can't get anything to work, even after copying what's in laser/simd |
| 16:23:39 | clyybber | rayman22201, Araq: You should join forces |
| 16:23:57 | clyybber | Maybe stream as you did that one time |
| 16:24:10 | clyybber | brentp: But using laser directly works? |
| 16:24:38 | rayman22201 | Lol. We already are. Araq is the one who told me to do my current experiment. 😝 |
| 16:24:45 | clyybber | ooh |
| 16:25:21 | rayman22201 | It's sooo close to working. There are just some weird bugs to work out. |
| 16:26:33 | FromDiscord | <mratsim> using laser directly is probably not supported :p |
| 16:26:49 | FromDiscord | <mratsim> there is a reason why it's not on nimble 😛 it's still aresearch repo |
| 16:26:52 | clyybber | use laser directly in your eye |
| 16:27:10 | FromDiscord | <mratsim> but I didn't catch what's your issue @brentp? |
| 16:27:11 | clyybber | mratsim: Not supported is better than not working :p |
| 16:27:19 | clyybber | mratsim: It segfaults |
| 16:27:29 | FromDiscord | <mratsim> what segfaults? |
| 16:27:41 | FromGitter | <brentp> @mratsim, my code example segfaults |
| 16:27:51 | FromDiscord | <mratsim> that probably has to do with alignment naively |
| 16:27:55 | FromGitter | <brentp> https://play.nim-lang.org/#ix=20Za |
| 16:28:24 | FromDiscord | <mratsim> AVX SIMD requires 16 bytes alignment |
| 16:28:33 | FromDiscord | <mratsim> use loadu instead |
| 16:28:39 | FromDiscord | <mratsim> for load unaligned |
| 16:29:40 | FromGitter | <brentp> aye. that works @mratsim. thanks |
| 16:29:48 | * | lritter joined #nim |
| 16:33:13 | * | narimiran quit (Ping timeout: 245 seconds) |
| 16:33:55 | FromDiscord | <yewpad> i wish there is some kind of documentation which lists the differences between the c and cpp backend. still can't tell the difference after a lot of googling. |
| 16:34:24 | FromDiscord | <mratsim> exceptions are using native C++, and the name mangling of proc |
| 16:34:49 | FromDiscord | <mratsim> oh and passing const references instead of pointers |
| 16:35:08 | Araq | rayman22201, dispose has nothing to do with my destructor bugs |
| 16:35:51 | Araq | I added 'dispose' to the stable technology in order to keep the number of variables low |
| 16:35:52 | FromDiscord | <yewpad> i was told that c can't replicate some fundemental c++ exception behavior. c would use error types and cpp would use cpp's exceptions. do the differ in any point when they're printed in the console. are there any visual changes or is it just for the sake of "api design"? |
| 16:36:50 | * | Hideki_ joined #nim |
| 16:36:53 | Araq | that said, you might want to use -d:useMalloc and valgrind |
| 16:37:14 | Araq | yewpad: to a good approximation the only difference is performance of the 'try' statement |
| 16:37:28 | FromDiscord | <yewpad> i don't really care about performance |
| 16:37:38 | FromDiscord | <yewpad> what i care about is file size... kinda |
| 16:37:45 | Araq | then use the default |
| 16:38:14 | FromDiscord | <yewpad> but it seems to me that the cpp target would be a lot more stable when it comes to nim's exception behavior |
| 16:38:54 | rayman22201 | I can see the leak without valgrind, but I just don't understand why it exists |
| 16:39:05 | rayman22201 | But I might try that as well |
| 16:39:43 | rayman22201 | I'm trying to figure out a minimal repro of what I'm seeing (outside of async) |
| 16:40:00 | * | rockcavera quit (Remote host closed the connection) |
| 16:40:02 | rayman22201 | It's proving difficult to do that |
| 16:40:20 | clyybber | rayman22201: Btw you can use gdb and valgrind together |
| 16:41:14 | FromDiscord | <mratsim> @yewpad, actually it's more buggy because of MSVC specialness wrt to exceptions |
| 16:41:23 | FromDiscord | <yewpad> hm |
| 16:41:26 | FromDiscord | <mratsim> if you don't use MSVC you'll be fine though |
| 16:41:31 | FromDiscord | <yewpad> i'll stick to the default target then |
| 16:41:33 | FromDiscord | <yewpad> for now |
| 16:41:56 | FromDiscord | <mratsim> see: https://github.com/nim-lang/Nim/issues/11846 |
| 16:41:57 | rayman22201 | Gdb might be useful to find my leaking string. Doesn't explain my other bug: why wrapping deepDispose in a wrapper proc changes it's behavior. |
| 16:41:58 | disbot | ^ Visual C++ exception message does not print, SIGABRT instead. |
| 16:41:59 | disbot | ^ snippet at https://play.nim-lang.org/#ix=20Zp 😏 |
| 16:43:15 | FromDiscord | <mratsim> basically the exception handler segfaults and doesn't print the exception message 😄 |
| 16:44:03 | * | Hideki_ quit (Ping timeout: 245 seconds) |
| 16:44:32 | clyybber | mratsim: That is fixed in 2019:3 Update of msvc |
| 16:44:36 | FromGitter | <brentp> here's a working avx2 example: https://play.nim-lang.org/#ix=20Zq |
| 16:47:21 | Araq | rayman22201, if you have X -> Y <- Z and deepDispose(X) and deepDispose(Z) then Y is freed twice |
| 16:47:52 | Araq | which then corrupts memory and so "putting stuff into a proc" can change the behaviour |
| 16:47:58 | disruptek | clyybber: see also https://github.com/nim-lang/Nim/issues/11081 |
| 16:47:59 | disbot | ^ DateTime field on Exception produces inconsistent C/++ handling |
| 16:47:59 | disbot | ^ snippet at https://play.nim-lang.org/#ix=20PX 😏 |
| 16:48:21 | Araq | maybe you need a multiDispose() that does this properly |
| 16:48:28 | rayman22201 | But I'm not doing that? |
| 16:48:47 | rayman22201 | Also, wouldn't that hit a gcAssert? |
| 16:50:43 | rayman22201 | Essentially, calling "deepDispose" directly causes it to act like regular "dispose". Calling "deepDispose" in a wrapper proc does the right thing |
| 16:51:50 | Araq | funny :-) |
| 16:52:05 | rayman22201 | I suppose that's minor. I can just leave the wrapper proc |
| 16:54:12 | * | nsf quit (Quit: WeeChat 2.6) |
| 17:00:34 | * | uu91 quit (Read error: Connection reset by peer) |
| 17:00:47 | * | uu91 joined #nim |
| 17:06:07 | Araq | ha, true, if it helps to get a result |
| 17:06:51 | FromGitter | <yorodm> Hello, any Windows 10 users around? |
| 17:08:08 | FromGitter | <yorodm> I'm having trouble building a library that depends on `[email protected]` |
| 17:09:22 | FromDiscord | <treeform> zip seems to have intermittent issues in windows, they get fixed then new ones happen... |
| 17:10:08 | Araq | zip suffers from "well it works on my machine so it must be good" |
| 17:10:22 | Araq | offtopic but too funny to miss: https://dilbert.com/strip/2019-11-05 |
| 17:10:25 | disruptek | you might want to try nimarchive instead. |
| 17:11:39 | shashlick | what's up gang - finally have some time to catch up |
| 17:11:59 | FromDiscord | <treeform> Good thing zip is only need for backward compatibility, there is so many better zipper now. I always use https://github.com/treeform/snappy so fast! |
| 17:12:38 | shashlick | i'm not a fan of adding more nimble related code into nim if we are trying to actually reduce that code |
| 17:12:44 | Araq | ah but this one is Nim-related: https://dilbert.com/strip/2019-10-29 |
| 17:12:50 | FromDiscord | <treeform> With snappy it is faster to read a compressed file than a non compressed file. |
| 17:13:10 | rayman22201 | I found my leaking string. But I don't have wifi were I'm at, so I can't send the code. Lol 😆 |
| 17:14:11 | clyybber | treeform: A bummer it doesn't support files > 2gb :p |
| 17:14:24 | rayman22201 | Setting the result in my async proc creates an intermediate string that dispose can't access |
| 17:14:31 | rayman22201 | Can't find I should say |
| 17:14:40 | clyybber | nevermind |
| 17:18:34 | FromDiscord | <Chiqqum_Ngbata> zstd is amazing |
| 17:22:33 | FromGitter | <yorodm> @Araq I seem to be missing a `zzip.dll` |
| 17:27:33 | * | abm quit (Remote host closed the connection) |
| 17:28:01 | * | abm joined #nim |
| 17:32:51 | * | abm quit (Ping timeout: 252 seconds) |
| 17:34:44 | FromGitter | <adam-r-kowalski> I just tried Nim version 1 and the compiler is crazy fast! It’s a joy to use, it seems like now it’s incremental? |
| 17:44:56 | rayman22201 | Nope. Just got better. |
| 17:45:08 | rayman22201 | Incremental is still coming |
| 17:45:58 | * | Hideki_ joined #nim |
| 17:50:16 | * | Hideki_ quit (Ping timeout: 240 seconds) |
| 17:53:28 | FromGitter | <adam-r-kowalski> Awesome! ⏎ ⏎ I’m using the json module and i’m curious about a few things. I want to convert a json object into one of my own types and I see that there is a `to` macro, but that seems to assume the field names are the same as the json object keys. What is the idiomatic way of converting to a object but hooking into the process? ⏎ ⏎ For now I wrote a `converter`which seems to work well. However, |
| 17:53:28 | FromGitter | ... one of my fields is a list of strings. Do you all just iterate over the values and then cast each one to a string then store that? Or is the a more idiomatic way of just passing in the desired type, and then using metaprogramming to figure out the necessary conversions [https://gitter.im/nim-lang/Nim?at=5dc30898a4541815c8a35253] |
| 17:56:19 | * | rockcavera joined #nim |
| 17:59:44 | shashlick | @kaushalmodi - why would you call Nim with --NimblePath if you don't want it |
| 18:00:09 | shashlick | I understand if you want to hard code --noNimblePath somewhere but if you are passing --NimblePath, it means you want it right |
| 18:02:03 | FromGitter | <kaushalmodi> shashlick: that's correct.. if I am passing --NimblePath then I intend to use it |
| 18:02:46 | FromGitter | <kaushalmodi> I have been thinking if the new --clearNimblePath adds a value vs modifying the behavior of existing --noNimblePath |
| 18:03:05 | FromGitter | <kaushalmodi> the main value I see is not surprising users by the change in behavior of --noNimblePath |
| 18:04:59 | shashlick | i don't see why --NimblePath is additive but that's probably around for a while |
| 18:05:45 | shashlick | it's simpler to have --noNimblePath do the clearNimblePath() and then any following --NimblePath should add again |
| 18:05:57 | shashlick | and we get rid of optNoNimblePath altogether |
| 18:06:30 | FromGitter | <kaushalmodi> shashlick: sounds good to me.. |
| 18:06:45 | FromGitter | <kaushalmodi> only concern is getting users be surprised by this change of behavior |
| 18:06:52 | FromGitter | <kaushalmodi> this should be noted well in the changelog |
| 18:08:45 | shashlick | i'm pushing back since I don't want more Nimble stuff in Nim - the direction we are going in is the opposite and there are potential solutions |
| 18:15:53 | disruptek | there's nothing nimble-ish about --clearNimblePath. |
| 18:17:13 | disruptek | you can complain that the compiler is specifying a path to Nimble, but you cannot also complain that we are removing that specification. |
| 18:17:21 | disruptek | pick one. |
| 18:18:04 | clyybber | why can't nimble use -p ? |
| 18:18:15 | disruptek | what's -p? |
| 18:18:19 | clyybber | --path |
| 18:18:21 | disruptek | it does. |
| 18:18:27 | disruptek | nimble doesn't even use nimblepath. |
| 18:18:30 | clyybber | ah |
| 18:18:33 | shashlick | what's wrong with modifying --noNimblePath to not disable, but just clear? |
| 18:18:34 | clyybber | right |
| 18:18:51 | disruptek | shashlick: you tell me. you're the one that uses nimble. |
| 18:19:38 | shashlick | i'm going tthrough he code history on the original motivation of --noNimblePath, in 2014 right now |
| 18:23:35 | shashlick | looks like https://github.com/nim-lang/Nim/commit/8c1ea5cb3f72901be47dc20366d228b0a1c9b417 is the commit |
| 18:23:47 | shashlick | @dom96 added it but unable to find the PR conversation so far |
| 18:24:03 | disruptek | who cares? |
| 18:24:58 | disruptek | feel free to make another PR to remove noNimblePath. you could also rewrite it to call clearNimblePath if you want. |
| 18:26:20 | shashlick | who cares - because before changing things, we need to understand why they were added in the first place |
| 18:27:08 | shashlick | i'm asking to change existing behavior which impacts legacy |
| 18:27:25 | disruptek | that's a discussion you can have with people using legacy package managers. |
| 18:27:30 | disruptek | this has nothing to do with that. |
| 18:27:45 | disruptek | it doesn't touch any code affecting any legacy package management solutions. |
| 18:28:01 | disruptek | it doesn't touch any code affecting any code affecting any legacy package management solutions, either. |
| 18:28:18 | shashlick | your PR is net new behavior which avoids the legacy discussion but will be yet more legacy that we need to reduce as part of reducing Nim's awareness of Nimble |
| 18:28:59 | disruptek | so you're saying that we can't reduce nim's reliance on nimble because that would be additional code that we'd need to reduce nim's reliance on nimble. |
| 18:29:02 | disruptek | makes perfect sense. |
| 18:29:16 | * | ng0 quit (Ping timeout: 260 seconds) |
| 18:29:47 | disruptek | i am sick of this community not improving its tooling because of handwavy fears. |
| 18:30:01 | Araq | disruptek, calm down please |
| 18:30:11 | disruptek | i'm as calm as can be. |
| 18:30:17 | shashlick | before you get frustrated, take the time to understand what i'm saying here |
| 18:30:40 | Araq | I'll merge your PR but --noNimblePath could clear the nimble path list |
| 18:30:44 | disruptek | i can't add code and i can't take code away. |
| 18:30:49 | shashlick | i'm trying to avoid more flags that work around the nim <-> nimble lock-in |
| 18:30:53 | FromGitter | <alehander92> @adam-r-kowalski |
| 18:31:05 | shashlick | but i'm talking about changing the existing code to fix the current behavior |
| 18:31:08 | disruptek | if you are willing to clear the path list, let's just do that. |
| 18:31:11 | Araq | but then this might break stuff so why not a new command line argument |
| 18:31:12 | FromGitter | <alehander92> is your problem |
| 18:31:17 | FromGitter | <alehander92> that you want different field names? |
| 18:31:27 | FromGitter | <alehander92> if so iirc there is wip work for that |
| 18:31:39 | shashlick | @Araq - the question is why anyone would want the current behavior |
| 18:31:49 | Araq | shashlick, nim.cfg gives it away |
| 18:31:52 | shashlick | why have --noNimblePath and yet add a --NimblePath |
| 18:31:52 | FromGitter | <alehander92> and also other libs https://github.com/status-im/nim-serialization |
| 18:32:17 | Araq | there is /opt/stuff also in your nimble path effectively giving us --global already |
| 18:32:21 | FromGitter | <alehander92> which has a json sub lib as well |
| 18:32:37 | shashlick | so that's why i was looking at the history of the add - it was added in 2013 for some issue or reason |
| 18:32:42 | FromGitter | <alehander92> not sure if the json `to` already supports that iirc @Vindaar worked or somebody? |
| 18:32:58 | shashlick | so before we add a new flag, we can at least understand if the current behavior is useless and can be changed or not |
| 18:33:07 | disruptek | --noNimblePath does something different from --clearNimblePath. |
| 18:33:11 | clyybber | we can add the current flag anyway |
| 18:33:14 | Araq | shashlick, https://github.com/nim-lang/Nim/blob/devel/config/nim.cfg#L49 |
| 18:33:17 | clyybber | and remove noNimblePath later on |
| 18:33:22 | clyybber | if it is really useless |
| 18:33:23 | disruptek | one option poisons nim against lazy paths, the other merely clears them. |
| 18:33:23 | Araq | we do understand why the current behavior exists |
| 18:33:53 | Araq | is anybody listening to me at all? |
| 18:33:55 | shashlick | how does that impact? |
| 18:34:16 | shashlick | if I set --noNimblePath in my cfg, are you saying the global nim.cfg will still add that nimblePath later on? |
| 18:34:22 | disruptek | if you poison your search paths, you cannot install arbitrary packages to your arbitrary nimble dir and have the compiler pick them up magically. |
| 18:34:23 | FromGitter | <kaushalmodi> Araq: If the vote matters, I am fine with changing the current behavior of --noNimblePath |
| 18:34:29 | shashlick | why would that get done after the user nim.cfg |
| 18:34:47 | Araq | the way things are done: |
| 18:34:54 | FromGitter | <kaushalmodi> actually the first thing I tried was doing --noNimblePath --NimblePath:asdfasdf assuming that I will be able to set paths afresh |
| 18:34:59 | disruptek | --noNimblePath prevents any use of lazy-load package directories. |
| 18:35:01 | Araq | - command line arguments are processed |
| 18:35:08 | Araq | - config files are processed |
| 18:35:19 | Araq | - command line arguments are processed *again* |
| 18:35:42 | Araq | because of @if defineStuff in the config etc |
| 18:36:18 | Araq | alternatively we could do a fixpoint iteration until no setting changes anymore :P |
| 18:36:36 | Araq | so the command line takes priority |
| 18:37:03 | clyybber | Araq: Is firstOrd and lastOrd the same as n[0].intVal and n[1].intVal for ranges? |
| 18:38:16 | clyybber | Ah got it. |
| 18:38:25 | clyybber | Was a bug on my end :D |
| 18:38:28 | shashlick | okay but will --clearNimblePath really work as expected then? will it still pick up some global nimblepath which was previously cleared |
| 18:39:12 | disruptek | it shouldn't matter to you; nimble uses --noNimblePath, which poisons the lazy-path search list anyway. |
| 18:39:29 | disruptek | as to whether it works, yes, it works. |
| 18:41:05 | shashlick | well, the naming is also mixed up --noNimblePath does what it says, but --nimblePath actually behaves like --addNimblePath |
| 18:42:06 | disruptek | if you want to help break the nim<->nimble link, how about renaming them to --addNimPath and --noNimPath and --clearNimPath? |
| 18:42:40 | * | nsf joined #nim |
| 18:42:46 | FromGitter | <kaushalmodi> disruptek: that would be confusing.. |
| 18:43:02 | FromGitter | <kaushalmodi> --nimblePath doesn't add just 1 path but paths of all packages under |
| 18:43:33 | * | nif quit (Quit: ...) |
| 18:43:36 | shashlick | well, --clearNimblePath solves it anyway, no need to break the --NimblePath legacy |
| 18:43:42 | * | nif joined #nim |
| 18:43:47 | disruptek | i agree. |
| 18:44:53 | Araq | well --nimblePath is a "smart path" |
| 18:45:07 | Araq | not really tied to the "Nimble" package manager all that much :P |
| 18:45:13 | Araq | so we can keep the name |
| 18:45:29 | shashlick | please understand that questions != handwavey fears |
| 18:45:46 | disruptek | yes, i'm just pointing out that it's obviously an inferior solution. |
| 18:45:54 | Araq | and #654 might be a deadend, yes --nimblePath causes trouble but as we have seen, not having it causes even more trouble |
| 18:46:20 | Araq | I don't want every Nim related tool to be invoked by Nimble instead, it's terrible |
| 18:46:27 | disruptek | it's just unassailably useful during development. is it required? not as long as we have a nim.cfg that works. but it's useful. |
| 18:46:30 | clyybber | why is it terrible? |
| 18:46:42 | clyybber | that would be exactly what I'd propose :P |
| 18:46:52 | Araq | it's bad enough already with Nimble's desire to hide the compiler's output from me |
| 18:47:04 | federico3 | yep |
| 18:47:07 | Araq | and with its reformatting of the compiler's error messages |
| 18:47:15 | federico3 | +1 |
| 18:47:26 | Araq | yay three dots in front of every line, thanks for nothing. |
| 18:47:35 | clyybber | thats a nimble problem though |
| 18:47:41 | disruptek | the compiler is a sophisticated program. it doesn't need nimble as a front-end. |
| 18:47:57 | clyybber | so why should the compiler accomodate for nimble, just because nimble isn't working as intended |
| 18:48:07 | disruptek | because nimble cannot be fixed. |
| 18:48:14 | clyybber | why? |
| 18:48:29 | rayman22201 | stupid question. what is the signature for `=` again? |
| 18:48:34 | rayman22201 | it's a hard to grep thing |
| 18:48:42 | clyybber | well |
| 18:48:47 | clyybber | the lhs has to be a var T |
| 18:48:48 | Araq | proc `=`(a: var T; b: T) |
| 18:48:51 | clyybber | and the rhs a T |
| 18:48:58 | * | krux02 joined #nim |
| 18:49:05 | clyybber | ^ |
| 18:49:06 | Araq | and it's actually easy to grep, 'proc `=`' with backticks |
| 18:49:30 | shashlick | @Araq - do you have time now to talk about the use case you want to enable in nimble |
| 18:49:51 | rayman22201 | `proc `=`(dst: var SomeObj; src: SomeObj) =` |
| 18:50:04 | rayman22201 | "proc `=`(dst: var SomeObj; src: SomeObj) =" |
| 18:50:36 | rayman22201 | I get: "/home/ray/Nim/Nim-devel/basicAsync.nim(6, 1) Error: signature for '=' must be proc[T: object](x: var T; y: T)" |
| 18:50:49 | rayman22201 | wat? |
| 18:51:09 | * | FromGitter quit (Read error: Connection reset by peer) |
| 18:51:27 | * | FromGitter joined #nim |
| 18:53:09 | Araq | rayman22201, SomeObj cannot be a 'ref' |
| 18:53:16 | Araq | shashlick, sure ok |
| 18:53:28 | rayman22201 | ah. ok |
| 18:53:32 | Araq | but dom96 isn't around |
| 18:53:39 | rayman22201 | The error should be better for that case. Just saying :-P |
| 18:54:20 | shashlick | ya but wanted to run some ideas by you while you are here |
| 18:55:03 | shashlick | so today, nimble develop only makes the project in question easy to develop per se |
| 18:55:09 | shashlick | it doesn't extend over to the deps |
| 18:55:55 | shashlick | what if nimble develop could be extended to mean local deps and each dependency would really be in nimble develop mode itself in the local deps folder |
| 18:56:23 | rayman22201 | Araq, any thoughts on this? http://ix.io/210p |
| 18:56:23 | disbot | ^ play at https://play.nim-lang.org/#ix=210p 😏 |
| 18:56:44 | shashlick | that way, everything is together and you can work on the main project and its dependencies simultaneously |
| 18:57:13 | shashlick | this is obviously different from the whole local deps RFC we have so far |
| 18:57:42 | shashlick | will this solution solve the problem you described earlier? |
| 18:58:12 | federico3 | what's the issue/PR #? |
| 18:58:13 | disruptek | this is what nimph does. |
| 18:59:13 | * | Hideki_ joined #nim |
| 18:59:22 | rayman22201 | output on the branch: Everything gets properly cleaned except for that one string https://www.irccloud.com/pastebin/XTjJX5nK/ |
| 19:00:03 | rayman22201 | using a non-seq based type allows everything to be disposed. no leaks |
| 19:01:49 | shashlick | @disruptek - which is why I don't believe that nimble cannot be improved |
| 19:02:02 | shashlick | everything comes with baggage |
| 19:03:41 | * | Hideki_ quit (Ping timeout: 246 seconds) |
| 19:03:50 | disruptek | well, i don't want to maintain my own fork of nimble. i would rather use a smaller program that i can modify and empower beyond what nimble is capable of. |
| 19:04:49 | clyybber | rayman22201: Hmm. Might be worth it to inspect the generated C code |
| 19:05:12 | disruptek | nimph is <500loc and already more useful to me than nimble itself. |
| 19:05:31 | shashlick | the thing is you have a good understanding of the problems and good ideas to solve them as well but without discussion and debating, you cannot get to consensus |
| 19:05:53 | disruptek | right, but you're missing a key point: |
| 19:05:57 | disruptek | i don't need concensus. |
| 19:05:58 | clyybber | shashlick: And thats why hes doing is own thing |
| 19:06:06 | clyybber | No problem with that |
| 19:06:23 | disruptek | you can look at my results and maybe it will help you with your debate club. |
| 19:06:29 | disruptek | in the meantime, i have software to write. |
| 19:06:37 | shashlick | this isn't a technical challenge, it is a people challenge |
| 19:06:50 | disruptek | yes, and i own my failure. |
| 19:06:57 | disruptek | i'm a bad person and a poor communicator. |
| 19:07:31 | rayman22201 | I'm able to replicate with a simple example: http://ix.io/210w |
| 19:07:32 | disbot | ^ play at https://play.nim-lang.org/#ix=210w 😏 |
| 19:07:38 | rayman22201 | *simpler |
| 19:08:08 | shashlick | i disagree with that, when you take the time, it is appreciated |
| 19:08:17 | rayman22201 | notice the same thing. In this case it's the "Buffer" object that leaks https://www.irccloud.com/pastebin/J1zPEwU8/ |
| 19:08:24 | shashlick | i've not seen any bullshit ideas from you |
| 19:08:35 | disruptek | well, told you i am always willing to look. |
| 19:09:08 | disruptek | at some point we have to accept that people will find new ways to use our software. |
| 19:09:12 | disruptek | we can support that, or not. |
| 19:09:25 | shashlick | why do you still think we aren't interested in supporting that |
| 19:09:43 | shashlick | these questions aren't to stop progress but to understand it |
| 19:10:05 | disruptek | i think 5 years of requests for the same feature are pretty tough to refute. |
| 19:10:24 | shashlick | it's not because they are bad ideas, it is because it takes time and effort |
| 19:10:32 | disruptek | not really. |
| 19:10:43 | clyybber | rayman22201: `=` is probably not called in `result = a` |
| 19:10:50 | clyybber | But `=sink` instead |
| 19:11:03 | shashlick | these issues would be closed if they were bad ideas |
| 19:11:41 | clyybber | shashlick: Point is, its a simpler dev cycle for disruptek |
| 19:11:47 | clyybber | productivity is higher |
| 19:12:07 | disruptek | it really doesn't matter why this stuff hasn't been implemented. |
| 19:12:24 | disruptek | yesterday i woke up and it didn't exist. today i woke up and it did. |
| 19:12:37 | shashlick | @clyybber - no one is arguing that |
| 19:13:16 | rayman22201 | @clyybber I just verified that my regular `=` proc is getting called |
| 19:13:31 | rayman22201 | but I'm not sure why it would matter |
| 19:14:02 | rayman22201 | I just added an `=destroy` proc as well. This also seems to get called. |
| 19:14:15 | rayman22201 | but the buffer does not get freed? |
| 19:14:29 | clyybber | rayman22201: Ok, it wouldn't matter probably |
| 19:14:42 | clyybber | rayman22201: GDB and valgrind to the rescue :p |
| 19:15:09 | shashlick | don't dismiss the efforts of building and maintaining a community, caring for history, backwards compatibility and interop |
| 19:15:25 | shashlick | it's not shiney, cool or fast moving |
| 19:15:41 | clyybber | shashlick: No one is dismissing that. |
| 19:15:57 | disruptek | it's great, but it doesn't solve our problems. |
| 19:16:06 | disruptek | it'd make a good book, but i don't want to live it. |
| 19:16:28 | clyybber | But people can do whatever they want, and that includes building their own package manager and solving problems that are bothersome to solve with "caring for history, backwards compatibility and interop" |
| 19:16:41 | clyybber | which IMO are all things which don't matter as much for Nim as for other langs |
| 19:16:56 | clyybber | Because old nim versions are really buggy |
| 19:18:25 | * | narimiran joined #nim |
| 19:18:28 | disruptek | and as a result, the compiler has two improvements waiting to go in. |
| 19:18:34 | disruptek | everyone wins. |
| 19:19:25 | rayman22201 | meh. I'm not so sure how much valgrind will help me here... maybe GDB though :/ |
| 19:20:01 | * | uu91 quit (Ping timeout: 268 seconds) |
| 19:21:32 | * | uu91 joined #nim |
| 19:21:45 | narimiran | @kaushalmodi if you're here and interested, here is what those echos in runnableExample of colors.nim print: https://travis-ci.org/nim-lang/Nim/jobs/608240630#L13873 |
| 19:21:52 | clyybber | rayman22201: Yeah valgrind might be a bit out of place here, still, you can run valgrind and GDB together, which is always better than gdb alone :p |
| 19:22:05 | narimiran | and you can also see that now another assert fails. (this is, again, only on 32-bit) |
| 19:22:08 | clyybber | although valgrind + gdb might be useful to find your other problem |
| 19:22:49 | narimiran | what should have been (r: 255, g: 0, b: 255) is (r: 0, g: 0, b: 0). fun fun fun |
| 19:25:15 | disruptek | that's a lot of fun. |
| 19:25:19 | rayman22201 | lol. clyybber. valgrind + gdb, the magic super team :-P |
| 19:28:53 | Araq | rayman22201, dispose does *not* free the attached string |
| 19:28:58 | Araq | deepDispose would |
| 19:29:16 | rayman22201 | I tried both. Neither works |
| 19:29:24 | Araq | ha |
| 19:29:31 | Araq | ut deepDispose is supposed to work! |
| 19:29:39 | Araq | so now you found your easy test case |
| 19:29:46 | rayman22201 | Lol 😆 |
| 19:30:12 | Araq | shashlick, I suspect it would work but it feels like more workarounds for Nimble not doing the right thing |
| 19:30:21 | FromGitter | <kaushalmodi> narimiran: so they are all (r,g,b) zeroes! |
| 19:30:27 | FromGitter | <kaushalmodi> but not on 64-bit |
| 19:30:32 | shashlick | @Araq - what should it do then? |
| 19:30:33 | narimiran | yep |
| 19:31:03 | Araq | shashlick, if nimbledeps/ exists it should use and 'git clone' into it |
| 19:31:13 | Araq | that would solve *all* of my problems |
| 19:31:15 | shashlick | workflow simply would be to `nimble develop` the main project and after that everything will be local and in develop mode |
| 19:31:28 | shashlick | no special actions to do to maintain it |
| 19:31:41 | Araq | there would still be the tension between 'nimble install' and 'git clone' otherwise |
| 19:31:59 | shashlick | nimble develop already does git clone |
| 19:32:04 | shashlick | we just leverage that functionality |
| 19:32:41 | Araq | I only used 'nimble develop' without further args, what does it mean "it does git clone"? |
| 19:33:57 | shashlick | you can do `nimble develop packagename` or `nimble develop URL` and it will clone locally |
| 19:34:23 | shashlick | or if you manually checked out your repo, you nimble develop and it will get setup for local deps |
| 19:34:41 | shashlick | in either case, you have your main project with full source control |
| 19:35:04 | shashlick | i'm proposing to extend nimble develop to develop all deps locally so everything will have full source control right there |
| 19:37:55 | Araq | yes |
| 19:38:04 | Araq | that sounds good |
| 19:38:25 | * | abm joined #nim |
| 19:38:32 | Araq | so if I do 'nimble develop foobar' does it create foobar/deps for me? |
| 19:38:33 | shashlick | Will that solve your use case 100% |
| 19:38:45 | shashlick | Not today but that's the proposal |
| 19:39:05 | shashlick | And it won't just install deps usual |
| 19:39:17 | clyybber | Araq: Here I go refactoring semobjconstr, haha |
| 19:39:18 | shashlick | It will actually setup each dep in develop mode |
| 19:40:09 | shashlick | Also, if you need to work on a fork of a dep, we will have to enable that too |
| 19:40:51 | clyybber | Araq: Btw, I'm making the case detection for object variant constructors a bit smarter, it will now work for range types too. |
| 19:41:10 | Araq | clyybber, I like it but I hope you can help me with --gc:destructors soon |
| 19:41:25 | Araq | would be such a nice christmas gift *cough* |
| 19:41:53 | Araq | shashlick, that solves my problems as far as I can overlook it. |
| 19:42:32 | clyybber | Araq: Ha, sure. Maybe I'll have a bit more time soon TM |
| 19:42:44 | Araq | however I'm a bit skeptical that my $nimbledir is full of develop overrides whereas I could set my $nimbledir to nimbledeps/ instead |
| 19:43:07 | Araq | and bypassing that logic, it's a legacy for me |
| 19:43:39 | Araq | but I can do that on my own in my nim.cfg, so whatever |
| 19:45:13 | * | jwm2241 joined #nim |
| 19:45:37 | clyybber | Araq: Can you refresh me on whats to do for --gc:destructors? |
| 19:46:07 | Araq | shashlick, actually thinking about it. the overrides in $nimbledir does cause harm |
| 19:46:27 | Araq | because my package local deps should not influence the builds of my other projects |
| 19:46:50 | Araq | clyybber, implementation is complete, left to do: bugfixes. tons of them. |
| 19:47:55 | clyybber | And GordonBGood is working on brining seqsv2 to every gc? |
| 19:48:54 | Araq | yeah and also reporting bugs |
| 19:51:33 | * | nc-x joined #nim |
| 19:52:11 | nc-x | well if the goal is to remove all gc's except destructors and boehm, then why go through all the effort to port seqsv2 to other gc's? |
| 19:52:39 | * | nc-x quit (Remote host closed the connection) |
| 19:53:32 | Araq | nc-x[m], risk mitigation, "let the perfect not be the enemy of the good", etc |
| 19:54:52 | shashlick | @Araq - not sure i'm getting what you are saying |
| 19:55:33 | shashlick | i understand you value the isolation since you are actually developing the deps themselves in parallel with the main project |
| 19:56:38 | shashlick | that wasn't identified in the original motivation of local deps |
| 19:56:51 | Araq | shashlick, I install package P, it has dependency D. Now D ends up in .nimble/pkgs/D-#head/D.nimble-link |
| 19:57:09 | Araq | s/install/nimble develop |
| 19:57:20 | shashlick | yes that's why this proposal includes local deps for nimble develop |
| 19:57:37 | Araq | now if I compile P2 that depends on D too, D-#head is used |
| 19:57:48 | Araq | but that's not what I want |
| 19:58:12 | Araq | furthermore if I nimble develop P2 I would get 2 conflicting D-#heads in my $nimbledir |
| 19:58:29 | Araq | not good. |
| 19:58:47 | Araq | $nimbledir must not be used at all and then stuff works properly |
| 19:59:16 | shashlick | but that's what i mean by local deps - all deps will go into $prj/deps if the project is setup with `nimble develop` |
| 19:59:28 | shashlick | $nimbleDir won't be used |
| 19:59:37 | Araq | ah ok, good |
| 19:59:41 | Araq | then we agree. |
| 19:59:50 | shashlick | that way you get the isolation since you could potentially work on the dep as well which will impact other projects |
| 20:00:12 | shashlick | the other question is whether every single dep should be in develop mode by default or if you will pick and choose |
| 20:00:31 | * | actuallybatman joined #nim |
| 20:00:32 | Araq | every single dep. |
| 20:00:45 | Araq | I can't choose since I don't know anyway when I start to work. |
| 20:00:45 | shashlick | and if you need a fork to actually modify them? |
| 20:01:06 | Araq | if I fork, I can patch my .git config to point to my fork |
| 20:01:24 | Araq | support for that can come later, it's not as important |
| 20:01:32 | shashlick | okay cool |
| 20:01:59 | shashlick | okay this seems simpler since it is isolated to `nimble develop` |
| 20:02:22 | disruptek | yes, it's quite simple. but it doesn't matter how simple it is. |
| 20:02:40 | Araq | well it would be a 'nimble deepdevelop' command :P |
| 20:02:53 | Araq | I doubt you can change the existing 'develop' setup |
| 20:02:56 | rayman22201 | lol. Araq loves the word "deep" :-P |
| 20:03:21 | Araq | I took it from "deep learning" |
| 20:03:24 | shashlick | i'll go through the details and see what the impact will be - right now i think it is possible |
| 20:03:34 | disruptek | oh, i thought it was from `deep penetration`. |
| 20:03:51 | disruptek | i learned it from `deepthroat`, myself. |
| 20:03:58 | Araq | oh come on now |
| 20:04:00 | shashlick | @disruptek - if you don't want to contribute then i'll appreciate you keep your snide comments to yourself |
| 20:04:19 | disruptek | fair enough. |
| 20:05:28 | Araq | disruptek, I merged your PR already because you said you tested it |
| 20:05:33 | Araq | ;-) |
| 20:05:50 | disruptek | thanks. the oss mantra: `it works for me.` |
| 20:05:52 | Araq | but please fix it once the bugs about it arrive |
| 20:06:15 | disruptek | okie. |
| 20:06:32 | shashlick | @Araq - now that I understand that, did you have any feedback on the lock files proposal i shared? |
| 20:07:18 | Araq | I replied, look at your gist |
| 20:09:01 | Araq | and since we're at it, my nimbledir has 149 directories |
| 20:09:32 | Araq | 5x regex-$version, 5 different versions of the 'regex' package |
| 20:10:08 | Araq | what exactly is "shared" here? it's accumulated cruft. |
| 20:10:13 | * | nsf quit (Quit: WeeChat 2.6) |
| 20:10:52 | shashlick | so the lock file RFC I shared is effectively using nim.cfg to tell Nim about paths |
| 20:10:58 | shashlick | so nimsuggest will just inherit it right? |
| 20:11:06 | Araq | right |
| 20:11:41 | shashlick | so nimble does not need to control nimsuggest, it simply creates the lock file and nim knows what to do |
| 20:12:30 | * | GordonBGood joined #nim |
| 20:12:54 | Araq | yes but I fear you're missing the "I'm in control" point |
| 20:13:25 | Araq | don't create a new file that is "managed" by Nimble, use the existing nim.cfg mechanism |
| 20:13:48 | shashlick | it is a new file only by name, not by format |
| 20:13:59 | Araq | generate comments like # Nimble section begin |
| 20:14:02 | Araq | # Nimble section end |
| 20:14:16 | Araq | and I *will* modify these myself too |
| 20:14:43 | Araq | "only by name" is already the damage I'm talking about |
| 20:15:09 | shashlick | ok new file just simplified it with existing packages out there with a nim.cfg at the root but i guess we can do it |
| 20:15:13 | clyybber | Hi GordonBGood |
| 20:15:45 | disruptek | i'm doing lockfiles in the same nim.cfg. |
| 20:16:07 | FromDiscord | <IanIAnIAN> Hello World |
| 20:17:12 | clyybber | !eval echo"Hello World" |
| 20:17:15 | NimBot | Hello World |
| 20:18:00 | shashlick | Araq: any other feedback? |
| 20:18:43 | Araq | shashlick, nitpick, Nimble must also emit --noNimbleDir |
| 20:18:55 | Araq | otherwise it won't work out |
| 20:19:05 | Araq | but I'm sure you know :-) |
| 20:19:36 | shashlick | i had added that under the Nim changes but with the new nim.cfg method, we will have to include it in the file |
| 20:20:04 | Araq | and we need to close #654 then, it bites with all the other designs |
| 20:20:20 | Araq | right? |
| 20:20:46 | shashlick | well once lock files become the norm, we can eventually remove the entire nimbleDir scan since paths will be specified in nim.cfg |
| 20:21:08 | Araq | hmmm ok |
| 20:21:34 | shashlick | which is why i was debating --NimblePath and --clearNimblePath |
| 20:21:37 | Araq | makes sense, however deps/ reintroduces the requirement for --nimblepath |
| 20:23:16 | shashlick | yes, i'll have to see how the `nimble develop` changes impacts lock files |
| 20:23:51 | shashlick | today nimble develop doesn't store enough package details to know which release it is |
| 20:24:21 | GordonBGood | Hi clyybber |
| 20:25:03 | shashlick | the lock file proposal from @zah covers some of that so i need to see how it can be done |
| 20:27:12 | Araq | as I said, I think 'nimble develop' cannot do it, it needs to be at least 'nimble develop --all' |
| 20:27:43 | shashlick | will you expect to create lock files in that state? |
| 20:28:12 | Araq | personally I don't care about lock files :-) |
| 20:28:25 | Araq | but consider this: |
| 20:28:35 | disruptek | https://github.com/nim-lang/nimble/compare/master...bobeff:feature/lock-file |
| 20:29:07 | Araq | I will *teach* others to use 'nimble deepdevelop foobar' because it's the best way to get work done |
| 20:29:41 | Araq | so the need for lockfiles for deepdevelop will probably emerge |
| 20:30:45 | shashlick | yup |
| 20:32:10 | * | NimBot joined #nim |
| 20:33:17 | Araq | my suggestion: use 'nimble clone foobar' for this new way of deep cloning things |
| 20:33:36 | Araq | it's short and I can remember it |
| 20:36:52 | * | eys quit (Quit: eys) |
| 20:47:05 | GordonBGood | clyybber: just finished scanning the logs, as Araq says, looking for and finding bugs in --gc:destructors also perculating elsewhere, maybe |
| 20:50:31 | FromDiscord | <krab4t> what you use for CLI tool arguments ` parseopt `? |
| 20:50:36 | disruptek | cligen |
| 20:50:57 | FromDiscord | <krab4t> sub 1 second answer are you bot? |
| 20:51:57 | disruptek | nah. |
| 20:52:04 | * | GordonBGood_ joined #nim |
| 20:53:52 | * | krux02 quit (Remote host closed the connection) |
| 20:54:08 | * | GordonBGood quit (Ping timeout: 265 seconds) |
| 20:56:05 | shashlick | Araq - I've updated the lock file RFC with our discussion - https://gist.github.com/genotrance/d07bfabd9ef8f66450c7e9732ffaf6f4 |
| 20:58:05 | disruptek | why would we want to remove --nimblePath? |
| 20:58:30 | dom96 | oh dear, looks like I missed a lot of discussion |
| 20:58:38 | dom96 | Anyone have a TL;DR? |
| 20:59:05 | disruptek | did you read the gist? |
| 20:59:38 | FromGitter | <alehander92> https://github.com/iffy/nim-argparse |
| 20:59:39 | FromGitter | <alehander92> as well |
| 20:59:43 | FromGitter | <alehander92> krab4t ^ |
| 20:59:47 | dom96 | disruptek, nope, I shall do that now |
| 20:59:53 | FromGitter | <alehander92> (its good as well, not that i use ) |
| 21:04:39 | * | Hideki_ joined #nim |
| 21:05:04 | shashlick | @dom96 - discussed the lock file gist as well as what Araq's real motivation is for local deps |
| 21:05:18 | shashlick | https://irclogs.nim-lang.org/06-11-2019.html#18:49:30 is the logs for the latter |
| 21:05:25 | shashlick | i've not documented it yet |
| 21:05:37 | shashlick | the lock file gist is up to date after conversation with Araq |
| 21:06:31 | shashlick | @disruptek - once Nimble informs Nim of which packages to load by nim.cfg, nim no longer needs to scan nimble paths |
| 21:08:10 | shashlick | of course, it still needs to know the base nimble path to substitute in nim.cfg paths, so i'm not so sure anymore |
| 21:08:40 | disruptek | yes, but the functionality imparted by --nimblePath is useful outside of localdeps and outside of nimble. |
| 21:09:41 | * | Hideki_ quit (Ping timeout: 276 seconds) |
| 21:11:26 | shashlick | why would that be useful? nim already gives you the ability to tell it all the paths |
| 21:12:06 | disruptek | you've never wanted to write nim and perform an import without nimble? |
| 21:15:01 | FromGitter | <brentp> i ported my algorithm to avx512 and it gave basically no speedup: https://play.nim-lang.org/#ix=211h . probably need to move the popcounting to the end |
| 21:19:13 | shashlick | no good answer for that but wanting to use a package installed by a package manager without running the package manager once in the project means Nim maintains its basic algorithm of search which is disconnected from package manager evolution |
| 21:19:58 | disruptek | nim's basic ability to add a directory's contents to its search path is a useful feature. why do you want to take it away from users? |
| 21:20:07 | disruptek | what did they ever do to you? |
| 21:20:15 | shashlick | --path is still there right |
| 21:22:00 | disruptek | the question remains. |
| 21:25:07 | dom96 | It would be silly to remove --path, I don't see why you'd ever do that |
| 21:26:26 | * | GordonBGood_ quit (Ping timeout: 268 seconds) |
| 21:26:50 | Araq | nobody will remove --path but disruptek enjoys --nimblePath and wants it to remain |
| 21:27:01 | shashlick | i'm just reflecting https://github.com/nim-lang/nimble/issues/654 |
| 21:27:23 | shashlick | if there's a super important reason to retain that legacy behavior when even nimble potentially won't need it then so be it |
| 21:27:53 | dom96 | Are you still referring to `--path`? |
| 21:27:54 | disruptek | why does it have to be "super important"? it's not hurting anyone. what hurts is providing features and then taking them away. |
| 21:28:52 | shashlick | no i am talking about the --Nimble* flags in Nim |
| 21:29:14 | Araq | disruptek: sure but it helps to know about their general usefulness |
| 21:29:24 | Araq | so that we don't remove useful things. |
| 21:29:42 | shashlick | anyway, it isn't the focus of that RFC, it is in the future if it is useful |
| 21:29:48 | disruptek | well, considering that virtually everyone uses it right now, i wouldn't think that i'd need to explain its usefulness. |
| 21:29:59 | dom96 | https://internals.rust-lang.org/t/cargo-global-package-installation/1510 |
| 21:30:03 | shashlick | it would be a 2.x change if anything |
| 21:30:21 | dom96 | Here is someone who presumably never heard of Nim asking the Rust community why they don't have the equivalent of --nimblePath |
| 21:30:29 | dom96 | That should prove its usefulness |
| 21:33:08 | * | clyybber quit (Quit: WeeChat 2.6) |
| 21:33:37 | rayman22201 | interesting... sure makes it seem like the flag has outgrown it's name.... seems bigger than nimble... |
| 21:34:08 | rayman22201 | but probably not worth changing the name at this point :-P |
| 21:36:07 | * | narimiran quit (Ping timeout: 250 seconds) |
| 21:42:27 | shashlick | @dom96 - any other comments on the proposal |
| 21:42:51 | dom96 | yes, I have quite a few, but in the interest of time I'll highlight just one thing |
| 21:43:04 | * | couven92 quit (Disconnected by services) |
| 21:43:08 | * | fredrik92 is now known as couven92 |
| 21:43:31 | * | fredrik92 joined #nim |
| 21:48:01 | FromDiscord | <mratsim> @brentp, did you try with AVX256 first? |
| 21:48:24 | FromDiscord | <mratsim> because AVX512 produces so much heat that CPU can downscale by 1GHz |
| 21:48:45 | FromDiscord | <mratsim> even my own CPU with liquid cooling needs to scale down by 500MHz with AVX512 otherwise it may shutdown |
| 21:49:58 | FromDiscord | <mratsim> if it's super perf critical, open an issue in Laser and I will give see what I can do |
| 21:50:40 | FromDiscord | <mratsim> also it seems like you are doing 4 reductions? |
| 21:50:45 | Araq | lol wtf |
| 21:52:19 | FromDiscord | <mratsim> in that case the bottleneck is not popcount but the reduction, they have carried dependency and you need multiple accumulators that are joined at the end if you want performance, you can run this bench as an example: https://github.com/numforge/laser/blob/master/benchmarks/fp_reduction_latency/reduction_bench.nim |
| 21:52:35 | * | freddy92 joined #nim |
| 21:53:06 | FromDiscord | <mratsim> carried dependency meaning that the processor has to stall for the result of previous compute before doing the next operation, even though it could do more |
| 21:53:11 | * | couven92 quit (Disconnected by services) |
| 21:53:19 | * | freddy92 is now known as couven92 |
| 21:54:05 | FromDiscord | <mratsim> everything is explained in the comments at the beginning of the file |
| 21:54:06 | FromGitter | <brentp> @mratsim . i did not |
| 21:54:51 | FromDiscord | <mratsim> try -fast-math first |
| 21:55:22 | FromDiscord | <mratsim> you will quickly see if it's avx downscaling (fast math doesn't help) or reduction latency (fast math helps tremendously) |
| 21:55:33 | dom96 | shashlick: replied |
| 21:56:15 | FromDiscord | <mratsim> with fast-math the compiler will consider that floating point addition is associative and will create extra reduction accumulators for your convenience |
| 21:56:56 | FromDiscord | <mratsim> but due to rounding and precision loss it needs to be opt in |
| 22:15:16 | * | solitudesf quit (Ping timeout: 240 seconds) |
| 22:19:24 | * | Vladar quit (Remote host closed the connection) |
| 22:21:55 | FromGitter | <brentp> ok @mratsim, I'll have a look. i'm not using FP, only integers . does that make a difference? |
| 22:23:23 | FromGitter | <mratsim> Yes, compiler doesn't need fast math to rearrange and optimize reductions |
| 22:23:29 | FromGitter | <mratsim> So it's something else |
| 22:23:46 | FromGitter | <brentp> i read that downscaling was less likely for the instructions i was using |
| 22:26:37 | FromGitter | <brentp> no effect from fast-math |
| 22:34:51 | FromGitter | <brentp> re doing 4 reductions, yes, I think that might be the problem.--especially since they are popcounts |
| 22:37:16 | * | a_b_m joined #nim |
| 22:39:24 | * | uu91 quit (Ping timeout: 252 seconds) |
| 22:41:03 | * | abm quit (Ping timeout: 268 seconds) |
| 22:41:16 | * | uu91 joined #nim |
| 22:45:20 | FromGitter | <brentp> so for multiple accumulators, you mean i basically unroll the loop and do e.g. 4 * 8 reductions to 8 different accumulators? |
| 22:48:40 | shashlick | @dom96 - still here? |
| 22:52:48 | * | jjido joined #nim |
| 22:59:13 | FromGitter | <brentp> @mratsim, seems like that benchmark is stale. complains about `raw_data`https://gist.githubusercontent.com/brentp/11a497dd5961c8340ddf05b89fef85a1/raw/8b9afac4858260ce391e0fdfd111334d63616a05/avx512_experiments.nim |
| 23:00:13 | FromGitter | <brentp> ok. found `.raw_buffer` |
| 23:03:31 | FromGitter | <kaushalmodi> What did I miss now? --nimblePath on chopping block? Why? |
| 23:04:09 | FromGitter | <kaushalmodi> It allows to add all the packages in a nimble path with just one switch, instead of manually adding the paths one by one using --path |
| 23:04:32 | FromGitter | <kaushalmodi> Araq: ^ |
| 23:05:50 | Araq | just forget it. |
| 23:06:08 | Araq | we know what --nimblePath is and it stays. |
| 23:06:41 | * | krux02 joined #nim |
| 23:07:02 | FromGitter | <kaushalmodi> Phew |
| 23:07:32 | * | xace quit (Ping timeout: 265 seconds) |
| 23:08:17 | FromGitter | <alehander92> https://internals.rust-lang.org/t/idea-introduce-project-field-to-cargo-toml-to-make-micro-crate-designs-less-scary/10895 |
| 23:08:28 | FromGitter | <alehander92> i have to admit, i saw the idea of `packs` appearing here |
| 23:08:33 | FromGitter | <alehander92> which sounds a lot like distributions |
| 23:09:01 | FromGitter | <kaushalmodi> Araq: btw I figured out how to run valgrind through the SystemVerilog compiler. I'll later post the log .. it mentioned something realized to "jumps to uninitiated variables" or something like that from gc.nim and gc_common.nim |
| 23:11:18 | shashlick | @dom96 - replied |
| 23:14:44 | dom96 | what? You're proposing that `nimble install` will edit the .nimble file now? |
| 23:18:03 | shashlick | eventually |
| 23:18:24 | shashlick | just like package.json gets updated |
| 23:18:46 | dom96 | I replied to one of your other points because I'm rather puzzled now |
| 23:19:46 | * | ng0 joined #nim |
| 23:19:51 | shashlick | I'm saying we don't need to force the user to use the package manager **all** the time but only when deps change |
| 23:19:58 | shashlick | it is a better middle ground to allow both camps to coexist |
| 23:20:05 | shashlick | pure nim and pure nimble |
| 23:20:22 | shashlick | most of the times, when deps change, it gets done automatically |
| 23:21:03 | shashlick | it is only when it happens with manual editing |
| 23:21:20 | shashlick | which gets further reduced with auto updating .nimble |
| 23:21:42 | shashlick | so i'm all for supporting both workflows |
| 23:21:42 | dom96 | I cannot imagine how auto updating .nimble would work |
| 23:22:00 | shashlick | i know it will be challenging cause it is code |
| 23:22:51 | dom96 | I guess `nimble require pkg@">= 1.0 & < 2.0"` would work |
| 23:23:33 | shashlick | don't even need that cause when you install a dependency in a project, you know what the package name is and the latest version |
| 23:23:38 | dom96 | but I don't understand what's so controversial about what we have now |
| 23:23:47 | dom96 | Don't care about dependency versions? Use Nim |
| 23:24:02 | dom96 | Do care about dependency version? Create a .nimble file and use nimble |
| 23:24:13 | dom96 | It's simple and it works. |
| 23:24:30 | shashlick | `nimble install abc` => add `requires "abc >= version installed" |
| 23:24:41 | shashlick | if user wants more nuance, they can hand edit and run `nimble install -d` |
| 23:25:26 | dom96 | I'm happy with this but not under `nimble install` |
| 23:26:27 | shashlick | so if a user installs a dep in a project, it means they want to add it to that project right |
| 23:26:33 | FromGitter | <Vindaar> @alehander92 @adam-r-kowalski yes, I worked on that JSON PR to add custom field names. Will pick it up again very soon. Should be simpler now with both the `to` macro refactored and the changes to `hasCustomPragma` |
| 23:27:00 | dom96 | shashlick: not always, I might just be installing a utility that I want to use on my system |
| 23:27:13 | dom96 | and happen to be inside a folder with a Nimble package |
| 23:27:30 | dom96 | what's the problem with having a separate command for this? |
| 23:31:47 | shashlick | a --save like npm? |
| 23:32:04 | shashlick | i'm just like if you are in a project folder, it means you want to work on it |
| 23:33:56 | shashlick | okay so that's just command line nuance |
| 23:36:11 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 23:36:40 | * | uvegbot quit (Ping timeout: 264 seconds) |
| 23:36:41 | dom96 | shashlick: other than not wanting to change how Nim users build code, do you have other objections to encouraging use of `nimble c`, `nimble check` etc? |
| 23:38:12 | shashlick | i already use nimble most of the time but there's a whole camp of people who love nim pure |
| 23:38:35 | shashlick | there's no changing minds when a middle ground is possible |
| 23:38:46 | shashlick | that's always my philosophy |
| 23:43:20 | shashlick | are you warming up to the nim.cfg method or no luck? |
| 23:47:32 | rayman22201 | araq, clyybber, check this out: http://ix.io/212d |
| 23:47:32 | disbot | ^ play at https://play.nim-lang.org/#ix=212d 😏 |
| 23:47:56 | rayman22201 | is the `=` proc "special" in some way? |
| 23:48:06 | rayman22201 | If I use "assign" instead, I don't leak |
| 23:50:02 | rayman22201 | I don't understand deepDispose well enough. Is it possible that `=` is missing something necessary to make deepDispose work? |
| 23:51:02 | rayman22201 | cc @GordonBGood |
| 23:55:39 | * | Hideki_ joined #nim |
| 23:56:51 | rayman22201 | @araq, can you explain the changes you made to compiler/vmgen.nim in the PR here: https://github.com/nim-lang/Nim/pull/12512/files? |
| 23:56:57 | rayman22201 | maybe that's related |
