<<02-06-2012>>

---

04:11:58	*	XAMPP joined #nimrod
06:10:17	*	XAMPP quit (Quit: There is no such thing as coincidence, only the inevitable.)
06:13:48	*	Psyclonic joined #nimrod
06:18:28	*	llm joined #nimrod
10:08:17	*	apriori_ joined #nimrod
10:08:48	dom96	good morning everyone
10:14:35	apriori_	there doesn't happen to be a c header to nim converter, does it?
10:18:26	dom96	apriori_: There is a tool which does that; c2nim
10:18:47	dom96	https://github.com/Araq/Nimrod/tree/master/compiler/c2nim
10:18:47	apriori_	can you give an example on how to use it on headers?
10:18:51	apriori_	yeah, I got that
10:19:17	dom96	http://build.nimrod-code.org/docs/c2nim.html
10:19:19	dom96	That might help
10:19:39	apriori_	ok, thank you
10:25:50	apriori_	uff, c2nim dies on the opencl headers ;)
10:27:38	dom96	You need to adjust the headers until c2nim understands them :P
10:27:51	apriori_	yeah, maybe...
10:27:58	apriori_	but this very first case doesnt make sense at all
10:29:35	dom96	Does c2nim crash?
10:29:41	apriori_	nope, just:
10:29:42	dom96	or just give you an error about the header file
10:29:47	apriori_	CL/cl_ext.h(67, 49) Error: ';' expected
10:30:17	apriori_	http://pastebin.com/s0p9fiVa
10:30:19	apriori_	code section...
10:30:20	dom96	Take a look at the docs, the limitations section.
10:30:24	apriori_	49 is right after the (
10:30:45	apriori_	I did, there is no real hint about that
10:30:57	apriori_	though I assume its the calling convention put in the forward declaration
10:31:23	dom96	Try to simplify it
10:31:28	apriori_	on it
10:47:13	apriori_	uff, opencl does some very wicked typedef stuff in their headers...
10:50:33	dom96	if it's not really important just remove it
10:50:47	apriori_	well, I think that special stuff actually is
10:50:54	apriori_	it forces some alignment on vector types
10:51:16	apriori_	but I will come to that later.. just commenting out and trying to get some very basic stuff running
10:57:55	apriori_	hm.. c2nim really has some problems with function pointer types
11:04:33	apriori_	is there some info on how nimrods module system works?
11:04:57	apriori_	I just tried to import something which is located in a subdirectory relative to a .nim... import Cl.cl notation doesn't seem to work.
11:07:18	dom96	I think `import "cl/cl"` will work
11:07:58	apriori_	nope
11:08:25	apriori_	ah, wait
11:08:32	apriori_	some error in the generated cl.nim
11:15:52	apriori_	now I got a real issue..
11:16:05	apriori_	the C library defines struct with names like _cl_platform_id
11:16:27	apriori_	c2nim transformed the c typedef
11:16:28	apriori_	typedef struct _cl_platform_id * cl_platform_id;
11:16:30	apriori_	to:
11:16:35	apriori_	cl_platform_id* = ptr _cl_platform_id
11:17:06	apriori_	which would be just fine.. if the compiler wouldn't complain about the leading underscore of _cl_platform_id
11:18:50	dom96	hrm, change cl_platform_id to PCLPlatformID and _cl_platform_id to TClPlatformID
11:19:10	dom96	I guess there is a lot more of these types.
11:19:28	apriori_	yeah.. but is that then a real pointer to the struct opencl wants there?
11:19:28	dom96	I don't think c2nim can automatically change the name like that
11:19:33	apriori_	which is defined in the lib?
11:20:17	dom96	i guess
11:20:55	apriori_	seems like I need a testcase for that
11:26:46	*	llm quit (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725])
11:40:33	apriori_	dom96: I don't think I properly described the issue..
11:40:56	apriori_	I want the equivalent of a simple C forward declaration of a struct type, which lies somewhere in a lib
11:41:30	dom96	In Nimrod you do not need to forward declare types
11:41:51	dom96	As long as they are in the same 'type' section it should work, I think.
11:41:56	apriori_	but how can I create an instance of such a struct that if nimrod has no clue about it?
11:42:41	dom96	Don't create it?
11:42:55	dom96	For the purposes of a wrapper it's not needed.
11:43:15	apriori_	it is needed ... it contains data one has to fill etc.
11:43:23	apriori_	otherwise I would need to write such stuff in C
11:44:05	dom96	I don't think I get what you mean.
11:44:15	dom96	Declare it as an object then?
11:44:32	apriori_	yep, you really don't get it ;)
11:44:37	apriori_	but wait a minute.. searching something
11:45:58	apriori_	dom96: ok, well..
11:46:03	apriori_	let us start from the beginning ^^
11:46:16	apriori_	in opencl.. there is a struct called cl_platform_id
11:49:17	*	Zerathul joined #nimrod
11:49:49	apriori_	and I can't find any definition of that struct and its field anywhere.. so I assume its just a declaration to something which is in the opencl libraries
11:50:06	apriori_	typedef struct _cl_platform_id * cl_platform_id;
11:50:16	apriori_	thats all I can find.. no proper struct declaration of _cl_platform_id
11:51:01	dom96	oh! Just declare it like this: TCLPlatformId*{.pure, final.} = object
11:51:39	*	Zerathul quit (Client Quit)
11:52:03	apriori_	ok, will try that
11:52:09	apriori_	thank you for your patience ;)
11:54:18	dom96	np
12:23:39	Araq	apriori_: you can tell c2nim how to translate identifiers
12:23:55	apriori_	Araq: ok, I will look into that..
12:23:58	apriori_	now I gotta go though
12:23:59	apriori_	bye
12:24:00	Araq	and you can tell c2nim about the CL_API_ENTRY macro too
12:24:04	Araq	bye
12:24:13	apriori_	ok, thank you
12:24:19	*	apriori_ quit (Read error: Connection reset by peer)
12:40:23	Araq	ping zahary
14:13:13	Araq	oh hi Psyclonic
14:13:30	Araq	didn't notice your arrival :-)
15:34:29	Tasser	Araq, he ninja'd in
15:38:29	Araq	Tasser: indeed :-)
16:01:30	Araq	zahary: got my message about slurp and staticRead?
16:01:54	zahary	which one?
16:03:11	zahary	I'm almost done btw. I'm currently coming up with an example for staticExec in the docs
16:04:38	Araq	the one where I argued that 'slurp' is like 'include'
16:04:48	Araq	and 'include myvar' shouldn't be supported either
16:04:54	Araq	(and isn't)
16:05:11	Araq	so I'd like to have both slurp and staticRead
16:06:44	zahary	well, I it's easy to do it this way, but I kind of disagree that staticRead should not be tracked automatically
16:07:52	Araq	it shouldn't until we got the caching API IMO
16:08:46	zahary	executing process can have many purposes, but when shouldn't modified files read by staticRead trigger a rebuild?
16:09:43	Araq	hm good point
17:17:47	Araq	yummy :-)
17:20:26	Araq	zahary: what are standalone except and finally blocks?
17:28:01	zahary	they are like atScopeExit and onError from D and clay
17:28:36	zahary	I have a bit more work on except tho
17:28:36	zahary	otherwise, they are used like this:
17:28:36	zahary	f = fopen("somefile")
17:28:36	zahary	finally: close(f)
17:31:33	zahary	I haven't made up my mind on "except:". should we call it onerror instead?
17:31:33	zahary	right now, it does consume the exception and I'm also considering leaving it this way and introducing separate onerror that's more standard (that doesn't consume it)
17:33:07	*	ccssnet quit (Read error: Connection reset by peer)
17:38:33	Araq	hm "onerror" is not particularly asthetic
17:39:01	Araq	I'd prefer 'except' for now
17:39:46	zahary	yeah, I wanted to be consistent too
17:39:58	Araq	however, I'm not convinced that's needed
17:40:24	zahary	well, if only as a checkbox feature, I think it's nice
17:40:26	zahary	https://github.com/jckarter/clay/blob/v0.1.0/doc/language-reference.md#scopeguardstatements
17:40:26	Araq	when one needs to program transactions, it may be better to create a macro for this purpose
17:40:33	zahary	https://github.com/jckarter/clay/blob/v0.1.0/doc/language-reference.md#scopeguardstatements
17:41:40	Araq	as a macro can know about the "rollback" convention
17:41:57	Araq	but I haven't really thought about it
17:44:08	zahary	in C++ I miss such facilities sometimes when the RAII code is kind of unique and one-off. example that comes to mind is stack management in lua (you mush always call lua_popstack or lua_settop with a different number/order/etc)
17:59:35	Araq	btw how is `*x` supposed to work?
17:59:47	Araq	var `*x` = 0 # gensym
17:59:57	Araq	`*x` # gensym again? o.O
18:00:18	Araq	i.e. how to use 'x'?
18:01:17	zahary	`*x` every time, yes
18:01:36	zahary	could be of interest: http://wiki.luajit.org/New-Garbage-Collector
18:02:20	zahary	we have deprecated `*x`, right? I could try to do something with a pragma instead
18:04:01	zahary	if you ask how it works, the idea is that * is mapped to unique ID during a single expansion of the template, so every time you say `*x`, you get <same-unique-id>x
18:09:18	Araq	yeah `*x` is deprecated and indeed I'm going the pragma way :-)
18:09:41	Araq	fyi I also decided to make locals 'byref' when captured in a closure
18:09:53	Araq	but there is a 'bycopy' pragma that can change the default
18:10:17	Araq	the variables in the built-in countup and countdown iterators will have the 'bycopy'
18:10:55	Araq	so capturing a for loop var has the right semantics
18:11:59	Araq	it feels a bit optimized towards rossetta code examples but oh well :-)
18:13:01	zahary	yeah, we talked about bycopy/byref before. sounds good
18:14:48	Araq	thanks for the link
18:14:51	Araq	"Also, a search for a "quad-color" GC (or variations) does not turn anything up. In the absence of evidence to the contrary, I (Mike Pall) hereby claim to have invented this algorithm. "
18:14:58	zahary	but I don't get the countup/countdown part. shouldn't every iterator var be captured this way?
18:15:26	Araq	ugh, he should have a correctness proof for that ... but hey, it's Mike Pall after all
18:16:21	Araq	well I'm not sure every "iterator var" should be captured this way
18:16:49	Araq	and the new implementation runs after transform() so iterator vars are lost by the time we run the lambda lifting
18:18:47	zahary	in pseudo javascript, the problem is often triggered like this
18:18:47	zahary	for elem in elements():
18:18:47	zahary	changeStyleBtn.click do:
18:18:47	zahary	elem.css "color", "red"
18:19:14	zahary	expected outcome: change all elements, what happens: only the last one gets changed
18:19:47	zahary	and the code is silly, because the loop could be inside the click handler, but the purpose is to illustrate the point
18:21:46	Araq	JS is weird I need to check how it behaves in nimrod :-)
18:24:25	Araq	for interfaces = tuple of closures we need byref capturing
18:24:34	Araq	so that's more important
18:25:22	Araq	in fact, I don't mind too much should it be the only capturing mechanism; python gets it wrong too :P
18:34:02	zahary	if you put an explicit copy on the first line of the loop like this:
18:34:02	zahary	for elem in elements():
18:34:02	zahary	var elemCopy = elem # in your algorithm, this variable will never be placed directly on the stack, right? instead it will become a member of the closure object?
18:34:02	zahary	something do: elemCopy
18:34:53	zahary	in C# there is only by ref and I guess their only modification to the compiler is the introduction of such an implicit variable
18:35:15	zahary	but nevertheless, more control doesn't hurt
18:36:17	Araq	it will become a member of the closure object, yes
18:36:39	Araq	but in a later version closure objects may be put onto the stack if they don't escape
18:36:55	zahary	yeah, that's why I said directly
18:37:36	Araq	oh I missed the 'directly' :-)
19:15:56	Araq	er, ... we've talked about this: capturing another variable that copies the for loop var does NOT work
19:16:36	Araq	because this new variable is then shared
19:17:18	Araq	but that's however a problem only because I perform the closure allocation not in the loop body, but at outer proc entry
19:17:20	Araq	hm
19:37:52	Araq	zahary: you broke nimbuild :P
19:37:55	Araq	lib/system.nim(2178, 62) Warning: unknown magic 'StaticExec' might crash the compiler [UnknownMagic]
19:37:57	Araq	lib/system.nim(2178, 15) Error: implementation of 'staticExec(command: string, input: string): string' expected
19:38:19	Araq	I had the same problem, just use ' = nil' as implementation
19:39:28	zahary	yeah, I noticed, sorry about that, but I thought unknown pragma is just a warning
19:39:51	zahary	ah, so no need for new sources after all, ok
19:42:58	Araq	well unkown pragma should only be a warning :-)
19:43:06	Araq	but I missed that part
19:43:28	Araq	we'd need a mUknown that's different from mNone to make it work :D
19:46:28	Araq	hey using localError() in the backends is cheap :P
19:47:01	Araq	I wanted to have the backends free from error reporting, but I can see it's the simplest and fastest solution :-/
19:47:44	Araq	it's however not correct, 'nimrod check' doesn't invoke the backend ...
19:48:32	Araq	it's good enough for now, but I suppose we need another pass checking for magics in weird places ...
19:52:31	zahary	I also considered efCompileTime expression flag for sem
19:55:54	Araq	ugh, I never liked the flags for nodes
20:12:39	Araq	case expressions?
20:13:05	Araq	and try expressions?
20:13:19	Araq	btw how do they render?
20:13:54	Araq	zahary: no codegen for c++ destructors yet?
20:15:46	zahary	well, after weighting all the implications I'm about to decide against them - with the current approach we get destructors working in C, C++ and evals - otherwise there must be 3 separate implementations
20:18:42	zahary	there is a future feature I'm interested in - generating headers with types that wrap nimrod types and allow idiomatic use from C++, but even my previous plan with real destructors woudn't get us this for free and it's still possible to achieve
20:20:58	*	ccssnet joined #nimrod
20:21:16	zahary	about the new expressions, they are only parsed for now (no sem, no rendering, etc)
20:22:27	zahary	I just took the opportunity to add them to the parser as they were somewhat similar to my other changes
20:29:06	Araq	I see
20:34:43	Araq	but we'll get most advantages once the code gen uses C++'s try statement instead of the setjmp approach, right?
20:35:04	Araq	I like fast try statements :-)
20:36:48	zahary	yes, I compared some C++ code for destructors vs this approach using many try statements and there is no difference in the assembly
20:37:41	zahary	it's interesting to see how setjmp compares, but we should probably recommend destructor-heavy code to use C++
20:38:02	Araq	yeah
20:38:23	Araq	it's nice to have the C backend for quick turn around times though
20:39:01	Araq	is there a difference between try { try { }} and try {}?
20:39:14	Araq	I mean for performance
20:39:34	Araq	for the setjmp solution there is
20:39:56	Araq	so I'm a bit worried that you don't merge implicit try-finally statements
20:40:04	zahary	shoudn't be. in C++ what matters is only the creation of a new object
20:41:13	zahary	hmm, I have to think about when such merges could occur in practice
20:42:05	Araq	var x = open"abc"
20:42:12	Araq	finally: x.close
20:42:18	Araq	var y = open"xyz"
20:42:23	Araq	finally: y.close
20:43:06	Araq	if I'd written with an explicit 'try', I would have merged the close operations somehow
20:43:25	Araq	it's not possible in the general case though
20:44:51	zahary	you could have written it like this:
20:44:51	zahary	var x, y
20:44:51	zahary	try:
20:44:51	zahary	x = open
20:44:51	zahary	y = open
20:44:51	zahary	finally:
20:44:51	zahary	if y != nil: close y
20:44:52	zahary	close x
20:44:53	zahary	but that's not equivalent
20:45:38	Araq	but I'd do it this way :-)
20:46:56	zahary	the try approach will be faster in C++, this would be faster in C (unfortunately it's trade-off that's left for the user to decide)
20:46:57	Araq	I've already adapted to Nimrod's "try is expensive" ...
20:48:10	Araq	for a destructor we could have a {.merge.} pragma ...
20:48:31	Araq	(I think .merge already exists but means something entirely different)
20:50:14	zahary	ultimately I want to use the C++ codegen, because that will allow me use more existing third party libraries and our own codebase
20:50:36	Araq	I know
20:52:01	Araq	we could require that calling 'destroy' twice does no harm
20:52:08	Araq	which is good style anyway
20:52:31	Araq	and then we could put destructors in the same finally section
20:53:02	zahary	seems very tough requirement
20:55:53	zahary	I'd like to use more noInit types in my code as well - this also makes things harder for the C codegen
21:02:48	Tasser	noInit types=
21:03:35	zahary	nimrod initializes all variables to zero by default
21:07:37	zahary	it's worth pointing out that any code involving exceptions will probably run faster in C++ and I think most rational people should use that
21:08:18	zahary	:) including us in the compiler itself
21:14:25	Araq	maybe if the destructor is annotated with .noSideEffect?
21:14:32	Araq	but ugh forget it
21:14:37	Araq	this doesn't make sense
21:16:03	Araq	so you mean that's hard to perform a no-op 'destroy' when the memory is not initialized?
21:17:39	zahary	yep
21:18:38	Araq	hm good point
21:21:12	Tasser	why so?
21:23:03	Araq	it's hard to do any checks on non initialized memory
21:27:32	Araq	so my idea is that vars et. al. declared in a template are gensym'ed unless declared with an {.export.} pragma. opinions?
21:27:54	Araq	or perhaps {.inject.}?
21:29:45	dom96	hello
21:30:06	Araq	hi dom96
21:32:25	dom96	So Prometheus was disappointing.
21:32:37	Araq	stop it
21:32:45	Araq	it will be the best movie ever
21:33:11	dom96	You can convince yourself all you want
21:33:30	Araq	dom96: syntax question: 'inject' or 'export' for vars that shall escape a template?
21:33:57	dom96	Define "escape" :P
21:34:10	Araq	currently this is possible:
21:34:18	dom96	Should be included in the resulting code or should not?
21:34:18	Araq	template t() = var x: int
21:34:21	Araq	t()
21:34:26	Araq	x = 23
21:34:36	Araq	but I'd like to forbid that
21:35:08	dom96	Those keywords kind of suggest to me that 'x' would behave like you just described
21:35:19	dom96	i.e. it would be in the resulting code
21:35:24	Araq	yep
21:35:27	Araq	that's the plan
21:35:33	dom96	Ugh, it's so hard to describe this for some reason
21:35:53	Araq	to disallow the above code and make you use a pragma to get back the behvaviour
21:36:04	Araq	template t() = var x {.inject.}: int
21:36:19	dom96	Won't this break a lot of code? since by default currently everything has that pragma?
21:36:54	Araq	yeah but we broke templates already with the 'immediate' stuff
21:37:14	Araq	better do it properly then
21:37:51	Araq	and for instance, jester should benefit quite a lot from that
21:38:15	dom96	"the 'immediate' stuff"?
21:38:49	Araq	no the arguments are sem'checked before template instantation to allow overloading of templates
21:38:54	Araq	*now
21:39:08	Araq	and you need the immediate pragma to disable that
21:40:40	dom96	ahh
21:42:57	dom96	Wouldn't it be better to have this: var x*: int ?
21:43:10	dom96	I don't really like the idea of a pragma for this.
21:43:49	Araq	but then what you write to declare a global variable in a template?
21:44:31	dom96	How about a new keyword?
21:45:06	dom96	or: `var x: int`
21:45:12	Araq	meh, 'export' is already planned for the '*'
21:45:23	Araq	and 'inject' is too useful to be a keyword
21:45:37	dom96	Would backquotes work?
21:45:44	Araq	nah
21:45:52	dom96	hrm.
21:45:57	dom96	var ~x: int
21:46:06	dom96	or
21:46:10	dom96	var x~: int
21:46:12	Araq	var x~: int
21:46:15	Araq	yeah
21:46:17	Araq	hm
21:46:26	Araq	or better:
21:46:29	Araq	var x+: int
21:46:34	dom96	hrm.
21:46:49	dom96	Sure I guess.
21:46:53	Araq	I like the pragma better
21:47:05	Araq	scope injection is evil and deserves an ugly pragma
21:47:09	dom96	But it's so much typing :\
21:47:23	dom96	I guess that's true.
21:47:32	dom96	I won't be scope injecting that often
21:47:38	Araq	let me check how many of my templates would be affected
21:49:08	dom96	16 posts on one thread, the forum definitely needs paging.
21:49:38	Araq	we could also delete old threads instead :P
21:49:41	Araq	XD
21:50:07	dom96	yeah, I like the idea of answering the same questions multiple times.
21:50:47	Araq	I answer more questions than you do anyway :P
21:50:52	Araq	so it's more work for me
21:51:53	dom96	It seems you like work. Go ahead, you'll get to delete the old threads AND answer the same questions again!
21:52:00	dom96	:P
21:55:27	Araq	ok, I'll go the 'inject' way
21:55:46	Araq	most of my templates don't have a 'var' section anyway
21:55:59	dom96	Awesome. Rafael Vasco's GLFW bindings work nicely.
21:56:17	Araq	did you try the example program or what?
21:56:48	dom96	yeah
22:01:16	dom96	oh and vladar put his nimgame library on github too
22:01:51	Araq	do I want to see the code?
22:02:52	dom96	I don't know. Do you like methods? :P
22:04:18	Araq	no
22:07:24	dom96	Araq: How are the closures going?
22:07:51	Araq	have been reviewing zahary's changes instead :-)
22:08:06	dom96	i see
22:09:09	*	dom96 will finish his changes to sockets
22:09:13	Araq	even unittest does no scope injections
22:09:34	Araq	this change won't change much code at all
22:09:39	Araq	*break
22:10:06	dom96	oh cool. I'm glad you guys are using nimbuild :)
22:12:19	Araq	sure, how else should we run the testsuite?
22:12:32	*	Araq forgot how to invoke the tester
22:12:42	dom96	haha
22:39:21	*	filwit joined #nimrod
22:39:36	filwit	hi dom96
22:39:55	filwit	sorry I missed you yesterday, but I'm guessing you where probably done after your exam anyways
22:40:48	dom96	hello filwit
22:41:17	filwit	does kinda suck we're in such different timezones
22:41:25	filwit	it's what, 1am over there?
22:41:35	dom96	nah, 11:40
22:41:44	filwit	oh alright, not to bad
22:42:35	filwit	I was trying to get on earlier today, but I was gone all day, and now I need to finish something for my brother
22:42:45	filwit	otherwise I'd say we should work on Aporia
22:43:02	dom96	Ahh, well my "friends" want to play Worms Reloaded anyways.
22:43:05	dom96	So it's alright
22:43:12	dom96	Will you be here later on?
22:43:44	filwit	hopefully, I have a bit of work to do, but I'll try and come to a good stopping place soon
22:44:02	filwit	I did get the "intelligent tab" in aporia almost finished
22:44:04	dom96	I'm not sure how long I will be up for though :\
22:44:17	filwit	ya, no worries
22:44:20	filwit	maybe sunday
22:44:20	dom96	"intelligent tab"?
22:44:21	filwit	?
22:44:30	filwit	ya, that's what I'm calling it
22:44:34	dom96	What is it?
22:44:40	dom96	And sure, sunday is alright.
22:45:09	filwit	well I was telling you that I was making it dedent when you pressed return after a blank line
22:45:17	filwit	well I've taken that a bit further
22:45:30	filwit	so it auto tabs into if/procs
22:45:53	dom96	oh cool.
22:45:53	filwit	and it wont dedent if you're "inside" a if/proc body, only at the end
22:46:12	dom96	For some reason when you said "tab" I thought tab as in well tab not indentation :P
22:46:24	filwit	and pressing delete dedents where applicable (shift-backspace can be used to force single delete)
22:46:47	dom96	Perhaps you should call it the "super nimrod mode" :P
22:46:48	filwit	I don't mean delete dedent the entire line btw
22:47:22	filwit	ah lol, "super nimrod mode" sounds a bit to cool for what it does
22:47:37	dom96	heh
22:47:52	filwit	but it actually does make things easier to work with, especially when just writing quick if statements and stuff
22:48:03	filwit	cause it auto tabs, and exits intelligently
22:48:56	dom96	I think you should call it that. We'll add more awesome features to it in the long run :)
22:49:00	filwit	I'm thinking that the auto dedent thing should be a "sub option" to the intelligent tabbing option though, cause some people might just want to have it auto tab after ifs and stuff without that
22:49:22	filwit	lol, alright, I'm all for having cool names
22:49:46	dom96	You can add another tab to the settings dialog and have lots of different checkboxes there :)
22:50:10	dom96	Although I guess the "Editor" tab has enough space
22:50:33	filwit	maybe we could add VIM style navigation, but with a spin so that you're not in Input/Nav modes, you just press Alt-J to move up, etc
22:51:30	dom96	Well I'm used to arrow keys anyways.
22:52:04	filwit	ya, I never actually used VIM, but I know one of the reasons people like it is because you never have to move your hands from the keyboard
22:52:27	filwit	though I don't like there keyboard short-cuts really, I think that concept has merit
22:53:16	filwit	we could just make A/S/D/W controls navigate when pressing Ctrl, or maybe move them to J/K/L/I
22:53:26	filwit	anyways...
22:53:31	filwit	:)
22:53:56	dom96	Perhaps we should have a plugins API?
22:54:09	filwit	that would be cool
22:54:16	filwit	what we really need is to convince Araq to make the compiler as a service
22:54:25	dom96	yes, for better suggest :)
22:54:30	filwit	so we can get Sugguest and Overview quickly
22:54:42	filwit	(and he ends up doing all the work for it)
22:54:46	filwit	;-P
22:54:49	dom96	lol
22:55:20	filwit	no seriously though, that would open the door to a lot of dev tools
22:55:23	filwit	not just suggest
22:55:41	filwit	refactoring, built-in REPL, etc..
22:55:52	filwit	could all take advantage of that
22:56:16	dom96	yes, all of that will have to be implemented though
22:56:21	dom96	in the compiler
22:56:40	dom96	I wish my compiler hacking skills were good enough to implement these things
22:56:49	filwit	guess I'm going to have to start digging into the compiler then :)
22:57:10	filwit	though I'm with you, I doubt I'll be of much use to it right now
22:57:39	filwit	but I've learned a lot about such things recently with all the D discussions I've had
22:57:58	filwit	still...
22:58:22	filwit	anyways man, I've got to do some stuff
22:58:33	filwit	I think I'm going to hop off here so this isn't a distraction
22:58:37	filwit	:)
22:58:56	filwit	I'll talk to you later, or more likely tomorrow
22:59:04	filwit	bye
22:59:38	dom96	see ya
23:00:47	*	filwit quit (Quit: Leaving)