<< 08-03-2019 >>
00:10:28*lf-araujo quit (Ping timeout: 245 seconds)
00:14:03*lf-araujo joined #nim
00:18:52federico3dom96: can I call jester's serve() when I need it without having to use manual routing like https://github.com/dom96/jester/blob/master/tests/example2.nim ?
00:19:23dom96https://github.com/dom96/jester/blob/master/tests/alltest_router2.nim#L5
00:19:44dom96this'll generate a proc called external_matcher (or something, check the macro)
00:20:30federico3thanks
00:22:11federico3dom96: initJester(external) works!
00:25:22shashlickwriting a text editor in nim has been an awesome experience
00:29:04shashlickscintilla also rocks - editor starts up in a second, uses 16megs ram, super responsive
00:36:16*freddy92 quit (Ping timeout: 246 seconds)
00:46:44FromGitter<gogolxdong> Isthat named scintilla?
00:47:38FromGitter<gogolxdong> VSCode seems never stable
00:50:35FromGitter<gogolxdong> besides 1.0 ,Nim needs a stable IDE
00:51:11federico3nimsuggests is your IDE :)
00:55:50*lf-araujo quit (Ping timeout: 255 seconds)
00:56:42FromGitter<gogolxdong> interested in adding a GUI？
00:59:59shashlickcheck out feud
01:00:04shashlickhttps://github.com/genotrance/feud/
01:00:42shashlickscintilla is a very popular source code editing component
01:00:47shashlickused by many editors
01:01:15shashlickunfortunately, i've focused mainly on features, zero on docs and user ramp up
01:01:17shashlicksoon I guess
01:05:17FromGitter<gogolxdong> hi, shashlick, good job. BTW,if the convention from QUIC cpp source is tricky, we will write from hand.Don't worry.
01:17:08FromGitter<gogolxdong> QUIC is in draft status though, I think we have time.
01:19:14shashlicksorry I totally forgot about QUIC
01:27:02FromGitter<gogolxdong> not your duty, still appreciate you are trying to offer help.
01:35:09*abm quit (Ping timeout: 252 seconds)
01:38:23FromGitter<gogolxdong> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c81c78e1fae6423ca4c2c78]
01:38:35FromGitter<gogolxdong> building on windows
01:41:39FromGitter<Varriount> @Clyybber What happens when you define `checkAbi`?
01:58:45*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
02:01:04*ng0 quit (Remote host closed the connection)
02:35:24*NimBot joined #nim
02:39:48FromGitter<gogolxdong> Does .nims file affect the same name nim file?
02:42:41FromGitter<kayabaNerve> Unless you name it `config.nims`, IIRC
02:45:42FromGitter<gogolxdong> good to know.
03:02:38*banc quit (Quit: Bye)
03:23:39*banc joined #nim
03:25:00*uptime quit (Ping timeout: 252 seconds)
03:30:14*bozaloshtsh_ is now known as bozaloshtsh
03:30:14*bozaloshtsh quit (Changing host)
03:30:14*bozaloshtsh joined #nim
03:33:58FromGitter<gogolxdong> How to integrate nimscript with nim source file? Like if something: exec "xxx"
03:35:16*uptime joined #nim
03:40:51*dddddd quit (Remote host closed the connection)
04:09:57FromGitter<genotrance> @gogolxdong can you delete build and try again
04:20:55*sealmove joined #nim
04:21:40sealmovehi, how do I restart Travis/Appveyor tests without changing PR?
04:32:56*chemist69 quit (Ping timeout: 258 seconds)
04:34:16*nsf joined #nim
04:34:48*chemist69 joined #nim
04:35:12*noonien quit (Quit: Connection closed for inactivity)
04:50:20FromGitter<genotrance> Close and reopen
04:51:26sealmoveoh thanks
05:13:12FromGitter<gogolxdong> @genotrance the same
05:15:08*Calinou quit (Remote host closed the connection)
05:16:17*Calinou joined #nim
05:18:24*rockcavera quit (Remote host closed the connection)
05:21:05*rockcavera joined #nim
05:22:13*ftsf joined #nim
05:25:28ftsfis there a way to get nim to log exceptions to the console on windows instead of (or in addition to) a MessageBox?
05:26:11ftsfIf I run a windows app via console i'd expect fatal exceptions to be logged there
05:26:54ftsfinstead of an uncopypastable message box
05:37:49FromGitter<gogolxdong> are you talking about fued?
05:39:29FromGitter<gogolxdong> feud
05:52:29shashlickya, weird need to check
05:53:30shashlickcan you update nimterop?
05:59:33*narimiran joined #nim
06:03:15FromGitter<gogolxdong> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c8205a325e4e24c0733f445]
06:03:28FromGitter<gogolxdong> seems unable.
06:04:15FromGitter<genotrance> can you uninstall then install?
06:08:41FromGitter<gogolxdong> http://ix.io/1CRa
06:10:38shashlickokay so even when it isn't there at all, it doesn't install
06:10:49shashlickyou get last gitter snippet?
06:11:22FromGitter<gogolxdong> what's that
06:11:33shashlickwait are you running in git bash?
06:11:57FromGitter<gogolxdong> on windows powershell
06:11:59shashlickyour paths are all linuxy
06:12:10shashlickcan you try in cmd
06:13:55shashlickI just tried in powershell and it worked fine
06:14:04shashlickit could be some old dependency
06:14:40FromGitter<genotrance> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c82084f0a6b915163f406c6]
06:15:03shashlickwhat version of nim
06:15:14FromGitter<gogolxdong> latest devel
06:21:32FromGitter<gogolxdong> I used the same code on linux subsystem to show you the error, it's messy code on windows.
06:21:57FromGitter<gogolxdong> ../../../lib/pure/includes/oserr.nim(85) raiseOSError ⏎ Error: unhandled exception: Permission denied [OSError]
06:25:48sealmoveguys what's up with this: https://ci.appveyor.com/project/Araq/nim/builds/22918494/job/3r9v27wntbs56uii ?
06:30:02shashlickweird - can you run nimble in debug mode
06:31:16shashlicksealmove: try rerunning
06:32:12shashlickthought I had access to Nim's AppVeyor, doesn't look like
06:35:15*sealmove quit (Quit: WeeChat 2.4)
06:35:36FromGitter<gogolxdong> http://ix.io/1CRg
06:37:20shashlickdid you git pull latest?
06:37:29FromGitter<gogolxdong> rm -rf nimterop/ ⏎ rm: cannot remove 'nimterop/': Permission denied
06:37:29shashlicklooks like it is still installing old stuff
06:37:46FromGitter<gogolxdong> trying to remove these
06:38:21shashlickdo you have a console or explorer open to that dir?
06:38:24FromGitter<gogolxdong> no opened stuff references to nimterop
06:38:29shashlickwindows is a pain with such things
06:39:40FromGitter<gogolxdong> ok, deleted
06:40:03FromGitter<gogolxdong> Let me try again.
06:40:23*jjido joined #nim
06:42:29FromGitter<gogolxdong> feud, the same
06:44:19FromGitter<genotrance> please try in a regular cmd window
06:46:30FromGitter<gogolxdong> ... ccmd: cmd /c cd D:\feud\build\scintilla && git remote add origin https://github.com/mirror/scintilla ⏎ ⏎ ``` ... result: ⏎ ... fatal: remote origin already exists.``` [https://gitter.im/nim-lang/Nim?at=5c820fc61c597e5db6a14e88]
06:49:05FromGitter<genotrance> how is that possible - if build directory was only just created
06:49:59shashlickso if you rm -rf build and then try again, it still says the same?
06:50:43FromGitter<gogolxdong> yes, I managed build.
06:51:41FromGitter<gogolxdong> nim c -r -d:release --hints:off feud.nim
06:54:46shashlickwhat version of git do you have
06:55:31FromGitter<gogolxdong> git version 2.20.1.windows.1
06:55:45shashlickso if you mkdir build, cd build, git init, git remote add origin https://github.com/mirror/scintilla it fails?
06:55:59shashlickthat's all I'm doing - https://github.com/nimterop/nimterop/blob/master/nimterop/git.nim#L105
06:57:04FromGitter<gogolxdong> this works
06:58:19FromGitter<gogolxdong> there might be some magic there .
06:59:10FromGitter<genotrance> probably - only thing i can think of is that build already exists from a previous run but the dirExists fails for some reason
06:59:20FromGitter<genotrance> but if you deleted build and tried from scratch, it should have worked
06:59:26Araqdamn, I now want 'ref' deeply immutable for parameters and 'let' vars. We could have 'mut' as a parameter modifier
07:00:32Araqit would be the right default for the nim compiler, at least
07:01:05FromGitter<gogolxdong> cloning manually now.
07:03:56*PMunch joined #nim
07:04:54FromGitter<gogolxdong> seems var ,ref, let will change, and an additional parameter modifier.
07:06:33FromGitter<gogolxdong> need to comment the static :gitPull() to get it work?
07:07:20shashlickya otherwise it will fail again
07:11:54FromGitter<gogolxdong> Does it process dependencies like C++, as you use the same recursive include?
07:12:56FromGitter<gogolxdong> besides nanomsg gitPull error ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c8215f8d3b35423cb8350cc]
07:15:35FromGitter<gogolxdong> I found it compiles slower than normal, or is it just a large code base?
07:15:46shashlickscintilla is big
07:15:52shashlickand there's many plugins it is compiling
07:16:23FromGitter<gogolxdong> still faster than C++ right?
07:16:34FromGitter<genotrance> hat's the output
07:16:42FromGitter<genotrance> if something fails compile, it retries
07:17:23shashlickhold on, i'm making a build
07:23:31*krux02 joined #nim
07:33:44FromGitter<gogolxdong> I noticed scintilla compiled to a static link library, which takes about two minutes, does nimterop do the same and take the same magnitude time？
07:35:57shashlickit only has to compile once
07:36:06shashlickafter that those object files don't change
07:36:47*vlad1777d quit (Ping timeout: 240 seconds)
07:37:59*vlad1777d joined #nim
07:39:00FromGitter<gogolxdong> I am aware of that. Wonder the comparison in theory between using nimterop and the native C++ .
07:39:27FromGitter<gogolxdong> for the same static link library.
07:40:34shashlicknot sure what you are asking, but nimterop only processes the header files
07:40:47shashlickand after first time, it caches the result so recompiles are negligible
07:43:08shashlickfor example, I just recompiled feud in 5.6 seconds since most other stuff was done before
07:43:15FromGitter<gogolxdong> Araq told me the worst of C++ compilation time is exponential and Nim's is linear.
07:44:46FromGitter<gogolxdong> Does it apply to nimterop compiling?
07:45:14*vlad1777d quit (Ping timeout: 250 seconds)
07:46:34*vlad1777d joined #nim
07:48:44shashlickI don't understand - nimterop is like c2nim - it goes thru the header file once
07:48:58shashlickAnd it doesn't understand c++, yet
07:53:40*chimez joined #nim
07:55:00FromGitter<gogolxdong> my bad, C++ has gone, here comes C, I want to express that c compiler parses headers recursively which causes worst compilation time, does c2nim change this effect?
07:56:11shashlickall nimterop (and c2nim not sure) do is make a single pass over the header file and make a simple wrapper in nim
07:56:56shashlickthe logic isn't that complicated since I am only extracting data types and procs
07:57:25*disruptek quit (Quit: Bye)
07:57:44*disruptek joined #nim
07:59:56*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:00:00*gmpreussner quit (Quit: kthxbye)
08:02:29FromGitter<gogolxdong> ok, I lost fundamentals of compiling.
08:03:31FromGitter<gogolxdong> What's the result of your building? window.nim(45, 21) Error: type mismatch: got <LRESULT> but expected 'int'
08:04:32*gmpreussner joined #nim
08:07:04shashlickwell, it should implicitly convert SendMessage's return value from LRESULT to int
08:07:12shashlickdo you have a global strict flag set
08:08:32FromGitter<gogolxdong> where to set the flag
08:11:15shashlickwhat version of winim do you have installed
08:12:44shashlickweird, it compiles fine here, what magic do you have on your machine!
08:14:22*Vladar joined #nim
08:15:43*jjido joined #nim
08:15:47FromGitter<liquid600pgm> I might take a shot at creating a dedicated IDE for Nim
08:16:02FromGitter<liquid600pgm> but I want to complete my current project first
08:19:45FromGitter<gogolxdong> winim 2.6
08:24:38*banc quit (Quit: Bye)
08:25:20shashlickhttps://github.com/genotrance/feud/releases
08:25:39*banc joined #nim
08:27:39shashlickliquid600pgm - please check out feud before you go all out
08:27:55*banc quit (Client Quit)
08:27:59shashlick@gogolxdong - does it run?
08:34:27*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:36:04shashlickRun the exe, it will extract some files and start the gui
08:36:22shashlickCheck out feud.ini for the keyboard shortcuts
08:36:44shashlick^e to type commands
08:38:14shashlickopen path\*.nim
08:38:25*JustASlacker joined #nim
08:38:58shashlickOnce files are loaded, you can fuzzy switch or use ^1 etc
08:39:28shashlickopen fl for file.nim
08:40:12shashlickOther commands show up in the console - listed by each plugin as it loads, most are used internally but you'll get the idea
08:40:26shashlickAnyway headed to bed, thanks for trying
08:46:56*chimez quit (Quit: chimez)
08:51:09*cornfeedhobo quit (Quit: ZNC - https://znc.in)
08:54:10*banc joined #nim
08:59:09*cornfeedhobo joined #nim
08:59:30FromGitter<gogolxdong> have a good dream.
09:02:43*floppydh joined #nim
09:25:05*abm joined #nim
09:59:13narimiranhttps://forum.nim-lang.org/t/4704
10:00:59*stefanos82 joined #nim
10:03:04FromGitter<Vindaar> Sounds great to me!
10:11:04Araqseems flawed to me ;-)
10:13:33Araqbut probably can be saved if the code style is adapted so that mutations don't span multiple proc calls
10:18:28FromGitter<Vindaar> Mind you, I'm neither knowledgeable enough, nor have thought enough about it. I can see that it might introduce subtleties, e.g. what you raise in your last post (block 2)
10:18:52FromGitter<Vindaar> If the implementation is sound and well explained in the manual, I'd really like to have it :)
10:19:41Araqaliasing seems to kill it, in 'var someLocal = f(args)' we have to assume that 'someLocal' aliases every possible 'arg'
10:20:14Araqand then any assignment like 'someLocal.field = val' has to be rejected
10:20:58Araqthe only question is how often it comes up in practice
10:21:30*stefanos82 quit (Remote host closed the connection)
10:23:02Araqif it comes up, you need to mark some parameters as 'mut' even though they are not and then 'mut' bubbles up in your entire codebase
10:23:38Araqor we introduce: {.harmless.}: someLocal.field = val to make the compiler shut up
10:26:24AraqI think we simply cannot win with 'ref', introduces 'nil', introduces wild aliasing, introduces wild sharing, requires a GC mechanism for cleanup, requires separation logic for proof engines
10:27:14*ng0 joined #nim
10:29:00*vlad1777d quit (Ping timeout: 244 seconds)
10:30:24*vlad1777d joined #nim
10:30:56FromGitter<Vindaar> I'm not quite following how `someLocal` (and its fields) are related to the `args` of `f` in general
10:35:48Araqwe don't know what 'f' does
10:35:53Araqconsider this:
10:36:08Araqproc p(param: Node) =
10:36:26Araq var v = id(param)
10:36:31Araq v.field = value
10:36:52Araqproc id(n: Node): Node = n
10:37:27Araqwe must reject 'p'
10:37:39Araqas it mutates what 'param' points to
10:39:03FromGitter<Vindaar> ah, was just writing up something like this in words. Yeah, whereas if `id` was something harmless, it'd have to be `param: mut Node` regardless, because we cannot know it is (unless we use your pragma above)
10:39:27Araqin order to reject it, we have to assume that 'id(param)' creates an alias to 'param' (and indeed that's what it does)
10:39:46Araqbut that assumption is conservative and will bite us.
10:39:52FromGitter<Vindaar> yep
10:39:55Araqthe only question is how hard it will bite us
10:47:03Araqah we can also disallow proc id(x: Node): Node = result = x as it turns an immutable ref into a mutable one
10:47:24Araqbut then 'proc find(...): Node' becomes impossible to write
10:49:43Araqhowever, whether to mutate find's result should be the caller's decision, not find's
10:50:47FromGitter<mratsim> According to Linux Torvalds after 0.20 we must release 1.0 because we won't have enough fingers and toes for the new versions.
10:53:29narimiran@mratsim, yeah, i really hate when people ask me which nim version i'm using, and i always respond the same: "wait, i need to remove my shoes to tell you that"
10:53:41FromGitter<mratsim> :D
11:00:52Araqstudying the compiler further, mutable refs as parameters are everywhere
11:01:40Araqparameters are the wrong granularity, a field based analysis would be much more useful, .writes: [PSym.loc.r, PNode.sons, PType.sym]
11:02:28Araqwith .writes: [] the juicy special case as before
11:20:22*cgfuh joined #nim
11:52:27Araqyay, https://www.techspot.com/news/79038-microsoft-introduces-drastic-performance-fix-spectre-variant.html
11:52:47Araqugh, https://www.zdnet.com/article/all-intel-chips-open-to-new-spoiler-non-spectre-attack-dont-expect-a-quick-fix/
11:52:49Araq:D
12:00:01*waleee joined #nim
12:02:08*matthias__ joined #nim
12:06:43*pwntus quit (Ping timeout: 245 seconds)
12:07:58*dddddd joined #nim
12:11:15*pwntus joined #nim
12:21:41*noonien joined #nim
12:38:57*lritter joined #nim
12:40:13*stefanos82 joined #nim
12:44:08FromGitter<Clyybber> I just disable the spectre fixes. They are more of a theoretical issue, and most/all? browsers already have their own protections against spectre
12:44:25Araqlol
12:44:59Araqit's "security", the one noun that disables thinking
12:45:15*cgfuh quit (Ping timeout: 268 seconds)
12:45:46FromGitter<Clyybber> I mean if we care so much about security, why not also protect against ram hammering
12:46:09FromGitter<Clyybber> and enforce a delay between successive writes...
12:46:20FromGitter<Clyybber> at some point it gets stupid
12:49:28FromGitter<Clyybber> @Varriount Thanks for the help, using `-d:checkAbi` makes it not compile anymore: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c8264d81fae6423ca5015a7]
12:51:02Araqah nice
12:57:10FromGitter<Clyybber> Araq: What does it mean?
13:00:59FromGitter<Clyybber> Araq: Also this happens for every programm using iterators and compiled with `-d:checkAbi`
13:01:03FromGitter<alehander42> @flyx ?
13:01:28FromGitter<alehander42> is there a way to force nimyaml to check for uppercase labels of fields even if the nim name is lowercase
13:07:18*Snircle joined #nim
13:08:40AraqClyybber: well I need to investigate, you're on Linux, right?
13:08:51FromGitter<Clyybber> Yeah
13:11:29FromGitter<alehander42> hm, it's not fatal, i can define templates with lowercase or just use uppercase field names
13:11:48FromGitter<alehander42> note to a future reader: default values can be used to get an "optional" field in nimyaml
13:35:28*Cthalupa quit (Ping timeout: 245 seconds)
13:36:14*Cthalupa joined #nim
13:47:05*sealmove joined #nim
13:49:41FromGitter<liquid600pgm> how to check if a type is compliant with a specific concept?
13:49:54FromGitter<liquid600pgm> is it just `val of SomeConcept`?
13:52:28*cgfuh joined #nim
13:54:06Araqval is SomeConcept
13:54:15Araq'is', not 'of'
13:54:26FromGitter<liquid600pgm> aah
13:54:39FromGitter<liquid600pgm> so `of` is used strictly for object inheritance?
13:55:16FromGitter<Clyybber> And in case statements :P
13:55:48FromGitter<liquid600pgm> (I know about case statements, I was referring to `of` as an "infix-like" operator)
13:56:34sealmoveAraq: Hi, I have question
13:59:28sealmoveIn nimeval.nim, in the proc `createInterpret`, these lines of code are included: https://pastecode.xyz/view/e750d781 but I couldn't find something like that when tracking nim secret code. Are these settings made somewhere (for example somenim configuration file)?
14:00:20Araqno.
14:00:35AraqI think they simply do it differently
14:02:01sealmoveSo I think they shouldn't be included in `runRepl` either... I changed the implementation to much the way nim secret does it, so I don't use createInterpreter in it. Your answer in the PR was pointing to older commit.
14:02:10sealmoveto match*
14:04:24*Cthalupa quit (Ping timeout: 250 seconds)
14:05:46*Cthalupa joined #nim
14:11:56FromGitter<Clyybber> Is shl and shr unsigned or signed in nim?
14:12:08FromGitter<Clyybber> Or does it depend on the type of the input?
14:14:15narimiran@Clyybber there is `ashr` also, don't know if you're aware of it: https://nim-lang.github.io/Nim/system.html#ashr%2Cint64%2CSomeInteger
14:14:35FromGitter<Clyybber> Ah yeah, I remember an issue about it.
14:18:53FromGitter<Clyybber> Can an `{.inline.}` proc be faster than a template??
14:22:23Araqit's always unsigned and there is ashr
14:23:21FromGitter<Clyybber> Ok, thanks
14:26:40FromGitter<liquid600pgm> is it possible to use a `case` statement on a type like this? ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c827ba03162ec7bc73c382c]
14:30:11FromGitter<liquid600pgm> nvm, my specific problem can be solved with `method`s
14:30:13FromGitter<Clyybber> Maybe in a static context, I guess the best way to find out is to try it out
14:31:29FromGitter<liquid600pgm> what I had was a bunch of objects which all inherited from one object, and I had to call the appropriate `call` proc for a specific type. multi-methods solve this problem perfectly
14:32:16FromGitter<Clyybber> Multimethods are about to get deprecated/removed
14:32:22FromGitter<AchalaSB> hey, I'm trying to compile Nim-C-wasm, Able to compile to C ⏎ While compiling C to wasm getting this error ⏎ ⏎ ```code paste, see link``` ⏎ ... [https://gitter.im/nim-lang/Nim?at=5c827cf67851db13498bb377]
14:32:38FromGitter<liquid600pgm> @Clyybber why is that?
14:32:50FromGitter<liquid600pgm> and what should I use as a replacement?
14:32:55FromGitter<Clyybber> @liquid600pgm But I think you aren't using multimethods. AFAICT you are using single-dynamic dispatch
14:33:14FromGitter<Clyybber> @liquid600pgm Because mulit-dynamic dispatch is hard/unneccessary most of the time.
14:33:43FromGitter<liquid600pgm> I'm confused now
14:33:50FromGitter<Clyybber> @AchalaSB Funny, I just had a similar issue above
14:33:56FromGitter<liquid600pgm> so what's the `method` syntax for?
14:34:26FromGitter<Clyybber> @liquid600pgm Its for dynamic dispatch, meaning it decides which method to call at runtime based on the type of the object
14:34:55FromGitter<liquid600pgm> that's what I need, but what's the difference between single- and multi-dynamic dispatch?
14:35:23FromGitter<liquid600pgm> is single just calling a single proc and multi calling multiple procs?
14:35:26FromGitter<Clyybber> Multi-dynamic dispatch is when it decides what method to call based on multiple objects at runtime
14:35:29FromGitter<AchalaSB> @Clyybber ohh, your issue fixed?
14:35:40FromGitter<Clyybber> Nope :P
14:35:48FromGitter<liquid600pgm> ahh, I understand that now
14:35:52FromGitter<liquid600pgm> thanks
14:37:31*sealmove quit (Quit: WeeChat 2.4)
14:38:04*hoijui joined #nim
14:55:07FromGitter<liquid600pgm> can the call operator be overriden for user-defined types?
14:55:21FromGitter<liquid600pgm> or is it reserved for procs and similar things?
14:55:24Zevvi believe so, but you need some exerimental pragma iirc
14:55:39FromGitter<liquid600pgm> oh well
14:56:15*PMunch quit (Remote host closed the connection)
14:56:33Zevv{.experimental: "callOperator".}
14:57:26FromGitter<liquid600pgm> I want to stick to stable features for now, so I won't be using it. I'll just create a `call` proc instead
15:00:28*cgfuh quit (Ping timeout: 255 seconds)
15:01:43Zevvfair enough
15:02:16*JustASlacker quit (Remote host closed the connection)
15:04:08FromGitter<Clyybber> @liquid600pgm OTOH if nobody tries them out, they wont stabilize.
15:06:32FromGitter<liquid600pgm> it seems the feature is stable in the latest #devel release
15:07:39FromGitter<liquid600pgm> oh wait, it's something different
15:08:17FromGitter<liquid600pgm> when was the feature implemented? I'd like to support Nim 0.19.4 as the minimal required version for my project
15:16:16Araqplease don't use the callOperator
15:16:34Araqit's too clever, a little more syntax often goes a long way
15:19:25*rnrwashere joined #nim
15:20:59*rnrwashere quit (Client Quit)
15:22:41ryukopostingdoes anyone know if the os library's filesystem browsing procs will work at compile time?
15:24:33shashlickSome of them don't work - cp, mv etc
15:24:37shashlickWalk
15:25:14shashlickSee poor man's versions here https://github.com/nimterop/nimterop/blob/master/nimterop/git.nim
15:26:26ryukopostingsick
15:26:58ryukopostingI wrote some of my own stuff like that for another project, might just reuse that stuff since afaik it should work fine
15:28:14narimiranhey ryukoposting! we're waiting for your next video :)
15:28:47ryukopostingyeah, i haven't gotten around to finalizing the content for it yet
15:28:56ryukopostinglast few weeks have been pretty busy
15:29:08ryukopostingexpect the next one to be out in around 2 weeks
15:29:43narimiranno worries. i know how much it takes to make some "short instructive example"
15:30:02*krux02 quit (Remote host closed the connection)
15:30:03narimiranpeople see the final product and think "i could type that in 10 minutes"
15:31:50FromGitter<Clyybber> Thats a common misconception people have about the time it takes to write concise examples/explanations. They often underestimate the many iterations of work it takes to arrive at a concise simple and understandable text.
15:32:10narimiranexactly
15:33:16FromGitter<Clyybber> `152 additions and 790 deletions` feels good man...
15:33:23FromGitter<Clyybber> now to actually understand the code...
15:41:47*noeontheend joined #nim
15:44:35*Trustable joined #nim
15:54:04*freddy92 joined #nim
16:01:04*freddy92 quit (Read error: Connection reset by peer)
16:19:11FromGitter<arnetheduck> btw, Araq, you mentioned you didn't like `experimental` as a std lib folder because if it turns out that the api is good/stable, you have to break everyones code.. here's an option: introduce an `{.unstable.}` pragma that enables the thing of you pass `-d:experimental:unstable`.. this way, those on the bleeding edge can opt in, and for those api that are deemed ok, you just remove unstable, breaking no code that
16:19:11FromGitter... was working before
16:20:34*rnrwashere joined #nim
16:21:58Araqok but -d:nimUnstable would accomplish the same without a compiler feature
16:22:31*rnrwashere quit (Remote host closed the connection)
16:22:53FromGitter<arnetheduck> granted, you can do it with a `when`
16:23:03*shashlick quit (Remote host closed the connection)
16:23:25*shashlick joined #nim
16:24:23FromGitter<arnetheduck> that said, all of these are non-problems with a better pm :)
16:27:50FromGitter<Clyybber> using a `when` seems like a good idea.
16:34:35Araqsome people cannot use a PM, no matter how good it is
16:36:49FromGitter<Clyybber> what does "PM" stand for in this context?
16:37:13FromGitter<arnetheduck> if you're talking about offline capabilities, good pm's have that also
16:39:32CalinouPM = package manager
16:40:11*rnrwashere joined #nim
16:40:54Araqbtw, I thought it through, cannot work, https://forum.nim-lang.org/t/4704
16:41:30*rnrwashere quit (Remote host closed the connection)
16:41:58Araqyou either need more language extensions or you need to be conservative.
16:42:41Araqand with the conservative analysis you end up having to annotate 'mut' where you don't want to and a wrong 'mut' quickly bubbles up
16:43:37*nsf quit (Quit: WeeChat 2.4)
16:43:54Araqthe potential aliasing kills most attempts of enforcing immutability.
16:45:53*rnrwashere joined #nim
16:46:18Araqesp if you use 'ref' for what it was designed, complex arbitrary graph-like structures.
17:01:30*rnrwashere quit (Remote host closed the connection)
17:02:24*rnrwashere joined #nim
17:03:09FromGitter<Varriount> This is sounding like one of those n-complete problems
17:06:27*rnrwashere quit (Ping timeout: 240 seconds)
17:08:53Araqas an effect on Type.field it would work and it would be simple, but it would be yet-another effect. Maybe it's worth it, maybe not.
17:11:00*cgfuh joined #nim
17:19:17FromGitter<liquid600pgm> is there any way to get the *actual* type passed to a proc? like this: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c82a415f895944c0860c111]
17:19:57FromGitter<liquid600pgm> what I need to do is print the actual type, eg. when you pass A it echos `A`, when you pass B it echos `B`
17:27:50shashlickfinally got a readme up - https://github.com/genotrance/feud/
17:28:55*vlad1777d quit (Ping timeout: 268 seconds)
17:30:30*vlad1777d joined #nim
17:30:46*Tortice joined #nim
17:30:52*abm quit (Ping timeout: 245 seconds)
17:31:02*rnrwashere joined #nim
17:32:38TorticeHi, I have a simple (in my head, anyway) program, which I don't know why is failing
17:32:59TorticeThe source: http://0x0.st/zH-1.nim and the build/run output: http://0x0.st/zH-Q.txt
17:33:07Torticeif the last for loop is removed, it runs fine
17:35:39*rnrwashere quit (Remote host closed the connection)
17:37:09narimiran" ## Iterator for the items of `node`. `node` has to be a JArray."
17:37:38narimiranyour page is not `JArray` so you cannot iterate over it
17:38:32Torticeoh
17:38:36Torticewell that's awfully simple
17:38:37Torticethanks
17:38:54narimiranit is `JObject`
17:38:58TorticeI'll try to read better next time
17:39:42shashlickfinally, a readme, a release binary and a screenshot 😄
17:39:50shashlicknow I can go back to coding
17:40:12narimiranTortice: https://nim-lang.github.io/Nim/json.html#pairs.i%2CJsonNode this should allow iterating through `JObject`
17:40:17*rnrwashere joined #nim
17:41:33narimiranTortice: yup, `for k, v in page.pairs:` works
17:44:31*floppydh quit (Quit: WeeChat 2.4)
17:51:07*vlad1777d quit (Ping timeout: 268 seconds)
17:51:49*vlad1777d joined #nim
17:58:52ZevvAny 'regular' pegs users here?
17:59:15FromGitter<liquid600pgm> I tried it before
18:05:53FromGitter<liquid600pgm> I have to say, despite its name, it's not that suitable for parsing that many things. it's more of a regexp alternative right now, which I do like (as it's a pure library so you don't need any extra `.dll`s/`.so`s)
18:06:16FromGitter<liquid600pgm> at least not suitable for parsing things into ASTs, from my experience
18:06:44FromGitter<liquid600pgm> the event-based API is pretty confusing, and that's what stopped me from doing anything too useful with the module
18:06:52Zevvyes, exactly. I'm a regular user and big fan of lpeg for lua, which has great support for all kind of captures
18:07:23Zevvbut for some reason I never got into the Nim pegs. Superficialy it seems similar, but it is so very different and misses things that make lpeg a breeze to use
18:07:56FromGitter<liquid600pgm> yeah, I just decided to use recursive descent parsing because pegs was too limited for me
18:07:57ZevvI hear a remark from Araq once that "he wrote pegs before he understood Nim", I was wondering if he has any more thoughts on the state of pegs
18:08:42ZevvI am considering making a literal nim port of lpegs. Probably some work to get it right, and maybe helpful for others as well
18:09:03Araqwell anything that doesn't use a macro for this is misguided
18:09:13Zevvplease explain?
18:09:25Araqsomething like
18:09:31Araqgrammar:
18:09:40Zevvoh yes, for construction, of course
18:09:44Araq peg"patternA": actionA
18:09:49Araq peg"patternB": actionB
18:10:21FromGitter<liquid600pgm> macros are the go-to thing to use for "the next pegs", as they allow you to transform source code into other source code and provide a nice DSL to the end user
18:10:54FromGitter<liquid600pgm> and obviously, they have much better performance
18:11:15FromGitter<liquid600pgm> compared to regexp and Nim's pegs
18:11:23Araqyeah, go for it please
18:12:35FromGitter<liquid600pgm> I can always help out, I've been parsing stuff for a lot of time now
18:12:40ZevvIt might be over my head, but I'll see if I can give it a go. I have pegs and lpeg for inspiration, and I know exactly which personal itches I want to scratch
18:12:51Araqnice
18:13:46FromGitter<liquid600pgm> feel free to ask any questions here if you have a hard time understanding something
18:14:02Zevvand you might not like Lua, but Roberto Ierusalimschy is a smart guy and writes _very_ nice and consice code
18:14:08Zevvgreat, thanks guys
18:16:41FromGitter<liquid600pgm> while we're in the topic of Lua, parsing, and all that good stuff, I'd like to announce a project I've been working on for a while now. it's an interpreted programming language, written entirely in Nim
18:17:14Zevvshow!
18:17:27FromGitter<liquid600pgm> the language is called "rod", and is still unfinished, but I thought it would be nice to share it now that the VM is working
18:18:05Zevvmy first question would be: how easy is it to interface with Nim?
18:18:37FromGitter<liquid600pgm> right now, pretty rough around the edges, but the plan is to provide a nice API full of helper macros
18:18:44FromGitter<liquid600pgm> here's the language's repo: https://github.com/liquid600pgm/rod
18:18:50Zevvcalling nim from rod, rod from nim and passing data both ways
18:19:16FromGitter<liquid600pgm> it's actually pretty simple, even at this early stage
18:19:49FromGitter<liquid600pgm> you just add a foreign function to the table of globals, and you can call it from rod
18:20:11FromGitter<liquid600pgm> rod functions can also be called from Nim using a `doCall` method
18:21:25FromGitter<liquid600pgm> take a look at this: https://github.com/liquid600pgm/rod/blob/master/tests/t_vm.nim and this: https://github.com/liquid600pgm/rod/blob/master/src/rod/stl.nim if you want *some* (though very little) info on embedding rod
18:22:07FromGitter<liquid600pgm> btw I think I forgot to change the year in the copyright headers xD
18:22:37Zevv ... Could not find task compile-exec in /tmp/rod/rod.nimble
18:22:46FromGitter<liquid600pgm> that's a draft
18:23:01FromGitter<liquid600pgm> use this for testing: `nim c -r tests/t_vm`
18:23:05Zevv:)
18:23:33Zevv../src/rod/vm.nim(15, 30) Error: inheritance only works with non-final objects; to enable inheritance write 'RodBaseFn of RootObj'
18:23:38Zevvam I too early :)
18:23:42FromGitter<liquid600pgm> hmm
18:23:45FromGitter<liquid600pgm> strange
18:23:50FromGitter<liquid600pgm> what version of Nim are you on?
18:23:57Zevv0.19.9 and a bit
18:24:36FromGitter<liquid600pgm> that's really strange, I added the `{.inheritable.}` pragma to `RodBaseFn` so it theoretically should work
18:25:11FromGitter<liquid600pgm> try changing line 16 in value.nim to declare `object of RootObj`
18:26:12Zevvthat works, but now stuff breaks in nim times, something about inNanoseconds
18:26:22ZevvWhat nim version do you suggest? I switch versions three times a day anyway
18:26:32FromGitter<liquid600pgm> I write rod on 0.19.9
18:26:39Zevvok
18:26:53FromGitter<liquid600pgm> theoretically it should work on 0.19.4, as I wrote rod referring to the stable docs
18:27:13AraqI think it's just the pragma placement
18:27:20AraqI fixed it in 0.19.9
18:27:32Araqprevious versions don't work as well
18:27:53FromGitter<liquid600pgm> ok, I changed it to inherit from `RootObj` so that issue doesn't occur
18:28:59FromGitter<liquid600pgm> oh do I love choosenim, it's such a useful tool for Nim development
18:29:03Zevvgot it, now works.
18:29:12FromGitter<liquid600pgm> great!
18:29:26*waleee quit (Quit: WeeChat 2.4)
18:29:43FromGitter<liquid600pgm> I'm gonna check it with 0.19.4, and fix any potential issues that arise
18:29:46Zevvthat's a sweet little VM :)
18:29:57FromGitter<liquid600pgm> thanks :)
18:30:00ZevvI never got beyond writing a Forth :(
18:30:04Zevvoh, and a basic
18:30:40FromGitter<liquid600pgm> that's still something
18:31:01FromGitter<liquid600pgm> I rewrote rod probably 3 times until it got to its current state, mainly due to my lack of experience
18:31:13Zevvthat's the only way to do it, I guess
18:31:21Zevvthe devil is in the details.
18:32:02Araqcopy compiler/vm.nim ;-)
18:32:19Araquse a register based VM, stack machines suck
18:32:50FromGitter<liquid600pgm> register based bytecode is *much* more difficult to compile
18:33:10AraqIMO that's a myth
18:33:41Araqall things considered, it's easier
18:33:47ZevvWell, you two have something to talk about, I'm going to cook and put the kids to bed :)
18:33:53FromGitter<liquid600pgm> well, I can't think of a good way to compile register-based bytecode myself
18:34:05FromGitter<liquid600pgm> I wanted to start with *something*
18:34:50Araqsure thing, no offense
18:35:03FromGitter<liquid600pgm> register-based VMs are definitely faster in some cases, which is a pretty big plus, but I don't think rod will have a register-based VM until at least 1.0
18:35:27Araqwell you can "cheat" and read Lua's source code or Nim's
18:36:59Araqfor a register based VM you need a register allocator but that's maybe 20 lines of code
18:37:00Zevvboth very dense, though
18:37:44Araqhint: the fixed size instructions are awesome for when you need to attach debugging info
18:37:59Araqwhich is always the case.
18:38:56FromGitter<liquid600pgm> my VM was modeled after Wren's (see http://wren.io/)
18:39:05AraqI never finished any stack based VM, debugging info, variable length instruction, eternal confusion about the stack direction (is a - b; pop a; pop b; minus or the other way round)
18:39:21FromGitter<liquid600pgm> well, not exactly, of course, because Nim's a higher level language than C
18:40:39FromGitter<liquid600pgm> gosh, the speed of my internet connection sucks today
18:41:46FromGitter<liquid600pgm> stack based VMs are good when you want something that's simple, or generally a good starting point
18:43:21FromGitter<liquid600pgm> so now I know rod doesn't compile with Nim 0.19.4 :shrug:
18:44:30ZevvBy the time you're finished you'll need Nim 4, at least :)
18:50:32FromGitter<liquid600pgm> where can I find the documentation for older Nim versions?
18:50:46Zevvgenerate from source, I guess
18:51:00Araqstack based VMs are not simple ;-)
18:51:28FromGitter<liquid600pgm> Araq: it depends on your point of view
18:53:21FromGitter<liquid600pgm> does anyone happen to know when was `Duration.inNanoseconds()` introduced?
18:53:33Araq2 weeks ago
18:53:57FromGitter<Varriount> Araq: That checkAbi define also breaks compilation with iterators on OSX
18:53:59FromGitter<liquid600pgm> so 0.19.9?
18:54:48Araqwell if you want simple an AST interpreter is hard to beat, if you use a stack you do so for performance and then why not directly use a register based VM
18:55:47FromGitter<liquid600pgm> the reason is I don't quite understand register based VMs yet, I want a working base to then expand on
18:56:16Araqsure, that's a very good reason
19:07:06Araqbut if you hit a wall, give up and rewrite it to use registers ;-)
19:07:48FromGitter<liquid600pgm> sure thing, I like learning new things so writing a register-based VM would be interesting
19:08:31Araqdon't repeat Python's mistakes, it's grown some shitty peephole optimizer
19:11:29FromGitter<liquid600pgm> do you have any good guides on how you can write a compiler for a register-based VM?
19:11:44*hoijui quit (Remote host closed the connection)
19:11:53Araqyou walk the AST and emit instructions
19:12:07FromGitter<liquid600pgm> well that's pretty obvious
19:12:19FromGitter<liquid600pgm> I was asking about how to manage the registers in a recursive setting
19:13:33FromGitter<liquid600pgm> you said something about a register allocator, is that the thing I'm asking for?
19:14:31Araqthe basic pattern is something like proc emitAdd(a, b: Register; dest: var Register) =
19:14:43*rnrwashere quit (Remote host closed the connection)
19:14:51Araq if unused(dest): dest = getTemp(registerAllocator)
19:15:01Araq emit opcAdd, dest, a, b
19:15:18FromGitter<liquid600pgm> hmm, I'll look into it, thanks :)
19:15:57Araqthe trick is to tell the emitter the destination if you can, so that you don't produce lots of pointless temporary assignments
19:16:26Araqyou don't need an optimizer, the produced code is very good automatically
19:16:51FromGitter<liquid600pgm> I don't plan on adding an optimizer for implementation simplicity's sake
19:17:15FromGitter<liquid600pgm> mainly because rod supports custom operators, like Nim, and those are added into runtime classes
19:17:37Araqwell you can write a jump optimizer, structured programming constructs tend to produce bad jump instructions
19:18:18*Cthalupa quit (Ping timeout: 252 seconds)
19:19:10Araqwithout much effort you turn 'i = i + 1' into a single instruction like opcAddI regA, regA, 1
19:19:32FromGitter<liquid600pgm> for now, I'll just focus on finishing the first version of rod
19:19:32Araqthat's 1 instruction vs 4 for the stack based VM.
19:19:39FromGitter<liquid600pgm> thanks for your guidance!
19:19:57*Cthalupa joined #nim
19:20:21FromGitter<liquid600pgm> (oh, and I know the benefits of register based VMs, often they're pretty obvious in themselves)
19:21:24Araqyou can also get crazy and add "super instructions" for example a single instruction to compute object.fieldA.fieldB
19:21:36Araq(Nim's VM doesn't do this)
19:22:21FromGitter<liquid600pgm> I won't be doing that for sure
19:22:25FromGitter<liquid600pgm> for simplicity's sake
19:24:02*lf-araujo joined #nim
19:24:37*abm joined #nim
19:28:28Araqor maybe write a JIT already, produce x86_64 code and on different CPUs run a x86 emulator
19:32:19FromGitter<Varriount> Then JIT the x86 emulator
19:33:27Araqcompile your Nim code to JS so that your VM runs in the browser
19:33:44FromGitter<liquid600pgm> I don't know if it can be done
19:33:55Araqthen run it in a browser in a browser because security
19:34:04FromGitter<liquid600pgm> lol
19:35:17Araqin fact, run Linux on your browser that then runs a virtual machine that runs Windows that runs your VM
19:37:15FromGitter<liquid600pgm> then send my computer to the Moon and run it here for extra extra safety
19:46:02*zyklon quit (Ping timeout: 257 seconds)
19:49:10*cgfuh quit (Ping timeout: 246 seconds)
19:57:46*zyklon joined #nim
20:03:44FromGitter<Clyybber> and then JIT the universe simulator
20:05:04FromGitter<Clyybber> @liquid600pgm Regarding your question above, I think you can use overloading like this: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c82caef8f294b134a0deddd]
20:06:22FromGitter<liquid600pgm> yeah, but I want to use this in a method to report that an incomplete function was called
20:06:46FromGitter<liquid600pgm> and that they should implement `doCall` for that specific type
20:07:46*cgfuh joined #nim
20:11:14FromGitter<Clyybber> Oh, ok
20:17:54FromGitter<deech> What the the `type` keyword do here? ⏎ ⏎ ``` MyCastables = concept x ⏎ x.to(type string) ⏎ ...``` [https://gitter.im/nim-lang/Nim?at=5c82cdf2293ac75db575cfa7]
20:18:12FromGitter<liquid600pgm> (https://files.gitter.im/nim-lang/Nim/YCJL/image.png)
20:18:14FromGitter<liquid600pgm> umm
20:18:38FromGitter<liquid600pgm> when I move it right after the export star it errors
20:19:23FromGitter<liquid600pgm> the error is `invalid pragma: acyclic`
20:20:32FromGitter<liquid600pgm> how am I supposed to type it then!?
20:24:06FromGitter<liquid600pgm> @deech this is done to explicitly mark that the parameter's type is `typedesc`
20:24:49FromGitter<liquid600pgm> and that it should accept `string` as a parameter
20:25:12FromGitter<liquid600pgm> (not that the parameter's type is `string`)
20:27:52FromGitter<deech> @liquid600pgm Nice, thanks! Entirely possible I missed it but I couldn't find that described anywhere before "Concepts" in the manual.
20:45:36*avanderneut joined #nim
20:45:38*nsf joined #nim
20:51:30*Vladar quit (Remote host closed the connection)
20:53:23FromGitter<liquid600pgm> (https://files.gitter.im/nim-lang/Nim/5psh/image.png)
20:53:25FromGitter<liquid600pgm> It's explained right here, but it's not that obvious what the `type` prefix does when you first read the doc.
20:55:42FromGitter<deech> Wow, of course. Thanks, appreciate it!
20:59:20shashlickopen -r *.nim in my home dir in feud - opened 292 files and 27mb ram usage
21:20:28*matthias__ quit (Quit: matthias__)
21:24:29*lf-araujo quit (Ping timeout: 268 seconds)
21:25:16*Trustable quit (Remote host closed the connection)
21:31:51*nsf quit (Quit: WeeChat 2.4)
21:57:52*oculuxe joined #nim
21:59:47*oculux quit (Ping timeout: 244 seconds)
22:02:17*oculux joined #nim
22:02:48*jxy quit (Ping timeout: 272 seconds)
22:04:13*oculuxe quit (Ping timeout: 245 seconds)
22:05:19*jxy joined #nim
22:06:13*Tortice quit (Remote host closed the connection)
22:06:30FromGitter<Clyybber> Does anybody know if there is a rational number implementation for nim?
22:10:20*lf-araujo joined #nim
22:10:55Araqrationals.nim? it used to be a thing
22:16:19*oculuxe joined #nim
22:18:08*oculux quit (Ping timeout: 268 seconds)
22:19:36FromGitter<Clyybber> Oh nice, thats f*ing cool
22:21:20FromGitter<iffy> In converting a C++ header to Nim, what do I use for SIZE_MAX?
22:21:29FromGitter<iffy> c2nim just left it
22:26:00FromGitter<iffy> `(0.uint) - 1` ?
22:28:34FromGitter<Clyybber> I think that may be right, depending on what size_t is on your platform
22:29:39FromGitter<Clyybber> So I guess on 64 bit it should be uint64.high
22:29:55FromGitter<iffy> okay, I'll go with that -- what's the worst that could happen if I'm wrong? ;)
22:30:26FromGitter<Clyybber> which isn't actually implemented in the std library, but this here should work: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c82ed02b4b6ef7bc87ae524]
22:30:36FromGitter<Clyybber> I'm using this
22:30:51FromGitter<Clyybber> and I can confirm that it works
22:30:55FromGitter<Clyybber> :P
22:31:18FromGitter<iffy> okay -- I suppose it could cause problems if the const is used in 32 bit locations?
22:31:33*jjido joined #nim
22:31:45FromGitter<iffy> Nim will yell at me if I try to use a uint64 when a uint32 is required, right?
22:31:46*oculux joined #nim
22:31:50FromGitter<Clyybber> Yeah
22:31:58FromGitter<iffy> okay, I'll start with 64; thanks!
22:31:58FromGitter<Clyybber> Probably...
22:32:01FromGitter<iffy> hehe
22:32:07FromGitter<Clyybber> Don't quote me on it.
22:32:30FromGitter<Clyybber> If people die, I'll run for the hills.
22:32:57*oculuxe quit (Ping timeout: 245 seconds)
22:33:00*lf-araujo quit (Ping timeout: 252 seconds)
22:33:09FromGitter<Clyybber> This is really interesting, regarding floating point arithmetic with high precision: https://sci-hub.tw/10.1007/978-3-662-49498-1_16
22:38:51FromGitter<liquid600pgm> if I enable an experimental feature in one module and use it for something, will I have to enable it in another module that imports the first module too?
22:41:16Araqgood question. it depends.
22:41:43Araqusually the .experimental refers to the declaration site and then can be used
22:42:05FromGitter<liquid600pgm> what I'm asking about is the `dotOperators` feature
22:42:27Araqyes, that one is declarationsite
22:42:40Araqwhich is pretty bad, but it is what it is :P
22:43:25FromGitter<iffy> Hmm... how do I convert char16_t to a nim type?
22:43:46FromGitter<liquid600pgm> for me it's good I can use them without relying on the users explicitly adding `{.experimental: "dotOperators".}` to their code
22:45:50*oculuxe joined #nim
22:47:51FromGitter<Clyybber> @iffy Depending on what it represents either uint16 or https://nim-lang.org/docs/unicode.html#Rune16
22:48:15FromGitter<Clyybber> If it represents arbitrary data, use uint16, if it represents a unicode char use Rune16
22:48:18*oculux quit (Ping timeout: 250 seconds)
22:49:29FromGitter<iffy> Hmmm... in this library it only ever refers to a `ref char16_t` (so a pointer?) so either one would probably work
22:49:31FromGitter<iffy> thanks
22:53:21*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:53:50Araqiffy, there is widestrs.nim
22:53:52*narimiran quit (Remote host closed the connection)
22:58:19FromGitter<iffy> oh, thanks; I'll take a look
23:00:33FromGitter<iffy> perfect, Utf16Char will probably work
23:01:20*oculux joined #nim
23:01:36*noeontheend quit (Ping timeout: 252 seconds)
23:03:25*oculuxe quit (Ping timeout: 246 seconds)
23:04:41FromGitter<iffy> Okay, now how do I specify that a proc adheres to some proc type. For instance, I have this type: `type napi_callback* = proc (env: napi_env; info: napi_callback_info): napi_value` and I have `proc Method(env: napi_env, args:napi_callback_info):napi_value = ...` but the compiler doesn't think `Method` can be passed as an arg of type `napi_callback`
23:05:05*jjido joined #nim
23:09:39FromGitter<iffy> casting doesn't work...
23:12:48*rnrwashere joined #nim
23:15:29*ryukoposting quit (Quit: WeeChat 1.6)
23:15:51*oculuxe joined #nim
23:18:06*oculux quit (Ping timeout: 252 seconds)
23:19:25*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:29:20Araqread about .closure
23:31:20*oculux joined #nim
23:33:22*oculuxe quit (Ping timeout: 245 seconds)
23:38:31FromGitter<iffy> k
23:45:13*dddddd quit (Remote host closed the connection)
23:45:35FromGitter<iffy> including `{.closure.}` on the type definition make Nim happy, but the C compiler complains about `candidate function not viable: no ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c82fe9f25e4e24c073aa1b7]
23:45:49FromGitter<iffy> But I'm off -- thank you for you help!
23:47:07*ng0 quit (Quit: Alexa, when is the end of world?)
23:47:24*oculuxe joined #nim
23:48:41*rnrwashere quit (Remote host closed the connection)
23:49:40*oculux quit (Ping timeout: 255 seconds)
23:55:11*stefanos82 quit (Remote host closed the connection)