| 00:12:07 | * | hoverbear quit (Quit: Textual IRC Client: www.textualapp.com) |
| 00:15:26 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 00:16:21 | OrionPKM | varriount you got any bright ideas on how we might add syntax highlighting to source code filters |
| 00:20:15 | * | yodi quit (Ping timeout: 250 seconds) |
| 00:32:03 | Varriount | OrionPKM, nope |
| 00:33:26 | Araq | well source code filters start with #! |
| 00:34:02 | Araq | and then you need to render everything starting with # as nimrod code |
| 00:34:15 | Araq | and the other stuff as a string literal or something like that |
| 00:35:43 | Varriount | Araq, the problem is that everything has to be done as regexes. And the rules can't really reference each other. |
| 00:36:18 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 00:36:29 | Varriount | OrionPKM, we could use the \A (start of string, not line) pattern, although I don't know if it works for syntax regexes |
| 00:36:39 | Varriount | It works with the find command |
| 00:37:31 | OrionPKM | hmm |
| 00:37:54 | Varriount | However, there's no easy way we could combine whatever language the filter processes, unless it's nimrod. |
| 00:38:38 | Varriount | I mean, we could, but it would mean a lot of 'include' directives in the syntax files, and work on the part of the user. |
| 00:39:17 | Varriount | Or perhaps a nameing scheme, like filename.markupname.nim |
| 00:39:45 | Varriount | And a plugin that combines the appropriate language files. |
| 00:41:25 | OrionPKM | well |
| 00:41:35 | OrionPKM | I dont mean to highlight whatever language |
| 00:41:42 | OrionPKM | I mean to highlight the nimrod that's hidden behind #'s |
| 00:42:13 | Varriount | OrionPKM, yes, but then what about the rest? |
| 00:42:21 | OrionPKM | let the chips fall where they may |
| 00:43:04 | Varriount | OrionPKM, looking at the api, I can probably come up with a plugin to dynamically combine two syntaxes |
| 00:44:39 | Varriount | Araq, if you ever find me creating a sublime-text-like editor, and see me using regexes for language parsing, you have my permission to hit me with a lead pipe |
| 00:45:31 | Araq | *shrug* it's well known regexes are good at nothing |
| 00:46:08 | OrionPKM | Varriount lets see if we can do it.. syntax highlighting would really help out with how terrible it is to make sourcecode filters :P |
| 00:46:22 | Varriount | OrionPKM, it's not hard. |
| 00:46:27 | Varriount | One minute... |
| 00:46:43 | Araq | gedit uses regexes plus some crazy state machines in xml |
| 00:48:58 | Varriount | What bugs me the most is the lack of any mechanism that allows reuse of regexes. |
| 00:49:53 | Araq | it's what makes the imperative programming paradigm work for everything :P |
| 00:50:13 | Varriount | There's the include directive, but you can't use it *in* another regex, you can only use it to add things like patterns to begin..end rules |
| 00:50:48 | Araq | declarative approaches tend to have these issues, SQL has the same problem |
| 00:51:38 | Varriount | Araq, what do you think of this -> http://construct.readthedocs.org/en/latest/ |
| 00:52:18 | OrionPKM | so.. figure out if it's a template (#! at beginning of file?) |
| 00:52:28 | OrionPKM | then what |
| 00:53:08 | Araq | Varriount: embedding a declarative-like DSL in a proper programming language doesn't have this issue |
| 00:53:18 | Araq | because there's always a quick way out |
| 00:53:48 | Varriount | Araq, I didn't mean that construct had those issues, I wanted to know what you thought of the library/concept |
| 00:54:13 | Varriount | OrionPKM, \A#\!\s* should match the beginning of every line in a source code filter. |
| 00:54:38 | OrionPKM | well, if you want to experiment with it go ahead :P |
| 00:55:13 | OrionPKM | you're the one who wants to do the syntax highlighting, I'm going to work on snippets and idetools integration |
| 00:55:48 | Varriount | Sounds like a plan. |
| 00:55:58 | Araq | Varriount: looks good to me |
| 00:56:28 | Varriount | If only there was a python2nimrod converter. :3 |
| 00:58:33 | Araq | well a nimrod solution is superior because you can use a macro to generate the readers and writers of your data description |
| 00:58:58 | Araq | you can't get that solution with a py2nim converters |
| 00:59:13 | Varriount | True. |
| 01:06:58 | Varriount | Heh, it can be really fun to look through the strings in an executable's image/memory. |
| 01:10:08 | Araq | good night |
| 01:10:18 | Varriount | Good night Araq. |
| 01:10:33 | OrionPKM | n8 |
| 01:14:33 | Varriount | OrionPKM, can source filter files use any functions other than the one's specified in the introduction page on nimrod's website? |
| 01:14:58 | OrionPKM | any functions? |
| 01:14:58 | OrionPKM | how do you mean |
| 01:15:18 | OrionPKM | you mean other than strip, replace etc? |
| 01:15:28 | Varriount | Yes |
| 01:15:38 | OrionPKM | not that I know of, but I wouldn't know :) |
| 01:15:53 | OrionPKM | I only do basic ones |
| 01:16:03 | OrionPKM | strip | stdtmpl |
| 01:24:33 | Varriount | Huh, sublime text doesn't appear to store it's in-memory files as ropes, or any other similar structure |
| 01:25:18 | Varriount | On the one hand, it's less complicated, on the other, ropes can save a great deal of memory, especially on long strings. |
| 01:28:58 | Varriount | OrionPKM, do you have a good example source code filter? |
| 01:29:18 | OrionPKM | let me see |
| 01:29:48 | OrionPKM | https://gist.github.com/onionhammer/7817182 |
| 01:30:08 | Varriount | Thanks. |
| 01:32:38 | Varriount | OrionPKM, if you have your syntax file, I can try merging it with mine. |
| 01:33:18 | OrionPKM | it's all up on the git repo |
| 01:54:29 | Varriount | OrionPKM, I don't think I'll be able to make the regex able to switch the StdTmpl defaults without some work |
| 01:54:54 | Varriount | Eg, the control characters, such as # |
| 01:55:14 | Varriount | It may not be possible :/ |
| 01:55:59 | * | brson_ joined #nimrod |
| 01:56:09 | * | brson quit (Ping timeout: 252 seconds) |
| 01:58:39 | OrionPKM | thats too bad |
| 01:59:14 | Varriount | OrionPKM, it's mainly because of the reference issue. |
| 01:59:14 | * | MFlamer quit (Ping timeout: 250 seconds) |
| 01:59:24 | OrionPKM | reference issue? |
| 02:00:14 | Varriount | You can't have 'begin', 'end', or 'match' rules reference the captures or bodies of other rules. |
| 02:00:49 | Varriount | At least, I don't know of any way you can, and I've searched quite a bit for a solution. |
| 02:00:59 | OrionPKM | alright then.. |
| 02:01:09 | OrionPKM | thats a pity |
| 02:01:29 | Varriount | OrionPKM, but again, I might be able to something with dynamically generated syntax files. |
| 02:05:54 | OrionPKM | dynamically generated syntax files? is that a thing? |
| 02:06:09 | Varriount | OrionPKM, with the help of plugins, yes. |
| 02:07:19 | OrionPKM | hm |
| 02:07:49 | Varriount | have a hook that checks whenever a nimrod file is open. If the file starts with a hashbang, search the first line or so for the stdtemp function, and if found, read the arguments. |
| 02:08:34 | Varriount | Apply the arguments to a template file, save the file with a unique name in the users directory, and switch to that syntax. |
| 02:09:19 | OrionPKM | is that something that is done |
| 02:09:34 | OrionPKM | by other plugins I mean |
| 02:09:34 | Varriount | I have no idea. |
| 02:09:59 | Varriount | OrionPKM, I have moderate amount of experience developing sublime text plugins |
| 02:10:09 | OrionPKM | i think it might be better to look into seeing if we can specially apply (via a plugin) a different syntax file |
| 02:10:09 | OrionPKM | rather than dynamically generate a whole syntax file |
| 02:10:34 | Varriount | OrionPKM, thats what the dynamic generation would do. |
| 02:10:59 | OrionPKM | im not talking about dynamically generating a syntax file |
| 02:10:59 | OrionPKM | I'm talking about loading a static syntax file |
| 02:11:09 | OrionPKM | dynamically |
| 02:11:09 | OrionPKM | :) |
| 02:11:09 | fowl | hi |
| 02:11:19 | Varriount | http://www.sublimetext.com/docs/2/api_reference.html#sublime.Window |
| 02:11:34 | OrionPKM | set_syntax_file |
| 02:11:34 | OrionPKM | yeah |
| 02:11:54 | OrionPKM | so if the file has #! we'll load the nimrod-sourcefilter.tmLanguage |
| 02:11:54 | OrionPKM | or whatever |
| 02:13:34 | Varriount | Yeah, but if we do that, without any generation, the control characters would be fixed. |
| 02:13:44 | Varriount | Er, fixed as in, unchangeable |
| 02:13:54 | OrionPKM | yeah, I think that's fine.. just assume # |
| 02:23:54 | Varriount | OrionPKM, also, you wouldn't have highlighting for the language paired with the filter. |
| 02:24:19 | OrionPKM | not as important |
| 02:24:29 | OrionPKM | they can switch back and forth with SS |
| 02:24:49 | Varriount | SS? |
| 02:24:59 | OrionPKM | ctrl+shift+p, ss |
| 02:27:50 | EXetoC | mushroom |
| 02:39:35 | OrionPKM | yep. mushroom |
| 03:10:55 | EXetoC | badger |
| 03:11:05 | Varriount | honey |
| 03:24:16 | EXetoC | snake |
| 03:25:51 | Varriount | mongoose |
| 04:10:37 | * | brson_ quit (Quit: leaving) |
| 04:12:42 | Varriount | You know that something is limiting when your tempted to make your own preprocessor/build system for it |
| 04:13:17 | OrionPKM | hm? |
| 04:14:22 | * | shodan45 quit (Ping timeout: 245 seconds) |
| 04:14:32 | Varriount | OrionPKM, there's no way easily include parts of the nimrod syntax file with the nimrod_filter syntax file, meaning I either have to "-include" the entire syntax, split the syntax into multiple files, or copypaste |
| 04:14:57 | OrionPKM | why do you need to do that? |
| 04:15:37 | Varriount | OrionPKM, the filter syntax is nimrod syntax, except that each filter line is prefixed by a # |
| 04:16:17 | OrionPKM | yeah... in order to prevent duplication of code, a pre-parser type thing might be needed.. but only for building it initially right? |
| 04:16:17 | * | shodan45 joined #nimrod |
| 04:16:17 | Varriount | If I add parts into the nimrod syntax file, I would prefer not to duplicate my work into another file |
| 04:16:27 | Varriount | OrionPKM, yeah |
| 04:16:37 | OrionPKM | we could distribute it w/o that bit |
| 04:16:57 | Varriount | Why wouldn't we distribute it? |
| 04:17:42 | OrionPKM | because of added dependencies, depending on how the "preparser" is written |
| 04:18:17 | * | shodan45 quit (Read error: Connection reset by peer) |
| 04:18:17 | * | shodan45_ joined #nimrod |
| 04:18:27 | Varriount | OrionPKM, if it's only for building, then only people who want to edit would have to get the dependancy |
| 04:18:27 | * | shodan45_ quit (Client Quit) |
| 04:18:37 | Varriount | which, in this case, would either by python, or nimrod. |
| 04:19:32 | OrionPKM | right.. if it's nimrod you dont want to force the user to compile a bunch of code just to run the plugin |
| 04:19:57 | Varriount | But this would only be for the initial build process, what we do. |
| 04:20:07 | Varriount | Or other developers. |
| 04:23:42 | * | xenagi joined #nimrod |
| 04:25:22 | OrionPKM | we should have a pre-generated file, just like the YAML -> XML file |
| 04:25:22 | OrionPKM | we package the XML file |
| 04:25:42 | Varriount | Ok |
| 04:25:42 | OrionPKM | package both |
| 04:25:52 | OrionPKM | but the XML is already built |
| 04:25:52 | Varriount | Yeah |
| 04:26:02 | Varriount | Thats what I meant ;| |
| 04:26:22 | OrionPKM | ok |
| 04:38:12 | * | hoverbear joined #nimrod |
| 04:49:18 | Varriount | hoverbear, hovering ever onward! |
| 04:49:53 | Varriount | OrionPKM, this looks interesting -> http://pyyaml.org/wiki/LibYAML |
| 04:52:23 | hoverbear | Varriount :) |
| 04:52:38 | OrionPKM | mmm so wrap it in nim? |
| 04:53:23 | Varriount | OrionPKM, well, it might be a bit of work to get the json to xml, even if wrapping libYaml goes smoothly |
| 04:54:03 | Varriount | OrionPKM, we could always customize the AAADev converter... |
| 04:55:03 | fowl | i couldnt figure out how to use libyaml |
| 04:55:18 | Varriount | fowl, howso? |
| 04:58:58 | OrionPKM | well |
| 04:59:08 | OrionPKM | think you'd be better off writing a custom parser in nimrod |
| 04:59:08 | OrionPKM | the format isn't that complicated |
| 04:59:38 | Varriount | OrionPKM, this particular instance of it, yes.. however... |
| 05:00:03 | OrionPKM | if we patch AAA, then we can't expect everyone to use the patched version if they want to build the plugin |
| 05:00:23 | Varriount | OrionPKM, this is the YAML specification - http://www.yaml.org/spec/1.2/spec.html |
| 05:01:23 | fowl | yaml is complicated |
| 05:01:58 | OrionPKM | yeah, but all we want to do is duplicate a yaml file and insert some patterns |
| 05:02:13 | Varriount | OrionPKM, and then process it with AAA |
| 05:02:13 | OrionPKM | right |
| 05:02:33 | OrionPKM | or hel |
| 05:02:33 | OrionPKM | just use the XML |
| 05:02:33 | OrionPKM | rather than the YAML |
| 05:02:58 | OrionPKM | we already have an XML parser, and then we dont need to run it through AAA |
| 05:03:08 | Varriount | Ooh, sharp thinking |
| 05:09:23 | OrionPKM | I'm heading to bed, gonna restart irc first tho, gnight |
| 05:09:38 | Varriount | Goodnight |
| 05:09:38 | * | xenagi quit (Read error: Connection reset by peer) |
| 05:09:38 | * | OrionPKM quit (Remote host closed the connection) |
| 05:09:48 | * | zahary__ joined #nimrod |
| 05:10:23 | hoverbear | Varriount: How are you doing? |
| 05:11:43 | Varriount | Hoverbear: Well, semester finals and projects are flying fast and thick, I've got relatives coming soon, a resume to create, and a mind to keep sane. |
| 05:11:53 | hoverbear | Hah, good luck |
| 05:12:13 | * | zahary_ quit (Ping timeout: 248 seconds) |
| 05:15:13 | * | OrionPKM joined #nimrod |
| 05:38:04 | * | dymk quit (Ping timeout: 264 seconds) |
| 05:42:34 | * | dymk joined #nimrod |
| 05:47:44 | * | DAddYE quit (Remote host closed the connection) |
| 06:35:55 | * | hoverbear quit (Quit: Textual IRC Client: www.textualapp.com) |
| 06:49:26 | * | DAddYE joined #nimrod |
| 06:53:36 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 06:59:06 | * | DAddYE joined #nimrod |
| 07:03:41 | * | DAddYE quit (Ping timeout: 260 seconds) |
| 07:20:46 | * | boydgreenfield joined #nimrod |
| 07:43:17 | * | silven quit (Ping timeout: 252 seconds) |
| 07:50:47 | * | DAddYE joined #nimrod |
| 07:55:07 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 07:56:17 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 08:15:27 | * | brihat left #nimrod (#nimrod) |
| 08:28:28 | * | aftershave quit (Ping timeout: 264 seconds) |
| 08:28:58 | * | DAddYE joined #nimrod |
| 08:29:08 | * | DAddYE quit (Remote host closed the connection) |
| 08:29:18 | * | DAddYE joined #nimrod |
| 08:29:18 | * | Zor quit (Ping timeout: 264 seconds) |
| 08:30:38 | * | aftershave joined #nimrod |
| 08:32:03 | * | ics_ joined #nimrod |
| 08:34:08 | * | JStoker_ joined #nimrod |
| 08:35:03 | * | ics quit (Ping timeout: 260 seconds) |
| 08:35:03 | * | JStoker quit (Ping timeout: 260 seconds) |
| 08:35:03 | * | Varriount quit (Ping timeout: 260 seconds) |
| 08:36:08 | * | JStoker_ is now known as JStoker |
| 08:36:58 | * | Zor joined #nimrod |
| 09:08:04 | * | DAddYE quit (Remote host closed the connection) |
| 09:08:44 | * | DAddYE joined #nimrod |
| 09:16:59 | * | CarpNet joined #nimrod |
| 10:33:52 | * | ics_ quit (Ping timeout: 245 seconds) |
| 10:36:07 | * | ics joined #nimrod |
| 10:54:43 | * | dirkk0 joined #nimrod |
| 10:56:03 | * | dirkk0 quit (Client Quit) |
| 10:56:33 | * | dirkk0 joined #nimrod |
| 11:20:54 | Kooda | Hm… Am I missing something about type conversions? I get EOutOfRange if I try to convert the highest value from uint16 to int8 (this is what I expected) but not to uint8, or from uint32, it just seems to cast silently (which of course can result in an incorrect value) |
| 11:21:09 | Kooda | Also, high(uint64) doesn’t seem to exist |
| 11:32:44 | fowl | Kooda, thats a bug |
| 11:32:54 | Kooda | ^^' |
| 11:33:09 | fowl | or, bugs |
| 11:33:54 | fowl | what do you call a group of bugs? |
| 11:34:09 | fowl | a hive? colony? swarm? |
| 11:34:19 | Kooda | Seems like I get the expected exception only with uint16 -> int8 |
| 11:34:19 | Kooda | Hehehe :D |
| 12:18:06 | * | Araq0 joined #nimrod |
| 12:18:56 | Araq0 | dom96: logs are down |
| 13:34:53 | * | isenmann quit (Quit: Leaving.) |
| 13:42:18 | * | BitPuffin joined #nimrod |
| 13:52:18 | * | radsoc joined #nimrod |
| 14:01:09 | * | EXetoC quit (Quit: WeeChat 0.4.2) |
| 14:06:19 | BitPuffin | I think it's a little strange to not be able to define an array type without saying how it is indexed |
| 14:06:34 | * | dirkk0 quit (Read error: Connection reset by peer) |
| 14:06:34 | BitPuffin | I mean you should have to say it |
| 14:06:49 | BitPuffin | but I mean some instances of that type might be different sizes |
| 14:06:50 | BitPuffin | I guess then I should use a seq |
| 14:07:00 | * | dirkk0 joined #nimrod |
| 14:07:15 | BitPuffin | but they can change size so it's unecessary |
| 14:11:30 | * | dirkk0 quit (Client Quit) |
| 14:22:20 | BitPuffin | dom96: you here? |
| 14:31:11 | * | dirkk0 joined #nimrod |
| 14:31:38 | dom96 | BitPuffin: yes |
| 14:34:47 | Araq0 | So use an openarray |
| 14:35:22 | Araq0 | See you later |
| 14:35:40 | * | Araq0 quit (Quit: Bye) |
| 14:41:28 | dom96 | I wonder who wrote this: http://www.cs.tut.fi/~popl/essays/nimrod.pdf |
| 14:41:51 | dom96 | and I wonder if that's a viable source for Wikipedia. |
| 14:45:10 | OrionPKM | odd there's no author |
| 14:46:28 | Kooda | dom96: nimrod-lang.org quoting should be enough, isn’t it? |
| 14:46:43 | dom96 | Kooda: it's not |
| 14:47:02 | Kooda | Ah? :o |
| 14:47:21 | dom96 | The article got deleted like 3 times already |
| 14:47:34 | Kooda | :o |
| 14:48:17 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 14:52:03 | dom96 | And people on HN argued in our favour too, didn't make much difference sadly :\ |
| 14:53:12 | BitPuffin | "So use an openarray" Pff, those can only be used for parameters |
| 14:53:36 | BitPuffin | dom96: I have an idea for an article for you to write lol. (Yes you will get the linagl article eventually xD) |
| 14:53:45 | dom96 | oh? what is it? |
| 14:54:40 | BitPuffin | dom96: message passing in nimrod |
| 14:56:03 | BitPuffin | Also send an email to tampere university of technology and ask who wrote the essay |
| 14:58:25 | BitPuffin | It was written by "Group 20" |
| 14:58:29 | BitPuffin | http://www.cs.tut.fi/~popl/seminar.shtml |
| 14:59:33 | dom96 | hrm, message passing. I guess I could, but I don't consider it the prettiest thing in Nimrod. |
| 14:59:44 | * | EXetoC1 joined #nimrod |
| 15:00:50 | BitPuffin | dom96: well the reason an article would be nice is because I've never done it in nimrod and a little guidance would be nice even if it is possible to figure out :P |
| 15:00:58 | dom96 | I see. |
| 15:02:22 | BitPuffin | mainly I'm wondering if you can send messages for different tasks to the same thread |
| 15:02:26 | BitPuffin | that would be super useful |
| 15:02:50 | BitPuffin | so for example if my renderer lives in a thread |
| 15:02:58 | BitPuffin | (because opengl can only handle one thread) |
| 15:03:10 | BitPuffin | it would still be cool to be able to send asynchronous commands to it |
| 15:03:17 | BitPuffin | like allocate buffer etc |
| 15:03:30 | BitPuffin | or draw scene |
| 15:03:44 | BitPuffin | but that would probably have to go first in the mailbox |
| 15:04:53 | dom96 | sure, that would work. |
| 15:05:00 | dom96 | You can send an arbitrary object. |
| 15:05:26 | BitPuffin | hot damn this GPU sucks.. 128 mb video ram |
| 15:05:28 | dom96 | But the bigger the object the less efficient things will get. |
| 15:06:30 | BitPuffin | dom96: sure, but the thought is that you'll tell the GPU to allocate the buffer, and in the mean time you actually construct the data itself |
| 15:06:49 | BitPuffin | dom96: and then when the gpu has allocated it and you've finished constructing it you send the data itself |
| 15:08:39 | BitPuffin | dom96: I assume this is not possible with the actor model |
| 15:08:44 | * | EXetoC1 quit (Quit: WeeChat 0.4.2) |
| 15:09:30 | dom96 | no idea heh |
| 15:09:55 | OrionPKM | bitpuffin are you going to make use of gpu/cpu shared memory? |
| 15:10:11 | BitPuffin | OrionPKM: no don't think so at least |
| 15:10:28 | OrionPKM | that's like, the latest and greatest thing |
| 15:10:33 | BitPuffin | oh |
| 15:10:35 | BitPuffin | well then no |
| 15:10:37 | OrionPKM | http://www.extremetech.com/gaming/154547-amds-next-gen-apu-unifies-cpugpu-memory-should-appear-in-kaveri-xbox-720-ps4 |
| 15:10:52 | BitPuffin | OrionPKM: does it sound like my gpu is the latest and greatest? :P |
| 15:11:08 | BitPuffin | is this like the bindless textures? |
| 15:11:08 | OrionPKM | heh, buy a new one |
| 15:11:23 | OrionPKM | idk, i havent looked into it deeply |
| 15:11:44 | * | EXetoC joined #nimrod |
| 15:12:18 | BitPuffin | OrionPKM: if you send me a new computer you get the game for free xD |
| 15:13:01 | dom96 | BitPuffin: Got any screenshots for us yet? |
| 15:14:23 | OrionPKM | i thought swedes were supposed to be rich |
| 15:14:44 | OrionPKM | guess they're not as well off as their cousins in norway |
| 15:23:22 | EXetoC | irc |
| 15:27:47 | * | dirkk_ joined #nimrod |
| 15:30:39 | BitPuffin | dom96: nope |
| 15:31:27 | * | dirkk0 quit (Ping timeout: 264 seconds) |
| 15:34:24 | BitPuffin | dom96: but if you write an article I'll give you an exclusive screenshot ;) |
| 15:34:49 | * | webskipper joined #nimrod |
| 15:35:57 | dom96 | BitPuffin: But I'm sick :( |
| 15:36:10 | dom96 | You should give me one to cheer me up :P |
| 15:36:51 | BitPuffin | dom96: nope! |
| 15:37:08 | BitPuffin | dom96: what does sick have to do with typing ;) |
| 15:40:59 | dom96 | It has a lot to do with my ability to think about what I'm typing |
| 15:42:49 | * | fundamental quit (Ping timeout: 272 seconds) |
| 15:43:41 | BitPuffin | dom96: man up :D |
| 15:44:35 | dom96 | hah thanks |
| 15:45:19 | * | q66 quit (Quit: Leaving) |
| 15:45:20 | BitPuffin | dom96: no but get well :) |
| 15:45:28 | BitPuffin | dom96: I'll give you a screenshot asap |
| 15:45:52 | dirkk_ | Indeed - get well soon, dom96 |
| 15:46:25 | dom96 | thanks guys :) |
| 15:47:11 | BitPuffin | dom96: you'll get it under an NDA lol kidding :D |
| 15:47:29 | * | BitPuffin is now known as CorporatePuffin |
| 15:47:31 | dom96 | lol, I wouldn't mind. |
| 15:47:55 | CorporatePuffin | dom96: I am also suing you |
| 15:48:12 | CorporatePuffin | I have a patent on being sick |
| 15:49:10 | * | CorporatePuffin is now known as BitPuffin |
| 15:49:18 | dom96 | That sounds like a pretty evil patent. |
| 15:49:46 | dom96 | But I have a patent on being healthy. |
| 15:49:49 | BitPuffin | well no it's good! prevents people from getting sick |
| 15:49:51 | dom96 | So hah! |
| 15:50:05 | BitPuffin | dom96: so you are gonna counter sue? |
| 15:50:44 | dom96 | what choice do I have? |
| 15:52:59 | BitPuffin | gotta defend your patents man |
| 15:54:42 | * | fundamental joined #nimrod |
| 16:02:45 | dom96 | I really wish I had enough time to finish the new async stuff in time for the new nimrod release. |
| 16:07:57 | OrionPKM | me too dom, me too :P |
| 16:10:17 | * | hoverbear joined #nimrod |
| 16:13:17 | OrionPKM | we need to remove SDL from the standard lib.. |
| 16:13:39 | BitPuffin | hell yea |
| 16:13:45 | dom96 | the graphics module depends on it |
| 16:13:56 | BitPuffin | so remove the graphics module |
| 16:14:00 | OrionPKM | we need to remove the graphics module |
| 16:14:01 | OrionPKM | :P |
| 16:14:16 | BitPuffin | that thing does not belong in an stdlib |
| 16:14:23 | dom96 | alright |
| 16:14:39 | BitPuffin | dom96: so easily convinced :D |
| 16:14:48 | OrionPKM | dom96 you give any more thought to my idea on sub-lists for babel? |
| 16:14:58 | dom96 | This reminds me, we really do need a release of babel before we release the new Nimrod. |
| 16:15:11 | BitPuffin | yup |
| 16:15:12 | BitPuffin | get to it |
| 16:15:14 | BitPuffin | nao |
| 16:15:42 | OrionPKM | you guys know if there's a compile time version number generaed for a program I can access? |
| 16:15:55 | BitPuffin | kind of lame that linagl is gonna be incompatible with 0.9.4 right from the start |
| 16:16:13 | BitPuffin | OrionPKM: think so |
| 16:16:27 | BitPuffin | look in the compiler source |
| 16:16:36 | BitPuffin | there is some kind of version module |
| 16:16:40 | BitPuffin | maybe you can use that |
| 16:18:12 | OrionPKM | that version looks hardcoded |
| 16:18:15 | OrionPKM | nversion.nim |
| 16:18:22 | * | hoverbear quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 16:18:57 | dom96 | OrionPKM: I think that for now it's easy enough to just make a pull request to the packages repo to add your package. Later we can extend this to allow for that but for now I think it's fine. |
| 16:19:43 | BitPuffin | well at least the swizzling is |
| 16:19:45 | OrionPKM | ok |
| 16:20:02 | BitPuffin | guess I'll release a new linagl version as nimrod 0.9.4 is released |
| 16:20:28 | OrionPKM | I think i might integrate babel into the ST plugin as well |
| 16:20:31 | webskipper | you using implicity typed vars ? var x = 1. pro / cons ? |
| 16:24:48 | * | mflamer joined #nimrod |
| 16:33:12 | OrionPKM | so dom, no ideas on the versioning thing? |
| 16:34:47 | dom96 | ehh, what do you mean? Do you want the Nimrod compiler version? |
| 16:36:37 | OrionPKM | no |
| 16:36:46 | OrionPKM | like an automatically generated build version |
| 16:37:07 | OrionPKM | if you keep compiling somefile.nim over and over, it keeps incrementing |
| 16:39:36 | dom96 | I don't think that exists. What do you want it for? |
| 16:42:03 | OrionPKM | so I can use it to generate versioned css/js files |
| 16:42:09 | OrionPKM | to invalidate cache |
| 16:45:02 | * | q66 joined #nimrod |
| 16:47:05 | * | mflamer quit (Ping timeout: 245 seconds) |
| 16:52:45 | * | fowl quit (Ping timeout: 245 seconds) |
| 16:53:12 | * | fowl joined #nimrod |
| 16:57:51 | BitPuffin | hmm |
| 16:58:08 | BitPuffin | I guess one might be able to use a TBO to simulate particles on the GPU |
| 17:00:18 | BitPuffin | question is if they can write to the buffer |
| 17:00:20 | BitPuffin | not sure |
| 17:09:02 | EXetoC | look, irc on mobile! high tech stuff man |
| 17:10:35 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 17:13:24 | BitPuffin | lol EXetoC :) |
| 17:13:52 | BitPuffin | I should probably use my phone more for irc though |
| 17:13:55 | BitPuffin | thanks for reminding me |
| 17:13:59 | BitPuffin | bbl! |
| 17:14:03 | * | BitPuffin quit (Quit: WeeChat 0.4.2) |
| 17:16:26 | * | PortablePuffin joined #nimrod |
| 17:16:33 | PortablePuffin | yay |
| 17:17:17 | EXetoC | orionpkm: rich? well im not :( |
| 17:17:35 | OrionPKM | you're a swed too? |
| 17:17:56 | EXetoC | maybe i have to work for it.lame |
| 17:18:03 | EXetoC | yes |
| 17:18:20 | OrionPKM | nobody's perfect |
| 17:19:02 | * | Hannibal_Smith joined #nimrod |
| 17:19:46 | EXetoC | :p |
| 17:20:24 | EXetoC | webskipper |
| 17:20:27 | * | gradha joined #nimrod |
| 17:20:30 | EXetoC | oops |
| 17:22:13 | EXetoC | it depends. sometimes it's clear what type is on the left side |
| 17:22:27 | gradha | OrionPKM: doesn't HTTP have enough cache invalidating methods for you to reinvent them or is JS special? |
| 17:22:46 | * | dirkk_ quit (Quit: This computer has gone to sleep) |
| 17:22:53 | * | PortablePuffin2 joined #nimrod |
| 17:23:10 | * | PortablePuffin quit (Ping timeout: 240 seconds) |
| 17:23:59 | EXetoC | very often in fact, but far from always imo |
| 17:26:50 | OrionPKM | i'm not reinventing anything gradha, it's a common technique |
| 17:27:03 | OrionPKM | the browser wont re-request a file that's cached |
| 17:27:23 | OrionPKM | until it reaches the cache's life time |
| 17:27:32 | * | hoverbear joined #nimrod |
| 17:27:44 | OrionPKM | if I do a new deployment before then, I want it to pull down the newer resources before that time |
| 17:27:52 | PortablePuffin2 | orionpkm are you sure? |
| 17:28:09 | OrionPKM | yes |
| 17:28:25 | OrionPKM | for client side caching |
| 17:28:27 | * | MFlamer joined #nimrod |
| 17:28:42 | PortablePuffin2 | well then how come you can tweak things when doing webdesign |
| 17:28:49 | Hannibal_Smith | HTTP is not an application protocol |
| 17:29:43 | Hannibal_Smith | And cache invalidation is an hard topic, generally |
| 17:30:39 | OrionPKM | because your stuff isnt cached, most likely |
| 17:30:51 | gradha | OrionPKM: I don't understand, if the server won't re-request a cached file, how does changing its contents on the server help? |
| 17:30:59 | OrionPKM | no |
| 17:31:10 | OrionPKM | I'm talking about client-side caching gradha |
| 17:31:15 | OrionPKM | http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2 |
| 17:32:18 | OrionPKM | if I have a file like app.js, a client wont request it if it's already cached with a valid expires timestamp |
| 17:32:38 | OrionPKM | unless the client forces a refresh (CTRL+F5 or something) |
| 17:33:01 | OrionPKM | but if I increment the filename referenced by the HTML, say app.002.js |
| 17:33:13 | OrionPKM | then the client will request the new file |
| 17:33:40 | gradha | the HTML file pointing to app.002.js is not cached the same way? |
| 17:33:53 | OrionPKM | no, the HTML file is not cached the same way |
| 17:33:57 | Hannibal_Smith | OrionPKM, if you are going to do this, seems like max-age in not the right thing to do |
| 17:34:23 | OrionPKM | why do you think that? |
| 17:34:56 | Hannibal_Smith | Because max-age is common for resources that have a defined lifetime, like html, images, css, js and so on |
| 17:35:07 | Hannibal_Smith | Not anything else |
| 17:35:17 | OrionPKM | you mean like exactly what I'm talking about? |
| 17:35:23 | OrionPKM | css/js/images |
| 17:35:33 | OrionPKM | static resources |
| 17:36:00 | EXetoC | know of any android irc clients with completion and highlighting |
| 17:36:15 | * | webskipper quit (Ping timeout: 245 seconds) |
| 17:36:17 | OrionPKM | Im using Expires not max-age |
| 17:36:39 | Hannibal_Smith | Ok OrionPKM, I probably got wrong, I did not follow the topic from the start |
| 17:37:38 | OrionPKM | https://developers.google.com/speed/docs/insights/LeverageBrowserCaching |
| 17:37:43 | gradha | OrionPKM: at the moment nimrod doesn't have compile time functionality to write files, therefore you can't read and update a file at compile time incrementing its value to later slurp it |
| 17:37:44 | OrionPKM | see "Using URL fingerprinting" |
| 17:38:03 | Hannibal_Smith | OrionPKM, yes I know |
| 17:38:25 | gradha | OrionPKM: Araq doesn't want any either because nimrod will soon get FFI which allows using normal IO at compile time, so then it will |
| 17:38:41 | Hannibal_Smith | But I can't understand why one would use this for serving a js, for example |
| 17:38:58 | OrionPKM | so that I can leverage the expires header, hannibal_smith |
| 17:39:00 | gradha | OrionPKM: for your current deployments you are forced to use an external program to run before your nimrod compilation command |
| 17:39:18 | gradha | OrionPKM: you can easily do that with a shell script or nakefile |
| 17:39:26 | OrionPKM | thanks gradha, maybe I'll use a staticExec or something |
| 17:39:32 | OrionPKM | to write the file |
| 17:39:51 | Hannibal_Smith | OrionPKM, if you resources are going to change, is proably better using a simpler etag |
| 17:40:05 | OrionPKM | nope |
| 17:40:08 | Hannibal_Smith | Why? |
| 17:40:35 | gradha | OrionPKM: I faced similar problems with http://stackoverflow.com/questions/19954952/how-do-i-recover-from-a-failed-import-in-nimrod, so you can have a staticExe first to update the file and then slurp the contents |
| 17:40:55 | OrionPKM | because that still involves a request |
| 17:41:06 | gradha | but then since you are already using external processes, it seems less brittle to put that away from source and into some external build system |
| 17:41:26 | OrionPKM | the resources are static, hannibal_smith, they only change when I release an updated version of the binary |
| 17:41:32 | Hannibal_Smith | OrionPKM, yes, it makes caching easy, the browser ask directly to the webserver if the resource has changed |
| 17:41:52 | OrionPKM | thats a much more complicated and less efficient solution |
| 17:41:58 | OrionPKM | why would I opt for that? |
| 17:43:17 | Hannibal_Smith | Ok, I get your point |
| 17:43:29 | * | EXetoC quit (Remote host closed the connection) |
| 17:44:10 | * | DAddYE joined #nimrod |
| 17:44:24 | Hannibal_Smith | Yes if you put an hash/version is a good way to handle changes |
| 17:44:25 | * | DAddYE quit (Remote host closed the connection) |
| 17:44:34 | OrionPKM | thanks gradha, I'll think about it some more |
| 17:44:35 | Hannibal_Smith | Probably it makes development more fragile |
| 17:44:46 | Hannibal_Smith | But works |
| 17:45:01 | OrionPKM | in what way |
| 17:45:20 | gradha | OrionPKM: most likely you will end up with a "version.exe" which you can staticExe, that will return the current build version as string and internally store/update the file |
| 17:45:27 | Hannibal_Smith | Because resources path are going to change to every revision |
| 17:45:41 | Hannibal_Smith | And your build script have to handle that |
| 17:45:59 | Hannibal_Smith | And keep this in sync with your code |
| 17:46:04 | * | DAddYE joined #nimrod |
| 17:46:09 | * | DAddYE quit (Remote host closed the connection) |
| 17:46:11 | OrionPKM | nope |
| 17:46:24 | * | DAddYE joined #nimrod |
| 17:46:27 | Hannibal_Smith | How would you handle that? |
| 17:46:29 | OrionPKM | the filenames will remain the same, only the request path will change |
| 17:47:06 | OrionPKM | request to app.___.js return app.js |
| 17:48:02 | Hannibal_Smith | So you only change your code? |
| 17:48:14 | OrionPKM | no, i only recompile |
| 17:48:23 | OrionPKM | if the file changes, a new version # gets generated |
| 17:48:58 | Hannibal_Smith | You are going to hash a file for every request? |
| 17:49:34 | OrionPKM | no, hashed at compile time |
| 17:49:55 | Hannibal_Smith | Ok, now I undestand what you were talking about |
| 17:50:06 | Hannibal_Smith | And I find it a great way |
| 17:51:46 | * | boydgreenfield joined #nimrod |
| 17:51:47 | * | PortablePuffin2 quit (Read error: Connection reset by peer) |
| 17:54:40 | OrionPKM | gradha I think thats exactly what Im going to end up doing lol >:\ |
| 17:54:52 | * | OrionPKM cant wait until the new VM is done :) |
| 17:55:14 | * | hoverbear quit (Quit: Textual IRC Client: www.textualapp.com) |
| 17:56:29 | gradha | isn't it done already? |
| 17:57:12 | OrionPKM | dont think so.. or if it is it's in a diff branch |
| 17:57:54 | Hannibal_Smith | OrionPKM, I'm only another curiosity, can nimrod call function at compile time, or are you going to parse nimrod to the this cache strategy? |
| 17:58:12 | gradha | Hannibal_Smith: it can, it's called a macro |
| 17:58:26 | Hannibal_Smith | It can call any library? |
| 17:58:29 | OrionPKM | yes, I'm using compiletime procs |
| 17:58:36 | gradha | Hannibal_Smith: yes, macros can run at compile time any nimrod code |
| 17:58:36 | OrionPKM | but they are very limited right now |
| 17:58:43 | Hannibal_Smith | Wow that's great |
| 17:58:45 | Hannibal_Smith | Thank you |
| 17:58:45 | OrionPKM | you cant write files etc |
| 17:59:11 | OrionPKM | compiletime procs and macros will become much more powerful |
| 17:59:19 | OrionPKM | with the new VM, if I understand correctly |
| 17:59:39 | OrionPKM | const someValue = someProc() <--- someProc is executed at compiletime |
| 17:59:42 | gradha | yes, that's on the vm2 branch https://github.com/Araq/Nimrod/commit/6ffaa235343e4f8d682cf08330401b9d63354586 |
| 18:00:25 | OrionPKM | also I think static: call() <-- call is executed at compile time |
| 18:01:31 | Hannibal_Smith | C++ and D has the concept of compile time functions, but they can't call any library of make any syscall |
| 18:01:44 | Hannibal_Smith | This is much more interesting |
| 18:01:54 | gradha | Hannibal_Smith: presumably that's what function foreign interface will allow for nimrod |
| 18:01:54 | Hannibal_Smith | *or make |
| 18:01:59 | gradha | or so we are told |
| 18:02:52 | * | hoverbear joined #nimrod |
| 18:05:27 | OrionPKM | gradha is there any forum info somewhere on the future FFI |
| 18:06:25 | gradha | can't remember any, just that it will work and bring peace, and make all geeks marry victoria secrets models and stuff |
| 18:06:25 | OrionPKM | uh huh |
| 18:06:25 | gradha | there's possibly more about FFI in the irc logs than the forum |
| 18:06:25 | OrionPKM | is vm2 planned for 0.9.4? |
| 18:06:29 | gradha | OrionPKM: yes, but plans always go very wrong |
| 18:07:18 | OrionPKM | :) |
| 18:07:28 | OrionPKM | better to delay the release than go w/o IMO :P |
| 18:07:56 | gradha | the only scenario where that attitute pays of is when version numbers are expensive |
| 18:08:17 | OrionPKM | heh |
| 18:08:24 | OrionPKM | good point |
| 18:08:55 | OrionPKM | hannibal_smith were you the one working on the VS plugin, or am I thinking of someone else? |
| 18:09:12 | Hannibal_Smith | I'm only a newbie, so is someone else |
| 18:09:24 | OrionPKM | ah k |
| 18:11:37 | * | shodan45 joined #nimrod |
| 18:19:20 | * | brson joined #nimrod |
| 18:26:24 | gradha | fowl: can't find und in fowltek, did that move? |
| 18:28:40 | gradha | fowl: oh, you renamed it to add in a descriptive commit "updates" |
| 18:29:36 | * | CarpNet quit (Quit: Leaving) |
| 18:35:42 | * | dirkk0 joined #nimrod |
| 18:36:08 | * | EXetoC joined #nimrod |
| 18:45:23 | * | zielmicha joined #nimrod |
| 18:50:08 | * | hoverbear quit (Quit: Hibernating, be back soon.) |
| 18:51:20 | * | dirkk0 quit (Quit: Leaving) |
| 18:54:18 | * | brson_ joined #nimrod |
| 18:54:49 | * | zielmicha quit (Read error: No route to host) |
| 18:58:15 | * | brson quit (Ping timeout: 246 seconds) |
| 19:01:34 | * | zielmicha joined #nimrod |
| 19:02:34 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 19:04:24 | * | boydgreenfield joined #nimrod |
| 19:04:59 | * | ics joined #nimrod |
| 19:19:18 | * | OrionPKM quit (Remote host closed the connection) |
| 19:22:39 | * | OrionPKM joined #nimrod |
| 19:26:23 | * | brson_ quit (Quit: leaving) |
| 19:26:38 | * | brson joined #nimrod |
| 19:31:02 | gradha | good night, honey badgers |
| 19:31:06 | * | gradha quit (Quit: bbl, need to watch http://www.youtube.com/watch?v=hcDEWiH-ciw again) |
| 19:35:49 | OrionPKM | night |
| 19:41:34 | * | exetoc42 joined #nimrod |
| 19:43:00 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 19:44:19 | * | exetoc42 quit (Client Quit) |
| 19:50:12 | * | snearch joined #nimrod |
| 19:53:24 | dom96 | hello snearch, welcome |
| 20:02:31 | * | brson quit (Ping timeout: 246 seconds) |
| 20:07:37 | snearch | hello dom96 |
| 20:07:48 | snearch | thanks |
| 20:09:14 | Araq | hi snearch welcome |
| 20:10:39 | snearch | thanks, Araq |
| 20:21:51 | OrionPKM | dom96 i think i might switch irc familiar to mongoose |
| 20:22:02 | OrionPKM | instead of httpserver and sockets stdlibs |
| 20:23:07 | dom96 | Wouldn't it be easier to fix httpserver? |
| 20:24:04 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 20:24:14 | * | CarpNet joined #nimrod |
| 20:26:00 | OrionPKM | well, also asyncio |
| 20:26:05 | OrionPKM | and sockets |
| 20:26:19 | OrionPKM | mongoose uses epoll and stuff too I think |
| 20:34:33 | radsoc | Araq: Hi, I tested copyMem to fill a CountTable key (defined as an array of char), instead of a char by char copy, and the performance boost is very significant (my process is twice as fast). The problem is that, actually, the key length will only be known at runtime so I can't use an array. And openarrays "can only be used for parameters". And Mem copying strings (or seqs) gives me runtime errors. Is there any other alternative ? |
| 20:44:49 | Araq | radsoc: not sure what you mean, '=' for strings does the mem copy for you |
| 20:46:17 | * | webskipper joined #nimrod |
| 20:46:25 | Araq | TCountTable[string] should do what you want? |
| 20:50:17 | * | snearch quit (Quit: Verlassend) |
| 20:54:28 | radsoc | Araq: You're right: I've forgot to add that, at the start of my process, I only have a (pointer to) a memfile, which I have to split in fixed size chunks. Each chunk is a key, but it's a array of char not a string: I can't use =. |
| 20:56:24 | Araq | well memory mapped files are not as fast as you might think |
| 20:57:15 | Araq | but that's a different topic |
| 20:57:26 | Araq | so what you need is this: |
| 20:57:58 | * | q66 quit (Quit: Leaving) |
| 20:58:02 | * | Kooda is also interested in memfiles doc/examples |
| 20:58:15 | Araq | ah, wait a second, I'm providing a gist |
| 21:01:10 | * | q66 joined #nimrod |
| 21:03:44 | Araq | proc fastToString(s: cstring, len: int, result: var string) = |
| 21:03:46 | Araq | result.setLen(len) |
| 21:03:47 | Araq | copyMem(addr result[0], s, len) |
| 21:04:00 | Araq | lol it's small enough to paste in here ;-) |
| 21:04:14 | Araq | the trick is to use the mutability of strings to our advantage |
| 21:04:22 | Araq | you need to use this as: |
| 21:04:40 | Araq | var tmp = "" # allocate string at startup |
| 21:04:50 | Araq | while ... # your processing loop: |
| 21:05:18 | Araq | fastToString(memFileBuffer, yourScannedLen, tmp) |
| 21:05:35 | Araq | countTab.inc(tmp) |
| 21:06:18 | Araq | note that 'inc' copies the string key if it's a fresh entry |
| 21:06:36 | Araq | since it's copied, we can re-use the 'tmp' string though |
| 21:06:58 | Araq | and end up with an optimal number of allocations |
| 21:07:46 | radsoc | I have to try this. Thanks a lot Araq, you're very helpful! |
| 21:07:56 | Kooda | Thanks :) |
| 21:09:17 | Kooda | Any pointer on how to read structured data as well? |
| 21:09:22 | * | boydgreenfield joined #nimrod |
| 21:10:08 | OrionPKM | whats the diff between that and substr |
| 21:10:27 | Araq | substr doesn't exist for cstring |
| 21:10:41 | OrionPKM | ah |
| 21:10:48 | Araq | and uts interface is wrong for performance |
| 21:10:51 | Araq | *its |
| 21:11:04 | Araq | note the 'var stringÄ |
| 21:11:09 | Araq | param |
| 21:11:35 | OrionPKM | didnt notice that |
| 21:11:41 | OrionPKM | thought it was the normal result variable |
| 21:12:35 | Kooda | Yeah, my too at first read :Þ |
| 21:12:54 | Araq | well that's the reason 'result' is no keyword |
| 21:13:16 | Araq | so that the ': T' --> 'result: var T' refactoring is painless |
| 21:13:58 | Araq | (which is a standard transformation really) |
| 21:14:38 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 21:22:07 | * | brson joined #nimrod |
| 21:24:03 | Kooda | Araq: is there a way to do some kind of pointer arithmetic? :x |
| 21:27:35 | Araq | Kooda: sure, fowl even has a package for it, but it's simple enough: |
| 21:28:25 | Araq | template `+=!` (a, b: expr): expr = a = cast[type(a)](cast[int](a) + b) |
| 21:28:26 | Kooda | For now I’m using cstring with array acces |
| 21:28:30 | Kooda | ^^' |
| 21:30:24 | Araq | Kooda, radsoc more efficient than memfiles can be the less known and badly documented "lexbase" module |
| 21:31:10 | Araq | which has logic that reuses the IO buffer and only line ending need checks whether a buffer refill is necessary |
| 21:31:39 | Araq | with memfiles the OS has no choice but to give you fresh pages |
| 21:31:50 | Araq | which is bad for the cpu caches |
| 21:32:15 | Araq | I use memfiles only if I need random access |
| 21:32:36 | Araq | for sequential access they are not optimal |
| 21:32:52 | Kooda | Well, that’s pretty much my case, and later it would be nice to decompress data to memory on the fly as well |
| 21:33:10 | Kooda | I read structured data from a binary file |
| 21:34:12 | Kooda | (a N64 rom) |
| 21:36:48 | OrionPKM | you're making an emulator or someting? |
| 21:37:12 | Kooda | I’m only trying to read a rom for the moment. |
| 21:38:00 | radsoc | Araq: fastTotString is quite slower. I just had to replace the cstring parameter with a pointer (because of my memfile): does it make any difference? Thanks for pointing us to lexbase (but the doc is a little terse) |
| 21:38:45 | Araq | radsoc: well you have to use pointer arithmetic for the cstring+len combo to work |
| 21:39:17 | Araq | well I don't know how you do your parsing |
| 21:39:36 | Araq | pointer vs cstring makes no difference |
| 21:42:25 | radsoc | I just use pointer arithmetic and it works. But copying char by char is faster: it's weird. |
| 21:43:33 | radsoc | I have something like this: cast[pointer](cast[TAddress](memfileSource.mem)+i*keyLen*cSize) |
| 21:43:50 | Araq | ok hmm |
| 21:44:10 | Araq | well you said copymem is faster |
| 21:44:21 | Araq | and now you say it isn't |
| 21:44:32 | Araq | so make up your mind :P |
| 21:44:50 | radsoc | copymem with an array is even faster than copying char by char. |
| 21:45:00 | * | boydgreenfield joined #nimrod |
| 21:45:14 | radsoc | but your copymem is slower :P |
| 21:45:53 | EXetoC | release mode? |
| 21:46:37 | radsoc | and it's weird |
| 21:47:15 | Araq | yup, modern cpus are crazy |
| 21:48:06 | Araq | it's pretty much luck how fast you can get your algorithms to run |
| 21:49:51 | Kooda | Araq: any way to get the address of the ith char of a cstring? or should I really use pointer arithmetics? |
| 21:50:22 | Kooda | (sorry to bother you, I’m still trying to make my mind around the language ^^') |
| 21:50:33 | radsoc | And can I use a macro or something like this? (my key length is always between 2 and 32 char) : it's weird too but... |
| 21:51:20 | Araq | radsoc: well then use an array[33, char] |
| 21:51:38 | Araq | if the key length is always smaller than that |
| 21:51:57 | Araq | Kooda: addr(s[i]) works too, you know |
| 21:52:21 | radsoc | I tried that but it's 50% slower and memory usage is 50% higher |
| 21:52:32 | Kooda | Araq: I get Error: expression has no address |
| 21:52:38 | * | PortablePuffin joined #nimrod |
| 21:55:27 | Hannibal_Smith | <Araq> it's pretty much luck how fast you can get your algorithms to run <-Is it not a bit extreme argument? |
| 21:56:34 | Araq | radsoc: well I don't follow sorry. So arrays are faster but not if you store them in the count table? |
| 21:58:33 | radsoc | Araq: using an array[0..31,char] is 50% slower than using an array[0..9,char] and memory usage is 50% higher |
| 22:00:42 | radsoc | and most of my keys will be between 2 and 10 char |
| 22:00:54 | Araq | Hannibal_Smith: maybe it's better when you use the cachegrind performance tools etc. I'm always too lazy to do so. |
| 22:03:14 | Hannibal_Smith | I'm convinced that if you really want performance, you have to know well all the assembly set of the CPU and how it works...no compiler can do this for you...but I'm only a student, so my opinion for sure contains flaws |
| 22:03:41 | Hannibal_Smith | And yes, use a good profiler, like VTune or perf |
| 22:07:10 | Hannibal_Smith | I'm really a nood. but... |
| 22:07:11 | Hannibal_Smith | <radsoc> I just use pointer arithmetic and it works. But copying char by char is faster: it's weird. |
| 22:07:11 | Hannibal_Smith | <radsoc> I have something like this: cast[pointer](cast[TAddress](memfileSource.mem)+i*keyLen*cSize) |
| 22:07:25 | * | Varriount joined #nimrod |
| 22:07:33 | Hannibal_Smith | For sure all you pay a little this pointer arithmetic |
| 22:09:36 | Araq | well I know the assembler set and how it "works" ... |
| 22:09:53 | Hannibal_Smith | Araq, I'm not saying this |
| 22:10:21 | Hannibal_Smith | What I'm saying that you can't really don't think about the hardware if you care about performance |
| 22:10:57 | Hannibal_Smith | I'm pretty sure that you have an enormous years of good study on your history |
| 22:11:17 | Hannibal_Smith | It wasn't my point |
| 22:11:22 | Araq | well let me put it this way: |
| 22:12:43 | Araq | knowing your algorithms and cpu architecture and profiling gets you to a solution that is close to optimal, albeit there is still a factor of 2-3x you can get then with luck ;-) |
| 22:13:18 | Araq | so "close to optimal" is not really close |
| 22:13:18 | Hannibal_Smith | I can't really view how |
| 22:14:03 | Araq | you can insert nop instructions at strategic places to make your code run faster for instance |
| 22:14:53 | * | ics joined #nimrod |
| 22:15:07 | Kooda | ǒ_o |
| 22:15:18 | Hannibal_Smith | Yes, you can understand after you studied about the cpu that your code will run, and with profiling with hardware counters |
| 22:15:22 | linkmauve1 | Kooda, think branch prediction for example. |
| 22:15:37 | Hannibal_Smith | If you L1D cache stalls |
| 22:15:47 | linkmauve1 | If it starts executing a long instruction while you wanted to go to the other branch, it will stall the pipeline. |
| 22:15:50 | Hannibal_Smith | You can view thanks to a good profiler where |
| 22:15:57 | Hannibal_Smith | And undestand why it stalls |
| 22:16:28 | Hannibal_Smith | Uhm---L1C? Ahh my memory is really bad |
| 22:16:43 | Hannibal_Smith | For sure L1D is not for code |
| 22:17:10 | linkmauve1 | Hannibal_Smith, a good compiler would do that for you, and not only on your specific pet architecture but on many more past, current and future. |
| 22:17:13 | Hannibal_Smith | But my point is, if a cpu is a machine, if you know how it works |
| 22:17:45 | Hannibal_Smith | linkmauve1, no, a good compiler can't because if has to be conservative |
| 22:18:06 | Hannibal_Smith | And can't really understand your problem |
| 22:18:19 | Hannibal_Smith | Of really change your data structure, memory access patterns... |
| 22:18:28 | Hannibal_Smith | *or really |
| 22:18:40 | * | PortablePuffin quit (Ping timeout: 246 seconds) |
| 22:20:02 | linkmauve1 | Of course algorithmically you still have to think by yourself, but many hardware-specific optimisations are well-understood and implemented in optimising compilers. |
| 22:20:28 | Varriount | *cough*intel compiler*cough* |
| 22:20:51 | linkmauve1 | You work with your tools, you can’t optimise everything by yourself, and the compiler cannot do it alone either. |
| 22:21:20 | Hannibal_Smith | <linkmauve1> You work with your tools, you can’t optimise everything by yourself, and the compiler cannot do it alone either. <-Yes, this is my point |
| 22:22:05 | Hannibal_Smith | IMHO, a language, have to leave space for letting the programmer to "let the compiler" optimize better your code |
| 22:22:27 | Hannibal_Smith | For example, in Java it is impossibile to tell what is the memory layout of a structure |
| 22:22:37 | Hannibal_Smith | Is not a compiler fault |
| 22:22:41 | Hannibal_Smith | But a language fault |
| 22:23:26 | Hannibal_Smith | And these are pretty basic optimizations |
| 22:25:46 | Hannibal_Smith | <Varriount> *cough*intel compiler*cough* <-If you define a struct that waste space because padding, Intel compiler can't fix that |
| 22:28:12 | Hannibal_Smith | Or tell the compiler to add some padding to align that to a cache line size... |
| 22:28:19 | Hannibal_Smith | And these are basics |
| 22:28:49 | Hannibal_Smith | I repeat, I'm only a student, so I can talk about basics |
| 22:28:59 | Hannibal_Smith | For sure there is a lot more |
| 22:29:55 | Hannibal_Smith | C and C++ for example thanks to intrinsics have gained a good way to tell to the compiler |
| 22:30:07 | Hannibal_Smith | That they really want the compiler do |
| 22:31:39 | * | ics quit (Ping timeout: 240 seconds) |
| 22:32:40 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 22:34:34 | * | ics joined #nimrod |
| 22:35:22 | radsoc | Araq: thanks again for your help. good night. |
| 22:35:31 | * | radsoc left #nimrod (#nimrod) |
| 22:49:11 | * | ics quit (Ping timeout: 252 seconds) |
| 22:51:17 | * | BitPuffin joined #nimrod |
| 22:52:37 | * | hoverbear joined #nimrod |
| 22:53:44 | * | ics joined #nimrod |
| 22:54:36 | * | CarpNet quit (Quit: Leaving) |
| 23:01:47 | EXetoC | BitPuffin: what up |
| 23:02:15 | Varriount | Hannibal_Smith, do you have any idea how one would wrap C structs using bit fields, from an external source, in nimrod? |
| 23:05:21 | Hannibal_Smith | Varriount, is a question more for Araq than me |
| 23:08:35 | Araq | Varriount: depends on whether you need to access the bit fields |
| 23:08:49 | Araq | if not you only have to ensure the object ends up having the same size |
| 23:09:12 | Araq | if you do you're in a world of fun with bitmasks ops |
| 23:09:58 | Araq | or you patch the compiler to support field {.bits: 3.}: int like I intended to do |
| 23:10:14 | * | ics quit (Ping timeout: 240 seconds) |
| 23:10:50 | Araq | 'bits' and 'union' pragmas are the last missing pieces for full C interop |
| 23:11:06 | OrionPKM | are those planned? |
| 23:12:16 | * | ics joined #nimrod |
| 23:15:19 | Araq | yes |
| 23:15:27 | Araq | I need to sleep now. good night |
| 23:15:36 | Hannibal_Smith | Bye |
| 23:27:58 | * | ics quit (Ping timeout: 246 seconds) |
| 23:35:24 | BitPuffin | EXetoC: now wurkin! you? |
| 23:38:51 | * | ics joined #nimrod |
| 23:40:40 | * | MFlamer quit (Ping timeout: 265 seconds) |
| 23:46:11 | EXetoC | BitPuffin: not much |
| 23:49:11 | * | ics quit (Ping timeout: 260 seconds) |
| 23:50:13 | * | boydgreenfield joined #nimrod |
| 23:53:34 | * | ics joined #nimrod |
| 23:56:13 | BitPuffin | EXetoC: considering moving to the bed though and finishing reading there |