<< 29-05-2019 >>

---

00:00:07	*	deech quit (Remote host closed the connection)
00:00:35	*	deech joined #nim
00:03:47	*	stefanos82 quit (Remote host closed the connection)
00:19:59	sealmove	are all operations on system.set O(1)?
00:20:24	*	lritter quit (Ping timeout: 258 seconds)
01:28:12	*	deech quit (Remote host closed the connection)
01:28:34	*	deech joined #nim
02:01:58	*	cyberjpn joined #nim
02:01:59	*	cyberjpn quit (Client Quit)
02:02:07	*	banc quit (Quit: Bye)
02:04:26	FromGitter	<jrfondren> I believe so, but you confirm with a benchmark of sets over different range types. range[1..10], range[1..1000], range[1..10_000]
02:16:40	*	xet7 quit (Quit: Leaving)
02:20:31	*	theelous3 quit (Ping timeout: 268 seconds)
02:22:51	*	seerix joined #nim
02:23:34	*	banc joined #nim
02:44:00	FromGitter	<kayabaNerve> If you have a seq with a length of 5, and call `mySeq.delete(100, mySeq.len - 1)`, the seq's length becomes 100 :/
02:51:30	*	laaron quit (Remote host closed the connection)
02:53:42	*	laaron joined #nim
03:04:08	*	dddddd quit (Remote host closed the connection)
03:07:51	leorize	Araq, narimiran: pushed a new (simpler) implementation for 32-bit testing with less unrelated bugs
03:09:57	*	smitop quit (Quit: Connection closed for inactivity)
03:13:23	*	kapilp quit (Quit: Connection closed for inactivity)
03:34:02	*	rnrwashere quit (Remote host closed the connection)
03:57:19	*	deech quit (Ping timeout: 248 seconds)
04:04:15	*	rnrwashere joined #nim
04:04:21	*	laaron quit (Remote host closed the connection)
04:04:22	*	cyraxjoe quit (Ping timeout: 246 seconds)
04:07:08	*	laaron joined #nim
04:08:41	*	laaron quit (Remote host closed the connection)
04:09:37	*	laaron joined #nim
04:12:12	*	jasper_ joined #nim
04:27:54	*	nsf joined #nim
04:35:56	*	Snircle quit (Quit: Textual IRC Client: www.textualapp.com)
04:36:33	*	macsek1911[m] quit (Remote host closed the connection)
04:36:36	*	Manny8888 quit (Read error: Connection reset by peer)
04:36:36	*	leorize[m] quit (Read error: Connection reset by peer)
04:36:40	*	spymasterd[m] quit (Remote host closed the connection)
04:36:45	*	lqdev[m] quit (Read error: Connection reset by peer)
04:36:45	*	Connor[m] quit (Read error: Connection reset by peer)
04:36:47	*	Cold[m] quit (Remote host closed the connection)
04:36:48	*	planetis[m] quit (Read error: Connection reset by peer)
04:36:48	*	BitPuffin quit (Read error: Connection reset by peer)
04:36:51	*	TheManiac[m] quit (Remote host closed the connection)
04:36:57	*	Demos[m] quit (Remote host closed the connection)
04:37:10	*	skrylar[m] quit (Read error: Connection reset by peer)
04:37:10	*	yglukhov[m] quit (Write error: Connection reset by peer)
04:37:10	*	narimiran[m] quit (Write error: Connection reset by peer)
04:37:10	*	GitterIntegrati4 quit (Write error: Connection reset by peer)
04:37:10	*	Miguelngel[m] quit (Remote host closed the connection)
04:37:10	*	xomachine[m] quit (Remote host closed the connection)
04:37:10	*	isaac[m]1 quit (Read error: Connection reset by peer)
04:37:10	*	gh0st[m] quit (Read error: Connection reset by peer)
04:37:10	*	zielmicha[m]1 quit (Remote host closed the connection)
04:37:10	*	k0mpjut0r quit (Write error: Broken pipe)
04:43:19	*	Connor[m] joined #nim
04:51:33	FromGitter	<Varriount> Anyone seen ryukoposting lately?
04:54:25	*	Senketsu quit (Quit: WeeChat 2.4)
05:01:40	*	Manny8888 joined #nim
05:01:40	*	BitPuffin joined #nim
05:01:40	*	Demos[m] joined #nim
05:01:40	*	leorize[m] joined #nim
05:01:40	*	k0mpjut0r joined #nim
05:01:40	*	isaac[m]1 joined #nim
05:01:40	*	gh0st[m] joined #nim
05:01:40	*	GitterIntegrati4 joined #nim
05:01:47	*	planetis[m] joined #nim
05:01:47	*	TheManiac[m] joined #nim
05:01:47	*	macsek1911[m] joined #nim
05:01:47	*	Cold[m] joined #nim
05:01:47	*	narimiran[m] joined #nim
05:01:47	*	spymasterd[m] joined #nim
05:01:48	*	zielmicha[m]1 joined #nim
05:01:48	*	lqdev[m] joined #nim
05:01:48	*	skrylar[m] joined #nim
05:01:49	*	yglukhov[m] joined #nim
05:01:50	*	xomachine[m] joined #nim
05:01:53	*	Miguelngel[m] joined #nim
05:14:55	*	narimiran joined #nim
05:24:56	*	leorize quit (Quit: WeeChat 2.3)
05:30:18	*	laaron quit (Remote host closed the connection)
05:37:11	*	laaron joined #nim
05:53:16	*	solitudesf- joined #nim
06:02:40	Zevv	17 april last
06:04:28	*	leorize_ joined #nim
06:13:32	*	leorize_ quit (Remote host closed the connection)
06:15:45	FromGitter	<alehander42> So await is not a macro but a keyword right
06:17:14	Araq	wrong
06:17:29	leorize[m]	it's not even in the keyword list
06:17:43	Araq	it's detected within .async
06:22:32	*	leorize_ joined #nim
06:23:51	Zevv	lib/pure/asyncmacro.nl:333
06:33:19	*	ShalokShalom joined #nim
06:36:03	*	PMunch joined #nim
06:36:46	leorize_	so after my new 32 bit ci got up, the error count dropped to 2 :p
06:39:51	*	leorize_ quit (Quit: WeeChat 2.3)
06:40:15	*	leorize_ joined #nim
06:41:31	Araq	leorize_, can you disable these 2 tests so that we can merge the PR?
06:43:42	leorize_	sure
06:46:01	*	kapilp joined #nim
06:47:15	*	leorize_ is now known as leorize
06:52:09	*	marcazar joined #nim
06:53:54	narimiran	leorize: one of those tests is just wrong ordering, otherwise is ok, right? and the other one?
06:58:59	FromGitter	<alehander42> Oh right
06:59:27	FromGitter	<alehander42> So in this case people can detectawait
06:59:34	FromGitter	<alehander42> Dot await
06:59:53	FromGitter	<alehander42> But I am not sure it's a better syntax honestly
07:00:00	*	gmpreussner quit (Quit: kthxbye)
07:02:39	*	krux02 joined #nim
07:04:21	*	gmpreussner joined #nim
07:06:55	leorize	narimiran: "closureleak" <-- doesn't seem to be a nice thing
07:07:21	leorize	and it's not just wrong ordering I think, the output is ridiculously large (see that barrage of newlines)
07:09:38	*	leorize quit (Remote host closed the connection)
07:12:55	*	rnrwashere quit (Remote host closed the connection)
07:15:01	Araq	the newlines are a separate issue we're working on
07:28:27	*	leorize joined #nim
07:31:22	*	hoijui joined #nim
07:32:44	*	solitudesf- quit (Ping timeout: 258 seconds)
07:40:36	*	Amun_Ra quit (Ping timeout: 244 seconds)
07:42:54	*	Amun_Ra joined #nim
07:52:55	leorize	Araq: looks like the excessive newlines leaked to 64-bit builds :/
07:54:44	*	laaron quit (Remote host closed the connection)
07:55:59	*	laaron joined #nim
08:00:38	livcd	custom exceptions need to be object of Exception ? i see somewhere in my old nim files ref object of Exception :O
08:03:42	*	hoijui quit (Remote host closed the connection)
08:06:43	*	couven92 joined #nim
08:10:36	PMunch	Hmm, I'm trying to read a large list of string into my program to create an array on compile-time
08:10:53	PMunch	But it doesn't seem to like staticRead("filename").splitLines()
08:23:24	narimiran	leorize: excessive newlines were here before, for quite some time. but we just fixed it :)
08:24:06	leorize	narimiran: it's failing for my PR :p
08:24:24	*	ShalokShalom quit (Remote host closed the connection)
08:25:30	narimiran	leorize: https://github.com/nim-lang/Nim/pull/11351
08:26:03	leorize	yay
08:26:05	WilhelmVonWeiner	is there a "best practices" way to run tests in nim?
08:26:33	WilhelmVonWeiner	there's a unittest module but I see in some stdlib files they end in "when isMainModule"
08:26:43	leorize	Araq dislikes unittest
08:26:52	leorize	that's why stdlib don't use it :p
08:27:09	leorize	narimiran: aside from that one problem, 32bit is passing now :p
08:27:28	livcd	i wish i could just bypass windows defender
08:28:19	narimiran	leorize: can't you disable tests/errmsgs/twrong_at_operator.nim ? it's just the order of expected procs
08:29:07	narimiran	github down for everybody or just me?
08:29:43	lqdev[m]	probably just you
08:29:45	narimiran	it's back up :)
08:30:07	leorize	narimiran: disabled for 32bit then it dies for everything else
08:30:07	narimiran	lqdev[m]: have you seen the mentions from yesterday about you memory consumption problem?
08:30:24	*	clyybber joined #nim
08:30:44	Araq	clyybber, the '=move' stuff is getting important, want me to take over?
08:30:53	lqdev[m]	yes, I've just been reading through those messages
08:31:05	narimiran	leorize: ah, yeah, now i see i was looking at 64bit tests
08:32:04	narimiran	Araq: is "disabled: 32bit" a valid 'flag'? https://github.com/nim-lang/Nim/pull/11337/commits/0039e2f3a91b48cc5f11b41f4e692c79e3181884
08:32:58	Araq	disabled: "32bit"
08:33:05	narimiran	leorize: ^
08:33:10	Araq	see testament/specs.nim line 211
08:33:11	leorize	it seems to work without the quotes, but sure
08:33:31	Araq	it's not documented well, but the code isn't overwhelming once you know it a bit :P
08:34:21	PMunch	Uhm, Additional info: "Could not find command: \'/bin/sh\'. OS error: Bad file descriptor" [OSError]
08:34:55	*	stefanos82 joined #nim
08:36:19	clyybber	Araq: Yeah, sry, I can't seem to figure out why the tests fail
08:36:37	Zevv	lqdev[m] / varriount: is this helpful? https://github.com/zevv/npeg/tree/dot#grammar-graph
08:38:01	clyybber	Araq: Removing NilLit from movable Node kinds should not cause problems right?
08:38:50	Araq	clyybber, why did you introduce the nfNoConst? it's bad, I don't like it
08:39:29	PMunch	I'm getting a lot of these strange errors..
08:40:04	clyybber	Araq: Yeah, it's really WIP. I didn't want to replicate the codegen logic in injectdestructors
08:40:27	PMunch	After switching my code from spawning one thread per domain query but rather doing a set amount of threads and feeding them domain names to resolve over a channel
08:42:14	*	arecaceae quit (Remote host closed the connection)
08:42:33	*	arecaceae joined #nim
08:43:08	WilhelmVonWeiner	Can someone better at Nim tell me what I might be doing wrong here? https://hastebin.com/oseqatiriq.cs
08:46:05	PMunch	By the way, this is the code I'm running. It works sometimes, but not always: http://ix.io/1KmD/Nim
08:47:38	PMunch	WilhelmVonWeiner, works fine if you change it to var q: Queue[10, int]
08:48:11	PMunch	That holds for both examples
08:49:28	WilhelmVonWeiner	"got: <static[int literal(10)](10) but expected: <N, T>"
08:49:46	WilhelmVonWeiner	`var q: Queue[10, int]`
08:50:45	WilhelmVonWeiner	nevermind
08:50:48	WilhelmVonWeiner	I'm an idiot
08:51:27	WilhelmVonWeiner	i should RTFO next time...
08:52:09	PMunch	Haha, no worries, we've all been there
08:53:44	Araq	clyybber, well literals are like function calls, they always produce a fresh value that can be moved
08:54:47	clyybber	Ok, that might be the cause of some of the problems then...
08:59:08	*	neceve joined #nim
09:13:22	PMunch	Hmm, it seems like it's the creation of streams that fails: http://ix.io/1KmJ
09:16:55	*	abm joined #nim
09:18:32	*	jasper_ quit (Quit: Page closed)
09:21:41	PMunch	So what would cause something like that..
09:24:17	Zevv	PMunch: cna you share your domain_list.txt?
09:24:49	PMunch	https://yurisk.info/domain_list.txt.gz
09:24:52	PMunch	It's a pretty long list..
09:25:04	PMunch	Got it from here: https://yurisk.info/2010/08/14/list-of-valid-domain-names/index.html
09:25:16	PMunch	Not all the domains on it are still valid though
09:25:37	Zevv	Ok, stuff is running. How long does it take to break down for you?
09:26:28	PMunch	It's kinda weird, it might do a full run, or it might crash after only 20 or so
09:26:36	PMunch	By the way, change that IP
09:26:42	Zevv	hm ok
09:26:59	PMunch	It's for the DNS server that I'm testing, so dig will probably list all of those as failures
09:30:49	Zevv	can't get it to crash here :/
09:31:19	PMunch	Hmm, I think it might be my computer that's running out of file descriptors or something like that
09:31:24	PMunch	But that would be strange..
09:31:30	Zevv	strace
09:32:04	*	Vladar joined #nim
09:34:47	*	floppydh joined #nim
09:35:59	PMunch	Tried to hard-code the threads count to 1, seems to still crash
09:36:13	PMunch	At least that'll make strace a bit easier
09:36:48	PMunch	Although it does happen a lot less
09:37:52	PMunch	Hmm, a snippet from the strace output: http://ix.io/1KmT
09:38:24	Zevv	you need strace -f
09:42:09	PMunch	http://ix.io/1KmX
09:42:51	PMunch	I'm off to lunch now, back in a bit
09:54:44	lqdev[m]	Zevv: those graphs seem like a helpful debugging feature
09:56:17	Zevv	yeah, I guess so - it nicely shows complexity and relations. And everybody loves colorful graphs, so that's a pro. I'll merge it to main soon.
10:02:10	Araq	-d:nimv019 is a thing now
10:02:31	Araq	collecting all the switches you need for a transition period form 0.19 to 0.20
10:03:17	narimiran	a.k.a now it's even easier to ignore deprecation warnings and never fix you code :P
10:04:34	Araq	well to be honest, Nim's development now outpaces the compiler's development
10:04:55	FromGitter	<mratsim> too fast too furious
10:04:55	Araq	and the Nim compiler NEEDS -d:nimOldCaseObjects
10:15:24	*	leorize quit (Remote host closed the connection)
10:17:37	*	solitudesf- joined #nim
10:18:03	*	leorize joined #nim
10:18:45	*	leorize quit (Client Quit)
10:29:27	PMunch	nimOldCaseObjects?
10:30:41	PMunch	Zevv, npeg makes graphs now? Sweet!
10:31:24	narimiran	...only if your computer has enough RAM :P
10:31:49	lqdev[m]	...and you dont F up your parser like I did
10:32:24	Zevv	hehe
10:33:37	*	a_b_m joined #nim
10:36:01	PMunch	Hmm, least helpful error message: "test.nim(52, 19) Error: type mismatch"?
10:36:16	*	abm quit (Ping timeout: 244 seconds)
10:36:29	lqdev[m]	:thinking: `you must provide a compile-time value for the discriminator 'kind' in order to prove that it's safe to initialize 'sons'.`
10:36:53	lqdev[m]	how do I prove that it's safe to initialize `sons`? I tried using a concept, no luck
10:37:24	*	lqdev[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/PwaZMQDfcZkRadAyzaMlVkYA >
10:37:29	leorize[m]	Zevv: do you still want my email matcher?
10:37:47	Zevv	yes, please
10:43:36	*	sealmove quit (Quit: WeeChat 2.4)
10:44:40	PMunch	Hmm, is there a type-safe way to have an array indexed by an enum?
10:45:10	lqdev[m]	yes, `array[low(YourEnum)..high(YourEnum), YourEnum]`
10:45:32	lqdev[m]	pretty repetitive but works
10:46:10	lqdev[m]	if you don't specify the range explicitly you won't be able to use the `high(YourEnum)` as the index
10:47:48	*	xet7 joined #nim
10:52:55	leorize[m]	Zevv: here you go: http://ix.io/1Kna
10:53:16	leorize[m]	please let me know once you're done w downloading it :p
10:53:56	leorize[m]	my stuff still hasn't been graded so... gotta limit exposure :p
10:54:33	Zevv	aaand its here
10:55:20	Zevv	ghehe: NPeg: grammar too complex :)
10:56:07	leorize[m]	oops, can't delete it
10:56:21	leorize[m]	well, it's not like anyone will look for it
10:57:05	leorize[m]	Zevv: lol
10:59:17	leorize[m]	I'm pretty sure this can be optimized
10:59:40	Zevv	well, I'll add some smarts to do the Right Thing - only inline if rules are "small enough"
11:00:37	PMunch	lqdev[m], oh, my bad. I just assumed it used the int value in that case :)
11:00:38	Zevv	here you go: http://zevv.nl/div/mail.png, enjoy the view
11:01:37	PMunch	array[YourEnum, int] works as well
11:03:07	leorize[m]	Zevv: nice :)
11:03:35	leorize[m]	oh and that email matcher also come w a ip matcher & domain name matcher :p
11:03:50	FromGitter	<data-man> @Zevv tests/performance.nim buildpatt.nim(172, 9) Error: NPeg: syntax error: {'0' .. '9', 'A' .. 'F', 'a' .. 'f'}{4} for nim-devel ?
11:04:16	Zevv	data-man: have to make my train, will look in an hour or so
11:04:46	FromGitter	<data-man> Cool!
11:07:01	Zevv	oh performance.nim is simply out of date, it probable should not be in git
11:08:07	leorize[m]	narimiran: quoted 32bit and still failing for non 32 bit
11:08:19	FromGitter	<data-man> @Zevv Why? Add more benchmarks! :)
11:08:21	narimiran	leorize[m]: gaaah
11:09:55	leorize[m]	maybe should just wait until araq get that newline pr in
11:10:01	FromGitter	<data-man> @Zevv https://github.com/pointlander/peg/blob/master/grammars/c/c.peg can be adapted for npeg?
11:10:36	*	jken joined #nim
11:12:08	lqdev[m]	Zevv: I think you should choose a different operator than `$` for referencing captures, it conflicts with the stringify operator
11:12:26	lqdev[m]	If you use it in a template, it just stringifies `1`
11:13:18	Zevv	data-man: not sure if you want to go there. nice toy project, but man: parsing C with a peg is pure machosism
11:13:35	Zevv	lqdev[m]: open for ideas. But why does it conflict?
11:14:20	Zevv	hehe, ment masochism but machosism is also true
11:14:26	lqdev[m]	it conflicts only if you use it in a template
11:15:00	Zevv	lqdev[m]: $1 is sugar for captures[0], which get injected
11:15:14	*	lqdev[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/LnPVTGmKlAqGBBWJMHrarXlx >
11:15:45	Zevv	try push captures[0] instead
11:15:59	lqdev[m]	Zevv: I know, it's just that the sugar just so happens to conflict with system.`$` in templates
11:16:11	lqdev[m]	already done that
11:16:37	Zevv	ok :) I already anticipated some problems there, but not sure about alternatives. ideas?
11:17:05	lqdev[m]	maybe use `\` instead of `$`? like in regex backreferences?
11:17:20	Zevv	does not parse in nim
11:17:48	leorize[m]	Zevv: https://rosettacode.org/wiki/Compiler/lexical_analyzer#Using_stream_with_lexer_library <- try writing that in npeg :) it would be some nice advertising for Nim :p
11:17:52	lqdev[m]	strange, this is a valid operator character according to https://nim-lang.github.io/Nim/manual.html#lexical-analysis-operators
11:18:35	lqdev[m]	perhaps `<` to complement `>`?
11:20:05	Zevv	hmm, or just reuse >, different context so no problem there
11:23:43	FromGitter	<data-man> @Zevv peg.go and cpp-peglib supports Packrat parsing. Are you planning to add it?
11:25:27	Zevv	nope. But thats just implementation, why would that matter, from a user perspective?
11:25:58	FromGitter	<kaushalmodi> lqdev[m], PMunch: `array[MyEnum]` works for me. See `terminal.nim` for an example.
11:27:05	PMunch	With only one type?
11:27:32	PMunch	I'm keeping counts for every enum, so I need my array to be array[MyEnum, int] anyways
11:28:43	FromGitter	<data-man> @Zevv Because the linear-time parsing :)
11:29:40	Zevv	npeg is linear time. and not a memory hog, like packrat
11:31:22	Zevv	data-man: brows through https://github.com/zevv/npeg/tree/master/doc if you want to know about design and alorithms used
11:32:18	FromDiscord_	<kodkuce> so in asynchttp serwer do i need to return after await req.respond, or it auto terminates all after
11:36:01	lqdev[m]	Zevv: it would be really nice if NPeg errors stored their position in the parsed text in the NPegError object
11:36:21	lqdev[m]	NPegException*
11:37:55	FromGitter	<data-man> @Zevv Thanks! I even found more doсы on arxiv.org :)
11:42:01	Zevv	lqdev[m]: will look into that
11:48:23	FromGitter	<kaushalmodi> PMunch: sorry, yes, typed in hurry over phone
11:48:58	FromGitter	<kaushalmodi> I meant to say that I didn't need to specify the high and low of the enum type.
11:49:26	PMunch	Oh yeah, I already discovered that :)
11:55:48	*	arecaceae quit (Remote host closed the connection)
11:56:07	*	arecaceae joined #nim
12:22:14	Zevv	Is the "Warning: programResult is deprecated" from unittest caused by something I do wrong, or is this a side effect of WIP?
12:22:48	*	abm joined #nim
12:23:43	lqdev[m]	kaushalmodi: really? the last time I tried that I got an IndexError
12:25:12	*	nc-x joined #nim
12:25:23	nc-x	Zevv: programResult was deprecated/removed recently
12:25:36	*	a_b_m quit (Ping timeout: 258 seconds)
12:26:08	nc-x	https://github.com/nim-lang/Nim/pull/11075
12:26:09	*	kapilp quit (Quit: Connection closed for inactivity)
12:26:37	narimiran	hey, nc-x! mobile version of our website should be fixed now
12:26:49	Zevv	nc-x: ok, so if I understand correctly that's WIP, unittest complaining is a known issue
12:27:22	FromGitter	<kaushalmodi> lqdev[m]: see https://scripter.co/notes/nim/#enum-length-arrays
12:27:58	FromGitter	<kaushalmodi> I have a small snippet there, but I have been heavily using enum indexed arrays as quick dictionaries
12:28:36	nc-x	narimiran: yay!!!
12:32:29	nc-x	There are other changes that can/should be made to the website IMO
12:32:45	narimiran	nc-x: of course there are :)
12:32:49	nc-x	for e.g. - the header has both learn and documentation
12:32:53	nc-x	they should be merged IMO
12:33:11	nc-x	esp. bcos Learn also contains links to the documentation
12:33:45	narimiran	yeah, and other stuff could be done differently, but i guess all that will wait until some major redesign
12:34:47	nc-x	👍
12:34:57	*	nc-x quit (Quit: Page closed)
12:37:22	*	solitudesf- quit (Ping timeout: 272 seconds)
12:38:41	*	Snircle joined #nim
12:39:24	*	tiorock joined #nim
12:39:24	*	tiorock quit (Changing host)
12:39:24	*	tiorock joined #nim
12:39:24	*	rockcavera quit (Killed (kornbluth.freenode.net (Nickname regained by services)))
12:39:24	*	tiorock is now known as rockcavera
12:42:25	*	dddddd joined #nim
12:43:20	FromDiscord_	<kodkuce> seq are passed by ref , right?
12:44:17	PMunch	Yes
12:44:25	PMunch	Well, it depends
12:44:58	PMunch	I think the seq itself (the count and the pointer to the data) might be passed by value IIRC
12:45:53	FromGitter	<alehander42> it's {Sup: {len: .., cap: ..}, data: pointer to [2, 4, 5]} afaik
12:46:03	FromGitter	<alehander42> but i think it changed in the new runtime
12:47:18	FromDiscord_	<kodkuce> ok ye, i just wanted to ask it dosent duplicated my stuff in seq 😃 was afraid for sec xD
12:48:47	FromGitter	<alehander42> but yeah it is generally `tySequence_qwqHTkRvwhrRyENtudHQ7g*` or similar, so seq is passed by ref
12:49:13	FromGitter	<mratsim> the main slowness with seq is when aliasing like let x = a -> this will allocate a complete new x by default
12:50:48	FromGitter	<mratsim> in general, anything that is over 3 * sizeof(pointer) is passed by pointer, and any type below is passed by copy
12:51:11	Zevv	3 * sizeof(float), even :)
12:51:16	FromGitter	<mratsim> you can enforce behaviour with {.bycopy.} or {.byref.} for FFI
12:51:32	FromGitter	<mratsim> sizeof(float) is always 24 bytes
12:52:05	FromGitter	<mratsim> sizeof(int) or sizeof(pointer) is 12 bytes on 32-bit platforms
12:53:47	FromGitter	<mratsim> 3*sizeof
12:57:09	dom96	narimiran: we shouldn't wait for a redesign to do these things
12:57:23	dom96	progressive improvements make a lot of sense
12:58:19	narimiran	dom96: ok, but how would you combine documentation and learn to make just one page?
12:58:38	narimiran	it's not that one is a subset of the other
12:59:04	dom96	I don't necessarily agree that we should combine those, but if you do you could just have a learn section and a docs section?
13:00:55	*	lritter joined #nim
13:06:53	*	theelous3 joined #nim
13:11:05	*	al_ joined #nim
13:11:32	*	apodo joined #nim
13:15:39	*	vlad1777d joined #nim
13:20:29	*	deech joined #nim
13:23:50	lqdev[m]	Zevv: take a look at https://nim-lang.github.io/Nim/manual.html#implementation-specific-pragmas-compile-time-define-pragmas, maybe it's a thing that could be used to fix https://github.com/zevv/npeg/blob/master/src/npeg/common.nim#L5
13:24:08	lqdev[m]	just make those variables {.intdefine.} and problem solved
13:24:14	lqdev[m]	consts*
13:24:56	FromDiscord_	<kodkuce> hmm
13:24:58	FromDiscord_	<kodkuce> http://ix.io/1KnO
13:25:19	FromDiscord_	<kodkuce> am i retarded or i dont get his error
13:26:05	narimiran	kodkuce give us a reproducible snippet
13:26:36	narimiran	but probably you just need to add `var`: errors: var seq[string]
13:26:58	narimiran	and while at it, add some spaces where needed, don't be a monster
13:27:28	lqdev[m]	^ please
13:27:39	lqdev[m]	spaces improve readability
13:28:18	FromDiscord_	<kodkuce> proc validate_username( inputed:JsonNode, var errors:seq[string] ) =
13:28:26	narimiran	can you read?
13:28:51	FromDiscord_	<kodkuce> spaces betiwn var:type too?
13:29:14	FromDiscord_	<kodkuce> that looks ugly
13:29:17	lqdev[m]	only there, don't add spaces after ( and before )
13:29:37	lqdev[m]	`proc name(arg1: type1, arg2: type2)`
13:29:54	narimiran	proc validate_username( inputed:JsonNode, var errors:seq[string] ) --> this won't work, and i won't tell you why, you have to read what people write to you
13:30:10	FromDiscord_	<kodkuce> spaces xD
13:30:33	FromGitter	<alehander42> he meant `var: errors: var seq[string]`
13:31:01	FromGitter	<alehander42> narimiran, those things are easy to miss, it wasnt obvious for me that he missed the second var as well
13:31:29	lqdev[m]	which second var?
13:31:32	narimiran	there's only one var needed, the first was part of the sentence
13:31:33	FromGitter	<alehander42> the only var indeed
13:31:43	FromGitter	<alehander42> yes but it does seem very confusing!
13:31:45	*	shadowbane joined #nim
13:31:48	Zevv	lqdev[m]: thansks, thats a good and cheap solution.
13:32:04	FromGitter	<alehander42> so yeah better to always wrap in ``
13:32:14	FromGitter	<alehander42> but sorry
13:32:16	narimiran	@alehander42, but he didn't even copy-pasted both of those, he just put one where he wanted
13:32:22	lqdev[m]	I was about to write that ^
13:32:35	FromDiscord_	<kodkuce> >> 14 proc validate_username(inputed: JsonNode, var errors: var seq[string]) =
13:32:51	FromDiscord_	<kodkuce> hmm it complins about indetation now
13:33:20	*	narimiran flips table
13:33:22	FromGitter	<alehander42> narimiran because as you see, to a person not familiar with the syntax
13:33:31	FromGitter	<alehander42> it seems as you say `var errors: var ..`
13:33:33	FromDiscord_	<kodkuce> hmm removing var infront errors removed error
13:34:30	narimiran	ok, here is the correct sentence, hopefully:
13:34:34	FromDiscord_	<kodkuce> proc validate_username(inputed: JsonNode, errors: var seq[string]) = WORK I THINK
13:34:48	FromGitter	<alehander42> that's why i said it's good to use quotes `` normally, as otherwise you just write a mess of code & text narimiran
13:34:52	narimiran	but probably you just need to add `var`. <some empty non-confusing space here> like this: `errors: var seq[string]`
13:35:08	FromGitter	<alehander42> yes, great
13:35:25	lqdev[m]	kodkuce: allow me to explain. types are defined like `arg: mods type[generic1, generic2...]`, where `arg` is the type name, `mods` are any necessary modifiers like `var` or `ref` and `generic1`, `generic2`... are generics
13:35:30	FromDiscord_	<kodkuce> litteraly i am confused what you all trying to tell me xD
13:35:51	FromGitter	<alehander42> is kuce a dog in serbian as well
13:36:13	FromDiscord_	<kodkuce> yep, but kodkuce means athouse
13:36:26	lqdev[m]	kodkuce: please read: https://nim-lang.github.io/Nim/manual.html#procedures
13:36:35	FromGitter	<alehander42> sorry narimiran
13:36:40	FromGitter	<alehander42> oh nice ok
13:36:53	FromDiscord_	<kodkuce> and kuce is writed as kuche , like this kuče
13:37:00	narimiran	lqdev[m]: don't bother, his usual reply is: "i dident read it"
13:37:39	FromDiscord_	<kodkuce> i did read it kinda, i just go trought it fast , mostly looking just exmaples
13:37:51	narimiran	lqdev[m]: i have already gave him some links and begged him to read.... but nah
13:39:57	FromDiscord_	<kodkuce> if i read it while i dont need it , my brain just GC marks it... I prefer learn by doing it , i learn better that way
13:40:52	narimiran	...as we all can see :D :D
13:42:45	narimiran	basically you're "outsourcing" searching/reading documentation, so we do it and just send you direct links to the parts you need at some moment
13:44:19	FromDiscord_	<kodkuce> hmm, possible, tought i newer thinked that way, i dident plan to be evil to community
13:45:15	FromDiscord_	<kodkuce> guess i can say i am sorry, but hmm will probbaly ask again at some point xD
13:45:29	lqdev[m]	here's a tip: ctrl+f in the manual (or any other part of the documentation)
13:45:39	FromGitter	<jrfondren> just make a chart out of your documentation requests. Then, if people don't answer you, you can draw a dip in the graph and report that the Nim community is losing their touch
13:45:40	FromDiscord_	<kodkuce> 😃
13:46:57	FromGitter	<jrfondren> "as you can see from this TTFR graph, over the summer the Nim community grew less responsive and this of course is a critical period for people still testing the language out."
13:48:19	WilhelmVonWeiner	Templates and macros are awesome.
13:48:29	livcd	emacs users raise your hands
13:48:36	WilhelmVonWeiner	The documentation could be more noob-friendly but I am lobing them
14:05:02	PMunch	WilhelmVonWeiner, really a fantastic feature :)
14:05:04	*	PMunch quit (Remote host closed the connection)
14:05:45	*	makerj quit (Quit: Page closed)
14:11:01	Zevv	lqdev[m]: -> privmsg
14:12:33	dom96	jrfondren: before long we'll have an SLA for answering questions in IRC :)
14:12:55	*	elrood joined #nim
14:31:12	*	Senketsu joined #nim
14:31:30	*	nsf quit (Quit: WeeChat 2.4)
14:49:59	Araq	bikeshedding question: should we remove the '0.' or go for 1.0?
14:50:13	WilhelmVonWeiner	no, only for 2
14:50:44	WilhelmVonWeiner	Nim 2 sounds fresh and clean, Nim 1 sounds like a Soviet ternary computer
14:51:33	clyybber	I really really want Setun
14:54:21	Araq	Setun? what does that mean?
14:54:35	FromGitter	<jrfondren> the big value of 1.0 is that it gives you a second first impression. So that's all I'd focus on. How good of an impression does the language make now? That's not the same thing as "how good is the language now", because people won't invest long enough to find out how good it is if they don't get a good impression of it.
14:55:41	narimiran	"well, they just switched from v0.20 to v20. i guess i need to wait until it is production ready at v100" :D :P
14:56:07	FromGitter	<jrfondren> I started using Nim not too long ago and my experience was that pretty much everything I tried to use had one or two issues with it. As in, github issues, PRs.
14:57:24	FromGitter	<alehander42> 1) 0 sounds better to me
14:57:45	FromGitter	<jrfondren> and there was that async bug that caused a simple web request to take 500ms longer than a synchronous request, if made outside of an event machine. Well that's exactly how someone would use it in exploratory or test code.
14:58:13	disruptek	for this, and other reasons, i'd stick to 0.20.
14:58:26	Araq	don't get me wrong, 0.20 will be 0.20
14:58:40	Araq	but what comes afterwards
14:58:41	disruptek	i'd expect nothing less.
14:58:42	FromGitter	<mratsim> Will it be 1.0RC though?
14:59:14	disruptek	i think newruntime needs some play. it could be the major defining feature of the language that makes people sit up and take notice, decide to dig in on 1.0.
14:59:23	narimiran	@mratsim depending on version naming scheme :P
14:59:41	FromGitter	<mratsim> I mean "spiritually"
14:59:42	narimiran	maybe it is 21RC :P :D
14:59:58	narimiran	yeah yeah, i know :) and yes, it is 1.0RC
14:59:58	FromGitter	<jrfondren> tires that aren't kicked will be found to be flat. I'd tie 1.0 to a "we went through stdlib and gave everything a good kick" step, so that the language won't seem broken to anyone giving it another look-over.
15:00:43	Araq	newruntime aside, that's what we have been doing for years now. fixing bugs, refining stuff, improving docs
15:01:04	Araq	but it never is "good enough" for v1
15:01:49	narimiran	@jrfondren that's good for newcomers, but what about all the existing code that it would break without x% of stdlib?
15:02:06	shashlick	1.0 means stability which you have already started providing with 0.19.x
15:02:24	narimiran	don't get me wrong, splitting the manual into 'stable' and 'experimental' part was a nice move IMO
15:06:43	*	rockcavera quit (Remote host closed the connection)
15:09:04	*	neceve quit (Remote host closed the connection)
15:09:49	FromGitter	<alehander42> i also dont think newruntime is very important for 1.0
15:10:10	FromGitter	<alehander42> a little more cleanup and 1.0 should be released imo
15:10:25	Araq	ok, what this "little more cleanup"
15:10:31	Araq	*what is this
15:10:46	FromGitter	<alehander42> well 0.20
15:10:48	FromGitter	<alehander42> or something
15:10:57	FromGitter	<alehander42> i mean finishing the stuff that 0.20 is about
15:12:02	shashlick	1.0 is a commitment to stability and something everyone can agree upon and maintain so that users feel confident
15:12:25	shashlick	i don't think it is any particular feature or # of open issues or something
15:12:27	*	solitudesf- joined #nim
15:12:39	Araq	agreed. it's not about perfection, it's about long term stability
15:12:44	*	Vladar quit (Remote host closed the connection)
15:13:08	shashlick	it will never be perfect, but bug fixes will continue to be released
15:13:30	Araq	v2 will be perfect :P
15:13:42	FromGitter	<jrfondren> anyway Python and Perl come to mind as languages that were pretty bad until they got up in the major versions. Perl at 5.x and I hear Python 4.x will be good.
15:13:54	shashlick	so the question is when you are ready to accept v1.0
15:13:58	narimiran	shashlick: agreed about stability
15:14:34	shashlick	and folks shouldn't be told to use devel when they run into issues like the discussion from yesterday
15:15:21	narimiran	yep, 0.20 should be "blessed" so no more "devel is more stable than stable"
15:17:23	shashlick	in fact, the 0.20.x branch should get backports as and when so users should use it instead of devel if they want the latest and greatest stable
15:17:49	*	rnrwashere joined #nim
15:18:16	Araq	I don't know if we will continue with the backporting
15:18:43	Araq	the backporting allows us to do breaking changes but we don't want more breaking changes
15:19:19	narimiran	well, 0.20 --> 1.0, and then i would like to see 1.0.2, 1.0.4, etc. - bugfixes without breaking changes and without any new features
15:19:58	shashlick	ya but what i mean is that just like folks live on devel nowadays, they should instead check out version-0-20 instead
15:20:16	shashlick	we can keep backporting fixes to that branch and make releases when appropriate, just like devel
15:20:36	shashlick	but people who are on the branch will get fixes right away instead of having to wait until an official release
15:20:42	*	floppydh quit (Quit: WeeChat 2.4)
15:20:49	narimiran	1.1.x, 1.2.x - new features, with as few breakings as possible
15:20:54	shashlick	of course, this can already be done today but we don't backport realtime
15:21:25	narimiran	shashlick: there were backports to 0.19 branch that somebody could have checkedout
15:21:47	shashlick	yes, we need to encourage that behavior
15:21:52	narimiran	we had "backport devel" versions 0.19.3 and 0.19.5 for example
15:22:16	narimiran	which then became 0.19.4 and 0.19.4
15:22:21	narimiran	*0.19.6
15:22:54	shashlick	and we also have nightlies for that branch so in some sense, we already have this stability that a 1.0 would deserve
15:24:29	*	rnrwashere quit (Remote host closed the connection)
15:24:50	FromGitter	<jrfondren> what I had in mind, talking about first impressions, was something like the documentation effort. Here's a list of features, can people annotate it (and create issues) as they run through the features like someone trying out the language might. This is already a lot like a documentation effort in itself since it's what you'd do if you were testing the documentation. On second thought though, this is something that
15:24:50	FromGitter	... someone could just go and do on their own.
15:25:44	*	rockcavera joined #nim
15:26:40	narimiran	@jrondren i think the playground/tour stuff that PMunch is working on will be really nice for first impression and getting the feel of the language
15:28:38	FromGitter	<mratsim> For more flexibility we can separate versioning of Nim compiler and Nim stdlib
15:29:14	FromGitter	<mratsim> not sure how that could be materialized but AFAIK Nim stdlib is still in need of a cleanup while Nim compiler only needs destructors
15:29:22	FromGitter	<jrfondren> oh yeah. so something like a "tour of strutils" would do double duty: on the one hand it's extra tutorial documentation for strutils, on the other hand it's an assurance that people won't run into "has anyone else ever used this?" tier bugs.
15:29:24	Araq	ha ha ha
15:29:52	Araq	ok, the compiler is only bad at destructors, nice :-)
15:31:11	*	Trustable joined #nim
15:31:38	FromGitter	<mratsim> yeah sure :p
15:32:23	FromGitter	<mratsim> the other pending stuff are non-breaking AFAIK (ok maybe incremental compilation will prevent compile-time globals or something)
15:33:12	Araq	I'll play with alternative IRs for IC, the AST is beginning to show its age
15:33:47	Araq	but this doesn't have to affect the macro system
15:34:16	Araq	eventually it should, what's good for compiler writers is also good for macro writers
15:35:43	disruptek	are exceptions changing at or before 1.0?
15:37:04	disruptek	if backporting won't continue, then it seems to me there is no place for a stable release, which means nim isn't ready for 1.0.
15:37:20	Araq	harsh words.
15:37:30	disruptek	fair, i think.
15:37:43	shashlick	when did anyone say backporting won't continue
15:37:47	Araq	well narimiran agrees with you and he is doing the backporting
15:38:05	narimiran	...and he would like to continue to do them :)
15:38:05	disruptek	it's a decision to make; i'm just stating my opinion. no skin in this game.
15:38:42	Araq	I'm not sure the backporting is required when we test more and more Nimble packages, CPU archs
15:39:25	disruptek	stable should simply continue to get more stable. if fixes (and only fixes) aren't ported, i don't see how that can happen.
15:39:41	FromDiscord_	<kodkuce> hmm i am newb , but if my voice counts, is there any reason why rush for 1.0 , i mean better have a good 1.0 then fast but broken
15:39:52	Araq	about exceptions, there are no plans to do change them any further.
15:40:02	disruptek	okay, thanks.
15:40:04	Zevv	what is the idiomatic way to get data from a custom exception in an except block? Do I need to explicitly cast?
15:40:28	Araq	disruptek, why? are you pro or anti exceptions?
15:40:49	Araq	kodkuce: "rush for 1.0"? Nim is older than Rust...
15:41:04	shashlick	backporting is the only way to provide stability that lasts
15:41:19	Araq	ok ok ok! you win. We'll backport.
15:41:57	shashlick	but i'm curious why you think more testing will give us the same stability
15:42:04	shashlick	since devel changes nonstop
15:43:04	Araq	in my little world Nim is almost always "green" on devel and so it doesn't break any code
15:43:11	*	Tyresc joined #nim
15:43:19	disruptek	i'd like to see them fully conceptualized so that your goals (no alloc?) and mine (compile-time raises-like audit) are satisfied. i like quirky and i don't understand why it isn't either 1) the default, or 2) removed.
15:43:42	FromGitter	<jrfondren> I wouldn't think less of Nim if the version I had installed right now was named 1.0. It's pretty good. My bikeshedding contribution is that the value of major version changes and 1.0 especially is that it encourages people to take a second look at the language.
15:44:13	Araq	disruptek, I consider it a superior alternative to -fno-exceptions
15:44:14	disruptek	the idea behind backporting is that new code and features (which can introduce bugs) is minimized to the greatest possible extent.
15:44:29	FromDiscord_	<kodkuce> yep but on rust i think there are like 1000 people in dev team, duno my opinion is if you go 1.0 displaying it as like LTS and it shows to be buged and broken it would bring a lot people fast and drop them permanent event faster, option 2 is go 1.0 but dont say its perfect 😃
15:44:45	disruptek	Araq: quirky, you mean?
15:44:49	Araq	yes
15:46:10	Araq	disruptek, to make them the default we would need something like {.important.} annotations for object fields that can only be accessed if the current exception is nil
15:46:21	FromDiscord_	<kodkuce> about backporting i would drop that and risk for bringing devel to perfection xD, plus i want you to work more on new runtime 😃
15:47:33	disruptek	when you consider the entire problem domain and the simplicity of a single (quirky) exception model, i think annotations are a small price to pay.
15:47:47	Araq	the point is, quirky exceptions are lovely but much too experimental for v1
15:48:15	disruptek	nim hasn't reached 0.20 yet, though. seems like 1.0 is a future target.
15:48:18	Araq	so I cannot make them the default and I don't want to remove them either.
15:49:48	*	Trustable quit (Remote host closed the connection)
15:49:48	disruptek	these innovations are what compel new users of the language to choose nim. i'm always going to support the differentiators.
15:51:10	disruptek	if they aren't ready for 1.0, so be it. i would wait until they are. showing off nim 1.0 with these powerful new approaches makes more sense to me than making them pillars of nim 2.0. as soon as you cut 1.0, progress will have to slow as large amounts of code become important to support going forward.
15:51:56	Araq	that ship has already sailed though. Porting .async to --newruntime is an unknown amount of work
15:52:13	disruptek	it's fine. async is a library.
15:57:50	*	seerix quit (Remote host closed the connection)
16:02:22	*	rnrwashere joined #nim
16:02:52	FromDiscord_	<kodkuce> kidnap dom put him in basement and force him to rewrite it on new runtime, easy solution
16:03:59	shashlick	fact is you need to draw the line somewhere and release 1.0, there's no perfect timing so might as well release 1.0 as what nim has been for the last couple years
16:04:26	shashlick	and let that live as 1.0 for a year or two while 2.0 comes out
16:04:45	FromGitter	<alehander42> disruptek the problem is that nim continued adding new innovations 10 years
16:05:01	FromGitter	<alehander42> you're right that newruntime would be best for 1.0
16:05:12	FromGitter	<alehander42> but if we wait for newruntime for 1.0, other new things will appear
16:05:16	FromGitter	<alehander42> and so on
16:05:23	narimiran	spot on
16:05:32	FromGitter	<alehander42> and i feel that it would be similar to the way 1.0 was delayed until
16:06:08	FromGitter	<alehander42> otherwise i'd love to see more stuff there
16:06:26	FromGitter	<alehander42> but i feel we shouldn't fixate on 1.0 and it's better to let it out sooner rather than later
16:06:31	*	rnrwashere quit (Ping timeout: 250 seconds)
16:06:36	FromGitter	<alehander42> and start seeing actual pain points
16:06:40	FromGitter	<alehander42> from more widespread use
16:06:41	disruptek	newruntime is actually the least of the problems, because the same code can run on multiple runtimes. it's just that i'd want personally want to advertise newruntime for 1.0, as the new third way killer feature...
16:06:43	FromGitter	<alehander42> eventually
16:07:02	shashlick	killer features are an illusion
16:07:11	shashlick	you want to be diligent and consistent to be stable
16:07:22	shashlick	it isn't exciting and cool to be stable
16:07:28	shashlick	but most of the world lives in that space
16:08:06	disruptek	you choose a restaurant based upon their killer tacos; you come back for their margaritas and chips, and that amazing mariachi band on tuesday nights.
16:08:28	shashlick	in fact, one option is to promote 0.19.x into 1.0 so it continues being stable
16:08:46	Araq	shashlick, that always was our plan B
16:08:48	FromGitter	<alehander42> but we already have --newruntime: it's just not default, right
16:08:54	FromGitter	<alehander42> experimental
16:08:59	FromGitter	<alehander42> this seems good enough to me
16:09:02	FromGitter	<alehander42> people can play with it
16:09:09	shashlick	disruptek: you do that in your youth, going from one restaurant to the next finding the best tacos, once you are my age sitting in a large org, reality hits
16:09:25	FromGitter	<alehander42> and eventually it can became stable in e.g. 2.0
16:09:34	narimiran	shashlick: but devel has lots of goodies i don't want to live without. and i don't mean just new features, but better error messages, better docs, etc.
16:10:09	disruptek	yes, but i'm saying that it's the differentiators that bring you in, while it's the total package that keeps you here.
16:10:10	Araq	yeah, we'll release 0.20 next week (hahaha), we would have released it this week but this week has 2 holidays
16:10:41	shashlick	ok so let me ask a different question - how long will 1.0 live?
16:11:02	shashlick	doesn't matter when it comes out and what it is based on - how long will it be maintained?
16:11:19	shashlick	0.19.x has been maintained for 8 months now
16:11:23	narimiran	shashlick: i'll force the others to make it live long :)
16:11:50	Araq	shashlick, what do you suggest?
16:12:47	shashlick	i really don't know how to answer that, but will be worth seeing how other languages and frameworks do it
16:13:54	FromDiscord_	<kodkuce> then put 1.0 , as i remmeber linux went to 4.20 then to 5 so anyway its just a number
16:14:09	FromGitter	<alehander42> btw
16:14:49	FromGitter	<alehander42> about the runtimes: how would --newruntime affect javascript backend
16:14:57	Araq	Python 2 was alive for 10 years after 3 came out
16:14:59	FromGitter	<alehander42> code written specifically for it, would it run without problems
16:15:23	FromGitter	<alehander42> python2 is extremely used (and it's still alive!)
16:15:29	FromGitter	<alehander42> i think its a good problem to have
16:15:31	narimiran	...unfortunately :P
16:15:33	FromDiscord_	<kodkuce> in Godot they do like version 3.1 then freez 3months fixing bugs ectera
16:15:34	FromGitter	<alehander42> if nim has a large enough community
16:15:36	disruptek	i don't think python2->3 is a good model at all.
16:15:39	FromGitter	<jrfondren> eh and python 2 has also changed a great deal over of the course of being '2'
16:15:41	shashlick	ubuntu lts releases are 5 years standard support
16:15:42	narimiran	disruptek: yep, it isn't
16:15:43	FromGitter	<alehander42> this means longer maintanance period
16:16:06	Araq	alehander42: we ignore the 'owned' annotations and compile to JS like before
16:16:51	shashlick	second question is what all will be backported - bug fixes only or non-breaking features? i think we had this conversation a while ago
16:16:57	FromGitter	<alehander42> my point is: in a far future, nim might drop the gc, right: but if it targets JS it would need to continue generating gc-compatible code
16:16:59	disruptek	i can't count the number of projects that simply died rather than get ported to python3. in fact, my amazon mws api (with like 90-100 calls) is stagnate in boto2 right now and even amazon isn't merging prs to that codebase. no mws support in boto3, either.
16:17:03	FromGitter	<alehander42> so what is the point in "dropping" it
16:17:37	narimiran	shashlick: 1.0.x bugfixes, 1.y.0 non-breaking features, 2.0 breaking stuff; no?
16:17:52	disruptek	how do you define a "non-breaking feature"? what determines if it's breaking?
16:18:38	FromDiscord_	<kodkuce> does asynchttp implement GET argments parsing or do i have to do that manauly
16:18:45	Araq	"my code doesn't compile anymore" / "my code now crashes at runtime" / "my code now does something different"
16:18:48	FromGitter	<alehander42> changing behavior etc which would break existing code
16:18:55	Araq	^ definition of "breaking".
16:19:20	disruptek	my point is that it's a nice idea, but it's pretty hard to pinpoint, especially when you have things like symbol collisions, etc.
16:19:24	narimiran	btw, look at this: https://i.imgur.com/cuxNBrz.png - if we continue with this tempo - we'll run out of the issues!! what then?? :P :D
16:19:28	FromGitter	<alehander42> kodkuce don't you use jester
16:19:48	FromGitter	<alehander42> nim can start
16:19:57	FromGitter	<alehander42> shipping issues from other projects
16:20:01	FromGitter	<alehander42> and solving them instead
16:20:20	disruptek	unsustainable.
16:20:22	FromGitter	<alehander42> like the plastic ship industry
16:21:15	Araq	anyway, 10 years for Python 2, 5 years for Nim v1, I say.
16:21:42	Araq	but hopefully it's not much effort to backport and we can keep v1 around without much effort
16:22:24	disruptek	five years sounds like an eternity.
16:22:51	shashlick	i felt like 5 years too but am looking at other programming languages to see what they did at 1.0
16:24:16	disruptek	does it matter? you are the ones who have to maintain it, not them, and only you know where you are and where you may be going.
16:24:42	Araq	anyway, devel now has -d:nimv019 for compat with 0.19
16:25:57	Araq	and if new features are put under 'when defined()' we *could* work on devel, not having to maintain 2 different versions.
16:26:16	Araq	but this was discussed before and it's more risky than backporting bugfixes
16:26:30	Araq	the disadvantage is that many bugfixes never get backported
16:26:31	shashlick	yep
16:27:25	shashlick	well, looking at rust, they just keep going, some .1 releases but not for long
16:27:51	shashlick	ruby maintains for a long time and multiple in parallel
16:30:14	shashlick	rust also breaks stuff and it is documented in their release notes
16:30:33	shashlick	0.19.x is better stability than rust offers looks like
16:32:47	shashlick	julia seems to have a 1.0.x and 1.1.x going in parallel, but it's quite young so not much of a metric
16:33:30	Araq	I think we'll simply do both, best of two worlds
16:33:37	narimiran	btw, we should learn from julia's 1.0 mistake
16:33:46	Zevv	which was?
16:33:55	Araq	new stuff is versionized via 'when defined' but we also backport to the v1 branch
16:34:31	narimiran	they had 0.7 which was kind of 1.0rc, which had all deprecated stuff, and then they released 1.0 without those deprecated stuff
16:34:44	narimiran	and suddenly half of the libraries were broken!!!
16:34:48	Zevv	whoa
16:34:52	Araq	that's a feature :-)
16:35:09	narimiran	"yes, we have 1.0 out, but please use 0.7 for some more time until libraries get fixed"
16:35:36	narimiran	we should remove as much deprecations from 0.20, not to repeat the same mistake
16:36:39	narimiran	i already removed some stuff couple of months ago that was still there, which was deprecated in v0.15 or so
16:36:53	Zevv	fair enough, this would be the right time
16:37:05	FromGitter	<mratsim> Julia was broken every 0.x versions
16:37:08	narimiran	and of course that broke some libraries, because everybody just ignores deprecation warnings
16:37:15	FromGitter	<mratsim> changing too fast
16:37:22	narimiran	sounds familiar :P
16:37:53	FromGitter	<mratsim> Well, as long as the "nimble directory structure that will become an error" is not enforced I don't think many lib will break :P
16:38:07	narimiran	haha, yeah, that should be removed
16:38:18	FromDiscord_	<kodkuce> alenhander42 nah i just used asyncdisptch cuz i thinked i dont need more, anyway i can do what i want manualy whitout argument parsing cuz i have only 1 argument to take in so i can do /route?myarg=blabla
16:42:11	shashlick	here's a reasonable middle ground - 2 actively maintained releases - stable with backports, devel, overlap as long as devel doesn't become stable
16:42:33	shashlick	so 1.0 lasts as long as devel isn't ready yet
16:42:48	narimiran	sounds reasonable
16:43:02	shashlick	that's basically 0.19.x and devel model, but will give enough time for Araq to be satisfied with 2.0
16:43:19	shashlick	so if it takes 3 years to make newruntime, so be it
16:43:28	shashlick	gives that much more stability to 1.0
16:44:05	shashlick	but caveat that any stable release will be maintained X years regardless where X can be 2-5 years as decided by the community
16:44:34	narimiran	btw, is this a case of premature optimization? :)
16:45:19	shashlick	i don't think so - the user base needs to be confident that if they pick nim, they won't be forced to move and get a known runway
16:45:50	Zevv	Nim 1.0 LTS
16:46:12	shashlick	and lib writers will also know they need to support stable and not chase devel at the cost of stable
16:46:32	FromDiscord_	<kodkuce> so evry release 1 devs stop working on devel and start working on back-porting for that version, devs need to start multiplying fast, anyone into genetics we need to start cloning devs
16:47:37	narimiran	kodkuce is not that complicated really. at least it wasn't for 0.19 backports.
16:48:30	FromGitter	<jrfondren> you'll get Nim LTS when some big company wants it and pays for it due to government contracts or such. That's how LTS happens. No need to cargo-cult it.
16:48:57	shashlick	2-3 years isn't LTS
16:50:40	FromDiscord_	<DeltaPHC> "rust also breaks stuff and it is documented in their release notes"
16:50:40	FromDiscord_	<DeltaPHC> Just to provide some related insight. Rust uses an 'edition system', and a policy to only backport non-breaking changes. Editions are a way to gate (user opt-in) actual breaking changes, and the compiler is able to handle various editions and also mix and match editions between dependencies. The package file specifies which edition it wants
16:50:41	FromDiscord_	<kodkuce> if its not coplicated then ye sure thats best way to do do 1.0 LTS
16:52:35	FromDiscord_	<DeltaPHC> Their edition system allows packages using, for example, 2015 edition code to depend on 2018 edition code, as long as the compiler is up to date. Avoids the ecosystem split that happened with Python 2-->3
16:53:28	FromGitter	<jrfondren> `{.nim2019.}`
16:53:59	Zevv	so, what languages did these kind of transitions *right* then?
16:54:13	shashlick	sounds like what Araq wanted to do with defined()
16:54:57	elrood	consider that once you release 1.0 with its implicit stability promises and somebody has based a considerably complex piece of software on that, if some feature or breaking change is introduced to the language they don't agree with nim is quite likely to be forked and the community fragmented anyway, elaborate backporting plans and all discussions one could have now nonwithstanding
16:56:32	*	al_ quit (Quit: al_)
16:56:43	*	envoyt joined #nim
16:57:00	*	laaron quit (Remote host closed the connection)
16:57:02	*	rnrwashere joined #nim
16:57:10	shashlick	fact though is that most people don't update their compilers unless they absolutely have to
16:57:24	*	laaron joined #nim
16:57:28	shashlick	that's why i think chasing new features does not resonate with most people
16:57:51	shashlick	even going from 0.19.4 => 0.19.6 will demand a full test effort for a production level app
16:58:19	FromDiscord_	<DeltaPHC> In Rust, `async` and `await` are not reserved keywords in the 2015 edition, so that older code can't use it. However, they had the foresight to reserve those keywords in the 2018 edition, only that the feature has been left unimplemented until fairly recently. So, soon, 2018+ edition code will be able to get that functionality because it isn't a breaking change. 2015 doesn't get it, but their code continues to work
16:59:01	shashlick	what the release cadence and stability commitment show the user base is that nim cares for real world use cases and not just a fun testbed to experiment with cool features
17:01:36	FromDiscord_	<DeltaPHC> People would update their compilers if the process is really easy and their existing code doesn't break
17:02:41	*	rnrwashere quit (Remote host closed the connection)
17:03:41	FromDiscord_	<DeltaPHC> Though, I suppose that guarantee can't be made until 1.0 is nailed down
17:04:27	FromGitter	<jrfondren> it is easy. 0.19.4 => 0.19.6 requiring a full test effort is true by tautology: if you have super high standards, then you'll apply super high standards. In practice it's not a severe upgrade and you can just do it and not worry too much. Nim isn't a scripting language after all, so there's some obvious lag involved in updating your compiler and updating deployed apps.
17:05:15	shashlick	that is an illusion - if i have a million line app, or even something smaller that bears my name, i'm not going to simply trust that my code works the same after changing the basic infrastructure
17:05:30	FromGitter	<jrfondren> in practice with frequent updates the annoyance will be that library authors update their minimum-required version willy-nilly.
17:05:42	FromGitter	<jrfondren> and that's still minor. You can clone the repo and edit it down and continue to use it.
17:07:42	FromGitter	<jrfondren> and, with 0.19.4 => 0.19.6, I'd ask: "do we need any of those changes? no?" and so realistically it'd be a 0.19.4 => 1.2 or such change :p
17:08:06	shashlick	that i agree
17:11:07	FromGitter	<jrfondren> sample size of 1, and it's a small app, but this wasn't painful: https://github.com/dom96/ipsumgenera/pull/35
17:11:26	FromGitter	<jrfondren> nim version "five years ago" -> stable
17:12:01	*	Vladar joined #nim
17:12:08	shashlick	working on my text editor feud - works fine on 0.19.x, doesn't build on devel since libs are broken
17:12:24	shashlick	and even when it did build on devel a couple months ago, there were behavioral changes
17:12:28	shashlick	bugs rather
17:13:20	narimiran	shashlick: which libs are broken on devel?
17:13:28	shashlick	winim
17:13:42	shashlick	https://github.com/khchen/winim/issues/39
17:13:58	*	envoyt quit (Ping timeout: 246 seconds)
17:14:15	narimiran	ok, based on the stuff written there, i think they're working on solving those
17:14:49	shashlick	no doubt it will get fixed, but I cannot simply assume my app will work 100% after upgrading to 0.20 - i will have to test
17:15:34	*	ng0 joined #nim
17:15:38	Zevv	do the 'important' nimble packages get tested against devel and stable?
17:15:58	shashlick	only devel right now, stable doesn't even have megatest
17:16:11	narimiran	btw, for you and others on stable - now would be the best time to test devel to see if something will break in 0.20
17:16:20	Zevv	shashlick: but that'll change as soon as 0.20 is the new stable, right
17:16:29	narimiran	Zevv: just devel, but once 0.20 is out, it can test both 0.20 and devel
17:16:30	shashlick	agreed
17:17:23	Zevv	Maybe this list should be advertised to the users somehow, like a "blessed" choice by the Nim community.
17:17:39	Zevv	I still have this problem that there's too many packages, and I never know which to choose based on nimble output alone
17:17:47	narimiran	Zevv: there are some ideas in that direction
17:17:48	Zevv	but then it's the good/bad/ugly discussion again
17:18:09	shashlick	which reminds me - @narmiran - can we add nimterop to important packages?
17:18:26	Zevv	yes please!
17:19:51	narimiran	shashlick: if nothing happens about that in the next 16 hours (tomorrow morning), please ping me to remind me
17:20:03	shashlick	np
17:20:24	Zevv	(shashlick sets his alarm clock)
17:20:37	narimiran	and if there are other packages that should be included - let me know
17:21:32	*	leorize joined #nim
17:25:56	*	seerix joined #nim
17:27:01	*	envoyt joined #nim
17:30:48	Zevv	narimiran: is `with` in there?
17:30:58	Zevv	I don't use it myself, but it seems to make people happy
17:31:26	narimiran	here's the list: https://github.com/nim-lang/Nim/blob/devel/testament/important_packages.nim
17:31:53	Zevv	ok, request: "with"
17:32:02	*	Vladar quit (Remote host closed the connection)
17:32:13	narimiran	ok, i wrote it down. check back tomorrow morning :)
17:32:28	Zevv	k
17:33:37	Araq	btw 0.20 is done, no more breaking changes, except for --newruntime
17:33:55	Araq	which will get =move
17:34:10	Araq	so you better check now against devel
17:34:37	FromGitter	<alehander42> you should call the article
17:34:52	FromGitter	<alehander42> `0.20: let's =move closer to 1.0`
17:36:22	FromGitter	<jrfondren> subtitle, "not including a kitchen =sink after all"
17:36:44	*	narimiran laughs at both
17:52:08	*	couven92 quit (Ping timeout: 272 seconds)
17:57:26	FromGitter	<rishavs> Paging Vladar!
18:07:09	*	NimBot joined #nim
18:18:21	*	sealmove joined #nim
18:28:22	narimiran	leorize[m]: yaaaaaaaaaay
18:28:31	narimiran	i know what's wrong with your failing test
18:32:35	*	rnrwashere joined #nim
18:34:25	*	rnrwashere quit (Remote host closed the connection)
18:45:54	*	sealmove quit (Quit: WeeChat 2.4)
18:55:35	Araq	http://www.commitstrip.com/en/2018/04/23/they-never-get-anything-right/
19:05:21	WilhelmVonWeiner	say I have a type containing an array. Can you make a pointer in that type which points to index 0 of that array?
19:05:39	WilhelmVonWeiner	or better yet, to a given index
19:06:43	Araq	addr a[i]
19:09:16	*	nsf joined #nim
19:14:53	WilhelmVonWeiner	I get an undefined identfier, I mean inside that same type
19:16:24	*	laaron- joined #nim
19:17:01	*	laaron quit (Quit: ZNC 1.7.1 - https://znc.in)
19:23:14	*	rnrwashere joined #nim
19:24:01	*	rnrwashere quit (Remote host closed the connection)
19:24:07	*	rnrwashere joined #nim
19:30:03	*	vlad1777d quit (Ping timeout: 245 seconds)
19:33:21	*	narimiran quit (Remote host closed the connection)
19:35:58	*	rnrwashere quit (Remote host closed the connection)
19:37:54	FromDiscord_	<nothing to no one> is there a way to have `nimble build` automatically build the project with the javascript backend?
19:38:54	*	kapilp joined #nim
19:40:51	*	rnrwashere joined #nim
19:41:06	*	elrood quit (Remote host closed the connection)
19:42:57	*	krux02 quit (Remote host closed the connection)
19:44:40	Araq	I'm afraid there isn't
19:45:03	*	rnrwashere quit (Ping timeout: 248 seconds)
19:49:08	*	rnrwashere joined #nim
19:49:48	FromDiscord_	<DeltaPHC> WilhelmVonWeiner: This? http://ix.io/1Kq3/nim
19:50:07	*	lritter quit (Ping timeout: 250 seconds)
19:53:44	*	rnrwashere quit (Ping timeout: 272 seconds)
19:54:02	FromDiscord_	<DeltaPHC> Just beware of things that could invalidate that pointer. If you pass around that object by value, the array might change location, or if you decide to have a ptr into a seq, adding/removing from the seq may cause it to reallocate and move around the data
19:55:10	*	leorize quit (Remote host closed the connection)
19:55:39	*	leorize joined #nim
19:57:47	*	andrzejku joined #nim
20:12:27	FromDiscord_	<nothing to no one> Araq: Would you be willing to add a new key to nimble files that allows constraining `nimble build` to a specific backend? I'd love to try and send a PR if you're cool with a feature like that
20:15:52	Araq	go ahead, I would love to have that feature too
20:16:24	*	abm quit (Quit: Leaving)
20:18:37	shashlick	if we had "before build" hook, we could use setCommand
20:18:44	shashlick	can't you use a nim.cfg in the interim?
20:23:06	Araq	nim.cfg doesn't support setting the target either
20:25:49	FromDiscord_	<DeltaPHC> Build hooks/scripts (written in Nim of course) seem like a better long-term solution for making nimble more capable
20:27:29	FromDiscord_	<DeltaPHC> Maybe said script could have access to a build API (an object of some kind) that can tell Nimble various things
20:39:07	FromDiscord_	<nothing to no one> I like the idea of a build object being used for settings
20:40:25	FromDiscord_	<DeltaPHC> Hm. Is the `backend` key not what is desired? https://github.com/nim-lang/nimble#optional
20:40:49	dom96	indeed
20:40:51	Araq	oh! so it already exists, I had no idea :-)
20:41:07	FromDiscord_	<DeltaPHC> lol
20:42:10	FromDiscord_	<nothing to no one> Oh nice! Ty :)
20:44:11	*	andrzejku quit (Remote host closed the connection)
20:44:24	FromGitter	<jrfondren> you might add backend selection to the 'nimble init' prompts.
20:56:09	*	nsf quit (Quit: WeeChat 2.4)
20:59:59	FromGitter	<xmonader> is there any examples on async/await with select?
21:00:21	FromGitter	<jrfondren> the select() syscall?
21:00:26	FromGitter	<xmonader> yea
21:01:27	FromGitter	<jrfondren> https://nim-lang.github.io/Nim/selectors.html is the module to look at.
21:03:11	FromGitter	<xmonader> was looking for more of a shortcut, I don't want to try to glue pieces that eventually might not work from someone's experience.
21:03:17	FromGitter	<jrfondren> why do you care though? I've never liked select() myself, because the fd sets are undocumented, in contrast to poll(). And then epoll() has a bunch of odd features but you can treat it as a strict upgrade from poll(), as epoll() will reorder the array so that you only have to loop over fds that have events.
21:04:15	FromGitter	<jrfondren> https://github.com/nim-lang/Nim/blob/devel/lib/pure/selectors.nim#L322 looks like select is only supported for a few systems
21:05:20	*	rnrwashere joined #nim
21:05:27	FromGitter	<xmonader> I don't really care about select itself, more caring of the behavior. ⏎ ⏎ I've 2 sockets in my application where any of them can have data at any given time and that would trigger flow in handling the other socket ⏎ ⏎ So i can't assume the sequence ... [https://gitter.im/nim-lang/Nim?at=5ceef41682c2dc79a51adffe]
21:06:20	FromGitter	<jrfondren> ok, so your real concern is just using async at all I guess :)
21:06:56	FromGitter	<xmonader> i think that's the advocated way in nim already no?
21:07:45	FromGitter	<jrfondren> at a low level, what you want to do is import asyncdispatch, set up event handlers, and then start the event machine.
21:08:06	FromGitter	<jrfondren> https://nim-lang.github.io/Nim/asyncdispatch.html#addRead%2CAsyncFD%2CCallback for example, will call a proc whenever your socket has data to read.
21:08:58	FromGitter	<xmonader> I think that maybe it :) thank you
21:09:05	FromGitter	<jrfondren> anything you also need to keep track of that doesn't really suit the event machine (i.e., there's no way to get a selector to return with an event for it), you can manage with addTimer.
21:09:47	*	rnrwashere quit (Ping timeout: 248 seconds)
21:18:45	*	sz0 joined #nim
21:25:23	*	rnrwashere joined #nim
21:26:25	*	marcazar quit (Quit: Leaving)
21:28:37	*	rnrwashere quit (Remote host closed the connection)
21:28:52	*	rnrwashere joined #nim
21:30:37	FromDiscord_	<kodkuce> hmm, am using nim -jwt am getting wierd issue i think
21:32:13	FromDiscord_	<kodkuce> eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1NTkyNTEzMzQsImFjdGl2YXRlaWQiOiI0In0.OTk4NzU3QTAxQTk4OTk5MUU3NURDMkJDQjI1Q0UzNENENzY4RDU0M0IzMDRBNzVEQ0E1MDk0Q0ZCQzdBQjA0Nw GOT THIS AS TOKEN, but when i check it on https://jwt.io/ its not working, my is longer i think or i am chking it somhow wrong, for alg i used HS256 in code like on example
21:34:37	*	rnrwashere quit (Remote host closed the connection)
21:35:41	*	rnrwashere joined #nim
21:37:44	FromGitter	<kdheepak> It's been a while since I looked at the nim website, and wow it looks SO NICE!
21:37:59	FromGitter	<kdheepak> The landing page and features page is really good :)
21:38:20	Araq	thanks
21:38:21	FromDiscord_	<kodkuce> https://pastebin.com/qgNuiSGX
21:38:41	Araq	kodkuce: watch out for '$' not doing what you need it to do
21:40:42	FromDiscord_	<kodkuce> hmm i dont think i used $ , only if it does auto for echo atoken
21:41:23	FromDiscord_	<kodkuce> i check will tostring
21:45:07	FromDiscord_	<kodkuce> hmm tryed toString too got same result, is it posible cuz i marked proc gcsafe maybe i scrwed up with gc tought i think that whya would be probbaly some crash type error
21:45:32	Araq	yeah it's unlikely to be GC issue
21:45:48	Araq	and yes 'echo' uses the $ operators
21:46:08	FromDiscord_	<kodkuce> echo atoken.toString()
21:46:59	FromDiscord_	<kodkuce> dident help
21:47:08	FromDiscord_	<kodkuce> anyway i go sleep now
21:47:15	FromDiscord_	<kodkuce> will cry tommorow xD
21:47:23	FromDiscord_	<kodkuce> good night all cya
21:47:37	*	kapilp quit (Quit: Connection closed for inactivity)
21:56:30	*	clyybber quit (Quit: WeeChat 2.4)
22:09:47	deech	Just wanted to check my understanding about macros: it looks the body of the macro gets expanded using the vm which currently implies that it has implicit access to all compile time variables/procs. Is this correct?
22:10:06	deech	s/it looks the/it looks like the/
22:11:01	deech	Also this doesn't seem to be how templates work.
22:14:35	Araq	correct
22:16:14	FromGitter	<jrfondren> you might get your power with your convenience by having a macro expand to a template, as in https://gist.github.com/jrfondren/829889fe6519118a71fb1ce76386e972
22:17:22	FromGitter	<jrfondren> though in that specific example, I think the macro's not worth it.
22:18:48	*	deech quit (Ping timeout: 245 seconds)
22:26:58	Araq	you can use --expandMacro:x to see the expansion of the macros named x
22:27:04	Araq	new on devel
22:27:37	*	deech joined #nim
22:28:13	Araq	btw I'll be offline the next two days
22:28:49	Araq	but I'll be in a train quite some time and there is no better environment to get some coding done...
22:30:17	Zevv	--expandMacro:x is basically a 'echo result.repr', right?
22:30:31	Araq	yes
22:30:36	Zevv	cool
22:30:56	Araq	should have done this earlier
22:31:19	Zevv	oh and it fully expands! My repr always expanded only 1 level still showing template calls, but this goes deeper. sweet
22:31:33	dom96	nice :O
22:31:56	dom96	Now who will write an extension to VS Code to allow me to expand a macro with a button click? :)
22:32:42	*	solitudesf- quit (Ping timeout: 272 seconds)
22:34:58	Araq	it was part of our "life improving Nim enhancements" program
22:35:35	Araq	tables auto-init, tables detect "illegal delete inside iteration", hashing is faster
22:35:40	Araq	error messages are better
22:35:57	Araq	C files can have the same name as the .nim files
22:36:31	Araq	no more "module must be unique inside nimble package" restriction
22:36:31	rayman22201	all of this sounds amazing and beautiful lol
22:37:02	FromGitter	<jrfondren> the error message improvements are great. For example instead of 14 ambiguous $ results you'll get just the two probably-relevant results
22:41:38	rayman22201	FYI, update on Nim godbolt integration: I got syntax highlighting and function name demangling to work, but for some reason it can't always tie the function name to the asm label for that function. I'm not sure why and I've been trying to tweak the godbolt demangler metadata to fix it, but no luck. I also still need to figure out how to get nim into Godbolts crazy docker / shell script spaghetti code for deployment.
22:42:55	*	banc quit (Quit: Bye)
22:43:33	*	apodo quit (Ping timeout: 252 seconds)
22:44:01	rayman22201	I'm going on a trip for a few days also, but unfortunately I'm probably not going to have any time to work on this until I get back.
22:45:34	rayman22201	It's taking me too long, but I will get Nim into Godbolt damnit!
22:46:04	Araq	that's the spririt!
22:46:13	FromGitter	<jrfondren> are there certain function names it consistently can't map to asm labels, or does the mapping sometimes succeed and sometimes fail on the same name?
22:46:37	FromGitter	<jrfondren> godbolt will be super helpful. I'm looking forward to it :)
22:52:49	Araq	I also think about --showasm:foo as a Nim compiler feature
22:53:22	Araq	there is no reason only a freaking website can do it
22:53:22	*	rnrwashere quit (Remote host closed the connection)
22:54:41	FromGitter	<jrfondren> I'd like that as well.
22:55:18	rayman22201	Well, specifically, it has no trouble matching up the return statement (even using the implicit result var) in all cases. Then again that is pretty much some moves followed by a popFrame, so it's pretty easy. But It either can't find the asm function label at all, or it matches the the "initStackBottomWith" function. That is the most confusing case...
22:56:41	rayman22201	It's consistent, once a function gets matched to a certain asm segment (or not matched), it doesn't change, but I don't yet understand why it's matching the way it is.
22:59:58	rayman22201	There is also some caching going on that may affect it. idk. too many layers lol
23:01:50	*	envoyt quit (Ping timeout: 272 seconds)
23:02:11	*	envoyt joined #nim
23:02:16	*	stefanos82 quit (Remote host closed the connection)
23:03:27	rayman22201	If I change the order of the procs in the file, the matches get crossed. It should be using the debug info from "--passC: -g". Another reason that the output is very confusingly broken.
23:04:47	xace	http://ix.io/1HwG # is there a better way to create the corresponding `var openArray[string] matches` for regex?
23:05:38	FromGitter	<jrfondren> `var matches = @[]`
23:06:33	FromGitter	<jrfondren> nah, first off that still needs the type obviously, and also regex doesn't expand the seq for you. So better off not using a seq at all.
23:06:38	xace	jrfondren ?? how will it guess that its a seq[string] ?
23:06:50	FromGitter	<jrfondren> it doesn't. that should be `var matches: seq[string]`
23:07:10	FromGitter	<jrfondren> but regex will just get an IndexError with that, so the array[#, string] option is really the best.
23:07:56	FromGitter	<jrfondren> your segfault was probably from running it with -d:release. No bounds checking with that.
23:08:43	FromGitter	<jrfondren> oh wait, I assumed you were using the regex module.
23:09:00	FromGitter	<jrfondren> if you're using re, you can just let it prepare the matches array for you
23:09:28	xace	how ?
23:11:32	FromGitter	<jrfondren> that's weird. why isn't this matching...
23:11:34	xace	with` =~ `?
23:11:39	FromGitter	<jrfondren> yeah
23:13:39	FromGitter	<jrfondren> I'm getting no output from this though, somehow: https://gist.github.com/jrfondren/c66c29d2333d005342c7b59b8092dde0
23:14:57	xace	same here
23:15:34	FromGitter	<jrfondren> it's finally happened. dementia at my young age. I knew that accepting the Anthrax vaccine was a bad idea.
23:16:41	xace	yeah believe me i feel stupid and i recall i read in the manual that its suppose to work
23:16:55	FromGitter	<jrfondren> `perl -le 'print $1 if "example v22" =~ /v(\d+)$/'` prints 22 though.
23:20:14	xace	ill leave it with the array[1,string] version and ask the same question tomorrow when all the ducks are in the pond
23:22:15	FromGitter	<jrfondren> oh say it isn't so...
23:22:25	FromGitter	<jrfondren> !eval echo "example v22" =~ re"v"
23:22:26	NimBot	Compile failed: in.nim(1, 20) Error: undeclared identifier: '=~'
23:22:35	FromGitter	<jrfondren> !eval import re; echo "example v22" =~ re"v"
23:22:37	NimBot	false
23:22:44	FromGitter	<jrfondren> !eval import re; echo "example v22" =~ re".*v"
23:22:47	NimBot	true
23:23:02	xace	waht?
23:23:09	xace	does it want a full match?
23:23:15	FromGitter	<jrfondren> this is implicitly anchored to the start of the string. I never noticed because literally my only uses of `re` all started with ^ anchors.
23:24:19	FromGitter	<jrfondren> this isn't documented and who even wants this behavior anyway?
23:24:21	xace	i guess i could ^.* but it feels very unnecessarry
23:24:27	rayman22201	want to see something weird. This works: http://ix.io/1Hx4/nim
23:24:27	xace	yeah exactly
23:25:36	xace	yeah, if you ask me the current behaviour isn't desireable...
23:25:44	FromGitter	<jrfondren> that's not weird. that's `find` rather than `match`.
23:26:04	FromGitter	<jrfondren> having `match` work the way it does is acceptable I guess, but `=~` certainly shouldn't use it.
23:27:45	xace	im guessing there is a point to it that im not getting, but after re-reading the manual i see my misunderstanding
23:28:12	rayman22201	oh I see what you are saying. `=~` using match does make sense. Match is an *equality* operator. equality works on the whole string
23:28:47	FromGitter	<jrfondren> anyway, for re.find, the `var matches: array[##, string]` is the best way since seq's flexiblity isn't exploited, and you got a segfault because of -d:release; without that you'd get an IndexError
23:29:25	xace	jrfondren: I get it now. Thank you for exploring this problem with me :)
23:29:28	rayman22201	internally, the re module does it as @jrfondren says.
23:29:44	rayman22201	https://github.com/nim-lang/Nim/blob/devel/lib/impure/re.nim#L25
23:30:01	xace	rayman22201: yeah I guess it makes sense, i guess i got tunnelvisioned when i used find() and missed that `=~` calls "match"
23:30:51	xace	jrfondren: earlier you were surprised that i was using the `re` module, what is the other module you expected? why is it recommended?
23:31:05	FromGitter	<jrfondren> Perl invented =~ and it doesn't have implicit anchoring. PHP AFAIK has implicit anchoring and it also has 200x other match operators like preg_ and crap because it's a horribly designed sack of garbage. Java has implicit anchoring probably out of pure contempt for anyone writing Java.
23:31:56	FromGitter	<jrfondren> what I would expect is a PCRE flag, like the internal ANCHORED, that I'd pass in the cosmically rare case that I wouldn't just put anchors in my own regexes.
23:33:03	rayman22201	lol. I do see your point.
23:36:19	FromGitter	<jrfondren> I can only imagine implicit anchoring as a feature intended for search boxes in UIs, so that you can pass (somewhat trusted) user input to the regex function and not get 'surprising' before like "hell" matching "shell"
23:37:15	FromGitter	<jrfondren> anyway I'll just add it to my list of Nim caveats. At least the Anthrax vaccine hasn't kicked in yet.
23:44:09	*	vlad1777d joined #nim
23:53:07	FromDiscord_	<Really?> Hello!
23:54:20	FromDiscord_	<Really?> For whatever reason, I'm having a bit of trouble with Nim. I am running tests of Nim without Nimble in the source directory (0.9.2), but after I run "bin/nim c koch" get the following error: lib/system/hti.nim(72, 11) Error: undeclared identifier: 'Cstring'
23:55:36	deech	I think I finally got this right! https://github.com/nim-lang/Nim/pull/11341
23:56:09	deech	Next up, adding variants to the VM!
23:57:03	FromDiscord_	<nothing to no one> That should be `cstring`, with a lowercase, right?
23:57:19	FromGitter	<jrfondren> @Really?, in stable nim, identifiers aren't case-insensitive on the first letter anymore, so any `Cstring` has to be `cstring`. Maybe you got hit by some transitional code on that old version.
23:57:53	FromGitter	<jrfondren> eh I wish github linked # issues in subjects like it does in bodies
23:58:01	FromDiscord_	<nothing to no one> oof, 0.9.2 seems pretty old, that's probably the issue
23:59:12	FromGitter	<jrfondren> cool.