| 00:00:57 | EXetoC | do you ever return arrays? |
| 00:01:10 | Demos | There are quite a lot of times when you want to have a function like that run with different constants each run, and would rather not pass them in each time. I guess a plain old structure would work OK |
| 00:02:14 | * | easy_muffin joined #nimrod |
| 00:02:37 | Araq | Demos: you can do a lot with pragmas |
| 00:04:24 | Araq | but it looks like you simply want var data {.gpu.}: array |
| 00:04:46 | Araq | and then access 'data' in your gpu proc |
| 00:09:32 | Demos | yeah, that works, although I spose it would not be an array |
| 00:10:05 | Demos | anyhow are you targeting shading languages or compute languages? |
| 00:10:26 | * | Archaeologist joined #nimrod |
| 00:10:47 | * | Archaeologist left #nimrod ("I'm a happy Miranda IM user! Get it here: http://miranda-im.org") |
| 00:12:00 | Araq | opencl |
| 00:20:39 | Araq | good night |
| 00:24:18 | * | easy_muffin quit () |
| 00:24:38 | * | brson joined #nimrod |
| 00:28:32 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 00:31:43 | * | Demos quit (Ping timeout: 272 seconds) |
| 00:33:19 | * | Demos joined #nimrod |
| 00:35:02 | * | xenagi joined #nimrod |
| 00:42:13 | * | vbtt quit (Quit: Page closed) |
| 00:48:57 | * | brson quit (Remote host closed the connection) |
| 00:49:12 | * | brson joined #nimrod |
| 01:06:21 | * | EXetoC quit (Quit: WeeChat 0.4.2) |
| 01:53:25 | * | brson quit (Ping timeout: 272 seconds) |
| 02:09:29 | * | LordAndrew joined #nimrod |
| 02:14:46 | * | Icefoz joined #nimrod |
| 02:15:29 | LordAndrew | evenin' |
| 02:16:50 | Varriount | Hi LordAndrew |
| 02:17:30 | Varriount | I'm not gonna be on much tonight - I have an english essay to write, among other things. |
| 02:21:48 | LordAndrew | ouch |
| 02:22:35 | Demos | At least you don't have a whole math assignment that you should really have done more of on the weekend.... |
| 02:30:46 | LordAndrew | Hmm. |
| 02:32:12 | LordAndrew | https://gist.github.com/Lordovos/8552530 |
| 02:33:20 | * | DAddYE quit (Remote host closed the connection) |
| 02:33:35 | LordAndrew | ...err. Whoops. There's something wrong with some of that. |
| 02:54:49 | * | Icefoz quit (Ping timeout: 252 seconds) |
| 03:09:36 | * | Icefoz joined #nimrod |
| 03:36:27 | * | Demos quit (Ping timeout: 260 seconds) |
| 03:36:28 | * | DAddYE_ joined #nimrod |
| 03:36:39 | * | DAddYE_ quit (Remote host closed the connection) |
| 03:36:46 | * | DAddYE_ joined #nimrod |
| 03:40:27 | * | Demos joined #nimrod |
| 04:10:01 | * | psquid quit (Ping timeout: 246 seconds) |
| 04:18:05 | * | Icefoz quit (Quit: Lost terminal) |
| 04:18:22 | * | psquid joined #nimrod |
| 04:27:26 | * | dmac joined #nimrod |
| 04:28:18 | * | dmac quit (Client Quit) |
| 04:29:07 | * | Demos quit (Ping timeout: 272 seconds) |
| 05:03:13 | * | Demos joined #nimrod |
| 05:26:58 | * | xenagi quit (Remote host closed the connection) |
| 05:33:27 | * | LordAndrew quit (Quit: Page closed) |
| 05:34:24 | * | LordAndrew joined #nimrod |
| 05:38:08 | * | LordAndrew quit (Client Quit) |
| 05:41:57 | * | LordAndrew joined #nimrod |
| 05:42:55 | * | LordAndrew left #nimrod (#nimrod) |
| 05:43:54 | * | LordAndrew joined #nimrod |
| 05:46:00 | * | brson joined #nimrod |
| 06:22:32 | * | ddl_smurf joined #nimrod |
| 06:46:59 | * | shodan45 quit (Ping timeout: 240 seconds) |
| 07:19:23 | * | Demos quit (Read error: Connection reset by peer) |
| 07:45:07 | * | LordAndrew quit (Quit: Out.) |
| 07:51:47 | * | BitPuffin joined #nimrod |
| 08:30:53 | * | odc joined #nimrod |
| 08:33:10 | * | DAddYE_ quit () |
| 08:34:40 | * | brson quit (Quit: leaving) |
| 08:48:22 | * | Araq_ joined #nimrod |
| 09:00:47 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]) |
| 09:22:05 | * | Atheist joined #nimrod |
| 09:22:27 | * | Atheist is now known as Guest43493 |
| 09:22:58 | * | Guest43493 quit (Read error: Connection reset by peer) |
| 09:32:14 | * | CarpNet joined #nimrod |
| 09:36:19 | * | BitPuffin quit (Ping timeout: 260 seconds) |
| 09:42:42 | * | noam quit (Read error: Connection reset by peer) |
| 09:43:09 | * | noam joined #nimrod |
| 10:24:51 | * | easy_muffin joined #nimrod |
| 10:39:01 | * | Araq_ joined #nimrod |
| 10:39:40 | bbodi | Hi all! How can I convert a fixed size char array to a string? |
| 11:06:16 | Araq_ | $ |
| 11:06:27 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]) |
| 11:08:12 | Araq | bbodi: toString is $ in nimrod |
| 11:15:46 | bbodi | Hi Araq! Thank you. |
| 11:21:57 | * | BitPuffin joined #nimrod |
| 11:23:39 | * | faassen joined #nimrod |
| 11:48:30 | * | EXetoC joined #nimrod |
| 12:34:46 | dom96 | You guys got any optimisation tips for https://github.com/dom96/ParticleBench/blob/master/N.nim ? |
| 12:43:51 | * | easy_muffin quit () |
| 12:50:12 | BitPuffin | dom96: ping me later this evening and I'll have a look |
| 12:51:13 | dom96 | ok |
| 13:25:22 | Araq | dom96: get rid of the 'bis' field |
| 13:25:44 | Araq | instead of setting it to false, swap the invalid point with the last point |
| 13:26:02 | * | xenagi joined #nimrod |
| 13:26:05 | Araq | no need for the bis check in renderPts this way |
| 13:27:00 | Araq | cleanupPtPool() is not necessary then anymore |
| 13:29:58 | Araq | not sure if it improves anything |
| 13:30:10 | Araq | are you allowed to use the || iterator, dom96 ? |
| 13:30:21 | dom96 | no idea |
| 13:31:32 | dom96 | we're pretty close to C performance anyway |
| 13:31:54 | dom96 | The Go implementation doesn't use goroutines |
| 13:31:59 | dom96 | so it would be unfair to use || |
| 13:32:31 | Araq | pretty close ain't good enough, disassemble both and see what's different :P |
| 13:32:45 | Araq | I'm tired of measuring things when you can look at the assembler instead |
| 13:32:51 | dom96 | I have better things to do. |
| 13:32:56 | Araq | so do I |
| 13:33:14 | BitPuffin | now fight |
| 13:33:26 | dom96 | We should get good PR anyway |
| 13:37:31 | Araq | pass more stuff via parameters btw |
| 13:37:58 | dom96 | I think I will just keep it as it is. |
| 13:38:06 | dom96 | All the other implementations are written like this. |
| 13:38:35 | Araq | ensure gcc uses the AVX instructions |
| 13:39:35 | dom96 | how? |
| 13:39:46 | Araq | -march or something like that |
| 13:40:03 | Araq | also you should at least try an unroll iterator |
| 13:40:20 | Araq | trivial to do in nimrod, pita in D,C++,C :P |
| 13:40:35 | Araq | I will do it later |
| 13:40:44 | dom96 | ok |
| 13:41:09 | BitPuffin | Araq is getting serious |
| 13:41:41 | * | darkf quit (Quit: Leaving) |
| 13:42:47 | dom96 | bbl |
| 13:43:11 | Araq | in fact ... use profile guided optimizations |
| 13:44:49 | BitPuffin | what's that? |
| 13:45:41 | Araq | BitPuffin: C's answer to just-in-time compilation ;-) |
| 13:48:06 | BitPuffin | Araq: Well okay, but what does that mean xD |
| 13:48:16 | EXetoC | optimizations guided by profile? :p |
| 13:48:20 | EXetoC | profiling |
| 13:56:51 | Araq | correction: it's -march=native |
| 13:57:16 | BitPuffin | wut |
| 13:59:57 | BitPuffin | guess it's a GCC flag? |
| 14:00:08 | EXetoC | yes |
| 14:01:03 | BitPuffin | what is it's daddy and what does it do |
| 14:01:07 | BitPuffin | its |
| 14:01:33 | EXetoC | some claim that -march=native enables too much, which results in less performant code |
| 14:02:25 | EXetoC | Araq: when you asked me to implement JSON output, did you mean just a flat schema? |
| 14:03:20 | Araq | EXetoC: not really, I was thinking of supporting postgresql's arrays and its new json data type |
| 14:06:54 | BitPuffin | JSON output?! |
| 14:08:09 | EXetoC | I was thinking about much more complicated stuff, but then again I was thinking about SQL data the wrong way |
| 14:08:14 | EXetoC | BitPuffin: this maybe http://www.postgresql.org/docs/9.3/static/functions-json.html |
| 14:08:26 | BitPuffin | well I know |
| 14:08:33 | BitPuffin | but json output sounds pretty general |
| 14:08:41 | BitPuffin | did you mean json output out of postgres etc or wat |
| 14:14:11 | EXetoC | Araq: of query results? |
| 14:15:05 | Araq | EXetoC: instead of seq[string] == TRow returns JSON everywhere |
| 14:15:57 | BitPuffin | Araq: for all db's? |
| 14:19:24 | EXetoC | I wouldn't know how to make it generic as I haven't used the JSON functionality yet. Should the procs just assume that the columns are JSON strings? |
| 14:21:45 | Araq | no, you need to query the db and find out the datatype |
| 14:22:03 | Araq | but some times like 'datetime' become JSON strings |
| 14:22:08 | Araq | *some types |
| 14:22:19 | Araq | BitPuffin: yes, for all of them |
| 14:22:38 | EXetoC | that was my first approach, but I couldn't find a way to figure out if something was an array |
| 14:23:23 | EXetoC | maybe because it was an array of user-defined types, which returned an arbitrary OID (one which didn't correspond to any built in type) |
| 14:24:44 | BitPuffin | Araq: that would be much better actually |
| 14:24:50 | BitPuffin | sucks to have everything as a string |
| 14:25:22 | Araq | BitPuffin: I like it this way, but I figured I'm a minority |
| 14:27:00 | EXetoC | I only complained because I had forgotten the little I had learned about SQL |
| 14:27:02 | BitPuffin | Araq: well I work around it anyway by modeling my objects as nimrod objects so it's not a huge deal |
| 14:27:08 | BitPuffin | just parseInt and stuff like that |
| 14:27:18 | EXetoC | but returning arrays in individual columns isn't very conventional, right? |
| 14:27:23 | BitPuffin | in fact json might complicate that a bit now that I think about it |
| 14:30:53 | Araq | EXetoC: right, that's an extension to the relational model |
| 14:31:11 | Araq | according to the relational model it's even "wrong" ;-) |
| 14:41:07 | BitPuffin | blown: mind |
| 14:41:11 | BitPuffin | no but xD |
| 14:43:38 | EXetoC | yeah. it might reduce the amount of necessary queries, and I partly had performance in mind, but I suspect that the caching engines are well optimized for querying the same row several times in a row |
| 14:44:11 | Araq | EXetoC: sounds more like you need to learn about joins |
| 14:47:51 | BitPuffin | join the dark side |
| 14:54:18 | EXetoC | I don't think it's relevant, but "the same row" is probably not what I meant |
| 14:55:00 | EXetoC | unless maybe everything is in the same table (with the help of arrays), but it's not relational then like you said |
| 15:01:37 | EXetoC | BitPuffin: what blew your mind? you also an SQL nub? :p |
| 15:03:20 | BitPuffin | EXetoC: nah I can use SQL |
| 15:03:24 | BitPuffin | fairly decently |
| 15:04:13 | * | Demos joined #nimrod |
| 15:04:39 | EXetoC | ok |
| 15:06:43 | EXetoC | Araq: some people don't like seq[string] for query results? I don't know what else makes sense now that I'm less clueless |
| 15:07:17 | OrionPK | shouldnt it be a table structure of some sort |
| 15:07:23 | OrionPK | rows & columns |
| 15:08:10 | OrionPK | SQL queries should result in a reader object of some sort, where you read 1 row at a time, and rows have multiple cells |
| 15:08:23 | BitPuffin | obviously not possible, but a tuple containing the fields would be amazingly awesome |
| 15:08:58 | OrionPK | why isnt that possible, bitpuffin? |
| 15:09:20 | OrionPK | you just have to make your query object at compile time |
| 15:09:24 | BitPuffin | because you can't know the names of the fields at compile time |
| 15:09:43 | BitPuffin | yeah well that's what I do ish |
| 15:10:06 | OrionPK | doable w/ macro stuff |
| 15:10:23 | BitPuffin | macros can't know what doesn't exist yet |
| 15:10:49 | OrionPK | dont know what you mean |
| 15:10:56 | EXetoC | you can validate at run-time and throw if there's a mismatch |
| 15:11:10 | BitPuffin | well I mean that a macro can't know about data that is outside of the program |
| 15:11:20 | OrionPK | why would it need to |
| 15:11:26 | BitPuffin | so it can't figure out that a database table has these rows or something |
| 15:11:33 | OrionPK | it would assume it does |
| 15:11:34 | BitPuffin | I guess you could do a delegator thing instead |
| 15:11:55 | OrionPK | a database schema should be fairly static, and probably change less often than your code |
| 15:12:11 | OrionPK | you should get predictable schema for any given query |
| 15:12:22 | OrionPK | with the columns you ask for |
| 15:12:38 | EXetoC | type validation can be done for built in SQL types anyway. I'll mess about with that next week or something |
| 15:12:40 | OrionPK | if a column doesnt exist, thats an error |
| 15:12:49 | BitPuffin | well I just mean knowing fiedl names |
| 15:12:59 | OrionPK | you tell it what field names in the query |
| 15:13:05 | OrionPK | field names = column names |
| 15:13:30 | BitPuffin | true |
| 15:13:31 | OrionPK | query(myQuery): "SELECT Field1, Field2, Field3 FROM TableA" |
| 15:13:51 | BitPuffin | then it could parse the sql to figure out what it is |
| 15:13:52 | OrionPK | myQuery gets compiled into a type and some procs |
| 15:14:29 | EXetoC | or query using libpq for example, which is much easier |
| 15:14:53 | EXetoC | well, that'd be at run-time then |
| 15:19:03 | EXetoC | or would it? :p |
| 15:19:10 | * | [1]Endy joined #nimrod |
| 15:19:31 | BitPuffin | EXetoC: ye |
| 15:28:37 | EXetoC | it depends on the VM |
| 15:29:32 | EXetoC | Araq: didn't you say that you were able to execute SDL code at compile-time? what is not allowed? database access for example |
| 15:48:19 | * | easy_muffin joined #nimrod |
| 16:01:54 | * | easy_muffin quit () |
| 16:08:42 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 16:23:17 | * | easy_muffin joined #nimrod |
| 16:28:55 | * | [2]Endy joined #nimrod |
| 16:32:19 | * | [1]Endy quit (Ping timeout: 252 seconds) |
| 16:48:03 | * | aftersha_ joined #nimrod |
| 16:52:21 | * | Mat3 joined #nimrod |
| 16:52:23 | Mat3 | hi |
| 16:54:15 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 16:56:31 | * | Demos quit (Ping timeout: 246 seconds) |
| 16:57:30 | * | BitPuffin joined #nimrod |
| 17:00:19 | * | aftersha_ joined #nimrod |
| 17:05:42 | * | Demos joined #nimrod |
| 17:20:28 | * | faassen left #nimrod (#nimrod) |
| 17:23:32 | BitPuffin | EXetoC: hmm, I pass forwardCompat = true but still get this: |
| 17:23:41 | BitPuffin | let glv = initGL_API(glv33, forwardCompat = true) |
| 17:23:45 | BitPuffin | wait |
| 17:23:47 | BitPuffin | lol |
| 17:23:49 | BitPuffin | hang on xD |
| 17:24:01 | BitPuffin | Error: unhandled exception: NSGL: The targeted version of OS X only supports OpenGL 3.2 and later versions if they use the core profile [EGLFW] |
| 17:24:12 | BitPuffin | oh wait |
| 17:24:18 | BitPuffin | read the error message IdiotPuffin |
| 17:24:49 | BitPuffin | EXetoC: what's the way to make it core? |
| 17:26:06 | EXetoC | BitPuffin: by setting profile |
| 17:26:23 | EXetoC | to glpCore |
| 17:26:39 | BitPuffin | EXetoC: well yeah but hao |
| 17:27:13 | EXetoC | GL_API = initGL_API(version = bla, profile = glpCore)? |
| 17:28:01 | BitPuffin | EXetoC: yay |
| 17:28:16 | BitPuffin | EXetoC: yeah I figured out right before I read what you said xD |
| 17:28:52 | EXetoC | :> |
| 17:29:00 | EXetoC | default args that can be named<3 |
| 17:32:32 | EXetoC | BitPuffin: is your nimrod build recent? |
| 17:41:42 | * | xenagi quit (Quit: Leaving) |
| 17:42:18 | BitPuffin | EXetoC: think so yeah |
| 17:42:40 | BitPuffin | can't remember arguments getting skipped working before |
| 17:42:43 | BitPuffin | maybe they did |
| 17:52:26 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 17:53:23 | * | BitPuffin joined #nimrod |
| 17:54:01 | EXetoC | BitPuffin: what do you mean? these are default arguments |
| 17:54:27 | BitPuffin | EXetoC: well I mean skipping some parameters that already have a default value |
| 17:55:32 | BitPuffin | If I'm not gonna inherit, is there any point in making it an object rather than a tuple? |
| 17:55:55 | EXetoC | yes, depending on if you want to encapsulate anything |
| 17:56:10 | EXetoC | BitPuffin: are you referring to the order of the parameters? |
| 17:56:23 | EXetoC | either way, I'm pretty sure it has worked for a long time |
| 17:56:46 | EXetoC | if you can name them at the call site then it shouldn't matter |
| 17:57:20 | BitPuffin | EXetoC: yes |
| 17:57:24 | BitPuffin | EXetoC: what do you mean |
| 17:57:29 | BitPuffin | EXetoC: oh you mean method for example? |
| 17:57:37 | BitPuffin | I haven't used method once tbh |
| 17:58:20 | EXetoC | the first thing I said was about objects and the following statements are related to default args |
| 17:59:02 | EXetoC | BitPuffin: you don't have to inherit when using objects, so encapsulation of individual fields is another use case |
| 17:59:20 | * | DAddYE joined #nimrod |
| 17:59:26 | EXetoC | you asked if inheritance was the only use of objects |
| 18:00:11 | EXetoC | I guess another use is making constructions more verbose in that the field names have to be specified, but that's often hidden behind an init/new proc anyway |
| 18:00:12 | BitPuffin | EXetoC: well okay and if I don't want to hide any variables is the stuff |
| 18:00:35 | BitPuffin | EXetoC: I guess the question is, if I use only stuff that tuples can already do, isn't it better to just use a tuple? |
| 18:02:19 | * | Demos quit (Ping timeout: 272 seconds) |
| 18:05:26 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 18:08:51 | * | Demos joined #nimrod |
| 18:09:02 | Demos | I see a TNimrodTypeKind type in macros. How can I get my hands on something of that type. Looking at dumpTree I see that type annotations are just idents |
| 18:09:48 | * | bbodi_ joined #nimrod |
| 18:10:16 | * | bbodi quit () |
| 18:10:50 | * | bbodi_ is now known as bbodi |
| 18:12:04 | bbodi | hi all! I saw that parseopt module is deprecated and the new parseopt2 shoud be used insteadf of it. But the compiler modules still use the deprecated parseopt modules. why? |
| 18:12:06 | EXetoC | BitPuffin: not really imo |
| 18:13:35 | EXetoC | bbodi: they haven't had the opportunity to migrate yet I think |
| 18:15:35 | bbodi | I have a working branch where I replaced the module imports to parseopt2.. do you think that it would be valuable to push it up to github? |
| 18:16:47 | BitPuffin | EXetoC: elaboRATE |
| 18:17:15 | dom96 | Dear Windows, why do you hate me? :( |
| 18:17:24 | EXetoC | BitPuffin: -not |
| 18:17:38 | EXetoC | that doesn't make much sense, but you know what I meant :p |
| 18:17:57 | EXetoC | I mean I can't see why not a tuple should be preferred then |
| 18:18:36 | BitPuffin | dom96: only because it sucks |
| 18:18:52 | BitPuffin | EXetoC: good boi |
| 18:18:58 | BitPuffin | EXetoC: so even when nesting? |
| 18:19:20 | EXetoC | bbodi: can't see why not if it behaves the same |
| 18:19:23 | EXetoC | BitPuffin: yeah |
| 18:19:31 | BitPuffin | EXetoC: fair enough |
| 18:20:09 | BitPuffin | I wonder what Araq think |
| 18:21:17 | BitPuffin | there is more syntax in tuple though, guess that's why I did object |
| 18:22:12 | Demos | serious question: Why do we still use that terrabad loop syntax for processing command line args? The interface would be so much simpler if you just said "give me the value of this arg" and the library did so |
| 18:22:32 | Demos | heck I wrote a library that did that in c++ and it was nice |
| 18:22:39 | EXetoC | BitPuffin: when? it's anonymous and field names can be omitted |
| 18:22:44 | Demos | is it just getopt? |
| 18:22:46 | EXetoC | and the type can be aliases |
| 18:23:40 | EXetoC | Demos: ya https://github.com/docopt/docopt |
| 18:23:58 | BitPuffin | EXetoC: well I mean that you can't use indentation syntax |
| 18:24:00 | EXetoC | *aliased |
| 18:24:03 | BitPuffin | you do[] |
| 18:24:16 | EXetoC | you can |
| 18:24:26 | Demos | EXetoC: neat-o |
| 18:24:31 | EXetoC | someone enlightened me to that fact not long ago |
| 18:26:07 | EXetoC | BitPuffin: or maybe you mean when nesting. I haven't tried that |
| 18:27:07 | Demos | ugh another compiler crash while doing macros.... |
| 18:27:49 | BitPuffin | EXetoC: you can do indentation syntax instead of [] with tuples |
| 18:27:51 | BitPuffin | ? |
| 18:28:15 | EXetoC | BitPuffin: yes http://build.nimrod-lang.org/docs/manual.html#tuples-and-object-types |
| 18:29:02 | EXetoC | later |
| 18:29:08 | Mat3 | Demos: What do you want to do ? |
| 18:29:10 | BitPuffin | EXetoC: motherfucker |
| 18:29:12 | BitPuffin | that's nice |
| 18:29:37 | Demos | take an AST and generate a string, also known as compileing the ast |
| 18:30:21 | BitPuffin | even works with nesting |
| 18:30:23 | BitPuffin | suhweet |
| 18:30:25 | Demos | getting Internal Error: GetUniqueType |
| 18:32:43 | Mat3 | I'm sorry, ask Araq about this type of errors |
| 18:32:51 | * | CarpNet quit (Quit: Leaving) |
| 18:33:06 | Demos | yeah, trying to pair it down to a minimal test case |
| 18:33:14 | Demos | but macros are supah buggy |
| 18:33:28 | EXetoC | someone got that yesterday or something. dunno if he reported it |
| 18:34:19 | Demos | hm, I got a segfault on using the quasi-quote stuff, and reported it |
| 18:34:24 | EXetoC | Demos: dont try too hard. he mostly just care if it compiles |
| 18:34:42 | Demos | hm? |
| 18:35:19 | EXetoC | to minimize the code |
| 18:36:34 | Demos | yeah, well I may learn something in the process of a minimal test case :D |
| 18:36:55 | EXetoC | that should be documented somewhere, because I think that some people are used to devs who refuse to examine anything big |
| 18:41:53 | * | brson joined #nimrod |
| 18:42:41 | Mat3 | Demos: Please take a breath and ask yourself if the use of macros is really 1. necessary, 2. efficient and 3. an elegant way of implementation for your problem |
| 18:43:01 | Demos | I am pretty sure it is |
| 18:43:19 | OrionPK | macros are always the answer |
| 18:43:37 | EXetoC | indeed |
| 18:43:48 | Mat3 | yeah, and BASIC is the solution, I know ;) |
| 18:43:58 | Demos | can we not do the whole "use restraint with macros" now. I am trying to learn to use them and am fiddleing around with a macro that generates GLSL from a nimrod proc. I will probably never finish this macro but I will learn something |
| 18:44:57 | EXetoC | I'm not sure why it's useful, but interesting nevertheless |
| 18:45:22 | OrionPK | why wouldnt you compile to GLSL at compiletime if you could? |
| 18:45:25 | OrionPK | silly mat3 |
| 18:45:38 | Mat3 | OrionPK: No, same logic |
| 18:45:39 | EXetoC | compile even? |
| 18:45:51 | EXetoC | oh you mean stringify |
| 18:46:16 | EXetoC | just guessing now |
| 18:47:34 | OrionPK | my logic is; if it doesnt need to change during runtime, and it can just as easily be done at compile time, do it at compile time |
| 18:48:11 | Demos | OrionPK: the ability to compile GLSL to a blob is a very new extension that is not widely supported |
| 18:48:15 | EXetoC | you want to generate binaries at compile-time? |
| 18:48:26 | EXetoC | right |
| 18:48:49 | OrionPK | demos not really talking about compiling it down to binary |
| 18:49:04 | OrionPK | just turning it into a GLSL string |
| 18:49:42 | OrionPK | you wouldnt want to compile to a blob because diff hardware might do it differently, i would think |
| 18:49:46 | EXetoC | you don't like inline strings that aren't highlighted? |
| 18:50:15 | OrionPK | who says they're not highlighted https://dl.dropboxusercontent.com/u/417554/sublanguages.png |
| 18:50:15 | EXetoC | so you want to go from nimrod to GLSL code? I can't think of anything else really |
| 18:50:26 | OrionPK | thats what demos wants |
| 18:51:00 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 18:51:32 | Demos | if I were doing HLSL I could compile to a blob by staticExecin FXC, and put that blob into a const var. |
| 18:51:39 | Demos | strings and binaries are the same here |
| 18:52:15 | EXetoC | how does that work? is it actually implemented? |
| 18:53:30 | EXetoC | that was directed towards OrionPK |
| 18:53:37 | OrionPK | does what work |
| 18:53:48 | OrionPK | the syntax highlighting? |
| 18:53:49 | EXetoC | the highlighting |
| 18:53:59 | OrionPK | yes, w/ the sublime text plugin |
| 18:54:11 | OrionPK | and my template/annotations module |
| 18:54:21 | * | BitPuffin joined #nimrod |
| 18:54:34 | EXetoC | ok |
| 18:55:11 | Mat3 | OrionPK: Well, some time code-depth matters for example, in some ways just defining constants will do the same without less effort - it's depends on the problem |
| 18:58:25 | * | Demos quit (Ping timeout: 272 seconds) |
| 18:58:52 | * | OrionPK quit (Remote host closed the connection) |
| 18:59:00 | * | Mat3 thinking in most cases computing static expressions at runtime isn't relevant in terms of both code-size and performance |
| 18:59:50 | Mat3 | anyhow off topic |
| 19:00:29 | * | OrionPK joined #nimrod |
| 19:03:40 | * | brson quit (Ping timeout: 265 seconds) |
| 19:04:07 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 19:04:52 | * | Mat3 is now known as Mat3-work |
| 19:05:32 | * | LordAndrew joined #nimrod |
| 19:10:27 | Mat3-work | ^with |
| 19:27:55 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 19:30:57 | Varriount | Good evening! |
| 19:32:43 | * | tdc joined #nimrod |
| 19:33:03 | LordAndrew | Good afternoon. :) |
| 19:33:11 | reactormonk | Good morning |
| 19:34:43 | * | filwit joined #nimrod |
| 19:35:29 | filwit | heya folks |
| 19:37:10 | Varriount | A wild filwit appeared! |
| 19:37:26 | * | Varriount throws a great ball at filwit! |
| 19:38:23 | filwit | filwit uses run |
| 19:38:32 | filwit | i never played pokemon.. |
| 19:38:58 | * | Trixar_za throws a Master Ball at Varriount |
| 19:39:01 | filwit | but i have pretty much all day to work on Nimrod, so imma try and get a model from Blender rendering :) |
| 19:39:20 | * | Varriount eats the Master Ball |
| 19:39:42 | Varriount | Heya Trixar_za, haven't seen you in here before. |
| 19:40:18 | Trixar_za | Oh, I idle a lot and make nonsense comments when nobody is watching |
| 19:40:18 | * | nueva joined #nimrod |
| 19:40:32 | Trixar_za | Nice to see that the channel has grown in the last few years |
| 19:40:55 | filwit | btw, someone on the forum wanted to know how to check for byte alignment of uint64 types in Nimrod. Anyone know the answer to that? |
| 19:40:58 | Trixar_za | I still remember when there was only like 13 of us :P |
| 19:41:47 | Varriount | 'byte alignment' in what context? |
| 19:41:54 | nueva | hi. can nimrod compiler output generated [C/C++] files' names (without generating files)? |
| 19:41:57 | Araq | hi nueva welcome |
| 19:42:23 | filwit | idk exactly. I didn't fully understand the question myself. Here's the forum post tho: http://forum.nimrod-lang.org/t/320/2 |
| 19:42:29 | filwit | ^ Varriount |
| 19:42:34 | nueva | i want to pass names of generated files to external build system |
| 19:44:24 | reactormonk | nueva, unlikely. There's more than one file generated usually |
| 19:44:25 | OrionPK | isnt it just folder_file.c |
| 19:44:26 | filwit | aren't the generated C files the same names as the Nimrod modules? |
| 19:45:19 | reactormonk | nueva, any problem with just reading the files back in? |
| 19:46:53 | nueva | reactormonk: build system requires generated files' names long before invoking compiler for real "compiling" to make build dependencies DAG |
| 19:48:19 | Trixar_za | What does DAG mean? |
| 19:48:50 | nueva | Trixar_za: direct acyclic graph, I suppose. |
| 19:49:37 | Trixar_za | Ah, the fourth one on the list. It was that or Data Analyst Group, but that didn't make sense. |
| 19:49:52 | LordAndrew | Is anyone here familiar with PEG ("Parsing expression grammar")? I was looking to do some regular expressions, but the re module suggests using the pegs module instead. |
| 19:50:07 | LordAndrew | Except, I can't... find any sort of information or tutorials on how to even use PEG. |
| 19:50:44 | Varriount | LordAndrew: The peg module? |
| 19:50:47 | nueva | Trixar_za: maybe you was right, because DAG isn't deciphered anything in manual :) |
| 19:51:13 | Trixar_za | http://nimrod-lang.org/pegs.html |
| 19:51:17 | Varriount | LordAndrew: The peg module has a pretty good explanation of PEG's and how to use them. |
| 19:51:43 | * | Mordecai joined #nimrod |
| 19:52:06 | Varriount | Hi psquid |
| 19:52:22 | filwit | dom96: 61 users? |
| 19:52:25 | nueva | i think compiler can recursively scan main module dependencies, generate just output [intermediate source] file names and print them |
| 19:52:36 | filwit | dom96: what's the record at these days? |
| 19:52:46 | Varriount | filwit: 62/63 |
| 19:52:54 | filwit | damn, so close |
| 19:53:34 | * | BitPuffin joined #nimrod |
| 19:53:38 | * | psquid quit (Disconnected by services) |
| 19:53:42 | * | Mordecai is now known as psquid |
| 19:53:49 | dom96 | filwit: 63 |
| 19:53:51 | nueva | but it doesn't have similar option ATM. so the only way is to change compiler by myself? or am I missing something? |
| 19:54:38 | * | aftersha_ joined #nimrod |
| 19:54:44 | * | vbtt joined #nimrod |
| 19:54:47 | filwit | nueva, you'll probably have to ask Araq or Zahary, but they're probably busy at the moment |
| 19:55:03 | Varriount | nueva: I believe that there might be ways to go around such things at the moment |
| 19:55:26 | Varriount | But nothing precisely as what you want. |
| 19:55:36 | Araq | nueva: you can make the compiler generate a build script |
| 19:55:44 | Araq | and extract the C filenames from that |
| 19:56:07 | nueva | OrionPK: yes it's pretty easy to find module name, but it's hard to find module's dependencies name (including standard library ones) without parsing sources. so I think compiler can do that. |
| 19:56:22 | OrionPK | this is true |
| 19:56:37 | * | Lordovos joined #nimrod |
| 19:56:42 | nueva | Araq: fine idea. I'll try it now. |
| 19:56:55 | Araq | there is also the option --genmapping |
| 19:56:58 | filwit | wait.. what about Nimrod genDepend ? |
| 19:57:07 | Varriount | nueva: You could also invoke the nimrod compiler with genDepend |
| 19:57:13 | Araq | the compiler then generates a "mapping file" that also has the C files in it |
| 19:57:14 | Lordovos | "Disconnected (Connection reset by peer)" what the heck does this mean |
| 19:57:38 | * | vendethiel joined #nimrod |
| 19:57:54 | Trixar_za | The server killed your connection for the client not responding fast enough to the ping ping event |
| 19:57:57 | filwit | dom96: 65 users!!! |
| 19:58:06 | filwit | PARTY TIME |
| 19:58:11 | dom96 | Trixar_za: no, that's ping timeout. |
| 19:58:13 | Trixar_za | s/for/because/ |
| 19:58:31 | Trixar_za | Oh, then the server just killed your connection |
| 19:58:46 | Varriount | LordAndrew: http://stackoverflow.com/questions/1434451/what-does-connection-reset-by-peer-mean |
| 19:58:58 | Araq | Varriount, filwit gendepend doesn't generate this information |
| 19:59:03 | dom96 | Lordovos: Something went wrong with your connection or Freenode's internet connection. |
| 19:59:09 | Trixar_za | Efneth as a whole list on it |
| 19:59:14 | Trixar_za | EFNet* |
| 19:59:21 | Araq | but niminst itself uses --genmapping so that's the proper way to do it |
| 19:59:55 | Varriount | Araq: You would just have to transform the actual file names into the c file names |
| 20:00:08 | Araq | the compiler then generates mapping.txt which is in .ini file format |
| 20:00:13 | * | LordAndrew quit (Ping timeout: 272 seconds) |
| 20:00:25 | Araq | Varriount: right ... "just" |
| 20:00:31 | Varriount | :3 |
| 20:00:38 | * | Lordovos is now known as LordAndrew |
| 20:00:40 | Araq | even though it's not that simple and might change any time |
| 20:01:17 | Trixar_za | Either way, it's something that happens on IRC, so don't worry about it |
| 20:01:19 | reactormonk | nueva, I'd make nimrod create a compile script and invoke that from your build system |
| 20:01:50 | LordAndrew | Trixar_za: Alrighty. |
| 20:02:14 | * | Mat3-work is now known as Mat3 |
| 20:02:28 | Varriount | LordAndrew: FYI, if your nick is registered with Freenode, you can use '/ns ghost <name>' (if you're identified) or '/ns ghost <name> <passord>' if you're not. |
| 20:02:33 | Trixar_za | Speaking of IRC - I have a network to break and fix |
| 20:02:33 | Trixar_za | :P |
| 20:03:07 | Varriount | If it isn't regsitered, I highly recommend registering it before someone takes it. Plus, then people can send you memos. |
| 20:03:15 | Varriount | *registered |
| 20:05:52 | xtagon | What does "internal error: too implement nkObjDownConv |
| 20:05:52 | xtagon | " mean? |
| 20:06:28 | xtagon | I've got a proc, and if you use it to assign a var it works, but it won't work for a const. |
| 20:06:46 | xtagon | https://gist.github.com/xtagon/167f358d8c0abc20d07f |
| 20:07:41 | Varriount | xtagon: Sounds like something that is planned to be implemented, but isn't actually implemented yet. |
| 20:08:46 | Varriount | 'nk |
| 20:08:48 | Trixar_za | Is Japan part of the EU? |
| 20:09:05 | Varriount | 'nk' usually means 'node kind', as in an ast node or something |
| 20:10:03 | Varriount | xtagon: What happens if you shift the syntax to 'toSemVer("1.23.4")' |
| 20:10:35 | Araq | xtagon: looks like another vmgen bug to me |
| 20:10:36 | xtagon | Varriount, tried that, no change |
| 20:11:38 | * | aruniiird joined #nimrod |
| 20:11:50 | Araq | hi aruniiird welcome |
| 20:12:28 | Mat3 | hi aruniiird |
| 20:12:34 | Varriount | xtagon: Changing the 'const' to 'let'? |
| 20:12:56 | Araq | xtagon: 'master' should compile it, 'devel' doesn't |
| 20:12:56 | * | zahary joined #nimrod |
| 20:13:06 | xtagon | Varriount, let works fine |
| 20:13:22 | Araq | dom96: 66! |
| 20:13:43 | dom96 | Awesome :D |
| 20:14:15 | zahary | wow, that's big jump. is the dr dobbs article out or something? |
| 20:14:38 | Mat3 | that would be nice |
| 20:14:50 | * | [1]Endy joined #nimrod |
| 20:14:51 | nueva | unfortunately, it looks like genMapping and genScript works only with compile* commands, which is kinda ruins the point. genDepend expects dot tool to be available (though it doesn't fail without it) and doesn't include stdlib modules. genMapping is pretty close to what I need BTW. |
| 20:15:05 | dom96 | I wouldn't call it 'big' yet. |
| 20:16:34 | filwit | 67 now |
| 20:16:42 | filwit | or is one of those redundant? |
| 20:17:00 | filwit | ah, Nimbot doesn't count, gottit |
| 20:17:27 | * | [2]Endy quit (Ping timeout: 260 seconds) |
| 20:18:47 | Araq | nueva: I can't follow, yes you have to compile your nimrod code so the compiler can tell you how the C files are named ... |
| 20:19:09 | dom96 | nah, we count doubles :P |
| 20:19:13 | Araq | how else should it work? |
| 20:19:20 | dom96 | and bots |
| 20:19:32 | Araq | filwit: we consider nimbot a (female) human being ... |
| 20:19:39 | Araq | XD |
| 20:19:39 | filwit | ^ lol |
| 20:19:57 | Trixar_za | Full of problems with a tendency not to tell you what's wrong? Oo |
| 20:20:21 | Varriount | Araq: Should "IRune" in unicode.nim be a native int? Shouldn't it be an int32? |
| 20:20:30 | filwit | well i'm glad i was finally around to see a new record reached |
| 20:20:59 | filwit | by the end of 2014 we'll probably be at 80-90 |
| 20:21:47 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 20:22:52 | dom96 | By the end of 2014 we'll be at 500 |
| 20:23:24 | dom96 | ok, maybe that's over ambitious. |
| 20:23:36 | nueva | Araq: yes, I have to. but in preliminary "compilation" I don't need generated sources' text at all. I only need sources' paths. I know input (main module) and can feed it to build system. but I don't know real outputs to feed to build system so that these outputs will be passed to C compiler. |
| 20:23:40 | dom96 | But 1.0 should be out by the end of 2014 |
| 20:24:03 | * | BitPuffin joined #nimrod |
| 20:24:15 | Araq | Varriount: who cares? unicode code-points are 21bits or something. so what makes int32 more correct than int? |
| 20:24:19 | filwit | hmm... i'll have a limited but functioning game engine out in 2014 too, so you never know |
| 20:24:42 | filwit | we'll have some stuff to advertise and write articles about |
| 20:26:18 | xtagon | filwit, is your game engine Hymn? |
| 20:26:22 | nueva | Araq: I want to use Nimrod compiler only as intermediate files generator. all real work on compiling C sources will be done by other build system. but I don't know exactly which files will be generated. |
| 20:26:34 | filwit | xtagon: that's it's codename, yes |
| 20:26:48 | xtagon | filwit, I'm the guy who e-mailed you the other day asking if it was going to be open source :) |
| 20:27:03 | filwit | ah :) nice to know who you are on the IRC |
| 20:27:08 | EXetoC | dom96: <500 = failure :/ |
| 20:27:39 | Araq | nueva: well you can extract the C filenames once and pretend they are static as long as your nimrod code doesn't import new modules |
| 20:31:06 | nueva | Araq: yeah, it looks like the best way for now. I just thought I've missed some existing option, so decided to ask. |
| 20:32:52 | Araq | nueva: I still don't get it. do you use --compileOnly and then your build system? |
| 20:33:27 | nueva | Araq: yes, exactly |
| 20:33:41 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 20:34:25 | Araq | aha, so you want --genmapping to work with --compileOnly |
| 20:34:39 | Araq | ok, added it to my todo |
| 20:36:34 | nueva | Araq: --genMapping works with --compileOnly. I want option to just scan dependencies of module and then print output file names (without generating/saving files' text). |
| 20:38:08 | * | BitPuffin joined #nimrod |
| 20:38:30 | * | brson joined #nimrod |
| 20:38:38 | nueva | Araq: I mean "_recursively_ scan" and "print _all_ output files's names" |
| 20:39:24 | * | [2]Endy joined #nimrod |
| 20:40:38 | * | brson quit (Client Quit) |
| 20:43:00 | Araq | nueva: ok, so "nimrod check" + --genMapping |
| 20:43:49 | * | [1]Endy quit (Ping timeout: 272 seconds) |
| 20:50:26 | * | io2 joined #nimrod |
| 20:50:41 | nueva | Araq: --genMapping doesn't worh with check command. |
| 20:50:57 | Araq | I know |
| 20:51:05 | Araq | but that's what you want, right? |
| 20:56:00 | * | easy_muffin quit () |
| 21:00:25 | * | [2]Endy quit (Ping timeout: 245 seconds) |
| 21:00:40 | * | brson joined #nimrod |
| 21:00:51 | nueva | Araq: pretty close, but what I really want is http://pastebin.com/GXK61sTt If mapping.txt would be possible to print to stdout and check would be possible to make silently (I don't want errors info) it would be fine too. |
| 21:01:38 | Araq | nueva: awaiting your compiler patch ;-) |
| 21:01:50 | LordAndrew | Hmm. Do the executables produced by compiling .nim code with Nimrod have any sort of external dependencies and/or licensing obligations? |
| 21:02:13 | * | brson quit (Client Quit) |
| 21:02:28 | * | brson joined #nimrod |
| 21:02:40 | Araq | LordAndrew: yeah, if you run the binary in production, you need to pay me $100,000 ;-) |
| 21:03:16 | Araq | --verbosity:2 prints external dependencies |
| 21:03:16 | nueva | Araq: will (possibly) do when generated sources list will grow too much :) |
| 21:03:36 | OrionPK | $100,000? what a steal |
| 21:04:27 | BitPuffin | hmm |
| 21:04:28 | BitPuffin | wtf |
| 21:04:44 | BitPuffin | ] expected: https://gist.github.com/BitPuffin/9ab658d8538f74e4b994 |
| 21:04:56 | BitPuffin | on the line with vertices |
| 21:04:58 | BitPuffin | I don't see it |
| 21:04:59 | BitPuffin | :( |
| 21:05:09 | BitPuffin | or wait |
| 21:05:10 | BitPuffin | hang own |
| 21:05:29 | filwit | i was reading how Linus Torvalds doesn't like C++ the other day, and made me think that Nimrod would actually be a language the guy would like as a "successor" to C |
| 21:05:37 | BitPuffin | nope |
| 21:05:40 | BitPuffin | don't see it :( |
| 21:05:49 | vbtt | filwit: with a gc? |
| 21:05:54 | filwit | good point |
| 21:06:01 | BitPuffin | optional gc |
| 21:06:05 | filwit | not really |
| 21:06:08 | OrionPK | linus torvalds doesnt like anything or anyone |
| 21:06:09 | BitPuffin | ya rly |
| 21:06:19 | BitPuffin | Sometimes I tend to not use GC |
| 21:06:20 | vbtt | and inheritance? |
| 21:06:22 | BitPuffin | cuz I'm a freak |
| 21:06:28 | BitPuffin | vbtt: optional inheritance |
| 21:06:40 | filwit | it actually works without GC? i thought Araq said that wasn't really possible.. |
| 21:06:57 | vbtt | ok, but i dont think nimrod should target to linus, specifically |
| 21:07:21 | BitPuffin | filwit: yarly |
| 21:07:21 | vbtt | filwit: it works if you do manual memory management, apparently. so no refs, only ptrs. |
| 21:07:40 | BitPuffin | well yeah obviously |
| 21:07:45 | BitPuffin | what else? |
| 21:07:49 | filwit | well i was thinking if we could only get Linus to endorse Nimrod, then we could get the Linux Foundation to fork out some funding |
| 21:07:52 | filwit | LOL |
| 21:07:57 | BitPuffin | If you don't GC you need to manage memory |
| 21:07:57 | filwit | (just kidding) |
| 21:08:30 | Araq | filwit: I don't think Linus would like Nimrod |
| 21:08:38 | BitPuffin | guys wtf, why doesn't the tuple work |
| 21:08:40 | filwit | BitPuffing: yeah, i've never tired, but I asked before and got a "not really possible" response |
| 21:08:46 | filwit | BitPuffin** |
| 21:08:59 | filwit | Araq: why not? |
| 21:09:04 | BitPuffin | filwit: not really as pleasant as GC nimrod all the time is what I would say |
| 21:10:10 | LordAndrew | Huh. In the .c files in the nimcache, they have "/* The generated code is subject to the original license. */" appended to the top. What is the "original license" this refers to? |
| 21:10:14 | * | bbodi quit (Ping timeout: 272 seconds) |
| 21:10:21 | filwit | Araq: based on his complaints about C++, it sounded like he really just doesn't like OOP |
| 21:10:32 | Araq | LordAndrew: the license you chose for your code |
| 21:10:52 | Mat3 | ciao |
| 21:11:08 | * | Mat3 quit (Quit: Verlassend) |
| 21:12:39 | Araq | filwit: Linus decided to build a Unix clone, so in my alternative reality this means he wouldn't recognize good design even if you nail it onto his forehead |
| 21:13:50 | filwit | well there where obviously practical benefits to making a Unix clone beyond the technical stuff |
| 21:14:09 | filwit | POSIX standard and all that |
| 21:14:44 | BitPuffin | hmm |
| 21:14:52 | BitPuffin | shouldn't it be possible to compare a ref array with nil? |
| 21:14:54 | nueva | i suppose nimbase.h could change in future compiler versions, so I shouldn't embed it in my project to use with generated files. is it true? |
| 21:14:55 | filwit | if it didn't conform to POSIX, it would probably only be as popular as ReactOS right now... |
| 21:15:00 | BitPuffin | I'm getting this instead |
| 21:15:10 | BitPuffin | Error: type mismatch: got (array[0..999999, TVec3], nil) |
| 21:15:11 | BitPuffin | but expected one of: |
| 21:15:15 | BitPuffin | <long list> |
| 21:16:26 | * | brson quit (Ping timeout: 264 seconds) |
| 21:17:55 | Araq | nueva: not sure, nimbase.h changes are rare |
| 21:18:05 | BitPuffin | https://gist.github.com/BitPuffin/8567509 |
| 21:18:08 | BitPuffin | that's the code |
| 21:18:16 | nueva | why is git repo is so huge? because it contained c sources in past? or any binary files? |
| 21:18:38 | BitPuffin | nueva: binary |
| 21:19:01 | Araq | BitPuffin: does it work on "master"? |
| 21:19:12 | BitPuffin | Araq: I think I might have master let me check |
| 21:19:27 | Araq | nueva: C sources as zips for bootstrapping convenience |
| 21:19:38 | BitPuffin | Already up-to-date. |
| 21:19:47 | LordAndrew | Would there be any use for something like this: https://gist.github.com/Lordovos/8552530 ? |
| 21:19:57 | Araq | does it work on "devel", BitPuffin ? |
| 21:20:03 | BitPuffin | Araq: que? |
| 21:20:42 | Araq | BitPuffin: we have 2 branches now. "devel" is unstable, "master" is supposed to be stable |
| 21:20:48 | BitPuffin | I see |
| 21:20:50 | BitPuffin | that's good |
| 21:21:41 | BitPuffin | I just did git checkout remote/origin/devel or something like that, hope that's the correct way |
| 21:22:08 | BitPuffin | SIGSEGV: Illegal storage access. (Attempt to read from nil?) |
| 21:22:10 | BitPuffin | ftw |
| 21:22:20 | BitPuffin | Araq: that would be a nein |
| 21:23:21 | filwit | git checkout origin/devel |
| 21:23:35 | filwit | unless your working off your own fork |
| 21:23:37 | BitPuffin | filwit: well I assume it worked since the error was something else |
| 21:23:43 | filwit | ah, okay |
| 21:23:54 | * | odc quit (Ping timeout: 252 seconds) |
| 21:24:46 | filwit | ps. you'll need to 'git checkout master' before 'git pull', in case you didn't know |
| 21:25:23 | BitPuffin | well I was already on master |
| 21:25:36 | filwit | i meant the next time you try and pull |
| 21:25:40 | BitPuffin | wtf now I can't build the master version because the devel version was broken |
| 21:26:02 | filwit | you'll get a merge conflict of something if you're not on master when trying to pull |
| 21:26:43 | Araq | BitPuffin: a known issue, modify ropes.nim, the line with expr[string] |
| 21:27:02 | BitPuffin | Araq: why isn't that committed already then? |
| 21:27:06 | Araq | make `~ ` to use the trival implementation |
| 21:27:08 | filwit | or 'git reset --hard' |
| 21:27:26 | filwit | then build master again |
| 21:27:38 | Araq | BitPuffin: because I have no time and nobody else here is doing anything productive |
| 21:28:00 | BitPuffin | Araq: well I'll deal with it when I get home then |
| 21:28:09 | Araq | thank you |
| 21:28:18 | BitPuffin | Araq: I'll PR dat shit |
| 21:29:34 | nueva | "import some/a" and "import some/some/a as b" will result in overwrited generated files ("nimcache/some_a.c"). is it bug or unexpected edge case? |
| 21:29:59 | * | tdc quit (Ping timeout: 240 seconds) |
| 21:30:19 | Araq | it's an expected edge case |
| 21:30:40 | Araq | the compiler uses the "package" name except that we have no notion of a "package" really |
| 21:31:05 | Araq | IMHO you get what you ordererd, a mess |
| 21:33:43 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 21:36:05 | nueva | Araq: yes, I've ordered a messed hierarchy, but not overwrited files. anyway, I can't really object you, because I can't think about a real similar example. |
| 21:36:36 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 21:38:12 | Araq | nueva: if the compiler would encode the full path, you couldn't move the nimcache directory around |
| 21:38:40 | Araq | I can't win the battle against increasing stupidity |
| 21:40:06 | * | vbtt_ joined #nimrod |
| 21:40:25 | vbtt_ | Araq: nimrod could complain about the conflict. |
| 21:41:02 | Araq | vbtt_: perhaps |
| 21:41:15 | vbtt_ | basically reject the mess. |
| 21:42:41 | Araq | but "omg nimrod fails when you have 2 identifcally named modules of different subdirectories which however have the same name" is not really an issue I care about |
| 21:43:19 | vbtt_ | fair enough |
| 21:44:34 | Araq | you might as well complain that the compiler doesn't make you an omelette yet |
| 21:45:29 | xtagon | from breakfast import omelette |
| 21:45:43 | EXetoC | so imports should be renamed then? because you can't control that when using third-party libs |
| 21:45:46 | * | brson joined #nimrod |
| 21:45:46 | * | brson quit (Client Quit) |
| 21:45:52 | EXetoC | if that's even relevant |
| 21:47:00 | nueva | well, Nimrod doesn't even care about its own output designed for feeding the compiler, what omelette will it then cook for feeding a human? |
| 21:48:33 | Araq | EXetoC: third-party libs usually adhere to babel's guidelines and so it shouldn't be a problem |
| 21:49:22 | Araq | if you have 2 different packages of the same name you already have path problems because the OS is stupid enough to enforce unique directory names ... |
| 21:50:45 | Araq | it's not like the compiler picks "source" as the package name when you have pgk/source/module.nim |
| 21:51:15 | Araq | it tries to be smart ... (yeah I know that usually ends in a desaster) |
| 21:52:25 | nueva | Araq: is it relevant for my artificial example? subdirectory can have the same name as its parent directory (or any other module's parent directory) so uniquiness constrant doesn't apply here. |
| 21:54:47 | Araq | nueva: it's relevant for the real world. artificial examples are cheap and meaningless |
| 22:00:16 | Varriount | Araq: I would use int32 because it uses less memory? |
| 22:01:27 | Araq | Varriount: ok ... a valid reason. so you store a seq[TRune] instead of an utf-8 string and care about memory usage |
| 22:01:49 | Araq | Varriount: so fix it if it concerns you |
| 22:02:14 | Varriount | I will. I was just wondering if you had a specific reason for implementing it as a native int. |
| 22:02:59 | nueva | Araq: nimbase.h is missing in nimcache and compile_*.sh script is placed outside of nimcache, so compiling of cached files on other computer isn't so obvious ATM. just nitpicking. |
| 22:03:16 | NimBot | Araq/Nimrod devel 749f920 Zahary Karadjov [+0 ±1 -0]: nest PreMain inside NimMain for easier consumption of static libraries developed in Nimrod... 2 more lines |
| 22:03:16 | NimBot | Araq/Nimrod devel 0317937 Zahary Karadjov [+0 ±3 -0]: fix the error "only proc headers can feature pragmas" when compiling in JS mode |
| 22:03:31 | Araq | nueva: it used to work |
| 22:04:01 | Araq | but we have constantly have to change things because people constantly complain |
| 22:04:10 | xtagon | Does anyone use the experimental JS mode? I find it interesting but have a hard time seeing practical use cases |
| 22:04:30 | Araq | reactormonk uses it |
| 22:04:56 | Varriount | Although, if you wanted to be really conservative, you could probably do something with a tuple (int16, int8) |
| 22:05:18 | Varriount | That would probably send Araq into paroxisms though. |
| 22:05:19 | Araq | Varriount: that doesn't change anything because of alignment |
| 22:05:25 | reactormonk | xtagon, kinda works |
| 22:05:45 | reactormonk | xtagon, https://github.com/Araq/Nimrod/issues?labels=JS&page=1&state=open |
| 22:06:07 | reactormonk | mostly https://github.com/Araq/Nimrod/issues/347 |
| 22:06:36 | reactormonk | my head just exploded because of a nasty case of JS userscript sandbox breaking :-/ |
| 22:07:50 | xtagon | I'm mainly wondering *why* you would want to use the JS compiler. Is it just to have a nicer syntax, as with CoffeeScript? |
| 22:08:20 | nueva | xtagon: maybe because of unified language on backend/frontend |
| 22:08:22 | filwit | so you can write an app and target native and web |
| 22:08:53 | xtagon | Ah |
| 22:09:12 | EXetoC | and language features of course |
| 22:09:31 | nueva | node.js made this for JavaScript but Nimrod is kinda meta-Node.js. with static typing and stuff. |
| 22:09:37 | Varriount | Araq: Since I'm not that knowledgable on alignment, could you explain? I thought that, at least on 32 bit systems, alignment was done in 4-byte chunks |
| 22:10:43 | Araq | yeah so what do you think your 3-byte tuple will take? |
| 22:11:24 | Araq | that's right, it will get size = 4 for all practical purposes |
| 22:11:25 | Varriount | Ah. Once again I get bits and bytes confused >_< |
| 22:14:01 | * | Smaehtin joined #nimrod |
| 22:17:04 | Varriount | Hi Smaehtin |
| 22:17:19 | Smaehtin | Hey everyone, Nimrod noob here. Why can I not evaluate a size of a given type at compile-time? |
| 22:17:34 | Smaehtin | Except for the built-in types like int, long, etc.? |
| 22:17:35 | Varriount | Smaehtin: Can we see an example? |
| 22:18:04 | Varriount | Also, what version of nimrod are you using, the version on the website, the master branch, or the dev branch? |
| 22:19:11 | Smaehtin | http://pastebin.com/HMskUn2Z |
| 22:19:22 | Smaehtin | I tried both master and the 0.9.2 version from the website |
| 22:19:59 | Araq | Smaehtin: because the size computation is still buggy |
| 22:20:12 | Araq | and so to prevent bugs, it's not allowed for now |
| 22:20:33 | Smaehtin | Araq: Okay, I see. Thanks a lot :) |
| 22:20:48 | Varriount | Smaehtin: Any particular reason why you need static size computation? |
| 22:21:37 | EXetoC | it should be "static" either way, no? |
| 22:21:41 | Smaehtin | But the sizeof works fine at run-time, that seems weird |
| 22:22:40 | Varriount | Smaehtin: It probably has to do with the fact that static blocks run in the VM |
| 22:22:43 | Smaehtin | No particular reason, I can easily work around the bug, but I just stumbled apon the bug |
| 22:23:01 | * | LordAndrew quit (Ping timeout: 248 seconds) |
| 22:23:18 | Varriount | For the basic types, sizes are hardcoded (I think) |
| 22:23:23 | Smaehtin | Varriount: I see, I wasn't actually aware that the static stuff was executed in a VM, haha |
| 22:24:02 | Varriount | Smaehtin: Static code, templates, macros, etc are all calculated by an internal vm |
| 22:24:40 | Smaehtin | Varrount: Oh alright, thanks! :) |
| 22:28:10 | Smaehtin | Another question: How are the plans going with the whole "making Nimrod case-sensitive" project? Or was that abandoned? |
| 22:29:57 | Araq | Smaehtin: it's not weird the compiler compiles 'sizeof' into C's sizeof |
| 22:30:41 | Varriount | Smaehtin: I think (I might be wrong) that Araq plans to have some sort of semi-case-sensitive mode. The problem right now is mainly the wrappers, I think |
| 22:30:59 | Smaehtin | Araq: No, I just realized that wasn't a very smart observation. My bad |
| 22:31:00 | Araq | Smaehtin: the compiler itself is now case consistent and you can use --cs:partial to get the partial case sensitivity we discussed on the forum |
| 22:31:22 | Smaehtin | Araq: Oh, also in the 0.9.2 version? Or master only? |
| 22:31:29 | Araq | most parts of the stdlib should work now with --cs:partial too |
| 22:31:38 | Araq | but it's in devel only |
| 22:31:48 | Smaehtin | Araq: Ah okay, that's nice. Thanks |
| 22:32:41 | Araq | since you're one who wants that feature, let me ask you: is --cs:partial sufficient or do you want --cs:full ? |
| 22:33:05 | * | Araq is still gathering data |
| 22:33:37 | Varriount | Is there an explanation of what is partial about cs:partial anywhere? |
| 22:33:48 | nueva | is current styleguide still promotes identifiers like T* and P* or style is changed to TypeName and TypeNameRef (or similar)? I have nothing against any of these (or any other) style, just want to know about current internal codestyle... |
| 22:34:00 | Smaehtin | Araq: I'm not sure exactly what the differences are |
| 22:34:31 | * | psquid quit (Quit: WeeChat 0.4.2) |
| 22:34:34 | Araq | ah ok, well --cs:parital distinguishes between Foo and foo but foo_bar is still the same as fooBar |
| 22:34:55 | Varriount | Ah, so that wrappers still work. |
| 22:34:56 | Araq | in other words case is significant for the first letter only |
| 22:35:20 | EXetoC | nueva: yes. stuff would collide otherwise |
| 22:35:23 | Smaehtin | Araq: I personally prefer --cs:full then, haha |
| 22:36:17 | Varriount | I'd prefer something like --cs:full, but have it act like cs:none if a _ is in the identifier (Again, for wrappers) |
| 22:36:22 | * | vbtt_ quit (Ping timeout: 272 seconds) |
| 22:36:43 | Varriount | Then again, I don't feel very strongly about things either way. |
| 22:36:51 | Araq | nueva: I don't know how the transition from TTyp to Typ should happen |
| 22:36:58 | * | psquid joined #nimrod |
| 22:36:58 | * | psquid quit (Changing host) |
| 22:36:58 | * | psquid joined #nimrod |
| 22:37:13 | Araq | technically it's pretty easy to do automatically |
| 22:37:40 | Smaehtin | I honestly like the Pascal type prefixes |
| 22:38:06 | Araq | Smaehtin: you do? then why do you want --cs:full, lol |
| 22:38:34 | EXetoC | I'd be fine with having both, why not :p |
| 22:39:07 | Varriount | Araq: If there's one thing reading those PHP rants taught me, it's that things, at least in a stdlib, should be consistant. |
| 22:39:11 | Smaehtin | Araq: I would prefer everything being case sensitive but still keeping the Pascal type prefixes |
| 22:39:31 | Araq | Smaehtin: yay ... that's a new opinion |
| 22:39:38 | Araq | brb |
| 22:39:40 | Smaehtin | Haha |
| 22:40:00 | EXetoC | I'd probably want Type and PType then or something like that |
| 22:40:15 | * | brson joined #nimrod |
| 22:41:07 | Smaehtin | EXetoC: Yeah that could work for me as well if it was of course still case-sensitive |
| 22:41:08 | dom96 | Looks like no matter what we do we will make somebody unhappy. |
| 22:41:49 | EXetoC | Smaehtin: I don't know why but ok |
| 22:42:01 | Smaehtin | dom96: That's stating the obvious, haha. Can't make everyone happy no matter what |
| 22:42:08 | nueva | is PType (by convention) just a shorter synonym for 'ref Type' or it's better also in some other sense? |
| 22:42:22 | EXetoC | or ptr Type |
| 22:42:27 | Varriount | I suggest we stick each option on a dart-board, blindfold Araq, and have him throw a dart and the one we should choose. |
| 22:42:45 | Smaehtin | Varriount: That would be the most fair thing to do |
| 22:42:49 | Varriount | *to pick the one |
| 22:43:58 | Smaehtin | Does anyone know why the PayPal donation link isn't working on the site? |
| 22:44:22 | nueva | just make something like gofmt for automatic formatting. automatically enforced common denominator is a bliss. |
| 22:44:24 | Smaehtin | Oops, nevermind, works fine now |
| 22:44:46 | Varriount | nueva: I agree with you there. *hugs pylint* |
| 22:45:13 | nueva | even if it's TType, PType and some other ugly mess :D |
| 22:50:25 | EXetoC | nueva: does it format everything? |
| 22:52:47 | Araq | Smaehtin: I still think case sensitivity is one of the biggest mistakes in the history of computing fwiw |
| 22:53:36 | Araq | if it works at all then only because auto-complete ignores the case when you type stuff in ... |
| 22:54:15 | nueva | EXetoC: do you mean "does it fail on some syntax constructs"? I beleive no, not on any. |
| 22:54:55 | Araq | in fact, even --cs:partial is slightly annoying |
| 22:55:22 | Araq | ok, so it's cstring because it's a builtin type like int, but is it cstringArray or CstringArray? |
| 22:55:43 | EXetoC | nueva: no, it could just skip some elements. for example, sometimes having an if/else on a single line is readable and sometimes it makes sense to use 4 lines |
| 22:55:47 | Smaehtin | Araq: It may be, but for some reason my OCD really kicks in when I'm reading the Nimrod documentation and see all the different casing conventions like readBuffer, ReadBytes, E_Base, EAsync, etc. :( |
| 22:56:07 | EXetoC | or some might prefer 2, but I prefer to go with either of the extremes |
| 22:56:19 | Araq | is it WideCString or wideCstring or widecstring ? |
| 22:56:49 | dom96 | You just need to be consistent. |
| 22:56:54 | EXetoC | wideC_string of course. pretty logical imo :p |
| 22:57:03 | Araq | and if it is WideCString do you really want a constructor proc wideCString ? |
| 22:57:29 | dom96 | And then it's much easier to predict these names. |
| 22:57:29 | EXetoC | not a fan of ctors that are named the same as the type? |
| 22:57:30 | Smaehtin | Araq: Yeah I see what you mean. Even Microsoft is inconsistent a lot of places when it comes to the .NET framework naming conventions |
| 22:57:39 | reactormonk | xtagon, and because javascript semantics suck. |
| 22:57:54 | Smaehtin | Yeah, consistency is really the key here I think |
| 22:57:55 | reactormonk | js> [100,1,2].sort() |
| 22:57:57 | reactormonk | [1, 100, 2] |
| 22:58:39 | Araq | Smaehtin: I disagree. consistency is only important because you have been trained to think so in decades of computing |
| 22:58:51 | dom96 | The only problem with consistency is that it is difficult to achieve. But if we have something like go fmt it shouldn't be a problem right? |
| 22:58:58 | Varriount | Araq: Have you seen PHP? |
| 22:59:14 | Smaehtin | Araq: Perhaps you're right. I'm not really the kind of person who loves changes :) |
| 22:59:18 | Araq | I cna wirte lkie tihs and yuo cna slitl raed it |
| 22:59:27 | Smaehtin | Araq: Wow |
| 22:59:32 | Varriount | ^ But not as easily |
| 22:59:51 | nueva | EXetoC: it has -r="": rewrite rule (e.g., 'a[b:len(a)] -> a[b:]') and also has indent width setting and tabs/spaces indent switch. otherwise rules are fixed. |
| 23:00:09 | nueva | wide_c_string |
| 23:00:31 | nueva | of types wide_c_string_t or wide_c_string_p |
| 23:00:39 | Varriount | Wait, why are we arguing/discussing this again? |
| 23:00:56 | EXetoC | because someone mentioned it! |
| 23:01:12 | Araq | Varriount: because it's fun |
| 23:01:12 | Smaehtin | I'm sorry, I think it's because I asked what the status was on the --cs compiler option |
| 23:01:15 | nueva | who let the dogs out? |
| 23:01:18 | EXetoC | nueva: C should be uppercase imo :> |
| 23:02:01 | Araq | dom96: it was easy to predict the names |
| 23:02:18 | Araq | it's just that the prefixes are admittedly somewhat ugly |
| 23:02:39 | Araq | and that's an issue when you confuse beauty with readability |
| 23:03:09 | * | aruniiird quit (Ping timeout: 272 seconds) |
| 23:03:22 | Varriount | Well, if we're all going to throw our opinions in the pot... I've always liked python's choice of using different styles for class names and procedure names. |
| 23:03:44 | Araq | Varriount: that's just hungarian notation |
| 23:03:50 | EXetoC | wide_C_string TCP_IP_ohai fooBar. this won't work with the upcoming changes though |
| 23:04:05 | * | brson quit (Ping timeout: 248 seconds) |
| 23:04:31 | Varriount | Araq: Do you have anything bad to say about hungarian notation then? I'm interested. |
| 23:04:49 | EXetoC | I like the sensible version |
| 23:04:49 | Araq | it's universally considered to be a bad idea :P |
| 23:04:53 | EXetoC | whichever that was |
| 23:05:15 | EXetoC | both? |
| 23:05:22 | Araq | Varriount: if this_is_easier_to_read thanThis why use both? |
| 23:05:55 | Varriount | To distinguish between types and procedures |
| 23:06:04 | EXetoC | systems hungarian is obviously stupid |
| 23:06:32 | Varriount | Also, notice that I said 'different styles' - I meant the difference itself, not the two styles. |
| 23:08:39 | Araq | what do variables look like? this_style? |
| 23:08:56 | Varriount | In python? Yes. |
| 23:09:24 | dom96 | We're pretty far down the graph: http://sogrady-media.redmonk.com/sogrady/files/2014/01/lang-rank-114-wm.png |
| 23:09:30 | Araq | ok, so it's important to distinguish between classes and defs but not between vars and defs because ... ? |
| 23:10:02 | EXetoC | cus call syntax? dunno |
| 23:10:25 | EXetoC | dom96: how can it be :> |
| 23:10:29 | Araq | dom96: but we ARE in the graph ... |
| 23:10:32 | Smaehtin | dom96: How long has Nimrod been around for? |
| 23:11:15 | * | brson joined #nimrod |
| 23:11:29 | dom96 | EXetoC: Because not enough Nimrod repos on github! |
| 23:11:37 | dom96 | Araq: True. |
| 23:11:56 | Varriount | Araq: Because the first usage of a var tends to be in the middle of a proc |
| 23:12:00 | dom96 | Smaehtin: Better ask Araq that. |
| 23:12:12 | nueva | maybe because vars and defs are the same? 'def a: return 5' is equivalent to 'a = lambda: 5' |
| 23:12:22 | Varriount | ^ That too |
| 23:12:29 | Smaehtin | Araq: How long has Nimrod been around (to the public)? |
| 23:12:34 | Araq | Smaehtin: since forever |
| 23:12:57 | Araq | can't remember, need to check the site, lol |
| 23:13:24 | Smaehtin | Araq: There isn't even a Wikipedia page about Nimrod! |
| 23:13:36 | Varriount | Smaehtin: it got taken down |
| 23:13:44 | Smaehtin | Varrount: How come? |
| 23:13:50 | Varriount | Due to lack of third party sources |
| 23:13:53 | dom96 | Smaehtin: We're not "notable" enough. |
| 23:14:17 | Smaehtin | Varriount: That's a shame. I really feel like Nimrod deserves a lot more attention than currently given |
| 23:14:34 | renesac | how can I iterate over the fields of a tuple while changing its values? |
| 23:14:42 | renesac | like: |
| 23:14:43 | renesac | for var c in min.fields: |
| 23:14:43 | renesac | c += 1 |
| 23:15:03 | nueva | btw, here is my usecase for Nimrod. have a C++ library, doesn't want to write in C++, want a language with interoperabilty with C++, but not C |
| 23:15:12 | Araq | for c in min.fields: c += 1 # should work |
| 23:15:24 | Varriount | Smaehtin: Which is why, despite the fact that there are plenty of other languages, I choose to work on nimrod. |
| 23:15:30 | Araq | the fields iterator acutally returns by 'var T' |
| 23:15:48 | Araq | (that's a secret) |
| 23:15:59 | renesac | I get Error: for a 'var' type a variable needs to be passed |
| 23:16:21 | Smaehtin | renesac: remove the var keyword |
| 23:16:23 | * | brson quit (Ping timeout: 245 seconds) |
| 23:16:29 | renesac | I removed |
| 23:16:39 | EXetoC | from the param? |
| 23:16:53 | EXetoC | var on param means you must pass in a var |
| 23:17:00 | renesac | if I didn't I would get: Error: identifier expected, but found 'keyword var' |
| 23:17:07 | Varriount | Not only are my meager talents of some use, but I get to use a language that isn't restricting (java) simple (C) or overly complicated (c++) |
| 23:17:28 | EXetoC | oops, didn't read properly |
| 23:18:08 | Araq | renesac: hmm, I am quite sure this worked before |
| 23:18:23 | renesac | oops |
| 23:18:25 | Araq | try perhaps: for x in fields(a): x = x + 3 |
| 23:18:29 | renesac | my fault |
| 23:18:37 | renesac | I declared min with "let" |
| 23:18:40 | renesac | sorry |
| 23:18:49 | Araq | good |
| 23:19:09 | dom96 | Personally I don't see myself contributing to anything big like Go or probably even Rust. Here we have a nice small community and there are plenty of opportunities to implement things which are great learning experiences and also help the language. |
| 23:19:11 | renesac | the docs on .fields have: "The current implementation also has a bug that affects symbol binding in the loop body." |
| 23:19:28 | Smaehtin | Varriount: Yeah, Nimrod really seems to have hit the perfect spot when it comes to performance, simplicity, etc. |
| 23:20:11 | renesac | it is only a problem when creating a new variable inside the loop body? |
| 23:20:17 | Varriount | Smaehtin: I'll never understand why C++ types hate garbage collection so. |
| 23:21:51 | EXetoC | I hated garbage collection before because I trusted the opinions of other C++ programmers |
| 23:21:54 | Smaehtin | Varriount: Yet they still use smart pointers everywhere |
| 23:23:31 | discoloda | many associate GC with scripting languages |
| 23:23:31 | Smaehtin | Varriount: I mean, a lot of the C++ lovers always talk about how bad a GC is even though they're effectively using a GC themselves in the form of smart pointers and whatnot |
| 23:24:23 | Smaehtin | discoloda: Yes, and bad performance too |
| 23:24:40 | EXetoC | but at least some probably based their opinions on languages that don't give you many options |
| 23:26:40 | renesac | this rant gives iOS devs view on garbage collection: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ |
| 23:26:57 | renesac | (it is way down the post, the start is more a rant against scripting languages) |
| 23:27:51 | renesac | search for "All about garbage collectors" |
| 23:29:46 | vbtt | gc has a bad rap because of the pauses, and secondly extra cpu usage |
| 23:31:29 | * | darkf joined #nimrod |
| 23:32:13 | renesac | what he is mainly concerned is controling the workspace of the app, so it can do heavier tasks w/o being killed by the OS |
| 23:32:29 | Smaehtin | renesac: Interesting article :) |
| 23:32:37 | Araq | that blog post has been debunked by now, I think |
| 23:32:45 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 23:32:57 | * | brson joined #nimrod |
| 23:33:00 | renesac | do you have a link? |
| 23:33:20 | Araq | I think the reddit discussion was quite good |
| 23:33:53 | vbtt | nimrod lets you control the pauses so it's basically eliminated the 1st issue |
| 23:34:45 | Araq | most power consumption for a smart phone comes from the display, not from how ARM runs Javascript code |
| 23:35:10 | Araq | etc. etc. he picks some JS benchmarks and concludes from them what he wants |
| 23:35:19 | Araq | no facts, no data |
| 23:35:55 | EXetoC | such a big post, but no facts? lovely |
| 23:36:05 | * | io2 quit (Ping timeout: 248 seconds) |
| 23:38:37 | * | brson quit (Ping timeout: 272 seconds) |
| 23:41:19 | Smaehtin | What parts of Nimrod actually rely on the GC? I know that built-ins like arrays in D rely on the GC, but I'm not sure about Nimrod. |
| 23:43:02 | Araq | Smaehtin: use the devel branch, compile with --gc:none and the compiler tells you |
| 23:43:30 | Araq | strings, seqs, refs and closures use the GC |
| 23:43:47 | Araq | strings and seqs don't have to but currently do |
| 23:43:59 | Smaehtin | Araq: Oh there's warning for that now? That's nice |
| 23:53:07 | renesac | can I index in tuple fields with numbers? ie: how to iterate over two or more tuples together? |
| 23:54:22 | Araq | renesac: for a, b in fields(x, y) |
| 23:54:48 | Araq | a iterates over x and b over y then |
| 23:55:01 | Araq | the tuples must be the same type |
| 23:56:35 | renesac | oh, that second requeriment might be problematic.... |
| 23:56:46 | renesac | they have the same number of fields, but of different types |
| 23:56:53 | renesac | (float vs int) |
| 23:57:00 | Araq | hmm try it |
| 23:57:04 | renesac | ok |
| 23:58:26 | renesac | type mismatch.. |
| 23:58:47 | renesac | with two tuples of the same type it indeed works |
| 23:59:48 | Araq | renesac: edit compiler/semstmts.nim, line 562 |
