<< 12-12-2018 >>

---

00:17:47	*	NimBot joined #nim
00:21:06	*	d10n-work joined #nim
00:34:47	*	fthe quit (Remote host closed the connection)
00:35:11	*	fthe joined #nim
00:53:35	FromDiscord_	<deech> Why isn't Travis picking up the test file I added as part of my PR? Doing `./koch tests` worked fine locally. https://github.com/nim-lang/Nim/pull/9934#issuecomment-446417859
00:57:18	*	fthe quit (Ping timeout: 272 seconds)
00:57:21	*	zachk quit (Quit: Leaving)
00:57:32	*	shpx quit (Excess Flood)
01:21:01	*	Tanger quit (Remote host closed the connection)
01:21:36	*	Tyresc quit (Quit: WeeChat 2.3-dev)
01:27:31	*	Snircle_ quit (Quit: Textual IRC Client: www.textualapp.com)
01:32:39	shashlick	@deech: I don't think that's what the file declaration is for - let me check
01:34:42	shashlick	aah maybe not
01:41:01	*	shpx joined #nim
01:51:57	*	biscarch joined #nim
01:54:09	*	biscarch left #nim (#nim)
02:00:06	*	kapil____ joined #nim
02:15:02	*	dddddd quit (Remote host closed the connection)
02:50:56	FromGitter	<gogolxdong> md5 module doesn't play with js
03:08:45	*	banc quit (Quit: Bye)
03:22:49	*	fthe joined #nim
03:25:23	*	banc joined #nim
03:35:08	FromGitter	<gogolxdong> How to import from CryptoJS like var CryptoJS{.importc.}:JsObject
03:37:06	FromGitter	<gogolxdong> as example demonstrates `var hash = CryptoJS.MD5('message');`
03:41:36	FromGitter	<zacharycarter> are you using the nodejs backend?
03:41:42	FromGitter	<zacharycarter> @gogolxdong ?
03:43:04	FromGitter	<gogolxdong> javascript
03:44:07	FromGitter	<zacharycarter> something like - ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c10840711bb5b25049f2f68]
03:44:16	FromGitter	<zacharycarter> and you need to import jsffi
03:47:58	*	whaletechno joined #nim
03:52:22	FromGitter	<gogolxdong> require is not defined though imported jsffi, `Uncaught ReferenceError: require is not defined at cmp.js:1572`
03:53:04	FromGitter	<zacharycarter> heh - yeah and now you're going to get into bundling if you want to use it :P
03:53:15	FromGitter	<zacharycarter> or you'll need to compile for NodeJS and then you can't use this in the browser
03:53:47	FromGitter	<zacharycarter> you can do this if you want
03:54:12	FromGitter	<zacharycarter> `proc md5(message: string): cstring {.importcpp: "crypto.MD5(#)".}`
03:54:27	FromGitter	<zacharycarter> but you'll have to be sure that `crypto` is a variable that exists in the global JS namespace
03:54:53	FromGitter	<gogolxdong> let me try
03:55:11	FromGitter	<zacharycarter> meaning you'll need to import a script tag
03:55:19	FromGitter	<zacharycarter> err import it via a script tag in HTML
03:55:34	FromGitter	<zacharycarter> and if it doesn't create some crypto variable - you'll need to call whatever main hook the library has that returns it
03:57:24	FromGitter	<gogolxdong> `proc md5(message: string): cstring {.importcpp: "CyptoJS.MD5(#)".}` ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c10872480986419d5796394]
03:57:57	FromGitter	<gogolxdong> core.js `var CryptoJS = CryptoJS || (function (Math, undefined) {...`
04:01:13	FromGitter	<zacharycarter> try changing message from string ot cstring
04:01:15	FromGitter	<zacharycarter> to*
04:03:43	FromGitter	<gogolxdong> works, then why `var CyptoJS{.importc.}:JsObject` doesn't work?
04:05:30	FromGitter	<zacharycarter> try putting a nodecl in there
04:05:44	FromGitter	<zacharycarter> other than that - not sure
04:07:59	FromGitter	<gogolxdong> works too, great
04:08:50	FromGitter	<gogolxdong> Are you mainly working on Graphics programming now?
04:09:08	FromGitter	<zacharycarter> yeah - but I'm exploring other languages besides Nim currently
04:09:18	FromGitter	<zacharycarter> looking at Zig and Kit and Chicken Scheme
04:09:39	FromGitter	<zacharycarter> and if none of those work out - I guess Rust
04:10:11	FromGitter	<zacharycarter> although so far, once I got beyond shared lib linking woes with kit - my experience has been rather pleasant
04:10:39	FromGitter	<gogolxdong> we have an expert working on Vulkan
04:11:03	FromGitter	<zacharycarter> Nim's perfectly capable for graphics programming - that's been proven
04:11:43	FromGitter	<zacharycarter> but I find myself fighting the GC these days to do anything outside of a single threaded process that doesn't support any kind of plugin system / hot loading of shared libs
04:12:04	FromGitter	<zacharycarter> it makes game development painful to a degree - so much re-compilation all the time, especially when you're trying to figure things out
04:12:51	FromGitter	<zacharycarter> I know that destructors / hcr are on the way - but I'm not looking to write a large codebase only to have to refactor it extensively six months from now
04:13:33	FromGitter	<zacharycarter> not for the reasons above anyway
04:14:07	FromGitter	<zacharycarter> the thought has crossed my mind to just use C and then use Nim as a scripting language
04:14:14	FromGitter	<zacharycarter> that might be an option
04:14:25	FromGitter	<gogolxdong> haha
04:14:48	FromGitter	<gogolxdong> if you want to build things from ground up.
04:15:12	FromGitter	<zacharycarter> well no - you could just compile the Nim code into a shared / static lib
04:15:18	FromGitter	<zacharycarter> and then consume it that way from your C program
04:15:24	FromGitter	<zacharycarter> and reload the lib when the nim code changes
04:15:41	FromGitter	<zacharycarter> the reason you can't do this with Nim today - or at least you're limited in the capacity - is because of Nim's GC
04:16:19	FromGitter	<zacharycarter> that's why there's the `useNimRtl` compiler flag
04:16:41	FromGitter	<zacharycarter> but this flag breaks any code that uses the GC during compile time - which some of the stdlib does
04:16:56	FromGitter	<zacharycarter> meaning you'd be re-authoring portions of the stdlib to make all of this work
04:17:22	FromGitter	<zacharycarter> now if you just have your game code written in Nim and the rest of your code in C/C++
04:17:46	FromGitter	<zacharycarter> you'd only have one instance of the Nim GC - assuming you didn't have any other shared libs in your project that were also authored in Nim
04:17:54	FromGitter	<zacharycarter> even then - you might be okay - I'm not sure
04:18:45	FromGitter	<zacharycarter> I'm enjoying kit so far though - I can just import a header file, link to the shared library and start calling functions
04:19:01	FromGitter	<zacharycarter> I don't have to write any binding / wrapper code
04:19:41	FromGitter	<gogolxdong> will check into kit
04:20:12	FromGitter	<zacharycarter> be forewarned, it's less mature than Nim and Zig :P
04:20:22	FromGitter	<zacharycarter> still neat to play with, and see how far you can push it
04:20:40	FromGitter	<zacharycarter> oh and yay - zig is finally done building, an hour later lol
04:20:45	FromGitter	<gogolxdong> Is that Sprite kit？
04:20:51	FromGitter	<zacharycarter> no
04:22:03	FromGitter	<zacharycarter> @zacharycarter ⏎ https://www.kitlang.org/ ⏎ https://ziglang.org/ ⏎ https://www.call-cc.org/ ⏎ these are the languages I'm looking at right now [https://gitter.im/nim-lang/Nim?at=5c108ceb8336e22a7d1c0f13]
04:22:19	FromGitter	<gogolxdong> A game development specific domain programming language?
04:23:10	FromGitter	<zacharycarter> well it's a systems programming language with a focus on game development
04:23:24	FromGitter	<zacharycarter> or it was designed with a focus on that
04:23:33	FromGitter	<gogolxdong> compiled to c only for now.
04:23:36	FromGitter	<zacharycarter> but for instance - this is a runnable kit program: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c108d48178d7860a1c26267]
04:23:45	FromGitter	<zacharycarter> I'm okay with that - compiling to C means the code is more portable
04:23:56	FromGitter	<zacharycarter> Zig doesn't compile to C and it doesn't depend on libc and it only runs on a handful of systems atm
04:24:01	FromGitter	<gogolxdong> might need js too
04:24:19	FromGitter	<zacharycarter> maybe - although I think WASM would be a better target
04:24:37	FromGitter	<zacharycarter> but then you get into the LLVM thing
04:24:39	FromGitter	<gogolxdong> hope kit and Nim will have.
04:24:46	FromGitter	<zacharycarter> I'm not too concerned with wasm / the web
04:24:56	FromGitter	<zacharycarter> my main focus is desktop development
04:25:43	FromGitter	<gogolxdong> the trend we are moving to.
04:26:05	FromGitter	<gogolxdong> GUI vs Web UI
04:26:31	FromGitter	<zacharycarter> maybe
04:26:42	FromGitter	<zacharycarter> wasm still has a long way to go
04:27:07	FromGitter	<zacharycarter> https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-future/
04:27:08	FromGitter	<gogolxdong> they coexist for a long time regarding most of current application.
04:27:53	FromGitter	<zacharycarter> well - I think everyone would pick writing a GUI with web technologies any day of the week, if there wasn't the performance concern
04:28:03	FromGitter	<zacharycarter> and it didn't mean shipping google chrome with your app
04:30:06	*	shpx quit (Quit: Textual IRC Client: www.textualapp.com)
04:30:41	FromGitter	<gogolxdong> you mean GUI contains Web UI?
04:31:28	FromGitter	<zacharycarter> or a GUI built with a web ui
04:31:32	FromGitter	<zacharycarter> like electron
04:32:11	FromGitter	<gogolxdong> I see, I meant desktop development then.
04:32:35	FromGitter	<zacharycarter> ah okay - I see what you mean
04:32:59	FromGitter	<gogolxdong> anything involved in web is super limited.
04:33:49	FromGitter	<gogolxdong> web sucks :)
04:33:53	FromGitter	<zacharycarter> I agree :)
04:43:00	*	fthe quit (Ping timeout: 244 seconds)
04:50:56	*	nsf joined #nim
04:56:10	*	lritter quit (Ping timeout: 246 seconds)
04:56:55	*	endragor joined #nim
04:56:59	*	lritter joined #nim
05:11:09	FromGitter	<AchalaSB> Is there any ipfs package in Nim lang?
05:17:37	*	ftsf quit (Read error: Connection reset by peer)
05:17:59	*	ftsf joined #nim
05:19:53	*	junland quit (Quit: Disconnected.)
05:20:00	*	junland joined #nim
05:29:46	FromGitter	<gogolxdong> we are writing our own.
05:32:00	FromGitter	<gogolxdong> as well as some improvements , but it's basically consist of Merkle DAG, Kademlia P2P, Bitswap which you can write by yourself.
05:34:52	FromGitter	<gogolxdong> IPFS concept is brilliant but it moves slowly, we are after is called sharing storage.
05:35:43	FromGitter	<AchalaSB> Ok. Will try to write by own.
05:36:02	FromGitter	<AchalaSB> And what about web3 provider?
05:39:07	*	kapil____ quit (Quit: Connection closed for inactivity)
05:58:48	*	narimiran joined #nim
06:55:37	bozaloshtsh	Is it possible for nimble to take extra commandline arguemnts (other than the task name)?
06:56:05	bozaloshtsh	to do things like nimble build -d:featureSwitch
06:56:27	bozaloshtsh	scanning nimble's source, it seems not.
06:56:53	bozaloshtsh	so if not, is it planned? or should I stop holding out and start using nake again.
06:57:34	leorize	bozaloshtsh: it's possible
06:57:56	leorize	nimble passes the flags directly to the Nim compiler
07:04:52	bozaloshtsh	leorize: but can I do when defined(x) from my project.nimble?
07:07:02	Araq	yes you can
07:08:20	bozaloshtsh	Araq: what would be the correct way to define x then? passing -d:x to nimble build isn't doing it.
07:09:02	Araq	tbh I'm surprised -d doesn't work.
07:09:19	Araq	maybe try --define:x too
07:11:26	bozaloshtsh	still has no effect on the nimscript evaluation.
07:11:52	*	krux02 joined #nim
07:14:26	*	ftsf quit (Quit: Leaving)
07:14:54	*	narimiran quit (Ping timeout: 244 seconds)
07:16:16	bozaloshtsh	I guess I can work around this by defining variables above the task definitions and using those as "switches"
07:38:26	*	stefanos82 joined #nim
08:07:24	FromGitter	<timotheecour> hi @araq i have 2 green PR’s (#9925 ; #9938) ; and for #9927 I’m wondering if you could help with the TODO I wrote regarding `popInfoContext`
08:08:37	leorize	Araq: ^
08:27:41	*	dom96_w joined #nim
08:29:38	*	dom96_w quit (Client Quit)
08:33:59	*	dom96_w joined #nim
08:35:02	*	dom96_w quit (Client Quit)
08:47:16	FromGitter	<mratsim> @bozaloshtsh @Araq switch(“define”,”x”) in Nimble. but that applies to the nim project, not to the nimble file
08:50:44	*	d10n-work quit (Quit: Connection closed for inactivity)
09:01:30	FromGitter	<gogolxdong> Can I define proc `vstyle{}`(styles:varargs[string]):VStyle and use it like vstyle{"cssFloat:left"}
09:03:25	FromGitter	<gogolxdong> error:undeclared identifier:{}
09:13:32	Araq	what's wrong with (), vstyle("a:b", "c:d") works
09:14:04	*	floppydh joined #nim
09:15:42	Araq	timotheecour: link please?
09:21:04	*	dddddd joined #nim
09:23:24	*	AndreasO joined #nim
09:27:06	*	AndreasO quit (Remote host closed the connection)
09:28:52	*	PMunch joined #nim
09:31:47	FromGitter	<gogolxdong> ```code paste, see link``` ⏎ ⏎ Error: undeclared identifier: 'vstyle' [https://gitter.im/nim-lang/Nim?at=5c10d583178d7860a1c41b23]
09:32:32	*	lritter quit (Ping timeout: 250 seconds)
09:37:16	Araq	well iirc my style macro only works in a buildHtml environment
09:41:06	FromGitter	<alehander42> the style proc works everywhere
09:41:42	FromGitter	<alehander42> @gogolxdong if you want vstyle("..", "..") you just need to overload vstyle itself
09:41:57	FromGitter	<alehander42> proc vstyle(styles: varargs[string]): ..
09:43:51	FromGitter	<alehander42> for `{}` I think you can define a singleton vstyle variable and overload `{}` for it's type
09:44:17	FromGitter	<alehander42> but overally you define `operatorname`(left: Left, right: Right)
09:44:31	FromGitter	<alehander42> not proc `left operatorname`
09:45:15	FromGitter	<alehander42> (`vstyle()` as proc vstyle(<args stuff>) would be simplest I think)
09:47:48	FromGitter	<gogolxdong> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c10d94326de6f0822c0b329]
09:49:29	FromGitter	<alehander42> you don't really need the additional \` around vstyles
09:49:36	FromGitter	<alehander42> vstyle
09:49:40	FromGitter	<alehander42> it's a normal name
09:49:41	FromGitter	<gogolxdong> you are right.
09:49:50	FromGitter	<alehander42> does it work now?
09:49:59	FromGitter	<gogolxdong> sure
09:50:41	FromGitter	<alehander42> great :D
09:53:34	FromGitter	<gogolxdong> It saves lots of explicit `kstring`.
09:56:02	FromGitter	<alehander42> ah, I just have a `j` template for cstring (and would do a `k` for kstrings if I need it), so I write j"lalalala" or k"lalala"
09:56:39	FromGitter	<alehander42> (`j` because I mostly use cstrings on the JS backend, so like "javascript cstring")
09:58:58	FromGitter	<gogolxdong> yeah, it's good. want to achieve native css style like vstyle(margin:20px, cssFloat:left)
10:06:34	FromGitter	<gogolxdong> Have you used karax?@alehander42
10:08:40	FromGitter	<alehander42> yes, a lot
10:09:34	FromGitter	<gogolxdong> Can you implement ripple effects like Google Material Design?
10:11:46	FromGitter	<gogolxdong> and how do you extract styles that can be reused.
10:12:32	FromGitter	<alehander42> Ive never used Google material design, sorry
10:13:12	FromGitter	<alehander42> But karax styles are just values of the VStyle , you can reuse or combine them any way you need
10:17:11	FromGitter	<alehander42> e.g. sometimes I have functions which generate parametrized styles based on their args
10:18:01	FromGitter	<gogolxdong> sounds cool
10:21:16	FromGitter	<gogolxdong> I'm trying to cover what we have done in Vue.js, because I'm not sure what issue comes up at what time. Does your case cover all your requirements?
10:22:30	FromGitter	<alehander42> it does, but I haven't used vue.js, so it's hard for me to compare them: I only had one trouble with the diff algorithm at one point, but I couldn't reproduce it in a small example
10:23:12	FromGitter	<alehander42> otherwise it works great, but frameworks like react/vue seem to have some additional things, so I have to look at their feature lists
10:30:17	FromGitter	<gogolxdong> I think I've covered one third at least, and the code is approximately one twentieth .
10:31:38	FromGitter	<timotheecour> @Araq *<Araq>* @timotheecour: link please? ⏎ Here: https://github.com/nim-lang/Nim/pull/9927#issuecomment-446537506
10:33:57	FromGitter	<alehander42> @gogolxdong what do you want to build with karax
10:38:09	FromGitter	<gogolxdong> our frontend, a cloud management platform
10:44:47	FromGitter	<alehander42> nice: well what is the best thing your team liked about vue? (what would be most probable to miss in other lib)
10:58:49	FromGitter	<gogolxdong> they only used Vue.js .
10:59:01	FromGitter	<gogolxdong> I'm not frontend dev :)
11:03:19	FromGitter	<gogolxdong> We tried to build with Karax almost ten months ago, didn't have sufficient knowledge about Nim neither Karax back then, after ran into some issues we cannot solve, we used plan B which uses Vue.js.
11:05:15	Araq	have I told you about my karax plan?
11:08:36	FromGitter	<gogolxdong> Not sure which part, you can tell me more.
11:12:21	*	dom96_w joined #nim
11:20:42	*	kapil____ joined #nim
11:24:04	Araq	we need a VNode that says "just take the real DOM node from over there"
11:25:21	*	pbodev1 joined #nim
11:37:39	*	AndreasO joined #nim
11:39:02	*	dom96_w quit (Read error: Connection reset by peer)
11:39:31	*	dom96_w joined #nim
11:40:01	*	AndreasO quit (Remote host closed the connection)
11:45:19	Zevv	Araq: sorry for the confusion about the asyncHttpServer. It is probably me misunderstanding things
11:46:41	*	dom96_w quit (Read error: Connection reset by peer)
11:46:53	*	dom96_w joined #nim
11:46:58	*	dom96_w quit (Client Quit)
11:48:04	*	Vladar joined #nim
12:00:57	FromGitter	<alehander42> Araq, can't we just add such a VNode currently
12:02:29	Araq	can we?
12:03:20	Araq	the idea is that we can keep the state in the input fields etc by telling Karax to always use "this one over here", no DOM diffing required
12:05:37	FromGitter	<zah> I recently used Karax as well and was a bit confused about how to handle a part of the DOM that requires manual manipulation (e.g. having a canvas that you draw to for example, or just a third party charting library). I came up with a solution, but it seemed a bit hacky
12:06:41	FromGitter	<zah> The mediaplayer example is something close, but not quite
12:09:20	FromGitter	<zah> In the rest of the React-like frameworks, you have hooks that allow you to execute code over the real nodes once the VDOM elements are rendered. Here is an example: ⏎ https://mithril.js.org/lifecycle-methods.html
12:12:25	FromGitter	<gogolxdong> VNode has a field named dom*:Node
12:14:30	*	fthe joined #nim
12:15:01	*	Snircle joined #nim
12:17:35	FromGitter	<gogolxdong> Do you have an idea of writing such VNode?
12:21:17	FromGitter	<zah> The typical pattern in other framework is that you'll create a placeholder VNode and you'll use some "init" procedure to convert the real DOM node into something richer (e.g. there are numerous charing libraries, text editors and so on which are instantiated over a placeholder node).
12:25:52	FromGitter	<zah> My "hacky" way to simulate this involved creating a global component instance that I referenced in a render proc. Once it has been shown on the screen, I was able to use `component.dom` from the rest of the program to manipulate it
12:27:32	*	abm joined #nim
12:32:24	Araq	zah, I think by now I tried every component implementation out there, the results are always confusing and hacky. Fundamentally this thing operates on a "let's redraw everything" assumption that simply bites with stateful components. We talked about this before
12:33:23	Araq	and that's not my egocentric opinion, Elm bans components too
12:35:19	Araq	but we have a nice VNode vs Node distinction and Nodes have state so if my idea works out we can get the best of both worlds with little added complexity
12:38:26	*	fthe quit (Ping timeout: 250 seconds)
12:42:24	*	ng0 joined #nim
12:42:50	FromGitter	<zah> Well, there are surprises in any framework, but the lifecycle hooks solve this problem to a large extent for me. If Elm is banning stateful components, there must be another mechanism in place to achieve the same. You can use a library such as ChartJS as a representative example: ⏎ https://www.chartjs.org/ ⏎ ⏎ It seems to be supported by Elm, although it's hard for me to tell what mechanism is being used by quickly
12:42:50	FromGitter	... browsing the code ⏎ https://github.com/suzuki-shin/elm-chartjs [https://gitter.im/nim-lang/Nim?at=5c1102498d4f3a2a7cadf187]
12:43:36	FromGitter	<zah> But what you describe can also work as long as my taking care of managing the DOM sub-tree
12:45:29	Araq	echartstest.nim shows how to do that
12:46:18	Araq	setForeignNodeId "echartSection"
12:46:18	Araq	# crucial part
12:47:12	Araq	and in VComponent we have the traditional life cycle hooks but I never really used them for anything
12:52:39	FromGitter	<zah> This reliance on IDs gets a little bit in the way when I have multiple charts on the page. Now I have to maintain my own "registry" with the known displayed charts
12:54:24	FromGitter	<zah> Otherwise, `setForeignNodeId` seems to be an alternative to the hack I used. ⏎ What are the names of the lifecycle hooks, so I can look them up (or an example that uses them)?
12:55:40	Araq	well that's my idea, an alternative setForeignNodeId
12:57:25	Araq	look at vdom.newComponent
12:57:26	FromGitter	<zah> Oh, I've actually seen these `onAttach` and `onDetach` methods. Makes me wonder now what was wrong with them and why I didn't use them
12:57:48	FromGitter	<zah> Will try again
12:59:43	FromGitter	<Vindaar> I've been building a plotting tool for my data in the last few weeks using karax where I also use `setForeignNodeId` to display a plotly graph. Works fine for me at the moment
13:29:33	FromGitter	<gogolxdong> When will this idea work out?
13:39:39	*	kapil____ quit (Quit: Connection closed for inactivity)
14:04:38	Araq	now
14:04:43	Araq	I pushed Karax v1.0
14:06:13	FromGitter	<gogolxdong> Great!
14:07:08	FromGitter	<mratsim> wow so fast :P
14:07:15	FromGitter	<mratsim> Nim coming soon™
14:09:00	FromGitter	<narimiran> time to change the second sentence in its readme ("The API is reasonably stable and version 1 should arrive anytime soon now.") :)
14:13:06	*	kapil____ joined #nim
14:14:47	edcragg	hello, what's the type `<seq[bool]>`? i can only think it's... a reference to a seq of bools?
14:15:36	Araq	it's a seq of bool, ignore the angle brackets
14:16:06	edcragg	ok, thanks :)
14:18:26	FromGitter	<gogolxdong> myAwesomeComponent haha
14:19:14	Araq	tell me if it works out in practice. if so I'll document it
14:20:14	FromGitter	<gogolxdong> sure
14:25:28	*	endragor quit (Remote host closed the connection)
14:51:17	*	stephenwithav joined #nim
15:20:09	*	nsf quit (Quit: WeeChat 2.3)
15:21:36	*	vlad1777d quit (Ping timeout: 244 seconds)
15:27:07	*	nc-x joined #nim
15:30:04	nc-x	Araq: https://github.com/nim-lang/Nim/pull/9943 are nim strings supposed to be nimCopy'ed in js codegen? Because if not, then I have a better fix.
15:31:30	FromGitter	<alehander42> i wanted to demonstrate the issue when something needs copy, strings are just an example
15:31:47	*	krux02 quit (Ping timeout: 240 seconds)
15:32:20	FromGitter	<alehander42> but i don't know how this part of jsgen works well at all, so probably there are much better fixes!(for this and the other test fails)
15:32:58	nc-x	This https://github.com/nc-x/Nim/commit/041512fe053fd115c79333e167d7071856a0c17e fixes the issue in your test
15:33:36	Araq	nc-x, I don't remember. it's likely strings are covered by nimCopy too
15:34:47	*	nc-x quit (Quit: Page closed)
15:35:17	FromGitter	<alehander42> well, they are basically arrays: I think they should be handled in the same way seq-s are
15:35:18	*	dom96_w joined #nim
15:35:25	dom96_w	https://github.com/nim-lang/Nim/pull/9888 :/
15:38:51	*	snowolf quit (Ping timeout: 260 seconds)
15:39:12	Araq	a stdlib must be allowed to live too
15:39:21	FromGitter	<arnetheduck> ugh. more stdlib code, not less - specially for something which is basically just a user-land format :/
15:40:04	FromGitter	<arnetheduck> by adding to it, you make it die
15:40:27	*	krux02 joined #nim
15:40:32	Araq	if we never add anything to it, it seems to be even more dead
15:40:58	FromGitter	<arnetheduck> yeah, half of it is because it's not receiving maintenance as the language evolves
15:41:14	FromGitter	<alehander42> yeah @nc-x it has the same problem for seq-s
15:41:17	FromGitter	<alehander42> with your fix
15:41:29	FromGitter	<mratsim> So add something that is supposed to stay stable with language evolution.
15:41:33	FromGitter	<alehander42> so the problem is with the nimCopy generation
15:43:03	Araq	Python has diffutils in its stdlib too.
15:43:35	Araq	in fact, Python has a stdlib that works quite like Nim's. it has cruft, it has useful stuff and it has broken stuff
15:44:01	FromGitter	<arnetheduck> yeah, and then they gained a package manager and have been moving away from that idea ever since (for good reason)
15:44:59	Araq	the security problems of these ecosystems makes me hesitate to embrace this idea
15:44:59	FromGitter	<arnetheduck> point is, if nim core developers don't use package management / nimble, pm and nimble will remain second-thoughts instead of making up the whole
15:45:54	*	snowolf joined #nim
15:46:39	*	nc-x joined #nim
15:47:54	FromGitter	<mratsim> Python stdlib is quite nice tbh, you can do a lot with just it.
15:47:54	dom96_w	Agree with arnetheduck
15:48:08	dom96_w	we have nowhere near the manpower to maintain these little modules
15:48:19	dom96_w	and putting them in the stdlib means we are expected to ensure these modules work
15:48:45	FromGitter	<mratsim> but do we need to maintain math? or json?
15:48:56	dom96_w	It doesn't help that you are merging modules which are simply not ready to be included. Nowadays I expect new modules to at least be documented well.
15:49:08	FromGitter	<mratsim> that should be the first criteria for inclusion. Something stable.
15:49:15	dom96_w	and to follow the code style guidelines
15:49:40	nc-x	@alehander42 adding tySequence into my fix fixes the sequence issue. The problem right now as far as I understand it is that https://github.com/nim-lang/Nim/blob/9f453592a40b6db4ab6715fe2f29ca573bb89148/compiler/jsgen.nim#L930 if this fails then we return false, which means that a nimCopy is generated. If it returns true, then it is direct assignment. Now the thing to think is whether a direct assignment is correct or nimCopy. Because if d
15:49:47	nc-x	correct then my fix should be correct
15:50:22	Araq	well I can move it from std to some hidden dir so that testament and unittest can use it
15:51:02	dom96_w	yes. Do that.
15:51:07	nc-x	<The bot snipped of my msg> Because if direct assignment is correct then my fix should be correct
15:51:10	FromGitter	<alehander42> @nc-x you're right, but I think that nimCopy is correct
15:51:30	FromGitter	<alehander42> because seq and string are copied by value, not by ref
15:52:10	FromGitter	<mratsim> @Araq @dom96 it shouldn’t be hidden, like testament, otherwise you prevent the community from forking and improving it or building on top.
15:52:27	Araq	dom96_w, the little modules are as hard to maintain when they are under github/araq or github/krux02
15:53:16	Araq	mratsim: that's the two "philosophies" about how to write a stdlib at work
15:53:36	Araq	my philosophy was "It's useful already and people can contribute"
15:53:52	FromGitter	<alehander42> @nc-x so the bug is that the generated nimCopy doesn't always change `dest` which doesn't make sense to me
15:53:55	Araq	the other philosphy is "it is not perfect, so don't include it"
15:54:34	dom96_w	It's not about perfection, it's about meeting a minimal standard
15:54:56	FromGitter	<mratsim> let’s define a standard then
15:55:00	Araq	which standard?
15:55:25	FromGitter	<mratsim> ==> RFC “ A standard for inclusion in the stdlib"
15:57:05	nc-x	@alehander42 Sorry I am a bit new to understand properly. But this gives same output on js and windows with my fix https://pastebin.com/w1EFYRpi
15:57:15	nc-x	Or are you talking about something else.
15:58:24	FromGitter	<arnetheduck> so put crap in a crap folder that's not expected to be maintained in backwards compatible fashion, so that the rest of us know which parts to rely upon and which are crap
15:59:01	Araq	for you everything is crap anyway.
15:59:10	*	narimiran joined #nim
16:00:18	FromGitter	<alehander42> @nc-x so what is the output for you?
16:00:22	FromGitter	<alehander42> from your example
16:00:23	FromGitter	<arnetheduck> depends on the context - if I want to deliver a working application, then yes, the bar is different compared to a throwaway script or a one-pager..
16:00:48	Araq	well here is the thing:
16:01:02	Araq	code starts as "crap" and then it's getting used and fixed
16:01:24	Araq	at some point we can move the file around from junk/ to std/
16:01:41	Araq	but that means people need to adjust their import statements
16:01:52	FromGitter	<alehander42> @nc-x try to compare it to the output for the C backend :)
16:01:58	Araq	which doesn't really work as well as you think it would
16:02:35	FromGitter	<arnetheduck> it works exactly as I said it would: you manage expectations that way, and in the junk folder, anything goes, including changing the api or moving it elsewhere
16:03:09	FromGitter	<arnetheduck> normally, this is why the outside-of-stdlib phase is so important, so you can settle on somthing that's well made and useful without impacting the core that people rely upon
16:04:18	FromGitter	<arnetheduck> if the PM is not well developed enough that you trust it yourself, the junk folder is a way to achieve a similar effect
16:04:44	Araq	https://dlang.org/phobos/std_experimental_checkedint.html
16:05:22	Araq	we can follow these guys and see when checkedint can moved out of "experimental"
16:05:48	Araq	or their allocator
16:07:10	FromGitter	<arnetheduck> so? clearly it's not passing the usefulness test sufficiently then, or people would be vocal about marking it not-crap
16:07:51	Araq	well allocator was written by Alexandrescu.
16:08:24	*	Perkol joined #nim
16:08:35	Araq	and he simply followed some policies.
16:09:31	Araq	the "experimental" doesn't mean anything about its code quality
16:09:35	FromGitter	<alehander42> I think this is different: we already have `{.experimental.}` etc for "alpha" features
16:09:46	FromGitter	<alehander42> isn't it equivalent to the D experimental thing
16:10:01	Araq	well yes, we have that for Nim language.
16:10:05	nc-x	@alehander42 output https://pastebin.com/H1jGe7B3
16:10:12	Araq	but we don't have a policy like that for the Nim stdlib.
16:10:25	Araq	we can do the same as D.
16:10:42	FromGitter	<arnetheduck> here's a bold suggestion: move the whole stdlib into crap and then let stuff trickle back in slowly
16:11:00	dom96_w	hah
16:11:17	FromGitter	<alehander42> @nc-x sorry, I might have misguided you : your example does work ok indeed, but you're not really testing what we want to test
16:11:41	FromGitter	<alehander42> you assign m1 to m2: they are both ref, so naturally their fields will point to the same seq(as m1 and m2 point to the same obj)
16:11:49	Araq	arnetheduck: more useful would then be a rocksolid-stable category
16:12:38	FromGitter	<arnetheduck> name it as you like.. though we already have core, pure, std, gonna be hard to find a good one :)
16:13:25	FromGitter	<alehander42> @nc-x https://gist.github.com/alehander42/3543b6a3c5d4f3a484eb155e8516d011
16:13:43	FromGitter	<alehander42> now try this one on the C backend and then on your patch
16:14:33	FromGitter	<arnetheduck> `stable` is not bad though.. again, it's about communication and managing expectations, so that people that want to build on top know what to expect and adapt to that -but it's just as much about maintaining an experimentation zone where you can be free about improving without breaking the world for everyone
16:16:50	dom96_w	maybe instead of putting the modules in folder we could just add a pragma to mark the stability of modules?
16:16:53	dom96_w	Rust offers this
16:16:55	FromGitter	<arnetheduck> the easier way to do that (for me, as a "user") is to keep experimental stuff outside the main repo, but that requires that everyone dogfoods the package manager, core devs included.. (becuase then the choice belongs to me, to either lock at a particular version or follow the experiments as they happen)
16:16:58	dom96_w	*in a folder
16:17:03	*	PMunch quit (Remote host closed the connection)
16:18:08	FromGitter	<alehander42> @nc-x I also see know your fix from yesterday: my fixes come because of similar issues with strings: are you sure proc-s don't require copying too?
16:18:28	FromGitter	<arnetheduck> our `ad2` decision was in large parts motivated by this: a desire not to break the world for a lot of people (and deal with the communications churn/friction this would cause), as we work on improving it for our use case
16:18:56	nc-x	@alehander42 Ah! your example makes it clear. Regarding yesterday's fix, I have no idea :)
16:18:56	Zevv	like gestreamer plugins: "the good, the bad and the ugly".
16:19:11	Araq	I fully support your ad2 move, but async is much harder to get right than a textdiff proc
16:19:15	FromGitter	<alehander42> you're probably right about procs tho: it doesn't make sense to not share the proc (and i don't think one can really mutate it)
16:19:46	Araq	and even if we get it wrong, we can add a .deprecated to the proc and write a new, better one
16:20:24	Araq	we already have all these tools for smooth migration paths and yet we pretend we don't and "argh, must get it correct this time..."
16:24:08	*	nc-x quit (Quit: Page closed)
16:24:30	Araq	Zevv, like every plugin system ever.
16:25:33	Zevv	I heard you adore plugins
16:26:17	Araq	it's like package management. It works when everybody plays nice and aheres to a long list of rules; aka never.
16:26:30	Zevv	uhu
16:26:43	Zevv	very true
16:30:29	*	endragor joined #nim
16:34:09	FromGitter	<mratsim> Archlinux package management works for me™
16:34:47	*	endragor quit (Ping timeout: 240 seconds)
16:47:53	FromGitter	<alehander42> @Araq I tried to add a discard locally as a fix for https://github.com/nim-lang/Nim/pull/9779
16:48:14	FromGitter	<alehander42> but whatever I do, an equivalent empty line with line info doesn't appear in the final c code
16:50:29	FromGitter	<alehander42> hm that's because discard empty is not generated, so I need to add discard 0
16:55:19	*	floppydh quit (Quit: WeeChat 2.3)
16:59:21	Araq	tada, it's in experimental/ now. Not sure anymore what any of this has to do with software quality but I need to work on more important things now
17:01:22	FromGitter	<mratsim> lol - experimental related: https://forum.nim-lang.org/t/4466
17:03:31	*	dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:04:54	*	dom96_w joined #nim
17:16:41	shashlick	what's the real difference between a useful module being in nim-lang/Nim, vs. in nim-lang/module and pulled into Nim in CI test and packaging?
17:17:01	shashlick	effectively, everything useful will be maintained, others will die over time
17:17:29	shashlick	i'm fine with either approach but I feel the stdlib should be allowed to grow - either as a built-in or external package
17:18:11	shashlick	that's the real attraction for any language that you can build anything easily
17:22:18	Araq	shashlick, diff.nim is useful for testament and unittest and if these would rely on a nimble package we would get a nice mutual dependency between Nim and Nimble
17:22:35	Araq	which we had before and was painful
17:23:27	*	jjido joined #nim
17:23:37	shashlick	having everything in the same repo perhaps has lower overhead compared to having separate ones that need to be brought together for test/delivery
17:23:45	shashlick	though circular dependencies are even more fun
17:24:02	shashlick	regardless, what's the primary concern with expanding the stdlib?
17:24:11	Araq	in the long run probably we can't fight some 'nimble install ' commands in travis
17:24:32	Araq	shashlick, "bad stuff happened"
17:26:20	shashlick	examples would help but i don't think there's any choice - the library is just as important to nim's evolution as the compiler
17:26:39	shashlick	if nimble packages are second tier citizens then that's just as much of a problem
17:27:15	Araq	they are not second tier citizens, I created plenty of Nimble packages myself
17:27:27	Araq	which I also maintain.
17:28:06	Araq	it's true that I'm not too happy with Nimble but I use it and play by our dogfoot rules
17:29:03	shashlick	ok so is the general strategy now
17:29:03	shashlick	- add any new cool libs as nimble packages which are tested separately
17:29:05	shashlick	- only add to stdlib if Nim itself depends on it
17:30:58	*	endragor joined #nim
17:35:07	*	endragor quit (Ping timeout: 240 seconds)
17:37:47	Araq	now that you said, I think so, yes
17:38:32	Zevv	Also meaning that stuff will be moved out of the stdlib actively?
17:46:33	*	Trustable joined #nim
17:52:06	*	dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:57:09	*	Tyresc joined #nim
18:00:59	*	Desetude joined #nim
18:01:03	*	Desetude left #nim (#nim)
18:04:02	*	couven92 quit (Read error: Connection reset by peer)
18:05:21	*	nsf joined #nim
18:08:01	*	dom96_w joined #nim
18:13:57	FromGitter	<arnetheduck> shashlick, there's no process for removing dead and obsolete stuff from the stdlib - that's the biggest difference imo
18:14:38	FromGitter	<arnetheduck> there's also an expectation that the stdlib will be maintained alongside the rest of the language, and be relatively stable, as far as api goes
18:16:33	FromGitter	<arnetheduck> outside packages solve both, neatly.. useful stuff gets maintained, and api changes can be introduced freely - the cost of freezing deps is low compared to freezing *all* of nim+stdlib (because the lib is a smaller unit)
18:17:01	Araq	Zevv, in the past we moved modules out of the stdlib into Nimble packages, and there are still things that should be moved
18:17:30	FromGitter	<arnetheduck> also, "useful for Nim" is "useful for the compiler" or "useful for the compiler and all tools and ..."
18:17:35	FromGitter	<arnetheduck> ?
18:18:02	narimiran	what is the criteria for "should be moved"?
18:18:27	shashlick	I agree that we should move things out then those pieces can evolve with more freedom and ownership
18:18:42	shashlick	I'd argue anything not needed by the compiler
18:19:17	shashlick	Even testament could be moved out in theory
18:19:22	Zevv	all the networking
18:25:13	FromGitter	<mratsim> there’s a difference between compiler, stdlib and nimble. ⏎ ⏎ Stdlib should be about: ⏎ ⏎ 1) Things that are not expected to change API-wise because the proper API has won (example math) ... [https://gitter.im/nim-lang/Nim?at=5c11528980986419d57e8274]
18:28:34	FromGitter	<arnetheduck> 4 is controversial indeed.. what you expect from the language depends on your context.. why json and not cbor, protobuf, xml, csv and all the others? what all of them have in common is that they're end-user formats that come and go - they're not based on some higher mathematical truth
18:29:25	FromGitter	<mratsim> popularity contest ;)
18:29:49	FromGitter	<mratsim> all languages have it, and people now expects it
18:30:10	FromGitter	<mratsim> csv is there as well
18:30:15	narimiran	yup, if json and csv were not part of stdlib i would be very surprised
18:30:16	Zevv	Not Lua - they ship without any batteries
18:30:21	FromGitter	<arnetheduck> yeah, that's why we have an ftp implementation in stdlib, as well as an html parser for who-knows-which-version of html
18:30:32	FromGitter	<mratsim> xml probably would have been there in 2003, but it was removed from Nim stdlib 2 months ago
18:30:47	FromGitter	<mratsim> html was removed 2 months ago along ith xmh
18:30:49	FromGitter	<mratsim> xml
18:31:07	FromGitter	<mratsim> are you aware of this @arnetheduck https://github.com/nim-lang/graveyard
18:32:11	FromGitter	<arnetheduck> oh, I was looking at my 0.19 checkout
18:32:26	FromGitter	<arnetheduck> graveyard looks good, yay!
18:39:17	Araq	https://docs.python.org/3/library/ftplib.html Python has FTP in its stdlib
18:39:26	FromGitter	<timotheecour> @araq > *<Araq>* shashlick, "bad stuff happened" ⏎ ⏎ Do you have a link or more details? IMO it’s unavoidable to have nimble packages being used as dependencies for nim tools (including testament), that’s basic dogfooding and code reuse. So we might as well fix all the “bad stuff” that happened and embrace nimble.
18:39:52	Araq	in its version 3.7, they had plenty of opportunity to remove it
18:40:26	Araq	and yet they didn't. Maybe because FTP is still a useful thing to have
18:40:35	FromGitter	<timotheecour> There is no cyclic dependency: c sources => nim compiler => koch => (nim compiler bootstrapped, nimble, tools)
18:41:06	Araq	timotheecour: there is, Nimble depends on Nim, Nim's repo depends on Nimble
18:41:37	Araq	Nim itself doesn't, but for some Nim tools we need to install NImble packages
18:42:21	FromGitter	<timotheecour> yes, that’s exactly what I’m saying, there is no cyclic dep. koch installs nimble, then nimble can install nimble packages.
18:42:46	Araq	bbl
18:42:58	FromGitter	<timotheecour> in fact koch already does install nimble; it just doesn’t call nimble install (yet)
18:46:32	FromGitter	<timotheecour> we’re already solving a more complex problem since a while ago (bootstrapping nim compiler, allowing to write nim in nim), this is an easier problem.
18:53:42	*	Vladar quit (Remote host closed the connection)
18:55:55	*	dom96_w quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:07:07	shashlick	i'm good with moving some candidates out into standalone repos and pulling them in for CI and packaging
19:07:26	shashlick	we could develop some tools in the process to simplify the process as we go along
19:08:07	shashlick	but before that, we need to clean up the nimble database infrastructure since a single json file doesn't scale too well
19:10:07	FromGitter	<timotheecour> nimble supports custom json file specifying where to find packages, doesnt it? so that could potentially be used if, say, we want to use mirrors for extra stability for those supported packages
19:11:00	shashlick	i'd rather move to a database to store that info centrally, perhaps even taken over by nimble.directory
19:11:03	FromGitter	<timotheecour> other than that could you elaborate on "a single json file doesn't scale too well” ?
19:11:10	shashlick	and nimble can download an sqlite file or something
19:11:28	*	shadowbane quit (Ping timeout: 250 seconds)
19:12:16	FromGitter	<timotheecour> if you’re worried about “scale” as in efficiency, I doubt it’ll ever be an issue (the numbers of packages are tiny in that regard)
19:12:41	FromGitter	<kaushalmodi> hello all!
19:12:54	FromGitter	<kaushalmodi> Just jumping into this conversation that I see going on ..
19:13:09	FromGitter	<kaushalmodi> I agree with shashlick (about please break up nimble JSON)
19:13:15	FromGitter	<kaushalmodi> @timotheecour ref: https://github.com/nim-lang/packages/issues/777
19:14:07	shashlick	well, we can still have json in the backend if required but need a cleaner api to submit packages
19:17:50	*	shadowbane joined #nim
19:17:50	*	shadowbane quit (Client Quit)
19:18:05	*	shadowbane joined #nim
19:20:11	FromGitter	<timotheecour> Okok, no problem with https://github.com/nim-lang/packages/issues/777 ; but that doesn’t justify using sqlite as the “authoritative” source; using either a single json or 1 json per package seems simpler.
19:20:31	FromGitter	<kaushalmodi> ok, I missed the sqlite part
19:20:41	FromGitter	<kaushalmodi> +1 for 1 json per package
19:21:10	FromGitter	<kaushalmodi> but -1 for a single humongous json that we have for all packages (like we do now)
19:21:57	*	kapil____ quit (Quit: Connection closed for inactivity)
19:23:38	FromGitter	<timotheecour> the humongous json could be auto-generated (ie, either not checked in, or checked in but updated after each commit using a git commit hook), from individual mypkg.json files in that repo btw, so it’ll make migration easy
19:24:06	FromGitter	<timotheecour> (ie existing tools that depend on that single json file would continue to work)
19:24:57	*	Perkol quit (Ping timeout: 244 seconds)
19:27:02	shashlick	well big question with 1 json per package is how nimble will refresh
19:27:20	shashlick	will it sit and download every single json? how will it know how to update
19:27:32	FromGitter	<timotheecour> see https://github.com/nim-lang/packages/issues/777#issuecomment-446712863
19:28:00	FromGitter	<timotheecour> nimble refresh just downloads the (now auto-generated) single json file
19:28:17	FromGitter	<timotheecour> that file is auto generated after each commit
19:28:57	shashlick	sounds fair
19:29:05	shashlick	but we still need a cleaner method to add packages
19:29:34	Zevv	anything good to be learned from pip, cpan, rocks, gems, npm, etc?
19:29:35	shashlick	nimble publish doesn't work most of the time
19:29:40	FromGitter	<timotheecour> just add mypkg.json and be done?
19:30:46	shashlick	nimble publish is good enough if it works
19:30:57	shashlick	separate files will make PR acceptance easier
19:31:11	FromGitter	<timotheecour> ok so problem solved then.
19:31:32	shashlick	one other issue with nimble is that releases are tied to nim even though your package manager can be allowed to evolve separately
19:31:39	*	PMunch joined #nim
19:33:24	FromGitter	<timotheecour> not sure what u mean? if Nim tools depend on a list of supported packages, all that’s needed is to add a proper version, eg: “testament: requires mypkg1 == 0.3.2"
19:34:13	shashlick	no i mean nimble only revs when nim posts a new release
19:34:24	shashlick	so bug fixes and improvements don't reach the community for months
19:35:42	shashlick	this is probably because nimble builds nim in to parse nimble files and requires the entire library available to run
19:38:01	FromGitter	<timotheecour> sorry, didn’t have my coffe, still not sure I follow, do u have a concrete example? bug fixes for what don’t reach the community? I haven’t experienced what you’re describing
19:39:55	shashlick	say for example that you run into the before install issue I had for nimgen packages - https://github.com/nim-lang/nimble/issues/280
19:40:32	shashlick	if it gets fixed in a week, no one benefits from it until the next release obviously
19:40:55	shashlick	but since the release is in sync with Nim itself, it will be months before that fix goes out
19:41:59	shashlick	further, existing installs of 0.19.0 are left out
19:43:47	FromGitter	<timotheecour> ok so u mean `bugs with nimble` (that was unclear till now); in that case, isn’t all that’s needed is (like any other nimble package), `nimble develop nimble` ?
19:44:19	FromGitter	<timotheecour> eg: ⏎ `git clone https://github.com/nim-lang/nimble && cd nimble && nimble develop`
19:46:26	FromGitter	<timotheecour> or maybe even: `./koch tools` (see `proc bundleNimbleSrc(latest: bool)`)
19:47:42	FromDiscord_	<Virepri> time to feel fuckin stupid again! https://twitch.tv/Virepri
19:49:13	*	zachk joined #nim
19:50:43	*	zachk quit (Changing host)
19:50:43	*	zachk joined #nim
19:54:24	shashlick	You can pip install -u
19:54:36	shashlick	Can't expect people to upgrade that way
19:55:45	shashlick	It has to be a tested and supported upgrade path
20:00:00	Araq	shashlick, you're correct but IMO we would be better served by Nimble part of the Nim repo and more frequent Nim releases
20:00:08	Araq	the existing split is a PITA
20:00:50	Araq	and Nimble is full of 'when NimCompilerApiVersion == 2' so that this thing continues to work with older Nims etc
20:01:50	FromGitter	<kaushalmodi> Araq: Hello!
20:02:06	Araq	hi
20:02:19	FromGitter	<kaushalmodi> I am bugged by a failure since the os/ospath got merged
20:02:25	FromGitter	<kaushalmodi> log: https://travis-ci.org/kaushalmodi/hello_musl/jobs/467154650#L719
20:02:38	FromGitter	<kaushalmodi> interestingly I cannot recreate that error on my machine
20:02:54	Araq	system.nim(376, 50) Warning: unknown magic 'Destroy' might crash the compiler [UnknownMagic]
20:03:06	Araq	^ your Nim library is not correct
20:03:30	Araq	your compiling a new stdlib with an older compiler that doesn't know the Destroy magic, for exampel
20:04:23	FromGitter	<kaushalmodi> hmm, I wonder how that could happen.. I even deleted the Travis cache so that it builds from c sources from scratch
20:04:26	*	krux02 quit (Remote host closed the connection)
20:04:47	FromGitter	<kaushalmodi> so that warning, and the following error related to Stat are related?
20:05:48	shashlick	Araq: why does nimble build nim in? why not use the installed Nim to execute the file as a script rather than parse it
20:06:13	FromGitter	<zacharycarter> needs the vm for nimscript?
20:06:14	FromGitter	<kaushalmodi> Araq: and I am not even caching csources: https://github.com/kaushalmodi/hello_musl/blob/5fe2adcc620fb2c2ecaaf8bb9a1fc4650c9d3654/.travis.yml#L51-L62
20:06:15	shashlick	building the nim compiler into tools gets difficult
20:06:36	FromGitter	<zacharycarter> I'm just guessing
20:06:51	shashlick	@zacharycarter: its easier to just nim e script.nims instead of merging cfg and nims into a nimble file
20:07:05	*	nsf quit (Quit: WeeChat 2.3)
20:07:06	FromGitter	<zacharycarter> well nimble has some custom nimscript definitions
20:07:18	FromGitter	<zacharycarter> beyond what the VM provides ootb
20:07:43	FromGitter	<zacharycarter> like tasks - etc
20:07:58	shashlick	anyway, i think it just complicates things - other package managers aren't tied to the release of the language
20:08:23	*	Trustable quit (Remote host closed the connection)
20:08:23	shashlick	while we are talking about spinning out stdlib stuff, nimble and other tools also fall into the same thing
20:11:29	*	pbodev1 quit (Ping timeout: 268 seconds)
20:11:31	*	lritter joined #nim
20:14:23	FromGitter	<kaushalmodi> Araq: So on my system (RHEL 6.8, 64-bit) where I just rebuild Nim from devel, that hello_musl project builds fine: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5c116c1ef4880a60a26b6af5]
20:17:59	FromGitter	<arnetheduck> a smaller standard library makes it easier to release a new nim version.. together with semantic versioning, it's also fairly easy to manage compatibility with community packages.. likewise, just because packages are in separate repos doesn't mean they cannot be simultaneously released with a new nim version, or gated to certain nim versions
20:18:22	FromGitter	<kaushalmodi> ok.. a bit of mystery clears.. looks like the Nim build process itself fails because of the presence of config.nims in that hello_musl project: https://travis-ci.org/kaushalmodi/hello_musl/jobs/467154650#L673
20:18:23	FromGitter	<timotheecour> @shashlick ⏎ ⏎ > *<shashlick>* You can pip install -u ⏎ ⏎ we could add support for `nimble update` , following what `brew update` does; maybe: ... [https://gitter.im/nim-lang/Nim?at=5c116d0fe4787d16e3886109]
20:20:41	FromGitter	<kaushalmodi> Araq: summary of this issue, with this config.nims (https://github.com/kaushalmodi/hello_musl/blob/master/config.nims) present in Nim's search path, `sh build.sh` from csources/ fails.
20:23:38	Araq	kaushalmodi: There is a PR addressing these config.nims bugs
20:24:05	Araq	shashlick, we discussed running 'nim e' but it's not clear this could work out
20:27:44	FromGitter	<kaushalmodi> Araq: Thanks. I believe you are referring to https://github.com/nim-lang/Nim/pull/9945; hope that that fixes this.
20:28:15	Araq	arnetheduck: I don't believe in semantic versioning. For a start, it completely ignores the problem that bugfixes can cause regressions. Secondly, it is expensive. Thirdly it cannot ever work reliably because of the immediate combinatorial explosion.
20:28:19	FromGitter	<timotheecour> ya I’m also curious why it couldn’t work out ; it’s weird that `nims` differs from `nimble` ; ideally a nimble file would just be a regular `nims` file that (maybe) has `import nimble_tools` to make `task` work
20:29:12	shashlick	Araq: I'm sure there were good reasons but it paints us in a corner
20:29:24	shashlick	either compiler is forced to move faster or tools slow down
20:29:44	FromGitter	<arnetheduck> you don't have to believe in it - it's a communications tool for humans - it's enough that I and the person releasing the package believe and understand the ideas behind it, and act accordingly
20:30:10	Araq	you claim "it works with version libA v2.0.x, libB v1.0.x" but to claim that you need to test N*M combinations
20:30:16	FromGitter	<arnetheduck> it tends to be better than nothing
20:30:30	Araq	and I don't believe in it because every package manager I've ever used had these problems.
20:31:01	ldlework	are we talking about Nix
20:31:07	shashlick	well if every library is in a separate repo, it can be tested with multiple versions of compiler in a separate CI setup
20:32:13	shashlick	N * M is done on a per package basis - travis is free that way
20:32:59	shashlick	i'm happily testing all nimgen wrappers on win/lin/osx times 0.18.0, 0.19.0 and devel every day
20:33:16	Araq	travis doesn't cost money.
20:33:31	Araq	it does consume energy though.
20:34:01	FromGitter	<arnetheduck> well, it describes an intent.. of course a bugfix will change actual semantics of a function, but generally not the intended semantics - and of course some people will fuck up the versioning, but generally, and with the help of tooling like abi checkers, you're able to categorize updates into "this will improve things without my action", "this will improve things if I opt to use the new stuff" and "this needs a lot
20:34:01	FromGitter	... of work", each representing an order of magnitude in the effort needed
20:34:02	shashlick	well stability is super expensive
20:34:32	shashlick	but stability is highly valued too
20:34:55	xace	as im developing a program, i leave some procedures which will be defined in the future. the thing is they are left unused and the compiler shows a hint that its unused. is there a pragma to disable the hint for that specific proc?
20:35:08	Araq	arnetheduck: you're describing patches for a process that IMHO does not work well.
20:35:08	shashlick	stability is also admittedly boring and routine but that's the cost of becoming mainstream
20:35:27	FromGitter	<arnetheduck> it gives library authors a free and well understood communications channel to their user base
20:35:34	Araq	Google praises its monorepo for a reason.
20:35:43	xace	(a pragma that disables the unused proc hint)
20:36:26	shashlick	xace: https://nim-lang.org/docs/manual.html#pragmas-used-pragma
20:37:18	xace	shashlick: thanks
20:37:29	Araq	if you want stability, nail down your dependencies precisely to the point where they might be considered part of your source tree
20:37:35	FromGitter	<arnetheduck> google can also coerce everyone in their microcosm to comply
20:37:54	ldlework	or use a good package manager like nix
20:37:58	ldlework	or guix
20:38:04	Araq	semantic versioning is all about making everybody comply.
20:38:05	ldlework	lol monorepo
20:38:09	shashlick	my main concern with a giant repo is that you cannot carve out access permissions as granularly with github
20:38:19	shashlick	if i am only allowed to work on httpclient.nim, it's not possible
20:38:24	FromGitter	<arnetheduck> er, lock down versions that's what a package manager does, generally
20:38:41	Araq	yes, I know.
20:38:56	Araq	but lock down is the opposite of "version > 1.0 < 1.6"
20:39:44	FromGitter	<arnetheduck> lock down is the dumb version of that.. then developers noticed that the process can be made more smooth with a bit of trust and communication
20:40:24	Araq	no, that is wrong. The math doesn't work out.
20:41:49	shashlick	so looks like we still aren't sure of offloading stdlib into separate repos
20:43:21	shashlick	python has everything in one repo looks like - https://github.com/python/cpython/tree/master/Lib
20:43:48	*	rayman22201 joined #nim
20:43:50	Araq	no, we will do that. but I fundamentally disagree with this idea that a complex dependency graph by different authors will give us stable software.
20:44:09	FromGitter	<timotheecour> development speed of individual packages would be really slowed down if they were part of a monorepo, especially if merging PR’s for these would be same as merging PR’s for Nim repo
20:44:31	Araq	ok, but now you are talking about "development speed"
20:44:59	Araq	previously the topic was more focussed on stability
20:45:12	shashlick	i like separate for ownership, freedom and speed
20:45:39	shashlick	stability is still the responsibility of that repo owner and there should be a CI that tests across nim versions regularly
20:46:08	Araq	and also across the versions of every dependency the package has?
20:46:16	FromGitter	<timotheecour> stability is achieved by locking down version (either with a range or with a specific tag), speed is achieved by evolving HEAD freely, independently of fact that a Nim tool may depend on mypkg 1.2.3
20:47:00	FromDiscord_	<Virepri> `nim_AoC_2018.nim(6, 5) Error: type mismatch: got <seq[proc (): string{.gcsafe, locks: <unknown>.}]> but expected 'seq[proc (): string{.locks: 0.}]'`
20:47:02	FromDiscord_	<Virepri> I have
20:47:08	FromDiscord_	<Virepri> no fuckin clue where to even start with fixing this
20:47:57	shashlick	Araq: well, it is easier to start with packages that don't have too many dependencies
20:48:07	FromGitter	<timotheecour> again, a Nim tool (binary or library) (say nimfind or testament) can depend on locked down versions of packages p1,p2,p3 and expose a stable API, even though packages p1,p2,p3 can evolve independently and make breaking changes in subsequent verions.
20:48:28	shashlick	once those easy ones are stripped out, we can evaluate complicated dependencies later and see if they can be simplified
20:48:39	shashlick	but that shouldn't stop the process today
20:49:25	shashlick	finally, a Nim release will pull a specific version of a package and test that vertically
20:49:41	FromGitter	<timotheecour> speed of depelopment (for that package, including breaking ones) and stabilty (for clients of a locked down version of that package) are both essential and can both achievable via semver
20:49:48	shashlick	that will restrict random combinations of packages
20:50:27	shashlick	we are still talking about nim standard lib which will be pulled in via nimble by koch
20:50:35	FromGitter	<kaushalmodi> Araq: Thanks. I finally got that hello_musl Travis to pass after a long streak of fails: https://travis-ci.org/kaushalmodi/hello_musl/builds. The "fix" was to move the repo's config.nims out of the way when building Nim: https://github.com/kaushalmodi/hello_musl/commit/03ce6418c6a7b749ba8bfd3a36bd99f3f487285b
20:50:39	FromGitter	<mratsim> @virepri, gist of the code
20:50:47	shashlick	not 3rd party packages
20:51:07	FromGitter	<mratsim> I don’t understand why we have .nimble, .nims and .cfg for config btw
20:51:16	Araq	shashlick, what you are saying is "having lots of depdendencies does not work well"
20:51:16	shashlick	i agree @mratsim
20:51:40	FromGitter	<kaushalmodi> I agree @mratsim this feels like dejavu
20:51:50	shashlick	super easy would have been a .nimble which has the cfg portion as structured comments and nims portion
20:52:00	*	rayman22201 quit ()
20:52:02	FromGitter	<timotheecour> I think we could start (today) experimenting with depending on nimble pkgs from nim tools, as an experiment (say, controlled by a flag if we’re unsure it’ll work), and see whether any of those issues are real.
20:52:10	Araq	.nims is the new config system, cfg is the odl config system and .nimble is for Nimble
20:52:29	Araq	I agree it's not optimal but I don't know what's hard to understand about it
20:52:30	FromDiscord_	<Virepri> ok so
20:52:35	shashlick	Araq: what i'm saying is have the same stdlib experience as today but have it distributed but brought together by nimble
20:52:39	FromDiscord_	<Virepri> I narrowed it down to algorithms.sort that's fucking me up
20:52:47	Araq	what's next? "Why do we have bikes, cars AND airplanes?"
20:52:50	shashlick	we are not enabling millions of version combinations
20:53:56	FromGitter	<mratsim> among .nimble, .nims and .cfg, which one allow me to fly? :P
20:54:08	FromGitter	<kaushalmodi> .nims
20:54:20	shashlick	in retrospect, i think user permissions are the main advantage of separate repos, speed is effectively the same
20:54:40	shashlick	testing and packaging is effectively the same
20:55:19	*	narimiran quit (Remote host closed the connection)
20:55:59	FromGitter	<timotheecour> > speed is effectively the same ⏎ ⏎ speed is essentially not the same in practice, when all PR’s are controlled by a single owner
20:56:26	shashlick	meaning issues and PRs are cleaner in a separate repo?
20:56:35	FromGitter	<timotheecour> obviously.
20:57:16	FromGitter	<timotheecour> HEAD of mypkg.nim can evolve more freely in mypkg.nim without breaking Nim that would only depend on mypkg.nim 1.2.3
20:57:20	shashlick	of course then user management starts becoming a deal too - like I don't have access to nimble but to nim
20:58:21	shashlick	well, I think devel should pull the latest tag from such repos
20:58:26	shashlick	cause that is the same experience as today
20:58:49	shashlick	but when you post v0.20.0 or whatever, it is one snapshot of the ecosystem
20:58:57	FromGitter	<timotheecour> instead of discussing theory forever, I suggest we experiment with this (and I can volunteer a PR that adds a nimble dependency from a koch tool)
20:59:07	Araq	so ... I am running Ubuntu 16.04 LTS, trying to install KDE.
20:59:11	Araq	it says
20:59:29	Araq	"kde-core (>=5:47) but it is not installable"
20:59:50	*	druonysus joined #nim
21:00:17	FromGitter	<sotrhRaven> Araq
21:00:19	Araq	it's not a theory that this doesn't work.
21:00:35	Araq	it fails in practice. Every day.
21:00:48	FromGitter	<sotrhRaven> Why are you still on 16.04
21:01:00	FromGitter	<timotheecour> brew works for me. Sometimes it breaks. And it gets fixed quickly.
21:02:14	ldlework	use nix
21:02:17	Araq	I found a couple of packages that simply don't work in brew. And btw I don't try to break these things.
21:02:27	ldlework	use whatever combination of deps for any other combination of deps you want
21:02:40	ldlework	in a cryptographically ensured reproducable way
21:02:46	FromGitter	<timotheecour> and it has far more complex setup (different languages, build tools) than our setup (single language, single build tool); and it uses semver ; eg https://formulae.brew.sh/formula/
21:02:47	FromGitter	<sotrhRaven> Every package/dependency manager has its issues. I don't think any one has it perfect.
21:03:00	ldlework	some are fundamentally better designed than others
21:03:52	ldlework	try to find some broken packages in nixpkgs, such that, the brokeness is with the packaging and not the actual software
21:04:28	FromGitter	<mratsim> Package managers break when other package managers get in play (like `pip` for Python or `cabal` or cpan or cran for Perl and R)
21:04:28	FromGitter	<timotheecour> > I found a couple of packages that simply don't work in brew ⏎ ⏎ have you reported a bug ? did it not get fixed? Every single issue I sent was fixed fairly quickly (some by me)
21:04:30	ldlework	everything is built automatically, and since the reproducability is higher than any other system, that means something for whether those packages will work on your laptop
21:04:32	ldlework	or server
21:04:55	ldlework	mratsim, that's why nixpkgs packages python, haskel, node, and so on packages themselves
21:04:58	FromGitter	<mratsim> I find pacman in Archlinux perfect
21:05:04	ldlework	lol no
21:05:14	Araq	ldlework, if I understand you correctly 'nix' does away with the semver and uses "reproducible builds"
21:05:30	ldlework	yeah, each dep is a sha
21:05:35	ldlework	content sha
21:05:42	Araq	yup, that works.
21:05:47	ldlework	yeah
21:05:53	Araq	why? because math, that's why.
21:05:56	ldlework	<3
21:05:57	FromGitter	<sotrhRaven> Nix is good
21:06:10	FromGitter	<timotheecour> there are definitely some things we can learn from brew. It learned from mistakes from prior package managers (eg macports, or other apt)
21:06:11	ldlework	if you sandbox it
21:06:15	ldlework	so nothing can use the internet
21:06:23	ldlework	the reproducability goes off the charts
21:06:28	ldlework	pacman has nothing on it
21:07:05	FromGitter	<sotrhRaven> Nix is written Haskell?
21:07:21	FromGitter	<mratsim> We were talking about development speed as well
21:07:28	FromGitter	<mratsim> and maintenance cost
21:07:28	ldlework	C++ I think
21:07:52	FromGitter	<sotrhRaven> Yep c++
21:08:12	Araq	I claim maintenance cost is unreasonable for semver.
21:08:24	FromGitter	<arnetheduck> there are two steps to package management - semver does one of them, locking the other... semver is about version discovery: which versions are likely to work with which other versions.. this is the communications part.. once you've done that, you lock down and test your stuff, using nix-style hashes or whatever other maths you choose. then the next time around, you use the first part again - the fuzzy trusty part
21:08:24	FromGitter	... - to help you find a matching set of packages that work together.. nowhere in this process is there an N*M for you, as a package consumer
21:09:00	ldlework	is semver actually useful?
21:09:09	FromGitter	<arnetheduck> you only test one version of each package you depend on, but to find that version, you use these communications tools that help you narrow down the scope of where you have to look
21:09:57	FromGitter	<arnetheduck> what's the maintenance cost of semver? I don't understand.. "nothing" is the equivalent of doing a major semver upgrade every time
21:10:05	ldlework	is bisecting that hard?
21:10:07	Araq	I just use 'git master' for all packages and create PRs to make it compatible with each other :P
21:10:11	ldlework	isn't bisecting the worst case
21:10:16	ldlework	don't consumer of libs have some context?
21:10:28	ldlework	wouldn't it be like araq says, start at Master, if that doesn't work
21:10:31	FromGitter	<mratsim> @Araq that works until you want a stable version and a devel version
21:10:31	ldlework	use latest release
21:10:36	ldlework	if that doesn't work, go back a few versions?
21:10:51	ldlework	blindly depending on semver to cover the interoperability of all software seems...
21:10:56	ldlework	idealistic
21:11:14	FromGitter	<mratsim> welcome to dynamic languages
21:11:14	Araq	I mean I use master for this "exploration" phase
21:11:19	ldlework	same
21:11:28	ldlework	what does dynamic have to do with anything
21:11:32	ldlework	this is about contracts
21:11:42	ldlework	interoperability
21:11:46	ldlework	it's not even about software
21:11:48	FromGitter	<mratsim> Try to ship Python
21:12:00	FromGitter	<mratsim> we need dockers or virtualenv
21:12:02	*	Sembei joined #nim
21:12:04	ldlework	i have like 50 different subtley different python installs on NixOS
21:12:13	ldlework	each package that uses Python can specify EXACTLY what it needs
21:12:13	Araq	^^ :D
21:12:23	ldlework	if two packages specify the same things
21:12:26	ldlework	they share a python
21:12:31	ldlework	it works marvelously and NEVER breaks
21:12:32	FromGitter	<timotheecour> @araq `brew` doesn’t have this combinatorial explosion problem. brew is designed so that you can `brew install foo` at all times (and, rarely, something might break, it gets fixed quickly) ⏎ Each formula (foo.rb) in homebrew-core is updated regularly to a git tag of upstream package foo in a way that works with rest of packages in brew ecosystem.
21:13:10	FromGitter	<mratsim> well, ship that to a user then
21:13:30	ldlework	in NixOS "nix-env install foo" the equivalent is consider basically what you do as a newbie to try things out
21:13:38	ldlework	and then you quickly NEVER install packages interactively
21:13:51	ldlework	and then, further, you basically try to NEVER install packages on your system
21:14:06	ldlework	(but you still do of course, its just you'd prefer not to)
21:14:21	ldlework	but installing packages on your system doesn't matter for the same reasons it would on arch
21:14:23	*	Pisuke quit (Ping timeout: 268 seconds)
21:14:25	ldlework	(dep interactions)
21:14:29	ldlework	those don't happen on NixOS
21:14:50	ldlework	simply because it's easy to delete a shell.nix file than something from your actual system configuration
21:15:26	FromGitter	<arnetheduck> btw Idlework, do you use NixOS on a day-to-day system?
21:15:30	ldlework	yup
21:15:37	ldlework	and since i know my system will never break
21:15:44	FromGitter	<arnetheduck> gnome?
21:15:47	ldlework	and if my laptop fails and I have to get a new one
21:16:00	FromGitter	<sotrhRaven> I may have try it again it's been a while
21:16:00	ldlework	that it will be a matter of hours until I have the -same exact- system running on a new laptop
21:16:07	ldlework	I can make huge investments into my workstation environment
21:16:11	ldlework	customizations and automations
21:16:18	ldlework	because I know once it works I never have to touch it again
21:16:25	ldlework	on a new laptop I wont "have to rememeber" anything
21:16:39	ldlework	so i have for example 100% global realtime theming :)
21:16:41	ldlework	let me get a video
21:17:03	ldlework	http://ldlework.com/projects/cards/la-karda/
21:17:06	ldlework	oops
21:17:09	ldlework	https://www.youtube.com/watch?v=sVHlYcKVerE
21:17:13	ldlework	https://www.youtube.com/watch?v=1hJQWxx3dqA
21:17:21	ldlework	the second one is most recent
21:17:31	ldlework	where even my wm reacts to the theme
21:17:36	FromGitter	<sotrhRaven> Cool
21:17:38	Araq	this is becoming #nim-offtopic
21:17:42	ldlework	yeah
21:18:07	ldlework	well it is an example of what you can get on with, once package management is not something you have to think about all the time and reproducability is Reproducability
21:18:08	FromGitter	<sotrhRaven> What de are there? That looks like i3.
21:18:09	ldlework	last thing I'll say
21:18:19	ldlework	there is a Nix equivalent for Emacs called straight.el
21:18:21	ldlework	which I also use
21:18:22	FromGitter	<arnetheduck> reminds me of enlightenment :)
21:18:22	FromGitter	<timotheecour> I think what’s missing is the equivalent of `homebrew-core` mono-repo that specifies a set of git tags for each package that work well together so that `nimble install foo` would work for all `foo`
21:18:41	ldlework	so OSes are not the only thing that are adopting pure package management
21:18:46	Araq	that's the missing "lockfiles" feature of Nimble, yeah
21:18:50	*	ldlework fingers nimble
21:20:56	FromGitter	<timotheecour> (not sure if you were replying to me regarding lockfiles?) lockfiles feature is needed but for other reasons : speed (so that nimble install won’t rebuild dependencies when safe to do so)
21:21:27	Araq	I think lockfiles are about reproducible builds
21:22:05	FromGitter	<timotheecour> all we need is a mono-repo for ecosystem of nimble packages that are co-installable; some of these packages (like llvm@6 in brew), will have different versions co-installable; that’s a separate topic we can discuss
21:22:41	ldlework	don't put the packages into a monorepo
21:22:46	ldlework	put the packaging into a monorepo
21:22:53	ldlework	if you can't do that, make nimble better
21:23:12	FromGitter	<timotheecour> so we can largely avoid that combinatorial explosion : note that “dub” (in D) HAS this combinatorial explosion issue and it breaks often; brew does NOT.
21:23:41	Araq	ok, and Nimble does have it too.
21:24:11	FromGitter	<timotheecour> > don't put the packages into a monorepo ⏎ ⏎ the monorepo will not have the packages, only the package versions
21:24:29	ldlework	it's not really a "monorepo" then
21:24:35	ldlework	it is just a repo for tracking packaging
21:24:44	ldlework	nixpkgs, nimpkgs
21:24:59	Araq	btw assuming brew works really well, it takes them about 15 maintainers
21:25:02	Araq	https://github.com/Homebrew/brew#who-are-you
21:25:22	*	jjido quit (Ping timeout: 250 seconds)
21:25:37	FromGitter	<timotheecour> it’s a monorepo: u make a PR to change version foo in a single repo, eg: https://github.com/Homebrew/homebrew-core/pull/35043/files
21:26:24	ldlework	yeah but the monorepo doesn't represent what could be separate repos
21:26:32	ldlework	like, you said, it isn't a mono repo of all the package sources
21:26:34	Araq	do we want a system with 15 maintainers whose whole job is to keep nimble packages working?
21:26:46	ldlework	its just a repo containing files that describe packages
21:26:52	ldlework	and where to get package sources
21:27:02	FromGitter	<timotheecour> it has lots of maintainers but they’re solving a much more complex problem that we’re facing, as i said: we have 1 language and 1 build tool to support; they have a zoo of different languages / build tools
21:27:09	FromGitter	<timotheecour> (and many many more packages)
21:27:20	kungtotte	Isn't that what Nimble already is? A repo to describe packages and where to get them.
21:28:04	ldlework	also https://www.youtube.com/watch?v=1hJQWxx3dqA
21:28:22	ldlework	kungtotte: yes, i'm balking at the misuse of monorepo
21:28:39	ldlework	also http://blog.appliedcompscilab.com/monotonic_versioning_manifesto/
21:28:43	ldlework	for a third option
21:29:06	FromGitter	<timotheecour> no, nimble (as of today) doesn’t guarantee packages can be co-installed
21:30:05	Araq	I would simply use dates for the version, this way I can assume that gcc-2018-04 works with nim-2018-06 (or not... :-)
21:30:30	ldlework	just use a content sha
21:30:38	ldlework	then make a system for labels to shas
21:30:43	Araq	the content sha has no timestamp
21:30:46	ldlework	so you can refer t o329423 as nim-2018, etc
21:30:46	shashlick	Ok so bringing all this to some conclusion - what are the near term decisions?
21:31:09	shashlick	Do we want to spin packages out and pull in with nimble or not
21:31:20	shashlick	Those with zero dependencies for starters
21:31:33	FromGitter	<timotheecour> date doesn’t work if you have a bugfix 2.7.2 => 2.7.3 on branch 2.x.x even though latest is 3.x.x
21:31:53	ldlework	another thing that the nix system has is overrides
21:32:02	ldlework	so let's say you have a system of content pinning
21:32:14	ldlework	and in nimble foo v2.5 is set to use bar v1.1
21:32:30	ldlework	but darn you'd really like to use foo2.5 with bar0.8
21:32:42	ldlework	and you happen to know, in a semver interoperability sense that that works
21:32:52	ldlework	well in nix you can just override this one detail
21:32:59	ldlework	if it builds good for you
21:33:12	Araq	timotheecour: then you use different names for different product (lines) :-)
21:34:14	Araq	and it works for the C++ standard because they don't have multiple branches.
21:34:16	FromGitter	<timotheecour> my proposal is we should start this monorepo (exact same concept as https://github.com/Homebrew/homebrew-core) of packge references (starting from a small number,eg jester,nim-regex,cligen etc, growing over time) ; eg call it nimble-core
21:34:52	Araq	I will regret this but ... wanna write an RFC? :D
21:35:03	FromGitter	<timotheecour> I expect it to be incredibly simpler than homebrew-core due to our more controlled setup
21:35:28	FromGitter	<timotheecour> sure.
21:35:37	Araq	good, thanks.
21:35:59	ldlework	news.ycombinator.com/nim-adopts-brew-packaging-strategy
21:36:06	FromGitter	<timotheecour> Btw: it’s very related (maybe not identical) to https://github.com/nim-lang/Nim/issues/8638
21:36:16	ldlework	that's gonna be a good day :)
21:36:33	*	omenar joined #nim
21:36:42	Araq	shashlick, well I think we'll just continue with moving packages out of Nim and ideally we can then later move even packages that Nim's tooling depends on
21:37:28	FromGitter	<timotheecour> awesome.
21:38:01	Araq	and when something breaks I can say "I told you" and feel good
21:38:16	Araq	win-win situation.
21:38:32	FromGitter	<timotheecour> sounds good to me; and yes, it’ll break, and get fixed.
21:39:12	FromGitter	<arnetheduck> how's 19.2 doing btw? :)
21:39:50	FromGitter	<timotheecour> ok for https://github.com/nim-lang/Nim/pull/9925 @araq what name should I use then? `getCurrentCompiler`?
21:39:53	FromGitter	<mratsim> I used to see miran backports on many of my issues last month but now it’s pretty quiet
21:40:35	FromGitter	<timotheecour> (`selfExe` just doesn’t match the rest of stdlib naming scheme)
21:41:12	Calinou	file size can also be a concern, but Qt apps are still fairly large for the most part so it's not exclusive to Electron
21:41:22	Calinou	wow, I scrolled way up and didn't realize that
21:41:33	Calinou	I wish Quassel displayed something like Discord when you scrolled up :P
21:42:59	Araq	mratsim: I've been waiting for kaushalmodi to return and take a look at my nightlies travis build setup...
21:43:36	FromGitter	<kaushalmodi> Araq: And I have returned.. today
21:43:42	FromGitter	<kaushalmodi> :)
21:44:17	Araq	timotheecour: maybe even 'getCurrentNimCompiler'
21:44:34	Araq	or getCurrentNimExe
21:44:39	FromGitter	<timotheecour> ok
21:46:14	FromGitter	<timotheecour> for https://github.com/nim-lang/Nim/pull/9927 : I’m all for `quote do` when feasible, but there are valid use cases for `parseStmt` ; eg: `nimterop` relies on that; or any time you need a human provided string (I have use cases for that)
21:47:22	Araq	I still don't see why we need pushinfoContext here. Nor why we suddenly need a new way to render trees in an error message
21:47:54	Araq	you ask me how to do it, I don't know, I look up how it's done elsewhere in the compiler and that's my answer
21:48:10	Araq	probably "blah blah: " & renderTree(n)
21:48:20	FromGitter	<timotheecour> i need a way to show the expression that failed ; otherwise what u currenlyy get is a completely useless error msg when parseStmt(s) fails (when s is generated)
21:48:33	Araq	and yeah, I know these multiline error messages are bad for tooling, that's a different issue though
21:54:23	FromGitter	<timotheecour> > renderTree(n) ⏎ ⏎ will try, thanks!
21:54:32	Araq	shashlick, oh and dom96 himself likes Nimble to use 'nim e' instead, so, it's worth thinking about it
21:54:53	*	stefanos82 quit (Remote host closed the connection)
21:56:08	shashlick	I'm sure there were some road blocks forcing this path
21:56:17	shashlick	Would be good to get context
21:57:39	Araq	well Nim is written in Nim and Nimble is written in Nim and usually "use via library" is much better than "use via IPC"
21:58:12	Araq	and to be fair, the compiler-as-an-API thing got better and better, not worse
21:58:40	Araq	but with our split Nimble needs to be able to build against old compiler API versions
21:59:42	Araq	and a compiler API is hard to get right and I would enjoy the freedom to break it again
21:59:49	FromGitter	<timotheecour> and, same can be said about tools that depend on compilerapi, eg nimfind, nimsuggest (and maybe one day, nimdoc ); these have same requirement on depending on nim compiler as a library
22:00:04	shashlick	So today nimble and c2nim are the two consumers I know of
22:00:21	shashlick	Oh ya those too
22:00:31	Araq	nimsuggest, nimfind, nimpretty, nawabs, nimedit
22:00:50	Araq	would be further examples
22:00:52	shashlick	But only nimble bundles in the full compiler, others just use portions? Is that right?
22:01:14	Araq	usually all these tools use the VM but not the C codegen
22:01:44	shashlick	I see, so solving this for nimble doesn't really go far enough
22:02:24	shashlick	Is it the best use of time, or should I look into splitting out stdlib instead
22:02:38	Araq	yes it would because your concern is the coupling of Nimble and Nim releases
22:02:40	FromGitter	<timotheecour> so the answer to `nimble updates are too slow coz tied to nim releases` is perhaps adding a `nimble update` (to self update either from latest nimble or latest stable nimble)
22:03:26	shashlick	Well how about this - compiler api should be self contained, not require any lib files like nimble does
22:04:14	shashlick	Then it's irrelevant what nimble and Nim executables are put together
22:04:16	FromGitter	<arnetheduck> btw, you can still have a monorepo and multiple packages (assuming nimble or whatever supports this well) - you can even version them together if that's easier for you - but it gives you the flexibility to make more granular should you want to, and it gives a clean way to move packages out as well - just update the reference to a new location when you no longer want to maintain together, and you're done..
22:05:36	shashlick	Of course compiling nimble on the fly will link with the installed Nim
22:05:59	shashlick	But you could make nimble with musl and make binary releases instead
22:06:12	dom96	The ideal is that Nimble can call `nim foobar ...` to get whatever functionality it needs for nimscript evaluation
22:06:21	dom96	nimble depending on the compiler is a pain
22:06:47	shashlick	What was the main motivation dom96?
22:06:56	dom96	motivation of what?
22:07:06	shashlick	For pulling the vm in?
22:07:28	shashlick	Rather - why did nim e not work
22:07:45	Araq	pre-install hooks?
22:08:17	Araq	post-install hooks, all these things your own .nimble files use?
22:08:38	dom96	I never looked into it too deeply, Araq implemented nimscript support initially :P
22:08:52	shashlick	Well why couldn't they just be a nims file?
22:08:56	Araq	I also kept it working
22:09:51	FromGitter	<timotheecour> ya, ideally a nimble file would just be a nims file with a `import nimble_tools` (or similar concept)
22:10:14	shashlick	Well we need a migration path for existing packages
22:10:23	FromGitter	<timotheecour> that could be done transparently
22:10:37	dom96	well no, you should be able to tell the compiler "hey, import this implicitly"
22:10:46	dom96	or you know... just prepend "import ..." before eval
22:10:47	FromGitter	<timotheecour> without having to change any nimble file (just change nimble repo )
22:10:48	Araq	yeah, don't break the packages, patch the .nimble file in a buffer and hand that to 'nim e' instead
22:11:15	shashlick	So is it as simple as loading the nimble file, removing out non nimscript, prepend some other stuff then running Nim e?
22:11:30	Araq	we don't know
22:11:39	Araq	it's possible that it can work out
22:11:56	shashlick	Ok I'll experiment on it
22:12:04	dom96	yeah, please do try it
22:12:23	FromGitter	<timotheecour> +1
22:12:33	shashlick	Two more real action items are splitting packages.json and identifying packages to spin out
22:12:42	Araq	well it's not the most pressing thing you can do
22:13:23	shashlick	So spun out packages are still to be treated as stdlib and pulled into the CI and packaging
22:13:34	Araq	as I said, you can also spend the effort in more frequent Nim releases that bundle Nimble
22:13:37	dom96	splitting packages.json?
22:13:45	FromGitter	<arnetheduck> all such things are so much easier in a declarative world - the way to add procedural support to that is through controlled extension points - gives you the best of both worlds
22:14:24	FromGitter	<timotheecour> @dom96 Splitting => https://github.com/nim-lang/packages/issues/777#issuecomment-446712863
22:14:25	Araq	arnetheduck, no they don't, declarative+procedural support is terrible
22:15:03	Araq	for example, that's what travis does and it's undebuggable
22:15:06	FromGitter	<arnetheduck> why is that? you get your basic functionality served to you with tools, helpers and everything else, the rest is plugins
22:15:22	FromGitter	<arnetheduck> why is travis undebuggable?
22:15:29	*	PMunch quit (Remote host closed the connection)
22:15:34	Araq	travis' linter cannot even give line numbers because it's just a YAML file
22:15:47	Araq	and by the time they do the linting they lost the line information
22:15:54	FromGitter	<arnetheduck> you can easily turn a declarative config file into a procedural one - not so, the other way around
22:15:55	FromGitter	<timotheecour> that’s the old nim.cfg vs config.nims debate again.. separate issue.
22:20:02	Araq	the other way round is trivial, you add 'echo' statements to your nimscript
22:20:22	Araq	which is exactly why one is debuggable and the other isn't.
22:22:26	dom96	huh, it's never the travis file that is in need of debugging
22:22:35	dom96	it's the commands that it runs, which are procedural...
22:22:47	Araq	hahahaha
22:23:07	Araq	yeah right. same for SQL queries or regexes.
22:23:16	*	enigmeta_ joined #nim
22:23:29	*	msmorgan_ joined #nim
22:24:43	*	snowolf_ joined #nim
22:26:58	Araq	but even that were true, the mixture ensures I cannot run the Bash fragments on any local machine to debug it
22:29:12	*	reveres joined #nim
22:29:12	*	Miguelngel[m]1 joined #nim
22:29:15	*	zacharycarter[m4 joined #nim
22:29:15	*	sg-james[m]1 joined #nim
22:29:16	*	zielmicha[m]2 joined #nim
22:29:20	*	toofly[m]1 joined #nim
22:29:26	*	enigmeta quit (Ping timeout: 250 seconds)
22:29:26	*	msmorgan quit (Ping timeout: 250 seconds)
22:29:28	*	Demos[m] quit (Ping timeout: 250 seconds)
22:29:45	*	revere quit (Ping timeout: 250 seconds)
22:29:45	*	toofly[m] quit (Ping timeout: 250 seconds)
22:29:45	*	sg-james[m] quit (Ping timeout: 250 seconds)
22:29:45	*	zielmicha[m] quit (Ping timeout: 250 seconds)
22:29:45	*	Miguelngel[m] quit (Ping timeout: 250 seconds)
22:29:45	*	zacharycarter[m] quit (Ping timeout: 250 seconds)
22:29:45	*	ArchieT[m] quit (Ping timeout: 250 seconds)
22:29:45	*	FromGitter quit (Ping timeout: 250 seconds)
22:29:45	*	snowolf quit (Ping timeout: 250 seconds)
22:29:45	*	gh0st[m] quit (Ping timeout: 250 seconds)
22:29:45	*	reveres is now known as revere
22:29:45	*	msmorgan_ is now known as msmorgan
22:29:45	*	enigmeta_ is now known as enigmeta
22:30:11	*	ArchieT[m] joined #nim
22:30:29	*	FromGitter joined #nim
22:30:32	*	gh0st[m] joined #nim
22:31:09	*	Demos[m] joined #nim
22:34:54	*	omenar quit (Remote host closed the connection)
22:35:25	*	fthe joined #nim
22:35:28	*	omenar joined #nim
22:36:01	*	omenar quit (Read error: No route to host)
22:39:16	shashlick	Ok so any votes on a module or group of modules we could spin out to a separate repo?
22:39:37	dom96	Please elaborate
22:40:02	FromGitter	<timotheecour> maybe the newly added lib/diff.nim ?
22:40:51	dom96	oh, you want to move stdlib modules into nimble
22:40:58	shashlick	Ya
22:40:58	dom96	nre please
22:41:03	shashlick	How about http*
22:41:11	dom96	either that or re
22:41:41	dom96	What's wrong with httpclient?
22:41:52	dom96	or rather, why do you want it out of the stdlib?
22:42:18	shashlick	Well it will still be part of stdlib, but just maintained in a separate repo
22:42:47	dom96	What's the motivation for that?
22:43:00	shashlick	Will get pulled into Nim via nimble
22:43:15	shashlick	And user experience will be identical to today
22:43:45	FromGitter	<timotheecour> `Will get pulled into Nim via nimble` => at a specific version 1.2.3
22:43:52	shashlick	Basically separate repo means new contributor can be given access just to that repo
22:43:54	Calinou	dom96: Travis advises putting your logic into a dedicated script file if it grows too big
22:44:00	shashlick	Separate issues and PR's
22:44:08	Calinou	it's what I do in most of my projects, this way you also get syntax highlighting, shellcheck, etc
22:45:00	FromGitter	<timotheecour> simplest might be to start with tools instead of stdlib packages
22:45:11	dom96	shashlick: I don't understand why you're focusing on specific modules. Either move the whole stdlib or nothing.
22:45:16	FromGitter	<timotheecour> `./koch tools` would then nimble install them.
22:46:18	dom96	In any case, I don't think it's a good idea
22:46:23	shashlick	Cause expertise are not universal
22:46:29	dom96	The benefits don't outweigh the pain
22:46:35	dom96	Moving tools I am 100% behind though
22:46:40	shashlick	I can contribute to http stuff but not regex
22:46:59	FromGitter	<timotheecour> right, let’s focus on tools for now since it’s not controversial
22:47:13	shashlick	Ok that's fine with me
22:47:53	dom96	oh, tools are controversial too
22:48:16	FromGitter	<timotheecour> So the only change is: ⏎ everything identical until `./koch tools` ; that command then builds nimble; then calls nimble `install nimfind` (u could start with that)
22:48:18	dom96	In fact, if it wasn't for me Nimble would probably be in the Nim repo too :P
22:49:59	FromGitter	<arnetheduck> shashlick, I think the contributor thing is a little weak as far as reasons go - ie monorepo makes version management a lot easier overall.. in fact, I'd think that git gives you enough equipment to be very liberal with your access mgmt - vast majority of developers are honest and you can always roll back any damage and revoke access
22:52:19	dom96	After using phabricator for a while I'm actually rather disappointed with GitHub
22:52:29	dom96	It really doesn't scale well for repos as large as Nim
22:53:34	dom96	Ideally we should get notifications for things we actually have knowledge about and can contribute to. Right now I get notifications for any issue on any random repo I am watching.
22:54:35	FromDiscord_	<Virepri> ok here's a doosy
22:55:00	FromDiscord_	<Virepri> Why is it that when I assign to a (initialized) table, I get a key error?
22:55:03	FromDiscord_	<Virepri> it just makes no sense, man
22:55:16	FromGitter	<zetashift> example>
22:55:30	FromGitter	<zetashift> only github notifications I get is from Arraymancer :P
22:55:34	FromDiscord_	<Virepri> `potVertCols[id] = initIntSet()`
22:55:44	FromDiscord_	<Virepri> this is causing a KeyError
22:55:55	FromDiscord_	<Virepri> even though I'm assigning to it 🤔
22:56:23	dom96	Virepri: gist your code
22:56:42	FromGitter	<zetashift> does it work with potVertCols.add(key, val): https://nim-lang.org/docs/tables.html#add%2CTable%5BA%2CB%5D%2CA%2CB ?
22:57:28	FromDiscord_	<Virepri> correction: attempting to deep copy an intset into the slot is causing problems
22:57:38	FromDiscord_	<Virepri> ewen though I've already assigned to it.
22:57:43	FromDiscord_	<Virepri> even though I've already assigned to it.
23:00:10	FromGitter	<mratsim> @zetashift Sorry :P I work on it by batches :P
23:00:28	FromGitter	<mratsim> probably a couple updates during the weekend as I want to release a new version
23:00:32	FromGitter	<zetashift> it was a compliment! I love it
23:01:03	FromGitter	<mratsim> then I will change the backend and break backward compatibility so it will be silent for at least 2 months or so I guess.
23:01:34	FromGitter	<zetashift> Are you gonna switch the backend to laser?
23:01:39	FromGitter	<mratsim> yes
23:01:50	FromGitter	<zetashift> Noice
23:02:15	FromGitter	<mratsim> but I have lots of optimisations to do. I can’t trust anything to be implemented fast. Even math.h
23:02:57	FromGitter	<mratsim> exp and log can be improved 10x.
23:04:09	FromGitter	<mratsim> But right now I’m trying to get my Shakespeare neural net to learn :P
23:04:30	FromGitter	<mratsim> seems like everyone is struggling even on the mainstream NN packages.
23:06:05	*	abm quit (Ping timeout: 244 seconds)
23:07:50	shashlick	@arnetheduck: I agree, if it isn't really valuable then we can drop it
23:08:39	shashlick	But I'm also not a fan of being too conservative of what belongs in the stdlib
23:12:53	*	abm joined #nim
23:16:07	*	fthe quit (Ping timeout: 240 seconds)
23:24:20	*	fthe joined #nim
23:28:24	*	fthe quit (Remote host closed the connection)
23:29:57	*	ng0 quit (Quit: Alexa, when is the end of world?)
23:40:37	*	martin2 joined #nim