<< 20-01-2020 >>

---

00:00:24	*	pbb joined #nim
00:05:03	*	Hideki_ quit (Remote host closed the connection)
00:37:05	*	cyraxjoe quit (Quit: No Ping reply in 180 seconds.)
00:38:24	*	cyraxjoe joined #nim
00:40:26	*	Hideki_ joined #nim
00:41:03	*	opal quit (Ping timeout: 240 seconds)
00:42:09	*	opal joined #nim
00:52:26	*	nuxdie quit (Ping timeout: 252 seconds)
00:52:51	*	nuxdie joined #nim
00:59:39	FromDiscord	<mfiano> Sigh. I spent all weekend fighting with the compiler. generics don't behave like i expect apparently
01:01:02	Yardanico	how do you expect them to behave? :P
01:01:17	Yardanico	just remember that type system inis compile-time :)
01:02:16	*	lritter quit (Quit: Leaving)
01:03:15	*	Hideki_ quit (Ping timeout: 272 seconds)
01:03:44	FromDiscord	<mfiano> Well for a start, I'd expect this to fail to compile https://play.nim-lang.org/#ix=27RU
01:09:57	Yardanico	well, seems like the resulting type is Vec2[system.float32]
01:10:22	Yardanico	seems like it's wrong for me, but you can always specify types explicitly
01:15:00	FromDiscord	<mfiano> Also I cant for the life of me figure out how to make this more generic and use a seq for storage and be able to create arbitrarily sized vectors
01:16:15	nisstyre	Is it safe to delete keys from a table while iterating over `pairs` ?
01:16:39	Yardanico	https://forum.nim-lang.org/t/3892
01:16:50	Yardanico	@mfiano I'll show you some code as an example in a few minutes :)
01:16:54	nisstyre	ok, makes sense
01:17:55	FromDiscord	<mfiano> Ok 🙂
01:18:05	Yardanico	well, I found a pretty old version, but - https://forum.nim-lang.org/t/914#5463
01:18:15	Yardanico	uses array as the underlying type instead of a seq since it's compiletime
01:18:56	Yardanico	or check out https://github.com/stavenko/nim-glm/blob/master/glm/vec.nim
01:20:43	FromDiscord	<mfiano> https://github.com/numforge/laser/blob/master/benchmarks/loop_iteration/tensor.nim seems to use seq but couldnt make sense out of it to adapt it
01:24:27	FromGitter	<mratsim> What's a Vec2[T]?
01:25:14	FromGitter	<mratsim> The tensor can store a Vec2[T]
01:25:41	FromGitter	<mratsim> Or you have 2 tensors, one for the x and one for the y
01:28:30	FromGitter	<mratsim> But otherwise isn't what you need just a seq[Vec2[T]]?
01:29:13	FromGitter	<mratsim> Or tuple[xs, ys: seq[T]]
01:30:48	Yardanico	I think they just want a generic Vector type :)
01:30:51	Yardanico	for different sizes
01:35:44	FromDiscord	<mfiano> Yeah, and that swizzle macro doesn't work in that thread
01:36:03	FromDiscord	<mfiano> undeclared field 'xy' using their code
01:41:37	FromDiscord	<treeform> @mfiano I found that a generic vector is too much to deal with. The errors are ugly... the code is complex. Do we have integer[16bit], integer[32bit], integer[64bit]? No ... it feels too heavy to use generics for a simple thing like vector.
01:42:07	FromDiscord	<treeform> In games you always use the float32 vector anyways almost 100% of the time.
01:42:50	FromDiscord	<mfiano> Thanks for your thoughts on the matter. I did read your implementation. I am just frutrated because I've been trying to write trivial code for days now and can't even get more than 10 lines to compile.
01:42:50	FromDiscord	<treeform> For a space game I was working on i had the flaot32 scene vectors and float64 space vectors ... even then I don't think generics would have helped me.
01:43:31	FromDiscord	<mfiano> That isn't true. I use half-floats and boolean vectors a lot to be passed as uniforms and to populate various buffers
01:44:05	FromDiscord	<mfiano> Though I have been a game developer for 20 years, so I've seen a lot of studio magic
01:44:24	FromDiscord	<treeform> I like magic when it works... I hate magic when it does not.
01:45:58	FromDiscord	<mfiano> Fair point.
01:46:24	FromDiscord	<mfiano> I'm just frustrated. Rust didn't even give me this much difficulty with its compiler, and I think that speaks volumes as to how I'm struggling here.
01:49:15	nisstyre	mfiano: Have you ever written Haskell? It took me months to get comfortable and not have huge compiler errors all the time
01:49:28	nisstyre	it's normal to have a high learning curve for some things
01:49:30	nisstyre	give it time
01:49:51	FromDiscord	<mfiano> Yeah I years ago
01:54:08	*	leorize quit (Quit: WeeChat 2.6)
02:10:28	disruptek	rayman22201: fair amount of corruption with that patch.
02:18:28	rayman22201	Yeah. No cycles any more but the closures don't live long enough. I think the fix is to give ownership of the closures to the Promise (this is what "disposable Promise" is supposed to do). But I'm at a party right now, so I can't do further testing.
02:20:44	disruptek	exactly. because we want everything to flow from the future.
02:21:27	rayman22201	Still good progress though. We had to break the cycle first
02:22:52	*	xet7 quit (Ping timeout: 268 seconds)
02:30:19	*	Hideki_ joined #nim
02:49:21	FromDiscord	<Rika> Huh. The default of a range[1..20] is 0, how do I change this?
02:49:58	disruptek	that's a good first step.
02:51:16	disruptek	i don't think you can without default fields; clyybber would know.
02:55:06	FromDiscord	<treeform> @mfiano it looks like float64 gets auto converted to float32... https://play.nim-lang.org/#ix=27Sd I never know that happens.
02:56:41	FromDiscord	<treeform> from manual:
02:56:43	FromDiscord	<treeform> ```Automatic type conversion in expressions with different kinds of floating
02:56:43	FromDiscord	<treeform> point types is performed: the smaller type is converted to the larger. Integer
02:56:43	FromDiscord	<treeform> types are **not** converted to floating point types automatically, nor vice
02:56:44	FromDiscord	<treeform> versa. Use the `toInt <system.html#toInt,float>`_ and
02:56:44	FromDiscord	<treeform> `toFloat <system.html#toFloat,int>`_ procs for these conversions.```
02:57:41	FromDiscord	<treeform> But the example I have is larger float64 bit is being auto converted to a smaller float32 bit.
02:59:27	FromGitter	<Varriount> disruptek: I'm still unsure as to whether this whole "only reference counting" scheme is going to help Nim.
02:59:42	disruptek	wut
03:00:15	disruptek	"only reference counting"?
03:00:49	disruptek	you mean weak?
03:00:55	FromGitter	<Varriount> Well, that's why cycles have to be broken in all the async stuff, right? There's no cycle detection/collector
03:01:07	disruptek	there is, in the form of orc.
03:01:32	disruptek	but orc makes more sense as a tool to help you have orc-free code that's faster to build and faster to run.
03:02:14	disruptek	obviously there are some cases where it'll be useful as an impl detail but...
03:03:22	FromGitter	<Varriount> That assumes that a user of the language has high performance requirements
03:04:08	disruptek	if orc improves then it could be made default, but it's pretty slow right now.
03:04:23	FromGitter	<Varriount> And that library writers will test their libraries using only arc
03:05:02	disruptek	i doubt most writers test their libraries.
03:05:27	disruptek	i mean, with regard to gc.
03:05:57	disruptek	golden tests itself for leaks. i don't think i've ever seen such a test before.
03:06:18	FromGitter	<Varriount> I wonder how possible it is to detect reference cycles at compile time
03:06:25	disruptek	admittedly, i haven't looked at a lot of tests. at least, i don't think i have.
03:06:48	disruptek	that's what orc does.
03:07:36	FromGitter	<Varriount> It's not a classic mark-and-sweep GC?
03:08:25	disruptek	no, i don't think so.
03:09:23	disruptek	it's weird, but i know the compiler better from c than i do from nim.
03:14:24	FromDiscord	<treeform> I create a forum post to talk about this float64->float32 stuff: https://forum.nim-lang.org/t/5836
03:16:01	FromDiscord	<treeform> disruptek, is it easier to test a deterministic GC for leaks? Your program can always check if its allocated memory = 0 right when it exists?
03:16:23	*	endragor joined #nim
03:16:41	FromDiscord	<treeform> Maybe there it could auto check on debug builds on exit and says some thing like "leak detected" on exit.
03:16:56	disruptek	not just that. in theory you can optimize alloc and layout.
03:23:28	*	dddddd quit (Remote host closed the connection)
03:24:37	disruptek	imagine that at process "exit" you examine the memory. you are expecting to find value X.
03:25:18	disruptek	now you can mess with the guts and still predict whether you deviate from X.
03:31:27	disruptek	we could do that at the end of a closure.
03:32:10	disruptek	or inside the cfg, really.
03:34:35	*	Hideki_ quit (Ping timeout: 268 seconds)
03:37:55	FromDiscord	<treeform> you could create asserts such as grab the amount of memory entering a critical section and exiting a critical section should match it...
03:38:16	disruptek	or be a multiple of X, etc.
03:39:21	FromDiscord	<treeform> I wanted to add a pragma ... that says some thing like will not allocate memory ... so that I can guard performance sensitive functions from allocating heap... so its kind of related.
03:40:23	disruptek	i wonder; is there an effect for heap use?
03:40:56	disruptek	that seems like the right place for it.
03:53:08	*	muffindrake quit (Ping timeout: 248 seconds)
03:55:32	*	muffindrake joined #nim
04:15:21	*	rockcavera quit (Remote host closed the connection)
04:48:26	*	marmotini_ joined #nim
04:51:24	*	nsf joined #nim
04:53:10	FromDiscord	<mfiano> @treeform Indeed. It seems like a serious flaw
05:03:26	FromDiscord	<treeform> @mfiano https://forum.nim-lang.org/t/5836
05:09:03	FromDiscord	<mfiano> I saw
05:09:42	*	ptdel quit (Remote host closed the connection)
05:15:13	Zevv	moi'n folks
05:15:24	disruptek	howdy zevv
05:15:46	Zevv	while we are talking allocs: I noticed nim's alloc implemention does not really do realloc - it always makes a new copy
05:16:05	Zevv	I have a 3 line snippet that runs 3 times faster with -d:useMalloc then with nims allocator
05:16:16	Zevv	and its not even that pathethic a use case
05:16:33	disruptek	y'know i love to hear these stories.
05:16:48	disruptek	it just means we're barely scratching the surface of what's possible.
05:17:19	disruptek	i'm not allowed to scratch any more.
05:17:33	disruptek	fungus, impetigo, mrsa.
05:17:39	Zevv	http://ix.io/27Su
05:17:55	disruptek	honestly, i'd get in trouble if they knew i took my gloves off.
05:18:21	Zevv	scratching the *surface* is always allowed
05:18:27	Zevv	don't dig too deep, though
05:18:39	disruptek	nice "use-case".
05:18:50	Zevv	funny eh
05:18:52	disruptek	i don't think that word means what you think it means.
05:20:04	Zevv	now someone will remark that I should use `string.repeat` instead of course
05:21:01	disruptek	treeform: got another candidate for your nimbench.
05:22:05	Zevv	I'll see if I can grog nims allocator and make it do the Right Thing here
05:22:19	Zevv	s/grog/grok/
05:22:29	disruptek	grog has its uses, too.
05:23:40	disruptek	i wouldn't waste it on the allocator, though.
05:24:55	Zevv	it makes me find the courage, right
05:25:04	disruptek	that's it.
05:25:17	disruptek	it girds the loins.
05:25:17	Zevv	but anyway, a more then 3 times speedup might be worth the effort.
05:25:28	disruptek	thing about the allocator though, is.
05:25:31	disruptek	she always puts out.
05:25:32	disruptek	always.
05:25:45	disruptek	don't waste your grog on the allocator.
05:31:01	*	Hideki_ joined #nim
05:35:18	*	Hideki_ quit (Ping timeout: 260 seconds)
05:35:23	Zevv	why do i even talk to you, i wonder
05:35:41	Zevv	but then again, hey, why not!
05:36:20	disruptek	zevv i'd like to tell you, but my dog is growling at me.
05:37:49	disruptek	keep my chair warm for the next 8hrs and have a good shift.
05:39:20	Zevv	sweet dreams
05:39:24	*	narimiran joined #nim
05:49:49	*	marmotini_ quit (Remote host closed the connection)
06:31:20	*	sagax quit (Read error: Connection reset by peer)
06:31:56	*	voltist quit (Quit: Leaving)
06:39:20	FromDiscord	<demotomohiro> ~~
06:39:52	FromDiscord	<demotomohiro> ~nim
06:39:52	disbot	no footnotes for `nim`. 🙁
06:58:29	FromDiscord	<DeltaPHC> Is there any documentation on how `testament` works? I can get the command line args of course, but that doesn't tell me how to write the actual tests, lol
06:59:33	shashlick	the nim-lang/nim/tests folder is full of them
07:00:20	FromDiscord	<DeltaPHC> Ah, examples. That's a start, thanks
07:00:47	FromDiscord	<DeltaPHC> I do think there should be an official guide for tests
07:01:32	shashlick	agree
07:02:28	*	dadada joined #nim
07:02:51	*	dadada is now known as Guest60505
07:07:34	*	arecaceae quit (Remote host closed the connection)
07:07:59	*	arecaceae joined #nim
07:13:45	FromDiscord	<DeltaPHC> It's something that I think Rust gets right for the most part. It doesn't even have the most featureful or amazing tests, but the barrier of entry is so low. Write functions with asserts in them, attribute them as tests, `cargo test`, that's it
07:16:14	shashlick	there is also nimble test and unittest module
07:17:03	*	Vladar joined #nim
07:17:49	FromDiscord	<DeltaPHC> unittest docs say to use testament :P
07:18:53	FromDiscord	<DeltaPHC> Didn't know about nimble test though
07:26:27	FromDiscord	<Rika> i think they mean when making tests for the compiler
07:26:33	FromDiscord	<Rika> otherwise, unittest is fine
07:26:57	FromDiscord	<Rika> from my experience there were no issues, but yeah that was my experience
07:29:31	FromDiscord	<DeltaPHC> I'm thinking that having three different, official ways of testing is a tad confusing, but I suppose it's not as big of a deal as just having tests in the first place
07:31:44	FromDiscord	<Rika> testament is supposed to replace unittest but i dont know where that's gone
07:37:07	FromDiscord	<DeltaPHC> Ideally there should be just one official way to do tests. People will still be free to make their own testing frameworks, but just officially speaking, I think unifying into one thing would be beneficial
07:45:56	FromDiscord	<DeltaPHC> Especially as Nim's ecosystem grows, people at any experience level shouldn't feel intimidated by writing tests, IMO
07:53:49	Araq	frederico had the idea of using testament with unittest's syntax
07:53:55	Araq	and I think it's a good one
07:54:31	Araq	barrier to entry is low with Nim too, use 'when isMainModule: assert ...'
07:54:54	Araq	and then run 'nim c -r mymodule'
07:55:31	*	muffindrake quit (Quit: muffindrake)
07:56:54	*	JustASlacker joined #nim
08:00:09	FromGitter	<Varriount> A mock generating framework would be nice. Somewhat difficult though
08:04:54	*	gmpreussner joined #nim
08:11:41	FromGitter	<zacharycarter> most languages don't have "an official way to do tests"
08:12:15	FromGitter	<zacharycarter> generally libraries are authored to provide support for testing
08:12:36	FromGitter	<zacharycarter> golang however had a test module in their stdlib
08:12:45	*	sagax joined #nim
08:13:02	FromGitter	<zacharycarter> I like the idea of the unittest module staying around, and just having its internals gutted for whatever the best implementation is - whether its testament or something else
08:13:37	FromGitter	<zacharycarter> I should say - most languages I've used, because I haven't used enough to make that definitive of a statement
08:17:46	Araq	yeah, unnittest is unkillable, we need to fix it
08:20:54	FromGitter	<Varriount> @zacharycarter it seems like, usually a de-facto standard arises
08:21:49	FromGitter	<Varriount> Python has an official unit test module, however most projects use pytest or nose
08:23:13	FromGitter	<zacharycarter> yeah - I guess I just don't like the word official, because as you just pointed out Python has an official one but most projects don't use it
08:23:43	FromGitter	<zacharycarter> I suppose that's unavoidable though
08:23:50	*	solitudesf joined #nim
08:25:50	Araq	not sure how it can be fixed though, it uses plenty of templates that are supposed to be "overridable"
08:26:11	Araq	and it uses inheritance and methods for the output generation
08:26:26	Araq	nothing I consider idiomatic.
08:29:42	*	muffindrake joined #nim
08:31:41	Araq	hmm testament could simply support a very similar DSL
08:36:24	*	PMunch joined #nim
08:38:19	*	floppydh joined #nim
08:48:37	Zevv	so, how do I add these leak checks back in those tests.
08:49:41	Zevv	using valgrind is not good for the run time and not portable
08:50:12	Zevv	glibc has malloc debug support, is that portable enough?
08:50:24	Zevv	Or add counters into all the alloc implementations?
08:51:08	*	uu91 joined #nim
08:52:35	Araq	I hoped there would be some semi-portable way to implement getOccupiedMem
08:52:56	Araq	like malloc_opt_getusedmem
08:53:35	Araq	maybe will fewer vowels to please the dyslexics
08:53:40	Araq	maybe with fewer vowels to please the dyslexics
08:55:47	Zevv	we can add that for implementations that don't provide it, would be pretty trivial. Alternative would be to do this ourselves - rename all the allocX procs to allocXimpl, and create some templates with the old names that optionally keep track of allocation counts and sizes. Enable for tests, keep disabled for production.
08:56:25	Zevv	The good thing of having one allocX implemenation is also that it is easer to add other ad-hoc trace code, like printing all allocs/frees, and it will work with all implementations
09:00:59	PMunch	Wait, are abbreviations with less vowels actually easier for dyslectics? Or where you just joking?
09:13:25	Araq	PMunch, joking.
09:13:32	Araq	Zevv, yeah, sounds good
09:14:04	*	Guest60505 is now known as dadada
09:15:38	dadada	I'm considering buying "nim in action" ... will I get updates of this ebook for free, when I buy it? Will it get updated regularly?
09:16:00	*	Vladar quit (Quit: Leaving)
09:21:34	dadada	mostly considering it to support Nim development, it would be nice to informed about changes to Nim through future versions of the same book though
09:25:46	livcd	not with manning
09:25:52	livcd	you get a 50% off at best
09:42:06	FromGitter	<zah> https://scontent.fsof6-1.fna.fbcdn.net/v/t1.0-9/82879865_2495312787401153_3735925264601841664_o.jpg?_nc_cat=107&_nc_ohc=nAX1hynL67EAX_XVLMv&_nc_ht=scontent.fsof6-1.fna&oh=2ca78be11eee2d0f540b9086ed0749b9&oe=5ED51492
09:45:14	*	Vladar joined #nim
09:45:50	Araq	:D
09:46:05	FromGitter	<zacharycarter> where is that from?
09:46:07	FromGitter	<zacharycarter> the picture I mean
10:01:00	FromGitter	<zah> Code::Dive in Poland
10:04:52	PMunch	dadada, the book is really good. And great care is taken to make sure that the examples all work in newer versions. It won't get updated though, so any completely new features you to to learn about from other sources
10:11:11	FromGitter	<zacharycarter> oh cool
10:14:06	dadada	ok, this may be a backwards idea, but hear me out, to create bindings for complex C++ projects couldn't we exploit the binary libraries with debug information? Thankfully work for parsing those has somewhat been done already, https://github.com/eliben/pyelftools
10:14:14	*	uu91 quit (Read error: Connection reset by peer)
10:15:09	dadada	the process would be compile say Qt5 with debug information -> use pyelftools as basis for custom tool to parse the created libraries and get all the information Nim needs to interface/interop with the library
10:17:01	Araq	it would most likely be machine specific and not help much
10:17:22	Araq	for example, how do you get information about the API's default parameters?
10:17:39	Araq	it's a concept that doesn't exist in the binary, the compiler filled out some parameters for you
10:18:55	Araq	look, Qt is very special with its moc compiler, arguably it's not really standard C++ so even if we had a perfect C++ parser producing a perfect Nim wrapper it would fail for Qt
10:19:01	dadada	good point about the default parameters
10:19:18	Araq	Qt deserves a special tool.
10:19:31	Araq	I know it sucks, but I can see no other realistic option
10:19:35	dadada	requires maybe, deserves I'm not so sure about...
10:19:49	Araq	ok, agreed
10:22:04	dadada	they created shiboken2 for the python bindings, maybe it can be adapted...
10:22:18	dadada	have been thinking about how to make Nim popular
10:22:48	Araq	we have a QT wrappers btw
10:23:27	*	sagax quit (Ping timeout: 265 seconds)
10:23:27	Araq	but it uses the Qt dynamic stuff, tbh I have no clue. ping filcuc
10:24:35	dadada	you mean QML then, I have never really liked that portion of Qt, QtWidget is what KDE is written in basically and that's the API I'd like to get for Nim
10:25:09	dadada	well QML might be great, but I've never really found a use for it (yet)
10:25:41	dadada	Araq:
10:25:41	Araq	yeah I think that is what it uses, QML
10:25:58	dadada	this basically says you're right http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2008-January/003271.html
10:26:12	dadada	DWARF can tell you that there's a default value
10:26:23	dadada	but it's not easily readable what that is
10:26:39	dadada	it points to a subroutine that can define it, but that's machine code
10:26:46	Araq	that's only an example
10:26:57	Araq	here is what is in DWARF: 16
10:27:08	Araq	here is what it really is: sizeof(int) + sizeof(void*)
10:27:25	Araq	compilers love constant folding
10:28:33	Araq	I know of no system whatsoever that uses DWARF to extract a high level interface
10:28:48	dadada	how about a backend for clang or gcc that doesn't compile to a library but to a JSON containing all relevant information for bindings
10:28:56	dadada	not that I'm going to write that :D
10:29:10	Araq	that's what nimterop does to some extend afaik
10:29:44	Araq	but if your real goal is to make Nim more popular, try our QML wrapper, write some examples
10:29:51	Araq	document its pain points
10:30:08	Araq	maybe offer binary downloads so that the rest of us doesn't have to hunt for missing DLLs
10:30:54	Araq	seems to be a more fruitful approach
10:31:05	dadada	well the best thing would be to port some large Qt project with a user base, that's usually not going to be QML
10:31:32	dadada	there's flatpack, snap, appimage, one of those should do the job
10:31:57	Araq	but then who's gonna maintain the port? and are the core devs willing to switch languages?
10:32:30	Araq	the world is full of reddit clones, yet everybody uses the one and only reddit
10:32:38	dadada	I have some abandoned Qt project that I used to maintain that has users
10:32:40	dadada	AQEMU
10:32:54	FromGitter	<dumjyl> for `const a = [1, 2, 3]; const b = a` where does `b` get resolved to `a` in the compiler?
10:33:52	Araq	dymjyl: line 616 in semstmts.nim
10:34:20	FromGitter	<dumjyl> thanks
10:34:37	Araq	dadada, aha, now we're talking
10:52:53	*	JustASlacker quit (Ping timeout: 272 seconds)
11:03:56	dom96	@zah: wow, how many talks has Viktor done on Nim now? must be at least 4
11:04:26	FromGitter	<zah> I've lost the count myself, but 4 sounds about right
11:08:40	dadada	the talk is great, hope he keeps it up
11:11:07	dom96	I got an invite for Code::DIve last year but wasn't brave enough :)
11:13:21	FromDiscord	<kodkuce> any web scrping lib done in nim?
11:18:05	FromGitter	<zacharycarter> https://nimble.directory/search?query=scraping
11:19:15	FromGitter	<zacharycarter> pretty excited to try out weave tonight
11:19:42	FromGitter	<zacharycarter> and see if it will help with my pathfinding bottleneck
11:19:51	*	xet7 joined #nim
11:20:28	FromDiscord	<kodkuce> i was blind 200%
11:23:03	FromDiscord	<Rika> how do i make a "context manager" (think that's a python term) in nim
11:27:03	Araq	via template withX(body) = ...
11:33:15	*	Hideki_ joined #nim
11:33:18	FromDiscord	<kodkuce> hmm oh i got html parts i need, now how do i convert html objects to nim objects , i have that xmlNode
11:36:38	Zevv	Is there a way to get a proc name as a (const) string at compile time?
11:37:08	FromDiscord	<kodkuce> or do i need to subquery
11:37:52	*	Hideki_ quit (Ping timeout: 260 seconds)
11:40:54	lqdev[m]	Zevv: in what sort of case?
11:42:13	lqdev[m]	you can get the name of a proc as a string pretty easily using macros, but I'm not quite sure what AST you're dealing with
11:42:14	Zevv	let's say "echo functionName()"
11:42:47	Zevv	when done in proc foo will print "foo"
11:43:02	Zevv	no need to have full signatures etc, just to simplify some code where I now pass explicit strings
11:45:21	FromDiscord	<kodkuce> how do i rip text form <h1>dsadsad</h1>
11:46:04	FromDiscord	<kodkuce> prbbaly innerText
11:46:25	lqdev[m]	Zevv: can you give a full example of the input and expected output?
11:47:22	*	rockcavera joined #nim
11:47:28	*	dadada quit (Ping timeout: 260 seconds)
11:53:03	*	sagax joined #nim
11:55:08	PMunch	Zevv, that would indeed be a neat feature
11:55:29	lqdev[m]	oh, I think I get it
11:55:51	lqdev[m]	I don't think that's a feature, unfortunately
11:56:46	lqdev[m]	there's system.instantiationInfo() but it only returns the file and position
11:57:01	PMunch	And it only works for templates
11:57:02	PMunch	https://play.nim-lang.org/#ix=27Ty
11:57:08	PMunch	I think that is what he wants
11:58:28	Zevv	like __FILE__ and __FUNCTION__ in the c preprocessor
11:58:39	Zevv	but nvrmnd, Im fine now
11:59:04	*	dddddd joined #nim
12:02:10	FromGitter	<dumjyl> You can do that with `owner`. This seems to work https://play.nim-lang.org/#ix=27TA
12:03:25	Zevv	sweet, thanks!
12:04:15	lqdev[m]	nice, I didn't think of that
12:06:12	PMunch	Never heard of owner before!
12:07:12	PMunch	Added back in 2018
12:08:59	FromGitter	<dumjyl> It exposes unspecced implementation details, so best avoid it if you can.
12:09:14	lqdev[m]	I did play around with owner for name mangling recently
12:14:00	Zevv	can't use it in my context, I'm too deep in the stdlib and can't use macros or NimNodes there. No problem, thanks anyway
12:18:02	PMunch	Too bad this isn't just built in, the compiler has to know this, right?
12:18:21	Zevv	well, no one seems to have needed this up to now :)
12:18:40	Zevv	and the context is tricky probably. What if you call it from within a template?
12:20:19	PMunch	It xpands and is then resolved right before the procedure is converted into C code?
12:20:59	Zevv	do we have a volounteer? :)
12:22:45	FromDiscord	<Rika> araq: is that the only way? i guess it works. i asked because i dont really like the withX style
12:23:56	FromDiscord	<kodkuce> i have wierd issue, am trying to just filter out something, so i am trying to use contains form strutils duno if xmlparser or some othe thing i importing is naming it same or what, but i am getting Error: type mismatch: got <string, string> but expected one of: proc contains[T](a: openArray[T]; item: T): bool, on playground if i do "sdasdsad".contains("sda") it works too so duno wtf is going around
12:24:29	*	FromGitter quit (Remote host closed the connection)
12:24:47	*	FromGitter joined #nim
12:25:06	FromDiscord	<Rika> what version are you on xd
12:25:38	FromDiscord	<Rika> if xmlparser exported the same name+arity function, it wouldnt compile at all
12:25:45	FromDiscord	<kodkuce> omg i am retard
12:26:14	FromDiscord	<kodkuce> i commented out strutils while i was commenting out old imports
12:27:18	*	matlock quit (Ping timeout: 258 seconds)
12:27:29	*	ryanhowe quit (Remote host closed the connection)
12:27:40	*	matlock joined #nim
12:27:41	*	gsingh93 quit (Ping timeout: 258 seconds)
12:27:45	*	sacredfrog joined #nim
12:28:22	*	shadowbane quit (Remote host closed the connection)
12:28:26	FromDiscord	<Rika> nice
12:28:49	*	shadowbane joined #nim
12:29:50	*	gsingh93 joined #nim
12:33:38	*	dddddd quit (Ping timeout: 240 seconds)
12:33:49	FromDiscord	<Tak> Maybe a silly question but I read that nim doesn't care if identifiers are my_func, myFunc or myfunc i.e snake case or capitalized
12:33:50	FromDiscord	<Tak>
12:33:50	FromDiscord	<Tak> Is that the case for standard library functions or just functions you write?
12:35:42	PMunch	It's for any function
12:35:48	PMunch	Or rather any identifier
12:36:00	PMunch	So variables and constants are the same
12:36:14	PMunch	The capitilization of the first character matters though
12:36:16	narimiran	@Vindaar are you around maybe?
12:36:24	PMunch	so MyFunc would not be the same as myFunc
12:36:34	PMunch	Tak ^
12:37:56	FromDiscord	<Tak> That's very cool, thanks. Follow-up - when calling a function, I saw it has UFCS where you can go object.func() or func(object). You can also go echo("Text") and echo "Text". Can you use spaced args for functions with more than one variable? i.e haskell style so like instead of my_func(arg_a, arg_b) you can go "my_func arg_a arg_b"?
12:38:14	FromDiscord	<Tak> Or for functions with no parameters?
12:40:19	PMunch	You can't use it for functions without parameters
12:41:48	federico3	https://news.ycombinator.com/item?id=21969815 this comment should be put in the GC manual
12:42:21	PMunch	Tak: https://play.nim-lang.org/#ix=27TL here is an example of things that are valid
12:43:13	PMunch	Oh, and 100.test2() is also valid: https://play.nim-lang.org/#ix=27TM
12:44:45	*	dadada joined #nim
12:45:09	*	dadada is now known as Guest15862
12:46:46	*	dddddd joined #nim
12:50:16	*	letto_ joined #nim
12:52:13	*	letto quit (Ping timeout: 258 seconds)
12:57:25	FromGitter	<Vindaar> @narimiran yep, I am
12:58:28	narimiran	@Vindaar i fixed it in the mean time, nevermind :)
12:58:54	FromGitter	<Vindaar> Heh, ok. Was it about adding `ggplotnim` to the packages?
12:58:59	narimiran	yeah
12:59:24	narimiran	by default i couldn't run it locally because i didn't have `ntangle`
12:59:52	narimiran	but we'll just test `nim c -r tests/tests.nim` (or any other file if you think it is more suitable or thorough)
13:01:12	FromGitter	<Vindaar> Oh, right that makes sense. Yes, the full test suite creates a bunch of recipe files from Org files using `ntangle`, which create a bunch of plots. These are then compared to reference plots to check if something changed in the images.
13:02:14	FromDiscord	<Tak> Brilliant, thanks PMunch, have used a fair few languages so just trying to get a feel for the syntax design 🙂 appreciate the help
13:03:35	PMunch	Happy to help :) Nims syntax is quite flexible!
13:04:31	FromGitter	<Vindaar> Maybe it's a better idea to exclude that part of the test from the default "test" task though
13:04:33	FromDiscord	<Tak> Yes, I've written a lot of FP stuff recently and always liked macro systems in CLisp and Rust so seems cool to have a pythonic lang with it
13:04:35	FromDiscord	<Rika> it's almost too flexible, but it isnt so thats 100% okay
13:05:17	FromDiscord	<Tak> Mm, I do wonder if it makes codebases less readable though if everyone uses it differently?
13:06:05	Guest15862	///////9-*9-----------------------8
13:06:17	Guest15862	sry, cleaning the keyboard :D
13:08:11	FromGitter	<Vindaar> @narimiran ok, I changed it. Please use the default `nimble test` now. :)
13:11:04	narimiran	yeah, it works now
13:11:32	*	Guest15862 is now known as dadada
13:14:06	FromGitter	<Vindaar> nice
13:21:45	FromDiscord	<Rika> tak, it doesnt really as its not very ambiguous
13:21:50	*	endragor quit (Remote host closed the connection)
13:21:57	FromDiscord	<Tak> Okie dokie 🙂
13:24:39	*	Hideki_ joined #nim
13:24:46	PMunch	In fact I find it makes codebases more readable
13:25:01	*	arecaceae quit (Remote host closed the connection)
13:25:24	PMunch	I can write a library that uses snake_case, but you can use it as camelCase in your code-base so you're not mixing the two styles
13:25:24	*	arecaceae joined #nim
13:26:03	FromDiscord	<Tak> That's true, people get to use their preferred way
13:26:03	FromDiscord	<Rika> but camelcase is preferred over here
13:26:45	FromDiscord	<Tak> Ok will keep that in mind, is there a style guide?
13:27:46	solitudesf	https://nim-lang.org/docs/nep1.html
13:28:30	FromDiscord	<Tak> Thanks!
13:30:47	*	endragor joined #nim
13:33:56	*	couven92 joined #nim
13:35:39	*	endragor quit (Ping timeout: 268 seconds)
13:37:08	*	couven92 quit (Client Quit)
13:38:29	FromGitter	<kaushalmodi> Tak: Run `nim` with `--styleCheck:hint` or `--styleCheck:error`
13:38:36	*	couven92 joined #nim
13:39:03	FromGitter	<kaushalmodi> I put this in my global config.nims: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5e25ad7620d0f078a6ae2037]
13:40:10	dadada	what's the thing Nim sceptics usually dislike most about Nim?
13:40:37	FromGitter	<kaushalmodi> dadada: I guess the style insensitivity..
13:41:55	dadada	nah, I think that feature is good :D
13:42:11	FromGitter	<kaushalmodi> dadada: I am not complaining :)
13:42:18	solitudesf	they dislike reading the tutorial and love making assumptions
13:42:54	FromGitter	<kaushalmodi> I wonder if Araq put that feature in just for the sceptics to hold on to as otherwise they wouldn't have anything else to complain about :P
13:43:28	solitudesf	@kaushalmodi there is always something to complain about
13:43:31	solitudesf	~&
13:43:31	disbot	&: 11unreachable -- solitudesf
13:48:17	dadada	I see some minor deviations from python syntax where I'm going "did they really have to do this?", usually I get why it's done like that in all the individual cases, however in sum it means that transitioning from python (back and forth) could become a huge issue, since superficially code between the langs looks very similar, but the devil is in the details
13:48:55	dadada	disclaimer: this isn't a complaint!
13:49:05	Araq	every deviation from Python had a good reason, ymmv of course
13:49:12	FromDiscord	<Rika> dadada: i'd like an example
13:49:20	FromDiscord	<Rika> not that im gonna argue
13:49:22	FromDiscord	<Rika> i just want to know
13:50:10	livcd	missing batteries
13:50:16	dadada	FromDiscord: if I give you one example, you or I can both explain why it's making sense, it's the sum of the differences that could (and probably will) trip up some future devs
13:50:33	FromDiscord	<Rika> i said i just wanted to know
13:50:36	FromDiscord	<Rika> uuuuuuuuuuuu
13:50:43	dadada	often it's probably python's fault for having less sane syntax
13:52:33	*	Hideki_ quit (Remote host closed the connection)
13:54:21	*	Hideki_ joined #nim
13:54:24	*	Hideki_ quit (Remote host closed the connection)
13:55:00	*	Hideki_ joined #nim
13:55:13	Araq	Python: 'def' vs 'class' vs 'global' (?) vs nothing for varable declarations.
13:55:28	FromGitter	<alehander92> but this is good dadada
13:55:38	FromGitter	<alehander92> because semantically they are different languages
13:55:55	FromGitter	<alehander92> so similar syntax might be a bit confusing
13:56:00	FromGitter	<alehander92> i think syntax feel
13:56:27	Araq	Nim: let vs var, proc vs func, type and const sections
13:56:45	dadada	Araq: the ones you named all make sense to me
13:59:18	*	Hideki_ quit (Ping timeout: 258 seconds)
14:00:42	*	marmotini_ joined #nim
14:07:12	FromDiscord	<Rika> compiling C is making me go insane again
14:10:19	*	couven92 quit (Quit: Client Disconnecting)
14:19:32	*	rockcavera quit (Remote host closed the connection)
14:21:36	dadada	Araq: why "notin" and "isnot" instead of "not in" and "is not" ... it's not a big deal either way, but one of python's draws is the natural language look
14:22:27	Araq	two token operators are arbitrary in a language where you can define your own operators
14:22:54	Araq	but on the other hand, Nim's keyword operators are already arbitrary.
14:23:18	Araq	iirc 'not in' didn't fit my operator parsing algorithm though
14:23:47	dadada	suspected that that was the reason ...
14:24:07	dadada	simplification for the parser's sake
14:24:30	dadada	hate to tell you, but that's one of the things I don't quite like
14:24:35	*	rockcavera joined #nim
14:24:48	dadada	in a sea of things I love about Nim!(*1000)
14:24:53	*	Hideki_ joined #nim
14:24:53	*	Hideki_ quit (Remote host closed the connection)
14:24:54	Araq	no offense taken
14:25:14	Araq	but notice that Python is FULL of "it's easier to implement this way" on its own
14:25:27	*	Hideki_ joined #nim
14:25:42	*	Hideki_ quit (Remote host closed the connection)
14:25:54	dadada	actually writing a preparser that melts "not in" into "notin" would be easy, wouldn't need to change the actual parser
14:25:55	*	Hideki_ joined #nim
14:25:57	FromGitter	<alehander92> there is some kind of consistency here imo
14:25:58	*	Hideki_ quit (Remote host closed the connection)
14:26:07	FromGitter	<alehander92> its not only about parser but about overall grammar
14:26:25	FromGitter	<alehander92> it helps to be able to think "random two words cant be an operator defined by this macro" imo
14:26:30	*	Hideki_ joined #nim
14:26:45	FromGitter	<alehander92> and keep in mind "parsing" in your head is very common for the human users
14:26:52	FromGitter	<alehander92> when writing/reading dsl-s
14:27:43	dadada	well isnot isn't part of the english language, if you're going for one word, then isnt or aint would both be more accurate, although you'd lack the '
14:28:07	dadada	(aint is slang admittedly)
14:29:08	Araq	'mole hill' vs 'molehill'
14:29:11	*	Hideki_ quit (Remote host closed the connection)
14:29:26	*	Hideki_ joined #nim
14:29:27	*	Hideki_ quit (Remote host closed the connection)
14:29:39	FromGitter	<alehander92> yeah i agree isnt probably would be a bit better
14:29:47	FromGitter	<alehander92> but after all .. isNot(a, b)
14:29:52	FromGitter	<alehander92> is also not part of the english language
14:29:55	FromDiscord	<Clyybber> I think its fine as is, its not Inform after all
14:30:00	*	Hideki_ joined #nim
14:30:12	FromGitter	<alehander92> maybe camelCase would've been the easier fix (and one can actually use that now)
14:30:17	FromGitter	<alehander92> (i think??)
14:30:17	FromDiscord	<Clyybber> and the consistency and simplicity gained is more than worth it
14:30:27	dadada	alehander92: in the case of isNot the camel case makes it clear that is and Not are separate words, so it becomes clear that they're not one word
14:30:40	FromDiscord	<Clyybber> is_not :p
14:30:41	FromGitter	<alehander92> yes i agree that camelcase/_ would've been cleanest
14:30:48	FromGitter	<alehander92> but thats life
14:31:09	FromGitter	<alehander92> but mate
14:31:11	FromGitter	<alehander92> isinstance
14:31:12	FromGitter	<alehander92> getattr
14:31:13	FromGitter	<alehander92> etc
14:31:16	FromGitter	<alehander92> python has many of those
14:31:22	FromDiscord	<Clyybber> dadada: I mean, you can also simply not use notin, and do not(a in b) instead
14:31:30	FromDiscord	<Clyybber> Its just there for convenience
14:31:52	FromDiscord	<Clyybber> And bowing to the irregularity of natural languages doesn't quite fit with macros and stuff I suppose
14:33:29	dadada	Clyybber that syntax is obviously inspired by python (which I consider a good thing), I'd be surprised if parsing a two word phrase would really cause much trouble ... as Araq said, it's a "molehill", there are bigger fish to fry .... yet, I care about molehills like that, sorry
14:34:05	dadada	there's just something off about the term "notin" when "not in" looks familiar and makes perfect sense
14:34:20	dadada	is notin not in or do we have no tin?
14:34:37	Araq	fwiw, not that it matters that much
14:34:43	Araq	from https://docs.python.org/3/reference/grammar.html
14:34:50	Araq	and_test: not_test ('and' not_test)*
14:34:50	Araq	not_test: 'not' not_test | comparison
14:34:50	Araq	comparison: expr (comp_op expr)*
14:34:50	Araq	comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'|'is'|'is' 'not'
14:35:13	Araq	is ambiguous
14:36:12	dadada	how about using ex instead of notin
14:36:19	dadada	ex means roughly outside
14:36:20	Araq	oh never mind, it seems to work out. for Python
14:36:22	FromDiscord	<Rika> dadada: context changes everything
14:36:38	FromDiscord	<Clyybber> dadada: Why though? Whats so bad about notin
14:36:39	FromDiscord	<Rika> ex sounds really vague
14:36:49	FromDiscord	<Rika> cant you write notIn anyway
14:36:58	Araq	but here you go
14:37:04	Araq	from the same source:
14:37:17	Araq	# "test '=' test" is really "keyword '=' test", but we have no such token.
14:37:17	Araq	# These need to be in a single rule to avoid grammar that is ambiguous
14:37:17	Araq	# to our LL(1) parser.
14:37:21	FromGitter	<alehander92> dadada, again isinstance, geattr, python does the same
14:37:40	FromGitter	<alehander92> almost: yes, no operators, but the difference is not so big
14:37:47	Araq	see? Python chooses to simplify things for its parser generator technology
14:37:50	PMunch	Rika, yes you can
14:38:14	FromGitter	<alehander92> python's stdlib is also not always snake_cased
14:38:18	PMunch	Or not_in of course, if you'd like
14:38:21	FromGitter	<alehander92> which is not a problem imo
14:38:23	*	Hideki_ quit (Ping timeout: 260 seconds)
14:39:04	Araq	(and it's not a bad thing, LL(1) is a nice property to strive for)
14:39:24	FromDiscord	<Clyybber> dadada: But I have to confess, when starting to look at nim I also wondered/didn't like notin, but after thinking more about I came to the conclusion that its better to have not_in rather than special case the parser
14:39:28	FromDiscord	<Clyybber> its also better for tooling
14:43:47	Araq	hardly but come on, who cares. English itself doesn't know if it's two or one word, molehill, filename
14:43:53	dadada	Clyybber: notin irritates me, I understand the technical reasons, notIn or not_in would both be okayish, but for everyone who likes python it will keep looking wrong
14:44:32	Araq	you're the first who claims that it "keeps" doing that.
14:44:48	Araq	most human beings are kings of adaption
14:45:35	PMunch	dadada, you can use notIn and not_in in Nim :)
14:45:40	FromGitter	<alehander92> dadada, you keep ignoring my argument that many python core stdlib methods do the same
14:45:49	*	Hideki_ joined #nim
14:46:24	FromGitter	<alehander92> so while i agree with you aesthetically, i dont really believe in your conclusion
14:46:58	FromGitter	<alehander92> and yeah, iirc ive read ruby people complaining about python in this regard :)
14:47:07	dadada	alehander92: I haven't ignored it, as I understand it "not" "==" "in" are more like keywords, like methods are methods and have always looked farther away from natural languager, also I don't consider python perfect in all regards obviously, or I wouldn't need to be here :D
14:47:22	FromGitter	<alehander92> also about even? vs is_even, so there is always more to have
14:47:56	*	NimBot joined #nim
14:48:10	Araq	dadada, here is what you should do:
14:48:19	FromGitter	<alehander92> yeah :)
14:48:52	Araq	program for nim for about 4 weeks and then tell us if it's still weird or whether your preceptrons could move on and you don't mind it anymore
14:49:01	dadada	Araq: well, I'm certain I can adjust, but I'm opinionated on this issue, and I feel python's aesthetics here (just in this one case!) are superior
14:49:48	dadada	I try to be a reasonable person, so I'll not refrain from using Nim just because of stuff like this, hopefully no one else will, tooo
14:49:57	FromDiscord	<Clyybber> : )
14:50:44	*	Hideki_ quit (Ping timeout: 265 seconds)
14:51:53	dadada	Araq: what do you think about "ni" instead of "in", the logic that a reverse in means the opposite and randomly n stands for not and i for in, it's shorter too
14:52:08	dadada	s/reverse/reversed
14:52:15	narimiran	this has gone too far
14:52:20	solitudesf	garbage
14:52:47	Araq	dadada, I can accept you like Python more on this single aspect
14:53:05	Araq	but I won't change the language or introduce more ways to write the same
14:53:19	Araq	you can already use 'if not x.contains(y)'
14:53:38	Araq	and never use 'notin' anywhere in your codebase, it'll work ;-)
14:54:33	*	PMunch quit (Quit: Leaving)
14:56:01	dadada	well, thanks nevertheless, it's not a big deal, just a matter of taste
14:56:22	Araq	yes and for good taste use 'contains' instead
14:57:29	dadada	yeah, that's nice ^^ options
15:05:43	*	oculux quit (Ping timeout: 265 seconds)
15:06:01	*	oculux joined #nim
15:08:29	*	ptdel joined #nim
15:16:40	*	ng0_ joined #nim
15:16:40	*	ng0_ quit (Changing host)
15:16:40	*	ng0_ joined #nim
15:20:03	*	ng0 quit (Ping timeout: 268 seconds)
15:27:10	*	marmotini_ quit (Remote host closed the connection)
15:27:44	*	marmotini_ joined #nim
15:30:37	*	ng0_ is now known as ng0
15:32:18	*	marmotini_ quit (Ping timeout: 265 seconds)
15:33:08	Zevv	Probably a very stupid question, but I don't see what is happening. I get an error "Error: system module needs: nimFrame" when trying to compile lib/nimrtl.nim after I made seemingly unrelated changes to the stdlib
15:33:12	Zevv	how do I debug this?
15:33:33	*	Hideki_ joined #nim
15:34:56	FromDiscord	<Clyybber> Zevv: since valgrind doesn't help here I'd say use "askaraq"
15:35:20	Araq	Zevv, it means you compile a proc with a body too early
15:35:43	Araq	Nim seeks to give the proc the nimFrame stuff but nimFrame isn't available
15:36:47	Zevv	yeah, but I can really not see how this is related to my changes. I guess I'll have to backtrack
15:36:58	*	tane joined #nim
15:37:37	Zevv	it's this commit: it adds templates around the alloc implementations. I'm not touching anything rtl or nimFrame avaik
15:37:39	Zevv	https://github.com/nim-lang/Nim/pull/13190/commits/c0e04405e2ad63c88e76cf9e97c2a2f6f7159eea
15:37:40	disbot	➥ Removed lib/system/allocators.nim. seqs_v2 and strs_v2 now uses allocShared0.
15:38:39	disruptek	you might need a shim for allocators before the rest of the machinery is in place.
15:38:39	Araq	proc `-`*(a, b: AllocStats): AllocStats = ?
15:38:54	disruptek	ie. your tracing stuff, etc.
15:39:15	Zevv	Araq: what's with that?
15:39:23	Araq	easy workaround: {.push stackTrace: off.} .. {.pop.}
15:39:37	Araq	Zevv, it's a proc with an implementation
15:39:49	Araq	so Nim wants to generate a nimFrame and fails at it
15:40:30	Zevv	ok, I clearly need to read up on this
15:42:04	Zevv	how is that different from other procs with implementations in the same file?
15:42:20	Zevv	oh inlines, right?
15:42:41	disruptek	they aren't procs.
15:43:57	Zevv	`proc freeShared(...)` isnt a proc
15:44:35	FromGitter	<alehander92> it sounds very socialist
15:44:47	*	Zevv is kind of in too deep it seems
15:48:38	Araq	you cannot read about it
15:48:48	disruptek	look at the code.
15:48:49	Araq	it's only ever an issue in system.nim
15:49:21	Araq	system.nim is crippled until the compiler arrives at the 'nimFrame' declaration
15:49:50	Zevv	right. So what are the general rules here?
15:49:57	Zevv	.inline. procs only?
15:50:26	Araq	use .push and .pop around your procs
15:50:29	Araq	as I outlined
15:50:58	Zevv	I removed those procs but still the same issue, so it is somewhere else still
15:51:01	Zevv	digging
15:52:49	Zevv	ok, fair enough. stackTrace off it is :)
15:52:50	Zevv	thanks
15:55:28	*	floppydh quit (Quit: WeeChat 2.7)
15:56:37	*	ptdel quit (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
15:59:10	*	ptdel joined #nim
16:04:27	*	Hideki_ quit (Ping timeout: 268 seconds)
16:05:21	*	krux02 joined #nim
16:07:26	disruptek	zevv, give us a hook to add a callback that receives some alloc audit info.
16:09:49	*	dadada quit (Ping timeout: 268 seconds)
16:10:00	FromGitter	<alehander92> ugh Araq karax breaks capture/closureScope
16:11:45	*	icebattle joined #nim
16:12:28	*	Trustable joined #nim
16:12:53	Zevv	disruptek: no bah
16:13:06	disruptek	well, a poll method, then?
16:13:34	Zevv	getAllocStats
16:13:47	Zevv	you can do it before and after and subtract them
16:13:59	Zevv	or do a withAllocStats: block
16:13:59	disruptek	dude.
16:14:18	disruptek	why no callback?
16:14:22	disruptek	i'll be good, i promise.
16:14:24	Zevv	why a callback?
16:14:33	disruptek	for realtime graphing.
16:14:46	Zevv	so who times that?
16:15:01	Zevv	nope, this is it. if you want a graph add it some other way
16:15:04	Zevv	less is more here
16:15:33	disruptek	i can add it either way but i'd rather have distinct records of alloc sizes versus averages, etc.
16:15:54	disruptek	it goes until a define; it will be less most of the time.
16:15:57	Zevv	it is still tricky though, because there is always stuff going on the counters often do not add up
16:15:58	disruptek	s/until/under/
16:16:08	Zevv	you can get 34 frees and 12 allocs
16:16:10	disruptek	all the more reason to run a callback.
16:16:20	Zevv	but from where?
16:16:21	FromDiscord	<Rika> i hate C dynamic libraries now
16:16:25	FromDiscord	<Rika> im going insane due to them
16:16:29	disruptek	that's your problem, sport.
16:16:33	Zevv	nimPreMain and nimPostMain?
16:16:50	disruptek	it doesn't have to capture initial allocs.
16:16:54	disruptek	just the meat of the thing.
16:17:04	Zevv	that is why you do a before and an after
16:17:24	disruptek	i'm gonna have golden's instrumentation running alongside the normal program.
16:17:27	Zevv	but first i need to get it past ci and araq anyway
16:17:32	disruptek	fair enough.
16:20:02	Zevv	I also have a problem with determinism it seems. the old statistcs only measured free/alloc calls for seqsv2 and strsv2, now I measure them all
16:20:16	Zevv	but some things are not stable over runs, which is kind of funny
16:20:31	FromDiscord	<Clyybber> now that is interesting
16:20:56	disruptek	sounds like you need that crappy context manager you wanted me to write.
16:21:55	Zevv	its about lifetime of stuff. things are not dead yet when i get the end result.
16:22:33	disruptek	sounds bad man.
16:23:11	Zevv	but what can i do. my program is measuring itself, there is no outer entity to do that. I want to report allocs from within the program, but they only drop to zero when it is done.
16:23:31	Zevv	adding a printf() to NimMain?!
16:23:34	disruptek	so what?
16:23:44	disruptek	it's normal for programs to alloc memory.
16:23:57	disruptek	delta the empty program against the full program.
16:24:26	Zevv	I'll think about it
16:26:57	disruptek	you picked a pretty rotten time to mess with allocators.
16:27:50	Zevv	no its not
16:27:55	Zevv	its the right time, surely
16:28:26	disruptek	shirley, it will confuse arc debugging.
16:29:17	Zevv	it simplifies
16:29:21	Zevv	i threw stuff out
16:29:26	Zevv	i made stuff smaller
16:29:37	Zevv	tell me again how bad that is
16:29:38	disruptek	wait, did you add any bugs?
16:29:46	Zevv	3, but very well hidden
16:29:59	disruptek	fair enough.
16:30:13	disruptek	i'd have been disappointed if it were less than 3.
16:37:06	*	dadada joined #nim
16:37:31	*	dadada is now known as Guest73511
16:40:02	*	ptdel quit (Ping timeout: 260 seconds)
16:41:10	*	Hideki_ joined #nim
16:43:44	disruptek	i just noticed all my nipples are sagging.
16:43:51	FromGitter	<alehander92> so what do you want to debug
16:44:08	disruptek	well, i gotta perk 'em up somehow.
16:44:09	*	marmotini_ joined #nim
16:44:27	disruptek	they look a little shriveled, too.
16:44:42	FromGitter	<alehander92> free/alloc count only, or free/alloc "time"/size as well etc
16:44:53	FromGitter	<alehander92> if you only need count/size
16:45:20	FromGitter	<alehander92> one thing you can do is run under `rr` and script with simple python the gdb
16:45:33	FromGitter	<alehander92> to postprocess each alloc/free call
16:45:42	disruptek	i wanna build this functionality into any nim program.
16:45:46	*	Hideki_ quit (Ping timeout: 265 seconds)
16:45:51	FromGitter	<alehander92> this way you should have almost no overhead
16:46:08	FromGitter	<alehander92> yeah , of course, i just proposed if zevv wants to debug a certain bug in his projects
16:46:08	disruptek	overhead is a fact of life.
16:46:35	disruptek	cats in boxes.
16:46:57	FromGitter	<alehander92> yeah, but you can move some of the "record" processing out of the original execution
16:47:24	FromGitter	<alehander92> doing that well enough helps with many practical cases..but i also have the very same problem with callgraphs anyway :P
16:48:02	*	ptdel joined #nim
16:51:21	disruptek	we'll just fork for every malloc and process the audit in another thread. 😁
16:52:44	Zevv	alehander92: i know we can run under external tools, but arq wants something portable that always works everywhere
16:53:01	Zevv	the simple solution would be to dump the counters after nim is done from C
16:59:27	Zevv	and the overhead is minimal. when enabled two ints are incremented, when disabled there is no code and no data emitted
17:00:57	*	abm joined #nim
17:23:33	Guest73511	https://www.phoronix.com/scan.php?page=news_item&px=Red-Hat-MIR-Lightweight-JIT
17:23:41	*	Guest73511 is now known as dadada
17:24:10	*	dadada is now known as Guest39061
17:24:30	*	Guest39061 is now known as dadaa
17:24:55	*	dadaa is now known as dadada
17:25:42	dadada	an an early stage currently, looks like it could become useful for porting Nim to WASM and the like in the future
17:32:35	lqdev[m]	how does `continue` behave in a for loop? does it jump forward to the end of the `for` loop's block, or what?
17:36:21	FromDiscord	<mratsim> it starts the next loop iteration immediately
17:36:39	FromDiscord	<mratsim> @dadada, Nim already compiles to WASM, there is no need to port
17:37:54	lqdev[m]	@mratsim I know, but I want the details of how it's implemented. after all, an iterator's heart doesn't necessarily have to be a `while` loop
17:38:53	lqdev[m]	but yeah according to my tests it just jumps past the body https://play.nim-lang.org/#ix=27UU
17:38:59	FromDiscord	<Clyybber> lqdev[m]: Its like a block with a break
17:39:11	FromDiscord	<Clyybber> It wraps the whole loop body in a block
17:39:21	FromDiscord	<Clyybber> and the continue is a break
17:39:27	FromDiscord	<Clyybber> out of that body
17:39:44	dadada	mratsim: aha! didn't know that, thanks. Still I'd like to share this interesting read: https://developers.redhat.com/blog/2020/01/20/mir-a-lightweight-jit-compiler-project/
17:40:11	FromDiscord	<Clyybber> lqdev[m]: See: https://nim-lang.github.io/Nim/manual#statements-and-expressions-continue-statement
17:41:38	lqdev[m]	yeah, I already figured it out but thanks
17:43:05	*	icebattle quit (Quit: leaving)
17:44:13	*	icebattle joined #nim
17:47:56	*	icebattle quit (Client Quit)
17:49:00	*	icebattle joined #nim
17:57:17	*	icebattle quit (Quit: leaving)
17:59:07	*	icebattle joined #nim
18:15:35	disruptek	still think nim is the wrong place to fix fd leaks.
18:36:28	disruptek	who has a working pragma macro for me.
18:36:43	disruptek	WHO
18:36:58	rayman22201	async? lol
18:40:24	*	EvergreenTree quit (Quit: Ping timeout (120 seconds))
18:40:52	*	EvergreenTree joined #nim
18:41:20	*	nsf quit (Quit: WeeChat 2.7)
18:41:51	disruptek	gotta be /working/
18:42:18	rayman22201	async works, just not with arc
18:42:38	Araq	why not?
18:42:47	Araq	didn't we fix it yesterday?
18:43:00	rayman22201	nope. I posted after you went to sleep
18:43:06	disruptek	the closure is corrupted.
18:43:23	Araq	ah
18:43:30	Araq	makes sense
18:43:33	disruptek	yeah.
18:43:37	Araq	I wondered about this too yesterday :P
18:43:51	Araq	dadada, from the article "The actual performance improvement is only 16%, ..."
18:44:14	Araq	16% is quite good, I'll take it from a mere recompile with a newer compiler
18:44:31	rayman22201	https://irclogs.nim-lang.org/19-01-2020.html#23:47:50
18:44:40	Araq	we can use these 16% to check for integer overflows etc
18:45:46	rayman22201	may need to fix that "var name = proc() {.closure.}" codegen / destructor issue to fix the async issue
18:46:12	shashlick	what's the difference between await and waitFor
18:46:21	disruptek	await is async.
18:46:44	rayman22201	await = one async wait for another async. waitFor = sync wait for an async (blocks)
18:46:45	disruptek	i still think the future has to own everything.
18:47:05	rayman22201	me too. But in order for the future to own a closure, the codegen better do the right thing.
18:47:24	rayman22201	"future.field = proc() {.closure.}" needs to work
18:47:56	disruptek	i think solving that is easier than a brittle rearch of the macro.
18:48:04	disruptek	or, i should say, more correct.
18:48:50	rayman22201	not mutually exclusive. both will be required
18:49:06	rayman22201	it can't be fixed purely at the language level
18:49:11	disruptek	i don't think async needs to be brittle.
18:49:19	shashlick	okay thanks
18:49:31	rayman22201	why would it be brittle?
18:50:00	disruptek	because there are cases where we play fast and loose with cursors that don't need to exist.
18:50:01	*	marmotini_ quit (Remote host closed the connection)
18:50:40	disruptek	anyway, that's my interpretation of some of the kitchen-sink solutions.
18:50:49	rayman22201	Here's the thing. async is a core macro. Most users will never write a future callback by hand. So fixing the macro will make it good enough for 95% of cases.
18:51:12	rayman22201	library authors and the std lib will need to be careful, but that is true already.
18:51:32	Araq	in addition to that
18:51:32	disruptek	this isn't a story i fancy retelling.
18:51:49	Araq	apps can use the cycle collector but Nim's core should work well without
18:52:33	disruptek	these aren't exclusive concepts, though.
18:52:41	rayman22201	does the cycle collector have a "debug" or "verbose" mode to give extra information about cycles it detects?
18:52:49	disruptek	sure.
18:53:02	rayman22201	I think that just needs docs and it will be fine
18:53:26	Araq	no the basic algorithm needs to be tweaked, currently it's stupid
18:53:47	Araq	but I want async to be free of cycles, it cannot be that hard
18:53:57	disruptek	that part doesn't matter; it can be as stupid as it wants in cycle-mode.
18:54:12	rayman22201	It is free of cycles. You did fix it araq. We just need to fix the lifetimes now
18:54:28	Araq	no, I got factors of 1000
18:54:30	disruptek	i think if you want to play dirty, you do that in a special cycle-free mode.
18:54:32	Araq	too slow for debug runs too
18:54:45	disruptek	ie. let orc break the cycles safely.
18:55:06	Araq	rayman22201, that means we didn't break the cycles properly :P
18:55:22	rayman22201	It's progress. baby steps :-P
18:56:22	Araq	please give me a gist with asyncSleep that shows the crash
18:56:38	rayman22201	see my irc log
18:56:41	rayman22201	I posted it
18:57:00	rayman22201	here is the patch: https://github.com/rayman22201/Nim/commit/39c1131a7d8f6d5b46d4aec78206f01a90b868f8
18:57:10	rayman22201	here is the test: http://ix.io/27RJ
18:57:48	rayman22201	I think the next step is to finally use "disposableFuture", which has fields to hold ownership of the closures.
18:58:09	disruptek	good.
18:58:13	FromDiscord	<Clyybber> So is there a compiler bug here or not?
18:58:23	disruptek	no yet imo.
18:58:52	FromDiscord	<Clyybber> and rayman thinks there is?
18:59:11	disruptek	i don't think anything thinks the impl is complete.
18:59:16	disruptek	s/anything/anyone/
18:59:22	rayman22201	there is. We are just doing too many things at once
18:59:37	disruptek	what do you think the bug is?
18:59:52	disruptek	i haven't seen anything not working correctly.
19:00:21	rayman22201	the bug is this: "proc myClosure {.closure.} = " correctly frees the closure, while "var myClosure = proc() {.closure.}" does not
19:00:55	Araq	of nkAsgn, nkFastAsgn:
19:00:55	Araq	if hasDestructor(n[0].typ) and n[1].kind notin {nkProcDef, nkDo, nkLambda}
19:01:10	Araq	is the suspicious logic in injectdestructors.nim
19:01:37	disruptek	i don't think you are managing the closure correctly; last patch i looked at the closure was a cursor.
19:01:50	FromDiscord	<Clyybber> Araq: Anything obvious wrong here?
19:01:55	Araq	sure
19:02:20	FromDiscord	<Clyybber> I can't see it..
19:02:20	Araq	it means we treat 'var x = proc ()' as a cursor
19:02:34	FromDiscord	<Clyybber> oh
19:03:04	Araq	I hacked this together to get some other test green :P
19:03:26	Araq	hopefully it's not required anymore
19:03:39	Araq	this code got quite some bugfixes afterwards
19:03:46	FromDiscord	<Clyybber> hehe
19:06:04	disruptek	turn off nameitervar as a closure and you get no leaks.
19:06:09	disruptek	sorry, cursor.
19:06:25	disruptek	tasyncawait.
19:06:31	rayman22201	We already got no leaks. It just had bad reads
19:06:42	disruptek	yes, no bad reads.
19:07:24	rayman22201	then you get leaks? This is what we established
19:07:35	disruptek	no leaks and no bad reads under --gc:arc.
19:08:20	shashlick	another async question - can you await within a top level waitFor
19:08:44	rayman22201	You can only await inside an async proc
19:08:46	disruptek	you can await in any .async.
19:08:59	Araq	guys, a gist please
19:09:13	disruptek	tests/async/tasyncawait.nim
19:09:25	shashlick	so when you call a proc which is async from isMainModule, how do you do it
19:09:34	disruptek	with waitfor.
19:09:36	rayman22201	waitFor
19:09:52	shashlick	okay so that was my question - the async stuff within the waitFor will still work as expected
19:09:54	disruptek	or, just `future = someproc`
19:10:15	disruptek	it'll work, but waitfor is sync.
19:10:36	disruptek	if you want it to run async, don't waitfor. just put the future somewhere where you can recover it later.
19:10:46	rayman22201	what modification did you do to the patch disruptek? I can't repro
19:11:25	rayman22201	you have to kick off the asyncEvent loop somewhere disruptek. And make sure the program lives long enough to complete the promise.
19:11:57	disruptek	yeah, that's his problem.
19:12:02	disruptek	he can drain/poll/whatever.
19:12:10	disruptek	var nameIterVar = iteratorNameSym
19:12:38	disruptek	if it's a cursor, the iterator won't live long enough.
19:12:47	rayman22201	but if it's not a cursor, it leaks
19:12:57	rayman22201	I literally just ran valgrind with no cursor and it leaks
19:13:11	disruptek	you're using malloc, right?
19:13:12	shashlick	what if the async proc doesn't return anything
19:13:14	rayman22201	yup
19:13:22	disruptek	okay, it will leak in malloc.
19:13:35	rayman22201	that's all that matters. nim alloc is sloppy
19:13:39	disruptek	shashlick: async procs all return futures.
19:13:40	*	dadada quit (Ping timeout: 265 seconds)
19:13:47	rayman22201	it will return Future[void]
19:13:54	disruptek	i'm saying we can fix that because we can diff it.
19:14:08	disruptek	but the logic is fine.
19:14:22	rayman22201	I disagree. There is a bug nim alloc
19:14:33	rayman22201	you can fix that, but that doesn't make the leak go away
19:14:33	disruptek	okay, what is it?
19:14:45	rayman22201	idk, why don't you diff it and find out?
19:14:46	disruptek	it's a bug that happens to let async work leak-free.
19:14:52	disruptek	with no corruption.
19:14:53	Araq	I have no updated macro so tasyncawait doesn't work for me
19:15:06	shashlick	so you can let x = asyncProc() and then runForever()?
19:15:07	rayman22201	araq, use my patch to see
19:16:42	rayman22201	shashlick, yes, but why even assign to x at that point? runForever() never returns.
19:17:19	Zevv	ok, I need advice again
19:17:31	shashlick	ok as long as async does what i expect
19:17:49	shashlick	right now even my single threaded version doesn't work so i'm debugging that - it fails the same way as the async version
19:17:53	shashlick	multi-threaded works though
19:17:57	Zevv	since the malloc counters now count all allocs/frees, it is hard to capture the right part to measure, and I get varying results over platforms. My counts at a ginven time do not match the counts on CI
19:18:11	Zevv	so I need to report them *after* nim is done
19:18:28	Zevv	so I need to put that in the codegen, and that is nasty stuff
19:18:52	disruptek	why can't you do this in the context manager?
19:19:25	Zevv	ok, what is the context manager
19:19:38	disruptek	insideThisBlockIwillCountAllocs:
19:20:13	rayman22201	disruptek, I don't understand. You seemed to agree with my "disposableAsync" design a bit ago, but now you disagree? based on what seems to me like buggy behavior (or at least unexplained differences in behavior) between alloc impls?
19:20:16	Zevv	nope, that does not add up. Some stuff gets destroyed after the block
19:20:44	disruptek	no, i still think that the future should get a rc'd ref to the iterator.
19:20:47	rayman22201	looking at the macro code from first principles, without the cursor, it cannot work correctly...
19:21:04	rayman22201	some magic in the allocator won't fix that. At best it hides it.
19:21:12	disruptek	well, my branch passes all the tests except for the traceback (in non-arc).
19:21:23	disruptek	and it passes --gc:arc for tasyncawait
19:21:50	disruptek	Zevv: use more than one block. lifting, remember.
19:21:54	rayman22201	the future must own the closure, not the other way around
19:22:00	disruptek	yes. agree.
19:22:13	rayman22201	then the closure cannot have an rc'ed ref
19:22:24	disruptek	"no, i still think that the future should get a rc'd ref to the iterator."
19:22:35	rayman22201	the iterator is also a closure!
19:22:39	disruptek	i know.
19:22:50	rayman22201	the rc implies ownership
19:22:51	disruptek	the future should own it. how else can i say this?
19:22:53	disruptek	yes.
19:22:54	disruptek	yes.
19:22:54	disruptek	yes.
19:23:00	disruptek	holy smokes dude.
19:23:12	rayman22201	then the iterator MUST NOT have an rc ref to the future
19:23:18	disruptek	correct.
19:23:33	shashlick	pushed my async update to px2 - same code can run in single threaded, multi-threaded or async modes
19:23:45	disruptek	what is px2?
19:23:45	rayman22201	rewind. I think I read what you are saying backwards.
19:23:48	shashlick	of course only multi-threaded works for connect tunneling
19:23:55	disruptek	rayman22201: agree.
19:24:12	shashlick	next gen https://github.com/genotrance/px written in Nim, leveraging libcurl
19:24:36	disruptek	i wonder if we can fix async exceptions in arc.
19:24:40	shashlick	with libcurl now, it will be able to go through any upstream proxy that libcurl supports, which is pretty much everything
19:24:57	shashlick	any of you stuck behind an NTLM or Kerberos proxy at work will relate
19:25:12	shashlick	NTLMAps / cntlm replacements
19:25:26	*	disruptek 🤷
19:25:56	shashlick	not you, you independent contractor you
19:26:21	shashlick	https://github.com/genotrance/px2 by the way
19:27:00	disruptek	Zevv: did that help?
19:28:26	rayman22201	disruptek, I still leak even with nim alloc https://www.irccloud.com/pastebin/zzKodoMt/
19:28:52	rayman22201	taking out the cursor
19:28:54	Araq	I really would like to help you
19:28:56	Zevv	disruptek: sorry, did what?
19:29:18	disruptek	Zevv: add more scope so when stuff gets lifted it doesn't leave your context.
19:29:21	Araq	but I can't, because you're sitting on an unpublished branch or something
19:29:27	disruptek	Araq: try my async72 branch.
19:29:36	Zevv	disruptek: you're pulling my finger, right?
19:29:36	rayman22201	https://github.com/rayman22201/Nim/commit/39c1131a7d8f6d5b46d4aec78206f01a90b868f8
19:29:50	rayman22201	I posted it 3 times araq
19:30:11	*	Trustable quit (Remote host closed the connection)
19:30:46	Araq	indeed but this is not how I want to work
19:31:00	Araq	yesterday you had some nice example that was easy to tweak
19:31:01	rayman22201	what do you need?
19:31:18	rayman22201	oh, I see. You want the expanded macro
19:31:18	Araq	I won't touch the macro until I'm sure what it needs to produce
19:31:29	disruptek	oi
19:31:31	rayman22201	I can produce this for you. stand by
19:32:12	Araq	and yeah, it's time to end this hacking around
19:32:43	disruptek	you told me to get tasyncawait.nim working without leaks.
19:32:48	*	jjido joined #nim
19:32:50	*	abm quit (Ping timeout: 240 seconds)
19:32:51	*	lritter joined #nim
19:32:53	Araq	disruptek, yes I did
19:33:01	Araq	and also without crashes :-)
19:33:06	disruptek	http://ix.io/27Vk
19:33:18	disruptek	it's hard to make it work any better than this.
19:33:27	Zevv	All heap blocks were freed -- no leaks are possible \o/
19:33:33	Araq	quite convincing.
19:33:41	Araq	what's the magic behind it?
19:33:50	Araq	the macro fix rayman22201 sent me?
19:34:21	rayman22201	and yet my simple example leaks?
19:34:33	disruptek	i'm not 100% sure, but we can diff my branch against ray's.
19:34:43	disruptek	i think it's just the nameIterVar not being a closure.
19:35:03	disruptek	i would rather narrow the debugging to the malloc/nimalloc diff.
19:35:30	Araq	disruptek, did you use -d:useMalloc with valgrind?
19:35:40	disruptek	no, useMalloc leaks.
19:35:48	Araq	gah...
19:36:01	disruptek	yes.
19:36:02	Araq	then your result is meaningless
19:36:14	Araq	valgrind only works with -d:useMalloc reliably
19:36:27	disruptek	but the point is that the lifetime is correct.
19:36:29	Araq	else valgrind doesn't understand Nim's allocator and reports "no leak possible"
19:36:51	disruptek	we aren't getting corruption because we are not prematurely freeing the closure.
19:37:02	Araq	yes and no.
19:37:21	Araq	if you never free memory you will hardly see any corruptions
19:37:34	Araq	corruptions are "use after free" bugs, most of the time
19:37:56	Araq	so if you leak and get no crashes, we don't know if the lifetimes are correct
19:38:03	Araq	most likely they really are not
19:38:04	disruptek	true. we do free, but maybe we don't free enough.
19:38:08	Araq	yup
19:38:15	rayman22201	https://play.nim-lang.org/#ix=27Vm
19:38:43	rayman22201	exactly what araq says.
19:38:53	rayman22201	disruptek, you are relying on faulty behavior and getting lucky
19:38:55	rayman22201	it's not a real fix
19:39:18	disruptek	maybe, but it won't work at all if we save a cursor to the iterator in the future.
19:39:20	rayman22201	the lifetime is still bad, it's just that the way mimalloc works, the memory happens to still be there.
19:39:50	disruptek	your disposableFuture needs a hard closure ref.
19:39:57	rayman22201	oh I see what you mean now! I agree! exactly
19:40:08	disruptek	finally 😁
19:40:09	rayman22201	we are on the same page
19:40:25	Zevv	bunch of amateurs!
19:40:32	rayman22201	your mimalloc stuff confused me "_P
19:40:48	rayman22201	:P
19:41:38	rayman22201	araq is that good enough or do you want me to minimize the example more?
19:41:39	*	jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:43:14	Araq	so, this version of yours doesn't crash but leaks memory. correct?
19:44:04	rayman22201	This one has bad reads
19:44:08	rayman22201	according to valgrind
19:44:14	rayman22201	it doesn't actually crash though
19:44:39	Araq	well on my machine it leaks and I don't run it via valgrind
19:44:52	Araq	because I'm on this loser OS
19:45:33	rayman22201	http://ix.io/27Vn
19:45:47	Araq	well
19:45:56	Araq	var nameIterVar_gensym400019 {.cursor.} = asyncProcIter_400016 # no owner? can't be right
19:46:11	disruptek	exactly.
19:46:14	rayman22201	agree
19:46:34	rayman22201	what's confusing is that it seems to be producing different behavior for different people
19:47:17	Araq	I "fixed it" via
19:47:17	Araq	var ownIter = asyncProcIter_400016
19:47:18	Araq	var nameIterVar_gensym400019 {.cursor.} = ownIter
19:47:22	Araq	but that's silly
19:47:43	Araq	the closure must own the iterator
19:47:59	rayman22201	why isn't the iterator def it's own owner?
19:48:16	rayman22201	just like "proc myClosure() {.closure.}" makes the current proc the owner.
19:48:46	rayman22201	doesn't "iterator asyncIter() {.closure.}" make the current proc the owner?
19:48:51	Araq	the example is bad because if I read it correctly
19:49:06	Araq	the callback is never attached to the Future we return
19:49:29	Araq	so we're looking at the wrong thing
19:49:40	Araq	some random closure that doesn't escape and must not leak
19:49:57	Araq	but in the real async it always escapes, it's put inside the future
19:50:12	Araq	please scream now if I'm wrong.
19:50:18	rayman22201	I don't understand
19:51:38	rayman22201	are you saying the "callback=" is never executed in this example?
19:51:52	rayman22201	that was the whole point of me putting the sleepAsync in there
19:52:18	Araq	apparently I have no clue
19:52:32	rayman22201	yeah. I just verified. the callback is added
19:52:36	*	Araq re-reads everything
19:53:42	Araq	gah this is a mindfuck
19:53:44	rayman22201	I see two ways to set it up. Have the Future own the closure cb, and the closure cb own the iterator. Or just have the Future own both the closure cb and the iterator directly.
19:53:53	rayman22201	I prefer the second option
19:54:30	Araq	but currently the future doesn't own anything, does it
19:54:39	rayman22201	no.
19:54:50	rayman22201	I think I just need to try to implement this crap I keep talking about
19:55:02	Araq	ok, so that's what I mean I guess
19:55:16	Araq	the freaking future doesn't own anything so this has no chance of working
19:55:26	rayman22201	I wanted to make sure there isn't anything I'm missing first
19:55:35	rayman22201	i.e. I put all the cursors in the right places
19:56:04	Araq	btw I prefer the option "Have the Future own the closure cb, and the closure cb own the iterator."
19:56:20	Araq	because an ownership hierarchy can't be bad
19:56:33	rayman22201	shallow vs wide tree :-P
19:56:42	rayman22201	vs. deep tree I mean
19:57:36	rayman22201	actually, your way saves a field on the Future, so I will try that first
19:57:44	*	ptdel quit (Read error: Connection reset by peer)
19:59:44	Araq	tbh I wouldn't mind some larger rewrites, this setup is super convoluted
20:00:02	Araq	and way more complex than it needs to be
20:01:14	Araq	but I complained about it when dom wrote it and he had some good argument like "your solution doesn't work at all"
20:02:13	*	kungtotte quit (Read error: Connection reset by peer)
20:02:58	rayman22201	I don't love it, but I'm afraid to make large changes to something that works
20:03:16	rayman22201	close to working anyway lol
20:03:32	*	ptdel joined #nim
20:03:32	*	kungtotte joined #nim
20:03:38	rayman22201	ok, so giving ownership of the closure to the Future still leaks. idk why
20:03:41	Araq	problem that I have with it: once it "works" it's still slow
20:03:59	Araq	so many allocations and closures
20:04:14	rayman22201	fair point. I would love to do something based on synthesis. Async really just needs to be a polling state machine.
20:04:41	disruptek	i really don't think it's that complex. you are both right. just put in the ref on the future and let's take the next step.
20:04:51	rayman22201	I just did it, and it's not working
20:04:59	disruptek	lemme see
20:05:03	rayman22201	I have to push my patch. working on it
20:05:07	rayman22201	stand by
20:05:11	disruptek	kk
20:05:29	dom96	Polling futures are likely the future, but we're stuck with what we have for the duration of 1.0
20:05:51	Araq	want to hear my wisdom after decades of debugging complex systems?
20:05:56	disruptek	having a hierarchy sounds better to me.
20:06:47	disruptek	i feel like with 5 people working on this, we spend every day taking two steps forward and one step back.
20:06:54	Araq	ok, nobody wants to hear my wisdom, too bad.
20:07:04	disruptek	Araq: don't ask to ask, just ask.
20:07:41	dom96	Something fun I noticed is that async await in Nim is now 6 years old.
20:07:50	rayman22201	ok, just pushed it to my branch: https://github.com/rayman22201/Nim/tree/arcify-async
20:07:54	disruptek	a better set of tests would help this.
20:08:00	Araq	dom96, we can add more vaporware to --gc:arc, like a mutated version of async
20:08:07	rayman22201	agreed. I added a few tests for my other async work, but we need more
20:08:28	Araq	like I did for 'repr' :P
20:09:08	rayman22201	oh, and the test. hold on
20:09:12	dom96	We need a testing framework for async, something which allows to test it without flakiness
20:09:29	Araq	dom96, but since you're here, do you remember what was wrong with my solution?
20:09:51	dom96	which solution?
20:09:51	rayman22201	https://play.nim-lang.org/#ix=27Vx
20:09:56	dom96	your leak fix?
20:10:04	Araq	dom96, no my async design
20:10:17	dom96	which one are you referring to?
20:10:20	Araq	before you wrote yours we discussed things
20:10:40	disruptek	ray, that doesn't work? i'm asking.
20:10:46	rayman22201	It didn't work for me
20:10:55	dom96	Araq, I don't recall what your design looked like
20:10:56	rayman22201	still leaks according to valgrind
20:11:06	disruptek	just in malloc, right?
20:11:20	rayman22201	I didn't check mimalloc.
20:11:46	dom96	bbs
20:11:47	rayman22201	mimalloc shows a leak still
20:11:56	rayman22201	extra Mem: 63208
20:12:12	disruptek	lemme diff my branch against yours.
20:12:41	rayman22201	kk
20:12:57	*	Vladar quit (Quit: Leaving)
20:15:15	rayman22201	I have to take off again. I'll be on mobile, but I won't be able to test stuff.
20:15:21	rayman22201	bbl
20:16:36	disruptek	oh this has all your dispose in it.
20:16:45	shashlick	how do you yield execution in async
20:16:59	disruptek	call another async proc.
20:19:42	shashlick	disruptek: i'm in this loop - https://github.com/genotrance/px2/blob/master/curl.nim#L194
20:19:53	shashlick	how do i release control so that another server connection can be handled
20:20:30	disruptek	asyncSleep(0)?
20:20:31	shashlick	also don't we have a stdout.flush() proc?
20:20:49	disruptek	i think there's something a little more special for this, but i cannot remember what i use.
20:20:53	rayman22201	wait
20:20:56	rayman22201	await
20:21:03	rayman22201	shashlick, await yields execution
20:21:18	disruptek	just plain `await`?
20:21:26	rayman22201	await some async proc
20:21:28	shashlick	i await asyncSleep(10) and it doesn't
20:21:35	Araq	dom96, basically we only deal with 'iterator (): FutureBase' in the dispatcher
20:21:38	disruptek	i know, but there's an idiom.
20:22:19	shashlick	it doesn't let another connection come in
20:22:21	shashlick	even if i do that
20:22:43	shashlick	connections come in here - https://github.com/genotrance/px2/blob/master/server.nim#L117
20:22:44	Araq	the dispatcher decides which iterator to resume based on which socket data is available
20:29:07	*	rockcavera quit (Read error: Connection reset by peer)
20:29:25	*	rockcavera joined #nim
20:29:25	*	rockcavera quit (Changing host)
20:29:25	*	rockcavera joined #nim
20:32:15	*	rockcavera is now known as Guest74317
20:32:15	*	tiorock joined #nim
20:32:15	*	Guest74317 quit (Killed (tolkien.freenode.net (Nickname regained by services)))
20:32:15	*	tiorock is now known as rockcavera
20:34:48	*	narimiran quit (Ping timeout: 260 seconds)
20:34:53	FromGitter	<zetashift> I tried compiling godot-nim with --gc:arc and quickly noticed I'm way out of my league here
20:40:46	FromDiscord	<DeltaPHC> I'm still not entirely sure of the relationship between newruntime, gc:arc, etc, other than they're intended to be stable for Nim 2.0. Or am I wrong?
20:41:14	disruptek	newruntime was an experiment that yielded gc:arc, expected to take over the world.
20:41:36	FromDiscord	<DeltaPHC> So no more newruntime, now all the work is in gc:arc?
20:41:52	disruptek	not really.
20:42:14	disruptek	i mean, yes, everyone is working on gc:arc but newruntime is not trash; most of it was instrumental in building arc.
20:42:45	FromDiscord	<DeltaPHC> Oh, I didn't mean in terms of quality. I just mean... what is intended to be used in the future
20:42:50	*	Hideki_ joined #nim
20:42:51	disruptek	gc:arc
20:43:00	disruptek	newruntime (maybe, if it matures further)
20:43:05	disruptek	gc:refc
20:43:07	disruptek	gc:orc
20:43:12	disruptek	gc:boehm
20:43:15	disruptek	gc:markAndSweep
20:43:18	disruptek	gc:none
20:43:30	disruptek	are you picking up what i'm layin' down, here?
20:43:31	FromDiscord	<DeltaPHC> What's the *default* going to be? lol
20:43:36	disruptek	gc:arc
20:43:39	FromDiscord	<DeltaPHC> Alright
20:45:08	FromDiscord	<DeltaPHC> Are scoped-based destructors going to be part of gc:arc?
20:45:23	disruptek	they are.
20:47:19	*	Hideki_ quit (Ping timeout: 268 seconds)
20:48:25	dom96	Araq, oh, you mean we get rid of `Future[T]` altogether?
20:49:17	dom96	shashlick, you should probably `asyncCheck` your `processClient` call
20:49:44	dom96	yeah... you're literally telling it to wait until processClient finishes before trying to accept other clients
20:55:35	*	jjido joined #nim
21:02:50	*	tane quit (Quit: Leaving)
21:04:33	shashlick	I see, I'll try that
21:04:40	shashlick	Thanks for the review
21:05:15	Zevv	so disruptek, is the leak fixed now?
21:05:18	rayman22201	disruptek any ideas from the diff?
21:05:51	rayman22201	Zevv, no 😭
21:06:37	disruptek	is there a reason we aren't doing this callbacklist stuff with recursion?
21:06:43	disruptek	it's pretty verbose.
21:06:47	rayman22201	I wonder if it's some codegen bug with closure assignment
21:07:04	rayman22201	that's a question for araq and dom96
21:07:34	disruptek	ima just rewrite it for my own edification.
21:07:35	dom96	if you're referring to what I think you're referring to then yes, there is a reason
21:07:37	dom96	check out the blame
21:07:42	disruptek	i did.
21:07:54	disruptek	it's "this is verbose but i dunno if i got it right"
21:08:02	disruptek	well, i know.
21:08:22	shashlick	Still don't clearly get await vs waitFor vs asyncCheck
21:08:46	disruptek	i think we should have a template that disarms closureRef that we use whenever we "finish" the future.
21:09:15	dom96	shashlick, my book has some nice explanations for these
21:09:24	rayman22201	I tried to make the closure assignment a move like this: retFuture_400014.closureRef = move(asyncProcNimAsyncContinue_400018)
21:09:25	rayman22201	but I can't because "error: 'asyncProcNimAsyncContinue_400018' is immutable, not 'var'"
21:09:43	rayman22201	and I can't make it mutable because of the codegen bug
21:10:57	rayman22201	disruptek, that is basically what "dispose" did. (The original experimental branch)
21:11:08	rayman22201	it disarmed the closure
21:12:42	rayman22201	note: "finish" of the future is sufficient, b/c it is a valid operation read a finished future multiple times. So it must be "lastReadOf(future) -> disarm(closure)"
21:12:57	rayman22201	"finish" *is not* sufficient
21:14:10	disruptek	but read just reads the value.
21:14:26	disruptek	am i missing something?
21:14:32	rayman22201	the value may reference the closure
21:15:39	disruptek	why is that a problem?
21:15:51	disruptek	the future will hold a ref to it. fine.
21:16:18	rayman22201	then it's not safe to disarm
21:16:30	disruptek	why not?
21:16:42	rayman22201	because there is still a ref pointing to it
21:16:48	disruptek	so what?
21:16:50	rayman22201	unless I misunderstand what you mean by disarm?
21:16:58	disruptek	disarm is `foo = nil`.
21:17:11	Araq	rayman22201, the codegen bug doesn't care about let vs var
21:17:25	rayman22201	right, but I can't generate either
21:17:58	rayman22201	technically I can only generate let
21:18:10	rayman22201	since that what "proc myClosure {.closure.}" amounts to
21:18:23	rayman22201	but that means I can't "move" it
21:19:27	rayman22201	disruptek: you might be right. disarm in the experimental branch actually called a free, there was no reference counting. with arc it might be safe to do it at the "finish"
21:19:48	disruptek	it's fine.
21:20:05	rayman22201	disarm used to be more dangerous :-P
21:20:20	rayman22201	I lost so many arms
21:21:57	rayman22201	araq, put another way, I want to do "future.closureRef = proc() {.closure.}"
21:22:19	rayman22201	but I can't do that right now, because "future.closureRef" gets treated like a cursor
21:27:36	Araq	feel free to patch the compiler
21:28:15	Araq	dom96, I'm not sure, in my head the Future is mostly a IO "request" that we yield to the event loop
21:28:39	Araq	but I remember this model being incompatible with IO completion ports
21:28:40	FromDiscord	<mfiano> Araq I made my first post on the forums in reply to a comment you posted earlier because I am extremely confused learning Nim (also looks like I'm moderated so only you can see it) 🙂
21:29:26	disruptek	ima clean up this linked-list stuff because it lacks confidence.
21:29:51	dom96	Araq, yes, on POSIX we ask whether the socket can be read, then we read it. On Windows we read it and get a notification when the read completes.
21:29:53	Araq	mfiano: I have no moderated posts in my queue
21:30:14	dom96	i.e. IOCP fits how async procs work in Nim
21:31:00	FromDiscord	<mfiano> Odd. It says I am moderated in my comment in https://forum.nim-lang.org/t/5836
21:31:33	Araq	ok, thanks
21:31:48	Araq	I made you a user and I'm awaiting your spam links
21:32:56	rayman22201	araq. I'm not familiar with that part of the compiler. where do I start?
21:33:39	Araq	injectdestructors.nim line 606
21:33:49	Araq	but I'm not sure anymore that it's wrong.
21:33:53	FromDiscord	<mfiano> Ha, most of my time is spent trying to understand what the compiler is thinking. The documentation says larger number types should never be converted to smaller types.
21:34:25	FromDiscord	<mfiano> I spent all weekend trying to understand these ~10 lines of code and other oddities...cross-referencing the docs and getting nowhere
21:34:28	Araq	yeah but floats are not numbers :P
21:34:52	FromDiscord	<mfiano> The docs uses floats as an example 🙂
21:35:02	Araq	really? yay...
21:35:32	Araq	the issue here is that float32 doesn't lose information, only precision
21:35:38	FromDiscord	<mfiano> > Automatic type conversion in expressions with different kinds of floating
21:35:38	FromDiscord	<mfiano> > point types is performed: the smaller type is converted to the larger. Integer
21:35:38	FromDiscord	<mfiano> > types are **not** converted to floating point types automatically, nor vice
21:35:38	FromDiscord	<mfiano> > versa. Use the `toInt <system.html#toInt,float>`_ and
21:35:39	FromDiscord	<mfiano> > `toFloat <system.html#toFloat,int>`_ procs for these conversions.
21:36:02	Araq	that's true.
21:36:27	Araq	it's about floats and ints, not about combining float32 with float64
21:36:45	FromDiscord	<mfiano> What it doesn't say is that a larger floating point type can be automatically converted to a smaller, losing valuable precision.
21:37:06	FromDiscord	<mfiano> I consider this a serious flaw, unless I'm misunderstanding the code I posted in the forum. Just changing the order has type instability
21:37:22	Araq	learn how to read
21:37:39	Araq	For further details, see `Convertible relation
21:37:39	Araq	<#type-relations-convertible-relation>`_.
21:37:48	Araq	and then in there it clearly says
21:38:00	Araq	proc isImplicitlyConvertible(a, b: PType): bool =
21:38:02	Araq	...
21:38:09	Araq	of float32: result = b in {float64}
21:38:09	Araq	of float64: result = b in {float32}
21:38:23	Araq	so the conversions happen both ways
21:38:34	FromDiscord	<mfiano> Ouch
21:38:40	Araq	now we can discuss whether the design is broken or not
21:38:50	Araq	but the documentation is good.
21:41:03	FromDiscord	<mfiano> I argue that any type instability resulting in loss of precision is bad. That's not normally how type contagion works in other languages, and any rounding by loss of precision is a form of data corruption. But I am not a compiler writer, so 🤷‍♂️
21:41:16	*	letto_ quit (Quit: Konversation terminated!)
21:42:02	*	letto joined #nim
21:42:41	Araq	I don't consider it a big issue tbh. float32 is used in the gaming domain where you look at the screen and say "close enough" and stick with 32bits for the speed advantages
21:43:35	Araq	in every other domain you use float64.
21:44:49	Araq	where are these domains where you need to watch out not to mix float32 and float64 so that your calculations are not off? why are there float32s to begin with?
21:45:50	Araq	and how can you detect it? if you convert it explicitly to float32 there is still no error detection going on
21:45:52	FromDiscord	<mfiano> There are a lot of physics computations that are best done with double-precision using a multiple of a machine epsilon to get numerical robustness...in the gaming domain.
21:47:36	Araq	here is what I expect to happen: "type mismatch: expected float32, but got float64". Programmers adds a 'float32(x)' conversion and curses the Nim compiler.
21:48:01	Araq	no thinking involved and the code is as quirky as before
21:48:26	Araq	but ok, at least it's visible in the code then
21:48:31	Araq	so I'll make the compiler emit a warning
21:49:04	FromDiscord	<DeltaPHC> Yeah, I think the argument is that it makes a difference whether the programmer *knows* when a loss of precision or information is happening
21:49:53	Araq	fair enough but the point remains: Now that you *know* it, it's still not detected/checked at runtime at all.
21:50:28	Araq	compare that with int8(x) which crashes at runtime.
21:51:57	FromDiscord	<gingerBill> My domain?
21:52:28	FromDiscord	<gingerBill> I'm a physicist so mixing 32-bit floats and 64-bit floats is a not a great idea. 64-bit floats everywhere except for rendering to a GPU.
21:53:42	*	Kaivo joined #nim
21:54:27	FromDiscord	<DeltaPHC> This isn't always a good solution (nor useful on GPUs), but there's also the less-popular fixed point numbers, if you want more consistent and predictable behavior
21:54:42	FromDiscord	<gingerBill> Sometimes 32-bit floats are stored to reduce memory but 64-bit floats are used in calculations.
21:54:52	FromDiscord	<gingerBill> Things get weird depends on many legacy systems.
21:57:09	FromDiscord	<gingerBill> And in many systems you will be using fixed point arithmetic or fixed precision arithmetic.
21:57:18	FromDiscord	<mfiano> Yes, numerical robustness is enough trouble as it is with floating point math. I am only arguing that the user should be aware of when there is automatic loss of precision, to save them some amount of trouble. Not if it should be an error, per se.
21:57:37	Araq	as I said, we'll fix it
21:58:56	*	ltriant joined #nim
21:59:21	FromDiscord	<DeltaPHC> At least it's not C/C++ where implicit int/float conversion happens. That's even more painful sometimes :P
22:00:48	FromDiscord	<gingerBill> That is just a nightmare.
22:03:06	donpdonp	why does echo now() show a timestamps and echo &"{now()}" shows nothing?
22:03:17	FromDiscord	<AGNiMA> please add a GitHub OAUTH token to your $NIMPH_TOKEN
22:04:26	FromDiscord	<AGNiMA> I've edit my .bash_profile with export NIMPH_TOKEN=<token> I also tried export $NIMPH_TOKEN=<token>
22:04:45	Araq	donpdonp, I don't know
22:05:21	donpdonp	"{now().`$`}" is a workaround.
22:06:35	Araq	and so is &"{$now()}"
22:07:18	donpdonp	o^O
22:08:13	dom96	!eval import strformat; echo(fmt("{now()}"))
22:08:15	NimBot	Compile failed: /playground/nim/lib/core/macros.nim(557, 1) Error: undeclared identifier: 'now'
22:08:23	dom96	!eval import strformat, times; echo(fmt("{now()}"))
22:08:28	NimBot	<no output>
22:08:48	dom96	!eval import strformat, times; echo(fmt("{Testing: now()}"))
22:08:51	NimBot	Compile failed: /playground/nim/lib/core/macros.nim(557, 1) Error: undeclared identifier: 'Testing'
22:08:58	dom96	!eval import strformat, times; echo(fmt("Testing: {now()}"))
22:09:03	NimBot	Testing:
22:09:11	dom96	how weird
22:09:22	Araq	quite a bug
22:09:58	*	jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:12:35	*	Hideki_ joined #nim
22:12:59	*	sagax quit (Ping timeout: 265 seconds)
22:17:27	lqdev[m]	Araq: I'm trying out ARC and I'm getting a hint: `passing 'chunk.file' to a sink parameter introduces an implicit copy; use 'move(chunk.file)' to prevent it` however in my case, I can't really move the thing nor copy it, I heard there's a `lent` but annotating my field with it doesn't seem to work, saying that `lent` cannot be used in this context. could you enlighten me on how `sink` and `lent` work?
22:19:33	Araq	why can't you move it? :P
22:19:53	Araq	but jokes aside, this warning needs to be tweaked
22:20:02	*	Hideki_ quit (Ping timeout: 240 seconds)
22:20:06	Araq	or maybe removed altogether
22:20:23	FromDiscord	<AGNiMA> anyone seen this from choosenim ? repository error: could not find repository from '/Users/xxxx/.choosenim/toolchains/nim-#devel/.git'
22:23:36	Araq	ah it's a "simple" times.nim bug
22:23:48	disruptek	agnima: export NIMPH_TOKEN=token should work. make sure you source .bash_profile to test it in your current session.
22:24:05	lqdev[m]	Araq: I can't move it because it actually needs to be copied, or better yet referenced from multiple tuples
22:24:27	lqdev[m]	I'd really like to not copy it in this case
22:24:39	*	rockcavera quit (Remote host closed the connection)
22:24:52	lqdev[m]	because there can be hundreds of those tuples at once
22:25:08	lqdev[m]	and they're not mutated
22:25:16	Araq	tuples are always copied
22:25:22	Araq	they are value types
22:33:24	FromDiscord	<AGNiMA> thanks @disruptek
22:43:21	*	seni joined #nim
22:45:23	*	solitudesf quit (Ping timeout: 272 seconds)
23:23:01	disruptek	so i'm catching up on bugs. async/arc... are we waiting for #12990 or what?
23:23:03	disbot	https://github.com/nim-lang/Nim/issues/12990 -- 3arc: C compilation error with imported global code using a closure iterator ; snippet at 12https://play.nim-lang.org/#ix=27Wm
23:23:28	*	NimBot joined #nim
23:47:53	*	icebattle quit (Ping timeout: 260 seconds)
23:54:39	*	leorize joined #nim
23:54:57	*	sekao joined #nim