<<03-06-2012>>

---

05:38:01	*	llm joined #nimrod
05:43:41	*	llm quit (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725])
08:13:31	zahary	Araq, unittest is using scope injection is some of the templates
08:13:51	Araq	zahary: yeah I noticed too
08:14:07	Araq	I was too focussed on the 'var/let' keywords :D
08:14:22	zahary	I suggest we also have a pragma that keeps the current behavior. e.g. {. verbatim .}
08:15:35	Araq	why? 'template t() {.inject.}' # t is injected, not t's body contains all injected symbols
08:15:53	Araq	is only a little more verbose
08:17:14	zahary	hm, yeah, you need 2 pragmas to support "contains all injected symbols" - the question is will this be useful
08:20:34	Araq	with 'inject' per symbol you gain full control already; 'verbatim' is a bit nicer for keeping backwards compatibility
08:22:53	Araq	which I heard nobody cares about for now ;-)
08:23:33	zahary	my reasoning was that after examining all my templates I couldn't quite see the one side prevailing
08:24:02	zahary	but I don't mind too much, we could try just inject and see how it goes
08:26:03	Araq	in fact, I think it's based mostly on symbol kind
08:26:23	Araq	a 'var/let' is rarely 'inject', but a local template/proc is
08:26:58	zahary	could be
08:27:40	Araq	we could also go the other way and have a 'private' pragma for 'gensym'; that would keep compatibility
08:27:46	zahary	inject, injectAll, genSym (reverts injectAll)
08:27:57	zahary	that's what I proposed originally
08:30:13	Araq	it's nicer if gensym is the default though; I like scope injection to be explicit
08:32:05	Araq	the 'eval' template is broken as it needs a 'block' for the 'payload'
08:32:17	Araq	no problem with gensym as default
08:33:10	Araq	though we could also make all declarations in a block gensym'ed
08:33:21	Araq	and eliminate the block in a template ...
08:33:40	Araq	so a 'block' in a template subtly changes its semantics ...
08:34:17	Araq	which is however exactly what the original designer (==me) had in mind :D
08:34:34	zahary	well, yes, gensym as default is my suggestion too. only if you used injectAll, then one must use explicit gensym. or if we decided that procs and templates are injected by default, then gensym could be used for them too
08:36:07	Araq	in fact the "block changes its meaning in a template" leads to natural intuitive code IMO
08:36:14	zahary	one little problem with block is that it affects variables lifetimes too - so the user can have this in mind and be surprised by the alternative handling
08:36:35	Araq	yeah it's "intuitive" but dirty ...
08:40:29	Araq	you can use 'if true:' instead of 'block' in a template to get the lifetime stuff
08:41:05	Araq	but these are exactly the thing that require long winded comments in the resulting code
09:03:56	Araq	ok, I'll implement 'inject', 'gensym' and 'injectAll'
09:04:35	Araq	macros don't have this problem as soon as 'gensym' is an accessible magic, right?
09:05:27	Araq	or did I miss something? the imperative AST construction is not ambiguous, or is it?
09:05:47	Araq	hm
09:07:49	Araq	I guess the compiler handles nkIdent vs nkSym not consequent enough and re-evaluates nkSym too; that seems bad for macros
09:17:25	dom96	hrm, when there is a type mismatch for a template the possible matches don't seem to be listed
09:54:04	Araq	dom96: fix it :P
09:54:30	dom96	Araq: What's the difficulty level? :P
09:56:08	Araq	dunno, 3/5?
09:56:28	dom96	That sounds tough.
09:57:13	Araq	ok 1/5 then
09:57:24	dom96	Still too tough heh
09:58:05	Araq	0/5?
09:58:24	Araq	my cat could do it :P
09:58:58	dom96	You have a cat?
09:59:15	Araq	no ...
09:59:31	Araq	thats why it is not implemented yet :P
09:59:37	dom96	hehe
09:59:50	dom96	ok, I will try it. When I feel like it :P
10:01:16	dom96	Hrm.
10:01:17	dom96	error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
12:38:35	*	Zerathul joined #nimrod
12:50:20	*	Zerathul quit (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725])
15:04:55	Araq	zahary: hu?
15:05:05	zahary	try the test case in your nimrod
15:05:34	Araq	er why should they?
15:05:50	Araq	hm
15:07:30	zahary	well, that's how it works in every other language and finally is for guaranteed clean-up after all
15:07:39	Araq	yeah alright
15:07:49	Araq	it's an edge case though IMO
15:10:07	zahary	I stumbled upon it why thinking how the C++ code should work (so I had to see what the C backend does)
15:10:07	zahary	I have an idea to implement a simpler solution if C11 is detected. have you ever considered some kind of configure step to detect the local compiler?
15:10:19	zahary	* while thinking *
15:14:45	Araq	in fact, there is somebody working on autoconf support for niminst/the compiler
15:15:22	Araq	what is the simpler solution for C11?
15:16:05	zahary	it's possible to use the new lambda syntax to create a local variable whose destructor is going to call the finally block
15:17:31	Araq	so you're talking about C++11, alright
15:18:03	zahary	yes, was there C11 too? sorry
15:18:13	Araq	I think so
15:19:08	zahary	yes, there is indeed
15:22:24	Araq	zahary: dom96 is working on SSL support for sockets
15:22:52	Araq	and now TSocket is not a 'distinct cint' anymore but an object with a buffer
15:22:59	dom96	Araq: I think i'm done. Unbuffered sockets are working too.
15:23:08	Araq	and as such
15:23:25	Araq	proc acceptAddr*(server: TSocket): tuple[sock: TSocket, address: string]
15:23:41	Araq	becomes inefficient
15:24:04	Araq	any ideas?
15:24:20	Araq	I'd say 'acceptAddr' has to change its interface
15:24:47	zahary	well, how inefficient? how big is the new TSocket? I guess it still holds a handle to the underlying OS object
15:25:41	Araq	yeah but it also contains a 4K array of char buffer
15:26:47	zahary	I see
15:27:06	Araq	proc p: TSocket # doesn't cause problems I think
15:27:39	Araq	as Nimrod's backend or perhaps the C compiler transform that into an implicit pointer parameter
15:27:48	zahary	I could look up how it's done in some other libraries - maybe it's popular to keep the buffer in some kind of external SSL adaptor that's passed to the ssl socket functions
15:28:08	Araq	the buffer is not only for SSL though
15:28:42	Araq	many protocols rely on a 'recvLine' which can't be done efficiently without buffering
15:29:04	Araq	(the OS's sockets API is a PITA ...)
15:30:47	Araq	we used to do 'recv(s, addr(ch), 1)' and receive a single character
15:30:55	Araq	for recvLine()
15:30:58	zahary	I'm most experience with boost.asio, where there is a streambuf object that you pass in the readline operation
15:31:13	zahary	you can also pass a fixed buffer
15:32:33	Araq	afaik this perforrmed an OS switch for every single character ...
15:32:57	Araq	dunno how it could perform decently
15:33:53	dom96	With buffering it seems to perform better: 0.021 with buffering, 0.063 without (In seconds)
15:35:08	Araq	i suppose glibc did some buffering too?
15:42:17	dom96	So, should I hold off with committing this?
15:42:50	Araq	ugh just change acceptAddr please
15:43:17	Araq	so that gets a var tsocket and a var string
15:45:12	dom96	acceptAddr only gets a TSocket, no string.
15:45:46	Araq	no ...
15:46:33	dom96	I can't return a 'var string'...
15:49:41	Araq	lol
15:50:01	Araq	it should be another param
15:50:36	dom96	oh, that's what you mean
15:50:47	dom96	... that will break a lot of code :(
15:50:57	Araq	really?
15:51:06	dom96	well maybe not that much.
15:51:19	Araq	well TSocket now has to be 'var TSocket' ...
15:51:29	Araq	we break every module that uses sockets already
15:52:33	Araq	zahary: C++11 is not something that needs to be detected I think; GCC, Visual, Clang and Intel do support large parts of it already, right?
15:53:23	zahary	with command line switches
15:54:23	Araq	good enough for me
15:56:39	zahary	well, I'll implement both more verbose C++98 version and the simpler C++11 version
15:57:23	Araq	*shrug* if you feel like it :-)
16:03:20	Araq	about the threading stuff: I suppose there are a lot of abstractions that hide thread creation, right?
16:03:25	dom96	Araq: I'll deprecate ssl, ok? (btw how do I do it? :P)
16:03:36	Araq	dom96: what? why?
16:04:00	dom96	Araq: Perhaps I should clarify, I mean the ssl module.
16:04:14	Araq	why?
16:04:25	Araq	because sockets now support everything of it?
16:04:30	dom96	yeah, and more.
16:05:30	Araq	alright, add a {.deprecated.} top level statement
16:05:38	Araq	to deprecate a module
16:06:05	dom96	ok
16:26:08	*	Boscop quit (Ping timeout: 240 seconds)
16:29:34	dom96	Araq: Well as soon as I change the accept function to what you suggest it stops working...
16:29:38	dom96	And I don't get why
16:29:47	*	Boscop joined #nimrod
16:31:58	dom96	Araq: Never mind
16:32:46	Araq	ok
16:39:46	dom96	Araq: ok, i'm ready to commit, have you found any other things that need adjusting?
16:45:00	Araq	dom96: perhaps we can make "SMTP module compiled without SSL support" a compile-time error message?
16:45:38	dom96	Sure, how do I do that?
16:45:48	dom96	when not defined(ssl): {.error: "...".}
16:45:49	dom96	?
16:46:07	Araq	yeah
16:46:46	Araq	it should be 'initSocket', not 'newTSocket'
16:47:17	Araq	but it's not important as you don't export that
16:49:07	Araq	sleep(500) # SSL supports no async io? or why is it needed?
16:49:20	Araq	and half a second seems a bit long
16:49:32	Araq	make that 50 or something
16:51:02	*	Boscop is now known as Boscop_
16:51:18	dom96	I guess I could use select
16:51:53	dom96	But i'd need to forward declare it...
16:51:57	*	dom96 got a bit lazy there :P
16:52:46	Araq	and waitFor() should be a proc, not a template
16:57:02	dom96	alright
16:57:49	Araq	and your recv*(socket: var TSocket, data: pointer, size: int): int implemenation is inefficient :P
16:58:08	Araq	it should copyMem() bulks, not handle single characters
17:06:38	dom96	Anything else?
17:10:46	Araq	no :-)
17:11:23	dom96	hrm
17:11:30	dom96	I don't think i'm doing this right:
17:11:31	dom96	copyMem(addr(socket.buffer[socket.currPos]), data, chunk)
17:11:36	dom96	help? :P
17:14:50	Araq	flip the args
17:14:57	Araq	'data' is the destination
17:16:02	dom96	oh god.
17:16:09	dom96	Apparently I don't know English anymore.
17:31:33	zahary	can someone try "nimrod —cc:gpp cpp hello.nim" for me. I'm getting some undefined symbols and I'm not sure whether I broke it somehow
17:32:17	zahary	isObj, systemInit, newObj - something in common about them?
17:34:44	Araq	zahary: sorry, I can't bootstrap atm
17:35:38	zahary	nevermind, executing some random build command fixed the issue, I guess some o file was bad
17:39:52	Araq	yummy :-)
18:11:00	dom96	Finally.
18:28:34	*	apriori_ joined #nimrod
18:48:54	Araq	so zahary since I'll be busy with the closure stuff the next week, do you want to to 'inject' stuff?
18:50:41	apriori_	btw., when trying to create a c->nimrod binding (in my case opencl) .. how shall I treat C unsigned types?
18:52:07	Araq	apriori_: use the signed versions, it only matters they have the same size
18:52:34	apriori_	Araq: ok
18:52:43	Araq	you should however use types like 'type cunsignedInt = cint' so that we can change it easily once we got unsigned support
18:52:59	apriori_	ok
18:57:39	Araq	oh and please apriori_ put you code on github :-)
18:57:45	Araq	*your
18:57:53	apriori_	well.. I will .. if it works some day :)
18:58:14	apriori_	I might run into tons of issues with forced alignments etc.
19:05:10	*	XAMPP joined #nimrod
19:25:19	apriori_	how would I translate: void (CL_CALLBACK * /* pfn_notify */)(const char *, const void *, size_t, void *) as a parameter to a function?
19:25:38	apriori_	c2nim did the following:
19:25:41	apriori_	a5: proc (a2: cstring, a3: pointer, a4: TCLSize_t,
19:25:45	apriori_	a5: pointer): proc (a2: ptr CL_CALLBACK),
19:26:42	Araq	c2nim doesn't like function pointers ;-)
19:26:52	apriori_	yeah, i though that, too
19:27:04	Araq	but it's not too bad
19:27:08	apriori_	but could you resolve that example? I got numerous cases like that
19:28:16	Araq	I think you need to replace 'ptr CL_CALLBACK' with 'CL_CALLBACK' and then it's fine
19:28:45	apriori_	well, maybe.. but CL_CALLBACK is a define which either expands to nothing or __stdcall
19:28:49	Araq	and 'size_t' is 'int'
19:29:05	Araq	oh simple then, use:
19:29:19	Araq	#def CL_CALLBACK __stdcall
19:32:27	Araq	so the proper translation is:
19:32:54	Araq	param: proc (a1: cstring, a2: pointer, a3: int, a4: pointer) {.stdcall.}
19:33:07	apriori_	ok
19:33:20	apriori_	and btw..
19:33:31	Araq	you can also do {.push callConv: stdcall.} for the whole module I think
19:33:35	apriori_	proc (....) : proc (...)... somehow reads like a higher order function
19:34:01	Araq	maybe that is because it *is* a higher order function :P
19:34:14	apriori_	ok ;)
19:34:27	apriori_	just feels a bit strange for a function pointer
19:34:35	apriori_	but in a way.. it even makes sense
19:34:55	Araq	there is no difference between them
19:35:38	apriori_	thank you
19:35:47	Araq	there is however a {.closure.} calling convention which makes the function pointer "fat" :-)
19:36:03	apriori_	ok
19:41:40	Araq	dom96: smtp.nim The SMTP module should be compiled with SSL support. Compile with -d:ssl. no
19:41:55	Araq	you broke some test :P
19:42:05	dom96	Yeah... I noticed
19:42:30	dom96	But I dunno how to tell the test suite to compile the smtp module with -d:ssl
19:43:55	Araq	create some nimrod.cfg?
19:45:03	Araq	or edit the tester
19:46:38	dom96	argh, i'll do it later
20:25:28	apriori_	ohm, how do I decribe a null pointer?
20:25:36	apriori_	addr(0) doesn't quite seem to do it
20:26:07	dom96	nil
20:26:11	apriori_	k
20:26:14	apriori_	thank you
20:52:13	*	Boscop_ is now known as Boscop
21:16:37	apriori_	hm, any hints on debugging a SIGSEGV when calling one of the binding functions?
21:17:59	Araq	it likely couldn't be loaded then
21:18:44	Araq	but hm, no
21:18:56	Araq	it should give an error message then
21:19:30	apriori_	ah, well, my error..
21:20:31	apriori_	should have passed in a PCLPlatform_Id*{.pure, final.} = ptr TCLPlatform_id TCLPlatform_id*{.pure, final.} = object
21:20:35	apriori_	but passed in the object
21:21:42	Araq	?
21:21:55	Araq	shouldn't the compiler moan about that?
21:22:08	apriori_	not if I construct a improper function prototype
21:22:16	Araq	true ...
21:43:30	apriori_	yet another strange case...
21:43:40	apriori_	I need a pointer to the beginning of a dynamic array
21:43:47	apriori_	I guess that's the sequence type?
21:44:07	apriori_	but what would be a pointer to its beginning? addr(platformIDs[0]) doesn't quite seem to be it
21:44:39	Araq	but it is
21:44:48	apriori_	ah, damn it..
21:44:55	apriori_	pretty much the same error ^^
21:45:00	apriori_	wrong function prototype
21:45:06	apriori_	ptr ptr needed...
21:45:35	Araq	well if you used c2nim it should be *consistently* wrong :-)
21:45:44	apriori_	yup, it is
21:45:55	apriori_	but I'd need to test every single function anyway
21:46:20	apriori_	luckily there aren't many
21:47:52	apriori_	awesome.. 2 functions already working :P
21:49:13	apriori_	oh.. just 71 left :P
21:50:10	Araq	maybe you should search and replace for TCLPlatform?
21:50:18	Araq	and replace it by PClPlatform?
21:50:41	apriori_	yeah, I did that already
21:52:48	Araq	proof reading should be faster than testing
21:55:10	apriori_	well, maybe..
21:55:21	apriori_	I'm checking signatures with the khronos documentation
21:55:41	apriori_	but sometimes.. its kinda weird
21:55:51	apriori_	not quite sure, what convention I should follow, because:
21:56:16	apriori_	e.g. clGetDeviceIDs takes "cl_platform_id".. which is a typedef struct _cl_platform_id * cl_platform_id
21:56:21	apriori_	so a pointer
21:56:56	apriori_	but.. TCLPlatform_id{.pure, final.} = object, PCLPlatform_id = ptr TCLPlatform_id
21:56:59	apriori_	its kinda confusing
21:57:21	apriori_	because also cl_platform_id * occurs in other functions
21:57:42	apriori_	so maybe I should just make the pointer to the objec the "base type" and call it TCLPlatform_id..
21:57:50	apriori_	any recommendations about that?
21:57:54	Araq	if that helps you sure
21:57:54	zahary	Araq, what exactly does happen when I say type csize {.importc: "size_t".} = int? does this somehow alter the existing representation of int?
21:59:08	Araq	zahary: there is no canonicalization for integral types, see ccgutils.GetUniqueType
21:59:20	apriori_	Araq: but its not really possible to direct write: TClPlatform_id*{.pure, final.} = ptr object
21:59:25	apriori_	so I need a dummy type, I gues
21:59:27	apriori_	*guess
21:59:54	Araq	to answer your question, there will be 2 or more tyInt objects, one of name "size_t" (typ's sym)
22:00:25	Araq	apriori_: yeah; 'ptr object' is planned though
22:00:47	apriori_	ok
22:02:30	Araq	zahary: the compiler has not been written with this in mind though, so there should be bugs with this feature
22:02:31	zahary	well, I would expect that, but suddenly after adding an innocent "unsigned int" in os.nim, I started to get errors in other modules - some var int procs became unsigned int*
22:03:58	Araq	C++'s type safety is hurting us, hu?
22:04:02	zahary	the PITA is that C++ doesn't like int* to unsinged int* conversions
22:06:25	Araq	*shrug* introduce unsigned ints to the compiler instead
22:07:09	Araq	my plan was to get rid of tyInt8..tyInt64 and have tyInt, tyIntX, tyUInt and tyUintX
22:07:09	zahary	well, yeah, but not tonight :)
22:07:29	Araq	the type's size can be used to determine the number of bits
22:07:41	Araq	but most of the time the code doesn't care anyway
22:07:56	Araq	so it's better to conflate them and make the enum smaller
22:09:11	zahary	the migration to C++ also triggered some kind of memory corruption involving sequences - I haven't quite figured out what's going on, but it's related to the use of Sup in C vs the direct inheritance in C++
22:09:29	Araq	that's strange
22:09:41	Araq	some different alignments ...
22:09:48	Araq	but that shouldn't happen
22:11:52	zahary	I don't know how often is triggered, I need only to comment a single use of the fileinfos sequence (global variable) in the compile to get a successful bootstrap
22:13:25	Araq	maybe you just triggered different code generation and the compiler keeps a negative offset pointer as root
22:13:58	Araq	we talked about it, it's a possibility and we can't work around it
22:14:07	Araq	though it's unlikely
22:18:17	zahary	I'm curious, why try blocks have a call to setFrame?
22:19:02	zahary	isn't that duplicated effort with the normal pushFrame at the start of the proc?
22:20:07	Araq	because it's non local control flow and the framePtr points beyond the current stack
22:20:26	Araq	it points into garbage if it returns via a longjmp
22:20:32	Araq	and that's bad for stack traces :-)
22:20:45	zahary	aha, that's required after the jump
22:27:21	apriori_	I assume it makes no sense to actually "port" headers guards, does it?
22:27:46	Araq	apriori_: no ... :-)
22:28:26	apriori_	good
22:30:31	apriori_	is there a "defined" thingy for unix systems?
22:30:54	apriori_	in the docs I just see a block of defined(windows), defined(macosx), else...
22:30:57	Araq	there is a 'when defined(unix)'
22:31:06	apriori_	good
22:31:09	Araq	and a 'when defined(posix)'
22:31:24	apriori_	ok, thank you
22:32:32	Araq	good night
22:32:37	apriori_	bye
23:19:52	*	apriori_ quit (Quit: Konversation terminated!)