<<11-12-2012>>

---

00:35:40	*	XAMPP quit (Quit: Leaving)
00:41:34	*	XAMPP joined #nimrod
00:41:35	*	XAMPP quit (Changing host)
00:41:35	*	XAMPP joined #nimrod
01:07:47	*	q66 quit (Quit: Quit)
04:14:26	*	Trix[a]r_za is now known as Trixar_za
04:46:34	*	Trixar_za is now known as Trix[a]r_za
09:15:45	*	XAMPP quit (Read error: Connection reset by peer)
09:36:22	*	FreeArtMan joined #nimrod
11:40:09	*	Araq_ joined #nimrod
11:44:08	*	Araq_ quit (Client Quit)
12:40:16	*	fowl quit (Quit: Leaving)
12:45:59	*	fowl joined #nimrod
12:58:03	*	q66 joined #nimrod
15:57:11	*	gradha joined #nimrod
15:57:45	gradha	I was looking for date parsing code and didn't find anything in code
15:58:45	gradha	for parsing dates in the iso format "2012-11-20T22:08:08.398990" I have just used split
15:59:00	gradha	should such a proc be added to the times module?
16:22:55	gradha	uf, what a can of worms parsing dates is
16:23:58	dom96	Doing anything with time itself is annoying.
16:26:21	dom96	I bet POSIX/WINAPI has some functions for parsing time.
16:26:55	gradha	posix has strptime but it requires you to know in advanced the format of the string being parsed
16:27:24	gradha	unfortunately ISO 8601 allows some variation with regards to amount of present elements and timezones
16:38:26	gradha	the TTimeInfo type uses enums for months, how can I easily transform 4 into the TMonth mApr enum?
16:39:48	gradha	big case?
16:39:56	dom96	TMonth(4) perhaps
16:41:21	gradha	yes, works
16:41:48	gradha	yay, it even raises EOutOfRange
16:56:10	*	_ponce quit (Remote host closed the connection)
16:56:27	*	_ponce joined #nimrod
17:07:12	gradha	what's the idiom when you want to catch an ignore an exception? at the moment I'm returning, but what if I wanted to continue with the flow of the proc? Is there a nop-like keyword?
17:25:58	reactormonk	gradha, begin <dangerous code> rescue <error> end
17:26:00	reactormonk	that's about it
17:26:40	reactormonk	but beware of capturing too much, if you capture Exception, I'll strangle you with your favourite stuffed animal.
17:27:38	gradha	that would be a panda
17:28:23	reactormonk	gradha, oh, duh
17:28:29	reactormonk	wrong channel -.-
17:28:38	gradha	still sounded like fun
17:28:41	reactormonk	this isn't the ruby one :-)
17:29:29	reactormonk	Exception even captures syntaxerrors when loading, that's why. Seen that once. Ugly implications.
17:44:12	gradha	dom96: I looked at https://github.com/JukkaL/mypy and maybe I'm reading wrong, but it seems like a prettier implementation of something like cython http://www.cython.org
17:45:46	gradha	basically, adding static typing to improve performance
17:48:06	dom96	true.
17:48:12	dom96	They do look similar.
17:48:21	*	dom96 didn't really look into 'mypy' that much
17:58:59	gradha	httpclient.TResponse.status is a string? cue audio of n-plicated status code parsing pain
18:04:07	dom96	what's wrong with that?
18:04:55	dom96	I suppose an enum would be nicer, but does this really cause any severe issues?
18:05:34	gradha	for every request you need to parse the string and convert the status code into an integer
18:06:26	dom96	how would you get around that?
18:07:01	dom96	The only difference here is, either you parse the string in your own code or httpclient does.
18:07:44	gradha	so that's what I was saying: every time I'm going to use httpclient I'm going to be duplicating string parsing code to make integer code comparisons
18:08:27	gradha	at the moment I have http://pastebin.com/p32pBFJZ
18:09:28	gradha	is there any way to do such comparisons faster at the string level?
18:11:38	dom96	response.status[0] in {'3', '4', '5'}
18:13:38	Araq	Zor: that D's slices create interior pointers is just the top of the iceberg of D's problems with GC
18:13:49	Zor	Araq: of course
18:14:52	gradha	dom96: is that better/worse than a case on the first string character?
18:15:08	Araq	so when should we tell them the other problems? ;-)
18:15:35	Zor	Araq: I don't think they're going to listen anyway
18:15:54	Araq	true
18:16:02	dom96	gradha: no idea, Araq?
18:16:52	Araq	I can hardly see 'parseInt' being any concern when retrieving data over a socket ...
18:17:33	Araq	parseInt is pretty slow yes, but not in comparison to IO
18:19:48	Araq	however I'd prefer an enum too :P
18:20:41	Araq	otherwise you simply don't implement the protocol completely in the library and make the client code perform part of the error checking that the library is supposed to do
18:22:42	gradha	does the request proc guarantee that all return paths return a status string with at least a character?
18:23:02	Araq	who knows ...
18:23:22	Araq	but it's always safe to acces s[0] (if 's' is not nil) ...
18:25:37	gradha	hmmm... how does nimrod fare in adding debug post assertions? would it be possible to wrap httpclient.parseResponse with a try/finally block which just asserts on some values and in release versions this would go completely away?
18:26:24	Araq	if you manage to use the C++ codegen visual C will optimize the try-block away for you
18:26:42	Araq	otherwise you need to do something like:
18:26:48	gradha	Hmmm... maybe a more direct approach would be to write a macro which wraps the whole proc and goes away when(release)
18:27:11	Araq	yeah, I was going to suggest just that
18:27:20	Araq	a simple template does the trick
18:28:09	Araq	whenever you need control flow abstraction a macro/template is a solution
18:28:37	Araq	the other solution is to use a closure, but that's more expensive
18:29:53	gradha	how are closures used in nimrod?
18:30:12	gradha	ah, nested procs
18:39:12	Araq	gradha: please go ahead and fix the httpclient ;-)
18:39:24	gradha	what's there to fix?
18:39:27	Araq	I prefer the enum too
18:40:04	dom96	Might as well fix that buffering bug while you're at it :P
18:40:13	Araq	yeah
18:40:42	Araq	and another thing that's desperately needed: tests for idetools so that I know when I break something
19:07:52	Araq	dom96: this patch mitigates the path problem for Babel ;-)
19:09:07	Araq	as now the path is picked consistently, so nimgame/utils is preferred over jester/utils if nimgame is already imported
19:10:09	dom96	hrm, ok. We're going to have to discuss details later.
19:10:12	dom96	bbl
19:31:11	dom96	back
19:31:39	dom96	Araq: So what does your patch fix exactly?
19:31:51	Araq	what I wrote above
19:32:04	Araq	there are 2 utils.nim, you can't import both packages then
19:32:23	Araq	but at least the very existance of the other package doesn't break anything
19:32:35	dom96	ok.
19:32:52	dom96	Can I import from the module's directory yet?
19:32:52	Araq	in fact, I think --babelPath is a misfeature
19:33:09	Araq	and that it shouldn't be used
19:33:17	Araq	and be deactivated
19:33:43	Araq	and you should do --path:$babel/nimgame in your project's configuration file
19:34:44	dom96	But then the babel file already contains that info...
19:36:02	Araq	only if the project has a .babel file
19:36:36	Araq	which is not that likely; I for instance don't want to add my *applications* to babel
19:37:06	dom96	ok, but then the .babel file serves as a list of dependencies for you app
19:37:09	dom96	brb
19:39:41	dom96	back
19:41:51	Araq	you're right that .cfg and .babel files do overlap in functionality
19:41:51	*	Vladar joined #nimrod
19:42:15	Araq	but .cfg was there first :P
19:42:40	dom96	pfff
19:43:12	dom96	Just make the compiler read the babel file, problem solved.
19:46:12	Araq	nah
19:46:28	Araq	what's the problem anyway?
19:46:46	dom96	currently?
19:47:04	dom96	That I cannot import module from within a module's directory?
19:47:47	Araq	but you can do that, or I'm misunderstanding you
19:48:35	dom96	nimgame/lib/engine.nim, lib/ directory has a module named common.
19:48:43	dom96	Can I 'import common' from engine.nim?
19:48:59	dom96	That was the original problem.
19:49:04	dom96	and still is?
19:49:33	Araq	I think you can do that, yes
19:52:09	dom96	so you fixed that?
19:59:04	Araq	that's always been possible
19:59:23	Araq	however you can do 'import common' everywhere else too ... :P
19:59:34	dom96	well, why did it not work for Vladar?
19:59:53	Araq	because he had it in lib/ ?
20:02:10	dom96	huh?
20:02:29	dom96	Didn't I just describe the same scenario as Vladar's and you said that I can do that?
20:02:57	Araq	I don't get it; nimgame works with the current compiler support for Babel
20:03:02	Araq	so does jester
20:03:11	Vladar	I confirm
20:03:29	Araq	it's hacky, but it works good enough until we have > ~50 packages
20:03:40	Vladar	it works since 8f4ea37 I think
20:03:51	dom96	sure. But I would prefer "import nimgame/common" instead of "import common"
20:04:42	Araq	well Vladar has to update nimgame then
20:04:53	Araq	but that would work too
20:05:29	dom96	All he needs to do is change the directory structure.
20:05:31	dom96	Nothing else.
20:09:25	Araq	but then I don't really like imposing a directory structure and it works already
20:11:39	dom96	sure, it works already. But it's simply incorrect.
20:13:33	dom96	People will get annoyed that they cannot use nimgame and have a 'common' module of their own
20:15:53	dom96	But it looks like you are simply set with how it works.
20:20:14	Araq	I already said, that will be fixed within time
20:26:19	dom96	so, what if I want to enforce this syntax? Can I do that?
20:28:15	Araq	nimgame/engine.nim
20:28:22	Araq	nimgame/nimgame/common.nim
20:28:36	Araq	would enforce the syntax
20:28:54	dom96	will I not still be able to 'import common'?
20:29:15	Araq	for now yes; later this will work
20:29:26	Araq	oh sorry
20:29:28	Araq	misread
20:30:01	Araq	argh
20:30:06	Araq	what do you mean?
20:30:50	dom96	Something tells me we are misinterpreting each other :P
20:30:58	dom96	And not just in this case.
20:31:04	dom96	earlier too.
20:31:21	Araq	perhaps
20:31:21	dom96	Let me be explicit.
20:31:37	dom96	~/babel/libs/nimgame/nimgame/common.nim
20:31:45	dom96	import common # Does this work?
20:31:55	dom96	import nimgame/common # Does this work?
20:32:18	dom96	(These imports are in some unrelated module, the module is not related to the nimgame package)
20:34:59	Araq	import common # no
20:35:07	Araq	import nimgame/common # yes
20:35:48	Araq	for the nimgame/common.nim file that is
20:36:06	dom96	ok. Now lets look at how nimgame will be installed in reality.
20:36:20	dom96	~/babel/libs/nimgame/lib/common.nim
20:36:30	dom96	Why does: import common work then?
20:36:48	Araq	because ~/babel/libs/nimgame/lib/ has been added to the path
20:37:01	Araq	because nimgame itself has no .nim files :P
20:37:35	Araq	if it had, things would be different; then ~/babel/libs/nimgame would be in the path
20:37:40	dom96	well then in the scenario I described earlier, the outcome would be the same as the current scenario for nimgame
20:39:41	Araq	I can't follow
20:39:46	Araq	which scenario?
20:39:50	Araq	and why does it matter?
20:40:05	dom96	because what you answered contradicts your newer answer.
20:40:18	Araq	lol what?
20:40:19	dom96	The scenario begins after I say "Let me be explicit"
20:40:43	Araq	ugh, just try it please
20:41:21	Araq	the real problem is that you can't have 2 common.nim files within the same project and that's a bit of work to fix, so I don't want to do it *now* given that we have 2 packages in total for now
20:42:03	dom96	Well to get the explicit "import nimgame/module" behaviour I will have to place a dummy.nim
20:42:29	dom96	or otherwise ~/babel/libs/nimgame/nimgame/ will be added to the path
20:44:21	Araq	yeah but that's exactly the behaviour I like
20:45:45	dom96	Well what I think will happen is:
20:46:01	dom96	We will get another package which uses the same module name as nimgame.
20:46:33	dom96	import common # I got nimgame, but now how do I get the other package?
20:46:44	dom96	And then there will simply be no way to fix this
20:46:56	dom96	The only thing you will be able to do is to tell the authors of the package to change it
20:47:02	fowl	import nimgame/common
20:47:06	dom96	Am I missing something?
20:47:13	Araq	yes
20:47:39	Araq	your rule "prefer the module within the same directory" for the 'import' statement fixes that then
20:48:14	dom96	what?
20:48:27	dom96	I'm not sure you understand what I mean.
20:48:32	dom96	We have two separate packages.
20:48:55	dom96	And another separate file which tries to import a module with the same name from the two packages.
20:50:44	*	fowl is now known as areola_borealis
20:51:39	Araq	well you do: import engine, common # picks the right 'common'
20:51:58	Araq	if you do: import common # good luck :P
20:52:12	dom96	The point is: I want the two commons
20:52:18	dom96	I want to import common from both packages
20:52:24	dom96	And I obviously can't
20:52:36	Araq	Araq the real problem is that you can't have 2 common.nim files within the same project and that's a bit of work to fix, so I don't want to do it *now* given that we have 2 packages in total for now
20:52:56	dom96	you simply don't get it.
20:53:10	Araq	and you can of course do: import nimgame/lib/common then
20:53:23	Araq	so yes, I don't get it
20:53:33	dom96	<Araq> and you can of course do: import nimgame/lib/common then
20:53:40	dom96	Well that changes the situation.
20:53:51	dom96	But that is ugly.
20:54:18	dom96	Like i've already said, my point is that the layout of the package stays.
20:54:29	dom96	So if the only way to import 'common' is to do "import common"
20:55:17	dom96	Then the only way to fix this later will be to change the layout of the package.
20:55:29	Araq	yes the layout of the package stays; that's a feature
20:55:53	Araq	otherwise we will come up with one layout to rule them all
20:56:05	Araq	and I certainly don't want to design that now
20:56:26	Araq	and it's doubtful such a thing exists anyway
20:56:52	dom96	Well, currently you are basically saying "ok, Nimgame gets to be the only package to export a module by the name of 'common'. No other packages will be able to do it EVER. Only way to let them do it will be to change the layout of nimgame"
20:57:18	Araq	that's not true
20:57:34	Araq	you can do: import nimgame/lib/common; import jester/common
20:57:42	Araq	you dislike the /lib/ in between
20:57:51	Araq	but quite frankly, that's your problem
21:01:31	dom96	ok, that's fine.
21:04:51	Vladar	Araq, I thought about that and here is an alternative option to consider: what if with path like this: $home/.babel/libs/foo-package/foo-lib/foo.nim and if no .nim files in foo-package we might do "import fool-lib/foo" ?
21:06:13	Vladar	then I'll rename nimgame/lib to nimgame/nimgame and "import nimgame/common" will work. Can compiler do that and preserve in-package ability to do just "import common"?
21:09:53	Araq	not without some notion of a 'package' within the compiler
21:10:04	Araq	currently the compiler has no such notion
21:10:32	Araq	dom96's idea to use the current path for the 'import' statement is not bad
21:13:25	dom96	IMO, that's the only way to go :P
21:13:32	Araq	the real problem is that you are all spoiled and can't stand any prefixes; otherwise you could name it nimgame_common.nim and call it a day
21:14:12	dom96	hey, if I weren't spoiled i'd be using C right now, or asm or some low level crap.
21:14:17	Araq	but I know I know, you all love to use utils, common and types as module names
21:15:05	dom96	Do you prefix all your module names with your project's name?
21:16:14	Araq	no, that results in filenames longer than 8 chars ... :P
21:17:25	dom96	yeah! How do you expect us to keep DOS support?
21:19:46	Vladar	It's ok, FreeDOS supports FAT32 =)
21:20:04	Araq	FPC uses module names like 'cg64f32.pas' :P
21:20:52	Araq	learn that lesson from it :P
21:22:06	Araq	or aoptcpu and aoptcpub
21:25:38	Araq	Vladar: do you feel like porting nimrod to freedos?
21:26:51	Vladar	Is there gcc on FreeDOS? =)
21:27:02	Araq	I bet there is
21:27:11	Araq	how else would they build the kernel?
21:27:17	Araq	or it is all written in asm?
21:28:06	dom96	I'm guessing the FreeDOS people are pretty hardcore, so I wouldn't be surprised.
21:28:11	Vladar	hm, it seems not: http://freedos.narod.ru/fd-doc/howto/faq.html#faq3_4
21:29:12	gradha	maybe http://www.delorie.com/djgpp/16bit/ would work
21:31:46	Vladar	Also, I doubt there is sdl port for dos
21:32:47	Araq	maybe but the compiler doesn't require SDL to run ... yet ;-)
21:49:18	*	XAMPP joined #nimrod
21:56:21	Vladar	bye
21:56:24	dom96	gradha: This is incorrect: https://github.com/gradha/Nimrod/commit/93f84492efdaf5a9f48d5b9502242373db1ae25d
21:56:36	*	Vladar quit (Quit: Leaving)
21:57:05	dom96	There is in fact a parseJson*(buffer: string): PJsonNode and a parseFile*(filename: string): PJsonNode
21:58:46	gradha	I still haven't gotten used to the fact that the most useful proc seems to be at the end of each module
21:59:48	gradha	I'll remove the text and update the example to use parseJson
22:06:16	gradha	https://github.com/gradha/Nimrod/commit/8d2f7287e9be7510219fb80b3c309d4bede9961d
22:06:42	Araq	gradha: use """ string literals please
22:07:27	gradha	oh, I did try to use enclosing ' but that doesn't work
22:09:09	gradha	it seems ' or " are the same to the parser
22:09:10	gradha	https://github.com/gradha/Nimrod/commit/1d4abeda7f92620f98094055ad8dea545e5bae1a
22:10:12	Araq	no, ' and " are not the same
22:10:41	gradha	small_json = '{"test": 1.3, "key2": true}'
22:10:49	gradha	Error: missing final '
22:12:38	Araq	'c' # character literal
22:12:42	Araq	"c" # string literal
22:14:55	gradha	hint: it would be less confusing if the error read: "missing final ' for character literal"
22:16:29	Araq	ok, done
22:41:30	*	areola_borealis is now known as fowl
22:44:05	*	calmar joined #nimrod
22:44:35	Araq	welcome calmar
22:52:53	*	fowl quit (Ping timeout: 252 seconds)
23:05:13	*	fowl joined #nimrod
23:12:27	gradha	wow, just discovered neither wget nor curl support http deflate under macosx
23:13:19	gradha	who uses the commandline on mac anyway
23:17:15	Araq	who uses a mac anyway :P
23:34:49	*	gradha quit (Quit: gradha)
23:48:55	*	q66 quit (Quit: Quit)