| 00:01:19 | FromGitter | <awr1> Hmm |
| 00:01:32 | FromGitter | <awr1> you can't place a lower bound on length of varargs[T] |
| 00:01:33 | FromGitter | <awr1> right? |
| 00:01:38 | shashlick | what i mean is build the header files into object files and then link them to the final binary |
| 00:02:09 | zacharycarter | yeah that's what I was thinking you meant - okay let me try that |
| 00:02:38 | shashlick | nested struct/union/enum support is coming in ast2 |
| 00:02:47 | zacharycarter | sweeet |
| 00:02:54 | shashlick | took a couple hours, amazing, this new arch |
| 00:02:57 | FromGitter | <awr1> trying to think if these signatures should be just `varargs[T]` or `x, y: T; z: varargs[T]` |
| 00:03:40 | FromGitter | <awr1> I suppose i could just add a `when args.len < 2` |
| 00:14:15 | * | JohnAD quit (Ping timeout: 260 seconds) |
| 00:17:33 | * | Trustable quit (Remote host closed the connection) |
| 00:21:28 | FromGitter | <awr1> https://github.com/nim-lang/Nim/pull/13985 |
| 00:28:43 | * | fputs quit (Quit: WeeChat 2.8) |
| 00:28:50 | FromDiscord | <clyybber> nice! |
| 00:29:01 | FromDiscord | <clyybber> I think this approach is the best |
| 00:29:39 | * | aEverr quit (Ping timeout: 260 seconds) |
| 00:30:21 | * | aEverr joined #nim |
| 00:36:54 | * | icebattle quit (Ping timeout: 256 seconds) |
| 00:48:57 | zacharycarter | shashlick: so I can produce an object file for the cpp source or the objc source - but then I have different problems with each |
| 00:49:17 | FromGitter | <timotheecour> can anyone please merge https://github.com/nim-lang/Nim/pull/13984 to unbreak nim CI? |
| 00:49:34 | zacharycarter | with the cpp source, when I try to compile my nim sources with the C compiler and link to it, I get an error about algorithm.h, which is a cpp header |
| 00:50:11 | zacharycarter | if I compile the objc sources, and compile my nim sources with the cpp backend I get errors because of name mangling and definitions not being found for importc |
| 00:50:33 | zacharycarter | is there a way to get nimterop to use the importc pragma and be explicit about what definition is being imported? |
| 00:51:22 | zacharycarter | I guess the first way doesn't make much sense - I can't really link a cpp object file when using a c compiler |
| 00:55:10 | zacharycarter | or I guess I can |
| 00:57:51 | * | icebattle joined #nim |
| 01:08:44 | * | icebattle quit (Ping timeout: 265 seconds) |
| 01:10:05 | zacharycarter | yay got it to work |
| 01:10:13 | zacharycarter | just had to link libc++ and use the c++ linker |
| 01:10:16 | Prestige | Is nimlsp supposed to be showing diagnostic info? I don't seem to be getting any error/warning info |
| 01:10:20 | * | chemist69 quit (Ping timeout: 246 seconds) |
| 01:12:34 | * | chemist69 joined #nim |
| 01:12:51 | * | pbb quit (Ping timeout: 272 seconds) |
| 01:14:48 | * | ryan__ joined #nim |
| 01:16:53 | * | Prestige quit (Quit: Prestige) |
| 01:17:14 | * | Prestige joined #nim |
| 01:17:33 | * | ryan_ quit (Ping timeout: 256 seconds) |
| 01:22:13 | * | icebattle joined #nim |
| 01:26:32 | * | icebattle quit (Ping timeout: 256 seconds) |
| 01:26:37 | * | lritter quit (Ping timeout: 265 seconds) |
| 01:27:06 | * | lritter joined #nim |
| 01:27:14 | * | icebattle joined #nim |
| 01:29:39 | * | ryan__ is now known as number_one |
| 01:30:25 | * | MightyJoe joined #nim |
| 01:32:11 | * | cyraxjoe quit (Ping timeout: 260 seconds) |
| 01:38:08 | * | cyraxjoe joined #nim |
| 01:39:34 | * | MightyJoe quit (Ping timeout: 240 seconds) |
| 01:44:25 | * | MightyJoe joined #nim |
| 01:44:59 | * | cyraxjoe quit (Ping timeout: 265 seconds) |
| 01:47:30 | * | Hexeratops joined #nim |
| 01:50:04 | shashlick | Yes was about to say that |
| 01:50:08 | shashlick | Awesome |
| 01:51:52 | zacharycarter | thanks for the protip |
| 02:05:39 | * | JohnAD joined #nim |
| 02:07:42 | * | endragor joined #nim |
| 02:14:28 | * | bunbunbunbunny joined #nim |
| 02:23:09 | * | muffindrake quit (Ping timeout: 246 seconds) |
| 02:25:26 | * | muffindrake joined #nim |
| 02:30:03 | * | icebattle quit (Read error: Connection reset by peer) |
| 02:38:40 | * | icebattle joined #nim |
| 02:44:57 | Prestige | Anyone familiar with xlib? I'm attempting to use XGrabPointer, and if I click on the root window I will get an error "BadWindow (invalid Window parameter)". Just attempting to pass in the event's window/root/subwindow, they all give that error |
| 02:47:41 | Prestige | ah I needed to check if it was of type x.None |
| 02:58:06 | * | audiofile quit (Ping timeout: 258 seconds) |
| 03:00:43 | * | opal quit (Ping timeout: 240 seconds) |
| 03:01:12 | * | Hexeratops quit (Read error: Connection reset by peer) |
| 03:03:54 | * | opal joined #nim |
| 03:08:54 | * | dddddd quit (Ping timeout: 240 seconds) |
| 03:20:43 | FromDiscord | <Varriount> Hm, what would I call an iterator that returns a stream of file path component indices? |
| 03:21:33 | leorize | componentSlices |
| 03:22:09 | FromDiscord | <Varriount> leorize: Thanks. |
| 03:22:44 | FromDiscord | <Varriount> It's frustrating trying to design the API for this path library, because what's convenient isn't what's efficient, and there's not an easy way to bridge the two. |
| 03:47:38 | FromDiscord | <Varriount> Araq: With distinct types, is there any way of avoiding the gymnastics required for conversions across generic containers, something like `var foo = LinkedList[ParentType](variableOfLinkedListChildType)`? |
| 04:05:10 | * | nsf joined #nim |
| 04:06:02 | * | supakeen quit (Quit: WeeChat 1.9.1) |
| 04:06:43 | * | supakeen joined #nim |
| 04:19:34 | * | zacharycarter quit (Ping timeout: 240 seconds) |
| 04:48:01 | * | Intensity joined #nim |
| 05:25:16 | FromGitter | <awr1> @Varriount can you clarify what you're asking |
| 05:27:13 | * | thomasross quit (Ping timeout: 264 seconds) |
| 05:29:08 | FromGitter | <awr1> are you asking for ways to decrease verbosity of that |
| 05:30:18 | * | rockcavera quit (Remote host closed the connection) |
| 05:31:34 | * | icebattle quit (Ping timeout: 256 seconds) |
| 05:35:25 | FromGitter | <awr1> if you know the mapping from child to its parent type, you could make a template that takes a type and returns a type |
| 05:43:16 | * | narimiran_ joined #nim |
| 05:52:19 | * | arielfe joined #nim |
| 05:54:22 | arielfe | i really want to learn nim, but also thinking about lisp. i have read interesting things about the way using lisps might help promote a deeper understanding of programming. do you i can have the same experience by learning and using nim? |
| 05:55:26 | Zevv | Nope, nothing compares to lisp. |
| 05:55:59 | arielfe | i see. thats what i thought. well - ill just have to do it as quickly as possible and then come back to nim :) |
| 05:56:33 | Zevv | But there is no reason to do both, and they're kind of different beast. Lisp brings you nirvana, but Nim is a powerful practical workhorse. |
| 05:57:00 | Zevv | For lisp, work your way through "Structure and Interpretation of Computer Programs" and you will see the light |
| 05:57:05 | Zevv | https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/1a-overview-and-introduction-to-lisp/ |
| 05:57:08 | arielfe | thats exactly what i was thinking :) |
| 05:58:29 | arielfe | yes the famous SICP book :) - which brings up another question - should i start from it? or some more introductory material for lisp and then move on to it? |
| 06:01:11 | * | waleee-cl joined #nim |
| 06:02:31 | * | gmpreussner quit (Ping timeout: 256 seconds) |
| 06:04:03 | * | gmpreussner joined #nim |
| 06:06:05 | * | PMunch joined #nim |
| 06:06:57 | * | icebattle joined #nim |
| 06:09:00 | arielfe | ok got all the answers i needed from searching and the start of the lecture you linked. Thanks a lot :) Zevv |
| 06:11:07 | * | arielfe quit (Remote host closed the connection) |
| 06:12:08 | * | icebattle quit (Ping timeout: 256 seconds) |
| 07:00:00 | * | gmpreussner quit (Quit: kthxbye) |
| 07:04:59 | * | gmpreussner joined #nim |
| 07:06:04 | Prestige | PMunch: does nimlsp report diagnostics? It looks like it should, looking at the README. My lsp client isn't reporting any, didn't know if it's because of nimlsp or a misconfiguration on my end |
| 07:06:27 | PMunch | Define diagnostics |
| 07:07:47 | Prestige | Syntax warnings/errors, like incorrect params, unmatched quotes and parens, etc |
| 07:08:13 | PMunch | Oh yeah, those should show up |
| 07:08:47 | * | neceve joined #nim |
| 07:09:22 | Prestige | Thanks, I'll dig into my coc-nvim setup then to see what's going wrong |
| 07:11:24 | PMunch | It only appears on file save though |
| 07:31:43 | * | jjido joined #nim |
| 07:41:18 | * | MarderIII joined #nim |
| 07:41:36 | * | bunbunbunbunny quit (Quit: Lost terminal) |
| 07:56:54 | * | Vladar joined #nim |
| 08:08:03 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 08:12:34 | number_one | Hey, maybe a weird question, anybody have any ideas for removing terminal styling from lines in files? |
| 08:13:17 | PMunch | number_one, this might help: https://github.com/PMunch/ansiparse |
| 08:13:55 | PMunch | Simply parse it with that, then go through and only pick out the kind == String entries |
| 08:16:54 | Prestige | PMunch: I seem to be getting autocompletion from nimlsp but nothing about diagnostics? Like if I declare let foo: string = 123, nothing shows. Is that expected? |
| 08:17:08 | Prestige | I thought maybe the lsp wasn't working at all, but I am getting completion |
| 08:19:32 | PMunch | Hmm, even when saving the file? |
| 08:19:53 | Prestige | Yeah :/ |
| 08:20:27 | Prestige | Idk if you have touched coc-nvim at all (it's what I'm using) but their docs for setting up for nimlsp seems really straightforward. Idk what I could be missing |
| 08:20:46 | PMunch | Well, either nimlsp doesn't get the save message, or it fails to check your code for some reason, or your nimlsp plugin doesn't support diagnostics, or your editor doesn't show them properly. |
| 08:21:01 | PMunch | Never even heard of it :P |
| 08:21:28 | PMunch | You could try to compile nimlsp with debug logging and see if that shines some light on the situation |
| 08:21:29 | Prestige | I have it working for a number of other languages, so maybe it isn't getting the save message |
| 08:21:46 | Prestige | Hm okay I'll try that out next |
| 08:22:31 | Prestige | only message I currently get from nimlsp is Hint: used config file '/home/redacted/.choosenim/toolchains/nim-1.2.0/config/nim.cfg' [Conf] |
| 08:24:01 | PMunch | Yeah, that comes from the compiler |
| 08:26:05 | * | dddddd joined #nim |
| 08:27:41 | Prestige | Looks like it is working https://0x0.st/iQ9A.txt |
| 08:34:20 | number_one | PMunch, thanks, this looks super helpful! |
| 08:37:01 | FromDiscord | <sealegs> This may be a dumb question, but is there a wsy to get unix time in milliseconds? |
| 08:37:13 | FromDiscord | <sealegs> way* |
| 08:40:18 | PMunch | sealegs epochTime()*1000? |
| 08:42:41 | PMunch | Prestige, yeah so it's definitely sending didSave notifications |
| 08:46:14 | Prestige | ah PMunch so a few lines down it says "versionSupport": false for publishDiagnostics |
| 08:46:21 | Prestige | I think that has something to do with it |
| 08:46:35 | Prestige | I'm not well versed with lsp though |
| 08:47:22 | * | pbb joined #nim |
| 08:49:08 | * | liblq-dev joined #nim |
| 08:49:52 | * | dwdv joined #nim |
| 08:50:34 | Prestige | found some details here https://microsoft.github.io/language-server-protocol/specification.html |
| 08:57:12 | Prestige | hm so that seems to have nothing to do with it. Looking at the output from nimlsp, I get autocompletion options but nothing back regarding diagnostics |
| 08:59:08 | PMunch | Nothing from any of these echos? https://github.com/PMunch/nimlsp/blob/master/src/nimlsp.nim#L439 |
| 08:59:54 | Prestige | Should all be here: https://0x0.st/iQ9A.txt |
| 08:59:59 | * | pbb quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 09:00:49 | * | pbb joined #nim |
| 09:03:27 | * | ftsf quit (Ping timeout: 260 seconds) |
| 09:08:33 | Prestige | Seems odd that nothing is output regarding diagnostics. Gotta go for now but I'll be back at it tomorrow, thanks for looking into it PMunch |
| 09:15:54 | * | sknebel quit (Remote host closed the connection) |
| 09:16:33 | * | sknebel joined #nim |
| 09:18:45 | * | ryan_ joined #nim |
| 09:21:03 | FromDiscord | <sealegs> PMunch, I mean like milliseconds since 1-1-1970 |
| 09:21:29 | * | number_one quit (Ping timeout: 256 seconds) |
| 09:21:49 | * | MarderIII quit (Ping timeout: 250 seconds) |
| 09:23:04 | PMunch | Yes |
| 09:23:07 | FromDiscord | <sealegs> Oh wait nvm thx, I thought epochTime() was just like toUnix() lol. |
| 09:23:16 | FromDiscord | <sealegs> My bad |
| 09:23:29 | PMunch | It's kinda in the name `epoch` in this context refers to 1-1-1970 |
| 09:23:50 | PMunch | Or rather, that is the specific epoch it refers to |
| 09:24:15 | PMunch | There are systems that use different epochs |
| 09:24:29 | FromDiscord | <sealegs> Interesting. |
| 09:25:56 | FromGitter | <kayabaNerve> Does Nim have shortcircuiting outside of and/or? |
| 09:26:32 | PMunch | I encountered it a lot when working with satellite data, they are afraid of rollover if the satellite stays up for longer than expected. But they still want to save on bandwidth since the downlink is limited. So they come up with all sorts of weird time systems in order to avoid using 64-bit timestamps |
| 09:27:18 | FromGitter | <kayabaNerve> I assume it follows C and it's only applied to and/or, and only because it compiles down to &&/||. Just checking as I'm writing a macro that needs to detect short circuiting. |
| 09:37:18 | FromDiscord | <Gary M> float queue_priorities[max_family_queues];memset(queue_priorities, 0, sizeof queue_priorities); |
| 09:37:24 | FromDiscord | <Gary M> whoops |
| 09:37:29 | FromDiscord | <Gary M> float queue_priorities[max_family_queues]; |
| 09:37:29 | FromDiscord | <Gary M> memset(queue_priorities, 0, sizeof queue_priorities); |
| 09:37:47 | FromDiscord | <Gary M> that's a pretty shitty piece of C code that I need to write similarly in Nim |
| 09:38:10 | Araq | kayabaNerve: only 'and' and 'or' do that, other constructs rely on 'if' expressions |
| 09:38:30 | FromDiscord | <Rika> let queue_priorities = newSeq[float](max_family_queues) |
| 09:38:34 | FromDiscord | <Gary M> so I did var queuePriorities = newSeq[float](maxFamilyQueues), but the whole memset thing is throwing a wrench into the equation |
| 09:38:54 | FromDiscord | <Rika> you dont need to memset it i dont think |
| 09:38:56 | Araq | Nim does the memset for you, you don't have to write anything for it |
| 09:39:05 | FromDiscord | <Gary M> oh |
| 09:39:12 | FromDiscord | <Gary M> well cool then 🙂 |
| 09:39:54 | Araq | zeroMem(addr(s[0]), sizeof(s[0]) * N) # would be the equivalent, but it's not required and harmful low level stuff |
| 09:40:49 | FromDiscord | <Rika> and is redundant too |
| 09:42:52 | FromDiscord | <Gary M> another question |
| 09:43:05 | FromDiscord | <Gary M> how do I do additional conditions in a for loop in nim |
| 09:43:12 | FromDiscord | <Rika> additional conditions? |
| 09:43:46 | FromDiscord | <Gary M> like for(int i = 1; i < 4 && i < someMaxVariable; ++i) |
| 09:43:59 | FromDiscord | <Rika> you just use a break inside the for |
| 09:44:05 | * | narimiran_ is now known as narimiran |
| 09:44:10 | narimiran | you use while loop |
| 09:44:12 | FromDiscord | <Rika> for i in something: if i < someotherthing: break |
| 09:44:28 | FromDiscord | <Rika> or that too |
| 09:44:49 | FromDiscord | <Gary M> ok, thanks |
| 09:53:19 | FromGitter | <kayabaNerve> Araq: Thanks for the confirmation. Working on Result unwrapping and the lack of short circuiting will break a lot of my code. Need to make sure I don't rely on it some place I don't think I do. |
| 09:54:32 | * | abm joined #nim |
| 09:55:51 | * | Trustable joined #nim |
| 10:10:45 | * | waleee-cl quit (Quit: Connection closed for inactivity) |
| 10:11:07 | * | krux02 joined #nim |
| 10:25:56 | FromDiscord | <Rika> how do you debug npeg stuff? |
| 10:26:07 | FromDiscord | <Rika> ah, theres a define |
| 10:31:13 | PMunch | Yea.. Most macros have that, but it's a bit random what it's called :P |
| 10:31:27 | PMunch | Even my own macros aren't consistent in what I call it.. |
| 10:32:04 | PMunch | With expandMacro it might get better, but it currently doesn't expand if the macro has an error in it, which is mostly what I use my `echo result.repr` for.. |
| 10:34:02 | * | jjido joined #nim |
| 10:57:26 | Zevv | Rika: what do you need? |
| 10:58:56 | FromDiscord | <Rika> never mind 😛 |
| 11:06:39 | FromGitter | <timotheecour> can anyone merge https://github.com/nim-lang/Nim/pull/13984 to un-break nim CI ? |
| 11:07:27 | FromDiscord | <clyybber> Done : ) |
| 11:08:16 | Zevv | Rika: ok, just ping me if you need a hand |
| 11:09:11 | FromGitter | <timotheecour> thanks @Clyybber ! |
| 11:09:58 | FromDiscord | <Rika> your docs are really good though |
| 11:10:04 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 11:10:34 | Zevv | Ah I thought it was the lack of users resulting in no support requests, but it's just the quality of the docs :) |
| 11:10:43 | Zevv | I hope |
| 11:11:52 | FromDiscord | <Rika> what do you mean lmao |
| 11:13:59 | * | jjido joined #nim |
| 11:14:52 | * | lritter quit (Quit: Leaving) |
| 11:15:07 | * | MarderIII joined #nim |
| 11:27:40 | * | sacredfrog quit (Quit: ZNC 1.7.5 - https://znc.in) |
| 11:27:43 | * | FromDiscord quit (Remote host closed the connection) |
| 11:27:45 | * | gmpreussner quit (Quit: kthxbye) |
| 11:27:58 | * | sacredfrog joined #nim |
| 11:28:03 | * | gmpreussner joined #nim |
| 11:28:16 | * | FromDiscord joined #nim |
| 11:29:21 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 11:30:53 | * | jjido joined #nim |
| 11:44:05 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 11:48:17 | * | solitudesf joined #nim |
| 11:50:40 | * | xace quit (Ping timeout: 256 seconds) |
| 11:50:58 | * | xace joined #nim |
| 12:01:16 | FromDiscord | <Recruit_main707> do we have an align prgma? |
| 12:02:37 | * | hax-scramper quit (Ping timeout: 264 seconds) |
| 12:06:02 | * | supakeen quit (Quit: WeeChat 1.9.1) |
| 12:06:42 | * | supakeen joined #nim |
| 12:09:27 | * | hax-scramper joined #nim |
| 12:10:21 | * | sunwukong joined #nim |
| 12:10:28 | Araq | yes we do |
| 12:10:48 | FromDiscord | <Recruit_main707> yes, ive found it, thanks Araq |
| 12:11:04 | * | dadada quit (Ping timeout: 256 seconds) |
| 12:12:50 | * | dadada joined #nim |
| 12:13:14 | * | dadada is now known as Guest45140 |
| 12:16:08 | * | a_b_m joined #nim |
| 12:19:41 | * | abm quit (Ping timeout: 258 seconds) |
| 12:20:32 | liblq-dev | Zevv: are you familiar with the Lua C API? |
| 12:21:06 | liblq-dev | 'cause I'm getting a "too many local variables" error for seemingly no reason |
| 12:24:17 | Araq | krux02, Scala does not have 'emit: <Java code here>' at all |
| 12:24:43 | Araq | stop your nonsense |
| 12:24:47 | krux02 | Araq: scala does not need an emit Java code here, because you can just used Java classes directly. |
| 12:24:51 | krux02 | No need to emit anything. |
| 12:24:52 | Araq | and the trollish behaviour |
| 12:25:08 | Araq | likewise C++ has no #emit feature |
| 12:25:12 | krux02 | Scala classen and Java classes with seamless. |
| 12:25:28 | krux02 | This isn't possible for C and C++ because of the lack of modules. |
| 12:25:40 | * | a_b_m quit (Quit: Leaving) |
| 12:25:41 | Araq | so what, it doesn't have an emit |
| 12:25:45 | krux02 | Maybe we might be able to do something smarter with c++ modules. |
| 12:26:05 | Araq | the RFC and PR are about "fixing" emit, but there is nothing to fix with it, it works |
| 12:26:17 | Araq | it's a sharp tool, no need to make it less sharp |
| 12:26:26 | krux02 | Araq: you are just in denial that there is a problem with emit. |
| 12:26:34 | krux02 | And that hurts the fixing process. |
| 12:26:44 | krux02 | That isn't helpful. |
| 12:27:04 | Araq | ok so enlighten me |
| 12:27:09 | Araq | where is the problem with emit? |
| 12:27:10 | krux02 | I don't need to. |
| 12:27:26 | krux02 | It is already written down by @timotheecour |
| 12:28:12 | federico3 | https://starchart.cc/nim-lang/nim.svg <-- heyy |
| 12:28:13 | Araq | it says "what if I mistype TYPESECTION?" well so what, the C code then fails to compile, otherwise the section annotation wasn't reqired to begin with |
| 12:28:54 | krux02 | maybe it fails |
| 12:29:02 | krux02 | maybe it doesn't fail and just does the wrong thing. |
| 12:29:18 | krux02 | I don't want to prove it to you. |
| 12:29:34 | FromDiscord | <Recruit_main707> federico3 wikipedia stats? |
| 12:29:40 | krux02 | It is your job to detect that here is a potential problem that should be addressed. |
| 12:30:02 | federico3 | Recruit_main707: github stars (FWIW) |
| 12:30:09 | FromDiscord | <Recruit_main707> nice |
| 12:30:39 | FromDiscord | <Recruit_main707> lets reach the thousand forks, 2 left! |
| 12:30:54 | Araq | krux02, it's also my job not to feed trolls |
| 12:31:08 | krux02 | Who is the troll? |
| 12:31:24 | Araq | you. |
| 12:33:32 | krux02 | Then why do you post such things like "Why do we need an even more powerful emit statement though? Why not let Nim be a real language that compiles via C or LLVM to binary code." in a conversation that tries to address detected problems with `emit`? |
| 12:33:47 | krux02 | That doesn't help the conversation at all. |
| 12:34:11 | krux02 | You are not offering a solution at all. You are just trollin the conversation with snark. |
| 12:34:26 | Araq | features must be justified well |
| 12:34:31 | krux02 | If you do so, don't get offended if I reply to you. |
| 12:34:58 | krux02 | ok |
| 12:35:05 | Araq | I like replies that don't imply "Araq is a fool, Nim is doomed" |
| 12:35:30 | * | Guest45140 is now known as dadada |
| 12:35:39 | krux02 | Then stop posting foolish stuff. |
| 12:36:01 | krux02 | Or comments that let me assume that you are in denial of problems |
| 12:36:04 | leorize[m] | eventually we should move torwards not having `emit` at all |
| 12:36:27 | Araq | I'm trying ;-) can you try the same please. |
| 12:36:54 | Araq | and "you are in denial" is 100% troll speak, just fyi |
| 12:36:54 | krux02 | ok, then admit at least that `emit` isn't perfectly designed. |
| 12:37:10 | krux02 | yes emit is a hack. But a damn useful hack that solves real problems. |
| 12:37:14 | Araq | emit is a hack, of course it's not perfectly designed |
| 12:37:20 | dadada | stop guys, just stop, this bickering is incredibly sad to see |
| 12:37:22 | Araq | it hardly was designed at all |
| 12:37:28 | krux02 | yes |
| 12:37:29 | FromDiscord | <Recruit_main707> emit is useful, i asked Araq about this and he told me we could pass the emit code by a c/cpp compiler right? |
| 12:38:08 | krux02 | Me and timothee were just discussing on ideas on how `emit` could be converted from "a hack" into a nice language feature that would also work well with editors. |
| 12:38:24 | leorize[m] | emit was a hack for the lack of proper interop fwiw |
| 12:38:42 | leorize[m] | I think we should find ways to deprecate it, not making it easier to use |
| 12:38:56 | FromDiscord | <Recruit_main707> imho emit is useful because its hacky |
| 12:39:00 | leorize[m] | the reason why emit is ugly is because you're not supposed to use it |
| 12:39:14 | FromDiscord | <Recruit_main707> it allows you to do some dirty things to avoid complex things |
| 12:39:29 | krux02 | please don't teach me about emit. |
| 12:39:36 | FromDiscord | <Recruit_main707> (at least thats how i use it) |
| 12:39:39 | krux02 | I know what it is good for and when it should be avoided. |
| 12:40:16 | FromDiscord | <Recruit_main707> i still dont get whats all of this for, redesigning emit? |
| 12:40:43 | krux02 | When there is a proper way to do it, always do the proper thing. The problem is, C++ is a very dirty language with preprocessor magic and weird syntax for compiler secific features that can best be accessed with `emit`. |
| 12:41:31 | krux02 | Recruit_main707: The problem is, we were just discussing emit and how to improve it. |
| 12:41:38 | krux02 | Because there are things that don't work well with it. |
| 12:42:22 | leorize | I generally think that the syntax is fine, if that's what you wanna change |
| 12:42:40 | krux02 | here is the context: https://github.com/nim-lang/RFCs/issues/210 |
| 12:43:54 | Araq | exactly, that's the *context* but there is no *motivation* and no *justification* |
| 12:44:35 | krux02 | whatever |
| 12:44:54 | Araq | it simply says "I don't like triple quoted strings and I want indentation based strings" and then conflating it with .emit and its quirks |
| 12:45:49 | * | abm joined #nim |
| 12:45:56 | krux02 | It is a discussion. |
| 12:46:23 | krux02 | not a finished proposal |
| 12:46:40 | Araq | it could start with a problem statement though. |
| 12:46:43 | leorize | so apparantly the main bug that I can see here is that `backticks` captures in emit have unclear semantics |
| 12:47:26 | krux02 | There are multiple problems with emit. |
| 12:47:27 | * | Tyresc joined #nim |
| 12:47:31 | krux02 | The backticks are one of them |
| 12:47:52 | * | rockcavera joined #nim |
| 12:47:52 | krux02 | The magic comment like /*TYPESECTION*/ is also one of them. |
| 12:47:57 | FromDiscord | <clyybber> I don't like the part of the proposal to put emit and asm out of the triple quoted string literals |
| 12:48:08 | krux02 | commants arn't supposed to have semantic. |
| 12:49:10 | krux02 | The last one is. I have a C code within Nim code. My editor can highlight C code nicely: Is there a reliable way to tell my editor to highlight a subset of my file as C instead of Nim? |
| 12:49:26 | FromDiscord | <clyybber> Thats an editor problem |
| 12:49:50 | leorize | yes, highlight a region that starts with `{.emit:\s+"""` and ends with `"""\.\?}` |
| 12:49:54 | krux02 | clyybber: that is means the language doesn't need to care about how hard it is for the editor to support it? |
| 12:49:58 | FromDiscord | <clyybber> Yeah |
| 12:50:01 | krux02 | no |
| 12:50:04 | krux02 | I disagree. |
| 12:50:06 | FromDiscord | <clyybber> And also its not hard |
| 12:50:29 | leorize | well I just gave you how to highlight inline C code :P |
| 12:50:53 | krux02 | leorize, that would work |
| 12:50:53 | Araq | how exactly are "indentation based string literals" easier for the editor support? |
| 12:51:31 | Araq | and are we even talking about "indentation based string literals (via asm?)" or are we talking about emit |
| 12:52:06 | * | Trustable quit (Remote host closed the connection) |
| 12:52:18 | Araq | this is all messed up, which is why I seek to close both the RFC and the PR fwiw |
| 12:52:18 | * | chemist69 quit (Quit: WeeChat 2.7) |
| 12:52:26 | * | hpyc9 quit (Quit: FREENODE IS FUCKING GAY) |
| 12:52:37 | * | hpyc9 joined #nim |
| 12:52:40 | Araq | but hey, I'm "in denial", so I re-opened it, have fun |
| 12:52:47 | krux02 | Araq: The problem with end tokens is, they might be ambiguous. A ) always closes the last opene (, An xml end tag for example is named, when you encounter </mytag> it closes the opened <mytag> |
| 12:53:12 | krux02 | that helps the editor a lot during the time when the text isn't fully written yet. |
| 12:53:16 | * | chemist69 joined #nim |
| 12:53:21 | leorize | I'd tell you that indentation-based literals make things harder to support, at least with vim |
| 12:53:37 | krux02 | incomplete stant end tokens often meke the editor rehighlight the entire file |
| 12:53:40 | FromDiscord | <clyybber> Yeah, and it also opens a whole can of worms |
| 12:53:49 | FromDiscord | <clyybber> Better to leave emit taking a string literal |
| 12:53:55 | Araq | there is an existing RFC for indentation based string literals too |
| 12:54:14 | * | zacharycarter joined #nim |
| 12:54:19 | krux02 | leorize, yes thank you, this is the type of comments I am hoping for. |
| 12:54:52 | krux02 | If you say it is really hard to support in popular editors it is an argument to not use indentation based string literals. |
| 12:55:40 | FromDiscord | <clyybber> So whats left is the enum for where we emit stuff |
| 12:56:27 | krux02 | In org-mode (emacs specific) there are code sections in other programming languages. Org mode fully supports syntax highlighting for these embedded code sections. But it does so by using very unambiguous start and end tokens. |
| 12:56:48 | krux02 | clyybber: No |
| 12:57:02 | FromDiscord | <Recruit_main707> as a side note: if youd need C++ highlight for the code inside your emit, dont you think it would be more fitting to just have it in a separate cpp file, and wrap it in nim? |
| 12:57:23 | krux02 | clyybber: Just because an idea seems to be bad. It isn't rejected yet. And if it is rejected it doesn't mean the search for an alternative is over. |
| 12:57:56 | leorize | I think it helps to present the problem and what you're trying to improve in a RFC |
| 12:57:57 | krux02 | Recruit_main707: depends |
| 12:58:05 | krux02 | not necessarily. |
| 12:58:20 | leorize | currently all I see is "I don't like this, can we change?" |
| 12:58:24 | krux02 | That is like saying you never want embedded javascript in an html document. |
| 12:58:37 | FromDiscord | <clyybber> And I really don't see whats wrong with having C code in a string literal |
| 12:58:50 | FromDiscord | <clyybber> Whats the advantage of having it without """ |
| 12:58:50 | FromDiscord | <Recruit_main707> but being that small, you should not need highlight then |
| 12:59:25 | FromDiscord | <clyybber> Its really ugly IMO since it blurs the lines between nim code and C code. Just imagine what happens to preprocessor statements |
| 12:59:37 | FromDiscord | <clyybber> Its a can of worms that need not be opened |
| 12:59:42 | FromDiscord | <clyybber> Simply use string literals |
| 13:00:00 | FromDiscord | <clyybber> And if you want to indent them write a helper and do """...""".unindent |
| 13:00:57 | dadada | how about developing indention based markdown support for Nim, that get's converted to a string in compilation, and enable an extension for this markdown that supports embedding of code including a hint for the lang, that way this feature could be reused for anything and not only emit, and editors would simply have to understand how Nim designates a markdown section (by indentation) and to support markdown |
| 13:00:57 | krux02 | leorize, there has been a lot of aggrevation of timothee's RFC's issues and pull requests. Please don't take them too serious. This what was proposed here in this PR by him was something that I mentioned in a conversation might be a good idea, and he converted it into an RFC because that is all we have right now. But to be honest it is nothing more than a proto RFC. The verbosity of timothee's style of writing RFC's |
| 13:00:57 | krux02 | make it seem more than it actually it. |
| 13:01:18 | krux02 | s/it\.\>/is./ |
| 13:01:26 | Araq | well I'm still waiting for an analysis of 'emit's problems |
| 13:01:39 | * | beatmox quit (Remote host closed the connection) |
| 13:01:53 | krux02 | tsizeof.nim |
| 13:01:58 | Araq | so far I heard arguments against triple quoted strings which we have an RFC for already. |
| 13:02:05 | * | xcm quit (Remote host closed the connection) |
| 13:02:15 | krux02 | the c_sizeof doesn't work top level because of the way `emit` works. |
| 13:02:29 | krux02 | The solution is "HERE" generation flag. |
| 13:02:39 | FromDiscord | <clyybber> So can we cut the RFC down? |
| 13:03:00 | FromDiscord | <Recruit_main707> dadada: from my complete ignorance, that seems utterly complicated and not useful |
| 13:03:02 | krux02 | clyybber: That is something that you have to figuer out with timothee. |
| 13:03:23 | krux02 | You can take the RFC over by making your own less verbose RFC that includes all the necessary information. |
| 13:03:50 | krux02 | But it really wears you down if you do it all the time. |
| 13:04:04 | FromDiscord | <clyybber> @timotheecour Can you extract the emit("here") into a seperate RFC? |
| 13:04:16 | * | xcm joined #nim |
| 13:04:36 | leorize | you know that highlighting `emit` is not hard when even github can do it :p |
| 13:04:50 | leorize | and they can't properly highlight `8'u8` literals |
| 13:04:51 | dadada | Recruit_main707: since markdown has become kind of a standard, first class lang support for it seems quite support |
| 13:04:52 | * | beatmox joined #nim |
| 13:05:07 | dadada | s/quite support/quite useful |
| 13:06:27 | leorize | sorry, but it's still no justification for overcomplicating things |
| 13:06:35 | FromDiscord | <clyybber> dadada: Sounds like you want macro DSL |
| 13:06:43 | leorize | and iirc docgen supports an RST/markdown mix |
| 13:06:44 | FromDiscord | <clyybber> This is about emit tho |
| 13:06:48 | FromDiscord | <clyybber> A builting pragma |
| 13:08:17 | Araq | btw .emit doesn't take a string literal. it takes a string literal or an array of string pieces to avoid the quoting hell |
| 13:08:54 | krux02 | Araq: yes and the array is ugly. |
| 13:08:56 | FromDiscord | <Recruit_main707> a very good decision imo |
| 13:09:18 | krux02 | It makes the potential support for syntax highlighting in emit code sections completely impossible. |
| 13:09:19 | Araq | krux02, ugly syntax for ugly semantics is a fair deal IMHO. |
| 13:09:54 | leorize | krux02: the array just make it not possible when you're using it |
| 13:10:15 | leorize | if you use the triple-quote syntax it's easy to highlight it |
| 13:10:25 | FromDiscord | <Recruit_main707> and allows some nim syntax highlight |
| 13:11:15 | leorize | case in point: github can even highlight `emit`, while they struggle with `'i32` suffixes |
| 13:12:47 | * | Vladar quit (Quit: Leaving) |
| 13:12:57 | leorize | I think the biggest issue with `emit` is how it lures the user into thinking that "the generated C code is ordered exactly like the Nim code" |
| 13:13:59 | leorize | tsizeof demonstrates this problem: you have an emit block before a `type` block (in the middle of the file), thinking that they will be added in the same order |
| 13:14:11 | FromDiscord | <mratsim> the array is ugly ... very ugly: https://github.com/mratsim/constantine/blob/master/constantine/primitives/extended_precision_64bit_uint128.nim#L32-L99 |
| 13:14:59 | * | MarderIII quit (Ping timeout: 260 seconds) |
| 13:15:04 | FromDiscord | <mratsim> interpolation would be much nicer (note this code is working by luck): https://github.com/numforge/laser/blob/master/benchmarks/transpose/transpose_bench.nim#L144-L167 |
| 13:15:48 | FromDiscord | <mratsim> I could do a macro though that transform interpolation in correct emit code |
| 13:16:06 | FromDiscord | <Recruit_main707> thats a good idea |
| 13:19:07 | Araq | mratsim: and why is that a problem? why is the real problem not identified as "Nim should support C's int128 type"? |
| 13:19:30 | * | MarderIII joined #nim |
| 13:20:38 | Araq | and why is tsizeof relevant for anything? it's a test testing nasty stuff, it's not representative for anything. |
| 13:20:39 | FromDiscord | <mratsim> the array being ugly makes it harder to write correct code |
| 13:20:58 | FromDiscord | <mratsim> it's easy to miss a parenthesis in the forest of quote and commas for example |
| 13:22:07 | krux02 | leorize, for editors it is good if there is an unambiguous regular expression to detect the beginning and the end. tripple quotes alone are ambiguous. Including the full pragma though could work. |
| 13:22:21 | FromGitter | <Clyybber> triple quotes are not ambiguous.. |
| 13:22:33 | leorize | krux02: they are not ambiguous... |
| 13:22:43 | leorize | I wrote editor plugins, I know |
| 13:23:04 | Araq | and indentation based literals have no regex to begin with. |
| 13:23:06 | krux02 | tripple quots can be any tripple quotes, how should the editor know that this string should be C code? |
| 13:23:09 | krux02 | It needs context. |
| 13:23:24 | FromGitter | <Clyybber> So look at the emit |
| 13:23:29 | leorize | krux02: I gave you the regex needed earlier |
| 13:23:35 | krux02 | I know I kno |
| 13:23:43 | krux02 | I also reference that |
| 13:23:54 | Araq | template ccode(x: untyped): untyped = x |
| 13:24:06 | Araq | .emit: ccode"""works""" |
| 13:24:24 | krux02 | Araq: yes that works |
| 13:24:31 | leorize | if markdown's inline code can be highlighted by editors, I see no problem in highlighting emit |
| 13:24:41 | krux02 | I don't think tripple quotes within C code is a thing. |
| 13:24:46 | leorize | you need a more convincing case |
| 13:24:54 | krux02 | And we don't support emitting python code. |
| 13:24:57 | FromDiscord | <mratsim> VScode properly highlight the emit code, unless "lo" appears |
| 13:25:10 | FromDiscord | <mratsim> not sure why |
| 13:25:11 | krux02 | lo? |
| 13:25:14 | FromDiscord | <mratsim> yes lo |
| 13:25:34 | FromDiscord | <mratsim> you can check with this file: https://github.com/mratsim/constantine/blob/master/constantine/primitives/extended_precision_64bit_uint128.nim#L32-L99 cs this one https://github.com/numforge/laser/blob/master/benchmarks/transpose/transpose_bench.nim#L144-L167 |
| 13:25:38 | FromDiscord | <mratsim> vs* |
| 13:25:38 | Araq | VSCode's syntax highlighting is just broken in all sort of ways |
| 13:25:41 | krux02 | mratsim: do you have a screenshot? I don't have vscode installed right now. |
| 13:25:45 | leorize | file a bug I guess, though I don't maintain that plugin :P |
| 13:26:29 | Araq | leorize, I gave up on it |
| 13:26:38 | krux02 | I maintain emacs syntax highlighting. That doesn't mean I have a solution for everything though. |
| 13:26:40 | Araq | it doesn't even understand Nim's keywords properly |
| 13:27:21 | krux02 | The process to fix nim syntax highlighting in emacs was to remove most of it. |
| 13:27:34 | FromDiscord | <mratsim> |
| 13:27:34 | FromDiscord | <mratsim> https://cdn.discordapp.com/attachments/371759389889003532/699974199934189568/2020-04-15_15-27.png |
| 13:27:44 | Araq | ^ I can imagine the same is true for VSCode's highlighter |
| 13:28:18 | FromDiscord | <mratsim> or it's the emit array that is broken |
| 13:28:25 | leorize | yea the vscode highlighter is broken |
| 13:28:49 | Araq | mratsim: how did you manage to use the same color for 'proc' and 'for'? |
| 13:29:18 | leorize | I know how to highlight that in vim, and I'll add that in just to prove the point :P |
| 13:29:24 | FromDiscord | <mratsim> afaik it's the C code highlighter |
| 13:29:44 | FromDiscord | <mratsim> or not |
| 13:29:48 | FromDiscord | <mratsim> just the color scheme |
| 13:30:12 | FromGitter | <alehander92> krux02 that indented other code idea seems interesting |
| 13:30:17 | FromGitter | <alehander92> but kinda radical |
| 13:31:19 | krux02 | alehander92: The thing about that is, if the editor can support indeted blocks of foreign code. It is impossible to mess it up. |
| 13:31:48 | krux02 | The editor won't accidentally make half of the file C code. |
| 13:31:53 | leorize | usually editors try not to care about indentation rules when highlighting |
| 13:32:01 | krux02 | leorize, that is the problem |
| 13:32:22 | Araq | 5 minutes ago you argued for regex based highlighting though |
| 13:32:59 | krux02 | I am just explaining my reasoning behind the indentation besed idea. |
| 13:33:07 | krux02 | currently they are both ideas. |
| 13:33:16 | krux02 | I did not fully reject any of them. |
| 13:33:37 | FromGitter | <alehander92> ok but how many editors can do it |
| 13:33:52 | FromGitter | <alehander92> i'd guess markdown support is the closest thing |
| 13:34:01 | * | nc-x joined #nim |
| 13:34:02 | FromGitter | <alehander92> if most ide-s support markdown with random code in sections |
| 13:34:08 | krux02 | mratsim: thanks a lot for the screenshot. I had no idea on its support for C syntax highlighting in Nim code. |
| 13:34:12 | FromGitter | <alehander92> this might be achievable |
| 13:34:30 | FromGitter | <alehander92> but i find something else bad |
| 13:34:39 | krux02 | alehander92: you mean gihub markdown? |
| 13:34:40 | FromGitter | <alehander92> if you have long C/JavaScript snippets |
| 13:34:47 | FromGitter | <alehander92> yes, sorry |
| 13:34:54 | krux02 | ```nim <--- not standard markdown |
| 13:35:06 | FromGitter | <alehander92> so if you have those, you can open nim files and just look at a lot of random otherlanguage highlighted code |
| 13:35:10 | FromGitter | <alehander92> and this is somehow confusing |
| 13:35:20 | companion_cube | Araq: fwiw, vscode will move to tree-sitter, I think? which is more powerful than regexes |
| 13:35:23 | FromGitter | <alehander92> like, e.g. rst/github markdown: one expects |
| 13:35:29 | FromGitter | <alehander92> that |
| 13:35:41 | FromGitter | <alehander92> i can think mostly of html/php as other examples of this style |
| 13:35:57 | krux02 | mratsim: this `lo` in code that breaks everything doen't make sense at all for me. |
| 13:36:08 | krux02 | alehander92: yes |
| 13:36:14 | krux02 | also html/javascript |
| 13:36:27 | krux02 | or JSP |
| 13:36:33 | FromDiscord | <mratsim> @krux02, I think it aws the "{.emit:[" syntax |
| 13:37:02 | FromDiscord | <mratsim> lo just happened to be at the beginning when I noticed highlight breakage |
| 13:37:13 | FromDiscord | <mratsim> I think it's* |
| 13:38:30 | nc-x | well, vscode just stabilized semantic highlighting a few days ago. And I think nimsuggest already provides that output (leorize's nvim.nim uses it for semantic highlighting IIRC) |
| 13:38:41 | krux02 | since you actually use the `emit` statement your opinion on this idea we just discussed might be important: https://github.com/nim-lang/RFCs/issues/210 |
| 13:38:45 | nc-x | so somebody just needs to add support in the vscode nim plugin |
| 13:38:54 | krux02 | but don't participate in anying emotianl stuff. |
| 13:38:57 | FromDiscord | <mratsim> @Araq, regarding int128 support in Nim, it's a good idea but I think providing MSVC API is probably easier to support on most platform: https://github.com/mratsim/constantine/blob/master/constantine/primitives/extended_precision_x86_64_msvc.nim#L24-L31 |
| 13:39:09 | krux02 | Only in ideas, becauese it is just an idea, nothing more. |
| 13:40:19 | * | jjido joined #nim |
| 13:42:16 | * | nc-x quit (Remote host closed the connection) |
| 13:42:23 | zacharycarter | I have a app built with --gc:arc that is loading a shared library and calling a function in it via the dynlib module |
| 13:42:31 | Araq | and here is the other, older RFC https://github.com/nim-lang/RFCs/issues/161 |
| 13:42:40 | krux02 | mratsim: Are you talking about `int128` as a builtin type that is just supported, or are you talking about the internal `int128`? |
| 13:42:44 | zacharycarter | It's being passed a ref object and I'm assigning a value to a field defined in the object |
| 13:43:25 | zacharycarter | I'm then creating another object and passing that to some C code, and I'm copying that field's value into another field in this new object |
| 13:44:01 | zacharycarter | my program hangs when the c code tries to dereference the cstring for value assignment |
| 13:44:12 | zacharycarter | because of an EXC_BAD_ACCESS |
| 13:44:23 | krux02 | zacharycarter, my recommendation: debug it. |
| 13:44:39 | krux02 | but build without line information, just with debug information. |
| 13:44:49 | FromGitter | <alehander92> guys |
| 13:44:50 | zacharycarter | okay |
| 13:44:53 | krux02 | Then you debug the generated C code, that allows you to spot incorrect code generation.. |
| 13:44:53 | FromGitter | <alehander92> sorry for offtopic |
| 13:45:03 | FromGitter | <alehander92> especially krux02 as you are good with debug/codegen |
| 13:45:13 | FromGitter | <alehander92> how should i generate lineinfo-s for generated nodes |
| 13:45:28 | FromGitter | <alehander92> with copyLineInfo or with other more idiomatic way? |
| 13:45:41 | krux02 | alehander92: currently you can't set the line information for generated nodes. |
| 13:46:09 | krux02 | you can set the line information of other already existing nodes though. |
| 13:46:12 | FromDiscord | <mratsim> @krux02 we were talking about the runtime int128, not the one in the compiler |
| 13:46:17 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 13:46:22 | krux02 | yes copyLineInfo is the only option right now |
| 13:46:31 | krux02 | mratsim: ok |
| 13:47:50 | krux02 | but as soon as runtime `int128` is supported as a builtin type the internal integer must be lifted to int256, or at least `int129` (if that is even a thing) to reintroduce all the problems the compiler had before the internal `int128` was introduced. |
| 13:48:02 | FromGitter | <alehander92> krux02 sorry, that's what i mean |
| 13:48:45 | FromGitter | <alehander92> e.g. if i generate a procedure, and i copyLineInfo to the symbol node of its name / the node of the iterator itself, this should work for linedir |
| 13:49:10 | FromDiscord | <mratsim> it doesn't need to be a builtin type and there is no need to allow compile-time computation on it |
| 13:49:34 | FromDiscord | <mratsim> for starter, just allowing additoon/substraction/negate/multiplication/division/shifts is good |
| 13:50:05 | FromDiscord | <mratsim> and to be cross-OS, you probably need an umul128 and udiv128 |
| 13:51:31 | FromDiscord | <mratsim> and otherwise if we want to allow compile-time compilation of those, it probably makes more sense to have a generic fixed precision library in the compiler like LLVM APInt |
| 13:54:57 | Araq | that's all true, I hesitate to do that because of the Nim VM |
| 13:55:41 | * | waleee-cl joined #nim |
| 13:55:48 | Araq | a VM that uses bigints for a language that otherwise uses machine integers is a recipe for inconsistencies. though extensive testing helps. |
| 13:55:58 | * | jjido joined #nim |
| 13:57:28 | FromDiscord | <mratsim> If you want the same representation as what an "wide-integer" would be in an underlying platform, it's just a "when cpuEndian == bigEndian" switch away |
| 13:58:19 | Araq | it's also diverse bitmask operations away |
| 13:58:30 | FromDiscord | <mratsim> besides Stint which only operates on power of 2, in constantine I also have my own VM compatible bigint library and it can operate on weird sizes like BigInt[17] or BigInt[381] |
| 13:59:49 | * | chemist69 quit (Ping timeout: 272 seconds) |
| 14:00:53 | * | chemist69 joined #nim |
| 14:05:20 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 14:22:11 | FromGitter | <sealmove> how to make this work? https://play.nim-lang.org/#ix=2i9x |
| 14:24:37 | * | Cadey is now known as Xe |
| 14:25:39 | shashlick | Araq: for types which are importc |
| 14:25:41 | shashlick | ```Error: cannot evaluate 'sizeof' because its type is not defined completely``` |
| 14:26:34 | shashlick | but the entire object is defined |
| 14:26:58 | * | jjido joined #nim |
| 14:27:03 | shashlick | https://play.nim-lang.org/#ix=2i9A |
| 14:35:17 | * | icebattle joined #nim |
| 14:36:27 | * | Cadey joined #nim |
| 14:49:41 | FromDiscord | <mratsim> int64/float64 should work |
| 14:49:48 | FromDiscord | <mratsim> your types are target dependent |
| 14:50:41 | shashlick | I tried 64 and get the same error |
| 14:51:05 | shashlick | basically, i'm trying to add a feature to nimterop to check that the types it generates matches the sizes of the actual C type |
| 14:51:06 | FromDiscord | <mratsim> this worked for me: https://github.com/nim-lang/Nim/issues/7675#issuecomment-383405960 |
| 14:51:18 | shashlick | but not able to get the size, and even emit is not working as expected |
| 14:51:21 | FromDiscord | <mratsim> see the int128 code with dummy uint64 fields |
| 14:51:49 | FromDiscord | <mratsim> the fields were added for sizeof |
| 14:53:14 | shashlick | hmm, cannot do that when generating types from C headers |
| 14:59:44 | shashlick | my other option is to use emit and do the check during runtime - it is purely for test purposes but am wondering how to check sizeof(Ctype) == sizeof(Nimtype) if they have the same name |
| 15:03:32 | * | nsf quit (Quit: WeeChat 2.8) |
| 15:05:26 | * | icebattle quit (Ping timeout: 256 seconds) |
| 15:10:45 | * | zacharyc1rter joined #nim |
| 15:12:52 | FromGitter | <alehander92> Araq |
| 15:13:00 | FromGitter | <alehander92> i am not good at the vm thing |
| 15:13:04 | FromGitter | <alehander92> how are hints printed |
| 15:13:35 | FromGitter | <alehander92> e.g. i do echo stuff; symbol.copyLineInfo(code); echo stuff |
| 15:13:54 | FromGitter | <alehander92> and i print stuff from vmgen when copyLineInfo is invoked |
| 15:14:03 | FromGitter | <alehander92> and this print seems to happen way before the stuff thing |
| 15:14:44 | FromGitter | <alehander92> i guess the vm executes all the opcodes and .. somehow flushes the echo after finished? |
| 15:15:20 | FromGitter | <alehander92> ah i need to add `static:` , still wonder why are those printed at all otherwise |
| 15:15:26 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 15:20:36 | FromGitter | <faulander> since today i get an indentation error on line 14 when compiling. same code, copied/pasted works in nim playground. i even tried putting comments in line 1-20 and i still get the same error. any clues? |
| 15:21:59 | FromGitter | <alehander92> can you link the code |
| 15:23:28 | * | icebattle joined #nim |
| 15:25:35 | * | jjido joined #nim |
| 15:25:37 | FromGitter | <faulander> it works in playground |
| 15:26:03 | FromGitter | <faulander> https://play.nim-lang.org/#ix=2ial |
| 15:27:15 | FromGitter | <faulander> compiler tells me its on line 14, i even deleted the first two lines, so the line which was before 14 is now 12. i still get the exact same error |
| 15:29:03 | * | Vladar joined #nim |
| 15:29:51 | FromGitter | <faulander> i think its in the proc hash*s last line |
| 15:30:42 | * | zacharycarter quit (Quit: Lost terminal) |
| 15:30:42 | * | zacharyc1rter quit (Quit: Lost terminal) |
| 15:31:29 | * | NimBot joined #nim |
| 15:31:41 | FromGitter | <alehander92> are you .. sure |
| 15:31:46 | FromGitter | <alehander92> you are not compiling the wrong file |
| 15:31:50 | FromGitter | <alehander92> this happens from time to time |
| 15:31:55 | * | sunwukong quit (Quit: Leaving) |
| 15:31:58 | FromGitter | <alehander92> to me |
| 15:32:05 | FromGitter | <alehander92> and it's always very confusing |
| 15:32:29 | FromGitter | <alehander92> it really sounds like this kind of thing |
| 15:33:00 | FromGitter | <faulander> aaaaaaaaaaaaaaaaaaaaaah |
| 15:33:08 | FromGitter | <faulander> i am soooooo sorry, i am such a total newb |
| 15:33:19 | FromGitter | <faulander> this did cost me an hour now! grrrrrrrr |
| 15:33:26 | FromGitter | <faulander> thanks alex, thanks so much! :* |
| 15:33:38 | FromDiscord | <Rika> lmao |
| 15:34:03 | FromGitter | <alehander92> @faulander no problem it happens a lot to me as well |
| 15:34:15 | FromGitter | <faulander> at least i can make you laugh :) |
| 15:34:16 | FromGitter | <alehander92> especially when you maintain several versions of the same code/project |
| 15:34:24 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 15:35:03 | FromGitter | <alehander92> one possible hint i can think of is somehow the compiler hinting a warning "no changes to source since last compilation with the same flags" |
| 15:35:15 | FromGitter | <alehander92> which would be great in detecting stuff like that |
| 15:35:51 | FromGitter | <alehander92> but it's very niche and probably too expensive for big projects , maybe a more general solution can be integrated in build systems which already track files |
| 15:38:43 | FromGitter | <alehander92> faulander laughing can be quite helpful :P |
| 15:38:58 | * | jjido joined #nim |
| 15:39:04 | FromDiscord | <Rika> i dont think its too expensive, given that nim already doesnt recompile if no change has happened |
| 15:39:19 | FromDiscord | <Rika> its probably just a matter of adding some print statement |
| 15:39:32 | * | jjido quit (Client Quit) |
| 15:39:42 | shashlick | ping leorize |
| 15:41:16 | FromGitter | <alehander92> not if you run `nim c` |
| 15:41:26 | FromGitter | <alehander92> it detects that only for the c files |
| 15:41:34 | FromGitter | <alehander92> which are organized in nimcache |
| 15:41:44 | FromGitter | <alehander92> at least thats what i guess? |
| 15:42:10 | * | jjido joined #nim |
| 15:50:03 | * | nsf joined #nim |
| 15:56:30 | * | icebattl1 joined #nim |
| 15:57:51 | * | thomasross joined #nim |
| 15:58:38 | * | icebattle quit (Ping timeout: 256 seconds) |
| 15:59:29 | * | Trustable joined #nim |
| 16:07:41 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 16:09:22 | FromGitter | <faulander> i have now made a task file in visual studio code, which automatically compiles the open file. |
| 16:10:37 | FromGitter | <faulander> if someone wants it --> https://play.nim-lang.org/#ix=2iaD |
| 16:10:58 | FromGitter | <faulander> must be in folder .vscode in tasks.json |
| 16:12:49 | FromDiscord | <Rika> big brain uses playground for nonnim code/data |
| 16:13:10 | FromDiscord | <Recruit_main707> bold statement |
| 16:13:20 | FromGitter | <faulander> very nice Rika |
| 16:14:17 | FromGitter | <faulander> big brain Rika doesn't recognize that big brain faulander is making newbie mistake ... |
| 16:14:23 | FromGitter | <faulander> +s |
| 16:14:29 | FromGitter | <faulander> (a lot of them) |
| 16:15:20 | FromDiscord | <Rika> i aint yo personal code proofer |
| 16:15:50 | FromGitter | <faulander> did i ask something directly from you may i ask? |
| 16:16:04 | FromDiscord | <Rika> nah |
| 16:16:05 | FromDiscord | <Rika> why |
| 16:16:36 | FromGitter | <faulander> because you state that "i am not your personal code proofer" and i never asked you to be. |
| 16:16:50 | FromDiscord | <Rika> `big brain Rika doesn't recognize that big brain faulander is making newbie mistake` |
| 16:17:01 | shashlick | chill guys |
| 16:17:04 | FromDiscord | <Rika> this implies that i should have recognized it |
| 16:17:11 | FromDiscord | <Rika> i thought you jokin |
| 16:17:12 | FromGitter | <faulander> well, that was a reply to your nice comment |
| 16:17:13 | FromDiscord | <Rika> i aint serious |
| 16:17:49 | FromDiscord | <Rika> lmao okay |
| 16:18:19 | * | chemist69 quit (Quit: WeeChat 2.7) |
| 16:18:34 | * | chemist69 joined #nim |
| 16:19:11 | * | fputs joined #nim |
| 16:25:14 | * | Vladar quit (Quit: Leaving) |
| 16:28:34 | * | JohnAD quit (Ping timeout: 240 seconds) |
| 16:32:00 | * | jjido joined #nim |
| 16:36:02 | * | nsf quit (Quit: WeeChat 2.8) |
| 16:44:24 | * | waleee-cl quit (Quit: Connection closed for inactivity) |
| 16:44:40 | * | Vladar joined #nim |
| 16:45:52 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 16:52:51 | Yardanico | @faulander if you have nim extension installed in vscode you can just hit F6 to compile and run currently opened nim file |
| 16:52:59 | Yardanico | no need to create tasks manually |
| 16:57:39 | * | Vladar quit (Read error: Connection reset by peer) |
| 16:58:04 | * | Vladar joined #nim |
| 16:59:21 | shashlick | is it possible to hide certain procs from doc output |
| 16:59:38 | shashlick | they still need to exist, cannot just use when not defined(nimdoc) |
| 17:00:53 | shashlick | alternatively, is it possible to have the export marker as a variable that can be on and off without having to duplicate the entire proc line |
| 17:04:02 | * | jjido joined #nim |
| 17:04:02 | * | endragor quit (Remote host closed the connection) |
| 17:06:32 | FromDiscord | <Skaruts> man... this is a bit of a trap in templates: https://play.nim-lang.org/#ix=2ibq |
| 17:07:22 | FromDiscord | <Varriount> Skarut's: True... but the only good way for the compiler to show that would be to show the "expanded" template. |
| 17:08:06 | FromDiscord | <Varriount> That's also why it's good policy not to re-use identifiers anywhere in a template, if you can help it. |
| 17:09:27 | Yardanico | yeah, because then you can get all sorts of interesting bugs because your code will be run twice instead of being run once :P |
| 17:10:29 | FromDiscord | <Skaruts> I fell for this a few times :S |
| 17:10:53 | * | zacharycarter joined #nim |
| 17:11:17 | zacharycarter | question - I'm allocating a string inside of a shared library I'm loading with the dynlib module's `loadLib` proc |
| 17:11:51 | zacharycarter | I pass in a var object to this proc and assign a string to one of its fields |
| 17:12:12 | zacharycarter | back in the host program I then assign this field's value to another field in another object, and then I unload the library |
| 17:12:27 | zacharycarter | It seems like the string gets collected though when I unload the library - which makes sense |
| 17:12:45 | zacharycarter | can I allocate a new string and copy the value from the old string? |
| 17:13:50 | zacharycarter | or should I use GC_ref or something |
| 17:14:20 | Yardanico | well I know there's deepCopy in default GC but I'm not sure if it's what you need really |
| 17:14:28 | Yardanico | I'm not experienced with memory management really |
| 17:14:33 | zacharycarter | I'm using --gc:arc |
| 17:14:37 | Yardanico | oh |
| 17:14:59 | zacharycarter | in both the host program and the shared lib |
| 17:16:55 | zacharycarter | GC_ref seems to work |
| 17:18:11 | * | fputs quit (Quit: WeeChat 2.8) |
| 17:19:29 | * | fputs joined #nim |
| 17:23:37 | * | hax-scramper quit (Ping timeout: 265 seconds) |
| 17:27:59 | zacharycarter | oh cool - I don't even need to rely on GC_ref I can just do `let foo = $foobar` |
| 17:38:04 | FromDiscord | <Skaruts> another trap, but this one's on me: https://play.nim-lang.org/#ix=2ibI 😄 |
| 17:38:31 | Yardanico | playground shows a different error though |
| 17:38:32 | FromDiscord | <Skaruts> gotta remember not to put that discard there because I always forget it's there when I add the block of code... |
| 17:38:35 | Yardanico | /usercode/in.nim(15, 8) Error: expression 'echo ["template fooing!"]' has no type (or is ambiguous) |
| 17:38:55 | FromDiscord | <Skaruts> yup that's the error I get |
| 17:39:08 | FromDiscord | <Skaruts> remove the discard and it's all fine |
| 17:39:29 | FromDiscord | <Skaruts> oh I forgot to take the previous error comments |
| 17:39:37 | FromDiscord | <Skaruts> disregard those |
| 17:40:24 | FromDiscord | <Rika> The discard immediately ends the block so technically the echo fooing is an invalid indentation error, isn't it? |
| 17:41:07 | FromDiscord | <Rika> But I think what nim interprets it as is that the discard statement is discarding the echo |
| 17:41:21 | Yardanico | let's check with a macro |
| 17:41:22 | FromDiscord | <Rika> Since echo is void, it spits the no type error |
| 17:41:44 | FromDiscord | <Skaruts> oh, yea that's probably what it's doing, @Rika |
| 17:42:04 | Yardanico | @Rika's right |
| 17:42:12 | Yardanico | https://play.nim-lang.org/#ix=2ibN |
| 17:42:24 | Yardanico | gives |
| 17:42:32 | Yardanico | (Arglist (StmtList (DiscardStmt (Command (Ident "echo") (StrLit "template fooing!"))))) (changed to lispRepr so it's 1 line) |
| 17:42:41 | Yardanico | so it discards an echo call |
| 17:44:50 | FromDiscord | <Skaruts> heh, knowing that would've saved me 10 minutes figuring it out |
| 17:44:56 | * | moerm joined #nim |
| 17:45:09 | moerm | Hello everyone |
| 17:45:14 | Yardanico | i'm still really confused about that though @Skaruts |
| 17:45:35 | FromDiscord | <Skaruts> about what? |
| 17:46:06 | Yardanico | about the error |
| 17:46:08 | Yardanico | and why it happens |
| 17:46:22 | * | rockcavera quit (Remote host closed the connection) |
| 17:47:21 | * | filcuc joined #nim |
| 17:47:37 | FromDiscord | <Skaruts> seems to me you're both right, it's pretty much interpreting as a statement `discard echo "template fooing!"` |
| 17:47:41 | FromDiscord | <Skaruts> https://play.nim-lang.org/#ix=2ibU |
| 17:48:03 | Yardanico | basically yeah https://play.nim-lang.org/#ix=2ibV |
| 17:55:34 | * | rockcavera joined #nim |
| 18:04:37 | FromDiscord | <Rika> It really should give an indentation error instead though |
| 18:05:19 | Yardanico | yes |
| 18:05:25 | Yardanico | well discard is quite special |
| 18:10:48 | * | moerm quit (Quit: Leaving) |
| 18:12:24 | leorize | shashlick: you pinged me? |
| 18:13:42 | * | hax-scramper joined #nim |
| 18:15:59 | shashlick | ya had a question around the enum implementation in nimterop |
| 18:16:21 | shashlick | distinct int ends up in wrong size in nested structs so had to change it to distinct cint |
| 18:16:39 | shashlick | will be ideal if you could join the nimterop gitter room |
| 18:17:36 | shashlick | was thinking of https://play.nim-lang.org/#ix=2iaK as the new implementation but then A or B won't work as proc params since they get converted into int |
| 18:17:51 | * | endragor joined #nim |
| 18:23:08 | * | endragor quit (Ping timeout: 256 seconds) |
| 18:24:45 | leorize | wait you implemented them as distinct int? shouldn't they be distinct cint? |
| 18:26:57 | shashlick | yes have changed it now |
| 18:27:15 | shashlick | https://github.com/nimterop/nimterop/blob/nested/nimterop/types.nim |
| 18:27:25 | shashlick | have nested struct support now in nimterop |
| 18:28:15 | * | filcuc quit (Ping timeout: 250 seconds) |
| 18:31:19 | Prestige | Looks like nimpretty isn't respecting --maxLineLen, anyone else seeing that? |
| 18:32:58 | * | audiofile joined #nim |
| 18:36:36 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 18:55:01 | shashlick | does it make any sense to wrap static inline functions? |
| 18:57:59 | leorize | usually you translate the function into nim :P |
| 18:58:03 | leorize | btw what's the gitter room? |
| 18:58:28 | Yardanico | nim-lang/nim |
| 18:59:07 | leorize | I mean for nimterop :P |
| 18:59:16 | shashlick | https://gitter.im/nimterop/Lobby |
| 18:59:24 | shashlick | folks can ask their questions around nimterp |
| 19:00:06 | FromDiscord | <Recruit_main707> aka: i fill the chat with questions :P |
| 19:03:05 | shashlick | once compiled, those inline functions don't really exist right? they aren't callable? |
| 19:04:32 | FromDiscord | <Recruit_main707> depends on the compiler i think, i guess if you call them they wont be inlined |
| 19:06:45 | leorize | shashlick: usually they are fully inlined |
| 19:10:44 | * | xcm quit (Remote host closed the connection) |
| 19:13:29 | * | xcm joined #nim |
| 19:15:53 | * | waleee-cl joined #nim |
| 19:35:00 | * | icebattl1 quit (Quit: leaving) |
| 19:35:25 | * | icebattle joined #nim |
| 19:40:52 | * | xcm quit (Remote host closed the connection) |
| 19:43:03 | * | xcm joined #nim |
| 19:55:20 | FromDiscord | <Skaruts> is there a way to prevent the docs from going in dark mode all the time? |
| 20:03:48 | Prestige | Does anyone know what "nimcheck" is? |
| 20:04:45 | Yardanico | "nim check" checks if your program is correct Nim code :) |
| 20:05:03 | Yardanico | and if it's not, it'll show what errors you have |
| 20:05:20 | Prestige | ah thank you |
| 20:05:29 | Yardanico | basically it has the same behaviour as the compiler but without the code generation step |
| 20:06:04 | Yardanico | you can also supply it with the same arguments as the Nim compiler like "nim check --threads:on" |
| 20:06:04 | Prestige | still debugging why nimlsp diagnostics aren't working with my lsp client, but ALE was. It was getting error info from nim check, rather than nimlsp |
| 20:08:09 | Yardanico | "nim check" is mostly used for IDEs/editors to highlight errors in your code right in the editor, but of course it can be used stand-alone too |
| 20:09:14 | Yardanico | the most complete nim extension is IMO the VSCode one, it has stuff like error highlighting, F6 to compile & run current file, nimsuggest integration, nimpretty integration |
| 20:14:03 | * | narimiran quit (Ping timeout: 260 seconds) |
| 20:15:05 | * | jjido joined #nim |
| 20:19:59 | Prestige | PMunch: are you sure diagnostics are being reported from nimlsp itself via the protocol? |
| 20:20:25 | * | hpyc9 quit (Killed (Sigyn (Stay safe off irc))) |
| 20:25:42 | * | Vladar quit (Quit: Leaving) |
| 20:28:07 | FromDiscord | <kodkuce> lol i using vscode whole time only like a month used neovim and i dident know F6 is compile and run |
| 20:32:46 | * | tane joined #nim |
| 20:33:49 | * | MarderIII quit (Quit: Leaving) |
| 20:41:43 | Prestige | I compiled nimlsp from source and copied nimsuggest into src/nimlsppkg/ then edited a file, here's the output PMunch https://0x0.st/iQJe.txt |
| 20:42:09 | Prestige | The very last line is "Trying to read frame" I wonder if something failed? |
| 20:46:47 | * | hpyc9 joined #nim |
| 20:50:39 | Yardanico | wow git bisect is impressive |
| 20:50:51 | Yardanico | I never used it but just found the first broken commit for https://github.com/nim-lang/Nim/issues/13935 in a few minutes |
| 20:52:28 | Yardanico | and it's easy to use too, just "git bisect start", "git bisect bad # current is bad", "git bisect good <commit-hash-of-good-revision", and then ./koch temp c stuff and "git bisect good" or "git bisect bad" |
| 20:56:46 | * | Ven`` joined #nim |
| 20:57:54 | * | solitudesf quit (Ping timeout: 256 seconds) |
| 21:00:57 | shashlick | Araq, leorize: do you have any ideas on how I can validate that the type wrappers I create with nimterop are correct in size? |
| 21:02:55 | leorize | we have -d:checkAbi for this iirc |
| 21:04:11 | leorize | Yardanico: beware that git bisect can lead you to the wrong place to look for bugs |
| 21:04:25 | Yardanico | well in this case it seems to do the right thing |
| 21:04:38 | Yardanico | the commit before that commit works fine, and the first "bad" commit is directly related to threads and --gc:arc :) |
| 21:05:34 | leorize | be sure to double check if it's the bug or it just expose a hidden one :P |
| 21:06:24 | Yardanico | btw how do I bind a proc with arguments in a template? |
| 21:06:30 | Yardanico | if it's imported from another module |
| 21:06:33 | Yardanico | or I can't? |
| 21:07:23 | leorize | Yardanico: wdym? |
| 21:07:57 | Yardanico | system.nim has sysAssert template which uses rawWrite from system/ansi_c |
| 21:08:06 | Yardanico | ah nvm I can just make it a proc temporarily |
| 21:08:19 | leorize | add `bind rawWrite` |
| 21:11:34 | PMunch | Prestige, sorry left my client connected while I was gone |
| 21:11:54 | Prestige | Np |
| 21:12:07 | PMunch | And yeah I'm sure |
| 21:12:40 | Prestige | Any thoughts on the last message I sent? |
| 21:13:04 | PMunch | If I disable my other Nim plug-in (zah/nim.vim) and open a file and run ":setf nim :e!" it starts showing diagnostics when I save the file |
| 21:13:42 | PMunch | Hmm, strange |
| 21:14:21 | PMunch | It's getting late here now though, I'll have a look at it tomorrow |
| 21:14:42 | PMunch | Might be a good time to have a look at the nimlsp code as well. It has an annoying bug that I really want to iron out |
| 21:15:21 | Prestige | I appreciate it, if I can help somehow let me know PMunch |
| 21:15:44 | leorize | you can look at the code :) |
| 21:15:53 | leorize | it's not too complicated afaict :) |
| 21:16:48 | Prestige | I'm not familiar with lsp but I'll take a look |
| 21:17:00 | * | tane quit (Quit: Leaving) |
| 21:17:25 | PMunch | Yeah if you stick to this file it should be pretty to understand: https://github.com/PMunch/nimlsp/blob/master/src/nimlsp.nim |
| 21:18:49 | PMunch | Hmm, it seems like it might not detect it as a valid DocumentNotification.. |
| 21:18:57 | leorize | if you can, can you fix the bug with forward declaration in nimsuggest? |
| 21:20:50 | PMunch | Forward declaration? |
| 21:22:23 | leorize | yea, http://ix.io/2idu |
| 21:27:57 | PMunch | Ah, figured out the bug Prestige |
| 21:28:01 | Prestige | I think you might be right - textDocumentNotification might just be failing on the source for some reason |
| 21:28:03 | Prestige | oh? |
| 21:28:23 | PMunch | Your LSP client is sending messages that don't match the schema |
| 21:28:53 | Prestige | If you can provvide some specifics I'll file a bug report with the client |
| 21:28:59 | Prestige | s/provvide/provide |
| 21:29:00 | * | filcuc joined #nim |
| 21:30:40 | PMunch | So the textDocument/didSave is supposed to have a DidSaveTextDocumentParams as the params. And DidSaveTextDocumentParams is supposed to have a textDocument field of the kind TextDocumentIdentifier. This only has one field according to the spec, namely uri which is supposed to be a DocumentUri. But your client sends: `{"uri":"file:///home/avahe/programming/nim/testing/test.nim","version":1}` ie. it has an extra version field. |
| 21:31:39 | Prestige | ah and that extra field is causing a breakage? I thought it'd just get ignored. But that's awesome, thanks for figuring that out |
| 21:31:46 | PMunch | This makes the check performed here: https://github.com/PMunch/nimlsp/blob/master/src/nimlsp.nim#L440 (through the textDocumentNotification template that calls whenValid which calls isValid from jsonschema: https://github.com/PMunch/jsonschema/blob/master/src/jsonschema.nim#L356 |
| 21:31:48 | PMunch | ) |
| 21:32:16 | PMunch | As you can see `isValid` has an option `allowExtra` that defaults to false. |
| 21:32:40 | Prestige | ah interesting |
| 21:32:54 | PMunch | So if you change this line: https://github.com/PMunch/nimlsp/blob/master/src/nimlsp.nim#L53 to have allowExtra=true it should work |
| 21:33:33 | Prestige | and line 58 I suppose wouldn't hurt either |
| 21:34:26 | PMunch | Yeah, for a proper fix, but it should work for this specific case by only changing line 53 |
| 21:36:18 | Prestige | ah it's working! Thanks :) |
| 21:36:24 | PMunch | No problem :) |
| 21:36:25 | Prestige | This is great |
| 21:36:36 | PMunch | I could've sworn that I had fixed that in nimlsp.. |
| 21:36:51 | Prestige | different branch maybe? |
| 21:36:52 | PMunch | I think I even implemented allowExtra in jsonschema for the express purpose of using it in nimlsp.. |
| 21:38:46 | Prestige | At least it was a simple fix. I'm very glad this works now |
| 21:40:45 | PMunch | This is so weird.. |
| 21:41:13 | PMunch | I really thought there was an issue with a similar thing, that got resolved by me adding allowExtra and toggling it in nimlsp.. |
| 21:41:17 | PMunch | Have I been dreaming? |
| 21:41:42 | PMunch | According to git blame I added allowExtra about a year and a half ago.. |
| 21:42:10 | Prestige | In nimlsp? |
| 21:42:51 | Prestige | Could've just forgotten to add it after putting allowExtra in the json schema |
| 21:43:30 | PMunch | No in jsonschema, added it Nov 2018 |
| 21:43:35 | PMunch | Might be |
| 21:43:54 | PMunch | But I remember there was some editor that sent some weird fields, and that I fixed the error by doing that.. |
| 21:44:10 | * | tiorock joined #nim |
| 21:44:11 | * | rockcavera quit (Killed (tepper.freenode.net (Nickname regained by services))) |
| 21:44:11 | * | tiorock is now known as rockcavera |
| 21:44:11 | * | rockcavera quit (Changing host) |
| 21:44:11 | * | rockcavera joined #nim |
| 21:44:54 | Prestige | Maybe it was an editor using jsonschema that didn't use nimlsp directly |
| 21:45:11 | PMunch | I don't think anything besides nimlsp uses jsonschema :P |
| 21:45:19 | PMunch | Apart from one of my other projects I think |
| 21:46:38 | PMunch | Oh well, off to bed |
| 21:46:40 | Prestige | After I get my current project to a decent state I'll probably start contributing to nimlsp or similar repos |
| 21:46:43 | Prestige | Gn |
| 21:47:07 | PMunch | What is your current project? |
| 21:47:22 | PMunch | The WM right? |
| 21:47:37 | Prestige | Yep |
| 21:47:38 | PMunch | I remember in your previous log the code in there was a lot of xlib stuff :P |
| 21:47:51 | Prestige | Haha yeah, we'll see how it goes |
| 21:48:01 | Prestige | Trying to replace my current wm with this |
| 21:48:34 | PMunch | If you send my a public key I could give you read access to the repo for my Nim WM |
| 21:48:53 | PMunch | Got some interesting macros there for handling xevents |
| 21:49:05 | PMunch | But, as I said, bedtime |
| 21:49:06 | * | PMunch quit (Quit: leaving) |
| 21:53:32 | * | jjido quit (Ping timeout: 246 seconds) |
| 21:58:30 | * | exelotl joined #nim |
| 21:59:26 | exelotl | I think I pinned down the nimterop bug I encountered yesterday? |
| 21:59:33 | exelotl | https://github.com/exelotl/nimterop-override-test |
| 22:00:42 | exelotl | A struct has a field which has leading underscores. It seems to be impossible to omit the field. |
| 22:01:58 | exelotl | I tried (1) using the -O flag to omit it, (2) using a plugin to set the name to "" |
| 22:10:02 | * | filcuc quit (Quit: Konversation terminated!) |
| 22:12:28 | * | liblq-dev quit (Quit: WeeChat 2.7.1) |
| 22:22:10 | shashlick | Did you try -E |
| 22:22:54 | shashlick | -O only works for the type |
| 22:23:09 | shashlick | Can't really omit a field of a struct |
| 22:24:10 | shashlick | And it has two _ so you need -E__ |
| 22:25:25 | exelotl | it still gets through with -E=__ |
| 22:29:48 | shashlick | Gets thru? |
| 22:30:42 | exelotl | as in, it still gives this error: |
| 22:30:46 | exelotl | Identifier 'SockaddrStorage:__ss_padding' (nskField) contains leading/trailing underscores '_' [AssertionError] |
| 22:32:16 | shashlick | Try without the = |
| 22:32:28 | shashlick | Though it should work with cligen |
| 22:33:44 | exelotl | oh, wow that actually works o_O |
| 22:35:36 | shashlick | Hmm I think only : is allowed |
| 22:35:44 | shashlick | Or the full name |
| 22:36:06 | exelotl | seems that both -E=__ and -E__ work in my minimal example |
| 22:37:01 | exelotl | still run into issues with the plugin though |
| 22:37:28 | exelotl | if you pass -E__ it doesn't strip the __ from the name that gets sent to the plugin |
| 22:38:34 | exelotl | I guess the plugin runs at an early stage or something? |
| 22:40:19 | * | abm quit (Read error: Connection reset by peer) |
| 22:41:26 | * | bunbunbunbunny joined #nim |
| 22:41:40 | * | bunbunbunbunny quit (Client Quit) |
| 22:41:51 | shashlick | Either or |
| 22:42:04 | shashlick | Cannot use plugin and -E |
| 22:42:11 | * | bunbunbunbunny joined #nim |
| 22:42:24 | shashlick | And for plugin, use strip, you cannot have a field with no name |
| 22:45:41 | * | endragor joined #nim |
| 22:50:23 | * | endragor quit (Ping timeout: 260 seconds) |
| 22:50:29 | shashlick | Please use -f:ast2 for new wrappers |
| 23:08:48 | * | neceve quit (Ping timeout: 256 seconds) |
| 23:12:15 | * | Trustable quit (Remote host closed the connection) |
| 23:16:20 | * | dwdv quit (Ping timeout: 256 seconds) |
| 23:19:42 | Prestige | Is there any documentation on testament? Do we just write files the same way we would with unittest? |
| 23:20:03 | Yardanico | no |
| 23:20:20 | Yardanico | testament is mainly used for testing nim itself, you can check tests in "tests" directory to see how they look :) |
| 23:20:44 | Prestige | Thanks :) |
| 23:21:03 | Yardanico | why you want to use testament though? unittest is pretty good and it's basically the most popular lib used for testing nim libs/apps |
| 23:21:35 | Prestige | just saw this suggesting to use testament: https://nim-lang.org/docs/unittest.html |
| 23:21:52 | Yardanico | well unittest will still be better for most apps/libs, or no separate test lib at all |
| 23:22:00 | Yardanico | testament might be better for bigger projects IMO |
| 23:22:12 | Prestige | Thank you |
| 23:27:15 | * | bunbunbunbunny quit (Ping timeout: 250 seconds) |
| 23:30:43 | * | lritter joined #nim |
| 23:32:11 | * | exelotl quit (Quit: Leaving) |
| 23:32:49 | * | krux02_ joined #nim |
| 23:34:44 | * | xet7 quit (Quit: Leaving) |
| 23:35:42 | * | krux02 quit (Ping timeout: 256 seconds) |
| 23:38:07 | * | Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 23:43:29 | * | bunbunbunbunny joined #nim |
| 23:54:12 | * | NimBot joined #nim |
