<< 30-11-2018 >>
00:01:36FromGitter<brentp> actually this ends up working: ` for isample in 0..<data.len: ⏎ ⏎ ```data[isample] = $cast[cstring](cs[isample * n_per].addr)``` ⏎ ⏎ ` [https://gitter.im/nim-lang/Nim?at=5c007de0a6c29a1037bbac8e]
00:02:52FromGitter<mratsim> seems convoluted
00:03:34FromGitter<brentp> would you explain? I'd be glad to make it simpler.
00:03:43FromGitter<mratsim> var foo = newString(data.len); copyMem(foo[0].addr, data.len)
00:04:27FromGitter<brentp> data is the (poorly named) dest. it is of type `seq[string]`
00:04:35FromGitter<brentp> cs is a cstring
00:04:59FromGitter<brentp> that is effectively $n strings, where $n == data.len
00:05:35FromGitter<mratsim> ah I see
00:06:06FromGitter<mratsim> probably your way is the best then
00:06:17FromGitter<brentp> this is the api, fwiw: https://github.com/samtools/htslib/blob/develop/htslib/vcf.h#L734
00:06:28FromGitter<brentp> note the large block of text above that line explaining the impl
00:08:58*def- quit (Ping timeout: 246 seconds)
00:09:05*def- joined #nim
00:11:08*vlad1777d quit (Remote host closed the connection)
00:11:12*edcragg_ quit (Ping timeout: 272 seconds)
00:12:05*vlad1777d joined #nim
00:15:41*edcragg_ joined #nim
00:21:54*krux02 quit (Remote host closed the connection)
00:27:51*edcragg_ quit (Ping timeout: 244 seconds)
00:40:24dom96So, who's doing Ludum Dare this weekend?
00:40:24*edcragg_ joined #nim
00:40:29dom96I might even livestream it this time
00:46:25*ghost64 quit (Quit: See you!)
00:51:20*ghost64 joined #nim
00:56:29FromGitter<rayman22201> Oh boy! That's this weekend!?! time has really gotten away from me...
01:00:29dom96yep :D
01:01:14dom96Sadly I have work on Monday so I'll be doing a 48 hour Jam with my SO, should still be fun though.
01:02:21FromGitter<arnetheduck> btw @dom96, when `nimble` dep resolution is running (`build` for example), what is it actually doing? it's surprisingly slow - like you can see the pause between each dep..
01:03:07dom96I'm guessing it's slow because it's running in debug mode
01:03:20dom96Because Araq decided to compile it in debug mode for a release... :'(
01:04:07FromGitter<arnetheduck> oh? I'm just doing whatever `choosenim` is doing.. is that a debug compile??
01:04:17dom96choosenim just calls `koch`
01:04:25dom96but yes, I believe so
01:04:34dom96It should be fixed in latest release
01:04:48dom96But anyway, yeah, the process is still slow because Nimble effectively embeds nimscript
01:05:26dom96So for each dependency it needs to read the .nimble file. This was fine when the .nimble files were simple .ini files but now... :(
01:06:45FromGitter<arnetheduck> `nimexec("c -d:release --nilseqs:on dist/nimble/src/nimble.nim")` - not that, it's a release build in 0.19
01:07:08FromGitter<arnetheduck> unless...
01:07:15FromGitter<arnetheduck> oh, there's a second line building nimble
01:07:19dom96It's easy to check
01:07:28dom96just run `nimble install` in a directory without a .nimble file
01:07:34dom96or even just `nimble ahsdasd`
01:07:38FromGitter<arnetheduck> `nimexec("c --noNimblePath -p:compiler --nilseqs:on " & installDir / "src/nimble.nim")`
01:07:40dom96you'll get a stack trace if it's debug mode
01:08:16dom96This is something we should investigate though
01:08:19FromGitter<arnetheduck> right, it's debug / stack trace
01:08:27dom96I can totally see nimscript evaluation not scaling
01:09:26dom96If you've got nothing better to do, feel free to measure it :)
01:09:28dom96good night
01:09:53FromGitter<arnetheduck> hm, gonna try a release build first I think..
01:22:57*ng0 quit (Quit: Alexa, when is the end of world?)
01:53:33*mavidser left #nim ("Textual IRC Client: www.textualapp.com")
01:55:56*Jesin quit (Quit: Leaving)
01:56:40*theelous3_ quit (Ping timeout: 268 seconds)
02:00:46*Jesin joined #nim
02:10:06FromGitter<arnetheduck> ok, nimble speed much better in release, thanks @dom96!
02:27:13*dddddd quit (Remote host closed the connection)
02:48:32*kapil____ quit (Quit: Connection closed for inactivity)
03:01:01FromGitter<citycide> while I do like `.nimble` files as they are I'm curious about the decision to make them nimscript. a static config like Rust's TOML or JS's JSON would be much faster. is there discussion on this somewhere already?
03:04:30*vlad1777d quit (Ping timeout: 268 seconds)
03:06:33*zachk quit (Quit: Leaving)
03:07:41*banc quit (Quit: ZNC - http://znc.in)
03:14:05*kapil____ joined #nim
03:18:48*abm quit (Ping timeout: 245 seconds)
03:24:40*banc joined #nim
03:32:18*Gertm joined #nim
03:58:40FromGitter<gogolxdong> is string type UTF8 encoding?
04:04:17FromGitter<gogolxdong> chinese email attachment name is messy code.
04:15:15FromGitter<gogolxdong> needs encoding convert like `open(destEncoding = "GB18030",srcEncoding= getCurrentEncoding()).convert(fileName)`
04:18:35FromGitter<zacharycarter> @citycide - NPM is what I think you're referring to when you're talking about a JS package manager
04:18:54FromGitter<zacharycarter> I find certain things about NPM to be infuriating
04:19:34FromGitter<zacharycarter> I like the ability to write scripts inside my nimble file - for defining custom tasks etc
04:20:09FromGitter<zacharycarter> which you can do inside of NPM for instance - but you have to keep them on one line
04:20:12FromGitter<zacharycarter> and you can't comment out any code
04:20:22FromGitter<zacharycarter> you always have the option to use NPM + nake
04:20:44FromGitter<zacharycarter> or keep all the nimscript for Nim external to your nimble file - not sure how much that will help with compilation speeds
04:44:15enthus1astgogolxdong maybe you could use base64 encoding
04:44:43enthus1astbut then you maybe need the encoding in the email header
04:55:49*endragor joined #nim
05:05:38*nsf joined #nim
05:53:03*kapil____ quit (Quit: Connection closed for inactivity)
06:14:12FromGitter<gogolxdong> Thanks for replying, the encoding convertor works for attachment name, if uses base64 encoding for email boy, the attachment content will be messy code.
06:21:15FromGitter<citycide> @zacharycarter no I wasn't talking about package managers, I was talking about module manifests
06:21:24FromGitter<citycide> static vs. dynamic
06:22:34FromGitter<citycide> and the limitations you're talking about (no comments, multiline scripts) are of JSON, not npm
06:24:36FromGitter<citycide> what I'm curious about is the speed of nimble's dependency resolutions, since @dom96 brought it up, given the switch to nimscript rather than ini
06:26:33FromGitter<gogolxdong> It works well under test directory, but doesn't under our project directory. The same code.
06:51:43FromGitter<gogolxdong> means file header uses Content-Transfer-Encoding":"quoted-printable"
06:56:57*mjanssen joined #nim
07:02:57FromGitter<gogolxdong> We have settled email sending with specific body layout and attachments using nimMime, thanks for your work. @enthus1ast
07:09:44*krux02 joined #nim
07:12:02*xace quit (Remote host closed the connection)
07:14:00*xace joined #nim
07:24:24*kapil____ joined #nim
08:11:49*Vladar joined #nim
08:17:23*MyMind joined #nim
08:18:23*Sembei quit (Ping timeout: 268 seconds)
08:18:50*druonysus quit (Ping timeout: 250 seconds)
08:19:14*druonysus joined #nim
08:19:14*druonysus quit (Changing host)
08:19:14*druonysus joined #nim
08:20:45*Perkol joined #nim
08:39:56PerkolHow do I overwrite file I am currently reading? E.g. I have a program with algo like read from input file -> do something with contents -> write to output file
08:40:24PerkolI want to write to input file. How can i do it correctly
08:40:29Perkol?
08:41:52FromGitter<narimiran> Perkol I'm talking blindly here, but: when you open it, use `rw` flag, not `r` (I guess this is default if you don't specify anything)
08:41:57leorizePerkol: you could read the entire input to the memory, then it's safe to write directly into the input file
08:42:49leorizeor, you could write to a temporary file, then replace the input file with that one
08:43:51Perkolleorize: thanks, but I want to do this in case hdd have no space for second file. Also file is big, might not fit in ram
08:45:15leorizeyou could try to: save the current position in file, read the file, seek back to the saved position, write the result
08:45:58leorizebut ofc that's not safe
08:46:09FromGitter<narimiran> https://nim-lang.org/docs/system.html#FileMode
08:47:13leorizenarimiran: this is not about read-write status, it's more about `sed '<something>' < inputfile > inputfile`
08:47:48leorizethere's a tool that would let one do something like this, but I forgot it's name sadly
08:48:21FromGitter<narimiran> ok, i guess i misunderstood the question
08:48:52Perkol>you could try to: save the current position in file, read the file, seek back to the saved position, write the result
08:49:19PerkolWould this ruin file if data size changes?
08:49:27leorizeyes, that's why I said it's not safe
08:50:12*Arrrrrrrrrrrrrrr joined #nim
09:41:29*derlafff quit (Quit: http://quassel-irc.org - ????????????? ??????. ?????.)
09:41:39*derlafff joined #nim
09:50:56*derlafff quit (Remote host closed the connection)
09:53:05*bilebucket joined #nim
09:57:14*derlafff joined #nim
09:57:33*derlafff quit (Remote host closed the connection)
09:58:54*Arrrrrrrrrrrrrrr quit (Quit: Page closed)
10:04:49*Perkol quit (Remote host closed the connection)
10:12:13krux02Perkol: I is best to write the changes into a new file and then when you are done reading you replace the file.
10:12:31krux02you cannot simply insert or delete in the middle of a file while reading it
10:16:46*PMunch joined #nim
10:23:59*dom96_w joined #nim
10:24:06*dom96_w quit (Changing host)
10:24:06*dom96_w joined #nim
10:24:34dom96_wnarimiran: FYI I tweeted about Ludum Dare as well, which just so happens to start when Advent of Code starts :)
10:27:34FromGitter<narimiran> dom96_w: yeah, i've seen. busy december :)
10:27:48dom96_wyeah :)
10:27:56dom96_wI'll try to livestream my Ludum Dare attempt this weekend
10:28:28dom96_wNow that I have my fiber + desktop it should be far more fun
10:28:59FromGitter<alehander42> how fast is fiber there?
10:29:59dom96_wI got really really lucky and managed to find an apartment with hyperoptic (Fiber to the home and therefore up to 1Gb)
10:30:11dom96_wI got the 150Mb which is already insane
10:30:59FromGitter<alehander42> 100 mbps is very normal around here since years
10:31:19FromGitter<alehander42> always surprised by the difference
10:31:31FromGitter<alehander42> i tried to livestream from france and I got 2 mbps
10:31:37FromGitter<alehander42> and i was flabbergasted
10:32:45FromGitter<alehander42> however, we have 1gbps only in plovdiv iirc :( jealous :D
10:33:32dom96_wyeah, everywhere else was 8Mb
10:33:36dom96_wand like 2mb upload at best
10:33:42dom96_wyou can't stream on taht
10:34:28*stefanos82 joined #nim
10:35:28*PMunch quit (Excess Flood)
10:36:09*PMunch joined #nim
10:40:12PMunchMy network is pretty good, but I'm pretty sure my router is about to die..
10:40:47PMunchWhenever I download too much it just dies..
10:40:55PMunchAnd I have to re-start it
10:45:08euantorI take it you're around London now dom96_w?
10:45:14dom96_wyep
10:45:24euantorI'm in the North East and I'm always surprised at how different things are
10:45:46dom96_wNorth East of London or the UK? :)
10:45:46euantorThe average in my town is around 50-60Mbps which is odd considering we're ina rural area
10:45:51euantorEngland
10:45:56dom96_wahh
10:46:13dom96_wyeah, London has really old infrastructure
10:46:28euantorI have some friends who were just outside london and the best they could get was 6Mbps
10:48:55dom96_wyeah, I got really lucky
10:49:13dom96_wCrazy thing was that the apartment didn't have the fiber installed
10:49:21dom96_wthey must have just been using BT... *shudder*
10:49:40euantorBT's who I'm with actually, and had no problems so far
10:49:55euantorUsed to be with Sky but their service was awful
10:51:41FromGitter<alehander42> @dom96 , Araq: wanted to ask you about an idea about the JS backend: in typescript, the cool thing is you can pass freely anon `{a: 2}` etc objects and still typecheck them correctly (kinda like tuples) ⏎ ⏎ currently our `js{a: 2}` generates a less nice `JsObject` : maybe we can have both: ⏎ ⏎ `js{a: 2}` generates `JSTuple[a: int]` and `JSTuple` have converters to `JsObject`, so you get the lightweight
10:51:41FromGitter... tuple-like thing very useful for interoping with JS and remain compatible [https://gitter.im/nim-lang/Nim?at=5c01163d1c439034aff6bbc2]
10:52:33dom96_w@alehander42: Any extra typing always sounds good to me
10:54:22FromGitter<alehander42> yes, this adds easier typesafety ⏎ as often in callbacks etc you need one-time types and it's so much better to just write ⏎ `event(proc(e: JsObject[a: int, b: U]))` than writing a `event(proc(e: SpecialType))` and SpecialType which you will never use elsewhere
10:55:20FromGitter<alehander42> notice, this looks exactly like tuples, but tuples *require* Field0 Field1 etc which doesn't work when the env passes you actually `a` `b`
10:58:38*leorize quit (Ping timeout: 268 seconds)
10:59:25*leorize joined #nim
11:22:22*Yardanico quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
11:22:33*Yardanico joined #nim
11:24:18FromGitter<mratsim> In big cities in France ou basically have 300~600Mbps everywhere
11:35:05*ng0 joined #nim
11:41:31FromGitter<alehander42> Probably just random luck from my side haha
11:46:45FromGitter<mratsim> Go 2 will have better errors and generics (or at least both are a goal): https://blog.golang.org/go2-here-we-come
11:57:43livcdI like Go but dont see many Go programs outside of the area where it shines.
11:58:04FromGitter<mratsim> the opposite is Javascript :P
11:58:26livcdYeah
11:58:37FromGitter<mratsim> I do’t like Go because anything I do requires generics
11:58:50krux02I like Go, and I think it has a bright future, but I don't see generics mentioned for go2
11:59:10FromGitter<mratsim> in the middle, you can search for it
11:59:27krux02mratsim: generics are great, but when you are creative, you realize how much you can get without them
11:59:54livcdI like Go as well but I do not like it's ergonomics and its confinement as I said
11:59:55krux02I lot of coude that I have seem in C++ would be 10 times better if it wouldn't be generic
12:00:13krux02ergonomics?
12:00:25FromGitter<mratsim> Building a tensor library without generics would be veeery painful
12:00:38krux02I don't like the if err panic pattern
12:00:40krux02it's stupid
12:00:44livcdlack of features
12:00:58FromGitter<mratsim> I think the if err will be addressed as they mention better error handling
12:01:56krux02mratsim: I didn't use real tensors, but for a lot of tensor operations, a combination of matrix multiplications with stride parameter is enough
12:01:58livcdBut now thinking about it I would not want to write a frontend in Go (thinking WASM) or GopherJS
12:02:25krux02you would only need to duplicate for float32 and float64. And when you are an application developer, you can settle for one of them
12:02:43FromGitter<mratsim> without generics you would need to implement them for float32, float64, int32, int64, in ML e’re even using FP16, int8 and int4
12:03:11krux02I haven seen a single use for integer matrices
12:03:41FromGitter<mratsim> Nvidia added dp4a and dp2a instructions for integer matrix multiplication
12:03:44krux02float16 is useful though to save memory on the GPU
12:04:00FromGitter<mratsim> and Intel will add integer matrix multiplication in AVX512-VNNI (Vector Neural Instruction)
12:04:26krux02yea for bitcoin mining integer instructions are important, but I don't see that as a real usage, it is an artificial
12:05:06FromGitter<mratsim> They are used when quantization of FP number is acceptable
12:06:08FromGitter<mratsim> for example Facebook int8 matrix multiplication: https://github.com/pytorch/FBGEMM/blob/master/src/FbgemmI8Depthwise.cc
12:06:26FromGitter<mratsim> for depthwise convolution
12:06:34krux02when my memory is correct, integer and floating point units are different hardware. A GPU hardware is specialized for one of them, not both. And game hardware usually prefers float
12:07:29FromGitter<mratsim> Yes, GPU are specialized for float32, the new RTX also have float16, float64 is reserved to Tesla
12:07:48FromGitter<mratsim> but due to the rise of ML, Nvidia added more integer compute: https://devblogs.nvidia.com/mixed-precision-programming-cuda-8/
12:08:07FromGitter<mratsim> `NVIDIA is expanding the set of tools available for mixed-precision computing with new 16-bit floating point and 8/16-bit integer computing capabilities.`
12:09:25krux02I think machine learning is a very dangerous technology. It won't be terminator 2, but it will raise even morse and more intelligent monopolies than facebook and google already are.
12:09:38FromGitter<mratsim> redeveloping a float32 library without generics to support those would be very annoying
12:11:07krux02well I get it, you want generics, and that is totally fine. All I wanted to say is, that without generics you can live a happy life in matrix tensor land as well, you just have to make a few cuts in what you want to support.
12:11:18*PMunch quit (Remote host closed the connection)
12:13:49FromGitter<mratsim> it’s not “a few”. You often have to deal with categorical data like “man, woman, child, dog” that are represented as integers. In natural language processing, you represent all words of the English dictionary as integer tensors.
12:15:38FromGitter<arnetheduck> @mratsim you got stuck with the generics hammer, and now everything looks like a generic nail :)
12:16:04FromGitter<mratsim> better generics than classes ;)
12:17:55FromGitter<mratsim> I do have libraries without a single generic (though I think they all have static, at least for arrays): https://github.com/mratsim/golem-prime/blob/master/src/datatypes.nim, https://github.com/mratsim/chirp8/blob/master/src/cpu.nim, https://github.com/mratsim/glyph/blob/master/glyph/snes/datatypes.nim
12:18:42krux02mratsim: I know this is kind of a different topic, but that use case you describe sounds a lot like a facebook use case, and I would like to avoid to develop a technology that help majorily companies like that.
12:18:45FromGitter<alehander42> Well, if you are creative you can do everything in assembly
12:19:10FromGitter<alehander42> The point of a language us to optimize clarity for some scenarios
12:19:32FromGitter<alehander42> Maybe go's approach is good for networking / some cli apps
12:19:39FromGitter<alehander42> But it's obviously niche
12:19:48FromGitter<mratsim> it’s not Facebook specific, it’s helpful anywhere you need to do deep learning applied to computer vision/image recognition/analysis
12:19:52livcdmratsim: whoa..i just realized status hired almost all the Nimers..Nimeans ?
12:20:20krux02not me
12:20:26FromGitter<alehander42> It's a bit like macros, go people would hate macros but they use codegenerators which are a worse version of it
12:20:26krux02I got hired by Araq
12:20:33krux02who is payed by status
12:20:47FromGitter<mratsim> semantics =)
12:20:56livcdkrux02: really?
12:21:03FromGitter<alehander42> I am hired by zah who is payed by status
12:21:09FromGitter<alehander42> They really got us all
12:21:53krux02I am a bit worried that at some point status might Drop up all, because it isn't profitable enough.
12:22:30livcdkrux02: nah. dom96_w will persuade FB to buy Status
12:22:43krux02I mean, it is crypto currency, that is basically just gambling
12:22:52FromGitter<mratsim> yeah, @alehander42 when I looked into the other JIT like asmjit and xbyak, they all use either import from a csv write a file with the code you want. I feel like this is a much better way to generate and check what you are doing: https://github.com/numforge/laser/blob/master/laser/photon_jit/x86_64/x86_64_ops.nim
12:23:17FromGitter<mratsim> import from csv or write a file*
12:23:29*dddddd joined #nim
12:24:55FromGitter<alehander42> Seems cleaner maybe
12:24:58FromGitter<arnetheduck> all things come to an end, nothing to do about that
12:25:39FromGitter<mratsim> and cryptocurrency != blockchain
12:26:37FromGitter<narimiran> @arnetheduck only pre-1.0 phase never ends :P
12:26:50FromGitter<arnetheduck> hahaha :)
12:28:23FromGitter<mratsim> https://github.com/nim-lang/Nim/pull/9826 :partyparrot:
12:28:40livcdyou are all remote right ?
12:28:47livcdit's based in Switzerland just on paper
12:29:03FromGitter<mratsim> COO, CFO and couple of HR are in Switzerland
12:29:24krux02this is my personal opinion not my representative opinion: I think nim has too many features that all introduce problems. And before the problems are evened out and one can say that it is stable or the code has been properly cleaned up from the cruft that turned out to be non useful, a new feature is added.
12:30:02FromGitter<mratsim> I don’t disagree
12:30:28krux02I see my personal goal in the Nim to say no to new features. My only goal it to cut non essential features that nobody uses just to prevent bug reports from users who might end up using those features.
12:30:34FromGitter<mratsim> I would say, as expected of pre-1.0 too.
12:30:56livcdkrux02: but these days you can get hired by gogolxdong as well
12:30:59FromGitter<mratsim> There are a lot of undocumented features as well.
12:31:00krux02no that has nothing to do with pre-1.0
12:31:15FromGitter<arnetheduck> krux02 - you're not alone in that camp
12:31:40FromGitter<mratsim> gc:regions/sack/none situation can be cleaned up I think
12:31:52FromGitter<mratsim> gc:v2, not even sure what that is
12:32:00FromGitter<arnetheduck> well, even those in switzerland are not in the same city, so I'm not sure that counts
12:32:59FromGitter<mratsim> btw, we now have Float128? https://github.com/nim-lang/Nim/pull/9826/files#diff-c2f32b8561115a01d52343ae891a8640R429
12:33:11FromGitter<waghanza> hi
12:33:33FromGitter<waghanza> could I compile statically a `nim` app using `musl` ?
12:33:40FromGitter<mratsim> yes
12:33:52FromGitter<waghanza> ok
12:34:08FromGitter<narimiran> @waghanza https://scripter.co/nim-deploying-static-binaries/
12:34:10FromGitter<waghanza> I'll try to compare `nim` to `rust` and `go` then
12:34:11FromGitter<mratsim> you can check this post: https://hookrace.net/blog/nim-binary-size/ and there are a couple relevant on the forum as well
12:34:26FromGitter<waghanza> 👍
12:34:50FromGitter<arnetheduck> float128 has been in the compiler at least for a good while afair
12:35:14*abm joined #nim
12:35:16livcdbut i am sure Nim will receive 1bn$ investment very soon from some Chinese IoT company!
12:37:12krux02my guess about float128 is, that it once was a feauter that was disabled because it caused too many compatibility problems.
12:37:27krux02it wasn't entirely removed, but also not entirely activated.
12:37:56Araqfloat128 never existed.
12:38:03krux02ok
12:38:08Araqbut some preparations for it were done
12:38:47krux02when I want to add something that should work with 'all' types, for example macros.newLit, then I am never sure what to do with float128
12:39:35krux02I can't implement it, all I can do it a `when compiles(float128):` with some code in it that has never been tested.
12:40:09FromGitter<mratsim> what about int128?
12:41:36krux02doesn't exist afaik
12:41:41Araqneither float128 nor int128 are scheduled
12:43:03*vlad1777d joined #nim
12:43:31Araqthe only mention of float128 is in the manual in the desc of the 'f128 suffix
12:44:01FromGitter<alehander42> @krux02 I agree,existing features must be fixed, but I can't think of many actual new language features for 1.0
12:44:35FromGitter<mratsim> moving the stdlib to destructors is an actual new language feature for 1.0
12:44:49FromGitter<mratsim> but we need a 0.20 with that baked in by default first.
12:44:54FromGitter<alehander42> On the other hand some features are simpler than others and also fix problems, it should be always an individual decision
12:45:16Araqyeah and IMHO the destructor feature is just worth it
12:45:19FromGitter<alehander42> Well destructors are not new in my mind
12:45:25Araqincluding delaying 1.0
12:45:31FromGitter<alehander42> And they are good to get right before 1
12:45:42krux02I am ok with destructors, I wanted a way to get rid of the GC and destructors seem to be the only solution for seq and string types to not require a GC
12:45:43FromGitter<mratsim> bonus point if we can avoid having to call `NimMain` when linking to Nim
12:46:23FromGitter<mratsim> I do need the GC from time to time. And for async as well
12:46:38krux02mratsim: optimizing a build to not generate something that isn't necessary isn't a new feature
12:47:00krux02mratsim, how does async require a GC?
12:47:06FromGitter<arnetheduck> destructors seems to be a can of worms that can be used as a motivation to introduce corollary features due to the sunk cost of working on it - ie "destructors won't work well without X, X is small, let's just do one more X because we've already invested so much in destructors"
12:47:23FromGitter<mratsim> alies on closures iterators, you need something to own its memory
12:47:36FromGitter<mratsim> async relies
12:47:39FromGitter<mratsim> keyboard broken
12:47:45Araqwell new feature of not, changing how Nim's core works is not a small thing to do
12:48:39*bilebucket left #nim ("WeeChat 2.3")
12:48:40krux02arnetheduck: the goal is that you never need to actually implement any destructors. The automatic destructors that will destroy your standard collection members (seq/string) should be enough.
12:49:11krux02mratsim: you don't need GC for closures
12:49:39krux02only when the closure outlives the λ expression
12:49:55FromGitter<narimiran> btw, how 'close' are destructors? v0.20? v0.21?
12:50:22krux02narimiran: you can try them today --gc:destructors
12:50:45FromGitter<mratsim> I think his question is when do we switch the standard lib
12:50:52FromGitter<narimiran> yup
12:51:00krux02when it's done.
12:51:01FromGitter<arnetheduck> "let's do destructors.. oh, we also need sink and move.. oh we also need ref-counting or something for those pesky refs.. oh, and then there are exceptions that need love and attention, oh, and then it would be nice with a new type-bound proc syntax maybe.. oh, and what do we do about methods.. oh and..."
12:51:19FromGitter<mratsim> you forgot concepts ;)
12:51:25FromGitter<mratsim> and “VTABLE"
12:52:07FromGitter<mratsim> but only the first 2 are relevant, ref and ref counting are already here and solid.
12:52:46FromGitter<narimiran> btw, i was thinking if the time for 0.19.2 has indeed passed. if we decide to release it, that will probably prolong 0.20 for quite some time. maybe to cancel our 0.19.2 plans and release 0.20 sooner (so all the new stuff gets properly tested ASAP)?
12:53:00krux02if I would be at the decision table, I would drop concepts for 1.0 and leave them for experimental. I think they are not worth the trouble they introduce.
12:53:03FromGitter<arnetheduck> as of yesterday, they ref's were an unsolved problem because they bring non-determinism for destructors, and ref-counting is tricky because it brings cycles, and then threads, and then...
12:53:10FromGitter<narimiran> (for those who don't know, there is a 0.19 branch with backported features, planned for 0.19.2)
12:53:46FromGitter<mratsim> I think it’s fine to release 0.19.2 even if 0.20 comes 1 month after
12:53:46krux02(ok I am at the decision table, and I already pointed that out, but Nim is still a Dictatorship, my vote doesn't count)
12:54:08FromGitter<arnetheduck> Araq is on point here - it's a massive undertaking to change the core of the language
12:54:49FromGitter<arnetheduck> specially while looking out for your users and trying not to break too much for them
12:54:51FromGitter<mratsim> do concepts introduce trouble internally? I use them sparingly in my codebases but we do have a serialization module that relies on them in Status codebase
12:55:15FromGitter<narimiran> @mratsim based on our history, i'm willing to bet there will be much larger gap between two released versions. (heck, now it is already a month that we're talking about releasing 0.19.2 "this weekend")
12:55:36krux02mratsim: there is an issue that causes exponential compilation time. It is not yet resolved. But it also uses converters.
12:56:01krux02ok it is not exponential
12:56:19FromGitter<mratsim> ah, converters. I don’t really like those except from literals.
12:56:26krux02it is an infinite loop that get's canceled after may cycles of no success
12:56:46Araqnarimiran: well I'm counting on you for 0.19.2. and its never "too late" for it as I expect this branch to turn into the v1
12:57:12Araqwhy else would we backport bugfixes to it ;-)
12:57:43krux02mratsim: it is often the combination of several features that cause problems. The the features alone with the very stable core of the language.
12:58:15*kungtotte joined #nim
12:58:52Araqkrux02, well we fixed one combinatorial explosion due to converters if you remember correctly. ok, the fix is not yet in devel.
12:59:07Araqbut it was converters, not concepts.
12:59:34FromGitter<narimiran> Araq: ok, fair enough :)
12:59:47krux02yes I corrected myself it was converters and concepts at the same time. Not sure if that problem would have been reproducable with converters alone.
13:00:24FromGitter<alehander42> I think converters are helpful for dsls
13:00:41FromGitter<arnetheduck> btw, of all the functional libs out there that make it nice and smooth to work with collections and all, which is the most developed / functional / etc? zerofunctional?
13:00:45FromGitter<alehander42> I also dont like too much usage of them
13:00:55krux02I have a very conservative way of programming. For every feature of the language Nim I first do several tests and try to break it, before I start to rely on it. And with concepts I was unhappy how the syntax mixed up type and value expressions and tried to, always do the right thing.
13:01:15Araqand just fyi all your votes "count", that's why I'm here
13:01:29krux02na, you are the Dictator
13:01:48Araqyeah but you can influence me
13:02:15FromGitter<mratsim> I agree about the value and type mix syntax
13:02:24FromGitter<mratsim> it looks foreign
13:02:29krux02you are the dictator, we are the advisors
13:02:42FromGitter<mratsim> or the breakers :P
13:03:44FromGitter<alehander42> I don't think so
13:03:50FromGitter<zacharycarter> @citycide - but module / package manifests are useless without package managers to parse and interpret them
13:04:04FromGitter<alehander42> I think conceots are closer to macros for type matching
13:04:12FromGitter<alehander42> And I find them more nimlike
13:04:14FromGitter<zacharycarter> and I got your point - but I still think there is value in Nimble allowing for scripts - at least we need to be able to write custom build tasks somewhere
13:04:20FromGitter<zacharycarter> and I don't think everyone wants to go back to nake
13:04:22FromGitter<alehander42> Than pure declarativeness
13:04:26FromGitter<arnetheduck> fwiw, I find the concepts syntax awkward as well.. also because it's one abstraction step away - it doesn't declare what the concept is, rather it shows a computation you should be able to perform, and then you have to figure out what the concept is from that
13:04:43FromGitter<alehander42> Jacek you can say the same about macros
13:05:12FromGitter<alehander42> They are not something you use in 98' of the cases
13:05:18FromGitter<arnetheduck> yeah, that's why I avoid them / consider them for 100x-advantage cases - it's a big ask of your fellow developers to do that step
13:05:27FromGitter<alehander42> I think this is a bit like the case thing
13:05:48FromGitter<alehander42> People usually comment without actually experiencing problems with this in practice
13:05:49FromGitter<arnetheduck> whereas concepts is something I'd like to use freely because they're so immensly useful
13:06:38krux02arnetheduck: I try to use a concrete type instead of a concept. Because with that I know it won't cause problems in the future.
13:07:28FromGitter<waghanza> is there a plan for nim 1.0 ?
13:07:36Araqsorry guys, but this atmosphere here is getting toxic, for a lack of a better word.
13:07:38FromGitter<waghanza> I mean a schedule
13:07:39dom96_wkrux02: I think most of the core team wants to remove features
13:07:47Araqyes, features cause problems.
13:07:55Araqyes, nothing is ever perfect.
13:08:01Araqyes, nothing is ever "done".
13:08:20krux02what is toxic? did I say something wrong?
13:08:23dom96_wMy style insensitivity post is just the first step in my "Things that I want changed before v1.0" series ;)
13:08:46Araqit's like reading the D forum.
13:08:59krux02I wasn't active in there.
13:09:01dom96_wGood news for Araq is that I've resolved to accept style insensitivity :P
13:09:33krux02D was never enough for me to say, I am going to switch. Too much a C++ lookalike.
13:09:34Araqeverything always sucks and it's not worth getting up in the morning.
13:09:52Araqkrux02, I'm not talking about only you.
13:10:01FromGitter<mratsim> I thought that was just the lunch break for everyoone ;)
13:10:37AraqI'm optimistic.
13:10:38krux02Well I am developing Nim, because in a lot of ways Nim makes me happy.
13:11:15AraqAnd I tell you what. It's a prerequisite for getting shit done.
13:11:42krux02A lot of good design decisions.
13:12:07krux02yea and polishing things makes me happy.
13:12:13Araqand even what you now consider a hack might later turn out to be the solution all things considered.
13:12:23Araq*right solution
13:12:56krux02when I finally get to the point of understanding a syntem and then I see branches that can be collapsed and code duplicatian can be removed. That is satisfying.
13:13:25Araqthat is satisfying to you, but it might break somebody's code too
13:13:53krux02I know
13:17:37Araqat the same time, we are often not seeing the simple solutions. "waa, ref can create cycles and only tree like datastructures can be dealt with destructors, everything falls apart".
13:19:05Araqoverlooked solution: add an explicit system.free() for refs
13:21:04dom96_wyeah, it's easy to overlook solutions that don't seem "perfect"
13:21:23dom96_weven though in the long-term they are possibly much better than changing the architecture of Nim signficantly
13:28:20FromGitter<arnetheduck> is there a `flatten' or `join` somewhere in nim? something that turns `seq[seq[T]]` into `seq[T]`? there's `concat` but it seems limited to varargs
13:30:27AraqI dunno, I write for loops.
13:30:50def-arnetheduck: It's been suggested a few years back, but not added I think: https://forum.nim-lang.org/t/1762
13:33:08krux02arnetheduck: seq[seq[T]] is in my experience a very inefficient data struture to begin with, it would be best if you find a way to avoid creating something like that in the first place.
13:34:41krux02but there is sequilts.concat
13:35:04krux02but it takes varargs not openarry
13:35:46enthus1astis there a way to break out from asyncnet.recvLine if i want to sent to the socket instead?
13:35:51FromGitter<mratsim> @arnetheduck: https://github.com/hfp/libxsmm/blob/master/src/generator_transpose_avx_avx512.c#L50-L58
13:35:54FromGitter<mratsim> argh sorry
13:36:00FromGitter<mratsim> https://github.com/nim-lang/Nim/pull/6807
13:36:46FromGitter<mratsim> @krux02 we can’t, it’s Ethereum specs
13:36:56krux02enthus1ast, there is a timeout parameter
13:37:05enthus1astfor async?
13:37:32krux02https://github.com/nim-lang/Nim/blob/devel/lib/deprecated/pure/sockets.nim#L1258
13:38:12enthus1astthats for normal sockets krux02
13:38:29krux02sorry then
13:39:23enthus1astit seems not possible, peek is also not possible
13:40:47FromGitter<yglukhov> Araq: is there a reason why non-global methods are disallowed? I've removed the semantic check and error, and they seem to be working.
13:40:59FromGitter<zacharycarter> @mratsim - multi dimensional dynamic arrays are a part of the spec? blah
13:41:40krux02yglukhov, why don't you just use local proc?
13:42:02FromGitter<mratsim> No have committees (a seq) and a sequence of committees in Ethereum sepcs
13:42:06FromGitter<mratsim> we have*
13:42:32FromGitter<zacharycarter> ah
13:42:42FromGitter<yglukhov> krux02: err.. for the same reason why I would not use a global proc instead of global method? :) i need runtime dispatch.
13:43:25krux02runtime dispatch when the method is local?
13:44:27krux02I guess a method needs to be registered to the type somehow, but the method is only valid to use in that local block. I just think there are many ways to break it in a bad way and the simpler solution is to just disallow it.
13:45:09krux02Sometimes I would really like to see the code. My way of programming seems to be so vastly different.
13:45:37krux02I don't use methods at all. I do runtime dispatch, but normally I implement it in a if else or case statement.
13:47:08FromGitter<zacharycarter> I keep looking at - https://github.com/onqtam/Nim/commits/hot-code-reloading - every day :P
13:47:29FromGitter<yglukhov> krux02: see the test: https://github.com/nim-lang/Nim/pull/9830
13:48:13*floppydh quit (Quit: WeeChat 2.3)
13:48:37FromGitter<mratsim> when I look into methods, it’s basically implemented as a proc with a tree of if/else in the body.
13:49:35dom96_wenthus1ast: you should have an async proc running in the "background" blocked on recvLine always
13:49:42dom96_wIf you want to send data then do it in another async proc
13:49:52dom96_wYou shouldn't need to break out of the recvLine
13:50:03dom96_wCan you explain why you want to do this?
13:50:32Araqhttp://www.drdobbs.com/architecture-and-design/safe-systems-from-unreliable-parts/228701716
13:51:26krux02yglukhov. that test case doesn't need dynamic dispatch, nor does it access anything from the closure
13:51:32FromGitter<zacharycarter> so what is our shut off switch?
13:51:45FromGitter<zacharycarter> or system
13:52:11Araq" Given component A that has a 10% failure rate, we need to get it down to 1%. Improving the quality of that component by a factor of 10 will get us there, but at a cost explosion of 10 times the price. But suppose we add in a backup component B, that also has a 10% failure rate. The odds of A and B both simultaneously failing are 10% of 10%, or 1%. This is achieved by a mere doubling of the cost instead of an order of magnitude increase. The reliability can
13:52:11Araqbe further improved to 0.1% by adding another backup component C with 3 times the cost, instead of a hundred times."
13:52:12enthus1astdom96_w: i'm writeing a client for mpd, the protocol has an idle mode where i receive events, i already have another socket where i send commands to mpd, but i need a way to let the idle socket join a channel
13:52:24enthus1asti maybe found a way with "withTimeout"
13:52:28Araq^ a must-read.
13:53:05FromGitter<mratsim> @Araq that’s assuming that failures are independent. I.e. this is the assumption in financial markets but it’s not true at all.
13:53:15FromGitter<zacharycarter> so it's extra fail-safe via redundancy
13:53:19Araqthat's what he says too, read it.
13:53:25FromGitter<zacharycarter> yeah - he talks about the need for de-coupling
13:53:31FromGitter<mratsim> Practice in finance shows that when some start to fails, probability of other failing as well gets much higher than theory
13:53:33dom96_wNote: timeouts might work, but recv requests cannot be cancelled yet, so you might lose data (!)
13:53:53enthus1astmhh
13:53:54krux02Araq: hmm, I am not sure if those statistics are correct. You are dealing with computers they all fail at the same time because they are exactly identical.
13:54:08Araqread the article.
13:55:18FromGitter<zacharycarter> I just don't get what the backup is supposed to be
13:55:28FromGitter<mratsim> power cycle ;)
13:55:31enthus1astdom96_w: if i understand right you propose an "incoming" buffer?
13:55:31FromGitter<zacharycarter> heh
13:55:36FromGitter<mratsim> that’s what they used in the Mars Land Rover
13:55:41FromGitter<zacharycarter> truth
13:56:33FromGitter<yglukhov> krux02: the test is there to demonstrate the creation of a voldemort type with its methods. i didn't say anything about closure. methods can not be closures, at least i don't expect nor want them to. all i'm talking about is the lexical scope of method definition.
13:56:45FromGitter<mratsim> voldemort type?
13:56:56*vlad1777d quit (Ping timeout: 246 seconds)
13:57:47FromGitter<yglukhov> yeah, the type you can't refer by name, because it's local to the proc.
14:00:51dom96_wenthus1ast: I'm not sure, I still don't 100% understand the problem you are trying to solve
14:01:06dom96_wWhat does letting an idle socket join a channel mean?
14:01:57FromGitter<zacharycarter> I have a question - and this ties into some of the discussion b/w @arnetheduck and Araq yesterday... ⏎ ⏎ If we look at an example from asyncnet - https://nim-lang.org/docs/asyncnet.html#examples-chat-server - there are no doubt procs called in that example that will potentially raise exceptions and there is no handling code in the example
14:02:05FromGitter<zacharycarter> unless I'm totally off
14:02:43FromGitter<zacharycarter> and this could lead to resource leaks right?
14:03:10AraqI doubt it, an unhandled exception kills the process and the OS cleans up
14:03:18FromGitter<zacharycarter> okay
14:03:24Araqand please note that this code was written before .async really supported try-finally
14:03:39Araqand now that's supported, so things got better.
14:03:48FromGitter<zacharycarter> +1
14:04:27FromGitter<zacharycarter> I was just trying to understand @arnetheduck thoughts regarding Nim programmers not being careful to handle errors / let them explode through the stack
14:04:28dom96_wYes, even now I would still avoid handling errors in it because it would add a lot of noise.
14:04:44FromGitter<zacharycarter> and I was wondering if I had found an example of such a thing - because I know people look at that code a lot
14:04:57enthus1astsorry for being unclear: i have a socket where i mostely receive lines, but somethimes i need to also send a line then receive the answer to the line, then wait for lines again (i wait for lines in an dispatcher function, but also have must be able to send lines from another async proc)
14:05:28krux02zacharycarter: me neither
14:05:55krux02forgot to scroll
14:06:02FromGitter<yglukhov> @zacharycarter asyncCheck is one big example of bad error handling. it should be banned in its current form imo.
14:06:06FromGitter<zacharycarter> @krux02 - you neither what :P ?
14:07:03*nsf quit (Quit: WeeChat 2.3)
14:07:31FromGitter<zacharycarter> @yglukhov - is that because it has potential to raise a RTE and it's never being used inside a try/catch/finally?
14:07:36dom96_wenthus1ast: okay, so the problem appears to be that you've got a loop that continuously reads data from the socket and you've also got a proc that sends a command and expects a response. If you do that the loop will read it though and you have no way to connect these?
14:07:40krux02yglukhov: I don't think it is a good idea to support local methods and then disallow them to use closures. That is a lot of checks thet need to be implemented correctly for gain except that the method is written in another block
14:08:01enthus1astdom96_w: ye
14:08:03enthus1astdom96_w: yes
14:08:08FromGitter<zacharycarter> oh - you don't get what the backup process is - got it
14:08:26krux02zacharycarter: I was referring to this: "I just don't get what the backup is supposed to be"
14:08:33FromGitter<zacharycarter> well - I think @mratsim 's power cycle suggestion is a good one
14:08:39dom96_wenthus1ast: That's indeed tricky
14:08:59FromGitter<zacharycarter> if the power cycling system was coupled with everything else - it wouldn't be a viable option
14:09:20FromGitter<zacharycarter> but if I'm building a desktop application - it's hard to draw an analogy IMO
14:09:21Araqyglukhov: in the past I've been too quick with filling in language holes.
14:09:33FromGitter<yglukhov> @zacharycarter right. with `asyncCheck foo()` and foo raising eventually you'll get a non-deterministic raise in somewhere `poll`.
14:09:36Araqso there is little chance I want "local methods"
14:09:45dom96_wenthus1ast: plenty of ways to get around it though. You could register a callback in your state object whenever you send a command, then in your main loop check whether a callback exists
14:09:46FromGitter<zacharycarter> makes sense
14:10:03dom96_wor better yet, not even a callback but a Future which you complete in your main loop if it's not nil
14:11:29enthus1astthats the reason i've choosed to go with 2 sockets but now i must solve it somehow :)
14:11:40enthus1astahh good idea this could indeed work
14:12:41Araqzacharycarter: the point is that it's totally counter-intuitive but building each subsystem twice by independent teams is what to do to get reliability
14:13:16FromGitter<zacharycarter> I guess if you have time
14:13:29FromGitter<zacharycarter> and the people
14:13:46krux02that why we have multiple c++ compilers?
14:14:18FromGitter<zacharycarter> well we don't invoke multiple C++ compilers at the same time in case one fails haha
14:14:27Araqyeah, well quality costs money, but this approach is much better than the usual "work harder, use more unit testing, check for every single integer overflow"
14:14:30enthus1astthank you dom96_w i will try this
14:14:59krux02zacharycarter, but we do have the option to change the backend compiler in the middle of a project
14:15:16FromGitter<zacharycarter> I agree - at a certain point, unit testing stops being productive
14:15:18krux02so just because the fallback isn't automated it doesn't mean it isn't there
14:15:27FromGitter<zacharycarter> people look at test coverage as some type of metric to chase
14:15:28Araqand for Nim is might mean "focus on the spec and encourage multiple implementations"
14:15:47FromGitter<mratsim> Which raises the question, which spec? :P
14:15:52FromGitter<zacharycarter> hehe
14:15:54Araqmanual.rst
14:16:38krux02I think a second implementation will make a lot of hacks that work now a problem again
14:17:09AraqI think the much bigger problem is that it means 2x the testing effort for every Nimble package out there
14:17:39FromGitter<mratsim> But much more than 2x reliability
14:18:02Araqon top of the backends*CPU*OS*NimVersion matrix they theoretically have to test for
14:18:47krux02can't become worse than the web developers test matrix of multiple browsers.
14:18:54FromGitter<mratsim> ^
14:18:59FromGitter<zacharycarter> doesn't Lisp or Scheme have the same issues?
14:19:03FromGitter<mratsim> or Android devs
14:19:13Araqunless you target the browser because then ...
14:19:25Araqyou multiple the effort with these factors
14:19:43Araqso yeah, it all becomes "worse"
14:20:10FromGitter<alehander42> btw this reminds me , why dont we add special support for Nim to at least travis
14:20:17FromGitter<alehander42> crystal did it in 2015 or something
14:20:25FromGitter<alehander42> it will simplify CI for many nimble packages
14:20:33Araqbecause you didn't do that and nobody else did
14:20:37FromGitter<alehander42> and adding new backend etc would be very simple for package minatinaers
14:20:54FromGitter<alehander42> I am ok to try it when I have time, just asking if somebody tried that before
14:21:13FromGitter<alehander42> and pinging @arnetheduck as he seems to have a lot of xp with optimizing nim travis builds
14:21:45FromGitter<mratsim> I think it’s XP because no one updated our build system :P
14:21:56Araqand yeah, "good news, only clang crashes with our C++ code" is not exactly what "reliability" means
14:22:12Araq:P
14:23:26FromGitter<alehander42> :D
14:23:28Araq"your website doesn't render on Opera"
14:23:52FromGitter<mratsim> more like, your website doesn’t render when cookies are blocked
14:25:02FromGitter<mratsim> @alehander42 I’ve updated the wiki page on Travis recently, I think it shows all the use you might need: https://github.com/nim-lang/Nim/wiki/BuildServices#building-nim-projects-on-travis-ci
14:25:11FromGitter<mratsim> i.e. with or without Docker
14:25:15FromGitter<mratsim> against stable or devel
14:28:12FromGitter<zacharycarter> https://aws.amazon.com/blogs/aws/new-for-aws-lambda-use-any-programming-language-and-share-common-components/
14:28:41FromGitter<zacharycarter> so it sounds like it'd be easier to get Nim up and running on AWS lambda now
14:28:41enthus1astanother question dom96_w could i maybe also use callSoon for this? Does the callSoon proc runs before the recvLine?
14:29:16FromGitter<zacharycarter> last time I did it, it was somewhat painful
14:29:37dom96_wenthus1ast: I would suggest avoiding that
14:32:05FromGitter<yglukhov> Araq, krox02: there's indeed a problem that lambdalifting "works" on local methods, leading to c compiler error. But `{.nimcall.}` procs should also be prevented from lambdalifting, so you could think of a method as "always nimcall calling convention". Sidenote: lambdalifting is currently not prevented on {.nimcall.} (https://github.com/nim-lang/Nim/issues/8473).
14:32:42Araqyeah, known bug, easy to fix, will break code
14:32:51Araq(the story of my life...)
14:33:12*endragor quit (Remote host closed the connection)
14:33:14FromGitter<yglukhov> you mean "will break invalid code"? :)
14:33:19Araqyes
14:34:00FromGitter<mratsim> We can remove the hacktoberfest tag on that btw :p
14:34:03FromGitter<yglukhov> which will be then fixed by just removing {.nimcall.}
14:34:11Araqyes
14:34:57FromGitter<yglukhov> so you're saying the bug is going to be fixed, right? :)
14:35:11Araqactually I was saying "please fix it"
14:35:15Araq:P
14:35:58FromGitter<yglukhov> I will fix it. If you listen to me about local methods :P
14:36:07Araqno way!
14:36:24FromGitter<yglukhov> why?
14:36:35Araqpeople asked for "generic methods", poor Araq implemented them
14:36:42enthus1astdom96_w: the future solution seems good the only thing i see is that, when i'm already awaiting an answer, the futures runs after i receive a line on the `idle` socket, when i often get events this might not be an issue but when there is no event in a long time, the future will run late
14:38:51Araqand I don't like the solution, effort spent on a feature I ultimately want to kill
14:38:51FromGitter<yglukhov> Araq: lexical locality is orthogonal to generic, as i see it. Can you prove me wrong?
14:39:32Araqprobably, let's see. generic instantations are cached. the cache is not aware of the scoping
14:40:53Araqthe dispatcher generation logic wasn't written with the .closure calling convention in mind. but oh
14:40:57FromGitter<yglukhov> Do you want to kill methods altogether or make them first-arg-dispatchable(ala vtable)?
14:41:20Araqyou don't even want to support .closure, so all you do is shifting the "inconsistency" a bit further
14:41:56FromGitter<yglukhov> "the dispatcher generation logic wasn't written with the .closure calling convention in mind. but oh" - that's fine to stay like that.
14:42:26FromGitter<yglukhov> I'm shifting the inconsistency, true. Also I'm extending the possible use cases.
14:42:52Araqfirst-arg-dispatchable for v1.
14:43:33FromGitter<yglukhov> and kill for v2 or what? :)
14:43:50Araqnot sure
14:45:14Araqideally map them to "closure in an object" with a simple AST rewrite
14:45:37Araqas that's what I use for runtime polymorphism and I still like it best
14:46:30FromGitter<yglukhov> isn't that vtable embedded into an instance?
14:46:45FromGitter<yglukhov> which gets duplicated for every such instance.
14:46:50Araqyeah
14:47:26Araqbut usually the duplication is better than the indirection, ymmv of course
14:49:33Araqand you can always add an indirection of your own
14:50:08FromGitter<yglukhov> i like the fat pointer interface approach a lot. lets you do "multiple inheritance". and imo, perfectly fits nim procedural ideology
14:50:49FromGitter<yglukhov> did you consider that?
14:52:36Araqyeah but I don't see much advantages. I mean, you share the 'env' pointer over the "tuples of closures" solution
14:57:05FromGitter<yglukhov> well it's about implementing a new interface to *existing* object, without modifying it. with your approach you will allocate-and-init a new tuple of closures every time you need to convert the object to an interface. because you can't store that tuple along with the object because you can't modify it.
14:58:01Araqyou can always embed the *existing* object into whatever tuple/object you need.
14:58:28Araqyou can use a converter to do the delegation.
14:58:35FromGitter<yglukhov> you can't *always do that*.
14:59:02Araqok, when not?
15:02:50FromGitter<yglukhov> ```# third party ⏎ type Foo = ref object ⏎ proc getFoo(): Foo ⏎ proc ⏎ ``` [https://gitter.im/nim-lang/Nim?at=5c01511abc1a693e3a34b209]
15:04:18AraqI don't understand
15:04:54FromGitter<yglukhov> sorry, accidentally hit enter. one sec.
15:07:21FromGitter<yglukhov> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c01522843c68b3727daf0d6]
15:10:56Araqtype Wrapper = ref object of Foo
15:11:01Araq b: Bar
15:11:32AraqonProcessFoo = proc(f: Foo) = consumeBar(Wrapper(f).b)
15:12:37FromGitter<yglukhov> So isn't it what I said? "with your approach you will allocate-and-init a new tuple of closures every time you need to convert the object to an interface"
15:13:29Araqwell ideally 'Bar' is a value type
15:14:04Araqbut it's not clear if you complain about the efficiency or about the convenience or...
15:15:39FromGitter<yglukhov> efficiency - yes. convenience - i think it may be possible to make it convenient either way.
15:23:44FromGitter<alehander42> @mratsim yeah, this can be better(travis): it should be possible to just write lang: nim version: devel / 0.19 or something like that
15:24:15FromGitter<alehander42> I think they accept PR-s / support if >=3 people agree to support it, I will check later
15:24:36FromGitter<alehander42> (3 lang users*)
15:56:04*endragor joined #nim
16:00:29*endragor quit (Ping timeout: 246 seconds)
16:20:50*endragor joined #nim
16:29:33*xet7 quit (Quit: Leaving)
16:32:10*xet7 joined #nim
16:40:31*Trustable joined #nim
16:43:11*Jesin quit (Ping timeout: 246 seconds)
16:44:10*Jesin joined #nim
16:46:07FromGitter<arnetheduck> @zacharycarter https://github.com/nim-lang/Nim/blob/devel/lib/pure/httpserver.nim#L104 - that's a very simple example of both a file handle leak and a memory leak (from 9 years ago! there goes the theory that oss eventually gets fixed because it's open :)).. the way to think about exceptions is that each and every statement and expression in your code has a hidden / invisible `if error: goto unknown_location` after
16:46:07FromGitter... it.. it's not unfair to call code that is susceptible to exceptions non-deterministic, because for all intents and purposes, you can't make deterministic assumptions about it by just looking at the statements being executed. `async` compounds that problem - not only can every statement jump out, but you've also di ... [https://gitter.im/nim-lang/Nim?at=5c01694f500e8e37283bf3bc]
16:46:44*nsf joined #nim
16:46:57*Vladar quit (Remote host closed the connection)
16:49:08*banc quit (Ping timeout: 246 seconds)
16:49:26*dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:50:46FromGitter<arnetheduck> so what happens next is that people come up with features that help make it more safe / harder to shoot yourself in the foot - in `C++` you have `RAII` or deterministic destruction - that helps you add stuff to that `if error` thing, to turn it into `if error: cleanup; goto unknown_location`, rust adds borrowing that let's you tell the compiler "hey, I'm changing state here and here but not here" and the compiler
16:50:46FromGitter... in return can tell you "yeah, that's safe" and in functional languages, you can't change state, so *any* ordering of execution is safe
16:51:55*narimiran joined #nim
16:53:28FromGitter<arnetheduck> ultimately, these are all tools that help you narrow down where the problem might be - they decrease the surface are of where you have to look, when a problem happens, whereas exceptions and mutability are features that increase the surface area - there are more things that can go wrong - and in return you get convenience, or in the case of mutability, better mechanical sympathy between your program and the
16:53:28FromGitter... hardware, which in general means (in a good way) less abstraction and more performance
16:56:31FromGitter<zacharycarter> @arnetheduck - very good explanation thank you
16:57:48*banc joined #nim
16:59:00*dom96_w joined #nim
17:00:19FromGitter<zacharycarter> I have written < 10k lines of C++ code so my experience with destructors is limited, but I've used them before, and understand what they do.
17:00:33FromGitter<zacharycarter> I know that I find exception handling via try/catch/finally to be tedious and annoying most of the time
17:01:59FromGitter<zacharycarter> I found the C style of handling errors - where you're examining return values, to be less annoying, but also much less insightful (about what type of error was being raised) and much more prone to failing to be caught by holes in programs
17:03:24FromGitter<zacharycarter> not that it's much different than a try/catch/finally because it still suffers from the determinism problem you mentioned above
17:04:13FromGitter<arnetheduck> > and pinging @arnetheduck as he seems to have a lot of xp with optimizing nim travis builds ⏎ ⏎ @alehander42 I wouldn't really call it that - the status builds were the first time I tried.. there's nothing "novel" in those builds really - they just happen cache the right thing, the finding of which is mostly a boring and tedious process
17:05:42Araqif doesn't have `if error: goto unknown_location`, it has `if error: goto except/finally/return`
17:07:03Araqand indeed RAII also helps with exception free code that happens to use 'return'
17:08:26FromGitter<zacharycarter> I'm very excited about `gc:destructors` but I can only imagine that featuring destructors upon all the other language features is getting into "very complex" territory for the compiler and runtime
17:08:48FromGitter<zacharycarter> along with the move semantics
17:08:49Araqand if your proc has no 'try' statement it becomes 'if error: return', not exactly "not deterministic control flow"
17:09:31Araqbut I can see that it weakens your argument, so we better adhere to your hand-waving terminology.
17:10:03FromGitter<zacharycarter> sorry - I don't mean to start a war here - I'm just trying to gain a better understanding of the friction in the community right now
17:10:08FromGitter<zacharycarter> or a battle rather
17:10:45FromGitter<zacharycarter> over this topic
17:12:14FromGitter<zacharycarter> I have faith in Araq and Dom and the core Nim devs
17:12:26FromGitter<zacharycarter> plus all of the major contributors
17:13:28FromGitter<zacharycarter> including you @arnetheduck :) - you guys are all very smart people
17:23:34FromGitter<arnetheduck> well, it's `if error: longjmp to some setjmp:ed location` or `if error: dwarf-jump to landing pad` to be specific, so as the compiler is compiling the function, it doesn't know where the jump will go and therefore cannot analyze if it's "safe" from a resource-usage / state-manipulation pov - also, as a human reading the code, it's incredibly hard to reason about when it's going to happen, because it *may* happen
17:23:34FromGitter... with any statement - that's what the qualification "for all intents and purposes" meant to convey - the part about people not really being good at this.. and yeah, you can plug some of the holes with `defer` and `finally` and `except`, but they're all "manual", drastically decreasing the likelihood they'll get used, ... [https://gitter.im/nim-lang/Nim?at=5c017216500e8e37283c3015]
17:27:39FromGitter<arnetheduck> and again, sometimes this is the right choice.. you have an OS running around you that will clean up your mess - just crash, let the supervisor restart you, and you have a fresh batch of 1024 file descriptors to leak, or whatever - why waste the effort?
17:33:07*narimiran quit (Remote host closed the connection)
17:34:04FromGitter<iffy> Anyone familiar with `jnim` that knows how to call a method on a Java object from nim?
17:34:26FromGitter<iffy> (an object given to Nim by a JNI call)
17:46:24FromGitter<yglukhov> @iffy ;)
17:46:37FromGitter<iffy> Didn't know if you were around :)
17:46:49*masquino joined #nim
17:47:18masquinohello all! I'm getting some weird Resource is temporarily unavailable error when running `nimble init`. Is anything broken? Or is it just me?
17:49:29FromGitter<yglukhov> @iffy, so... is it your question? :) It's kinda the first few lines of the README.md
17:49:38FromGitter<iffy> @yglukhov I'm trying to get something I can paste.
17:54:05FromGitter<iffy> I've tried both with jnim and without (using `emit`). Here's pseudo code for what I'm trying to do:
17:54:27FromGitter<iffy> @yglukhov https://gist.github.com/iffy/1515cda0c1bc1af77ae2cf6c61fdfe2b
17:55:14FromGitter<iffy> When I call `executeSomeJS()` the app crashes -- I'm just now digging in to see what the error is
17:55:51FromGitter<iffy> I wish I had a complete example rather than pseudo code, but it's a bit of a huge mess right now
17:59:07FromGitter<iffy> no traceback in the log. The process just dies
18:04:24FromGitter<yglukhov> smth like this ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c017ba79f38cc0fd5844ee6]
18:05:14FromGitter<yglukhov> I assume the problem with your code is that you store a jobject without creating globalref. WiishActivity.fromJObject does that under the hood.
18:06:05FromGitter<yglukhov> also make sure the Java_org_wiish_exampleapp_WiishActivity_wiish_1init is correct. note the first argument is `this`.
18:07:05FromGitter<iffy> so myInit doesn't accept a JNIEnv?
18:07:14FromGitter<iffy> (or that's handled underneath, too?)
18:08:17*krux02 quit (Remote host closed the connection)
18:08:54FromGitter<yglukhov> Oh, thats my mistake, sorry :)
18:09:05FromGitter<yglukhov> Jnienv should be there
18:10:28FromGitter<iffy> `JNIEnvPtr`?
18:12:24FromGitter<yglukhov> Doesnt matter, you're not using it. pointer is good enough :)
18:12:39FromGitter<iffy> hehe, k
18:13:45FromGitter<iffy> `Error: attempting to call undeclared routine: 'fromJObject'` do I need to import more than `jnim` and `java/lang`?
18:15:33*dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:17:01FromGitter<iffy> oh, nm, template problem. Wasn't importing it in the template
18:22:43*endragor quit (Remote host closed the connection)
18:31:25*nolanv left #nim ("WeeChat 2.2")
18:36:16FromGitter<iffy> @yglukhov I'm getting `JNI DETECTED ERROR IN APPLICATION: JNI NewGlobalRef called with pending exception java.lang.NullPointerException: Attempt to invoke virtual method 'void android.webkit.WebView.evaluateJavascript(java.lang.String, android.webkit.ValueCallback)' on a null object reference`
18:37:22FromGitter<iffy> and since `WiishActivity.evalJavaScript` calls `webView.evaluateJavascript`, I'm at least making it into that function. But for whatever reason, the `webView` property is null
18:38:10FromGitter<iffy> https://github.com/iffy/wiish/blob/mobile-jsbridge/wiishpkg/building/data/android-webview/app/src/main/java/org/wiish/exampleapp/WiishActivity.java#L46
18:45:38*Jesin quit (Quit: Leaving)
18:53:55*Jesin joined #nim
18:54:02FromGitter<iffy> @yglukhov do I need to call `initJNI()` or is that taken care of by virtue of the Android JVM running my code?
19:18:43Araqarnetheduck: my point is that the *lack* of 'try' makes it significantly easier to reason about to the point that the arguments becomes "I don't know the caller that return will return to"
19:18:46*Jesin quit (Quit: Leaving)
19:20:09Araqand destructors avoid the 'try', that's one of their purposes.
19:20:29Araqbbl
19:21:35*Jesin joined #nim
19:22:54FromGitter<arnetheduck> yeah, that's a good point - and it's in line with what I wrote, that once you have exceptions, you also need a bunch of other tools to "automate" unwinding etc (or really to deal with the mess that exceptions introduce), so that you get at least passable robustness in the face of errors..
19:23:49FromGitter<arnetheduck> with that agreement, we should really head out for a 🍺 to stave off any rumors of wars going on :)
19:32:58*zachk joined #nim
19:36:06*zachk quit (Changing host)
19:36:06*zachk joined #nim
19:37:31FromGitter<zacharycarter> lol - I didn't mean war I meant battle / fight / whatever
19:56:29*PMunch joined #nim
20:03:10FromGitter<arnetheduck> er, debate is the word, I think - it's the internet, the one way you can move ahead is through consensus and working code - not an arena conductive to fights :)
20:05:39FromGitter<zacharycarter> its true - though you two have a tendency to toss grenades at one another - or at least that's how it comes across
20:05:51FromGitter<zacharycarter> not knowing either of you personally, it's hard to judge if feathers are getting ruffled or not
20:06:41FromGitter<zacharycarter> I suppose if they were, you would cease interacting
20:07:06FromGitter<rayman22201> Reminds me of this article about creating better concurrency primitives (good read btw): https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
20:09:07*matti quit (Ping timeout: 246 seconds)
20:09:50FromGitter<rayman22201> related to @arnetheduck's statements about exceptions being non-deterministic. In this case, the article is talking about error conditions escaping their environment when threads get involved, resulting in non-deterministic reasoning (similar to how goto makes it hard to reason about functions).
20:16:25FromGitter<arnetheduck> yep.. libraries like tbb are centered around the same idea, that the structure of the tasks you want to perform is bound to something tangible - like the nursery or some other synchonization point you and reason about
20:17:39FromGitter<arnetheduck> it's a little mini-world within which shit still can happen, but at least you can determine the bounds of it, just like in traditional functions without exceptions, you can make assumptions that simplify reasoning
20:18:01FromGitter<rayman22201> Or Haskell monad land :-P
20:18:09FromGitter<rayman22201> IO monad*
20:18:23FromGitter<rayman22201> Tangentially, I think the "handleErrors" concept that was linked yesterday is pretty cool: https://gist.github.com/zah/d2d729b39d95a1dfedf8183ca35043b3. I like the idea of forcing the caller to deal with errors or explicitly ignore them. It gets tough when then pattern isn't followed all the way down though. (thus Araqs statements about making {.push raises [] .} for making the stdlib behave better. Though that is
20:18:24FromGitter... kind of a stop gap measure.)
20:23:12*endragor joined #nim
20:27:32*endragor quit (Ping timeout: 246 seconds)
20:48:27Araq"mini-worls within shit can happen" -- so ... a "try except" environment?
20:49:18Araqthe more I think about it, the more shallow the arguments against exceptions become.
20:49:29*dddddd quit (Ping timeout: 268 seconds)
20:50:12Araqhere is a piece of code, a[i-1] = b[i] + c[j], want to know where it can possibly fail?
20:50:36Araqeverywhere.
20:51:09Araq- can underflow, + can overflow, array index to a can fail, access to b can fail, access to c can fail.
20:51:46Araq"but, I want to be able to *see* where the failures can come from so I annotate every subexpression with 'try'". That's cargo cult programming.
20:54:27*dddddd joined #nim
20:57:37FromGitter<rayman22201> In some domains, you do basically that. I.E. Ada with SPARK, or Idris
20:57:47Araqbesides, if 'write' doesn't return anything, what do you think it does on error? it throws IOError, d'oh, that was so hard to reason about. Do know what it shit about IOError? The "IO" part, there is no need for more than one type of recoverable error type.
20:59:36Araqin fact, if it can return multiple errors that all can reasonably require different error handlers, that's when you switch to an enum as the return type.
21:01:07*NimBot joined #nim
21:01:23FromGitter<arnetheduck> an enforced `try..except` environment where structure gives you no option - but provides a sandbox that you can use to divide and conquer the complexity
21:02:43Araqand I don't mind "terminate" but it doesn't compose well. I see it as a hacky 'raise' implementation.
21:04:48FromGitter<rayman22201> lol, if by 'raise' you mean 'raise' up to the OS
21:06:29FromGitter<rayman22201> or "terminate and restart" in the case of the Mars Rover / embedded environment.
21:07:24FromGitter<arnetheduck> as noted, the mars rover was more like `terminate and wait for manual check`
21:07:49FromGitter<arnetheduck> everything else was scheduled / ordinary
21:09:47FromGitter<rayman22201> sure. I think the "terminate" is the important point here though
21:13:52Araqin the Nim compiler 'nimcache' has to be created somewhere with createDir. That can fail. What to do:
21:14:25Araqa) make every single proc in the compiler return Either[T].
21:14:53Araqb) call: quit "cannot create directory". (Er, what about clients of the compiler API then?)
21:15:03Araqc) let it raise an exception.
21:16:44Araqd) add a callback to the compiler API "what to do when createDir fails".
21:17:21FromGitter<rayman22201> This reminds me of the arguments around Java "checked exceptions"
21:17:37dom96Nim has checked exceptions too ;)
21:17:41dom96And they are awesome
21:19:10AraqI like solution (d) but I notice that is not what anybody so far has argued for and that this callback would better be allowed to call 'quit'
21:19:30Araqwhich is a poor man's raise.
21:20:43FromGitter<rayman22201> @dom96 you mean the exception tracking system? @araq: c and d seem like duals of each other to me.
21:21:36dom96Araq: Are you 100% for exceptions these days? :)
21:21:58FromGitter<zacharycarter> well if you enforced D) - you'd add a bit more constraint
21:22:04FromGitter<zacharycarter> although people could just do nothing inside of the callback
21:22:12FromGitter<zacharycarter> so I'm not sure what it accomplishes
21:22:17FromGitter<zacharycarter> vs just allowing them to handle the exception
21:23:28FromGitter<zacharycarter> @rayman22201 - the nursery article is very good, thanks for sharing that
21:23:49FromGitter<rayman22201> 👍
21:23:49FromGitter<zacharycarter> I think I saw it before but didn't read it all the way through, which was a mistake
21:24:06FromGitter<rayman22201> It's a bit long, but it has some good bits
21:24:20FromGitter<zacharycarter> definitely does
21:24:21PMunchHmm, nimsuggest doesn't return anything if you try to execute "use" on the attribute of an object
21:24:37PMunchBut it does work if you run it where it is defined
21:24:57*smitop_ joined #nim
21:25:17PMunchSo it will work if you run in on line 2, but not if you run it on line 17 here: http://ix.io/1uXj/Nim
21:31:39AraqPMunch, I think I know this bug :-)
21:31:54PMunchAh so it is a bug and not a feature :)
21:32:09Araqin some strategic place a 'onUse' is missing
21:33:11Araqdom96, I think we can simplify Nim's exceptions further and maybe even change the codegen strategy for them
21:33:53Araqbut the arguments against exceptions are more and more unconvincing.
21:35:47FromGitter<rayman22201> Why do you not like option A.) @Araq ? Either type all the places
21:36:19Araqtake this for example http://joeduffyblog.com/2016/02/07/the-error-model/
21:36:37Araqhe argues very well and knows what he is talking about.
21:36:54Araqand yet ... he is full of shit.
21:36:59Araq"This reminds me of On Error Resume Next in Visual Basic, and the way Windows Forms automatically caught and swallowed errors thrown by the application, and attempted to proceed. I’m not blaming Anders for his viewpoint here; heck, for C#’s wild popularity, I’m convinced it was the right call given the climate at the time. But this sure isn’t the way to write operating system code."
21:37:36Araqer, that is exactly what Midori ended up using too.
21:37:42*wildlander joined #nim
21:38:38*jxy quit (Quit: leaving)
21:38:46Araqoverflow in Midori causes "abandonment", in other word it calls 'terminate'
21:39:01Araqand since you don't the OS to shut-down all the time, stuff gets restarted
21:39:17Araqso ... it's in a try except section.
21:41:36*nsf quit (Quit: WeeChat 2.3)
21:42:56FromGitter<rayman22201> He basically agrees with you in his paragraph titled: "Enter Exceptions"
21:43:23FromGitter<rayman22201> Although I think this is an important point: "although Midori had exceptions, a method that wasn’t annotated as throws could never throw one. Never ever ever. "
21:43:30PMunchAah, the beauty of metaprogramming :) Just saved myself a run-time crash because my jsonschema library checks if a field can possibly exist in the Json data when it's validated :)
21:43:52Araqrayman22201, but everything can "abandon"...
21:44:13Araqwhich is like Go's "panic" btw.
21:44:34Araqyeah right, you are not using "exceptions" because you used a different term, congrats
21:46:06FromGitter<rayman22201> Well, this goes back to your "improved exceptions rfc" a while back. The idea of separating true "non-recoverable" errors from "recoverable" errors is important.
21:46:40FromGitter<rayman22201> I don't think the mechanism is the issue, it's the categorization.
21:48:54Araqwell I agree with the separation but I also notice that it might as well be wishful thinking on his and mine part.
21:49:17PMunchWhat's the status on https://github.com/nim-lang/Nim/pull/9818 by the way?
21:49:17Araqthey created a system where components are restarted on failure.
21:49:47Araqwho knows how many real "bugs" they can deal with by the very same mechanism
21:50:47Araqhe *thinks* that these throws and try annotations improved the robustness but then they went ahead and did runtime monitoring
21:51:25Araqno numbers to back up his claims, no control group B.
21:53:08*kapil____ quit (Quit: Connection closed for inactivity)
21:53:14Araqand Erlang only does the runtime stuff and people report it produces robust systems too.
21:54:32*wildlander quit (Quit: Konversation terminated!)
21:55:52Araqthe Sqlite authors argue they don't care about C's static typing or tooling because they have 100% line coverage including tests that simulate OOM conditions.
21:57:06Araqit's of course expensive to develop in this fashion, it's much cheaper to blame the used programming language instead for the crapware one produced
21:57:25*stefanos82 quit (Remote host closed the connection)
21:57:27*xet7 quit (Quit: Leaving)
21:57:29*jxy joined #nim
21:57:38*wildlander joined #nim
21:57:58FromGitter<rayman22201> He actually seems to suggest that his "abandonment" solved the most "bugs". Which is arguably pretty close to the Erlang model. Though you are correct. There is no control group or valid numbers so it's hard to take a proper scientific result from the article.
21:59:45*Jesin quit (Quit: Leaving)
22:00:12Araq"We solved the easy problems and gave up on the hard one and restarted the subsystems"
22:01:08Araqthat's not good enough.
22:02:38FromGitter<rayman22201> Sqlite is on the other end of the spectrum, but they have had years of real world testing as well, and no control group there either. so it's hard to say if their approach is any better. You could write "perfect" software in Coq or Idris by mathematically proving all cases of your software. That's good enough but arguably too expensive and impossible in some cases.
22:03:38Araq"For the rest? Yes, you guessed it: abandonment. Nice and simple.
22:03:38AraqIt was surprising how much of this we got away with. I attribute most of this to the isolation model. In fact, we could intentionally let a process suffer OOM, and ensuing abandonment, as a result of resource management policy, and still remain confident that stability and recovery were built in to the overall architecture."
22:03:49FromGitter<rayman22201> @Araq, I feel I'm distracting you from real issues from people like @PMunch. sorry
22:03:52Araqso he says it himself.
22:04:21FromGitter<rayman22201> yeah, that's basically Erlang
22:04:36PMunchDon't worry about it, I was just wondering what the status of the PR was. I'm just eager to update nimlsp with new and neat features :)
22:04:48AraqPMunch, sorry, looking at it now
22:04:59Araqthe status is "I need to see if PMunch is right"
22:05:24PMunchnimlsp actually works pretty well now, but it takes a lot of time to initialize when you open the file..
22:05:29PMunchOh cool :)
22:09:14AraqPMunch, ok, so ...
22:09:36AraqexecuteEpc sets these hooks but execute doesn't anymore
22:09:45Araqbut executeEpc is EPC specific code
22:10:26PMunchHmm, I intended to add it everywhere execute was called
22:11:20PMunchOh yeah, it alsa does it in execCmd
22:11:32PMunchL441-446
22:12:20Araqok, but why?
22:12:37Araqit's easier to understand in the current version
22:13:10PMunchWell the thing is that the library also calls execute
22:13:22FromGitter<arnetheduck> so when you write software, there's an unwritten contract between you and the user.. this contract generally is referred to as "common sense", or the shared understanding which errors you're expected to deal with, and which errors the user is expected to deal with.. so there are two things that can happen - you can fail to live up to the common sense, or the sense might not be so common after all.. it's the first
22:13:22FromGitter... category that I want my programming tool (compiler) to help me with, so that insofar as is possible, I can uphold what I believe is sense and what I assume others share with me
22:13:42PMunchBut the structuredErrorHook callback won't work for that since it tries to write to one of the channels
22:13:51PMunchAnd the library doesn't use channels
22:15:14AraqPMunch, ok but then it's easier to introduce a rawExecute or executeNoHooks and have execute this helper
22:15:24Araqand your lib calls this helper too then.
22:15:31FromGitter<arnetheduck> in the compiler sense, if the folder doesn't exist, it's common sense, or "culture" between me and the compiler writer to say that I, as a user running the compiler, can deal with it.. that changes when I'm a library user - then I want command and control, and I want the api of "compilethebloodycode(x:string)" to tell me that a possiblity for errors exist and what these are, so that I, the library consumer, can pass
22:15:31FromGitter... on my common sense to my users, and not be beholden to the sense of the original compiler writer
22:15:49PMunchHmm, I guess that makes sense
22:15:53Araqbut I agree it's hard to come up with a good name for it
22:16:47FromGitter<arnetheduck> thus, a compiler that allows for errors to be seen and dealt with, and allows whoever is calling both discover and choose the "what-if" handling for the missing directory, is one that's more powerful, insofar as it allows both behaviors - at a price though - it'll have a more complicated API
22:21:25*jxy quit (Quit: leaving)
22:23:12Araqarnetheduck: createDir is an easy example, consider this
22:25:20Araqin 'nim check' (and nimsuggest, ...) the compiler resumes after an error. one way to do this is to raise an exception when an error is found and then you have a 'try except' handler in the semantic checking for top level statements, so that after an error in proc A the analysis proceeds with proc B
22:25:54*jxy joined #nim
22:28:42Araqand why should this "top level statement" granularity imply "every top level statement" runs in its own process? Midori and Erlang tie the error mechanism to a process isolation mechanism.
22:31:02Araqthat helps robustness but also causes "friction"
22:32:52Araqand there is no reason to assume that the heap is corrupted after semcheck found an error in the programmer's AST
22:35:20Araqthe Nim compiler in Midori means every proc is 'throws' and every single call I make is annotated with 'try'.
22:35:43FromGitter<arnetheduck> it's not a bad escape hatch to have - agreed - and of course there are situations where it makes sense - but on average, if I look at which error handling mechanisms lead to software with less bugs - specially the critical or larger-scale kind where reliability matters, or where programmers are more aware of "what could possibly go wrong" - it's not gonna be the exception-based world - and I think I've mentioned it
22:35:43FromGitter... several times now - exceptions have a time and place - python wouldn't be python with explicit error handling - it would suck in that world... but then again, you don't put python and reliability in the same sentence - just like static typing is onerous, it also removes the possibility for a certain class of issue ... [https://gitter.im/nim-lang/Nim?at=5c01bb3f8fa4333e391ca816]
22:36:41Araqunless I say "fuck this shit" and use 'quit', er sorry, 'abandon'
22:37:53FromGitter<arnetheduck> oh, I'm fine with that actually - it's at least honest - it basically says.. "I have no idea what to do with this mess and I don't want to throw you under the bus by giving you a false sense of security"
22:38:35FromGitter<arnetheduck> > no reason to assume that the heap is corrupted after semcheck
22:38:55FromGitter<arnetheduck> so give the language a language to tell the compiler this, so the compiler can help me find the cases where I was wrong
22:44:59Araq"put python and reliability in the same sentence" -- but maybe if add some Erlang'ish features to it...
22:45:06Araq;-)
22:47:36Araqand for me static typing is nice as a "typo catcher", for readability and for helping the compiler produce fast code.
22:48:02Araq"correctness" is not really among its virtues
22:48:41Araqesp if you want a type system that a human being can still understand.
22:49:13FromGitter<rayman22201> lol. wait, what? by that argument, you would use lisp with a fancy IDE?
22:49:47Araqlisp has no static typing and a syntax I dislike. why would I use it?
22:49:52*Trustable quit (Remote host closed the connection)
22:50:15Araqdon't get me wrong, a "typo catcher" is a brilliant thing and I don't want to miss it
22:50:34FromGitter<rayman22201> > for me static typing is nice as a "typo catcher" ⏎ a fancy IDE has a similar role
22:50:38XeAraq: because people used a globally distributed pub/sub system to tell you to use lisp. They put words on your screen, that means you have to listen to them now.
22:50:59Xe</s>
22:51:11Araqrayman22201: I think we mean different things by "typo catcher"
22:51:38Araqit includes stuff like "no, that object has no field called 'f'"
22:51:40FromGitter<rayman22201> possibly. I think type systems are much stronger than "typo catchers"
22:53:12FromGitter<rayman22201> "correctness" is hard regardless, it depends on the domain and is np complete. I'm more interested in "robustness" with the whole exceptions thing.
22:55:52AraqIME Nim's robustness can increase much more by removing/avoiding Nim's GC.
22:57:28FromGitter<rayman22201> For me it's a categorical thing. There are times that I don't care about errors. In this case, die and give me a good way to help me debug (stack trace, etc...). There are times when there is no way I could have handled the error anyway. In this case, again, die and help me debug. Then there are cases when I really care about the errors. In this case I want the compiler to help me make sure I actually handled every
22:57:28FromGitter... error case and didn't forget one. Checked exceptions / exception tracking do solve this problem, though as with all these kinds of solutions it works better when it's more deeply integrated into the language (i.e. into the std lib and the compiler apis.)
22:59:20Araqwell I don't mind "die" either but it makes library development tedious
23:02:09FromGitter<arnetheduck> so you see, you're the source of the supervisor idea after all: write shitty but small components, so that the loss of one isn't fatal, then do a wrapper that cleans up the mess :)
23:03:02FromGitter<rayman22201> lol
23:03:31Araqok, "I am the source". I am not sure what that means but I can live with that.
23:06:49FromGitter<rayman22201> There seems to be two camps around robustness, the "fail fast and recover" people and the "verify all possible states are handled" people.
23:13:53FromGitter<zacharycarter> > IME Nim's robustness can increase much more by removing/avoiding Nim's GC. ⏎ ⏎ But that takes time right? Since a lot of the stdlib relies on it?
23:15:00Araq the stdlib is rather easy to patch though, it doesn't create cycles
23:15:10FromGitter<zacharycarter> gotcha
23:15:29Araqand for async code there are also solutions
23:16:02FromGitter<zacharycarter> well - I'm very much looking forward to the new gc and the hot code reloading - as a user anyway
23:16:12FromGitter<zacharycarter> I obviously can't really speak much from a contributor / maintainer perspective
23:16:48FromGitter<zacharycarter> regarding how much overhead and complexity they add
23:17:00Araqthe compiler itself will rely on a GC for a looong time though :D
23:17:22FromGitter<zacharycarter> :)
23:20:17Araqbut hey, there is no rush for it to get rid of it and in the past massive compiler refactorings were surprisingly effective
23:20:45AraqI mean "effective" in the sense "caused few regressions"
23:36:27*kapil____ joined #nim
23:37:52Araqyay, incremental compilation doesn't produce wrong C code anymore. now it produces linker errors
23:38:05Araq:-( time to go to sleep
23:38:56FromGitter<zacharycarter> night!