00:00:04 | shashlick | Presume you are with devel |
00:00:32 | FromDiscord | <j$> devel? |
00:00:34 | FromDiscord | <j$> im on windows |
00:00:38 | shashlick | Ok I'm not home yet but I'll get you up and running |
00:00:45 | shashlick | What version of Nim |
00:00:52 | FromDiscord | <j$> 19.4 |
00:01:05 | FromDiscord | <j$> but im on choosenim |
00:01:16 | FromDiscord | <j$> dunno if that changes anything |
00:01:33 | shashlick | Did c2nim install |
00:01:40 | shashlick | That's fine |
00:02:26 | * | rnrwashere joined #nim |
00:05:29 | * | vlad1777d joined #nim |
00:06:16 | * | rnrwashere quit (Remote host closed the connection) |
00:06:29 | * | rnrwashere joined #nim |
00:09:01 | rayman22201 | yup. Just verified that pulling nimpcre from git instead of nimble works on both 0.19.4 and devel |
00:09:23 | rayman22201 | yay, more nimble bugs :-P |
00:11:32 | * | i7sDream joined #nim |
00:13:12 | shashlick | That's an old one |
00:13:36 | FromDiscord | <j$> does it matter where I clone it to? |
00:14:03 | rayman22201 | anywhere but `.nimble\pkgs` |
00:14:06 | * | Cthalupa quit (Ping timeout: 252 seconds) |
00:14:53 | rayman22201 | I vaguely remember the issue, but I don't remember what the bug acutally is. pre-install tasks don't run or something? |
00:15:49 | * | Cthalupa joined #nim |
00:15:56 | * | i7sDream quit (Ping timeout: 246 seconds) |
00:16:01 | FromDiscord | <j$> umm is there an issue with 0.19.4 on windows? |
00:16:13 | FromDiscord | <j$> I cannot get it to install |
00:18:50 | rayman22201 | j$, no, 0.19.4 should work fine on windows. But I thought you already had nim installed? |
00:19:02 | rayman22201 | I thought you were using choosenim? |
00:19:17 | rayman22201 | we mean git clone `nimpcre`, not nim itself. |
00:19:56 | FromDiscord | <j$> yeah I know, I wanted to switch back, but I guess Ill go back to choosenim |
00:20:03 | FromDiscord | <j$> oh wait |
00:20:31 | FromDiscord | <j$> I could get dlls to load in my executable with choosenim for some reason |
00:20:45 | FromDiscord | <j$> I dont even know if those things are related |
00:22:42 | rayman22201 | now I'm confused.... It sounds like you are changing too many things at once here. |
00:23:02 | FromDiscord | <j$> okay |
00:23:14 | FromDiscord | <j$> ill be back |
00:23:57 | rayman22201 | *obligitory Arnold Schwarzenegger voice* |
00:25:28 | FromDiscord | <j$> okay so I am installing choose nim rn, when im finished with that I will redo git clone of nimpcre then ill let you guys know what the deal is |
00:26:54 | rayman22201 | cool. good luck. hopefully it will go smoother this time |
00:28:23 | FromDiscord | <j$> installed nim w/choosenim |
00:29:45 | FromDiscord | <j$> installed nimpcre |
00:29:58 | * | rnrwashere quit (Remote host closed the connection) |
00:30:03 | rayman22201 | via nimble or git clone? |
00:30:12 | FromDiscord | <j$> the pkg dir seems correct at first glance |
00:30:25 | FromDiscord | <j$> git |
00:30:29 | rayman22201 | sweet |
00:32:27 | FromDiscord | <j$> and my test nimpcre compiled so that's good |
00:34:05 | FromDiscord | <j$> now im having the issue of dlls not loading with my executable, sdl2 to be specific |
00:35:35 | rayman22201 | sdl is a lot harder to try and static link. I would not recommend that. |
00:36:18 | FromDiscord | <j$> not static linking |
00:36:54 | rayman22201 | the exe just can't find the dll? |
00:36:57 | FromDiscord | <j$> yeah |
00:37:01 | FromDiscord | <j$> it's in the same dir |
00:37:07 | FromDiscord | <j$> it builds |
00:37:12 | FromDiscord | <j$> Im stumped |
00:37:19 | rayman22201 | may be the wrong version of the dll |
00:39:33 | shashlick | Yay at least nimpcre works |
00:39:45 | rayman22201 | lol. yay indeed :-P |
00:39:52 | FromDiscord | <j$> ya thanks for that! |
00:40:01 | shashlick | Basically, nimble checks what to install before the before install task runs now |
00:40:04 | rayman22201 | Is this the nimble bug? https://github.com/nim-lang/nimble/issues/549 |
00:40:24 | shashlick | Since nimgen runs in before install, everything it does isn't detected |
00:40:29 | shashlick | Yep |
00:40:36 | shashlick | It changed in 0.9.0 |
00:41:03 | shashlick | That's a small part of the reason why I started nimterop |
00:43:58 | FromDiscord | <j$> seems nice from what I understood |
00:44:09 | rayman22201 | I'm trying to understand the issue, but I'm particularly confused by your last comment. It works for "special versions" but not release tags? |
00:44:21 | rayman22201 | what special versions are you referring to? |
00:44:40 | FromDiscord | <j$> so any ideas on dlls not loading? the version isn't the issue |
00:45:06 | rayman22201 | how do you know j$? Can you give use the error message? |
00:45:41 | FromDiscord | <j$> could not load: SDL2.dll |
00:45:50 | FromDiscord | <j$> it compiles fine |
00:46:03 | rayman22201 | that doesn't tell you if it's a version issue though |
00:46:16 | FromDiscord | <j$> the documentation specifies the correct version |
00:46:32 | FromDiscord | <j$> I mean I guess it could be wrong but I doubt it |
00:46:46 | FromDiscord | <j$> this happened when I switched to choosenim |
00:46:55 | FromDiscord | <j$> that's why I wanted to switch back |
00:47:11 | rayman22201 | choosenim affected it? that seems odd to me |
00:47:25 | FromDiscord | <j$> well I don't know |
00:47:32 | FromDiscord | <j$> it could be changing to 10.4 |
00:47:37 | FromDiscord | <j$> 19.4* |
00:47:37 | rayman22201 | this is one area linux is better than windows imo. the "ldd" utility... |
00:47:46 | rayman22201 | try running this tool on your exe: http://www.dependencywalker.com/ |
00:48:54 | rayman22201 | what are you using on the nim side to talk to sdl? |
00:49:49 | FromDiscord | <j$> https://github.com/Vladar4/sdl2_nim |
00:49:59 | FromDiscord | <j$> Error: At least one required implicit or forwarded dependency was not found. |
00:49:59 | FromDiscord | <j$> Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module. |
00:49:59 | FromDiscord | <j$> Error: Modules with different CPU types were found. |
00:50:00 | FromDiscord | <j$> Warning: At least one delay-load dependency module was not found. |
00:50:15 | FromDiscord | <j$> this is what I get from that dep walker |
00:51:54 | rayman22201 | well, this error "Error: Modules with different CPU types were found." is telling me that you might be using the 32bit version when you should have the 64bit version |
00:52:17 | rayman22201 | or possibly vice versa |
00:52:29 | rayman22201 | I actually think nim is 32bit by default on windows |
00:53:31 | rayman22201 | what does "gcc.exe -v" give you? |
00:55:39 | FromDiscord | <j$> it was the 32 bit thing |
00:55:42 | FromDiscord | <j$> *sigh* |
00:55:50 | rayman22201 | woot |
00:56:01 | FromDiscord | <j$> I dont even remember changing the dlls |
00:56:05 | FromDiscord | <j$> but whatever |
00:56:25 | rayman22201 | but it works now? yay. *cheers* |
00:58:14 | FromDiscord | <j$> yay! |
00:58:47 | rayman22201 | sorry you had so much trouble, but I'm glad you hung in there :-) |
01:02:39 | * | junk[m] quit (*.net *.split) |
01:02:39 | * | leorize quit (*.net *.split) |
01:02:39 | * | k0mpjut0r quit (*.net *.split) |
01:02:40 | * | serialdev[m] quit (*.net *.split) |
01:03:56 | FromDiscord | <j$> yeah thank you for all of your help |
01:03:59 | FromDiscord | <j$> you are a beast |
01:04:18 | FromDiscord | <j$> i've learn alot these past couple days |
01:04:32 | FromDiscord | <j$> and I just wanna write some code |
01:09:54 | * | serialdev[m] joined #nim |
01:09:58 | * | k0mpjut0r joined #nim |
01:09:58 | * | junk[m] joined #nim |
01:10:33 | * | leorize joined #nim |
01:20:51 | rayman22201 | lol. np. I think shashlick is the real beast here. Hopefully you can be back to some blissful code writing now. |
01:42:19 | shashlick | do you think I should port nimpcre to nimterop? |
01:42:26 | shashlick | will avoid the c2nim dependency |
01:42:36 | shashlick | i can fix the nimble issue eventually |
01:43:17 | rayman22201 | yes, since nimterop is the more "modern" successor anyway. But the nimble bug should be fixed as well... eventually. |
01:43:22 | rayman22201 | so yes |
01:43:25 | rayman22201 | and yes lol |
01:48:40 | * | rnrwashere joined #nim |
01:50:04 | shashlick | 😄 |
01:50:35 | disruptek | i wish i could define the types of my `let`s in the top of my block and have the compiler merely assert that i set their values only once. |
01:54:10 | * | chimez joined #nim |
02:07:08 | * | banc quit (Quit: Bye) |
02:14:37 | * | i7sDream joined #nim |
02:14:43 | FromGitter | <kaushalmodi> I was trying to use generics, but this doesn't work: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5cb7dd924b4cb471d914a7a4] |
02:16:56 | FromGitter | <kaushalmodi> the error I get is: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5cb7de18a4ef097471b7f83e] |
02:19:57 | * | i7sDream quit (Ping timeout: 255 seconds) |
02:27:58 | * | banc joined #nim |
02:30:34 | FromGitter | <disruptek> @kaushalmodi the [T,U] are types, not variables. you get that, right? |
02:30:53 | FromGitter | <kaushalmodi> yeah .. |
02:31:02 | FromGitter | <kaushalmodi> I thought I am using them as types |
02:31:25 | FromGitter | <kaushalmodi> isn't `ptr U` a type? |
02:31:27 | FromGitter | <disruptek> show us how you're calling `arrayToObj`. |
02:32:28 | FromGitter | <kaushalmodi> http://ix.io/1Gv7 |
02:32:59 | FromGitter | <kaushalmodi> see `intArrayObjPtr: ptr IntArr = s.arrayToObj()` |
02:34:16 | disruptek | so what is type T and what is type U? |
02:34:38 | rayman22201 | Nim has no way to figure out what U should be from that call |
02:35:41 | FromGitter | <kaushalmodi> T is cint and U is IntArr |
02:35:50 | FromGitter | <kaushalmodi> IntArr is an object type |
02:35:55 | rayman22201 | try `arrayToObj[cint, IntArr](s)` |
02:36:23 | rayman22201 | the generic can only infer types from the input arguments |
02:36:30 | disruptek | it only *feels* like magic. :-) |
02:36:43 | FromGitter | <kaushalmodi> let me try .. though the compilation is failing at the generic definition itself |
02:36:49 | disruptek | Nim: no magic here. |
02:36:52 | rayman22201 | lol |
02:37:35 | FromGitter | <kaushalmodi> I agree, but I was specifying types in that assignment |
02:37:47 | FromGitter | <kaushalmodi> `intArrayObjPtr: ptr IntArr = s.arrayToObj()` |
02:37:54 | disruptek | the lhs is completely separate. |
02:37:59 | FromGitter | <kaushalmodi> isn't the return type obvious there? |
02:38:28 | disruptek | i guess i see what you mean. hmm. i don't think it works that way, but maybe it could. |
02:38:29 | rayman22201 | you only specified types on the result. exactly. An expression can be arbitrarily nested, so there is no way to use the result type to infer a type |
02:38:51 | rayman22201 | result == lhs |
02:38:53 | disruptek | i guess the problem is Nim cannot *assume* that your code is correct. |
02:39:08 | disruptek | and, it would have to, to type-check the lhs versus rhs. |
02:39:25 | rayman22201 | well, it does do that. |
02:39:32 | rayman22201 | that is where the error is coming. |
02:39:55 | rayman22201 | the type of the rhs cannot depend on the lhs |
02:40:04 | disruptek | yes, but it would have to assume that the return value is the lhs and then transitively assign it to the U generic. |
02:40:06 | * | i7sDream joined #nim |
02:40:24 | disruptek | anyway... it doesn't work this way. :-D |
02:40:26 | FromGitter | <kaushalmodi> I see, thanks |
02:40:44 | FromGitter | <kaushalmodi> rayman22201: explicitly specifying the types worked! |
02:40:44 | disruptek | (and that's a good thing) |
02:40:56 | rayman22201 | correct, and no sane type checker does this lol |
02:40:59 | rayman22201 | yay! good |
02:41:01 | * | disruptek w00h00s |
02:41:04 | FromGitter | <kaushalmodi> though .. I found a functional bug :P |
02:41:16 | disruptek | ...because it's not type checking. ;-) |
02:41:36 | disruptek | new for nim 2.0: type *assuming*. |
02:41:40 | disruptek | something to look forward to? |
02:41:44 | FromGitter | <kaushalmodi> no .. about assigning value to the `result[]` |
02:42:04 | rayman22201 | @disruptek lmao :troll: |
02:42:27 | * | i7sDream quit (Read error: Connection reset by peer) |
02:42:41 | rayman22201 | what is the bug @kaushalmodi? |
02:42:53 | FromGitter | <kaushalmodi> this is the working code: http://ix.io/1Gva |
02:43:22 | FromGitter | <kaushalmodi> I am trying the encapsulate the setting of `intArrayObjPtr` in a generic proc |
02:43:39 | disruptek | all things considering, it's an incredible language. i've only written like 500 loc but i'm loving it. |
02:43:56 | FromGitter | <kaushalmodi> so that I don't need to repeat those 10 lines for each `T,U` type combination |
02:45:30 | rayman22201 | @disruptek glad you are enjoying it. We all think Nim is pretty damn cool here :-) |
02:45:41 | rayman22201 | @kuashalmodi I don't see the bug though |
02:46:02 | rayman22201 | I'm just looking at the code, not actually running it |
02:46:11 | FromGitter | <kaushalmodi> if I encapsulate that in proc, I get: ⏎ ⏎ > SIGSEGV: Illegal storage access. (Attempt to read from nil?) |
02:46:46 | FromGitter | <kaushalmodi> yes, it will be difficult to get running without compiling the C code |
02:47:06 | FromGitter | <kaushalmodi> this Nim code is a wrapper around some C code I exported from Matlab |
02:47:58 | FromGitter | <kaushalmodi> you will need all code from this directory to actually run it: https://github.com/kaushalmodi/nim-systemverilog-dpic/tree/master/inp_outp_both_nested_struct_matlab |
02:48:53 | rayman22201 | what line does the segv happen. can you tell? |
02:49:08 | rayman22201 | I wonder if you might accomplish this more easily by using a template? |
02:51:57 | FromGitter | <kaushalmodi> template would probably work as it would be inline expansion .. I looked at template docs but couldn't figure out how to make a generic template |
02:52:31 | rayman22201 | `inputSizeArrayPtr` no longer exists after you return from the function, yet you are keeping a pointer to it in the result object. |
02:52:43 | rayman22201 | technically `inputSizeArray` no longer exists |
02:52:59 | FromGitter | <kaushalmodi> that's what I thought |
02:53:11 | FromGitter | <kaushalmodi> all the alloc0 done in the proc probably get lost |
02:54:20 | FromGitter | <kaushalmodi> the segv is happening from C side .. where I call a func imported from C |
02:55:24 | rayman22201 | the alloc0 stays around. You are explicitly creating shared memory there, but `inputSizeArray` is a local variable, so it goes away |
02:55:36 | shashlick | we really need a new choosenim release |
02:55:43 | shashlick | the latest binary is more than a year old |
02:56:28 | rayman22201 | This is what happens when the maintainer gets that sweet sweet Facebook job :-P |
02:56:50 | I_Right_I | I think reinstall might be a good feature for choosenim |
02:57:03 | rayman22201 | I agree |
02:57:55 | I_Right_I | or update -f |
02:58:02 | I_Right_I | --force |
02:58:13 | FromGitter | <alehander42> ruby3 plan some static inferrence stuff after all |
02:58:22 | rayman22201 | nimble packages don't get re-built when you change nim versions with choosenim. My intuition says that you could end up with compatibility issues because of this, but idk the right solution. |
02:58:27 | FromGitter | <alehander42> but i still don't understand the plan completely |
02:58:43 | FromGitter | <alehander42> it seems they will include doc/rbi file annotations optionally |
03:00:25 | rayman22201 | @alehander42, I'm sorry, I missed the context |
03:03:49 | rayman22201 | @kaushalmodi: looking at your working code, how do you determine your generic types? It looks like you have the "U" type hard coded to `IntArr` and you infer the type of s (in this case `seq[cint]`) |
03:04:38 | FromGitter | <kaushalmodi> the working code doesn't use generics |
03:05:13 | FromGitter | <kaushalmodi> the U type is `IntArrObj` (I made a typo here earlier) |
03:05:56 | FromGitter | <kaushalmodi> your suggestion to explicitly specify T and U to `cint` and `IntArrObj` makes compilation work, but then I get sigsegv |
03:06:45 | FromGitter | <kaushalmodi> as you said, that `inputSizeArray` from inside the proc is getting lost .. |
03:07:07 | * | rockcavera joined #nim |
03:07:15 | rayman22201 | my point is that there really is only one type needed here. the type of `s`. The output type `u` is explicitly specified by you |
03:08:11 | FromGitter | <kaushalmodi> I didn't follow |
03:08:12 | rayman22201 | a template could just take the output type as an argument, and get the type of s |
03:08:52 | FromGitter | <kaushalmodi> but how would the alloc0 work? |
03:13:08 | FromGitter | <kaushalmodi> I am basically trying to reduce the copy/paste I need to do here: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5cb7eb442e2caa1aa677d8d0] |
03:14:35 | FromGitter | <kaushalmodi> *that T in above snippet is actually cint |
03:14:58 | rayman22201 | yup. I understand |
03:15:09 | rayman22201 | which is what templates are for lol |
03:15:48 | FromGitter | <kaushalmodi> so in that template, I need 2 generic types .. |
03:16:12 | FromGitter | <kaushalmodi> the cint can be cdouble, and the object type IntArrayObj can be RealArrayObj |
03:22:47 | rayman22201 | https://pastebin.com/raw/ddV8wi5a |
03:22:56 | rayman22201 | freaking copy paste issues. sorry |
03:23:46 | I_Right_I | 2018 and we still have copy paste formatting issues.....sigh |
03:23:55 | I_Right_I | 2019 |
03:24:10 | rayman22201 | there are tools for this, but I'm lazy and I haven't set them up lol |
03:24:51 | FromGitter | <kaushalmodi> rayman22201: thanks! let me try that |
03:26:10 | I_Right_I | yeah but we were supposed to be able to voice activate the kind of stuff from our hover cars |
03:26:15 | rayman22201 | no promises. There may be typos |
03:26:59 | rayman22201 | lol. I was hoping to just be plugged into the Matrix straight from my brain stem right now. |
03:28:47 | shashlick | just created a PR to remove the compiler from nimble - https://github.com/nim-lang/nimble/pull/635 |
03:28:50 | shashlick | reviews appreciated |
03:29:04 | shashlick | @Araq and @dom96 ^^^ |
03:30:23 | * | rnrwashere quit (Remote host closed the connection) |
03:33:03 | rayman22201 | congrats shashlick! good work |
03:33:09 | FromGitter | <kaushalmodi> rayman22201: `result` probably cannot be used in templates |
03:33:15 | * | arecacea1 quit (Remote host closed the connection) |
03:33:36 | * | arecacea1 joined #nim |
03:33:48 | FromGitter | <kaushalmodi> Error: undeclared identifier: 'result' |
03:34:29 | FromGitter | <kaushalmodi> I think I should put this optimization on hold for now :P |
03:34:31 | shashlick | thanks rayman22201 🙂 |
03:34:46 | rayman22201 | oh yeah. Templates are just fancy copy and paste. Think a better version of the c preprocessor |
03:38:07 | I_Right_I | hey is there any optimization benefits to using Templates? |
03:38:39 | rayman22201 | @kaushalmodi: I think this will work: https://pastebin.com/raw/azpjFXWW |
03:39:15 | rayman22201 | I don't remember if it needs to be wrapped in a block expression or not |
03:39:42 | rayman22201 | I_Right_I: simple answer, yes. complicated answer, it depends. |
03:40:14 | I_Right_I | okay, so just like c |
03:40:46 | rayman22201 | yup |
03:41:13 | rayman22201 | way better than C though :-P |
03:45:04 | I_Right_I | I remember working on a preprocessed function in c, wondering why It wasn't faster than my previous function, just to find out my compiler was inlining it anyways. |
03:45:53 | rayman22201 | same thing happens in Nim land |
03:46:02 | rayman22201 | C compilers are pretty good these days |
03:46:52 | FromGitter | <kaushalmodi> rayman22201: ⏎ ⏎ that didn't work either ⏎ ⏎ > mean_func_test_template.nim(13, 24) Error: cannot cast to a non concrete type: 'ptr UncheckedArray[type cint]' [https://gitter.im/nim-lang/Nim?at=5cb7f32c375bac7470c1c31e] |
03:47:13 | I_Right_I | yeah I am sure but now I am much older and fraction wiser. |
03:47:15 | FromGitter | <kaushalmodi> I need to sit down and properly understand templates |
03:48:05 | rayman22201 | oh, you don't need type. It's already a type |
03:48:13 | rayman22201 | cool |
03:48:30 | rayman22201 | you can just do `ptr UncheckedArray[u]` |
03:48:35 | * | i7sDream joined #nim |
03:48:37 | FromGitter | <kaushalmodi> yep! |
03:48:41 | rayman22201 | or s I mean |
03:48:45 | FromGitter | <kaushalmodi> that's what I tried and it .. |
03:48:48 | FromGitter | <kaushalmodi> worked! |
03:48:52 | rayman22201 | wooot! |
03:49:03 | FromGitter | <kaushalmodi> final working piece: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5cb7f3afb489bb6ed780e7cb] |
03:49:23 | FromGitter | <kaushalmodi> had to upcase the type to `S` to not mix with the in-scope var `s` |
03:50:18 | FromGitter | <kaushalmodi> what's interesting is that the template invocation looks funny .. |
03:50:24 | FromGitter | <kaushalmodi> ```for idx, s in inputData: ⏎ let ⏎ intArrayObjPtr = arrayToObj(cint, IntArrayObj)``` [https://gitter.im/nim-lang/Nim?at=5cb7f400375bac7470c1c81a] |
03:50:55 | FromGitter | <kaushalmodi> I have never used templates like this .. it's operating on the variable `s` in that `for` scope .. |
03:51:34 | FromGitter | <kaushalmodi> rayman22201: thanks again! |
03:52:03 | rayman22201 | np. glad to help :-) |
03:54:57 | I_Right_I | The threaded UDP socket library I have been working on a little here and there is a bit more useful then when I first posted it. If any ones interested. |
03:54:59 | I_Right_I | https://github.com/i-right-i/simpleUDP |
03:56:49 | FromGitter | <kaushalmodi> rayman22201: I just made this minor refinement: http://ix.io/1Gvo (use typedesc instead of untyped and added the array/seq as input to the template to not hardcode the `s` var into the template) |
03:57:23 | rayman22201 | I agree. That is more clear |
03:57:56 | rayman22201 | technically the template opened a new child scope, it is hygenic, but this is still more clear |
03:58:45 | rayman22201 | you could also just use `type` instead of `typedesc` |
03:58:56 | rayman22201 | I think they are aliased to each other so it doesn't really matter |
04:01:17 | FromGitter | <kaushalmodi> type didn't |
04:01:19 | FromGitter | <kaushalmodi> work |
04:01:28 | rayman22201 | orly? |
04:01:39 | rayman22201 | what Nim verison? |
04:01:48 | FromGitter | <kaushalmodi> nim devel |
04:02:01 | FromGitter | <kaushalmodi> works with typedesc, but it I use type, I get |
04:02:07 | FromGitter | <kaushalmodi> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5cb7f6bf375bac7470c1d7a5] |
04:03:03 | rayman22201 | I think that might be a bug |
04:04:19 | rayman22201 | IntArrayObj is an alias, but `type` is not getting the root type, it's using the whole type alias node |
04:05:15 | rayman22201 | if that makes sense? put another way, it's not following the alias. |
04:06:55 | rayman22201 | I_Right_I, looks like you are making good progress on your lib. very cool. |
04:07:15 | FromGitter | <kaushalmodi> but using typedesc works .. |
04:07:21 | FromGitter | <kaushalmodi> I'll come up with a minimal example |
04:07:35 | rayman22201 | yeah. typdesc gets the root type |
04:08:06 | rayman22201 | this might just be a case where it is working as intended, but needs better documentation. |
04:08:32 | rayman22201 | the difference between `type` and `typedesc` is not obvious in this context |
04:11:35 | FromGitter | <kaushalmodi> minimal example: http://ix.io/1Gvq |
04:14:16 | rayman22201 | yeah, the culperate is : `IntArrayObj* = emxArray_int32_T` |
04:14:58 | rayman22201 | using `type` gives `type type emxArray_int32_T` |
04:14:58 | rayman22201 | using `typedesc` gives `type emxArray_int32_T` |
04:15:26 | rayman22201 | notice the nesting in the first part |
04:19:12 | I_Right_I | rayman22201: Thanks it still needs ipv6 support added, better examples and docs(big shocker). But I got it to the point were I can use it for the protocol framework I want to build. |
04:21:53 | FromGitter | <kaushalmodi> rayman22201: Done: https://github.com/nim-lang/Nim/issues/11058 |
04:28:16 | rayman22201 | Cool. Thanks! |
04:28:27 | rayman22201 | Ok. TTYL. |
04:29:02 | * | nsf joined #nim |
04:30:39 | FromGitter | <kaushalmodi> alright, thanks for sticking through helping me find a solution and a bug :D |
04:46:39 | * | rnrwashere joined #nim |
04:54:57 | * | dddddd quit (Remote host closed the connection) |
05:10:30 | * | narimiran joined #nim |
05:14:46 | * | rnrwashere quit (Remote host closed the connection) |
05:32:00 | * | I_Right_I quit (Remote host closed the connection) |
05:32:38 | * | kapil____ joined #nim |
05:48:05 | * | solitudesf joined #nim |
06:41:51 | * | hoijui joined #nim |
06:42:31 | * | jjido joined #nim |
06:46:30 | * | hoijui quit (Remote host closed the connection) |
06:56:15 | * | solitudesf quit (Ping timeout: 255 seconds) |
07:00:00 | * | gmpreussner quit (Quit: kthxbye) |
07:04:40 | * | gmpreussner joined #nim |
07:06:49 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
07:35:54 | * | krux02 joined #nim |
07:58:23 | * | neceve joined #nim |
08:07:13 | * | floppydh joined #nim |
08:09:16 | * | Lord_Nightmare quit (Ping timeout: 268 seconds) |
08:24:27 | * | Lord_Nightmare joined #nim |
08:26:58 | * | rnrwashere joined #nim |
08:31:07 | * | rnrwashere quit (Ping timeout: 240 seconds) |
08:34:36 | * | chimez quit (Quit: chimez) |
08:37:14 | * | Vladar joined #nim |
09:00:48 | * | solitudesf joined #nim |
09:38:56 | * | sz0 joined #nim |
09:43:11 | * | lritter joined #nim |
09:45:06 | FromGitter | <palash25> Hi, I am trying out the httpclient library and this example perplexed me ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ what is the `%*` before the curly braces supposed to mean? when I try to do the same in my nim script I get an error saying `undeclared identifier: '%*'` [https://gitter.im/nim-lang/Nim?at=5cb847225b3f941aa54f0122] |
09:45:27 | FromGitter | <palash25> here is my code ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5cb84737375bac7470c3eb4c] |
09:45:34 | Zevv | import json |
09:46:16 | Zevv | it's a macro doing JSON serialization |
09:46:19 | Zevv | it's terrible, IMHO |
09:46:36 | Zevv | the rationale is that it's often used, and thus should be short |
09:47:00 | Zevv | https://nim-lang.github.io/Nim/json.html#%25%2A.m%2Cuntyped |
09:47:09 | FromGitter | <palash25> thanks, importing json solved it |
09:47:14 | Zevv | sweet |
09:47:21 | FromGitter | <palash25> it should be documented though |
09:47:30 | FromGitter | <palash25> can I raise an issue? |
09:47:35 | Zevv | don't forget to compile with -d:ssl |
09:47:36 | narimiran | in which way? |
09:47:53 | FromGitter | <palash25> > don't forget to compile with -d:ssl ⏎ ⏎ did that, it worked |
09:47:55 | narimiran | what is the issue? "you imported something and didn't explicitly tell me"? |
09:48:38 | lritter | shameless plug: after a year of work, i published 0.14 of my programming language https://bitbucket.org/duangle/scopes |
09:49:13 | Zevv | palash25: where did you find the example? Because the samples in the Nim docs do import json |
09:49:33 | lritter | i know, it's insolent to mention it here but i was told nim is interested ;) |
09:49:48 | narimiran | Zevv: so does his original example too ;) |
09:49:55 | Zevv | ow :) |
09:49:55 | FromGitter | <palash25> > *<narimiran>* what is the issue? "you imported something and didn't explicitly tell me"? ⏎ ⏎ to add import json to that code snippet in the httpclient examples |
09:49:58 | lritter | i managed to add borrow checking in a way that is hopefully less annoying. |
09:50:00 | FromGitter | <palash25> and a comment about `*%` being a macro |
09:50:05 | lritter | ask me all about it ;) |
09:50:46 | narimiran | palash25 that code snippet *has* json import, both in your paste and in https://nim-lang.github.io/Nim/httpclient.html example |
09:51:34 | FromGitter | <palash25> > *<Zevv>* @palash25: where did you find the example? Because the samples in the Nim docs do import json ⏎ ⏎ here https://nim-lang.github.io/Nim/httpclient.html under the http post section |
09:51:54 | Zevv | "import httpclient, json" |
09:52:17 | narimiran | btw, when i write the docs for some module, i usually write why we import other modules, what do they bring |
09:52:18 | Zevv | so you probably did a mispaste, these things happen. I understand your confusion about %*, it's not trivial, to say the least |
09:52:19 | FromGitter | <palash25> fuck, didn't see that |
09:53:08 | dom96 | Pro Tip: use the index to find symbols like these: https://nim-lang.org/docs/theindex.html |
09:53:18 | dom96 | Just Ctrl+F "%*" |
09:53:45 | FromGitter | <palash25> cool, thanks |
09:53:51 | dom96 | In the long run we should look into injecting hyperlinks into code samples like these |
09:55:15 | dom96 | Zevv: While `%` is cryptic it really is used a lot so IMO it deserves an operator. |
09:56:00 | Zevv | I know, and I understand |
09:56:19 | Zevv | I use 'import' and 'while' even more, lets make these ^@ and &! :) |
09:56:31 | narimiran | :D :D |
09:56:32 | Zevv | but I'm not starting that discussion :) |
10:01:19 | dom96 | I see your point, but meh. It goes the other way too, why not use `multiply` instead of `*`? :P |
10:01:25 | * | kapil____ quit (Quit: Connection closed for inactivity) |
10:01:26 | FromGitter | <mratsim> please no |
10:01:28 | FromGitter | <mratsim> spare me |
10:01:38 | Zevv | I'm *not* |
10:02:06 | FromGitter | <mratsim> also &! is already used in hashes lib for mixing hashes |
10:03:00 | Zevv | If we run out of operators we can still adapt the APL alphabet. Oh, all the unicode pages we could use! |
10:04:22 | FromGitter | <mratsim> my main issues with operators is precedence |
10:05:18 | narimiran | dom96: yeah, people usually come to nim irc asking about what does this mysterious '*' operator do with two numbers. :P |
10:05:35 | Zevv | no fighting no fighting |
10:05:48 | narimiran | Zevv: you started it!! :P :D |
10:05:52 | * | Tanger quit (Ping timeout: 245 seconds) |
10:06:17 | * | Zevv sneaks out to lunch |
10:06:34 | narimiran | food fight? |
10:06:52 | dom96 | You don't have to convince me, I would have been happy with a toJson :P |
10:06:58 | dom96 | I just don't think it's worth grmubling about it :P |
10:07:26 | narimiran | well, it is casual fri— i mean thursday |
10:24:46 | FromGitter | <mratsim> @narimiran, since you didn't raise a PR I don't have a proper place to comment besides your commit but I'm pretty sure this is wrong: https://github.com/narimiran/Nim/commit/f1c5e7aa52c732cefec0183149cdcc85514e9cc7#r33227653 |
10:27:39 | * | ofelas quit (Quit: shutdown -h now) |
10:30:24 | * | ofelas joined #nim |
10:35:39 | narimiran | mratsim thanks for the comment! btw, PR is here https://github.com/nim-lang/Nim/pull/11051 and maybe you should copy-paste it there too? |
10:40:51 | * | sentreen quit (Quit: sentreen) |
10:41:47 | * | sentreen joined #nim |
10:42:23 | * | stefanos82 joined #nim |
10:45:07 | * | sentreen quit (Client Quit) |
10:45:16 | * | sentreen joined #nim |
10:50:44 | * | ng0 joined #nim |
10:53:07 | * | Tanger joined #nim |
10:57:57 | * | Tanger quit (Ping timeout: 244 seconds) |
11:13:50 | * | Snircle joined #nim |
11:34:05 | * | uptime quit (Quit: It's been a pleasure working with some of you, and I will not forget those of you soon. But remember, while today it is me, we all shall fall. In other words, I'm quitting.) |
11:47:19 | * | ofelas quit (Ping timeout: 246 seconds) |
11:53:00 | * | dddddd_ joined #nim |
11:54:30 | shashlick | @dom96 - https://github.com/nim-lang/nimble/pull/635 |
11:57:15 | * | dddddd_ is now known as dddddd |
12:01:57 | * | kapil____ joined #nim |
12:02:55 | FromGitter | <kaushalmodi> I have been using constructs like `castptr FftCharObj (alloc0(sizeof FftCharObj))` dozens of times lately |
12:02:59 | FromGitter | <kaushalmodi> should it be that common? |
12:03:20 | FromGitter | <kaushalmodi> basically wondering if a sugar syntax already exists for that |
12:03:33 | narimiran | what are the possible answers? 1. yes; 2. no; 3. it depends? :) |
12:04:26 | FromGitter | <kaushalmodi> was trying to guage if folks working on Nim/C interop frequently used that |
12:04:42 | FromGitter | <kaushalmodi> and if having a concise template to do that was worth in the stdlib |
12:05:11 | narimiran | IIRC it is on purpose convoluted to discourage its usage |
12:05:52 | FromGitter | <kaushalmodi> so is there an equivalent recommended way to do the same? |
12:06:04 | Zevv | kaushalmodi: I guess typically you should make a Nim object representing the C struct |
12:06:19 | FromGitter | <kaushalmodi> FftCharObj *is* a Nim object |
12:06:23 | FromGitter | <kaushalmodi> it's struct on the C side |
12:06:34 | FromGitter | <kaushalmodi> and I need to return a pointer to that struct back to the C side |
12:08:07 | leorize | kaushalmodi: use `system.create` |
12:09:08 | * | Tanger joined #nim |
12:09:49 | leorize | it existed for a long time I believe, but everyone keeps doing the `cast` thing. I guess the docs should mention that proc |
12:10:55 | FromGitter | <mratsim> create and alloc disappeared from the doc at one point |
12:10:58 | Zevv | I'm probably missing something obvious, but why can't just just put your objects somewhere in Nim and addr them? |
12:11:17 | FromGitter | <kaushalmodi> Zevv: @mratsim might answer that :) |
12:11:33 | FromGitter | <kaushalmodi> I don't claim to know 100% of the details |
12:11:36 | Zevv | I never used any cast or alloc0 magic. I just make a Nim object, and pass the addr to C |
12:11:47 | FromGitter | <kaushalmodi> but the gist I got is that use `ref` only for objects you deal with within Nim |
12:12:35 | leorize | uhmm, `addr` returns a ptr... |
12:12:36 | FromGitter | <kaushalmodi> Zevv: I used to do that, but recently switched to using ptrs on Nim/C boundary |
12:12:36 | Zevv | Well, you should of course keep the object alive on the Nim side as long as C also uses them |
12:13:41 | FromGitter | <kaushalmodi> leorize: so .. you mean .. use an foo = SomeObj(..) constructor as usual and then do just `addr foo`? |
12:13:46 | FromGitter | <mratsim> yes |
12:13:57 | Zevv | that's what I do |
12:14:15 | FromGitter | <kaushalmodi> I didn't think of that |
12:14:17 | FromGitter | <kaushalmodi> thanks guys |
12:14:18 | Zevv | :) |
12:14:27 | FromGitter | <kaushalmodi> I thought that it's either ref or ptr |
12:14:35 | narimiran | kaushalmodi idea: if you decide to refactor it - maybe this is worth of some short blogpost/note? |
12:14:42 | FromGitter | <mratsim> my case is a bit special, I use cast for arrays/ptr uncheckedArray |
12:14:58 | FromGitter | <mratsim> and alloc + another step for specific finalizers |
12:15:00 | FromGitter | <kaushalmodi> narimiran: I worry that I might mislead folks as I don't have 100% knowledge on these topics |
12:15:12 | Zevv | But make sure to keep an eye on where the objects live and who keeps them alive. If it was created on the stack, you give it to C and leave your scope, things will go *boom* |
12:15:16 | FromGitter | <kaushalmodi> I am learning bits and pieces as I stumble through it |
12:15:34 | narimiran | well, now you have your old way, and hopefully soon you'll have "new, improved, simpler" way of doing it |
12:15:36 | leorize | most of the time I just abuse how the compiler translate `var` to C pointer :p |
12:15:56 | FromGitter | <mratsim> `create` seems to have lifetime issues |
12:16:12 | narimiran | just to show a comparison between the two would be a nice start, and might be beneficial for others who are in your shoes |
12:16:14 | FromGitter | <mratsim> @leorize sounds like a bad idea |
12:16:15 | FromGitter | <kaushalmodi> thanks all; need to sign off for now |
12:16:41 | FromGitter | <kaushalmodi> narimiran: let me see if I can write up something useful |
12:16:49 | narimiran | thank you in advance :) |
12:17:35 | leorize | mratsim: a lot of compiler-specific details are abused for C interop iirc |
12:17:53 | FromGitter | <mratsim> I never add to use that |
12:17:57 | FromGitter | <mratsim> had* |
12:18:21 | leorize | IIRC there aren't any docs for how set[T] is implemented |
12:18:41 | leorize | but everyone uses that to pass flags to C proc anyway :p |
12:18:58 | Zevv | ? like how |
12:19:00 | FromGitter | <mratsim> it's a bitfield and you cannot reproduce C flags with Nim sets |
12:19:58 | FromGitter | <mratsim> My way to do C flags is this way: https://github.com/numforge/laser/blob/master/laser/photon_jit/photon_osalloc.nim#L15-L54 |
12:20:25 | leorize | I believe the compiler used to (or still) implements set[T] as a C bit field. I recall reading some posts on the forums about it. |
12:20:37 | Zevv | no, it's an array of uint8s |
12:20:47 | Zevv | with some shift, ors and ands |
12:21:00 | leorize | yea that's how I do my flags too |
12:21:07 | Zevv | I recently happened to look into the implementation to see if I could speed it up |
12:21:44 | FromGitter | <mratsim> it's not a C bitfield, you can't use those at compile-time |
12:24:14 | Zevv | I added `setbit` and `clearBit` to bitops some time ago for stuff like `iflag.clearBits(IXON, IXOF, IXANY)` instead of `iflag = iflag and not (IXON or IXOF or IXANY) |
12:25:20 | * | narimiran quit (Ping timeout: 246 seconds) |
12:25:28 | Zevv | also allows for multiple bits, so `v.clearBits(3, 4)` instead of `v = v and not ((1 shl 3) or (1 shl 4))` |
12:25:47 | FromGitter | <mratsim> bitops is problematic for me, I always have to copy-paste it and change the "undefined" behaviour set on corner cases for count trailing/leading zero |
12:30:54 | Zevv | elaborate? |
12:36:45 | FromGitter | <mratsim> when you countLeadingZero(0) when you set no undefined you get 0 |
12:38:37 | FromGitter | <mratsim> first of all, having a configuration via const is problematic for a library because every user of that library needs to also had that configuration flag, and also bitops might be used in the same project, sometimes when undefined behaviour is OK for perf purposes in some parts of the code and defined behaviors needed in other part |
12:39:03 | Zevv | ah ok; I only referred to the setBits, not to the rest of the lib. |
12:39:12 | FromGitter | <mratsim> last, countLeadingZero(0) should be the number of bits of the type |
12:39:48 | * | NimBot joined #nim |
12:39:55 | FromGitter | <mratsim> and modular arithmetics and all that jazz |
12:44:17 | * | FromGitter quit (Remote host closed the connection) |
12:44:17 | * | oprypin quit (Quit: Bye) |
12:47:12 | * | oprypin joined #nim |
12:47:23 | * | FromGitter joined #nim |
13:11:02 | * | i7sDream quit (Ping timeout: 250 seconds) |
13:11:10 | * | oprypin quit (Quit: Bye) |
13:11:17 | * | oprypin joined #nim |
13:12:00 | * | oprypin quit (Client Quit) |
13:12:07 | * | oprypin joined #nim |
13:12:21 | * | oprypin quit (Client Quit) |
13:12:28 | * | oprypin joined #nim |
13:15:32 | * | i7sDream joined #nim |
13:17:25 | * | Minimisthupper joined #nim |
13:18:27 | * | i7sDream quit (Remote host closed the connection) |
13:25:05 | * | oprypin quit (Quit: Bye) |
13:36:08 | * | oprypin joined #nim |
13:40:36 | * | floppydh quit (Quit: WeeChat 2.4) |
13:41:22 | * | chickendan joined #nim |
13:42:34 | * | floppydh joined #nim |
13:43:57 | * | solitudesf quit (Ping timeout: 255 seconds) |
13:48:05 | krux02 | mratsim: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html |
13:48:23 | krux02 | it is just a forward to a builtin of gcc (and other compilers) |
13:48:27 | krux02 | and there it is undefined |
13:49:31 | krux02 | __builtin_clz __builtin_clzll is where you should look |
13:55:49 | * | nsf quit (Quit: WeeChat 2.4) |
14:00:54 | * | fanta1 joined #nim |
14:02:29 | FromGitter | <kaushalmodi> leorize: you mentioned something about using var for C interop |
14:02:58 | FromGitter | <kaushalmodi> My observation is that I need to use `unsafeAddr` for a `let` var, while I can use `addr` for a `var` var. |
14:03:04 | Zevv | true |
14:03:27 | FromGitter | <kaushalmodi> So is it correct to generalize that I should use `var` for vars whose pointers I need to send to C? |
14:03:43 | Zevv | I believe I've been told that's the right thing to do |
14:03:53 | FromGitter | <kaushalmodi> Zevv: thanks |
14:04:04 | leorize | yea, unless you know the underlying code won't change the stuff that pointer points to |
14:04:12 | Zevv | I guess the compiler might decide a 'let' var can be optimized away as a constant |
14:04:16 | Zevv | which doesn't have an address |
14:05:05 | Zevv | I read an old thread soemwhere about this, let me find that |
14:05:32 | Zevv | https://forum.nim-lang.org/t/708 |
14:05:57 | FromGitter | <kaushalmodi> awesome! |
14:05:58 | Zevv | "Builtin 'addr' operator for taking the address of a memory location. This works even for let variables or parameters for better interop with C and so it is considered even more unsafe than the ordinary addr. When you use it to write a wrapper for a C library, you should always check that the original library does never write to data behind the pointer that is returned from this procedure." |
14:06:30 | Zevv | From the "unsafeAddr" manual. Seems that unsafeAddr is ok too, as long as you take care C will not write to your data |
14:06:32 | FromGitter | <kaushalmodi> the challenge is to figure out how to put together all this info so that it's understandable |
14:06:37 | FromGitter | <kaushalmodi> it's a bunch of "rules" |
14:06:45 | Zevv | It is not really that hard from a C perspective |
14:06:59 | FromGitter | <kaushalmodi> unsafeAddr just makes it look "more unsafe" :) |
14:07:20 | FromGitter | <kaushalmodi> Zevv: yeah, I have never coded in C |
14:07:34 | FromGitter | <kaushalmodi> kinda getting a little bit hang of it as I am learning Nim |
14:07:48 | Zevv | You have a Nim object living somewhere. If it is a 'var' you can take the address and pass it to C, and C can modify it. If it is a 'let', you can take unsafeAddr, and your C code should promisy-promisty it should not write to the pointer |
14:08:18 | Zevv | recap: var -> addr -> some *; let -> unsafeAddr -> const some * |
14:09:12 | FromGitter | <kaushalmodi> got it! |
14:10:24 | FromGitter | <kaushalmodi> while we are at this topic .. |
14:10:39 | FromGitter | <kaushalmodi> the `var` vars are on stack and `let` vars are on heap? |
14:10:48 | Zevv | nope |
14:10:49 | FromGitter | <kaushalmodi> and C deals with only the stack and not the heap? |
14:11:11 | leorize | everything is on the stack unless specified otherwise :) |
14:11:12 | Zevv | 'var' and 'let' can live in the same space. It is just a way to let the compiler know if you plan to modify it in the future. 'let' is a single assignment var |
14:11:20 | FromGitter | <kaushalmodi> ok |
14:11:35 | Zevv | what leorize says: it is basically on the stack, *unless* you explictly allocate something with new() |
14:12:03 | Zevv | note that new is used in various libraries, constructurs tend to start with new: newSeq, newTable, etc |
14:12:28 | FromGitter | <kaushalmodi> that makes sense |
14:12:44 | leorize | and pointer points to a memory location, your computer doesn't care if the pointer point to the stack or the heap. |
14:12:52 | Zevv | Everything made with 'new' yields a 'ref'. A 'ref' is a typed pointer to a thing which of which the memory is managaed by Nim |
14:13:38 | * | solitudesf joined #nim |
14:13:57 | Zevv | But in real life, funny things happen under the hood. If you make a var which you access from within the scope of a proc, you might create a closure. Which is not *really* on the stack. |
14:14:01 | Zevv | Having fun yet? :) |
14:14:27 | FromGitter | <kaushalmodi> I am actually trying to visualize this whole thing |
14:14:30 | * | i7sDream joined #nim |
14:14:39 | FromGitter | <kaushalmodi> will post a pic of a diagram shortly |
14:15:05 | FromGitter | <kaushalmodi> so .. if you do `addr` on a ref'd obj, you get the addr from heap? |
14:15:34 | FromGitter | <kaushalmodi> and if you do the same on a `var` obj, you get the addr from stack? |
14:15:56 | leorize | you'll get addr to the ref :p |
14:18:01 | Zevv | kaushalmodi: if you're not accustumed to C, the whole pointer/ref/addr thing might be daunting at first |
14:18:15 | Zevv | What helps is writing small snippets to see what happens under the hood. |
14:18:19 | Zevv | http://paste.ubuntu.com/p/d2km9wxXd2/ |
14:18:57 | Zevv | Here you can see what happens. 'a' is a var, and 'a.addr.repr' is the representation of the address of a |
14:19:57 | Zevv | You can see its address (which happens to be on my stack) and value. Then there is 'b', which is a ref to an int. If you print the b.addr.repr, you get another indirection: the ref itself lives on the stack, and points to the heap. And at this address on the heap lives the actual int with value '2' |
14:20:47 | * | floppydh quit (Quit: WeeChat 2.4) |
14:23:24 | * | rnrwashere joined #nim |
14:27:45 | FromGitter | <mratsim> @krux02, there is an extra noUndefined wrapper other GCC in bitops |
14:28:02 | FromGitter | <kaushalmodi> Zevv, leorize: please review https://www.dropbox.com/s/kuhuiouowzaqrh0/Nim_addr_ref_stack_heap_Scan%20Apr%2018%2C%202019.pdf?dl=0 |
14:28:16 | FromGitter | <mratsim> this part: https://github.com/nim-lang/Nim/blob/master/lib/pure/bitops.nim#L301-L303 |
14:30:07 | Zevv | kaushalmodi: sweet. I'd drop the seqs for now |
14:30:42 | Zevv | Use a basic type, or maybe an array. But seqs have overhead which is not in the drawing, and does not matter here. |
14:31:08 | * | Minimisthupper quit (Quit: Konversation terminated!) |
14:31:17 | FromGitter | <kaushalmodi> array has a "new" construct too? |
14:31:51 | Zevv | You can 'new' anything. But if you want to make a drawing about all this, just put a single 'int' on the heap, which is more simple |
14:32:18 | FromGitter | <kaushalmodi> interestingly I have never used `new` .. looking up |
14:32:23 | Zevv | I think we should be able to slowly build this up in a series of drawings, that would make a nice tutorial for beginners |
14:32:26 | FromGitter | <mratsim> you'll get a ref array |
14:32:43 | Zevv | yeah, but let's not get into ref arrays and seqs right from the start |
14:32:53 | FromGitter | <mratsim> new 2 will give you a ref int |
14:33:38 | Zevv | kaushalmodi: did you see the pastebin link I posted a few minutes ago |
14:34:22 | FromGitter | <kaushalmodi> I am about to have a look.. was working on that drawing |
14:34:28 | Zevv | ah ok :) |
14:34:38 | FromGitter | <kaushalmodi> ok, makes sense |
14:34:45 | FromGitter | <kaushalmodi> :) |
14:36:16 | * | fanta1 quit (Quit: fanta1) |
14:38:00 | FromGitter | <kaushalmodi> what is the second reference that the ref makes? |
14:38:24 | FromGitter | <kaushalmodi> the first addr is the addr to the ref in stack, and the second addr is the addr in heap that that ref points to? |
14:39:10 | Zevv | yes |
14:39:17 | FromGitter | <kaushalmodi> basically a refVar.addr is a pointer (in stack) to a pointer (in heap) |
14:39:44 | Zevv | Yes. But in practice you'd probably not need the address of a pointer in Nim |
14:39:55 | FromGitter | <kaushalmodi> yeah |
14:40:02 | FromGitter | <kaushalmodi> may be you meant just `b.repr` |
14:40:37 | Zevv | Yeah, but this shows what's actually happening. The ref is a real thing that also lives somewhere |
14:52:51 | * | rnrwashere quit (Remote host closed the connection) |
14:54:28 | * | rnrwashere joined #nim |
15:01:58 | * | rnrwashere quit (Remote host closed the connection) |
15:03:25 | * | i7sDream quit (Remote host closed the connection) |
15:03:52 | * | i7sDream joined #nim |
15:04:34 | * | nsf joined #nim |
15:04:59 | * | rnrwashere joined #nim |
15:06:47 | * | i7sDream quit (Remote host closed the connection) |
15:07:13 | * | i7sDream joined #nim |
15:09:08 | * | i7sDream quit (Remote host closed the connection) |
15:09:34 | * | i7sDream joined #nim |
15:11:29 | * | i7sDream quit (Remote host closed the connection) |
15:11:58 | * | i7sDream joined #nim |
15:13:53 | * | i7sDream quit (Remote host closed the connection) |
15:14:20 | * | i7sDream joined #nim |
15:16:13 | * | i7sDream quit (Remote host closed the connection) |
15:16:27 | FromGitter | <mratsim> Coming soon "Ref hunters", in the middle of the jungle, unknown creatures called ref are living, we will follow the story of Kaushal, the ref hunter. |
15:16:44 | * | i7sDream joined #nim |
15:18:25 | * | rnrwashere quit (Remote host closed the connection) |
15:22:30 | * | iLiquid joined #nim |
15:23:24 | Zevv | a close cousin of the garbage collector |
15:26:40 | * | i7sDream quit (Remote host closed the connection) |
15:27:07 | * | i7sDream joined #nim |
15:31:03 | * | i7sDream quit (Remote host closed the connection) |
15:31:32 | * | i7sDream joined #nim |
15:35:27 | * | i7sDream quit (Remote host closed the connection) |
15:36:11 | * | i7sDream joined #nim |
15:38:06 | * | i7sDream quit (Remote host closed the connection) |
15:38:34 | * | i7sDream joined #nim |
15:40:44 | * | i7sDream quit (Client Quit) |
15:41:12 | * | i7sDream joined #nim |
15:46:00 | shashlick | The silence after submitting a big PR is deafening! I need to take a break... |
15:48:54 | * | Jesin quit (Quit: Leaving) |
15:56:50 | * | Jesin joined #nim |
16:29:53 | krux02 | shashlick, which PR in particular are you talking about? |
16:32:21 | * | Trustable joined #nim |
16:33:09 | * | hoijui joined #nim |
16:35:29 | shashlick | @krux02 - https://github.com/nim-lang/nimble/pull/635 |
16:36:50 | krux02 | ah, it is about nimble. |
16:37:45 | krux02 | last time I merged something in nimble, dom96 becaume suddenly very active, re removed my merge rights and reverted the PR. |
16:38:00 | krux02 | The issues that were fixed in that PR, he left untouched. |
16:39:18 | krux02 | here: https://github.com/nim-lang/nimble/commit/587402fa1dbb6a025de97b7042c88b5a295c417b |
16:39:27 | FromDiscord | <SirBroadwell> what's equivalent of https://nim-lang.org/docs/net.html#connectUnix%2CSocket%2Cstring bindUnix on Windows ? |
16:40:23 | shashlick | ya i hate waiting, cause i don't work on anything else while i do |
16:44:38 | * | jjido joined #nim |
16:49:26 | * | glassofethanol joined #nim |
16:49:36 | * | glassofethanol left #nim (#nim) |
17:01:26 | * | i7sDream quit (Quit: WeeChat 2.4) |
17:08:43 | * | hoijui quit (Ping timeout: 258 seconds) |
17:15:00 | * | I_Right_I joined #nim |
17:15:02 | shashlick | 33 seconds for koch boot -d:release from scratch - life's good |
17:16:29 | shashlick | 38 seconds koch tools |
17:17:34 | * | hoijui joined #nim |
17:40:46 | * | Jjp137 quit (Read error: Connection reset by peer) |
17:41:28 | * | Jjp137 joined #nim |
17:51:14 | dom96 | krux02: Ignoring my comments in a PR and merging without talking to me ain't cool. |
17:57:24 | krux02 | shashlick, I recently worked on optimizing bootstrapping. Turned out that bootstrapping wasn't faster at all, but at least I got 20% less memory usage. |
17:59:10 | shashlick | ya i just saw the video blog |
17:59:27 | shashlick | it only really bothers devs who recompile often |
17:59:45 | shashlick | even i don't have to cause i stay in the periphery |
18:00:08 | shashlick | for compiler dev, do you have a way to koch boot for one iteration only? |
18:01:15 | dom96 | ./koch temp or nim c compiler/nim |
18:04:55 | shashlick | oh cool, good to know |
18:07:03 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
18:14:45 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
18:20:16 | * | neceve quit (Remote host closed the connection) |
18:25:19 | * | JustASlacker joined #nim |
18:26:57 | * | hoijui quit (Ping timeout: 252 seconds) |
18:34:10 | krux02 | shashlick, koch temp build a debug build of the compiler though `nim_temp`, pretty much what you need to to debug the compiler. |
18:34:38 | * | Jesin quit (Quit: Leaving) |
18:35:11 | krux02 | When I worked on the performance improvements on `koch boot`, I just did my measurements on `koch boot` the improvements are general for all compilations. |
18:36:12 | shashlick | okay thanks |
18:36:25 | shashlick | i use koch temp in tissue to generate the stack traces |
18:47:19 | dom96 | shashlick, thanks for going through the issues |
18:50:01 | shashlick | sure @dom96, while the nocompiler PR is going through review, i was looking for the next thing of priority |
18:52:43 | dom96 | by the way, just so we're all clear, I appreciate others reviewing PRs too. Feel free to go through shashlick's PR and make comments/accept it, if I see multiple accepts it gives me confidence that it's good to go |
18:54:11 | shashlick | @dom96 - by the way, was trying to get choosenim working on travis windows but we need a new release to do that since eraseLine() is crashing in the 0.3.2 release, and that is already fixed in the code |
18:55:26 | dom96 | yeah, please send me binaries if you can build a 32bit choosenim manually |
18:55:26 | shashlick | I can work on the choosenim CI but still need your help to get tagging and posting done to make it official, so if you have ideas on how to delegate some of that without giving full access, let me know |
18:55:47 | shashlick | oh if you just want binaries, i can send you those for all platforms |
18:55:56 | shashlick | what version would you want it tagged as |
18:56:06 | FromGitter | <mratsim> yeah finally 64-bit choosenim on windows :p |
18:56:19 | dom96 | 0.3.4 I guess |
18:56:37 | shashlick | we have new features though - installing binaries on windows |
18:56:47 | shashlick | a year's worth of code fixes |
18:57:11 | dom96 | alright, 0.4.0 is fine with me too |
18:57:32 | FromGitter | <mratsim> yeah I agree 0.4 is better |
18:57:33 | shashlick | 30 commits - https://github.com/dom96/choosenim/compare/v0.3.2...master |
18:58:12 | shashlick | okay i'll send you binaries later today, will post on bintray |
18:58:29 | shashlick | i made another init.sh PR for msys support |
18:58:49 | dom96 | cool |
18:58:54 | dom96 | bbl |
18:59:02 | shashlick | it might help to make the init.sh posted on http://nim-lang.org to just forward to github |
18:59:27 | shashlick | https://raw.githubusercontent.com/dom96/choosenim/master/scripts/choosenim-unix-init.sh |
18:59:47 | shashlick | that way we don't need to update it there for every change here |
19:11:45 | * | jjido joined #nim |
19:17:50 | * | glassofethanol joined #nim |
19:17:56 | * | glassofethanol left #nim (#nim) |
19:20:31 | * | Jesin joined #nim |
19:28:39 | * | nsf quit (Quit: WeeChat 2.4) |
19:35:43 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
19:40:15 | dom96 | shashlick, It's really trivial to change |
19:42:10 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
19:43:35 | shashlick | Ok just want to avoid boring you for simple things |
19:44:12 | shashlick | https://github.com/dom96/choosenim/pull/115 |
19:44:42 | * | onionhammer quit (Quit: WeeChat 1.9.1) |
19:47:36 | * | onionhammer joined #nim |
19:57:18 | * | rnrwashere joined #nim |
19:57:26 | * | smitop joined #nim |
20:03:16 | * | jjido joined #nim |
20:07:12 | * | rnrwashere quit (Remote host closed the connection) |
20:10:47 | * | rnrwashere joined #nim |
20:19:57 | shashlick | done |
20:20:08 | * | al_ joined #nim |
20:30:13 | * | kapil____ quit (Quit: Connection closed for inactivity) |
20:30:48 | FromGitter | <jrfondren> but you're keeping the comment? :) |
20:31:57 | shashlick | ? |
20:33:10 | shashlick | are mac binaries able to run on any osx version or do you need to compile them in some special way |
20:33:27 | dom96 | hrm, good question, not sure |
20:34:13 | shashlick | okay how did you compile choosenim for osx? just on your laptop? |
20:34:41 | dom96 | yep |
20:34:49 | dom96 | I can do that anyway since I'm on a mac |
20:35:06 | shashlick | okay |
20:35:18 | shashlick | for linux, did you build in some special way, besides older linux? |
20:35:31 | shashlick | wondering about any static binaries |
20:35:33 | FromGitter | <jrfondren> I mean the "TODO: add a -y to this next line" comment that's on the line prior |
20:35:49 | shashlick | aww shucks 😄 |
20:37:46 | * | kapil____ joined #nim |
20:38:16 | dom96 | AFAIK no, all deps are listed here https://github.com/dom96/choosenim#dependencies |
20:38:25 | dom96 | before you build this, let me fix something |
20:39:02 | shashlick | i'll build on holy build box so it will work almost anywhere since 2011 |
20:39:13 | dom96 | awesome |
20:40:11 | FromGitter | <jrfondren> https://grokbase.com/t/gg/golang-nuts/1414vat1em/go-nuts-mac-os-binary-compatibility suggests there are some issues with macOS over versions. |
20:40:37 | FromGitter | <jrfondren> otool -L on a nim-compiled binary here has just this dynamic link: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5) |
20:41:58 | dom96 | ugh, I swear, VS code launching nimsuggests that use 200% CPU is sooo annoying |
20:42:42 | * | JustASlacker quit (Ping timeout: 246 seconds) |
20:42:59 | dom96 | yay jester passes on travis |
20:43:46 | dom96 | v0.4.2 tagged with the 0-day fix |
20:43:54 | shashlick | okay pulling |
20:44:19 | shashlick | do you really need the .exe package, or is the zip good enough |
20:45:01 | shashlick | okay looks like you are talking about jester |
20:46:40 | shashlick | dom96 were you making any changes to choosenim as well or should I build binaries with v0.4.0? |
20:47:58 | dom96 | I was |
20:48:01 | dom96 | just a little fix |
20:48:04 | dom96 | shouldn't take long |
20:52:58 | * | lritter quit (Ping timeout: 245 seconds) |
20:53:19 | shashlick | okay no rush, i'll wait |
21:02:55 | * | rnrwashere quit (Remote host closed the connection) |
21:07:58 | * | sz0 quit (Quit: Connection closed for inactivity) |
21:19:03 | * | rnrwashere joined #nim |
21:20:23 | * | al_ quit (Quit: al_) |
21:22:29 | * | shashlick quit (Remote host closed the connection) |
21:22:48 | * | chickendan quit (Quit: Quit) |
21:22:54 | * | shashlick joined #nim |
21:23:07 | * | rnrwashere quit (Ping timeout: 240 seconds) |
21:24:00 | * | Tyresc joined #nim |
21:29:24 | * | Vladar quit (Remote host closed the connection) |
21:35:33 | shashlick | does this actually work - nimble build -d:release |
21:35:54 | dom96 | nimble build defaults to -d:release |
21:35:58 | dom96 | AFAIK |
21:36:08 | dom96 | so `choosenim versions` is broken :/ |
21:37:47 | dom96 | ahh: Request forbidden by administrative rules. Please make sure your request has a User-Agent header |
21:38:54 | shashlick | i thought nimble build was debug |
21:40:04 | * | Trustable quit (Remote host closed the connection) |
21:45:03 | * | solitudesf quit (Ping timeout: 245 seconds) |
21:46:34 | dom96 | as a side note libcurl is really nice to work with |
21:46:41 | dom96 | shashlick, 0.4.0 tagged |
21:46:58 | dom96 | please make sure you're compiling with osinfo >= 0.3.0 |
21:47:01 | shashlick | nifty - am working on the linux hbb |
21:47:04 | dom96 | best to use `nimble build` to make sure |
21:47:29 | shashlick | so you sure nimble build is release right? all this time i thought it was debug |
21:48:20 | dom96 | pretty sure, but you can verify by using Ctrl+C and seeing if there is a stack trace |
21:49:01 | * | I_Right_I quit (Remote host closed the connection) |
21:52:04 | dom96 | travis failure :( |
21:54:07 | dom96 | Error: Incorrect .nimble file: /Users/dom/.nimble/pkgs/nimble-0.9.0/nimble.nimble does not contain a version field. |
21:54:15 | dom96 | Nimble is just completely broken right now on HEAD Nim :( |
21:55:01 | shashlick | doesn't look like build sets -d:release, it does on install |
21:55:47 | shashlick | that's weird, it was working for me all this time |
21:56:37 | shashlick | well, i'm seeing the same with choosenim build now |
21:56:46 | shashlick | it is if you use nimble as a package |
21:57:14 | shashlick | well, actually i fix that in #634 |
21:57:17 | shashlick | #635 |
21:57:22 | dom96 | this is just me trying to install Nimble |
21:57:34 | shashlick | at least on windows, ospaths cannot be imported in devel anymore, it is broken |
21:58:09 | dom96 | well, I have no way to tell what else depends on osinfo 0.2.0 (https://travis-ci.org/dom96/choosenim/jobs/521930512#L760) |
21:58:15 | dom96 | maybe you can take a look |
21:58:42 | dom96 | and also, please look into this error. It's super weird and I bet it's some nimscript silliness once again (likely a VM bug) |
21:59:45 | shashlick | when do you think you can look at #635 |
22:07:20 | shashlick | i built a binary but it complains libcrypto.so is missing on my ubuntu |
22:08:39 | shashlick | meh, never mind, i built a 32-bit linux, obviously it won't run on my real 64-bit machine |
22:08:56 | dom96 | once again, 32bit linux is practically non-existant |
22:08:58 | dom96 | we don't need it |
22:09:24 | FromGitter | <jrfondren> not less you're targeting CentOS 5 :) |
22:10:28 | shashlick | 😄 |
22:10:36 | shashlick | well, i have a binary if anyone cares |
22:11:47 | dom96 | if you want to get fancy then build us an arm binary :P |
22:12:26 | shashlick | it's doable with dockcross |
22:12:46 | shashlick | https://github.com/dockcross/dockcross |
22:13:00 | shashlick | but assuming all deps work as expected |
22:13:40 | shashlick | tell me which ones you want and i can try |
22:14:30 | dom96 | I'll try to review tomorrow |
22:14:37 | dom96 | your nimble pr |
22:14:48 | shashlick | cool |
22:14:56 | dom96 | anyway, arm would be nice since there were people that wanted it |
22:15:09 | shashlick | there's many arms in dockcross, which ones? |
22:15:29 | dom96 | it'll take forever for Nim to build on an RPi so I'm guessing most will give up though |
22:15:48 | FromGitter | <jrfondren> linux-arm7 (maybe a?) or linux-arm64 |
22:15:57 | dom96 | research which one's most popular |
22:16:07 | dom96 | in particular whichever one is the RPi |
22:16:14 | dom96 | see you later |
22:16:23 | FromGitter | <jrfondren> most consumer arm 32-bit I believe, but there are some server ARMs out there that are aarch64 |
22:17:16 | shashlick | okay project for another day, but will try |
22:17:34 | shashlick | looks like it is dockcross/linux-armv6 |
22:20:22 | FromGitter | <jrfondren> "The port is necessary because the official Debian wheezy armhf release is compatible only with versions of the ARM architecture later than the one used on the Raspberry Pi (ARMv7-A CPUs and higher, vs the Raspberry Pi's ARMv6 CPU).", from Raspbian FAQ, so that's probably what you want even though newer rPI can also support aarch64 -- raspbian may still not have libs for that |
22:36:53 | shashlick | So what's being asked is a nightly build of Nim itself for RPi |
22:37:37 | shashlick | Building a choosenim for RPi isn't as useful since it will sit and build Nim from scratch anyway |
22:38:19 | shashlick | I have no way to test though so if someone can do that, I can make a build |
22:38:51 | FromGitter | <jrfondren> if someone can build choosenim for rpi? |
22:40:04 | * | iLiquid quit (Quit: iLiquid) |
22:45:30 | * | stefanos82 quit (Remote host closed the connection) |
22:51:10 | * | krux02 quit (Remote host closed the connection) |
22:51:58 | shashlick | No I mean someone can test the nim build I make on an actual RPi |
22:52:16 | * | dddddd quit (Remote host closed the connection) |
22:52:18 | rayman22201 | I've got an old rpi 2B+ laying around |
22:53:04 | rayman22201 | not the fanciest new one, but should get the job done |
22:56:04 | * | dddddd joined #nim |
22:56:46 | shashlick | So how many purple want |
22:57:04 | shashlick | Ugh how many people want to run Nim on the rpi |
22:57:30 | shashlick | You'd think you'd rather cross compile on a regular machine |
22:57:45 | shashlick | Is there a gcc that runs on the RPi |
22:57:50 | FromGitter | <jrfondren> yeah of course. |
22:58:01 | FromGitter | <jrfondren> I've a pi3 here in a laptop form factor -- the pitop |
22:58:19 | rayman22201 | neat |
22:58:54 | rayman22201 | I can give you ssh access to mine if you want shashlick. I trust you won't turn my home network into a botnet :-P |
23:01:15 | shashlick | Haha I'll be good :) |
23:01:29 | shashlick | Ok give me some time to play with dock cross |
23:02:00 | FromGitter | <arnetheduck> https://ownyourbits.com/2018/06/27/running-and-building-arm-docker-containers-in-x86/ |
23:03:30 | FromGitter | <arnetheduck> see https://github.com/status-im/nim-docker/blob/master/.travis.yml for building nim for arms on docker (times out on travis, qemu is a bit slow, but works locally on any x86_64) |
23:03:54 | rayman22201 | ok. np. I have to find the power cord for it and give it an ip address anyway :-P |
23:05:07 | FromGitter | <arnetheduck> you can then build any binaries you like, in there, including choosenim |
23:05:18 | shashlick | @arnetheduck - looks like you have figured that out already |
23:05:47 | shashlick | Did you consider dock cross? |
23:06:05 | * | [rg] joined #nim |
23:08:22 | FromGitter | <arnetheduck> that's different afair. cross-toolchains create binaries for a different target platform but can't run the resulting binary. what I linked above runs an actual arm gcc/nim inside a docker, there's no cross-compiling involved - you can also run the resulting binary directly in there |
23:08:59 | shashlick | That's cool, might add that into nightlies |
23:09:06 | shashlick | Since we run tests as well |
23:10:01 | shashlick | Of course I need to add osx binaries first! |
23:10:03 | FromGitter | <arnetheduck> we might use something along those lines to distribute binaries for arm for nimbus, eventually, but it's not finished yet. cross-compiling is (a lot) faster (no qemu) but you can't run your tests, like you want. |
23:10:21 | shashlick | And then add functionality in choosenim to install from nightlies |
23:10:30 | shashlick | And then this, and then that |
23:10:40 | shashlick | Never ending man |
23:11:24 | FromGitter | <arnetheduck> I wouldn't know. I removed choosenim as it causes lots of issues I'm in no mood to investigate |
23:20:14 | * | kapil____ quit (Quit: Connection closed for inactivity) |
23:21:19 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
23:30:50 | shashlick | I've had good experience with choosenim - what has bothered you so far? |
23:37:07 | * | dddddd quit (Remote host closed the connection) |
23:40:13 | disruptek | i couldn't make it work consistently and it seemed too opinionated to work with. |
23:54:06 | shashlick | What's your workflow |
23:57:28 | shashlick | The way I use it is to install all stable releases |
23:58:08 | shashlick | And use git clone for devel and point to that when I want devel |
23:59:00 | FromGitter | <arnetheduck> I have a couple of nims installed, as well as nlvm.. it tends to confuse which nim std lib it should be using, when there are a few of them |
23:59:47 | rayman22201 | I tend to just pull from git myself. But I have had the wrong stdb lib problem several times when using choosenim. |