<< 12-09-2013 >>

---

00:03:22	*	mac01021 joined #nimrod
00:31:16	*	ltbarcly joined #nimrod
00:35:51	*	ltbarcly quit (Ping timeout: 245 seconds)
00:38:16	*	ltbarcly joined #nimrod
00:42:56	*	ltbarcly quit (Ping timeout: 245 seconds)
00:44:17	*	ltbarcly joined #nimrod
00:49:05	*	ltbarcly quit (Ping timeout: 268 seconds)
00:49:49	*	ltbarcly joined #nimrod
00:56:41	*	mac01021 quit (Ping timeout: 245 seconds)
00:58:46	*	ltbarcly quit (Ping timeout: 245 seconds)
00:59:48	*	ltbarcly joined #nimrod
00:59:56	*	brson quit (Quit: leaving)
01:00:28	*	DAddYE quit (Remote host closed the connection)
01:02:43	*	ltbarcly quit (Client Quit)
01:12:00	*	mac01021 joined #nimrod
02:22:33	*	q66 quit (Quit: Leaving)
02:45:24	*	ltbarcly joined #nimrod
02:52:46	*	ltbarcly quit (Ping timeout: 256 seconds)
02:53:14	*	XAMPP joined #nimrod
02:53:24	*	XAMPP quit (Changing host)
02:53:24	*	XAMPP joined #nimrod
03:02:09	*	DAddYE joined #nimrod
03:08:20	*	DAddYE quit (Ping timeout: 245 seconds)
03:39:13	*	brson joined #nimrod
03:44:04	*	ltbarcly joined #nimrod
03:47:59	*	ltbarcly quit (Client Quit)
03:52:05	*	mac01021 quit (Ping timeout: 248 seconds)
03:55:41	*	ltbarcly joined #nimrod
04:00:35	*	OrionPK quit (Quit: Leaving)
04:05:24	*	DAddYE joined #nimrod
04:07:45	*	ltbarcly quit (Ping timeout: 276 seconds)
04:09:44	*	ltbarcly joined #nimrod
04:11:40	*	DAddYE quit (Ping timeout: 245 seconds)
04:14:54	*	ltbarcly quit (Ping timeout: 276 seconds)
04:17:22	*	ltbarcly joined #nimrod
04:22:19	*	ltbarcly quit (Ping timeout: 256 seconds)
04:23:24	*	ltbarcly joined #nimrod
04:28:31	*	ltbarcly quit (Quit: Computer has gone to sleep.)
04:40:04	*	ltbarcly joined #nimrod
04:44:35	*	ltbarcly quit (Ping timeout: 240 seconds)
04:46:35	*	ltbarcly joined #nimrod
04:50:53	*	ltbarcly quit (Client Quit)
04:56:28	*	DAddYE joined #nimrod
04:58:55	*	Associat0r joined #nimrod
05:01:04	*	Associ8or quit (Ping timeout: 264 seconds)
05:46:55	*	DAddYE quit (Remote host closed the connection)
05:56:13	*	brson quit (Quit: leaving)
06:01:08	*	MFlamer joined #nimrod
06:01:25	MFlamer	Hey Araq, you around?
06:11:32	*	comex quit (Ping timeout: 260 seconds)
06:11:39	*	comex joined #nimrod
06:12:21	*	MFlamer quit (Ping timeout: 250 seconds)
06:15:55	*	DAddYE joined #nimrod
07:02:09	*	ltbarcly joined #nimrod
07:28:22	*	DAddYE quit (Remote host closed the connection)
07:28:54	*	DAddYE joined #nimrod
07:33:20	*	DAddYE quit (Ping timeout: 245 seconds)
08:29:31	*	DAddYE joined #nimrod
08:35:51	*	DAddYE quit (Ping timeout: 245 seconds)
08:56:28	*	Araq_ joined #nimrod
09:00:52	*	Araq__ joined #nimrod
09:04:35	*	Araq_ quit (Ping timeout: 245 seconds)
09:24:27	*	Araq__ quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812])
09:32:40	*	DAddYE joined #nimrod
09:38:45	*	DAddYE quit (Ping timeout: 245 seconds)
09:45:24	*	q66 joined #nimrod
10:08:24	*	Araq_ joined #nimrod
10:35:44	*	DAddYE joined #nimrod
10:42:05	*	DAddYE quit (Ping timeout: 245 seconds)
10:49:35	*	Araq_ quit (Ping timeout: 245 seconds)
11:09:06	*	Araq_ joined #nimrod
11:38:48	*	DAddYE joined #nimrod
11:45:01	*	DAddYE quit (Ping timeout: 245 seconds)
12:03:42	*	shevy joined #nimrod
12:32:01	*	Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812])
12:41:48	*	DAddYE joined #nimrod
12:48:20	*	DAddYE quit (Ping timeout: 245 seconds)
13:10:52	*	faassen joined #nimrod
13:44:57	*	DAddYE joined #nimrod
13:52:06	*	DAddYE quit (Ping timeout: 276 seconds)
14:06:50	*	noam_ quit (Read error: Connection reset by peer)
14:10:05	*	noam_ joined #nimrod
14:30:24	*	faassen quit (Quit: Leaving.)
14:44:51	*	Hannibal_Smith joined #nimrod
14:48:17	*	DAddYE joined #nimrod
14:54:14	*	shodan45 joined #nimrod
14:54:35	*	DAddYE quit (Ping timeout: 245 seconds)
14:57:26	*	ltbarcly_ joined #nimrod
14:59:06	*	ltbarcly_ quit (Client Quit)
15:44:17	*	Mat2 joined #nimrod
15:44:20	Mat2	hi all7
15:44:25	Mat2	eh hi all
15:51:29	*	DAddYE joined #nimrod
15:52:11	*	Mat2 is now known as Mat2-coding
15:57:30	*	DAddYE quit (Ping timeout: 245 seconds)
16:07:10	*	brson joined #nimrod
16:32:09	*	Araq_ joined #nimrod
16:57:40	*	DAddYE joined #nimrod
16:59:11	*	MFlamer joined #nimrod
16:59:29	Araq_	hi MFlamer, now I'm around
16:59:49	Mat2-coding	hi Araq_
17:00:11	Araq_	servus Mat2-coding
17:01:10	MFlamer	cool, I wanted to ask what types you see being stored in our lock free table? We can easily store 32 or 64bit types and pointers. But any use of a pointer after is not going to be atomic
17:03:06	Araq_	not sure what you mean. do you mean the table takes over the ownership of some pointer I pass to it?
17:09:02	Araq_	well in any way the table should support for keys every type that has a 'hash' implementation and for values every type
17:09:45	MFlamer	No, I guess I'm having trouble wrapping my head around how atomically getting a pointer to shared memory is useful. What can a thread do with it? One you have multiple threads stomping on an object in shared memory, things are screwed anyway, correct?
17:11:35	Araq_	well no
17:11:55	Araq_	a shared hash table is very useful for lots of things
17:12:15	Araq_	that it is "lock free" is only an implementation detail to make it faster
17:12:42	MFlamer	The lock free table can only store 32 or 64 bit types as values, due to the underlying need for atomic load, store and CAS operations. Is that useful enough?
17:12:53	Araq_	look at the profiler's code for a good use case
17:14:00	Araq_	I'm not sure of the details but you should be able to reserve a slot with these atomic operations
17:14:27	Araq_	and once you have a slot you can copy the values into it with no syncronisation
17:17:08	Araq_	I guess you need a "version number" for the table or a stride of it and if the version changed, you need to retry
17:17:54	Araq_	essentially implementing a special cased STM
17:22:03	MFlamer	I think the idea is that using atomic ops you can get a pointer from the table, then use acquire and release semantics to safely modify the object. Something like that. I have a simple prototype now I need to get the dynamic resizing implemented.
17:24:27	Araq_	yeah but you may be right that the Java implementation relies on the fact it only stores two pointers
17:24:43	Araq_	for the (key, value) pair
17:24:55	MFlamer	Yes
17:25:26	Araq_	well for a first implementation that would be fine too
17:26:20	MFlamer	Anyway, I'm make good progress and it's an interesting subject. I just wanted to be clear on your opinion. I'll keep you posted on my progress.
17:27:01	Araq_	excellent
17:27:36	Araq_	btw that is one of my
17:29:36	Araq_	points really: the complexity of STM seems to come from the fact that STM needs to be able to deal with an arbitrary number of store operations. For special cases like a hash table that is not necessary and should be much simpler to implement
17:32:12	MFlamer	Yes, I agree. Good call. I think a good STM implementation will be good as a future project. Apparently the newer gcc has some features related specificly to stm, might be interseting to look at later
17:33:46	Araq_	yup
17:34:04	Araq_	and btw requiring gcc 4.8 or whatever for that to work is fine with me
17:34:17	*	ltbarcly_ joined #nimrod
17:34:20	MFlamer	sweet. makes life easier
17:34:28	Araq_	we can always make somebody provide workarounds via inline assembler later
17:34:39	MFlamer	got it
17:34:58	Araq_	in fact you can do it
17:35:19	Araq_	just dissamble the asm and look how it works ;-)
17:35:59	MFlamer	I'm gonna be low level concurrent god by the time this is done
17:36:09	MFlamer	:-)
17:36:21	*	Mat2-coding fdbg is a nice tool wor this kind of work
17:36:36	MFlamer	I gotta get back to paying the bills in C++. catch you later
17:36:48	Araq_	alright, have fun
17:36:50	MFlamer	fdbg, ok
17:37:17	*	MFlamer quit (Quit: Page closed)
17:59:46	*	Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812])
18:04:06	*	Araq_ joined #nimrod
18:09:29	*	Associat0r quit (Quit: Associat0r)
18:11:32	*	Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812])
18:23:35	*	DAddYE quit ()
19:08:25	*	Hannibal_Smith quit (Quit: Sto andando via)
19:43:54	reactormonk	is there a sleep() in nimrod / JS?
19:45:15	reactormonk	hm, any setInterval?
19:52:16	reactormonk	no shift on seqs? Or next on iterators?
19:54:23	Mat2-coding	what do you mean with 'shift on seqs' ? You can access sequence elements indexed
19:54:40	*	zahary joined #nimrod
19:56:27	reactormonk	always need the next element, so I try to find a way so I don't have to explicitly store the items ;-)
19:56:32	reactormonk	s/items/contexts/
20:00:15	Araq	reactormonk: you wanted c++ support in c2nim, now use it ;-)
20:00:25	reactormonk	Araq, all in due time
20:00:38	Araq	well I am not working on it any more
20:00:44	Araq	I will fix bugs of course
20:01:33	Araq	turned out that the parsing of C++ is actually quite boring and not the challenge that I hoped for :P
20:02:43	reactormonk	Araq, and also nasty?
20:03:04	Araq	nope
20:03:14	Mat2-coding	you want an iterator just for accessing an element successor, is that right ?!??
20:03:29	reactormonk	yup
20:03:29	Araq	not any nastier than C anyway
20:04:01	reactormonk	spiral(tilingArea(activeClient), 0.5, relevantclients()).items # nice try?
20:05:13	reactormonk	what's the best way to get an iterator I can iterate over?
20:06:20	Araq	arbitrary lookahead + back tracking is required by both; c++ only adds "ahead of time token stream injection" for the >> shift operator that can close 2 nested template parameter lists
20:07:57	Araq	would make another nice blog post about how mutable state does simplify programming ;-)
20:08:54	Araq	or maybe I'm just too unimaginative how it can be done in FP
20:09:43	reactormonk	Araq, can you explain the problem >> solves?
20:10:00	Araq	reactormonk: iterators are not first class so what you want is not easily doable in your way
20:10:07	reactormonk	kk
20:10:20	Araq	use seq + an index
20:10:25	Mat2-coding	you would define a tail-recursive closure for example, which iterate over the sequence
20:10:58	Araq	Mat2-coding: that is possible with first class iterators but these turned out to be VERY buggy
20:11:18	Mat2-coding	I agree
20:11:43	Araq	reactormonk: templateA<templateB<int>> is allowed in C++11
20:12:02	Araq	note that >> is however the shift right operator in C++
20:12:33	Araq	so the parser needs to patch it into > >
20:13:59	reactormonk	Araq, btw, how do I use setInterval?
20:14:38	Araq	how I am supposed to know? I only know about the JS backend, I don't know much about JS or its library in particular
20:15:01	*	XAMPP quit (Ping timeout: 248 seconds)
20:20:06	reactormonk	it wants a cstring function name
20:20:13	reactormonk	how do I generate one from my proc?
20:22:36	Araq	astToStr(procname) ?
20:24:53	dom96	reactormonk: You sure the proc signature is not wrong?
20:33:41	Araq	ping zahary, zahary_
20:35:01	zahary	pong Araq
20:35:06	Araq	https://pay.reddit.com/r/rust/comments/1d9rko/memory_safe_cc_time_to_flip_the_switch/c9p2aon
20:36:29	zahary	this is not true. references extend the lifetime of temporaries
20:37:27	zahary	The second context is when a reference is bound to a temporary. The temporary to which the reference is bound or the temporary that is the complete object to a subobject of which the temporary is bound persists for the lifetime of the reference except as specified below. A temporary bound to a reference member in a constructor’s ctor-initializer (12.6.2) persists until the constructor exits. A temporary bound to a reference parameter in a function call (5.2.
20:39:40	zahary	although I have to look at the definition of min to see the return type
20:43:50	Araq	well it outputs 0 on my machine
20:44:00	Araq	it should output 3
20:46:13	Araq	well if it's true, I think our destructors design is actually really good. It ensures it's bound to a variable so you know when the destructor is invoked (at the variable's scope ending)
20:46:22	zahary	std::min indeed returns by reference and the problem is valid, because the "binding to temporary" is indirect here
20:48:22	zahary	temporaries are nice for shorter code
20:48:41	Araq	nice you have the ansi c++ standard under your pillow btw ;-)
20:48:42	zahary	we can also solve the issue by not destructing them "at the semicolon" as in C++
20:49:23	zahary	:) google found the quote for me
20:50:59	Araq	yeah we can do proper lifetime and escape analysis to deal with it
20:51:57	Araq	but it makes me proud of the current design anyway :-)
20:52:39	zahary	I meant a simpler solution.
20:52:39	zahary	basically, with explicit variables you propose the code to be written like this
20:52:39	zahary	var a = string("foo")
20:52:39	zahary	var b = string("bar")
20:52:39	zahary	var c: var string = min(a, b)
20:52:40	zahary	…
20:52:40	zahary	c goes out of scope before a and b
20:53:21	zahary	you can assign the same lifetime to the temporary just as if there was a variable declared at the spot
20:54:22	zahary	string here is something like the C++'s string (object with destructor)
20:54:42	Araq	sure but the 'var string' shouldn't invoke the destructor at scope exit
20:55:06	Araq	it's only an alias
20:55:12	zahary	yes, it doesn't
20:55:27	zahary	the lifetime of a and b is important here
20:55:52	Araq	yeah and it's obvious because we made the programmer name them explicitly
20:56:42	zahary	yes, but I'm saying that the compiler can inject "faux variables" when seeing expressions such as min(string("foo"), string("bar"))
20:57:12	Araq	but what is the (dynamic) scope of these faux variables?
20:57:18	Araq	how do you compute the proper scope?
20:57:32	zahary	exactly the same if you had written normal variables on the previous line
20:58:19	Araq	if a and (let temp = ...; ) # oops
20:58:59	Araq	you must not do the 'let temp = f()' before 'if a' is true
21:00:28	zahary	I'm not quite following. is "let temp" injected here or written by the user?
21:00:41	reactormonk	dom96, that's what dom.js is
21:00:47	Araq	ok one step back:
21:00:58	Araq	if a and f() # original code
21:01:11	Araq	f returns a destructable type
21:01:21	Araq	the compiler must not rewrite it to:
21:01:25	Araq	let temp = f()
21:01:32	Araq	if a and temp: ...
21:02:04	zahary	well, sure - you take my words too literally
21:02:42	Araq	it can rewrite it to: if a and (let temp = f()) but then you have:
21:02:51	zahary	the problem with C++ is the early destruction - temporaries are destroyed on the nearest semicolon - basically you want to keep them alive in a scope greater than the newly introduced alias (that can be a return value from a function call involving the temporary)
21:03:58	Araq	if a and (let temp = f()) { ... } # destructor called at }
21:04:52	Araq	whereas if the programmer writes it, it is: { let temp = f(); if a and temp ... { } } # destructor called at }
21:05:16	Araq	hmm makes me think if what we do here is actually sound wrt conditionals
21:06:12	zahary	what's wrong with the first example? the destructor is called when the if block finishes, which sounds right
21:07:03	Mat2-coding	zahary: How do you set the right position for invoking destructors ?
21:07:20	zahary	we invoke destructors manually in the C code
21:08:17	Araq	oh but it's not
21:09:02	Araq	if a or (let temp = f()): ... # destruct temp here?
21:09:16	Araq	however the explicit 'temp' doesn't help us
21:09:26	*	shafire joined #nimrod
21:09:36	shafire	I knew, you were it ;)
21:09:39	Mat2-coding	hi shafire
21:09:43	shafire	hi Mat2-coding
21:10:01	Araq	in fact ... the scope doesn't reflect the conditional life-time, nor can it
21:10:58	Araq	the explicit 'temp' helps a bit because you cannot access it in the body anyway and expect it too work
21:11:24	Araq	unless you do 'if not a: echo tmp' ... gah
21:11:29	Araq	in the body
21:12:20	Araq	makes me wonder how C++ does that, I need to try it
21:13:02	zahary	again, C++ destroys temporaries at the nearest semicolon (whole expression)
21:13:03	Mat2-coding	invoking destructors as soon as possible I suggest
21:13:23	zahary	if(foo()) {} // the return value of foo will be destroyed before entering the if block
21:13:55	Araq	ah yeah
21:14:11	Araq	so it can invoke the destructor unconditionally
21:14:31	Araq	well hmm
21:15:09	zahary	I'm still not completely grokking your previous argument. why cant I destroy the temporary only if it was created at the end of the if block?
21:15:37	zahary	but anyway - even this is not a real problem, because only newly created aliases pose the risk we are discussing here
21:16:09	zahary	is it valid to write if a and (b: var T = min(T(), T()):
21:16:36	Araq	well one problem is that the constructor might be called in a condition
21:16:43	zahary	if a and (let b: var T …
21:16:52	Araq	and the destructor needs the same condition
21:17:09	Araq	we can't simply invoke it at some scope end
21:17:43	Araq	look at my 'or' example
21:18:51	Mat2-coding	need some sleep, ciao
21:19:00	*	Mat2-coding quit (Quit: Verlassend)
21:19:01	Araq	good night Mat2-coding
21:19:42	zahary	it seems to me that generating a code that calls the destructors in the reverse order the objects will potentially be constructed is enough - there should be labels in the code that allow me jump to execute a subset of the destruction sequence
21:21:46	Araq	well you need to produce this:
21:22:12	Araq	if a or (let tmp = f(); f_constructed = true): ...
21:22:25	Araq	if f_constructed: destruct(tmp)
21:31:28	zahary	my point is that you don't need this.
21:31:28	zahary	there are number of conditionals before the if block is entered - these can be mapped to multiple if statements
21:31:28	zahary	if condition1: goto after_if
21:31:28	zahary	create temp1
21:31:28	zahary	if condition2: goto destroy_temp1
21:31:29	zahary	create temp2
21:31:29	zahary	if condition3: goto destroy_temp2
21:31:30	zahary	normal if block
21:31:31	zahary	…
21:31:31	zahary	destroy_temp2: destroy(temp2)
21:31:31	zahary	destroy_temp1: destroy(temp1)
21:31:32	zahary	after_if:
21:32:14	*	shafire left #nimrod (#nimrod)
21:33:30	*	shafire joined #nimrod
21:35:46	Araq	I'm pretty sure this doesn't work
21:36:17	Araq	but I can't come up with a counter example right now
21:36:22	zahary	ah, I figured the problem is the "or" operator
21:36:32	zahary	ok, thinking about it
21:53:17	*	BitPuffin joined #nimrod
22:21:15	Araq	hi BitPuffin, use my new c2nim
22:24:57	BitPuffin	haha hey Araq, why?
22:56:27	*	shafire quit (Quit: Page closed)
22:58:49	BitPuffin	turning off irc to save resources
22:59:00	*	BitPuffin quit (Remote host closed the connection)
23:04:36	*	mac01021 joined #nimrod
23:04:56	Araq	hi mac01021 wb
23:05:38	mac01021	hi, Araq
23:05:55	mac01021	just checking out the channel to get a feel for how active it is
23:20:23	Araq	well check out our logs then
23:36:47	*	Associat0r joined #nimrod
23:36:47	*	Associat0r quit (Changing host)
23:36:47	*	Associat0r joined #nimrod
23:50:48	*	ltbarcly_ quit (Read error: Operation timed out)