<< 18-05-2015 >>

---

00:05:01	*	vikaton quit ()
00:05:42	*	pregressive joined #nim
00:14:20	*	wedowmaker joined #nim
00:21:25	*	johnsoft quit (Ping timeout: 264 seconds)
00:21:49	*	johnsoft joined #nim
00:40:13	*	dtscode joined #nim
00:44:26	*	vikaton joined #nim
00:45:05	vikaton	is the instllation process from github on linux add Nim to my path?
00:45:09	vikaton	will the*
00:45:15	dtscode	No.
00:45:24	dtscode	Not that hard to do manually though
00:50:45	vikaton	dtscode, what would be added?
00:51:01	dtscode	What do you mean what would be added?
00:51:52	vikaton	the commands for the github installation
00:52:17	*	dtscode left #nim ("Leaving")
00:52:30	*	dtscode joined #nim
00:52:43	dtscode	The software you downloaded...
01:02:37	vikaton	dtscode: If I have installed Nim from github, how can I add Nim to my path
01:03:28	dtscode	https://www.google.com/search?site=&source=hp&q=how+to+add+programs+to+path+linux&oq=how+to+add+programs+to+path+linux&gs_l=hp.3..0i22i30l4.1502.20598.0.20798.52.37.8.3.3.0.730.5392.2j23j2j2j6-1.30.0.msedr...0...1c.1.64.hp..16.36.4332.0.tjdkrNWdp88
01:06:13	*	Kingsquee quit (Quit: Konversation terminated!)
01:10:41	dom96_	vikaton: export PATH=$PATH:/path/to/nim/bin/
01:10:47	dom96_	vikaton: inside your .bash_rc
01:10:57	dom96_	or something like that
01:11:22	vikaton	thanks for the ping
01:12:12	*	Kingsquee joined #nim
01:17:09	*	Jehan_ quit (Quit: Leaving)
01:20:31	*	dom96_ quit (Ping timeout: 246 seconds)
01:20:46	vikaton	gcc -c -w -O3 -fno-strict-aliasing -I/root/Nim/lib -o compiler/nimcache/compiler_nim.o compiler/nimcache/compiler_nim.c
01:20:46	vikaton	Error: execution of an external program failed
01:20:46	vikaton	FAILURE
01:20:59	vikaton	er, any help why I have this?
01:21:46	dtscode	Post the command/entire output plz
01:22:14	vikaton	Im doing ./koch boot -d:release
01:22:23	vikaton	so the output is too large
01:22:30	dtscode	No its not
01:23:26	vikaton	https://www.irccloud.com/pastebin/XpscegbD
01:23:29	vikaton	dtscode: ^
01:23:50	dtscode	What gcc do you have also?
01:24:22	vikaton	dtscode: gcc (Debian 4.7.2-5) 4.7.2
01:31:07	ZZZZZZZZZ	use --parallelBuild:1
01:31:15	ZZZZZZZZZ	to be able to get the errors
01:31:40	ZZZZZZZZZ	./koch boot --parallelBuild:1 -d:release
01:31:57	ZZZZZZZZZ	i think it might give you more precise error?
01:34:51	vikaton	https://www.irccloud.com/pastebin/GcgExcks
01:34:59	vikaton	ZZZZZZZZZ: dtscode ^
01:36:16	ZZZZZZZZZ	vikaton: no idea, but what happens if you run manuall gcc -c -w -O3 -fno-strict-aliasing -I/root/Nim/lib -o compiler/nimcache/stdlib_system.o compiler/nimcache/stdlib_system.c
01:36:41	ZZZZZZZZZ	(the line that seem to fail)
01:36:49	vikaton	nothing happened
01:37:08	vikaton	ZZZZZZZZZ: does that mean it worked or?
01:37:26	ZZZZZZZZZ	probably lol
01:37:34	ZZZZZZZZZ	i mean
01:37:37	ZZZZZZZZZ	not the complete build
01:37:58	ZZZZZZZZZ	but if you look at compiler/nimcache/stdlib_system.o it should be there
01:38:05	ZZZZZZZZZ	and before it probably wasnt there
01:39:01	ZZZZZZZZZ	try running it again i guess? i dont know if it will try to rebuild it from scratch or what
01:39:29	ZZZZZZZZZ	probably will keep it cached and it will work..
01:39:38	federico3	dom96: thanks, I found a pdf, albeit outdated
01:41:00	vikaton	lemme see
01:41:21	vikaton	still fails :(
01:41:27	ZZZZZZZZZ	with the same line?
01:41:41	ZZZZZZZZZ	on nimcache stdlib_system
01:45:45	*	darkf joined #nim
01:56:49	vikaton	yeah ZZZZZZZZZ
01:57:08	ZZZZZZZZZ	i give up!
01:57:12	ZZZZZZZZZ	lol
02:00:59	Varriount	ZZZZZZZZZ: What's going on?
02:01:22	vikaton	Ill try tomrrow I gues
02:01:27	ZZZZZZZZZ	o i meant i give up on helping vikaton
02:01:34	ZZZZZZZZZ	Varriout: ^
02:01:35	Varriount	vikaton: What's wrong?
02:02:01	vikaton	'Varriount My Nim installation from github wouldt work
02:02:06	vikaton	https://www.irccloud.com/pastebin/GcgExcks
02:02:13	Varriount	vikaton: Are you booting using a csource binary?
02:02:43	vikaton	im not sure
02:03:22	Varriount	vikaton: Try downloading and compiling this: https://github.com/nim-lang/csources
02:03:54	Varriount	Then use that to boot a Nim comprised of code from the *devel* branch.
02:04:07	vikaton	hmm
02:05:03	Varriount	If you're trying to boot master, use the 'master' branch from the csources repo
02:05:25	Varriount	(and the 'master' branch from the Nim repo)
02:15:56	federico3	I suggest asciidoc as a format for documentation
02:19:06	Varriount	federico3: Your suggestion is a bit late, unless you want to write an asciidoc backend for nimdoc.
02:19:43	federico3	Nimdoc or koch?
02:20:15	Varriount	koch invokes nimdoc
02:28:31	federico3	Tnx, I'm looking at its docs. Implementing asciidoc input and also output might be doable
02:30:12	Varriount	vikaton: Ping
02:30:34	vikaton	Varriount: pong
02:31:04	Varriount	vikaton: Were you able to resolve your problem?
02:31:16	vikaton	Not yet, I will tomorrow :P
02:45:12	vikaton	is Nim planning on compiling directly to LLVM >
02:45:13	vikaton	?
02:48:25	*	BitPuffin|osx quit (Ping timeout: 255 seconds)
02:50:43	Varriount	vikaton: Not likely.
02:51:13	*	fowl quit (Excess Flood)
02:51:20	Varriount	Or rather, there's nothing stopping others from working on a backend, but there's no plan for one either.
02:51:44	*	notfowl joined #nim
02:51:44	*	notfowl quit (Excess Flood)
02:52:12	vikaton	I see
02:52:44	*	notfowl joined #nim
02:53:27	Varriount	notfowl: Stop not being here :<
02:55:44	notfowl	do you need me
02:57:02	vikaton	so let me get this straight
02:57:08	vikaton	Nim outputs C
02:57:14	vikaton	but does not compile to it?
02:59:00	notfowl	vikaton: those are the sam
02:59:16	vikaton	mh
02:59:25	notfowl	Nim is not a c compiler
02:59:56	vikaton	Yes I know that
03:01:51	notfowl	I don't understand your question
03:04:38	vikaton	I think I recall someone saying
03:05:06	vikaton	"Nim doesn't compile down to C, it outputs it which is then compiled by gcc"
03:13:21	notfowl	Well it also invokes the c compiler. I would call it a series of data transformations starting at Nim syntax and ending with an executable
03:14:54	*	superfunc joined #nim
03:32:07	*	superfunc quit (Ping timeout: 246 seconds)
03:33:31	*	Perelandric quit (Ping timeout: 246 seconds)
03:37:55	*	dtscode quit (Ping timeout: 255 seconds)
03:44:13	*	dhasenan quit (Remote host closed the connection)
04:12:16	*	johnsoft quit (Ping timeout: 258 seconds)
04:13:08	*	johnsoft joined #nim
04:19:58	*	gamesbrainiac joined #nim
04:24:25	*	Sornaensis quit (Ping timeout: 264 seconds)
04:25:49	*	intra quit (Ping timeout: 256 seconds)
04:26:29	*	Sornaensis joined #nim
04:40:49	reactormonk	vikaton, it's a transcompiler. I would say nim compiles to C.
04:47:00	*	transfuturist quit (Quit: Lost terminal)
05:03:53	*	dhasenan joined #nim
05:07:59	*	pregressive quit (Remote host closed the connection)
05:08:31	*	pregressive joined #nim
05:13:13	*	pregressive quit (Ping timeout: 258 seconds)
05:21:53	*	jbomo quit ()
05:33:40	*	gamesbrainiac left #nim ("Bye folks!")
05:38:55	*	endragor joined #nim
05:40:47	*	intra joined #nim
05:48:52	*	elbow_jason joined #nim
06:13:54	*	NimBot joined #nim
06:43:11	*	yglukhov_____ joined #nim
06:43:13	*	yglukhov_____ quit (Remote host closed the connection)
06:43:48	*	yglukhov_____ joined #nim
06:59:20	*	BlaXpirit joined #nim
07:04:13	*	dddddd joined #nim
07:05:38	*	endragor_ joined #nim
07:09:35	*	endragor quit (Ping timeout: 256 seconds)
07:11:17	*	intra quit (Ping timeout: 258 seconds)
07:17:32	*	Ven joined #nim
07:19:34	*	endragor_ quit (Remote host closed the connection)
07:19:55	*	Ven quit (Client Quit)
07:23:18	*	Ven joined #nim
07:24:33	*	bjz joined #nim
07:28:53	*	pregressive joined #nim
07:29:20	*	bjz quit (Client Quit)
07:32:01	*	ingsoc joined #nim
07:33:23	*	pregressive quit (Ping timeout: 256 seconds)
07:38:58	*	borisv joined #nim
07:39:28	*	d3m1gd quit (Ping timeout: 244 seconds)
07:40:15	borisv	Hello again... on the topic of declaring arrays: if I understand correctly, there is currently no way to declare an array and initialize every element with a value _different_ from the default value for the type, is that so?
07:40:46	BlaXpirit	borisv, u can definitely do that with seq
07:44:52	borisv	BlaXpirit: are we talking about arrays, as in `var a = array[0..5, int]`? How would I write this?
07:48:03	borisv	I don't know if it is bad form to give examples from the standard libraries of other languages, but how could I say the equivalent of `std::vector<int> a(6, 3);` (C++: an array of 6 integers with initial value 3)
07:51:07	borisv	My question is a follow-up of a closed issue on github (#2462). It was closed after merging pull request #2701, but this pull request only provided an implementation for a `fill`, which fills an array after declaring it. Obviously, one would often want to be able to fill the array as it is declared, hence my question.
07:51:54	*	d3m1gd joined #nim
07:53:54	BlaXpirit	welp, i don't see anything
08:11:13	*	endragor joined #nim
08:12:24	*	Trustable joined #nim
08:14:48	*	OnO joined #nim
08:14:51	notfowl	We have a newseq like that
08:15:06	BlaXpirit	that's what i thought
08:15:07	notfowl	Vector is closer to seq that array
08:15:41	BlaXpirit	except i can't find it
08:15:46	*	coffeepot joined #nim
08:15:54	borisv	BlaXpirit: http://nim-lang.org/docs/sequtils.html
08:16:28	borisv	and http://nim-lang.org/docs/system.html#newSeq,seq[T],Natural
08:16:38	notfowl	Called newseqwith
08:16:53	BlaXpirit	and where is it?
08:17:11	BlaXpirit	ah template :|
08:18:41	borisv	notfowl: so, what I am looking for is simply `var a = newSeqWith(6, 3.int)`?
08:19:50	notfowl	If you want something like an std::vector instead of an array yes
08:20:40	borisv	and now `a` is a _sequence_, ie it is dynamic and lives on the heap etc
08:21:27	notfowl	borisv: see on the doc the link it says view source or something. Check it out. Its not black magic
08:21:54	notfowl	Seq is on the heap yes
08:22:00	notfowl	Resizable
08:23:22	borisv	notfowl: no, not black magic. just trying to figure out what is the "idiomatic" way to do things in nim. It is never easy to get started with a new language, particularly because of the weird ways that names are used in subtly different ways
08:24:29	borisv	the `vector` in STL should have been called an `array`, and now it seems that nim's `sequence` is the C++ `vector` is the `array` which is not just a chunk of memory....
08:27:38	*	filwit quit (Ping timeout: 256 seconds)
08:29:37	BlaXpirit	borisv, note that there is an `array` in C++ standard library
08:30:01	BlaXpirit	and indeed seq is like C++ vector
08:32:35	borisv	BlaXpirit: it took me a while to digest this, but now I get it
08:32:56	notfowl	It has similar semantics
08:33:23	notfowl	Unless its marked shallow, assignment does a copy
08:33:41	*	OnO quit (Quit: Textual IRC Client: www.textualapp.com)
08:34:55	*	pipeep quit (Ping timeout: 248 seconds)
08:34:57	*	elbow_jason quit (Ping timeout: 240 seconds)
08:37:25	borisv	notfowl: yes, I did try it. For both `array` and `sequence` assignment makes a copy.
08:38:03	*	pipeep joined #nim
08:39:56	*	n1ftyn8 quit (Ping timeout: 276 seconds)
08:41:18	*	n1ftyn8 joined #nim
08:42:32	*	CARAM__ quit (Ping timeout: 276 seconds)
08:44:29	*	mikolalysenko quit (Ping timeout: 276 seconds)
08:45:19	*	CARAM__ joined #nim
08:46:16	*	mikolalysenko joined #nim
08:47:45	*	TylerE quit (Ping timeout: 276 seconds)
08:48:06	*	TylerE joined #nim
08:48:14	*	borisv quit (Quit: Leaving)
08:50:55	*	Demon_Fox quit (Quit: Leaving)
08:57:38	*	endragor quit (Read error: Connection reset by peer)
08:58:08	*	endragor joined #nim
09:01:27	*	yglukhov______ joined #nim
09:03:37	*	yglukhov_______ joined #nim
09:03:37	*	yglukhov______ quit (Read error: Connection reset by peer)
09:05:14	*	yglukhov_____ quit (Ping timeout: 264 seconds)
09:20:53	*	Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:35:14	*	Kingsquee quit (Quit: Konversation terminated!)
09:37:08	*	yglukhov________ joined #nim
09:37:08	*	yglukhov_______ quit (Read error: Connection reset by peer)
09:37:23	*	yglukhov________ quit (Remote host closed the connection)
09:37:56	*	yglukhov________ joined #nim
09:44:31	*	Kingsquee joined #nim
09:57:18	*	BlaXpirit quit (Quit: Quit Konversation)
10:05:41	Araq	reactormonk: ffs there is no such thing as a "transcompiler" or "transpiler". It's called a "compiler".
10:08:15	Araq	you can say that a source-to-source-translator is not a compiler as the output is meant for human consumption then, but that's not what Nim aims for. It is a compiler.
10:14:07	*	OnO joined #nim
10:14:36	Araq	OnO: noSideEffect is not designed to map onto GCC's pure
10:14:47	OnO	hi
10:15:15	OnO	sure, that's why I wonder if you should bring some extra pragma for that
10:15:28	OnO	like cPure or sthing
10:15:29	Araq	and the point of the effect system is safety/security, not efficiency. these things are rather easy compute in an optimizer anyway
10:16:35	OnO	but I hope you understand my concerns, that we need to have a means to issue GCC ((pure)), otherwise optimizer will not be able to remove calls to foreign API
10:16:44	Araq	though it's true that common compilers are stupid in this respect, looked at visual c++ recently, it's really bad at it
10:17:56	OnO	yeah, GCC is not good either, if you bring any pointer then ((pure)) is no longer effective, eg. if using non-inline Nim iterator
10:18:11	Araq	OnO: Nim should remove these calls, not GCC
10:19:04	OnO	honestly I don't see how, because it would need to trace inline calls too
10:19:35	Araq	this should be done with a TR macro
10:20:23	Araq	but again, how do you gather the fields?
10:20:46	OnO	well... imagine this: for user in User.where(...): if logged(user): echo user.name & " is logged"
10:20:51	OnO	logged is user defined proc
10:21:19	OnO	where is my macro, but the stmt containst logged() call, I cannot trace what happens there
10:21:22	OnO	not at this point
10:21:32	OnO	Araq: I gather fields just reading object record
10:21:37	OnO	right now
10:22:10	Araq	so somewhere I have to do type User = object id, name, pass: string ?
10:22:35	OnO	no.. that's the whole point you don't need to
10:22:56	Araq	hrm? so how does it work?
10:23:00	OnO	I just want to bring "old well known" ORM into Nim, as in ActiveRecord for example
10:23:10	OnO	currently it gets ALL fields of the model
10:23:14	Araq	I never used ActiveRecord
10:23:51	OnO	but I want to infer that from the user's code, so only fields that are used should be loaded
10:24:10	OnO	as long user calls only other inline procs it is possible in theory
10:24:19	OnO	https://github.com/nanoant/nim-orm/blob/master/orm.nim
10:24:21	Araq	so how does it get ALL fields?
10:24:46	OnO	recList = T.typeNode[1].getType[1]; for node in children(recList): result.add("`" & node.repr & "`")
10:27:24	Araq	ok, so via getType, that does mean I need to have 'type User = ...' somewhere in my code
10:28:59	Araq	and I also need to inherit from 'Model' for this, yikes
10:31:18	Araq	in LinqToSQL I tell the IDE where to find the database and then I can drag and drop what to import into C#, so these classes are all generated. Now that sucks for different reasons, but I still think we should generate these types from the DB at compile-time
10:31:19	OnO	yes, your model type has to inherit from model
10:31:39	OnO	you don't need to declare anything because "user" if passed from iterator: for user in User.where(...):
10:32:18	Araq	where does User with capital U come from though?
10:32:25	OnO	Araq: it is supposed to work other way around, you define your DB model only in Nim code, there is absolutely no SQL in your code
10:32:49	OnO	ORM should set up you tables and everything using your model class definition
10:32:56	*	TEttinger joined #nim
10:32:58	Araq	aha, ok, so you avoid the problem of having 2 definitions by generating the SQL
10:32:59	*	Ven joined #nim
10:33:05	OnO	of course
10:33:09	Araq	meh ;-)
10:33:19	OnO	one code to rule them all ;)
10:33:36	Araq	that's why people say ActiveRecord is not good when you already have existing DBs
10:33:49	OnO	sure, I don't care about that
10:34:02	Araq	but I do :-)
10:34:08	OnO	I want to make Nim high level general purpose solution
10:34:32	OnO	Async HTTP, HTTP builder + ORM will be killer to Ruby Rails ;)
10:34:55	Araq	but we don't need to kill Rails. It's already dead :P
10:35:24	strcmp1	you could dig its grave
10:35:25	OnO	believe me its not, I am working with some new project and they still use Rails to make new webapps
10:35:42	OnO	what are the alternatives anyway
10:35:42	OnO	?
10:35:57	Araq	Node.js, dunno
10:36:21	strcmp1	there's a lot of alternatives, even inside ruby itself
10:36:25	OnO	well, it serves bit different purpose, node.js tries to bring similar webframeworks, but I think Rails is still most used one
10:36:48	OnO	strcmp1: indeed, but all of them follow the same ORM paradigm
10:37:17	OnO	I don't think Rails was the first to ORM, but it did indeed make it kind of standard
10:37:28	Araq	well linqToSql works differently and is used too
10:37:33	OnO	before you were coding all this shitty SQL resulting in spaghetti code
10:37:37	vikaton	Rails isnt dead :P
10:37:39	vikaton	yet
10:37:52	vikaton	still #1 Framework
10:38:23	strcmp1	rails puts too much focus on productivity/convenience, and not enough on performance, that's where it will fall down imo
10:38:26	OnO	Araq: honestly lingToSql isn't conceptually different from ORM solutions
10:38:36	Araq	but it is.
10:38:39	vikaton	Use Lotusrb
10:38:46	vikaton	Its like Rails but MUCH faster
10:38:47	Araq	we just figured out how it's different
10:38:51	vikaton	http://lotusrb.org
10:39:10	strcmp1	yeah, im familiar with it, it feels a little wrong to discuss such things in #nim :p
10:39:55	vikaton	Araq, have you ever told github to rename Nim?
10:40:43	OnO	Araq: anyways, going back to the subject :P any ideas how to optimize DB to model loads ? I was also thinkging about something like: Field<Type> to do lazy load, but I think it is mess
10:40:58	OnO	and it is nothing better than in other languages
10:41:04	OnO	the trick is to do it at compile time
10:41:12	OnO	not at runtime
10:41:21	Araq	OnO: well I told you how to do it better than in other languages, but you disagree
10:41:25	coffeepot	can we annotate object fields to tag them as db fields?
10:41:34	Araq	the thing is:
10:41:59	OnO	Araq: if you tell me how I can trace dot access in statement passed to macro :)
10:42:15	OnO	including dot access in called inline procs ..
10:42:21	Araq	type Foo = object id {.primaryKey.}: int etc. is nice but ultimately toyish
10:42:31	Araq	coffeepot: yes we can but read on
10:42:35	coffeepot	:)
10:42:56	Araq	you end up reinventing LOTs of annoations in Nim that SQL already provides
10:43:08	Araq	like indexes etc
10:43:16	Araq	or even character set settings
10:43:36	Araq	and at the end of the day most companies *already* have a database model
10:43:51	Araq	so it should be generated from the existing model
10:44:16	coffeepot	"reinventing SQL" i've been there :( completely agree. ORM is a tricky beast to design more than code
10:45:37	OnO	Araq: I don't care, I want a tool for new projects, not for adapting existing databases
10:46:04	Araq	yes but then you use the database as some dumb datastore
10:46:25	Araq	many prefer to use the database as a database
10:46:37	coffeepot	I prefer ORM from a DB to code direction myself, purely because a) when I end up using ORM I already have a DB. This makes it more complex though because sometimes DBs are a mess and b) whilst it makes it simpler and removes some edge cases you're constraining the DB by the ORM. Sorry not providing a soluting, just thoughts :D
10:46:46	OnO	nope, I just want to replace SQL with the native language
10:46:53	OnO	this is proven to work in many projects
10:47:05	OnO	that was the reason of Rails success
10:47:23	OnO	with Nim I believe we can do it better, at least more performance-wise
10:47:39	Araq	don't give me these meta-reasons please.
10:48:16	coffeepot	why can't we have both?
10:48:30	OnO	why to refuse them? this isn't a hype, ORM has proven to be just effective
10:48:41	coffeepot	create DB from object template, and maybe access db via dictionaries of field metadata or something
10:49:03	Araq	OnO: and yet here you are and want to improve upon them.
10:49:46	OnO	Araq: I've already worked in Rails camp couple years ago, also using other solutions like Sinatra, etc. etc.
10:50:10	OnO	there's nothing to improve there because they already work great
10:50:35	OnO	yet the rely on the languages that are not so much optimizable as Nim is
10:50:54	Araq	they don't work well for lots of use cases. Like when you already have a database and data.
10:50:58	OnO	with Nim you can reach bare metal, with Python or Ruby hardly
10:51:18	Araq	it's not about ORM vs no-ORM here
10:51:30	Araq	it's about whether to read in an existing model
10:51:46	Araq	or to generate the model from Nim code
10:51:59	OnO	I don't refuse to see that there are existing solutions and existing databases, and some devs that will prefer to work with SQL
10:52:39	Araq	well back to the point: I want to read the model from the database, you don't. ok, too bad, but it's you who's doing the work.
10:52:42	OnO	if they will migrate from other ORM solutions then they definitely will NOT generate model out of SQL that was generated out of their other-language-model
10:54:00	OnO	Araq: this is somehow side-subject, if you want to do it your way - model out of existing DB, then you will still need to know which fields to read, which to skip
10:54:03	coffeepot	is it not possible to be able to build a model in code to create/access the DB, but also be able to read in metadata to build the model too?
10:54:35	OnO	my interest is to limit data read from DB only to this actually referenced in the code itself
10:54:52	OnO	it doesn't matter where the model came from
10:55:43	OnO	even it does not matter if we use objects or just dictionaries
10:56:42	Araq	coffeepot: sure that would be the ultimate solution, but that seems rather unrealistic at this point
10:57:38	OnO	I don't see any problem to create a tool that will migrate existing SQL database to ORM solution
10:58:44	Araq	"migration" is the keyword here. you don't want that. DB migration is a pain in the ass and not always possible.
10:58:55	coffeepot	Araq yes, fair enough. OnO What would actually need to change to 'migrate to an orm solution'?
10:59:03	Araq	but ok, back to the original problem
10:59:47	Araq	so ... I have a User object but that's complete (because the model is generated from it ;-) ) and so lots of redundant stuff is read from the DB
10:59:47	OnO	coffeepot: reason is to keep all to application logic and model in same place and same language
11:00:01	OnO	Araq: yes
11:01:38	Araq	so one easy way is to make people use another UserTemp object with just the fields that are required
11:02:35	Araq	but that's not convenient of course
11:05:50	*	notfowl quit (Excess Flood)
11:06:44	*	notfowl joined #nim
11:07:28	Araq	OnO: in general, if you need more overview, you need to do
11:07:31	Araq	orm:
11:07:40	Araq	for u in User.select(...):
11:07:50	Araq	if u.name == "abc": ...
11:09:12	Araq	this way you can also transform the 'if' into a 'where' clause and merge it with the select
11:09:32	Araq	but it's harder to implement, of course
11:10:33	OnO	nice idea
11:11:19	OnO	for u in User: if u ....: ...work.. instead of for u in User.where(...): ...work..
11:30:56	Araq	alternatively you can leave it as it is and make the 'orm' block perform the optimization on a typed AST
11:31:32	Araq	and warn or error if you pass the full 'u' around: Warning 'u' escapes analysis, leading to inefficient code.
11:32:23	Araq	I think that's how I'd do it.
11:32:47	OnO	I understand, I'll try to do it this way then
11:33:20	OnO	also I will add some API to specify fields to be fetched explicitly
11:33:43	OnO	Araq: but I've question, any way to force inlining some procs at Nim level, not C level?
11:34:03	Araq	template does that
11:34:08	OnO	yeah.. ok
11:34:10	OnO	good point
11:34:16	Araq	but with slightly different semantics ofc
11:34:30	OnO	a warning: u escaped analysis, consider using templates
11:34:33	OnO	good
11:34:56	OnO	"u escaped analysis, consider using templates or manually specify fetched fields"
11:35:16	Araq	yeah that's cool
11:37:03	*	dddddd quit (Ping timeout: 256 seconds)
11:38:27	*	OnO quit (Quit: My iMac has gone to sleep. ZZZzzz…)
11:38:35	Araq	there is another builtin planned, 'getImpl' to inspect the AST of passed procs/iterators/consts etc
11:38:59	Araq	you could use that to inspect the AST of inline procs
11:39:11	Araq	but it doesn't exist yet ;-)
11:57:09	*	pregressive joined #nim
11:57:30	*	Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:00:58	*	Ven joined #nim
12:14:05	*	boopisaway is now known as boop
12:14:46	*	bluenote_ joined #nim
12:23:49	*	Kingsquee quit (Quit: Konversation terminated!)
12:34:40	boop	i'm not convinced that TSECURITY_ATTRIBUTES works on createPipe()
12:35:15	boop	windows.h has the signature as a ptr LPSECURITY_ATTRIBUTES but winlean doesn't
12:36:50	boop	or er, LPSECURITY_ATTRIBUTES is a ptr SECURITY_ATTRIBUTES, which is what winlean's TSECURITY_ATTRIBUTES is
12:39:14	*	d3m1gd left #nim ("WeeChat 1.1.1")
12:46:05	ingsoc	are there plans for a multicore aware concurrency feature like Go's goroutines ?
12:47:03	Araq	why plans? 'spawn' already exists
12:48:02	emilsp	ingsoc, doesn't the beauty of Go's concurrency stem from the 'channels' ? goroutines are basically static functions, right ?
12:48:16	ingsoc	ok yess
12:48:18	ingsoc	channels
12:49:14	ingsoc	ok, a mechanism for lightweight independently running synchronous threads of execution that can automatically utilise multiple cores
12:49:38	emilsp	that requires a runtime, though
12:49:59	*	darkf quit (Read error: Connection reset by peer)
12:50:13	ingsoc	there has been a library for scala/java called akka
12:50:19	ingsoc	that kind of does soem,thing similar
12:50:22	ingsoc	something
12:50:35	*	darkf joined #nim
12:58:51	*	NimBot joined #nim
13:01:08	ingsoc	emilsp: btw goroutines are the fundamental unit of concurrency. channels are a mechanism for communication between them.
13:05:01	emilsp	ingsoc, okay.
13:05:08	*	wilinando joined #nim
13:05:20	*	wilinando quit (Client Quit)
13:05:30	emilsp	ingsoc, I hate living in interesting times, I don't have nearly enough time to get my head around half of what I want to look into
13:05:53	ingsoc	emilsp: I totally sympathise there
13:06:06	ingsoc	client side web dev is even worse
13:06:10	ingsoc	atm
13:07:50	*	yglukhov________ quit (Ping timeout: 272 seconds)
13:08:22	*	Aszarsha joined #nim
13:08:25	Araq	ingsoc: so how many cores does your CPU have?
13:08:40	ingsoc	8 hw threads
13:09:02	ingsoc	thats a 3 years old laptop
13:10:17	ingsoc	in my opinion looks more interesting and immediately useful than go or rust etc.
13:10:23	Araq	and how many does your GPU have?
13:10:25	ingsoc	Nim looks*
13:10:54	ingsoc	there are a case of problems like network servers where the goroutine abstraction or erlang process can prove to be very useful
13:11:41	ingsoc	especially with the ability to utilise all cores pretty easily without major code changes or introducing possible major bugs
13:11:59	ingsoc	that is the only point i am making and was just curious that was all
13:12:07	ingsoc	i have no idea what all you guys are using nim for
13:12:28	ingsoc	but to be able to write something like nginx in nim with comparable performance
13:13:07	ingsoc	with much more concise code etc. seems interesting
13:13:31	*	yglukhov________ joined #nim
13:14:03	Araq	yeah ofc but IMHO it's much more interesting to look at how we can harness the power of GPUs
13:14:06	emilsp	ingsoc, you have to make sure that every thread is 'safe', which is easy to achieve in erlang, but nim gives you freedom
13:15:05	emilsp	Araq, for serverside web 'applications' the gpu sits too far away from sockets to be useful, most of the time would be spent on moving data back and forth to/from the gpu
13:15:25	ingsoc	Araq: are GPU's suitable for general purpose parallelism of or is it suited to only certain computational code ?, i have never coded for GPU's
13:15:25	Araq	emilsp: there are setups to avoid this
13:15:43	coffeepot	Araq. are you thinking of some kind of CUDA library for Nim, or just generally utilities to harness the parallelisation of GPUs for general work behind the scenes?
13:15:53	coffeepot	either way, damn awesome
13:16:55	emilsp	Araq, yes, but even then, it's a SIMD arch, where the paralelism is 'synchronous' to an extent, whilst most web backends are very asynchronous in nature.
13:17:29	emilsp	and still, most web applications are bottlenecked by IO, not compute perf
13:17:58	Araq	which means it's rather pointless to have them run on more than 1 core ... ;-)
13:18:08	coffeepot	I'm doing a physics module atm for my own projects, but i was considering down the line of using OpenCL for this internally. It'd be amazing if there were a generalised way in Nim of accessing the GPU
13:18:35	ingsoc	Araq: Not true
13:18:59	Araq	ingsoc: why not?
13:19:55	*	Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:20:05	emilsp	Araq, no, the idea is that multiple threads do multiple things, one for accepting connections, one for dealing with the database, and then some small computation and returing data to the socket
13:20:23	emilsp	so, with go, you get thread pools for each operation
13:20:48	ingsoc	Araq: I will give erlang as the example as it gets concurrency correct but is not compiled to machine code and so is an order of magnitude slower in exectuion (at least) to native c, althoguh apparently there is a JIT in the works which could improve this situation somewhat. Anyway, regarding concurrency
13:20:59	def-	coffeepot: I guess that's the plan: https://github.com/Araq/Nim/wiki/GSoC-2015-Ideas#add-a-code-generator-for-opencl
13:21:00	emilsp	so you don't block where you don't need to block
13:21:20	ingsoc	when erlang VM starts it queries the system for the number of cores/hw threads in the machine
13:21:21	boop	...
13:21:23	boop	it wooorks
13:21:23	emilsp	def-, opencl is so old school, vulkan/spirv is where it's at
13:21:26	Araq	emilsp: I don't need explanations of how Go works. Thanks.
13:21:27	ingsoc	it then starts a OS thread for each core
13:22:02	emilsp	Araq, sorry for showing disrespect, no offence was intended
13:22:28	Araq	the question was: When you're IO bound, why pretend you're CPU bound?
13:22:28	ingsoc	Araq: should i refrain from an erlang one too >?
13:22:32	ingsoc	:D
13:22:43	ingsoc	ui haven't finished yet
13:23:31	*	vikaton quit (Quit: Connection closed for inactivity)
13:24:02	coffeepot	def- wow... that would be absolutely incredible. So we could write shaders directly in Nim, too! Kind of a game changer from both gamedev and scientific computing. Wish I was knowledgable enough to help with that.
13:24:25	LoneTech	Araq: the main reason I can think of is to use the same code techniques to deal with concurrency and asynchronous behaviour
13:24:32	ingsoc	there are benefits of the process/goroutine abstraction for non CPU bound problems (e.g. IO) as well
13:24:39	Araq	emilsp: def- optimized our HTTP server by getting rid of some 'await'. In other words, introducing *more* blocking.
13:24:41	ingsoc	things like nodejs use callbacks everywhere
13:24:52	ingsoc	i see has the await (borroed from c#)
13:24:59	ingsoc	which is an improvement
13:25:06	emilsp	Araq, have you load tested it ?
13:25:16	ingsoc	i see Nim has await i meant
13:27:19	def-	emilsp: the tests were documented here: https://github.com/def-/nim-http-speedup
13:28:26	dom96	Araq: Surely if it was just IO bound then throwing extra threads at it would not increase the requests per second.
13:29:04	ekarlso	def-: is ^ async or ?
13:29:24	def-	ekarlso: i don't understand the question
13:29:35	ekarlso	the perf tests, async http server or ?
13:29:37	Araq	dom96: the benchmarks are not IO bound afaict. The requests come from the same machine.
13:29:46	def-	ekarlso: mostly yes, also includes some other stuff
13:30:13	emilsp	dom96, the idea is to seperate requests, so blocking requests never hinder nonblocking requests, which is already implemented, afaik
13:30:14	dom96	Araq: does that mean that the benchmark is incorrect?
13:30:40	Araq	no, it's not. it has nothing to do with reality though.
13:31:32	Araq	the test shows that with > 100K req/s it's getting CPU bound. perhaps. I dunno really.
13:31:41	*	banisterfiend quit (Read error: Connection reset by peer)
13:33:26	dom96	Well, i'm confused, because benchmarking it on my laptop puts it above Golang.
13:33:47	Araq	lol I don't care about the results
13:34:19	dom96	Perhaps I should create a Digital Ocean VPS to benchmark things properly.
13:35:02	*	BitPuffin|osx joined #nim
13:35:52	Araq	IME nobody has problems that are reflected by these benchmarks.
13:36:36	Araq	you might as well benchmark your CPU by making it run 1 million add opcodes with no other instructions in between
13:39:09	coffeepot	I'm surprised the web framework benchmarks aren't built around serving a standardised test blog tbh, was quite surprised at the fuss of people ranking how many empty requests a framework can do, though I guess it shows how fast it can do the minimum work
13:43:47	Araq	"Removed from OpenCL C++ are features like allocation and releasing of memory, virtual functions, abstract virtual classes, function pointers, goto, and other changes that don't work too well in a parallel computing environment".
13:45:35	boop	dom96: poke? have async piping working on windows for osproc, but it needs to be specified before the process is started
13:45:47	boop	any preferences for how it should be structured?
13:51:03	ingsoc	a parallel version of asyncnet (one using http://nim-lang.org/docs/asyncdispatch.html) would be interesting if this is possible to see what overhead there is to using that module as it gets rid of the majority of boilderplate code dealing with socket polling and callback management, also why is it stated that it is "(broken anyway)" in the results
13:51:32	ingsoc	def-: ^
13:51:41	ingsoc	but yea it isn;t really a real world test
13:52:17	ingsoc	if you then call a DB driver to query a DB during a call and that API is synchronous (blocking) then you have stalled the server no ?
13:52:41	ingsoc	until DB responds and no other web requests will be responded to until that time
13:52:53	Araq	right, that's why you need to spawn the DB call
13:53:03	ingsoc	so a db server thread pool
13:53:18	ingsoc	and then pass them and match them up to the calling socket client on response from db
13:53:41	ingsoc	ok
13:54:19	emilsp	ingsoc, this problem is usually solved by a framework, not a standard library
13:54:21	ingsoc	i think there is a non-blocking option as well in the postgresql db driver
13:54:29	ingsoc	possibly, i dunno
13:54:38	dom96	boop: hrm, dunno. Just do it whatever you think is best and let us review it.
13:54:38	ingsoc	yeah true
13:55:37	ingsoc	so what the hell is jester doing ? is this not even using async io ?
13:56:17	ingsoc	just req/resp, serving each connection sequentially ?
13:56:45	boop	dom96: how many idioms does passing an "async" bool to startProcess break? :)
13:57:34	def-	ingsoc: well, the general order should be right.
13:58:43	*	yglukhov________ quit (Remote host closed the connection)
13:59:16	*	yglukhov________ joined #nim
13:59:33	*	intra joined #nim
14:00:02	*	BlaXpirit joined #nim
14:03:14	dom96	boop: I would prefer an async type.
14:03:26	boop	subtype? yeah.
14:03:28	*	boop nods.
14:03:35	boop	still getting used to nim idioms
14:04:34	*	saml joined #nim
14:11:29	*	darkf quit (Quit: Leaving)
14:22:25	*	bjz joined #nim
14:27:53	*	bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
14:28:10	*	bjz joined #nim
14:28:23	*	bjz quit (Client Quit)
14:29:23	*	gokr quit (Quit: Leaving.)
14:30:10	*	bjz joined #nim
14:36:29	*	vikaton joined #nim
14:38:46	*	OnO joined #nim
14:45:04	*	Aszarsha quit (Remote host closed the connection)
14:48:07	*	yglukhov________ quit (Quit: Be back later ...)
14:57:06	*	Perelandric joined #nim
14:59:49	*	OnO quit (Ping timeout: 264 seconds)
15:18:08	*	gyeates joined #nim
15:21:33	*	boop is now known as boopisaway
15:24:12	*	renesac joined #nim
15:24:40	*	banister joined #nim
15:34:22	vikaton	does Nim have non-blocking I/O
15:35:55	saml	yes
15:36:12	saml	http://nim-lang.org/docs/asyncio.html
15:36:23	saml	looks like depreacated
15:36:27	saml	use asyncdispatch
15:37:17	*	dddddd joined #nim
15:37:29	vikaton	hmm
15:38:22	*	bluenote_ quit (Ping timeout: 246 seconds)
15:57:42	*	Arrrrr joined #nim
15:58:58	Arrrrr	HI
15:59:54	*	gyeates quit (Ping timeout: 258 seconds)
16:01:11	landgraf	Error: implementation of 'id' expected
16:01:17	landgraf	what does it mean?
16:01:32	landgraf	which kind of implementation?
16:02:47	Araq	proc id: int = 3
16:02:59	Araq	would be an implementation of 'id'
16:03:25	landgraf	Araq: missed spaces :(
16:03:38	Araq	hrm?
16:03:48	landgraf	Araq: id*: int -> id* : int
16:03:54	landgraf	Araq: this fixed the issue
16:04:01	Araq	er ... what?
16:04:12	landgraf	ah no
16:04:14	landgraf	nvm
16:04:18	Araq	lol
16:04:36	reactormonk	Araq, you asked me a while back for being here, then just gtfo'd...
16:05:08	Araq	reactormonk: I asked because you need to be able to fix all the regressions that your PRs caused
16:06:48	reactormonk	Araq, haven't seen any show up
16:06:54	Araq	indeed
16:07:01	reactormonk	at elast as issues.
16:07:23	Araq	can you fix nimsuggest please?
16:07:56	landgraf	Araq: Well. It was indentation. (I'm playing with nim second time).
16:07:59	reactormonk	Araq, https://github.com/Araq/Nim/issues/2694 ?
16:13:22	*	coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
16:15:50	*	gyeates joined #nim
16:29:10	*	gokr joined #nim
16:47:41	vikaton	I was just asking, since I heard rumors of Nim being very unsafe
16:50:00	*	Jesin quit (Quit: Leaving)
16:50:24	ldlework	vikaton: very unsafe pre-rust or post-rust
16:50:30	reactormonk	vikaton, yeah, we had a debian guy asking if he could bootstrap nim
16:50:59	ldlework	It seems many people's thresholds of what 'very safe' has changed pretty substantially as of late
16:51:15	vikaton	ldlework: not sure what you mean
16:51:16	*	endragor quit (Ping timeout: 272 seconds)
16:51:49	ldlework	dunno how else to say it
16:52:07	vikaton	the post-rust thing
16:52:26	vikaton	They just say its unsafe because of compilation to C and C's undefined behaviour
16:52:29	*	Jesin joined #nim
16:52:49	vikaton	also heard rumor that Nim may compile straight to LLVM in the future
16:54:03	reactormonk	unlikely
17:02:51	gokr	vikaton: The "unsafe" bit... sure, Nim doesn't have the same memory safety as Rust, but ... it sure seems MUCH easier to work with. And the C bit? Araq may know more, and sure, you can probably cook up some corner case code - but generally things work fine. And if you find an issue, file a bug report.
17:03:15	gokr	When I say "seems" that's because I haven't coded in Rust.
17:03:45	*	endragor joined #nim
17:04:33	Araq	reactormonk: exactly that bug
17:05:36	Araq	vikaton: I'm very busy these days but soonish I will address these foolish points against Nim in its faq
17:06:32	vikaton	Araq: Sounds good
17:07:56	Araq	here is a hint: x86 has an "illegal opcode" error/runtime trap. does that mean C has that error too cause it compiles to x86?
17:08:59	vikaton	Im guessing no
17:12:54	gokr	Btw, there are lots of languages that compile via C, including duh... C itself. Which you know, Linux etc is written in :) Its all about compiling "correct" C.
17:20:26	Arrrrr	Does unicode module have any proc to test whether a rune is a digit or not?
17:26:04	*	BitPuffin|osx quit (Ping timeout: 245 seconds)
17:32:29	*	brson joined #nim
17:32:40	*	boopisaway is now known as boop
17:33:18	Araq	Arrrrr: there are PRs for that but I consider the unicode notion of what "digit" means completely broken. Just check for x in {'0'..'9'} instead
17:33:48	Arrrrr	Yep, i thought that. Thanks.
17:42:43	*	Jehan_ joined #nim
17:48:33	Jehan_	Glasgow Haskell used to have C as a compilation target; Eiffel studio still does. This really has nothing whatsoever to do with safety.
17:49:00	Jehan_	Leaving aside the fact that "safety" is way too vague a term to be meaningful.
17:53:53	Arrrrr	Why is not '\n' allowed as a literal char?
17:53:56	*	Matthias247 joined #nim
17:54:00	*	banister quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:54:09	dom96	Arrrrr: because it's two chars on some OS'
17:54:18	Jehan_	Use '\l' instead.
17:54:22	Araq	it's actually quite easy to design a language where every function has to be total
17:54:52	Arrrrr	I see, thanks Jehan_ and dom96
17:55:07	*	gokr quit (Quit: Leaving.)
18:04:39	*	zahary quit (Ping timeout: 256 seconds)
18:07:37	vikaton	mhm
18:09:38	*	BitPuffin|osx joined #nim
18:12:29	*	iamd3vil joined #nim
18:23:12	*	flaviu joined #nim
18:24:42	flaviu	Just having a bit of fun with synthmeat's concept from last week: http://a.pomf.se/vxxywb.svg
18:29:52	*	iamd3vil quit (Ping timeout: 246 seconds)
18:30:51	Araq	Jehan_: what do you think about this idea: make 'func' mean the same as 'proc' but every ptr/ref parameter is *deeply* immutable and also a "lent" pointer, meaning that x.field = param is not allowed
18:31:25	Jehan_	Araq: Hmm. Will there be an escape mechanism if you need it?
18:31:25	*	redwyn_ joined #nim
18:31:51	Araq	no. why?
18:32:34	Jehan_	Araq: Because you may need to change the internal representation even if something "seems" immutable.
18:32:56	Araq	well the point of this is to allow:
18:33:02	Jehan_	We have this in a computer algebra systems as a core feature.
18:33:10	Jehan_	Where most types can accumulate and cache properties.
18:33:10	Araq	func depth(n: ref Node): int = ...
18:33:19	Jehan_	Such as whether a group is abelian.
18:33:33	Araq	spawn depth(someTree) # no deepcopies for someTree here
18:34:14	Araq	so if it's mutable under the hood, that's too unsafe for the thread local GC etc
18:34:19	Jehan_	Hmm. First of all, I'm not sure if that works.
18:34:43	Jehan_	Once spawn returns, someTree can be mutated again while the task is still running.
18:34:44	Araq	it works in 'parallel' due to the barrier it implies
18:34:57	Araq	(I hope)
18:35:34	Jehan_	Even in parallel, I don't see it.
18:35:42	Jehan_	var foo = ...
18:35:50	Jehan_	spawn task(foo)
18:35:54	Jehan_	foo.x = 0
18:36:42	Araq	well that's part of the nasty "disjoint check" then, which might be intractable for 'refs'
18:37:14	Jehan_	Yeah, I'm not sure if that's decidable.
18:38:26	Jehan_	Second, even if it worked, the use case is so limited that I'm not sure if one should set a keyword aside for it.
18:38:47	Araq	well it's "obviously" wrong as the lent/immutable attributes belongs to the parameter, not to the routine
18:39:16	*	gyeates quit (Quit: Leaving)
18:39:22	Araq	but maybe in practice it works out
18:39:42	Araq	due to aliasing it's hard to do it on a parameter basis
18:40:10	Araq	plus of course, it looks sexy ;-)
18:40:19	Jehan_	You still have the aliasing issues with multiple threads.
18:40:41	Jehan_	Eh ... I wouldn't see myself using it if it came with such restrictions.
18:40:58	Jehan_	I'm assuming that manipulating global variables would also be strictly forbidden?
18:41:40	Araq	it'd better do that yeah, func not implying 'noSideEffect' would be pretty weird
18:41:59	Araq	but strictly speaking we don't have to do that
18:42:07	Jehan_	The problem is, of course, that then you can't even temporarily insert debugging code.
18:42:22	Araq	there is always debugEcho
18:42:27	Jehan_	Well, if you can manipulate globals, then you have aliasing problems again.
18:42:40	Jehan_	Too limited for a lot of stuff I sometimes need to do.
18:42:56	Jehan_	Debugging may involve gathering data over a period of time to analyze it.
18:44:24	Araq	yeah but then you can always aggregate data into an sqlite table :P
18:44:37	Jehan_	People would probably just start building their own escape mechanisms, via importc, emit, or addr.
18:45:11	Jehan_	Has happened with just about every language ever that tried to control too much what programmers could do. :)
18:45:57	Araq	nah, ... because of ... Haskell ... argh
18:46:10	*	Araq cannot disagree with this argument
18:46:41	Jehan_	I was actually just hacking around Haskell's laziness the other day with deepseq. :)
18:47:02	Jehan_	benchmarking lazy code can be ... tricky.
18:48:08	Jehan_	I think that Nim may need a separate language mechanism to deal with shared data, whether mutable or immutable.
18:48:32	Jehan_	Because that's what this seems to be aiming at.
18:48:47	Araq	well we have that with '=' and '=destroy' following C++'s path allowing atomic RC
18:49:55	Jehan_	So, you want a global shared heap for that?
18:49:59	Araq	I have SharedString and SharedTable, but they don't work yet due to a nice bug. Either =destroy works or '=' but not both. :-)
18:50:04	*	redwyn_ quit (Quit: leaving)
18:50:31	Araq	but that's actually just a manifestation of an old destructor bug
18:50:34	Jehan_	What is =destroy?
18:50:39	*	OnO joined #nim
18:50:49	Araq	the syntax for a destructor
18:50:57	Jehan_	Ah.
18:51:25	Jehan_	Hmm, sort of like a shorthand for `= nil` with immediate effect?
18:51:58	Araq	and yeah, these use a global shared heap. No, it's wrapped in an implicit 'try' at scope exit, really much like C++
18:52:14	Jehan_	Umm, is the idea then that any data type that you want to share needs a duplicate implementation with explicit atomic RC?
18:52:32	Jehan_	I'm not sure I like that ...
18:52:54	Araq	yes. That's the idea.
18:53:12	Jehan_	That sounds like a major violation of DRY.
18:53:23	*	flaviu quit (Remote host closed the connection)
18:53:28	*	ldlework hands Araq a towel.
18:54:00	Jehan_	Not to mention that if you really do it like C++, the shared pointer updates are damn expensive.
18:54:02	Araq	ldlework: not sure what that means
18:54:13	Jehan_	Pun about DRY. :)
18:54:25	Araq	ah got it
18:55:01	Jehan_	I still maintain that the easiest solution would be to have lockable shared heaps.
18:55:21	boop	hmm
18:55:26	Jehan_	Make them read-lockable and you can pass immutable data structures around as much as you want.
18:55:31	boop	i can't find docs on "object of", but i'm sure i saw them before
18:55:35	Jehan_	Write locks and you can exchange data between threads.
18:55:36	boop	any hints?
18:56:20	Arrrrr	boop: http://nim-lang.org/docs/tut2.html#object-oriented-programming-objects
18:56:27	onionhammer	Araq where did we land with module-private constructors?
18:56:42	boop	ah! that's the one
18:56:44	boop	thanks
18:56:45	Araq	onionhammer: nowhere.
18:57:28	Araq	onionhammer: a pragma to disable T(x: 1) construction is consensus
18:57:45	Araq	but all the other proposals don't appeal to me
18:57:51	onionhammer	yeah
18:58:02	onionhammer	pragma is better than nothing
18:58:09	Jehan_	{.opaque.}?
18:58:21	Arrrrr	Agree
18:59:06	Araq	not sure. I guess .opaque is the best we can come up
18:59:21	onionhammer	it's not really opaque though
18:59:49	onionhammer	{.internal.}? :P
18:59:58	Araq	.abstract ?
19:00:15	Araq	.privateconstructible
19:00:20	Jehan_	I'd say {.sealed.}, but that is commonly used for other things.
19:00:22	onionhammer	it's a mouthful
19:00:32	Araq	.privateCons
19:00:34	onionhammer	sealed is good...
19:00:46	Arrrrr	{.noCon.}
19:00:49	Araq	no, sealed is already used for 'final' in C#
19:00:58	Jehan_	onionhammer: Yeah, but it's commonly used for other purposes, so that would confuse people.
19:01:01	onionhammer	yeah
19:01:12	Jehan_	And for "no inheritance outside this package" in Scala.
19:01:17	onionhammer	there's still a constructor arrrr, just cant be used outside of the module
19:01:42	Araq	ah so Scala shamelessly uses C#'s keyword to mean something else.
19:02:01	Araq	better join #scala to tell them it's "confusing me"
19:02:01	Jehan_	Dunno, it may have preceded C# or be simultaneous?
19:02:08	Jehan_	Both have been around for a long time.
19:02:25	Araq	I'm not serious
19:02:48	Araq	it's just that in #nim there is this idea that everybody is always confused about everything, never reading anything.
19:02:52	onionhammer	.internalconstructor. :P
19:03:15	onionhammer	.internalctor.
19:03:39	Arrrrr	sounds good, why not privatector
19:03:45	*	yglukhov________ joined #nim
19:03:46	Araq	Java's volatile also doesn't match C++'s volatile
19:03:48	onionhammer	.opaque. it is..
19:03:50	onionhammer	lol
19:04:03	Araq	but for some reason java got away with it
19:04:41	Arrrrr	because none that programmed in c++ took java seriously
19:04:41	*	dtscode joined #nim
19:05:17	Jehan_	Java is shorthand for "reinventing the wheel, poorly".
19:05:21	*	pregressive quit (Remote host closed the connection)
19:05:41	Jehan_	Okay, that was a bit mean ... but they revisited so many errors that they could have avoided by looking at the state of the art.
19:07:16	Jehan_	I still like Per Brinch Hansen's article about Java's concurrency. It's not often that a peer-reviewed paper publishes a rant by a famous scientist that basically says, "what on earth were you thinking?"
19:07:42	def-	onionhammer: {.private.} makes more sense to me
19:07:58	Arrrrr	What is wrong with java's concurrency?
19:08:40	*	pregressive joined #nim
19:08:59	Jehan_	Arrrrr: http://brinch-hansen.net/papers/1999b.pdf
19:09:23	Araq	Jehan_: yeah well ... lockable heaps. Make them happen please. ;-)
19:09:45	Jehan_	Araq: I can make lockable heaps easy enough.
19:09:51	Jehan_	The tricky part is the language integration.
19:11:03	Jehan_	There are a number of ways of going about that, and I don't want to put in the work without knowing it won't have to be thrown away in the end.
19:11:32	*	UberLambda joined #nim
19:12:25	dom96	Do you guys have any idea how we could bring language support for Nim in travis CI?
19:13:02	Jehan_	Araq: The easiest solution would be copying Eiffel's model, but that is more limited than I like.
19:13:21	Jehan_	Plus, it's really centered around OOP and would have to partly redesigned.
19:13:35	Araq	Jehan_: well you can start with a NEP
19:13:56	Jehan_	That sounds doable.
19:15:08	Araq	dom96: no.
19:15:54	def-	dom96: Similar to this? https://github.com/def-/nimes/blob/master/circle.yml
19:16:04	*	dom96 is setting up Travis CI for the packages repo
19:16:13	def-	I haven't tried Travis CI, but Circle worked easily
19:16:30	def-	Compiles all my builds: https://circleci.com/gh/def-/nimes
19:16:51	dom96	how many of these continuous integration services is there now? lol
19:17:11	Jehan_	More importantly, how do they make money?
19:17:14	def-	Too many. I just chose Circle because someone had a script for it already
19:17:26	dom96	Jehan_: They ask for money when testing private repos.
19:17:39	Jehan_	dom96: Hmm, I see.
19:17:44	def-	and you have to pay if you want to run tests with many cores / many tests at the same time
19:17:47	dom96	def-: ahh. Somebody created a script for travis for me, so I may as well use it.
19:18:12	synthmeat	where exactly can implicit declarations happen?
19:18:29	dom96	I wonder if we could move the Nim repo to one of these services and get nightly builds for free.
19:18:45	Arrrrr	"The 1980s will probably be remembered as the decade in which programmers took a gigantic step backwards by switching from secure Pascal-like languages to insecure C-like languages. I have no rational explanation for this trend. But it seems to me that if computer programmers cannot even agree that security is an essential requirement of any programming language, then we have not yet established a discipline of computing based on common
19:19:22	Arrrrr	Funny
19:19:40	dtscode	synthmeat: The only one that comes to mind is a proc's implicit result variable
19:19:55	synthmeat	Arrrrr: you didn't send the entire quote though. it stops at "common"
19:19:56	dtscode	Since Nim (afaik) doesn't have a this or a self
19:20:02	Jehan_	Arrrrr: It was performance, really, combined with the arrival of personal computers.
19:20:13	Arrrrr	" commonly accepted principles."
19:20:18	Jehan_	I wrote stuff in assembly language back then because anything else was too slow.
19:20:22	synthmeat	dtscode: it works for "for i in 0..2"?
19:20:33	dtscode	synthmeat: What works?
19:20:40	synthmeat	implicit declaration
19:20:55	dtscode	Nothing is implicitly declared there
19:20:57	Jehan_	But yeah, that was sort of depressing still. He has a point there.
19:21:13	dtscode	Because pascal was so secure?
19:21:16	dtscode	and fortran?
19:21:20	synthmeat	dtscode: it says so in the manual?
19:21:32	Jehan_	dtscode: Concurrent Pascal, which he wrote, *was* memory-safe.
19:21:39	synthmeat	quote, "The variable i is implicitly declared by the for loop and has the type int, because that is what countup returns."
19:22:05	dtscode	Well you are still explicitly writing the I. I would say its explicitly defined.
19:22:09	synthmeat	without const, let or var, that sure looks like implicit declaration
19:22:33	dtscode	No, the i is the declaration
19:22:49	dtscode	proc(foo: string) doesn't have const, let, var
19:22:55	dtscode	Jehan_: Eh...
19:23:44	ldlework	That's more like type inference
19:24:01	synthmeat	dtscode: ok. let's agree that what happens there in the for loop is not implicit declaration, in spite of it saying so in the manual, and whatever you want to call it....
19:24:08	synthmeat	where can something like that occur, besides for?
19:25:15	ldlework	synthmeat: do you care about manuals using language for illustrative purposes, or cases where really, you cannot statically analyze some behavior?
19:25:16	dtscode	Is it python that can do if i in [1,2,3] or can you do that in nim as well?
19:25:27	ldlework	that python
19:25:40	Jehan_	Both.
19:25:44	ldlework	woot
19:25:46	synthmeat	ldlework: i'm interested in places where i can introduce a variable without saying "var"
19:26:06	ldlework	synthmeat: that's a poor standard for implicit declaration
19:26:12	dtscode	synthmeat: if i in @["woooooo", "docker", "nimbus"
19:26:22	ldlework	Because its other mechanisms that explicitly stand in for var, in the cases such as for
19:26:27	ldlework	Not "no mechanism at all"
19:27:13	synthmeat	well, if you can present me a mental model of thinking about it more elegantly, i'm wide open :)
19:27:22	ldlework	I just did
19:27:37	ldlework	with the case of 'for', alternative syntax is a standin for var.
19:27:50	synthmeat	it's the "special case"
19:27:52	synthmeat	?
19:27:56	ldlework	There are no cases, or any kind of variant behavior, where the effect changes. You'll get an interation variable.
19:27:56	*	flaviu joined #nim
19:28:06	ldlework	iteration*
19:28:13	ldlework	IE, for is just var spelled differently.
19:28:30	ldlework	Its still an explicit site where a variable is declared. Its type is simply inferred.
19:28:31	synthmeat	is "if" that too?
19:28:32	flaviu	My vim keeps complaining about "lib/system.nim|666 col 6 error| implementation of 'system.+(x: int64)' expected"
19:28:40	flaviu	does anyone have any idea what's going on?
19:28:46	ldlework	synthmeat: can if introduce names?
19:28:55	synthmeat	yeah
19:29:10	ldlework	It can?
19:29:41	synthmeat	no, it cannot
19:29:51	ldlework	Alright then :)
19:30:57	synthmeat	it's just then some syntactic sugar for for loops only?
19:31:37	ldlework	Well that's the only case discussed. I can't think of any other places but I am just disagreeing that what happens in a for loop is a useful instance of what you'd call "implicit declaration"
19:32:08	synthmeat	are there then cases of implicit declarations anywhere at all?
19:34:52	*	banister joined #nim
19:35:16	dtscode	synthmeat: I already told you that
19:35:49	dtscode	<dtscode> synthmeat: The only one that comes to mind is a proc's implicit result variable
19:36:08	*	gokr joined #nim
19:36:19	synthmeat	ok, yeah, i understand now
19:36:24	synthmeat	thanks, that makes sense
19:37:02	synthmeat	i'm trying to figure out a use case where this "not really implicit" declaration would make sense besides for loop, and can't think of one that would be unambigous in whether it is a const, var or let
19:37:09	synthmeat	cool, thanks both!
19:41:52	Araq	Jehan_: smartEiffel never got multi-threading/scoop and the commercial Eiffel has a shared memory GC, last time I checked. So it's not clear at all to me that I can simply copy Eiffel.
19:42:09	Jehan_	Araq: I'll write up why it works.
19:42:26	Jehan_	It works not only for shared memory, but (in principle) even for distributed systems.
19:42:42	Araq	in fact the commercial Eiffel has some documentation about thread local GCs but more recent versions of the documentation don't have that.
19:43:18	Jehan_	The basic idea is that `separate` is a new reference type that denotes a reference to a foreign data space.
19:43:28	Araq	and indeed Scoop is about locking and "guarding", not about memory management
19:43:47	Jehan_	Those are the language features that tie it together.
19:44:30	Jehan_	But there's an underlying requirement that objects are partitioned into separate data spaces.
19:44:54	Jehan_	You can still use a shared GC, and it makes a lot of stuff easier.
19:45:13	Jehan_	The "require" as a wait condition is a pain to implement otherwise, but also overkill.
19:45:39	Araq	yeah that part makes no sense to me anyway.
19:45:51	Jehan_	I'll try and do a NEP write-up later this week.
19:45:59	Araq	a precondition is not a "wait for" condition
19:46:11	Araq	this part always really bugged me
19:46:15	Jehan_	Yeah, that has been one of the criticisms of the model.
19:46:36	Araq	it's not "simple" if you only add 1 keyword but rewrite the underlying semantics
19:46:37	Jehan_	When I wrote my own stuff, I designed synchronization contracts that were separate from preconditions.
19:46:38	onionhammer	def- its not really a private type though
19:46:50	Jehan_	Yeah, that's also something that I never good.
19:46:52	Jehan_	got*
19:47:03	Jehan_	Keyword minimalism is not a design goal in and of itself.
19:47:12	Araq	exactly
19:47:31	flaviu	Does anyone have a self-balancing search tree implementation in Nim?
19:47:39	Jehan_	The key idea, though, is that separate introduces a new reference type and the rest of the stuff is how to make access to such references safe.
19:47:53	Jehan_	flaviu: As it so happens, I wrote one the other day. Let me upload it.
19:47:55	Araq	flaviu: the memory manager uses a variant of AVL trees
19:48:21	Araq	ropes.nim used to have a splay tree implementation
19:48:34	Araq	git history might show it
19:48:37	flaviu	Jehan_: Lucky timing. Thanks!
19:49:03	flaviu	Araq: It's probably going to be easier to use Jehan_'s than to tear out all the unrelated machinery from those two.
19:49:16	Jehan_	flaviu: It's a red-black tree, you may have to adapt it, it's very simple. It's a proof of concept for how to do pattern matching without actually having pattern matching.
19:49:22	Araq	flaviu: yeah but you'll learn more :P
19:49:58	flaviu	Jehan_: Sure, that's no problem.
19:49:58	flaviu	Araq: In that case, I might as well as write my own RB tree and actually learn how it works.
19:50:18	ldlework	doesn't E and Erlang have a lot to say about this stuff?
19:50:42	ldlework	I know that in Monte that they have a reference type called a "farref" which refers to memory in a remote VAT
19:51:18	Jehan_	flaviu: https://bitbucket.org/behrends/rbtree
19:51:54	Jehan_	The only tricky stuff is that that I define a macro to get the `&` operator for tuples.
19:52:05	Jehan_	E.g. (1, 2) & (3, 4) -> (1, 2, 3, 4)
19:52:48	Jehan_	OCaml is still faster because of their crazy good GC, but it blows Haskell and F# out of the water. :)
19:53:22	flaviu	http://www.vision.caltech.edu/~mmcgill/tuples/index.html might have been another option
19:54:04	Jehan_	flaviu: Huh, I didn't know of that.
19:54:31	Araq	at one point in Nim's history I need to apologize for stuff like result[1][0][0] :D
19:54:44	Jehan_	Not sure how he makes it a proc, though, at least not without performance overhead. :)
19:55:22	Jehan_	Araq: Meh, it's not ideal, but it does work for now. :)
19:55:27	Araq	but hey, I was young and needed the money
19:55:59	Araq	btw that's one major reason why Nim lacks pattern matching.
19:56:01	reactormonk	Araq, what would be the alternative?¨
19:56:04	flaviu	Jehan_: Looks like he uses macros: https://github.com/MasonMcGill/tuples/blob/master/source/tuples.nim#L303-L319
19:56:09	Arrrrr	money driven development
19:56:28	Araq	I like trees with a variable number of children
19:56:38	Jehan_	flaviu: Ah, yes.
19:56:40	Araq	and I don't see how to pattern match these
19:56:52	Jehan_	Still, I didn't want to have external dependencies.
19:57:04	*	yglukhov________ quit (Quit: Be back later ...)
19:57:18	Araq	reactormonk: I don't have a good alternative.
19:57:30	flaviu	Jehan_: Makes sense, especially for the context you described.
19:57:41	Jehan_	Araq: There are ways using tree grammars, but probably overkill.
19:57:55	Araq	lots of accessors, firstStmt.firstTupleElem.firstTupleElem
19:58:03	flaviu	Foo(_, Bar(FooBar(v)))?
19:58:06	Jehan_	flaviu: I basically wanted to tackle http://rosettacode.org/wiki/Pattern_matching out of curiosity.
19:58:27	Araq	my DrDobb's article also shows how to do pattern matching ...
19:58:33	Araq	but apparently nobody read it
19:58:42	Jehan_	See PCCTS/Sorcerer.
19:59:02	ldlework	pattern matching is one of the cooler pld features
19:59:12	def-	Jehan_: nice, planning to put it on rosetta code?
19:59:18	Jehan_	Araq: Well, I did read it but wasn't really applicable.
19:59:30	Jehan_	def-: It would be a lie, since it doesn't really do pattern matching.
19:59:47	Jehan_	I happen to think it's an elegant hack around it, but it's not the same.
20:00:10	def-	alright, i guess that's also why i didn't tackle that one
20:00:47	Jehan_	I have been thinking about writing a general pattern matching macro that would work, but ... not urgent enough.
20:01:18	Arrrrr	:O
20:01:20	ldlework	:0
20:01:34	Jehan_	It'd be something like: let Foo(x, y, Bar(z, v)) ~= someStructure.
20:02:13	def-	Jehan_: wouldn't that make more sense baked into the compiler?
20:02:34	Jehan_	Would be transformed into let (flag1, x, y, tmp) = Foo(someStructure); if flag1: let (flag 2, z, v) = Bar(tmp); flag1 and flag2
20:02:35	Araq	def-: not really. read my article please.
20:02:51	ldlework	Araq: which one?
20:02:53	Jehan_	Basically, Foo and Bar would work like unapply in Scala.
20:03:11	def-	Araq: i actually read it, but it's long ago
20:03:27	Araq	but ok, let me do it for OSCON
20:03:36	Araq	I need more macro examples anyway
20:03:44	*	endragor quit (Remote host closed the connection)
20:03:50	Arrrrr	http://www.drdobbs.com/open-source/nimrod-a-new-systems-programming-languag/240165321
20:04:32	Araq	def-: tl;dr you want a customized equality for matching against Foo(x, x)
20:05:31	Araq	now you can say "but you can overload '==' for that" and then I say "ok, fair enough"
20:05:41	Jehan_	flaviu: Hmm, the macros module predates getType. The way he gets at the length is a brilliant hack, but ... dear god. :)
20:06:30	Araq	yeah getType is a real enabler.
20:06:56	Jehan_	Araq: Basically, he counts an index variable up, until t[i] fails. That's the length of the tuple.
20:07:06	Jehan_	Eh, until compiles(t[i]) fails.
20:07:11	Araq	XD
20:07:33	Arrrrr	Isnt that slow?
20:07:40	Arrrrr	i mean, the exception
20:07:46	Araq	Arrrrr: it's only done at compile-time
20:07:53	flaviu	Jehan_: heh, that is clever.
20:08:20	flaviu	Arrrrr: And there is no exception: it's a compiles() call.
20:08:26	flaviu	That's slower than an exception :P
20:08:31	Arrrrr	lol
20:08:43	Araq	dunno about that
20:09:22	dom96	That is genius.
20:09:25	Araq	but yeah, it uses a 'try'
20:09:31	Araq	in the compiler
20:11:37	*	OnO quit (Quit: My iMac has gone to sleep. ZZZzzz…)
20:11:39	Jehan_	What impresses me about C compilers most these days is how well they can optimize struct assignments (both in whole and to their components).
20:11:58	Jehan_	This is really what makes using tuples as an abstraction and still getting good performance possible.
20:13:30	Araq	hey, it's what depresses me most about C compilers. you have all this powerful machinery but it doesn't apply to bignums since "not builtin"
20:13:41	*	UberLambda quit (Quit: Leaving)
20:15:05	flaviu	Can someone verify the output of `nim --dump.format:json --verbosity:0 foo` is bad?
20:15:53	Araq	flaviu: pretty sure it is. --verbosity:0 doesn't imply --hints:off etc
20:15:57	Jehan_	Araq: Well, optimizing bignum arithmetic is really a deeper problem.
20:16:17	Jehan_	My officemate happens to be one of the MPIR developers, so I know a bit about it.
20:16:46	flaviu	I don't think that's the problem. I get `{""version"":""0.11.2"", ...` as the output.
20:17:31	Araq	Jehan_: register allocation for x86 and "avoid temporaries for bignums" is pretty much the same problem
20:17:52	Arrrrr	Have to go, good night.
20:17:56	*	Arrrrr quit (Quit: Page closed)
20:18:35	Jehan_	Araq: at a very high level, and it's not the only optimization problem you're dealing with.
20:19:22	dom96	yay. Jester is now at ~80% of the speed of asynchttpserver.
20:20:35	Araq	Jehan_: yes but it's much better than no optimization at all, which is what you get.
20:20:43	onionhammer	dom96 cool, breaking changes?
20:20:47	dom96	onionhammer: nope
20:20:51	onionhammer	cool
20:20:56	onionhammer	i'll give it a try
20:21:00	Jehan_	Araq: Yeah, but the compiler still needs to know about the library.
20:21:06	onionhammer	is it published to nimble?
20:21:07	Araq	dom96: used lexim? ;-)
20:21:17	dom96	Araq: nope
20:21:21	Jehan_	Incidentally, term rewriting macros may be nice for this. :)
20:21:27	Jehan_	Not perfect, but they could help a bit.
20:21:41	dom96	onionhammer: It's in Nimble's package list.
20:21:48	Araq	well they better could. They have been designed for this.
20:22:23	onionhammer	dom96 nimble install jester?
20:22:31	dom96	onionhammer: yep
20:22:47	onionhammer	i'll bench it when i get home.
20:22:53	onionhammer	before/after on my blog site
20:24:13	Quora	dom96: jester is great :D
20:25:02	dom96	Quora: thanks :)
20:25:46	Araq	dom96: use lexim please
20:26:11	Araq	also add support for custom states and rewrite it completely to not use async ... *cough*
20:26:41	flaviu	I'm pretty sure #2738 is broken. See https://github.com/Araq/Nim/pull/2738/files#diff-e00d77321d9bf30eaf8e4be863d9b565R976 and https://github.com/Araq/Nim/blob/30aed77d0419916b724205b519fe54a47be6284b/lib/pure/json.nim#L874
20:27:07	Araq	hrm now I wonder if that's actually possible
20:27:08	Quora	Does anyone have any suggestions for an XMLRPC library to use with nim?
20:27:26	Araq	Quora: use a JSON RPC library instead
20:27:41	*	OnO joined #nim
20:27:47	Quora	Araq: let's say that is immutable for the scope of my question
20:27:49	dom96	^^ https://github.com/dom96/nim-jsonrpc
20:28:13	Araq	using a format designed for semistructured text for RPCs is so stupid
20:28:21	Quora	I agree
20:28:28	Quora	actually
20:28:30	Quora	hmm
20:28:32	dom96	A certain someone still owes me $200 for that JSON RPC lib.
20:28:38	Jehan_	But sometimes you still get it forced upon you. :(
20:29:01	Quora	dom96: do you have example usage around?
20:29:10	ldlework	dom96: you take bounties?
20:29:18	dom96	Quora: take a look at the tests.
20:29:48	dom96	ldlework: It wasn't really a bounty. But do I take them? Sure.
20:29:51	ldlework	I wonder how much it would cost me to get forward declarations.
20:30:23	dom96	You would have to pay Araq or Zahary for that.
20:31:04	flaviu	ldlework: I hope I've explained why a 100% solution would be too expensive?
20:31:16	dom96	ldlework: This seems to be what you are looking for: http://nim-lang.org/support.html
20:31:18	ldlework	'two passes during a step I literally don't care how long it takes'
20:31:30	*	Trustable_2 joined #nim
20:31:47	Araq	ldlework: depends on what exactly you're after
20:32:03	OnO	any reason I cannot override dot accessor with a template `.` ?
20:32:03	dom96	Araq: not sure how lexim would help
20:32:14	flaviu	ldlework: *at least two passes
20:32:22	ldlework	flaviu: sure
20:32:56	*	Trustable quit (Ping timeout: 272 seconds)
20:33:09	ldlework	Araq: basically be able to do what I can do with functions, but for types, allowing mutually referential modules
20:33:22	ldlework	err
20:33:28	ldlework	allowing mutually referential types across modules
20:33:37	Jehan_	Araq: I just realized that you live across the town from where I am. Plus, same street where I used to live as a student.
20:34:10	Araq	Jehan_: yeah I know :-)
20:34:47	dom96	Any of you guys going to be near or in Edinburgh on the 11th of June?
20:35:35	Jehan_	dom96: Unlikely, though I may be in St Andrews later this year.
20:37:18	*	ingsoc quit (Quit: Leaving.)
20:37:32	*	pregressive quit ()
20:37:46	OnO	nevermind, it works with macro `.`
20:37:55	dom96	Jehan_: Pity. I was actually considering attending a university there.
20:39:14	dtscode	:D The 12th of June is my birthday
20:39:25	onionhammer	http://h2o.github.io/
20:39:28	onionhammer	oo this looks promising
20:39:47	onionhammer	early days though by the looks of it
20:42:01	flaviu	dom96, onionhammer: please see https://github.com/Araq/Nim/pull/2755
20:42:24	dom96	onionhammer: ooh. Let's make that the backend of Jester :D
20:42:26	onionhammer	did you submit a bug?
20:42:55	dom96	flaviu: What's the problem with that PR?
20:43:38	flaviu	Line 976 and line 970.
20:44:07	flaviu	Those lines + context should be fixed and tests added to prevent similar problems.
20:44:31	def-	dom96: nice work on optimizing jester
20:44:48	flaviu	Then #2738 can be remerged.
20:44:56	dom96	def-: Thanks. I'm sure there is more that can be done.
20:45:02	reactormonk	Araq, btw, there can't be more than one dirty file with nimsuggest... should I fix that?
20:45:21	onionhammer	flaviu what about those lines?
20:45:24	dom96	def-: For example I wonder if there is any way to optimise async procs because they add a seriously large amount of overhead.
20:45:41	dom96	def-: I'm not sure whether it is just the Futures, the first class iterator allocation or both.
20:45:46	def-	dom96: indeed, that should be the main optimization
20:45:52	def-	dom96: and multi-threading of course
20:45:52	Araq	reactormonk: hrm, the compiler certainly knows more than 1 dirtyfile
20:46:04	flaviu	onionhammer: Those lines lead to double-quoting, see the implementation of escapeJson.
20:46:22	onionhammer	ahh
20:46:31	reactormonk	Araq, ok, later then maybe. I'll put it on github
20:46:32	onionhammer	escapeJson adds extra quotes?
20:46:47	onionhammer	grmble...
20:47:02	onionhammer	thats not intuitive
20:47:38	onionhammer	how big of a breaking change would it be to not add quotes around input string with escape Json.. jeez..
20:47:55	flaviu	I'm not sure why escapeJson is exported, because that could be fixed without any problem if it wasn't.
20:48:19	reactormonk	onionhammer, it's used in a few places
20:48:42	onionhammer	it makes sense to export it imo... just not to add quotes
20:49:09	Araq	hrm? "foo" should become "\"foo\""
20:49:13	Araq	not ""foo""
20:49:23	onionhammer	foo should be foo, there's nothing to escape
20:49:32	Araq	for JSON?
20:49:37	onionhammer	right
20:49:43	dom96	could we fix toUgly instead of reverting the PR?
20:49:45	flaviu	I agree, if people want the quotes, they can do `newJString("foo")`.
20:49:49	dom96	and... test it properly this time?
20:49:57	Araq	foo is not valid JSON.
20:50:01	flaviu	dom96: Revert the PR, and then merge it again when it's fixed.
20:50:11	onionhammer	foo is a valid json STRING value
20:50:36	dom96	flaviu: there were already problems with the fork disappearing
20:50:40	dom96	don't think that's a good idea
20:50:44	Araq	escapeJson("foo") --> "\"foo\""
20:50:49	reactormonk	what's the return type of escapeJSON? Is it JString? If not, it should return "foo"
20:50:58	Araq	what else should escapeJson do?
20:50:59	onionhammer	escapeJson("foo") => "foo"
20:51:08	Araq	no way.
20:51:10	flaviu	dom96: We don't want to have bad code in devel, especially since I compile my nim directly from devel.
20:51:31	onionhammer	escapeJson(value) != wrapInQuotes(value)
20:51:32	dom96	then let's fix it quickly.
20:51:52	dom96	Doc string for escapeJson: Converts a string `s` to its JSON representation.
20:51:54	reactormonk	anyone messed with the linux profiler yet?
20:52:03	dom96	The JSON representation of a string includes the quotes.
20:52:18	Araq	onionhammer: what should be "escaped" then?
20:52:40	onionhammer	Araq http://json.org/
20:52:51	flaviu	Just merge https://github.com/Araq/Nim/pull/2755 and then we can argue all we want over this.
20:52:53	onionhammer	unicode characters, quotation marks, newline characters, etc
20:53:01	dom96	flaviu: I will just fix it instead.
20:53:02	*	OnO quit (Quit: My iMac has gone to sleep. ZZZzzz…)
20:53:20	flaviu	Make a new PR to replace #2738 if there are problems with the branch disappearing.
20:54:25	Araq	onionhammer: sorry this makes no sense. If \0 becomes \u0000 then certainly the quotes should be added as well
20:54:38	onionhammer	Araq of course, but only if quotes are in the original string
20:54:49	onionhammer	this is *adding* quotes to the string
20:55:05	Araq	yes, and that's correct
20:55:12	onionhammer	*sigh*
20:55:23	Araq	maybe we need to rename 'escape'
20:55:55	onionhammer	newJStringNode("somevalue") maybe
20:55:57	onionhammer	lol
20:56:09	reactormonk	dundundidun.... valgrind takes ages....
20:56:41	flaviu	reactormonk: Try perf.
20:57:25	reactormonk	flaviu, got me a page on how to use that?
20:57:35	reactormonk	... and can I attach it to a process?
20:58:14	onionhammer	anyway, good find flaviu, sorry for that. I was working with my own escape implementation while testing it looks like
20:58:45	onionhammer	(I was trying to improve the performance of that too, but it didnt make an appreciable difference)
20:59:19	dom96	Fixed.
20:59:43	onionhammer	thanks
21:00:52	flaviu	reactormonk: Turn on debug info in Nim, and then use perf record --call-graph dwarf -e instructions -c 500 myprogram
21:01:14	flaviu	Change the value of -c based on the runtime of your program.
21:01:23	flaviu	run perf report to see the results.
21:01:45	reactormonk	and -p to attach
21:02:25	reactormonk	turn on debug info via --passC:-g ?
21:03:01	flaviu	No, --debuginfo --linedir:on
21:08:41	reactormonk	it's running the GC quite often...
21:09:17	def-	flaviu: I think --debugger:native does the same
21:12:31	reactormonk	flaviu, wanna help dig? I'm trying to find out why nimsuggest bugs on the second call.
21:12:47	*	TEttinger quit (Ping timeout: 256 seconds)
21:12:56	reactormonk	O.o 2G in perf data
21:14:12	flaviu	Yep, it's big. Changing -c should fix that. I don't remember if it needs to be increased or decreased :P
21:15:27	flaviu	def-: Huh, that's not even that recent. Well, I can use that from now on.
21:16:05	Araq	reactormonk: compiler/modules.nim implements the logic you like to debug
21:16:22	flaviu	reactormonk: sorry, I'm working on something else right now
21:16:45	reactormonk	Araq, yup, put my debug in there already
21:19:37	reactormonk	Araq, hm. at the first pass, it just compiles said module a few times. At the second, it compiles the whole compiler I'd say.
21:21:49	reactormonk	yup, it does.
21:21:57	reactormonk	ah fuck, debugging global state. I hate that
21:24:44	mahlon_	Hello, new to nim, have what will probably be a quick one: I've written a deepcopy proc for a custom type, and I want to test/assert that the copied object is indeed different. Is there an easy way to get an object "unique" identifier for comparison? Address location as string or something?
21:25:54	*	mahlon_ is now known as mahlon
21:26:34	Araq	mahlon: cast the ref to int
21:27:01	Araq	or repr it
21:27:03	reactormonk	wouldn't addr <variable> work better?
21:27:21	Araq	reactormonk: that most likely would return a stack address
21:27:35	reactormonk	Araq, ah, the location of the pointer?
21:28:31	reactormonk	mahlon, btw, cast[int](ref_variable)
21:28:51	reactormonk	or was it (int)? I always get that mixed up with java syntax
21:29:26	Araq	reactormonk: use Nim's syntax for Nim code.
21:29:35	Araq	that should be easy enough to remember :P
21:29:45	Araq	(yes, it's cast[int](ref_var)
21:29:57	reactormonk	I'm usually just tossing it at the compiler and see if it complains
21:30:31	mahlon	Perfect. Thanks all.
21:34:12	flaviu	What's the story wrt strong spaces? Is that getting dropped?
21:35:37	Araq	flaviu: I think so.
21:35:55	*	redwyn joined #nim
21:36:24	flaviu	ok
21:36:46	*	Trustable_2 quit (Remote host closed the connection)
21:36:52	Araq	people are all vehemently against language dialects these days
21:37:17	reactormonk	uniformity \o/
21:37:31	Araq	I actually like the idea that you can do #! strongSpaces or !# curlies and have it your way
21:38:41	Araq	but I'm alone.
21:39:15	Araq	IMHO Nim is still too far ahead of its time in these aspects
21:39:52	Araq	programmers instead agreed that fascism is the only way to develop large software systems
21:42:08	*	boydgreenfield joined #nim
21:45:04	reactormonk	Araq, I think the caching and file indexes are broked... do you mind if I tweak nimsuggest to compile the whole project at startup?
21:45:53	renesac	by they way, from what I tried of strongSpaces, I liked the distinction between no space and one space
21:46:18	Araq	reactormonk: doesn't it do that already?
21:46:21	renesac	but I don't think that "one space" vs "two spaces" is as visible
21:46:50	Araq	renesac: yeah fair enough
21:47:13	Araq	I only really cared about one vs none space
21:47:13	renesac	and the worst thing about it is that when quickly prototyping the compiler will keep nagging you about inconsistent spacing
21:47:31	renesac	reminds me of the ";" errors in C that I wanted to scape
21:47:32	reactormonk	Araq, nope.
21:47:39	renesac	^^"
21:47:39	Araq	oh really? now that's interesting, renesac
21:47:42	reactormonk	I'll take that as a "no"
21:47:58	Araq	cause the common wisdom said the worst feature is all the random bugs you get with this feature
21:48:04	renesac	Araq: well, they are my fault
21:48:24	Araq	reactormonk: fix it, fix it, fix it. I'll review anyway
21:48:43	renesac	but it is good for slopyness be tolerated when you are just trying out things
21:49:05	renesac	you want nicelly formated code when you are going to show to others
21:49:08	reactormonk	Araq, it's just something that might get very ugly if I have to change it afterwards... I might rely on all files being in the index already
21:49:25	reactormonk	so the suggest might bork if the file isn't in the index.
21:49:36	Araq	renesac: all I take from it is that I'm right. :P
21:49:38	reactormonk	on the other hand, it might get a bit more robust
21:49:51	Araq	reactormonk: yeah go for it
21:50:23	reactormonk	also, I might have a bug or two in my code ^^
21:50:58	reactormonk	ah nope, just wrong message sent
21:51:01	renesac	but yeah, maybe I would learn to (almost) always use consistent spaces between my operators, like I can remember to put ";" after every line in C (after some time swiching to it)
21:51:22	renesac	I usually correct those things latter when re-reading the code
21:51:46	reactormonk	the whole ";" story just came from fortran overcompensation because people really didn't like whitespace-sensitivity
21:51:53	renesac	and yeah, your take for it might be right ^^"
21:52:59	reactormonk	oh, SIGSEGV, old friend, so we meet again
21:54:42	vikaton	SigSegV is seg fault?
21:56:24	reactormonk	yup
21:56:47	*	pregressive joined #nim
21:57:03	onionhammer	dom96 ok maybe i'll make a wrapper for h2o :P
21:57:13	dom96	onionhammer: do it
21:57:13	reactormonk	vikaton, if you try to dereference a pointer in the kernel space (like null, because null is 0, which is the start of kernel space), you get a segmentation fault. So the kernel stops execution and send your process a SIGSEGV.
21:57:36	onionhammer	dom96 only if you agree to make jester compatible w/ it ;P
21:57:39	reactormonk	... correct me if I'm wrong. But someone's gonna do that anyway :-)
21:58:04	dom96	onionhammer: me? Why not you? :P
21:58:46	onionhammer	psh
21:59:08	onionhammer	decouple jester from the std lib and make the http server pluggable maybe
21:59:10	onionhammer	then I will
21:59:17	dom96	onionhammer: I might do it, it sounds fun.
21:59:26	dom96	onionhammer: Just write the wrapper and we'll see ;)
21:59:27	vikaton	reactormonk: deref null pointers is the term right?
21:59:37	boydgreenfield	Araq: Is https://github.com/Araq/Nim/issues/2724 and https://github.com/Araq/Nim/issues/88 something that someone who hasn’t spent time with the compiler codebase (me) can help out with? Or just a “wait for it to land”-style feature?
21:59:46	Araq	ah hi boydgreenfield
22:00:04	reactormonk	vikaton, yup
22:00:10	boydgreenfield	Araq: Hi :). And sorry that this one’s a pain.
22:00:38	reactormonk	vikaton, derefing a null pointer gives you a segfault.
22:00:47	Araq	boydgreenfield: when I looked it the problem it looked hard, but I dunno. Usually these things don't stay hard.
22:00:52	Araq	*at the
22:00:57	vikaton	Yeah I figured, thanks reactormonk
22:01:37	Araq	boydgreenfield: either way, it's only compiler/sigmatch.nim that needs to learn about it, I think
22:02:41	*	vbtt_ joined #nim
22:03:18	renesac	reactormonk: in C deref a null pointer is undefined behaviour
22:03:43	vikaton	so is that what the Rust people always complain about?
22:03:44	renesac	that is one of the points people saying nim is unsafe by compiling to C tout
22:03:46	vikaton	segfaults?
22:03:58	renesac	not segfault, undefined behaviour
22:04:07	renesac	well, segfaults is another topic
22:04:09	reactormonk	vikaton, so it doesn't need to segfault, it may
22:04:35	vikaton	so its kind of a luck sort of thing?
22:04:46	renesac	the problem with undefined behaviour is when the compiler optimizers becomes too clever and starts using it
22:04:53	*	boop is now known as boopisaway
22:04:55	*	redwyn quit (Ping timeout: 256 seconds)
22:05:04	renesac	I don't know if it is the case for dereferencing null pointers
22:05:38	renesac	I never saw it being something else than a segfault on modern systems
22:05:52	reactormonk	but it might be
22:06:14	flaviu	renesac: related: http://blog.regehr.org/archives/1234
22:06:41	boydgreenfield	Araq: Ok, I’ll take a look. Turns out that the alternative is passing the T type parameter up into every object that uses the generic, which becomes… inelegant very quickly.
22:07:04	boydgreenfield	(or lots of case statements and checking)
22:08:20	*	redwyn joined #nim
22:08:43	Jehan_	renesac: It sometimes can not segfault if you're accessing a very large data structure.
22:09:21	renesac	Jehan_: why?
22:10:10	Jehan_	Because then you may end up in actual process memory.
22:10:36	renesac	?
22:10:38	reactormonk	Araq, how does nimsugget collect the symbols exactly?
22:11:09	Araq	reactormonk: depends on what you request. 'sug' is different from 'def'.
22:11:20	Araq	but it's all done in compiler/suggest.nim
22:11:30	Jehan_	renesac: Assume that process memory starts at address 65536. Then any null pointer access for an element in a data structure with an offset >= 65536 may succeed.
22:11:57	Araq	Jehan_: yeah I've never seen this in practice in my entire life.
22:12:04	Jehan_	e.g. var a: ref char[100000]; echo a[90000]
22:12:04	renesac	hum
22:12:12	Jehan_	Araq: Yeah, it's mostly a theoretical concern.
22:12:36	Araq	it seems to be the most important reason to diss Nim these days
22:12:37	renesac	well, the major concern would be the compiler optimizer doing something funny with it
22:12:46	Jehan_	Plus, a language cannot protect against all bad behavior.
22:13:20	renesac	well, what Jehan_ said is somewhat the compiler doing something funny
22:13:21	Jehan_	Try calculating fib(100) with a recursive fibonacci implementation and your program will essentially become unusable, too.
22:13:24	renesac	for performance
22:13:37	Jehan_	renesac: Huh?
22:13:47	Jehan_	No, this was just about memory layout.
22:13:50	renesac	or not
22:14:07	renesac	because [] is just a pointer arithimetic operator in c,...
22:14:17	renesac	syntax sugar
22:14:19	reactormonk	Araq, from what I can read you basically run the compiler with a few if gCmd == cmdIdeTools: suggestStmt(c, a)
22:14:20	Jehan_	That said, one could add explicit null checks to be on the safe side if it were a pressing need.
22:14:41	Araq	yup and we have to do it for marketing reasons
22:14:46	*	gsingh93 joined #nim
22:14:59	Jehan_	The reality is that even in Rust the following program crashes: fn main() { if true { main(); } }
22:15:07	Araq	but it's very telling how far from reality these discussions really are
22:15:17	renesac	and yes, languages like rust overemphasizes the importance of the types of safety it gives, IMHO
22:15:27	Jehan_	There's so much stuff that a compiler can't really protect against.
22:15:38	reactormonk	which would kinda explain the whole problem... I ran compileProject before the first suggest, and now it doesn't suggest anything anymore because the compiler isn't compiling anything because it's all cached
22:15:55	reactormonk	at least I now know the cache is working as intended
22:16:25	Jehan_	reactormonk: And that's actually a good example. You're about a 100x more likely to have a bug because of faulty cache logic.
22:16:35	*	boopisaway is now known as boop
22:16:52	reactormonk	Jehan_, it's not faulty in general, it just not doing as expected
22:16:57	Araq	Jehan_: iirc Microsoft's compiler can emit stack overflow checks and null pointer deref checks when the offset is too large
22:17:11	Araq	in fact, that's what the JVM does
22:17:12	Jehan_	The thing is, as someone who at some time actually did write formal specifications (in Z), I have no clue why everybody seems to think that type systems protect them against all flaws.
22:17:13	*	BlaXpirit quit (Remote host closed the connection)
22:17:32	Araq	emit a check when the offset is too big, rely on some segfault handler otherwise
22:17:33	Jehan_	reactormonk: I wasn't picking on you, I was just pointing out that getting cache logic right is a difficult issue.
22:18:26	Jehan_	Araq: Yeah, you can. But even so, there are so many bugs that occur even though they are "safe" (the quotes are intentional).
22:18:49	Jehan_	The last line effect, for example: http://www.viva64.com/en/b/0260/
22:18:54	reactormonk	Araq, there's two options. a) disable caching for nimsuggest. will make it SLOOOOW and probably unusable b) cache all suggest* calls and replay them c) cache all suggest* calls and figure out how a better way than replaying them
22:19:03	reactormonk	actually, three.
22:19:59	Jehan_	Program correctness requires a multi-faceted approach and static typing does not sprinkle fairy dust on your code that makes bugs magically go away.
22:20:37	flaviu	How would I do [1.. ^1] on a user-defined type?
22:20:39	renesac	reactormonk: you could hash some way the calls to decide if an identical call was already made or not
22:20:48	renesac	with high probability
22:21:01	reactormonk	renesac, high probability? hello, bloom filter
22:21:05	renesac	:P
22:21:06	flaviu	How does the special-casing work?
22:21:18	reactormonk	flaviu, special-casing?
22:21:28	flaviu	for [1 .. ^1].
22:21:48	*	Kingsquee joined #nim
22:21:49	vikaton	Jehan_, in all fairness, They try to eliminate segfaults, data races etc etc
22:21:53	vikaton	and they have done a good job
22:21:57	reactormonk	probably converted to len(seq) - 1 - x
22:22:13	vikaton	Rust isnt perfect, but it sure does help with mem saftey
22:22:30	Jehan_	flaviu: You need to define len(x) for the type.
22:22:43	Jehan_	vikaton: I know what they are trying to do, and it's worthwhile.
22:23:00	vikaton	However it does provide extra headaches
22:23:14	Jehan_	But it also has left a large footprint on the language and the code you write.
22:23:35	vikaton	whats a footprint in this case?
22:24:01	renesac	reactormonk: well, you can make a hash table where the final step compares the whole contents of the call
22:24:01	Jehan_	vikaton: Making the language and programs bigger and noisier to carry the additional information required.
22:24:15	Jehan_	Programming language design is the art of tradeoffs.
22:24:16	vikaton	True
22:24:23	*	dtscode quit (Ping timeout: 258 seconds)
22:24:30	vikaton	Ehh Idk about that :)
22:24:33	Jehan_	There are definitely areas where the Rust approach has just the right tradeoffs.
22:24:42	Jehan_	TANSTAAFL, in other words. :)
22:25:02	vikaton	Crystal seems to be my best trade
22:25:04	reactormonk	renesac, I'll wait for Araq, I can run some counts meanwhile
22:25:23	*	boop is now known as boopisaway
22:25:45	Jehan_	vikaton: For what it's worth, none of the languages I know of has perfect tradeoffs for the use cases I need. So I stick with the ones that come closest.
22:25:48	Jehan_	E.g. Scala and Nim.
22:26:11	reactormonk	renesac, actually, might be a bit ugly. pretty sure PContext is changed
22:26:26	Jehan_	Ruby if I need to script something fast. And a few others.
22:26:37	Jehan_	It's always good to be proficient in more than one language. :)
22:26:47	vikaton	I want to ask a question
22:26:51	reactormonk	Jehan_, ruby for scripting, nim for speed, scala for money here ;-)
22:26:56	renesac	reactormonk: well, this should be solvable if the cache is to work at all, right?
22:27:01	Jehan_	reactormonk: Heh. :)
22:27:01	vikaton	Lets take Nim v C++
22:27:20	vikaton	Why does Nim have much more elegant syntax + speed
22:27:21	Jehan_	I have a small Nim project where I use ruby to generate Nim code.
22:27:27	Jehan_	vikaton: Does it?
22:27:41	vikaton	while C++ can get verbose or the most part
22:27:42	Jehan_	It's entirely subjective. Some people hate whitespace-based syntax.
22:27:52	vbtt_	They're wrong, of course.
22:28:04	vbtt_	;)
22:28:42	Jehan_	Personally, I like Pascal-style (well, Eiffel-style, to be precise) syntax, but nobody makes languages with that anymore.
22:28:44	vikaton	hmm
22:29:06	vikaton	Dont you see a huge paradigm of syntax between C++ and Ruby?
22:29:09	Jehan_	In the end, as long as the syntax doesn't make me hit my head against a wall, I'm fine with pretty much anything.
22:29:21	Jehan_	Paradigm of syntax?
22:29:22	vikaton	syntax difference*
22:29:45	Jehan_	Well, yeah, there are plenty of differences. Why?
22:29:48	reactormonk	renesac, we're talking 300k calls here.
22:30:59	vikaton	Jehan_, It takes half the time to create something in Ruby then it is C++, let's imagine Ruby was as fast for a second, why would people continue C++ ?
22:31:17	renesac	reactormonk: is it somewhat recursive, so you can cache closer to the base cases that won't change as much?
22:31:20	reactormonk	vikaton, I like types
22:31:21	Jehan_	vikaton: Because they've got resources invested in C++.
22:31:24	reactormonk	renesac, unlikely
22:31:38	reactormonk	renesac, I just counted proc suggestExpr*(c: PContext, node: PNode) =
22:31:42	Jehan_	Plus, it's about more than time to create something; it also has to be maintainable.
22:32:04	reactormonk	which is basically where all the suggest calls go through once
22:32:13	Jehan_	There's some research that one of the major benefits of static typing is that they serve as self-verified documentation, making maintenance easier.
22:32:16	vikaton	reactormonk: imagine that added into Ruby
22:32:33	reactormonk	vikaton, no method_missing magic anymore
22:32:58	vikaton	wait wut
22:33:55	Jehan_	For what it's worth, I wrote an Eiffel compiler in Ruby for my Ph.D. thesis (before Ruby was popular).
22:34:15	Araq	XD
22:34:34	Jehan_	That worked pretty well for getting it implemented fast (two months), but ... it was difficult to maintain without having type annotations.
22:34:42	Araq	I ignored Ruby before it was popular... :P
22:34:47	vikaton	Jehan_, port it to Crystal !
22:34:52	Araq	and I'm still ignoring it
22:35:01	vikaton	I love Ruby :((
22:35:09	notfowl	A reason to use c++ over ruby? Ruby has broken backwards compatibility several times since version 1.8.
22:35:17	Jehan_	vikaton: I'll have yet to see where crystal is going.
22:35:24	renesac	reactormonk: I was just wondering that if the PContext changes inviabilizes caching at that level, then one should cache in a lower level
22:35:29	renesac	but I don't know the code
22:36:04	Jehan_	It looks really nice for small programs, but how well will a JIT approach from source work for programs hundreds of KLOCs in length?
22:37:13	Araq	vikaton: I don't like the attitude behind Crystal. it starts with the premise that "Ruby is perfect, but too slow". That's not why you should start a new language. ymmv
22:37:14	Jehan_	Mercurial had to work pretty hard to keep Python start up time in check, and that's with just an interpreter.
22:38:07	*	filwit joined #nim
22:38:31	Jehan_	I have some tools that get called literally dozens of times during a build process.
22:38:48	vikaton	Araq, they want to make it as close to Ruby as possible, but like the blog about "Crystal, a different language" they are changing things that will make it better
22:38:52	Jehan_	Nim happens to be perfect for that, because it has next to no startup overhead and is still reasonably expressive.
22:39:10	Jehan_	While, much as I love Scala, the JVM startup time is prohibitive for that.
22:39:29	flaviu	Isn't Crystal AOT?
22:39:54	Jehan_	flaviu: Is it? Whenever I tried it, I ran it on a .cr file and didn't see any object code produced.
22:40:56	vikaton	yeah @ flaviu
22:40:59	Jehan_	flaviu: Mind you, I may be totally wrong there, it's been a while.
22:41:28	Jehan_	Hmm, it looks like it caches compilation results.
22:41:36	vikaton	crystal text.cr - runs it like its interpreted, but its really compiles
22:41:47	vikaton	crystal build text.cr makes the executable file
22:41:54	vikaton	but does not run
22:41:58	Jehan_	I see.
22:42:15	Jehan_	Nevermind then. :)
22:42:25	*	bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
22:42:37	Araq	vikaton: Nim is as close to Python as possible except for all its improvements then ;-)
22:43:27	vbtt_	Python is better than Ruby so it's a win :)
22:43:33	Jehan_	vikaton: In any event, Crystal is one of the languages I'm watching. I'll wait until it approaches stability, though.
22:44:07	vbtt_	nim is more mature than crystal, imo
22:44:34	vikaton	vbtt, Idk about that tbh
22:44:59	vikaton	It would seem like it should be, since Nim is not as new and is 0.11
22:45:11	*	vendethiel quit (Ping timeout: 244 seconds)
22:45:16	vikaton	but since Crystal is basically like Ruby, you can seach for the methods in ruby docs
22:46:27	dom96	Jehan_: What do you think of Rust?
22:46:48	Jehan_	dom96: As a research project, thoroughly fascinating.
22:47:13	Jehan_	But it offers me nothing for the application domains I require.
22:48:01	filwit	Rust's compiler probably helps you catch a few nasty concurrency related memory errors, which is nice. Gotta give em that.
22:48:19	Jehan_	Most of the stuff I do is about algorithmic correctness (non-trivial one at that), not the type system.
22:48:48	dom96	I see.
22:48:54	vikaton	Nim's Type system and Rust's are very much alike
22:49:09	Araq	what? o.O
22:49:18	Jehan_	filwit: I'm not a big fan of their approach to concurrency. Again, there's nothing wrong with it, it just doesn't help me.
22:49:59	vbtt_	what's similar about rust and nim's type systems?
22:50:09	reactormonk	Araq, mind giving me an answer?
22:50:18	Araq	reactormonk: what's the question?
22:50:31	reactormonk	Araq, there's three options. a) disable caching for nimsuggest. will make it SLOOOOW and probably unusable b) cache all suggest* calls and replay them c) cache all suggest* calls and figure out how a better way than replaying them
22:50:31	vikaton	or maybe I'm not using the right terms
22:50:34	Araq	vbtt_: it uses colons ;-)
22:50:54	Jehan_	filwit: I do work in computer algebra. I need tools that are flexible and are capable of operating at a high level of abstraction, but don't bog me down in details.
22:50:55	vbtt_	:)
22:51:02	Araq	reactormonk: the caching already exists, if it's wrong fix it
22:51:19	reactormonk	Araq, compiler caching or suggest caching?
22:51:19	Araq	disabling it is not an option
22:51:22	vikaton	Actually scratch that
22:51:33	reactormonk	figured as much
22:51:46	Araq	reactormonk: there is only 1 caching
22:51:49	filwit	Jehan_: Well IIRC Rust's ownership tracking will prevent you from writing to memory from one thread to another accidentally, while Nim currently doesn't (due to lack of deep immute or similar ownership tracking)
22:51:53	Araq	which is the module cache
22:52:25	Jehan_	filwit: I'm not saying that Nim is my perfect language for everything. I use it for a subset of the things I need.
22:52:26	vbtt_	btw, what's the status of nimsuggest? not-quite-ready/ alpha / beta quality?
22:52:38	reactormonk	vbtt_, doesn't work imo
22:52:44	Jehan_	Most actual computer algebra stuff happens in specialized languages.
22:52:44	Araq	filwit: we do deep copying instead.
22:53:05	Araq	vbtt_: works well for me
22:53:06	reactormonk	Araq, yup, and as soon as a file hits the module cache there's no suggestions from that file anymore because the compiler never passes over it - that's my theory
22:53:13	vbtt_	thanks reactormonk - i couldn't compile it so was wondering if I should fight the fight
22:53:16	Jehan_	filwit: In general, Nim is also a bit low level for many of the things I need (but is great for the system level tooling that I have to do).
22:53:18	*	vikaton quit ()
22:53:25	reactormonk	vbtt_, ah, yup. just compile it in the compiler dir
22:53:43	vbtt_	hm ok i'll try that
22:53:59	Araq	vbtt_: 0.11.2 has some docs about it
22:54:02	reactormonk	vbtt_, nim c nimsuggest.nim && cp -f nimsuggest ../../bin/nimsuggest
22:54:27	filwit	Araq, yeah I agree that's a good solution to the problem, and when we have it that will be very cool. I'm just giving credit where it's due ATM (unless you've recently made deep immute or something and I'm just out of the loop).
22:54:59	Araq	hrm? it does deepCopy. since 0.10.x
22:55:04	vbtt_	i thought i followed the docs on the site. http://nim-lang.org/docs/nimsuggest.html#installation
22:55:06	notfowl	There's a lot wrong with crystal. For ex you can't redefine a method after its been used. Well you can, it silently fails
22:55:09	vbtt_	didn't work for me :(
22:55:14	vbtt_	but will try again.
22:55:59	Jehan_	filwit: For what it's worth, there are plenty of existing alternative solutions.
22:56:12	Jehan_	They've just been studiously ignored by mainstream programming languages.
22:56:24	reactormonk	so nimsuggest actually works in aporia? ...
22:56:26	filwit	Araq: err... i a parrallel test of mine messing up due to lack of deep-immute parameters not that long ago.. but maybe I need to rerun those tests.. sorry not trying to spread bad info..
22:56:49	Araq	filwit: that bug has been fixed and had nothing to do with 'parallel'
22:56:57	Araq	or 'spawn'
22:57:31	filwit	Jehan_: Well i'm certainly no expert here (quite the novices actually)
22:57:51	filwit	Araq: ah, okay.. that was a huge misunderstanding on my part then.. :|
22:58:28	Jehan_	Safe concurrency has been around since the 1970s/1980s (Concurrent Pascal, CLU/Argus, Eiffel/SCOOP).
22:58:32	vbtt_	rust doesn't even allow two mut reference to the same object in the same thread.
22:58:52	flaviu	I need a temporary variable in a macro, how would I do that?
22:59:07	Araq	flaviu: macros.gensym
22:59:29	flaviu	thanks!
22:59:32	Araq	filwit: also the major problem is that imho nobody has yet figured out how to do multi-threading in a game engine. afaict.
22:59:43	filwit	Jehan_: well like Araq said, deep immute is something I thought Rust did that Nim did not, which apparently is wrong.. and that was the entire basis for my initial claim that Rust would catch nasty memory bugs.
22:59:53	Jehan_	Araq: Games have their own sets of interesting constraints.
22:59:56	Araq	filwit: no no no, sorry
23:00:23	Jehan_	filwit: Rust doesn't really worry too much about immutability (they got that right, in my opinion), but about safe sharing.
23:00:27	Araq	filwit: Rust has deep immutability. Nim has deep copying. you're right there is a big difference.
23:00:32	*	reactormonk quit (Quit: WeeChat 0.4.3)
23:00:56	Jehan_	My problem is that they try to solve that problem at compile time, which, in my experience, lacks expressiveness and saddles you with a lot of bookkeeping.
23:01:15	filwit	well threading is used a ton in games.. just not to update certain steps of the pipeline like game-logic (so far as I'm aware.. so yeah, take that with salt)
23:01:43	filwit	Araq: ahhhh okay i get it
23:01:54	Jehan_	filwit: The last time I wrote a computer game was in school, that was on an eight-bit computer in Z80 assembler. :)
23:02:14	filwit	nice :)
23:02:29	Jehan_	Meaning that my practical experience in the area is rather limited. :)
23:02:31	Araq	filwit: yes but it's *far* from a solved problem
23:02:53	*	vendethiel joined #nim
23:03:44	Araq	and the solutions I know all use a single shared heap aka C's malloc and then blame Nim for its GC instead of its thread local heap. ;-)
23:04:31	filwit	Araq: i have some interesting ideas here actually.. namely semantic scanning for GameObject references which is used to divide the objects into concurrently separate parts automatically (so you can at least thread some of it automatically where possible)
23:05:31	Jehan_	One thing about concurrency is that there's really no single "one size fits all" solution.
23:05:48	filwit	Araq: also, I am not afraid of unsafe memory, so Nim's unmanaged shared memory for something as tightly controlled as the game object management/event dispatch doesn't bother me :)
23:06:25	*	LoneTech quit (Ping timeout: 264 seconds)
23:06:33	*	LoneTech joined #nim
23:08:03	Araq	Jehan_: yeah but multi-threading a game engine, solves a real problem. multi-threading an async http server... doesn't. :-)
23:08:21	Jehan_	Araq: Heh, yeah.
23:08:25	filwit	Jehan_, Araq: If I could switch gears here for a sec, I want to let you know I've jotted down a 'pros/cons' list + reasoning about my constructor's side-project: https://gist.github.com/PhilipWitte/0ca58b9655a6f3fd8ff0#file-pros-cons-md
23:08:39	filwit	Jehan_, Araq: I'm not looking for your feedback on that right now
23:09:06	*	boydgreenfield quit (Quit: boydgreenfield)
23:09:21	filwit	Jehan_, Araq: I just wanted to let you know I fleshed out my reasoning a bit about what I'm going to be attempting to do soon.
23:09:42	Jehan_	filwit: Glancing at it, I believe my objections still stand.
23:09:53	Jehan_	Again, not that this matters. You'll have to convince Araq, not me. :)
23:11:00	filwit	Jehan_: okay, noted, and we don't need to go over the points again.. we really need to sample a larger community, but the only way to do that is with a working system IMO.
23:11:06	Jehan_	In particular, it's still not backwards-compatible, as far as I can tell.
23:11:09	*	reactormonk joined #nim
23:11:19	filwit	Jehan_: actually I realized it is fully
23:11:49	filwit	Jehan_: in fact, the one that isn't backwards compatible is the "limit obj constructors to their modules" approach
23:12:14	Jehan_	filwit: I know that, this is why there's probably going to be based a pragma-based solution.
23:12:27	Jehan_	But it can still break existing uses of T() and T(x).
23:13:59	filwit	no, because it only invokes 'create' if one exists.. so you're right, it could actually break *some* code where a 'create' function existed and wasn't expected to be invoked as a constructor.. but those cases should be rarer
23:14:56	filwit	most of the time all existing code would do exactly what it does now for T() and T(x).. things only change *after* you add in the 'create' procs
23:15:51	*	pondererer joined #nim
23:16:04	pondererer	https://www.quora.com/Is-Nim-really-that-unsafe
23:16:09	*	pondererer quit (Client Quit)
23:16:37	*	Matthias247 quit (Read error: Connection reset by peer)
23:17:09	Jehan_	So, if there's a create routine, you suddenly cannot do type conversions anymore or instantiate a new object based on its type?
23:17:39	Jehan_	I'm really not sure why this particular syntax is so important ...
23:19:31	*	milosn quit (Ping timeout: 250 seconds)
23:19:31	filwit	well the point isn't about the syntax.. in fact your question is exactly what we want the possibility to do (limit the constructor of a type to a specific path unless you go outside of your way to do it)
23:20:14	*	milosn joined #nim
23:21:41	notfowl	How is that even a question
23:21:52	filwit	I did look at your 'make' macro, and I like it (I use named constructors bond to types in my code).. but the problem is that the most obvious syntax for creating types is artificially limited as a instantiate method for most types
23:22:11	notfowl	"Is Nim really that unsafe?" What is the context
23:25:12	*	vendethiel quit (Ping timeout: 272 seconds)
23:25:23	filwit	Jehan_: you do raise a good point about type conversion though.. I image sometimes you'd want a 'create(t:var T, u:U)` proc and still keep type-conversion to other types, while other times you would want to limited them entirely.. I think this could probably be addressed with a pragma though
23:26:02	Jehan_	notfowl: No explicit nil checks, apparently, but relying on segfaults.
23:27:50	*	gokr quit (Quit: Leaving.)
23:31:42	*	wb quit (Ping timeout: 252 seconds)
23:33:06	*	Jehan_ quit (Quit: Leaving)
23:34:14	*	saml_ joined #nim
23:37:48	def-	notfowl: I guess this is the context: https://news.ycombinator.com/item?id=9050999 I see this repeated whenever Nim is mentioned somewhere
23:38:26	*	Kingsquee quit (Quit: Konversation terminated!)
23:39:19	reactormonk	Araq, ok, if I reset gCompiledModules and gMemCacheData it keeps working, so I gotta dig in there and see what goes wrong
23:41:22	*	vikaton joined #nim
23:41:40	vikaton	HOw do I download http://nim-lang.org/download/nim-0.11.2.tar.xz from a VPS ._.
23:41:45	vikaton	I completely forgot
23:41:48	def-	vikaton: wget
23:42:06	vikaton	o w000w
23:42:12	*	redwyn quit (Quit: leaving)
23:44:11	*	vbtt_ quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
23:51:44	*	dtscode joined #nim
23:53:32	vikaton	def-, after adding export PATH=$PATH:/root/nim-0.11.2/bin/ in my bashrc, do I reboot?
23:53:42	*	Kingsquee joined #nim
23:53:45	vikaton	or make changes go in affect?
23:53:51	*	gsingh93 quit (Ping timeout: 276 seconds)
23:53:57	flaviu	vikaton: Reboot linux? What sort of madness is this oO
23:54:00	dom96	vikaton: source .bashrc
23:54:16	def-	vikaton: you could log out and log in again, or source the file, or do the export in your shell
23:54:30	vikaton	Nope, got it, thanks def- !
23:54:31	def-	or restart of course, if you really want to
23:54:42	vikaton	I reboot my linux all the time!
23:54:59	dtscode	When in doubt turning it off and on is always the answer
23:55:30	flaviu	dtscode: Nothing ever goes wrong ;)
23:55:42	dtscode	Never :D
23:55:49	Araq	vikaton: you should only reboot linux for trying a different distro.
23:56:01	Araq	and you should try a different distro every day.
23:56:19	dtscode	Which is generally faster? A dispatch table, or if-chain calling functions?
23:56:24	vikaton	I see
23:56:34	Araq	if-chain
23:56:43	dtscode	Thanks Araq
23:56:54	flaviu	Or when your graphics card either got damaged by static or got messed up by factory and crashes whenever you don't run it at half clock speed
23:57:30	vikaton	How good is Nim with functional programming aspects?
23:57:48	dtscode	As good as any other language
23:57:55	Araq	Nim is better than you are at FP
23:58:02	flaviu	Stdlib support is lacking, and lambdas are a little verbose.
23:58:03	dtscode	Than me?
23:58:23	flaviu	exciting changes coming to lambdas though, and you can always write your own stdlib.
23:58:37	Araq	dtscode: no vikaton
23:58:58	vikaton	:(
23:59:02	vikaton	u dont know that :(
23:59:10	dtscode	Araq: Ah. Well the statement still fits for me :D
23:59:11	dom96	flaviu: what exciting changes?
23:59:14	dom96	aww poor vikaton
23:59:33	Araq	vikaton: silly questions sometimes get you a silly answer
23:59:38	dtscode	dom96: I've been meaning to ask you a question
23:59:42	flaviu	Araq: Didn't you say that you like the `_` syntax at one point?
23:59:42	Araq	sorry!
23:59:53	vikaton	Well mainly