<< 23-01-2019 >>
00:01:24*Jjp137 joined #nim
00:25:50*leorize joined #nim
00:33:41FromGitter<dandevelo> More details here: https://forum.nim-lang.org/t/4581
00:46:38leorizeInstead of linking staticlib with Nim, you could just do the ordinary "import"
00:47:09leorizecurrently the lib generation options only generate libs for use outside of Nim
00:54:51FromGitter<dandevelo> @leorize what if I need to use multiple libs created with Nim in the same application outside of Nim?
00:55:11leorizethat's not possible atm, sadly
00:55:42leorizethe GC has to be shared, so we have to wait until someone manage to split the GC to a lib of it's own
00:57:04*Tyresc quit (Quit: WeeChat 2.4-dev)
01:04:34rayman22201https://nim-lang.org/docs/nimc.html#dll-generation
01:04:39rayman22201use nimrtl
01:04:49rayman22201that is literally the GC split into it's own lib
01:05:01*zachk quit (Quit: Leaving)
01:05:27*abm quit (Ping timeout: 244 seconds)
01:05:38rayman22201or use one of the no GC options. --gc:none, --gc:regions, or --gc:destructors
01:06:52rayman22201idk what's up with the noMain issue. That seems like a bug, but I'm not sure.
01:07:02leorizeNimMain is used to initialize the Gc
01:07:08leorizeit'll always be there
01:07:39leorizenimrtl is bigger than just the GC however
01:07:49leorizeand it's a shared lib :/
01:09:29rayman22201it's a valid option, what ever your opinion of shared libs.
01:10:19leorizewell, the person asking want to use static libs
01:10:40leorizewith a bit of modification it might be possible to generate static nimrtl however
01:10:52rayman22201that's a good point. I missed that. :-/
01:12:20rayman22201this makes the no gc options seem more attractive.
01:13:30leorizewell NimMain also inits the module, should there be any initialization code
01:15:49rayman22201true
01:17:20*skellock joined #nim
01:25:05JnRI have a good question. I thought of the idea of a cross platform compiler being run strictly as a liveboot on my Raspberry Pi and acting like a cross-platform translator for running virtual machines and x64 programs on Arm7. I found out that Nim actually has a cross-platform function built into it. Has anyone tried anything like this?
01:26:15JnRObviously the Arm7 device would have to have a significant amount of memory but I think it can be done
01:32:22*darithorn quit (Quit: Leaving)
01:35:25rayman22201Nim just spits out C. So if you have a C compiler for a platform, you can cross compile to it. In theory anyway... Cross compiling is a bit of an art in practice.
01:37:33rayman22201Your bigger problem is not memory. Arm is notoriously bad at x86/x64 emulation (same going the other way as well. This is why android emulators typically have crap performance). It's very slow. Not because of memory, just because the assembly languages and architectures are so different.
01:41:18*ghost64 quit (Read error: Connection reset by peer)
01:42:13FromGitter<JasperJenkins> Is this a bug or is their some logic I'm not seeing? ```proc returnsInt(): int {.compileTime.} = ⏎ var x = 1 ⏎ ⏎ proc noReturn() {.compileTime.} = ⏎ var x = 2 ... [https://gitter.im/nim-lang/Nim?at=5c47c675cb47ec300088470f]
01:46:12*ghost64 joined #nim
01:47:04rayman22201better: https://pastebin.com/raw/RrKEhDDQ
01:47:14rayman22201You are trying to run a compileTime proc at runtime
01:49:40JnRrayman22201 Yeah that's pretty much the answer I was expecting. I only want to use the Arm device as a remote host but I guess you can't just float over top of the architecture
01:50:19rayman22201@JasperJenkins, does that make sense?
01:50:19*xace quit (Ping timeout: 246 seconds)
01:51:15rayman22201@JnR, yeah. Still neat idea though :-P
02:50:15*darithorn joined #nim
03:01:55*JnR quit (Remote host closed the connection)
03:02:06*banc quit (Quit: Bye)
03:10:57*skellock quit (Quit: WeeChat 2.3)
03:22:46*banc joined #nim
03:37:26*Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
03:44:49*darithorn quit (Remote host closed the connection)
03:50:58*darithorn joined #nim
04:00:28*smitop quit (Quit: Connection closed for inactivity)
04:07:38*xace joined #nim
04:21:26FromGitter<kaushalmodi> I am trying to get `gzgets` from `zip/zlib` to work for a while, but am out of ideas: https://ptpb.pw/Tpe-/nim
04:24:33FromGitter<kaushalmodi> If I replace `gzgets` with a `gzgetc` loop, it works. I had a typo in the earlier link, but even after fixing it (see updated in https://ptpb.pw/DDTl/nim), I have the same issue
04:24:50FromGitter<kaushalmodi> the `line` read is always an empty string and the file pointer never increments
04:25:52*nsf joined #nim
04:30:18FromGitter<kaushalmodi> arghh, sorry folks, that version had another mistake .. was making mistake in creating this minimal version..
04:31:08FromGitter<kaushalmodi> so here are the tested version: the version with gzgetc works ( https://ptpb.pw/JheU/nim ), and this same code with gzgets does not ( https://ptpb.pw/s12O/nim )
04:36:18*oculux quit (Quit: blah)
04:37:11*oculux joined #nim
04:47:26FromGitter<kaushalmodi> got some interesting results after I tweaked the `gzgets` mapping with the header file
04:47:32FromGitter<kaushalmodi> https://ptpb.pw/WuFB/nim
04:48:03FromGitter<kaushalmodi> after that tweak, I get this output: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c47f203ba355012a4820a0d]
04:48:23FromGitter<kaushalmodi> can someone explain the reason behind this?
04:49:10FromGitter<kaushalmodi> zlib.h has ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c47f246dab15872ceda4e14]
04:51:27leorizeyou didn't initialize Pbytef
04:51:40*darithorn quit (Quit: Leaving)
04:51:54FromGitter<kaushalmodi> *what's that -- looking into zlib.nim*
04:51:55leorizecstring is nil by default lol
04:52:12leorizelook at your old example
04:52:26leorizethe pointer didn't increment because you passed a nil cstring in
04:53:06leorize```Pbytef = cstring```
04:53:24FromGitter<kaushalmodi> right, but I didn't understand the initialization part
04:54:05leorizeyour old example did: `var line: Pbytef`
04:54:12leorizethis is `nil` by default
04:54:38leorize`gzgets` work on an preallocated buffer, not an empty one
04:54:52FromGitter<kaushalmodi> how do I do that?
04:55:38FromGitter<kaushalmodi> I could preallocate that char array
04:55:57FromGitter<kaushalmodi> but the `gzgets` signature does not like that
04:56:22leorizepass in the pointer to the first variable
04:56:29leorizefirst index*
04:56:59leorize`addr lineArr[0]`
04:58:13leorizeif the compiler complain, just cast that expression to cstring
04:58:23leorizeinterfacing with C is never a nice thing :P
04:59:09FromGitter<kaushalmodi> finally! https://ptpb.pw/YrZg/nim
04:59:15FromGitter<kaushalmodi> thank you!
04:59:24FromGitter<kaushalmodi> I wasted about 2-3 hours on this
04:59:25FromGitter<kaushalmodi> :(
05:00:07FromGitter<kaushalmodi> *Learning C the hard way*
05:00:20leorizethere's a book with that name ;)
05:00:27FromGitter<kaushalmodi> I know
05:00:33*leorize quit (Remote host closed the connection)
05:00:39FromGitter<kaushalmodi> but never took up learning C
05:01:09FromGitter<kaushalmodi> I thought that the difference between cstring and string was that one ended in null and other didn't
05:01:26FromGitter<kaushalmodi> has no idea that cstring had to be manually initialized
05:01:51FromGitter<kaushalmodi> I reread this so many times: https://github.com/madler/zlib/blob/master/zlib.h#L1491
05:02:20FromGitter<kaushalmodi> I thought that `gzgets` would populated the `buf` with the contents from file
05:15:59FromGitter<kaushalmodi> leorize: this was really enlightening, thanks again!
05:34:07*oculux quit (Ping timeout: 244 seconds)
05:41:25*NimBot joined #nim
05:44:30TangerIs AndreiRegiani on IRC?
06:13:03*oculux joined #nim
06:23:38*miran joined #nim
06:38:16*oculux quit (Quit: blah)
06:39:24*oculux joined #nim
06:47:43*leorize joined #nim
06:54:16*kapil____ joined #nim
07:04:46*oculux quit (Quit: blah)
07:05:43*oculux joined #nim
07:13:24*krux02 joined #nim
07:16:33*oculux quit (Quit: blah)
07:22:10*dddddd quit (Remote host closed the connection)
08:00:00*gmpreussner quit (Quit: kthxbye)
08:04:43*gmpreussner joined #nim
08:15:01FromGitter<gogolxdong> httpbeast.nim(287) eventLoop ⏎ httpbeast.nim(203) processEvents ⏎ httpbeast.nim(140) bodyInTransit ⏎ system.nim(3877) failedAssertImpl ⏎ system.nim(3870) raiseAssert ... [https://gitter.im/nim-lang/Nim?at=5c48228535350772cf76a2cf]
08:15:14FromGitter<gogolxdong> got jester exception
08:24:03*Vladar joined #nim
08:26:49Zevvnot sure if an assert would be appropriate there - if i understand correctly the remote has lied about its content-length.
08:29:13FromGitter<gogolxdong> What's the purpose of this assertion?
08:30:26FromGitter<gogolxdong> to filter out suspicious request?
08:31:46Zevvthat was probably the intention, but asserting on received data is never the right thing to do.
08:31:53ZevvI can reproduce here
08:31:59*oculux joined #nim
08:32:00Zevvby making curl lie
08:35:03Zevvhttps://github.com/dom96/httpbeast/issues/21
08:38:04ZevvYou could catch the assert exception for now to prevent the crash
08:38:35FromGitter<gogolxdong> sure.
08:39:32*BigEpsilon joined #nim
08:42:29*PMunch joined #nim
08:42:39Araqno, fix httpbeast already
08:42:44Araqterrible.
08:43:00Zevv"for now"
08:51:45TangerWhat do you guys use for handling temporary files? I see the getTempDir is not advised in the docas
09:03:44*krux02 quit (Remote host closed the connection)
09:10:43*abm joined #nim
09:16:25livcdIs the only "production" option for a cross platform http server asynchttpserver with a reverse proxy ?
09:38:00Araqyes, unless you feel adventurous, asynchttpserver was reviewed for security problems fwiw
09:38:07*OrganicAnywhere joined #nim
09:43:56*kapil____ quit (Quit: Connection closed for inactivity)
09:44:04*OrganicAnywhere quit ()
10:05:00*OrganicAnywhere joined #nim
10:13:23*OrganicAnywhere quit ()
10:28:37*vonHabsi quit (Ping timeout: 244 seconds)
10:29:27*vonHabsi joined #nim
10:33:26*lritter joined #nim
10:36:56*vonHabsi quit (Ping timeout: 246 seconds)
10:43:38AraqI think we should put generic methods under .experimental until their issues have been resolved
10:43:52Araqpeople walk into it, https://forum.nim-lang.org/t/4566
10:44:10Araqand this feature was poorly implemented from the beginning
10:44:11*vonHabsi joined #nim
10:46:07FromGitter<mratsim> I used to use generics methods in Arraymancer for like 6 months
10:46:16FromGitter<mratsim> I removed them completely in November
10:46:32Araqand now you're much happier, right?
10:46:45FromGitter<mratsim> well I had a major hard stop
10:46:47FromGitter<mratsim> so yeah :p
10:47:32FromGitter<mratsim> they couldn't resolve the fields in a object variant
10:47:39AraqI know how to "fix" them, we don't have to remove the 'method' keyword. But the 'multi' aspect from them
10:48:36Araqand ... I dunno, the implementation should produce a vtable somehow
10:48:44FromGitter<mratsim> see here: https://github.com/mratsim/Arraymancer/issues/327
10:49:39ZevvI'm still threading on thin ice here because I don't understand the underlying mechanisms; but the issue I ran into for which the final conclusion was "multi methods and generics are broken beyond repair" (##10038) did not actually use *multi* methods, right?
10:49:43FromGitter<mratsim> If I don't use a generic, the generic method doesn't see the field
10:50:16AraqZevv, right but the 'multi' aspect doesn't help, it makes everything even more complex
10:50:31Araqin C++ you cannot have a virtual template function.
10:50:43Araqinteresting, isn't it.
10:52:10ZevvFrom a user perspective, please put it behind and .exerimental then, because I'd rather have none then something that mostly works but sometimes is broken
10:52:37Araqyeah.
10:53:52AraqI could also give it a try and fix it but then it's unclear what other problems may exist
10:55:01Araqoriginally methods did not support generics and the world was sane
10:55:22Araqsame as C++, you cannot have virtual templates
10:55:24Zevvyes, but we want generic everythings.
10:55:31ZevvI even like my generics generic
10:56:04Araqwell if everything is generic, there is little to no need for dynamic dispatch
10:56:23Araqthese features overlap and yet don't work well together.
10:57:09Zevvand there lies the problem. But it took me a while before I properly grasped that, lacking proper education in this field
10:59:35*abm quit (Ping timeout: 250 seconds)
10:59:37Araqin fact, when I introduced the .base annotation I should have stepped back already
11:00:06Araqwhy is .base required? what does it do? why do the other languages not require it?
11:00:20Zevvyes, these were my questions
11:00:27Araq.base is already patching a broken design :-)
11:02:48*absolutejam joined #nim
11:03:52*PMunch quit (Ping timeout: 250 seconds)
11:08:05*PMunch joined #nim
11:10:07FromGitter<mratsim> Actually you still need dynamic dispatch + generics
11:10:27FromGitter<mratsim> when you want dynamic containers of float32/float64 etc ;)
11:10:59FromGitter<mratsim> generics generics, aka Higher Kinded type would be useful for me
11:11:44absolutejammornin' all
11:11:56FromGitter<mratsim> I can't do `proc fooT; V: Variable[Tensor[T (v: V, t: T): T =` for example
11:12:32FromGitter<mratsim> I have to use a `subtype` macro to extract subtypes, and macro + generics are also a pain to work with
11:12:38FromGitter<mratsim> Hi abosultejam
11:13:35*OrganicAnywhere joined #nim
11:13:40*OrganicAnywhere quit (Client Quit)
11:49:47*zachcarter quit (Ping timeout: 240 seconds)
11:51:12leorizeis it just me or CI is getting slower?
11:51:21absolutejamrewrite it in Nim ;)
11:52:23*abm joined #nim
11:54:52Araqits queue is too long
11:54:55Zevvleorize: run time or queue time?
11:54:58Zevvthat
11:55:10leorizequeue time
11:55:27leorizedid we got more contributors or something? :p
11:55:51*ng0 joined #nim
11:56:42federico3https://robert-mcdermott.gitlab.io/posts/speeding-up-python-with-nim/ is the author around here? Having an RSS feed would be a nice addition to planet.nim-lang.org
12:02:01*zachcarter joined #nim
12:03:26miranleorize: it is not just you (unfortunately :))
12:21:23PMunchfederico3, TIL planet.nim-lang.org
12:21:27PMunchWhat is that page?
12:29:32miran(rss) blog aggregator
12:32:05*dddddd joined #nim
12:33:01*stefanos82 joined #nim
12:35:01PMunchHmm interesting
12:35:59PMunchI should add per-tag RSS feeds to my site and PR it with a Nim tag filter :)
12:36:07federico3please do!
12:45:17*OrganicAnywhere joined #nim
12:45:30*OrganicAnywhere quit (Client Quit)
12:51:23FromGitter<kaushalmodi> federico3: Just noticed that the planet hasn't used my new feed
12:51:42FromGitter<kaushalmodi> It still has the whole Nim notes from my old feed
12:52:07FromGitter<arnetheduck> > but asserting on received data is never the right thing to do ⏎ ⏎ aww, don't kill the fun of having a remote-induced crash possibility ;)
12:52:17livcdsame here
12:52:22livcdTIL planet.nim-lang.org Oo
12:53:10FromGitter<kaushalmodi> federico3: The Nim notes (and few other Nim notes) are no longer on https://scripter.co/tags/nim/atom.xml
12:53:19FromGitter<kaushalmodi> May be you need to clear the cache?
12:53:31federico3https://github.com/FedericoCeratto/nim-planet/pull/1/files is this up to date?
12:53:55FromGitter<kaushalmodi> Yes, the link I posted above is the same
12:54:53federico3https://github.com/FedericoCeratto/nim-planet/blob/master/nim_planet.ini this is the current conf
12:57:20federico3I don't get it. Try to load https://scripter.co/tags/nim/atom.xml in a browser. I'm seeing whole posts.
13:03:37*zachcarter quit (Ping timeout: 244 seconds)
13:09:40FromGitter<kaushalmodi> federico3: the posts are still whole, but I removed the big "Nim notes" posts
13:10:38FromGitter<kaushalmodi> The world around me is moving towards RSS with whole posts, as they like to get all info from their RSS readers, and not have a link indirection to see the whole thing.
13:11:12PMunchYeah, full post RSS is way better
13:11:16PMunchAs a user
13:11:32FromGitter<kaushalmodi> Yep
13:11:53FromGitter<kaushalmodi> federico3: what happens if you empty that `cache` directly?
13:12:04FromGitter<kaushalmodi> s/directly/dir
13:14:15FromGitter<kaushalmodi> federico3: to summarize, earlier my feed had short "posts" and long "notes" (like Nim notes). Now it has only the "posts". So my feed will be less flooding now :)
13:16:57*skellock joined #nim
13:21:11federico3I don't see much benefit in removing posts from the planet once they are published. The way RSS feeds are consumed is more like a stream.
13:28:38*Snircle joined #nim
13:34:19FromGitter<mratsim> many pulled back on full RSS due to copy websites that steal organic traffic coming from Google searches
13:36:03FromGitter<kaushalmodi> @mratsim that's a good problem to have ;)
13:36:38FromGitter<kaushalmodi> federico3: but this is a special case, the planet right now is flooded with Nim notes. No one would scroll past that to see more posts.
13:37:04federico3ok, I'll try to clear the cache
13:37:17FromGitter<kaushalmodi> Actually the planet should auto add "Read more" expansion links, but that's a different problem to tackle.
13:38:02federico3somebody should write an aggregator in Nim ;)
13:38:10FromGitter<kaushalmodi> :)
13:39:23miran@kaushalmodi re .rst vs _doc.nim — i think that is bikeshedding ;)
13:40:55FromGitter<kaushalmodi> It's actually not bikeshedding
13:41:16FromGitter<kaushalmodi> It affects in practise how you view docs vs code
13:41:50FromGitter<kaushalmodi> In the current PR, docs are pasted in a .nim file that's exclusively for docs.
13:42:02FromGitter<kaushalmodi> Then why not just have a .rst file?
13:42:29FromGitter<kaushalmodi> The nim doc should be fixed to just expand the includes of rsts before evaluating runnableExamples
13:42:54miranlet's see if Araq changed his mind about that ;) ^
13:42:59FromGitter<kaushalmodi> it's nicer to find only true code files if I look for *.nim files
13:43:14FromGitter<kaushalmodi> If you want docs, look for *.rst
13:43:21FromGitter<kaushalmodi> How is that bikeshedding?
13:43:24FromGitter<Vindaar> @miran: I agree with @kaushalmodi, because if such a file is only docs anyway, `.rst` allows to view the files properly by themselves
13:43:48FromGitter<kaushalmodi> For others, ref: https://github.com/nim-lang/Nim/pull/10429#issuecomment-456801417
13:44:10miranok, i'll wait for you to discuss and decide before taking any further steps about it :)
13:44:24FromGitter<kaushalmodi> With .rst files, you automatically get rst support in editors (Emacs at least) :)
13:46:10*nsf quit (Quit: WeeChat 2.3)
13:46:29federico3@kaushalmodi: cache refreshed
13:46:41*vlad1777d joined #nim
13:47:09federico3interesting behavior...
13:58:58Araqbah, we are never allowed to take shortcuts
13:59:12Araqrst also supports runnable examples via the custiom :test: annotation
13:59:18Araqbut it's not optimized yet
13:59:46Araqalternatively we can use foo.nimdoc as 'include' supports custom file extensions
13:59:56Araqfor example:
14:00:02Araqstrutils.nim:
14:00:10Araqinclude "strutils.nimdoc"
14:01:17*PMunch quit (Remote host closed the connection)
14:01:28*PMunch joined #nim
14:02:14*krux02 joined #nim
14:02:20FromGitter<alehander42> But why do we need a custom file for top level docs
14:02:40FromGitter<alehander42> Why would one need to maintain two files for the same module
14:02:59absolutejamare there any plans for the compiler to not require type/proc definitions in the right order?
14:04:20*salewski joined #nim
14:04:53Araqalehander42: because excessive docs annoy me, that's why
14:05:08Araqthere is no technical reason to split them up
14:05:42Araqabsolutejam, yes, and we have a pragma .reorder: on for this
14:06:08Araqit kinda sucks but it's better than nothing until we wait for the more complete solution
14:06:24miranabsolutejam: in the mean time you could use forward declarations
14:07:15salewskiIf someone of you is using Windows7, maybe you can give him a hint:
14:07:24salewskiIf someone of you is using Windows7, maybe you can give him a hint: https://github.com/StefanSalewski/gintro/issues/38#issuecomment-456768187
14:08:26FromGitter<alehander42> Araq, but why: they're much more useful near the code: and one always needs to jump to the function he needs anyway, what is on top of the file is usually irrelevant otherwise
14:08:27salewskiMaybe he does the PATH update wrong? Has he to rebbot?
14:08:30absolutejamah cool
14:08:50absolutejamNever realised how much I relied on it until I started with Nim
14:12:07salewskiReboot or reopen terminal after export PATH=/mingw64/bin:$PATH on Windows7?
14:12:42FromGitter<gogolxdong> import karax / [jstrutils, kajax, vdom, karaxdsl, karax, kdom, kbase] ⏎ ⏎ proc reverse(e:Event, n: VNode) = ⏎ ⏎ ```result = buildHtml(tdiv()): ⏎ button(onclick = reverse): text "submit"``` ... [https://gitter.im/nim-lang/Nim?at=5c48765a9bfa375aab49646e]
14:12:50salewskiI can not help him, bye.
14:13:12FromGitter<gogolxdong> How to change the text of the VNode onclick?
14:13:35FromGitter<gogolxdong> Is there anywhere I misunderstood?
14:14:30Araqsalewski, PATH updates don't require an OS restart
14:14:38Araqbut a terminal restart
14:15:35Araqgogolxdong: you don't change the text of a VNode, you put what to render into a variable that is changed in your onclick handler
14:16:58Araqprobably should have made the virtual DOM immutable.
14:17:09salewskiThanks araq, I will tell him. (I have to admit that I am not sure if PATH is used for DLL lookup on windows.)
14:19:09Araqit is.
14:19:39Araqand tell him to get "Rapid Environment Editor" to get a sane UI for envvars
14:19:47*aguspiza joined #nim
14:19:53Araq(No, they don't pay me. It's sad.)
14:20:26Araqand usually "cannot load x.dll" is also caused by 32 vs 64bit problems
14:21:04salewskiThanks, good hint!
14:21:31Araqand tell him to use real Windows tools, not this msys clusterfuck
14:22:27salewskiWill send him a link to this IRC log.
14:22:33Araquh oh
14:22:35Araq:D
14:23:24FromGitter<mratsim> real windows tool are also buggy ...
14:23:46FromGitter<mratsim> I can't install directX 9 on windows for example
14:24:00FromGitter<mratsim> windows 10
14:24:23FromGitter<mratsim> or you can't prevent windows from hoarding 20% of your GPU memory
14:24:50FromGitter<mratsim> sorry 15%
14:25:12FromGitter<mratsim> with GPU with 8+GB of vram that's dumb
14:25:29*salewski quit (Quit: WeeChat 2.3)
14:25:58Araqisn't direct 9 quite old?
14:26:19FromGitter<mratsim> yeah but it was the defacto standard from 2005 to 2011 or something
14:26:25Araqand the GPU memory problems sounds like a driver problem
14:26:55FromGitter<mratsim> no it's WDDM 2.0 issue
14:27:00Araqofc nothing beats the good ol' XP
14:27:05FromGitter<mratsim> (windows driver model ...)
14:27:18FromGitter<mratsim> yeah directx 9 long life was due to XP
14:27:41FromGitter<mratsim> Nvidia drivers on Linux doesn't reserve more than what they need
14:28:05Araqno, they don't work at all instead :P
14:28:09miran:D :D
14:28:29FromGitter<mratsim> they do
14:28:35FromGitter<mratsim> and they work well :p
14:28:45*miran was also surprised to see someone speaks positively about gpu drivers on linux
14:28:47Araqthey never did when I still had Linux
14:28:49FromGitter<mratsim> I even have kernel mode settings with the proprietary driver
14:29:38FromGitter<mratsim> though somehow, I have 2 GPUs and on windows I need to connect the screen on a different GPU from Linux
14:29:58miran#firstworldproblems
14:30:48skellockman_holding_too_many_limes.tga
14:32:48FromGitter<gogolxdong> @Araq, I have to read your each word carefully to make it right. I think I haven't got the spirit of Karax yet.
14:36:32Araqhttps://github.com/pragmagic/karax#event-model
14:37:15Araqit's always state -> VNode. The state is *not* in the VNode, it comes from somewhere else to drive your UI.
14:38:57FromGitter<alehander42> Imagine that the only way to change anything in the ui is by rerunning redraw
14:39:15FromGitter<gogolxdong> yeah, my usage is a variant and a bit more complicated.
14:39:16FromGitter<alehander42> (which is ran automatically after each event handler)
14:39:33FromGitter<alehander42> So it should reflect a change in your state
14:39:53FromGitter<alehander42> Vnode is
14:40:10FromGitter<alehander42> Just an implementation detail for the end user imo
14:50:51FromGitter<zacharycarter> Update on the playground - I just wrote the service unit file and the service is starting
14:51:04FromGitter<zacharycarter> I need to add nginx rules to route requests to the backend appropriately - and then do some testing
14:51:14FromGitter<zacharycarter> after that it should be back up - so I'm hoping by this evening at the latest
14:51:29miran@zacharycarter which nim version does/will playground use?
14:53:53FromGitter<zacharycarter> miran: whatever the latest official nim docker image is
14:54:35skellockthat docker image could use an update btw --- i think it's 19.0
14:54:47skellock*0.19.0
14:54:48FromGitter<zacharycarter> https://hub.docker.com/r/nimlang/nim this one I believe
14:55:09FromGitter<mratsim> it's from moigagoo iirc
14:55:30FromGitter<mratsim> https://github.com/moigagoo/nimage
15:03:30*aguspiza quit (Ping timeout: 250 seconds)
15:06:05Araqwe have 0.19.2 and can release 0.19.4 any day
15:10:03*lritter quit (Ping timeout: 245 seconds)
15:12:48FromGitter<mratsim> why not today?
15:13:34Araqtoo easy, need to work on something harder today.
15:14:03mirantowards 0.20 release. hard enough? :P
15:15:07FromGitter<mratsim> I'm impressed with that PR btw: https://github.com/nim-lang/Nim/commit/d9ee377517fe22e307592f4d6c019388600b5e57 @Vindaar
15:16:11Araqwe're getting lots of good PRs these days
15:18:01skellock2019 - the year of nim (on the desktop)
15:18:44FromGitter<mratsim> on the server
15:18:55FromGitter<mratsim> for desktop we need a cross platform gui toolkit :p
15:19:27skellockmratsim: sounds straight forward >.>
15:20:11FromGitter<Vindaar> @mratsim Thanks! But TheLemonMan deserves most of that credit :) I mainly extracted a test case from laser
15:20:27FromGitter<zacharycarter> NiGui
15:20:29FromGitter<zacharycarter> go!
15:21:05FromGitter<mratsim> that has been very annoying because it completely blocked me on Laser parallel stuff
15:25:03FromGitter<Vindaar> I figured it'd be an annoying bug for you
15:25:38*darithorn joined #nim
15:27:27*ng0_ joined #nim
15:29:07*ng0 quit (Ping timeout: 256 seconds)
15:29:15*ng0_ is now known as ng0
15:33:51*seni joined #nim
15:36:21*nsf joined #nim
15:43:56FromGitter<mratsim> yeah it is, because I needed devel for OpenMP but not a too recent one due to that regression
15:44:27FromGitter<mratsim> also now I can use the normal parameters to pass static objects instead of being forced to use the generics syntax.
15:45:36FromGitter<mratsim> but I guess there are other pitfalls with static object. I'm pretty sure I found one with `when` condition for an object field
15:53:56*PMunch quit (Ping timeout: 240 seconds)
15:57:41*PMunch joined #nim
16:00:58*PMunch quit (Remote host closed the connection)
16:13:00FromGitter<Vindaar> more pitfalls -> more issues -> more fixes --> ... --> no* issues? ⏎ ⏎ 1) in practical terms
16:14:02FromGitter<mratsim> yeah, but it's very distracting from what you're working on
16:14:15FromGitter<Vindaar> oh, that is certainly true
16:14:28Araqhttps://youtu.be/DmYOPkI_LzU
16:16:20*Trustable joined #nim
16:20:03FromGitter<kaushalmodi> Araq: About the .nimdoc ..
16:20:10FromGitter<kaushalmodi> why do we want one more file type? :)
16:20:40FromGitter<kaushalmodi> we already have .rst. Do you think that it will be too difficult to do the .. include expansion of the RST files before evaluating runnableExamples?
16:22:01*skellock quit (Ping timeout: 244 seconds)
16:22:59Araqok, whatever, will speed it up
16:23:15FromGitter<kaushalmodi> .nimdoc will lead to more fragmentation
16:23:20miran@kaushalmodi btw, we can also keep everything like it is currently (in the same file), if Araq gives in :)
16:23:32FromGitter<kaushalmodi> miran: that works too
16:24:01FromGitter<kaushalmodi> but please no fragmentation (like a new .nimdoc) or having doc-only code files (foo_doc.nim).
16:24:21FromGitter<mratsim> +1
16:24:28FromGitter<kaushalmodi> the including of rst files is a nice to have feature
16:24:49FromGitter<kaushalmodi> then folks can write in md/Org/whatever and have pandoc generate those rst files
16:25:03*absolutejam quit (Ping timeout: 245 seconds)
16:26:37Araqyou can already write in .md, Nim's docgen supports markdown features now
16:27:06FromGitter<kaushalmodi> Araq: there needed to be a big announcement for that :)
16:27:11FromGitter<kaushalmodi> I'll try that out later
16:27:17FromGitter<arnetheduck> ```code paste, see link``` ⏎ ⏎ while working on this.. can you do something about `runnableExamples` as well? in snippets like above, it's really hard to tell example from implementation [https://gitter.im/nim-lang/Nim?at=5c4895e4ba355012a4867089]
16:27:48FromGitter<kaushalmodi> use a newline before `return c in Letters`?
16:28:28FromGitter<arnetheduck> well, I'm taking that from the std lib.. it's a silly example, but the lib is littered with it - the feature encourages it
16:28:37Araqit's wrong to consider runnableExample "not really part of the code"
16:28:54Araqthey are as important as every other code if not moreso.
16:28:57miran@arnetheduck that is relatively frequently discussed. one idea is to have an empty line. what i use in my private project is to have runnable examples indented with 4 spaces
16:29:03Araqwhich is why they stick out from the ## docs.
16:29:14AraqI know you hate it. I like it very much.
16:29:31FromGitter<arnetheduck> you can keep it and try to address this concern?
16:29:43Araqadd a newline?
16:29:51FromGitter<arnetheduck> not enough
16:30:17miran@arnetheduck http://ix.io/1yBh/
16:30:25Araqwhat would be enough then?
16:30:26FromGitter<arnetheduck> extra indent or a comment line between or something would make it stand out ("the noise ends here")
16:30:33miranhere are three ways of doing it, from the other day
16:30:42Araqit is NOT noise.
16:30:47Araqthat's where we disagree.
16:30:59FromGitter<arnetheduck> it is, when you're looking for the implementation
16:31:03miran2nd is the current, 1st is the current+newline, 3rd is what i use
16:31:21Araqit's a poor *spec*.
16:31:48Araq"hide the spec for me" is not something you should ask for constantly.
16:32:02FromGitter<arnetheduck> well whatever, it's different and distinct in "what problem does this piece of text solve"?
16:32:10FromGitter<kaushalmodi> how about: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c489709f780a1521f587bc3]
16:32:17Araqthen teach your editor to fold it.
16:32:21FromGitter<arnetheduck> @kaushalmodi brilliant
16:32:23mirani really like 4-space indentation for runnable examples, but the last time i brought it up, Araq was against it (did you change your mind maybe?)
16:32:36FromGitter<kaushalmodi> *I don't know if that would work though ..*
16:32:43FromGitter<arnetheduck> I prefer @kaushalmodi's..
16:32:56FromGitter<kaushalmodi> i.e. not sure if nim doc will read in that runnableExamples .. need to try out
16:32:58Araq4 spaces is nothing nimpretty would understand
16:33:45miran@kaushalmodi further documentation after runnable example works, so a single ## should too
16:33:59FromGitter<kaushalmodi> yup it works
16:34:07FromGitter<kaushalmodi> Araq, miran: are you fine with that?
16:34:21AraqI don't like it all but it's a compromise, so go for it.
16:34:31FromGitter<kaushalmodi> As I updated few of the code blocks with this style in my project, I like it
16:34:57FromGitter<arnetheduck> point is, at times (quite often), *I'm looking for the implementation*, for whatever reason.. I don't want the spec, I don't want the docs, I don't want anything else.. at that stage, all the other stuff *is noise*
16:35:38FromGitter<kaushalmodi> Araq: thanks
16:35:44miranbtw, vscode can fold runnable examples, should help with the noise cancelling
16:35:51FromGitter<kaushalmodi> miran: what do you think of that `##` doc-ender?
16:35:56FromGitter<arnetheduck> it can't fold them automatically
16:36:53miran@kaushalmodi i don't have a strong opinion about it. i might give it a try and report back at you tomorrow, after some docs written like that
16:37:15FromGitter<kaushalmodi> miran: cool, thanks for considering
16:37:46miranyeah, it is not automatic, but it is one keyboard shortcut away
16:37:52Araqthough I wonder if we could patch the docgen to allow a complete (foo.nim foo.rst) split
16:38:37miranwhile at it, make it a (foo.nim, foo.md) split ;)
16:38:59FromGitter<kaushalmodi> miran: +1 on .md :)
16:39:06Araqbut in practice it'll probably as bad as C++'s .h/.cpp split
16:39:27Araqso better teach vscode how to fold things properly
16:39:36miran@kaushalmodi it is 4284218:1 in .md's favor (with Araq being the only one on .rst's side :D)
16:39:40FromGitter<arnetheduck> @miran well, sort of.. it can't fold `runnableExamples` *and nothing else*
16:40:14Araqit cannot fold anything useful IME, it always folds way too much
16:40:45FromGitter<arnetheduck> and it works in vscode only.. it doesn't work when reviewing a PR on github.. sometimes you're not in control over the way the text is displayed
16:41:21miran@arnetheduck well, i was thinking more about the situation where you're "looking for the implementation" of a function, you see a runnable example and just press ctrl+shift+[ so you make it gone. i didn't think it could be done for a whole document/project
16:41:22Araqwell a diff is a diff, it tries to keep the diffs small
16:41:56FromGitter<arnetheduck> I usually `ctrl-k ctrl-1` to fold to function prototypes.. mostly because nim's basic module support means you have to make large modules
16:42:35miran@kaushalmodi i can already say that i like ## better than the empty newline
16:42:56FromGitter<arnetheduck> @miran now add that as a warning to the compiler ;)
16:43:15FromGitter<kaushalmodi> miran: It already looked better in Gitter at https://gitter.im/nim-lang/Nim?at=5c489709f780a1521f587bc3 when I pasted that sample
16:43:31FromGitter<Vindaar> +1 to `##` there
16:43:44FromGitter<kaushalmodi> I agree to the point that @arnetheduck made.. this needs to look good without relying on VSCode folding
16:44:22FromGitter<arnetheduck> text is king, it's the stuff we do all day, looking at text.. less tooling needed for that default case, the better
16:44:30miran4-spaces look good without folding, wherever you look at it (e.g. github)
16:44:59Araqtext is always bullshit, code is in trees.
16:45:20Araqdiff would work better on trees too.
16:45:40Araqeverything would be better with trees.
16:45:47FromGitter<arnetheduck> you know any good tree-diff? have looked for them without success
16:46:17Araqwell it's a stillborn as long as all PLs are stored in text without a common tree representation
16:46:26FromGitter<arnetheduck> structural diffs in general are hard to get right and inherently become less generic..
16:46:56Araqthe diff is often completely off and doesn't reflect the real editing steps
16:49:05FromGitter<Vindaar> @Araq, isn't a filesystem with /directories/ a tree, too? :P
16:49:36Araqha, good one
16:50:02Araqif it is a tree then why does it have symlinks
16:50:21FromGitter<Vindaar> fair point
16:50:44FromGitter<kaushalmodi> See https://github.com/nim-lang/Nim/pull/10432/files
16:51:20miranhaha, you didn't waste any time, did you :D
16:51:21FromGitter<arnetheduck> actually, that's something really cool vscode does now - functions in a file (anything foldable I think), are just part of the path just like the filename is.. pretty nifty
16:51:32FromGitter<kaushalmodi> The `##` also helped fix an easily introducible bug: https://github.com/nim-lang/Nim/pull/10432/files#diff-3890ade26b30222078b05cab885646faL198 :)
16:51:36FromGitter<arnetheduck> I've seen that in a few editors already
16:52:03FromGitter<kaushalmodi> well.. you will see that fix if that line, line 198 is not highlighted
16:52:31FromGitter<kaushalmodi> essentially not a bug, but a compile failure annoyance
16:54:01Zevv"If you change the stdlib (anything under lib/, eg lib/pure/os.nim), put a test in the file you changed.". Is that still relevant, tests don't go in the file iself but in tests?
16:54:31Araqwe don't know, Zevv
16:54:32*BigEpsilon quit (Quit: WeeChat 2.3)
16:55:14Araqthe guideline is "runnableExamples are examples" and further excessive tests might go into a dedicated test file
16:55:43FromGitter<arnetheduck> @kaushalmodi indeed, it's exactly that kind of stuff I don't like with runnableExamples.. indent / spacing is invisible, it doesn't give any visual clues... if I've scrolled the file a bit, and it looks like below, I have no clue and have to scroll up: ⏎ ⏎ ``` echo "blabla" ⏎ ⏎ result = 2 * x``` ⏎ ⏎ it's distracting because in an example, the echo is ok, but in implementation, it's a
16:55:44FromGitter... side-effect, so I lose the train of thought when analyzing the implementation.. when reviewing code, every distraction increases the potential for other things to slip through [https://gitter.im/nim-lang/Nim?at=5c489c8f0721b912a5c80a01]
16:59:17Araqeverything is always distracting and confusing. Today it's indentation, tomorrow it's long string literals in an editor that doesn't understand Nim's lexing rules. And then it's some incredibly useful default rule like "on error unwind the stack".
17:02:47FromGitter<arnetheduck> well, yeah, and when things are distracting and confusing, you try to isolate them and solve the problems separately.. "now I'm writing examples, the primary objective is to be helpful to the reader of the examples and show the code in the best possible light so as to introduce them to the utility of the function", "now I'm writing the implementation - it has to be efficient and deal with corner cases and do the
17:02:47FromGitter... task in the least surprising way"
17:04:19Araq"Now I updated the implementation and the runnableExamples are failing and I don't see why..."
17:05:46FromGitter<arnetheduck> I guess maybe I read more code than I change then..
17:14:07Araqbtw you don't have to use runnableExamples, you can use ##[ ]## with .. code-block:: nim :test:
17:14:49Araqexcept that it's slower but I'm working on it
17:15:46Araqcorrection: it doesn't work at all, but should :-)
17:18:13FromGitter<arnetheduck> oh, yeah, but I want to use code that others have written, and if we as a community can come up with a solution that works for more people, there's a beautiful future ahead for everyone involved
17:21:25FromGitter<mratsim> *Unicorns galloping into the sunset
17:44:34*skellock joined #nim
17:52:32shashlickHehe my last github issue comment probably reads like that too
18:01:15*Trustable quit (Remote host closed the connection)
18:13:36*nsf quit (Quit: WeeChat 2.3)
18:28:45*stefanos82 quit (Remote host closed the connection)
18:40:19*krux02 quit (Remote host closed the connection)
18:43:20*brainproxy joined #nim
18:56:32*a_b_m joined #nim
18:59:36*abm quit (Ping timeout: 244 seconds)
19:02:19FromGitter<iffy> I've been trying to solve a gcassert problem in my code. I'm trying to get some better tools to give me better visibility into what's going on. How do I use `--memTracker:on`, `-d:leakDetector` and `-d:memProfiler`?
19:14:40*zachcarter joined #nim
19:14:46*PMunch joined #nim
19:16:00rayman22201completely off topic, but does anybody happen to know the equivalent of the linux tool `nm` for windows? I need to get the exposed symbols of a dll
19:18:41*OrganicAnywhere joined #nim
19:18:52*OrganicAnywhere quit (Client Quit)
19:20:50rayman22201It's dumpbin. if anybody cares lol.... linux dev on windows. Like a fish out of water.
19:21:06Zevv"If you change the stdlib (anything under lib/, eg lib/pure/os.nim), put a test in the file you changed.". Is that still relevant, tests don't go in the file iself but in tests?
19:21:12Zevvoh sorry
19:32:27*zachcart1r joined #nim
19:34:26*zachcarter quit (Ping timeout: 240 seconds)
19:35:58FromGitter<iffy> Right here in gc.nim it says that black means "in use or free" https://github.com/nim-lang/Nim/blob/devel/lib/system/gc.nim#L35
19:36:13FromGitter<iffy> Isn't that contradictory? Shouldn't black mean only that it's in use?
19:37:08FromGitter<iffy> Oh wait... nm
19:37:18Araqyou don't have a gc problem, you have a memory corruption
19:37:32Araqmost likely caused by a wrong C wrapper
19:37:56Araqrunning with valgrind can help, checking every 'cast' can help
19:38:15FromGitter<iffy> Araq: meaning, whatever's using my nim-made C library is messing with the nim-owned memory?
19:38:16Araqcheck that int and cint didn't get mixed up, check 32 vs 64 bit builds
19:38:40FromGitter<iffy> and by "whatever" I mean Node.JS
19:39:33*Tyresc joined #nim
19:39:33Araqdo you call nimGC_setStackBottom() ?
19:39:49FromGitter<iffy> Araq: no, I don't call any GC functions in my current version of code
19:39:57FromGitter<iffy> not even GC_ref or GC_unref
19:40:56Araqyou use node.js with a Nim extension and don't setup Nim's GC?
19:41:07FromGitter<iffy> I call NimMain, but that's it
19:43:05*OrganicAnywhere joined #nim
19:43:39Araqok that should cover setStackBottom
19:43:53Araqdo you pass strings to C?
19:44:14FromGitter<iffy> Yes, strings are the main thing I'm passing from JS -> my C++ code -> Nim and back
19:44:36FromGitter<iffy> And all my segfaults seem to happen when doing something with strings
19:45:07Araqthen maybe you should start to use GC_ref/unref
19:46:11FromGitter<iffy> I started to. As a debugging move, I only used GC_ref and didn't ever unref, but I still got segfaults.
19:47:32FromGitter<iffy> Currently, in Nim, I make a copy of every incoming string using copyMem and I append every outgoing string to a global sequence of strings (which I think is sort of equivalent to GC_ref)
19:49:26Araqha, na that doesn't work, when you append to a global sequence it creates a copy and the old string is subject to garbage collection
19:49:36FromGitter<iffy> oh, hehe
19:50:01Araquse GC_ref instead, but you can also play with GC_disable and GC_enable
19:50:26Araqso that the GC doesn't collect when strings are still flying around language boundaries
19:50:37FromGitter<iffy> k, I'll try that, and check my ints/cints and also see if I can get valgrind to run this
19:50:52Araqor you use --gc:regions and custom regions memory management
19:50:53FromGitter<iffy> How does Nim know where to set the stack bottom, btw?
19:51:09FromGitter<iffy> Cause I could see Node not honoring it, maybe?
19:51:34*OrganicAnywhere quit ()
19:51:41Araqyeah, it's possible
19:53:50FromGitter<iffy> Araq: GC_disable() made it work without errors
19:54:13Araqunfortunately that doesn't mean much.
19:54:27FromGitter<iffy> That's what I was just concluding :)
19:54:42FromGitter<arnetheduck> check this out btw, nim is featured in the `libp2p` roadmap: https://docs.google.com/document/d/1Rd4yNw1TNQBvfRrKeEMSTseb6fvPzS-C--obOn0nul8/edit#heading=h.81ihj7mrpz4p
19:55:12Araqiffy if you could share some code I could say more
19:55:46ZevvAraq: if you have a minute, can you explain to me what the if line 232 in asyncmacro checks for? retval should either be nothing or Future[T], but allows something else
19:56:06FromGitter<iffy> Araq: Yeah; I think I'm going to trim this down to a reproducible, shareable snippet. It's mostly proprietary stuff unfortunately
19:57:25AraqZevv: there are 2 AST representations for A[B]
19:57:33Araqthat's what this code is checking for
19:58:05ZevvI expected something like that, but how does that trigger in real life? I see this never happening in all of the tests
19:58:10Araqit's either nkBracketExpr(A, B) or nkCall("[]", A, B)
19:58:13dom96hey guys, what's new?
19:58:33Araqdom96: we released a Nim music video
19:58:54AraqZevv: well it's defensive code :P
19:59:04ZevvFair enough, thanks
19:59:39dom96This one? https://www.youtube.com/watch?v=DmYOPkI_LzU&t=0s
20:00:06Araqyeah
20:01:10dom96No tweets about it?
20:03:07Araqfeel free
20:04:31dom96done
20:04:36xacethats great, i wanted to ask at the last video about how to use krux's gdb script but I guess this answers it
20:04:55rayman22201Just watching the video. Araq sounds much more clear ;-)
20:05:07*aguspiza joined #nim
20:05:58dom96Cool, so we've got two talks about Nim at FOSDEM (even if one is indirectly about Nim) https://fosdem.org/2019/schedule/event/nimbus/
20:07:42rayman22201Araq quote of the day, "in my experience debugging in releaese mode with GDB is the same..." except when it's not lol. "Cannot access this local variable. It has been optimized away." DAMNIT XP
20:08:29*Araq shrugs
20:08:54ZevvIf I would make a PR to do the async implicit Future[T] return transformation, would it make sense to change all code in stdlib and tests hat that now returns a Future[T] as well?
20:08:56Araq"Variable has been optimized away" was a Delphi problem
20:09:04Araqnot a GDB one, but ymmv
20:09:36AraqZevv: this PR requires you won the RFC fight first
20:09:51ZevvIt's hypothetical :)
20:10:39dom96We've discussed this already, explicit Future[T] is the way
20:11:06dom96Unless you've got a different argument than "I hate typing", I won't be swayed :)
20:11:36rayman22201True, optimized local variables is a general aggressive optimizer problem. It's great, until you need to debug. It happens to me all the time at my job with C++ code. I'm just venting my frustration.
20:13:20Zevvdom96: I made some arguments here https://tinyurl.com/ya8exu7s. I naively assumed the "thumbs up" from araq on that was good news
20:14:51*zachk joined #nim
20:15:57*zachk quit (Read error: Connection reset by peer)
20:16:02Araqrayman22201: do you use GDB?
20:16:19*zachk joined #nim
20:16:23rayman22201yes... for better or worse
20:17:35AraqZevv: I like this change, yes.
20:18:01Araqbut I don't use my BDFL status all the time.
20:18:12*zachk quit (Changing host)
20:18:12*zachk joined #nim
20:18:49ZevvI had to look that one up :)
20:19:00Zevvand its not the Bund Deutscher Fußball-Lehrer
20:19:11Araqlol
20:19:29dom96I replied
20:20:37Zevvsweet
20:20:53Araqah hmmm, This should not leave existing code working, but might cause confusion with nested Future return types like Future[Future[int]]."
20:21:03dom96yeah...
20:21:07Araqthat's why we didn't do it iirc
20:21:09dom96yet another reason
20:21:40dom96btw, please ping me about async RFCs
20:21:55ZevvAraq: that's a typo, it *should* leave existing code working of course
20:22:00dom96also, can we force people to write proper PR RFCs?
20:22:09dom96I don't have time to go through all RFC issues :(
20:22:32AraqZevv: not my point
20:22:34Zevv:)
20:22:58AraqFuture[Future[T]] vs Future[T] is confusing when T is short for Future[T]
20:23:13Araqand c# too uses Task<T> explicitly.
20:23:42dom96wouldn't be surprised if other languages with async await do too
20:23:46dom96Bet you Python does as well
20:23:56Araqand every newer C# feature got extensive usability testing.
20:24:10Araqor at least "some". :P
20:24:13dom96I know that Hack does too
20:25:09Araqhowever we could have sugar, ^T for Future[T] and ^ for await... :P
20:25:18dom96noooo
20:25:34dom96It's hard enough to explain async await to people
20:25:37dom96don't make it harder
20:25:40AraqI'm not serious.
20:26:06dom96Great
20:26:11dom96Araq: You coming to FOSDEM?
20:26:30Araqno.
20:26:49dom96pity
20:27:31federico3pity indeed :(
20:37:03FromGitter<zacharycarter> dom96: why is it hard to explain async await to people?
20:37:40FromGitter<zacharycarter> do you mean idiosyncacies in Nim's implementation?
20:37:46FromGitter<zacharycarter> or the concept in general?
20:37:53dom96Two reasons: it's not easy for people to understand what goes on "under the hood" and there are multiple symbols (await, waitFor, runForever, poll, etc.)
20:38:04FromGitter<zacharycarter> so the former - gotcha
20:38:23dom96Many people find it hard to understand what the difference between `await` and `waitFor` are
20:38:37dom96many also don't understand what a Future is I think
20:38:57FromGitter<zacharycarter> maybe we could create some analogous references to other popular PLs?
20:38:59Zevvpromises are pretty common these days
20:39:03FromGitter<zacharycarter> so like - Future = Promise
20:39:07Zevv^
20:39:08dom96Not sure it is idiosyncracies, how can we merge these symbols?
20:39:17FromGitter<zacharycarter> well - we can't
20:39:21FromGitter<zacharycarter> but we can explain them in JS terms
20:39:36FromGitter<zacharycarter> which many people doing async/await programming are familiar with
20:39:37FromGitter<zacharycarter> or C# terms
20:39:44dom96Sure
20:39:57FromGitter<zacharycarter> that's why I was a bit confused at first - because I know a lot of people are already familiar with these concepts
20:40:02dom96I wonder what the C#/JS equivalents are actually
20:40:04FromGitter<zacharycarter> but they're used to them in a JS or C# context
20:40:14FromGitter<zacharycarter> well - I know for sure that Promises are JS's version of Futures
20:40:20dom96we need someone who knows C#/JS well to write these
20:40:22FromGitter<zacharycarter> I'm sure JS has a waitFor
20:40:27FromGitter<zacharycarter> they definitely have an await
20:40:42FromGitter<zacharycarter> C# - I can't help with
20:40:56FromGitter<zacharycarter> I have a co-worker I could tap though - who loves to talk about C#
20:41:10dom96Do it, get them to contribute to Nim :D
20:41:18FromGitter<zacharycarter> okay - I will talk to him tomorrow about it
20:41:41FromGitter<zacharycarter> btw - interview with Riot's engineering leads is tomorrow night
20:41:50FromGitter<zacharycarter> send me good karma everyone plz :P
20:41:55Zevvffiw: for me the async magic only made sense once I grokked the way it ends up in C.
20:42:18dom96zacharycarter: All the best :)
20:42:52FromGitter<zacharycarter> well - I'm not sure comparing and contrasting terminology will necessarily provide insight into implementation
20:43:13FromGitter<zacharycarter> but I would presume - that most languages are handling it in a comparable fashion
20:43:21FromGitter<zacharycarter> but that's coming out of my butt - I have no real assurance there
20:43:27FromGitter<zacharycarter> thank's dom96 :D
20:47:43*smitop joined #nim
20:49:44Zevvyay for #10385, great stuff with all the documentation initatives
20:50:35dom96yeah, awesome job to narimiran and the brilliant contributors!
20:50:38FromGitter<arnetheduck> I'm happy with future[t] - let's me know what I can do with the return value, and the accompanying costs (dynamic allocation, etc)
20:50:49*oculux quit (Quit: blah)
20:51:16*oculux joined #nim
20:52:47ZevvYeah but I have to watch my learning colluegues try to return a newFuture[int]() from their .async procs :)
20:54:42FromGitter<arnetheduck> well, I just had the opposite case where a function was returning nothing and therefore caused a compile fail for a missing `discard` on the return value, because someone had created a smart macro that did this transformation.. when the future is returned, you know what to look for in the manual, at least
20:57:23dom96Yeah, the explicit return type also aids in discoverability
20:57:47dom96If no async functions mention Future then nobody will have any clue that they're used behind the scenes
20:57:55dom96I do feel your pain though, Zevv
20:58:13ZevvI'll stop complaining about it, I promise ;)
20:58:13dom96Sadly not everything can be intuitive :)
20:59:07*def- quit (Ping timeout: 240 seconds)
20:59:23*def- joined #nim
20:59:44*Gertm joined #nim
21:00:01Zevvin the end both solutions are just as good/bad: there is simply a serious transformation being done on the proc, and you really have to know all the details to see all the consequences
21:03:25smitopWhat is idiomatic: `Port 80`, `Port(80)`, or `80.Port`?
21:04:49dom96bah, why did I `git pull` nim
21:05:18dom96smitop: Either of the last two
21:08:54dom96https://github.com/nim-lang/Nim/issues/10433 :/
21:10:38dom96Looks like a bisect is in order
21:11:00dom96What I get for grabbing HEAD D:
21:11:40Araq1. runnableExamples run in their own module and import the current module.
21:12:01dom96"Maybe only when importing the module?"
21:12:03Araq2. it's now strings = nums.mapIt($(4 * it))
21:12:19Araqwe removed deprecated stuff, that's all
21:12:28Araqapparently the error message suffers from this.
21:12:28dom96oh
21:12:32dom96bahhhh
21:12:39Araq:-)
21:12:41dom96That's a piss poor error message
21:14:01dom96Pardon my language :P
21:14:54AraqI have no idea why it doesn't say "invalid number of parameters"
21:15:03Araqor something along those lines
21:15:30dom96Okay, well, feel free to reopen my issue
21:15:34dom96or just fix the error message
21:15:42dom96I'm guessing there may be a few people who run into this
21:15:51Araqbut again, "Maybe only when importing the module?" doesn't apply, runnableExamples "emulate" the import
21:16:07*mops_ joined #nim
21:16:43*miran quit (Ping timeout: 245 seconds)
21:17:03Araqhmm it tries to typecheck before deciding there is no variant of mapIt that can match, tough nut
21:17:49Araqwe can turn the .deprecated into an .error
21:18:02Araqso that people get a nice error message
21:20:26dom96Yeah, let's do that
21:22:19mops_Hi everyone! I'm quite new nim user. Can anyone recommend some good dependency injection container for nim?
21:22:46xacemops_: dependency injection manager? as in package manager?
21:23:28xacenim comes with `nimble` which lets you install and set project dependencies etc...
21:24:05mops_No I mean dependency injection IOC for concrete classes and interfaces. For example for .NET: https://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx
21:24:13Araqno it's some "interfaces for everything" paradigm from the OO people who don't understand programming.
21:24:43rayman22201@araq @dom96 It tries to typecheck the argument expression before it typechecks the function right? damn. This is the problem with macros injecting symbols. Why are good error messages so hard?
21:25:27AraqYou have procs operating on data. You create test data and pass it to your procs. No framework required.
21:26:34Araqno need to monkey patch your procs, no dynamic binding everywhere, test your code with test data, separate your code from your data.
21:27:24Araqrayman22201: the error message is precise but misleading :P
21:27:52rayman22201lol. yes, you are correct.
21:29:04dom96Araq: What are your thoughts on mocking frameworks? :)
21:29:55Araqnever needed one and I prefer my "goto implementation" to work and not to point me to some interface declaration shit
21:31:17Araq"Do you want to go to the interface implementing class instead?" Yes, ffs, and not to the one that's mocking me.
21:31:31mops_Yes thats fine. But how would you create this class graph A -> B -> C -> D (A depends on B, B depends on C, C depends on D). With DI container I can register instances of classes and then I can easily create for example A class without creating dependencies by hand. It is super convenient when system grows and there are more dependencies between entities. This of course one use case of DI. But I'm not sure how it will look in nim...
21:33:09AraqI don't have a class graph.
21:33:19mops_:)
21:35:32mops_Thats fine. Thanks for your time ;) I wish nim all the best! Bye :)
21:35:44rayman22201OOP is not very popular in Nim land.
21:35:52mops_I see
21:36:38rayman22201You would probably use some sort of macro to accomplish a DI system. There isn't really any existing project for it though.
21:36:42mops_unfortunetely it is easier for me to design in OOP way
21:37:35mops_Maybe I should learn to design systems in FP way? Do you know any good resoruces to learn it?
21:38:09*shashlick quit (Remote host closed the connection)
21:38:40rayman22201Nim is more old school imperative.
21:39:21FromGitter<arnetheduck> become good at nim: write nim programs. become good at programming: write different programs :)
21:40:03Araqmops_: you can use inheritance in Nim and closures give you much of what DI would give you
21:40:27Araqbut it's hardly the idiomatic solution
21:40:55mops_nim has single or multiple inheritance (like C++)?
21:41:28Araqat the same time I'm still researching how to write stateful UIs without OOP (*cough*)
21:41:58Araqsingle inheritance.
21:42:29mops_och, thats very exciting! because I always thought that UI is so natural in OOP
21:42:48mops_very interesting :)
21:43:22Zevvimmediate mode UIs are hip these days
21:43:45Araqreally?
21:44:12mops_reactive approach seems one option. In haskell they use reactive programming for UI
21:44:32rayman22201reactjs and the bunch is basically (lets take our stateful UI and pretend it' immediate mode)
21:44:50rayman22201Haskell as well, true
21:45:01rayman22201but Haskell doesn't really have a choice lol
21:45:10mops_:D
21:45:13*shashlick joined #nim
21:45:13*shashlick quit (Read error: Connection reset by peer)
21:45:14Araqreactjs is full of state, they wrap it in "components"
21:45:33rayman22201I didn't say it was good at it's job lol
21:46:02Araqreactjs is not "reactive programming" either
21:46:19Araqbtw.
21:46:37rayman22201cyclejs or elm are more proper "reactive programming" with stream abstractions and such
21:46:53Araqelm is not reactive
21:47:33Araqfor "reactive" you need a dependency graph, elm is just FP + DOM diffing.
21:48:01Araqand React is OO + DOM diffing.
21:48:27AraqVue.js is reactive.
21:48:33rayman22201:shrugs:
21:48:53dom96oh, is that why I'm getting the impression that so many people are hyped up about Vue?
21:49:00dom96btw you really need to invest time marketing karax
21:49:17dom96It really is a great framework, but unless it gets exposure it won't get far
21:50:05Araqyou're probably right but it got as far as I need it to go.
21:51:20Araqit's at v1 and nim isn't.
21:51:40dom96Argh, I wish I could use my supertype constructor and just cast it to the subtype
21:52:12dom96Do we have a way to handle this?
21:54:22dom96TIL https://nim-lang.org/docs/system.html#procCall%2Cuntyped
21:54:33FromDiscord_<exelotl> I've used Vue and it's really freaking nice, it's so powerful and Just Makes Sense, you can get the basics down in 30 mins
21:54:39Araqnot really. Use a factory proc
21:54:39dom96procCall is an odd name for this
21:54:56*aguspiza quit (Ping timeout: 240 seconds)
21:55:02dom96exelotl: basics meaning what? :)
21:56:17Araqexelotl: I will never use it again. I'd rather write down programs with own blood until I bled to death
21:56:42FromDiscord_<exelotl> haha wow xD
21:57:21dom96Now that's a quote to put on a T-shirt
21:58:49FromDiscord_<exelotl> dom96: like, the basic structure of having a page where elements are bound to javascript variables, conditional rendering
21:59:06*stefanos82 joined #nim
22:00:31Araqdom96: it turns a "method call" into a "proc call".
22:00:44dom96yeah, meh, not what I want anyway
22:00:59Araqwe could use "staticCall" instead except that 'static' already some a completely different meaning in Nim
22:01:04dom96I'll probably end up refactoring this to use composition eventually
22:01:12*mops_ left #nim (#nim)
22:01:12Araqgood boy. :-)
22:01:41*shashlick joined #nim
22:01:57dom96lol
22:08:52shashlicktest
22:09:11FromGitter<kaushalmodi> works
22:09:54shashlickjust upgraded matterbridge to latest - had to move to new slack tokens
22:10:21shashlicki hope to update koch xz and ship linux binaries before 0.19.4 comes out
22:12:33shashlickanyone knows the answer to this - https://stackoverflow.com/questions/54313875/how-to-redirect-output-to-file-if-no-console-detected-in-nim/54314090?noredirect=1#comment95448507_54314090
22:19:03shashlick@kaushalmodi - that branch name change didn't work on nightlies
22:19:10rayman22201hard to say without seeing more code. Maybe stdout is getting shadowed? There are two assigments in that example. Is the open failing or the stdout?
22:20:07shashlicki think it is better to tag with vVERSION-date since that will always be new and on the top
22:23:06FromGitter<kaushalmodi> shashlick: the problem is to find the HEAD built version
22:23:23FromGitter<kaushalmodi> the version for HEAD right now is 0.19.9, but that won't be the case always
22:23:48FromGitter<kaushalmodi> wondering why the branch name addition wouldn't work ..
22:24:34shashlickagain it won't help with sorting
22:24:39FromGitter<kaushalmodi> it has worked: https://github.com/nim-lang/nightlies/releases/tag/v0.19.9-f0be575
22:24:40shashlicksince it will not change
22:24:59FromGitter<kaushalmodi> I added the branch name to the `name` field
22:25:43FromGitter<kaushalmodi> (https://files.gitter.im/nim-lang/Nim/V388/image.png)
22:25:46shashlickyes but it won't be sorted correctly since the tags and the name will still be random due to the hash
22:26:12FromGitter<kaushalmodi> in the api, the last updated release becomes index 0
22:26:15FromGitter<kaushalmodi> of the JSON
22:26:34FromGitter<kaushalmodi> JSON -> https://api.github.com/repos/nim-lang/nightlies/releases
22:27:06FromGitter<kaushalmodi> I believe that fixing of sorting on the releases page is a separate issue
22:27:09shashlicktag needs to be `v0.19.9-2019-01-23` and name needs to be `v0.19.9-2019-01-23 nightly build`
22:27:21shashlickusing the build hash in tag and name won't help with sorting
22:27:28shashlickwhy do you need the branch name when it is already part of the version name
22:27:31FromGitter<kaushalmodi> ah, now I get it
22:27:41FromGitter<kaushalmodi> version name is 0.19.9
22:27:51FromGitter<kaushalmodi> it will change after the next major release
22:28:24FromGitter<kaushalmodi> I am thinking of how someone would reliably get the latest build of HEAD without knowing the version number
22:28:28shashlickok then remove the v0.19.9 part and instead use `devel-2019-01-23` and `version-0-19-2019-01-23` instead
22:29:06FromGitter<kaushalmodi> the only catch is that we won't get multiple releases on the same day
22:29:24FromGitter<kaushalmodi> if we attempt to rebuild, all the releases will club under the same release
22:29:41shashlickthat's fine - nightly is nightly 😄
22:29:47FromGitter<kaushalmodi> :)
22:29:54shashlickand if manually initiated, it is probably to replace the older one
22:30:03FromGitter<kaushalmodi> makes sense
22:30:20FromGitter<kaushalmodi> do you want me to change name and tag as you suggested?
22:30:31shashlickone other change we need to do is kick off all devel first and then all stable jobs
22:30:40shashlickright now it orders by OS
22:30:53shashlickthat way, most jobs for a given branch will start around the same time
22:31:03shashlickavoiding building of different hashes
22:31:06shashlickya please if you can
22:35:50FromGitter<iffy> Araq: If you're interested and have Node installed on your computer, here's my sscce https://github.com/iffy/node-nim-memory-bug
22:36:35dom96why not devel-commit_hash?
22:36:45dom96Not using the latest commit might be nice in some cases
22:36:48FromGitter<kaushalmodi> dom96: sorting
22:36:55dom96sorting for what?
22:37:12shashlicksince hashes are random, releases show up randomly on the page
22:37:14FromGitter<kaushalmodi> sorting of releases on https://github.com/nim-lang/nightlies/releases
22:37:29shashlicklook at the page and you'll see how the first posted isn't the latest always
22:40:17dom96devel-2019-01-23-commit_hash then?
22:40:31dom96or just create a page that lists these properly
22:40:48FromGitter<kaushalmodi> shashlick: remembered something ..
22:40:53FromGitter<kaushalmodi> you will need to uniquify tags
22:41:03FromGitter<kaushalmodi> else update on the same day won't get deployed
22:41:36FromGitter<kaushalmodi> so let's just do `<BRANCH>-<DATE>-<HASH>` as dom96 suggested
22:45:00shashlickthat's fine with me
22:49:17*PMunch quit (Remote host closed the connection)
22:49:25FromGitter<kaushalmodi> shashlick: not sure how to fix the order of builds in Travis
22:49:35FromGitter<kaushalmodi> probably need to manually add matrix / include?
22:51:11dom96Thank you for working on this by the way guys!
22:51:21shashlicki was hoping switching order of env and os would do it
22:52:41shashlickdeclaring env before os in the yaml
22:52:45shashlickhopefully it is that simple
22:52:55*Marumoto joined #nim
22:52:56shashlickelse not worth it, rather work on moving to koch CI
22:53:20shashlickdom96 - absolutely
22:53:50shashlickdom96 - pinging again on that init.sh PR
23:03:26*skellock quit (Ping timeout: 240 seconds)
23:15:17Araqyeah, write Nim programs instead of Bash scripts
23:15:53*vlad1777d quit (Ping timeout: 245 seconds)
23:24:11shashlickyou need to install nim first 😄
23:24:57shashlickthis is the choosenim init.sh script to install it
23:25:07shashlickdoes nim doc support cross references?
23:25:40*Vladar quit (Remote host closed the connection)
23:25:53shashlicknm
23:38:46*skellock joined #nim
23:42:30FromGitter<iffy> If I did: `var res:string = "something"; GC_ref(res); result = addr res[0]` earlier, and now I want to `GC_unref` that string but I only have the result cstring. How do I go from cstring to something I can `GC_unref`?
23:43:08FromGitter<iffy> `var to_unref:string = $mycstring` seems to make a copy
23:43:34FromGitter<iffy> dom96: ^ you suggested that first part a few days ago
23:46:40rayman22201`cast[string](mycstring)` maybe? If you know for sure it's the same string.
23:49:20FromGitter<iffy> Hmm... that's giving me an out-of-memory error. Maybe the cstring isn't null-terminated? mycstring.repr seems fine, though
23:50:27rayman22201Nim strings are no longer null terminated iirc
23:51:05FromGitter<iffy> `var toUnref:string = caststring (mycstring)` is causing the out of memory error
23:53:59rayman22201Hrmm. Can you copy the nim string to cstring first and then pass it to c?
23:54:32leorizeyou can't `cast[cstring]` because string has a totally different structure in memory
23:54:44FromGitter<iffy> In one function, I create a var string, then return it as a cstring to the calling C code.
23:54:56FromGitter<iffy> (and GC_ref it before I return it)
23:55:02leorizeusually you would pass your string to C like this: `cstring(string)`
23:55:25FromGitter<iffy> Once the calling C code has made a copy, the calling C calls another function to tell my Nim code to release the string
23:55:47leorizethen I suggest passing the real string itself
23:55:58rayman22201That makes sense. That is what I thought @leorize. But since he was passing a nim string through from the start, I thought c might respect the memory layout and it might work.
23:56:01FromGitter<iffy> back to C?
23:56:33leorizeyep
23:56:40leorizepass it as a pointer of sort
23:56:45leorizethen a proc to get the cstring
23:56:55leorizethen a proc to remove the passed string
23:57:24FromGitter<iffy> Is the return type of my function (it's called `echo`) `string` then? Or `ptr string`?
23:59:01FromGitter<iffy> I'll be back tomorrow; got to go