| 00:00:31 | ftsf_ | any idea why this would be and how to fix it? |
| 00:08:03 | FromGitter | <Varriount> ftsf_: Can we see your code? |
| 00:09:37 | ftsf_ | proc foo() = echo "test" |
| 00:09:37 | ftsf_ | addQuitProc(foo) |
| 00:12:33 | ftsf_ | (that's all that's required to reproduce it) |
| 00:20:41 | FromGitter | <Varriount> ftsf_: It appears that the compiler isn't displaying the proper signature when it errors. |
| 00:20:57 | FromGitter | <Varriount> 'addQuitProc' expects 'proc() {.noconv.}' |
| 00:22:27 | FromGitter | <Varriount> ```proc foo() {.noconv.} = echo "test" ⏎ addQuitProc(foo)``` [https://gitter.im/nim-lang/Nim?at=59125d47c4d73f445a8ebd31] |
| 00:23:14 | ftsf_ | ahh |
| 00:23:18 | ftsf_ | not in the docs either |
| 00:23:20 | ftsf_ | but good to know |
| 00:23:33 | ftsf_ | will add an issue i guess |
| 00:23:54 | ftsf_ | thanks |
| 00:42:16 | * | Trioxin joined #nim |
| 00:42:25 | * | Jesin quit (Quit: Leaving) |
| 00:45:06 | Trioxin | What's the best way to manage a huge config file (Tens of thousands of lines)? The way I'm doing it sucks. Anytime a block of config needs to be added, it queries mysql and rewrites the whole file. I was thinking of holding the whole file in memory, appending additions, and regenerating the whole file only for deletions. Idk if I really need to keep the whole config in memory though (Like an array or list) but I don't want to query MySQL |
| 00:45:07 | Trioxin | for all the previous config, just what needs to be changed. Nim should be great for this I think for speed. |
| 01:06:11 | FromGitter | <Varriount> Trioxin: Use a database instead, and put up a frontend for modifying the configuration. |
| 01:07:00 | FromGitter | <Varriount> Or, you could go the apache/nginx route and write a turing-complete configuration language |
| 01:07:24 | FromGitter | <Varriount> We would need a better idea of what the configuration is, it's current format, etc. |
| 01:08:18 | demi- | a config file that huge sounds more like code than a configuration |
| 01:08:51 | FromGitter | <Varriount> demi-: Lissssp |
| 01:08:58 | FromGitter | <Varriount> :D |
| 01:09:19 | demi- | |
| 01:18:24 | * | SusWombat quit (Quit: Leaving) |
| 01:27:45 | * | Jesin joined #nim |
| 01:46:00 | ftsf_ | polishing up my nim game system for open sourcing =) |
| 01:59:00 | * | def-pri-pub joined #nim |
| 02:02:34 | * | chemist69 quit (Ping timeout: 255 seconds) |
| 02:16:15 | * | chemist69 joined #nim |
| 02:17:55 | * | Jesin quit (Quit: Leaving) |
| 02:44:16 | * | dddddd quit (Remote host closed the connection) |
| 03:02:45 | FromGitter | <Varriount> @Araq Any chance of merging the weird Nimscript modules back into the proper standard library modules? The duplication that's going on at the moment is really confusing. |
| 03:09:01 | * | brson joined #nim |
| 03:18:47 | enthus1ast | how i setPosition a FileStream to EOF? |
| 03:19:01 | enthus1ast | can i |
| 03:20:19 | * | def-pri-pub quit (Quit: leaving) |
| 03:23:09 | * | girvo joined #nim |
| 03:23:11 | girvo | Hey all :) |
| 03:23:36 | enthus1ast | moin |
| 03:24:03 | girvo | How do I disambiguate a pragma? "reactor" has "async", but so does the standard lib, so it's using the wrong one. {.reactor.async.} doesn't work, obviously, heh. |
| 03:24:26 | FromGitter | <Varriount> enthus1ast: Well that's the thing about a stream - it may not have an end |
| 03:25:13 | FromGitter | <Varriount> girvo: When importing from reactor, try `from reactor import async as rasync` |
| 03:25:16 | girvo | dom96: I got threadpools working with async/await, but had to use Reactor to get it to work unfortunately; from what I've seen, asyncdispatch really expects you to be using an AsyncFD for futures |
| 03:25:32 | girvo | Varriount, perfect, I'll give that a go. Couldn't remember the syntax :) |
| 03:26:03 | FromGitter | <Varriount> girvo: Isn't reactor another async lib, separate from the one in the standard library? |
| 03:26:45 | girvo | Varriout: it is, yep, built on libuv which I've got experience with; for my current usecase it will do, but long term I want to have a crack at making asyncdispatch slightly more generic in terms of it's Future impl |
| 03:27:10 | girvo | I need non-blocking threadpools with async IO for a project right now, so this will do heh |
| 03:28:08 | enthus1ast | thats the think with streams, ty Varriount |
| 03:32:07 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 03:34:53 | girvo | Varriount: import as doesn't want to work, I'm running 0.16.0 currently. Switched to latest devel instead, and it breaks with reactor *sigh* lol |
| 03:35:43 | jackv | girvo: and I use Reactor because I need UDP, which isn't included in the current asyncnet |
| 03:35:47 | girvo | Is it possible to disable {.async.}? I don't even import asyncdispatch, so I'm a bit confused as to where it's coming from |
| 03:36:45 | jackv | I think Reactor also implements that macro? |
| 03:36:58 | FromGitter | <Varriount> girvo: Is asyncdispatch being processed? The compiler output should say. |
| 03:43:20 | enthus1ast | jackv afaik is udp in asyncdispatch |
| 03:44:18 | enthus1ast | afaik sendTo |
| 03:46:00 | enthus1ast | and recvFromInto |
| 03:48:37 | * | Jesin joined #nim |
| 03:52:52 | jackv | enthus1ast: ah yeah looks like it. I was under the impression that it was still in upcoming/asyncdispatch. Seems counterintuitive that it's not part of asyncnet, doesn't it? |
| 03:53:14 | * | Serenitor joined #nim |
| 04:05:10 | * | Serenitor quit (Quit: Leaving) |
| 04:31:35 | * | zachcarter quit (Quit: zachcarter) |
| 04:41:29 | * | brson quit (Ping timeout: 272 seconds) |
| 04:42:30 | * | BennyElg quit (Remote host closed the connection) |
| 04:52:15 | * | brson joined #nim |
| 04:57:08 | * | chrisheller quit (Remote host closed the connection) |
| 04:58:12 | * | chrisheller joined #nim |
| 04:58:14 | * | chrisheller quit (Remote host closed the connection) |
| 04:58:36 | * | chrisheller joined #nim |
| 05:25:27 | * | brson quit (Quit: leaving) |
| 05:31:55 | * | xet7 quit (Quit: Leaving) |
| 05:46:46 | * | gokr joined #nim |
| 06:04:01 | * | rauss quit (Quit: WeeChat 1.7.1) |
| 06:08:53 | * | Vladar joined #nim |
| 06:11:06 | * | girvo quit (Quit: leaving) |
| 06:26:55 | * | rosshadden quit (Ping timeout: 245 seconds) |
| 06:28:58 | * | arnetheduck quit (Remote host closed the connection) |
| 06:30:04 | * | jsgrant_om quit (Ping timeout: 240 seconds) |
| 06:30:49 | * | arnetheduck joined #nim |
| 06:31:00 | * | rosshadden joined #nim |
| 06:32:56 | * | nsf joined #nim |
| 06:36:28 | * | BennyElg joined #nim |
| 06:40:40 | * | BennyElg quit (Ping timeout: 245 seconds) |
| 06:45:17 | * | BennyElg joined #nim |
| 06:51:00 | * | yglukhov joined #nim |
| 07:11:04 | * | Amun_Ra quit (Quit: さよなら) |
| 07:11:12 | * | gokr quit (Ping timeout: 258 seconds) |
| 07:12:36 | * | Amun_Ra joined #nim |
| 07:15:02 | * | gokr joined #nim |
| 07:20:19 | * | gokr quit (Read error: Connection reset by peer) |
| 07:27:04 | * | Trioxin2 joined #nim |
| 07:30:10 | * | Trioxin quit (Ping timeout: 255 seconds) |
| 07:32:47 | * | Arrrr joined #nim |
| 07:32:57 | * | Trioxin2 is now known as Trioxin |
| 07:40:05 | * | gokr joined #nim |
| 07:48:28 | * | Trioxin2 joined #nim |
| 07:48:35 | * | Trioxin quit (Disconnected by services) |
| 07:48:41 | * | Trioxin2 is now known as Trioxin |
| 07:49:46 | FromGitter | <andreaferretti> @dom96 thank you, I just installed it and everything works fine! |
| 07:50:03 | FromGitter | <andreaferretti> I opened an issue, which is just a small annoyance, nothing breaking |
| 07:50:17 | FromGitter | <andreaferretti> but I think it is wasteful to rebuild from scratch on update |
| 08:08:14 | * | BennyElg quit (Remote host closed the connection) |
| 08:12:25 | * | couven92 joined #nim |
| 08:42:37 | * | Trioxin quit (Ping timeout: 240 seconds) |
| 08:42:56 | * | Trioxin joined #nim |
| 09:04:50 | * | GustavoLapasta joined #nim |
| 09:13:47 | * | adeohluwa joined #nim |
| 09:43:29 | * | krux02 joined #nim |
| 09:56:30 | * | rosshadden quit (Ping timeout: 245 seconds) |
| 10:04:39 | * | MyMind joined #nim |
| 10:08:58 | * | BennyElg joined #nim |
| 10:13:23 | * | rosshadden joined #nim |
| 10:13:59 | * | BennyElg quit (Ping timeout: 272 seconds) |
| 10:14:49 | * | PMunch joined #nim |
| 10:18:49 | * | krux02 quit (Remote host closed the connection) |
| 10:23:52 | * | GustavoLapasta quit (Quit: Leaving) |
| 10:28:31 | * | Tiberium joined #nim |
| 10:32:54 | * | zachcarter joined #nim |
| 10:33:39 | couven92 | Is there a way to let a macro take a static array of untyped as an argument? |
| 10:34:05 | couven92 | The compiler complains that it cannot compile the macro because the argument is generic |
| 10:37:17 | FromGitter | <zacharycarter> hrm I have a nims file with a task defined in it but `nim e myfile.nims` isn't producing any output |
| 10:47:37 | PMunch | Araq, did you take a look at the newest version of codeRepr? |
| 10:48:43 | FromGitter | <zacharycarter> Does anyone know how to execute tasks defined in a nimscript file? |
| 10:51:49 | PMunch | Isn't it just "nimble <task name>"? |
| 10:52:03 | FromGitter | <zacharycarter> probably but my tasks aren't defined in a nimble ifle |
| 10:52:04 | FromGitter | <zacharycarter> file |
| 10:52:08 | FromGitter | <zacharycarter> it's a standalone nimscript file |
| 10:52:29 | PMunch | "nimble <task name> <nimscriptfile>"? |
| 10:52:33 | PMunch | Just guessing by the way :P |
| 10:52:49 | FromGitter | <zacharycarter> Error: Specified directory does not contain a .nimble file. |
| 10:53:18 | PMunch | Ah, I think your nimscript code has to be in a .nimble file for nimble to read it |
| 10:54:09 | FromGitter | <zacharycarter> I see plenty of nims files floating around though |
| 10:54:13 | FromGitter | <zacharycarter> with tasks defined in them |
| 10:55:14 | FromGitter | <zacharycarter> https://github.com/nim-lang/nim-mode/blob/04507a391fcce5689890a1d9801f13ccf965e33b/tests/syntax/test_nimscript.nims |
| 10:55:15 | FromGitter | <zacharycarter> for instance |
| 10:55:50 | FromGitter | <zacharycarter> but you may very well be right |
| 10:56:11 | PMunch | Hmm, strange |
| 10:56:27 | PMunch | You better ask dom96 I think. And the answer should be written down somewhere :P |
| 10:57:11 | FromGitter | <zacharycarter> agreed |
| 11:03:24 | FromGitter | <zacharycarter> https://nim-lang.org/0.16.0/nims.html is not too clear about this |
| 11:03:42 | * | Snircle joined #nim |
| 11:21:44 | * | kunev quit (Ping timeout: 240 seconds) |
| 11:24:28 | * | kunev joined #nim |
| 11:40:04 | * | adeohluwa quit (Quit: Connection closed for inactivity) |
| 11:46:12 | * | krux02 joined #nim |
| 11:47:37 | * | gokr quit (Ping timeout: 240 seconds) |
| 12:01:17 | dom96 | zacharycarter: IIRC you just run: nim <task_name> |
| 12:01:27 | dom96 | that's how it works for nimble too: nimble <task_name> |
| 12:04:37 | FromGitter | <zacharycarter> @dom96 hrm for some reason that's not working for me |
| 12:05:44 | FromGitter | <zacharycarter> maybe it's because I have a nim.cfg and a nims in the same folder |
| 12:08:03 | * | BennyElg joined #nim |
| 12:11:12 | demi- | i don't know how i missed it before but having the nim compiler generate a graphviz file of the dependency graph is fantastic |
| 12:12:05 | FromGitter | <zacharycarter> bleh I guess i'll keep using nake |
| 12:12:07 | FromGitter | <zacharycarter> nimscript is failing me |
| 12:12:35 | FromGitter | <zacharycarter> ahhhhh |
| 12:12:39 | FromGitter | <zacharycarter> must be named config.nims |
| 12:24:19 | ftsf_ | with a nimble module where should i put example code? |
| 12:25:05 | demi- | ftsf_: in an excluded examples folder or something similar |
| 12:25:11 | ftsf_ | ok |
| 12:25:40 | demi- | same pattern used for tests code directories, so they don't get installed with the module |
| 12:31:16 | * | yglukhov quit (Remote host closed the connection) |
| 12:35:43 | couven92 | how do I define a tuple where one of the fields is a type descriptor? |
| 12:36:31 | couven92 | `Foobar = tuple[f1: typedesc]` gives me that `typedesc is not a concrete type` |
| 12:39:50 | dom96 | couven92: I don't think that's possible |
| 12:42:44 | * | yglukhov joined #nim |
| 12:42:45 | * | yglukhov quit (Remote host closed the connection) |
| 12:47:52 | * | pie_ joined #nim |
| 13:08:08 | * | zachcarter quit (Quit: zachcarter) |
| 13:09:18 | * | BennyElg quit (Remote host closed the connection) |
| 13:11:09 | * | BennyElg joined #nim |
| 13:19:06 | * | yglukhov joined #nim |
| 13:20:08 | FromGitter | <ftsf> \o/ https://github.com/ftsf/nico |
| 13:23:28 | dom96 | Nice :D |
| 13:24:18 | FromGitter | <ftsf> feels good, got vektor using the same code now. |
| 13:24:51 | FromGitter | <ftsf> had a few vendored versions of that basecode mixed up over a few projects with variations |
| 13:26:18 | * | Vladar quit (Quit: Leaving) |
| 13:27:20 | dom96 | Quickly skimmed the code. Looks super good, one thing you're doing right is using only procedures and no methods :) |
| 13:27:39 | dom96 | Could use some modularity though, a lot of stuff is in the nico module but not a big deal |
| 13:33:50 | FromGitter | <ftsf> yeah i was wanting to separate it out |
| 13:34:04 | FromGitter | <ftsf> started but then i broke everything so i undid it |
| 13:34:37 | FromGitter | <BontaVlad> VEKTOR 2089 look awesome! |
| 13:35:05 | FromGitter | <ftsf> :3 thanks |
| 13:50:13 | * | yglukhov_ joined #nim |
| 13:52:18 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 13:52:45 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 13:58:49 | FromGitter | <ftsf> hmm that's annoying, i'm depending on stb_image, but there's two nimble modules with that name =\ |
| 14:02:06 | krux02 | I just saw that PNode has a comment field in the compiler, can I set that for debugging conditions? |
| 14:03:42 | * | rauss joined #nim |
| 14:04:44 | Araq | krux02: it's not meant for that but I guess you can misuse it for debugging |
| 14:06:04 | krux02 | yes I was just wondering if and when the node will have the comment field set |
| 14:12:45 | * | ftsf_ quit (Ping timeout: 260 seconds) |
| 14:23:20 | FromGitter | <andreaferretti> I opened a forum thread about reproducible builds |
| 14:23:21 | FromGitter | <andreaferretti> https://forum.nim-lang.org/t/2954 |
| 14:23:44 | * | BennyElg quit (Remote host closed the connection) |
| 14:23:54 | FromGitter | <andreaferretti> I think it is important that library authors do not mention `nimble install` as a way to make the library available |
| 14:23:59 | FromGitter | <andreaferretti> but I keep seeing it |
| 14:24:12 | FromGitter | <andreaferretti> the latest example being https://github.com/ftsf/nico |
| 14:24:32 | * | BennyElg joined #nim |
| 14:24:38 | FromGitter | <andreaferretti> please, add your comments, I think it is important to start a discussion |
| 14:31:44 | * | BennyElg quit (Remote host closed the connection) |
| 14:47:46 | Araq | krux02: ## doc comment sets the comment field :-) |
| 14:53:08 | Araq | andreaferretti: any remarks on nawabs? :-) |
| 14:55:05 | * | pie_ quit (Ping timeout: 260 seconds) |
| 15:03:24 | Tiberium | #offtopic: is this a good comparasion? https://svnvsgit.com/ |
| 15:07:42 | * | vlad1777d joined #nim |
| 15:12:01 | * | pie_ joined #nim |
| 15:24:36 | flyx | Tiberium: a) use #nim-offtopic b) this is not a good comparison, more a commentary of other comparisons. moreover, starting a „facts“ article with a claim in the first sentence which is never sourced or backed with any data or examples makes for a very poor impression. |
| 15:28:52 | * | gokr joined #nim |
| 15:33:41 | * | zachcarter joined #nim |
| 15:35:07 | * | gokr quit (Ping timeout: 264 seconds) |
| 15:46:48 | couven92 | hmm... overloading a macro doen't work= |
| 15:46:50 | couven92 | ? |
| 15:49:19 | * | Vladar joined #nim |
| 15:51:25 | * | adeohluwa joined #nim |
| 15:53:38 | * | brson joined #nim |
| 15:54:26 | Araq | it does but you need to read the manual carefully about 'untyped' parameters |
| 15:54:49 | yglukhov_ | Hey guys, what do you think: https://github.com/yglukhov/better-nimble-doc/blob/master/README.md |
| 15:55:14 | couven92 | okay... that's probably my problem... I have multiple untyped params here... But if I suffix each overload it works just fine |
| 15:57:44 | couven92 | Araq, is there a way to get the macros as pragmas thing to send arguments as well? the example in the manual doesn't show how or if that is possible |
| 15:58:19 | Araq | proc foo() {.annotate: "value".} = ... |
| 15:58:30 | Araq | macro annoate(value: string, body: untyped) = ... |
| 15:59:23 | couven92 | and `proc foo() {.annotate: ["lots", "of", "arguments"].}` for more than one? |
| 16:01:37 | Araq | yglukhov_: TL;DR, show us the diff to the old readme perhaps? |
| 16:01:42 | Araq | couven92: yup |
| 16:01:56 | yglukhov_ | Araq: added the link to the diff at the front page of the repo |
| 16:02:13 | yglukhov_ | https://github.com/yglukhov/better-nimble-doc/compare/8cc157779d6abccc9e47c5bcade47053df780523...master |
| 16:02:25 | couven92 | thx, although... I need to name my args for readability... so the usual syntax is problably better in my case anyways... :/ |
| 16:02:32 | * | undefined92 joined #nim |
| 16:03:00 | undefined92 | Is there a way to require at least one element when taking a seq, openArray or varargs? |
| 16:05:14 | Tiberium | undefined92, assert maybe? |
| 16:05:34 | Tiberium | assert len(seq) > 0 is the simplest way probably |
| 16:06:35 | Araq | couven92: pass a named tuple constructor? |
| 16:07:45 | undefined92 | I guess i take one argument + additional varargs and append during runtime. That way i atleast get compiletime guarantees. |
| 16:12:29 | * | undefined92 quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 16:14:47 | dom96 | One important thing to note is that .lock files will only be created for binary packages. |
| 16:15:50 | dom96 | Changing what `install` does seems too disruptive. |
| 16:16:37 | yglukhov_ | dom96: i would rather say `lock.files` of the dependencies are ignored. |
| 16:17:11 | dom96 | okay, but then why have them at all? |
| 16:21:18 | couven92 | uhm, since we have the very useful "is declared but not used" hint, can we have that for parameters as well? |
| 16:21:23 | yglukhov_ | because they may be needed by package authors. or if a package is both bin and lib. in any case decision on whether to create the lockfile or not requires additional logic and time to implement, so why bother |
| 16:21:44 | yglukhov_ | dom96: its always easier to ignore something =) |
| 16:22:53 | dom96 | because checking is easy |
| 16:23:30 | dom96 | if pkgInfo.bin.len > 0: echo("It's a binary package") |
| 16:23:56 | yglukhov_ | dom96: install could do the old thing with `-g` flag or smth. in this readme I'm not trying to keep backward compatibility by any means. I'm trying to figure out an ideal interface. And then, once its done we can think about compat issues |
| 16:24:10 | dom96 | ok |
| 16:25:03 | yglukhov_ | dom96: well consider my case: i've got a repo with my application. |
| 16:26:00 | yglukhov_ | dom96: i want to make reproducible builds, but the app is not `bin`, because its build process is much more sophisticated than just running nim with some cfg |
| 16:27:10 | dom96 | But in that case you won't be able to use Nimble to do the build and Nim will have no clue about the .lock file. |
| 16:27:11 | yglukhov_ | dom96: also to me the overall architecture of nimble would look more modular if it doesnt force its way of building. |
| 16:27:30 | yglukhov_ | dom96: exactly! and i have an answer for that as well |
| 16:27:53 | dom96 | I can already imagine some solutions... yay, more complexity :\ |
| 16:28:04 | yglukhov_ | dom96: actually much less. |
| 16:28:30 | dom96 | Okay, i'll let you finish your changes :) |
| 16:29:02 | yglukhov_ | dom96: the solution is dead simple. introduce `nimble paths` command. it will output raw list of absolute paths to the right package deps. |
| 16:30:20 | yglukhov_ | nim will just call `nimble paths` instead all of its current sophisticated logic that is trying to look as it knows how nimble works =) |
| 16:30:34 | yglukhov_ | Araq ping as well |
| 16:30:38 | FromGitter | <stisa> yglukhov_ I'm a little confused about project structure, there seem to be 3 different recommended versions? Is there no way to choose one? |
| 16:30:59 | FromGitter | <stisa> actually 4 versions if you count hybrid I guess |
| 16:31:17 | dom96 | That second sentence took me by surprise |
| 16:32:10 | dom96 | So presumably you just want `nimble c ...` to be the same as `nim c ...` |
| 16:32:13 | yglukhov_ | stisa: i'm not sure i understand your question. which versions are you talking about |
| 16:32:18 | * | Trustable joined #nim |
| 16:33:50 | yglukhov_ | dom96: well.. i haven't thought from this perspective, but... yeah... |
| 16:34:27 | FromGitter | <stisa> sorry, I meant ways to structure a project, I think we should try to only recommend one |
| 16:34:51 | dom96 | stisa: Pretty sure that's in the original nimble readme too. |
| 16:34:59 | * | Matthias247 joined #nim |
| 16:35:09 | dom96 | stisa: And the multiple ways are warranted. Not every project is the same. |
| 16:35:12 | demi- | this is neat https://www.visualstudio.com/vs/visual-studio-mac/ |
| 16:35:20 | demi- | looks like they bought MSBuild to mac |
| 16:35:29 | yglukhov_ | stisa: ok. sorry, but I'm not trying to change/discuss package structure here yet. I've got my opinion about it, but at this point i just don't want to create more chaos =)) |
| 16:36:24 | couven92 | yglukhov_, chaos is good! I'm game! :D |
| 16:36:27 | dom96 | yglukhov_: It would be helpful to see an example of a project that cannot be handled by Nimble's build system. |
| 16:39:18 | * | arnetheduck quit (Ping timeout: 264 seconds) |
| 16:41:46 | yglukhov_ | dom96: can nimble file include modules from the dependencies that are not installed yet? |
| 16:42:17 | dom96 | No, how could it? |
| 16:42:35 | * | BennyElg joined #nim |
| 16:43:44 | yglukhov_ | dom96: well how do i reproduce this logic with nimble build? currently i import it to the nakefile: https://github.com/yglukhov/nimx/blob/master/nimx/naketools.nim |
| 16:44:25 | yglukhov_ | dom96: i mean, its a lot of logic that can not be placed into the nimble file itself, it should be imported. |
| 16:45:04 | dom96 | Well, nimx's nimble file can certainly import nimx/naketools.nim. |
| 16:45:13 | dom96 | I thought you meant another dependency's |
| 16:45:24 | yglukhov_ | dom96: im using this nakefile in a lot of projects |
| 16:45:27 | yglukhov_ | * import |
| 16:45:44 | demi- | why are you wrapping these things |
| 16:46:22 | yglukhov_ | dom96: also heres another thing which i don't like badly about using nimscript as a build script |
| 16:46:26 | demi- | yglukhov_: that seems horrific to try to maintain |
| 16:46:30 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 16:47:32 | dom96 | I see. Hrm. |
| 16:48:32 | yglukhov_ | dom96: e.g. some time ago we've done image packing lib, which does lots of raster processing, intended to be used on the build phase. with nakefile i just import it and use it. with nims it would be just dead slow. |
| 16:49:01 | yglukhov_ | dom96: with nakefile i just type `nake js` and it runs jester inside, and starts the browser using nim api. |
| 16:49:36 | dom96 | For things like this you should be able to call out to nakefile etc. |
| 16:49:40 | yglukhov_ | dom96: with nakefile, i can use system keychain api on macos to verify that i have a valid cert to sign ios build |
| 16:49:50 | dom96 | But I don't think your overhaul is necessary. |
| 16:50:06 | dom96 | Just a case of exposing these paths inside the .nimble file to tasks, no? |
| 16:50:44 | demi- | yglukhov_: that should be the job of running `codesign`, not of some nimscript code |
| 16:50:59 | yglukhov_ | dom96: i could, but why? what is the advantage of concatenating two tasks into one (dependency management + task runner) if we could easily separate those from one another. also making nim c consistent and reproducible. |
| 16:51:54 | yglukhov_ | dom96, demi-, i want to parse/modify info.plist of a bundle, and for that i might want to use a lib that is wrapped around c lib, which is native |
| 16:52:31 | demi- | you shouldn't be modifying the infoplist once it is in a bundle, you should be doing it beforehand |
| 16:52:45 | dom96 | Because that is the whole point of turning .nimble files into nimscript files, isn't it? |
| 16:52:48 | demi- | which you can do natively using the xml module in nim |
| 16:54:21 | demi- | the dependency manager shouldn't also be doing build steps unless there is an integration requirement, which i don't think nim has unless you plan on using Xcode or something to build the code |
| 16:55:31 | demi- | looking at the naketools.nim file you link, i see a lot of fragile behavior, especially for osx, and i'm not sure why you would want this as part of a dep/package manager |
| 16:55:59 | * | nsf quit (Quit: WeeChat 1.7.1) |
| 16:56:02 | yglukhov_ | dom96: not at all. nimscript is much more useful than ini, because it is more expressive. you can have constants like const myBranchNameIWantToUseForAFamilyOfPrivateSubprojects, and other useful cases, really. |
| 16:56:17 | yglukhov_ | but nimscript obviously has its limitations |
| 16:56:23 | yglukhov_ | it cant call native code |
| 16:56:48 | yglukhov_ | it cant do networking |
| 16:56:49 | dom96 | But you can, you have the ability to execute external processes. That's all you need. |
| 16:56:52 | yglukhov_ | it is slow |
| 16:57:29 | yglukhov_ | dom96: but why would i bother writing and maintaining separate tools to be those externals? |
| 16:57:53 | yglukhov_ | if i can just call a proc from a nakefile and thats it |
| 16:57:59 | dom96 | you're already maintaining a nake file, isn't that an external tool? |
| 16:58:01 | yglukhov_ | no strings attached |
| 16:58:21 | demi- | dom96: i agree |
| 16:58:37 | yglukhov_ | dom96, no because i don't have to build it. |
| 16:59:12 | dom96 | Okay, maybe we should step back. |
| 16:59:35 | dom96 | Are you happy with your current setup? I guess the answer is no, so what would you like to see? |
| 17:01:17 | * | gokr joined #nim |
| 17:01:37 | yglukhov_ | dom96: I want reproducible builds and tools with consistent user experience. |
| 17:02:27 | yglukhov_ | dom96: also i don't want any restrictions. |
| 17:03:09 | demi- | why cannot you accomplish this with the compile.json that nim produces plus something like a compilation database from clang? |
| 17:04:28 | yglukhov_ | demi-: which "this" are you talking about? |
| 17:04:48 | demi- | having reproducible builds and tools |
| 17:05:15 | demi- | both of those things i mentioned produce a record of what was done to produce output, thus could be used to recreate a build the exact same way |
| 17:06:01 | yglukhov_ | demi-: ok, i think we misunderstood each other, and have to define what "reproducible build" is. |
| 17:06:14 | dom96 | yglukhov_: Alright, those are goals which are a bit abstract to me. There are many ways to accomplish them and we both have different ideas of how they can be accomplished. |
| 17:06:16 | demi- | ok, what did you mean by that? |
| 17:07:22 | dom96 | One concrete question I have in mind is what is (and should be) the point of entry for building your software? |
| 17:07:33 | dom96 | Is it nake? |
| 17:07:48 | yglukhov_ | demi-: by reproducible build i mean reproducible dependency tree. like ruby bundle, cargo toml, nodejs npm does. does that make sense? |
| 17:07:57 | couven92 | Do we have sth like the __LINE__ preprocessor in Nim? :O |
| 17:08:17 | demi- | ah i see, so you want a lock file or something that registers the versions of the dependencies to use |
| 17:11:14 | yglukhov_ | dom96: I personaly prefer nake for the reasons above. but nake is a task runner. it is not a build system. my nimx.naketools on the other hand is kinda a build system, but thats another story. |
| 17:11:35 | yglukhov_ | demi-: exaclty! |
| 17:12:11 | dom96 | yglukhov_: Sure, but to me that already creates an inconsistency. Nimble needs to know how to build your software, and so you need to tell it. |
| 17:12:19 | demi- | yglukhov_: ok i get you, that is something that nimble should have anyway; so you have a .nimble file that says it wants foo > 0.1, and ends up installing 0.2.1, it should record that in a lock file somewhere |
| 17:12:48 | yglukhov_ | demi-: correct. |
| 17:12:59 | demi- | i am 1000% in agreement about that |
| 17:13:10 | dom96 | Yes, and that is on my roadmap. |
| 17:13:32 | demi- | that is separate from any other build system stuff tho |
| 17:13:43 | yglukhov_ | dom96: "Nimble needs to know how to build your software" why does it? |
| 17:14:07 | yglukhov_ | demi-: so now we're on the page =)) |
| 17:14:25 | demi- | |
| 17:14:32 | dom96 | Two reasons: 1) Consistency: every package should be buildable via `nimble build` 2) Nimble needs to know how to build packages so that it can install them. |
| 17:15:10 | demi- | dom96: my understanding of lock files is that if they exist alongside the dep file, it should be used instead of whatever is declared in the dep file |
| 17:15:11 | yglukhov_ | 1) why? |
| 17:15:16 | demi- | and use strictly those versions |
| 17:15:27 | dom96 | demi-: indeed |
| 17:15:41 | demi- | i believe that is what yglukhov_ is requesting to have |
| 17:15:56 | yglukhov_ | 2) i've got a game project that is an app bundle which is 10gb big. why the heck would i want to install it to nimble/bin? |
| 17:16:32 | dom96 | Okay, perhaps you don't and never will, but you said yourself that you want consistent tooling. |
| 17:16:56 | demi- | yglukhov_: wouldn't you want to `nimble build` and then install the binary in a specific directory using a post-build task? |
| 17:18:03 | dom96 | if you really just want Nimble for dependency management then that's fine. We can introduce the ``nimble paths`` command and then you can use it in your build script/nakefile |
| 17:18:44 | dom96 | But here is what I imagined when you mentioned it: execCmd("nim c $1 foo.nim" % [execCmd("nimble paths")] # (Simplified example) |
| 17:19:44 | yglukhov_ | dom96: 1st priority: in no case the tooling should stay in my way of doing things. 2nd: if it does for its own good reasons, it should be replaceable in the "ecosystem" meaning. |
| 17:21:44 | yglukhov_ | tooling should be hackable, kinda =) |
| 17:21:52 | yglukhov_ | and modular |
| 17:23:08 | dom96 | yes, it should be. But you're suggesting that Nim should call Nimble directly, when in some cases Nimble calls Nim... that sounds like a recipe for a disaster. |
| 17:24:56 | yglukhov_ | now a few words regarding consistency. i think it would be more consistent for jester to be only dependency manager. an outstanding dependency manager. this way, nimble will never call to nim. currently nim knows about nimble packages. so the dependency is already cyclic. |
| 17:26:05 | yglukhov_ | but we can break this cycle and make nim behave consistently whether it is called from other build tools or on its own. |
| 17:28:35 | yglukhov_ | think of the advantages. the only interface between nim and nimble that you will have to maintain is `nimble paths`. want to change nimble behavior based on env var? go ahead! want to change package dir with env var? no problem. nim doesn't care. it will just listen to what `nimble paths` tell. |
| 17:29:13 | yglukhov_ | no need to synchronize nim/nimble releases. dead simple interface for all times! |
| 17:31:00 | yglukhov_ | ok, sorry, but i have to leave for an hour. would be nice to continue our discussion. |
| 17:31:57 | * | yglukhov_ quit (Remote host closed the connection) |
| 17:32:43 | * | Vladar quit (Quit: Leaving) |
| 17:33:32 | * | MyMind quit (Ping timeout: 255 seconds) |
| 17:34:44 | * | gokr quit (Ping timeout: 240 seconds) |
| 17:35:20 | * | yglukhov_ joined #nim |
| 17:39:25 | * | yglukhov_ quit (Ping timeout: 245 seconds) |
| 17:40:44 | * | PMunch quit (Quit: leaving) |
| 17:41:14 | * | couven92 quit (Read error: Connection reset by peer) |
| 17:42:34 | * | yglukhov joined #nim |
| 17:47:17 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 18:03:23 | * | krux02 quit (Remote host closed the connection) |
| 18:05:38 | * | PMunch joined #nim |
| 18:11:12 | * | yglukhov joined #nim |
| 18:16:51 | * | yglukhov quit (Remote host closed the connection) |
| 18:19:15 | * | libman joined #nim |
| 18:24:31 | * | yglukhov joined #nim |
| 18:27:54 | * | nsf joined #nim |
| 18:29:25 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 18:34:58 | * | jsgrant_om joined #nim |
| 19:22:29 | * | Arrrr quit (Quit: Leaving.) |
| 19:22:37 | * | jsgrant_om quit (Quit: Peace Peeps. o/ If you need me asap, message me at msg(at)jsgrant.io & I'll try to get back to you within 24 hours.) |
| 19:24:22 | * | jsgrant_om joined #nim |
| 19:29:00 | * | yglukhov joined #nim |
| 19:46:15 | yglukhov | dom96, Araq: so what do you think? does my point make sense? |
| 19:49:15 | demi- | i don't think `nim` (the compiler) should know about `.nimble` packages, that seems bad |
| 19:49:31 | * | Matthias247 joined #nim |
| 19:49:53 | * | Tiberium quit (Quit: Leaving) |
| 19:50:06 | yglukhov | demi-: but now it does |
| 19:50:11 | demi- | :( |
| 19:50:29 | demi- | is this for linking modules? |
| 19:51:26 | yglukhov | package search paths. but my point is that nim should only call once to `nimble paths` command. this way nim would know nothing about how nimble packages are organized. |
| 19:53:12 | demi- | i think that would be a step in the right direction, i would look at how this gets handled for C, where would have to define those for the compiler (sure there are default, and no reason why existing default couldn't be kept) but the compiler shouldn't be calling back into the dependency manager for that info |
| 19:54:37 | * | Tiberium joined #nim |
| 19:58:48 | demi- | this should probably be defined by an environment variable or something that gets shared between nim compiler and nimble |
| 20:00:02 | yglukhov | hrm. maybe you're right. |
| 20:00:16 | demi- | some managers put dependencies in place along-side code to get loaded that way, which is another alternative |
| 20:01:04 | * | Tiberium quit (Remote host closed the connection) |
| 20:01:14 | demi- | modern c compilers handle some of this by handling defaults of searching `/usr/include` and `/usr/lib` for headers and libraries respectively |
| 20:01:47 | demi- | so nim would need something similar or define via an env-var |
| 20:03:00 | * | Tiberium joined #nim |
| 20:05:38 | * | couven92 joined #nim |
| 20:05:47 | * | Ven joined #nim |
| 20:06:11 | * | Ven is now known as Guest53690 |
| 20:13:51 | * | yglukhov quit (Remote host closed the connection) |
| 20:14:06 | dom96 | huh? I thought the idea is that `nimble paths` is different for each package, how could an environment variable work for this case? |
| 20:23:41 | * | Trioxin2 joined #nim |
| 20:24:33 | * | Tiberium quit (Remote host closed the connection) |
| 20:27:34 | * | Trioxin quit (Ping timeout: 246 seconds) |
| 20:28:01 | demi- | you would need an env-var to define the path to look for packages in |
| 20:28:06 | * | Snircle joined #nim |
| 20:30:27 | dom96 | It's already defined, and not using an env var. |
| 20:30:36 | dom96 | It's defined in Nim's config file. |
| 20:32:56 | demi- | i think what is wanted is to have nimble deterministically select versions of the libraries to build against, and if the nim compiler doesn't have to call into nimble to work out where those are, then everything is fine? |
| 20:33:17 | euantor | dom96: regarding your PR against my recaptcha lib, are we expecting devel to release soon or shall I merge into a devel branch until then? |
| 20:34:12 | dom96 | It should be soon, but you never know :) |
| 20:37:12 | demi- | dom96: i think part of the problem is that there isn't a build system that isn't packaged up with something else so it is a bit murky as to who and how this gets done |
| 20:37:31 | euantor | I'll merge it to a devel branch then once I get to a computer |
| 20:41:06 | * | rauss quit (Quit: WeeChat 1.7.1) |
| 20:43:31 | * | zachcarter quit (Quit: zachcarter) |
| 20:59:32 | * | Guest53690 quit (Ping timeout: 260 seconds) |
| 21:00:07 | * | Ven joined #nim |
| 21:00:32 | * | Ven is now known as Guest11399 |
| 21:01:10 | * | adeohluwa quit (Quit: Connection closed for inactivity) |
| 21:06:25 | euantor | Merged into a new level branch, thanks :) |
| 21:09:12 | dom96 | euantor: thanks :) |
| 21:12:38 | dom96 | hrm, odd, seems Nimble has a bug when installing a specific branch. |
| 21:13:03 | euantor | yay! |
| 21:13:19 | * | gokr joined #nim |
| 21:29:28 | * | Trustable quit (Remote host closed the connection) |
| 21:31:57 | * | Guest11399 quit (Ping timeout: 268 seconds) |
| 21:34:08 | * | Ven_ joined #nim |
| 21:34:31 | * | Sentreen quit (Ping timeout: 264 seconds) |
| 21:38:52 | * | Ven_ quit (Ping timeout: 255 seconds) |
| 21:41:31 | dom96 | We now have recaptcha :) |
| 21:41:56 | dom96 | oh, right, I need to setup an email server |
| 21:47:26 | * | Sentreen joined #nim |
| 21:58:13 | * | zachcarter joined #nim |
| 22:20:44 | federico3 | is nimble cloning using --depth 1 ? Looks like it's doing a full clone |
| 22:27:58 | * | gokr quit (Ping timeout: 246 seconds) |
| 22:31:35 | * | Trioxin2 is now known as Trioxin |
| 22:37:08 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 22:41:21 | * | couven92 quit (Quit: Client Disconnecting) |
| 22:46:02 | dom96 | ugh "Free accounts are for test purposes only. Please upgrade or add the address to authorized recipients in Account Settings." |
| 22:53:21 | * | pie_ quit (Ping timeout: 272 seconds) |
| 22:56:16 | * | rauss joined #nim |
| 23:01:01 | * | nsf quit (Quit: WeeChat 1.7.1) |
| 23:10:52 | FromGitter | <Varriount> dom96: What site is this? |
| 23:10:58 | dom96 | forum |
| 23:11:26 | FromGitter | <Varriount> The forum requires paid accounts? |
| 23:12:57 | dom96 | I tried to use mailgun for mail sending |
| 23:29:00 | enthus1ast | can i asynchronously call an shell command and await the return code somehow? or do i have to do this with a process? |
| 23:29:49 | enthus1ast | i have to admit that i struggle with the async docs a little bit : / |
| 23:35:06 | dom96 | afraid not, you'll need to create a new thread |
| 23:35:46 | * | PMunch quit (Quit: leaving) |
| 23:40:22 | enthus1ast | whould it make sense to write a async proc that polls the termination state of a process? |
| 23:43:35 | dom96 | that would work but wouldn't be very efficient |
| 23:52:51 | * | adeohluwa joined #nim |