| 00:00:01 | MFlamer | no, for some nice syntax for ADT's |
| 00:01:01 | MFlamer | but, this macro could create an object with variants that were all ref's and some seperate strucs to hold the data |
| 00:01:54 | MFlamer | shit, the macro could also make some decisions on wetherto allocate or not based on difference in size of the variant fields |
| 00:02:05 | MFlamer | but, gotta start simple |
| 00:02:18 | MFlamer | fowl: what do you mean? |
| 00:02:41 | fowl | type |
| 00:02:43 | fowl | TA = object |
| 00:02:48 | fowl | TB {.macro.} = object |
| 00:02:51 | fowl | TC = object |
| 00:03:26 | EXetoC | I'm not sure I follow. does this mean that everything will be provided by a library, or that the compiler will expose a lot of options? |
| 00:03:30 | fowl | you could have macro return a statement list where you define procs with the TB type and it be seamless |
| 00:03:32 | fowl | i think |
| 00:04:31 | EXetoC | that was directed towards MFlamer btw |
| 00:04:37 | MFlamer | but wouldnt the proc be inside the type block? or can you get out |
| 00:05:22 | MFlamer | what happens if you dont attach the generated ast to callsite? |
| 00:06:08 | EXetoC | do you have a choice? |
| 00:06:39 | MFlamer | EXetoC: we have alot of different stuff in the conv. now. The way I see it there are 3 ways to represent ADT's or Sumtypes if you will |
| 00:07:10 | MFlamer | 1) a union of all the variant fields + a variant tag |
| 00:07:18 | fowl | MFlamer, it would take some magic but that parts not implemented yet so its doable |
| 00:08:14 | MFlamer | 2) same as 1 but generate strucs instead of a union to save memory |
| 00:08:54 | MFlamer | 3) each variant is a ref or ptr to some dyn aloc struc with the fields for each variant |
| 00:09:34 | MFlamer | so in 3 the variants are all the same size, but we have another indirection |
| 00:09:39 | * | DAddYE quit (Remote host closed the connection) |
| 00:09:51 | BitPuffin | is this possible? TTerrainSections = array[int64.min..int64.max, array[int64.min..int64.max, PTerrainSection]] |
| 00:09:53 | BitPuffin | lol |
| 00:10:07 | BitPuffin | I mean is indexing from a negative value legal? |
| 00:10:30 | MFlamer | 1) is whats in Nimrod now, 3) can be accomplished now if the user structures his data this way |
| 00:11:13 | BitPuffin | MFlamer: was that to me? |
| 00:11:18 | EXetoC | BitPuffin: yes |
| 00:11:21 | MFlamer | 2) is some idea zahary mentioned that I started to implement, but am sota stuck. And, not sure if it gets us much anyway |
| 00:11:30 | BitPuffin | EXetoC: cewl :D |
| 00:12:00 | MFlamer | BitPuffin: no, i'm rambeling to EXetoC |
| 00:12:40 | BitPuffin | MFlamer: carry on |
| 00:12:42 | EXetoC | MFlamer: I don't know what's best. I just thought it would be cool if the compiler could decide what strategy to use, unless maybe the user explicitly decides |
| 00:13:41 | MFlamer | Now, another thing on the table (also mentioned by some other users here recently) is the desire for a macro to define our object variants with seperate kind enums etc. in a more elegant Haskell like style |
| 00:14:25 | MFlamer | EXetoC: hat would be really cool |
| 00:14:30 | MFlamer | that* |
| 00:15:09 | BitPuffin | say WHAT |
| 00:15:44 | BitPuffin | https://gist.github.com/BitPuffin/7798020 |
| 00:15:48 | BitPuffin | Araq: ^^^^^^^^^^ |
| 00:16:08 | fowl | you're comparing typedescs |
| 00:16:20 | BitPuffin | TTerrainSections = array[int64.min..int64.max, array[int64.min..int64.max, PTerrainSection]] |
| 00:16:28 | BitPuffin | fowl: no u |
| 00:16:31 | BitPuffin | no but seriously no |
| 00:16:41 | fowl | one day you will learn nimrod |
| 00:16:55 | BitPuffin | one dayyy! |
| 00:17:05 | fowl | BitPuffin, its .low and .high, not .min and .max |
| 00:17:12 | BitPuffin | ah |
| 00:17:15 | BitPuffin | wtf |
| 00:17:20 | BitPuffin | I am drunk am I not |
| 00:17:30 | * | Varriount_ joined #nimrod |
| 00:17:33 | OrionPKM | now why doesnt low/high work for uint fowl |
| 00:18:02 | fowl | OrionPKM, no idea |
| 00:18:13 | BitPuffin | fowl: one day you will learn nimrod |
| 00:19:28 | * | travisbrady quit (Ping timeout: 250 seconds) |
| 00:20:30 | EXetoC | makes no sense :p |
| 00:20:40 | * | Varriount quit (Ping timeout: 245 seconds) |
| 00:20:40 | * | Varriount_ is now known as Varriount |
| 00:22:08 | EXetoC | MFlamer: why all these proposed helper macros? will the whole thing be implemented in a library? |
| 00:22:12 | EXetoC | rather than in the compiler |
| 00:22:35 | EXetoC | for example, will it be integrated with 'case'? |
| 00:23:13 | MFlamer | The struct representation for object variants would be done in the compiler |
| 00:23:36 | MFlamer | The only macro here would be to streamline the syntax a bit |
| 00:23:52 | MFlamer | Have you seen Haskell ADT's ? |
| 00:24:52 | EXetoC | nope |
| 00:25:13 | Varriount | EXetoC, technically, aside from their own set of bugs, macros could replicate many parts of the grammer. After all, they're just procedures that act on AST's, like 75% of the compiler. |
| 00:26:15 | MFlamer | data Tree a = EmptyTree |
| 00:26:15 | MFlamer | | Node a (Tree a) (Tree a) |
| 00:26:29 | MFlamer | thats the equivalent of |
| 00:26:33 | MFlamer | type |
| 00:27:08 | MFlamer | tkTree = enum |
| 00:27:28 | MFlamer | tkEmptyTree, |
| 00:27:39 | MFlamer | tkNode |
| 00:27:55 | MFlamer | TTree = object |
| 00:28:04 | MFlamer | sorry |
| 00:28:20 | MFlamer | TTree[T] = object |
| 00:28:48 | MFlamer | case kind: |
| 00:29:48 | MFlamer | of tkNode: l,r: TTree[T] |
| 00:30:01 | MFlamer | else: nil |
| 00:30:41 | MFlamer | something like that, Just nice to have a macro to define the enum and object together |
| 00:30:43 | EXetoC | yeah I'm familiar with the concept |
| 00:31:31 | EXetoC | since I've been using Rust a little |
| 00:32:23 | MFlamer | ok, alot like rust |
| 00:32:49 | EXetoC | yeah same basic idea |
| 00:34:52 | Varriount | Why is it that people are so attached to semicolons and braces? |
| 00:35:08 | EXetoC | cus they are FOOLS |
| 00:36:09 | EXetoC | fools I say |
| 00:36:33 | BitPuffin | hmm, can't check if an array is nil |
| 00:37:07 | EXetoC | aren't arrays value types? |
| 00:37:40 | BitPuffin | I guess |
| 00:38:27 | fowl | thats a massive array btrw |
| 00:38:38 | EXetoC | wut |
| 00:38:57 | fowl | BitPuffin, what is sizeof(TTerrainSections) |
| 00:39:11 | Varriount | Any particular reason the function for getting command line input is in its' own module, with no other procs? |
| 00:39:12 | EXetoC | oh. yeah |
| 00:39:43 | BitPuffin | fowl: dunno |
| 00:39:44 | fowl | Varriount, paramcount, paramstr are in system.nim |
| 00:39:45 | EXetoC | that's liek huge |
| 00:39:55 | Varriount | fowl, I mean, at run time. |
| 00:39:58 | EXetoC | huger than your RAM |
| 00:40:03 | Varriount | Like, prompting for user input |
| 00:40:05 | EXetoC | yes, huger |
| 00:40:13 | fowl | rdstdin? |
| 00:40:17 | BitPuffin | guys relax |
| 00:40:18 | Varriount | fowl, yeah. |
| 00:40:23 | BitPuffin | it's an array of PTerraiSections |
| 00:40:27 | BitPuffin | not TTerrainSections |
| 00:40:33 | BitPuffin | so most of that array will be nil |
| 00:40:40 | Varriount | there's only 1 or 2 functions in that module. |
| 00:40:46 | fowl | BitPuffin, im just curious what the size is |
| 00:40:54 | EXetoC | the size is fixed, so don't you get about a gazillion pointers? |
| 00:41:07 | fowl | 8 bytes x (high(uint64) ** 2) |
| 00:41:24 | EXetoC | c(:)-< |
| 00:41:53 | BitPuffin | fowl: I'd guess around 30mb |
| 00:42:34 | BitPuffin | EXetoC: yeah but it's all nil yo |
| 00:42:54 | EXetoC | don't you mean ~835511105130522005...... bytes? |
| 00:43:11 | BitPuffin | hmm wait |
| 00:43:21 | MFlamer | nil is still a word |
| 00:43:22 | EXetoC | 2**64 ** 2 * 8. no? :D |
| 00:43:44 | BitPuffin | MFlamer: well it doesn't contain the string nil |
| 00:44:06 | BitPuffin | if they are all nil, doesn't it mean they all point to the same place? |
| 00:44:20 | BitPuffin | try it on your computors |
| 00:44:36 | EXetoC | yes, but each pointer occupies a word, and in this case it's a gazillion of them |
| 00:44:40 | MFlamer | yeah, but the pointer is still there, so 64 bits |
| 00:44:46 | MFlamer | 8 bytes |
| 00:44:48 | Varriount | Anyone here think that it would be more intuitive to bundle rdstdin into the terminal module? |
| 00:44:51 | EXetoC | fowl: confirm plz. don't wanna look stupid here |
| 00:45:02 | MFlamer | but you know that :-) |
| 00:45:12 | fowl | nil pointer still takes 4 or 8 bytes |
| 00:45:20 | fowl | nil just means its value is 0 |
| 00:45:27 | MFlamer | thats what i said |
| 00:45:58 | EXetoC | BitPuffin: type 2**64 ** 2 * 8 in the python interpreter |
| 00:46:48 | MFlamer | use a quadtree or something |
| 00:46:50 | fowl | lol it says sizeof is 8 bytes, so maybe it is a ptr |
| 00:49:47 | BitPuffin | erf |
| 00:51:21 | BitPuffin | MFlamer: ugh, fine just as long as my computer doesn't explode |
| 00:52:07 | * | XAMPP quit (Read error: Connection reset by peer) |
| 00:52:08 | MFlamer | What are you doing? Where's the code? |
| 00:52:40 | BitPuffin | MFlamer: a game on my harddrive and in a private repo on bitbucket |
| 00:53:04 | MFlamer | very exclusive |
| 00:53:31 | BitPuffin | yaman |
| 00:53:43 | MFlamer | how do the rest of these guys know what you are talking about? |
| 00:53:57 | MFlamer | Are they in the club |
| 00:54:08 | fowl | no, we're unworthy :( |
| 00:54:24 | EXetoC | we were only discussing this really massive array |
| 00:54:36 | BitPuffin | MFlamer: because I'm practically tossing all the source code around in snippets? |
| 00:55:03 | fowl | BitPuffin, whta kind of game is it anyways |
| 00:55:37 | fowl | BitPuffin, are you going to have a pay-to-win model (free to play but you gotta pay to get good equipment) |
| 00:55:52 | BitPuffin | fowl: no |
| 00:55:54 | BitPuffin | brb reboot! |
| 00:56:18 | MFlamer | BitPuffin: good luck man |
| 00:57:45 | * | BitPuffin quit (Read error: No route to host) |
| 00:57:51 | Varriount | Meh, none of the games I like to play could have pay-to-win models |
| 00:58:28 | EXetoC | free to play ~= pay to win == crap :p |
| 00:59:06 | * | Varriount wishes there were more narrative adventure games. |
| 00:59:06 | * | BitPuffin joined #nimrod |
| 00:59:29 | fowl | Varriount, games like what |
| 00:59:30 | EXetoC | Varriount: system.nim does have readLine though |
| 01:00:44 | fowl | Varriount, oh and terminal.nim has nothing to do with readline |
| 01:01:02 | Varriount | fowl, http://www.gog.com/game/primordia |
| 01:02:50 | EXetoC | fowl: what readline? there's readLine in system, and then there's the readline lib which rdstdin references |
| 01:02:55 | Varriount | EXetoC, that's for files, not standard input (although you might be able to use the standard input stream) |
| 01:03:07 | EXetoC | yes |
| 01:03:18 | EXetoC | which is a terminal lib, right? so it might make sense to merge it with terminal |
| 01:03:32 | EXetoC | if it really is so bad to have such a tiny module |
| 01:03:49 | * | wolfspaw joined #nimrod |
| 01:04:24 | wolfspaw | Hi! I'm trying to use C scanf on nimrod, this is how I tried: |
| 01:04:30 | wolfspaw | proc scanf(formatstr: cstring) {.importc: "scanf", varargs.} |
| 01:04:30 | wolfspaw | var tst: int |
| 01:04:31 | wolfspaw | scanf("%ld", addr(tst)) |
| 01:04:31 | wolfspaw | write(stdout, tst) |
| 01:04:55 | wolfspaw | --- Which gives this error: ------- |
| 01:04:56 | wolfspaw | error: conflicting types for 'scanf' |
| 01:04:57 | wolfspaw | N_NIMCALL(void, scanf)(NCSTRING formatstr, ...); |
| 01:04:57 | wolfspaw | ^ |
| 01:04:57 | wolfspaw | note: in definition of macro 'N_NIMCALL' |
| 01:04:57 | wolfspaw | # define N_NIMCALL(rettype, name) rettype __fastcall name |
| 01:05:10 | OrionPKM | make a gist please |
| 01:05:34 | EXetoC | Varriount: so it's part of the same interface, and as such it can be used for keyboard input as well |
| 01:05:52 | wolfspaw | OrionPKM okay, hold'on |
| 01:06:23 | OrionPKM | varriount you checked that stuff in yet? |
| 01:06:34 | Varriount | OrionPKM, haven't had the chance. |
| 01:06:39 | OrionPKM | np |
| 01:06:40 | wolfspaw | OrionPKM: https://gist.github.com/anonymous/7798509 |
| 01:06:47 | Varriount | I spent 5 hours today on a math test |
| 01:07:04 | Varriount | and I'm gonna have to stay up late tonight in order to get a paper done. |
| 01:07:43 | Varriount | Why professors insist on assigning all the projects at the end of the semester, on top of exam studies, I have no idea. :< |
| 01:08:02 | OrionPKM | np |
| 01:08:04 | EXetoC | sadistic bastards |
| 01:08:11 | EXetoC | well, have fun |
| 01:08:12 | OrionPKM | can you link the plugin you had made again? |
| 01:08:19 | Varriount | wolfspaw, I think scanf is already defined. |
| 01:08:47 | Varriount | Or maybe my brain is just addled |
| 01:09:03 | EXetoC | BitPuffin: just tell people to enable plenty of swap before attempting to run your game :p |
| 01:09:33 | * | MFlamer quit (Remote host closed the connection) |
| 01:09:38 | EXetoC | sorry, I'll drop that subject now |
| 01:09:52 | OrionPKM | wolfspaw, add in header: "<stdio.h>" into the pragma |
| 01:10:35 | Varriount | OrionPKM, https://gist.github.com/Varriount/7775253 |
| 01:10:45 | OrionPKM | thanks |
| 01:10:49 | EXetoC | it says something about a conflict though, so I wonder if that will help |
| 01:10:49 | * | DAddYE joined #nimrod |
| 01:10:58 | EXetoC | either way, it should be a bug |
| 01:11:31 | Varriount | wolfspaw, try naming your procedure something else. |
| 01:11:51 | wolfspaw | OrionPKM: fantastic! Thanks, really simple! |
| 01:11:51 | BitPuffin | EXetoC: yeah :P |
| 01:12:18 | BitPuffin | I'm still not quite sure that I understand, I guess what you mean is that the address to nil still takes up space? |
| 01:12:47 | EXetoC | yes, the word-sized pointer |
| 01:12:56 | BitPuffin | problem with things like quadtree is that it'll get slower the further you get |
| 01:14:11 | EXetoC | so, ints would've taken up just as much space |
| 01:15:50 | * | DAddYE quit (Ping timeout: 264 seconds) |
| 01:15:53 | Varriount | Huh, today I learned that you can run dll functions from the windows command line |
| 01:16:16 | BitPuffin | EXetoC: microsoft word is much bigger than an int |
| 01:16:20 | BitPuffin | no but what do you mean word |
| 01:16:53 | BitPuffin | yay fowl has a quadtree |
| 01:17:14 | fowl | ^^ |
| 01:17:18 | EXetoC | so, how about a reasonably sized array instead? :p unless you need to allocate and de-allocate dynamically |
| 01:17:19 | wolfspaw | OrionPKM: would be feasible to wrap that scanf in a Nimrod macro, doing compile-time safe-checks (for making sure the number and types of variables match), as to expose a safe scanf with zero runtime overhead? |
| 01:17:31 | BitPuffin | fowl: again with the whole searchability thing |
| 01:17:37 | BitPuffin | fowl: gotta organize your stuff :p |
| 01:17:54 | * | DAddYE joined #nimrod |
| 01:18:03 | OrionPKM | why not :P |
| 01:18:33 | EXetoC | http://en.wikipedia.org/wiki/Word_%28computer_architecture%29 |
| 01:19:25 | BitPuffin | ollrajt |
| 01:20:14 | Varriount | wolfspaw, any particular reason you're wrapping scanf, instead of using nimrods standard lib? |
| 01:20:21 | BitPuffin | fowl: question, how come children is a seq |
| 01:20:34 | BitPuffin | fowl: you already know that there is 4 children |
| 01:21:25 | fowl | no children is the actual objects in a node |
| 01:21:46 | fowl | the node is partitioned when there are too many children in it |
| 01:21:48 | BitPuffin | ah |
| 01:23:18 | OrionPKM | varriount grr why hasnt AAAPackageDev been updated to st3 |
| 01:23:43 | EXetoC | why am I just sitting here doing nothing |
| 01:24:19 | Varriount | OrionPKM, it might be, however I use sublime text 2 |
| 01:24:32 | OrionPKM | it's not in package control for st3 |
| 01:24:38 | Varriount | *shrug* |
| 01:25:03 | Varriount | It probably wouldn't be hard to get it running. |
| 01:26:58 | Varriount | OrionPKM, you can keep just the xml/json stuff - I can always convert whatever you write to yaml, edit, and convert back. |
| 01:27:07 | fowl | BitPuffin, you probably want an octtree for 3d, right |
| 01:27:11 | wolfspaw | varriount just curiosity/exploring, I'm also used to C (scanf) and C++ (streams) and in nimrod I just found the "parseInt", "parseFloat" ways for getting formated input |
| 01:27:56 | OrionPKM | Varriount nah i'll see if I cant get this running |
| 01:28:26 | Varriount | wolfspaw, though the web documentation for the stdlib may not be the prettiest (go to python's documentation for that), it is immensely helpful. |
| 01:28:41 | * | mflamer joined #nimrod |
| 01:29:03 | Varriount | Though, it's by no means the ugliest either. *cough*javadoc*cough* |
| 01:30:12 | BitPuffin | fowl: well no because the terrain is actually 2d |
| 01:30:21 | BitPuffin | I mean the space it covers |
| 01:30:28 | BitPuffin | well not the terrain |
| 01:30:29 | fowl | so its flat? :( |
| 01:30:31 | BitPuffin | but the sections |
| 01:30:33 | BitPuffin | nonono |
| 01:30:35 | fowl | what kind of game is this |
| 01:30:37 | BitPuffin | the sections are a 2d grid |
| 01:30:44 | BitPuffin | but each section contains a terrain heightmap |
| 01:30:46 | BitPuffin | :P |
| 01:30:49 | fowl | oh |
| 01:31:09 | BitPuffin | makur sensur= |
| 01:31:11 | BitPuffin | ? |
| 01:31:17 | fowl | yea |
| 01:31:24 | BitPuffin | cool :D |
| 01:32:11 | * | shodan45 quit (Quit: Konversation terminated!) |
| 01:32:22 | * | shodan45 joined #nimrod |
| 01:32:43 | fowl | stop avoiding that question tho |
| 01:33:07 | BitPuffin | fowl: the octree question? |
| 01:33:37 | fowl | what kind of game |
| 01:33:40 | BitPuffin | ah |
| 01:33:45 | BitPuffin | I'm not avoiding the question |
| 01:33:47 | fowl | i hope its a remake of katamari damacy |
| 01:33:52 | BitPuffin | it's a game that you can play |
| 01:33:52 | fowl | that would be swell |
| 01:33:59 | BitPuffin | if you move the mouse the camera moves |
| 01:34:07 | EXetoC | nice |
| 01:34:08 | BitPuffin | if you press w you move forward |
| 01:34:23 | BitPuffin | and if you press a you walk left |
| 01:34:32 | BitPuffin | s, back and d right! |
| 01:34:39 | BitPuffin | so innovative |
| 01:34:41 | fowl | what happens if you click the mouse, do you swing a sword or fire bullets |
| 01:34:46 | BitPuffin | nothing |
| 01:34:56 | EXetoC | explosions? |
| 01:35:13 | BitPuffin | Araq pops out of a hole and scares you |
| 01:35:42 | BitPuffin | no but it's inspired by a game I played a couple of years ago now |
| 01:35:55 | Varriount | If I press the spacebar, I expect flying honey badgers to pop out of my screen, and nothing less. |
| 01:36:06 | Varriount | BitPuffin, lemme guess, minecraft? |
| 01:36:06 | BitPuffin | http://january.cc/ |
| 01:36:11 | BitPuffin | Varriount: nah |
| 01:36:43 | BitPuffin | you won't see any boxy boxes here no |
| 01:37:23 | fowl | lame |
| 01:37:26 | fowl | requires flash 11.3 |
| 01:37:41 | fowl | scumbag adobe |
| 01:37:47 | BitPuffin | yeah |
| 01:37:48 | BitPuffin | fuckas |
| 01:37:56 | BitPuffin | well maybe that's a new version even |
| 01:38:06 | BitPuffin | I remember playing that a long while ago |
| 01:38:25 | BitPuffin | but suddenly it seems like people have written about it in 2013 |
| 01:38:26 | BitPuffin | :s |
| 01:38:45 | EXetoC | pokemon? super mario? |
| 01:38:49 | BitPuffin | 2 years ago it was |
| 01:38:56 | BitPuffin | EXetoC: I already linked to the game |
| 01:38:59 | OrionPKM | varriount think it's working, just had to manually install |
| 01:39:02 | BitPuffin | talk about party pooper :P |
| 01:39:04 | EXetoC | BitPuffin: ok that makes sense |
| 01:39:30 | Varriount | The game I've alway's wanted to remake someday was a game originally on lego.com called Spybot: The Nightfall Incident |
| 01:43:48 | * | wolfspaw quit (Read error: Connection reset by peer) |
| 01:43:49 | BitPuffin | so a tuple can't be nil either? :( |
| 01:43:51 | BitPuffin | agh |
| 01:44:33 | Varriount | OrionPKM, are you planning on writing in YAML too? |
| 01:44:42 | OrionPKM | yeah |
| 01:44:45 | BitPuffin | how do they expect me to free up the dataaaa |
| 01:44:56 | OrionPKM | if I can figure out how to get yaml -> XML |
| 01:44:59 | EXetoC | by not using a value type |
| 01:45:09 | OrionPKM | im watching louie CK right now though so im kind of distracted |
| 01:45:15 | Varriount | OrionPKM, ctrl+shift+p -> convert |
| 01:45:17 | BitPuffin | EXetoC: can I do ref tuple? |
| 01:45:29 | BitPuffin | or do I need to wrap it in a package |
| 01:45:47 | OrionPKM | varriount the syntax highlighting is working, but that's not I guess |
| 01:46:05 | Varriount | OrionPKM, check the console |
| 01:46:18 | Varriount | ctrl+` |
| 01:46:25 | OrionPKM | yeah I know |
| 01:47:16 | Varriount | As a side note, sublime plugin development can be a pain - the api is.. useful for common tasks, but gets flaky for uncommon things. |
| 01:47:28 | OrionPKM | looks like it's not working in ST3 |
| 01:47:30 | BitPuffin | ref tuple seem to work |
| 01:47:32 | OrionPKM | just the syntax highlighting |
| 01:47:42 | Varriount | OrionPKM, any console errors? |
| 01:47:43 | BitPuffin | not sure how to initialize that though |
| 01:47:46 | OrionPKM | yes, quite a few |
| 01:48:15 | EXetoC | BitPuffin: by using new. I don't think there's a shortcut for this |
| 01:48:34 | Varriount | OrionPKM, https://github.com/SublimeText/AAAPackageDev/pull/25 |
| 01:48:41 | EXetoC | type X = ref tuple[x, y: int]; var a: X; new(a); a.x = cake |
| 01:49:05 | OrionPKM | it hasn't been merged? |
| 01:49:10 | BitPuffin | EXetoC: aww |
| 01:49:15 | BitPuffin | EXetoC: oh well that'll do |
| 01:49:18 | Varriount | OrionPKM, nope! |
| 01:49:23 | EXetoC | make it an object if you want the shortcut |
| 01:50:08 | EXetoC | the syntax can be retained in some cases by defining a converter |
| 01:50:43 | BitPuffin | EXetoC: well it's meant to be passed to GL too so an object is not really a good choice |
| 01:50:45 | fowl | did you know there is also new(t:typedesc): ref t |
| 01:50:58 | EXetoC | BitPuffin: the layout is identical |
| 01:51:27 | BitPuffin | EXetoC: so nimrod doesn't handle memory layout for us? |
| 01:51:41 | EXetoC | 'object' defines a value type |
| 01:51:42 | BitPuffin | or do you mean put the array in an object |
| 01:51:46 | BitPuffin | ref object* |
| 01:51:48 | EXetoC | and then you can stick ptr or ref onto it if you want |
| 01:51:58 | * | DAddYE quit (Remote host closed the connection) |
| 01:52:30 | * | DAddYE joined #nimrod |
| 01:52:32 | EXetoC | either of those three should be fine. they don't have any hidden fields |
| 01:52:53 | OrionPKM | varriount fewer errors |
| 01:54:14 | EXetoC | not that it would matter, unless for some reason you couldn't set the stride |
| 01:55:41 | Varriount | OrionPKM, are they fixable you think? |
| 01:56:38 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 01:56:39 | EXetoC | badger badger |
| 01:56:39 | OrionPKM | maybe, if not i'll go back to ST2 |
| 01:56:57 | OrionPKM | Varriount I only upgraded because somehow my ST2 install became hopelessly corrupted, theme was all fucked up |
| 01:57:14 | OrionPKM | but that was several months atgo |
| 01:57:15 | OrionPKM | ago* |
| 01:58:03 | EXetoC | must.. resist.. meta.. programming.. |
| 01:58:56 | BitPuffin | EXetoC: vector lib? |
| 02:01:08 | EXetoC | BitPuffin: asserting == and ~= :p |
| 02:01:17 | EXetoC | for epicly compact unit tests |
| 02:01:49 | Varriount | I hate writing unit tests. I know that they're supposed to be good, but... |
| 02:02:16 | BitPuffin | Varriount: fuckem |
| 02:04:02 | EXetoC | it's hard to get going |
| 02:06:10 | BitPuffin | EXetoC: with your game project? |
| 02:06:29 | EXetoC | but I think it's satisfying. at least those for math-oriented modules |
| 02:06:33 | EXetoC | BitPuffin: with unit tests |
| 02:06:38 | BitPuffin | EXetoC: ah |
| 02:06:40 | BitPuffin | yeah |
| 02:06:55 | BitPuffin | honestly almost everytime I don't test things in linagl it turns out to be wrong xD |
| 02:07:06 | BitPuffin | well okay that's a bit over the top |
| 02:07:12 | BitPuffin | but it has happened some times at least |
| 02:07:31 | BitPuffin | some of it not getting caught was the compiler not erroring when it should etc |
| 02:07:34 | BitPuffin | but that's fixed now |
| 02:09:04 | Varriount | OrionPKM, I'm off to do some things, I'll be back in ~1 hour |
| 02:09:17 | OrionPKM | I'll be out probably |
| 02:09:18 | OrionPKM | ttyl |
| 02:14:04 | EXetoC | dot(vec2(0, 0), vec2(0, 0)) ~=? 0 |
| 02:14:17 | EXetoC | near equality assert c(:) |
| 02:15:15 | fowl | EXetoC, there's a unittest module |
| 02:21:26 | EXetoC | fowl: ok, trying to figure out how to use it |
| 02:24:57 | fowl | https://github.com/fowlmouth/nimlibs/blob/master/tests/test_bbtree.nim |
| 02:25:31 | EXetoC | that certainly helps |
| 02:32:55 | * | shodan45_ joined #nimrod |
| 02:32:55 | * | shodan45 quit (Write error: Connection reset by peer) |
| 02:34:39 | * | shodan45 joined #nimrod |
| 02:34:46 | * | shodan45_ quit (Read error: Connection reset by peer) |
| 02:35:20 | BitPuffin | goodnight! |
| 02:35:36 | EXetoC | bbbb |
| 02:35:49 | EXetoC | fowl: it just that it seems a little buggy |
| 02:36:28 | * | xenagi joined #nimrod |
| 02:38:10 | * | shodan45 quit (Read error: Connection reset by peer) |
| 02:38:14 | * | shodan45_ joined #nimrod |
| 02:39:37 | * | BitPuffin quit (Ping timeout: 246 seconds) |
| 02:42:18 | EXetoC | fowl: that module fails like so: "lib/pure/unittest.nim(127, 42) Error: index out of bounds" |
| 02:42:21 | EXetoC | reporting it now |
| 02:47:26 | * | shodan45_ quit (Quit: Konversation terminated!) |
| 02:47:31 | * | shodan45 joined #nimrod |
| 02:49:26 | * | mflamer quit (Ping timeout: 240 seconds) |
| 02:53:17 | * | DAddYE joined #nimrod |
| 02:55:23 | * | shodan45 quit (Quit: Konversation terminated!) |
| 02:57:26 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 03:03:09 | * | DAddYE joined #nimrod |
| 03:07:21 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 03:54:55 | * | DAddYE joined #nimrod |
| 03:56:40 | * | brson quit (Quit: leaving) |
| 03:59:02 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 04:04:53 | * | hoverbear joined #nimrod |
| 04:30:46 | * | yodi joined #nimrod |
| 04:56:52 | * | DAddYE joined #nimrod |
| 05:01:35 | * | DAddYE quit (Ping timeout: 260 seconds) |
| 05:14:32 | OrionPKM | varriount i committed a bunch o stuff |
| 05:30:53 | yodi | it would be nice if nimrod can do this |
| 05:31:23 | yodi | for i in countfrom(10, 1): ... |
| 05:31:37 | yodi | or |
| 05:31:50 | yodi | for i in 10..1: |
| 05:33:30 | fowl | https://gist.github.com/fowlmouth/7800592 |
| 05:34:52 | * | xenagi quit (Read error: Connection reset by peer) |
| 05:37:30 | fowl | yodi, ^ |
| 05:37:37 | yodi | thanks fowl, i meant support into the core api |
| 05:59:02 | * | DAddYE_ joined #nimrod |
| 05:59:16 | * | DAddYE_ quit (Remote host closed the connection) |
| 05:59:22 | * | DAddYE_ joined #nimrod |
| 06:04:47 | * | hoverbear quit (Quit: Textual IRC Client: www.textualapp.com) |
| 06:06:04 | * | hoverbear joined #nimrod |
| 06:10:50 | * | Varriount quit (Ping timeout: 246 seconds) |
| 06:21:40 | * | achim joined #nimrod |
| 06:25:27 | * | DAddYE_ quit (Remote host closed the connection) |
| 06:25:58 | * | DAddYE joined #nimrod |
| 06:30:14 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 06:32:20 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 06:35:27 | * | hoverbear quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 06:44:05 | * | mflamer joined #nimrod |
| 07:26:28 | * | DAddYE joined #nimrod |
| 07:31:50 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 07:36:29 | * | Varriount joined #nimrod |
| 07:46:14 | * | DAddYE joined #nimrod |
| 07:46:28 | * | DAddYE quit (Remote host closed the connection) |
| 07:46:34 | * | DAddYE joined #nimrod |
| 08:11:41 | * | mflamer quit (Ping timeout: 272 seconds) |
| 08:21:07 | * | DAddYE quit (Remote host closed the connection) |
| 08:21:36 | * | DAddYE joined #nimrod |
| 08:27:13 | * | girvo joined #nimrod |
| 08:27:58 | * | girvo quit (Client Quit) |
| 08:32:36 | * | girvo joined #nimrod |
| 09:13:35 | * | girvo quit (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 09:20:39 | * | Mat3 joined #nimrod |
| 09:20:50 | Mat3 | hi all |
| 09:22:10 | fowl | hey |
| 09:29:46 | * | girvo joined #nimrod |
| 09:30:05 | * | girvo quit (Remote host closed the connection) |
| 09:30:31 | * | girvo joined #nimrod |
| 09:34:00 | * | CarpNet joined #nimrod |
| 09:46:59 | Mat3 | hi fowl |
| 09:47:25 | * | Mat3 reading the logs |
| 09:51:46 | * | girvo quit (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 10:29:09 | Mat3 | one sting which I want to change in my source is the dependency on some constants I must define, specially the lack of MAP_ANON or MAP_ANONYMOUS in the POSIX layer (which difer from OS to OS). I know these constants are not part of POSIX 1.x. On the other side it's the only way to reserve system memory though mmap with setted executable flag (which indeed is needed for executing generated machine code on most xNIX systems) |
| 10:29:22 | Mat3 | ^differ |
| 10:31:24 | Mat3 | ^^ the only way without handling faked file-handles. Another alternative would be using valloc (not part of POSIX) and mprotect (with non existent MAP_ANON flag) |
| 10:33:56 | Mat3 | I think it would be nice to extend the POSIX wrapper with both valloc and MAP_ANON, because there are often used (but non-stadard of course) |
| 10:34:01 | Mat3 | ^standard |
| 10:44:35 | * | Mat3 quit (Ping timeout: 260 seconds) |
| 11:01:57 | * | Mat3 joined #nimrod |
| 11:06:50 | * | Mat3 quit (Ping timeout: 264 seconds) |
| 11:27:01 | * | faassen left #nimrod (#nimrod) |
| 11:50:55 | * | BitPuffin joined #nimrod |
| 11:51:59 | * | BitPuffin quit (Client Quit) |
| 11:54:58 | * | faassen joined #nimrod |
| 11:57:21 | * | BitPuffin joined #nimrod |
| 11:57:44 | BitPuffin | Hey guys! |
| 11:58:53 | dom96 | hey |
| 11:58:59 | * | dom96 is still sick :( |
| 11:59:24 | dom96 | But i'm not only spreading germs, i'm also spreading the news of Nimrod! http://www.reddit.com/r/programming/comments/1s4iw1/converge_compile_time_metaprogramming_details/cdu48cp |
| 12:02:50 | BitPuffin | dom96: lol :D |
| 12:02:55 | BitPuffin | I'm trying out standing up working today |
| 12:07:05 | dom96 | Cool. I hear of more and more people doing that. |
| 12:07:27 | BitPuffin | I just put my laptop on a bunch of books haha |
| 12:07:42 | BitPuffin | which doesn't help with the screen much but hey |
| 12:07:48 | BitPuffin | it might be an improvement at least |
| 12:32:19 | dom96 | BitPuffin: how's the game going? |
| 12:34:58 | yodi | creating a game takes a lot of endurance |
| 12:35:42 | yodi | i still have an unfinished game on my pc somewhere |
| 12:39:54 | BitPuffin | dom96: behind but forward |
| 12:40:05 | BitPuffin | dom96: got a flat tire on my bike today so that's gonna steal a lot of time too :( |
| 12:40:22 | BitPuffin | are all number types initialized to 0 by default? |
| 12:41:13 | fowl | BitPuffin, no, some of them are initialized to 42 |
| 12:41:24 | BitPuffin | fowl: :O! |
| 12:41:25 | fowl | only the 128bit types though |
| 12:41:36 | BitPuffin | erh |
| 12:41:36 | dom96 | BitPuffin: aww that sucks |
| 12:41:49 | dom96 | I'm missing a mock exam in school today... |
| 12:42:04 | dom96 | I'm probably going to have to do it tomorrow in class ugh |
| 12:42:41 | BitPuffin | does typedesc{TMatrix} work? And does it make it so that every subtype of TMatrix (ie. TMat4 = TMatrix[float32, range[0..3], range[0..3]] work? |
| 12:42:46 | BitPuffin | dom96: mock? |
| 12:43:08 | dom96 | BitPuffin: practice, trial, not-real-exam |
| 12:43:32 | BitPuffin | dom96: |
| 12:43:35 | BitPuffin | ah |
| 12:43:39 | BitPuffin | dom96: that sucks :( |
| 12:43:47 | dom96 | BitPuffin: I think that's a TR macro syntax. |
| 12:44:05 | BitPuffin | dom96: you gonna have to de-abbrev that |
| 12:44:14 | dom96 | BitPuffin: Yeah, I was going to go today but i'm coughing so much that I would distract everyone or choke trying not to cough during the exam lol |
| 12:44:34 | dom96 | BitPuffin: Term Rewriting |
| 12:45:12 | BitPuffin | dom96: haha :D |
| 12:45:14 | BitPuffin | right |
| 12:45:16 | BitPuffin | hmm |
| 12:45:55 | BitPuffin | well I have an identity proc which looks like identity[T, N]() |
| 12:46:05 | BitPuffin | and I want a variation that provides TMat4.identity() |
| 12:49:40 | dom96 | what's the signature of identity? |
| 12:51:11 | dom96 | perhaps 'definition' is the correct term lol |
| 12:51:24 | BitPuffin | dom96: yea I already showed you the signature haha |
| 12:51:31 | BitPuffin | dom96: or do you mean mathematical? |
| 12:51:48 | BitPuffin | I = Iii = 1 |
| 12:52:02 | dom96 | oh, well huh. It's just: proc identity[T, N]() ? |
| 12:52:02 | BitPuffin | so the diagonal is 1 |
| 12:52:15 | BitPuffin | dom96: I already have that one |
| 12:52:39 | dom96 | Show me the full proc please |
| 12:53:11 | fowl | you want to pass "TMat4" as an argumetn? typedesc[TMat4] |
| 12:53:45 | BitPuffin | fowl: thanks! |
| 12:53:50 | BitPuffin | dom96: it dun diddily work |
| 12:54:03 | * | dom96 is still curious what the proc looks like |
| 12:54:27 | BitPuffin | dom96: it doesn't work but here: |
| 12:54:44 | BitPuffin | https://gist.github.com/BitPuffin/7804696 |
| 12:54:57 | BitPuffin | guess it should be 1.T |
| 12:54:58 | fowl | i've also seen people use "type T" in param type |
| 12:55:06 | fowl | type int #=> typedesc[int] |
| 12:55:34 | BitPuffin | which one is preferred by das komjunity? |
| 12:55:45 | fowl | i dunno |
| 12:56:16 | EXetoC | typedesc should be more common. I've never seen "type T" |
| 12:56:26 | BitPuffin | uh |
| 12:56:30 | BitPuffin | that identity proc is wrong |
| 12:56:48 | fowl | looks wrong |
| 12:57:00 | dom96 | Does "type T" actually work? I've never seen it either |
| 12:57:03 | BitPuffin | I don't know how it is even possible though |
| 12:57:05 | fowl | shouldnt identity be like [1 0 0 0 1 0 0 0 1] |
| 12:57:08 | fowl | for 3x3 |
| 12:57:10 | BitPuffin | I mean the result |
| 12:57:15 | EXetoC | dom96: seems like it |
| 12:57:27 | fowl | dom96, yea i ve seen filwit use it |
| 12:58:27 | BitPuffin | https://gist.github.com/BitPuffin/7804744 |
| 12:58:30 | BitPuffin | hahaha |
| 12:58:32 | BitPuffin | say wtf |
| 12:58:38 | dom96 | hrm, it works indeed. |
| 12:58:39 | EXetoC | type T > T.type > type(T). makes sense |
| 12:59:19 | BitPuffin | I have NO IDEA where those numbers that weren't 1.0 came from |
| 12:59:22 | BitPuffin | seriously wtf |
| 13:00:11 | fowl | run it more times see if its always those numbers |
| 13:00:13 | dom96 | check what result is before you iterate over it |
| 13:00:38 | BitPuffin | fowl: nope, different err time |
| 13:00:51 | BitPuffin | guess I'm gonna have to iterate over num |
| 13:00:59 | fowl | someone wrong with the stack |
| 13:01:02 | fowl | something* |
| 13:01:28 | BitPuffin | bug in the nimrudd? |
| 13:01:30 | EXetoC | 4.567...-41 ~= 0 |
| 13:01:45 | BitPuffin | hmm |
| 13:01:47 | BitPuffin | right |
| 13:01:47 | EXetoC | I don't like the default formatting |
| 13:01:54 | EXetoC | it's often very confusing when debugging |
| 13:02:00 | BitPuffin | no it's stupid |
| 13:02:14 | BitPuffin | i think you should have to be explicit to get the exp form |
| 13:02:33 | EXetoC | sometimes you can make out what the number is though, but it's difficult in this case |
| 13:02:35 | EXetoC | yeah |
| 13:02:54 | BitPuffin | well guess my workaround is gonna be to put 0 there explicitely since it obviously can't initialize floats properly on its own |
| 13:03:28 | fowl | dont check the generated c or anything |
| 13:03:47 | dom96 | try to reproduce it standalone |
| 13:03:58 | EXetoC | like I said, it's 0 apparently, but maybe you're referring to something else |
| 13:04:02 | BitPuffin | no u |
| 13:04:12 | dom96 | It should be '0.0000000000000000e+00' |
| 13:04:48 | BitPuffin | https://gist.github.com/BitPuffin/7804827 |
| 13:05:01 | BitPuffin | dom96: for now that's gonna have to be the workaround |
| 13:05:06 | BitPuffin | i don't have time to report this bug right now |
| 13:05:27 | fowl | oh haha |
| 13:05:35 | fowl | that looks right anyways compared to the first version |
| 13:06:03 | fowl | 1x1, 2x2, 3x3 were 1.0 the rest of the fields were whatever was on the stack |
| 13:06:18 | BitPuffin | fowl: well the initial proc was correct, just that for some reason it initialized the result with almost 0 lol |
| 13:06:53 | dom96 | maybe arrays don't get implicitly initialised |
| 13:07:07 | BitPuffin | https://gist.github.com/BitPuffin/7804860 this didn't work though |
| 13:07:25 | * | girvo joined #nimrod |
| 13:07:28 | BitPuffin | guess there is no result either for that part |
| 13:07:32 | * | girvo quit (Client Quit) |
| 13:07:39 | BitPuffin | but it whines about the m.R != m.C |
| 13:07:44 | BitPuffin | zahary_: fixit! |
| 13:07:46 | BitPuffin | lol |
| 13:07:48 | BitPuffin | :P |
| 13:07:59 | fowl | BitPuffin, it works for me |
| 13:08:08 | fowl | BitPuffin, the first version |
| 13:08:13 | EXetoC | why not just evaluate the part after result? since you're returning expr anyway |
| 13:08:55 | BitPuffin | fowl: ah the first version works yes |
| 13:08:56 | fowl | https://gist.github.com/fowlmouth/7804881 |
| 13:09:22 | fowl | then what are we talking about |
| 13:09:25 | fowl | are you drunk again |
| 13:09:26 | BitPuffin | EXetoC: What do you mean, R and C has to be identical |
| 13:09:31 | BitPuffin | fowl: this time you are the drunk wan |
| 13:09:52 | fowl | https://gist.github.com/BitPuffin/7804744 |
| 13:09:59 | fowl | you're drunk |
| 13:10:04 | dom96 | fowl: Maybe he has something on the stack, while you don't? |
| 13:10:13 | BitPuffin | fowl: look at the gist you alcoholic :P |
| 13:10:43 | BitPuffin | I probably do have something on the stack |
| 13:10:47 | fowl | that was the gist from: heres my function, why does it give this result |
| 13:10:49 | BitPuffin | because there are variables created before it |
| 13:10:56 | dom96 | precisely |
| 13:11:04 | dom96 | Show us your full code :P |
| 13:11:21 | BitPuffin | fowl: well that's not even what we are talking about, gotta keep up maaaaaan |
| 13:11:24 | BitPuffin | sure I'll push |
| 13:11:28 | BitPuffin | in the mean time find the repo |
| 13:11:31 | BitPuffin | because I'm not gonna link |
| 13:11:49 | dom96 | https://bitbucket.org/BitPuffin/linagl right? |
| 13:12:41 | fowl | whats so great about bitbucket |
| 13:12:58 | BitPuffin | alright it's pushed |
| 13:13:00 | dom96 | free private repos |
| 13:13:01 | BitPuffin | dom96: yup |
| 13:13:08 | BitPuffin | free private repos + mercurial support |
| 13:13:19 | fowl | whos thelonelybyte |
| 13:13:24 | dom96 | what's so great about mercurial? :P |
| 13:13:25 | BitPuffin | fowl: yo moma |
| 13:13:43 | fowl | BitPuffin, thats the one thats linked to from linagl on github |
| 13:13:55 | BitPuffin | fowl: ah |
| 13:13:57 | BitPuffin | fowl: old repo |
| 13:14:06 | BitPuffin | fowl: dom96's link nao |
| 13:14:21 | fowl | BitPuffin, you should try the first way again |
| 13:14:29 | BitPuffin | no |
| 13:14:36 | fowl | with one loop, but before the loop use "reset result" |
| 13:14:50 | BitPuffin | fowl: but that's even more efficient isn't it? |
| 13:15:02 | EXetoC | gonna report it? |
| 13:15:11 | fowl | BitPuffin, more efficient than what |
| 13:15:41 | BitPuffin | EXetoC: I'd like to but there is no time! |
| 13:16:50 | EXetoC | k |
| 13:20:53 | EXetoC | "http://build.nimrod-lang.org/docs/manual.html#var-statement" it'd be odd if it didn't apply to return values etc |
| 13:21:02 | EXetoC | I didn't know that enums were initialized like that |
| 13:22:53 | fowl | EXetoC, im pretty sure initialization is done with memset0() |
| 13:23:30 | fowl | reset does the same thing, so if that fixes the function then we found the issue |
| 13:25:37 | EXetoC | it'd be convenient if the first enumerator was the default, but then again it often is 0 anyway |
| 13:25:37 | fowl | what do i know |
| 13:25:39 | fowl | im drunk |
| 13:26:31 | EXetoC | and an invalid value conveniently stringifies to "invalid data" or something like that |
| 13:26:55 | EXetoC | fowl: when did you last compile test_bbtree successfully? |
| 13:28:32 | yodi | is there list comprehension equivalent in nimrod? |
| 13:31:30 | fowl | EXetoC, probably whenever i committed it |
| 13:33:27 | fowl | yodi, yes, map() |
| 13:35:01 | fowl | EXetoC, minimal test works though |
| 13:35:23 | fowl | eigenlicht, https://gist.github.com/fowlmouth/7805216 |
| 13:35:26 | fowl | EXetoC, * |
| 13:35:42 | EXetoC | ok |
| 13:36:35 | EXetoC | list comprehensions are a little more concise though, but a macro and/or more compact lambdas might help (that's just a couple of macro bug fixes away I think) |
| 13:46:44 | * | Mat3 joined #nimrod |
| 13:49:10 | yodi | EXetoC: i agree, even better still an implementation something like LINQ |
| 14:00:46 | BitPuffin | yay we now have orthographic projection :D |
| 14:02:59 | BitPuffin | perspective coming right up |
| 14:24:40 | * | achim quit (Quit: Textual IRC Client: http://www.textualapp.com/) |
| 14:32:40 | BitPuffin | or well |
| 14:32:46 | BitPuffin | first orthographic inverse |
| 14:40:12 | EXetoC | great |
| 14:40:28 | EXetoC | and I just rendered a quad. awesome |
| 14:44:44 | BitPuffin | actually I'm gonna skip orthographic inverse for now and focus on perspective |
| 14:44:54 | BitPuffin | since I don't need orthographic for this project! |
| 14:45:11 | BitPuffin | EXetoC: with projection? lol :) |
| 14:47:08 | EXetoC | nah |
| 14:47:34 | BitPuffin | EXetoC: just a plain triangle strip? |
| 14:48:04 | BitPuffin | hmm |
| 14:48:24 | BitPuffin | maybe I should render my terrain as a triangle strip instead of with indices |
| 14:49:28 | BitPuffin | that's probably both faster and more space efficient so why not |
| 14:49:36 | EXetoC | how do I explicitly print the same stack trace that is printed when not catching exceptions? |
| 14:49:56 | EXetoC | BitPuffin: indices are always used, so I don't know what you mean |
| 14:50:30 | BitPuffin | EXetoC: indexed triangles you goof |
| 14:51:27 | BitPuffin | EXetoC: it's when each triangle is assigned an index so that for meshes you don't have to store the vertices more than once per face |
| 14:53:00 | * | fundamental2 joined #nimrod |
| 14:55:13 | dom96 | hi fundamental2 |
| 14:55:28 | fundamental2 | dom96: hello |
| 14:55:35 | * | fundamental2 is now known as fundamental |
| 14:56:03 | BitPuffin | wouldn't it feel strange to have a game that would track your distance to the screen and adjust the FOV accordingly? haha |
| 14:56:57 | dom96 | That would actually be cool and quite possible with a kinect |
| 14:57:21 | BitPuffin | yeah it would be cool but it would probably cause nausea haha |
| 15:03:01 | dom96 | yeah, that's the challenge heh |
| 15:07:57 | EXetoC | BitPuffin: im a nub. also, I blame the wording :p |
| 15:08:35 | BitPuffin | EXetoC: the wording makes perfect sense when you know what it is :P |
| 15:28:14 | * | travisbrady joined #nimrod |
| 15:31:49 | BitPuffin | okay we've got perspective projection! |
| 15:32:35 | dom96 | ELI5 |
| 15:33:24 | dom96 | what that is |
| 15:33:33 | BitPuffin | dom96: ? |
| 15:33:40 | dom96 | explain like i'm five |
| 15:34:32 | BitPuffin | hahaha |
| 15:34:43 | BitPuffin | dom96: you wanna know what perspective projection is? |
| 15:34:59 | dom96 | yes |
| 15:35:06 | BitPuffin | you don't know? |
| 15:35:22 | BitPuffin | do you know what orthographic projection is? |
| 15:35:29 | dom96 | nope lol |
| 15:35:32 | BitPuffin | haha |
| 15:35:34 | BitPuffin | well okay |
| 15:35:37 | BitPuffin | open blender |
| 15:35:45 | BitPuffin | press 5 on the numpad |
| 15:35:57 | BitPuffin | and you will toggle between orthographic and perspective projection :P |
| 15:36:19 | * | dom96 can't be bothered installing blender |
| 15:36:22 | dom96 | I'll just google it |
| 15:36:31 | BitPuffin | http://db-in.com/blog/wp-content/uploads/2011/03/projection_example.gif |
| 15:36:33 | BitPuffin | dom96: ^ |
| 15:37:25 | dom96 | I see. |
| 15:37:41 | BitPuffin | here you can see the details of how it works http://www.arcsynthesis.org/gltut/Positioning/Tut04%20Perspective%20Projection.html |
| 15:40:25 | * | dom96 seriously needs to play around with OpenGL |
| 15:41:41 | * | mflamer joined #nimrod |
| 15:44:41 | BitPuffin | dom96: http://open.gl |
| 15:46:01 | dom96 | BitPuffin: thanks |
| 15:47:24 | OrionPKM | oh, nice site |
| 15:48:44 | OrionPKM | dom96 orthogonal is useful for directional shadow mapping |
| 15:49:14 | OrionPKM | i.e. shadow maps cast from a directional light |
| 15:49:51 | BitPuffin | ELH5 |
| 15:52:08 | OrionPKM | :P |
| 15:55:15 | * | dirkk0 joined #nimrod |
| 15:55:34 | Mat3 | ciao |
| 15:55:49 | * | Mat3 quit (Quit: Verlassend) |
| 16:00:28 | BitPuffin | rotations added |
| 16:00:40 | BitPuffin | however not around arbitrary axis or point yet |
| 16:10:17 | dom96 | BitPuffin: Can you show us a screenshot? |
| 16:11:32 | BitPuffin | dom96: maybe later if I manage to get the terrain rendering working tonight |
| 16:11:48 | dom96 | cool |
| 16:11:57 | * | dirkk0 quit (Read error: Connection reset by peer) |
| 16:12:35 | * | travisbrady quit (Quit: travisbrady) |
| 16:13:46 | * | dirkk0 joined #nimrod |
| 16:14:02 | BitPuffin | dom96: right now I'm only adding the matrix transformations so that I can get going with the rendering |
| 16:14:19 | OrionPKM | procedural terrain generation? |
| 16:15:13 | BitPuffin | OrionPKM: yeah later but today only rendering |
| 16:15:24 | OrionPKM | mm, ok |
| 16:15:36 | BitPuffin | hmm |
| 16:15:53 | BitPuffin | proc rotateAround(point, angle) or rotateAround(angle, point) ? |
| 16:17:55 | * | zielmicha joined #nimrod |
| 16:19:20 | EXetoC | why not just rotate? |
| 16:19:27 | EXetoC | pt.rotate(angle) ? |
| 16:22:42 | BitPuffin | EXetoC: I don't think it's as clear what's happening there |
| 16:23:09 | * | mflamer quit (Ping timeout: 272 seconds) |
| 16:23:23 | BitPuffin | some NEWBS might go "Why would you rotate a point ©_©" |
| 16:26:18 | BitPuffin | EXetoC: or, one way wone could do it would be to make it so that you write "around(pt).rotate(angle)" |
| 16:27:11 | BitPuffin | but that's not gonna be intuitive |
| 16:27:14 | BitPuffin | even if it reads nice |
| 16:27:20 | BitPuffin | but when glossing the api |
| 16:27:32 | BitPuffin | some NEWBS might go "What is around ©_©" |
| 16:28:13 | EXetoC | isn't it sort of like "rotate this point around an angle"? would that be an accurate description? |
| 16:29:40 | BitPuffin | EXetoC: no it's when you use the point as the thing you rotate around |
| 16:30:46 | EXetoC | I don't follow. someone with more experience should chime in |
| 16:31:26 | BitPuffin | EXetoC: basically think of it as the center of mass |
| 16:31:36 | BitPuffin | kind of at least |
| 16:31:38 | * | girvo joined #nimrod |
| 16:31:58 | BitPuffin | if you rotate an object in SPACE!!! it will rotate around it's center of mass |
| 16:32:10 | BitPuffin | but say you want the center of mass to be the earth |
| 16:32:31 | BitPuffin | as you might wanna do if you wanna rotate the moon around the earth |
| 16:32:48 | girvo | question: are the idetools fast enough to be run in real-time? I'm working on QSciTE at the moment, and am thinking about better integration |
| 16:32:51 | BitPuffin | anyways I'm gonna call them rotateAround rotatexAround etc |
| 16:33:35 | BitPuffin | EXetoC: makes sense? |
| 16:33:47 | BitPuffin | orbiting |
| 16:35:12 | girvo | so trying to decide the right way to go about it |
| 16:38:41 | EXetoC | BitPuffin: yes |
| 16:39:02 | EXetoC | BitPuffin: it's similar in unity apparently: "transform.RotateAround( renderer.bounds.center, transform.TransformDirection(Vector3.up), angle)" |
| 16:40:22 | dom96 | girvo: To me they still seem a bit too slow, but I haven't tested them recently. Play around with CAAS (Compiler as a service) and see if it's fast enough for you. |
| 16:40:32 | EXetoC | BitPuffin: "c2nim you bad muthafucka" have you confirmed that your approach works correctly? :p |
| 16:40:48 | girvo | dom96: will do, cheers |
| 16:40:58 | BitPuffin | EXetoC: in portaudio? |
| 16:41:01 | EXetoC | ya |
| 16:41:08 | EXetoC | dom96: it is? have you tested on any large projects? |
| 16:41:12 | BitPuffin | I haven't played any sound yet |
| 16:41:15 | BitPuffin | but it doesn't crash xD |
| 16:41:24 | EXetoC | it seemed to be fairly fast in my case, but then again my project is pretty small still |
| 16:41:28 | EXetoC | ok |
| 16:41:29 | girvo | dom96: Oh! Neat! |
| 16:41:35 | dom96 | EXetoC: I think I tested it on Aporia. |
| 16:42:09 | dom96 | But it was a long time ago now, so there is a chance the speed has improved greatly. |
| 16:42:10 | EXetoC | dom96: got a KLOC estimate? |
| 16:42:16 | girvo | dom96: that's actually pretty cool. I'm currently working on QSciTE and fiddling with clangs similar tools, and remembered that nimrod had something but CAAS is another level |
| 16:42:16 | EXetoC | oh |
| 16:43:40 | * | IrvMG joined #nimrod |
| 16:43:58 | * | XAMPP joined #nimrod |
| 16:46:29 | girvo | dom96: am going to have a play with it some more once I've fixed a few bugs in QSciTE. And give it an actual release DMG already, it hasn't had a build in 18 months but i finally got it compiling tonight |
| 16:46:56 | girvo | if only Nimrod could interface with Obj-C/Cocoa... one can dream, can't they? |
| 16:47:12 | C0C0 | damn cocoa |
| 16:47:19 | C0C0 | allways triggers my highlighting |
| 16:47:27 | girvo | haha sorry! :) |
| 16:47:28 | * | IrvMG_ joined #nimrod |
| 16:47:33 | C0C0 | :P |
| 16:47:55 | * | IrvMG quit (Ping timeout: 245 seconds) |
| 16:48:12 | girvo | but seriously, screw it. why couldn't they have done a nice C API, then built the Mac idioms in Obj-C on top... then you get language binding for free(ish) |
| 16:48:45 | IrvMG_ | Hello |
| 16:51:43 | NimBot | dom96/jester master 5c5bd96 Hitesh Jasani [+0 ±1 -0]: Update OSErrorMsg usage due to nimrod 0.9.4 deprecation |
| 16:51:43 | NimBot | dom96/jester master 82bd1c1 Dominik Picheta [+0 ±1 -0]: Merge pull request #6 from hiteshjasani/master... 2 more lines |
| 16:51:58 | BitPuffin | girvo: it can interface with obj-c |
| 16:52:00 | BitPuffin | and cocoa |
| 16:52:02 | BitPuffin | if you write the binding |
| 16:52:09 | BitPuffin | nimrod can compile to obj-c |
| 16:52:27 | girvo | BitPuffin: funny you say that, I just started looking at other bridges and wanted to see how painful a binding would be... |
| 16:52:39 | C0C0 | BitPuffin: fuuu :P |
| 16:53:00 | girvo | BitPuffin: Considerng that Nimrod and Obj-C are probably equally powerful, it might be doable. |
| 16:53:20 | C0C0 | girvo: everything is turing complete - even magic the gathering :P |
| 16:53:31 | BitPuffin | C0C0: ? |
| 16:53:36 | girvo | The only issue you have is that C0C0 (:D) has its weird idioms which translating to equiv Nimrod would be difficult |
| 16:54:32 | C0C0 | girvo: :P |
| 16:54:37 | girvo | guess its time to get my hands dirty and see how this might work.. |
| 16:54:59 | C0C0 | BitPuffin: cocoa will always trigger my username highlighting |
| 16:56:11 | EXetoC | cocoa nom |
| 16:56:29 | C0C0 | :P |
| 16:56:34 | girvo | brb I feel like a hot chocolate now |
| 16:56:40 | * | brson joined #nimrod |
| 16:57:46 | BitPuffin | C0C0: really? but your name is C0C0 not cocoa |
| 16:57:53 | BitPuffin | girvo: me too |
| 16:58:12 | C0C0 | but people tend to write coco when they are using clients without tabcompletion |
| 16:59:04 | EXetoC | well they fail at life |
| 16:59:10 | C0C0 | ^^ |
| 16:59:50 | girvo | BitPuffin: excluding c2nim, do you know if there are any docs (its ok if they're incomplete) about writing bindings to stuff other than ANSI C? |
| 17:00:01 | * | travisbrady joined #nimrod |
| 17:01:03 | BitPuffin | girvo: there is an example of c++ wrapping in the repo |
| 17:01:07 | BitPuffin | I don't know much else |
| 17:01:13 | girvo | BitPuffin: Sweet, that'd be a start. Cheers |
| 17:02:27 | girvo | HAH. It's an Irrlicht example, neat! my first 3d engine I ever played with, back in the day |
| 17:03:08 | EXetoC | but you might get an error saying that abs, sprintf etc are missing |
| 17:03:17 | EXetoC | you do have to choose the cpp target, right? |
| 17:03:39 | girvo | Sweet, I didn't know there was a obj-c target for nim |
| 17:04:17 | girvo | I'm going to have to play with this. That's awesome. This language man, I keep thinking I'd need something, only to find out is actually already there! |
| 17:05:59 | EXetoC | the objc target actually works though. that's great |
| 17:06:11 | girvo | seriously? oh heck yes EXetoC |
| 17:06:14 | EXetoC | well, I wonder how many people will use it, but still |
| 17:06:39 | EXetoC | I'll try to report the cpp bugs this week |
| 17:06:57 | girvo | of course, cocoa (sorry C0C0 lol) is such a big target to write bindings for (so much that RubyMotion makes a business out of it), but its certainly going to be fun to hack on |
| 17:07:25 | C0C0 | :P |
| 17:07:41 | girvo | cause theres an objc target, its actually feasible, though. that's crazy :/ lol |
| 17:08:11 | * | IrvMG_ quit () |
| 17:10:07 | girvo | only major issue I can think of is dealing with it's ARC; I can see issues using nimrod's GC on top of it (say, by using a nimrod lib with the bindings) |
| 17:12:49 | girvo | *giggle* now I'm picturing using nimrods DRC instead of cocoa's ARC, for cocoa itself. one can dream, right |
| 17:13:10 | girvo | anyway, i should go to bed, but thanks so much everyone. stoked to hear the obj-c target exists :D |
| 17:17:26 | EXetoC | c(:)-< l8r |
| 17:18:20 | * | girvo quit (Quit: Textual IRC Client: www.textualapp.com) |
| 17:19:50 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 17:23:36 | BitPuffin | lol |
| 17:23:40 | BitPuffin | this proc |
| 17:25:08 | BitPuffin | it's literally from hell |
| 17:25:14 | EXetoC | wot |
| 17:25:54 | * | MFlamer joined #nimrod |
| 17:26:10 | MFlamer | Hi all |
| 17:26:42 | BitPuffin | hey MFlamer |
| 17:27:00 | BitPuffin | EXetoC: you don't know what you are getting in to with writing your own lib :P |
| 17:27:09 | BitPuffin | and you may not copy paste this proc! |
| 17:27:27 | BitPuffin | so much blood sweat and tears has been spent writing this proc |
| 17:27:54 | EXetoC | I have really low requirements |
| 17:28:38 | BitPuffin | EXetoC: so you don't need the ability to rotate around an arbitrary axis? |
| 17:29:25 | EXetoC | it's 2D now, but I think I have something like that in the matrix module for some other project |
| 17:29:46 | BitPuffin | ah |
| 17:29:51 | BitPuffin | well 2d rotation is easy |
| 17:30:26 | EXetoC | it was for 3 dimensions |
| 17:30:46 | BitPuffin | what was |
| 17:31:08 | EXetoC | that matrix function |
| 17:31:13 | EXetoC | but I'll have to confirm that it does indeed work |
| 17:31:54 | BitPuffin | EXetoC: you have a matrix for rotation about arbitrary axis in 3d? |
| 17:34:21 | * | OrionPKM quit (Remote host closed the connection) |
| 17:38:35 | EXetoC | BitPuffin: maybe https://gist.github.com/EXetoC/c19595131de44b674ce2 |
| 17:39:04 | BitPuffin | EXetoC: that's rust |
| 17:39:09 | EXetoC | yes |
| 17:39:29 | EXetoC | I didn't say it was a nimrod project |
| 17:39:30 | BitPuffin | EXetoC: but wth there is no angle o.O |
| 17:39:40 | BitPuffin | anyways here is mine https://gist.github.com/BitPuffin/7809816 |
| 17:39:48 | BitPuffin | and yes I plan to optimize it by storing the results haha |
| 17:39:54 | EXetoC | well it should be local then |
| 17:40:11 | * | OrionPKM joined #nimrod |
| 17:40:14 | BitPuffin | EXetoC: well how can you construct a rotation matrix without an angle |
| 17:40:16 | dom96 | We should really start writing down these pygments issues. |
| 17:40:32 | dom96 | and then fix them |
| 17:41:27 | BitPuffin | dom96: pygment? |
| 17:41:36 | dom96 | BitPuffin: the syntax highlighter github uses |
| 17:41:44 | BitPuffin | dom96: ah yeah |
| 17:41:47 | BitPuffin | looks like shit |
| 17:44:18 | dom96 | huh wait. Shouldn't that be 0'f32? |
| 17:44:33 | EXetoC | BitPuffin: actually, it's apparently only used here "fn from_components(pos: V3, scale: V3, rot: V3) -> M {" |
| 17:44:47 | BitPuffin | dom96: doesn't matter if the first elements is float32s |
| 17:44:50 | BitPuffin | but yeah there are mistakes |
| 17:44:58 | BitPuffin | I'm currently rewriting it to be more efficient |
| 17:45:43 | dom96 | No, I mean. You wrote '0f32', I thought it must be '0'f32' |
| 17:46:09 | BitPuffin | dom96: no it's fine to just write 0f32 |
| 17:47:32 | dom96 | interesting |
| 17:48:32 | dom96 | So yeah, add any bugs you see to: https://github.com/Araq/Nimrod/wiki/Pygments-issues |
| 17:49:26 | BitPuffin | what's more efficient, store an element from an array in a variable if it is used many times or just index it? |
| 17:51:03 | * | DAddYE joined #nimrod |
| 17:51:41 | OrionPKM | how many times? |
| 17:52:01 | * | DAddYE quit (Remote host closed the connection) |
| 17:52:13 | * | DAddYE joined #nimrod |
| 17:53:03 | BitPuffin | OrionPKM: 6! |
| 17:54:02 | OrionPKM | dom96 httpserver kinda sucks ;P |
| 17:54:12 | dom96 | I agree |
| 17:54:23 | OrionPKM | i'm getting requests taking 57 seconds |
| 17:54:30 | OrionPKM | then i hit the same request again and it's 1 second |
| 18:03:19 | BitPuffin | now the proc is a bit better |
| 18:03:48 | BitPuffin | https://gist.github.com/BitPuffin/7810239 |
| 18:05:27 | Varriount | Hey dom96, may I add a page to the wiki on tips for python programmers coming to nimrod? |
| 18:05:54 | BitPuffin | Varriount: of course |
| 18:05:55 | dom96 | Varriount: Sure. Add whatever you want, it is a wiki after all. |
| 18:06:35 | Varriount | I mean, the list isn't huge, but things like tuple unpacking, iterators, etc present some gotchas |
| 18:07:46 | BitPuffin | Varriount: it is also useful for a nimrod programmer looking at how things are done in python |
| 18:08:43 | dirkk0 | now that you mention it - it would be cool to have python/nimrod side by side examples. |
| 18:09:11 | EXetoC | BitPuffin: it's an absolute rotation, so only a direction is needed |
| 18:09:22 | Varriount | dirkk0, well, I've had thoughts of doing something like what scala's tutorials are planned to do. |
| 18:09:24 | EXetoC | so yeah that's not the kind of rotation you were referring to |
| 18:09:33 | Varriount | Tutorials for people coming from python, java, etc |
| 18:09:54 | BitPuffin | anyways would https://gist.github.com/BitPuffin/7810239 be faster if I switched axis[0] with x, axis[1] with y etc? |
| 18:10:01 | Varriount | However such a project is too ambitious, and the tutuorials already present are fine. |
| 18:10:16 | Varriount | BitPuffin, benchmark time! |
| 18:10:24 | BitPuffin | Varriount: I don't have time for benchmark ;_; |
| 18:10:54 | Varriount | :< |
| 18:11:15 | BitPuffin | meh |
| 18:11:17 | BitPuffin | I'll leave it |
| 18:11:22 | BitPuffin | gotta get on |
| 18:12:23 | EXetoC | yeah optimize later srsly :p |
| 18:12:23 | BitPuffin | EXetoC: I'm not even sure what you mean o.O |
| 18:12:28 | BitPuffin | yup |
| 18:12:42 | BitPuffin | lol |
| 18:12:49 | BitPuffin | didn't even check if it compiled before I pushed |
| 18:12:52 | BitPuffin | but it did! |
| 18:14:14 | dirkk0 | Varriount: I am not familiar what the Scala guys do ...? |
| 18:14:18 | * | travisbrady quit (Quit: travisbrady) |
| 18:15:54 | * | Durz0 joined #nimrod |
| 18:16:23 | Araq | hi Durz0 welcome |
| 18:16:37 | Durz0 | hello |
| 18:19:18 | EXetoC | BitPuffin: well, I showed you the definition of from_components. the matrix is used like this https://gist.github.com/EXetoC/436a67b0200ea6932571 |
| 18:23:17 | Araq | BitPuffin: axis[0] vs x shouldn't matter |
| 18:25:29 | * | travisbrady joined #nimrod |
| 18:28:22 | EXetoC | I managed to implement mouse look in that project, but I gave up when I couldn't figure out culling was one unit off :p |
| 18:28:55 | EXetoC | *figure out why |
| 18:30:31 | EXetoC | as in stuff <= 1 unit away from the camera would disappear |
| 18:35:40 | BitPuffin | Araq: ah, well then I might change it to x in the future because it is more readable I think |
| 18:35:42 | * | CarpNet quit (Quit: Leaving) |
| 18:36:30 | BitPuffin | EXetoC: I'll look in to that once upon a time |
| 18:41:38 | BitPuffin | Araq: you are gonna have to market nimrod to more london programmer/gamedev shops so that I can get a jerb there |
| 18:43:24 | Varriount | Bah, they're all too busy drooling over Unity Engine :/ |
| 18:43:47 | BitPuffin | EXetoC: why are you coding in rust ;) you are even the one who made me abandon rust! hypocrite! |
| 18:43:52 | BitPuffin | Varriount: yeah :/ |
| 18:44:02 | BitPuffin | I plan to change that though |
| 18:44:06 | BitPuffin | but it's gonna take a while |
| 18:44:26 | Varriount | BitPuffin, if you have to make a framework, make one that follow's libGDX's api design |
| 18:44:44 | Varriount | http://libgdx.badlogicgames.com/ |
| 18:45:06 | Varriount | Yes, it's java, however the api itself is both easy to use and powerful. |
| 18:45:34 | Varriount | (At least, for 2d stuff, I haven't worked with the 3d api's in a while) |
| 18:45:41 | BitPuffin | Varriount: yeah I already know about libgdx |
| 18:45:49 | BitPuffin | I have larger plans though |
| 18:46:17 | EXetoC | BitPuffin: I told you it was an old project |
| 18:46:25 | BitPuffin | EXetoC: port it! |
| 18:47:43 | Varriount | BitPuffin, look down at the bottom of that page, the credits for the site |
| 18:47:44 | EXetoC | I might port bits and pieces |
| 18:47:59 | BitPuffin | Varriount: let me guess, you? |
| 18:48:06 | Varriount | Nope |
| 18:48:12 | Varriount | "HTML/CSS by bitowl" |
| 18:48:15 | * | Mat3 joined #nimrod |
| 18:48:20 | Mat3 | hi all |
| 18:48:34 | BitPuffin | Varriount: and? |
| 18:48:54 | Araq | hi Mat3 |
| 18:48:54 | Varriount | BitPuffin, it looks like you have a relative. :3 |
| 18:49:11 | BitPuffin | aaaaaahhhhh :D |
| 18:49:39 | BitPuffin | Mat3 is in our shaders, snatchin our vertices up |
| 18:50:31 | BitPuffin | Varriount: maybe he got inspired by my nick, I've been in #libgdb now and then |
| 18:51:18 | Mat3 | hi Araq,Varriount,BitPuffin |
| 18:52:05 | BitPuffin | gdx |
| 18:52:37 | BitPuffin | hey Mat3! |
| 18:52:57 | BitPuffin | I'm hungryyyyyyyy |
| 18:53:05 | BitPuffin | waiting for my burger |
| 18:53:13 | Mat3 | BitPuffin: Try to misuse GPU's for heavy vectored computations ? :D |
| 18:53:31 | Mat3 | (with DirectX) |
| 18:54:02 | BitPuffin | Mat3: hahaha. Well doing vector stuff on GPU is alright, but not with D3d :P |
| 18:54:57 | BitPuffin | bah |
| 18:55:01 | Mat3 | it's possible however |
| 18:55:14 | BitPuffin | can't decide which notation I'm gonna use for shearing/skewing |
| 18:55:42 | BitPuffin | they can take either one parameter or two |
| 18:55:48 | BitPuffin | Mat3: of course but microsoft |
| 18:57:07 | Mat3 | Araq: I vote for including MAP_ANON to the POSIX wrapper (for conventional misuse of mmap) |
| 18:59:26 | Araq | well make a pull request |
| 19:03:20 | BitPuffin | I'll go with the 2 parameter one |
| 19:04:00 | BitPuffin | question is if I should call it shear or skew |
| 19:04:39 | BitPuffin | shear I think |
| 19:05:36 | Mat3 | Araq: ok, I need to reactivate my GIT account for doing so ? |
| 19:07:05 | Araq | yeah |
| 19:07:44 | Araq | hi fundamental welcome |
| 19:07:58 | * | Araq keeps seeing new nicks |
| 19:09:58 | BitPuffin | burger!!! |
| 19:12:11 | Mat3 | ciao, see you guys |
| 19:12:14 | * | Mat3 quit (Quit: Verlassend) |
| 19:13:05 | * | boydgreenfield joined #nimrod |
| 19:18:05 | * | tylere joined #nimrod |
| 19:18:15 | tylere | So I'm getting a really confusing compiler error |
| 19:18:21 | tylere | so have this code: https://gist.github.com/tylereaves/7811511 |
| 19:18:31 | tylere | prob001.nim(3, 20) Error: type mismatch: got (bool, bool) |
| 19:18:50 | dom96 | Now the new record is 61. :) |
| 19:18:53 | MFlamer | Who was it here who was trying to use nimrod for embedded applications? |
| 19:19:20 | MFlamer | Maybe a special backend or minimal stdlib or something? |
| 19:19:36 | dom96 | tylere: replace the "||" with "or" |
| 19:19:43 | MFlamer | was that Mat3? |
| 19:20:51 | tylere | dom96: ahh, that works |
| 19:21:07 | tylere | dom96: I still might file an issue over it as that error message is very unhelpful |
| 19:21:49 | tylere | in particular, if the compiler sees a type mismatch it should imo always report both the _found_ type and the _expected_ type |
| 19:22:05 | MFlamer | Thought it would be pretty cool to command this little chip with nimrod http://www.mouser.com/pdfdocs/INDP28495_Kinetis_L_Series_KL02_FSv4HR.pdf |
| 19:22:12 | dom96 | tylere: Did it not list functions after that error? |
| 19:22:43 | tylere | dom96: nope |
| 19:22:43 | tylere | https://gist.github.com/tylereaves/7811582 |
| 19:22:48 | tylere | that's the entireity of compiler output |
| 19:23:38 | dom96 | tylere: In that case I agree, it could definitely be improved. |
| 19:26:17 | tylere | I'll open a bug |
| 19:27:24 | dom96 | tylere: thanks :) |
| 19:34:31 | dom96 | I edited your formatting a bit |
| 19:34:40 | * | isenmann quit (Ping timeout: 264 seconds) |
| 19:40:16 | * | Hannibal_Smith joined #nimrod |
| 19:48:53 | * | MFlamer quit (Read error: Connection reset by peer) |
| 19:50:13 | * | MFlamer joined #nimrod |
| 19:53:33 | Araq | aha! |
| 19:53:41 | BitPuffin | snoooooooooooooooooooooooooooooooooooooooooooow!!!!! |
| 19:54:01 | Araq | BitPuffin: think about your signal to noise ratio please |
| 19:59:53 | Araq | so ... when there is an internal error in the "compiles" context the compiler doesn't tell you the error message |
| 20:00:03 | Araq | for obvious reasons |
| 20:08:47 | Varriount | Araq, sadly, I can't see the obvious reasons, what are they? |
| 20:09:33 | BitPuffin | ping zahary_ |
| 20:09:58 | BitPuffin | Araq: hm? |
| 20:10:18 | Araq | Varriount: 'compiles' is supposed to return false when it doesn't compile. error messages should not be emitted |
| 20:10:40 | Araq | we use the holzhammer method to suppress the error messages |
| 20:10:58 | BitPuffin | does the delegator pragma only work on procs? Because I want to do compile time evaluation :( |
| 20:11:13 | Varriount | Delegator pragma? |
| 20:11:51 | BitPuffin | http://build.nimrod-lang.org/docs/manual.html#delegator-pragma |
| 20:11:53 | BitPuffin | Varriount: ^ |
| 20:12:53 | Varriount | Ooh, interesting. |
| 20:13:10 | * | Varriount should really read the build version of the manual |
| 20:16:44 | BitPuffin | Araq: shouldn't a when statement work on a string{lit} parameter? |
| 20:18:38 | Araq | no |
| 20:18:41 | Araq | it shouldn't |
| 20:18:53 | Araq | use expr[string] for that |
| 20:19:03 | Araq | and I really hate expr[string] |
| 20:19:10 | Araq | it makes no sense |
| 20:19:37 | Araq | an expression of type "string" is obviously an expression |
| 20:19:49 | Araq | so what should expr[string] mean? |
| 20:21:12 | * | brson quit (Ping timeout: 240 seconds) |
| 20:21:36 | BitPuffin | Araq: dunno, I thought string{lit} would make sense in this case |
| 20:22:26 | Araq | why? string{lit} is a string literal, it doesn't make it generic so you can't look at the passed value |
| 20:23:04 | BitPuffin | Araq: who said anything about generics? |
| 20:24:22 | Araq | well if you don't have an instantation per passed string literal how can a 'when' statement work? |
| 20:25:14 | BitPuffin | Araq: well it worked when it was a template |
| 20:25:16 | BitPuffin | Error: type mismatch: got (TVector[int, range 0..4(int)]) but expected 'expr[string]' |
| 20:25:18 | BitPuffin | wtf |
| 20:25:25 | BitPuffin | proc `()`[T, I](str: expr[string], vec: TVector[T, I]): expr {.delegator.} = |
| 20:25:35 | BitPuffin | assert vec3.rgbbg == [1, 3, 37, 37, 3] |
| 20:28:20 | Araq | well of course it worked when it was a template |
| 20:28:50 | * | zielmicha1 joined #nimrod |
| 20:28:56 | BitPuffin | "The delegators can be any callable symbol type (procs, templates, macros) depending on the desired effect" um.. lies? delegator on a template yields invalid pragma |
| 20:29:11 | Araq | a template gives you the required instantiations |
| 20:29:30 | Araq | why is that hard to understand? |
| 20:30:00 | * | zielmicha quit (Ping timeout: 245 seconds) |
| 20:30:28 | BitPuffin | Araq: so when only works in generic contexts? |
| 20:30:28 | Araq | BitPuffin: ever thought that the feature is in development? |
| 20:30:42 | BitPuffin | Araq: yes it's what I'm thinking right now |
| 20:30:51 | Araq | 'when' works when the expression can be evaluated at compile time |
| 20:31:07 | BitPuffin | Araq: yes and literals are known at compile time aren't they? |
| 20:31:17 | Araq | string{lit} is not sufficient to provide a compile time context |
| 20:31:33 | BitPuffin | okay why not? |
| 20:31:39 | Araq | and now I'll leave you alone and think about it because I can only repeat myself |
| 20:32:14 | BitPuffin | well |
| 20:32:46 | BitPuffin | I'm gonna take it as procs (except for generic parameters) aren't instantiated per argument so that's why it doesn't work |
| 20:33:08 | BitPuffin | because I guess it is the point of procs? :P |
| 20:33:42 | Varriount | BitPuffin, I'd be quiet if I were you, lest you get backhanded by Araq all the way to Pluto |
| 20:34:17 | Varriount | And I prefer my Puffins on Earth, thankyouverymuch |
| 20:34:17 | BitPuffin | Varriount: but I'm like eminem |
| 20:34:50 | * | zielmicha1 is now known as zielmicha |
| 20:35:39 | * | BitPuffin thinks there should be a deprecated pragma |
| 20:36:03 | Varriount | There is. The compiler uses it. |
| 20:38:18 | OrionPKM | there should also be some sort of importc pragma or something |
| 20:40:18 | * | Varriount slaps OrionPKM and BitPuffin around a bit with an electric mackeral |
| 20:40:34 | BitPuffin | OrionPKM: or a noSideEffects pragma |
| 20:42:39 | BitPuffin | Araq: think I found a bug :P |
| 20:42:58 | BitPuffin | /home/isak/src/nim/linagl/src/linagl/nimcache/linagl_vector.o: In function `vectorInit': |
| 20:43:01 | BitPuffin | linagl_vector.c:(.text+0x1092): undefined reference to `swizzleimpl_90827' |
| 20:43:36 | Varriount | BitPuffin, are you dealing with nested procs/iterators? |
| 20:43:42 | BitPuffin | Varriount: no |
| 20:43:54 | BitPuffin | this is just a compiletime proc being called from a template |
| 20:44:11 | Araq | well you use a compiletime proc at runtime |
| 20:44:19 | BitPuffin | Araq: no I don't |
| 20:44:39 | Araq | well report it then |
| 20:44:47 | BitPuffin | or at least not that I know of |
| 20:44:56 | Varriount | BitPuffin, if you use a compiletime proc in a template, doesn't the body the template passes use the proc? |
| 20:45:05 | BitPuffin | https://bitbucket.org/BitPuffin/linagl/src/fd8282dd461ee8082018e76715c0fcdf0316f014/src/linagl/vector.nim?at=default |
| 20:45:08 | BitPuffin | do you see anything? |
| 20:45:43 | BitPuffin | Varriount: probably not, otherwise there would be no point of compiletime procs? |
| 20:46:33 | Varriount | BitPuffin, do you have proof that the compiletime proc *runs* at compiletime? |
| 20:46:41 | Varriount | like, an echo statement or something? |
| 20:46:49 | BitPuffin | Varriount: once upon a time it worked? |
| 20:47:41 | Varriount | BitPuffin, it sounds like the compiletime proc is being left in the template body, uncalled |
| 20:49:16 | Araq | BitPuffin: I don't think it ever worked |
| 20:49:25 | Araq | I remember that error message and your complaining |
| 20:49:34 | BitPuffin | Araq: it did, the unittests used to pass once upon a time |
| 20:49:46 | Varriount | BitPuffin, did you comment out some tests? |
| 20:49:49 | BitPuffin | Araq: Well sure it looks familiar, but I know it used to work |
| 20:50:33 | Varriount | Instead of complaining, debug it. |
| 20:50:48 | BitPuffin | do I look like I have time for that |
| 20:50:53 | BitPuffin | I'm way behind my schedule |
| 20:50:57 | Varriount | You have time to complain about it. |
| 20:51:45 | Varriount | Turn on linedir -> open up c file that throws the error -> find the erroneous line -> put in bug report |
| 20:51:59 | BitPuffin | welp |
| 20:52:04 | BitPuffin | maybe by the end of the year |
| 20:52:11 | Varriount | -_- |
| 20:52:30 | BitPuffin | Varriount: complaining about it is quick and at least gets it on the radar |
| 20:52:35 | BitPuffin | debugging takes years |
| 20:52:49 | Varriount | BitPuffin, putting it in a bug report gets it on the radar |
| 20:52:57 | * | MFlamer quit (Ping timeout: 252 seconds) |
| 20:53:42 | BitPuffin | Varriount: okay I'll throw together the lamest bug report ever then |
| 20:54:11 | Varriount | Which I will then probably update with more info. Sigh. |
| 20:57:01 | * | radsoc joined #nimrod |
| 20:59:00 | BitPuffin | https://github.com/Araq/Nimrod/issues/711 there Varriount |
| 20:59:11 | * | Durz0 quit (Quit: WeeChat 0.4.0) |
| 20:59:31 | * | MFlamer joined #nimrod |
| 21:03:39 | Varriount | Odd, I would've expected gcc's semantic checking to catch that. |
| 21:08:08 | Varriount | BitPuffin, why does that procedure need to be called at compile time? |
| 21:08:44 | * | tylere quit (Remote host closed the connection) |
| 21:08:46 | Varriount | And if you say, "for speed" I will swim all the way over to Great Britain, find you, and give you a smack upside the head. |
| 21:08:57 | BitPuffin | Varriount: for speed |
| 21:09:06 | * | BitPuffin is not in the UK so it's safe |
| 21:09:34 | BitPuffin | Varriount: no but do you mean the whole template and everything or just that proc? |
| 21:09:49 | Varriount | Just that proc |
| 21:10:51 | Araq | well it should always be done at compile time, so that pragma is fine |
| 21:11:03 | * | brson joined #nimrod |
| 21:11:05 | Araq | no idea why the compiler is too stupid to not eval it at compile time |
| 21:11:20 | BitPuffin | Varriount: right, because I want it to be a compile time error |
| 21:11:25 | Araq | hi radsoc welcome |
| 21:11:36 | BitPuffin | when you specify a char that is not valid |
| 21:11:46 | BitPuffin | instead of a crash |
| 21:11:49 | radsoc | hi Araq thanks |
| 21:12:21 | BitPuffin | I guess it already is |
| 21:12:34 | BitPuffin | but it's unecessary to do the thing at runtime I think |
| 21:13:08 | Varriount | BitPuffin, don't arrays need instanciation when they are arguments? |
| 21:15:02 | BitPuffin | Varriount: guess that depends? this template returns an expr and doesn't modify the array |
| 21:15:23 | Varriount | But in the swizzleImp proc |
| 21:16:00 | BitPuffin | Varriount: since when does swizzleImpl take an array as an argument |
| 21:16:12 | BitPuffin | well unless you count the string |
| 21:16:15 | Varriount | No, but it returns one. |
| 21:16:33 | BitPuffin | and? |
| 21:16:50 | BitPuffin | really though EXetoC wrote this when I couldn't :P |
| 21:16:53 | Varriount | don't you have to do new(result)? or is that only for complex types/objects? |
| 21:17:07 | BitPuffin | Varriount: nah I don't think so |
| 21:18:10 | Araq | Varriount: new(result) is only for 'ref' |
| 21:18:28 | Varriount | Ah, ok. |
| 21:18:33 | MFlamer | Araq: who was it here who was using nimrod for imbedded applications? |
| 21:18:42 | MFlamer | embedded* |
| 21:18:43 | BitPuffin | I think Araq would have yelled by now if the code was wrong Varriount |
| 21:18:57 | BitPuffin | and I'm certain it worked |
| 21:19:02 | BitPuffin | like 99% |
| 21:19:10 | Araq | MFlamer: mat3 and some others who don't hang around here |
| 21:19:11 | Varriount | BitPuffin, yeah, but If I see something I don't understand, I ask how it works. |
| 21:19:11 | BitPuffin | EXetoC can verify |
| 21:19:18 | Varriount | That's how I learn things. |
| 21:19:21 | BitPuffin | Varriount: ah gotcha |
| 21:19:44 | Varriount | BitPuffin, I have a solution |
| 21:19:54 | MFlamer | ok, thanks |
| 21:19:57 | Varriount | remove the compiletime pragma. :3 |
| 21:20:03 | BitPuffin | Varriount: never |
| 21:21:00 | BitPuffin | no code should be generated for that proc |
| 21:21:13 | BitPuffin | it's only intended to be a helper for swizzling |
| 21:22:20 | Varriount | You can either spend the time coming up with a real fix, or patch it. Or, of course, have broken code :D |
| 21:23:10 | BitPuffin | Varriount: Well for now I'll leave it broken since I probably won't use swizzling much anyway because I can't get the proper syntax to work |
| 21:23:22 | BitPuffin | as you can see it is deprecated because of that |
| 21:23:35 | * | isenmann joined #nimrod |
| 21:23:37 | BitPuffin | and since it's an error in the compiler it will eventually get fixed |
| 21:23:45 | Varriount | I've heard the term before, but what is swizzling? |
| 21:24:15 | BitPuffin | v.xyzyzzzyyzyyzyzyyyzz |
| 21:27:20 | * | shodan45 joined #nimrod |
| 21:27:50 | dom96 | New record! |
| 21:27:53 | Araq | dom96: is ... |
| 21:27:58 | dom96 | hello isenmann |
| 21:28:01 | Araq | ha! was about to ask |
| 21:28:19 | BitPuffin | dom96: hahaha man you are sitting there like a hawk, not saying anything, just staring at the numbers |
| 21:28:41 | Araq | well he needs to enter the numbers every 108 minutes |
| 21:28:44 | BitPuffin | dom96: no go update NimBot to do this for you instead of having to keep count :P |
| 21:28:49 | dom96 | 4 8 15 16 23 42 |
| 21:28:53 | dom96 | Execute |
| 21:28:58 | BitPuffin | dom96 is stanley |
| 21:29:03 | * | dom96 is Desmond |
| 21:29:09 | BitPuffin | dom96 is dead |
| 21:29:11 | BitPuffin | what |
| 21:29:40 | BitPuffin | woa holy fuck |
| 21:29:46 | dom96 | Araq: I'm liking these Lost references from you heh |
| 21:29:57 | BitPuffin | the lamps keep on twitching |
| 21:29:59 | Araq | dom96: seems nobody else does |
| 21:30:05 | BitPuffin | oh it's currently a storm btw |
| 21:30:06 | Araq | ;-) |
| 21:30:08 | BitPuffin | so if I die |
| 21:30:13 | BitPuffin | you heard it first |
| 21:30:24 | shodan45 | how is the javascript target (backend?) coming along? |
| 21:30:27 | dom96 | BitPuffin: Nooooo, you can't :( |
| 21:30:56 | BitPuffin | dom96: oh right! I'm immortal! |
| 21:30:56 | dom96 | shodan45: I don't think it's currently the top priority so it's not really being worked on. |
| 21:31:53 | Araq | shodan45: I consider it "quite stable". I don't think there is much (if any) production code using it though. |
| 21:32:25 | dom96 | What we need is to get the tester to run JS tests. |
| 21:32:39 | BitPuffin | probably because the dom module is from the rennaisance |
| 21:32:39 | Varriount | And generate documentation. |
| 21:32:42 | dom96 | But first nimbuild is in need of improvement... |
| 21:32:54 | Varriount | *looks at dom96* |
| 21:33:08 | Araq | well I did run quite some tests and it worked quite well |
| 21:33:09 | shodan45 | dom96, Araq: I ask because the recent Scala.js stuff looks *very* tempting ;) |
| 21:33:34 | BitPuffin | shodan45: even for an AI? |
| 21:33:36 | Araq | shodan45: no! please stay! if you encounter bugs they are in general trivial to fix |
| 21:33:44 | dom96 | shodan45: reactormonk probably has the most experience with the JS backend. AFAIK he didn't run into any problems. |
| 21:33:59 | BitPuffin | Araq: but the dom module.. THE DOM MODULE |
| 21:34:05 | shodan45 | link, fyi: http://www.scala-js.org/ |
| 21:34:22 | reactormonk | shodan45, didn't use too much |
| 21:34:38 | Varriount | BitPuffin, call me a simpleton if you must, but what does this do exactly/meant to do? -> "0.. <str.len" |
| 21:34:53 | shodan45 | it's really the JS interoperability that intrigues me |
| 21:35:04 | dom96 | Varriount: It's the same as: 0 .. str.len-1 |
| 21:35:05 | reactormonk | shodan45, you can get the same with nimrod |
| 21:35:15 | BitPuffin | Varriount: I think it does 0..str.len-1 |
| 21:35:24 | Varriount | So, it produces a range type? |
| 21:35:26 | BitPuffin | dom96: shh |
| 21:35:30 | reactormonk | the only nasty stuff is that nimrod wants you to use types, so you'll have to write them yourself. I used some ruby scripts to convert from doxygen to JS |
| 21:35:36 | Araq | shodan45: "ArrayIndexOutOfBoundsException are not checked" well they are in Nimrod even for the JS backend |
| 21:35:57 | BitPuffin | SMACK BOOM BANG!!! ARAQ IS ON FIRE!! |
| 21:35:59 | reactormonk | shodan45, https://github.com/reactormonk/nim-kwin |
| 21:36:26 | BitPuffin | yes I am overworked |
| 21:36:34 | dom96 | shodan45: It seems that scala.js is even less stable than Nimrod's JS backend. They do say that it is still experimental. |
| 21:37:16 | Araq | and not supported by TypeState so it's not "official" |
| 21:37:27 | BitPuffin | that's what came to my mind too dom96, it's like we're twins |
| 21:38:07 | shodan45 | reactormonk: uhhh holy wtf, are those bindings (is that the right word?) to script KDE's KWin's JS stuff? |
| 21:38:16 | dom96 | BitPuffin: That's all the evidence I need. We are now twins! |
| 21:38:23 | BitPuffin | dom96: yay! |
| 21:39:12 | dom96 | BitPuffin: Now transfer your OpenGL knowledge to me through our secret twin telepathic link. |
| 21:39:14 | EXetoC | Varriount: see the definition of `..` and ´<´ in system.nim |
| 21:39:24 | Varriount | BitPuffin, ok, this is odd. static: echo(repr(type(0.. <str.len))) produces "int", yet "static: echo(repr(0.. <str.len))" produces (0, 4) |
| 21:39:40 | EXetoC | Varriount: < is syntactic sugar for -1, and .. constructs a TSlice[Type] |
| 21:40:05 | BitPuffin | dom96: but it's encrypted and I lost the key |
| 21:40:08 | * | faassen left #nimrod (#nimrod) |
| 21:40:23 | EXetoC | actually, there's also a `..` iterator rather than proc, which is why it works in conjunction with 'for' |
| 21:40:40 | dom96 | BitPuffin: Damn. Just need to brute force it then. |
| 21:40:51 | BitPuffin | dom96: yeah it is currently transferring |
| 21:41:17 | Varriount | EXetoC, then why is the type 'int' and not 'TRange[int]'? |
| 21:41:29 | BitPuffin | dom96: it's probably gonna take a while though, but system is pretty overloaded |
| 21:41:32 | BitPuffin | my* |
| 21:42:02 | BitPuffin | plus my TTIC is a very old one |
| 21:42:15 | EXetoC | Varriount: I don't know |
| 21:42:16 | dom96 | Your TTIC? lol |
| 21:42:43 | BitPuffin | dom96: My Twin Telepathic Interface Controller |
| 21:42:44 | reactormonk | shodan45, yup |
| 21:43:09 | boydgreenfield | Quick question: How do folks recommend doing run-time timing/profiling? I just realized getTime() rounds to the nearest second... (right?) |
| 21:43:11 | dom96 | BitPuffin: I have the latest one from Microsoft. I hope they kept backwards compatibility. |
| 21:43:19 | * | dom96 thinks we should stop lol |
| 21:43:29 | shodan45 | reactormonk: wow? |
| 21:43:39 | EXetoC | Varriount: I've never seen it evaluate to int though, because I've never gotten any strange related error |
| 21:43:44 | BitPuffin | dom96: mine is an old DOS one, but it's compatible with FreeDOS |
| 21:43:48 | BitPuffin | maybe :D |
| 21:43:50 | EXetoC | maybe some bug is triggered in that expression. just a guess |
| 21:43:55 | boydgreenfield | epochTime? |
| 21:44:00 | shodan45 | reactormonk: something like that exist for jquery or similar? |
| 21:44:15 | Araq | boydgreenfield: cpuTime? |
| 21:44:35 | Araq | I mostly use linux's time command |
| 21:44:45 | boydgreenfield | Ok cpuTime. Perfect, thanks! |
| 21:44:54 | boydgreenfield | Wrapping up that Bloom filter I mentioned last week... |
| 21:45:04 | boydgreenfield | (Using a sequence of int8s at the moment though...) |
| 21:45:17 | Araq | use a sequence of uint or int |
| 21:45:42 | Araq | it's faster and not more effort |
| 21:46:24 | Varriount | But not as memory conservative? |
| 21:46:37 | reactormonk | shodan45, probably. Grab a scripting language of your choice, a html parser, the jquery api and a bit of patience |
| 21:47:07 | Varriount | EXetoC, probably because I'm using static or something. |
| 21:48:05 | Araq | Varriount: 8 bytes vs 1 byte that will be aligned ... shouldn't matter at all |
| 21:48:31 | shodan45 | reactormonk: interesting... |
| 21:48:33 | reactormonk | shodan45, or ask me again in a week and I'll take a look |
| 21:49:02 | boydgreenfield | Araq/Varriount: I'll look to swap it out in a bit then – just requires changes to the bit math |
| 21:49:23 | shodan45 | reactormonk: what about creating multiple JS files? something kinda sorta like libraries? |
| 21:49:36 | Araq | yeah, you need to replace 8 by 8*sizeof(int) ;-) |
| 21:49:48 | shodan45 | reactormonk: or does it not still create 1 big JS file? |
| 21:50:17 | Araq | it creates 1 big JS file, but that is common for distribution anyway so JS engines can deal with it |
| 21:50:35 | boydgreenfield | Araq: Well, I had a const for my 8 bit positions, but will do those on the fly at variable/64-bit ints |
| 21:50:59 | Araq | nah it's still known at compile time, boydgreenfield |
| 21:51:15 | Araq | it's just that you don't know sizeof(int), the compiler knows |
| 21:51:16 | reactormonk | shodan45, you working with emacs? |
| 21:52:04 | Araq | boydgreenfield: please post some results and I'm interested in your implementation too. My new GC is likely to use a bloom filter for stack marking |
| 21:52:42 | boydgreenfield | Araq: Will do shortly. It's not optimized at all... and I'd also love some feedback on writing more idiomatic Nimrod (I'm bastardizing it into Python I suspect) |
| 21:53:14 | shodan45 | reactormonk: no... not working with anything at all yet :) |
| 21:54:21 | reactormonk | shodan45, what's your editor of choice? |
| 21:54:50 | EXetoC | notepad? |
| 21:55:51 | shodan45 | reactormonk: I've recently fallen in love with JetBrains' IDEs... but that would take a bit of effort to get working I think. Other than that, I just use Kate or Kwrite. |
| 21:59:40 | reactormonk | shodan45, go with vim/emacs/sublime/something |
| 21:59:58 | reactormonk | I suppose there won't be any JB for nimrod in the near future |
| 22:00:08 | boydgreenfield | Araq: Well, that was painless. I'll paste the github link in a second. |
| 22:00:20 | Varriount | BitPuffin, EXetoC, so, am I getting this right: You are passing '0.. <str.len', which creates a concrete TSlice, as a generic parameter to SwizzleImpl, which then uses that generic parameter as the index slice for it's array return type |
| 22:00:29 | boydgreenfield | (looks to be 15% slower with ints?) |
| 22:00:56 | OrionPKM | the ST plugin is getting some lovin now |
| 22:01:03 | OrionPKM | or rather, a new one is :) |
| 22:01:09 | OrionPKM | it's not in the package control yet though |
| 22:01:15 | shodan45 | reactormonk: the java & python versions are open source, and there's several free plugins for unsupported languages, so it's certainly doable |
| 22:01:26 | Varriount | OrionPKM, I just added typedesc as a builtin type. |
| 22:01:52 | OrionPKM | cool |
| 22:02:19 | OrionPKM | did you commit it? |
| 22:02:35 | boydgreenfield | Araq: link is here https://github.com/boydgreenfield/nimrod-bloom |
| 22:03:23 | OrionPKM | Varriount I added TODO comment highlight |
| 22:03:33 | EXetoC | Varriount: I don't even remember much about that :p |
| 22:03:38 | EXetoC | will look into it soon |
| 22:04:15 | OrionPKM | Varriount I'm going to try to switch to CAAS some time this weekend |
| 22:04:29 | OrionPKM | for the idetools calls |
| 22:04:50 | OrionPKM | some snippets would be nice as well |
| 22:04:53 | Varriount | I'm gonna try to get some more syntax highlighting stuff done. |
| 22:05:00 | OrionPKM | what's left? |
| 22:05:06 | OrionPKM | I really wish we could do tooltips :( |
| 22:05:15 | Varriount | OrionPKM, mainly complex stuff |
| 22:05:34 | Varriount | procedure declarations and bodies |
| 22:05:34 | OrionPKM | I was thinking it might be nice if pragmas stood out a bit.. |
| 22:05:39 | Varriount | Pragmas |
| 22:05:57 | EXetoC | Varriount: ok which line? |
| 22:06:03 | Varriount | As a side note, the python syntax file is a good base. |
| 22:06:30 | OrionPKM | whatever we're using right now is a good base, that yaml file is nice and clean |
| 22:06:32 | Varriount | EXetoC, in the code BitPuffin pasted, line 32 |
| 22:08:17 | radsoc | MFlamer: Hi, I tried lockfreehash yesterday but had a problem at compile time : lockfreehash.nim(23, 18) Error: type mismatch. The line 23 is: TRaw = range[0..4611686018427387903]. It's strange because if I create a .nim with range[0..(high(int) div 2)], it works :is not 4611686018427387903 interpreted as an int? is there any workaround ? (without rebuild) |
| 22:08:46 | EXetoC | Varriount: this might clarify: array[0..5, int] (from the manual) means that the array is indexed from 0 to 5, so it has 6 elements |
| 22:09:00 | MFlamer | Hi radsoc |
| 22:09:22 | EXetoC | so if specifying a swizzle like this: xxyzzzxz, then what you get is an 8-dimensional vector |
| 22:11:02 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 22:11:04 | MFlamer | radsoc: you are trying as 64bit. I was getting that same problem, when I wrote it. Unfortunatly it may only work as 32bit right now |
| 22:11:15 | reactormonk | shodan45, go for it |
| 22:11:28 | MFlamer | Will 32bit work for you? |
| 22:11:39 | EXetoC | so, if the original input vector is [2, 6, 1], then the above swizzle will generate [2, 2, 6, 1, 1, 1, 2, 1] |
| 22:11:55 | EXetoC | I don't know if you got the concept, but perhaps you understand the actual implementation now |
| 22:12:04 | * | hoverbear joined #nimrod |
| 22:12:36 | * | Hannibal_Smith quit (Quit: Sto andando via) |
| 22:13:25 | * | zielmicha quit (Read error: No route to host) |
| 22:14:53 | Varriount | EXetoC, yes, I know |
| 22:15:34 | * | BitPuffin joined #nimrod |
| 22:15:46 | MFlamer | radsoc: so, maybe my range is too big. That may fix this issue, but I would have to add a few more things to support 64 bit. I might be able to get to it tonight if you need it |
| 22:15:50 | radsoc | MFlamer: well, unfortunately no... do you think (high(int) div 2) could be OK? |
| 22:15:52 | EXetoC | Varriount: ok so the answer to your question is simply yes |
| 22:16:37 | radsoc | MFlamer: please, don't work at night for me! |
| 22:17:15 | shodan45 | reactormonk: weekend project... maybe ;) |
| 22:17:38 | MFlamer | the hashing function and a few other things are set up only for 32bit ptrs as of now. We need the table to get finished anyway.....or this will just come up again |
| 22:17:49 | * | zielmicha joined #nimrod |
| 22:19:02 | radsoc | MFlamer: I really can wait some days |
| 22:19:38 | reactormonk | shodan45, more than that |
| 22:19:46 | MFlamer | radsoc: OK, well I'll post on the forum when I get to it. |
| 22:20:04 | Araq | boydgreenfield: your nimrod code is actually quite idiomatic |
| 22:20:36 | Araq | the 'var' declarations at the top of the proc body are unnecessary though. Nimrod is not pascal. |
| 22:20:49 | radsoc | MFlamer: OK, thanks! |
| 22:21:00 | Araq | just do: var/let hash_set = bf.hash(item) |
| 22:21:16 | boydgreenfield | Araq: Thanks! And good to know... I also have a lot of snake_case and I wasn't sure what the best way to handle optional params is (or import/from statements, for that matter) |
| 22:21:24 | Araq | MFlamer: please get to it :P |
| 22:21:44 | Araq | we need this concurrent hash table in a working state |
| 22:21:57 | MFlamer | OK |
| 22:23:52 | Araq | god, I hate our test suite. It's full of hard cases ... |
| 22:24:16 | boydgreenfield | Araq: When is it appropriate to include the var at the top of the proc? For variables being redefined in a loop is it preferable to include var above or within the loop itself? |
| 22:24:36 | boydgreenfield | (and if/else paths seem to raise compiler hints/warnings?) |
| 22:24:44 | Varriount | Araq, hard cases? |
| 22:25:11 | Araq | Varriount: it's like somebody added every hard to support case to our test suite |
| 22:25:11 | radsoc | good night |
| 22:25:16 | * | radsoc quit (Remote host closed the connection) |
| 22:25:36 | MFlamer | goodnight radsoc |
| 22:25:59 | Varriount | Araq, probably because each test case was born out of a bug report. |
| 22:26:28 | Araq | boydgreenfield: just use 'let v = expr' whenever possible. If not possible try 'var' and if that's not possible try to declare it in an outer scope |
| 22:26:43 | boydgreenfield | Araq: Got it. Thx. |
| 22:27:48 | Araq | Varriount: believe it or not, it's often also 'cause we know how to write tests ... |
| 22:30:53 | shodan45 | reactormonk: to get something like a browser's alert() function imported into nimrod, I'd just need '{.importc: "alert"}' after the nimrod proc signature, right? |
| 22:31:10 | reactormonk | shodan45, yup, check kwin-nim ;-) |
| 22:33:02 | shodan45 | reactormonk: very cool |
| 22:34:03 | OrionPKM | wouldnt you just need {.nodecl.}? |
| 22:36:35 | Araq | OrionPKM: 'nodecl' wouldn't prevent name mangling |
| 22:37:04 | OrionPKM | ah.. in the manual you dont use it on printf |
| 22:37:12 | OrionPKM | erm, importc |
| 22:37:51 | Araq | 'nodecl' got more error prone btw because now nimbase.h doesn't import stdio etc. anymore |
| 22:38:08 | Araq | so you end up having no header at all in the generated C |
| 22:38:19 | OrionPKM | importc without a string uses the function name, right? |
| 22:38:21 | Araq | so be careful with 'nodecl', 'nodecl' is a hack anyway |
| 22:38:25 | Araq | right. |
| 22:38:25 | OrionPKM | ok |
| 22:41:40 | BitPuffin | nelson mandela died |
| 22:42:11 | Varriount | Araq, is there anything... special about the type of '1..5'? |
| 22:42:27 | BitPuffin | http://www.nytimes.com/2013/12/06/world/africa/nelson-mandela_obit.html?hp&_r=0 |
| 22:42:37 | Araq | Varriount: yes. it's highly ambiguous |
| 22:43:08 | Araq | it's either a TSlice or a range, depending on the context |
| 22:50:04 | * | brson quit (Read error: Connection reset by peer) |
| 22:50:45 | * | brson joined #nimrod |
| 22:52:08 | * | XAMPP_ joined #nimrod |
| 22:53:38 | * | XAMPP quit (Ping timeout: 264 seconds) |
| 22:55:47 | Varriount | Araq, so, why is it that you can call a generic function like foo[1..4](intSeq), but not foo[TSlice[int](1,4)](intSeq)? |
| 22:56:12 | EXetoC | "proc `..` ..." |
| 22:56:18 | Varriount | Er, TSlice[int](a:1,b:4) |
| 22:56:50 | EXetoC | that proc constructs a slice |
| 22:57:13 | Varriount | EXetoC, one of the forms of `..` And an arrays first arguments accepts? |
| 22:57:50 | Araq | Varriount: why is it? complexity breeds bugs. That's why. |
| 22:58:57 | Varriount | So.. a `..` in a generic parameter is a special case then? |
| 22:59:11 | * | dymk quit (Ping timeout: 246 seconds) |
| 22:59:18 | EXetoC | you should be able to construct a TSlice explicitly |
| 23:00:02 | EXetoC | if not, then you're doing something wrong. or maybe it's not possible when dealing with array and range, but they would be special cases then |
| 23:00:43 | Varriount | EXetoC, https://gist.github.com/Varriount/7815593 |
| 23:03:42 | * | dirkk0 quit (Quit: Leaving) |
| 23:04:55 | * | dymk joined #nimrod |
| 23:06:47 | EXetoC | I think I misread. Araq: so it has actually been explicitly disallowed for type parameters? |
| 23:07:17 | EXetoC | because "var x = TSlice[int](a: 1, b: 5)" works |
| 23:08:14 | EXetoC | I'm making no sense as always |
| 23:09:18 | Varriount | EXetoC, I can explicitly *instantiate* TSlices, but I can't use them in generic parameters. But I can use `..` in generic parameters, despite `..` returning a TSlice. |
| 23:09:40 | EXetoC | Varriount: it's simply a special case, as it is when doing array[0..1, int] or range[0..1] |
| 23:10:50 | EXetoC | so .. is indeed handled in a special way in some cases, so it's not just a proc and an iterator defined in system.nim |
| 23:11:56 | * | Varriount is adding this to his proposal |
| 23:15:40 | EXetoC | adding what? |
| 23:16:25 | Varriount | This inconsistancy |
| 23:17:56 | Varriount | EXetoC, you may or may not recall that, a couple weeks ago, I proposed that generic argument syntax should eventually be changed into partial argument instanciation |
| 23:19:08 | Varriount | Because of all the little differences between generic procedures, and procedures with arguments that have a type of typedesc |
| 23:23:38 | * | travisbrady quit (Ping timeout: 240 seconds) |
| 23:26:16 | BitPuffin | dom96: probably not gonna get a screenshot tonight :P |
| 23:26:22 | dom96 | :( |
| 23:26:32 | dom96 | Give us one anyway! |
| 23:26:33 | BitPuffin | since I need to shower soon |
| 23:26:38 | BitPuffin | dom96: nein! |
| 23:26:51 | BitPuffin | unless you want a black screen ofc |
| 23:26:58 | BitPuffin | terrain comes first :P |
| 23:27:08 | dom96 | lol ok |
| 23:27:10 | BitPuffin | and I'm trying to decide what way to do it right |
| 23:27:23 | EXetoC | come on, just show us one triangle |
| 23:27:40 | BitPuffin | EXetoC: you can save the day by showing your quad |
| 23:28:55 | EXetoC | three quads even |
| 23:30:33 | BitPuffin | okay |
| 23:30:36 | BitPuffin | uploading screenshot |
| 23:30:45 | Varriount | :O |
| 23:30:51 | dom96 | :O |
| 23:30:56 | BitPuffin | http://www.pasteall.org/pic/show.php?id=63600 |
| 23:32:35 | Varriount | Hey, I play that game all the time! |
| 23:32:44 | EXetoC | color terminal? neat |
| 23:33:10 | OrionPKM | yuy |
| 23:33:11 | BitPuffin | EXetoC: I dunno it's just rxvt-unicode, weechat presented the colors :s :D |
| 23:33:30 | BitPuffin | shit my computer is dying!! no battery!! |
| 23:33:44 | BitPuffin | as you can see in the pic :P |
| 23:36:28 | * | zielmicha quit (Ping timeout: 246 seconds) |
| 23:37:49 | Varriount | BitPuffin, and, you have no connection? |
| 23:37:59 | Varriount | W:Down, E:Down |
| 23:38:02 | BitPuffin | Varriount: apparently not |
| 23:38:12 | BitPuffin | the no battery part is actually true |
| 23:38:13 | dom96 | Well I'm away to sleep. |
| 23:38:14 | dom96 | Bye |
| 23:38:16 | BitPuffin | there is no battery on my laptop |
| 23:38:20 | BitPuffin | dom96: night! |
| 23:38:27 | BitPuffin | s/on/in |
| 23:38:37 | Varriount | BitPuffin, what happens if the plug falls out? |
| 23:38:46 | BitPuffin | Varriount: the laptop dies |
| 23:39:01 | Varriount | Why don't you have a battery? |
| 23:39:06 | BitPuffin | because it died |
| 23:39:12 | Varriount | ? |
| 23:39:17 | BitPuffin | like the monday before this one |
| 23:39:20 | BitPuffin | or was it this one? |
| 23:39:28 | BitPuffin | think it was the monday before last |
| 23:39:35 | Varriount | Nah, it's next monday you're thinking about |
| 23:39:39 | BitPuffin | haha |
| 23:39:41 | BitPuffin | ofc |
| 23:39:48 | BitPuffin | no but seriously |
| 23:39:54 | BitPuffin | it just stopped working out of the blue |
| 23:39:57 | BitPuffin | fucking annoying |
| 23:40:31 | BitPuffin | it died the 25th of november |
| 23:40:43 | EXetoC | this year? |
| 23:40:56 | BitPuffin | EXetoC: no during the rennaisance |
| 23:40:59 | BitPuffin | yes this year |
| 23:46:23 | BitPuffin | EXetoC: I'm guessing you draw your quads using a triangle strip? :P |
| 23:47:32 | shodan45 | BitPuffin: generally, batteries don't just "die" - check for broken contacts, etc. |
| 23:48:05 | EXetoC | BitPuffin: points |
| 23:48:26 | EXetoC | actually no, tri strips |
| 23:48:36 | * | jimmt is now known as jennjimm |
| 23:48:50 | BitPuffin | EXetoC: haha points :P |
| 23:48:54 | EXetoC | c(:) |
| 23:49:14 | BitPuffin | shodan45: they look just fine |
| 23:51:06 | BitPuffin | shodan45: but when I put it in it just says charging forever and the battery symbol lamp thing blinks red |
