| 00:01:06 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 00:04:06 | * | ftsf_ joined #nim |
| 00:06:44 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:11:11 | * | elrood_ quit (Quit: Leaving) |
| 00:11:47 | zachcarter | so I’m looking at this docu surroundin gsets : |
| 00:12:02 | zachcarter | https://nim-lang.org/docs/manual.html#types-set-type |
| 00:12:10 | zachcarter | it says : Sets are often used to define a type for the flags of a procedure. This is a much cleaner (and type safe) solution than just defining integer constants that should be or'ed together. |
| 00:12:22 | zachcarter | fine but how do I do that if my method wants like a uint32 |
| 00:12:30 | zachcarter | and is expecting integer constants ORd together |
| 00:12:36 | zachcarter | how do I go from a set to like a uint32 |
| 00:21:19 | ftsf_ | does mySet.uint32 work? |
| 00:21:31 | ftsf_ | i played a little with sets but was rather confused |
| 00:21:39 | zachcarter | hrm let me try that |
| 00:21:40 | ftsf_ | i think for the same reasons as you |
| 00:21:45 | zachcarter | yeah :/ |
| 00:23:33 | zachcarter | I don’t think what I”m trying to do is going to work |
| 00:23:52 | zachcarter | I’m trying to add a thin wrapper around some enums |
| 00:23:57 | zachcarter | so I’m declaring my own enums like |
| 00:24:09 | zachcarter | type |
| 00:24:10 | zachcarter | WindowFlag* {.pure.} = enum |
| 00:24:11 | zachcarter | WindowFullscreen = sdl.SDL_WINDOW_FULLSCREEN # Start window in fullscreen mode |
| 00:24:12 | zachcarter | WindowOpenGL = sdl.SDL_WINDOW_OPENGL # Create window with OpenGL support |
| 00:24:13 | zachcarter | WindowShown = sdl.SDL_WINDOW_SHOWN # Window will start out visible |
| 00:24:27 | zachcarter | then I’m trying to put these together in a set |
| 00:24:29 | zachcarter | so like |
| 00:24:36 | zachcarter | {WindowFullscreen, WindowShown} |
| 00:24:56 | zachcarter | and then I want to ideally pass those as if they were |
| 00:25:02 | zachcarter | WindowFullscreen.ord or WindowShown.ord |
| 00:25:04 | ftsf_ | pass WindowFullscreen or WindowShown |
| 00:25:14 | zachcarter | I have to do .ord :/ |
| 00:25:22 | zachcarter | which isn’t ideal |
| 00:25:31 | ftsf_ | hmm you could have a converter... |
| 00:25:33 | ftsf_ | but yeah not ideal |
| 00:25:37 | zachcarter | yeah |
| 00:28:03 | couven92 | cheatfate, okay, vccenv is now back again... VCC Auto-discovery reimagined |
| 00:28:49 | couven92 | I created the vccdiscover utility, which now only uses vccenv, but later also will use vswhere |
| 00:32:55 | cheatfate | vswhere can be implemented in pure nim |
| 00:36:49 | couven92 | cheatfate, yes, I am working on that |
| 00:37:23 | cheatfate | couven92, but what about speed of vs2017? |
| 00:37:31 | cheatfate | is it more responsive in interface? |
| 00:38:25 | couven92 | You mean the IDE? Yeah, they did a lot of optimizations for the startup and resource consumptions |
| 00:38:47 | * | def-pri-pub joined #nim |
| 00:39:21 | cheatfate | and is it stable now? |
| 00:39:22 | * | PMunch quit (Quit: leaving) |
| 00:39:32 | couven92 | If you install an extension that uses a lot of memory, startup time, or CPU, VS2017 automatically detects that and gives you the ability defer loading of that extension |
| 00:40:15 | * | hcorion joined #nim |
| 00:40:17 | * | PMunch joined #nim |
| 00:40:20 | couven92 | stable... I haven't had much issues yet... But I have seen some issues in the .NET Core Tooling |
| 00:40:51 | hcorion | Hi all! I'd like to turn the following code into a one-liner but I can't figure out how: |
| 00:40:52 | hcorion | var test: string = await socket.recv(1) |
| 00:40:56 | cheatfate | i even dont installing .net, i'm using only c/c++ |
| 00:40:58 | hcorion | var good: bool = test == $1 |
| 00:41:11 | couven92 | cheatfate, then you should be fine |
| 00:42:27 | couven92 | And even better: You can choose not to install C#, .NET and all that stuff... Just only install the C++ workload and it'll just do that (and include the core editor features of course) |
| 00:44:06 | couven92 | BTW, I am playing with the idea to integrate nimsuggest into Visual Studio, create a project system that suits nim and with that provide 1st class support for nim development in VS |
| 00:47:21 | * | ftsf_ really wishes opengl API was better with type safety |
| 00:50:19 | ftsf_ | maybe i'll make a nice nim wrapper around opengl that hides all that crap and lets you just do things with nice safe types |
| 01:00:44 | * | couven92 quit (Quit: Good Night!) |
| 01:10:02 | hcorion | Perhaps this might help @ftsf_ https://github.com/krux02/opengl-sandbox |
| 01:11:14 | ftsf_ | hcorion, some of it is likely useful |
| 01:33:33 | * | zachcarter quit (Quit: zachcarter) |
| 01:34:19 | * | donlzx joined #nim |
| 01:36:34 | * | brson quit (Quit: leaving) |
| 01:47:02 | * | PMunch quit (Quit: leaving) |
| 01:52:44 | * | pie__ quit (Ping timeout: 258 seconds) |
| 02:32:40 | * | Nobabs27 joined #nim |
| 02:40:30 | * | chemist69 quit (Disconnected by services) |
| 02:40:36 | * | chemist69_ joined #nim |
| 02:52:41 | * | BitPuffin|osx quit (Remote host closed the connection) |
| 02:57:22 | * | zachcarter joined #nim |
| 02:58:51 | * | hcorion quit (Quit: Konversation terminated!) |
| 03:01:02 | * | libman quit (Quit: Connection closed for inactivity) |
| 03:01:28 | zachcarter | ftsf_ you could use bgfx :P |
| 03:03:35 | ftsf_ | hmm don't know much about it |
| 03:03:39 | ftsf_ | nice api? |
| 03:04:12 | zachcarter | yeah |
| 03:04:16 | zachcarter | I can give you some sample code |
| 03:04:17 | zachcarter | one sec |
| 03:04:28 | zachcarter | it could be made more nim friendly |
| 03:05:24 | zachcarter | https://gist.github.com/zacharycarter/10e6b41fb2eada6cdfaaa519b50eb001 |
| 03:06:04 | zachcarter | you’re still dealing with buffers though |
| 03:06:25 | zachcarter | and uniforms etc |
| 03:06:41 | zachcarter | krux02’s opengl sandbox is nice but no OSX support :/ |
| 03:06:58 | ftsf_ | hmm... it's got platform specific stuff? |
| 03:07:06 | zachcarter | that’s mostly for SDL |
| 03:07:16 | zachcarter | oh sorry |
| 03:07:25 | zachcarter | yes it needs to know what platform you’re running on |
| 03:07:34 | zachcarter | because it chooses the corrrect render backend to call |
| 03:07:44 | zachcarter | OpenGL, OpenGL ES, DirectX 9, 11, 12 eventually Vulkan |
| 03:07:49 | zachcarter | etc |
| 03:08:11 | zachcarter | it may be overkill for your needs I’m not sure |
| 03:08:24 | ftsf_ | hmm |
| 03:08:33 | zachcarter | I find it a bit easier to work with than OpenGL though |
| 03:08:42 | ftsf_ | i'll check it out |
| 03:08:59 | zachcarter | cool :) if you need help with anything let me know |
| 03:09:32 | * | Nobabs27 quit (Quit: Leaving) |
| 03:12:01 | ftsf_ | thanks =) |
| 03:12:07 | zachcarter | sure thing! |
| 03:12:15 | zachcarter | btw the maintainer is really nice and helpful and hangs out in gitter |
| 03:23:19 | * | federico3 quit (Quit: WeeChat 1.7) |
| 03:26:01 | * | ftsf_ quit (Quit: :q!) |
| 03:48:34 | * | zachcarter quit (Read error: Connection reset by peer) |
| 03:48:52 | * | zachcarter joined #nim |
| 04:03:02 | * | def-pri-pub quit (Quit: leaving) |
| 04:05:54 | * | def-pri-pub joined #nim |
| 04:14:23 | * | vlad1777d joined #nim |
| 04:33:33 | * | donlzx quit (Ping timeout: 260 seconds) |
| 04:39:30 | * | donlzx joined #nim |
| 04:46:20 | * | ftsf_ joined #nim |
| 04:50:16 | * | bungoman_ joined #nim |
| 04:51:50 | * | bungoman quit (Ping timeout: 246 seconds) |
| 04:54:25 | * | zachcarter quit (Quit: zachcarter) |
| 05:06:28 | * | def-pri-pub quit (Remote host closed the connection) |
| 05:20:12 | * | xet7_ is now known as xet7 |
| 05:27:10 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 05:29:36 | * | Vladar joined #nim |
| 05:37:21 | * | zaquest quit (Quit: Leaving) |
| 05:58:43 | * | yglukhov joined #nim |
| 06:03:23 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 06:07:46 | * | arnetheduck joined #nim |
| 06:09:37 | * | Jehan_ joined #nim |
| 06:11:29 | * | shashlick quit (Ping timeout: 240 seconds) |
| 06:13:06 | * | shashlick joined #nim |
| 06:26:39 | * | Jehan_ quit (Quit: Leaving) |
| 06:27:05 | * | Jehan_ joined #nim |
| 06:29:35 | * | Jehan_ quit (Client Quit) |
| 06:30:54 | * | Jehan_ joined #nim |
| 06:32:31 | * | Jehan_ quit (Client Quit) |
| 06:33:58 | * | Jehan_ joined #nim |
| 06:34:17 | * | Jehan_ quit (Client Quit) |
| 06:34:34 | * | Jehan_ joined #nim |
| 06:37:54 | * | Jehan_ quit (Client Quit) |
| 06:38:48 | * | Jehan_ joined #nim |
| 06:43:29 | * | chemist69_ quit (Ping timeout: 246 seconds) |
| 06:44:22 | * | chemist69 joined #nim |
| 06:46:20 | * | kulelu88 quit (Ping timeout: 268 seconds) |
| 06:55:46 | * | nsf joined #nim |
| 07:05:49 | * | Jehan_ quit (Quit: Leaving) |
| 07:07:27 | * | ftsf_ quit (Quit: :q!) |
| 07:09:57 | * | zaquest joined #nim |
| 07:11:05 | * | rokups joined #nim |
| 07:32:20 | * | Jehan_ joined #nim |
| 07:41:19 | * | yglukhov joined #nim |
| 07:43:10 | * | Jehan_ quit (Quit: Leaving) |
| 07:44:05 | * | Jehan_ joined #nim |
| 07:51:47 | * | couven92 joined #nim |
| 07:52:20 | couven92 | Good morning everyone! :) |
| 07:58:09 | FromGitter | <vegansk> Good afternoon @couven92 :-) |
| 07:58:41 | couven92 | Hi, @vegansk, on the other side of the pond? |
| 08:01:28 | FromGitter | <vegansk> No, Siberia :-) |
| 08:01:56 | * | bjz joined #nim |
| 08:02:14 | couven92 | Ah! Right, makes sense... Sorry I was going in the wrong direction... :P It's probably in the middle of the night in the US now... |
| 08:05:11 | couven92 | we should use `nimsuggest` in favor of `nim idetools`, right? |
| 08:07:17 | FromGitter | <vegansk> @couven92, yes. vs code, emacs, aporia uses nimsuggest |
| 08:07:52 | couven92 | So why does the documentation on `nimsuggest` suck, while `nim idetools` is pretty well documented? |
| 08:09:36 | FromGitter | <vegansk> I don't see idetools documentation here: https://nim-lang.org/docs/tools.html |
| 08:10:17 | * | Jehan_ quit (Quit: Leaving) |
| 08:10:54 | couven92 | https://nim-lang.org/docs/nimc.html#nim-idetools-integration |
| 08:21:33 | * | jjido joined #nim |
| 08:24:45 | * | gokr joined #nim |
| 08:29:59 | FromGitter | <vegansk> @couven92, I guess, it's the standart problem: there is always no time for documenting things :-) |
| 08:30:28 | * | jjido quit (Remote host closed the connection) |
| 08:30:48 | * | jjido joined #nim |
| 08:32:51 | couven92 | A shame really... I have no clue what the other (undocumented) nimsuggest commands do... and don't really understand it from reading the nimsuggets source code either... :/ |
| 08:32:57 | * | tankfeeder joined #nim |
| 08:33:33 | Araq | couven92: I took what's still relevant from the idetools docs and didn't write much new |
| 08:34:01 | * | Andris_zbx joined #nim |
| 08:34:42 | couven92 | Araq, okay... what do the `dus`, `chk`, `mod`, `highlight`, `outline` and `known` commands do? |
| 08:35:02 | * | Vladar quit (Remote host closed the connection) |
| 08:35:05 | Araq | known file.nim # is that file part of the project you gave to nimsuggest |
| 08:35:23 | Araq | chk # check the file for errors, report errors similar to suggestions |
| 08:35:39 | Araq | mod # I literally cannot remember |
| 08:35:54 | Araq | highlight # give back token highlighting information |
| 08:36:36 | Araq | dus # def or use # my favorite, when on a declaration, jump to its usages, when on a usage, jump to its declaration |
| 08:36:49 | Araq | (that's what every editor should do, don't make think) |
| 08:36:54 | Araq | *make me |
| 08:37:09 | Araq | outline # can't remember |
| 08:37:20 | couven92 | ah okay... so highlight is for painting the text buffer in the IDE, and outline is for collapsing and expanding code blocks? |
| 08:37:36 | couven92 | s/painting/colouring |
| 08:37:45 | Araq | unlikely |
| 08:37:59 | Araq | read its code and document what it does :-) |
| 08:38:03 | couven92 | :P |
| 08:38:13 | * | Vladar joined #nim |
| 08:39:16 | couven92 | vccexe and vccdiscover both have their documentation through the `--help` command-line argument... Is that okay, or should I write doc pages in rst as well? |
| 08:40:14 | Araq | just patch nimsuggest.rst please |
| 08:40:18 | * | Jehan_ joined #nim |
| 08:40:34 | Araq | reading docs in that 80x20 excuse you call a terminal is a pain |
| 08:41:01 | couven92 | okay... I will do that... while writing Visual Studio integration, and I'll write vccexe.rst as well while I am at it |
| 08:41:11 | * | Jehan_ quit (Client Quit) |
| 08:41:23 | Araq | check out the existing VS plugin |
| 08:41:50 | couven92 | the NimStudio thing? |
| 08:41:56 | Araq | you can probably base your work on that, nimsuggest's output is not that different from idetools |
| 08:42:01 | Araq | yes, NimStudio |
| 08:43:16 | * | Jehan_ joined #nim |
| 08:43:36 | couven92 | yeah, I had a look at that... I was planning on doing that... But it might be that I'll rework that quite a bit... but... I'll fork it anyways... |
| 08:44:10 | couven92 | I'll have to see how much new stuff has come with VS2017 in terms of VSIX development |
| 08:44:30 | Araq | oh and write some debugger support :-) |
| 08:44:48 | Araq | with --debugger:native the Nim compiler produces name mappings, that's a start |
| 08:45:00 | couven92 | Araq, I'll need to write my MSc. as well!!!! :P |
| 08:47:02 | couven92 | oh, regarding vccexe, do you wnat to wait until I have ported vswhere to nim, so that we can auto-discover VS2017, or do you want to look at the added features for vccexe as it is now? Might take some time (probably a couple of days) until I get vswhere to work... |
| 08:47:46 | Araq | I prefer to review small incremental improvements |
| 08:47:54 | Araq | and your PR is red btw, check it out |
| 08:48:08 | Araq | that means it causes some tests to fail |
| 08:48:50 | couven92 | is it? it's green here... Yes, I had an error, forgot to update the `koch tools` command, but that is fixed |
| 08:53:33 | Araq | ah ok |
| 08:54:30 | * | zachcarter joined #nim |
| 08:57:40 | cheatfate | couven92, is it possible to change semantic of compilation with vcc to have something comparable to mingw? i mean we don't really needs to see `command line`, only warnings and errors |
| 08:58:22 | couven92 | cheatfate, compile a release build, then it echoes nothing |
| 08:58:42 | cheatfate | what i need to compile to release build? |
| 08:58:44 | cheatfate | nim? |
| 08:58:48 | couven92 | vccexe |
| 08:58:58 | cheatfate | but that's koch task not mine |
| 08:59:20 | couven92 | ah! okay... I'll put it into koch. Thanks! :) |
| 08:59:25 | * | Jehan_ quit (Quit: Leaving) |
| 09:00:05 | couven92 | ah, wait... cheatfate, if you run `koch tools -d:release` does it compile vccexe as a release build? It think it would... |
| 09:00:43 | couven92 | so if you just run `koch tools`, koch will debug compile all tools, as far as I understand |
| 09:01:41 | * | Jehan_ joined #nim |
| 09:02:46 | cheatfate | couven92, https://gist.github.com/cheatfate/df5b8b833488735a93c02e2181301d37 |
| 09:02:56 | cheatfate | this is output after i have made `koch tools -d:release` |
| 09:03:05 | cheatfate | i think CC: filename is enough |
| 09:04:03 | * | Jehan_ quit (Client Quit) |
| 09:04:11 | couven92 | yeah, I totally agree... Though, I don't really understand why `koch tools -d:release` produces debg builds... Hmm... |
| 09:08:49 | cheatfate | but wait i think koch tools don't even build `vcc*` tools |
| 09:09:02 | couven92 | cheatfate, yes it does |
| 09:09:16 | cheatfate | for me with latest build it builds nimgrep & nimble only |
| 09:09:52 | Araq | cheatfate: nim c koch.nim |
| 09:09:58 | couven92 | Ah! |
| 09:09:59 | Araq | to get a more recent koch version |
| 09:10:02 | couven92 | :) |
| 09:11:53 | cheatfate | Araq, i think more recent koch version i will get when i'm making `git pull` |
| 09:11:58 | cheatfate | and i have made it yesterday |
| 09:12:29 | couven92 | cheatfate, no, git pull will only get you the newest source code... You'll have to recompile it |
| 09:13:05 | cheatfate | couven92, do you really think i'm so stupid? |
| 09:13:35 | cheatfate | i dont see here https://github.com/nim-lang/Nim/blob/devel/koch.nim#L253-L260 |
| 09:13:36 | couven92 | forgetful maybe... I have personally done that same mistake several times! |
| 09:13:57 | cheatfate | any lines about to build vccexe |
| 09:14:22 | couven92 | uh..., woah... |
| 09:15:50 | cheatfate | so i think my koch version is pretty recent... |
| 09:16:14 | couven92 | ah! here it is: https://github.com/nim-lang/Nim/blob/01afff495cdf1b9bb0646894dac74fcfdb59d072/koch.nim#L210 |
| 09:16:52 | cheatfate | but bundlewintools is for core developers only... |
| 09:17:01 | cheatfate | and i dont need `finish` |
| 09:17:21 | cheatfate | this is mostly `before release build` step |
| 09:17:37 | euantor | quick off topic question, what's with the `empty.txt` files in the `bin/` and `build/` directories? Wouldn't a `.gitignore` make more sense? |
| 09:17:43 | couven92 | According to `git blame`, Araq put it there... I don't know why it's not in the tools builder... |
| 09:18:02 | couven92 | euantor, it's so that the directories exist |
| 09:18:21 | euantor | `.gitignore` achieves the same thing and is slightly more standard |
| 09:18:23 | ldlework | What are some examples of great uses of Nim's macros? |
| 09:18:30 | euantor | Not a big issue, just wondering why it was chosen :) |
| 09:18:56 | couven92 | euantor, no! .gitignore is for IGNORING files from the git index... |
| 09:19:22 | euantor | Yes, so you would do: |
| 09:19:35 | euantor | https://www.irccloud.com/pastebin/EPhs9cib/ |
| 09:19:35 | couven92 | So that way, when you clone Nim from source, you'd be missing a lot of the directories that nim expects to be there |
| 09:19:43 | cheatfate | Araq, why `koch tools` don't build `vcc*` tools on windows? |
| 09:19:47 | euantor | Ignore everything in directory, but not `.gitignore` |
| 09:20:21 | euantor | @ldlework I'd say `asyncdispatch` is a pretty good example of Nim's macros in sue: https://github.com/nim-lang/Nim/blob/01afff495cdf1b9bb0646894dac74fcfdb59d072/lib/pure/asyncmacro.nim#L396 |
| 09:20:52 | couven92 | euantor, Ah... Okay... now I see what you mean... Well... depends on what you think is "more standard"... RubyOnRails for example creates empty .keep files and adds them to the git index |
| 09:20:59 | cheatfate | euantor, not the best example of macro usage... |
| 09:21:58 | euantor | A pretty good one though, I can't think of many others in the stdlib off the top of my head |
| 09:22:10 | cheatfate | euantor, its like when you reach level 80 in macro programming, you can get it |
| 09:22:21 | euantor | @couven92 Fair enough, was just wondering because I'm used to the `.gitignore` approach :) |
| 09:22:30 | couven92 | cheatfate, in order to build vccexe (as a release build) run the following from the nim root: `nim compile -d:release -o:bin\vccexe vccenv\vccexe` |
| 09:22:45 | euantor | I've been meaning to write a blog post about my first attempts at working with macros |
| 09:24:06 | couven92 | or if you want my newest additions to vccexe you'll have to check them out from my couven92/Nim repo... Then vccexe will have moved from vccenv to vccexe and you'll have to run `nim compile -d:release -o:bin\vccexe tools\vccexe\vccexe` |
| 09:24:39 | couven92 | ah sorry, I forgot a "tools" path segment in the first command... sorry... |
| 09:25:48 | cheatfate | couven92, i just think `koch tools` must build it for developers... |
| 09:25:56 | couven92 | I agree! |
| 09:26:07 | couven92 | Let's make a PR! :) |
| 09:26:24 | couven92 | and if you have your Nim distribution under source control (as I have), then you probably don't want to edit the nim.cfg in the repo... I have created my own nim.cfg in APPDATA where I set cc to vcc |
| 09:27:53 | cheatfate | couven92, i'm using --cc:vcc to change compilers |
| 09:27:58 | cheatfate | i'm not always use vcc |
| 09:28:07 | couven92 | that works as well :) |
| 09:28:10 | cheatfate | because it creates slower nim code |
| 09:28:17 | cheatfate | and slower compiling |
| 09:28:32 | cheatfate | so mingw is my choice |
| 09:28:51 | cheatfate | but with mingw i can't use much better vs debugger |
| 09:29:07 | couven92 | yeah... well... I have given up on MinGW... and I refuse to install MinGW just so that nim compiles... But that's probably just me being weird and stupid! :P |
| 09:29:57 | cheatfate | i'm not installing mingw, its pretty portable |
| 09:30:10 | cheatfate | i'm just need to put `bin` folder to path |
| 09:32:12 | couven92 | well, I think ONE C/C++ compiler is enough... So I use VCC since I use Visual Studio on daily basis anyways, and that way I know that my compiler is always up to date... |
| 09:32:27 | couven92 | With MinGW I'd just forget about it, and never update it |
| 09:32:51 | couven92 | Since I'd use MinGW so rarely |
| 09:35:33 | Araq | couven92, cheatfate ok ok, my bad, put it under the wrong koch command |
| 09:38:00 | * | user0___ joined #nim |
| 09:40:08 | cheatfate | when somebody helps me to finish nim debugger, then i will uninstall VS from my PC :) |
| 09:41:11 | * | jjido quit (Ping timeout: 264 seconds) |
| 09:44:03 | * | user0___ quit (Read error: Connection reset by peer) |
| 09:44:15 | * | user0___ joined #nim |
| 09:48:10 | couven92 | Araq, does that mean, that you're moving it to the right place in koch, or am I doing a PR? |
| 09:49:21 | * | deavmi__ joined #nim |
| 09:49:26 | Araq | just a sec |
| 09:51:48 | * | deavmi__ quit (Client Quit) |
| 09:54:17 | * | kulelu88 joined #nim |
| 09:55:29 | kulelu88 | if I have a file stored at the same level as the execution of my program, how do I call to that file ? |
| 09:55:44 | couven92 | import file |
| 09:56:02 | couven92 | where file is the filename without the .nim extension |
| 09:56:42 | kulelu88 | couven92: say I want to use a non-nim file. eg. file.txt |
| 09:57:46 | couven92 | say what? you want to compile a file.txt? Why would you want to do that? Nim source code is supposed to be in a .nim file! |
| 09:58:35 | FromGitter | <dom96> @euantor I've seen people using '.gitkeep', but it's just something people came up with, Git doesn't sanction this convention. Empty.txt is also fine. |
| 09:58:37 | kulelu88 | couven92: you are misunderstanding. I have a program that wants to see/use a .txt file to do something. |
| 09:59:07 | couven92 | kulelu88, so you wnat to open the file for reading? |
| 09:59:21 | kulelu88 | yeah, essentially |
| 10:00:00 | flyx | kulelu88: use os.getAppDir() for getting the directory your executable is located in |
| 10:00:24 | euantor | @dom96 Yeah, no problem. I've just never seen it before now :) |
| 10:00:32 | FromGitter | <dom96> btw here is a simple macro from my book: https://github.com/dom96/nim-in-action-code/blob/master/Chapter9/configurator/configurator.nim |
| 10:00:40 | FromGitter | <dom96> I still need to add comments to the code though. |
| 10:01:31 | couven92 | kulelu88, and system.open for opening the file: https://nim-lang.org/docs/system.html#open,File,string,FileMode,int |
| 10:02:34 | kulelu88 | how do I make a variable declared in a proc accessible to other procs ? |
| 10:02:47 | * | yglukhov quit (Remote host closed the connection) |
| 10:03:04 | couven92 | kulelu88, by passing it to the proc as an argument |
| 10:03:12 | FromGitter | <vegansk> @dom96, could you point me, why async macro fails here: https://github.com/nim-lang/Nim/issues/5571 |
| 10:04:02 | FromGitter | <Varriount> kulelu88: You have to either make the variable global, or pass the date around through parameters/returns |
| 10:04:14 | * | yglukhov joined #nim |
| 10:07:27 | * | yglukhov quit (Remote host closed the connection) |
| 10:10:50 | kulelu88 | @Varriount , how would I pass db to the proc called "test": https://www.zerobin.net/?8356791069ae8e22#AXZdd6hZulfB3XxJNtcoNSNPJ4KsIQZu4x/8/W6eDgY= ? |
| 10:13:22 | FromGitter | <Varriount> kulelu88: You would change the return type of activate to the database type, then call activate() in your test procedure and assign the return value to a variable. |
| 10:17:31 | kulelu88 | @Varriount equivalent to saying: proc activate(): DbConn = #do something ... proc test() = db = activate() ? |
| 10:18:09 | FromGitter | <Varriount> kulelu88: Pretty much, yes |
| 10:19:48 | FromGitter | <dom96> @vegansk one of the variables that the async macro is generating is global and not gc safe I guess. Not sure why it would have worked before and not after @endragor's changes though. |
| 10:19:57 | FromGitter | <dom96> Are you compiling with --threads:on? |
| 10:21:34 | FromGitter | <vegansk> @dom96, yes. Forgot to mention about ``--threads:on`` |
| 10:22:05 | kulelu88 | @Varriount but when I call activate() from test(), I need to pass the inputs to activate(name, dbname, pw), correct ? |
| 10:22:37 | FromGitter | <Varriount> Yes. |
| 10:22:53 | kulelu88 | alright, that is not what I want though. so I guess I need to declare a global variable |
| 10:23:58 | FromGitter | <vegansk> Here is the output of -d:nimDumpAsync. And I can't see there is this ``not GC -safe`` mem ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=58d0ff3da84f611959c96af5] |
| 10:27:15 | FromGitter | <vegansk> @dom96, it worked before. I found the problem in this test (https://github.com/vegansk/nimboost/blob/master/tests/boost/io/test_asyncstreams.nim#L10) and now I use this git hash (https://github.com/vegansk/nimboost/blob/master/.travis.yml#L9) to make travis green |
| 10:32:46 | FromGitter | <vegansk> @dom96, it's fixed in https://github.com/nim-lang/Nim/pull/5583 |
| 10:33:07 | * | federico3 joined #nim |
| 10:41:31 | * | donlzx quit (Quit: Leaving) |
| 10:42:02 | * | yglukhov joined #nim |
| 10:46:50 | * | yglukhov quit (Remote host closed the connection) |
| 10:47:24 | Araq | couven92, cheatfate 'koch wintools' |
| 10:47:35 | Araq | includes it, what's wrong with that |
| 10:47:54 | couven92 | Araq, cheatfate wanted it in tools... |
| 10:48:20 | couven92 | But I get why it is in wintools... VCC is windows only... |
| 10:48:24 | cheatfate | Araq, when i run `koch` i dont see any `wintools` option available... i think its not documented too |
| 10:48:43 | cheatfate | why not use `tools` with `when defined(windows)`? |
| 10:49:32 | couven92 | But hey, vccexe should work fine on Linux as well... It just wouldn't do anything... (except if you manage to marry VCC to wine or sth like that) |
| 10:53:59 | Araq | ok, |
| 10:54:12 | Araq | should I also add the -d:release for it? |
| 10:54:45 | cheatfate | nope its not necessary if `koch tools -d:release` can be specified to make release version |
| 10:54:45 | couven92 | maybe I should add a --verbose command-line argument to vccexe instead? |
| 10:55:16 | * | Vladar quit (Remote host closed the connection) |
| 10:55:42 | Araq | cheatfate: 'koch tools' doesn't take options, it builds stuff we intend to ship with nim |
| 10:56:00 | Araq | some tools already have -d:release, for example nimsuggest |
| 10:56:32 | Araq | couven92: that would be better, but for now tell me wether -d:release or not |
| 10:56:36 | cheatfate | `koch boot -d:release` and `koch boot`, it will be nice to save behavior |
| 10:56:53 | * | yglukhov joined #nim |
| 10:57:24 | couven92 | I'd say not... I'll add --verbose instead right away |
| 10:57:33 | Araq | couven92: ok. |
| 10:57:52 | Araq | cheatfate: I don't want to update our official build instructions yet again |
| 10:58:16 | cheatfate | Araq, but this is simple logic... and now this is just bunch of undocumented commands |
| 10:58:59 | cheatfate | if `koch xxx` make build then it must accept build options, like `koch boot` do |
| 10:59:45 | * | federico3 quit (Quit: WeeChat 1.7) |
| 11:00:11 | cheatfate | but now you will add `vccexe` debug version to `koch tools`, so if some editor wants to capture `errors` and `warnings` it must compile this files by itself |
| 11:00:17 | * | Sembei joined #nim |
| 11:00:47 | cheatfate | because its impossible to capture errors/warnings using vcc compiler |
| 11:00:53 | Araq | it's simple logic, but it's not what I want. 'koch tools' builds additional tools. some tools in release mode because they are too slow otherwise, others are fine in debug mode, 'koch tools -d:release' passes -d:release to every tool |
| 11:01:19 | Araq | and then 'koch tools' would compile nimsuggest in debug mode for consistency. bah. |
| 11:01:36 | * | yglukhov quit (Remote host closed the connection) |
| 11:02:05 | cheatfate | if nimsuggest not ready to be shipped in release mode, then maybe it must be removed from tools? |
| 11:02:30 | Araq | it's not exactly hard to do on your own: nim c -o:bin/vccexe.exe tools/vccenv/vccexe |
| 11:02:32 | * | Snircle joined #nim |
| 11:02:50 | * | Vladar joined #nim |
| 11:02:55 | couven92 | Araq, that's how I have always done it! :P |
| 11:02:57 | cheatfate | yeah, its not so hard for me... but vccexe is a tool? or no? |
| 11:03:05 | * | Pisuke quit (Ping timeout: 260 seconds) |
| 11:03:16 | cheatfate | tomorrow some newcomers will ask you same question? |
| 11:03:22 | cheatfate | what do you answer? |
| 11:03:56 | cheatfate | you answer them, `nim c -o:bin/vccexe.exe ...` |
| 11:04:22 | cheatfate | its nonsense |
| 11:04:33 | Araq | I added vcc to 'koch tools' |
| 11:04:47 | Araq | but I'm ignoring this 'koch tools -d:release' proposal. |
| 11:04:53 | * | yglukhov joined #nim |
| 11:05:06 | Araq | I will ignore the proposal again when other newcomers demand it. |
| 11:05:24 | Araq | when 3 people demand it, I'll consider changing my opinion. |
| 11:05:40 | cheatfate | so koch tools build debugging version of vccexe? |
| 11:06:02 | Araq | that's how it usually works. of course, you then say "you only listen to newcomers, never to me", but that's just unfair. ;-) |
| 11:07:01 | cheatfate | couven92, please remove debugging output from vccexe |
| 11:07:35 | couven92 | yeah, easy! I am onto it right now! :P |
| 11:07:38 | cheatfate | because on large projects it gives so much noise |
| 11:08:57 | * | zachcarter quit (Quit: zachcarter) |
| 11:09:20 | cheatfate | Araq, `koch` needs some love too, or it will turn to `trash can` |
| 11:09:43 | * | kulelu88 quit (Quit: Leaving) |
| 11:09:50 | cheatfate | like nimble |
| 11:16:52 | * | zachcarter joined #nim |
| 11:17:41 | FromGitter | <andreaferretti> I am little lost |
| 11:17:51 | FromGitter | <andreaferretti> what it the suggested way to build tools at the end |
| 11:18:05 | FromGitter | <andreaferretti> `koch tools` or `koch tools -d:release`? |
| 11:18:11 | FromGitter | <andreaferretti> as of today |
| 11:18:53 | cheatfate | lol |
| 11:19:35 | FromGitter | <andreaferretti> I'm serious, I didn't follow the whole discussion... |
| 11:20:01 | cheatfate | andreaferretti: you can use as `koch tools` and `koch tools -d:release` - it doesn't matter because `koch` knows better what to do |
| 11:21:16 | FromGitter | <andreaferretti> ok, thank you! |
| 11:21:27 | cheatfate | but if you one of `vccexe` users, then you need to do `nim c -d:release -o:bin/vccexe.exe tools/vccenv/vccexe` by your own |
| 11:21:41 | couven92 | Araq, cheatfate, okay verbose command-line argument is now part of vccexe (regardless of debug or release build). I have also rebased my PR on Araq's koch changes |
| 11:22:41 | * | federico3 joined #nim |
| 11:27:59 | * | Jehan_ joined #nim |
| 11:41:42 | Araq | cheatfate: koch is loved. but sometimes I disagree with you. |
| 11:46:54 | * | Mr_Milja joined #nim |
| 11:47:50 | couven92 | Araq, on the topic of koch, why does it compile nim 5! times? I can understand the first and second time, but then? |
| 11:48:01 | * | Mr_Milja left #nim (#nim) |
| 11:48:38 | couven92 | Because I now have in my compiler directory: nim.exe nim0.exe, nim1.exe, nim2.exe and nim3.exe??? |
| 12:01:35 | stisa | couven92 : I think it recompiles nim until the new nim.exe is equal to the last |
| 12:01:47 | couven92 | ah! makes sense |
| 12:07:47 | cheatfate | interesting and how it can be different if options are not changing? |
| 12:07:58 | cheatfate | or compilers has some random mechanics inside? |
| 12:09:39 | * | cheatfate quit (Read error: Connection reset by peer) |
| 12:12:38 | stisa | Not sure, my guess is that it is a sort of test, if it can compile itself it is reasonably sure that it works? |
| 12:17:54 | * | bjz_ joined #nim |
| 12:18:53 | Araq | bootstrapping requires 3 iterations |
| 12:19:06 | * | bjz quit (Ping timeout: 240 seconds) |
| 12:19:11 | Araq | there is some proof about that iirc, the last nim3.exe is copied to your bin/ |
| 12:20:09 | Araq | and we could remove them all from compiler/ |
| 12:25:33 | * | adeohluwa joined #nim |
| 12:26:10 | * | cheatfate joined #nim |
| 12:26:36 | * | zachcarter quit (Quit: zachcarter) |
| 12:29:43 | * | adeohluwa quit (Read error: Connection reset by peer) |
| 12:36:07 | FromGitter | <dom96> @cheatfate: Nimble is a "trashcan"? |
| 12:40:58 | * | cheatfate quit (Quit: Leaving) |
| 12:47:11 | * | cheatfate joined #nim |
| 13:06:39 | * | PMunch joined #nim |
| 13:11:47 | * | zachcarter joined #nim |
| 13:20:45 | * | yglukhov quit (Remote host closed the connection) |
| 13:21:41 | * | yglukhov joined #nim |
| 13:25:47 | * | yglukhov quit (Remote host closed the connection) |
| 13:38:57 | * | chemist69 quit (Ping timeout: 260 seconds) |
| 13:53:50 | * | yglukhov joined #nim |
| 14:03:57 | * | pie__ joined #nim |
| 14:05:36 | * | chemist69 joined #nim |
| 14:08:26 | * | PMunch left #nim ("leaving") |
| 14:08:36 | * | PMunch joined #nim |
| 14:08:39 | PMunch | http://ix.io/p90 |
| 14:08:44 | PMunch | Why is this failing? |
| 14:09:05 | PMunch | Shouldn't the default high[T](x: T): T also work for the high(cint) call? |
| 14:09:39 | * | bjz_ quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 14:11:33 | * | bjz joined #nim |
| 14:45:55 | subsetpark | I feel like I've seen discussion on this before, but I can't say where... I essentially want to do, `if defined(release): define(bar)`. Is that possible? |
| 14:46:37 | subsetpark | I have a `noDebug` flag that I pass in for some of my test builds, and I want to ensure that it's also defined wherever release is passed in. |
| 14:47:16 | PMunch | https://nim-lang.org/docs/manual.html#implementation-specific-pragmas-compile-time-define-pragmas |
| 14:49:48 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 14:57:00 | subsetpark | PMunch: that's not exactly what I'm describing. Are you implying that's the best I can do? |
| 14:58:06 | PMunch | Hmm, maybe not |
| 14:58:09 | PMunch | Hold on |
| 14:58:30 | PMunch | Well |
| 14:59:05 | PMunch | You could do a when defined(release): const NoDebug {.intdefine.} = 1 |
| 14:59:11 | PMunch | I think that would work |
| 15:01:10 | subsetpark | hm - but in that case, how would you treat it when -d:noDebug is passed in, but not -d:release? The calls couldn't check for `when defined(noDebug)` because it's a const, but the const wouldn't be declared because release isn't defined |
| 15:01:35 | subsetpark | unless `defined()` also works on consts |
| 15:02:58 | PMunch | When you use {.intdefine.} it should work |
| 15:04:34 | subsetpark | when defined(release): |
| 15:04:34 | subsetpark | const Foo {.intdefine.} = 1 |
| 15:04:34 | subsetpark | echo Foo |
| 15:04:43 | subsetpark | doesn't compile with -d:Foo=1 |
| 15:05:57 | subsetpark | oh but you're saying check with defined, not as avalue... |
| 15:06:27 | PMunch | Yeah |
| 15:06:33 | FromGitter | <couven92_twitter> Uhm, is there a way to iterate over all values in a non-ordinal enumerated type? |
| 15:07:23 | subsetpark | yeah, in that case it compiles but the const line doesn't do what we want it to - `defined(Foo)` is false |
| 15:07:39 | FromGitter | <couven92_twitter> Had that problem yesterday already, but then I found a workaround. Now I really need it, since I have a pretty big enum... |
| 15:09:48 | PMunch | couven92_twitter: Have you tried "for i in myEnum:" ? |
| 15:11:40 | * | krux02 joined #nim |
| 15:22:40 | PMunch | dom96, Araq, the Nim site should really point /docs/ to /documentation.html |
| 15:22:53 | couven92 | PMunch, good idea... let's try... |
| 15:23:32 | PMunch | Cause right now it serves up the main page, but all relative paths are borked so it doesn't load any of the CSS/JS |
| 15:23:36 | PMunch | Or images |
| 15:31:02 | subsetpark | PMunch: I decided to just declare a const VERBOSITY from each possible flag |
| 15:31:28 | PMunch | Ah, that is also an option :) |
| 15:34:48 | * | couven92 quit (Quit: Client disconnecting) |
| 15:38:54 | * | jjido joined #nim |
| 15:39:35 | * | jjido quit (Read error: Connection reset by peer) |
| 15:40:24 | * | jjido joined #nim |
| 15:43:55 | * | BitPuffin|osx joined #nim |
| 15:45:06 | * | jjido quit (Read error: Connection reset by peer) |
| 15:50:42 | * | tankfeeder quit (Quit: Leaving) |
| 15:56:41 | * | krux02 quit (Remote host closed the connection) |
| 15:59:26 | PMunch | Hmm, I'm trying to move some stuff around in wxnim and create some new examples |
| 16:00:32 | PMunch | But I'm having some trouble getting example3 to compile |
| 16:00:47 | PMunch | It complains that it can't find wxStyledTextCtrl things |
| 16:00:55 | PMunch | Which are obviously imported from stc.nim.. |
| 16:14:07 | * | flaviu joined #nim |
| 16:33:59 | * | gokr quit (Ping timeout: 264 seconds) |
| 16:42:48 | * | krux02 joined #nim |
| 16:44:57 | PMunch | I fixed the stc thing with when defined(linux): {.passL: "`wx-config --libs stc`".} by the way (for you log readers) |
| 16:45:15 | PMunch | It appears that wx-config doesn't include the stc headers by default |
| 16:48:41 | PMunch | Is there a way to generate converters that are only invoked when interfacing with a specific library? |
| 16:48:55 | PMunch | For wxWidgets you tend to need some cint casts |
| 16:49:50 | PMunch | And it would be neat if these were to happen automatically, without the user having to write the converter every time and without polluting their other code with the converter (after all there is a reason why it's not default) |
| 16:54:33 | * | Andris_zbx quit (Remote host closed the connection) |
| 17:03:56 | * | gokr joined #nim |
| 17:03:57 | * | yglukhov quit (Remote host closed the connection) |
| 17:05:54 | FromGitter | <Varriount> PMunch: Can you give an example? |
| 17:06:13 | PMunch | Of the converter thing? |
| 17:07:03 | PMunch | Well, say I want to have a progress bar in wxWidgets. Using wxnim I get access to the function setValue(gauge: ptr WxGauge, value: cint) |
| 17:07:06 | * | couven92 joined #nim |
| 17:07:26 | PMunch | So to call it I would need to do progressBar.setValue(cint(variable)) |
| 17:08:26 | PMunch | Since these are all over the place in wxWidgets it would be nice to declare a converter intToCint(in: int):cint = cint(in) |
| 17:08:46 | FromGitter | <Varriount> Well, you can make a macro that generates a procedure overload, given a procedure name. The procedure overload would use generics and compile-time statements to convert arguments. |
| 17:09:01 | PMunch | But I don't want to have it declared for all the code the user might write, only the code that is actually a call through wxnim |
| 17:09:32 | FromGitter | <Varriount> Write a higher-level wrapper? |
| 17:09:45 | FromGitter | <Varriount> Generally though, things like that are a bad idea. Manual type conversions are there for a reason. |
| 17:10:09 | PMunch | That's why I don't want to have the converter globally for a user |
| 17:12:01 | FromGitter | <Varriount> PMunch: The most convenient thing I can think of is to create a macro that accepts a low-level procedure name, and produces a version of that procedure that does the conversions automatically. |
| 17:12:24 | FromGitter | <Varriount> You could also try using term-rewriting macros to rewrite the calls. |
| 17:12:38 | PMunch | Hmm |
| 17:13:54 | dom96 | hello guys |
| 17:17:53 | PMunch | Hi there |
| 17:24:44 | PMunch | dom96, did you see my message about the website? |
| 17:25:08 | dom96 | Yes, PRs welcome :) |
| 17:26:12 | dom96 | To be honest, fixes to the current websites are a bit of a low priority |
| 17:26:19 | dom96 | since we're working on a new one |
| 17:26:46 | PMunch | Ooh, anything cool planned? |
| 17:26:57 | PMunch | Or just a cosmetic redo? |
| 17:31:39 | FromGitter | <andreaferretti> any news about the progress? |
| 17:31:42 | FromGitter | <andreaferretti> what is missing now? |
| 17:32:56 | dom96 | andreaferretti: I would call it about 70% complete |
| 17:32:59 | dom96 | There is a lot of content missing |
| 17:33:13 | * | Jehan_ quit (Ping timeout: 268 seconds) |
| 17:34:21 | * | Jehan_ joined #nim |
| 17:35:12 | FromGitter | <andreaferretti> with respect to the current site? or in general? |
| 17:35:17 | FromGitter | <andreaferretti> it can always be expanded later on |
| 17:35:18 | * | Salewski joined #nim |
| 17:36:03 | * | Trustable joined #nim |
| 17:36:50 | Salewski | PMunch, when you declare your converter "declare a converter intToCint(in: int):cint = cint(in)" in module wxWidgets but do not export that converter, |
| 17:37:29 | Salewski | then it may work just fine. That is my memory related to GTK, sorry can not test yet. |
| 17:37:41 | * | Salewski left #nim (#nim) |
| 17:43:01 | dom96 | andreaferretti: sure, it can. But the basics have to be good. The new design will get us a lot of fresh eye balls and I want to ensure they stick around |
| 17:46:23 | * | chemist69 quit (Ping timeout: 246 seconds) |
| 17:49:33 | * | chemist69 joined #nim |
| 17:53:17 | * | Jehan_ quit (Quit: Leaving) |
| 17:53:49 | * | Salewski joined #nim |
| 17:55:14 | Salewski | Araq, I still wonder about what Jason M. once wrote about wrapper design in forum https://forum.nim-lang.org/t/1901#11815 |
| 17:55:27 | Salewski | "Currently, it uses ref types and finalizers to ensure objects are released, too. However, I want to move it to using plain" |
| 17:55:39 | Salewski | "types, and overloaded = and =destroy (assignment operators and destructors). The idea is that these types will have" |
| 17:56:02 | FromGitter | <andreaferretti> @dom96 makes sense :-) |
| 17:56:04 | Salewski | "the same in-memory layout as a plain pointer, so you can just use them everywhere without the indirection that ref" |
| 17:56:15 | * | flaviu quit (Ping timeout: 240 seconds) |
| 17:56:18 | Salewski | "incurs. But the current scheme works quite well, after all in a GUI app you don't access your GtkButtons in tight loops," |
| 17:56:30 | Salewski | "and the overhead is probably already lower as in Python+GTK." |
| 17:57:06 | Salewski | May his idea with destroy() work when we define pure Nim objects? |
| 17:57:48 | Araq | Salewski: destructors are still in the design phase. we have some proposal. it needs to be refined and implemented. |
| 17:58:03 | Araq | until this happens =destroy is unusable and ref+finalizers is the way to go |
| 17:58:25 | Araq | and it's also not part of our roadmap for v1 (soon to be updated) |
| 17:59:21 | Salewski | OK, thanks. Then I will try to follow the libui scheme for GTK3 high level wrapper. |
| 18:00:47 | PMunch | Salewski, I've got to run now but I don't think that would work. The user is calling the function so wouldn't the conversion need to happen there? |
| 18:00:52 | PMunch | Be back later |
| 18:01:26 | * | flaviu joined #nim |
| 18:01:51 | Salewski | PMunch, that was my initial thought too, but I think that was wrong. Can not really remember... |
| 18:01:56 | Salewski | Bye. |
| 18:02:01 | * | yglukhov joined #nim |
| 18:04:06 | * | gokr quit (Ping timeout: 240 seconds) |
| 18:05:28 | * | flaviu quit (Ping timeout: 240 seconds) |
| 18:06:21 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 18:08:22 | * | flaviu joined #nim |
| 18:18:54 | Salewski | PMunch, you are right, and my memory was wrong. The converter is only working when it is exported -- and that is what we want to avoid... |
| 18:19:02 | Salewski | # module i |
| 18:19:10 | Salewski | converter localCon0*(b:bool): int = int(b) |
| 18:19:16 | Salewski | proc test*(i: int) = echo i |
| 18:19:25 | Salewski | #module h |
| 18:19:30 | Salewski | import i |
| 18:19:38 | Salewski | test(0); test(true); test(false) |
| 18:19:42 | * | Salewski left #nim (#nim) |
| 18:24:36 | * | brson joined #nim |
| 18:29:18 | PMunch | Back now |
| 18:29:45 | PMunch | Yeah, that's what I thought |
| 18:33:20 | * | Matthias247 joined #nim |
| 18:36:31 | * | SusWombat_ joined #nim |
| 18:38:35 | * | SusWombat quit (Ping timeout: 268 seconds) |
| 18:47:02 | * | brson quit (Quit: leaving) |
| 19:00:29 | * | flaviu quit (Ping timeout: 260 seconds) |
| 19:02:57 | * | deavmi__ joined #nim |
| 19:03:22 | * | deavmi__ quit (Client Quit) |
| 19:04:21 | * | gokr joined #nim |
| 19:08:29 | * | brson joined #nim |
| 19:20:27 | * | zaquest quit (Quit: Leaving) |
| 19:26:37 | * | flaviu joined #nim |
| 19:29:50 | * | elrood joined #nim |
| 19:54:38 | PMunch | Updated my wxnim fork with instructions on how to use the genui macro: https://github.com/PMunch/wxnim#the-genui-macro |
| 19:55:12 | PMunch | Also added an example on how to use Nims threads and wxWidgets event passing to allow you to run long tasks on a separate thread from the UI |
| 20:06:04 | zachcarter | Question about host.systemCPU - would mips encompass both mips32 and mips64? |
| 20:06:39 | zachcarter | sorry |
| 20:06:41 | zachcarter | I meant system.hostCPU |
| 20:12:24 | Araq | PMunch: I see two options. |
| 20:12:35 | Araq | I merge your PR and review it. |
| 20:12:47 | Araq | or rather the other way round. |
| 20:13:12 | Araq | or you take over and update the packages.json entry so that you're the new maintainer |
| 20:13:48 | PMunch | It's up to you really |
| 20:14:18 | PMunch | The problem now is that your version is auto-generated |
| 20:14:27 | PMunch | But I've made changes to the files so that's no longer the case |
| 20:14:40 | PMunch | So running the create script would completely ruin it :P |
| 20:15:12 | PMunch | So it really should be two separate repos |
| 20:15:36 | * | Nobabs27 joined #nim |
| 20:15:47 | PMunch | And when/if we get 3.1.0 working with your auto-generate approach it would be easier to merge it into my repo |
| 20:16:18 | * | user0___ quit (Quit: user0___) |
| 20:16:44 | * | zaquest joined #nim |
| 20:18:37 | Araq | PMunch: oh yeah, wanted to ask. |
| 20:18:51 | Araq | so the 3 way diff/patch thing didn't work out? |
| 20:19:18 | PMunch | I sorta gave up on it before I tried it.. |
| 20:19:21 | Araq | zachcarter: no, it's mips vs mips64 or something |
| 20:19:30 | zachcarter | okay thanks Araq |
| 20:19:43 | PMunch | I got busy with something else and I just wanted to get the macro done |
| 20:19:43 | Araq | or maybe mips32 vs mips64 |
| 20:20:04 | zachcarter | either one works for me |
| 20:20:18 | PMunch | I might revisit it now |
| 20:20:57 | Araq | (name: "mips", intSize: 32, endian: bigEndian, floatSize: 64, bit: 32), |
| 20:21:16 | Araq | so it's mips. and 64 bit version shall be mips64 |
| 20:21:49 | Araq | platform.nim still lacks mips64 though |
| 20:29:22 | Araq | PMunch: well wxWidgets was the first wrapper I wrote with the idea of diff&patch again |
| 20:29:36 | Araq | would be sad to lose that |
| 20:30:25 | PMunch | Yeah |
| 20:30:34 | PMunch | Hmm, let's see what I have actually changed |
| 20:34:22 | PMunch | Hmm, some things are probably doable by changing the header |
| 20:36:54 | PMunch | I think most of these could be done by changing the header |
| 20:37:33 | * | Nobabs27 quit (Quit: Leaving) |
| 20:37:34 | PMunch | At least one of them (stc.nim) has a passL pragma in it though |
| 20:37:51 | PMunch | Other than that I think it's just a matter of changing a couple of lines in the headers |
| 20:47:59 | * | bjz joined #nim |
| 20:59:51 | dyce[m] | mipsel |
| 20:59:58 | * | shashlick quit (Ping timeout: 260 seconds) |
| 21:02:17 | * | zachcarter quit (Ping timeout: 260 seconds) |
| 21:02:19 | * | shashlick joined #nim |
| 21:08:11 | Araq | lol "The great thing about using a popular language is how easy it is to find packages that would do what you wanted if they actually worked." |
| 21:14:45 | * | smt quit (Ping timeout: 240 seconds) |
| 21:14:47 | PMunch | Haha, good point :P |
| 21:22:33 | * | smt joined #nim |
| 21:29:23 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 21:32:15 | * | rokups quit (Quit: Connection closed for inactivity) |
| 21:34:50 | * | smt_ joined #nim |
| 21:38:15 | * | smt quit (Ping timeout: 240 seconds) |
| 21:42:19 | dyce[m] | https://nim-lang.org/docs/system.html#lines.i,string is amazing |
| 21:44:09 | FromGitter | <Varriount> dyce[m]: Eh, I always disliked that one. Too easy to mistake it for a procedure that iterates over lines in an actual string. |
| 21:45:28 | dyce[m] | Varriount, i see, i think its because theres some huge argument whether you should use a string for a filepath vs an type/object. so both exist |
| 21:47:35 | dyce[m] | perhaps if it only operated on a File type it wouldnt be as confusing? |
| 21:49:24 | dyce[m] | but operating on a string is a great convenience vs converting to a File |
| 21:52:41 | demi- | i would like a built-in Path type |
| 21:53:01 | demi- | that used a URL instead of a string to represent location of the filesystem |
| 21:53:22 | cheatfate | demi-, and how it will works with url encoding? |
| 21:53:39 | demi- | there is no encoding involved? |
| 21:53:51 | demi- | file:// and C:\ |
| 21:54:03 | cheatfate | demi-, how you can combine url encoded path with filesystem path? |
| 21:54:15 | demi- | i guess it depends on the encoding of the system |
| 21:54:43 | demi- | cheatfate: i don't think you would, path being a type would mean it cannot be arbitrarily combined with non paths |
| 21:54:49 | * | smt_ quit (Read error: Connection reset by peer) |
| 21:54:55 | cheatfate | because dosname `C:\` is obsolete, but still using, it is all the time converted to something like \\PhysicalDrive0\ |
| 21:55:21 | demi- | the URL bit was to have it not backed as an arbitrary concat and splitting of strings |
| 21:55:52 | cheatfate | demi-, ok, what about international paths? windows uses unicode while url uses punycode... |
| 21:56:25 | demi- | :| ok nevermind i said "url" specifically |
| 21:56:32 | demi- | because clearly that isn't the word i wanted |
| 21:56:55 | demi- | "i want a non-string backed path type" |
| 21:57:39 | cheatfate | demi-, but all syscalls using string path types, so it will be converted every time for every syscall, from path type to string... |
| 21:57:39 | demi- | something like this https://pypi.python.org/pypi/pathlib/ |
| 21:59:39 | cheatfate | demi-, you can always make module which implements this :) but i think it must be implemented with `string` as default storage... otherwise it can become slowdown (allocate string and concatenate path parts) |
| 22:01:11 | FromGitter | <Varriount> C-c-c-cache! |
| 22:01:12 | demi- | :\ i might have to |
| 22:05:37 | * | zachcarter joined #nim |
| 22:07:37 | cheatfate | Varriount: cache is not always good, what if happens if you enumerating like 10,000,000 files via os.walkFiles() and you will first construct path object, then deconstruct it back to string, to just echo it to console... |
| 22:08:11 | cheatfate | so what you can cache in this situation? |
| 22:09:06 | demi- | nothing, the point of this would to enhance safety with accessing the file system |
| 22:10:12 | cheatfate | what safety? |
| 22:10:47 | cheatfate | path returned from syscall is almost 100% normal, until somebody not forged syscall |
| 22:10:47 | demi- | working with paths |
| 22:12:06 | * | flaviu quit (Ping timeout: 240 seconds) |
| 22:14:50 | * | flaviu joined #nim |
| 22:17:20 | Araq | type Path = distinct string |
| 22:17:40 | Araq | proc `&`(a, b: Path): Path = Path(a.string / b.string) |
| 22:18:05 | * | couven92 quit (Read error: Connection reset by peer) |
| 22:18:36 | Araq | I thought about this too but never tried it in practice |
| 22:19:10 | demi- | there seems to be a non-trivial amount of logic here: https://github.com/python/cpython/blob/3.6/Lib/pathlib.py |
| 22:20:47 | demi- | composing things that are not strings as strings in inherently difficult and has a bunch of weird edge-case behavior around it if you make a mistake (e.g.: file system paths and urls) |
| 22:21:47 | * | Trustable quit (Remote host closed the connection) |
| 22:24:07 | demi- | apple handles this by forcing their URL class handle things and use a supplimental components class (https://developer.apple.com/reference/foundation/nsurl and https://developer.apple.com/reference/foundation/nsurlcomponents) |
| 22:27:35 | Araq | pathlib.py seems like something I would avoid to use |
| 22:28:10 | Araq | https://github.com/python/cpython/commit/1add96f1b669436ca96dc8adf24276adea6aea4c # pretty sure my distinct string wouldn't have this bug |
| 22:28:18 | euantor | Rust has something similar in the form of std::path https://doc.rust-lang.org/1.10.0/std/path/index.html |
| 22:28:47 | euantor | I far prefer strings, they're far more readable |
| 22:29:11 | * | chemist69 quit (Ping timeout: 246 seconds) |
| 22:29:47 | demi- | C++ has a similar thing too i think |
| 22:31:26 | Araq | skimming the docs Rust pretty much uses the distinct string idea |
| 22:31:50 | Araq | it doesn't build a list that then needs to be concatenated again |
| 22:32:07 | demi- | i really don't care how it gets implemented tbh; i would like to work with paths as not-strings. that was my original point |
| 22:32:10 | * | vlad1777d quit (Remote host closed the connection) |
| 22:32:21 | Araq | yeah, I can see the merit in that |
| 22:32:34 | Araq | but don't overdesign it. |
| 22:32:38 | * | chemist69 joined #nim |
| 22:33:57 | demi- | it looks like someone already ported python's pathlib over to nim: https://github.com/achesak/nim-pythonpathlib |
| 22:35:13 | Araq | pathlib even uses multiple inheritance: class PosixPath(Path, PurePosixPath):... :-) |
| 22:37:38 | Araq | I'd copy from Rust's lib, I think. ideally from an implementation that is less than 500 lines |
| 22:38:30 | * | nsf quit (Quit: WeeChat 1.7) |
| 22:39:01 | Araq | AbsolutePath/AbsolutePath is invalid, maybe absolute vs relative should be encoded in the types too |
| 22:41:51 | demi- | if such a type was to be added to the stdlib, i'd also want to see all of the syscalls take the path type instead of strings; but i don't know how likely that would be to get in since it would be a breaking change. |
| 22:42:53 | Araq | we can sneak it in like we do for TaintedString |
| 22:43:10 | Araq | but TaintedString wasn't a success and we think about removing it again |
| 22:44:00 | Araq | in the Nim compiler AbsolutePath vs RelativePath would have prevented some bugs |
| 22:45:01 | Araq | but then that's even more tedious than just a Path type |
| 22:45:46 | demi- | ¯\_(ツ)_/¯ |
| 22:46:04 | Araq | I doubt Path alone would have prevented bugs in the compiler. it's a difficult design tradeoff |
| 22:46:15 | demi- | yeah, i can understand that |
| 22:47:03 | Araq | however, if you introduce pathlib.nim |
| 22:47:58 | Araq | you can have proc open(f: Path): File as overloads to the ones in system.nim. Nim's decoupling between types and procs helps somewhat here |
| 22:48:17 | demi- | ah, true |
| 22:49:12 | * | elrood quit (Quit: Leaving) |
| 23:00:02 | * | flaviu quit (Remote host closed the connection) |
| 23:00:49 | * | onionhammer quit (Read error: Connection reset by peer) |
| 23:02:33 | * | onionhammer joined #nim |
| 23:06:46 | * | PMunch quit (Quit: leaving) |
| 23:20:04 | * | zachcarter quit (Quit: zachcarter) |
| 23:21:19 | * | bungoman joined #nim |
| 23:22:23 | * | bungoman_ quit (Ping timeout: 246 seconds) |
| 23:42:19 | * | smt joined #nim |
| 23:50:51 | * | rauss joined #nim |
| 23:56:05 | * | zachcarter joined #nim |