<< 10-03-2019 >>
00:10:01*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:12:04*ng0 quit (Quit: Alexa, when is the end of world?)
00:15:07*vlad1777d quit (Ping timeout: 240 seconds)
00:20:43*rnrwashere joined #nim
00:31:19*rnrwashere quit (Remote host closed the connection)
00:33:06*rnrwashere joined #nim
00:43:40*abm joined #nim
00:59:18*solitudesf quit (Quit: ZNC - https://znc.in)
01:03:47*solitudesf joined #nim
01:04:56*rnrwashere quit ()
01:18:26*abm quit (Read error: Connection reset by peer)
01:19:45ftsfwhat does " Error: usage of 'audioCallback' is a user-defined error" mean? with the line being: audioSpec.callback = audioCallback
01:24:56FromGitter<Varriount> ftsf: What library is this?
01:25:18FromGitter<Varriount> Sounds like some code is using the `error` pragma
01:25:45ftsfsetting audioSpec.callback in sdl2_nim: https://github.com/Vladar4/sdl2_nim/blob/master/sdl2/private/audio.nim#L169
01:26:52*lf-araujo quit (Ping timeout: 255 seconds)
01:30:11FromGitter<Varriount> ftsf: What's the full traceback?
01:30:23FromGitter<Varriount> Or full error message?
01:30:56ftsf..\..\nico\nico\backends\sdl2.nim(1047, 26) Error: usage of 'audioCallback' is a user-defined error no traceback
01:32:17ftsfwhat does user-defined error mean?
01:44:16FromGitter<Varriount> It means that an procedure or template was invoked that was decorated with the `error` pragma
01:49:23ftsfhmm can't find anything with an error pragma =\
01:50:25ftsfI guess it must be in the assignment operator
01:50:59*NimBot joined #nim
02:21:57FromGitter<gogolxdong> I saw
02:22:04FromGitter<gogolxdong> (https://files.gitter.im/nim-lang/Nim/yZqA/image.png)
02:50:37*Cthalupa quit (Ping timeout: 244 seconds)
02:53:26*Cthalupa joined #nim
03:02:39*banc quit (Quit: Bye)
03:25:33*banc joined #nim
03:52:38*rnrwashere joined #nim
04:11:14FromGitter<Varriount> ftsf: try turning the verbosity up
04:11:33*rnrwashere quit (Remote host closed the connection)
04:30:14*chemist69 quit (Ping timeout: 258 seconds)
04:31:38*dddddd quit (Remote host closed the connection)
04:32:16*chemist69 joined #nim
04:36:43FromGitter<kayabaNerve> @Varriount True devs debug by setting the verbosity to 0 and using a multimeter on their RAM.
04:39:57*rnrwashere joined #nim
04:44:43*rnrwashere quit (Remote host closed the connection)
04:45:21*rnrwashere joined #nim
06:17:54*arecacea1 quit (Remote host closed the connection)
06:18:13*arecacea1 joined #nim
06:22:32shashlick@gogolxdong - might be issues due to non-English setup
06:45:57*rnrwashere quit (Remote host closed the connection)
06:53:34*crem1 joined #nim
06:53:52*skelett1 joined #nim
06:57:57*spymasterd[m] quit (*.net *.split)
06:57:57*skelett quit (*.net *.split)
06:58:00*crem quit (*.net *.split)
06:58:01*xylef quit (*.net *.split)
06:58:02*yglukhov[m] quit (*.net *.split)
06:58:03*deansher quit (*.net *.split)
07:00:00*gmpreussner quit (Quit: kthxbye)
07:00:51*nsf joined #nim
07:00:58*narimiran joined #nim
07:01:40*banc quit (Ping timeout: 255 seconds)
07:03:09*banc joined #nim
07:04:56*gmpreussner joined #nim
07:26:17*banc quit (Ping timeout: 245 seconds)
07:32:29*banc joined #nim
07:35:36FromGitter<gogolxdong> yeah, the same thought here.
07:43:42*Trustable joined #nim
08:15:54*seerix quit (Ping timeout: 252 seconds)
08:19:09ftsfVarriout, hmm nothing new at higher verbosity levels, i'll try and trim stuff down to a smaller reproduction
08:21:09*chimez joined #nim
08:28:18*chimez quit (Quit: chimez)
08:31:08*seerix joined #nim
08:43:48*rockcavera quit (Remote host closed the connection)
08:48:39*Trustable quit (Remote host closed the connection)
08:52:52*rockcavera joined #nim
09:04:56*lf-araujo joined #nim
09:07:01*lf-araujo quit (Remote host closed the connection)
09:21:22*narimiran quit (Ping timeout: 250 seconds)
09:27:27*stefanos82 joined #nim
09:42:23*jjido joined #nim
09:50:14*Vladar joined #nim
09:50:34Zevvliquid600pgm and/or Araq, would you have time to listen to and comment on some of my musings?
09:58:37AraqZevv: shoot
09:58:53Zevvhttps://github.com/zevv/npeg/blob/master/README.md
09:59:36ZevvI made a lot faster progress on the PEG lib then I expected. PEGs are not constructed from a macro/DSL, but from Nim objects which can be combined with operators.
09:59:58ZevvThe LPEG way. This allows you to create parsers from Nim code, which is pretty flexible
10:00:20AraqI hate it.
10:00:23ZevvThe PEG patterns get compiled to a very simple row of VM instructions, which are parsed by a tiny machine
10:00:28ZevvYou hate it, I love it, whatever
10:00:31Araq;-)
10:00:56Araqconstructing the grammar at runtime is never what I need
10:01:01ZevvLater on I can provide any kind of macro DSL to construct stuff however you want
10:01:21Zevvon top of this. Construct from DSL, construct from text, construct from carrot cake, I dont care.
10:01:36ZevvWhat I want/need at this time is two things, nto sure if possible:
10:01:45Zevv- I'd like to get the stuff to compile at compile time into consts
10:01:55Zevv- I'd like to transliterate the compiled code into Nim
10:02:19ZevvThe first has to do with limitations of the Nim vm, and the second has to do with the fact that I will end up with goto's
10:03:35ZevvThe VM runs non-recursively and does it bookkeeiping on a little stack. Some instructions require the VM to jump around, which I have no clue how to translate to Nim, as we don't have gotos.
10:03:48Araqyeah, lots of problems, compile the grammar to Nim code, done. I'm tired of the inferior solutions, we have plenty of these already
10:04:06ZevvSo, what would be supirior then
10:04:08Araqbut there is actually an undocumented way to get 'goto'
10:04:20AraqI forgot how it works but 'lexim' uses it
10:04:39Zevvok, that's cool. But still, do you feel my current path leads to something usable?
10:04:40Araqkind of like 'var pc {.goto.}: int'
10:05:23Araqno, your current path has been done about 5 times already I never wanted to use the resulting systems
10:05:46Zevvbecause of what
10:05:59Araqhere is what you should do: compile the grammar to NimNode in a macro, that's what Nim was built for.
10:07:02Araqbecause the result is slower than handwritten code and gives you a bad API where you have case objects/methods etc, pretending you don't know the grammar at compile-time when you always do know.
10:08:14ZevvI like the API, but that's a matter of taste. The underlying mechanism can still work if I skip the intermediate language of course
10:08:30ZevvOk, I feel where you'd like this to go, let me see if I can find out how to get there
10:08:42Araqlisten to me please
10:08:55AraqPEGs are by their nature already hardly declarative at all
10:09:22*lf-araujo joined #nim
10:09:53Araqfor example '/*' .* '*/' doesn't match C comment syntax
10:10:06Zevvsure
10:10:23Araqthat * is literally a simple-minded 'while' loop
10:10:55Araq / is an ordered choice like 'if' does it
10:11:51Araqcompiling PEGs to Nim constructs is super-straightforward, no need to create a VM, no need to design much an API
10:12:20ZevvYeah, well, remember this is the first time I ever do something like this :/
10:12:29ZevvSo, yes, I'm listeing to you :)
10:13:14Araqhttps://nim-lang.org/docs/strscans.html#the-scanp-macro
10:13:59Araqscanp is pretty bad, I never use it, but it does get the translation process right
10:14:13Zevvok, I'll look into that
10:15:11Araqthis is a crucial idea: "The parsing is performed with the help of 3 helper templates that that can be implemented for a custom type."
10:15:31Araqscanp is bad because it's expression based so you cannot structure the grammar easily
10:16:11Araqand the inplace bindings 'E -> a' can be hard to read
10:19:27ZevvI'll do some playing around; Thanks so far - I'll probably get back to you with more at some time.
10:21:43Araqthese 3 helper templates make the macro fully type agnostic, something you don't get with an API
10:23:02ZevvTrue
10:24:41Araqcopy 'scanp's implementation, give it a different frontend and then you need one more thing, 'proc' generation so that you can have more than one syntax rule and rules can be recursive
10:39:10*lf-araujo_ joined #nim
10:40:16*lf-araujo quit (Ping timeout: 244 seconds)
10:40:16*lf-araujo_ is now known as lf-araujo
10:41:02*ng0 joined #nim
10:44:36ftsffound an interesting thing, initialising a sequence of procs raises type in regards to lock level Error: type mismatch: got <proc (self: Object): bool{.locks: 0.}> but expected 'proc (self: Object): bool{.gcsafe, locks: 0.}'
10:44:47ftsfbut initialising it empty and adding them individually works fine
10:50:16ftsfx.add([a,b,c]) has the same issues as x = @[a,b,c]
10:50:30ftsfbut x.add(a) x.add(b) x.add(c) is ok
11:02:09*sealmove joined #nim
11:02:47*brakmic joined #nim
11:03:45sealmovehi, Araq: why doesn't nimscript module work in nim secret?
11:04:53Araqbecause the REPL is not NimScript
11:05:02sealmovewhat exactly is it? :D
11:05:28Araqideally the REPL is a REPL for the full Nim language, NimScript is restricted to what the VM supports
11:06:19Araqftsf: how strange, can you report it please?
11:07:03sealmovein theory, is it possible to use compiler components (ast, parser, lexer etc) to construct a "proper" REPL?
11:07:27sealmoveor is there an innate limitation?
11:07:31ftsfAraq, yep!
11:12:39Araqwe now even have hot-code reloading for the native backend, there is no limit to what the REPL could do
11:24:06sealmoveAraq: what is the state with FFI in nimscript? I saw that you merged some changes 2 weeks ago but wrote that you will disable them later? I also tried using the compiler switch and it didn't work.
11:25:57FromGitter<BaldEagleX02> I have found a way to debug Nim efficiently in VS Code: https://github.com/pragmagic/vscode-nim/issues/65
11:28:09sealmoveI know I am late to the party :D but I want to understand what's happening
11:32:34*deansher joined #nim
11:34:28*dddddd joined #nim
11:43:06*nsf quit (Quit: WeeChat 2.4)
11:46:03*spymasterd[m] joined #nim
11:46:14sealmoveAfter reading carefully about hot-code reloading, I guess nimscript is becoming completely irrelevant
11:47:19*yglukhov[m] joined #nim
11:47:19*xylef joined #nim
11:50:40*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:51:29ftsfhttps://github.com/nim-lang/Nim/issues/10817
11:52:40dom96sealmove: it's not. Nimscript is still what is used for configuring Nim and in Nimble files
11:53:29sealmove@dom96: Sure. I mean it will stay in this niche, and not expand to something more.
11:54:09sealmove(irrelevant to repls and similar, I meant)
12:03:55sealmoveso is hcr ready to use?
12:04:13dom96has gc safety enforcement changes recently? https://github.com/dom96/jester/issues/188
12:04:26dom96*changed
12:28:36*sz0 quit (Quit: Connection closed for inactivity)
12:38:05*Trustable joined #nim
12:40:39*lf-araujo quit (Ping timeout: 244 seconds)
12:45:35*lf-araujo joined #nim
13:05:55*natrys joined #nim
13:06:31Araqdom96: yes, the compiler used to be too lax. but I'm thinking about a switch to mitigate the problem
13:06:50Araqthere is also a simpler solution that so far we overlooked
13:09:59Zevvscanp lacks ordered choice, which kind of changes the game, right
13:10:44Zevvhm nevermind, need more time reading up
13:10:55Araqno, it lacks it because attaching actions to 'or' is flawed
13:11:39Araqor because I never implemented it, it's not hard to do
13:12:50Zevvwell, that would require adding backtracking up to a certain level
13:13:25Zevvwhich is why I called it 'changing the game'
13:13:53Araqgiven that * doesn't backtrack either I don't think you need it
13:14:38Zevvhmm
13:14:40Araqsure it would be nicer with backtracking but then a really declarative grammar would also be nicer
13:15:32AraqI would focus on the rules first and that they can be mutually recursive
13:16:12Araqthen you can add the construct 'metaRule = ruleA / ruleB / ruleC'
13:16:30Araqand if the firstsets of these rules are disjoint you don't need backtracking
13:16:46Zevvyes, but in real life they are not
13:16:46Araqthat should be the class of LL(1) languages then
13:17:07AraqLL(1) is widely used in real life.
13:17:14ZevvCan't parse HTTP or SIP with that
13:17:28Araqthat's news to me
13:17:47Zevvthis is all new to me, so you're probably right
13:18:22Araqmost handwritten recursive descent parsing is naturally LL(1)
13:18:34*lf-araujo quit (Remote host closed the connection)
13:19:00Araqc2nim is the only parser I ever wrote that had to use backtracking
13:20:05Araqyou can get fancy and compute the firstsets and report if there is a conflict
13:21:41*rnrwashere joined #nim
13:23:29FromDiscord<Zireael> I don't understand - the top-level part is never executed, and if I indent it and/or move to where it's commented out, I get errors
13:23:29FromDiscord<Zireael> https://cdn.discordapp.com/attachments/371759389889003532/554293246117937152/Code_2019-03-10_14-22-37.png
13:24:30FromDiscord<Zireael> basically trying to do something like this but in Nim: https://github.com/mozdevs/gamedev-js-tiles/blob/6e25f5a891641cbe4d60bfbbaa11df01ff594add/common.js
13:24:45*brakmic quit (Remote host closed the connection)
13:25:14FromDiscord<Zireael> after all, withe core dom module, and the nimble html5_canvas, it ought to work - but I can't even get to the canvas part, I get stuck earlier
13:25:25*brakmic joined #nim
13:25:37AraqZevv: read this http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf page 18 following
13:26:35*brakmic quit (Remote host closed the connection)
13:26:52*brakmic joined #nim
13:27:15Zevvthans
13:27:16Zevvk
13:28:23*brakmic_ joined #nim
13:29:32AraqZireael: run the compiler from the command line to see what it says, nimsuggest probably doesn't know you use 'nim js ...'
13:30:53Araqdom96: what do you think about this idea: there is no .gcsafe effect anymore, --threads:on means you cannot use globals with GC'ed memory unless in a ``{.gcsafe.}: body`` block that checks at runtime it runs on the main thread
13:30:55*brakmic_ quit (Client Quit)
13:31:18*brakmic quit (Ping timeout: 245 seconds)
13:32:32Araqthe guarantees are in practice identical and we get rid of the .gcsafe annotation everywhere
13:33:39Araqand don't have to wait until the MM/GC become threadsafe for this, we can do it today.
13:34:52*brakmic joined #nim
13:36:04dom96Araq: That sounds good
13:36:40Araqany problems with the idea?
13:36:55dom96That I'm not sure about :)
13:37:03*rnrwashere quit (Remote host closed the connection)
13:37:26*rnrwashere joined #nim
13:45:17*brakmic_ joined #nim
13:47:58*brakmic quit (Ping timeout: 245 seconds)
13:48:34dom96oh man, recursive dependencies are really killing my productivity here
13:49:30*rnrwashere quit (Remote host closed the connection)
13:49:46*rnrwashere joined #nim
13:53:05FromGitter<Clyybber> Ugh, why is dart code so hard to read...
13:54:29*rnrwashere quit (Remote host closed the connection)
13:56:45*rnrwashere joined #nim
13:57:23*jjido joined #nim
14:14:04*nsf joined #nim
14:16:20FromGitter<gogolxdong> How to make svg work in Karax?
14:18:09*lritter joined #nim
14:30:32FromDiscord<Zireael> Araq: same error: canvas.nim(90, 14) Error: type mismatch: got <proc (ev: Event){.closure, locks: 0.}> but expected 'proc (event: Event)'
14:30:38*ofelas joined #nim
14:30:45*narimiran joined #nim
14:32:00FromDiscord<Zireael> same thing happens if I try to make the image loading a proc
14:38:06*abm joined #nim
14:44:11*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
14:45:30*jjido joined #nim
14:50:08*sealmove quit (Quit: WeeChat 2.4)
14:50:48*brakmic joined #nim
14:52:26Araqis it the same Event type?
14:53:26*brakmic_ quit (Ping timeout: 244 seconds)
14:58:17*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:23:34*vlad1777d joined #nim
15:32:19FromDiscord<Zireael> yeah
15:32:27FromDiscord<Zireael> the only thing I change is indentation
15:33:17FromDiscord<Zireael> I tried to work around this by writing a small js loader class and nim bindings, and I'm having trouble finding Nim equivalent of this:
15:33:17FromDiscord<Zireael> var Loader = {
15:33:17FromDiscord<Zireael> images: {}
15:33:17FromDiscord<Zireael> };
15:33:54FromDiscord<Zireael> I have written
15:33:54FromDiscord<Zireael> ''' type
15:33:54FromDiscord<Zireael> Loader* = ref object {.importc.}
15:34:12FromDiscord<Zireael> I have written
15:34:12FromDiscord<Zireael> ''' type
15:34:13FromDiscord<Zireael> Loader* = ref object {.importc.}
15:34:13FromDiscord<Zireael> images {.importc.} '''
15:34:33FromDiscord<Zireael> but I'm having trouble finding the correct Nim type so that it maps to {} and not null by default
15:34:43FromDiscord<Zireael> I have written
15:34:43FromDiscord<Zireael> ```type
15:34:43FromDiscord<Zireael> Loader* = ref object {.importc.}
15:34:44FromDiscord<Zireael> images {.importc.} ```
15:35:00FromDiscord<Zireael> I have written
15:35:00FromDiscord<Zireael> ```
15:35:00FromDiscord<Zireael> type
15:35:00FromDiscord<Zireael> Loader* = ref object {.importc.}
15:35:00FromDiscord<Zireael> images {.importc.} ```
15:35:22narimiranyour every edit is another message(s) on irc
15:35:44FromDiscord<Zireael> I was having trouble with formatting
15:35:53narimiranhttps://i.imgur.com/Rg6z5Cu.png
15:36:10FromDiscord<Zireael> bad irc bot then, sorry 😦
15:37:19FromDiscord<Zireael> if it matters, down the line images is used as a images[key] = value kind of a storage
15:39:03FromDiscord<Zireael> and I can't figure out the Nim equivalent of that - the key is a cstring and the value is... does it matter for the type definition?
15:55:06*onionhammer1 joined #nim
15:56:43*onionhammer quit (Ping timeout: 255 seconds)
16:00:39leorizeZireael: so if I understand this correctly, you'd like to map the images[key] = value of javascript in Nim?
16:05:10FromDiscord<Zireael> yeah, and init it to {} instead of null
16:05:35FromDiscord<Zireael> if it can't be done, I'll make a function on the js side and simply make a proc calling it, but...
16:06:30leorize`proc `[]=`(a: var <type of image here>; key: cstring; value: <type of value>) = {.emit: "`a`[`key`] = `value`".}`
16:06:38leorize^ should be something like that
16:07:02leorizethen you can do images[key] = value in Nim
16:07:16leorize```proc `[]=`(a: var <type of image here>; key: cstring; value: <type of value>) = {.emit: "`a`[`key`] = `value`".}```
16:07:28leorize(added more backticks for discord)
16:07:41FromDiscord<Zireael> nice, and whatt about initializing it to {} instead of null?
16:08:55leorizeI'm not entirely sure since I don't know what is `{}` in javascript
16:09:16leorizebut my guess is that you could make an init proc in Nim for that
16:09:49FromDiscord<Zireael> {} in javascript is an empty array
16:11:05leorize{.emit.} all the way :P
16:11:33Araqstop hacking around, understand the compiler's error message and make your code compile
16:11:57Araqgist it and ask for help on the forum. or here.
16:12:28FromGitter<liquid600pgm> actually, `{}` in JS is an empty object (so an empty `Table[K, V]` in Nim)
16:12:44Araqmost likely is you imported two different dom.nim modules so that Event is two different types and the compiler doesn't tell you
16:15:38FromGitter<syhpoon> Hey guys, ⏎ I'm trying to understands concepts in Nim and it seems like one cannot use a variable of a concept type as an object field: ⏎ ⏎ ```code paste, see link``` ⏎ ... [https://gitter.im/nim-lang/Nim?at=5c853829b4b6ef7bc888ede6]
16:18:28leorizeconcept is a kind of generic, so I guess you Wut type would have to be
16:18:43leorize```type Wut[T: MyT] = ref object[x: MyT]```
16:22:07*abm quit (Ping timeout: 240 seconds)
16:23:21FromGitter<syhpoon> okay, now it compiles successfully. Thank you leorize!
16:39:22FromGitter<liquid600pgm> wow, I didn't know it was possible to use concepts like that
16:39:32FromGitter<liquid600pgm> good to know
16:49:54*rnrwashere quit (Remote host closed the connection)
16:53:00*rnrwashere joined #nim
16:55:03*rnrwashere quit (Remote host closed the connection)
17:26:47*jjido joined #nim
18:21:15*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:25:15*ryukoposting joined #nim
18:26:21ryukopostingokay, so I successfully generated type definitions for each of the hundreds of "shapes" used by ec2 from its JSON spec
18:27:46ryukopostingthe problem is, those types form a massive tree of dependencies. I was hoping that, by turning all the objects (or as the AWS spec calls them, structures) into ref objects, the compiler could resolve all the types by just saying "oh this is a pointer"
18:29:49ryukopostingbut it seems like the compiler is still trying to traverse this massive, probably cyclic tree of type declarations. The JSON parser works like a champ, around 24000 lines of JSON parsed in under 2 seconds on my machine, but the compiler sits there for an unknown amount of time (I let it run for 5 minutes once) after the AST is already generated. I know it's sitting in the type declarations because if I remove
18:29:51ryukopostingthose, then the hangup disappears
18:31:27ryukopostingso the big bottleneck is resolving type dependencies, and that's a big problem bc it's /really/ slow, like I said
18:32:21ryukopostingthe compiler eats up more RAM than usual (~175MB) once it has 20000 lines worth of JSON tokens sitting in memory, but it's not overwhelmingly slow
18:33:04ryukopostingI was hoping someone with some insight into how the compiler resolves types might be able to offer me some advice on how to generate code that will play nice with it
18:33:14*jjido joined #nim
18:35:18*jjido quit (Client Quit)
18:41:19FromGitter<liquid600pgm> yay, `if` statements/expressions are now a thing in rod
18:43:57FromGitter<liquid600pgm> now `loop`, `for`, `while` and `loop...while`
18:44:32*brakmic quit (Remote host closed the connection)
18:44:59FromGitter<liquid600pgm> fortunately primitive loops (`loop, `while` and `loop...while`) are quite simple as they don't make use of an iterator protocol
18:48:18*jjido joined #nim
18:50:00*brakmic joined #nim
18:51:07ryukopostingliquid600pgm nice
18:51:26*jjido quit (Client Quit)
18:58:19*nsf quit (Quit: WeeChat 2.4)
19:01:20FromGitter<liquid600pgm> by the way, which do you think is better? `do...while`, or `loop...while`?
19:01:52ryukopostingwhat would a loop while be,
19:02:07*jjido joined #nim
19:02:09FromGitter<liquid600pgm> they're semantically the same, the only difference is the first keyword
19:02:20ryukopostingthe exact same thing as a do-while? I'd just stuck to traditional semantics unless changing it would offer a noteworthy benefit
19:02:49*jjido quit (Client Quit)
19:03:19FromGitter<liquid600pgm> I'm afraid `do...while` would clash with `do` blocks (they're blocks that evaluate to a single expression) in terms of readability
19:03:48ryukopostingthat's fair
19:11:46Araqryukoposting, type sections are processed in 3 phases but afaik there is no recursion or complex graph processing involved
19:12:03Araqso it should scale linearily
19:17:15*narimiran_ joined #nim
19:19:45*narimiran quit (Ping timeout: 268 seconds)
19:24:55*jjido joined #nim
19:26:50*jjido quit (Client Quit)
19:28:34shashlickAraq: can you please share why you think removing the vm from nimble is a good idea? My logic is that it allows nimble to evolve separately, inherits all nimscript improvements with zero effort and simplifies the code. But curious to hear your thoughts.
19:29:42shashlickAlso curious if nimble files should be compiled rather than run thru nimscript - will allow all sorts of possibilities
19:30:11Araqwell I'm out of words. Couldn't say it better than you did.
19:30:38AraqI also agree on compiling Nimble files, it's an interesting idea
19:31:24Araqthough it might be bad for "security". Better run 40K LOC Bash scripts aka ./configure instead ;-)
19:31:33*stefanos82 quit (Remote host closed the connection)
19:32:05shashlickThe only obstacles is setting an entry point - today, I'll have to modify the file every time you run a command
19:32:47shashlickWell I could have a generic main function too never mind
19:32:53dom96Compiling will be far too slow
19:33:18shashlickBut only need to compile once, then it can be cached
19:33:23Araqdom96, I think it can be cached
19:33:47dom96Removing the VM from Nimble is a good idea because having two separate binaries that implement the same things is a bad idea and leads to tons of incompatibilities
19:35:27shashlickSo assuming we can compile, where should we cache the binary
19:36:16Araq$home/.cache/nimblebins/$projectname/
19:36:36dom96lol, might just be crazy enough to work
19:36:41shashlickSame applies to generated nims file if that's the route we take
19:36:44dom96but no, just put the binary beside the .nimble file
19:39:03shashlickit could conflict with the project binary
19:40:22dom96not if you name it `projname.nimble.cache`
19:41:24*abm joined #nim
19:42:01shashlickon windows that will be projname.nimble.cache.exe
19:42:10shashlickreminds me of java 🙂
19:47:29*krux89 joined #nim
19:48:30dom96Doesn't have to be AFAIK, does Windows refuse to execute binaries that don't have the .exe extension?
19:50:18shashlicki'll try
19:50:48shashlickmeanwhile, can you please update choosenim's init.sh with the latest in git so that it starts working in git bash on windows
19:51:02Araqgive the exe its extension ffs
19:51:16AraqI hate extensionless files, it's like dynamic typing
19:51:57dom96shashlick: done
19:52:12dom96Araq: there are two extensions...
19:52:25dom96but yeah, alright
19:52:39shashlickyay it works
19:53:16shashlicknow need to get a new choosenim binary uploaded - 0.3.2 is so old
19:54:28*vlad1777d quit (Ping timeout: 250 seconds)
19:55:30ryukopostingthanks Araq
19:56:03*vlad1777d joined #nim
19:56:55shashlickdom96: to post a new choosenim, need a new tag - do you plan on bumping to 0.4.0
20:00:43shashlickgreat I need more init.sh fixes to run on travis - https://travis-ci.org/genotrance/feud/builds/504399550
20:02:33FromDiscord<hkg> anybodoy is using vscode nim extension?
20:03:05FromDiscord<hkg> 'cause, I'm having a weird error. `No 'nim' binary could be found in PATH environment variable`
20:03:09FromDiscord<hkg> but nim is in path
20:03:38FromGitter<Varriount> dom96: Technically you can execute binaries without the exe extension, however you would have to do it through the CreateProcess API call
20:04:33FromGitter<Varriount> Most Windows programs use `.exe` as a filter, rather than relying on the executable permission
20:04:49*narimiran_ is now known as narimiran
20:05:18narimiranhkg: wild guess, you added nim to path in .bashrc, and you use some other shell?
20:07:04FromDiscord<hkg> I'm on windows
20:07:29narimiranthen "have you tried to turning it off and on again" :D
20:07:53FromDiscord<hkg> yeah
20:13:48FromDiscord<hkg> idk what's wrong, it was working properly before
20:14:37narimirani just checked and nim plugin (unlike some other similar plugins) doesn't have an option to manually provide path to nim binary....
20:15:07narimiranand i'm not on windows so i cannot help you, sorry
20:15:43FromGitter<liquid600pgm> was `generic` a keyword in older versions of Nim?
20:15:46*Trustable quit (Remote host closed the connection)
20:16:14*jjido joined #nim
20:18:34*jjido quit (Client Quit)
20:23:25FromDiscord<hkg> what the-
20:23:44FromDiscord<hkg> every nim file is gone
20:24:17FromDiscord<hkg> 4 files in the entire *nim* directory
20:24:21FromDiscord<hkg> what happened
20:24:31FromGitter<liquid600pgm> what did you use to install Nim?
20:24:57FromDiscord<hkg> i manually installed it
20:25:01FromGitter<liquid600pgm> also, what's your Windows version?
20:25:16FromDiscord<hkg> win 10, of course
20:25:52FromGitter<liquid600pgm> I mean, which build (eg. 1803, 1809, or something)
20:26:16FromDiscord<hkg> https://i.imgur.com/hIbBpfk.png
20:26:55FromDiscord<hkg> and it's working now
20:27:09FromGitter<liquid600pgm> hm, strange
20:27:23FromDiscord<hkg> I've reinstalled nim
20:27:26FromDiscord<hkg> so it's working
20:27:34*xet7 joined #nim
20:27:36rayman22201hkg, windows has a "system" Path and a "user" path. which one is set?
20:27:50FromGitter<liquid600pgm> I thought this might be related to the Windows deleting files bug, but you're on an Insiders build, so probably not the case
20:28:02FromDiscord<hkg> both of them were set
20:28:10rayman22201depending on how the path was set, it could have been a temporary change.
20:28:18rayman22201Windows is weird about that
20:28:24rayman22201Reinstalling worked?
20:28:28FromDiscord<hkg> but, the problem was that
20:28:32FromDiscord<hkg> all files from nim directory
20:28:34FromDiscord<hkg> disappeared
20:29:17rayman22201weird
20:31:08ryukopostinghey dom96, so when nimble installs a package, how would I make it install miscellaneous resource files required by the package?
20:32:32solitudesfhttps://github.com/nim-lang/nimble#optional installDirs, InstallExt, installFiles
20:34:36ryukopostingnoice, thanks
20:38:07*jjido joined #nim
20:38:36ryukopostingok this is kinda strange
20:39:53ryukopostingi have a call to a macro that returns a fairly large chunk of AST, and putting a static: echo at the end of the file where the call is made, it never gets there even though a debug message right at the end of the macro prints just fine
20:41:22ryukopostingi think the type declaration block is just that massive, I'll have to change up how I approach it
20:43:06FromGitter<Varriount> ryukoposting: I have an update for that signing code.
20:43:15ryukopostingnice
20:43:23FromGitter<Varriount> It's going to need future updates to support S3
20:43:31ryukopostingI was having issues getting it to compile, missing calls to some external modules
20:45:19ryukopostingTIL declaring 1447 codependent types in a single type block is a bad idea
20:49:12FromGitter<Varriount> You need nimcrypto
20:49:24FromGitter<Varriount> That should be it though
20:49:45ryukopostingokay, I'll give it another shot
20:50:34FromGitter<Varriount> In total, it's two files, and nimcrypto
20:53:33*brakmic quit (Ping timeout: 244 seconds)
20:55:03*brakmic_ joined #nim
20:57:57*vlad1777d quit (Ping timeout: 245 seconds)
20:59:51*vlad1777d joined #nim
21:01:54*rnrwashere joined #nim
21:10:39FromGitter<kayabaNerve> Someone say Nimcrypto?
21:11:02FromGitter<kayabaNerve> :P
21:12:07FromGitter<kayabaNerve> Great lib. I hated how it required devel back in the 0.17 days though...
21:13:10*brakmic_ quit (Remote host closed the connection)
21:13:31*abm quit (Ping timeout: 255 seconds)
21:15:13*brakmic joined #nim
21:17:36*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:18:00*brakmic quit (Remote host closed the connection)
21:18:09*brakmic joined #nim
21:23:45*rnrwashere quit (Remote host closed the connection)
21:26:05*Vladar quit (Remote host closed the connection)
21:28:49*narimiran quit (Ping timeout: 255 seconds)
21:31:05*thomasross quit (Remote host closed the connection)
21:31:17*thomasross joined #nim
21:34:11*vlad1777d quit (Ping timeout: 268 seconds)
21:46:15*natrys quit (Quit: natrys)
21:50:41ryukopostinghow would i resolve paths to resource files for an installed nimble package? I can get it to put all the JSON files where I want them, but then I can't make a file path to them
21:52:09FromGitter<danielecook> Has anyone compiled a shared lib and loaded it into R?
21:53:08ryukopostingi have not
21:53:20ryukopostingnot too familiar with R, probably can't help sorry :(
21:54:00FromGitter<danielecook> well, it may be something obvious b/c I'm not too familiar with compiled languages
21:56:13FromGitter<danielecook> Was testing with this: ⏎ ⏎ ```dyn.load("test.so")``` [https://gitter.im/nim-lang/Nim?at=5c8587fd293ac75db586aeb6]
21:56:23FromGitter<danielecook> but it can't find the function
21:57:12ryukopostingdid you disable name mangling for the function you want to call?
21:57:40FromGitter<danielecook> Probably not. I do not know what that is! Coming from a python background here
21:58:07*Jesin quit (Quit: Leaving)
21:59:33*rnrwashere joined #nim
22:03:03*Jesin joined #nim
22:05:06ryukopostingoh, alright so inside a shared lib there are little strings that correspond with the functions exposed by the library
22:05:43FromGitter<danielecook> ok - so can you use a pragma to ensure they don't get mangled?
22:05:51FromGitter<danielecook> I was trying a few... .extern, .exportc
22:06:06ryukopostingin C, those strings are just whatever you named the function. However, in Nim, C++, Rust, and a lot of other languages, you can have many functions with the same name, so they get mangled so there's no collisions
22:06:07*rnrwashere quit (Remote host closed the connection)
22:06:18ryukopostingit's exportc, if I recall
22:07:24ryukopostingif you're using nimble, you'll want to be set up as a library project
22:07:41ryukopostingif you're just calling the nim compiler directly, you'll want to add the flag --app:lib
22:08:17FromGitter<danielecook> ok - yep looks like I got that
22:08:44FromGitter<danielecook> I think the issue might be something I am missing on the R side at this point because it can't find any 'symbols' in the library
22:10:16FromGitter<danielecook> Also nim can't seem to find the `.byref` pragma
22:10:39FromGitter<danielecook> test.nim(1, 42) Error: attempting to call undeclared routine: 'byref'
22:11:08*rnrwashere joined #nim
22:12:02ryukopostingcan you show me how you're using it?
22:12:30FromGitter<danielecook> ```proc add5(s: int): int {.exportc: "add5", byref.} = ⏎ return s + 5``` [https://gitter.im/nim-lang/Nim?at=5c858bce1fae6423ca640256]
22:12:48ryukopostingwhat are you trying to do
22:13:02FromGitter<danielecook> heh, ok, so R is a slow language
22:13:17FromGitter<danielecook> So i'm just trying to figure out how to call a function I compile in Nim from within R
22:13:31FromGitter<danielecook> Just as a starting point, I've written this function `add5` which adds 5 to a number
22:13:33ryukopostingbyref isn't a valid pragma to use on the return type of a pragma
22:13:45FromGitter<danielecook> right - ok I see...good point
22:13:48ryukopostingor shoot, on a function signature sorry lol
22:14:12FromGitter<danielecook> so the reason I was doing that to begin with is that the R FFI requires things to be passed by reference
22:14:29ryukopostingif you want to pass by reference, you can do something like proc add5(s: var int), probably the easiest way to do it while you're still getting used to the lang
22:14:57FromGitter<danielecook> ok i'll give that a go real quick
22:16:32dom96Maybe you want a `ptr int`?
22:17:10FromGitter<danielecook> hmm, I think the hold up here is probably more on the R side of things
22:17:29FromGitter<danielecook> If anyone is curious here is the background: http://adv-r.had.co.nz/C-interface.html#calling-c ... This may not be something I can figure out in an evening
22:17:56FromGitter<danielecook> Looks like the examples call some R-lib headers
22:18:17FromGitter<danielecook> However, I'll not that R also can run C++ code through a sep. interface
22:18:32ryukopostingoi dom, is it possible to get a relative file path at compile time
22:18:53FromGitter<danielecook> in any event, helpful start really appreciate it
22:18:56ryukopostingim trying to get it to successfully find some json resource files once nimble has installed it
22:19:07ryukopostingno problem, best of luck
22:20:01Araqhttps://github.com/nim-lang/RFCs/issues/142
22:24:24*brakmic quit ()
22:38:21*jjido joined #nim
22:44:43*rnrwashere quit ()
23:00:28shashlickdom96: why is this not working? https://travis-ci.org/genotrance/feud/builds/504445781 - I added -y to the install command
23:04:46*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:14:23Araqaww no feedback for https://github.com/nim-lang/RFCs/issues/142
23:14:31ryukopostingone sec
23:14:38Araqyou all like .gcsafe :-)
23:14:38ryukopostingyou're not gonna like me for this
23:14:47ryukopostingi like .gcsafe lol
23:14:51ryukopostingi actually like it a lot
23:15:16Araqwow, never heard that before, from anybody
23:15:40Araqbut I like you for it, it's always good to hear different opinions
23:16:05ryukopostingit's actually one of my favorite things about the language
23:17:02ryukopostingi think i've had to use a gcsafe block once, ever
23:18:09ryukopostingI kinda hint at this in the post, but it's not like Nim code looks like Rust, with unsafe {} blocks littered across the entire codebase
23:18:53ryukopostingI can see the argument, though. Sometimes it can be a little finicky. I think it's for the best though
23:19:53*catgirl joined #nim
23:20:02Araqwell what wins the debate for me is this: if you don't use globals the language is as safe as before, but without the .gcsafety idea
23:20:10catgirlhey
23:20:35Araqand if you use globals you're made to think about "oh this can only run on the main thread, ok"
23:21:10Araqmuch more ergonomic than writing .gcsafe to your callback types and forward declarations
23:21:27Araqhi catgirl
23:21:32ryukopostingI suppose. Sometimes there just isn't a good way around it, and I guess my approach to that would just be to remove global variables
23:21:44ryukopostingbut I'm not the language designer lol
23:21:58Araqthat's what the stdlib does, it replaced effectively all globals by .threadvar
23:22:10ryukopostinghello catgirl
23:22:40Araqso yeah, we use .threadvar much more often but still have to add .gcsafe to please the effect system god.
23:23:45ryukopostingmy worry is just that there's really only two combinations that keep Nim as safe as it is now- either leave gcsafe and threadvar alone, or remove gcsafe and make threadvar the default
23:24:14ryukopostingthe latter would probably be "safer" overall, but it would be kind of awkward and inconsistent with the rest of the language
23:28:54*rnrwashere joined #nim
23:29:03*rnrwashere quit (Remote host closed the connection)
23:34:20shashlickStruggling with choosenim tty issues
23:34:30shashlickWhat a bore
23:34:48ryukopostingwat
23:34:52ryukopostingwhat's wrong?
23:35:07shashlickhttps://travis-ci.org/genotrance/feud/builds/504445781
23:35:20shashlickTrying to get the init script working on Travis in windows
23:42:19ryukopostinglooks like a call to choosenim in init.sh is missing a -y
23:42:31ryukopostinghad the same thing happen on my gitlab CI scripts a few times
23:45:36shashlickI am editing the init file on Travis
23:45:43shashlickI've printed the output as well
23:45:50shashlickIt does get updated
23:47:14*ng0 quit (Quit: Alexa, when is the end of world?)
23:47:21ryukopostingweird
23:47:57ryukopostingi know almost nothing about travis, so I can't really comment on that part
23:53:31shashlickYa debugging remotely is a royal pain
23:55:29ryukopostingyeah, thankfully my pipelines are pretty straightforward lol
23:55:47ryukopostingpretty much use the same container for everything, then just call "nimble test" and let it do its thing
23:56:00shashlickWindows?
23:56:06ryukopostinglinux
23:56:12ryukopostingdevuan, specifically
23:56:18*lritter quit (Ping timeout: 245 seconds)
23:56:54shashlickNeat, I've been trying to expand choosenim init to work on windows so have to run into some roadblocks
23:57:01shashlickCan't be easy now can it
23:57:41ryukopostingthe most consistent way I've found to support windows is to not support windows, then tell people to install MSYS2
23:58:40shashlickWell this is in msys
23:58:46shashlickThat's what Travis runs
23:58:56ryukopostingwhich is crappy, but the dumb, weird little inconsistencies are not worth dealing with for any project that isn't specifically targeting windows
23:59:05ryukopostingoh interesting, i did not know that
23:59:24shashlickWell I think I should try bash instead of sh
23:59:33ryukopostingprobably yeah
23:59:36shashlickWho knows if that's different on windows
23:59:59shashlickDon't know why choosenim didn't see the -y though