<<07-07-2012>>

---

00:11:46	*	Trixar_za is now known as Trix[a]r_za
03:50:31	*	Trix[a]r_za is now known as Trixar_za
05:45:55	*	Trixar_za is now known as Trix[a]r_za
10:52:06	*	filwit joined #nimrod
10:53:23	filwit	hi, Araq, I'm not sure you're around, but I was thinking about our last discussion on factory functions vs constructors
10:54:04	filwit	and I came to the conclusion that I like factory functions, except 'attached' to the Type itself
10:54:28	filwit	I'm not sure if there's currently a way to do this in Nimrod (i'm playing around trying to figure it out)
10:54:37	filwit	but what I mean is something like this:
10:54:44	filwit	type Foo = object
10:54:48	filwit	bar : uint
10:55:27	filwit	proc new(f:TypeOf(Foo)) : ref Foo =
10:55:31	filwit	result.new()
10:55:37	filwit	result.bar = 2345
10:55:47	filwit	proc main =
10:56:01	filwit	var f = Foo.new()
10:56:15	filwit	echo f.bar # prints 2345
10:59:13	filwit	this way I can see what Type i'm creating at a glance (which was my argument in favor of Constructors), but you still have the abstraction capabilities and factories, and consistency of a "one-proc-model-that-does-all" (which keeps the learning curve flat)
11:00:22	filwit	any naming conventions, eg, 'new', 'init', 'create', etc, will be easy to pick through with proper IDE suggest features, and easy to understand at a glance
11:02:49	filwit	So in short, I agree that factories are a better choice, and it would still be up to the library creator to write factories in the style or not
11:05:32	filwit	I think that having the ability to attach a Proc to a Type is a Win-Win situation, and an elegant middle ground
11:05:57	filwit	but please, let me know your thoughts :-)
11:08:17	filwit	If you don't have any technical or personal objections to the idea, I would like to try and implement it myself (though I'm not sure entirely how far I will get, at least not soon)
11:10:53	filwit	....wow.... okay... probably should have tried it out a bit more before posting :)
11:11:03	filwit	turns out this already works if i do:
11:11:21	fowl	use type() instead of typeof()
11:11:22	filwit	proc new(f:Foo.type) : ref Foo =
11:11:42	filwit	fowl, ya. Just figured that out, thanks
11:11:53	filwit	soo.... that's sweet
11:12:27	filwit	guess I'll be using that for all of my construction functions
11:17:03	dom96	hello everyone
11:17:13	filwit	hi dom96
11:17:27	dom96	hello filwit!
11:17:49	Araq	filwit: I read your suggestion
11:17:52	Araq	and I like it :-)
11:18:01	filwit	cool
11:18:03	filwit	:)
11:18:08	Araq	I will read it again this weekend though :P
11:18:20	Araq	thanks to NimBot these things are now logged :D
11:18:29	filwit	handy
11:18:31	Araq	I'm pretty busy with integer types btw
11:18:42	Araq	I've implemented my original idea
11:18:58	Araq	as the other solution produced bugs even in the compiler itself
11:19:08	filwit	what's happening with uint vs int?
11:19:27	fowl	nimrod 0.8.15 introducing int4 and int2?
11:19:48	Araq	I despise unsigned ints, but people moaned enough
11:19:55	Araq	so nimrod will get them
11:20:06	Araq	however, "uint64" is not an ordinal type
11:20:27	Araq	as then I'd have to use bignums in the compiler itself everywhere to model this properly
11:20:43	Araq	and that's too much work :P
11:20:54	Araq	plus I have no idea how compile times would be affected
11:21:48	Araq	see http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/ for why Nimrod didn't include them
11:21:50	filwit	won't uint just a a 'distinct int'?
11:21:58	Araq	that's possible
11:22:10	Araq	but not that good for C compatibility
11:22:17	filwit	ah, i c
11:22:53	filwit	still, there shouldn't be a ton of problems since int/uint are the same size
11:23:17	filwit	I would think at least
11:23:26	Araq	there is no problem if you don't use the full range in the first place
11:23:49	Araq	if you need to care about all the edge cases + overflows it's quickly an enormous effort
11:24:00	Araq	it's a PITA in the compiler for instance
11:24:09	Araq	and yet I'm pretty sure bugs remain
11:24:53	Araq	if you use 'int' for speed and do some graphics/game programming where the range is less than -say- 1 Million
11:25:15	Araq	then you can be sloppy about these things
11:25:42	filwit	well, I'm not fully aware of the challenges of super-low-level stuff like that
11:25:58	filwit	but I'm sure you'll find a good solution :)
11:26:14	Araq	thanks
11:26:30	Araq	I think I found it; tests will tell today whether I was right :D
11:26:55	filwit	good luck!
11:26:58	Araq	it's quite advanced, the compiler figures 'and 0xff' fits in a byte ...
11:28:07	filwit	so uint can end up being a single byte?
11:28:19	Araq	basically it does interval arithmetic to be smarter
11:28:29	filwit	interesting
11:28:35	Araq	and allows any implicit conversion that does not lose any information
11:28:56	Araq	and requires explicit conversions for everything it can't prove correct
11:29:37	filwit	btw, that reminds me of an idea I had for strings once... where the compiler would choose a formatted string or regular string based on a weather the '$' symbol was present
11:29:41	filwit	so you could do:
11:29:48	filwit	var s = "My Name"
11:29:57	filwit	echo "Your name is $s"
11:30:12	filwit	and it would automatically format the string
11:30:24	filwit	anyways, just a random idea...
11:30:32	Araq	check the tests or examples for "interpolatedString"
11:30:39	Araq	it can be done with a macro
11:30:40	filwit	k
11:30:52	Araq	(with today's compiler)
11:30:54	filwit	oh, duh!
11:31:14	filwit	gah, Nimrod has the best macro system, I keep forgetting
11:31:17	filwit	one sec
11:31:25	Araq	well with 0.8.14 it worked :-)
11:31:27	Araq	we tested it
11:32:42	filwit	I'm not finding it
11:32:48	filwit	what folder is it in?
11:36:31	Araq	wait a sec ...
11:38:16	Araq	tests/run/tstringinterp.nim
11:38:25	filwit	kthanks
11:38:27	Araq	now that was easy .... ._.
11:38:41	Araq	make a proper stdlib module out of it please :-)
11:39:17	Araq	with a bit better names than concatStyleInterpolation and formatStyleInterpolation ...
11:40:17	filwit	you want it in strutils?
11:41:01	filwit	I was thinking it would be nice as a default for all strings (with a pragma to turn it for for compile time performance)
11:41:16	filwit	but that might be to big a change to make...
11:41:20	Araq	not in strutils please ;-)
11:41:34	Araq	it would make strutils depend on macros.nim ...
11:41:47	filwit	so system.nim then?
11:41:53	Araq	ha
11:41:59	Araq	that's even worse
11:42:02	filwit	lol
11:42:09	Araq	luckily the compiler will prevent it :P
11:42:21	Araq	as system.nim can't import anything
11:42:22	filwit	(thought that already imported macro.nim ;P)
11:42:30	filwit	okay I see
11:42:40	Araq	but you're right
11:42:40	filwit	so just a new lib then
11:42:48	Araq	people want it built-in
11:42:53	filwit	ya
11:43:09	Araq	the problem is that I don't as it's then useless for i18n
11:43:18	filwit	Google's Dart has this by default, though I don't know if it's optimized when the string doesn't have $ in it
11:43:34	filwit	il8n?
11:43:41	Araq	internationalization
11:44:11	filwit	isn't the '$' common among all keyboards?
11:44:20	Araq	in fact, arguably it should support the 'subexes' module ...
11:44:24	Araq	lol
11:44:31	Araq	I'm talking about $ on keyboards
11:44:34	Araq	*not*
11:44:47	Araq	I'm talking about:
11:45:15	Araq	echo "value is $x".translateToCurrentLocale
11:45:49	filwit	the formatting would happen before .translateToCurrentLocale
11:45:57	filwit	?
11:46:01	Araq	yes
11:46:09	filwit	then what's the problem?
11:46:13	Araq	and that's wrong
11:47:04	Araq	"$x file[s] copied" --> becomes: $x & " file[s] copied"
11:47:17	Araq	ideally at compile time for efficiency
11:47:34	Araq	but you can't internationalize a bunch of string concatentations
11:47:50	Araq	you need to keep the pattern as a single piece
11:48:02	Araq	only then 'translate' can do it properly
11:48:13	filwit	ahh... i see the problem
11:48:23	filwit	hmm....
11:49:21	filwit	ya that's impossible because if formating happens at compile-time and translate happens at runtime... it doesn't work
11:49:29	Araq	the problem is that if we do it by a built-in it's too opinionated
11:50:02	Araq	see 'subexes' for instance how IMHO *real* format strings can become
11:50:38	filwit	well... if "$x file[s] copied".translate() became --> ($x & " file[s] copied").translate() wouldn't that work?
11:50:58	Araq	no it wouldn't
11:50:59	filwit	maybe I don't see the problem...
11:51:07	filwit	anyways, for now I'll just make it a lib
11:51:24	Araq	translate could be a macro yes and see the &
11:52:00	filwit	ya, true
11:52:17	Araq	but that doesn't work too well
11:52:30	Araq	keep in mind that "file[s]" is already hackish
11:52:50	Araq	and you really want to use "file" or "files" depending on the value of 'x'
11:53:31	Araq	subexes include a conditional construct for this reason ...
11:54:40	filwit	okay, well how about "string".format() for the naming?
11:55:38	Araq	I dunno
11:56:37	Araq	make it useful as a raw string literal identifier
11:56:38	filwit	hmm... what about $"the string"
11:56:50	filwit	and put it in subex?
11:56:51	Araq	ambiguous
11:57:00	filwit	subexes**
11:57:03	Araq	putting it in subexes is fine
11:57:14	Araq	but $"the string" doesn't work
11:57:25	filwit	there's already a $string defined? what does it do?
11:57:32	Araq	as system.nim already has a `$`(x: string): string
11:57:38	Araq	it's a no-op
11:57:50	filwit	oh, right
11:57:58	Araq	in generic code you wanna say $x and get a string
11:58:10	Araq	no matter if it already is a string ...
11:58:22	Araq	it's really useful :-)
11:58:31	filwit	ya I agree
11:58:39	filwit	so, what's wrong with .format?
11:58:52	filwit	better idea?
12:01:43	Araq	echo format"${x +y}"
12:01:51	Araq	hrm, not sexy enough :P
12:02:14	Araq	and I think $$ is already taken by marshal.nim ...
12:02:33	Araq	plus an operator bites with 'echo' ...
12:02:42	filwit	format"..." describes what's happening though...
12:03:03	Araq	as 'echo $x' is parsed as '(echo) $ (x)'
12:03:39	Araq	format" ..." does not 'format'
12:03:49	Araq	that's what % does
12:04:09	Araq	format" ... " does a compiletime string interpolation with scope capturing ...
12:04:33	filwit	hmm.... okay
12:04:59	filwit	plus, if it's not an operator, people will just use "...", $x, "..."
12:05:06	filwit	when they can
12:05:21	Araq	well I don't mind
12:05:22	filwit	or '&'
12:05:33	Araq	all it does is saving some characters to type
12:05:39	filwit	what about $&"..."
12:05:49	Araq	that's good
12:05:55	Araq	I like it
12:06:08	filwit	kinda implies it's saving you from typing '&' all over the place
12:06:16	Araq	$ for "substitution" and & because it transforms into a concatenation
12:06:19	filwit	okay, I'll do that then
12:06:34	Araq	and then have $% for "formatStyleInterpolation"
12:06:46	filwit	okay
12:06:47	Araq	yummy
12:07:47	filwit	but I actually need to run for a minute, I'll do this when I get back
12:14:35	Araq	no problem
12:28:11	Araq	see you later
12:47:48	dom96	Well that went far: Error: unknown processor: armv6l
12:57:01	filwit	okay
12:57:11	filwit	you working on arm stuff dom96?
12:57:24	dom96	filwit: I got a Raspberry Pi yesterday :)
12:57:34	filwit	nice
12:57:34	dom96	So I thought: Lets test Nimrod!
12:57:40	filwit	good
12:57:59	dom96	I think all I need to do is add that CPU to niminst's config
12:57:59	filwit	how's the little system, I hear they're still selling like crazy
12:58:16	dom96	Well it works :P
12:58:22	dom96	And is quite cool.
12:58:24	filwit	:)
12:58:31	dom96	Not that I have done anything interesting with it yet
12:58:40	filwit	what have you got installed on it?
12:58:48	filwit	Arch?
12:58:51	dom96	yep
12:58:54	filwit	cool
12:59:31	filwit	what sort of software do they have built for Arch-ARM? I never could fine a repository... i'm assuming it's more like AUR
13:00:09	filwit	but I doubt they have Gimp and stuff right?
13:00:38	dom96	Take a look here: http://archlinuxarm.org/packages
13:00:54	dom96	So far everything that I attempted to install was there.
13:01:08	dom96	I haven't installed anything "graphical" yet though
13:01:11	dom96	just command line apps
13:01:51	filwit	cool, thanks for the link, I'll check it out in a sec
13:05:06	filwit	wow, looks like they have everything....
13:05:17	filwit	Gimp, Inkscape, Gnome Shell
13:05:32	filwit	no Blender though
13:05:32	dom96	indeed
13:05:40	dom96	interesting
13:05:40	filwit	but that was expected
13:07:51	dom96	why was it expected?
13:08:32	filwit	well I know Blender doesn't have an Android support yet, mostly because I don't think BlenderPlayer is fully ported to ARM yet
13:08:38	filwit	I follow BlenderNation.org
13:09:13	filwit	ARM graphics drivers are OpenGLES only I think, while Blender uses OpenGL
13:10:36	dom96	oh
13:16:40	filwit	btw, dom96, it looks like your error is related to ARM6 architecture (a guess)
13:16:56	dom96	yes, I know what the error is
13:16:56	filwit	but I thought ArchARM only ran on Arm5/Arm7
13:17:01	filwit	oh, okay
13:17:03	dom96	The csources are not generated for that architecture
13:17:15	filwit	ah
13:17:19	dom96	It's an error from Nimrod :)
13:21:04	dom96	I would love to play around with the GPIO pins.
13:21:13	dom96	Looks like I'll be visiting a local electronics supplies store :P
13:21:43	filwit	no idea what GPIO pins are :-S
13:23:03	dom96	They are pins which can be used for Input or Output and can be controlled by software/
13:23:08	dom96	They are available on the Pi.
13:24:20	filwit	oh cool, so you can make an app (in Nimrod of course) to control your garage door
13:24:39	dom96	yep :P
13:27:36	filwit	do you know if Git branches are case sensitive?
13:28:20	filwit	nevermind i got it
13:28:34	dom96	no clue
13:42:52	filwit	does Nimrod import folder names?
13:43:20	filwit	aka, dir: src/math/vectors.nim
13:43:34	filwit	dirc: src/math/matrix.nim
13:43:42	dom96	Yeah, I think you can do "import "src/math/matrix.nim""
13:43:44	filwit	import src.math
13:43:52	dom96	You can't import a whole directory though
13:44:15	filwit	so I can't import all .nim files under a folder by just stopping at the folder?
13:44:26	filwit	or doing a '.*'?
13:44:32	dom96	You could create a file and put in it all the imports
13:44:36	dom96	and then just include it
13:44:46	filwit	okay, so it's like D then
13:45:09	filwit	I never did understand why you couldn't just import the whole folder like Java... but maybe there's a reason for it
13:47:21	dom96	Seems like it could get confusing.
13:47:28	dom96	If you forget what modules are in a folder.
13:47:37	dom96	And what the modules contain...
13:50:16	filwit	idk, anytime you move code around, you have to change the imports
13:50:33	filwit	which is one benefit of using namespaces like C#/C++
13:50:52	filwit	(though I prefer import/modules personally)
14:04:08	dom96	I'm sure Araq can come up with a better reason than me :P
14:04:37	filwit	oh I'm just complaining for complaining sake really ;-P
14:05:22	dom96	lol
14:05:32	filwit	I can't get this stupid thing to compile... urg
14:05:49	*	dom96 wonders if we could piggyback on the Raspberry Pi's popularity
14:06:04	dom96	What's the problem?
14:06:41	filwit	well I'm copying the code from tests/run/tstringinterp.nim into lib/pure/subexes.nim
14:07:08	filwit	and renaming the functions concate/format to `$&`/`$%`
14:07:34	dom96	right, and?
14:07:45	filwit	but while the test compiles and runs fine, my modified subexes is giving me a Internal Error: no string found
14:07:54	filwit	on this line:
14:08:00	filwit	macro `$&` *(e: expr): expr =
14:08:08	filwit	var args: seq[PNimrodNode] # THIS ONE
14:08:20	filwit	whoops, shit
14:08:23	filwit	wrong line
14:08:27	filwit	this one:
14:08:42	filwit	template ProcessInterpolations(e: expr) =
14:08:43	dom96	Well an Internal Error means you've crashed the compiler...
14:08:49	filwit	var s = e[1].strVal #THIS ONE
14:09:17	filwit	ya that's what I'm guessing, but I'm not sure why i've crashed it
14:09:22	filwit	I'm importing the same things
14:09:34	filwit	it just doesn't like the line
14:09:41	filwit	var s = e[1].strVal
14:09:41	dom96	gist all your code please
14:09:51	filwit	hmmm, k
14:11:04	filwit	https://gist.github.com/3066595
14:11:09	filwit	errors on line 339
14:13:48	dom96	Are you using the latest compiler?
14:14:16	filwit	yes
14:14:22	filwit	just forked and built it
14:14:26	filwit	0.8.15
14:15:05	filwit	it's odd, cause it's working with the test, but not the subexes
14:15:13	filwit	....but I have no idea why...
14:15:19	dom96	Well it compiles for me.
14:15:25	filwit	what?
14:15:29	filwit	what does?
14:15:34	dom96	The file
14:15:42	dom96	You pasted
14:15:49	filwit	you replaced your subexes file?
14:16:11	dom96	Well no. I just saved it as a different file
14:16:26	filwit	I made a test file, which imports subexes and uses the functions
14:16:45	dom96	I see.
14:16:53	filwit	but I'm just copy pasting code from the tstringinterp.nim test which does compile and run
14:16:54	dom96	ok, gist that too then :P
14:16:58	filwit	k
14:18:17	filwit	this doesn't work:
14:18:18	filwit	https://gist.github.com/3066618
14:18:42	filwit	this does work:
14:18:42	filwit	https://gist.github.com/3066620
14:19:42	filwit	the subexes file I'm importing in the first one (the one that doesn't work) is the modified subexes gist I paster originally
14:20:28	filwit	if you notice, the functions after ### --- TEMP --- ### in the subexes file are identical to the ones int the working test source
14:20:41	filwit	It's just copypasta
14:22:12	dom96	hrm
14:22:19	filwit	ya...
14:23:05	dom96	Working on it :)
14:23:45	dom96	I'm pretty sure this is a bug.
14:23:59	filwit	That's what I'm thinking
14:24:07	filwit	I guess I'll wait till Araq gets back
14:24:11	dom96	Some kind of difference between imported module processing and top level code processing
14:24:23	dom96	You can try to fix it yourself if you want
14:24:38	dom96	Bootstrap without -d:release and you'll get a stack trace
14:24:49	filwit	I'm not sure where to begin, it looks like a problem in the core expression tree structure
14:25:03	filwit	oh, okay
14:25:38	filwit	I'm actually getting a warning (as well as an error) about 'concat' being defined but never used
14:25:47	filwit	only in the subexes file thought
14:25:50	filwit	though**
14:25:58	filwit	in the working test, i don't get that warning
14:26:09	dom96	I doubt that has any significance
14:26:17	filwit	ya didn't think it did
14:26:29	filwit	okay, i'll try bootstrapping in debug
14:27:20	filwit	what does 'koch' stand-for/mean anyways?
14:27:27	filwit	German maybe?
14:27:32	dom96	It means cook in German :P
14:27:44	filwit	ah, thought it might be something like that
14:29:59	filwit	what is the order of the trace back? recent is last?
14:30:25	filwit	okay, never mind
14:30:30	filwit	just looking at it I can tell
14:31:21	filwit	looks like there's an assertion failure
14:31:22	dom96	yeah
14:31:36	dom96	The assertion is just so that it crashes and prints a stack trace
14:31:57	dom96	evals.nim(1110) evalMagicOrCall
14:32:04	dom96	That's where the error occurs
14:32:36	filwit	you following along with me, or something?
14:33:00	dom96	nah, had the stack trace in another window, thought I'd help :P
14:33:13	filwit	lol, well thanks for the info
14:34:05	*	dom96 hopes his SD card won't die from all the writes and reads
14:34:18	dom96	Any ideas on how many it can take?
14:34:36	dom96	IIRC they are quite sensitive to many writes
14:34:49	filwit	no idea, sorry
14:34:59	filwit	buy backups :)
14:35:19	dom96	The SD card I got cost me almost as much as the RPI heh.
14:35:27	dom96	So I'm not buying any more :P
14:35:50	filwit	damn, really?
14:35:54	filwit	I thought those where cheap
14:36:56	filwit	I'ved that in places like South America, where the economy isn't as good as here, a copy of Windows is actually (quite a bit) more expensive than here
14:36:59	filwit	which is odd
14:37:36	dom96	yay, Nimrod is compiling.
14:37:45	filwit	nice
14:46:08	dom96	Nimrod Compiler Version 0.8.15 (2012-07-07) [Linux: armv6l]
14:46:10	dom96	w00t
14:47:27	filwit	good work!
14:47:37	dom96	:)
14:47:42	dom96	It's quite slow.
14:48:00	dom96	The CPU isn't the fastest though so I'm not surprised.
14:48:04	filwit	I imagine it's not the fastest machine in the world
14:48:13	dom96	700mhz :)
14:48:37	filwit	plus, Nimrod takes a less direct rout to compile code than... "normal" codegens
14:49:31	dom96	Yeah, it goes through gcc.
14:49:31	filwit	I asked Araq if he ever had plans on making a LLVM backend, but he said it was impossible (or something along those lines)
14:49:37	filwit	I'm not sure why...
14:49:49	dom96	I'm sure it's not impossible./
14:50:10	dom96	Well, maybe there are some features that Nimrod depends on that llvm would make hard to implement
14:50:10	filwit	ya, maybe he mis-understood what I was asking
14:50:21	filwit	like what?
14:50:28	dom96	dunno.
14:50:37	dom96	I'm clueless about LLVM :P
14:51:01	filwit	then how do you know LLVM would make it hard to implement :-V
14:51:41	filwit	anyways, I'm sure there's something
14:51:58	filwit	and it's not important ATM to have uber fast compilation times
14:52:46	filwit	it would be nice to eventually use GCC or LLVM directly, so there's no slow-downs on the parsing side
14:53:24	filwit	but if I remember correctly, most of the performance hit comes from the codegen anyways, so a slightly slower parser/lexer shouldn't make a huge difference
14:54:43	dom96	GCC isn't that slow I don't think.
14:55:05	dom96	And we can use tinycc instead :)
14:56:05	filwit	compared to LLVM, GCC is pretty slow
14:56:15	filwit	not horrible though
14:56:23	filwit	and ya, there are faster ones
14:56:30	filwit	though I've never used TCC
14:56:56	filwit	comparing GCC compile times to C# and DMD though... it's a big difference
14:57:03	filwit	when you have a lot of code
14:57:17	dom96	We could also use clang.
14:58:11	filwit	ya, and like I said, I remember someone's statics before showing that the parser wasn't the big source of slow down
14:58:20	filwit	it's the codegen
14:58:35	filwit	and C compiles much faster than C++
14:59:06	filwit	so parser Nimrod, then parsing C, before codegen probably isn't a big hit
14:59:13	filwit	compared to the codegen itself
15:02:40	dom96	yeah
15:03:10	filwit	anyways, I'm going to head out for a bit
15:03:21	dom96	alright. See you later
15:03:28	filwit	bye
16:03:53	*	Trix[a]r_za is now known as Trixar_za
16:10:23	*	Trixar_za is now known as Trix[a]r_za
18:07:11	*	XAMPP quit (Quit: There is no such thing as coincidence, only the inevitable.)
18:19:02	Araq	back
18:19:26	Araq	filwit: an internal error is a bug yeah ... I'll look into it next week or so ...
18:19:44	Araq	very busy with all the reported bugs and feature requests ...
18:20:10	Araq	and an LLVM backend is far from *impossible*
18:20:35	Araq	but it adds no significant value over the current approach
18:20:54	Araq	and maintaining one more backend is not a small task
18:21:13	Araq	we're talking about 5K lines of complex logic here
18:52:56	filwit	hi Araq
18:53:29	filwit	okay, I was trying to trace the error myself, but I got a bit lost as to what could be causing it
18:53:41	Araq	it's the 'concat' stuff I'm pretty sure
18:53:52	Araq	the warning makes the difference I think
18:54:13	filwit	hm....
18:54:38	Araq	in fact ... macros still leak information
18:54:51	Araq	you can't just export them and expect things to work
18:55:03	filwit	I can gist the stack trace, maybe if you took a look at it you could give me a hint
18:55:06	Araq	the macro constructs a call to 'concat' so that needs to be exported too
18:55:22	Araq	alright stack trace helps
18:56:10	filwit	I did notice that evalAux om evals.nim only handles nkMacroStmt, and no nkMacroExpr
18:56:15	filwit	okay, one sec
18:56:29	Araq	there is no nkMacroExpr I think
18:57:00	filwit	https://gist.github.com/3066618
18:58:08	Araq	oh
18:58:09	filwit	oh, I thought there was..., I thought it might have been and bug born from your work to merge stmt and expr
18:58:35	Araq	lol these internal errors are no bugs
18:58:48	Araq	they should simply be better error messages instead :P
18:58:57	filwit	I see
18:59:04	Araq	you attempt to get the string value out of a node that is no string literal
19:00:03	filwit	it's just odd that it works in an completely isolated case, but fails when it's part of an external lib
19:00:26	Araq	make it output 'renderTree(n)' in evals.nim:1110
19:00:42	Araq	it's not that odd
19:00:45	filwit	k
19:01:16	Araq	as I said, the macro you use builds an AST that contains access to 'concat' which isn't exported
19:01:47	filwit	ohh... that' makes sense now
19:01:55	filwit	I thought that warning might be a clue
19:02:33	filwit	I could simply make that concat function and internal proc of both `$%` and `$&`
19:02:46	Araq	the macro should bind the symbol with a built-in API I think
19:02:54	Araq	but this API doesn't exist yet :-/
19:03:02	Araq	so yeah you have to hack around
19:03:03	dom96	haha, looks like i'm still a total noob at Nimrod :P
19:03:22	filwit	you and me both dom96
19:03:48	filwit	(though you know a lot more than me :-P)
19:04:01	dom96	Well at least you were correct to think that the warning was significant.
19:05:58	filwit	you're right!
19:06:02	filwit	it's official then
19:06:15	filwit	my Nimrod skillz r the gr8test
19:06:46	Araq	macros can easily be confusing ;-)
19:06:56	Araq	in fact, my plan is:
19:07:01	filwit	that concat proc was only used by `$&`
19:07:08	dom96	Araq: Can I commit & push changes to get arm working?
19:07:11	filwit	but it's still not working...
19:07:28	Araq	0.9.0 get integers and closures right
19:07:36	Araq	0.9.2 get templates right
19:07:43	Araq	0.9.4 get macros right
19:08:03	Araq	0.9.6 .. 1.0.0 get term rewriting macros right ;-)
19:08:41	Araq	dom96: no ...
19:08:47	filwit	noble goals, but I hope that somewhere in there the aliasing issue between local variables and Types is addressed
19:08:58	filwit	that's my single biggest annoyance at this point...
19:09:04	dom96	Araq: Why not?
19:09:05	Araq	show the diff please dom96
19:09:15	filwit	since I'm a bit OCD and hate the whole TType/PType thing....
19:09:16	dom96	Fine, don't trust me! :P
19:09:35	dom96	Araq: It's actually kind of weird. The CPU name is armv6l
19:09:39	dom96	Not just 'arm'
19:09:52	Araq	filwit: I didn't list details like that :P
19:10:07	filwit	ahh, cool :-)
19:10:18	dom96	So we will need to add it to platforms for each version I guess
19:10:30	Araq	and the TType PType thing is only annoying if you never used Delphi for years :P
19:10:59	dom96	If someone manages to obtain different machines with differing ARM CPUs.
19:11:08	filwit	ya, never used Delphi at all...
19:11:45	Araq	dom96: the proper way is to adapt the build.sh script to detect any kind of ARM CPU
19:11:57	Araq	*not* make the compiler aware of this mess
19:12:18	dom96	Araq: Right, how should it be done in platform.nim?
19:12:38	Araq	platform.nim already knows ARM I hope?
19:14:22	dom96	yeah, but the name is 'arm' will it detect 'armv6l' as 'arm'?
19:14:33	dom96	Well actually I know the answer to that.
19:14:37	dom96	Because it complained.
19:14:39	dom96	So it doesn't.
19:15:53	Araq	make build.sh convert armv6l -> arm ?
19:16:21	filwit	damn, well IDK what to do about this $%/$& thing... guess I'll just comment it out and put a #TODO on it
19:16:42	filwit	what's the preferred method to block comment? when false:
19:16:43	filwit	?
19:17:04	dom96	Araq: koch doesn't use build.sh how do you expect it to work?
19:17:07	filwit	or should I just remove it and do it again later since it's just copypasta to begin with
19:17:39	Araq	dom96: koch is built with nimrod ...
19:18:02	Araq	and "knows" the CPU it runs on as it's compiled into the koch executable
19:18:08	Araq	it all starts with build.sh ...
19:18:13	dom96	Araq: ok.
19:18:28	Araq	filwit: whatever you feel like
19:18:33	filwit	k
19:18:46	Araq	what's OCD btw?
19:18:59	filwit	Obsessive Compulsive Disorder
19:19:17	Araq	and why can't you do 't: TType' like me? :P
19:19:34	filwit	I don't actually have OCD or anything...
19:19:50	filwit	i don't know how you can do TType stuff
19:19:58	filwit	it's crazy insane man
19:20:29	Araq	hey it's important whether it's value or a reference semantics
19:20:57	Araq	oh right ... you only want reference semantics everywhere right? :P
19:21:04	filwit	no
19:21:14	filwit	but I would like : type Foo = ref object
19:21:24	filwit	to _default_ to reference symantics
19:21:31	filwit	semantics**
19:21:37	Araq	ok
19:21:42	Araq	well no need to argue
19:21:49	Araq	the feature requests have been accepted
19:21:53	filwit	wasn't trying too :P
19:22:01	Araq	but still I wonder:
19:22:26	Araq	proc copy(dest: var TMyObject, src: TMyObject) = ...
19:22:37	Araq	is pretty common, right?
19:22:44	Araq	I mean to use 'dest' and 'src'
19:22:49	filwit	the real reason why I don't like TType/PType is because it's the only 'ugly' thing about Nim, and requires you to purposely mis-name all your types when there's a more elegant solution available
19:23:08	filwit	yes, that's common
19:23:17	Araq	and somehow nobody writes that as:
19:23:27	Araq	proc copy(destMyObject: var TMyObject, srcMyObject: TMyObject) = ...
19:23:52	Araq	so the type is not part of the name as soon as a "better" candidate is available ...
19:24:00	filwit	there's no need to stutter the type name
19:24:24	Araq	which implies you can use 1 letter parameter names for:
19:24:35	Araq	proc p(m: TMyObject)
19:24:42	Araq	and no information is lost ...
19:24:49	Araq	it's perfectly fine style IMHO
19:24:55	Araq	and once you do that
19:25:09	Araq	you can easily name your types without leading T and P ...
19:25:39	filwit	no, not really
19:25:44	filwit	but not because of parameters
19:25:53	filwit	because of local variables
19:25:57	filwit	i've tried
19:26:11	filwit	usually I'll write code like:
19:26:17	filwit	type Foo = object
19:26:19	filwit	...
19:26:23	filwit	proc bar =
19:26:31	filwit	var foo : Foo
19:26:38	filwit	# whoops
19:27:09	Araq	var f: Foo
19:27:14	filwit	the problem is that IF I want to name my types without T/P, then I'm constantly running into conflicts
19:27:47	filwit	yes that works, and I could name it fooLocal, or fooo, or anything else
19:28:06	filwit	but I don't think forcing people to avoid naming conflicts is the best solution
19:28:20	filwit	it would be much more elegant if this simply worked
19:28:50	Araq	it's 3 lines in the compiler :P
19:28:54	Araq	I think
19:29:06	Araq	it will be weird for macros
19:29:20	filwit	3 lines in the compiler? what is?
19:29:34	filwit	:-V
19:29:52	Araq	oh please, you simply need to make type name lookup prefer symbols of kind skType ...
19:30:11	filwit	I'm completely confused....
19:30:35	Araq	I mean: implementing the feature you desparately want
19:30:44	Araq	takes like 3 lines in the compiler
19:30:59	filwit	oh, nice
19:31:17	filwit	why isn't it done yet then? hmmmmm?????!?!
19:31:24	filwit	:-P
19:31:25	Araq	lack of time?
19:31:52	filwit	well shit, if it's that simply, point me in the right direction
19:32:04	filwit	what file is this that only needs 3 lines of modification?
19:33:22	filwit	I feel horribly unproductive today, with my previous attempts to modify the compiler being thorted
19:33:32	Araq	semtypes.nim:187
19:33:39	filwit	perfect, thanks!
19:33:52	Araq	you need to do a lookup that filters
19:34:37	Araq	oh hrm lookups.nim doesn't support that yet :P
19:34:43	Araq	so it's more than 3 lines
19:34:49	Araq	but trivial
19:35:06	filwit	I'll see what I can come up with
19:35:36	Araq	checkout proc SymTabGet*(tab: TSymTab, s: PIdent, filter: TSymKinds): PSym
19:35:54	filwit	k
19:35:59	Araq	lookups.nim needs a proc to access that proc
19:39:04	Araq	dom96: does -d:release work on ARM?
19:40:04	Araq	filwit: btw zahary did some tests recently
19:40:27	Araq	and Visual C++ produces a much faster Nimrod compiler than GCC, LLVM and even Intel C++
19:40:46	Araq	it was 2.7s vs 3.2 vs 3.4 iirc
19:41:05	filwit	hmmm.. that's odd
19:41:34	Araq	which is one reason why I want to stick with the C code gen
19:41:41	filwit	I would like to see actual C++ examples being faster on VC++ than G++
19:42:05	filwit	ya, the C codegen has some nice things
19:42:38	filwit	and like I said, parsing is probably a negligible cost compared to codegen
19:43:02	filwit	so it's not a big productivity issue really
19:43:41	Araq	I have some problems with the "parsing" vs "codegen" distinction :P
19:44:09	Araq	it's really "lexing" -> "parsing" -> "semantic checking" -> "code generation"
19:44:10	filwit	:-)
19:44:26	Araq	and "semantic checking" *is* expensive
19:44:43	Araq	often moreso than code gen
19:44:59	filwit	hmmm... well good to know
19:45:10	Araq	but somehow people don't even mention it :P
19:46:53	Araq	btw Nimrod executes the C compiler in parallel to keep all your cores busy
19:47:21	Araq	but the Nimrod compiler itself can't be parallelized easily
19:47:28	filwit	nice, I noticed Nimrod compiles pretty fast with the nimcache and stuff
19:47:59	Araq	you should try --symbolFiles:on but it's still buggy
19:48:26	filwit	well I'll avoid it for the moment then
19:48:36	filwit	sounds cool though
19:48:57	Araq	but recompile times of 0.1s are nice :P
19:49:30	filwit	nice
19:49:32	filwit	heh, I was thinking about proc parameters the yesterday, and I had a thought I'd like your opinion on (seeing as you know a ton about this stuff)
19:49:48	filwit	(this isn't a feature suggestion, btw, just random thoughts)
19:50:18	filwit	so basically, what if you had "typeless" parameter that looked like weak typed programming
19:50:19	filwit	so:
19:50:33	filwit	proc foo(x, y) =
19:50:41	filwit	x.doSomething()
19:50:57	filwit	var a : int
19:51:00	filwit	a + y
19:51:11	Araq	zahary already implemented that, but I don't know the status
19:51:17	filwit	then, the compiler would simply duck-type the "typeless" params are compile time
19:51:23	Araq	yep
19:51:25	filwit	really?
19:51:28	filwit	that's awesome
19:51:32	Araq	we know clay ;-)
19:51:47	filwit	well I don't, I came up with this independently
19:51:50	filwit	:)
19:52:09	Araq	I also want:
19:52:16	filwit	that's cool though, glad to here that Nimrod will be doing something like this
19:52:30	Araq	proc foo(x: int; y, z; a: bool)
19:52:40	Araq	note the ;
19:52:49	filwit	ya I was just going to ask about the syntax of that issue
19:52:49	Araq	so that some are inferred and some are not
19:53:24	filwit	cool :)
19:54:28	filwit	the ';' could be always used as a general 'end expr' symbol
19:54:32	filwit	var a, b : int
19:54:38	Araq	yep, planned
19:54:39	filwit	a = 1; b = 3
19:54:46	filwit	cool :)
19:54:47	Araq	yes yes
19:54:54	Araq	your proc indentation feature is also easy to do
19:55:10	Araq	only needs changes to parser.nim
19:55:22	filwit	well I'm still struggling with the first problem :P
19:55:23	Araq	and yes it'd be nice if you could help with that
19:55:44	filwit	yes, I would like to be able to help out with compiler stuff
19:55:52	filwit	it's just a bit... complex, atm
19:56:06	filwit	though everything seems organized well so far
19:56:15	Araq	it isn't
19:56:23	Araq	but still bearable
19:57:15	filwit	well, once I change the symbol resolution issue, maybe refactoring some of the code is in order?
19:57:18	filwit	:-)
19:57:24	Araq	no please don't
19:57:29	filwit	damnit...
19:57:56	Araq	I hate it when I don't know where to find my code ...
19:58:12	Araq	that's far worse for my productivity
19:58:39	filwit	okay, I feel ya, what If I just went thought and changed a bunch of TType/PType things?
19:58:54	filwit	<8-D
19:59:03	Araq	I see
19:59:06	filwit	LOL
19:59:15	Araq	yeah I got the joke :P
20:00:46	dom96	Araq: I don't think it does, however I tested it when I didn't yet edit platform.nim. I will try it again.
20:01:03	filwit	man I can't type today... I keep looking back and realizing I've typed things like *thought instead of *through
20:03:22	Araq	"It's been part of DMD2 for a while now. It allows you to do things like:
20:03:24	Araq	ubyte lowbits(int x)
20:03:25	Araq	{
20:03:27	Araq	return x & 7;
20:03:29	Araq	}
20:03:30	Araq	without an explicit cast. The compiler knows that x&7 can safely fit
20:03:32	Araq	inside a single byte."
20:03:33	Araq	argh!
20:03:35	Araq	D already does it
20:03:36	Araq	damn you, D ...
20:03:52	Araq	I thought Nimrod will be original with this feature ...
20:05:13	filwit	lol, nothing wrong with being second
20:05:20	filwit	there's only so many ideas in the world
20:08:05	Araq	oh well
20:08:30	Araq	at least I am smart enough to notice that bitwise or does not adhere to simple interval arithmetic rules
20:08:37	dom96	pff. D. Nimrod's syntax is so much better.
20:08:49	dom96	D doesn't stand a chance.
20:10:14	Araq	and both have no chance against Rust ;-)
20:10:49	filwit	I didn't like Rust for some reason... I forgot why though
20:11:31	filwit	ah, right.. pointer and namespace symbols like '->' and '::'
20:11:38	dom96	Araq: Have some faith.
20:11:41	filwit	was one reason
20:12:03	Araq	faith? against a paid team of compiler devs?
20:12:05	dom96	However I must admit, it does not look good.
20:12:27	filwit	does Rust even have meta programming?
20:12:31	filwit	what's that like?
20:12:32	Araq	which are not as brain dead as to leave out generics from their language?
20:12:56	Araq	afaik Rust's metaprogramming is not advanced yet
20:13:09	filwit	why would you want Generics when you have proper Templates?
20:13:10	Araq	and requires macro invokation with '#'
20:13:31	filwit	someone on the D forums figured out how you can even inherit from template functions
20:13:46	filwit	which was the only pro to Generics, If I remember correctly
20:13:55	dom96	Araq: I saw their roadmap just today. Maybe I shouldn't show you it, might depress you.
20:14:17	Araq	filwit: I'm talking about the mystical "average programmer"
20:14:50	Araq	generics vs. templates is a lost argument for these as they don't care about the difference
20:14:55	filwit	ah.. that fabled creator is only myth and legend ;)
20:15:17	Araq	dom96: show me the roadmap please
20:15:25	dom96	https://github.com/mozilla/rust/wiki/Note-development-roadmap
20:26:01	Araq	interesting
20:26:15	Araq	and they don't even list the features we have planned :P
20:27:07	dom96	It's really unfair that they have mozilla backing them.
20:27:46	dom96	btw filwit any progress on that Nimrod logo mockup?
20:28:02	filwit	honestly, I think their syntax is a bit confusing
20:28:24	filwit	dom96, no, haven't worked on anything Nimrod related in awhile
20:28:29	filwit	but I'll complete it
20:28:35	dom96	Great :D
20:28:45	dom96	I haven't actually used Rust, D, or Go.
20:29:09	dom96	Ever since I found Nimrod I've been using it, heh.
20:29:46	filwit	I've used D and played with Go a few times
20:29:56	filwit	not a fan of Go, but D has some great things
20:30:02	filwit	most of which Nimrod has
20:30:09	filwit	and does better, IMO
20:30:20	dom96	The C-like syntax really pushes me away from those languages.
20:30:20	Araq	ha thanks
20:30:47	filwit	the fact that there's no distinctions between Macro/Template/Proc use is something I think is really great about Nim
20:31:10	filwit	cause reading through code, all you're doing is tracing "function" calls, like in C
20:31:18	filwit	it's just easy to read and understand
20:32:04	filwit	(which is why I'm so against TType/PType stuff, not to bring that up again)
20:32:21	filwit	looking through Rust, it looks like it's got a lot of power
20:32:33	filwit	but I'd rather use D (between the two)
20:32:43	filwit	because D is easier on the eyes
20:32:58	filwit	though Rust's pattern matching is interesting
20:33:45	filwit	dom96: I'm fine with the C like {} syntax
20:34:02	filwit	but one thing I really like about Nimrod is it's case-insensitivity
20:34:18	dom96	The reason Nimrod caught my eye in the first place is its python-like syntax.
20:34:40	dom96	Back then I was really into and I just wanted a python which compiled to C.
20:34:45	filwit	notice on the roadmap their talking about universalizing the capitalization between old and new libs
20:34:46	dom96	*into python
20:35:09	filwit	see, the Python syntax had the opposite effect on me
20:35:22	filwit	I almost passed Nimrod up completely after seeing a code example
20:35:34	filwit	but the feature list on the home page kept me reading
20:35:34	Araq	what?
20:35:55	Araq	you actually like nimrod's case insensitivity?
20:36:01	Araq	interesting :-)
20:36:18	filwit	ya, and the fact that '_' is just their for fluff
20:36:30	filwit	it means I can use other's libs in the style I want
20:36:33	filwit	which I like
20:36:43	Araq	well that was the point :-)
20:37:08	Araq	but would I do it again?
20:37:14	Araq	unlikely ;-)
20:37:20	filwit	lot of problems?
20:37:27	Araq	I would make the compiler enforce the naming convention instead
20:37:33	filwit	it obviously wont work with linking to C and such
20:37:42	dom96	haha.
20:37:44	filwit	lol
20:37:48	dom96	That would certainly make people angry.
20:37:51	filwit	all or nothing eh
20:37:56	Araq	in fact there are suprisingly little problems with C libs
20:38:06	Araq	and Nimrod's case insensitivity
20:38:19	Araq	I was suprised how few clashes it produces :D
20:38:34	Araq	no, I still like the insensitivity way
20:38:48	Araq	the reason why I would do it differently has to do with *people* :P
20:38:48	filwit	yes, I'm glad you didn't enforce a standard
20:39:12	Araq	because many people really dislike it
20:39:15	filwit	cause if it was foo_bar() I probably wouldn't have read any further :P
20:39:39	filwit	really? others don't like the case insensitivity?
20:39:52	Araq	yeah
20:39:55	Araq	many dislike it
20:39:55	filwit	I told my brother about it, and he was against the idea... but he usually is
20:40:02	dom96	It's always the first thing they complain about
20:40:03	filwit	mostly because he does this:
20:40:08	filwit	class Foo {
20:40:22	filwit	private in bar;
20:40:31	filwit	public int bar() {...}
20:40:32	filwit	}
20:40:38	filwit	shit
20:40:41	filwit	should be:
20:40:48	filwit	public int Bar() { ...}
20:41:12	filwit	basically all public members are capitalized (C#), and privates are lower camelCase
20:41:33	Araq	privates are _thisWay in C# :P
20:41:41	filwit	usually, I know
20:41:57	filwit	but we don't do that in our SDK
20:41:57	Araq	public Foo Foo { get; set; }
20:42:19	Araq	C#'s style guidelines don't make any sense anyway
20:42:36	filwit	meh, I like them well enough
20:42:38	Araq	public Foo Foo { get; set; } // doesn't compile
20:43:26	filwit	ya, I was always torn between PascalCase and camelCase
20:43:56	filwit	in one way, PascalCase is more consistent, but in other camelCase has nice distinction between types/locals
20:43:59	dom96	TIL that's called PascalCase
20:44:29	filwit	I usually use camelCase, but Reign SDK is PascalCase, so I'm use to both
20:45:05	filwit	I usually just use whatever the language recommends
20:45:12	Araq	at work I "program" quite some SQL :-)
20:45:31	Araq	it's soooo convenient to not have to care about this crap in a REPL
20:45:46	filwit	except in the case of Nimrod, where I just complain about every feature until you agree to do it just to shut me up
20:45:59	filwit	;D
20:46:44	Araq	I don't mind :P
20:47:46	Araq	as I know time also deals with these things; nobody moans about time_t in C :P
20:48:12	Araq	time_t is from the gods and if you don't like it it's *your* problem
20:48:23	Araq	in fact
20:48:41	Araq	everything in C is the *programmer's* fault XD
20:48:48	filwit	lol
20:49:15	filwit	people don't complain about C, because to start down that path is to enter insanity
20:49:38	Araq	people worship C and UNIX
20:49:46	filwit	I know
20:50:13	dom96	and vim
20:50:24	dom96	Don't forget about vim :P
20:50:41	Araq	no! emacs!
20:50:49	filwit	okay, I understand how C is popular, but I never understood Vim's keyboard shortcuts
20:50:59	filwit	'h' as up?
20:51:06	dom96	What you mean that OS?
20:51:06	filwit	and 'l' and down?
20:51:26	dom96	I can run quake in my emacs, it's obviously far better than vim!
20:51:27	filwit	but granted, I haven't given Vim much time of day
20:52:11	Araq	well every other widget in the OS uses the common cursor keys
20:52:12	dom96	yes, why make arrow keys work when you can use letters to move the cursor!
20:52:27	Araq	so it's unproductive to learn Vim
20:52:39	dom96	They could have at least used something like WASD
20:52:55	Araq	dom96: 'W' didn't exist back then
20:53:05	Araq	the letter 'W' was invented much later ...
20:53:25	dom96	oh, did the ancient Mayans invent vim?
20:53:38	Araq	yep :P
20:53:49	filwit	that explains it
20:54:44	dom96	Some poor calendar maker must have forgotten how to move the cursor and just gave up on finishing the calendar.
20:55:11	filwit	the mystery is solved
20:55:46	filwit	maybe at the end of the year, all Vim software will spontaneously erase itself
20:56:00	dom96	That would be great. lol.
20:56:12	filwit	and all the Vim folks will end their lives thinking it's the end of the world
20:58:29	filwit	looks like they found the Higgs boson
20:58:38	Araq	yeah
20:58:47	Araq	unfortunately
20:58:57	filwit	you had a better theory?
20:58:57	Araq	I'd have preferred if they hadn't found it
20:59:00	dom96	Not sure what benefit that really brings.
20:59:02	filwit	lol
20:59:03	Araq	lol no
20:59:19	dom96	He wanted to find it himself.
20:59:21	Araq	but the standard theory is so ugly
20:59:39	dom96	Using the Nimrod hadron collider simulator.
20:59:42	Araq	it'd be nicer if something would prove it wrong
21:00:05	Araq	http://www.osnews.com/story/25556 btw still my favourite
21:00:14	filwit	dom96: no one knows yet, but considering the research into quantum physics years ago now enables our computers today... I would say it's pretty cool
21:00:47	filwit	Araq: I don't really know all that math jumbo...
21:01:18	filwit	new standard theory:
21:01:35	filwit	proc main : {.magic.}
21:02:02	Araq	"The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things," Landley explains, "It stopped making any sense before Linux was ever invented, for multiple reasons." XD
21:18:53	*	XAMPP joined #nimrod
21:22:11	dom96	Araq: Do you know much about the longevity of SD cards?
21:22:27	Araq	SSD?
21:23:36	dom96	No. Secure Digital: http://en.wikipedia.org/wiki/Secure_Digital
21:26:41	Araq	I dunno
21:26:49	Araq	I would be careful with it ;-)
21:27:22	Araq	as I've seen quite some SSD break when you're doing many writes
21:27:53	Araq	SSD sounds similar to SD so it should be similar for these :-)
21:28:15	Araq	that doesn't really make much sense
21:28:32	Araq	but it's interesting to notice how one's own brain "works"
21:29:20	dom96	hrm? What doesn't make sense?
21:30:35	Araq	read it again
21:36:33	dom96	i see. Well they are quite similar.
21:36:38	dom96	Both use flash storage.
21:36:52	Araq	yeah I noticed that later too
21:36:55	*	Trix[a]r_za is now known as Trixar_za
21:45:15	Trixar_za	filwit really does have a one track mind, hey?
21:46:11	filwit	eh?
21:46:27	Trixar_za	The last 3 times I've seen you talk, it's been about factories
21:46:28	Trixar_za	:P
21:46:41	Trixar_za	And how they're superior
21:46:53	filwit	oh, lol
21:47:03	filwit	I was actually arguing in favor of Constructors before
21:47:17	filwit	but yes, it's been an on-going discussion
21:47:25	Trixar_za	lol, shows you how I have half-read stuff :P
21:47:28	Araq	I was arguing in favor of factories
21:47:43	Araq	though I don't really like them XD
21:47:52	filwit	now I'm in favor of Factories (applied to Types)
21:47:59	Trixar_za	Clearly I side with Araq - mostly because he has the cookies
21:48:04	filwit	so, var foo = Foo.new(...)
21:48:21	dom96	Araq has cookies?
21:48:27	filwit	oh, well that's understandable... because of the cookies
21:48:31	Araq	if you need a factory, you want to abstract a type hierachy away
21:48:35	dom96	How do I not know of this!?
21:48:46	Araq	which leads to the question:
21:48:57	Araq	why have the type hierachy at all in the first place?
21:49:07	Araq	use a sum type instead
21:49:20	Araq	however, unfortunately; it can't always be avoided
21:49:42	filwit	I think type hierarchy is logical
21:49:50	filwit	we sort of classify things that way naturally
21:50:00	filwit	but idk, whatever works best
21:50:17	Araq	hierarchies suck IMO ;-)
21:50:31	Araq	System.IO.Text.FileReader
21:50:44	Trixar_za	Ah, I was just about to ask if it has to do with that
21:50:47	Trixar_za	:P
21:50:54	filwit	what's wrong with that?
21:51:00	Araq	System.Properties.Settings.Argh
21:51:10	Araq	it's arbitrary
21:51:13	filwit	at least you know where things are coming from
21:51:16	Araq	that's wrong with it
21:51:27	Araq	it's bureaucratic too
21:51:38	Trixar_za	Like with python: self.wrap(string.str()).split()
21:51:41	Araq	why not Universe.System.IO?
21:51:48	Araq	why not Multiverse.Universe.System.IO?
21:51:53	filwit	because we program on computers?
21:51:58	filwit	and not universes
21:52:04	Araq	why not Settings.Properties?
21:52:13	Araq	what's the difference between them anyway?
21:52:19	filwit	that's acceptable
21:52:32	Trixar_za	oh right and don't forget self.wrap(string.str()).time.sleep(10)
21:52:48	filwit	I'm just in favor of understanding over abbreviation
21:53:09	Trixar_za	Actually that's all bad examples from me ;P
21:53:13	filwit	if I can't understand where things are coming from, it's hard to understand the structure... unless I wrote it to begin with
21:53:31	Araq	it's all coming from .NET :P
21:53:32	filwit	that's why hierarchy classification is, IMO, good
21:54:36	Trixar_za	md5sum = hashlib.md5(title+desc).hexdigest()
21:54:42	Trixar_za	^--- real life example
21:56:10	Trixar_za	Well, made a little pretty of course
21:56:17	Trixar_za	Otherwise it will be one hell of a long line
21:57:01	dom96	You can import things from directories in Nimrod can't you? i.e. import "Package/module"
21:57:07	dom96	As long as that is possible I am happy.
21:57:55	dom96	Because if you have large libraries you want to have modules with name like 'types.nim'
21:58:12	dom96	and if you want to use multiple libraries these would clash without putting them into their own dirs.
21:58:36	dom96	Well I guess you could always just name them: LibraryTypes.nim
21:59:07	Trixar_za	md5sum = hashlib.md5(((item.title+item.description).strip("Live Scores: ").replace("#", "")).encode("utf-8")).hexdigest()
21:59:10	Trixar_za	I was bored
21:59:22	Trixar_za	This is why you shouldn't write one liners in Python
21:59:22	Trixar_za	:P
22:00:03	dom96	Trixar_za: Were you trying to obfuscate your code at the same time as writing it?
22:00:47	Trixar_za	Actually I'm using the md5sum to keep track of the rss feeds the bot has shown
22:00:51	Trixar_za	Doesn't always work
22:01:03	Trixar_za	Mostly because python's hashlib sucks by design
22:01:42	Trixar_za	feedparser rocks though
22:04:21	Trixar_za	Which reminds me, how does error handling work in Nimrod?
22:05:02	Araq	exceptions or return values
22:05:15	Araq	mostly exceptions
22:05:34	Araq	but thanks to 'discard' return values are possible too
22:10:19	Trixar_za	Oh yeah, discard :P
22:11:01	filwit	is there a reason you set things to nil in Nimrod on initialization?
22:11:07	filwit	var ident: PIdent = nil
22:11:19	filwit	isn't it defaultly nil?
22:12:27	Araq	yeah I'm just more explicit sometimes
22:12:35	filwit	okay, just woundering
22:12:38	filwit	wondering**
22:12:44	Araq	plus most of the code has been translated from Delphi :P
22:12:57	Araq	and Delphi has no implicit initialization
22:12:58	filwit	it was originally written in Delphi?
22:13:04	Araq	yeah
22:13:13	filwit	interesting
22:13:24	Araq	well ... the common subset of Delphi and Nimrod, in fact
22:13:36	dom96	I thought it was pascal?
22:13:46	dom96	Is there a big difference between the two?
22:13:47	Araq	there is no meaningful difference, dom96
22:13:51	dom96	i see
22:16:40	Araq	Trixar_za: http://www.youtube.com/watch?v=feAlOzra7LQ&feature=related
22:18:41	Trixar_za	One Nipple "AhAhAh"
22:20:52	filwit	reminds me of Dave Chappelle, lol
22:20:57	filwit	http://www.youtube.com/watch?v=xCbU_11hx8Y
22:23:03	Trixar_za	Mind you, I forgot about the Japanese version of Dragonball featuring Goku finding out the Bulma lacks a penis and balls
22:23:35	Trixar_za	Clearly the Americans can't deal with jokes like that
22:23:36	Trixar_za	:p
22:24:18	Araq	ugh Dave Chappelle is too hard to understand for me ;-)
22:26:36	filwit	lol
22:27:52	filwit	I've seen that DragonBall clip before, Trixar_za
22:49:11	dom96	Araq: https://gist.github.com/481a029fb383ed36dd14
22:50:36	Araq	looks good dom96
22:52:28	dom96	alright.
23:43:03	Araq	good night guys
23:43:09	filwit	later
23:43:44	filwit	someone just logged into my gmail from Tiawan
23:43:49	filwit	:-S
23:51:14	*	SchalaZeal joined #nimrod
23:52:33	SchalaZeal	I just noticed support for ARM and... well... thing is if ARM is going to be supported, I really recommend making a proper cross compiler if so.