<<24-04-2019>>

00:08:22*a_b_m quit (Ping timeout: 245 seconds)
00:15:21*[rg] joined #nim
00:32:26*sentreen quit (Ping timeout: 268 seconds)
00:39:55*fredrik92 joined #nim
00:40:08*couven92 quit (Disconnected by services)
00:40:17*fredrik92 is now known as couven92
00:43:25*dddddd quit (Read error: Connection reset by peer)
00:44:27*sentreen joined #nim
00:46:42*sentreen_ joined #nim
00:49:57*sentreen quit (Ping timeout: 258 seconds)
01:05:12FromGitter<jrfondren> the old manual's at https://nim-lang.org/docs/manual.html#procedures-do-notation
01:12:33*couven92 quit (Quit: Client Disconnecting)
01:13:56FromGitter<jrfondren> chopping block: Package level objects, Void type, Covariance, Automatic dereferencing, Automatic self insertions, Do notation, Read/write tracking, Concepts, type[T], type operator, special operators, Type bound operations, Term rewriting macros, AST based overloading, Unchecked pragma, Prallel & Spawn, Guards and locks, Taint mode
01:15:55*[rg] quit (Quit: Leaving)
01:18:32*jasper__ joined #nim
01:20:54*rnrwashere joined #nim
01:26:52jasper__That stuffs been moved to the experimental manual. Link near top of normal manual. Maybe there should be a link from docs mainland?
01:27:11jasper__mainpage*
01:28:08*rnrwashere quit (Remote host closed the connection)
01:28:08FromGitter<jrfondren> rather, I don't look for navigational content in the main body of the manual
01:28:18FromGitter<jrfondren> which is a polite way of saying I didn't read boring stuff at the beginning
01:29:04*rnrwashere joined #nim
01:30:03FromGitter<jrfondren> the type operator's still gone, though
01:38:38*rnrwashere quit (Remote host closed the connection)
01:55:57*flaviu joined #nim
02:07:17*banc quit (Quit: Bye)
02:23:18*arecaceae quit (Remote host closed the connection)
02:23:38*arecaceae joined #nim
02:28:33*banc joined #nim
02:36:50FromGitter<brentp> this throws an underflow error.
02:36:53FromGitter<brentp> ``````
02:37:00FromGitter<brentp> ```var x:uint32 = 0 ⏎ for i in 0..<x: ⏎ echo i ``` [https://gitter.im/nim-lang/Nim?at=5cbfcbcb5b3f941aa5803f60]
02:37:28FromGitter<brentp> I can see why, and can cast to int, but this seems surprising. is it a bug?
02:52:28FromGitter<jrfondren> common behavior in other languages is to do nothing in such cases, but I don't know if it's an actual bug.
02:53:59FromGitter<jrfondren> ah wait, the languages I thought of didn't have unsigned ints though. this loop also does nothing in Nim, given signed ints
02:54:52FromGitter<jrfondren> what behavior were you hoping from that loop? A loop of FFFF_FFFF iterations and a loop of zero iterations both seem reasonable.
02:56:59FromGitter<jrfondren> (in d:release, the behavior you get is FFFF_FFFF iterations)
03:00:21*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
03:21:03FromGitter<jrfondren> correction: the behavior you get in d:release is an infinite loop.
03:21:27FromGitter<jrfondren> this might be because of GCC optimizing an 'impossibility' out of the loop test.
03:21:40FromGitter<jrfondren> in any case, that makes it a lot more of a candidate for a bug.
03:22:28FromGitter<jrfondren> I'll submit an issue about it
03:24:43shashlickgot the android build done but now nimble doesn't run - could not import: SSL_CTX_ctrl
03:25:14FromGitter<brentp> @jrfondren I don't see inifinte loop with -d:release
03:25:35FromGitter<jrfondren> try this: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5cbfd72f8790b0307ef0249d]
03:27:38FromGitter<brentp> hrm well. I do see infinte loop in original. I was just compiling without -r flag
03:40:07leorize[m]1shashlick: maybe because android doesn't use openssl?
03:40:37*leorize[m]1 is now known as leorize[m]
03:41:37shashlicki'll have to statically link openssl into nimble?
03:42:17shashlickthere's a libssl.so in the lib directory and per termux's package info, it is 1.1.1
03:42:44shashlickbut nm -D doesn't show SSL_CTX_ctrl
03:46:41shashlickmy ubuntu copy of libssl.so does
04:02:05*kapil____ joined #nim
04:29:45*nsf joined #nim
05:01:07*rnrwashere joined #nim
05:19:13FromDiscord_<treeform> I am trying to convert a utf16 string, but I get strange error:
05:19:14FromDiscord_<treeform> echo convert("T\0h\0e\0 \0M\0", "UTF-8", "UTF-16")
05:19:29FromDiscord_<treeform> Error: unhandled exception: The parameter is incorrect.
05:19:39FromDiscord_<treeform> What am I doing wrong?
05:26:20*narimiran joined #nim
05:26:52*leorize quit (Quit: WeeChat 2.3)
05:39:33FromGitter<jrfondren> works for me.
05:41:11FromGitter<jrfondren> complete workable example on stable and devel: ⏎ ⏎ ```import encodings ⏎ echo convert("T\0h\0e\0 \0M\0", "UTF-8", "UTF-16")``` [https://gitter.im/nim-lang/Nim?at=5cbff6f73b6cb0686a434db7]
05:43:18FromGitter<jrfondren> encodings makes use of libiconv on posix, and some kernel32 stuff on windows. if that example's failing for you, you probably have iconv problems. try stracing the executable to see what it's doing.
05:46:41*solitudesf- joined #nim
05:49:58FromDiscord_<treeform> no I am on windows, I am having windows kernal32 problems.
05:50:31FromDiscord_<treeform> this line: https://github.com/nim-lang/Nim/blob/master/lib/pure/encodings.nim#L395
05:50:37*rnrwashere quit (Remote host closed the connection)
05:50:50FromDiscord_<treeform> It seems like it tries wideCharToMultiByte several times, then gives up.
05:51:51FromDiscord_<treeform> I just did my own utf16 decoding and it works, probably not idea.
05:54:26*leorize joined #nim
05:57:21*rnrwashere joined #nim
05:59:37*krux02 joined #nim
06:00:09*leorize quit (Ping timeout: 256 seconds)
06:02:10FromGitter<kayabaNerve> Anyone else's Nim compiler outputting "_7" a lot?
06:03:07FromGitter<kayabaNerve> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5cbffc1b97dcb371d803cb00]
06:03:24FromGitter<kayabaNerve> It's only happening with Nimble packages.
06:07:38leorize[m]it's the "same module name in nimble" fix
06:08:10leorize[m]see https://github.com/nim-lang/Nim/commit/0121dda9ba903b764cbd234667cc03f79ebadf44
06:10:35*thomasross quit (Ping timeout: 246 seconds)
06:20:33AraqI want to fix the compiler message but not the file mangling :P
06:20:43Araqanybody got a problem with that? ;-)
06:21:58*leorize joined #nim
06:29:37*leorize quit (Ping timeout: 256 seconds)
06:32:51leorize[m]nimble really needs a better dependency graph
06:33:31leorize[m]install a package and it asked me to "overwrite" that dependency installed earlier 3 times in a row
06:35:55AraqI agree.
06:40:05*PMunch joined #nim
06:46:02*solitudesf- quit (Ping timeout: 250 seconds)
06:46:23*rokups joined #nim
06:46:40leorize[m]Araq: I believe a template can be used as a pragma without annotating with {.pragma.}, right?
06:46:45leorize[m]or does that just applies to macros?
06:47:19Araqthese are different things. .pragma is for object field pragmas etc
06:47:29Araqproc transformators don't have the .pragma
06:49:23leorize[m]I see
06:58:45*solitudesf- joined #nim
07:00:00*gmpreussner quit (Quit: kthxbye)
07:04:48*gmpreussner joined #nim
07:05:14*solitudesf- quit (Ping timeout: 258 seconds)
07:11:54PMunchWhy is getEnv in the ospaths module? That is a bit unintuitive
07:12:51FromGitter<jrfondren> in devel, that's a deprecated module that just reexports from os
07:23:29PMunchAh, nice
07:25:12*Perkol joined #nim
07:41:56*slugm joined #nim
07:53:43FromGitter<kayabaNerve> Thanks leorize[m] for the clarification
07:54:17*rnrwashere quit (Remote host closed the connection)
07:54:59FromGitter<kayabaNerve> Nim
07:55:15FromGitter<kayabaNerve> *Nim's macros are one of the best things about Nim, especially with how flexible they are.
07:55:33*SebastianM joined #nim
07:56:02FromGitter<kayabaNerve> I use two macros in my code base, one for stricter error handling and a valid raises on async, and one to stop double setting fields on refs by accident.
07:56:10SebastianMHey guys,
07:56:18FromGitter<kayabaNerve> It's great to be able to open up the compiler like that. Next we just need file wide macros...
07:56:32FromGitter<jrfondren> templates can be scoped to a single proc body.
07:56:52SebastianMIs there a way to discover object methods like in Python? dir(object)?
07:56:55FromGitter<kayabaNerve> Is there a Feature Request for that? It's been discussed often, and the general discussion is: "I want to do X" "Can't be done" "Maybe can be" "Filters"
07:57:25FromGitter<jrfondren> @kayabaNerve for file-scoped macros?
07:57:27FromGitter<kayabaNerve> I've been on the side that recommends filters, but I actually sat down with them the other day and they just aren't a valid option.
07:57:28FromGitter<kayabaNerve> Yeah.
07:57:36FromGitter<kayabaNerve> A single line at the top of the file.
07:57:51FromGitter<kayabaNerve> Filters are line by line and therefore can't be used to apply a leading ident to the entire file.
07:58:30FromGitter<jrfondren> SebastianM, what I tend to do is start inim and type void.blah , so that inim can complain about the type mismatch, and suggest valid alternatives
07:58:33FromGitter<kayabaNerve> I tried doing two replace filters chained together; one replacing \n with `\n `, and one replacing `\n <-` with \n.
07:59:02FromGitter<kayabaNerve> Gitter removes the spaces, but the `\n`s in code tags are meant to have 4 spaces after...
07:59:04FromGitter<jrfondren> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5cc0174797dcb371d8048fbd]
07:59:38FromGitter<jrfondren> the wiki says that dir()-style reflection is possible but I haven't seen an example of it yet
08:02:03*neceve joined #nim
08:03:08FromGitter<jrfondren> are you sure that macros *aren't* file scoped already?
08:03:37SebastianMjfrontdren, thank you
08:03:50FromGitter<jrfondren> loosely speaking. modules like sugar have export symbols on their macros after all.
08:04:55*SebastianM quit (Quit: Seeya)
08:05:46*floppydh joined #nim
08:07:10FromGitter<jrfondren> OK, I guess you're watching to be given the entire AST of the file to work with.
08:17:11FromGitter<jrfondren> @kayabaNerve well it looks relatively easy to add a new kind of source filter.
08:17:34FromGitter<jrfondren> start with filterNames in compiler/syntaxes.nim
08:18:01FromGitter<jrfondren> and applyFilter has a case that could be extended.
08:23:10PMunchHmm, I'm trying to create a template/macro that adds explanations to error messages to the documentation. Something like expl("Something went wrong", "This message occurs when blah, blah, blah, blah") only "Something went wrong" will be printed, but the procedure should have a table of messages and explanations
08:23:45PMunchHmm, maybe a pragma applied to the procedure is the only way..
08:24:05PMunchAdding ## in the middle of a procedure body doesn't work..
08:25:09leorize[m]you can use a placeholder template I believe
08:26:14PMunchPlaceholder?
08:28:01leorize[m]ah, I misread your msg, sorry
08:28:16*slugm quit (Remote host closed the connection)
08:28:24leorize[m]yea, I think you'd need a pragma for that
08:32:30*slugm joined #nim
08:33:22FromGitter<kayabaNerve> @jrfondren It's possible to edit the compiler in a lot of ways.
08:33:46FromGitter<kayabaNerve> A file wide macro that requires a compiler edit shouldn't be via a filter.
08:38:35FromGitter<jrfondren> that's at least an option that clearly signals that something weird's going on. I'm already a little repulsed by the performWithUndo do-notation example, where code that looks visually unrelated to the preceding code is actually part of the preceding code's control flow.
08:40:09Araqthe 'do' notation was moved to manual_experimental for a reason
08:40:33Araqand I *hate* full file rewrite macros which is why they don't exist
08:41:01Araqyou cannot read code where anything is subject to arbitrary macro rewrites
08:41:44*slugm_ joined #nim
08:43:02*Vladar joined #nim
08:44:08*slugm quit (Ping timeout: 258 seconds)
08:44:30FromGitter<jrfondren> or even if you can in practice, tooling stops being able to. Perl can't even syntax check a script if it includes a module that isn't available.
08:45:23*slugm_ quit (Remote host closed the connection)
08:48:27*slugm joined #nim
08:48:40*SebastianM joined #nim
08:50:37*slugm quit (Remote host closed the connection)
08:50:56SebastianMAraq, guys:I discovered nim secrets and playing with it for learning purposes. But when i type e.g var a = 10 it echoes 10 and when i then type e.g a = 15 it echoes 10, the previous value.Could you please check it? Nim nightly from yesterday. Thank you
08:51:12*SebastianM quit (Client Quit)
08:51:48leorize[m]nim secret is a secret for a reason :p
08:52:25FromGitter<jrfondren> nimble install inim . it's pretty good.
08:52:27*slugm joined #nim
08:52:30PMunchSebastianM, you mean like this http://ix.io/1H3v/ ?
08:52:37narimiranSebastianM: see if `inim` works better for you
08:53:21FromGitter<kayabaNerve> Araq: It's all about scope. Can you read a function if it has a macro?
08:53:34FromGitter<kayabaNerve> If you can, then why can't you read a file if it has a macro?
08:53:34PMunchHmm, what's the best way to have a macro just slightly modify it's input?
08:53:49FromGitter<kayabaNerve> It's just removing the requirement to apply a 4 space ident to everything
08:54:00PMunchAs in replace instances of something with something else. Do I need to build the entire tree over again, or use deepCopy?
08:54:03narimiranbtw, i also tested it on devel (PMunch tested it with 0.19.4) and it seems to work correctly
08:54:26FromGitter<kayabaNerve> It's not like the discussion is about having external files apply macros. The discussion is about a file having it's L1 declaring a file wide use of macro X.
08:55:30leorize[m]don't really know if this works: {.push: yourmacro.}
09:06:22Araqyes, I can read the function because the macro call would be written as
09:06:26Araqm: proc
09:06:34Araqor proc ... {.m.}
09:06:51Araqand that makes all the difference
09:06:58*sentreen_ quit (Quit: sentreen_)
09:07:14*sentreen joined #nim
09:12:51leorize[m]Araq: should "cast[seq[byte]](string)" (and the reverse) get their own procs? This is common enough in Nim when you have to deal with binary data
09:13:15PMunchHmm, so I can't deep copy, and I can't define the input to a macro as var. So do I have to manually recreate the entire tree?
09:14:22FromGitter<mratsim> I don't think so
09:14:46FromGitter<mratsim> we should change usage of strings for binary to seq[byte] instead
09:15:05FromGitter<mratsim> I'm not even sure how cast seq[byte] would interact with destructors
09:15:28FromGitter<mratsim> @PMunch, thoughts on protobuf2 support? https://github.com/PMunch/protobuf-nim/issues/16
09:16:12leorize[m]IIRC Araq said it'd work, and a quick look at their structures in seqs and strs module yield similar structures
09:16:33PMunchmratsim, oh sorry. I read that while on a super dingy internet connetion and forgot to reply when I got back
09:17:11*Perkol quit (Remote host closed the connection)
09:17:27Araqleorize[m]: didn't you fix 'cast' with --newruntime?
09:17:49leorize[m]mratsim: and while we should change string to seq[byte] for binary, that won't make all the current libs change :/
09:18:11leorize[m]Araq: I didn't?
09:18:33leorize[m]must be cooldome or someone else :p
09:19:41Araqok it was somebody else then. but it works
09:23:19FromGitter<mratsim> @leorize, yeah I know but I think we're going there. For crypto I already raised this: https://github.com/nim-lang/RFCs/issues/32 and nimcrypto is doing the right thing (TM) and PMunch added streaming from seq byte in streams as well.
09:23:46FromGitter<mratsim> I'm not too sure about the other domain that often use binary blobs (graphics?)
09:26:44FromGitter<mratsim> @Araq, thoughts on revisiting all binary blob proc in stdlib, use seq[byte] and deprecated the string API? I think we should do that for 0.20 so that we don't entrench bad practice in 1.0
09:26:51FromGitter<mratsim> deprecate*
09:27:58FromGitter<mratsim> I think we should leave newStringStream for interop with C `char *` but at least all the crypto packages should be changed
09:29:58PMunchWhy isn't there a prepend in the macros module?
09:33:01*xet7 quit (Quit: Leaving)
09:34:18*stefanos82 joined #nim
09:34:27FromGitter<jrfondren> so the benefit of avoiding strings for binary data, is it that strings are immutable but when you have large blobs of binary data you often want to mutate it? or is it "the word string should only apply to properly encoded human text" like in lots of other languages?
09:34:44*Cthalupa quit (Ping timeout: 258 seconds)
09:34:49leorize[m]the latter
09:35:03FromGitter<jrfondren> then I prefer the status quo.
09:35:22narimiranjrfondren: strings are mutable, btw
09:35:44*Cthalupa joined #nim
09:35:46FromGitter<jrfondren> too many experiences of "OK I want to sling bytes around and I don't care about them at all except that they should move from here to there OH NO AN UNICODE ALLIGATOR EMOJI, the server just crashed"
09:36:02*xet7 joined #nim
09:36:19FromGitter<jrfondren> that's a real world example btw.
09:37:39leorize[m]uhmm, care to elaborate? If it's utf-8, then everything is composed with byte, how can your server crash?
09:38:18FromGitter<jrfondren> the server validated its strings. Unicode though is a moving target, so clients started sending what they but not the server considered to be valid.
09:39:36leorize[m]Nim doesn't do that unless you told it to :p
09:39:41FromGitter<jrfondren> yeah, I like that.
09:40:10dom96what does this have to do with seq[byte] vs. string?
09:40:13FromGitter<mratsim> It's not about the message content or encoding, it's about what is expected.
09:40:29*Cthalupa quit (Ping timeout: 258 seconds)
09:40:38FromGitter<jrfondren> I like the status quo where Nim doesn't enforce any encoding and strings can contain binary.
09:40:53FromGitter<mratsim> binary blob --> seq[byte], something for humans --> string
09:40:56FromGitter<jrfondren> I asked what the point was of moves to not enforce the bad practice of using the string type for binary data
09:41:19dom96jrfondren: Oh I agree with you there
09:41:25FromGitter<mratsim> the goal is about using the type system to prevent bugs
09:41:45FromGitter<jrfondren> type HumanString = distinct string
09:41:48FromGitter<mratsim> especially for crypto, where you have string message but output binary blob
09:42:08dom96Do we really want socket.recv to return a seq[byte]?
09:42:26FromGitter<jrfondren> well the output could be anything, couldn't it. Someone could encrypt random noise and send it to you.
09:42:30dom96Most protocols are in fact human friendly
09:42:50*Cthalupa joined #nim
09:43:14leorize[m]which is why I think a set of zero cost conversion procs are nice...
09:43:47FromGitter<jrfondren> seq[byte] and string do seem to be identically backed.
09:43:48FromGitter<mratsim> wehn you see a seq[byte] in the signature, you know that you can receive anything, so that you need to validate it.
09:44:00FromGitter<mratsim> yes string and seq[byte] can be casted into each other
09:44:20FromGitter<mratsim> apparently it started as an implementation detail but Araq will keep it like that in the future
09:44:55dom96casted? He should make it possible to type convert these then
09:45:04dom96cast should be viewed as dangerous
09:46:14FromGitter<mratsim> Regarding recv, it uses a void *: https://nim-lang.org/docs/posix.html#recv%2CSocketHandle%2Cpointer%2Cint%2Ccint
09:46:57FromGitter<mratsim> so you can recv into a seq byte
09:47:04FromGitter<jrfondren> yeah, the raw syscalls don't care about data. I really hate spending hours at a time trying to find the incantation that'll tell some of these languages how to do that and not mess with it further.
09:47:13FromGitter<mratsim> This is what we use in Chronos
09:47:14ZevvI would be sad if I could no longer recv and send strings
09:47:42Zevvconversion is still cumbersome, and casting is nasty
09:47:44leorize[m]I'm pretty sure recv should return a TaintedString
09:48:17Zevvseems the right thing to do
09:48:25FromGitter<jrfondren> does distinct not work well on strings? I've noticed that it can be pretty annoying to get the desired borrows, in other uses.
09:48:45FromGitter<mratsim> we can have recv(buffer: var TaintedString|seq[byte], foo: ...)
09:49:01FromGitter<mratsim> distinct works on strings, but is unusable with generics
09:49:04leorize[m]distinct works well, just that it's underused
09:49:15dom96most people use the recv that returns a string
09:49:32FromGitter<mratsim> because they have no other option
09:49:58leorize[m]doesn't mean you should drop the byte folks when you could just support them :p
09:50:31leorize[m]also TaintedString seems to be more inline with how other parts like readLine works
09:53:28dom96yeah, I agree that TaintedString should be returned
09:54:40*r4vi quit (Ping timeout: 264 seconds)
09:54:40*enigmeta quit (Ping timeout: 264 seconds)
09:54:52*enigmeta joined #nim
09:58:38*r4vi joined #nim
09:58:56*iLiquid joined #nim
10:02:05FromGitter<yglukhov> `string` in computer science usually means a sequence of characters. `TaintedString` means something intended to be a string, but needing some validation first. `seq[byte]` is a sequence of arbitrary bytes (binary data). What am i missing here?
10:02:44*lritter joined #nim
10:02:48Zevvwell, it just depends on how you're going to handle the data. Some protocols are better handled by strings, some by binary data.
10:03:00FromGitter<jrfondren> there are a bunch of crypto modules that differ in the types they use and that's annoying. There's also a sentiment that strings should mean valid Unicode and that worried me. that's all.
10:03:42ZevvOh I never knew that - but there is nothing in place enforcing that anywhere, right?
10:03:44leorize[m]oh, I believe Nim will never enforce any encoding on string
10:03:48FromGitter<mratsim> user-supplied string needs to be checked anyway for validity
10:04:15ZevvBut still - apart from casting, there is no zero-cost way to convert strings into seq[char] or seq[byte], right?
10:04:29FromGitter<mratsim> but the string type should be intended for something using human characters whatever encoding is used, not for raw binary data
10:04:56FromGitter<jrfondren> since the casting is safe, I guess the zero-cost way would just be an inline proc that does the cast, so you don't have to :)
10:05:07FromGitter<yglukhov> So is `recv` is tcp/udp, there's no notion of "sequence of characters" at that level. It's only binary data. Which you can further try interpreting as sequence of characters (ie string).
10:05:22leorize[m]Zevv: yea, and I think we should add some proc for that
10:05:44Zevvthat would make sense. If the underlying representation changes one day, casting is no longer valid.
10:06:28ZevvAnd the system calls handling void* is a good indicatio that there is no right answer here. It is just bytes - I might want to put it in a string, or put it in a seq[byte], depending on what I'm doing.
10:07:06FromGitter<jrfondren> which anyway leads back to "modules differ in their choices and that's annoying"
10:07:45leorize[m]anyone want to make toString and toSeqByte?
10:07:52FromGitter<mratsim> which is why I want to tackle standardizing that, at least for my domain of interest
10:08:00*couven92 joined #nim
10:08:18FromGitter<mratsim> because I don't want to have more crypto packages using string or seq[uint8] (yes there are)
10:08:42FromGitter<mratsim> and string is sometimes expected to be hex string ...
10:08:58Zevvmratsim: makes sense, what is your proposal then?
10:09:40FromGitter<mratsim> For crypto, deprecates string for binary, and have a seq[byte] proc for starter
10:09:47Zevv11:14 < FromGitter> <mratsim> we should change usage of strings for binary to seq[byte] instead
10:09:51Zevvsorry :)
10:10:23FromGitter<mratsim> also I have to check the "$" implementation so that it's consistent, some produce a binary string, and some produce hex code
10:10:59FromGitter<mratsim> regarding networking I think we should have both TaintedString|seq[byte] recv and friends
10:11:05FromGitter<mratsim> and deprecate the string one.
10:11:15FromGitter<jrfondren> that's going too far.
10:11:16FromGitter<mratsim> that's assuming we want to go forward with TaintedString
10:11:31FromGitter<mratsim> there is a RFC by timotheecour on that though
10:11:32FromGitter<jrfondren> oh well TaintedString instead of string is fine
10:12:09ZevvTaintedString makes sense, as converting to a string is trivial
10:12:36ZevvTaintedString is nothing more then a distinct string, right?
10:12:48Zevvthere is no magic under the hood
10:12:57FromGitter<mratsim> iirc there were some complaints that it's still costly because you have to think about it but better check the RFC, I didn't really participate in it
10:13:12FromGitter<jrfondren> moreover if you don't turn tainting on, you get a string.
10:14:00FromGitter<mratsim> Feel free to discuss: https://github.com/nim-lang/RFCs/issues/24
10:14:05Zevvwell, the whole purpose is to make you think about it. You're pulling in unsafe data, just on your hands for a second before you handle it
10:14:31FromGitter<jrfondren> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5cc037073b6cb0686a44eb7b]
10:14:46FromGitter<jrfondren> see? what a cool language.
10:15:09FromGitter<mratsim> The conversation is stale so it's good to have new Nim devs perspective on that
10:15:53FromGitter<jrfondren> want that in Ruby or Perl, you've got to hack it into the guts of the interpreter. If Nim didn't provide TaintedString, a nimble module could provide all the tainted versions and people could use that instead of the flag.
10:16:04ZevvI guess defaulting to the safe mode is also good from the PR stance of Nim being a safe language.
10:23:50*Vladar quit (Remote host closed the connection)
10:27:02Araqmaybe TaintedString is the wrong idea
10:27:37Araq'string' is already quite "untyped", what matters is that you don't end up with 'string' in your SQL/HTML
10:28:33Araqnor in your osproc calls...
10:30:28FromGitter<mratsim> Hopefully showing that we care about types in stdlib will make dev care about types in their own lib
10:35:46Araqyeah. I think that's it. in the compiler I have nimnode.strVal of type 'string'. has that gone through Nim's parser? yes. so it's not a 'TaintedString'. Can I pass n.strVal to 'exec'? seems to be a terrible idea
10:49:16FromGitter<kayabaNerve> Araq: So proc {.m.} is clear, as well as m: proc, but not apply(m) \r\n proc()
10:49:36Araqyes.
10:49:45FromGitter<kayabaNerve> Eh. Writing it as a function call sucks. apply is also way to generic a function name.
10:49:52FromGitter<kayabaNerve> :thinking:
10:49:59Araqthat's where Nim and I draw the line.
10:50:18Araqa macro can influence its children, not its parents
10:50:42*kapil____ quit (Quit: Connection closed for inactivity)
10:51:40FromGitter<kayabaNerve> I think those are the same level
10:52:15FromGitter<kayabaNerve> I think a parent would be if a file wide macro affected a file which imported the file the macro was in
10:57:43krux02@mratsim: can you elaborate more on what you want to do in 11091 a bit more?
10:57:58krux02I think I did something similar in the past, and there is a better approach to do it.
10:59:34FromGitter<mratsim> my main issue is the openSymChoice of [] instead of nnkBracketExpr
11:02:08FromGitter<mratsim> second issue but more meta is that I'm always fighting with symbols in macros :/
11:02:21PMunchHmm, grid tables aren't implemented. That's incovenient..
11:02:33PMunchThe simple table syntax is a bit of a pain to make programatically
11:02:39FromGitter<mratsim> I've opened a feature request a year ago about grid tables
11:07:05FromGitter<mratsim> Pandoc outputs grid tables by default as well which is useful to convert markdown to rst
11:11:17FromGitter<mratsim> A captcha with what is the result of 2+2 would go a long way to prevent those pesky spammers
11:11:51Zevv!eval 2+2
11:11:51NimBotCompile failed: <no output>
11:12:07FromGitter<mratsim> or a hidden field that is not supposed to be filled or both
11:12:10narimiran!eval echo 2+2
11:12:11NimBotCompile failed: <no output>
11:12:41FromGitter<mratsim> !eval echo(2+2)
11:12:41NimBotCompile failed: <no output>
11:12:48FromGitter<mratsim> I think the bot is dead
11:12:50FromGitter<liquid600pgm> iirc nimbot is broken
11:12:55ZevvFor months
11:13:00FromGitter<mratsim> !eval echo "It's alive!"
11:13:00NimBotCompile failed: <no output>
11:13:25ZevvI fork bombed it once, and that also killed the live nim playbin.
11:13:41Zevviirc the original maintainers were not pleased with the setup and decided not to bring it back up
11:14:06FromGitter<mratsim> mmm the playground is dead as well :/
11:14:17krux02that is sad
11:14:22narimiranplayground has been dead for quite a long time
11:14:27Zevv^
11:14:41FromGitter<mratsim> I guess that's why the bot doesn't work
11:14:43krux02mratsim: but about your problem with the symbols in the macro, I had very similar problems
11:15:13dom96nimbot isn't broken
11:15:15dom96the playground is
11:15:19FromGitter<mratsim> Yeah I expect everyone to have issues with those, even strformat was due to symbols
11:15:20dom96all nimbot does is call it
11:15:24krux02I think I eventually gave in and made my macro aware of nnkBrackedExpr and the call to ``[]`` as well.
11:15:30dom96once again, I repeat
11:15:35dom96I've got a Droplet ready
11:15:42dom96someone just needs to set up the playground on it
11:15:44dom96any takers?
11:16:12*dddddd joined #nim
11:16:23FromGitter<mratsim> what's a droplet :?
11:16:30PMunchI was supposed to take over the playground..
11:16:31krux02I wanted to ask the same thing
11:16:38krux02I have no idea what a droplet is
11:16:39dom96digitalocean VPS
11:16:46krux02VPS?
11:16:50PMunchBut no-one ever gave me access to it..
11:16:55FromGitter<liquid600pgm> virtual private server
11:16:58FromGitter<mratsim> VPS is like a server
11:17:05FromGitter<mratsim> but in a container
11:17:09FromGitter<liquid600pgm> ^
11:17:15krux02ok
11:17:21PMunchSo I guess what I'm saying is dom96 that I can set it up
11:17:39krux02I think sooner or later we are better off with a real PS (private server)
11:17:46PMunchOr well, I don't know how to, since I never saw the old setup. But I can hopefully figure it out :P
11:17:58dom96PMunch, it's a learning experience :)
11:18:07dom96send me your public ssh key and I'll add you
11:18:16dom96krux02, why?
11:18:23krux02mratsim: what does your macro compile
11:18:40krux02dom96, mostly because of testing timeouts.
11:19:07krux02on private servers we can control the testing environment better.
11:19:08dom96you mean for CI?
11:19:12FromGitter<mratsim> @krux02: the full example is here - https://github.com/mratsim/compute-graph-optim/blob/master/e10_DSL_compiler_interleaved.nim#L364-L381
11:19:12krux02yes
11:19:21dom96I agree
11:19:28dom96but just call them VPS'
11:19:29*vlad1777d__ quit (Ping timeout: 255 seconds)
11:19:47krux02mratsim: what does it do?
11:20:05FromGitter<mratsim> I'm building a neural network compiler, so mostly linear algebra, for now I compile to Nim code, next step is compiling to SSE/AVX instructions with dynamic dispatch
11:20:19FromGitter<mratsim> next step is compiling to LLVM bitcode for cuda/opencl/vulkan code generation
11:21:10FromGitter<mratsim> basically I have a expression, say a + b + c on a sequence of floats, I fuse all loops and output optimised SIMD instructions with runtime CPU detection
11:21:12krux02well, since I already have a working nim to glsl compiler I think I might be able to give you some valuable information
11:21:33krux02so what is a in this context?
11:21:41FromGitter<mratsim> a sequence of float
11:21:47krux02is a + b + c part of a kernel?
11:21:49FromGitter<mratsim> b is the same, of the same length
11:21:53FromGitter<mratsim> and c as well
11:21:59FromGitter<mratsim> you can view that as a kernel yes
11:22:00krux02or is `+` a vector/seq instruction?
11:22:08FromGitter<mratsim> and in the future I want to be able to compose them
11:22:09krux02ah ok
11:22:29krux02you want to compose what?
11:22:31FromGitter<mratsim> basically a is an AstNode, and compile materialize that
11:23:06FromGitter<mratsim> foo = a + b + c, bar = foo * 2 --> foobar should fuse everything without ever materializing the foo intermediate sequence
11:23:37FromGitter<mratsim> and it should support statement as well, like foo += a
11:24:15*Trustable joined #nim
11:24:34FromGitter<mratsim> the link I gave is a proof of concept working for scalars
11:25:21krux02ah, I get it now.
11:25:46krux02the syntax is a bit confusing to me right now
11:25:59FromGitter<mratsim> I'll work on that
11:26:24krux02I would probably try to keep the normal function syntax
11:26:59FromGitter<mratsim> Yeah I could use normal function syntax and scan it in a macro
11:27:03krux02proc foobar[T](a, b, c: T): tuple[bar, baz, buzz: T] {.compile.} = buzz = a * 1000
11:27:16FromGitter<mratsim> I wouldn't need a template for scoping that way
11:27:19FromGitter<mratsim> even better
11:27:33FromGitter<mratsim> thanks for the suggestion
11:27:36krux02with get impl you can even do it without annotating the function at all
11:28:43krux02sometimes the solution is very simpler, but for strange reasons you just don't see it.
11:29:28FromGitter<mratsim> I was focused on the AST so I just used my first idea for API :p
11:29:55*i7sDream joined #nim
11:30:27krux02yea, it matters to reuse existing patterns in the language, because they have been proven to work
11:30:41krux02and they are supported by other structures in the language.
11:31:05FromGitter<mratsim> when I say focused, I was checking embedded domain specific language in Scala, Haskell, ocaml, stuff like church encodings, attribute grammars, tagless typed interpreters: https://github.com/mratsim/Arraymancer/issues/347#issuecomment-461009747
11:31:53krux02I don't know church encodings, but I do know embedded DSLs
11:32:09krux02I think Nim is the best language in the world right now to implement them.
11:32:15FromGitter<mratsim> I agree
11:33:33FromGitter<mratsim> I think it's also the best language to implement emulators/VM and JITs
11:33:45krux02not sure about that, never did it
11:34:07krux02but it can be
11:34:08FromGitter<liquid600pgm> writing a programming language was pretty fun in Nim, never finished it though
11:34:17FromGitter<liquid600pgm> I plan on getting back to the project after a while
11:34:19FromGitter<mratsim> all emulators and JIT need an opcode table
11:34:31krux02I once implemented an eDSL in Nim, where sums in einstein notation should be compiled into calls into blas.
11:34:42FromGitter<mratsim> Plenty use an intermediate codegen either in the host language or Python
11:34:52FromGitter<mratsim> ah I'm interested
11:35:05krux02so expressions like a[i,j] = x[i,k] * y[j,k]
11:35:05FromGitter<mratsim> I need to implement einsum for Arraymancer
11:35:30FromGitter<liquid600pgm> oh man I love the fact you can have multiple index arguments
11:35:44FromGitter<liquid600pgm> it's pretty useful for implementing tilemap-based worlds in game dev
11:35:56krux02well, it is just a minor thing
11:36:23krux02btw for tilemap I prefer to use vector types for indexing
11:36:32krux02mymap[vec2i(3,4)]
11:36:38FromGitter<liquid600pgm> why?
11:36:53krux02because I use vector types everywhere
11:37:07krux02for pos in vec2i(0) ..< vec2i(size):
11:37:30FromGitter<liquid600pgm> aah, that makes sense
11:38:01FromGitter<liquid600pgm> those minor things add up though, and make for a pretty sweet language
11:38:15krux02you can also have an overload for bilinear sampling mymap[vec2f(1.4,2.12)]
11:38:29FromGitter<mratsim> iirc someone proposed to create a nimgame channel as we have several game devs
11:39:43krux02well, I don't think we have enough of them to keep a nimgame channel active
11:40:01krux02also I don't want to be a lurker in 100 channels
11:40:06FromGitter<mratsim> :P
11:40:26FromGitter<mratsim> then I guess, a regular NimGame blog post with those kind of tips might attract more people
11:40:41narimiran+1
11:40:53krux02well the vec2i(0) ..< vec2i(size) loop works in all languages that I used so far
11:41:08krux02maybe not go
11:41:32krux02but it works in c++, scala and Nim
11:41:44*Trustable quit (Remote host closed the connection)
12:08:23federico3I think we need a nimgame lib more than a channel ;D
12:08:38narimiranfederico3: https://github.com/Vladar4/nimgame2/ ?
12:09:15narimiranone of the best documented nim packages from what i've seen. https://vladar4.github.io/nimgame2/
12:09:24FromGitter<liquid600pgm> I'm also creating a game engine for Nim, it's not finished yet though
12:09:41federico3something like that
12:10:56*NimBot joined #nim
12:27:42*i7sDream_ joined #nim
12:28:05FromGitter<liquid600pgm> was `generic` ever a keyword in Nim?
12:30:27*i7sDream quit (Ping timeout: 245 seconds)
12:33:20Araqyes I think so
12:33:57FromGitter<liquid600pgm> aah, that explains why the VS Code syntax highlights it red, as if it were a syntax error
12:56:11*i7sDream_ is now known as i7sDream
13:08:02*i7sDream quit (Quit: WeeChat 2.4)
13:11:50shashlickAnyone gotten nimble running on Android? Having libssl issues
13:16:05PMunchshashlick, I think couven92 might've done it
13:16:33PMunchBy the way, onyone know how to have a .. code-block formatted as Nim code in a documentation comment
13:17:19narimiranPMunch: what do you mean? what is the problem?
13:17:45PMunchI tried to do .. code-block:: Nim (both upper and lower case) but it just messed up the formatting
13:17:58FromGitter<mratsim> .. codeblock::nim o something like that, can never remember RST
13:18:43FromGitter<mratsim> .. code:: nim
13:18:57narimiranPMunch: stdlib uses exactly what you have tried....
13:19:05FromGitter<mratsim> https://github.com/mratsim/Arraymancer/blob/a4d3fc11f337f0c1837fdb19a34c3b7b7fa6c65c/src/tensor/higher_order_applymap.nim#L116-L136
13:19:13FromGitter<liquid600pgm> are you sure you indented the code block correctly?
13:19:41FromGitter<mratsim> and this is the output: https://mratsim.github.io/Arraymancer/tensor.higher_order_applymap.html#map%2CTensor[T]%2C
13:19:44narimiranyes, was going to ask exactly that. leave some spaces between ## and your not-indented stuff
13:19:46*stefanos82 quit (Remote host closed the connection)
13:20:06FromGitter<liquid600pgm> one space should be enough
13:20:24narimiranbut for you own sake, use two ;)
13:21:31PMunchnarimiran, aaah I just forgot to have a blank newline before my .. code-block :)
13:21:40narimiranheh
13:22:05narimiran(nim's) rst parser is quite picky and it doesn't forgive any mistakes :)
13:22:40narimiranonce i did ..code-block:: and it failed
13:22:44shashlickThanks @PMunch - wonder if @couven92 is on here
13:23:02shashlickI could statically compile in libssl but that doesn't feel right
13:23:24shashlickAlso am really wondering who will be compiling stuff directly on the end device
13:23:33narimirannow, how do i create theindex.html?
13:23:56PMunch--index:on or something like that
13:24:07PMunchIt's in the docgen documentation
13:24:37narimiranPMunch: thanks, found it
13:26:33narimiran...but there's no index still :)
13:28:27narimiranhahah, downloading https://nim-lang.github.io/Nim/theindex.html works like a charm for my use case :D :D
13:28:51FromGitter<kaushalmodi> narimiran: probably this might help: https://github.com/kaushalmodi/nim_config/blob/ffdefa859b9b9837dcb8fe643f04a75e5f98089b/config.nims#L249-L266
13:29:12narimirankaushalmodi: thanks!
13:29:41FromGitter<kaushalmodi> there was a hack involved as you see in that task
13:32:17*leorize joined #nim
13:33:27leorizeanyone used `norm` (the nim ORM)?
13:37:33AraqNOTE: appveyor is down/weird
13:37:46Araqdo not merge PRs until it's active again
13:52:46FromGitter<mratsim> Nim ORM is supposed to be Ormin
13:54:44leorizeThere's a new ORM called norm
13:55:42leorizeI'm having no idea how to search for a row via a field in the object though
14:11:58Araqnarimiran: actually Nim's RST parser is less picky than docutils'
14:12:08Araqbut it sucks :-)
14:12:26narimiran:D
14:16:54*clyybber joined #nim
14:18:04clyybberHCR talk got uploaded yesterday: https://www.youtube.com/watch?v=7WgCt0Wooeo
14:22:50clyybberdom96: And the corresponding HN thread: https://news.ycombinator.com/item?id=19738572
14:23:12FromGitter<jrfondren> "heavily biased C++ rant", exactly what my morning needed :)
14:26:16*solitudesf- joined #nim
14:28:43ZevvWhat's this Viktor Kirilov's real name?
14:28:51ZevvIs it someone we know from #nim?
14:28:57dom96oooh nice clyybber
14:29:01krux02clyybber, well sad to know that that the talk is already outdated
14:29:44FromGitter<mratsim> https://www.reddit.com/r/programming/comments/bgvai3/nim_first_natively_compiled_language_with_hot/
14:29:46krux02multimethods are on the way out
14:31:16leorizeZevv: it's someone that's currently hired with the grant from Status
14:31:19PMunchIs there a way to pass a list to a pragma?
14:31:28leorizeI believe I've never seen that guy on IRC
14:31:52FromGitter<jrfondren> like {.emit: [result, " = getenv(\"this?\");"].}
14:31:59narimiranZevv: https://github.com/onqtam
14:32:02FromGitter<mratsim> I'll redo the reddit post it's broken
14:32:07leorizePMunch: you can just use an array?
14:33:09*floppydh quit (Quit: WeeChat 2.4)
14:33:34FromGitter<mratsim> ah, playback on other websites is disabled
14:33:47FromGitter<mratsim> so https://www.reddit.com/r/programming/comments/bgvbym/nim_first_natively_compiled_language_with_hot/
14:34:36PMunchleorize, those are static length
14:34:47*Vladar joined #nim
14:35:12leorizeyou can use varargs for non-static length
14:40:26clyybberZevv: Its onqtam on github
14:41:44PMunchleorize, hmm. I'll have to look into that tomorrow
14:43:33*PMunch quit (Remote host closed the connection)
14:49:16livcdViktor Kirilov sounds so damn familiar
14:49:30FromGitter<mratsim> He is often in C++ conferences
14:49:42livcdI dont watch those
14:51:24livcdhmm there are still no videos from RubyKaigi
14:54:42*rnrwashere joined #nim
14:58:23*banc quit (Ping timeout: 246 seconds)
15:05:42*rnrwashere quit (Remote host closed the connection)
15:13:56*ober left #nim ("ERC (IRC client for Emacs 26.1)")
15:32:57*Trustable joined #nim
15:40:25*thomasross joined #nim
15:55:23*thomasross quit (Ping timeout: 258 seconds)
16:03:04*leorize quit (Quit: WeeChat 2.3)
16:05:03*floppydh joined #nim
16:06:53FromDiscord_<turbosoggy> Is nim production ready?
16:07:04*Vladar quit (Remote host closed the connection)
16:11:27Zevvdefine production ready. It is for me, but it might not be for you
16:13:45federico3https://lobste.rs/s/e0skes/nim_first_natively_compiled_language
16:18:32FromGitter<mratsim> It's used in atleast one hedge fund
16:19:30*Snircle joined #nim
16:19:53FromDiscord_<turbosoggy> I mean are there any un documented features, compiler errors, errors with the gc, etc
16:20:19FromGitter<mratsim> compiler errors are not really a problem for production
16:20:52FromGitter<mratsim> GC, we don't have GC issues since a year or more, apart from sometimes when we want to avoid it.
16:20:56shashlick0.19.x is a pretty good base
16:20:59FromGitter<mratsim> undocumented features, ye there are
16:23:41livcdhedge fund ?
16:24:00FromGitter<mratsim> yes, those funds with hundreds of millions of dollars
16:24:51livcdwhich one ? ^^
16:25:07livcdahh i think i know
16:27:59livcdI dont. Unicredit is not a hedge fund
16:28:15*krux02 quit (Ping timeout: 264 seconds)
16:28:33FromGitter<mratsim> Unicredit is a bank and I don't think andrea is using Nim in visible projects
16:30:11disrupteki'm busy atm, but can i get some feedback on #11088? i think i understand the issue pretty well, now, and it's more of a documentation-versus-code thing. the semantics are different from, say, Python, and that's fine if 1) we document them and 2) they work correctly with {.raises.} and 3) the compiler validates them correctly.
16:30:20FromDiscord_<turbosoggy> Maybe i didnt say it right but by compiler errors i mean the compiler produces the wrong code
16:30:36livcdmratsim: yeah that's why I was confused. But there was a repo on github @ unicredit
16:30:45livcdhttps://www.blackrock.com <- this gave me a massive headache
16:30:49FromGitter<mratsim> @turbosoggy, no such cases
16:30:55livcd(was just checking out hedge funds)
16:31:10livcdmratsim: you cant disclose the hedge fund ?
16:31:16FromGitter<mratsim> there are errors that are caught by clang/gcc
16:31:44FromGitter<mratsim> @livcd, I don't know, but there is a core Nim contributor in a fund.
16:32:04livcd(furiously searching)
16:32:06FromGitter<mratsim> and at Status we're using it for blockchain as well
16:33:17*krux02 joined #nim
16:34:41livcdok did not find who
16:38:00*curious joined #nim
16:38:20*curious quit (Client Quit)
16:38:27*krux02 quit (Ping timeout: 264 seconds)
16:38:36*krux02 joined #nim
16:42:58*Jesin quit (Quit: Leaving)
16:47:51*Jesin joined #nim
16:51:10*natrys joined #nim
16:55:37*rnrwashere joined #nim
16:57:12*harryrford joined #nim
16:57:21harryrfordhey is anyone here?
16:57:38livcdyes
16:58:35*neceve quit (Remote host closed the connection)
16:58:38harryrfordhow are you going
16:58:55harryrfordi have a few questions about nim, have you been in the space for a while?
16:59:43*jjido joined #nim
17:00:03harryrfordis the nim community growing?
17:00:20FromGitter<kaushalmodi> harryrford: everybody here would be somehow in the Nim "space" :)
17:00:27FromGitter<kaushalmodi> and it's an awesome and growing community
17:00:42harryrfordfantastic :)
17:02:45*Jesin quit (Quit: Leaving)
17:03:37ZevvI heard there are *dozens* of us :)
17:05:00Zevvnaah that was some time ago. It is a pretty active and friendly community. IRC is often busy, and when nothing is happening there is usually someone idling who can answer your questions
17:05:21*Jesin joined #nim
17:05:39ZevvI think it is mainly european, so when europe is asleep things might be a bit more slow
17:06:09FromGitter<kaushalmodi> US east coast here
17:07:57Zevvand the core devs are usually around here as well, which is great.
17:11:38harryrfordThats great, the more I read the more fascinated by this languageI I become. I see serious potential for this language to be used in production in the future, I hope it happens.
17:11:49harryrfordThats great, the more I read the more fascinated by this language I become. I see serious potential for this language to be used in production in the future, I hope it happens.
17:15:19Zevvthe future is here, for some of us. I have Nim code managing phone calls and presence info in a big dutch telco, running pretty deep in the core network
17:15:35Zevvpeople do cryptocurrency in Nim
17:17:02harryrfordthats awesome. so people have build a blockchain implementation in nim?
17:19:00FromGitter<alehander42> Livcd yeah I guess rubykaigi upload would take more time
17:19:07FromGitter<alehander42> They had a lot of talks
17:19:31FromGitter<alehander42> Ooh the Victor talk got traction on hn nice
17:19:48FromGitter<alehander42> Pretty cool
17:20:35Zevv#17, lets bring it to the top!
17:22:06*rnrwashere quit (Remote host closed the connection)
17:22:44*rnrwashere joined #nim
17:24:30livcdalehander42: i was on holiday and hoped it would be online when I returned :(
17:26:01*harryrford quit (Quit: Page closed)
17:27:34*rnrwashere quit (Ping timeout: 276 seconds)
17:29:18ZevvMaybe Narimiran should throw in his case-style explanation from last week before anyone starts complaining :/
17:29:45narimiranZevv: last week? you mean yesterday? :D :D
17:30:05ZevvOh I'm completely off, it's holidays here, I was convinced it was monday :)
17:30:53disruptekkayabaNerve: wanna share your {.async raises.} solution?
17:33:04narimiranwhen it comes to case (in)sensitivity, it feels like a quick sand. the more you explain that it is not a problem, the more people who haven't tried it complain that it is
17:33:56FromGitter<jrfondren> "it's less insensitive than Common Lisp"
17:38:29FromGitter<jrfondren> @Zevv, https://gist.github.com/jrfondren/a944af2448b8aa36a55e2341906f36c4 prints out the `str` string vertically. This works for UTF8. Is there a quick way I can take advantage of unicode.runeLenAt to match a Rune in an npeg pattern, without A) hardcoding runeLenAt's logic in the pattern, or B) giving up and rewriting npeg to work with runes from the get-go?
17:38:57FromGitter<jrfondren> I have random unicode garbage in this dataset, and unidecoding it makes it unparseable.
17:39:33FromGitter<jrfondren> but I know at least that the unicode will always appear in a certain sections of the data, so I could just match it potentially.
17:40:27FromGitter<jrfondren> what I'd like is a R atom that only matches non-ASCII runes.
17:41:59Zevvlet me see
17:44:26*Trustable quit (Remote host closed the connection)
17:48:07Zevvdoes http://p.zevv.nl/?b517 help you?
17:48:52dom96yay HN front page
17:50:04*rnrwashere joined #nim
17:50:28FromGitter<jrfondren> that's the hardcoding that I was wanting to avoid but... yeah I guess that's a lot easier than the alternative.
17:50:57FromGitter<jrfondren> thanks, I'll go with this for now
17:51:05ZevvI did some prototyping with various ways to handle unicode/utf8/runes, but they were all nasty - dependencies, performance, etc
17:52:43*rnrwashere quit (Client Quit)
17:53:21FromGitter<jrfondren> aye. and that'd be a shame since npeg's performance seems to be very good right now.
17:55:18FromGitter<jrfondren> in a benchmark pulling email senders out of a 400MB exim log, it does as well as Python: https://github.com/jrfondren/topsender-bench
17:55:46*rokups quit (Quit: Connection closed for inactivity)
17:56:45narimiranjrfondren `-d:release` already includes `--opt:speed`
17:57:10*stefanos82 joined #nim
17:57:34FromGitter<jrfondren> oh
17:58:24ZevvAh cool, npeg in a benchmark
17:58:45Zevvlet me do some profiling
17:59:17Zevvwhere do I find your exim_mainlog?
17:59:49FromGitter<jrfondren> well, it's a real log so it's got customer data in it :/
17:59:58Zevvah :)
18:00:03ZevvDamn, I only got postfix logs
18:00:05narimiranrot13 it, it will be ok :P
18:00:35Zevvyeah, that should do. I promise not to look :)
18:01:02FromGitter<jrfondren> I'll see about a dummy log in a few days.
18:01:33narimiranjrfondren what is the slowest part of the nim implementations?
18:02:37Zevvcool benchmark jrfondren. Also good to see NPeg does very good memory-wise
18:03:19narimirani.e. how is CountTable behaving?
18:03:21FromGitter<jrfondren> there's probably a lot of unnecessary string copying from the lines() iterator. 0.19.4's CountTable has a very slow sort but that's already fixed in devel.
18:03:23*Jesin quit (Quit: Leaving)
18:03:58narimiranyeah, please use devel for benchmarks
18:04:20shashlick@narimiran any plans for a 0.19.6?
18:04:27FromGitter<jrfondren> D is actually the winner on the benchmark, but my pcre wrapper that worked fine on Linux just segfaults on macOS. It is a mystery.
18:04:37narimiranshashlick: there are plans for 0.20 instead ;)
18:05:33shashlickokay, will be really cool if we could do one more 0.19.x release even if 0.20 comes out
18:05:41Zevvjrfondren: NonAt <- Graph - '@'
18:05:55narimiranjrfondren: btw, how come you didn't use collections.counter in your python version? (https://docs.python.org/3.7/library/collections.html#collections.Counter)
18:06:20FromGitter<jrfondren> I don't know Python well at all
18:06:50narimiranshashlick: yes, i see the point in that. i'll talk to Araq about that idea
18:07:38FromGitter<jrfondren> @Zevv ah, thanks
18:07:52ZevvI'm pushing 0.10.0 as we speak for the Graph fix
18:08:11shashlick0.19.x has already been maintained for 4 months (Sep - Jan) - having one more release will be a really good as a track record for stability
18:09:06narimiranshashlick: yes, 0.19 is "poor man's 1.0" :)
18:09:34shashlickif we can claim that every release is maintained for 9 months, will be a good statement
18:11:53shashlickthat's already better than rust, looking at their release history
18:13:26ZevvWell, I found an exim main log from herbomethairestaurant. I guess they have the http docroot a bit to high up in the filesystem
18:13:52federico3shashlick: or at least 6 months as long as the promise is kept
18:14:17*Jesin joined #nim
18:14:24shashlickif 0.19.6 comes out tomorrow, it is already 7 months from 0.19.0
18:14:36shashlickmaybe 9 months means 0.19.8 and that might be too much
18:15:03shashlickmaybe a release 0.x.0 + 2/3/4 bugfix releases
18:15:17*nsf quit (Quit: WeeChat 2.4)
18:19:35narimiranmake that 1.x.0 ;)
18:22:07*rnrwashere joined #nim
18:25:49*rnrwashere quit (Remote host closed the connection)
18:44:35*natrys quit (Quit: natrys)
18:49:13*rnrwashere joined #nim
18:49:18*rnrwashere quit (Remote host closed the connection)
19:09:23*jjido quit (Quit: Connection closed for inactivity)
19:29:12*floppydh quit (Quit: WeeChat 2.4)
19:32:27*rnrwashere joined #nim
19:35:06FromGitter<arnetheduck> er Araq so with the new `a/util`, `b/util` support, how do you explicitly pick a symbol from one of them? `a.util.symbol` would make sense..
19:35:33Araqimport a/util as au
19:35:37Araqau.symbol
19:36:57*rnrwashere quit (Ping timeout: 258 seconds)
19:37:41FromGitter<arnetheduck> ok :(.. and another question: what's the plan for all those system modules exporting symbols? `system/memory`, `system/ansi_c` .. are these now part of.. what.. the language standard lib? are they public symbols that are expected to be stable across nim versions?
19:38:34*rnrwashere joined #nim
19:39:59FromGitter<arnetheduck> I mean, there's `copyMem` which is a rename of `memcpy`, `zeroMem` which is `memset` but crippled, then there's `nimCopyMem` which.. uh.. implements `copyMem` with another public name? (I'm trying to figure out which name I should use to implement a builtin in nlvm.. llvm has optimized versions of these..)
19:41:07Araqthe problem is that some C environments pretend that memcpy is provided by the "OS" and so lack it when you don't have an OS
19:41:46Araqwhich makes no fucking sense but that's why we also have our own non-libc nimCopyMem that "always" works
19:42:17*rnrwashere quit (Remote host closed the connection)
19:42:19*rnrwashe_ joined #nim
19:42:42Araqand zeroMem is not a "crippled" memset, it's a fixed memset because you cannot get the argument order wrong
19:44:05FromGitter<arnetheduck> well, in nim, it's crippled because you can only fill with `0` - where in reality it could take a `byte` and not have the argument order issue, at least not the same way
19:44:38Araqanyhow, system/memory and friends are an implementation detail. for now
19:44:53Araqwe need a --leanSystem switch to complete the cleanup
19:45:11Araqor something better. I'm listening for ideas.
19:45:15FromGitter<arnetheduck> but what I'd like to understand is whether there's any pattern to follow here.. ie some of these pseudo-builtins from c are magics, some of them are ansi_c, some of them are `lib/core`, etc etc..
19:45:58*rnrwashe_ quit (Remote host closed the connection)
19:46:41Araqoh the pattern is maybe a bit complex but mostly sound. A proc is 'magic' if we need it to be builtin for the C/JS/VM target combination
19:46:42FromGitter<arnetheduck> I'd go with anything, as long as the rest of the lib is cleaned up at the same time.. there are now like 5-6 started refactorings and cleanups that each introduces its own style.. that's the hard part, for me at least, when doing nlvm
19:47:11Araqsome 'magic' procs also need their own special sem'check
19:47:35Araqfew are 'magic' simply because of legacy
19:47:42FromGitter<arnetheduck> so `system/ansi_c` for example being an implementation detail will soon turn into a backwards compat thing because of the public symbols it exports..
19:48:05Araqhuh? sytem imports it but doesn't export it
19:48:20FromGitter<arnetheduck> but `import system/ansi_c` is valid from user code so..
19:48:28Araqand pre 0.20 you cannot import system/ansi_c
19:48:37Araqwell maybe you can, I haven't tried
19:48:43Araqbut it wasn't documented
19:49:03FromGitter<arnetheduck> no, it didn't export the names, so it would have been a noop
19:49:14Araqah, right.
19:50:12*rnrwashere joined #nim
19:50:51*banc joined #nim
19:50:53FromGitter<arnetheduck> an inelegant solution is what c does, which reserves all symbols starting with `__` and `_X` for the "system", whatever that is, so that the namespace is not polluted
19:51:06FromGitter<arnetheduck> er, so the namespace is polluted in a predictable way
19:51:44FromGitter<arnetheduck> what's bothersome for larger projects is that you can break module a by adding a symbol to module b very easily.. it's worse when the std lib does it because of how it's imported everwhere
19:53:48Araqyeah but that's a different topic and also has a solution but I'm not sure we'll do anything about it for v1
19:54:17*rnrwashere quit (Remote host closed the connection)
19:55:07Araqanyway. the idea was that you import core/module but never system/module and that's now reversed
19:55:59FromGitter<arnetheduck> here's a little feather in the hat for you, btw: https://twitter.com/jcksie/status/1120693600759754753
19:56:23FromGitter<arnetheduck> that's where the whole nim_program_result stuff comes from :)
19:57:27Araqer thanks but it's your feather, I think.
19:58:47FromGitter<arnetheduck> well, it's the aggressively-dead-code-eliminating design of the language at work.. there's still a number of writeable, non-optional globals being output in "normal" mode, but for `os:standalone` that's the last of them, unless you start using exceptions
20:00:12Araqback to the problem: assuming that use --leanSystem (which doesn't exist) you shouldn't import system/assertions
20:00:44Araqbut instead std/assertions. I think.
20:01:43Araqand so system should import std/assertions. which shouldn't be imported unless you use --leanSystem. confusing.
20:02:39FromGitter<arnetheduck> confusing.
20:04:37Araqor we have an import std/assertions that always works
20:05:19*gangstacat quit (Quit: Ĝis!)
20:07:48FromGitter<arnetheduck> I actually have a local repo with a mosly-empty system.nim that I'm playing around with to test (nothing concrete yet).. it would be used for embedded systems, and the first test it would apply to symbols (for inclusion) would be that they have no runtime cost if not used (so no exceptions, no globals, etc). anything that has (hidden) cost you'd have to explicitly import. . another test would be that you should be
20:07:48FromGitter... able to have two versions of most things, so if I come up with a better assertion scheme, I should be able to import assertions2 etc.. this is important for versioning reasons, so that I can make changes without breaking old code (a bit like C++ has inline namespace which change the ABI symbol but work like nim and ... [https://gitter.im/nim-lang/Nim?at=5cc0c214a4ef097471f2bdfd]
20:08:24FromGitter<arnetheduck> well, I you won't be able to escape this issue without the user being explicit somewhere..
20:09:13*rnrwashere joined #nim
20:09:14FromGitter<arnetheduck> I don't believe in API/ABI-altering compile-time-flags in general, it doesn't scale.. the --leanSystem code wouldn't work with non-lean-system code and that would be a problem
20:11:03FromGitter<arnetheduck> we just had that discussion about -d:release for nimbus, and how it turns off checks.. but out-of-bounds etc when checks are on are part of a well-defined semantic of the language/library and alter the expected control flow - a try/except will swallow them for example. this means that instead of one semantic to test and search for security issues and weird flows, you end up with many... not good for reliability.
20:12:53Araqhmm? don't use -d:release, instead use --stackTrace:off --opt:speed/size
20:13:29Araqand then turn off more checks via .push for relevant procs that the profiler marked
20:14:52*[rg] joined #nim
20:14:55Araqbut Nim and to a large extend C++/Rust/<"system programming language"> have an inherent debug/release split that kinda sucks. the .NET/JVM platforms are much better at "one mode of operation for everything and everybody"
20:15:08*rnrwashere quit (Remote host closed the connection)
20:15:24*go|dfish joined #nim
20:15:33Araqafaict a JIT helps to accomplish this.
20:15:35*rnrwashere joined #nim
20:16:10FromGitter<arnetheduck> well, yeah, we can, but then we're fighting the language. what I'm saying is that `leanSystem` falls in the same category - we'll end up with some libraries expecting it and some not, and then you can't combine them -> doesn't scale.. we used bitops as another example
20:16:42Araqyou're definitely not "fighting" the language by not using -d:release
20:16:43*gangstacat joined #nim
20:17:12Araqcode that only "works" with --checks:off is broken code
20:19:37*rnrwashere quit (Ping timeout: 245 seconds)
20:20:22FromGitter<arnetheduck> it might be broken but only by convention, and where the less onerous thing is to write broken code - because the mechanism for delivering the breakage is the same as non-broken code (exceptions), stuff like a naked `except:` will hide the broken code and you have to make an extra effort (limit the scope of `except`) to find the breakage.. that makes it hard to trust other peoples code for example, reusing "public"
20:20:22FromGitter... libraries
20:21:58FromGitter<arnetheduck> it's a bit like in C - some code might be broken by optimization because it uses some UB that the compiler exploits. these kinds of bugs are extremely hard to track down later, when you have a larger project
20:22:58FromGitter<arnetheduck> how does a jit help with the "one mode" thing?
20:23:20*narimiran quit (Ping timeout: 258 seconds)
20:24:05Araqit helps because it's always turned on and can optimize your array bound checks etc based on the runtime profile
20:24:53shadowbaneThey can only optimize it to the point of tagging the branch as unlikely though, a JIT can't (usually) determine that bounds checks aren't needed at all.
20:25:02shadowbaneJava just always runs bounds checks.
20:25:14Araqnah.
20:25:49Araqit can hoist it out of loops, ok, a static compiler can do the same.
20:27:17FromGitter<arnetheduck> rust runs bounds checks always and relies on static elision and safe constructs to avoid them (ie iterator instead of access-by-array-index)
20:27:22FromGitter<arnetheduck> I suspect swift does the same
20:29:01Araqsure, but a JIT can better optimize/specialize code for the happy path
20:29:07FromGitter<arnetheduck> I'm considering to do the same in nlvm actually, to not allow disabling the checks.. but it's difficult, for said semantic reasons (doing so, I'd be breaking some previously working code that for example does `push boundscheck:on; try: a[i] except outofbounds: bla`
20:30:24FromGitter<arnetheduck> in the case of these checks that are (socially?) expected to not trigger, one would always optimize for the happy case, in a static compiler
20:31:04FromGitter<arnetheduck> basically, in the C case, you'd sprinkle with `unlikely` and in nlvm, I'll be doing the same (if I ever have time for it)
20:31:23FromGitter<arnetheduck> but in nlvm I have more powerful toys available to me, bringing down the cost
20:31:28AraqluaJIT did beat Fortran on one benchmark fwiw. But anyway, if the lib relies on exceptions to turn out-of-bounds into valid code, it's wrong code. The spec explicitly tells it's invalid.
20:32:17FromGitter<arnetheduck> the compiler doesn't. I tend to follow the compiler, not the documentation, when thinking about practical application of the theory :)
20:32:57Araqwell I can change the compiler :P
20:33:04FromGitter<arnetheduck> and jvm sometimes beats c++ because it can devirtualize more aggressively and specialize functions for specific instances
20:33:43Araqexactly. but the thing is, this is all theoretical. You dream up of problems in unknown libraries that you end up using in your mission critical software
20:34:22FromGitter<arnetheduck> well, it's not theoretical in our case. we had bugs swallowed by it and engineers scratching their heads :)
20:34:37Araqwhat?
20:34:38*rnrwashere joined #nim
20:34:48FromGitter<arnetheduck> aggressively swallowed exceptions
20:35:14Araqbah
20:35:17FromGitter<arnetheduck> and `-d:flag`-dependent library conflicts
20:35:36*slugm quit (Remote host closed the connection)
20:36:07AraqI hate this.
20:36:28AraqNow I'm out of arguments and need to change the compiler.
20:36:30FromGitter<arnetheduck> panicing on those occasions btw would lead to more efficient code because you could prove it statically to be exception-free and elide the exception bloat :)
20:36:43AraqI know.
20:37:11AraqI still like my "quirky exceptions" best fwiw.
20:37:26FromGitter<arnetheduck> I like it for its boldness :)
20:39:40AraqI thought about injecting 'if error: return' for procs with the IO .tag
20:40:08Araqthen the check is paid for at proc entry but not after every proc call
20:42:34*rnrwashere quit (Ping timeout: 276 seconds)
20:42:58Araqa related problem is that people use -fno-exceptions and say "yay, smaller and faster code" but that's because they turned the exceptions into a panic, not into an if-cascade. But at the same time panic is often all you need when you write an application so this -fno-exceptions switch is very useful...
20:43:46Araqso under this new "fixed C++ exception handling" proposal you would lose a useful switch and turn everything into a shitty if-cascade instead.
20:44:37FromGitter<arnetheduck> its `-fno-exceptions` I'm after actually, in a sense.. contradicting my own arguments above about one-way-only, yay!
20:45:33FromGitter<arnetheduck> but it's a bit less bad, because code that's written to be exception-free works with exceptions also
20:47:21Araqnot sure what you mean. IMO the code is broken anyway and there is no language that lacks the nasty stack unwinding feature, even C has setjmp and signal handlers
20:47:59AraqGo has defer and panic and Rust also offer(ed) stack unwinding
20:48:17*xet7 quit (Quit: Leaving)
20:50:34Araqbtw with -d:nimQuirky I turn index-out-of-bounds into fatal errors
20:51:09FromGitter<arnetheduck> so why not do it for normal nim too? afair the manual allows it so you can always point to it and say told you so :)
20:52:06Araqyeah, consider it done for v0.20 (I hope?). It might be some work to adapt the tests.
20:52:44FromGitter<arnetheduck> ooh nice.
20:53:26Araqalso, I plan to do -d:safety vs -d:performance and make -d:release a legacy
20:54:01Araqtoo many people don't understand -d:release
20:54:41FromGitter<arnetheduck> well, with those names, -d:performance will become the -d:release.. why would you *not* want performance?
20:55:14Araqhmm good point
20:56:47FromGitter<arnetheduck> have you measured recently btw the cost of `--checks:on`? afair, the biggest perf-killer in nim is `--linetrace` - that's like 2-3x slowdown on `--opt:speed`
20:57:14AraqI haven't but that's what I hoped for ;-)
20:57:34Araqthe integer overflow checking is hard for the C backend
20:57:45FromGitter<arnetheduck> I can imagine that if you turn those checks to panics it shouldn't be too bad
20:58:55FromGitter<arnetheduck> well, it's made slightly harder I think by all the `NI` casts - I think they confuse the c compiler - it's one of the differences I've seen in the generated llvm code when comparing..
20:59:42Araqnever seen these turn into something in the produced assembler code
20:59:49FromGitter<arnetheduck> specially bools - when values are guaranteed to be 0/1 the optimizer can reason about them better
21:00:17FromGitter<arnetheduck> they don't turn into something, the lead to missed-optimizations mainly
21:00:46Araqstrange but ok
21:00:58disrupteki like quirky. what's the "fixed C++ exception handling" proposal?
21:01:41AraqHerb Sutter's superior new way of doing exceptions by if checks on a misused CPU flag
21:01:43FromGitter<arnetheduck> like when a bool is a char (like in c), it has 256 possible values for the optimizer, and it has a harder time proving things.
21:01:54disruptekoh right.
21:02:03Araqwe map bool to C++'s bool.
21:03:08disruptekcan we talk about the #11088 issue? i just want to know if it is intentional.
21:03:08FromGitter<arnetheduck> when you extend that same logic to `NI` it gets even worse.. sometimes it's fine, but sometimes I've seen some pretty big differences - it's one of the reasons why I can get better perf in nlvm over c, because I can be a bit more specific
21:04:06FromGitter<arnetheduck> well c++'s bool is a #define in c, just like enum is an int
21:04:09disrupteki am going to be using nlvm, btw -- thanks for that. i am building a pipeline with klee and running everything in graal, so i'm all about the IR. :-)
21:04:54FromGitter<arnetheduck> still hoping that someone will do the right thing and add windows and osx support :)
21:05:51disruptektoo many people use -d:release, period.
21:05:58*banc quit (Ping timeout: 276 seconds)
21:06:39FromGitter<arnetheduck> if you're all about the IR you'll also be sad to know that nlvm generates setjmp for exceptions instead of doing it properly *hint, hint*
21:06:55Araqouch
21:07:11disruptekwell, i still don't understand exceptions in nim, so i'm not too worried about it yet. :-D
21:07:27disrupteki mean, i get it, i just am not convinced it's as intended.
21:07:32Araqdisruptek: I don't understand the issue
21:07:44*banc joined #nim
21:08:59FromGitter<arnetheduck> yeah I know.. sad and embarrassing. but now it should be plausible to fix, because it no longer has to go by similarity-to-c-backend with the test suite mostly passing. the new skipTests flag will help with that.
21:09:02disruptekthere doesn't seem to be a way to dominate an exception type in the except: clause and still make use of the `as error:` binding as the original type -- it gets shadowed as the dominating type.
21:10:26disruptekthen if you re-raise it, you're raising a dominating type which means it poisons your {.raises.} to be, perhaps, broader than you intended. which could be fine, if that's the semantic we want. i just don't know.
21:10:36disruptekit's not, fwiw, the way it works in python.
21:11:05Araqsee this is where it becomes super-confusing
21:11:27Araqdo you talk about the .raises effects or about the order of 'except' clauses?
21:11:38disruptekwhen i say that if you re-raise it, you're raising a dominating type, you're not /actually/. the type doesn't change. but the {.raises.} has to, because nim is split-brained about the type of the exception.
21:12:52disrupteki'm talking about both. i think nim should tell me when i'm dominating a later clause in the stmt list, for one thing. and if it won't do that because it's not the job of nim, then i feel like we should document that {.raises.} is code in that it only works if you correctly order in contents. ie. you need to know the exception inheritance tree and encode it into every proc.
21:13:11disruptekthere are good reasons to do that. but nim is missing one leg of the stool right now, imho.
21:13:51*revere quit (Ping timeout: 264 seconds)
21:14:12AraqI'm afraid I'll reply tomorrow properly.
21:14:32disruptekit's fine, i just wanted to know if there was there there or if i was just missing something. ;-)
21:14:50AraqBut a .raise list like [Exception, ValueError] conveys the idea that the compiler assumes the worst and it can raise any Exception
21:15:02Araqbut it also computed that it definitely can raise ValueError :P
21:15:17disruptekthat's an impossible raise list, currently. Exception dominates ValueError. you'll get a warning if it compiles.
21:15:48*revere joined #nim
21:15:56Araqmaybe if you wrote this list explicitly
21:16:05Araqif it's computed, it's a valid outcome
21:16:27disruptekit may be valid, but if so, i wish it would compile and/or not create spurious warning messages.
21:18:04Araqbut why? if you wrote it down explicitly, you were confused
21:18:14Araqas Exception dominates ValueError
21:18:38Araqthe compiler is allowed to communicate its confusion but the programmer should know better
21:20:24disruptekthat's fine, if every time i write a {.raises.} i need to express a hierarchy of exceptions that will not change... it just means that if i move an exception type around in the hierarchy, i may have to modify raises everywhere. that's fine. but it's not really clear from the documentation, and the error messages aren't helpful. plus, the poison issue...
21:20:47disruptekthe compiler should not be confused about exception inheritance, should it?
21:22:49Araqno it shouldn't. but is it?
21:24:00disrupteklet me put it this way... if i use an except Exception: to catch a ValueError and then re-raise it, does the compiler really think that the method can raise Exception? because that's the way {.raises.} works right now, and it means that it's hard to both use dominating clauses and have functions not raise broader and broader exceptions, even when they provably do not.
21:24:35Araqah I see.
21:24:38disruptekand i still cannot do anything ValueError specific in that Exception clause, which makes it pretty weak in terms of utility.
21:26:22disrupteki still want to emphasize that it's not that the semantic is necessarily wrong, it's just different and not clearly communicated. it's also not clear if it's working as intended.
21:26:39Araqwell I need to investigate. there is no logic in the compiler that says "oh, it says except E so I'm gonna add 'E' to the .raises list"
21:27:21disrupteki think maybe re-raise is getting wrapped and unwrapped or something. i dunno. i haven't looked at the compiler, i've only tested it with code.
21:28:04disruptekor, perhaps more likely, raise creates an effect that propogates upwards, so when it's called with an Exception type, that's what bubbles up.
21:28:36Araqwell yes, that's what 'raise' does
21:29:36disruptekso, in an Exception as foo: clause, raise foo will raise Exception. even if the original type is ValueError. and we can catch that `raise foo` as a ValueError upwards in the stack.
21:29:49AraqI still consider the .raises effect system business a largely failed experiment btw
21:30:32disrupteki think it could work really well, we're just missing the piece that the compiler can provide to ensure we don't create logic bugs when changing exceptions. it's almost complete, to my eye.
21:32:36Araqeven assuming it works 100% perfectly, it's mostly sophistry.
21:32:59disruptekwhy is that?
21:33:54Araqin practice I only care about can-raise vs cant-raise and can-raise should be reserved to IO which are pervasive failures that have some hope of being re-tryable
21:34:07*iLiquid quit (Quit: iLiquid)
21:34:48disruptekexactly. this is a very real scenario.
21:35:19Araqand then I don't need static checking for it, frankly.
21:35:40disrupteki have some api code that makes async requests. failures can occur at the network level, due to an api failure, or due to response parsing failures.
21:35:42AraqI know which procs do IO
21:36:07disruptekthe reason to have static checking is that the compiler is smarter than we are. :-)
21:36:13Araqthe compiler can help with that but it's not required and the compiler could instead check for more important things
21:36:52disruptekwell, it doesn't currently check for except: clauses that will never get executed because they are dominated in the same expression.
21:37:09disruptekso bikeshedding {.raises.} seems a little misplaced. :-P
21:37:32Araqas I said, let's assume a "perfect" implementation.
21:37:52disruptekokay. do you pretty dominating clauses to work like python? or nim?
21:37:56disruptek^prefer
21:38:09Araqthen I would still reject it based on my experiences.
21:38:30Araqexcept Exception: echo "A"
21:39:00Araqexcept ValueError: echo "B" # invalid code, the checks are performed one after the other
21:39:27disruptekthat's a good improvement for nim, yes.
21:39:46Araqthat's how it's done in Nim and also how it's done in Python
21:39:48Araqafaik
21:39:56disruptekwe don't error on that code.
21:40:05disruptekafaik
21:40:23Araqand Python does?
21:40:59disrupteki dunno, but the python vs. nim comparison isn't about detecting dominance.
21:41:31disruptekit's about the fact that in python, if you except Exception as foo: then `foo` has whatever type it was when thrown, not Exception. not so in nim.
21:42:18disruptekin nim, whatever you catch gets painted with the dominating exception type brush. and that paints right into {.raises.} (which we aren't talking about)
21:43:08disruptekmaybe nim's way is better. so far, i am not loving it, but i can be taught!
21:43:16Araqer ...
21:43:35Araqexcept Exception as foo: # surely foo has the type Exception, what else?
21:46:34disrupteksometimes we want to operate on several exceptions -- a type of exception that share the same parent, eg. IOErrors -- identically, in the same block. nim currently requires me to write code that operates on IOErrors in those blocks. this part is fine, and as it should be. but IOErrors may be defined with sub-types and thrown, and the exception i get to work with is only the IOError, not the subtype
21:46:40disruptekcaught by the broader, dominating except IOError:
21:47:20disruptekexcept Exception as foo: is type Exception in nim, but might be ValueError in python.
21:49:46disruptekhere's an example of how python does it: https://gist.github.com/disruptek/3b173a17989c0c6047908cd72832264e
21:51:35disruptekdoes that help?
21:54:06disruptekgotta split, bbiab.
22:02:08AraqPython has no static typing
22:02:50FromGitter<deech> Are there any plans for separate namespaces for compile/run time? It would be nice if I could do something like: ⏎ ⏎ ```proc f(): auto {.compileTime.} = discard ⏎ proc f(): int = 100``` ⏎ ⏎ Although that would make invoking more complicated. [https://gitter.im/nim-lang/Nim?at=5cc0dd0a990feb4518f899e6]
22:02:58clyybberkrux02 are you there?
22:03:23*solitudesf- quit (Ping timeout: 245 seconds)
22:04:13FromGitter<dom96> Araq: is that really how Nim works?
22:04:35FromDiscord_<!!Liam is Unlucky> 'trying to get glfw to work with this https://github.com/ephja/nim-glfw
22:04:35FromDiscord_<!!Liam is Unlucky> I get, the output, could not load: glfw3.dll
22:04:35FromDiscord_<!!Liam is Unlucky> anyone know
22:04:54FromGitter<dom96> You need that DLL beside your exe
22:05:10FromDiscord_<!!Liam is Unlucky> oh ok
22:14:09Araqdom96: I don't know what "really how" means and I'm sleeping
22:14:58FromDiscord_<!!Liam is Unlucky> hmmm, I put it in the same directory as my exe, but still get the same output
22:15:39*lritter quit (Ping timeout: 258 seconds)
22:21:25FromGitter<matrixbot> `noonereally` is nim more portable than golang?
22:21:35FromGitter<matrixbot> `noonereally` being c api?
22:33:35FromDiscord_<exelotl> yes
22:35:18federico3I have to say --hints:off makes compilation nicer
22:44:23krux02clyybber, sorry not today anymore, I was offline. I will be online in 7 hours again
22:44:29*krux02 quit (Remote host closed the connection)
22:46:26*vlad1777d__ joined #nim
22:47:20clyybberkrux02: Ok, good night
22:47:34*clyybber quit (Quit: WeeChat 2.4)
23:00:11*WilhelmVonWeiner quit (Quit: leaving)
23:01:00*WilhelmVonWeiner joined #nim
23:01:19*stefanos82 quit (Remote host closed the connection)
23:09:48*[rg] quit (Quit: Leaving)
23:15:50*Jesin quit (Quit: Leaving)
23:24:38FromGitter<kayabaNerve> disruptek: You still there?
23:25:52*Jesin joined #nim
23:26:22FromGitter<kayabaNerve> My async raises code is part of a more expansive macro which stops exception bubble up. It creates function copes and strips out the async code for sync code.
23:28:36FromGitter<kayabaNerve> Alone as an async raises macro, it'd only work if your async function never calls any async procs itself, or you wrap every async call in a try: except: block.
23:29:06FromGitter<kayabaNerve> If you're still interested, https://github.com/MerosCrypto/ForceCheck
23:32:13*gangstacat quit (Ping timeout: 276 seconds)
23:35:30disruptekkayabaNerve: thanks, i'm sure we have run into the same problems, so i appreciate a shared solution as well. ;-)
23:36:56disrupteki don't see what static typing has to do with it.
23:38:34FromGitter<kayabaNerve> I don't see why you'
23:38:41FromGitter<kayabaNerve> *you're bringing up static typing.
23:38:49FromGitter<kayabaNerve> I'm guessing if my lib mentions that, it's a typo :P
23:39:32disruptekno, it was something Araq had mentioned in reply to the earlier convo re: exceptions.
23:40:20FromGitter<kayabaNerve> Oh, sorry.
23:44:07disruptekso if i'm reading this readme right, you basically munge the async functions so you can properly do exception bubble up for the purposes of compilation only? just to detect/generate a sync function with a proper raises?
23:45:46FromGitter<kayabaNerve> This macro is meant to stop exception bubble up and force explicit error handling at every level.
23:46:04FromGitter<kayabaNerve> It's an overkill solution to a lack of error handling in my project that's served quite well.
23:46:17FromGitter<kayabaNerve> A benefit is that we get a proper raises on async procs.
23:46:31disruptekdoesn't sound like overkill to me; you already have to do this to deal with async properly. that's the problem. ;-)
23:47:03FromGitter<kayabaNerve> We create two duplicates which Nim removes as dead code. The first has all of its awaits replaced with waitFor, async removed, and every raise replaced with discard.
23:47:39FromGitter<kayabaNerve> That stops the bubble up. The second has the same async mods, but the raises are untouched. That has the raises added.
23:47:45FromGitter<kayabaNerve> Your original function has no raises added.
23:48:12FromGitter<kayabaNerve> ```proc () {.async.} = ⏎ echo "Hi"``` [https://gitter.im/nim-lang/Nim?at=5cc0f5bce416b84519d5c839]
23:48:46FromGitter<kayabaNerve> That should compile with a blank raises. Async will force that to have Exception added to the raises. It will compile with a blank forceCheck.
23:49:30disruptekright, so you use the sync version to detect the raises and then add them to the original function?
23:50:08FromGitter<kayabaNerve> The original function never gets any raises as it will never compile with any meaningful raises.
23:50:48FromGitter<kayabaNerve> The sync version with untouched raise statements gets the raises pragma.
23:50:48disrupteki mean, the second one that "has the raises added".
23:51:02disruptekright.
23:52:10FromGitter<kayabaNerve> As long as you wrap your async calls to stop bubble up, the larger purpose of the macro, it enables adding a meaningful raises pragma to async functions.
23:52:51disruptekyeah, it's useful, thanks. right now my async stuff is just a forest of try/except: and it's making me grumpy.
23:53:33FromGitter<kayabaNerve> I'm happy if it helps