| 00:40:39 | * | HakanD quit (Quit: Be back later ...) |
| 00:50:05 | * | fedons joined #nim |
| 01:19:42 | * | boop is now known as boopisaway |
| 01:46:15 | * | def- quit (Ping timeout: 240 seconds) |
| 01:47:39 | * | def- joined #nim |
| 01:52:35 | * | def- quit (Ping timeout: 246 seconds) |
| 01:57:09 | * | def- joined #nim |
| 02:02:28 | * | fedons_ joined #nim |
| 02:04:06 | * | fedons quit (Ping timeout: 256 seconds) |
| 02:06:36 | * | jaco60 quit (Ping timeout: 250 seconds) |
| 02:09:12 | * | def- quit (Ping timeout: 256 seconds) |
| 02:11:42 | * | HakanD joined #nim |
| 02:12:39 | * | def- joined #nim |
| 02:16:02 | * | HakanD quit (Ping timeout: 246 seconds) |
| 02:20:34 | * | jakesyl quit (Ping timeout: 245 seconds) |
| 02:34:15 | * | jakesyl joined #nim |
| 02:34:54 | * | fedons_ quit (Quit: This computer has gone to sleep) |
| 02:36:28 | * | fedons_ joined #nim |
| 02:38:35 | * | fedons_ quit (Client Quit) |
| 02:45:01 | * | fedons_ joined #nim |
| 02:53:43 | * | pregressive quit (Remote host closed the connection) |
| 03:09:20 | * | fedons joined #nim |
| 03:11:26 | * | fedons_ quit (Ping timeout: 240 seconds) |
| 03:12:25 | * | HakanD joined #nim |
| 03:13:02 | * | fedons quit (Client Quit) |
| 03:16:48 | * | HakanD quit (Ping timeout: 250 seconds) |
| 04:29:01 | * | vikaton joined #nim |
| 04:38:30 | * | darkf joined #nim |
| 05:11:58 | * | HakanD joined #nim |
| 05:16:56 | * | HakanD quit (Ping timeout: 272 seconds) |
| 06:43:21 | * | pregressive joined #nim |
| 06:47:39 | * | Demon_Fox quit (Quit: Leaving) |
| 07:19:21 | * | pregressive quit (Remote host closed the connection) |
| 07:55:28 | * | desophos quit (Read error: Connection reset by peer) |
| 08:44:12 | * | yglukhov joined #nim |
| 09:02:31 | * | HakanD joined #nim |
| 09:11:24 | * | HakanD_ joined #nim |
| 09:12:07 | * | yglukhov quit (Remote host closed the connection) |
| 09:13:17 | * | yglukhov joined #nim |
| 09:14:51 | * | HakanD quit (Ping timeout: 265 seconds) |
| 09:17:46 | * | yglukhov quit (Ping timeout: 250 seconds) |
| 09:19:12 | * | yglukhov joined #nim |
| 09:20:02 | * | pregressive joined #nim |
| 09:25:05 | * | pregressive quit (Ping timeout: 276 seconds) |
| 10:04:27 | * | fedons joined #nim |
| 10:15:50 | * | HakanD_ quit (Ping timeout: 260 seconds) |
| 10:16:17 | * | HakanD_ joined #nim |
| 10:16:30 | * | fedons quit (Read error: Connection reset by peer) |
| 10:30:15 | * | fedons joined #nim |
| 10:38:05 | * | vikaton quit (Quit: Connection closed for inactivity) |
| 10:38:32 | * | fedons quit (Quit: This computer has gone to sleep) |
| 10:45:52 | * | irrequietus joined #nim |
| 11:04:44 | * | HakanD_ quit (Ping timeout: 245 seconds) |
| 11:05:13 | * | HakanD_ joined #nim |
| 11:20:53 | * | pregressive joined #nim |
| 11:23:51 | * | HakanD_ quit (Quit: Be back later ...) |
| 11:25:59 | * | pregressive quit (Ping timeout: 264 seconds) |
| 11:30:33 | * | HakanD_ joined #nim |
| 11:34:07 | * | Trustable joined #nim |
| 12:13:13 | * | yglukhov quit (Remote host closed the connection) |
| 12:37:44 | * | gokr quit (Ping timeout: 272 seconds) |
| 12:40:31 | * | gokr joined #nim |
| 12:46:35 | * | xet7 quit (Ping timeout: 240 seconds) |
| 13:11:22 | dom96 | Happy new year guys! |
| 13:12:42 | * | yglukhov joined #nim |
| 13:14:32 | dom96 | hey yglukhov |
| 13:17:05 | * | yglukhov quit (Ping timeout: 255 seconds) |
| 13:21:36 | * | pregressive joined #nim |
| 13:22:21 | * | jaco60 joined #nim |
| 13:25:59 | * | pregressive quit (Ping timeout: 245 seconds) |
| 13:46:50 | * | krux02 joined #nim |
| 13:47:09 | krux02 | Happy new year |
| 14:16:27 | * | fedons joined #nim |
| 14:17:45 | * | fedons quit (Client Quit) |
| 14:18:19 | * | mto_ joined #nim |
| 14:20:59 | * | jakesyl quit (Ping timeout: 255 seconds) |
| 14:24:57 | * | HakanD_ quit (Quit: Be back later ...) |
| 14:29:34 | * | BlaXpirit quit (Quit: Bye) |
| 14:33:38 | * | gokr quit (Ping timeout: 272 seconds) |
| 14:33:46 | * | jakesyl joined #nim |
| 14:35:20 | * | gokr joined #nim |
| 14:35:39 | * | BlaXpirit joined #nim |
| 14:37:27 | nsf | I want to try nim for a hobby project of mine (a voxel game: http://www.youtube.com/watch?v=WGLDphpqf5M) and I would use it for the sake of concurrency primitives mostly (I'll write my own coroutines in a similar way async/await is implemented). However, the concern is the thread-local heap model, I would gladly use BoehmGC, but uncertain about its future. Will nim support some form of a shared heap model |
| 14:37:30 | nsf | forever? |
| 14:38:19 | nsf | Also if somebody tried something similar (multiplexing coroutines onto threads), I would love to take a look :) |
| 14:38:35 | nsf | At the moment I use F#/mono for that |
| 14:39:13 | nsf | I mean for coroutines in general |
| 14:40:03 | * | BlaXpirit_ joined #nim |
| 14:40:05 | * | strcmp1 quit (Ping timeout: 260 seconds) |
| 14:40:38 | * | BlaXpirit quit (Ping timeout: 260 seconds) |
| 14:40:55 | * | strcmp1 joined #nim |
| 14:43:15 | * | BlaXpirit_ is now known as BlaXpirit |
| 14:43:23 | * | BlaXpirit quit (Client Quit) |
| 14:43:47 | * | BlaXpirit joined #nim |
| 14:47:31 | * | BlaXpirit quit (Client Quit) |
| 14:50:35 | Araq_ | nsf: good questions. |
| 14:51:22 | * | gokr quit (Ping timeout: 256 seconds) |
| 14:51:35 | Araq_ | I currently favour passing coroutines per copy to some thread pool |
| 14:52:28 | * | gokr joined #nim |
| 14:52:34 | * | BlaXpirit joined #nim |
| 14:54:24 | nsf | Yes, I thought a bit about that. If it's possible to do what I want with thread-local model. Maybe as soon as coroutine begins to execute, tie it to a thread. But then you still need to pass data around. |
| 14:54:52 | nsf | One of the cases is when I launch 100 (or some other number) of coroutines and then wait for their completion collecting some data. |
| 14:54:56 | Araq_ | enriched with atomic reference counting or perhaps unique pointers. BoehmGC won't go away anytime soon though. |
| 14:55:29 | Araq_ | but I certainly don't see Boehm an important part of Nim's future, it's just too fragile, both in theory and in practice. |
| 14:55:31 | nsf | And since in many cases the data I'm working on comes from C++ world, so it's manually managed anyway. |
| 14:55:53 | nsf | Yeah, I understand that, that's why I asked about some form of shared heap model. |
| 14:56:20 | nsf | Be it boehm or some other GC or even some way to provide that via ref counting. |
| 14:56:25 | * | strcmp1 quit (Ping timeout: 260 seconds) |
| 14:56:44 | * | strcmp1 joined #nim |
| 14:56:56 | nsf | Oh, also I wanted to ask why doc says that channels are slow? |
| 14:57:27 | * | yglukhov joined #nim |
| 14:57:43 | nsf | Is it simply due to deep copying or there are some other reasons? |
| 15:00:12 | Araq_ | it also doesn't do any lockfree fancy stuff |
| 15:00:20 | nsf | that's fine |
| 15:01:10 | Araq_ | I benchmarked channels against Nim's spawn and the results were pretty much on par |
| 15:01:33 | Araq_ | which either means both implementations suck or that both are not that bad. |
| 15:03:59 | nsf | yeah, using thread-local model isn't trivial, for example waiting on coroutines is currently implemented via an atomic counter, each coroutine may have an atomic counter pointer and when it exits and the pointer is not nil it decrements itself, part of atomic counter is a coroutine pointer which waits on that counter |
| 15:04:22 | nsf | the coroutine which decrements it to zero puts the waiting coroutine into execution queue |
| 15:04:42 | nsf | and that part is not trivial, because waiting coroutine is already tied to a thread |
| 15:04:44 | nsf | hm. |
| 15:05:04 | nsf | I really have a strong desire to just go with boehm |
| 15:05:12 | Araq_ | for games I would simply exploit data parallelism everywhere |
| 15:05:22 | nsf | porting things from F#/mono world would be way simpler |
| 15:05:22 | Araq_ | and pretend there is no concurrency to take advantage of |
| 15:05:43 | Araq_ | but I'm not expert. |
| 15:05:44 | nsf | Araq_: sadly it doesn't just work, for some cases sure, but not for mine |
| 15:06:20 | Araq_ | how come? |
| 15:07:00 | nsf | it's a voxel game, a lot of things require communication and are not completely independent |
| 15:07:16 | nsf | there are things like light propagation which are quite heavy on communication |
| 15:07:27 | nsf | much easier to model with coroutines |
| 15:07:42 | nsf | I had a pure C++ implementation, it was a mess |
| 15:07:49 | Araq_ | sounds like a desaster for debugging. |
| 15:08:01 | nsf | yes, you just do it very carefully :) |
| 15:08:07 | nsf | and hope for the best |
| 15:09:12 | Araq_ | if you're heavy on communication, you're heavy on dependencies. and dependencies kill parallelism. |
| 15:09:25 | Araq_ | generally speaking. |
| 15:09:51 | nsf | yes, but I have to live with that somehow |
| 15:09:57 | nsf | that's where coroutines help |
| 15:13:11 | Araq_ | well, boehm GC is fine for now, go ahead and use it. |
| 15:13:24 | nsf | ok, I'll try it |
| 15:16:34 | Araq_ | do you get deterministic behaviour with your approach? |
| 15:16:41 | Araq_ | just curious. |
| 15:16:51 | nsf | uhm, what do you mean by deterministic? |
| 15:17:08 | nsf | does it run in given time frame or something else? |
| 15:17:20 | nsf | is it data race free? |
| 15:17:24 | Araq_ | can you multiplayer your game? |
| 15:17:33 | Araq_ | is it race free? |
| 15:17:39 | Araq_ | free of timing issues? |
| 15:18:00 | nsf | as for race free, I hope so, I don't actually run any simulations on coroutine system yet |
| 15:18:16 | nsf | physics in game is executed in a C++ thread via physx (which actually spawns its own thread) |
| 15:18:17 | Araq_ | does the same sequence of input events produce the same results pixel by pixel? |
| 15:18:58 | nsf | coroutines only produce data, it's just the data is rather complicated and requires multiple stages to build |
| 15:20:45 | Araq_ | so it's essentially: game loop iteration starts --> coroutines produce debugging hell --> big synchronization point --> game loop iteration ends ? |
| 15:21:16 | nsf | no, game loop currently interacts with coroutines via separate queue in a non-blocking fashion |
| 15:21:34 | nsf | coroutines produce data and push a "flip" notification via that queue |
| 15:21:45 | nsf | then at some random frame update happens |
| 15:22:01 | nsf | so, it's very undetermenistic in that sense |
| 15:22:19 | Araq_ | I see. Interesting. Anything I can read about this setup? |
| 15:22:23 | * | pregressive joined #nim |
| 15:23:09 | nsf | nothing that I know of, I haven't seen anybody doing that, it's not because what I do is unique or anything, just gamedev is a rather closed environment |
| 15:23:23 | nsf | you can see some of the info via confs like gdc and what not |
| 15:23:35 | nsf | I can give you one video link, by which my coroutine system is inspired |
| 15:24:07 | nsf | http://gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine |
| 15:24:09 | nsf | I think it's this one |
| 15:24:33 | nsf | but they use coroutines for a different reason |
| 15:24:57 | nsf | https://vimeo.com/102444836 |
| 15:25:47 | nsf | my game is a voxel one, it just build loads of geometry at runtime :) and to build optimal geometry I need to inspect neighbours of each voxel, so I have to break the job somehow into multiple CPUs also |
| 15:26:14 | nsf | http://i.imgur.com/hgGBcCX.png |
| 15:26:26 | nsf | oh and latest iteration also contains software fake light propagation system |
| 15:26:30 | nsf | another dependency hell |
| 15:26:35 | * | pregressive quit (Ping timeout: 240 seconds) |
| 15:27:32 | nsf | so for me coroutines just help to build the system that makes sense and to keep the complexity under control |
| 15:29:21 | nsf | player moves -> I need to update geometry around him -> geometry is updated via several means, first I need to get it via some source.. random generation or on disk -> then calculate the geometry itself, update physical representation -> then calculate light which is multiple stages of flood fill propagation -> then upload it all in such a way so that GPU keeps running at 60fps without visible glitches |
| 15:29:23 | nsf | etc. |
| 15:29:36 | nsf | https://gist.github.com/nsf/c8eeb0d1819ee469472d |
| 15:29:50 | nsf | I have some early prototypes snippets in F#, if you can read F# :) |
| 15:30:53 | * | jakesyl quit (Ping timeout: 265 seconds) |
| 15:31:33 | nsf | oh, math alone is rather painful |
| 15:31:37 | nsf | like I have multiple layers of things |
| 15:32:26 | nsf | map segments, which are geometry chunks uploaded to GPU, independently updated, then I have the storage system which is divided into storage chunks which are divided into chunk columns and finally chunks |
| 15:32:53 | nsf | need to move all that mess around somehow :) |
| 15:33:41 | nsf | and the data is not static, I mean usually you just precompute things, but it is live |
| 15:33:43 | nsf | you can change things |
| 15:34:15 | nsf | then you realize you end up having your little database implementation in there with read/write locks |
| 15:35:53 | nsf | anyways, will try nim for that all and let you know if it works :) |
| 15:36:51 | nsf | https://gist.github.com/nsf/c8eeb0d1819ee469472d#file-voxels-fs-L159-L168 |
| 15:37:00 | nsf | it's really much easier to write things like that via coroutines |
| 15:37:51 | nsf | try loading storage chunk (which is a potentially long I/O operation on its own) or generate one (generation can be broken into tens of coroutines and executed in parallel) and get it back |
| 15:38:08 | nsf | https://gist.github.com/nsf/c8eeb0d1819ee469472d#file-voxels-fs-L58-L64 |
| 15:38:22 | nsf | generation, just spawn a 3d array of coroutines and wait for their completion |
| 15:38:30 | nsf | was a real mess in C++ :) |
| 15:40:08 | nsf | and well I mention that database thing, if a coroutine wants to read a chunk of voxels, it may have to wait while writing coroutine does something |
| 15:41:27 | nsf | with first class coroutines you just pause it and put it into a list, no need to invent any sort of weird control flow |
| 15:41:35 | nsf | mentioned* |
| 16:01:48 | * | yglukhov quit (Remote host closed the connection) |
| 16:02:23 | * | yglukhov joined #nim |
| 16:07:00 | * | yglukhov quit (Ping timeout: 260 seconds) |
| 16:10:29 | * | allan0_ joined #nim |
| 16:11:18 | Araq_ | nsf: ok, great. also chekc out -d:nimCoroutines |
| 16:11:55 | * | allan0 quit (Ping timeout: 240 seconds) |
| 16:12:35 | nsf | I've seen implementation (I think), it's a stack switching one, I'm not a big fan of those, because my game also calls C++ code a lot, so you kind of picky about stack sizes and stackless coroutines are very compact |
| 16:12:48 | nsf | so, not sure, for some reason I always avoided those |
| 16:12:55 | nsf | maybe I shouldn't |
| 16:14:06 | nsf | https://github.com/nim-lang/Nim/blob/devel/lib/pure/coro.nim#L18 |
| 16:14:10 | nsf | 512K, hm |
| 16:14:31 | nsf | so you see it's not small, you make a 100 coroutines and that's 50M |
| 16:15:33 | * | yglukhov joined #nim |
| 16:17:58 | Araq_ | I agree. |
| 16:18:16 | * | lenstr joined #nim |
| 16:21:49 | * | gokr quit (Read error: Connection reset by peer) |
| 16:35:12 | * | johnsoft is now known as whatisaphone |
| 16:37:42 | * | whatisaphone is now known as johnsoft |
| 17:23:08 | * | pregressive joined #nim |
| 17:27:46 | * | pregressive quit (Ping timeout: 256 seconds) |
| 17:49:37 | * | pregressive joined #nim |
| 17:50:53 | * | fedons joined #nim |
| 17:55:33 | * | KevinRoss joined #nim |
| 17:56:20 | KevinRoss | Is Nim faster than C++? |
| 17:59:40 | mto_ | its on the same level in my experience |
| 18:03:59 | KevinRoss | Why Nim is not popular? Is community lacking of motivation to promote/advertise the Nim? |
| 18:05:11 | mto_ | doesn't have inertia like C++ or corporate backing like Go/Rust would be my guess |
| 18:07:25 | * | Matthias247 joined #nim |
| 18:11:01 | KevinRoss | I see the docs, I don't like the camel case. |
| 18:12:32 | * | BitPuffin|osx quit (Ping timeout: 256 seconds) |
| 18:14:30 | krux02 | KevinRoss: nim is unstable meaning it still has breaking changes from time to time, companies don't like that. |
| 18:15:18 | nsf | nobody likes it, but what can you do :) |
| 18:15:38 | * | BitPuffin|osx joined #nim |
| 18:15:44 | krux02 | KevinRoss: nim is what they call style insensitive, it ignores the case of letters and any underscore or dash, so you can use that instead of camel case |
| 18:17:47 | KevinRoss | krux02: what do you mean? ignoring function/method name case? |
| 18:17:54 | krux02 | KevinRoss: to ask if nim is faster than c++ is not really productive, nim compiles to C and nim has for most constructs of C code equivalent constructs |
| 18:18:38 | krux02 | fooBar is the same as foo_Bar or foo_bar |
| 18:18:54 | nsf | KevinRoss: http://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality |
| 18:19:34 | krux02 | you are allowed to like that, but you don't need to |
| 18:19:58 | * | fedons_ joined #nim |
| 18:23:32 | * | fedons quit (Ping timeout: 272 seconds) |
| 18:36:37 | * | darkf quit (Quit: Leaving) |
| 18:39:49 | * | KevinRoss quit (Quit: Page closed) |
| 18:49:37 | * | fedons_ quit (Quit: This computer has gone to sleep) |
| 19:00:49 | * | xet7 joined #nim |
| 19:04:41 | * | xet7 quit (Client Quit) |
| 19:09:09 | * | xet7 joined #nim |
| 19:14:35 | * | vikaton joined #nim |
| 19:54:08 | krux02 | Araq_: I made an issue about a new getType behavior, and I would like to get your opinion about it: https://github.com/nim-lang/Nim/issues/3681 |
| 19:57:03 | * | strcmp1 quit (Quit: return 0;) |
| 20:02:01 | Araq_ | krux02: I don't really care. You're free to make it as consistent as you like iff there is a clear way of how to update one's code. |
| 20:02:13 | * | strcmp1 joined #nim |
| 20:02:19 | Araq_ | and no silent change in behaviour is introduced. |
| 20:02:38 | Araq_ | I prefer to discuss more details when reviewing your PR. |
| 20:03:50 | krux02 | ok, I also don't like silent behavior, but since it is your language, I do not like to work on something and in the end you say you don't like it, or I realize that it doesn't work out as I expect it to work out, because I haven't seen all the use cases |
| 20:04:13 | Araq_ | fair point, but I already told you the ideas in getType(). |
| 20:04:36 | krux02 | yes, but I am not sure if I really got them right |
| 20:04:55 | Araq_ | well you will understand much more when fighting with the implementation. |
| 20:05:06 | krux02 | I see |
| 20:06:10 | Araq_ | and getType() surely is a crucial feature that will affect how serialization libraries etc are designed. |
| 20:06:27 | * | Demon_Fox joined #nim |
| 20:07:02 | krux02 | yes I need getType, because I am writing a binding between opengl glsl and nim, and I need to be able to operate on types |
| 20:07:10 | Araq_ | but I think you should play with its implementation now. |
| 20:07:18 | * | strcmp1 quit (Quit: WeeChat 1.3) |
| 20:08:23 | krux02 | I put some thoughts into recursive types now |
| 20:08:31 | Araq_ | tinker with it and see what works for your use case. |
| 20:09:55 | Araq_ | I can merge yglukhov's PR in the meantime. |
| 20:10:08 | krux02 | I have seen, that runtime type information has a different interface to the types than macros |
| 20:10:58 | Araq_ | do |
| 20:10:59 | Araq_ | not |
| 20:11:02 | Araq_ | touch |
| 20:11:05 | Araq_ | RTTI. |
| 20:11:13 | krux02 | ok |
| 20:11:18 | krux02 | understand |
| 20:15:38 | * | strcmp1 joined #nim |
| 20:15:55 | krux02 | I will now dig a bit in the nim compiler code, but I can't guarantee that I will be successful. |
| 20:18:14 | yglukhov | krux02: what can you say about nimsl? don't you want to take it as a start? |
| 20:18:35 | yglukhov | Araq, thanks for merge. My variant is now complete =) |
| 20:20:03 | krux02 | yglukhov. I really like nimsl and yes you are right, I should look into it. |
| 20:21:12 | yglukhov | krux02: i'd be glad to have some feedback and/or prs ;) |
| 20:22:19 | krux02 | yglukhov: yea I do like it, and I think sooner or later I will integrate it in my project. |
| 20:22:40 | yglukhov | thats great! whats your project btw? =) |
| 20:23:02 | * | desophos joined #nim |
| 20:23:44 | krux02 | yglukhov: https://github.com/krux02/opengl-sandbox |
| 20:24:19 | yglukhov | btw, guys, if someone cares. docker yglukhov/devel image is now able to run headless nimx ui autotests on travis! yay! =) |
| 20:24:53 | * | HakanD_ joined #nim |
| 20:25:38 | krux02 | yglukhov: I am not trying to write glsl in nim, but I am trying to get rid of almost all error prone opengl boilerplate code |
| 20:26:52 | krux02 | yglukhov: With your project I only disgaree in one point, I think a proc doesn't map very well to a shader stage. |
| 20:28:19 | krux02 | yglukhov: But having a proc, that is also a callable function in my glsl code, is extremely useful. |
| 20:28:25 | yglukhov | krux02: oh nice. may i also suggest to have a look at nimx (ui lib powered by gl, compiles to all targets including javascript), and rod (scne-graph engine) |
| 20:29:54 | yglukhov | regarding the procs, you may be right. we've implemented an ubershader in rod, which is currently glsl, and we'll try to port it to nimsl soonish. so we'll see how it goes out =) |
| 20:31:58 | krux02 | is nimx creating a gui that can contain an opengl context, or can I render the nimx ui into a texture, that I can render inside of the game engine in for example a computer screen in the game? |
| 20:34:50 | Araq_ | yglukhov: what is the state of your font renderer? |
| 20:35:30 | Araq_ | I'd like to integrate it into nimedit cause SDL's font rendering sucks |
| 20:35:32 | yglukhov | nimx is tied on opengl pretty tightly currently. so you can (use nimx's glcontext and perform your gl drawing right inside in nimx subview | render nimx's views to the currently bound framebuffer or use nimxs Image API to render to texture) |
| 20:36:26 | yglukhov | Araq: havent started yet, sorry. if thats a blocker for you, ill try to raise its priority ;) |
| 20:37:11 | Araq_ | well no worries, I use nimedit already anyway |
| 20:37:12 | yglukhov | do you want to switch away from immode? |
| 20:37:19 | Araq_ | no. |
| 20:37:28 | yglukhov | ok |
| 20:37:29 | Araq_ | not if I can avoid it. I love immode. |
| 20:40:08 | * | saml_ joined #nim |
| 20:40:41 | krux02 | yglukhov: rendering the ui on a projected texture is only useful, if I can project the mouse events, too. That means that I would need to be able to process/modify each mouse event etc before the ui sees them. |
| 20:42:11 | yglukhov | krux02: true. i'm gonna do a ui component in rod this week. the component will be able to attach a nimx view to the node, with proper event forwarding, etc. but im not sure if that will help you, since youve got your own engine ;) |
| 20:42:52 | yglukhov | btw how mature your engine is? |
| 20:42:55 | krux02 | just that you know, I am not planning to use any ui engine an the future at all. |
| 20:43:31 | * | nchambers joined #nim |
| 20:43:38 | krux02 | I realized that for games all I need for ingame ui is a list of buttons each with it's own event mothod |
| 20:44:27 | krux02 | sliders check boxes moveable windows all not necessary for me |
| 20:45:01 | krux02 | and for a clickable "start game" button, I do not need a ui library |
| 20:45:58 | krux02 | the highest complexity in menues I ever needed were sub menus with a generic back button |
| 20:46:57 | yglukhov | ok, but nimx is not only about ui, it also has windows, gl context, animations, fonts (sdf fonts coming soon), and it is capable to compile to android, ios, windows, linux, mac, and webgl. and nim is perfect for its dead code elimination. using a "big" dependency in nimble basically costs nothing. |
| 20:47:34 | yglukhov | also we're planning to get away from sdl. nimx currrenlty depends on sdl |
| 20:47:46 | yglukhov | but pretty loosely =) |
| 20:48:03 | krux02 | don't misunderstand me, but aren't you just cloning sdl? |
| 20:48:42 | yglukhov | not yet, because im using it ;) |
| 20:48:45 | krux02 | sdl dosn't have ui or animations, but the rest is there and widely tested |
| 20:50:06 | yglukhov | the problem with sdl is its not nim. that means, its a pita to create portable buildable product with it. |
| 20:50:24 | * | jakesyl joined #nim |
| 20:51:10 | krux02 | I like sdl2, and to get me moved to something different, someone needs to point me to a fundamental design error in sdl as the reason, why it can't be just another sdl extension. |
| 20:51:22 | krux02 | I am pretty conservative about thet |
| 20:52:29 | krux02 | yes you are right sdl2 is not nim, but you can't write an sdl replacement without native code |
| 20:52:59 | yglukhov | but nim IS native code =) |
| 20:55:55 | krux02 | can you tell me in which situation sdl2 does not work out? |
| 20:56:00 | yglukhov | js? |
| 20:57:38 | yglukhov | i didnt say it doesnt work out. horses work out, but we use cars, right? ;) |
| 20:58:21 | krux02 | good point, but for me js is horses |
| 20:59:14 | yglukhov | exaclty! so why not use nim instead of js? and deploy nim code as web apps? =) |
| 21:00:02 | krux02 | What do you think about compile nim code to c, and deploy as nacl? |
| 21:01:08 | krux02 | nacl works today, tomorrow there will be WebAssembly. |
| 21:01:34 | krux02 | just circumvent js altogether |
| 21:02:29 | yglukhov | but its only chrome, no? |
| 21:03:41 | krux02 | nacl yes, webassembly is the same idea, but it is browsers cooperating |
| 21:03:43 | yglukhov | and webasm is definitely interesting, but not there yet |
| 21:03:54 | krux02 | Yes it is not there yet |
| 21:04:43 | krux02 | but if it releases, it makes your project pretty much obsolete. |
| 21:05:32 | yglukhov | really? why? |
| 21:06:03 | krux02 | All the work you put into it to make it work on javascript just to find out in the end, that compiling to webassembly is better. |
| 21:06:57 | krux02 | Ok WebAssembly can fail, or take way too long to finish |
| 21:07:49 | yglukhov | well i dont put that much work into js tbh. nim mostly does a good job. there is like less that 0.5% js-specific code in our js-compatible projects =) |
| 21:07:56 | krux02 | I know that sdl2 works on nacl, and I am pretty sure that if WebAssembly progresses it will work there, too. |
| 21:08:53 | krux02 | It's your decision if you want to clone sdl2 to be able to compile to js. |
| 21:09:38 | yglukhov | well, i don't want to beat sdl. it's just my observation from my experience, that c dependencies are hard to deal with when going cross-platform. and its not like they are hard in nim. they are hard in c as well =) |
| 21:11:32 | krux02 | SDL ist not only c, it also has some objective C (mac) and other stuff depending onthe platform |
| 21:12:07 | yglukhov | are you an sdl2 author by any chance? ;) |
| 21:12:19 | krux02 | and it as a backend for the closed console systems where I don't have a dev kit |
| 21:12:28 | krux02 | nope not by any chance |
| 21:13:04 | krux02 | I am just very opinionated about certain things |
| 21:13:28 | yglukhov | yeah, just like me! :D |
| 21:13:56 | krux02 | I am also very opinionated about the fact that basically every new game engine is written is written in c++ enen though c++ sucks at it |
| 21:14:59 | yglukhov | there was no option up until recently |
| 21:15:53 | krux02 | I am just saying it, because that's the reason I tried out nim. |
| 21:17:14 | krux02 | what languages have you worked with in games/engines/rendering-stuff |
| 21:17:25 | yglukhov | have you tried d and rust already? |
| 21:18:02 | krux02 | I took a very short peek into rust, and my shading sdl I wanted to do in rust, but sadly the rust macros suck |
| 21:18:08 | krux02 | they are just not there yet |
| 21:19:25 | yglukhov | games/engines/rendering-stuff - c++. like you said, there's pretty much nothing except c++. but other than games, i've tried and used different languages |
| 21:21:39 | krux02 | https://github.com/rust-lang/rust/blob/c4b16384f101bbe28dc4eec0651a61cb9d5274ac/src/libstd/macros.rs |
| 21:21:49 | krux02 | look at the implementation of println |
| 21:21:55 | krux02 | it forwards to print |
| 21:22:13 | krux02 | that forwards to format_args |
| 21:22:20 | krux02 | and then the implementation of format_args |
| 21:22:51 | krux02 | that's the reason I decided not to look further |
| 21:23:21 | krux02 | D seems to be pretty solid at this point in time, but there is something missing in D that really makes it more powerful than c++ |
| 21:24:34 | krux02 | I haven't worked with D, but I couldn't find anything in D where I would have said, yes that's something cool, and worth checkout out the language. |
| 21:24:53 | krux02 | But I did try out Go and Scala |
| 21:25:10 | krux02 | Scala is just awesome, there is so much done right in that language. |
| 21:26:20 | krux02 | But slow compilation and the inability to have a type like the c++ std::vector<MyStruct> made me look further. |
| 21:27:11 | krux02 | additionally dealing with the java class loader and bindings to C were really a pain. |
| 21:28:07 | krux02 | I don't know why I tried Go, probably because of it's simplicity, and unlike scala, it had value typed arrays |
| 21:28:40 | krux02 | But it's too much like C, so now I am in the nimworld |
| 21:29:42 | * | vendethiel joined #nim |
| 21:30:42 | yglukhov | well i guess you should enjoy it =) |
| 21:37:29 | * | bigfondue quit (Ping timeout: 255 seconds) |
| 21:39:00 | krux02 | if there weren't the nasty bugs, then yes I would |
| 21:41:55 | krux02 | yay I have code where the existence of a completely unused proc changes the behavior |
| 21:43:01 | yglukhov | cool! file a bug =) |
| 21:54:59 | * | bigfondue joined #nim |
| 22:00:40 | Araq_ | "Objects have a type header and therefore are not suitable to represent a C-struct, you need a tuple to do that." no. |
| 22:01:01 | Araq_ | objects only have a header when you inherit from RootObj or similar |
| 22:02:06 | * | mto_ quit (Ping timeout: 260 seconds) |
| 22:05:36 | * | mto_ joined #nim |
| 22:11:06 | * | bigfondue quit (Ping timeout: 256 seconds) |
| 22:14:36 | * | bigfondue joined #nim |
| 22:15:39 | krux02 | Araq_: oh, ok I guess I have to reread the documentation then |
| 22:17:53 | * | yglukhov quit (Remote host closed the connection) |
| 22:18:30 | krux02 | Araq_: the documentation clearly says: Objects have access to their type at runtime, so that the of operator can be used to determine the object's type |
| 22:18:55 | * | yglukhov joined #nim |
| 22:18:59 | krux02 | Araq_: it is in http://nim-lang.org/docs/manual.html#types-tuples-and-object-types |
| 22:19:18 | * | Lea2 is now known as Learath2 |
| 22:20:16 | Araq_ | ok, that's wrong or at least misleading |
| 22:20:24 | krux02 | Araq_: this tells me that any object has at least one id of some form stored somewhere (beginning) in the object, so that the of operator can work |
| 22:21:06 | * | saml_ quit (Remote host closed the connection) |
| 22:24:50 | * | yglukhov quit (Ping timeout: 272 seconds) |
| 22:24:55 | Araq_ | the of operator doesn't need to work where there is no inheritance allowed anyway |
| 22:26:35 | * | vendethiel quit (Read error: Connection reset by peer) |
| 22:26:45 | * | vendethiel joined #nim |
| 22:31:53 | * | HakanD_ quit (Quit: Be back later ...) |
| 22:33:54 | * | HakanD_ joined #nim |
| 22:34:02 | krux02 | Araq_: yes but object allows inheritance. |
| 22:35:08 | krux02 | the documentation doesn't say anything about object type declarations leaving out the base class |
| 22:35:59 | krux02 | so I just assumend that it would work like in java, where the base class has a default value when left out |
| 22:37:08 | krux02 | in Java it is Object and in nim it is RootObj |
| 22:37:08 | * | HakanD_ quit (Client Quit) |
| 22:38:48 | Araq_ | well, it doesn't work that way in Nim. |
| 22:40:05 | krux02 | then sorry for misinforming other people, |
| 22:41:34 | krux02 | But then there are some question open, what can an object do, that doesn't inherit anything over a tuple type, and can I inherit from it? |
| 22:43:57 | krux02 | never mind |
| 22:44:01 | krux02 | I tried it out |
| 22:54:09 | krux02 | Araq_: I cant find the implementation of macros.getType, it states some magic: NGetType, but searching that word doesn't reveal anything in the git repository |
| 23:02:39 | Araq_ | grep deeper. |
| 23:02:56 | Araq_ | also the PR that I just merged shows where it's implemented |
| 23:05:32 | * | Trustable quit (Quit: Leaving) |
| 23:14:54 | * | pregressive quit (Remote host closed the connection) |
| 23:15:28 | * | pregressive joined #nim |
| 23:20:19 | * | pregressive quit (Ping timeout: 276 seconds) |
| 23:38:05 | * | vikaton quit (Quit: Connection closed for inactivity) |
| 23:56:05 | * | k1io- joined #nim |
| 23:58:00 | * | jaco_ joined #nim |
| 23:58:01 | * | zxtx_ joined #nim |
| 23:59:19 | * | OmIkRoNiXz joined #nim |
