<< 07-02-2016 >>

---

00:11:04	*	Trustable quit (Remote host closed the connection)
00:13:17	*	shodan45 quit (Quit: Konversation terminated!)
00:13:55	*	Sornaenst is now known as THE_LORD
00:14:06	*	THE_LORD is now known as Sornaensis
00:20:44	*	M-max1 joined #nim
00:21:15	*	M-max quit (Ping timeout: 240 seconds)
00:22:32	*	Demon_Fox quit (Ping timeout: 240 seconds)
00:22:32	*	ephja quit (Ping timeout: 240 seconds)
00:25:17	*	vendethiel- joined #nim
00:25:39	*	Demon_Fox joined #nim
00:28:50	*	vendethiel quit (Ping timeout: 240 seconds)
00:29:40	*	ephja joined #nim
00:38:17	*	Matthias247 quit (Read error: Connection reset by peer)
00:46:06	*	apotheon quit (Ping timeout: 240 seconds)
00:47:03	*	apotheon joined #nim
00:52:55	Araq	ldlework: sounds it should work yeah
00:53:06	ldlework	Araq: I was using the proc keyword :(
00:54:07	Araq	happens to the best of us
00:54:19	*	derka joined #nim
00:54:43	*	filwit quit (Read error: Connection reset by peer)
00:56:50	*	derka quit (Client Quit)
01:09:35	*	jaco60 quit (Ping timeout: 240 seconds)
01:12:02	*	yglukhov joined #nim
01:16:09	*	yglukhov quit (Ping timeout: 240 seconds)
01:40:01	*	arnetheduck joined #nim
01:48:50	*	zaimatzoain joined #nim
01:48:58	*	zaimatzoain left #nim ("ERC Version 5.3 (IRC client for Emacs)")
01:49:31	*	pregressive joined #nim
01:49:34	*	Sornaensis quit (Max SendQ exceeded)
01:49:40	*	Sornaensis joined #nim
01:51:05	*	derka joined #nim
01:53:40	*	pregressive quit (Ping timeout: 248 seconds)
02:04:29	*	ljgu joined #nim
02:04:40	ljgu	how do i compile a program to a windows executable? Im on linux atm
02:15:17	*	ljgu quit (Quit: Page closed)
02:15:36	Xe	wait, nim can codegen php?
02:18:13	ldlework	wat
02:18:53	Xe	https://github.com/nim-lang/Nim/pull/3835#discussion_r52110412
02:19:40	ldlework	huh
02:28:19	*	derka quit (Quit: derka)
02:41:18	*	skyfex joined #nim
02:53:14	*	yuta joined #nim
02:55:35	*	filwit joined #nim
02:59:32	yuta	hello
02:59:42	ldlework	hi
03:00:18	yuta	Does anyone can get documentation comment information from nimsuggest?
03:00:46	*	ephja quit (Ping timeout: 245 seconds)
03:01:04	yuta	I'm afraid to ask in forum/github issue if it's only my environment
03:01:44	ldlework	yuta: the community is still small enough the forum is the best place to ask anyway
03:03:28	yuta	thanks idlework. I'll ask nim forum
03:13:20	*	yglukhov joined #nim
03:17:45	*	yglukhov quit (Ping timeout: 240 seconds)
03:21:05	*	skyfex quit (Quit: My Mac has gone to sleep. ZZZzzz…)
03:34:48	*	yuta quit (Remote host closed the connection)
03:40:30	*	yglukhov joined #nim
03:43:33	*	pregressive joined #nim
03:44:56	*	yglukhov quit (Ping timeout: 240 seconds)
03:48:47	*	lompik joined #nim
03:50:06	*	sanctus joined #nim
03:50:10	*	sanctus is now known as francisl
03:50:18	*	francisl quit (Client Quit)
03:50:35	*	francisl joined #nim
03:57:56	*	filwit quit (Ping timeout: 250 seconds)
04:00:29	*	francisl quit (Quit: francisl)
04:03:21	*	francisl joined #nim
04:03:43	*	francisl quit (Client Quit)
04:04:07	*	francisl joined #nim
04:12:40	*	filwit joined #nim
04:24:38	*	brson quit (Quit: leaving)
04:28:45	Varriount_	arnetheduck: You there? I've been gone most of the day.
04:29:10	arnetheduck	Varriount_, yep
04:29:51	Varriount_	arnetheduck: First off, your SDL procedure wasn't exported properly, which lead to nothing ever happening.
04:30:00	Varriount_	The rendersound one.
04:30:29	arnetheduck	sdl? rendersound?
04:31:02	Varriount_	arnetheduck: I was helping you with the dll-reload-on-change stuff, right? Or am I confusing you with someone else?
04:31:36	arnetheduck	Varriount_, think you're confused ;) I'm the nlvm guy
04:31:59	Varriount_	arnetheduck: Oh, sorry. My mistake
04:32:19	filwit	ohh! nlvm looks very cool, btw.
04:33:36	Varriount_	arnetheduck: Well, on windows, the easiest way to make things work is to simply have clang compile the bytecode directly. There's a nasty bug (that's really old) that makes assembly output garbled.
04:34:26	*	lompik quit (Ping timeout: 252 seconds)
04:34:41	Varriount_	arnetheduck: Aside from that, the problem is resolving identifiers in C libraries and headers. Even if the correct object files are used, nlvm outputs symbols for things like defined identifiers.
04:34:54	arnetheduck	Varriount_, yeah, that's what I'm using too now (think I wrote it down in the readme as well)
04:35:39	Varriount_	arnetheduck: Might want to put it as the preferred way. I kept having to mangle arguments to the various llvm tools to get things working otherwise.
04:36:11	*	junw_ quit (Ping timeout: 245 seconds)
04:36:48	arnetheduck	Varriount_, I think I did, check out the latest readme.. also started on a support lib to work around the symbols problem.. though it's really a workaround, longer term it would probably be better to mod stdlib
04:37:07	Varriount_	arnetheduck: Regarding the llvm dynlib, on windows the makefile has to be modified to run objdump correctly.
04:37:39	arnetheduck	hm, ok.. I
04:37:42	Varriount_	The llvm source doesn't export symbols using the declspec mechanism on windows, so the code has to be patched.
04:37:58	Varriount_	Or rather, the dll does.
04:38:24	arnetheduck	ok.. it's possible to use the static libs as well, except that the link times are annoying when recompiling nlvm
04:39:16	arnetheduck	that's probably the longer term solution, but not something I want to use right now.. I think it should be possible to switch between the two using some when magic
04:39:24	Varriount_	arnetheduck: Also, it's a tad faster to compile in release mode. My laptop took ~10 minutes and 4GB of memory during the compilation process otherwise.
04:39:36	Varriount_	Er, release mode for the llvm dynlib.
04:40:22	arnetheduck	Varriount_, yeah, but since llvm error checking is based on asserts, any problems with your generated bytecode and it crashes.. in debug mode, at least it gives an assert with some info as to what might be wrong
04:41:15	Varriount_	arnetheduck: Oh. Wonderful.
04:41:45	Varriount_	arnetheduck: Well, I can generate some DLL's for others who want to try nlvm on Windows.
04:42:09	Varriount_	On the plus side, I got to learn about makefiles and cmake
04:43:00	arnetheduck	Varriount_, could do that.. I guess there are no official debug dll's to be had?
04:43:20	arnetheduck	you compiling with msvc or mingw btw?
04:43:33	Varriount_	arnetheduck: For libllvm? I think there are a few scattered about, but they're 32-bit.
04:43:38	Varriount_	mingw
04:44:28	arnetheduck	Varriount_, ah, that's why.. on linux only the autoconf make files support shared libs.. they've fixed it for 3.8 though, so maybe it'll be easier on win also
04:45:03	Varriount_	arnetheduck: 3.8 is released?
04:45:04	arnetheduck	for windows, maybe cygwin would work with the current llvm ver, using autoconf
04:45:28	arnetheduck	Varriount_, almost, I think.. I think there was an RC last I checked
04:45:35	Varriount_	I could have sworn I was using whatever was given on llvm's downloads section.
04:45:53	*	Varriount_ is now known as Varriount
04:46:43	arnetheduck	Varriount, ah, feb18.. release candidate avail now.
04:47:28	arnetheduck	filwit, thanks. it'll be a lot more cool if it actually starts working ;)
05:18:03	*	chadsy joined #nim
05:19:14	*	chadsy quit (Client Quit)
05:19:25	*	chadsy joined #nim
05:20:39	Varriount	arnetheduck: Have you built llvm 3.7.1?
05:20:44	*	chadsy quit (Client Quit)
05:21:05	*	xawdy joined #nim
05:22:17	*	xawdy quit (Client Quit)
05:22:35	*	xawdy joined #nim
05:23:45	*	nullsector joined #nim
05:31:27	*	xawdy quit (Quit: Leaving)
05:35:33	arnetheduck	Varriount, yeah
05:41:56	*	yglukhov joined #nim
05:42:37	Varriount	arnetheduck: Did you use cmake at all?
05:42:52	arnetheduck	Varriount, no, autoconf + make
05:42:59	arnetheduck	like the instructions in the readme
05:43:06	Varriount	arnetheduck: Ah.
05:43:55	Varriount	arnetheduck: Windows people get to use cmake. And apparently whoever wrote the invokation for the python script forgot to put a flag to actually run the script properly.
05:44:23	*	nullsector quit (Read error: Connection reset by peer)
05:45:18	arnetheduck	Varriount, well, with 3.8, I think automake is gone, and they made an effort to ensure all features were ported to cmake
05:46:08	Varriount	arnetheduck: What's frustrating is that I could have sworn the configuration process worked properly a wekk ago.
05:46:13	Varriount	*week
05:46:20	*	yglukhov quit (Ping timeout: 245 seconds)
05:47:11	arnetheduck	Varriount, heh, unix has the history command for that situation ;)
05:47:38	Varriount	arnetheduck: True, but last time I used the default configuration provided by cmake-gui
05:48:21	Varriount	With the exception of modifying one of the cmake files so that the llvm dynlib would build. But I know I didn't do anything with python.
05:54:41	*	Varriount_ joined #nim
05:54:41	*	Varriount quit (Disconnected by services)
05:57:07	Varriount_	arnetheduck: Ah, found the problem. It was due to some symlinks.
06:12:20	*	FreezerburnV quit (Ping timeout: 252 seconds)
06:18:55	*	pregressive quit ()
06:19:59	*	pregressive joined #nim
06:23:31	*	francisl quit (Quit: francisl)
06:48:33	*	gour joined #nim
07:07:43	*	endragor joined #nim
07:09:43	*	pregressive quit (Remote host closed the connection)
07:10:17	*	pregressive joined #nim
07:14:42	*	pregressive quit (Ping timeout: 250 seconds)
07:41:53	ldlework	Do you really ever need to make a "ref Table[..]" type?
07:42:01	ldlework	Because a Table is already a ref type?
07:42:42	ldlework	Oh I see there is TableRef
07:43:27	*	yglukhov joined #nim
07:47:33	ldlework	If you make a type as `ref object` does that mean there is no way to make a value of that type?
07:47:38	ldlework	Other than a reference to it on the heap?
07:47:48	*	yglukhov quit (Ping timeout: 248 seconds)
07:48:00	ldlework	I mean, there is no way to pass it by value, other than passing around a reference to it on the heap?
07:50:42	ldlework	I guess all the little Nimians are asleep right now
07:51:01	*	gour quit (Quit: WeeChat 1.4)
07:51:27	filwit	ldlework: the only other way to "pass it around" would be to copy it..
07:51:53	ldlework	filwit: right, which is what you get with normal structure types created with "type foo = object .."
07:52:20	ldlework	filwit: so I'm asking, if you create a "type bar = ref object", does this mean when you create the object it is created on the heap and the only thing you can pass around is a ref to it on the heap?
07:52:29	ldlework	IE it can never really be copied just by passing it?
07:52:53	filwit	you can always manually copy it via shallow/deepCopy
07:53:20	ldlework	Sure, but I'm asking specifically does creating a type of "ref object" prevent copying via passing semantics?
07:53:22	filwit	or you can do: var x: type(bar[]) = someBar[] # I think
07:53:36	ldlework	If I never purposefully copy it like you're describing, it'll never be copied right?
07:53:54	filwit	not unless you're passing it to another thread, no
07:54:01	ldlework	that's pretty useful
07:54:58	ldlework	I like that you have the option to create a base "FooObj = object" and then create a RefType with "Foo = ref FooObj"
07:55:17	ldlework	Or you can just do "Foo = ref object" and prevent it from naturally being passed by vale
07:55:19	ldlework	value
07:55:38	ldlework	there's a lot of flexibility available
07:57:02	ldlework	Like, I never ever want my huge map type passed by value
07:57:13	filwit	the parallel/spawn macros will auto-deepCopy ref-types that you pass to procedures (since it has to for safety) but beyond that, yeah you can limit and object to always be ref semantics... also, what's cool is in {.experimental.} code you can pass an ref-object to a proc that takes a non-ref version and it auto-derefs (which prevents you from mutating it's fields)
07:57:18	ldlework	So I'm going to define it as "ref object" so that you can't naturally do that by accident
07:58:03	ldlework	de-ref's it and so passes it by value, and hence copying it
07:58:06	ldlework	right?
07:58:25	ldlework	I mean, in Nim, everything is passed by value
07:58:32	filwit	i would assume so... but I'm not sure actually
07:58:37	ldlework	you're jsut sometimes passing a structure or sometimes passing a reference
07:59:11	ldlework	filwit: I would imagine that's why you can't mutate it, because you actually have a copy
07:59:13	filwit	well.. isn't that the way all languages work? I mean.. a reference is just and int address..
07:59:34	ldlework	Well, not all languages, take python for example.
07:59:54	ldlework	Everything is "passed by value" per-se, but the only thing you can pass is references.
08:00:16	ldlework	But yeah you're right
08:00:23	ldlework	fundamentally, all passing is done 'by value'
08:01:31	filwit	ldlework: about the auto-deref, Nim could actually just specialize procedures that auto-deref and assume value semantics to avoid the copy... but I doubt it does that
08:02:22	filwit	that's probably why the feature is {.experimental.} cause it might not really be a good idea.. i mean it kinda breaks your "I can prevent unwittingly copying a large heap object" scenerio
08:02:35	ldlework	oh yeah
08:03:09	ldlework	I mean if the compiler has already recognized this kind of thing, it can probably just complain if any operations that mutate it exist.
08:03:22	ldlework	rather than copying the data
08:03:24	ldlework	mm yeah
08:04:33	filwit	oh btw, there's also a {.byRef.} and {.byVal.} pragmas I think, which you can apply to regular objects... so you can get a hybrid object where any "var x = y" is a copy, but passing 'y' will do so by reference (or vise versa)
08:05:19	ldlework	that just seems confusing
08:05:26	ldlework	heh but flexible!
08:07:09	filwit	yeah it's probably not a good idea in regular code.. In fact, a long time ago I was originally the person who suggested adding in 'ref object'.. Araq liked the idea, but now I'm not sure I really do.. it hides the details from call-site (originally I just suggested it cause there was the T/P Hungarian notation everywhere to avoid typing 'ref')
08:09:21	filwit	and btw, you could always enforce the use a ref version of a specific type even before 'ref object' by simply not exposing the FooObj version
08:10:03	ldlework	yeah but with `ref object` yo udon't have to define two types at all
08:10:37	ldlework	and the fact that nim kinda treats references transparently, it all adds up to a nice package
08:10:38	filwit	he's going to laugh at me for complaining so much about removing the T/P thing a long time ago, and now suggesting that it's good to have that info (value/ref) at callsite...
08:11:00	ldlework	I think the thing I just mentioned is why its okay to not care
08:11:21	ldlework	Also the T/P thing still lives on
08:11:31	ldlework	Some people do FooObj/Foo and some people do Foo/FooRef
08:12:11	ldlework	I have been doing the former, but I think I want to switch to the latter.
08:13:15	filwit	i think you should do both, just depending on which you want promoted... eg, always assume 'Foo' is what your API users will pick, and if that's supposed to be a reference do the former, if not, the latter
08:14:08	filwit	or, like you said.. just have 'Foo' with a default and let people who really want the underlining object type jump through a bit of syntax hoops to get it
08:15:22	ldlework	I used to actually use 'ref' throughout my code
08:15:30	ldlework	dunno, didn't like it after a while
08:16:24	ldlework	But I think I like Foo/FooRef because then I can just go on knowing that, I'm passing things by value and sometimes, and it'll be obvious when, I'll be passing a ref by value (because Ref will be in the type name)
08:16:39	ldlework	Just seems like the most straightforward cognitive model to work with.
08:16:53	filwit	yeah, TBH it's much better not to have 'ref' everywhere.. I take it back... with proper IDE inspection tools you just hover over the type real-quick to find out what it is..
08:17:09	ldlework	Its kind of like if you always used object types and used 'ref' keyword where you wanted references
08:17:30	ldlework	except that you get to save a bunch of 'ref' keywords, but you're still treating 'ref' types the same way
08:18:13	ldlework	My IDE doesn't know Nim that well
08:18:21	filwit	well the thing is a lot of my code right now I'm using objects (in continuous arrays) and passing around 'ptr T'
08:18:43	ldlework	I think 'ptr' is loud enough that you should use the keyword for it
08:18:47	filwit	well... i use both, just different parts of my application stuff
08:19:10	filwit	what IDE do you use?
08:19:14	ldlework	emacs
08:19:26	filwit	ah.. never used emacs.
08:19:48	filwit	the Atom Nim support is pretty nice now (jump to def is nice)
08:20:35	filwit	but honestly I still use Aporia for most of my Nim code... mostly cause I wrote all the color styles and I like to be able to control what the syntax is displayed like
08:20:37	ldlework	filwit: what do you use Nim for mostly?
08:21:38	filwit	heh, well I've done a lot of playing around with Nim for various things, I was building a HTML/CSS/server DSL a year or so ago.. but mostly game-engine related stuff
08:22:25	ldlework	I'm writing a data-driven game engine :)
08:22:39	ldlework	I wrote a json-driven entity-component system
08:22:42	filwit	i think Nim fits such a wide range of domains (because of it's meta-programming) that I always have these crazy ideas and want to work on them, but don't have the time
08:22:50	ldlework	currently working on a chunked streaming tilemap system
08:23:02	ldlework	I love the metaprogramming
08:23:02	filwit	oh, very cool
08:23:32	filwit	i thought you where a web-developer? I kinda remember having an argument with you about Nim's web HTML/CSS a long time ago :P
08:24:21	ldlework	I'm a professional programmer so I'm expected to be proficient in the latest web-technologies regardless if it has anything to do with my direct profession.
08:24:49	ldlework	I just ran the gauntlet getting up to speed on React and Redux
08:25:19	ldlework	I built a realtime websocket-streaming Docker logs dashboard a couple weeks ago for work.
08:25:32	ldlework	But I am a distributed systems architect.
08:26:04	ldlework	I just do games for fun!
08:26:11	filwit	oh i see, that makes sense then why you need to keep up with fullstack tech
08:26:44	ldlework	component-based web programming is pretty crazy
08:27:23	filwit	component-based web programming? are you talking about games or distributed server apps?
08:27:32	ldlework	Like with React
08:27:44	filwit	ah, i don't know anything about React or Redux
08:27:49	ldlework	Where your front-end consists of a top-level react component, which has child components, and its just react components all the way down
08:27:53	ldlework	ah
08:28:20	ldlework	FRP is the future of the the front-end
08:28:26	ldlework	at least for the next 9 months or so ;)
08:28:30	*	Demon_Fox quit (Quit: Leaving)
08:28:36	filwit	hmm... that just sounds like a fancy way of saying MVC or MVVC? or is this design something different?
08:28:53	ldlework	Yeah it has a lot in common with MVC conceptually
08:29:01	filwit	"at least for the next 9 months or so ;)" LOL
08:29:09	ldlework	and propoents of FRP would probably find themselves trying too hard to distinguish them
08:29:47	ldlework	filwit: MVC is sort of "two-way binding"
08:29:56	ldlework	FRP is more, "one-way binding"
08:30:03	filwit	okay i see, I've done some MVC/MVVC WPF/Silverlight work in the past, but mostly the front-end view-controller stuff
08:32:06	ldlework	FRP is sort of, there is a core model and when it changes all the data will flow uni-directionally from root to leaf to render the document and nothing will cross talk and everything is immutable
08:32:27	ldlework	its like a refinement in discipline over mvc... kinda
08:33:06	ldlework	With React, there is a virtual dom
08:33:15	ldlework	your javascript manipulates and controls a virtual dom
08:33:36	ldlework	and then react has a ReactDOM backend which effectuates the virtual dom onto the real DOM
08:33:52	ldlework	but what's neat is there's nothing saying that the virtual dom has to render out to the browser DOM api
08:34:07	ldlework	so you can make a node app that renders to the browser, or say a curses interface
08:35:01	filwit	so in FRP there is not defined mechanism for user-actions to mutate data? if a list is re-ordered for example, the control just arbitrarily submits those data changes, or is there a model it it like MVVC?
08:35:18	filwit	to be honest, I kinda like that idea more... half the time MVVC is complete overkill...
08:35:44	filwit	(list re-ordered by user)
08:35:54	ldlework	Well, you attach code to those handlers, which mutate the data, which causes the entire virtual dom to be reconstructed
08:36:03	ldlework	the difference between the old virtual dom and the new virtual dom is computed
08:36:11	ldlework	the specific difference is applied to the live dom
08:36:21	ldlework	so specifically only the elements needing to change are re-rendered
08:36:37	ldlework	virtual dom: cheap
08:36:40	ldlework	real dom: expensive
08:38:04	filwit	okay i see.. thought rebuilding/comparing the entire DOM doesn't actually sound as efficient as updating data per-control
08:38:09	filwit	though*
08:38:43	filwit	but maybe they have some clever way to do it fast (eg, it only rebuilds the entire DOM in theory)
08:41:55	filwit	i might take a look at it later, but honestly I'm trying to move away from that kind of work in general.. I really want to get a job as a game-developer for some company and move more towards that career path.
08:42:18	ldlework	it rebuilds the virtual dom
08:42:27	ldlework	the virtual dom is just abstract objects representing the real dom
08:42:40	ldlework	filwit: work on dadren with me
08:43:37	ldlework	I'm building a huge data-driven open-world rougelike game in which I hope to have lots of emergent interactions from all of the stuff in the game.
08:43:42	filwit	haha, paid work? cause I'm between gigs and looking for real work, not just hobby project.
08:43:56	ldlework	Well how do you expect to convince anyone to pay you?
08:44:04	ldlework	Have you worked on any games before?
08:44:39	filwit	yes, two small games (Unity3D and our own internal C# SDK)
08:45:03	ldlework	filwit: then let's go to steam
08:45:11	ldlework	like everyone else
08:45:14	ldlework	do you have a job?
08:45:22	filwit	and I've been doing game-dev stuff since I was very young (eg, writing OpenGL/DirectX shader stuff, etc)
08:45:25	*	yglukhov joined #nim
08:45:27	ldlework	Same.
08:46:06	filwit	but I was mostly just joking, I didn't actually think you where looking to hire anyone, if you are, I would be very interested in applying (especially if it's Nim code)
08:46:18	filwit	and no, I don't currently have a job
08:46:35	filwit	(handing out resumes this week)
08:46:50	ldlework	I'm not hiring anyone. I work a fulltime job at Docker. But I have written a number of games and am a capable programmer. If I met another programmer such as myself, I could see myself collaborating seriously to get a game onto steam.
08:46:59	ldlework	But if you're looking for a real gig, that's something else.
08:47:14	filwit	okay I see
08:47:41	filwit	i would still be interested in the future maybe, but right now I have to focus on getting more income
08:48:04	Varriount_	Hi guys!
08:48:05	ldlework	yes, it is nice to have a livelyhood
08:48:10	*	Varriount_ is now known as Varriount
08:48:19	ldlework	filwit: I wish you the bestestest of luck in that regard
08:48:48	filwit	ldlework: thanks!
08:48:54	filwit	hi Varriount
08:48:58	ldlework	hi V
08:49:20	filwit	btw, I noticed there's a #nim-gamedev.. what do y'all do in there?
08:49:30	Varriount	If I made a game (at least, as a learning experience) it would probably be something based off of the Megaman Battle Network games.
08:49:35	*	yglukhov quit (Ping timeout: 240 seconds)
08:49:47	Varriount	I loved those games...
08:49:52	filwit	just a place to discuss gamedev stuff without bottlenecking #nim?
08:50:16	ldlework	filwit: #nim-gamedev
08:50:23	ldlework	oh
08:50:27	filwit	never played Megaman games.. but I was always more interested in 3D stuff
08:50:27	ldlework	talk about gamedev in nim
08:50:32	ldlework	mostly me talking about dadren development
08:50:50	filwit	ldlework: where are you on that project? it sound really cool
08:51:21	ldlework	I have the json-driven ECS complete. I have tileset support. Basic scene management. I'm working on a streaming chunked tilemap and camera system now.
08:52:22	ldlework	Would love any kind of collaboration
08:52:33	ldlework	I have no deadline and am just tinkering when I find myself motivated
08:52:40	ldlework	Anyone like that is welcome
08:52:54	filwit	hmm.. cool. Does your ECS use continuous memory, btw? I'm not sure if you mean "json driven" as in "stores json objects per component" or "loads jsons files and builds components"
08:53:14	ldlework	the json defines entity models or 'templates'
08:53:29	ldlework	IE, a definition of some group of components and their default values, with a name
08:53:32	ldlework	so I can say
08:53:42	ldlework	hey entity manager make me a "death ship, over here"
08:53:54	ldlework	well the quotes are strange there but you get the point
08:53:56	ldlework	:)
08:54:21	ldlework	but no the ECS is not optimized at all
08:54:30	*	desophos quit (Read error: Connection reset by peer)
08:54:37	ldlework	I use Tables right now because there's no reason to preoptimize
08:54:41	Varriount	filwit: What do you mean by 'continuous memory'?
08:55:00	ldlework	I assume they mean "arrays of homogenous component instances"
08:55:09	filwit	okay i see, that's similar to what I'm doing, but I don't have much of the JSON loading/storing done (i have a basic version working, but it doesn't support everything I need and my component model recently changed, so I have a lot to do here)
08:55:15	filwit	^ ldlework
08:55:18	ldlework	an array of all the Position components, an array of all the Velocity components, etc
08:55:35	ldlework	filwit: why should we compete?
08:55:37	ldlework	just join me
08:55:42	ldlework	we'll get much much futher
08:56:29	ldlework	there's so much to do, to think of duplicating efforts it makes me a bit nauseous
08:56:42	filwit	Varriount: 'continuous memory' = array of object not ref-object.., eg, all memory for the components are inline which prevents cache-misses when preforming some task over a bunch of them and increases performance (compared to reading an address and doing a lookup per ref for each component)
08:57:10	Varriount	filwit: Ah
08:57:12	filwit	ldlework: well I didn't know you where making and ECS until just now :P
08:57:20	ldlework	It assumes that you can process all of the components sequentially anyway
08:57:26	ldlework	which is only useful for some kinds of components
08:58:02	ldlework	and when you start implementing your game, your update loop is not going to be this straight list of clean systems that nicely and orderly iterate over continguous arrays of components updating them
08:58:19	filwit	ldlework: but I'd love to collaborate on work like this in the near future, I have a project that I'm cleaning up right now that I'll put on github soon.. after that maybe we can compare and talk about joining forces..
08:58:32	ldlework	filwit: okay
08:58:34	Varriount	I can't help thinking that this is where Java and Python really takes the hit for game development - Since everything is a ref, you can't optimize for cache hits/misses.
08:59:09	ldlework	Python takes a hit because every attribute access is a massive function call
08:59:22	ldlework	and every function call is a massiver function call
09:00:08	filwit	in Python all objects are basically tables.. so not only would your component objects be non-continuous, but every field inside them would be as well...
09:00:26	Varriount	arnetheduck: By the way, the LLVM dynlib on windows is 'LLVM.dll'
09:00:45	Varriount	filwit: Pretty much.
09:01:11	ldlework	filwit: well I guess hit me up sometime then
09:01:13	filwit	same for Javascript, although with these languages you can "hack" them and basically make your own memory management using a bit array of bytes or something and storing object in it
09:01:31	federico3	Any epub available with the docs from the new release?
09:04:01	filwit	ldlework: will do, gotta get a job first, then fix up my game-engine project a bit more (i have a couple goals to meet before i put it on github), then I'll make a forum post about it or something and we can compare/collaborate then.
09:22:01	*	yglukhov joined #nim
09:26:19	*	yglukhov quit (Remote host closed the connection)
09:32:30	*	yglukhov joined #nim
09:40:56	*	gour joined #nim
09:43:32	*	endragor quit ()
09:45:14	*	endragor joined #nim
09:47:31	*	yglukhov quit (Remote host closed the connection)
09:49:17	*	yglukhov joined #nim
10:09:37	*	yglukhov quit (Remote host closed the connection)
10:10:12	*	yglukhov joined #nim
10:13:01	*	yglukhov quit (Remote host closed the connection)
10:13:35	*	yglukhov joined #nim
10:15:01	*	sheerun joined #nim
10:22:52	*	darkf joined #nim
10:29:07	Araq	er ... def- do you have repo access?
10:29:16	Araq	how come I don't know?
10:29:22	*	yglukhov quit (Remote host closed the connection)
10:29:26	*	sheerun quit ()
10:29:30	Araq	(it's fine, I'm just wondering)
10:29:48	*	sheerun joined #nim
10:34:59	*	yglukhov joined #nim
10:38:18	filcuc	is it more idiomatic create or init as a name for initializing the field of an object. Basically when using inheritance where the subclass class the parent initialization proc
10:38:33	filcuc	*call*
10:40:52	filwit	filcuc: i believe it's 'init' for regular value objects, and 'new' for ref-objects. There is a 'create' proc in system which allocates unsafe ptr types on the heap, so I wouldn't call it 'create'
10:42:21	filwit	eg: `let x = initFoo(..) # returns value object` ... and: `let y = newFoo(..) # returns ref object`
10:45:41	filcuc	filwit: but the proc i want doesn't return anything :| . It's just the call to the base object type initializing proc.
10:46:32	filcuc	filwit: in other words. type A = ref object of RootObj | type B = ref object of B | newA(): A | newB(): B
10:47:04	filcuc	inside newB() i would like to call the proc of A that initialize its fields
10:48:05	filcuc	my question it's if there's a proper name for this proc, given that as you explained init is used for objects and new for ref objects
10:48:56	*	Matthias247 joined #nim
10:49:50	filwit	filcuc: I'm not sure if there's a idiomatic naming convention for that exact scenario (there might be).. personally I always call that sort of thing 'setup', but 'init' makes just as much sense
10:52:44	filcuc	filwit: setup is a good one
10:52:44	*	dashed joined #nim
10:52:50	filcuc	filwit: thank you ;)
10:54:49	*	yglukhov_ joined #nim
10:54:49	*	yglukhov quit (Read error: Connection reset by peer)
11:01:57	Araq	filwit: I think your macro skills exceed mine :-)
11:02:18	Araq	not sure I would have come up with http://forum.nim-lang.org/t/2006/2
11:02:25	filwit	haha, i doubt that very much
11:03:16	filwit	and i was just looking at thinking... damn I should have used `macros.newTree(...)` instead of `newNimNode(...).add(...)`
11:04:39	*	TheManiac is now known as Max
11:05:08	*	Max is now known as Guest33022
11:06:00	*	M-max1 is now known as TheManiac
11:06:14	*	Guest33022 quit (Quit: leaving)
11:07:19	Araq	newTree is pretty new though
11:07:51	filwit	is it? i just saw someone on the forums use it and I was think "how have I not know about this?"
11:08:10	Araq	since 0.11 or 0.12 maybe
11:09:06	*	derka joined #nim
11:09:20	filwit	very good addition... i should really contribute some PRs to the macros lib.. i use it a ton and there are some missing construction functions i use a lot, plus some missing features of the exist ones (eg, `newProc` doesn't take pragmas)
11:18:28	*	derka quit (Ping timeout: 248 seconds)
11:19:52	*	gokr joined #nim
11:20:54	gokr	Araq: I am using c2nim and wondering how to do the mangles for uint32_t etc...
11:21:29	gokr	If I am running c2nim on many header files, what's the smart way here?
11:22:02	filwit	very good addition... i should really contribute some PRs to the macros lib.. i use it a ton and there are some missing construction functions i use a lot, plus some missing features of the exist ones (eg, `newProc` doesn't take pragmas)
11:22:15	filwit	whoops, shit..
11:22:33	filwit	alt-tabbed into this instead of the terminal..
11:23:07	*	jaco60 joined #nim
11:24:23	gokr	For the insatiably curious, I am testing to get Nim going on a MediaTek Linkit ONE.
11:24:42	gokr	So I want to wrap Arduino libs, and also specific libs from MediaTek.
11:36:15	def-	Araq: yes, I do. no idea, was never announced to me, I just noticed one day.
11:37:36	*	yglukhov_ quit (Read error: Connection reset by peer)
11:37:36	*	yglukhov joined #nim
11:54:32	*	yglukhov_ joined #nim
11:54:32	*	yglukhov quit (Read error: Connection reset by peer)
11:54:34	*	gokr quit (Quit: Leaving.)
11:57:11	*	yglukhov_ quit (Read error: Connection reset by peer)
11:58:59	*	arnetheduck quit (Ping timeout: 264 seconds)
12:00:36	*	arnetheduck joined #nim
12:01:58	*	yglukhov joined #nim
12:05:43	*	endragor quit (Remote host closed the connection)
12:11:22	*	gokr joined #nim
12:13:16	*	gokr quit (Client Quit)
12:13:16	*	yglukhov quit (Read error: Connection reset by peer)
12:13:19	*	yglukhov_ joined #nim
12:15:47	*	yglukhov_ quit (Read error: Connection reset by peer)
12:22:13	*	junw joined #nim
12:25:26	*	yglukhov joined #nim
12:34:13	Araq	gokr: use a config.c2nim file and pass that to every c2nim invocation
12:34:39	Araq	that config.c2nim can #mangle uint32_t or #def it
12:41:51	*	endragor joined #nim
12:46:57	*	FreezerburnV joined #nim
12:58:23	*	lompik joined #nim
13:22:49	filwit	Araq: how expensive is getType() on the VM?
13:23:03	flyx	in the system.html documentation, all links to „exception hierarchy“ seem to be broken
13:23:46	flyx	and in manual.html, in the exception hierarchy, OutOfMemoryError is listed, but it's actually named OutOfMemError
13:25:03	flyx	should I open an issue for that?
13:25:25	filwit	Araq: for instance, which would be faster: a macro which uses getType() to determine if a type is ref, or just outputs a `when T is ref: ...` ?
13:26:17	filwit	Actually, Nim always outputs compile-times so I guess I should just benchmark this myself.. nevermind
13:27:39	*	endragor quit (Remote host closed the connection)
13:29:18	*	Egon_ joined #nim
13:30:00	*	endragor joined #nim
13:32:38	*	Egon_ quit (Client Quit)
13:33:25	*	gokr joined #nim
13:35:10	*	endragor quit (Ping timeout: 276 seconds)
13:41:27	*	Egon_ joined #nim
13:41:48	*	yglukhov quit (Remote host closed the connection)
13:42:50	*	Egon_ quit (Client Quit)
13:43:40	*	yglukhov joined #nim
13:43:59	*	petercommand joined #nim
13:44:04	*	petercommand left #nim (#nim)
13:44:13	*	junw_ joined #nim
13:47:50	*	junw quit (Ping timeout: 272 seconds)
13:51:01	Araq	getType should be slower
13:52:21	*	sheerun quit ()
13:54:29	*	Mgeorge joined #nim
13:54:53	*	Mgeorge is now known as Guest47588
13:55:27	filwit	Araq: k, thanks
13:56:08	*	Guest47588 quit (Client Quit)
13:57:34	*	toaoMgeorge joined #nim
14:12:27	gokr	Araq: So, yeah, I was just wondering if I could pass some "pre file" using a specific option to c2nim but yes, of course, I can pass more than one file. Duh.
14:13:19	Araq	a .c2nim file is a "pre file"
14:13:51	*	skyfex joined #nim
14:14:17	gokr	Ehm, "config.c2nim" ok, so... is this a specific file format or... is it described in the manual?
14:14:48	gokr	Or do I just fill it with the same stuff I would put in the #ifdef C2NIM sections?
14:14:59	*	gokr checking c2nim manual again...
14:16:00	*	yglukhov quit (Remote host closed the connection)
14:18:13	gokr	Araq: Ok, nevermind. I found you explaining this in the IRC log back in july.
14:18:23	gokr	So the name is just a convention.
14:18:35	gokr	Cool.
14:19:32	*	Dildosan joined #nim
14:25:13	*	yglukhov joined #nim
14:25:37	Araq	I guess I need to update the docs lol
14:25:54	Araq	it's the same stuff you would put into #ifdef sections
14:33:28	gokr	right
14:43:03	*	darian joined #nim
14:43:50	*	junw_ quit (Ping timeout: 245 seconds)
14:44:25	*	filcuc quit (Quit: Konversation terminated!)
14:48:07	filwit	hmm... i just realized I could easily make a macro which in an objects generic fields from the constructor parameters... that's interesting..
14:48:23	filwit	*infers*
14:50:05	*	skyfex quit (Read error: Connection reset by peer)
14:55:44	*	darian quit (Quit: Page closed)
15:01:24	*	StarBrilliant joined #nim
15:01:48	*	FreezerburnV quit (Ping timeout: 252 seconds)
15:03:19	*	yglukhov_ joined #nim
15:03:19	*	yglukhov quit (Read error: Connection reset by peer)
15:18:12	*	emery joined #nim
15:19:26	*	antoniomo joined #nim
15:31:56	*	arnetheduck quit (Ping timeout: 240 seconds)
15:33:03	gokr	Araq: Idiotic question. So... dynlib, that's for so/dlls, but what about static libs?
15:34:05	Araq	you can either use #header or do nothing.
15:34:29	Xe	is it normal for nim's file handling stuff to eat tab characters?
15:35:01	Araq	if you do nothing, it frees you from being source compatible with the C headers which is usually more of an advantage than a disadvantage
15:35:36	Araq	the codegen then generates the proc headers and you need some --passL logic to pass the static libs to the linker
15:35:40	Araq	Xe: no.
15:35:59	Xe	okay, because I think I am seeing that
15:37:12	Xe	it might be jester though
15:37:25	*	Matthias247 quit (Read error: Connection reset by peer)
15:39:00	Xe	https://git.xeserv.us/xena/twtxtlist/src/master/src/twtxt.nim#L12-L13
15:39:10	Xe	is this the correct way to insert a tab character into a string?
15:40:51	Araq	sure but you can also do x & "\t" & y
15:42:02	Xe	it ate the tab in printing and file io
15:42:16	Xe	https://twtxtlist.cf/twtxt.txt should have a tab there
15:43:25	Araq	I doubt it's Nim's or Jester's fault.
15:43:51	Araq	nimuggest uses the tab as separator too and it works
15:45:05	Xe	huh
15:49:15	*	yglukhov joined #nim
15:49:16	*	yglukhov_ quit (Read error: Connection reset by peer)
15:51:22	*	yglukhov quit (Read error: Connection reset by peer)
15:54:31	*	yglukhov joined #nim
16:01:59	*	yglukhov quit (Read error: Connection reset by peer)
16:04:41	*	yglukhov joined #nim
16:10:04	*	Dildosan quit (Remote host closed the connection)
16:11:55	*	cnu- quit (Ping timeout: 240 seconds)
16:14:33	*	cnu- joined #nim
16:20:01	*	Dildosan joined #nim
16:27:07	*	Dildosan quit (Quit: Leaving)
16:30:31	*	yglukhov_ joined #nim
16:30:32	*	yglukhov quit (Read error: Connection reset by peer)
16:34:09	*	sheerun joined #nim
16:34:10	*	Ven joined #nim
16:40:34	*	yglukhov_ quit (Read error: Connection reset by peer)
16:44:53	*	yglukhov joined #nim
16:46:46	emery	what is a good example in nim to test OS support? (something graphical would be nice)
17:01:59	*	yglukhov quit (Read error: Connection reset by peer)
17:02:22	*	junw_ joined #nim
17:04:42	*	yglukhov joined #nim
17:07:10	*	Trustable joined #nim
17:17:46	*	yglukhov quit (Read error: Connection reset by peer)
17:21:59	*	yglukhov joined #nim
17:26:14	*	derka joined #nim
17:27:49	Araq	emery: hey welcome. what do you mean?
17:28:43	emery	I have hallo.nim running on a new OS but I need a better example
17:30:02	emery	c++ system interface to most everything but compilecpp worked -> http://genode.org/
17:30:51	*	Ven quit (Read error: Connection reset by peer)
17:31:42	emery	I would try aporia but we don't have GTK
17:32:27	*	Ven joined #nim
17:32:36	Araq	ah that's what you mean. hmm, well we have IUP examples, GTK examples, OpenGL examples
17:32:44	Araq	something using Qt
17:32:56	Araq	stuff that uses SDL2
17:32:56	emery	qt would be nice
17:33:11	emery	sdl would probably be eaiser
17:33:40	emery	I would do nimes but it doesn't seem to be working on my gentoo machine
17:33:48	Araq	nimble search qt
17:34:15	Araq	lists git://github.com/filcuc/nimqml
17:34:24	Araq	and usually nimble packages come with examples
17:34:38	*	yglukhov quit (Read error: Connection reset by peer)
17:34:53	Araq	not sure what we've left in the "Nim core" as UI app examples
17:34:53	*	yglukhov joined #nim
17:36:34	emery	I'll just play around with nimble then
17:36:49	*	yglukhov quit (Read error: Connection reset by peer)
17:40:09	*	yglukhov joined #nim
17:41:41	toaoMgeorge	May I ask... when do you guys think Nim will reach 1.0 (just curious)?
17:42:55	*	sheerun quit ()
17:56:43	*	ephja joined #nim
18:01:17	*	antoniomo quit (Quit: WeeChat 1.4)
18:03:47	*	yglukhov quit (Read error: Connection reset by peer)
18:03:54	*	yglukhov joined #nim
18:11:45	*	Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:15:55	*	junw_ quit (Read error: Connection reset by peer)
18:16:00	*	quark1 joined #nim
18:19:52	*	yglukhov_ joined #nim
18:19:52	*	yglukhov quit (Read error: Connection reset by peer)
18:22:23	*	yglukhov_ quit (Read error: Connection reset by peer)
18:27:19	*	Matthias247 joined #nim
18:28:20	*	yglukhov joined #nim
18:29:56	*	Varriount quit (Disconnected by services)
18:29:56	*	Varriount_ joined #nim
18:37:20	*	yglukhov_ joined #nim
18:37:20	*	yglukhov quit (Read error: Connection reset by peer)
18:40:23	*	yglukhov_ quit (Read error: Connection reset by peer)
18:50:12	*	yglukhov joined #nim
18:54:47	*	yglukhov quit (Ping timeout: 264 seconds)
18:55:02	*	matkuki joined #nim
19:04:42	*	sheerun joined #nim
19:09:24	matkuki	Anyone familiar with Chipmunk2D?
19:10:08	ldlework	matkuki: heh still struggling with that?
19:11:01	matkuki	Idlework: Almost done updating it. I'm getting some very small angles with the 'getAngle' procedure and I don't know why?
19:13:00	matkuki	Here is the working version: https://github.com/matkuki/nimrod-chipmunk
19:13:02	matkuki	Everything except the sdl_playground.nim example is working.
19:19:14	ldlework	Sorry I'm in no condition to help atm
19:21:17	ldlework	got my own mysteries
19:21:24	ldlework	Like, wtf does: hatchet.nim(44, 18) Error: invalid type: 'GeneratorType' in this context: 'proc (app: App): GameScene'
19:21:26	ldlework	even mean
19:22:57	matkuki	no idea
19:23:45	ldlework	I feel like I should just ignore concepts all together
19:26:10	ldlework	Araq: am I using concepts wrongly? https://gist.github.com/dustinlacewell/078ced7f6edd6be0a9f7
19:26:29	*	mat4 joined #nim
19:26:31	mat4	hi all
19:26:35	ldlework	hi mat
19:26:49	matkuki	Hey BlaXpirit, thanks for telling me about the 'csfmlNoDestructors' switch, that fixed everything!
19:26:56	matkuki	hi mat4
19:28:01	BlaXpirit	matkuki, yeah but now watch the process eat more and more memory without end
19:29:11	mat4	Araq: How does Nim support contract programming (if at all) ?
19:30:20	mat4	(I mean beside assertions)
19:30:27	Araq	mat4: there is only 'assert' plus what you can come up with via Nim's meta programming facilities
19:30:52	matkuki	BlaXpirit: Nope, holding steady. https://github.com/matkuki/nimrod-chipmunk planets.nim example.
19:31:49	Araq	ldlework: yes but how come
19:31:52	Araq	TreeGenerator* = object
19:31:52	Araq	entities: var EntityManager
19:32:01	Araq	does compile? cause it shouldn't
19:32:06	ldlework	heh
19:32:08	ldlework	it does
19:32:18	ldlework	I can update my compiler but its only a few weeks old
19:32:56	ldlework	Araq: I can commit all the code to a branch if you want
19:33:54	Araq	GeneratorType[TileType] = concept cg
19:33:54	Araq	newChunk(cg, int, int) is Chunk[TileType]
19:34:01	Araq	you need to use
19:34:07	Araq	var x: int
19:34:14	Araq	newchunk(cg, x, x) is ...
19:34:33	Araq	because 'int' would be newChunk gets 2 typedescs which is clearly not what you want
19:35:41	ldlework	As a special rule providing further convenience when writing concepts, any type value appearing in a callable expression will be treated as a variable of the designated type for overload resolution purposes, unless the type value was passed in its explicit typedesc[T] form:
19:35:47	ldlework	type
19:35:50	ldlework	OutputStream = concept s
19:35:51	ldlework	write(var s, string)
19:35:54	ldlework	I was just mimicing this example
19:36:19	ldlework	newChunk's signature is (GeneratorType[TileType], int, int) so that's why I wrote that.
19:37:16	ldlework	So you have to pass actual values when calling a proc inside of a Concept?
19:38:58	ldlework	btw, when I remove the "var" from the structure type declaration, I get:
19:39:01	ldlework	hatchet.nim(42, 32) Error: type mismatch: got (EntityManager, string)
19:39:03	ldlework	but expected one of:
19:39:05	ldlework	system.create(T: typedesc, size: Positive)
19:39:07	ldlework	entities.create(em: var EntityManager, tmpl: string)
19:39:51	ldlework	Because I'm calling it with "gen.entities.create(...)"
19:40:31	ldlework	where entities is a field on gen
19:43:50	Araq	is that still in the manual?
19:44:03	Araq	need to remove it, that's not how it works anymore
19:44:05	ldlework	yeah
19:44:08	ldlework	oh?
19:44:22	ldlework	It doesn't say how to express proc constratints otherwise
19:44:33	Araq	I just told you.
19:44:37	ldlework	I had no inkling that you have to create a useless variable just to pass it to the proc
19:44:51	ldlework	Sure I'll try it
19:44:54	Araq	"further convenience" my ass when the feature is hardly usable in the first place
19:45:14	ldlework	well that is a far nicer way to express it
19:45:30	Araq	that's just a template away anyway
19:46:06	Araq	template oftype(t: typedesc): untyped = (var x: t; x)
19:46:15	Araq	write(oftype(string))
19:46:35	ldlework	So you're saying it would be trivial to maintain as syntax.
19:46:51	Araq	no, quite the opposite
19:47:06	ldlework	that its trivial for everyone to have this template in their codebase
19:47:58	Araq	no, I am saying that we could eventually introduce such a helper
19:48:19	ldlework	oh gotcha.
19:48:31	Araq	but it would always be explicit because further conflation of typedesc[T] with T is misguided
19:48:43	Araq	and typedesc is already a clusterfuck to support in the compiler
19:49:36	ldlework	Sorry to hear its so complicated. It does allow for nice expressions of things.
19:49:50	Araq	and it took years until we read about it in the literature and to learn how its type theory works
19:50:06	ldlework	You mean treating types as values?
19:50:49	Araq	I mean what typedesc[typedesc[T]] should mean
19:51:16	ldlework	ah
19:51:50	ldlework	So i guess I'm just hung up on this line: GameTile(entity: gen.entities.create("tree").id)
19:52:05	ldlework	where its complaining that I'm passing a non-var 'entities' to create()
19:52:18	ldlework	that's why I put 'var' in the field declaration for the generator
19:52:39	ldlework	do I have to do `var x = gen.entities; x.create(...)`
19:53:09	ldlework	hmm doing that just gets me, hatchet.nim(45, 18) Error: invalid type: 'GeneratorType' in this context: 'proc (app: App): GameScene'
19:53:11	ldlework	again
19:54:02	Araq	oh yeah that also cannot work :P
19:54:08	Araq	a concept is not an interface
19:54:16	Araq	you cannot store it in an object
19:54:20	ldlework	it sure seems like one
19:54:23	Araq	it has no runtime representation
19:54:28	ldlework	oh I don't want to store it..
19:54:34	Araq	it's just a fancy generic constraint
19:54:43	ldlework	Isn't that how I'm using it?
19:54:49	Araq	Tilemap*[TileType] = ref object
19:54:49	Araq	chunk_width, chunk_height: int
19:54:49	Araq	chunks: Table[Point, Chunk[TileType]]
19:54:51	Araq	generator: GeneratorType[TileType]
19:55:12	Araq	that surely stores it in the Tilemap
19:55:12	ldlework	Yes, I only want to store T's on a generator field
19:55:24	ldlework	where T is T: GeneratorType[TileType]
19:56:39	*	yglukhov joined #nim
19:58:46	Araq	speaking of which ... can we replace 'method' with Go-like interfaces in the language and call it a day? anybody who wants to implement that?
19:59:06	ldlework	oh my god
19:59:18	toaoMgeorge	Yes
19:59:39	ldlework	the death of nim :(
19:59:43	Araq	I'm tired of explaining 'concept' to people. Or 'method'.
20:00:17	ldlework	Araq: it wasn't that my field type was specified as GeneratorType
20:00:25	*	dashed quit (Quit: Connection closed for inactivity)
20:00:26	ldlework	it was that I did not add GeneratorType to the brackexpr of Tilemap
20:00:41	ldlework	once I added a second generic param to Tilemap[TileType, GeneratorType] it worked
20:01:08	ldlework	I'll be super sad if methods go away.
20:01:18	Araq	interesting.
20:01:30	*	yglukhov quit (Ping timeout: 272 seconds)
20:01:44	ldlework	You can't express crap with go interfaces.
20:01:52	ldlework	Everything interesting ends up as interface{}
20:02:00	ldlework	which is truely useless.
20:02:07	ldlework	might as well use python
20:02:19	Araq	I think since we have generics they would be much more useful for us
20:02:19	*	yglukhov joined #nim
20:02:39	ldlework	I seems strange to me that method are the hard thing to maintain.
20:02:39	Araq	as well as easier to understand for people.
20:02:48	ephja	and then silly casts
20:02:54	ldlework	exactly
20:02:57	ldlework	its so nasty
20:03:10	Araq	well don't get hung on "Go-like" too much
20:03:13	ephja	I don't remember many details, but it seemed ridiculous
20:03:20	ldlework	I'm also suspect that methods are these things that people don't understand
20:03:25	ldlework	That have to be continuously explained.
20:03:27	Araq	I just meant structural typing
20:04:10	Araq	well I guess it's easy to say "it will be easier" when I don't even have any kind of spec in my head
20:05:30	ldlework	Methods are super nice, if I can't express my relationship at compile-time methods are always a runtime solution that seems connect up the gap I cross at compile time.
20:05:53	ldlework	That they are supported by the language and I don't have to do anything special when I cross that bridge is like having running water.
20:07:36	ldlework	heh doh
20:07:37	ldlework	hatchet.nim(50, 30) Error: type mismatch: got (int literal(10), int literal(10), TreeGenerator)
20:07:39	ldlework	but expected one of:
20:07:42	ldlework	tilemap.newTilemap(chunk_width: int, chunk_height: int, gen: GeneratorType)
20:09:12	*	brson joined #nim
20:13:19	ephja	can the usual construction pattern be used, when the type in question is expected to have descendents? "proc newBaseClass(): BaseClass"?
20:14:04	ephja	or must this pattern be used: "proc init(o: BaseClass) = o.foo = ..."?
20:15:51	Araq	init for obvious reasons (BaseClass has a different size)
20:15:59	ephja	right
20:16:14	ephja	we did talk about a potential constructor pragma before. I wonder if it's doable with a macro
20:17:08	ephja	"let x = initFoo()" calling initFoo(foo: var Foo), but the 'let' would have to be dealt with, though the call site can be modified
20:19:31	*	sheerun quit ()
20:20:15	toaoMgeorge	http://blog.rust-lang.org/2015/05/11/traits.html
20:21:07	toaoMgeorge	What do you think of those?
20:21:29	filwit	+1 for keeping methods around.. i use them sparingly, but i *do* use them.. if anything, 'interfaces' should just be built with Nim's meta-programming and added as part of the standard lib (though to do it properly you might want some kind of 'concept' reflections/getType equivalent)
20:21:51	gokr	I use methods a lot.
20:22:55	ldlework	toaoMgeorge: If I remember correctly Rust never got like default implementations or something was missing forever and then they decided to never implement it.
20:23:10	ldlework	Which made traits not a full solution for me. But I forget what it was at this point.
20:23:19	ldlework	Default method implementations? Something like that.
20:24:22	gokr	What came of fowl's stuff?
20:24:27	ldlework	I think it was the eventual reason why I left Rust and eventually found Nim. It simply implemented methods (which allowed me to get what I was trying to do, done) and then I was eventually sucked in by the meta programming.
20:25:09	ephja	I dunno if that would get us closer to a more general allocation scheme (new(Foo, arg...) and init(Foo, arg...) allocating on the heap and stack respectively, and then invoking the same initialization proc)
20:25:23	ephja	inheritance might complicate such an interface
20:26:18	gokr	IMHO methods is a very important "bridge" for us Smalltalk/Python/Ruby people. Otherwise the dynamic OO story is incomplete for us.
20:26:20	filwit	pretty sure in Rust traits double as both an ad-hoc generic specialer and 'interface' (fat pointer to vtable & instance) when used a struct field... but that was awhile ago I heard that and can't remember where from now..
20:27:54	toaoMgeorge	Mmh
20:27:55	Araq	toaoMgeorge: ah yeah that design ... doesn't really fit Nim. but it's nice.
20:28:10	gokr	Although I would be interested to hear how "Go like interfaces" would work.
20:28:11	ephja	filwit: that's correct IIRC
20:28:47	ldlework	I think the general pattern of why I need this stuff is because I want to implement some type L that accepts some type U. Then the way I want to use L is by importing it, passing it something that's *like* a U, a U' and then getting that U' back later as a U'.
20:28:57	ldlework	But I don't have control of L at all.
20:29:21	ldlework	With methods, this pattern just works everytime.
20:29:38	ldlework	Generally, I want U to provide me most of the implementation.
20:29:47	ldlework	And I want to customize that implementation with U'
20:29:56	Araq	ldlework: if I ever design a new PL, it will likely be "dynamically typed" and use a specializer to get efficiency back and a theorem prover to get the type safety back
20:30:07	gokr	Araq: Wow.
20:30:20	ldlework	I just want to write reusable code.
20:30:20	Xe	how do I depointer a pointer in nim?
20:30:39	Araq	it sucks that every aspect ends up in the type system
20:30:41	ephja	Araq: and the performance?
20:31:12	mat4	ldlework: What is your opinion about functional programming ?
20:31:39	ldlework	mat4: I'm all for it. I try to use it wherever I can identify places to do so.
20:31:47	*	sheerun joined #nim
20:31:52	ldlework	I love building up a vocabulary tiny atomic partials.
20:32:03	gokr	ephja: Performance is fairly orthogonal to dynamic/static typing - contrary to most people's belief. Dynamic typing needs smarter runtime support though.
20:32:07	ldlework	But functional programming isn't a magic wand that makes the usecase I just described go away.
20:32:19	Araq	currently type systems have to deal with too many conflicting goals
20:33:06	filwit	honestly I think the best theoretical "concept" design for Nim would be to have two types, much like it has two meta-programming procedure types... eg, a 'trait' which is a structurally iteratable type which can be used as both ad-hoc generic & interfaces (just like Rust), and our current 'concept' which gives you the full power to specialize ask questions (but can't be iterated over easily)
20:33:47	Araq	fowl worked on a macro that turns a concept into an interface
20:33:56	Araq	that's the right thing for Nim right now
20:34:07	ephja	ldlework: have you tried to define concepts with procs containing var parameters yet?
20:34:16	gokr	Araq: That was the thing I was asking status about.
20:35:01	Araq	well fowl is not exactly active these days
20:35:11	filwit	Araq: well that would be perfect of course, but I don't see how it's possible.. i mean a concept can pretty much ask any question, so how can you figure out which procs are available?
20:35:32	Araq	you inspect the concept in the macro and bail out if you cannot handle the construction
20:35:43	Araq	pretty easy.
20:37:16	Araq	gokr: I disagree. The data type layouts that static typing produces are just more or less impossible to produce with a dynamic language.
20:37:16	filwit	yeah but that seems bug-prone.. ie, the concept could behave differently for an interface than for a generic-specalizer.. though I suppose since the interface version would always be "sub set" of the concept's features it might not actually cause problems..
20:37:41	Araq	case in point: JavaScript has superb JITs
20:37:47	Araq	and yet got typed arrays anyway.
20:38:19	gokr	I did say "fairly" :)
20:38:27	ephja	let's get cracking with nim 2 then :p
20:38:37	filwit	LOL
20:38:58	ephja	I'll be in charge of delegation
20:39:15	gokr	Of course its an advantage to know everything at compile time. But there are things that you still can do better with adaptive optimization.
20:40:14	filwit	gokr: yeah but those optimizations can be applied to static, JIT compiled languages much easier
20:40:32	*	filwit hates dynamic languages
20:40:37	gokr	filwit: Is that really a truth, or just something you "think"?
20:40:49	filwit	something I think
20:41:18	gokr	Strongtalk for example, which had static typing - didn't use it at all to get its superior performance at the time. It was all PICs and adaptive optimizations.
20:41:42	gokr	The stuff that was later commercialized as Hotspot tech - and bought by Sun and stuffed into the JVM.
20:41:55	gokr	Self was first though.
20:42:21	gokr	Araq: Are there statically typed langs that do similar stuff at runtime?
20:42:29	gokr	I am not aware of any I think.
20:42:46	filwit	I don't know anything about the tech you just brought up, but I don't see how a dynamic language could gain any extra performance over a static language just by adding JIT (which can be applied to both)
20:43:12	gokr	filwit: The difference is not purely JITing - the difference is adapting to runtime circumstances.
20:43:17	filwit	of course, I would be very interested to be proven wrong on that point
20:43:29	gokr	A pure JIT doesn't really do that.
20:44:03	gokr	Its a given that a "smart enough" adaptive runtime can beat a static compiler - it simply has more info.
20:44:37	mat4	that's right
20:44:54	filwit	okay sure, if your code made heavy use of tables, having a mechanism which built those into inline memory structures and treated them as structures on-the-fly could be very useful... but even then you could, theoretically, do the same thing in a static language with a specific library
20:44:58	gokr	Its just damn hard to write such adaptive runtimes.
20:45:19	filwit	but yeah, that might need compiler support to be "easy"
20:45:29	ldlework	We don't need a new language
20:45:32	gokr	filwit: The difference is that in runtime you can see the data - like say a loop - and decide that, hey, I can optimize for this specific case.
20:45:34	ldlework	We just need to not throw away methods
20:45:38	ldlework	a feature we already have
20:46:25	ldlework	methods + meta-programming + macros == everything I've ever needed to express anything I've ever wanted to express
20:46:46	gokr	I think for example that the JVM is beating C++ these days on certain benchmarks. I suspect that is due to the adaptive optimizations.
20:47:16	filwit	gokr: but what you said is somewhat reverse of what you're suggesting since the runtime (in a dynamic language) has to first proof the type structure at runtime before it can optimize that loop
20:47:47	gokr	(duh, Java is of course a case I didn't even consider. Statically typed with heavy adaptive opts.)
20:48:22	filwit	and since 90% of the time your types don't randomly change structure, it doesn't make sense not to help the compiler out in the optimization step
20:49:11	gokr	filwit: Not sure what you are saying. And I am no expert - but I do *know* adaptive optimizations at runtime can beat statically compiled code. Its not surprising either.
20:50:40	filwit	I'm not saying they can't, but "adaptive optimizations" imply a lot.. I was specifically talking about data structures in a statically typed vs dynamically typed language..
20:53:30	mat4	a JIT compiler has the advantage of accessible runtime state(s) for optimization. A Side effect of this is the possibility to tag storage locations with specific data formats. A static compiler can't use the dynamic program state for optimisation beside runtime interpretation
20:55:00	mat4	which transform the static compiler in fact to a special case of inefficient JIT compiler
20:56:22	filwit	yeah, I've always thought JIT was theoretically better than AOT compilation... I wasn't trying to imply anything different by saying "static language" (i guess that term is far too broad)
20:57:50	*	Trustable quit (Remote host closed the connection)
20:58:52	filwit	anyways, gotta do other stuff for a bit, bbl
20:58:56	mat4	I think the real difference lays in the possibility of a language environment supporting dynamic code transformation (programs which extend or modifcate there own code for example)
20:59:09	mat4	^modificate
20:59:38	Araq	mat4: the problem with "adaptive" optimizations that e.g. infer "this is an array of plain old ints" is that they use the program's history
20:59:58	Araq	and so need to shield against a future where everything is possible anyway
21:00:00	filwit	mat4: even if the compiler can do that for optimization, you would still only want to do it once and cache the result (unless your hardware is dynamic of course)
21:00:15	Araq	with static information you know the *future* in addition to that
21:00:41	Araq	so you know it'll always stay an int array and need no guard checks whatsoever
21:01:05	toaoMgeorge	Araq: where can I find that fowl's work you were talking about?
21:01:34	Araq	and the last time I checked even LuaJIT doesn't produce vector instructions though there was some talk that it's possible
21:02:37	Araq	knowing the future is far superior than recording the history.
21:02:41	Araq	*to
21:02:42	mat4	Araq: That's language dependent. For a 'pure' dynamic language there is no static state because all definations can change at runtime, which is intended so no demand for protection
21:03:47	mat4	for this such languages often use external code specification modelling
21:04:40	gokr	This article explains some of how Hotspot and similar VMs work: https://clementbera.wordpress.com/2014/01/09/the-sista-chronicles-i-an-introduction-to-adaptive-recompilation/
21:04:55	gokr	Clement writes in an easy to understand way.
21:05:01	filwit	Araq: to play devils advocate, there is the possibility where a code-base was making heavy use of Tables (objects who's future couldn't be known) and, for efficiency, would compile these into "real" binary objects for specific life-cycles (or something like that... much like Google's V8 Javascript compiler works)... in that scenerio it would be a benefit to have "compiler support" for those data structures over a simple library
21:05:02	filwit	(because the compiler to could indicate life-spans, etc)
21:05:49	Araq	runtime adaptive optimizations are very useful no doubt, but they can all be applied to static languages too
21:06:10	Araq	but staticness buys you something no "adaptive" technology can buy.
21:06:22	Araq	which is: knowing the future.
21:07:24	Araq	the only reason C++ environments have no JIT by now seems to be that there is not much to be gained from it
21:07:50	Araq	otherwise somebody would start to do it and the others have to follow
21:08:05	filwit	well.... there is LLVM which has a JIT
21:08:06	Araq	since lots of people are very interested their C++ code runs as fast as possible
21:08:35	Araq	LLVM started with a JIT to get its funding.
21:09:00	gokr	toaoMgeorge: I can't find it, but he is "fowlmouth" on github
21:09:00	Araq	that's my impression at least, don't quote me on that.
21:09:36	filwit	yeah, anyways bbl
21:09:43	Araq	but that just hardens my point: JIT for C++ is possible but nobody is interested in it
21:10:01	Araq	clang is a traditional static compiler toolchain
21:10:24	gokr	Araq: Couldn't in theory statically typed languages end up being written in a "too static" style thus actually *preventing* good adaptive optimization?
21:10:40	gokr	I mean "programs in statically typed languages".
21:10:46	*	tstm quit (*.net *.split)
21:10:55	mat4	in my opinion it makes no sense to write a JIT compiler for languages like C++ because of there static design
21:11:03	*	tstm joined #nim
21:11:22	filwit	mat4: both C# and Java disagree with you there
21:11:23	gokr	Its just a nagging feeling I get often when I read statically typed code... code that basically manually performs the various lookups and matches.
21:12:35	Araq	gokr: well no, in theory knowing more about a program can't hurt. In practice too many specializations can blow up your instruction cache and your C++ can be slower than your Smalltalk code
21:12:39	mat4	filwit: Bith languages use AOT compilers, even Google switched to this compilation technique for tehre Java environment
21:12:41	filwit	"manually performs the lookups and matches" is exactly what a dynamic language does, not a static one
21:12:51	gokr	filwit: You missed my point.
21:12:58	gokr	I think.
21:13:20	Araq	gokr: so it's the opposite I think. In theory you can't lose. In practice you can. ;-)
21:13:39	*	matkuki quit (Quit: ChatZilla 0.9.92 [Firefox 44.0/20160123151951])
21:13:47	ldlework	gokr: I had the same response as filwit
21:13:49	filwit	gokr: perhaps.. but I think the phrasing was a bit unclear. "performing" a lookup implies doing more work, which is what a dynamic language has to do
21:13:52	gokr	So, take for example this: http://nim-lang.org/docs/manual.html#types-object-variants
21:13:58	Araq	but then in practice even Smalltalk systems don't stay small, right? ;-)
21:13:59	ldlework	It seems like when I look at dynamic code, its the one doing all the checking.
21:14:06	ldlework	isinstance, hasattr and so on
21:14:21	ldlework	gokr: that to me expands out to different functions though
21:14:24	ldlework	that contain no type checking
21:14:27	ldlework	when I see cased code
21:14:33	ldlework	same with generics
21:14:34	filwit	mat4: sure, AOT with JIT options.. I'm just saying they're not like C/C++ AOT and are statically typed
21:14:51	gokr	ldlework: But it basically is doing polymorphic dispatch - but manually.
21:14:59	ldlework	no not manually
21:15:02	ldlework	its not doing dispatch
21:15:07	ldlework	its expanding it out to different implementations
21:15:12	ldlework	which contain no dispatch at all
21:15:30	ldlework	as if I had written individual distinct implemenations, except I didn't have to do that manually.
21:15:35	ldlework	Its the best of both worlds.
21:15:42	ldlework	I get to express a generic relationship, but pay no cost for it.
21:15:55	ldlework	that's clearly the superlative case, imo.
21:17:27	Araq	there seems to be a misunderstanding here
21:17:29	gokr	ldlework: Ok, you are probably right. I think I misunderstood that part.
21:17:33	ldlework	no doubt :D
21:17:47	gokr	So that was a bad example indeed.
21:18:05	*	cyraxjoe quit (K-Lined)
21:18:36	mat4	filwit: my point is that I can't see any advantage for static compilation in case of dynamic languages or dynamic programming techniques. That's at current a weak point of static compilation. In all other cases interpretation is easier to implement and efficient enough (both in therms of ressource usage and performance)
21:19:11	gokr	But... I do get the feeling that a lot of code (in more complex systems) written in statically typed languages tend to end up ... doing workarounds that hurt more than they help. For example, in Java they started misusing XML for EVERYTHING just to avoid recompilation.
21:19:52	ldlework	gokr: In Nim you have a great type system, with generics, typeclasses, user-type-classes (not really, do they work?)
21:20:04	mat4	It's natural to add JIT compilation to an interpreter so the usage of static against dynamic compilation is really a consequence of language design
21:20:10	ldlework	And then you also have the ability to /directly/ expand parameterized implementations with templates and macros.
21:20:15	Araq	gokr: which ends up being slower than a solution that stays in JIT'ed Smalltalk all the way, yes
21:20:24	gokr	Araq: Exact.
21:20:42	gokr	That was just what I was trying to say.
21:20:57	filwit	mat4: yeah I agree with that. You said something about no need for a JIT with statically typed languages above which is what I was responding too.
21:21:04	Araq	but that's just a psychological thing, IMO.
21:21:13	gokr	There were a number of large systems rewritten in C++ (from Smalltalk) in order to *gain* performance but ended up being DOG SLOWER instead.
21:21:24	gokr	And still - in a micro benchmark C++ will beat Smalltalk.
21:21:35	ldlework	Well sure, anyone can implement mud.
21:21:38	*	yglukhov quit (Read error: Connection reset by peer)
21:21:41	gokr	So in larger systems the simple truths dont work.
21:22:01	ldlework	Given infinite resources, you'd be able to build a more efficient system in C++.
21:22:01	mat4	filwit: ah, ok
21:22:25	*	yglukhov joined #nim
21:22:32	ldlework	Since you could just reimplement smalltalk if you wanted. If it turns out that smalltalk is literally the most efficient solution in this universe.
21:22:59	ldlework	I just doubt that, "implement smalltalk in C++" is how you get to the efficiency of smalltalk implementations if you have to use C++.
21:23:05	Araq	ldlework: that cuts both ways, you could implement a C++ compiler in Smalltalk
21:23:28	ldlework	Sure, but you wouldn't be running the C++ compiler as the solution for your problem.
21:23:35	gokr	ldlework: I am not following.
21:23:39	ldlework	You'd still have to then write the C++ solution to your problem and compile it with your C++ program.
21:23:47	mat4	one could write a Smalltalk implementation without much effort in assembler
21:24:08	ldlework	gokr: I'm saying, given two teams, one using C++ and one using Smalltalk, and given the same task - given infinite resources, the C++ team could always implement the smalltalk team's answer.
21:24:15	gokr	mat4: There have been several.
21:24:16	ldlework	The implication of that is:
21:24:56	gokr	ldlework: Its a fairly uninteresting statement.
21:25:00	ldlework	Unless the most efficeint solution to the problem available in our universe is always modeled by a smalltalk runtime - then C++ seems like it has an inherent advantage.
21:25:06	ldlework	Not really.
21:25:29	gokr	ldlework: Its like saying "Well, given enough resources I can do it all better in assembler".
21:25:51	ldlework	The reality where "smalltalk can always produce a more efficient solution" is one in where, anytime you're using C++, you must implement smalltalk in order to produce an equivalent solution.
21:26:01	ldlework	That's clearly not true.
21:26:12	ldlework	Even for large programs.
21:26:25	ldlework	That Java people started writing their programs in XML says nothing at all really.
21:26:40	Araq	another problem is that the hardware itself is already quite "adaptive". it predicts branches and memory access patterns etc. The moment JITs do better for C++ than C++ would do otherwise the hardware should change and do the same thing the JIT does :P
21:27:16	ldlework	The reason it says nothing at all, is because I'm not inclined to write my Nim program in XML.
21:27:23	mat4	of course it says that Jave programmers favorite XML against there Java (which I can understand)
21:27:25	ldlework	There is a reason why Nim didn't simply replicate Java's type system.
21:27:33	ldlework	haha
21:27:36	gokr	ldlework: If we are now in the "I refuse to try to even argue reasonably" I am out.
21:27:59	ldlework	gokr: I think I'm making a very reasonable low level observation about the argument you were making above.
21:28:07	ldlework	I'm not trying to be unreasonable at all. But if the point is confusing I'll drop it.
21:28:29	mat4	sorry, what was the argument again ? I'm lost in different postings
21:29:06	gokr	So you think its interesting to say that... the C++ team can always reimplement Smalltalk, and thus can always "win"? Well, fine, as i said - no point in discussing.
21:29:48	ldlework	I thin the premise was, at large enough program sizes, with languages like C++ and Java, you're forced to simply reinvent smalltalk, or die trying with some isnane XML dsl.
21:32:20	*	yglukhov_ joined #nim
21:32:20	*	yglukhov quit (Read error: Connection reset by peer)
21:32:38	gokr	The simple point I was making (which Araq btw grokked easy enough) is that statically compiled languages, especially when used in large complex systems, don't help that much. This has been seen in practice in history. And I suspect it has largely to do with the "straight jacket" of the type systems causing workarounds and insane code.
21:33:06	gokr	And in fact, performance is often not the main key either. Its maintenance and ability to adapt quickly.
21:33:38	Araq	Well but to be fair, pleny of large C++ codebases prove the opposite too.
21:33:47	mat4	as addition: I think that most higher level Smalltalk aren't able to express with Langauges like C++
21:34:09	gokr	However, I do find it very interesting that Araq would contemplate making a dynamically typed language. I had never expected to hear those words :)
21:34:39	Araq	There is no evidence the typical AAA game title could have been written in Smalltalk instead.
21:34:45	gokr	mat4: True, most of those systems engage in meta programming which is obviously not at all easily done in C++.
21:35:45	Araq	I remember one console title that was programmed in Lisp and they had to rewrite large parts in C++
21:36:15	Araq	I doubt their Lisp system was just badly designed.
21:36:23	mat4	I've onced talked to a programmer from IBM which chooses Smalltalk for a really sophisticated and large database product because of its meta- and dynamic programming features
21:37:07	gokr	mat4: yeah. It's the obvious case. Finance. Large manufacturing systems etc.
21:37:34	Araq	gokr: well it's just "dynamically typed" as the starting point to get the simplicity. as I said, 2 additional things would be added on top of that
21:37:59	Araq	one to easily get back the runtime efficiency
21:38:24	gokr	Araq: I agree, for raw low level performance Smalltalk is not it. Just like Java isn't really either.
21:38:33	Araq	one to get back type safety and hopefully far exceed the state of the art in this aspect.
21:39:22	Araq	in other words there would be code, then decoupled from that efficiency annotations
21:39:37	Araq	and then decoupled from that proof and typing annotations
21:40:17	gokr	i would love to see a language that is malleable and dynamic like Smalltalk - but able to later on be "coached" into really hard performant code, using annotations.
21:40:25	gokr	Its kinda like what Dart is doing I guess.
21:40:34	gokr	Or could do.
21:40:37	Araq	and I think it would throw away any plan to ever do this stunt with incremental compilations.
21:40:40	gour	gokr: do you still do smalltalk/pharo?
21:41:07	gokr	gour: For the moment I don't. I spend daytime messing with javascript and what not. And free time I spend on "Ni".
21:41:40	gokr	Araq convinced me the other day to turn the Ni interpreter stackless - so that is my next task there.
21:42:10	gour	gokr: Ni is scripting language ala smalltalk?
21:42:18	gokr	Well... kinda.
21:42:46	gokr	I got inspired by Rebol actually. Which is very Forth-ish/Lisp-ish in syntax and semantics.
21:43:16	gokr	So I hacked up Ni as a Rebol-ish language, but then I started drifting towards Smalltalk by adding keyword syntax etc.
21:43:31	gokr	Its pure fun. And I think its getting interesting.
21:44:11	*	yglukhov_ quit (Remote host closed the connection)
21:44:17	gokr	https://github.com/gokr/ni
21:44:45	gokr	It does have a REPL, and I just switched to using ... the stuff in Nim that wraps linenoise. So you get history and line editing.
21:45:26	Araq	oh btw "Even if a software application is big, usually at most 10% of its code is frequently used."
21:46:26	Araq	Unreal Engine is claimed to have a "flat profile" meaning that after diverse rounds of optimizations they got it to the point where lots of things are equally performance critical
21:46:29	gokr	gour: But its truly for the ... insatiably interested. :) No solid language manual yet.
21:46:45	gour	gokr: ok, i got it ;)
21:47:11	gokr	gour: But do play around if you are interested. It's only about 1100 loc I think.
21:47:23	Araq	and that doesn't even take WCET into account.
21:47:38	gour	gokr: well, i've to play with nim first ;)
21:47:44	gokr	WCET?
21:48:03	Araq	"worst case execution times"
21:48:07	gokr	Ah
21:48:14	Araq	important for hard realtime stuff.
21:48:20	gokr	yeah
21:48:52	gokr	mat4: Didn't you play around with some VM thingy?
21:49:00	mat4	yes
21:49:05	gokr	How are things going there?
21:49:10	*	brson quit (Ping timeout: 250 seconds)
21:49:12	Araq	I happened to work for such a company, you know. They support hard realtime with Java.
21:49:19	gokr	(and oh, Ni runs in nodejs btw, that was insane)
21:49:23	Araq	you know what they do?
21:49:34	gokr	No objects :)
21:49:38	Araq	the compile all of the Java code ahead of time.
21:49:41	Araq	*they compile
21:50:08	gokr	Yeah, I know. In those cases its more important to have predictable performance.
21:50:25	mat4	gokr: I use it as environment for my processor design
21:50:31	gokr	Ah, cool.
21:51:06	gokr	Araq: Its not that I am against AOT. I just haven't seen ANY statically typed language matching the malleability and live coding experience Smalltalk offers. I want both.
21:51:34	gokr	Smalltalk/X can compile AOT too IIRC.
21:51:43	gokr	But... never used it.
21:51:55	gokr	I suspect they do something like you do :)
21:51:59	gokr	(compile to C)
21:52:25	mat4	also I'm writing a 'pure' concatenative language at current for my own which is 'pure' dynamic to ease development
21:52:50	gokr	Ah, neat! In Nim?
21:53:29	mat4	yes
21:54:01	gokr	mat4: I am right now toying with c2nim-wrapping the Arduino libs.
21:54:42	gokr	I have a ... MediaTek Linkit ONE that I want to see if I can get Nim (and Ni) going on.
21:54:47	mat4	that's great news
21:55:27	Araq	anyway, it's nice to hear you guys actually like methods and want them to stay in the language :-)
21:55:29	mat4	I hope to have an Arduino like IDE ready soon for my project
21:55:51	gokr	The Arduino IDE is friendly enough to show what they hell its doing when compiling. So I am making a Makefile out of that (and other sources on the net).
21:56:39	gokr	Araq: I like them a LOT. Of course open for alternatives, but don't just remove them because... then you lost me at least :)
21:56:56	gokr	The Ni interpreter uses them a lot.
21:57:24	Araq	well I have an alternative besides 'interface'
21:57:44	gokr	And I do like the fact that Nim has no "class/traits/interface" group-of-behaviors-concept.
21:57:57	gokr	In fact... that inspired me to not introduce it in Ni either.
21:58:15	gokr	I am gonna try something else crazy for polymorphism in Ni.
21:59:06	mat4	personally I found no real use for such abstractions. Compile time contract support would be nice however (requires, final etc.)
21:59:28	gokr	mat4: But you are a Forth guy. :)
21:59:39	mat4	right
21:59:51	gokr	Which I really respect. Forth is the Zen.
22:00:02	gokr	I love it in theory, but never got around to actually code it.
22:00:23	gokr	And of course... no automatic memory management etc... not really 2016 :)
22:00:23	mat4	it's mor a philosophy than a language
22:00:38	gokr	In Ni I do try to capture some of those values though.
22:00:46	gokr	For example, there are no keywords in Ni either.
22:01:28	gokr	And while I don't have a stack for arg passing - it works similarly.
22:03:04	*	Varriount_ is now known as Varriount
22:03:12	mat4	Your language is concatenative as I see, for which a stack representation is only an implementation strategy not mandatory
22:03:26	gokr	Araq: IIRC there is no mechanism today to write Nim code that can analyze a Nim module (the AST) and spit out another Nim module? I mean, without annotating the first module.
22:03:47	gokr	mat4: Good point.
22:04:17	gokr	mat4: I ran with threads the other day, that was fun.
22:04:50	gokr	mat4: Creates a separate interpreter in the spawned thread :)
22:05:12	mat4	ah yes, I choosed the same approach
22:05:55	gokr	Araq: For stackless, am I correct that using procvars I can stuff the "next call" into the activation record, and let the interpreter loop use that to dispatch further?
22:06:23	Araq	that sounds it would work
22:06:46	gokr	Itching to try it out soon. Doesn't seem that hard.
22:06:48	Araq	gokr: surely there is a way, but it's a bit ugly with staticRead and parseStmt
22:07:22	gokr	Araq: Reason I ask is because... it would be super cool to be able to generate glue code for wrapping Nim modules for use in Ni.
22:08:12	gokr	Has the use case never come up before?
22:08:34	gokr	Outside of the compiler I mean ;)
22:08:48	Araq	usually .push myMacro is good enough
22:09:03	Araq	it's often overlooked that it is possible.
22:09:11	Araq	in fact ... I'm not sure it's possible.
22:09:15	Araq	never tried it :-)
22:09:23	gokr	Eh. ".push myMacro"?
22:09:29	Araq	it's an accidentical feature if it works
22:10:52	Varriount	<3 Closures
22:13:50	Araq	so .. nobody wants to hear my alternative to methods that have never been done elsewhere afaict
22:14:00	*	Varriount_ joined #nim
22:14:00	*	Varriount quit (Disconnected by services)
22:14:06	*	derka quit (Ping timeout: 245 seconds)
22:15:48	gokr	Araq: I definitely do, just chatted with mat4 a bit :)
22:16:11	gokr	Araq: Hit us with the cool shit.
22:19:36	mat4	what are these alternatives ?
22:21:33	Araq	I'm preparing a gist
22:24:11	*	Dildosan joined #nim
22:26:41	filwit	i'm interested in this method alternative
22:28:19	*	gour quit (Quit: WeeChat 1.4)
22:29:01	Araq	https://gist.github.com/Araq/03629a7e9e4da243c59f
22:29:21	Araq	the vtable creations etc can already be done conveniently via a macro
22:29:59	Araq	but currently the delegation aspect would require ugly converters and the .delegate(this) is currently quite impossible to achieve
22:30:39	Araq	the .delegate pragma is also useful for all kind of wrappers, was a topic on the forum
22:31:33	Araq	I think D does something very similar with its "alias this" idea.
22:31:49	Araq	which is a way to introduce restricted type converters.
22:32:23	Araq	but we extend the idea to get rid of the traditional idea that 'method' needs to be a language builtin
22:33:06	*	brson joined #nim
22:38:11	gokr	Araq: I can't say I understand the exact implications. It seems every concrete (instantiated) type will correspond to a unique vtable?
22:39:39	Araq	well one implication is that we trade multi methods for traditional methods
22:40:22	Araq	but are more flexible in how it's done and need more macros to make it convenient
22:41:11	*	Demon_Fox joined #nim
22:41:46	filwit	can't this basically already be done with a "macro `.`(obj:T, call:string)" ?
22:43:01	Araq	hmm good question, I like to ignore that overloading of `.` is in the language
22:43:03	gokr	Araq: Ah, right. Only dispatch on receiver.
22:43:14	Araq	gokr: exactly.
22:44:38	*	yglukhov joined #nim
22:45:55	*	vendethiel- quit (Ping timeout: 260 seconds)
22:46:06	filwit	yeah i know for almost a fact that I could make a macro lib which provides this delegate feature.. you can just use {.pure inheritance.} instead of your {.delegate.} to specify to the `.` macro which fields should be consider for delegation
22:47:54	filwit	eg: type Delegate {.pure inheritable.} = object; type VTable = object of Delegate ...; type Foo = tuple[vtable:Vtable]; let f: Foo; f.fuzzbuzz();
22:48:56	filwit	so basically, Araq, you've already made this feature in the language without considering it yet! meta-programming FTW
22:49:32	filwit	actually, what would be very nice for this type of thing is user-defined pragmas for type fields
22:49:32	Araq	no, zahary did it.
22:49:39	filwit	oh, okay
22:50:01	Araq	and he is usually very aware of what it's possible with the features he put into Nim.
22:50:12	*	yglukhov quit (Ping timeout: 248 seconds)
22:50:47	filwit	zahary makes all these features, but I don't think I've very seen him on the forums and only very rarely on #nim...
22:51:18	filwit	then again I don't exactly hang out here all too often myself, so maybe I've just missed him
22:52:05	Araq	well he made all these features and then left it to me to get them stable :P
22:52:36	Araq	not sure I like this division of work.
22:52:48	ldlework	I'm surprised methods are hard to support as a language feature
22:53:03	filwit	yeah i feel your pain, but the rest of us love concepts!
22:53:34	ldlework	a concept doesn't do the same thing
22:53:45	ldlework	I cannot recieve default implementations from a concept
22:53:45	filwit	i was responding to Araq
22:53:47	ldlework	oh
22:54:15	Araq	ldlework: well they are not hard to support if people think they are fine the way they are now.
22:54:37	ldlework	I would certainly not worry too much about them and I would document their pitfalls.
22:54:43	ldlework	The future is longer than the past, so to speak.
22:55:08	*	dashed joined #nim
22:55:58	Araq	but in an overly complex language I'm longing for things to remove ;-)
22:56:43	filwit	I accidentally do `Foo(x:-1)` sometimes.. which is a syntactical bug.. and I hate that it is. It's a very minor thing that I rarely run into, but it gets under my skin..
22:57:10	Araq	hmm? that's ugly, why do you do that?
22:57:48	filwit	i don't like putting spaces around the ':' in parameters? idk.. i think it groups things together better
22:58:00	Araq	not around.
22:58:02	filwit	but then I should just learn to get used to the other way to I don't accidentally do that
22:58:11	ldlework	filwit: just after
22:58:12	Araq	after the colon, like it's done in English: See?
22:58:55	filwit	yeah, but it groups things better when you've got lots of them.... (foo:123, bar:"234, a,b:2345)
22:59:29	Araq	or you use postfix unary minus: Foo(x:123.`-`)
22:59:59	filwit	lol, no haha I'll just occasionally put spaces when I need them, or learn to always do it
23:00:29	filwit	actually I tried to define a `:-` template (like we have a `..<`) but it doesn't work
23:00:55	Araq	colons cannot start an operator iirc
23:01:18	Araq	so we could support foo:-1 but still ... it's ugly.
23:01:59	filwit	oh, that must have been recent addtion cause I swear I remember making an example where you could use `x := ...` as a replacement for `var x = ...`
23:03:13	Araq	hmm true, := is actually in the test suite
23:03:28	Araq	never mind, I don't know Nim.
23:03:32	ldlework	hehe
23:03:39	ldlework	now he listens
23:09:08	ldlework	filwit: are you building a PoC for the "delegate composition" ?
23:09:22	ldlework	or "compositional delegate" I guess
23:09:32	filwit	PoC?
23:09:41	ldlework	proof of concept you said you could build it with macros
23:10:21	filwit	oh no, that's very easy though I could make you a gist in a couple minutes if you want (though I'm guessing you could do it too)
23:10:56	ldlework	I'm so burnt out writing macros for a few months :P
23:12:26	filwit	btw, I was looking at the log and noticed that I missed your comment before about how your ECS wasn't using continuous memory, and that such designs usually don't work well cause they're hard to manage, etc..
23:13:33	mat4	probably it would be better if the language is be splitted into implementation levels because of the every time increase of features. Otherwise I fear at some point the whole compiler get unmaintable (either because of compiler level feature support or excessive meta programming dependencies)
23:13:39	ldlework	Well, they are hard to create "front-end" abstractions for.
23:13:41	*	Dildosan quit (Quit: Leaving)
23:13:55	mat4	^is splitted
23:14:01	filwit	i just wanted to comment on that saying that's what this Maikelin guy from the forums and I where talking about the other day.. it's actually not too hard to group components into separate arrays and manage them if you have decent meta-programming
23:14:22	filwit	(don't think i said his name right)
23:14:43	ldlework	filwit: my entire ECS is generated from a macro, so that they are stored as tables is totally abstracted and underlying implementation detail right now
23:15:23	ldlework	I will switch over to arrays once I'm at a point where I'm noticing bottle neck in my game for sure.
23:15:27	filwit	yeah i was browsing your gist/github a little bit ago
23:15:59	ldlework	what did you think overall
23:16:35	filwit	i only glanced through your stuff, but overall the code looks good
23:16:59	ldlework	ah ok
23:17:02	filwit	i didn't pick up on everything that's going on, or what you where trying to accomplish in what i was reading through mostly, just browsing through things
23:17:19	ldlework	magic.nim basically generates all the code
23:17:27	ldlework	types are generated systematically
23:17:32	ldlework	procs are generated with parseStmt
23:17:41	ldlework	you define some component types
23:17:55	ldlework	and then you do `aggregate(NewTypeName, [Component1, Component2])
23:18:09	ldlework	this emits two new types, a NewTypeName and a NewTypeNameManager
23:18:14	filwit	ahh... magic.nim is one I didn't look at, thought that was going to be something else..
23:18:21	ldlework	hehe
23:18:50	*	mat4 quit (Quit: Verlassend)
23:18:53	filwit	i see
23:19:19	ldlework	NewTypeName is basically a struct of references to Component1, Component2, etc
23:19:19	filwit	btw, did you see the prototype ECS i made for the guy on the forums the other day?
23:19:38	ldlework	references to instances of those types which are stored in tables, keyed by entity id
23:19:47	ldlework	nope
23:19:50	filwit	it uses a similar concept to your aggregate thing, but stores them in separate arrays (instead of building types)
23:19:58	filwit	the syntax ends up being the same though
23:20:07	filwit	(not the same, similar)
23:20:19	ldlework	feel free to link me
23:20:20	filwit	er.. here one sec..
23:20:29	filwit	https://gist.github.com/PhilipWitte/c14a4913e2fbc3704643
23:21:16	filwit	don't worry about read the entire 'brim.nim' file, lol.. the macros are a bit too complex to just browse.. but you get an idea from the 'app.nim' file about the goal
23:22:40	filwit	basically the idea is that you have different "aggregate groups" (called componentGroup in the gist), and a "world" which is a collection of these... then some fancy macros which allow you to add any combination of components and it will place those into their matching group
23:23:25	filwit	then you can 'call' and procedure and it will pass every instance of each component in groups which match the proc's parameters
23:23:34	ldlework	ah cool
23:23:42	ldlework	I might just go ahead and change aggregate to an expression macro
23:23:54	ldlework	it comes off as 'lighter' in the callsite
23:24:02	ldlework	thanks
23:24:34	filwit	idk, aggregate is a pretty good name, really
23:24:42	filwit	er wait... i misread that
23:24:55	ldlework	type Entity = aggregate(Position, Velocity)
23:25:05	ldlework	looks much lighter than
23:25:14	ldlework	aggregate(Entity, [Position, Velocity])
23:25:40	filwit	ah yes, i agree completely... i was wondering exactly what 'aggregate' did (until you just told me).. but if I saw "type X = aggregate(..)" i would know implicitly
23:25:48	ldlework	exactly
23:26:01	ldlework	filwit: I like your thing. I don't quite agree with how your "systems" are exposed on the front-end but I could see how someone might.
23:26:42	ldlework	Oh well I guess I have the problem
23:26:49	ldlework	In that aggregate emits two types.
23:26:57	filwit	well this is an adaptation of some other (similar) ideas I've been playing with, and I used his terminology for this example (I don't call things this)
23:27:20	ldlework	filwit: I like the api, where systems have a reference to the manager and they can just say
23:27:27	ldlework	"give me all the entities with X, Y and Z components"
23:27:31	ldlework	Or any combination thereof
23:27:34	ldlework	And then do whatever
23:27:44	filwit	but the main goal of his project was very similar to mine.. ie, keep all the components for each entity inline with each other so iterating over them is as cache-efficient as possible
23:27:47	ldlework	Instead of having 'registered' systems, which are called and passed a specific list, etc
23:28:04	ldlework	you mean
23:28:14	ldlework	keeping all the component values, in homogenous arrays
23:28:22	ldlework	IE, all the positions in one array
23:28:26	ldlework	all the velocities in another array
23:28:54	ldlework	?
23:29:01	filwit	yes, but also keeping their counterpart component in order (per entity)
23:29:19	ldlework	I don't know what you mean by that last part
23:29:32	ldlework	so that in each array, Entity1's components are all first?
23:29:45	ldlework	IE keep the individual lists ordered by entity?
23:30:07	filwit	yeah.. if I'm understanding what you're asking..
23:30:17	ldlework	What's the advantage of doing that?
23:30:24	ldlework	keeping the component arrays sorted by entity
23:30:25	filwit	basically an "entity" is just and index inside a specific componentGroup
23:30:38	ldlework	what if not all entities have all the components
23:30:47	filwit	and each component doesn't need to store any entity reference at all (not even an ID)
23:31:21	filwit	that's why there's separate component groups
23:31:31	ldlework	so in your system, you cannot add and remove components
23:31:34	ldlework	to an entity
23:31:39	filwit	so one group has (Pos, Vel, string)... another (Pos, Foo), etc..
23:31:51	filwit	yes you can, but via copy
23:32:00	ldlework	But
23:32:07	ldlework	If you have 3 components
23:32:12	ldlework	that means you have to have 9 groups of those arrays
23:32:19	ldlework	for every possible combination of active componetns
23:32:43	ldlework	or more right
23:32:55	filwit	no, no.. each group just has an array for each component, it doesn't multiply the more you add to each one or anything
23:33:06	ldlework	No I'm saying
23:33:10	ldlework	If I wanted to in your system
23:33:44	ldlework	Start with an empty entity, then add a Pos, then remove a pos, then add a Vel then remove a Vel, then add a Name and remove a name, then add a Pos and Vel, then remove a Pos and Vel, then add a Pos and Name....
23:33:48	ldlework	and so on for every combination
23:33:55	ldlework	then I need to create a group for every possible combination
23:34:04	ldlework	meaning you have tons and tons of arrays representing all the possible groups
23:34:21	ldlework	It seems like in your system, you need to know up front, all the possible entity runtime-types.
23:34:41	ldlework	In my system you say, "Entitys can have A, B, C ... X, Y and Z components"
23:34:46	filwit	sure, but how often do you really want to do that? it's like static vs dynamic typing.. often there are specific patterns to an entities state
23:34:49	ldlework	And then you can create components of any kind.
23:34:56	ldlework	And you use JSON to define those novel types
23:35:14	ldlework	So that people who don't want to compile your code can contribute new entity types which change gameplay and so on through data alone.
23:35:29	ldlework	And gameplay mechanics, or even scripting can invent new ones on the fly.
23:35:45	filwit	you can still do that kind of thing, you just do it via a plugin system (DLL)
23:35:57	ldlework	I'm going with totally data driven.
23:36:48	ldlework	But I do see the point of yours. You can easily create a ShipType and a PowerUp type and so on by combining your components.
23:37:11	ldlework	They don't need to be defined at runtime, and therefore you can loop over all ships incredibly fast, all powerups really fast and so on.
23:37:36	ldlework	In my system, you kinda have to be querying component arrays a lot, unless I fully automate caching.
23:38:23	filwit	exactly... memory reads takes ~200 cycles on a x86_64 machine.. and cache reads in 64bytes at a time, so continous memory reads are important (benchmark it sometime and you'll see)
23:38:51	ldlework	I have no desire to worry about performance at all right now.
23:39:26	filwit	i understand that too, but actually I'm partially doing this to also make code easier to write... as odd as that sounds
23:39:29	ldlework	so many other abstractions to write
23:40:17	filwit	but there are some things that definitely get complicated to do with continuous memory (namely maintaining safe references)
23:41:05	ldlework	filwit: what kind of game do you eventually wnat to write
23:41:17	ldlework	also you should come hang out in #nim-gamedev
23:41:44	filwit	k i'll hang out there next time i get on (gonna head out soon)
23:42:13	*	derka joined #nim
23:42:43	filwit	idk exactly what kind of game I want to make.. I enjoy certain types of games a lot, but I'm wouldn't mind working on things outside of those
23:43:59	ldlework	like a open world wilderness survival roguelike with data-driven content so the world can be filled with millions of things that ca nbe broken down and recombined into different things with tools and crafting?
23:44:46	ldlework	My worldgen so far is totally data-driven too
23:44:52	filwit	I only really play a couple games, and much more rarely these days.. but one of my favorites (that I still play from time-to-time) is Skyrim
23:45:01	filwit	which is something very like what you described...
23:45:19	ldlework	filwit: sure, skyrim, but top-down tile-based and turn-based
23:45:35	filwit	how do you do turn-based + open-world?
23:45:46	ldlework	what do you mean?
23:46:09	filwit	okay nevermind... I was thining open-world == MMO.. my mistake
23:46:33	ldlework	think top-down 2D retro-tile-based graphics, turnbased minecraft with no mining.
23:47:18	*	yglukhov joined #nim
23:47:50	ldlework	just wilderness survival, flora, fuana, the elements, day-night, seasonal changes, tanning, boiling deer stomachs for waterskins, making salt from marsh waters, crafting bows, making layered clothes and armors
23:47:57	ldlework	that's what I want to start with anyway
23:48:14	filwit	sounds interesting
23:48:38	ldlework	filwit: you should play Cataclysm DDA
23:48:41	filwit	by "top down" you mean something like Zelda: A Link to the Past ?
23:48:45	ldlework	which is essentially what I'm describing
23:48:55	ldlework	But it has more gamesystems to support more items
23:49:08	ldlework	It has sprawling cities you can explroed jsut filled with endless stuff in the houses and stores and stuff
23:49:15	ldlework	everything can be broken down and built back up
23:49:54	ldlework	there's a vehicle system, a system for building an installing bionics into yourself, a whole building system, a system for simulating your immune system and the effects of disease and medicine, layered clothing and exposure system
23:50:16	filwit	this terminal game?
23:50:26	ldlework	it has an SDL version with graphical tiles too
23:51:03	ldlework	example of the map, http://staticdelivery.nexusmods.com/mods/411/images/1-0-1433569030.png
23:51:22	ldlework	example of gameplay, http://staticdelivery.nexusmods.com/mods/411/images/1-1-1393234669.png
23:51:36	*	yglukhov quit (Ping timeout: 245 seconds)
23:51:46	ldlework	http://www.cesspit.net/misc/catatile10e.gif
23:52:15	filwit	for some reason this reminds me of that old "Bolo" mac OS9 game I used to play as a kid
23:52:17	ldlework	there are other tilesets
23:52:26	ldlework	isometric, 32x32 full color, etc
23:52:30	ldlework	I just like the retrodays look
23:52:39	ldlework	I got the author to allow me to use the full tileset for my own game
23:52:42	ldlework	woot
23:53:10	ldlework	filwit: you should just join me and we should be this game
23:53:12	filwit	yeah Tile games are fun to make, it's a whole world in itself
23:53:30	ldlework	s/be/make
23:53:37	filwit	ldlework: well maybe, but I'm focused a few other things right now
23:54:02	ldlework	yeah sure, wait until I've implemented all the boilerplate I see how it is
23:54:14	filwit	lol
23:55:13	filwit	no but really, I'm just starting to look for new work, and I don't know what my schedule will be like + I want to continue my own project as well (it's more 3D OpenGL stuff)
23:55:46	filwit	but working with other's on a Nim game project does sound fun
23:56:25	filwit	it would be nice it we could start a Nim game jam or something based around a specific project like there (where many people could contribute)
23:56:38	filwit	like this*
23:57:38	filwit	what time-zone are you in, btw?
23:57:50	filwit	i'm in Pacific time
23:57:57	ldlework	same
23:58:01	filwit	okay cool
23:58:23	filwit	i used to be eastern, and that was a lot easier talking to #nim where most people are germany/uk
23:58:45	ldlework	yeah :(