<<25-06-2012>>

---

00:23:52	*	dom96_and joined #nimrod
00:24:08	*	dom96_and quit (Client Quit)
06:52:54	*	llm joined #nimrod
07:01:29	*	llm quit (Quit: ChatZilla 0.9.88.2 [Firefox 13.0.1/20120614114901])
09:15:43	*	Araq_ joined #nimrod
09:18:01	Araq_	good news zahary I found the memory corruption bug :-)
09:22:01	zahary	yeah, I read the log
09:22:08	zahary	good to hear
09:40:27	*	Araq_ quit (Read error: Connection timed out)
09:41:03	*	Araq_ joined #nimrod
10:34:10	*	Trix[a]r_za is now known as Trixar_za
10:55:04	*	Araq_ quit (Quit: ChatZilla 0.9.88.2 [Firefox 13.0.1/20120614114901])
10:57:13	Tasser	Araq, found any leftover money?
11:20:04	Trixar_za	Oh I see
11:20:34	Trixar_za	I need to add nimgame to the cfg file if I want to put it in a separate directory
11:25:20	Trixar_za	!words
11:25:39	Trixar_za	er, wrong channel :P
12:24:57	*	Trixar_za is now known as Trix[a]r_za
13:26:26	*	JStoker quit (Excess Flood)
13:30:25	*	shevy quit (Ping timeout: 260 seconds)
13:36:14	*	JStoker joined #nimrod
13:42:58	*	shevy joined #nimrod
14:58:49	*	Trix[a]r_za is now known as Trixar_za
15:13:36	*	Trixar_za is now known as Trix[a]r_za
15:43:53	*	Trix[a]r_za is now known as Trixar_za
16:00:40	*	Trixar_za is now known as Trix[a]r_za
16:17:20	*	Trix[a]r_za is now known as Trixar_za
16:52:13	Trixar_za	Araq, what are the minimum package requirements for Nimrod?
16:53:05	Araq	Trixar_za: you need a GCC
16:53:13	Araq	dunno about other requirements
16:53:37	Trixar_za	I figured as much. Seems the rest is just optional extras
16:54:57	Trixar_za	I actually tried to see how small I could make the nimrod compiler's directory (post bootstrapped and with nimrod's compiler compiled)
16:55:00	Trixar_za	It's about 20MB
16:55:45	Trixar_za	23MB with the examples and tests included
16:56:38	Trixar_za	Meaning it's smaller than Python and Perl packaged
16:57:48	Trixar_za	Yes, I was kind of bored earlier :P
17:00:41	Trixar_za	Oh btw Araq, if you use nimgame with the latest github build it actually produces a completely different error
17:03:05	Araq	the compiler's exe is about 1 MB
17:03:22	Araq	you only need system.nim, lib/system and the configuration files I think
17:03:32	Araq	should be way less than 20 MB ...
17:03:39	Trixar_za	True
17:04:51	Trixar_za	I left in the core, impure, pure, wrappers, posix and system
17:05:19	Trixar_za	and ecmas
17:05:22	Trixar_za	whatever that is
17:05:42	Araq	ok 'core' is needed too, otherwise macros wouldn't work
17:06:30	Trixar_za	You'll probably need core to provide most functionality though
17:06:44	Trixar_za	er s/core/pure/
17:06:45	Trixar_za	:P
18:01:55	*	Trixar_za is now known as Trix[a]r_za
18:25:03	Araq	ping zahary
18:25:47	zahary	here
18:26:00	Araq	I've implemented routine annotations
18:26:11	Araq	aka "macros in a pragma section"
18:26:29	Araq	and I noticed there are some interesting things going on :-)
18:26:38	Araq	m:
18:26:44	Araq	proc p[T]() = nil
18:26:51	Araq	passes the generic 'p' to m
18:27:01	Araq	and there is not much that can be done about it
18:27:05	Araq	but for this:
18:27:14	Araq	proc p[T]() {.m.} = nil
18:27:27	Araq	we can actually invoke 'm' for every instantiated 'p'
18:27:37	Araq	which is what you really want I think
18:28:25	zahary	I wanted side effects from instantiations, but this actually is already possible with a static block inside the proc body
18:29:40	Araq	I know
18:30:07	Araq	so do you think it should just be syntactic sugar and no difference semantically?
18:31:47	zahary	the classic use case for pragma attached to proc is when a bunch of real procs represent a single piece of functionality. like a RPC proc (you end up compiling code for serialization, probably replace the proc with a thunk function, etc)
18:34:04	Araq	I'm thinking of 'memoize'
18:34:16	zahary	but surely there will be cases where "after instantiation" is useful (maybe another immediate vs ordinary option)
18:34:37	Araq	proc p[T](a, b: T): T {.memoize: (a, b).}
18:34:49	Araq	which is tranformed into:
18:35:06	Araq	memoize((a,b)): proc p[T] ...
18:36:05	*	Tasser quit (Ping timeout: 260 seconds)
18:36:17	zahary	is this a runtime memoization/
18:37:05	Araq	er, yes?
18:37:12	Araq	if I understand the term correctly :-)
18:37:26	Araq	you want a different cache for each instantiation
18:37:31	Araq	I think ...
18:37:55	Araq	but it can be done with 'static' too
18:38:12	Araq	er, ... I dunno
18:38:19	zahary	you can get that if you produce a single generic proc from the macro
18:39:50	zahary	proc cached_p[T](a, b:T) =
18:39:50	zahary	var cache: THash[pair[T]] {.global.}
18:39:50	zahary	if (a, b) in cache: ….
18:45:29	Araq	sure
18:48:09	Araq	well
18:48:24	Araq	since it doesn't work yet the way I intented
18:48:45	Araq	I'll go with the simple way and make it only syntactic sugar
18:50:16	zahary	also, you can derive your "per instantiation" behavior from the simpler mechanism
18:50:16	zahary	you just need to insert a static block in the resulting proc
18:50:37	Araq	well my way has problems anyway
18:51:03	Araq	in generic instantiation it's not supposed that proc.ast is somehow not a nkProcDef
18:51:08	Araq	(or similar)
18:51:46	zahary	does pragma push work pragma macros? that would be quite useful I think
18:51:57	zahary	* with with *
18:52:00	zahary	work wirh
18:52:11	Araq	template m(s: stmt): stmt {.immediate.} =
18:52:12	Araq	{.push stackTrace: off.}
18:52:13	Araq	s
18:52:15	Araq	{.pop.}
18:52:17	Araq	works
18:52:18	Araq	if that's what you mean
18:52:29	Araq	in fact, I only tested it with this :D
18:52:43	zahary	I mean. {.push myMacroPragma.}
18:52:57	Araq	no
18:53:13	Araq	what's the purpose?
18:53:17	Araq	myMacroPragma:
18:53:19	Araq	proc a
18:53:21	Araq	proc b
18:53:23	Araq	...
18:53:32	Araq	ok you have to intend it
18:53:55	Araq	but I don't really like 'push' and 'pop'
18:54:04	Araq	they caused much trouble to implement
18:54:19	Araq	I prefer a first class construct:
18:54:38	zahary	yes, that's why I wasn't sure about the need for macro pragmas after all
18:54:43	Araq	with optimizations=on:
18:54:49	Araq	...
18:54:59	Araq	is nicer IMO than push and pop
18:55:20	Araq	would also have been much easier to implement
18:55:27	Araq	but it sucks for system.nim
18:55:28	*	Tasser joined #nimrod
18:55:45	Araq	as we'd have even more indentation
18:55:51	Tasser	back we are again
18:56:15	Araq	and push/pop can do nice unstructed things:
18:56:23	Araq	when defined(x):
18:56:29	Araq	{.push: ....}
18:56:38	Araq	... ordinary code here
18:56:42	Araq	when defined(x):
18:56:47	Araq	{.pop.}
18:56:52	zahary	true that
18:58:07	Araq	but then I never know which parts in system.nim have the dreaded stack traces turned on ... :-)
19:00:30	Araq	which is however due to the include files; unstructured pushs are not the reason ... hm
19:00:38	zahary	ideally, there will be also a compile-time IDE api. you'll be able to say things like "add visual label to this definition" and the IDE will display it somehow
19:14:26	Araq	macros that modify whole procs have other issues btw:
19:14:43	Araq	vectorize:
19:14:49	Araq	proc p ...
19:15:22	Araq	if 'vectorize' is not an 'immediate' macro 'p' should be checked for semantics
19:15:50	Araq	which is what we need since then 'vectorize' has a chance to look at the *types*
19:16:12	Araq	so it transforms p and returns an optimized p
19:16:29	Araq	but then we check 'p' for semantics again
19:16:40	Araq	as we can't be sure the macro produced something reasonable
19:17:07	Araq	but semantic checking for nkProcDef introduces a new 'p'
19:17:22	Araq	this means it will clash with "attempt to redefine p"
19:17:31	Araq	or something even worse
19:18:14	zahary	well, there will be need for some flags like nfTransformed on the proc def for example
19:19:28	Araq	I think we simply need a specialized "semAfterMacroExpansion"
19:19:37	Araq	that overwrites the definition
19:20:42	Araq	you already did something similar
19:20:55	Araq	but I forgot the details :-)
19:23:05	Araq	on the other hand
19:23:13	Araq	if macros can access the symbol table
19:23:23	Araq	you could overwrite the definition yourself
19:23:33	Araq	and return a dummy 'nil' node
19:23:55	Araq	oh ...
19:24:17	Araq	that's a loophole then
19:24:28	Araq	it can bypass the semantic checker this way
19:27:56	zahary	I think the symbol table should be accessible with magics like isDefined, etc, but the interface shouldn't be too low level
19:27:56	zahary	I considered once adding a addDefinition magic (can't recall why I needed that), but it was going to take a nkTypeDef or nkProcDef and just run the sem functions over them
19:30:01	Araq	actually it's a bit weird to hand nkProcDef to the macro
19:30:16	Araq	perhaps the macro should receive the proc's body only
19:30:41	Araq	but then it couldn't add implicit parameters
19:30:46	Araq	so screw that
19:34:53	Araq	hm it should be easy to add an 'overwrite' mode for semcheck after macro expansion
19:35:08	Araq	in fact the code is already prepared for it
19:35:17	Araq	as the REPL has the same problem
19:35:25	Araq	var x = error
19:35:33	Araq	var x = 0 # overwrite please
19:40:15	Araq	ok, next topic:
19:40:31	Araq	I plan to implement a {.forward: on.} pragma
19:40:54	Araq	that causes the compilation pipeline to pass the whole module to the passes
19:41:18	Araq	and the semantic pass will then add the headers of all procs and methods to the symbol table
19:41:38	Araq	as if there would be an explicit forward declaration for them
19:42:29	Araq	we can later make {.forward: on.} the default, but I will turn it off for the wrappers anyway
19:43:03	Araq	the plan is to not add any proc/method in a 'when' statement
19:43:29	Araq	and to not do it for templates, iterators and macros as these have inlining semantics anyway
19:43:54	Araq	and I don't like the compiler to use some arbitrary flow through the module for semantic checking
19:44:21	Araq	(yes I know it's not really arbitrary ...)
19:45:13	Araq	I think these restrictions make perfect sense :-)
19:45:23	Araq	opinions?
19:45:26	zahary	so, when I say "forward on", at the top of the module there are forward declarations for all procs?
19:46:02	zahary	what are the when statements doing? when isDefined(paramType): forward declare?
19:47:19	zahary	ah, I read your message in a wrong way
19:48:02	zahary	well, the problem is the param types which come from other modules - the forward declarations should appear after the import statements
19:48:21	Tasser	what about conditional imports?
19:48:31	zahary	you can do them now
19:48:57	Araq	well it's restricted to a single module obviously
19:49:11	Araq	you need the explict forwards if you do cyclic modules
19:49:23	Araq	which are currently broken anyway
19:49:45	Araq	oh wait
19:49:49	Araq	now I get what you mean
19:50:11	Araq	hm yes the {.forward: on.} needs to come after the import statements
19:50:17	Araq	tricky
19:50:38	Tasser	why tricky?
19:50:54	Araq	because 'import' can appear anywhere in top level scope
19:51:04	Araq	you don't have to do it at the top of the module
19:51:13	Araq	(though almost all code does it)
19:53:15	Tasser	can't you resolve wherever a proc can be forward-declarated?
19:54:46	Araq	what do you mean?
19:54:51	zahary	you need to do a topological sort on the graph of procs pointing to their dependent symbol names (i.e. type names appearing as params and return values)
19:58:32	Araq	that's as bad as doing a depth first traversal through th e module
19:58:54	Araq	might as well do that then instead
19:59:35	Araq	first pass simply adds forwarded syms to the symbol table
19:59:50	Araq	and then semantic checking is done when the symbol is accessed
20:00:08	zahary	I was explaining to Tass. otherwise, yeah, I have thought about this and a first pass over all modules is what I would go with
20:00:36	Araq	over all modules? o.O
20:00:49	Araq	I was still talking about *within* a single module
20:01:56	zahary	well, I think cyclic dependencies should be allowed
20:02:22	Araq	they are but you need explicit forwarding for them to work
20:02:41	Araq	otherwise you have Java/C# style
20:03:19	Araq	which is hardly a module system at all
20:03:51	zahary	hmm, what's not right there?
20:05:30	Araq	I'm not sure how java does it these days
20:05:59	Araq	but visual studio recompiles everything when I load a solution and keeps it in memory
20:06:31	Araq	afaik it uses a whole program translation approach much like nimrod does
20:06:59	Araq	except that nimrod now has symbol files
20:07:30	Araq	I don't know if they could be done for C#
20:07:33	zahary	are assemblies equivalent to symbol files?
20:07:44	zahary	when it comes to compilation I mean
20:08:01	zahary	aren't assemblies *
20:08:15	Araq	hm I dunno :-)
20:08:35	Araq	I only know it compiles too much and it takes too long :D
20:10:30	zahary	you can have any cyclic dependency in nimrod too (if it's not cyclic at the symbol level) - it's just quite a bit of pain in the ass to write the code in the required style
20:10:31	zahary	you have to do it like this
20:10:31	zahary	proc foo(x: int)
20:10:31	zahary	import tables
20:10:32	zahary	proc foo(x: TTable)
20:10:33	zahary	import windows
20:10:33	zahary	proc foo(x: HWND)
20:11:16	zahary	everything that doesn't depend on another module gets at the top of the file, all imports are pushed as much as possible after the forward declarations
20:11:46	zahary	this doesn't brake symbol files, right?
20:12:24	Araq	yeah it should be possible
20:12:49	Araq	and yes
20:13:06	Araq	it is possible to do allow all sort of crazy cycles and cache nevertheless
20:13:55	Araq	for a cyclic dependency you simply have to the algorithm "assume unchanged"
20:17:13	Araq	but if you have a dependency A -> B -> A you can hardly call it "modularity"
20:17:31	Araq	how do you reuse B?
20:17:44	Araq	ship it with A?
20:18:00	Araq	you may as well 'include' it then ...
20:19:34	zahary	in lasagna code terms, there just at the same layer. cyclic dependencies should not break layers
20:20:42	Araq	http://www.haskell.org/haskellwiki/Mutually_recursive_modules
20:20:53	zahary	I remember reading an article once that argued that all OOP consists of a cyclic dependency between the few data structures that appear as members
20:26:00	Araq	well
20:26:13	Araq	I think I'll do it differently :D
20:26:22	Araq	embrace the pragma solution
20:26:43	Araq	{.forward_refs.} # put forward refs here for all procs coming afterwards
20:26:59	Araq	and the programmer has to put it after the imports himself :D
20:27:13	zahary	the proliferation of included files in the compiler is evidence for the these troubles with cyclic dependencies - there is the sem layer, but it can't be broken in several modules - instead we end up with one sumo module
20:27:39	Araq	yes I know you would bring this argument ;-)
20:27:46	Araq	it's a good point
20:28:20	Araq	but the compiler is already quite complex and your proposal might take years to implement
20:28:46	Araq	I want a hacky solution now :-)
20:30:06	zahary	I don't think it's that hard. I'm more worried about the performance costs associated with it, but I might give it a shot.
20:30:28	Araq	btw we also could use modules instead of includes with the "dynamic binding hack"
20:30:48	zahary	of course, you can implement anything in the meantime
20:31:44	Araq	alright
20:32:12	Araq	if haskell needs hacks around these things, nimrod is allowed them too :D
20:32:30	zahary	I know, but I considered it even less appealing than the import statements layout that I mentioned earlier
20:37:21	Araq	maybe we need the notion of a "package" in nimrod
20:37:47	Araq	and we disallow cyclic dependencies between packages
20:38:04	Araq	and compile a package as a single compilation unit
20:38:24	Araq	this is effectively the 'include' solution but with better namespacing
20:56:54	Tasser	Araq, so import package.file or what?
20:57:11	Tasser	or package.path/to/file/in/package
20:57:54	Araq	Tasser: I dunno
20:59:56	zahary	aren't packages in haskell a collections of modules? something more closer to a lib or dll in nimrod
21:00:43	Araq	how come you are marked as away, zahary? :-)
21:01:17	zahary	dunno, I was away for the last 20 minutes
21:01:21	zahary	am I still away?
21:03:02	Araq	yes
21:06:53	Araq	and to answer your question: I think haskell's packages only have to do with the package manager
21:07:04	Araq	recursive modules are orthogonal to them
21:08:43	Araq	(btw now you're not away anymore)
21:09:36	Araq	ok next topic (last for today)
21:09:55	Araq	generics suck as you have to type [T] all over
21:10:19	Araq	I always played with the idea to do:
21:10:36	Araq	generic [T: constraints_here]:
21:10:38	Araq	type
21:10:46	Araq	TContainer = ...
21:10:55	Araq	proc op1( ...
21:11:22	Araq	where the 'generic' would simply insert the [T] at the "appropriate" places
21:12:13	Araq	but we already have implicit generics now ...
21:12:23	Araq	what's their status btw?
21:14:43	zahary	so you like my proc foo(x: seq) style :)
21:14:45	Tasser	Araq, so where would T be inserted in that snippet?
21:15:01	Tasser	zahary, thumbs up for that
21:15:23	Tasser	and I'd rather call them container instead of implicit generics
21:15:26	Araq	zahary: as I said, I'd prefer empty [] to denote a generic
21:15:46	Araq	in the implicit case
21:15:50	Tasser	container generics that is
21:15:59	Araq	but I can see that it's a bit ugly
21:16:14	Tasser	Araq, it takes a seq. Why the need for []?
21:16:35	Araq	to have "proc p(a, b)" # note no types here
21:16:50	Araq	available for more advanced type inference
21:18:01	Tasser	I'd say use * or . as wildcard in that case
21:18:09	Tasser	... which is ugly, sadly
21:18:10	zahary	but that's orthogonal too. there are simple 2 types Any(current expr) and Infer(to be implemented) and one of them is the default
21:18:22	zahary	* simply 2 *
21:18:43	Araq	well yes but 'proc p(a, b)' can only have 1 meaning I think?
21:18:56	*	Trix[a]r_za is now known as Trixar_za
21:19:00	zahary	it will mean infer when we have that
21:19:12	Araq	you don't want haskell's type inference, you want clay's type propagation
21:19:43	Araq	so it will break compatibility once we got 'infer'?
21:19:52	zahary	yep, I haven't programmed much in haskell, but I found it too strict in the few examples I tried
21:21:15	zahary	and I actually mean the 'a types handling in ML in general (I have spent more time with ocaml than haskell)
21:23:10	Araq	hm what do you mean? 'a is too restrictive?
21:23:31	Trixar_za	Btw Araq, I was thinking. I recently compiled Python and it actually had some painful dependencies (and headers) to compile certain modules. With Nimrod you don't need those headers to compile nimrod or even the packages needed by impure or wrappers
21:23:58	Trixar_za	modules*
21:24:13	Araq	Trixar_za: yes. and your point is?
21:26:36	Trixar_za	Well, a Nimrod package will have less requirements (actually only gcc) and the rest are suggested packages
21:26:46	Trixar_za	Speaking as a packager
21:27:22	Araq	well a nimrod package depends onto the nimrod compiler
21:27:32	Araq	and the nimrod compiler on GCC ... :-)
21:28:34	Araq	Trixar_za: actually I have been thinking to provide a minimal nimrod distribution in addition to the default distribution
21:28:42	fowl	latest nimgame failing to compile for me :(
21:28:54	Trixar_za	Same here fowl
21:29:02	Trixar_za	With a new error too
21:29:03	Trixar_za	:P
21:29:52	fowl	who is vladar4
21:29:56	fowl	does he come in here
21:30:42	Araq	vladar is only on the forum I think
21:30:55	Araq	but it's on github, file a bug report
21:31:03	Araq	though I think it's a compiler bug
21:31:15	Trixar_za	lib/nimgame/mask.nim(25, 18) Error: type mismatch: got (int, uint16)
21:31:15	Trixar_za	but expected one of:
21:31:27	Araq	oh I see
21:31:38	Araq	well unsigned ints are new ;-)
21:31:48	Trixar_za	lol
21:32:14	Trixar_za	so originally it didn't use unsigned ints?
21:32:22	Araq	yes
21:32:28	fowl	mine is different http://pastebin.com/1KBCvtbJ
21:32:46	fowl	cryptic >_>
21:32:46	Trixar_za	This is with the latest git version btw :P
21:34:09	Trixar_za	run koch boot -d:release
21:34:29	fowl	i dont have a `koch`
21:34:33	Araq	well fowl your error is related
21:34:53	Trixar_za	Ah, you didn't bootstrap then
21:35:15	Araq	er what?
21:35:33	Araq	fowl: how can you have a debug version of the compiler without bootstrapping? o.O
21:35:46	Trixar_za	Well, he didn't use ./bin/nimrod to compile koch
21:35:54	fowl	Araq, not sure?
21:36:00	Trixar_za	and didn't do koch boot -d:release
21:36:01	fowl	this time i installed through AUR
21:37:02	Trixar_za	When I messed up the koch boot you told me to do (I parseopt was taking 5 minutes like usual, so I just killed the process) it gave me the same error
21:37:37	Trixar_za	after doing koch boot -d:release properly, it fixed it and gave me the other standard error :/
21:38:24	Araq	Trixar_za: it hardly "fixed" it ...
21:38:31	Araq	it just hide it
21:38:40	Trixar_za	lol
21:38:50	Trixar_za	Well hidden then
21:39:00	fowl	id rather wait until its updated for .8.15 than compiling .8.14 again
21:39:19	Araq	sure
21:40:45	Trixar_za	Btw fowl, did you fix nimgame's use of do?
21:41:06	Araq	AUR's package is stupid if it ships with a debug version of the compiler ...
21:41:19	Araq	it gives nimrod's compile times a bad name ...
21:43:22	fowl	Trixar_za,i could give it a try
21:43:26	Trixar_za	Ah, so it's actually a bug and because the libraries still had the debugger code inside, it showed.
21:43:46	Trixar_za	I thought I broke something >.>
21:46:15	Araq	so zahary what do you think of my 'generic' block? unnecessary?
21:48:28	zahary	fist about ocaml… let me try to remember:
21:48:29	zahary	1 very weird problem was that some basic operations like number arithmetics were not defined as generic functions and this created all sort of problems in implementing other generic functions, which are based on these operations
21:48:29	zahary	I can't remember the details on why the type system didn't allow me to work around this problem in a way similar to C++ where I would simply introduce overloads to adapt the incompatible interfaces
21:49:08	Araq	because ocaml doesn't support general overloading
21:49:20	Araq	as overloading + type inference is NP complete
21:49:39	Araq	it also has +. for float addition iirc
21:50:05	zahary	how does haskell deal with this? the grass is greener there as type classes are more consistently used in most of the libraries
21:50:31	Araq	I think the somewhat bounded overloading doesn't help
21:50:49	Araq	and they just have potentially exponential compile times :-)
21:51:57	zahary	but even haskell type classes are too strict for me as you need to explicitly define every single category of types and provide type classes instances for every type
21:52:22	Araq	on the other hand the type classes introduce runtime polymorphism so they don't need to resolve the conflict at compile time ... ugh ... my haskell is too weak to tell
21:54:02	Araq	anyway, I like the C++ styled duck typing for generics
21:54:30	Araq	it's flexible and who cares if compile time errors are somewhat hard to read
21:55:29	zahary	you claimed better error messages and avoiding accidental type mismatches are good reasons to avoid overly generic code, but I don't see why anything that compiles (a type mismatch, you passed a wrong kind of duck) should be an error
21:56:24	zahary	the errors can be improved upon - the clang guys are using very interesting algorithm to recover the "implicit interface" of the generic param
21:57:11	zahary	so they tell you why your type is broken and locate the correct offending line pretty well
21:57:43	Araq	hey you're unfair
21:58:03	Araq	I always said it's kinda stupid to specify the contract that's already implict in the proc body anyway
21:58:50	Araq	however I said I'd do:
21:58:56	Araq	type TMyFloat = float
21:59:11	Araq	and then have a 500K math library rely on nominal typing
21:59:22	Araq	to get sane compile times
21:59:32	Araq	and prevent code bloat
22:00:55	Araq	and it's easy to overdo generic types: every single string I use could be string[encoding] for instance
22:01:11	Araq	and generics are viral
22:02:00	Araq	speaking of which
22:02:16	Araq	if you buy a commercial physics engine in C++
22:02:36	Araq	what does the code use? templates everywhere? or nominal typing?
22:03:08	zahary	nominal typing, I complained at length how terrible is that if you remember
22:03:25	zahary	in fact every single library have their own math types
22:04:02	Araq	true but I suppose you can only do so much if you want to provide a DLL
22:04:27	zahary	and you can't take advantage of ton of useful code for that reason (you are willing to endure the pain for the fancy physics engine)
22:04:27	zahary	well, you can ship rod files
22:06:11	zahary	given that obfuscated version of the code can be produced, there will be less concerns for companies protecting their commercial code
22:08:30	Araq	rod files are simple to disassemble ... ;-)
22:10:42	Araq	but we can change that; please continue
22:12:18	zahary	the simple symbol renaming techniques are enough of a barrier for someone to seriously consider "stealing / forking" a commercial codebase
22:21:34	Trixar_za	Hehehe
22:21:46	Trixar_za	I think I may enjoy writing a tutorial
22:24:23	Trixar_za	Installing Nimrod: "This is the point in most tutorials/guides where they baby you into how to install the programming language to your system. I'm not going to do this (sorry). Read install.txt like a good boy/girl and follow the instructions for your operating system. Well done, you deserve a cookie."
22:25:49	Araq	lots of people have trouble with building nimrod, Trixar_za :P
22:26:06	Araq	as you can never use the latest stable release to compile the new one
22:26:27	Araq	and I never mentioned that fact anywhere ...
22:27:07	Araq	but hey that only shows nimrod's rapid progress :D
22:27:23	Trixar_za	Or that it's jumped the shark early
22:27:24	Trixar_za	:P
22:29:08	Trixar_za	But yeah, I probably should provide some guide on how to do it. Taught somebody to use -d:release and --opt:size today too
22:29:15	Trixar_za	I don't even thing about it anymore :/
22:37:42	*	Trixar_za disappears to bed
22:38:21	*	Trixar_za is now known as Trix[a]r_za
22:44:38	Araq	good night
22:44:54	fowl	how can you have problems? there are only 4 steps