00:01:40 | * | TheManiac quit (Ping timeout: 245 seconds) |
00:01:40 | * | erwana[m] quit (Ping timeout: 245 seconds) |
00:02:05 | * | euantor quit (Ping timeout: 245 seconds) |
00:02:30 | * | MightyJoe quit (Ping timeout: 245 seconds) |
00:02:30 | * | jivank[m] quit (Ping timeout: 245 seconds) |
00:03:14 | * | erwana[m] joined #nim |
00:03:14 | * | TheManiac joined #nim |
00:03:50 | * | euantor joined #nim |
00:05:20 | * | cyraxjoe joined #nim |
00:12:57 | * | jivank[m] joined #nim |
00:13:45 | * | FromGitter quit (Ping timeout: 240 seconds) |
00:20:54 | * | Matthias247 quit (Read error: Connection reset by peer) |
00:22:14 | * | rauss joined #nim |
00:22:26 | libman | Picking up from last night: the problem of some pages on the Nim web-site (ref https://archive.is/uJfZG#selection-1257.15-1257.37 ), setting User-Agent request header same as my Chromium makes no difference. |
00:26:19 | libman | Also, I thought I observed this 404 problem affecting all pages on the site, but I could have been mistaken. At present it doesn't seem to affect the main site (ex `curl -I https://nim-lang.org/question.html` => "HTTP/1.1 200 OK") |
00:27:24 | * | FromGitter joined #nim |
00:28:16 | libman | But any page on any subdomain I tried (forum, irclogs, any others?) returns "HTTP/1.1 404 Not Found" |
00:31:08 | ftsf_ | libman, seems to be a problem with HEAD requests |
00:36:10 | libman | I don't mean to annoy anybody with this, but some crawlers (ex archive.org) can't access those anymore... |
00:37:05 | libman | So this isn't about figuring out what headers to add to curl to get it working on my end. |
00:51:24 | zachcarter | alright the first tutorial is done - https://gist.github.com/zacharycarter/846869eb3423e20af04dea226b65c18f |
00:51:55 | zachcarter | for osx anyway |
00:52:08 | zachcarter | I still need linux / windows build instructions but I’ll work on those this weekend when I have access to more machines |
00:52:48 | zachcarter | feedback more than welcome :) |
00:54:38 | * | xet7 quit (Quit: Leaving) |
01:11:48 | * | Vladar quit (Quit: Leaving) |
01:20:27 | * | def-pri-pub joined #nim |
01:54:05 | * | brson joined #nim |
02:30:03 | * | brson quit (Quit: leaving) |
02:30:50 | * | chemist69 quit (Disconnected by services) |
02:30:55 | * | chemist69_ joined #nim |
02:43:43 | zachcarter | http://imgur.com/a/evOIC |
02:57:32 | rauss | zachcarter: Looks great- |
02:57:35 | rauss | ! |
02:57:40 | zachcarter | thank you! |
02:58:18 | rauss | I will probably use your nuklear stuff once I get there in my game engine |
02:58:28 | zachcarter | awesome :) |
02:58:29 | rauss | and will start helping at that point where I can |
02:58:56 | zachcarter | I’m working on a 2d game framework myself |
02:59:10 | rauss | Mine is a framework as well |
02:59:21 | zachcarter | ah cool, what are you using for rendering? |
02:59:26 | rauss | a la LÖVE |
02:59:41 | rauss | currently sdl2, but only because I can't use bgfx on linux yet |
02:59:59 | zachcarter | gotcha, yeah bgfx is nice that’s what I’m using atm |
03:00:09 | zachcarter | what’s the hangup on linux with bgfx? |
03:00:11 | rauss | https://github.com/Halsys/nim-bgfx/issues/2#issuecomment-280234794 |
03:00:24 | rauss | Rather, |
03:00:47 | rauss | I can use bgfx with glfw currently (and will probably do that), but not sdl2+bgfx |
03:00:57 | zachcarter | ah okay yeah I’m using glfw |
03:02:25 | zachcarter | I was using SDL2 but I ditched it, it seemed to be taking over a lot of my application when all I really wanted it for was windowing |
03:02:38 | zachcarter | not necessarily taking over, but crepeing into |
03:02:42 | zachcarter | creeping* |
03:03:46 | rauss | What are you using for controls? |
03:04:46 | zachcarter | I haven’t really touched input yet to be honest |
03:04:57 | rauss | Ah. I'm using SDL2 for that |
03:05:07 | zachcarter | everything works through callbacks in GLFW |
03:05:16 | zachcarter | so when a key is pressed a C callback is fired which I can hook into |
03:05:46 | zachcarter | rather trivially |
03:05:54 | zachcarter | just need to define a proc with a cdecl pragma |
03:06:39 | zachcarter | I just haven’t gotten around to actually coding any games, right now I’m working on tooling - I figure any 2d game library / framework is going to need some way to create texture atlases and then render them |
03:06:49 | zachcarter | I can already render textures and regions of textures, so texture atlases are next |
03:07:40 | zachcarter | I’ve written a sprite batch class which submits draw calls in batches to BGFX, I haven’t done any sorting yet which apparently you handle with views in BGFX, so I’ll eventually get to that once I actually start making my game |
03:11:21 | rauss | I should really prioritize switching to bgfx before doing any more in my drawing module... =\ doesn't make sense to implement everything in SDL2 since I plan on using bgfx ultimately. I've just been lazy I guess. |
03:11:59 | zachcarter | well I can tell you the SDL2 renderer is quite a bit higher level compared to BGFX |
03:12:30 | zachcarter | here’s some sample code from my sprite batch / texture stuff - |
03:13:14 | zachcarter | https://gist.github.com/zacharycarter/f13d61268971dfe385c7663bb74b7ece |
03:14:19 | zachcarter | just be prepared for some linear algebra and submitting draw calls to buffers etc |
03:14:30 | zachcarter | it’s not as simple as SDL draw rect and stuff |
03:14:46 | zachcarter | not sure if you’ve used a drawing API like OpenGL / DirectX before |
03:14:57 | zachcarter | with shaders etc |
03:15:12 | * | zaquest joined #nim |
03:23:54 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
03:48:23 | * | zaquest quit (Quit: Leaving) |
03:51:49 | zachcarter | these nuklear bindings definitely need an abstraction layer now that I’ve used them a bit |
03:52:04 | * | zaquest joined #nim |
03:52:16 | zachcarter | I think I understand enough to write one |
03:52:25 | zachcarter | once I finish this texture packer thing I will |
04:00:24 | rauss | Yeah I'm no stranger to OpenGL and linear algebra :) |
04:01:31 | zachcarter | good :) |
04:02:04 | zachcarter | a few tips - if you’re doing 2d look into transient vertex and index buffers |
04:02:31 | zachcarter | you’ll want to use those whenever you don’t need draw state to persist across frames |
04:02:47 | zachcarter | I use them for my sprite batch as well as in my bgfx nuklear backend |
04:03:07 | zachcarter | the bgfx nuklear backend was quite the pain to write |
04:03:17 | zachcarter | even with an example C++ / SDL one |
04:03:20 | rauss | You mean fun! |
04:03:24 | zachcarter | right! |
04:03:38 | zachcarter | You can definitely have mine |
04:03:46 | zachcarter | when you get to that point |
04:03:55 | rauss | Thanks man. This looks great |
04:04:12 | rauss | Nice job |
04:04:12 | zachcarter | there are a few quirks I need to explain with its use though - mostly due to shortcomings with the nuklear API |
04:04:15 | zachcarter | thank you |
04:19:05 | * | zachcarter_ joined #nim |
04:20:28 | * | zachcarter quit (Ping timeout: 240 seconds) |
04:20:28 | * | zachcarter_ is now known as zachcarter |
04:48:10 | * | Nobabs27 quit (Quit: Leaving) |
05:12:58 | * | arnetheduck joined #nim |
05:35:18 | * | yglukhov joined #nim |
05:36:13 | * | def-pri-pub quit (Quit: leaving) |
05:37:34 | * | yglukhov quit (Remote host closed the connection) |
06:30:55 | * | libman quit (Quit: Connection closed for inactivity) |
06:31:24 | * | nsf joined #nim |
06:33:25 | * | chemist69_ quit (Ping timeout: 240 seconds) |
06:56:29 | * | butchster quit (Ping timeout: 255 seconds) |
07:04:30 | * | chemist69 joined #nim |
07:04:46 | * | rauss quit (Quit: WeeChat 1.7) |
07:19:28 | * | bjz joined #nim |
07:32:00 | * | djellemah quit (Read error: Connection reset by peer) |
07:37:16 | * | yglukhov joined #nim |
07:37:27 | * | yglukhov quit (Remote host closed the connection) |
07:37:41 | * | yglukhov joined #nim |
07:43:50 | * | djellemah joined #nim |
07:56:44 | * | zachcarter quit (Quit: zachcarter) |
08:14:47 | * | Vladar joined #nim |
08:14:47 | * | ofelas quit (Read error: Connection reset by peer) |
08:15:14 | * | rokups joined #nim |
08:15:16 | * | ofelas joined #nim |
08:41:40 | * | Andris_zbx joined #nim |
08:51:08 | yglukhov | Araq: hi, there's a regression resulting in c compile error because of bad identifiers in a c struct. e.g. NimStringDesc* 555013; |
09:09:44 | * | TheManiac quit (Remote host closed the connection) |
09:09:44 | * | M-Quora quit (Remote host closed the connection) |
09:09:45 | * | jivank[m] quit (Remote host closed the connection) |
09:09:45 | * | hohlerde quit (Read error: Connection reset by peer) |
09:09:45 | * | Jipok[m] quit (Read error: Connection reset by peer) |
09:09:46 | * | MrAxilus[m] quit (Remote host closed the connection) |
09:09:46 | * | Guest73656[m] quit (Read error: Connection reset by peer) |
09:09:46 | * | dyce[m] quit (Write error: Connection reset by peer) |
09:09:46 | * | stisa quit (Read error: Connection reset by peer) |
09:09:46 | * | erwana[m] quit (Read error: Connection reset by peer) |
09:09:47 | * | ehmry quit (Write error: Connection reset by peer) |
09:15:09 | * | flyx quit (Quit: ZNC - http://znc.in) |
09:19:34 | * | flyx joined #nim |
09:22:51 | * | Learath2 quit (Quit: WeeChat 1.4) |
09:30:14 | * | couven92 joined #nim |
09:45:25 | * | shashlick quit (Ping timeout: 240 seconds) |
09:58:13 | * | shashlick joined #nim |
10:33:19 | * | dyce[m] joined #nim |
10:36:00 | cheatfate | rokups, ping |
10:36:07 | rokups | pong |
10:36:37 | cheatfate | rokups, i found a problem in coroutines |
10:36:52 | rokups | im all ears |
10:36:54 | cheatfate | this is theoretical problem |
10:37:36 | cheatfate | there functions like `alive` which using `proc` as identifier |
10:38:10 | cheatfate | with such approach its not possible to start like N coroutines which have same procedure |
10:38:30 | cheatfate | its possible to start but not possible to check if some of them are alive |
10:38:44 | cheatfate | because `proc` will be same for all coroutines |
10:39:34 | cheatfate | what do you think? |
10:39:43 | rokups | damn. this is not theoretical but very much practical. i think only idiot could write that code ;) |
10:40:51 | rokups | fix could be start() returning some coroutine identifier and we could wait on that |
10:41:05 | cheatfate | yep |
10:41:19 | cheatfate | i think stack address will be nice identifier |
10:41:40 | cheatfate | or Coroutine object address |
10:41:59 | cheatfate | or maybe its better to return Coroutine object itself |
10:42:33 | cheatfate | and make some fields of the Coroutine object as `public` |
10:43:20 | cheatfate | i think it would be nice to have access to `state` field of Coroutine object. |
10:43:38 | rokups | there was some talk about coroutines running on different threads. if someone set out to implement that returing coroutine object would be obstacle for them since it would require copying and address would change while in reality new object would represent same coroutine |
10:44:32 | cheatfate | rokups, then stack address would be the best variant |
10:44:51 | rokups | yes i agree |
10:45:07 | rokups | unless someone thinks of making auto-expanding stack support |
10:45:23 | rokups | but i have no idea how that is implemented in glibc so idk if it reallocates stack or what |
10:45:38 | rokups | i doubt anyone would do this though |
10:45:52 | cheatfate | rokups, then you need to generate unique IDs |
10:46:10 | cheatfate | because self-growing stacks is a nice feature too |
10:47:53 | rokups | incrementing id might get messy when coroutines get moved to another thread, unless its global |
10:49:41 | cheatfate | but we don't need globals |
10:50:35 | cheatfate | then maybe some kind of `thread_id + stack_address + proc_address`. |
10:52:46 | rokups | wouldnt that pose a danger of `5 + 3` == `3 + 5` kind of problem? |
10:53:31 | cheatfate | rokups, when i mean some kind i mean F(thread_id, stack_address, proc_address) which can be MD5(thread_id + stack_address + proc_address) |
10:53:49 | rokups | true that |
10:54:40 | rokups | ill search info on how self-growing stacks are implemented. maybe stack address is ok after all. |
10:57:06 | * | Kingsquee quit (Quit: https://i.imgur.com/qicT3GK.gif) |
10:58:04 | cheatfate | rokups, it will be implemented like realloc(), but in nim we dont have access to realloc, so for us it will be alloc/copymem/free(old) |
10:58:37 | cheatfate | so on stack change everything will be changed |
11:00:40 | cheatfate | and to achieve this you will need to handle signal on posix systems and VEH on windows |
11:01:08 | rokups | https://gcc.gnu.org/wiki/SplitStacks says that new stack is slipped in for new function call when expansion is needed and only parameters may be copied. old stack is left intact |
11:01:29 | rokups | never heard of this being supported on windows |
11:02:14 | cheatfate | rokups, you can allocate stack as 2 pages, for example 1st (low) guard page, 2nd (high) exactly stack page |
11:02:31 | cheatfate | guard page is protected via PAGE_NOACCESS |
11:02:45 | cheatfate | so if coroutine access this page |
11:02:55 | cheatfate | your VEH handler will be invoked |
11:04:29 | cheatfate | in VEH handler you are checking if code invoked exception are inside of coroutine and guard page is belongs to this coroutine, if so you allocate new stack and modify execution context with new RSP |
11:04:34 | rokups | i do not think it is even safe to copy entire stack to new place and use that as a stack. there may be references to the old stack. new copy would invalidate them. there would be boom |
11:06:07 | cheatfate | yep, you are right, then self-growing stacks not possible |
11:06:18 | cheatfate | so you can use stack address as identifier |
11:06:49 | rokups | they are possible, and using stack address is ok ;) |
11:07:09 | rokups | read that gcc page i linked, it describes the process on how they do it. its pretty clever |
11:08:55 | cheatfate | you will need to modify GC structures |
11:09:03 | cheatfate | so it will not access this stack anymore |
11:09:08 | cheatfate | old stack i mean |
11:10:13 | * | krux02 joined #nim |
11:11:47 | rokups | why? new stack is extension of the old one. old stack does not go anywhere, its just that when application runs out of stack space it slips in new stack pointer. returning from such function puts back in old stack pointer. and we are perfectly ok yielding across these stack boundaries as execution context including stack pointer is saved |
11:13:39 | cheatfate | ok |
11:14:33 | * | jivank[m] joined #nim |
11:14:35 | * | MrAxilus[m] joined #nim |
11:14:36 | * | M-Quora joined #nim |
11:14:36 | * | ehmry joined #nim |
11:14:40 | * | erwana[m] joined #nim |
11:14:41 | * | hohlerde joined #nim |
11:14:41 | * | stisa joined #nim |
11:14:42 | * | Guest73656[m] joined #nim |
11:14:42 | * | Jipok[m] joined #nim |
11:14:42 | * | TheManiac joined #nim |
11:14:50 | cheatfate | rokups, do you like your `alive` function? because it O(n) |
11:15:13 | cheatfate | maybe its better to have it O(1)? |
11:16:35 | rokups | totally, though im not sure how exactly |
11:16:49 | rokups | (without getting in a way to multithreading) |
11:19:57 | cheatfate | currently you allocating stack in `ptr memory` and Coroutine object in `ref memory`, you can allocate everything in `ptr memory` so make Coroutine object include stack as array. |
11:20:44 | cheatfate | so in memory it can be `header` + `stack` or `stack` + `header`. |
11:21:05 | cheatfate | so if you have stack address you can obtain header address |
11:21:42 | cheatfate | also only one allocation will be done on coroutine creation, so it gives some more performance |
11:24:03 | cheatfate | but header must not be on the way of stack expansion |
11:34:41 | rokups | hmm thats a good idea. then start() could return ptr to coroutine object even. and since it is memory unmanaged by gc then having coroutine scheduled in another thread would not require copying coroutine structure |
11:34:58 | rokups | sounds like its all only good things |
11:37:46 | cheatfate | ok, i'm waiting for your work, i want to build asynchronous framework on base of your coroutines |
11:45:46 | rokups | cool, will make a patch in coming day or two |
11:50:12 | * | sz0 joined #nim |
11:50:15 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
11:58:38 | * | djellemah_ joined #nim |
11:58:47 | * | djellemah_ quit (Remote host closed the connection) |
12:04:42 | * | libman joined #nim |
12:13:47 | libman | Should I file a bug report regarding the aforementioned problem that archive.org/etc can no longer access nim-lang.org subdomains due to HEAD requests returning 404, bring it up on the forum, or just ignore it? // attn dom96 |
12:15:13 | * | jivank[m] quit (Ping timeout: 252 seconds) |
12:29:49 | * | jivank[m] joined #nim |
12:39:55 | krux02 | libman: when you noticed it, you should create an issue that describes what you realized, and what it causes. Then the Nim developers can decide what to do with it. |
12:40:19 | krux02 | They still have the option to put it on low priority or fix it. |
12:40:58 | libman | On the GitHub repo for the Website? |
12:42:23 | * | zachcarter joined #nim |
12:42:52 | libman | I guess I'll just have to overcome my allergy towards using GitHub for things other than copyfree license nagging... |
12:44:31 | krux02 | libman: probably for the website: What is your problem with github? |
12:45:47 | libman | Nothing that seriously warrants polluting this channel... |
12:50:24 | * | stisa quit (Ping timeout: 252 seconds) |
12:51:50 | * | tankfeeder joined #nim |
12:55:16 | * | stisa joined #nim |
13:01:25 | * | MrAxilus[m] quit (Ping timeout: 252 seconds) |
13:04:00 | * | MrAxilus[m] joined #nim |
13:12:01 | * | ftsf_ quit (Quit: :q!) |
13:13:06 | krux02 | libman: I don't know what the problem is, so just meniton it, I guess I can google the rest. |
13:23:20 | * | rupil joined #nim |
13:23:54 | * | PMunch joined #nim |
13:33:53 | * | zachcarter quit (Quit: zachcarter) |
13:42:24 | FromGitter | <andreaferretti> hi, a question about nimsuggest |
13:44:16 | FromGitter | <andreaferretti> is there a way (say in atom) to figure out what is the root file where nimsuggest starts |
13:45:00 | FromGitter | <andreaferretti> I always have the problem where I have a library file in the root directory I am opening |
13:45:09 | FromGitter | <andreaferretti> and tests in a subdirectory |
13:45:31 | FromGitter | <andreaferretti> the nimble file configures `path:"."` in each task |
13:45:46 | FromGitter | <andreaferretti> still, I get spurious errors in nimsuggest |
13:46:12 | FromGitter | <andreaferretti> I guess the problem is that nimsuggest is not able to figure out that the test I am writing |
13:46:25 | FromGitter | <andreaferretti> should be able to import the library, which lives one level up |
13:46:48 | FromGitter | <andreaferretti> I am not sure how to fix this |
13:48:00 | * | tyler569 joined #nim |
13:49:29 | demi- | andreaferretti, yeah it is the one that has an associated .nim.cfg file or .nimble file iirc |
13:50:26 | FromGitter | <andreaferretti> the problem is |
13:50:30 | FromGitter | <andreaferretti> I have a .nimble file |
13:50:46 | FromGitter | <andreaferretti> but source is configured in nimble tasks |
13:51:08 | demi- | i don't know the answer to that then |
13:51:25 | FromGitter | <andreaferretti> like this https://github.com/unicredit/emmy/blob/master/emmy.nimble#L35 |
13:52:22 | demi- | ah i see, yeah, sorry i don't know how to get nimsuggest to work with that |
13:52:32 | demi- | (also your github avatar is really cool) |
13:54:27 | FromGitter | <andreaferretti> :-) |
13:56:37 | demi- | presumably you should configure the nimsuggest plugin for atom to select based on the initial file that gets opened, so that way when you open the tests it will pick up that? |
13:56:48 | demi- | or i guess change how nimble is configured? |
13:57:19 | demi- | neither of those sound great but I don't know if the tooling is built out enough to handle this? |
13:57:30 | * | stisa quit (Ping timeout: 252 seconds) |
14:00:32 | * | stisa joined #nim |
14:01:44 | * | Jesin quit (Ping timeout: 255 seconds) |
14:03:56 | FromGitter | <andreaferretti> I would do an of these |
14:03:58 | FromGitter | <andreaferretti> any |
14:04:03 | FromGitter | <andreaferretti> if I knew how |
14:04:12 | FromGitter | <andreaferretti> essentially all my libraries have this structure |
14:04:19 | FromGitter | <andreaferretti> hence I cannot rely on nimsuggest at all |
14:05:11 | demi- | ah i see, i would offer to help but i know very little about nimsuggest beyond what i already said as i'm currently blocked on implementing it for the editor i use as i need socket access for communication with it |
14:08:46 | * | Jesin joined #nim |
14:12:40 | FromGitter | <andreaferretti> thank you anyway |
14:19:49 | * | yeeve quit (Remote host closed the connection) |
14:24:40 | * | yeeve joined #nim |
14:26:13 | * | tankfeeder quit (Quit: Leaving) |
14:34:32 | rokups | are symlinks allowed in compiler repo? |
14:46:26 | * | zachcarter joined #nim |
14:48:07 | * | jivank[m] quit (Ping timeout: 252 seconds) |
14:51:26 | * | jivank[m] joined #nim |
15:00:23 | * | hohlerde quit (Ping timeout: 264 seconds) |
15:08:23 | * | rauss joined #nim |
15:09:15 | * | PMunch quit (Quit: leaving) |
15:09:37 | * | hohlerde joined #nim |
15:22:45 | * | M-Quora quit (Ping timeout: 252 seconds) |
15:24:50 | krux02 | rokups: unrelated to whether they are allowed or not, they do work on NTFS |
15:25:09 | rokups | you are so misinformed |
15:25:46 | krux02 | last time I did test ls -s on an ntfs filesystem, I was surprised that it actually produced a link |
15:26:26 | * | M-Quora joined #nim |
15:26:32 | krux02 | but anyway, when you think it does not work on NTFS hard drives, you should have your answer |
15:27:11 | rokups | you just said you saw yourself symlinks work and you still claim they do not work. amazing :) |
15:36:55 | * | rupil left #nim (#nim) |
15:39:21 | * | djellemah quit (Ping timeout: 260 seconds) |
15:39:59 | * | djellemah joined #nim |
15:42:16 | flyx | demi-: so your editor is not able to open sockets? |
15:42:30 | enthus1ast | krux02 rokups used git on windows lateley? : ) |
15:42:49 | enthus1ast | they do symlinks afaik |
15:44:07 | rokups | then maybe ill get the blessing. i could save duplicating bunch of files and get coroutines tested in multiple configurations that way |
15:45:59 | demi- | flyx: not from the API it currently has |
15:46:13 | demi- | that is probably going to be changing though |
15:46:54 | * | yglukhov quit (Remote host closed the connection) |
15:50:03 | * | yglukhov joined #nim |
15:51:07 | * | dexterk joined #nim |
15:51:22 | * | dexterk__ quit (Ping timeout: 268 seconds) |
15:52:01 | * | nsf quit (Quit: WeeChat 1.7) |
15:54:39 | * | yglukhov quit (Ping timeout: 252 seconds) |
15:58:59 | krux02 | enthuslast: I haven't used windows lately, I just used ``bash$ ln -s`` on an NTFS hd. |
16:03:48 | * | PMunch joined #nim |
16:06:04 | * | tobacco_joe joined #nim |
16:06:15 | zachcarter | I’m trying to bind to an inline C function and failing miserabily, can anyone help? https://gist.github.com/zacharycarter/9a765bb81e1493ec3324d1037f40b0d0 |
16:06:32 | * | tobacco_joe left #nim ("('Out')") |
16:07:40 | zachcarter | whoops sorry |
16:07:44 | zachcarter | that example is bad I’ll fix it |
16:08:06 | zachcarter | fixed |
16:11:42 | * | MrAxilus[m] quit (Ping timeout: 252 seconds) |
16:14:54 | zachcarter | removing the static inline seems to work... |
16:15:00 | * | hohlerde quit (Ping timeout: 252 seconds) |
16:17:24 | * | hohlerde joined #nim |
16:17:35 | zachcarter | that’s not a solution though I don’t believe... |
16:18:00 | krux02 | zachcarter: static makes a function local |
16:18:09 | krux02 | the function will not be seen from the linke |
16:18:12 | krux02 | r |
16:18:14 | zachcarter | ah okay thanks |
16:18:22 | * | MrAxilus[m] joined #nim |
16:18:25 | krux02 | and it will not clash with other functions with the same name |
16:19:00 | zachcarter | hrm if I remove static and keep the inline keyword in C I still can’t seem to bind to them |
16:19:40 | krux02 | why do you need it te be inline? |
16:20:06 | zachcarter | I don’t necessarily, they were just inlined in C |
16:21:27 | krux02 | normally inlined functions in C are also declared in function scope, so that the compiler can inline them |
16:21:37 | krux02 | otherwise the function could only be inlined from the linker |
16:21:46 | krux02 | and that is a much more complicated problem |
16:22:41 | krux02 | So this is a bit half knowledge here, but afaik inlined functions in C are declared in headers as static, so that each compilation unit knows about them, and can then inline them |
16:22:59 | krux02 | and then the function is just not exported at all to the linker |
16:23:06 | krux02 | therefore you can't bind them |
16:23:10 | zachcarter | okay this makes sense |
16:24:13 | zachcarter | thank you for that explanation |
16:24:17 | krux02 | and when you bind to them there is also little guarantee, that it will be inlined from the linker |
16:24:39 | krux02 | so my guess would be to port that inlined function to a template or an inline function in Nim |
16:24:52 | krux02 | ah wait |
16:24:55 | krux02 | it's printf |
16:25:52 | zachcarter | there’s a bunch of static inlines here I’ll probably need to port |
16:30:36 | * | Trustable joined #nim |
16:30:51 | * | derlafff quit (Quit: No Ping reply in 180 seconds.) |
16:33:30 | * | derlafff joined #nim |
16:34:04 | krux02 | yea and it's the horrible C varargs |
16:34:16 | krux02 | varargs that can basically do nothing more than printf |
16:34:35 | zachcarter | yeah |
16:34:40 | zachcarter | so annoying |
16:37:55 | krux02 | well you know it's used from nim |
16:38:18 | krux02 | therefore, you could cheat and only support a single string parameter |
16:38:51 | krux02 | strutils.format can do all the fuzz that these C marcros are supposed to solve |
16:39:38 | krux02 | What I want to say is that you are not really missing out on something, when you do not support an printf interface |
16:40:24 | krux02 | you just need provide one print function in your bind.c that just prints a string |
16:40:27 | krux02 | and that one you bind |
16:44:19 | * | sz0 quit (Quit: Connection closed for inactivity) |
16:44:38 | zachcarter | right |
16:47:45 | * | Andris_zbx quit (Remote host closed the connection) |
16:48:23 | * | jmkr quit (Ping timeout: 264 seconds) |
16:52:12 | * | jmkr joined #nim |
17:00:24 | * | yglukhov joined #nim |
17:01:22 | * | yglukhov quit (Remote host closed the connection) |
17:01:34 | * | yglukhov joined #nim |
17:03:15 | yglukhov | Can anyone remind me how to use memtracker option? |
17:05:35 | krux02 | zachcarter: can you leave a comment here https://github.com/nim-lang/Nim/issues/5437 when you think that it would actually help you to write your wrapper? |
17:05:43 | zachcarter | sure |
17:06:20 | * | yglukhov quit (Remote host closed the connection) |
17:07:32 | * | Matthias247 joined #nim |
17:11:49 | * | ehmry quit (Remote host closed the connection) |
17:11:50 | * | erwana[m] quit (Read error: Connection reset by peer) |
17:11:50 | * | Jipok[m] quit (Read error: Connection reset by peer) |
17:11:50 | * | Guest73656[m] quit (Read error: Connection reset by peer) |
17:11:51 | * | dyce[m] quit (Write error: Connection reset by peer) |
17:11:51 | * | M-Quora quit (Write error: Connection reset by peer) |
17:11:58 | * | jivank[m] quit (Write error: Connection reset by peer) |
17:11:59 | * | hohlerde quit (Read error: Connection reset by peer) |
17:11:59 | * | TheManiac quit (Read error: Connection reset by peer) |
17:12:00 | * | stisa quit (Read error: Connection reset by peer) |
17:12:02 | * | MrAxilus[m] quit (Read error: Connection reset by peer) |
17:17:44 | * | brson joined #nim |
17:27:24 | * | yglukhov joined #nim |
17:28:21 | * | BitPuffin|osx joined #nim |
17:34:21 | * | Snircle joined #nim |
17:39:19 | * | yglukhov quit (Remote host closed the connection) |
17:40:04 | * | yglukhov joined #nim |
17:48:20 | * | dyce[m] joined #nim |
18:04:22 | * | yglukhov quit (Remote host closed the connection) |
18:16:36 | zachcarter | Looks like my bindings are working for : https://bitbucket.org/cfyzium/bearlibterminal - https://drive.google.com/file/d/0B2CfYyfxKriOV0Y4ZF9laGhYWWM/view?usp=sharing |
18:17:29 | * | yglukhov joined #nim |
18:18:31 | * | butchster joined #nim |
18:19:37 | krux02 | is the -d:nativeStackTrace option for the nim compiler supposed to do something? |
18:20:40 | krux02 | cool |
18:22:59 | krux02 | zachcarter: I did not know about tha libterminal thing |
18:23:30 | zachcarter | krux02: it’s one of the more popular terminal emulators a lot of roguelike game developers use |
18:23:35 | krux02 | sounds like the library to make a rogue like |
18:23:44 | krux02 | hah |
18:23:45 | zachcarter | IMO it beats the pants off of libtcod |
18:23:59 | krux02 | I don't know libtcod |
18:24:01 | zachcarter | doesn’t offer as much but it’s just a terminal emulator and that’s good |
18:24:13 | zachcarter | libtcod tries to provide everything and doesn’t do a great job at any of it |
18:24:13 | zachcarter | one sec |
18:24:22 | zachcarter | http://roguecentral.org/doryen/libtcod/ |
18:25:04 | demi- | oh neat, this looks better than termbox |
18:26:23 | demi- | if i wasn't so deeply invested in termbox at this point i'd switch |
18:26:28 | krux02 | actually I do know libtcod |
18:26:35 | krux02 | it's used in brogue |
18:26:41 | demi- | chose termbox over ncurses because ncurses is brutal to manage |
18:27:27 | zachcarter | I’m trying to get more roguelike devs looking at nim |
18:27:31 | krux02 | I think it's funny, that people switch to just do ascii art, because it is supposed to be easier, and then it it actually not, because of horrible terminal things |
18:28:02 | zachcarter | agreed |
18:28:15 | krux02 | easiest is 2D sprite blitting I guess |
18:28:37 | krux02 | and all that I saw in the example can very easily done with 2D sprite blitting |
18:28:41 | Vladar | keep in mind that libtcod is actually graphical, not text-mode |
18:28:55 | krux02 | I know |
18:29:05 | krux02 | but it can enable a text mode afaik |
18:29:13 | krux02 | at least brogue the game can |
18:29:20 | krux02 | but that doesn't look so good |
18:29:32 | zachcarter | probably because of lack of square fonts |
18:29:36 | zachcarter | I’m guessing |
18:29:47 | krux02 | when a game is made to support true color, rendering it in terminal colors doesn't do it a favor |
18:30:03 | krux02 | the square fonts are not the problem |
18:30:09 | zachcarter | ah okay |
18:30:14 | krux02 | my terminal uses a square font |
18:30:21 | Vladar | I guess, text-mode isn't a part of libtcod API |
18:30:25 | * | hohlerde joined #nim |
18:30:26 | * | jivank[m] joined #nim |
18:30:26 | * | MrAxilus[m] joined #nim |
18:30:29 | * | M-Quora joined #nim |
18:30:30 | * | ehmry joined #nim |
18:30:32 | * | erwana[m] joined #nim |
18:30:33 | * | stisa joined #nim |
18:30:34 | * | TheManiac joined #nim |
18:30:35 | * | Guest73656[m] joined #nim |
18:30:37 | * | Jipok[m] joined #nim |
18:30:37 | krux02 | but however libtcod is, brogue is a pretty awesome game |
18:30:51 | krux02 | I am not heavily invested in roguelike games |
18:31:14 | zachcarter | brogue is a good game, I’m not sure how much of the libtcod library it uses |
18:31:16 | krux02 | I just wasted some time in dwarf fortress (not the best experience) and tested brogue |
18:31:24 | krux02 | it is just so simple to get started |
18:31:35 | zachcarter | I know in the roguelike I am working on, libtcod wouldn’t even scratch the surface of the procedural generatiion stuff I need |
18:31:39 | krux02 | I don't know much much comes from libtcod, and how much it is brogue |
18:31:51 | zachcarter | These were the maps I was procedurally generating in Java |
18:32:03 | zachcarter | and libgdx before switching to nim |
18:32:16 | zachcarter | https://github.com/zacharycarter/mapgen |
18:32:17 | Vladar | there's some pretty neat prodedural generation stuff in libtcod, IIRC |
18:32:43 | zachcarter | there is but it’s fairly rudimentary proc gen stuff Vladar |
18:33:22 | zachcarter | for instance, with the maps I just linked I was generating, they wouldn’t have been possible to generate with the proc gen features in libtcod |
18:33:36 | zachcarter | no 4d perlin / simplex noise in libtgcod |
18:33:40 | zachcarter | libtcod* |
18:34:05 | Vladar | It may be, don't remember for sure. It's pretty long ago when I messed with libtcod, writing its wrapper for Nim. |
18:34:49 | zachcarter | another shortcoming of libtcod is it’s osx support :/ |
18:34:54 | zachcarter | or lack thereof |
18:35:44 | krux02 | yea, mac support |
18:35:47 | krux02 | always a struggle |
18:36:07 | krux02 | I also did a procedural game project in scala |
18:36:26 | krux02 | It was in 2010 I think |
18:36:58 | zachcarter | nice |
18:36:59 | krux02 | I wanted it to be like mincraft with the qubes, but also to allow arbitrary shapes |
18:37:07 | krux02 | I was looking for screenshots |
18:37:11 | krux02 | I don't find them anymore |
18:37:29 | krux02 | it was 3D |
18:38:19 | krux02 | the wase even a live editor for the procedural world |
18:38:37 | krux02 | and a prediction function for it |
18:38:51 | * | yglukhov quit (Remote host closed the connection) |
18:38:51 | * | nsf joined #nim |
18:38:58 | zachcarter | sounds sweet |
18:39:02 | demi- | I don't know how you can build something like that to work on unix/linux and not get it to work on OS X |
18:39:11 | krux02 | the problem for 3d world generation is that when you want to sample 3D space it is O^3 |
18:39:38 | * | yglukhov joined #nim |
18:40:00 | zachcarter | agreed demi- |
18:40:09 | zachcarter | libtcod is using sdl / sdl2 to my knowledge as well |
18:40:24 | krux02 | That engine the the possibility to arbitrarily define the density function of the noise, and still keep the complexity in somewhat O(N^2*lon(N)) |
18:40:34 | demi- | hmmm, yeah i don't see why that wouldn't be compatible then |
18:40:51 | demi- | almost like you had to intentionally go out of your way to make things difficult |
18:41:28 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
18:41:42 | krux02 | so there was some compiler that worked on the density function symbolically and generated a range prediction function for the 3D world |
18:42:16 | krux02 | and the generater used the 3D range (volume) and asked: "does this intersect 0?" |
18:42:24 | krux02 | super nice stuff there |
18:42:29 | zachcarter | sounds like it |
18:42:45 | krux02 | brogue has a mac release tw |
18:42:47 | krux02 | btw |
18:42:54 | zachcarter | yeah some people have gotten libtcod to compile on osx |
18:43:15 | zachcarter | I know it’s possible it just doesn’t work and the author has stated implicity if you want to get it working it’s on you |
18:43:42 | zachcarter | I’m pretty sure AWS East Coast services are being DDOSed right now |
18:43:47 | zachcarter | and not winning |
18:44:08 | zachcarter | everything is slow / timing out |
18:44:11 | zachcarter | https://status.bitbucket.org/ |
18:44:26 | zachcarter | https://status.github.com/ |
18:44:27 | krux02 | yea |
18:44:30 | krux02 | I see |
18:44:32 | krux02 | it's slow |
18:44:44 | * | elrood joined #nim |
18:45:11 | zachcarter | well break time then |
18:47:12 | demi- | it is pretty broken |
18:47:30 | * | xet7 joined #nim |
18:48:02 | Vladar | Well, I received osx related patch recently, so libtcod surely works there at least for someone https://github.com/Vladar4/libtcod_nim/commit/2e48a05df4917329eadaf35ce3ad2734131c4a20 |
18:52:53 | krux02 | just to mention it, when you once want to start editing bitmaps: gimp is horrible with that. I recently found grafx2 |
18:53:16 | Vladar | aseprite for me |
18:53:29 | krux02 | it's a bit retro, but still very easy to use and very pixel art oriented |
18:53:43 | krux02 | (supports color cycles) |
18:54:36 | zachcarter | https://github.com/podiki/libtcod-mac looks like maybe doryen upped his game and now libtcod is working on osx too |
18:54:55 | zachcarter | since it says that repo is no longer needed and libtcod can be built on osx provided the correct dependencies are installed |
19:03:52 | * | ehmry is now known as ehmry[m] |
19:16:08 | * | zahary_ joined #nim |
19:22:05 | * | dddddd joined #nim |
19:24:43 | PMunch | Araq, https://github.com/Araq/wxnim/pull/3 |
19:24:56 | PMunch | Made a pull request to the wxWidgets bindings |
19:25:25 | zachcarter | krux02: it doesn’t look like we’re going to have much in the way of libraries to bind to for artificial intelligence |
19:25:46 | zachcarter | this is a hole that needs filling |
19:27:41 | krux02 | zachcarter: what do you mean by that? |
19:27:58 | zachcarter | probably going to have to write some time of AI library / framework |
19:28:10 | zachcarter | something similar to https://github.com/libgdx/gdx-ai |
19:28:56 | zachcarter | opensteer is c++ |
19:29:06 | * | Ven joined #nim |
19:30:43 | krux02 | I didn't know there were AI libraries |
19:30:58 | krux02 | AI is also very very broad field |
19:31:02 | zachcarter | it is |
19:31:11 | krux02 | Game AI has usually very little to do with machine learning |
19:31:18 | zachcarter | agreed |
19:32:28 | krux02 | I had lectures about machine learning, and I can tell you it is super hard |
19:32:34 | krux02 | I mean the basics are simple |
19:32:50 | krux02 | but it is all very fuzzy |
19:33:07 | zachcarter | https://github.com/recastnavigation/recastnavigation |
19:33:31 | krux02 | it leaves the nice and defined discrete logic world that we computer scientists and programmers like so much about computers :P |
19:33:57 | zachcarter | :) |
19:35:29 | krux02 | well the first thing I already see in this library is, that it is build on level pregeneration |
19:35:46 | krux02 | build the level in an editor and then run it through the tool |
19:35:51 | krux02 | at least that is my impression |
19:35:58 | krux02 | that is very common to do |
19:36:02 | krux02 | almost all games do that |
19:36:08 | zachcarter | yeah |
19:36:27 | krux02 | but I am writing my own engine, because I do not want to be like almost all games |
19:37:09 | krux02 | I don.t have a problem with stupid AI |
19:37:18 | krux02 | games can still be fun when the AI is not |
19:37:41 | zachcarter | true |
19:37:41 | krux02 | so my choice for me here is clear |
19:38:04 | krux02 | just write a trivial AI that can handle a dynamic environment |
19:39:12 | * | PMunch quit (Quit: leaving) |
19:39:56 | * | couven92 quit (Read error: Connection reset by peer) |
20:02:54 | krux02 | zachcarter: But thank you for the feference material of the raycast navigator |
20:03:04 | krux02 | I think I can use some information from it |
20:03:06 | zachcarter | np |
20:03:18 | zachcarter | I’m working on some higher level bindings for nuklear |
20:03:46 | zachcarter | not really sure what I’m doing but after I write one function I’ll post a gist and see what you think |
20:09:39 | zachcarter | krux02: is this essentially what I should be doing : https://gist.github.com/zacharycarter/cb784e5fa781e7364b251c583cb8a0f8 ? |
20:10:38 | zachcarter | that way users of the bindings don’t have to deal with pointers |
20:18:30 | krux02 | when you write a binding for a c function you don't need cdecl |
20:18:57 | krux02 | cdecl disables name mangling, so that you know the name when you want to call it from C |
20:19:21 | zachcarter | ah okay |
20:19:25 | zachcarter | thanks for that |
20:19:28 | krux02 | functions you do not intend to call from your own c code don't need that |
20:19:50 | krux02 | but apart from that I don't know what that gist is supposed to do |
20:19:51 | zachcarter | that makes sense now why it’s on callbacks from c code in GLFW and stuff okay |
20:20:08 | zachcarter | remember the other day when we were talking about how bindings should have two layers |
20:20:18 | zachcarter | one layer very close to the C code |
20:20:44 | zachcarter | then another layer of abstraction |
20:21:06 | zachcarter | I’m essentially trying to figure out how I should be wrapping these functions with another layer of abstraction so users don’t have to deal with passing pointers |
20:21:35 | krux02 | I don't think that pointer are a problem at all |
20:22:29 | zachcarter | I don’t either but one person in here was complaining about them, and I believe def-pri-pub suggested another layer of abstraction on top of the bindings |
20:22:38 | zachcarter | maybe it wasn’t the pointers he / they were referring to being the problem |
20:22:52 | krux02 | when the user of the c library has to handle lifetame / deallocation / destruction of objects, nim does not provide anything working to take that away |
20:23:02 | * | tyler569 left #nim (#nim) |
20:23:03 | krux02 | in C++ you would wrap in in an object with destructor |
20:23:08 | krux02 | but that doesn't work in nim |
20:23:11 | zachcarter | right |
20:23:34 | krux02 | and the abstraction you provided is not guaranteed to work |
20:23:43 | krux02 | it will probably work, but it can also just fail |
20:24:01 | krux02 | I don't know what init_default does |
20:24:20 | krux02 | there are two ways you could abstract it away |
20:24:24 | zachcarter | okay |
20:24:40 | krux02 | first of all, I would just call it init |
20:24:50 | krux02 | unless there is an alternative buffer initializer |
20:24:58 | zachcarter | there are a bunch |
20:25:07 | krux02 | do the other ones all have arguments? |
20:25:31 | zachcarter | https://github.com/zacharycarter/nuklear-nim/blob/master/nuklear.nim#L1025 |
20:27:01 | krux02 | ok there are three |
20:27:20 | krux02 | I would call them all just init |
20:27:20 | zachcarter | yeah I thought there were more |
20:27:24 | zachcarter | okay |
20:27:34 | krux02 | but the default has no argument |
20:27:45 | * | Kingsquee joined #nim |
20:27:47 | krux02 | wait |
20:27:47 | zachcarter | okay |
20:27:53 | krux02 | they all should have the buffer as an argument |
20:28:02 | krux02 | the question is how you want to pass it |
20:28:08 | zachcarter | right |
20:28:09 | krux02 | the alternative to ptr is var |
20:28:23 | zachcarter | ah okay so that would be the Nim way to do it |
20:28:31 | zachcarter | that makes sense now |
20:28:42 | krux02 | var is just a hidden pointer |
20:28:45 | zachcarter | right |
20:29:10 | krux02 | semantically it is the same, but people don't need to wrider var buffer: Buffer; buffer.addr.init |
20:29:20 | * | elrood quit (Quit: Leaving) |
20:29:25 | krux02 | they can just write buffer.init |
20:29:43 | zachcarter | okay cool thank you yeah I totally forgot I could use var here |
20:30:18 | krux02 | and for the rest, you could just leave out the prefix |
20:30:26 | krux02 | unless it clashes with something in system |
20:30:31 | zachcarter | right |
20:30:42 | krux02 | but I don't think so because it is all with the typed first argument |
20:30:56 | krux02 | the typed first argument basically removes all name clashes |
20:48:23 | * | Salewski joined #nim |
20:51:02 | Salewski | I have a string stream from module streams. I can move position for next write backwards with setPosition(). But characters after this new position |
20:51:13 | * | Trustable quit (Remote host closed the connection) |
20:51:36 | Salewski | do still exist. How can I delete these. Something like setLen()? |
20:55:49 | FromGitter | <philip-wernersbach> How do I execute Nimscript files? |
20:56:09 | FromGitter | <philip-wernersbach> I'm trying to build the examples in @Araq 's karat repo |
20:56:12 | Salewski | Well, string stream object exposes the data field, which is a string. Can I do arbitrary string operations on data field, so call data.setLen()? |
21:03:13 | Salewski | philip-wernersbach: See https://nim-lang.org/0.11.3/nims.html # Use nim e myscript.nims to run myscript.nims |
21:08:11 | FromGitter | <philip-wernersbach> @Salewski Thanks. "nim e example.nims" does nothing though :( |
21:12:12 | * | rokups quit (Quit: Connection closed for inactivity) |
21:14:28 | * | rauce quit (Ping timeout: 240 seconds) |
21:16:15 | * | rauce joined #nim |
21:23:58 | * | krux02 quit (Remote host closed the connection) |
21:27:39 | * | rauce quit (Ping timeout: 240 seconds) |
21:27:57 | * | rauce joined #nim |
21:40:29 | Salewski | philip-wernersbach: Works fine here. Nim Compiler Version 0.16.0 (2017-01-09) [Linux: amd64] |
21:40:55 | Salewski | Maybe you have this old bug: http://stackoverflow.com/questions/34279446/nim-nimscript-is-not-executing-commands |
21:50:13 | * | butchster_ joined #nim |
21:50:16 | * | rauce quit (Ping timeout: 268 seconds) |
21:50:58 | * | butchster quit (Ping timeout: 240 seconds) |
21:51:15 | * | rauce joined #nim |
21:51:31 | * | butchster_ quit (Client Quit) |
21:51:41 | * | butchster joined #nim |
21:56:47 | * | zachcarter quit (Ping timeout: 264 seconds) |
22:05:01 | * | ofelas quit (Quit: Leaving) |
22:05:38 | * | aziz joined #nim |
22:07:40 | * | Vladar quit (Quit: Leaving) |
22:14:08 | * | Jesin quit (Quit: Leaving) |
22:16:49 | * | Jesin joined #nim |
22:18:12 | * | Salewski quit (Quit: Salewski) |
22:18:21 | * | Salewski joined #nim |
22:19:36 | * | krux02 joined #nim |
22:19:44 | krux02 | aparently I was offline |
22:19:48 | krux02 | I am back now yay |
22:20:05 | krux02 | hmm, how do I make a generic over all distinct int types? |
22:25:02 | * | PMunch joined #nim |
22:35:24 | * | ofelas joined #nim |
22:35:33 | * | ofelas_ joined #nim |
22:35:33 | * | ofelas_ quit (Client Quit) |
22:38:01 | * | Salewski left #nim (#nim) |
22:38:58 | * | rauss quit (Quit: WeeChat 1.7) |
22:55:02 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
22:55:42 | FromGitter | <philip-wernersbach> @Salewski Might be. I'm using 0.15.2, I'll try upgrading |
23:00:58 | * | Senketsu joined #nim |
23:01:18 | * | Senketsu quit (Client Quit) |
23:01:19 | * | aziz quit (Remote host closed the connection) |
23:02:00 | * | nsf quit (Quit: WeeChat 1.7) |
23:18:04 | * | zachcarter joined #nim |
23:20:17 | * | ofelas quit (Remote host closed the connection) |
23:20:42 | * | ofelas joined #nim |
23:24:28 | * | zachcarter quit (Ping timeout: 240 seconds) |
23:26:27 | krux02 | I found a way do make a function generic over all field pairs, I used a concept and a macro |
23:26:32 | krux02 | does work very well |
23:26:47 | * | ofelas quit (Remote host closed the connection) |
23:27:12 | krux02 | is there some mutable version of fieldPairs |
23:27:30 | * | ofelas joined #nim |
23:30:17 | * | ftsf_ joined #nim |
23:42:48 | * | couven92 joined #nim |
23:50:13 | * | Snircle joined #nim |
23:59:21 | * | themagician quit () |