| 00:04:44 | * | ftsf quit (Ping timeout: 255 seconds) |
| 00:05:25 | * | stisa2 quit (Ping timeout: 260 seconds) |
| 00:17:55 | * | ftsf joined #nim |
| 00:25:27 | * | PMunch quit (Quit: leaving) |
| 00:27:28 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:37:49 | * | stisa2 joined #nim |
| 00:38:49 | * | zachcarter quit (Quit: zachcarter) |
| 00:59:38 | * | IRCFrEAK joined #nim |
| 00:59:40 | * | IRCFrEAK left #nim (#nim) |
| 01:12:57 | * | gangstacat quit (Quit: Ĝis) |
| 01:18:10 | * | gangstacat joined #nim |
| 01:42:57 | * | stisa2 quit (Ping timeout: 260 seconds) |
| 01:43:49 | * | stisa2 joined #nim |
| 01:51:43 | * | sz0 joined #nim |
| 02:13:46 | * | vlad1777d__ quit (Quit: Leaving) |
| 02:28:41 | * | stisa2 quit (Ping timeout: 240 seconds) |
| 02:29:05 | * | couven92 quit (Read error: Connection reset by peer) |
| 02:30:02 | * | stisa2 joined #nim |
| 02:34:20 | * | stisa2 quit (Ping timeout: 240 seconds) |
| 02:36:28 | * | stisa2 joined #nim |
| 02:42:20 | * | chemist69 quit (Ping timeout: 240 seconds) |
| 02:56:21 | * | chemist69 joined #nim |
| 03:23:17 | * | stisa2 quit (Ping timeout: 260 seconds) |
| 03:23:38 | * | stisa2 joined #nim |
| 03:27:48 | * | yglukhov joined #nim |
| 03:32:00 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 03:34:40 | * | stisa2 quit (Ping timeout: 240 seconds) |
| 03:55:56 | * | roygbiv joined #nim |
| 04:06:07 | * | madgoat joined #nim |
| 04:06:09 | * | madgoat left #nim (#nim) |
| 04:24:14 | * | roygbiv quit (Remote host closed the connection) |
| 04:25:15 | * | roygbiv joined #nim |
| 04:40:30 | * | def-pri-pub quit (Quit: leaving) |
| 05:16:30 | * | stisa2 joined #nim |
| 05:34:53 | * | stisa2 quit (Ping timeout: 260 seconds) |
| 05:58:05 | * | nsf joined #nim |
| 05:58:26 | * | chemist69 quit (Ping timeout: 255 seconds) |
| 06:03:11 | * | chemist69 joined #nim |
| 06:21:27 | * | roygbiv quit (Quit: ™) |
| 06:26:58 | * | yglukhov joined #nim |
| 06:31:29 | * | yglukhov quit (Ping timeout: 268 seconds) |
| 06:37:23 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 06:45:22 | * | ftsf quit (Quit: :q!) |
| 06:45:43 | * | djellemah_ joined #nim |
| 06:46:28 | * | stisa2 joined #nim |
| 07:24:24 | * | bjz joined #nim |
| 07:27:27 | * | Princess17b29a quit (Read error: Connection reset by peer) |
| 07:29:56 | * | Princess17b29a joined #nim |
| 07:34:41 | * | stisa2 quit (Ping timeout: 260 seconds) |
| 07:35:36 | * | stisa2 joined #nim |
| 07:42:42 | * | rauss quit (Quit: WeeChat 1.7) |
| 07:58:38 | * | yglukhov joined #nim |
| 07:59:12 | * | couven92 joined #nim |
| 08:10:24 | * | gokr joined #nim |
| 08:10:53 | * | libman quit (Quit: Connection closed for inactivity) |
| 08:14:06 | * | yglukhov quit (Remote host closed the connection) |
| 08:16:44 | * | rokups joined #nim |
| 08:17:21 | rokups | whats this failed build job under allowed failures? https://travis-ci.org/nim-lang/Nim/builds/202960164 |
| 08:17:33 | rokups | should i be concerned about my changes breaking it? |
| 08:23:54 | * | yglukhov joined #nim |
| 08:32:58 | Araq | rokups: https://github.com/nim-lang/Nim/pull/5317 is green for me |
| 08:33:15 | Araq | travis OSX tests are not yet green and that is not your fault |
| 08:35:18 | yglukhov | Araq: hi. can you say anything about https://github.com/nim-lang/Nim/issues/5411 and https://github.com/nim-lang/Nim/issues/5241 . are they hard to fix? I've spent some time to understand, but apparently not enough. |
| 08:36:03 | rokups | oh thats osx, i see. did you see latest things i did? cleaned up that gc code to avoid multiple copies of same code with minor changes and made coroutines opt-out instead of opt-in (just to see how CI reacts). seems promising. tell me what you think and if i should revert it to opt-in before merge. |
| 08:36:25 | * | stisa2 quit (Ping timeout: 260 seconds) |
| 08:36:37 | * | stisa2 joined #nim |
| 08:37:41 | Araq | opt-in of course :-) |
| 08:37:50 | Araq | it may end up in 0.16.2 |
| 08:40:42 | Araq | yglukhov: no idea, where are you stuck? |
| 08:44:08 | yglukhov | Araq: regarding 5241 i'm stuck in sigmatch between isObjectSubtype and sameObjectTypes |
| 08:46:44 | * | Arrrr joined #nim |
| 08:46:44 | * | Arrrr quit (Changing host) |
| 08:46:44 | * | Arrrr joined #nim |
| 08:46:54 | Araq | well we have a subtype relation in this match, so you need to fix isObjectSubtype |
| 08:50:21 | yglukhov | isObjectSubtype relies mostly on sameObjectTypes. |
| 09:08:11 | * | Vladar joined #nim |
| 09:14:17 | * | sz0 quit (Quit: Connection closed for inactivity) |
| 09:14:20 | * | chemist69 quit (Ping timeout: 240 seconds) |
| 09:15:00 | * | chemist69 joined #nim |
| 09:36:01 | Arrrr | {.used.} pragma at last. That was a perfect addition. |
| 09:41:15 | Araq | you should thank endragor for that :-) |
| 09:41:45 | Araq | but I wonder why so many people like/need this feature |
| 09:44:47 | Arrrr | Endragor, great idea, thanks. I use this mostly for templates that are only needed inside other templates that accept untyped code, for example https://glot.io/snippets/enayljdqvu |
| 09:44:57 | Arrrr | This would compile with "minus not used" |
| 09:45:40 | Arrrr | I don't want to move them into global scope |
| 09:57:56 | * | bjz_ joined #nim |
| 09:58:18 | * | zachcarter joined #nim |
| 09:58:56 | Araq | Arrrr: ah, very good example, thanks |
| 09:59:28 | * | bjz quit (Ping timeout: 240 seconds) |
| 10:29:11 | * | Jesin quit (Ping timeout: 240 seconds) |
| 10:38:01 | * | bjz_ quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 10:45:07 | * | bjz joined #nim |
| 11:06:01 | * | couven92 quit (Quit: Client disconnecting) |
| 11:27:23 | * | arnetheduck joined #nim |
| 11:29:49 | * | yglukhov quit (Remote host closed the connection) |
| 11:50:33 | * | zevlg joined #nim |
| 11:53:26 | * | yglukhov joined #nim |
| 11:56:57 | zachcarter | o/ |
| 11:58:19 | * | yglukhov quit (Ping timeout: 268 seconds) |
| 12:02:37 | * | Snircle joined #nim |
| 12:06:46 | rokups | Araq: could you take a look at this when you can? https://github.com/rokups/Nim/blob/6ec0114e6e7dfcb0f55889aa35f48cf386de6f47/lib/arch/coro.nim#L372-L388 last assert is failing. Can GC_fullCollect() not free objects seq that was just assigned to nil? Or is it a gc bug i introduced? |
| 12:09:48 | zachcarter | http://imgur.com/a/WcH2o |
| 12:10:03 | zachcarter | I haven’t figured out how to effectively iterate through the elements and draw them yet |
| 12:10:16 | zachcarter | but if I just start hardcoding draw commands the children start drawing :) |
| 12:10:26 | zachcarter | so i guess the wrap is a success |
| 12:29:39 | * | yglukhov joined #nim |
| 12:44:26 | zachcarter | http://imgur.com/a/zqoYN - better screenshot |
| 12:46:29 | Arrrr | What are you going to make? |
| 12:50:26 | * | Salewski joined #nim |
| 12:51:00 | zachcarter | editor for a game engine |
| 12:51:25 | zachcarter | going to use nim-bgfx and write a drawing backend for that |
| 12:51:59 | Salewski | I wonder if we have some proc for taking n elements from an array like |
| 12:52:03 | Salewski | take(n=3, [1,2,3,4] ) ==> [[1,2,3], [1,2,4], [1,3,4], [2,3,4]] |
| 12:52:29 | Salewski | Should work for arbitrary n. |
| 12:53:35 | Salewski | Indeed I would need that for a table or set, but of course I can convert table/set to array first. |
| 12:54:46 | zachcarter | I’m going to have to wrap a texture compression library next I think but I’ll get to that when I need to |
| 12:54:56 | zachcarter | now though I’m going to start on this editor :D |
| 12:55:23 | zachcarter | Salewski: I have no idea |
| 13:05:50 | Salewski | http://stackoverflow.com/questions/127704/algorithm-to-return-all-combinations-of-k-elements-from-n |
| 13:06:13 | Salewski | Will read that later, bye... |
| 13:08:45 | * | Salewski left #nim (#nim) |
| 13:14:56 | * | stisa2 quit (Ping timeout: 255 seconds) |
| 13:27:00 | * | Arrrr quit (Read error: Connection reset by peer) |
| 13:34:42 | * | adeohluwa joined #nim |
| 13:38:00 | * | stisa2 joined #nim |
| 13:50:41 | * | gokr quit (Ping timeout: 240 seconds) |
| 13:56:12 | * | planhths joined #nim |
| 13:57:25 | * | planhths quit (Client Quit) |
| 13:59:43 | Araq | rokups: you know that stack scanning is conservative so a stack slot that looks like the pointer to the seq can keep it alive |
| 13:59:53 | Araq | I dunno why it comes up again and again and again. |
| 14:00:31 | rokups | im flattered. i dont know shit :) thanks for clarifying though ;) |
| 14:00:54 | Araq | GC_fullCollect should come with a big warning. |
| 14:02:17 | rokups | was just trying to asses if i did not break something. though bootstrapping compiler seems to be pretty good indicator of that as well. when i got it half-working it started bootstrapping but with max memory usage of 1.2 GB ^_^ |
| 14:03:30 | * | irrequietus quit (Ping timeout: 268 seconds) |
| 14:07:44 | * | PMunch joined #nim |
| 14:08:13 | * | stisa2 quit (Ping timeout: 260 seconds) |
| 14:08:20 | * | couven92 joined #nim |
| 14:10:56 | * | stisa2 joined #nim |
| 14:15:48 | FromGitter | <konqoro> @Salewski something like this? https://github.com/konqoro/Course_6002x/blob/master/Week1/items.nim#L42-L52 |
| 14:18:23 | * | stisa3 joined #nim |
| 14:20:11 | * | stisa2 quit (Ping timeout: 240 seconds) |
| 14:21:41 | * | adeohluwa quit (Ping timeout: 240 seconds) |
| 14:21:46 | * | planhths joined #nim |
| 14:22:31 | * | federico3 quit (Quit: WeeChat 1.1.1) |
| 14:27:45 | * | federico3 joined #nim |
| 14:28:48 | rokups | by the way i also moved coro.nim from pure folder to arch, but i am not sure it is the right place. it is not a pure module since it depends on importc'ed stuff and some assembly in some cases. it probably should go into impure right? or maybe system? idk. |
| 14:31:02 | cheatfate | rokups, impure modules are modules which requires additional dependencies, your module is uses only system specific functions |
| 14:32:04 | rokups | hmm yeah indeed |
| 14:32:33 | cheatfate | so `pure` is a right place |
| 14:32:33 | * | stisa3 quit (Read error: Connection reset by peer) |
| 14:34:13 | Araq | yup, 'pure' is fine, but 'arch' would be fine too |
| 14:34:23 | Araq | 'impure' is really "requires DLL" |
| 14:34:37 | Araq | os.nim uses the OS quite a bit and is "pure" ;-) |
| 14:36:01 | rokups | isnt "pure" for modules that contain / depend only on nim code and no importc? |
| 14:36:30 | rokups | oh os.nim, yeah it does use importc |
| 14:36:57 | rokups | thing with arch.. idk if we want import arch.coro, or if it even makes sense tbh |
| 14:37:59 | Araq | ah yeah we don't |
| 14:38:22 | * | stisa2 joined #nim |
| 14:40:37 | rokups | another thing, should public api from coro.nim be prefixed with "coro"? like coroRun(), coroSuspend(), coroWait()? imho coro.run() is prettier but due to namespace pollution it probably would cause issues |
| 14:42:38 | * | gokr joined #nim |
| 14:42:45 | * | stisa2 quit (Ping timeout: 260 seconds) |
| 14:43:41 | Araq | no. |
| 14:43:48 | Araq | no prefixes. |
| 14:44:18 | Araq | there is no namespace pollution, no matter how often you guys bring it up. |
| 14:44:33 | * | stisa2 joined #nim |
| 14:46:06 | FromGitter | <krux02> there is still the argument, that a `run()` somewhere alone in the code is not obvious to know where it comes from, where a `coro.run` is much more readable |
| 14:48:39 | rokups | its up to people to do the right thing then. im totally fine with it, i can trust myself to try do a right thing. ;) |
| 14:48:42 | FromGitter | <krux02> a lonely instance of run() could also be overridden and when the override comes from the same file it might be undetected by the compiler |
| 14:49:18 | zevlg | Hmm, got some compilation error I don't understand, here is the code: https://gist.github.com/7d7da46cad41831ab5b2a7d3e2e86cd0 |
| 14:49:43 | zevlg | `getJustFunc' compiles fine, but in `getFunc' where I'm trying to utilize tuples, compilation fails |
| 14:49:50 | FromGitter | <krux02> so no matter what Araq says, I prefer when people don't need to be aware of these things and do the right thing automatically |
| 14:50:02 | zevlg | what is the correct way to implement `getFunc' ? |
| 14:50:52 | FromGitter | <krux02> I would like if there would be an export like * but that does not allow to use the function nakedly |
| 14:50:56 | Araq | rokups: it's fine to document that the module should be imported as 'from coro import nil' |
| 14:51:01 | FromGitter | <krux02> that forces to use explicit package |
| 14:51:43 | Araq | krux02: Nim assumes the client ultimately knows better than the module. |
| 14:52:22 | rokups | krux02 that would surely lead to some confusion. one module imports one way, the other one imports differently.. thats no good. |
| 14:52:28 | Araq | and that's always true, since the module has much less context/information. |
| 14:52:46 | FromGitter | <krux02> yes that is a nice assumption, and generally it does the right thing without being annoying, but there is horrible code out there |
| 14:53:19 | FromGitter | <krux02> rokups: probably |
| 14:53:33 | Araq | yeah I don't care about that. :-) everything not written by me is horrible anyway. |
| 14:53:45 | Araq | and often my own code is too. |
| 14:54:20 | FromGitter | <krux02> I am not claiming I have the perfect solution, but I try that the naive way of doing something is the right way to do it |
| 14:54:33 | FromGitter | <krux02> otherwise it's like building up spike traps |
| 14:56:32 | FromGitter | <krux02> s/naive/naïve/ :P |
| 14:56:59 | Araq | with another export marker everybody and newbies especially would patronize others with their naïve ideas of how to program |
| 14:57:09 | Araq | :P |
| 14:58:15 | FromGitter | <krux02> yes a different export marker might make a solution for this problem possible, but probably it would cause more harm than benefit |
| 14:58:44 | rokups | i think there is enough magic already. language should be getting simpler, not more complex |
| 14:59:00 | rokups | but simple is hard.. |
| 14:59:15 | Araq | zevlg: because your getFunc claims to return (string, proc ...) |
| 14:59:30 | Araq | yet you only return title_fun |
| 15:00:17 | FromGitter | <krux02> we could also go the c++ way of solving things. Junt add a function deep in the standard library that handles things better than the default, and then blame everybody who doesn't use it to be a bad programmer |
| 15:00:18 | zevlg | title_fun is tuple as well, i get this compilation error: Error: type mismatch: got ((string, proc (i: int){.gcsafe, locks: 0.})) but expected '(string, proc (i: int){.closure.})' |
| 15:02:58 | zevlg | compiled with nim 0.16 |
| 15:04:23 | * | libman joined #nim |
| 15:06:05 | * | gokr quit (Ping timeout: 260 seconds) |
| 15:11:04 | Araq | zevlg: annotate your proc types with .nimcall then |
| 15:14:19 | zachcarter | krux02: I just cleaned up the nuklear-nim repo quite a bit |
| 15:15:02 | zevlg | Araq: works, hm, but very non-intuitive .. why `getJustFunc' does not yeild error as well ? |
| 15:15:31 | * | Jesin joined #nim |
| 15:23:59 | chemist69 | zachcarter: that looks very interesting. Do you maybe plan to also make a wrapper that is a bit more high-level? |
| 15:25:01 | zachcarter | chemist69 - it wasn’t on my radar, but it’s something that if I have time or really find the need to do I’ll definitely consider it |
| 15:25:34 | zachcarter | the library isn’t too difficult to use, it’s built to be flexible and allow you to use it with whatever drawing backend you want |
| 15:25:49 | Araq | zevlg: because there is a convertible relation from proc .nimcall to proc .closure but this relation is not lifted to tuples and I don't know if there is PL out there that does that |
| 15:26:44 | chemist69 | zachcarter: I understand. It's just that I get a bit overwhelmed by all the `addr` and `ptr` :P |
| 15:27:21 | zachcarter | ah yeah I see what you mean |
| 15:28:32 | chemist69 | but that's just my complete lack of C knowledge... |
| 15:28:40 | zachcarter | if nuklear remains pretty stable, I’ll give it a go |
| 15:28:53 | zachcarter | I just don’t to have to maintian an abstraction layer on top of a set of bindings |
| 15:30:55 | chemist69 | It's definitely an interesting project, thanks for bringing it to Nim. |
| 15:32:31 | zachcarter | sure thing - I’m going to write a backend now for nim-bgfx for it |
| 15:32:45 | zachcarter | as I plan on using that in my engine |
| 15:34:26 | zachcarter | for now I’m going to include it in my game engine code, if there’s interest to make it its own nimble module in the future I’ll do so - I don’t think anyone else is really using both libraries at the moment but me to my knowledge |
| 15:34:38 | zachcarter | in nim I mean |
| 15:42:59 | * | arnetheduck quit (Ping timeout: 255 seconds) |
| 15:49:29 | * | stisa2 quit (Ping timeout: 260 seconds) |
| 15:52:28 | * | Gonzih quit (Quit: WeeChat 1.6) |
| 15:53:45 | * | Gonzih joined #nim |
| 16:02:00 | rokups | this is a beauty https://github.com/bluenote10/NimData |
| 16:02:35 | * | vlad1777d joined #nim |
| 16:06:24 | * | PMunch quit (Quit: leaving) |
| 16:07:30 | * | yglukhov quit (Remote host closed the connection) |
| 16:08:33 | chemist69 | I agree, its awesome! |
| 16:22:31 | zachcarter | also if there’s any interest - https://github.com/zacharycarter/soloud-nim - are bindings to the soloud audio engine - https://github.com/jarikomppa/soloud |
| 16:27:10 | * | rauss joined #nim |
| 16:27:27 | * | federico3 quit (Quit: WeeChat 1.5) |
| 16:32:39 | * | Vladar quit (Remote host closed the connection) |
| 16:39:36 | * | federico3 joined #nim |
| 16:52:11 | * | Trustable joined #nim |
| 16:52:33 | * | sz0 joined #nim |
| 17:09:20 | * | niv quit (Ping timeout: 240 seconds) |
| 17:09:20 | * | Princess17b29a quit (Ping timeout: 240 seconds) |
| 17:09:20 | * | djellemah quit (Ping timeout: 240 seconds) |
| 17:09:21 | * | yglukhov joined #nim |
| 17:09:33 | * | djellemah joined #nim |
| 17:09:43 | * | Princess17b29a joined #nim |
| 17:11:32 | zachcarter | I’m pretty nimble stupid - I’ve created a nimble package here - https://github.com/zacharycarter/nuklear-nim but I can’t import nuklear_nim in another project, can anyone help me get this correct? |
| 17:11:49 | zachcarter | I’ve added it as a dependency but the import nuklear_nim statement fails |
| 17:12:11 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 17:12:24 | FromGitter | <andreaferretti> are you using nimble to compile that other project or just nim? |
| 17:12:41 | FromGitter | <andreaferretti> you need to change `nim c ...` to `nimble c ...` |
| 17:12:52 | FromGitter | <andreaferretti> nim is not aware of dependencies, nimble is |
| 17:12:58 | zachcarter | hrm let me see |
| 17:13:43 | zachcarter | even with nimble c it fails |
| 17:13:49 | * | Arrrr joined #nim |
| 17:13:49 | * | Arrrr quit (Changing host) |
| 17:13:49 | * | Arrrr joined #nim |
| 17:14:12 | zachcarter | cannot open ‘nuklear_nim’ |
| 17:16:11 | FromGitter | <andreaferretti> can you post the nimble file of your project? |
| 17:16:36 | FromGitter | <andreaferretti> by the way, I don't see nuklear in the package list |
| 17:16:37 | zachcarter | ah I see |
| 17:16:37 | FromGitter | <andreaferretti> https://github.com/nim-lang/packages/blob/master/packages.json |
| 17:16:41 | zachcarter | yeah it’s not |
| 17:16:46 | zachcarter | I haven’t published it to nimble yet |
| 17:16:55 | FromGitter | <andreaferretti> well, that is why :-) |
| 17:16:55 | zachcarter | I think from reading the nimble docu - my nim file needs to be in the root of my project |
| 17:17:07 | * | krux02 joined #nim |
| 17:17:09 | zachcarter | oh no I’ve linked to it in my nimble file via the git url |
| 17:17:14 | zachcarter | which works apparently |
| 17:17:36 | zachcarter | it definitely installs the package it just doesn’t import it and that’s apparently my fault for not putting nuklear_nim.nim in the nuklear_nim root dir, fixing tha tnow |
| 17:18:17 | dom96 | You might want to consider naming it simply "nuklear" |
| 17:18:32 | * | nsf quit (Quit: WeeChat 1.7) |
| 17:18:52 | zachcarter | thanks dom96 I’ll do that |
| 17:24:01 | krux02 | zachcarter: https://github.com/vurtun/nuklear/blob/master/nuklear.h#L390 |
| 17:24:18 | krux02 | seems like you can get rid of all the nk_types |
| 17:24:35 | zachcarter | yeah definitely |
| 17:24:47 | krux02 | and replace them with the sized nim types |
| 17:25:28 | krux02 | it would be a few search and replace operations |
| 17:25:51 | zachcarter | I’ll do that |
| 17:26:33 | krux02 | cool |
| 17:36:34 | zachcarter | krux02: done |
| 17:36:46 | krux02 | cool |
| 17:38:52 | krux02 | and the dummy_arrays can go away |
| 17:39:05 | krux02 | they are for internal checking I guess |
| 17:47:11 | * | planhths quit (Ping timeout: 240 seconds) |
| 18:01:30 | zachcarter | okay I’ll get rid of those |
| 18:01:55 | * | gokr joined #nim |
| 18:06:17 | FromGitter | <Varriount> zachcarter: How go things? |
| 18:06:27 | zachcarter | good thanks, you Varriount? |
| 18:06:52 | FromGitter | <Varriount> Studying German. Currently doing vocab work |
| 18:07:11 | zachcarter | nice :) |
| 18:07:23 | zachcarter | I’m writing a nim-bgfx backend for the nuklear stuff |
| 18:07:29 | zachcarter | for the engine |
| 18:07:46 | zachcarter | so I can start building an editor |
| 18:09:51 | FromGitter | <Varriount> Nuklear is the immediate GUI library, right? |
| 18:10:03 | krux02 | yes it is |
| 18:10:11 | krux02 | it is one immediate mode gui library |
| 18:10:13 | krux02 | there are more |
| 18:10:17 | krux02 | for example imgui |
| 18:10:40 | zachcarter | mmhmm |
| 18:10:49 | krux02 | bit that one is afaik the only one with a nim wrapper (now) |
| 18:11:13 | zachcarter | yeah imgui is C++ I believe |
| 18:11:15 | krux02 | s/bit/but/ |
| 18:11:19 | zachcarter | Nukelar seemed like a good target since it was ansi-c |
| 18:11:24 | krux02 | yes simple c++, but c++ |
| 18:14:11 | FromGitter | <Varriount> "Seemed" referring to the problems you have had wrapping it? |
| 18:15:16 | zachcarter | haha well it was definitely more challenging than I had hoped at first, but I mean all the difficulties I had were learning experiences, and good ones at that |
| 18:15:55 | zachcarter | I started with Nuklear, and then when I failed hard and fast I eventually tried imgui but failed hard and fast there too, at that point I had to decide which lib I wanted more |
| 18:16:53 | zachcarter | Nuklear won, mostly because I was trying to bind to - https://github.com/Extrawurst/cimgui - and this seemed like a very convoluted way of getting imgui working |
| 18:17:47 | * | couven92 quit (Quit: Client disconnecting) |
| 18:18:15 | * | Matthias247 joined #nim |
| 18:19:38 | krux02 | I did not have real experience with any of those libraries, but I think they will be used to do debug drawing for my application only |
| 18:19:45 | krux02 | I want to use it |
| 18:20:09 | krux02 | can you tell what was the hardest part to get working? |
| 18:20:25 | * | nsf joined #nim |
| 18:21:09 | zachcarter | imgui? |
| 18:21:10 | krux02 | I remember when I once made a wrapper for glfw in go, it was tough to get all the callbacks working, because unline Nim, go did not allow to have just C style functions, so I had to trick a little bit |
| 18:21:17 | krux02 | sorry not imgui |
| 18:21:18 | zachcarter | or nuklear? |
| 18:21:19 | krux02 | nuklear |
| 18:21:27 | zachcarter | you mean to get the bindings working? |
| 18:21:30 | krux02 | yes |
| 18:22:28 | zachcarter | well the first major roadblock I encountered was the fact that I didn’t have my types aligned properly with nuklears, some of my types had additional fields that the Nuklear types didn’t have |
| 18:23:10 | zachcarter | so when Nuklear was reading memory from properties, it was sometimes reading into other properties |
| 18:23:15 | krux02 | I wonder how that can happen |
| 18:23:27 | zachcarter | I didn’t figure this out until I did a sizeof(nuklear context) in C and Nim |
| 18:23:41 | zachcarter | well it happened because Nukelar does those funky conditional defines |
| 18:23:59 | zachcarter | where certain fields don’t get defined unless you have a certain preprocessor definition |
| 18:24:09 | zachcarter | so when I ran c2nim it picked up all these fields |
| 18:24:37 | zachcarter | I guess I should step back a bit too - I didn’t generate the bindings straight from the header there was way too much preprocessor magic to do tht |
| 18:25:08 | zachcarter | so I ran the gcc/clang (I assume it’s clang on osx) preprocessor on the header file first, that was step number one |
| 18:25:50 | krux02 | yes normally that is just way too much output |
| 18:25:56 | zachcarter | then I had to do a lot of manual manipuliation to the generated nim code - mostly fixing enumerations that were using bitwise flags, and nesting types within eachother, removing forward declarations, etc |
| 18:26:16 | zachcarter | sorry not nesting types within each other |
| 18:26:22 | zachcarter | but nesting types within the same type statement |
| 18:27:02 | zachcarter | once all that was done that’s when the bindings started working and I was able to call the nuklear code, then It was a matter of figuring that size thing, and also figuring out that all my enums had to have the size specifier pragma on them |
| 18:27:16 | zachcarter | from there it was just writing all the glfw3 / opengl code and other than that it was pretty straightforward |
| 18:27:19 | FromGitter | <Varriount> Die |
| 18:27:43 | krux02 | Varriount? |
| 18:27:44 | FromGitter | <Varriount> Sorry, my phone feel |
| 18:27:49 | FromGitter | <Varriount> *fell |
| 18:28:23 | zachcarter | thought you switched to German mode on us, or got really angry at something :P |
| 18:28:58 | FromGitter | <Varriount> Are you still using that backend abstraction library? |
| 18:29:04 | zachcarter | I am |
| 18:29:45 | FromGitter | <Varriount> Cool |
| 18:31:11 | krux02 | I still keep my opengl shader binding code generator up and alive |
| 18:31:33 | krux02 | it just requires the operating system to have ok'ish support for Opengl. |
| 19:06:18 | * | def-pri-pub joined #nim |
| 19:18:45 | * | Vladar joined #nim |
| 19:28:53 | * | chemist69 quit (Ping timeout: 255 seconds) |
| 19:33:31 | * | chemist69 joined #nim |
| 19:34:17 | * | sz0 quit (Quit: Connection closed for inactivity) |
| 20:26:05 | * | handlex joined #nim |
| 20:31:28 | shashlick | does libui work with mingw or is VCC required? |
| 20:35:29 | * | handlex quit (Ping timeout: 255 seconds) |
| 20:36:31 | Araq | shashlick: recent mingw might work, but requires a patch, for now VCC is required |
| 20:37:46 | shashlick | thanks - I'll try it out |
| 20:53:58 | * | djellemah_ quit (Ping timeout: 240 seconds) |
| 20:57:21 | bbl | hmmh |
| 20:57:51 | bbl | ``while true: echo GC_getStatistics()`` leaks memory |
| 20:58:30 | Araq | do you even know how to detect a leak? |
| 20:59:15 | bbl | run that and check htop |
| 21:00:17 | * | PMunch joined #nim |
| 21:00:38 | Araq | does it grow beyond e.g. 16MB? |
| 21:00:45 | bbl | It does that only with -d:release |
| 21:01:23 | bbl | 1 gig now |
| 21:02:05 | bbl | ~40mb per second |
| 21:02:10 | * | rokups quit (Quit: Connection closed for inactivity) |
| 21:03:47 | Araq | ok, that is a leak :-) |
| 21:03:53 | bbl | indeed |
| 21:04:07 | Araq | use nim devel |
| 21:04:13 | Araq | and tell me the OS |
| 21:04:18 | bbl | didn't need valgrind to find that |
| 21:04:28 | bbl | linux and latest master |
| 21:04:34 | bbl | sec with the devel |
| 21:04:37 | * | Arrrr quit (Quit: Leaving.) |
| 21:04:51 | bbl | it was devel |
| 21:04:58 | bbl | same happened with 15.0 |
| 21:07:34 | Araq | I wonder if GC_enable() doesn't enable the GC again properly |
| 21:07:51 | * | krux02 quit (Ping timeout: 260 seconds) |
| 21:10:02 | Araq | oh wait |
| 21:10:13 | Araq | it disables it, runs, enables it |
| 21:10:23 | Araq | but your loop does nothing else, hence the leak :-) |
| 21:10:42 | bbl | yeah it's quite niche situation |
| 21:10:44 | Araq | so ... only fails for your toy program :P |
| 21:10:50 | bbl | I just wanted to check the output of that function :D |
| 21:10:51 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 21:11:30 | Araq | still we should fix it, that GC_disable/enable pair shouldn't be necessary at all. |
| 21:13:45 | bbl | Seems like it only stops leaking if I access a variable outside of that while's scope |
| 21:16:41 | Araq | no, you need to allocate something so the GC has a chance to run |
| 21:16:50 | Araq | the GC runs in 'new' et al |
| 21:20:07 | * | krux02 joined #nim |
| 21:25:36 | * | Vladar quit (Quit: Leaving) |
| 21:41:35 | * | UxerUospr joined #nim |
| 21:50:20 | shashlick | docopt-0.6.4\docopt.nim(569, 6) Warning: 'docopt_exc' is not GC-safe as it calls 'fix' [GcUnsafe2] |
| 21:50:25 | shashlick | docopt-0.6.4\docopt.nim(602, 6) Warning: 'docopt' is not GC-safe as it calls 'docopt_exc' [GcUnsafe2] |
| 21:50:53 | shashlick | opening an issue against docopt |
| 22:03:14 | * | gokr quit (Ping timeout: 255 seconds) |
| 22:21:43 | * | Salewski joined #nim |
| 22:22:55 | Salewski | 14:15:48 FromGitter <konqoro> @Salewski something like this? https://github.com/konqoro/Course_6002x/blob/master/Week1/items.nim#L42-L52 |
| 22:23:33 | Salewski | Thanks konqoro, but I think that is not what I need. But Rosetta has it :-) |
| 22:23:50 | Salewski | https://rosettacode.org/wiki/Combinations#Nim |
| 22:23:59 | Salewski | Bye. |
| 22:28:17 | Salewski | (Well, at least for integers, I still have to modify it to arbitrary array elements...) |
| 22:29:33 | * | nsf quit (Quit: WeeChat 1.7) |
| 22:49:33 | * | Salewski left #nim (#nim) |
| 22:59:46 | * | krux02 quit (Quit: Leaving) |
| 23:05:26 | * | zachcarter quit (Quit: zachcarter) |
| 23:13:58 | * | Trustable quit (Remote host closed the connection) |
| 23:14:49 | * | reactormonk quit (Ping timeout: 240 seconds) |
| 23:15:58 | * | reactormonk joined #nim |
| 23:17:31 | PMunch | Found this talk pretty interesting: https://www.youtube.com/watch?v=wf-BqAjZb8M |
| 23:17:39 | * | ftsf joined #nim |
| 23:17:43 | PMunch | Especially the part from 23:38 |
| 23:18:02 | PMunch | Directly applicable to Nim as well, with c2nim and all |
| 23:28:30 | rauss | I'd like to understand this better. Can anyone explain why this doesn't work?: |
| 23:28:36 | rauss | `type foo = tuple[ a, b: uint8 ]; var bar: foo = ( 2, 4 )` |
| 23:28:50 | rauss | I don't understand why nim doesn't try to cast the ints as uint8s. |
| 23:29:11 | PMunch | Nim doesn't auto-cast to lower precision |
| 23:29:39 | PMunch | You can write a simple converter |
| 23:29:41 | rauss | Even though the ints are less than 256? |
| 23:29:46 | PMunch | Yup |
| 23:29:53 | PMunch | They are ints none the less |
| 23:30:01 | rauss | PMunch: Okay thanks |
| 23:31:12 | PMunch | If you write a converter: "converter toUint8(x: int): uint8 = x.uint8" |
| 23:31:30 | PMunch | Then it will use that converter to automatically cast ints to uint8 |
| 23:34:56 | rauss | I didn't know about converters, however that did not work |
| 23:37:49 | Araq | because the convertible conversion is not lifted to tuples. |
| 23:37:57 | Araq | because the convertible conversion is not lifted to tuples. |
| 23:37:59 | Araq | because the convertible conversion is not lifted to tuples. |
| 23:38:02 | Araq | because the convertible conversion is not lifted to tuples. |
| 23:38:04 | Araq | because the convertible conversion is not lifted to tuples. |
| 23:38:07 | Araq | because the convertible conversion is not lifted to tuples. |
| 23:38:36 | PMunch | Was that intentional Araq? :P |
| 23:38:41 | Araq | why should I be the only one here who feels like a brainless echo |
| 23:39:15 | PMunch | Sorry, haven't heard about that before.. |
| 23:40:22 | PMunch | Why is it not lifted by the way? |
| 23:40:24 | * | UxerUospr quit (Quit: Lost terminal) |
| 23:41:25 | Araq | because it's questionable language design. |
| 23:41:45 | Araq | let x = (2, 4) # int*int |
| 23:42:06 | Araq | let bar: foo = (2, 4) # uint8*uint8 |
| 23:42:13 | Araq | let bar = x # allowed? |
| 23:43:45 | Araq | if you disallow that, you don't have one tuple type constructor in the language, but two. |
| 23:44:40 | Araq | and internally (2, 4) has the type tuple_constructor[...] and 'x' has the type tuple_value[...] |
| 23:46:04 | rauss | Thanks for the explanation. |
| 23:46:23 | PMunch | Ah, that makes sense. Thanks again for explaining all of Nims design choices |
| 23:46:29 | PMunch | It's really interesting :) |
| 23:47:12 | Araq | if you do allow 'let bar: foo = x' (where is not of type 'bar') to keep the type system simple, you then have to also allow that in nestings of arrays and seqs etc |
| 23:47:34 | Araq | that might be conceptually simple, but it surely is a pita to implement |
| 23:49:23 | PMunch | I would imagine |
| 23:50:05 | rauss | Well on that note, why does the colors module use range[0..255] instead of uint8? |
| 23:50:18 | rauss | Dealing with that is why I ran into this |
| 23:50:31 | Araq | that said, that part of the language is a pita and we should at least have a stdlib macro to mitigate the pain |
| 23:52:39 | rauss | Referring to the rgb proc: https://github.com/nim-lang/Nim/blob/master/lib/pure/colors.nim#L408 |
| 23:57:46 | Araq | rauss: because colors need saturated arithmetic and Nim keeps u8+(int literal) as u8, it wouldn't convert to 'int' |
| 23:58:03 | Araq | so it felt better to model it as a range instead |
| 23:58:18 | Araq | not sure I would do it this way again, but that has been the reasoning |
| 23:59:19 | rauss | Araq: Would the same need be met by `range[0.uint8..255.uint8]`? Even though that's redundant |