<< 19-01-2020 >>

---

00:00:01	*	junland quit (Quit: %ZNC Disconnected%)
00:01:19	*	junland joined #nim
00:13:09	*	zedeus quit (Ping timeout: 265 seconds)
00:17:08	*	NimBot joined #nim
00:34:24	*	zedeus joined #nim
01:11:07	*	voltist joined #nim
01:18:25	*	Cthalupa joined #nim
01:18:53	*	lritter quit (Ping timeout: 272 seconds)
01:19:23	*	lritter joined #nim
01:27:59	*	zedeus quit (Quit: WeeChat 2.7)
01:29:49	*	zedeus joined #nim
01:40:46	FromDiscord	<treeform> I am not a fan of tupples for some reason... So I don't use that in vmath.
01:41:03	*	Hideki_ joined #nim
01:41:54	*	Hideki_ quit (Client Quit)
01:43:33	*	Hideki_ joined #nim
02:29:55	*	Tyresc quit (Quit: WeeChat 2.7-dev)
02:30:55	*	leorize joined #nim
02:31:54	leorize	Araq: how would destructors interact with {.noreturn.} procs?
02:32:13	leorize	will the resources be cleaned up or they will just be left there?
02:34:11	disruptek	great question. you can look at what happens by building the compiler with -d:toDebug="always" and saving the compiler's output.
02:36:38	leorize	well the problem is that this is not in the destructors spec iirc...
02:37:24	disruptek	ergo, code is spec.
02:40:35	leorize	the answer is no: https://play.nim-lang.org/#ix=27Ni
02:41:35	disruptek	what you can do is raise.
02:42:20	leorize	my only concern about this is that file descriptors will leak on `exec` calls, since they are not closed by default
02:42:45	disruptek	they are closed by default.
02:43:01	leorize	nope, unless you mark them with O_CLOEXEC/FD_CLOEXEC
02:43:20	leorize	which currently is not done within Nim...
02:43:30	disruptek	i mean, they should have their destructors run by default upon leaving scope.
02:44:12	disruptek	there are cases where they are lifted, but...
02:44:20	leorize	well but if you have an httpclient open for instance
02:44:50	leorize	then you exec, then that fd will leak
02:45:30	leorize	this is also a problem if stuff are executed via fork-exec
02:45:45	disruptek	yeah, i mean, that's kinda the fault of the programmer, right?
02:46:31	leorize	well, they would trust that "destructors" will close it for them :P
02:46:52	disruptek	but who is to say what the correct behavior is?
02:47:32	leorize	I guess to anticipate for destructors, we should mark every spawned destructible fds as O_CLOEXEC/FD_CLOEXEC
02:48:14	leorize	in the stdlib ofc :P
02:48:31	disruptek	hmmm.
02:49:03	leorize	FDs are so easy to leak :/
02:49:26	leorize	if you don't mark them with CLOEXEC ofc :P
02:50:10	leorize	fork creates duplicates for all of them, then exec will keep them open
02:50:42	leorize	luckily in stdlib this can only happen if you do -d:useFork, which is the default for the bsds iirc
02:51:27	disruptek	still, i dunno how i feel about forcing a flag.
02:51:42	FromDiscord	<DeltaPHC> lol. Unrelated, but I'm code-golfing the classic "99 bottles" program. Got it down to 322 chars with this monstrosity: https://play.nim-lang.org/#ix=27Nk
02:52:04	disruptek	i feel like it's not too ugly to be explicit and clear; it's not really the job of the language to manage the environment this way.
02:52:12	leorize	disruptek: well just use it for stdlibs high-level abstraction stuff, like Socket, HttpClient, etc.
02:52:32	leorize	and a big warnings in the docs that the destructors won't run on {.noreturn.}
02:52:42	leorize	s/a/several/
02:52:49	leorize	should be enough :P
02:53:10	disruptek	maybe we should lead by example.
02:53:21	disruptek	code it the longer, correct way.
02:54:03	disruptek	if it's really arduous, y'know, more code may yet be written.
02:58:23	leorize	looks like file descriptor is the only significant thing that leak through exec
02:58:38	disruptek	there's that, at least.
03:01:18	leorize	FDs really are designed to leak
03:02:37	leorize	I've looked at various posix documentations of process spawning, and all of them explicitly say that unless marked with O_CLOEXEC, any fd that's still open will remain open when `exec` happens
03:03:44	leorize	ah, someone already reported this: https://github.com/nim-lang/Nim/issues/6602
03:03:46	disbot	➥ File descripters should be non-inheritable by default.
03:04:18	nisstyre	Are there any XCB bindings for Nim? I need "xcb_poll_for_event" (or something like it), but the standard Xlib doesn't really support that afaict
03:05:14	disruptek	i think solitudesf is the one to ask.
03:05:36	*	Hideki__ joined #nim
03:05:51	nisstyre	I could just use importc for it I guess
03:05:57	nisstyre	since I only need that one function really
03:06:19	nisstyre	although I guess I would need the xcb event types too
03:06:29	*	Hideki_ quit (Read error: No route to host)
03:06:51	disruptek	i just don't think it's a bug, leorize.
03:06:55	*	Hideki__ quit (Read error: Connection reset by peer)
03:07:02	*	Hideki_ joined #nim
03:07:47	leorize	destructors not run on {.noreturn.}?
03:08:03	disruptek	no, the CLOEXEC
03:09:02	disruptek	i don't know what the right move is for noreturn.
03:09:19	leorize	well it's a problem when you start making long running processes that spawn other "maybe long running" processes
03:09:31	*	Hideki__ joined #nim
03:09:44	disruptek	i get it, but i think we have to follow convention here, too.
03:09:57	*	Hideki_ quit (Read error: No route to host)
03:10:25	*	Hideki_ joined #nim
03:10:28	leorize	wdym?
03:10:50	disruptek	i think we have to preserve the possibility that the user wants or expects their destructors not to run.
03:11:03	disruptek	maybe they know more about the situation than we do.
03:11:10	disruptek	remember, they can always raise.
03:11:53	disruptek	they can also free their stuff.
03:12:50	*	Hideki__ quit (Read error: Connection reset by peer)
03:13:04	leorize	i thought that's the not running on {.noreturn.}? :p
03:13:47	disruptek	right. i don't think they should run on .noreturn
03:15:57	*	ptdel quit (Ping timeout: 260 seconds)
03:20:02	leorize	disruptek: well I guess this is how to make it run :P https://play.nim-lang.org/#ix=27Ns
03:21:37	disruptek	that's not bad, is it?
03:21:50	leorize	it's terrible :P
03:22:17	leorize	it depends on experimental api, and I'm pretty sure it can't nest
03:22:44	leorize	oh hey it can
03:22:53	leorize	still depending on unstable api is never a good thing
03:24:25	disruptek	i'm just really wary of getting it wrong. this is exactly the sort of thing that is important you get right.
03:26:09	disruptek	now i want a mock library. like, a really, really good one.
03:27:08	*	lritter quit (Remote host closed the connection)
03:37:09	*	Hideki__ joined #nim
03:37:09	*	Hideki_ quit (Read error: Connection reset by peer)
03:37:38	*	ptdel joined #nim
03:40:32	*	Hideki_ joined #nim
03:40:32	*	Hideki__ quit (Read error: Connection reset by peer)
03:51:38	*	logand`` joined #nim
03:52:32	*	nickster4 joined #nim
03:55:02	*	muffindrake quit (Ping timeout: 260 seconds)
03:55:38	*	logand` quit (Ping timeout: 268 seconds)
03:57:12	*	muffindrake joined #nim
03:58:45	disruptek	i want a way to record a stream with timestamps on when the data became readable. then i want to be able to play that stream back, modifying the time signature.
04:00:45	disruptek	seems pretty useful, right?
04:17:57	*	nickster quit (Quit: The Lounge - https://thelounge.chat)
04:17:57	*	nickster4 is now known as nickster
04:21:30	*	Hideki__ joined #nim
04:21:32	*	Hideki_ quit (Read error: Connection reset by peer)
04:22:05	*	Hideki__ quit (Read error: Connection reset by peer)
04:22:09	*	Hideki_ joined #nim
04:23:30	*	Hideki__ joined #nim
04:23:30	*	Hideki_ quit (Read error: Connection reset by peer)
04:32:01	*	Hideki_ joined #nim
04:32:01	*	Hideki__ quit (Read error: Connection reset by peer)
04:47:22	*	Hideki__ joined #nim
04:47:33	*	Hideki_ quit (Read error: No route to host)
04:47:51	*	Hideki_ joined #nim
04:47:54	*	Hideki__ quit (Read error: Connection reset by peer)
04:57:50	*	dddddd quit (Remote host closed the connection)
05:10:51	*	Ekho- is now known as Ekho
05:43:49	*	Hideki_ quit (Remote host closed the connection)
05:44:37	*	Hideki_ joined #nim
05:48:51	*	Hideki_ quit (Ping timeout: 240 seconds)
06:14:24	shashlick	I don't get it - even if I have a single-threaded version of my code, I'm having some gc funkiness going on - same memory location is being reused despite returning from a proc on the next invocation
06:14:30	shashlick	don't see the issue with boehm
06:14:48	disruptek	-d:useMalloc
06:15:19	shashlick	nope still
06:15:30	disruptek	this isn't arc, right?
06:15:36	shashlick	nope standard
06:15:44	disruptek	damn.
06:16:02	shashlick	i've spent hours on this crap
06:16:21	shashlick	who's messing with my memory
06:16:32	disruptek	despite returning from a proc on the next invocation?
06:16:40	shashlick	yep
06:16:43	disruptek	yep
06:16:56	shashlick	https://github.com/genotrance/px2/blob/master/server.nim#L58
06:17:13	*	Hideki_ joined #nim
06:18:22	shashlick	i'm using httputils and it avoids copies and points to stuff in the middle of strings
06:18:42	shashlick	and then calling libcurl just throws everything off
06:18:46	shashlick	deepCopy doesn't help either
06:19:10	disruptek	you're running it single-threaded.
06:19:20	shashlick	works the first time, then next invocation of processRequest - where everything should be brand new - still issues
06:19:25	shashlick	i've removed all threading and still same
06:19:34	shashlick	must be some dumbass thing i've done
06:19:54	*	voltist quit (Quit: Leaving)
06:19:59	disruptek	i've only had that issue on global iteration.
06:20:19	disruptek	outside a proc.
06:22:46	*	narimiran joined #nim
06:23:14	shashlick	okay now threads are optional
06:24:42	disruptek	i don't see the problem.
06:25:26	shashlick	so problem happens here - https://github.com/genotrance/px2/blob/master/curl.nim#L66
06:25:35	shashlick	creating a list of headers to pass to libcurl
06:25:49	shashlick	when I print it out, it's all fine
06:25:57	shashlick	but when it goes to curl, there's spurious characters in it
06:26:10	disruptek	that's my least-favorite kind of character.
06:26:11	shashlick	not the first time, but in subsequent calls
06:27:04	disruptek	well that's bananas.
06:27:29	disruptek	put the concatenation into a cstring type and print that.
06:28:06	disruptek	i wonder if some of this stripping and shaving zevv has been doing has finally nicked an artery.
06:28:24	shashlick	same issue with arc as well, had to turn threading off to get it working
06:28:43	shashlick	well, fails with 1.0.4 as well
06:28:46	disruptek	let's see what it looks like as a cstring.
06:29:27	shashlick	well, echoing it might just switch it back to a string and work
06:29:40	disruptek	right, but i want to see it come out of the cstring type.
06:30:06	disruptek	our strings are different now.
06:30:59	shashlick	you're right, i see it in my prints too
06:31:09	shashlick	http://google.com becomes http://google.com*
06:31:51	disruptek	some say it's better but i say it ain't.
06:32:01	disruptek	i'd rather laugh with the sinners than cry with the saints.
06:32:09	disruptek	the sinners are much more fun...
06:32:43	shashlick	there are no sinners nor saints
06:34:01	disruptek	so it's realloc; aka zevv's bug.
06:34:38	disruptek	what are the chances?
06:34:47	*	rockcavera is now known as Guest87279
06:34:47	*	tiorock joined #nim
06:34:47	*	Guest87279 quit (Killed (weber.freenode.net (Nickname regained by services)))
06:34:47	*	tiorock is now known as rockcavera
06:34:57	shashlick	how do you mean
06:35:00	disruptek	this must have been exposed by something else.
06:35:26	disruptek	we happen to discover the same dirty buffer bug independently, and twice?
06:38:15	shashlick	well it is broken as far back as 0.20.2
06:38:22	shashlick	cannot go before that since ya
06:39:13	*	Hideki_ quit (Ping timeout: 260 seconds)
06:39:16	disruptek	i don't get it.
06:41:06	*	Hideki_ joined #nim
06:41:12	shashlick	what now
06:41:22	disruptek	this really makes no sense.
06:41:47	shashlick	it is not null terminated correctly
06:41:54	shashlick	if i print as string, it knows how long it is
06:42:03	shashlick	if i print as cstring, you see extra stuff
06:42:43	disruptek	but the cstring conversion should terminate it correctly.
06:43:14	shashlick	nope
06:43:31	disruptek	it never does?
06:43:42	disruptek	i'm using them all over the place. never had a problem.
06:44:21	shashlick	ya there's something else
06:44:43	shashlick	so now I'm `(name & ": " & value & " ").strip()`
06:44:53	*	nsf joined #nim
06:45:08	disruptek	kinky.
06:45:35	disruptek	i'm big on objectifying strippers.
06:46:16	shashlick	yep that fixed it
06:46:36	shashlick	two places - with the headers iterator and uri()
06:46:52	shashlick	i'd like to blame https://github.com/status-im/nim-http-utils/blob/master/httputils.nim#L557
06:47:13	shashlick	blame status
06:47:25	disruptek	well why wouldn't you use stdlib?
06:47:46	disruptek	gah it didn't even occur to me.
06:47:59	shashlick	cause it is all or nothing with httpserver
06:48:02	shashlick	i need more control
06:48:26	shashlick	plus i couldn't use asynchttpserver so good luck
06:48:40	shashlick	the procs aren't written in a way where i could take over things i want
06:48:50	disruptek	well, no argument here.
06:49:10	shashlick	there is no plain httpserver, only async
06:49:12	disruptek	i didn't realize this was that project.
06:49:26	Araq	hi
06:49:27	disruptek	like i said, it needs to be replaced.
06:49:34	shashlick	hey Araq
06:49:36	disruptek	sup
06:49:39	shashlick	welcome to my grumbling
06:51:36	disruptek	why do people write code like this?
06:52:02	shashlick	well, you know what - it is httputils' fault
06:52:18	shashlick	they simply cast a string of bytes into a string
06:52:20	shashlick	https://github.com/status-im/nim-http-utils/blob/master/httputils.nim#L565
06:52:32	disruptek	i know.
06:52:56	disruptek	hence my question.
06:53:02	leorize	Windows is weird
06:53:16	leorize	so fopen() doesn't leak fds on Windows
06:53:17	shashlick	the need for speed
06:53:29	disruptek	who cares how efficient it might be if it's broken?
06:53:29	leorize	it leaks the handle instead
06:57:28	leorize	so I'm working on #6602, and now I need a name for an API to set if a FileHandle can be inherited by child processes
06:57:28	disbot	https://github.com/nim-lang/Nim/issues/6602 -- 3File descripters should be non-inheritable by default.
06:57:31	leorize	any ideas?
07:00:30	Araq	shashlick: 'cast' between strings and seqs is semi-officially supported
07:01:09	shashlick	then why does converting to a cstring result in extra chars
07:02:34	leorize	someone forgot the null terminator?
07:03:05	shashlick	https://github.com/status-im/nim-http-utils/blob/master/httputils.nim#L565 <= they are casting a seq[byte] into a string
07:03:13	shashlick	if you then cstring that, you get extra stuff
07:03:35	Araq	yeah sure, seq don't have zero terminators, only strings do :-)
07:04:08	shashlick	what's amusing is that you'd expect a \r there but you get other stuff which makes no sense
07:04:27	shashlick	since it is just pointing to a range within the larger buffer
07:04:40	leorize	this is exactly why I always need a len() when I work with cstring
07:05:14	shashlick	joys of coding `(r.uri() & " ").strip()`
07:05:52	FromGitter	<Varriount> I'm uncomfortable with strings being casted to a sequence
07:06:08	shashlick	funny thing is that --gc:boehm is cool with this and you don't see issues
07:06:21	shashlick	so it's like the buffer is going out of scope or something and getting collected
07:06:33	leorize	well they are internally identical
07:06:47	leorize	I guess we need an official API for this instead of casting around
07:06:59	shashlick	i'm really not sure what's up here but at least i can proceed for now
07:07:09	shashlick	i'll bet it will bite me else where
07:07:22	FromGitter	<Varriount> leorize: While they are internally identical, strings have that null separator
07:08:27	leorize	I'd advice to never rely on that
07:08:43	leorize	most of the C API I have seen usually take a buflen
07:09:04	shashlick	tell libcurl that
07:09:46	FromGitter	<Varriount> leorize: Hence Why I'm uncomfortable with it
07:10:01	leorize	shashlick: they don't have an api with buflen?
07:10:14	shashlick	https://curl.haxx.se/libcurl/c/curl_slist_append.html
07:10:17	leorize	Varriount: I guess this is why we need an official solution :P
07:13:35	leorize	shashlick: I guess this is a walkaround that you can do: setLen +1 the string, then it's safe to pass to curl
07:13:50	leorize	or just copy it should do
07:16:19	shashlick	deepCopy didn't really help
07:16:34	leorize	setLen +1 it is then
07:23:17	*	ptdel quit (Ping timeout: 260 seconds)
07:24:54	shashlick	so be it, it isn't quite as ugly
07:32:44	FromGitter	<Varriount> leorize, shashlick: That's disgusting
07:55:52	*	solitudesf joined #nim
08:05:17	*	gmpreussner joined #nim
08:10:13	*	Jjp137 quit (Quit: Leaving)
08:10:20	*	Jjp137 joined #nim
08:12:12	*	gmpreussner quit (Ping timeout: 258 seconds)
08:34:48	*	narimiran quit (Quit: leaving)
08:52:23	shashlick	nim isn't loading any libcurl dll I'm giving it
08:52:29	shashlick	just says could not load
08:52:34	shashlick	32-bit nor 64-bit
08:52:43	shashlick	any ideas?
08:53:39	*	jjido joined #nim
08:57:08	Araq	did you get the calling conventions right?
08:57:19	shashlick	i'm using your libcurl wrapper
08:59:17	shashlick	okay got it running, but getting an overflow error
08:59:37	shashlick	the headerfunction callback is getting ridiculous values for size and nmemb
09:02:53	shashlick	you have to be right don't you
09:03:47	Araq	"my" wrapper?
09:04:04	Araq	when did I write that one, 10 years ago?
09:04:12	shashlick	the callback is in my code right and I got that from choosenim which only uses curl on osx
09:04:18	shashlick	it didn't have {.cdecl.}
09:04:20	Araq	better c2nim it from scratch :P
09:04:39	shashlick	it's still working for the most part 🙂
09:04:50	*	luis_ joined #nim
09:10:33	*	tane_ joined #nim
09:14:23	shashlick	my word, it works! px2 POC is a success
09:17:23	*	jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:24:46	shashlick	390 lines of code and you get a state of the art replacement for cntlm backed by libcurl
09:25:13	shashlick	now all that remains is configurability and other cosmetics
09:27:44	*	nsf quit (Quit: WeeChat 2.7)
09:28:25	shashlick	brilliant, it was a very painful but amazing what can be accomplished over a weekend
09:31:47	*	Hideki_ quit (Remote host closed the connection)
09:32:24	*	Hideki_ joined #nim
09:32:49	Zevv	ah it all worked out for you, sweet
09:33:07	shashlick	yep, phew, should sleep - 1/2 the night is over
09:33:18	Zevv	who cares :)
09:33:30	Zevv	sleep well then!
09:33:41	shashlick	i've crossed the age where it didn't matter 😉
09:34:08	shashlick	and this is the second night in a row
09:37:12	*	Hideki_ quit (Ping timeout: 265 seconds)
09:37:55	*	Hideki_ joined #nim
09:38:35	*	luis_ quit (Ping timeout: 272 seconds)
09:39:00	*	silvernode joined #nim
09:42:38	*	Hideki_ quit (Ping timeout: 268 seconds)
09:43:56	*	Hideki_ joined #nim
09:48:41	Araq	how can we tell the CIs that it's 2020 and we default to C++11 now?
09:50:22	*	jjido joined #nim
10:06:18	FromGitter	<mratsim> Vcc defaults to C++11
10:06:31	leorize	Araq: pass -std=c++11 to gcc compatible compilers
10:12:54	*	oculux quit (Quit: blah)
10:16:00	FromGitter	<sheerluck> i like c++20 more
10:29:23	*	leorize quit (Ping timeout: 240 seconds)
10:34:16	*	NimBot joined #nim
10:39:24	shashlick	thank you!
10:42:41	*	luis_ joined #nim
10:53:11	*	nsf joined #nim
10:53:38	*	dom96 continues to wonder why Status is reimplementing things in the stdlib
10:59:55	*	Pixeli joined #nim
11:01:53	stefantalpalaru	It's simple: upstreaming stdlib changes takes too damn long. If they are considered "features", they can only get into x.y.0 releases which are done twice a year.
11:02:03	luis_	hi all, how do I get the absolute value of a number in Nim?
11:03:12	stefantalpalaru	Other times, changes are simply rejected because the BDFL doesn't want to maintain them: https://github.com/nim-lang/Nim/pull/9724
11:03:13	disbot	➥ unittest: opt-in test parallelisation
11:03:27	dom96	stefantalpalaru: see, but you're reimplementing things from scratch. I'd understand if you just fork what's there already with the possibility to upstream it later, but you're not doing that.
11:03:45	stefantalpalaru	So the workaround is to fork as much of the stdlib as we need, in order to get the bug fixes or features we need.
11:04:42	stefantalpalaru	"Sorry, this is not something we are keen on maintaining. Unittest is already very quirky, don't want it to use multithreading. Please create a fork of unittest that provides this feature."
11:04:57	dom96	And yes, I did check the initial commit of the http-utils package
11:05:01	stefantalpalaru	It doesn't get any more clear than that.
11:05:44	stefantalpalaru	Upstream is just not interested in imporoving stdlib and, when it is, it might take 6 months for it to reach an official release.
11:06:09	stefantalpalaru	So the question is: why aren't you forking stdlib modules?
11:07:48	dom96	Are you asking me?
11:07:54	stefantalpalaru	Yes.
11:08:25	dom96	Can you give me an example where I have reimplemented something?
11:08:30	dom96	without forking stdlib?
11:08:58	stefantalpalaru	That's not how the English language works.
11:09:28	lqdev[m]	luis_: use math.abs
11:09:35	dom96	That's... what?
11:10:03	solitudesf	lqdev[m], abs is in system
11:10:09	stefantalpalaru	That's a non-sequitur. I'm asking you why you aren't forking the stdlib and you respond with gibberish. Come on, it's a simple question.
11:10:11	lqdev[m]	oh, right
11:10:20	lqdev[m]	thought it'd be in math
11:10:37	lqdev[m]	man, system is big
11:10:55	dom96	My answer is: I always fix things in the stdlib. I don't "fork" it because I have commit access to the Nim repo
11:11:04	dom96	But that's just semantics
11:11:21	dom96	The reason I asked you to show me evidence of where I have reimplemented stuff is because you are implying that I have
11:12:32	stefantalpalaru	ASo you use Nim's devel branch in your projects?
11:12:37	stefantalpalaru	*So
11:13:14	*	luis_ quit (Ping timeout: 240 seconds)
11:14:16	dom96	Sometimes, if I need it.
11:15:40	dom96	Even if I didn't and needed some stdlib fixes it would be trivial to backport them to a stable release.
11:16:30	dom96	But using bleeding edge Nim works fairly well in general.
11:19:05	dom96	Once again I ask you, why reimplement http utilities when you could instead fork the code into a package and fix what you need, then upstream it at a later date? Surely that would take far less time and give back a lot to the Nim community
11:20:19	planetis[m]	how did you guys choose to respond to taking long to upstream changes, would you do something better, like discuss it more publicly, demand to change release schedule, etc? i share the same concerns with dom96 but i not familiar with the situation so i am not drawing any conclussions.
11:21:42	*	luis_ joined #nim
11:22:43	*	ikan-keli_ quit (Ping timeout: 258 seconds)
11:24:27	stefantalpalaru	dom96, you'll have to ask cheatfate. I wasn't there when the decision was made for status-im/nim-http-utils.
11:25:29	*	ikan-keli_ joined #nim
11:26:10	dom96	Fair enough
11:27:37	dom96	Fun trivia: async await became a thing in Nim all the way back in 2014 https://nim-lang.org/blog/2014/04/21/version-094-released.html :O
11:28:00	stefantalpalaru	planetis, there's a #nim-testers IRC channel where I complained about https://github.com/nim-lang/Nim/pull/12922 not getting into 1.0.6 because it's considered a "feature" and semver patch versions are only for bugfixes. When I couldn't convince anyone that this cherry-picking based development model where the devel branch is left stale for half a year needs to be changed, I fell back to asking for monthly x.y.0 releases.
11:28:01	disbot	➥ generic stack trace overriding mechanism
11:28:31	dom96	What is the purpose of that channel?
11:28:40	stefantalpalaru	Testing release candidates.
11:29:13	stefantalpalaru	In this case, https://github.com/nim-lang/nightlies/releases/tag/2020-01-16-version-1-0-2f557f7
11:29:20	dom96	These kinds of things should probably be discussed here
11:29:23	FromDiscord	<mratsim> @shashlick this should fix your issue, pending review: https://github.com/status-im/nim-http-utils/pull/9
11:29:24	disbot	➥ Null terminate public strings
11:29:32	*	dadada joined #nim
11:29:38	dadada	hey
11:29:39	FromDiscord	<Rika> has anyone made a pushdown automaton on nim? i know someone made an fsm
11:29:53	dadada	is there a roadmap with future planned changes to the language?
11:30:08	dom96	mratsim: one reason why I dislike seq[byte] ;)
11:30:08	stefantalpalaru	dom96, I tried to: https://irclogs.nim-lang.org/29-12-2019.html#15:42:05
11:30:11	FromDiscord	<mratsim> @Rika, a pushdown automaton is just a FSM + a stack
11:30:16	FromDiscord	<Rika> i do know that
11:30:20	FromDiscord	<Rika> but im a lazy fuck
11:30:25	FromDiscord	<mratsim> the json parser is a pushdown automaton
11:30:41	*	luis_ quit (Quit: luis_)
11:30:45	FromDiscord	<Rika> i'll prolly just fuck around with the fsm no?
11:30:51	FromDiscord	<Rika> prolly yeah
11:30:59	FromDiscord	<mratsim> you can also adapt synthesis , just save states to go back to in a stack
11:31:11	*	luis_ joined #nim
11:31:31	FromDiscord	<Rika> i dont even know if i should use a pushdown automaton though lmao
11:31:48	FromDiscord	<Rika> i'm thinking of using it for saving what ui menu i'm at for the application i'm making
11:32:00	FromDiscord	<Rika> does it make sense to use a pushdown automaton for that?
11:32:05	FromDiscord	<mratsim> THe easiest way to learn pushdown automaton is to write a brainfuck interpreter
11:32:09	FromDiscord	<mratsim> yes it does
11:32:21	FromDiscord	<mratsim> that's probably the most maintainable way as well
11:32:33	FromDiscord	<Rika> yeah i had a light bulb moment
11:33:06	dom96	stefantalpalaru, I see. Got lost in the noise I suppose. I think these kinds of problems deserve a discussion in the forum.
11:33:07	FromDiscord	<Rika> the issue is prolly creating the transitions because that can be a mess so i'll have to think of a good api for the pd automaton
11:33:58	FromDiscord	<mratsim> this is the pushdown automaton part of my brainfuck interpreter: https://github.com/mratsim/jitterland/blob/master/bfVM_v02.nim#L48-L52
11:34:30	FromDiscord	<mratsim> just saving and restoring the beginning of loops
11:34:44	FromDiscord	<Rika> @_@
11:34:50	dom96	btw with regards to async await, I'm putting it on the record, I think we should take inspiration from Rust and try to implement polling-based futures for zero-cost abstraction async await (for Nim 2.0)
11:35:07	FromDiscord	<Rika> woah discussion about nim 2.0
11:35:10	planetis[m]	also ime araq is not a bdfl at all, but you know, people who do all the work also get a bigger vote, this is not uncommon,
11:35:20	FromDiscord	<mratsim> Nim futures are not polling?
11:35:30	FromDiscord	<Rika> araq doesnt give a bdfl feeling
11:35:38	dom96	mratsim: nope
11:35:41	planetis[m]	in households for example...
11:35:44	dom96	Surprised you don't know that
11:36:15	FromDiscord	<mratsim> I almost didn't touch async/await
11:36:43	FromDiscord	<mratsim> spawn/sync (multithreading) is already quite a handful
11:36:51	dom96	Good that you don't know. I will definitely point this out during my FOSDEM talk then
11:37:08	dom96	or rather, good that you tell me that you don't know :)
11:38:39	FromDiscord	<Rika> what does it mean by futures being polling?
11:38:59	FromDiscord	<mratsim> btw, in the current design of async dispatch, how would it make sense to cooperate with a threadpool? an event loop per thread would work? I expect the OS primitives handle race conditions gracefully
11:40:42	dom96	mratsim: event loop per thread is how httpbeast works. You can also get pretty far by enabling `await spawn myThread()`, which we got pretty close to.
11:43:14	federico3	dom96: speaking of which, did you document what is not async in asyncnet and jester?
11:43:51	dom96	huh? everything should be async. Are you referring to asyncfile not being async?
11:44:10	federico3	that one and IIRC there was something else
11:45:17	FromDiscord	<mratsim> regarding string vs seq[byte], this would also have been an issue if the httpRequest buffer was a string. Casting a subslice of a string or seq[byte] to string will not zero-terminate it
11:46:08	FromDiscord	<mratsim> Also the ultimate rootcause is the design of C cstring
11:47:03	dom96	True, which leads me to another suggestion: we should be as vigilant about `cast` as Rust is about `unsafe` and possibly implement something similar to `cargo-geiger` but for `cast` and other "unsafe" constructs
11:48:36	dadada	are there any accepted proposals for future changes to the Nim language?
11:48:42	dadada	or a list of those?
11:48:54	FromDiscord	<mratsim> Shouldn't that be handled by nimpretty?
11:49:45	FromDiscord	<mratsim> @dadada: https://github.com/nim-lang/RFCs/issues https://github.com/nim-lang/RFCs/milestone/1 https://github.com/nim-lang/Nim/milestones
11:50:10	dom96	dadada, it's all a bit disorganised, but reading through the RFCs issues can give you some sense: https://github.com/nim-lang/rfcs
11:50:35	dom96	oh cool, I didn't know about that milestone
11:51:31	FromDiscord	<mratsim> I'm not sure why github hides the milestones
11:51:42	FromDiscord	<mratsim> if you don't have the direct link it's impossible to discover
11:52:14	dadada	mratsim: good point
11:52:18	dom96	I'll edit the readme to include this link
11:53:13	FromDiscord	<mratsim> btw, while you do maintenance, can I get contributor rights to RFCs, I can't move RFC from the Nim main tracker to the RFCs repo
11:53:52	dom96	Tbh I don't think we should do that
11:54:09	dom96	Instead we should close the issue and say "Please write up a proper RFC in the RFC repo"
11:54:27	dom96	Otherwise we'll get vague tiny and low-effort issues
11:54:49	dadada	that list of milestones ends with 1.1 and contains only one proposal, it's not very useful that way
11:55:20	dadada	at least currently, don't know how it used to look
11:58:40	*	dcmertens joined #nim
11:59:16	FromDiscord	<mratsim> mmmh, for example this one is short but I wouldn't say it's low-effort: https://github.com/nim-lang/Nim/issues/11776
11:59:17	disbot	➥ Exception should not be Defect
12:00:10	FromDiscord	<mratsim> or this one, we should probably be closed? cc @Araq https://github.com/nim-lang/Nim/issues/8363
12:00:12	disbot	➥ Rework Nim's exception handling ; snippet at 12https://play.nim-lang.org/#ix=27OQ
12:03:47	dom96	mratsim: I added you as a collaborator
12:03:56	dom96	btw how is yglukhov, haven't seen him in some time
12:07:08	*	krux02 joined #nim
12:07:35	FromDiscord	<mratsim> he is in vacation right now. He has been fighting peer discovery for P2P for months
12:08:05	dom96	ahh nice
12:18:35	*	luis_ quit (Remote host closed the connection)
12:25:49	*	oculux joined #nim
12:26:31	dadada	https://github.com/nim-lang/RFCs/milestone/1 <- 4 proposals that look nice
12:26:53	dadada	is araq a full time nim dev?
12:30:12	*	krux02 quit (Remote host closed the connection)
12:31:34	*	krux02 joined #nim
12:32:02	*	krux02 quit (Remote host closed the connection)
12:34:20	dadada	on the bountysource page: "Nim has never had anyone working on it full-time"
12:34:31	dadada	makes Nim all the more impressive
12:34:47	dom96	that's pretty outdated
12:35:03	dom96	This was true until 2 years or so ago
12:36:16	dadada	dom96: then enlighten me
12:40:50	FromDiscord	<Rika> i think there are a few thanks to status.im
12:43:14	dadada	great
12:43:25	dadada	is there a nim developers conference or anything like that planned?
12:45:28	*	dddddd joined #nim
12:49:59	FromGitter	<zetashift> some talks at FOSDEM but for now no exclusively Nim conf planned
12:52:27	dadada	ah
12:59:07	dadada	did google give any reason why Nim has so far been rejected for GSoC?
13:01:07	dadada	the deadline of 2020 is: Deadline February 5, 2020
13:01:15	dadada	https://summerofcode.withgoogle.com/
13:01:29	dom96	Want to help us apply? :)
13:03:01	dadada	have zero experience with doing that, just wanted to ensure you're aware of it
13:03:19	*	jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:03:22	dadada	all I might be able to contribute are project ideas, ...,
13:04:07	dadada	may favorite idea is for a student to write wrappers for popular C++ libraries such as Qt5
13:04:32	dadada	even better would be for them to write tools for writing those wrappers quicker/easier/seamlessly
13:07:25	*	gangstacat quit (Quit: Ĝis!)
13:08:03	*	Vladar joined #nim
13:09:25	*	luis_ joined #nim
13:10:50	dadada	the students would learn about Nim as well as the APIs and uses of those popular libraries (which is good for them), and Nim would become more popular due to those hurdles of language switching (missing your favorite APIs/libs) becoming less relevant (win-win)
13:15:44	FromDiscord	<Recruit_main_70007> @mratsim hello, (just to clarify, i am Albus from gitter) i really want to start ML in Nim, and since nimtorch is a bit "slept", i want to use arraymancer, but i dont know how to slove the could not load blas.dll error
13:16:35	FromDiscord	<mratsim> which platform are you on?
13:16:41	FromDiscord	<Recruit_main_70007> windows
13:17:40	FromDiscord	<mratsim> You need to download openblas: https://www.openblas.net/
13:18:34	FromDiscord	<mratsim> put it somewhere, add that folder to your PATH
13:18:48	FromDiscord	<mratsim> i.e. developing on windows is a huge pain 😉
13:19:17	FromDiscord	<Recruit_main_70007> and can i get them into a folder that is aleady in path?
13:19:58	FromDiscord	<mratsim> yes
13:20:13	FromDiscord	<mratsim> if that helps this is my CI code, I use nuget to install OpenBLAS: https://github.com/mratsim/Arraymancer/blob/master/.appveyor.yml#L30-L43
13:20:58	FromDiscord	<Recruit_main_70007> and do i need any special flags when compiling?
13:21:00	dadada	dom96: so are you applying? I have found nothing on this top "Nim Gsoc 2020"
13:21:06	dadada	topic
13:21:26	dadada	it's understandable to me if you're not, since you keep being rejected
13:21:48	dadada	on the other hand many other projects I've followed were accepted, so it's definitely possible
13:22:04	FromDiscord	<mratsim> if it's not called blas.dll you need to pass -d:blas=yourBLasName
13:22:39	dadada	for example nuitka was accepted, and they had a student ensure that the top 20 projects on pypi work with nuitka or something to that extend
13:22:49	FromDiscord	<mratsim> ultimately I want to remove BLAS dependency but it's a lot of optimization work
13:23:46	FromDiscord	<Recruit_main_70007> thats good, do you think you could add this to the readme?
13:23:46	FromDiscord	<Recruit_main_70007> i found this difficult to do
13:24:25	dadada	another thing that might help is to extend the Nim organization, you could include promising Nim based projects like this one https://github.com/nimterop/nimterop in the Nim organization and make a project suggestion for it, for example the KDE organization spans dozens of different subprojects
13:25:03	FromDiscord	<mratsim> sure, you can also PR specific windows instruction there if you have time: https://github.com/mratsim/Arraymancer#installation
13:25:33	*	luis_ quit (Ping timeout: 246 seconds)
13:25:33	*	Pixeli quit (Read error: Connection reset by peer)
13:25:56	FromDiscord	<Recruit_main_70007> 👌
13:28:43	FromDiscord	<Recruit_main_70007> not working...
13:28:43	FromDiscord	<Recruit_main_70007> i have this in the path system variable,
13:28:43	FromDiscord	<Recruit_main_70007> "C:\Program Files\openblas\bin"
13:28:43	FromDiscord	<Recruit_main_70007> inside it, i have "blas.dll"
13:28:44	FromDiscord	<Recruit_main_70007> maybe i have to restart?
13:29:14	FromDiscord	<Recruit_main_70007> also PATHEXT has ".DLL"
13:30:31	dadada	dom96: a student could add Nim support to SWIG swig.org
13:32:51	FromDiscord	<Recruit_main_70007> dadada: nim is already compatible with any language that can import a C/C++ dll.
13:33:59	*	luis_ joined #nim
13:34:49	dadada	Recruit_main_70007: there's still a lot of boiler plate coding to do before it really can interface
13:35:51	dadada	when considering a new language I'm not really looking for a theoretical compatibility, I'm looking for the convenience of being able to use the tools I like with the least amount of effort necessary
13:36:44	dadada	so, since some people have already written boiler plate code for interfacing with other languages, one idea would be to piggyback on their code ... why write the same boilerplate twice/trice?
13:36:58	*	Hideki_ quit (Remote host closed the connection)
13:37:34	*	Hideki_ joined #nim
13:37:37	dadada	when I was writing "I'm" I really meant a general developer that looks for a new language
13:41:20	*	Hideki_ quit (Remote host closed the connection)
13:41:25	*	luis_ quit (Remote host closed the connection)
13:41:46	*	luis_ joined #nim
13:42:42	*	Hideki_ joined #nim
13:43:03	*	luis_ quit (Client Quit)
13:43:43	*	luis_ joined #nim
13:43:50	dadada	"SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages."
13:44:17	dadada	see, some C/C++ projects already have the boilerplate code for SWIG
13:44:45	dadada	and those can then be easily interfaced from high level langs such as D, Python, Ruby and so forth, which are supported by SWIG
13:46:31	dadada	now you could ask those projects to also create special interfacing code for Nim, which would mean in the logical conclusion that making this bridging/interfacing working/boilerplate work would've to be done for each higher language separately
13:46:46	dadada	which obviously sounds like a waste of human time!
13:47:31	FromDiscord	<Recruit_main_70007> how do i compile an iterator to a dll?, dynlib flag fails
13:47:32	dadada	OR someone writes the few thousand lines of code for Nim SWIG support ... I think it would be a nice GSoC project
13:47:58	*	dcmertens quit (Ping timeout: 260 seconds)
13:47:59	solitudesf	@Recruit_main_70007, you cant
13:48:41	*	luis_ quit (Quit: luis_)
13:48:50	FromDiscord	<Recruit_main_70007> so how would i do it, having a function and a for loop?
13:49:16	*	luis_ joined #nim
13:55:17	*	luis_ quit (Ping timeout: 260 seconds)
14:03:40	lqdev[m]	believe me or not but iterators do not have a runtime representation
14:03:51	lqdev[m]	they're sort of like templates
14:04:45	lqdev[m]	where each yield statement in the iterator is replaced with the body of the for loop
14:07:45	*	filcuc joined #nim
14:10:55	*	lritter joined #nim
14:17:52	*	silvernode quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
14:18:20	*	luis_ joined #nim
14:18:26	FromDiscord	<Rika> theyre inlined
14:20:44	dom96	closure iterators are different though
14:21:12	FromDiscord	<Recruit_main_70007> explain please
14:21:13	FromDiscord	<Rika> those have state
14:21:28	FromDiscord	<Rika> do you know python iterators?
14:21:42	FromDiscord	<Recruit_main_70007> for loops right?
14:21:49	FromDiscord	<Rika> no, python iterators
14:21:58	FromDiscord	<Rika> as in the iterator object
14:22:26	FromDiscord	<Recruit_main_70007> very little
14:36:10	*	Hideki_ quit (Remote host closed the connection)
14:36:48	*	Hideki_ joined #nim
14:39:26	*	filcuc quit (Ping timeout: 268 seconds)
14:42:57	*	Hideki_ quit (Ping timeout: 268 seconds)
14:45:45	*	luis_ quit (Remote host closed the connection)
14:53:56	*	filcuc joined #nim
14:57:07	*	narimiran joined #nim
14:59:34	*	Hideki_ joined #nim
15:04:49	FromDiscord	<mratsim> Python iterator just define a "next" function call, and Python iterators are just calling next() next() next() until next doesn't return anything
15:06:34	FromDiscord	<mratsim> I'm not sure the point @Rika wanted to make but the thing is, Nim iterators are a compile-time construct and cannot be called from C. It's just an abstraction so that "something" can be called as if it was a for loop
15:07:32	FromDiscord	<Recruit_main_70007> well, i found that the best solution is to get your for loop done inside a nim function and then calling it
15:08:28	FromDiscord	<mratsim> yes
15:09:56	Zevv	so, what is now the correlation between =destroy and new(..., finalizer). Do these end up to be the same thing?
15:12:26	FromDiscord	<Rika> @mratsim i meant that python iterators have state, which is pretty similar to closure iterators in nim
15:12:42	FromDiscord	<mratsim> @zevv yes
15:13:08	FromDiscord	<mratsim> there was a discussion about that yesterday or the day before
15:13:15	Zevv	ah I missed that, sorry
15:13:33	FromDiscord	<mratsim> it's here: https://forum.nim-lang.org/t/5825
15:13:43	Zevv	a little experiment indeed tells me the answer, if I do 'new' I can not create a =destroy for the same type
15:14:05	Zevv	so that makes sense. I do prefer the =destroy, as passing a type destructor to `new` feels wrong and funny
15:14:19	Zevv	thanks for the confirmation
15:15:54	FromDiscord	<mratsim> =destroy doesn't work for ref objects anyway
15:16:07	Zevv	it does with arc, right?
15:16:40	*	ng0_ joined #nim
15:16:51	Zevv	i now have one `=destroy` that works both with heap and stack
15:17:00	FromDiscord	<mratsim> AFAIk it's just that finalizers are triggered at the same time as destructors now
15:17:04	FromDiscord	<mratsim> ah
15:17:08	FromDiscord	<mratsim> well not sure
15:17:16	FromDiscord	<mratsim> @treeform @Araq: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01096.html
15:17:32	FromDiscord	<mratsim> ^ [C++ coroutines] Initial implementation pushed to master.
15:19:53	*	ng0 quit (Ping timeout: 265 seconds)
15:24:31	*	dadada quit (Ping timeout: 265 seconds)
15:26:51	*	Hideki_ quit (Remote host closed the connection)
15:27:35	*	Hideki_ joined #nim
15:32:28	*	Hideki_ quit (Ping timeout: 268 seconds)
15:33:47	FromGitter	<zacharycarter> anyone have any experience implementing parallel pathfinding? I've found some resources on the subject - https://software.intel.com/en-us/articles/the-secrets-of-parallel-pathfinding-on-modern-computer-hardware & https://link.springer.com/chapter/10.1007/978-3-642-25090-3_25 & https://github.com/acwilton/parallel-path-finding
15:34:02	FromGitter	<zacharycarter> but wondering if anyone here has implemented any of these before
15:34:06	FromGitter	<zacharycarter> or explored the topic
15:35:31	FromGitter	<zacharycarter> right now in my map generation process, a* is the bottleneck
15:37:25	*	pbb quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
15:38:52	*	pbb joined #nim
15:42:34	*	filcuc quit (Remote host closed the connection)
15:43:01	*	filcuc joined #nim
15:48:32	FromDiscord	<mratsim> never implemented but if it's just derivate from depth-first or breadth-first search it should be easy to parallelize with Weave
15:48:43	FromDiscord	<mratsim> is your code public?
15:49:12	FromDiscord	<mratsim> I can add it as a Weave benchmark if it's relatively self-contained
15:49:17	*	ng0_ is now known as ng0
15:49:55	Araq	Zevv, =destroy is bound to the object type and the finalizer to the 'ref' type
15:50:07	Araq	but ultimately it's the same thing
15:50:21	Araq	and we map destructors to finalizers for the old GCs
15:50:31	Araq	and we map finalizers to destructors for --gc:arc
15:50:39	Zevv	that makes sense, thanks
15:50:45	Zevv	mention all that in your talk :)
15:51:11	Araq	finalizers have the advantage that historic Nim versions already understand them
15:51:54	Araq	uh oh my talk
15:52:05	Araq	need to prepare it...
15:52:42	Zevv	nah, just improvise some stand up comedy for 30 minutes, you'll be just fine
15:53:04	FromDiscord	<mratsim> same thing ...
15:53:35	*	filcuc quit (Remote host closed the connection)
15:54:11	*	filcuc joined #nim
15:55:18	Araq	mratsim: the C++ ABI seems pointer heavy
15:55:26	*	Hideki_ joined #nim
15:56:05	Araq	which is bad when you want to serialize the state machine to disk because you want to give your users a "save any time" feature
15:56:21	Araq	but hey, what I do know about game development.
15:59:24	*	filcuc quit (Remote host closed the connection)
16:00:17	*	Hideki_ quit (Ping timeout: 265 seconds)
16:00:50	*	ng0 quit (Ping timeout: 268 seconds)
16:07:40	*	ng0 joined #nim
16:11:09	*	gangstacat joined #nim
16:11:24	*	gangstacat quit (Remote host closed the connection)
16:11:54	*	gangstacat joined #nim
16:20:06	*	dadada joined #nim
16:20:29	*	dadada is now known as Guest62063
16:22:10	*	Guest62063 left #nim (#nim)
16:32:50	disruptek	ok, who has a version of nim that reads /etc/nim.cfg or /etc/nim/nim.cfg?
16:33:57	federico3	I do
16:34:02	disruptek	i do not.
16:34:15	*	jjido joined #nim
16:34:16	FromGitter	<zetashift> (I do not)
16:34:32	disruptek	what platform?
16:35:20	FromGitter	<zetashift> On my linux box
16:35:41	FromGitter	<deech> The stable `nimble` gives me an error when I try to `search` or `list`: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e24855d5cd79646607a3bd0]
16:35:42	*	Trustable joined #nim
16:35:54	FromGitter	<deech> I did a `nimble update` first.
16:36:06	FromGitter	<zetashift> huh I get the same error
16:36:39	FromGitter	<deech> idk if it's the cause but I don't have a file called `packages.json`, but I do see a `packages_official.json`.
16:37:20	disruptek	i think you might be entitled to a prize if you have the official copy.
16:38:45	FromGitter	<deech> I removed it and updated, poof it's back.
16:39:00	disruptek	someone really wants you to have that file.
16:41:24	*	Hideki_ joined #nim
16:42:47	FromGitter	<deech> Ok moving on, has anyone run into issues with compilation time when using the C++ backend on larger projects?
16:43:59	disruptek	no, but i use ccache pretty extensively.
16:47:55	*	nsf quit (Quit: WeeChat 2.7)
16:49:51	disruptek	i built rust on my palmtop (4 threads). it took >2½hrs. building nim with one thread took <8½mins.
16:50:54	disruptek	takes my workstation 25s, for comparison.
16:58:35	FromDiscord	<+[+-]> Hey there, new to nim and I've been working on a text based adventure game thing to try and get myself more acquainted with the language and I've been trying to figure out how I'd be able to actually print out individual characters at an interval of one second as an example. I know I can run stdout.write <character> but after looking at the manual, the tutorials, and even checking the forums I haven't found a way where that'd be feasible. I k
17:01:23	solitudesf	https://nim-lang.github.io/Nim/os.html#sleep%2Cint
17:01:38	FromDiscord	<+[+-]> You're a hero
17:01:40	solitudesf	https://nim-lang.github.io/Nim/theindex.html use this to search stdlib
17:04:27	*	Hideki_ quit (Ping timeout: 272 seconds)
17:11:10	*	oz quit (Ping timeout: 252 seconds)
17:12:03	FromDiscord	<treeform> @mratsim the C++ coroutines seem to be more like async/await rather then what coroutines usually are...
17:13:20	FromDiscord	<treeform> Fibers on Win32 are pretty interesting: https://nullprogram.com/blog/2019/03/28/ Never knew about them or how they worked.
17:13:40	*	oz joined #nim
17:13:42	*	ptdel joined #nim
17:19:08	FromDiscord	<treeform> Some thing I read and can't find anymore. I would like to test this: The system that use thousands of "green" threads to do IO can do IO fast in benchmarks. But as soon as they need to do any real work they blow up the CPU cache causing a ton of missed caches and make everything way slower... which approaches the legacy using real threads performance.
17:20:25	FromDiscord	<treeform> I would like to test the hypotheses, that doing work and not just pure IO... will make async/coroutines/fibers ... run at about the same speed as threaded code with locks.
17:20:46	disruptek	i think that's only true if all your fiber does is yield.
17:20:54	FromDiscord	<treeform> It might be a ton of extra complexity for not a huge gain....
17:21:02	disruptek	i've never had a problem with fibers being inefficient on the cpu.
17:22:02	disruptek	they are cheaper to switch. that's the whole point.
17:22:37	FromDiscord	<treeform> If you want to read a file... well there is no kernel async API. So that's threads. You want to do DNS? will that's threads too... So many things in OS require blocking ... that threads escape is required from "async/coroutines/fibers" world.
17:23:47	FromDiscord	<treeform> "never had a problem with fibers" but what % of fibers efficacy do you gain in your app?
17:24:15	disruptek	you mean, what overhead do i have?
17:24:30	FromDiscord	<treeform> yes I am interested in real world benchmarks
17:24:44	FromDiscord	<treeform> is fibers vs threads a 2% gain? 50% gain? 99% gain?
17:24:56	disruptek	oh, i don't know. i don't care. the win for me is in structure, design, architecture, readability, etc.
17:25:14	disruptek	never noticed any performance difference.
17:25:21	FromDiscord	<treeform> well I am saying that maybe threads are simpler and way better supported at OS level.
17:25:32	disruptek	sure, but fibers have their place. they do work.
17:25:38	disruptek	they can be faster than threads.
17:26:05	disruptek	you're second-guessing greenlet for some reason.
17:26:07	disruptek	what's up?
17:26:15	FromDiscord	<treeform> not if you do a ton of DNS stuff... DNS lookups block your whole async program.
17:27:25	disruptek	why?
17:29:14	FromDiscord	<treeform> https://github.com/nim-lang/Nim/issues/7422#issuecomment-573602101
17:29:16	disbot	➥ Async networking and blocking host name resolving / DNS
17:29:18	FromDiscord	<treeform> because it requires OS stuff.
17:30:25	FromDiscord	<treeform> Basically the OS it build for threads. Doing Async with the OS needs some sort of synchronization ...
17:30:33	FromDiscord	<treeform> While threads don't.
17:30:53	disruptek	so sumb.
17:30:56	disruptek	dumb, too.
17:31:34	*	JustASlacker joined #nim
17:31:58	disruptek	i don't know if i have another resolver in me.
17:32:16	FromDiscord	<treeform> I am feel more ignorant about the subject of asycn/threads the more I read about them...
17:32:20	disruptek	i wrote dns servers in perl and python.
17:32:40	FromDiscord	<treeform> I want to benchmark and test hypotheses... cause I think there are myths here.
17:32:42	FromDiscord	<DeltaPHC> Generally speaking, the wisdom I've heard is that threads and fibers/coroutines/async-await are two different tools that are best at different things
17:33:04	FromDiscord	<treeform> I want to test this "wisdom"
17:33:14	Zevv	sure, but you dont have the choice always
17:33:33	Zevv	what if you want to use two libs, one threaded and one async?
17:33:46	Zevv	you cant await on both at the same time
17:33:59	disruptek	better example is that you need to integrate with existing architecture.
17:34:47	dom96	treeform: benchmarking is challenging, there are so many use cases that any synthetic benchmark has no hope of capturing
17:35:18	FromDiscord	<DeltaPHC> Parallelism vs. concurrency. They aren't mutually exclusive. For example, Go multiplexes coroutines on multiple threads. Each thread might have more than one "goroutine" on it. It all depends on how the scheduling is implemented
17:35:39	FromDiscord	<treeform> dom96, yeah that's probably the main thing I worry about. Its like "unknowable" problem.
17:36:15	disruptek	i don't believe that.
17:36:24	disruptek	i believe the problem is as real as you think it is.
17:36:45	disruptek	net-net, you have an issue you need to solve. it doesn't matter what the benchmarks say.
17:38:05	*	JustASlacker quit (Ping timeout: 268 seconds)
17:38:12	FromGitter	<Varriount> Who is net-net?
17:38:34	disruptek	i mean, when all is said and done.
17:39:05	disruptek	the app is the benchmark. it's too slow.
17:49:25	*	dddddd quit (Ping timeout: 272 seconds)
17:50:39	*	JustASlacker joined #nim
17:51:06	FromDiscord	<treeform> I guess the route I am taking now -- for highest performance. Don't use threads or async... using a UDP packet based thingy...
17:51:45	disruptek	you mean, writing your own resolver.
17:53:13	dom96	speaking of performance, just optimised my game's particle draws to reduce the frame time from 27ms to 1.7ms
17:53:29	FromDiscord	<treeform> nice! That's a huge win.
17:53:46	FromDiscord	<treeform> I was doing particles in my game the other day.
17:54:23	dom96	Thanks :) There are definitely plenty of other things that I can do, these optimisations were fairly simple and only needed to be done because I wanted to get particles on the screen ASAP
17:54:54	FromDiscord	<treeform> this is with SDL?
17:54:58	dom96	yep
17:57:50	FromDiscord	<treeform> I struggled with pausing the game and pausing the particles as well. And making sure the particles frame rate sync with the variable simulation rate. But I think I solved it.
17:58:02	FromDiscord	<Recruit_main_70007> guys, we are having a RLBot tournament, its the first appearance of a Nim bot and the second time of a Boolang, (both mine although they suck), it is very cool, we are starting in 3 minutes.
17:58:02	FromDiscord	<Recruit_main_70007>
17:58:03	FromDiscord	<Recruit_main_70007> https://www.twitch.tv/RLBotOfficial
17:58:37	dom96	treeform: oh? Why did you struggle with that?
17:59:00	FromDiscord	<treeform> I don't know... bad previous code?
17:59:58	dom96	Isn't it just a case of not calling your `update` procedure?
18:02:24	*	dddddd joined #nim
18:02:55	*	dadada joined #nim
18:02:56	dadada	hi
18:03:17	dadada	what language do yo think is most similar to Nim?
18:03:27	FromDiscord	<treeform> Nimrod? 🙂
18:03:27	dom96	Recruit_main_70007: what's the name of the NIm bot?
18:03:43	FromDiscord	<Recruit_main_70007> NimBot
18:03:57	dadada	taking into account less of the syntax and more of the feature side
18:04:13	dom96	hah, of course :)
18:04:43	dom96	this seems fun
18:05:02	dadada	s/do yo/do you
18:05:18	FromDiscord	<Recruit_main_70007> this ones are not precisely the best ones, but there are some nutty ones
18:05:53	*	dom96 wonders what demos are
18:05:59	dom96	never played rocket league :D
18:06:14	FromDiscord	<treeform> I think its short for demolition, or kill the other car.
18:06:23	FromDiscord	<Recruit_main_70007> ^
18:06:48	FromDiscord	<treeform> It looks like the faster car wins during collisions if its going fast enough.... not sure how that works
18:07:31	*	JustASlacker quit (Ping timeout: 258 seconds)
18:09:08	FromDiscord	<DeltaPHC> dadada: If we're talking only features, it's actually hard to say whether any one language has most of everything Nim does. Nim itself borrows a lot from other languages
18:09:20	FromDiscord	<treeform> maybe a proper angle is also required
18:10:26	FromDiscord	<DeltaPHC> I'm not sure if I've seen another language besides <insert Lisp variant here> that quite has the macro and meta-programming features of Nim
18:11:28	shashlick	Thanks @mratsim for the fix
18:12:16	FromDiscord	<treeform> if you can't have lisp macros, maybe forth macros? Rebol? Red?
18:14:00	dadada	DeltaPHC: I'm asking for closeness, sameness (this word should exist, even if it doesn't, agree?) of features :D
18:14:38	FromDiscord	<DeltaPHC> But then Nim's type system takes in features from other languages. Sum types (object variants) from functional languages, generics/constant generics similar to C++, but it also has some limited form of typeclasses, and there's also concepts which is coming to C++ though it's rather experimental
18:15:09	Araq	if you want Nim, you know where to find it
18:15:19	FromDiscord	<treeform> The indentation makes it look like python...
18:15:19	Araq	I don't understand the point of the question
18:15:44	dadada	Araq: I agree with you
18:16:25	FromDiscord	<treeform> If you want python with types you can go Pyrex, Cython, Boo...
18:16:27	dadada	I was just considering how much work it would be to write a Nim module for swig, swig docs suggests starting with the module for a language that has similar features / is similar
18:16:40	Araq	aha
18:16:44	dadada	copy paste and then modify
18:16:52	Araq	swig used to support Modula 3 iirc
18:16:58	Araq	use that as the foundation ;-)
18:17:00	FromDiscord	<treeform> that's a a lot more contained.
18:17:09	FromDiscord	<treeform> constrained*
18:17:15	dadada	they do support Go :D
18:17:26	FromDiscord	<treeform> Hmm, I never used a swig wrapper I liked.
18:17:34	FromDiscord	<DeltaPHC> Nearly every popular language is sort of a descendant from Algol :^)
18:17:47	Araq	treeform: I wrote c2nim after having studied Swig
18:18:23	dadada	after swiftly looking over some swig code I see why
18:18:37	Araq	Swig uses a bastard version of C++ with dynamic typing
18:18:57	Araq	and it has its own non-standard C++ parser (like c2nim)
18:20:40	Araq	dadada, IMO the way forward is to use clang's parser inside c2nim
18:20:51	Araq	that's of course easier said than done
18:21:00	dadada	everything is
18:21:09	disruptek	Araq: you're might be the first person i've ever met who's guilty of bikeshedding an unimplementation.
18:21:27	FromDiscord	<treeform> which language has the largest library of high quality software? Python2nim, Java2nim, JavaScript2nim?
18:21:38	Araq	disruptek, that sounds good. does it also mean anything?
18:21:58	FromDiscord	<treeform> its surly not php2nim...
18:22:12	disruptek	telling zevv how to not-implement...
18:22:27	dadada	treeform: oh my, I just want Qt5 for Nim :D
18:22:38	federico3	certainly not javascript either
18:22:45	FromDiscord	<treeform> Why Qt5?
18:22:58	FromDiscord	<DeltaPHC> It's a popular GUI framework
18:23:11	disruptek	i really like qt.
18:23:17	disruptek	i dunno who people hate it so much.
18:23:18	dadada	treeform: because I found Qt a breeze to program in each time, I used to use Qt2, too
18:23:30	disruptek	s/who/why/
18:23:37	FromDiscord	<DeltaPHC> Main downside of Qt is that it's rather heavyweight
18:23:45	*	nsf joined #nim
18:23:46	FromDiscord	<DeltaPHC> But it's also very complete
18:23:47	disruptek	even though i prefer gtk apps to run, i prefer writing qt apps.
18:23:49	FromDiscord	<DeltaPHC> and comprehensive
18:23:57	disruptek	and consistent.
18:24:09	Araq	dadada, krux02 started to wrap Qt via their doc generator
18:24:21	FromDiscord	<treeform> What is the most popular Qt powered app? I don't think I have used any.
18:24:24	dadada	disruptek: it's more than a gui framework, it has tools for a lot of different tasks, you can build a httpserver, or manipulate images, it's really a giant library
18:24:34	disruptek	yes, i know.
18:24:38	Araq	not sure if he uploaded the code though
18:24:46	disruptek	i've written c++ qt and also pyqt apps.
18:24:58	Araq	anyhow, it's an idea worth exploring, instead of producing HTML, produce a Nim wrapper out of it
18:25:05	disruptek	clever.
18:25:14	dadada	who hates it? I've used gtk, too, like them both, does that make me odd?
18:25:45	FromDiscord	<DeltaPHC> That can also be seen as a "downside" of Qt. That it's basically an entire ecosystem that you have to immerse yourself into. Use its non-standard C++ extensions to make things easier. That sort of thing
18:25:47	disruptek	no; araq doesn't like symlinks.
18:25:51	disruptek	that's "odd".
18:26:40	Araq	nothing odd about it, I like trees much better than more general graphs
18:26:53	Araq	it's odd that you bring it up in a discussion about Qt though
18:26:57	dadada	Araq: while a clever trick that I used once too, making a specific tool for porting each lib is exactly the wrong approach
18:27:03	disruptek	sometimes a library is just a means to an end. it's not a fashion statement and it's not a political treatise and it's not a bomber's manifesto.
18:27:06	dadada	it's still very cool, and if it works I appreciate it!
18:27:29	*	JustASlacker joined #nim
18:27:46	Araq	dadada, ikr, hence I wrote c2nim
18:27:51	FromDiscord	<mratsim> Nim concepts predates C++ @DeltaPHC
18:28:08	FromDiscord	<DeltaPHC> Does it?
18:28:11	Araq	mratsim: not really
18:28:12	rayman22201	We also got nimterop based on tree-sitter as an attempt to modernize wrappers.
18:28:33	dadada	that one looks promising :D it would be best if there were multiple such tools
18:28:38	Araq	there have been C++ concept concepts and Nim's concepts were heavily inspired by them
18:28:51	dadada	that way if one fails you can try the next one until one works
18:29:14	Araq	I massage the input code until it works with c2nim instead.
18:29:21	rayman22201	We already have 2 and a half, c2nim, nimgen, nimterop
18:29:31	rayman22201	How many do we need lol?
18:29:59	disruptek	no more than it takes.
18:30:05	Araq	one more, one that can wrap Qt
18:30:06	dadada	my point is that you can't have too many, but you can have too few
18:30:30	disruptek	wicked insight right there.
18:30:47	FromDiscord	<DeltaPHC> C++ concepts were proposed for previous standards from previous years, just that it wasn't until C++20 that it was finally accepted
18:30:55	Araq	yup.
18:31:13	Araq	and then they got it wrong in C++20 still IMHO.
18:31:30	Araq	and so did Nim, see my RFC about it
18:31:42	disruptek	!rfc concepts
18:31:44	disbot	https://github.com/nim-lang/RFCs/issues/168 -- 3Concepts and type-checking generics 7& 19 more...
18:31:54	FromDiscord	<DeltaPHC> To be fair, it's a rather complex idea and type system feature
18:31:57	Araq	yes, that one
18:32:26	FromDiscord	<mratsim> btw @Araq, do you know if this is an easy fix or not? https://github.com/nim-lang/Nim/issues/11142
18:32:26	FromDiscord	<mratsim>
18:32:26	FromDiscord	<mratsim> The crypto world is being taken by storms by zero-knowledge proofs and elliptic curve crypto and to experiment/implement them properly you need a modular bigint library.
18:32:26	FromDiscord	<mratsim> #11142 would really help into having a nice interface by storing all crypto constants in an object.
18:32:28	disbot	➥ Type mismatch on init of static[T] object with T being a static[U] ; snippet at 12https://play.nim-lang.org/#ix=27Qf
18:32:29	disbot	https://github.com/nim-lang/Nim/issues/11142 -- 3Type mismatch on init of static[T] object with T being a static[U] ; snippet at 12https://play.nim-lang.org/#ix=27Qf
18:33:34	Araq	mratsim: I gave it a try and despaired
18:33:42	FromDiscord	<mratsim> ah shoot
18:33:59	FromDiscord	<mratsim> I'll try another way then
18:33:59	Araq	maybe there is a variation
18:34:09	Araq	that also doesn't work yet but is easier to fix
18:34:41	FromDiscord	<mratsim> I would say the alternative would be to have a "static pointer"
18:34:43	Araq	in theory it's not too hard, in practice it makes me wanna rewrite one or two subsystems inside the compiler...
18:35:03	dadada	Nim seems to have most of the features of go... it should be easy to interface with go code?
18:35:13	dadada	there's a way to interface with go code from c
18:35:26	FromDiscord	<mratsim> it even has go GC
18:35:54	FromDiscord	<mratsim> but yes compile nim as a dll, call from Go
18:35:58	Araq	dadada, Go doesn't interface well with other natively compiled languages because of its growable stacks. IMHO
18:36:50	FromGitter	<zetashift> cgo it's called right? I read that it isn't a smooth interop
18:37:29	dadada	well, since there are a bunch of great go libs calling go code from within Nim seems the most useful to :D
18:37:32	rayman22201	Araq: I would love to get your thoughts on our async leak if you have a chance. Have you seen my latest minimal repro?
18:38:05	dadada	zetashift: https://medium.com/@ben.mcclelland/an-adventure-into-cgo-calling-go-code-with-c-b20aa6637e75
18:39:34	disruptek	rayman22201: i'm not even sure the hand-written version is safe anymore.
18:39:50	*	dcmertens joined #nim
18:40:08	rayman22201	What do you mean?
18:40:37	dadada	this year qt6 might get released with some c++17 rewrites, one can only hope they're working on getting rid of their metacompiler, would make interop easier
18:42:32	rayman22201	Or I should say. I trust the hand written one because I have a pretty deep understanding of the macro and I know how to translate back and forth. It's one of my main Nim area of expertise.
18:43:24	shashlick	Nice link
18:43:45	disruptek	i don't think it's wise to pass a cursor on the future to the callback.
18:44:28	Araq	rayman22201, I'm listening and have a couple of hours time
18:44:34	rayman22201	https://play.nim-lang.org/#ix=27Hd
18:44:39	rayman22201	the following example leaks
18:44:43	rayman22201	and I don't know why
18:44:53	shashlick	I'm not too attached to the wrapper gen portion of nimterop
18:44:55	rayman22201	and I'm not even setting the callback on the future
18:45:08	shashlick	Nimgen is dead and nimterop can use c2nim
18:45:49	shashlick	Tomorrow if we get more tools that can wrap, they will be supported by nimterop
18:46:30	rayman22201	what is telling to me, getOccupiedMem, shows no leak, but valgrind shows a leak.
18:46:39	rayman22201	I trust valgrind more than getOccupiedMem
18:47:03	Araq	getOccupiedMem is not working with -d:useMalloc
18:47:13	shashlick	I am reimplementing the toast backend to use the nim ast and renderer but it is a long road even for parity with what toast can do today
18:47:56	*	Kaivo quit (Quit: WeeChat 2.7)
18:47:56	shashlick	And too many fun projects distracting me but nothing new there for anyone
18:48:15	dadada	Araq: just my 2 cents, I believe it's not preferable spending your time recreating another C/C++ parser when multiple other more generalized projects (swig, clang, probably many more, ...) have done so, clang of course is perfect in that it will always follow the C++ standards closely, but on the other hand the swig project has a close to 25 year history with new languages keep being added and new releases
18:48:18	disruptek	well, we know it's a future. there are only so many code paths.
18:48:21	dadada	each year, so discounting it is a mistake in my opinion
18:49:06	disruptek	shashlick: long road, but a much better result.
18:49:08	shashlick	dadada: I'm still not convinced by clang since it is such a big dependency
18:49:20	dadada	Araq: but still, skimming over the swig code I completely understand that no one wants to put in the work, it's massive headache to be sure
18:50:00	shashlick	Arguably you could create generic wrappers which also include all preprocessor translations into Nim compile time code
18:50:23	shashlick	But I'd try if we had infinite time
18:50:28	dadada	shashlick: QtCreator is also using clang as a runtime dependency, but with developers today regularly using 16 GB RAM and a 1TB SSD for 100 bucks there's really no point in saving in the wrong place
18:50:42	shashlick	I know gogolxdong is trying that
18:51:05	dadada	shashlick: if the final user of the code (user of app/service) doesn't suffer by a dependency it shouldn't matter too much
18:51:09	rayman22201	Disruptek / Araq I'm convinced the leak is related to cursors and closure iterators and not futures
18:51:09	Araq	dadada, sure but c2nim already exists now and back then it was the best option around
18:51:25	shashlick	I know tree-sitter gets no love but it is quite good at what is does
18:51:41	disruptek	hmm, i will look again, but i think i got it down to just 56 bytes. i got it pretty tight.
18:52:06	rayman22201	It's not the size that matters but the reason why
18:52:11	dadada	Araq: not trying to pick on you! Indeed I'm star struck, good work! Nim is one of my favorite languages to keep track of.
18:52:43	shashlick	Araq - by the way, I'm using $nim to build the compiler portions into nimterop now so we should do the same for c2nim as well instead of copying source over
18:53:03	shashlick	It works well all the way back to 0.20.2
18:53:06	dadada	shashlick: tree-sitter looks very interesting, too
18:53:21	rayman22201	Disruptek Notice, Your version returns the future and my version returns nil, but still leaks.
18:53:25	shashlick	dadada I like how portable it is
18:53:59	shashlick	Nimterop worked seamlessly with musl as well
18:54:10	shashlick	So in theory, it can work for any target
18:54:13	disruptek	yes, but the sum doesn't matter.
18:54:17	*	JustASlacker quit (Ping timeout: 265 seconds)
18:54:19	FromGitter	<zacharycarter> mratsim: I'll work on a weave example for the pathfinding tomorrow. Got hung up this evening with stuff
18:54:21	disruptek	we have to return the future or async is not useful.
18:55:01	rayman22201	It's also not useful if it leaks, and I'm trying to narrow down code paths
18:55:21	disruptek	okay, but you fundamentally change the way arc works when you return nil.
18:55:35	rayman22201	No. That's straight from the macro
18:55:36	disruptek	so it's fundamentally changing your ability to debug.
18:55:50	rayman22201	It returns nil if the future completes immediately
18:56:03	disruptek	okay, sure.
18:56:03	Araq	rayman22201, so which object does it leak?
18:56:05	rayman22201	Look at the original macro output
18:56:16	disruptek	i have to switch my compiler around.
18:56:36	rayman22201	I didn't arbitrarily do that
18:56:37	dadada	GSoC deadline is on Feb 5 , would be a great boost for the project
18:56:48	disruptek	i also modified async some, so i guess it's possible we're looking at different inputs.
18:57:03	rayman22201	Araq: good question
18:57:20	rayman22201	I believe it's still the future. 72 bytes
18:57:51	rayman22201	Somehow it's not acting like a cursor?
18:58:15	Araq	on the contrary, when it is a cursor, its destructor isn't called and then it leaks
18:58:24	disruptek	this.
18:58:30	Araq	so it's "acting like a cursor too much"
18:58:42	disruptek	but the other possibility is that the closure cannot supply a cursor.
18:58:52	disruptek	one of those two things.
18:58:55	rayman22201	Maybe this
18:58:57	rayman22201	Yeah
18:59:29	disruptek	i think gcc is inifinite-looping on passaux.nim
18:59:40	disruptek	i don't even...
19:00:20	rayman22201	My next step is to analyze the generated c again more closely, but I wanted some insight first.
19:02:40	Araq	rayman22201, I'm not sure we support .cursor for closures
19:02:59	rayman22201	That might be the problem?
19:03:01	disruptek	well, that explains that.
19:03:16	Araq	never mind, it is supported
19:03:25	disruptek	also, dom96 looked at this and came to the same conclusion.
19:03:35	disruptek	is there a test?
19:04:28	dom96	the example I saw which didn't leak had the closure iterator removed
19:04:56	disruptek	hmm, i'm getting no leaks right now. maybe my test is broken.
19:04:57	rayman22201	The closure iterator is definitely the source of the leak
19:05:27	dom96	here is what I tried: https://gist.github.com/dom96/bd14faf86a426d9365a95ff49e74e74a
19:06:07	rayman22201	That still leaks iirc
19:06:21	dom96	yes
19:06:33	rayman22201	Basically the same thing I did to start
19:06:45	rayman22201	Then I narrowed it down to the closure iterator
19:07:41	disruptek	ah, it's malloc.
19:07:49	disruptek	it leaks with useMalloc but not our alloc.
19:08:02	rayman22201	Fascinating!
19:08:08	disruptek	yeah, that explains a lot.
19:08:27	disruptek	🤯
19:09:05	disruptek	okay, i'm on head now.
19:09:42	FromDiscord	<Clyybber> Araq > in theory it's not too hard, in practice it makes me wanna rewrite one or two subsystems inside the compiler...
19:09:42	FromDiscord	<Clyybber> I mean, thats a good thing? After the work is done I mean :p
19:09:52	Araq	rayman22201, it leaks for me
19:09:59	Araq	too without -d:useMalloc
19:10:07	Araq	use -d:useMalloc + valgrind
19:10:07	rayman22201	Damn
19:10:21	Araq	or use no malloc and getOccupiedMem()
19:10:39	disruptek	which test is this?
19:10:43	Araq	so the good news is: I can reproduce
19:10:50	rayman22201	Yay
19:10:55	Araq	and I'm using a different OS and a different allocator
19:11:08	Araq	disruptek, https://play.nim-lang.org/#ix=27Hd
19:11:09	disruptek	so what's different...
19:11:12	Zevv	disruptek: what is your testcase?
19:11:21	disruptek	i will publish.
19:11:23	Zevv	let me see if it is related to the stuff I touched over the last days
19:11:47	disruptek	http://ix.io/27Qt
19:11:59	Araq	Clyybber: sure but I have "compiler rewrites" scheduled for 2021
19:12:06	disruptek	this is what i use to diff the cfgs and the c output
19:12:28	disruptek	http://ix.io/27Qu/nim -- my current test.nim
19:14:48	Zevv	I think the malloc test is fair, the nim alloc test not
19:14:58	Zevv	nim allocs a huge block and just frees that on the end, or is that not so?
19:15:13	disruptek	pretty sure we critically must work correctly with malloc.
19:15:48	disruptek	but of course we can still draw some conclusions.
19:15:49	Zevv	var fut = asyncProc()
19:15:55	Zevv	is the line leaking according to valgrind
19:15:57	Zevv	but you kew that
19:17:06	disruptek	well, we lift loop vars. this might not be wrong.
19:17:48	disruptek	no, it's wrong.
19:17:56	rayman22201	🤣
19:18:45	Zevv	disruptek: does it make sense to minimise the test case first
19:18:54	Zevv	inspecting the C is no fun like this
19:19:12	disruptek	you're not enjoying yourself?
19:19:25	disruptek	i get a real flow going.
19:19:30	Zevv	I've been looking through generated C code quite a bit recently
19:19:37	Zevv	and I so friggin' *hate* it
19:19:55	rayman22201	Disruptek is a masochist
19:20:06	disruptek	okay, so we have the full async and we have the hand-written async.
19:20:15	disruptek	you want a sync version now?
19:20:22	Zevv	free(((void*) ((NI)((NU64)(((NI) (ptrdiff_t) (p))) - (NU64)(((NI) 8))))));
19:20:31	Zevv	stuff like that is so much fun
19:21:02	disruptek	that's the bit i thought we were seeing in your nimmin branch.
19:21:06	disruptek	minnim
19:21:10	disruptek	whatever it is.
19:21:34	disruptek	how do you propose to reduce it?
19:21:49	rayman22201	"Hand Written" implies it's arbitrary. It was a carefully crafted minimal sample that very closely adheres to the same rules the macro follows.
19:22:08	disruptek	i know.
19:22:35	disruptek	so again, how do you propose to reduce it?
19:23:01	rayman22201	I already did?
19:23:06	Araq	so do you want me to understand it or not
19:23:24	Zevv	disruptek: sorry, it was 80% out-whenned code, I didn't notice that yet
19:23:40	Araq	if so, be quiet
19:23:48	Zevv	yessir
19:25:58	dom96	just tried to compile my game with --gc:arc and received a type mismatch on `repr` taking a uint8 of all places
19:27:18	dom96	do we have a different implementation of repr for --gc:arc?
19:27:55	Zevv	no repr with arc, afaik
19:28:14	dadada	what is the best way to promote Nim? I think writing apps. This is really why I brought up Qt5... also another great idea is to target webassembly!
19:28:16	disruptek	is or will be replaced with $
19:28:19	*	JustASlacker joined #nim
19:28:38	Araq	dom96, indeed we do
19:28:46	dom96	why wouldn't we have repr with arc?
19:28:46	Araq	I wrote a new repr for --gc:arc, was the easiest solution
19:28:54	*	jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:29:00	dom96	anyway, after fixing that: https://gist.github.com/dom96/e1d4dbe78e29450b55af59a9cf6d46ec
19:29:03	Araq	because we don't have useful RTTI
19:29:06	dom96	It doesn't even manage to load my config json
19:29:21	Araq	strange
19:29:32	Araq	I personally ensure all the json tests are green
19:29:37	Araq	with --gc:arc
19:29:39	Araq	*ensured
19:29:51	dom96	maybe there is a corruption somewhere
19:29:52	disruptek	openapi runs with json at compile-time in arc.
19:30:25	disruptek	and thus, runtime.
19:32:32	dadada	Araq: did you choose echo to make echo "hello" look similar to shell code, in that case why not drop the echo &"hello {var}" syntax for echo "hello ${var}" , this would make the lang an even better shell code replacement, you could use something like $$ when the dev means a literal $
19:32:47	disruptek	actually, nevermind. the tests are purely runtime for openapi.
19:33:00	dadada	sorry for weird wording of my question, hope you get what I mean
19:34:08	dadada	i.e. echo "hello $${var}" prints "hello ${var}" and echo "hello ${var}" prints "hello 22" (if var == 22)
19:34:23	FromDiscord	<Clyybber> Zevv; nice!
19:34:35	FromDiscord	<Clyybber> (making seqs/strings smaller)
19:34:38	Zevv	Clyybber: ?
19:34:42	Zevv	oh yeah right
19:34:58	Zevv	thanks.
19:35:37	Araq	rayman22201
19:35:44	Araq	var closureIter_window: typeof(asyncClosureIter) # leak gone
19:35:54	Araq	you cannot make this a .cursor, it causes the leak
19:36:05	Araq	and in retrospect it's obvious why
19:37:02	Araq	case closed, I'm allowed to watch Columbo now.
19:37:07	rayman22201	Lol
19:37:33	rayman22201	The closure environment leaks in this case
19:37:43	rayman22201	Hrmm
19:37:46	Araq	except that we only have one TV and my wife is watching some other crap
19:38:10	rayman22201	Lol. Wife always wins 😛
19:38:31	disruptek	i cannot repro that.
19:39:06	rayman22201	The wife or the cursor? Lol
19:40:19	disruptek	i cannot reproduce leak-free async on -d:useMalloc.
19:42:00	disruptek	nameIterVal doesn't need a cursor but who cares. i'm still leaking.
19:42:19	*	nsf quit (Quit: WeeChat 2.7)
19:43:09	rayman22201	Yeah... Even if it worked, it puts me back to square 0. Adding the second closure back in still leaks
19:43:33	Araq	for me without the .cursor the leak is gone
19:43:49	Araq	so now you need to give me a bigger example program that leaks
19:44:32	rayman22201	yeah. confirmed, removing the cursor doesn't leak for me. Building the larger example now. stand by
19:44:45	dom96	can you guys post your full code?
19:45:08	rayman22201	actually, it's just the original: https://play.nim-lang.org/#ix=27H5
19:45:11	dom96	It's incredibly confusing to see you say "it doesn't leak for me" without specifying exactly what code you're using
19:45:18	shashlick	We need some docs on using valgrind with Nim
19:45:32	*	zielmicha__ is now known as zielmicha
19:45:42	shashlick	And more formal tutorial using gdb as well
19:45:52	*	zielmicha is now known as zielmicha__
19:46:02	*	JustASlacker quit (Ping timeout: 258 seconds)
19:46:04	shashlick	When things get hard in Nim, you end up in the deep end with almost no help
19:46:04	rayman22201	we are posting the code Dom. We aren't going to post it with every comment
19:46:10	dom96	rayman22201, and that leaks?
19:46:42	shashlick	And it is sometimes hard to minimize code samples to ask people to help
19:47:22	disruptek	well, i cannot reproduce this success.
19:47:40	rayman22201	that's strange. My valgrind shows no leaks when I take out the cursor
19:47:52	rayman22201	@dom96 @disruptek: here is the recap: https://play.nim-lang.org/#ix=27QF
19:48:49	dom96	okay, and when you apply this to the full code generated by the async macro does it still leak?
19:48:49	rayman22201	which brings us back to the full macro output + cursor annotations here: https://play.nim-lang.org/#ix=27H5
19:49:02	rayman22201	similar to what you did originally Dom
19:49:13	rayman22201	we came to similar conclusions independently I think
19:49:40	FromDiscord	<Clyybber> shashlick: For gdb theres a video tutorial by krux
19:49:49	rayman22201	which means, the leak is somewhere else. idk where
19:49:49	FromDiscord	<Clyybber> and for valgrind its just -d:useMalloc
19:50:08	FromDiscord	<Clyybber> ~valgrind is use -d:useMalloc
19:50:08	disbot	valgrind: 11use -d:useMalloc
19:51:17	shashlick	Yes but all these tutorials are spread out, we need a page on in our manual collating it
19:51:28	shashlick	Debugging or something
19:52:15	rayman22201	@dom96, @araq, @disruptek, here is a slight modification sot the iterator also uses the cursor Future: https://play.nim-lang.org/#ix=27QG
19:52:48	rayman22201	Here is the valgrind output from this https://www.irccloud.com/pastebin/DWzaoLTp/
19:53:18	rayman22201	The interesting part to me is this line: asyncProc__rLFS7Q9b7yfzqBp3gcbvCKw (@mbasicAsync.nim.c:816)
19:53:41	rayman22201	that is the closure environment for the second closure (If I understand the C correctly.)
19:54:09	rayman22201	specifically the closure environement for `asyncProcNimAsyncContinue_400016`
19:57:20	disruptek	you're not including the closure cursor in the iterator.
19:57:50	disruptek	only the future cursor matters.
19:58:11	rayman22201	that's not what valgrind says
19:58:56	disruptek	i'm looking at the playground paste.
19:59:03	rayman22201	I don't understand what you mean "include the closure cursor in the iterator"?
19:59:14	rayman22201	you should probably look at things before you make comments, as a general rule
19:59:40	disruptek	that's why i'm commenting.
20:00:24	rayman22201	If anything, I expect the closure to not live long enough, since the callback gets a cursor to the closure.
20:01:12	disruptek	you're right, i wasn't looking at the right link.
20:01:18	rayman22201	the only strong ref to the closure is the proc itself, which should free the closure on return, but it is apparently not doing that?
20:03:17	rayman22201	unless I'm missing some other strong ref somewhere?
20:03:55	Araq	you do but nothing I try works either :P
20:04:37	rayman22201	you tease. what strong ref am I missing? :-P
20:04:54	rayman22201	but also, :-(
20:05:17	Araq	I have
20:05:18	Araq	var asyncProcIterOwner = asyncProcIter_400015
20:05:18	Araq	var nameIterVar_gensym400018 {.cursor.} = asyncProcIterOwner
20:05:39	Araq	and also
20:05:42	Araq	var closureWindow: typeof(asyncProcNimAsyncContinue_400016)
20:05:44	Araq	var closureWindowUnowned {.cursor.}: typeof(asyncProcNimAsyncContinue_400016)
20:05:46	Araq	but no luck, the leak remains
20:06:00	Araq	(no need to run it a loop btw, it leaks on the first iteration)
20:06:15	disruptek	well, i said that but you said it was fixed. 🙄
20:06:27	rayman22201	the loop was an artifact of earlier testing. ignore that. sorry
20:10:05	*	Vladar quit (Quit: Leaving)
20:10:57	*	ptdel quit (Ping timeout: 260 seconds)
20:12:03	Araq	want to see my solution?
20:12:13	rayman22201	yes
20:12:26	rayman22201	but now I'm worried
20:12:32	Araq	basically I removed the crap and it works :-)
20:12:56	rayman22201	show me the crap! :-P
20:13:12	Araq	https://play.nim-lang.org/#ix=27QO
20:13:26	Araq	not sure if the macro can produce this instead but it seems do-able to me
20:14:13	disruptek	yes, you're two days behind me, araq. 😜
20:14:23	rayman22201	it looks like you just pulled out the error handling?
20:14:37	Araq	doesn't matter, the error handling doesn't leak
20:15:10	dom96	what is the actual change to the original generated by the macro?
20:15:15	rayman22201	exactly
20:15:17	rayman22201	this?
20:15:21	rayman22201	I don't understand what changed
20:15:27	disruptek	well, that leaks for me.
20:15:40	Araq	start
20:15:42	Araq	hello sailor green eggs and ham
20:15:43	Araq	finish
20:15:45	Araq	extra Mem: 0
20:15:49	Araq	it really doesn't
20:16:00	disruptek	-d:useMalloc
20:16:06	dom96	for reference, here is what the macro generates: https://gist.github.com/dom96/a4f8754f646e95a03985fa91b56172c3
20:16:19	Araq	the most important change is that I gave the anon proc a name
20:17:11	Araq	I don't understand why the macro doesn't do that, it simplifies things quite a bit
20:17:31	Araq	and it's still a .closure so we're good
20:18:28	rayman22201	confirmed it does not leak for me
20:18:38	Araq	and once you have the named proc, all you need to do is watch out for captures
20:18:39	rayman22201	still trying to understand what magic you did Araq lol
20:19:05	Araq	and we probably need better support for a more precise control over captures
20:19:15	disruptek	so we can'd useMalloc with arc?
20:19:28	rayman22201	I tested with useMalloc
20:19:30	rayman22201	no leaks
20:19:32	Araq	disruptek, we can and do it all the time
20:19:43	disruptek	i cannot repro this.
20:20:01	Araq	disruptek, ok, so where does it leak for you?
20:20:02	*	jjido joined #nim
20:20:13	rayman22201	disruptek, I have a feeling your codebase may have drifted? mayb start from head again?
20:20:28	disruptek	holdon, let me c+p araq's stuff again.
20:21:04	disruptek	yep, it's fine.
20:21:06	disruptek	sorry.
20:21:08	rayman22201	the closure does have a name, "asyncProcNimAsyncContinue_400016"
20:21:17	rayman22201	it looks like you just changed the name to "inner"
20:22:01	Araq	no, it's not a 'var' anymore
20:22:09	Araq	please read it carefully
20:22:26	dom96	Araq, can you modify the original again without removing other things?
20:22:37	dom96	just the changes necessary to get rid of the leak
20:23:02	Araq	bah, all that is missing the 'assert' logic
20:23:10	Araq	but ok, let me try
20:23:41	rayman22201	ah. interesting. it was me that changed it to var
20:23:47	rayman22201	the macro doesn't do that
20:24:53	rayman22201	son of a bisket
20:25:04	rayman22201	biscuit even
20:25:23	rayman22201	why does that matter?
20:25:46	disruptek	my closure has a first name, it's OSCURLE
20:25:53	Araq	rayman22201, maybe it's a bug in injectdestructors.nim
20:26:06	Araq	but since it's so convoluted anyway, why not fix our macro instead?
20:26:26	Araq	dom96, what to base it on?
20:26:31	rayman22201	I agree. This is a straightforward fix the macro. but why not both? lol
20:26:33	disruptek	itym in addition to
20:26:33	dom96	my gist
20:26:40	Araq	https://play.nim-lang.org/#ix=27QG ?
20:26:50	dom96	https://gist.github.com/dom96/a4f8754f646e95a03985fa91b56172c3
20:27:07	Araq	ok
20:27:56	FromDiscord	<itmuckel> Hey guys! How do I write a `=destroy` function for a `ref object` type?
20:28:47	rayman22201	@dom96 https://play.nim-lang.org/#ix=27QV
20:28:54	rayman22201	That's the fix
20:29:00	lqdev[m]	@itmuckel you don't, instead create your ref type with `new(x, proc () = discard)`
20:29:05	lqdev[m]	the second param is the finalizer
20:29:35	FromDiscord	<itmuckel> oh okay, thanks!
20:29:36	lqdev[m]	change the `proc () =` to `proc (x: MyRefType)`
20:29:54	lqdev[m]	see https://nim-lang.org/docs/system.html#new%2Cref.T%2Cproc%28ref.T%29
20:29:56	rayman22201	make `retFutUnown` and `nameIterVar` into cursors
20:30:28	dom96	https://gist.github.com/dom96/e3a9c381993aefffad3dd241d5a4b489/revisions#diff-51d3f11ded3e2aea5be62d7d3a33e651
20:31:43	rayman22201	yup
20:33:21	dom96	okay, should be fairly trivial macro change then
20:33:27	Araq	dom96, replied on your gist
20:34:07	disruptek	if nameiter isn't a cursor, we leak in malloc but not nim.
20:35:29	rayman22201	this. Also, I think we may need a more complicated example, because the iterator needs to be able to live longer.
20:36:01	*	asd joined #nim
20:36:11	disruptek	we have longer tests in stdlib.
20:36:12	rayman22201	it works in this case because the promise completes immediately, but now we need to test a case where it takes some iterations of the async event loop to complete
20:36:29	dom96	easy test: use sleepAsync
20:39:10	rayman22201	good idea.
20:39:16	rayman22201	bah. I have to go. bbl
20:39:31	Araq	ok, bye
20:39:38	*	asd quit (Remote host closed the connection)
20:42:31	Araq	dom96, about your json problem, run it via 'nim c --gc:arc --debuginfo -d:useMalloc foo.nim && valgrind ./foo'
20:42:40	Araq	and see what it turns up
20:42:43	*	narimiran quit (Ping timeout: 260 seconds)
20:46:24	*	JustASlacker joined #nim
21:00:52	*	Hideki_ joined #nim
21:05:28	*	Hideki_ quit (Ping timeout: 268 seconds)
21:09:30	*	jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:21:30	*	logand`` quit (Ping timeout: 268 seconds)
21:32:08	Zevv	~.
21:32:09	disbot	no footnotes for `.`. 🙁
21:33:15	*	ronny joined #nim
21:33:33	ronny	hi
21:34:18	ronny	is there a siggested library/structure to use when creating commands with subcommands (similar to git + its subcommands)
21:35:43	disruptek	!repo cligen
21:35:44	disbot	https://github.com/c-blake/cligen -- 9cligen: 11Nim library to infer/generate command-line-interfaces 15 140⭐ 11🍴 7& 1 more...
21:35:58	*	Trustable quit (Remote host closed the connection)
21:39:00	*	leorize joined #nim
21:52:00	*	tane_ quit (Quit: Leaving)
21:55:56	ronny	nimble search after nimble update complains about missing ddescription in packages.json ?
21:55:59	*	dadada quit (Ping timeout: 258 seconds)
22:03:39	*	JustASlacker quit (Ping timeout: 258 seconds)
22:06:26	FromDiscord	<Clyybber> !repo nimph
22:06:26	disbot	https://github.com/disruptek/nimph -- 9nimph: 11Nim package hierarchy manager from the future 🧚 15 52⭐ 2🍴 7& 1 more...
22:08:43	shashlick	is it possible to have different proc signatures depending on a when condition
22:08:54	disruptek	sure.
22:08:55	shashlick	want to see if async and no async can coexist in the same file
22:09:08	shashlick	but same body
22:09:24	disruptek	mmm just use a template.
22:09:36	shashlick	how
22:09:47	shashlick	ah okay
22:09:50	disruptek	yeah.
22:14:46	*	letto quit (Ping timeout: 258 seconds)
22:20:11	shashlick	nope, says await only available within .async.
22:20:20	disruptek	well, yeah.
22:20:47	shashlick	http://ix.io/27Rp
22:23:11	*	letto joined #nim
22:25:46	*	opal quit (Remote host closed the connection)
22:25:59	*	opal joined #nim
22:28:23	*	ptdel joined #nim
22:30:22	*	Hideki_ joined #nim
22:35:41	*	solitudesf quit (Ping timeout: 272 seconds)
22:36:03	*	opal quit (Ping timeout: 240 seconds)
22:36:07	*	dcmertens quit (Ping timeout: 268 seconds)
22:37:39	shashlick	figured it out but async still doesn't work
22:38:18	shashlick	have to return number of bytes written in curl's write callbacks and it doesn't get the value with Future[int]
22:38:39	shashlick	basically running async code in cdecl callback
22:39:12	disruptek	and you cannot get a return value into your proc?
22:39:22	disruptek	or you cannot get it to come back out in the Future[int]?
22:39:30	*	opal joined #nim
22:39:41	shashlick	it does come back but curl probably doesn't get what i returned
22:39:49	shashlick	i'm returning to curl
22:40:58	disruptek	does it work if you `waitfor` the async proc?
22:41:24	shashlick	but i'm not the caller, curl is
22:41:40	disruptek	i wouldn't expect this to work.
22:41:42	shashlick	basically this proc - https://github.com/genotrance/px2/blob/master/curl.nim#L29
22:41:55	shashlick	headerCb is called by curl when it has headers to write
22:42:12	shashlick	so I need to mark the proc as Future[int] {.async, cdecl.}
22:43:26	disruptek	this is nuts. why do you have to do this?
22:44:20	shashlick	changing await to waitFor in the callback and removing the async from the signature worked
22:45:07	disruptek	yeah, why do you need to use async?
22:46:34	disruptek	you're a wild man, shashlick.
22:47:02	*	pbb quit (Ping timeout: 252 seconds)
22:48:39	*	pbb joined #nim
22:50:04	dom96	ronny: can you try again? I fixed the description
22:51:55	*	Hideki_ quit (Remote host closed the connection)
22:53:04	shashlick	well, this is going to be a multi-connection proxy server so it needs to be able to do things in parallel
22:53:07	dom96	Araq, just did what you suggested, so far valgrind appears to be stuck.
22:53:46	shashlick	it is unclear if it will really work in async mode cause curl might just block on perform()
22:54:07	shashlick	but now i have a single threaded, single threaded async and multi-threaded version
22:54:20	shashlick	need to check if it works as expected in each mode and the benefits
22:54:22	dom96	Araq, yep, I'm killing it. It's using 100% CPU and not doing anything, here is the output it gave: https://gist.github.com/dom96/f5f16d962cad189dab6a788cc2593d49
22:55:44	shashlick	what's a good load testing tool that supports proxies
23:05:36	*	voltist joined #nim
23:24:51	*	ptdel quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
23:24:54	*	Hideki_ joined #nim
23:27:51	*	ptdel joined #nim
23:29:31	*	Hideki_ quit (Ping timeout: 258 seconds)
23:30:50	*	pbb quit (Ping timeout: 240 seconds)
23:46:53	*	Hideki_ joined #nim
23:47:50	rayman22201	@dom96, @disruptek, @araq, I can't stay, but I added the cursors to the correct places in the async macro
23:47:50	rayman22201	https://github.com/rayman22201/Nim/commit/39c1131a7d8f6d5b46d4aec78206f01a90b868f8
23:48:06	rayman22201	bad news. It breaks with sleepAsync :-(
23:48:40	rayman22201	use this test: http://ix.io/27RJ
23:49:30	rayman22201	weirdly, with useMalloc and valgrind it gives bad reads. With nim alloc it just leaks. bad either way
23:51:51	rayman22201	I believe it's the lifetime issue I spoke of earlier
23:57:03	*	NimBot joined #nim