| 00:02:43 | * | xhevahir quit (Quit: Leaving) |
| 00:02:57 | * | Hannibal_Smith quit (Quit: Sto andando via) |
| 00:20:59 | fowl | BitPuffin, my dad is going to buy some video cards and a motherboard, know of a good resource for info |
| 00:21:27 | * | Varriount raises his hand |
| 00:21:51 | Varriount | fowl, make sure that whatever he buys is supported by the computer's power supply. |
| 00:22:22 | fowl | you mean enough wattage? |
| 00:23:00 | Varriount | Yeah |
| 00:23:31 | C0C0 | BitPuffin: if ther was a markov random field trained on your messages it would allways say "take cover take cover take cover" |
| 00:24:09 | fowl | Varriount, can you recommend a card |
| 00:24:14 | Varriount | Also, if he is running linux, try to stick with nVidia - AMD/ATI's graphics drivers are buggy (linux especially, but also on windows) |
| 00:24:29 | Varriount | Fowl, price range? |
| 00:24:50 | Araq | C0C0: well BitPuffin is scared by my witty remarks |
| 00:24:58 | fowl | Varriount, is there a diff in hardware needed for scrypt/sha256 mining |
| 00:25:23 | Varriount | fowl, I wouldn't know. |
| 00:26:31 | Araq | argh I'm bootstrapping in full GC debug mode |
| 00:26:31 | Varriount | My guess is that for such things, the number of processors and the bandwidth of the card's buses would be the most important thing. |
| 00:26:36 | Araq | no wonder it takes forever |
| 00:27:03 | Varriount | Araq, have fun, you might want to find a movie to watch while waiting. |
| 00:27:30 | Araq | well I pressed ctrl+c instead |
| 00:27:31 | fowl | Varriount, is there a site with a nice chart/table |
| 00:27:35 | fowl | for comparing hardware |
| 00:28:08 | Varriount | fowl, this is the best site I use -> http://www.newegg.com/Product/PowerSearch.aspx?SubCategory=48&N=100007709&IsNodeId=1 |
| 00:28:32 | Varriount | Put criteria in, get choices, compare, and choose. |
| 00:29:08 | fowl | can i use MH/s as criteria |
| 00:29:20 | Araq | fowl: I'm too stupid to spot the bug in "bringToFront" |
| 00:29:21 | Varriount | Huh? |
| 00:29:39 | BitPuffin | fowl: what's he gonna use it for? |
| 00:30:05 | Varriount | Araq, any progress on tracking that memory corruption bug? The one that causes the build bots to crash when bootstrapping a second time? |
| 00:30:06 | BitPuffin | :) |
| 00:30:06 | fowl | Araq, i dont see it either |
| 00:30:39 | BitPuffin | fowl: lol MH/s |
| 00:30:43 | Araq | Varriount: well I found a bug that might be responsible |
| 00:30:45 | BitPuffin | fowl: don't use a gpu to min |
| 00:30:47 | BitPuffin | e |
| 00:30:53 | BitPuffin | it's a waste of money |
| 00:31:04 | BitPuffin | if you wanna mine you should get an asic |
| 00:31:10 | fowl | Araq, maybe the function should just do list.remove(entry); list.prepend(entry) |
| 00:31:15 | Varriount | Isn't mining illegal/unethical/stealing? |
| 00:31:22 | BitPuffin | Varriount: no? |
| 00:31:34 | fowl | Varriount, what did you think i was talking abuot |
| 00:31:35 | BitPuffin | Varriount: not bitcoin mining at least xD |
| 00:31:37 | Araq | fowl: ok try that then |
| 00:31:53 | webskipper | which algorithm(s) should I choose for speed comparisons. For example nimrod vs java ? |
| 00:32:04 | fowl | Araq, also that is the only usage of bringToFront() |
| 00:32:04 | BitPuffin | fowl: for the record, when it comes to mining, amd beats nvidia |
| 00:32:07 | fowl | in compiler/ |
| 00:32:19 | BitPuffin | not that it matters because you'd be ruining a perfectly good gpu if you used it to mine |
| 00:32:22 | Araq | webskipper: the algorithms where nimrod wins obviously :P |
| 00:32:29 | webskipper | what about quicksort :D |
| 00:32:40 | webskipper | or should I build trees ? |
| 00:32:47 | Varriount | webskipper, object creation and initialization. |
| 00:32:50 | fowl | BitPuffin, Better your best with ASICS wide variety of running shoes, high performance athletic shoes & all sport athletic gear. Shop now to experience the world of ASICS! |
| 00:32:55 | Araq | the binary tree benchmark is a bitch |
| 00:33:03 | BitPuffin | fowl: anyway there is a bitcoin wiki page that compares mh/s for various gpus |
| 00:33:33 | webskipper | Araq: is a bitch ? Which benchmark you mean ? |
| 00:33:33 | Varriount | Ok, since my hazy idea is obviously flawed, what *is* bitcoin mining? |
| 00:33:50 | BitPuffin | Varriount: it's when you mine bitcoin |
| 00:33:52 | BitPuffin | s |
| 00:33:57 | BitPuffin | yes that was a very helpful answer |
| 00:34:00 | Araq | the binary tree bench from the language shootout |
| 00:34:15 | Araq | nimrod is doing quite bad on this one |
| 00:34:33 | BitPuffin | Varriount: basically it's kind of like brute forcing passwords. You already know the expected output, so you need to calculate the input |
| 00:34:41 | fowl | BitPuffin, why is asic prefered, and those are prebuilt machines only, right? |
| 00:34:42 | webskipper | Araq: url ? http://benchmarksgame.alioth.debian.org/ ? |
| 00:34:53 | fowl | BitPuffin, can i use them for scrypt coins like LTC, FTC |
| 00:34:59 | Araq | webskipper: yes |
| 00:35:02 | BitPuffin | fowl: because the hashrate of gpus are balls compared to that of asics |
| 00:35:10 | Varriount | Araq, how did you get github to add nimrod syntax highlighting? |
| 00:35:12 | webskipper | Araq: and why is it a bitch ? :D |
| 00:35:29 | Araq | because it's so hard to optimize my GC against it :P |
| 00:35:33 | BitPuffin | fowl: as far as I know there isn't an asic for scrypt yet but that may have changed |
| 00:36:01 | BitPuffin | so if you wanna mine scrypt I guess your best bet is gpu |
| 00:36:06 | BitPuffin | but there isn't really any point to that |
| 00:36:13 | BitPuffin | go pro or go home |
| 00:36:15 | BitPuffin | buy an asic :P |
| 00:36:20 | Araq | Varriount: dom96 slept with a female employee of github |
| 00:36:48 | fowl | BitPuffin, there isnt a point to mining bitcoins if you arent already |
| 00:36:55 | fowl | the difficulty is too damn high |
| 00:37:03 | BitPuffin | fowl: there is with asics |
| 00:37:21 | BitPuffin | it's the asics that are making it high |
| 00:37:26 | BitPuffin | so if you are one of the asics |
| 00:37:30 | BitPuffin | catching |
| 00:37:33 | Araq | fowl: I'm quite sure it's the only usage of bringToFront |
| 00:37:35 | BitPuffin | ca-ching* |
| 00:38:02 | webskipper | Araq: do we have an implementation in nimrod ? |
| 00:38:13 | Araq | Varriount: speaking of which. can you reduce builder.nim so that the bug is triggered without these crazy git interactions? |
| 00:38:16 | BitPuffin | fowl: look at some mining calculators I guess and compare with the hashrate of asics etc and see if it is worth it |
| 00:38:24 | fowl | arent they still quite expensive |
| 00:38:27 | BitPuffin | to the googles my friend |
| 00:38:38 | fowl | irc >>>> google |
| 00:38:58 | BitPuffin | there is a 25 ghz for 1245 usd |
| 00:39:02 | Araq | webskipper: tests/gc/bintrees.nim |
| 00:39:04 | Varriount | Araq, explain/clarify? |
| 00:39:11 | fowl | BitPuffin, whats your opinion on https://cex.io/ |
| 00:39:27 | Araq | Varriount: I need a reduced test case for the corruption |
| 00:39:42 | Araq | "reduced" can still be a very large program |
| 00:39:44 | Varriount | Oh, why didn't you just say so? |
| 00:39:52 | BitPuffin | fowl: is it "cloud hashing" ? |
| 00:39:53 | Araq | but it shouldn't interact with github |
| 00:40:00 | Araq | because that really sucks for testing |
| 00:40:18 | Araq | Varriount: next time I will |
| 00:40:27 | Varriount | Araq, I'll do my best. I still suspect that the cause of the problem is threading. |
| 00:40:47 | fowl | BitPuffin, yea |
| 00:40:51 | Araq | Varriount: that would made my day. thanks |
| 00:41:05 | BitPuffin | fowl: I'm sure it might be nice, you are gonna have to evaluate it yourself though :) |
| 00:41:08 | webskipper | github is slow AGAIN *argh* |
| 00:41:21 | * | Varriount gets the ice-cream scoop and the scalpal |
| 00:41:54 | Varriount | Araq, I may not be on much for the next two weeks - I have finals. |
| 00:42:10 | Araq | damn |
| 00:42:25 | Araq | next two weeks are all that I've left to release 0.9.14 |
| 00:42:35 | Araq | er ... 0.9.4 lol |
| 00:42:48 | BitPuffin | well |
| 00:42:52 | fowl | BitPuffin, going to eat pizza, you gonna be around in 30 mins? |
| 00:43:14 | BitPuffin | next ~3 weeks is all I have to make this game so you are not alone Araq |
| 00:43:17 | BitPuffin | fowl: probably |
| 00:43:18 | EXetoC | who knows. he always sleeps early |
| 00:43:20 | Varriount | Araq, is it ok if the builder connects to the hub? |
| 00:43:20 | BitPuffin | no guarantees |
| 00:43:27 | BitPuffin | I'm sleepy |
| 00:43:29 | Araq | sure |
| 00:43:52 | Araq | Varriount: how about this? you come up with the test case, and I'll show you everything I know about debugging memory corruptions. |
| 00:44:03 | Varriount | Oh joy. |
| 00:44:46 | Araq | they don't teach you these things in university :P |
| 00:45:32 | BitPuffin | they don't teach you nuthin |
| 00:48:18 | EXetoC | sure. nothing at all |
| 00:49:17 | Varriount | Araq, besides connecting to github, what else should I try to remove from the builder> |
| 00:50:02 | BitPuffin | code |
| 00:53:22 | Araq | well just ensure it runs bootstrapping twice without me doing anything |
| 00:53:32 | Araq | that should already be it |
| 00:54:36 | Varriount | It should crash with the segfault the second time, right? |
| 00:54:52 | Araq | right |
| 00:57:51 | * | Icefoz joined #nimrod |
| 00:57:59 | Araq | hi Icefoz welcome |
| 00:58:03 | Icefoz | Thanks. |
| 00:59:04 | Icefoz | Was just taking a closer look at nimrod for once and discovered that I think I love it and hate it at the same time. So my plan was to lurk here and see how it works in practice. |
| 00:59:52 | BitPuffin | Icefoz: why the hate? |
| 01:00:57 | Icefoz | While I dearly love python I sort of feel like indentation-sensitive syntax is an objectively bad idea. And indentation-sensitive comments is an idea that makes my nipples tingle in fear. |
| 01:01:07 | Icefoz | I'm just reading through the tutorials so far, though. |
| 01:01:27 | BitPuffin | hehe |
| 01:01:51 | Araq | actually we'll get rid of those I think |
| 01:02:02 | Araq | I mean the indentation based comments |
| 01:02:06 | EXetoC | objectively bad? really? |
| 01:02:35 | Araq | it's however a really minor thing |
| 01:02:51 | NimBot | Araq/Nimrod master 8fb0fbe Araq [+1 ±4 -0]: fixes a regression where memset was used without including <string.h> |
| 01:02:51 | NimBot | Araq/Nimrod master 75fc39d Araq [+1 ±4 -1]: Merge branch 'master' of github.com:Araq/Nimrod |
| 01:03:04 | Icefoz | Not like super-duper-mega-bad. But it adds a little conceptual+technical complexity for no real benefit. |
| 01:03:30 | Araq | the benefit for me is that it gets rid of } } } or "end end end" |
| 01:03:31 | Icefoz | +social complexity too, because of all the haters. |
| 01:03:50 | Araq | I really hate those, it's baby sitting the compiler |
| 01:04:02 | BitPuffin | Icefoz: as EXetoC implied, "feel like" and "objectively" don't really belong in the same sentence |
| 01:04:20 | Icefoz | The number of times I hammer tab in emacs to get to the right indentation is probably about the same number of keystrokes as typing } } }. :-P |
| 01:04:28 | Icefoz | But, that's fair. |
| 01:04:32 | Araq | it's not about the typing |
| 01:04:35 | Araq | it's about the reading |
| 01:04:38 | Varriount | ^ |
| 01:04:42 | BitPuffin | well |
| 01:04:50 | Icefoz | Good point. I don't read other people's code as much as I should. |
| 01:05:04 | BitPuffin | and does any decent programmer not indent their code anyway? |
| 01:05:06 | * | mflamer_ joined #nimrod |
| 01:05:08 | Araq | it's also not about other people for me |
| 01:05:17 | BitPuffin | Araq: says the guy with the ONE CHARACTER VARIABLES RUN!!! |
| 01:05:19 | Araq | I just like to have lots of *code* on my screen |
| 01:05:33 | Araq | *code* which actually does something |
| 01:05:37 | BitPuffin | yeah I hear you one that one |
| 01:05:44 | BitPuffin | that's why I use such a small font |
| 01:05:45 | Araq | so that the bug might show up |
| 01:05:45 | Icefoz | I'm honestly curious how you came up with indentation-sensitive comments. |
| 01:05:59 | Varriount | Icefoz, documentation generation! |
| 01:06:29 | BitPuffin | actually I quite like the indentation sensitive comments |
| 01:06:35 | EXetoC | doesn't emacs support auto-indentation? I'd be surprised if it didn't, as it has been around since the early 1900s or something like that |
| 01:06:36 | Icefoz | Varriount: Even for wing-style comments within a block? Seems odd. |
| 01:06:39 | BitPuffin | because of what Varriount said |
| 01:06:45 | BitPuffin | plus it enforces consistency |
| 01:06:53 | BitPuffin | so you can sort of always know what the comment comments on |
| 01:07:20 | Varriount | Icefoz, I didn't come up with the wing-style comments. Besides, you don't have to use that style if you don't want to. |
| 01:07:22 | EXetoC | BitPuffin: what's really annoying is when you're trying to comment out an enumerator for example |
| 01:07:26 | BitPuffin | EXetoC: believe it was uncovered in 1567 by christopher columbus |
| 01:07:33 | Icefoz | Just feels uncomfortable having the compiler mandate something you should do anyway. I like the option to be sloppy. |
| 01:07:46 | Icefoz | But I haven't tried it myself yet, so. |
| 01:07:57 | BitPuffin | Icefoz: then you are gonna like the case insensitivity lol :D |
| 01:08:05 | BitPuffin | and style insensitivity |
| 01:08:06 | EXetoC | Icefoz: like he said, it might change |
| 01:08:12 | BitPuffin | a_b == aB |
| 01:09:13 | Icefoz | BitPuffin: Oh gods, really? There's a difference between I-want-to-comment-this-out-right-now sloppy and what-variable-is-this-pretending-to-be sloppy. D: |
| 01:09:28 | Icefoz | EXetoC: And, changing is fair. |
| 01:10:11 | BitPuffin | I don't see how commenting something out is a problem? |
| 01:10:12 | Icefoz | I'm just rambling my impressions as they occur, at this point. |
| 01:10:22 | BitPuffin | you can put a comment anywhere |
| 01:10:31 | BitPuffin | just that it's a part of the AST |
| 01:10:39 | BitPuffin | but that doesn't really matter when just removing something |
| 01:10:48 | Icefoz | Anyway, gtg for a bit. Nice talking to you all. |
| 01:10:53 | EXetoC | Icefoz: yeah sure do that |
| 01:10:58 | EXetoC | bye |
| 01:11:00 | BitPuffin | go? |
| 01:11:27 | Araq | BitPuffin: remind me to never make you an official promoter ;-) |
| 01:11:42 | EXetoC | lol |
| 01:12:00 | BitPuffin | Araq: are you saying I did bad? :O |
| 01:12:21 | Araq | don't scare people with the SI |
| 01:12:32 | BitPuffin | but it sounded like he'd like it |
| 01:12:42 | BitPuffin | Icefoz: nimrod can also cure cancer |
| 01:12:59 | Araq | though it's funny it scares people when I know it's a non-issue |
| 01:13:17 | BitPuffin | well |
| 01:13:24 | BitPuffin | the only issue about it is the error message |
| 01:14:07 | BitPuffin | although figuring it out once through the painful error message really makes it sink in too |
| 01:14:14 | BitPuffin | so you don't make the same mistake twice |
| 01:14:47 | EXetoC | no u |
| 01:14:59 | BitPuffin | EXetoC: yo momma |
| 01:16:10 | Araq | a single time in my lifetime I'd like to meet somebody who doesn't confuse consistency with sensitivity |
| 01:17:04 | BitPuffin | well |
| 01:17:15 | BitPuffin | there is some consistency through sensitivity |
| 01:17:37 | BitPuffin | but that consistency is little gain for much lost |
| 01:17:38 | Araq | only consistency with the guy who wrote the definition |
| 01:17:49 | BitPuffin | yeah |
| 01:17:57 | Araq | not project-wide consistency |
| 01:18:05 | BitPuffin | true, you also win a lot of consistency by having a homogenus codebase |
| 01:18:41 | Araq | but anyway |
| 01:18:48 | Araq | I need to sleep now, good night |
| 01:18:56 | BitPuffin | me too but I'm not gonna yet |
| 01:18:59 | BitPuffin | night Araq |
| 01:20:46 | Varriount | Gak, so much builder code. I don't know what to remove >_< |
| 01:20:58 | Varriount | It's like a giant Jenga tower. |
| 01:21:25 | BitPuffin | that's a good description of source cod |
| 01:21:27 | BitPuffin | e |
| 01:21:45 | Varriount | Not neccessarily. |
| 01:21:52 | BitPuffin | well |
| 01:21:57 | BitPuffin | maybe not with pure functions |
| 01:22:47 | mflamer_ | I synched my branch with master a few days ago and the compiler seems quite a bit slower |
| 01:22:59 | mflamer_ | anyone else notice this? |
| 01:23:06 | Varriount | Nope. |
| 01:24:02 | BitPuffin | maybe fowl sneaked a bitcoin miner into it |
| 01:24:35 | mflamer_ | Thats funny, good thing I have none to mine |
| 01:25:31 | BitPuffin | mflamer_: well I mean that mines for him in secret |
| 01:28:19 | mflamer_ | Are you back up and running? Araq fixed that bug right? |
| 01:28:46 | mflamer_ | Was that the generic . field access bug? |
| 01:29:44 | BitPuffin | mflamer_: no that bug still remains |
| 01:29:56 | BitPuffin | mflamer_: it was a bugfix for the workaround to the workaround |
| 01:30:31 | mflamer_ | oh, damn. Well did it get you what you needed for now? |
| 01:30:38 | BitPuffin | yeah for now :) |
| 01:30:43 | mflamer_ | cool |
| 01:30:48 | BitPuffin | I have the code for n-dimensional stuff but it doesn't work yet |
| 01:31:00 | BitPuffin | but I worked around it by hard coding for the sizes I needed |
| 01:31:39 | BitPuffin | and then there was a bug when it thought that proc a(b: array[0..1, T]) and proc a(b: array[0..2, T]) was identical |
| 01:31:55 | * | MFlamer quit (Ping timeout: 272 seconds) |
| 01:33:48 | webskipper | is e+001 ? x10 ? |
| 01:34:16 | Varriount | Araq, did you do something with TThread? |
| 01:34:58 | EXetoC | webskipper: won't echo tell you? :p |
| 01:35:17 | BitPuffin | webskipper: is |
| 01:35:22 | BitPuffin | yes |
| 01:35:24 | webskipper | echo tells me CPU time [s] 1.2028000000000000e+001 |
| 01:35:26 | webskipper | lol |
| 01:35:33 | EXetoC | oh right |
| 01:35:40 | Varriount | webskipper, that's a power |
| 01:35:46 | BitPuffin | webskipper: e+001 is short for * 10^1 |
| 01:35:49 | EXetoC | yeah you'd have to use strutils.formatFloat |
| 01:35:53 | webskipper | ok |
| 01:41:58 | Varriount | Araq, ping aling a ding dong |
| 01:43:26 | EXetoC | he's sleeping and that |
| 01:43:32 | Varriount | Oh. |
| 01:43:33 | * | DAddYE quit (Remote host closed the connection) |
| 01:44:06 | * | DAddYE joined #nimrod |
| 01:44:14 | Varriount | Well, I got the builder to run, but not actually tell the subprocesses (git and the like) to do anything. |
| 01:45:16 | Varriount | It still calls them, but just as themselves (like when you type *only* nimrod on the command line - you get the info printout, and nothing else. |
| 01:45:45 | BitPuffin | I'm gonna sleep now |
| 01:45:47 | BitPuffin | :/ |
| 01:45:51 | BitPuffin | goodnight! |
| 01:49:01 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 01:50:15 | * | BitPuffin quit (Ping timeout: 246 seconds) |
| 02:10:49 | * | Varriount_ joined #nimrod |
| 02:14:38 | * | Varriount quit (Ping timeout: 240 seconds) |
| 02:14:38 | * | Varriount_ is now known as Varriount |
| 02:16:50 | webskipper | C 1 sec, Nimrod 1.7 sec, Java 4.7 sec |
| 02:27:05 | * | xenagi joined #nimrod |
| 02:29:23 | * | boydgreenfield joined #nimrod |
| 02:29:35 | * | boydgreenfield quit (Client Quit) |
| 02:31:19 | fowl | webskipper, for quicksort |
| 02:31:20 | fowl | ? |
| 02:31:35 | webskipper | binarytree depth = 24 |
| 02:32:47 | EXetoC | 0.5 sec seems like a reasonable goal :> |
| 02:44:53 | * | DAddYE joined #nimrod |
| 02:49:02 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 02:53:12 | * | jdp left #nimrod ("quit") |
| 03:14:28 | * | tylere joined #nimrod |
| 03:14:43 | tylere | Are the sdl_ wrappers considered stable? |
| 03:14:56 | tylere | I'm getting a sigsegv from SDL_image.load |
| 03:15:00 | tylere | err, IMG_Load |
| 03:15:16 | tylere | same code works fine using a bmp image and sdl.loadbmp |
| 03:16:31 | fowl | yes they're stable |
| 03:17:02 | tylere | The actual error I'm getting is SIGSEGV: Illegal storage access. <Attempt to read from nil?> |
| 03:17:09 | * | mflamer_ quit (Ping timeout: 272 seconds) |
| 03:17:10 | tylere | this is just lastest 64bif sdl1.2 dlls on w64 |
| 03:17:16 | tylere | with mingw64 |
| 03:17:35 | fowl | can you try examples/sdlex.nim in the nimrod repo |
| 03:19:42 | tylere | loads and draws a sort of indigo background |
| 03:21:25 | tylere | https://gist.github.com/tylereaves/7763368 |
| 03:21:27 | tylere | that's my code |
| 03:21:41 | tylere | it's a port of the lazy foo tutorial part 4 |
| 03:24:03 | fowl | it loads for me |
| 03:24:22 | fowl | oh wait let me try img_load |
| 03:25:47 | fowl | works fine for me with img_load |
| 03:26:25 | tylere | interesting |
| 03:26:35 | tylere | it looks to me like it's actually sigsegv inside the dll somehwere |
| 03:26:42 | tylere | is there any way I can turn on additional debugging? |
| 03:28:17 | tylere | fowl - try actually creating the x.jpg file |
| 03:28:32 | tylere | if it's missing it appears the normal logic kicks in and nothing crashs - the program just winds down |
| 03:28:39 | tylere | but if the file is present it sigsegvs |
| 03:32:06 | fowl | tylere, you're loading "x.bmp" regardless of what you pass to load_image() |
| 03:32:22 | tylere | swap the commented lines |
| 03:32:29 | tylere | to run the img_load line and not the loadbmp line |
| 03:32:30 | fowl | it works fine for me |
| 03:34:05 | tylere | so according to gdb... |
| 03:34:19 | tylere | 0x00007fefe0811cb in msvcrt!memmove <> from msvcrt.dll |
| 03:34:36 | tylere | wonder if it's an issue with the sdl dlls being compiled with vc++ instead of mingw |
| 03:34:42 | fowl | sdl was probably built with vc instead of .. yea |
| 03:34:48 | fowl | :p |
| 03:35:29 | tylere | but that shouldn't matter |
| 03:35:33 | tylere | that's the whole point of dlls... |
| 03:36:17 | webskipper | have we something like "prepare()" to avoid sql injections ? |
| 03:37:06 | webskipper | http://en.wikipedia.org/wiki/Prepared_statement |
| 03:38:10 | tylere | fowl: Are you running 32bit or 64bit? |
| 03:39:16 | fowl | im on linux |
| 03:39:24 | fowl | 64 |
| 03:40:51 | tylere | ahh, might be a windows issue then |
| 03:41:03 | fowl | webskipper, yes but im not sure how to use it |
| 03:42:18 | webskipper | fowl: the wrapper "postgres" seems to offer it but "db_postgres" not |
| 03:46:24 | * | DAddYE joined #nimrod |
| 03:50:38 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 03:53:25 | fowl | webskipper, see exec() |
| 03:54:47 | * | datura quit (Quit: Leaving) |
| 03:56:06 | webskipper | you mean args: varargs[string, `$`] ? |
| 04:03:50 | * | brihat quit (Ping timeout: 265 seconds) |
| 04:07:58 | * | brihat joined #nimrod |
| 04:09:49 | * | Varriount_ joined #nimrod |
| 04:13:06 | * | Varriount quit (Ping timeout: 246 seconds) |
| 04:13:06 | * | Varriount_ is now known as Varriount |
| 04:18:33 | * | boydgreenfield joined #nimrod |
| 04:20:16 | * | webskipper quit (Ping timeout: 264 seconds) |
| 04:35:52 | * | mflamer joined #nimrod |
| 04:43:59 | * | webskipper joined #nimrod |
| 04:47:17 | * | DAddYE joined #nimrod |
| 04:51:26 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 04:54:40 | * | tylere quit (Quit: Page closed) |
| 05:12:35 | * | Icefoz quit (Quit: leaving) |
| 05:13:50 | * | Icefoz joined #nimrod |
| 05:34:03 | * | xenagi quit (Quit: Leaving) |
| 05:41:31 | * | DAddYE joined #nimrod |
| 05:41:43 | * | DAddYE quit (Remote host closed the connection) |
| 05:41:49 | * | DAddYE_ joined #nimrod |
| 05:44:47 | * | DAddYE_ quit (Remote host closed the connection) |
| 05:45:15 | * | DAddYE joined #nimrod |
| 05:53:02 | * | mflamer quit (Ping timeout: 240 seconds) |
| 06:03:35 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 06:07:36 | * | dirkk0 joined #nimrod |
| 06:12:03 | webskipper | MOOOOOOOOORNING :D |
| 06:17:19 | NimBot | nimrod-code/packages master 99f0f27 Billingsly Wetherfordshire [+0 ±1 -0]: added windows package |
| 06:18:31 | fowl | ha i meant to do a PR, did a commit for some reason |
| 06:21:26 | * | boydgreenfield joined #nimrod |
| 06:56:46 | * | girvo joined #nimrod |
| 07:08:34 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 07:22:45 | dirkk0 | morning, fowl. Do you have any minimal SDL2 example you can share? |
| 07:22:58 | * | zahary quit (Ping timeout: 246 seconds) |
| 07:28:46 | fowl | dirkk0, in the examples folder for fowltek |
| 07:31:40 | dirkk0 | fowl: oh, I see - I was a folder too deep. thx! |
| 07:33:00 | dirkk0 | fowl: yay, it's working! |
| 07:34:46 | dirkk0 | fowl: the skeleton, that is. the gui example doesn't (undeclared identifier: 'White' ) |
| 07:35:29 | fowl | im not surprised, i havent updated that gui in a long time |
| 07:35:44 | fowl | i have a habit of getting things to a working state then losing interest |
| 07:36:41 | dirkk0 | but you still are into the engine/gamedev based on sdl2 thing? |
| 07:37:11 | fowl | yea |
| 07:37:28 | fowl | my current project though is porting SFML, it has a nicer API |
| 07:39:57 | dirkk0 | i c |
| 07:43:09 | dirkk0 | mind if I check this out on mac (and win later)? |
| 07:47:16 | * | webskipper quit (Ping timeout: 264 seconds) |
| 07:47:52 | * | webskipper joined #nimrod |
| 07:52:07 | * | DAddYE quit (Remote host closed the connection) |
| 07:52:15 | * | DAddYE joined #nimrod |
| 08:01:13 | webskipper | is there a special reason why we have no class keyword in nimrod ? |
| 08:01:34 | webskipper | if I understand the doc right it is easy to implement classes ? |
| 08:04:21 | * | dirkk0 quit (Quit: This computer has gone to sleep) |
| 08:18:48 | fowl | webskipper, a class is an inheritable object |
| 08:19:28 | fowl | you can use methods which provide dynamic dispatch or you can use a vtable pattern (for example see the streams module) |
| 08:20:19 | webskipper | yeah but that is not really the explanation why we have no class statement !? |
| 08:22:44 | fowl | what does a class statement add? |
| 08:32:37 | webskipper | class attributes ? would say oop feeling we know it from other languages. In addition the semantic of "object" is an other. |
| 08:33:12 | fowl | oop is not a focus in nimrod |
| 08:38:18 | * | girvo quit (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 08:45:19 | webskipper | Yes I think so too. |
| 08:46:39 | fowl | by it not being a focus, you have different ways to implement it if you need to |
| 08:50:09 | * | DAddYE quit (Remote host closed the connection) |
| 08:50:39 | * | DAddYE joined #nimrod |
| 09:09:02 | * | webskipper quit (Ping timeout: 246 seconds) |
| 09:28:54 | * | girvo joined #nimrod |
| 10:00:57 | Araq | Varriount: I'm back |
| 10:16:06 | * | webskipper joined #nimrod |
| 10:20:33 | Araq | webskipper: I don't mind adding a "class" macro to the stdlib, but the "best" implementation is still to be found |
| 10:21:14 | Araq | there has been some work on component systems too which should be included |
| 11:34:33 | * | BitPuffin joined #nimrod |
| 11:35:49 | BitPuffin | ahoy maties! |
| 11:37:06 | BitPuffin | EXetoC: you here? :) |
| 11:38:57 | EXetoC | BitPuffin: yeah, you? |
| 11:40:15 | BitPuffin | EXetoC: no |
| 11:40:29 | EXetoC | :O |
| 11:40:29 | BitPuffin | EXetoC: anyways I just wanted to check how your glfw3 wrapper work went |
| 11:40:39 | BitPuffin | I'm gonna work with it today |
| 11:40:46 | BitPuffin | so if there's bugs I'm gonna hunt you down ;) |
| 11:41:16 | * | webskipper quit (Ping timeout: 246 seconds) |
| 11:43:04 | BitPuffin | but first I'm gonna bind vorbisfile |
| 11:43:41 | * | krusipo quit (Read error: Connection reset by peer) |
| 11:46:08 | * | krusipo joined #nimrod |
| 11:51:11 | BitPuffin | Araq: wouldn't there be a way to make TMsg generic instead of having to cast? |
| 11:52:30 | Araq | what's your context? |
| 11:53:14 | * | faassen joined #nimrod |
| 11:53:38 | BitPuffin | Araq: Well I'm just looking at the way TMsg seems to be implemented |
| 11:53:59 | BitPuffin | with TMsg.content being a pointer |
| 11:54:23 | BitPuffin | couldn't that be some kind of generic type? |
| 11:54:35 | BitPuffin | or a pointer to a generic type |
| 11:56:11 | BitPuffin | or wait hang on |
| 11:56:21 | BitPuffin | maybe I'm getting a little confused here |
| 11:56:35 | Araq | are you talking about channels? |
| 11:56:39 | Araq | or what? |
| 11:56:46 | BitPuffin | Araq: yaman |
| 11:57:57 | Araq | well that was written before I found out with benchmarking that my RTTI stuff sucks for performance |
| 11:58:07 | BitPuffin | RTTI? |
| 11:58:20 | Araq | it looked like a good idea to keep the code size small at that time |
| 11:58:27 | Araq | "runtime type information" |
| 11:58:47 | BitPuffin | ah |
| 11:58:50 | BitPuffin | Yeah |
| 11:59:05 | BitPuffin | those generally bite with performance |
| 11:59:10 | BitPuffin | it seems like |
| 11:59:20 | BitPuffin | anyways I just realized something |
| 11:59:23 | BitPuffin | TChannel*[TMsg] = TRawChannel |
| 11:59:38 | BitPuffin | TMsg here is just a generic parameter isn't it? and doesn't have anything to do with the one in zmq.nim? |
| 11:59:51 | fowl | lol BitPuffin |
| 11:59:56 | fowl | you're drunk |
| 12:00:01 | BitPuffin | fowl: maybeee |
| 12:00:09 | BitPuffin | nah I'm not |
| 12:00:13 | BitPuffin | but I might be dehydrated |
| 12:00:16 | BitPuffin | should get some water |
| 12:00:32 | BitPuffin | Okay guys! Time to vote |
| 12:00:47 | BitPuffin | nim-vorbis file, or rod-vorbisfile |
| 12:00:48 | BitPuffin | :D |
| 12:01:28 | fowl | how about just libvorbis or whatever it is |
| 12:01:37 | BitPuffin | no I am only gonna bind libvorbis |
| 12:01:39 | fowl | there's enough nim- packages floating around |
| 12:01:47 | BitPuffin | maybe just vorbisfile then? |
| 12:01:54 | BitPuffin | but that's not good SEO |
| 12:02:07 | BitPuffin | miley-vorbisfile-cyrus? |
| 12:02:18 | BitPuffin | since that's apparently what people are talking about |
| 12:02:19 | EXetoC | yeah there's a reason why we have the prefix |
| 12:02:27 | fowl | oh |
| 12:02:32 | fowl | i just looked up SEO |
| 12:02:43 | BitPuffin | I'm going with nim-vorbisfile |
| 12:02:46 | BitPuffin | you guys are too unfocused |
| 12:03:14 | EXetoC | wot |
| 12:03:15 | fowl | my response: google knows you well enough to know that you love the nim, also the package contains the url where you can find the source, so |
| 12:03:54 | * | dirkk0 joined #nimrod |
| 12:03:59 | fowl | BitPuffin, might as well make it nim-audio because you know we'll have libao and libpulse etc too |
| 12:04:13 | BitPuffin | fowl: well, then we'll put them in separate bindings |
| 12:04:24 | BitPuffin | for this project all I need is vorbisfile |
| 12:04:32 | BitPuffin | not gonna sit here and bind my dick off |
| 12:05:02 | fowl | my repository count is too damn high |
| 12:05:46 | BitPuffin | fowl: the least you could do is to rename the repository to fowltek I mean come on |
| 12:05:47 | fowl | in nim-termbox i also have a wrapper for newt, so i need to change the package name to nim-term-ui-stuff |
| 12:05:58 | BitPuffin | nooo |
| 12:06:05 | fowl | BitPuffin, lol i know i should do that |
| 12:06:12 | BitPuffin | if I want termbox binding all I wanna install is termbox |
| 12:06:32 | fowl | sorry, you have to accept my other 400-line wrapper with it |
| 12:06:50 | BitPuffin | noooooooooooooooooOOOOOOOOOOOOOOOOOOOOooooooo |
| 12:06:54 | fowl | you're gonna need more than a floppy disk bud |
| 12:07:54 | Araq | ah the "lib" prefix. One of my favourites. foo.dll # makes sense. libfoo.so # er wtf? are there "shared objects" which are no lib? |
| 12:08:39 | fowl | plugins maybe |
| 12:08:45 | Araq | why is called "shared object" anyway? will we ever improve on the technology stack of the 60ies? |
| 12:10:25 | BitPuffin | include/vorbis/vorbisfile.h(77, 8) Error: ')' expected |
| 12:10:28 | BitPuffin | poop |
| 12:10:48 | EXetoC | common error. you need to define something probably |
| 12:11:13 | BitPuffin | wtf kind of a line is that anyway |
| 12:11:20 | BitPuffin | (int (*)(void *, ogg_int64_t, int)) _ov_header_fseek_wrap, |
| 12:11:40 | EXetoC | oh. function pointer? |
| 12:11:46 | EXetoC | that syntax is just the worst |
| 12:11:55 | fowl | BitPuffin, yea you have to pull those out into a typedef |
| 12:12:05 | BitPuffin | .-. |
| 12:12:09 | fowl | it doesnt do well with anonymous func types |
| 12:12:26 | BitPuffin | is this even C xD |
| 12:12:46 | fowl | yea |
| 12:13:23 | fowl | its a shit header though, your function args are going to be a1,a2,.. not giving you any information on the argument you're supposed to pass |
| 12:13:41 | BitPuffin | so what I need to do is |
| 12:13:50 | BitPuffin | typedef (int (*)(void *, ogg_int64_t, int)) _ov_header_fseek_wrap; ? |
| 12:15:14 | Araq | typedef syntax for function pointers is different |
| 12:15:59 | BitPuffin | sure but |
| 12:16:01 | BitPuffin | something like that |
| 12:16:09 | BitPuffin | you mena I have to make each function pointer a typedef |
| 12:16:13 | fowl | BitPuffin, those are static vars though |
| 12:16:23 | BitPuffin | and put them in the static thingyball |
| 12:16:35 | fowl | These structs below (OV_CALLBACKS_DEFAULT etc) are defined here as * static data. That means that every file which includes this header * will get its own copy of these structs whether it uses them or * not |
| 12:16:54 | fowl | BitPuffin, see if your .so has OV_CALLBACKS_DEFAULT |
| 12:17:10 | EXetoC | opengl.loadExtensions() yields this now all of a sudden "glfw_glfw.c:(.text+0x7aa9): undefined reference to `nimLoadProcs0'". I don't know why |
| 12:17:37 | Araq | EXetoC: when you don't use any extension method, this happens |
| 12:17:41 | BitPuffin | fowl: the libvorbis.so? |
| 12:18:11 | fowl | BitPuffin, yea, if so, you can just importc those |
| 12:18:36 | BitPuffin | how do I even do that |
| 12:19:09 | fowl | nm -gU /usr/lib/libvorb.so |
| 12:19:22 | fowl | | grep OV_CALLBACKS_DEFAULT |
| 12:20:17 | fowl | er nm -D |
| 12:20:58 | EXetoC | Araq: ok I guess I can't automate that in a lib then |
| 12:21:23 | BitPuffin | doesn't look like it |
| 12:22:42 | Araq | EXetoC: nope, opengl is screwed up |
| 12:23:09 | Araq | otherwise opengl.nim itself could invoke loadExtensions() |
| 12:23:18 | fowl | BitPuffin, take the types from struct ov_callbacks like this: size_t (*read_func) (void *ptr, size_t size, size_t nmemb, void *datasource); |
| 12:23:30 | BitPuffin | Araq: you scared me when you said that opengl is screwed up |
| 12:23:47 | EXetoC | Araq: it's really not possible? oh well. still, this is a pretty neat solution, so whatever |
| 12:24:09 | Araq | well Nimrod has special compiler support for dynamic loading of opengl |
| 12:24:19 | EXetoC | right |
| 12:24:22 | Araq | and it still can't be abstracted away |
| 12:24:26 | fowl | BitPuffin, make that a typedef renaming read_func to ov_read_func |
| 12:24:30 | Araq | so ... yes. it's fucked up |
| 12:24:36 | fowl | BitPuffin, here ill make a gist |
| 12:24:44 | * | BitPuffin is processing |
| 12:24:46 | Araq | afaict microsoft is too blame for this |
| 12:24:53 | BitPuffin | seriously I'm gonna go get some water |
| 12:25:04 | Araq | ms wouldn't update their shitty opengl drivers so people had to be creative |
| 12:25:28 | Araq | and came up with novel ways to do dynamic loading |
| 12:26:04 | EXetoC | I love competition |
| 12:27:09 | fowl | BitPuffin, https://gist.github.com/fowlmouth/7768397 |
| 12:28:19 | BitPuffin | fowl: ah I see what you mean |
| 12:28:33 | BitPuffin | but why is this necessary? |
| 12:28:58 | BitPuffin | it's not even complaining about that struct? |
| 12:29:04 | BitPuffin | or is this for later |
| 12:29:22 | fowl | BitPuffin, for later, otherwise the type will translate with a bunch of anonymous function fields |
| 12:29:32 | BitPuffin | so that we could say ov_read_fuck in the OV_DEFAULT BLABLA |
| 12:29:35 | BitPuffin | ? |
| 12:30:20 | fowl | well presumably those default vtables are useful |
| 12:30:33 | BitPuffin | yeah |
| 12:30:43 | fowl | so if someone has vorbis code in c they can easily translate it to nimrod because OV_CALLBACKS_STREAMONLY is there |
| 12:31:20 | NimBot | Araq/Nimrod master a3d325b Araq [+0 ±1 -0]: don't use memset for temps unless necessary |
| 12:32:07 | BitPuffin | fowl: okay I've done it |
| 12:32:19 | BitPuffin | so now in the static blablas |
| 12:32:25 | fowl | looks like the rest of the file should translate fine |
| 12:32:35 | BitPuffin | I just put ov_read_func in front of fread? |
| 12:32:38 | BitPuffin | etc |
| 12:32:43 | fowl | for the statics just /* comment them out |
| 12:32:57 | BitPuffin | oh |
| 12:33:05 | BitPuffin | well I'm okay with that |
| 12:33:45 | BitPuffin | fowl: but now I don't get the defaults? |
| 12:34:05 | fowl | https://gist.github.com/fowlmouth/7768397#file-gistfile1-c-L22 |
| 12:34:27 | BitPuffin | vorbisfile.h(200, 33) Error: identifier expected, but found '*' |
| 12:34:47 | BitPuffin | ahhh |
| 12:35:30 | fowl | BitPuffin, for ex the STREAMONLY_NOCLOSE one would look like var OV_CALLBACKS_STREAMONLY_NOCLOSE* = TOVCallbacks(readFunc: fread) # the others are initialized to nil |
| 12:36:09 | BitPuffin | gotcha |
| 12:36:17 | BitPuffin | that's not so hard :) |
| 12:36:47 | BitPuffin | void (*filter)(float **pcm,long channels,long samples,void *filter_param),void *filter_param); |
| 12:36:52 | BitPuffin | it's whining about that though |
| 12:37:16 | BitPuffin | it doesn't like *filter |
| 12:37:29 | fowl | yea thats an anonymous func type |
| 12:37:51 | fowl | typedef void (*filter_cb)(float **pcm,long channels,long samples,void *filter_param); |
| 12:38:02 | fowl | before the func |
| 12:38:10 | BitPuffin | but still keep the old one? |
| 12:38:20 | fowl | then that line becomes: filter_cb filter, void *filter_param); |
| 12:39:02 | Araq | fowl: omg you used "_cb" as a suffix. Now I'm confused for good. Never heard of something called a "callback". Your code is cryptic! I programmed for 2 days now and can't understand it! |
| 12:39:17 | Araq | sorry, couldn't resist |
| 12:39:19 | BitPuffin | Araq: shh |
| 12:39:34 | fowl | lol |
| 12:39:49 | BitPuffin | fowl: you sure you got the parenthesis right? |
| 12:40:03 | fowl | where |
| 12:40:13 | BitPuffin | filter_cb filter, void *filter_param); |
| 12:40:23 | fowl | yea |
| 12:40:32 | BitPuffin | oh right |
| 12:40:33 | fowl | thats the last two params for ov_read_filter() |
| 12:40:36 | BitPuffin | it's part of the entire noodle |
| 12:40:49 | fowl | you owe me a fraction of a bitcoin |
| 12:41:05 | BitPuffin | we don't even know if we are done yet! |
| 12:42:15 | BitPuffin | and pff :P |
| 12:42:18 | fowl | im sure thats all thats needed |
| 12:42:25 | BitPuffin | I might tip you when the game is done |
| 12:42:38 | BitPuffin | if people buy it |
| 12:42:39 | BitPuffin | :P |
| 12:43:00 | fowl | wonder how many games people are selling for bitcoins only |
| 12:43:47 | fowl | selling their games* |
| 12:43:55 | BitPuffin | humblebundle? |
| 12:43:59 | fowl | or other computer works |
| 12:49:34 | BitPuffin | uhhh |
| 12:49:43 | BitPuffin | Do i need to also wrap codec.h? |
| 12:50:23 | BitPuffin | proc (ptr: pointer; lol c2nim you a funny guy |
| 12:52:00 | BitPuffin | or can I just C include it with a pragma or something |
| 12:56:07 | BitPuffin | size_t is just int in nimrod right? |
| 12:56:41 | BitPuffin | yeah it is |
| 12:59:06 | BitPuffin | yeah I have to wrap some of codec at least |
| 12:59:25 | fowl | size_t is csize |
| 13:00:28 | BitPuffin | or actually ogg |
| 13:00:45 | BitPuffin | fowl: are you sure? |
| 13:00:55 | BitPuffin | Araq: DAddYE: wrapping size_t to int is the way to go |
| 13:01:25 | EXetoC | see system.nim :p |
| 13:02:47 | BitPuffin | Araq: your quotes don't hold up |
| 13:02:48 | * | Varriount_ joined #nimrod |
| 13:03:15 | EXetoC | but I thought size_t was an unsigned type |
| 13:03:21 | BitPuffin | me too |
| 13:03:50 | BitPuffin | c2nim should really know about this stuff |
| 13:04:10 | BitPuffin | is there a good reason that it doesn't do the conversion for us? |
| 13:06:09 | * | Varriount quit (Ping timeout: 246 seconds) |
| 13:06:09 | * | Varriount_ is now known as Varriount |
| 13:06:40 | fowl | yes |
| 13:06:43 | fowl | the government |
| 13:07:20 | BitPuffin | makes sense |
| 13:11:08 | * | girvo quit (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 13:18:20 | * | zahary_ left #nimrod (#nimrod) |
| 13:36:23 | * | Kooda joined #nimrod |
| 13:40:18 | Araq | hi Kooda welcome |
| 13:40:28 | Kooda | Hi! |
| 13:40:46 | Kooda | I just discovered this project and read the 2 manuals, seems quite nice! |
| 13:44:15 | Araq | thanks |
| 13:44:30 | fowl | dirkk0, thanks for the PRs, i added you as a collaborator so you can push future changes |
| 13:48:30 | BitPuffin | Araq: err, how do I alias a type |
| 13:48:37 | BitPuffin | type T = int? |
| 13:48:44 | BitPuffin | yeah |
| 13:48:50 | fowl | template T: expr = int |
| 13:48:55 | BitPuffin | I'm not smart today |
| 13:48:56 | fowl | const T = int |
| 13:49:06 | fowl | dont listen to me |
| 13:49:13 | * | fowl is poor |
| 13:50:30 | Kooda | Araq: in fact, the idea of a Lispy C, with manual memory managment possible, tiny runtime, static typing… has been in my mind for quite some time now ^^' |
| 13:57:39 | Kooda | Build successful on NetBSD x86 :D |
| 13:59:03 | fowl | Kooda, hope you are building from github |
| 13:59:07 | Kooda | Yep |
| 13:59:12 | BitPuffin | proc streamPageoutFill*(os: ptr TStreamState; og: ptr TPage; nfill: cint): cint {.cdecl.} |
| 13:59:13 | fowl | good stuff |
| 13:59:21 | BitPuffin | not sure why it expects an implementation of that one |
| 13:59:27 | BitPuffin | but not ether ones that look the same |
| 13:59:40 | fowl | BitPuffin, it has to come from somewhere |
| 13:59:46 | fowl | you need importc/dynlib |
| 14:00:16 | BitPuffin | but there are sooo many other procs above it that looks exactly the same |
| 14:00:17 | fowl | BitPuffin, you can do {.push callconv:cdecl, dynlib:libname.} before your functions so you can leave those off |
| 14:00:25 | fowl | BitPuffin, upload what you have please? |
| 14:00:29 | BitPuffin | yaman |
| 14:01:08 | BitPuffin | https://bitbucket.org/BitPuffin/nim-ogg |
| 14:01:09 | BitPuffin | fowl: ^ |
| 14:01:34 | BitPuffin | yeah the when defined blah is going away |
| 14:02:19 | fowl | its secret |
| 14:02:32 | BitPuffin | it is? |
| 14:02:40 | fowl | You do not have access to this repository. |
| 14:02:41 | BitPuffin | try again |
| 14:03:00 | fowl | ok |
| 14:03:09 | Araq | Kooda: sometimes I think Nimrod is just too weird even for Lispers. :P |
| 14:03:24 | BitPuffin | fowl: you are gonna die when you realize that I'm gonna make nim-vorbis depend on this library |
| 14:03:30 | Kooda | Araq: why? :o |
| 14:03:47 | fowl | BitPuffin, why not just put them together |
| 14:03:55 | fowl | BitPuffin, this is part of vorbis isnt it |
| 14:03:58 | BitPuffin | fowl: because ogg is also a container for theora |
| 14:04:14 | BitPuffin | so if someone ever wants to wrap theora they can use this |
| 14:04:27 | BitPuffin | fowl: you are not a big fan of modularity are you :D |
| 14:04:32 | BitPuffin | anyways back to the wrapping |
| 14:05:15 | fowl | i dunno why it complains about that function as opposed to any other, they all need to be implemented though |
| 14:05:23 | BitPuffin | yeah |
| 14:05:54 | fowl | you can also push importc if the function names are the same as they are in c |
| 14:06:05 | BitPuffin | but I should just add {.push dynlib:"libogg.so".} or whatever |
| 14:06:24 | BitPuffin | fowl: well I have renamed them |
| 14:06:28 | BitPuffin | so I'll have to do it manually |
| 14:06:31 | fowl | they have a prefix? |
| 14:06:37 | BitPuffin | yeah |
| 14:06:39 | BitPuffin | and sometimes even > |
| 14:06:42 | BitPuffin | _* |
| 14:06:44 | BitPuffin | which is not even legal |
| 14:06:46 | BitPuffin | it's illegal |
| 14:06:48 | BitPuffin | don't they know |
| 14:06:51 | fowl | importc: "prefix_$1" |
| 14:06:57 | fowl | oh yea thats an issue then |
| 14:07:25 | BitPuffin | could I do that and importc: "_prefix_$1" ? |
| 14:07:28 | fowl | well i would make a {.pragma.} for importc: "prefix_$1" then so you only have to bother with the weird-named functions |
| 14:07:36 | fowl | yea |
| 14:08:19 | fowl | i dont see __ in ogg.h |
| 14:08:39 | BitPuffin | oh oh wait |
| 14:08:46 | BitPuffin | it's because c2nim stripped the prefix |
| 14:08:58 | fowl | aw you butchered the names |
| 14:09:03 | BitPuffin | yap |
| 14:09:09 | fowl | sucks |
| 14:09:14 | BitPuffin | bawls |
| 14:09:24 | fowl | otherwise |
| 14:09:29 | fowl | this could have been a real purdy wrapper |
| 14:09:49 | fowl | with tons of {.pop.} {.push importc: "ogg_page_$1".} |
| 14:10:10 | BitPuffin | what is purdy |
| 14:10:12 | BitPuffin | haha |
| 14:11:13 | fowl | https://www.youtube.com/watch?v=jVDN8yR3ig0 |
| 14:11:18 | Araq | Kooda: we have T/P prefixes, comments as part of the AST, a strange templates/macros split, no dynamic typing, no homoiconity, no "class" keyword, no interfaces, "type" sections are offending by themselves etc. etc. |
| 14:12:34 | Araq | oh and we use "proc" instead of "def" or "func" |
| 14:12:39 | Kooda | Ahaha |
| 14:12:57 | Kooda | Well, for now, it looks good to me :Þ |
| 14:13:06 | Araq | there is enough to dislike for everybody :P |
| 14:13:08 | Kooda | (and, comments in the AST, that’s awesome! :D) |
| 14:13:24 | BitPuffin | that doesn't happen often |
| 14:14:08 | Araq | BitPuffin: I'm copying your style ;-) |
| 14:14:16 | Araq | scaring away new users |
| 14:14:21 | BitPuffin | Araq: :D |
| 14:14:37 | Kooda | I’m not scared yet. :’° |
| 14:14:43 | Araq | damn lol |
| 14:15:18 | Kooda | When I saw the part on OOP in the tutorial 2, I was so happy… :D |
| 14:15:20 | BitPuffin | he's a brave one |
| 14:15:40 | BitPuffin | what part again? |
| 14:15:40 | Kooda | (I’m not a huge fan of OOP in general) |
| 14:16:01 | Kooda | “While Nimrod's support for object oriented programming (OOP) is minimalistic, powerful OOP technics can be used. OOP is seen as one way to design a program, not the only way. Often a procedural approach leads to simpler and more efficient code. In particular, prefering composition over inheritance is often the better design.” |
| 14:16:34 | BitPuffin | ah |
| 14:16:37 | BitPuffin | yeah |
| 14:16:55 | BitPuffin | well preferring composition over inheritance is a part of some OOP principle too isn't it? |
| 14:17:43 | Araq | yeah it's the principle "forget about inheritance and when you do composition you don't need dynamic binding either" |
| 14:17:59 | Araq | "oh and then nothing of the classical OO is left" |
| 14:18:08 | Kooda | ^^' |
| 14:18:10 | Araq | "but don't say that too loud" |
| 14:18:21 | BitPuffin | http://en.wikipedia.org/wiki/Liskov_substitution_principle |
| 14:18:26 | Araq | it's the "OO doesn't work"-principle of OO |
| 14:18:34 | BitPuffin | hahaha :D |
| 14:18:35 | Kooda | Hehe |
| 14:33:21 | * | dirkk0 quit (Quit: Leaving) |
| 14:45:14 | BitPuffin | man this wrapping is tedious :P |
| 14:45:38 | BitPuffin | gonna finish ogg and then eat lunch |
| 14:56:40 | EXetoC | lunch? lies |
| 14:57:25 | EXetoC | BitPuffin: will upload the lib some time today |
| 15:07:40 | BitPuffin | https://bitbucket.org/BitPuffin/nim-ogg/src/55898eaef9e6b712073026523b9a7ff40c8a9154/src/ogg/ogg.nim?at=default does this look fine to you guys? |
| 15:07:52 | BitPuffin | it compiled at least lol |
| 15:08:05 | BitPuffin | I'm not gonna bother fixing the names for now |
| 15:08:09 | BitPuffin | in types |
| 15:08:12 | BitPuffin | procs are however nice |
| 15:10:39 | fowl | the functions still have prefixes |
| 15:11:34 | fowl | you can reduce noise by just pushing the pragmas in comogg |
| 15:34:06 | Araq | ping OrionPKM |
| 15:37:25 | OrionPKM | what's up araq |
| 15:38:33 | Araq | my todo.txt says "simple closure iterator doesn't work" |
| 15:38:43 | Araq | and I remember you trying something like: |
| 15:38:56 | Araq | iterator mycountup(a, b: int): int {.closure.} = |
| 15:38:58 | Araq | for i in a..b: yield i |
| 15:39:07 | Araq | but this works flawlessly for me ... |
| 15:39:25 | OrionPKM | hm |
| 15:39:26 | Araq | do you still have your gist? |
| 15:40:36 | OrionPKM | I vaguely recall that, dont remember if there was a gist |
| 15:40:50 | OrionPKM | unless |
| 15:40:50 | OrionPKM | https://gist.github.com/onionhammer/5809996 |
| 15:40:52 | OrionPKM | that's it |
| 15:42:18 | OrionPKM | yeah it works for me now, you must have unwittingly fixed it in the past :) |
| 15:43:03 | BitPuffin | fowl: what do you mean still have prefixes |
| 15:43:21 | BitPuffin | ah you mean pack and stream etc? |
| 15:43:41 | BitPuffin | I think I'm gonna keep thos |
| 15:43:44 | BitPuffin | e |
| 15:43:48 | BitPuffin | because they keep things grouped |
| 15:44:01 | BitPuffin | I just don't think the ogg prefix is necessary |
| 15:44:04 | BitPuffin | since it is in the ogg module |
| 15:45:51 | Araq | OrionPKM: alright thanks |
| 15:49:15 | * | mflamer joined #nimrod |
| 15:50:03 | Araq | hi mflamer, I got your message |
| 15:50:35 | mflamer | Goodmorning Araq |
| 15:51:38 | Araq | well it depends on what you're implementing; if the field name is not in multiple branches it's obvious which struct type to use |
| 15:52:17 | Araq | it might not be *safe* but that's a different problem |
| 15:53:15 | Araq | access to a field of an ADT is usually enforced to go through pattern matching which ensures the safety properties |
| 15:54:06 | Araq | but I'm not sure how far you want to take your research project |
| 15:57:13 | Icefoz | Wait, Nimrod's stdlib is entirely source? It appears to compile the bits it needs on the fly and cache them. |
| 15:57:20 | Icefoz | That's so cool. Goofy, but cool. |
| 15:58:16 | Araq | you can build a nimrtl.dll and use that instead. Though apparently there is a new regression which prevents that from working. |
| 15:59:39 | mflamer | Thats a good point Araq |
| 16:01:29 | Icefoz | I assume it does pretty much the same thing when building non-stdlib projects? |
| 16:04:56 | Icefoz | Looks like it does, so. |
| 16:05:18 | Araq | Icefoz: the compiler doesn't know what a stdlib project is |
| 16:05:40 | Icefoz | Makes sense. |
| 16:14:15 | * | mflamer quit (Ping timeout: 272 seconds) |
| 16:18:22 | Varriount | Icefoz, what do you mean, entirely from source? Don't most compilers build from source? |
| 16:20:27 | Icefoz | Varriount: Yeah, but most compilers also pre-compile and archive their standard library. It just vaguely surprised me. |
| 16:21:54 | Varriount | Icefoz, well, for what it's worth, compilation is pretty fast. No huge long configure scripts to run :D |
| 16:23:19 | Araq | yay Varriount is back :-) |
| 16:23:20 | Icefoz | Yep. |
| 16:26:24 | EXetoC | BitPuffin: nah, couldn't resist making my own matrix stuffs :> |
| 16:33:35 | * | Varriount_ joined #nimrod |
| 16:37:02 | * | Varriount quit (Ping timeout: 240 seconds) |
| 16:37:03 | * | Varriount_ is now known as Varriount |
| 16:41:10 | NimBot | nimrod-code/packages master 168a5fa Isak Andersson [+0 ±1 -0]: Add nim-ogg |
| 16:41:10 | NimBot | nimrod-code/packages master 5e35951 Dominik Picheta [+0 ±1 -0]: Merge pull request #35 from BitPuffin/master... 2 more lines |
| 16:41:20 | * | MFlamer joined #nimrod |
| 16:43:47 | BitPuffin | EXetoC: noob :/ |
| 16:43:53 | BitPuffin | yay dom96 :D |
| 16:44:30 | BitPuffin | EXetoC: and all the goodies are going in today |
| 16:44:32 | BitPuffin | pff |
| 16:45:13 | BitPuffin | wtf |
| 16:45:33 | BitPuffin | https://gist.github.com/BitPuffin/7772643 |
| 16:45:50 | BitPuffin | getting invalid indentation on the when line |
| 16:47:17 | BitPuffin | or no on the elif line |
| 16:48:10 | OrionPKM | what are you using ogg for? |
| 16:48:41 | BitPuffin | OrionPKM: vorbis |
| 16:52:11 | BitPuffin | WHY IS IT INVALID INDENTATION IT ISN'T EVEN |
| 16:52:17 | * | BitPuffin ragequits |
| 16:52:21 | Kooda | :o |
| 16:53:40 | BitPuffin | Araq: why doesn't poop |
| 16:54:57 | BitPuffin | oh wait the error wasn't in that file even |
| 16:55:03 | BitPuffin | xD |
| 16:57:01 | Varriount | Idea - Make a magic macro that, at compile time, reads in a template config file and constructs a routine to parse it, and at runtime, parses the actual config file, replacing/throwing errors if neccessary. |
| 16:57:53 | Icefoz | Varriount: Isn't that called a parser generator? |
| 16:58:38 | Varriount | Icefoz, a parser generator is ussually for freeform languages. I mean, something that would parse a *.ini file |
| 16:59:22 | Varriount | Currently I'm going through huge, 150 line block of code that does nothing but act on the parameters in a .ini file. |
| 17:01:03 | * | brson joined #nimrod |
| 17:01:25 | Varriount | Icefoz, have you read on nimrod's source filters? |
| 17:02:08 | BitPuffin | What's the equivalent of FILE in nimrod? |
| 17:02:28 | BitPuffin | CFile? |
| 17:02:43 | BitPuffin | yeah |
| 17:03:01 | Araq | FILE* is TFile |
| 17:03:50 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 17:04:48 | Icefoz | It'd be a limited-case parser. It actually sounds devestatingly useful. |
| 17:05:00 | Icefoz | Varriount: Not yet. |
| 17:05:06 | OrionPKM | bitpuffin what about vorbis |
| 17:05:11 | Kooda | Any Nimrod developper making games? :Þ I was wondering if I would try the coming Ludum Dare in Nimrod :3 |
| 17:05:50 | Icefoz | CRAP I've just re-invented XML schemas. |
| 17:06:12 | OrionPKM | Kooda there are a lot of people here interested in making games, but I dont know any actual active games in development |
| 17:06:23 | Araq | Varriount: so what would the declarative syntax you propose? on "blah" do: someVar = someValue ? |
| 17:06:38 | Araq | do you realize how close that is to the string case? |
| 17:06:42 | Kooda | OrionPKM: ok |
| 17:07:44 | BitPuffin | OrionPKM: sound |
| 17:08:14 | OrionPKM | I know what ogg is bitpuffin :P |
| 17:08:25 | OrionPKM | I was just curious if you were working on something interesting that makes use of it |
| 17:08:53 | Kooda | Making noise with nimrod? :’° |
| 17:08:56 | EXetoC | games ofc |
| 17:09:33 | Icefoz | Okay, now that I've gone through the tutorials, Nimrod is still disturbingly close to the programming language idea I've been cooking up for the last couple months. |
| 17:09:44 | EXetoC | such languages will always be supported by plenty of game devs :> |
| 17:09:49 | Kooda | Icefoz: welcome to the club! :D |
| 17:10:07 | EXetoC | Icefoz: great |
| 17:10:10 | MFlamer | Icefoz: Thats a common theme here |
| 17:10:11 | Icefoz | Except that 10% which is things I either didn't think of, didn't worry about, or wouldn't have put in, which makes it feel a little demented. |
| 17:10:14 | BitPuffin | OrionPKM: ah, yeah a game |
| 17:10:28 | BitPuffin | set to release on the 26th but that's impossible but hey I'm going for it anyway |
| 17:10:39 | MFlamer | Its like a utopian refugee camp |
| 17:10:54 | Kooda | hahah |
| 17:11:24 | MFlamer | Here's some koolaid |
| 17:12:37 | Icefoz | At least the demented bits are consistent. |
| 17:14:15 | Icefoz | Question, is Nimrod designed for systems-level/embedded programming? Could you easily write an OS kernel in it, or program an Arduino? |
| 17:14:28 | Icefoz | It _looks_ like it, but I don't know enough about the runtime yet. |
| 17:15:10 | EXetoC | https://github.com/dom96/nimkernel |
| 17:15:52 | EXetoC | BitPuffin: you're talking about a squared matrix type, but won't a simple cast do? |
| 17:16:04 | EXetoC | that's my approach when accessing individual elements with a single index |
| 17:16:26 | EXetoC | or am I missing something? |
| 17:16:52 | dom96 | Kooda: I participated in LD with Nimrod a while back |
| 17:17:07 | dom96 | Didn't manage to get my game finished though because I suck at art heh |
| 17:17:20 | EXetoC | procedural art ftw |
| 17:17:44 | Varriount | Icefoz, yes. |
| 17:18:30 | Varriount | The GC is pretty optimized, and you can inline assembler statements. You can also do without the GC or type information altogether. |
| 17:18:53 | Varriount | Nimrod is translated to C, if you didn't already know. |
| 17:19:26 | EXetoC | not that that alone means much, but yeah |
| 17:26:22 | Icefoz | Varriount: Thanks. |
| 17:27:14 | Varriount | Icefoz, I think someone got nimrod to run on an embedded system (64kb of something?) |
| 17:29:22 | BitPuffin | EXetoC: I'm talking about a squared matrix type? |
| 17:29:27 | BitPuffin | that might be old news |
| 17:29:32 | BitPuffin | I decided to skip that |
| 17:30:28 | EXetoC | BitPuffin: in that source comment |
| 17:30:30 | EXetoC | ok |
| 17:34:29 | Icefoz | Is there an inverse to the ord() function? Something that will take an integer and turn it into the specified enum, if possible? |
| 17:34:49 | * | DAddYE_ joined #nimrod |
| 17:37:11 | Icefoz | Another random question, is there any runtime reflection? |
| 17:37:20 | * | DAddYE_ quit (Remote host closed the connection) |
| 17:37:27 | Varriount | Icefoz, in what way? |
| 17:37:56 | * | DAddYE_ joined #nimrod |
| 17:38:05 | dom96 | Icefoz: I think you can just cast your int to that enum |
| 17:38:12 | Varriount | Also, you *might* try casting the- yeah |
| 17:38:48 | Icefoz | Cast, or convert? |
| 17:39:01 | BitPuffin | gotta go! be back soon |
| 17:39:08 | Varriount | Icefoz, cast |
| 17:39:16 | Varriount | cast[type](value) |
| 17:39:22 | * | BitPuffin quit (Quit: WeeChat 0.4.2) |
| 17:39:34 | Varriount | cast[MyEnum](3) |
| 17:40:04 | dom96 | no |
| 17:40:09 | dom96 | MyEnum(3) |
| 17:40:24 | Varriount | Oh. :/ |
| 17:42:04 | * | shodan45 quit (Quit: Konversation terminated!) |
| 17:42:16 | Araq | Icefoz: in general runtime reflection is considered a design flaw in Nimrod |
| 17:42:33 | Araq | there is marshal.nim to serialize arbitrary data structures though |
| 17:42:52 | Icefoz | If you have to reflect at runtime, you should be doing it with compile-time rewriting? |
| 17:43:04 | Varriount | H/E There's a remarkable amount of information that can be extracted at compile tine |
| 17:43:06 | Araq | Icefoz: that's the general idea, yes |
| 17:43:06 | Varriount | *time |
| 17:43:11 | Icefoz | Okay. |
| 17:44:12 | Varriount | Icefoz, if you really need such things: http://nimrod-lang.org/system.html#517 |
| 17:44:24 | Varriount | Also, typeinfo.nim |
| 17:47:26 | Icefoz | Cool, thanks. |
| 17:47:49 | Varriount | Araq, under what circumstance would instanciationinfo().line return -1? |
| 17:48:51 | * | zielmicha joined #nimrod |
| 17:51:39 | * | achim joined #nimrod |
| 17:53:25 | Araq | Varriount: when there is no instanstiation going on |
| 17:53:57 | Araq | Varriount: what's the state of your lambda lifting improvements btw? I'm working on that part too now |
| 17:54:11 | Araq | hi achim welcome |
| 17:54:26 | Varriount | Araq, I got stuck at simply allowing the isInnerProc to accept iterators. |
| 17:54:36 | achim | hi Araq, thanks! |
| 17:54:47 | Araq | dom96, Icefoz type conversion instead of 'cast' for enums is preferable |
| 17:54:52 | * | Varriount is scatterbrained |
| 17:55:23 | Varriount | Araq, what's your progress? |
| 17:59:59 | achim | Araq: regarding this compiler error: https://gist.github.com/achim/7733214 - that seems to be clang-related. a gcc-built nimrod is fine on both osx and ubuntu, and clang builds fail on both systems. do you accept clang-related bug reports or is clang officially unsupported? |
| 18:00:39 | Araq | achim: on the contrary, clang is the default for mac now |
| 18:00:49 | Araq | so we need to ensure it works |
| 18:01:16 | Araq | Varriount: haven't started yet really. But I feel like working on something simple :P |
| 18:01:32 | OrionPKM | you said LINQ would be easy, work on that :P |
| 18:02:49 | Varriount | Araq, is there some more reliable method for retrieving the current line of the program, even if it's only for debug builds? |
| 18:03:14 | Varriount | getStackInfo() reports the correct line information. |
| 18:03:33 | Varriount | However I don't need the full stack information, just the line numbers |
| 18:03:47 | EXetoC | you could wrap it in a template |
| 18:03:52 | EXetoC | not a good solution? |
| 18:03:57 | Araq | well patch the stdlib to provide that information, Varriount :P |
| 18:04:00 | Varriount | EXetoC, no. |
| 18:05:19 | MFlamer | Araq: seems your comment regarding pattern matching on ADT's as the way to ensure safe field access is logical. But, i'll have to see if this implies some hardcoded patternmatching in the language, which you have managed to isolate to macros so far |
| 18:07:41 | Araq | Varriount: system/excpt.nim contains the stack trace generation code |
| 18:08:34 | Araq | the logic is convoluted because it only has a static array to work with, when you use a 'seq' it's much easier |
| 18:10:43 | * | Varriount_ joined #nimrod |
| 18:10:49 | Varriount_ | Ok, something is off with my connection. |
| 18:11:12 | * | Varriount quit (Disconnected by services) |
| 18:11:12 | * | Varriount_ is now known as Varriount |
| 18:11:33 | * | capisce quit (Read error: Operation timed out) |
| 18:16:20 | * | capisce joined #nimrod |
| 18:16:30 | * | Hannibal_Smith joined #nimrod |
| 18:23:51 | Varriount | Araq, nimrod only writes the last 32 frames for stack trace info? |
| 18:25:05 | * | dirkk0 joined #nimrod |
| 18:26:05 | Araq | Varriount: no it writes 128, the first 32 then '...' and then the last 95 |
| 18:26:27 | Varriount | Ah, ok. |
| 18:27:50 | Varriount | Araq, I can't help but thinks that, compared to the internals of a gcc/llvm (or at least, the part's that I've seen) the nimrod compiler internals are relatively easier to read, even if not always easy to follow |
| 18:28:15 | Varriount | I can actually understand the stack trace procedures without developing a migraine. |
| 18:28:46 | Araq | impossible. I'm sure I used abbrevs there too. :-) |
| 18:29:28 | Varriount | Araq, though you used abbreviations, you tend to use them only where they actually make sense, and can be inferred out. |
| 18:29:45 | Araq | oh wow. thanks |
| 18:30:31 | Varriount | Also, because you see type information much more in nimrod than, say, python, descriptive variable names are not *quite* so important |
| 18:30:58 | Araq | ah enough of it |
| 18:31:16 | Araq | I'm not used to compliments, can't handle them |
| 18:31:25 | Araq | :-) |
| 18:32:46 | Varriount | I wish I could write a research paper things like that, rather than the boring subjects my composition professor prefers. |
| 18:32:50 | OrionPKM | i just hate when he abbreviates function names because they're keywords :P |
| 18:32:53 | Varriount | *on things |
| 18:33:24 | EXetoC | OrionPKM: you prefer `type`? |
| 18:33:30 | Varriount | OrionPKM, same, but for modules |
| 18:33:35 | OrionPKM | yes |
| 18:33:38 | OrionPKM | typ |
| 18:33:39 | OrionPKM | :P |
| 18:33:54 | Varriount | when I see strutils, I always think "StructUtils" |
| 18:34:02 | OrionPKM | yah, that too |
| 18:34:17 | OrionPKM | sometimes he gets a bit carried away w/ the abbreviations |
| 18:34:28 | Hannibal_Smith | I honestly don't like any form of abbreviation :O |
| 18:34:37 | OrionPKM | you a C# programmer? :) |
| 18:34:40 | Hannibal_Smith | Yes |
| 18:34:46 | * | CarpNet quit (Quit: Leaving) |
| 18:34:48 | OrionPKM | how did I guess |
| 18:35:04 | Varriount | OrionPKM, he could have also been a Python programmer. :P |
| 18:35:40 | OrionPKM | C# gets pretty wordy, but I HATE seeing abbreviations in it |
| 18:35:56 | Varriount | OrionPKM, Don't forget Java |
| 18:35:57 | Hannibal_Smith | Writing long names is not a problem with Visual Studio |
| 18:36:00 | OrionPKM | yeah |
| 18:36:23 | Hannibal_Smith | And writing is only "one time", read is "many times" |
| 18:36:34 | OrionPKM | who was it that was workng on the visual studio plugin |
| 18:36:37 | OrionPKM | for nimrod |
| 18:36:38 | Araq | yes. And I prefer the abbrevs for reading. |
| 18:36:43 | Hannibal_Smith | Ahahaha |
| 18:36:49 | Varriount | Hannibal_Smith, except when long names cause 180 character lines. |
| 18:37:04 | EXetoC | I prefer abbreviations as long as it's relatively clear what it stands for |
| 18:37:07 | OrionPKM | abbrevs are fine for reading, typically.. it's writing that sucks because you have to look up the exact abbreviation for what you want |
| 18:37:14 | Hannibal_Smith | Varriount, there don't really exist in the .Net BLC |
| 18:37:17 | Araq | it's the natural thing to do when you use a word very often |
| 18:37:24 | Araq | you make it shorter |
| 18:37:44 | Hannibal_Smith | Well, even .Net abbreviate thing like pointer to ptr |
| 18:38:05 | Araq | and many technical terms in english are taken over from latin which has many long words |
| 18:38:19 | Varriount | BroadcastButtonFactoryList.addFactory(BroadcastButtonFactory<CheesyOneWayButton>(20, CheeseTypes.MexicanCheese)) |
| 18:38:47 | Varriount | ^ Why I dislike java |
| 18:38:49 | EXetoC | cheese. yum |
| 18:39:10 | EXetoC | factories, biatch! |
| 18:39:11 | Hannibal_Smith | Varriount, probably is more a fault of the OOP...probably |
| 18:39:15 | OrionPKM | Araq speaking of abbreviation, some way to abbreviate proc's would be nice ;) |
| 18:39:35 | EXetoC | wut |
| 18:39:36 | Araq | btw I wrote the compiler initially in Pascal. You can't blame me for being a lazy typist! |
| 18:39:38 | Varriount | OrionPKM, leave Araq alone, he's trying to fix bugs. |
| 18:39:50 | OrionPKM | hehe |
| 18:39:55 | Varriount | I would prefer bugs to be fixed before new features are added. |
| 18:40:10 | OrionPKM | yeah yeah |
| 18:40:23 | Araq | begin begin begin end end end # argh, just kill me already |
| 18:40:47 | Varriount | Now, how to get the last frame in the stack... |
| 18:40:51 | Araq | though the typing is an issue too when you're writing code to debug things |
| 18:41:09 | Hannibal_Smith | Why? |
| 18:41:23 | OrionPKM | proc (x: type): string = ... vs. (x:type) => ... |
| 18:41:32 | Araq | Varriount: the very first frame is the "last frame" |
| 18:41:57 | Araq | it's reversed since it's a singly linked list |
| 18:42:34 | dom96 | some way to abbreviate proc types would be nice indeed. |
| 18:45:24 | OrionPKM | oh, distnct that's another one |
| 18:45:24 | OrionPKM | :P |
| 18:45:29 | Kooda | Then we would need a way to abbreviate this abbreviation |
| 18:45:43 | OrionPKM | x: type => ... |
| 18:45:51 | OrionPKM | x => |
| 18:45:51 | Kooda | D: |
| 18:46:06 | Kooda | => # magic function that does everything |
| 18:46:07 | OrionPKM | type inference magic! |
| 18:46:52 | Varriount | Araq, I'll likely have a line info proc done by the end of the day, do you want me to submit a pull request? Also, Thanks for the help. |
| 18:47:05 | Kooda | Oh, I saw “lambda” is a reserved keyword, but I didn’t find anything about lambdas in the manual. :o |
| 18:47:22 | Araq | well managed to get lambdas with the "proc" keyword |
| 18:47:23 | Varriount | Kooda, some words are reserved for future use |
| 18:47:51 | EXetoC | Hannibal_Smith: because it's really annoying to have to type much in some situations |
| 18:47:55 | Varriount | Anyone here want to try out my Sublime Text tmLanguage file for nimrod? |
| 18:48:19 | EXetoC | and readability doesn't really matter when you're making lots of local changes. that can be dealt with when the bug has been fixed or whatever |
| 18:48:35 | OrionPKM | Varriount I have my own tmLanguage |
| 18:48:50 | Varriount | OrionPKM, and you haven't published it? |
| 18:48:51 | MFlamer | Varriount: yes, I have my own but would like to try yours also |
| 18:48:57 | OrionPKM | and integration w/ nimrod idetools |
| 18:48:57 | Araq | Varriount: I would like to have it in some other module, but I can see that's much more work |
| 18:49:00 | EXetoC | Hannibal_Smith: if you were even referring to that |
| 18:49:13 | Araq | extracting these things from system.nim ain't easy |
| 18:49:20 | Varriount | Araq, I don't even know how I would get it into another module. :/ |
| 18:49:26 | OrionPKM | Varriount Im also planning on adding better syntax highlighting for source code filters |
| 18:49:33 | Araq | yes, that's what I'm talking about |
| 18:49:55 | Varriount | OrionPKM, Why haven't you published the sublime text stuff then? |
| 18:50:20 | OrionPKM | it's not ready |
| 18:50:35 | OrionPKM | https://www.dropbox.com/s/84gtcgjmw2ec61r/Nimrod-Sublime.zip |
| 18:50:37 | OrionPKM | but you can try it out |
| 18:51:43 | Araq | OrionPKM: your comment about the writability of abbrevs is spot on, which is why we have http://nimrod-lang.org/apis.html |
| 18:52:25 | OrionPKM | Add distnct to that table |
| 18:52:48 | Araq | well I think we should rename that to "unique" |
| 18:53:05 | OrionPKM | yeah |
| 18:53:08 | Varriount | MFlamer, https://gist.github.com/Varriount/7775253 |
| 18:53:19 | MFlamer | thanks |
| 18:53:20 | Varriount | MFlamer, it's very much a side project |
| 18:53:26 | EXetoC | *common* abbrevs are indeed not bad at all |
| 18:53:36 | Varriount | Mainly just to familiarize myself with regex and such. |
| 18:53:48 | Varriount | EXetoC, except for 'str' |
| 18:54:11 | Varriount | 'str' - Is it a struct, or a string? No one knows! |
| 18:54:39 | MFlamer | sounds similar to what I have. Did OrionPKM say he is using IDE tools in his? That would be awsome |
| 18:55:22 | Varriount | MFlamer, my biggest grievence is that you can include other regexes in match rules. Meaning quite a bit a duplication |
| 18:55:31 | Varriount | *you can't |
| 18:55:36 | EXetoC | Varriount: well, I can't recall ever seeing 'str', where it's an abbreviation of anything other than 'string' |
| 18:56:32 | EXetoC | anyway, string is already short |
| 18:57:53 | MFlamer | Varriount: you wrote a JSON file then used the converter to XML, right? |
| 19:00:19 | Varriount | MFlamer, Yeah. I attached both versions to the gist. |
| 19:00:34 | Varriount | The plugin I use is AAAPackageDev |
| 19:00:53 | MFlamer | I diddnt see the JSON file, I'll look again |
| 19:00:56 | Varriount | MFlamer, It's actual YAML |
| 19:01:14 | MFlamer | I dont even know what YAML is |
| 19:01:23 | Varriount | A markup language for humans. |
| 19:01:35 | OrionPKM | I've just been editing the XML straight up |
| 19:01:39 | Varriount | Think reStructured text. |
| 19:01:48 | OrionPKM | AAAPackageDev would probably be preferable |
| 19:01:49 | Varriount | OrionPKM, *shudder* |
| 19:02:01 | Varriount | OrionPKM, it can also translate XML to YAML |
| 19:02:16 | MFlamer | I found JSON much easier to work with |
| 19:06:45 | OrionPKM | varriount you should merge the plugins together |
| 19:07:16 | OrionPKM | lets make a new plugin and put it up on sublime package control |
| 19:07:25 | OrionPKM | the one that's up there isnt being maintained very well |
| 19:07:27 | MFlamer | enough of us seem to be using sublime that we should pool efforts |
| 19:07:53 | Araq | Varriount: YAML is in fact not a markup language, but a data description language |
| 19:08:02 | Araq | big difference |
| 19:08:23 | Araq | even though people didn't understand this difference and used XML for everything ... |
| 19:08:44 | OrionPKM | the main features of mine (based on the existing sublime PC) are treating discard """ ... """ as a comment like aporia and go-to-definition, |
| 19:13:50 | Varriount | OrionPKM, want me to start and create the repo? |
| 19:14:04 | * | Mat2 joined #nimrod |
| 19:14:08 | Mat2 | hi all |
| 19:14:17 | Araq | yay Mat2 is back |
| 19:14:19 | Varriount | Heeeeellllooooooo! |
| 19:14:38 | Mat2 | hi Araq and Varriount |
| 19:15:22 | OrionPKM | varriount sure, add me as a contributor |
| 19:15:33 | Mat2 | hi OrionPKM |
| 19:15:42 | OrionPKM | hi mat2 |
| 19:16:08 | Mat2 | Araq: Does Nimrod support tail-call recursion ? |
| 19:16:17 | Varriount | OrionPKM, any particular name? I'm thinking something along the lines of "NimLime |
| 19:16:23 | Varriount | *"NimLime" |
| 19:16:35 | Araq | Mat2: no; gcc does it when optimization is turned on |
| 19:16:37 | Varriount | Or "LimeRod" |
| 19:17:50 | OrionPKM | hmm.. |
| 19:18:17 | Varriount | Or we could just do "Sublime-Nimrod" |
| 19:19:03 | OrionPKM | yeah. just make sure the name isn't the same as thrr |
| 19:19:22 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 19:19:36 | OrionPKM | as the current one |
| 19:19:40 | Varriount | OrionPKM, which name? |
| 19:20:31 | * | Varriount_ joined #nimrod |
| 19:20:40 | Mat2 | Araq: hmm, I hope Clang and other compiler behave the same |
| 19:20:42 | * | Varriount quit (Disconnected by services) |
| 19:20:42 | * | Varriount_ is now known as Varriount |
| 19:20:45 | Varriount | OrionPKM, which name? |
| 19:21:02 | Araq | Mat2: clang and visual C++ do and I'm sure Intel does too |
| 19:21:21 | Araq | other compilers don't exist anymore |
| 19:22:37 | Mat2 | right, except PCC (OpenBSD) |
| 19:22:38 | Varriount | Doesn't the intel compiler cost, like, thousands or something? |
| 19:22:47 | OrionPKM | nimrod sublime |
| 19:22:58 | Mat2 | Varriount: Yes |
| 19:23:17 | Araq | so tell me: which large open source project does build with PCC? |
| 19:23:27 | Araq | can't think of any |
| 19:23:45 | Kooda | NetBSD builds with pcc afaik :Þ |
| 19:24:02 | Mat2 | OpenBSD will use PCC as replacement for GCC |
| 19:24:04 | Varriount | Araq, on native stack traces, where is the line information? |
| 19:24:43 | Kooda | Relying on compiler optimization is weird… |
| 19:24:43 | Varriount | I can't test it, because Windows doesn't support native stack traces (I think?) |
| 19:24:56 | Araq | that was before clang got stable, afaik |
| 19:25:20 | Araq | clang has the right license (TM) so the BSD guys should be happy with it |
| 19:25:57 | Araq | Kooda: it's the best we can do since we compile to C |
| 19:26:12 | zielmicha | Kooda: TCO is itself a compiler optimalization :) |
| 19:26:22 | Kooda | Araq: yes, but C standards doesn’t talk about tail-calls :Þ |
| 19:26:23 | Mat2 | Kooda: Well, a compiler to C is restricted in supported optimizations beside GCC specific extensions |
| 19:26:50 | Kooda | don’t* |
| 19:27:12 | Araq | actually we could do it like some scheme does and perform some heavy transformations |
| 19:27:17 | Kooda | zielmicha: of course, but it could be from nimrod, not from C. |
| 19:27:30 | Araq | then we can guarantee tail calls |
| 19:27:45 | Mat2 | Araq: That can be right (AFAIK as I know some OpenBSD developers doesn't want to relate on the LLVM infrstructure however) |
| 19:27:52 | Kooda | I only know about Chicken’s way (Continuation passing style) |
| 19:28:01 | Araq | yeah |
| 19:28:08 | Araq | I'm talking about Chicken |
| 19:28:11 | Kooda | :) |
| 19:28:53 | Mat2 | so it is doable |
| 19:29:11 | Araq | Mat2: why is that important for you again? you have your own native backend anyway ;-) |
| 19:29:29 | OrionPKM | brb |
| 19:29:55 | * | OrionPKM quit (Remote host closed the connection) |
| 19:30:10 | Araq | it's doable but then you can't translate function calls into C function calls and all hell breaks lose for C interop |
| 19:31:00 | Mat2 | Araq: Personally I prefer recursations and wan't to know about possible side-effects if I follow this style (stack overflows for example) |
| 19:31:30 | Mat2 | (recursations against loop constructs) |
| 19:31:44 | Araq | personally I wouldn't even call a tail recursive call a recursion :-) |
| 19:31:48 | EXetoC | *recursions |
| 19:31:58 | Mat2 | thanks, EXetoC |
| 19:32:29 | Varriount | Araq, when extracting information from native stack traces, where is the line information located? |
| 19:32:49 | Mat2 | brb |
| 19:32:53 | Araq | Varriount: I don't know anything about native stack traces |
| 19:33:11 | Araq | comex patched excpt.nim some day and added support for them |
| 19:33:16 | Varriount | Ah. |
| 19:33:41 | Araq | I don't think they still work |
| 19:33:50 | Varriount | (What's the difference between native and non-native stack traces?) |
| 19:33:51 | Araq | it surely is fragile |
| 19:33:59 | Araq | non-native stack traces work |
| 19:34:05 | Araq | and are what you see in general |
| 19:34:21 | EXetoC | Mat2: yay no offense taken :p |
| 19:34:24 | Varriount | Araq, the code looks to be highly dependant on os data structures |
| 19:34:44 | Araq | Varriount: that would the "native" version then, yes |
| 19:34:56 | * | comex waves |
| 19:35:05 | Varriount | Yeah, forgot to mention that. |
| 19:35:18 | Varriount | Hi Comex, care to explain native stack traces? |
| 19:35:31 | * | dirkk0 quit (Quit: Leaving) |
| 19:36:33 | comex | sec |
| 19:37:19 | comex | yeah, it's just a wrapper to the built-in backtrace function |
| 19:37:25 | * | Hannibal_Smith quit (Quit: Sto andando via) |
| 19:37:34 | Varriount | The backtrace function being...? |
| 19:37:40 | comex | a c library function |
| 19:37:42 | comex | and dladdr to get symbols |
| 19:37:53 | Varriount | That sounds hacky. |
| 19:38:22 | comex | it's not really, they're standard library functions |
| 19:38:26 | comex | but you won't get the line info that way |
| 19:39:12 | Varriount | So.. do I need to worry about supporting nativeStackTrace when getting line numbers? |
| 19:40:01 | comex | what are you trying to do? :) |
| 19:40:08 | comex | the line numbers aren't available, so |
| 19:40:26 | comex | it wouldn't be possible to support it |
| 19:40:56 | Araq | Varriount: just ensure your proc doesn't even exist then, so users get a nice compile time error |
| 19:41:33 | * | OrionPKM joined #nimrod |
| 19:42:24 | Varriount | Araq, anything I should be careful with when dealing with the raw stack frames? |
| 19:43:07 | Araq | well the order is reversed but apart from that |
| 19:43:15 | Araq | not many gotchas here |
| 19:43:39 | Araq | unless you move it into another module |
| 19:43:55 | Araq | then it requires some magic :P |
| 19:43:56 | Varriount | Which I don't know how to do, without including it. :/ |
| 19:44:22 | MFlamer | Varriount: What are you working on? |
| 19:46:08 | Varriount | MFlamer, I'm working on getting a function that retrieves the current line number more reliably than InstantiationInfo().line, so that I can trace the execution path of builder.nim (the build bot), so I can narrow the builder.nim code down to an example that Araq can test for memory corruption. |
| 19:46:52 | Varriount | And I refuse to hand-write line numbers into 100+ echo calls, especially when the line numbers will change as I modify the program. |
| 19:47:04 | MFlamer | I see, ok. I thought it sounded related to IDE tools or something likie that |
| 19:47:24 | Araq | er ... you know system.writeStackTrace exists, right? |
| 19:47:39 | Varriount | Araq, I don't want the entire stack trace. |
| 19:47:48 | Araq | why do you want to know less than that? |
| 19:49:09 | Varriount | Araq, in order to trace the program's execution path, I have inserted echo calls after every 'if', 'while', and the other control structures. |
| 19:49:49 | Araq | cool. sounds like a job for a dirty TR macro though :-) |
| 19:49:55 | Varriount | TR? |
| 19:50:01 | Araq | term rewriting |
| 19:50:01 | EXetoC | term rewriting |
| 19:50:12 | Varriount | :D |
| 19:50:33 | Varriount | Araq, faster for me to insert the echos |
| 19:50:45 | Varriount | Also, I'm scared of macros. |
| 19:51:37 | Araq | we all are |
| 19:51:51 | Araq | I'm because they are buggy. :-) |
| 19:54:32 | MFlamer | Not for long! When the new VM is done ;-) |
| 19:56:13 | MFlamer | Araq: when you talk about the VM, is that what is currently in eval.nim? |
| 19:57:14 | Araq | yeah. now it's in vm.nim |
| 19:57:35 | Varriount | Ok, a "success" exit code is... 0, right? |
| 19:57:46 | Araq | right |
| 19:57:54 | Araq | the only success code |
| 20:02:07 | Varriount | OrionPKM, you ok with MIT License? |
| 20:02:13 | OrionPKM | sure |
| 20:03:05 | OrionPKM | if you're around later tonight, we should brainstorm some features we'd like |
| 20:03:13 | OrionPKM | I've got some ideas knocking around |
| 20:03:33 | Varriount | OrionPKM, which nick are you? Onion-something? |
| 20:04:45 | Varriount | Nevermind, you are added, OnionHammer |
| 20:05:33 | OrionPKM | yeah |
| 20:11:47 | * | webskipper joined #nimrod |
| 20:13:37 | * | Varriount wishes dom96 would help slim down the builder |
| 20:14:14 | Varriount | OrionPKM, you gonna push your package first? |
| 20:16:48 | Mat2 | ehm, what was these constant name for the CPU dependent endianess ? |
| 20:17:17 | Varriount | As a side note, we should probably add a page on the site with links/info for nimrod editor support |
| 20:17:33 | Varriount | Mat2, Big Endian and Little Endian? |
| 20:20:37 | * | gradha joined #nimrod |
| 20:20:58 | Varriount | Hey gradhoney badger |
| 20:21:04 | gradha | yo yo yo |
| 20:22:27 | Mat2 | Varriount: Both, I search just for a function or boolean constant holding true or false: Something like - bigEndian: true |
| 20:24:12 | Varriount | Mat2, you might have to do something funky with the compiler - I'm not sure nimrod takes into account endianess, since it's translated to C. GCC/VS/Clang take care of that. |
| 20:25:31 | OrionPKM | Varriount up to you. i'm at work atm |
| 20:26:27 | Mat2 | Varriount: I need the endianess of a given platform for the backend routines of my compiler (which generating native code) |
| 20:27:56 | Varriount | Lessee... |
| 20:30:21 | Varriount | Mat2, http://stackoverflow.com/questions/1001307/detecting-endianness-programmatically-in-a-c-program |
| 20:30:59 | Varriount | You should be able to translate that to nimrod. |
| 20:34:27 | Mat2 | ehm, thanks - exist there any predefined constant (as for C) ? |
| 20:35:15 | * | Varriount_ joined #nimrod |
| 20:35:48 | Mat2 | get some sleep, ciao |
| 20:35:53 | * | ics joined #nimrod |
| 20:36:01 | * | Mat2 quit (Quit: Verlassend) |
| 20:38:31 | * | Varriount quit (Ping timeout: 245 seconds) |
| 20:38:31 | * | Varriount_ is now known as Varriount |
| 20:46:28 | gradha | is https://en.wikipedia.org/wiki/JPEG_XR evil or not? discuss! |
| 20:48:05 | gradha | wow, microsoft code using Makefiles, what parallel universe is this |
| 20:51:47 | Kooda | They saw the light! |
| 20:52:31 | gradha | at least they compensate providing the spec in a .doc file |
| 20:55:29 | * | BitPuffin joined #nimrod |
| 20:59:42 | * | MFlamer quit (Read error: Connection reset by peer) |
| 21:00:48 | * | MFlamer joined #nimrod |
| 21:08:02 | BitPuffin | what's the nimrod equivalent of fread? |
| 21:08:28 | gradha | readbytes maybe? |
| 21:11:19 | BitPuffin | yeah that's what I was thinking but I don't know |
| 21:11:55 | gradha | there are many read* procs due to types, pick the one you prefer |
| 21:12:14 | BitPuffin | ReadBytes doesn't take the same parameters |
| 21:13:05 | gradha | a buffer and length, what else is there? |
| 21:14:32 | BitPuffin | fread takes a ptr to memory with size*count at least, and it takes size and count (gasp!) and a stream |
| 21:15:22 | BitPuffin | TReadFunc* = proc (point: pointer; size: csize; nmemb: csize; |
| 21:15:25 | BitPuffin | datasource: pointer): csize {.cdecl.} |
| 21:15:26 | gradha | yeah, fread making the size*count multiplication is difficult to replicate, being proprietary algorithm and that |
| 21:16:02 | BitPuffin | it is? http://man7.org/linux/man-pages/man3/fwrite.3.html |
| 21:16:17 | gradha | readbytes is just a typed wrapper over readBuffer, which is a wrapper over fread, don't know where your problem is |
| 21:16:46 | BitPuffin | gradha: my problem is YOU! |
| 21:16:47 | BitPuffin | no kidding |
| 21:17:00 | BitPuffin | my problem is that the proc needs to matche TReadFunc format |
| 21:17:08 | gradha | so write yet another wrapper? |
| 21:18:19 | BitPuffin | ._. |
| 21:18:25 | * | achim quit (Quit: Computer has gone to sleep.) |
| 21:19:07 | gradha | I'm sure Araq will tell you about some nimrod call oneliner unrolling super thingy that makes you happier |
| 21:19:41 | gradha | or you could importc yourself fread and pass it directly |
| 21:20:10 | BitPuffin | yeah I guess |
| 21:20:22 | BitPuffin | is there no stdio raw binding for nimroad? |
| 21:21:02 | gradha | define raw |
| 21:21:24 | BitPuffin | no sugar |
| 21:22:16 | gradha | like lower than fread? |
| 21:22:25 | BitPuffin | noo |
| 21:22:30 | BitPuffin | exactly fread |
| 21:22:44 | gradha | that would be readBuffer |
| 21:22:48 | Varriount | BitPuffin, use readBuffer |
| 21:23:45 | BitPuffin | Varriount: but the argument order is different |
| 21:23:56 | BitPuffin | do I need to make a readBufferTwo? |
| 21:24:48 | BitPuffin | doesn't even have the same parameter count |
| 21:25:03 | gradha | so make a wrapper |
| 21:25:14 | gradha | look at https://github.com/Araq/Nimrod/blob/master/lib/system/sysio.nim#L223 |
| 21:26:03 | gradha | you could wrap readBuffer to provide the same stupid C interface, or importc yourself fread and pass that |
| 21:26:38 | Varriount | BitPuffin, what about named parameters? |
| 21:27:22 | BitPuffin | gradha: but why doesn't it just make fread public ah |
| 21:27:24 | BitPuffin | alright |
| 21:27:26 | BitPuffin | I'll copy it |
| 21:27:57 | BitPuffin | is it because noDecl? |
| 21:28:39 | gradha | I guess it's because fread API is stupid |
| 21:28:52 | Araq | indeed |
| 21:29:13 | BitPuffin | yeah but it's useful when wrapping |
| 21:30:04 | gradha | cool kids don't use fread today, they mmap files into arrays and stuff |
| 21:30:44 | BitPuffin | mmmmmmmmmmmmmmmmmmmmap |
| 21:32:05 | BitPuffin | vorbisfile.nim(43, 82) Error: invalid pragma: importc: "fread |
| 21:32:17 | BitPuffin | var fread*: TReadFunc = proc (buf: Pointer, size, n: int, f: TFile): int {.importc: "fread", header: "<stdio.h>", tags: [FReadIO].} |
| 21:32:26 | BitPuffin | is it because I var'd it? |
| 21:32:33 | BitPuffin | because I didn't know what else to do |
| 21:34:05 | gradha | first copy lines 36-37 of sysio, then you use that |
| 21:35:02 | BitPuffin | ah |
| 21:35:12 | BitPuffin | that's what I did |
| 21:35:26 | BitPuffin | but I had to change the type to csize and TFile to pointer |
| 21:36:06 | Varriount | Araq, I'm curious, why do you need the git stuff removed from the builder for finding the memory corruption? |
| 21:39:44 | BitPuffin | no fclose? |
| 21:40:59 | BitPuffin | just close I guess |
| 21:41:27 | gradha | fclose is imported by system.nim as close |
| 21:42:20 | Araq | gradha: should we tell BitPuffin about "grep" and "nimgrep"? |
| 21:42:30 | gradha | shush |
| 21:42:50 | gradha | if you go telling about my superpowers people will notice they arent' that super |
| 21:43:25 | EXetoC | I have done that already :p |
| 21:43:36 | * | BitPuffin uses ack |
| 21:43:39 | Varriount | Araq ^ |
| 21:43:51 | EXetoC | yeah yeah |
| 21:44:32 | gradha | amazing, 3 of the 5 top reasons to use ack are solved by bash aliases |
| 21:45:10 | gradha | alias ngrep='nimgrep --recursive -y --ext:nim' |
| 21:45:45 | gradha | crap, now it's me revealing my superpowers, I'm failling INT rolls like crazy |
| 21:45:55 | EXetoC | BitPuffin: did you in fact need my lib today? |
| 21:46:01 | BitPuffin | EXetoC: yes |
| 21:46:30 | EXetoC | BitPuffin: I'll upload it. will take < 20 min |
| 21:46:54 | BitPuffin | EXetoC: don't rush :) |
| 21:52:19 | BitPuffin | dom96: merge! |
| 21:52:46 | BitPuffin | EXetoC: while I'm waiting on you I'm gonna read |
| 21:53:02 | BitPuffin | I have 40 pages to read |
| 21:53:49 | webskipper | I am asking me where the std lib lays - is it compiled into the nimrod exe ? |
| 21:53:57 | BitPuffin | webskipper: nah |
| 21:54:11 | BitPuffin | webskipper: look in nimrod.cfg I think |
| 21:54:12 | Varriount | webskipper, ./lib/ |
| 21:54:13 | BitPuffin | and you'll see |
| 21:54:19 | MFlamer | Araq: At this point I can't gaurantee that the kind field is in any specific position in a case object, correct? |
| 21:54:39 | MFlamer | unless I force it in my alternate backend |
| 21:54:40 | webskipper | ah lib yea |
| 21:54:42 | webskipper | i am blind |
| 21:55:30 | BitPuffin | EXetoC: why are you making a math lib? :( I'm hurt lol |
| 21:55:44 | Araq | webskipper: it is compiled into the exe, yes |
| 21:55:52 | Araq | oh wait |
| 21:56:43 | Araq | well it's not a resource of nimrod.exe if that's what you mean |
| 21:57:03 | * | brson quit (Ping timeout: 246 seconds) |
| 21:57:07 | Araq | MFlamer: correct |
| 21:57:21 | gradha | maybe EXetoC's math library has a better badger interface |
| 21:57:25 | Araq | and btw TSocket has 2 "case"s |
| 21:58:07 | Varriount | Araq, why, when trying to find the memory corruption, why do you need the git stuff removed? |
| 21:58:20 | Araq | no need to completely remove it |
| 21:58:41 | Araq | but I need to do "builder someconfig.ini" and then it does it's thing and crashes |
| 21:58:49 | Araq | *its |
| 21:59:01 | * | brson joined #nimrod |
| 21:59:07 | Araq | otherwise I need to push random stuff just to trigger the crash |
| 21:59:07 | Varriount | Hm. |
| 21:59:18 | Varriount | Oh, ok. |
| 21:59:45 | BitPuffin | by the way guys I'm a bit torn with linagl for proc names |
| 22:00:04 | BitPuffin | it seems inconsistent in a way |
| 22:00:10 | BitPuffin | I'm trying to keep things mathy |
| 22:00:13 | BitPuffin | so determinant is det |
| 22:00:38 | BitPuffin | but that is inconsistent with other proc names that don't have a short mathy name |
| 22:00:54 | MFlamer | whats the purpose of these typedefs in the generated C? |
| 22:00:57 | MFlamer | typedef struct tmaybe78031_SV1 tmaybe78031_SV1; |
| 22:00:57 | MFlamer | typedef struct tmaybe78031_SV2 tmaybe78031_SV2; |
| 22:00:57 | MFlamer | typedef struct TNimType TNimType; |
| 22:01:41 | MFlamer | give an example Bitpuffin |
| 22:01:56 | NimBot | nimrod-code/packages master fc6adee Isak Andersson [+0 ±1 -0]: Add nim-vorbis |
| 22:01:56 | NimBot | nimrod-code/packages master d835eb4 Dominik Picheta [+0 ±1 -0]: Merge pull request #36 from BitPuffin/master... 2 more lines |
| 22:01:58 | BitPuffin | MFlamer: transposed, inversed |
| 22:02:00 | * | faassen quit (Quit: Leaving.) |
| 22:02:01 | gradha | BitPuffin: why is the description of nim-vorbis the same as for nim-ogg, are they the same? |
| 22:02:32 | BitPuffin | oops |
| 22:02:33 | MFlamer | inv, trans ? |
| 22:02:48 | dom96 | And I just merged it.. gah. |
| 22:02:58 | BitPuffin | gradha: that should be libvorbis |
| 22:03:04 | Araq | inv would mean inverse and not inversed so inversed is fine |
| 22:03:08 | BitPuffin | dom96: want me to make a new pull request? |
| 22:03:27 | MFlamer | ah |
| 22:03:30 | BitPuffin | I'm considering just skipping the math names |
| 22:03:36 | BitPuffin | so making det determinant |
| 22:03:36 | EXetoC | BitPuffin: because it's easy to implement. it's part of the engine |
| 22:03:40 | dom96 | BitPuffin: It's ok, i'll change it |
| 22:03:47 | BitPuffin | MFlamer: there is also minor and cofactor |
| 22:03:49 | EXetoC | no generics used etc |
| 22:03:59 | BitPuffin | EXetoC: but then why not use fowltek :P |
| 22:04:13 | BitPuffin | dom96: aw, thanks |
| 22:04:15 | Araq | BitPuffin: determinant instead of det is a sin |
| 22:04:16 | MFlamer | yeah, good luck with shortys for all those |
| 22:04:26 | NimBot | nimrod-code/packages master 2e952b4 Dominik Picheta [+0 ±1 -0]: Fixed nim-vorbis' description |
| 22:04:29 | BitPuffin | Araq: yeah I know, but you know, the whole consistency thing |
| 22:04:29 | Araq | heck I don't even know how to spell determinant |
| 22:04:42 | Araq | consistency is overrated |
| 22:04:55 | Araq | 'det' is too sweet, use it |
| 22:04:57 | BitPuffin | Araq: oooooooooOOOOOOOOOOOOOOOR we could have aliases ;) |
| 22:05:01 | BitPuffin | Yeah I like det |
| 22:05:03 | MFlamer | what are those typedefs for? |
| 22:05:07 | BitPuffin | but it's inconsistent |
| 22:05:31 | Araq | MFlamer: it's usually some dependency gone wild |
| 22:05:42 | BitPuffin | Araq: there is sort of an alias actually, but the alias is limited, which is why it has a reason to exist |
| 22:05:48 | BitPuffin | it's shorter and nicer if you can do it |
| 22:05:56 | BitPuffin | but when you need more control you use the real one |
| 22:06:05 | BitPuffin | I'm talking about minor |
| 22:06:11 | gradha | BitPuffin: Lindsay says "use detox instead of det" |
| 22:06:17 | Araq | yeah. that makes like ... no sense whatsoever |
| 22:06:30 | BitPuffin | you can do m{12} instead of m.minor(1, 2) |
| 22:06:58 | BitPuffin | but with {} you can't do same as m.minor(100, 3) |
| 22:06:59 | Araq | ah ok |
| 22:07:09 | BitPuffin | and then minor will also be able to take arrays |
| 22:07:14 | Araq | yeah well then have aliases |
| 22:07:24 | BitPuffin | so you can delete 0 or more rows or columns |
| 22:07:37 | Araq | but don't alias == as 'equals' :P |
| 22:07:42 | BitPuffin | Araq: even for determinant? or should that remain det |
| 22:07:42 | Varriount | BitPuffin, what are you talking about? |
| 22:07:49 | BitPuffin | Varriount: matrix minors |
| 22:07:51 | Araq | BitPuffin: that should remain det |
| 22:08:07 | BitPuffin | Araq: yeah, I thought this {} alias had a reason to exist |
| 22:08:12 | BitPuffin | even in your eyes :P |
| 22:08:25 | Araq | well it's not an alias |
| 22:08:34 | BitPuffin | because the typical math notation is m{10} |
| 22:08:41 | BitPuffin | no not exactly |
| 22:08:45 | Araq | an alias would have the same signature |
| 22:08:47 | BitPuffin | it's more of a convenient shortcut |
| 22:08:59 | Araq | yeah, so have shortcuts |
| 22:09:12 | BitPuffin | it's already in there |
| 22:09:23 | BitPuffin | take a look if you have doubts :D |
| 22:14:22 | MFlamer | Araq: is FieldDiscriminantCheck designed to test attempted field access for object variants at runtime? |
| 22:15:31 | Araq | I think so |
| 22:17:03 | Varriount | Araq, I take it that you would also like the builder to not take 30 minutes to actually get to the crash point? |
| 22:18:55 | Araq | just make it perform a bootstrapping twice. that should trigger it already |
| 22:19:06 | Araq | no need to make it run the tests etc.. |
| 22:24:08 | BitPuffin | Araq: should I keep submatrix as sub? |
| 22:24:51 | Araq | BitPuffin: now that's an edge case :P I think i'd prefer submatrix |
| 22:25:04 | BitPuffin | hmm |
| 22:25:05 | dom96 | oh so you got Varriount working on reproducing this corruption. |
| 22:25:07 | BitPuffin | okay |
| 22:25:25 | BitPuffin | yeah I guess sub can even be confused with subtraction |
| 22:25:35 | Araq | dom96: yeah |
| 22:25:37 | BitPuffin | or substitute or a lot of stuff |
| 22:25:55 | BitPuffin | sandwiches |
| 22:26:54 | Varriount | How does one include an icon when building an executable? |
| 22:27:20 | OrionPKM | on windows |
| 22:27:21 | Varriount | dom96, you might just want to ignore buildbot for a while. |
| 22:27:22 | OrionPKM | when defined(windows): const favicon = staticExec("windres favicon.rc -O coff -o favicon.res") {.link: "favicon.res".} |
| 22:28:02 | Varriount | OrionPKM, what about on linux? (Can it be done on linux?) |
| 22:28:10 | OrionPKM | no idea, let me know if you find out :P |
| 22:28:23 | Araq | linux has no icons |
| 22:28:37 | Varriount | :< |
| 22:29:35 | Kooda | Hm, sorry to bother you, but pointers usage is still a bit blury, even after reading the docs… Should I always cast a value of type `pointer` before I can dereference it? |
| 22:29:54 | Kooda | (I’m trying to use memfiles) |
| 22:30:00 | Araq | yes |
| 22:30:08 | Araq | pointer is like void* |
| 22:30:16 | Kooda | Ok :) |
| 22:31:00 | Kooda | And, for example, can a `ptr char` be used as an array or it’s more complicated? |
| 22:31:22 | Araq | use 'cstring' instead |
| 22:31:25 | Varriount | Kooda, it would be better to use a ref, since those are garbage collected. |
| 22:31:40 | Araq | Varriount: he can't. he's using memfiles |
| 22:31:42 | Kooda | Varriount: memfiles.open() gives me a pointer |
| 22:31:51 | Varriount | Oh. |
| 22:32:22 | Kooda | Araq: is a mmap()ed file null terminated? |
| 22:32:29 | Araq | no |
| 22:32:34 | Araq | unless you're lucky |
| 22:32:42 | Kooda | Ok, so I have to be careful |
| 22:33:14 | Araq | the compiler uses memfiles too for the "rod" file mechanism |
| 22:33:28 | Araq | and I terminate rod files with \0 for this reason :-) |
| 22:33:41 | Kooda | rod? |
| 22:33:56 | Araq | nimrod's broken symbol file caching mechanism |
| 22:34:05 | Kooda | ^^' |
| 22:34:07 | Araq | which will finally give us incremental compilation |
| 22:34:16 | Kooda | Oh, awesome :) |
| 22:35:31 | Kooda | Just to be sure… cast() doesn’t copy anything, right? |
| 22:35:43 | EXetoC | Araq: we have none? |
| 22:35:50 | NimBot | nimrod-code/packages master b3858fe Grzegorz Adam Hankiewicz [+0 ±2 -0]: Adds web field to packages. |
| 22:35:50 | NimBot | nimrod-code/packages master 4b5b2f4 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Hyperlinks packages.json for github. |
| 22:35:50 | NimBot | nimrod-code/packages master 105ab94 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Updates Nimrod website domain name. |
| 22:35:50 | NimBot | nimrod-code/packages master 7da238b Grzegorz Adam Hankiewicz [+0 ±2 -0]: Merge pull request #31 from gradha/pr_adds_web_field... 2 more lines |
| 22:35:55 | EXetoC | if so, then awesome. it's already fast as it is |
| 22:39:56 | Araq | Kooda: right |
| 22:40:30 | Araq | EXetoC: when it worked it bootstrapped in 0.02s on my machine iirc |
| 22:40:48 | Kooda | Maybe I should be less afraid of sementic differences with C… since it compiles to C ^^' |
| 22:41:22 | Araq | well ... you should be afraid. but pointer/cstring/ptr and cast are all quite like C |
| 22:41:44 | BitPuffin | Araq: lies |
| 22:42:07 | dom96 | Varriount: Do you need any help with the builder? |
| 22:42:18 | Varriount | dom96, in what sense? |
| 22:42:41 | Varriount | Araq, I *think* I reproduced the crash. |
| 22:42:48 | EXetoC | BitPuffin: https://github.com/EXetoC/nim-glfw |
| 22:42:54 | EXetoC | took about 18 minutes, right :p |
| 22:42:57 | dom96 | At getting it to build twice. |
| 22:43:20 | BitPuffin | EXetoC: yahoo! then you have 2 minutes to tell me what's new :D |
| 22:43:27 | EXetoC | will have to add it to babel. I removed the number from the name |
| 22:43:30 | Varriount | Araq, however it doesn't go through the whole build process the first time for some reason. |
| 22:43:48 | Araq | Varriount: :-/ |
| 22:44:00 | BitPuffin | EXetoC: doesn't that clash though |
| 22:44:19 | Varriount | Araq, it's probably because the builder launched each build in a new thread. |
| 22:44:46 | EXetoC | BitPuffin: no, the other one is called nimrod-glfw |
| 22:44:57 | BitPuffin | ah lol |
| 22:45:08 | BitPuffin | well how will people know which one to pick :) |
| 22:45:51 | EXetoC | I don't know :p by reading the description maybe |
| 22:46:09 | Varriount | Araq, so... what now? |
| 22:46:16 | BitPuffin | now don't get http://upload.wikimedia.org/wikipedia/commons/6/60/Rooster_portrait2.jpg y |
| 22:47:38 | Araq | Varriount: let's hope you're right and we won't hunt a phantom |
| 22:48:50 | Araq | dom96: please help us here |
| 22:51:38 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 22:51:42 | EXetoC | is the babel extension actually documented? |
| 22:51:50 | BitPuffin | EXetoC: nope |
| 22:52:02 | EXetoC | I'll just check the source |
| 22:53:07 | Varriount | Araq, how do you want me to send you the files? |
| 22:53:48 | Araq | Varriount: as a gist please |
| 22:54:00 | BitPuffin | as ji |
| 22:54:06 | BitPuffin | jizz? |
| 22:54:12 | EXetoC | BitPuffin: what's new? uh, almost nothing |
| 22:54:22 | * | Varriount_ joined #nimrod |
| 22:54:36 | EXetoC | will add a more verbose example later, but it shouldn't be too hard to figure things out |
| 22:54:46 | * | Varriount quit (Disconnected by services) |
| 22:54:47 | * | Varriount_ is now known as Varriount |
| 22:54:53 | BitPuffin | EXetoC: it should ẃork out, otherwise I'll nag you |
| 22:55:00 | Varriount | Araq, how do you want me to send you the files? |
| 22:55:01 | BitPuffin | but what did you change |
| 22:55:06 | BitPuffin | what is a commit log even |
| 22:55:11 | Araq | Varriount: as a gist please |
| 22:55:50 | EXetoC | BitPuffin: it's not even the same repository. why? I don't have a good answer |
| 22:56:08 | BitPuffin | well I was just wondering :P |
| 22:56:29 | EXetoC | :p |
| 22:56:39 | Varriount | Araq, -> https://gist.github.com/Varriount/7779114 |
| 22:57:03 | EXetoC | nag away. I just end up playing dod if no one has a task for me |
| 22:57:14 | BitPuffin | :P |
| 22:57:21 | BitPuffin | first I'm gonna read |
| 22:57:25 | BitPuffin | and code linagl |
| 22:57:37 | BitPuffin | so you can play dod now if you wanna |
| 23:01:04 | Araq | Varriount: thanks |
| 23:01:19 | EXetoC | I didn't mean like that. I've wasted too much time on games |
| 23:01:19 | Varriount | Araq, does it work/crash? |
| 23:01:49 | gradha | EXetoC: so you didn't enjoy playing those games? |
| 23:02:19 | OrionPKM | so how about removing the 'defined and not used' warning for block labels |
| 23:03:00 | BitPuffin | when this game is done I'm gonna play a lot of dota 2 |
| 23:05:00 | * | webskipper quit (Ping timeout: 245 seconds) |
| 23:06:00 | Araq | Varriount: Started builder: built at 2013-12-04 00:05:00 |
| 23:06:00 | Araq | hubConnect |
| 23:06:00 | Araq | Handling connect. |
| 23:06:00 | Araq | Incorrect welcome message from hub |
| 23:06:00 | Araq | Waiting 5 seconds... |
| 23:06:00 | Araq | hubConnect |
| 23:06:00 | Araq | 115 |
| 23:06:10 | Araq | Handling connect. |
| 23:06:10 | Araq | The hub accepted me! |
| 23:06:10 | Araq | 115 |
| 23:06:10 | Araq | 115 |
| 23:06:10 | Araq | so ... no, doesn't crash |
| 23:06:25 | Varriount | -_- |
| 23:06:25 | * | brson quit (Ping timeout: 246 seconds) |
| 23:06:45 | BitPuffin | Varriount: run memtest86+ on your box for 24 hours and come back |
| 23:06:45 | dom96 | well the website just crashed... |
| 23:06:53 | Varriount | >_> |
| 23:07:41 | Varriount | dom96, why did it crash? |
| 23:08:21 | BitPuffin | crazy golang people hacking our site!!!!! |
| 23:08:31 | EXetoC | can't paste into github's editor either -.- these web-based editors are weird |
| 23:08:53 | dom96 | I think it's because one of the builder's reconnected during a build |
| 23:09:02 | Araq | that would be mine then :-) |
| 23:09:18 | dom96 | Araq: Here is the code which does what you want: https://gist.github.com/dom96/9359643a06c6585f23e8 |
| 23:09:27 | BitPuffin | sensitive system much |
| 23:09:53 | BitPuffin | Araq is the crazy golang man, who would have guessed |
| 23:10:11 | * | Varriount blames threads |
| 23:10:30 | dom96 | I don't know if it reproduces the corruption but it runs the build infinitely. |
| 23:10:46 | Araq | dom96: well let's see, thanks |
| 23:11:08 | EXetoC | gradha: yeah, but it's such an unproductive task |
| 23:11:32 | gradha | EXetoC: only if your goal in life is not happiness |
| 23:11:34 | Varriount | Araq, dom96, I have to go - I need to study for a math exam tomorrow. |
| 23:11:38 | BitPuffin | EXetoC: well it's not healthy to be productive 100% of the time |
| 23:11:54 | dom96 | yeah, I need to go too. |
| 23:11:57 | Araq | Varriount: thank you for your help. Good luck tomorrow. |
| 23:12:09 | gradha | this talk about starting procs and threads reminds me that pig and elephant dna just won't splice |
| 23:12:10 | Araq | dom96: thank you for your help. Good luck tomorrow. |
| 23:12:32 | BitPuffin | was that a copy paste? |
| 23:12:35 | dom96 | What, I don't have any exams tomorrow. |
| 23:12:48 | BitPuffin | dom96: no, he's just coming to fight you |
| 23:12:50 | Araq | everybody needs luck for tomorrow |
| 23:13:14 | dom96 | BitPuffin: Well then he needs luck not me :P |
| 23:13:32 | BitPuffin | haha! Ain't that right, he's just being cocky :P |
| 23:13:57 | gradha | good night, honey badgers |
| 23:14:09 | * | hoverbear joined #nimrod |
| 23:14:09 | dom96 | bye honey badger! |
| 23:14:27 | EXetoC | dom96: yo |
| 23:14:42 | EXetoC | wanna merge my package pull first? |
| 23:14:50 | EXetoC | dom96: oh he's the one who said bye |
| 23:14:54 | BitPuffin | lol |
| 23:14:54 | * | webskipper joined #nimrod |
| 23:15:00 | Araq | well Jacob told me we all need luck for tomorrow |
| 23:15:02 | EXetoC | first |
| 23:15:17 | BitPuffin | who the hell is Jacob |
| 23:15:19 | EXetoC | dude, you know what I mean |
| 23:15:22 | dom96 | Lost reference :P |
| 23:15:35 | dom96 | probably |
| 23:15:52 | BitPuffin | Araq: are you watching Twilight? |
| 23:15:56 | dom96 | Araq: I'll see you in another life brother. |
| 23:16:17 | BitPuffin | http://images5.fanpop.com/image/photos/28100000/jacob-shirless-twilight-series-28141353-487-800.jpg araq's man |
| 23:16:20 | NimBot | nimrod-code/packages master 349eb1f Erik Johansson Andersson [+0 ±1 -0]: Edit the entries for my libs |
| 23:16:20 | NimBot | nimrod-code/packages master bd90295 Dominik Picheta [+0 ±1 -0]: Merge pull request #37 from EXetoC/patch-1... 2 more lines |
| 23:16:26 | dom96 | bye! |
| 23:16:28 | EXetoC | ktnx dude |
| 23:16:33 | BitPuffin | sleep well dom96! |
| 23:16:41 | dom96 | BitPuffin: thx |
| 23:16:44 | BitPuffin | don't get hit by a car in your dream! |
| 23:16:45 | dom96 | You too! |
| 23:16:45 | Araq | BitPuffin: Jacob tells me what to do |
| 23:17:48 | BitPuffin | Araq: is he the one keeping you motivated through the hell of making a programming language? |
| 23:18:55 | Araq | BitPuffin: yeah he told me I'm special and the island needs a new programming language. |
| 23:19:32 | BitPuffin | Araq: you don't happen to be sleep deprived by any chance? :P |
| 23:20:09 | Araq | apparently nobody except dom96 gets the reference |
| 23:20:52 | BitPuffin | ah |
| 23:20:55 | BitPuffin | I didn't watch lost |
| 23:21:02 | gradha | good night, honey badgers |
| 23:21:02 | BitPuffin | well |
| 23:21:07 | BitPuffin | maybe an episode or so |
| 23:21:09 | * | gradha quit (Quit: bbl, need to watch http://www.youtube.com/watch?v=hcDEWiH-ciw again) |
| 23:30:11 | OrionPKM | you didnt miss much bitpuffin |
| 23:30:56 | Araq | OrionPKM: hey, Lost is cool. |
| 23:31:04 | OrionPKM | first couple seasons were good |
| 23:31:11 | Araq | yeah |
| 23:31:21 | OrionPKM | last couple seasons ruined the whole thing for me |
| 23:31:22 | Araq | then it went downhill |
| 23:32:18 | Araq | but I like the first 3 seasons enough to forgive them |
| 23:32:41 | OrionPKM | I dont know if BSG pulled a LOST or LOST pulled a BSG |
| 23:33:27 | BitPuffin | BSG? |
| 23:33:33 | OrionPKM | battlestar |
| 23:33:35 | BitPuffin | ah |
| 23:33:37 | BitPuffin | right |
| 23:33:46 | BitPuffin | well it seemed like lost was retarded |
| 23:33:52 | BitPuffin | like we have to get off the island |
| 23:33:57 | BitPuffin | no we have get back |
| 23:33:57 | * | zielmicha quit (Ping timeout: 248 seconds) |
| 23:34:06 | BitPuffin | shit why are we here we need to get off |
| 23:34:16 | BitPuffin | rinse and repeate |
| 23:34:18 | BitPuffin | repeat* |
| 23:34:23 | BitPuffin | I'm too tired |
| 23:37:31 | * | brson joined #nimrod |
| 23:57:46 | Varriount | Araq, is the builder crashing? |
| 23:59:35 | * | brson_ joined #nimrod |
