<<27-11-2012>>

---

00:33:29	*	q66 quit (Quit: Quit)
00:33:34	*	Trix[a]r_za is now known as Trixar_za
01:22:11	*	Trixar_za is now known as Trix[a]r_za
05:16:36	*	XAMPP quit (Read error: Connection reset by peer)
11:50:54	*	Trix[a]r_za is now known as Trixar_za
12:08:55	*	Araq_ joined #nimrod
12:15:07	*	Araq_ quit (Quit: ChatZilla 0.9.89 [Firefox 16.0.2/20121024073032])
13:07:10	*	q66 joined #nimrod
13:38:55	*	FreeArtMan joined #nimrod
14:01:08	*	apriori| joined #nimrod
14:01:12	apriori|	hi guys
14:01:23	apriori|	for an array constructor, is it possible to declare the element type?
14:01:32	apriori|	something like [ 0, 1, 3 ]:char ?
14:03:14	fowl	apriori|: [char(0), 1, 3]
14:07:09	*	apriori|| joined #nimrod
14:07:21	*	apriori| quit (Ping timeout: 244 seconds)
14:10:36	apriori||	fowl: not working
14:10:44	apriori||	it will then complain about element 2 not matching the type
14:11:13	apriori||	seems like every element would need to be a proper char literal :/
14:12:40	fowl	o.. i thought it worked before
14:12:42	fowl	>_>
14:18:33	*	apriori|| quit (Ping timeout: 244 seconds)
14:19:05	*	apriori|| joined #nimrod
14:19:39	fowl	apriori||: https://gist.github.com/4154437 :>
14:21:22	apriori||	fowl: you are insane :P
14:27:20	*	apriori|| quit (Ping timeout: 244 seconds)
14:39:35	*	apriori|| joined #nimrod
15:50:41	*	apriori|| quit (Ping timeout: 244 seconds)
16:09:54	*	apriori|| joined #nimrod
16:28:48	dom96	I've tried this: array[0..2, char]([0,1,3])
16:28:52	dom96	Sadly, it does not work.
16:51:06	*	FreeArtMan quit (Ping timeout: 264 seconds)
16:51:41	*	FreeArtMan joined #nimrod
16:53:21	apriori||	dom96: fowls solution worked...
16:53:30	apriori||	although.. something like that should really be available in the language
16:53:39	dom96	yes, I agree.
16:53:42	apriori||	other example... can we specify the basetype of an enum?
16:53:57	dom96	Not as far as I know.
16:54:02	apriori||	hrm
16:54:21	apriori||	and..well, so far I'm not that happy with arithmetics involving chars and ints
16:54:37	apriori||	something like auto-widening should be possible and also include char
16:56:18	apriori||	and, something like this doesn't quite work:
16:56:34	apriori||	var bla:int32 = someValue
16:56:46	apriori||	type SomeEnum = enum
16:56:58	apriori||	someEnumVal = 0x0123'i32
16:57:03	apriori||	bla and someEnumVal
16:57:14	apriori||	or bla and SomeEnum.someEnumVal
16:57:20	fowl	apriori||: use a converter toi32*(some: enum): int32 = int32(some)
16:57:39	apriori||	I know, Araq would say, use a bit set.. but this is a mixed case.. a bit set (flagging) + some other values not covered by the enum
16:57:59	apriori||	fowl: I thought about converters, too, but there seem to be cases in which they're just ignored
16:58:26	apriori||	e.g., when trying to use a char code as an index in array access
16:58:51	apriori||	fowl: and that converter shouldn't be necessary, if the basetype of the enum matches
17:03:05	fowl	tr00
17:39:28	*	apriori|| quit (Quit: Konversation terminated!)
18:21:46	Araq	er ... you're all wrong :P
18:22:14	dom96	That's nice to hear
18:22:19	Araq	[ '\0', '\1', '\2']
18:22:31	Araq	if too verbose use a template/macro
18:22:57	Araq	and there is a way to set the enum's basetype via the .size pragma
18:23:17	Araq	and there are no implicit conversions because of this thing called "type safety" ...
18:23:37	Araq	you know, the feature which actually improves productivity over assembler ...
18:34:30	Araq	aprioria should learn to use 'const' instead of 'enum' ... Nimrod is not D ...
18:36:57	dom96	hrm, interesting. Is it convention to use 'put' for setting a value for a key?
18:37:51	Araq	yeah or []=
18:38:00	Araq	but []= is more like 'update'
18:38:23	dom96	ok
18:48:56	*	apriori_ joined #nimrod
18:50:29	Araq	hi apriori_, read the logs
18:51:11	apriori_	on it
18:51:12	Araq	sorry for the tone, was an annoying day
18:52:05	apriori_	Araq: no problem.. got used to it :P
18:52:28	apriori_	anyway... I prefer to use enum to "group" constants.. at least I think thats one of its purposes
18:52:53	Araq	but it's not
18:52:59	Araq	it creates a new type
18:53:06	apriori_	well, yeah, I know
18:53:11	Araq	the underlying integer type is mostly an implementation detail
18:53:35	apriori_	but.. in what way is implicitly converting (in one direction) to the basetype type unsafe?
18:54:11	Araq	well the fewer types you have the more type unsafe your code is
18:54:25	Araq	python for instance has only 1 type
18:54:58	apriori_	well, maybe a matter of taste..
18:55:02	Araq	implicit conversions weaken the type system
18:55:17	Araq	proc p(x: int; e: someenum)
18:55:24	Araq	p(1, 0) # really?
18:55:31	Araq	maybe you meant:
18:55:35	Araq	p(0, 1)
18:55:47	apriori_	but, I dont only care for types to be a value constraint but also that types may share a representation.. in which case it makes no sense to me, that e.g. the named implicit conversion does not work (at least in the named direction)
18:56:18	reactormonk	Araq, scala uses implicits for kinda monkey-patching
18:56:23	apriori_	because, it will result in tons of typecasts in quite common situations
18:56:27	Araq	what is a "named implicit" conversion?
18:57:35	apriori_	Araq: I mean the enum with some base type T -> T conversion
18:58:02	Araq	well you a converter to get that (yeah I know it's buggy)
18:58:17	apriori_	yup, converters seem indeed to be buggy
18:58:17	Araq	but if you want that, why have an enum in the first place?
18:58:29	Araq	'const' introduces a section for a reason
18:58:32	apriori_	as already mentioned.. because of the grouping of constants
18:58:57	apriori_	yeah.. as said.. .matter of taste.. or matter of "getting used to"
18:59:06	apriori_	enum is definetly used differently in other languages
18:59:25	Araq	well I'd argue it's completely broken in C-like languages
18:59:39	Araq	and all the others do it like Nimrod does
19:01:00	apriori_	well, maybe
19:01:46	apriori_	another thing feeling somehow strange (although it _might_ even make sense) is that char may not be used for array.[]
19:02:03	Araq	but it can:
19:02:23	Araq	type tarray = array[char, int]
19:02:32	Araq	a['a'] # perfectly fine then
19:02:57	Araq	maybe you need to read about nimrod's notion of ordinal types
19:03:15	Araq	you can even do:
19:03:15	apriori_	well, that might work...
19:03:26	apriori_	but I can say, you get into weird mixed cases in OS dev
19:03:30	Araq	type tarray = array['A'..'Z', int]
19:03:41	apriori_	which inherently shows how broken some stuff even is...
19:04:04	apriori_	yeah, I got that
19:04:51	apriori_	in OS dev though, one got really mixed up semantics of e.g. the ascii codes for the keyboard
19:05:48	apriori_	depending on the state, the fetched code is an offset in one of 5 tables
19:05:56	*	XAMPP joined #nimrod
19:06:54	Araq	yeah you end up with stuff like const upperA = int32('A') in the X11 interfaces
19:07:58	Araq	but *shrug* a key press 'a' is not the same as the character 'a' anyway
19:08:16	apriori_	yup
19:08:26	Araq	when I press TAB I don't want to produce \t :P
19:08:39	apriori_	the issue really seems to be with the design of this keyboard controller stuff, in the os designed by my professor
19:10:36	apriori_	btw.. some random bullshit in hardware design:
19:10:40	apriori_	(cast[ptr uint16](0x472))[] = 0x1234
19:10:50	apriori_	this tells the bios the following reboot was "intentional"
19:11:19	apriori_	and hardware stuff is full of such "magic" constants
19:11:36	Araq	yeah, but what would be the alternative?
19:12:05	apriori_	well.. a little bit more structure, maybe.. for such flags
19:12:26	apriori_	the 0x472 feels really random
19:13:00	Araq	but any mapping to a binary number is arbitrary
19:13:02	apriori_	and it's still funny, that the keyboard controller does the actual reboot
19:13:24	Araq	it feels random because it is random ;-)
19:13:32	apriori_	yeah, maybe...
19:13:38	Araq	maybe you'd prefer 0xCAFEBABE?
19:13:42	apriori_	^^
19:14:16	apriori_	or the solaris style: "0xdefec8ed"
19:17:10	Araq	btw is anybody on windows?
19:17:26	Araq	issue #263 looks troublesome
19:20:33	*	gradha joined #nimrod
19:23:10	apriori_	Araq: btw, one thing I also like, when you use enums to group constants...
19:23:31	apriori_	you can qualify their name with EnumName.ValueName.. which I think, often improves readability
19:23:40	apriori_	and gets rid of usual prefixed stuff
19:23:59	Araq	I prefer the prefixes ;-)
19:24:08	Araq	but you can get that with .pure enums
19:24:30	apriori_	huh? get what?
19:26:27	dom96	Araq: Seems most of the docs for the osproc module are missing, doc2 bug?
19:26:47	Araq	the compiler enforces typ.value then, apriori_
19:26:53	apriori_	Araq: ok
19:27:07	Araq	dom96: hrm yeah quite possible
19:28:55	Araq	I consider enumName.valueName annoyingly verbose, but this 'std.array.array' stuff is worse ;-)
19:29:15	apriori_	it might be verbose
19:29:18	apriori_	but its precise...
19:29:36	apriori_	I prefer that, for names, which might be used more often...
19:30:53	Araq	I never know where to find anything in .NET ... System.Diagnostics.Process? wtf?
19:31:19	Araq	fortunately the IDE mitigates the problem
19:31:20	apriori_	^^
19:35:48	Araq	// Get the application configuration file.
19:35:49	Araq	System.Configuration.Configuration config =
19:35:51	Araq	ConfigurationManager.OpenExeConfiguration(
19:35:52	Araq	ConfigurationUserLevel.None);
19:36:43	Araq	or my new favorite:
19:37:04	Araq	System.Configuration.ConfigurationSettings.AppSettings :P
19:37:11	apriori_	Araq: I didnt say I always prefer qualified names..
19:37:18	Araq	yeah sure
19:37:23	apriori_	just for "random constants" whose name might be used more often
19:37:42	Araq	no, might *not* be used often
19:37:49	apriori_	say, one got an enum for operations.. and one is called something very commonly used as "start"
19:38:04	Araq	if it's used often, the verbosity becomes annoying
19:42:01	dom96	hrm, are the following paths not equivalent? "/home/dom/" "/home/dom"
19:42:52	gradha	there might be a difference if dom is a symlink, the former "dereferences" it, the latter points to the symlink
19:42:57	dom96	I suppose the former is said to refer to a directory, whereas the latter to a file.
19:44:13	*	FreeArtMan quit (Read error: Operation timed out)
19:44:24	dom96	in that case shouldn't splitFile("/home/dom/file").dir be "/home/dom/"?
19:44:43	Araq	perhaps
19:44:55	Araq	but code would break :P
19:45:20	Araq	and the trailing / is subtle
19:45:24	gradha	AFAIK the convention is to never have an API return a path with a trailing path separator
19:45:39	Araq	yeah
19:45:52	Araq	brb
19:46:17	dom96	alright
19:46:47	gradha	also, to know the difference in that case you would need to stat the path previously, which is slower, and might be problematic in itself
19:47:20	gradha	usually you are just dealing with strings, which ignore symlinks and their implementation
19:48:32	gradha	I've seen programs dereference the parent directory through "..", but that is even more problematic
19:48:48	gradha	if you just followed a symlink, going "back" might give you a totally different path
19:50:37	dom96	Thankfully I think I should be fine without resolving symlinks.
19:51:49	gradha	usually you only have to take them into consideration if you are writing some sort of recursive fs tree algorithm due to cycles
19:55:13	*	Trixar_za is now known as Trix[a]r_za
20:06:45	*	apriori_ quit (Ping timeout: 255 seconds)
20:09:40	gradha	having a prototype like this proc openDatabase*(path: string): TDbConn {.cdecl, exportc.} =
20:09:50	gradha	creates a weird exportation naming problem
20:10:11	gradha	due to the TDbConn not marked with {.exportc.} nimrod generates a random name
20:10:25	gradha	I get N_CDECL(tsqlite371300*, openDatabase)(NimStringDesc* path);
20:11:18	gradha	I wonder about the guarantees of the naming for tsqlite371300, maybe on a different machine the source would not work?
20:14:31	Araq	hu?
20:16:05	Araq	in the header that would be something like:
20:16:19	Araq	typedef struct tsqlite371300 tsqlite371300;
20:16:27	Araq	how is that machine dependent?
20:16:28	gradha	yes
20:16:41	gradha	well, where does that number come from? is it random generated?
20:16:51	Araq	it's a global ID
20:17:09	Araq	which however can change between compilation runs should you ever change something ...
20:17:26	gradha	indeed, so it can't be used reliably
20:17:33	Araq	so yeah, exporting the type explicitly is a good idea
20:18:03	gradha	so it's time to mark all nimrod types as exportc just in case? seems a PITA
20:18:17	Araq	why all? only the exported ones ...
20:18:37	Araq	btw you can now 'push exportc: "prefix$1" '
20:19:16	gradha	wouldn't it make sense then to have nimrod exportc automatically all types marked with *?
20:20:04	Araq	no
20:20:21	Araq	I dislike these conflations
20:20:45	Araq	otherwise you would __dllexport those identifiers too in DLL generation, I suppose?
20:20:53	Araq	for "convenience" ...
20:21:54	Araq	the export marker * is not a stable property anyway, often I end up exporting stuff only for some single other module
20:24:20	gradha	say module a defines a type, and module b imports a, can module b "re-mark" a's type with exportc?
20:25:16	gradha	or in other words, can I mark types with explicit exportc even if they originally didn't?
20:25:46	gradha	AFAICS it's just to have a stable name during C exportation
20:36:48	Araq	well you could 'include' a to hijack it
20:37:01	Araq	the problem with a stable name is that's hard to generate one in general
20:37:17	Araq	and I'm more concerned about accidental name clashes
20:37:34	Araq	especially since C has no namespaces
20:37:40	gradha	I tried creating an alias for the type but nimrod still uses the "deepest" type, so my renamed alias exportc is ignored
20:38:01	Araq	these type aliases are a pita to handle in the compiler
20:38:24	Araq	"what do you mean the types are identical but one has some other external identifier?"
20:38:49	Araq	we should get rid of them instead of embracing them
20:48:18	Araq	argh strange connection problems
20:48:49	*	Vladar joined #nimrod
20:50:57	gradha	wrt to the "convenience" of exporting identifiers, it is not so much for convenience as for situations where a module in nimrod doesn't mark a type with exportc (say db_sqlite), then you are stuck with random names which can change from version to version and can't use the type in C code directly. Maybe in the future somebody will be bitten by this, when nimrod is so popular and successful everybody wants to interface with it
20:52:09	Araq	maybe we will have it fixed by then :P
20:52:41	Araq	it's not hard to write a patch script to fix the generated header though
20:53:03	Araq	but I know, I know, programmers don't ever program these days ...
20:53:24	gradha	in my case I've decided to avoid the whole situation creating another layer on top, layers upon layers, of layers upon layers.
20:53:31	gradha	aka layer.layer.layer.layer.hello
20:54:04	gradha	what are CPU cycles for if you can't enjoy them
20:54:35	Araq	;-)
20:56:50	gradha	ah, what was the cake name for this anti-pattern of layers
20:57:31	Araq	lasagne?
20:57:50	gradha	lasagne is a cake were you live? wow! I want that
20:58:19	Araq	ha ha, very funny
20:58:46	gradha	in spanish the cake is milhojas, let's see if google translates that
20:59:19	gradha	hmm.. strudel?
20:59:45	gradha	nah, that's from northern europe
20:59:52	gradha	milhojas is from italy I think
21:01:07	gradha	ok, this is the closest I've gotten http://en.wikipedia.org/wiki/Mille-feuille
21:01:15	gradha	won't search more, I'm salivating too much
21:14:53	Araq	so ... if we have:
21:15:01	Araq	from module import * except a, b
21:15:08	Araq	and not:
21:15:12	Araq	from module import *
21:15:23	Araq	people will complain endlessly, right?
21:15:33	Araq	from module import *
21:15:36	Araq	is the same as:
21:15:39	Araq	import module
21:16:26	gradha	is the except to avoid having two conflicting names in the same namespace and to avoid having to use module.thingy?
21:16:38	Araq	yep
21:17:03	Araq	import module except a, b
21:17:10	Araq	is maybe a better solution
21:17:23	Araq	the * currently has no meaning in imports
21:17:35	gradha	can you do in nimrod "import module; something = module.something"?
21:18:01	Araq	no
21:18:14	Araq	it's often requested, but somewhat hard to implement
21:18:45	Araq	but a template can provide this feature mostly
21:20:02	gradha	I like the import module except a, b, despite having the concept of layer.layer.layer.layer.layer integrated deep inside of me
21:20:46	Araq	really? I thought you've programmed in objective C :P
21:21:26	gradha	unfortunately I also have to do java
21:21:50	gradha	see how popular java is that obj-c adopted the dot syntax
21:22:11	Araq	did it?
21:22:23	gradha	instead of [obj method] you can do obj.method
21:22:30	Araq	since when?
21:22:37	gradha	like objc 2.0
21:22:49	Araq	intesting, didn't know that
21:23:23	Araq	that makes 'importobjc' superfluous, right?
21:23:32	gradha	it makes properties more user-friendly to people coming from other languages
21:23:49	Araq	oh so it's only for properties?
21:23:57	Araq	no obj.method(a, b) ?
21:24:15	*	apriori_ joined #nimrod
21:24:16	gradha	nope
21:24:28	Araq	well Java has no properties :P
21:24:36	Araq	so it copied C# :P
21:25:11	gradha	objc "properties" are just syntax sugar for the compiler creating setters/getters for you
21:25:21	gradha	it's still all messages down below
21:25:48	gradha	when you write obj.property that translates to [objc property]
21:26:04	Araq	yeah got it
21:26:04	gradha	if you write obj.property = 4, that translates to [obj setProperty:4]
21:26:16	gradha	that's why it doesn't work with more parameters
21:27:25	Araq	apriori_: 'from module import * except a, b' or 'import module except a,b ' ?
21:27:42	Araq	Vladar: same question
21:27:46	Araq	dom96: same question
21:29:06	dom96	hrm, hard decision.
21:29:35	dom96	The former is nicer to read, the latter is more concise.
21:29:47	Araq	well you better hurry, I'm implementing it
21:30:54	Vladar	Araq, I like second more
21:31:40	dom96	'import module excluding a,b'
21:31:46	Araq	I could also support 'import path.module' but then people will become confused when it wouldn't work elsewhere
21:32:18	apriori_	hm...
21:32:20	apriori_	prefering 2nd
21:32:27	Araq	I won't add 'excluding' as a keyword
21:32:30	apriori_	but one should get rid of that string literal variant
21:32:41	Araq	I know you dislike it
21:32:42	apriori_	or enforce string literals throughout.. I just think its inconsistent
21:33:10	Araq	what about: 'import path/module' then?
21:33:54	dom96	and then will you allow 'import ../path/module' too? :P
21:34:11	Vladar	yeah, that would be better, cause you can have dots in the name itself
21:34:14	apriori_	Araq: ok for me
21:34:24	Araq	well it does parse as an expression, dom96, so why not
21:34:50	Araq	you can have dots in the name? that's news for me ...
21:35:22	Vladar	i mean, directory structure
21:35:41	Araq	ok, so it's 'import module except ...', good
21:35:49	Araq	and quite consistent
21:42:36	gradha	how do I convert from cstring to string? casting is not working
21:42:43	Araq	$
21:43:10	gradha	thanks
21:49:22	Araq	# module A
21:49:47	Araq	template fakeMod: expr = [B, C]
21:49:54	Araq	# module Z:
21:50:01	Araq	import A, fakeMod
21:50:04	Araq	--> produces
21:50:09	Araq	import A, B, C
21:50:25	Araq	should we allow these things?
21:50:35	Araq	fowl would love them I suppose
21:50:49	dom96	Maybe only in a separate import statement?
21:51:04	dom96	Also, only when the template is exported :P
21:51:16	Araq	if we allow for fakes me may as well do it properly ;-)
21:51:23	Araq	(yeah, missed the *)
21:52:08	dom96	hrm, this could allow for some nice things for babel.
21:53:50	dom96	Feels like magic though. Might confuse users no?
21:54:08	Araq	sure
21:55:40	fowl	dom96: i think aporia cut off my custom command
21:55:59	fowl	$findExe(nimrod) c --path: does me no good :<
21:57:24	Araq	fowl: I'd like your opinion on these 'import' features
21:57:30	dom96	fowl: Missing a $#?
21:57:50	dom96	'$findExe(nimrod) c --path:... $#'
21:57:53	gradha	Araq: shouldn't nimrod export procs with non var parameters as const?
21:58:52	dom96	fowl: Do you mean that it was reloaded incorrectly after restarting aporia?
21:58:58	Araq	nimrod doesn't like C++'s const
21:59:04	fowl	dom96: i think so
21:59:08	Araq	and mostly pretends it doesn't exist
21:59:19	fowl	Araq: the import stuff sounds useful
22:00:30	fowl	it would be useful if in c++, let declared things as const
22:01:01	Araq	we need to do something about 'const', yes
22:01:10	Araq	I'm not sure what though
22:01:12	fowl	apparently if a function returns const you can't assign it to a non-const
22:01:32	dom96	fowl: Works for me.
22:02:00	dom96	fowl: Need more specific steps to reproduce, I guess.
22:03:47	fowl	dom96: i think it got reset somehow, i just restarted it and it stayed set
22:04:01	dom96	weird
22:24:05	Vladar	It seems I figured out what causes that crashes in windows binary of libtcod. One of the crashes�
22:24:58	gradha	looks like I can't build documentation locally on mac, fsmonitor is not supported
22:25:13	gradha	Hint: fsmonitor [Processing]
22:25:13	gradha	lib/pure/fsmonitor.nim(25, 10) Error: Your platform is not supported.
22:25:15	gradha	Hint: inotify [Processing]
22:25:17	gradha	...Hint: math [Processing]
22:25:18	gradha	lib/pure/fsmonitor.nim(113, 15) Error: undeclared identifier: 'read'
22:25:20	gradha	external program failed
22:25:20	gradha	Error: execution of an external program failed
22:25:21	gradha	FAILURE
22:26:05	Araq	Vladar: well?
22:26:30	*	Trix[a]r_za is now known as Trixar_za
22:26:31	Araq	and can you have a look at bug #263
22:28:19	dom96	mmm, perhaps fsmonitor should check for defined(nimdoc).
22:28:50	Vladar	Araq, I testing it yet, but I pretty sure it glitch out on windows if you declare callback function in const. When I changed const to var _this_ bug was gone
22:37:08	Araq	can't follow, do you mean 'const p = proc () = ....' ? o.O
22:37:39	Vladar	Araq, I'm not sure yet. Trying to replicate bug in separate file.
22:37:58	Vladar	When I'm be totally sure I'll post a bugreport
22:39:21	Araq	instead of producing a new bug report, fix #263 instead ;-)
22:40:44	Vladar	Araq, I built nimrod under wine yesterday pretty smooth
22:41:27	*	apriori_ quit (Quit: Konversation terminated!)
22:51:03	*	gradha quit (Quit: gradha)
23:15:49	*	Zor joined #nimrod
23:18:01	Araq	welcome Zor :-)
23:18:22	Zor	o hai!
23:20:56	dom96	hello Zor!
23:29:36	*	Vladar quit (Remote host closed the connection)
23:29:41	*	Trixar_za is now known as Trix[a]r_za