| 00:02:53 | * | brson quit (Ping timeout: 240 seconds) |
| 00:08:03 | MFlamer | Araq: why are TNimNode and TNimType needed in the generated code? |
| 00:10:34 | BitPuffin | is there an infinite integer type? |
| 00:10:42 | BitPuffin | "infinite" |
| 00:11:33 | BitPuffin | BigInt |
| 00:14:13 | MFlamer | Araq: I see if I compile with --checks:off they are not necessary, so obviously for runtime checks |
| 00:16:57 | MFlamer | so, nevermind on that q |
| 00:20:49 | Varriount | BitPuffin, as of yet, no. Though if you manage to wrap GMP, you'll be forever in our good graces. |
| 00:23:24 | BitPuffin | Varriount: meh, I think 2^63 -1 will be enough world sections in each direction :P |
| 00:24:45 | EXetoC | are you sure? |
| 00:27:59 | BitPuffin | EXetoC: lol fairly (I know that you are joking) if one section is 1km^2 and it takes 10 minutes to walk 1km then you'd have to walk for 92233720368547758070 minutes to crash the game |
| 00:32:02 | * | jimmt joined #nimrod |
| 00:32:12 | BitPuffin | which is ~112089590725665678.2 months |
| 00:32:27 | EXetoC | yeah that's a decent limit |
| 00:33:54 | BitPuffin | which is ~9340799227138807 years |
| 00:34:09 | BitPuffin | it's probably gonna be fine lol |
| 00:35:09 | * | jimmjenn quit (Ping timeout: 246 seconds) |
| 00:35:17 | BitPuffin | and most players will probably not walk in a straight line either |
| 00:35:44 | BitPuffin | and if they walk diagonally that number increases by sqrt(2) :P |
| 00:36:09 | EXetoC | :E |
| 00:36:44 | EXetoC | assaultcube decided that it was a feature rather than a bug |
| 00:38:01 | EXetoC | ok that's not the same thing |
| 00:39:24 | EXetoC | they don't normalize the movement direction, so you basically end up holding two movement keys all the time as that means you travel faster. it's kinda stupid |
| 00:39:47 | BitPuffin | ah |
| 00:39:49 | BitPuffin | that's retarded |
| 00:41:32 | Varriount | BitPuffin, Or you could just use another integer |
| 00:41:47 | BitPuffin | Varriount: what do you mean? |
| 00:42:21 | Varriount | Well, for example, if you had a grid |
| 00:42:40 | Varriount | *2d grid |
| 00:43:38 | Varriount | you would store coordinates as [(xCoord,xRegion),(yCoord,yRegion)] |
| 00:44:18 | Varriount | It's not unlimited, but close enough. |
| 00:44:49 | BitPuffin | Varriount: I don't see the difference |
| 00:45:16 | BitPuffin | Varriount: I was already talking about sections, which is basically the grid squares, and they are indexed by a 64bit integer |
| 00:45:51 | BitPuffin | so a section is indexed by sections[xregion][yregion] |
| 00:46:00 | BitPuffin | and you are in one of these regions |
| 00:46:14 | BitPuffin | so your position will probably be relative to the center of the region |
| 00:46:30 | Varriount | BitPuffin, if you want to expand the range, all you have to do is add another parent region |
| 00:46:44 | BitPuffin | oooooh |
| 00:46:47 | BitPuffin | you mean like that |
| 00:47:04 | BitPuffin | Varriount: don't you think that 9340799227138807 years of walking time is enough though? |
| 00:47:24 | Varriount | BitPuffin, not when we have memory editors. :D |
| 00:47:39 | * | jimmt is now known as jennjimm |
| 00:47:50 | BitPuffin | well if people are using memory editors they are gonna crash the game anyway ;) |
| 00:47:57 | Varriount | True. |
| 00:48:19 | BitPuffin | however one could make it infinite somehow with a linked list or something like that |
| 00:48:25 | BitPuffin | that you traverse |
| 00:48:30 | BitPuffin | but that could go south |
| 00:49:16 | Varriount | BitPuffin, what do you think BigNums are? |
| 00:49:29 | BitPuffin | Varriount: cool |
| 00:49:58 | Varriount | Although, a linked list is a rather simplistic one that isn't *quite* infinite |
| 00:50:21 | BitPuffin | well some kind of list at least |
| 00:50:27 | BitPuffin | that isn't indexed by numbers |
| 00:50:49 | Varriount | http://en.wikipedia.org/wiki/Bignum#Implementation_issues |
| 00:52:22 | Varriount | BitPuffin, also http://www.laurentluce.com/posts/python-integer-objects-implementation/ |
| 00:52:39 | Varriount | Python's ints are technically bignums by default. |
| 00:55:30 | Varriount | I wish they would teach things like this in CS classes. :( |
| 01:02:55 | EXetoC | meep |
| 01:03:29 | BitPuffin | Varriount: gotta take a look at that some day |
| 01:03:32 | BitPuffin | EXetoC: moop |
| 01:05:05 | BitPuffin | EXetoC: just as I am gonna use glfw :P |
| 01:06:33 | BitPuffin | EXetoC: glfw was the cool one right? not wrapper |
| 01:07:15 | OrionPKM | glfw doesnt do much but give you a window |
| 01:07:29 | EXetoC | nim-glfw |
| 01:09:23 | EXetoC | OrionPKM: yeah but I thought it needed some default args :p |
| 01:09:31 | BitPuffin | uh |
| 01:09:33 | BitPuffin | what's the thing again |
| 01:09:35 | BitPuffin | when debug? |
| 01:09:39 | BitPuffin | when defined(debug) ? |
| 01:10:10 | OrionPKM | you should look at horde3$ |
| 01:10:12 | OrionPKM | 3d |
| 01:10:31 | BitPuffin | OrionPKM: no I'm writing my own rendering stuffs |
| 01:10:46 | OrionPKM | what for?:p |
| 01:11:16 | BitPuffin | OrionPKM: my game |
| 01:13:16 | OrionPKM | Idk. as someone who has reinvented the wheel a lot, I think you're better off using an existing engine |
| 01:13:22 | EXetoC | I see a single use of "when debug" in the nimrod dir |
| 01:14:09 | * | hoverbear quit (Quit: Textual IRC Client: www.textualapp.com) |
| 01:14:37 | EXetoC | OrionPKM: depends on what the goal is |
| 01:14:47 | EXetoC | but I guess you can learn plenty of stuff by going in any direction |
| 01:16:29 | OrionPKM | if the goal is to learn graphics, use glfw. if the goal is to make it finished product, use an engine |
| 01:16:40 | * | MFlamer quit (Ping timeout: 245 seconds) |
| 01:18:33 | OrionPKM | or if your goal is to make a sweet game engine in nimrod, then by all means use glfw :) |
| 01:19:00 | EXetoC | hell yeah |
| 01:20:03 | BitPuffin | wtf why can't I import devel/logging |
| 01:20:12 | * | Demos joined #nimrod |
| 01:20:57 | EXetoC | is the root dir even in the path? |
| 01:21:06 | EXetoC | because it's in the same dir as 'lib' |
| 01:21:19 | BitPuffin | dunno this is the arch pkg |
| 01:21:25 | BitPuffin | aur |
| 01:21:28 | BitPuffin | * |
| 01:21:40 | BitPuffin | but maybe I should just ditch that anyway |
| 01:21:43 | BitPuffin | causes so much pain |
| 01:22:49 | OrionPKM | Varriount if you want to start off the ST plugin repo, go ahead, otherwise i'd just start from scratch since I dont want to base it off of the existing ST plugin |
| 01:22:56 | OrionPKM | I'll port over my added functionality |
| 01:23:26 | BitPuffin | OrionPKM: I don't like working with existing engines |
| 01:23:33 | BitPuffin | OrionPKM: however horde3d is pretty good |
| 01:23:39 | BitPuffin | but it's not that active |
| 01:23:55 | OrionPKM | no, it's not.. but afaik it's a solid foundation |
| 01:24:18 | BitPuffin | plus I'm a graphics guy |
| 01:24:27 | OrionPKM | https://github.com/attilaz/horde3d-x/tree/gles2_d3d11 |
| 01:24:28 | BitPuffin | so I like doing that dirty work |
| 01:24:30 | EXetoC | BitPuffin: I mean, it's probably not even installed, if you look at nimrod's root dir |
| 01:24:34 | OrionPKM | mmk |
| 01:24:38 | EXetoC | where lib and devel is in the same dir |
| 01:24:48 | BitPuffin | EXetoC: yeah I don't care, I'm gonna get rid of the aur version right away anyway |
| 01:25:12 | BitPuffin | then we'll see :D |
| 01:25:24 | EXetoC | no I don't think that matters |
| 01:25:44 | Demos | horde3d looks just OK, not great. I dun think there are any really good FOSS graphics engines |
| 01:26:11 | BitPuffin | EXetoC: well it matters for my mood |
| 01:26:15 | BitPuffin | the aur version is a pain |
| 01:26:27 | BitPuffin | because it wants to download the full repo with every update etc |
| 01:26:51 | EXetoC | so I guess you have to re-distribute that module yourself for now |
| 01:26:56 | EXetoC | yeah that sucks |
| 01:27:03 | BitPuffin | yeah I guess |
| 01:27:08 | BitPuffin | I'll just copy it |
| 01:28:42 | BitPuffin | when debug didn't work |
| 01:28:45 | BitPuffin | hmm |
| 01:29:54 | EXetoC | Demos: OGRE? but I don't know if they're improving it much these days |
| 01:30:32 | Demos | OGRE is not what I would call "clean" |
| 01:30:47 | BitPuffin | ogre sucks |
| 01:30:56 | OrionPKM | Demos it's not about the demos |
| 01:31:00 | OrionPKM | it's about the artwork |
| 01:31:03 | BitPuffin | irrlicht is pretty okay, as long as you wanna extend it |
| 01:31:08 | OrionPKM | and how well structured the engine is |
| 01:42:40 | * | ics joined #nimrod |
| 01:45:44 | * | DAddYE_ quit (Remote host closed the connection) |
| 01:46:17 | * | DAddYE joined #nimrod |
| 01:50:18 | * | DAddYE_ joined #nimrod |
| 01:50:29 | * | DAddYE quit (Ping timeout: 248 seconds) |
| 01:53:36 | * | mflamer joined #nimrod |
| 01:53:51 | EXetoC | it appears to me that e-books are priced in a ridiculous manner |
| 01:54:45 | * | DAddYE_ quit (Ping timeout: 246 seconds) |
| 01:55:16 | BitPuffin | EXetoC: hm |
| 01:55:25 | BitPuffin | Error: unhandled exception: unknown error [EGLFW] |
| 01:55:30 | BitPuffin | Error: execution of an external program failed |
| 01:56:12 | BitPuffin | EXetoC: in getPrimaryMonitor |
| 01:56:19 | EXetoC | :o |
| 01:56:36 | BitPuffin | ah |
| 01:56:40 | BitPuffin | glfw.init() :P |
| 01:56:49 | BitPuffin | that wasn't in your example!! |
| 01:58:19 | BitPuffin | EXetoC: shouldn't THints be exported? |
| 01:58:49 | EXetoC | making changes now |
| 02:01:52 | BitPuffin | EXetoC: any chance you know if I can check that the context creation was successful |
| 02:01:58 | BitPuffin | like the correct GL version loaded etc |
| 02:04:38 | Demos | glfwGetError or somesuch |
| 02:04:50 | Demos | it will fail if it can not load the hinted context |
| 02:06:03 | BitPuffin | ah so if it does get created it initialized successfully? |
| 02:06:30 | EXetoC | yes |
| 02:06:33 | EXetoC | changes pushed |
| 02:07:30 | Demos | ah sorry, pass a void(*)(int, const char*) to glfwSetErrorCallback |
| 02:07:37 | Demos | it will be called when there is an error |
| 02:08:10 | BitPuffin | doesn't EXetoC's lib already do that? |
| 02:08:11 | Demos | from there you can throw a nimrod exception I guess |
| 02:08:12 | BitPuffin | didn't check |
| 02:09:15 | Demos | you should likely check the return value of glfwInit |
| 02:10:04 | EXetoC | yup doing that |
| 02:10:06 | Demos | yeah no idea how much error code -> exception stuff EXetoC does, I have only used glfw from c++ |
| 02:10:23 | BitPuffin | yeah I used glfw in C/C++ and D |
| 02:10:31 | Demos | if you ask for an openGL version that glfw can not make than it should fail and error |
| 02:10:31 | BitPuffin | it's a bit different with EXetoC's lib though :) |
| 02:10:41 | BitPuffin | I did ask for a version |
| 02:10:53 | EXetoC | Demos: actually, you should throw only after said callback has returned, but yeah |
| 02:11:14 | Demos | well one could throw from the callback (maybe) |
| 02:11:43 | EXetoC | I'm trying to be safe in this regard |
| 02:12:29 | Demos | yeah throwing from the callback may cause the exception to propagate into the C code and "bad things" could happen |
| 02:13:58 | EXetoC | right |
| 02:19:34 | EXetoC | BitPuffin: I tried to make it really convenient, but newWnd is obviously not always the first function to be called |
| 02:19:37 | EXetoC | is it working now? |
| 02:20:11 | BitPuffin | EXetoC: Is what working? I think it was already working lol |
| 02:20:13 | BitPuffin | :P |
| 02:20:57 | EXetoC | eh nevermind |
| 02:22:09 | BitPuffin | EXetoC: why is sampleRate asserted to be <= 192000 ? |
| 02:24:18 | BitPuffin | in nim-ao? |
| 02:25:02 | EXetoC | is that ever exceeded? |
| 02:26:26 | EXetoC | whatever, I'll remove it |
| 02:26:56 | BitPuffin | EXetoC: 320 is not an uncommon samplerate |
| 02:27:00 | BitPuffin | there is also 500 |
| 02:27:04 | BitPuffin | never seen that though |
| 02:27:42 | BitPuffin | http://en.wikipedia.org/wiki/Vorbis#Technical_details |
| 02:30:12 | EXetoC | that's not the same thing is it? but anyway |
| 02:32:55 | BitPuffin | oh wait |
| 02:32:58 | BitPuffin | samplerate and bitrate |
| 02:33:01 | BitPuffin | no that's not the same |
| 02:33:30 | BitPuffin | EXetoC: do you know if there is any limit on how many devices one can create? |
| 02:34:26 | BitPuffin | yeah there is nothing higher than 192 afaik for sample rates |
| 02:34:29 | EXetoC | not that I can recall. it's probably a really high platform-dependent limit, if any |
| 02:34:54 | BitPuffin | because my environment sounds is recorded in 96k |
| 02:35:03 | BitPuffin | and I was thinking maybe I'd export the music in 192 |
| 02:35:06 | BitPuffin | or maybe not |
| 02:35:14 | BitPuffin | Maybe I should keep it all in 96 |
| 02:36:05 | BitPuffin | hot damn 5,644,800 exists |
| 02:36:15 | BitPuffin | Double-Rate DSD, 1-bit Direct Stream Digital at 2x the rate of the SACD. Used in some professional DSD recorders. |
| 02:36:33 | EXetoC | yeah |
| 02:36:49 | BitPuffin | who would use that xD |
| 02:37:16 | fowl | i was writing a bunch of xlib stuff |
| 02:37:32 | fowl | opening windows, etc, really ugly stuff |
| 02:37:41 | fowl | i just deleted it and using glfw instead |
| 02:38:16 | BitPuffin | EXetoC: but why is bitdepth limited to 16 |
| 02:39:33 | BitPuffin | kind of silly to have to use float16 aint it :D |
| 02:40:11 | EXetoC | BitPuffin: I'm not sure if > 44.100 makes sense generally speaking. The nyquist frequency is at the limit of human hearing at that point (~22000 hz) |
| 02:40:38 | EXetoC | BitPuffin: usually shorts are used |
| 02:40:47 | * | brson_ quit (Quit: leaving) |
| 02:41:03 | EXetoC | most sound cards deal with 16 bits |
| 02:41:18 | EXetoC | anyway, I got rid of all those restrictions |
| 02:41:52 | BitPuffin | EXetoC: well you can do either fixed point or floating point |
| 02:42:12 | BitPuffin | yeah I guess you're right |
| 02:43:02 | BitPuffin | but I wanna do float :D |
| 02:43:09 | EXetoC | so you'd pass int16's then. I can't remember if I used float too, but then it's just a matter of doing a conversion |
| 02:43:47 | BitPuffin | maybe there's a restriction in ao too |
| 02:43:48 | BitPuffin | I dunno |
| 02:46:35 | EXetoC | I got this in some old project "let mono = samples.map(proc(x: TR): int16 = int16(x * TR(high(int16)) * 0.05))" |
| 02:46:54 | * | DAddYE joined #nimrod |
| 02:47:15 | EXetoC | and then I convert to stereo simply by inserting each element twice into another sequence, before passing it to the device |
| 02:48:01 | BitPuffin | you mean another channel? |
| 02:50:09 | EXetoC | here's a snippet that doesn't compile, but which demonstrates it https://gist.github.com/EXetoC/26a32d87027186767114 |
| 02:51:15 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 02:53:31 | BitPuffin | pattern? |
| 02:54:05 | EXetoC | still confusing though, but the data for the channels is interleaved. so if 'mono' is the signal, then you insert each successive value twice to have it sound the same on both speakers |
| 02:54:23 | EXetoC | BitPuffin: that's some unrelated stuff |
| 02:55:22 | EXetoC | it's currently just a DAW that lacks a graphical interface. a pattern is just a set of notes that you can put somewhere in the timeline |
| 02:56:01 | BitPuffin | ah |
| 02:57:38 | BitPuffin | EXetoC: what's TR? |
| 02:58:42 | EXetoC | BitPuffin: R stands for Real |
| 02:58:47 | EXetoC | I'm not doing that anymore |
| 02:58:56 | BitPuffin | ah |
| 03:01:12 | * | mflamer quit (Ping timeout: 246 seconds) |
| 03:02:39 | fowl | so whats up newbs |
| 03:03:01 | BitPuffin | newbin |
| 03:05:04 | BitPuffin | uh |
| 03:05:27 | BitPuffin | EXetoC: https://gist.github.com/BitPuffin/7781679 |
| 03:06:04 | * | DAddYE joined #nimrod |
| 03:06:15 | BitPuffin | ah |
| 03:06:17 | * | DAddYE quit (Remote host closed the connection) |
| 03:06:19 | BitPuffin | it doesn't link for me? |
| 03:06:24 | * | DAddYE joined #nimrod |
| 03:06:43 | EXetoC | -l:-lao |
| 03:06:59 | BitPuffin | yup |
| 03:07:30 | BitPuffin | EXetoC: why aren't you making it link automatically? :o |
| 03:08:23 | fowl | you need {.header.} on the functions and {.passl: "-lao".} |
| 03:08:51 | * | Varriount_ joined #nimrod |
| 03:09:59 | BitPuffin | yeah I know |
| 03:10:08 | * | DAddYE_ joined #nimrod |
| 03:10:13 | EXetoC | I probably didn't know about that back then |
| 03:12:02 | BitPuffin | EXetoC: but you wrapped glfw first didn't you? |
| 03:12:02 | EXetoC | fowl: passl doesn't work |
| 03:12:12 | BitPuffin | EXetoC: just set dynlib |
| 03:12:16 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 03:12:16 | * | Varriount quit (Ping timeout: 245 seconds) |
| 03:12:16 | * | Varriount_ is now known as Varriount |
| 03:14:44 | * | xenagi joined #nimrod |
| 03:15:20 | EXetoC | BitPuffin: no I get this then "ERROR: Failed to load plugin /usr/lib/ao/plugins-4/libalsa.so => dlopen() failed" |
| 03:18:50 | * | reactormonk quit (Ping timeout: 245 seconds) |
| 03:19:24 | BitPuffin | ah |
| 03:19:24 | BitPuffin | I get this |
| 03:19:24 | BitPuffin | Error: unhandled exception: Unable to open audio device [EAo] |
| 03:19:24 | EXetoC | that too |
| 03:19:24 | * | mflamer joined #nimrod |
| 03:21:14 | BitPuffin | EXetoC: any idea on why? |
| 03:21:36 | EXetoC | no |
| 03:21:55 | BitPuffin | ( |
| 03:21:58 | BitPuffin | :( |
| 03:25:12 | EXetoC | BitPuffin: http://www.sendspace.com/file/m2wk93 that's the whole example |
| 03:25:25 | EXetoC | but I'm adding a proper one tomorrow |
| 03:26:20 | BitPuffin | cool I'll check it out! |
| 03:26:23 | BitPuffin | But I'm gonna sleep now |
| 03:26:49 | EXetoC | yeah oh shit it's late |
| 03:27:30 | BitPuffin | yeah :/ |
| 03:27:38 | EXetoC | created it back in june apparently |
| 03:27:38 | BitPuffin | I'm really stressed with this project |
| 03:27:41 | BitPuffin | damn it |
| 03:27:44 | BitPuffin | anyways |
| 03:27:45 | EXetoC | ok time to hug the pillow |
| 03:27:46 | BitPuffin | goodnight! |
| 03:27:53 | BitPuffin | Talk to you tomorrow |
| 03:27:54 | EXetoC | yeah, silly deadline :p |
| 03:27:59 | BitPuffin | I'm gonna drool all over the pillow |
| 03:28:09 | BitPuffin | EXetoC: well I don't have much of a choice, the game is very seasonal :P |
| 03:28:17 | EXetoC | will help you with my expert skills |
| 03:28:24 | BitPuffin | cool bro :D |
| 03:28:36 | BitPuffin | night! |
| 03:30:13 | EXetoC | bai |
| 03:33:06 | * | BitPuffin quit (Ping timeout: 245 seconds) |
| 03:57:34 | * | DAddYE_ quit (Remote host closed the connection) |
| 03:58:50 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 04:01:05 | * | ics joined #nimrod |
| 04:01:51 | * | DAddYE joined #nimrod |
| 04:02:24 | * | DAddYE quit (Remote host closed the connection) |
| 04:02:30 | * | DAddYE joined #nimrod |
| 04:03:03 | * | DAddYE quit (Remote host closed the connection) |
| 04:05:36 | * | mflamer quit (Ping timeout: 245 seconds) |
| 04:15:26 | * | mflamer joined #nimrod |
| 04:34:08 | * | xenagi quit (Quit: Leaving) |
| 05:04:01 | * | DAddYE joined #nimrod |
| 05:09:42 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 05:28:44 | * | NimBot joined #nimrod |
| 06:06:25 | * | DAddYE joined #nimrod |
| 06:10:45 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 06:31:26 | * | Varriount_ joined #nimrod |
| 06:34:51 | * | Varriount quit (Ping timeout: 245 seconds) |
| 06:34:51 | * | Varriount_ is now known as Varriount |
| 06:54:51 | * | girvo joined #nimrod |
| 07:48:08 | * | Varriount_ joined #nimrod |
| 07:48:38 | * | girvo quit (Quit: Textual IRC Client: www.textualapp.com) |
| 07:49:53 | * | Varriount quit (Ping timeout: 245 seconds) |
| 07:49:53 | * | Varriount_ is now known as Varriount |
| 07:59:28 | * | Demos quit (Read error: Connection reset by peer) |
| 08:09:58 | * | DAddYE joined #nimrod |
| 08:13:53 | * | jimmt joined #nimrod |
| 08:14:13 | * | DAddYE quit (Ping timeout: 246 seconds) |
| 08:16:58 | * | jennjimm quit (Ping timeout: 260 seconds) |
| 08:17:18 | * | brihat quit (Ping timeout: 245 seconds) |
| 08:22:19 | * | girvo joined #nimrod |
| 08:23:54 | * | girvo left #nimrod (#nimrod) |
| 08:25:59 | * | girvo joined #nimrod |
| 08:34:34 | * | brihat joined #nimrod |
| 09:02:50 | * | noam_ joined #nimrod |
| 09:03:55 | * | Varriount_ joined #nimrod |
| 09:06:10 | * | Varriount quit (Ping timeout: 245 seconds) |
| 09:06:10 | * | Varriount_ is now known as Varriount |
| 09:06:30 | * | dymk joined #nimrod |
| 09:06:50 | * | webskipper quit (Read error: Connection reset by peer) |
| 09:10:15 | * | Araq_bnc joined #nimrod |
| 09:11:15 | * | DAddYE joined #nimrod |
| 09:12:20 | * | noam quit (*.net *.split) |
| 09:12:20 | * | _dymk quit (*.net *.split) |
| 09:12:20 | * | aftershave quit (*.net *.split) |
| 09:12:20 | * | Araq quit (*.net *.split) |
| 09:15:30 | * | DAddYE quit (Ping timeout: 246 seconds) |
| 09:26:00 | * | achim joined #nimrod |
| 09:26:50 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 09:27:15 | * | ics joined #nimrod |
| 09:27:15 | * | dirkk0 joined #nimrod |
| 09:29:15 | * | dirkk0 quit (Client Quit) |
| 09:31:35 | * | ics quit (Ping timeout: 240 seconds) |
| 09:47:41 | * | CarpNet joined #nimrod |
| 09:51:01 | * | noam_ quit (Disconnected by services) |
| 09:51:21 | * | noam__ joined #nimrod |
| 09:51:31 | * | noam__ is now known as noam |
| 10:12:42 | * | DAddYE joined #nimrod |
| 10:13:12 | * | Araq_bnc is now known as Araq |
| 10:17:12 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 10:21:42 | * | aftershave joined #nimrod |
| 11:13:49 | * | DAddYE joined #nimrod |
| 11:17:55 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 11:18:46 | * | girvo quit (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 11:47:46 | * | girvo joined #nimrod |
| 11:47:52 | * | faassen joined #nimrod |
| 12:02:16 | * | girvo quit (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 12:02:34 | * | BitPuffin joined #nimrod |
| 12:02:50 | BitPuffin | good day! |
| 12:02:59 | BitPuffin | EXetoC: did you figure out the noodle doodle? |
| 12:03:34 | dom96 | hello |
| 12:03:47 | BitPuffin | hey dom96! |
| 12:05:34 | dom96 | hey BitPuffin! |
| 12:05:46 | EXetoC | BitPuffin: ? |
| 12:07:51 | BitPuffin | EXetoC: the ao exception |
| 12:07:57 | BitPuffin | dom96: sup? :) |
| 12:08:32 | dom96 | Stayed off school today :P |
| 12:09:48 | BitPuffin | dom96: sweet xD |
| 12:12:07 | EXetoC | no |
| 12:12:58 | dom96 | BitPuffin: Where is this linagl article!? |
| 12:13:09 | BitPuffin | dom96: I'm behind my schedule ;_; |
| 12:13:14 | BitPuffin | dom96: if I catch up I'll write it |
| 12:13:19 | dom96 | what schedule? |
| 12:13:23 | BitPuffin | for my game |
| 12:15:06 | * | DAddYE joined #nimrod |
| 12:15:26 | dom96 | You're coding it in Nimrod right? |
| 12:15:46 | fowl | we dont use nimrod anymore |
| 12:15:49 | fowl | we all do PHP |
| 12:16:39 | BitPuffin | dom96: yes |
| 12:16:50 | BitPuffin | or actually I decided to go with COBOL |
| 12:19:05 | dom96 | hehe, good good. |
| 12:19:35 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 12:19:54 | BitPuffin | ao_alsa ERROR: Unable to open ALSA device 'default' for playback => No such file or directory |
| 12:19:56 | BitPuffin | fuuu ^ |
| 12:21:51 | * | zahary_ joined #nimrod |
| 12:25:01 | EXetoC | and you're using the default driver? |
| 12:30:54 | BitPuffin | EXetoC: yea |
| 12:31:40 | BitPuffin | EXetoC: https://gist.github.com/BitPuffin/7786741 |
| 12:32:36 | BitPuffin | proc newDevice*(fmt: TSampleFmt, driver = TDriver.default): PDevice = |
| 12:33:01 | EXetoC | and you're not using pulse? do any other applications fail in this regard? |
| 12:33:42 | BitPuffin | EXetoC: no I'm not using pulse |
| 12:34:43 | EXetoC | renoise for example doesn't play nice with my alsa and I have no idea what I'm doing wrong, but I haven't had a problem with libao yet |
| 12:34:43 | BitPuffin | and vlc for example works |
| 12:35:35 | EXetoC | what about aplay? if you got some wavs laying around |
| 12:37:00 | BitPuffin | https://gist.github.com/BitPuffin/7786807 |
| 12:37:02 | BitPuffin | interesting |
| 12:39:02 | dom96 | Maybe try changing the default driver in /etc/libao.conf |
| 12:39:28 | BitPuffin | well |
| 12:39:30 | dom96 | Perhaps OSS. |
| 12:39:34 | BitPuffin | come on |
| 12:39:37 | BitPuffin | not oss :P |
| 12:39:52 | dom96 | lol |
| 12:42:16 | BitPuffin | it's not the 1500s |
| 12:42:43 | EXetoC | I don't know if jack needs to be running. does jackd work? |
| 12:43:46 | EXetoC | jack is mentioned, so I'm guessing that it's installed. I don't know what other applications do. maybe they use fallbacks |
| 12:44:19 | BitPuffin | don't think jack needs to be running |
| 12:45:05 | EXetoC | I don't know then, but something is wrong if aplay doesn't work |
| 12:46:33 | BitPuffin | hot damn jack_control start and now the output is this |
| 12:46:58 | BitPuffin | DEBUG Creating audio device |
| 12:47:00 | BitPuffin | jack_client_new: deprecated |
| 12:47:05 | BitPuffin | DEBUG Destroying audio device |
| 12:47:09 | BitPuffin | as it should |
| 12:50:25 | EXetoC | ok |
| 12:53:21 | BitPuffin | but I don't know if that will actually output sound |
| 12:54:05 | EXetoC | try the code I sent you before |
| 12:54:36 | BitPuffin | EXetoC: don't think i still have the tab |
| 12:55:40 | EXetoC | the url is still available. http://www.sendspace.com/file/m2wk93 |
| 12:55:46 | EXetoC | nimrod c -l:-lao -r main.nim |
| 12:56:18 | BitPuffin | EXetoC: removed some jack shits from asoundrc |
| 12:56:22 | BitPuffin | ran alsactl init |
| 12:56:24 | BitPuffin | ran the game |
| 12:56:27 | BitPuffin | nemos problemos |
| 12:56:29 | BitPuffin | with jack started |
| 12:56:41 | BitPuffin | oh right it was a download |
| 12:57:02 | BitPuffin | I'm gonna run your thing just to see if there is any audio |
| 12:58:55 | BitPuffin | EXetoC: it doesn't compile |
| 12:58:59 | EXetoC | :E |
| 12:59:57 | EXetoC | I wonder why |
| 13:00:33 | BitPuffin | EXetoC: because of this https://gist.github.com/BitPuffin/7787084 |
| 13:02:08 | EXetoC | I re-built nimrod yesterday. I don't know if that's why it works for me |
| 13:02:19 | BitPuffin | But I did too |
| 13:02:25 | BitPuffin | you know when I raged about the whole aur thing |
| 13:03:46 | EXetoC | >.> |
| 13:04:11 | EXetoC | and you remembered to pull? |
| 13:04:29 | BitPuffin | well it was a fresh clone even |
| 13:07:50 | EXetoC | will try that |
| 13:09:02 | EXetoC | so the output of 'which nimrod' is correct? |
| 13:10:07 | BitPuffin | yup |
| 13:12:59 | EXetoC | still works for me |
| 13:13:21 | BitPuffin | git pull |
| 13:13:21 | EXetoC | after cloning and then building |
| 13:13:23 | BitPuffin | Already up-to-date. |
| 13:14:01 | EXetoC | 5 modules in the archive, right? |
| 13:14:25 | BitPuffin | yup |
| 13:14:41 | EXetoC | I don't know wth is going on then |
| 13:14:45 | BitPuffin | EXetoC: and we're both using arch linux x86_64? |
| 13:15:03 | EXetoC | yes. I use gcc 4.8.1 |
| 13:15:23 | BitPuffin | gcc --version |
| 13:15:26 | BitPuffin | gcc (GCC) 4.8.2 |
| 13:15:27 | BitPuffin | hmm :P |
| 13:16:20 | * | DAddYE joined #nimrod |
| 13:18:34 | EXetoC | it works when bootstrapping with and without -d:release. I don't know what else to try |
| 13:20:32 | BitPuffin | could it seriously be gcc then? |
| 13:20:34 | * | DAddYE quit (Ping timeout: 246 seconds) |
| 13:20:38 | BitPuffin | EXetoC: update your gcc |
| 13:20:54 | EXetoC | I have |
| 13:20:57 | BitPuffin | hm |
| 13:22:39 | * | Mat2_ joined #nimrod |
| 13:22:54 | * | Mat2_ quit (Client Quit) |
| 13:23:11 | * | Mat2_ joined #nimrod |
| 13:24:31 | EXetoC | do any other projects compile? |
| 13:26:07 | Mat2_ | . |
| 13:26:38 | EXetoC | lo |
| 13:26:45 | Mat2_ | hi all |
| 13:26:50 | BitPuffin | EXetoC: yeah |
| 13:26:53 | BitPuffin | my game compiles |
| 13:27:02 | BitPuffin | linagl |
| 13:27:04 | BitPuffin | nim-ogg |
| 13:27:07 | BitPuffin | nim-vorbis |
| 13:27:09 | BitPuffin | errthin |
| 13:27:21 | * | Mat2_ is now known as Mat3 |
| 13:29:10 | Mat3 | does one know if the standard value for booleans at declaration is true or false (or even undefined) ? |
| 13:30:15 | EXetoC | pretty sure it's false |
| 13:30:21 | EXetoC | everything is initialized by default |
| 13:30:24 | BitPuffin | probably false |
| 13:30:29 | Mat3 | thanks |
| 13:37:46 | EXetoC | is --hint working? if so, then I can't figure out how to use it |
| 13:39:21 | BitPuffin | what's the corret way of doing what i'm trying to do here? |
| 13:39:23 | BitPuffin | var fileptr: ptr TOggVorbisFile = cast[ptr TOggVorbisFile](alloc0(sizeof(TOggVorbisFile))) |
| 13:40:38 | EXetoC | nevermind |
| 13:41:34 | BitPuffin | Araq: almighty memory manager, guide me |
| 13:43:23 | BitPuffin | result = new PAudioFile(file: fileptr) |
| 13:43:26 | BitPuffin | becomes None |
| 13:43:29 | BitPuffin | wtf is none even :P |
| 13:44:11 | fowl | wtf is new, are we in c++ |
| 13:44:25 | BitPuffin | oh wait |
| 13:44:27 | BitPuffin | shouldn't be new |
| 13:44:29 | BitPuffin | lol |
| 13:44:32 | BitPuffin | :D |
| 13:44:42 | BitPuffin | fowl: there is a new keyword though |
| 13:44:53 | fowl | well thats _new_ to me |
| 13:44:57 | EXetoC | it's not just a proc? |
| 13:44:59 | * | NimWolf joined #nimrod |
| 13:45:02 | fowl | ^ |
| 13:45:11 | EXetoC | BitPuffin: depends. is PAudioFile part of ogg? |
| 13:45:33 | BitPuffin | EXetoC: no it's in mah game |
| 13:45:46 | BitPuffin | type |
| 13:45:47 | EXetoC | and I don't think there's anything more convenient than alloc0 + sizeof + cast |
| 13:45:48 | BitPuffin | TAudioFile = object |
| 13:45:50 | BitPuffin | file: ptr TOggVorbisFile |
| 13:45:52 | BitPuffin | PAudioFile = ref TAudioFile |
| 13:46:16 | EXetoC | so "new(result); result.file = ..."? |
| 13:46:41 | fowl | EXetoC, thats oldschool |
| 13:46:55 | fowl | kool kids say result = PAudioFile(file: f) |
| 13:47:11 | EXetoC | forgot about that |
| 13:47:11 | fowl | although, you probably want a destructor to free that ptr |
| 13:47:31 | EXetoC | implicit 'new' |
| 13:49:46 | BitPuffin | fowl: already have one |
| 13:49:54 | BitPuffin | it's why I wrapped it in TAudioFile |
| 13:50:11 | fowl | does that work |
| 13:50:16 | BitPuffin | no idea |
| 13:50:26 | BitPuffin | don't see why it wouldn't |
| 13:50:42 | fowl | because {.destructor.} is for value types leaving scope, not reference types |
| 13:51:00 | fowl | destructor is like c++'s ~ |
| 13:51:48 | fowl | http://build.nimrod-lang.org/docs/manual.html#destructor-pragma |
| 13:54:03 | fowl | wow i didnt know about {.delegator.} or `()` being a valid operator |
| 13:54:12 | fowl | i swear every time i look in the manual i learn new things |
| 13:54:22 | BitPuffin | fowl: it's pretty new |
| 13:54:29 | BitPuffin | it's gonna be added to linagl really soon |
| 13:55:05 | BitPuffin | well I'll keep the destructor thingy |
| 13:55:14 | BitPuffin | but I'll probably call it explicitly |
| 13:55:22 | BitPuffin | maybe it will save my ass one day |
| 13:56:42 | fowl | you know how to finalizer right |
| 13:58:09 | BitPuffin | herp? |
| 13:59:08 | BitPuffin | fowl: there is no such thing in tfm |
| 13:59:46 | fowl | what |
| 13:59:49 | * | Varriount_ joined #nimrod |
| 13:59:51 | EXetoC | finally? |
| 14:00:30 | fowl | BitPuffin, you're right |
| 14:00:37 | fowl | BitPuffin, its probably in the tutorial |
| 14:00:50 | BitPuffin | ahhh |
| 14:00:55 | BitPuffin | yeah I know about finally |
| 14:00:57 | BitPuffin | and except |
| 14:00:59 | BitPuffin | etc |
| 14:01:10 | fowl | BitPuffin, when allocating a ref ty: new(result, free) free is proc(x: PType) = free stuff that you need to here |
| 14:01:11 | BitPuffin | time to lunch |
| 14:01:20 | BitPuffin | at least calling open and close doesn't segfault or anything |
| 14:01:24 | BitPuffin | so that's positive |
| 14:01:28 | fowl | hey |
| 14:01:55 | BitPuffin | fowl: but you just told me to not use new |
| 14:01:58 | BitPuffin | lol |
| 14:02:14 | EXetoC | he meant explicitly |
| 14:02:18 | fowl | BitPuffin, fine then, allocate pointers and dont free them, i dont care |
| 14:02:49 | BitPuffin | fowl: well I'd like to use the stuffs you said |
| 14:02:54 | fowl | you have to use new() if you want to give it a finalizer |
| 14:03:01 | BitPuffin | aha |
| 14:03:03 | BitPuffin | cool |
| 14:03:05 | * | Varriount quit (Ping timeout: 246 seconds) |
| 14:03:06 | * | Varriount_ is now known as Varriount |
| 14:03:36 | BitPuffin | fowl: does it matter if the proc is a destructor? |
| 14:04:16 | fowl | idk |
| 14:05:43 | BitPuffin | ah |
| 14:05:46 | BitPuffin | it has to be a ref |
| 14:06:25 | BitPuffin | you can't set a ref to nil? |
| 14:06:27 | BitPuffin | wtf |
| 14:06:56 | dom96 | you can |
| 14:06:56 | BitPuffin | well that added a sigsegv |
| 14:07:02 | EXetoC | I just tried it. it works |
| 14:07:16 | fowl | ofc |
| 14:07:25 | BitPuffin | new(result, close) |
| 14:07:28 | BitPuffin | result.file = fileptr |
| 14:07:58 | BitPuffin | so result.file is nil? wtf |
| 14:08:48 | EXetoC | yes, initially |
| 14:09:08 | BitPuffin | EXetoC: but I called new on it right before |
| 14:09:11 | EXetoC | it shouldn't be after the assignment if fileptr isn't nil |
| 14:09:24 | BitPuffin | it isn't |
| 14:09:56 | Araq | hi NimWolf, welcome. Nice nick. |
| 14:09:58 | * | Mat3 quit (Quit: Verlassend) |
| 14:10:04 | EXetoC | so what should it initialize to if not nil? |
| 14:10:12 | BitPuffin | https://gist.github.com/BitPuffin/7787980 |
| 14:10:36 | BitPuffin | yes I log excessively |
| 14:11:16 | * | Mat3 joined #nimrod |
| 14:12:41 | BitPuffin | I fail to see how result.file can be new |
| 14:12:43 | BitPuffin | brb lunch |
| 14:12:49 | fowl | BitPuffin, jeez man |
| 14:12:57 | BitPuffin | fowl: jizz man |
| 14:13:06 | fowl | BitPuffin, you initialized a ref ref TAudioFile |
| 14:13:25 | EXetoC | -.- |
| 14:13:33 | Mat3 | what you guys think about the concept of delegate monads for low-level memory access ? |
| 14:13:35 | BitPuffin | ahhhh |
| 14:13:38 | BitPuffin | hahahaha |
| 14:13:40 | BitPuffin | lol |
| 14:13:45 | fowl | BitPuffin, you're drunk |
| 14:13:47 | BitPuffin | fowl: nice catch |
| 14:13:53 | BitPuffin | fowl: like your dad then |
| 14:13:59 | fowl | nah he doesnt drink |
| 14:14:05 | fowl | like my mom would be more accurate |
| 14:14:39 | BitPuffin | yay it doesn't crash |
| 14:14:46 | EXetoC | AWESOME |
| 14:14:46 | BitPuffin | fowl: I'll remember than for future slamdowns |
| 14:14:57 | BitPuffin | EXetoC: what is? |
| 14:15:16 | EXetoC | programs that don't crash |
| 14:15:50 | fowl | is fopen() the one from stdlib.h |
| 14:16:14 | BitPuffin | fowl: no it's from vorbisfile I think |
| 14:16:25 | BitPuffin | EXetoC: you got that right |
| 14:16:41 | BitPuffin | fowl: thanks for the help :D does this mean that the shit will be GCd now? |
| 14:17:08 | fowl | yea |
| 14:17:18 | fowl | i like fractions of bitcoins for christmas btw |
| 14:17:42 | * | DAddYE joined #nimrod |
| 14:17:44 | EXetoC | can I have one bitcoin? |
| 14:18:34 | BitPuffin | fowl: the game won't come out until 26th at best |
| 14:22:21 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 14:23:41 | * | Mat3 cast[ptr array[0..avmNatAdrSpace,uWord]](self.pVmMem)[self.tOpcode.iVmMem] = self.tOpcode.Opcode |
| 14:23:59 | * | Mat3 accessing memory in Nimrod can be so simple |
| 14:26:49 | C0C0 | dafuq? |
| 14:26:55 | C0C0 | what is that |
| 14:27:12 | fowl | what are you working on lol |
| 14:27:38 | C0C0 | some kind of VM apparently |
| 14:27:55 | C0C0 | another iteration of corewars? |
| 14:28:00 | C0C0 | I fucking love corewars |
| 14:28:15 | Mat3 | implementing vectored instruction sheduling for my VM design |
| 14:28:34 | C0C0 | hmm no corewars? |
| 14:28:37 | Mat3 | no |
| 14:29:44 | C0C0 | too bad |
| 14:30:18 | fowl | vectored instruction scheduling, sounds fancy |
| 14:37:13 | BitPuffin | yeah I think Mat3 only joined this channel to make us feel stupid |
| 14:37:33 | EXetoC | pfft, game dev is much more hardcore, man |
| 14:37:45 | BitPuffin | awwww yeaaaa |
| 14:37:55 | Mat3 | there exist a VM mode where each decoder (for 2 fused instruction slots) executed parallel (as real-time thread). In this case the compiler must be able to assemble opcodes from independent threads (just like for conventional VLIW architectures) |
| 14:38:24 | C0C0 | "conventional VLIW architectures" |
| 14:38:34 | EXetoC | it all makes sense now |
| 14:38:45 | C0C0 | guess I have some reading to do bevor I can play with you Mat3 ^^ |
| 14:39:00 | BitPuffin | pff, I knew that |
| 14:39:16 | BitPuffin | even before I started programming |
| 14:39:26 | fowl | lol |
| 14:39:49 | C0C0 | ^^ |
| 14:40:07 | C0C0 | Mat3: what exactly are you doing (on a more "explain your granddad level)? |
| 14:40:09 | C0C0 | sounds interessting |
| 14:43:06 | Mat3 | implementing a minimalistic VM design and environment for a scaled-down Nimrod variant for system-programming as replacement for C |
| 14:43:39 | EXetoC | = win |
| 14:43:40 | * | Mat3 reminds me changing my translator engine |
| 14:44:32 | Mat3 | (and make the result on some embedded boards) |
| 14:44:37 | C0C0 | hmm? |
| 14:44:48 | C0C0 | your implementing a vm for nimrod? |
| 14:45:27 | C0C0 | so you can use an interpreted language on embedded devices? |
| 14:46:51 | Mat3 | for using a Nimrod alike environment on the device to be precise |
| 14:47:06 | Mat3 | http://www.dontronics-shop.com/olimex-duinomite-mini.html |
| 14:47:12 | Mat3 | ^like these |
| 14:47:14 | C0C0 | hmm whats the problem with the nimrod generated C code? |
| 14:47:25 | C0C0 | is the GC code not portable? |
| 14:47:39 | OrionPKM | replacement for C is pretty ambitious :p |
| 14:47:55 | Mat3 | it is as I know |
| 14:48:19 | Araq | "delegate monads for low-level memory access" ... please give an example for that |
| 14:48:35 | Araq | I only have some vague idea what you mean |
| 14:48:54 | Mat3 | OrionPKM: Not really (these board above uses Basic for example ) |
| 14:49:23 | OrionPKM | ew :) |
| 14:49:27 | * | NimWolf quit (Quit: Nettalk6 - www.ntalk.de) |
| 14:51:20 | Mat3 | Araq: Instead of explicit casting for accessing memory (and by do so, bypassing the type system more or less) think of some intrinsic, free procedures which convert there input as side effect |
| 14:52:00 | Mat3 | and handles memory accessing this way |
| 14:54:11 | Mat3 | like accessing memory though a set of memory managing functions |
| 14:54:20 | Araq | peek and poke? |
| 14:54:20 | Mat3 | (I hope this makes sense) |
| 14:54:56 | Mat3 | something like that, only managed at runtime |
| 14:55:38 | Araq | not sure how this can work. you'd need some type tags at runtime to be able to check anything |
| 14:58:53 | * | mflamer joined #nimrod |
| 15:01:16 | Mat3 | yes, this will need dynamic type tagging as I think about it |
| 15:01:46 | Mat3 | however, for an interpretative system this should be of no problem |
| 15:04:09 | Araq | actually |
| 15:04:39 | Araq | I can envision a safeCast that is like 'cast' but the compiler ensures you only perform casts that cannot break memory safety |
| 15:04:58 | Araq | kind of like the typed arrays in JavaScript work |
| 15:05:41 | Araq | not sure how useful this is for your purposes though |
| 15:08:47 | Mat3 | one problem is: Some MCU's featuring an extended Harvard architecture (like some DSP's from TI) and this involves handling of two accessible but different memory spaces |
| 15:09:40 | Mat3 | (you can add a third one for SoC devices) |
| 15:09:42 | Araq | two different memory spaces looks like we need parametrized pointer types |
| 15:09:50 | Araq | bbl |
| 15:10:31 | Mat3 | see you guys later (work) |
| 15:10:32 | Mat3 | ciao |
| 15:10:39 | * | Mat3 quit (Quit: Verlassend) |
| 15:16:22 | mflamer | Araq: You still working through TAPL? |
| 15:18:55 | * | DAddYE joined #nimrod |
| 15:23:20 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 15:25:55 | BitPuffin | EXetoC: yeah, above 48khz sampling rate does not really make sense for playback. However for recording 96khz is really good :) |
| 15:27:40 | OrionPKM | araq there's some issue with idetools that prevents it from actually returning, it just kinda hangs |
| 15:27:49 | OrionPKM | have you run into that? |
| 15:30:17 | BitPuffin | however bitdepth cap at 16bit signed doesn't make sense, since it's also common to use 24 |
| 15:33:02 | mflamer | brb |
| 15:37:59 | * | mflamer quit (Ping timeout: 272 seconds) |
| 15:39:03 | EXetoC | BitPuffin: I don't know why having a nyquist frequency of 48k is any better than ~20k but ok |
| 15:39:31 | EXetoC | BitPuffin: haven't you done an update? |
| 15:39:51 | EXetoC | those checks have been removed |
| 15:42:04 | Araq | OrionPKM: this could also be the latest babel issue that fowl reported |
| 15:42:18 | Araq | I mean the babel support we had to include into the compiler |
| 15:42:49 | OrionPKM | when did he report this? |
| 15:45:23 | EXetoC | BitPuffin: well, it might be useful for when analyzing audio, if that's what you're referring to |
| 15:46:10 | EXetoC | if anti-aliasing is even useful then |
| 15:48:08 | Araq | OrionPKM: he didn't report it yet. Try to comment out the line |
| 15:48:10 | Araq | compiler/options.nim:274: bringToFront(lazyPaths, it) |
| 15:48:39 | OrionPKM | I'll give it a shot when I get a chance, will let you know. |
| 15:49:21 | fowl | Araq, its fixed |
| 15:49:34 | fowl | Araq, its in the commit removing x11, opengl, etc |
| 15:49:37 | fowl | er PR |
| 15:50:33 | BitPuffin | EXetoC: well the nyquist frequency of a pcm signal is half the sampling rate |
| 15:50:52 | BitPuffin | EXetoC: so with 48khz the nyquist frequency is 24khz |
| 15:51:06 | BitPuffin | which is silghty above human capability |
| 15:52:12 | BitPuffin | EXetoC: however when it comes to recording it's still useful to go above 48khz 96khz etc because there is more headroom for the low pass filter that helps avoid aliasing |
| 15:52:51 | BitPuffin | EXetoC: so I'll record at 96khz because that the maximum that my m10 handles, but playback in the game will be 48 or so |
| 15:53:11 | Araq | dom96: I merged fowl's pull request but nimbot remains silent |
| 15:53:14 | Araq | :-( |
| 15:53:21 | NimBot | Araq/Nimrod master de3ebb6 fowlmouth [+0 ±0 -21]: removed x11 |
| 15:53:21 | NimBot | Araq/Nimrod master 6775485 fowlmouth [+0 ±0 -20]: removed gtk2 |
| 15:53:21 | NimBot | Araq/Nimrod master 3d16b9c fowlmouth [+0 ±0 -7]: Removed opengl |
| 15:53:21 | NimBot | Araq/Nimrod master 95e65ee fowlmouth [+0 ±0 -14]: Removed lua, python, tcl, cairo |
| 15:53:21 | NimBot | 4 more commits. |
| 15:53:26 | Araq | oh lol |
| 15:53:30 | BitPuffin | EXetoC: but for others using libao with nimrod it's obviously good to be able to play 96khz etc sampling rates |
| 15:53:45 | Araq | I need to go, see you guys later |
| 15:53:50 | BitPuffin | see you Araq! |
| 15:55:34 | EXetoC | BitPuffin: I'm not sure what you're implying, but maybe I'll read more about this some other time |
| 15:55:44 | EXetoC | BitPuffin: well, the limit was set to 192khz before |
| 15:56:35 | BitPuffin | EXetoC: oh haha :P |
| 15:57:06 | BitPuffin | EXetoC: bit depth of my m10 recorder is 24 |
| 15:57:10 | dom96 | Have you guys heard of badBIOS? Being able to play sound at a high frequency certainly has it's use for malicious purposes. |
| 15:57:29 | BitPuffin | dom96: isn't that just a rumor though |
| 15:58:04 | BitPuffin | EXetoC: I guess the limit should be set to the highest thing that is ever being used 500 something or whatever it was |
| 15:58:14 | dom96 | Yeah. But apparently some scientists reproduced a prototype which communicates that way: http://arstechnica.com/security/2013/12/scientist-developed-malware-covertly-jumps-air-gaps-using-inaudible-sound/ |
| 15:58:27 | BitPuffin | dom96: yeah It's certainly theoretically possible |
| 15:58:38 | BitPuffin | however I wonder how that can be lossless |
| 15:58:48 | dom96 | I'm actually considering trying it myself for fun heh |
| 15:59:06 | BitPuffin | lol |
| 15:59:08 | BitPuffin | write it in nimrod |
| 15:59:17 | dom96 | well of course |
| 15:59:38 | C0C0 | BitPuffin: why wouldn't it be lossless? |
| 15:59:53 | C0C0 | the internet was build via data transission via audio |
| 15:59:57 | C0C0 | resends ftw |
| 16:00:12 | BitPuffin | C0C0: well distortion by flying through air |
| 16:00:31 | fowl | data rate is 20 bits/second |
| 16:00:43 | BitPuffin | C0C0: I mean the radio signals you can listen to certainly aren't in the same condition as from where they were transmitted is it? |
| 16:01:20 | BitPuffin | EXetoC: haha okay I'm gonna keep 16 bit depth since alsa warned me :P |
| 16:04:28 | C0C0 | BitPuffin: so what? |
| 16:04:40 | C0C0 | thats where frequency/phase modulation comes in? |
| 16:05:24 | EXetoC | a 1hz signal just has to be close enough to 1hz in the end I guess |
| 16:05:33 | BitPuffin | EXetoC: okay I'm not gonna use libao |
| 16:07:12 | EXetoC | ok |
| 16:07:25 | C0C0 | EXetoC: well frequency shifts are rather uncommon no? |
| 16:07:26 | BitPuffin | EXetoC: don't you wanna know why? |
| 16:07:34 | BitPuffin | it's not your fault lol :P |
| 16:08:00 | EXetoC | too low level? |
| 16:08:02 | C0C0 | afaik the only reason for frequency shifts in the signal (in the secenario) is the doppler effet of moving things |
| 16:08:57 | OrionPKM | Araq, when I comment out that line you mentioned, it no longer hangs, it gives a SIGSEGV instead |
| 16:09:07 | BitPuffin | EXetoC: hell no |
| 16:09:10 | BitPuffin | EXetoC: GPL |
| 16:09:46 | C0C0 | EXetoC: which should be rather minor |
| 16:09:54 | fowl | OrionPKM, he's just merged my changes in, try now |
| 16:10:05 | C0C0 | especially since there will always be refelcted waves with the original frequence as well |
| 16:10:27 | C0C0 | except for someone carrying the computer arround rather fast |
| 16:10:56 | OrionPKM | fowl is it all merged now? |
| 16:11:01 | fowl | yea |
| 16:11:09 | EXetoC | BitPuffin: ok I don't know why that matters |
| 16:11:26 | BitPuffin | EXetoC: because that means my code also has to be GPL licensed |
| 16:12:18 | OrionPKM | fowl SIGSEGV instaed of hang with your changes |
| 16:13:32 | fowl | oh..hmm |
| 16:15:17 | OrionPKM | it's an improvement to crash instead of hang though :) |
| 16:16:11 | EXetoC | BitPuffin: I don't think I ever realized that it was that restrictive. I hate it even more now |
| 16:16:28 | fowl | OrionPKM, you did uncomment that line, right |
| 16:16:34 | OrionPKM | yes |
| 16:16:38 | BitPuffin | EXetoC: Yeah the GPL is terrible |
| 16:17:46 | fowl | BitPuffin, i thought you only have to GPL your code if you modify theirs |
| 16:17:56 | BitPuffin | fowl: that's LGPL |
| 16:17:58 | BitPuffin | iirc |
| 16:18:24 | BitPuffin | LGPL let's you statically link and I don't know if it spreads like the GPL the same way |
| 16:20:01 | * | MFlamer joined #nimrod |
| 16:20:10 | * | DAddYE joined #nimrod |
| 16:20:55 | EXetoC | BitPuffin: same with GPL3? |
| 16:22:26 | BitPuffin | EXetoC: even worse with GPL3 |
| 16:22:59 | EXetoC | wth |
| 16:23:15 | BitPuffin | I believe GPL3 put another restriction that you can't put GPLv3 software on a device without enabling the user to replace it or modify it or somethnig |
| 16:23:22 | BitPuffin | so it applies to manufacturers more |
| 16:23:27 | EXetoC | fortunately it seems like BSD, MIT, X11 etc are fairly popular these days |
| 16:23:28 | BitPuffin | it's why linux is staying with gpl2 |
| 16:23:40 | EXetoC | right |
| 16:23:47 | BitPuffin | EXetoC: yep, and I go even further by putting my stuff in the public domain |
| 16:24:14 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 16:25:20 | EXetoC | ok |
| 16:26:14 | EXetoC | maybe I should wrap portaudio then |
| 16:30:10 | BitPuffin | EXetoC: already working on it |
| 16:30:35 | BitPuffin | how do i get c2nim to strip underscores? |
| 16:30:47 | * | linkmauve1 joined #nimrod |
| 16:32:05 | EXetoC | BitPuffin: no modifications needed even |
| 16:33:25 | BitPuffin | EXetoC: nope I know |
| 16:36:02 | EXetoC | what alternative universe are we in anyway? |
| 16:36:05 | BitPuffin | what was the pragma again |
| 16:36:26 | BitPuffin | {.push importc: "Pa_$".} ? |
| 16:36:52 | BitPuffin | fowl: master, tell me iirc |
| 16:37:24 | BitPuffin | ah with a 1 |
| 16:39:46 | EXetoC | does it even make sense to distribute nim-ao under MIT then? |
| 16:40:23 | BitPuffin | EXetoC: that's a gray area that I don't know |
| 16:40:43 | BitPuffin | well I guess it makes sense |
| 16:40:47 | BitPuffin | the binding code is mit |
| 16:40:54 | BitPuffin | since it doesn't actually call the GPL code |
| 16:41:11 | BitPuffin | but whoever is using the binding is calling GPL code |
| 16:41:18 | BitPuffin | so their code becomes GPL licensed |
| 16:41:26 | BitPuffin | and when they use it your code also becomes GPL'd |
| 16:41:38 | BitPuffin | eh |
| 16:41:44 | BitPuffin | ClusterfuckPL |
| 16:41:49 | EXetoC | :o |
| 16:42:26 | BitPuffin | portaudio.nim(26, 34) Error: invalid order in enum 'NotInitialized' |
| 16:42:37 | BitPuffin | TErrorCode* {.size: sizeof(cint).} = enum |
| 16:42:40 | BitPuffin | NoError = 0, NotInitialized = - 10000, UnanticipatedHostError, |
| 16:42:57 | EXetoC | yes you'll have to move stuff around |
| 16:43:00 | BitPuffin | should I just move NoError to the end? |
| 16:43:17 | EXetoC | the latter doesn't have a value? |
| 16:43:20 | dom96 | depends on what value you want UnanticipatedHostError to have |
| 16:44:08 | BitPuffin | dom96: well in C I guess that'd be -9999 |
| 16:44:17 | BitPuffin | so same here |
| 16:44:39 | EXetoC | that's an odd set of values then, but maybe that's the case |
| 16:45:06 | EXetoC | so yeah I guess paNoError should be moved |
| 16:45:27 | BitPuffin | well it fixed the compilation error at least |
| 16:45:28 | EXetoC | are you going to make a high-level wrapper? |
| 16:45:32 | BitPuffin | but maybe breaks the ballsieball |
| 16:45:48 | EXetoC | I don't think so |
| 16:45:52 | BitPuffin | EXetoC: no don't think so, maybe you could create a separate babel pkg for high level stuff? |
| 16:46:20 | BitPuffin | unless you wanna do it in my repo and say I dedicate any and all copyright interest in this software to the |
| 16:46:23 | BitPuffin | public domain. I make this dedication for the benefit of the public at |
| 16:46:25 | BitPuffin | large and to the detriment of my heirs and successors. I intend this |
| 16:46:27 | BitPuffin | dedication to be an overt act of relinquishment in perpetuity of all |
| 16:46:29 | BitPuffin | present and future rights to this software under copyright law. |
| 16:46:38 | BitPuffin | xD |
| 16:46:48 | EXetoC | I think you said it wasn't going to be a problem, so I don't mind in that case |
| 16:47:20 | BitPuffin | what being a problem? |
| 16:47:41 | BitPuffin | typedef int PaDeviceIndex; |
| 16:47:45 | BitPuffin | #define paNoDevice ((PaDeviceIndex)-1) |
| 16:47:51 | BitPuffin | so how the fuck do I deal with that |
| 16:48:01 | EXetoC | public domain |
| 16:48:09 | BitPuffin | EXetoC: public domain is definitely not a problem |
| 16:48:18 | * | Varriount_ joined #nimrod |
| 16:48:19 | BitPuffin | especially with CC0 |
| 16:48:28 | BitPuffin | because it works in countries that don't have public domain |
| 16:48:40 | BitPuffin | with a fallback thingy |
| 16:48:50 | BitPuffin | guess it's a macro |
| 16:49:19 | EXetoC | but PaDeviceIndex is a type. wut |
| 16:49:40 | BitPuffin | yeah wth |
| 16:49:46 | BitPuffin | I dunno maybe it's an argument? |
| 16:49:54 | EXetoC | "typedef int PaDeviceIndex; PaDeviceIndex-1" :O |
| 16:50:34 | * | gradha joined #nimrod |
| 16:51:30 | * | Varriount quit (Ping timeout: 245 seconds) |
| 16:51:30 | * | Varriount_ is now known as Varriount |
| 16:51:51 | BitPuffin | EXetoC: I'll go ahead and interpret it like this |
| 16:51:56 | BitPuffin | template noDevice(idx: TDeviceIndex): expr = |
| 16:51:59 | BitPuffin | idx - 1 |
| 16:52:08 | BitPuffin | any C guru can correct me |
| 16:52:11 | BitPuffin | because I ain't one |
| 16:52:51 | EXetoC | does that even compile when used? |
| 16:53:01 | BitPuffin | EXetoC: portaudio.h? |
| 16:53:46 | gradha | OrionPKM: you mentioned idetools hanging, are you running it as a server or starting a fresh compiler for each query? |
| 16:54:55 | BitPuffin | oh ffs |
| 16:55:04 | BitPuffin | type |
| 16:55:05 | OrionPKM | gradha fresh for each query, for now |
| 16:55:06 | BitPuffin | TSampleFormat* = culong |
| 16:55:11 | BitPuffin | Float32* = cast[(TSampleFormat)](0x00000001) #*< @see PaSampleFormat |
| 16:55:28 | gradha | OrionPKM: hangs in such a way are certainly new |
| 16:55:30 | EXetoC | BitPuffin: The C code is subtracting from a type |
| 16:56:19 | OrionPKM | well its not hanging anymore gradha, it's giving a SIGSEGV |
| 16:56:23 | BitPuffin | EXetoC: I think it is a macro though? |
| 16:56:38 | gradha | progress |
| 16:56:48 | OrionPKM | gradha which is something I've gotten from idetools before |
| 16:57:15 | EXetoC | BitPuffin: yes but it doesn't. it does output -1 though. so make it -1.cint |
| 16:58:43 | EXetoC | I can't even replicate it |
| 16:58:54 | OrionPKM | gradha fowl it seems to happen for whole files, not specific lookups in that file |
| 16:59:04 | BitPuffin | EXetoC: you tried compiling? |
| 16:59:15 | gradha | OrionPKM: I did stop looking at idetools some months ago but never had a sigsev, might be worth knowing when more or less you started having them for a hypothetical git-bisect |
| 16:59:35 | EXetoC | BitPuffin: I could print it in C++, but it fails when I do it on my own typedef |
| 16:59:38 | EXetoC | it printed -1 |
| 17:00:05 | OrionPKM | i.e. for file1.nim idetools always gives a SIGSEGV no matter what row/col, but file2.nim works |
| 17:02:22 | gradha | OrionPKM: you have file1.nim somewhere for playin with? |
| 17:02:46 | OrionPKM | gradha I'll make a gist later, i'm at work now |
| 17:03:08 | OrionPKM | I tried reproducing it in a smaller file last night, but i'll try again |
| 17:03:19 | OrionPKM | it's happening in a large project right now |
| 17:06:06 | * | boydgreenfield joined #nimrod |
| 17:07:21 | EXetoC | BitPuffin: it's a cast |
| 17:07:40 | EXetoC | I'm forgetting these languages already |
| 17:07:52 | EXetoC | it's fairly cryptic though, right :p |
| 17:11:02 | BitPuffin | EXetoC: lol haha true |
| 17:11:08 | BitPuffin | can't believe we didn't see that |
| 17:11:14 | BitPuffin | i'll deal with it |
| 17:11:18 | BitPuffin | just gotta deal with this |
| 17:11:27 | BitPuffin | typedef void PaStream; |
| 17:11:57 | BitPuffin | c2nim says type TStream* = nil |
| 17:12:03 | BitPuffin | but that is not legal |
| 17:12:28 | EXetoC | it's probably used as a pointer |
| 17:12:44 | BitPuffin | yeah almost at least |
| 17:12:54 | BitPuffin | but pointer is a pointer to void |
| 17:12:56 | BitPuffin | this is void |
| 17:12:59 | BitPuffin | so wut |
| 17:13:14 | EXetoC | so just 'pointer' in nimrod |
| 17:13:51 | BitPuffin | EXetoC: no |
| 17:13:59 | BitPuffin | EXetoC: pointer is void* |
| 17:14:02 | BitPuffin | this is void |
| 17:14:29 | EXetoC | yes, but it's never used only as PaStream, and I don't know if you can achieve the same thing in nimrod |
| 17:14:33 | BitPuffin | but yeah they take ptr ptr of TStream lol |
| 17:14:42 | BitPuffin | so I'll rewrite that as a pointer[] |
| 17:15:34 | EXetoC | it does once |
| 17:16:55 | BitPuffin | how do I write that something is an array without knowing its size? |
| 17:17:27 | EXetoC | it doesn't matter because a pointer is a pointer |
| 17:17:42 | EXetoC | so maybe you'll have to fiddle around with just 'pointer' |
| 17:18:12 | BitPuffin | okay so I'll just rewrite ptr ptr TStream to ptr TStream where TStream is a ptr? |
| 17:18:15 | BitPuffin | pointer* |
| 17:21:18 | EXetoC | no it should be two pointers, but I don't know if it makes sense in nimrod |
| 17:21:41 | * | DAddYE joined #nimrod |
| 17:23:22 | EXetoC | http://portaudio.com/docs/v19-doxydocs/paex__sine_8c_source.html |
| 17:26:01 | BitPuffin | EXetoC: well it is two pointers now |
| 17:26:15 | BitPuffin | EXetoC: PStream = ptr TStream |
| 17:26:20 | BitPuffin | and TStream = pointer |
| 17:27:50 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 17:27:59 | BitPuffin | Error: invalid pragma: importc: "Pa_$1" |
| 17:28:10 | * | zielmicha joined #nimrod |
| 17:29:12 | BitPuffin | fowl: you lied! |
| 17:29:56 | EXetoC | just 'pointer' might do like I said, but it might be a good idea to make it similar |
| 17:30:24 | * | ics joined #nimrod |
| 17:32:03 | EXetoC | ok time to do boring stuff. good luck |
| 17:34:34 | BitPuffin | EXetoC: well I'll change it if it turns out to be bad |
| 17:36:09 | EXetoC | I don't think it matters is what I'm saying. I'm just nitpicking |
| 17:37:12 | BitPuffin | thank the jebus for macros |
| 17:50:47 | BitPuffin | (vim macros) |
| 17:51:12 | EXetoC | ya |
| 17:57:35 | BitPuffin | fucking github |
| 17:57:58 | BitPuffin | dom96: could you add nim-portaudio to packages? |
| 17:58:12 | BitPuffin | same everything as nim-ogg and nim-vorbis except different names and urls |
| 17:58:26 | BitPuffin | or gradha |
| 17:58:53 | gradha | BitPuffin: what is giving you problems? |
| 17:59:14 | BitPuffin | github |
| 17:59:22 | BitPuffin | ERROR: Storage server temporarily offline. See http://status.github.com for GitHub system status. |
| 17:59:33 | gradha | can't do much about that myself |
| 17:59:42 | BitPuffin | well it might not even apply to the real repo |
| 17:59:58 | * | DAddYE joined #nimrod |
| 17:59:59 | BitPuffin | because it happened after I deleted and reforked |
| 18:00:05 | BitPuffin | because I didn't wanna download etc |
| 18:00:11 | gradha | hah, now the truth comes, YOU broke github |
| 18:00:17 | BitPuffin | their status page says 100% |
| 18:00:32 | BitPuffin | will the FBI come for me now ;_; |
| 18:02:45 | EXetoC | gradha: no u |
| 18:06:27 | * | brson joined #nimrod |
| 18:07:29 | BitPuffin | time to go home |
| 18:07:32 | BitPuffin | bbl! |
| 18:07:33 | * | BitPuffin quit (Quit: WeeChat 0.4.2) |
| 18:12:52 | * | dirkk0 joined #nimrod |
| 18:15:21 | Araq | hi linkmauve1 welcome |
| 18:15:32 | linkmauve1 | Hi. :) |
| 18:15:57 | linkmauve1 | I just discovered nimrod yesterday, thanks to Kooda here. |
| 18:16:50 | gradha | we'll give Kooda a cookie then |
| 18:17:37 | linkmauve1 | I’m currently writing a game using Cython/SDL2/OpenGL, and from what I’ve read nimrod fixes all the grips I’ve encountered with Cython/Python. |
| 18:18:22 | linkmauve1 | It seems based on the same architecture, except without the python dependency and with a much more sensible type model. |
| 18:20:53 | linkmauve1 | I’ve started reading the tutorial, and so far I like this language a lot. :) |
| 18:21:22 | * | NimWolf joined #nimrod |
| 18:21:28 | EXetoC | same architecture? I'm not sure what that means |
| 18:22:06 | * | NimWolf left #nimrod (#nimrod) |
| 18:22:16 | * | wolfspaw joined #nimrod |
| 18:22:53 | wolfspaw | What is the idiomatic way for getting input in Nimrod? For example, suppose I want to get a int, an string, and a float. In C++ that would be "cin >> intVar >> stringVar >> floatVar" while in C that would be "scanf ("%i %s %f", &intVar, strVar, &floatVar)". |
| 18:23:16 | linkmauve1 | EXetoC, well, the same basic idea, compiling from a high-level language to C, with some type inference and such. |
| 18:23:41 | * | DAddYE quit (Remote host closed the connection) |
| 18:24:22 | gradha | wolfspaw: the base is given in the tutorial "let n = parseInt(readLine(stdin))" |
| 18:24:27 | EXetoC | there are other targets too, but C is indeed the main one |
| 18:25:22 | wolfspaw | gradha |
| 18:25:25 | wolfspaw | okay, thanks! |
| 18:26:04 | OrionPKM | woflspaw you could probably also use scanf, if you wanted to |
| 18:26:20 | * | DAddYE joined #nimrod |
| 18:27:28 | wolfspaw | OrionPKM: I find scanf pretty convenient, I'll look in the manual about using C functions then. Thanks! |
| 18:29:58 | dirkk0 | linkmauvel: fowl wrote a SDL2 lib here: https://github.com/fowlmouth/nimlibs/tree/master/fowltek |
| 18:30:08 | linkmauve1 | Oh, nice. :) |
| 18:30:27 | linkmauve1 | I don’t think I will migrate my current project, too much code already written, but for the next one this is good. |
| 18:30:34 | dirkk0 | which is working except that some libs are not converted yet (mixer). |
| 18:32:09 | EXetoC | fowl will do anything for a bitcoin |
| 18:32:30 | linkmauve1 | ^^ |
| 18:33:30 | * | CarpNet quit (Quit: Leaving) |
| 18:40:13 | * | shodan45 joined #nimrod |
| 18:52:21 | * | OrionPKM quit (Remote host closed the connection) |
| 18:54:00 | Araq | hi wolfspaw welcome |
| 18:59:18 | wolfspaw | thanks Araq! Great language, very good work. I just entered in contact with it, still reading the page docs |
| 19:01:09 | Araq | be careful when wrapping scanf, int is "long" so you need to use "%ld" instead of "%d" |
| 19:01:46 | * | dom96 waits patiently for his bitcoin wallet to synchronise |
| 19:04:20 | wolfspaw | ah, I see. okay! |
| 19:08:13 | * | BitPuffin joined #nimrod |
| 19:09:15 | * | wolfspaw quit (Read error: Connection reset by peer) |
| 19:20:28 | * | travisbrady joined #nimrod |
| 19:20:38 | Araq | hi travisbrady welcome |
| 19:20:48 | travisbrady | hello, Araz |
| 19:21:01 | travisbrady | pardon me, Araq mit ein 'Q' |
| 19:30:02 | BitPuffin | heyo! |
| 19:30:13 | gradha | BitPuffin: wb |
| 19:34:28 | BitPuffin | thanks gradha |
| 19:34:31 | BitPuffin | dom96: MERGE!!! |
| 19:35:12 | BitPuffin | EXetoC: portaudio coming to babel now |
| 19:35:25 | BitPuffin | EXetoC: I'm guessing you are also switching your project over to portaudio? |
| 19:35:39 | BitPuffin | gradha: do you have permission to merge? |
| 19:35:47 | EXetoC | yes. screw GPL |
| 19:35:50 | gradha | BitPuffin: yes |
| 19:36:14 | BitPuffin | gradha: do it bruthaaa |
| 19:36:26 | BitPuffin | EXetoC: yeah it's terrible |
| 19:37:04 | BitPuffin | EXetoC: I guess you might be right about the whole pointer thing, pointer doesn't really know what it's pointing to |
| 19:37:19 | BitPuffin | or meh |
| 19:37:25 | BitPuffin | I think if this works it makes more sense |
| 19:38:50 | gradha | BitPuffin: so you want this nim-portaudio merged? |
| 19:40:07 | BitPuffin | gradha: yes |
| 19:41:06 | gradha | I wonder if your recent pattern for description "binding for xxx" could be improved, so as to not require people know about portaudio |
| 19:41:41 | * | gradha also wonders if it would help for babel-packages to grow a helper "platforms" attribute |
| 19:41:58 | BitPuffin | gradha: well maybe, but I don't have time to fix that now |
| 19:42:22 | gradha | ah, time, if only we could cash it as money |
| 19:43:36 | gradha | how many users will be kept in the dark until that PR is merged? |
| 19:46:30 | EXetoC | the tags should give the users a clue |
| 19:46:44 | NimBot | nimrod-code/packages master 1aec83a Isak Andersson [+0 ±1 -0]: Add nim-portaudio |
| 19:46:44 | NimBot | nimrod-code/packages master ab1995e Grzegorz Adam Hankiewicz [+0 ±1 -0]: Merge pull request #38 from BitPuffin/master... 2 more lines |
| 19:47:04 | BitPuffin | EXetoC, gradha: and the name, it's got audio in it |
| 19:47:14 | dirkk0 | I barely dare to ask this question, but 'for i in 1..10: |
| 19:47:14 | dirkk0 | echo(i)' is turned into about 90 lines of c code (when I expected rather a dozen): http://pastebin.com/vCVg7dev - is that clang or something else? |
| 19:49:23 | gradha | dirkk0: you don't need to worry about that unless they pay you by LOC, in which case you are already winning |
| 19:50:49 | gradha | dirkk0: still you could try different size options for nimrod if you are worried |
| 19:51:12 | Araq | well 30 lines are just some typedefs which C manages to generate no assembler for |
| 19:51:59 | Araq | and the other 60 include things like line tracing for your debugging pleasure |
| 19:52:06 | Araq | try with -d:release |
| 19:52:27 | EXetoC | I bet that'll come up often |
| 19:52:35 | BitPuffin | EXetoC: errday |
| 19:52:46 | Araq | and btw with the right options my "hello world" program has the same size as its C counterpart |
| 19:53:46 | dirkk0 | the options would be? |
| 19:54:14 | BitPuffin | Araq: I have never been able to get it to the same size |
| 19:54:27 | EXetoC | Araq: is the single-argument version of `..` supposed to work in conjunction with 'for'? |
| 19:54:31 | BitPuffin | with gc:none opt:size d:release and so on |
| 19:54:34 | BitPuffin | tried lots of stuff |
| 19:54:39 | EXetoC | "for i in ..10" |
| 19:55:37 | gradha | anybody got "H.P. Lovecraft: The Complete Fiction", is it any good? |
| 19:55:53 | Araq | gradha: I read pretty much all of Lovecraft |
| 19:56:06 | Araq | it's good but by today's standards not scary at all |
| 19:56:06 | gradha | oh, that explains you writing compilers |
| 19:56:23 | * | OrionPKM joined #nimrod |
| 19:56:30 | Araq | OrionPKM: 60! |
| 19:56:38 | EXetoC | Araq: ok there's no iterator for that. do you think there should be one? |
| 19:56:44 | dirkk0 | you are right down to 50 something: http://pastebin.com/KgNFj69h |
| 19:57:37 | OrionPKM | araq hm? |
| 19:57:47 | gradha | dirkk0: maybe nimrod should generate all the C source code in a single line followed by semicolons |
| 19:57:56 | * | travisbrady quit (Quit: travisbrady) |
| 19:58:07 | OrionPKM | oh, people :p |
| 19:58:10 | EXetoC | dirkk0: yeah but what's left when the C compiler is done with it? |
| 19:58:38 | Araq | EXetoC: no. what would it gain us? |
| 19:58:39 | dirkk0 | gradha: that would be cheating compared to the nimrod simplicity. |
| 19:59:34 | OrionPKM | 59 now |
| 19:59:58 | gradha | dirkk0: somehow the word simplicity shouldn't include reviewing generated C source code by a tool |
| 20:00:24 | Araq | BitPuffin: -d:release --os:standalone -d:noSignalHandler iirc |
| 20:00:41 | Araq | maybe --os:standalone ain't necessary, don't remember |
| 20:00:46 | EXetoC | Araq: just a little consistency |
| 20:01:16 | OrionPKM | Araq fowl |
| 20:01:33 | OrionPKM | i think the sigsegv in idetools has to do w/ how the project is structured, or at least one of them is |
| 20:01:52 | OrionPKM | if you import a file thats up a directory, it crashes |
| 20:03:19 | OrionPKM | I had (pseudo) /folder/file1.nim import /file2.nim, it crashed when I looked up a --def in file1, but when I moved file2 into /folder/ it worked |
| 20:04:10 | gradha | the relative import is using ../ explicitly or through a nimrod.cfg with path=..? |
| 20:04:10 | dirkk0 | my point was basically - will I be able to change the c code manually after the nimrod compilation. |
| 20:04:21 | * | mflamer_ joined #nimrod |
| 20:04:46 | * | mflamer_ quit (Remote host closed the connection) |
| 20:04:47 | Araq | dirkk0: yes. nobody does it, but yes you can do it. |
| 20:05:04 | gradha | dirkk0: what changes to you plan on doing? |
| 20:05:05 | Araq | I regularly edit the generated assembler |
| 20:05:55 | gradha | Araq: but do you use a computer or a butterfly to change the assembler? |
| 20:06:04 | OrionPKM | gradha no, not quite so simple |
| 20:06:29 | OrionPKM | when the program is compiled there is actually a 3rd file importing folder/file1 |
| 20:06:41 | OrionPKM | the issue is when the 3rd file is the 'main project' file |
| 20:06:48 | OrionPKM | but it's not specified in idetools |
| 20:06:58 | Araq | gradha: I have my own autoconf inspired toolchain, so that I can edit the nimrod code, run my scripts and that applies some diffs on the generated assembler to make it faster |
| 20:07:35 | BitPuffin | what's the convention for naming types that are procs? |
| 20:07:58 | dirkk0 | that's what I was implying. Cool to see that Araq does this, too. |
| 20:08:34 | EXetoC | BitPuffin: that are procs? |
| 20:08:48 | dirkk0 | In the JS world pre- and post-processing is needed. Like badly. |
| 20:09:03 | gradha | Araq: bah assembler, it would be more hardcore if you had implement an autoconf like toolchain to modify the output generated by autoconf |
| 20:09:11 | BitPuffin | EXetoC: type balls = proc(a, b: int) |
| 20:09:54 | gradha | dirkk0: I wouldn't expect the generated C code to be an example of the generated JS code |
| 20:10:03 | EXetoC | I don't know. I use the 'Cb' suffix whenever it makes sense |
| 20:10:28 | gradha | dirkk0: plus for such intimate interaction you could likely implement yourself a fancy bridge with nimrod's emit |
| 20:10:41 | BitPuffin | EXetoC: yeah me too |
| 20:10:45 | dirkk0 | gradha: that wasn't my point. Rather SASS and uglyfying. |
| 20:10:47 | BitPuffin | EXetoC: but should I put T in front of it? |
| 20:11:21 | EXetoC | that makes sense to me |
| 20:11:42 | gradha | dirkk0: sorry, I'm lucky enough to avoid web thingies, so no idea what you are talking about |
| 20:12:17 | zielmicha | Do destructors work on references? |
| 20:12:17 | dirkk0 | gradha: you are a very lucky man, then. |
| 20:12:50 | OrionPKM | I dont think I have a good way to determine the "proj.nim" project file dynamically for idetools |
| 20:12:56 | gradha | dirkk0: I even enjoy chocolate, as I'm doing right now |
| 20:13:17 | * | gradha is amazed by SNSD having a dedicated page in the spanish itunes store |
| 20:13:20 | zielmicha | (for things like calling "free" functions of external objects) |
| 20:13:29 | OrionPKM | if anyone has any brilliant ideas, let me know :p |
| 20:13:35 | EXetoC | BitPuffin: hm, maybe I should've just used a Proc suffix, but that's really verbose :> |
| 20:14:23 | gradha | OrionPKM: you might want to ask zahary_, he also had to use heuristics to detect that for the vim plugin, can't recall what he ended up deciding and why though |
| 20:14:47 | gradha | OrionPKM: maybe a good idea would be to look for .cfg files and pick the .nim one with the same base name? |
| 20:15:02 | OrionPKM | gradha possibly |
| 20:15:29 | OrionPKM | a .nimrod.cfg you mean? :) |
| 20:15:44 | gradha | a proj.nimrod.cfg, wouldn't it? |
| 20:16:07 | OrionPKM | yes, but just .cfg could pick up a cfg file like "settings.cfg" |
| 20:16:34 | gradha | maybe that's why they call them heuristics, because they rarely work |
| 20:17:08 | OrionPKM | how about I just recurse up and try every .nim file until the call succeeds? :P |
| 20:17:15 | OrionPKM | dont see what could possibly go wrong there |
| 20:18:06 | OrionPKM | it would be nice to get a meaningful error message though, instead of sigsegv |
| 20:18:08 | gradha | you need to query parents (../../) too to be sure |
| 20:18:13 | dirkk0 | gradha: what is nimrods emit? |
| 20:18:20 | OrionPKM | thats what I meant gradha |
| 20:18:25 | OrionPKM | by recursively |
| 20:18:27 | * | Varriount_ joined #nimrod |
| 20:18:30 | OrionPKM | all the way to your root directory :p |
| 20:19:00 | gradha | OrionPKM: ah, sorry, I'm used to recursivity mean down in the hierarchy, not up |
| 20:19:27 | gradha | dirkk0: here's an example https://github.com/Araq/Nimrod/blob/master/examples/objciface/gnustepex.nim#L4 |
| 20:19:30 | EXetoC | so that naming format is only valid when a babel file is present? |
| 20:19:47 | gradha | dirkk0: it allows you to generate specific code for the underlying compiler/platform in cases of great necessity (or pure malice) |
| 20:19:54 | EXetoC | otherwise, should it just be nimrod.cfg? |
| 20:20:28 | * | travisbrady joined #nimrod |
| 20:21:06 | OrionPKM | the naming format is file.nimrod.cfg |
| 20:21:25 | OrionPKM | the file.cfg is ignored by the compiler now |
| 20:21:55 | * | Varriount quit (Ping timeout: 245 seconds) |
| 20:21:55 | * | Varriount_ is now known as Varriount |
| 20:22:08 | gradha | there went the chance to make the filenames "project xxx for nimrod.configuration" |
| 20:22:22 | dirkk0 | gradha: I see, thanks. |
| 20:22:22 | EXetoC | and for libs? |
| 20:23:17 | OrionPKM | I dont think it's any different from libraries |
| 20:23:49 | EXetoC | ok so it's just an arbitrary prefix |
| 20:24:13 | OrionPKM | arbitrary? |
| 20:24:48 | OrionPKM | yourfilenamehere.nimrod.cfg |
| 20:25:10 | OrionPKM | yourfilenamehere.cfg is ignored by the compiler, but your program can use it |
| 20:25:48 | Araq | zielmicha: yes it should work. there is a bug that keeps destructors from working with generics though |
| 20:29:25 | gradha | the record of 60 won't be recorded until dom96 is here to verify it in person |
| 20:30:03 | OrionPKM | we're at 61 now |
| 20:30:18 | OrionPKM | nice thing about having my irc client in a browser :P |
| 20:30:28 | gradha | OrionPKM: my client says otherwise, that's why we need a third impartial spectator |
| 20:30:43 | EXetoC | OrionPKM: the whole string is the filename, but yeah I know what you mean :p |
| 20:31:41 | EXetoC | so configs for libs are processed? |
| 20:32:57 | dom96 | 61 doesn't count, varriount was here twice. |
| 20:33:03 | dom96 | 60 is the current record. |
| 20:33:10 | Araq | huh? really? |
| 20:33:18 | Araq | I thought we had 65 once |
| 20:33:54 | OrionPKM | I think it's just the project file's cfg |
| 20:34:02 | dom96 | I don't think so. |
| 20:34:08 | dom96 | Unless I missed that occurrence |
| 20:34:25 | gradha | dom96: you should teach NimBot a few tricks, like how to high five |
| 20:37:47 | gradha | lol, the gnustepex doesn't even compile, nobody noticed so far |
| 20:38:33 | Araq | gradha: well it worked for me once :P |
| 20:39:05 | gradha | maybe before you copied and pasted, I'm seeing the version at http://gnustep.made-it.com/GSPT/xml/Tutorial_en.html is correct, you have to inherit NSObject, not Object |
| 20:39:46 | EXetoC | OrionPKM: ok so there is indeed a difference, in that there isn't even such a thing as a library cfg :p |
| 20:39:55 | EXetoC | I don't know if it'd be particularly useful |
| 20:41:01 | gradha | Araq: btw, what's the point of putting the example in a separate dir and have it emit objc rather than put it in a separate file? |
| 20:41:07 | BitPuffin | EXetoC: why the proc suffix? |
| 20:41:12 | BitPuffin | Araq: chime in please |
| 20:42:44 | EXetoC | ok Cb then, or nothing if it's not confusing |
| 20:43:19 | Araq | BitPuffin: well? |
| 20:43:41 | Araq | T for everything except P for ptr/ref/var |
| 20:43:51 | Araq | oh and E for exception |
| 20:43:58 | Araq | and F for Effect |
| 20:44:25 | Araq | but we'll get rid of it anyway |
| 20:44:53 | EXetoC | :< |
| 20:45:21 | BitPuffin | Araq: so no separate prefix for callbacks/procs? |
| 20:45:31 | Araq | BitPuffin: T prefix |
| 20:46:48 | BitPuffin | Araq: and suffix? |
| 20:47:19 | Araq | 'er' I guess ... TReader = proc (...) |
| 20:47:37 | Araq | TReadFunc is also common in the wrappers I think |
| 20:47:58 | BitPuffin | hmm |
| 20:48:01 | BitPuffin | even for callbacks |
| 20:48:16 | zielmicha | Araq: they don't, or am I doing something wrong? https://gist.github.com/zielmicha/7795223 |
| 20:48:25 | Araq | Cb suffix is fine, now go on with your life |
| 20:48:29 | BitPuffin | isn't proc a much better suffic for that lol |
| 20:49:22 | gradha | Araq: sorry, I see now the gnustep example is indeed correct, for some reason there are two versions of the example which is confusing |
| 20:50:23 | Araq | zielmicha: well your destructor is attached to TThing, not PThing |
| 20:50:31 | Araq | you need a finalizer for PThing |
| 20:50:48 | zielmicha | with (instance: var PThing) it doesn't work either |
| 20:51:05 | Araq | and yeah it's a feature request that a destructor is made into a finalizer |
| 20:51:40 | zielmicha | so there are no finalizers yet? |
| 20:51:47 | Araq | yes there are |
| 20:52:06 | Araq | as well as destructors but they are not aware of each other |
| 20:52:11 | zielmicha | how are they called? they are not described in manual |
| 20:52:34 | Araq | new(foo, finalizer) attaches a finalizer to the type of foo |
| 20:52:37 | Araq | confusing, I know |
| 20:52:57 | Araq | note that it's really attached to the *type* and not only to the instance |
| 20:53:36 | gradha | so you can do new(foo, finalizer); new(foo) and the second has the finalizer too? or it gets changed? |
| 20:53:54 | Araq | (instance: var PThing) should work if you put your example in a 'block' |
| 20:54:33 | zielmicha | I think we should mention them in "destructor pragma" manual section. I'll make pull request with changes. |
| 20:54:39 | Araq | gradha: second has finalizer too |
| 20:54:48 | Araq | zielmicha: alright excellent |
| 20:55:57 | gradha | Araq: how does that work in the context of a 3rd party lib module? The module uses finalizers, but end users import the module and just use normal new, do they get finalizers too? |
| 20:57:35 | Araq | yes they do get finalizers too but nobody creates a module and says 'just new() the stuff' |
| 20:57:53 | Araq | there will always be some constructor |
| 20:58:14 | * | brson quit (Ping timeout: 240 seconds) |
| 20:59:43 | * | tylere joined #nimrod |
| 20:59:46 | gradha | with "new(foo, fin1); new(foo, fin2)" is fin2 called for both objects? |
| 21:00:20 | tylere | So what is the right way to deal with (C-struct style) binary data? Like I say I know a file contains a bunch of, say 16-bit unsigned ints...what's the right way to handle something like that? |
| 21:01:29 | tylere | I mean, I know I could write code by hand to do it, but I kinda hope there is something better |
| 21:01:35 | tylere | Something like python's struct module |
| 21:02:46 | * | brson joined #nimrod |
| 21:02:48 | Araq | declare an object with the proper fields and read that. that has some endian issues though |
| 21:03:26 | Araq | gradha: dunno, either fin1 or fin2. one overwrites the other. or not. |
| 21:03:34 | tylere | Araq: Yea, that's what I'm worried about. |
| 21:03:49 | tylere | The file I have mind is a bit...weird. Including being in big-endian order |
| 21:04:09 | gradha | I wrote https://github.com/gradha/epak, there is also the endians module if you prefer that |
| 21:05:05 | BitPuffin | Araq: seriously how do you get a nimrod hello world as a C |
| 21:05:21 | Araq | BitPuffin: I already told you |
| 21:05:28 | gradha | BitPuffin: echo "Hello C" |
| 21:06:33 | tylere | BitPuffin: Compile it, then look in the nimcache directory |
| 21:08:20 | * | tylere quit (Remote host closed the connection) |
| 21:08:53 | BitPuffin | Araq: ah you did lol! |
| 21:09:18 | gradha | Araq: with all that talk about nimrod being static it seems finalizers are very dynamic |
| 21:10:16 | BitPuffin | Araq: lib/system.nim(1830, 10) Error: cannot open 'panicoverride' |
| 21:10:19 | BitPuffin | lol |
| 21:10:40 | gradha | BitPuffin: try without standalone |
| 21:11:13 | Araq | BitPuffin: you can find a panicoverride in the repo. |
| 21:12:02 | Araq | gradha: sometimes I provide a very useful feature before it's perfect |
| 21:12:21 | BitPuffin | gradha: makes it hugee |
| 21:12:25 | BitPuffin | no not huge |
| 21:12:26 | BitPuffin | but yeah |
| 21:12:59 | gradha | BitPuffin: the other day I compiled hello world to 9KB, how much do you get? |
| 21:13:14 | BitPuffin | gradha: 20 |
| 21:13:31 | gradha | looks like your world is bigger than mine then |
| 21:14:18 | BitPuffin | Araq: where should I put it? lib? |
| 21:14:36 | Araq | tests/manyloc/standalone contains an example |
| 21:16:28 | BitPuffin | still 20k |
| 21:17:00 | BitPuffin | I just copied the panicoverride from there into the dir |
| 21:18:54 | BitPuffin | it dun dinnely work |
| 21:20:15 | gradha | BitPuffin: use upx on the binary, see how much it compresses your hellos |
| 21:21:11 | BitPuffin | 13093 -> 7640 58.35% linux/ElfAMD test |
| 21:21:21 | gradha | wow, amd elfs |
| 21:21:29 | BitPuffin | upx: a.out: NotCompressibleException |
| 21:21:37 | BitPuffin | haha |
| 21:22:02 | BitPuffin | yay, with compression it is the same!! |
| 21:23:05 | BitPuffin | uh |
| 21:23:16 | BitPuffin | recompiled and it doesn't compress |
| 21:23:18 | BitPuffin | that's weird |
| 21:23:53 | BitPuffin | ah wait |
| 21:24:27 | * | achim quit (Quit: Computer has gone to sleep.) |
| 21:25:01 | * | gradha waits patiently |
| 21:25:17 | BitPuffin | gradha: WAAAIT |
| 21:26:18 | * | gradha compiles and runs "while true: WAAAAIT(BitPuffin)" |
| 21:27:11 | BitPuffin | gradha: scrots or it didn't happen |
| 21:27:33 | gradha | BitPuffin: well, I'm in an infinite loop now, can't do much |
| 21:27:50 | BitPuffin | gradha: open another terminal? |
| 21:30:03 | gradha | BitPuffin: so you want a screenshot of an empty terminal? |
| 21:30:45 | gradha | http://dl.dropbox.com/u/145894/t/bitpuffin.png |
| 21:31:15 | BitPuffin | goodt |
| 21:31:24 | BitPuffin | Now let's cherish this moment |
| 21:33:09 | gradha | there you go, try to optimize this to 10kb https://gist.github.com/gradha/7795983 |
| 21:33:46 | BitPuffin | nah |
| 21:33:50 | BitPuffin | don't have time lol :D |
| 21:39:08 | BitPuffin | YAY THE COMPILER HANGS! |
| 21:39:37 | dom96 | Araq: How's the nimbuild corruption finding going? |
| 21:39:41 | BitPuffin | Because that's good when you have a deadline |
| 21:40:04 | BitPuffin | Hint: file [Processing] |
| 21:40:12 | BitPuffin | :D :D :D :D :D :D :D :D :D :D |
| 21:40:29 | gradha | BitPuffin: do you have a diff of what you changed to make that happen? that could be useful |
| 21:40:40 | Araq | BitPuffin: get the latest github version |
| 21:40:45 | BitPuffin | gradha: I wasn't even working in that file |
| 21:41:02 | Araq | babel support was broken |
| 21:41:10 | BitPuffin | woa dat pull |
| 21:41:11 | gradha | BitPuffin: it doesn't matter, you had a version which compiles, one which doesn't, see what changed |
| 21:41:43 | BitPuffin | gradha: I removed libao and inserted portaudio |
| 21:42:00 | BitPuffin | now it doesn't hang though |
| 21:42:01 | BitPuffin | with latest |
| 21:42:09 | BitPuffin | EXetoC: think glfw may have broken with latest |
| 21:42:20 | BitPuffin | /home/isak/.babel/pkgs/nim-glfw-0.1.0/glfw/glfw.nim(1, 20) Error: cannot open 'wrappers/opengl/opengl' |
| 21:42:27 | * | Varriount_ joined #nimrod |
| 21:42:43 | BitPuffin | probably since it's now in opengl/opengl or something |
| 21:42:49 | BitPuffin | EXetoC: you should also make opengl a dep |
| 21:43:31 | BitPuffin | EXetoC: are you gonna fix it nao or do you want me to pull request? |
| 21:43:43 | EXetoC | that shouldn't be there anymore |
| 21:43:46 | EXetoC | will fix it |
| 21:43:49 | * | dirkk0 quit (Quit: Leaving) |
| 21:44:31 | EXetoC | mission accomplished |
| 21:45:24 | Araq | dom96: I'm too tired to work on it |
| 21:46:14 | * | Varriount quit (Ping timeout: 240 seconds) |
| 21:46:14 | * | Varriount_ is now known as Varriount |
| 21:46:42 | BitPuffin | EXetoC: already pushed? :o |
| 21:46:48 | EXetoC | BitPuffin: ya |
| 21:46:51 | gradha | BitPuffin: your game will be crossplatform? |
| 21:46:52 | BitPuffin | EXetoC: manly |
| 21:46:57 | BitPuffin | gradha: yes |
| 21:47:06 | EXetoC | gradha: dude, obviously |
| 21:47:07 | OrionPKM | upx + strip guys |
| 21:47:25 | gradha | EXetoC: for platform > 1? |
| 21:48:21 | EXetoC | gradha: as opposed to single-platform cross-platform? :p |
| 21:49:16 | gradha | EXetoC: some people write crossplatform testing only one platform but advertise as n > 1, then those don't compile |
| 21:49:21 | BitPuffin | OrionPKM: after that it does not run lol |
| 21:49:29 | dom96 | Araq: pity |
| 21:49:36 | EXetoC | oh. yeah I guess |
| 21:49:37 | OrionPKM | bitpuffin does for my program ;P |
| 21:49:43 | OrionPKM | strip first, then upx |
| 21:50:07 | gradha | Araq: if you've finished Lost you could try "Almost Human", heard good things about it |
| 21:50:15 | BitPuffin | OrionPKM: didn't change the size |
| 21:50:19 | EXetoC | Araq: were you saying that it's not possible to have "loadExtensions()" in the code, without getting any errors when no extensions are referenced? |
| 21:50:25 | dom96 | gradha: I watch it, it's great. |
| 21:50:42 | gradha | Araq: there you go, you should trust dom96 |
| 21:50:45 | EXetoC | I'm not sure if that's what you thought I was asking about in the first place |
| 21:50:47 | OrionPKM | for my IRC app it goes to 343 with strip, then 144 with upx |
| 21:50:54 | OrionPKM | goes to like 230 or so without strip |
| 21:51:00 | gradha | dom96: do cool asian chicks appear? |
| 21:51:10 | dom96 | gradha: Not really. |
| 21:51:20 | gradha | dom96: then I'm not watching |
| 21:51:53 | dom96 | gradha: There is a Chinese guy that sells live futuristic snails. |
| 21:52:13 | Araq | hmmm "Almost human" |
| 21:52:16 | dom96 | As food heh. |
| 21:52:17 | EXetoC | dom96: go on |
| 21:52:25 | EXetoC | interesting |
| 21:52:28 | dom96 | actually, it's technically slugs. |
| 21:52:34 | dom96 | except not technically |
| 21:52:39 | dom96 | it is precisely slugs |
| 21:52:54 | Araq | but I also have the Dishonored DLC to play |
| 21:53:27 | gradha | Araq: play it during the commercials? |
| 21:54:10 | Araq | what's that? commercials? |
| 21:54:47 | Araq | internet's commercials don't work like that |
| 21:54:58 | gradha | you have youtube without ads? |
| 21:55:06 | EXetoC | adblock!! |
| 21:55:29 | dom96 | torrents ftw |
| 21:57:05 | EXetoC | gradha: you don't? |
| 21:57:14 | gradha | Grimm: "A homicide detective discovers he is a descendant of hunters who fight supernatural forces." |
| 21:57:34 | EXetoC | how exciting |
| 21:57:48 | gradha | EXetoC: the html5 player doesn't have them, they appear if I run chrome with flash |
| 21:58:00 | EXetoC | :< |
| 21:59:10 | dom96 | adblock is so good that I was genuinely surprised at the amount of ads on websites which I would have thought were ad free when using somebody else's computer. |
| 21:59:42 | gradha | dom96: yeah, it's like "wtf, internet looks like this? how do people cope with it?" |
| 22:00:20 | dom96 | yep. This reaction is even stronger when watching TV. |
| 22:00:44 | dom96 | I must have saved years of my life by watching all my TV shows without any ads. |
| 22:00:59 | gradha | when I go to my parents house I actually watch the TV for the ads, they look intriguing when you are not spammed with them |
| 22:02:23 | gradha | plus they are filled with this "reality people", so many neighbour hot women washing clothes and stuff, waiting for a miracle product to help them |
| 22:02:41 | OrionPKM | gradha, a better description: "A homicide detective discovers he is a descendant of hunters who fight furries." |
| 22:03:24 | gradha | OrionPKM: since twillight werewolves have lost their beastlyness |
| 22:03:31 | Araq | well I managed to take showers during the ads when I was still watching TV |
| 22:04:06 | EXetoC | that's a lot of showers |
| 22:05:15 | gradha | I've never met a hot neighbour who didn't know about miracle washing mashine powder, there's still hope |
| 22:05:55 | Araq | EXetoC: XD |
| 22:06:15 | gradha | dom96: let me guess, the robot is the black cop |
| 22:06:24 | dom96 | gradha: yep |
| 22:06:28 | dom96 | He's hilarious |
| 22:06:39 | dom96 | That's the brilliance of the show |
| 22:06:55 | gradha | "Detective Valerie Stahl is a sharp beautiful, and very analytical. She has a secret that might go unnoticed.". Admiral Ackbar thinks it's a trap. |
| 22:07:23 | gradha | "Captain Sandra Maldonado, was originally envisioned as a man.". Hmm… I see a pattern here… |
| 22:08:23 | Araq | gradha: link? |
| 22:08:45 | gradha | http://sharetv.com/shows/almost_human/cast/valerie_stahl + http://sharetv.com/shows/almost_human/cast/capt_sandra_maldonado |
| 22:09:28 | dom96 | gah, spoilers |
| 22:09:48 | gradha | so it looks like it has come to this |
| 22:10:24 | * | radsoc joined #nimrod |
| 22:10:59 | gradha | dom96: the spoiler is that instead of robots they are all traps? |
| 22:11:16 | radsoc | MFlamer : sorry I didn't have much time today to try your LFHT but just got this message at compile time: lockfreehash.nim(23, 18) Error: type mismatch. I'll try again tomorrow. |
| 22:11:17 | dom96 | No that Valerie has a secret that might go unnoticed. |
| 22:11:38 | radsoc | good night |
| 22:11:39 | gradha | dom96: that's like a horoscope, you could say that about anybody |
| 22:11:42 | * | radsoc left #nimrod (#nimrod) |
| 22:11:48 | BitPuffin | hmm |
| 22:12:05 | dom96 | gradha: true |
| 22:12:15 | BitPuffin | how do I initialize a proc type to be a certain type? |
| 22:12:16 | EXetoC | BitPuffin: anything bad about nim-glfw's interface? if not, then there's not much else to do |
| 22:12:25 | EXetoC | 1-2 procs might be missing, that's all |
| 22:12:30 | BitPuffin | EXetoC: not that has struck me yet at least |
| 22:12:34 | EXetoC | BitPuffin: type? value? |
| 22:12:36 | EXetoC | ok |
| 22:12:42 | BitPuffin | EXetoC: value |
| 22:12:43 | gradha | "Araq, creator of nimrod. He has a secret that might go unnoticed." |
| 22:13:03 | Araq | yeah that's damn right |
| 22:13:04 | gradha | "Gradha, honey badger. He has a secret that might go unnoticed." |
| 22:13:07 | EXetoC | a type is just a declaration. you need to create a var |
| 22:13:22 | BitPuffin | EXetoC: yeah I know but how do I make it match the type |
| 22:13:33 | gradha | "Dom96, a god. Has a secret that might go unnoticed." |
| 22:13:43 | gradha | There you go, you can fill those in your facebook profile pages |
| 22:13:49 | BitPuffin | EXetoC: or ah it also has to be a ptr |
| 22:14:00 | BitPuffin | how do I make a proc ptr xD |
| 22:14:03 | EXetoC | no I don't think so |
| 22:14:07 | dom96 | hehe |
| 22:14:17 | EXetoC | if the type isn't also a "ptr proc..." |
| 22:14:23 | BitPuffin | EXetoC: it is |
| 22:14:36 | BitPuffin | PDeviceCallback* = ptr TStreamCallback |
| 22:14:38 | dom96 | anyone wanna optimise an opengl nimrod benchmark? |
| 22:15:08 | * | gradha takes one step behind the line |
| 22:15:23 | gradha | oh, so many volunteers! |
| 22:15:45 | BitPuffin | Araq: how do I make a ptr proc |
| 22:15:55 | EXetoC | BitPuffin: no idea. why do you need it? for the sake of binary compatibility? |
| 22:16:03 | BitPuffin | EXetoC: yeah |
| 22:16:28 | BitPuffin | EXetoC: openDefaultStream takes a ptr TStreamCallback |
| 22:17:41 | Araq | BitPuffin: some say it's then "ptr proc ..." |
| 22:17:42 | dom96 | I guess the prospect of optimisation isn't as exciting as I thought... |
| 22:18:00 | BitPuffin | dom96: it is but I'm busy |
| 22:18:35 | Araq | dom96: the problem is that it'll run optimal on my machine but then on the official benchmark machine will lose against some C++ version with 0.1% time difference |
| 22:19:30 | dom96 | Araq: I'll ask the guy about how it compares on his machine. |
| 22:19:38 | EXetoC | BitPuffin: I don't know if that's correctly annotated then |
| 22:19:58 | EXetoC | if you look at portaudio.h |
| 22:20:24 | BitPuffin | EXetoC: I was suspecting that maybe it was c2nim's fault |
| 22:21:42 | dom96 | Araq: Just need to get it as fast as possible. |
| 22:22:01 | BitPuffin | EXetoC: what should it be then? |
| 22:22:04 | BitPuffin | just proc? |
| 22:22:50 | EXetoC | BitPuffin: yes, but then 'ptr' would also have to be omitted from the definition, if TStreamCallback is indeed a proc type |
| 22:23:00 | Araq | dom96: alright show me what you got |
| 22:23:33 | BitPuffin | EXetoC: from the definition? |
| 22:24:02 | dom96 | Araq: https://gist.github.com/dom96/485c7a97472d31dc6b6e |
| 22:24:27 | EXetoC | BitPuffin: yeah, the 'ptr' for openDefaultStream |
| 22:24:28 | EXetoC | unless I'm misreading portaudio.h and it is indeed a pointer to a function pointer, but I suspect that it isn't |
| 22:25:04 | NimBot | Araq/Nimrod master da687af Hitesh Jasani [+0 ±1 -0]: Add docs for connecting to postgres with keyword/value connection... 1 more lines |
| 22:25:04 | NimBot | Araq/Nimrod master f340eb3 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Merge pull request #706 from hiteshjasani/master... 2 more lines |
| 22:25:46 | BitPuffin | EXetoC: hmm tricky wan |
| 22:26:36 | BitPuffin | EXetoC: but wouldn't the parameter just be PaStreamCallback callback ? |
| 22:27:04 | BitPuffin | I'm gonna try in |
| 22:28:26 | EXetoC | I think so, if by that you mean "streamCallback: ptr PaStreamCallback" -> "streamCallback: PaStreamCallback" |
| 22:29:02 | * | zielmicha1 joined #nimrod |
| 22:29:05 | Araq | gradha: uh oh |
| 22:29:15 | Araq | why did you merge that postgres stuff? |
| 22:29:30 | Araq | looked suspicous to me |
| 22:29:45 | gradha | the author changed it into a docstring |
| 22:29:50 | BitPuffin | EXetoC: well I meant in C |
| 22:30:00 | * | zielmicha quit (Ping timeout: 245 seconds) |
| 22:30:39 | Araq | can somebody enhance the tester to run over any babel package and checks it compiles? |
| 22:30:43 | EXetoC | I guess it depends on what the typedef looks like |
| 22:31:10 | Araq | dom96: no threading this time? |
| 22:31:40 | dom96 | no |
| 22:32:14 | * | MFlamer quit (Read error: Connection reset by peer) |
| 22:33:38 | EXetoC | BitPuffin: and I don't see a '*' before the parameter list where the typedef is, but it's included where it's being used |
| 22:33:47 | EXetoC | hopefully these are somewhat educated guesses :p |
| 22:34:11 | Araq | dom96: are we allowed to multi-thread it? |
| 22:34:13 | * | MFlamer joined #nimrod |
| 22:34:34 | dom96 | Araq: I don't think so. |
| 22:34:47 | dom96 | Araq: https://github.com/logicchains/ParticleBench |
| 22:35:02 | BitPuffin | EXetoC: yeah we'll see if this crashes on us :P |
| 22:36:38 | OrionPKM | dont see a nimrod version |
| 22:38:01 | BitPuffin | benchmarking opengl in different languages is the most pointless thing ever btw |
| 22:38:29 | Varriount | Doesn't it all depend on video drivers? |
| 22:38:40 | Varriount | Or the firmware of the video card? |
| 22:39:05 | BitPuffin | since it is all pipelined and happens on the gpu, except for in the case where the transfer of calls and data to the GPU happens faster than the application reaches the next call to the gpu there can't be any difference |
| 22:39:14 | BitPuffin | because then the bottleneck is on the GPU |
| 22:39:26 | OrionPKM | yeah, should be software rendering benchmark |
| 22:40:06 | OrionPKM | still the CPU can slow things down a lot for gl programs, i doubt those programs all run at the same speed |
| 22:40:10 | gradha | Araq: maybe not enhace the tester, but https://gist.github.com/gradha/7796905 builds and tests the stuff |
| 22:40:43 | BitPuffin | And I'd say that if you architect your application properly it is very rare that the cpu doesn't reach the point of the next call before the gpu finishes and that's not very relevant to the language |
| 22:40:46 | Araq | gradha: we don't believe in unix shell scripting here |
| 22:40:59 | EXetoC | maybe it does some CPU-heavy stuff, but then it's not just an OpenGL benchmark |
| 22:41:07 | EXetoC | seems kinda pointless either way |
| 22:41:14 | BitPuffin | EXetoC: well then it's not an opengl benchmark period |
| 22:41:27 | BitPuffin | benchmarking opengl has nothing to do with the application level |
| 22:41:38 | BitPuffin | when you benchmark opengl you benchmark the driver and gpu |
| 22:42:10 | BitPuffin | but sure the application can be the bottleneck but then it's not related to language, it's the design of the program |
| 22:42:19 | MFlamer | It's a particle system, thats gonna be cpu bound |
| 22:42:29 | MFlamer | unless its openCL |
| 22:42:36 | gradha | good night, honey badgers |
| 22:42:48 | * | gradha quit (Quit: bbl, need to watch http://www.youtube.com/watch?v=hcDEWiH-ciw again) |
| 22:42:50 | dom96 | indeed, there is a lot of objects created I think. |
| 22:43:11 | BitPuffin | MFlamer: well then it isn't really an opengl benchmark, and I'm pretty sure you should do particle simulation in the vertex shader anyway |
| 22:43:27 | BitPuffin | unless ofc the gpu is extremely busy and the cpu is just hangin around |
| 22:43:35 | OrionPKM | so its called "ParticleBench" not "OpenGL bench" |
| 22:43:39 | BitPuffin | but at that point it's gonna vary on different hardware anyway |
| 22:43:47 | OrionPKM | OpenGL is just a visualization |
| 22:43:58 | BitPuffin | ah |
| 22:43:59 | BitPuffin | well |
| 22:44:01 | OrionPKM | thats true of every benchmark |
| 22:44:24 | BitPuffin | OrionPKM: well I mean at the point where you make such architecture decisions |
| 22:44:33 | MFlamer | Yeah, I suppose a vertex shader would work pretty well for particle stuff |
| 22:44:34 | BitPuffin | which you don't really do in benchmarks |
| 22:44:48 | BitPuffin | MFlamer: if not then the compute shader is excellent |
| 22:44:49 | Araq | MFlamer: TAny is as close as Top as you can get when you've value based types |
| 22:45:14 | * | zielmicha1 quit (Ping timeout: 264 seconds) |
| 22:45:15 | OrionPKM | mflamer vertex shaders cant create vertices |
| 22:45:21 | OrionPKM | you'd need a geometry shader for that |
| 22:45:40 | EXetoC | do you mean BitPuffin? |
| 22:45:47 | EXetoC | nvm I misread |
| 22:46:34 | MFlamer | Araq: can we instantiate generics with TAny? I havent looked into that one, I'll check it out. Did my use case make a litle sense? |
| 22:47:04 | Araq | haven't looked at your use case, sorry |
| 22:47:24 | MFlamer | OrionPKM: Yeah, I know tesselation shader even better than geometry shader, right? |
| 22:47:31 | Araq | and TAny is only the representation part at runtime |
| 22:47:40 | Araq | there are no converters to TAny |
| 22:47:49 | OrionPKM | mflamer I stopped paying attention after SM 3 :) |
| 22:48:06 | MFlamer | Araq: No worries, I knoe you have much more pressing issues |
| 22:48:07 | OrionPKM | I havent done graphics stuff since college |
| 22:48:14 | BitPuffin | OrionPKM: what's vertices got to do with particle simulation |
| 22:48:30 | OrionPKM | each particle = 1 vertice in a vertex buffer, typically |
| 22:48:43 | BitPuffin | OrionPKM: yeah but the vertex is passed in |
| 22:48:48 | MFlamer | OrionPKM: I'm not up to date either, that arena moves very quickly |
| 22:49:05 | BitPuffin | that's like suggesting that we can't project geometry because the vertex shader can't create vertices |
| 22:49:05 | OrionPKM | yeah the vertex is created on the CPU |
| 22:49:11 | OrionPKM | unless it's from a geometry shader |
| 22:49:32 | BitPuffin | OrionPKM: yeah but you can still update it in the vertex shader |
| 22:49:40 | BitPuffin | the simulation doesn't have to happen on the cpu |
| 22:50:40 | MFlamer | brb |
| 22:50:54 | OrionPKM | yeah you can translate vertices, what's your point |
| 22:51:16 | BitPuffin | OrionPKM: I mean that you can simulate the particle's movement in the vertex shader |
| 22:51:30 | OrionPKM | yes, you can |
| 22:51:34 | BitPuffin | ofc it can't react to the environment |
| 22:51:45 | BitPuffin | for that you'd need to do it either in a compute shader or on the cpu |
| 22:51:58 | Varriount | BitPuffin why not? |
| 22:51:59 | OrionPKM | well, I wouldn't say that, but okay |
| 22:52:31 | BitPuffin | Varriount: Because the vertex shader deals with one vertex at a time and doesn't know about the surrounding world |
| 22:52:44 | BitPuffin | unless you pass in some uniforms etc, but that storage is limited |
| 22:52:46 | OrionPKM | it can know about the surrounding world if you tell the shader about the surrounding world |
| 22:53:19 | BitPuffin | well |
| 22:53:32 | BitPuffin | actually that's not even the reason why it can't react to the world |
| 22:53:52 | BitPuffin | simulating particles in the vertex shaders means that it's stateless and has to be according to a function of time |
| 22:54:26 | Varriount | BitPuffin, how much data can a vertex hold? |
| 22:54:48 | OrionPKM | color/xyzw |
| 22:54:58 | Varriount | w? |
| 22:55:06 | BitPuffin | But I guess you could pass something in to that function of time but then you'd have to keep passing in the same thing in order for the result in the future to be deterministic |
| 22:55:13 | BitPuffin | so you'd run out of memory |
| 22:55:30 | OrionPKM | you're generalizing |
| 22:55:44 | BitPuffin | Varriount: you mean how many slots there are for uniforms and attributes? |
| 22:56:51 | OrionPKM | varriount vector4 |
| 22:57:19 | BitPuffin | OrionPKM: what do you mean I am generalizing |
| 22:57:33 | OrionPKM | I mean your environment might just be a simple XZ plane |
| 22:57:53 | OrionPKM | particles could easily bounce off of it |
| 22:58:15 | BitPuffin | OrionPKM: well sure but the environment can't change |
| 22:58:47 | BitPuffin | OrionPKM: and if it does change, in order for the result to be the same you are gonna have to keep passing in all the previous changes continuously |
| 23:00:31 | * | Varriount_ joined #nimrod |
| 23:02:10 | OrionPKM | varriount did you get my message? |
| 23:02:56 | BitPuffin | Varriount: if you wanna know how much data can be associated per vertex you are gonna have to get the least required vertex attributes for the GL version you are targeting, or for your gpu glGet(GL_MAX_VERTEX_ATTRIBS) |
| 23:03:27 | BitPuffin | Varriount: and then if you want to know how much data can be associated per vertex batch you are gonna have to look up how many uniforms you can have in the gl version or on your gpu |
| 23:03:35 | * | Varriount quit (Ping timeout: 245 seconds) |
| 23:03:35 | * | Varriount_ is now known as Varriount |
| 23:03:43 | MFlamer | Araq: the idea was to have a type that can be used to instantiate a "None" variant of some type like TBTree[string]. Basicly a useless dummy type that can pass for anything, but do nothing |
| 23:04:10 | Araq | well we have 'void' for that |
| 23:04:15 | BitPuffin | GL_MAX_VERTEX_UNIFORM_COMPONENTS |
| 23:04:31 | Araq | and TTable[TKey, void] is conceptually a TSet[TKey] |
| 23:04:42 | Araq | it's quite useful indeed |
| 23:04:59 | MFlamer | oh, ok maybe that all I need |
| 23:05:39 | Araq | dom96: please post your benchmark on the forum and see what people will come up with |
| 23:07:40 | EXetoC | MFlamer: yeah, I thought it would be useful for some generic args for example |
| 23:08:06 | EXetoC | where you do something different if it is "void", but void cannot be instantiated atm |
| 23:09:52 | MFlamer | A simple example is in TMaybe[T] where you would want a None variant that has no fields, so T is useless. I dont want None to need a type to instantiate |
| 23:10:42 | dom96 | Araq: Ok, i'll do that later. |
| 23:10:43 | dom96 | Good night |
| 23:10:52 | EXetoC | isn't it basically a type in Rust? an enumerator that doesn't have any fields |
| 23:11:16 | MFlamer | I'll have to see how fowl handles this in his Maybe implementation |
| 23:12:00 | MFlamer | TMaybe[T] has 2 variants Just[T] x: T and None |
| 23:13:19 | MFlamer | Just[T] has 1 field of type T, None has no fields so a None of TMaybe[int] should be the same and be interchangeable with a None of TMaybe[string] |
| 23:13:59 | MFlamer | I think I have tried void and it does not serve this purpose |
| 23:14:43 | MFlamer | a constructor function "None(): TMaybe[?]".......thats the problem |
| 23:15:08 | EXetoC | yes, it's verbose |
| 23:15:43 | fowl | mine is just tuple[bool, T] |
| 23:15:52 | EXetoC | I think I tried to shorten something similar at one point, but I might've run into a limitation with 'converter' then |
| 23:16:53 | MFlamer | fowl: OK, so true and false are the same size |
| 23:16:56 | fowl | i decided to it this way for two main reasons: it doesnt save an space to use a variant type, with variant type its impossible to switch between them without reset()ing the object |
| 23:17:49 | fowl | also, being able to do if(var (has, val) = someMaybeOp(); has): use val |
| 23:17:53 | EXetoC | MFlamer: what else? should it resize dynamically? |
| 23:18:25 | MFlamer | fowl: Yeah, I'm trying to hack together an alternative rep for variants that uses a struct instead of a union to avoid the size thing, pretty tough though |
| 23:21:05 | fowl | well i dont see how you can avoid it, None[T] and Just[T] have to be the same size |
| 23:21:17 | MFlamer | EXetoC: not necessarily, thats a different issue. I guess for now I'll have to live witha none constructor like "None[int](): TMaybe[int]" |
| 23:22:23 | EXetoC | fowl: unless you allocate, which is what I was implying. that sucks obviously :p |
| 23:22:51 | MFlamer | fowl: Only with the backend creating a union. Theoreticly possible to generate a different struct for each variant. I have started a compiler patch, but there are some parts of it that I just dont know how to accomplish yet |
| 23:24:00 | MFlamer | Yeah, or allocate. Which is how most compilers do ADT's |
| 23:25:26 | fowl | ah |
| 23:25:34 | EXetoC | is the difference purely conceptual in this case? struct vs union |
| 23:27:01 | MFlamer | well, with strucs each variant can be a different size. So, "None" only needs to be a byte or whatever to hold the variant tag, While Some[T] couls be huge |
| 23:27:07 | MFlamer | could* |
| 23:27:52 | MFlamer | but, you could never reset |
| 23:28:55 | MFlamer | if thats what you meant |
| 23:31:55 | EXetoC | it's common to allocate in this case? I just thought it might incur some runtime overhead |
| 23:34:12 | MFlamer | I'm no expert but, I believe Haskell and Rust (ADT's or enums with fields) are represented as a pointer to the struct(fields) and a variant tag. So each variant is the same size (like 2 words for example) |
| 23:36:29 | MFlamer | there's another indirection, but that's the price you pay for the elegance of ADT's |
| 23:41:06 | EXetoC | do you really save so much space in general that it's worth allocating? |
| 23:44:20 | MFlamer | with a simple type like Maybe, probably not, but with big trees you might |
| 23:45:25 | EXetoC | can't the actual var be dynamically allocated then? if said programmer realizes that it incurs a lot of overhead |
| 23:46:37 | EXetoC | or maybe that would be a common occurrence. I wouldn't know really |
| 23:48:28 | MFlamer | In a functional language like haskell, everything is dynamicly allocated but immutable so there is no choice |
| 23:48:45 | EXetoC | right |
| 23:52:33 | EXetoC | so what if the compiler decides what to do for each individual type? if it's not too much work to implement |
| 23:53:31 | MFlamer | what do you mean? |
| 23:54:17 | MFlamer | like, allocate dyn for large stuff and just use a union otherwise? |
| 23:54:29 | EXetoC | something like that |
| 23:55:02 | EXetoC | does that make sense? |
| 23:56:22 | MFlamer | The user could just make that decision as it stands now. It just gets more verbose because then you have an object with variants and the seperate objects for the actual fields |
| 23:57:15 | MFlamer | But, we could also package all this up into a sweet macro |
| 23:58:00 | MFlamer | which brings me to a question I've been wanting to ask... |
| 23:58:24 | MFlamer | can you move up the ast in a macro? |
| 23:58:47 | fowl | up from callsite()? |
| 23:58:50 | EXetoC | no, you can't go outside the call site |
| 23:59:03 | MFlamer | like if the user is in a type block and we want him to call a macro that creates some proc |
| 23:59:12 | MFlamer | yes, up from callsite |
| 23:59:29 | fowl | no |
| 23:59:31 | EXetoC | MFlamer: macro for what? for defining the allocation strategy or something else? |
| 23:59:40 | MFlamer | ok, thanks fowl |
| 23:59:56 | fowl | once types are usable in type sections, its concievable that you could return a stmt list where you could define procs |
