<< 14-10-2018 >>
00:01:29krux02I can't say I like the situation
00:03:03FromGitter<timotheecour> well i definitely want git logs to show your name, again, I took all precautions in that PR (the above commit shows you as author), and this can be fixed by @araq via `force push`
00:04:39krux02well he is very likely asleep by now
00:04:52krux02it's 2:00 at night right now
00:10:42*Snircle joined #nim
00:16:18*krux02 quit (Remote host closed the connection)
00:17:46*derlafff quit (Quit: http://quassel-irc.org - ????????????? ??????. ?????.)
00:17:54*derlafff joined #nim
00:19:01*derlafff is now known as der
00:19:03*der is now known as derlafff
00:19:07*arecaceae quit (Remote host closed the connection)
00:19:26*arecaceae joined #nim
00:26:37*malkomalko joined #nim
00:32:56*Tortice joined #nim
00:37:27FromGitter<bpo217> I'm struggling to link a nim library I wrote to use in a C program, anyone got a moment?
00:38:56FromGitter<bpo217> This is how you compile a static library right? `nim -d:release -o:bin/list.a --app:staticlib --header --noMain compile src/list.nim`
00:51:48FromGitter<yyyc514> how does filterTmpl work? is it called from inside a macro or something?
00:52:10FromGitter<yyyc514> or am i just looking at the compiler internals now?
01:01:12bozaloshtshI feel like nim's multisync isn't talked about enough. Does any other language allow such cool compile-time polymorphism?
01:03:04bozaloshtshnon-lisp, of course
01:09:13*dddddd quit (Read error: Connection reset by peer)
01:16:40ryuomaybe D.
01:16:44FromGitter<bpo217> Can someone explain why `{.exportc.}` on a proc doesn't generate the function in the header file if you pass the compiler `--header`? I just feel like it should be there and it isn't. Am I misunderstanding what `{.exportc.}` actually does?
01:16:49ryuoNot sure though.
01:18:48FromGitter<kayabaNerve> @bpo217 What is it creating as thee header?
01:23:28FromGitter<bpo217> You mean the name of the file?
01:23:47FromGitter<bpo217> @kayabaNerve It's just the name of the nim file except .h
01:24:04FromGitter<bpo217> so `list.nim` becomes `list.h`
01:24:15FromGitter<kayabaNerve> The content.
01:24:26FromGitter<kayabaNerve> I'm asking for your Nim source and generated header.
01:24:40FromGitter<bpo217> Got it
01:24:57FromGitter<bpo217> Header file generated ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5bc29ae982893a2f3bda4cf5]
01:25:34FromGitter<bpo217> list.nim ⏎ ⏎ ```proc testingabc: string {.exportc.} = "testingabc"``` [https://gitter.im/nim-lang/Nim?at=5bc29b0ebbdc0b250539a4d3]
01:26:39FromGitter<kayabaNerve> ... What.
01:27:05FromGitter<kayabaNerve> One sec
01:27:22FromGitter<bpo217> Looks like it's there, I guess it should be callable in a test.c file if I link it properly.
01:28:07FromGitter<bpo217> I'm seeing this line `N_NIMCALL(NimStringDesc*, testingabc)(void);`
01:29:39FromGitter<bpo217> can I just do `testingabc()` in a .c file if I link everything correctly in theory?
01:31:42FromGitter<kayabaNerve> I was running it on my end.
01:31:47FromGitter<kayabaNerve> That said, I believe so.
01:31:54FromGitter<kayabaNerve> Sorry for the delay.
01:32:22FromGitter<kayabaNerve> The Nim example with `proc fib` says: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5bc29ca5ae7be9401652c120]
01:32:24FromGitter<timotheecour> ya it should work
01:32:56FromGitter<bpo217> Is that `NimMain()` call required to avoid segfaults or something?
01:33:06FromGitter<kayabaNerve> It's required to set up the Nim code.
01:33:19FromGitter<bpo217> I see.
01:33:20FromGitter<timotheecour> ya various setups (maybe initializing globals etc)
01:33:37FromGitter<bpo217> It's wild you can do this at all.
01:33:42FromGitter<bpo217> Thanks for your input.
01:42:13*rnrwashere quit (Remote host closed the connection)
01:42:33FromGitter<bpo217> Does `exportc ` work with types? I keep trying it in various places in my code and I can't get it to compile.
01:43:41FromGitter<bpo217> Maybe I have to use `{.push.}`?
01:44:09*a_chou joined #nim
01:44:16*a_chou quit (Client Quit)
01:44:21FromGitter<bpo217> jk I got it
01:47:14*rnrwashere joined #nim
01:47:14*a_chou joined #nim
02:04:48*banc quit (Quit: ZNC - http://znc.in)
02:06:45*Snircle quit (Ping timeout: 252 seconds)
02:11:19FromGitter<bpo217> So ⏎ ⏎ ```type ⏎ Tester {.exportc.} = object ⏎ value: int``` ⏎ ⏎ doesn't export anything to the generated h file. Is exporting types supported or is it only certain kinds? [https://gitter.im/nim-lang/Nim?at=5bc2a5c7600c5f6423a65ba1]
02:12:07FromGitter<yyyc514> macros can’t use regular expressions?
02:12:13FromGitter<yyyc514> because that hits the C libraries?
02:18:58leorizeyyyc514: There's nim-regex, which is a Nim-native regex library
02:19:05leorizeyou can use that with macros I believe
02:19:09FromGitter<yyyc514> oh cool :)
02:20:25*banc joined #nim
02:20:46FromGitter<yyyc514> does streams nto work either?
02:20:50FromGitter<yyyc514> Error: cannot generate VM code for s()
02:20:54FromGitter<yyyc514> streams.nim(341, 25)
02:26:25FromGitter<yyyc514> are there any good docs on what does and doesn’t work in the macro env?
02:28:38*malkomalko quit (Quit: Lost terminal)
02:35:18*a_chou quit (Quit: a_chou)
03:03:43*rlr quit (Quit: -)
03:03:54*rlr joined #nim
03:10:54FromGitter<bpo217> @yyyc514 You have probably already visited: https://nim-lang.org/docs/manual.html#macros
03:11:09FromGitter<yyyc514> yeah i find it kind of light on actual deep info though
03:11:29FromGitter<yyyc514> like no explaining the VM vs the compiled code, etc
03:12:30FromGitter<yyyc514> no mention of {.compileTime.}, etc
03:12:55FromGitter<bpo217> {.compileTime.} is in the pragmas section I believe?
03:13:24FromGitter<bpo217> https://nim-lang.org/docs/manual.html#pragmas
03:14:59FromGitter<yyyc514> right but it’s pretty important for doing anything advanced with macros
03:15:18FromGitter<yyyc514> or at least relevant
03:16:38*chemist69 quit (Ping timeout: 252 seconds)
03:18:43*chemist69 joined #nim
03:38:24*druonysus quit (Ping timeout: 252 seconds)
03:59:03*stevejohnson joined #nim
04:09:19FromDiscord<demotomohiro> This issue has been closed but what Araq told me doesn't work. https://github.com/nim-lang/Nim/issues/9359
04:19:37FromGitter<yyyc514> how can i echo without a new line?
04:21:40leorizeyyyc514: `stdout.write "no new line!"`
04:31:24FromGitter<yyyc514> anError: attempting to call undeclared routine: 'print'
04:32:46FromGitter<yyyc514> oh write
04:32:49FromGitter<yyyc514> read
04:34:51FromDiscord<demotomohiro> !eval stdout.write "test"
04:34:54NimBottest
04:35:28FromDiscord<demotomohiro> !eval stdout.write "foo"; stdout.write "bar"
04:35:30NimBotfoobar
04:42:26*grahamg quit (Ping timeout: 250 seconds)
04:49:24stevejohnsonIs it safe to cast a string to a seq[uint8] to read the bytes more easily?
04:51:06FromDiscord<demotomohiro> !eval echo cast[seq[uint8]]("foobar")
04:51:09NimBot<no output>
04:51:52FromDiscord<demotomohiro> !eval echo cast[array[6, uint8]]("foobar")
04:51:53NimBotCompile failed: in.nim(1, 6) Error: expression cannot be cast to array[0..5, uint8]
04:56:31FromDiscord<demotomohiro> !eval echo cast[array[6,uint8]]("foobar"[0])
04:56:34NimBot[102, 32, 254, 127, 0, 0]
04:57:13FromGitter<kayabaNerve> stevejohnson Still here?
04:57:35FromGitter<kayabaNerve> It's purposeless. You have `for b in str:` and str[0]
04:57:41FromDiscord<irskep> Yep, I'm still here
04:57:49FromGitter<kayabaNerve> There's no need to cast.
04:58:11FromGitter<kayabaNerve> `.len`, multiple iterators, array access...
04:58:40FromDiscord<irskep> Except that str[0] is signed, and every value I need to pull out of there is going to a uint8 (bridging to a C library) and it's just annoying to cast each access
04:59:26FromDiscord<irskep> This is an extremely minor issue, I was just curious
05:05:02FromGitter<kayabaNerve> Ah. Maybe use a converter in that specific spot?
05:05:14FromGitter<kayabaNerve> You can scope it with a block.
05:05:36FromGitter<kayabaNerve> Or, if you know the len, you can cast it to an array; not a seq, as demotomohiro showed.
05:08:49FromDiscord<demotomohiro> What I showed in above code is not safe, these values are NOT a ascii code of "foobar"
05:09:28FromGitter<kayabaNerve> LOL
05:10:22FromDiscord<demotomohiro> I showed wrong cast from string to array
05:11:11FromGitter<kayabaNerve> I got it
05:11:18FromGitter<kayabaNerve> irskep Still here?
05:11:32FromDiscord<demotomohiro> If you use C library to get/set string in Nim, cstring type might be usefull but I cannot find good example
05:13:05FromGitter<kayabaNerve> echo castarray[6 (cstring("foobar"))
05:13:15FromGitter<kayabaNerve> !eval echo castarray[6 (cstring("foobar"))
05:13:16NimBotCompile failed: in.nim(1, 18) Error: ']' expected
05:13:29FromGitter<kayabaNerve> echo castarray[6, uint8 (cstring("foobar"))
05:13:47FromGitter<kayabaNerve> Typo. array[6, uint8]] not [6].
05:13:55FromGitter<kayabaNerve> And I forgot the eval call again...
05:14:05FromGitter<kayabaNerve> !eval echo castarray[6, uint8 (cstring("foobar"))
05:14:06NimBotCompile failed: in.nim(1, 25) Error: ']' expected
05:14:45FromGitter<kayabaNerve> Is Gitter's Markdown changing what IRC is getting? 0_0
05:16:51FromDiscord<demotomohiro> it looks like you cannot type ']'
05:17:33FromDiscord<demotomohiro> !eval echo cast[array[6, uint8]](cstring("foobar"))
05:17:34NimBotCompile failed: in.nim(1, 6) Error: expression cannot be cast to array[0..5, uint8]
05:18:04FromGitter<kayabaNerve> Yeah. And that. I moved to playground.
05:18:32FromGitter<kayabaNerve> It looks like you have to use copyMem.
05:20:01FromDiscord<irskep> I'm "kind of" still here 😃 Popping in and out as I do things. I don't know the length of the array beforehand; I'm writing a parser for a binary file format.
05:20:43FromGitter<kayabaNerve> copyMem uses a dynamic len; you can use arrays sortof with {.unchecked.}
05:21:12FromGitter<kayabaNerve> I'd just write a converter in a block statement
05:21:15FromDiscord<irskep> https://github.com/irskep/rexpaint_nim/blob/master/src/rexpaint.nim
05:21:33FromDiscord<irskep> Byte format: http://steveasleep.com/rexpaint_manual.html#appendix-b:-.xp-format-specification-(and-import-libraries)
05:21:41FromGitter<kayabaNerve> Then you don't worry about the converter getting out of scope and you can use the string itself.
05:23:54FromGitter<irskep> I'm just now learning that converters are a thing, thanks!
05:24:12FromGitter<irskep> Literally started learning Nim 2 weeks ago
05:24:33FromGitter<kayabaNerve> Al good
05:26:01*darithorn quit ()
05:29:07*nsf joined #nim
05:42:41*smt quit (Read error: Connection reset by peer)
05:47:34*shashlick quit (Remote host closed the connection)
05:48:18*shashlick joined #nim
05:49:18*Widdershins quit (Ping timeout: 252 seconds)
05:50:39*Widdershins joined #nim
06:00:32FromGitter<yyyc514> Error: type mismatch: got <type Forum>
06:00:41FromGitter<yyyc514> can i actually pass the FOrum type not an instance of a forum?
06:05:30FromGitter<yyyc514> type(Forum)
06:05:31FromGitter<yyyc514> nice
06:06:00*stevejohnson left #nim (#nim)
06:10:52*rnrwashere quit (Remote host closed the connection)
06:16:55FromGitter<yyyc514> OH stdtmpl are evaluated every time, yes?
06:17:30FromGitter<yyyc514> well i mean it’s a bunch of adds i guess
06:28:29FromGitter<yyyc514> hmmm so imports can’t be dynamic or altered with templates? maybe with macros?
06:28:57FromGitter<yyyc514> or maybe it works if it’s still top-level
06:29:00*wildlander_ joined #nim
06:29:48*wildlander quit (Ping timeout: 244 seconds)
06:40:25*wildlander_ quit (Quit: Konversation terminated!)
06:41:20*wildlander joined #nim
06:57:32Araqthere is a forum thread about that
06:59:03FromGitter<kayabaNerve> Yeah but all the cool kids use Gitter.
07:01:58FromGitter<yyyc514> link?
07:02:12FromGitter<kayabaNerve> https://gitter.im
07:02:22FromGitter<yyyc514> lol to the forum thread that was mentioned
07:04:27Araqhttps://forum.nim-lang.org/t/4248#26453
07:14:13*narimiran joined #nim
07:17:24*wildlander quit (Quit: Konversation terminated!)
07:38:34*tefter joined #nim
07:50:48*endragor joined #nim
07:51:55*anamok joined #nim
07:51:57anamokhi
07:52:48anamokIf one has some ideas how to extend the standard library, where to signal it? Open a github ticket?
07:53:54*endragor quit (Remote host closed the connection)
07:56:42leorizeyes
08:14:38*anamok quit (Ping timeout: 245 seconds)
08:22:46*endragor joined #nim
08:26:28*endragor quit (Remote host closed the connection)
08:36:06*nsf quit (Quit: WeeChat 2.2)
08:39:08*hoijui joined #nim
08:44:25*Arrrr joined #nim
08:50:30ArrrrYeah, sizeOf works on compile time now
08:56:11*platoff joined #nim
09:03:21*gmpreussner quit (Ping timeout: 250 seconds)
09:03:43*gmpreussner joined #nim
09:11:32FromGitter<mratsim> on devel
09:12:48FromGitter<mratsim> Is there a way to get a the C symbol of a Nim variable? I can’t use emit (it’s for openmp annotations)
09:14:41leorizeisn't that {.emit.} job?
09:15:26FromGitter<mratsim> I can’t use emit for openmp annotations
09:16:03FromGitter<xmonader> anyone aware of ascii table library in nim?
09:16:59leorizemratsim: you could use `{.exportc: "varNameMangledByHand".}`
09:17:26FromGitter<mratsim> mmm maybe that will work
09:17:32FromGitter<mratsim> reference: https://github.com/mratsim/Arraymancer/issues/308
09:19:09FromGitter<mratsim> yeah it works, though I need to create a mangler to deal with nested template now :/
09:22:37Araqmratsim: should be a simple codegen fix, the OpenMP string needs .emit extrapolation support
09:23:06FromGitter<mratsim> ah yeah that would be nicer
09:24:16*craigger joined #nim
09:24:16*craigger_ quit (Read error: Connection reset by peer)
09:58:04*endragor joined #nim
09:59:17*krux02 joined #nim
09:59:56*endragor quit (Remote host closed the connection)
10:00:22narimiranthere are lots of "callsite is deprecated, use varargs[untyped]" errors in the tests. how exactly do you replace one with the other?
10:04:42*nc-x joined #nim
10:05:47nc-xAraq: https://ci.appveyor.com/project/Araq/nim/builds/19494192 has [Warning] - Invalid category specified "caas", no tests were run. There are 3 other such invalid categories. Have tests been removed from those categories or is it a typo?
10:08:50*nc-x quit (Client Quit)
10:28:41krux02narimiran: first of all callsite is deprecated, yes, that doesn't mean it should be removed from the tests
10:29:13narimirankrux02: ok
10:30:28krux02but generally, callsite returns a node of kind call the the macro. varargs[untyped] just provides the argument, but since you are in the marco, you know the symbol of the macro invocation
10:31:06narimiranspeaking of tests: now i have a situation where the results are different if i run file normally or i do `koch tests`!?
10:31:31narimiransomething is true in one case and false in the other :/
10:31:54krux02can you give me a link to the test?
10:31:58*Vladar joined #nim
10:33:24narimiranhttps://github.com/nim-lang/Nim/blob/devel/tests/magics/t8693.nim
10:33:52narimiranrun it with `nim c -r` and you'll get a different output than written at the top
10:34:11narimiranlast two function calls differ
10:35:07krux02I would try to rewrite the test with asserts
10:35:14krux02I don't like this output comparison
10:35:21narimirankrux02: i did, and that's how i found the error
10:35:24krux02with asserts you see better where it failed
10:35:54krux02you mean the result of bar?
10:36:23narimiranyes, `bar(any, Foo)` and `bar(Foo, any)`
10:37:12leorizewhen I run it, the last 4 lines are missing
10:37:36*Ven`` joined #nim
10:38:25krux02I would argue that the test is correct
10:39:23krux02``any`` is a tagged container for an object
10:39:35krux02similar to how objects are stored in dynamically types languages
10:40:17krux02but an ``any`` object is certainly not an int
10:40:21krux02it can contain an int
10:40:25krux02but it isn't an int
10:41:12narimiranbut how to explain different results depending on how it is run?
10:41:53leorizecould you try to count the lines? I'm missing 4 lines compared to the expected output
10:42:41ArrrrIs the doc issue stopping this PR https://github.com/nim-lang/Nim/pull/8614 ?
10:42:55narimiranleorize: i get correct number of lines (14) in both stable and devel
10:45:30leorizeArrrr: I think the fact that the author hasn't addressed the comments yet stopped the PR
10:46:38narimiranand there are three conflicts that need to be resolved, even if everything else is ok
10:46:41*elrood joined #nim
10:46:51FromGitter<timotheecour> ya need to get back to that PR
10:48:40leorizenarimiran: that test have the same output whether running with testament or the compiler
10:48:51*endragor joined #nim
10:49:12narimiranleorize: what OS?
10:49:17leorizelinux
10:49:20leorizex86_64
10:49:30narimiranhmm, strange, same here, but i get different results
10:49:34leorizealso remember to use the newly generated compiler in `compiler/nim`
10:49:46narimiranhow new is that?
10:50:21narimiranoh, now i see LemonBoy added those tests 4 hours ago
10:50:46narimiranthat answers my questions. my 1 day old devel is outdated :)
10:51:05leorizemine was 3 days old :)
10:55:04*endragor quit (Remote host closed the connection)
10:55:51narimiranyup, after updating everything is ok. sorry for the false alarm
11:03:01*endragor joined #nim
11:04:53*kapil____ joined #nim
11:08:20*endragor quit (Ping timeout: 268 seconds)
11:15:02*dddddd joined #nim
11:28:50*nsf joined #nim
11:38:35*Arrrr quit (Quit: Arrrr)
11:43:00*SenasOzys joined #nim
11:44:34*vlad1777d__ joined #nim
11:55:19krux02yay all my work on sizeof alignof is now officially listed as timothees contribution
11:55:20krux02yay
12:00:09narimirankrux02: i told you to (personally) fix those conflicts ;) because Araq told me to do it, but i've seen that that would make me the author so i declined
12:01:32elroodi believe the way to change the author of a commit was mentioned at least twice here lately
12:02:23krux02then how do I do it?
12:02:38krux02it was mentioned last night when it was too late for me to pay attention to anything
12:02:40krux02?
12:02:54krux02I don't understand
12:03:01krux02why does it matter so much to squash the commit
12:04:05narimiranif there were no conflicts, squashing your PR wouldn't be a problem
12:04:41leorizesince the commits are merged, there aren't much you can do atm
12:04:41krux02diverging history is what it was. I don't get it why people want to tamper the history to look linear when it wasn't
12:05:33krux02I wouldn't care if it was a tiny thing, but that PR was my PR I spent most work into
12:05:52krux02I think half of my total contribution to Nim is in that PR alone
12:06:28narimiranso my question, again, is: why didn't you resolve that one conflict by yourself?
12:07:42narimiranleorize: revert that commit and then merge krux02's branch?
12:08:13krux02narimiran, I did resolve all conflicts around 100 times
12:08:20krux02but that PR is big
12:08:24krux02constantly things get changed
12:08:52krux02it usally takes a day and then it has conflics again
12:09:08narimiranwhen i tried to resolve it locally, one simple merge is all it took.
12:09:54narimiranthat PR was ready to merge, there wouldn't have been "a day and then it has conflicts again"
12:10:00krux02I merged it
12:10:05krux02but the PR is closed now
12:10:57narimiranit can be reopened
12:22:03krux02narimiran, I just merged my local branch with devel
12:22:12krux02now also on my local branch every is timotee
12:22:43narimiranouch
12:23:35narimirantry reverting his commit, and then merge it?
12:23:42*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:27:30*Ven`` joined #nim
12:28:24krux02 there are already commits based on top of sizeofalignof
12:29:11narimiran:'(
12:31:09*xomachine[m] quit (Ping timeout: 276 seconds)
12:31:09*zacharycarter[m] quit (Ping timeout: 276 seconds)
12:31:09*gh0st[m] quit (Ping timeout: 276 seconds)
12:31:10*syntonym[m] quit (Ping timeout: 276 seconds)
12:31:10*bitstoppa[m] quit (Ping timeout: 276 seconds)
12:31:16*Yardanico quit (Quit: Quitting)
12:31:26*hohlerde quit (Ping timeout: 260 seconds)
12:32:02*Yardanico joined #nim
12:32:10*zacharycarter[m] joined #nim
12:32:16*syntonym[m] joined #nim
12:32:23*bitstoppa[m] joined #nim
12:32:27*Connor[m]1 quit (Ping timeout: 276 seconds)
12:32:39*gh0st[m] joined #nim
12:32:42*xomachine[m] joined #nim
12:32:44*hohlerde joined #nim
12:33:29*Connor[m]1 joined #nim
12:47:51*vlad1777d__ quit (Ping timeout: 252 seconds)
12:51:08FromGitter<kaushalmodi> krux02: If you can point me to your functional branch, I can rebase it to latest devel then, and send you the patch
12:51:15FromGitter<kaushalmodi> If you today, latest by tomorrow
12:51:38FromGitter<kaushalmodi> \* if not today
12:54:21krux02https://github.com/krux02/Nim/tree/sizeof-alignof
12:54:24krux02thanks for the offer
12:55:51narimiran@kaushalmodi: but the devel already contains a commit based on krux02's branch: https://github.com/nim-lang/Nim/commit/745f1642d6faf3a30543cd76196a7462d7460d6d
13:54:11FromGitter<kaushalmodi> Then we just need to cherry pick the missing commits from that sizeof-alignof branch
13:54:30FromGitter<mratsim> seems like you’re in for git hell
13:55:11FromGitter<kaushalmodi> I never understood "git hell"
13:55:40FromGitter<kaushalmodi> Commits are simple linked changes
13:56:11FromGitter<mratsim> when links are interleaved that’s when you get hell
13:57:09FromGitter<kaushalmodi> You should avoid that interleaving, but even then it's not too bad
13:58:32FromGitter<kaushalmodi> If you are working off a branch for a long time, it's a good practice to keep on rebasing your local branch to upstream
14:21:18*SenasOzys quit (Ping timeout: 245 seconds)
14:24:28narimirancan somebody run this and tell me if everything is ok on your end: https://github.com/nim-lang/Nim/blob/devel/tests/sets/tsets3.nim
14:24:39narimiranhere it fails on line 94
14:27:29*SenasOzys joined #nim
14:36:46*stefanos82 joined #nim
14:40:23FromDiscord<Shield> https://docs.microsoft.com/en-us/windows/desktop/DxTechArts/lockless-programming
14:41:45FromDiscord<Shield> and with that my lockless approach died, multithreading is really a pain, who would've thought that both the compiler and CPU can rearange the order of operations
14:43:06*smt joined #nim
14:43:56*kapil____ quit (Quit: Connection closed for inactivity)
14:49:00*nc-x joined #nim
14:49:05nc-xnarimiran: fails for me as well
14:49:43*nc-x quit (Client Quit)
14:49:43narimirannc-x: thanks. interesting that when i run `koch tests cat sets` everything is fine
14:50:36FromGitter<kaushalmodi> krux02: which commits from your branch are already in devel?
14:51:04narimiran@kaushalmodi: all of them, but squashed, from what i can tell
14:51:06krux02all except the last merge that doesn't do anything really
14:51:16krux02yes
14:51:39*anamok joined #nim
15:00:12*rnrwashere joined #nim
15:06:52FromGitter<kaushalmodi> krux02: Then why do you want to merge it?
15:07:12FromGitter<kaushalmodi> If the devel has all the changes that are needed, but create a new branch based off that.
15:07:34narimiran@kaushalmodi it is because he is not listed as the author of those changes
15:07:52krux02kaushalmodi: I don't want to change anything, I would like that the changes that I made and that are merged have my name on them
15:08:52FromGitter<kaushalmodi> Well, then, revert those in a new local branch based off devel, and apply the changes again with the correct author
15:10:59*Trustable joined #nim
15:15:30Araqkrux02: ouch, well, we can put your name on compiler/sizealignoffsetimpl.nim
15:15:37Araqit needs a header anyway
15:15:38FromGitter<kaushalmodi> Yeah
15:16:00FromGitter<kaushalmodi> Because I don't think that otherwise force pushing is recommended on published branches
15:16:32krux02yea force push is never good
15:17:27FromGitter<kaushalmodi> So, yeah, there are no options other than committing a delete and re-addition of that file, or put yourself as the author in the file header (easier)
15:18:01krux02ok, I guess I add a file header.
15:19:34anamokhi
15:20:30dom96what's the problem?
15:20:57dom96Names in headers?
15:21:06anamokIn the signature of a proc, should I leave spaces around the `=` sign of optional parameters? 1) `proc hello(debug = true)` or 2) `proc hello(debug=true)` is better?
15:21:42narimirananamok: i've seen people mostly use spaces
15:22:11narimirandom96: this is what started the trouble: https://github.com/nim-lang/Nim/pull/9356
15:22:29anamokOK. And when you call the proc? Spaces or no spaces?
15:22:34dom96oh, that's not cool
15:23:28dom96:/
15:23:41dom96Especially since GitHub supports squashing?
15:24:51narimirandom96: it was not possible to squash krux02's branch, there was one conflict left to be resolved
15:25:05dom96So resolve it and then squash?
15:26:42narimiranthe trouble started here: https://irclogs.nim-lang.org/13-10-2018.html#18:13:31
15:27:52narimiranor maybe start reading from 18:05, where i asked krux02 to resolve it
15:29:05dom96so krux02 didn't care, but now does because his name is missing from the commits?
15:29:24narimiranyup :D
15:30:18krux02I didn't care about squashed commits
15:31:07dom96but... you're still in the commit metadata: https://github.com/nim-lang/Nim/pull/9356/commits/082612e7fbe59dfa0f25333f08e2685e88527356
15:31:20dom96and in the commit message
15:31:26*hoijui quit (Ping timeout: 252 seconds)
15:32:20*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:35:03*SenasOzys quit (Ping timeout: 252 seconds)
15:35:15dom96ugh, but that commit got changed because Araq merged it...
15:36:14*Ven`` joined #nim
15:39:41Araqcan't help it, I'll never give a fuck about git
15:40:02*edcragg quit (Quit: ZNC - http://znc.in)
15:40:36*edcragg joined #nim
16:10:21shashlickHow many of you good folks can contribute a machine - real or virtual - to run Nim builds?
16:14:10*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:17:33shashlickAlternative is to pay appveyor $150 a month and get unlimited concurrent builds :thinking_face:
16:18:30federico3shashlick: again, there was already a buildbot fleet
16:22:30*vlad1777d__ joined #nim
16:22:48shashlickWe gave it up for some reason and don't want to go back to it?
16:26:10*craigger_ joined #nim
16:28:32*craigger quit (Ping timeout: 272 seconds)
16:36:39*craigger joined #nim
16:38:47*craigger_ quit (Ping timeout: 276 seconds)
16:52:27*craigger quit (Ping timeout: 276 seconds)
16:52:45*craigger joined #nim
16:54:54*hoijui joined #nim
16:55:34FromGitter<mratsim> is there a way to do mangling with the {.compile.} pragma? I got name conflicts due to many init.c file names :/
16:55:54FromGitter<mratsim> or just emit custom names
16:57:12narimirancan somebody run this and tell me if everything is ok on your end: https://github.com/nim-lang/Nim/blob/devel/tests/sets/tsets3.nim ? here it fails on line 94
16:57:50*craigger_ joined #nim
16:59:36FromGitter<mratsim> does that mean that w can pass a tuple? https://github.com/nim-lang/Nim/blob/745f1642d6faf3a30543cd76196a7462d7460d6d/compiler/pragmas.nim#L487-L493 with destination?
17:00:15*craigger quit (Ping timeout: 276 seconds)
17:01:11*craigger_ quit (Read error: Connection reset by peer)
17:04:58*craigger joined #nim
17:06:55Araqmratsim: yeah have a look at 'ui' where I used this
17:07:06Araqnarimiran: TSet? is that still a thing?
17:07:17FromGitter<mratsim> it seems to work on a toy example, trying with a more complex one
17:07:29*craigger_ joined #nim
17:09:33*craigger quit (Ping timeout: 250 seconds)
17:10:23narimiranAraq: "Warning: use HashSet instead; TSet is deprecated"
17:11:13narimiranthat's easy to change, but the worrying part is that assert on lline 94
17:11:49narimiranrunning the file raises error, `koch tests` doesn't mind at all
17:13:45Araqnarimiran: can reproduce too, very concerning
17:15:51Araqwell the test is wrong I think, question is what does testament does with this... just test it compiles?!
17:17:36narimiranOH SHIT!!!
17:17:56narimirani just made one assert completely wrong and it passed `koch test`
17:18:31narimiranchanging to `doAssert` doesn't help
17:18:41narimiranthis needs fix ASAP!!
17:20:56AraqTESTING tests/sets/tsets3.nim compile
17:21:05Araq^ testament only tested for "compile"
17:21:31Araqinvestigating but I doubt it comes up often, most tests have a 'discard' section
17:22:18Araqok, found it
17:22:49narimiranyeah, that discard section is necessary to raise wrong asserts
17:23:44AraqI fixed it but my fix causes new problems :P
17:23:56narimirannow some tests are failing? :D
17:25:47narimirani'll remove that wrong assert from that file (as it is included in my "part 5" PR), and will make sure that in the future test files have that discard block
17:27:57Araqyou do that, I'm rewriting the testament logic, it's bonkers
17:28:22Araqbut I'll push it to a branch for you to review :P
17:28:46narimiranhow the tables have turned :D
17:32:26*hoijui quit (Quit: Leaving)
17:39:32FromGitter<mratsim> @Araq the compiles with 2 inputs is buggy, it only works if the first one is a relative path.
17:41:16Araqwhy would you ever use an absolute path?
17:46:12FromGitter<mratsim> for wrappers I always use something like this: const csp = currentSourcePath.rsplit(DirSep, 1)[0]
17:46:41FromGitter<mratsim> it’s useful to passC the headers
17:48:35*malkomalko joined #nim
17:55:10*MyMind quit (Excess Flood)
17:55:45anamokIn the .nimble file I add `skipExt = @["nim"]` but the source file is also installed. I'm making a binary package.
17:56:16*MyMind joined #nim
18:01:37*vlad1777d__ quit (Ping timeout: 244 seconds)
18:04:34Araqterrible stuff, mratsim
18:06:26FromGitter<mratsim> pragmatic stuff
18:10:56*rnrwashere quit (Remote host closed the connection)
18:11:10*rnrwashere joined #nim
18:12:27*rnrwashere quit (Remote host closed the connection)
18:15:03*rnrwashere joined #nim
18:27:28*tefter quit (Remote host closed the connection)
18:30:15*rnrwashere quit ()
18:35:06*malkomalko quit (Quit: Lost terminal)
18:41:46*Trustable quit (Remote host closed the connection)
18:50:28*craigger joined #nim
18:50:28*craigger_ quit (Ping timeout: 245 seconds)
18:56:49*craigger_ joined #nim
18:57:36*craigger quit (Ping timeout: 260 seconds)
19:01:55*erratic quit (Quit: this server has gone to sleep)
19:06:21*craigger joined #nim
19:07:45*craigger_ quit (Ping timeout: 244 seconds)
19:10:54*shadwick joined #nim
19:11:12*craigger quit (Ping timeout: 252 seconds)
19:11:16shadwickHi all -- Is there a proc for creating a temp file ala `mktemp` in the stdlib?
19:11:24*craigger joined #nim
19:17:33*PMunch joined #nim
19:19:29elroodshadwick, there's ospaths.getTempDir, and you get access to posix.mkstemp, but no direct cross-platform convenience mktemp-like method yet
19:22:47*enthus1ast joined #nim
19:23:26enthus1astis there an build in alternative to this (store multiple bool values inside int): https://gist.github.com/enthus1ast/0993a76ec8e6c22d09bc0030eac6a159
19:24:16FromGitter<alehander42> i think you can store multiple bool values inside bool
19:24:32enthus1astmy goal is to store multiple values inside one byte
19:24:46enthus1astand in my application i would love to use an enum
19:24:51FromGitter<alehander42> so, the same thing, yeah
19:24:58shadwickelrood: Thanks. It mentions "Please do not use this" for getTempDir
19:25:15shadwickelrood: I just wanted to make sure I wasn't missing it in my search
19:25:23*craigger_ joined #nim
19:26:55*craigger quit (Ping timeout: 250 seconds)
19:28:45enthus1astalehander42 could you elaborate?
19:29:42FromGitter<alehander42> i was just kidding, because bool-s usually take 1 byte
19:42:58*craigger_ quit (Read error: Connection reset by peer)
19:43:08*anamok quit (Remote host closed the connection)
19:43:48*craigger joined #nim
19:46:50*Jesin quit (Quit: Leaving)
19:46:57*krux02 quit (Remote host closed the connection)
19:48:01*vlad1777d__ joined #nim
19:52:38*endragor joined #nim
19:57:01*endragor quit (Ping timeout: 246 seconds)
19:58:40*Jesin joined #nim
20:01:01*a_chou joined #nim
20:07:32*a_chou quit (Remote host closed the connection)
20:08:27*shadwick quit (Ping timeout: 256 seconds)
20:10:55*a_chou joined #nim
20:13:29FromGitter<mratsim> @enthus1ast use a builtin `set`
20:15:11FromGitter<mratsim> this takes 2 bytes: https://github.com/mratsim/glyph/blob/master/glyph/snes/datatypes.nim#L61 and stores 9 booleans
20:18:51*platoff quit (Read error: Connection reset by peer)
20:25:30*Vladar quit (Remote host closed the connection)
20:42:14*filcuc joined #nim
20:43:21filcuci've updated today to 0.19.0 and i didn't follow the nim development since 0.17.0..is the '-' char become illegal in nimble packages?
20:44:38*narimiran quit (Ping timeout: 245 seconds)
20:45:14PMunchfilcuc, in package names yes
20:45:20PMunchSame for module names
20:45:58*nsf quit (Quit: WeeChat 2.2)
20:46:43PMunchNot sure when or why it happened
20:47:11filcucnp
20:47:29filcucthanks
20:49:10*filcuc quit (Quit: Konversation terminated!)
20:49:40FromGitter<yyyc514> is there an apply or way to pass scope/binding around?
20:50:15PMunchyyyc514, not quite sure what you're trying to do. Do you have an example?
20:50:38FromGitter<yyyc514> have one function call another nad pass all the local variable state (for example)
20:51:15FromGitter<yyyc514> want a controller to setup a bunch of variables for a template without having to pass them all manually
20:52:23PMunchTemplates should be able to do that
20:53:05FromGitter<yyyc514> do you have an example?
20:55:15enthus1astthank you mratsim i will
20:56:33PMunchWell, this already works: http://ix.io/1pa3
20:57:22FromGitter<yyyc514> oh a template as a literal template
20:57:50FromGitter<yyyc514> i’m trying to use StdTmpl filter so my template is a proc
20:57:55FromGitter<yyyc514> not sure it could be a literal template
20:58:27Araqyou can use a 'template' in a 'templ' file too
20:59:18FromGitter<yyyc514> yeah playing with that now
20:59:41PMunchyyyc514, you can also define your proc within the proc to allow it to access the state of the outer proc
20:59:47PMunchIf that makes sense
21:01:27AraqI usually put my stuff in an 'object' and pass it around
21:01:41FromGitter<yyyc514> hmmmm
21:02:00PMunchYeah, that's of course the traditional way of doing it :P
21:02:06FromGitter<yyyc514> Araq: but then youd’ really have to define all the types of things upfront yes?
21:02:15PMunchYeah
21:02:27PMunchOr you could use some expandable data structure
21:02:33Araqyou have to do that anyway in a statically typed environment
21:02:34PMunchLike the JSON object type
21:02:51FromGitter<yyyc514> Araq: not if you let th ecompile and tempaltes do the work :)
21:03:02Araqwhich is also where the productivity benefits come from IME.
21:03:24Araqbecause you can then let the machine check your code
21:03:57Araqin fact, make me program in a dynamically typed environment one more time and I'll quit programming and sell potatoes instead
21:04:12FromGitter<yyyc514> lol wow
21:04:19FromGitter<yyyc514> must have had soem bad experiences :)
21:04:25PMunchHaha, let's try to not make that happen
21:05:05*a_chou quit (Quit: a_chou)
21:05:07FromGitter<timotheecour> @krux02 @araq @dom96 regarding wrong author metadata in @krux02 ’s PR, I just want to point out that I mentioned it in IRC as soon as I noticed the issue when the PR was merged, see https://github.com/nim-lang/Nim/pull/9356/commits/082612e7fbe59dfa0f25333f08e2685e88527356 , and that the PR I wrote clearly shows @krux02 as the author (see https://github.com/nim-lang/Nim/pu
21:05:07FromGitter... ll/9356/commits/082612e7fbe59dfa0f25333f08e2685e88527356) ; unfortunately when the PR got merged via rebase (instead of merge) it erased @krux02 ’s name ; I suggested a corrective action (push force ) which could’ve worked if done right away but now indeed it may be risky. As an alternative, @krux02 can do another PR that has 2 commits: 1: undo the c ... [https://gitter.im/nim-lang/Nim?at=5bc3af83c7bf7c3662104496]
21:06:54FromGitter<timotheecour> Furthermore, this will still allow a fast-forward merge and not have any negative effect of git force push.
21:09:42AraqI'll just add a comment instead ## The git history is lying (surprise, surprise) and this is all krux02's work.
21:11:04*amk joined #nim
21:12:23FromGitter<timotheecour> whatever you guys prefer ; maybe good to add a link to https://github.com/nim-lang/Nim/pull/5664 in the relevant nim file so all the useful discussion is linked
21:13:34AraqI'll migrate to Fossil instead.
21:14:52AraqNim v0.20 will only run on ReactOS and its source code stored in a Fossil repo.
21:17:27Araqhmm, "Our features -- 9 million lines of code and growing", how is that a feature?
21:26:40FromGitter<yyyc514> how to import without making everythign global again?
21:27:29*craigger_ joined #nim
21:27:35FromGitter<yawaramin> from mymodule import nil
21:27:49*craigger quit (Ping timeout: 250 seconds)
21:28:40FromGitter<yyyc514> how do you mix that with as syntax?
21:28:42*amk quit (Ping timeout: 252 seconds)
21:31:09*darithorn joined #nim
21:31:29FromGitter<yawaramin> from lists as list import nil
21:31:53FromGitter<yyyc514> ah i had it backwrds :) thanks
21:31:54*craigger_ quit (Ping timeout: 244 seconds)
21:32:13FromGitter<yawaramin> but it's really not ideal to do that. a lot of generic behaviour can depend on doing `import list` style
21:32:39*craigger joined #nim
21:32:54FromGitter<yawaramin> e.g., if you have a generic function that traverses an iterable using `myIterable.items`, then you need `import lists` in the calling module to make it work with lists
21:32:55FromGitter<yyyc514> ah
21:34:59*PMunch quit (Remote host closed the connection)
21:35:13*darithorn quit (Client Quit)
21:39:48*craigger quit (Ping timeout: 268 seconds)
21:45:41*rockcavera joined #nim
21:50:17FromGitter<mratsim> the method call syntax is the major pain I would say, but there is an RFC to auto-import all procs where the first param is an already imported type
21:50:55FromGitter<mratsim> this would force qualified imports for type but bring automatically related proc a bit similar to methods in OO lang
21:50:56FromGitter<yyyc514> can a macro figure out the type of a variable in it’s local scope?
21:51:27FromGitter<mratsim> Nim is statically typed, local variable type is always known
21:51:58FromGitter<yyyc514> but how would a macro get at that if all i had was the variables name?
21:52:29FromGitter<yyyc514> var s = “test”; something(“test”) # something should output “String"
21:52:40FromGitter<mratsim> it depends on how you call the macro: ⏎ ⏎ If it’s before the symbol resolution or not
21:53:03Araqnote that the AST after symbol resolution is finally getting fixed and spec'ed :-)
21:53:16FromGitter<mratsim> import typetraits; var s = “test”; echo s.type.name
21:53:30FromGitter<mratsim> no need for macro here
21:53:39FromGitter<yyyc514> i need the macro for other things :)
21:53:42FromGitter<mratsim> typetraits is only needed to convert a type to string
21:54:19FromGitter<mratsim> macro foo(x: typed): untyped = result = getType(s)
21:54:24FromGitter<yyyc514> that’s good to know though, hmmmm
21:54:46FromGitter<yyyc514> you mean getType(x) yes?
21:54:57FromGitter<mratsim> yes
21:55:13FromGitter<mratsim> @Araq so does that mean that this will be solved? https://github.com/nim-lang/Nim/issues/7719
21:55:26FromGitter<mratsim> that would be awesome!
21:57:38Araqer ... *cough* ... seems not a bug?
21:58:04AraqgetType() is hard and always will be hard because Nim's type system kinda sux
21:59:18FromGitter<mratsim> well, as long as it’s documented. Sometimes I feel like I’m in a labyrinth trying to find the exit.
21:59:29elroodrewrite? it's still pre-v1.0 ;P
21:59:57FromGitter<mratsim> and replacing the NimSym and NimIdent by fresh idents seemed like triggering a secret door.
21:59:59Araqmratsim: getTypeInst et al have extensive tests, we can use them as the spec for better or worse
22:01:24FromGitter<mratsim> What I’m afraid of, is basically people like me finding silly workaround and then those workarounds become (bad) examples of how you should use getTypeInst and friends
22:03:16FromGitter<yyyc514> fitler templates are a weird compiler thing right? will parseStmt handle them in macros?
22:04:08Araqmratsim: the problem is more likely that you construct types rather than inspect them
22:04:21Araqand type construction via macros is pretty much unsupported
22:04:44FromGitter<mratsim> ah well, now I know why I’m alone :P
22:08:42*Snircle joined #nim
22:09:08Araqwe would need to ensure you got the type graphs right, so... you construct an AST instead that describes the type
22:13:07FromGitter<timotheecour> @araq friendly ping on https://github.com/nim-lang/Nim/pull/8315 (isHidden); any concerns left?
22:15:58FromGitter<mratsim> This looks like an interesting generic parser for multi-language: https://thestrangeloop.com/2018/tree-sitter---a-new-parsing-system-for-programming-tools.html
22:16:16FromGitter<timotheecour> (as well as https://github.com/nim-lang/Nim/pull/8711 has been +1’d 5 times ...)
22:16:42FromGitter<yyyc514> is nim filter supposed to be “nimf” or is that an old thing?
22:16:45FromGitter<mratsim> pure C, no need for language server.
22:16:58FromGitter<mratsim> and no regexp
22:16:59FromGitter<yyyc514> trying to update the NimLime package
22:17:34FromGitter<timotheecour> (unless you want to wait for 19.2, for toSeq, I forgot)
22:17:58FromGitter<mratsim> another +1 ;)
22:18:13FromGitter<timotheecour> Thx:)
22:18:38Araqas I said 19.2 will be cherrypicking fun for somebody
22:19:25AraqI'm sure this will go well, what could possibly go wrong with somebody using lots of git commands manually
22:23:28FromGitter<timotheecour> [controversial statement follows...] I don’t think there’s enough manpower to maintain pre-1.0 LTR’s like 19.x, what could be feasible is to only (manually if necessay) cherry-pick security or other critical fixes for stuff like 19.x ; if user wants latest bug fixes, devel works at specified points (in between regressions) ; maybe after 1.0 this could be revisited
22:25:01Araqwell there is this async queue bug regression we need to address plus a handful more
22:25:36Araqand we need to do this at one point anyway, it's time we figure out how to do it
22:27:01Araqyour toSeq is complex, 3 variants plus I intend to add a 4th
22:27:15FromGitter<timotheecour> which one
22:27:28AraqtoSeq(for i in 1..10: i)
22:27:41Araqfor loops can be expressions in 0.19
22:27:50FromGitter<mratsim> 1) 19 or 0.20?
22:28:04Araqwe didn't announce that yet as nothing makes use of this feature
22:28:09FromGitter<mratsim> I wasn’t aware it was already added
22:28:18FromGitter<timotheecour> can `toSeq(for i in 1..10: i)` be added after #8711 ?
22:28:31FromGitter<mratsim> I was waiting for that for loopfusion: https://github.com/numforge/loop-fusion
22:28:57Araqsure you bet, but I wonder if I can fix/tweak Nim to make toSeq simpler
22:29:02FromGitter<mratsim> and to refactor arraymancer looping
22:29:18Araqit's pretty bad the language is so complex :-)
22:29:36Araqwe need more features to fight the complexity
22:29:43FromGitter<mratsim> lol
22:29:44Araq;-)
22:30:02FromGitter<mratsim> aka we need cait for it … concepts!
22:30:12Araq'cait' ?
22:30:13*craigger joined #nim
22:30:16FromGitter<mratsim> wait*
22:30:32Araqit's the coolest second first name
22:31:02FromGitter<timotheecour> > sure you bet, but I wonder if I can fix/tweak Nim to make toSeq simpler ⏎ ⏎ well this can be done after, with no breaking change to toSeq API (no idea how long `if I can fix/tweak Nim to make toSeq simpler` could take…)
22:31:32Araqyeah but then your PR can also wait, plenty of people used toSeq before
22:31:45FromGitter<mratsim> I’d like more OpenMP features or atleast an emit that doesn’t move line in release mode :P
22:32:24Araqalso... thinking about it... few use closure iterators directly, they are always produced by async
22:32:24FromGitter<mratsim> maybe I should bench Nim threadpool as well.
22:32:53Araqmaybe we can obscure closure iterators?
22:33:06FromGitter<timotheecour> what do u mean by that
22:33:31Araqasync uses them but they are officially not part of Nim
22:33:36FromGitter<mratsim> Some were asking about coroutines recently. I always told them, just use closure iterators.
22:34:26Araqwe can pretend async/await are builtin and don't mention closure iterators.
22:34:38FromGitter<mratsim> But don’t privatize closure iterator before inline iterator chaining is fixed: https://github.com/nim-lang/Nim/issues/4516
22:34:58FromGitter<timotheecour> well closure iterators are definitely in use (I use them too) , because of all limitations of inline iterators…. both are needed at the moment
22:35:17Araqand why would that be supported? it's an inline iterator, hardly more than a fancy template
22:35:19FromGitter<mratsim> you will break everyone’s “my functional library in Nim” which seem to be a super popular project when learning the language
22:35:43FromGitter<mratsim> @Araq, the manual says that’s inline iterator chaining is supported
22:35:47FromGitter<mratsim> that*
22:36:05Araqdoes it? I thought I removed that section
22:36:28FromGitter<timotheecour> regarding inline iterators, what would make them more bearable is allowing to abstract them as 1st class constructs, eg: ⏎ `iter foo = myInlineIter(32); for a in foo(): yield a`
22:36:29FromGitter<mratsim> but you didn’t remove the bug ;)
22:37:02FromGitter<timotheecour> where `iter` is another keyword along `const/var/let/`
22:37:09FromGitter<mratsim> anyway zero-functional shows that you have them be fast with a generic syntax.
22:38:10FromGitter<mratsim> as long as it’s clearer than Rust’s, I’m was always confused by their `iter` vs `into_iter`
22:38:21FromGitter<mratsim> I was* (sorry it’s late)
22:41:17FromGitter<mratsim> also inline iterator chaining would probably allow me to fuse loops with term-rewriting macro I think.
22:41:28Araqtimotheecour: an inline routine is by its nature not a first class construct
22:42:01dom96closure iterators aren't part of Nim officially? wtf?
22:42:08FromGitter<mratsim> async
22:42:26FromDiscord<Shield> closure iterators are definitely a nice feature that i'm using, why would you hide something neat
22:42:28FromGitter<timotheecour> what I meant is https://github.com/nim-lang/Nim/issues/9374
22:42:29FromGitter<mratsim> I guess, not part of the compiler
22:42:32Araqdom96, I'm merely thinking aloud
22:43:08Araqtrying to get us out of our messy situation wrt iterators
22:43:32Araqand as I said, async wouldn't be affected
22:44:08Araqbut whatever
22:46:12dom96huh
22:46:18dom96You've stated what appears to be a fact
22:46:49AraqI started with "maybe we can obscure closure iterators? "
22:46:59Araqand then I explained what that would mean
22:47:55dom96I see
22:49:02FromGitter<timotheecour> > an inline routine is by its nature not a first class construct ⏎ ⏎ at least please read the draft https://github.com/nim-lang/Nim/issues/9374 ( I closed the issue because it’s still a draft, I wrote it some time ago but hadn’t put it up yet)
22:52:26Araqdunno, every design that doesn't allow me to iterate over two collections in a pairwise fashion is not worth it IMO, it's just something that fails a tiny bit later
22:53:30Araqand this filterLazy(mapLazy(myiter(5), a*10), a<25) stuff is something a DSL can easily cover
22:53:36FromGitter<timotheecour> you can, with `next(it: iter)` and `finished(it: iter)`
22:54:26Araqever tried to do that? that's Nim's inline vs closure iterator problem. but yeah, you can turn an inline iterator into a closure iter automatically
22:56:16*endragor joined #nim
22:56:19Araqand it's probably quite easy to do that in the compiler but then people complained about the closure iterators interface and so we need to change that too etc yadda yadda
22:58:03Araqbut maybe it's as simple as "convert inline to closure, just like I can pass a .nimcall proc to a closure"
23:01:12*endragor quit (Ping timeout: 268 seconds)
23:01:49*smt` joined #nim
23:03:49FromGitter<timotheecour> the problem, obviously, is performance when converting inline to closure: see https://github.com/def-/nim-iterutils/commit/29ec94cbe8bce4956c5cae73f7a0302773d6f610 where benchmark shows > 10X difference
23:05:19*smt quit (Ping timeout: 250 seconds)
23:05:20FromGitter<timotheecour> and I think we can have a "best of both worlds” by allowing inline iterators usable in what would look more like 1st class citizens by which you can declare such iterators via `iter foo = myInlineIter`
23:09:41FromGitter<timotheecour> > filterLazy(mapLazy(myiter(5), a*10), a<25) stuff is something a DSL can easily cover ⏎ ⏎ by that I believe you mean something like https://github.com/zero-functional/zero-functional ; however (as issues 35 and 36 show), even with such DSL its usage and integration with code is problematic, causing the need for closure iterators ; if inline iterators would be more 1st class, this problem would go away.
23:12:32*elrood quit (Quit: Leaving)
23:22:41Araq"causing the need for closure iterators" so ... causing the need for the real first class thing that is slower?
23:23:29Araqit's always the same ... "here is A" -- "ah, but A is not perfect, we need Ab and that is objectively better"
23:23:55Araqdo that often enough and you end up with an objectively "good" language nobody wants to use
23:24:24*craigger_ joined #nim
23:24:38*craigger quit (Ping timeout: 245 seconds)
23:29:58FromGitter<timotheecour> I believe we can have 1st class inline iterators. For example: in D, ranges (front, empty, popFront) are 1st class, yet zero cost abstraction: you can compose them and get code that’s as efficient as manually written code. I actually implemented ranges in nim based something similar to (front,empty,popFront), and it indeeed worked as fast (but ran into large compile times when combining a lot of these nim
23:29:58FromGitter... ranges). It’s actually not super different from finished/next.
23:30:36Araqit's also completely full of ownership problems
23:33:05FromGitter<timotheecour> I’ll have to think about that, I didn’t recall it being a problem.
23:33:33Araqit's such a big problem that a whole new language was created (Rust)
23:36:07Araqbut if you're right then we don't need anything, use front, empty, popFront instead, hopefully with better names
23:37:07FromGitter<timotheecour> I’ll try to post my code and show the compile time issues I was running into (not runtime speed issues).