<< 17-07-2018 >>
00:11:28krux02skrylar: Vulkan has even less support on Apple than OpenGL.
00:27:58*BitPuffin quit (Remote host closed the connection)
00:36:37*donlzx joined #nim
00:55:27*cspar quit (Ping timeout: 244 seconds)
00:56:25*krux02 quit (Remote host closed the connection)
01:17:35*cspar joined #nim
01:24:17*mr_yogurt joined #nim
01:31:02*jamesroseman joined #nim
01:42:55*dddddd quit (Ping timeout: 256 seconds)
01:43:29*jamesroseman quit (Quit: Lost terminal)
01:47:14*donlzx quit (Remote host closed the connection)
01:47:50*dddddd joined #nim
02:31:35*dddddd quit (Remote host closed the connection)
03:04:28*endragor joined #nim
03:30:40benjikunYou can do inline procedures in Nim right?
03:39:57FromGitter<gogolxdong> ./koch tools got
03:40:02FromGitter<gogolxdong> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5b4d65124b583a74a720f8b1]
03:40:57FromGitter<gogolxdong> build nimble failed.
03:58:57*xylef quit (Ping timeout: 240 seconds)
04:07:08*drazan quit (Ping timeout: 244 seconds)
04:08:29*drazan joined #nim
04:30:27*nsf joined #nim
04:39:37*donlzx joined #nim
04:57:17*miran joined #nim
05:20:51*leorize quit (Ping timeout: 240 seconds)
05:56:03FromGitter<xmonader> @benjikun check this https://xmonader.github.io/nimdays/day4_asynclinkschecker.html#cid10 writing links checker using httpclient
06:06:00FromGitter<mratsim> @benjikun `proc foo(x: int): int {.inline.} = …`
06:07:52*miran quit (Ping timeout: 265 seconds)
06:09:51*xylef joined #nim
06:17:42FromGitter<data-man> https://encode.ru/threads/2980-C-Lua-and-Nim
06:28:33*jjido joined #nim
06:33:43*Shivelight joined #nim
06:35:46CodeVanceyou can't expect to use vulkan if you want to have anysort of backwards compatibility
06:36:07CodeVanceI'm busy "trying" to make a backwards compatible rendering lib
06:37:38FromGitter<CodeDoes> @gogolxdong Check out travis before attempting to build from source. Make sure you only build on green commits. if your on a red commit then reset to a green commit and try again. https://travis-ci.org/nim-lang/Nim/builds
06:38:27*xylef quit (Ping timeout: 268 seconds)
07:02:08*donlzx quit (Remote host closed the connection)
07:14:10*jjido quit (Ping timeout: 244 seconds)
07:24:35*Vladar joined #nim
07:24:58*PMunch joined #nim
07:26:24*jjido joined #nim
07:31:10*jjido quit (Read error: Connection reset by peer)
07:38:42*jjido joined #nim
07:42:57*jjido quit (Ping timeout: 240 seconds)
08:21:00FromGitter<Varriount> dom95, araq: Have you read this article on the new Pipes API in C#? It looks interesting: https://blog.marcgravell.com/2018/07/pipe-dreams-part-1.html?m=1
08:22:41*krux02 joined #nim
08:33:03*xylef joined #nim
08:37:50*xylef quit (Quit: WeeChat 2.2)
08:40:59*xylef joined #nim
08:44:35*dddddd joined #nim
08:45:29FromGitter<Yardanico> We're currently talking about pragma syntax in russian telegram group, and here's the question - as far as I know we can't have same annotations like Python because it would break backwards compatibility?
08:50:32FromGitter<Yardanico> and another suggestion: make it possible to place pragmas before procedures like ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5b4dadd83187ca3ee8b9ebdb]
08:59:31PMunchVarriount, pipelines look interesting
09:00:02Araqvardanico: yeah .. not gonna happen. we don't need more ways to write the same
09:00:56PMunchI really like the way they expose their buffer to you, and you tell it how much you put in/took out.
09:01:02Araqjust get more professional, use the existing syntax and accept that every syntax feels natural after a while.
09:07:06*donlzx joined #nim
09:09:06FromGitter<mratsim> @Yardanico are you talking about decorators?
09:09:10FromGitter<Yardanico> @mratsim yes
09:11:02FromGitter<mratsim> you can do : ⏎ ⏎ ```{.push: foo.} ⏎ proc bar() = … ⏎ {.pop.}``` ⏎ ⏎ So you will have parsing ambiguities to solve [https://gitter.im/nim-lang/Nim?at=5b4db2a679f7236acb301137]
09:11:28FromGitter<mratsim> does the pragma apply to the proc below or is it a global one
09:12:33zacharycarterCan you curry arrow functions in Nim like in JS?
09:12:44zacharycarterI want to do like
09:13:42krux02i don't think Nim has currying, but I am pretty sure you can make it a macro
09:13:46FromGitter<mratsim> I’m pretty sure I found some gist with curry macro from Araq and def-
09:14:42FromGitter<Yardanico> yeah I did too
09:14:57*zacharycarter sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/fvZnBqLCtobQQcCEbLwdAmIR >
09:14:57zacharycarteror something like that
09:15:00FromGitter<Yardanico> https://gist.github.com/fowlmouth/9b9010397ad5fe4b9872
09:15:05FromGitter<Yardanico> found this
09:15:37zacharycarternot sure what I'm doing makes sense either
09:19:18zacharycarterhrm
09:19:30zacharycarterokay thanks
09:19:45FromGitter<mratsim> https://github.com/Araq/metapar/blob/master/livedemo/curry.nim
09:20:12zacharycarterawesome thank you
09:21:40FromGitter<mratsim> def curry is unfinished though: https://github.com/def-/nim-unsorted/blob/master/curry.nim
09:43:13*Shivelight quit (Quit: Connection closed for inactivity)
09:56:24FromGitter<Vindaar> is there some way to improve the error message in case a module using `Channels` is compiled without `--threads:on`?
09:57:35FromGitter<Vindaar> The error is simply `undeclared identifier: Channels`. It makes sense if one knows what's going on, but for someone who doesn't know the details about a module, it's not evident that the issue is simply the missing thread support :/
09:58:19FromGitter<Vindaar> (ok, I guess as a maintainer of a package using `Channels` I'm responsible for making sure the user is compiling with thread support)
09:58:55AraqVindaar: --threads:on should simply be the new default. it's 2018 already
09:59:14FromGitter<Vindaar> hehe, glad you agree with me :)
10:08:09zacharycarterfound - https://github.com/t8m8/currying -
10:12:01FromGitter<narimiran> zacharycarter: currying looks nice
10:17:59krux02Araq: what is the gain to have threads disabled?
10:19:11*Shivelight joined #nim
10:19:49*xet7 joined #nim
10:20:50krux02(I mean of cource, when you don't need them in the first place)
10:28:28FromGitter<gogolxdong> How to use [n.sourcefile]?
10:28:35FromGitter<gogolxdong> of nimgen?
10:30:50*PMunch quit (Remote host closed the connection)
10:49:30*BitPuffin joined #nim
10:50:22*krux02 quit (Remote host closed the connection)
10:52:45FromGitter<Varriount> @Yardanico You could. Theoretically the `[..]` syntax could use that.
10:53:19*stefanos82 joined #nim
10:53:28FromGitter<Varriount> That is, pragma lists using square brackets cold indicate the following procedure.
10:53:32*PMunch joined #nim
11:21:37*jjido joined #nim
11:26:38*xylef quit (Quit: WeeChat 2.2)
11:32:16stefanos82which C compilers Nim supports by default?
11:33:41PMunchI think at least GCC, Clang, and VCC should work. But there's probably more
11:34:25stefanos82I have tried to use afl-gcc so I can fuzz the generated C code and threw an error message
11:35:56PMunchWhat kind of error?
11:36:38stefanos82nim.cfg(1, 1) Error: unknown C compiler: 'afl-gcc'
11:39:14def-use gcc but set the binary path to afl-gcc
11:40:22def-nim --cc:gcc --gcc.exe:afl-gcc --gccc.linkerexe:afl-gcc c myfile
11:40:33stefanos82ah cool
11:40:37*donlzx quit (Remote host closed the connection)
11:40:46stefanos82I will set this inside my nim.cfg and test it right away
11:41:26*ng0 joined #nim
11:41:43def-for your original querstion, list of compilers: https://github.com/nim-lang/Nim/blob/devel/compiler/extccomp.nim#L61
11:42:29dom96Basically all of them :D
11:42:52stefanos82the question is def- and dom96: why -O3 and not -02?
11:43:26def-more optimizations = better, you can change the default for your projects of course
11:44:30stefanos82that's not the case with -03. It more than often produces problematic executables that actually crash
11:44:43stefanos82not always, but happens quite often I'm afraid
11:44:45*donlzx joined #nim
11:44:50stefanos82with -02 you don't have this issue
11:45:00def-why do they crash?
11:46:02def-Looking at -O3 here the additional optimizations of -O3 don't sound bad: https://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Optimize-Options.html
11:46:56stefanos82def-: it has something to do with vectorization that -03 enables by default
11:51:55stefanos82btw def-, your afl-gcc were almost correct; in place of --gcc.exe:afl-gcc should have been --cc.exe:"afl-gcc"
11:53:12def-oops
11:53:35def-they changed that then
11:54:07*donlzx quit (Remote host closed the connection)
11:55:33def-That reminds me that I have a WIP article about "Fuzzing Nim with AFL" from > 2 years ago that I never finished
11:56:45*cspar_ joined #nim
11:59:02stefanos82do it mate, I need to read it!
11:59:12stefanos82I want to fuzz my generated code
11:59:17def-nono, didn't have good ideas for it
11:59:27*cspar quit (Ping timeout: 240 seconds)
11:59:30stefanos82just a demo so we can get a rough idea
11:59:32def-but generally it should be quite easy, just like fuzzing C
11:59:35stefanos82nothing sophisticated
12:00:01def-so you can just follow the normal instructions for AFL, except for the nim compile command
12:01:32*krux02 joined #nim
12:03:20*xylef joined #nim
12:06:36federico3def-: there's https://github.com/nim-lang/Nim/wiki/Fuzzing-your-nim-code-to-rabbit-out-all-the-hard-bugs
12:06:53def-hah, also says gcc.exe there!
12:08:41stefanos82lol this will drive me crazy
12:08:53stefanos82why it didn't work on my version, I have no idea
12:10:30stefanos82I honestly didn't know Nim wiki pages have a page dedicated to AFL
12:10:34stefanos82that's so cool!
12:12:05federico3we really need to do something about the wiki visibility
12:14:50*fvs` left #nim ("ERC (IRC client for Emacs 26.1)")
12:16:00stefanos82I suppose we need a better wiki (?)
12:16:11stefanos82I find sphinx docs quite convenient
12:16:51federico3you mean http://www.sphinx-doc.org ?
12:16:54stefanos82the "previous | next | modules | index" navigation is very nice to use while reading an article
12:16:55stefanos82yep
12:17:05stefanos82right before I pressed enter you suggested it lol
12:17:18federico3it's better than nim doc but it's not a wiki
12:18:27stefanos82true :/
12:19:09stefanos82moinmoin is a nice wiki, but it's implemented in Python
12:19:15stefanos82I don't know how the team would feel about it
12:20:22federico3NIH syndrome strikes again
12:25:25Araqthe NIH syndrome is a prerequisite for developing something new.
12:31:18stefanos82what's NIH syndrome?
12:31:40def-https://en.wikipedia.org/wiki/Not_invented_here
12:32:21stefanos82btw federico3, I have tested the sample code from the link you shared and it crashes immediately on my version; it does not produce the output as displayed in Testcases
12:34:29*Perkol joined #nim
12:34:49PerkolAnyone know how to convert seq[uint8] to string?
12:35:23FromGitter<Varriount> Perkol: What's the encoding?
12:36:51dom96Let's implement a Nim wiki :D
12:37:06FromGitter<Varriount> If you want a straight conversion, you can just look through the sequence and convert+add the bytes to the string.
12:37:33stefanos82dom96: even better; why not implement a static website generator in Nim?
12:37:33FromGitter<Varriount> dom96: As long as I can read it on a dailup connection.
12:37:49dom96stefanos82: Because I've already implemented one :P
12:37:58stefanos82which is...?
12:38:01stefanos82I haven't seen it
12:38:04federico3Varriount: I wish! :(
12:38:06dom96https://github.com/dom96/ipsumgenera
12:38:20dom96Desperately needs maintenance
12:39:04PerkolVarriount: raw bytes from binary file
12:39:05stefanos82I guess its name it's not catchy so it can convince people it's not an actual dummy demo
12:39:28PMunch!eval var s = @[72'u8, 101, 108, 108, 111]; echo cast[string](s)
12:39:31NimBotHello
12:39:37PMunchPerkol ^
12:39:45PMunchDon't think that is recommended though :P
12:39:53PMunchBut they do share the same memory layout
12:44:02Araqthe GC also knows this needs to work.
12:44:21Araqand the new seq implementation also supports it.
12:46:09PMunchExplicitly? Or is it just a quirk?
12:47:01AraqI am not sure this is documented.
12:47:24Araqbut it's supposed to work and as I said, the new impl also consciously allows it
12:47:45PMunchOh cool
12:51:53FromGitter<mratsim> @Perkol, ideally you should use seq\[byte\] instead of string for raw bytes
12:53:27FromGitter<mratsim> @dom96 I think a cookbook that you can update with Github PR is better suited to Nim. ⏎ ⏎ This avoids having to deal with authentication, spammers, and the result is completely static
12:55:46stefanos82I think Nim got a lot smarter than I thought it could become lol https://pastebin.com/BsMJWHxy
12:55:52stefanos82this is the code from https://github.com/nim-lang/Nim/wiki/Fuzzing-your-nim-code-to-rabbit-out-all-the-hard-bugs
12:56:28*cspar_ quit (Ping timeout: 268 seconds)
12:59:00Araqwe had a cookbook, not sure what happened to it
12:59:16stefanos82it got overcooked lol!
13:00:08*endragor quit (Remote host closed the connection)
13:01:50*Perkol quit (Remote host closed the connection)
13:02:41*nsf quit (Quit: WeeChat 2.1)
13:05:11zacharycarterIs it possible to add values to an existing enumeration via a macro?
13:08:28Araqno, enums are sealed.
13:09:16zacharycartergotcha - thank you
13:23:47PMunchWhy is it that a macro something get an ident and sometimes a sym?
13:24:33PMunchI have a library that needs to get "included" and not "imported", but a macro I was using messed up because it was expecting an ident by got a sym
13:25:53FromGitter<kaushalmodi> Hey, I have a Nim cookbook too, just that it's written in Org as it allows quick reevaluation of all the code snippets. It's open to additions and corrections.
13:31:40Araqwe have the :test: annotation for that
13:34:16*cspar_ joined #nim
13:35:31FromGitter<kaushalmodi> Araq: I find it easier to have echoes with type names to better introspect the Nim basics. I have seen runnableExamples but I have seen only asserts in those. Can "nim doc" append the stdout content after each code block (like I do in my notes)?
13:36:04FromGitter<kaushalmodi> I am not aware of :test: annotation.
13:36:10Araqno, I don't understand why this is desirable
13:36:49Araqthe point it to ensure the examples work as they are. if you generate the program's output, you need to inspect the output manually. all the time.
13:38:48FromGitter<kaushalmodi> I just git diff ;)
13:53:49*cspar_ quit (Ping timeout: 260 seconds)
13:57:26*DarkArctic_ joined #nim
13:58:53*Shivelight quit (Quit: Connection closed for inactivity)
14:01:18*DarkArctic quit (Ping timeout: 244 seconds)
14:05:53*DarkArctic_ quit (Quit: Leaving)
14:11:21Araqah
14:11:25Araqecho (1..2).type.name
14:11:25Araqecho type(1..2).name
14:11:29Araqis not a bug :P
14:11:44Araqit's a feature.
14:17:30*PMunch quit (Quit: Leaving)
14:25:34FromGitter<kaushalmodi> hmm.. when would you use one vs another
14:26:05FromGitter<kaushalmodi> or rather what would be the style of type.name one should use so that it behaves as expected
14:26:34FromGitter<kaushalmodi> So far `$type(foo)` seems to be a "bulletproof" way
14:28:48FromGitter<kaushalmodi> Araq: Talking about typetraits, I end up in this bug very often: https://github.com/nim-lang/Nim/issues/7976
14:29:36Araq'type' prefers the "iterator" interpretation (documented behaviour) but when you use the dot syntax, the type checking doesn't consider iterators (somewhat documented behaviour) and so x.type is different from type(x) and can be used to disambiguate procs from iterators
14:30:18AraqI agree it's terrible though :P
14:30:58Araqand we need something like type(x, preferIterators)
14:31:42Araqdid I mention that I think iterators are bad and should have been implemented via macros...?
14:32:24FromGitter<kaushalmodi> About "type(x, preferIterators)", are iterators that special that they deserve that special parameter?
14:32:42Araqyes. it's crucial for 'sequtils' to work.
14:39:51*drazan quit (Remote host closed the connection)
14:40:03FromGitter<Vindaar> is it a known bug that the `=~` template from `re.nim` doesn't seem to work in generic procs?
14:40:17FromGitter<GULPF> imo allowing iterators to share their signature with a proc was a misstake
14:41:34FromGitter<kaushalmodi> I don't understand those low level details, but making a change is the Right Thing, and even if it's breaking, it should be done. ⏎ Such changes are better done sooner than later.
14:41:51*drazan joined #nim
14:43:21AraqGULPF: hmm that might be an easy way out
14:44:27Araqit's easy enough to use toSeq to get a materialization
14:44:42Araqand so the proc variants are not required
14:57:05*miran joined #nim
14:57:34FromGitter<GULPF> `..` is tricky though, but maybe it's worth changing it anyway. Iterators are way to convoluted right now so nobody understands how they work (I don't understand them either)
15:01:55AraqI do understand how they work, but I also understand I don't count. :-)
15:02:47CodeVanceiterators are simple
15:02:55CodeVancewhats complicated about them?
15:03:01CodeVancethey are a bit limited though
15:03:12Araqiterator items(x: Slice[T]): T works for consistency already
15:03:14Araqso that
15:03:17Araqlet x = 1..3
15:03:26Araqfor a in x # works
15:03:35Araqfor a in 1..3 # works.
15:04:23*floppydh joined #nim
15:04:26AraqCodeVance: they come in two variants, .closure and .inline and .inline iterators can only be used in 'for' loops
15:04:45Araqand so can be overloaded with procs which cannot be used in 'for' loops
15:05:05FromGitter<GULPF> @CodeDoes https://forum.nim-lang.org/t/3465
15:05:13FromGitter<GULPF> sorry, @CodeVance
15:06:03CodeVanceSame person
15:06:16FromGitter<GULPF> oh, good :P
15:09:08CodeVanceiterators aren't complicated
15:09:35CodeVanceAnd they are just special little procs
15:11:14Araqconceptually they are closer to macros than to procs
15:12:56CodeVanceYeah they aren't really procs. I know that
15:13:59CodeVanceMaybe there should be a next macro?
15:14:23CodeVanceI don't really know what I'd expect to happen from var x = iter()
15:14:45CodeVanceIn other langs you get an "iterator" object.
15:17:35Araqand this iterator object's size depends on the concrete iterator, so you need to use type erasure/closures/inheritance and
15:17:47Araqthe basic iteration primitive depends on a heap allocation.
15:18:29Araqnot to mention its ownership problems.
15:18:51Araqthis stuff is hard. :-)
15:19:08*benjikun2 joined #nim
15:19:33FromGitter<GULPF> CodeVance: iterators has tons of weird features like changing arguments while iterating, while simultaneously making more common use cases hard
15:20:11FromGitter<GULPF> https://gist.github.com/GULPF/72fb92717d83f194c3c8c835d72051a3
15:20:58CodeVancewhat about a pointer? besides plain iterators are fine. you dont need fancy iterators . ive yet to see usecase for fancy iterators
15:21:05*benjikun quit (Ping timeout: 248 seconds)
15:21:26Araqer.. all of async is built on top of the "fancy" iterators.
15:21:49CodeVanceno those are plain
15:21:56CodeVanceyou can't send a variable back
15:22:19AraqI think we disagree on what "fancy" means
15:23:12CodeVanceWell I can't see how much simpler iterators can get
15:23:27miran...and here's the author of that "strange iterators" thread :)
15:23:34CodeVanceSo if you assign an iterator to a variable without calling it you create an iterator object. thing.
15:24:10CodeVanceIf you call the iterator it's like a `next(iter, param)`
15:24:22CodeVanceWhich I didn't know was possible
15:24:27CodeVanceso its fancy
15:25:30CodeVancemaybe its because its a closure And I don't really understand it
15:26:42Araqwell I had my reasons of why they are the way they are.
15:27:42miranif you (plural) look at the linked issue (https://github.com/nim-lang/Nim/issues/7047), it seems that lots of people would like to see iterators change
15:28:09CodeVanceIts not bad. but I never knew they work that way. I don't really understand how they work either
15:28:28Araqand it's easy to propose a solution that misses the details. but I agree they are subtle.
15:28:44CodeVanceI just want to understand them
15:29:16Araqfor example, the fact that you have to *repeat* the arguments solves the problem of not having to copy the arguments into the hidden iterator object
15:29:42*CodeVance sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/CAJtpEcgmwECjweFxTFvkMNT >
15:31:09AraqCodeVance: an iterator yield default(T) after exhaustion
15:31:21CodeVance```nim
15:31:33Araqnot much to understand here, use 'finished' to see if it has finished
15:32:36CodeVancehmm. Is this the most efficient way it can be done?
15:32:44CodeVanceI expected an exception or something
15:33:22Araqyes, it's quite optimal
15:33:58miranwhy are (closure) iterators noticeably slow? can something be done about that?
15:34:50Araqwhat does 'slow' mean for you.
15:35:19miranmuch slower than a variant of code which uses a proc instead of that iterator
15:36:30Araqand what does "much slower" mean?
15:36:59miran~2x
15:37:27miran(or in the headline style: 200%)
15:38:11*CodeVance sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/GqXjzcvalNAigOmRWAvizwpH >
15:40:09FromGitter<Varriount> miran: what are you comparing the closures against? Regular function calls, or iterators?
15:40:22miranregular functions
15:40:52Araqfactor of 2 is ok, locals are lifted to the heap etc
15:42:01*nsf joined #nim
15:46:40CodeVancenvm if I add closure pragma my code works
15:54:05FromGitter<tim-st> can I call non closure iterator with next?
15:54:56*endragor joined #nim
15:56:30Araqno.
16:04:08jjidoAraq: does the nim iterator need the params of the function that created the iterator at each iteration?
16:04:56*endragor quit (Remote host closed the connection)
16:07:58Araqyes!
16:08:20Araqbecause otherwise it would need to copy or move the arguments into the hidden iteration object
16:09:02Araqor create memory unsafe dangling pointers.
16:09:34jjidoSo the function frame is not kept around
16:09:45Araqnow that we're getting fleshed out move semantics, maybe we can do better. but if you read my blog, "reification" is tough.
16:10:12jjidoDangling pointers can be cleared of when you exit the scope
16:10:29Araqsure.
16:10:38Araqwe can also prevent the iterator object from escaping.
16:11:05Araqbut given the constraints, the current solution is quite creative.
16:16:02jjidoI would use a closure (or more precisely a continuation) to avoid repeated parameters. It removes the flexibility of doing really cool things like changing the parameters for next iteration but...
16:17:49Araqit never was about that "flexibility"
16:19:40Araqit was about speed and memory safety.
16:25:31*jjido quit (Read error: Connection reset by peer)
16:28:08FromGitter<mratsim> you can create a next() template for inline iterators
16:29:11FromGitter<mratsim> This is what I use in Arraymancer: https://github.com/mratsim/Arraymancer/blob/master/src/tensor/private/p_accessors.nim#L116-L125
16:41:07*cryptocat1094 joined #nim
16:43:44*jjido joined #nim
16:45:14dom96Shouldn't this be working? https://gist.github.com/dom96/8d74217810f687f689da06005c961525
16:45:30dom96Note the difference between the tuple field names
16:45:43dom96But tuples with different field names should be compatible
16:48:26*leorize joined #nim
16:50:27*jjido quit (Ping timeout: 240 seconds)
16:51:43*zacharycarter sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/AIfjkPLVKLhPjamjZurlMqQT >
16:52:00*zacharycarter sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/yjsZPSMCyANSBhJGDDuJMeKO >
16:52:40*Trustable joined #nim
16:52:54*jjido joined #nim
16:53:37Yardanicozacharycarter, ActionKinds enum should be explicitly converted to int
16:53:54Yardanicotry with `int(ActionKinds.CountUp)` instead of `ActionKinds.CountUp`
16:54:33FromGitter<kayabaNerve> dom96 Isn't that the whole point of tuples? Lol.
16:54:54FromGitter<kayabaNerve> If it had that level of enforcement it would just be an object...
16:54:57dom96indeed, seems like a bug
16:55:01dom96Araq: Is it a bug?
16:55:06FromGitter<kayabaNerve> The point is names are optional and they focus is the value.
16:55:08zacharycarterI don't think that's it
16:55:13zacharycarterbecause I can replace ActionKinds.CountUp with 0
16:55:13zacharycarterand I still get that error
16:55:24FromGitter<kayabaNerve> dom96 agreed with me; I published a Nimble package; life is complete
17:00:21FromGitter<kaushalmodi> dom96: Looks like two named tuples need to have the same field names in same order to be equal ⏎ https://scripter.co/notes/nim/#tuple-type-equality
17:00:53FromGitter<kaushalmodi> Though, you need just the field type and order to be equal if comparing named and **unnamed* tuples
17:03:44dom96kaushalmodi: oh :'(
17:04:01dom96That's definitely surprising behaviour
17:04:59FromGitter<tim-st> I think it's ok, because tuples can be indexed by int and that could five different type
17:05:08FromGitter<tim-st> *give
17:06:11FromGitter<tim-st> surprising is that tuples with same contents in different order dont always have same size (imo)
17:06:28FromGitter<kayabaNerve> I think all Tuples should be compared as unnamed IF that padding bug is irrelevant or fixed
17:06:54FromGitter<tim-st> padding bug?
17:07:08FromGitter<kayabaNerve> Different sizes for different orders?
17:07:42FromGitter<tim-st> that's a "feature" with negative benefits, no one could explain me why they can have different sizes
17:07:43FromGitter<kayabaNerve> Subclause 6.7.2.1 of the C Standard states, "There may be unnamed padding within a structure object, but not at its beginning" [ISO/IEC 9899:2011].
17:08:04FromGitter<kayabaNerve> My comment on it being a bug was more on Nim's end
17:08:19FromGitter<tim-st> I mean I understand why they have different sizes, but now why it's not normalized
17:08:23FromGitter<tim-st> *not
17:08:26FromGitter<kayabaNerve> It's a side effect from C compiling, not a bug, and considered a negative feature in C.
17:09:05FromGitter<kayabaNerve> This actually shouldn't matter for tuples
17:09:11FromGitter<kayabaNerve> Because the order must be the same
17:09:13FromGitter<kayabaNerve> NVM.
17:09:19FromGitter<tim-st> c can handle it with pack pragma, but they cant find out when it's appropriate to do the optimization and when not
17:09:31dom96Awwh yeah. From 34k req/s to 260k req/s after my Jester optimisations. :D
17:09:37FromGitter<kayabaNerve> dom96: So should we base Tuple type/value equality on them as if they're unnamed?
17:09:48FromGitter<kayabaNerve> Also, congrats. How's middleware?
17:10:18dom96Basic middleware support should be there now
17:10:26FromGitter<kayabaNerve> Have a guide? :P
17:10:28FromGitter<kayabaNerve> Or example?
17:11:56dom96Just create a `proc match(request: Request): ResponseData` and then use `register` on your Jester instance to add it as a matcher.
17:12:05FromGitter<kayabaNerve> Got it. Thanks
17:12:29dom96It's very preliminary so let me know what else is needed for proper middleware support :)
17:12:48FromGitter<kayabaNerve> I'll look into it ;)
17:12:51FromGitter<kaushalmodi> dom96: Why not export the tuple type from the module you are importing and use that type instead?
17:13:19dom96kaushalmodi: because that would require modifying the stdlib
17:14:42FromGitter<kaushalmodi> hmm, in that case you just need to manually ensure that the field names/order/type are the exact same.. ⏎ .. or don't make that temporary tuple a named tuple
17:14:53FromGitter<kayabaNerve> So why not fix the compiler?
17:14:57FromGitter<kaushalmodi> make it anonymous.. then you need to match only the type and order
17:15:03FromGitter<kaushalmodi> .. of fields
17:15:05FromGitter<kayabaNerve> Or create an unnamed tuple from the named tuple when you're done with itr
17:15:31FromGitter<kaushalmodi> @kayabaNerve What's there to fix in the compiler?
17:16:03FromGitter<kaushalmodi> I think it makes sense to not count two tuple types as equals if someone made sure to give their fields different names
17:17:32FromGitter<kaushalmodi> It's even documented: https://nim-lang.org/docs/manual.html#types-tuples-and-object-types
17:17:42FromGitter<kaushalmodi> > Different tuple-types are equivalent if they specify the same fields of the same type in the same order. The names of the fields also have to be identical.
17:19:45*arecacea1 quit (Remote host closed the connection)
17:20:37*arecacea1 joined #nim
17:24:14*zacharycarter sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/tqXnwnLTDrMVVrTSwXwPZShA >
17:24:15zacharycarter:/
17:28:04FromGitter<kayabaNerve> @kaushalmodi That's not tuple behavior. It's type behavior.
17:28:20FromGitter<kayabaNerve> zarcharycarter: We can't read that without clicking a link lol
17:28:27FromGitter<kayabaNerve> **\* zacharycarter** sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/tqXnwnLTDrMVVrTSwXwPZShA >
17:28:47FromGitter<kayabaNerve> It seems so annoying 0_o
17:28:51zacharycarterweird
17:29:10FromGitter<kayabaNerve> @kaushalmodi If I wanted a tuple to care about that, I'd declare an object using type
17:29:28zacharycarterI'm on Riot - it's just a link to a triple quoted string
17:29:30zacharycarternot sure why it's doing that 😕
17:29:42dom96These error are indeed annoying.
17:29:48dom96Mark your proc type with {.nimcall.}
17:30:02dom96Then it compiles
17:30:03FromGitter<kayabaNerve> There's a reason it isn't type. Names are both optional and solely for the coder's ease. The backend should see all tuples as anonymous and solely see .name as [0] or [1] or whatever
17:30:10miran@kayabaNerve we on IRC must click a link even when somebody posts on gitter ;)
17:30:29miranbut that is better than pasting the code directly as multiple messages ;)
17:30:50zacharycarterthank you dom96!
17:31:05FromGitter<mratsim> Yeah I thought tuple used structural typing
17:31:08FromGitter<kayabaNerve> miran: Oh gosh that's annoying as hell I'm scarred and sad
17:31:28zacharycarternever would have figured that out
17:31:46FromGitter<mratsim> at least default name for fields (field0, field1, fieldXXX) should match any tuple with the same type
17:32:36FromGitter<kayabaNerve> Yep. That's why they exist. Else, named tuples are just objects with anonymous constructors.
17:32:46FromGitter<kayabaNerve> *potentially anonymous.
17:34:54dom96miran: If only our IRC clients were smart enough to open such links and embed their message in the chat
17:34:59dom96That sure would be nice and modern
17:35:26FromGitter<kayabaNerve> dom96: Write a client in Nim
17:35:33FromGitter<kayabaNerve> Have it do that
17:36:56dom96Would love to
17:38:47*fvs joined #nim
17:39:27*Widdershins quit (Ping timeout: 256 seconds)
17:41:29*Widdershins joined #nim
17:44:47*Trustable quit (Remote host closed the connection)
17:48:16Calinouhi, is it possible to have an optional/nullable property in a type?
17:48:36CalinouI have a Color type which may store either a lightness or a value, but I will never need both of them at the same time
17:48:43Calinou(HSL/HSV color systems)
17:48:52FromGitter<mratsim> you can use an object variant
17:50:18FromGitter<mratsim> typy ColorKind = ckLightness, ckValue; type Color = object; case kind: ColorKind; of ckLightness: lightness: int; of ckValue: value: int
17:50:37Calinouoh, this is pretty interesting
17:51:20FromGitter<mratsim> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5b4e2c973187ca3ee8bb7e54]
17:52:10FromGitter<mratsim> sorry type ColorKind = enum; ckLightness, ckValue
17:52:22FromGitter<mratsim> the gist/gitter should be correct
17:52:23Araqdom96: no, it's not a bug.
17:52:38Araqand the language used to work like you all want it to, and it sucked.
17:53:20dom96When was this?
17:53:22dom96and why did it suck?
17:53:32Araqdunno, pre 0.14, maybe
17:54:01Araqit sucked because in generics the T then sometimes has the field names a, b or x, y, for example
17:54:15Araqsuper hard to solve this consistently.
17:54:27Araqif you want nameless tuples, don't use names.
18:02:46FromGitter<mratsim> there is no issue for parameter passing though right? `proc foo(x: tuple[a, b: int]) = …`
18:04:34miranit is
18:04:49mirantype mismatch
18:05:29mirannameless tuples can be passed, named cannot
18:05:40CalinouI like how there's a userstyle for dark Nim docs :D
18:21:23*jjido quit (Ping timeout: 256 seconds)
18:25:10*Trustable joined #nim
18:25:33dom96So here is a problem
18:25:46dom96How do I enable logging in threads created by another library?
18:26:02dom96Is the only solution really just "Do it in the library itself?"
18:27:18Araqlibraries should not create threads
18:29:56dom96Why not?
18:30:58FromGitter<kayabaNerve> Araq: What if it's pthreads?
18:31:11FromGitter<kayabaNerve> 🤔
18:32:12FromGitter<kayabaNerve> Actual statement though. What if's a multi precision/cryptography library parallelizes whenever effective?
18:32:21FromGitter<kayabaNerve> *multi precision number
18:33:07FromGitter<kayabaNerve> Some of the math elliptic curves do is crazy. I don't believe any of it is able to be done in parallel, yet I think AES can be...
18:55:08Araqdom96: because they dictate --threads:on then
18:55:20Araqand not every system has threads.
18:55:38dom96What if the library only creates threads when --threads:on is specified?
18:55:39Araqit's better to allow the upper layers to do the thread plumbing
18:59:17Araqbut anyway, don't we have an enableLogger() you can call in the thread?
19:05:11dom96yes, but then I have to do that in my library
19:05:19dom96What if the user wants to change the log level?
19:07:51*chopzwei joined #nim
19:16:16federico3dom96: that's why some logging libraries have a logger tree. It nests loggers from any library in use an the application at the root can access it and configure log levels & so on
19:24:25Araqdom96: meh, logging should just be made threadsafe I guess
19:24:42Araqnot threadlocal, threadsafe.
19:27:16stefanos82Araq: when --threads:on is used along with C++ code generator, does it use PThreads or C++11's thread?
19:28:59AraqPThreads
19:29:23stefanos82I see
19:29:34federico3dom96: besides, threading and async is why I ended up writing my morelogging lib
19:41:19*benji__ joined #nim
19:44:53*benjikun2 quit (Ping timeout: 244 seconds)
19:46:00federico3yet, the lack of logging hierarchy is going to affect all libraries that use the stdlib logging module
19:47:06Araqapropos hierarchy, I'm about to write an RFC to give Nim supervisors
19:54:05*Trustable quit (Remote host closed the connection)
19:55:47krux02federico3, there are people in this world who think the built in logging functionality of Linux makes every logging "framework" redundant
19:58:07Araqand then there is me, who thinks sqlite makes "logging" redundant.
19:58:07federico3krux02: Which one? There's more than one. Also, they cannot deliver some of the features that a library can.
20:04:58krux02federico3, I don't want to point you to a specific one. I am by far not an expert. All I want is to point you to look beyond the Nim horizon
20:08:35*miran quit (Quit: Konversation terminated!)
20:14:03federico3err... thanks?
20:14:50*Ven`` joined #nim
20:16:33*chopzwei quit (Quit: Leaving)
20:22:19*Vladar quit (Quit: Leaving)
20:24:32FromDiscord<treeform> Araq, I am doing 100% in my programming in nim now both at work and home. Thank you for making a great language.
20:31:21*xylef quit (Ping timeout: 240 seconds)
20:36:23Araqaweseom
20:38:44Araqawesome
20:39:02*regtools quit (Ping timeout: 276 seconds)
20:47:14*nsf quit (Quit: WeeChat 2.1)
20:47:20*FromGitter quit (Read error: Connection reset by peer)
20:48:09*FromGitter joined #nim
20:48:56*FromGitter quit (Read error: Connection reset by peer)
20:49:04*FromGitter joined #nim
20:51:57*avsej quit (Ping timeout: 240 seconds)
20:53:45*avsej joined #nim
20:53:49*avsej quit (Changing host)
20:53:49*avsej joined #nim
20:55:58*cryptocat1094 quit (Quit: gtg)
20:56:53*FromGitter quit (Remote host closed the connection)
20:57:02*FromGitter joined #nim
21:02:21*avsej quit (Ping timeout: 240 seconds)
21:03:19*FromGitter quit (Read error: Connection reset by peer)
21:03:31*FromGitter joined #nim
21:04:26*avsej joined #nim
21:04:26*avsej quit (Changing host)
21:04:26*avsej joined #nim
21:18:11*FromGitter quit (Remote host closed the connection)
21:19:35*FromGitter joined #nim
21:35:48FromDiscord<exelotl> so uh, what's people's opinion on something like this? https://gist.github.com/geckojsc/751892cb240704b5af84b29ba6ba3c39
21:36:18*FromGitter quit (Remote host closed the connection)
21:36:26*FromGitter joined #nim
21:46:20*Jesin joined #nim
21:53:45*avsej quit (Ping timeout: 264 seconds)
21:54:21*avsej joined #nim
21:54:22*avsej quit (Changing host)
21:54:22*avsej joined #nim
21:58:52*avsej quit (Ping timeout: 256 seconds)
22:01:21*dorelix_ joined #nim
22:03:14*dorelix quit (Ping timeout: 260 seconds)
22:13:59*avsej joined #nim
22:14:00*avsej quit (Changing host)
22:14:00*avsej joined #nim
22:21:33bozaloshtshexelotl: unnecessary
22:22:00bozaloshtshadding strings together is ugly, use format.
22:26:56dom96My opinion is: don't weaken the type system, it's there for a reason.
22:36:24*Sembei joined #nim
22:38:10*Pisuke quit (Ping timeout: 264 seconds)
22:38:55CodeVanceI'd prefer + for string concat
22:39:25FromDiscord<exelotl> yeah, tbh the only reason I thought of doing this is because I really don't like & for concatenation xD
22:39:27*Ven`` quit (Quit: q+)
22:39:49FromDiscord<exelotl> it's so awkward to reach
22:40:02FromDiscord<exelotl> and it looks ugly
22:40:32dom96+ is harder to reach on my keyboard :P
22:40:43dom96It's just something that requires getting used to
22:41:11*ng0 quit (Quit: Alexa, when is the end of world?)
22:41:23*FromGitter quit (Read error: Connection reset by peer)
22:42:12*FromGitter joined #nim
22:42:57FromDiscord<exelotl> fair, I feel like I got used to other weird concat operators (like Lua's `..`) a lot quicker than this
22:45:10CodeVancediff is .. is easy to get to on keyboard
22:45:56CodeVancenormal english keyboard & is in the middle top of keyboard. I have to try a few keys before it sticks
22:45:57CodeVanceoh well
22:46:02*benji__ is now known as benjikun
22:46:14CodeVancenitpicking
22:48:27FromDiscord<exelotl> I was wondering if there's a rationale behind using &? At first I was thinking it was to avoid confusion with arithmetic +, but then you have / for path joining
22:49:07*FromGitter quit (Remote host closed the connection)
22:49:30*FromGitter joined #nim
22:49:54*tersec_ quit (Ping timeout: 260 seconds)
22:50:19*tersec_ joined #nim
22:50:27*avsej quit (Ping timeout: 240 seconds)
22:55:36*avsej joined #nim
22:55:36*avsej quit (Changing host)
22:55:36*avsej joined #nim
23:04:50*avsej quit (Ping timeout: 244 seconds)
23:09:56*avsej joined #nim
23:09:57*avsej quit (Changing host)
23:09:57*avsej joined #nim
23:17:52*donlzx joined #nim
23:30:44*Jesin quit (Ping timeout: 260 seconds)
23:30:57*avsej quit (Ping timeout: 240 seconds)
23:33:40*avsej joined #nim
23:33:40*avsej quit (Changing host)
23:33:40*avsej joined #nim
23:34:04*xet7 quit (Quit: Leaving)
23:37:51*avsej quit (Ping timeout: 240 seconds)
23:38:38FromGitter<kayabaNerve> dom06 https://github.com/nemasu/asmttpd
23:40:06*avsej joined #nim
23:40:06*avsej quit (Changing host)
23:40:06*avsej joined #nim
23:40:40FromGitter<rayman22201> I'm having an issue with variant types / case statements. I am messing around with Peg.nim in stdlib. I added a new type to the enum, along with a new switch to the case statement and now I'm getting an error: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5b4e7e784b583a74a7241a6b]
23:41:40FromGitter<rayman22201> any ideas why, adding a switch would cause the compiler to tell me that I don't have all the cases covered?
23:43:08FromGitter<kayabaNerve> Because you don't have a default?
23:43:39FromGitter<kayabaNerve> *else
23:43:49FromGitter<rayman22201> the else is right there
23:43:58FromGitter<rayman22201> second to last line
23:44:17FromGitter<rayman22201> ```else: sons[Peg]```
23:44:21FromGitter<kayabaNerve> Nvm. Sorry.
23:44:23FromGitter<kayabaNerve> Yep
23:44:28FromGitter<kayabaNerve> I didn't read the
23:44:33FromGitter<kayabaNerve> *code statement
23:44:38*stefanos82 quit (Quit: Quitting for now...)
23:44:48FromGitter<rayman22201> np
23:45:22FromGitter<rayman22201> It's weird. If I delete my new case, it works. the ```pkGreedyRangeRepeat```
23:45:44FromGitter<kayabaNerve> Why is your Peg object that?
23:46:04FromGitter<rayman22201> why would adding a case cause this? I have a feeling it might be something else and the compiler is giving me an incorrect error msg.
23:46:17FromGitter<kayabaNerve> The source has it mapped to a node which is the same thing... Does that affect it?
23:46:53FromGitter<kayabaNerve> Improper spacing? What if you make it one line?
23:47:18FromGitter<rayman22201> doesn't make a difference. I have tried it both ways. one line or two
23:47:26FromGitter<kayabaNerve> I'm guessing and doubt it isn't about the node. My... Not prediction or guess is that it's spacing
23:47:27FromGitter<kayabaNerve> Got it.
23:48:11zacharycarterdo you have all cases covered?
23:48:16zacharycarteroh
23:48:17zacharycarterI see you have an else
23:48:24FromGitter<kayabaNerve> Lol
23:48:44FromGitter<kayabaNerve> I did the exact same
23:48:57FromGitter<rayman22201> Lol. The default case for everybody's response to case statement problems :-P very meta
23:48:59zacharycarter:P
23:49:04zacharycarterthat one liner
23:49:05zacharycartertricky bastard
23:49:33zacharycarteryeah I feel like I've seen this before
23:49:45*FromGitter quit (Read error: Connection reset by peer)
23:50:26*FromGitter joined #nim
23:50:49FromGitter<rayman22201> here is some interesting additional info. if I change my new case to this I don't error: ⏎ ⏎ ```of pkGreedyRangeRepeat: min: int``` [https://gitter.im/nim-lang/Nim?at=5b4e80d964990f3c000c9f45]
23:51:05FromGitter<rayman22201> Well, I get a different error, because the other fields are missing
23:51:20FromGitter<rayman22201> but the compiler gets passed the case statement
23:52:39FromGitter<rayman22201> Why would having multiple fields defined in a variant type case statement cause the compiler to think I don't have all the cases covered?
23:57:18*avsej quit (Ping timeout: 256 seconds)
23:59:22zacharycarterwell
23:59:28*zacharycarter sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/kVyfUbjKYLJYgDQQxeEaahpX >
23:59:59*zacharycarter sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/HHRETFMEtUbsBpNNgsQfCBhA >