<< 28-11-2018 >>
00:45:21*ftsf joined #nim
00:45:22*Notkea quit (Read error: Connection reset by peer)
00:45:49*Notkea joined #nim
02:01:32*zachk quit (Quit: Leaving)
02:36:50FromGitter<gogolxdong> Is there any AEAD implementation in Nim?
03:01:00*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
03:07:41*banc quit (Quit: ZNC - http://znc.in)
03:11:42FromGitter<arnetheduck> @gogolxdong https://github.com/cheatfate/nimcrypto implements GCM..
03:17:44*theelous3_ quit (Ping timeout: 250 seconds)
03:24:09*banc joined #nim
03:37:40*abm quit (Ping timeout: 250 seconds)
03:39:21FromGitter<gogolxdong> yes, how about AEAD
03:40:15FromGitter<gogolxdong> AEAD_AES_128_GCM AES-128 with a 16-octet authentication tag
03:40:46FromGitter<gogolxdong> AES Galois/Counter Mode (AES-GCM) [GCM] is a family of AEAD algorithms based upon AES.
04:02:38*leorize joined #nim
04:11:37FromGitter<gogolxdong> have no idea of how they combined.
04:13:27*leorize quit (Quit: WeeChat 2.3)
04:14:31*leorize joined #nim
04:20:00*leorize quit (Quit: WeeChat 2.3)
04:52:44*ah_ joined #nim
04:53:09*ah_ quit (Client Quit)
04:58:53bozaloshtshIs it impossible to have a table with a case object as a key?
04:59:39bozaloshtshsorry, TableRef. Table[A, A] works where A is a case object
04:59:46bozaloshtshthat's a strange restriction.
05:00:13bozaloshtshif I try newTable[A, A]() I get "parallel 'fields' iterator does not work for case objects
05:01:35*nsf joined #nim
05:04:46bozaloshtshIs there a workaround for this or am I just Not To Use a case object as a table key?
05:13:34xacebozaloshtsh: im a bit too busy to actually help, but iirc you need to `import hashes` and proc hash(x: A): Hash = result = x.KEY.hash \n result = !$result # note that !$ finishes the hash
05:14:03bozaloshtshxace: I implemented a hash for it, there's a different compile error for that (one that makes sense)
05:15:56xacehmm, i cant gather another guess at your problem atm. im a beginner myself and im very busy atm... sorry
05:16:35bozaloshtshno worries, this seems to be a pretty deep issue, or there's some implicit restrictions on case objects I can't find clearly mentioned anywhere in the docs
05:20:58bozaloshtshhttps://ptpb.pw/3ke-/nim
05:29:17*dddddd quit (Remote host closed the connection)
05:31:16bozaloshtshfiled an issue on github
05:41:23FromGitter<gogolxdong> Is there a statement as 1..12.toSeq?
05:53:17*narimiran joined #nim
05:53:58bozaloshtshgogolxdong: (1..12).toSeq should work
06:04:59narimiranbozaloshtsh: you must put it in front: `toSeq(1..12)`
06:05:21narimiranbut there is an issue/PR which would allow it after an iterator
06:06:17bozaloshtshhmm, it seems that with the devel branch, (1..12).toSeq works, but on master, (1..12).toSeq gives me a stange type error
06:06:38narimiranoh, it is already merged in devel? i wasn't sure
06:07:08bozaloshtshI'm avoiding the devel branch currently, there seem to be some very strange regressions in codegen
06:07:31narimiranbozaloshtsh: don't avoid it. report those regressions!
06:07:51bozaloshtshtoo tired to squint at the generated C code, perhaps tomorrow :p
06:08:48bozaloshtshI need to set up choosenim (or whatever it's called) so that I can switch between compilers quickly for situations like this
06:09:01narimiranyep, choosenim is the way to go
06:14:51ldleworkor dive into NixOS :)
06:19:30FromGitter<gogolxdong> Is there a reference shows how AEAD_AES_128_GCM works?
06:26:25FromGitter<gogolxdong> Do I have to understand how AES, GCM and AEAD works separately first?
06:39:45*Vladar joined #nim
07:06:51*krux02 joined #nim
07:16:40*narimiran quit (Remote host closed the connection)
07:16:45*ftsf quit (Quit: Leaving)
07:18:26*jjido joined #nim
07:22:46*leorize joined #nim
07:40:46*krux02 quit (Ping timeout: 250 seconds)
07:53:08*NimBot joined #nim
07:55:22*krux02 joined #nim
08:02:05*jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:09:36*krux02 quit (Ping timeout: 246 seconds)
08:19:42*krux02 joined #nim
08:25:10FromGitter<alehander42> Araq, very cool
08:25:29FromGitter<alehander42> but I was under the impression one looks at the first several iterations in fixpoint analysis too
08:26:24*krux02 quit (Ping timeout: 246 seconds)
08:28:25FromGitter<alehander42> but overally, pretty cool, that it works for many cases of even raw pointers and various owners
08:29:15Araqnot "first several iterations", it's exactly:
08:29:20Araq- consider 0 iterations.
08:29:24Araq- consider 1 iteration.
08:29:28Araq- consider 2 iterations.
08:29:37Araqif I understood it correctly
08:29:38FromGitter<alehander42> on the other hand I imagine a similar system preventing only nil refs should be a bit simpler, as they are supposed to point to either nil or to a valid value, as the gc keeps it alive, so you maintain a flag, not a set
08:37:31*krux02 joined #nim
08:43:19*stefanos82 joined #nim
08:45:20FromGitter<alehander42> yes, you're right about the loops
08:45:40FromGitter<alehander42> the interesting thing is they use the same scheme for static functions
08:45:47FromGitter<alehander42> static variables *
08:46:03FromGitter<alehander42> in functions
08:50:54FromGitter<alehander42> on the other hand, what would happen to ref in nogc ? i read that the idea was to be a rc pointer?
08:52:22FromGitter<alehander42> in this case, it still becomes invalid/nil mostly because of assignment/branches, not because of the ref-ed object disappearing
08:56:14Araqcan't really follow you
08:57:53FromGitter<alehander42> my point is, if this is true, one can replicate a similar impl for ref-s with an enum instead of a set : nil / maybenil / safe (or a set with only two elements: nil / safe ) and with a bit simpler rules for changing those enums
08:58:42FromGitter<alehander42> and even a `maybenil` assumption for functions returning a ref
08:59:53FromGitter<alehander42> after all, one can use `ref T not nil` if the system can prove a function returns a valid reference
09:00:43FromGitter<alehander42> (but I guess you think of a more general ptr/owner safety checking, I am only thinking about the refs thing)
09:01:16*Vladar quit (Remote host closed the connection)
09:01:38Araqoh yeah, but note that the paper also mentions not-null inference/annotations
09:02:10Araqyou're right that it makes the "pset" easier.
09:02:57FromGitter<alehander42> yeah, because gc/rc prevents some cases of dangling, I should've phrased it like that
09:03:36AraqI'll tinker with this and see if it helps with "index out of bounds" detections
09:04:31Araqcause that's the more general problem, you can map "use after move" and "access of a nil" to array indexing problems
09:06:27FromGitter<alehander42> but for the annotations, they say `by default we assume that a function returns values that are derived from its arguments.` which is a bit more liberal than I like: they say later that they just teach people to not use globals/etc if they can, but it still happens
09:06:53FromGitter<alehander42> that's why I'd just assume it might be nil/invalid without annotation and make the caller do a check
09:07:00Araqso what, we have .noSideEffect for that and can be precise
09:07:43FromGitter<alehander42> hm yeah, for pure functions we can be precise too, but for the general case we can assume unsafety
09:08:37FromGitter<alehander42> so 3 cases: pure functions can be proved, functions returning `not nil` can be assumed to be safe, others can be assumed to return unsafe value
09:09:54FromGitter<alehander42> yeah, i can see it for nil, but how is use after move similar
09:10:18FromGitter<alehander42> if we imagine that a variable is a collection of its value and after move it becomes empty?
09:10:35Araqvar x = move(y); use(y); --> var x = y; setLen(y, 0); y[0]
09:11:08FromGitter<alehander42> yes
09:12:25FromGitter<alehander42> well in general for indexing pset <=> max valid index
09:13:42FromGitter<alehander42> which might be hard to analyze, I mean you quickly get to symbolic math (e.g. accessing 3*n elements of seq[with n] + seq[with n] )
09:18:07Araqhttps://github.com/nim-lang/Nim/blob/devel/compiler/guards.nim#L833 sure it gets messy ;-)
09:20:45Araqbut symbolic math is fun and it's not clear how many rules you actually need in practice to cover what the average programmer is capable of writing
09:21:27Araqand runtime array index checking sucks as much as nil deref bugs
09:36:12*Ven`` joined #nim
09:40:16*Ven`` quit (Ping timeout: 244 seconds)
09:43:04*Ven`` joined #nim
09:47:44*Ven`` quit (Ping timeout: 250 seconds)
09:56:53*Ven`` joined #nim
09:58:39*endragor joined #nim
10:05:30FromGitter<alehander42> yeaah
10:05:49FromGitter<alehander42> I asked @zah once about the guards stuff, it seemed very advanced :D
10:05:59FromGitter<alehander42> that's kinda true
10:06:23FromGitter<alehander42> for pseudolang I planned simple O[n] annotations as a langdev experiment
10:07:14*dom96_w joined #nim
10:07:34*dom96_w quit (Changing host)
10:07:34*dom96_w joined #nim
10:07:38*dddddd joined #nim
10:08:06dom96_wPMunch: That's a good idea about a Small Langs devroom (from yesterday). There is actually a devroom for "minimal languages", maybe we should apply for an "emerging languages" devroom next year
10:08:09FromGitter<alehander42> and on "paper" it looked feasible to symmath through some of the common scenarios: one still can't solve hard problems, but it can learn to recognize a lot of solvable summation/product/even recurrent cases
10:08:55FromGitter<alehander42> at least from what i remember about the O math from algo class exercises
10:10:38FromGitter<alehander42> but you also kinda need a lot of interprocedural analysis which is more feasible in a limited language/small programs
10:10:38FromGitter<AchalaSB> how to call Async Function inside main function.. ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ `httpRequest` is my main function [https://gitter.im/nim-lang/Nim?at=5bfe699eb6c07010529e059f]
10:10:59*floppydh joined #nim
10:11:55dom96_wYou're not giving it the correct arguments it seems
10:12:07dom96_wnothing `async` specific about it though
10:12:54*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:13:39FromGitter<AchalaSB> My main function is not of the type `async`. My question is can I call that inside async function call?
10:13:51leorizeyou can
10:14:11AraqwaitFor asyncProc()
10:14:32Araqdon't use asyncCheck asyncProc(). Right?
10:22:04FromGitter<AchalaSB> Here is my code. Where I have to change my code. ⏎ By changing asyncCheck into asyncProc, got errors ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5bfe6c4cf849b222e0b7e132]
10:23:57leorizeyour error is right there
10:24:16leorize`httpRequest` take a `FunSettings` as it's first argument
10:24:31leorizebut you call it with an `AsyncSocket` instead
10:27:34FromGitter<alehander42> @AchalaSB where are FunSettings and FunResponse coming from ?
10:28:00FromGitter<alehander42> they seem to be your own types, but you're not creating a FunSettings anywhere in server
10:28:15FromGitter<AchalaSB> Its user defined types
10:28:31*Ven`` joined #nim
10:28:39FromGitter<alehander42> ok, so where are the settings in proc serve?
10:28:59FromGitter<alehander42> I guess you have to load them from somewhere(a file or something else?)
10:30:25FromGitter<AchalaSB> The proc serve is to load my file in server
10:31:51FromGitter<alehander42> great, but you still need those FunSettings , right?
10:32:01FromGitter<alehander42> where do they come from
10:32:08FromGitter<AchalaSB> Then how can I call my function in server synchronsly?
10:32:24FromGitter<AchalaSB> how can I call FunSetting in my proc serve
10:32:56FromGitter<alehander42> well, it's not a function, FunSettings is an object: you need to create it and fill it with values somewhere
10:33:01FromGitter<alehander42> that's why I asked you
10:34:16FromGitter<AchalaSB> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5bfe6f28b6c07010529e2a8b]
10:34:43FromGitter<alehander42> ok, and now you need to create it and actually pass it to httpServer, right?
10:34:54FromGitter<AchalaSB> yes
10:36:01FromGitter<alehander42> ok, and fix your other arguments of httpServer
10:38:32FromGitter<alehander42> in `socket.client.httpRequest( socket.address)`, you need to pass the FunSettings value and see what are socket.client (AsyncSocket) and socket.address(string) types : httpRequest *must* match those types, always look in the errors a bit, they help
10:41:58FromGitter<AchalaSB> you mean `asyncCheck socket.client.httpRequest(FunSetting.socket.address)` or `asyncCheck socket.client.httpRequest(settings: FunSetting, socket.address)`
10:43:07leorizeyou have to create a new `FunSetting` object
10:43:08FromGitter<alehander42> well, this depends on your logic: I don't know which of those 2 addresses you need. I guess the first one?
10:43:14FromGitter<alehander42> and use waitFor not asyncCheck
10:43:32leorizeuse `await`
10:43:38leorizesince that func is an async func
10:43:40FromGitter<AchalaSB> tried with this also `proc serve*(server: Server, port= 8545, settings: FunSettings, address=""):Future[void] {.async.} = `
10:46:12FromGitter<alehander42> ok , but then you need to pass the settings to your serve functions. you really need to make sure you have a good plan about this program: are you sure you know why you need the `settings`
10:49:21FromGitter<AchalaSB> I need settings to fetch my file/file path
10:55:16*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:01:07FromGitter<gogolxdong> result of `sha256.hmac(salt, secret) ` is different from ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ which in Go, anyone knows where the trick is? [https://gitter.im/nim-lang/Nim?at=5bfe75737d26db1e830b6e4b]
11:07:52FromGitter<mratsim> in nimcrypto?
11:07:57FromGitter<gogolxdong> yes
11:09:28FromGitter<mratsim> is it sha3_256, sha2_256 or keccak_256?
11:10:02*PMunch joined #nim
11:10:04FromGitter<gogolxdong> sha2_256 I think , how to distinguish
11:10:22FromGitter<mratsim> if you’re working with Ethereum/IPFS you probably need keccak_256
11:10:57FromGitter<gogolxdong> QUIC uses sha256
11:11:27FromGitter<mratsim> there are test vectors here: https://github.com/cheatfate/nimcrypto/blob/master/tests/testhmac.nim, you can try them with QUIC to make sure which SHA(2, 3, Keccak) they are using
11:11:37FromGitter<mratsim> I agree that it’s a mess
11:22:17FromGitter<gogolxdong> I though it's identical with the one in Go, but turned out wrong, there is no need to rerun your test vectors since it has been tested vastly.
11:24:27FromGitter<gogolxdong> also noticed the test suite of HMAC-SHA2-256 test vectors is the implementation of hmac* itself, so nowhere to go as for me.
11:38:06FromGitter<mratsim> I not sure I understand what you mean by implementation itself
11:38:56FromGitter<mratsim> sha2_256.digest() basically does ctx.init, ctx.update, ctx.finish, ctx.clear
11:39:09FromGitter<mratsim> digest is just a wrapper on top of those 4 procs
11:39:29FromGitter<m4d3bug> can I use any package to change the format to the excel's format?
11:40:05FromGitter<mratsim> the tests vectors give the inputs -> result so you can put the same input in the go implementation and check i you have the same results
11:40:19*seni joined #nim
11:40:44*vlad1777d joined #nim
11:40:45FromGitter<mratsim> @m4d3bug : https://forum.nim-lang.org/t/3288?
11:41:21FromGitter<mratsim> there is even a package: https://github.com/KeepCoolWithCoolidge/nimlibxlsxwriter not sure what you mean by “the format"
11:43:05*couven92 joined #nim
11:48:45*abm joined #nim
11:50:53FromGitter<m4d3bug> I am using nimMime to send email with attach
11:51:48FromGitter<mratsim> so you want to send a mail in Excel format?
11:52:45FromGitter<mratsim> or just the mime type?
11:53:20FromGitter<m4d3bug> It seem I just need to pass any data which is string typehttps://github.com/enthus1ast/nimMime/blob/master/mime.nim#L311
11:53:48FromGitter<m4d3bug> and data should be Excel format
11:54:02FromGitter<mratsim> If it’s similar to the OpenDocument Format mime types (.odf) it’s probably application/vnd-something
11:54:10FromGitter<m4d3bug> Is that right?
11:54:56FromGitter<mratsim> yes according to the signature you should pass the Excel mime types to mimeTypeOverride
11:55:55FromGitter<m4d3bug> but now only send the txt is ok
11:57:26FromGitter<m4d3bug> maybe I should turn the data to the Excel format before I pass it to the newAttachment?
12:02:54FromGitter<mratsim> I can’t say, this is completely out of my expertise. Intuitively I suppose there is a “attachFile” proc that just dump the content of a file and attach a mime type to that raw dump
12:08:31*krux02 quit (Remote host closed the connection)
12:08:58FromGitter<m4d3bug> I used vnd-something first @mratsim
12:09:08FromGitter<m4d3bug> but I change it to application/octet-stream
12:10:41*norok2 joined #nim
12:14:44FromGitter<m4d3bug> Is that right? @mratsim
12:15:12FromGitter<mratsim> octet-stream just means binary blob
12:15:33FromGitter<mratsim> what if you don’t put anything and let the client auto-infer from the .xls(x) extension?
12:22:01*Ven`` joined #nim
12:37:27*dddddd quit (Quit: Hasta otra..)
12:41:20*Snircle joined #nim
12:46:28*norok2 quit (Quit: Konversation terminated!)
12:53:38PMunchHmm, is there a way to call a procedure but redirect it's stdout to stderr?
12:53:56FromGitter<mratsim> muck with 1& > 2
12:54:02FromGitter<mratsim> os something like that
12:54:05PMunchIn Nim
12:54:07FromGitter<mratsim> or*
12:54:20PMunchI know how to do it for processes
12:54:47PMunchProblem is that LSP communicates over stdin/stdout, with extra information passed over stderr
12:55:19PMunchBut when I call nimsuggest as a library it sometimes crashes with error messages written to stdout
13:03:53dom96_wYou can't overwrite Nim's stdout
13:04:04dom96_wyou can probably do some magic with POSIX/WinAPI though
13:04:37*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:05:41PMunchHmm
13:05:43FromGitter<alehander42> maybe nimsuggest shouldn't write error messages to stdout
13:06:26FromGitter<alehander42> ah it writes info messages
13:08:10dom96_wyou're likely better off just changing your procedure to take either stdin or stderr
13:13:55*Ven`` joined #nim
13:15:40*nsf quit (Quit: WeeChat 2.3)
13:17:09PMunchYeah that's what I'm working on atm
13:17:23*endragor quit (Remote host closed the connection)
13:18:20*seni quit (Ping timeout: 250 seconds)
13:26:00*endragor joined #nim
13:30:28*endragor quit (Ping timeout: 250 seconds)
13:34:54*vlad1777d quit (Ping timeout: 268 seconds)
13:35:16*vlad1777d joined #nim
13:35:21Araqdom96_w, you can there is some API proc to do that
13:35:29Araqforgot its name though
13:35:48Araqsystem.reopen
13:35:53dom96_wPMunch: btw why are you calling nimsuggest as a library?
13:36:06dom96_wYou should be calling it as a process IMO
13:36:10PMunchTo avoid having to juggle external processes
13:36:22Araqdom96_w, I told him to use it as a library :-)
13:36:30PMunchnimlsp is written in Nim, so I don't see a reason why nimsuggest should run as a separate process
13:36:51Araqyeah for nimlsp it's the right thing to do
13:36:53dom96_wbecause if it crashes your LSP server dies too
13:37:12dom96_wor if it uses too much memory your LSP server is screwed
13:37:13PMunchYeah, which should trigger an error in your editor, and give you the option to restart it
13:37:25dom96_was a process you'll be able to act as its supervisor and restart it if it misbehaves
13:37:27PMunchUnlike most of the bridges which just silently hangs..
13:37:44Araqdom96_w, true but whether that is handled well depends on the LS protocol
13:37:46PMunchMoving that supervisor role to the editor
13:39:02dom96_w:'(
13:39:20dom96_wIMO LSP should just be an agent that calls to various suggestion engines
13:39:36dom96_wand ensures they aren't misbehaving
13:39:45dom96_wI doubt an editor will handle all of these cases
13:39:56dom96_wDoes the LSP protocol mandate this?
13:40:05PMunchWell it would need to be able to supervise the process it starts anyways
13:40:08*endragor joined #nim
13:41:08dom96_wAnother disadvantage: you cannot update nimsuggest easily
13:41:42PMunchAdvantage: you don't have to match nimsuggest and nimlsp versions
13:43:10dom96_wwhy would you have to? Surely the nimsuggest protocol won't change in backwards incompatible ways (that would break all editors that use it...)
13:43:39PMunchWell to get any of the potentially new features you would need to have a nimlsp that implements them
13:43:51PMunchSo you can easily update nimsuggest, but you'll also have to update nimlsp
13:44:20*endragor quit (Ping timeout: 250 seconds)
13:44:37PMunchPlus, nimlsp shouldn't be any harder than nimsuggest to update
13:47:02dom96_wSo we'll end up with nimlsp bundled with Nim
13:47:08dom96_wBecause nimsuggest will become effectively obsolete
13:47:53dom96_wif you're doing this then why don't you just implement it in nimsuggest?
13:48:08PMunchBecause you didn't want that last time I asked
13:48:41dom96_wSo you're listening to my advice for that but not for this lol
13:48:55dom96_wYou can't pick and choose advice like this
13:49:55PMunchI created an issue for nimsuggest that it should implement LSP (or it already existed and I commented on it, can't remember). You said it should be a separate tool, so I started working on that and realised interfacing with another program was just unnecessary work.
13:51:22PMunchWell, my goal here is just to make it work. I don't really care how it's done as long as it is maintainable and preferably easy to implement
13:53:44dom96_wOh well. It's up to you. I had a couple of awesome features in mind for this which depend on handling it this way, I guess I'll either need to extract code from your project or start from scratch.
13:53:51PMunchI realised that the nimsuggest bridge was just a lot of work for little to no gain, so I made it importable as a library instead (which of course could be used for other projects, krux02 have already hinted that he wants to rewrite the emacs plugin this way: https://github.com/nim-lang/Nim/pull/9784)
13:54:09PMunchHmm, what kind of features?
13:54:50dom96_wHaving more and more binaries that effectively contain the full functionality of the compiler is a bad idea IMO.
13:55:03*vlad1777d quit (Ping timeout: 246 seconds)
13:55:12dom96_wNot only is it a pain for compile times, it also means that we'll have multiple binaries with different Nim version support
13:55:52PMunchYeah I can see that
13:55:55dom96_wMainly the supervisor features. I would make the LSP server as stable as possible and allow users the ability to report any bugs with a simple click.
13:55:59*vlad1777d joined #nim
13:56:06dom96_w(Any bugs in nimsuggest that is)
13:56:48dom96_wLSP supports popping up questions in the editor for this
13:57:08PMunchBut for me it's outweighed by the ease of programming all of this..
13:57:41PMunchWell if you make a super solid supervisor that I can import as a library I could just use that
13:58:35dom96_wJust go for it. It might very well turn out to be good enough, but I don't think the problems with nimsuggest will be magically solved by just using a different protocol
13:58:49*enthus1ast quit (Quit: WeeChat 1.6)
13:58:57PMunchI just want to be able to use nimsuggest with "var nimsuggest = initNimSuggest("/path/to/project/file.nim"); let suggestions = nimsuggest.sug(10, 4)"
13:59:36*dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:59:37*enthus1ast joined #nim
14:00:07PMunchImporting it as a library makes that easier to achieve, but if I could import a supervisor instead that offers the safe (or better) functionality with little extra work then I'd be all for that
14:00:40PMunchs/safe/same
14:02:00*dom96_w joined #nim
14:08:07*Ven`` quit (Ping timeout: 268 seconds)
14:09:16*dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
14:16:33*Ven`` joined #nim
14:25:23shashlickhow do you use a var at compile time and run time
14:26:38*endragor joined #nim
14:30:55PMunchshashlick, not entirely sure what you mean
14:33:07*ng0 joined #nim
14:39:02*norok2 joined #nim
14:39:19norok2hey, can anybody help me with this? https://stackoverflow.com/questions/53520162/generate-a-new-sequence-with-values-from-a-function
14:40:19leorizenorok2: array indices are of type `int`, not `int64`
14:41:15leorizethe `..<` iterator takes the type from `n`, which was `int64`. you just need to convert `n` to int with `int(n)`
14:43:34leorizefor the second error, it was because `toSeq(0..<5)` generated an array of `int`, but your function take an `int64`, which is considered incompatible by the compiler
14:43:47leorizeand sorry for not posting this on SO, I don't have an account there
14:44:00norok2@leorize thanks for the reply, it's OK
14:45:04norok2but then why `..< int(n)` does indeed work? the `squared` proc is expecting `int64`
14:46:08norok2I would rather do `result[int(i)] = ` or something, however ugly that might be
14:49:22FromGitter<mratsim> use can use `newSeqWith(yourfunction)` from sequtils
14:49:26FromGitter<mratsim> you*
14:50:33FromGitter<mratsim> example: https://github.com/SimonDanisch/julia-challenge/blob/master/nim/nim_sol_mratsim.nim#L49
14:51:14leorizenorok2: because `int` can be converted to `int64`
14:51:19leorizethe issue with map is that:
14:51:35leorizeit's signature is: `proc map[T, S](s: openArray[T]; op: proc (x: T): S {.closure.}): seq[S]`
14:52:06leorizemeaning that the mapped proc must take the same type as the array elements
14:52:51FromGitter<mratsim> you should use mapIt instead of passing a closure. That’s quite costly.
14:53:10FromGitter<mratsim> or use zero-functional or loopfusion packages ;)
14:54:23leorizeI'm wondering if there's something like newSeqWith to generate arrays at compile time
14:54:48FromGitter<alehander42> `a: array[Type, N]` ?
14:55:09leorizebut then you'd need to fill it by hand
14:55:25FromGitter<alehander42> well you do ` = [..]`
14:55:31FromGitter<alehander42> but i usually have enum arrays
14:55:40FromGitter<mratsim> use “fill"
14:55:49FromGitter<mratsim> or implement “newArrayWith” ;)
14:56:07FromGitter<mratsim> initArrayWith*
14:56:33*dom96_w joined #nim
14:56:45leorizehmm, it's not really hard :p
14:56:58FromGitter<mratsim> if you do newSeqWith in a macro it will be transformed into an array in C code
14:57:58leorizeyea, it's should be easy, but I wonder if it has any practical use case lol
14:59:47FromGitter<narimiran> "to generate arrays at compile time" you can use `block` inside of which you loop or whatever you need to do?
15:00:25FromGitter<mratsim> @leorize, it is useful: https://github.com/status-im/nim-byteutils/blob/master/byteutils.nim#L14-L15
15:01:47FromGitter<mratsim> contrary to newSeqWith it doesn’t call multiple times the input though, so you can’t use it for `rand(10)` to fill an array with random values
15:01:48shashlickPMunch: so I have a var which I'm using during compile time so I've marked it with {.compiletime.}
15:01:56shashlicki want to use it during runtime too
15:02:08shashlicki'm okay repopulating it but don't want two names for the same var
15:02:09PMunchAnd keep it's last value from the compile time?
15:02:15PMunchAh..
15:02:16PMunchHmm
15:02:27PMunchNot quite sure if that is even possible
15:02:27FromGitter<mratsim> let runtime = comptime?
15:02:44shashlicki don't care about the contents - want to reuse the name
15:03:09FromGitter<mratsim> they must be in different scope then
15:03:36shashlickwell, they are globals which i need to get rid of anyway... hmm
15:03:44shashlicki think i'll move to an object
15:04:43shashlickstill i'll have two names
15:04:58shashlickso i'll have to write two procs to populate them the same way
15:09:00*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:09:55*nsf joined #nim
15:18:48*Ven`` joined #nim
15:26:00leorizeshashlick: you can use `when nimvm:` I think
15:28:04leorizeoops, it doesn't work
15:29:46shashlick😞
15:30:08*dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:31:31leorizecould this be a VM bug? https://ptpb.pw/77Kj/nim
15:31:40leorizethat example prints:
15:31:43leorize`[1, 1, 1, 1, 1, 1, 1, 1, 1, 1]`
15:31:48leorize`[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]`
15:31:57leorizebut they should be equal to each other :/
15:35:28*vlad1777d quit (Ping timeout: 245 seconds)
15:36:08*Ven`` quit (Ping timeout: 250 seconds)
15:36:11norok2@leorize: why the `result[i] = ...` is so strict about the type, but the `newSeq[int64](n)` isn't? I mean `i` and `n` were `int64` in both cases. Is this an unwanted feature or there is more to it?
15:36:28*Ven`` joined #nim
15:36:57leorize@mratsim: that code I linked above is the array version of `newSeqWith` :D
15:38:24leorizenorok2: seq indices are `int`-only
15:38:54leorize`int64` could be bigger than `int` on certain architectures, which is why conversion is blocked
15:39:53norok2this I understand, but then `newSeq[T](n)` should require `n` to be `int`-only
15:41:20leorizethat's because the signature of `newSeq` is: `proc newSeq[T](len = 0.Natural): seq[T]`
15:41:50leorizeand `Natural` is a `range`
15:42:09leorizewhich currently still have poor compiler schematic check sadly...
15:43:03norok2OK, so that's kind of an unwanted feature :-P
15:43:36norok2regarding the `map`-way, how would I then have `toSeq()` to generate `int64` items?
15:44:26leorizethe iterator you placed in there should yield `int64`
15:45:56FromGitter<mratsim> @leorize, if you use static int as a result instead of compiletime it works I think
15:46:20*dddddd joined #nim
15:46:23FromGitter<mratsim> see here: https://github.com/numforge/laser/blob/master/laser/openmp.nim#L13-L25
15:46:41FromGitter<mratsim> though there is a PR to disallow static result type so I have to check
15:47:06leorizeyep, static int work
15:47:34leorizethat's certainly unexpected... is there a bug filled for it?
15:48:19FromGitter<mratsim> let me open one
15:48:26FromGitter<mratsim> what’s your github handle?
15:48:50leorize"@alaviss"
15:50:10*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:53:41*Trustable joined #nim
15:56:54*abm quit (Read error: Connection reset by peer)
16:01:26norok2var arr = toSeq(0 ..< 5)
16:01:27norok2var sq_arr = map(arr, proc(x: int): int64 = squared(x))
16:02:09norok2this would work but that's basically doing (again) `int` to `int64` casting
16:02:41norok2it looks like sometimes this needs to be explicit and sometimes not, how can know when this is needed?
16:03:34leorizeuse `0 ..< 5'i64` and you got a seq of `int64`
16:04:24*narimiran joined #nim
16:04:26leorizeall `int` literal are to be assumed as `int`, unless they're larger than `int32` then the compiler will turn them into `int64`
16:04:43FromGitter<mratsim> @leorize: https://github.com/nim-lang/Nim/issues/9817
16:05:22*Vladar joined #nim
16:06:46leorizethanks for filling the bug!
16:06:57norok2thanks for the int, but this does not answer the question on why `squared(i)` with `i` and `int` works inside the `squared_seq` procedure, but it doesn't when using it with `map()`
16:07:38leorizeI showed you the signature of `map()`
16:07:53leorizeit takes a proc that take the same type as the array element
16:07:59leorizebut `int` is not `int64`
16:08:17norok2but in `squared()` this is also the case
16:08:35norok2why in `map()` this is honored, and in `squared()` not
16:08:54leorizeit's honored because it's explicitly laid out
16:09:21leorize`int` can be implicitly converted to `int64`, so the compiler will do that when needed
16:09:45leorizethe type signature of `map()` however, forbid this entirely by enforcing the type for the mapped function
16:10:16leorizein such cases, you should use `mapIt`
16:10:29norok2I thought it was deprecated
16:10:30leorizeit's more relaxed than `map`, and also faster
16:10:41leorizeno, it's not deprecated
16:11:17norok2BTW `0 ..< 5'i64` does not work -- gives type mismatch error, but `0'i64 ..< 5'i64`does work
16:12:55leorizetype inferrence is weird at times
16:29:27*msmorgan__ left #nim (#nim)
16:30:50*msmorgan joined #nim
16:34:39*rockcavera quit (Remote host closed the connection)
16:46:17PMunchDiscovered a tiny issue with my library wrapping, https://github.com/nim-lang/Nim/pull/9818. Once this is merged I'll set the nimlsp master to use the library version and continue working on actual features :)
16:46:37PMunchBut I've just tested it out in some different editors and the results are looking good so far, lot's of stuff already working :)
16:53:54FromGitter<arnetheduck> does lsp have room for language-specific extensions?
16:56:03*endragor quit (Remote host closed the connection)
16:56:35*floppydh quit (Quit: WeeChat 2.3)
16:57:26*dom96_w joined #nim
17:15:53*craigger quit (Quit: bye)
17:18:25*craigger joined #nim
17:23:22*nsf quit (Quit: WeeChat 2.3)
17:36:09*Jesin joined #nim
17:48:44*Perkol joined #nim
17:55:58PMuncharnetheduck, not sure. What kind were you thinking of?
18:04:03*ng0 quit (Remote host closed the connection)
18:04:43*norok2 quit (Quit: Konversation terminated!)
18:05:06*ng0 joined #nim
18:14:40*Trustable quit (Remote host closed the connection)
18:36:59*jjido joined #nim
18:46:27*Jesin quit (Quit: Leaving)
18:46:42*Snircle quit (Read error: Connection reset by peer)
18:47:17*Snircle joined #nim
18:52:04*Jesin joined #nim
18:52:26*jjido quit (Ping timeout: 250 seconds)
18:58:36*PMunch quit (Remote host closed the connection)
19:06:03*nsf joined #nim
19:07:14*jjido joined #nim
19:21:55*d_s joined #nim
19:26:37*leorize quit (Quit: WeeChat 2.2)
19:28:32*jjido quit (Read error: No route to host)
19:29:20*Armaldio joined #nim
19:35:19*jjido joined #nim
19:36:30FromDiscord_<Armaldio> Hello everyone,
19:36:30FromDiscord_<Armaldio> I'm currently facing a problem while starting a process.
19:36:30FromDiscord_<Armaldio>
19:36:30FromDiscord_<Armaldio> I have node.js installed and want to start node on a file (cmd: 'node index.js').
19:36:31FromDiscord_<Armaldio> I've managed to ouput the result of a simple file with "static" content using startProcess("node", "", @[filepath])
19:36:34FromDiscord_<Armaldio> However, my code is dynamic in the sense there are prompts, so it doesn't work because it wait for process to stop before giving you access to the output.
19:36:34FromDiscord_<Armaldio>
19:36:35FromDiscord_<Armaldio> I can see two options here:
19:36:38FromDiscord_<Armaldio> Having somehow the output through streams than I can somehow read in nim asynchronously, but I'm not sure it will really fit cause of prompts and seems also overcomplicated
19:36:41FromDiscord_<Armaldio> Second possibility is that I'm missing a proc that just start my process and "give it the hand" like if I was launching it myself.
19:36:42FromDiscord_<Armaldio>
19:36:43FromDiscord_<Armaldio> Am i clear enough ?
19:47:26xaceArmaldio: im not really sure, but there are input streams too to control the prompts if thats what you are asking
19:50:55xaceotherwise maybe you are asking about running() or waitForExit() im not really sure
20:03:08*Ven`` joined #nim
20:10:51FromDiscord_<Armaldio> it's just that when I start my node process it act like if it's a background process, run it and end it
20:10:51FromDiscord_<Armaldio> But i'd like to be able to interact with the subprocess interactively
20:11:47*nsf quit (Quit: WeeChat 2.3)
20:12:43*Ven`` quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:15:51*zachk joined #nim
20:16:25*zachk quit (Changing host)
20:16:25*zachk joined #nim
20:16:45*theelous3_ joined #nim
20:20:25*jjido quit (Read error: Connection reset by peer)
20:26:41FromGitter<zetashift> @Calinou you there by any chance?
20:26:57*dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:27:44Calinouhi, yes :)
20:28:57FromGitter<zetashift> hey! the godot-nim small post I wrote has been sitting there for a while now: https://github.com/nim-lang/website/pull/93 if it's not good enough I can close it, or if something needs to be added could you let me know so I can try and change it
20:29:10FromGitter<rayman22201> @Armaldio, this is an example from python, but the concept is the exact same: https://stackoverflow.com/questions/14457303/python-subprocess-and-user-interaction ⏎ You would use https://nim-lang.org/docs/osproc.html#startProcess and https://nim-lang.org/docs/osproc.html#inputStream to interact with the process
20:29:55FromDiscord_<Armaldio> Thanks @rayman22201! Will look at these resources and let you know if I can make it work 😃
20:32:18*Perkol quit (Quit: Leaving)
20:32:28FromGitter<rayman22201> 👍
20:34:04*miran joined #nim
20:34:11Calinou@zetashift The content looks good, but the writing leaves to be desired (it doesn't feel very professional to me). Still, it can be merged since we don't have too many news articles lately
20:34:44CalinouI also saw a few more typos but I can use the GitHub suggestions feature now :)
20:34:48Calinou(so you can apply them with a single click)
20:36:26*narimiran quit (Ping timeout: 250 seconds)
20:36:34FromGitter<zetashift> cool cool
20:37:06FromGitter<zetashift> and yeah I'm not a good writer
20:37:06Calinoualso I'm very busy finishing my game for the Game Off jam :P
20:38:50FromGitter<zetashift> ah yeah it can wait, just needed confirmation if I should close it or not
20:40:20*miran is now known as narimiran
20:46:32*Jesin quit (Quit: Leaving)
20:53:37*Sembei joined #nim
20:54:40*narimiran quit (Ping timeout: 272 seconds)
20:55:36FromGitter<arnetheduck> @PMunch I was thinking that the only reason to keep nimsuggest around is that it might be able to support stuff that's outside of LSP
20:55:52FromGitter<arnetheduck> however, if LSP has extension points, could just drop nimsuggest completely
20:56:49FromGitter<arnetheduck> that said, +1 for turning it into a lib - that's the beginning of a lot of analysis tools that become easier to write
21:00:56*jjido joined #nim
21:03:10*stefanos82 quit (Remote host closed the connection)
21:04:14FromGitter<rayman22201> I agree with you completely @arnetheduck. Dom96 makes a good point about including the whole Nim compiler as a dependency. That isn't ideal, but I feel like the pros outway the cons here, and compile times can be fixed in other ways. I would rather have more cool compiler based analysis tools. Nim also isn't trying to be erlang, so trying to shoehorn supervisor features into LSP doesn't seem like a great idea to me.
21:04:45*Ven`` joined #nim
21:07:35FromGitter<arnetheduck> the approach has served `llvm` and `clang` well, to say the least.. compile times are something that nim needs to deal with generally, not just for the compiler.. as long as it relies on the current compile-all-sources-always, nim apps are going to be limited to scripts and trinkets
21:07:49Araqit's not the whole compiler fwiw, the C and JS codegens are not used
21:08:17FromGitter<arnetheduck> yeah, that too, but that separation is not very clean in the compiler
21:08:25*Ven`` quit (Client Quit)
21:10:49FromGitter<arnetheduck> that's why it's good that work is being done towards treating it as a library - compiler, nimsuggest etc.. that'll promote some good refactoring as well
21:12:44FromGitter<rayman22201> exactly +100
21:16:45FromGitter<arnetheduck> shoehorning supervisors in seems to be a recurring theme among nim developers, not sure where that's coming from either.. ie it's been used as an argument to keep exceptions - that you can have an outer supervisor loop that somehow will be able to deal with the mess after an exception rips through the call stack with no care for partially committed state
21:17:41*sz0 joined #nim
21:23:19Araqthat argument remains to be uncontested
21:24:26*Vladar quit (Remote host closed the connection)
21:28:32Araq"rips through the call stack with no care for partially committed state" is just words, no facts. Does an Erlang supervisor roll back file system changes? no. that would not even been desirable for logging files. So... the "shitty" partial solution is what every system does.
21:30:19FromGitter<arnetheduck> no, it's not just words, it's an expression of the fact that nim lacks the tools to unwind safely - ie deterministic destructors etc
21:30:43Araqand why error handling is better when it's tied to a concurrency primitive ("lightweight processes!") remains a mystery too.
21:32:28Araqok, so ignoring the fact that we're getting destructors, that means C# and Java and Python ... cannot "unwind safely".
21:35:12jjidoSupervisor is good to look at ordering and deadlock prevention. It is for concurrency not error handling.
21:35:14FromGitter<arnetheduck> ever seen a java program? every book and tutorial out there points out that you have to write a finally statement in nearly every proc to make sure it's safe - c# likewise with `using`.. python, not a bastion of reliability / not a systems programming language as nim purports to be
21:35:18FromGitter<rayman22201> I'm confused. sorry. :-/ Araq, is your statement pro supervisor, or pro exceptions, or both? I always saw those as two different concepts (though they can work together).
21:35:46FromGitter<arnetheduck> nim destructors are like c# disposables.. deterministic, sometimes, from what understand?
21:37:37Araqjjido: for deadlock prevention you don't need a supervisor, you can also use static analysis
21:38:44Araqrayman22201: my point is that exceptions don't have any alternative.
21:40:46FromGitter<rayman22201> ah. ok. I see. Yeah, I have to agree with you there. There isn't really a way to fully "roll back" or "fully commit" state in a moderately complex system in practice (i.e. modern computer software). There is just new error states, and how you handle those error states.
21:40:57Araqexit() only works when you run on an OS, wrapping everything in an Either is infeasible. The very idea of a "function that cannot fail" is an illusion, software runs on hardware with finite resources.
21:41:07FromGitter<rayman22201> yeah
21:45:14FromGitter<arnetheduck> another illusion then is that "you can deal with every failure" like a supervisor tries to do
21:45:33FromGitter<rayman22201> also true.
21:46:53*jjido_ joined #nim
21:50:41AraqI don't see how that is a comparable illusion. when my software crashes, my OS doesn't.
21:51:15Araqit would be cool if we could always assume an OS and exit() but I wouldn't call the result a "systems" programming language then.
21:53:10Araqthe C++ software on the Mars Rover restarts quickly though without an OS, so maybe we need a restart() primitive instead
21:57:25FromGitter<arnetheduck> c++? https://softwareengineering.stackexchange.com/questions/159637/what-is-the-mars-curiosity-rovers-software-built-in
21:58:29Araqhttps://www.youtube.com/watch?v=3SdSKZFoUa8
22:00:02FromGitter<rayman22201> cool
22:05:45Araqhttps://youtu.be/3SdSKZFoUa8?t=4295 here is where he talks about rebooting
22:20:58*rockcavera joined #nim
22:23:10federico3rebooting is pretty common practice on airplanes and other scenarios as well but is getting offtopic
22:25:02FromGitter<arnetheduck> notably he says "reboot and wait for human input" - that means in particular: don't blindly try again
22:25:35FromGitter<arnetheduck> doesn't sound like a supervisor or a top-level exception handler
22:32:15Araqhe also says "it reboots many times a day"
22:32:30Araqand I don't think he implies that it waits for human input then
22:32:39federico3it doesn't
22:34:04livcdare we getting estructors ?
22:35:37Araqyeah, of the deterministic variant, C++ inspired
22:36:17Araqand yeah, they too have their share of problems because nothing is perfect in this world
22:37:31*jjido_ quit (Quit: Textual IRC Client: www.textualapp.com)
22:37:42FromGitter<arnetheduck> well, reboot in the sense "controlled shutdown sequence, then controlled startup sequence", not the supervisor kind "something didn't work, let's try again"
22:38:23FromGitter<arnetheduck> er, destructors + refs = non-deterministic, no?
22:40:36Araqwhat to map 'ref' to is an open problem, but a shared_ptr is not unthinkable. and yeah, I know, shared_ptr is not "deterministic" either, it races into what thread does the destruction, yawn
22:42:05FromGitter<arnetheduck> yay refcounting and cycles :)
22:42:20Araq^ so predictable.
22:42:30FromGitter<arnetheduck> irresistable :)
22:45:44Araqmy favourite solution so far though is to write a precise and simple copying GC for refs. and to tell people to not use 'ref'. but when they do, at least they get a O(live heap) cost instead of O(heap size)
22:48:36FromGitter<arnetheduck> so how would you represent a graph, if not through refs? indices?
22:51:14Araqyes
22:53:46Araqpreferably of the (index, generation) variant
23:00:59*abm joined #nim
23:01:50*tiorock joined #nim
23:01:50*tiorock quit (Changing host)
23:01:50*tiorock joined #nim
23:01:50*rockcavera is now known as Guest97851
23:01:50*Guest97851 quit (Killed (cherryh.freenode.net (Nickname regained by services)))
23:01:50*tiorock is now known as rockcavera
23:05:47*vlad1777d joined #nim
23:06:38*jjido quit (Read error: Connection reset by peer)
23:07:08*jjido joined #nim
23:07:17*Armaldio quit (Remote host closed the connection)
23:44:40*jjido quit (Remote host closed the connection)
23:49:21*vlad1777d quit (Remote host closed the connection)
23:49:30FromGitter<zacharycarter> I just read most of the conversation above - I am slightly confused... I think exception handling can take on different forms - and Nim uses try / except in the stdlib pretty thoroughly
23:51:13*vlad1777d joined #nim
23:51:44FromGitter<zacharycarter> so if I had some code that was like - ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5bff2a10f048fa10513bcc5f]
23:51:55FromGitter<zacharycarter> sorry just going to just this
23:54:12FromGitter<zacharycarter> if I have code like this - https://gist.github.com/zacharycarter/ecf846bd75c79ca611046ec59cb05697
23:54:25FromGitter<zacharycarter> isn't that similar to Java?
23:58:19FromGitter<zacharycarter> I know that's not a destructor - but what's the difference between that and Java's ability to unwind safely?