| 00:01:44 | renesac | why we can't ask for 'inline' at the call site instead of the function definition? |
| 00:01:58 | renesac | this is a general question, not really nimrod specific |
| 00:04:20 | Demos | well "inline" does not do anything in c/c++, it is just a linker directive. In nimrod it is because it is not implemented yet |
| 00:04:40 | Demos | also, it causes problems when you do not actually have the code for a given function |
| 00:04:50 | renesac | Demos, it is a hint for the compiler |
| 00:05:05 | Demos | I dont think modern compilers treat it as a hint |
| 00:05:23 | Demos | it disables the ODR |
| 00:05:33 | renesac | IIRC GCC -O3 will inline by default functions up to x size |
| 00:05:55 | renesac | but if said function is declared as inline, it will accept a much larger function |
| 00:06:02 | Demos | right, but the only functions it can inline are those declared inline, or templates, or inline member functions |
| 00:06:09 | Demos | unless you turn on lto |
| 00:06:12 | Demos | or do a unity build |
| 00:06:14 | renesac | and if __AWAYS_INLINE (or something like that), it will aways inline |
| 00:06:51 | Demos | again I dont see how gcc can even inline anything that does not already have inline linkage |
| 00:07:11 | Demos | (except for lto and unity builds ofc) |
| 00:09:58 | renesac | hum, so it is a problem when you don't have the whole source code at hand |
| 00:14:12 | Demos | yeah, in general I would just let the nimrod and C compilers decide what to inline |
| 00:15:35 | Demos | the motivation for being able to get the AST of any proc is to do stuff like rewriting that proc to run on the GPU and stuff, not to do inlineing |
| 00:17:16 | renesac | I wonder if anonymous procs are inlined by default... I guess they normally are by the C compiler, given that they are short |
| 00:18:01 | renesac | though I haven't looked at how long nimrod makes them it's output C |
| 00:20:05 | fowl | renesac, no, they have to be able to be passed around and carry an environment with them |
| 00:20:14 | Demos | you could test by making a nice big array and compareing nimrod's sort to c++'s std::sort |
| 00:21:12 | renesac | fowl, oh, true |
| 00:21:27 | renesac | even if they are not returned by the function? |
| 00:21:34 | renesac | like simple lambdas? |
| 00:24:38 | fowl | renesac, i guess in theory it could be inlined if its not passed around at all, it doesnt apply to many cases though |
| 00:25:08 | fowl | like if you wanted to do echo (proc(): int = 4)() |
| 00:25:59 | renesac | well, I'm thinking more as a lambda passed as a parameter for a function |
| 00:26:01 | renesac | like map() |
| 00:26:28 | renesac | I guess you can never know what the function will do with the function you passed to it... |
| 00:26:37 | renesac | *closure |
| 00:27:27 | * | zahary1 quit (Quit: Leaving.) |
| 00:27:51 | * | zahary1 joined #nimrod |
| 00:31:05 | Demos | I just timed it with sort. Nimrod is like twice as slow as c++, but it could be random num generation |
| 00:31:26 | renesac | Demos, generate the random number array first, then start the timer |
| 00:31:35 | Demos | yeah |
| 00:32:19 | * | zahary1 quit (Ping timeout: 264 seconds) |
| 00:32:52 | Demos | changed from random() to rand() in nimrod and we are now way faster than c++ |
| 00:33:20 | Demos | damn rand() is compile time |
| 00:33:38 | renesac | take the random()/rand() out of the picture |
| 00:33:40 | renesac | yeah |
| 00:35:31 | Demos | yeah what library can I use in nimrod to time things/get accurate timers |
| 00:36:09 | renesac | https://github.com/Araq/Nimrod/blob/devel/lib/system/timers.nim <-- this isn't public |
| 00:36:24 | renesac | I was going to work on it btw |
| 00:37:03 | renesac | in the mean time, you can do many loops and time outside it |
| 00:37:11 | renesac | *another alternative is |
| 00:37:31 | renesac | so you have some seconds, where the timer precision isn't a isseu |
| 00:37:36 | renesac | issue |
| 00:38:24 | renesac | one of the reasons I'm asking those questions is to see if I can make my 'timeit' function a proc instead of a template |
| 00:38:47 | renesac | but it seems it needs to be a template if I don't want extra function call overhead |
| 00:44:51 | * | brson joined #nimrod |
| 00:46:33 | Demos | OK it looks like nimrod inlines simple lambda functions |
| 00:50:25 | Demos | fuck me g++ generates a lot of code |
| 00:53:21 | Demos | even with that little short program the nimrod version is 1/2 as long and 1/2 as wide |
| 00:54:33 | Demos | and renesac take a look at std::chrono (http://en.cppreference.com/w/cpp/header/chrono) it is pretty well designed |
| 01:15:41 | * | eximius quit (Disconnected by services) |
| 01:16:38 | * | brson quit (Ping timeout: 252 seconds) |
| 01:21:05 | renesac | Demos, nice, but I'm not sure if I can trust it to inline aways |
| 01:21:29 | Demos | well if it can inline and it would actually be a good idea to inline it probably will |
| 01:21:40 | renesac | is the nimrod binary bigger or smaller than c++? |
| 01:22:59 | Demos | a bit bigger |
| 01:23:26 | renesac | oh, considering that nimrod has to fit a whole GC in it, not bad |
| 01:23:39 | Demos | but nobody cares, also c++ may dynamic link libc++ |
| 01:24:11 | Demos | yup! |
| 01:24:23 | renesac | yeah |
| 01:25:13 | Demos | anyway comparing the sizes of little programs is super pointless |
| 01:26:01 | renesac | Demos, for my benchmark usage, I will convert the high resolution times to a simple floating point value... like nimrod times does |
| 01:26:25 | Demos | make sure not to do arithmetic on it |
| 01:26:35 | Demos | like don't accumulate it |
| 01:26:46 | Demos | for a library you usually want to store times in integers |
| 01:27:39 | renesac | precision problems will be significant if using a float64? |
| 01:27:48 | renesac | it has a 53bit mantissa.. |
| 01:28:30 | renesac | and clock precision varies between OSes |
| 01:31:08 | Demos | clock precision varies between CPUs, if your OS does not let you use the CPUs high precision clock you should get a better OS |
| 01:31:41 | BitPuffin | Demos: why do you think it is a strange choice? |
| 01:32:02 | Demos | BitPuffin: why do I think what is a strange choice |
| 01:32:07 | BitPuffin | Demos: C :P |
| 01:32:20 | BitPuffin | Demos: I'm not either close to being done yet, lucklily it's a minild |
| 01:32:31 | BitPuffin | Demos: the thing is, I accidentally started ray tracing |
| 01:32:40 | * | brson joined #nimrod |
| 01:32:42 | BitPuffin | and now I have to optimize before I even have stuff on the screen haha |
| 01:32:52 | renesac | http://nadeausoftware.com/articles/2012/03/c_c_tip_how_measure_cpu_time_benchmarking <-- many options |
| 01:33:02 | Demos | wow welcome to the party. I think it is a strange choice because it prioritized speed that you will likely not need. I am using love for that reason, although I have not worked on it today... |
| 01:33:12 | renesac | bbl |
| 01:33:34 | BitPuffin | Demos: well I can't even imagine how slow it would be in something like lua |
| 01:33:52 | BitPuffin | Demos: the speed is definitely needed, do you realize the computing power it takes to ray trace in real time :P |
| 01:34:09 | fowl | how intensive ray tracing do you need for a demake though |
| 01:34:09 | BitPuffin | I am gonna implement trees and shit xD |
| 01:34:48 | BitPuffin | fowl: it's not bouncing light or anything so not very |
| 01:34:58 | BitPuffin | still though it's pretty intensive |
| 01:35:09 | Demos | ray casting was a common way to render back in the day |
| 01:35:28 | BitPuffin | considering I get ~20 FPS when only calculating the directions for each pixel |
| 01:35:33 | BitPuffin | Demos: yeah but ray casting is done in 2d |
| 01:35:40 | BitPuffin | I'm doing essentially ray casting in 3d |
| 01:36:04 | BitPuffin | so say you are rendering with 800*600 resolution |
| 01:36:10 | Demos | oh, I thought ray casting was like ray tracing but with just one bounce and like one ray per pixel |
| 01:36:13 | BitPuffin | with regular oldschool ray casting that would be 800 rays |
| 01:36:19 | Demos | oh |
| 01:36:20 | Demos | right |
| 01:36:23 | BitPuffin | but with my method it is 800*600 |
| 01:36:49 | EXetoC | luajit excluded I assume |
| 01:36:54 | BitPuffin | 480 000, as opposed to 800 |
| 01:37:04 | BitPuffin | EXetoC: there is also that language |
| 01:37:07 | BitPuffin | EXetoC: you know |
| 01:37:12 | BitPuffin | the systems programming variant of lua |
| 01:37:49 | BitPuffin | Terra |
| 01:37:58 | BitPuffin | http://terralang.org/ |
| 01:39:19 | Demos | well nimrod looks better :D |
| 01:40:29 | BitPuffin | Demos: and it's not designed to interoperate with Lua and C |
| 01:40:32 | BitPuffin | completely different languages :P |
| 01:41:20 | Demos | I guess |
| 02:03:12 | * | DAddYE joined #nimrod |
| 02:03:59 | * | Demos quit (Quit: Textual IRC Client: www.textualapp.com) |
| 02:07:48 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 02:09:03 | fowl | Warning: Cannot prove that 'ev' is initialized. This will become a compile time error in the future. [ProveInit] |
| 02:09:29 | fowl | will there be a way to ignore it? |
| 02:11:43 | * | Demos joined #nimrod |
| 02:40:01 | * | brson quit (Ping timeout: 240 seconds) |
| 03:03:51 | * | DAddYE joined #nimrod |
| 03:05:06 | * | Demos_ joined #nimrod |
| 03:07:37 | * | Demos quit (Ping timeout: 240 seconds) |
| 03:08:01 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 03:12:16 | * | Demos joined #nimrod |
| 03:15:13 | * | Demos_ quit (Ping timeout: 240 seconds) |
| 04:44:36 | * | darkf quit (Ping timeout: 253 seconds) |
| 04:46:40 | * | darkf joined #nimrod |
| 04:48:06 | * | DAddYE joined #nimrod |
| 05:00:15 | * | runvnc joined #nimrod |
| 05:58:30 | * | DAddYE quit (Remote host closed the connection) |
| 06:10:41 | * | DAddYE joined #nimrod |
| 06:22:59 | * | Demos quit (Read error: Connection reset by peer) |
| 07:18:42 | * | DAddYE quit (Remote host closed the connection) |
| 07:19:08 | * | DAddYE joined #nimrod |
| 07:19:23 | * | Zuchto quit (Ping timeout: 268 seconds) |
| 07:19:38 | * | renesac quit (Ping timeout: 240 seconds) |
| 07:20:06 | * | renesac joined #nimrod |
| 07:23:18 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 07:24:41 | * | Zuchto joined #nimrod |
| 07:28:02 | * | zahary1 joined #nimrod |
| 07:58:53 | * | zahary1 quit (Quit: Leaving.) |
| 08:02:56 | * | Mordecai joined #nimrod |
| 08:02:59 | * | psquid quit (Ping timeout: 240 seconds) |
| 08:03:15 | * | Mordecai is now known as Guest10997 |
| 08:19:42 | * | DAddYE joined #nimrod |
| 08:21:44 | * | Endy joined #nimrod |
| 08:24:04 | * | DAddYE quit (Ping timeout: 246 seconds) |
| 08:28:37 | * | BitPuffin quit (Ping timeout: 268 seconds) |
| 08:45:34 | * | brihat joined #nimrod |
| 08:45:36 | * | brihat1 joined #nimrod |
| 08:45:42 | * | brihat left #nimrod (#nimrod) |
| 08:45:47 | * | brihat1 quit (Client Quit) |
| 08:45:59 | * | zahary1 joined #nimrod |
| 08:51:36 | * | faassen joined #nimrod |
| 08:59:22 | * | zahary1 quit (Quit: Leaving.) |
| 09:01:08 | * | BitPuffin joined #nimrod |
| 09:20:18 | * | DAddYE joined #nimrod |
| 09:23:34 | * | runvnc quit (Quit: Leaving) |
| 09:24:25 | * | runvnc joined #nimrod |
| 09:24:44 | * | BitPuffin quit (Ping timeout: 268 seconds) |
| 09:24:51 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 09:28:02 | flyx | morning folks |
| 09:28:54 | flyx | is the opengl binding usable? I get "SIGSEGV: Illegal storage access. (Attempt to read from nil?)" when calling glMatrixMode |
| 09:29:41 | flyx | … or any other method from it |
| 09:32:43 | * | CarpNet joined #nimrod |
| 09:47:36 | flyx | it seems like the "new" opengl binding just uses stdcall no matter what, while the old gl binding uses the correct calling convention, which works |
| 09:48:53 | * | BitPuffin joined #nimrod |
| 09:57:40 | * | XenMaster joined #nimrod |
| 10:05:49 | Skrylar | meep! |
| 10:17:09 | * | [1]Endy joined #nimrod |
| 10:18:02 | NimBot | Araq/Nimrod devel 711c798 Zahary Karadjov [+1 ±2 -0]: failing test case preventing the use of --gc:v2: tsymchoicefield |
| 10:18:21 | * | zahary_ joined #nimrod |
| 10:19:58 | * | Endy quit (Ping timeout: 240 seconds) |
| 10:19:58 | * | [1]Endy is now known as Endy |
| 10:22:00 | zahary_ | Araq, do you think we should have some kind of parity between procs and fields. if x.someProc could be a proc, should we also support someField( x )? |
| 10:24:24 | zahary_ | take a look at a failing test case that I pushed for which I'm not sure how the fix should be approached. it's somewhat related to the question above |
| 10:39:18 | Skrylar | zahary: is there a use case for doing that? |
| 10:39:30 | Skrylar | X(someObject) |
| 10:40:19 | zahary_ | only relatively silly arguments. you could do map(list, name) - where name could be both a function or a field |
| 10:42:20 | Skrylar | i guess you could do that, and have functions resolve before fields |
| 10:42:31 | zahary_ | if you want your code to be generic, you should be careful to prefer the dot syntax at the moment, because it will handle both fields and procs |
| 10:43:03 | Skrylar | yeah, i ran in to that with some rect code |
| 10:43:20 | Skrylar | what happens if you have a function and field with the same name though? |
| 10:43:30 | Skrylar | i guess a magic GetField(x,y) could solve that |
| 10:43:51 | zahary_ | they could be overloaded normally |
| 11:08:42 | Skrylar | Nimrod's AST is crazy looking o_O |
| 11:09:05 | Skrylar | Dumped a tree repr to look at some macro output and there's this huge stack of "open sym list" and the same identifier a dozen times |
| 11:25:21 | * | Trimsty joined #nimrod |
| 11:31:46 | Araq | zahary_: in fact 'x.y' is broken in generics right now |
| 11:32:05 | Araq | so "prefer dot access in generics" doesn't even work as a rule |
| 11:32:22 | Araq | fix should be easy though but could break code |
| 11:33:43 | Araq | I like to have full x.f vs f(x) interoperability |
| 11:34:15 | Araq | but x.f() is ambiguous if 'f' is a proc field |
| 11:35:10 | Araq | we could always transform x.f() to f(x) and require (x.f)() to call the *field* but that's ugly when you use closures for interfaces |
| 11:38:21 | Araq | and at that point I gave up and left the rules as they are now ... |
| 11:39:46 | Araq | what we should do instead is to provide easy-to-use readonly field access so no trivial getters are to be generated |
| 11:40:09 | Araq | we could use + instead of * for public readonly fields |
| 11:40:34 | Araq | write access is still allowed in the same module for initialization |
| 11:41:01 | * | clovis joined #nimrod |
| 11:41:01 | * | clovis left #nimrod (#nimrod) |
| 11:44:27 | Araq | flyx: stdcall is mapped to cdecl when os != windows |
| 11:44:42 | Araq | seems unlikely that this is your problem |
| 11:46:31 | Araq | Skrylar: yeah we should fix the view of symbol choices |
| 11:46:32 | flyx | Araq: I don't see any other difference between the bindings |
| 11:47:10 | Araq | flyx: well do the old bindings work and the new don't? what's the error message? |
| 11:47:26 | Araq | hi XenMaster welcome |
| 11:48:01 | flyx | Araq: the old bindings work, the new produce the segfault I pasted |
| 11:49:42 | Araq | call loadExtensions() after you setup the context |
| 11:50:43 | flyx | ah, that works |
| 11:50:53 | Araq | I guess this should make it into the FAQ lol |
| 11:50:56 | flyx | glMatrixMode is hardly an extension, is it? |
| 11:51:07 | Araq | true that's weird |
| 11:51:27 | Araq | but I'm no opengl expert, ask fowl when he's around |
| 11:51:36 | Araq | or BitPuffin or whoever |
| 11:52:14 | Araq | maybe the new wrapper thinks glMatrixMode is an extension |
| 11:52:24 | flyx | well I did similar things when writing an OpenGL binding for Ada. You can query *all* OpenGL functions that have been added in v1.1 or later. that makes sense if you don't know which OpenGL version you're running against |
| 11:53:17 | Araq | well we have special compiler support for opengl so that dead code elimination continues to work |
| 11:53:22 | BitPuffin | wat |
| 11:53:28 | BitPuffin | why are you using glMatrixMode |
| 11:53:34 | flyx | but it's still weird because glMatrixMode is OpenGL 1.0 |
| 11:53:38 | BitPuffin | why would you do legacy GL |
| 11:53:45 | Araq | bbl |
| 11:53:55 | BitPuffin | all matrix stuff has been deprecated since 3.0 and removed from core in 3.1 and upwards |
| 11:54:13 | BitPuffin | you construct them yourself and send them to the shaders instead |
| 11:54:14 | flyx | BitPuffin: because I just write some tests and the OGL 3.x stuff is way too much overhead for them |
| 11:54:27 | BitPuffin | flyx: well okay |
| 11:54:38 | BitPuffin | flyx: is glMatrixMode not in the binding? |
| 11:54:58 | flyx | BitPuffin: it is, but as Araq said, it only works after calling loadExtensions() |
| 11:55:01 | BitPuffin | bcause if it is, it should just be a matter of creating a context with old opengl |
| 11:55:10 | BitPuffin | that's weird |
| 11:55:57 | flyx | I'm on OSX, it's creating an OGL 2.x context by default (unless I specify otherwise), so backwards compatibility shouldn't be the problem |
| 11:56:16 | flyx | anyway, seems like I have a glfw3 binding ready |
| 11:56:39 | BitPuffin | pretty sure glfw3 creates a gl 3.x context by default |
| 11:56:45 | BitPuffin | don't even know if it supports lesser |
| 11:56:47 | BitPuffin | ask in #glfw |
| 11:56:49 | BitPuffin | I'm not sure |
| 11:56:55 | flyx | I'm pretty sure |
| 11:57:08 | flyx | I have used it in the past with Ada on OSX and other platforms |
| 11:58:43 | BitPuffin | glfw3? |
| 11:58:46 | BitPuffin | or just glfw2 |
| 11:58:52 | BitPuffin | glfw2 creates old by default |
| 11:59:08 | flyx | both |
| 11:59:35 | flyx | see http://www.glfw.org/docs/latest/window.html#window_hints_values |
| 12:00:20 | flyx | on OSX, you have to explicitly query a core profile to get a 3.x context |
| 12:00:41 | flyx | by default, you get a compat profile |
| 12:04:05 | Skrylar | I'm pretty sure they removed the compat profile from OSX, unles they put it back |
| 12:06:29 | flyx | well it works here, so I don't see how discussing that it shouldn't work gets us anywhere |
| 12:18:19 | * | Skrylar prods Araq, zahary and fowl to peer at this: https://gist.github.com/Skrylar/9739068 before skry spends a while engaging in macro-fu |
| 12:21:07 | XenMaster | hypothetically: person X knows only python, is very smart, and wants to help develop nimrod, what should he do? |
| 12:23:41 | Skrylar | they really like compiler patches, though thats probably a bit too deep |
| 12:24:58 | flyx | has anyone done a yaml parser for nimrod yet? |
| 12:25:18 | Skrylar | i don't think theres a stdlib one |
| 12:25:34 | Skrylar | yaml is kind of nasty to parse :( |
| 12:25:51 | flyx | it seems like a good opportunity to test nimrod's metaprogramming features, but I don't want to do work that has already done by someone else |
| 12:27:54 | Skrylar | i don't see one on a google search |
| 12:28:06 | flyx | neither did I |
| 12:28:10 | XenMaster | nobody wants help from smart X? (X is realises he needs to learn something before contributing...) |
| 12:28:31 | flyx | let's see how far I get |
| 12:30:44 | Skrylar | XenMaster: it'd be better to ask araq or zahary directly, since those two would know more about it |
| 12:30:51 | Skrylar | as far as helping nimrod directly |
| 12:32:06 | XenMaster | :araq, zahary: how can smart pers X, who knows only python, help working on nimrod? whats the next thing he should learn if python isnt sufficient? |
| 12:33:12 | zahary_ | XenMaster, are the parts of the language that are particularly foreign to you? |
| 12:33:23 | zahary_ | are there * |
| 12:33:54 | XenMaster | you mean nimrod? |
| 12:34:11 | XenMaster | or python? |
| 12:34:14 | zahary_ | yes, isn't your question about you learning nimrod? or is it about contributing |
| 12:34:33 | XenMaster | it is about contributing |
| 12:35:35 | XenMaster | I wanna contribute because i see future in nimrod, and i could learn from it |
| 12:36:18 | zahary_ | ah, I see. good. if you want to dive into the deep and contribute to the compiler itself, I have always suggested implementing type traits as a first step |
| 12:37:15 | zahary_ | otherwise, there are few infrastructure projects that need more work - nimbuild come to mind |
| 12:37:37 | zahary_ | and everyone working on a libraries is helping both as a tester for our new cool stuff and by spreading the word |
| 12:38:10 | XenMaster | compiler is most appealing |
| 12:39:13 | zahary_ | see my comments here if you are interested in the type traits I mentioned: http://forum.nimrod-lang.org/t/297 |
| 12:45:04 | Araq | XenMaster: IMHO the best starting point is the tester |
| 12:45:24 | Araq | https://gist.github.com/anonymous/7abcfc8994d5c77a6980 |
| 12:46:25 | Araq | the failing tests need to be repaired |
| 12:46:35 | XenMaster | Araq: would you have said the same if X is smartest person in this room (hypethetically)? |
| 12:47:10 | Araq | no |
| 12:47:23 | zahary_ | actually fixing the tests in much more hardcore than what I suggested :) |
| 12:47:38 | XenMaster | would you have said compiler araq? |
| 12:47:46 | Araq | then I would have said, "fix the remaining closure-related bugs by modifying compiler/lambdalifting.nim" |
| 12:47:59 | XenMaster | ok |
| 12:49:12 | Araq | or: "implement write tracking" |
| 12:49:21 | Araq | or: "implement the new concurrency model" |
| 12:49:45 | XenMaster | I'll look into concurrency |
| 12:49:54 | Araq | or "implement the pure RC'ing GC for best interop with evil Objective C framework" |
| 12:50:32 | zahary_ | codegen improvements are relatively easy to do - you could try to implement precise stack marking for the current GCs |
| 12:51:02 | XenMaster | I like the challenge of concurrency |
| 12:53:59 | Araq | the concurrency stuff is all frontend related though, the backend already exists |
| 12:57:07 | XenMaster | backend is bugfree? |
| 13:00:05 | flyx | is nimrod's compiler available through the stdlib? I think the nimrod lexer would be a good starting point for implementing yaml. |
| 13:00:37 | Skrylar | hm |
| 13:01:09 | Skrylar | as i understand it, 'var' implies pointer yes? so it ought to be safe to jink around the type system and call a proc(pointer) and hope for the best |
| 13:01:27 | Skrylar | (i wouldn't advocate this in regular code, but its to go in behind a delegate type) |
| 13:04:25 | Araq | 'var' is a hidden pointer yes |
| 13:04:49 | Araq | XenMaster: the GC and backend stuff exists and is stable when it comes to threading |
| 13:05:06 | Araq | the major problem is that the frontend doesn't catch mistakes |
| 13:05:46 | Araq | so it's easy to blame the backend when it's in fact a subtle bug in your code that a smarter compiler should have caught |
| 13:06:54 | Skrylar | Araq: i'm working on the event queue/map version today :P |
| 13:07:46 | Araq | well actually ... the concurrency model builds onto our existing technology and has been designed so that I can implement it this year in my spare time :P |
| 13:08:16 | Araq | with more resources it might look rather differently |
| 13:20:18 | Araq | XenMaster: you know about my blog, right? http://nimrod-lang.org/blog/ |
| 13:20:40 | Araq | I have a working prototype for 'spawn' which I can send to you |
| 13:21:26 | XenMaster | Bitpuffin has showed me |
| 13:22:37 | XenMaster | originally, I wanted to implement a cryptoproof messenger in nimrod, but the more I read about it, the more I am interestd in working on nimrod |
| 13:22:51 | XenMaster | if I can find a challenge in that, I will do that |
| 13:23:15 | Araq | can't think of anything more challenging ... well ok, I can :P |
| 13:24:12 | * | io2 joined #nimrod |
| 13:25:13 | XenMaster | to contribute, learn C or nimrod? |
| 13:28:03 | Araq | nimrod |
| 13:28:25 | BitPuffin | I showed what? |
| 13:28:38 | BitPuffin | ah |
| 13:28:40 | BitPuffin | the blog |
| 13:29:18 | BitPuffin | indeed Araq, I point people in the right direction when you are not here, so don't think I'm not a nimrod guy just because I code C and objective C at the moment XD |
| 13:29:53 | Araq | BitPuffin: you know |
| 13:30:15 | Araq | if you said "waaa nim not stable, I'm using c++", I would understand |
| 13:30:16 | BitPuffin | no I don't :o |
| 13:30:18 | BitPuffin | ah |
| 13:30:39 | BitPuffin | Araq: why? |
| 13:30:45 | BitPuffin | C++ is so much shittier than C |
| 13:31:02 | BitPuffin | Good C++ code = basically C |
| 13:31:09 | Araq | no |
| 13:31:51 | Araq | C = full of "if (errno) goto error;" |
| 13:32:14 | BitPuffin | I have no such line in my code |
| 13:32:42 | BitPuffin | i have something like if (!al_init()) return false; though |
| 13:32:43 | EXetoC | whatever your approach is then |
| 13:32:50 | BitPuffin | but that code wolud be identical in C++ |
| 13:33:11 | BitPuffin | EXetoC: do you really think I have time for error handling in a jam game :P |
| 13:33:43 | EXetoC | I guess not |
| 13:34:09 | BitPuffin | I just assume the files are there and load them for example |
| 13:35:08 | Araq | BitPuffin: ok fair point, error handling is quite dependent on the problem |
| 13:36:31 | EXetoC | Araq: speaking of var, who created the opengl modules? because someone was complaining about having to cast nil to var in some cases |
| 13:36:51 | EXetoC | I guess var makes sense as long as 'nil' isn't valid |
| 13:37:02 | Araq | I pas2nim'ed the opengl wrapper and cleaned it up a bit |
| 13:37:16 | Araq | I assumed 'var' is fine where the delphi version used 'var' |
| 13:37:23 | Araq | apparently I was wrong :P |
| 13:37:59 | EXetoC | is 'var' in delphi different in this respect? |
| 13:39:09 | EXetoC | either that or the delphi version is badly implemented |
| 13:40:04 | Araq | the latter |
| 13:40:16 | Skrylar | intriguing. nimrod gets confused if you try to assign 'result' in a function definition within a quote do: |
| 13:40:25 | Skrylar | however it understands return correctly |
| 13:42:09 | zahary_ | Skrylar, quote do just produces verbatim AST - what are effect are you expecting from a result assignment there? |
| 13:43:26 | zahary_ | *what effects* ; it will just give the AST of the "result = x" statement |
| 13:43:58 | Skrylar | hold on, let me gist it |
| 13:44:10 | Skrylar | it actually makes sense to do "result = something" where I do it |
| 13:44:27 | EXetoC | Araq: finding all cases where 'var' is acceptable is a pain in the ass I imagine, so should we just replace all instances of var with ptr? |
| 13:45:29 | Skrylar | EXetoC: but then you'd have to use addr() on input params |
| 13:45:51 | Skrylar | I thought 'var' was kind of like & in C++, you use it for "i will modify this, but its not *actually* a pointer so don't put & on it yourself" |
| 13:46:15 | Skrylar | or just pass-by-ref |
| 13:46:27 | Araq | Skrylar: it is C++'s & |
| 13:47:00 | Araq | EXetoC: fine with me, but breaks code. maybe better: overload what you need with 'ptr T' instead of 'var T' |
| 13:47:08 | BitPuffin | Araq: aren't C++ exceptions pretty shit anyway? |
| 13:47:32 | Araq | BitPuffin: pretty shit? zero cost exception handling is "pretty shit"? |
| 13:47:51 | BitPuffin | Araq: it was a question, not a statement |
| 13:47:53 | Araq | how are explicit 'if's everywhere better for performance? |
| 13:48:05 | Araq | that question was never answered by the C guys |
| 13:48:23 | Skrylar | zahary: https://gist.github.com/Skrylar/9740396 |
| 13:48:54 | Skrylar | and C++ exceptions *weren't* "zero cost" for a very long time |
| 13:49:21 | EXetoC | zero compared to manual checking, right? |
| 13:49:48 | Skrylar | EXetoC; no, some of the older compilers had an exponential increase in code bloat as well as slow triggering of exceptions, or using complicated side-chains |
| 13:49:56 | zahary_ | looks like bug Skrylar, feel free to post it |
| 13:50:23 | Skrylar | EXetoC: basically, they have cheaper exceptions *now* but a lot of opinions about it were formed pre-2013 |
| 13:51:41 | Skrylar | zahary: noted. seems like i've been finding a lot of these lately, lol |
| 13:52:08 | BitPuffin | Araq: it was? |
| 13:52:08 | Araq | imho we should simply remove 'macros.quote' |
| 13:52:31 | Araq | it's buggy and/or weird and there are at least 2 other ways to accomplish the same |
| 13:52:38 | zahary_ | I guess the goal of this code is to assign numeric IDs to types? |
| 13:53:01 | Skrylar | zahary: yeah, its used for priming event types |
| 13:53:27 | zahary_ | there is a much simpler solution if so; proc mytypeid(x: typedesc) = var id {.global.} = nextId(); return id |
| 13:54:16 | Araq | make that 'static nextId()' |
| 13:55:29 | zahary_ | generating the sequence at run-time is still safer, because it works across modules |
| 13:55:38 | EXetoC | Araq: only 25 instances of 'var' in OpenGL. I expected it to be present everywhere |
| 13:55:42 | zahary_ | static variables don't have that feature yet |
| 13:55:46 | EXetoC | ok so that's not a very big problem then |
| 13:55:57 | Skrylar | i tested two modules with that macro and it worked |
| 13:56:04 | Skrylar | didn't test 3 though |
| 13:56:23 | Araq | zahary_: static vars are now global across module boundaries |
| 13:56:31 | zahary_ | ah, didn't know that |
| 13:56:31 | EXetoC | zahary_: have you looked into that UDTC issue? should I report it? |
| 13:56:45 | Skrylar | i set aside a note to try the other method later though |
| 13:56:55 | Araq | yes you do, I told you. you asked my why the eval context is a singleton, remember? |
| 13:57:35 | EXetoC | zahary_: dumb question. I'll report it |
| 13:57:41 | zahary_ | not yet EXetoC, I have it in my scratch.nim file (which is the first I open when I press NIM in vim) |
| 13:58:30 | zahary_ | reporting is always better, because I don't have to think about commit messages :P |
| 13:58:41 | EXetoC | yep |
| 14:01:41 | Araq | EXetoC: so provide 25 overloads. you can mark the 'var' procs as deprecated |
| 14:05:54 | * | darkf quit (Quit: Leaving) |
| 14:12:28 | Skrylar | hrm |
| 14:13:07 | Skrylar | well the bonus that i've seen so far to an event map, is that its possible to have static dispatch (which means zero-malloc processing) |
| 14:13:46 | Skrylar | though it does appear to still require callbacks, admittedly those are centralized |
| 14:21:48 | Skrylar | Araq: do you think its reasonable to set a hardcap on event size? it would be possible to make a standard queue fully generic without invoking pointer insanity by doing so |
| 14:22:21 | Skrylar | most of the C libs have an event size of like ~8 ints for all events IIRC |
| 14:23:30 | * | BitPuffin quit (Quit: WeeChat 0.4.3) |
| 14:23:44 | * | BitPuffin joined #nimrod |
| 14:25:25 | Araq | Skrylar: I like the idea but people will complain |
| 14:25:51 | Skrylar | i'll prototype it for an hour or two. |
| 14:26:04 | Skrylar | i have half a Wx-style event map setup |
| 14:26:22 | Araq | btw did you look at exhu's project? |
| 14:26:37 | Skrylar | i don't have the github link |
| 14:32:05 | Araq | mmm all I can find is this: https://github.com/exhu/nimrod-misc |
| 14:32:27 | Araq | so either he removed it or he never really started or he didn't put it online |
| 14:32:46 | Skrylar | i could probably work on mine faster than i have been :/ |
| 14:32:59 | Skrylar | its been off for a few days while i poked around with event models |
| 14:33:12 | Skrylar | I *really* like signals and slots, but it requires a lot of... Sadness. |
| 14:35:54 | * | Skrylar peers distrustfully at this article on event queues |
| 14:36:18 | zahary_ | I recently starred a signals/slots library by fowl |
| 14:36:43 | zahary_ | and I probably will soon use it as a test subject for varargs generics |
| 14:36:51 | Skrylar | yeah, i saw fowl's |
| 14:37:31 | Skrylar | i wrote something similar and tested signal disconnection in finalizers with it, but there's a lot of ... sadness involved. |
| 14:38:23 | zahary_ | btw, Araq, my GC doesn't have the finalizers bug reported by Skrylar |
| 14:38:46 | Skrylar | zahary_: the one where it keeps one pair of cycles alive conservatively? |
| 14:38:54 | zahary_ | yes |
| 14:39:55 | Araq | zahary_: so? you do the stack scanning a bit differently |
| 14:40:31 | Araq | btw your GC also caused random crashes on my machine |
| 14:40:36 | zahary_ | is that it? I think I never managed to activate this part |
| 14:41:29 | Araq | well I don't know I don't get how stacks work |
| 14:41:50 | Araq | in theory I should be able to mask the stack bottom to be at the page boundary |
| 14:42:08 | Araq | but whenever I do it, it crashes in subtle ways |
| 14:42:28 | Araq | comex said the stack is not page aligned but that makes no sense to me |
| 14:42:50 | Araq | even it weren't the memory protection is page based |
| 14:42:54 | Skrylar | its up to the OS and compiler :/ |
| 14:43:13 | Araq | so I am free to access random bits on the same page, in theory |
| 14:43:20 | Skrylar | you can certainly align the stack to a page boundary in raw assembly, since you just set it to whatever you want |
| 14:44:26 | Skrylar | i know some memory debugging setups will also push sentinel values to the stack to check for issues |
| 14:44:55 | Skrylar | but.. yeah. stack debugging is a tiny hell |
| 15:01:10 | * | XenMaster quit (Quit: Ex-Chat) |
| 15:02:01 | Skrylar | looks like SDL2's largest event is smaller than 64-bytes |
| 15:16:08 | * | brson joined #nimrod |
| 15:24:12 | Kelet | Can anyone compile git master? I get compiler/semdata.nim(261, 16) Error: 'getSysType' cannot be passed to a procvar |
| 15:59:25 | EXetoC | Kelet: I don't know. What about devel? |
| 16:00:46 | EXetoC | both compile for me |
| 16:01:17 | Kelet | Oops, I meant devel |
| 16:01:19 | Kelet | weird |
| 16:02:00 | EXetoC | Kelet: try with -d:release |
| 16:02:22 | * | psquid joined #nimrod |
| 16:02:35 | EXetoC | omitting it seems to be the problem |
| 16:04:35 | * | Guest10997 quit (Ping timeout: 252 seconds) |
| 16:04:44 | EXetoC | ok this time it's not working for me |
| 16:07:17 | comex | Araq: what are you doing exactly? |
| 16:07:39 | EXetoC | apparently the tester can compile it |
| 16:11:33 | * | Demos joined #nimrod |
| 16:14:31 | Demos | I do not like signals and slots. Although I do not like them in the context of game programming, they are probably better for other stuff |
| 16:15:37 | Demos | although actually using a slot as a replacement for seq[proc(...)] could be good I guess, I just dont like them when you are like shooting events every which way and it is hard to figure out what the hell is going on |
| 16:25:39 | * | Demos_ joined #nimrod |
| 16:26:49 | * | Demos quit (Ping timeout: 265 seconds) |
| 16:28:08 | * | Skrylar quit (Ping timeout: 246 seconds) |
| 16:35:01 | EXetoC | "Untracked files: tests/..., tests/..., tests/..., tests/..., tests/..., tests/..., tests../, ..." :> |
| 16:37:54 | EXetoC | Kelet: surround the argument of getSysType with params |
| 16:38:22 | EXetoC | that particular syntax is supposed to work, but it's new |
| 16:47:02 | * | DAddYE joined #nimrod |
| 16:47:38 | Kelet | http://pastebin.com/X0a2pMe6 |
| 16:47:56 | Kelet | Why does this give: irc.nim(4, 19) Error: expression 'irc("irc.freenode.net", nick = "bot", joinChans = @ ["#keletbot"])' cannot be called |
| 16:48:09 | Kelet | Is it because of the module/fxn name collision? |
| 16:48:15 | zahary_ | nick: "bot", joinChans: @[] |
| 16:48:20 | zahary_ | : instead of = |
| 16:48:30 | EXetoC | huh |
| 16:48:54 | Kelet | oh. |
| 16:48:55 | zahary_ | ah, that's not a type, my bad |
| 16:50:02 | EXetoC | Kelet: does irc.irc(...) work? |
| 16:51:03 | Kelet | no same error only for irc.irc(...) |
| 16:52:31 | EXetoC | Kelet: the original code works for me |
| 16:52:37 | EXetoC | after this change: "type -> typ"? |
| 16:52:47 | EXetoC | disregard the question mark |
| 16:52:52 | EXetoC | so you are indeed on devel? |
| 16:53:01 | Kelet | no im on the stable version atm |
| 16:53:32 | Kelet | 0.9.2 |
| 16:53:38 | * | Skrylar joined #nimrod |
| 16:54:00 | EXetoC | it's best to use devel for now |
| 16:55:02 | EXetoC | I told you how to make devel to compile. Did you notice? only that particular line needs to be modified |
| 16:55:08 | EXetoC | -to |
| 16:55:55 | Kelet | I'll try it |
| 16:56:21 | Kelet | I'm on a crappy network and don't have the sources though, which is why I was trying to avoid it. It takes a long time to get the sources and usually disconnects the way through :/ |
| 16:56:26 | Kelet | ah well |
| 16:57:55 | EXetoC | oh |
| 17:01:32 | * | bot983298 joined #nimrod |
| 17:01:35 | * | bot983298 quit (Read error: Connection reset by peer) |
| 17:02:54 | * | Demos_ quit (Ping timeout: 268 seconds) |
| 17:07:17 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 17:21:48 | Kelet | EXetoC: Now I get lib/system/inclrtl.nim(27, 24) Error: invalid exported symbol |
| 17:21:53 | Kelet | when compiling devel |
| 17:24:17 | EXetoC | ok I didn't get that |
| 17:25:26 | fowl | <Skrylar> i wrote something similar and tested signal disconnection in finalizers with it, but there's a lot of ... sadness involved. |
| 17:25:36 | EXetoC | Kelet: ./koch boot? |
| 17:25:50 | fowl | Skrylar, what a pity that you dont run the tests i've written, i'd like to get some confirmation that it works because it seems to work fine |
| 17:29:34 | EXetoC | Kelet: did you specify nimrtl explicitly? |
| 17:40:14 | * | BitPuffin joined #nimrod |
| 17:45:55 | NimBot | Araq/Nimrod devel cc677b6 Araq [+0 ±3 -1]: VM: endless loop prevention |
| 17:45:55 | NimBot | Araq/Nimrod devel 4c4b3fd Araq [+0 ±3 -0]: VM: attempt to get integer ops right |
| 17:45:55 | NimBot | Araq/Nimrod devel ef8e94c Araq [+1 ±7 -0]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
| 17:58:47 | * | psquid quit (Ping timeout: 246 seconds) |
| 17:59:18 | * | psquid joined #nimrod |
| 18:01:38 | dom96 | Kelet: You should clone with --depth 1 if you're on a slow connection. |
| 18:04:12 | fowl | Kelet, that will prevent them from getting the devel branch |
| 18:13:36 | reactormonk | Kelet, I can give you a trimmed down repo |
| 18:14:04 | reactormonk | btw: https://github.com/Araq/Nimrod/issues/958 |
| 18:14:06 | fowl | er i meant that @ dom96 |
| 18:14:43 | dom96 | fowl: hrm, really? But isn't the devel branch default now? |
| 18:15:11 | dom96 | You can always just download https://github.com/Araq/Nimrod/archive/devel.zip |
| 18:15:19 | fowl | not sure, i had to do some git magic to set it up to track all branches |
| 18:15:32 | fowl | maybe you can specify devel branch in the clone command |
| 18:26:41 | * | q66 joined #nimrod |
| 18:26:41 | * | q66 quit (Changing host) |
| 18:26:41 | * | q66 joined #nimrod |
| 18:30:15 | * | Ransel_ joined #nimrod |
| 18:39:08 | EXetoC | fowl: it is indeed the default now |
| 18:48:19 | * | skyfex joined #nimrod |
| 18:53:01 | * | Mat3 joined #nimrod |
| 18:53:06 | Mat3 | hi all |
| 18:53:18 | * | renesac quit (Ping timeout: 240 seconds) |
| 18:54:18 | * | Matthias247 joined #nimrod |
| 18:59:54 | fowl | how can i see the gcc line used to compile |
| 19:00:28 | Skrylar | uh oh... stdlib code is broken :( |
| 19:00:48 | Skrylar | fowl: nimrod --listCmd? |
| 19:01:08 | Skrylar | or so its supposed to, i just tried it and it errors |
| 19:01:29 | fowl | ah it works thanks |
| 19:01:41 | * | q66 quit (Ping timeout: 252 seconds) |
| 19:01:42 | EXetoC | and in the generated C sources |
| 19:02:44 | dom96 | and the compiler will output it by default |
| 19:02:49 | dom96 | when compiling |
| 19:03:10 | dom96 | It depends on whether you have stuff in nimcache though I think |
| 19:03:50 | fowl | wow |
| 19:03:51 | Skrylar | wat |
| 19:03:56 | * | q66 joined #nimrod |
| 19:04:00 | fowl | its ignoring my {.passL.} directive |
| 19:04:01 | Skrylar | "error undeclared identifier: count" in queues.nim |
| 19:04:27 | Skrylar | i checked the source file in the stdlib.. its certainly there |
| 19:04:28 | Mat3 | the compiler command should be included as comment in the generated C files |
| 19:05:50 | * | renesac joined #nimrod |
| 19:09:13 | Skrylar | oh. it looks related to the newSeq derpage where newSeq won't work with certain inputs |
| 19:12:29 | Skrylar | Nope, its apparently just generics breaking again |
| 19:19:32 | EXetoC | Araq: could the gl prefix not be removed automatically at the time when the modules were generated? |
| 19:23:15 | Skrylar | zahary: uhh.. so theres something derpy going on where "assert q.count" errors as being unable to find identifier 'count' yet commenting out the assert from stdlib code lets it compile... |
| 19:24:02 | zahary | and I guess renaming the variable to something different than count solves the problem? |
| 19:24:15 | Skrylar | i didn't try that (it's not my code) |
| 19:24:38 | Skrylar | the line underneath "dec q.count" doesn't trip it; so Assert is specifically the derp |
| 19:25:28 | zahary | I have reported similar issue with templates today - it's a bit outside of the part of generics I usually work, but I'll probably get to it at some point |
| 19:26:39 | zahary | actually, it's probably exactly the same issue - assert being a template |
| 19:33:11 | * | Demos joined #nimrod |
| 19:46:43 | Demos | oh my god steam streaming is great |
| 19:57:34 | * | nequitans quit (Remote host closed the connection) |
| 19:57:42 | * | nequitans joined #nimrod |
| 19:58:41 | * | Demos quit (Remote host closed the connection) |
| 20:01:08 | * | Trimsty quit (Remote host closed the connection) |
| 20:12:43 | * | brson quit (Quit: leaving) |
| 20:12:51 | * | brson joined #nimrod |
| 20:18:05 | * | flaviu joined #nimrod |
| 20:25:19 | * | silven quit (Remote host closed the connection) |
| 20:31:46 | * | runvnc quit (Quit: WeeChat 0.4.1) |
| 20:40:25 | dom96 | Things are really quiet on the forum lately. |
| 20:43:36 | Mat3 | too much bug fixing |
| 20:44:38 | dom96 | that must be it |
| 20:45:58 | * | faassen left #nimrod (#nimrod) |
| 20:46:09 | * | nequitans_ joined #nimrod |
| 20:47:59 | * | nequitans quit (Ping timeout: 268 seconds) |
| 20:55:10 | BitPuffin | so Araq, does nimrod compiler optimize much or does it leave that up to the C compiler? |
| 20:55:27 | BitPuffin | I'm asking because I'm thinking about how to write code that is easy for a compiler to optimize |
| 20:55:42 | BitPuffin | and if maybe that is a harder to do in a language where compilation happens "twice" |
| 20:56:04 | Araq | the compiler does optimize but it does a shitty job at it |
| 20:56:27 | BitPuffin | Araq: ah, so one should try to cater to the C compiler then? |
| 20:56:32 | Araq | there is no separate optimizer pass, most optimizations are part of the codegen |
| 20:56:36 | BitPuffin | at least at the very moment |
| 20:57:10 | Araq | I can't answer this question |
| 20:57:22 | Araq | I know too much to give any meaningful answer. :P |
| 20:57:23 | BitPuffin | no it's a weird question |
| 20:57:25 | BitPuffin | :P |
| 20:57:37 | BitPuffin | all hail the all knowing oracle |
| 20:58:01 | BitPuffin | I guess what I should do is to just look at the output assembly |
| 20:58:10 | Araq | indeed |
| 20:59:29 | dom96 | whoa, did BitPuffin just summon Araq? |
| 21:00:07 | Araq | skyfex: if you're looking for work, you could implement the pure RC'ing GC |
| 21:01:50 | * | Gxen joined #nimrod |
| 21:02:25 | skyfex | Araq: What'd it be for? |
| 21:04:40 | Gxen | Araq: woher kommst du? nord, sud? |
| 21:07:17 | Araq | hi Gxen: süd |
| 21:07:17 | BitPuffin | Araq: answer me this oh oracle, what is hoisting? |
| 21:07:46 | dom96 | BitPuffin: It's when you catch a fish. |
| 21:07:48 | Araq | skyfex: better interop with the cocoa framework; the Gc is agnostic to the stacks |
| 21:08:02 | dom96 | BitPuffin: And then you put it outside a loop. |
| 21:08:05 | Araq | --> can easily use C coroutine libraries |
| 21:08:06 | dom96 | :P |
| 21:08:29 | BitPuffin | dom96: wat |
| 21:08:46 | BitPuffin | dom96: so it's literally just finding stuff you only need to do once and putting it outside the loop? |
| 21:08:55 | dom96 | BitPuffin: yes |
| 21:08:57 | dom96 | AFAIK |
| 21:09:11 | skyfex | Araq: Aha, hmm, would be an interesting project, but I'm worried my motivation wouldn't be great. I don't do much Cocoa programming anymore. But maybe it'd be useful in embedded applications too? hmm |
| 21:09:22 | BitPuffin | Araq: is thar correct, oh almightly oracle |
| 21:09:46 | Araq | BitPuffin: "loop invariant code hoisting", look it up |
| 21:09:54 | Araq | (yes dom96 is correct) |
| 21:10:23 | BitPuffin | yeah because searching for hoisting only gave me javascript lol |
| 21:10:26 | dom96 | yay I'm correct. |
| 21:10:40 | * | dom96 pats himself on the back |
| 21:10:48 | Matthias247 | skyfex: I think for real embedded stuff the current task-local GC is better suited |
| 21:12:33 | BitPuffin | oh well that was simple |
| 21:12:59 | BitPuffin | stuff that you should do anyway because compilers are silly |
| 21:14:19 | flaviu | https://pay.reddit.com/r/learnprogramming/comments/217z9b/what_are_the_bleeding_edge_technologies_today/cgaib07 |
| 21:15:27 | flaviu | Seems to be a good reception there |
| 21:16:08 | dom96 | hrm, nice find, or did you post it? |
| 21:16:15 | flaviu | I found it |
| 21:16:25 | BitPuffin | filwit still not back? |
| 21:16:39 | dom96 | BitPuffin: Yeah ;( |
| 21:20:12 | BitPuffin | :/ |
| 21:21:24 | Mat3 | flaviu: The Mill CPU architecture seem to realize some promising ideas |
| 21:23:24 | flaviu | Yes, I'm really looking forward to that too. I'm also really exited about games on linux |
| 21:24:46 | Mat3 | hmm, beside steam I see only minor development in these area (there exist some Linux versions of recent games however) |
| 21:26:23 | flaviu | He mentions CryEngine coming to Linux, which might be leading up to a AAA title being released on linux |
| 21:33:35 | Matthias247 | while valve now largely focuses on linux they somehow they are mostly focussing on Steam and apparently not on so much on developing games themselves. At least it looks so |
| 21:34:52 | Araq | Gxen: and you? where are you from? and why is that important? ;-) |
| 21:35:11 | Mat3 | everything is important these days |
| 21:36:17 | Gxen | Araq: I saw a video of you, and you reminded me of someone I knew 10y ago when I studied in Germany/Oldenburg; he was a computerscientist student |
| 21:36:24 | * | psquid_ joined #nimrod |
| 21:37:02 | Gxen | Araq: I am finnish |
| 21:38:59 | * | psquid quit (Ping timeout: 252 seconds) |
| 21:40:52 | Gxen | (new to nimrod, going over the tutorials) case..of..else: with string else is not needed cause not possible to cover all strings... not even with regex? |
| 21:42:35 | EXetoC | I don't know where regex comes in |
| 21:43:14 | Araq | Gxen: well I didn't study in Oldenburg :-) |
| 21:43:44 | Araq | ping zahary, zahary_ |
| 21:45:17 | EXetoC | I wonder if that 'else' requirement was removed as a result of our discussion a while back |
| 21:45:35 | Mat3 | ciao |
| 21:45:39 | EXetoC | bye |
| 21:45:46 | * | Mat3 quit (Quit: Verlassend) |
| 21:46:41 | EXetoC | I might've agreed with that other guy in that it wasn't necessary, but it's not like it requires particularly much effort |
| 21:47:06 | Araq | it wasn't removed |
| 21:47:28 | Araq | he made a good point but I don't remember it :-/ |
| 21:47:31 | Araq | do you? |
| 21:48:22 | dom96 | Araq: I've run into a bit of a dillema. |
| 21:48:27 | EXetoC | Araq: you mean it was never required? |
| 21:48:39 | EXetoC | or did I argue for the exact opposite? :p |
| 21:49:00 | Araq | the guy was convincing but it's not like I do everything at once |
| 21:49:11 | Araq | and now I forgot his arguments |
| 21:49:26 | dom96 | Araq: I'm keeping the async socket distinct. However, I have simply copied the definition of PSocket instead of writing "distinct PSocket" so that I don't need to export the fields of PSocket. |
| 21:49:51 | dom96 | Araq: Now what I would like is to use a proc defined for a PSocket. |
| 21:50:06 | dom96 | Araq: Should I be doing this whole thing differently? |
| 21:50:13 | Araq | no. |
| 21:50:27 | dom96 | Araq: The only way I see what I want working is to cast to PSocket |
| 21:50:31 | Araq | mysocket.baseType is not too offensive, is it? |
| 21:51:22 | Araq | dom96: type conversions (not casts) work just fine with 'distinct' |
| 21:51:50 | EXetoC | Araq: I think the argument was that there's an infinite amount of variations, and so requiring it doesn't make much sense |
| 21:51:51 | dom96 | Araq: Well I don't want to use 'distinct' like I said. |
| 21:51:55 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 21:52:03 | Araq | how often do you think people will need to pass an AsyncSocket to a SyncSocket? |
| 21:52:16 | Gxen | imo its stupid to omit the else requirement for strings.. the benefit for leaving it out doesnt outweight the cost of remembering when not to leave it out |
| 21:52:19 | Araq | should not be common, so an explict type conversion is just fine |
| 21:53:04 | EXetoC | Gxen: isn't it similar to requiring 'else' for 'if' blocks? |
| 21:53:18 | * | Endy quit (Ping timeout: 240 seconds) |
| 21:53:47 | Araq | Gxen: no need to 'remember' anything, the compiler tells you |
| 21:53:53 | Gxen | EXetoC: no, if else is a logical thing, case of else is a syntax thing |
| 21:54:36 | Araq | so use 'else' with a string case, it's not like it's not possible |
| 21:56:17 | * | Endy joined #nimrod |
| 21:56:23 | dom96 | Araq: Re-read what I said |
| 21:57:35 | Araq | dom96: ok, got it |
| 21:57:41 | * | Araq is thinking about it |
| 21:57:45 | EXetoC | Araq: I think he wants it to be mandatory, but I don't know if it makes much sense when explicitly covering every case is impossible |
| 21:58:26 | Araq | ah yeah that was the argument, "make me use the 'else' for string cases for consistency" |
| 21:59:24 | Gxen | of course thats what I want.. |
| 21:59:54 | Araq | Gxen: ok, ok, you're the 2nd. will add it to my todo |
| 22:00:09 | Gxen | I don't wanna think every time:"is coering the whole range posssible and can I omit the else"... "oh, lets see what the compiler thinks"... |
| 22:01:22 | * | Endy quit (Ping timeout: 268 seconds) |
| 22:01:34 | Araq | the point is: "I think/want to cover every case here, so I'm leaving out the 'else' and the compiler checks for me" |
| 22:01:49 | EXetoC | so you'll only add it to be sure *if* it's required? seems like an odd reasoning, but ok there's still the consistency argument |
| 22:02:21 | Gxen | Araq: I excuse in advance.. I am gonna be your worst critic for the next x time.. but I mean it well :) |
| 22:02:53 | Gxen | explicit is better than implicit.. |
| 22:03:22 | Araq | that's why I can't write down any types in python, right? :P |
| 22:03:30 | Gxen | :D |
| 22:03:38 | EXetoC | Araq: that sounds like something that would apply only when dealing with a finite set of variations |
| 22:03:40 | Gxen | fair enough.. |
| 22:05:05 | Araq | EXetoC: the point of pattern matching is not the unpacking. It's the exhaustiveness check. |
| 22:10:10 | EXetoC | yes, in which case you can't ever leave out 'else' for strings, and that's why I couldn't figure out what you meant by your previous remark; but I suppose it's possible to extend the feature set for string matching |
| 22:10:56 | * | Gxen quit (Quit: Lost terminal) |
| 22:13:19 | * | DAddYE_ joined #nimrod |
| 22:13:19 | * | DAddYE quit (Read error: Connection reset by peer) |
| 22:14:11 | EXetoC | actually, that seems really complicated |
| 22:15:22 | EXetoC | Time to parse the rest of the OpenGL xml spec. too bad they didn't include null-validity for pointers |
| 22:16:23 | fowl | opengl xml spec? |
| 22:16:58 | EXetoC | I'll just take care of that 'var' issue first |
| 22:17:26 | EXetoC | fowl: yes, an official spec. for facilitating in writing bindings I assume |
| 22:17:56 | EXetoC | an official parseable spec to be exact. https://bitbucket.org/alfonse/gl-xml-specs/overview |
| 22:20:03 | fowl | oh wow |
| 22:20:13 | fowl | this is like c mixed with xml |
| 22:20:32 | dom96 | Araq: Did you think of a solution? |
| 22:20:34 | fowl | <type requires="stddef">typedef ptrdiff_t <name>GLintptr</name>;</type> |
| 22:21:36 | flaviu | At least enums are categorized... |
| 22:22:25 | flaviu | Never mind, the enums are just generic in the actual methods |
| 22:22:44 | flaviu | sometimes, sometimes not |
| 22:24:31 | * | Ransel_ quit (Ping timeout: 264 seconds) |
| 22:24:38 | Araq | dom96: use a distinct type and export the fields for now |
| 22:25:03 | EXetoC | fowl: I hadn't noticed. I don't like that |
| 22:25:14 | EXetoC | but it shouldn't complicate things all that much |
| 22:26:35 | dom96 | Somebody advocate Nimrod in here: http://www.reddit.com/r/programming/comments/218yqw/using_and_abusing_macros/ |
| 22:29:28 | fowl | EXetoC, it definitely is more complicated than just using xml |
| 22:29:44 | EXetoC | yes. some spec.. |
| 22:29:50 | fowl | <type><base>ptrdiff_t</base><name>GLintptr</name></type> would be nice |
| 22:33:24 | EXetoC | maybe I'll convert it to a proper spec |
| 22:34:12 | BitPuffin | Araq: if there is one good outcome of me doing this in C rather than nimrod is that in the future it won't feel as weird to use ptr instead of ref when I need to |
| 22:36:09 | Araq | BitPuffin: declaring an array like char** foo = {"a", "b" "c"}; will make you go back to nimrod |
| 22:36:41 | Araq | (note: comma missing means 2 elements instead of 3 and C does not perform any bounds checking) |
| 22:39:48 | BitPuffin | doesn't "b" "c" result in an invalid expression |
| 22:40:03 | BitPuffin | Araq: I'm not away from Nimrod, it's still my favorite language and I still use it :P |
| 22:40:25 | BitPuffin | some things have been kind of weird |
| 22:40:35 | BitPuffin | like I can't do vec3 x = WORLD_X |
| 22:40:48 | BitPuffin | where WORLD_X is a global const vec3 |
| 22:41:58 | dom96 | Did you finish your game? |
| 22:42:47 | fowl | i dont know if C does it but C++ concats strings like "a" "b" |
| 22:43:59 | dom96 | I can see why. It makes splitting up strings over multiple lines easier. |
| 22:46:28 | * | psquid_ is now known as psquid |
| 22:51:39 | BitPuffin | Araq: how does one go about to use intrinsic functions in nimrod? |
| 22:51:57 | BitPuffin | like when defined(gcc): someGccFunc(ar,ch.ur,achurach) |
| 22:57:07 | * | DAddYE_ quit (Remote host closed the connection) |
| 22:57:45 | * | DAddYE joined #nimrod |
| 23:00:56 | EXetoC | BitPuffin: you should use importc I think |
| 23:01:27 | EXetoC | and yes that appears to be how you determine what C compiler is used |
| 23:16:23 | * | brson quit (Quit: leaving) |
| 23:23:05 | dom96 | Araq: ugh. I have to cast to that type if I want to access any field... |
| 23:24:34 | BitPuffin | EXetoC: seems simple enough then |
| 23:24:59 | dom96 | BitPuffin: I'll take the lack of answer as a no. |
| 23:25:23 | BitPuffin | dom96: I'ms still working on it |
| 23:25:38 | BitPuffin | dom96: I didn't notice your question because you didn't highlight me :P |
| 23:25:58 | dom96 | excuses excuses |
| 23:26:44 | dom96 | If only you used Nimrod. It would be done by now :P |
| 23:31:45 | * | darkf joined #nimrod |
| 23:37:47 | * | gverilla joined #nimrod |
| 23:38:13 | gverilla | hi |
| 23:38:25 | dom96 | hi gverilla |
| 23:39:16 | gverilla | i'm starting to learn rust: is there a elegant way to convert a sequence of strings to a sequence of ints? |
| 23:39:58 | BitPuffin | dom96: No I'd still be wrapping allegro |
| 23:40:09 | dom96 | gverilla: Rust? This is #nimrod not #rust. |
| 23:40:10 | BitPuffin | gverilla: this is not rust lol |
| 23:40:19 | gverilla | right, i meant nimrod :) |
| 23:40:25 | gverilla | sorry :) |
| 23:40:28 | BitPuffin | haha |
| 23:40:35 | dom96 | BitPuffin: Yeah, because you are using every single function in allegro right? |
| 23:40:40 | BitPuffin | dom96: totally |
| 23:40:51 | BitPuffin | how did you know? |
| 23:41:13 | BitPuffin | gverilla: if there isn't it would be quick to implement |
| 23:42:18 | * | q66 quit (Quit: Leaving) |
| 23:42:38 | gverilla | ive implemented a loop with parseint, but i feel there should be a simpler solution :P |
| 23:42:55 | dom96 | You can use map. |
| 23:43:06 | EXetoC | or mapIt |
| 23:43:40 | dom96 | Procedural style isn't that bad usually though |
| 23:43:43 | dom96 | It grows on you. |
| 23:44:05 | * | io2 quit () |
| 23:45:09 | gverilla | dom96, thanks! i find to prefer simple oneliners for simple tasks like this. no need to clutter the code with ten lines for this... ;) |
| 23:45:28 | dom96 | gverilla: https://gist.github.com/dom96/a6cb03559189f8b104a8 |
| 23:45:37 | EXetoC | lib/pure/collections/sequtils.nim:419: strings = nums.mapIt(string, $(4 * it)) |
| 23:45:40 | BitPuffin | gverilla: well then mapping parseint sounds like a good choice |
| 23:46:03 | Araq | dom96: or simply x.map(parseInt) |
| 23:46:24 | EXetoC | neat |
| 23:47:00 | dom96 | Araq: If only the procvar pragma wasn't necessary I would feel more safe in assuming that that would work :P |
| 23:47:01 | * | flaviu quit (Quit: Leaving.) |
| 23:47:46 | Araq | parseInt is .procvar :P |
| 23:48:17 | dom96 | It could very easily not have been. |
| 23:48:22 | gverilla | thanks guys! yeah, it still needs a wrapper to get the int from parseint |
| 23:48:36 | gverilla | but i've got it from here ^^ |
| 23:50:55 | dom96 | Araq: What about my problem? |
| 23:56:11 | Araq | dom96: I have to see your code |
| 23:56:20 | Araq | brb |
| 23:56:27 | dom96 | Araq: it's on github |
| 23:56:34 | dom96 | net/asyncnet |