<< 25-12-2015 >>
00:03:37*irrequietus quit ()
00:07:47*vendethiel- joined #nim
00:11:40*vendethiel quit (Ping timeout: 265 seconds)
00:19:45*zepolen joined #nim
00:59:49*yglukhov joined #nim
01:04:21*yglukhov quit (Ping timeout: 265 seconds)
01:08:32*vendethiel- quit (Ping timeout: 255 seconds)
01:25:55*jaco60 quit (Ping timeout: 240 seconds)
01:31:11*yglukhov joined #nim
01:36:05*yglukhov quit (Ping timeout: 260 seconds)
01:52:11*brson joined #nim
02:02:34*yglukhov joined #nim
02:07:23*yglukhov quit (Ping timeout: 264 seconds)
02:15:56*[CBR]Unspoken quit (Ping timeout: 250 seconds)
02:31:04*[CBR]Unspoken joined #nim
02:34:01*yglukhov joined #nim
02:38:29*yglukhov quit (Ping timeout: 245 seconds)
02:42:05*Varriount-Laptop joined #nim
03:05:25*yglukhov joined #nim
03:09:44*yglukhov quit (Ping timeout: 245 seconds)
03:37:27*yglukhov joined #nim
03:41:49*yglukhov quit (Ping timeout: 245 seconds)
04:08:36*vendethiel joined #nim
04:08:54*yglukhov joined #nim
04:13:04*yglukhov quit (Ping timeout: 245 seconds)
04:26:32*brson quit (Ping timeout: 276 seconds)
04:28:34*brson joined #nim
04:32:40*vendethiel quit (Ping timeout: 265 seconds)
04:35:30*brson quit (Quit: leaving)
04:40:27*yglukhov joined #nim
04:44:35*yglukhov quit (Ping timeout: 240 seconds)
05:15:46*Varriount-Laptop quit (Ping timeout: 256 seconds)
05:28:27*darkf joined #nim
06:11:49*BitPuffin|osx quit (Ping timeout: 245 seconds)
06:31:18*yglukhov joined #nim
06:34:50*Varriount-Laptop joined #nim
06:35:34*yglukhov quit (Ping timeout: 245 seconds)
06:42:14*vegansk joined #nim
06:51:32*Varriount-Laptop quit (Ping timeout: 256 seconds)
07:03:01*yglukhov joined #nim
07:05:07*sepisoad joined #nim
07:07:14*yglukhov quit (Ping timeout: 245 seconds)
07:21:18*pregressive joined #nim
07:24:03*pregressive quit (Remote host closed the connection)
07:24:13*Demon_Fox joined #nim
07:30:32*vqrs quit (Ping timeout: 250 seconds)
07:31:43*vqrs joined #nim
07:34:41*yglukhov joined #nim
07:38:54*yglukhov quit (Ping timeout: 245 seconds)
07:56:29*sepisoad quit (Read error: Connection reset by peer)
07:58:04*vikaton quit (Quit: Connection closed for inactivity)
08:06:07*yglukhov joined #nim
08:10:34*yglukhov quit (Ping timeout: 245 seconds)
08:39:52*yglukhov joined #nim
08:44:19*yglukhov quit (Ping timeout: 245 seconds)
08:45:23*matkuki joined #nim
09:09:44*yglukhov joined #nim
09:33:16*yglukhov quit (Remote host closed the connection)
09:44:43*irrequietus joined #nim
09:48:49*yglukhov joined #nim
09:53:04*yglukhov quit (Ping timeout: 245 seconds)
10:03:36*yglukhov joined #nim
10:07:35*yglukhov quit (Ping timeout: 240 seconds)
10:10:18*yglukhov joined #nim
10:15:06*yglukhov quit (Ping timeout: 272 seconds)
10:18:00*zepolen quit (Read error: Connection reset by peer)
10:26:27*matkuki quit (Read error: Connection reset by peer)
10:26:45*yglukhov joined #nim
10:31:02*yglukhov quit (Ping timeout: 255 seconds)
10:36:08*Demon_Fox quit (Quit: Leaving)
10:38:23*gunn quit (Read error: Connection reset by peer)
10:39:22*gunn joined #nim
11:03:08*Trustable joined #nim
11:05:40*jaco60 joined #nim
11:13:11*yglukhov joined #nim
11:17:35*yglukhov quit (Ping timeout: 264 seconds)
11:28:48*yglukhov joined #nim
11:33:30*yglukhov quit (Ping timeout: 260 seconds)
11:35:00*sora joined #nim
11:48:10*yglukhov joined #nim
11:52:16*yglukhov quit (Ping timeout: 250 seconds)
12:09:49*sora quit (Remote host closed the connection)
12:57:43*Rush_ quit (Read error: Connection reset by peer)
12:58:05*reactormonk quit (Ping timeout: 276 seconds)
12:58:44*r-ku- quit (Ping timeout: 276 seconds)
12:59:00*r-ku joined #nim
12:59:09*reactormonk joined #nim
13:01:00*RushPL joined #nim
13:39:25*Trustable quit (Remote host closed the connection)
13:43:25*matkuki joined #nim
13:43:51*matkuki quit (Client Quit)
14:02:26*matkuki joined #nim
14:05:49matkukiAnybody got glut working on windows?
14:06:33matkukiTried MinGW and MSVC, both give segfault on glutInit function.
14:10:29matkukiI tried the stuff on the forum, but it doesn't work on windows: http://forum.nim-lang.org/t/917/1
14:10:30matkukiAlso tried fowlmouth change, but no change: https://github.com/nim-lang/opengl/issues/23
14:24:29*boopisaway is now known as boop
14:24:32*boop is now known as boopisaway
14:30:27NimBotnim-lang/Nim devel 25e862b def [+0 ±1 -0]: Fix osproc compilation on NetBSD, use workaround for missing execvpe
14:30:27NimBotnim-lang/Nim devel cbab2ec Dominik Picheta [+0 ±1 -0]: Merge pull request #3663 from def-/netbsd-fix... 2 more lines
14:31:05dom96matkuki: Sorry, don't have windows right now otherwise would try to help you.
14:31:14dom96matkuki: If you don't get an answer here then please ask on the forum.
14:35:09matkukidom96: Thanks, will try.
14:40:45*sorakun joined #nim
14:43:10*dom96 quit (Changing host)
14:43:10*dom96 joined #nim
15:07:15*tyu joined #nim
15:15:39*vendethiel joined #nim
15:35:37*sorakun quit (Remote host closed the connection)
15:38:20*matkuki quit (Quit: ChatZilla 0.9.92 [Firefox 43.0.2/20151221130713])
15:39:24dom96Araq_: There is no way for me to retrieve the flags specified in the nimscript file
15:39:30dom96using ``switch``
15:40:18dom96because ``switch`` calls processSwitch. ProcessSwitch does not store the flags anywhere, but instead has a giant case statement which configures a large amount of variables depending on the switch it gets
15:41:17dom96So it looks like we'll need to change the implementation of it
16:11:01*vendethiel- joined #nim
16:14:54*vendethiel quit (Ping timeout: 260 seconds)
16:33:32dom96booyah https://github.com/nim-lang/nimble/commit/84f371982bc9643f4e42507929f59244f200a10c
16:33:51dom96This now works: https://github.com/nim-lang/nimble/blob/master/tests/nimscript/nimscript.nimble#L20
17:17:37*tyu quit (Quit: Connection closed for inactivity)
17:25:24*Demon_Fox joined #nim
18:26:19*darkf quit (Quit: Leaving)
18:47:43*nchambers joined #nim
18:55:28*nchambers quit (Disconnected by services)
18:59:44*BitPuffin joined #nim
19:12:16Araq_dom96: or you use when compileOption("key", "value") ...
19:13:20dom96Araq_: Not sure I follow
19:14:53Araq_oh sorry, I misunderstood your problem
19:15:14Araq_ok, well
19:15:30Araq_the question is whether 'switch' stays for compiler switches
19:15:42Araq_or whether it's also used for nimble switches
19:16:28Araq_does nimble have switches? and why do I need to influence them?
19:16:44Araq_I couldn't do that in the traditional .nimble file either.
19:19:48*sorakun joined #nim
19:28:11dom96of course it does
19:28:35dom96nimble c -r blah.nim # the `-r` is passed as a flag to the nim compiler
19:28:43dom96so you need to do:
19:28:45dom96--r
19:28:51dom96setCommand "c", "blah.nim"
19:29:08*nchambers joined #nim
19:31:20Araq_seems stupid.
19:32:12Araq_exec "nim c -r blah.nim"
19:32:16Araq_setCommand "nop"
19:32:21Araq_problem solved.
19:32:29dom96No
19:32:38dom96nimble c -r blah.nim is not the same as nim c -r blah.nim!
19:33:10dom96but actually. setCommand itself seems stupid
19:33:21dom96What's the point of it at all when you can just exec?
19:33:37Araq_to save 1 roundtrip in the compiler
19:34:17Araq_there is no difference for nimble since nimble exec's the compiler anyway
19:34:17nchambersAraq_, nice tail
19:34:53dom96ahh great
19:34:53Araq_nchambers: thanks, the ladies enjoy it
19:35:03dom96So there is no reason for setCommand to even be supported in Nimble
19:35:03nchambers:D:
19:35:33Araq_dom96: well right now setCommand in nimble sets the *nimble* command
19:35:40Araq_how nimble should proceed after the task
19:36:04Araq_so it's not redundant, but different from what it means for nim
19:36:21dom96i may as well just use 'exec'
19:36:45dom96The only difference is that it will use the 'nimble' that is in PATH
19:37:06Araq_hrm true
19:37:55dom96or better yet
19:38:10dom96I will override 'exec' to check whether the user is trying to execute 'nimble'
19:38:25dom96And you should do the same in NimScript for the compiler
19:39:36dom96setCommand can be supported too, but I'm not sure what situation makes it beneficial
19:39:55dom96it's already awkward to work with
19:42:06*vendethiel- quit (Remote host closed the connection)
19:42:14*vendethiel joined #nim
19:42:50Araq_dunno, I think it's totally natural
19:43:00Araq_task build, "alias for c":
19:43:04Araq_ setCommand "c"
19:43:31Araq_and now you also know why it doesn't support options
19:43:45Araq_because these are taken over from the command line just like before
19:44:03Araq_ setCommand "c", "foo.nim" is the weird special case
19:44:11Araq_where it *changes* the subject
19:48:37dom96See. I was not aware of that.
19:49:27dom96setCommand is not specified concretely anywhere
19:50:08dom96so in that case `nim build -r foo.nim` will translate to `nim c -r foo.nim`
19:51:55dom96If that's what setCommand should be used for then please document that fact
19:52:20dom96In that case let's keep it, but we should also make exec "nim c foo" work as I described
19:53:23Araq_yeah, will improve its docs
19:53:40Araq_not sure about exec "nim c foo" doing special casing
19:54:05Araq_but I don't like exec "$nim c foo" either, so hrm
19:54:17dom96then introduce another proc
19:54:19Araq_I think we should document that 'exec' shouldn't be used
19:54:33dom96exec will be necessary
19:54:38Araq_and have execNim, execNimble, etc
19:55:05dom96or how about just 'nim' and 'nimble'
19:55:18*nchambers quit (Changing host)
19:55:18*nchambers joined #nim
19:55:29dom96nim "c foo"
19:56:23dom96It's also a bit annoying to see a different API for NimScript
19:56:33*nchambers is now known as mewtwo
19:56:48dom96at least keep the names consistent
19:57:17*mewtwo is now known as charmander
19:57:30dom96for example cpFile vs. copyFile
19:57:43Araq_I took the names from nake
19:57:59Araq_and the semantics are different so they have different names
19:58:21Araq_cpFile supports logging
19:58:27Araq_copyFile doesn't
19:59:07*charmander is now known as squirtle
20:00:35dom96right
20:00:36dom96so
20:00:39dom96nim "c foo"?
20:00:59Araq_meh, I prefer execNim
20:01:11Araq_but I guess 'nim' is fine
20:01:25dom96meh fine
20:02:39*squirtle is now known as bulbasaur
20:02:59*bulbasaur is now known as nchambers
20:04:04dom96Sometimes I realise why some channels are +N
20:04:13dom96(No nickname changes)
20:04:58nchambersthat was the lasttime I promise
20:05:49dom96Araq_: Would you be okay with me splitting up setupVM?
20:06:21dom96into a proc which sets up the builtins that will always have the same implementation
20:06:26*nchambers quit (Changing host)
20:06:26*nchambers joined #nim
20:06:28dom96vs. stuff like switch()
20:06:30*nchambers quit (Changing host)
20:06:30*nchambers joined #nim
20:06:55dom96which will need to be different for nimble
20:07:14Araq_that split is already there
20:07:30Araq_but nimble likes the same builtins as nim, IMO
20:07:44Araq_so it uses nim's setupVM and builds stuff on top of that
20:07:56dom96I had to copy the setupVM proc
20:08:00dom96from compiler's sources
20:08:11Araq_hrm?
20:08:26Araq_iirc I just used it
20:09:12dom96https://github.com/nim-lang/nimble/blob/master/src/nimblepkg/nimscriptsupport.nim#L170
20:09:34dom96But maybe it's valid to just call registerCallback again?
20:10:11dom96so: vmdefs.setupVM(); blah.registerCallback("ProcWhichWasAlreadyRegisteredInVmDefs", ...)
20:10:53dom96like I said, I had to do that because what vmdefs.setupVM did was not good enough for Nimble
20:12:20dom96or rather not vmdef but scriptconfig: https://github.com/nim-lang/Nim/blob/devel/compiler/scriptconfig.nim#L28
20:12:29dom96https://github.com/nim-lang/Nim/blob/devel/compiler/scriptconfig.nim#L118
20:12:52dom96See what I mean?
20:17:48*vikaton joined #nim
20:28:16Araq_I see that you messed with 'switch' which you shouldn't have
20:35:21Araq_nimble doesn't need its own 'switch'
20:41:21dom96Araq_: Why do you think that?
20:42:02dom96what if I want to define a 'cr' alias which is just 'nimble c -r'?
20:42:59Araq_what if you don't? and what if you introduce your own nimbleSwitch proc?
20:43:53Araq_what if I like to use the *same* nimscript file for nim and for nimble and I don't want to wrap every call to 'switch' in a 'when not defined(nimble)' section?
20:45:11Araq_please think about your end users. 2 different impls for 'switch' is just annoying
20:45:24dom96huh?
20:45:38dom96I think you got this the other way around
20:45:53dom96if I introduce a 'nimbleSwitch' then you will need to use `when not defined(nimble)`
20:46:25Araq_not if I just want to call the switch for the nim compiler
20:46:53dom96Sorry, I don't understand what you mean
20:47:13Araq_right now I call 'switch' and the meaning is: set a Nim switch.
20:47:40Araq_you plan to change it into: set a Nim or Nimble switch, depending on what was invoked
20:48:07dom96yeah...
20:48:27dom96If you're invoking Nimble, how can you expect 'switch' to set a Nim switch?
20:48:41Araq_when I write
20:48:50Araq_task build:
20:49:00Araq_ switch("deadcodeelim", "on")
20:49:23Araq_it's pretty obvious I don't mean Nimble's deadcodeelim because that doesn't exist
20:49:46Araq_but if you override its behaviour for nimble, I need to do:
20:49:50Araq_task build:
20:49:56Araq_ when not defined(nimble):
20:50:00Araq_ switch(...)
20:50:18*sorakun quit (Remote host closed the connection)
20:50:26Araq_or disable the build task altogether for Nimble.
20:51:13dom96so you want the `switch` to do *nothing* in Nimble?
20:51:51Araq_yeah and that's what the current implementation does, albeit implicitly
20:51:52dom96Why would you invoke the `build` task in Nimble when it's meant for Nim?
20:52:17dom96an error is surely better than silently ignoring it
20:52:21Araq_because I enjoy not giving a fuck about whether it's "nim build" or "nimble build"
20:52:32Araq_to build my Nim based software
20:52:51Araq_that was one of the original ideas behind the nimscript support for both Nim and Nimble.
20:53:56dom96But there is a difference.
20:54:00dom96Nim != nimble
20:54:01Araq_likewise for common tasks like 'tests' and 'docs'
20:54:47dom96But more importantly, how about you calm the hell down.
20:55:26Araq_I'm calm but will watch my language
20:56:40dom96We either talk about this now, or I will implement it as I see fit and you will complain in 6 months that it's not right.
20:56:49dom96By then it will be too late.
20:57:02Araq_don't worry, I am calm.
20:57:22Araq_and we surely need to discuss it now
20:57:37dom96Right. I think your dream of not caring whether it's "nim build" or "nimble build" is impossible.
20:58:12Araq_that would be very sad. what are the reasons?
20:58:37dom96I may be wrong but here is that I think.
20:58:39dom96*what
20:59:40dom96It really depends on the use case. Let's say you want to create an alias for 'c'.
20:59:56dom96If you want to call it 'build' then you already have a problem
21:00:04dom96because 'build' is defined by Nimble already but not by Nim.
21:00:19Araq_(that's a Nimble bug then :P but go on)
21:00:36dom96If you name it 'build_this_shit' then the alias will work
21:00:43dom96but then 'nim c' != 'nimble c'
21:00:56dom96That said, it is close.
21:01:15dom96So actually, your `switch("deadcodeelim", "on")` *will* work.
21:01:26dom96inside the 'build_this_shit' task
21:02:19dom96But like I said, they are different.
21:02:58dom96The difference is small: 'nim c' looks at ~/.nimble/pkgs/ and adds the latest version of each package to its path.
21:03:12dom96So that the file you are compiling can "import jester" successfully.
21:04:09dom96'nimble c' calls 'nim c' with the --noNimblePath (or something like that) switch which disables this behaviour, it instead passes a list of paths explicitly which it builds itself.
21:04:24dom96The list of paths it passes is generated based on the dependencies specified in the .nimble file
21:05:02dom96So if your .nimble file doesn't specify "requires "jester >= 0.1.0"" then you won't be able to "import jester"
21:05:44dom96It also looks at the version range specified in the .nimble file and picks the right version (not just the latest like the Nim compiler does)
21:06:10dom96With me so far?
21:06:17Araq_sure
21:06:37Araq_and I have to admit I wasn't aware "nimble c" does all that
21:06:57Araq_but it makes sense
21:07:14dom96Indeed. You need to use Nimble more :P
21:07:30Araq_so "nimble build" is the "build properly caring about its dependencies"
21:07:45dom96yes
21:07:51Araq_and my "nim build" would be "build it according to the build task"
21:08:16dom96hrm, perhaps.
21:08:26*tyu joined #nim
21:08:27dom96Not sure what you mean by "according to the build task"
21:08:29Araq_well that's what it does already
21:08:45Araq_it looks for a task named "build" in the nims file
21:09:05dom96Oh, you mean because Nimble already defines a 'build'
21:09:24Araq_yeah
21:09:29dom96it does a bit more too
21:09:39Araq_o.O
21:09:51dom96it reads the 'bin' key in the .nimble metadata and builds the files specified there
21:09:55Araq_you mean "nimble build" does more than "nimble c"?
21:09:58dom96yes
21:10:05Araq_ah ok
21:10:07dom96'nimble c' takes a parameter
21:10:11dom96nimble build does not
21:11:12dom96But let's go back to 'build_this_shit'
21:11:52dom96in that case it is good that `switch` will also work in Nimble
21:11:55dom96instead of being ignored
21:12:43dom96So 1 point in my implementation's favour ;)
21:13:41Araq_I fail to see how
21:14:14dom96Ahh. I guess I forgot to mention another thing that 'nimble c' does
21:14:17dom96:P
21:15:00Araq_well, it's pretty obvious now how this thing should work
21:15:02dom96nimble c -d:release foo -> nim c -d:release <x> foo (where <x> is --noNimblePath and all the --path specs)
21:15:15dom96i.e. flags are passed to nim
21:15:28Araq_yeah ofc
21:15:29dom96Another scenario: https://gist.github.com/dom96/89ae2870b5733ea575b1
21:15:53dom96If you already knew that then you should understand why it's 1 point in favour of my implementation
21:16:30Araq_well no, sorry
21:16:34dom96but in this second scenario: I want to define a 'cr' task, which is just an alias for 'nimble c -r'
21:16:38dom96(or 'nim c -r'
21:16:39dom96)
21:16:50Araq_that means 'switch' *always* sets a compiler switch
21:17:08Araq_and only due to implementation details nimble needs to implement it differently
21:17:17Araq_so that it actually does the right thing
21:17:31dom96Hrm, okay. So in those scenarios, Nimble perhaps gets lucky.
21:17:38dom96Because it passes those flags to nim anyway
21:17:47Araq_it's a cool thing, but it's different from nimbleSwitch.
21:17:56dom96So please tell me another scenario where it would be different
21:18:05dom96I'm not sure what you mean
21:18:21dom96How is it different from nimbleSwitch?
21:18:23Araq_say nimble supports --verbose
21:18:44Araq_switch("verbose") means activate *Nim*'s verbosity
21:19:04Araq_nimbleSwitch("verbose") means activate Nimble's verbosity
21:20:21Araq_independently from whether I invoked "nimble build" or "nim build", switch("verbose") always means "make Nim verbose"
21:21:08Araq_but lets first switch the topic slightly
21:21:25Araq_so we know what "nimble c" means and what "nim c" means.
21:21:34Araq_and the distinction is cool.
21:21:58Araq_but the same should be for "nimble build" and "nim build"
21:22:51Araq_for "nim build" it's already the way I want it ... argh, no screw that
21:23:11Araq_it's way too late to change "nimble build", right?
21:24:32dom96maybe not, what do you want to change it to?
21:27:11*BitPuffin|osx joined #nim
21:29:29Araq_to be consistent with "nim build"
21:29:52Araq_but hrm
21:29:58Araq_this cannot work -.-
21:30:46Araq_or maybe hrm
21:31:24Araq_so what "nimble build" could do is the following:
21:31:53Araq_it runs the task "build" like Nim does, but Nimble has a different 'exec' implementation
21:32:28Araq_that patches things like "nim c foo.nim" to "nim c --noNimblePath --explicit-deps-here foo.nim"
21:32:54Araq_then it would be consistent with "nimble c foo" vs "nim c foo"
21:33:09Araq_but I'm not sure I like this.
21:36:20dom96nooo
21:36:39dom96if you're exec'ing 'nim' with specific args then that is what should happen
21:37:31dom96Is it really that bad to have two nimscript files?
21:37:35dom96one for nim and the other for nimble?
21:37:47dom96The Nimble one already will have a .nimble extension
21:38:19Araq_yeah but I planned to make the compiler accept .nimble in addition to .nims
21:38:28dom96that way I can keep the nimble-specific stuff implemented in nimble
21:38:46dom96it feels messy right now
21:38:50Araq_but I really like to have 1 file with the meta stuff in it
21:39:09Araq_that describes how to build the software
21:39:23Araq_and how to invoke tests, how to build the docs
21:39:26Araq_and its dependencies
21:39:39Araq_it's very friendly for our users IMO
21:40:10dom96it sounds to me like there is no point to even having nim itself supporting nims
21:40:21dom96what tasks will need to be nim-specific?
21:40:32dom96everything can just go into .nimble and be invoked via 'nimble'
21:41:14Araq_well Nims replaces Nim's old config system.
21:41:21Araq_which predates Nimble.
21:41:44Araq_so maybe you're right but what harm does Nim's nimscript support do?
21:42:24Araq_so yeah, 'nimble' can run every task and 'nim' only a subset of the available tasks
21:42:36Araq_seems fine to me.
21:43:14Araq_and it's a good thing since nimble can download stuff and Nim cannot.
21:43:51Araq_so if I run "nim foobar" I can be ensured it works when I'm offline
21:43:58Araq_*assured
21:44:15dom96Okay. So you are fine to have the nimble-specific stuff be separate from the nim-nimscript stuff?
21:44:37Araq_not for the tasks: build, tests and docs
21:45:04Araq_these should require no special casing for either nim or nimble.
21:50:56dom96In the long run I don't think Nim will be able to eval the .nimble file
21:51:23dom96So the metadata var definitions may as well be removed from system/nimscript.nim
21:51:33dom96and defined by Nimble itsel
21:51:33dom96f
21:52:02dom96For tasks like the ones you listed. I don't know, I guess you could put them in a .nims file, that way Nimble can still eval that
21:52:04dom96and so can Nim?
21:52:20dom96But then Nimble will need to first check the .nimble file, but also all the .nims files for tasks
21:54:55ekarlsoso what's hot in nimland ?
22:01:27dom96ekarlso: nimble getting nimscript support
22:03:13Araq_dom96: well .nimble can just include a .nims file for that
22:03:56dom96true, but it's nicer to make it automatic :P
22:04:30dom96The problem is: I doubt users will care, they will just put all tasks in the .nimble file
22:08:33dom96I suppose it's in their hands then
22:09:14dom96So, you're fine with me moving the var definitions (for the metadata: version, license etc) from the nimscript.nim file into Nimble?
22:14:03Araq_not really.
22:14:33Araq_it feels like giving up way too early
22:15:37Araq_and think about the 'version' problem
22:16:12Araq_const Version = '1.1' # foo.nimble
22:16:30Araq_from "foo.nimble" import Version # in the project.nim
22:17:03Araq_# doesn't work because .nimble is full of Nimble specific stuff
22:17:17dom96I don't think it will even work now
22:17:20Araq_but never mind, that problem exists with .nims too
22:17:24dom96yeah
22:17:25Araq_yeah
22:18:04Araq_for my newer projects I have an include file that just has that version const
22:22:33Araq_do we agree 'switch' should always set a Nim compiler switch?
22:22:55dom96Not if .nimble is only evaluatable by nimble
22:24:25Araq_lol
22:25:08*irrequietus quit ()
22:25:48*BitPuffin quit (Remote host closed the connection)
22:27:29dom96in that case it should set a Nimble switch
22:27:32dom96don't you agree?
22:28:27Araq_no, I know Nim's switches and they are all important but I cannot say the same for Nimble :P
22:30:07dom96But it will only ever be evaluated by Nimble
22:30:15dom96It doesn't make sense to leave it unimplemented
22:37:38Araq_hmm
22:47:41dom96well? :)
22:52:53Araq_IMO it's confusing if switch changes its semantics
22:53:16dom96but...
22:53:18dom96it doesn't
22:53:33dom96it's context-specific
23:00:45dom96well, that's how it is implemented right now
23:00:51dom96so I will just keep it
23:01:16dom96only thing needed now is to separate the nimble-specific stuff from system/nimscript.nim
23:07:19Araq_right.
23:07:32Araq_I just realized it's easier if I just accept everything you do.
23:09:37dom96lol
23:11:16dom96perhaps
23:11:20dom96But I want your opinion anyway
23:11:38dom96I guess when it comes down to us disagreeing...
23:11:50dom96may as well just pick one side
23:17:33Araq_well it's not important enough so go ahead and I will likely accept it
23:17:37*tyu quit (Quit: Connection closed for inactivity)
23:31:36*brson joined #nim