| 00:00:01 | Araq | flaviu: oh yeah. you're right |
| 00:00:03 | dom96 | dtscode: yay, I like questions. |
| 00:00:06 | vikaton | because I probably have the least amount of programming experience here |
| 00:00:27 | dom96 | flaviu: oh yeah! That is exciting. |
| 00:00:27 | dtscode | What resources did you use when you went to implement the async* libs? |
| 00:00:40 | dom96 | flaviu: We should make that into a proper github feature request |
| 00:00:46 | Araq | the _ syntax is something we should copy |
| 00:00:56 | Araq | can we then remove the => ? |
| 00:01:00 | flaviu | dom96: Like https://github.com/Araq/Nim/issues/2179? |
| 00:01:07 | dtscode | We have => syntax? |
| 00:01:10 | dtscode | D: |
| 00:01:16 | dtscode | 2c#4me |
| 00:01:17 | dom96 | dtscode: msdn, posix docs, googling "async winapi" "async posix" mostly. |
| 00:01:17 | Araq | dtscode: in future.nim |
| 00:01:28 | dtscode | dom96: Thanks. |
| 00:01:35 | Araq | dom96: you also read a couple of articles |
| 00:01:43 | dtscode | Araq: Ah... yeah I would never go in there |
| 00:01:58 | dom96 | Araq: oh dear. Were you watching me? |
| 00:02:08 | def- | I think that's the first time I've seen someone looking for a Nim developer: http://www.guru.com/jobs/mobile-library-for-nim-lang/1128547 |
| 00:02:09 | flaviu | Sometimes you want to label your params, like `(a, b) => (b + a) * a` |
| 00:02:10 | dom96 | Araq: Also, we can never remove => |
| 00:02:11 | Araq | dude, we're the same person |
| 00:02:56 | dom96 | def-: damn, is this for real? |
| 00:03:19 | def- | dom96: looks like it, but never heard of that website before |
| 00:03:46 | Araq | def-: can you write the FAQ destroying the petty "nil checks missing" argument? |
| 00:04:15 | dom96 | def-: seems a bit odd though |
| 00:04:23 | def- | Araq: I don't have much knowledge for either side of the argument and didn't bother to read into it because it's not very relevant for me personally |
| 00:04:40 | flaviu | The budget on that listing is low for something that's supposed to work with both ios and android. |
| 00:04:41 | def- | so better not |
| 00:04:57 | dom96 | def-: kind of vague, and Nim isn't exactly the obvious language to use for iOS and Android dev. |
| 00:05:07 | dom96 | and what flaviu said |
| 00:05:59 | dtscode | Why wouldn't nim work well with android/IOS? |
| 00:06:15 | flaviu | dtscode: That person wants both, from the same codebase. |
| 00:06:32 | dtscode | Well thats just stupid |
| 00:06:57 | flaviu | Yep, and IOS/android is really close to uncharted territory for Nim anyway. |
| 00:07:08 | dtscode | Actually, you know what would be great? One standard format for apps. An app-protocol as it were |
| 00:07:15 | Araq | no it's cool and works. |
| 00:07:20 | flaviu | dtscode: Like webapps? |
| 00:07:26 | dtscode | flaviu: Phone apps |
| 00:07:35 | Araq | it's called ... er ... cannot remember |
| 00:07:49 | flaviu | dtscode: So a webview to a webapp published in an app store? |
| 00:07:57 | Araq | but it's based on Mono and a commercial product |
| 00:08:02 | Araq | and it works |
| 00:08:16 | flaviu | Xamarin? |
| 00:08:20 | dtscode | flaviu: I guess that would work. I'm more referring to the meta of it |
| 00:08:29 | Araq | flaviu: yeah |
| 00:08:41 | def- | at least nim + sdl2 seems perfectly fine for android, didn't try iOS |
| 00:09:04 | dtscode | sdl works on android too? |
| 00:09:09 | flaviu | Have people seen https://h2o.github.io/? |
| 00:09:10 | dtscode | Or has it always? |
| 00:09:13 | dtscode | Yes |
| 00:09:18 | flaviu | It got posted on reddit today, seems neat enough. |
| 00:09:29 | def- | dtscode: You've seen my post? http://hookrace.net/blog/porting-nes-go-nim/ |
| 00:09:44 | dtscode | def-: I have not. Thanks :D |
| 00:10:02 | dtscode | At some point in the future I was going to write an emulator in Nim. Maybe a gameboy one. |
| 00:10:10 | def- | dtscode: dom96 is writing one already |
| 00:10:11 | flaviu | An MIT web server supporting tls, http2? yes please. |
| 00:10:17 | dtscode | def-: I know. |
| 00:10:23 | def- | dtscode: I know because i wanted to write one too and then went for NES instead |
| 00:10:47 | dtscode | I wouldn't mind doing NES. I just want to do Gameboy because I will actually use that |
| 00:11:03 | dtscode | flaviu: Ah is that why its so good? Because its MIT? |
| 00:12:06 | flaviu | dtscode: Yes, permissive license, excellent performance, http2. All I need to do now is see how horrible the C api is ;) |
| 00:12:18 | dtscode | :D |
| 00:12:46 | dtscode | Look at me talking when theres Nimbus2 work to do |
| 00:16:04 | dom96 | def-: dtscode: might take a while for me to finish mine |
| 00:16:27 | dtscode | def-: Lets tie him up with nim issues until we finish ours |
| 00:16:43 | vikaton | can I delete the folder the nim tarball created in my root folder now? |
| 00:16:46 | def- | dtscode: I'm not going to write another emulator |
| 00:16:49 | vikaton | now that its exported or nahh? |
| 00:16:54 | def- | vikaton: nope, keep it! |
| 00:17:04 | vikaton | awe :( |
| 00:17:05 | dtscode | Thats where the stdlib is isn't it? |
| 00:17:10 | def- | vikaton: the binary and stdlib is in there, you need it |
| 00:17:11 | vikaton | yeah |
| 00:17:23 | vikaton | could I cp it to PATH ? |
| 00:17:25 | def- | vikaton: by exporting it you just tell your shell where to find the nim binary |
| 00:17:42 | def- | no, you would also have install the standard library, there's an install.sh script for that |
| 00:17:54 | vikaton | ok |
| 00:18:11 | dtscode | You know... depending on how often coopernurse rebuilds his docker image, we technically don't have to build nim anymore |
| 00:18:12 | def- | but it's better to add the nim-bin path to PATH instead of installing it |
| 00:18:16 | dtscode | just run the docker image |
| 00:20:38 | * | gsingh93 joined #nim |
| 00:21:31 | vikaton | ahh shoot |
| 00:21:47 | vikaton | codeanywhere.com doesnt have Nim support in their text editors :( |
| 00:26:32 | * | vendethiel joined #nim |
| 00:26:44 | def- | vikaton: ekarlso was working on something like that for Nim, not sure what happened to it |
| 00:27:01 | vikaton | for codeanywhere? |
| 00:27:13 | def- | ah wait, I thought codeanywhere is something else, oops |
| 00:27:20 | vikaton | lol |
| 00:27:44 | flaviu | Has anyone figured out a functioning implementation of python's "enumerate"? |
| 00:28:08 | def- | flaviu: pairs? |
| 00:28:49 | flaviu | def-: I have an iterator, not a type. |
| 00:29:04 | flaviu | I need a `iterator enumerate[T](iter: iterator(): T): tuple[i: int, val: T]`. |
| 00:30:54 | def- | flaviu: probably a template if you want it to work with inline iterators |
| 00:31:53 | vikaton | uhhh |
| 00:32:11 | dtscode | Damn it I got distracted again |
| 00:32:12 | vikaton | CC: yup |
| 00:32:12 | vikaton | Error: unhandled exception: The system cannot find the file specified |
| 00:32:12 | vikaton | [OSError] |
| 00:32:23 | vikaton | What file? :S |
| 00:32:31 | flaviu | vikaton: Your C compiler. |
| 00:32:37 | flaviu | Do you have gcc/clang installed? |
| 00:32:49 | vikaton | oh damn |
| 00:32:51 | vikaton | ! |
| 00:33:33 | vikaton | I dont have MinW installed |
| 00:33:41 | dtscode | You're on windows? |
| 00:34:17 | vikaton | Yeah |
| 00:34:52 | flaviu | vikaton: I thought you mentioned a bashrc? |
| 00:35:10 | vikaton | flaviu: thats my linux vps |
| 00:35:16 | vikaton | : ] |
| 00:35:41 | vikaton | I switched over to Windows since codeanywhere didnt have Nim support for syntax |
| 00:37:50 | * | ir2ivps10 quit (K-Lined) |
| 00:38:31 | vikaton | Whats a valid indentation ? |
| 00:42:11 | vikaton | nvm |
| 00:45:51 | * | gsingh93 quit (Ping timeout: 276 seconds) |
| 00:47:45 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 01:06:26 | dtscode | Which call would be more expensive? startsWith on a string of no more than 10 characters or split an arbitrary string on ' '? |
| 01:08:41 | renesac | split, you have to do memory allocation, copy, etc |
| 01:09:22 | renesac | and parse the whole string |
| 01:11:36 | dtscode | Yeah I figured. |
| 01:11:41 | dtscode | Damn. Oh well |
| 01:13:34 | flaviu | dtscode: Also, that whole "premature optimization" thing. You're writing an IRC bot, a few extra nanoseconds are nothing compared to the network. |
| 01:13:48 | dtscode | flaviu: Its not nanoseconds this time |
| 01:14:35 | dtscode | Although, it might be just calling the docker image takes a bit of time, but I'm working on it |
| 01:15:39 | renesac | string joining is usually much more a performance problem than spliting, because it is easy to program a algorithm with quadratic time complexity |
| 01:19:05 | * | brson quit (Quit: leaving) |
| 01:19:36 | * | brson joined #nim |
| 01:38:06 | * | brson quit (Quit: leaving) |
| 01:38:18 | * | brson joined #nim |
| 01:44:49 | * | Fernandos quit (Quit: ➾ EXIT ⌨) |
| 01:49:42 | * | brson quit (Quit: leaving) |
| 01:53:14 | vikaton | do you guys think Nim will be adopted in the market post 1.0 and afterwards? |
| 01:54:21 | filwit | yes |
| 01:56:17 | vikaton | Nice |
| 02:11:15 | * | dtscode quit (Ping timeout: 264 seconds) |
| 02:15:29 | * | darkf joined #nim |
| 02:21:34 | * | notfowl quit (Excess Flood) |
| 02:22:28 | * | notfowl joined #nim |
| 02:25:35 | * | johnsoft quit (Ping timeout: 256 seconds) |
| 02:26:17 | * | johnsoft joined #nim |
| 02:56:17 | * | dddddd quit (Ping timeout: 244 seconds) |
| 03:30:23 | * | pregressive quit (Remote host closed the connection) |
| 03:30:38 | * | pregressive joined #nim |
| 03:34:49 | * | Perelandric quit (Ping timeout: 246 seconds) |
| 03:35:01 | * | notfowl quit (Excess Flood) |
| 03:35:28 | * | notfowl joined #nim |
| 03:40:16 | * | notfowl quit (Excess Flood) |
| 03:41:28 | * | notfowl joined #nim |
| 03:43:09 | * | saml_ quit (Ping timeout: 245 seconds) |
| 03:44:19 | * | endragor joined #nim |
| 03:55:07 | * | intra quit (Ping timeout: 256 seconds) |
| 03:57:14 | * | Jesin quit (Quit: Leaving) |
| 04:07:04 | * | milosn quit (Read error: Connection reset by peer) |
| 04:07:08 | * | milosn_ joined #nim |
| 04:08:25 | * | BlaXpirit joined #nim |
| 04:08:45 | * | notfowl quit (Excess Flood) |
| 04:21:40 | * | TEttinger joined #nim |
| 04:25:58 | * | notfowl joined #nim |
| 04:26:52 | * | notfowl quit (Excess Flood) |
| 04:29:28 | * | notfowl joined #nim |
| 04:31:34 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 04:34:00 | * | pregressive quit (Remote host closed the connection) |
| 04:41:01 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 04:46:07 | * | vendethiel joined #nim |
| 04:52:25 | * | Varriount_ joined #nim |
| 04:55:07 | * | Varriount quit (Ping timeout: 244 seconds) |
| 05:04:02 | * | milosn_ is now known as milosn |
| 05:10:00 | * | yglukhov________ joined #nim |
| 05:12:52 | * | yglukhov________ quit (Client Quit) |
| 05:13:31 | * | vikaton quit (Quit: Connection closed for inactivity) |
| 05:27:34 | * | yglukhov________ joined #nim |
| 05:33:32 | * | yglukhov________ quit (Quit: Be back later ...) |
| 05:55:23 | * | jackv joined #nim |
| 06:00:55 | * | vendethiel quit (Ping timeout: 256 seconds) |
| 06:16:08 | * | solidsnack joined #nim |
| 06:16:10 | * | solidsnack left #nim ("Textual IRC Client: www.textualapp.com") |
| 06:16:31 | * | solidsnack joined #nim |
| 06:22:18 | * | strcmp1 quit (Ping timeout: 256 seconds) |
| 06:24:39 | * | ingsoc joined #nim |
| 06:25:39 | * | vendethiel joined #nim |
| 06:26:38 | * | strcmp1 joined #nim |
| 06:43:15 | * | yglukhov________ joined #nim |
| 06:48:31 | * | vendethiel quit (Ping timeout: 256 seconds) |
| 06:50:01 | * | gokr joined #nim |
| 06:58:38 | * | Ven joined #nim |
| 06:59:37 | * | kokozedman joined #nim |
| 07:08:05 | * | Ven quit (Read error: No route to host) |
| 07:08:35 | * | endragor_ joined #nim |
| 07:11:45 | * | endragor quit (Ping timeout: 256 seconds) |
| 07:12:44 | * | strcmp1 quit (Ping timeout: 245 seconds) |
| 07:21:21 | * | strcmp1 joined #nim |
| 07:26:05 | * | vendethiel joined #nim |
| 07:38:17 | * | bjz joined #nim |
| 07:41:58 | * | Ven joined #nim |
| 07:49:57 | * | vendethiel quit (Ping timeout: 265 seconds) |
| 07:59:47 | * | ddl_smurf joined #nim |
| 08:01:18 | * | OnO joined #nim |
| 08:03:57 | * | coffeepot joined #nim |
| 08:05:54 | * | Trustable joined #nim |
| 08:11:14 | * | solidsna_ joined #nim |
| 08:11:23 | * | solidsnack quit (Read error: Connection reset by peer) |
| 08:15:18 | * | endragor_ quit (Remote host closed the connection) |
| 08:15:47 | * | endragor joined #nim |
| 08:19:49 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 08:20:44 | * | solidsna_ quit (Ping timeout: 256 seconds) |
| 08:25:28 | * | yglukhov________ quit (Ping timeout: 255 seconds) |
| 08:26:04 | * | yglukhov________ joined #nim |
| 08:28:04 | * | dt__ joined #nim |
| 08:29:35 | * | dt__ left #nim (#nim) |
| 08:42:42 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 08:43:01 | * | bjz joined #nim |
| 08:51:52 | * | wb joined #nim |
| 08:59:52 | * | ddl_smurf joined #nim |
| 09:05:42 | * | TEttinger quit (Ping timeout: 276 seconds) |
| 09:07:32 | * | NemeXis joined #nim |
| 09:07:39 | * | NemeXis left #nim (#nim) |
| 09:13:30 | * | IronY joined #nim |
| 09:18:43 | * | polde quit (Read error: Connection reset by peer) |
| 09:20:35 | IronY | so |
| 09:20:38 | IronY | Lol |
| 09:20:45 | IronY | What would one build in nim |
| 09:20:50 | IronY | whats it primary niche? |
| 09:21:03 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 09:21:52 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 09:22:27 | * | polde joined #nim |
| 09:23:27 | * | bjz joined #nim |
| 09:23:29 | coffeepot | I'm only a neophyte so someone else might be able to answer better, but it's a systems language with high level syntax, so everything from kernels and games to web and scripting |
| 09:23:41 | IronY | yeah was looking at the git hub trending |
| 09:23:51 | IronY | nes emulator written in nim compiled to js |
| 09:24:03 | IronY | thats purty neat |
| 09:25:51 | coffeepot | I came to Nim because it's statically typed and compiled, but is more like python in it's high level approach. |
| 09:26:10 | coffeepot | also yeah compiling to javascript is nice |
| 09:28:56 | coffeepot | nim focuses on efficiency and expression with a clean syntax, so for me that is it's niche. |
| 09:31:47 | IronY | no thats fair enough |
| 09:32:05 | IronY | learning now |
| 09:32:14 | IronY | compiler and nimble installed |
| 09:32:26 | coffeepot | it's one of the most enjoyable languages I've ever used tbh :) |
| 09:32:43 | IronY | what did you do has a starter get to know the language project |
| 09:32:46 | ekarlso | too bad it doesn't get more attention :p |
| 09:33:41 | IronY | You need a flashy website and a podcast series for that ekarlso |
| 09:33:59 | IronY | and you have to throw out words, like elegant, and expressive |
| 09:34:14 | coffeepot | I started by writing a game that is gradually growing, but atm am trying write a higher level wrapper for sql server |
| 09:34:50 | IronY | 'metaprogramming' |
| 09:35:07 | IronY | the founder introduces it as ' a programming language he made in his spare time, because he can ' |
| 09:35:15 | IronY | thats something i can get behind lol |
| 09:35:22 | filwit | :) |
| 09:35:43 | filwit | we' |
| 09:35:46 | filwit | whoops... |
| 09:36:23 | coffeepot | imo it's fair enough to use "elegant, expressive and efficient" when describing nim, as despite sounding 'buzzwordy' it really describes the takeaway experience from using it |
| 09:37:01 | Araq | coffeepot: wow that's really nice. thank you. :-) |
| 09:37:46 | Araq | IronY: I'm preparing lots of material for oscon, which answers more of these questions. i hope. |
| 09:37:51 | coffeepot | Araq you're welcome, thanks for sticking to your principles and generating something that's made me love programming again! |
| 09:38:00 | IronY | Araq, is this you in the video I am watching |
| 09:38:05 | IronY | http://www.infoq.com/presentations/nimrod |
| 09:38:10 | Araq | yes |
| 09:38:19 | IronY | This is why I live irc. well done sir, well done |
| 09:39:31 | IronY | live = love that is |
| 09:39:51 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 09:42:47 | * | TEttinger joined #nim |
| 09:55:48 | * | bjz joined #nim |
| 10:03:25 | * | boopisaway is now known as boop |
| 10:08:16 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 10:10:18 | * | bjz joined #nim |
| 10:15:55 | * | bjz quit (Ping timeout: 256 seconds) |
| 10:36:51 | * | vendethiel joined #nim |
| 10:41:22 | kokozedman | IronY, from Madagascar here, building router applications with Nim... and best of all: it works, and efficient, and simple and expressive, and everything in between |
| 10:41:48 | kokozedman | OpenWrt platform based on uClibc |
| 10:41:59 | IronY | very very nice |
| 10:42:09 | IronY | closed source? |
| 10:42:37 | kokozedman | yes, closed unfortunately for the time being |
| 10:45:26 | IronY | how the hell does this compile down to javascript |
| 10:45:30 | IronY | like in the sense of the nes emulator |
| 10:46:01 | IronY | I just dont get how u get a low level static typed langauge to a javascript canvas |
| 10:48:14 | def- | IronY: Looked at the article? http://hookrace.net/blog/porting-nes-go-nim/ |
| 10:48:51 | IronY | LOL |
| 10:48:59 | IronY | well that was exactly what I was looking for |
| 10:49:06 | * | bjz joined #nim |
| 10:52:13 | flaviu | IronY: Keep in mind the NEW emulator uses emscripten |
| 10:52:30 | * | BlaXpirit joined #nim |
| 10:52:39 | flaviu | Nim also has it's own JS backend, but it's still experimental |
| 10:54:10 | * | vikaton joined #nim |
| 10:57:12 | def- | emscripten works pretty great, except Nim's GC doesn't seem to work (yet) |
| 10:58:43 | synthmeat | so, how would something like js2nim (like c2nim) work with either emscripten or some native js backend? |
| 10:59:15 | synthmeat | c2nim is quite useful tool |
| 11:00:48 | synthmeat | or, better question maybe - how would you use external js libraries in nim, with emscripten/native js backend? |
| 11:01:17 | def- | you can use importc as with the C backend |
| 11:01:24 | * | tmku quit (Ping timeout: 276 seconds) |
| 11:01:47 | def- | synthmeat: see here for example: http://hookrace.net/blog/what-is-special-about-nim/#compile-to-javascript |
| 11:02:00 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 11:04:05 | synthmeat | but no any sort of automatic wrapper? |
| 11:05:19 | coffeepot | I'm thinking of writing an API server for some functions at work that'll serve up JSON. Is Jester suitable for this or would I be better off just using httpserver? |
| 11:06:42 | coffeepot | I like the Jester way of doing things but wondering if it might be a bit of overkill for a simple server |
| 11:07:16 | coffeepot | also am thinking it's more orientated towards html and pages |
| 11:07:49 | * | tmku joined #nim |
| 11:10:22 | def- | synthmeat: haven't seen any js2nim |
| 11:10:27 | * | vendethiel joined #nim |
| 11:10:47 | def- | I think the JS backend still needs some love to work well |
| 11:12:20 | * | TEttinger quit (Quit: Leaving) |
| 11:12:33 | synthmeat | def-: any particulary glaring things that emscripten misses? |
| 11:28:52 | * | endragor_ joined #nim |
| 11:29:04 | * | endragor quit (Read error: Connection reset by peer) |
| 11:32:54 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 11:35:15 | * | banister quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 11:35:42 | * | dddddd joined #nim |
| 11:48:45 | * | OnO quit (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 11:49:11 | def- | synthmeat: I only noticed the GC, but haven't experimented much |
| 11:50:53 | * | Ven joined #nim |
| 12:00:07 | * | vendethiel joined #nim |
| 12:01:54 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 12:06:42 | * | Kingsquee quit (Quit: Konversation terminated!) |
| 12:09:45 | * | banister joined #nim |
| 12:13:03 | * | Ven joined #nim |
| 12:17:44 | * | banister quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 12:21:21 | * | BitPuffin|osx quit (Ping timeout: 276 seconds) |
| 12:24:11 | * | TEttinger joined #nim |
| 12:24:58 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 12:36:34 | * | milosn quit (Quit: leaving) |
| 12:39:03 | Araq | more opinions please: https://github.com/Araq/Nim/pull/2700 |
| 12:42:35 | TEttinger | I think california's almond farmers should be taxed for their heavy water usage |
| 12:42:40 | TEttinger | wrong kind of opinion? |
| 12:52:13 | Araq | heavy water is delicious |
| 12:55:25 | Araq | but also expensive |
| 12:55:29 | synthmeat | yeah, ```toUTF8()``` and ```validateUtf8()``` within the same file looks funky |
| 12:55:53 | Araq | so they shouldn't pay a tax |
| 12:56:06 | synthmeat | i just assumed nim-way is to uppercase only the start of the word, even if it's an acronym |
| 12:56:30 | strcmp1 | Araq, all governments should eliminate taxes and fund themselves through state-owned businesses :p |
| 12:56:35 | Araq | synthmeat: yeah I added this rule to our style guide |
| 12:57:53 | * | boop is now known as boopisaway |
| 12:58:24 | synthmeat | sweet |
| 13:08:23 | * | vendethiel joined #nim |
| 13:08:50 | * | intra joined #nim |
| 13:22:32 | * | derkirche joined #nim |
| 13:22:36 | * | derkirche left #nim (#nim) |
| 13:40:14 | * | phira quit (Ping timeout: 245 seconds) |
| 13:45:28 | * | phira joined #nim |
| 13:45:29 | * | phira quit (Excess Flood) |
| 13:45:58 | * | phira joined #nim |
| 13:46:00 | * | phira quit (Excess Flood) |
| 13:46:27 | * | phira joined #nim |
| 13:46:30 | * | phira quit (Excess Flood) |
| 13:46:57 | * | phira joined #nim |
| 13:46:58 | * | darkf_ joined #nim |
| 13:46:58 | * | darkf quit (Disconnected by services) |
| 13:47:00 | * | phira quit (Excess Flood) |
| 13:47:05 | * | darkf_ is now known as darkf |
| 13:47:26 | * | phira joined #nim |
| 13:47:29 | * | phira quit (Excess Flood) |
| 13:48:01 | * | phira joined #nim |
| 13:48:03 | * | phira quit (Excess Flood) |
| 13:48:27 | * | phira joined #nim |
| 13:52:47 | * | BitPuffin joined #nim |
| 13:59:32 | * | gsingh93 joined #nim |
| 14:00:28 | * | pregressive joined #nim |
| 14:00:28 | * | pregressive quit (Client Quit) |
| 14:01:16 | * | pregressive joined #nim |
| 14:05:41 | * | Strikecarl joined #nim |
| 14:25:04 | vikaton | Nim doesnt have % ? |
| 14:25:08 | vikaton | its only mod? |
| 14:26:22 | def- | vikaton: right, similar to add/&&, or/||, etc |
| 14:26:59 | def- | There is %% for unsigned modulo: http://nim-lang.org/docs/system.html#%%,IntMax32,IntMax32 |
| 14:27:26 | * | endragor_ quit (Ping timeout: 276 seconds) |
| 14:27:31 | vikaton | Is it possible to alias mod for % ? |
| 14:28:27 | def- | template `%`(x, y): expr = x mod y |
| 14:37:36 | vikaton | oh niiice |
| 14:38:23 | vikaton | are templates expensive? |
| 14:38:58 | coffeepot | afaik templates are just advanced inlining? |
| 14:39:40 | * | yglukhov________ is now known as yglukhov |
| 14:40:15 | * | yglukhov quit (Quit: Lingo: www.lingoirc.com) |
| 14:40:30 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 14:40:35 | * | yglukhov joined #nim |
| 14:40:56 | Araq | vikaton: no runtime overhead, it's just a macro |
| 14:41:39 | coffeepot | more info http://nim-lang.org/docs/manual.html#templates |
| 14:43:48 | coffeepot | (so, not just advanced inlining ;) ) |
| 14:44:11 | def- | In this case it simply replaces any invocation of `%` with mod at compile time, that's all |
| 14:45:06 | * | OnO joined #nim |
| 14:49:46 | * | OnO quit (Client Quit) |
| 14:50:42 | vikaton | Coool |
| 14:52:00 | * | darkf quit (Quit: Leaving) |
| 14:53:37 | vikaton | equivalent of "(0..1000).select { |x| (x % 3 == 0) || (x % 5 == 0) }.sum" in Nim? |
| 14:53:47 | vikaton | .select is kind of like.filter in Rust |
| 14:55:37 | def- | vikaton: you want a functional version or imperative? |
| 14:56:03 | vikaton | Both would be nice, though I'll go with functional |
| 14:56:09 | vikaton | Just Funtional actually |
| 14:58:39 | * | Strikecarl quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 15:00:10 | def- | vikaton: https://gist.github.com/def-/dd15da453001af9ce7a1 |
| 15:00:57 | vikaton | thanks def- |
| 15:01:03 | def- | the imperative is much more performant, no heap/GC allocations etc |
| 15:01:38 | def- | if my iterutils started working again they would work instead of sequtils as well |
| 15:02:15 | vikaton | I thought NIm had '|' |
| 15:02:35 | def- | what's that? |
| 15:02:54 | vikaton | Like in python, I or C++'s II |
| 15:02:57 | vikaton | ||* |
| 15:03:02 | vikaton | |* |
| 15:03:07 | def- | nope, just "or" |
| 15:03:26 | def- | ah, you can use | at type level |
| 15:03:44 | def- | if your proc accepts "int8 or uint8" you can also write "int8 | uint8" |
| 15:05:26 | vikaton | def, if I use templates on your example like template `|`(x, y): expr = x or y |
| 15:05:45 | vikaton | I would get a type mismatch error of (bool, intliteral) etc |
| 15:06:02 | def- | yes, you would have to write (XXX) | (YYY) i assume |
| 15:06:06 | def- | with brackets |
| 15:06:11 | vikaton | o |
| 15:06:33 | def- | I would recommend to get used to Nim's or/and/mod instead |
| 15:07:10 | vikaton | hmm |
| 15:07:34 | vikaton | Araq, have you ever told Github to chnage Nimrod to NIm ? |
| 15:08:19 | federico3 | vikaton: yes |
| 15:08:34 | def- | vikaton: They can't rename it for internal reasons, but it will eventually be fixed: https://github.com/github/linguist/pull/1936 |
| 15:09:11 | Araq | vikaton: I'm pretty sure I didn't. but others did. |
| 15:10:29 | vikaton | ah Ok |
| 15:11:01 | * | yglukhov quit (Ping timeout: 258 seconds) |
| 15:17:02 | def- | vikaton: oh, and you can write the functions the other way around in Nim: https://gist.github.com/def-/dd15da453001af9ce7a1#file-foo-nim-L13 |
| 15:18:18 | vikaton | oh nicee |
| 15:19:42 | * | milosn joined #nim |
| 15:19:54 | coffeepot | also you don't need to use brackets as def- shows, so you can write: echo "stuff", "stuff".echo or echo("stuff) |
| 15:20:23 | coffeepot | absolutely love this feature of Nim |
| 15:20:48 | * | drewsrem joined #nim |
| 15:21:08 | * | the9to5 joined #nim |
| 15:21:46 | def- | coffeepot: actually that's one of the common criticisms of Nim, but I agree that it's nice when you use it to increase readability |
| 15:22:33 | coffeepot | yeah I see it criticised by every comment I've seen personally are "I haven't used Nim but this puts me off". |
| 15:22:37 | drewsrem | I'm trying to get a simple async-example working where two async-procs simultaneously output characters to stdout (one faster, one slower), however, it seems that it's not working. Maybe if someone would be so kind and have a quick look: http://ix.io/iEF |
| 15:22:58 | coffeepot | in practice once you know about UCS it all flows, for me at least |
| 15:24:13 | def- | drewsrem: what's the expected output and what does it do? |
| 15:25:02 | drewsrem | def-, basically the async part of main should output .........#.........# |
| 15:25:28 | drewsrem | Instead it outputs: .#.#.#.#.#.#.#.# ... |
| 15:26:02 | drewsrem | i.e. the async-proc that writes . sleepAsync's shorter then the one for # but they both seem to wait for the same time |
| 15:27:04 | drewsrem | So it seems that both procs run simultaneously, but they sleepAsync for the same time, tho one is written to sleep 1/10 of the other |
| 15:29:14 | drewsrem | When I let them sleepAsync for much longer it seems to work. - Almost seems that it's impossible to sleepAsync below a whole second? |
| 15:30:42 | dom96 | try using while true: pool(1) instead of runForever() |
| 15:30:45 | dom96 | drewsrem: ^ |
| 15:30:57 | dom96 | s/pool/poll/ |
| 15:31:04 | dom96 | The default timeout for poll is 500ms |
| 15:31:21 | drewsrem | That outputs ".#" and then stops |
| 15:32:36 | drewsrem | ah |
| 15:32:37 | drewsrem | sorry |
| 15:32:39 | drewsrem | I've misread |
| 15:33:08 | dom96 | you shouldn't discard futures btw |
| 15:35:15 | dom96 | also, fast_fill_async and slow_fill_async won't run until fast_fill and slow_fill are finished. |
| 15:35:37 | dom96 | async does not create multiple threads |
| 15:35:56 | def- | while true: poll(1) looks good |
| 15:36:23 | coffeepot | is async timeslicing? |
| 15:36:31 | drewsrem | dom96, right I just intended to notice the different rates at which they output |
| 15:36:56 | drewsrem | dom96, thanks, that worked perfectly |
| 15:37:04 | dom96 | Good :) |
| 15:37:10 | drewsrem | Why shouldn't I discard futures? |
| 15:37:30 | def- | drewsrem: http://nim-lang.org/docs/asyncdispatch.html#asyncdispatch-discarding-futures |
| 15:37:46 | drewsrem | def-, thanks, should've read more carefully |
| 15:41:15 | drewsrem | On a related note, I tried to create a short template that would shorthand writing "await sleepAsync" expecting something like C-macros but got bit because "await" apparently only works in async-pragma procs?: http://ix.io/iEK |
| 15:41:40 | drewsrem | I guess I'd have to look into macros? |
| 15:43:40 | Araq | async is a rather heavy transformation, no idea how you think you can 'await' to work without it |
| 15:44:54 | drewsrem | Araq, my goal was to just abbreviate having to write "await sleepAsync" everytime with something shorthand |
| 15:45:21 | drewsrem | Was just curious tho, it's not an actual issue |
| 15:45:30 | Araq | ah, the old "async" needs to be able to see the 'await' problem |
| 15:45:56 | dom96 | drewsrem: I would suggest creating a proc for that. Something like proc slp(time: int): Future[void] = sleepAsync(time) |
| 15:45:56 | dom96 | , you will still need to write the 'await' though. |
| 15:45:57 | Araq | yeah we'll get rid of that one. eventually. |
| 15:46:18 | dom96 | or you can write 'yield' instead of 'await' in your template, but that's hackish. |
| 15:46:38 | dom96 | Async templates here we come :P |
| 15:46:39 | drewsrem | thanks for the response, the codebase is so small, I might just sed-replace it for now |
| 15:52:32 | * | Arrrrrr joined #nim |
| 15:55:12 | * | polde quit (Ping timeout: 276 seconds) |
| 15:57:50 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 16:06:56 | * | Perelandric joined #nim |
| 16:09:06 | * | vendethiel joined #nim |
| 16:20:51 | vikaton | There's something weird with Nim's http server example |
| 16:21:00 | vikaton | it only reads |
| 16:21:39 | vikaton | how Can I change it so? |
| 16:21:49 | * | fizzbooze joined #nim |
| 16:28:02 | Arrrrrr | What do you mean by "it only reads", reads what |
| 16:33:12 | * | coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 16:33:39 | vikaton | for example |
| 16:33:43 | vikaton | here lemme gist |
| 16:35:47 | * | nimster joined #nim |
| 16:38:02 | vikaton | Arrrrrr: https://gist.github.com/Vikaton/d11d27d98a7090336256 |
| 16:38:59 | Arrrrrr | It sould return hello world you mean |
| 16:39:20 | vikaton | it does in the browser |
| 16:39:50 | vikaton | but wrk doesnt function properly with it, like it does with any other language |
| 16:39:55 | * | boopisaway is now known as boop |
| 16:47:48 | drewsrem | Is it possible to read the value of the Future in the Futures callback anon-proc ? |
| 16:48:26 | drewsrem | Ah, it clearly is |
| 16:49:34 | * | fizzbooze quit (Ping timeout: 272 seconds) |
| 16:56:42 | vikaton | any solution? |
| 16:56:49 | * | vendethiel quit (Ping timeout: 258 seconds) |
| 16:56:50 | def- | vikaton: works with the asynchttpserver |
| 16:57:03 | def- | http://nim-lang.org/docs/asynchttpserver.html |
| 16:57:52 | def- | Or at least I thought so |
| 16:58:10 | def- | but not sure why the old httpserver is broken |
| 16:58:53 | * | vendethiel joined #nim |
| 17:00:10 | vikaton | Well it works |
| 17:00:53 | vikaton | nim asynchttpserver performs the same as Crystal, and beats Rust's Hyper in hello world micro benchmark |
| 17:01:03 | vikaton | fyi, nothing meaningfull as always |
| 17:01:13 | * | ingsoc1 joined #nim |
| 17:01:19 | def- | Not meaningful, but good to hear: https://github.com/def-/nim-http-speedup |
| 17:01:30 | * | gsingh93_ joined #nim |
| 17:02:53 | * | ingsoc quit (Ping timeout: 265 seconds) |
| 17:04:45 | * | leru joined #nim |
| 17:05:21 | def- | ok, the problem is that httpserver implements http 1.1 wrongly and doesn't keep the connection alive |
| 17:05:56 | * | leru quit (Client Quit) |
| 17:06:01 | ekarlso | vikaton: Crystal ? |
| 17:06:03 | * | leru joined #nim |
| 17:06:03 | * | nimster quit (Quit: Page closed) |
| 17:06:21 | ldlework | The language everyone is jumping the Nim ship for. |
| 17:06:23 | vikaton | ekarlso: http://crystal-lang.org |
| 17:06:53 | vikaton | ldlework: Are you sure? I think many people use both of them as the same time |
| 17:06:59 | vikaton | those who use both anyway |
| 17:07:12 | ldlework | just trolling |
| 17:07:23 | ldlework | too tired to see it through |
| 17:08:12 | def- | in the httpserver.nim there are some comments about "# XXX we ignore "HTTP/1.1" etc. for now here" |
| 17:08:16 | def- | I guess that's the culprit |
| 17:12:25 | * | yglukhov_ joined #nim |
| 17:14:55 | vikaton | Whats the difference between templates and macros in Nim? |
| 17:16:34 | * | strcmp1 quit (Quit: Leaving) |
| 17:17:09 | ldlework | vikaton: templates are lexical, macros are procs that take and return AST. |
| 17:17:32 | ldlework | You can implement any template as a macro. |
| 17:17:41 | ldlework | But you do all the work yourself. |
| 17:18:11 | vikaton | I see |
| 17:21:29 | * | vendethiel quit (Ping timeout: 256 seconds) |
| 17:27:00 | * | ingsoc1 quit (Quit: Leaving.) |
| 17:27:08 | * | ingsoc joined #nim |
| 17:30:05 | * | strcmp1 joined #nim |
| 17:30:24 | * | vendethiel joined #nim |
| 17:55:08 | * | OnO joined #nim |
| 18:01:13 | * | brson joined #nim |
| 18:01:29 | * | kokozedman_ joined #nim |
| 18:04:27 | * | kokozedman quit (Ping timeout: 250 seconds) |
| 18:05:57 | * | OnO quit (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 18:07:06 | * | OnO joined #nim |
| 18:09:59 | * | BitPuffin quit (Ping timeout: 246 seconds) |
| 18:31:53 | * | Jesin joined #nim |
| 18:40:22 | * | skyfex____ joined #nim |
| 18:41:36 | * | brson_ joined #nim |
| 18:42:25 | * | brson quit (Ping timeout: 264 seconds) |
| 18:42:56 | * | skyfex___ quit (Ping timeout: 265 seconds) |
| 18:44:02 | * | brson_ quit (Client Quit) |
| 18:44:16 | * | brson joined #nim |
| 18:56:57 | * | Jesin quit (Ping timeout: 265 seconds) |
| 19:11:13 | * | xender left #nim ("WeeChat 1.0") |
| 19:26:17 | * | ChrisMAN quit (Remote host closed the connection) |
| 19:26:36 | * | Jesin joined #nim |
| 19:40:27 | * | ChrisMAN joined #nim |
| 19:41:47 | * | Arrrrrr quit (Quit: Page closed) |
| 19:50:44 | * | ingsoc1 joined #nim |
| 19:50:54 | kokozedman_ | How again do I create a TThread that takes no argument? TThread[] is invalid |
| 19:51:16 | * | ingsoc quit (Ping timeout: 255 seconds) |
| 19:54:34 | Araq | kokozedman_: TThread[void] |
| 19:54:54 | kokozedman_ | Araq, thanks |
| 19:55:38 | kokozedman_ | Araq, by the way, about the thread channel, has it been overhauled yet? last time I was told it needed some update for performance |
| 19:57:08 | Araq | no, but I did some tests and on my machine thread+channel is on par with 'spawn' with all its compiler magic |
| 19:57:23 | Araq | so it's not that bad |
| 19:59:17 | * | BlaXpirit quit (Remote host closed the connection) |
| 20:01:08 | * | gsingh93 quit (Ping timeout: 256 seconds) |
| 20:01:09 | * | gsingh93_ is now known as gsingh93 |
| 20:01:11 | * | BlaXpirit joined #nim |
| 20:19:02 | * | xender joined #nim |
| 20:19:36 | xender | Does Nim have namespaces? |
| 20:20:02 | xender | If so, is it possible to disable automatic namespace polluting on import? |
| 20:20:08 | def- | xender: every module is in its namespace |
| 20:20:16 | def- | yes, use from module import nil |
| 20:20:31 | ldlework | What does that do |
| 20:20:40 | xender | In Python, to pollute my namespace, I have to do "from foo import *" instead of "import foo". In C++, i have to explicitely write "using namespace bar". |
| 20:20:54 | Araq | in Nim you write from foo import nil |
| 20:21:05 | xender | def-, Araq: Oh, okay... That seems strange, but if it's the only way... |
| 20:21:07 | def- | xender: in Nim the opposite is the default, but you're not forced to use it |
| 20:21:16 | ldlework | Does that make ufcs a bit strange? |
| 20:21:25 | xender | Hm, why is it really the default? |
| 20:21:27 | ldlework | (or impossible?) |
| 20:21:29 | def- | ldlework: indeed, operators also don't really work then |
| 20:21:36 | xender | It looks like a regression to C cavemen times |
| 20:21:41 | * | ldlework hugs Nim |
| 20:21:58 | Varriount_ | Araq: "I won't use my dictatorship superpowers, so vote away" |
| 20:22:03 | * | Varriount_ is now known as Varriount |
| 20:22:15 | * | leru quit (Quit: Nettalk6 - www.ntalk.de) |
| 20:22:16 | Araq | xender: use from foo import nil. you'll eventually learn why it's stupid and not the default. |
| 20:22:54 | Araq | but for now: BE AFRAID. |
| 20:22:59 | ldlework | xender: 'methods' are not really methods in Nim. When you import T you get none of the functions that work with T. |
| 20:23:17 | ldlework | xender: so if you have to go through the module namespace, you can't do T.foo() |
| 20:23:30 | ldlework | You'd have to do, M.foo(T) |
| 20:23:32 | ldlework | or whatever |
| 20:23:48 | ldlework | I guess, 't' to indicate an instance of T |
| 20:23:51 | def- | and even if you just do "import strutils", you can still use strutils.toLower |
| 20:24:06 | xender | ldlework: Ouch. So, Nim looked like a nice language for me, but that design flaw seems to completely undermine that position :( |
| 20:24:09 | ldlework | You'll just clobber any other toLower |
| 20:24:15 | dom96 | That is a pity. |
| 20:24:26 | ldlework | xender: I too wrestle with swallowing it. |
| 20:24:33 | dom96 | Perhaps it's time to discuss introducing 'use module' to be equivalent to 'from module import nil' |
| 20:24:36 | ldlework | But not quite enough to undermine my interest. |
| 20:24:40 | dom96 | but with the added bonus that it works with UFCS |
| 20:25:03 | ldlework | dom96: its that last part that is the source of all the trouble isn't it? |
| 20:25:07 | dom96 | then everyone will be happy, right? |
| 20:25:17 | ldlework | If the last part wasn't a problem, I don't think xender would have a problem typing "from foo import nil" |
| 20:25:38 | dom96 | I think that typing 'from foo import nil' would still become annoying. |
| 20:25:42 | def- | dom96: no, then they will want the colon after if/for removed, tabs instead of spaces, full case-sensitivity, etc |
| 20:25:52 | ldlework | dom96: Sure but the actual limitation is ufcs/divorced methods |
| 20:26:06 | ldlework | how you import just a module name is aesthetics |
| 20:26:20 | Araq | xender: please don't listen to #nim. try the language out anyway. |
| 20:26:37 | ldlework | Araq: no one asked him otherwise |
| 20:26:42 | dom96 | def-: People already want those things. |
| 20:26:43 | Araq | contrary to what people seem to believe 'from foo import nil' does exist and works |
| 20:26:53 | xender | ldlework: Well, I was looking for a language that will allow me to write code that is 1. clean 2. portable. And as for cleanness, Nim looks worse than Python for me, but being compilable to JS beats it. But those namespaces are too much for me. |
| 20:27:02 | ldlework | Araq: except now operators and ufcs is broken? |
| 20:27:07 | xender | Araq: What about methods then? |
| 20:27:12 | Araq | ldlework: why is it broken? |
| 20:27:24 | Araq | you want explicit module.foo syntax, you get it. |
| 20:27:31 | ldlework | Araq: from foo import nil; var t = foo.T(); |
| 20:27:35 | ldlework | How do I call a method on t? |
| 20:27:38 | ldlework | using ufcs? |
| 20:27:49 | dom96 | xender: Nothing stops you from writing module.foo instead of foo everywhere. |
| 20:27:50 | Araq | you cannot but why it that a problem? |
| 20:27:57 | ldlework | Araq: seriously, be real. |
| 20:28:03 | xender | ldlework++ |
| 20:28:05 | Araq | I'm real. |
| 20:28:09 | ldlework | No one discouraged him from using the language. |
| 20:28:13 | ldlework | Yet you act like we did. |
| 20:28:14 | * | kokozedman_ quit (Ping timeout: 246 seconds) |
| 20:28:32 | ldlework | And now you're pretending that a feature of your languae doesn't break when you use another feature of the language. |
| 20:28:47 | xender | Hm, can nazi namespace chacking be performed with some preprocessing layer? |
| 20:29:06 | dom96 | Nazi? Let's not start calling things that please. |
| 20:29:12 | Araq | ldlework: it's not broken. |
| 20:29:21 | Araq | it does what you asked it to do. |
| 20:29:23 | ldlework | Araq: "ceases to work in the same way as if you didn't use the other feature" |
| 20:29:45 | ldlework | C# would be sad. |
| 20:29:47 | dom96 | Araq: I think ldlework wants something that is not quite as strict. |
| 20:29:57 | Araq | if you want module.foo, how is writing module.foo "broken"? |
| 20:30:02 | ldlework | No, I just don't want us to lie to people about Nim's limitations. |
| 20:30:03 | dom96 | Araq: Something in between import foo and from foo import nil. |
| 20:30:09 | def- | dom96: i think that sounds like a reasonable compromise |
| 20:30:12 | ldlework | People invest actual time, of their finite lives. |
| 20:30:31 | ldlework | I don't care that it works the way it currently does. Like I said this problem doesn't entirely undermine my enjoyment of Nim. |
| 20:30:47 | ldlework | It just makes it have a corner that can never be rounded. |
| 20:30:49 | dom96 | def-: no ufcs when using 'from foo import nil'? |
| 20:31:02 | xender | Yeah, I was thinking about making a game in Nim, but if that means I have to write unclean code, I'd be better going back to my modular origami... |
| 20:31:18 | def- | dom96: no, that method call syntax still works with a "use module" |
| 20:31:34 | dom96 | def-: ahh, so you think my idea has some merit? |
| 20:31:40 | def- | right |
| 20:31:45 | ldlework | If you can make it work with "use module" then it doesn't matter what syntax you slap over it. |
| 20:31:50 | dom96 | Cool. Time for an RFC then. |
| 20:32:00 | ldlework | I thought the underlying problem is technically challenging? |
| 20:32:04 | def- | xender: how do you have to write unclean code? I'd say it's just not enforced that you write clean code (depending on your definition of clean) |
| 20:32:24 | ldlework | def-: I think he means inconsistent |
| 20:32:44 | ldlework | ufcs in any module not doing a nil import, namespace referencing in those that do |
| 20:32:47 | dom96 | ldlework: In that case Araq will have an excuse to refuse the RFC. |
| 20:32:51 | ldlework | And having to remember this |
| 20:33:05 | ldlework | dom96: oh I thought the technically difficulty was already established in previous discussions, sorry |
| 20:33:09 | ldlework | technical* |
| 20:33:21 | dom96 | ldlework: Perhaps it was. I was most likely missing during them. |
| 20:33:23 | ldlework | I might be misconstruing fixpoint iteration during compilation |
| 20:33:32 | xender | def-: Okay, you're right, it's more a matter of not being enforced to write clean code. But i want such an enforcement when it comes to namespacing, unless I explicitely tell that I want to have a symbol from other namespace imported directly into current one. |
| 20:33:51 | ldlework | xender: that is kind of the point of namespacing amirite? |
| 20:34:16 | ldlework | xender: your ide will solve this problem |
| 20:34:30 | dom96 | xender: would you still use Nim if you knew that there was an option not to enforce namespacing? |
| 20:34:31 | xender | ldlework: I don't use and IDE. |
| 20:34:45 | dom96 | xender: but if there was also the opposite option (what I am proposing with 'use module')? |
| 20:34:46 | * | yglukhov_ quit (Quit: Be back later ...) |
| 20:37:34 | flaviu | dom96: I think that there are actual important problems that need to be solved. |
| 20:37:41 | * | Matthias247 joined #nim |
| 20:38:02 | dom96 | flaviu: I agree. |
| 20:38:17 | dom96 | flaviu: Which is why Araq shouldn't implement this. |
| 20:38:22 | xender | dom96: I've not really started using Nim for real, but being both high-level compilable to JS is enchanting. What I want is an option to enable a namespacing mode when top-level identifiers must be qualified unless explicitely from...imported, but "methods" (UFCS as ldlework calls it) work as they should. |
| 20:38:26 | dom96 | flaviu: If somebody wants this badly enough they can implement this. |
| 20:38:50 | xender | dom96: I don't mind an option to disable namespacing, I just wouldn't be using such an option. |
| 20:39:02 | flaviu | xender: Like D does it? |
| 20:39:06 | dom96 | I know that sounds harsh, and I apologise, but Araq has been awesome at implementing many of people's wishes over the past few years. |
| 20:39:50 | dom96 | It's unfair that there are bugs which prevent people who actually are using Nim *right now* from putting Nim in production. |
| 20:40:27 | * | yglukhov_ joined #nim |
| 20:40:34 | def- | and this isn't the first time this feature has been asked for |
| 20:41:21 | ldlework | xender: I come from Python and wanted to use Nim for game programming as well. The biggest hurdle I had to overcome was the inability to have different types in different modules, refer to each other. |
| 20:41:45 | dom96 | There are far too many cases of people coming in here, asking for a feature, Araq finally implementing the feature they asked for and then they simply disappear. |
| 20:41:45 | ldlework | xender: so if you use a parent<->child relationship at all, in your design sensibilities, then you'll likely run into this limitation |
| 20:42:09 | synthmeat | hey, um, how about we that want to game dev with nim pool up? there's like 3 different glfw wrappers already :D |
| 20:42:16 | ldlework | xender: it can be overcome by moving types into the same module, but its annoying if you're super organized like I am. But again, not a reason to give up Nim entirely. |
| 20:42:42 | Araq | ldlework: plus I showed you an acceptable workaround. |
| 20:42:50 | ldlework | Araq: types.nim? |
| 20:42:57 | Araq | no. a real one. |
| 20:43:02 | ldlework | That seemed mostly acceptable, though gross to people I show it to |
| 20:43:09 | ldlework | Oh, I must have forgotten |
| 20:43:16 | xender | flaviu: I'm not familiar with how D does it... |
| 20:43:31 | Araq | type Forwarded = object of Foo |
| 20:43:43 | Araq | type Useit = object x: ref Forwarded |
| 20:43:50 | Araq | # later in some other module: |
| 20:44:02 | Araq | type RealOne = object of Forwarded |
| 20:44:14 | flaviu | xender: Neither am I, but my rough understanding is that they use different rules for symbol lookup in UFCS and standard calls. |
| 20:44:30 | ldlework | :3 |
| 20:44:41 | Araq | you need an object conversion then due to the subtyping |
| 20:44:44 | dom96 | xender: Well then let's write an RFC on Github asking for this feature. Araq can then officially state his opinions on it, if he likes it then that's great, somebody can implement it. |
| 20:44:54 | xender | ldlework: You mean that you if you want to have circular dependency of symbols in type definitions, you have to define both types in one block, right? |
| 20:44:55 | Araq | but that's a 1 line accessor |
| 20:44:57 | ldlework | Araq: I think types.nim is a bit easier to reason about. |
| 20:45:01 | ldlework | xender: yeah |
| 20:45:28 | ldlework | xender: the way I deal with it, is I put literally all the types of my program into a single module, but put their methods and such in separate modules. |
| 20:45:40 | ldlework | I then use a compiler flag to import types.nim implicitly everywhere |
| 20:45:43 | xender | ldlework: Hm, I think that maybe generics could help to work around it. And coming from Python, you should be already familiar with duck-typing, which is similar to generics. |
| 20:45:46 | ldlework | This problem mostly goes away then. |
| 20:45:50 | ldlework | xender: it doesn't. |
| 20:46:04 | xender | ldlework: It won't work even with generics? |
| 20:46:14 | Araq | ldlework: generics are a workaround too |
| 20:46:24 | ldlework | The problem is that using generics everywhere you need a single type is *more ugly* than any of the workarounds. |
| 20:46:34 | ldlework | It breaks the actual abstractions in the software you're trying to define and represent. |
| 20:46:38 | ldlework | Can't say I would ever do that. |
| 20:47:05 | Araq | you can also hide the type completely in a closure, depending on the concrete usage |
| 20:47:19 | ldlework | You have a bunch of code (IE, the generic types) that don't actually sovle anything related to the problem your software is trying to solve |
| 20:47:25 | ldlework | Just work around limitations of the language you're using |
| 20:47:26 | xender | ldlework: Yeah, you're right, but on the other hand, duck-typing in Python works in similar way, but because it's implicit, it doesn't stand out that much and doesn't look ugly. |
| 20:48:03 | ldlework | At least the types.nim way, the language is actually getting out of the way by the time you're writing *your* code. |
| 20:48:14 | * | ldlework shrugs. |
| 20:49:12 | * | yglukhov_ quit (Quit: Be back later ...) |
| 20:49:17 | ldlework | Actually |
| 20:49:23 | ldlework | Instead of fixed point iteration |
| 20:49:32 | ldlework | Why not just have the compiler scoop up all my defined types |
| 20:49:47 | ldlework | And then compile/parse/whatever them as if they were in a single block in some implicit types.nim |
| 20:49:56 | ldlework | And then effect them across my code the same way the flag does |
| 20:50:02 | ldlework | tada? |
| 20:50:19 | Araq | ldlework: works when you ignore the fact that macros can generate types |
| 20:50:22 | ldlework | Maybe the dollar tag on this feature goes down? |
| 20:50:24 | ldlework | fuck. |
| 20:50:32 | ldlework | Araq: hehe ok |
| 20:51:06 | Araq | but it does work |
| 20:51:09 | ldlework | I guess in that case, you still have all types available in all modules. |
| 20:51:13 | Araq | and is an acceptable tradeoff |
| 20:51:14 | ldlework | But that's a very tiny price to pay I guess |
| 20:51:35 | ldlework | It *would* allow me to reuse all the design experience from Python |
| 20:51:47 | ldlework | And not introduce a third or fourth type where I'm used to just having a recursive relation. |
| 20:51:54 | Araq | in fact, I like the idea and will sleep over it |
| 20:52:09 | * | ldlework notices hair on his arm standing straight. |
| 20:53:06 | Araq | "yeah we fucked up that part of the language when it comes to macro interactions, but most langs have no macros, so there." |
| 20:53:12 | ldlework | haha |
| 20:53:42 | ldlework | Maybe a pragma for type generating macros :3 |
| 20:53:59 | ldlework | Or maybe the compiler should be able to detect macros that produce type definitions or some insane shit |
| 20:54:08 | ldlework | but maybe less "hard" than doing fixedpoint iteration |
| 20:54:43 | ldlework | I guess when it comes to macros detection of anything is a fool's errand. |
| 20:55:31 | ldlework | Araq: the macro consequence is verrrrrrrrry tiny |
| 20:55:47 | ldlework | And when do you care about recursive relationships across macros for /compiletime generated types/ anyway? |
| 20:55:55 | ldlework | across modules* |
| 20:56:05 | Araq | well almost right. |
| 20:56:16 | Araq | there is the famous 'class' macro ;-) |
| 20:56:24 | ldlework | hmm yeah |
| 20:56:27 | ldlework | ouchies. |
| 20:56:35 | ldlework | "welll alll my types are defined using macros!" |
| 20:56:46 | ldlework | I could see myself saying this in a few months |
| 20:57:35 | ldlework | xender: you should at least now see Nim as intellectually interesting enough that you shouldn't leave so hastily :) |
| 20:58:27 | xender | ldlework: I got lost halfway through above discussion :P |
| 20:58:33 | * | the9to5 quit () |
| 20:58:43 | ldlework | xender: I only pretend to know what I'm talking about. |
| 20:59:00 | xender | ldlework: I like going intelectual only when it makes sense to do so. :P |
| 21:00:16 | xender | ldlework: You know, you can have long and interesting discussion about everything, but they can be pointless anyway. :P |
| 21:04:11 | synthmeat | seriously though, let's make a game framework |
| 21:04:24 | synthmeat | get something up for LD in august |
| 21:04:31 | vikaton | wuts LD |
| 21:04:37 | synthmeat | ludum dare |
| 21:04:58 | vikaton | o |
| 21:06:24 | ldlework | synthmeat: if you wanna collaborate on a Nim LD I might be interested |
| 21:06:24 | ldlework | Maybe we can get notfowl on board too |
| 21:06:24 | synthmeat | i have a name and registered channel :P |
| 21:06:24 | dom96 | I can get on board too |
| 21:06:24 | dom96 | Love LD |
| 21:06:25 | synthmeat | "geronimo" was #2 choice, but loved "denim" |
| 21:06:41 | synthmeat | currently, def-'s there, and i just finished tutorial, part 1 |
| 21:06:43 | synthmeat | twice :D |
| 21:07:06 | vikaton | xender: if you want to propose a Language chnage, submit an issue :P |
| 21:07:08 | vikaton | chnage* |
| 21:07:18 | vikaton | s/chnage/change |
| 21:07:20 | Araq | https://wiki.haskell.org/Import just fyi. |
| 21:07:21 | vikaton | :[ |
| 21:07:39 | synthmeat | lurk in #denim if ya wanna, we'll get something up by next LD |
| 21:07:41 | Araq | Haskell does it like Nim, and I've yet to read that Haskell is a regression to C times. |
| 21:07:47 | def- | all i did so far was make nim-glfw statically compile the GLFW library so you don't need to have it installed |
| 21:07:47 | flaviu | https://github.com/Araq/Nim/pull/2762 |
| 21:08:10 | dom96 | synthmeat: If I'm honest I prefer geronimo |
| 21:08:15 | dom96 | mostly because Doctor Who. |
| 21:08:25 | def- | Araq: Haskell also has significant whitespace and still people always complain about Nim having it |
| 21:08:38 | synthmeat | dom96: yeah, me too, but there's apache project called geronimo, so uneccesary confusion |
| 21:09:10 | dom96 | synthmeat: Is this what you are planning on calling the LD game? |
| 21:09:22 | synthmeat | dom96: no, some "high" level game framework |
| 21:09:29 | ldlework | 'nimple' was the name of the game lib I'm creating |
| 21:09:36 | dom96 | synthmeat: ahh cool |
| 21:09:47 | dom96 | synthmeat: denim sounds good for that |
| 21:09:48 | synthmeat | i think def- and i are aligned on 2d as focus, for now |
| 21:10:55 | synthmeat | someone with opengl chops on board would come in handy |
| 21:11:15 | dom96 | Araq: Then again though, Haskell has no UFCS. |
| 21:11:51 | dom96 | synthmeat: Are you planning on using just opengl for everything? |
| 21:12:45 | synthmeat | dom96: not sure i understand the question. everything would be opengl (es, or webgl subset of es) hardware accelerated, yes |
| 21:13:06 | dom96 | synthmeat: I'm wondering if you will build on top of sdl or sfml. |
| 21:13:30 | Araq | dom96: not sure I see the point. Nim has no UFCS with 'from import' either. |
| 21:13:53 | dom96 | Araq: Yeah, and that is the problem. |
| 21:14:11 | synthmeat | dom96: def- suggested sdl2, but with potential of swapping the "backends" for rendering/audio/whatnot. so, in spirit of that, we'd start with glfw for start, since it's lightest to start, and we'd need to make it "swappable" at some later point anyways |
| 21:14:32 | dom96 | synthmeat: Sounds good. |
| 21:14:55 | def- | dom96: I think glfw makes sense because you don't need to install any dependencies: Get Nim + Nimble and you can immediately build stuff. SDL2 is heavier, but works on about every platform |
| 21:15:27 | synthmeat | glfw is so super sweet though |
| 21:15:27 | Araq | "Nim has this nice feature, UFCS, but unfortunately it doesn't work with from import. Haskell doesn't even have UFCS to begin with, so it's better." |
| 21:15:27 | vikaton | how does c2nim work? |
| 21:15:46 | dom96 | def-: cool. But won't you still need GLFW to static link it? |
| 21:15:55 | def- | dom96: nope: https://github.com/EXetoC/nim-glfw/blob/master/lib/glfw/wrapper.nim#L12-L52 |
| 21:16:19 | def- | I pulled in the glfw source code, similar to nre for pcre and go's glfw wrapper |
| 21:16:21 | dom96 | Araq: Yes, but xender/ldlework aren't saying that Haskell is better. |
| 21:16:38 | dom96 | def-: oh, I see. Wow. |
| 21:16:41 | Araq | dom96: but you implied it. |
| 21:16:48 | xender | I have not mentionned Haskell and I don't even know it o_O |
| 21:17:35 | ldlework | Yeah no comparative analysis was made :P |
| 21:17:43 | dom96 | Araq: Would it be challenging to implement my proposal? |
| 21:18:03 | Araq | it's the same old "having no legs is an advantage cause then they cannot be broken" argument from you, dom96. I prefer to walk though. |
| 21:19:19 | Araq | dom96: I don't understand your proposal. |
| 21:20:00 | Araq | In fact, I don't understand any proposal. you all seem to want 'from foo import nothing except this, that and that one over there' |
| 21:20:35 | Araq | and nobody has ever formalized this rule. |
| 21:21:52 | dom96 | Araq: https://gist.github.com/dom96/f2b00b31378a65b59842 |
| 21:22:35 | dom96 | err, small mistake on that last line. Corrected it. |
| 21:23:01 | ldlework | Araq: lol you're my favorite.... something |
| 21:23:18 | ldlework | pld maybe :) |
| 21:26:43 | Araq | so ... instead of a.f(b) gettting rewritten to f(a, b) it gets rewritten to module.f(a, b) ? |
| 21:27:28 | dom96 | if it's imported via 'use module' then yes. |
| 21:27:42 | Araq | that's completely different from the "type based" imports that were previously discussed |
| 21:28:02 | dom96 | Do you have a formal specification of those? |
| 21:28:09 | Araq | no. |
| 21:31:03 | Araq | dom96: the advantage of your proposal is that's much simpler then the previous ones. the disadvantage is that it doesn't address operators. |
| 21:31:48 | dom96 | I think people can live without operators. |
| 21:32:05 | flaviu | :O |
| 21:32:10 | dom96 | If they want to use them then they can just import them via from module import `[]` |
| 21:33:24 | dom96 | Actually, thinking about it some more, perhaps they should just be imported. |
| 21:33:36 | dom96 | The same way that they are when you use 'import module' |
| 21:33:51 | Araq | nah |
| 21:34:19 | Araq | from module import operators, ucfs |
| 21:34:34 | Araq | we need a fancy way of spelling this ofc |
| 21:35:47 | dom96 | hrm |
| 21:36:07 | dom96 | use module (with operators) vs. from module use nil (no operators) |
| 21:36:24 | vikaton | Why is Nim called Nim :) |
| 21:37:03 | Araq | from module import what_I_like |
| 21:37:03 | * | ingsoc1 quit (Ping timeout: 256 seconds) |
| 21:37:40 | Araq | vikaton: turned out the americans name their idiots after ancient kings |
| 21:38:09 | xender | vikaton: Because of an ancient game. Also, this makes it a PITA to search for Nim gamedev tutorials :> |
| 21:38:27 | vikaton | I see |
| 21:39:18 | vikaton | Thats hilarious @ Araq |
| 21:40:10 | dom96 | Araq: What do you think about my proposal though? |
| 21:41:39 | Araq | dom96: dunno. it suggests that method call syntax gives some additional namespace protections. but it doesn't. |
| 21:42:41 | Araq | so it's a "feeling good" feature which no connection to reality. |
| 21:42:45 | Araq | *with |
| 21:42:57 | dom96 | Perhaps. But on the other hand it would be easy to implement from what I can tell. |
| 21:44:20 | dom96 | It might be worth the good feelings. |
| 21:44:25 | Araq | so echo(a, b) is a bad namespace polution, but a.echo(b) is not? |
| 21:46:07 | flaviu | "UnpackNoneError" is a little awkward, anyone have any better ideas? |
| 21:46:34 | Araq | dom96: you're right. it seems rather easy to implement |
| 21:47:16 | dom96 | flaviu: OptionEmptyError |
| 21:47:27 | Araq | flaviu: UnpackError |
| 21:47:35 | dom96 | Araq's is better. |
| 21:47:52 | dom96 | Araq: Yeah. That does seem a little odd. |
| 21:48:01 | dom96 | Araq: Something to sleep over perhaps? |
| 21:49:20 | ekarlso | sleep, what's that dom96 :p |
| 21:49:45 | flaviu | How is `foo[bar]()` parsed? Isn't this an ambiguity in the grammar? |
| 21:49:49 | dom96 | ekarlso: Even Araq needs sleep every few months :P |
| 21:51:56 | Araq | flaviu: yes it is. fortunately "grammar ambiguity" is not a well defined problem so you can cheat easily. |
| 21:53:00 | flaviu | Araq: How is it not a well defined problem? two or more parse trees for the same input == grammar ambiguity. |
| 21:53:14 | flaviu | I can definitely see how cheating might work here though. |
| 21:53:15 | Araq | the parse trees are not well defined. |
| 21:53:22 | * | ingsoc joined #nim |
| 21:53:54 | Araq | you don't have to distinguish between "generic application" and "array access" |
| 21:54:07 | Araq | for nim it's just "nkBracketExpr" |
| 21:54:35 | flaviu | Ah, I see. |
| 21:54:40 | * | the9to5 joined #nim |
| 21:56:54 | federico3 | dom96: the Debian pkg requires a little updating but I'm currently on holidays for a month |
| 21:57:07 | dom96 | federico3: oh cool. You're here. |
| 21:57:29 | dom96 | federico3: I see. What about those security issues? |
| 21:57:38 | federico3 | On and off ;) |
| 22:01:09 | * | pregressive quit (Remote host closed the connection) |
| 22:05:35 | * | Trustable quit (Remote host closed the connection) |
| 22:05:39 | * | milosn quit (Quit: Reconnecting) |
| 22:05:48 | * | milosn joined #nim |
| 22:06:30 | * | gsingh93_ joined #nim |
| 22:10:27 | dom96 | Araq: Right, well, i'm going to create an issue for this on Github anyway. |
| 22:11:19 | Araq | I don't look at the list of issues without a filter. |
| 22:11:54 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 22:12:33 | federico3 | they are not urgent for the first release |
| 22:15:17 | dom96 | federico3: ok |
| 22:18:20 | * | the9to5 quit () |
| 22:18:58 | * | boop is now known as boopisaway |
| 22:21:27 | federico3 | dom96: regarding the security of csources, IIRC the contents of c_code changed compared with the previous release |
| 22:22:28 | dom96 | federico3: they change regularly. |
| 22:22:52 | * | the9to5 joined #nim |
| 22:23:10 | federico3 | all of them, it seems, not just the latest directory |
| 22:23:26 | * | Jesin quit (Quit: Leaving) |
| 22:23:47 | federico3 | ok, not a problem for the moment |
| 22:25:55 | * | gsingh93 quit (Quit: Connection closed for inactivity) |
| 22:25:58 | * | vbtt_ joined #nim |
| 22:25:58 | * | Jesin joined #nim |
| 22:26:01 | vbtt_ | hello |
| 22:26:58 | Araq | hi vbtt_ welcome back |
| 22:27:37 | vbtt_ | thanks. just saw an interesting discussion in the logs |
| 22:27:41 | vbtt_ | use, import etc. |
| 22:28:21 | vbtt_ | i'm not quite sure why the current system is broken or lacking |
| 22:30:38 | Varriount | vbtt_: My eyes tend to just glaze over when people start talking of such things. |
| 22:31:12 | vbtt_ | why? it's important but nim made a choice |
| 22:31:26 | * | vendethiel joined #nim |
| 22:31:34 | vbtt_ | i'm not sure what the argument against the choice is - are there real issues with import? |
| 22:31:51 | Varriount | vbtt_: I'm of the opinion that you're often better off trying to implement the change yourself, rather than persuading others to do it for you. |
| 22:31:55 | vbtt_ | I'm used to Python - imports are explicit and 'import *' is discouraged, but python does not overload, it overwrites |
| 22:32:17 | vbtt_ | Varriount:sure, but you need approval to be accepted |
| 22:42:24 | * | OnO quit (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 22:42:33 | * | BitPuffin|osx joined #nim |
| 22:44:16 | vbtt_ | instead of letting the importer specify what they want, why not let the exporter add tags to the symbols and let the importer specify which tags they want |
| 22:44:48 | Varriount | vbtt_: Can you clarify? |
| 22:44:55 | * | OnO joined #nim |
| 22:45:19 | * | OnO quit (Client Quit) |
| 22:45:24 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 22:45:24 | vbtt_ | let me preface with saying the current system is probalby fine, i'm just throwing out more suggestions tthat might be useful |
| 22:46:33 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 22:47:28 | vbtt_ | e.g. https://gist.github.com/anonymous/1ee1957c021c86cdc355 |
| 22:47:52 | vbtt_ | another option is to use compile time predicate functions to specify what to import |
| 22:48:18 | vbtt_ | from module_m import matching my_predicate_function |
| 22:48:21 | Araq | vbtt_: yeah I had that idea too. a macro to influence the import mechanism |
| 22:48:30 | vbtt_ | from module_m import matching is_operator |
| 22:48:59 | vbtt_ | that can subsume type based import (if I understand what they mean.. import all functions that apply on type X) |
| 22:49:49 | vbtt_ | since you already have a compiler vm, using matching functions gives most flexibility IMO, assuming it can be done |
| 22:50:08 | vbtt_ | .procs are compile time objects too, I'm assuming |
| 22:50:21 | notfowl | fwiw the import system works fine for me |
| 22:50:31 | * | brson quit (Quit: leaving) |
| 22:52:05 | vbtt_ | also, having matching functions means any arbitrary users's specific requirements for the import feature can be just implemented by a matching function. |
| 22:52:39 | vbtt_ | anyway, just wanted to mention the idea. |
| 22:52:54 | vbtt_ | Araq:interesting - did you decide for/against the macro? |
| 22:56:31 | gokr | One valid issue AFAICT is that its hard to import a "complete type". If you do oop style programming, then you typically want to import a "class", but there is no such concept today. |
| 22:57:11 | gokr | So either you import * from that module, or you will have to pick each and every method/proc - as far as I understand it. |
| 22:57:36 | gokr | But of course * goes a long way in practice. |
| 22:57:55 | vbtt_ | right, if you can have predicates, you could do `from m import matching for_type(m.T)` |
| 22:58:00 | vbtt_ | is * really that bad? |
| 22:58:07 | gokr | I don't think so |
| 22:58:09 | vbtt_ | because it's automatically overloaded locally? |
| 22:58:29 | gokr | But others are more disturbed by it - but not sure if thats rooted in practice or in theory :) |
| 22:58:34 | def- | vbtt_: i think the argument is that in big projects with many imports and many people working on it, it may be difficult to figure out where a proc came from |
| 23:00:05 | vbtt_ | I used to think * is bad, specially because of my python history |
| 23:00:18 | vbtt_ | but I think it's probalby ok for nim. |
| 23:00:31 | vbtt_ | def-:that's an issue for tools to sovle |
| 23:00:43 | vbtt_ | tools can be very accurate here |
| 23:01:32 | def- | yep, nimsuggest and ntags: https://bitbucket.org/behrends/ntags |
| 23:01:36 | dom96 | ooh, first time ever a post in r/nim made it to my reddit front page |
| 23:13:39 | onionhammer | hm weird. nim is sigsegving while compiling parseutils |
| 23:15:27 | Araq | onionhammer: OOM? |
| 23:16:13 | onionhammer | Araq i probably screwed something up |
| 23:16:40 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 23:16:50 | Araq | vbtt_: afaict the people with the most Nim code are the ones that are least concerned about how Nim's import works. |
| 23:18:22 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 23:18:59 | ldlework | This is like Golang and generics. |
| 23:19:03 | ldlework | Same form. |
| 23:19:29 | Araq | this is like the strong spaces discussion. everybody agreed it's a bad idea and will lead to bugs. and the one guy who actually used the feature reported "the compiler is too picky then". |
| 23:20:10 | Araq | which is the opposite of "leads to bugs" |
| 23:20:59 | Araq | ldlework: it has nothing to do with go and generics, but I know that's your favrourite example to back up whatever point you're trying to bring up. |
| 23:21:25 | ldlework | Little effort is required to see that you are making the same argument that Go programmers make for generics. |
| 23:21:34 | Araq | disagreeing with you means it's like Golang's design. |
| 23:21:39 | ldlework | If only I would write more go |
| 23:21:45 | ldlework | I would see I don't need a generics system |
| 23:22:00 | ldlework | Neither of these arguments are mine |
| 23:22:07 | ldlework | Their yours and Go users, and they are of the same form. |
| 23:24:54 | Araq | even if that would be true, it's completely irrelevant. "News: We added a different import mechanism in order to not be like Golang or people who argue for Golang." |
| 23:26:06 | ldlework | speaking of irrelevant, my point has nothing to do with golang's import system |
| 23:26:10 | def- | Araq: I think what ldlework is trying to say is just that the people who use a language often get used to its pecularities |
| 23:26:24 | ldlework | yes |
| 23:26:32 | ldlework | say what you mean "oh you'll get used to it." |
| 23:26:37 | ldlework | this isn't a technical defense of the import system |
| 23:27:21 | ldlework | not that I'm demanding one, I was merely responding to the form of your statement |
| 23:28:20 | ldlework | Golang programmers might be used to not having generics, but it doesn't change the objective universe where generics make a non-zero number of things easier to write. |
| 23:29:02 | * | sdw joined #nim |
| 23:29:09 | ldlework | Getting used to, or otherwise writing in a style or manner that allows you to write programs under the conditions of Nim's existing import mechanics doesn't mean that alternative import mechanics will objectively become less flexible in a relative sense or whatever |
| 23:29:36 | * | Varriount is still clueless |
| 23:29:46 | ldlework | Its just a crappy way to pee on everyone who disagrees with you. |
| 23:30:10 | flaviu | Why not just drop the whole import discussion until 2.0? It's at least "good enough", and there are better things to focus on than bikeshedding over import. |
| 23:30:20 | ldlework | flaviu: turns away users obviously |
| 23:30:39 | ldlework | not that I suggest that be the major concern, but that is at least an observable effect |
| 23:30:43 | ldlework | and you asked |
| 23:30:52 | Araq | ldlework: and yet I've never heard "oh this sucks but I got used to it" either. if that's your argument. |
| 23:31:09 | flaviu | ldlework: it was a rhetorical question :) |
| 23:31:35 | ldlework | Araq: right, I remember when we did that poll |
| 23:31:53 | ldlework | someone should make that available on the website |
| 23:32:34 | flaviu | Anyway, this can all be solved with a linter that faults procs exclusively for types the module writer does not own. |
| 23:33:34 | ldlework | flaviu: yeah, at least then, for the set of users we would otherwise lose, we can save the ones who depend on heavy IDEs |
| 23:33:48 | flaviu | ldlework: linter != IDE |
| 23:34:08 | ldlework | flaviu: okay the subset of people who run linters on their code as an external tool |
| 23:37:13 | * | the9to5 quit () |
| 23:38:45 | * | the9to5 joined #nim |
| 23:41:38 | * | TEttinger quit (Ping timeout: 265 seconds) |
| 23:42:07 | * | Senketsu quit (Ping timeout: 265 seconds) |
| 23:50:55 | reactormonk | Araq, any documentation on the compiler caching? |
| 23:54:40 | Araq | ldlework: The import mechanism changes you're after do not help with the problem of code navigation without an IDE, so it would be nice not to bring up more and more old arguments that have been addressed and IMHO in fact completely destroyed. |
| 23:55:12 | Araq | reactormonk: sorry, no, but you already know all the involved modules |
| 23:55:30 | Araq | good night |
| 23:55:36 | Varriount | Night. |
| 23:55:43 | ldlework | I was responding directly to flaviu. |
| 23:56:35 | ldlework | And they really really really do, help IDE-less users. Namespacing does precisely the thing of letting you know where something came from. |
| 23:56:42 | ldlework | Not sure how 'code navigation' came into this at all. |