| 00:00:55 | * | luis__ joined #nim |
| 00:04:38 | * | luis_ quit (Ping timeout: 245 seconds) |
| 00:14:11 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
| 00:31:30 | * | cgfuh quit (Ping timeout: 250 seconds) |
| 00:39:09 | * | luis__ quit (Ping timeout: 252 seconds) |
| 00:47:29 | * | jjido quit (Quit: Connection closed for inactivity) |
| 01:05:59 | * | arecacea1 quit (Remote host closed the connection) |
| 01:06:17 | * | arecacea1 joined #nim |
| 01:06:36 | * | rnrwashere quit (Remote host closed the connection) |
| 01:10:15 | * | rnrwashere joined #nim |
| 01:19:12 | FromDiscord | <++x;> Yo guys. |
| 01:20:28 | FromDiscord | <++x;> If i were to get the Nim cache. And run the C++ code by it's self in the C++ compiler then would the code still execute? It should still be able to execute. |
| 01:21:29 | FromDiscord | <++x;> So like if i wrote Hello world in Nim and got the cache and ran the cache then Hello would should still be executable. |
| 01:21:52 | FromDiscord | <++x;> From the cache that's written in C++. |
| 01:22:32 | shashlick | yes - if you run in verbose mode, you can even see the commands nim runs |
| 01:29:23 | * | stefanos82 quit (Remote host closed the connection) |
| 01:30:18 | * | abm quit (Ping timeout: 252 seconds) |
| 01:33:22 | shashlick | There's also a flag to gen only and not build |
| 01:41:44 | * | solitudesf quit (Quit: ZNC - https://znc.in) |
| 01:44:19 | * | abeaumont quit (Ping timeout: 250 seconds) |
| 01:44:44 | * | solitudesf joined #nim |
| 01:49:03 | * | cgfuh joined #nim |
| 02:07:46 | FromGitter | <arnetheduck> Araq, think of a package manager as a tool that composes a standard library for you :) `go` goes a bit in this direction, with its vendor directory where you literally keep a per-project copy of deps |
| 02:14:05 | FromGitter | <zetashift> https://gist.github.com/zetashift/7f9c180f3025341a18483688d88ddca9 made a quick (and bad) version in Nim of this thing that recently got posted: https://gist.github.com/munificent/b1bcd969063da3e6c298be070a22b604 |
| 02:15:57 | * | cgfuh quit (Ping timeout: 252 seconds) |
| 02:16:13 | * | sealmove quit (Quit: WeeChat 2.4) |
| 02:35:15 | * | Jesin joined #nim |
| 02:40:13 | * | Jjp137 quit (Read error: Connection reset by peer) |
| 02:40:36 | * | Jjp137 joined #nim |
| 02:53:23 | * | Jjp137 quit (Ping timeout: 245 seconds) |
| 03:00:43 | * | Jjp137 joined #nim |
| 03:02:38 | * | banc quit (Quit: Bye) |
| 03:03:57 | * | dddddd quit (Remote host closed the connection) |
| 03:09:16 | rnrwashere | Someone please add a note in spawn section of manual about passing ptr instead of ref would not copy all underlying data structure |
| 03:09:34 | rnrwashere | Newbs like me probably wont understand: ref parameters are deeply copied which is a subtle semantic change and can cause performance problems but ensures memory safety. This deep copy is performed via system.deepCopy and so can be overridden. |
| 03:23:25 | * | banc joined #nim |
| 03:35:52 | * | rnrwashere quit () |
| 03:39:58 | * | Jesin quit (Quit: Leaving) |
| 03:40:29 | * | abeaumont joined #nim |
| 03:44:46 | * | Jesin joined #nim |
| 03:49:05 | * | noeontheend joined #nim |
| 03:52:06 | * | noeontheend quit (Remote host closed the connection) |
| 03:52:43 | * | noeontheend joined #nim |
| 04:11:12 | * | noonien quit (Quit: Connection closed for inactivity) |
| 04:26:32 | * | bobby quit (*.net *.split) |
| 04:26:32 | * | MasterdonY quit (*.net *.split) |
| 04:26:32 | * | mr_yogurt_ quit (*.net *.split) |
| 04:26:33 | * | Lord_Nightmare quit (*.net *.split) |
| 04:29:35 | * | beatmox quit (Ping timeout: 255 seconds) |
| 04:29:42 | * | beatmox joined #nim |
| 04:31:55 | * | nsf joined #nim |
| 04:34:33 | * | chemist69 quit (Ping timeout: 252 seconds) |
| 04:36:35 | * | chemist69 joined #nim |
| 04:53:43 | * | bobby joined #nim |
| 04:53:43 | * | MasterdonY joined #nim |
| 04:53:43 | * | mr_yogurt_ joined #nim |
| 04:53:43 | * | Lord_Nightmare joined #nim |
| 04:53:51 | * | noeontheend quit (Ping timeout: 252 seconds) |
| 04:57:29 | * | banc quit (Ping timeout: 255 seconds) |
| 04:58:29 | * | banc joined #nim |
| 05:17:00 | * | Jesin quit (Quit: Leaving) |
| 05:19:58 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 05:27:08 | * | chimez joined #nim |
| 05:42:16 | FromGitter | <Varriount> rnrwashere: What do you mean? There's already a note |
| 05:44:24 | * | narimiran joined #nim |
| 05:53:08 | * | JustASlacker joined #nim |
| 06:00:05 | Araq | I think he means that the note is confusing. |
| 06:26:45 | * | JustASlacker quit (Ping timeout: 252 seconds) |
| 06:40:28 | * | JustASlacker joined #nim |
| 07:00:12 | * | krux02 joined #nim |
| 07:11:47 | * | JustASlacker quit (Quit: Leaving) |
| 07:13:35 | * | PMunch joined #nim |
| 07:49:09 | * | Vladar joined #nim |
| 07:59:26 | * | jjido joined #nim |
| 08:00:00 | * | gmpreussner quit (Quit: kthxbye) |
| 08:04:42 | * | gmpreussner joined #nim |
| 08:06:07 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 08:11:23 | PMunch | Good morning everyone :) |
| 08:16:11 | * | couven92 joined #nim |
| 08:22:49 | * | fredrik92 joined #nim |
| 08:25:00 | * | couven92 quit (Ping timeout: 252 seconds) |
| 08:41:14 | * | jjido joined #nim |
| 09:02:09 | * | MyMind joined #nim |
| 09:02:17 | * | Sembei quit (Ping timeout: 255 seconds) |
| 09:03:44 | * | floppydh joined #nim |
| 09:05:02 | Zevv | Good morning to you sir! Is this the new initiative to keep the channel going? :) |
| 09:06:45 | * | luis__ joined #nim |
| 09:07:34 | luis__ | Is gintro multiplatform, will a gtk3 window work on Windows? |
| 09:08:05 | * | luis__ is now known as lf-araujo |
| 09:11:16 | * | abm joined #nim |
| 09:11:29 | * | floppydh quit (Quit: WeeChat 2.3) |
| 09:12:37 | narimiran | Zevv: look at the logs from yesterday evening. all i need to do is to rename `options` to `optionals` and suddenly this channel is much more active |
| 09:13:22 | Zevv | ghehe |
| 09:13:24 | narimiran | what should i rename today to keep the flow? :D |
| 09:13:32 | Zevv | Nim to Nimrod? |
| 09:14:14 | narimiran | i don't know, let's start the discussion :P |
| 09:28:31 | * | salewski joined #nim |
| 09:28:40 | PMunch | Zevv, haha people say hello here from time to time. But I agree that the channel has been very quiet lately |
| 09:29:08 | PMunch | lf-araujo, not sure about gintro, but Gtk3 should run on Windows |
| 09:29:57 | salewski | luis__, gtk3 from gintro should work fine on windows, but does not offer native look. |
| 09:30:06 | PMunch | I saw the wNim library by the way, got me interested in working on genui again :P |
| 09:30:31 | lf-araujo | salewski: thanks |
| 09:30:55 | PMunch | I know I say that a lot, but the layouting stuff in wNim added a piece I was missing from the puzzle :) |
| 09:31:27 | PMunch | lf-araujo, if you want cross-platform native looks you might want to check out https://github.com/PMunch/wxnim |
| 09:31:41 | lf-araujo | salewski, PMunch: Would gintro build on Darwin? |
| 09:32:05 | PMunch | wxWidgets wrapper with some special sauce to make it easier to use in Nim :) |
| 09:32:24 | narimiran | any news about playground? what is happening with it? |
| 09:32:25 | PMunch | lf-araujo, think so yeah. But again the same caveat that you don't get native looks |
| 09:32:40 | PMunch | narimiran, not sure. I'm still waiting for the hand-over |
| 09:32:43 | salewski | GTK3 with Mac is difficult, not only for Nim. For C users too. |
| 09:32:44 | lf-araujo | thanks |
| 09:33:10 | PMunch | lf-araujo, wxWidgets will work on Linux, Mac, and Windows with the native toolkits |
| 09:33:31 | lf-araujo | Will it really? |
| 09:33:35 | PMunch | Yup |
| 09:33:47 | lf-araujo | What is the module name I should be looking? |
| 09:33:56 | lf-araujo | wxWidgets? |
| 09:33:59 | PMunch | github.com/PMunch/wxnim#examples |
| 09:34:24 | lf-araujo | Oh, great... |
| 09:34:50 | PMunch | And on a Mac with a dark theme: github.com/PMunch/wxnim/blob/4b686fc5cef585efc1c83ebdab0931200a07baea/screenshots/osx.png |
| 09:35:41 | lf-araujo | And it looks ok too on linux... |
| 09:36:49 | lf-araujo | PMunch: Can it be installed with Nimble? |
| 09:36:53 | PMunch | Yeah, it uses Gtk on Linux |
| 09:36:57 | PMunch | lf-araujo, yup |
| 09:37:16 | PMunch | nimble install wxnim && <package manager install> wxGtk |
| 09:38:28 | PMunch | Oh wait, it's not in the nimble package directory.. |
| 09:39:07 | PMunch | So "nimble install https://github.com/PMunch/wxnim.git" |
| 09:39:25 | * | floppydh joined #nim |
| 09:42:47 | * | salewski quit (Quit: WeeChat 2.3) |
| 09:43:24 | PMunch | I was sure it was there.. |
| 09:58:06 | * | Dmdaman joined #nim |
| 09:58:49 | * | Dmdaman quit (Client Quit) |
| 10:02:07 | * | lf-araujo quit (Ping timeout: 245 seconds) |
| 10:02:54 | Zevv | oh pegs running at compile time I just hear, sweet! |
| 10:04:21 | PMunch | Oh nice |
| 10:10:08 | FromGitter | <alehander42> Can I use nimpretry as a library @Araq |
| 10:10:43 | FromGitter | <alehander42> E.g. passing my PNode to renderer.nim but somehow with nimpretty enabled |
| 10:11:14 | FromGitter | <alehander42> Currently I always get functions and all top level statements without any newlines between them |
| 10:32:39 | Araq | alehander42: the renderer does produce newlines |
| 10:35:29 | * | lf-araujo joined #nim |
| 10:37:33 | lf-araujo | are there any repl or interactive shells for NIM? i can find wheineman/nrpl, but it seems development has stoped... |
| 10:40:30 | Vladar | https://github.com/AndreiRegiani/INim |
| 10:45:15 | * | lritter joined #nim |
| 11:00:00 | * | floppydh quit (Quit: WeeChat 2.3) |
| 11:01:57 | * | floppydh joined #nim |
| 11:02:25 | * | dddddd joined #nim |
| 11:13:36 | FromGitter | <arnavb> Why do nim imports include everything in that module without a prefix? Wouldn't this be considered an anti-pattern? I know I can put the prefix myself, but why was this done in the first place? |
| 11:14:11 | def- | arnavb: since Nim is statically typed it's fine even if there are multiple functions with the same name and the compiler will warn you when there is a collision |
| 11:14:45 | def- | and when reading the code the IDE can show you what module the function comes from |
| 11:15:41 | FromGitter | <arnavb> Is it good practice to use fully qualified names or not? |
| 11:15:54 | FromGitter | <arnavb> i.e What do majority of projects do |
| 11:19:32 | * | salewski joined #nim |
| 11:20:54 | FromGitter | <alehander42> @Araq what i mean is |
| 11:21:01 | FromGitter | <alehander42> i want to produce two newlines |
| 11:21:02 | salewski | arnavb, use fully qualified names is generally not used. See compiler sources for example. |
| 11:21:15 | FromGitter | <alehander42> so e.g. methods are separated visually |
| 11:21:18 | * | lf-araujo quit (Ping timeout: 245 seconds) |
| 11:21:24 | FromGitter | <alehander42> not starting immediately on the next |
| 11:21:33 | salewski | This arnavb question should really be part of the Nim FAQ. |
| 11:24:02 | * | salewski quit (Client Quit) |
| 11:31:48 | PMunch | arnavb, most people don't use fully qualified names, unless there is some ambiguity or the name of the procedure doesn't make much sense without the full name of the package |
| 11:33:20 | FromGitter | <Clyybber> @Araq Regarding the crashing code from yesterday, valgrind reported this: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ All the "errors" are from zlib.so. ... [https://gitter.im/nim-lang/Nim?at=5c8101801c597e5db69a307e] |
| 11:33:51 | FromGitter | <arnavb> Ah that makes sense. |
| 11:38:17 | * | planetis[m] joined #nim |
| 11:45:55 | PMunch | > This arnavb question should really be part of the Nim FAQ. |
| 11:46:00 | PMunch | Or at least the NEP-1 style guide |
| 11:50:33 | * | waleee joined #nim |
| 11:55:18 | * | MyMind quit (Ping timeout: 250 seconds) |
| 12:13:09 | * | oculux quit (Quit: blah) |
| 12:27:43 | * | oculux joined #nim |
| 12:29:46 | * | ng0 joined #nim |
| 12:31:39 | * | sealmove joined #nim |
| 12:32:39 | * | lf-araujo joined #nim |
| 12:41:33 | * | Snircle joined #nim |
| 12:53:08 | * | lf-araujo quit (Ping timeout: 255 seconds) |
| 13:00:47 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 13:02:10 | * | Snircle joined #nim |
| 13:18:04 | * | nsf quit (Quit: WeeChat 2.4) |
| 13:28:06 | * | cgfuh joined #nim |
| 13:35:31 | * | noonien joined #nim |
| 13:50:55 | Zevv | In the latest video it was mentioned that some modules should now be working at compile time, which - probably - included pegs |
| 13:51:23 | Zevv | There are still some out of bounds errors when indexing the one-after-last char in a cstring, which I locally fixed |
| 13:52:16 | Zevv | but now I still get "Error: invalid type for const: Peg". Is this something that might be fixable at compile time with the changes that enabled other modules to work at compile time? |
| 13:54:41 | Araq | Zevv: a Peg contains a 'ref' and we don't know how to generate static C code for that |
| 13:54:57 | Zevv | ok, so that is not what changed. Too bad ! :) |
| 13:55:20 | Araq | we can consider to allow 'ref T' in 'const' |
| 13:55:31 | Araq | and teach the codegen to allocate it on the heap anyway |
| 13:55:42 | * | a_b_m joined #nim |
| 13:55:46 | Araq | the GC will hate it though :P |
| 13:58:47 | * | abm quit (Ping timeout: 245 seconds) |
| 14:00:27 | * | dddddd quit (Ping timeout: 240 seconds) |
| 14:00:53 | * | dddddd joined #nim |
| 14:02:07 | * | kapil____ joined #nim |
| 14:05:39 | * | a__b__m joined #nim |
| 14:08:45 | * | a_b_m quit (Ping timeout: 252 seconds) |
| 14:14:31 | FromGitter | <danielecook> What does it mean if when I echo an object it looks like this? ⏎ ⏎ ```(ref_allele: ...alt_allele: ...chrom: ...position: ...)``` [https://gitter.im/nim-lang/Nim?at=5c8127468f294b134a03028d] |
| 14:14:38 | FromGitter | <danielecook> I cannot access the fields of this object |
| 14:15:03 | * | a_b_m joined #nim |
| 14:15:58 | FromGitter | <danielecook> nvm...the fields weren't being exported |
| 14:16:03 | FromGitter | <danielecook> Is there a shorthand for exporting all fields? |
| 14:17:36 | FromGitter | <recloser> is the recently merged support for hcr for native usable at the moment? i wanted to try it out but it just complains that it can't load libnimhcr.so |
| 14:17:56 | * | a__b__m quit (Ping timeout: 244 seconds) |
| 14:23:14 | FromGitter | <recloser> @danielecook you could make it a tuple, they export all their fields by default |
| 14:27:40 | FromGitter | <danielecook> Thanks! |
| 14:32:27 | * | Cthalupa quit (Ping timeout: 240 seconds) |
| 14:33:34 | * | Cthalupa joined #nim |
| 14:41:39 | sealmove | finally achieved what I've been trying :) now you can make a custom proc and call `runRepl(customProc)` to override nim secret :) |
| 14:45:59 | Zevv | so, how are your repl adventures going, is it all working out? |
| 14:47:31 | sealmove | yup! |
| 14:48:29 | sealmove | first plan is to make it a working shell for my daily tasks so I can make it my default shell |
| 14:49:29 | sealmove | after that I'll keep adding feature that I miss as I use it |
| 14:50:02 | sealmove | and when the experience is satisfying I'll make a repo |
| 14:50:43 | sealmove | sadly nimscript module doesn't work in interactive mode (functions like cd, listFiles etc) |
| 14:50:56 | sealmove | so I'll have to implement some built-ins |
| 14:51:11 | sealmove | also, env will be typed, just like in xonsh |
| 14:51:24 | sealmove | not just a list of string-string key-value pairs |
| 14:51:42 | sealmove | for example $PATH can be a table of strings |
| 14:52:18 | sealmove | not table sorry, I mean array |
| 14:52:52 | sealmove | then you can use add() to add to $PATH |
| 14:55:00 | Zevv | sweet :) |
| 15:03:47 | * | freddy92 joined #nim |
| 15:05:07 | * | PMunch quit (Remote host closed the connection) |
| 15:05:25 | * | chimez quit (Quit: chimez) |
| 15:07:47 | * | fredrik92 quit (Ping timeout: 268 seconds) |
| 15:22:57 | * | waleee quit (Quit: WeeChat 2.4) |
| 15:32:08 | FromGitter | <bdhb> Hi everyone, new member here. I submitted a PR few days ago. What is the approval process like? How long does it usually take for the PR to be reviewed? |
| 15:34:35 | narimiran | @bdhb your tests are red. but we had failing tests on devel the other day, so i'm gonna restart them to be sure if that is because of your changes or not |
| 15:36:28 | FromGitter | <bdhb> Thanks @narimiran . Appreciate it. |
| 15:37:35 | narimiran | no problem. check back in an hour or two (probably the latter) to see if they're green. if not, try to fix the failing tests. if everything is ok, feel free to ping us here tomorrow if it isn't merged or at least reviewed |
| 15:37:40 | sealmove | I've got red PR too, and I'm 100% sure it's not my code |
| 15:39:09 | narimiran | sealmove: you're right. the same test is red on devel currently |
| 15:39:21 | narimiran | wait until is fixed |
| 15:39:29 | sealmove | ok thanks |
| 15:39:43 | narimiran | (and the same goes for @bdhb if the only failing test will be `tests/parallel/tdeepcopy2.nim`) |
| 15:47:19 | FromGitter | <alehander42> how do we |
| 15:48:36 | FromGitter | <alehander42> git dependency nimble |
| 15:48:46 | FromGitter | <alehander42> was it like `= git@..#branch` |
| 15:48:53 | FromGitter | <alehander42> i cant really remember the syntax to add it |
| 15:49:02 | narimiran | pkgname@#head ? |
| 15:49:26 | FromGitter | <alehander42> bless ya narimiran |
| 15:49:38 | narimiran | :) |
| 15:50:32 | FromGitter | <alehander42> but still hmm |
| 15:50:42 | FromGitter | <alehander42> where do i put the actual git repo |
| 15:50:43 | narimiran | :( |
| 15:51:17 | narimiran | i'm not sure i understand the question |
| 15:51:51 | FromGitter | <alehander42> e.g. i want to point to |
| 15:51:59 | FromGitter | <alehander42> myaccount/myfork.git#b |
| 15:54:13 | * | nsf joined #nim |
| 15:58:02 | * | floppydh quit (Quit: WeeChat 2.4) |
| 15:58:43 | FromGitter | <recloser> oops.nim(56, 20) Error: cannot instantiate CoolType; got: <A, B> but expected: <A, B> |
| 15:58:48 | FromGitter | <recloser> really makes you think |
| 15:59:08 | FromGitter | <mratsim> are you using macros? |
| 15:59:13 | FromGitter | <recloser> yeah |
| 15:59:49 | FromGitter | <recloser> https://gist.github.com/recloser/310c0a6408e23a8ee512f8273e380339 |
| 16:00:50 | FromGitter | <mratsim> mmmh I had a meta RFCs where I tracked those but with the RFCs changes the issues have been unliked :/ https://github.com/nim-lang/RFCs/issues/44 |
| 16:00:59 | * | Trustable joined #nim |
| 16:01:38 | shashlick | sealmove: what's your issue with nimscript |
| 16:02:12 | sealmove | shashlick: try using listFiles() in nim secret; it doesn't work. |
| 16:02:22 | sealmove | or any such function for that matter. |
| 16:04:38 | FromGitter | <recloser> mratsim: that stuff seems mostly related to typed macros, the macro i linked uses untyped idents, not syms |
| 16:06:03 | FromGitter | <recloser> also, oddly, the `foobarize` works fine, despite depending on those generic params, only `barbarize` fails, but i can't figure out why, since the generated ast seems to look fine |
| 16:06:07 | FromGitter | <alehander42> oh praise the Lord |
| 16:06:09 | FromGitter | <alehander42> finally found it |
| 16:06:18 | FromGitter | <alehander42> i just have to paste the https github link |
| 16:06:33 | FromGitter | <alehander42> i thought its name=<some kinf od git url> |
| 16:08:11 | FromGitter | <mratsim> @recloser I would have to get into it but indeed most of macros + generics issues I had where with genSym or getTypeImpl/getTypeInst direct reuse instead of creating a new ident node |
| 16:16:33 | shashlick | sealmove: okay not sure how nim secret works, but listFiles should work in a nims file |
| 16:17:04 | FromGitter | <liquid600pgm> just wanted to ask: why is the REPL executed with `nim secret`? |
| 16:17:17 | sealmove | shashlick: nimscript works fine in scripts, but not in interactive mode |
| 16:17:36 | sealmove | but it's not a problem at all |
| 16:17:45 | sealmove | it's not intended for a shell |
| 16:18:00 | shashlick | well you do have a readline proc in nimscript now |
| 16:18:03 | shashlick | so it is possible |
| 16:18:56 | sealmove | readline? |
| 16:19:43 | shashlick | https://nim-lang.github.io/Nim/nimscript.html#readLineFromStdin |
| 16:20:11 | shashlick | but ya, nimscript won't allow you to type listDirs() and execute the proc without some table of string => proc |
| 16:20:23 | shashlick | there's no eval |
| 17:00:49 | * | jjido quit (Quit: Connection closed for inactivity) |
| 17:02:16 | sealmove | I don't get rdstdin |
| 17:03:20 | sealmove | can't even use Ctrl-D, Ctrl-C etc |
| 17:03:57 | sealmove | and it writes to stdout which is non-overridable |
| 17:09:51 | sealmove | writing a native version using terminal module shouldn't be so hard, right? |
| 17:10:15 | * | stefanos82 joined #nim |
| 17:10:28 | shashlick | see if https://github.com/jangko/nim-noise helps |
| 17:12:35 | * | Jesin joined #nim |
| 17:13:44 | sealmove | ohhh thanks! |
| 17:20:44 | sealmove | works great |
| 17:30:02 | * | narimiran quit (Ping timeout: 245 seconds) |
| 17:31:42 | shashlick | cool |
| 17:31:53 | shashlick | is it possible to set compile mode to cpp with a pragma |
| 17:36:38 | shashlick | or even with nim.cfg |
| 17:36:53 | shashlick | so even if someone types `nim c`, the file will get compiled as cpp |
| 17:37:57 | sealmove | can I redirect stdout to stderr? |
| 17:42:53 | * | sealmove quit (Quit: WeeChat 2.4) |
| 17:44:41 | shashlick | Araq: i'm using importcpp for a proc from a header file, how come nim doesn't use g++ to process that file |
| 17:50:41 | * | seni joined #nim |
| 17:57:13 | shashlick | okay a nims file with setCommand("cpp") works |
| 18:22:56 | Araq | hmm is it too late to map 'func' to deep immutability for all its non-var arguments? |
| 18:30:08 | FromGitter | <arnetheduck> how deep? |
| 18:30:11 | * | a_b_m quit (Ping timeout: 255 seconds) |
| 18:30:34 | * | abm joined #nim |
| 18:38:02 | FromGitter | <recloser> i dunno about func, but i hope that if deep immutability checking is added then it will also be possible to designate particular params in regular procs as immutable, cpp style |
| 18:38:50 | FromGitter | <bdhb> @narimiran It looks like the only failing test is `tests/parallel/tdeepcopy2.nim` |
| 18:41:12 | * | seni quit (Remote host closed the connection) |
| 18:45:24 | * | nsf quit (Ping timeout: 252 seconds) |
| 18:51:11 | Araq | well "deep to the bottom", func depth(n: Node): int doesn't mutate the tree starting at 'n' |
| 18:52:09 | * | NimBot joined #nim |
| 18:52:12 | Araq | yes |
| 18:53:06 | FromGitter | <arnetheduck> funny, we just had that conversation yesterday for nimbus.. ie it's pretty sad that a non-var ref param can be used to mutate things, func or not |
| 18:53:44 | FromGitter | <kayabaNerve> Wat |
| 18:54:01 | FromGitter | <arnetheduck> one more thing I miss is the requirement at the call site to call out vars, so that when I call a function that will mutate stuff, I can see that at the call site and not have to trace both proc and type declaration |
| 18:54:07 | FromGitter | <kayabaNerve> One of the only two reasons I use ref is for its immutability. |
| 18:54:34 | FromGitter | <kayabaNerve> *mutability |
| 18:54:55 | FromGitter | <kayabaNerve> It I can still edit the fields of a var ref, that may be tolerable, albeit annoying as hell, but if I had to reconstruct the entire ref? |
| 18:55:01 | Araq | arnetheduck: that's not gonna happen, I like myseq.add(foo) too much |
| 18:55:14 | Araq | don't need shitty (var myseq).add(foo) |
| 18:58:24 | FromGitter | <arnetheduck> @kayabaNerve yeah, var ref works... right now, if there's a `proc(a: SomeType)`, you can tell from looking at it whether it's allowed to mutate a or not, so you have to go read the code.. there's also no way to guarantee that it won't mutate a (by mistake) |
| 18:58:46 | FromGitter | <recloser> @Araq: what about immutable refs for regular procs, tho? something like `let ref T`? |
| 18:59:50 | FromGitter | <arnetheduck> so a) it's not too late to change func, and b) proc should be changed also :) |
| 19:00:52 | FromGitter | <recloser> seems a tad too late to change proc to enforce "varness" for ref params |
| 19:04:17 | * | NimBot joined #nim |
| 19:06:08 | FromGitter | <kayabaNerve> @arnetheduck I rather not break anything but add an let label or something to arguments. |
| 19:08:23 | FromGitter | <arnetheduck> @kayabaNerve that would be ugly - it would be a special case for proc's which would be very odd, because for non-ref objects, you need to explicitly specify that it's mutable (immutable is a sane default in my eyes - relaxing a stronger guarantee is less error prone than the other way around) |
| 19:11:03 | FromGitter | <kayabaNerve> proc myProc(a: let T) |
| 19:11:10 | FromGitter | <arnetheduck> assuming nim will gain a larger user base after it makes promises about stability via a 1.0 release, I'd say it's rather cheap to break things now. |
| 19:11:23 | FromGitter | <kayabaNerve> Immutability as the default is a breaking change. |
| 19:11:33 | FromGitter | <kayabaNerve> A ref is a memory managed pointer. |
| 19:11:46 | FromGitter | <kayabaNerve> If you do not want to risk editing data passed via a ref, don't pass a reff. |
| 19:12:12 | FromGitter | <kayabaNerve> If you define your type as T, not ref T, it won't be mutable when passed. Problem solved. |
| 19:13:00 | FromGitter | <liquid600pgm> just please, don't make Nim into another one of those functional-super-memory-safe languages |
| 19:13:15 | FromGitter | <kayabaNerve> I'm happy where it is. |
| 19:13:20 | FromGitter | <liquid600pgm> same |
| 19:13:21 | FromGitter | <arnetheduck> that's a fine point to hang your assumptions on. I know how it works.. it doesn't help me at all when I'm looking at `proc a(x: X)` |
| 19:13:35 | FromGitter | <kayabaNerve> Want immutability? Don't use a ref. For some reason want ref immutability? Add a let label. |
| 19:14:12 | FromGitter | <kayabaNerve> Which is why you, as the special case, should have a let label. |
| 19:14:32 | FromGitter | <kayabaNerve> Instead of having the language change |
| 19:14:36 | FromGitter | <kayabaNerve> (in my opinion) |
| 19:14:47 | FromGitter | <liquid600pgm> ^ |
| 19:17:24 | FromGitter | <arnetheduck> well, looking at it from the proc's point of view, it's obviously not a special case to use `var` for mutability and defaulting to immutability.. I mean, it would be pretty weird having to choose between `proc a(x: var X)`, `proc a(x: X)` and `proc a(x: let X)` depending on the type of `X`.. you see it as a special case because you're used to the ref-is-mutable kind of thinking |
| 19:19:41 | FromGitter | <arnetheduck> I mean, looking at the keyword, `ref` it's a memory-managed reference.. it doesn't really say that much about mutability, really. that's what `var` and `let` are supposed to do |
| 19:20:26 | FromGitter | <liquid600pgm> `let` looks stupid in parameter context, I'd change it to `const` |
| 19:21:18 | FromGitter | <liquid600pgm> `let` is a verb, and `ref`/`var` are adjectives (I read them as reference-conted, variable) |
| 19:22:00 | * | nevermind left #nim ("Leaving") |
| 19:22:30 | FromGitter | <arnetheduck> call it what you like, but the fact remains that we have keywords related to mutability, and separate keywords related to addressing/memory.. conflating the two will inevitably force you to make more strange rules for other parts of the language - that has nothing to do with me, it's a fairly objective fact |
| 19:24:24 | Araq | mutability in Nim is attached to the symbol kind, not to the type and it's one of my favorite aspects about Nim |
| 19:25:06 | Araq | if we want more immutability, it should be an effect or a property of the parameter/routine, not part of the type |
| 19:25:31 | Araq | otherwise you get 'const seq[const T] |
| 19:25:38 | Araq | and stuff, no thanks |
| 19:26:22 | FromGitter | <arnetheduck> well, how does that hold up, in the `proc a` case? x is the symbol, it's not a `var`, and I can mutate what it refers to? |
| 19:27:14 | Araq | 1. 'var ref' is a pointer to a pointer, so using that to convey mutability is a mismatch |
| 19:28:14 | Araq | 2. the last time I tried to solve this puzzle without a 'writes' effect, it got messy, quickly. Consider this: |
| 19:28:21 | Araq | proc p(x: ref T) = |
| 19:28:27 | Araq | var m = x |
| 19:28:38 | Araq | m.field = value # tada, mutated |
| 19:34:39 | FromGitter | <arnetheduck> and if you block that assignment? |
| 19:35:11 | Araq | then you cannot traverse a tree to find the key, for example |
| 19:36:30 | Araq | or: you reinvented my write-tracking analysis, which works without a 'const' type ;-) |
| 19:37:16 | FromGitter | <arnetheduck> well, you can, sort of, if you allow `m` to be reassigned to another ref even if it's a `let`, no? |
| 19:37:35 | Araq | the property itself is not really hard to compute, but encoding it with a type is pretty foolish, IMO |
| 19:38:17 | FromGitter | <arnetheduck> so let/var determines if the thing that can be reached through that symbol can be mutated, not the symbol itself |
| 19:39:41 | Araq | so ... you propose that 'let' refers to the thing pointed to |
| 19:39:51 | Araq | and not to the variable itself |
| 19:40:15 | FromGitter | <arnetheduck> `propose` is maybe a strong word here.. `explore` maybe? but yes. |
| 19:40:27 | Araq | let it = head; while it != nil: result = it.field; it = it.next # allowed |
| 19:40:40 | FromGitter | <arnetheduck> yeah, something like that |
| 19:40:42 | Araq | let it = head; while it != nil: it.field = value; it = it.next # invalid |
| 19:40:57 | FromGitter | <arnetheduck> that's the one |
| 19:41:01 | Araq | well congrats, that's something I never considered :-) |
| 19:41:43 | FromGitter | <arnetheduck> just brute-force searching all combinations here ;) |
| 19:42:15 | Araq | it means we need 'proc p(x: mut ref T)' |
| 19:42:34 | Araq | or we live with 'var ref T' but that's really bad for inheritance and subtyping |
| 19:44:29 | * | matthias__ joined #nim |
| 19:45:10 | FromGitter | <arnetheduck> my real problem (in nimbus) is that we have a whole bunch of code that looks like `proc a(x: X)` where `X` is some graph type that needs the reference semantics, and there's no way for me to express that some proc's are read-only with respect to `x`, which I'm a bit sad about |
| 19:45:59 | Araq | well tell me about, the compiler is full of this sadness |
| 19:46:06 | Araq | :D |
| 19:46:37 | Araq | func a(x: X) would work but it's limited |
| 19:46:44 | FromGitter | <arnetheduck> ah yeah, well, `nlvm` also, but nobody is paying me to make `nlvm` stable, so I can sort of live with that ;) |
| 19:47:27 | Araq | proc a(x: X) {.writes: [].} is the more general solution but yet-another effect |
| 19:47:31 | FromGitter | <arnetheduck> with your super-immutable rule, yeah.. but it's.. ugly.. I wouldn't want to try to explain that rule to anyone |
| 19:51:54 | FromGitter | <arnetheduck> what these sorts of rules primarily do is that they let me trust code written by others, or by myself long ago, much more.. ie if I see a library in C++ that observes const hygiene, I'll implicitly trust it more and will be more willing to reuse that code rather than writing my own, because I will know that the compiler upholds certain standards for me, with certain classes of bugs & issues not present.. for solo |
| 19:51:54 | FromGitter | ... programming of small scripts, sure, it doesn't matter that much, but once you start growing larger pieces of software.. well.. |
| 19:52:02 | * | Vladar quit (Remote host closed the connection) |
| 19:59:03 | * | jjido joined #nim |
| 20:00:15 | Araq | what's hard about my rule to explain? 'func' means you cannot access global variables nor mutate anything |
| 20:03:06 | FromGitter | <arnetheduck> what would a `func(x: var X)` mean then? |
| 20:03:19 | FromGitter | <arnetheduck> for a non-ref X (I have to specify that :)) |
| 20:05:07 | FromGitter | <kayabaNerve> @arnetheduck It says it's a reference. References are mutable. ⏎ ⏎ Araq: Why if we don't have mut ref T or var ref T, but let ref T :thinking: No breaking changes and it makes pointers, which exist to mutate things (I'm sure we can discuss OSs and the 1980s and you can prove me wrong, but I'm discussing in modern times when you aren't on a barebones system; you pass a pointer to mutate the original object), |
| 20:05:07 | FromGitter | ... remain mutable. ⏎ ⏎ I'm against modifying func because func is just noSideEffect. If I pass in an object to be mutated, that's not a side effect. ... [https://gitter.im/nim-lang/Nim?at=5c8179731c597e5db69da60d] |
| 20:06:44 | * | lf-araujo joined #nim |
| 20:10:05 | Araq | well 'var X' still mutates |
| 20:10:15 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 20:13:10 | * | Trustable quit (Remote host closed the connection) |
| 20:23:15 | dom96 | hey guys |
| 20:23:25 | dom96 | another day, another argument about a breaking change? :) |
| 20:24:57 | * | jjido quit (Quit: Textual IRC Client: www.textualapp.com) |
| 20:25:29 | * | jjido joined #nim |
| 20:25:55 | dom96 | bah, that's why I couldn't find my docgen issue |
| 20:25:59 | dom96 | it was moved to RFCs |
| 20:26:23 | FromGitter | <arnetheduck> > another argument about a breaking change ⏎ ⏎ it's quite likely I'd be on the other side of that argument if I was responsible for the language :) being an external observer comes with a refreshing degree of freedom to challenge assumptions |
| 20:26:44 | dom96 | Anyone wanna give me a TL;DR? |
| 20:27:58 | FromGitter | <kayabaNerve> dom96: @arnetheduck doesn't want things to be mutable. I suggested adding a let to the function parameter. @arnetheduck wants the default to be immutable, not default to be mutable. He and Araq talked. Making func default immutable came up to. |
| 20:28:23 | FromGitter | <recloser> tldr: araq considers making func enforce deep ref/ptr immutability; opinions on the matter differ |
| 20:28:37 | FromGitter | <kayabaNerve> The default is immutable; you have to use var, ptr, or ref to make it mutable. ATD just wants to expand to also include ref, despite pointers being designed to be mutable. |
| 20:28:57 | dom96 | yeah. Tough problem |
| 20:29:01 | FromGitter | <kayabaNerve> If I pass a ref to a func, and the func uses the ref for the reason it's a ref, that's not a side effect |
| 20:29:03 | FromGitter | <kayabaNerve> I passed it |
| 20:29:08 | FromGitter | <kayabaNerve> I said, use this. |
| 20:29:12 | FromGitter | <kayabaNerve> That's a regular effect |
| 20:29:32 | FromGitter | <kayabaNerve> There's also the writes pragma, so I suggested ATD make his own function macro called duck |
| 20:29:39 | FromGitter | <kayabaNerve> That adds an empty writes pragma |
| 20:29:39 | dom96 | I think we should solve this after 1.0 is out ;) |
| 20:29:57 | FromGitter | <kayabaNerve> I'm fine with delaying it until breaking changes are harder to add in lol |
| 20:30:10 | FromGitter | <kayabaNerve> Delaying it to 1.0 will effectively kill it :D |
| 20:34:43 | FromGitter | <arnetheduck> mostly I pointed out that let & var are mutability modifiers, while ref, ptr et al are memory handling modifiers - the rest follows logically, really - some people however want ref to be both about memory and about mutability ;) |
| 20:35:10 | FromGitter | <kayabaNerve> The data at pointers is mutable though |
| 20:35:12 | FromGitter | <kayabaNerve> That' |
| 20:35:19 | FromGitter | <kayabaNerve> *That's... |
| 20:35:22 | FromGitter | <kayabaNerve> the POINT :D |
| 20:35:55 | FromGitter | <arnetheduck> well, in computer memory, everything is mutable. I kind of like assembler for that, there's no doubt on what ground you're standing. |
| 20:36:54 | dom96 | Thank you to everyone that voted in https://github.com/nim-lang/Nim/pull/10797 btw, hopefully the majority will put this change to rest. It certainly has given me a bit more faith in the Nim community. |
| 20:37:32 | FromGitter | <arnetheduck> voting is what you do when you don't actually want to solve a problem and you give up ;) |
| 20:38:49 | dom96 | Wasn't my idea :P |
| 20:42:35 | dom96 | On a side note, I'm just starting a new package and it seems I am naturally pushed into using methods + inheritance, that makes me uncomfortable. |
| 20:42:42 | dom96 | Are these still on the chopping block? |
| 20:46:06 | FromDiscord | <exelotl> From what I heard it’s just multi-methods? But you’re more in the know than me so 🤷 |
| 20:47:44 | * | vlad1777d joined #nim |
| 20:55:01 | FromGitter | <kayabaNerve> dom96 What do you mean inheritance? |
| 20:55:29 | dom96 | What could I mean? `Foo = ref object of RootObj` |
| 20:56:54 | FromGitter | <kayabaNerve> Why would that be removed? |
| 20:57:01 | FromGitter | <kayabaNerve> I actually need polymorphism lol |
| 20:57:07 | FromGitter | <kayabaNerve> It's a critical part of my codebase |
| 20:57:57 | FromGitter | <kayabaNerve> I have a data structure where there can be five different types of entries in it. Polymorphism allows me to store everything as an "Entry" and then cast to the proper type and access unique fields. |
| 20:58:16 | * | narimiran joined #nim |
| 20:58:40 | FromGitter | <kayabaNerve> It's also handled really well in Nim |
| 20:58:58 | FromGitter | <kayabaNerve> So I'd love to know if it is on the chopping block right now, if it's going to be, and why? |
| 20:59:38 | Araq | inheritance stays and 'method' too but the 'multi' aspect will go |
| 21:01:02 | Araq | also, new idea: let's have 'const ref T' but only for parameters and inside the proc body we use my write-tracking algorithm to enforce it |
| 21:01:24 | FromGitter | <kayabaNerve> What's multi? :P |
| 21:01:47 | FromGitter | <kayabaNerve> And I'm very happy we're keeping inheritance :D |
| 21:05:42 | dom96 | Araq: Honestly, just leave it until after 1.0 is out |
| 21:05:50 | FromGitter | <kayabaNerve> @arnetheduck If the change isn't breaking and forces you to add a new label, I'd be happy to learn macros and write you a duck macro if it's possible within the Nim language. ;) |
| 21:05:52 | dom96 | Don't turn Nim into C++ |
| 21:06:44 | Araq | sure ok, but 'const ref T' is available and won't break anything and also works for 'method' etc |
| 21:07:23 | Araq | it would be verbose though so making 'func' sugar for 'const' parameters would be nice |
| 21:08:36 | Araq | so unless we declare 'func' as unstable we better sort this out for v1 |
| 21:09:49 | dom96 | yes, so you can add it post-1.0 |
| 21:10:20 | Araq | also, deeply immutable 'let' would be sweet, it's what I always want to express |
| 21:12:41 | * | cgfuh quit (Quit: WeeChat 2.3) |
| 21:13:20 | * | hoijui joined #nim |
| 21:24:10 | FromGitter | <arnetheduck> @kayabaNerve I know macros well enough and I don't like them ;) too steep a learning curve to impose on my fellow programmers, specially if I have to write one to work around a crufty design solution based on historical accident, explain what the past mistake was then explain what the macro does, and then be incompatible with the entire eco-system because I'm special |
| 21:24:54 | FromGitter | <arnetheduck> it's why 99% of all dsl suck.. I want to use my general-purpose knowledge, not their special cases |
| 21:28:27 | FromGitter | <arnetheduck> why I think the immutable-by-default is a worthwhile breakage is that I believe it would lead to more *high quality* nim code out there in libraries in the long run, which would float my boat, because then I wouldn't have to write all that code myself ;) |
| 21:30:23 | FromGitter | <Clyybber> I think it's convinient enough to have optional deep immutability |
| 21:30:40 | FromGitter | <Clyybber> So it's opt-in. |
| 21:30:53 | jjido | don't you need codeflow analysis for deep immutable? Unless you block calls to mutable code within the func |
| 21:31:16 | FromGitter | <arnetheduck> basic behavioral science says opt-in means few people use it |
| 21:32:03 | FromGitter | <Clyybber> One could implement hints in the compiler that hint at using deep-immutability, if it's possible. |
| 21:34:25 | FromGitter | <Clyybber> It would be a really big breaking change, and you would then sometimes write procs like `proc(x: let X)` which reads a bit weird. |
| 21:34:28 | FromGitter | <arnetheduck> thing is, 95% of people don't even know or care what the whole issue is about |
| 21:34:54 | FromGitter | <arnetheduck> hell, I would prefer not to know :) |
| 21:36:47 | FromGitter | <Clyybber> IMO let just isn't the right keyword for deep-immutability, but thats very subjective |
| 21:37:00 | * | narimiran quit (Ping timeout: 252 seconds) |
| 21:37:42 | FromGitter | <Clyybber> OTOH I can't seem to come up with a 3 letter abbreviation for deep-immutabilty |
| 21:37:44 | FromGitter | <arnetheduck> `proc(x: let X)` on balance, I think makes things worse.. `proc(x: X)` already is immutable unless I use a ref type.. there are all kinds of reasons not to use ref - mutability is just one more, so if I have to choose, I prefer to associate `ref` with `avoid` and be done with it ;) |
| 21:38:36 | FromGitter | <arnetheduck> I mean, there are other issues to... ⏎ ⏎ ```let x = y``` ⏎ ⏎ is x a copy? you have no idea until you look at the type definition, far away [https://gitter.im/nim-lang/Nim?at=5c818f5c7851db134985949c] |
| 21:38:56 | Araq | 'avoid ref' is true no matter how we patch it indeed |
| 21:38:59 | FromGitter | <arnetheduck> you wanna change from non-ref to ref? good luck |
| 21:39:42 | * | matthias__ quit (Read error: Connection reset by peer) |
| 21:40:01 | FromGitter | <arnetheduck> so let's rename it to `avoid` :) `avoid object of RootObj` reads pretty well, considering what the side effects are ;) |
| 21:40:07 | Araq | jjido: we have the analysis ready, but no syntax for it |
| 21:40:19 | FromGitter | <mikra01> hi all. I do mainly pl/sql. every parameter is immutable by default. if not you have to use the 'out' keyword. thats nice I think. you see at a glance whats happening. |
| 21:41:06 | FromGitter | <Clyybber> In Nim every parameter is immutable by default too, but not deeply-immutable. The equivalent to `out` is `var` in Nim |
| 21:41:19 | Araq | pl/sql is not used to implement trees or graphs so it get away without pointers more easily. |
| 21:41:45 | Araq | *it can get |
| 21:41:57 | FromGitter | <arnetheduck> they're deeply immutable if they're not `ref` - at least in the sense that object fields follow the mutability of the symbol, for non-ref objects |
| 21:42:18 | FromGitter | <Clyybber> So if `let` were to mean deep-immutability, would there be any reason to add/keep a keyword that implies non-deep-immutability? |
| 21:43:27 | jjido | Clyybber: no |
| 21:43:44 | * | rnrwashere joined #nim |
| 21:44:01 | jjido | it is default |
| 21:44:22 | FromGitter | <Clyybber> I mean if deep-immutability were the default. |
| 21:44:28 | jjido | Araq: does it just need a keyword for parameters? |
| 21:44:31 | FromGitter | <mikra01> you can do trees in pl/sql. but thats very ugly :-) especially when tables are involved.. |
| 21:45:17 | Araq | I know SQL quite well, wrote a garbage collector in it |
| 21:45:42 | * | theelous3_ joined #nim |
| 21:46:02 | FromGitter | <mikra01> :-> |
| 21:46:12 | jjido | (what kind of garbage did it collect I wonder) |
| 21:46:46 | FromGitter | <mikra01> on the database there is always: shit in, shit out :-) |
| 21:46:58 | FromGitter | <Clyybber> @Araq Is there any performance benefit if one uses `let some = ref someobj` instead of `var some = ref someobj`? |
| 21:47:53 | dom96 | Araq: Are generic methods meant to work or not? |
| 21:48:05 | dom96 | I'm getting a warning: generic method not attachable to object type is deprecated |
| 21:48:35 | Araq | well better avoid this warning :P |
| 21:48:54 | Araq | generic methods have been patched. and then patched. and they still don't work well. |
| 21:49:01 | FromGitter | <mikra01> @ Clyybber this confused my a lot at the beginning |
| 21:49:20 | Araq | in C++ virtual templates are not supported either iirc |
| 21:49:54 | Araq | sometimes C++ got the design right :P |
| 21:50:57 | dom96 | :/ |
| 21:51:20 | dom96 | I can either use floats everywhere or use a generic... |
| 21:56:00 | dom96 | oh well, let me try to rethink this poor Python OOP design I'm basing this package on |
| 21:56:12 | Araq | :-) |
| 21:56:17 | FromGitter | <Clyybber> @mikra01 Do you know the answer? |
| 21:57:31 | Araq | the GC collected table entries that are not referenced by the roots |
| 21:57:50 | Araq | I stored a graph in the DB. |
| 21:58:32 | FromGitter | <mikra01> @Clyybber I assume that depends on the compiler. Its a pointer anyway. if it's in the cache it should be faster. memory is slow. |
| 22:00:38 | Araq | Clyybber: there is no difference |
| 22:00:51 | * | theelous3_ quit (Read error: Connection reset by peer) |
| 22:01:23 | FromGitter | <Clyybber> Ok, then I wouldn't mind changing let to mean deeply-immutable |
| 22:01:45 | Araq | yeah, nobody would "mind", it's just hard to design properly :P |
| 22:03:52 | Araq | eventually we'll figure it out. |
| 22:04:03 | FromGitter | <Clyybber> But what are immutable refs useful for anyways? Can't you just write `proc(x: X)` instead of `proc(x: ref X)` and then dereference the ref object at the callsite? |
| 22:04:36 | FromGitter | <Clyybber> s/immutable/deeply-immutable |
| 22:04:43 | Araq | that's only one level deep |
| 22:05:03 | FromGitter | <Clyybber> Hmm, I se |
| 22:05:07 | FromGitter | <Clyybber> see |
| 22:05:28 | Araq | plus the deref is ugly, but I have a proposal for that... |
| 22:06:17 | FromGitter | <Clyybber> Nice |
| 22:07:12 | FromGitter | <Clyybber> Araq: Btw, I'm struggling to find the issue I had yesterday, I tried your suggestion with using valgrind, but it doesn't report any leaks whatsoever. |
| 22:07:29 | Araq | it reports memory corruptions |
| 22:07:39 | Araq | and that's the problem you should look for |
| 22:07:46 | FromGitter | <Clyybber> Oh yeah, none of that too, afaict |
| 22:12:09 | * | krux02 quit (Remote host closed the connection) |
| 22:13:39 | FromGitter | <Clyybber> nvrmind... |
| 22:14:35 | Araq | https://phys.org/news/2014-09-natural-networks-stable-man-made.html#nRlv |
| 22:18:55 | FromGitter | <kayabaNerve> Araq: I, in the limited amount I matter, if any, support a deep immutable let, but func sugar for const redefines func. In my opinion, a changed passed ref isn't a side effect versus an effect. This would make func no side effects + no write effects. ⏎ ⏎ I also just prefet let over const for the naming. ⏎ ⏎ @arnetheduck You want to make ref not a ref though. You want to make a... view. I actually like |
| 22:18:55 | FromGitter | ... that. `view` ... [https://gitter.im/nim-lang/Nim?at=5c8198cf1c597e5db69e7edb] |
| 22:19:18 | FromGitter | <deech> @Araq: Is there a way to print out the known subtypes of a type at compile time? |
| 22:19:26 | FromGitter | <kayabaNerve> Wait, are Nim macros powerful enough where you can create a third ptr/ref? |
| 22:19:51 | FromGitter | <kayabaNerve> If you could define a type as `view T` and then auto generate the helper functions... |
| 22:19:58 | Araq | deech: we don't have that info in the compiler |
| 22:22:23 | Araq | kayabaNerve: too tired to think about it |
| 22:22:26 | FromGitter | <deech> The typechecker has that information though, right? Otherwise how does it resolve `proc`'s with subtyped arguments? Do you mean that the information isn't made available? |
| 22:23:04 | Araq | well we know if X inherited from Y, but we don't keep a list from Y's perspective |
| 22:23:54 | FromGitter | <deech> Wait I got my vocabulary all turned around, what I want is a list of parents not children, sorry. |
| 22:24:50 | Araq | that's what macros.getType() gives you too, if you stroke it a little |
| 22:25:04 | FromGitter | <deech> Cool, I'll check it out. Thanks! |
| 22:25:17 | FromGitter | <Clyybber> @Araq I guess I can ignore "jump depends on uninitialised value" and "use of uninitialised value"? |
| 22:25:37 | Araq | maybe |
| 22:26:54 | FromGitter | <Clyybber> If so, then this would be the interesting bit: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c819aae86e34a126fa417ed] |
| 22:27:20 | FromGitter | <Clyybber> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c819ac786e34a126fa41848] |
| 22:27:58 | * | lf-araujo quit (Ping timeout: 250 seconds) |
| 22:31:21 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 22:31:29 | Araq | also run your program with -d:useSysAssert -d:useGcAssert |
| 22:31:52 | FromGitter | <Clyybber> Ok |
| 22:32:56 | FromGitter | <Clyybber> Does -d:useGcAssert do anything when I call GC_disable() at the beginning? |
| 22:34:38 | FromGitter | <Clyybber> Huh, when I do that, it doesn't crash anymore... |
| 22:35:07 | Araq | Heisenbug |
| 22:35:19 | FromGitter | <Clyybber> lol |
| 22:38:37 | * | rnrwashere quit (Remote host closed the connection) |
| 22:39:01 | * | rnrwashere joined #nim |
| 22:39:57 | FromGitter | <Clyybber> The invalid read and write valgrind reported disappears too, when using -d:useSysAssert -d:useGcAssert |
| 22:40:31 | FromGitter | <Clyybber> So that confirms that those invalid write/reads are indeed the issue |
| 22:43:09 | FromGitter | <Clyybber> I just confirmed that it is `-d:useSysAssert` which fixes the issue |
| 22:44:09 | * | stefanos82 quit (Remote host closed the connection) |
| 22:49:35 | FromGitter | <Clyybber> And it doesn't quit instead of crash either... It just runs the whole program successfully... |
| 22:50:07 | * | vlad1777d quit (Ping timeout: 240 seconds) |
| 22:50:47 | * | hoijui quit (Ping timeout: 240 seconds) |
| 22:51:47 | * | hoijui joined #nim |
| 22:52:44 | FromGitter | <Clyybber> Which is really weird, since that means that this https://github.com/nim-lang/Nim/blob/2b5e48d80735be60c68023de114a586bbcc18360/lib/system.nim#L1660 branch is never evaluated so it shouldn't make a difference right? |
| 22:52:54 | FromGitter | <mikra01> what is the technically difference between ⏎ castcstring (teststr) and teststr.cstring? if you do a ⏎ ffi call (printf for instance). ⏎ the type cast fails; the type conversion works.. [https://gitter.im/nim-lang/Nim?at=5c81a0c5bf7990126e68500c] |
| 22:55:26 | FromGitter | <Clyybber> @mikra01 AFAIK the latter also makes sure that the length is converted appropriately |
| 22:55:46 | FromGitter | <Clyybber> Because cstring uses null-terminated strings, while nim stores the length |
| 22:56:27 | FromGitter | <Clyybber> Btw, you can use backticks to make gitter treat your code as code, like this: `somecode` |
| 22:58:45 | FromGitter | <mikra01> @Clybber ah thank you. I got it :-). also thanks for the backticks hint.. |
| 23:04:22 | * | vlad1777d joined #nim |
| 23:09:59 | Araq | Clyybber: please report your problem on the forum if you can provide something reproducible |
| 23:10:04 | * | ryukoposting joined #nim |
| 23:10:51 | FromGitter | <Clyybber> Yep, will do. |
| 23:12:59 | FromGitter | <deech> Not sure if this counts as a bug but the following fails to compile: ⏎ ⏎ ```let x = someSideEffectingOp ⏎ x = x``` [https://gitter.im/nim-lang/Nim?at=5c81a57be527821f0a1febc2] |
| 23:13:59 | FromGitter | <deech> I guess even in the second case it's safe. |
| 23:14:44 | * | lf-araujo joined #nim |
| 23:15:31 | FromGitter | <Clyybber> But let means its immutable, so I think its fair enough to disallow this |
| 23:16:28 | ryukoposting | since nightly has JSON now, shouldn't I be able to call parseJson() in a const declaration? |
| 23:16:45 | ryukoposting | e.g. const x = readFile("123.json").parseJson |
| 23:21:49 | FromGitter | <deech> @Clyybber Sure. I think I've come around to that. The compiler *could* do some analysis since that example is provably safe but I also like how fast Nim compiles so I'm all for keeping the compiler as simple as possible. Just a curious quirk. |
| 23:22:49 | FromGitter | <Clyybber> I agree. also IMO allowing this would be a quirk, but thats subjective I guess |
| 23:22:54 | FromGitter | <mikra01> cu I am out now.. |
| 23:23:05 | FromGitter | <Clyybber> bb |
| 23:23:31 | FromGitter | <recloser> @ryukoposting you can call parseJson at compile time, but you can't assign a ref object to const |
| 23:25:23 | ryukoposting | aaah |
| 23:25:41 | ryukoposting | no problem, I'll just have to structure this carefully |
| 23:26:54 | * | lritter quit (Quit: Leaving) |
| 23:32:51 | lf-araujo | Hi all, is it possible to make nim compiler run a nim file, but without saving the binary in current dir? |
| 23:33:25 | lf-araujo | in other words, can I direct the compiler to save the binary on /tmp |
| 23:33:56 | ryukoposting | probably just use -o |
| 23:34:27 | lf-araujo | thanks |
| 23:37:28 | * | hoijui quit (Remote host closed the connection) |
| 23:50:23 | ryukoposting | successfully parsed the EC2 API spec, and used it to declare Ec2Metadata object type, and declared a const of that type and populated it B) |
| 23:52:01 | ryukoposting | thankfully, the AWS API metadata stuff is already camel case- I don't even have to fix the style B) |
| 23:52:37 | FromGitter | <Clyybber> Araq: Forum post is up: https://forum.nim-lang.org/t/4700#29331 |
| 23:53:05 | ryukoposting | >heisenbug |
| 23:53:11 | ryukoposting | never heard that before, I like it |
| 23:53:22 | * | rnrwashere quit (Remote host closed the connection) |
| 23:53:36 | FromGitter | <Clyybber> I like the name, not so much the thing it describes |
| 23:53:45 | ryukoposting | fair enough lol |
| 23:54:27 | ryukoposting | I gotta admit, I'm perfectly content to be a lowly library writer, the stuff the nim compiler has to do is mind-boggling |
| 23:54:30 | FromGitter | <Clyybber> @dom96 Hey, it seems my account and thus my post is modeated on the forums, can you change that? |
| 23:54:59 | * | rnrwashere joined #nim |
| 23:55:01 | dom96 | yes, I'm not the only one though |
| 23:55:17 | dom96 | (Just for reference :)) |
| 23:55:41 | FromGitter | <Clyybber> Thank you :D |
| 23:59:27 | * | rnrwashere quit (Ping timeout: 252 seconds) |