<<20-11-2012>>

---

00:30:43	*	q66 quit (Quit: Quit)
00:34:16	zahary	Araq, what's the purpose of getUniqueType in the backend? can you give me an example of types that needs to be canonicalized to the same type?
04:45:59	fowl	hrm i cant do {.pragma: SF, importcpp.} =(
07:37:15	*	XAMPP quit (Read error: Connection reset by peer)
09:25:53	Araq	zahary: tuples come to mind and I think also generic objects are kind of structural in nimrod
09:34:31	fowl	im continuing work on sfml c++ wrapper, im attempting to sidestep inheritance with (A or B or C) types
09:34:49	Araq	hi fowl that's nice
09:34:59	fowl	its working well so far
09:35:05	Araq	dunno what (A or B or C) types are ;-)
09:35:15	Araq	sum types?
09:35:17	fowl	https://gist.github.com/4116737
09:35:20	fowl	see TDrawable
09:36:04	fowl	line 24
09:37:38	Araq	I prefer | instead of 'or' here
09:37:59	Araq	funny that it works :P
09:38:19	Araq	I mean you're creating an implicit generic with it and importcpp it
09:38:36	Araq	but hey, if it works it's fine
09:38:46	fowl	yea
09:39:35	fowl	sfml.cpp has like no code in it
09:39:39	fowl	25 lines
09:40:02	Araq	it's all lazy :P
09:40:25	fowl	I was wondering how to call C++ destructor?
09:40:50	Araq	import it "Class::~destructor" ?
09:41:08	fowl	dont you call `delete` though in cpp
09:41:45	Araq	good point; if you generate C++ and it relies on the C++ header the C++ will invoke the destructor for you
09:42:29	Araq	implicitly
09:42:34	Araq	as it's C++ code ...
09:42:56	fowl	but how do i call it from nimrod
09:43:57	Araq	hack around with .emit ...
09:44:11	Araq	you're right it's hard thanks to C++'s delete syntax
09:44:53	fowl	i was thinking like proc destroy*[A](some: var A) = {.emit "delete `some`".}
09:45:21	Araq	that could work
09:46:38	fowl	*** glibc detected *** /home/fowl/projects/newsfml/sftest: double free or corruption (!prev): 0x00000000026ac3a0 ***
09:46:41	fowl	it works :D
09:46:58	fowl	thats cuz i put it in a loop to make sure it crashed
09:47:12	Araq	yeah I figured
11:30:46	fowl	is there a conditional i can check for cpp/c
11:32:49	fowl	i want to throw {.error.} if someone tries to use sfml with c instead of getting a bunch of errors like unknown typename 'namespace'
11:40:53	Araq	I'm not sure I think it's 'when defined(cpp)'
11:44:03	fowl	ah perfect :D ty
12:56:34	*	q66 joined #nimrod
14:24:00	*	XAMPP joined #nimrod
15:23:17	*	apriori| joined #nimrod
15:25:01	*	apriori| is now known as |apriori|
15:35:19	Araq	hi |apriori|
15:35:25	|apriori|	hi Araq
15:36:09	Araq	in case you didn't notice: we're getting C#-like async support :-)
15:36:41	|apriori|	Araq: hm, I don't even know what that is :/
15:36:42	|apriori|	looking up
15:37:53	|apriori|	ah
15:37:54	|apriori|	nice :)
15:43:23	Araq	it's also a pretty cool collaborative tasking system ;-)
15:50:35	zahary	Araq, my question yesterday about getUniqueType was because I got caas to the point where it can recompile nimrod, but right now we've got around 100MB of logical memory leaks on each compilation so I'm investigating the purpose of all global caches
15:51:30	Araq	awesome :D
15:51:58	zahary	the caches for generics, methods and ropes are easy to understand, but getUniqueType is more puzzling
15:52:29	zahary	what kind of properties must it preserve between two compilations? I see that the type info is somewhat affected by it
15:52:55	Araq	it doesn't need to preserve anything afaik
15:52:56	zahary	e.g. on assignments, you want the ID tag of the object to be that of the unique type
15:53:13	Araq	otherwise rodfiles would serialize the cache somehow
15:53:57	Araq	well ... do you want caas to work with C code generation?
15:54:04	zahary	it doesn't need to preserve, because it will be rebuilt or it just doesn't store sensitive data?
15:54:30	Araq	answer my question first :P
15:54:43	zahary	what do you mean?
15:54:50	|apriori|	Araq: I just talked with my professor about the nimrod OS stuff
15:55:05	|apriori|	Araq: he would like to see it released under apache license
15:55:20	zahary	I cache the results of sem (the complete PContext) and I cache the parts of the BModule that would have been read from the C source
15:55:46	zahary	then, if merge is required I reuse the old merging code for rodfiles
16:01:42	Araq	|apriori|: that sounds good
16:02:14	Araq	why do you cache the PContext? that sounds wrong ...
16:02:46	Araq	my idea was that we already "cache" the module's PSym
16:02:58	Araq	and that contains the interface and thus everything of interest
16:03:15	zahary	what's wrong about it? if the module doesn't change and another module tries to import it, I just give them the cached Module
16:03:46	Araq	PContext is supposed to be scratch data for while processing a module
16:04:16	Araq	you either cache a whole module or you recompile a module
16:04:35	Araq	it doesn't make sense to keep the interim data structure
16:04:57	zahary	I'll review and revisit everything when the system is stable enough - right now I often need more per-module data in order to be able to properly "unload" some module before it's recompiled
16:06:14	zahary	gCompiledModules: seq[PSym] = @[]
16:06:18	zahary	I and lied actually :)
16:06:21	zahary	I don't cache the context
16:07:31	zahary	so, back to getUniqueType. it doesn't need to preserve, because it will be rebuilt or it just doesn't store sensitive data?
16:09:34	Araq	I'm still thinking about it :-)
16:09:55	zahary	it's massive hit for var types (the cache)
16:09:58	Araq	it doesn't matter if you use 'caas' for intellisense
16:10:23	Araq	obviously but I'm not of the consequences if you want codegen to work
16:10:28	Araq	*not sure
16:10:29	zahary	I want the full incremental builds experience
16:11:09	Araq	btw don't push your changes
16:11:16	zahary	sure
16:11:25	Araq	nimbuild will have branch support very soon :D
16:12:44	zahary	btw if the data in the getUniqueType cache is sensitive, it really should affect rodfiles too, because slight changes in the order of compilation can lead to different canonicalizations
16:14:29	Araq	true
16:14:44	zahary	can you explain what's important for type IDs, when it comes to canonicalization?
16:15:43	zahary	types like var T and array[ref T] can be assigned IDs that must match in all modules?
16:16:20	Araq	no 'var T' and 'array' are boring as they are pointers in C which use structural typing
16:16:39	zahary	so it's really only about tuples in the end?
16:16:41	Araq	it's only important for things that become a 'struct' in C
16:16:55	zahary	because named types are nominal anyway
16:16:59	Araq	closures for instance are affected too
16:17:36	Araq	other proc types are not
16:17:44	zahary	what about the GC? doesn't it use these IDs somehow?
16:18:00	Araq	no it doesn't
16:18:13	Araq	for RTTI in the worst case we get duplicate entries
16:18:32	Araq	but RTTI doesn't use pointer equivalence
16:18:43	Araq	except for the "of" operator
16:19:05	Araq	but "of" deals with classes anyway which use nominal typing
16:19:24	Araq	it should be buggy for DLLs though :-/
16:22:33	*	|apriori| quit (Ping timeout: 244 seconds)
16:23:32	Araq	in general the getUniqueType prevents wrong C code for everything "struct" related and optimizes/merges RTTI
16:28:46	Araq	however if you ensure that the type gets the same ID as it used to the gTypeTable caching should work, right?
16:29:07	zahary	alright, normalizing tuples is similar to normalizing generic types so I'll get that part easily
16:29:15	Araq	can't see how this cache causes the leak
16:30:03	zahary	the leaks are easily explained. after all all types link to their module, which links to all public procs, which links ...
16:30:19	Araq	and yeah invalidating modules by deleting them from gCompiledModules was my idea too
16:30:36	zahary	I have quite a lot of work to do yet for dealing with the caches. I wanted to understand them first well
16:30:56	Araq	er ... 'main.compMods' is it
16:31:14	Araq	no need to introduce another sequence for them
16:31:22	zahary	I must have renamed that
16:32:38	Araq	there is also rodread.gMods
16:32:45	zahary	I know
16:33:03	Araq	but it's irrelevant since you don't use rodfiles, right?
16:33:09	zahary	right
16:33:23	zahary	but I'll merge some of the crc checking algorithms
16:33:33	zahary	right now, I'm duplicating a bit of that
16:34:00	Araq	why is that necessary?
16:34:13	zahary	crc checking or the duplication?
16:34:19	Araq	the editor should tell nimrod what to invalidate
16:34:25	Araq	(the crc checking)
16:36:18	zahary	I plan to support dirty buffers and even syncing of buffer contents (vim and some other editors support a special protocol for that), but right now I need to test so I need crc (doesn't hurt to have it too)
16:41:08	Araq	I see
16:48:42	Araq	what's up with #254 btw? can we easily support that?
16:51:04	zahary	probably something is sigmatch, the default argument is not the last one
16:52:09	Araq	yeah I know
16:52:22	Araq	the question was if it can be supported easily
16:52:43	Araq	don't remember the nkDo transformation :P
16:52:57	zahary	theoretically, param matching is like regular expression matching. you can easily have param?
16:53:41	zahary	I think nkDo doesn't affect that
16:54:05	zahary	can you have proc foo(x: int, y = 10, z: int) right now?
16:54:18	Araq	yeah but you need named params to call it
16:54:31	Araq	foo(x=2, z=3)
16:58:36	Araq	and using a non-deterministic algorithm for param matching is insane :P
16:58:53	Araq	too slow :P
16:59:08	Araq	especially since nimrod uses full overloading resolution everywhere ...
16:59:46	zahary	I said "theoretically" :)
17:03:24	Araq	so ... I'm thinking about 'shared ref'
17:04:09	Araq	as I said GC support could use boehm but it looks easy to do with the current GC too
17:04:50	zahary	what's the plan?
17:05:17	zahary	what's out there as algorithms? is there an incremental concurrent collector?
17:05:28	Araq	yes
17:05:47	Araq	in fact the current GC has been based on a paper about such a beast
17:06:10	Araq	but for version 1 I will go for something easier ;-)
17:06:52	Araq	the basics we need are the same anyway
17:07:01	Araq	we need a stop the world mechanism
17:07:12	Araq	which we can put into 'new(x: var shared ref T)'
17:07:48	Araq	and then people can insert the barrier explicitly in some loop; I don't really like the compiler doing it behind the backs
17:08:13	zahary	what does boehm do? it uses set_context tricks to cheat the other threads into running a collect cycle?
17:08:30	Araq	it uses signals magic to stop threads
17:09:09	zahary	… but doesn't use multi-threaded collection?
17:09:09	Araq	but as I said, one new idea is to implement '--gc:mixed' and use boehm for the shared heap
17:09:21	Araq	it uses parallel marking
17:09:44	zahary	so it, must force the other threads to start executing the marking code?
17:09:56	zahary	that's what I meant - it replaces their current context?
17:10:01	Araq	no it stops all mutator threads
17:10:04	Araq	and then collects
17:10:15	Araq	but uses parallelism within its collection
17:10:16	zahary	aha, I see
17:10:47	Araq	well that's how I would implement it, I think boehm does it the same way ;-)
17:11:01	zahary	look at their code
17:11:07	*	FreeArtMan joined #nimrod
17:12:55	Araq	nah the code is ugly
17:13:23	zahary	I've looked it when we chased the interior pointer problems
17:13:43	zahary	it was relatively easy to follow
17:14:29	Araq	not for me
17:14:40	*	fowl quit (Quit: Leaving)
17:14:46	Araq	the data structure that turns into a hash table for 64bit was ... meh
17:15:17	Araq	but anyway
17:15:31	Araq	for 'shared ref' we need an even more expensive write barrier
17:15:49	Araq	it's essentially the same write barrier as today but it requires atomic inc/dec
17:15:56	zahary	yes
17:16:56	zahary	btw, a very long term question. do you think we should make strings and sequences automatic types at some point?
17:16:56	zahary	I'm interested in writing old-school threading code without paying the GC price for nimrod threads .
17:17:59	Araq	automatic types == STL like with destructors?
17:18:07	zahary	yes
17:18:16	zahary	and generally, it would be possible to create a bit more complicated programs without bringing the GC
17:18:30	Araq	should definitely become a compile-time option yes
17:18:36	zahary	ok, coolk
17:18:48	Araq	and was one reason I chose value semantics for them :-)
17:19:28	Araq	though allowing 'nil' for them is a bit awkward then
17:19:44	Araq	but we'll get rid of that too
17:19:58	zahary	yeah, you did good there
17:21:15	*	fowl joined #nimrod
17:37:09	Araq	so ... 'shared' a keyword or a pragma for a start?
17:41:40	zahary	I don't really care
17:41:58	zahary	it's fine both ways
17:46:29	Araq	I'll go with the keyword then
17:46:50	Araq	introduces new AST nodes but it's too dangerous to be a pragma
17:47:17	Araq	we could have shared[ref T] I guess ... hrm ...
17:48:09	zahary	XL was cool with its pointer types, but here you may strive for consistency
17:55:28	Araq	the more important question is whether it's tyRef + flag or tySharedRef
17:55:48	Araq	I fear it's the later as RTTI is affected by this decision
17:56:02	zahary	yes, makes sense
17:56:02	Araq	and for RTTI tySharedRef seems preferable
17:56:17	zahary	shared ref should bind stronger in overloads too
17:57:08	Araq	well I think they should be completely incompatible :-/
17:57:37	zahary	is it unsafe to use the shared write barrier on a normal ref? etc
17:57:58	Araq	you can pass 'shared ref' to 'ref' but not the other way round
17:58:15	zahary	yes, that's what I meant
17:59:18	Araq	well hrm no you can't
17:59:25	zahary	actually, isn't it the other way around, you can pass a ref to a shared ref proc?
17:59:49	zahary	shared ref to ref will be unsafe, because the normal ref write barrier will be used
18:00:06	Araq	the write barrier is not only problem
18:00:46	Araq	x.shared = unshared # but local GC collects 'unshared'
18:01:18	Araq	x.unshared = shared # requires 2 different marker procs then
18:01:36	Araq	one for the local GC and another one for the shared GC ...
18:01:36	zahary	ahm, yes
18:02:25	Araq	ok we need to improve our thread analysis pass then :-)
18:02:36	Araq	to get back some polymorphism for these pointers
18:02:58	Araq	I figured my thread analysis is in fact an application of abstract interpretation :D
18:03:23	zahary	haven't looked at it so far
18:04:32	Araq	you should ... it's creepy
18:05:02	Araq	makes me want to learn coq and prove things ...
18:12:30	Araq	if we only pick the --gc:mixed solution we can use 'ptr' for Boehm's GC ...
18:13:08	zahary	there should be unsafe ptr type. what do you mean?
18:13:44	Araq	we have the unsafe ptr type already, it's called 'ptr'
18:13:51	Araq	we can do:
18:14:07	Araq	proc new(x: var shared ref T) # future proof
18:14:14	Araq	or we can do:
18:14:33	Araq	proc new(x: var ptr T) # shared pointer; uses Boehm's GC
18:14:46	Araq	the later doesn't require changes in the type system
18:15:04	Araq	but is not a good long term solution
18:15:25	zahary	I'm still not following. new should be overloaded, right?
18:15:44	zahary	why isn't var ptr T the same as T** in C
18:16:27	Araq	well we discussed introducing another pointer type, 'shared ref' for a shared GC'ed heap
18:16:42	zahary	aha, you are thinking how to avoid that?
18:16:45	Araq	and it turns out to get complex with no subtyping between 'ref' and 'shared ref'
18:17:10	zahary	calling shared T to eliminated the confusion for example
18:17:18	zahary	call it *
18:17:46	*	apriori| joined #nimrod
18:18:14	Araq	however we can also leave 'shared ref' unnamed in the language and misuse 'ptr' for the feature
18:18:31	zahary	I dislike that. var ptr T is T** for me
18:18:46	Araq	what has 'var ptr T' to do with that?
18:19:08	zahary	proc new(x: var ptr T) irc://irc.freenode.net:6667/# shared pointer; uses Boehm's GC
18:19:15	zahary	I'm responding to this message
18:19:16	Araq	ah ok
18:20:44	Araq	well ... the more pointer types we get the harder it gets to write generic code
18:21:02	zahary	generic code should be written without ref as I have advocated before
18:21:39	Araq	true and it should be possible to make ptr/ref another param for the generic
18:21:41	zahary	the unsureAsgnRef business can be addressed with additional hidden arguments
18:22:00	Araq	I'd prefer specialization
18:22:02	zahary	or direct multiple compilation of the procs
18:22:05	Araq	yeah
18:28:30	Araq	btw you know about the ABA problem in C++, right?
18:29:16	zahary	why do you limit it to C++?
18:30:07	zahary	the time-of-check-vs-time-of-… problem?
18:30:32	Araq	it's not limited to C++, but mitigated by a GC
18:31:01	zahary	hmm, why so? it's a algorithmic problem for me
18:31:18	zahary	I could write a program that demonstrates it in nimrod
18:33:19	Araq	wait a sec, I'm looking for the paper
18:33:39	zahary	http://en.wikipedia.org/wiki/ABA_problem I'm rereading this
18:40:19	Araq	ah yeah, it's this: http://www.research.ibm.com/people/m/michael/RC23089.pdf
18:48:26	zahary	do you have to write lock-free code for the thread channels?
18:48:50	*	FreeArtMan quit (Quit: Out of this 3D)
18:50:11	Araq	no, but it would make them faster I think
18:51:14	zahary	such features can be optimized after everything else is polished
18:58:40	*	apriori| quit (Remote host closed the connection)
19:22:18	*	apriori| joined #nimrod
19:22:47	Araq	sure
19:54:34	Araq	hu?
19:54:48	Araq	the compiler still uses fastcall ...
19:55:22	Araq	not for GNU though ...
19:58:48	apriori|	http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 O_o
19:59:51	Araq	yes I'm aware ;-)
20:02:30	apriori|	out of curiosity...
20:02:46	apriori|	is it not possible to push the "discardable" pragma using pragma push for some reason?
20:03:03	apriori|	so that it will be applied to all following function declarations until "pop"?
20:03:12	Araq	you can't push every pragma, only a few selected ones
20:03:24	apriori|	okay
20:03:34	apriori|	well, maybe that's ok
20:04:04	Araq	nah it's a stupid implementation restriction
20:04:28	Araq	let me see if I can fix it, fowl moaned about it too
20:04:51	apriori|	ok
20:34:37	Araq	zahary join #nimbuild please :D
20:34:58	Araq	it now notifies when the tester has finished
20:39:52	*	apriori|| joined #nimrod
20:42:26	*	apriori| quit (Ping timeout: 244 seconds)
22:14:16	*	zahary quit (*.net *.split)
22:14:28	*	zahary joined #nimrod
22:24:34	*	ccssnet quit (*.net *.split)
22:33:49	Araq	apriori||: I've implemented this feature
22:33:54	Araq	do you want to test it?
22:34:26	apriori||	Araq: ok, on it
22:34:32	apriori||	is it in git?
22:34:37	Araq	wait a sec
22:35:43	Araq	hrm doesn't work :-/
22:39:59	apriori||	I need to go to bed now
22:40:01	apriori||	bye Araq
22:40:02	apriori||	bye all
22:40:09	Araq	bye
22:40:12	*	apriori|| quit (Quit: Konversation terminated!)
22:47:00	*	ccssnet joined #nimrod