<< 30-01-2018 >>

---

00:16:10	*	endragor joined #nim
00:20:17	*	couven92 quit (Quit: Good night)
00:20:40	*	endragor quit (Ping timeout: 260 seconds)
00:21:18	*	MJCaley joined #nim
00:37:16	*	SitiSchu joined #nim
00:38:45	*	S1t1Schu quit (Ping timeout: 264 seconds)
00:42:38	*	yglukhov quit (Remote host closed the connection)
00:42:44	FromGitter	<honewatson> @Quelklef maybe you could use concepts?
00:42:55	FromGitter	<honewatson> Instead of `==` you use `is`
00:43:17	FromGitter	<Quelklef> I thought `is` was for checking types?
00:45:33	*	MJCaley quit (Quit: MJCaley)
00:55:12	*	yglukhov joined #nim
00:59:45	*	yglukhov quit (Ping timeout: 248 seconds)
01:00:41	FromGitter	<honewatson> sorry missed the first part of your messages
01:09:37	*	endragor joined #nim
01:14:07	*	endragor quit (Ping timeout: 248 seconds)
01:18:10	*	rockcavera joined #nim
02:00:32	*	sz0 quit (Quit: Connection closed for inactivity)
02:11:59	*	tinAndi joined #nim
02:17:37	*	tinAndi quit (Ping timeout: 248 seconds)
02:20:38	*	radagast quit (Ping timeout: 252 seconds)
02:26:19	*	S1tiSchu joined #nim
02:29:53	*	SitiSchu quit (Ping timeout: 248 seconds)
02:33:10	*	chemist69 quit (Ping timeout: 240 seconds)
02:41:46	*	dddddd quit (Remote host closed the connection)
02:46:44	*	chemist69 joined #nim
02:57:18	*	endragor joined #nim
03:19:57	*	Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
03:44:01	*	radagast joined #nim
04:18:21	copygirl	Mhh this is strange..
04:19:03	copygirl	Picked up Nim after a little break again. I'm trying to use nim-glfw (https://github.com/ephja/nim-glfw), so I added `requires "nim-glfw >= 0.2.1"` to my .nimble file.
04:19:46	copygirl	It says "Installing [email protected]" when installing it the first time.
04:20:46	copygirl	And on the following builds, it keeps installing and downloading it again and again.
04:20:54	copygirl	`Prompt: [email protected] already exists. Overwrite? [y/N]`
04:22:21	copygirl	Additionally.. I don't seem to be getting the right version, or something. The source says the function is called `initialize`, but in my workspace it's apparently `init`? Also, `DefaultOpenglWindowConfig` is missing.
04:22:29	copygirl	I'm just generally confused right now.
04:29:39	copygirl	Same happens without specifying a version.
04:31:49	copygirl	I guess I may want to specify @#head or so..?
04:37:17	copygirl	Using `requires "nim-glfw#891dce3"` allows me to use the most recent, and get rid of the build errors, but somehow it still keeps redownloading and prompting me if it can overwrite it each time.
04:41:47	copygirl	I think I'll use the other glfw package.
04:43:22	copygirl	Well that has the same redownload+promt problem :/
05:40:18	*	radagast quit (Quit: radagast)
06:10:53	*	nsf joined #nim
06:49:41	*	xkapastel quit (Quit: Connection closed for inactivity)
06:50:02	*	smt joined #nim
06:56:53	Araq	copygirl: I think the build does wrong things :-)
06:57:26	copygirl	Araq: Which build?
06:59:23	Araq	sorry, misread. Try the latest Nimble version please.
06:59:37	*	gokr joined #nim
07:07:20	copygirl	Araq: I'm on 0.8.8 according to nimble --version.
07:07:29	copygirl	Should I grab it from git, or..?
07:08:06	Araq	0.8.8 should be fine
07:08:11	copygirl	Using nim + nimble packages from the official Arch repositories btw.
07:16:04	shashlick	snip can now create gists - should now be good to load a snippet posted here, quickly compile/edit/fix and then create a new gist to post back here
07:17:08	shashlick	will add ability to update existing gists next, feedback appreciated
07:29:01	Araq	copygirl: maybe you use the wrong nimble commands? :-)
07:29:33	copygirl	Just "nimble build"..?
07:29:56	copygirl	Like I cleared out my .nimble directory, run "nimble build" twice, and that happens.
07:30:20	copygirl	Maybe that's because the packages are called "nim-glfw" or so but install as "glfw"?
07:34:56	*	c0ntribut0r quit (Ping timeout: 256 seconds)
07:35:26	*	c0ntribut0r joined #nim
07:46:45	Araq	good point
07:52:25	*	cspar__ joined #nim
07:53:55	*	c0ntribut0r quit (Ping timeout: 260 seconds)
07:54:59	*	c0ntribut0r joined #nim
07:55:11	*	cspar_ quit (Ping timeout: 248 seconds)
08:30:54	*	derlafff quit (Remote host closed the connection)
08:31:19	*	derlafff joined #nim
08:34:10	*	Arrrr joined #nim
08:35:55	*	Vladar joined #nim
08:37:30	Arrrr	"Garbage collection was a mistak"- Andreas Rumpf
08:43:03	Araq	Arrrr: that is a misquote
08:44:47	*	c0ntribut0r quit (Ping timeout: 248 seconds)
08:45:26	*	c0ntribut0r joined #nim
08:48:22	Arrrr	Historical revisionism
08:48:38	Araq	but yeah, eventually I might say that. it's a weird model alien to how the most important memory safe systems work.
08:49:00	Araq	and by that I mean databases.
08:49:49	Araq	delete from foo where id = 80 // others still have access to it? don't care, the ID is not reused, clients will notice it's gone.
08:50:14	Araq	that means you can detect use after free bugs reliably. instead of turning them into logical memory leaks.
08:51:43	*	c0ntribut0r quit (Ping timeout: 248 seconds)
08:51:55	*	c0ntribut0r joined #nim
08:52:38	Araq	that's the solution that scales, GC is a fairy tale.
08:58:52	FromGitter	<Sud0nim> @Araq - just curious, in your future vision of Nim does the GC-less memory manage look more like C++ or Rust in terms of compiler strictness?
08:59:06	FromGitter	<Sud0nim> management*
09:00:42	Araq	https://github.com/nim-lang/Nim/wiki/Destructors
09:00:56	Araq	a good mixture of both C++'s and Rust's ideas.
09:04:35	*	gmpreussner quit (Ping timeout: 240 seconds)
09:04:38	Araq	I am in favour of C++'s model though for convenience. ("ok I got a 'use after move' error, so copy it instead, but don't nag me about it")
09:05:16	*	gmpreussner joined #nim
09:05:27	FromGitter	<Sud0nim> Thanks, that last line answered my question :)
09:06:41	*	endragor quit (Remote host closed the connection)
09:07:45	Araq	are you looking forward to it? :-)
09:08:59	*	yglukhov joined #nim
09:10:08	*	yglukhov quit (Read error: Connection reset by peer)
09:10:09	*	yglukhov_ joined #nim
09:10:42	*	yglukhov_ quit (Remote host closed the connection)
09:10:58	*	yglukhov joined #nim
09:16:48	*	c0ntribut0r quit (Read error: Connection reset by peer)
09:17:32	FromGitter	<Sud0nim> Eventually, yes! I am also learning Rust as I do want to dabble a bit more in real time systems (I work in financial markets), but I don't have any great love for Rust as a language. If Nim can gradually provide something similar to Rust in terms of RAII (but perhaps less strict), then I will really have found my dream language which I can do practically anything in. I guess I do have a desire for those safety
09:17:32	FromGitter	... promises, but would also be quite happy with something in-between the C++ and Rust to get a good level of productivity to safety.
09:18:12	*	c0ntribut0r joined #nim
09:19:03	*	arnetheduck joined #nim
09:19:57	*	skelett joined #nim
09:20:26	FromGitter	<Varriount> @Sud0nim What do you mean by RAII? That's more of a memory management technique for C++/C. It isn't really something that translates well across languages.
09:20:46	Araq	for me RAII is identical to destructors
09:22:07	flyx	C++ always coins the strangest terms for their concepts.
09:22:29	Araq	I also call it "scope based memory management"
09:22:33	FromGitter	<Sud0nim> OK maybe I used the wrong term, lifetimes/ownership and memory management based on scopes
09:22:48	Araq	not sure that that term is so underused
09:23:00	Araq	it's the rather obvious name.
09:23:45	*	endragor joined #nim
09:24:31	FromGitter	<Sud0nim> Essentially GC-less memory and resource management was what I was meaning @Varriount
09:26:04	FromGitter	<Varriount> @Sud0nim Hm. Well @Araq has plans for minimizing/removing the need for a GC.
09:26:45	FromGitter	<Varriount> Although I believe it's a rather bad misconception that "no GC == faster program"
09:27:32	FromGitter	<Varriount> (Not helped by the fact that most GCs or there are of the stop-the-world variety)
09:29:34	FromGitter	<Varriount> @Sud0nim You might be interested in @mratsim 's work, he's developing a tensor/vector library which uses cuda, opencl, etc
09:31:15	FromGitter	<Sud0nim> Yes, that is true - I am thinking mainly of situations where stop-the-world won't be possible rather than only for speed. My experience with Nim is that speed hasn't really been a problem
09:33:54	Araq	GC can often be faster than the alternatives if you have a GC with a bump pointer allocator at its heard
09:34:03	*	endragor quit (Remote host closed the connection)
09:34:10	Araq	it almost always uses more memory though
09:34:53	Araq	and doesn't work as well with file handles or anything that needs to be close()d
09:36:11	Araq	(typo, I meant "heart")
09:45:48	*	Arrrr quit (Ping timeout: 240 seconds)
10:15:42	*	dddddd joined #nim
10:29:07	*	BitPuffin joined #nim
10:34:38	*	endragor joined #nim
10:39:49	FromGitter	<mratsim> @Sud0nim @qqtop has some financial libraries for Nim, afaik he is a HK based fund manager.
10:40:10	*	endragor quit (Ping timeout: 260 seconds)
10:41:08	FromGitter	<mratsim> If you want to build further financial libs in Nim I can also help as I've worked in capital markets and private banking for a while (and passed CFA level 1).
10:41:18	copygirl	Araq: So, should I help look into the issue I was having, or..?
10:41:35	FromGitter	<mratsim> (failed CFA level 2 because I did too much data science last year)
10:46:33	Araq	copygirl: wait for dom96 please
10:46:48	copygirl	*nods* Will do.
10:48:55	*	pydsigner quit (Ping timeout: 260 seconds)
10:51:08	*	pydsigner joined #nim
11:06:40	*	radagast joined #nim
11:21:34	*	endragor joined #nim
11:38:25	FromGitter	<survivorm> @PMunch here?
11:45:38	*	tinAndi joined #nim
11:50:48	*	tinAndi quit (Ping timeout: 240 seconds)
11:54:20	dom96	hey copygirl! That's a Nimble bug, it's because nim-glfw was renamed to glfw. Nimble thinks you are trying to install a new package named 'nim-glfw' and only realises it's a renamed package that's already installed too late.
11:54:31	dom96	Workaround is to just depend on 'glfw' instead of 'nim-glfw'
11:55:41	copygirl	dom96: Happens with both packages though. nimrod-glfw and nim-glfw. They can't both be renamed.
11:56:25	radagast	Hello again. Suppose I have a data structure MyContainer[T] that can be composed of either DoublyLinkedList[T] or seq[T].
11:56:29	radagast	Now I do not want to make procs like newMyContainerFromLinkedList[T] or newMyContainerFromVector[T]. It looks very ugly. Is it possible to have an enum of containers so I can incorporate the underlying data structure into the type system? If so, can I see an example?
11:56:36	radagast	For example, newMyContainerFromLinkedList[T] turns into newMyContainer[T; LinkedList[T]]?
11:57:02	copygirl	dom96: And both packages appear under those names (nim-/nimrod-glfw) in the package list, not "glfw".
11:58:01	dom96	ahh, good catch
11:58:39	dom96	I blame the package maintainers then :)
11:59:06	Araq	radagast: don't accept the list version. problem solved.
11:59:18	dom96	Nimble should probably handle this case anyway though
11:59:28	Araq	DoublyLinkedLists are too slow anyway, nobody should use them
12:00:03	copygirl	How come nimble install the packages using the package name they specify instead of the one you install them as..?
12:00:43	radagast	Well, that was pretty straight forward :D I guess you do have a point. Having to underlying structures just adds to cognitive load.
12:02:26	dom96	copygirl: because the ultimate source of truth about the package is its .nimble file
12:02:46	*	Snircle joined #nim
12:04:36	dom96	copygirl: Thank you for your donation btw :)
12:04:58	copygirl	You guys are doing awesome work!
12:05:26	copygirl	And still being super responsive and stuff.
12:06:00	dom96	Thanks :D
12:06:20	dom96	I submitted an issue for this https://github.com/nim-lang/nimble/issues/453 :)
12:07:11	copygirl	Thank you!
12:08:03	copygirl	So the correct approach would be to PR to these repositories and set the names in their .nimble files to what they are in the package list?
12:11:12	dom96	The other way around. This should be done for both packages: https://github.com/nim-lang/packages#renaming-packages
12:13:19	copygirl	dom96: But they both want to be the package "glfw".
12:14:51	dom96	is one of them not glfw3?
12:16:29	copygirl	I think the package is glfw but the namespace (?) is glfw3.
12:17:52	copygirl	Both are wrapping glfw 3 it seems.
12:20:30	*	Yardanico joined #nim
12:28:48	*	floppydh joined #nim
12:29:34	copygirl	Another question, on code similar to this, I get the warning `Cannot prove that 'cfg' is initialized. This will become a compile time error in the future. [ProveInit]` - https://github.com/ephja/nim-glfw/blob/master/examples/minimal.nim#L5
12:31:06	dom96	copygirl: The namespace should match the package name
12:31:27	copygirl	This is how DefaultOpenglWindowConfig is defined by the way: https://github.com/ephja/nim-glfw/blob/master/src/glfw.nim#L500
12:32:01	dom96	I think the reason for that is that some of the fields are not initialised
12:32:10	dom96	Error message could really improve to state which fields.
12:33:24	*	solitudesf joined #nim
12:38:40	FromGitter	<mratsim> @radagast Agree with Araq, doubly linked-list are bad™. But you can do what you want with a static enum argument, and use "when yourEnum is DoublyLinkedList” to set what is inside.
12:40:14	FromGitter	<mratsim> or use object variant or conditional objectt field
12:40:43	FromGitter	<mratsim> https://forum.nim-lang.org/t/3150. I still recomment you keep it simple
13:20:18	*	solitudesf quit (Quit: solitudesf)
13:21:06	*	solitudesf joined #nim
13:24:22	*	salewski joined #nim
13:25:21	Yardanico	SIMD-accelerated base64 (maybe someone is interested): https://github.com/lemire/fastbase64
13:27:13	euantor	in my experience the only thing making the Nim stdlib bas64 slow is splitting it into new lines - I've used a modified version of it in the past without that and it was quite a lot faster
13:27:42	Yardanico	well I don't really understand why it splits it into multiple lines
13:28:15	euantor	one of the RFCs say that it should be split after X characters
13:30:14	Yardanico	hmm, did anyone notice than github slightly updated commit history page?
13:30:51	salewski	dom96, question about of github repository names for nimble package: Shoud it be github.com/StefanSalewski/RTree or github.com/StefanSalewski/rtree ?
13:31:11	dom96	It doesn't matter as far Nimble is concerned
13:31:13	Yardanico	salewski, I think it doesn't matter for nimble package, only package filename does
13:31:19	Yardanico	*package name
13:31:21	salewski	Most repositories seems to use only lover case names, but not all.
13:31:22	dom96	but for the sake of people cloning your repo I would suggest the latter
13:31:45	salewski	OK.
13:35:07	*	salewski quit (Quit: WeeChat 1.9.1)
13:44:09	*	solitudesf quit (Remote host closed the connection)
13:44:26	*	Zaidan joined #nim
13:44:57	*	Zaidan quit (Remote host closed the connection)
13:45:15	*	Zaidan joined #nim
13:45:40	*	Zaidan quit (Remote host closed the connection)
13:50:10	Araq	so ... did we really introduce &"{x}" because fmt "{x}" would have been too verbose?
13:51:00	*	nsf quit (Quit: WeeChat 2.0.1)
13:51:04	euantor	¯\_(ツ)_/¯
13:51:09	Araq	fmt"\n" vs fmt "\n" is 100% consistent with how Nim works.
13:51:28	Araq	oh ewll
13:51:49	Araq	eventually we shall have %"{x}" and then it makes sense
13:52:08	euantor	I'd have prefereed `fmt "\n"` personally, but I'm not overly upset about it
13:52:22	dom96	omg lol
13:52:48	FromGitter	<RedBeard0531> https://github.com/nim-lang/Nim/pull/7071 :)
13:53:34	Araq	oh a new term. "Lover case names"
13:53:53	*	solitudesf joined #nim
13:54:46	Araq	case "Anna": closed.
13:56:43	Araq	RedBeard0531: I have argued before (and still do) that this makes the rules harder to understand
13:56:59	Araq	maybe less error prone, but it's special casing things
13:57:14	*	xkapastel joined #nim
13:59:27	FromGitter	<RedBeard0531> I think it just makes fmt more of a DSL (like re) and less of a function. Then it feels like you are writing a "fmt-string" rather than a string you pass to the fmt macro. While the latter is what technically happens under the hood, I think users of the lib should be thinking in the former style.
14:00:17	FromGitter	<RedBeard0531> note that re"a\nb" doesn't treat that as a 4 char sequence a \ n b, but as a <NEWLINE> b
14:01:19	FromGitter	<RedBeard0531> I think fmt should feel more like that than a normal function
14:10:55	copygirl	`type mismatch: got (proc (_: GenericParam, size: GenericParam): untyped) but expected 'FramebufferSizeCb = proc (window: Window, res: tuple[w: int32, h: int32]){.closure.}'
14:11:25	copygirl	Trying to use a lambda with a callback function setter. Should this not be possible?
14:15:18	*	natrys joined #nim
14:27:51	Araq	copygirl: well it appears the compiler cannot infer the types so it sticks with generic params
14:28:44	copygirl	`window.framebufferSizeCb = (_, size) => onWindowResized(size[0], size[1])`
14:29:10	*	sz0 joined #nim
14:29:55	copygirl	I suppose can't infer it too well from an assignment? Probably works alright if it was a produce that took the callback as a parameter..?
14:33:47	copygirl	procedure*
14:35:16	Araq	yeah, no way it can infer this
14:35:36	*	yglukhov quit (Remote host closed the connection)
14:49:56	*	yglukhov joined #nim
14:58:58	*	zahary_ joined #nim
15:14:30	*	c0ntribut0r quit (Ping timeout: 256 seconds)
15:15:10	*	c0ntribut0r joined #nim
15:16:51	FromGitter	<mratsim> @copygirl instead of using the anonymous function from future use proc(something: T, some stuff: U): V = your statements
15:19:49	copygirl	@mrastsim: Yeah that's what I had before but I was hoping to use lambda syntax, thinking it would be able to infer the types properly.
15:28:27	*	yglukhov_ joined #nim
15:28:27	*	yglukhov quit (Read error: Connection reset by peer)
15:34:18	*	c0ntribut0r quit (Ping timeout: 240 seconds)
15:34:46	*	endragor quit (Remote host closed the connection)
15:34:46	radagast	While implementing a popFront(), is x = x[1 .. x.len() - 1] more efficient than x.delete(0) ?
15:35:16	*	c0ntribut0r joined #nim
15:40:59	Araq	no
15:43:59	*	c0ntribut0r quit (Ping timeout: 248 seconds)
15:45:16	*	c0ntribut0r joined #nim
15:53:37	*	c0ntribut0r quit (Ping timeout: 248 seconds)
15:55:07	*	c0ntribut0r joined #nim
15:56:41	*	salewski joined #nim
15:58:13	*	endragor joined #nim
15:58:16	salewski	radagast, I am missing a popFront() too. It was called shift() in Ruby, unfortunately it is O(n).
15:59:28	salewski	And I miss still even() and odd() for ints. But I have to admit that Rust also don't have them.
16:00:08	salewski	But me me i.even is easier to read then i mod 2 == 0
16:01:10	salewski	Maybe for seq's we should have alias s.last for s[^1] ?
16:02:41	*	gokr quit (Ping timeout: 248 seconds)
16:04:55	*	gokr joined #nim
16:04:57	*	solitudesf quit (Ping timeout: 240 seconds)
16:07:50	*	salewski quit (Quit: WeeChat 1.9.1)
16:09:21	*	floppydh quit (Quit: WeeChat 2.0.1)
16:14:09	*	c0ntribut0r quit (Ping timeout: 264 seconds)
16:14:57	*	c0ntribut0r joined #nim
16:16:06	*	miran joined #nim
16:27:36	*	smt quit (Quit: Leaving)
16:30:12	FromGitter	<alehander42> maybe we can have something like a "helpers" nimble package containing all kinds of similar often user-defined templates/procs/etc and eventually qualify stuff from it to the stdlib?
16:32:11	dom96	sure
16:34:12	dom96	We can even create it in the nim-lang team to give it a bit more official-ness
16:35:53	shashlick	is there any plan to sustain shipped Nim releases (back porting bug fixes) for some period of time? Or is it post 1.0?
16:36:24	*	salewski joined #nim
16:37:31	*	sz0 quit (Quit: Connection closed for inactivity)
16:38:16	shashlick	I was reading the recent reddit thread on the future of Nim and was thinking about what really defines 1.0
16:38:41	shashlick	I think 1.0 is a distraction, what people are really asking for is a stable release that will be sustained for a reasonable period of time
16:38:48	FromGitter	<Bennyelg> What do you say of changing "&" to "+" when concat strings ? ⏎ https://github.com/nim-lang/Nim/blob/devel/lib/core/strs.nim#L92 ?
16:39:23	dom96	shashlick: back porting bug fixes from what?
16:39:24	shashlick	If 0.17 will get bug fixes backported for 2 years, people can commit to a stable foundation. Experiment how much ever on HEAD and take 1.5 years to split out 0.18 and give the community 6 months to migrate and then EOL support on 0.17, but keep a stable branch that is alive and not just a snapshot in time. What it's versioned as is then irrelevant.
16:39:43	shashlick	In fact, if you call the next release 1.0 and follow this model and there's no pressure to fix everything before 1.0.
16:39:56	shashlick	I'm curious what you all think about this
16:40:08	dom96	Araq is pretty eager to start on v2, and whatever fixes are made there will be backported
16:40:11	dom96	I think that's the plan
16:40:33	dom96	I'll probably try to stop him from getting to v2 too quickly though
16:41:48	shashlick	then just release the next release 0.18, 0.17.4 as 1.0, create a branch and then let Araq have his way on HEAD
16:42:12	FromGitter	<Bennyelg> I also agree that v2 is too far away, just stick the current path
16:42:18	shashlick	any bug fixes made on HEAD can be merged into 1.0 and that can have a separate existence
16:42:29	FromGitter	<Bennyelg> unless you fixed a bunch of major bugs
16:43:21	shashlick	I don't think we should stop Araq from improving the language, but a separate effort should be made to have a stable language for a couple years, until HEAD is ready to split out again
16:43:27	*	yglukhov_ quit (Ping timeout: 240 seconds)
16:43:41	dom96	HEAD shouldn't have new features
16:43:47	dom96	well
16:43:49	dom96	breaking features
16:43:53	dom96	when we're post v1.
16:44:16	r4vi	the way python has added feature from 3.3 to 3.7 has been really nice
16:44:16	shashlick	in fact, I believe 1.0 should retain all deprecations so that anyone using pre-1.0 can still have mostly functioning code, deprecations should only be removed in 2.0
16:44:31	FromGitter	<Bennyelg> @dom96 new features are still can be created, till you can announce of a first version (a stable one)
16:44:56	shashlick	why should HEAD be stable? None of us should be using HEAD unless we are developing new features
16:45:17	dom96	it shouldn't be stable, but it should work towards the next v1 release
16:45:30	FromGitter	<Bennyelg> I agree
16:45:38	dom96	No, we should remove all deprecations at v1
16:45:53	FromGitter	<Bennyelg> When v1 released, than the head will be a different thing, but working thing.
16:46:09	shashlick	at this point, yes but once HEAD => 1.0, 1.0 should be a branch and HEAD should become 2.0 devel
16:46:35	dom96	why?
16:46:35	FromGitter	<Bennyelg> yes something like that
16:46:55	shashlick	if you want to remove deprecations in 1.0, it means 1.0 will be out at least a year
16:47:12	salewski	I still wonder: When Nim V1 and V2 will exist side by side for some time, will we then need two versions of many nimble packages?
16:47:16	shashlick	deprecations should last for an entire release cycle, not just a couple months
16:47:38	shashlick	salewski: ya, just like Python packages took time to support both versions
16:48:34	shashlick	the problem now is that Nim packges are often built against HEAD and that's not sustainable for regular developers
16:49:24	skrylar	I will confess i wandered off again from nim coding, and that's a concern i have had shashlick
16:49:28	*	Trustable joined #nim
16:50:00	shashlick	I don't think 1.0 is going to be perfect, in fact no release of any product is going to be perfect. That's why you have a separate sustaining branch that lives on and is maintained and non-breaking improvements are made, while future language dev continues on HEAD
16:50:12	skrylar	Have been reflecting on the objections made by people outside of small language circles, and there seems to be a consistent pattern: small languages are ignoring most of the objections, and it causes them to remain small
16:50:38	skrylar	One of such is a continued adherence to "just use HEAD" which plagues ex. Red. Well if you want people to use head then you are not really ready, and why did youmake a stable release?
16:51:25	skrylar	Ruby is much more stable but enterprises still have some (more manageable, now) objections, like the speed that Gems move
16:51:37	Araq	skrylar: I agree and I would release v1 tomorrow
16:51:50	shashlick	here's the statement on the Go releases page: Each major Go release is supported until there are two newer major releases. For example, Go 1.8 is supported until Go 1.10 is released, and Go 1.9 is supported until Go 1.11 is released. We fix critical problems, including critical security problems, in supported releases as needed by issuing minor revisions (for example, Go 1.9.1, Go 1.9.2, and so on).
16:51:59	FromGitter	<Bennyelg> :D
16:52:00	skrylar	Go is also unmanageable, though
16:52:06	shashlick	even if we have 1 stable maintained release of Nim for a couple years, it will make a big difference to mind share
16:52:16	dom96	starting work on a brand new version so soon is a mistake
16:52:19	FromGitter	<Bennyelg> @Araq This is a brainstorming Idea
16:52:25	dom96	Is Rust working on v2 already?
16:52:26	FromGitter	<Bennyelg> just release it and start fresh from now
16:52:39	skrylar	Go has a good internal release cycle, yes. They have a bad package management cycle. You just wire to git urls, which means ALL Go projects are in a perpetual state of using HEAD releases.
16:52:45	shashlick	skrylar: but at least they have some strategy and as a developer, I can standardize on 1.8 and sit there until I need to update
16:52:53	skrylar	see above
16:53:03	skrylar	go's core, yes stable and tick-tock. but dep management is hell
16:53:09	skrylar	I actually fixed Hugo on Windows. It was not fun
16:53:26	shashlick	skrylar: yes agreed, nimble at least has some versioning
16:53:32	Araq	that said, 0.17.2 is useful and stable
16:53:40	Araq	well reasonably stable.
16:53:50	Araq	problem is packages are not developed against 0.17.2
16:53:51	skrylar	gem bundles and npm and such have versions, go just uses head urls. i think you can now add tags though (as if anyone does)
16:53:54	Araq	but against devel.
16:53:59	dom96	The reasoning for telling people to "use HEAD" is due to lack of regular releases
16:54:01	skrylar	Good luck git-bisecting across 5 repositories with no version information :)
16:54:06	dom96	and the only way we can fix that is with more resources
16:54:10	shashlick	the main point I'm trying to make is that call what you have today as 1.0 and keep maintaining it in parallel
16:54:12	shashlick	deprecate in 2.0
16:54:22	dom96	starting work on v2 won't make that easy
16:54:25	skrylar	dom96, i don't think so. i used the stable just fine
16:54:29	Araq	dom96: actually we can enforce Nimble packages to not rely on git devel
16:54:45	shashlick	if you can make the official statement that 0.17.2 is now 1.0 and it will be maintained for 2 years, it will be great
16:54:58	shashlick	you can back port some new features and bug fixes but no breaking changes
16:55:05	Araq	I don't really want to, but I suspect I could.
16:55:24	Araq	but yes, the crucial word idea is "back port bugfixes"
16:55:30	skrylar	it's not so important that stable be alive for X years. what is important is that supporting assets are up to date
16:55:45	skrylar	I just poked around Pharo and they are failing hard at that
16:55:52	Araq	IMO v1 means bugfixes are back ported
16:56:03	skrylar	They actually wrote some books (good!) but they refer to outdated images with breaking changes (heinous)
16:56:08	shashlick	I believe having stable for a long period invites more commercial interest
16:56:18	*	yglukhov joined #nim
16:56:19	dom96	Changing HEAD to mean v2 will actually encourage people to use HEAD I think
16:56:22	skrylar	commercial interest rises out of noobs using the product and making useful things
16:56:51	dom96	and more importantly it will risk fracturing the community
16:56:53	shashlick	dom96: but then you give zero guarantee that stuff working today will work tomorrow
16:57:04	shashlick	it's development and only of interest to the core devs
16:57:12	shashlick	the community should commit to 1.0
16:57:23	dom96	the community should be allowed to add features to v1
16:57:29	Araq	no.
16:57:39	Araq	v1 is feature freeze what else should it mean
16:57:58	shashlick	dom96: yes as long as they are non-breaking and minor
16:58:10	dom96	what? It should mean there are no breaking changes
16:58:18	dom96	@ Araq
16:58:24	skrylar	if you ask me (and you didn't) then you can do whatever in a future X.Y as long as all the books and blog posts about X.Wildcard remain working
16:58:36	dom96	yeah
16:58:40	Araq	that's downright impossible with 'when compiles'
16:58:51	Araq	but it can be reasonably "no breaking"
16:58:57	shashlick	if you added 10 new functions to stdlib, sure you can back port it into the stable release - I guess this is more subjective
16:59:07	dom96	Araq: How so?
16:59:29	*	yglukhov quit (Remote host closed the connection)
16:59:37	Araq	when declared(macros.splat):
16:59:42	Araq	broken code
16:59:46	Araq	else:
16:59:49	Araq	echo "hi"
17:00:04	Araq	v1 adds 'macros.splat', code breaks.
17:00:09	skrylar	I recently tried to use Pharo's doc generator. Their pages lead to broken links, and the ones that work use outdated images. Once you finally do find a working link, it barfs SSL errors. And then installing on the working VM results in other errors from removed functions. That is exactly what a "stable" environment does not do :\
17:00:54	dom96	Araq: but... that's like saying: when NimMajor == 1 and NimMinor > 1: broken code
17:01:04	dom96	Why would someone speculate?
17:01:07	dom96	I don't get it
17:01:16	Araq	yes, so we need a reasonable definition of "no code breakages"
17:01:32	Araq	and we don't have one. so version 1 should be "backport bugfixes"
17:01:38	skrylar	sounds like you've re-encountered why clang has feature(xxx) prgmas
17:01:45	dom96	we'll come up with one for the version 1 release
17:01:53	dom96	That's one of the reasons a version 1 release is difficult
17:02:11	Araq	it's not difficult. you make it difficult.
17:02:11	dom96	There will be acceptable breaking changes
17:02:19	shashlick	I'll argue that as a normal developer, I am not interested in updating my compiler every few weeks. I want a stable platform that fixes bugs. Even updating every 6 months is expensive since I have to retest everything
17:02:19	shashlick	araq: that's a fair statement, until the language adds the ability, we live with that constraint
17:02:26	dom96	Like issues to do with security
17:03:06	Araq	more critically though
17:03:13	Araq	bugfixes can and do break code.
17:03:17	Araq	moreso than new features.
17:03:33	dom96	yeah, so saying "v1 is a feature freeze" doesn't make sense
17:03:42	dom96	I don't see how I'm making things more difficult?
17:03:43	shashlick	overall, all I'm trying to get at is #1 - stable release that lasts and #2 - get to #1 as soon as possible
17:03:46	*	yglukhov_ joined #nim
17:03:56	Araq	latest endevours about a[^1] have shown this again.
17:04:17	Araq	however, it's possible to make educated guesses.
17:04:25	*	endragor_ joined #nim
17:04:37	Araq	some bugfixes are obviously non-breaking
17:04:45	Araq	some are obviously critical.
17:05:04	Araq	my reimplementation of '^' was obviously critical.
17:05:11	Araq	and I wouldn't have done it for version 1.
17:05:13	dom96	yes, and if we make a breaking change that was unintended that's called a regression and we fix it in the next release.
17:05:14	skrylar	I found that it's not that hard to run Jenkins and a test suite against stable/unstable. Although uncertainty of features being removed/broken is more stressful than "did it accidentally break"
17:05:45	Araq	but still I don't want a version 1 where the stdlib is constantly growing
17:05:56	dom96	The main thing is that we don't say "Well, you'll have to fix your source code" unless the breakage is really important
17:05:57	Araq	just because it "doesn't break" things.
17:06:06	dom96	why?
17:06:28	Araq	because I also enjoy a promise about "bloat freedom"
17:06:39	skrylar	dom96, there can be an interesting cognitive situation if one isn't careful. i think someone counted pharo has 6,000 classes by default. Cuio has 600.
17:07:19	Araq	also, since we need to backport stuff to v1
17:07:20	dom96	skrylar: Is that considered bad?
17:07:25	Araq	why backport more than necessary?
17:07:31	*	couven92 joined #nim
17:07:34	skrylar	dom96, in the context of a noob programmer having to learn it all, yes
17:07:35	dom96	A lot of people seem to love the "battery-included" philosophy
17:07:45	*	endragor quit (Ping timeout: 248 seconds)
17:08:10	*	yglukhov_ quit (Ping timeout: 240 seconds)
17:08:11	Araq	if version 1 is not about perfection (and it is not), it should be about "hardly changing".
17:08:11	miran	for starters - just release the mythical v1.0
17:08:23	shashlick	if the core language and basic stdlib are stable then more of such development can happen in nimble packages which are tested with each bugfix update
17:08:27	skrylar	Battery inclusion is a choice of a distribution. The GHC platform for instance, includes many batteries. The GHC compiler does not
17:08:29	dom96	Araq: And just start releasing v2? bleh
17:08:33	Araq	excactly.
17:08:42	Araq	we have nimble packages to grow the library.
17:08:48	miran	there will be no 1.1, 1.2, etc?!
17:09:02	dom96	miran: I'm afraid of that too now
17:09:11	dom96	This whole conversation is really depressing
17:09:28	shashlick	as long as package designers are trained to target the stable releases and not head
17:09:32	dom96	"Lol, why use v1 when v2 is being worked on already"
17:09:41	skrylar	maybe i should go restart my old blog and just post about why microcommunities are failing at managing release schedules. lol
17:09:41	dom96	v1 will mean absolutely nothing and people will see that
17:09:43	miran	the main question (asked so many times) is - will there be 1.0?
17:10:06	shashlick	dom96: developers need to be trained to look at stable and most regular developers do that
17:10:34	dom96	if v1 remains stagnant people will have no faith in it
17:10:35	miran	1.1, 1.2, ... should be about improvements (and they should exist), 2.0 should be about big breaking changes
17:10:39	dom96	We need to invest time into it
17:10:48	shashlick	it's only contributors who are attracted to new features and are okay with the unstability of devel
17:10:54	dom96	That includes new features, not just backported fixes
17:11:17	dom96	There needs to be a balance. I'm not saying we should focus on v1 forever, but give it some love.
17:11:35	dom96	Until we see the real issues with 1.0 and can decide what 2.0 should be
17:11:35	shashlick	dom96: new features are always attractive to developers but you cannot afford to update your compiler every couple months
17:12:00	dom96	shashlick: Why not?
17:12:11	shashlick	no downstream project can sustain that unstability
17:12:12	shashlick	it's only fun projects that can sustain that
17:12:29	dom96	What unstability? It's new features which are guaranteed to not break things
17:12:46	shashlick	even my mini editor is now a lot of work to retest if I update the compiler
17:12:58	dom96	that's because Nim hasn't passed v1 yet
17:13:20	dom96	and the current release has the most breakage ever
17:13:28	shashlick	you cannot assume that as a developer that the latest download doesn't break anything, you still need to retest
17:13:31	shashlick	so that you can make that assurance to your customers
17:13:32	dom96	(on purpose!)
17:14:06	shashlick	I understand that backporting new features that are not breaking is a grey area and I'm quite open to the idea
17:14:27	shashlick	but at the same time, updating is not free for a developer
17:14:53	shashlick	he still needs to test to verify and not every project has extensive automated tests in place
17:14:58	dom96	That's true. But even bug fixes have a risk of instability.
17:15:44	shashlick	absolutely so most projects are conservative with tools, you don't change unless you absolutely have to
17:16:24	shashlick	and that's what people are really asking for - confidence that once they pick Nim, they are taken care of - there's stability with some assurance that if things are broken, they will be fixed and not pointed to HEAD which is too unstable for anything real world
17:16:30	FromGitter	<alehander42> but why would nim post v1 release new versions more often than once in 6 months anyway? currently new .<x> version come even less often
17:16:43	miran	i know working on v2.0 (while v1.0 is still not out!) is probably much fun, but the focus should be on those 1.1k boring open issues. IMHO
17:16:54	shashlick	There's still people using visual studio 6 or Python 2.x because they cannot justify the cost of updating and avoid change as much as possible
17:17:25	skrylar	well. there are things that need to be done and things that are fun to do
17:17:25	shashlick	miran: those open issues can be fixed as 1.0 progresses
17:17:59	miran	shashlick: some of those must be fixed before
17:18:42	miran	skrylar: well put
17:18:57	shashlick	most developers want to get things done and don't care what v2.0 brings, they are consumers, as I have been with Python for years now
17:19:09	dom96	when new releases of Python 2.x are released, they contain new additions to the stdlib
17:19:58	dom96	And I believe python 3.x was only begun during like the 2.7 era, no?
17:20:16	shashlick	I didn't ever care what new thing came out, I just used the language and got my work done, almost 95% of the world is like that
17:20:41	shashlick	but I like Nim enough to play with HEAD, I never did that with other langauges
17:20:54	*	endragor_ quit (Remote host closed the connection)
17:21:30	*	endragor joined #nim
17:21:38	shashlick	again, I'm open to stdlib improvements in point releases, that's a philosophy discussion between you and @araq :)
17:22:15	dom96	The time between major Python release is around 7 years
17:22:43	dom96	Okay, well, I do agree that it is a philosophy discussion
17:22:53	dom96	My main concern is about moving to v2 development too early
17:23:22	miran	what will happen if nim gets more users with v1.0? the number of open issues will probably quickly rise to 2k, 3k, and more. and what will be the solution? telling people "wait couple of years, this might get fixed in v2.0"?
17:23:47	shashlick	then maybe v2 stuff happens in a separate branch and not HEAD which should target the next bug fix release
17:23:53	dom96	yeah
17:24:02	dom96	That's what me and you were arguing about as far as I can tell
17:24:11	dom96	HEAD should track the next 1.x release
17:24:35	dom96	v2 can be developed in some separate branch
17:25:25	dom96	Now about the philosophy of whether to start v2 development immediately or not, there are two options which I see as the Python route and the Swift route.
17:25:35	dom96	Swift is pushing out major releases really quickly
17:25:58	*	endragor quit (Ping timeout: 256 seconds)
17:26:08	dom96	Swift 2.0 was released a year after Swift 1.0
17:26:21	Araq	Swift is an exception
17:26:29	Araq	we should use Python's model
17:26:43	dom96	Really? I would have thought you'd want the Swift model
17:26:44	miran	i think it is a question of focus. and i agree with Araq that new features for v1.x shouldn't be the focus. the focus should be bugfixes!! (and not v2.0) again IMHO
17:27:05	dom96	miran: of course, but we shouldn't forbid new features in 1.x
17:27:13	skrylar	swift is also an abomination >:(
17:27:35	shashlick	honestly, I feel @araq and other core developers should have the space (separate branch) to do what they want, no doubt they focus on what needs to get done but there should be space to research and investigate and productise
17:27:39	dom96	skrylar: how so?
17:27:49	Araq	ok, well we can add features and have v1.1 obviously
17:27:55	skrylar	dom96, they're trying to pull people closer to Java away from Smalltalk
17:28:02	Araq	but that essentially means 3 not 2 branches
17:28:08	Araq	so even more work for us.
17:28:15	*	a_chou joined #nim
17:28:20	Araq	which is why I don't get why you are so keen on it.
17:28:27	*	a_chou left #nim (#nim)
17:28:34	Araq	so we have v2 branch (devel?)
17:28:39	Araq	v1.0.x branch
17:28:44	dom96	skrylar: huh, you mean it's an abomination in how they're marketing it?
17:28:46	Araq	v1.1.x branch
17:28:54	Araq	Python does that and I'm fine with it
17:28:55	*	tinAndi joined #nim
17:28:56	skrylar	dom96, i mean i don't like any of tim cook's crap
17:29:17	dom96	skrylar: That's pretty subjective
17:29:50	*	a_chou joined #nim
17:29:57	dom96	It's nice to hate on Apple but I'm curious about objective reasons why Swift isn't a good language.
17:30:21	skrylar	It's not that I hate Apple. It's that I don't think abandoning Smalltalk is a good idea
17:30:31	Araq	shashlick: I prefer to hide new features under a switch like --newruntime instead of branches. I don't recall introducing problems with this approach
17:30:31	shashlick	araq: I think there's one 1.x.x branch = bugfixes which roll second x, and features which depending on size rolls first x
17:30:53	Araq	but that's somewhat offtopic, maybe.
17:30:54	miran	dom96: about new features - i would say: take one year to fix as many bugs as possible, and in that time listen to your users (whose number might increase with v1) and their needs - that way you can create a list of most wanted features
17:30:54	FromGitter	<alehander42> who has abandoned smalltalk :O apple never really used it
17:31:00	dom96	Araq: Yes, well, I'm not sure we have to stick to this v1.0.x and v1.1.x separation
17:31:04	skrylar	objective-c is a compiled descendent thereof
17:31:08	*	a_chou_ joined #nim
17:31:18	Araq	it's what gcc and clang do, --std-c99
17:31:19	miran	it is the thing mentioned on the reddit - nim currently wants to be too many things
17:31:26	*	a_chou_ quit (Client Quit)
17:31:45	dom96	miran: I agree
17:31:50	Araq	I don't.
17:31:50	*	a_chou quit (Client Quit)
17:31:56	FromGitter	<alehander42> objective-c was a mess
17:31:57	Yardanico	https://www.reddit.com/r/nim/comments/7smw81/nim_future/dt62s28/
17:32:06	shashlick	1.0.x vs 1.1.x is what HEAD becomes depending on the contents
17:32:20	dom96	shashlick: yep
17:32:22	Araq	"wants to be too many things"
17:32:27	Araq	doesn't mean anything.
17:32:38	Araq	Scala wants to be too many things.
17:32:41	skrylar	dom96, it's going to be a hard writeup because smalltalk/lispers and the c/c++ type people wnat different things
17:32:43	Araq	Swift wants to be too many things.
17:32:47	Araq	C++ wants to be too many things.
17:32:51	Araq	D wants to be too many things.
17:32:55	dom96	shashlick: Does the release have only bug fixes? Yes -> 1.0.x, no -> 1.1.0
17:33:08	Araq	that's just a way of saying "it supports many things".
17:33:35	Araq	Golang can compile to JS.
17:33:38	skrylar	dom96, it's going to be a hard writeup because smalltalk/lispers and the c/c++ type people wnat different things
17:33:42	skrylar	what
17:33:44	Araq	"Go wants to be too many things"
17:33:47	skrylar	that's not what i typed in *kicks irc*
17:34:06	*	a_chou joined #nim
17:34:07	skrylar	anyway i disagree that infix notation is bad, and one of the "wins" people claim with swift is that it looks more like C
17:34:11	skrylar	looking more like C is not an advantage
17:34:41	Araq	"Kotlin native"? omg, it wants to be too many things.
17:35:00	*	a_chou left #nim (#nim)
17:35:36	Araq	"Linear types for Haskell"? omg, it wants to be too many things.
17:35:59	miran	Araq: those languages have are in post-v1.0, nim is still in 0.x version
17:36:10	Araq	we can fix that.
17:36:23	skrylar	dom96, i might be willing to say Objective-Rust was a good idea, because itm ight be, but we'll never see it
17:37:06	dom96	btw my "I agree" was in reference to the earlier comment by miran :)
17:37:15	miran	Araq: renaming 0.18 to 1.0, and then just working on v2 will not fix that ;)
17:37:33	Araq	for me it will.
17:37:35	dom96	Although I do think our focus is spread a little too thin. But again, there is a blanace.
17:37:38	dom96	*balance
17:37:52	dom96	We could have ended up with Go if we went the other way :)
17:37:52	miran	for (potential) users will not
17:38:06	skrylar	go is fine
17:38:08	dom96	Generics? You're trying to be too many things!
17:38:37	*	tinAndi quit (Ping timeout: 265 seconds)
17:38:39	skrylar	honestly i would rather have something like Terra
17:38:46	Araq	miran: why not? bugs are bugs, it's bad we have so many, but it's unrewarding to just fix bugs for months and years.
17:39:15	Araq	the choice is rarely between "new features" and "bug fixing"
17:39:16	miran	unrewarding? as in boring, or?
17:39:20	shashlick	dom96: sorry to disrupt this conversation but i'm not sure doing bug fixes on HEAD makes sense
17:39:23	skrylar	they have a little demo of terra emulating C++ and Go interfaces in like, <200 lines of lua
17:39:42	skrylar	then if you want generics you just shove them in
17:39:43	shashlick	cause when 2.0 branch is ready to go, you need to merge all of it into HEAD, then where do you maintain the 1.x branch
17:40:01	skrylar	anyway, time to womble
17:40:05	Araq	the choice is between "New features" and "play some game" or "watch TV"
17:40:13	miran	Araq: it took so many years for nim to come to v1, i don't see why spending a (single) year on bugfixes would be a bad choice
17:40:41	Araq	bugfixes are constantly arriving.
17:40:52	Araq	and they are burning us out.
17:40:58	shashlick	dom96: best is to have unstable = HEAD and branch out for releases and maintain on those branches with appropriate tags
17:41:09	Araq	a single year on bugfixing and I would kill myself.
17:41:10	miran	Araq: but bugs are arriving at higher rate. and with more users, they will arrive even quicker
17:41:26	Araq	it's the nature of open source. :P
17:41:43	miran	Araq: any possibility to have more "core" devs, except you and dom96?
17:41:44	salewski	Maybe just release 1.0. When it brings many new users, it may bring much more money for bountysource, so you can hire developers to fix the 1000+ bugs. And Araq can work on 2.0. When V1.0 brings no more users -- well then Araq can work on 2.0 too.
17:42:04	shashlick	miran: I agree some bugs absolutely have to be fixed, but all said and done, the reality is that this is not a paid gig so if it smells like a day job without pay, we'll lose core developers
17:42:38	miran	shashlick: on the other hand, if you lose users, who are you developing for?
17:42:38	Araq	we will hire developer(s) for bugfixing, yes
17:43:03	miran	Araq: nice to hear
17:43:20	shashlick	salewski: that's why I think it is crucial to have a stable release, it will have known issues which will get fixed over time, but tracking bugs against HEAD is a lost cause
17:43:56	FromGitter	<data-man> @Araq: After FOSDEM? ;)
17:44:10	shashlick	cause there's new stuff added and the issues keep piling up
17:45:32	shashlick	first effort is to pick a date when stable is branched out - when araq and dom96 are happy with the state of affairs
17:45:42	shashlick	next verify which of these thousands of issues actually exist on this branch
17:45:53	FromGitter	<andreaferretti> I have to say that Nim is remarkably stable anyway
17:45:58	Araq	skrylar: Terra is cool but too tedious to work with in practice, afaict
17:46:06	shashlick	fix as many high priority ones
17:46:21	FromGitter	<andreaferretti> I have like twelve libraries and I only had to update a few easy lines between 0.17 and 0.18
17:46:30	shashlick	remove deprecations as much as reasonable
17:46:33	shashlick	and then ship 1.0
17:46:38	FromGitter	<andreaferretti> due to `<` being deprecated
17:46:48	miran	"when araq and dom96 are happy with the state of affairs" --> that might be not before v2 :D :D
17:46:51	shashlick	if you don't branch out for 1.0, you will keep working on HEAD with new and bug fixes together and it's a moving target
17:46:52	Araq	andreaferretti: and you use concepts and static[T]. remarkable indeed :-)
17:48:13	shashlick	miran: haha :)
17:48:54	shashlick	anyway, lots of ideas but I'm ready to help in any way when it comes to such release management stuff
17:51:02	dom96	keep in mind that Nimble needs to reach v1 as well
17:51:11	dom96	but I think that might happen separately
17:51:36	shashlick	so is there any agreement on when deprecated stuff goes away?
17:52:10	dom96	Araq's rule is after two releases IIRC
17:52:19	dom96	But IMO at 1.0 we should just get rid of all deprecated symbols
17:52:34	Araq	that's one thing I don't care about at all, sorry
17:52:35	shashlick	how big an effort is that you think?
17:52:41	miran	semi-related: rust 2018 roadmap, and users' comments: https://www.reddit.com/r/programming/comments/7ty23x/rust_2018_roadmap/
17:52:41	Araq	remove them, leave them in
17:52:51	Araq	I don't care.
17:53:06	dom96	shashlick: pretty big, because we'll have to fix the stdlib to not use these deprecated symbols
17:53:35	dom96	on the other hand...
17:53:50	shashlick	at my work, we leave in deprecated stuff for several years since customers depend on it
17:53:53	dom96	maybe it would be nice if when the new wave of people using v1 come in that old code still works
17:54:00	dom96	even if it does use deprecated procs
17:54:15	shashlick	given Nim is still not 1.0, you could get away with removing it
17:54:18	miran	fixing those deprecated stuff should be easy, right?
17:54:30	shashlick	but if the effort is huge, then deprioritize it
17:54:36	FromGitter	<adamrezich> speaking of deprecated symbols I just pulled after not using nim for months and is it just me or is basic2d gone?
17:54:53	shashlick	I feel all deprecated stuff should stay in through 1.x
17:55:05	dom96	miran: it's easy, but boring
17:55:30	dom96	we have been keeping deprecated stuff for far too long though, there are still deprecations from 4+ years ago
17:55:31	Araq	adamrezich: It's in a nimble package now iirc
17:55:34	*	tinAndi joined #nim
17:55:34	shashlick	it should slowly get cleaned up as part of the process of getting to 2.0
17:55:47	shashlick	if you remove it now, 1.0 will have a bunch of libs that don't work
17:55:48	miran	dom96: that's great to leave for somebody else to do it, while you and Araq focus on more important stuff
17:56:02	Araq	Yardanico wants to do it already :-)
17:56:33	miran	i'm all for cleaning as much as possible before v1.0 - see python 2vs3 neverending story
17:56:41	shashlick	I'm just trying to prioritize getting to 1.0, deprecation isn't something worth delaying in my mind
17:57:02	Araq	speaking of which
17:57:09	Araq	can we deprecate macros.callsite?
17:57:29	Araq	it's suprisingly hard to support in the compiler (1% of runtime afaict)
17:57:44	miran	shashlick: and if you remove it later, 2.0 will have a bunch of users with "but i've been using it like that since v1.0 and it all worked"
17:57:54	Araq	and it's now covered by 'varargs'
17:58:11	Araq	miran: so? it always warned about it
17:58:12	FromGitter	<adamrezich> Araq: awesome thanks, it'd be nice if that was reflected in the docs :>
17:59:13	shashlick	miran: no escape, but they got called out on every compile when they were coding - deprecation spits out warnings on compile right?
17:59:22	Araq	yup.
18:00:06	miran	shashlick, Araq: if Yardanico wants to clean it now, i say - why not :)
18:00:13	shashlick	can expand the message stating that it will be removed in the next major release so recommended to not use it. also having an alternate mechanism part of the message would be nice (if not already)
18:01:06	*	tinAndi quit (Ping timeout: 256 seconds)
18:02:13	Yardanico	miran, well IMO we can remove stuff which was deprecated for 1+ years
18:02:18	FromGitter	<mratsim> A year on bug fixing? Yeah if your sponsor is Oracle or SAP :P, that’s boring otherwise. People are inspired by vision, entreprises by stability. Do you want to attract people or entreprises
18:02:38	shashlick	miran: my only concern is all the libs out there - if they don't work due to removal, we will have a 1.0 with a bunch of broken libs
18:02:52	Yardanico	shashlick, we can fix them by PRs/forking
18:02:52	Araq	mratsim: ideally both.
18:03:02	Yardanico	nimble takeover is not the best thing, but it's here for these cases
18:03:15	Araq	shashlick: we will have a v0.18 with a bunch of broken libs
18:03:21	FromGitter	<mratsim> @shashlick, nimble packagescan require nim=0.17.2
18:03:22	Araq	how do you like that?
18:03:30	Araq	;-)
18:03:31	FromGitter	<mratsim> packages can*
18:04:19	miran	shashlick: if they didn't fix deprecated stuff already, that means they are unmantained. and will be unmantained proably also when a next major release comes up
18:04:26	shashlick	but as part of 1.0, we'd need to check all popular libs anyway so might not hurt either way
18:04:28	shashlick	I'm fine either way
18:05:06	Yardanico	well you know some developers are not developing their projects but they accept PRs: https://github.com/ziotom78/parsetoml/commit/4bbaa96bfadc90743bf7a6c39ef2b8044bebd0b5
18:05:08	Yardanico	(just an example)
18:05:23	miran	and it is better to replace such libs now than later
18:05:24	shashlick	araq: 😀
18:06:00	Araq	that's true (about the unmaintained modules) but it's also nice if you can just use old stuff knowing that it keeps working anyway
18:06:18	FromGitter	<mratsim> —> choosenim
18:06:20	shashlick	sounds good, so are we all ready to deprecate for 1.0?
18:06:21	Yardanico	Araq, well yeah, nobody will argue with that :)
18:07:48	miran	@mratsim "Do you want to attract people or entreprises" -> do you want a language for small weekend project or for something more than that too? ;)
18:08:38	Araq	any opinions on "callsite"?
18:09:22	Yardanico	133 code results on github
18:09:24	Yardanico	https://github.com/search?q=language%3Anim+callsite&type=Code&utf8=%E2%9C%93
18:09:34	Yardanico	most of them are nim repo forks
18:10:03	Araq	ok, it's doomed.
18:10:25	shashlick	so here's what I have so far for next steps on 1.0 and some release process
18:10:27	shashlick	https://gist.github.com/genotrance/4e4158909972617082dc223b2bb0b2f0
18:10:30	shashlick	please review and comment accordingly
18:10:59	dom96	Araq: Make an issue about it instead of giving a small sample of people here 5 minutes to answer...
18:11:54	Araq	"Nim progesses too slow" - "Make an issue about that so that we can have a long discussion about it"
18:14:49	dom96	Don't be silly
18:17:30	Araq	shashlick: "Evaluate all issues and verify if still valid, prioritize major bugs"
18:18:38	Araq	if I review 20 bugs each day (and I don't...), it takes 55 days to do just that.
18:18:48	*	icebattle joined #nim
18:20:14	FromGitter	<adamrezich> does anyone have the windows x64 sdl_gfx.dll? trying to get sdl2 working in Nim on x64 and the only binary on the internet seems to be an expired link on the nim forums
18:20:34	Araq	which is exactly why these big ideas about v1 (TM) cannot work.
18:20:47	Araq	"review the whole stdlib and make it consistent"
18:21:06	Araq	is another of these grand ideas.
18:21:58	Araq	"ensure the documentation is up to date everywhere". same.
18:22:01	shashlick	araq: from what I've seen, many of the issues don't have any steps to reproduce or details or any agreement on what a fix should be (noob point of view)
18:22:15	Araq	"ensure the important libraries all work with v1"
18:22:17	Araq	same.
18:22:31	shashlick	what I meant by that is all high priority issues are fixed - how that is decided is up to you
18:22:37	Araq	"ensure tests are green for all major OS/C compiler configuations". same.
18:24:01	shashlick	ok, let me ask a different way, what do you think needs to be done for you to say 1.0 is ready to ship
18:24:02	Araq	it's not that we don't know what real quality would look like. it's unreasonably expensive to get it for a project of Nim's scale.
18:25:17	shashlick	absolutely, and that's my position too, you could release 0.17.2 as 1.0 and build on that, there will always be open bugs but have to create some foundation
18:27:20	shashlick	just trying to understand your definition of ready to ship, accordingly we can plot a roadmap
18:28:08	FromGitter	<zetashift> @adamrezich I got one!
18:28:19	FromGitter	<zetashift> Compiled it last weekend for the same ends hehe
18:29:15	*	yglukhov joined #nim
18:29:16	Araq	shashlick: as my todo says, "high priority" bugs, "regressions" and "showstoppers"
18:29:39	FromGitter	<adamrezich> @zetashift got a link or something? :D
18:29:42	Araq	though some regressions can be closed as "yeah, it now works as documented"
18:30:47	shashlick	araq: is it fair to say this list is mostly known?
18:30:59	Araq	the issues are tagged
18:31:35	dom96	in particular high priority + stdlib issues are what I'm focusing on right now
18:31:38	FromGitter	<zetashift> @adamrezich on it, I wasn't sure if you already had on
18:31:49	Araq	though tbh I stopped marking bugs as "high priority" as it just means "v1 never ships"
18:32:20	shashlick	do we need to limit them somewhat to make it more achievable?
18:33:18	*	yglukhov quit (Ping timeout: 240 seconds)
18:33:58	Araq	the ones that are marked need to be fixed or downgraded to "medium priority"
18:34:07	FromGitter	<zetashift> @adamrezich https://www.dropbox.com/s/ck9gwkyety1h6vm/SDL2_gfx.dll?dl=0
18:34:19	shashlick	updated the gist
18:35:35	shashlick	so two options - branch 1.0 right away, remove deprecated and fix issues and backport to 1.0 branch
18:35:53	Araq	another thing I want to do:
18:36:01	shashlick	OR no more new features on HEAD till remove deprecated/fix issues, then branch out
18:36:20	Araq	- review the special typing rules for template/macro that is not documented anywhere and see if we can remove it
18:36:23	shashlick	obviously former gives more freedom but is more work
18:36:42	Araq	- special typing rule for unification for basic arithmetic operations
18:36:48	FromGitter	<adamrezich> @zetashift awesome, thanks so much!
18:38:38	shashlick	araq: should I add that to the gist or does it belong on the issue tracker?
18:39:49	*	devdri joined #nim
18:43:27	Araq	good question. let me create issues for these
18:47:58	*	Trustable quit (Remote host closed the connection)
18:49:46	*	yglukhov joined #nim
18:52:36	*	yglukhov quit (Read error: Connection reset by peer)
18:53:09	*	radagast quit (Ping timeout: 264 seconds)
18:53:09	*	yglukhov joined #nim
18:54:24	shashlick	any comment on branching 1.0 sooner or later? HEAD is a moving target
18:55:48	Araq	for me devel is the v1 branch...
18:56:29	Araq	new developments are behind the --newruntime switch
18:57:32	Araq	and don't affect anybody. it's risky to not use a branch for that, but since I have never introduced a bug by this afaict, the risk seems too low to care about it
18:58:11	Araq	and working on multiple branches at the same time is tedious. needs to happen once v1 is out though.
18:58:54	*	nsf joined #nim
19:00:49	shashlick	will newruntime persist in 1.0?
19:01:32	Araq	yes, it's for transitioning to the new runtime. for 2.0 it should be the default
19:02:17	shashlick	I agree multiple branches is a pain but a necessary one, ideally we have separate maintainers who will backport relevant changes from devel into the branch, eventually
19:02:34	Araq	that's true and part of the release cycle
19:02:51	Araq	what do you suggest?
19:04:47	Araq	but now I consider making this the rule. one git branch, compiler supports --version:1|1.x|2|etc switches
19:05:12	Araq	(and stdlib too of course)
19:05:46	Araq	it's unusual, but who is here to testify it doesn't work?
19:06:40	shashlick	so are you saying all work will be done on HEAD and capabilities will be separated and controlled by command line flag?
19:06:54	Araq	it's an idea I'm thinking about.
19:07:17	Araq	if we are careful, I cannot see why it can't work.
19:07:39	Araq	as we said, even bugfixes can mean 1.0.2 is worse for your project than 1.0.0
19:07:53	Araq	so that's bad, you have to wait for 1.0.4 then.
19:08:37	Araq	but that's no reason we can't have capability control by command line flags.
19:08:39	shashlick	it might work, my only concern is that not everyone has the aptitude to contribute with that code flexibility
19:09:25	shashlick	so you reduce your potential contributor base by picking a non-standard release process
19:09:45	Araq	well instead of branches, you get 'if' statements in the compiler and 'when' statements in the stdlib. it's a tradeoff.
19:10:29	Araq	shashlick: it's similar to what GCC and clang do though with their --std-c99 switches
19:12:26	shashlick	hmm, I'll have to think about it - does require more discipline and more chances of breaking things
19:12:50	shashlick	how will breaking changes be handled? two different versions of code execute based on the flag?
19:13:01	miran	nobody asked me, but i vote for a more traditional/familiar way - branches
19:13:05	Araq	yes
19:13:30	*	couven92 quit (Ping timeout: 260 seconds)
19:13:31	Araq	miran: Python does that and Python has dedicated maintainers that backport stuff all day long
19:13:51	shashlick	and if there's a bug in both chunks, have to fix it in both places (which would be required with branches too but you have merges to simplify that)
19:14:29	Araq	Python's way works but it's not obvious this is the best way to do it.
19:14:45	*	gokr quit (Ping timeout: 264 seconds)
19:14:47	miran	Araq: but nim doesn't have 2.7, 3.4, 3.5, 3.6, and 3.7
19:15:04	Araq	but it should, no?
19:15:08	miran	no
19:15:28	Araq	what should it have then?
19:15:58	FromGitter	<zetashift> @dom96 I'm having the x64 windows crash with choosenim: https://github.com/dom96/choosenim/issues/35 there are some solutions in that issue but I'm not sure on which file to apply them
19:16:18	shashlick	eventually it might, but today, even stable and devel is a great
19:16:33	miran	Araq: 1.x and 2.0
19:16:47	Araq	we already use 3 numbers.
19:17:00	dom96	zetashift: only way to workaround it is to download the file that choosenim downloads manully
19:17:01	Araq	major.features.patches
19:17:20	dom96	zetashift: you're better off just grabbing Nim the traditional way until I release a new version of choosenim
19:17:23	shashlick	here's a related thread that leans towards what araq suggests - https://softwareengineering.stackexchange.com/questions/134754/is-it-a-good-practice-to-use-branches-to-maintain-different-editions-of-the-same
19:17:53	FromGitter	<zetashift> @dom96 thank you!
19:18:08	FromGitter	<matrixbot> `pqflx3` Id support version switches over branches as separate branches diverge and maintaining is a lot of work
19:19:19	shashlick	araq: okay, so you still release a point release like you do today but end user has the ability to pick the version they want to use and ideally they use stable. if they use devel, they get some warning?
19:19:29	shashlick	also, what happens when you no longer support an older version - say 3.0 is out and you're done supporting 1.0
19:19:33	*	PMunch joined #nim
19:20:06	shashlick	for first question - i meant, they git clone #head and pick versions with the flag
19:20:44	*	yglukhov quit (Remote host closed the connection)
19:21:17	Araq	shashlick: then I can finally remove the ifs/whens in the code :-)
19:21:34	miran	Araq: isn't that boring? ;)
19:21:41	Araq	but that's what frightens me, every new proc in the stdlib will be in a 'when' guard
19:22:23	Araq	these 'when's are already tedious but required for the cross platform support
19:22:34	Araq	but to use them everywhere, oh my
19:23:26	shashlick	stdlib is fine, what about the core language? will this mechanism work there too?
19:23:42	Yardanico	shashlick, it already does ;)
19:23:46	Yardanico	there are a lot of switches
19:24:25	Yardanico	shashlick, https://github.com/nim-lang/Nim/blob/ad222e3015841f4e57bf3f75d809b00082b91a3a/doc/advopt.txt
19:24:41	Yardanico	see in Advanced options
19:24:54	Yardanico	ah, sorry, wrong
19:24:55	shashlick	no doubt, but in terms of ongoing maintenance and deltas over time
19:25:40	shashlick	every line of code could have a bunch of whens around it
19:26:05	Araq	as I said, for the compiler it means 'if', for the stdlib it means 'when'
19:26:20	Araq	then you can switch Nim versions at runtime easily
19:26:53	Araq	it also makes the compiler slower over time but we can then replace the 'if' with a 'when' :P
19:27:28	miran	the alternative is to have a cleaner code, with a bit more work with branches?
19:27:59	Araq	it's not a "bit" more work. it's manual work vs automated work.
19:28:40	Araq	bugfixes automatically affect all versions under my scheme and need to be backported manually under Python's scheme.
19:28:46	shashlick	how is it automated?
19:29:38	shashlick	there's still the effort of sifting through the code and figuring out which "releases" have a bug
19:29:58	Araq	huh?
19:30:17	Araq	that's obvious by inspecting the code during the bugfix
19:30:33	Araq	you write a test, it fails.
19:30:42	Araq	you fix the bug, the test starts to work.
19:31:02	Araq	the code you fixed is the code that is used in the relevant versions
19:31:34	Araq	rarely it can be the case that some other similar code also needs to be fixed
19:31:49	shashlick	can you point me to an example in the existing code? then I can quit speculating
19:32:29	Araq	https://github.com/nim-lang/Nim/commit/8fdc2919360653f5444752b3fd80f12bfe4816ba
19:32:37	Araq	Nim has 3 GCs using this allocator
19:33:08	Araq	I fixed the allocator, all GCs are affected and work better than before
19:33:40	Araq	wouldn't be different for other parts of the stdlib.
19:34:05	Araq	the fix applies to all Nim versions 1.0.x, 1.1.x, 2.0.x would they exist.
19:35:40	*	natrys quit (Ping timeout: 240 seconds)
19:35:51	Araq	the only thing that's left to do is to build 3 release download packages
19:36:07	Araq	each one defaulting to a different version
19:36:22	shashlick	okay so how would the versioning work? --version:1.0.5 will allow all stuff upto that version to show up, newer stuff would disappear
19:36:37	Araq	yes
19:37:31	shashlick	okay, so you are still looking at shipping different packages, only the code is common, not the release packages?
19:37:48	shashlick	I thought even the package could be common and contain everything
19:38:09	shashlick	then it's the user's responsibility to explicitly pick the version
19:38:23	Araq	that's true but if I download Nim-v1.1.2 that should somehow be the default
19:38:42	Araq	maybe it's just a text file next to the .exe that contains 1.1.2 though :P
19:39:43	shashlick	nim,cfg
19:40:22	shashlick	another article: https://devops.com/feature-branching-vs-feature-flags-whats-right-tool-job/
19:43:15	*	yglukhov joined #nim
19:46:30	shashlick	https://trunkbaseddevelopment.com/
19:47:35	*	yglukhov quit (Ping timeout: 240 seconds)
19:50:16	*	natrys joined #nim
19:52:46	*	yglukhov joined #nim
19:54:48	*	salewski quit (Quit: WeeChat 1.9.1)
19:55:27	*	BitPuffin quit (Remote host closed the connection)
19:59:00	*	c0ntribut0r quit (Ping timeout: 260 seconds)
19:59:35	*	c0ntribut0r joined #nim
20:14:36	shashlick	here's the updated gist based on the single branch discussion, please review and provide feedback
20:14:37	shashlick	https://gist.github.com/genotrance/4e4158909972617082dc223b2bb0b2f0
20:14:50	shashlick	i've also asked a question on how releases will be tagged
20:15:00	shashlick	thanks for the participation :)
20:24:44	*	Yardanico quit (Remote host closed the connection)
20:24:51	*	PMunch quit (Quit: leaving)
20:27:18	*	c0ntribut0r quit (Ping timeout: 256 seconds)
20:29:10	FromGitter	<Bennyelg> Nice work
20:35:50	FromGitter	<matrixbot> `pqflx3` I dont think bugfixes would go behind version blocks. I wouldnt run nim1.0.1.exe --version:1.0.0.
20:44:49	*	c0ntribut0r joined #nim
20:48:29	FromGitter	<Bennyelg> https://nim-lang.org/docs/ssl.html#connect,SecureSocket,string,int deprecated?
20:49:49	FromGitter	<mratsim> I'm In.
20:52:33	*	vivus joined #nim
20:59:38	FromGitter	<Bennyelg> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5a70dcbae217167e2c1f3d5f]
21:01:44	FromGitter	<Bennyelg> was just typo
21:02:03	FromGitter	<Bennyelg> how I can I verify an ack from the address?
21:06:04	*	nsf quit (Quit: WeeChat 2.0.1)
21:06:27	*	miran quit (Quit: Konversation terminated!)
21:08:40	FromGitter	<Bennyelg> I see this bug is still open: ⏎ https://github.com/nim-lang/Nim/issues/2753
21:35:39	*	MJCaley joined #nim
21:36:44	shashlick	@pqflx3: makes sense - bug fixes would go directly into wherever it belongs so even if someone were using --version:1.0.0, they would inherit it - the idea being they want to use 1.0.x and all fixes built for it
21:38:01	FromGitter	<honewatson> Will there still be a GC option available in Nim v2?
21:38:29	dom96	That is a good question
21:39:04	dom96	Personally if Araq isn't planning on making that an option I will fight for it so it's likely to happen :P
21:41:46	Araq	honewatson: uncertain.
21:41:55	shashlick	I agree, the GC is very effective for many use cases
21:42:29	Araq	I would prefer to map 'ref' to optimized atomic refcounting and leave it at that
21:43:14	Araq	maybe with a semi-manual cycle collector
21:44:08	*	Jesin joined #nim
21:46:49	Araq	shashlick: yeah, "trunk based development"
21:46:56	Araq	but how do we do the git tagging?
21:47:42	*	arecaceae quit (Remote host closed the connection)
21:47:56	Araq	and more importantly, do we really want a 'when' for every new proc we add to the stdlib?
21:48:28	*	arecaceae joined #nim
21:48:41	shashlick	ya I had the same question on git tagging
21:48:52	Araq	we could also have lib/1.0.2/strutils.nim, lib/1.1.0/strutils.nim but then bugfixes need to be applied to both files
21:49:19	Araq	we can have a version pragma though.
21:49:25	shashlick	that defeats the purpose
21:49:39	Araq	proc foo() {.version: "1.1.0".} = ...
21:50:07	Araq	probably a good idea
21:50:18	shashlick	updated gist based on @pqflx3's comment
21:51:46	Araq	yeah, we need a .version pragma
21:52:01	FromGitter	<honewatson> I think if you have solid options for both GC and No GC then you have essentially a very strong selling point. For me Nim with GC is in a nutshell - the benefits of Golang, but a better language. It allows you to just get stuff done as a general language. I don't see how that would be possible with the additional overhead of having to worry about memory management. It would mean a more niche and limited market
21:52:01	FromGitter	... for Nim in my mind. Performance with GC is good enough for general use cases.
21:53:14	Araq	getting rid of the GC (if we do it completely) is not for the performance.
21:53:21	shashlick	araq: .version will solve the when() concern
21:53:59	FromGitter	<honewatson> @Araq also I agree that you personally ( and Dom ) should not be focused on bug fixes but that there does need to be a an aim and process in getting more community members helping with fixing bugs
21:54:08	Araq	as I said, performance is competitive if not better when you base it on a bump pointer allocator
21:55:18	Araq	GCs problems are interop with the FFI, more memory usage and worse idioms for dealing with sockets/files (you can still forget to use Python's with statement)
21:55:22	dom96	I think the main point is: don't force us to worry about telling the compiler when it should dealloc memory
21:55:34	dom96	Just offer some form of automatic memory management
21:56:43	shashlick	how about GC is on by default like nim 1.x but all of stdlib manually manages memory so if you want to turn GC off, it's the same capability
21:56:48	FromGitter	<honewatson> So how much additional code overhead and mental overhead will there be with no GC?
21:56:49	Araq	no proposal of mine says "ok, just write dealloc everywhere"
21:57:12	shashlick	and package writers can also add a pragma stating they are gc free
21:57:42	FromGitter	<Bennyelg> cast JsonNode to string ?
21:57:59	shashlick	effectively, users get to use the GC but core language/stdlib is GC free
21:58:01	FromGitter	<honewatson> Also the FFI is better than most other languages at the moment.
21:58:05	dom96	also, please let's discuss this 'version' pragma further before deciding to implement it
21:58:44	dom96	Araq: Okay, but how many code changes will be required to achieve what you propose?
21:59:12	Araq	I created an RFC with more details
21:59:22	shashlick	@honewatson: agreed, the ffi is super effective
22:00:01	Araq	https://github.com/nim-lang/Nim/issues/7041
22:00:08	dom96	Okay, I still need to study it (v2 right now is a distant priority for me so I probably won't study it for a while)
22:01:25	dom96	It would be nice to offer a summary explaining how this will affect current code in the wild.
22:01:41	dom96	because it really doesn't seem clear based on the current contents of the wiki article
22:02:07	Araq	unclear what to do with refs and closures
22:02:25	Araq	if we ignore these, it amounts to:
22:02:27	dom96	yeah, and that's a big issue IMO
22:02:48	Araq	introduce 'lent' and 'sink' annotations or live with the worse performance
22:03:58	Araq	note that I consider these annotations really helpful regardless of their performance implications
22:05:05	Araq	they enable the compiler to do more checking.
22:07:01	Araq	shashlick: ok, tag can just be "v1.0.1, v1.2.1, v2.0.1" for a bugfix?
22:08:21	shashlick	so basically tag the latest version of every branch contained
22:08:29	Araq	yeah
22:08:33	*	couven92 joined #nim
22:09:30	dom96	I don't see a reason for putting features inside version blocks for 1.x maintenance
22:09:35	shashlick	so then you can ship also as a single package - set version to latest version of the oldest branch by default
22:10:05	shashlick	and nim --list-versions and nim --set-version:1.2.1 or something to that effect
22:10:38	shashlick	then global nim.cfg gets configured accordingly and it's transparent to user going forward
22:11:38	Araq	dom96: then why do we have a version number consisting of three numbers?
22:12:22	Araq	shashlick: yes.
22:12:53	dom96	Araq: To signal that new functionality was added?
22:13:05	dom96	I don't see what that has to do with "version blocks"
22:14:13	shashlick	but in effect, it means there's no way to run --version:1.0.5 since it will automatically contain the new features from 1.1
22:14:44	FromGitter	<honewatson> ok well regarding the no GC points here thats sound promising and interesting - maybe revolutionary. For me hearing Nim v2 will be GC free and that maybe there won't be a GC option without explaining the workflow/code implications was alarming an I imagine that could be the case for others in the community.
22:16:12	Araq	sorry about that. :-)
22:16:20	dom96	Araq: Oh, you mean you want the "trunk-based development"?
22:16:25	Araq	yes.
22:16:34	Araq	I want the trunk-based development.
22:16:56	shashlick	dom96: i'm documenting both methods for now
22:20:15	FromGitter	<honewatson> +1 for removing all deprecations for v1
22:21:54	Araq	shashlick: any other problems you can see with the trunk based model?
22:23:00	shashlick	just made some updates to gist - more open questions
22:23:21	shashlick	need to figure out timelines, how many parallel branches, deprecation of versions, etc.
22:23:43	dom96	You'll still undoubtedly need a 'when version == 1.0' anyway
22:23:52	dom96	And code will be a massive mess with all these whens
22:23:56	dom96	It's a bad idea IMO
22:26:15	Araq	shashlick: I think 3 branches. 1.0.x, 1.morefeatures.x, 2.0.x (breaks stuff)
22:26:46	Araq	dom96: only a couple of these whens will be required if we do it right
22:27:20	Araq	I want to give it a real try before we start with the manual approach of branches and backports
22:27:38	shashlick	some more updates to first bullet
22:28:40	shashlick	dom96: I agree it's more diligence required but merge hell is it's own nightmare too
22:28:46	shashlick	and I like the idea of having multiple versions available simultaneously
22:28:54	Araq	> Can {.version.} be used by users?
22:29:03	Araq	yes, but it's Nim's version.
22:29:10	*	Vladar quit (Quit: Leaving)
22:29:21	Araq	also .version can be implemented a macro with today's Nim
22:29:28	shashlick	that actually works well since you can target your packages or code to work with multiple versions
22:29:35	shashlick	of Nim
22:29:53	Araq	so people can write their own "packageVersion" version of this macro
22:30:24	shashlick	araq: so 2.0.x - this version won't exist for some time, it will probably come out a while after? for near term, it will be an unstable branch?
22:31:31	Araq	maybe we have some odd/even thing going on then, 2.0.x becomes 3.0 once it's stable and released? not sure
22:32:12	Araq	0.x becomes 1.0, 2.x becomes 3.0, makes sense, right?
22:33:21	shashlick	I'm not a fan of losing major versions, prefer alpha/beta and such but those aren't any better
22:34:46	Araq	I'm not a fan of alpha/beta since it's harder for computers to understand
22:35:43	shashlick	Araq: as you can see, there's a lot more difference in using this trunk approach - devs have to be careful and users also have to be careful
22:36:16	shashlick	have to remove code from old versions instead of just letting the branch die/delete
22:36:53	Araq	we review the code anyway, only the reviewer needs to be more careful and I can imagine a
22:37:10	shashlick	but good to think through
22:37:23	Araq	heuristics like "line with proc without .version" --> red flag.
22:37:24	shashlick	i'm adding some pro/con stuff - feel free to elaborate
22:37:26	shashlick	is it possible to share a gist to edit?
22:38:34	Araq	i doubt it
22:40:16	shashlick	do we already have the ability to do when NimVersion = xyz?
22:41:41	Araq	yeah
22:42:22	shashlick	so if I have code using new Nim features, it will still compile? ignores syntax and other things in the when block?
22:43:03	shashlick	will it still compile with an older Nim which doesn't understand that syntax but ignores it since version is lower
22:44:15	Araq	that's a good point
22:44:35	Araq	everything in a 'when' still needs to parse
22:44:59	Araq	but disabled branches are not sem'checked
22:45:00	shashlick	if you want breaking changes to coexist, those could be syntax changes too
22:45:03	dom96	I thought the idea was that you always have the "latest" nim
22:45:25	Araq	well it's tough.
22:45:27	dom96	I guess the problem is compiler changes?
22:45:39	Araq	so lets come up with an example
22:45:55	Araq	Nim v2 introduces indentation based string literals
22:45:58	dom96	you've got the version though, so you'd be disabling those anyway.
22:46:02	Araq	they look like
22:46:07	Araq	const foo = '''
22:46:13	Araq	text here
22:46:17	Araq	no close.
22:46:27	Araq	this is a lexer/parser change
22:46:40	*	xkapastel quit (Quit: Connection closed for inactivity)
22:46:45	Araq	with the trunk based model, no problem
22:47:16	Araq	1.0.1 "supports" this as far as required to be able to work within a 'when' block
22:47:29	Araq	2.0.0 knows the construct.
22:47:59	dom96	that's already 1.0.1 behaving differently though
22:48:19	dom96	It's 1.0.1 but the parser is 2.0.0
22:48:41	Araq	maybe, but it works.
22:48:57	shashlick	that kind of defeats the purpose since I'm not really getting an old stable version
22:49:03	dom96	yeah
22:49:05	shashlick	i'm getting new stuff even though you said it is old
22:49:18	Araq	so you depend on previous syntax errors? how?
22:49:42	dom96	what if 2.0 makes something a syntax error?
22:50:06	Araq	like?
22:50:16	shashlick	so think of this - I am a package writer and I write when 1.x: use 1.x syntax, when 2.x: use cool 2.x capability
22:50:25	*	natrys quit (Quit: natrys)
22:50:51	dom96	like let's say you want to remove the 'do' notation
22:51:04	shashlick	when an end user runs this with nim 1.x-1, it should work
22:51:10	FromGitter	<data-man> About the version pragma: what's next? commit pragma? Version changes rarely, and that worked before a some commit may not work after another.
22:51:18	shashlick	otherwise packagers and stdlib alike will have to be very specific with version requirements
22:52:21	*	MJCaley quit (Quit: MJCaley)
22:52:23	shashlick	as discussed, 1.x shouldn't break anything, whether bugfix or new feature releases
22:53:09	Araq	it doesn't break anything. ''' used to not compile, now it does but it only makes to sem'check where it would error
22:53:25	Araq	so that it can be used in a 'when'
22:54:00	Araq	"I relied on this specific compiler error message" is unreasonable backwards compatibility.
22:54:50	shashlick	I'm kind of lost in my own question - have updated the gist with some pro/con stuff
22:55:03	Araq	now to dom96's example
22:56:35	Araq	the 'do' notation would need to be removed in the way that it still works within a 'when false' section.
22:57:34	shashlick	so a packager would have to say "when 1.1" if he wants to use the new features of 1.1, else he'd say 1.0. if a user now uses Nim 1.2, it should simply work. we cannot expect a user to use 1.0 and get it to work since the package explicitly states 1.1
22:57:35	dom96	I still dislike this :)
22:57:57	dom96	Well... you'd say when version > 1.1
22:58:52	shashlick	okay, so the concern I have is that if the same package includes a "when 1.0" and a "when 2.1" section simultaneously and a user uses Nim 1.0 which contained Nim 2.0 at the time, that package won't work when in Nim 1.0 mode
22:59:18	shashlick	assuming there's some unparsable change between 2.0 and 2.1, which is again a breaking change and not allowed given our scheme
23:00:26	shashlick	I think there's some hole in there but I can't seem to find it :)
23:00:40	Araq	we have #? braces in today's Nim.
23:00:49	Araq	not documented and will be removed again.
23:01:05	Araq	but it shows how flexible we already are in this.
23:01:50	dom96	I think that while backporting fixes will be a pain, it will be relatively easy and as a side effect teach people about the compiler.
23:02:25	Araq	I asked the Python developers.
23:02:29	dom96	and the code will be much cleaner
23:02:46	dom96	It's already a challenge dealing with the 'when's we already have
23:02:55	shashlick	that's a good point, it will be a good training base for less experienced contributors - added to gist
23:03:29	Araq	they essentially do backports in an arbitrary fashion since it's manual.
23:03:46	Araq	I don't want to train people on bullshit work.
23:04:24	shashlick	I'm uncertain though - who will decide that a change should be backported? someone experienced who made the change in the first place
23:04:43	shashlick	or understands it well enough
23:04:44	shashlick	how would that process work
23:04:57	Araq	Python has dedicated developers
23:05:04	Araq	who do nothing else.
23:05:16	Araq	than keep 3.x, 2.7.x etc up to date
23:06:03	dom96	another reason for backporting manually is that it will encourage us to work on the 1.x branch more
23:06:08	dom96	for longer
23:06:17	Araq	that's not a reason.
23:06:25	Araq	that's a misunderstanding of the trunk model.
23:07:00	dom96	It all comes down to people's impressions
23:07:26	dom96	a compiler filled with v2 might discourage them from settling on v1
23:08:02	Araq	and some people are impressed by a superior development model.
23:09:08	Araq	btw the .version annotation is very useful for the generated documentation too.
23:09:24	shashlick	dom96: that's why the commitment has to be keeping 1.x stable
23:09:53	shashlick	v2 should be for future work and not really advertised too much until it's closer to ready
23:09:58	dom96	Araq: That's a good point, but that won't always be enough
23:10:15	dom96	In many cases we'll have `when version > 1.1`
23:10:36	dom96	I do want the doc gen to handle stuff like this too of course
23:10:56	Araq	we need a .version that supports ranges
23:11:04	Araq	but that's about it.
23:11:05	shashlick	when 2.x ships, there should only be a bugfix release for 1.x - of course that means 4 branches - 1.x bugfix, 2.x bugfix, 2.x new and 3.x breaking new
23:11:06	*	byte512 quit (Ping timeout: 268 seconds)
23:11:14	dom96	Araq: Huh?
23:11:25	dom96	You surely don't mean the pragma
23:11:28	dom96	but the constant
23:11:35	Araq	I do mean the pragma.
23:12:11	dom96	{.version: 1.1.} should just mean >1.1 by default
23:12:14	dom96	*>=
23:12:21	Araq	proc foo() {.version: "1.1.0, < 2.0.0".} # from 1.1.0 onwards, but removed in 2.0
23:12:40	Araq	or some similar syntax
23:14:42	Araq	shashlick: the trunk model easily extends to 4 branches, I don't really understand your point
23:14:51	shashlick	why would you need that - if added in 1.1.0, it would be marked deprecated in 2.x and removed in 3.x
23:15:34	Araq	hu?
23:15:40	shashlick	it does but it's more work too, more a resource challenge. of course, that's when 3.0 comes out so will be a different story then
23:16:20	Araq	it's stupid to not try this model and go right to the "manual work" solution
23:16:37	Araq	we can't learn anything.
23:16:55	Araq	obviously the branching model works, if you put enough manual work into it.
23:18:34	Araq	it's an evolutionary deadend since you can't move away from it then.
23:19:15	shashlick	araq: my comment was for the "1.1.0, < 2.0.0" suggestion
23:19:45	shashlick	if a proc needs to be removed, it would have to be deprecated first and removed in the next release where there won't be any record of it anyway
23:20:14	Araq	sometimes it's dangerous and should be removed immediately with no deprecation path
23:20:50	Araq	can happen and is easy enough to support in the pragma
23:21:20	Araq	but you rise a good point, .deprecated also need to know about the versioning
23:22:41	*	byte512 joined #nim
23:30:08	*	radagast joined #nim
23:31:43	shashlick	Ok so what do we need to do to close on the branching vs trunking topic
23:33:30	shashlick	And what else are we missing in the list of things to get to 1.0
23:33:34	Araq	bootstrapping could cause problems
23:34:15	Araq	v1.0 must be able to build devel but v1.0.2 could already contain a shit of unrelated stuff
23:34:42	Araq	but nothing travis would tell us about immediately.
23:34:47	Araq	*would not
23:35:08	Araq	*but travis would tell us about immediately.
23:36:07	Araq	will sleep over it, good night
23:37:15	*	ipjk joined #nim
23:39:01	*	rockcavera quit (Remote host closed the connection)
23:40:03	shashlick	👍
23:40:56	FromGitter	<zetashift> these are healthy discussions but damn as a noobie I have no idea what it means
23:55:28	FromGitter	<Quelklef> Is there any way to have a template evaluate to a proc?
23:55:46	FromGitter	<Quelklef> ```template makeEcho(msg: string): proc() = ⏎ proc() = ⏎ echo msg``` [https://gitter.im/nim-lang/Nim?at=5a71060198927d5745593169]
23:56:51	FromGitter	<Quelklef> ```code paste, see link``` ⏎ ⏎ Doesn't work when used >1 times (redefinition of 'returnproc') [https://gitter.im/nim-lang/Nim?at=5a7106436117191e61d3d2b4]
23:57:02	*	rockcavera joined #nim
23:58:11	FromGitter	<Quelklef> I, um, just found a solution, but I have no idea why it works:
23:58:22	FromGitter	<Quelklef> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5a71069ee217167e2c202f6e]
23:58:32	FromGitter	<Quelklef> How does the block evaluate to `returnproc`?