<< 04-09-2020 >>

---

00:06:49	*	a_chou joined #nim
00:08:17	*	a_chou quit (Remote host closed the connection)
00:13:24	disruptek	clyybber: you up?
00:57:22	*	ldlework left #nim ("WeeChat 2.8")
01:19:05	*	arecacea1 quit (Remote host closed the connection)
01:19:28	*	arecacea1 joined #nim
01:31:55	*	apahl quit (Ping timeout: 240 seconds)
01:33:56	*	maier joined #nim
01:33:57	*	apahl joined #nim
01:39:09	*	maier quit (Ping timeout: 265 seconds)
02:06:43	*	waleee-cl quit (Quit: Connection closed for inactivity)
02:14:55	*	muffindrake quit (Ping timeout: 240 seconds)
02:17:15	*	muffindrake joined #nim
02:27:05	*	audiofile quit (Quit: Default Quit Message)
03:06:32	*	rockcavera quit (Remote host closed the connection)
03:16:23	disruptek	!last Rebel
03:16:24	disbot	Rebel spoke in 12#nim 5 hours ago 12https://irclogs.nim-lang.org/03-09-2020.html#21:48:18
03:33:21	*	apahl quit (Ping timeout: 272 seconds)
03:34:09	*	apahl joined #nim
03:34:48	*	maier joined #nim
03:39:49	*	maier quit (Ping timeout: 264 seconds)
04:03:21	*	opal quit (Remote host closed the connection)
04:04:50	*	opal joined #nim
04:06:02	*	supakeen quit (Quit: WeeChat 2.9)
04:06:38	*	supakeen joined #nim
04:08:16	Prestige	If i have an array of ints, some 64 bit because of size, is there a way to implicitly cast the smaller ints (that could be int32 etc) to int64?
04:08:33	Prestige	e.g. https://play.nim-lang.org/#ix=2w5h
04:09:04	disruptek	sequences and arrays only hold a single type at a time.
04:09:12	Prestige	Yes
04:09:14	disruptek	they are all int64s in your example.
04:09:39	Prestige	It doesn't compile because 16 isn't an int64
04:10:07	disruptek	ah, specify the type of the first item: 16.int64
04:10:20	Prestige	I'm hoping I don't have to manually convert them all like that, is all
04:10:32	disruptek	another syntax: https://play.nim-lang.org/#ix=2w5j
04:10:39	disruptek	you only need to specify the first item.
04:10:50	Prestige	oh? interesting
04:11:11	Prestige	Thanks
04:11:14	disruptek	sure.
04:20:21	*	Prestige quit (Quit: Prestige)
04:25:58	*	Prestige joined #nim
04:31:10	*	Prestige quit (Quit: Prestige)
04:32:17	*	Prestige joined #nim
04:40:35	Prestige	Hm maybe you can shed some light on this disruptek. Someone is attempting to convert this C code to nim https://stackoverflow.com/questions/10699927/xlib-argb-window-icon/15595582#15595582
04:41:01	Prestige	I have everything converted except the cast the make in the XChangeProperty call
04:41:33	Prestige	It's an int64 array and they cast in to a pointer to an unsigned char, which seems wrong..
04:41:44	Prestige	cast it*
04:41:48	disruptek	neat.
04:41:53	Prestige	ThoughtS
04:41:55	Prestige	?
04:42:35	disruptek	you have an XChangeProperty call exposed to you in nim, right?
04:42:42	Prestige	Right
04:42:49	disruptek	what do the docs say it takes? i'm not bothered by the types.
04:42:52	disruptek	i'm just curious.
04:42:54	disruptek	memory is memory.
04:43:02	Prestige	Pcuchar
04:43:29	disruptek	that sounds like what they've cast it to, right?
04:43:51	Prestige	fails to compile - cant cast int64 to a Pcuchar. Not sure if there's an unsafe cast operator
04:44:10	disruptek	sure: cast[Pcuchar](buffer)
04:44:45	Prestige	hm oh I think I need the buffer addr
04:44:47	disruptek	what goes in that array?
04:44:52	disruptek	addr buffer
04:45:20	Prestige	I think that was the ticket. Thanks
04:45:29	disruptek	nice.
04:52:15	*	antranigv quit (Read error: Connection reset by peer)
04:52:39	*	antranigv joined #nim
05:07:09	*	narimiran joined #nim
05:35:42	*	maier joined #nim
05:40:25	*	maier quit (Ping timeout: 240 seconds)
05:49:11	*	solitudesf joined #nim
06:00:09	*	vicfred quit (Quit: Leaving)
06:10:25	*	maier joined #nim
07:17:06	*	vicfred joined #nim
07:18:13	*	vicfred quit (Max SendQ exceeded)
07:18:41	*	vicfred joined #nim
07:19:56	*	vicfred quit (Max SendQ exceeded)
07:20:26	*	vicfred joined #nim
07:21:11	*	vicfred quit (Client Quit)
07:30:57	*	PMunch joined #nim
07:42:34	*	hsh joined #nim
07:43:10	*	Guest63113 quit (Remote host closed the connection)
07:45:17	hsh	hi everyone. pretty basic question: I'm including a `tmpl` file in my Nim code to create an HTML list. The function signature is something like `proc genList(notes: seq[Note]): string =` and I'm getting a `Error: undeclared identifier: 'Note'`. The template works fine if I pass a `seq[string]` instead. Any tips?
07:46:35	*	PMunch quit (Ping timeout: 240 seconds)
07:50:03	Araq	add an 'import' statement to your template code
07:50:10	*	snowolf joined #nim
07:52:15	hsh	Araq: thanks!
07:53:35	*	krux02 joined #nim
07:57:03	hsh	OK, it's an improvement, I'm getting `This might be caused by a recursive module dependency:`. Just need to refactor this then :)
07:59:29	hsh	Araq: brilliant, works fine. Thanks for the help.
08:00:24	*	PMunch joined #nim
08:00:53	*	PMunch_ joined #nim
08:05:01	*	PMunch quit (Ping timeout: 264 seconds)
08:09:30	*	arecacea1 quit (Remote host closed the connection)
08:09:48	*	hnOsmium0001 quit (Quit: Connection closed for inactivity)
08:10:26	*	arecacea1 joined #nim
08:11:19	voidpi	I did some kind of hello world program and it worked, then copied the binary to another pc but it won't run
08:12:03	voidpi	it's looking for ld-linux-x86-64.so.2 in the wrong directory
08:12:49	Araq	some people swear by linking against musl instead.
08:13:56	voidpi	I was hoping for some magic switch or env var to just run it in the second machine
08:19:31	Araq	leorize[m] knows these things
08:19:43	Araq	let's see if he's around
08:20:27	voidpi	Araq: great, thanks
08:22:36	Araq	usually is also helps to link against an old libc version but I've never done it myself
08:24:52	voidpi	I think I rather test with musl
08:25:07	*	revere quit (Quit: quit)
08:25:47	Araq	also the ld-linux thing might come from one of your dependencies and not from libc
08:26:36	*	revere joined #nim
08:27:26	*	filcuc joined #nim
08:27:32	voidpi	import irc, asyncdispatch, strutils
08:27:54	*	revere quit (Client Quit)
08:27:58	voidpi	not really just the standard lib
08:28:21	*	snowolf quit (Remote host closed the connection)
08:28:26	*	revere joined #nim
08:28:48	filcuc	i fail to compile WebEngine with VS2017. Ninja just exist with an error1 but i don't get any information on the error. Is there a way to display more info during the build? or a log?
08:31:59	*	snowolf joined #nim
08:32:40	filcuc	ignore my message sorry
08:35:11	alehander92	no problem
08:41:10	Araq	"when convenience and speed are in conflict, prefer speed." hmm I don't think I agree
08:47:24	*	Trustable joined #nim
08:47:38	PMunch_	voidpi, you can see LD_LIBRARY_PATH to where it resides
08:49:15	Araq	PMunch_, ah thanks for clarifying
08:49:19	PMunch_	But it's weird that ld-linux should reside in a different directory, where was it on your original machine vs. the running machine
08:49:32	*	PMunch_ is now known as PMunch
08:51:12	alehander92	does the ci know to not run on draft pr-s
08:54:10	Araq	nope but we can ignore its results
08:59:34	Yardanico	The bridge is down for some reason, I got pinged by Clyybber :) I just finished my lessons in the uni for today, so I'll be going home to fix it
09:01:51	narimiran	alehander92: use `[ci skip]` in commit message to prevent CIs from running
09:02:20	Araq	narimiran, that doesn't work for most CIs we're using
09:02:37	Araq	but maybe these got an update and now it works, I dunno
09:02:39	alehander92	narimiran hey thanks, i thought it's for PR names
09:02:43	narimiran	Araq: IIRC it should work for all except those on sr.ht
09:03:40	alehander92	we have sourcehut ? :O
09:03:46	*	darrion_oakenbow left #nim ("Kicked by @appservice-irc:matrix.org : Idle for 30+ days")
09:08:57	euantorano	For sr.ht you can use `git push -o skip-ci` on git.sr.ht at least - not sure if it works with GitHub using dispatch.sr.ht to run builds through builds.sr.ht
09:09:20	euantorano	And yes, we have sourcehut builds for OpenBSD and FreeBSD
09:09:44	voidpi	PMunch: LD_LIBRARY_PATH=/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ./bot
09:09:46	voidpi	-bash: ./bot: No such file or directory
09:10:32	voidpi	program compiled in void x64, later copied to debian x64
09:11:02	voidpi	anyway, time to sleep
09:14:03	PMunch	voidpi, uhm, that error tells you that it doesn't find the program..
09:14:10	PMunch	Are you sure you're in the right directory?
09:14:21	PMunch	And LD_LIBRARY_PATH should point to a folder, not the file itself
09:52:31	*	FromDiscord quit (Remote host closed the connection)
09:52:45	*	FromDiscord joined #nim
09:52:50	Yardanico	bridge up
09:53:07	FromDiscord	<Yardanico> 1234
09:53:15	Yardanico	:ok_hand:
09:53:24	FromDiscord	<Clyybber> nice!
09:54:32	PMunch	Oh, was the bridge down?
10:00:17	FromDiscord	<Yardanico> From discord to irc
10:07:27	FromDiscord	<Clyybber> yep
10:07:45	FromDiscord	<Clyybber> Araq: Wdyt about moving the hoistedParam transformation into sem?
10:08:24	FromDiscord	<Clyybber> currently it only works at toplevel because lambdalifting doesn't operate on the AST post-hoistedParam
10:08:44	FromDiscord	<Clyybber> and its nicer for typed macros I think
10:08:51	Araq	yeah, totally agree
10:08:58	Araq	that must be done in sem phase 1
10:09:09	FromDiscord	<Clyybber> cool, I'll make a PR
10:09:33	Araq	zahary did it in transf in order not to mess with the macro system but it's better to expose the real nature of the call
10:09:41	FromDiscord	<Clyybber> yeah
10:09:59	FromDiscord	<Clyybber> otherwise macros have to deal with these weird syms (since those get inserted into sem1 anyways)
10:10:14	FromDiscord	<Clyybber> but they would only be declared later in transf
10:10:30	FromDiscord	<Clyybber> (edit) 'into' => 'in'
10:11:13	FromDiscord	<Varriount> @Yardanico Stuttgart is a bit less flat
10:11:30	FromDiscord	<Yardanico> We can move to <#371759607934353448> now :)
10:21:23	Araq	if the bridge is running once again, how come I don't understand your conversations? :-)
10:22:03	FromDiscord	<Clyybber> heh, because they refer back to a time where it was broken :D
10:33:39	*	audiofile joined #nim
10:35:18	*	audiofile quit (Client Quit)
10:45:47	FromGitter	<ynfle> Is there an easy way `nim check` a bunch of files or (a) folder(s) without a bash script?
10:46:47	Araq	check a file that imports all your modules
10:47:33	FromDiscord	<Clyybber> Araq: WDYT about introducing a newTreeI and newTreeIT in ast.nim, similar to newNodeI/newNodeIT?
10:47:50	Araq	fine
10:53:12	Araq	also if you want to, start an explicit NodeKind to NodeKind mapping so that we can evolve Nim's AST without affecting the macro system
10:53:44	FromDiscord	<Clyybber> oh, about that
10:54:25	FromDiscord	<Clyybber> I had an idea where we just allow duplicate case/set entries when one of them is {.deprecated.}
10:54:57	FromDiscord	<Clyybber> then case n.kind of nnkIfExpr, nnkIfBranch: continues to work
10:55:10	Araq	beware of that change
10:55:22	Araq	nnkIfExpr does not open a scope but nnkIfBranch does
10:55:52	FromDiscord	<Clyybber> oh?
10:55:57	FromDiscord	<Clyybber> huh, really?
10:56:10	Araq	nah
10:56:14	Araq	I'm wrong :-)
10:56:29	FromDiscord	<Clyybber> my whole world was about to crumble apart :D
10:56:58	Araq	but the idea is good, only certain node kinds introduce a scope and these must not be mixed with kinds that do not open a scope
10:57:17	FromDiscord	<Clyybber> yeah, but nkIfExpr should definitely open a scope IMO
10:57:22	Araq	so that passes and easily replicate the symbol lookup phase
11:07:00	alehander92	does `if` open a scope currently?
11:07:05	FromDiscord	<Clyybber> yeah
11:07:26	alehander92	huh, i am not sure i've used that
11:07:51	FromDiscord	<Clyybber> how would you "use" it?
11:08:01	FromDiscord	<Clyybber> its for safety.
11:08:02	alehander92	well, by defining a `let x` in my `if` :D
11:08:28	FromDiscord	<Clyybber> you wouldn't want to access a variable outside of your if that has been declared in a branch of the if thats never reached
11:09:06	alehander92	well, one can detect if it has been defined in all branches
11:09:16	FromDiscord	<Clyybber> yes one can do that
11:09:18	alehander92	but having multiple decl-s might look confusing
11:09:20	FromDiscord	<Clyybber> but one would be stupid to do that
11:09:36	FromDiscord	<Clyybber> because multiple decls still mean different symbols
11:09:42	alehander92	yeah yeah
11:09:44	FromDiscord	<Clyybber> except when using when
11:09:47	alehander92	just `let a: T` .. `a = ..; a = ..` is a bit annoying
11:09:48	FromDiscord	<Clyybber> then they mean the same symbol
11:09:56	alehander92	but the other solutions seem worse
11:10:12	alehander92	`var a: T..` *
11:10:40	alehander92	writing `let a = if .. ` is not always simple
11:11:06	alehander92	and in the other case one can't express that `a` is not changed after init, because he has to use `var`
11:11:19	alehander92	but this is a nitpick
11:11:38	FromDiscord	<Clyybber> wdym not changed after init
11:11:49	FromDiscord	<Clyybber> there is no change after init with the if expr
11:12:28	alehander92	well `var a: T .. ; if .. a = ..; else: a = .. ; # now nothing stops me from reassigning a even if what i wanted was for it to be let`
11:12:48	FromDiscord	<Clyybber> yeah
11:13:16	FromDiscord	<Clyybber> I thought about a generalization of mutability once, that is parameterized by the amount of allowed mutations
11:13:31	FromDiscord	<Clyybber> but its stupid, if expressions lead to better code anyways
11:15:26	alehander92	that would be pretty fun
11:15:33	alehander92	but yeah probably not good design
11:15:59	FromDiscord	<Clyybber> I think it could work well if you do it via proofs
11:16:01	FromDiscord	<Clyybber> like ATS
11:16:01	alehander92	but initialization vs usage phases seem as a common problem
11:16:03	alehander92	in design
11:16:16	FromDiscord	<Clyybber> where a mutation consumes a "mutable proof"
11:16:21	alehander92	e.g. i've read about other ideas even in functional languages
11:16:31	alehander92	to relax the language in initialization phase
11:16:34	FromDiscord	<Clyybber> and on variable init you can define how many mutable proofs you want a variable to have
11:17:28	alehander92	hm, can't one use a general form of affine typing
11:17:44	alehander92	where the limit is not 1, but `n`
11:17:56	FromDiscord	<Clyybber> yeah
11:18:00	FromDiscord	<Clyybber> thats what I outlined above
11:18:14	alehander92	but does this require having a proof system
11:18:20	FromDiscord	<Clyybber> no, but its the same
11:18:22	alehander92	that's what i wondered
11:18:33	alehander92	yeah, but no proofs <3
11:18:44	FromDiscord	<Clyybber> when you can consume proofs you have an affine type system
11:18:46	FromDiscord	<Clyybber> automatically
11:19:32	alehander92	and you have a "oh man i have a proof concept in this lang" user problem
11:20:06	FromDiscord	<Clyybber> yeah, sure. But affine typing isn't much easier
11:20:14	FromDiscord	<Clyybber> I mean its the same
11:20:24	FromDiscord	<Clyybber> but think about it, our proof could just be a number
11:20:46	FromDiscord	<Clyybber> now every mutation takes Mutable[T, static int]
11:20:55	FromDiscord	<Clyybber> and returns the same thing but with its static int decremented
11:21:21	alehander92	yeah, but you need to make it symbolic, no?
11:21:28	alehander92	to take branching into account
11:21:34	alehander92	and looping
11:21:40	FromDiscord	<Clyybber> yeah
11:21:53	FromDiscord	<Clyybber> so you get to the point of static analysis
11:21:56	alehander92	and now one has a Expr(max(n, 4 + a))
11:21:59	FromDiscord	<Clyybber> which is: proving
11:22:20	alehander92	yeah, but the point of lang design is not scaring your users away and hiding the prooving part
11:22:30	FromDiscord	<Clyybber> oh sure, you can hide that part
11:22:39	FromDiscord	<Clyybber> but IMO its easier to think about
11:22:41	alehander92	i have to look more at ats tho
11:22:51	alehander92	oh yeah
11:22:51	FromDiscord	<Clyybber> yeah, its a great language
11:22:56	FromDiscord	<Clyybber> well, the inside is great
11:23:02	FromDiscord	<Clyybber> the syntax is insane
11:23:16	alehander92	that's a bit similar to the cost problem : i tried to use symbolic computation once already in a compiler
11:24:11	alehander92	but after the simple loop i got into ughh a lot of problems haha
11:24:43	FromDiscord	<Clyybber> yeah exactly
11:24:54	FromDiscord	<Clyybber> ATS manages by a termination marker
11:25:00	FromDiscord	<Clyybber> or I forgot how its called
11:25:14	alehander92	or at least i just didn't continue
11:25:29	FromDiscord	<Clyybber> also, https://github.com/githwxi/ATS-Xanadu/commits/master
11:25:39	FromDiscord	<Clyybber> insanity
11:46:02	*	lritter joined #nim
11:47:41	*	Vladar joined #nim
11:59:28	*	newUser joined #nim
12:02:52	newUser	Hi, please can someone help: I have a private member of a c++ class 'double **R;' and want to translate it to nim. Some hints?
12:03:57	FromDiscord	<Rika> depensd on if its an "array" or just a double pointer (for some reason) but usually it'd be `R: seq[float64]`
12:04:14	newUser	a double pointer
12:04:29	FromDiscord	<Rika> `R: ptr ptr float64`
12:04:38	newUser	thanks :-)
12:04:47	FromDiscord	<Rika> i dont know why you'd want that but
12:05:06	FromDiscord	<Rika> are you sure that its not a dynamic array
12:05:16	newUser	R[i][i]
12:06:01	*	supakeen quit (Quit: WeeChat 2.9)
12:06:17	newUser	example: x[N-1] = d[N-1] / R[N-1][N-1]; for (i=N-2;i>=0;i--) { Sum = 0.0; for (j=i+1;j<N;j++) Sum += R[i][j]*x[j]; x[i] = ( d[i] - Sum ) / R[i][i];
12:06:33	FromDiscord	<Rika> use `R: seq[seq[float64]]`, that looks like a 2d array
12:06:37	*	supakeen joined #nim
12:06:44	newUser	k, thx
12:15:17	FromDiscord	<Lod> is the code for https://nimble.directory/ on github? I wanted to give some css love
12:18:34	FromDiscord	<dk> Can you use `nimscript.projectDir` in static context in a .nim file?
12:18:46	FromDiscord	<dk> ex. `static: discard projectDir()`
12:21:53	*	codic quit (Quit: killed)
12:21:53	*	BitPuffin quit (Quit: killed)
12:21:53	*	unclechu quit (Quit: killed)
12:21:55	*	lnxw37d4 quit (Quit: killed)
12:22:01	*	planetis[m] quit (Quit: killed)
12:22:03	*	silvernode[m] quit (Quit: killed)
12:22:05	*	skrylar[m] quit (Quit: killed)
12:22:05	*	MTRNord[m] quit (Quit: killed)
12:22:06	*	einichi quit (Quit: killed)
12:22:06	*	hnOsmium0001[m] quit (Quit: killed)
12:22:08	*	agentofuser[m] quit (Quit: killed)
12:22:12	*	guelosk[m] quit (Quit: killed)
12:22:12	*	torbencarstens[m quit (Quit: killed)
12:22:12	*	leorize[m] quit (Quit: killed)
12:22:12	*	rakgew[m]1 quit (Quit: killed)
12:22:13	*	slackytude[m] quit (Quit: killed)
12:22:14	*	alfabetacain[m] quit (Quit: killed)
12:22:14	*	GitterIntegratio quit (Quit: killed)
12:22:14	*	stisa[m] quit (Quit: killed)
12:22:19	*	jarredkenny[m] quit (Quit: killed)
12:22:19	*	ee7[m] quit (Quit: killed)
12:22:19	*	k0mpjut0r quit (Quit: killed)
12:22:19	*	vycb[m] quit (Quit: killed)
12:23:15	*	rockcavera joined #nim
12:25:05	*	newUser left #nim (#nim)
12:31:05	*	MTRNord[m] joined #nim
12:36:42	*	Zevv is now known as zv
12:37:12	*	zv is now known as Guest71338
12:43:20	PMunch	Going undercover Guest71338?
12:45:22	FromDiscord	<lqdev> @Rika actually, no
12:45:31	FromDiscord	<lqdev> using a seq in a seq is bad
12:45:46	FromDiscord	<lqdev> because it requires a double pointer deref
12:45:52	FromDiscord	<lqdev> when you can have just one
12:46:35	FromDiscord	<lqdev> it's better to use a flat `seq[float64]` and access its elements using `mySeq[x + y * width]`, where width is the width of one row
12:47:35	*	waleee-cl joined #nim
12:48:03	FromDiscord	<Rika> yeah but if they want total same data layout then
12:48:11	FromDiscord	<lqdev> @Lod https://github.com/FedericoCeratto/nim-package-directory
12:48:14	FromDiscord	<Rika> if they want to directly copy and translate
12:48:26	FromDiscord	<Rika> tell them it
12:48:32	FromDiscord	<lqdev> it's nice of you to improve the css, it's a bit half-baked now
12:49:01	alehander92	clyybber
12:49:12	FromDiscord	<lqdev> @Rika but that doesn't mean they can't gain some performance by using some better optimization :)
12:49:20	FromDiscord	<Rika> tell them about it
12:49:31	FromDiscord	<Rika> why are you telling me
12:49:39	alehander92	haha i see, well a bit strange commits
12:50:03	alehander92	i'll take a look at ats later really , i had to read about frama-c some of these days anyway
12:50:51	*	Vladar quit (Quit: Leaving)
12:51:03	*	pietroppeter joined #nim
13:01:22	*	k0mpjut0r joined #nim
13:01:23	*	hnOsmium0001[m] joined #nim
13:01:23	*	planetis[m] joined #nim
13:01:23	*	codic joined #nim
13:01:23	*	leorize[m] joined #nim
13:01:23	*	einichi joined #nim
13:01:23	*	GitterIntegratio joined #nim
13:01:23	*	unclechu joined #nim
13:01:23	*	BitPuffin joined #nim
13:01:24	*	lnxw37d4 joined #nim
13:01:28	*	silvernode[m] joined #nim
13:01:29	*	ee7[m] joined #nim
13:01:29	*	torbencarstens[m joined #nim
13:01:29	*	rakgew[m] joined #nim
13:01:29	*	alfabetacain[m] joined #nim
13:01:29	*	guelosk[m] joined #nim
13:01:29	*	skrylar[m] joined #nim
13:01:30	*	stisa[m] joined #nim
13:01:30	*	slackytude[m] joined #nim
13:01:30	*	agentofuser[m] joined #nim
13:01:30	*	vycb[m] joined #nim
13:01:37	alehander92	ok, back to work now
13:05:21	FromDiscord	<lqdev> @Rika alright
13:05:29	FromDiscord	<lqdev> newUser read my message above about using seq[seq[T]]
13:05:41	FromDiscord	<lqdev> it's a performance hindrance
13:05:48	FromDiscord	<lqdev> not just in nim tho
13:10:38	*	newUser joined #nim
13:15:31	newUser	lqdev: thx, I have read it from log. I want 1st to translate 1:1 from c++ to Nim and later like a fork optimize it.
13:16:16	alehander92	a very valid strategy
13:18:47	FromDiscord	<lqdev> cool
13:39:22	*	newUser left #nim (#nim)
13:40:47	alehander92	https://github.com/nim-lang/RFCs/pull/169 Araq this is the newer version
13:40:49	disbot	➥ Nilable and non-nilable types ; snippet at 12https://play.nim-lang.org/#ix=2w7p
13:44:30	*	NimBot joined #nim
13:44:59	alehander92	fixed a bit
13:45:24	alehander92	so, i think `default` itself should just lead to a warning *if* instantiated with certain types
13:45:37	alehander92	but a warning that leads to the high level invocation somehow
13:45:53	alehander92	because many collections can have many methods which use default similarly
13:46:52	alehander92	something like `default instantiated by setLen(seq[A]) instantiated by your code`
13:51:34	Araq	alehander92: move it from PRs to 'issues' please
13:54:24	disruptek	Araq: i think the jsonutils test is demonstrating a bug or, underspecified behavior at best. would like to get a second opinion.
13:54:33	disruptek	only repros under cpp.
13:55:11	disruptek	afaik it's the only failing test for mangling.
13:56:01	FromDiscord	<dom96> Can we agree that unqualified package imports are not a good idea? i.e. https://forum.nim-lang.org/t/6738#42112
13:57:11	FromDiscord	<Yardanico> Why? I've always liked them
13:57:19	Araq	dom96: ever since we got the 'import path / [moduleA, B]' syntax qualified imports are nice enough to work with
13:57:29	Araq	so I agree, yes.
13:57:47	Araq	we don't have to support them (except for backwards compat yada yada)
13:57:49	disruptek	cblake is right.
13:58:22	FromDiscord	<dom96> Araq: what does backwards compat have to do with it
13:58:25	FromDiscord	<dom96> (edit) 'it' => 'it?'
13:58:43	alehander92	Araq ok, but then we are using the comments: i guess this is ok, if i link
13:58:50	alehander92	losing the comments*
13:59:01	FromDiscord	<dom96> Yardanico: You've always liked unqualified imports? You've never had them
14:00:24	FromDiscord	<Yardanico> Ah, you meant a different thing
14:01:02	FromDiscord	<Yardanico> I thought you were talking about unqualified imports in general
14:01:36	disruptek	why would i want to have to `import frosty / frosty` instead of `import frosty`?
14:01:54	FromDiscord	<dom96> lol
14:01:55	shashlick	There's no easy way to do what cblake suggests
14:02:06	FromDiscord	<dom96> disruptek: I agree with you there
14:02:23	disruptek	i don't think i understand this issue.
14:02:36	FromDiscord	<dom96> What definitely shouldn't be possible is `import utils` instead of `import frosty/utils`
14:02:43	FromDiscord	<dom96> which is what cblake suggests
14:02:54	disruptek	well, i agree.
14:02:57	disruptek	with you.
14:03:29	disruptek	i always qualify my imports and it has been a problem with nimble.
14:03:39	disruptek	so, yeah, i'd love to see that fixed.
14:03:58	disruptek	used to be that i couldn't install nimph because nimph had qualified imports for nimph/foo.
14:04:01	FromDiscord	<lqdev> i just realized that nimble says `Success: Package Nim created successfully` after using `nimble init`
14:04:07	FromDiscord	<lqdev> @dom96 i'm pretty sure that's a typo
14:04:11	FromDiscord	<lqdev> or bug
14:04:18	FromDiscord	<lqdev> as my package is not called `Nim`
14:04:33	disruptek	everyone's so sensitive today. 😁
14:04:35	FromDiscord	<dom96> sure, make an issue
14:04:53	disruptek	yeah, we need a separate place to bikeshed this.
14:05:28	FromDiscord	<dom96> To be fair, there is the tricky thing with local imports
14:06:03	FromDiscord	<dom96> if I have frosty/{utils.nim,foobar.nim} then I would typically write `import utils` in `foobar.nim` not `import frosty/utils`
14:06:18	disruptek	that's wrong, imo.
14:06:41	disruptek	iirc you can `import ./utils` if you want to be a rebel.
14:06:52	FromDiscord	<dom96> yeah, I'm leaning towards agreeing although I haven't thought through all the ramifications
14:06:55	FromDiscord	<lqdev> then what do you suggest? ruby's `require_relative`?
14:07:08	FromDiscord	<lqdev> 'cause the name of that thing is hideous
14:07:20	FromDiscord	<lqdev> ./utils could work
14:07:25	FromDiscord	<lqdev> but it's just weird
14:07:39	FromDiscord	<lqdev> looks like node.js, not nim
14:07:53	disruptek	i just `import frosty/utils`. it's what you want.
14:08:02	disruptek	it tells exactly the story you need to tell.
14:08:17	Araq	no.
14:08:25	FromDiscord	<lqdev> oh wait
14:08:27	FromDiscord	<lqdev> that's my bad
14:08:37	FromDiscord	<lqdev> @dom96 i created a package in ~/Coding/Nim…
14:08:39	Araq	you 'import utils' because "local" imports are resolved relative to the current file
14:09:18	FromDiscord	<Rika> didnt someone here have an issue because of unqualified imports recently
14:09:19	Araq	nothing tricky about it, Nim works this way since 0.14 or something
14:09:28	disruptek	not my fault it was poorly designed.
14:09:49	disruptek	rika: it was yesterday, iirc.
14:09:53	Araq	it wasn't poorly designed.
14:10:01	disruptek	not my fault it was underspecified.
14:10:24	Araq	it's well documented in nimc.html
14:10:44	disruptek	great, our ambiguous syntax is well-documented.
14:10:51	disruptek	let's put that on the landing page, leorize.
14:11:25	Araq	ha our documentation is wrong though :-)
14:11:54	disruptek	when you've finished iterating, lemme know so i can file bugs.
14:12:08	Araq	https://nim-lang.org/docs/nimc.html#compiler-usage-search-path-handling well the docs could be better
14:12:50	Araq	and " If multiple files are found an ambiguity error is produced." is wrong, afaict, Nim never did that
14:14:34	FromDiscord	<dom96> Yeah, with Nim's current import rules, `import frosty/utils` could result in unexpected behaviour
14:14:48	FromDiscord	<dom96> compiling frosty will fail unless it's installed
14:15:01	FromDiscord	<dom96> and if an older version is installed it'll pick that older version(!)
14:15:49	FromDiscord	<dom96> Which reminds me of another thing that's missing from @shashlick's proposal: what do we do about --nimblePath? I actually liked cblake's suggestion to replace it with a nim.cfg file in ~/.nimble/pkgs/
14:16:31	Araq	what's "Missing"? there is no --nimblePath, nimble creates a section with --path statements
14:17:06	FromDiscord	<dom96> Once again... ↵globally installed packages make development easier
14:17:24	FromDiscord	<dom96> I don't want to `nimble init` every little script that happens to depend on jester (or another nimble package)
14:17:40	alehander92	https://github.com/nim-lang/RFCs/issues/250
14:17:42	Araq	you're pretty alone with this opinion though
14:17:42	disbot	➥ Type checking for nil dereference: nilable and not-nilable types ; snippet at 12https://play.nim-lang.org/#ix=2w7D
14:17:43	FromDiscord	<dom96> Nim should feel like a scripting language where possible
14:17:48	alehander92	ok this is the issue
14:18:03	Araq	globally installed packages never simplified anything for me
14:18:13	FromDiscord	<dom96> I don't think I am.
14:18:28	Araq	besides, you can always write --path in your global config for packages you keep using for everything
14:18:58	alehander92	and someone needs to label it 2020 because i just closed 1/4 goals with the old PR thing
14:18:59	Araq	you don't need Nimble at all for scripts
14:19:09	FromDiscord	<dom96> I install package with Nimble already
14:19:21	FromDiscord	<dom96> it should make them available globally for me
14:19:41	FromDiscord	<dom96> (edit) 'package' => 'packages'
14:19:54	Araq	so invent 'nimble install --global foobar'
14:20:47	FromDiscord	<dom96> sure, I can live with that
14:20:48	alehander92	but why would you distribute scripts with nimble: ruby is scripting lang and still gems usually have a well defined structure
14:21:17	alehander92	so if a script deserves to be a package, it seems it should be easy to just `init` and drop it in the right place
14:21:22	FromDiscord	<dom96> As long as you allow that nim.cfg file to be loaded implicitly by Nim 🙂
14:35:09	*	Trustable quit (Remote host closed the connection)
14:45:27	stefantalpalaru	What's the best way to dynamically allocate a "cstring" and have it be garbage collected? Do I need to keep a reference to an associated "string" instance to control its lifetime?
14:49:50	*	Vladar joined #nim
14:54:09	FromDiscord	<Yardanico> Maybe you just want to have a string and convert to cstring when needed?
14:56:26	*	maier quit (Ping timeout: 258 seconds)
14:59:14	*	narimiran quit (Ping timeout: 260 seconds)
15:02:20	FromGitter	<brentp> normally, i come here to get help with a question. for a positive change, here's a paper for software i wrote in nim that's just out (and pretty widely used already): https://genomemedicine.biomedcentral.com/articles/10.1186/s13073-020-00761-2
15:03:03	FromDiscord	<Rika> nnice
15:05:49	alehander92	woow
15:05:51	alehander92	nice !
15:14:34	FromDiscord	<dom96> whoa, Nim is literally helping cure cancer?
15:15:32	FromGitter	<brentp> i guess you could say that. though i wouldn't put it so boldy.
15:15:53	FromDiscord	<dom96> aww, I was hoping I could tweet that. That would be some nice like-bait 🙂
15:17:23	FromDiscord	<dom96> There is a genomics startup that used to use Nim btw https://github.com/onecodex/
15:17:47	FromDiscord	<dom96> or maybe they still do, no idea 🙂
15:19:50	FromDiscord	<dom96> Very nice work though, congrats on getting that published brentp!
15:20:13	shashlick	sorry couldn't talk earlier - `import frosty/utils` only when there's a conflict is not possible
15:21:05	Araq	stefantalpalaru: yeah
15:21:08	shashlick	if like cblake suggests, we eliminate the version from `~/.nimble/pkgs/frosty-0.1.0` and add `--path:~/.nimble/pkgs` along with `~/.nimble/pkgs/frosty`, it will work
15:21:21	shashlick	but if there's a srcDir, not anymore
15:22:00	shashlick	so if you said `import utils`, it would work fine if there's no second `utils.nim` , if there's two, you can qualify with `frosty/utils`
15:22:20	Araq	if you're inside 'frosty' it's always 'frosty/utils'
15:22:25	shashlick	but the srcDir breaks that option, not to mention the fact that the version in dir name makes the directory unique
15:22:28	FromDiscord	<dom96> yes, IMO it's not important that it is or isn't possible
15:22:34	FromDiscord	<dom96> it's just a bad idea overall
15:22:38	Araq	if you're inside 'frosty' then 'utils' is always interpreted as 'frosty/utils'
15:22:54	Araq	(clarified my sentence)
15:22:54	shashlick	I agree it is confusing for the user
15:23:00	FromDiscord	<dom96> There is a good design reason for not enforcing module names when calling procs
15:23:12	FromDiscord	<dom96> there is no such reason for module imports
15:23:25	shashlick	at least for now, i feel we need to let the proposal proceed since we aren't really changing the namespace headache
15:23:26	alehander92	brentp better to post on forum
15:23:29	shashlick	maybe fight it another day?
15:23:49	Araq	btw please remember that we already have 'import pkg / frosty / utils'
15:24:29	Araq	there is nothing to be added to the Nim compiler, you can disambiguate already
15:24:44	FromDiscord	<dom96> shashlick: your proposal is currently just new features, I think it's worth discussing the real backwards incompatible changes
15:25:39	Araq	rubber duck time
15:25:45	FromDiscord	<dom96> And what we should discuss is well explained by my last point in https://forum.nim-lang.org/t/6738#41989
15:26:04	FromDiscord	<dom96> yay, my awesome post loading still works in the forum
15:27:35	shashlick	these aren't really many changes
15:27:53	shashlick	but what specific concerns do you want to discuss
15:29:03	shashlick	for backwards compatibility, there's no impact on nim, but as mentioned, an older nimble will not work in some scenarios
15:29:37	FromDiscord	<dom96> Like I wrote in that post
15:30:00	FromDiscord	<dom96> I want to either enforce package structures with an error or have Nimble change the directory structure and get rid of those warnings
15:30:08	FromDiscord	<dom96> or some other solution that I haven't thought of
15:30:34	shashlick	i'm saying let's leave the warnings and not change package structure
15:31:06	shashlick	cause warnings = no change from current behavior, which can be refined later
15:31:24	shashlick	but at least you get the other improvements which is same package before and after install, and lesser confusion
15:31:29	FromDiscord	<dom96> and I'm saying we should decide how to refine it
15:31:32	shashlick	not to forget the nim.cfg interop
15:31:32	Araq	change the package structure and disable the warnings if 'nimbleVersion = 2' can be found in the .nimble file
15:31:35	FromDiscord	<dom96> that's more important than any of the rest of the proposal
15:32:06	shashlick	Araq: it cannot be on a per package basis
15:32:08	FromDiscord	<dom96> and also, I don't think you should care too much about backwards compat (within reason)
15:32:15	Araq	shashlick: why not?
15:32:16	FromDiscord	<dom96> Nimble isn't 1.0
15:32:41	shashlick	i have identified the impact that's all, there very little change related to handling compat
15:32:58	FromDiscord	<dom96> Indeed, regarding what Araq is leaning towards
15:33:13	FromDiscord	<dom96> Your proposal focuses on Nimble not editing the directory structure of a package
15:33:15	FromDiscord	<dom96> and installing it as-is
15:33:24	FromDiscord	<dom96> but it looks clear to me that we will either be left with these warnings
15:33:30	shashlick	yes and doing that warrants the nim.cfg change
15:33:31	FromDiscord	<dom96> or we will have to get NImble to modify the package structure
15:33:38	FromDiscord	<dom96> this is why it's important to think about this
15:34:10	shashlick	no one likes the warnings, so we are softening it, changing pkg structure is not liked at all
15:34:42	FromDiscord	<dom96> the warnings are pointless if they are not eventually enforced
15:34:47	FromDiscord	<dom96> and I do not see how you have softened them
15:34:52	Araq	changing the structure is what brought us today's problems
15:34:55	shashlick	not all warnings have to be acted on
15:35:17	Araq	do not change the structure and remove the warnings
15:35:23	FromDiscord	<dom96> these ones should be
15:35:28	shashlick	that's just a middle ground between cblake and your position
15:35:40	FromDiscord	<dom96> a package with a dash shouldn't be installed either
15:35:45	FromDiscord	<dom96> and yet it /could/
15:35:46	Araq	for backwards compat look inside the .nimble file
15:36:21	FromDiscord	<dom96> a package should be valid to be installed. There should be no middle ground.
15:36:38	Araq	and make 'nimble init' produce 'nimbleVersion = 2' so that all new packages start with the new better way of doing things
15:39:27	shashlick	Araq that doesn't work cause nimble installs packages globally
15:39:50	Araq	well you know my opinion on that one ;-)
15:40:11	shashlick	Plus why does this need to be opt in
15:40:20	shashlick	What's the value in delaying it
15:40:28	Araq	so that all the other packages keep working
15:40:54	Araq	plus maybe we need 'nimbleVersion = 3' some day
15:41:11	Araq	why pretend to know the future
15:41:12	FromDiscord	<dom96> What are you even proposing to change that's backwards incompatible?
15:41:24	FromDiscord	<dom96> removing warnings doesn't break packages
15:41:55	*	bouzu_ joined #nim
15:41:56	Araq	well 'install' means 'git clone', there is no srcDir etc
15:42:08	shashlick	Nimble version doesn't help with any of the compat issues
15:42:12	Araq	that's incompatible with today's nimble, I think
15:42:27	shashlick	Yes that's what is proposed
15:42:40	FromDiscord	<dom96> huh, srcDir remains
15:42:59	shashlick	Moving stuff around is gone
15:43:18	shashlick	srcDir only remains to know the right path to tell Nim
15:43:26	FromDiscord	<dom96> yeah, so nothing breaks
15:43:34	FromDiscord	<dom96> Don't see where the breakage supposedly occurs
15:43:38	*	arecacea1 quit (Remote host closed the connection)
15:43:49	shashlick	When you use older nimble
15:44:01	shashlick	People use choosenim to go back and forth
15:44:19	FromDiscord	<dom96> Yeah, `nimbleVersion = 2` won't save you there lol
15:44:28	FromDiscord	<dom96> and it has nothing to do with global installs
15:44:35	*	arecacea1 joined #nim
15:44:47	FromDiscord	<dom96> but honestly, this is besides the point.
15:44:48	shashlick	And it's additional complexity that doesn't add any value - maintaining the status quo
15:45:01	FromDiscord	<dom96> Let's focus on this important question of package structure
15:45:12	shashlick	But that's the whole point
15:45:32	shashlick	Something that's not impacted is gating this proposal
15:45:48	shashlick	It's not about priorities but taking a step forward
15:46:05	FromDiscord	<dom96> Why can't we have a decision on this one thing too?
15:46:15	FromDiscord	<dom96> It relates to these proposals and whether they make sense
15:46:39	shashlick	Cause I can't code anything until then and it doesn't impact the rest of this proposal
15:47:21	shashlick	If I took out the first para, it wouldn't even be relevant
15:47:34	FromDiscord	<dom96> It does impact this proposal
15:47:54	FromDiscord	<dom96> This proposal aims to ensure Nimble installs packages as they are
15:48:09	shashlick	The goal is to not change the structure - any namespace improvements need to build on that
15:48:10	FromDiscord	<dom96> but if we decide in the future that we need to modify packages because of their package structure then we'll be back to square one
15:48:13	FromDiscord	<dom96> so what would be the point?
15:48:32	FromDiscord	<dom96> There is only two approaches, either you make package structure warnings a fatal
15:48:36	FromDiscord	<dom96> or you modify the package structure
15:48:55	FromDiscord	<dom96> It's not something that should take a long time to decide
15:49:21	shashlick	If you can think of a way to handle the srcDir thing, we can reach a solution
15:49:26	FromDiscord	<dom96> but if you opt for the second option then this whole proposal doesn't feel correct
15:49:29	shashlick	Qualify if conflict
15:49:55	FromDiscord	<dom96> what's the `srcDir` thing?
15:52:34	shashlick	if you say we do away with the warnings, then it means we provide some contingency for users when conflicts do happen
15:52:51	shashlick	which means a user needs to qualify what he means when the source says `import utils`
15:53:12	shashlick	actually even that doesn''t work - cause a user can edit his code, but not a dependent package's code
15:53:17	*	vicfred joined #nim
15:53:39	shashlick	I was referring to this - https://irclogs.nim-lang.org/04-09-2020.html#15:20:13
15:53:55	shashlick	if user says `import utils` and Nim says there's a conflict - multiple modules with same name
15:54:04	shashlick	then user would need to specify `import frosty/utils`
15:54:31	FromDiscord	<dom96> yes, you'd need to git clone a package into a `pkgname-0.1.0/pkgname` directory
15:54:35	shashlick	but that breaks if there's a srcDir cause `~/.nimble/pkgs/frosty/src/utils.nim` won't resolve with `--path:~/.nimble/pkgs`
15:54:43	FromDiscord	<dom96> or if it has a `srcDir` set then you'd need to create that
15:54:58	FromDiscord	<dom96> hence why I say "Nimble would need to modify the package structure"
15:55:28	shashlick	i'm not on that square - i say we inform the community why nimble is warning you - today it just says what to do, not why
15:55:38	FromDiscord	<dom96> Nimble would need to mv pkgname-0.1.0/src/ pkgname-0.1.0/src/pkgname/
15:56:06	FromDiscord	<dom96> I'm not saying I think this is what we should do
15:56:09	FromDiscord	<dom96> I'm just outlining the options
15:56:26	FromDiscord	<dom96> If we stick to the warnings then they should become fatals
15:56:32	FromDiscord	<dom96> and I believe that strongly
15:57:31	FromDiscord	<whisperdev> Would anyone have a clue why this shows like this?
15:57:44	FromDiscord	<whisperdev> https://media.discordapp.net/attachments/371759389889003532/751471065548455956/unknown.png
15:58:01	shashlick	yes considering all options of mangling package structure are surprising and confusing, i'm not for that
15:58:44	FromDiscord	<dom96> That's fine, but then you should make that obvious since a lot of people seem to have these warnings
15:58:50	FromDiscord	<dom96> Maybe they will come up with a better alternative
15:58:51	FromDiscord	<lqdev> @whisperdev probably UTF-16
15:59:18	FromDiscord	<lqdev> each UTF-16 character takes 2 bytes, which is more than the size of `char`
15:59:34	shashlick	I still don't see why cblake thinks https://forum.nim-lang.org/t/6738#42106 is easy
15:59:40	mipri	echo 'hello' | iconv -t utf16|od -c # prints: 0000000 377 376 h \0 e \0 l \0 l \0 o \0 \n \0
16:00:04	FromDiscord	<lqdev> try storing your string as a seq[uint16], and to print it, convert them to Runes, and print that
16:00:13	shashlick	so the other option is to put all nimble packages in pkgname subdir, break the whole ecosystem and force everyone to fix their imports
16:00:34	shashlick	but that would still require package structure changes cause you'd need srcDir/pkgname
16:00:43	FromDiscord	<dom96> yes, that would be part of what I suggested
16:00:50	*	hnOsmium0001 joined #nim
16:01:06	FromDiscord	<whisperdev> With wide string i get a chinese character there
16:01:07	Araq	I don't understand what's wrong with my proposal
16:01:10	FromDiscord	<whisperdev> https://media.discordapp.net/attachments/371759389889003532/751471924772732938/unknown.png
16:01:14	shashlick	Araq: which one
16:01:18	FromDiscord	<dom96> I just want to make sure that people aren't under the illusion that you are going to get rid of the warnings
16:01:33	shashlick	easiest thing is to do nothing - sit with warnings, no errors - no impact on community
16:01:44	Araq	shashlick: 'git clone', remove warnings for .nimble files that contain 'nimbleVersion = 2'
16:02:13	shashlick	Araq: how does that help users who do run into namespace conflicts?
16:02:36	shashlick	of course, we do nothing today to help them either but at least the incidence is lower, in theory because we warn
16:02:43	Araq	there are no namespace conflicts.
16:02:53	FromDiscord	<dom96> shashlick: I'm also worried that the lock file changes are going to throw a spanner into this proposal (or your implementation of it will make merging lock files impractical)
16:03:41	shashlick	Araq: why do you say there's no conflicts - if two packages not owned by the user export utils.nim, what is the user supposed to do? Make a local copy and modify the file?
16:03:53	shashlick	dom96: why does it affect lock files
16:04:11	FromDiscord	<dom96> shashlick: no idea if it does, just worried it might.
16:04:22	Araq	shashlick: you cannot "export utils".
16:04:50	FromDiscord	<whisperdev> I dont understand this <:(
16:04:50	Araq	it's always 'import x / utils' vs 'import y / utils'
16:05:26	shashlick	what if a package structure is such that `~/.nimble/pkgs/frosty-0.1.0/utils.nim` exists?
16:05:33	Araq	whisperdev: please show us some code snippet
16:05:54	*	bouzu_ quit (Quit: Leaving)
16:06:07	shashlick	where do x and y come from
16:06:28	Araq	shashlick: that's either 'import "frosty-0.1.0" / utils ' or 'import frosty / utils'
16:06:40	shashlick	does compiler already have code such that it resolves `import frosty/utils` today?
16:07:21	shashlick	what if a dependent of frosty simply has `import utils` with the hope that it will get frosty's copy of it
16:07:24	Araq	no, I added code for that 5 years ago but it got downvoted and removed again
16:07:28	shashlick	a user can edit his own code
16:08:05	shashlick	but if you have another dependency that does this, you have to manually edit it
16:08:23	Araq	> what if a dependent of frosty simply has `import utils` with the hope that it will get frosty's copy of it
16:08:29	Araq	that's not supported.
16:08:34	shashlick	so the code doesn't exist today, and tying to a version in the import statement isn't thrilling either
16:08:52	Araq	it's not "thrilling" but acceptable
16:09:11	Araq	you can always complain about the code quality of a package you happen to rely on
16:09:49	Araq	ideally the maintainer is responsive and helpful so that 'import "frosty-0.1.0" / utils ' is only a temporary hack
16:09:54	FromDiscord	<whisperdev> I have something like this https://play.nim-lang.org/#ix=2w84
16:10:19	shashlick	Araq: but then the basic rule is to not export stuff without a namespace
16:10:50	shashlick	the two rules identified in the proposal - https://github.com/nim-lang/nimble/wiki/Package-structure-and-Interop#namespace-guidance
16:11:02	shashlick	so what's wrong with nimble enforcing it
16:11:25	Araq	whisperdev: this part is wrong cast[LPBYTE](&buffer2)
16:11:41	Araq	(I think)
16:11:47	shashlick	https://github.com/nim-lang/nimble/blob/master/src/nimblepkg/packageparser.nim#L127 is our warning today - it can be improved as suggested in the proposal
16:12:02	shashlick	a blog about why all this matters
16:12:39	Araq	shashlick: it's wrong because it's not Nimble's business to enforce these things, maybe I write a single package with two different "namespaces"
16:13:20	FromDiscord	<whisperdev> Araq: I am kinda clueless.https://docs.microsoft.com/en-us/windows/win32/api/winsvc/nf-winsvc-queryserviceconfig2a
16:13:22	shashlick	the other option is to force a namespace with nimble and nim resolves `import frosty` as `frosty/frosty`, but it still breaks with srcDir which will need pkg structure changes, and break all existing nim code
16:13:26	FromDiscord	<whisperdev> This says it's lpbyte
16:13:46	Araq	it's wrong because it's pessimistic, always assuming there will be a conflict when in reality conflicts are rare.
16:14:05	shashlick	Araq: which is why I feel a clean warning is better than what we have now along with additional guidance on the topic
16:14:29	Araq	you can have a "nimble nanny" command that outlines best practices and produces warnings or errors
16:14:44	shashlick	nimble check can be that nanny
16:14:57	Araq	but it should be opt-in, most of the time the warnings are more annoying than helpful
16:15:00	shashlick	so we could remove it from nimble install and ensure nimble publish calls check first
16:15:18	*	Kaivo quit (Quit: WeeChat 2.9)
16:15:45	shashlick	most people don't know about any of this stuff so documentation is warranted nonetheless
16:16:04	Araq	whisperdev: yes but your variable is a "wide string", var buffer2 = newWString(needed)
16:16:06	FromDiscord	<dom96> sorry, but that's not good enough
16:16:11	FromDiscord	<dom96> publishing is a single-time thing
16:16:26	FromDiscord	<dom96> packages grow and gain new modules and can then break the package structure
16:16:55	shashlick	maybe a git pre-commit hook that calls nimble check 😄
16:17:04	FromDiscord	<dom96> I disagree with Araq's view on this, we should be strict here and allow people to force an install (with a `--force` or something)
16:17:07	FromDiscord	<dom96> but we should fatal by default
16:17:11	shashlick	i think the basic message is that people don't want more policing
16:17:38	shashlick	what's a good example of nim being relaxed in some other aspect like this
16:17:44	Araq	yes, indeed. I don't want more of it either
16:17:48	FromDiscord	<dom96> I think that there are a few people that didn't understand it and got annoyed, but there are also dozens that successfully fixed the issues and were happy
16:17:59	FromDiscord	<dom96> You don't hear from them of course
16:18:06	mipri	or add a nimble subcommand to add and push release tags for you, to do such checks
16:18:13	FromDiscord	<whisperdev> Araq: so what should I do?
16:18:20	FromDiscord	<dom96> so it's unfair to listen to the people, most of whom don't ever want to use Nimble anyway, about this
16:18:34	Araq	look. the way Nimble does it is completely not feasible for a mixed environment.
16:18:45	Araq	you don't get to decide on Godot's directory layout
16:18:59	FromDiscord	<dom96> how is it not?
16:19:30	Araq	yet if I could "nimble install godot" and it would all work without additional build steps it would be sweet. so design for flexibility, not for "omg, what about a conflict"
16:19:46	FromDiscord	<dom96> there are package management systems that are far more strict, I would argue that most Linux's are far more strict with their directory layouts
16:19:53	Araq	I don't use godot and Nimbus in the same project.
16:19:56	FromDiscord	<dom96> and the advantages of those are dubious
16:20:20	FromDiscord	<dom96> there is nothing about these rules stopping godot from working
16:20:31	FromDiscord	<dom96> I don't see how it would prevent a monorepo from working well
16:20:53	Araq	as I said, what if my package has two "namespaces"
16:21:02	FromDiscord	<dom96> then you create another package
16:21:19	FromDiscord	<dom96> or you nest the namespaces
16:21:29	Araq	maybe because I wrap Godot which has two namespaces
16:22:07	shashlick	dom96: what about the proposal doesn't work for a monorepo
16:22:16	shashlick	or multi package repos
16:22:36	FromDiscord	<dom96> shashlick: what? I never intended to imply that
16:22:49	FromDiscord	<dom96> Not sure how you got that from what I said
16:22:54	shashlick	okay never mind
16:23:11	Araq	whisperdev: var buffer2 = newString(needed)
16:23:32	shashlick	okay so if one says no warning, other says error, i say warning continues to be the middle ground still
16:24:38	Araq	shashlick: 'import "frosty-0.1.0" / utils ' is already the wrong question
16:24:42	shashlick	fact of the matter is that people can still install packages outside the nimble package list or nimble altogether and run into issues so in some sense, this doesn't need to be nimble's problem
16:25:05	Araq	frosty's URL does not include the version, the version part of the directory was created by Nimble
16:25:35	Araq	you're working around problems of Nimble's own creation
16:25:43	shashlick	yes but that's legacy now
16:25:56	shashlick	either we break everything or build on this
16:26:01	FromDiscord	<whisperdev> Araq: If I do that I get the string like in the first screenshot
16:26:34	*	a_chou joined #nim
16:27:13	FromDiscord	<dom96> Araq: how else should Nimble install multiple versions of the same package side-by-side?
16:27:45	Araq	as I said, make deps project local and all these problems disappear
16:27:47	alehander92	why can't import x just check for `x/x` if other matches don't exist
16:28:15	FromDiscord	<dom96> Araq: until you get to a situation where two different of the same package are required
16:28:22	FromDiscord	<dom96> (edit) 'Araq: until you get to a situation where two different ... of' => 'Araq: until you get to a situation where two differentversions'
16:28:31	Araq	yeah yeah, still never happened in my entire life.
16:28:43	Araq	here is what did happen: Nimble prevents me from getting work done.
16:29:00	alehander92	wait, how does nimble support two packages with diff versions
16:29:05	FromDiscord	<dom96> it doesn't
16:29:11	FromDiscord	<dom96> but it should
16:29:23	alehander92	yes, it should
16:29:30	Araq	if I have a version conflict I prefer to update the code so that I don't get the code bloat of two very similar libraries
16:29:45	FromDiscord	<dom96> but it's okay, Araq didn't run into this so it won't be a problem for us ever 🙂
16:29:46	alehander92	but this is never the reason
16:29:55	alehander92	but if you depend on A and B which depend on those versions
16:30:22	alehander92	you need to upstream an upgrade to A or B
16:30:41	Araq	dom96: well focussing on issues that people really have rather than anticipated non-issues seems a smart thing to do.
16:30:59	FromDiscord	<dom96> No, these are anticipated real issues
16:31:17	FromDiscord	<dom96> The only reason Nim developers haven't run into it yet is because the package ecosystem is too small
16:31:19	Araq	eps because these issues have no good automatic solution at all
16:31:26	FromDiscord	<whisperdev> yes please lets focus on the issue i have 😄
16:31:50	Araq	whisperdev: you confuse QueryServiceConfig2A with QueryServiceConfig2W
16:31:53	*	Kaivo joined #nim
16:32:39	FromDiscord	<whisperdev> I get the 1st screenshot with or without Config2W and newString
16:34:27	shashlick	in order for things to be as desired, we have to do away with srcDir, plus only allow one version at a time
16:34:58	shashlick	and whatever is desired, it will not coexist with older nimbles
16:35:02	*	snowolf quit (Remote host closed the connection)
16:35:22	FromDiscord	<dom96> haha no way
16:35:39	FromDiscord	<dom96> but happy to discuss it nonetheless
16:35:52	shashlick	and even then there's issues cause if someone has `import utils` and `requires frosty`, they have no recourse when a conflict happens
16:36:07	FromDiscord	<dom96> I would actually prefer to enforce a `src` dir
16:36:46	shashlick	then you will need `frosty-0.1.0/src/frosty/utils`
16:36:56	shashlick	that's even more joy
16:37:09	*	snowolf joined #nim
16:38:04	Araq	dom96: 1000 Nimble packages are representative of what is yet to come, open any book on statistics to confirm
16:38:31	shashlick	it's easy to delegate to the package owner - if they export random crap and it bites their ass much later, they will still come back to figure out how to resolve the problem without breaking their users
16:38:32	Araq	you're making up these complex scenarios all the while the *simple* stuff remains almost unusable
16:38:34	FromDiscord	<dom96> Araq: yeah, and actually, now I remember that disruptek ran into this very problem
16:38:40	FromDiscord	<dom96> so it's already proving my point
16:39:10	FromDiscord	<dom96> now you'll say "well, he can just fix the upstream package"
16:39:16	shashlick	so if we keep it all open then there still needs to be guidance for **when** things go wrong
16:39:19	FromDiscord	<dom96> You do realise I can say the same to all these problems you seem to be having, right?
16:39:33	shashlick	and users will have to bear the brunt when they want to use two popular conflicting pacakges
16:39:51	FromDiscord	<dom96> but once you have a web of thousands of packages depending on each other then it will be a nightmare
16:40:08	FromDiscord	<dom96> and no, the current 1000 packages aren't enough statistically to understand these issues
16:40:15	FromDiscord	<dom96> the depth of dependencies is almost never more than 1
16:40:36	shashlick	the fact though is that both adding or removing restrictions is disruptive, at any point, now or later
16:40:44	Araq	cblake created stats about it, you ignore them because they don't suit your opinion.
16:42:04	Araq	but I'm out, do what you want, solve problems that have no good solution, meanwhile I remove multiple foobar entries from $nimble-dir in order to gain control over my builds
16:42:34	FromDiscord	<dom96> huh? Wasn't cblake arguing for what you already agreed wasn't the way forward?
16:42:49	FromDiscord	<dom96> pretty sure that's what his stats supported, i.e. making it possible to not qualify imports
16:43:02	FromDiscord	<dom96> version conflicts are a whole different thing entirely
16:43:48	FromDiscord	<dom96> furthermore, I have no idea what problems you face with Nimble
16:43:52	FromDiscord	<dom96> You never talk about them properly
16:44:03	Araq	lol
16:44:29	Araq	I wrote multiple RFCs, multiple issues, described again and again the workflow that Nimble needs to support for me
16:44:31	FromDiscord	<dom96> shashlick: do you know what Araq is referring to?
16:44:50	FromDiscord	<dom96> yes, you wrote what workflow you want. But you didn't describe the /problems/
16:45:23	shashlick	I have the memory of a goldfish unfortunately
16:45:28	Araq	once again, if deps are project local than conflicts can *only* arise when you have a version conflict. which right now doesn't even have a good solution either and yet we survive
16:45:50	FromDiscord	<dom96> and by all accounts your problems are being solved
16:45:56	FromDiscord	<dom96> you've got local deps already AFAIK
16:45:56	shashlick	anyway, if nimble does wash it's hands off of the namespace debacle, no warnings, nothing
16:46:15	shashlick	users may still run into this issue - how will they work around it?
16:46:25	*	bouzu_ joined #nim
16:46:38	Araq	I always say the same thing.
16:46:45	shashlick	it will be a Nim issue then so there still needs to be some guidance
16:46:54	shashlick	"frosty-0.1.0" / utils?
16:46:57	alehander92	but dom96 is right: having upstream packages depend on different versions is something which would happen when we actually have popular libs
16:46:58	*	bouzu_ quit (Client Quit)
16:47:04	Araq	1. Install deps locally to the project by 'git clone'. No $version dir enters the picture
16:47:29	disruptek	man, you guys...
16:47:43	*	a_chou quit (Ping timeout: 260 seconds)
16:47:52	Araq	2. No namespacing issues either.
16:48:13	shashlick	Araq: there's still a srcDir which could be in the way
16:48:19	Araq	the end. all the rest is legacy stuff
16:48:23	shashlick	and users will need to do `import frosty/src/utils`
16:48:54	Araq	so what man, if it's 'src' on github, it's reflected in the import command
16:48:58	FromDiscord	<dom96> Araq: that's the solution, what's your problem with the current state of things?
16:49:08	FromDiscord	<whisperdev> so I guess I have to talk to kchen about this
16:49:11	FromDiscord	<whisperdev> :/
16:49:12	voidpi	PMunch: yes I was on the right directory and did try to just point to the directory first
16:49:45	*	a_chou joined #nim
16:49:55	shashlick	dom96: the nim.cfg interop is one
16:50:16	shashlick	which is mostly an agreed upon solution
16:50:34	Araq	dom96: the current state of things doesn't work. I don't want to have 4 versions of jester installed, neither of which I can build the docs for.
16:50:45	Araq	the problems are well documented by now.
16:51:22	FromDiscord	<dom96> Why doesn't it work? Why do you not want those 4 versions? How does that actually impact you?
16:51:36	disruptek	fwiw, if nimph cannot figure out your package's structure just by looking at it, it probably won't work. i'm not likely to launch nimscript just to read a .nimble file.
16:52:12	*	maier joined #nim
16:52:47	shashlick	the proposal retains srcDir for backwards compatibility
16:52:55	shashlick	ultimately you don't want to break user code
16:53:04	disruptek	i'm not likely to launch nimscript just to read a .nimble file.
16:53:10	shashlick	that's the only real thing in the nimble file worth mention
16:53:15	shashlick	there's nimble dump
16:53:18	disruptek	i am going to generate .nimble files for packages.
16:53:22	shashlick	but you can also grep srcDir
16:53:36	shashlick	since it's a simple string
16:53:43	disruptek	if you think i'm going to run `nimble dump` instead of doing my own nimscript eval you're really not picking up what i'm putting down.
16:54:05	shashlick	solve this deadlock and you can do whatever you want
16:54:11	shashlick	even if you don't, you can ;)
16:54:32	disruptek	if your package is so bizarre that i cannot determine the srcDir by inspecting it, then it won't work with nimph.
16:54:43	disruptek	and i would argue it shouldn't work with nimble, either.
16:55:19	disruptek	but, you guys do what you want. as long as the compiler doesn't change on me, i'm fine with whatever.
16:55:35	disruptek	we'll share code in a library, so we can use whatever works best.
16:56:10	disruptek	what's the deadlock, anyway? i hate to impose the question and don't feel bad just telling me to read the forum.
16:57:04	disruptek	Araq: all my packages are moving to submodules named frosty/ or skiplists/ or whatever right in the project directory. it works fine.
16:57:05	*	maier quit (Ping timeout: 240 seconds)
16:57:17	shashlick	Araq wants no more warnings, dom96 wants errors for namespace issues
16:58:22	alehander92	disruptek how can one test the mangling PR as you asked in the forum?
16:58:37	disruptek	i think errors make no sense unless you literally cannot answer an important question like, "what code actually runs?"
16:58:51	disruptek	alehander92: clone the PR and build software with the resulting compiler.
16:59:22	alehander92	but what are good candidates for breaking it
16:59:28	disruptek	how should i know?
16:59:32	alehander92	i mean, what was the weak point until now
16:59:39	*	superbia2 joined #nim
16:59:40	shashlick	sounds like US politics - more vs. less government oversight
16:59:43	disruptek	the only test that fails is jsonutils and i'm not convinced it isn't a nim bug.
16:59:53	disruptek	it's just my opinion.
17:00:10	alehander92	shashlick big standard lib vs small one is often also comparable to the government thing
17:00:26	disruptek	nimph only errors when it cannot make sense of the env, which is almost never.
17:00:42	disruptek	the fact is that the compiler is pretty easy to reason about, as is the environment.
17:00:51	disruptek	it's not hard to have perfect knowledge.
17:01:16	alehander92	you're optimistic today!
17:01:24	disruptek	if i need to move this into the package manager library, i will.
17:01:44	*	superbia1 quit (Ping timeout: 260 seconds)
17:01:48	shashlick	need to worry about the past man
17:01:54	shashlick	and the present
17:02:11	disruptek	admittedly, i don't use a lot of software from other people, but i don't find it to be a problem in practice.
17:02:20	shashlick	anyway, still blocked
17:02:26	disruptek	what's the blocker?
17:02:50	disruptek	the warnings-vs-errors thing?
17:03:18	shashlick	I think so
17:03:26	*	disruptek yawns.
17:03:47	disruptek	can't you do the rest of the stuff?
17:04:03	shashlick	I thought I could but it doesn't seem like
17:04:11	shashlick	maybe just the nim.cfg stuff in isolation
17:04:21	shashlick	but then that'll be more backwards compat stuff in the future
17:05:58	*	mipri left #nim (#nim)
17:05:59	alehander92	hmm
17:06:08	alehander92	disruptek
17:06:26	alehander92	what do you think about 2 versions of same package as deps
17:07:21	*	dddddd_ joined #nim
17:09:14	Araq	disruptek: what's special about jsonutils?
17:09:44	FromDiscord	<dom96> Araq: see my question above
17:09:47	Araq	it doesn't mess with anything like .exportc
17:09:49	*	dddddd quit (Ping timeout: 264 seconds)
17:10:12	*	dddddd__ joined #nim
17:10:26	disruptek	gensym<->generics<->procs
17:10:46	Araq	dom96: it impacts me because 'nim c' is not 'nimble c' so what 'nim c' picks might be wrong
17:10:47	disruptek	alehander92: i'm in favor of designing it out of the language if possible.
17:11:09	shashlick	Araq: but that will be fixed with nim.cfg right
17:11:23	shashlick	both algorithms will be brought in sync
17:11:32	Araq	right. dom96: furthermore the shared directory claims to save space and yet I bet I'm fine with a single jester version
17:11:51	disruptek	shashlick: feel free to create tickets in nimph for stuff you want in the library, or just hit me up somehow. i am starting to put something together.
17:11:51	Araq	but I don't know which dependencies still require jester-0.9
17:12:17	Araq	old cruft accumulates by construction with Nimble's current design.
17:12:25	FromDiscord	<dom96> Araq: and this caused you actual problems? Where `nim` picked the wrong version?
17:12:31	alehander92	disruptek but how can you do that: it's a social problem
17:12:36	Araq	not for jester, but yes
17:12:37	alehander92	(if it's a problem at all)
17:12:45	*	dddddd_ quit (Ping timeout: 240 seconds)
17:12:53	disruptek	dom96: the problem is that if something gets removed, you won't know if /other/ software is somehow picking up a different version.
17:12:57	disruptek	it's the shadowing problem.
17:13:04	disruptek	nimph has code for this, btw.
17:13:11	shashlick	disruptek: part of the challenge for Nimble will be pulling the dep in koch, but we'll see
17:13:22	disruptek	alehander92: what's the social part? i see none.
17:13:35	disruptek	pulling the dep in koch?
17:13:42	FromDiscord	<dom96> Araq: I would argue that this is a problem unique to you, others are not allergic to using `nimble c`
17:13:54	disruptek	dom96: it's not unique to Araq.
17:14:10	disruptek	there's just nothing irrational about his reasoning, also.
17:14:12	shashlick	I don't think this is a problem - nim.cfg is already agreed upon and users can use Nim c or nimble c just fine
17:14:16	shashlick	not worth debating it again
17:14:17	Araq	well it's great that real problems are unique to me whereas anticipated problems are "real" and pressing as soon as we have one billion packages.
17:14:26	disruptek	lol
17:15:24	shashlick	Araq: these dependency headaches are real, people have spent years on it, why do you say they aren't real? want to understand
17:15:44	*	dddddd__ quit (Ping timeout: 260 seconds)
17:15:56	FromDiscord	<dom96> Araq: objectively those problems are only real to those that refuse to use `nimble c`
17:16:19	disruptek	dom96: fair enough.
17:16:49	shashlick	are you saying that these aren't problems right now so not to over engineer? or that Nim has something special where we won't run into it
17:16:55	alehander92	well this is unfair: to have the clash problem, one needs many libs with >=2 stable version and some popular libs that many ppl use in their own libs (e.g. serialization/logging/sugar-y stuff). it's a bit early for that now, but it seems normal that at one point those conditions would change
17:17:39	FromDiscord	<dom96> We cannot design things without anticipating problems
17:17:41	disruptek	alehander92: the social problem is that people are afraid to fork.
17:17:42	alehander92	this might not be a goal for nimble to solve , but this doesn't mean it's some kind of conspiracy theory
17:18:05	disruptek	provide the tools to develop software, better.
17:18:09	alehander92	disruptek yes, people have better usages of their time
17:18:11	disruptek	leap and the net shall appear.
17:18:43	disruptek	if no one can be bothered to update a needed dependency, then it doesn't sound like software i want to depend upon.
17:19:03	alehander92	there might be many reasons
17:19:10	alehander92	especially when nim itself gets to 2.0 etc
17:19:12	shashlick	it's hard to simply fix packages what are out for a long time
17:19:20	shashlick	it will break existing code
17:19:23	alehander92	i don't even see what's the big deal from package manager view
17:19:24	disruptek	this is simply wrong.
17:19:50	disruptek	the big deal is that we don't want an environment supporting multiple versions of the same package.
17:19:52	alehander92	if you have 1 version: everything is the same, only otherwise you add optionally some kind of tag
17:20:02	alehander92	and this doesn't even affect the lang
17:20:08	disruptek	we would rather have singleton instances providing better quality to all consumers.
17:20:13	Araq	to bring this into a productive discussion
17:20:14	alehander92	unless the people want to directly import differences
17:20:16	FromDiscord	<dom96> Thinking about this more, blaming Nimble for your problems when you refuse to use it is incredibly unfair.
17:20:19	alehander92	which rarely happens
17:20:31	disruptek	dom96: create better products.
17:20:37	Araq	I'm happy with shashlick's improvements and they generally move into the right direction
17:21:02	Araq	dom96: for a long time Nimble didn't support argument forwarding so I *had* to use 'nim c' for testing
17:21:02	alehander92	disruptek this is idealistic, but i don't think you can expect it from ecosystems no matter of your tooling
17:21:24	FromDiscord	<dom96> Araq: that's simply not true, `nimble c` always supported argument forwarding
17:21:48	FromDiscord	<dom96> You couldn't use it because you also refuse to switch Nim compilers via the PATH
17:21:48	Araq	dom96: --gc:arc ?
17:22:00	FromDiscord	<dom96> literally every flag was passed to Nim
17:22:13	Araq	plus remember that this's also about needing to use 'nim_temp' (different binary)
17:22:13	disruptek	alehander92: if it's idealistic to expect more from nim, call my an idealist.
17:22:29	FromDiscord	<dom96> yes, hence what I wrote above.
17:22:48	FromDiscord	<dom96> And that problem is definitely unique to you
17:22:48	disruptek	it's not like we aren't in a position to dictate how stuff works.
17:22:53	alehander92	and other stuff e.g. cargo / rust already supports that
17:22:54	FromDiscord	<dom96> the rest either use choosenim or change their PATH
17:22:57	alehander92	without any drama
17:23:02	shashlick	Araq: you have --nim: now
17:23:08	alehander92	it's not like we can't look and learn from other ecosystems
17:23:09	Araq	yeah I know
17:23:13	alehander92	we don't have to guess
17:23:37	disruptek	indeed, but don't conflate inspiration with plagiarism.
17:23:42	shashlick	I think the focus of this proposal was more about addressing all the reasons why people were not wanting to use nimble
17:23:46	Araq	alehander92: we cannot learn from them if we want the simplest thing that works, but fair enough, nobody really wants that
17:24:02	disruptek	i've used a lot of package management systems in different ecosystems. they've inspired me to produce something different.
17:24:11	Araq	but anyhow I know I am now getting what I need, I'm happy
17:24:27	Araq	but if you discuss once again how package structure should be enforced
17:24:43	Araq	and how to improve things for everybody, I give my opinion
17:24:48	alehander92	disruptek surely, just was trying to say that 1) it doesn't seem as some kind of painful problem to have it 2) bigger ecosystems probably have those clashes
17:24:53	Araq	and that is that most of this is artificial complexity
17:25:05	disruptek	alehander92: they have those clashes because they permit them.
17:25:37	disruptek	it's less painful to design them out of the system in the first place.
17:25:46	Araq	I'm telling you the way out of the complexity, arbitrary rules and resulting bugs.
17:26:00	alehander92	disruptek by this logic if you dont permit this .. other user would just come and write the next package manager `multi`
17:26:16	disruptek	if it works, great.
17:26:20	disruptek	i'm not against innovation.
17:26:24	alehander92	and the ecosystem will be able to get them again
17:26:30	disruptek	you think i want to spend my time writing package managers?
17:26:32	alehander92	but this would affect your manager
17:26:35	disruptek	i tried to get shashlick to take over nimph.
17:26:36	Araq	also, the more you *enforce*, the more packages are simply not listed for 'nimble search' but remain github repos
17:26:50	disruptek	exactly.
17:26:53	alehander92	disruptek well people have stranger hobbies
17:26:55	Araq	you tend to overlook this entirely.
17:26:56	disruptek	i don't put any of my packages in nimble.
17:27:07	disruptek	it's too big a pita and i hate the publishing method.
17:27:15	disruptek	i submitted a pr to fix it. it was rejected.
17:27:20	FromDiscord	<Rika> @PizzaFox dont hesitate to ask
17:27:21	FromDiscord	<Rika> anything
17:27:26	FromDiscord	<PizzaFox> huh
17:27:30	FromDiscord	<Rika> even with this conversation going on
17:27:35	alehander92	but my experience in other langs is that sometimes this enforcement works
17:27:42	FromDiscord	<PizzaFox> i am simply watching nim contributors arguing lol i think i hit a key by accident
17:27:46	FromDiscord	<Rika> i see
17:27:48	alehander92	maybe if a critical mass already uses X it's different
17:27:48	disruptek	alehander92: i wrote nimph because i wanted a pm that worked better for me.
17:27:58	disruptek	if you can replace it, more power to you.
17:28:00	disruptek	i will contribute.
17:28:02	alehander92	i am a bit afraid that this is a python-like situation
17:28:30	alehander92	like, having python with `n` managers/solutions competing is usually considered one of its weakest points
17:29:06	alehander92	so in ruby even if `gem` is probably nothing extraordinary, the simple fact it's just universal and it works is a +
17:29:14	Araq	alehander92: which is why a single complex Nimble is better for us than multiple PMs. and more important than the "simplest thing that can work"
17:29:19	FromDiscord	<dom96> Really, the package manager should have been designed with the language
17:29:55	Araq	dom96: we did, see --nimblePath. we failed.
17:30:03	FromDiscord	<dom96> no
17:30:25	alehander92	Araq probably yeah
17:30:39	disruptek	bbl
17:31:15	Araq	dom96: so why does the Nim compiler have all these Nimble specific flags then?
17:31:18	FromDiscord	<dom96> Anyway, I'm tired now
17:31:26	FromDiscord	<dom96> It feels like no matter what arguments I make they won't be listened to
17:31:50	FromDiscord	<dom96> I've spent years arguing about how I wanted Nimble to work and we reached the compromise we reached
17:31:54	alehander92	disruptek it's great that you wrote it, i even like some of the ideas a lot
17:32:00	FromDiscord	<dom96> and now it feels like Nimble gets all the blame
17:33:02	Araq	yeah, it's something personal which is why you don't listen. ;-)
17:35:13	shashlick	I disagree on that
17:35:17	shashlick	there's valid points on both sides
17:35:37	shashlick	but we need to proceed here in some direction
17:36:08	shashlick	cause there's no shortage of effort being wasted on mini package managers
17:36:25	FromDiscord	<UNIcodeX> @dom96 while you're here, any insight on resolving this nimble error?↵`Error: Cannot satisfy the dependency on cligen 1.2.0 and cligen 0.9.45` ?
17:36:36	FromDiscord	<dom96> Wow
17:36:54	FromDiscord	<UNIcodeX> (edit) removed '?'
17:36:58	FromDiscord	<dom96> So now there is two people that ran into this problem.
17:37:25	Araq	dom96: only because you don't phrase the problem properly. ;-)
17:38:17	Araq	this Nimble error is a symptom of the wrong design.
17:38:22	FromDiscord	<dom96> Come on
17:38:26	FromDiscord	<dom96> This is just getting ridiculous
17:38:41	Araq	*Why* does this conflict exist?
17:38:56	FromDiscord	<dom96> Earlier you were saying that there was no sign of this being a "real" problem
17:39:02	FromDiscord	<dom96> you have it now staring in your face
17:39:12	*	Araq sighs
17:39:18	FromDiscord	<dom96> @UNIcodeX sorry that you're getting in the middle of this, but we were literally arguing about this earlier
17:39:30	FromDiscord	<dom96> Nim doesn't support depending on two different versions of the same package
17:39:51	FromDiscord	<dom96> so you'll need to find the package you depend on, which depends on the older cligen and update it to work on the new one
17:40:09	Araq	and now we're getting to the real problem ;-)
17:40:12	alehander92	i have to say I also wanted to give something like cligen as an example (but i thought libs might use more often stuff like serialization libs)
17:40:26	FromDiscord	<Kiloneie> Does Nim's forum support vote pools ?
17:40:28	FromDiscord	<UNIcodeX> I thought as much after perusing some of the previous ↵> @UNIcodeX sorry that you're getting in the middle of this, but we were literally arguing about this earlier↵@dom96 messages and then running into this.
17:40:34	*	giaco joined #nim
17:40:57	FromDiscord	<UNIcodeX> (edit) 'I thought as much after perusing some of the previous ↵>' => '>' | 'earlier↵@dom96 messages and then running into this.' => 'earlier'
17:41:05	FromDiscord	<UNIcodeX> (edit) 'earlier' => 'earlier↵I thought as much after perusing some of the previous messages and then running into this.'
17:41:35	FromDiscord	<dom96> @Kiloneie no but you can link to a straw poll or something
17:42:07	giaco	I'm looking for a new language to build closed-source static client applications for desktop, but also capable of future full-stack webapp development. I'm looking at nim and kotlin right now, they both seems capable of doing that. Why should I prefer nim over kotlin?
17:42:09	FromDiscord	<UNIcodeX> So this is what sparked the debate about different PMs, and the pros / cons of nimble vs nimph?
17:42:17	alehander92	Araq but this is a human problem: different maintainers move on different speeds
17:42:22	Araq	here is why it's not a real problem: Nimble has no fucking idea if only the versions are mismanaged or if there are real source code incompatiblities. The Nim compiler could tell but isn't asked. Solution: "Just make the Nim complier eat dogfood"
17:42:53	Araq	"just make it support multiple versions at the same time so that it'll never get cleaned up"
17:43:24	Araq	and why? so that we can blame the Nim compiler and not our perfectly designed Nimble.
17:43:35	FromDiscord	<dom96> Araq: there is no way to tell the Nim compiler: this path should depend on this path, and this path should depend on this other path
17:44:08	Araq	yeah yeah, there is no shortage of complex solutions
17:44:18	Araq	how about we find simple ones.
17:44:34	FromDiscord	<UNIcodeX> > Araq but this is a human problem: different maintainers move on different speeds↵@alehander92[IRC]#0000 surely though there is a graceful way to handle it. I don't know of the best solution either. Supporting multiple versions causes clutter, but would at least work, and disk space is cheap. However, clutter is unseemly and has it's own draw backs
17:44:38	FromDiscord	<dom96> Nimble isn't perfectly designed, far from it
17:45:18	FromDiscord	<dom96> But you simply cannot blame Nimble here for what is a limitation in the Nim compiler
17:46:08	FromDiscord	<UNIcodeX> I missed the message alleging why the Nim compiler is the issue. Maybe I should just bow out and keep reading.
17:46:10	Araq	I blame it for a useless, annoying error.
17:46:43	Araq	how about Nimble says "Conflict here, I'll install 1.2 and you get to update your dependencies"
17:47:04	Araq	chances are that it still compiles anyway
17:47:19	Araq	because people don't enjoy versioning at all and it's not just me who doesn't.
17:47:27	FromDiscord	<haxscramper> > So now there is two people that ran into this problem.↵@dom96 Count me too
17:47:44	*	solitudesf- joined #nim
17:47:50	*	solitudesf quit (Read error: Connection reset by peer)
17:47:56	FromDiscord	<UNIcodeX> me three. This sounds like a winner to me. At least I wouldn't have to manually edit packages after they're installed just so I can get to the project at hand.
17:48:06	Guest71338	The more popular the library, the more projects depend on it, the more often it wil cause clashes
17:49:45	alehander92	Araq but what if you can't update those dependencies
17:49:51	Araq	Ok, I'm wrong, it's fine. I take it back. The problem is super real and pressing. The cause of the problem is usually misrepresented. ("If only Nim could deal with multiple versions...")
17:50:33	Araq	alehander92: it's source code you download. There is no way in hell you cannot work around the problem.
17:50:35	alehander92	now you have to go and fork package X, upgrade Y's usage in it, PR and wait OR maintain a separate fork in your own tree
17:50:45	alehander92	yeah trust me i maintained many forks of libs
17:50:48	alehander92	it's horrible
17:50:57	alehander92	if you don't upstream them quickly
17:51:02	shashlick	but is it possible to solve that with a PM?
17:51:08	shashlick	or is this manual crap inevitable
17:51:13	FromDiscord	<dom96> Fair enough. Perhaps Nimble shouldn't hard fail on that, that's in the realm of solving this problem. I'm glad you acknowledge now that it is a real problem!
17:51:39	alehander92	but yes it's doable, and it's a valid thing for Nimble to ask for
17:52:04	alehander92	bbl
17:52:12	Guest71338	nick Zevv
17:52:28	FromDiscord	<dom96> Indeed, there are multiple ways to solving this and we should discuss it. That is all I wanted.
17:52:49	shashlick	fun part is that this isn't the name spacing issue
17:52:56	*	Guest71338 is now known as Zevv
17:53:00	FromDiscord	<dom96> yes, this is a completely different problem
17:54:11	Araq	well yes. sometimes these are confused though by saying "make the version part of the library name"
17:54:17	Araq	oh shit, bbl
17:54:24	Araq	my children should sleep...
17:54:35	FromDiscord	<dom96> yeah, I should go too
17:54:41	FromDiscord	<dom96> let's park this discussion for later
17:54:57	FromDiscord	<Rika> good to know that this didnt end heated
17:54:59	FromDiscord	<dom96> (or you know, others can discuss it while we're gone heh)
17:55:27	FromDiscord	<dom96> (edit) 'you know,' => 'actually,'
17:55:38	shashlick	so this multiple version issue can be deferred for later
17:55:56	shashlick	at least from my point of view, I'd like to make some progress on the proposal so would want to prioritize the namespace issue
17:56:32	shashlick	if we concede the headache to Nim then we can deal with this separately in the compiler or in v2 or something
17:58:33	FromDiscord	<dom96> shashlick: +1
17:59:05	*	a_chou quit (Ping timeout: 240 seconds)
18:01:40	alehander92	guys i get Error: The AssertionDefect type requires the following fields to be initialized: parent,
18:01:44	alehander92	up
18:01:54	alehander92	has this happened on bootstrapping with you
18:02:07	alehander92	(bootstrapping a patch, not the upstream code)
18:02:54	*	filcuc quit (Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/)
18:03:37	FromGitter	<tim-st> why was the commit info in `nim version` removed?
18:05:04	shashlick	how did you get nim
18:05:30	FromGitter	<tim-st> https://github.com/nim-lang/nightlies/releases
18:06:12	FromGitter	<tim-st> my last nightly from july still had it
18:06:18	FromGitter	<tim-st> same source
18:06:32	shashlick	might need to check with @leorize if something has changed in nightlies
18:07:46	leorize[m]	"shashlick" (https://matrix.to/#/@freenode_shashlick:matrix.org): it's only available for devel atm
18:08:36	FromGitter	<tim-st> you mean "branch=devel"?
18:09:22	FromGitter	<tim-st> my version from the url above says branch devel
18:11:25	FromGitter	<tim-st> maybe it's because the user is "github-actions"
18:15:41	FromDiscord	<Recruit_main707> if i have a template like this, is that if statement processed at compile time? https://play.nim-lang.org/#ix=2w8A
18:16:16	Zevv	shashlick: so, which languages got this *right* then
18:16:27	*	dddddd__ joined #nim
18:16:29	Zevv	allowing multiple dependency versions
18:16:41	*	dddddd__ is now known as dddddd
18:17:26	*	maier joined #nim
18:17:44	shashlick	No idea honestly - and that's really the second issue which I'd rather discuss after we figure out the namespace one
18:18:09	shashlick	I think rust was adding support for multi versions
18:19:30	disruptek	copying bad design is not good design.
18:19:47	Zevv	what "bad design" are you refering to then?
18:20:53	shashlick	More more is less - https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html
18:21:06	Zevv	no, but I asked about dependency management
18:21:10	alehander92	rust has it yeah
18:21:15	Zevv	but is it bad
18:21:16	Zevv	?
18:22:27	alehander92	https://stephencoakley.com/2019/04/24/how-rust-solved-dependency-hell
18:22:49	*	maier quit (Ping timeout: 260 seconds)
18:22:51	alehander92	but as far as i see you can have most 1 direct dep version but many indirect dep versions of X
18:23:12	*	maier joined #nim
18:26:41	alehander92	which actually makes sense (so you dont have this import a-1/x problem)
18:27:03	Zevv	that seems reasonable
18:27:37	Zevv	it might prove problematic if a library offers a way to talk to one of its dependencies somehow, but that's probably a corner case
18:28:46	alehander92	like passing objects from the dep' type around? (as one of the blog article examples)
18:29:10	alehander92	yeah, well one can always just try to upgrade the dependency in those cases
18:29:16	alehander92	but you have options
18:31:55	disruptek	what's bad is that it's complexity to solve a problem that shouldn't exist.
18:32:27	disruptek	indeed, if we say we don't support it, we ensure that the problem won't exist because humans will have to fix their stuff.
18:32:38	alehander92	but it seems most ecosystems have it: i do remember now ruby gems having it, it seems java has it
18:32:43	*	maier quit (Ping timeout: 260 seconds)
18:32:46	disruptek	it could be that this is the solution we want, not a technical solution that enables poor software.
18:33:04	alehander92	well, that's what those ecosystems already do dude
18:33:19	disruptek	copying bad design is not good design.
18:33:23	alehander92	it's a bit like go "we simply wouldn't solve this and offload it to the people"
18:33:42	alehander92	valid, but not very original
18:33:51	disruptek	sorry.
18:34:05	disruptek	sometimes originality isn't as important as results.
18:34:06	alehander92	permitting dependency hell might also be bad design
18:34:22	disruptek	prove it.
18:34:23	alehander92	and it's far more mainstream
18:34:42	alehander92	so it's strange to me that just doing nothing as most older ecocystems already do
18:34:58	disruptek	your solution is always available to us, but we don't need it yet.
18:35:02	alehander92	is lauded as original solution
18:35:04	disruptek	so, let's not add the complexity.
18:35:20	alehander92	but where is the complexity
18:35:22	disruptek	no one is lauding anything as original here.
18:35:29	alehander92	e.g. i write my own nimph
18:36:12	alehander92	the only difference would be that only when i find two indirect a-1 and a-2 i might add `-v` to the submodule path
18:36:13	Zevv	disruptek: "because humans will have to fix their stuff". I see your point, but it's a PITA for the end user
18:36:24	disruptek	mangling adds complexity outside of simple path-fu.
18:36:25	alehander92	he wants to change our civilization
18:36:31	alehander92	to keep the problem simpler
18:36:44	disruptek	mangling packages extends all the way to the backend. it's a problem.
18:36:57	disruptek	error messages are a problem.
18:36:57	Zevv	what is the "backend"?
18:37:02	disruptek	sigmatch is a problem.
18:37:07	disruptek	caching is a problem.
18:37:18	alehander92	disruptek is right, sorry, i didnt say this part
18:37:24	disruptek	this stuff is impactful way beyond your suggestion.
18:37:34	alehander92	i agree it's less trivial
18:37:39	disruptek	the backend is c.
18:37:39	alehander92	but i also don't think its super hard
18:37:49	disruptek	no, i did it early on in my nimph experiments.
18:37:50	alehander92	so it's ok to leave it out because its more complex
18:37:50	Zevv	it is probably super hard. But it might still be worth persuing
18:37:54	alehander92	but i can see it in nim2.0
18:38:15	disruptek	there's no reason for it today. we can always add it later.
18:38:28	alehander92	and i think compile time evaluation is probably harder for caching etc
18:38:34	alehander92	yeah i agree
18:38:50	alehander92	the discussion was just that this is a valid problem
18:38:57	alehander92	not to solve it now i think
18:39:31	*	maier joined #nim
18:40:58	alehander92	ok man need to fix my compiler branch now
18:41:10	alehander92	i get an assert failure and can't find out why
18:41:15	*	Trustable joined #nim
18:42:35	FromDiscord	<Recruit_main707> sent a code paste, see https://play.nim-lang.org/#ix=2w8H
18:44:23	disruptek	it's a valid problem but i'm not convinced it's a problem we should be solving with any of the solutions suggested thus far.
18:44:45	disruptek	if we solve it at all, i mean.
18:44:59	*	maier quit (Ping timeout: 260 seconds)
18:45:07	shashlick	This is starting to sound like zig or go
18:45:18	shashlick	Leave features out cause, ya
18:45:23	shashlick	Complexity
18:45:36	shashlick	Not my problem
18:45:40	disruptek	if you can't know the right thing to do, why do anything?
18:45:47	Zevv	that's a real world solution you have to take - not enough hands is a very good reason
18:46:03	alehander92	i think "solve it later" is ok
18:46:08	disruptek	maybe it makes more sense to put time into stuff that needs to be fixed sooner, like concepts or incremental compilation.
18:46:12	alehander92	no need to complicate IC and other stuff for now
18:46:15	Zevv	sure, if you could open a can of engineers for every problem. "solve it later" is nothing to be ashamed of
18:46:18	Zevv	it's not like having broken windows
18:46:28	alehander92	but after they work well, it would be a good fit for next goals imho
18:46:39	disruptek	exactly. underspecified design is preferable to poor design.
18:46:55	alehander92	i think the problem would be with "we wouldn't have this ever"
18:47:01	alehander92	because it sounds more un-nimlike
18:47:06	alehander92	(even if it's also valid)
18:47:10	shashlick	Ya but solving it later != problem doesn't exist
18:47:13	disruptek	well, we should choose a path that everyone can get behind.
18:47:16	FromDiscord	<haxscramper> @Recruit_main707 Can't this just be a function? If `x` and `y` are compile-time parameters anyway you might do `static[int]` and raise assert in `static:` block
18:47:24	disruptek	not something that roughly half of the users can find fault with.
18:47:35	FromDiscord	<haxscramper> sent a code paste, see https://play.nim-lang.org/#ix=2w8K
18:47:38	FromDiscord	<Recruit_main707> shit, assety in a static block
18:47:45	disruptek	not something designed to solve problems we don't have which could create many problems for us in the future.
18:47:52	FromDiscord	<Recruit_main707> thats what i have been looking for since forever, thanks
18:48:30	alehander92	hm, how much is left
18:48:34	alehander92	from the new concepts
18:49:05	shashlick	My proposal is middle enough
18:49:22	shashlick	Doesn't over solve anything
18:49:31	disruptek	i think that's true.
18:49:39	shashlick	Cause the rest is undefined
18:51:23	*	narimiran joined #nim
18:52:17	shashlick	At least let's get on this square and then move forward
18:52:24	Araq	„Rust's solution involves a fair number of moving parts, but it essentially boils down to challenging a core assumption that we have made up until this point:
18:52:24	Araq	Only one version of any given package should exist in the final application.“
18:52:24	Araq	Well I question the whole „version“ idea instead. In fact, the „semantic versioning“ idea is a lie. 3 numbers do not have semantics, they are completely made up and have no connection to the Nim source code.
18:52:27	shashlick	Even this change breaks a bunch of stuff
18:52:56	disruptek	even what change?
18:53:33	shashlick	This proposal
18:53:53	disruptek	i dunno, it's largely what nimph is doing and it doesn't seem broken to me.
18:54:08	shashlick	Breaks compat is what I mean
18:54:16	disruptek	do you have numbers on that?
18:54:50	shashlick	I've documented it in the compat section
18:54:57	disruptek	Araq: we could compute semver automatically if it'd help.
18:55:08	disruptek	shashlick: that's new, right?
18:55:18	*	PMunch quit (Quit: leaving)
18:55:41	shashlick	The section?
18:55:54	Araq	disruptek: well you can always add more stuff on top of broken ideas and then they start to work, see the theory of epicycles
18:55:54	shashlick	Ya after Araq's feedback
18:56:22	disruptek	Araq: a fair point. just trying to be helpful. i think semver is dumb, too.
18:56:42	Araq	Nim's pretty unique with its 'when defined/declared/compiles' constructs btw
18:56:43	disruptek	nimph could issue a warning if you bump a project after adding a breaking change.
18:57:17	Araq	it's pretty flexible and compatbility issues can directly addressed in the source code
18:57:43	Araq	I say this because shashlick asked about it a couple of hours ago iirc
18:57:45	shashlick	what broken things are you referring to in this context
18:57:55	disruptek	yep. we do need a general feature set lib and maybe even a way for the importer to specify the compatability version of a library they want to use.
18:57:56	*	natrys joined #nim
18:58:43	disruptek	i think these are largely problems that software developers should be able to fix for each other, though.
18:59:02	disruptek	as the creator of a lib, i should know what changes are appropriate.
18:59:53	disruptek	"nimble does not read nim.cfg" ... wut
18:59:54	shashlick	so ya, you could do when xyz: import frosty/src/utils
19:00:26	*	krux02 quit (Read error: Connection reset by peer)
19:00:33	shashlick	but if you have `import util` in a dependency, you will have to vendor it and edit it
19:00:42	shashlick	anyway, have gone round that merrygo
19:00:58	*	krux02 joined #nim
19:01:08	Araq	there is no real alternative for bad code, somebody has to fix it
19:01:22	disruptek	yeah, i am done worrying about nimble's idea of package structure.
19:01:40	disruptek	i use what works well with the compiler, which is remarkably simple. you should try it some time.
19:02:56	shashlick	stop taunting :(
19:03:25	shashlick	Araq: it's not bad code - user didn't know any better, now with more info they can improve
19:03:41	shashlick	in isolation, life was good, but once you interact with others (packages), politics emerge
19:04:08	alehander92	well, libs expose some kind of type/function api
19:04:20	alehander92	even if you don't have any explicit version numbers
19:04:29	alehander92	those can be incompatible, same thing
19:04:42	shashlick	at this rate, we'll get c++ support in nimterop first
19:05:00	disruptek	shashlick: honestly, all you need to do is issue warnings. it works.
19:05:04	FromGitter	<genotrance> fat chance
19:06:06	*	superbia2 is now known as superbia
19:06:13	alehander92	but i mean ..
19:06:26	alehander92	one can just write his own import system mechanism with macros
19:06:35	alehander92	and sidestep even part of that
19:06:38	Araq	shashlick: I am optimistic, relax, we're getting there.
19:06:54	disruptek	alehander92: the point is that we can tell what's going to be compat. nimph can calculate those semver changes.
19:06:56	alehander92	i think people did such stuff with overriding python's imports
19:07:13	alehander92	disruptek awesome
19:07:51	disruptek	nimph could even display public api changes between versions or compute when such changes can affect your code.
19:08:01	disruptek	it's not like we don't have perfect knowledge here.
19:08:20	shashlick	ok will fix some non-controversial bugs in the interim
19:08:22	disruptek	we won't know if semantics change, but certainly we can confirm interfaces.
19:08:31	alehander92	that would be cool
19:09:39	disruptek	people will use whatever is easiest, so let us not give them garbage like jsonutils.
19:10:10	Araq	I still don't see how jsonutils is so special for name mangling
19:10:32	Araq	looks pretty tame to me
19:10:55	Araq	working concepts would have made the code much better but that is irrelevant for name mangling
19:11:27	disruptek	i think it's poorly written, but that isn't relevant to mangling, either.
19:11:44	disruptek	i even think it was a bad merge, but again...
19:12:51	disruptek	Araq: btw, have you ever seen this?
19:12:54	disruptek	!repo jason
19:12:56	disbot	https://github.com/disruptek/jason -- 9jason: 11JSON done right 15 5⭐ 0🍴
19:14:07	Araq	seems to have the right ideas :-)
19:17:23	disruptek	it even compiles under c++ and mangling.
19:19:00	Araq	and under arc?
19:19:16	disruptek	of course.
19:19:27	disruptek	but it was just a hack to test concepts.
19:20:26	disruptek	basically, it's frosty with concepts.
19:21:41	disruptek	i guess i hadn't learned about newTree at the time.
19:27:42	Araq	concepts are delayed btw, help is appreciated
19:27:57	Araq	don't have time to work on it, it's not scheduled
19:32:00	*	FromDiscord quit (Remote host closed the connection)
19:32:15	*	FromDiscord joined #nim
19:33:18	disruptek	what is it that has to happen?
19:33:50	disruptek	i thought you were going to write the spec after finishing the impl.
19:34:35	Zevv	wait what jason
19:34:47	Zevv	dude. One repo a day keep the doctor away?!
19:34:47	disruptek	i think i'm ready to fork mangling for ic. iirc, it doesn't work with early nim for concept reasons. but i need to move forward.
19:35:00	disruptek	Zevv: it was a 1-day hack from months ago.
19:35:23	Zevv	ooh no hoorays for you then
19:35:38	disruptek	i probably do need to advertise stuff more, though. i don't even star my own repos, i realized recently.
19:36:10	Zevv	you're just polluting the module ecosystem with all your half baked libraries
19:36:17	*	hsh quit (Quit: Connection closed for inactivity)
19:36:23	disruptek	yeah, that's me.
19:36:50	Zevv	I'll star you
19:37:44	*	xet7 joined #nim
19:39:38	disruptek	w00h00
19:41:02	Araq	disruptek: the Dictionary[K, V] concept must work :-)
19:42:18	Araq	some jungling with tyGenericInst and tyGenericInvokation so that K and V type vars are properly bound
19:42:50	disruptek	your impl is in just one file now, right?
19:42:58	Araq	right, concepts.nim
19:43:04	disruptek	excellent.
19:45:44	disruptek	#15252
19:45:45	disbot	https://github.com/nim-lang/Nim/pull/15252 -- 3Turn proc params into syms
19:53:27	disruptek	you're killing me with these comments.
19:56:48	*	audiofile joined #nim
20:02:34	*	lritter quit (Ping timeout: 260 seconds)
20:07:41	FromDiscord	<haxscramper> I'm just testing out docker for nim development, and when I run `nimble install https://github.com/disruptek/nimph` I get `Cannot satisfy the dependency on cligen 1.2.0 and cligen 0.9.45`. No packages installed, nothing at all except `choosenim`.
20:08:55	*	lritter joined #nim
20:19:33	disruptek	yeah, nimph may work fine with cligen 0.9.45 but there was a cosmetic output bug that i was avoiding.
20:19:41	disruptek	sadly, nimterop requires a later cligen for some reason.
20:19:56	disruptek	why are you using docker?
20:20:19	disruptek	i mean, nimph may work fine with a /later/ cligen.
20:21:02	shashlick	do you want me to push cligen back
20:21:14	disruptek	not if you need 1.2
20:21:29	shashlick	i have no specific requirement
20:21:34	disruptek	wut
20:21:48	shashlick	i just update my deps like you taught me
20:22:09	disruptek	i'm confused.
20:22:22	FromDiscord	<Elegant Beef> You changed the requirement for no reason?
20:24:15	shashlick	why would i just link to a 3 year old version of cligen
20:25:25	*	narimiran quit (Ping timeout: 264 seconds)
20:25:56	shashlick	cligen is at 1.2.0, nimterop asks for 1.0.0
20:26:41	disruptek	do you need 1.0.0?
20:27:04	shashlick	no, i can downgrade in the name of peace
20:27:18	shashlick	what version do you want
20:27:38	disruptek	0.9.45 works for me, but you can specify whatever you need.
20:27:48	disruptek	i noticed that 1.0 produces some display artifacts.
20:27:56	disruptek	i need to look into it but it hasn't been a priority.
20:28:40	disruptek	i need 0.9.41+
20:28:52	shashlick	ugh i just pushed 0.9.45
20:29:01	disruptek	yeah, that works, as i said.
20:29:02	disruptek	thanks.
20:29:15	shashlick	https://github.com/nimterop/nimterop/tree/cligendep
20:29:19	shashlick	once tests pass, i'll merge
20:30:50	*	rockcavera is now known as Guest23864
20:30:50	*	tiorock joined #nim
20:30:50	*	Guest23864 quit (Killed (cherryh.freenode.net (Nickname regained by services)))
20:30:50	*	tiorock is now known as rockcavera
20:33:40	FromDiscord	<haxscramper> > why are you using docker?↵I'm just starting to use docker, testing new idea for organizing all development garbage on my desktop
20:36:30	disruptek	if you're using nimph, you can pull a bunch of packages in a directory and then just --nimblePath="/that/directory/" wherever you want that stuff.
20:36:32	FromDiscord	<haxscramper> And I also want to run installation tests in docker locally before pushing new version
20:37:09	FromDiscord	<haxscramper> Because I only now realized that I published `hcparse` but added `nimtrats` as dependency which is not published
20:40:10	*	Trustable quit (Remote host closed the connection)
20:41:19	disruptek	neat.
20:42:31	shashlick	who wants to pick a nimble issue that needs fixing
20:42:34	*	a_chou joined #nim
20:54:39	disruptek	araq was talking about working on nimble.
20:55:52	shashlick	when was this
20:58:38	disruptek	0.9.45 is the last one that doesn't print a spurious "Usage:" with every subcommand. maybe i can work around this.
21:00:57	disruptek	i think i need noHdr = true.
21:01:14	disruptek	yep.
21:03:29	disruptek	okay, i can bump this and support 1+ cligen (but not 0.9.45).
21:06:32	*	a_chou quit (Ping timeout: 256 seconds)
21:06:46	disruptek	clyybber: early submodule support in there.
21:09:14	shashlick	So would I merge my pr or leave as is
21:09:28	disruptek	you can leave it, thanks. or merge it. up to you.
21:09:41	disruptek	merging it will merely support nimph-1.0.0.
21:10:06	disruptek	1.0.1 is already released.
21:11:06	FromDiscord	<Sebastián> been looking into nim and seems amazing, thinking of jumping in but curious, what language did you guys use most before switching to nim?
21:11:22	FromDiscord	<haxscramper> lisp/C++
21:11:30	FromDiscord	<dom96> Python
21:11:41	disruptek	English
21:11:42	FromDiscord	<Rika> python
21:11:49	FromDiscord	<Rika> LOL
21:11:54	FromDiscord	<Sebastián> nice, what ya do with python before. Data Science stuff?
21:12:06	FromDiscord	<Rika> random dumb shit, for my case
21:12:24	FromDiscord	<Sebastián> a I see, thanks dudes. Nim seems pretty rad, hope more devs start adopting it
21:12:26	disruptek	it's not about the length of your snake; it's all about the motion of the ocean.
21:13:18	disruptek	shashlick: here's a notice from nimph:
21:13:20	disruptek	no path to /home/adavidoff/git/nimph/npeg as `npeg`
21:14:12	disruptek	it's telling me this because the project `npeg` is within my project directory, but i don't have anything in there that i can import, because npeg lives in a src subdirectory.
21:14:31	disruptek	the question to you is, what should nimph say in this scenario?
21:14:41	disruptek	`nothing` is a valid answer, of course.
21:16:04	disruptek	keep in mind that there is no requirement, that i'm aware of, that the package name match the import name.
21:16:04	*	a_chou joined #nim
21:20:09	FromDiscord	<Elegant Beef> I used C# before nim
21:23:56	disruptek	for what?
21:25:05	*	solitudesf- quit (Ping timeout: 240 seconds)
21:25:20	FromDiscord	<dom96> > keep in mind that there is no requirement, that i'm aware of, that the package name match the import name.
21:25:21	FromDiscord	<dom96> there is
21:25:49	disruptek	if that's true, that's awesome and hugely helpful.
21:26:24	FromDiscord	<dom96> I'm either misunderstanding you or you've missed a pretty fundamental aspect of the whole package structure debate
21:26:56	disruptek	more likely the later, as i see lots of names with hyphens in them in nimble's packages.json.
21:27:13	*	audiofile quit (Quit: Default Quit Message)
21:27:52	disruptek	are nimble names not the same as package names?
21:28:12	disruptek	i mean, how many different names are there for one library, for example?
21:28:36	FromDiscord	<dom96> if there are packages with hyphens then they shouldn't have been merged
21:28:40	disruptek	nim-glfw, let's say.
21:28:41	FromDiscord	<dom96> and I will bollock whoever merged them
21:28:53	FromDiscord	<dom96> there are legacy packages that have been there since forever
21:28:55	FromDiscord	<dom96> that might be one of them
21:29:02	FromDiscord	<dom96> but yes, you cannot have hyphens in package names
21:29:12	disruptek	as we discussed earlier.
21:29:14	FromDiscord	<dom96> precisely because they are supposed to match the module that you import
21:30:11	FromDiscord	<exelotl> Languages in the order I first used them:↵C++, AS3, JS, Lua, ooc, C↵Also did some Pascal at school (must've been the only school in the country still using it lol), then went to uni where we did Java and a bit of OCaml and Haskell
21:30:51	FromDiscord	<dom96> I like that we've got ex-ooc users, I remember arguing with people that swore by that language 😛
21:31:48	FromDiscord	<exelotl> haha I discovered nim shortly after ooc and bounced off it because all the keywords and syntax were so alien to me
21:32:12	shashlick	just added this - https://forum.nim-lang.org/t/6738#42130
21:32:20	shashlick	hope it summarizes our discussion reasonably
21:32:55	voidpi	Sebastián: I know some python and been learning nim lately
21:33:34	voidpi	I really like it
21:33:41	FromDiscord	<JSGRANT> Mostly Elisp then later Common-Lisp; With tiny bits of Scala in-between. But really there was like a 3 years gap where I didn't do any programming.
21:33:51	FromDiscord	<dom96> shashlick: regarding https://forum.nim-lang.org/t/6738#42130. Again, how is your proposal proposing "softer" warnings?
21:33:59	FromDiscord	<dom96> they seem the same to me
21:34:42	FromDiscord	<JSGRANT> Tried to "relive the magic" recently with Lisp & I just didn't have the motivation anymore after that long-break; Nim really excited me though and I was never a big-fan of Python so that kinda surprised me
21:35:12	shashlick	dom96 - shorter, mentioning namespace, recommendation will be a link
21:36:01	FromDiscord	<dom96> shashlick: I would rephrase to "reworded", "softer" implies that the current warnings scream at the user or something I dunno 🙂
21:37:56	FromDiscord	<exelotl> The context in which I picked up Nim was: my favourite niche speedy modern programming language (ooc) was abandoned, I was looking for an alternative which I could use to make a fast and lightweight 2D game engine. I tried golang and quickly gave up because it's so limited and its FFI story is awful
21:38:10	FromDiscord	<JSGRANT> Also getting more-and-more interested in gamedev; Nim is "near perfect" for my expectations & don't have to dip in the kludges / verbosity of C++ all too much
21:39:17	disruptek	somalier has two #head dependencies specified.
21:39:27	FromDiscord	<JSGRANT> Not a huge-fan of transpiling to C/C++ over just having an LLVM IR ... but it seems to really help the FFI 'story' a bit
21:39:35	*	Vladar quit (Quit: Leaving)
21:39:43	FromDiscord	<dom96> @JSGRANT why?
21:39:45	FromDiscord	<Elegant Beef> I mean looking at rust, it gives us faster compile time
21:39:59	FromDiscord	<JSGRANT> @dom96 Why arm I nodt a fan of transpiling?
21:40:01	disruptek	that's not why it's faster.
21:40:25	FromDiscord	<Elegant Beef> Cmon disruptek, let me make my illinformed joke
21:40:57	FromDiscord	<JSGRANT> It's more of conceptually pure thing for me; Not a technical choice -- technically it's probably worse (at least informed by the very-little I know about FFI)
21:41:35	FromDiscord	<dom96> @JSGRANT yes
21:41:58	FromDiscord	<dom96> Here is my perspective: even gcc "transpiles" C code to asm
21:42:18	FromDiscord	<dom96> So the distinction is really not important to make or care about
21:42:28	FromDiscord	<Rika> whos resetting the days without transpilation argument counter
21:42:29	FromDiscord	<Elegant Beef> I mean it's a moot point, all languages use intermediate representations
21:42:38	FromDiscord	<exelotl> lol rika
21:43:16	disruptek	there are two things i like: llvm gives us the ability to target a modern ir that is closer to asm, if we want to. also, it's a platform that has wide support that we can leverage.
21:44:04	FromDiscord	<JSGRANT> @dom96 I think that's fair; C itself is the IR & it's mostly bikeshedding -- but still conceptually I like the 'purity' aspect; And yeah on disruptek's point, I'd assume there is an aspect of more fine-grained tuning
21:44:24	FromDiscord	<Elegant Beef> Yea it'd be cool to support, but complaining about using C as the IR is an unending complaint based off silly idea that "Transpiling bad"
21:44:43	FromDiscord	<dom96> disruptek: I'd say that C has a much wider support than LLVM
21:45:01	FromDiscord	<JSGRANT> That being said ... if I made a top-10 list for me regarding Nim; That's probably would "just make it" at number 10. It's by no means a killer-feature / deal-breaker
21:45:09	disruptek	llvm is wide enough for me. others may disagree, but they probably aren't writing code that i care about.
21:45:36	FromDiscord	<JSGRANT> I care a LOT more about making Nim "feel dynamic / reflective".
21:45:48	*	a_chou quit (Ping timeout: 260 seconds)
21:45:58	FromDiscord	<JSGRANT> That's why things like HCR are really exciting to me -- but that's probably my Lisp-history / bias.
21:46:18	disruptek	if you're into it, i really don't think it's very hard to achieve.
21:46:24	*	natrys quit (Ping timeout: 260 seconds)
21:46:26	disruptek	but, i would throw away the current impl.
21:48:09	FromDiscord	<JSGRANT> Also yeah, disruptek; I've never seen people stating Rust (or similar) not supporting enough platforms as a big achitectural issue. lol
21:48:39	FromDiscord	<JSGRANT> Disruptek: Assuming you're talking about hcr?
21:48:46	FromDiscord	<JSGRANT> Not nlvm or something? lol
21:48:47	FromDiscord	<Rika> most people only really care about 5 or so architectures
21:48:48	disruptek	yeah.
21:50:14	FromDiscord	<JSGRANT> Don't know next-to anything about language design ... but it "seems" like is should easier when we get incremental-compilation? idk
21:50:31	FromDiscord	<JSGRANT> Need to look into how it works a lot more; Because right now it's "basically magic" to me lol
21:50:57	FromDiscord	<exelotl> compiling to C has always been a huge selling point of a language to me, but yeah it basically all comes down to interop. I learned GBA dev in C, and when picking up Nim I could keep using the same toolchain and libraries. Meanwhile the Rust GBA folks basically have to reinvent everything themselves
21:51:08	disruptek	maybe a little easier, just because ic provides more guarantees wrt mutability.
21:51:35	FromDiscord	<Elegant Beef> Compiling to C is pretty nice, as then you can say "It's just a cleaner way to write C" 😄
21:51:45	disruptek	the fact is, our backend is not really the killer feature.
21:52:27	FromDiscord	<Elegant Beef> Now that metaprogramming 😄
21:52:49	disruptek	it'd be one thing if we were really plugged into generating lots of artifacts for C debugging or introspection or something.
21:52:53	disruptek	i just don't see that, though.
21:52:55	*	D_ quit (Ping timeout: 240 seconds)
21:53:20	disruptek	i would personally rather generate llvm-ir and plug /that/ into static analysis.
21:53:37	disruptek	i would rather generate llvm-ir that i can run on jvm.
21:53:44	FromDiscord	<JSGRANT> I mean people (and even myself) many times have gone "Well Lisp is compiled & and can do all this magic" but there seems to be a ton of late-binding there compared to Nim. So certainly the way we achieve that is probably going to differ? Again, something I need to look into a LOT more -- but it's really interesting to me. Between seeing HCR & Lisp-ish Macros, those were really the two biggest things that got me interested in Nim.
21:55:11	FromDiscord	<Elegant Beef> Coming from C# metaprogramming, compile time evaluation, portabillity, and UFCS are what's keeping me around. Releasing a binary then saying "Download latest dotnet core or mono runtime to run this" is just dumb
21:55:23	disruptek	i was never a serious lisper but i've always enjoyed the elegance. that's what's attractive to me. i want to achieve that in a language that is closer to the metal. that's the promise of nim, to me.
21:57:20	disruptek	the ability to stand on the shoulders of the c or c++ ecosystem is huge. my systems don't run java, but getting access to both ecosystems would be amazing.
21:58:40	FromDiscord	<Elegant Beef> Cause the C/C++ we dont need the RIIN initiative that Rust has
21:59:35	FromDiscord	<Elegant Beef> But yes write everything pure 😛
22:00:11	*	D_ joined #nim
22:00:20	FromDiscord	<Rika> RII() is a pretty bad idea for some situations anyway
22:00:26	FromDiscord	<Rebel> any chance someone has implemented PS for linux without just calling execProcess?
22:00:38	disruptek	!repo psutils
22:00:39	disbot	https://github.com/johnscillieri/psutil-nim -- 9psutil-nim: 11Port of python psutil to nim 15 23⭐ 11🍴 7& 2 more...
22:00:50	disruptek	what does that one do?
22:01:30	FromDiscord	<Rebel> thanks that's a good start need to get much more than just pids
22:01:55	disruptek	specific questions often yield specific answers.
22:02:01	FromDiscord	<Rebel> lol true
22:02:29	disruptek	there are so many ways to get process data on linux...
22:02:49	FromDiscord	<Rebel> also @Elegant Beef I would check out .NET 5 and even with .NET Core 3 + you can have single binaries that have the runtime embedded in them so users don't need to install .NET Core or .NET
22:02:50	FromDiscord	<Rebel> (edit) 'also @Elegant Beef I would check out .NET 5 and even with .NET Core 3 + you can have single binaries that have the runtime embedded in them so users don't need to install .NET Core or .NET ... ' => 'also @Elegant Beef I would check out .NET 5 and even with .NET Core 3 + you can have single binaries that have the runtime embedded in them so users don't need to install .NET Core or .NET5'
22:03:02	FromDiscord	<Rebel> lol yes disruptek I am fully aware
22:03:08	FromDiscord	<Rebel> just lazy and was hoping someone did it already
22:03:15	FromDiscord	<JSGRANT> sent a long message, see http://ix.io/2w9l
22:03:37	FromDiscord	<Rebel> and it's cross platform 😉
22:03:38	FromDiscord	<Elegant Beef> Lol rebel, im not going to use C# anywhere outside unity
22:03:43	FromDiscord	<Rebel> fair enough
22:03:52	FromDiscord	<JSGRANT> Not even beef-lang, beef? lol
22:03:55	FromDiscord	<Rebel> can also check corert which is pretty cool and can convert .NET Core to native code
22:03:57	FromDiscord	<Elegant Beef> Fuck no
22:04:04	FromDiscord	<JSGRANT> Elegant Roast
22:05:00	FromDiscord	<Elegant Beef> https://media.discordapp.net/attachments/371759389889003532/751563486743756970/unknown.png
22:05:05	FromDiscord	<Elegant Beef> So you lose good features
22:05:18	FromDiscord	<Elegant Beef> Not even faux meta programming
22:05:20	FromDiscord	<JSGRANT> Oh wow, that's kinda depressing
22:05:57	FromDiscord	<JSGRANT> But yeah -- really if we can get Nim like halfway or three-forths towards that workflow though; I'd be beyond happy and it 'seems' possible & a decent thing to shoot for imo.
22:06:29	FromDiscord	<Elegant Beef> REPL is hard for compiled language isnt it?
22:07:06	FromDiscord	<JSGRANT> Scala did it; Nim already did it (sorta).
22:07:30	FromDiscord	<JSGRANT> Obligatory https://github.com/inim-repl/INim
22:07:35	FromDiscord	<Elegant Beef> Yea i know of inim
22:08:36	FromDiscord	<Rebel> have you played around with the DLR elegant?
22:09:22	FromDiscord	<Elegant Beef> Nope i really only use C# inside Unity
22:10:14	FromDiscord	<JSGRANT> But I don't think it's really the repl that is the issue, more-so having sufficent reflection / late-binding where you can overwrite the old block of code without completely messing up the state.
22:11:33	FromDiscord	<Elegant Beef> I mean coming from C#, the amount i used reflection was mostly cause C# lacks metaprogramming
22:11:51	FromDiscord	<Rebel> there's a whole book about metaprogramming in C#? lol
22:12:00	FromDiscord	<JSGRANT> Also I guess you can do compile-time reflection (?) but I assume there are notably more costs (or at least things to keep track of) over late-binding / doing it at runtime *
22:12:22	FromDiscord	<Elegant Beef> I mean you do it on intialization of the code
22:12:24	FromDiscord	<Elegant Beef> Then cache it
22:12:27	FromDiscord	<Elegant Beef> But it's the dumbest shit
22:12:51	FromDiscord	<Elegant Beef> You tag things with attributes then search the entire appdomain to find them, then generate whatever you want
22:13:08	FromDiscord	<Elegant Beef> It
22:13:15	FromDiscord	<Elegant Beef> (edit) 'It' => 'It's the most roundabout way to do anythiing'
22:14:08	FromDiscord	<Elegant Beef> This is a funny response https://stackoverflow.com/a/281050
22:14:15	*	Guest94576 joined #nim
22:14:28	FromDiscord	<JSGRANT> Honestly if that never even comes close to happening -- it's still not even a dealbreaker for me; There's project I'm very hopeful for (like Spry) where that level of live-coding / updating is an explicit goal of the language.
22:14:46	FromDiscord	<Rebel> look at when that answer was posted
22:14:48	FromDiscord	<Rebel> before the DLR came out
22:14:54	FromDiscord	<Rebel> and the advent of IronPython
22:15:16	*	Guest94576 quit (Client Quit)
22:15:16	FromDiscord	<Elegant Beef> I dont know what your point is
22:15:44	FromDiscord	<Elegant Beef> the stanard C# runtime cannot metaprogram, so you cannot use it everywhere such as unity using ancient C#
22:17:14	FromDiscord	<Rebel> I would need to look at unity as I have not used it but you need to clarify
22:17:19	FromDiscord	<Rebel> when you are saying runtime
22:17:39	FromDiscord	<Rebel> do you mean the Common Language Runtime or do you mean both the CLR + Dynamic Language Runtime which sits on top of the CLR
22:17:47	FromDiscord	<Elegant Beef> Unity uses the monoruntime iirc
22:17:52	FromDiscord	<Rebel> oh shit lol
22:17:53	FromDiscord	<Elegant Beef> (edit) 'monoruntime' => 'mono runtime'
22:18:11	FromDiscord	<Elegant Beef> Either the mono runtime or il2cpp which is just a C# to CPP as the name implies
22:18:25	FromDiscord	<Elegant Beef> Eitherway C# isnt nearly as nice as Nim so dont see why i'd go back to C#
22:18:33	FromDiscord	<JSGRANT> I think it uses a serveral year-old version of Mono iirc?
22:18:48	FromDiscord	<Elegant Beef> It's on like C# 7 or 8 atm
22:19:18	FromDiscord	<JSGRANT> Oh that's not that bad then? Isn't that only like 1-2 years old
22:19:29	FromDiscord	<JSGRANT> I had someone telling me it was like closer to 5...
22:19:31	FromDiscord	<Rebel> I guess it depends what your goals are and what you are trying to do I enjoy C# and am working on creating a custom language with the DLR lol writing a lexer and parser by hand are a pita
22:19:46	FromDiscord	<Elegant Beef> C# doesnt do anything nicer than Nim imo, so there is no benefit to using it
22:20:05	disruptek	well, it's much better supported.
22:20:07	FromDiscord	<JSGRANT> Is F# or similar workable in Unity? I know Clojure sorta-kinda works with Arcadia
22:20:21	FromDiscord	<Elegant Beef> Yea, but that's pretty moot disruptek, when i dont really need support
22:20:44	FromDiscord	<JSGRANT> At this point I guess it doesn't matter; I've bought into the Godot koolaid
22:21:06	FromDiscord	<Elegant Beef> Unless F# is just C# in disguise no it wouldnt
22:21:24	FromDiscord	<Recruit_main707> @JSGRANT .net is usually compatible independently of the language, if unity uses mono, boo, f# and even ironpython should work iirc
22:21:25	FromDiscord	<Elegant Beef> You can in theory use the native libraries for scripting, but it's a mess
22:21:53	FromDiscord	<Recruit_main707> actually, not sure if ironpython supports mono
22:21:59	FromDiscord	<Rebel> can check out NeoLua
22:22:06	FromDiscord	<Elegant Beef> Well that's only true if you can import the unity project and use the .dlls and i have no clue if F# supports C# .dlls
22:22:16	FromDiscord	<Recruit_main707> thats what i mean
22:22:18	FromDiscord	<Rebel> couldn't you use Fody and Costura to weave the dlls?
22:22:25	FromDiscord	<JSGRANT> Hm, curious I haven't heard any popular attempts in Unity; Well ... I guess you're paying for the ecosystem even if C# isn't ideal imo
22:22:37	FromDiscord	<Elegant Beef> Dont look at me, it's a proprietary engine that could be cool if it was OSS 😛
22:22:44	FromDiscord	<JSGRANT> Arcadia I only knew about because it was niche-enough to be "cool"
22:23:36	FromDiscord	<Recruit_main707> i have used c# dlls with other .net langs before, the only problem is that they usually run on an older .net version, that will be a big obstacle, i dont know how actively developed f# is
22:24:41	FromDiscord	<Elegant Beef> Turns out some people are using F# for unity
22:24:50	FromDiscord	<Elegant Beef> https://github.com/AugustDailey/Functional-Game-Development-Senior-Project
22:26:19	*	abm joined #nim
22:30:50	*	pietroppeter quit (Quit: Connection closed for inactivity)
22:32:25	FromDiscord	<Rebel> any chance anybody knows the easiest way to store bytes read from a file into an array? Was looking at filestreams and then realized readBytes may be easier but stuck with streams and am regretting it lol. https://play.nim-lang.org/#ix=2w9p Not sure what the error means either Error: cannot evaluate at compile time: bFile
22:33:05	FromDiscord	<dom96> array sizes need to be evaluatable at compile-time
22:33:14	FromDiscord	<dom96> use a seq for dynamic sizing
22:48:21	FromDiscord	<Rebel> interesting
22:49:44	FromDiscord	<Rebel> and then let's say you needed to pass that byte seq to a proc that expected an array I could then just create a new array based off the seq?
22:58:26	bozaloshtsh	is there any work already done on implementing closure iterators in the js backend? I'm trying to implement it but don't want to duplicate work here
23:00:53	*	thomasross joined #nim
23:00:53	*	krux02 quit (Read error: Connection reset by peer)
23:01:31	*	krux02 joined #nim
23:08:17	disruptek	doubtful.
23:12:08	FromDiscord	<Rebel> hmmm turns out maybe I don't need to do any funky casting a seq may work if unsafeAddr array[int, byte] == unsafeAddr seq
23:12:17	FromDiscord	<Rebel> (edit) 'seq' => 'seq[byte]'
23:14:14	FromDiscord	<Rebel> don't even remember why I used an array in the first place think I just copied the code from nim forums lol
23:18:40	bozaloshtsh	Rebel: what you probably want is the readAll() proc
23:19:04	bozaloshtsh	unless I've misunderstood what you're trying to achieve
23:19:53	bozaloshtsh	if you try to write to a seq in a low-level way, I assume bad things will happen.
23:21:45	*	lritter quit (Quit: Leaving)
23:25:01	FromDiscord	<exelotl> sent a code paste, see https://play.nim-lang.org/#ix=2w9y
23:25:22	FromDiscord	<exelotl> and it would automatically deduce the types in the method and assign them to the fields with the same name. And if you later decided you didn't want to assign, you could use `func (.x, .y)` instead, and it would still deduce the types, but not perform the assignment
23:26:22	bozaloshtsh	write a macro!
23:26:22	FromDiscord	<Rebel> I want to read bytes from a file and store them in a data structure that I can use that unsafeAddr with WriteProcessMemory
23:26:51	bozaloshtsh	Rebel: read it into a string then turn that into a cstring
23:27:26	bozaloshtsh	AFAIK a cstring is pretty much exactly a null-terminated char buffer so you can use unsafeaddr with that
23:27:43	FromDiscord	<exelotl> bozaloshtsh: I tried that a while back but I couldn't find a nice way that was both convenient and syntactically valid
23:27:55	bozaloshtsh	cstring(stream.readAll()) didn't work?
23:28:01	bozaloshtsh	oh misread username sorry
23:28:01	FromDiscord	<Rebel> interesting I know array[int, byte] works
23:28:10	FromDiscord	<Rebel> I didn't try cstring will try that soonish
23:28:19	FromDiscord	<Rebel> the C# equivalent is System.IO.File.ReadAllBytes
23:29:05	bozaloshtsh	C# doesn't let you play around with raw pointers so (I assume) it provides you with an array-of-bytes-like abstraction
23:29:23	bozaloshtsh	actually never mind I have no idea what C# does
23:29:23	FromDiscord	<Rebel> well the best you can get without compiling with unsafe are IntPtrs
23:30:13	bozaloshtsh	an array of bytes won't work for this because you _have_ to know its size at compile time
23:30:55	bozaloshtsh	you could read the file at compile time, however, so there's that :p
23:34:48	FromDiscord	<Rebel> not possible
23:34:56	FromDiscord	<Rebel> for what I am doing
23:36:52	FromDiscord	<Rebel> the user is passing in the file
23:40:48	*	krux02_ joined #nim
23:42:24	*	FromDiscord quit (Remote host closed the connection)
23:42:37	*	FromDiscord joined #nim
23:44:00	*	vicfred quit (Quit: Leaving)
23:44:11	*	krux02 quit (Ping timeout: 240 seconds)
23:48:08	FromDiscord	<Rebel> File path*
23:48:54	*	a_chou joined #nim
23:49:02	FromDiscord	<Elegant Beef> What are you doing exactly?
23:49:25	FromDiscord	<Elegant Beef> Reading a file, then wanting to do what with it
23:53:12	FromDiscord	<Rebel> Just want to store the bytes in an array or seq and then call writeprocessmemory with lpbuffer being the unsafeaddr of that seq or array
23:58:26	FromDiscord	<Rebel> hardcoding an array[int, byte] works just fine but is not feasible lol I got some ideas so we should be gucci
23:59:41	FromDiscord	<Elegant Beef> I mean you can do this if i get what you want↵https://play.nim-lang.org/#ix=2w9F
23:59:49	FromDiscord	<Rika> why does it have to be unsafeaddr