<< 06-02-2019 >>
00:00:49*askatasuna left #nim (#nim)
00:02:26*rockcavera joined #nim
00:03:05FromGitter<akavel> What does this error mean: `Error: type mismatch: got <proc (s: Stream){.gcsafe, locks: 0.}> but expected 'proc (s: Stream){.gcsafe.}' ... .tag effects differ` ?
00:24:28*vlad1777d joined #nim
00:27:43FromDiscord_<demotomohiro> krux02, thank you! I added the text about how to refresh the screen in tui mode in my blog post
00:32:54*stefanos82 quit (Remote host closed the connection)
00:35:10FromDiscord_<demotomohiro> @fvs, there is faster way to reverse bits
00:35:17FromDiscord_<demotomohiro> http://aggregate.org/MAGIC/#Bit%20Reversal
00:40:48FromDiscord_<demotomohiro> @akavel, you want to define an array like this?
00:40:49FromDiscord_<demotomohiro> https://wandbox.org/permlink/4D2B65bpMo2HC5Qg
00:44:35fvsdemotomohiro, thanks. Nice page.
00:46:30fvsinteresting to see bit operations on this page are all on unsigned ints
00:51:30FromGitter<akavel> @demotomohiro: thanks, this I already solved; any hints on the `.tag effects differ` error by chance? :)
00:57:32*jacobsin joined #nim
01:06:26abmi've got client service talking to server rest api with certificate authentication
01:06:42abmwhen running both services on local IIS everything goes smoothly
01:06:58abmbut on azure the server doesn't seem to get the certificate
01:07:33abmanyone have any idea what could be the cause?
01:13:15*seni quit (Quit: Leaving)
01:20:58FromGitter<dandevelo> @abm maybe the certificate is not set up correctly on azure?
01:22:07abmshit, this is definitely wrong channel for this question
01:22:19abmsorry dandevelo
01:23:04*abm left #nim ("Leaving")
01:30:26*jacobsin quit (Ping timeout: 240 seconds)
01:32:02*jacobsin joined #nim
01:32:15shashlicktoo many bugs today
01:36:12*jacobsin quit (Ping timeout: 246 seconds)
02:02:13*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
03:02:25*banc quit (Quit: Bye)
03:23:19*banc joined #nim
03:28:27*theelous3 quit (Ping timeout: 240 seconds)
03:32:53FromDiscord_<Geroro / Grey Ghost> Hi all! I'm trying to reimport a dll but the function I'm running in the dll isn't updating, do I have to clear a cache or something to reimport a dll? Thanks!
03:35:16*fvs left #nim ("leaving")
03:37:56*volkov joined #nim
03:46:33leorize@Geroro: have you unloaded the dll beforehand?
03:58:38*kapil____ joined #nim
04:08:35*nsf joined #nim
04:38:43*jacobsin joined #nim
04:39:48*dddddd quit (Remote host closed the connection)
04:42:56*jacobsin quit (Ping timeout: 250 seconds)
05:03:02*volkov quit (Remote host closed the connection)
05:09:38*jacobsin joined #nim
06:11:51*vlad1777d quit (Remote host closed the connection)
06:14:04*vlad1777d joined #nim
06:17:52*flaviu joined #nim
06:18:46FromDiscord_<Geroro / Grey Ghost> I got it working after reading this, https://16bpp.net/page/hot-loading-code-in-nim , Thank you @leorize! :)
06:37:27*kapil____ quit (Quit: Connection closed for inactivity)
06:55:27*jacobsin quit (Ping timeout: 240 seconds)
06:55:53*narimiran joined #nim
07:55:13*kapil____ joined #nim
07:55:22*enow joined #nim
07:59:22FromGitter<timotheecour> how do we control name mangling of a proc with `nim cpp` ?
07:59:56enowIf I want to call a nim function from js and pass it an array how do I go about to do that
08:00:00*gmpreussner quit (Quit: kthxbye)
08:02:51Araqjust pass it an array, Nim's arrays are mapped to JS's arrays
08:04:44*gmpreussner joined #nim
08:09:40enowoh neat thx!
08:10:11enowwhat if it's an object because I have a key value object
08:13:14Araqthen it's the {key: value} JS object
08:15:00FromGitter<timotheecour> @araq any idea about my question above? how do i control name mangling of a proc in `nim cpp`: `proc foobar2(a: int) {.exportc: "FOO$1”.}` ⏎ => this will mangle as `__Z10FOOfoobar2x` instead of `_FOOfoobar2` (and will fail at `importc` time)
08:15:49Araqwell you already know ;-)
08:16:02Araqexportc influences the C(++) name
08:16:12Araqnot the name mangling that happens afterwards
08:16:33Araqso you need to play tricks with emit "extern C" or .codegenDecl
08:28:07*vlad1777d quit (Ping timeout: 240 seconds)
08:28:19enowor nice
08:28:50enowhm I'm getting something weird when I'm trying to output a string with console.log
08:29:19enowso in the compile code it turns out like console.log(toJSStr("123"))
08:29:47enowbut if I evaluate toJSStr("123") in the developer console I get some weird utf-8 symbols
08:30:14enowand it throws: Uncaught URIError: URI malformed
08:41:27Araqthen get your string handling right, Nim's strings are not JS's strings
08:43:59Araqthere are a couple of thousand lines of example code that use Nim's JS backend and it's documented here https://nim-lang.org/docs/backends.html#backends-the-javascript-target but these docs are bad :-)
08:44:06Araqnarimiran, more work...
08:44:19narimiran:)
08:52:11*jacobsin joined #nim
08:55:05*JustASlacker joined #nim
08:56:28*jacobsin quit (Ping timeout: 244 seconds)
09:03:35*floppydh joined #nim
09:17:53FromGitter<alehander42> enow: nim strings <=> js number arrays
09:18:13FromGitter<alehander42> nim cstring <=> javascript strings
09:19:21FromGitter<alehander42> you can write helpers/shortcut templates so you can do c"lala" or something instead of cstring"lala"
09:20:06FromGitter<alehander42> i agree it's a little confusing, but nim strings are mutable, so it's hard to represent them directly
09:23:57*oculux quit (Quit: blah)
09:26:51FromGitter<kayabaNerve> @alehander42 Just make everything immutable and declared at compile time. Ez.
09:27:51FromGitter<kayabaNerve> (just joking :P, not trying to suggest a serious idea or distract from the honest discussion about string intricacies)
09:29:48FromGitter<alehander42> :D it's a simple solution!
09:30:18*Vladar joined #nim
09:30:51FromGitter<kayabaNerve> KayabaLang.
09:31:01FromGitter<kayabaNerve> Give it 5 years and some AI researchers would declare it amazing
09:31:21ZevvDoes anyone know about any Nim <-> z3 bindings?
09:31:44FromGitter<kayabaNerve> I could legitimately seeing a joke, half-esoteric language that treats it itself seriously becoming a specialized language.
09:33:50FromGitter<alehander42> i am sure some language tried that already :D
09:34:38FromGitter<kayabaNerve> I think there's a ton of semi-esoteric languages with wide spread advocacy. Just look at Elixir. That said, Elixir wasn't started as a joke,
09:39:48*tzui joined #nim
09:40:34*oculux joined #nim
09:49:20*neceve joined #nim
10:02:41FromGitter<mratsim> Brainfuck
10:04:08*oculux quit (Quit: blah)
10:06:37*Vladar quit (Remote host closed the connection)
10:07:08*Vladar joined #nim
10:10:12FromGitter<kayabaNerve> @mratsim Yeah but what group advocates widespread usage of it
10:10:37FromGitter<kayabaNerve> I mean like what if a BF-C combo become a premier language in Ai dev, or neural nets, or AR...
10:16:00FromGitter<mratsim> Interpreter devs are pushing Brainfuck as a standard language to test Interpreter and JIT implementations ;)
10:22:14xace_leorize: Would there be big changes required to make your nim.nvim compatible with vanilla vim?
10:23:28FromGitter<timotheecour> @araq > so you need to play tricks with emit "extern C" or .codegenDecl ⏎ ⏎ see https://github.com/nim-lang/Nim/issues/10578 for my attempts, so far it doesn’t work but maybe you have a trick I haven’t though of? ⏎ My proposal is simple and implementation is probably quite simple; so it’s just a matter of agreeing on semantics [https://gitter.im/nim-lang/Nim?at=5c5ab5a078e1ed4103ee46e2]
10:23:56Araq.codegenDecl should work?
10:24:26FromGitter<timotheecour> see the issue i lnked to
10:27:02Araqproc foobar2(a: int) {.codegenDecl: """extern "C" $1 my_foobar1 $3""".}
10:32:03AraqIMO all we need an 'externc' pragma
10:32:03FromGitter<timotheecour> it doesn’t work, it’s the same issue as i mentioned in the linked issue
10:32:51FromGitter<timotheecour> U either get the proc optimized out, or using it gives u an error as it tries to use the wrong name: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c5ab7d39221b9382d233bc0]
10:33:27Araqproc foobar2(a: int) {.externc: "my_foobar1", codegenDecl: """extern "C" $1 $2 $3""".}
10:35:22FromGitter<timotheecour> ok so we agree somethings currently missing, correct?
10:36:07FromGitter<timotheecour> if u have `externc: “my_foobar1”` isn’t `codegenDecl` redundant in above decl?
10:36:27Araqno because it adds the 'extern "C"'
10:36:57Araqah typo
10:37:04Araqproc foobar2(a: int) {.exportc: "my_foobar1", codegenDecl: """extern "C" $1 $2 $3""".}
10:37:10Araq^ try this variant please
10:42:10*PMunch joined #nim
10:42:13FromGitter<timotheecour> Ok! seems to work!
10:42:16FromGitter<timotheecour> thanks :)
10:43:03FromGitter<timotheecour> my point still holds though, we shd make by default `exportc/importc` work by themselves with both `nim c` `nim cpp`
10:43:30Araqyeah but the rules are unclear
10:43:46FromGitter<timotheecour> otherwise they’re always be issues when switching from `nim c ` to `nim cpp` or worse, when mixing shared libs
10:44:10FromGitter<timotheecour> rule 1 or rule 2?
10:44:32FromGitter<timotheecour> (in proposal in https://github.com/nim-lang/Nim/issues/10578)
10:45:17*oculux joined #nim
10:45:58Araqno, it's unclear what to do
10:46:20FromGitter<timotheecour> what’s the disadvantage of rule 1?
10:46:53Araqit breaks code, exportc already has a meaning and it's not that hard to understand
10:47:09Araqit means "don't optimize out and use this name in produced code"
10:47:46Araqthe fact that C++ later mangles it is of no consequence, on some platforms C names are mangled too
10:47:48FromGitter<timotheecour> that would still hold under rule 1
10:48:20FromGitter<timotheecour> it is of consequence: right now, `importc` doesn’t work with `exportc`
10:49:23Araqit is not exportc's business
10:49:27FromGitter<timotheecour> > on some platforms C names are mangled too ⏎ ⏎ that wouldn’t matter, it’d just apply the extern C behavior
10:50:21Araqwell 'mangling: cpp' is a deadend, I'm not gonna reimplement C++'s mangling rules
10:50:37FromGitter<timotheecour> and u dont have to
10:50:56Araqand as I've argued before, it starts with clear names
10:51:00FromGitter<timotheecour> `mangling: cpp` would just skip adding `export C`
10:51:32FromGitter<timotheecour> ya, the name `exportc` actually suggests “c”, not “cpp"
10:51:52Araqyeah so it would be confusing, I would expect mangling: cpp to mangle it as C++ does, not that it translates to C++ and so it kinda works out
10:52:24*jacobsin joined #nim
10:53:23FromGitter<timotheecour> i dont’ understand; `externc:”foo” mangling: cpp` would be simply what we have today`
10:53:29Araqok, so 'exportc' is misnamed, it already exists though and so we would need a deprecation period etc
10:54:56Araqmaybe we can come up with a good name this time that does what it says
10:55:01FromGitter<timotheecour> ok now we’re talking; sure; we can have a transisiton flag `—experimental:exportcNoMangle` that ppl can enable and later would be come default
10:55:56Araqwhat 'exportc' currently does still needs to be possible
10:56:23FromGitter<timotheecour> yes, that’s the `mangling:cpp` i was talking about, and that was my `rule 2`
10:56:54*jacobsin quit (Ping timeout: 250 seconds)
10:57:10FromGitter<timotheecour> and that extends naturally to `mangling:d` `mangling:objc`
10:57:14FromGitter<kayabaNerve> Oh. Is it a known bug that some C files are only compiled with -f?
10:57:19Araqbut I don't like this design.
10:57:25FromGitter<timotheecour> which part
10:57:58FromGitter<kayabaNerve> As in, if you delete nimcache and run `nim c`, the linker will claim C files are missing, but if you use `nim c -f`, it works?
10:58:43Araqall of it. You make exportc produce an extern "C" declaration which we then disable via more annotations. it's not "mangling:cpp" it's "noExternC"
10:58:57FromGitter<timotheecour> i want to be able to call `myDFun() {.exportc:”funname”, mangling:d .}` likewise with OBJC and C++ (C++ being priority obviously)
11:00:18Araqwe don't have 'mangling:d' nor objective C nor C++, all we have is (avoid / doUse) ExternC
11:00:43*oculux quit (Quit: blah)
11:01:16Araqthis stuff is already complex enough, don't pretend we have mangling when all we do is C++ code generation tinkering
11:01:17FromGitter<timotheecour> it actually makes sense, and can use it even without `exportc` for simple (common!) case of nim name maching un-mangled C++ name: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c5abe7df04ef00644eafd65]
11:01:23PMunchThe video of the meta-programming talk is now available and I've updated my article with it: https://peterme.net/meta-programming-in-nim-fosdem-talk-companion-post.html
11:03:36FromGitter<timotheecour> > You make exportc produce an extern "C" declaration which we then disable via more annotations ⏎ ⏎ my previous msg addresses this: u just need `mangling:cpp` for the common simple case, `mangling:cpp exportc` is not even needed
11:05:24FromGitter<timotheecour> > don't pretend we have mangling when all we do is C++ code generation tinkering ⏎ ⏎ it doesn’t require a C++ mangler, code generation as we already do is enough
11:05:55Araqwhat would mangling:cpp do without an externc?
11:07:04FromGitter<timotheecour> it would mangle `foobar1(a: int) as `_Z10my_foobar1x` (ie imply exactly the same as the CURRENT exportc)
11:07:41Araqbut it wouldn't work at all with 'nim c'!
11:07:42FromGitter<timotheecour> ( i think u meant exportc, not externc)
11:07:55Araq(yes, sorry)
11:09:19AraqkayabaNerve: Nim is not a build system for C++ code, so yeah, sometimes you need to use -f.
11:09:30FromGitter<timotheecour> Correct! `mangling:cpp` would require `nim c`, or as future improvement, we could use existing libraries for that (D does that so it’s possible)
11:09:49FromGitter<timotheecour> Typo: would require `nim cpp`
11:09:58FromGitter<kayabaNerve> Araq: The code I'm referring to is C.
11:10:07AraqkayabaNerve: Nim is not a build system for C code, so yeah, sometimes you need to use -f.
11:10:12FromGitter<kayabaNerve> Lol
11:10:24FromGitter<timotheecour> so there’s no loss of functionality compared to what we have today
11:10:30FromGitter<kayabaNerve> That said, I'll take it this is a known issue, and I shouldn't produce a MWE and create a GitHub Issue?
11:11:06Araqthere is an RFC for it or something and timothee has a patch :-)
11:11:23FromGitter<timotheecour> u can also have: `mangling:native` which means: `mangling:cpp` with `nim cpp` and `mangling:c` with `nim c`
11:12:33FromGitter<kayabaNerve> Thanks for the info
11:12:35*enow quit (Read error: Connection reset by peer)
11:12:52Araqand yeah I know that Nim is already so much better at building C code than cmake/make/tup/scons so that you demand a complete solution ;-)
11:13:09FromGitter<timotheecour> @kayabaNerve => https://github.com/nim-lang/Nim/issues/10441
11:14:41*lritter joined #nim
11:20:11FromGitter<timotheecour> so unless u have a better proposal (that works transparently regardless we use `nim c` or `nim cpp`) and is as simple as `proc fun(){mangling:native|c|cpp|d|objc}` I think we shd go for it
11:21:58FromGitter<timotheecour> (w `mangling:cpp` being implementable today, the rest being left as future options that work well w that syntax)
11:23:59Araqbetter proposal: don't lie, add an 'externc' switch
11:24:25Araqbetter proposal 2: don't lie, add an 'noExternc' switch
11:25:26FromGitter<timotheecour> that’s the wrong default; it will break all code that uses `proc fun() {.exportc: "foo".}` the day they try to switch to `nim cpp`
11:25:31xace_is "nim ctags main.nim" suppose to generate a valid ctags file?
11:26:11FromGitter<timotheecour> `exportc` already has `c` in it, so it’s not really a lie
11:27:17Araqno, that "only" breaks code then, that's my proposal 2
11:29:22*stefanos82 joined #nim
11:31:03FromGitter<timotheecour> what’s the semantic of noExternc? ⏎ if it’s this, i’m ok ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c5ac57713a2814df62b71ee]
11:32:59Araqyes
11:33:54Araqand while I'm in my bad mood... I really don't like Nimble's .nimble dir
11:34:06FromGitter<timotheecour> Ok so that’s same as my rule 1, but modified rule 2 to use `noExternC` instead of `mangling:cpp` ; not what I’d preferred but i can live with that
11:34:30AraqI cannot do 'nimble install pkg && cd pkg && nimble test' because Nimble doesn't install the tests
11:35:04Araqso I have to do 'nimble install pkg', 'git clone url', 'cd pkg', 'nimble develop', 'nimble test'
11:35:32FromGitter<timotheecour> ya i had to solve the same problem in my nimble-CI
11:36:11FromGitter<timotheecour> but `nimble install pkg` isn’t needed
11:36:55FromGitter<timotheecour> in fact it’s wrong
11:37:00Araqand even then Nimble's very idea of nuking the .git dir and redistribute the files just so that I can do 'import jester' and save a couple of keystrokes over 'import jester/jester' or something is bad
11:37:46Araqhow do I ensure the dependencies exist when I don't use 'nimble install pkg'?
11:38:00FromGitter<timotheecour> nimble build
11:38:37Araqthat only works for "binary" packages or whatever they are called
11:40:04Araqand the lack of 'git clone' means I cannot create PRs against packages easily
11:41:07FromGitter<timotheecour> > that only works for "binary" packages or whatever they are calle ⏎ ⏎ i think there’s a way to query whether it’s library-only or binary/hybrid; in latter case call nimble build
11:41:45Araqwe're a small community, nimble makes it harder to contribute to existing packages because all I have is these 'pkg-1.0' dirs lying in a hidden .nimble directory
11:42:08FromGitter<timotheecour> well i’d never do a PR against that, u’d use `nimble develop`, always
11:42:33FromGitter<timotheecour> but I agree nimble would be better off using `git clone` instead of copying/re-arranging files
11:42:57FromGitter<timotheecour> in fact it should do exactly what `brew` does.
11:43:41FromGitter<timotheecour> actually scratch that last sentence;
11:44:33AraqNimble solves an NP complete problem, "which packages version ranges work given these requirements"
11:44:52Araqthat is not a problem that I've ever had in my entire life as a developer.
11:45:34AraqInstead I'm fine with using the latest version for all and fixing code until it works.
11:45:53FromGitter<timotheecour> i can tell u for a fact nimble does a much better job at that than D’s dub
11:46:49AraqCorrection:
11:47:03AraqInstead I'm fine with using the latest version for all and fixing code until it works. And then having reproducible builds.
11:47:22FromGitter<timotheecour> but what u’re describing is brew’s model; only the latest is supported and u get a consistent echosystem of libs that work together; it requires a centralized repo; and is some work, but doable; and that’s what i had suggested we shd strive for
11:47:40AraqI remember agreeing with you :-)
11:48:59FromGitter<timotheecour> Good! it’s in fact very tightly coupled to having nimble-wide CI
11:50:14federico3nimble-wide?
11:50:58FromGitter<timotheecour> https://github.com/nim-lang/Nim/pull/10247
11:51:58*oculux joined #nim
11:53:00FromGitter<timotheecour> btw @araq not sure if u saw that: https://github.com/nim-lang/Nim/pull/10576/commits/bb1ddf004ae0c4c0cc04b93f234c5cabcb3b0909 ; it fixes ur echoBinSafe error, but then fails w `nim cpp` ; but we can use the `codegenDecl` workaround until `noExternC` is implemented
11:53:54Araqnah sorry, it's not good enough
11:54:38Araqwhat we instead need is a proc rawEcho(args: openArray[cstring]) that doesn't allocate that we can use for system.nim development
11:54:50Araqand we can implement 'echo' with rawEcho then
11:55:33Araqand actually this should be moved into a callback so that I can delegate barebones error logging to whatever I need to without using --os:standalone with its panic override stuff
11:56:25Araqthere are a couple of callbacks that all of system.nim should be based on:
11:56:28Araq- onEcho
11:56:36Araq- onRaiseDefect
11:57:13Araq- onGetAllocator (but that's much harder as the memory subsystem requires features that no 'malloc' offers)
12:00:22FromGitter<timotheecour> Ya user-settable callbacks would be great; esp to override `echo` with `onEcho: write also file:line in color and also log`
12:01:21FromGitter<timotheecour> i’m glad u’re changing some `includes` to `import`, it really is saner;
12:01:49Araqbbl
12:02:14FromGitter<timotheecour> can’t we use a dummy GC (that allocates but never deallocates) for when GC is not initialized yet and we need procs that allocate (eg: `$`) ?
12:14:01*neceve quit (Read error: Connection reset by peer)
12:14:14*kapil____ quit (Quit: Connection closed for inactivity)
12:21:56*dddddd joined #nim
12:39:53*Snircle joined #nim
12:51:59*Cthalupa quit (Ping timeout: 268 seconds)
12:52:35*Cthalupa joined #nim
12:52:42*jacobsin joined #nim
12:57:37*jacobsin quit (Ping timeout: 268 seconds)
13:10:40Araqtimotheecour: not easy to do, cannot use 'malloc' for embedded, cannot use mmap either
13:11:05Araqthe only thing I could use is var fakeHeap: array[N, byte]
13:11:21Araqbut then this bloats the exe with this array that is usually unused
13:13:20Araqbtw "my platform does not have a heap" is yet another myth, you do have a heap unless your platform lacks global variables
13:18:56*rokups joined #nim
13:26:57PMunchCould be interesting for microcontrollers. Set a max binary size and use the rest for a virtual heap
13:30:35Araqsure but I don't want to pay for this array when I can use mmap
13:37:46*vlad1777d joined #nim
13:46:33*vlad1777d quit (Remote host closed the connection)
13:47:40*tzuii joined #nim
13:48:29*vlad1777d joined #nim
13:50:03*tzui quit (Ping timeout: 245 seconds)
13:54:44*nsf quit (Quit: WeeChat 2.3)
13:57:27*Cthalupa quit (Ping timeout: 240 seconds)
13:58:33*PMunch quit (Remote host closed the connection)
13:59:18*Cthalupa joined #nim
14:11:31*fanta7531 joined #nim
14:17:06*theelous3 joined #nim
14:30:13*jacobsin joined #nim
14:30:15AraqPMunch! aww we is gone
14:30:28Araqwatched your talk, it's very nice
14:31:55*surma__ is now known as surma
14:33:47xace_is there a video of PMunch's talk?
14:34:02Araqhttps://forum.nim-lang.org/t/4631
14:34:38*jacobsin quit (Ping timeout: 245 seconds)
14:36:27xace_That was fast, thank you.
14:44:28*askatasuna joined #nim
14:49:55AraqError: unhandled exception: testresults\io.json(2, 186) Error: ] expected [JsonParsingError]
14:50:08Araqis testresults\io.json already gone? you bet.
14:50:28Araqbut hey, at least my 'git status' is clean... ffs
14:50:38*nc-x joined #nim
14:51:01nc-x`Error: ] expected ` I get that error a lot of times when i run some tests locally
14:51:56narimiranhey nc-x, while you're here: take a look at the mobile documentation. it should be much better now than yesterday when you reported it
14:54:17nc-xnarimiran: just looked at it. it looks fine except that I would love to have the index back ;D
14:54:45narimiranheh, never satisfied :)
14:54:46nc-xMaybe add a hamburger menu or something that opens up index and hides the docs
14:55:05nc-x:D
14:55:31narimirannc-x: just a reminder, i'm a complete CSS newb ;)
14:55:34nc-xAlso, IMO https://nim-lang.org/learn.html should also link to devel docs
14:56:07narimiranshit, you're right, i forgot to change it there (i did in documentation.html)
14:56:23nc-xnarimiran: well consider this assignment for learning CSS ;P
14:57:18*narimiran looks in Araq's direction, he doesn't look very pleased with that idea
14:57:53FromGitter<alehander42> https://github-history.netlify.com/nim-lang/nim/commits/master/compiler/nim.nim
14:58:04FromGitter<alehander42> pretty cool app
14:58:17FromGitter<alehander42> (arrows left right)
14:58:42narimirannc-x: i might consider this "crazy" style fixes, once i'm pleased with the content ;)
14:59:12nc-x👍
15:02:08*nc-x quit (Quit: Page closed)
15:10:59*PMunch joined #nim
15:11:12*shadowbane quit (Quit: Konversation terminated!)
15:15:01*shadowbane joined #nim
15:20:03*aguspiza joined #nim
15:20:46xace_btw a little nitpick i have: Wouldn't it be reasonable to have links at the top of the forum to go back to the nim-lang.org website? or maybe even have all the links (blog, features, download, learn, documentation, forum, donate) at the top?
15:23:16*tzuiii joined #nim
15:24:38*kapil____ joined #nim
15:25:41*tzuii quit (Ping timeout: 246 seconds)
15:32:48*vlad1777d quit (Ping timeout: 252 seconds)
15:34:59*JustASlacker quit (Quit: Leaving)
16:17:50FromGitter<kaushalmodi> Araq: koch doesn't build on devel
16:17:51FromGitter<kaushalmodi> > lib/pure/streams.nim(49, 64) Error: can have an unlisted effect: ReadIOEffect
16:18:09FromGitter<kaushalmodi> looks relevant to that last commit maybe
16:18:38*vlad1777d joined #nim
16:21:32narimiranaaaah, so *that's* why my unrelated streams PR fails!
16:26:03*vlad1777d quit (Ping timeout: 268 seconds)
16:30:27*jacobsin joined #nim
16:32:45leorizexace_: yep, basically it's not possible to do TCP connection with vimscript in vim
16:33:17leorizenot to mention that matchaddpos is terrible, I need the nvim buffer highlight API
16:37:10*Trustable joined #nim
16:40:27Araqbah
16:40:44Araqworks for me
16:41:10*rnrwashere joined #nim
16:41:50FromGitter<kaushalmodi> Travis is failing
16:42:15FromGitter<kaushalmodi> See the run_CI koch failure
16:42:46Araqyeah, reproduced
16:43:21xace_leorize: oki cool i'll try to grumble about it for a couple of hours and then give up
16:43:47leorizemigrate to nvim! :P
16:43:52Araqnarimiran, did you backport the streams.nim changes?
16:44:20narimiranwhen, what?
16:45:36Araqfor 0.19.4
16:46:06xace_leorize: lol i wish i had the courage to take the first step
16:48:29*rnrwashere quit (Remote host closed the connection)
16:49:59narimiranAraq: the last two commits in streams.nim in 0.19 branch were some docs update in october
16:50:26*rnrwashere joined #nim
16:50:40Araqkk
16:50:50*fanta7531 quit (Quit: fanta7531)
16:52:56*jacobsin quit (Ping timeout: 240 seconds)
16:53:23*rnrwashere quit (Remote host closed the connection)
16:55:03*rnrwashere joined #nim
16:55:05FromGitter<alehander42> nice change in style of
16:55:13FromGitter<alehander42> css* of the manual narimiran
16:55:31narimiranthanks :)
16:55:51*rnrwashere quit (Remote host closed the connection)
16:57:30*nsf joined #nim
17:01:12shashlickAraq: you cool if I fix this https://github.com/nim-lang/Nim/issues/9370 cc @timotheecour @mratsim
17:01:21shashlickit is extremely annoying when working with C libs
17:02:59FromGitter<brentp> I am using `setMaxPoolSize(threads)` where, `threads` is, e.g. 12. Then I `spawn` ~600 and `blockUntil` they are all done. It appears that it always uses the number of CPUs available on the machine, even if I specify a single thread. Am I using that wrong or is this a known problem?
17:03:28Araqshashlick: sure
17:03:53Araqbrentp: how do you specify the single thread?
17:04:05FromGitter<brentp> here is the actual code: https://github.com/brentp/somalier/blob/master/src/somalier.nim#L531-L550
17:04:16FromGitter<mratsim> lgtm
17:04:24FromGitter<brentp> @Araq, I just mean, with `threads = 1`
17:04:25FromGitter<mratsim> @shashlick^
17:04:52shashlickhttps://github.com/nim-lang/Nim/issues/10299 is the more overarching issue
17:06:34shashlickanother question - is there any workaround for https://github.com/nim-lang/Nim/issues/9863
17:08:08Araqdon't use static in macros, it's confusing
17:08:28*rnrwashere joined #nim
17:09:12shashlickeven without static, if I use `seq[string] = []`, it doesn't work
17:10:02shashlickError: type mismatch: got <array[0..-1, empty]> but expected 'seq[string]'
17:11:36Araq@[]
17:12:03FromGitter<mratsim> static is the only way to pass values instead of Nimnodes to macros
17:13:41*PMunch_ joined #nim
17:14:04shashlick@[] gets forced to empty no matter wht I pass into the macro
17:14:28FromGitter<brentp> @Araq, here is a reproducer. on my (linux) machines, it uses all available CPUs even though I set pool size to 1. ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ Am I using this incorrectly? [https://gitter.im/nim-lang/Nim?at=5c5b15f47b68f94102806d91]
17:14:34shashlickAraq: http://ix.io/1AlD/nim
17:14:34*rnrwashere quit (Remote host closed the connection)
17:14:40shashlickif you run that, it will print Nothing
17:15:04shashlickss.kind = nnkSym
17:15:56*PMunch quit (Ping timeout: 240 seconds)
17:16:14*rnrwashere joined #nim
17:17:07Araqproc setMaxPoolSize*(size: range[1..MaxThreadPoolSize]) =
17:17:07Araq maxPoolSize = size
17:17:07Araq if currentPoolSize > maxPoolSize:
17:17:09Araq for i in maxPoolSize..currentPoolSize-1:
17:17:11Araq let w = addr(workersData[i])
17:17:13Araq w.shutdown = true
17:17:32Araqmakes no sense to me, it needs to shutdown threads for 1
17:17:48Araqbut still it should work, maybe you spawn too quickly afterwards
17:18:29*d10n-work joined #nim
17:20:20FromGitter<brentp> even with `setMaxPoolSize(2); sleep(1000)`, it uses all CPUs.
17:23:13*PMunch_ quit (Remote host closed the connection)
17:24:21*aguspiza quit (Ping timeout: 246 seconds)
17:26:19*rnrwashere quit (Remote host closed the connection)
17:28:59*rnrwashere joined #nim
17:31:26*rnrwashere quit (Remote host closed the connection)
17:33:39*kapil____ quit (Quit: Connection closed for inactivity)
17:34:35narimiran@alehander42 if you notice some regressions or things that could be improved in the docs visual style, let me know (i already have some small fixes, but waiting for something more substantial before i push it :))
17:35:40narimiranwell, that goes for the rest of you too, not only for alehander ;)
17:37:01shashlickso is this a bug - http://ix.io/1AlD/nim - prints Nothing
17:54:25*rnrwashere joined #nim
17:57:01*jacobsin joined #nim
17:57:34*fanta7531 joined #nim
18:01:34*jacobsin quit (Ping timeout: 250 seconds)
18:02:07*volkov joined #nim
18:10:06*volkov quit (Remote host closed the connection)
18:12:16Zevvnimterop generates distinct ints instead of enums, is that new?
18:12:44shashlickit changed a month ago
18:12:50leorizeit should be better than generating enums
18:13:05shashlickhttps://github.com/nimterop/nimterop/issues/99
18:13:28ZevvHmm ok.
18:14:10ZevvI'll fix those by hand, I like the ability to convert from and to strings
18:14:16Zevvfor debugging and other purposes
18:14:24leorizewell the `$` not printing the enum name can be solved by generating `$`
18:14:28leorizeshouldn't be too hard
18:14:37shashlickdo you mean $enum => enum
18:14:44shashlick@timotheecour has that same concern
18:14:53shashlickthat thread discusses that
18:15:04*Zevv reading up
18:15:20leorizesince you have a map of them anyway, building a `$` proc would be simple
18:15:53Zevva map?
18:16:14ZevvI have a distinct type and a number of consts using the type
18:16:25shashlickthe problem is when multiple names map to the same value
18:16:47ZevvI see, that kind of defies the purpose of an enum
18:16:56shashlickbut C does crazy things with enums
18:17:05Zevv"C does crazy things"
18:17:07shashlickand hence it cannot be mapped to Nim enums which are more disciplined
18:17:19leorizethere's a "hack" around that, but it's rather complicated
18:17:22*Trustable quit (Remote host closed the connection)
18:17:31leorizeand I believe I've showed @shashlick before :P
18:17:35Zevvyes, but how is building a `$` simple, I need to provide this myself, I can not deduce that from the defined types, right?
18:17:50leorizeZevv: I was talking about nimterop :P
18:17:50shashlickleorize: I had the converter before but there was push back on that
18:18:04Zevvleorize: ah ok
18:18:41shashlickif you can give me a template that converts the enum name to a string, will be great 😄
18:19:13leorizeastToStr to the rescue :P
18:19:21leorizeobviously doesn't work on runtime enums
18:21:15leorizeor, you could make a `$` that prints "thisEnum or thisOtherEnum" :P
18:21:29leorizeand pray that people don't mistake that as bitwise or
18:22:24ZevvI see the problem, but it is too bad that I lose enum semantics for all cases where the C enums are well-behaved
18:22:35Zevvpardon my complaining :)
18:23:04Zevvfor example, the distinct int type is not limited to the enum values
18:23:08shashlickno worries - so the main thing you miss is being able to print the enum name?
18:23:13leorizemost of the semantics doesn't work with C enum anw
18:23:22Zevvwell, it doesn't *feel* like an enum anymore :)
18:23:44leorizeyou can say enum is a `distinct range[]`
18:24:13*rnrwashere quit (Remote host closed the connection)
18:24:26ZevvIf the range is continguous the distinct int could be range limited
18:25:06Zevvbut if not, then not, and then the behaviour is unpredictable
18:25:35leorizeenum with holes is not really well treated in Nim as well
18:25:37Zevvthere is simple no single good solution
18:25:40leorizeyou can't really `inc` them
18:25:49Zevvtrue
18:26:12leorizeand `set[Enum]` can't be guaranteed to work with C
18:26:34leorizeI saw people use it, but I think it's only working because of the current internals
18:27:14ZevvOk, I'll just provide a few `$`s for the cases I need, then I'll probably be fine
18:27:17Zevvthanks for the info
18:27:28shashlickagain, want to clarify - is the problem mainly printing the enum?
18:27:37Zevvat this time it is
18:27:50Zevvbut then the next problem would of course be the other way around :)
18:28:17shashlickwe can track values and print the enum name, but if there are duplicate values, you will get the first instance
18:28:33leorizeyou can print `or this value` :P
18:28:42Zevvwould/could/should it make sense to make two cases of code generation. One for well-behaved enums, and one for the rest?
18:28:56Zevvso that nice enums still map to a Nim enum
18:30:21shashlickso traditional enum is painful since C enums can be out of order
18:30:45shashlickif we want to imlpement that, it would mean calculating and verifying the actual value and reordering
18:31:00leorizeand that's basically implementing nimterop/nimterop#99
18:31:16shashlickyes and i don't know if it is really worth it
18:31:25shashlickthough @timotheecour thinks differently
18:31:39shashlickas it is, such tools become complex quickly and then maintenance becomes hard
18:31:41*jacobsin joined #nim
18:32:06shashlickbut i could just as well be called lazy so I prefer staying open to ideas
18:32:47Zevv:)
18:33:07ZevvAnyway, I need to go. Thanks for the background info
18:33:14Zevvlater!
18:33:28leorizethe idea isn't too bad
18:33:36leorizebut I found the argument rather inconvincing
18:34:01leorizethe only thing I miss is `$`
18:34:29shashlickcan you please explain
18:34:36*fanta7531 quit (Quit: fanta7531)
18:35:15*aguspiza joined #nim
18:35:34leorizefrom what I can read in nimterop/nimterop#99, these are the main reason: "type safety, and $ prints as int which is really not good"
18:35:50leorizeof which I'd say using enum won't give us any more type safety
18:36:01*rnrwashere joined #nim
18:37:19leorize`distinct int` is as typesafe as an `enum`
18:37:41leorizesure, it won't bound check, but you can't get that with sparse enums either
18:38:07*rnrwashere quit (Remote host closed the connection)
18:38:11shashlickok sounds fair, please share your thoughts on that issue - i'd rather keep the implementation as is so that we can focus on adding more support C/C++ declarations
18:42:35FromGitter<kaushalmodi> shashlick: Nim allows naming multiple deprecated enum names to the same enum
18:42:57FromGitter<kaushalmodi> not perfect, but that might at least remove a road block
18:43:08FromGitter<kaushalmodi> the code will compile but with deprecation warnings
18:43:23leorizethat's basically a dirty hack
18:43:46leorizeshashlick: ever thought of splitting nimterop facilities into Nim's macros?
18:43:58shashlickwhich portions?
18:44:12leorizesplit the cenum generating code?
18:44:24shashlickoriginally, toast only generated the AST to stdout and all rendering was done in cimport / compile time
18:44:34shashlickit is just much faster to do it in toast
18:44:36leorizeit can be nice for others to use it without using nimterop
18:44:45shashlicksince i can directly use the tree-sitter data structure
18:45:18shashlickotherwise i had to recreate the data structure at compile time
18:45:29shashlickplus restricted to the vm, but that didn't really affect much
18:45:34shashlickit was just slower
18:45:43leorizeI see
18:45:59shashlickeven toast could be done in compile time once you can ffi
18:46:53leorizeI was hoping to see a cenum macro like this: `cenum Enum: eVal1 = 100, eVal2 = 10`
18:47:17leorizeit's rather helpful when manually writing wrappers
18:47:28leorizebut I guess we should automate everything nowadays :P
18:50:14*rnrwashere joined #nim
18:51:46shashlickno you are supposed to use nimterop and not hand write anything anymore 🙂
18:54:08FromGitter<arnetheduck> shashlick, you were asking for examples for nlvm, but I can't really think of any better examples than nlvm itself..
18:56:22shashlicksounds fair - what's a good file to look at
18:57:39*rnrwashere quit (Remote host closed the connection)
18:59:03*rnrwashere joined #nim
18:59:45FromGitter<arnetheduck> https://github.com/arnetheduck/nlvm/blob/master/llvm/llvm.nim probably.. it provides an easy-to-use interface over the raw c interface
19:01:13shashlickcool
19:02:12FromGitter<arnetheduck> then there's https://github.com/arnetheduck/nlvm/blob/master/nlvm/llgen.nim, but it might be a bit intimidating (I'm a happy code-folding user)
19:11:23*TheLemonMan joined #nim
19:12:22TheLemonManleorize, fwiw vim does support TCP connections, see https://vimhelp.org/channel.txt.html
19:13:30TheLemonManand if you want to abstract over the differences between vim and neovim's async implementation check out https://github.com/prabirshrestha/async.vim
19:13:30*housecarpenter joined #nim
19:14:07TheLemonManit'd be nice to have the code-completion part at least, who cares about syntax highlighting
19:17:58*aguspiza quit (Ping timeout: 245 seconds)
19:21:07*tzuiii quit (Remote host closed the connection)
19:24:48narimiranTheLemonMan: completely offtopic: i love your punny package names! :)
19:26:23TheLemonManhah thank you, that's my creative outlet
19:39:59narimiranbtw, the content of your packages is also ok, i guess :P
19:40:58*lritter quit (Quit: Leaving)
19:52:42*smitop joined #nim
19:53:40smitopIf I use a relative path from ``staticRead``, is it relative from the nim file calling it, the working directory the compiler is in, or something else?
19:54:11TheLemonManthe file it's written in iirc
19:54:14*nsf quit (Quit: WeeChat 2.3)
19:59:13*jacobsin quit (Remote host closed the connection)
20:03:43*Ven`` joined #nim
20:08:39*rokups quit (Quit: Connection closed for inactivity)
20:17:25*TheLemonMan quit (Quit: "It's now safe to turn off your computer.")
20:21:23*zachk joined #nim
20:21:52*rnrwashere quit (Remote host closed the connection)
20:22:08*zachk quit (Changing host)
20:22:08*zachk joined #nim
20:28:56*kapil____ joined #nim
20:34:29FromGitter<timotheecour> @araq > *<Araq>* Error: unhandled exception: testresults\io.json(2, 186) Error: ] expected [JsonParsingError] ⏎ ⏎ => there’s a recent issue about that that was closed; the fix: `rebuild koch` (the potential better fix: koch warns when it’s dirty based on `hash(koch.nim)`
20:34:41*aguspiza joined #nim
20:41:40*floppydh quit (Quit: WeeChat 2.3)
20:53:49Araqsince you're here, https://github.com/nim-lang/Nim/pull/10150
20:56:18*aguspiza quit (Ping timeout: 245 seconds)
20:57:27livcdso i was not able to try falcon hmmm...i get the same error on mac as i did on windows for nake: https://paste.fedoraproject.org/paste/A7f-5413Vxe2BcvdTk2zRA
20:59:11AraqexecProcess("git", „“, ["--no-pager", "show", "-s", "--format=%ci", "HEAD"],
20:59:11Araq options = {poUsePath})
21:00:50Araq#### Breaking changes in the standard library
21:00:51Araq- `osproc.execProcess` now also takes a `workingDir` parameter.
21:02:33livcdwell ok i replaced it with what the git command gives
21:03:14dom96Hey guys
21:06:14livcdwell i am just running into more issues which i dunno how to solve: https://paste.fedoraproject.org/paste/0HLmWiI~5FKxBhLzuhCQQg
21:13:27FromGitter<deech> Is VSCode currently the best supported Nim editor?
21:16:43*narimiran quit (Ping timeout: 245 seconds)
21:18:06livcdyglukhov[m]: ping
21:22:22FromGitter<timotheecour> @araq: yeah, i intend to follow up on https://github.com/nim-lang/Nim/pull/10150 ; it was actually quite close , need to rebase and i know how to fix that CI failure; so many things to do… maybe this weekend
21:22:50Araqthe PR queue is too long
21:23:10Araqand we need to do something about it
21:23:18FromGitter<timotheecour> well u can filter out stuff which has broken CI when viewing it
21:23:22Araqand yes, that's not your fault. ;-)
21:23:40Araqbroken CI can also simply mean timeout, unfortunately
21:24:34FromGitter<timotheecour> how about we add a tag to indicate: WIP (with meaning: don’t look at my PR unless u’re nice and want to help)
21:25:07Araqand I've said before, if you're blocked because we don't merge quickly enough, consider working on a single timothee branch that you want to merge occasionally
21:25:22*housecarpenter quit (Read error: Connection reset by peer)
21:25:41AraqWIP PRs are noise for me, the github issue tracker is not anybody's personal todo list.
21:26:42*housecarpenter joined #nim
21:26:42FromGitter<timotheecour> well everyone does it and it actually helps to see what’s the current WIP PRs, but as a reviewer, u’re free to ignore these
21:27:19FromGitter<timotheecour> but i do care about the existing WIP PRS from others (eg that thing from krux02 to fix node comments in AST…)
21:27:58AraqI'm looking at that right now
21:28:49FromGitter<timotheecour> there’s a ton of good work from everyone that goes to waste because it’s 90% complete and the final push is not done, it’s sad
21:29:03FromGitter<timotheecour> (and ya, i have a lot of these)
21:32:47*Ven`` quit (Ping timeout: 240 seconds)
21:33:27Araqnot much goes to waste, they stay open until somebody completes it and merges it
21:34:37FromGitter<timotheecour> well it’s a waste until those 86 issues materialize
21:35:13FromGitter<timotheecour> but they bitrot… and then the author abandons them (and yes, guilty of it)
21:36:10FromGitter<timotheecour> `s/abandon/neglect/` bc of shifting priorities
21:38:21*dragan joined #nim
21:38:58FromGitter<timotheecour> back to bootstrapping GC before GC is initialized: for platforms w malloc, we can use that; for platforms without it, we can have a CT flag with `—allocateScratchSpace=64000` => allows having a working `echo $(10, “foo”, bar)` while debugging system.nim
21:40:50FromGitter<timotheecour> avoids all those issues w not allowing `echoBinSafe` before `import io` or not allowing allocations in `gc.nim`
21:43:08*rnrwashere joined #nim
21:43:36FromGitter<akavel> Hi! I'm trying to write two mutually-recursive functions with `concept` parameters, and I'm getting an: `Error: generic instantiation too nested` - is it illegal to do?
21:43:53*rnrwashere quit (Remote host closed the connection)
21:45:51draganHi!
21:47:02Araqhi dragan welcome
21:47:06FromGitter<timotheecour> @akavel => https://github.com/nim-lang/Nim/issues/9422
21:51:23FromGitter<akavel> @timotheecour hmm, the reply by Araq in #9422 says "exponential compiletimes are known and mysterious", but doesn't say anything about your "Error: too nested for type matching" nor my "Error: generic instantiation too nested"... :/
21:51:40FromGitter<akavel> are those two errors "known and mysterious" too? or are they "known and non-mysterious"?
21:53:42FromGitter<timotheecour> it’s the same error i think; `too nested for type matching` error happens because nim compiler caps number of iterations (because, it’s exponential)
21:54:06Araqwell the one exponential bug's cause is known now and a converter bug
21:54:10FromGitter<timotheecour> so u can tweak that number (as i did ) but it kicks the can down the road
21:54:16Araqwe also had a fix for it, somewhere.
21:54:55FromGitter<timotheecour> but https://github.com/nim-lang/Nim/issues/9422 doens’t use converter
21:54:56AraqI also had a nice idea for concepts that I need to implement before concepts can move further
21:55:21FromGitter<timotheecour> i have a much better than `concept`
21:55:30FromGitter<timotheecour> more flexible, simpler to implement
21:56:00FromGitter<akavel> Should I try to simplify this to a minimal reducer and submit an issue on github?
21:56:14FromGitter<akavel> the case I have?
21:56:15*Vladar quit (Remote host closed the connection)
21:56:45FromGitter<akavel> it seems quite simple, so at first glance should be really easy to minimize
21:56:46FromGitter<timotheecour> @araq https://github.com/nim-lang/RFCs/issues/60
21:56:53FromGitter<akavel> *reducer = reproducer
21:59:11FromGitter<timotheecour> @akavel maybe try to search if ur test case is a duplicate , if not, then definitely sure, maybe add test case to https://github.com/nim-lang/Nim/issues/9422 or create a new issue depending on ur finding
21:59:35FromGitter<timotheecour> (after minimizing)
22:00:27Araqha, no, that's terrible
22:01:02Araqakavel: mutally recursive concepts sound uncomputable to me
22:01:26FromGitter<akavel> Araq: no, the concept is one :)
22:01:42FromGitter<akavel> just it has two procedures which are mutually recursive
22:01:50FromGitter<akavel> operating on the same one concept
22:02:16*smitop quit (Quit: Connection closed for inactivity)
22:02:25FromGitter<akavel> `proc foo(x: MyConcept)` and `proc bar(x: MyConcept)`
22:02:26FromGitter<timotheecour> at least post some code (a PR in ur scratch repo is easiest, else a gist )
22:03:07FromGitter<akavel> foo calls bar in some cases, bar calls foo
22:03:08Araqwell mutually depending generic procs are hard too
22:04:08draganI just wanted to say that you are doing great job, Nim is great language, my first impressions
22:04:13FromGitter<akavel> Ok, so it seems I'm out of luck here?
22:05:13FromGitter<timotheecour> just post some code (the friendliest way is a PR if more than 1 file, or a gist is fine if a single file) and maybe we can see if there’s a better approach?
22:05:24FromGitter<timotheecour> (PR against ur own repo)
22:05:25FromGitter<zetashift> https://github.com/nim-lang/Nim/issues/8927#issuecomment-459982345 I'm excited :D
22:05:46FromGitter<akavel> @timotheecour Ok, I'll try, thanks. As to PR, what do you mean?
22:06:29FromGitter<akavel> @timotheecour Uh, right, well, ok, actually I already have this code in the repo already;
22:06:39FromGitter<akavel> the repo is in non-compiling state currently
22:06:43FromGitter<timotheecour> something that makes it easy for ppl to try out ur test case w a one liner: ⏎ `git clone foo && nim c -r bar.nim`
22:07:08FromGitter<akavel> Ahh, ok
22:07:20FromGitter<timotheecour> (friendlier than gist IF there’s more than 1 file involved)
22:07:29draganI want to help with the documentation if you like
22:07:59Araqdragan: nice, contact narimiran[m] when he's awake
22:08:08FromGitter<timotheecour> @dragan => https://github.com/nim-lang/Nim/issues/10330
22:08:29FromGitter<akavel> @timotheecour So, I've just uploaded last fixes which led to this error, so it's currently available for cloning at: https://github.com/akavel/nixme
22:09:05FromGitter<akavel> sorry, branch *nim*
22:09:27FromGitter<akavel> the default master is still Rust
22:10:31FromGitter<akavel> `git clone -b nim https://github.com/akavel/nixme` I suppose
22:11:05FromGitter<akavel> the problem is between lines:
22:11:09FromGitter<akavel> https://github.com/akavel/nixme/blob/0edc067225bb2db92dbc2d46dbc20a93d1796b1c/src/nixmepkg/nar.nim#L27
22:11:21draganGreat then, I needed an analogue of fseek, fread, offset, but I can't find an example in the docs, so after I port my project I can start with that maybe :)
22:11:24FromGitter<akavel> https://github.com/akavel/nixme/blob/0edc067225bb2db92dbc2d46dbc20a93d1796b1c/src/nixmepkg/nar.nim#L60
22:11:39draganFileIO is crutial i think
22:12:24Araqon devel it's now in system/io.nim (still part of system, so no import required)
22:13:15FromGitter<akavel> `parse_node` calls `parse_directory`, which may again call `parse_node` (because directories obviously may contain other files/directories, etc.)
22:14:02FromGitter<akavel> and I need to pass some "Handler" type to these, which will have a few methods, namely "create_directory", "create_file", "create_symlink"
22:14:31FromGitter<akavel> I thought I could use concept for that, thinking it might be similar like trait in Rust, or interface in Go
22:15:02FromGitter<akavel> but given that it won't work like that, is there something else I could/should use here?
22:15:12FromGitter<timotheecour> @dragan lib/system/sysio.nim:52:12: proc c_fseek(f: File, offset: int64, whence: cint): cint {.
22:15:30FromGitter<timotheecour> (ripgrep is your friend … or nimgrep but ...)
22:15:54FromGitter<akavel> I couldn't find anything good in the Manual... but I'm totally a noob, I might have overlooked something
22:16:27FromGitter<akavel> so, any suggestions? @timotheecour ?
22:16:56*craigger quit (Ping timeout: 268 seconds)
22:17:56FromGitter<akavel> Should I create an object type? but I don't understand well if objects inherit methods in Nim?
22:17:59*craigger joined #nim
22:18:00Araquse streams.nim
22:18:04FromGitter<timotheecour> turns out `c_fseek` is not exported ; as a temporary workaround in ur code u can grep (better: ripgrep) for fseek => u find `proc c_fseek(f: File, offset: int64, whence: cint): cint {. ⏎ ⏎ ```importc: "fseeko", header: "<stdio.h>", tags: [].}` => and copy that to ur code``` [https://gitter.im/nim-lang/Nim?at=5c5b5d1c9221b9382d280118]
22:18:19Araqthere is setFilePos
22:18:25FromGitter<akavel> also seem to have seen that "inheritance is deprecated" or something like that somewhere around Nim docs...
22:18:43Araqnah, it's not
22:19:08Araqinheritance is here to stay, methods will change
22:19:38shashlickAraq: after your io.nim change, we cannot open files at compile time anymore
22:19:42FromGitter<timotheecour> @araq https://nim-lang.github.io/Nim/io.html gives 404
22:19:52shashlicksystem\io.nim(483, 9) Error: VM is only allowed to 'cast' between integers and/or floats of same size
22:20:39shashlickreadFile and writeFile both worked fine before this commit
22:20:47FromGitter<timotheecour> ouch
22:21:42*Araq shrugs
22:21:53Araqwe have thousands of tests for these things
22:22:09Araqadd another one and fix the regression
22:23:32FromGitter<akavel> still, for now I should probably try replacing the concept with an object + methods with {.base.}?
22:24:30shashlickAraq: has the mapping changed? was "stdlib.system.X" - shouldn't it be the same?
22:24:39Araqshashlick: ah :D
22:24:50shashlickvmops.nim
22:24:52Araqwell now it's system.io.X
22:25:06Araqgood catch, but the tests should have caught it
22:25:10shashlickso no more stdlib? or stdlib.system.io.X
22:25:24Araqno, it's stdlib.io.X
22:25:41Araqpackage.realmodule.X (forwarding doesn't count)
22:26:00shashlickcool i'll fix later today
22:26:15shashlickwhile i'm in there, can we add copyFile, moveFile and related calls also to the VM?
22:26:22shashlickall file and dir operations
22:27:58Araqakavel: https://github.com/nim-lang/Nim/blob/devel/lib/pure/parsesql.nim#L639 this is how to write a parser
22:28:31Araqno dynamic binding, no concepts, no need to pretend that you don't know the involved types
22:28:50shashlickalternatively, can I add a macro that can add all exported procs of a module into the vm and put os/io in there
22:29:03Araqrecursive descent parsing, was invented in the 50ies or something and still works better than anything else invented afterwards
22:30:13Araqshashlick: for the VM or for Nimscript?
22:30:17FromGitter<timotheecour> => `static: writeFile` doesn't work anymore since `system refactorings` · Issue #10585 · nim-lang/Nim (https://github.com/nim-lang/Nim/issues/10585)
22:30:19shashlickfor the VM
22:30:27Araqhmmmm
22:30:28FromGitter<timotheecour> just filed: `static: writeFile` doesn't work anymore since `system refactorings` #10585
22:31:11FromGitter<akavel> Araq: hmm, I'll have a look, but I really might not know the involved types:
22:31:12shashlickotherwise I have to write sad code like this - https://github.com/nimterop/nimterop/blob/master/nimterop/git.nim#L25
22:31:24FromGitter<akavel> I want to be able to plug in various handlers
22:31:31FromGitter<akavel> of the AST
22:31:56FromGitter<akavel> while parsing - without having to build the full AST in memory
22:32:17FromGitter<akavel> a.k.a. "parsing events"
22:33:18FromGitter<akavel> like the whole XML parser libraries quagmire some years ago
22:33:24AraqI don't like parsing events at all but they are easy, give the parser a bunch of callbacks
22:33:28FromGitter<akavel> with "event parsers", "pull parsers", etc.
22:33:55FromGitter<akavel> So, proc fields, right?
22:34:02FromGitter<akavel> Like in the streams library?
22:34:46Araqright.
22:34:58FromGitter<akavel> Ok, thanks!
22:35:06Araqshashlick: bah, it's so sad that you convinced me
22:36:06shashlickYay!
22:36:41shashlickOk so continue to pick and choose procs or can I look into mass import
22:37:29*rnrwashere joined #nim
22:37:45FromGitter<timotheecour> 404 error => https://github.com/nim-lang/Nim/pull/10587
22:38:04FromGitter<timotheecour> (PR, not issue)
22:38:06shashlickAssuming I can process a module ast and identify proc signatures at that point
22:38:10*rnrwashere quit (Remote host closed the connection)
22:38:38Araqno mass imports!
22:40:23shashlickOk then generic code with white list?
22:40:44shashlickBasically from module import x y
22:46:58ZevvIs there a way to limit the visibility of templates to a block scope of another template?
22:50:25Araqdeclare the template inside a template
22:50:28Araqshashlick: yes
22:50:31Zevvoh that simple :)
22:52:29*stefanos82 quit (Remote host closed the connection)
22:59:06*NimBot joined #nim
23:00:55*rnrwashere joined #nim
23:01:28*rnrwashere quit (Remote host closed the connection)
23:10:01*rnrwashere joined #nim
23:11:25*rnrwashere quit (Remote host closed the connection)
23:11:32*rnrwashere joined #nim
23:19:59Zevvbasic Z3/Nim working: http://paste.debian.net/plain/1065752
23:27:04Araqnice
23:29:13*rnrwashere quit (Remote host closed the connection)
23:32:46FromGitter<timotheecour> @araq i’m fixing the regression introduced w `system refactorings` here: https://github.com/nim-lang/Nim/pull/10588; could i pretty-please have a merge-when-ci-passes so i can focus on reducing that PR queue we talked about?
23:34:30Araqthen why do you add 'removeFile' to the VM
23:34:57Araqyay, compile-time bomb, nuke your $HOME by doing 'nim c'
23:35:00FromGitter<timotheecour> i explained why: it avoids yet-more error prone workarounds in CT client code
23:35:17Araqand I just explained why it's bad
23:35:21FromGitter<timotheecour> client code can already do that w `gorge “rm …”`
23:35:49Araqnot on Windows
23:36:07FromGitter<timotheecour> u can’t rm files on windows shell?
23:36:18Araqno it's called 'del'
23:36:18*rnrwashere joined #nim
23:36:55FromGitter<timotheecour> so, same thing, client code can already do that at CT w `del`; it’s not making situation any worse, only better bc removeFile is safer alternative
23:37:48FromGitter<timotheecour> (and portable, and avoids catastrophic issues when a quoting bug in client code deletes wrong file w the shell workaround to removeFile)
23:38:15Araq1. some protection in gorge would be nice.
23:38:48Araq2. requiring a hack means it's not sanctioned.
23:39:19Araq3. don't conflate feature additions with bugfixes.
23:39:21FromGitter<timotheecour> what i’m very happy to do (maybe in other PR) is an option `nim —sandboxCT:true` (in another PR) that would prevent certain things at CT
23:40:11Araqlet me say it again: you have a problem, a valid one. Result: Nim has one more compile switch.
23:40:31AraqFor everybody.
23:40:38Araqbecause hey, you had a problem.
23:40:56Araqit really pisses me off.
23:41:44FromGitter<timotheecour> git has a milliion and i can still use it, its cmd line is well designed; flags r there for a reason; I just put it in my user config ONCE and never bother looking at them again
23:47:10FromGitter<timotheecour> it’s like nim: it has a ton of features, but learning curve is mild bc u don’t need to learn all features before u can start using it; same w a well designed (orthogonal) cmd line: u can just ignore all `—advanced` cmdline flags and when u need it u can use it; it’s not like it’s in your face. I really don’t have a problem w clang/brew/git having more flags; the only thing that matters is sane defaults
23:47:10FromGitter... so they’re not in your face.
23:48:04*theelous3 quit (Ping timeout: 246 seconds)
23:48:44FromGitter<timotheecour> for sake of moving on and fixing that regression (which blocks nimterop), i’ll remove `removeFile` from that PR and re-introduce it in a separate PR; ok?
23:54:11*smitop joined #nim
23:54:25FromGitter<timotheecour> Done => https://github.com/nim-lang/Nim/pull/10588/files
23:57:15FromGitter<timotheecour> exact same comment as what @shashlick said: ⏎ ⏎ > *<shashlick>* otherwise I have to write sad code like this - https://github.com/nimterop/nimterop/blob/master/nimterop/git.nim#L25