| 00:46:39 | * | fowl|asus is now known as fowl|afk |
| 01:46:53 | * | fowl|afk quit (Ping timeout: 255 seconds) |
| 01:58:54 | * | q66 quit (Quit: Quit) |
| 03:05:41 | * | fowl joined #nimrod |
| 03:54:04 | Zor | Araq: do you require any particular c compiler in nimrod? |
| 03:58:01 | * | shevy2 is now known as shevy |
| 04:02:25 | * | shevy left #nimrod ("I'll be back ... maybe") |
| 09:10:05 | Araq | Zor: we don't require any particular C compiler, but sometimes the C compiler has bugs that prevent it from building nimrod properly; officially supported are: GCC, visual C++, clang and intel C/C++'s compiler |
| 09:11:14 | Araq | borland's C++ compiler was buggy enough that I stopped supporting it |
| 09:12:05 | Araq | Tiny C used to work but is not maintained and doesn't work on my linux distribution anymore anyway |
| 11:39:58 | * | apriori_ joined #nimrod |
| 11:57:29 | * | q66 joined #nimrod |
| 12:00:24 | * | FreeArtMan joined #nimrod |
| 12:10:37 | _ponce | hi |
| 12:10:57 | _ponce | what is the extent of what can be computed at compile-time and emit() ? |
| 12:11:27 | Araq | pretty much the safe subset of the language can be computed at compile-time |
| 12:11:43 | Araq | however the FFI does not work for now |
| 12:11:49 | _ponce | great |
| 12:11:59 | Araq | you can 'staticRead' a file into a string at compile time |
| 12:12:18 | _ponce | may I iterate on a const tuple array describing bit structures and generate AST with that, then emit it? |
| 12:13:34 | Araq | yeah but I don't know what you mean with 'emit'? |
| 12:14:00 | _ponce | template emit*(s: expr): stmt |
| 12:14:16 | Araq | you can also run a process and capture its output at compile time with 'staticExec' |
| 12:14:45 | _ponce | I suppose there is a way to emit AST nodes directly? |
| 12:15:06 | Araq | yeah this 'emit' builtin is rarely needed |
| 12:15:49 | _ponce | use case: all this would save SO much time if implementing a video codec |
| 12:16:01 | _ponce | where syntax is quite a big undertaking |
| 12:16:19 | _ponce | the binary syntax |
| 12:16:43 | _ponce | I also love how you support ICC |
| 12:17:07 | Araq | well it's been a while since I last tested ICC ;-) |
| 12:17:34 | _ponce | it almost support a super set of GCC and MSVC |
| 12:17:57 | _ponce | so it should still work :) |
| 12:18:06 | Araq | yeah "should" ... |
| 12:21:38 | Araq | _ponce: best way to learn about Nimrod's macros is perhaps this: http://forum.nimrod-code.org/t/90 |
| 12:31:08 | Araq | bbl |
| 12:44:05 | * | Trix[a]r_za is now known as Trixar_za |
| 13:29:13 | * | FreeArtMan quit (Read error: Connection reset by peer) |
| 14:15:02 | * | Trixar_za is now known as Trix[a]r_za |
| 14:49:29 | * | Vladar joined #nimrod |
| 15:13:00 | * | apriori_ quit (Remote host closed the connection) |
| 15:55:46 | * | apriori_ joined #nimrod |
| 16:00:06 | Araq | oh hi Vladar |
| 16:00:23 | Araq | I heard 0.9.1 doesn't work with nimgame; can you please check? |
| 16:01:30 | Vladar | Hi, Araq. Checking... |
| 16:04:51 | Vladar | Araq, works pretty well, as for me |
| 16:05:17 | Araq | which os and cpu? |
| 16:06:32 | Vladar | Debian, Intel Core 2 Duo E6550 |
| 16:12:15 | Araq | ok |
| 16:13:16 | Vladar | Araq, anything specific, error messages? |
| 16:28:29 | Araq | dom96 reported some runtime crah in the init code |
| 16:28:32 | Araq | *crash |
| 16:29:09 | Araq | but I already have some bugs left to fix which may cause this |
| 16:29:47 | dom96 | yeah, there seems to be an issue with the GC. |
| 16:30:04 | dom96 | But also, Vladar I don't think you are initializing the engine's 'state' field |
| 16:30:09 | dom96 | IIRC |
| 16:30:26 | dom96 | Also, you should consider removing the dependency on fnt/default... |
| 16:35:42 | Vladar | dom96, yes, you need to assign something to this field before calling engine.start() |
| 16:36:10 | dom96 | hrm, some docs mentioning that would help :P |
| 16:39:46 | Vladar | dom96, maybe even complete tutorial for the next release. For now, look into 'asteroids' demo code. |
| 17:44:31 | apriori_ | fowl: did you test (c)fml with opengl? |
| 18:46:20 | Vladar | Araq, is destructor pragma expected not to touch vars with global pragma? |
| 18:49:02 | Araq | Vladar: good question |
| 18:49:39 | Araq | globals shouldn't have their destructors invoked, yeah |
| 18:52:26 | Vladar | hmm... |
| 18:52:46 | Vladar | Then, something wrong happens now |
| 18:52:59 | Araq | well that's how it *should* be, but the compiler doesn't check for .global ;-) |
| 18:53:07 | Araq | so yep, bug here |
| 18:53:32 | _ponce | how should resource destruction be handled in idiomatic Nimrod? |
| 18:54:04 | _ponce | how to ensure eg. lock release with a RAII-like mechanism? |
| 18:54:38 | Araq | destructors are implemented but not finished |
| 18:54:52 | Araq | but for 'lock' I prefer a 'lock' template: |
| 18:54:59 | Araq | lock xyz: body |
| 18:57:07 | Vladar | Araq: Also, is there any easy way to properly auto-destroy ptr, aside of making it field of ref-object and place descructor call in object's finalizer? |
| 18:58:00 | Araq | Vladar: there is nothing special about 'ptr', just introduce a destructor for the type |
| 18:59:14 | _ponce | so... no stack unwinding? |
| 18:59:36 | _ponce | I would be ok with a template and a "defer" feature which inject in calling scope |
| 18:59:59 | Araq | I can't follow |
| 19:00:09 | Vladar | Yeah, I think I'll do so. But in that case I'll better get rid of all {.global.} vars in libtcod samples =) |
| 19:00:20 | _ponce | what would be the definition of the lock template |
| 19:00:36 | Araq | Vladar: you can also wait a few minutes until I fixed the bug |
| 19:00:57 | _ponce | oh, I see: a template can take any block as parameter |
| 19:01:07 | _ponce | fine then |
| 19:01:11 | Araq | _ponce: the lock template can use 'try' finally, but we have standalone 'finally' too |
| 19:01:17 | Araq | which can act as 'defer' |
| 19:01:30 | Araq | and yes we also have destructors in addition to that |
| 19:01:59 | Araq | the stdlib doesn't use these shiney new features though |
| 19:02:13 | Araq | and exposes 'close' operations or uses a GC finalizer |
| 19:02:36 | _ponce | yes you would need a kind of destructor to get an auto-destroy ptr |
| 19:03:25 | _ponce | I like this, it's more explicit than invisible stack unwinding |
| 19:03:47 | Araq | for stuff like locks, yes |
| 19:03:57 | Araq | for data abstraction nothing beats a destructor |
| 19:05:53 | Araq | IMO destructors are pretty hard to design properly |
| 19:06:35 | Araq | as you need an escape analysis for them; the C++ way of invoking destructors and copy constructors that the compiler is allowed to optimize away is just ugly |
| 19:15:12 | Araq | Vladar: I didn't test it, please try it out :P |
| 19:16:35 | Vladar | let's see |
| 19:19:27 | Araq | apriori_: the opengl names are not 'wrong', I prefixed the 'const' to prevent name clashes ;-) ... how come you didn't get any? |
| 19:19:48 | apriori_ | hrm... |
| 19:19:51 | apriori_ | ooops then.. |
| 19:20:05 | apriori_ | well, I didnt even try.. I just saw those weird constGL.... |
| 19:20:19 | apriori_ | and considered them an error when creating the wrapper |
| 19:29:47 | Vladar | Araq, it seems to work quite nice, thanks =) |
| 19:54:29 | apriori_ | do you guys have any problems with importc in the latest git version? |
| 19:54:45 | apriori_ | I apparently end up with a zero function pointer for glViewport using the gl wrapper |
| 19:58:43 | Zor | Araq: so what do you use for inline asm? sounds like that'd be very dependent on C compiler/underlying assembler |
| 19:59:37 | apriori_ | Zor: currently the asm statement, which generated a asm statement for the c compiler |
| 19:59:47 | apriori_ | there is no compiler dependent transformation done, though |
| 20:10:30 | Araq | you can implement asm transformations with compile-time string processing |
| 20:11:06 | Araq | apriori_: I made the opengl wrapper load extensions on demand, maybe that broke something for you? |
| 20:11:36 | apriori_ | Araq: pretty much.. the generated nimLoadProcs0 of the generated opengl.c is never called |
| 20:12:20 | Araq | you need to call it yourself via loadExtensions() in your main |
| 20:12:28 | apriori_ | yeah.. found it just now |
| 20:12:46 | Araq | it's documented :P |
| 20:13:01 | apriori_ | grr :P |
| 20:13:29 | apriori_ | yup.. working.. |
| 20:13:34 | Araq | it's pretty sick, the compiler generates the nimLoadProcs0() for you |
| 20:13:51 | Araq | so loadExtensions only loads the extensions you actually use in your code ;-) |
| 20:14:05 | apriori_ | yup.. I see the generated code |
| 20:14:11 | apriori_ | and yes.. only used functions included there |
| 20:14:45 | Araq | no need for 'glew' in Nimrod wonderland ... :P |
| 20:14:59 | apriori_ | glew is a pain :P |
| 20:15:19 | apriori_ | I ended up having a hell lot of issues with it.. in several projects |
| 20:15:33 | apriori_ | but it was of course much better than loading each func by hand |
| 20:16:29 | apriori_ | btw |
| 20:16:46 | apriori_ | does the nimLoadProc importc declaration cause it not to be called automatically? |
| 20:17:13 | Araq | nope, {.pragma: ogl, dynlib: glGetProc(oglHandle, "0").} does the magic |
| 20:18:15 | apriori_ | hm |
| 20:18:17 | apriori_ | I dont get it :P |
| 20:19:07 | apriori_ | I know that pragma is used for the funcs.. to make them dynload the respective func name.. |
| 20:19:34 | apriori_ | but I dont get how that should stop the code gen from generating a call which does the actual dynloading automatically |
| 20:20:17 | Araq | dynlib: callHere() has special semantics |
| 20:20:23 | Araq | that's how it works |
| 20:20:29 | Araq | I don't think I documented it |
| 20:20:32 | apriori_ | ok |
| 20:22:21 | apriori_ | btw.. |
| 20:22:26 | apriori_ | about those weird constGL_* |
| 20:22:44 | apriori_ | maybe it might be a better idea to consistently prefix all constants with something |
| 20:23:36 | Araq | I considered that, found it tedious and decided that nobody would ever use the clashing constants anyway ;-) |
| 20:24:09 | apriori_ | :P |
| 20:24:29 | Araq | the better way would be to put them into a new module openglconsts and then you can use the openglconsts.XYZ notation to get them |
| 20:27:29 | Araq | but then if you want to improve the opengl wrapper, you should introduce proper enums and make it typesafe :P |
| 20:28:00 | apriori_ | yeah.. and _that_ is tedious :P |
| 20:28:20 | Araq | and btw some people use that module so don't break it, use .deprecated. and provide a transition path |
| 20:52:02 | * | Vladar quit (Quit: Leaving) |
| 21:16:24 | * | gradha joined #nimrod |
| 21:20:15 | gradha | I'm finishing an iOS example and need a splash graphic, should I take icons/nimrod.ico and expand it to ipad retina resolutions for fun value? |
| 21:20:46 | gradha | alternatively I can use my github avatar |
| 21:28:54 | * | Zerathul joined #nimrod |
| 21:30:01 | dom96 | gradha: Nimrod icon! |
| 21:30:23 | * | Zerathul quit (Client Quit) |
| 21:32:37 | gradha | hmm... IIRC there are websites with free icons/graphics for poor programmers with bad taste, maybe I should stroll around the net for that |
| 21:44:46 | fowl | dom96: no on csfml+opengl but it should work fine |
| 21:45:14 | dom96 | I think that was apriori_ asking not me ;) |
| 21:45:26 | fowl | just call opengl.loadextensions after you create the window |
| 21:45:30 | fowl | oh mb |
| 21:45:55 | apriori_ | fowl: yeah, Araq told me.. |
| 21:46:35 | fowl | apriori_: it has to be called after the rendering context is created but before any opengl calls |
| 21:46:44 | apriori_ | yeah, got that |
| 21:46:50 | apriori_ | pretty much like glewInit |
| 21:57:54 | gradha | dom96: how are you doing on this lum dare thingy? |
| 21:58:26 | dom96 | gradha: Not very well. |
| 21:58:32 | dom96 | gradha: Not enough time sadly :\ |
| 21:59:24 | gradha | it seems it's just 4h of the compo, are you doing that or the jam? |
| 21:59:40 | dom96 | I'm doing that. |
| 22:00:06 | dom96 | If it wasn't for school tomorrow I would most likely be able to get it done. |
| 22:00:50 | dom96 | Also, It seems i've caught a cold. So i'm at a disadvantage :P |
| 22:01:59 | gradha | don't go to school because of the cold and complete your entry then |
| 22:02:40 | dom96 | lol |
| 22:03:04 | dom96 | Maybe I will but my school attendance is low enough... :P |
| 22:08:30 | gradha | yeah, no need for further graphics, it's embarrassing enough now http://dl.dropbox.com/u/145894/t/splash.png |
| 22:09:05 | dom96 | That looks pretty good actually |
| 22:09:52 | gradha | clearly you are under the effect of an illness, take care man |
| 22:09:58 | dom96 | hehe |
| 22:21:22 | dom96 | ok, that's enough for today. |
| 22:21:24 | dom96 | Good night |
| 22:21:30 | gradha | bye |
| 23:09:17 | * | gradha quit (Quit: gradha) |
| 23:22:36 | * | q66 quit (Quit: Quit) |