| 00:06:51 | * | aziz quit (Remote host closed the connection) |
| 00:09:44 | * | brson joined #nim |
| 00:20:35 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 00:21:19 | * | vendethiel joined #nim |
| 00:21:30 | * | fedons joined #nim |
| 00:27:13 | * | desophos joined #nim |
| 00:59:53 | NimBot | nim-lang/Nim new-ll b3600a0 Andreas Rumpf [+0 ±1 -0]: compute LL before the other transformations as that should produce more efficient code for closure iterators |
| 00:59:53 | NimBot | nim-lang/Nim new-ll c12c41c Andreas Rumpf [+0 ±1 -0]: made indirectAccess slightly more efficient |
| 00:59:53 | NimBot | nim-lang/Nim new-ll 57149a4 Andreas Rumpf [+0 ±1 -0]: up references work |
| 00:59:53 | NimBot | nim-lang/Nim new-ll 870b037 Andreas Rumpf [+0 ±1 -0]: bootstrapping works again |
| 01:02:16 | * | brson quit (Quit: leaving) |
| 01:02:44 | * | vendethiel quit (Ping timeout: 276 seconds) |
| 01:17:37 | Araq_ | somebody might want to test boot -d:release of the new-ll branch against devel |
| 01:18:04 | Araq_ | I suspect compile times improved measurably for new-ll but I'm busy with making new-ll actually work |
| 01:21:48 | * | bpr joined #nim |
| 01:22:09 | * | fedons quit (Quit: This computer has gone to sleep) |
| 01:28:39 | bpr | I just successfully compiled Nim from the new-ll branch on OS X 10.10.5. |
| 01:37:14 | * | jaco60 quit (Ping timeout: 250 seconds) |
| 01:43:06 | Araq_ | well? |
| 01:44:51 | NimBot | nim-lang/Nim new-ll 5c9332c Andreas Rumpf [+0 ±1 -0]: fixes closure generation when only paramters are captured |
| 01:55:29 | bpr | I haven't run many tests. I tried compiling the 'OO as method-suite in object/tuple' example I posted to the forum, and now the generated C code causes a failure in clang. |
| 01:58:04 | bpr | Same issue with 5c9332c that you just released. |
| 03:41:51 | * | kniteli joined #nim |
| 04:08:31 | * | Demon_Fox quit (Quit: Leaving) |
| 04:08:44 | * | cyraxjoe quit (Read error: Connection reset by peer) |
| 04:08:44 | * | cyraxjoe_ joined #nim |
| 04:22:57 | * | brson joined #nim |
| 04:26:12 | * | brson quit (Client Quit) |
| 04:26:41 | * | desophos_ joined #nim |
| 04:31:23 | * | desophos_ quit (Ping timeout: 264 seconds) |
| 04:54:31 | * | vendethiel joined #nim |
| 05:12:03 | * | bpr quit (Ping timeout: 252 seconds) |
| 05:17:39 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 05:50:53 | * | darkf joined #nim |
| 07:05:34 | * | dv- quit (Ping timeout: 245 seconds) |
| 07:30:40 | * | kniteli left #nim ("Leaving") |
| 08:03:47 | * | fedons joined #nim |
| 08:07:05 | * | yglukhov joined #nim |
| 08:30:41 | * | sepisoad joined #nim |
| 08:36:13 | * | desophos quit (Read error: Connection reset by peer) |
| 08:51:38 | * | fedons quit (Quit: This computer has gone to sleep) |
| 08:54:47 | * | fedons joined #nim |
| 08:56:12 | * | fedons quit (Client Quit) |
| 08:57:27 | yglukhov | dom96: can i import a module (which is a dependency) into a nimble file? |
| 09:04:07 | sepisoad | can we use nimscript instead of json/xml config file, i mean after compiling the app |
| 09:29:35 | * | BitPuffin|osx quit (Ping timeout: 260 seconds) |
| 09:36:21 | * | desophos joined #nim |
| 09:40:55 | * | desophos quit (Ping timeout: 265 seconds) |
| 09:54:26 | * | sepisoad quit (Ping timeout: 276 seconds) |
| 10:00:49 | * | yglukhov_ joined #nim |
| 10:02:48 | * | yglukho__ joined #nim |
| 10:02:48 | * | yglukhov_ quit (Read error: Connection reset by peer) |
| 10:04:15 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 10:05:02 | * | yglukhov joined #nim |
| 10:05:03 | * | yglukho__ quit (Read error: Connection reset by peer) |
| 10:17:18 | Araq_ | could not import: sqlite3_column_table_name |
| 10:17:34 | Araq_ | hrm, is that not always available? -.- |
| 10:28:01 | * | jaco60 joined #nim |
| 10:29:35 | * | yglukhov quit (Ping timeout: 264 seconds) |
| 11:06:06 | * | vendethiel joined #nim |
| 11:06:52 | * | sepisoad joined #nim |
| 11:17:27 | dom96 | yglukhov: You should be able to. |
| 11:28:21 | dom96 | Araq_: think implementing something similar to https://dlang.org/spec/memory-safe-d.html using the effect system in Nim would be doable? |
| 11:28:48 | dom96 | I think the effect system would need some extensions (which are already needed anyway) |
| 11:30:44 | * | gokr joined #nim |
| 11:36:58 | * | girvo joined #nim |
| 11:37:01 | girvo | Hey all :) |
| 11:44:16 | * | sepisoad quit (Ping timeout: 276 seconds) |
| 11:57:27 | * | sepisoad joined #nim |
| 12:03:38 | Araq_ | dom96: I already explained why it's pointless |
| 12:03:58 | Araq_ | the point of an effect system is to restrict something |
| 12:04:27 | dom96 | Araq_: Oh. I think I recall that... vaguely, sorry. |
| 12:04:31 | Araq_ | and the transitions from unsafe->safe and safe->unsafe both have to be possible |
| 12:04:44 | Araq_ | which means there is not much to restrict here |
| 12:04:48 | dom96 | hey girvo! |
| 12:04:56 | Araq_ | you can of course come up with all sort of rules for this |
| 12:05:12 | Araq_ | but we have enough complexity in the language already |
| 12:05:22 | Araq_ | and the effect system that we have is already under-used |
| 12:05:29 | dom96 | I think the idea is to have such rules. i.e. the transitions only allowed inside a @trusted (like in D) |
| 12:05:35 | * | bigfondue quit (Ping timeout: 264 seconds) |
| 12:05:53 | dom96 | I personally find the effect system under-developed |
| 12:06:11 | dom96 | But maybe I need to use it |
| 12:06:34 | Araq_ | well your code essentially says "fuck you, effect system" everywhere |
| 12:06:48 | Araq_ | you might want to find out why that is :P |
| 12:06:48 | * | bigfondue joined #nim |
| 12:06:59 | dom96 | Yeah. I know. |
| 12:07:12 | Araq_ | and what it would take to fix this via a more elaborate effect system |
| 12:07:46 | Araq_ | anyway, why does my tester fail on mac os x? |
| 12:07:58 | dom96 | So that's a "No" to a safe subset of Nim or a "No" to a safe subset of Nim (implemented using effect system)? |
| 12:08:07 | dom96 | or "no" to both? |
| 12:08:30 | Araq_ | we have a safe subset and the manual is clear about it |
| 12:08:40 | Araq_ | and it's kind of enforced by the JS backend anyway |
| 12:08:49 | Araq_ | so it's not some theoretical thing |
| 12:09:37 | Araq_ | and the unsafe features are all done by keywords |
| 12:10:15 | Araq_ | but *shrug*, fine let's rename 'cast' to 'unsafe cast' and 'addr' to 'unsafe addr' and 'ptr' to 'unsafe ptr' in order to please the people coming from Rust |
| 12:10:30 | Araq_ | which for some reason can learn Rust but not read a language manual ... |
| 12:12:04 | dom96 | I think the idea is to have a single keyword which makes unsafe features acceptable by the compiler |
| 12:12:27 | dom96 | instead of needing to analyse the full procedure to check for 'addr', 'cast' and 'ptr' |
| 12:12:59 | Araq_ | so? what kind of analysis can deal with 1 keyword but not with 3? |
| 12:13:18 | Araq_ | and do we want to base our language on that kind of analysis technology? |
| 12:14:19 | Araq_ | Stop designing programming languages for reddit. |
| 12:15:33 | dom96 | okay |
| 12:16:18 | * | Jesin quit (Quit: Leaving) |
| 12:17:47 | Araq_ | what we could easily do is to have a C#-inspired {.unsafe: on|off} that is required to use 'cast' et al directly |
| 12:18:18 | Araq_ | Modula 3 took this approach with its 'unsafe/safe' modules |
| 12:18:40 | dom96 | That would be cool |
| 12:18:48 | Araq_ | but it doesn't take an effect system and IME too many Modula 3 modules started with 'unsafe' to make this worthwhile |
| 12:19:33 | Araq_ | but hey, what do I know about language design ... :P |
| 12:20:46 | dom96 | You're right as always. It's HN though not Reddit :) |
| 12:21:26 | dom96 | https://news.ycombinator.com/item?id=10804486 |
| 12:21:54 | Araq_ | just link them to the IRC logs :P |
| 12:22:05 | Araq_ | I dunno why hacker news doesn't do this already anyway |
| 12:22:24 | dom96 | I already replied |
| 12:22:32 | Araq_ | Nim's IRC logs are the only trustable source of computing technology |
| 12:22:36 | dom96 | hah |
| 12:22:43 | dom96 | I need to improve the IRC logs to make the timestamps linkable |
| 12:22:59 | dom96 | Anyway |
| 12:23:04 | Araq_ | so ... |
| 12:23:07 | dom96 | Back to more realistic issues |
| 12:23:08 | dom96 | https://github.com/nim-lang/nimble/issues/178#issue-124094700 |
| 12:23:24 | dom96 | Any ideas why --path:"$nim" doesn't work with nim-0.12.0.tar.xz package? |
| 12:23:41 | dom96 | Maybe it's a devel addition to Nim? |
| 12:23:48 | Araq_ | anyway, why does my tester fail on mac os x? |
| 12:24:09 | dom96 | I'll look into it for you |
| 12:24:26 | Araq_ | oh it doesn't |
| 12:24:38 | Araq_ | but somebody added debugging output to dlopen yay |
| 12:24:40 | Araq_ | ... |
| 12:25:28 | dom96 | oh? |
| 12:28:04 | dom96 | so what about my question? |
| 12:28:49 | Araq_ | --path:"$nim" doesn't work because it has no meaning when install it to /usr/bin ? |
| 12:29:08 | Araq_ | I don't think there have been any changes to its behaviour but I could be wrong |
| 12:29:18 | dom96 | I don't think that's what the user did |
| 12:31:28 | dom96 | Good news is that with NimScript support I will be able to detect if the compiler sources are present |
| 12:31:35 | dom96 | and hopefully give a nice error if they aren't :) |
| 12:33:05 | * | sepisoad quit (Read error: Connection reset by peer) |
| 12:42:34 | * | yglukhov joined #nim |
| 12:44:36 | dom96 | yglukhov: seen my message? |
| 12:55:38 | yglukhov | dom96: yep, ill try, thanks. But will not evaluation of nimble file fail when the dependency is not installed yet? |
| 12:56:36 | dom96 | Damn. True. |
| 12:56:48 | dom96 | I haven't thought about it much yet |
| 12:58:52 | yglukhov | dom96: since you don't want to allow tasks to be called manually, maybe its good to do when defined(Task_taskName) inside a task template. Then you can do such imports in the tasks. We can import in proc scope, right? |
| 12:59:27 | dom96 | I don't mind if you call tasks manually. Never said I don't want to allow it! |
| 12:59:46 | dom96 | That would work, but we would need a runtime import keyword. |
| 13:00:18 | yglukhov | yeah, you just argued that its not needed ;) and i mostly agree in fact |
| 13:00:21 | dom96 | using `import foo` in proc scope would still import it before the script is evaluated I think |
| 13:00:47 | yglukhov | not if it's under when defined(Task_taskName) |
| 13:01:33 | yglukhov | and nimble would then defined appropriate Task_* before evaluating the script for a specific task |
| 13:02:42 | dom96 | hrm |
| 13:02:50 | dom96 | that would work |
| 13:03:05 | * | fedons joined #nim |
| 13:03:09 | dom96 | but would also be annoying to write everywhere |
| 13:03:11 | yglukhov | but now that im thinking about it... it would not be convenient. |
| 13:03:16 | yglukhov | yeah, exactly |
| 13:03:16 | dom96 | :) |
| 13:03:18 | yglukhov | =) |
| 13:03:34 | dom96 | I'll see what I can do with runtime imports |
| 13:03:52 | dom96 | I'm trying to get as much into this Nimble release as I can |
| 13:04:03 | dom96 | Currently working on multiple package list URLs. |
| 13:04:08 | yglukhov | is lockfile on the list? ;) |
| 13:04:26 | dom96 | not right now, but if it's something you really want then I will consider it more seriously :) |
| 13:04:36 | yglukhov | no, not really =) |
| 13:05:01 | yglukhov | one thing i want badly is to force update everything. |
| 13:06:01 | yglukhov | thats one annoying thing when our team of 5 works with 6 or more dependant projects at once |
| 13:06:46 | dom96 | You mean this? https://github.com/nim-lang/nimble/issues/88 |
| 13:07:04 | dom96 | Because that is on my list |
| 13:07:27 | dom96 | I guess you mean this though https://github.com/nim-lang/nimble/issues/169 |
| 13:07:53 | dom96 | I think it depends on #88 |
| 13:09:09 | dom96 | well actually I guess not |
| 13:09:12 | dom96 | I'll see what I can do |
| 13:09:39 | dom96 | I want #88 a lot though because it's annoying seeing Nimble clone a git repo every time |
| 13:10:09 | dom96 | then again, I should be careful not to introduce too much too fast or Nimble will become incredibly unstable |
| 13:16:24 | * | boopisaway quit (Ping timeout: 245 seconds) |
| 13:18:27 | yglukhov | dom96: yep, i mean 169. but 88 refers kinda similar option as "a manual command to refresh" |
| 13:20:27 | yglukhov | dom96: is build task override planned? |
| 13:21:05 | dom96 | yes. Overrides, pre and post hooks are on my todo |
| 13:22:30 | yglukhov | nice. |
| 13:22:36 | * | weox joined #nim |
| 13:23:11 | * | weox left #nim (#nim) |
| 13:23:29 | * | weox joined #nim |
| 13:26:06 | * | fedons quit (Quit: This computer has gone to sleep) |
| 13:29:33 | * | boopisaway joined #nim |
| 13:31:54 | * | boopisaway is now known as boop |
| 13:34:15 | * | weox left #nim (#nim) |
| 13:36:57 | girvo | quick q: how experimental are Concepts? :P |
| 13:37:52 | * | \u quit (Ping timeout: 250 seconds) |
| 13:41:31 | Araq_ | girvo: they are supposed to be stable enough for inclusion of version 1 |
| 13:42:02 | Araq_ | people keep misusing them but I cannot see how fixing the compiler to disallow invalid constructions is a big deal |
| 13:44:05 | dom96 | https://github.com/nim-lang/nimble/commit/835157ce34798ce11ba5517be97426738d6ad230 :D |
| 13:48:55 | dom96 | And just like that 3 issues close. |
| 13:49:04 | * | girvo quit (Ping timeout: 276 seconds) |
| 13:49:44 | dom96 | *4 |
| 13:58:29 | * | ray- joined #nim |
| 14:04:03 | * | fedons joined #nim |
| 14:06:15 | Araq_ | pre and post hooks? so I can say "after building do this"? |
| 14:06:50 | * | ray- quit (Ping timeout: 246 seconds) |
| 14:07:01 | Araq_ | do we need them? the idea of nimscript support is to get rid of featurism ... -.- |
| 14:08:59 | * | ray- joined #nim |
| 14:13:01 | dom96 | I might expose calls for each default task and then just allow overrides |
| 14:26:56 | * | Jesin joined #nim |
| 14:29:54 | * | fedons quit (Quit: This computer has gone to sleep) |
| 14:30:43 | * | fedons joined #nim |
| 14:31:28 | * | bpr joined #nim |
| 14:36:36 | bpr | Araq, how is work on the new lambda lifter coming along? |
| 14:36:54 | bpr | The downward funarg quadrature example from http://forum.nim-lang.org/t/352 doesn't work any more in the new branch. |
| 14:37:56 | * | ray- quit (Changing host) |
| 14:37:56 | * | ray- joined #nim |
| 14:37:56 | * | ray- is now known as \u |
| 14:39:50 | * | Jesin quit (Ping timeout: 250 seconds) |
| 14:43:15 | Araq_ | bpr: slowing going through the tests and fixing them |
| 14:44:08 | Araq_ | the forum example should be in the test suite by now |
| 14:44:16 | Araq_ | but I'm at test case number 2 ... |
| 14:44:45 | Araq_ | the compiler allows .closure procs in a 'const' context -.- but this is not sound |
| 14:44:57 | yglukhov | the hooks we might need is preinstall/postinstall |
| 14:45:26 | Araq_ | 'install' itself is already a design bug IMHO |
| 14:45:35 | Araq_ | nimble is not for installing software. |
| 14:45:49 | Araq_ | it's for dealing with Nimble package dependencies. |
| 14:46:26 | yglukhov | maybe "install" as a standalone command. but the package might need to know when its being installed to download dlls for example =) |
| 14:46:54 | Araq_ | to install software on your system, you should use beer/pacgirl or brain cell. |
| 14:47:38 | yglukhov | well, im just speculating. i personally didnt have a single need for install hooks |
| 14:48:25 | Araq_ | yglukhov: do you use .closure procs for 'consts'? |
| 14:48:49 | yglukhov | errr... nope, i guess...\ |
| 14:48:59 | Araq_ | I bet people do, in macros |
| 14:49:07 | Araq_ | ugh. |
| 14:49:56 | yglukhov | do you mean "const myconst = someClosureProc()" ? |
| 14:51:01 | Araq_ | no. |
| 14:51:27 | Araq_ | const foo = {"a": a, "b": b} where a and b are .closure procs |
| 14:51:42 | Araq_ | but that capture no environment |
| 14:52:02 | Araq_ | if they would, I'm quite sure the C codegen would fail for this ... hrm somebody should test this |
| 14:52:25 | yglukhov | and local procs with no pragmas are .closures? |
| 14:52:34 | Araq_ | .closure procs that actually don't capture anything are quite a pita to support in the compiler. |
| 14:53:02 | Araq_ | yglukhov: local procs are either .nimcall or .closure if you don't give them an explicit calling convention |
| 14:53:08 | * | Jesin joined #nim |
| 14:53:09 | Araq_ | the compiler computes it for you. |
| 14:53:23 | Araq_ | but you can do: |
| 14:53:42 | Araq_ | proc foo {.closure} = echo "fake closure!" |
| 14:55:07 | dom96 | Araq_: 'install' is nice for experimenting with packages |
| 14:55:28 | * | Jesin quit (Client Quit) |
| 14:55:49 | Araq_ | dom96: 'install' is fine for the reason it's such a pita to build installers for the Linux distros out there |
| 14:56:18 | Araq_ | but it surely is against Nimble's philosophy. IMO. |
| 14:56:54 | yglukhov | Araq: tbh, i don't see any reason to explicitly add .closure to proc definition. proc variables - yes. procs - why? |
| 14:57:48 | * | Jesin joined #nim |
| 14:57:59 | Araq_ | yglukhov: it makes some sense for [a, b] where every element has to have the same type and 'a' does capture and 'b' does not. |
| 14:58:46 | yglukhov | ah, true. |
| 15:00:41 | yglukhov | dom96: can i fix invalid pkg names in packages.json for you? ;) |
| 15:01:12 | dom96 | yglukhov: The .nimble files need to be fixed too, which can't be done without the author. |
| 15:01:57 | Araq_ | test 3 ... fails. |
| 15:02:08 | Araq_ | but it should cause I changed the semantics ... |
| 15:02:15 | yglukhov | dom96: even if they are not nimscripts? |
| 15:02:59 | dom96 | yglukhov: yes. |
| 15:03:44 | yglukhov | did i say its really frustrating? |
| 15:03:44 | * | saml joined #nim |
| 15:04:18 | dom96 | which packages are problematic? |
| 15:05:05 | yglukhov | currently nim-vorbis and nim-ogg i can see |
| 15:05:11 | yglukhov | maybe more... |
| 15:05:30 | * | bpr quit (Ping timeout: 252 seconds) |
| 15:05:52 | yglukhov | our autobuilds are now failing because they do nimble install from scratch on every build |
| 15:06:15 | dom96 | oh :\ |
| 15:07:04 | dom96 | I'll implement --force |
| 15:07:31 | yglukhov | why not disable validation temporarily? |
| 15:07:44 | yglukhov | you know, do a more gradual transition |
| 15:07:48 | dom96 | yeah |
| 15:07:52 | dom96 | You're right. |
| 15:07:54 | dom96 | I'll do that |
| 15:07:59 | yglukhov | thanks a bunch |
| 15:08:02 | dom96 | Sorry about this. |
| 15:08:07 | yglukhov | no worries |
| 15:21:20 | * | Jesin quit (Ping timeout: 260 seconds) |
| 15:30:21 | * | fedons quit (Quit: This computer has gone to sleep) |
| 15:31:19 | * | fedons joined #nim |
| 15:31:28 | * | fedons quit (Client Quit) |
| 15:33:13 | yglukhov | dom96: ""198.169.246.30:80" - isnt an uri, is it? |
| 15:33:44 | yglukhov | uri has to start with scheme, eg http: |
| 15:34:06 | dom96 | I'll have to consult the RFC :) |
| 15:34:22 | dom96 | but yeah, it works with http:// appended |
| 15:39:44 | yglukhov | dom96: oh, btw. i'm not 100% sure, but when i import nimx.something into my nimx project, it seems like the actual file is getting imported from nimx which is currently installed in nimble pkgs, and not the nimx im currenlty working with. can you confirm that? |
| 15:41:46 | dom96 | That is possible. |
| 15:42:11 | dom96 | If you compile with nimble it shouldn't happen though |
| 15:46:10 | dom96 | yglukhov: Do your autobuilds nimble install each package explicitly? |
| 15:48:10 | dom96 | I will soften the validation even more but will keep it as an error in the event that ``nimble install`` is executed with no args. |
| 15:48:17 | dom96 | i.e. to install a local package |
| 15:48:29 | dom96 | That way (I hope) package authors will know that they need to fix their package |
| 15:49:02 | dom96 | But maybe that's still too annoying |
| 15:49:17 | dom96 | I verify each package that goes into the package listing anyway |
| 15:49:37 | * | bpr joined #nim |
| 15:52:14 | * | joelmo joined #nim |
| 15:52:28 | bpr | Well, it's great that lambda lifting and closures are getting a lot of love right now. I hope that when it's all sorted, 'method' can be deprecated. |
| 16:00:00 | Araq_ | bpr: me too :-) |
| 16:01:32 | dom96 | yglukhov: done! |
| 16:07:53 | yglukhov | dom96: my autobuild runs "nimble install -y" in the root of my repo |
| 16:08:09 | dom96 | ahh okay |
| 16:08:10 | dom96 | good |
| 16:08:27 | yglukhov | deprecate method? how is that possible? |
| 16:09:52 | * | vendethiel quit (Ping timeout: 256 seconds) |
| 16:17:37 | * | boop is now known as boopisaway |
| 16:17:44 | bpr | yglukhov: If all of the closure stuff works well we could use the 'suite-of-methods' pattern for implementing simple OO. |
| 16:19:21 | bpr | I wonder if maybe an Ada(>= 95)-like approach to OO technics should have been tried before 'method', but as Araq seems quite familiar with Ada I'm sure he has his reasons for trying 'method' instead. |
| 16:23:50 | * | vendethiel joined #nim |
| 16:25:51 | * | fedons joined #nim |
| 16:25:55 | NimBot | nim-lang/Nim devel bf4c137 Dominik Picheta [+0 ±1 -0]: Fixes incorrect Host header when using httpclient with proxy. |
| 16:25:55 | NimBot | nim-lang/Nim devel deef047 Dominik Picheta [+0 ±2 -0]: Merge branch 'devel' of github.com:nim-lang/Nim into devel |
| 16:26:04 | * | pregressive joined #nim |
| 16:37:57 | * | matkuki joined #nim |
| 17:02:59 | * | yglukhov quit (Ping timeout: 255 seconds) |
| 17:03:28 | * | matkuki quit (Quit: ChatZilla 0.9.92 [Firefox 43.0.3/20151223140742]) |
| 17:04:34 | * | yglukhov joined #nim |
| 17:04:43 | * | yglukhov quit (Remote host closed the connection) |
| 17:13:09 | * | boopisaway is now known as boop |
| 17:16:16 | * | fedons quit (Quit: This computer has gone to sleep) |
| 17:18:00 | * | fedons joined #nim |
| 17:26:04 | * | fedons quit (Read error: Connection reset by peer) |
| 17:27:12 | * | fedons joined #nim |
| 17:28:31 | * | Demon_Fox joined #nim |
| 17:32:11 | dom96 | Only 6 more high priority issues in Nimble left! |
| 17:33:54 | * | nimnoob joined #nim |
| 17:37:43 | * | nimnoob quit (Client Quit) |
| 17:40:35 | flyx | I pushed my YAML implementation to github: https://github.com/flyx/NimYAML it's rather experimental currently |
| 17:41:52 | Xe | flyx: i'd like the ability to make an existing type serializeable |
| 17:42:14 | flyx | Xe: it can do that, but it's not well-tested |
| 17:42:36 | flyx | there's an example in the readme |
| 17:42:48 | * | bpr quit (Ping timeout: 252 seconds) |
| 17:43:21 | flyx | also, it doesn't generate local tags for the serialized types yet |
| 17:49:00 | * | fedons quit (Quit: This computer has gone to sleep) |
| 17:49:47 | * | dyu joined #nim |
| 17:55:31 | dom96 | flyx: Looks nice. Will this just be a parser or will it also include a data structure to hold the YAML data and procedures for navigating through it? |
| 17:57:30 | flyx | dom96: I would rather have a properly working automatic serialization / deserialization than have a data structure for the YAML core schema. |
| 17:58:04 | flyx | dom96: but there currently is a utility function to parse YAML input to Nim's JsonNode, if the structure allows it |
| 18:00:11 | flyx | dom96: I don't see much need for a data representation of the YAML core schema. if you want to load some YAML source which does not map to a Nim type, you'd probably want to parse it into some internal datastructure for easier access anyway, and you can do that with the parser |
| 18:00:36 | flyx | but for completeness, I think I will eventually add a YAML core schema representation. |
| 18:01:39 | flyx | it won't be much work to add it, anyway |
| 18:02:44 | dom96 | flyx: Sure, that makes sense. I do like having a data structure from which I can quickly extract data though. It makes experimenting with the data much easier for example. |
| 18:03:06 | dom96 | but yeah, even if you don't provide it I (or somebody else) can always write it. |
| 18:03:28 | Araq_ | map it to JSON |
| 18:04:01 | Araq_ | everything can be mapped to JSON and it's the defacto data interchange format |
| 18:05:00 | * | pregressive quit (Read error: Connection reset by peer) |
| 18:05:14 | flyx | Araq_: as I said, it's possible to parse YAML input into JsonNode, and it's also possible to dump a YAML event stream as JSON. as long as maps do only have scalars as keys. |
| 18:05:18 | * | pregressive joined #nim |
| 18:06:52 | flyx | a well, and JSON also has no representation of +/- infinity and NaN, that will lead to incorrect JSON output by JsonNode |
| 18:07:17 | * | yglukhov joined #nim |
| 18:11:26 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 18:18:48 | * | Sornaensis quit (Excess Flood) |
| 18:18:58 | Araq_ | interesting point. |
| 18:19:09 | Araq_ | no Inf and Nan for JSON? pity. |
| 18:19:12 | * | Sornaensis joined #nim |
| 18:20:12 | Araq_ | maybe somebody should try the middle way between overspecifying the wrong problem (XML) or letting a standard emerge from "what's easy in the browser right now" |
| 18:24:27 | * | yglukhov joined #nim |
| 18:39:56 | * | fedons joined #nim |
| 18:55:17 | * | fedons quit (Quit: This computer has gone to sleep) |
| 18:57:46 | * | fedons joined #nim |
| 18:59:07 | * | brson joined #nim |
| 19:05:07 | Araq_ | error: use of undeclared identifier 'foob'; did you mean 'feof'? |
| 19:05:25 | Araq_ | clang could always be smarter |
| 19:06:38 | * | fedons quit (Quit: This computer has gone to sleep) |
| 19:23:39 | Araq_ | yay, LL works except for the closure iterators |
| 19:35:33 | * | dyu quit (Ping timeout: 252 seconds) |
| 19:38:54 | yglukhov | thats so awesome! may i hope that closure iters will work in js along with c? ;) |
| 19:40:12 | * | pregressive quit (Read error: Connection reset by peer) |
| 19:40:28 | * | pregressive joined #nim |
| 19:41:03 | Araq_ | well ... |
| 19:41:24 | Araq_ | I made the new LL semantics closer to JS, so we don't have to generate dummy functions for loops |
| 19:42:14 | Araq_ | and I can write some JS backend code for closure iters |
| 19:42:31 | Araq_ | why don't you do it though? I told you the theory |
| 19:43:15 | NimBot | nim-lang/Nim devel 72f8046 Andreas Rumpf [+0 ±1 -0]: do not print spurious warnings when dlopen fails; can be re-enabled with -d:nimDebugDlOpen |
| 19:43:15 | NimBot | nim-lang/Nim devel 255177f Andreas Rumpf [+0 ±1 -1]: new db_sqlite requires deadCodeElim:on because not every sqlite3_column_name |
| 19:44:26 | Araq_ | you only have to give every control flow statement two different implementations ... |
| 19:46:36 | Araq_ | ah I also had another idea. |
| 19:47:04 | Araq_ | we should perhaps introduce .delegate fields in the language |
| 19:47:40 | * | bpr joined #nim |
| 19:47:51 | Araq_ | that could be used to transform obj.foo() to obj.vmt.foo() |
| 19:48:19 | Araq_ | as a not as pervasive dot overloading |
| 19:50:17 | bpr | Looks like things are progressing nicely on the closure front. I'm looking forward to getting home and trying the new-ll Nim out. |
| 20:03:25 | * | NimrodBot joined #nim |
| 20:03:43 | * | NimrodBot quit (Remote host closed the connection) |
| 20:04:54 | yglukhov | Araq, sorry, but i hardly understood a word. |
| 20:06:11 | * | NimrodBot joined #nim |
| 20:06:12 | Araq_ | I'll see what I can do then. |
| 20:06:24 | yglukhov | and closure iters are not a priority for me now, tbh. just would be nice to play with, but not that critical =) |
| 20:06:36 | * | NimrodBot quit (Remote host closed the connection) |
| 20:07:35 | yglukhov | dom96: there's a strange error with variant auto build. could you take a look please? https://travis-ci.org/yglukhov/variant/builds/99313585 |
| 20:09:38 | yglukhov | specifically: Cannot find nimscriptapi.nim |
| 20:09:45 | yglukhov | i cant find it either %) |
| 20:14:22 | yglukhov | ah i see it's in nimble git now... |
| 20:26:59 | yglukhov | dom96: please, see this log as well: https://travis-ci.org/yglukhov/variant/builds/99322105. "nimble path nimble" fails |
| 20:27:12 | yglukhov | however i can't reproduce it on my mac |
| 20:33:49 | * | joelmo quit (Quit: Connection closed for inactivity) |
| 20:35:52 | * | darkf quit (Quit: Leaving) |
| 20:43:13 | * | yglukhov quit (Remote host closed the connection) |
| 20:49:55 | * | yglukhov joined #nim |
| 20:53:23 | * | vendethiel quit (Read error: Connection reset by peer) |
| 20:54:38 | * | thotypous is now known as matias |
| 20:55:12 | * | yglukhov quit (Remote host closed the connection) |
| 20:55:17 | * | vendethiel joined #nim |
| 20:56:28 | * | desophos joined #nim |
| 20:57:17 | * | yglukhov joined #nim |
| 21:05:50 | * | irrequietus joined #nim |
| 21:13:32 | * | jakesyl joined #nim |
| 21:15:07 | dom96 | yglukhov: how does your travis instance install nimble? |
| 21:16:16 | yglukhov | dom96: nim e ./install_nimble.nims |
| 21:16:20 | yglukhov | from nim dir |
| 21:17:42 | dom96 | There is your problem ;) |
| 21:18:53 | * | def- quit (Ping timeout: 276 seconds) |
| 21:19:21 | yglukhov | ahhh, true... |
| 21:19:37 | yglukhov | i think ill fix the install_nimble.nims... |
| 21:20:45 | dom96 | yeah, it's a useful script but there is a reason that Nimble should be installed using Nimble. |
| 21:21:02 | dom96 | Not just copied to Nim's bin |
| 21:22:11 | * | desophos quit (Remote host closed the connection) |
| 21:25:30 | * | desophos joined #nim |
| 21:26:29 | * | desophos quit (Read error: Connection reset by peer) |
| 21:40:39 | * | def- joined #nim |
| 21:40:49 | * | Jesin joined #nim |
| 21:40:58 | yglukhov | dom96: will it do? https://github.com/nim-lang/Nim/pull/3676 |
| 21:41:24 | * | desophos joined #nim |
| 21:42:59 | * | Jesin quit (Client Quit) |
| 21:44:28 | dom96 | yglukhov: Won't work on Windows, but looks good. Wanna see what Araq_ thinks before merging though. |
| 21:45:00 | * | desophos_ joined #nim |
| 21:45:54 | * | desophos quit (Ping timeout: 256 seconds) |
| 21:46:11 | * | def- quit (Ping timeout: 276 seconds) |
| 21:46:37 | yglukhov | ah, travis failed because nimble is no longer in path. |
| 21:47:04 | * | Jesin joined #nim |
| 21:58:22 | Araq_ | "won't work on windows but looks good" ? |
| 21:58:58 | yglukhov | =)) |
| 21:59:59 | Araq_ | https://www.youtube.com/watch?v=6x4qNdSM4dA&feature=youtu.be&t=149 |
| 22:00:02 | * | jakesyl quit (Ping timeout: 246 seconds) |
| 22:00:23 | yglukhov | did it use to work on windows? and if yes, why should not it work with my changes? |
| 22:03:44 | Araq_ | no idea but what's the real problem? |
| 22:04:05 | Araq_ | my script works on any OS and installing nimble to nim's bin/ is the right thing to do. |
| 22:04:49 | yglukhov | nimble is no longer a standalone binary. it requires nimscriptapi.nim as a resource |
| 22:07:55 | * | desophos_ is now known as desophos |
| 22:11:28 | dom96 | https://github.com/nim-lang/nimble#from-source |
| 22:12:32 | Araq_ | how is this relevant? |
| 22:12:55 | Araq_ | the script doesn't install nimble via "nimble install nimble" |
| 22:13:08 | Araq_ | it just builds it and puts the .exe to the right place |
| 22:14:20 | * | pregressive quit (Read error: Connection reset by peer) |
| 22:14:53 | * | pregressive joined #nim |
| 22:16:32 | dom96 | Araq_: yglukhov's version does |
| 22:17:28 | * | Trustable joined #nim |
| 22:18:01 | yglukhov | updated pr. Araq's notes addressed. |
| 22:19:09 | Araq_ | I don't know why you make it so complicated, "nimble update nimble" might be a problem with the exe lock on Windows but you can do this: http://stackoverflow.com/questions/459734/is-there-a-way-to-make-a-self-updatable-executable-in-windows |
| 22:19:47 | Araq_ | rename the old running exe on windows before building the new exe |
| 22:23:39 | * | def- joined #nim |
| 22:24:13 | yglukhov | will "nim -o:nimble1" automatically add ".exe" on windows? |
| 22:24:21 | Araq_ | why does nimble use itself to install it? don't we have niminst to build installers? do we really need yet another self recursive dependency just to be cool? |
| 22:24:45 | dom96 | Because Nimble is a Nimble package |
| 22:25:00 | Araq_ | what if I don't have a nimble? |
| 22:25:29 | Araq_ | ah, so then I should build it from source ... |
| 22:25:38 | dom96 | Araq_: What's the problem? |
| 22:25:40 | Araq_ | which is what 'nimbe install nimble' does anyway ... |
| 22:25:46 | dom96 | It's not difficult to use Nimble this way |
| 22:26:40 | Araq_ | yglukhov: dunno, I doubt it |
| 22:26:42 | dom96 | yglukhov: BitPuffin renamed his nim-ogg, nim-portaudio and nim-vorbis repos to ogg, portaudio and vorbis. I added those as aliases to the package list. |
| 22:28:07 | dom96 | s/repos/packages/ |
| 22:28:19 | yglukhov | cool! |
| 22:28:58 | * | def- quit (Ping timeout: 256 seconds) |
| 22:29:08 | Araq_ | well you're messing with my precious script. |
| 22:29:15 | Araq_ | and I demand to know why. |
| 22:29:56 | * | bpr quit (Quit: Page closed) |
| 22:30:07 | yglukhov | does toExe blindlessly adds .exe suffix to a string? |
| 22:30:45 | Araq_ | no it's smart |
| 22:30:46 | yglukhov | * blindly |
| 22:31:13 | Araq_ | it's also a nop on posix systems |
| 22:31:25 | yglukhov | how smart it is on windows? =) |
| 22:31:30 | Araq_ | well actually |
| 22:31:38 | Araq_ | use "foo".toExe |
| 22:31:49 | Araq_ | produces "foo" on posix, "foo.exe" on windows. |
| 22:32:29 | Araq_ | and I think you're right "foo.exe".toExe produces "foo.exe.exe" but who cares |
| 22:33:01 | Araq_ | dom96: what is the problem? and why is travis failing? |
| 22:36:19 | dom96 | Araq_: yglukhov is using the script to install Nimble. Nimble needs nimscriptapi.nim to function. The script doesn't install that anywhere. Nimble fails. |
| 22:37:15 | Araq_ | the script assumes that nimble wasn't installed and nobody bothered to add $nimble_bin to his PATH |
| 22:37:25 | Araq_ | you cannot just change the script nilly willy |
| 22:37:40 | Araq_ | use a different script if it doesn't fullfill your needs. |
| 22:38:14 | Araq_ | and in fact, the script was especially written for Windows ... |
| 22:38:26 | Araq_ | but it works everywhere because Nimscript is so awesome |
| 22:41:07 | dom96 | Right. That's why I wanted your feedback. |
| 22:41:18 | dom96 | It's your script. |
| 22:41:23 | yglukhov | but it will not work as it is from now on, because dom96 has made another breaking change ;) |
| 22:41:50 | yglukhov | even on windows |
| 22:43:57 | Araq_ | how so? |
| 22:45:34 | yglukhov | if nimble is not properly installed (that is nimble install nimble) it will not find nimscriptapi.nim, which is needed to evaluate nimscript nimble files |
| 22:45:56 | Araq_ | so make it find 'nimscriptapi.nim'. |
| 22:47:10 | Araq_ | why does that depend on a proper installation, just use relative paths, relative to nimble.exe. |
| 22:47:41 | Araq_ | that's what every working app bundler does. |
| 22:48:04 | yglukhov | it does and it works when nimble is in its src. but your script copies it out to nim/bin |
| 22:48:29 | dom96 | Araq_: Why are you so against Nimble installing itself? |
| 22:48:31 | Araq_ | nimble.exe never should be in its src, it's not a source. |
| 22:49:33 | yglukhov | thats where nim puts nimble upon compilation :D |
| 22:49:38 | yglukhov | lol |
| 22:49:52 | yglukhov | an hour wasted for nothing |
| 22:50:19 | Araq_ | so copy it over to somewhere else ... like the script does. |
| 22:51:59 | Araq_ | dom96: it's needlessly complex for no gain, pretends niminst doesn't exist and doesn't even solve 'nimble update nimble', but this is besides the point since the problems we're discussing don't have much to do with "nimble install nimble", in my opinion. |
| 22:52:45 | yglukhov | whats niminst anyway? |
| 22:52:54 | yglukhov | never heard of it |
| 22:53:26 | Araq_ | it produces real installers for end users who don't care if the software is Nim based or not. |
| 22:55:03 | dom96 | using Nimble to perform the installation *is* the simple solution |
| 22:55:08 | yglukhov | but nimble users do care that software is nim based. right? =) i personally use nimble install nimble pretty often. handy. and dead easy to remember |
| 22:55:11 | dom96 | adding niminst to the mix would make things more complex |
| 22:55:27 | Araq_ | for you. but not for your users. |
| 22:55:58 | dom96 | What's so hard about the current installation instructions? |
| 22:55:58 | Araq_ | but it's all beside the point anyway. |
| 22:56:11 | dom96 | Please tell me because I honestly have no idea. |
| 22:56:50 | Araq_ | it's bad because you have 2 scripts here as your installation instructions that you didn't write down as a Nim script ;-) |
| 22:57:08 | Araq_ | so users have to read and see whether they are on posix or not |
| 22:57:29 | dom96 | NimScript didn't exist when I wrote those instructions |
| 22:57:33 | dom96 | As I'm sure you are aware. |
| 22:57:36 | Araq_ | exactly. |
| 22:57:52 | Araq_ | and I wrote the cool script later. |
| 22:57:58 | Araq_ | but it's all beside the point anyway. |
| 22:58:09 | Araq_ | why does Nimble only work when it's installed "properly"? |
| 22:58:24 | Araq_ | what does "properly" even mean on 3 different OSes? |
| 22:58:38 | Araq_ | it needs to just work instead. |
| 22:58:49 | * | pregressive quit () |
| 22:59:10 | dom96 | Because "properly" is the only way it should be installed. |
| 22:59:15 | * | kernasi joined #nim |
| 22:59:19 | dom96 | You want me to guess how people will install it? |
| 22:59:23 | kernasi | hi |
| 22:59:27 | dom96 | hello kernasi! |
| 22:59:47 | Araq_ | that's what happens anyway thanks to all the other package managers out there. |
| 23:00:09 | Araq_ | brew might not agree with your ideas of how nimble should be installed ... |
| 23:00:20 | Araq_ | you simply need to be more flexible. sorry. |
| 23:02:28 | yglukhov | dom96: can you staticRead it? |
| 23:02:53 | dom96 | Araq_: Good point. |
| 23:03:04 | yglukhov | i don't really care who wins this fight, just want to get it working. |
| 23:03:28 | dom96 | yglukhov: hah. Just copy ``nimblepkg`` beside the nimble binary and it should work. |
| 23:04:14 | yglukhov | in Araq's script? Araq, that sounds good for you? |
| 23:05:38 | dom96 | Araq_: Package managers which are already established will have a reason to put Nimble in some non-standard location |
| 23:05:43 | dom96 | Araq_: What's your reason? |
| 23:06:46 | dom96 | (non-standard location meaning "non-standard to Nimble right now, but universally acclaimed by all the Unix users ;)") |
| 23:07:09 | Araq_ | I don't see the need to rely on $nimble_bin being in my PATH when I know for a fact nim/bin will work |
| 23:08:00 | Araq_ | you didn't automate adding it to my PATH anyway, Nim's installer does that. but you don't use niminst to build an installer, so you're unlucky. |
| 23:08:27 | Araq_ | in fact, I don't know if I have nimble_bin in my PATH. |
| 23:08:54 | Araq_ | and do bundle nimble.exe on Windows anyway, it's part of the core. |
| 23:09:25 | Araq_ | we cannot do the same on Unix, mostly because nimble is in its own git repo. |
| 23:10:15 | Araq_ | *and we do bundle |
| 23:11:03 | yglukhov | nimscript cannot copy dirs, can it? |
| 23:11:36 | Araq_ | neither can Nim's os module I think. |
| 23:11:50 | dom96 | I'm happy to add more locations where Nimble searches for nimscriptapi |
| 23:12:06 | Araq_ | and it's not clear what that means thanks to symlinks. |
| 23:12:25 | yglukhov | dom96, are you really sure you dont want to staticread? |
| 23:12:57 | yglukhov | that seems like the simpliest solution considering all the pros and cons. |
| 23:13:29 | dom96 | Hrm. yeah. |
| 23:13:32 | dom96 | I think I will do that |
| 23:13:37 | dom96 | Will need to think about it some more. |
| 23:13:39 | dom96 | bbl |
| 23:15:30 | Araq_ | yglukhov: by that logic Nim should staticRead its entire stdlib |
| 23:15:42 | Araq_ | which is actually been proposed |
| 23:15:46 | Araq_ | *has |
| 23:16:27 | Araq_ | but good lord you all act like using getAppDir() / "lib" / "nimscriptap.nim" is hard to do in Nim. |
| 23:16:55 | yglukhov | yeah, it might do so when we get it compiling to js. |
| 23:17:24 | yglukhov | good lord, getAppDir() / "lib" / "nimscriptap.nim" will not work |
| 23:17:58 | yglukhov | because getAppDir() is nim_path, to which you copy only nimble.exe, and not "lib" / "nimscriptap.nim" |
| 23:19:23 | Araq_ | my nimble scripting support was in an include file, included by system.nim |
| 23:19:34 | Araq_ | so there was nothing to copy, it was already there. |
| 23:23:18 | yglukhov | i know. but its not the case anymore, as far as i understood |
| 23:24:02 | yglukhov | and tbh i agree that nimble scripting support should reside in nimble, not in nim |
| 23:24:34 | Araq_ | *shrug* it kind of misses the point entirely |
| 23:24:43 | yglukhov | why? |
| 23:25:05 | Araq_ | because I want a single .nimble file with all of my configuration and meta information |
| 23:25:15 | Araq_ | that can be read by both nim and nimble |
| 23:25:41 | yglukhov | yeah, me too. and dom96 has done it like so, no? |
| 23:25:44 | Araq_ | and so nim needs to support packageName = "foobar" and makes it a dummy rather than me having to write 'when defined(nimble)' everywhere |
| 23:25:57 | yglukhov | ah |
| 23:26:25 | Araq_ | and for me nimble is part of the core. |
| 23:26:34 | Araq_ | I shouldn't even have to install it at all. |
| 23:26:53 | Araq_ | I should build nim from source by whatever means and also get a working nimble. |
| 23:27:11 | Araq_ | or install the binaries and again the binaries should have nimble. |
| 23:27:14 | yglukhov | well, youll have to discuss it with dom96 more thoughly |
| 23:27:28 | Araq_ | we did discuss it already |
| 23:27:42 | Araq_ | he disagrees and so is free to do it his way. |
| 23:27:57 | Araq_ | Nimble is his baby, not mine. |
| 23:28:13 | Araq_ | but again, Nimble needs to be flexible of how it was installed. |
| 23:28:19 | Araq_ | *about |
| 23:28:39 | Araq_ | not because of my personal agenda. But because of all the other packagers out there. |
| 23:29:01 | yglukhov | can .cfg keys be passed to nim in some other way? |
| 23:29:25 | Araq_ | via the command line. |
| 23:29:37 | Araq_ | most of them, maybe not all. |
| 23:29:58 | yglukhov | like gcc path, gcc name, linker name, etc. |
| 23:30:17 | Araq_ | --gcc.path="..." |
| 23:30:26 | yglukhov | oh cool |
| 23:30:34 | yglukhov | how did i miss that |
| 23:31:37 | * | boop is now known as boopisaway |
| 23:31:51 | Araq_ | or maybe it's --putenv:gcc.path="..." |
| 23:31:58 | yglukhov | if that is so, you should not worry about nims configuration at all on the nim side |
| 23:32:10 | yglukhov | it all can be done by nimble |
| 23:32:38 | Araq_ | no. it needs to be supported by both. |
| 23:32:43 | yglukhov | why? |
| 23:32:45 | Araq_ | we talked about that too :P |
| 23:32:52 | Araq_ | nim build foo |
| 23:32:55 | Araq_ | is different from |
| 23:32:58 | Araq_ | nimble build foo |
| 23:33:15 | yglukhov | nim should not support "build" |
| 23:33:17 | yglukhov | imho |
| 23:33:34 | Araq_ | 'nimble build' respects nimble dependencies via --noNimblePath and adding the packages explicitly |
| 23:33:50 | Araq_ | 'nim build' just runs the build task in the nimscript file. |
| 23:35:21 | Araq_ | well I don't know what 'nimble build' will mean once the nimscript stuff landed |
| 23:35:43 | Araq_ | but the distinction makes some sense and I would like to keep it. |
| 23:37:20 | yglukhov | can not nimble make this distinction later on? like "nimble --allowAllPackages build " |
| 23:38:48 | Araq_ | perhaps. |
| 23:39:25 | yglukhov | you know, verbally "nim build" and "nimble build" tell me no difference. guess how many years i have to work in nim to get to it. but "nimble build" and "nimble --something build" explicitly tell me there is a difference |
| 23:40:26 | yglukhov | and it also tells me that i can learn about it by nimble --help | grep comething |
| 23:40:57 | Araq_ | well it's not like we were evil. 'nim build' is emergent behaviour. |
| 23:43:09 | Araq_ | and you could also argue we don't need 'nimble' at all, just a package dependency API usable with Nimscript |
| 23:43:38 | * | Trustable quit (Remote host closed the connection) |
| 23:44:00 | Araq_ | and then I can either do 'nim c foo.nim' or 'nim foo.nims' # default task or 'nim task foo.nims' |
| 23:45:04 | Araq_ | but then the compiler is officially allowed to perform downloads and the security people rage |
| 23:46:00 | * | def- joined #nim |
| 23:46:08 | yglukhov | i don't care much if pkg management is done through nimble or nim, as long as there is one right way to do it. also it's pretty conventional to do pkg management in a separate tool. |
| 23:47:27 | yglukhov | and then if we're talking about packages, we get a distinction that clearly states: nim is for compiling files with some low-level options. nimble is for building packages. |
| 23:47:33 | NimBot | nim-lang/Nim new-ll 25e862b def [+0 ±1 -0]: Fix osproc compilation on NetBSD, use workaround for missing execvpe |
| 23:47:33 | NimBot | nim-lang/Nim new-ll 31cc181 def [+0 ±1 -0]: Fix nativesockets compilation on OpenBSD and NetBSD |
| 23:47:33 | NimBot | nim-lang/Nim new-ll 3c557a0 trustable-code [+1 ±1 -0]: fix issue #3550 |
| 23:47:33 | NimBot | nim-lang/Nim new-ll ebd14bd Andreas Rumpf [+1 ±1 -0]: Merge pull request #3666 from trustable-code/PR10... 2 more lines |
| 23:47:33 | NimBot | 15 more commits. |
| 23:48:23 | Araq_ | yglukhov: 'nim' is shorter to type ;-) |
| 23:49:15 | Araq_ | it doesn't hurt to be flexible but I agree that 'nimble --allowAllPackages build' is the better alternative |
| 23:49:43 | Araq_ | so yeah 'nim build' shouldn't become a standard |
| 23:50:34 | * | def- quit (Ping timeout: 256 seconds) |
| 23:50:45 | yglukhov | if flexibility costs nothing, then ok. but in your case, this flexibility requires some lines of code, that need to be supported. also there's a thin line between flexibility and ambiguity ;) |
| 23:51:19 | Araq_ | not sure what you mean. |
| 23:51:40 | Araq_ | 'nim build' required not a single line of code, it's just 'nim $task' |
| 23:52:40 | yglukhov | nim $task requires lines of code. nim could get away without nims support at all. |
| 23:53:24 | Araq_ | not really. 'nim e foo.nims' is too cool to do without and is not really nimble's business |
| 23:54:32 | yglukhov | ok, i mean "tasks" support. nim e is cool indeed. |
| 23:55:26 | Araq_ | yeah but then why do I need a nimble file for 'nim test foo.nim'? it's cool it works without nimble. |
| 23:57:03 | Araq_ | plus we can remove the .cfg based configuration system in the compiler eventually, which people also complained about |
| 23:57:24 | Araq_ | as it's not really documented and yet another syntax for people to learn. |
| 23:57:29 | yglukhov | in real life you would have dependencies, which are managed by nimble. so you can't live without it. |
| 23:58:22 | yglukhov | +1 to kill cfg in favor of cmdline, which is configured by nimble |
| 23:58:50 | Araq_ | cmdlines cannot be arbitrarily long though |
| 23:58:59 | Araq_ | so -10 for that. |
| 23:59:02 | Araq_ | :P |
| 23:59:56 | yglukhov | but cfg is not arbitrarily long |