<< 23-11-2013 >>

---

00:03:43	C0C0	I assume channels can be used in a one to many sending way?
00:03:49	*	brson quit (Quit: leaving)
00:04:01	C0C0	e.G. the organizer publishes in one channel and all the threads try to read from the same channel?
00:04:04	*	brson joined #nimrod
00:04:39	C0C0	is there a GO-like select operation for multiple channels?
00:05:02	fowl	C0C0, i believe channels.recv removes the message from the queue
00:05:36	C0C0	e.G. multiple threads can listen the same channel but only one gets the message?
00:05:50	fowl	yea
00:06:38	C0C0	ok thats good
00:14:43	*	shodan45 quit (Ping timeout: 245 seconds)
00:16:59	Araq	yeah please report the GC crash though I'm sure it's due to you using it wrong :P
00:17:27	C0C0	me too :)
00:17:39	C0C0	currently trying to use channels
00:17:58	C0C0	thing is: its hard to break down the crash into a small failing example I'm afraid
00:18:20	C0C0	so we could upload a few hundret lines of path tracer code
00:18:52	C0C0	is there a primer on how to use channels somewhere?
00:19:00	C0C0	a little example code?
00:19:20	Araq	no. nowbody knows how to use them
00:19:29	fowl	lol
00:19:45	C0C0	^^
00:20:22	leex	what does the compiler want to tell me if it says: Error: for a 'var' type a variable needs to be passed
00:20:41	leex	C0C0 and I have been getting this a couple of times now
00:20:58	leex	now when we do: channel.recv()
00:21:07	fowl	that you're trying to pass it a variable that you declared with let
00:21:28	C0C0	hmm no let anywhere^^
00:21:35	dom96	or that you're trying to pass it a literal
00:21:44	C0C0	nope
00:21:51	fowl	C0C0, bet?
00:21:59	C0C0	fowl: maybe implicitly
00:22:08	C0C0	but no let is written anywhere
00:22:09	*	BitPuffin quit (Ping timeout: 272 seconds)
00:22:14	dom96	what does the code look like then?
00:23:10	leex	dom96, fowl http://pastebin.com/yUYRXyi4
00:24:01	C0C0	so we are creating some threads, passing the channels as arguments
00:24:02	dom96	where does the error happen?
00:24:14	C0C0	line 9 used to read
00:24:17	leex	threads.nim(9, 12) Error: for a 'var' type a variable needs to be passed
00:24:28	C0C0	var i = channels.incoming.read()
00:24:52	C0C0	(but as leex said this is irrelevant to the error)
00:25:04	fowl	no it isnt
00:25:20	C0C0	well either way the error is the same
00:25:30	fowl	nimrod passes arguments as const unless you specify it as var T
00:25:52	fowl	you shouldnt be passing the channels in the thread argument
00:26:04	C0C0	how should the thread access them?
00:26:06	C0C0	globals?
00:26:09	fowl	yes
00:26:31	C0C0	ok
00:26:36	C0C0	gonna try that
00:27:01	C0C0	(it might seem we are ranting a lot here, but we acctually enjoy nimrod quite a bit)
00:27:26	C0C0	a littel to few stackoverflow questions to finde when googeling for problems though
00:27:46	C0C0	^^
00:30:37	Araq	don't ever pass TChannel around
00:30:44	Araq	use ptr TChannel for that
00:30:49	Araq	and yes. ptr not ref
00:30:59	leex	http://sprunge.us/eGWK and http://sprunge.us/jfYY
00:31:20	C0C0	ok
00:33:49	fowl	Actor support for Nimrod. An actor is implemented as a thread with a channel as its inbox.
00:33:59	fowl	maybe?
00:34:24	C0C0	Araq: how do we get a ptr to a channel?
00:35:06	C0C0	var a = TChannel[int]() ; channel_ptr = addr(a) doesnt seem to work
00:35:49	Araq	well you need to create the channel differently
00:36:11	C0C0	is there docu for that anywhere?
00:36:20	C0C0	(less wasting your time)
00:36:34	Araq	http://nimrod-lang.org/channels.html
00:36:38	Araq	open
00:37:36	C0C0	but open neither takes a ptr nor returns one ?
00:38:46	fowl	C0C0, when you create the thread pass it result.addr and job.addr
00:39:20	C0C0	öhm ok this is the direct opposite of what araq just said?
00:39:31	fowl	no
00:39:47	fowl	you do also need to open() the channel before you use it
00:40:07	C0C0	ah
00:42:01	fowl	http://pastebin.com/VsZuudpF
00:42:27	C0C0	cool thx
00:42:42	C0C0	that was what we where currently trying^^
00:44:10	C0C0	nice
00:44:14	leex	fowl: thanks
00:44:14	C0C0	this works as expected
00:44:17	C0C0	thanks a lot :)
00:45:05	leex	out of memory :D maybe we shouldn't send so much 3's to the channel :D
00:47:53	Araq	a TChannel really should be a global
00:48:29	Araq	in fact, globals are Nimrod's way to do thread communication
00:52:27	*	faassen left #nimrod (#nimrod)
00:52:45	C0C0	nice this seems to work quite fine
00:59:15	*	MFlamer quit (Ping timeout: 272 seconds)
01:16:21	*	shodan45 joined #nimrod
01:16:27	*	shodan45 quit (Client Quit)
01:18:02	*	DAddYE quit (Remote host closed the connection)
01:21:35	C0C0	Araq: but the GC is still broken
01:21:51	C0C0	since we are programming a pathtracer we have a scene object
01:22:23	C0C0	we don't really want to suply every thread with a complete copy of this scene object
01:22:38	C0C0	(however threads should only read from the scene)
01:22:51	C0C0	I guess the right way is to use a ptr to scene?
01:23:00	C0C0	and pass this to the treads?
01:24:01	*	DAddYE joined #nimrod
01:24:16	C0C0	but then what about all the objects that are GC'd in the thread heaps
01:25:26	fowl	ptrs are not gc'd
01:26:01	fowl	if you want to get a pointer to the scene data (that's a ref) do scenedata[].addr
01:26:05	C0C0	fowl but we create new objects that may hold references to objects obtained via a pointer
01:27:11	C0C0	e.g. an intersection object that stores the scene object that caused the intersection
01:27:20	C0C0	now the intersection object ist GC'd
01:27:28	C0C0	but intersection.obj is not
01:27:54	fowl	idk
01:28:37	*	DAddYE quit (Ping timeout: 248 seconds)
01:41:29	*	ics joined #nimrod
01:56:16	*	brson quit (Ping timeout: 264 seconds)
02:00:50	C0C0	thanks for all the help
02:01:02	C0C0	leex will paste a nice little picture for tonights work
02:03:40	*	EXetoC quit (Quit: WeeChat 0.4.2)
02:06:33	*	familiar125 joined #nimrod
02:08:12	leex	http://i.imgur.com/IDxzTP8.png
02:12:54	Varriount	leex, C0C0 , ooh, shiny
02:20:12	familiar125	another Nimrod ray tracer?
03:12:31	*	Demos joined #nimrod
03:28:24	*	DAddYE joined #nimrod
03:33:31	*	DAddYE quit (Ping timeout: 272 seconds)
03:36:13	*	ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
03:37:42	*	familiar125 left #nimrod (#nimrod)
03:41:40	*	ics joined #nimrod
04:03:00	*	ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
04:04:12	*	ics joined #nimrod
04:30:10	*	DAddYE joined #nimrod
04:34:57	*	DAddYE quit (Ping timeout: 272 seconds)
05:20:55	*	Demos quit (Quit: Leaving)
05:31:35	*	DAddYE joined #nimrod
05:35:58	*	DAddYE quit (Ping timeout: 245 seconds)
06:09:21	*	OrionPK quit (Quit: Leaving)
06:32:56	*	DAddYE joined #nimrod
06:37:02	*	DAddYE quit (Ping timeout: 240 seconds)
07:29:47	*	ics quit (Ping timeout: 252 seconds)
07:34:18	*	DAddYE joined #nimrod
07:39:09	*	DAddYE quit (Ping timeout: 272 seconds)
07:45:49	*	zahary joined #nimrod
08:35:40	*	DAddYE joined #nimrod
08:39:50	*	DAddYE quit (Ping timeout: 240 seconds)
09:14:34	*	Jackneill joined #nimrod
09:35:53	*	p0nce left #nimrod (#nimrod)
09:37:01	*	DAddYE joined #nimrod
09:41:45	*	DAddYE quit (Ping timeout: 272 seconds)
10:09:50	Araq	C0C0: indeed you should pass a "ptr"
10:21:28	C0C0	Araq: does that include all objects that hold refs to objects from the other heap?
10:21:59	C0C0	(e.g. intersection holds a ptr to the sceneobject)
10:38:18	*	DAddYE joined #nimrod
10:38:20	C0C0	(also: is there a way to construct a const ptr e.g. one where the underlaying object must not be changed)?
10:42:55	*	DAddYE quit (Ping timeout: 272 seconds)
10:59:52	C0C0	anyone around?
11:06:34	fowl	C0C0, no there isnt
11:10:31	C0C0	cool
11:10:57	C0C0	mind to enlighten me about the nimrod memory modell?
11:13:52	fowl	eh?
11:14:30	C0C0	I just don't get how to implement a shared data structure
11:14:37	C0C0	(in my case the scene tree)
11:14:41	Araq	C0C0: well what you should do is to GC_ref your 'ref' so that it can't be collected, cast it to ptr and then GC_unref when the threads are done with it
11:15:06	C0C0	Araq: e.G. the entire scene tree consist of ptrs
11:15:25	Araq	well it really depends on what the threads do
11:15:30	C0C0	read
11:15:32	C0C0	and iterate
11:15:40	C0C0	nothing else
11:15:42	Araq	that's fine with the approach I suggested
11:16:07	C0C0	e.G. I only have to pass the root node as pointer?
11:16:12	Araq	yes
11:16:23	C0C0	ok thx
11:17:17	C0C0	if I create new datastructures in the threads that hold refs to elements of the tree is that ok as well?
11:17:24	C0C0	sorry forgot to mention that
11:17:47	Araq	depends on if the datastructure lasts longer than the thread
11:17:56	C0C0	nope
11:17:59	C0C0	a lot shorter
11:18:02	Araq	remember that 'new' allocates on a thread local heap
11:18:16	C0C0	yeah sure
11:18:34	C0C0	but how does the GC free a local structure that holds a ref to a foreign heap?
11:19:15	Araq	good point, you must not do this
11:19:23	Araq	you have to use 'ptr' for these
11:19:46	C0C0	ok
11:19:55	Araq	it's all pretty complex and unsafe :-/
11:20:11	C0C0	yeah and for a noob like me completely intransparent
11:20:20	Araq	but hey, we'll get a better memory model "soon"
11:20:25	C0C0	:)
11:20:37	C0C0	also let me say that coding nimrod is quite fun
11:20:52	Araq	thanks
11:21:01	C0C0	(modulo having to as the channel for pretty much every littel detail)
11:21:21	Araq	well feel free to improve the implementation
11:21:46	Araq	it's very hard though :P
11:21:52	Araq	bbl
11:22:12	C0C0	(I was more considering improving documentation)
11:27:30	C0C0	if i have a ptr to a baseclass poiting to subclass are methods still resolved correctly?
11:35:01	C0C0	Araq: when I pass a member of the tree to a function that expects a ref is that valid?
11:35:10	C0C0	or do I always have to pass ptrs?
11:39:24	fowl	C0C0, method's dynamic dispatch works with ptr and ref, yes
11:39:43	*	DAddYE joined #nimrod
11:39:48	C0C0	hmm
11:39:50	C0C0	strange
11:42:32	*	EXetoC joined #nimrod
11:43:28	Araq	C0C0: methods should still be resolved properly, yes
11:43:55	Araq	'ref' can never point to members
11:44:15	C0C0	?
11:44:23	Araq	'ref' is an owning pointer
11:44:53	*	DAddYE quit (Ping timeout: 272 seconds)
11:44:58	C0C0	oh member was to be taken mir liberally
11:45:21	C0C0	the tree nodes contain seq of refs to objects or refs to objects
11:46:47	Araq	well it depends ... I would rather change the proc to take a ptr in the first place
11:47:19	C0C0	yeah did that allready
11:47:39	C0C0	but now it seems that method resolving doesn't work anymore
11:48:00	Araq	hmm that could be a bug
11:48:19	fowl	i disagree because i just tested methods with ptrs
11:48:25	C0C0	let me try to build a minimal example
11:48:30	C0C0	then we can talk better^^
11:48:57	Araq	and while we're at it ... I plan to replace allocShared's implementation to use a lock free memory allocator
11:49:16	Araq	there is some paper which claims to have an implementation too somewhere
11:50:52	*	Associat0r quit (Quit: Associat0r)
12:09:29	C0C0	funny I found a bug in the codegen
12:10:32	C0C0	http://sprunge.us/fBgQ <- minimal failing example
12:11:00	C0C0	if I use line 17 correct method lookup fails
12:11:07	C0C0	if i use line 18 codegen fails
12:11:38	*	BitPuffin joined #nimrod
12:12:54	fowl	C0C0, one method wants ptr ref T, the other one wants ptr T
12:13:06	fowl	in this case they are normal functions
12:13:48	C0C0	aah
12:15:03	C0C0	then the typchecker complains that w[0].addr is ptr ref T... so I have to use w[0][].ptr
12:15:20	C0C0	does that avoid the garbage collectors anger?
12:15:25	fowl	w[0][].addr
12:15:48	fowl	it should
12:17:08	C0C0	e.G. w[0][].addr does not preduce a reference cound modefication on the foreign heap object?
12:17:52	fowl	no it doesnt
12:18:07	fowl	its the lazy way to cast to pointer
12:19:45	C0C0	ok
12:21:40	*	BitPuffin quit (Ping timeout: 245 seconds)
12:22:30	C0C0	Araq: you might want to look into the code gen stuff anyway
12:23:27	C0C0	also there seems to be a problem with the assigning seq[A] created by the literal @[A()] to a variable of type set[B] if A is an instance of B
12:24:20	fowl	C0C0, try giving the seq a type
12:24:42	C0C0	yeah that should work
12:25:02	C0C0	(I don'T really have the problem, just stumbled uppon it during construction of the minimal sample)
12:25:40	*	BitPuffin joined #nimrod
12:27:11	Araq	C0C0: I'm quite sure it's already reported
12:27:14	C0C0	ok
12:27:20	C0C0	sorry then
12:27:26	Araq	np
12:29:27	C0C0	thanks for all the support guys
12:29:32	C0C0	working fine now
12:29:43	C0C0	now we can render images with less noise^^
12:41:03	*	DAddYE joined #nimrod
12:45:25	*	DAddYE quit (Ping timeout: 248 seconds)
12:46:45	BitPuffin	have you guys been discussing this the whole night? o.O
12:47:22	C0C0	BitPuffin: nope, went to bed at around 4am local time, started working at 11am again :P
12:47:30	dom96	hello
12:47:48	C0C0	hi
12:48:36	BitPuffin	haha :D
12:48:37	BitPuffin	nice
12:48:41	BitPuffin	hey dom96
12:49:11	C0C0	BitPuffin: weekend => I can work on fun stuff^^
12:49:13	dom96	hey BitPuffin
12:49:34	BitPuffin	C0C0: hehe :D
12:49:40	BitPuffin	dom96: sup?
12:50:29	C0C0	BitPuffin: not that my masters thesis wouldn't be fun from a theoretical point of view but unfortunately I have to depend on a 1 Million line Java codebase written by 10 generations of more or less incapable students...
12:52:32	Araq	C0C0: seems like your code would make the base for a really nice article about nimrod's concurrency model. please do it.
12:53:28	*	CarpNet joined #nimrod
12:53:34	Araq	it will take some time until that information becomes outdated for better or worse
12:53:48	C0C0	^^
12:54:27	C0C0	not sure that I understood nimrods concurrency model at all
12:56:01	BitPuffin	C0C0: sounds awesome lol :P
12:56:26	C0C0	BitPuffin: in principle its quite cool stuff really, but fixin other peoples bugs is not so much fun
12:56:35	BitPuffin	C0C0: what is it about?
12:56:52	C0C0	termination analysis for LLVM bytecode
12:57:14	BitPuffin	cool!
12:57:21	BitPuffin	what's that got to do with java though?
12:57:22	C0C0	or in my case more "proving memory correctness of llvm bytecode"
12:57:37	C0C0	BitPuffin: the chair has this pet project
12:57:39	C0C0	called aprove
12:57:54	C0C0	http://aprove.informatik.rwth-aachen.de/
12:58:13	C0C0	where AProVE was the most powerful tool for termination of TRSs in 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 and 2012.
12:58:17	BitPuffin	ah
12:58:19	C0C0	to quote there website
12:58:24	C0C0	aprove is written in java
12:58:42	C0C0	and I'm working on a new frontend for llvm
12:59:21	BitPuffin	interesting
12:59:26	BitPuffin	for verifying llvm code?
12:59:28	BitPuffin	with aprove
13:00:06	C0C0	yeah
13:00:18	BitPuffin	cool
13:01:06	C0C0	"or how I stoped worrying and lerned to love the java"
13:01:28	BitPuffin	hehe
13:01:36	BitPuffin	well Java is bad, but it works
13:03:49	C0C0	its not even that bad If you don't see it from the "what can I do it" point of view but from the "what can all the 50 people before me do wrong" view
13:04:33	BitPuffin	well it is suitable for some things
13:05:14	C0C0	yeah for "not fucking up everything" for example :P
13:05:44	EXetoC	verbosity overload
13:06:09	BitPuffin	C0C0: you mean like in C++ :P
13:06:25	C0C0	EXetoC: fun fact: wehenever I read a new piece of code, I copy it into a new editor and strip all type declarations
13:06:36	C0C0	BitPuffin: *cough*
13:07:21	BitPuffin	I don't really know why people are so scared of verbosity
13:07:40	BitPuffin	The important thing is not that it is quick to type
13:07:49	C0C0	last project I worked on was a little smaller, but C++ written BY one really capable guy with WAY to much fun with templates + hordes of students
13:08:01	BitPuffin	it's that you can read and understand the code without having to go look at its definitions and so on
13:08:20	C0C0	BitPuffin: well I really need more time to read the code with types then without
13:08:35	C0C0	a = new Set()
13:08:42	C0C0	a[tuple] = 4
13:08:49	BitPuffin	C0C0: but nimrod has types
13:08:54	C0C0	is nearly as understandabel as
13:09:28	BitPuffin	well sure with constructors etc it is really stupidly obvious
13:09:45	BitPuffin	but what about something where you pass in a string and get like a helicopter back
13:09:48	C0C0	HashSet<ImmutablePair<AbstractState,AbstractState>,LLVMReference> = new HashSet<ImmutbalePair<AbstractState,AbstractState>, LLVMRefercen>()
13:10:02	BitPuffin	haha
13:10:32	C0C0	BitPuffin: well if that hapens the compiler tells me anyway
13:10:36	BitPuffin	but yeah you shouldn't need to specify two things twice
13:10:37	C0C0	(or the IDE for the matter of fact)
13:10:55	C0C0	I whish I could just not display that crap in each and every line
13:10:55	BitPuffin	well then we are not discussing language anymore
13:11:01	BitPuffin	then we are discussing tools
13:11:02	fowl	auto foo = hash<t1, t2>()
13:11:07	fowl	;
13:11:25	C0C0	fowl: what is that supposed to say?
13:11:50	fowl	auto is a c++11 thing
13:11:52	C0C0	BitPuffin: true that, anyway I find ruby code a lot easier to read then java code
13:11:54	BitPuffin	C0C0: that in c++ you have the auto keyword
13:11:58	C0C0	fowl: I know
13:12:04	BitPuffin	C0C0: same here
13:12:08	C0C0	but still t1, t2 is cheating :P
13:12:17	C0C0	now I know you could typedef in C++
13:12:19	BitPuffin	C0C0: I like langages where you don't need an IDE to know what's going on
13:12:21	fowl	well i didnt feel like typing all that you typed lol
13:12:27	C0C0	:P
13:12:51	C0C0	BitPuffin: I don't really thing that explicit type annotations are helping reading code
13:13:00	C0C0	maybe a function argument level
13:13:06	BitPuffin	C0C0: I think it totally depends
13:13:26	BitPuffin	I mean in the case of newVector()
13:13:38	BitPuffin	you don't really need an annotation to know that you get a vector back
13:13:45	C0C0	yeah
13:13:57	Araq	the "what can all the 50 people before me do wrong" view is fundamentally flawed imho
13:14:05	C0C0	most of the time I acctually don't really care about the type (especially when reading code)
13:14:08	EXetoC	BitPuffin: isn't some of the verbosity in java for example unecessary? Anyway, I'm trying to be a little more verbose when I'm writing Nimrod code
13:14:22	BitPuffin	EXetoC: a lot of it is unnecessary
13:14:32	C0C0	BitPuffin: typedefs would be sooo very nice
13:14:35	dom96	looks like the strangeloop talks are being released ... slowly.
13:14:45	BitPuffin	I didn't say that having to repeat everything twice per line was good
13:14:50	BitPuffin	I just mean verbosity isn't bad
13:14:52	BitPuffin	just repetition
13:15:04	BitPuffin	dom96: is Araq's out?
13:15:15	dom96	I don't think so.
13:15:16	C0C0	BitPuffin: bad thing is that stuff like this is not the exception but nearly every variable I touch
13:15:24	C0C0	I was considering subclassing Hashmap
13:15:37	BitPuffin	C0C0: yeah and that's where it is bad
13:15:41	C0C0	just so I can write new MapRangeToRef()
13:15:45	C0C0	or something
13:15:52	BitPuffin	it should (like in nimrod) be optional to annotate the type
13:15:57	EXetoC	BitPuffin: ok repetition then
13:16:13	BitPuffin	and when it's really not clear from the name of the procs you are calling what you get back then you should consider annotating
13:16:32	C0C0	BitPuffin: big pluss for nimrod
13:18:15	BitPuffin	EXetoC: With verbosity I mean things like keywords or variables that are shortened in order to save one character and suddenly that word can be read as multiple different words
13:18:21	BitPuffin	causing ambiguity
13:19:10	Araq	I often wonder what the Java equivalent of math would look like
13:19:24	Araq	"we don't let you write integrals they can be hard to understand"
13:19:39	*	Amrykid quit (Changing host)
13:19:39	*	Amrykid joined #nimrod
13:19:40	Araq	"you can easily use a lim of a infinite sum instead"
13:19:57	Araq	"but we don't let you write infinite sums either. they can be hard to understand"
13:20:00	BitPuffin	everything has to be a polynomial
13:20:13	EXetoC	ok
13:20:17	C0C0	linear plz
13:20:23	Araq	"just use baby talk with ... to imply infinite repetition"
13:20:39	C0C0	don't use infinity in first place
13:20:48	Araq	yeah it's too hard
13:20:58	Araq	don't calculate this properly
13:20:59	C0C0	difference between math and java
13:21:05	Araq	use your thumb instead
13:21:08	C0C0	is that java was designed to be used by trained monkeys
13:21:27	C0C0	(and it does that job quite ok I think)
13:21:41	Araq	not really. Java fails spectacularly for this too
13:22:02	Araq	because the paradigm to embrace is then plain old procedural programming, not OO
13:22:14	Araq	procedural is much easier to get right
13:22:22	C0C0	hmm lets not go to java+OO
13:22:25	C0C0	thats a bad place
13:23:38	C0C0	I mean nimrod is a more "OOP" language then java
13:23:49	BitPuffin	oh shit
13:23:53	BitPuffin	C0C0 take cover
13:25:01	C0C0	why?
13:25:31	Araq	interesting. I consider Nimrod to be anti OO in lots of ways
13:25:40	BitPuffin	there
13:25:44	EXetoC	Russel Winder said in one of his talks that Java didn't have "true" OO until Java 8 IIRC
13:26:00	C0C0	Araq: and still its more OO then java :P
13:26:14	BitPuffin	then wtf is java
13:26:27	C0C0	at leat in nimrod I can define methods for (int) and put a int into Container
13:26:44	BitPuffin	ah
13:26:46	BitPuffin	gotcha
13:27:01	C0C0	I mean WTF?
13:27:09	C0C0	they force you to create a Main class
13:27:12	BitPuffin	does nimrod have multiple inheritance? can't remember lol
13:27:21	C0C0	BitPuffin: mutliple inheritance != OO
13:27:24	BitPuffin	C0C0: there is an integer class though xD
13:27:26	BitPuffin	no I know
13:27:31	BitPuffin	but it just came to mind
13:27:45	C0C0	BitPuffin: Imho Multiple inheritance is an extreamly bad Idea
13:27:47	Araq	EXetoC: Russel Winder is full of ridiculous claims
13:28:10	C0C0	golangs's anonymous structures are way more to my liking
13:28:11	EXetoC	ok..
13:28:17	BitPuffin	C0C0: haha a main class
13:28:23	C0C0	traits/mixins ftw
13:28:23	BitPuffin	that's not the only class they force you to create
13:28:31	BitPuffin	they force you to put everything in a class
13:28:38	BitPuffin	and that's really where the shit hits the fan for me
13:28:50	C0C0	BitPuffin: like: you have to have a fucking main class that does absofuckinglutely nothing but call main
13:29:02	C0C0	but ooohhh... lets not make ints objects...
13:29:08	BitPuffin	hahaha
13:29:48	C0C0	and well lets add generics
13:29:54	C0C0	so we can have Set<T>
13:30:09	C0C0	now what happens if you have a = new Set<Foo>()
13:30:20	BitPuffin	or better, new Set<int>
13:30:26	BitPuffin	();
13:30:28	C0C0	a.contains(new SomethingThatDoesntHaveToDoanythingwithFoo)
13:30:31	C0C0	?
13:30:37	C0C0	type error?
13:30:40	C0C0	runtime error?
13:30:47	fowl	yes?
13:30:58	BitPuffin	computer what happened
13:30:58	C0C0	no
13:31:01	C0C0	nothing
13:31:05	C0C0	returns null
13:31:12	fowl	lol!
13:31:17	C0C0	same btw for get(wrong_typed_value)
13:31:53	C0C0	took me 3 day finding that bug after some massive refactoring trusting the fucking type checker
13:32:04	fowl	multiple dynamic dispatch is way better than bound methods anyways
13:32:11	EXetoC	Araq: are you saying that's wrong? I've heard several people claim that the original meaning of OO is very different from the kind of OO that we get with the very common class keyword
13:32:16	fowl	way more useful i should say
13:32:44	C0C0	fowl: throw in a little pattern matching :)
13:33:30	BitPuffin	C0C0: but I like that you can't even create generics of the primitive type
13:33:49	C0C0	BitPuffin: yeah right? totaly OOP
13:33:52	BitPuffin	such a lovely wart
13:34:11	fowl	i didnt realize java had generics
13:34:18	fowl	why is ArrayList still used
13:34:18	C0C0	^^
13:34:23	BitPuffin	C0C0: seems like you have a lot of java talk to get off your chest lol
13:34:24	C0C0	fowl: its not
13:34:37	Araq	EXetoC: I claim Alan Kay changed the meaning of OO in order to not be blamed for the crap that resulted from it
13:34:37	BitPuffin	it is
13:34:44	fowl	i only read java, sometimes, i still see it used
13:34:48	BitPuffin	we used it a lot when learning java in school
13:35:01	C0C0	BitPuffin: °_o
13:35:03	fowl	Type x = (Type)someArrayList[i];
13:35:21	EXetoC	:E
13:35:27	C0C0	if thats in your codebase => run and hide
13:35:30	Araq	more seriously Alan Kay's definition of OO makes Smalltalk not OO, but Erlang
13:35:46	Araq	so ... it's bs all the way down
13:36:12	BitPuffin	C0C0: it is! although I don't touch that codebase anymore
13:36:15	BitPuffin	I'm liberated
13:36:17	BitPuffin	I'm nimerated
13:36:22	C0C0	^^
13:36:37	fowl	eiffel looks interesting
13:36:52	fowl	it wouldnt compile for me though so i moved on
13:36:55	BitPuffin	honestly it is a great reason that I won't go to university
13:37:04	C0C0	?
13:37:07	BitPuffin	using java causes me to burn out xD
13:37:31	C0C0	thats why I spend the whole weekend building stuff against the burning
13:38:00	BitPuffin	I guess, but I feel like school depresses you so much that you don't even have that energy when the weekend comes
13:38:09	Araq	In my not so humble opinion, programming by relying heavily on message passing has never worked and never will
13:38:09	BitPuffin	especially when you do java
13:38:41	BitPuffin	Araq: isn't that the best concurrency thing we have in nimrod atm though?
13:38:50	C0C0	Araq: I find ruby quite working & enyojable
13:38:59	BitPuffin	oh no
13:39:02	BitPuffin	C0C0 take cover!!
13:39:09	C0C0	BitPuffin: you keep saying that
13:39:20	BitPuffin	I do
13:39:27	C0C0	but I like a good flamewar
13:39:38	fowl	i came from ruby
13:39:45	Araq	C0C0: ruby is not OO by Kay's definition either
13:39:45	BitPuffin	I came from everything
13:40:02	C0C0	Araq: I don't really care about Kay's definition^^
13:40:18	Araq	;-)
13:40:34	C0C0	Araq: ruby is pretty much second only to smalltalk imho (At least sampled from the langauges I know)
13:40:44	C0C0	(with respect to "how OO is the langauge")
13:41:33	BitPuffin	I think ruby is great for hacking on small projects
13:41:38	BitPuffin	it's a much better perl
13:41:47	fowl	^
13:41:50	Araq	well I keep hearing good things about Ruby. I never used it. Python was my last dynamically typed language. ever.
13:42:00	C0C0	^^
13:42:24	*	DAddYE joined #nimrod
13:42:32	C0C0	BitPuffin: I really whish ruby had optional static typing + pattern matching
13:42:42	fowl	i hit the OO-wall A LOT in ruby
13:42:48	C0C0	fowl: ?
13:42:56	C0C0	what is the OO-wall?
13:43:19	BitPuffin	hasn't everyone experienced the oo-wall?
13:43:42	fowl	where your hierarchy becomes too specialized, you have classes for Actor, NPC, Player, Bat, Dog, etc and want to share functionality between them, end up repeating code
13:44:06	C0C0	fowl: don't use a hierarchy?
13:44:07	Araq	BitPuffin: nimrod lacks multiple inheritance (MI) but I have nothing against MI. But it's lots of work to implement.
13:44:25	BitPuffin	Araq: so do you think we will ever have it?
13:44:27	C0C0	fowl: I think I never used hierarchies with depth > 2
13:44:33	C0C0	Araq: pleas don't
13:44:35	Araq	in fact, I rather have MI than single inheritance + interfaces
13:44:42	BitPuffin	C0C0: you don't have to use it
13:45:08	Araq	SI + interfaces means you have 2 hierarchies instead of 1. I don't see how that simplifies things.
13:45:17	BitPuffin	well sure but what's left when you don't have the hierchy
13:45:20	BitPuffin	achur,hy
13:45:22	BitPuffin	you know that word
13:45:24	BitPuffin	that spells
13:45:34	BitPuffin	hierarchy
13:46:08	Araq	and the last time I thought about it, MI is more efficient than SI+interfaces
13:46:16	BitPuffin	and powerful
13:46:18	C0C0	mixins/traits is imho far superior to MI
13:46:27	C0C0	as in "more powerfull"
13:46:38	*	DAddYE quit (Ping timeout: 240 seconds)
13:46:48	BitPuffin	doesn't that have a much different usecase though
13:47:00	C0C0	BitPuffin: not really afaik
13:47:06	BitPuffin	inheritance/interfaces/MI is used for polymorphism
13:47:15	Araq	C0C0: I don't know your definition of mixins/traits to comment
13:47:16	EXetoC	Araq: dynamic languages are often used for game logic etc, but Nimrod would be fine also, don't you think? with proper dynamic loading etc
13:47:22	EXetoC	maybe having a complete VM will help too
13:47:46	BitPuffin	I'm gonna use nimrod as a scripting lang for my games
13:47:53	BitPuffin	"scripting"
13:47:56	BitPuffin	logic
13:48:02	EXetoC	but I don't know, maybe you'd have to bundle some things then. I'm not exactly an expert at this
13:48:05	fowl	EXetoC, what is dynamic loading
13:48:05	bastian_	is there any way to tell the compiler to link with another object file?
13:48:27	Araq	bastian_: {.link: "foo.o".} iirc
13:48:29	BitPuffin	all you do is that you compile the logic into a dynamic lib and load it
13:48:52	BitPuffin	well heh
13:48:55	BitPuffin	"all" you do
13:48:58	C0C0	Araq: basically fixes the diamond of death by inserting the "inherited classses" virtually in the hierarchy
13:49:10	bastian_	Araq: thanks, didn't know this is a pragma
13:50:09	Araq	C0C0: c++ has 'virtual' inheritance for this afaik
13:50:14	EXetoC	BitPuffin: it might be simple eventually
13:50:28	C0C0	Araq: hmm don't know about virtual inheritance in C++
13:50:35	BitPuffin	EXetoC: it is already rather simple I think
13:50:43	BitPuffin	of course I haven't tried it yet
13:50:49	BitPuffin	but I don't see why it'd be difficult
13:50:56	C0C0	Araq: boils down to this: you have a class A that inherrits from B and extends traits C,D
13:51:10	EXetoC	BitPuffin: we could give it a go some time
13:51:17	BitPuffin	EXetoC: sure
13:51:24	BitPuffin	I'm not doing it for my december project probably
13:51:30	C0C0	then you create a virtual hierachy A < C' < D' < B
13:52:06	C0C0	so wher C' is identical to C except that it inherits from D'
13:52:14	EXetoC	BitPuffin: so you didn't want help from me with the game? I thought we discussed it briefly when you asked dom96 about it, but yesterday you seemed unaware of that
13:52:57	BitPuffin	EXetoC: I don't know what you are talking about :(
13:53:03	fowl	EXetoC, i would just use something like lua, python, tcl, perl, lisp, scheme, you know, any of the scripting languages that are for scripting
13:53:17	BitPuffin	do you mean the potential open source game project we discussed like a week back?
13:54:05	EXetoC	yep
13:54:17	C0C0	Araq: that fixes the "OO-wall" that was described earlier, replaces multiple inheritance quite nicely and makes interfaces obsolete
13:54:27	EXetoC	fowl: ok, maybe it sucks less compared to writing all the code in one of those languages :-)
13:54:38	BitPuffin	Ah well that wasn't really a project I started or wanted help with, just something we could all do together to have something nice to show off in nimrod
13:57:06	BitPuffin	well what I mean is, it was not "my" project
13:57:35	EXetoC	yeah ok
13:58:13	Araq	C0C0: alright but then maybe "row polymorphism" does the same :P it's hard to evaluate all the newer OO'ish language features and decide what to put into in a systems programming language
13:59:13	C0C0	Araq: don't really know what row polymorphism is
13:59:23	Araq	see?
13:59:25	C0C0	^^
13:59:41	C0C0	Araq: I was just saying that traits are better then MI / Interfaces
14:00:03	Araq	yeah and now I have to look up various definitions and code examples to see if you're right
14:00:22	Araq	or you prepare an article for me :P
14:00:30	BitPuffin	yeah it feels like mixins have different meanings in every language if I'm gonna be honest
14:00:41	C0C0	BitPuffin: yeah thats true
14:01:10	Araq	so ... that's the way to get a new OO'ish feature. don't make me work.
14:01:42	C0C0	Araq: honestly I havent even checked wether nimrod cannot emulate this stuff allready :P
14:01:43	BitPuffin	Araq: how do we get you to give us competitive concurrency? :D
14:02:46	Araq	BitPuffin: pay me so I can live from Nimrod development. Then I'll show you the true meaning of perfection. :P
14:05:58	C0C0	Araq: http://blog.safaribooksonline.com/2013/05/30/traits-how-scala-tames-multiple-inheritance/ <- I finde this article quit good and short
14:10:53	BitPuffin	Araq: I already plan to donate a percentage from what I make on nimrod to nimrod :P
14:13:13	Araq	BitPuffin: thanks. Well the current problem I'm facing is that my new design is too complex and reintroduces "modes" what the write tracking tries to avoid
14:13:43	BitPuffin	Araq: you mean in for the concurrency?
14:13:49	BitPuffin	s/in//
14:13:54	Araq	yes
14:14:22	BitPuffin	modes as in when you open a file for example and specify if you are gonna read, write, or both etc?
14:14:35	Araq	modes as explained in my article
14:14:56	BitPuffin	on the blog?
14:15:07	BitPuffin	I'll go ahead and read it
14:15:27	BitPuffin	I'm not getting any response from irc.mozilla.org #identiy anyway
14:15:56	fowl	where's the blog again
14:16:48	BitPuffin	http://nimrod-lang.org/blog
14:16:55	fowl	ty
14:17:04	BitPuffin	no problemos!
14:17:27	BitPuffin	eller som man säger i götet, nemas problemas änna dåva
14:17:37	fowl	ik het van jaaaar
14:17:39	fowl	jajaja
14:18:01	fowl	sry i dont know swedish, only pig dutch
14:18:17	BitPuffin	haha :P
14:18:29	BitPuffin	EXetoC: translate
14:28:41	Araq	in fact, I fear the current concurrency model is already quite nice with the safety vs efficiency trade-off it provides. When you want shared memory efficiency you need an ownership model in your head and might as well do manual memory management then.
14:29:10	C0C0	Araq is there a way to get a const ptr?
14:29:19	Araq	no
14:31:33	Araq	perhaps you can try to make a 'distinct' pointer and provide only a read-access deref operation
14:32:24	Araq	dunno if that's feasible
14:32:32	C0C0	Araq: its not really importand
14:32:46	C0C0	I would just sleep better if my shared memory was read only :P
14:33:10	C0C0	(and would have been an interessting fact for an multithreading article)
14:37:30	Araq	usually "const" is a feeling good feature only as mutable aliases are allowed to the same memory
14:37:57	Araq	nimrod's planned write tracking doesn't have this problem
14:38:04	C0C0	nice
14:41:39	Araq	what's a polynimial part like 3*x^2 called in english?
14:43:19	C0C0	I'd guess term of degree 2
14:43:48	*	DAddYE joined #nimrod
14:45:46	BitPuffin	what the prettiest way to construct a json object in nimrod
14:45:59	dom96	Using `%`
14:46:18	BitPuffin	yeah but how do I use that
14:46:37	BitPuffin	var p: PJsonNode = %[???]
14:46:38	dom96	var obj = @{"field": %56}
14:46:44	dom96	er
14:46:46	EXetoC	BitPuffin: I don't even
14:46:48	dom96	s/@/%/
14:46:53	BitPuffin	ah
14:47:00	Araq	actually we should make that a macro
14:47:07	Araq	so only 1 % is necessary
14:48:01	dom96	indeed
14:48:07	*	DAddYE quit (Ping timeout: 246 seconds)
14:49:24	BitPuffin	Is there a module to parse x-www-form-urlencoded?
14:50:26	dom96	cgi.urldecode perhaps
14:51:24	BitPuffin	doesn't seam right
14:51:28	BitPuffin	basiaclly this:
14:51:48	BitPuffin	assertion=blablablab&audience=http://foo.com:8383
14:52:10	BitPuffin	so that I could parse that and get something that I could get form[assertion]
14:52:15	BitPuffin	err
14:52:17	BitPuffin	"assertion"
14:52:33	Araq	cgi can do that
14:53:29	BitPuffin	how?
14:53:50	Araq	dunno, look at its docs
14:53:56	BitPuffin	I am -_-
14:54:31	Araq	iterator decodeData
14:55:44	BitPuffin	isn't that actually the same format as cookies?
14:55:59	BitPuffin	so I could actually do data.getCookie("assertion")
14:57:02	Araq	no, it's similar but not the same
14:57:14	BitPuffin	ah
14:57:23	BitPuffin	well okay so I have to loop?
14:57:34	BitPuffin	since it is an iterator
14:57:46	Araq	you can loop and store it in a PStringTable
14:58:06	Araq	unfortunately cgi misses that for input strings
14:58:16	BitPuffin	hmm
14:58:28	Araq	and only provides one which reads from stdin or environment var
14:58:33	BitPuffin	maybe for what I'm doing maybe just substrining away assertion= from the start of the string is sufficient
14:58:46	Araq	don't do that
14:59:03	Araq	this way is prone to bugs
14:59:04	BitPuffin	why? all I am getting in anyways is a string with "assertion=blabla"
14:59:23	Araq	not using a real parser tends to be buggy
14:59:44	*	OrionPK joined #nimrod
14:59:44	Araq	especially in the long run
14:59:59	BitPuffin	worst thing that could happen is that someone sends a request that says "assertion=blabla&blabla=bleble" and that tries to get verified at persona and fails
15:00:01	BitPuffin	but hmm
15:00:07	dom96	just write your own parser, it's not that hard.
15:00:08	BitPuffin	there is a potential issue I guess
15:00:21	Araq	use parseCookies at least
15:00:28	Araq	this is easy to fix then
15:00:56	BitPuffin	you mean getCookie?
15:01:08	dom96	BitPuffin: Aren't you using jester?
15:01:10	Araq	or getCookie
15:01:31	BitPuffin	dom96: I am
15:01:36	Araq	in fact, add a proper 'readData' overload to cgi.nim and make a pull request
15:01:44	dom96	BitPuffin: Then doesn't it parse it for you?
15:01:46	Araq	it's trivial to add
15:01:59	BitPuffin	dom96: it's not a cookie
15:02:04	BitPuffin	it's in the body of a request
15:02:38	dom96	Yeah, jester parses that.
15:02:51	BitPuffin	say whut
15:03:07	BitPuffin	body is just a string
15:03:16	dom96	Look at request.params.
15:03:21	dom96	It's in there.
15:03:40	BitPuffin	u srs
15:04:03	dom96	yes.
15:07:47	Araq	C0C0: the designer of that new java makes a convincing argument that lambdas are more appropriate than structural typing
15:08:13	BitPuffin	let data: PJsonNode = %{"assertion": ass, "audience": hostname & ":" & $port}
15:08:19	BitPuffin	I'm doing it wrong
15:08:39	dom96	You need a % in front of each value
15:08:55	C0C0	Araq: I'm afraid I don't understand
15:09:09	BitPuffin	dom96: say what
15:09:55	BitPuffin	looks like that fixed it :s
15:09:57	BitPuffin	I don't know why
15:10:20	dom96	because % converts your string into a PJsonNode
15:10:21	OrionPK	% tells it to make a PJsonNode
15:11:00	BitPuffin	yeah I figured it out
15:14:27	BitPuffin	let ass = request.params["assertion"]
15:14:31	BitPuffin	dom96: that gives me ""
15:15:08	dom96	Why don't you echo the params and check what's actually in it?
15:18:32	BitPuffin	dom96: apparently nothing
15:18:46	dom96	what's the content-type?
15:19:53	BitPuffin	dom96: is that in request?
15:19:55	BitPuffin	obj
15:20:12	dom96	yes, in headers
15:21:01	BitPuffin	application/x-www-form-urlencoded; charset=UTF-8
15:21:19	dom96	ahh, that's a bug then hah
15:21:45	dom96	sec
15:23:57	NimBot	dom96/jester master 1a66a53 Dominik Picheta [+0 ±1 -0]: Fixes content-type detection problems.
15:24:01	dom96	try now
15:24:26	Araq	dom96: impressive bug fixing speed
15:24:40	dom96	thank you :P
15:24:51	Araq	ping zahary
15:26:27	zahary	hi
15:26:34	zahary	I gotta go out in 5 minutes
15:26:50	Araq	ok, that's enough to get you thinking about a serious problem:
15:26:55	BitPuffin	dom96: alright sec
15:27:29	BitPuffin	dom96: what's the command to update though? just babel install jester again?
15:28:00	OrionPK	yes
15:28:06	OrionPK	it asks you if u want to overwrite
15:28:10	BitPuffin	ye
15:28:12	Araq	x.shallowCopy(y) where x is a string and y is a string literal happens to work iff 'x' is a local as that doesn't invoke the wirte barrier
15:28:44	BitPuffin	dom96: looks like it worked
15:29:37	dom96	good
15:30:21	Araq	but in general can't work and there is a case where it works but fails at the second assignment because then there is no header to decref
15:30:37	Araq	however I fail to come up with a concrete scenario for this right now
15:31:38	zahary	what does shadow copy do? just replicates the pointer without increasing the ref count?
15:31:43	Araq	I'm quite sure though that's the bug that plagues nimbuild
15:31:56	Araq	shadow copy is the nkFastAsgn node
15:32:11	Araq	it performs the assignment as if the 'string' were a 'ref'
15:32:31	Araq	so in other words it checks x's location and decides which write barrier to invoke
15:32:50	Araq	for a stack location nothing is done except pointer assignment
15:33:03	zahary	I think it's ok to reuse the buffer, but you have to increase the refcount
15:33:26	Araq	there is no refcount for string literals
15:33:29	zahary	ah, yes - you are saying just that
15:33:33	Araq	though we could add one
15:34:34	zahary	gotta go, we'll get back to this latesr
15:34:42	Araq	alright
15:45:06	*	DAddYE joined #nimrod
15:49:26	*	DAddYE quit (Ping timeout: 240 seconds)
16:21:20	*	Associat0r joined #nimrod
16:21:20	*	Associat0r quit (Changing host)
16:21:20	*	Associat0r joined #nimrod
16:37:21	*	xenagi joined #nimrod
16:46:25	*	DAddYE joined #nimrod
16:50:38	*	DAddYE quit (Ping timeout: 240 seconds)
17:26:24	*	OrionPK is now known as OrionPKN
17:27:06	*	OrionPKN is now known as OrionPK
17:32:10	*	OrionPK is now known as OrionPKN
17:32:23	*	OrionPKN is now known as OrionPK
17:47:48	*	DAddYE joined #nimrod
17:51:50	*	DAddYE quit (Ping timeout: 240 seconds)
17:52:28	*	OrionPK is now known as OrionPKN
17:58:41	bastian_	Araq: is there any way to make the path in the link pragma relative to the source's file instead of where the compiler is invoked from?
18:01:26	bastian_	the C compiler is invoked with the relative name, instead of an absolute one
18:14:10	*	OrionPKN is now known as OrionPK
18:16:22	BitPuffin	EXetoC: I think I'm gonna fix linagl now :P
18:16:27	BitPuffin	hold on to your horse
18:18:17	Araq	bastian_: iirc you can do "$projectdir/foo.o"
18:18:39	*	noam_ joined #nimrod
18:21:43	*	noam quit (Ping timeout: 252 seconds)
18:22:46	bastian_	Araq: ah, so it's just passing this as a literal, i see
18:31:33	Araq	actually ... looking at the code ... $projectdir needs to $projectpath and even that is not supported but instead the compiler tries to find the file in your Path
18:32:09	Araq	so .. it should just work
18:38:53	BitPuffin	Error: internal error: invalid kind for last(tyGenericParam) err
18:39:15	BitPuffin	at least have the courtecy to tell me where it happened :(
18:39:33	Araq	it's usually some invokation of 'high'
18:39:39	Araq	or 'len'
18:40:58	BitPuffin	Araq: yeah it might be that
18:41:25	BitPuffin	https://gist.github.com/BitPuffin/7618340
18:41:29	BitPuffin	I suspect that one
18:42:52	BitPuffin	It would be really cool if I didn't have to work around my workaround
18:43:05	Araq	seriously?
18:43:15	BitPuffin	Araq: what?
18:43:24	Araq	how often are you gonna attempt C.high when C is a generic param?
18:43:37	BitPuffin	C is a range
18:43:48	BitPuffin	but I can't do that because I can't say that it is a range
18:43:52	BitPuffin	because of a compiler bug
18:44:04	Araq	well even if you tell it that doesn't help
18:44:23	Araq	that requires yet another notion of partial generic instantation to work
18:44:54	Araq	no yes. it should work. but it's not surprising that it doesn't
18:45:43	BitPuffin	I guess I could work around it by doing some vodoo of extracting the row and column and running low and high on that
18:45:44	Araq	and TMatrix[T, R.low..R.high-1, C.low..C.high-1] seems to be the same as
18:45:47	BitPuffin	pretty ridiculous but yeah
18:45:53	BitPuffin	oh yeah
18:45:56	Araq	TMatrix[T, R, C] anyway
18:45:58	BitPuffin	doesn't solve that part though
18:46:10	BitPuffin	Araq: okay well that should be -2 then :P
18:47:10	Araq	ah ok
18:47:18	Araq	it's not the same because of the -1
18:47:32	BitPuffin	it deletes a row and a column from the matrix
18:47:43	BitPuffin	if you read the ducks
18:48:28	Araq	why should I read the docs? they don't trigger the compiler bug
18:48:45	Araq	also keep in mind that currently 'r' and 'R' is the same identifier
18:48:56	Araq	so ... that would be the next problem
18:49:06	BitPuffin	Araq: well to understand what the desired effect is
18:49:08	*	DAddYE joined #nimrod
18:49:08	BitPuffin	right true
18:49:21	BitPuffin	I wrote this at first as an ideal way where there wasn't any bugs
18:49:26	BitPuffin	and couldn't test compile it
18:49:29	BitPuffin	:P
18:50:49	BitPuffin	unfortunately I can still not fix the signature :(
18:51:22	Araq	yeah sorry, seems hard to workaround
18:51:42	BitPuffin	zahary: did you fix the :range annotations to generic params? Because it doesn't appear to be failing at least. Although I don't remember the error
18:51:48	BitPuffin	right he's not here
18:51:55	BitPuffin	Araq: gah :(
18:52:10	BitPuffin	frustrating
18:52:14	*	Araq wonders how ML deals with a partially constructed array types
18:52:33	BitPuffin	This project has a deadline for december
18:53:26	*	DAddYE quit (Ping timeout: 240 seconds)
18:54:32	Araq	BitPuffin: well you can always use a 'seq' instead and do the y*m+x address computation yourself
18:54:35	BitPuffin	I guess I'm gonna have to hardcode the type of matrices I need currently
18:54:58	Araq	ugly but you can patch over it with overloaded [] operators
18:55:24	BitPuffin	is overloading of [] supported though?
18:55:33	Araq	with latest github version yes
18:55:37	BitPuffin	nice!
18:55:44	Araq	overloading of [] for seqs should work
18:55:51	BitPuffin	but arrays?
18:55:58	Araq	for arrays too
18:56:00	BitPuffin	cool
18:56:08	BitPuffin	Hmm yeah I guess that's doable
18:56:16	BitPuffin	really ugly like you say but it would work around it
18:57:08	Araq	of course ML doesn't have that problem to begin with: http://www.standardml.org/Basis/array.html
18:57:28	BitPuffin	Araq: however doesn't seqs have different literals?
18:57:32	BitPuffin	that would kind of break it :/
18:58:04	Araq	really. why? is @[] so much harder to type than []?
19:01:58	BitPuffin	Araq: the hard to type thing is not a factor
19:02:02	*	OrionPK is now known as OrionPKM
19:02:05	BitPuffin	Araq: it's about changing the API
19:02:10	*	OrionPKM is now known as OrionPK
19:02:19	BitPuffin	and I don't want to change the API to something I am gonna change later anyways
19:02:41	Araq	understandable but misguided :-)
19:03:12	Araq	it's better to let APIs evolve and make people update their code for some time
19:03:53	*	OrionPK is now known as OrionPKM
19:03:56	*	OrionPKM is now known as OrionPK
19:04:00	BitPuffin	Araq: well sure, I draw the line when it's about changing the api to something worse, if I know that something is a big improvement that will of course change
19:04:04	BitPuffin	or if it is necessary
19:04:17	BitPuffin	but this is kind of changing the API in the name of a temporary workaround
19:04:41	Araq	no it's in the name of a still evolving language
19:04:47	BitPuffin	sure
19:05:04	Araq	and you have every right to use nicer features once they become available
19:05:13	OrionPK	jeez nimrod takes a long time to build on RBPI :D
19:05:22	BitPuffin	but I think API wise, even though it is quite annoying to have to do it, working aronud it by hardcoding it for certain types seems preferrable to changing the API
19:05:57	*	familiar125 joined #nimrod
19:06:15	BitPuffin	I can just temporarily when false: out the current ideal implementation and add an else: and implement the hardcoded ones
19:06:36	Araq	ok if you prefer it this way, sure go ahead
19:06:39	BitPuffin	well actually else is not even needed
19:06:55	BitPuffin	since it isn't that bad to keep the hardcoded ones for performance reasons probably
19:07:10	Araq	in fact
19:07:34	Araq	the hardcoded ones are way easier to map to CUDA or something like that
19:07:42	BitPuffin	yup
19:08:09	Araq	OrionPK: are you familiar125 ?
19:09:00	BitPuffin	yeah I think I'll do that
19:09:56	BitPuffin	Araq: does it matter if the hardcoded ones appear before or after the generic one?
19:10:00	BitPuffin	in the source file
19:10:08	familiar125	yes araq
19:10:24	Araq	no, overloading resolution is not dependent on declaration order
19:10:32	BitPuffin	Araq: okay! Good :D
19:12:23	BitPuffin	he is testing his new epic irc client
19:15:13	Araq	hmm explaining a pattern matching macro in a tutorial-like article might not have been my best idea ...
19:15:42	Araq	oh well. People can handle it, right?
19:16:00	familiar125	I was. now I'm just using it
19:16:19	BitPuffin	familiar125: so it's done?
19:16:30	Araq	"this is a case statement. And this is how to implement pattern matching without unification."
19:20:01	familiar125	no
19:20:08	familiar125	it's not done
19:27:57	BitPuffin	is there an array like type that is not homogenus?
19:29:41	EXetoC	sum type elements?
19:30:06	Araq	a tuple?
19:30:24	BitPuffin	Araq: a tuple isn't really array like, well I guess I'm asking about seq like really
19:30:42	Araq	well tup[0] works fwiw
19:34:12	BitPuffin	that's resizable?
19:34:21	Araq	no
19:35:24	EXetoC	object variants
19:36:21	BitPuffin	EXetoC: well then you might as well say subtypes
19:36:26	BitPuffin	hmm
19:36:57	BitPuffin	in the hard coded ones above 2x2 matrices, should I loop or do a huge wall of if statements...
19:37:02	BitPuffin	convenience over performance
19:37:47	Araq	use a loop
19:38:30	BitPuffin	Araq: I considered unrolling them but that would become huge
19:38:35	BitPuffin	since it's two loops
19:38:48	Araq	unrolling them is stupid
19:39:00	Araq	let the optimizer do its job
19:39:06	BitPuffin	lol okay
19:39:09	BitPuffin	:D
19:41:24	Araq	but if you really feel like it, iterators and templates make unrolling very easy to do
19:42:21	BitPuffin	nah
19:42:31	BitPuffin	I'll leave it as it is
19:43:19	Araq	write an article about an 'unroll' iterator and spam hacker news and reddit
19:44:01	Araq	extra points if you can write it Rich-style so everybody thinks you have invented something new
19:44:11	BitPuffin	matrix.nim(156, 10) Error: ambiguous call; both matrix.{}(m: TMatrix[T, range 0..1(int), range 0..1(int)], n: range 10..99(int)): T and matrix.{}(M: TMatrix[T, range 0..2(int), range 0..2(int)], n: range 10..99(int)): TMatrix[T, range 0..1(int), range 0..1(int)] match for: (Array constructor[0..1, Array constructor[0..1, int]], int literal(10))
19:44:34	BitPuffin	Araq: Rich Hickey?
19:44:45	Araq	yes
19:44:48	BitPuffin	lol
19:44:59	BitPuffin	he pretends he invented something new? lol
19:45:08	Araq	no that would be unfair
19:45:18	Araq	but he surely knows how to market things
19:45:26	BitPuffin	you mean understating it
19:46:05	Araq	what?
19:46:11	Araq	understate it?
19:46:30	BitPuffin	yeah that he's pretending he invented something
19:47:03	Araq	I'm not saying that
19:47:40	BitPuffin	seriously is this a bug or what
19:47:47	BitPuffin	how can that be an ambiguous call
19:47:52	BitPuffin	uouououos
19:48:16	Araq	I fixed that bug once
19:48:23	Araq	no idea why it pops up again
19:48:29	BitPuffin	https://gist.github.com/BitPuffin/7619079#file-gistfile1-nim-L48
19:49:26	BitPuffin	oh so you mean unfair then. You mean that people are acting like he invented it because he markets it cleverly
19:50:02	Araq	I mean it would be unfair of me to say that
19:50:23	*	DAddYE joined #nimrod
19:50:30	BitPuffin	you mean it is too much to say it?
19:50:43	Araq	yes
19:50:49	BitPuffin	gotcha
19:50:52	BitPuffin	weird bug
19:50:59	BitPuffin	especially if you have fixed it before
19:53:22	BitPuffin	Araq: ah it's an inference thing
19:53:38	BitPuffin	Araq: If I am specific about its type it works
19:53:46	BitPuffin	although that should not really be necessary I think but yeah
19:54:33	BitPuffin	at least it's not a fatal bug
19:54:43	*	DAddYE quit (Ping timeout: 245 seconds)
19:56:36	familiar125	araq so hard would it be to implement a linq like feature in nimrod
19:56:50	BitPuffin	it would be so hard?
19:56:51	familiar125	how'
19:56:57	Araq	not hard
19:57:05	familiar125	sorry. on my phone
19:57:09	Araq	macros easily can do it
19:57:18	familiar125	cool
19:57:23	Araq	but in my article I'm showing pattern matching
19:57:38	Araq	so ... currying and Linq have to wait
19:58:00	BitPuffin	I'll add currying next year
20:00:03	EXetoC	nom
20:04:20	BitPuffin	matrix.nim(129, 0) Error: redefinition of '{}'
20:04:23	BitPuffin	I BEG TO DIFFER
20:04:37	BitPuffin	Araq: same bug I reckon?
20:05:27	Araq	quite possible though I don't remember adding a check for that
20:05:47	BitPuffin	if not that would be amazing
20:06:02	BitPuffin	because then it would work xD
20:10:08	Araq	BitPuffin: wanna fix that bug?
20:10:30	BitPuffin	Araq: Yeah
20:10:34	BitPuffin	I'll have to
20:10:39	BitPuffin	or else this project won't get done :P
20:11:50	BitPuffin	Araq: but first a bug report is needed
20:11:56	BitPuffin	to mark the progress etc
20:13:22	Araq	well tell me when you're ready
20:13:38	BitPuffin	sure
20:13:43	BitPuffin	just gonna eat dinner now!
20:13:46	BitPuffin	I've been bbqcodin
20:21:44	*	ack006 joined #nimrod
20:22:39	Araq	hi ack006 welcome back
20:23:58	BitPuffin	we should program NimBot to keey track of who's been here before and who hasn't and greet the newcomers with a welcoming message
20:24:22	BitPuffin	Araq simply doesn't scale the way a bot can xD, now back to eating
20:26:07	Araq	hey I scale quite well.
20:26:27	Araq	hi Kristina welcome
20:27:06	BitPuffin	I din't say you scale bad
20:27:10	Kristina	Hi.
20:27:12	BitPuffin	but not as good as a bot
20:28:55	*	ics joined #nimrod
20:30:18	C0C0	how do I create a sequence literal @[A(),A()] whith type seq[B] (where B is parent of A)?
20:30:40	Araq	@[B(A()), A()]
20:30:47	C0C0	ah ok :)
20:51:50	*	DAddYE joined #nimrod
20:52:07	BitPuffin	Araq: https://github.com/Araq/Nimrod/issues/686 good enough?
20:53:21	Araq	sure. now fix it
20:53:28	BitPuffin	yes
20:54:35	BitPuffin	Araq: would an acceptable solution be to find the place where it fails and just check if the type is a generic and then look if the params are different?
20:55:05	Araq	1) use a debug build of the compiler
20:55:15	Araq	2) invoke the compiler with --verbosity:3
20:55:21	Araq	3) pastebin the stack trace please
20:55:37	BitPuffin	sure thing
20:55:46	BitPuffin	just a sec ;D
20:56:14	*	DAddYE quit (Ping timeout: 240 seconds)
21:03:32	*	Jackneill quit (Remote host closed the connection)
21:12:43	BitPuffin	Araq: https://gist.github.com/BitPuffin/7620016
21:14:05	*	ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
21:18:38	BitPuffin	holy koch that's a big proc
21:18:54	Araq	it's also irrelevant
21:19:12	BitPuffin	(semProcAux)
21:19:20	BitPuffin	is it? okay, I was just going up the trace one by one
21:19:28	Araq	the problem is that procfind.SearchForProc returns not nil even though it should
21:19:38	Araq	as the header clearly differs
21:20:06	Araq	and this seems to be caused by equalGenericParams returning true
21:20:33	Araq	which is caused by sameTypeOrNil(a.typ, b.typ, {TypeDescExactMatch}) returning true
21:20:57	BitPuffin	you are quick sir
21:23:25	Araq	in procfind.equalGenericParams
21:23:44	Araq	insert in line 30
21:24:34	Araq	if procA.info ?? "poop.nim":
21:24:50	Araq	debug(a.typ)
21:24:56	Araq	debug(b.typ)
21:25:13	Araq	and see what it says
21:25:21	BitPuffin	should it really be ?? and not ==?
21:26:08	Araq	yes. it's really ??
21:27:50	BitPuffin	alright, what does that do? extract filename of a proc?
21:28:22	Araq	yes
21:28:25	*	filwit joined #nimrod
21:28:53	filwit	hey folks
21:28:58	Araq	hi filwit
21:29:20	filwit	is there any proc in the macros lib that gets the name of a node without the '*' mark?
21:29:28	Araq	yes
21:29:28	filwit	or do i need to strip that out manually?
21:29:36	BitPuffin	Araq: I'm not actually sure it says anything
21:29:54	filwit	Araq: great!
21:30:46	filwit	Araq: mind given me a hint as to what it's called ? :P
21:31:16	filwit	strVal?
21:31:22	Araq	basename
21:31:33	filwit	hmmm.. thought i tried that one...
21:31:38	filwit	let me try again
21:32:00	Araq	someProc.name.basename
21:32:07	Araq	should do it
21:32:07	BitPuffin	https://gist.github.com/BitPuffin/7620204
21:32:51	filwit	Araq: awesome, it worked. Thanks
21:33:02	BitPuffin	oops some weird pasting action going on, ignore that
21:33:09	BitPuffin	read from line 16
21:33:29	Araq	BitPuffin: sorry
21:33:37	Araq	line 30 but not in that 'if'
21:33:44	Araq	but still in the 'for'
21:33:53	BitPuffin	ah
21:34:19	BitPuffin	so on line 29 then
21:36:38	BitPuffin	Araq: tyGenericParam T
21:36:41	BitPuffin	tyGenericParam T
21:38:24	Araq	well that makes sense
21:38:33	Araq	indeed those are equal
21:39:57	BitPuffin	yup
21:40:03	Araq	my bad
21:40:12	Araq	goto line 51
21:40:16	Araq	should be "return"
21:40:48	Araq	insert before the retturn (same indentation)
21:40:54	BitPuffin	master line 51 or mine :P
21:41:05	Araq	master
21:41:11	BitPuffin	cool
21:41:15	Araq	and you may remove the change already
21:41:28	BitPuffin	ofc!
21:41:38	Araq	if fn.info ?? "poop.nim":
21:41:47	BitPuffin	yup
21:42:09	Araq	debug result.ast.sons[paramsPos]
21:42:17	Araq	debug fn.ast.sons[paramsPos]
21:43:02	Araq	and insert into line 54
21:43:15	Araq	(now 57 I guess since you added 3 lines of code)
21:43:19	bastian_	Araq: ah, so it's just passing this as a literal, i see
21:43:39	Araq	bastian_: already told you I was wrong
21:44:12	Araq	BitPuffin: if fn.info ?? "poop.nim": echo "WTF?"
21:46:14	bastian_	Araq: sorry, accidentally reposted from history. wanted to ask about memset: the system module seem to have (zero|copy|move)Mem, but not set
21:46:51	Araq	well you can easily wrap it yourself and I've yet to see a memset that is not a zeroMem
21:47:15	Araq	memset(s, sizeof(s), 0) is a common bug
21:47:25	Araq	so Nimrod tries to improve on that
21:47:37	bastian_	i'm aware it's a one-liner to import, but maybe for consistency
21:47:52	Araq	(or was it memset(s, 0, sizeof(s)) ? ;-) )
21:47:56	bastian_	well, i'm trying to set all buckets of a bitset to true
21:48:34	Araq	fair enough but then how do we make it not as error prone?
21:50:02	bastian_	didn't even think about this. really like your API design approach of preventing potential misuse
21:50:05	BitPuffin	Araq: alright compiling
21:50:24	bastian_	not sure, maybe then it shouldn't be in system
21:52:41	filwit	Araq: i may have asked this before, but is there an easy way to remove a single Pragma from the Pragmas of a PNimNode through Macros?
21:52:43	BitPuffin	Araq: https://gist.github.com/BitPuffin/7620412
21:53:12	*	DAddYE joined #nimrod
21:54:14	Araq	BitPuffin: and here we have the bug :-)
21:54:48	Araq	the range[0..2] thing is transformed to an AnonType
21:55:10	Araq	which then compares equal ...
21:55:33	BitPuffin	that's strange
21:55:41	BitPuffin	well not that they compare equal in that case
21:55:45	BitPuffin	but that it is AnonType
21:57:26	*	DAddYE quit (Ping timeout: 240 seconds)
21:59:17	Araq	meh this is zahary's code which I don't understand
21:59:26	BitPuffin	lol :(
21:59:40	BitPuffin	what does one chant to summon zahary
22:00:00	Araq	no idea why he needs to do 'semConv(c, n, symFromType(destType, n.info))'
22:00:35	BitPuffin	is c and n (cnn lololol) context and node?
22:00:36	Araq	and btw the reason is not that we use 1 letter variables :P
22:01:17	Araq	I don't know *why* he needs to do this, *what* he does is obvious enough :P
22:01:52	BitPuffin	well I know but I'm only looking at one line that you pasted, so it's impossible to look up what the 1 letter variable name is in this case, with the full source it is a bit more trivial lol
22:01:58	BitPuffin	Guess I can ack my way to your line
22:02:14	Araq	and sure c is the context, n is node
22:02:25	BitPuffin	yay, I guessed it ;D
22:02:45	BitPuffin	see people, they aren't THAT horrible :P
22:03:56	Araq	well in any case using ExprStructuralEquivalent to compare parameter lists is a hack
22:03:58	BitPuffin	hmm, semConv, is that just to convert a symbol into a node?
22:04:16	Araq	semConv # semantic checking of a type conversion node
22:04:54	Araq	'sem' is always "semantic checking"
22:05:08	BitPuffin	I see
22:05:43	BitPuffin	and that checks whether the semantics are legal?
22:05:55	Araq	yes
22:06:01	BitPuffin	gotcha
22:06:10	BitPuffin	but what's a type conversion node?
22:06:11	Araq	it also transforms things if necessary
22:06:16	BitPuffin	and possible
22:06:21	Araq	T(a) where T ia a type
22:06:31	BitPuffin	ah
22:06:32	BitPuffin	right
22:06:36	BitPuffin	I've used those :P
22:07:48	BitPuffin	hmm, if one were to write a book on nimrod they should try to somehow sneak a node way of thinking about your code as you write it
22:08:01	BitPuffin	that way when you start looking at the compiler things make a lot of sense
22:08:17	BitPuffin	well they do make sense but it takes a while to settle :P
22:08:43	Araq	actually many things don't make any sense
22:08:51	Araq	those are the bugfixes
22:09:06	BitPuffin	the things that don't make sense?
22:09:39	Araq	http://www.joelonsoftware.com/articles/fog0000000069.html
22:10:01	Araq	"Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes."
22:11:09	BitPuffin	:)
22:11:41	BitPuffin	Well in general when you write code that does not make sense it is generally good to add a comment
22:12:16	BitPuffin	I think for regular code comments are usually not necessary
22:12:20	BitPuffin	but for bug fixes etc
22:12:37	BitPuffin	it's nice with a comment like # to fix #8493
22:12:46	Araq	yeah and I try to do that now.
22:12:49	Araq	;-)
22:13:05	BitPuffin	good!
22:13:07	Araq	but even better than fix #89 is a small example program
22:13:13	BitPuffin	I've actually read that article a long while ago
22:13:23	Araq	otherwise I need to lookup bug #89 ...
22:13:28	BitPuffin	hehe true
22:13:55	BitPuffin	but I should read it again. Not like I have anything to do really with all these bugs :P
22:14:37	BitPuffin	ambigous sentence
22:15:06	BitPuffin	I meant in the sense of things I can do while they exist, not in the way with being responsible for them
22:15:15	BitPuffin	although I guess I'm not that either but you get the point
22:16:43	Araq	filwit: I don't know, ask fowl
22:17:11	filwit	Araq: k. then no, cause i think i did and he didn't know
22:22:41	Araq	BitPuffin: try the following fix please
22:22:54	Araq	semtypes.nim:232
22:23:32	Araq	add a "modifyNode: bool" parameter to semTypeIdent
22:24:16	Araq	in line 946 pass 'false' to it, and in line 963 pass true
22:24:28	BitPuffin	sure
22:24:44	Araq	and modify line 263 to:
22:24:58	Araq	if result.typ.kind != tyGenericParam and modifyNode:
22:25:23	Araq	leave the debug stuff that you added
22:25:32	Araq	that's it.
22:25:44	BitPuffin	... right after I ran a git reset --hard HEAD
22:26:22	BitPuffin	luckly I can just grab from the paste
22:34:19	BitPuffin	Araq: are the lines adjusted to how they shift?
22:34:37	*	ics joined #nimrod
22:35:13	BitPuffin	well I'll probably see it
22:35:16	Araq	there is no shifting
22:35:23	BitPuffin	yeah true lol
22:35:34	*	BitPuffin is not the brightest one in the room
22:36:07	BitPuffin	Araq: do you want a default parameter value for modifyNode?
22:36:37	Araq	no
22:36:51	Araq	otherwise I would have told you so :P
22:37:02	BitPuffin	alright, just wanted to make sure :P
22:37:20	Araq	default values ensure that you don't consider every invokation site
22:37:33	Araq	which is the opposite of bug fixing
22:38:09	BitPuffin	yeah I guess that's reasonable to say
22:38:40	BitPuffin	did you mean line 945?
22:39:27	BitPuffin	and 962?
22:39:45	Araq	use your brain please
22:40:03	Araq	it's obvious what I meant even if I got the numbers wrong
22:40:07	BitPuffin	I'm gonna assume yes
22:40:10	BitPuffin	:P
22:46:40	BitPuffin	https://gist.github.com/BitPuffin/7620980
22:46:42	BitPuffin	Araq: ^
22:48:09	EXetoC	BitPuffin: have you memorized the compiler yet?
22:48:54	BitPuffin	EXetoC: hell noe
22:49:19	BitPuffin	but at least I know what sem always stands for :P
22:49:52	EXetoC	cool
22:51:05	Araq	you guys should read Luajit's source code. Or FPC's.
22:51:27	filwit	see what i'm saying tho..
22:52:00	BitPuffin	why? And what's FPC?
22:52:11	Araq	filwit: and yet you have no alternative. Or do you honestly suggest I write 5000 times 'semanticCheckingOfX' ?
22:52:36	filwit	semanticCheckX sounds fine to me really
22:52:41	BitPuffin	yeah me too
22:52:46	BitPuffin	we are programmers
22:52:48	BitPuffin	we type rather fast
22:53:07	Araq	yeah. we all like 200 column wide lines
22:53:34	BitPuffin	at least if you don't have to decrypt them
22:53:47	Araq	and we all like to have no overview over what the algorithm does
22:53:49	filwit	abbreviation isn't a problem.. it's over-abbreviation on top of a challenging domain
22:54:12	filwit	and i'm not criticizing your code really
22:54:22	filwit	only saying that for groups, it's best to be clear
22:54:27	*	DAddYE joined #nimrod
22:54:28	BitPuffin	I have such a small font anyway so i don't care much about the width of lines until they reach real extremes
22:54:54	BitPuffin	ofc that doesn't mean I don't try to keep it within 80 or so
22:55:12	BitPuffin	because thanks to the font I can have a lot of files on screen at the same time
22:55:30	BitPuffin	and screen resolutions are increasing and monitors get bigger etc
22:55:52	Araq	it's really easy: you ask "what? where is this defined? what's the type here? what does that abbrev mean?"
22:56:11	Araq	I ask "what's the used algorithm and why does it fail for this case?"
22:56:44	BitPuffin	it's hard to know why the algorithm fails though if you don't know what something does
22:57:01	BitPuffin	sure sometimes even without abbrew you need to have a look at the code behind that proc
22:57:29	BitPuffin	and like filwit says, abbrev is not a problem, over abbrev is
22:58:38	*	DAddYE quit (Ping timeout: 240 seconds)
22:58:39	filwit	Araq: how you approach problems isn't the issue. It's how clear the algorithm is to read and understand coming in, since, one large code bases you're often jumping around a lot. It's like the rule "you should comment your code".. sometimes that just slows things down.. but it helps others understand what you where doing
22:59:29	Araq	filwit: the problem is that as soon as you have my experience you stop disagreeing with me.
22:59:52	Araq	sorry to be blunt but seriously tell Mike Pall his Luajit is hard because he uses L instead of "context"
23:00:03	Araq	it's absurd
23:00:41	Araq	system.collections.table.put!(t, k, math.saturated.add(system.collections.table.get(t, k), 1))
23:00:44	Araq	vs
23:00:51	Araq	t[k] = t[k] +! 1
23:01:34	BitPuffin	well that's not a fair comparison
23:01:40	BitPuffin	operators are usually clear what they mean
23:01:49	filwit	Araq: i still disagree with somethings Nimrod does, i just don't complain about issues I know wont change. Not to say you have not changed my mind on some things as well.
23:01:52	BitPuffin	well maybe not +! in that case
23:02:30	filwit	Araq: you comparison is completely unrealistic
23:02:33	BitPuffin	L instead of context is in fact quite terrible
23:03:00	filwit	Araq: if you want to really demonstrate how your way is better, don't try and cheat by making the alternative way worse than real life
23:03:08	BitPuffin	switch to dvorak, buy a mechanical keyboard, and learn to type faster
23:03:35	EXetoC	I don't know if L stands for anything particular, but it seems like a common convention in the lua world, so that's alright then. I wouldn't mind typing "context" though
23:03:59	Araq	it's not about typing
23:04:10	EXetoC	mechanical keyboards? but those cost more than $20 :>
23:04:35	Araq	I don't want to *read* semanticCheck when 'sem' means the same and is used consistently in a 67K line code base
23:04:36	BitPuffin	EXetoC: well maybe if it's commonly used in lua it is fine, but it's still not really good
23:05:03	BitPuffin	why is reading that even a problem
23:05:11	filwit	Araq: i actually *kinda* agree with you about the 'sem' thing...
23:05:12	BitPuffin	it's not like you dissect it character by character
23:05:18	BitPuffin	you just look at the word and it's stored
23:05:18	Araq	skimming the code is faster when there is less code
23:05:36	Araq	no, word length is important for skimming
23:05:36	filwit	Araq: it really just needs very clear-cut documentation, and 'sem' isn't really a problem
23:06:04	filwit	Araq: it's things like 'n' for 'node' that i think fall under 'over abbreviated'
23:06:12	BitPuffin	in fact reasonably elaborated names distinguish themselves so they actually help skimming
23:06:23	Araq	and filwit my example is not even overblown
23:06:37	Araq	people always come here and want ! to denote side effects
23:06:47	Araq	and path.to.module.access everywhere
23:07:26	Araq	it's just that they are not serious because if they were they would love Java *cough*
23:07:43	Araq	well they are not honest to themselves
23:07:50	BitPuffin	I don't really find the problem with java to be that you type too much
23:07:51	filwit	people don't like Java for other reasons
23:08:14	Araq	oh really? how come verbosity is always listed as a reason?
23:08:16	filwit	and Java doesn't have operators, or things that *do help*
23:08:27	C0C0	Araq: the reason is that you have to read too much
23:08:42	filwit	and actually Araq, i agree, Java is too verbose
23:08:44	BitPuffin	Araq: yeah but people who complain about its verbosity are quite frankly stupid
23:08:57	filwit	i think C# is too verbose too
23:08:58	BitPuffin	other than int in = new int int int int(); int ()
23:09:08	filwit	i think D is pretty clean though (in many ways)
23:09:24	BitPuffin	java could do the same as D and C++ and add auto
23:09:35	BitPuffin	and it would eliminate the over verbosity
23:12:50	Araq	filwit: name 1 example where c# is verbose where D is not
23:13:16	filwit	override foo()
23:13:26	filwit	immutable x = 0;
23:13:44	Araq	var x = 0; // c# has no immutable
23:14:02	filwit	static x = 0; // this then...
23:14:08	BitPuffin	http://www.youtube.com/watch?feature=player_detailpage&v=21qzNbsGlbQ#t=2858
23:14:14	BitPuffin	relevant^
23:14:33	filwit	and for the record, i think Nimrod has some very clean syntax as well
23:14:45	EXetoC	I only use 1-2 letter identifiers when it's really obvious what's going on. I get easily confused otherwise
23:14:55	EXetoC	I think my ability to keep track of stuff is below average though
23:15:13	filwit	it's alien, but works well once you get used to it, and i kinda like the non-case-sensitivity
23:15:26	filwit	(alien to me i mean, not to everyone)
23:16:11	*	noam_ is now known as noam
23:16:29	filwit	EXetoC: i always make my tool's function names long, and local vars abbreviated
23:16:51	filwit	EXetoC: and by "long" i mostly mean "clear"..
23:18:04	EXetoC	right
23:18:11	filwit	see really, i think Nimrod's code, even it's internals are pretty clean. I have my gripes about 'newSeq', but even 'seq' is starting to grow on me.
23:18:26	BitPuffin	EXetoC: yeah like proc `+`*(theOperandOnTheLeftSide, theOperandOnTheRightSide: TNumber): TNumber = ... is obviously overdoing it
23:18:35	BitPuffin	there a and b would be stupid to not use :P
23:19:26	EXetoC	BitPuffin: woah I was just typing proc "`+`(x, y....".
23:20:50	filwit	BitPuffin: yup
23:21:14	EXetoC	filwit: what kind of gripes?
23:22:13	filwit	just some gripes. i've made these arguments before, but ultimately it's not very important at the moment
23:22:59	EXetoC	ook
23:24:29	filwit	i like interfaces to be standard, so when i can't do something like seq[int].new(...) where i can do that on other types, it feels off to me.
23:25:06	Araq	you can't do 44.new() either and yet it never bothered you
23:25:13	filwit	note that i said "fee's off to me", so it's not a big issue, i just think it's easier to get people involved when things are consistent
23:25:31	Araq	it's all completely arbitrary imho
23:25:33	filwit	Araq: 44 is not a reference type
23:25:38	Araq	neither is 'seq'
23:25:42	filwit	??
23:25:48	filwit	ah, right..
23:25:53	EXetoC	I'm not sure I follow. I know there's the 'new' prefix convention for when receiving a reference and 'init' for value types
23:26:11	Araq	yeah but newSeq predates that convention ...
23:26:18	filwit	Araq: was it once a ref type?
23:26:22	Araq	no
23:26:54	filwit	i could have sworn i rand into an issue because newSeq() wasn't called before add before...
23:27:21	Araq	yeah seqs are a bit hybrid
23:27:33	filwit	yeah i see
23:27:41	Araq	just like strings they have 'nil'
23:28:07	Araq	but are value types for the most part until you start playing with shallowCopy or .shallow for performance
23:28:33	filwit	either way, i maintain that's it's better for advertising in general to minimize common interfaces, and 'newSeq' kinda breaks that.. but mostly i think that can't be fixed until overload by return type where in place anyways.
23:29:05	BitPuffin	Araq: by the way did you see the paste?
23:29:30	Araq	BitPuffin: yeah, I'm still thinking
23:29:53	filwit	that's why i don't think this kind of thing is important too. It's not important right now (we need more applications than language features ATM), and it can always be addressed later.
23:30:40	BitPuffin	Araq: alrighty, sorry, just wanted to check so it didn't slip by
23:31:02	filwit	Nimrod is very capable right now, i've ran into some bugs, but it's a shit ton better than where D was a few years ago, and look how much D has grown in the last little bit
23:31:42	EXetoC	filwit: so you want the signature to change? got an example?
23:31:55	EXetoC	hypothetical or not
23:31:58	filwit	EXetoC: i'm not sure what you're asking?
23:32:07	filwit	signature for seq?
23:32:30	filwit	if so, then: var s = seq[int].new(0, 1, 2, 3)
23:32:56	filwit	but actually, that might not be good...
23:33:05	EXetoC	typedesc?
23:33:10	EXetoC	ok..
23:33:43	filwit	hypothetically, once Nimrod (sometime after 1.0) can do overload-by-return-type, then the syntax could be this:
23:33:54	filwit	var s: seq[int] = new(1, 2, 3)
23:34:07	filwit	which i think is even more consistent with the rest of the language
23:34:33	Araq	seq[int](1, 2, 3) would be consistent with the new object constructors
23:34:45	Araq	which came later, after newSeq ...
23:34:55	Araq	history surely can explain things
23:35:19	BitPuffin	ahh, var s: TType = new(...) is nice syntax I think
23:35:27	filwit	i've tried the new object constructor before, but it has limitations right?
23:35:42	Araq	only that it can't infer generic types
23:35:55	Araq	there have been bugs but they have all been fixed afaict
23:36:33	filwit	no, i mean that you must explicitly provide the data to the constructor..
23:36:53	filwit	in the case of seq, that's fine, and i think the syntax looks good
23:37:01	filwit	does that work right now by any chance?
23:37:14	Araq	depends on whether the type is marked as "needs explicit initialization"
23:37:25	filwit	how is that marking set?
23:37:42	Araq	needs to be documented, sorry
23:37:51	Araq	things evolve too quickly
23:37:56	filwit	okay, np
23:38:00	Araq	it's hard to keep the manual up to date
23:38:10	filwit	limited manpower
23:38:14	Araq	yep
23:38:14	filwit	no worries
23:38:27	Araq	and no, seq[int](1, 2, 3) doesn't work, however @[1, 2, 3] does
23:38:28	BitPuffin	limited energy and motivation when the funs is in the code
23:38:42	Araq	and is consistent with array constructors [1, 2, 3]
23:38:52	filwit	Araq: yeah i know about @[] (and i use it over newSeq)
23:39:00	Araq	so ... you're always unfair :P
23:39:14	filwit	no, i don't like the '@'
23:39:19	filwit	i wish it was not there
23:39:24	filwit	personally...
23:39:30	Araq	ultimate consistency leads to Lisp's syntax
23:39:46	Araq	which I can't stand personally
23:39:51	filwit	lol, true, but that's why these things are a religion
23:40:10	Araq	and even Lisp needs to cheat with , '
23:40:24	Araq	because it's just unfeasible
23:41:26	Araq	filwit: early versions used [1, 2, 3] for seqs
23:41:38	Araq	turned out to be too ambiguous
23:42:41	filwit	yeah, although i almost wish it was still like that.. only because i'm (completely guessing) anonymous seq's will be passed around more often in code
23:43:02	filwit	and then use the @[] thing for arrays...
23:43:06	BitPuffin	whaat lisp has awesome syntax :D
23:43:17	filwit	but honestly, that's completely irrelevant, lol
23:43:29	filwit	either way is pretty much fine, especially for now
23:43:33	Araq	actually if you have [...] in your code you have a fixed number of them, so it can be made into an array which is more efficient
23:43:55	Araq	and "foo" % [a, b, c] is common
23:44:06	filwit	what does that do?
23:44:17	BitPuffin	format the string?
23:44:26	filwit	ahh, right, right
23:44:26	EXetoC	how would that seq construction syntax work? with the help of compiler magic? or will we eventually get actual constructor functions that are tied to types?
23:45:11	Araq	EXetoC: with compiler magic I guess. but we got constructor functions tied to types with the Typ(field: bar) notation
23:45:40	EXetoC	I meant actual procs, but ok
23:47:29	filwit	EXetoC: in my code, i run everything through my own OOP-style macro, and then i use a {.init.} pragma to denote a initilizer (it makes a proc attached to both the typedesc and instance)
23:48:41	filwit	that's the real beauty of Nimrod's macros i think. I have all sort of plans for how Hymn will eventually be able to render code and you'll have Light-Table type abilities because I just compile the OOP parts really dynamically and wire them up to editor events..
23:49:19	EXetoC	does this macro need to be applied to the actual type?
23:49:34	filwit	it builds a type
23:49:41	filwit	one sec
23:51:40	filwit	https://gist.github.com/PhilipWitte/7621555
23:52:59	Araq	filwit: it may surprise you but I really like it :-)
23:53:03	filwit	also, my Kate color highlighting is nice and highlights an "someProc a, b" situation look nice, so 'part Person' looks like it's built-in, which is cool
23:53:13	filwit	Araq: awesome :)
23:53:19	Araq	however
23:53:22	Araq	one nitpick:
23:53:54	Araq	I went through some pains so that @ can be used for 'this.'
23:54:00	Araq	so:
23:54:04	Araq	@name = name
23:54:09	Araq	instead of:
23:54:15	Araq	this.name = name
23:54:30	filwit	will that work automatically?
23:54:32	EXetoC	neato
23:54:46	filwit	(right now there's a bug, so i can't try it out)
23:55:03	Araq	well you need template `@`(field): expr = this.field
23:55:12	Araq	but that's all
23:55:23	filwit	okay i see. That's Ruby right?
23:55:33	Araq	right
23:55:51	filwit	hmm... well i will consider it, if just to keep consistency
23:55:53	*	DAddYE joined #nimrod
23:56:04	filwit	one thing i don't like is it's not the best to type on American keyboards
23:56:18	filwit	but it's not the worst either
23:56:33	Araq	lol it sucks completely on a german keyboard
23:56:43	filwit	then why use that?
23:57:06	Araq	well I don't
23:57:21	Araq	but I thought it would fit right into your design
23:57:23	filwit	'me' might be better than 'this'
23:57:36	Araq	I considered 'my'
23:57:40	Araq	my.name = name
23:57:51	filwit	not bad either..
23:58:02	EXetoC	yeah
23:58:46	filwit	my idea was that i was going to define a template for each field, but in a sub-block or something so that only the proc's definitions could see it
23:58:57	filwit	then you wouldn't have to use 'this' or anything (it would be optional)
23:59:14	Araq	also to repeat myself: I'm not that concerned about typing things. I don't want to read things. ;-)
23:59:30	filwit	i see