| 00:03:58 | * | xenagi joined #nimrod |
| 00:05:32 | * | isenmann quit (Ping timeout: 252 seconds) |
| 00:06:14 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 00:07:05 | * | LordAndrew joined #nimrod |
| 00:07:41 | * | isenmann joined #nimrod |
| 00:18:15 | * | BitPuffin joined #nimrod |
| 00:35:18 | Varriount | Hey xenagi, LordAndrew, isenmann |
| 00:35:26 | LordAndrew | Howdy. |
| 00:36:30 | LordAndrew | How are you? |
| 00:40:03 | Varriount | hungry |
| 00:40:18 | LordAndrew | ah. I just had KFC :p |
| 00:41:11 | Varriount | It's been an interesting day. Apparently parts of freenode have been invaded by silent bots. |
| 00:41:34 | Varriount | Although, 'invaded' is a bit strong. More like 'silently passing through' |
| 00:41:46 | LordAndrew | :( |
| 00:42:43 | * | easymuffin joined #nimrod |
| 00:42:53 | Varriount | Hi easymuffin |
| 01:00:53 | * | ddl_smurf quit (Ping timeout: 248 seconds) |
| 01:21:19 | xenagi | sup Varriount |
| 01:31:51 | discoloda | dang, sdl_net seems to not work (PUDPpacket values doesnt make sense) |
| 01:38:31 | * | easymuffin quit () |
| 01:55:05 | * | DAddYE quit (Remote host closed the connection) |
| 02:29:27 | * | ddl_smurf joined #nimrod |
| 02:36:13 | Varriount | Hello again ddl_smurf |
| 02:36:40 | ddl_smurf | g'evening |
| 02:38:37 | * | foxcub quit (Quit: foxcub) |
| 02:43:34 | * | EXetoC quit (Quit: WeeChat 0.4.2) |
| 02:56:47 | * | DAddYE joined #nimrod |
| 03:01:37 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 03:06:24 | * | DAddYE joined #nimrod |
| 03:11:07 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 03:23:24 | * | DAddYE joined #nimrod |
| 03:56:05 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 04:51:58 | * | vbtt joined #nimrod |
| 04:58:06 | * | LordAndrew quit (Quit: Page closed) |
| 05:15:33 | * | xenagi quit (Quit: Leaving) |
| 05:36:23 | * | brson joined #nimrod |
| 05:59:56 | * | BitPuffin joined #nimrod |
| 06:00:44 | * | derangedTypi joined #nimrod |
| 06:00:52 | * | derangedTypi left #nimrod (#nimrod) |
| 06:04:50 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 06:09:43 | * | xtagon quit (Ping timeout: 272 seconds) |
| 06:20:49 | * | vbtt quit (Quit: Page closed) |
| 06:22:31 | * | brson quit (Quit: leaving) |
| 06:23:34 | * | DAddYE quit (Remote host closed the connection) |
| 06:36:00 | * | DAddYE joined #nimrod |
| 08:02:52 | * | BitPuffin joined #nimrod |
| 08:06:30 | * | Demos quit (Read error: Connection reset by peer) |
| 08:08:02 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 08:31:42 | * | odc joined #nimrod |
| 08:33:52 | * | Araq_ joined #nimrod |
| 08:41:22 | * | noam quit (Ping timeout: 246 seconds) |
| 08:42:12 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]) |
| 08:55:33 | * | delian66 quit (Ping timeout: 272 seconds) |
| 09:04:06 | * | BitPuffin joined #nimrod |
| 09:08:51 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 09:11:39 | * | delian66 joined #nimrod |
| 09:27:10 | * | DAddYE quit (Remote host closed the connection) |
| 09:34:07 | * | CarpNet joined #nimrod |
| 09:40:50 | * | DAddYE joined #nimrod |
| 09:41:04 | * | DAddYE quit (Remote host closed the connection) |
| 09:41:10 | * | DAddYE joined #nimrod |
| 09:45:37 | * | Kooda quit (Quit: leaving) |
| 09:45:52 | * | Kooda joined #nimrod |
| 09:54:03 | * | easy_muffin joined #nimrod |
| 10:11:07 | * | Araq_ joined #nimrod |
| 10:24:14 | * | BitPuffin joined #nimrod |
| 10:30:51 | * | DAddYE quit (Remote host closed the connection) |
| 10:31:18 | * | DAddYE joined #nimrod |
| 10:35:59 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 10:51:49 | * | BitPuffin quit (Ping timeout: 248 seconds) |
| 10:52:40 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]) |
| 10:56:02 | * | BitPuffin joined #nimrod |
| 10:58:27 | * | bbodi joined #nimrod |
| 11:08:53 | * | BitPuffin quit (Ping timeout: 248 seconds) |
| 11:32:30 | * | DAddYE joined #nimrod |
| 11:36:53 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 11:40:19 | * | EXetoC joined #nimrod |
| 11:42:08 | * | DAddYE joined #nimrod |
| 11:46:47 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 12:07:57 | * | BitPuffin joined #nimrod |
| 12:38:47 | * | Araq_ joined #nimrod |
| 12:49:45 | * | BitPuffin quit (Ping timeout: 265 seconds) |
| 13:07:07 | * | Araq_ quit (Read error: Connection timed out) |
| 13:08:01 | * | Araq_ joined #nimrod |
| 13:10:29 | * | easy_muffin quit (Ping timeout: 248 seconds) |
| 13:16:43 | * | Mat3 joined #nimrod |
| 13:16:49 | Mat3 | hello |
| 13:20:52 | * | darkf quit (Quit: Leaving) |
| 13:24:03 | bbodi | hi |
| 13:25:45 | dom96 | hey |
| 13:25:57 | Mat3 | hi dom96 |
| 13:26:08 | dom96 | hello Mat3 and bbodi |
| 13:27:23 | bbodi | hi dom96 |
| 13:31:53 | bbodi | hey guys, have you got some interesting projects? what are you working on using Nimrod? |
| 13:32:13 | dom96 | oh, you're new. Welcome! :) |
| 13:32:29 | dom96 | I made Babel, Aporia, jester, ipsumgenera and some others. |
| 13:32:46 | bbodi | oh, cool :) thanks for your work! |
| 13:32:47 | dom96 | take a look at the nimrod-code organisation on github and on my profile: github.com/dom96 |
| 13:33:12 | bbodi | I know and use some of them, like Babel and Aporia |
| 13:33:39 | bbodi | btw, Nimrod is a fantastic programming langauge, Im very productive with it |
| 13:35:13 | * | faassen joined #nimrod |
| 13:36:37 | dom96 | That's good to hear |
| 13:38:35 | bbodi | I have experiences in a lot of languages, My bachelor thesis was written in D, I work as a Java developer, I learned Rust and Go as well. But currently my favourite is Nimrod :) |
| 13:39:26 | Kooda | Yay :) |
| 13:39:37 | dom96 | cool. |
| 13:39:45 | dom96 | I hope that someday I can write my thesis in Nimrod :) |
| 13:40:12 | Mat3 | bbodi: hello |
| 13:40:18 | bbodi | Mat3: hello |
| 13:40:54 | bbodi | dom96: what are you learning? |
| 13:41:03 | Mat3 | Rust seems to be quite common these day (I guess because of Mozilla) |
| 13:41:11 | dom96 | bbodi: I'm still in high school heh. |
| 13:41:47 | bbodi | Yes, Rust have a huge community support |
| 13:41:58 | dom96 | bbodi: But i'm currently studying 4 A levels: Physics, Maths, ICT and Biology. |
| 13:43:10 | bbodi | dom96: cool :) its good to see that the younger generation is so productive :) |
| 13:46:35 | dom96 | heh, yeah but sadly nowadays school is getting in the way too much. |
| 13:47:03 | bbodi | are there somebody here, who working on the Nimrod compiler itself? |
| 13:47:22 | dom96 | Araq_/Araq |
| 13:47:27 | dom96 | He's probably at work though. |
| 13:47:43 | dom96 | He's our BDFL :P |
| 13:48:23 | bbodi | yes I know his name, his the author of Nimrod. Respect him! what doeas BDFL mean? :) |
| 13:49:32 | dom96 | http://en.wikipedia.org/wiki/BDFL |
| 13:50:47 | bbodi | thanks, I didn't know it. |
| 13:52:45 | bbodi | have you got any plans for upgrading Babel? |
| 13:53:05 | * | phao joined #nimrod |
| 13:53:15 | dom96 | hello phao |
| 13:53:25 | Mat3 | h phao |
| 13:53:30 | bbodi | hi phao |
| 13:53:36 | * | BitPuffin joined #nimrod |
| 13:53:51 | dom96 | bbodi: there is a todo in the repo, also need to fix the issues. |
| 13:55:16 | Mat3 | should I support 256 bit SIMD processing (and if so, integer only + fixed-point or floating-point) ? |
| 13:55:43 | Mat3 | I remember someone was working on a vector library |
| 13:58:06 | phao | heya |
| 14:07:21 | BitPuffin | Mat3: I am |
| 14:07:48 | renesac | does nimrod have support for SIMD intrinsics? |
| 14:09:03 | EXetoC | BitPuffin: as in SIMD? |
| 14:09:16 | BitPuffin | EXetoC: what |
| 14:09:18 | BitPuffin | no |
| 14:09:22 | BitPuffin | vector library |
| 14:09:40 | BitPuffin | would sure like ta add some simd optimizations though |
| 14:10:02 | Mat3 | hi BitPuffin |
| 14:10:21 | BitPuffin | hey Mat3 |
| 14:11:31 | Mat3 | GCC support some SIMD extenesions so it would be possible to exetnd the Nimrod compiler supporting it (on the other side, this would bound Nimrod even more to GCC related extensions) |
| 14:11:36 | Mat3 | ^extensions |
| 14:11:51 | Mat3 | ^add some support for them in Nimrod |
| 14:12:23 | dom96 | You could just add a define which enables those optimisations or something. |
| 14:16:04 | renesac | Mat3, IIRC most intrinsics are more dependent on the architecture than the compiler, though their names may change from a compiler to another |
| 14:16:15 | * | phao left #nimrod ("Fui embora") |
| 14:19:38 | Mat3 | hi renesac: Anyhow, that means adjusting the compiler to a specific C backend |
| 14:21:33 | BitPuffin | which is ze lame |
| 14:21:45 | Mat3 | (an alternative would be just misusing integer arithmetic for SIMD operations which should work well for at least fixpoint) |
| 14:21:52 | Mat3 | ^specific |
| 14:23:25 | * | Mat3 damn line editor |
| 14:24:18 | bbodi | \name boba |
| 14:24:25 | bbodi | sorry |
| 14:24:49 | Mat3 | example: add 0x01020304, 0x04030201 (for a packed word of 4 bytes) |
| 14:26:31 | Mat3 | and for saturating possible overflows and-masking the highest bits of the source operands |
| 14:27:35 | Mat3 | for most CPU architectures this is probably also the fastest way of processing SIMD data |
| 14:28:21 | Mat3 | have some work to do, see you guys |
| 14:28:33 | * | Mat3 quit (Quit: Verlassend) |
| 14:28:51 | * | easy_muffin joined #nimrod |
| 14:33:12 | * | easy_muffin quit (Client Quit) |
| 14:33:32 | * | easy_muffin joined #nimrod |
| 14:35:39 | * | easy_muffin quit (Client Quit) |
| 14:36:00 | * | easy_muffin joined #nimrod |
| 14:36:32 | * | easy_muffin quit (Client Quit) |
| 14:36:46 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]) |
| 15:03:54 | * | psquid quit (Quit: groceries) |
| 15:33:50 | discoloda | in sockets, why are ports and the hton/ntoh functions signed? |
| 15:34:21 | dom96 | Because Araq doesn't like unsigned ints. |
| 15:34:51 | * | [1]Endy joined #nimrod |
| 15:34:52 | discoloda | it breaks with ports over 32768 |
| 15:35:26 | dom96 | Actually, I thought we fixed that. |
| 15:35:34 | dom96 | Are you on master/devel? |
| 15:35:54 | discoloda | master |
| 15:36:10 | dom96 | TPort* = distinct uint16 |
| 15:36:18 | dom96 | ports are unsigned |
| 15:36:57 | discoloda | its the hton/ntoh functions where it initially broke for me |
| 15:47:52 | BitPuffin | dom96: well I hate compilers, doesn't mean I shouldn't use them ;) |
| 15:48:14 | dom96 | BitPuffin: huh? |
| 15:49:00 | BitPuffin | dom96: doesn't like unsigned ints, doesn't like compilers |
| 15:49:07 | BitPuffin | dom96: are you slow poke today? |
| 15:49:22 | dom96 | oh right |
| 15:49:23 | dom96 | Yes |
| 15:49:41 | dom96 | Trying to get IOCP to work is messing with my brain. |
| 15:49:42 | BitPuffin | dom96: you should play dota 2 |
| 15:49:51 | BitPuffin | dom96: tf2noob |
| 15:50:07 | BitPuffin | dom96: at least you can pride yourself that death prophet, glados, and the tf2 announcer is the same person |
| 15:56:06 | discoloda | why hate on unsigned ints? |
| 15:56:48 | dom96 | https://github.com/Araq/Nimrod/wiki/Unofficial-FAQ#why-are-unsigned-types-discouraged |
| 15:59:30 | * | psquid joined #nimrod |
| 16:01:59 | Kooda | Even if he doesn’t like them, they have to work because they are still useful in some cases (like low level) |
| 16:02:18 | Kooda | repr() doesn’t work with unsigned |
| 16:02:20 | * | easy_muffin joined #nimrod |
| 16:04:29 | BitPuffin | seems a bit unjustified |
| 16:04:31 | BitPuffin | anyway gotta go |
| 16:06:48 | EXetoC | I don't think so |
| 16:08:45 | EXetoC | positive ranges are fine imo. they just need to work a little better with tuples |
| 16:09:35 | renesac | they are not fine because they don't wrap around, which is needed in most places you would use unsigned numbers |
| 16:10:57 | EXetoC | I didn't say the should never be used |
| 16:11:15 | EXetoC | I guess it sounded like it |
| 16:12:07 | renesac | so, we need to define a int128 to be used everywhere in the compiler? |
| 16:13:09 | renesac | so uints can get a Ordinal treatment? |
| 16:13:14 | * | BitPuffin quit (Ping timeout: 265 seconds) |
| 16:15:28 | * | easy_muffin quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 16:33:35 | renesac | though other compilers seems to have implemented uints w/o resorting to that... |
| 16:35:11 | * | foxcub joined #nimrod |
| 16:35:48 | * | Demos joined #nimrod |
| 16:43:28 | renesac | hum, in D they effectively use a int65 |
| 16:43:30 | renesac | https://github.com/D-Programming-Language/dmd/blob/a3743bc645fc065104470cdecbd64e3f14034fdf/src/intrange.c |
| 16:45:56 | renesac | I'm not sure how it trickles down to the rest of the compiler |
| 17:09:11 | * | psquid quit (Ping timeout: 260 seconds) |
| 17:10:13 | * | psquid joined #nimrod |
| 17:10:34 | * | psquid quit (Changing host) |
| 17:10:34 | * | psquid joined #nimrod |
| 17:23:10 | reactormonk | what is {.borrow.} exactly? |
| 17:26:17 | EXetoC | isn't the description in the manual any good? |
| 17:27:43 | * | foxcub quit (Quit: foxcub) |
| 17:40:52 | reactormonk | sweet |
| 17:42:09 | * | DAddYE joined #nimrod |
| 17:42:27 | * | DAddYE quit (Remote host closed the connection) |
| 17:42:40 | * | DAddYE joined #nimrod |
| 17:57:13 | * | brson joined #nimrod |
| 18:09:50 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 18:10:02 | * | vbtt joined #nimrod |
| 18:18:19 | * | [1]Endy quit (Ping timeout: 260 seconds) |
| 18:18:22 | * | noam joined #nimrod |
| 18:32:03 | Araq | renesac: in the original design of Nimrod, there was no unsigned, but there was +% to get wrap around addition etc. |
| 18:32:41 | * | CarpNet quit (Quit: Leaving) |
| 18:32:42 | Araq | just because you need wrapping this doesn't mean you have to introduce a whole new integer type zoo |
| 18:32:56 | * | LordAndrew joined #nimrod |
| 18:33:14 | Araq | otherwise you also need saturatedInt, saturatedInt8, etc ... |
| 18:34:21 | Araq | btw LLVM does it the same way, there is only i32, i8, etc. and then there are signed/unsigned operations for these |
| 18:38:44 | EXetoC | I didn't understand those operators. It's obvious now.. |
| 18:44:10 | reactormonk | any comments on better nimrod? http://dpaste.com/1563108/ |
| 18:46:15 | Araq | reactormonk: line 22, conversion to int is not necessary |
| 18:46:31 | Araq | result = ""; setLen --> result = newString(destLen) |
| 18:46:43 | Araq | use 'let' instead of 'var' where possible |
| 18:47:07 | reactormonk | what's the difference? |
| 18:48:03 | Araq | rtfm |
| 18:48:55 | reactormonk | immutability included? |
| 18:49:22 | Araq | like scala's val vs var, yes |
| 18:49:55 | * | Demos quit (Ping timeout: 252 seconds) |
| 18:52:19 | Araq | hi bbodi, are you new? |
| 18:52:34 | Araq | welcome |
| 18:53:45 | vbtt | I'm not really sure of the difference between const and let |
| 18:54:08 | Araq | const # evaluate at compile time |
| 18:54:12 | Araq | let # immutable |
| 18:54:25 | reactormonk | let # evaluate at runtime |
| 18:54:28 | reactormonk | they're both immutable. |
| 18:54:34 | Araq | yeah |
| 18:55:07 | vbtt | ah i see. so prefer const over let over var, it seems? |
| 18:55:21 | Araq | yes |
| 18:55:54 | reactormonk | const adds the most constraints, whereas var the least, etc. |
| 18:56:53 | vbtt | yeah. the word 'let' seems out of place though, being a verb. though i dont have a better suggestion. |
| 18:57:32 | reactormonk | `val` |
| 18:58:21 | vbtt | val looks too much like var. |
| 18:58:49 | Araq | let is common in ML-like languages so it's perfectly fine |
| 18:59:09 | Araq | iirc some dialects of basic also use 'let' |
| 18:59:31 | * | Mordecai joined #nimrod |
| 19:00:21 | * | psquid quit (Ping timeout: 248 seconds) |
| 19:00:23 | vbtt | let implies both single assignment and immutability? |
| 19:01:29 | * | Mordecai is now known as psquid |
| 19:04:00 | Araq | actually only single assignment |
| 19:04:56 | vbtt | hmm ok. |
| 19:05:48 | vbtt | how is const different from 'let' within a static block? |
| 19:05:59 | * | xtagon joined #nimrod |
| 19:06:34 | * | BitPuffin joined #nimrod |
| 19:06:50 | Araq | the code generator doesn't treat let within static special, but it treats consts special |
| 19:07:43 | Araq | apart from that I don't think there are any differences but note that 'static' came much later |
| 19:10:02 | vbtt | ok. just for simplicity it would be nice to have fewer types of assignment statements. |
| 19:11:58 | Araq | *shrug* the number of control flow constructs or assignment statements pales in comparison to the stdlib |
| 19:12:22 | Araq | this holds for every programming language I know |
| 19:13:12 | Araq | leaving out "case" in the name of simplicity (Python) is just absurd |
| 19:14:09 | reactormonk | vbtt, `let` doesn't enforce imutability of the structure you're referencing, only the reference |
| 19:16:39 | vbtt | Araq: i'm just suggesting removing any redundancy without sacrificing convenience. the little decisions the programmer's make ("let or const?") add up. |
| 19:17:03 | vbtt | but yeah - I do support the case statement. |
| 19:17:10 | vbtt | reactormonk: thanks. |
| 19:17:56 | reactormonk | vbtt, I don't see any way to make it easier. You need all three stages. |
| 19:18:27 | Araq | vbtt: that argument would be valid if you can decide wether to use let or const, but you can't really, it's deterministic what to use |
| 19:18:47 | vbtt | reactormonk: I was wondering if let within static blocks could that replace const. |
| 19:19:07 | vbtt | ok, nevermind. it's not a big deal. |
| 19:34:36 | * | easy_muffin joined #nimrod |
| 19:35:11 | EXetoC | the high-level DB interface can't really be used for complex queries, right? |
| 19:35:28 | Araq | lol what makes you think so? |
| 19:35:49 | Araq | I use it for queries of arbitrary complexity |
| 19:41:53 | reactormonk | there's `openbabel` which also has a binary `babel` :-/ |
| 19:43:26 | EXetoC | Araq: and when the returned rows are complex? deep nestings etc. it's not a problem in simple cases at least, because you just need a couple of helper functions |
| 19:44:15 | Araq | EXetoC: there is no such thing as "complex rows", it's always a 2D table |
| 19:45:40 | Araq | but maybe instead of strings as the base type I should have used JSON ... |
| 19:46:09 | Araq | oh well, we can always create db_postgre2.nim ... :P |
| 19:47:43 | Araq | would actually pretty cool to unify JSON and whatever the Db uses as its native format |
| 19:48:39 | vbtt | stupid q - whats koch? |
| 19:48:42 | EXetoC | yes. I'm using arrays and it's complicated already, so I'll use the wrapper when necessary |
| 19:49:27 | Araq | vbtt: koch is german and means "cook" |
| 19:51:34 | vbtt | ok |
| 19:55:13 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 19:55:14 | Araq | EXetoC: which db are you using? |
| 19:58:05 | * | BitPuffin joined #nimrod |
| 19:58:48 | EXetoC | Araq: postgres |
| 20:01:08 | Araq | EXetoC: can you adapt db_postgres and create dbj_postgres (= with JSON)? |
| 20:02:25 | * | brson quit (Quit: leaving) |
| 20:24:41 | vbtt | Araq: is there a detailed roadmap to 1.0? |
| 20:25:06 | Araq | there is my todo.txt and zahary keeps his own todo somewhere |
| 20:25:15 | vbtt | also, the website news is old and may give the impression of an inactive project. |
| 20:25:58 | reactormonk | vbtt, you say we should use the issue tracker on github for the news instead? |
| 20:26:22 | dom96 | oh yes. We should add a new post to the news about Araq's talk |
| 20:27:13 | vbtt | reactormonk: doesn't matter what you use, issue tracker, git. just that the website looks 'alive' |
| 20:27:27 | vbtt | also people know what to expect in the future. it keeps the excitement up. |
| 20:27:40 | vbtt | i mean - *if* people know.. |
| 20:27:41 | reactormonk | dom96, s/We/you/ |
| 20:28:12 | reactormonk | btw, having the same css for both webpage and tutorials would be nice too |
| 20:28:20 | reactormonk | do we have an issue tracker for the website? |
| 20:28:20 | vbtt | you could even publish the todo.txt into the website and link prominently. |
| 20:31:01 | reactormonk | or just give it to me and I'll write it into the issue tracker |
| 20:32:13 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 20:37:59 | Araq | gah, not more issues please |
| 20:38:20 | * | [1]Endy joined #nimrod |
| 20:39:02 | Araq | vbtt: my plan is to get this feature complete for 0.9.4 and then we have 3 versions of bugfixes and optimizations |
| 20:39:33 | Araq | in fact, we only have the resources to either fix bugs or work on new stuff ... sad, but true |
| 20:40:19 | vbtt | Araq: yes i understand. fwiw, i suggest fix bugs and stabilize. you can always add more features later. |
| 20:40:43 | vbtt | also, more ppl will look at stable releases and then you'll have more feedback to build the features you want to build. |
| 20:41:42 | Araq | I don't think we need more feedback really, studies show 5 beta testers are enough and quality only gradually improves with more testers |
| 20:42:11 | Araq | in fact, bug reports are already often duplicates |
| 20:42:24 | Araq | or reporting what we already know |
| 20:43:04 | * | BitPuffin joined #nimrod |
| 20:43:39 | vbtt | Araq: if not for feedback, you want more ppl to build more libraries, no? |
| 20:44:56 | vbtt | I'm just saying i'd rather see a stable language sooner so I can use it to build stuff, rather than a bigger language later. |
| 20:47:16 | vbtt | right now I can use c, which is a pain. or go, which i didn't like, or rust (not ready). but nimrod is so much better. |
| 20:47:24 | vbtt | i wish it were more 'ready' :) |
| 20:48:20 | xtagon | If I can weigh in on this...I wish it were more "ready" also, but I think we should just be appreciative of how active and awesome this project is already :) It's not like we're entitled to a stable version, it's not our project |
| 20:48:49 | * | tdc joined #nimrod |
| 20:48:54 | Araq | vbtt: pay me for it and you'll get a stable release much sooner |
| 20:49:21 | Araq | that's what is really missing. commercial support |
| 20:49:46 | vbtt | I wish I could. |
| 20:49:53 | Araq | there has never ever worked a person fulltime on Nimrod |
| 20:50:39 | vbtt | yeah i realize, i'm not complaining, just saying if nimrod becomes more poplular, you might get paid for working on it too (at least part time) |
| 20:51:26 | reactormonk | donation button \o/ |
| 20:51:29 | vbtt | xtagon: agree. |
| 20:52:55 | vbtt | and i definitely appreciate all your effort on the language. |
| 20:53:17 | vbtt | think about it this way -if people didn't like the language, they wouldn't be asking for more :) |
| 20:54:58 | Araq | yeah thanks :-) |
| 20:55:15 | * | faassen quit (Quit: Leaving.) |
| 20:55:21 | Araq | vbtt: so what about full coroutines? can they wait for 1.0 ? |
| 20:55:26 | Araq | *for after 1.0 |
| 20:55:50 | * | Demos joined #nimrod |
| 20:55:57 | vbtt | Araq: I thought they were not in 1.0 anyway (unless I or someone else implemented them :) |
| 20:56:15 | vbtt | but yeah - sure - after 1.0. as long as you make sure it's in the published roadmap. |
| 20:56:38 | renesac | Araq: hum, indeed that is another way, but when using those +% operations there is no advantage of ints over uints anymore, except perhaps for the compiler writer... |
| 20:56:56 | vbtt | nimrod already has a lot of great stuff - templates, macros, clean syntax. |
| 20:57:29 | Araq | vbtt: your point is valid though, coroutines are a game changer for writing severs |
| 20:57:46 | Araq | which is what most people do nowadays with a "systems" programming language |
| 20:57:51 | vbtt | Araq: yes, look at go. that's the only worthwhile feature ;) |
| 20:57:59 | Araq | yup |
| 20:58:03 | renesac | and they are more limited (no +=, or >= as far as I can see), and more prone to errors when translating algorithms (some + left behind) |
| 20:58:32 | vbtt | Araq: but..there are other things ppl can do with sytems languages. nimrod right now is clean 'C' with powerful metaprogramming. |
| 20:58:56 | Araq | one can learn a lot from golang when it comes to conquer the market |
| 20:59:03 | renesac | btw, saturated types do not look like a bad idea for people who needs to use them... |
| 20:59:04 | vbtt | Araq: which is also very useful. you just have to make sure people know you've thought about coroutines and they will be in later.. |
| 20:59:37 | * | shodan45 stabs PHP in the face |
| 20:59:49 | Araq | renesac: there is >=% |
| 21:00:14 | * | [1]Endy quit (Ping timeout: 264 seconds) |
| 21:00:20 | Araq | and that's the beauty of it really, you can do if x <% len and get the fast check |
| 21:00:22 | renesac | oh, it isn't listed on the manual (only >=%) |
| 21:00:34 | Araq | the manual doesn't repeat system.nim |
| 21:02:11 | shodan45 | Araq: if you ever look at PHP, please only use it as a "never ever do this" example |
| 21:02:22 | renesac | it don't needs to repeat system.nim, but I would expect the tables to be complete... |
| 21:02:50 | Araq | renesac: you're right about the "error prone" and hence I had to add unsigned but I still wish unsigned would never have been invented in the first place |
| 21:03:00 | xtagon | shodan45, Ah, PHP. The breakfast of masochists. |
| 21:03:15 | Araq | just imagine C would support unsigned floats |
| 21:03:23 | Araq | and the mess that would result from that |
| 21:03:41 | Araq | all to save a single bit in a 64bit number ... |
| 21:04:20 | * | LordAndrew quit (Ping timeout: 272 seconds) |
| 21:04:23 | renesac | power of two numbers are pretty, 63 is not |
| 21:04:24 | renesac | :P |
| 21:04:43 | * | Mordecai joined #nimrod |
| 21:04:51 | Araq | and everybody needs then to support unsigned float as some C library ends up using them and everybody needs to wrap against it |
| 21:04:58 | renesac | but yeah, it may be because unsigned numbers exists that this is so... |
| 21:05:37 | * | radsoc joined #nimrod |
| 21:05:40 | Araq | and the C library only uses them because C programmers are too stupid to tell the difference between "unsigned" and "positive" |
| 21:06:25 | * | psquid quit (Ping timeout: 272 seconds) |
| 21:07:10 | * | shodan45 goes back in time & kills whoever added "magic quotes" to PHP |
| 21:07:34 | Araq | shodan45: there is a lot to learn from PHP |
| 21:07:43 | * | reactormonk goes back in time & kills whoever added PHP |
| 21:08:27 | renesac | shodan45: I assume you already have read this: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ |
| 21:08:29 | shodan45 | I've now wasted 3+ hours because somehow this dev server's magic_quotes_gpc setting got enabled |
| 21:08:46 | shodan45 | renesac: oh yes. I almost have that URL memorized. |
| 21:08:49 | reactormonk | shodan45, magic quotes? |
| 21:09:27 | shodan45 | reactormonk: yes, magic quotes. An idea that transcends stupidity. |
| 21:10:11 | shodan45 | reactormonk: it escapes all incoming get, post, and cookie data with backslashes |
| 21:10:40 | shodan45 | err it escapes quotes with backslashes |
| 21:11:24 | shodan45 | I'm now waiting for the server admin to tell me wtf is going on. >_> |
| 21:11:35 | vbtt | Araq: a big reason behind golangs success is corporate backing and famous people |
| 21:13:41 | Araq | vbtt: indeed but their "worse is better" attitude also helped tremendously to get 1.0 out |
| 21:15:02 | vbtt | Araq: perhaps. people complain more about generics missing in golang than they will about coroutines missing in nimrod. |
| 21:15:47 | vbtt | also, there's a way to actually implement coroutines in nimrod and someone will do it. unlike golang where they explicitly reject generics now and forever. |
| 21:16:17 | Araq | golang will get generics |
| 21:16:30 | * | Mordecai is now known as psquid |
| 21:16:31 | Araq | it may not be tomorrow, but it will get them |
| 21:16:48 | Araq | they might end up being crap like Java's generics |
| 21:17:14 | vbtt | heck, just C with nicer metaprogramming and cleaner syntax will be a nice language to use. nimrod has all that and gc, better variants, methods, generics already! |
| 21:17:34 | vbtt | Araq: afaik, the core golang devs are against generics. |
| 21:18:12 | vbtt | anyway, what i'm saying is you already have an extremely useful set of features in a nice bundle. just polish it and release. |
| 21:18:12 | Araq | vbtt: they are but it doesn't matter too much |
| 21:18:21 | renesac | vbbt: gc isn't universally regarded as a good thing, especially among c/c++ programmers |
| 21:18:49 | renesac | see rust popularity and recent deprecation of @ pointer type |
| 21:19:06 | Araq | I'm against methods and inheritance and now look what nimrod has |
| 21:19:48 | vbtt | renesac: but gc is useful for a number of uses, even in systems type programming. i don't think the gc is going away. my basic point being 'nimrod has a very useful set of features already to be a complete language' |
| 21:20:00 | Araq | though that could also just show my lack of balls to leave this feature out ;-) |
| 21:20:20 | renesac | yep |
| 21:20:36 | renesac | rust is still experimental in their gc-less aproach |
| 21:21:25 | * | Araq uses inheritance as an optimization to save memory ... |
| 21:21:27 | bstrie | Araq: I'm not convinced that the go devs will ever implement generics. their attitude of "we'll think about doing this someday" appears to be mostly lipservice to get people off their back |
| 21:21:33 | vbtt | Araq: fwiw, i don't like inheritance either. specially with the good 'generic' feature that nimrod now has, inheritance is pointless. |
| 21:21:55 | vbtt | Araq: perhaps you're letting too much slip in. |
| 21:22:18 | renesac | but I would like to see owned pointers in nimrod 2.0, but I'm afraid it would let to a substantially different language, as is happening with rust |
| 21:22:59 | renesac | (actually, I haven't done any rust programming, so I don't know how bothersome the static checks on pointers are, and I'm a bit afraid of them) |
| 21:23:31 | * | bstrie tempts renesac with the forbidden rusty fruit |
| 21:24:08 | vbtt | that's why i'm suggesting to stop adding features (in fact remove some that aren't fully backed) and focus on 1.0 with a well defined feature set and stable syntax. |
| 21:24:25 | Araq | renesac: actually my "write tracking" algorithm can compute lent pointers easily, so owned pointers look feasible ... |
| 21:24:51 | Araq | vbtt: even ML had to add some form of inheritance for its exceptions |
| 21:25:09 | Araq | that was the point that made me add it |
| 21:25:30 | vbtt | Araq: invent another system for exceptions. the control flow for exceptions seems ok but the inheritance always seemed wonky to me. |
| 21:25:31 | bstrie | Araq: keep in mind that owned pointers in rust would be way too painful without also having borrowed references |
| 21:25:56 | vbtt | why do all my errors have to align in a nice hierarchy? |
| 21:26:00 | Araq | bstrie: borrowed references can be computed after the fact |
| 21:26:07 | vbtt | maybe i should just use tags or something. |
| 21:26:24 | Araq | with minimal adjustments to what we already have, bstrie |
| 21:26:52 | Araq | afaik anyway, haven't thought too hard about it |
| 21:27:37 | * | zahary joined #nimrod |
| 21:31:59 | renesac | how do I inspect what type a variable/expression is (I'm having trouble to find that in the manual)? |
| 21:32:25 | Araq | type(x) |
| 21:32:31 | renesac | oh, simple |
| 21:32:38 | renesac | ^^" |
| 21:34:25 | renesac | I got "Error: internal error: GetUniqueType" |
| 21:35:18 | Araq | that means the meta type ended up somewhere it shouldnt |
| 21:35:55 | renesac | I tried to print it, and then I just tried to assign it to a variable |
| 21:36:08 | shodan45 | Araq: couldn't you do inheritance via macros/templates? |
| 21:36:15 | renesac | *and then I got less ambitious and just .. |
| 21:36:38 | vbtt | Araq: the new vm stuff, not sure what the use case for that is. |
| 21:36:54 | Varriount | Araq: Fwiw, the manual doesn't really explain *why* methods are needed, or how they should be used - it just says stuff about how they are calculated at run-time |
| 21:37:16 | EXetoC | = virtual |
| 21:37:25 | EXetoC | unlike procs |
| 21:37:37 | * | tdc quit (Quit: Leaving) |
| 21:38:01 | vbtt | Varriount: methods are dynamic dispatch but procs are static? |
| 21:38:01 | Araq | shodan45: you can come very close with a converter |
| 21:42:10 | Varriount | renesac: I'm reading that php-fractal article you linked. It's quite entertaining |
| 21:42:34 | vbtt | reading the todo: omg you have a generational gc in there? |
| 21:42:55 | vbtt | even golang shipped without a generational gc for 1.0, no? |
| 21:44:48 | Araq | a generational gc is not particularly hard to implement :P |
| 21:44:59 | Araq | but surely doesn't have to be in 1.0 |
| 21:45:10 | renesac | is a gerational gc a big win in a language that uses the stack as much as possible? |
| 21:45:32 | renesac | I understand this type of gc was developed thinking on java |
| 21:45:54 | Araq | renesac: I'm quite sure it's a big win for nimrod too |
| 21:46:48 | Araq | using the stack "as much as possible" helps but stacks suck :-) |
| 21:48:03 | Araq | the real problem is that the return value stack has been conflated with the parameter stack to the point it's hard to even think how to do it properly |
| 21:48:58 | renesac | hum |
| 21:49:05 | Araq | but think about it ... return address are stored in the same memory as stack frames and so when you return the memory is freed at the same time |
| 21:49:40 | Araq | that works as long as you don't want the frame to escape |
| 21:50:39 | renesac | escape? |
| 21:50:45 | Araq | I think Algol got function call semantics fundamentally wrong and we never recovered from that |
| 21:51:09 | Araq | but I'm not sure how it needs to be done either :P |
| 21:51:18 | renesac | any article/blog post ranting on that? |
| 21:51:29 | Araq | no ... |
| 21:52:08 | renesac | right... but are you planing on allocating all via gc instead of the stack? |
| 21:52:10 | vbtt | Araq: surely the semantics don't require a stack? |
| 21:52:20 | vbtt | it's just an implementation detail, no? |
| 21:53:44 | vbtt | it would be sweet if the function frames were on the heap. for one, coroutines will be trivial. however you'll have memory allocation/deallocation overhead. |
| 21:53:53 | Araq | renesac: no |
| 21:54:01 | Araq | vbtt: ML does that |
| 21:55:18 | renesac | right, it would be a terrible idea in terms of memory use and probably performance (stacks seems very efficient, if limited) |
| 21:55:28 | renesac | I think |
| 21:56:30 | renesac | by the way, what nimrod uses behind the scenes for memory allocation? jemalloc? |
| 21:56:40 | vbtt | renesac: you can optimize it by allocating large chunks and using them as a stack so avoiding gc overhead. |
| 21:57:32 | renesac | vbtt: at the cost of even more memory overhead...? |
| 21:58:03 | Demos | renesac: you should nimgrep for alloc, alloc0 and friends |
| 21:58:18 | vbtt | renesac: no - the memory used will be the same. just on the heap instead of the stack. but you'll have overhead at every function call. |
| 21:58:42 | vbtt | Araq: not that i'm suggesting it but it should be feasible to make nimrod 'stackless', right? |
| 21:59:07 | vbtt | i.e. the parameter and return value are stored in heap objects. only C calls use the stack. |
| 21:59:26 | vbtt | wait the function return addresses are the issue. |
| 22:00:14 | renesac | Demos: nimgrep is a tool? |
| 22:00:18 | Demos | yeah |
| 22:00:26 | Demos | it is in the nimrod source repo |
| 22:00:34 | Demos | it is like grep....for nimrod |
| 22:00:38 | renesac | right |
| 22:01:02 | Araq | renesac: nimrod uses it's own allocator, was faster than dlmalloc when I benchmarked it years ago |
| 22:01:44 | Araq | should still be on par with other allocators since it's thread local anyway |
| 22:02:34 | Araq | and we have more efficient thread local storage than what an allocator might use |
| 22:07:17 | renesac | hum, why? |
| 22:07:38 | renesac | and have you read the stuff in http://www.canonware.com/jemalloc/ ? |
| 22:08:40 | renesac | jemalloc seems to have received many man hours to make it as generic and optimized as possible |
| 22:09:12 | * | easy_muffin quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 22:09:22 | renesac | I also liked their experimental api, makes much more sense than the traditional one |
| 22:10:38 | * | easy_muffin joined #nimrod |
| 22:11:28 | Araq | renesac: it doesn't matter, jemalloc solves a different problem than nimrod's allocator |
| 22:11:35 | Araq | but here you go: "This allocator uses multiple arenas in order to reduce lock contention for threaded programs on multi-processor systems." |
| 22:11:45 | Araq | nimrod's uses 0 locks. |
| 22:11:51 | dom96 | easy_muffin: I don't think anyone welcomed you yet. So welcome :) |
| 22:11:58 | renesac | right |
| 22:12:04 | easy_muffin | Hi |
| 22:13:41 | Araq | hi easy_muffin, I thought you were BitPuffin ... |
| 22:14:45 | EXetoC | rly |
| 22:16:43 | renesac | your allocator then chose the performance extreme over memory overhead in this tradeoff. |
| 22:17:48 | Araq | renesac: or maybe it doesn't need to provide shared memory because we have allocShared for that, which C lacks |
| 22:18:02 | easy_muffin | Hi Araq, no i'm not BitPuffin ;-) |
| 22:18:22 | Araq | in C some other thread can dealloc, in nimrod that's not allowed |
| 22:18:41 | * | easy_muffin quit () |
| 22:18:42 | Araq | allocators for C need to be more generic and this adds overhead |
| 22:19:27 | renesac | hum, but the reason they don't use arenas == number of threads seems to be because the memory overhead of an arena |
| 22:20:04 | renesac | so they use thread-specific caches |
| 22:20:31 | Araq | but even if jemalloc is faster and uses less memory that doesn't help nimrod because nimrod's GC needs to determine *quickly* if some bit pattern is a valid pointer |
| 22:20:50 | Araq | does jemalloc support this feature? not afaict |
| 22:21:12 | * | odc quit (Ping timeout: 252 seconds) |
| 22:21:26 | vbtt | Araq: is nimrod's gc precise? |
| 22:21:30 | Araq | so yeah, we're stupid to not use components built for entirely different purposes |
| 22:21:53 | Araq | vbtt: it is precise except for the stack scanning which has to be conservative for C interop |
| 22:22:01 | renesac | hum, I was not saying that you were stupid |
| 22:22:29 | renesac | only afraid of a small NIH syndrome |
| 22:22:32 | Araq | good ;-) |
| 22:22:55 | Araq | of course I have a NIH syndrome, I invented a fucking programming language |
| 22:23:12 | renesac | lol |
| 22:24:43 | renesac | well, that is just performance optimization, not really relevant now for nimrod (the language itself already seems plenity fast) |
| 22:26:26 | * | zahary quit (Quit: Leaving.) |
| 22:30:50 | * | Demos quit (Ping timeout: 264 seconds) |
| 22:43:23 | Araq | vbtt: the plan was that the new VM fixes lots of bugs regarding macro evaluation but all it achieved was to keep me busy for months |
| 22:43:42 | Araq | but now that I spent so much time on it, I don't want to go back |
| 22:44:02 | vbtt | ah so it's primarily the compile time evaluator. |
| 22:44:17 | vbtt | and as a bonus a runtime 'eval' ? |
| 22:44:21 | Araq | at least it's faster and nimrod now performs compile time evaluation faster than python runtime evaluation |
| 22:44:49 | Araq | yeah we get "eval" as a bonus |
| 22:45:11 | Araq | but in retrospect it was a mistake to write it |
| 22:45:53 | vbtt | why? is it not better than the old one? |
| 22:46:37 | Araq | it certainly is more complex and still lacks some features like checking for overflows |
| 22:47:24 | Araq | also it created a nasty situation when it comes to closures |
| 22:47:51 | Araq | which couldn't have been forseen |
| 22:48:34 | Araq | but oh well, it's faster :P |
| 22:52:18 | vbtt | heh ok |
| 22:54:23 | * | Demos joined #nimrod |
| 22:55:26 | Araq | huh? no questions about the closure problem? |
| 22:56:14 | Araq | you cannot possibly simply accept what I say!? |
| 22:56:27 | renesac | what was the closure problem? (said in a slow questioning voice) |
| 22:56:27 | renesac | XD |
| 22:57:02 | * | NimrodBot joined #nimrod |
| 22:57:11 | * | NimrodBot quit (Read error: Connection reset by peer) |
| 22:57:24 | Araq | we must not perform lambda lifting for the JS backend but for compile time evaluation now we need to do it |
| 22:57:28 | * | NimrodBot joined #nimrod |
| 22:57:47 | Araq | hi NimrodBot, is NimBot your girlfriend? |
| 22:58:20 | renesac | you should have started with "Glad you asked" ;) |
| 22:59:04 | * | NimrodBot quit (Read error: Connection reset by peer) |
| 22:59:13 | EXetoC | Araq: so you want arbitrary query results to be converted to json? |
| 22:59:48 | Araq | EXetoC: yeah, or do your query results now produce cyclic graphs? |
| 23:01:22 | EXetoC | ugh. no |
| 23:01:52 | Araq | then it's easy to map it to JSON |
| 23:02:53 | * | Araq notes that nothing is easy to map to xml ... :P |
| 23:03:38 | vbtt | Araq: why cant you do lambda liftin for the js backend? |
| 23:04:02 | EXetoC | it must be possible to figure out if something is an array, but this particular OID isn't present in any header |
| 23:04:13 | dom96 | Really odd errors happen when you put the export marker after the [T] |
| 23:04:28 | EXetoC | PQfmod maybe |
| 23:04:31 | Araq | vbtt: that produces JS functions which are not compatible with JS's callbacks afaict |
| 23:05:02 | vbtt | Araq: i see. honestly I dont know why you have a js backend. |
| 23:05:34 | Araq | so your frontend can re-use your validation logic |
| 23:05:49 | Araq | also not many statically typed language compile to JS |
| 23:06:00 | EXetoC | eh no |
| 23:06:05 | Araq | well now that emscripten exists that's wrong |
| 23:06:23 | Araq | but emscripten didn't exist back then |
| 23:06:33 | vbtt | dart? *mostly* statically typed. |
| 23:06:52 | Araq | dart is made by people who still think OO is a good idea |
| 23:06:58 | vbtt | and there's a few more now - ceylon. |
| 23:07:06 | vbtt | the point is - statically typed. |
| 23:07:10 | Demos | dart is like javascript without any of the good ideas |
| 23:07:25 | vbtt | anyway - seems like a lot of work to avoid validation duplication. |
| 23:07:32 | dom96 | haskell can nowadays even compile to JS IIRC |
| 23:07:46 | Araq | argh, yeah yeah yeah, got it |
| 23:08:05 | Demos | ceylon turned my off by being all "you can not overload operators but you can overload a function "add" that will get called by the + operator, this is surely safer" |
| 23:08:17 | dom96 | Araq: Should this work? https://github.com/Araq/Nimrod/issues/833 |
| 23:08:23 | Demos | but then again I only looked at ceylon for like 30mins |
| 23:08:53 | Araq | dom96: yeah, it's a known regression |
| 23:09:15 | dom96 | Araq: Count that as a showstopper for me then. |
| 23:09:24 | vbtt | Araq: if you want a validation checker, just have a simple nim2js(nimf) call that converts pure functions to js. |
| 23:09:32 | Araq | just use 'int' instead of 'void' and continue, dom96 |
| 23:09:33 | vbtt | Araq: or just distch the js backend for now. |
| 23:09:36 | Araq | will fix it asap |
| 23:09:40 | vbtt | revisit later. |
| 23:09:44 | dom96 | Araq: oh is it to do with void? |
| 23:09:54 | Araq | dom96: yes |
| 23:10:05 | dom96 | that's cool |
| 23:10:27 | * | radsoc quit (Ping timeout: 260 seconds) |
| 23:10:53 | Araq | vbtt: we can mark it experimental for 1.0 |
| 23:11:21 | vbtt | Araq: sure. fronend developers will not want to write nimrod, trust me. |
| 23:11:42 | Araq | but I don't want to write in JS :P |
| 23:11:55 | vbtt | and often you may not want javascript validators identical to the backend ones. e.g. js may validate as you type or prevent you from typing certain keys. |
| 23:12:02 | dom96 | We just need a nice Nimrod JS to Nimrod Jester bridge ;) |
| 23:13:55 | Demos | frankly I dont see why everyone is so intent on getting nimrod to support webscale big data in the cloud. It seems totally ideal for game programming, and game programmers currently endure pain that can not be solved with things like python. Speaking of which has anyone else seen that talk by Tim Sweeny (Epic Games) on the next programming language for games? |
| 23:14:59 | vbtt | Demos: why not both? |
| 23:15:03 | discoloda | Nimrod to brainfuck, we need that |
| 23:15:45 | dom96 | What we need is compile-time brainfuck evaluation. |
| 23:15:57 | Demos | sure I guess both would be good... Maybe I just don't like the web |
| 23:16:10 | renesac | we could re-write the compiler in brainfuck, and get rid of that problems with closures |
| 23:16:21 | Araq | Demos: Tim Sweeny's talk is that old PDF, right? |
| 23:16:26 | Demos | yeah |
| 23:16:39 | Demos | the one with the terrable clipart |
| 23:16:53 | Araq | that has been debunked by now |
| 23:17:11 | Araq | "we never use assembler" -- yes, you do |
| 23:17:38 | Demos | yeah, it was a bit of a "fireside chat" |
| 23:19:56 | Araq | vbtt: speaking of which, game engines seem to benefit from inheritance ;-) |
| 23:20:05 | * | darkf joined #nimrod |
| 23:20:26 | Araq | one of the rare domains where OO seems to work |
| 23:20:48 | Demos | Really? I think inheratance is OK for game engines, but it is not ideal. You tend to get some classes that grow without bound |
| 23:20:50 | vbtt | how is it used in game engines? |
| 23:20:54 | Demos | player and AI seem to be common ones |
| 23:21:38 | Araq | vbtt: it helps to build component systems but you need to ask zahary for the details |
| 23:22:23 | Demos | I wonder what Zahary's definition of component-systems is... everyone seems to have a different definition :D |
| 23:23:37 | discoloda | OO has many different definitions as well |
| 23:23:45 | Demos | this is true |
| 23:24:16 | Demos | that said the definition you are using depends more on your language than the defintion of componet systems does |
| 23:24:40 | Demos | like the defintion of "Object" is fixed for a given language |
| 23:25:26 | Demos | I had an idea for a game engine with a somewhat novel design, but I got destracted by Visual Studio and toying with a shader DSL |
| 23:25:42 | discoloda | what part is novel? |
| 23:26:30 | Araq | discoloda: the best definition of OO is that from Cook, http://www.cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsADT90.pdf |
| 23:27:36 | Demos | the idea was to ditch the idea of a "scene" and just have parts of a scene that store specific types. There would be some kind of "Scene Part" data structure and when you wanted to define a compoent type you would make a global scene part the held that component |
| 23:29:06 | Demos | you end up avoiding the need for any kind of type erasure |
| 23:29:16 | Demos | I think |
| 23:31:19 | vbtt | Araq: another suggestion - for 1.0, pick one broad area (server development or games or embedded) and target that, while not precluding future application to other areas. |
| 23:31:25 | discoloda | ive made a little ECS (well two, one C and another C++11), it basically at runtime constructs a table where rows are entities and columns are components. and has systems that run a function over entities that have components it wants. |
| 23:31:31 | vbtt | and by that i mean pick server development :) |
| 23:31:44 | Araq | yeah I picked game development ... |
| 23:32:06 | Araq | so we have a realtime GC, lots of meta programming goodness and nobody with money |
| 23:32:17 | Araq | smart move. |
| 23:32:28 | Araq | ;-) |
| 23:32:34 | vbtt | ahah |
| 23:34:05 | vbtt | money will be hard unless you really capture critical mass. |
| 23:34:12 | vbtt | doesn't matter which area you pick. |
| 23:34:25 | Demos | discoloda: yeah, that is essentially what I would do. But the trick is that I do NOT need to erase the type of the components, which is super nice |
| 23:34:39 | vbtt | or you could build a product/library in nimrod and sell support for that. |
| 23:35:18 | discoloda | https://github.com/discoloda/DianaCPP11 not sure if does what you want |
| 23:38:27 | Araq | vbtt: I'm playing with a .gpu pragma that compiles a subset of nimrod for you GPU. helps to win the rather annoying array manipulation benchmarks |
| 23:40:09 | Demos | neat! I was playing with that idea a few days ago before I realized that I did not know how to write macros. How does it deal with binding data to the pipeline? |
| 23:40:15 | EXetoC | Araq: I can't figure out how to determine if something is an array, let alone traverse it |
| 23:40:57 | Araq | EXetoC: good, so you can't blame nimrod's db_postgres.nim |
| 23:41:27 | discoloda | does Nimrod have a function to visit AST nodes and transform them if they satisfy a predicate? |
| 23:41:47 | Araq | Demos: macros can't really do that for now because they can't peak into a proc's implementation |
| 23:42:16 | Araq | (what do you mean "getImpl is planned for 0.9.4"?) |
| 23:42:38 | Demos | I thought pragmas could take a whole proc, and I was working with a stmt macro since I wanted to be able to specify uniforms and then a proc in the same block |
| 23:43:03 | Araq | Demos: yeah that works but is more limited than what I have in mind |
| 23:43:45 | Araq | discoloda: macros can do that |
| 23:43:48 | Demos | yeah, I was going for essentially the same primitives as HLSL or GLSL but without all the waffleing around with data layouts and types |
| 23:44:56 | Demos | being able to just write a shader and get all the glue written for free is super appealing |
| 23:45:01 | EXetoC | Araq: :o |
| 23:45:07 | discoloda | Araq: sure, you can do that to everything but what if you only want to do it to procs with a certain pragma? |
| 23:45:35 | vbtt | Araq: sounds cool, but game dev is not area. |
| 23:45:47 | Araq | discoloda: then you use a pragma macro? |
| 23:46:04 | Araq | proc p {.m.} is tranformed into |
| 23:46:07 | Araq | m: |
| 23:46:11 | Araq | proc p |
| 23:46:26 | Araq | no need for any special logic, discoloda |
| 23:46:33 | Demos | so pragma macros can peak into implementations right? Do the problems come when you want to allow proc calls in GPU compiled code? |
| 23:46:40 | Demos | ofc they would need to be inlines |
| 23:46:43 | discoloda | can you limit macros and templates to that scope though? |
| 23:46:43 | Demos | *inlined |
| 23:47:01 | Araq | discoloda: no, what's the point? |
| 23:47:08 | Araq | Demos: yeah that's the problem |
| 23:47:32 | Demos | allright |
| 23:47:47 | Araq | "getImpl" is the missing part for that to work, Demos |
| 23:47:54 | Demos | how are you dealing with the fact that you need to pass in both uniform and per-element (vertex) data? |
| 23:47:57 | Demos | right |
| 23:48:36 | Araq | Demos: not sure I understand |
| 23:48:44 | Araq | please elaborate |
| 23:50:33 | Demos | like I have a gpu program proc doSomeBadassArrayStuff(a: openarray[int]): openarray[int] {.gpu.} that does some GPU work on each element in the array a. Suppose for each run of the proc I need some data constant to that run. For graphics this would be stuff like transform matrices, light information, material information, and so on. |
| 23:51:22 | Demos | In addition you need to be able to figure out a syntax to bind together different stages of the pipeline if you want to target graphics and not openGL style compute |
| 23:51:57 | Demos | *openGL style compute |
| 23:52:03 | Demos | *openCL style compute |
| 23:52:08 | Demos | dem fingers |
| 23:54:53 | Araq | no idea what you mean, you access the constant and retrieve its implementation |
| 23:55:38 | Araq | like [[1,2,3],[4,5,6],[7,8,9]] and compile that to opencl or whatever |
| 23:56:55 | discoloda | Araq: i was trying to figure out if there was a way to do something like .gpu without compiler changes |
| 23:57:51 | discoloda | Araq: i guess making the content of a proc/block a DSL |
| 23:57:54 | EXetoC | Araq: there's row_to_json |
| 23:58:18 | Araq | EXetoC: interesting |
| 23:58:21 | EXetoC | but how do you extract arrays for example? surely there's a decent way to do that, other than parsing it yourself |