| 00:04:14 | Demos | IRC logs are down |
| 00:06:24 | EXetoC | it's not exactly a big improvement over the traditional way of string formatting |
| 00:07:16 | Varriount | Demos: Go yell at dom96, he's the one with access to the server. |
| 00:07:29 | Varriount | Demos: Probably disk space taken up. |
| 00:17:41 | * | springbok quit (Ping timeout: 264 seconds) |
| 00:30:13 | * | shevy left #nimrod ("I'll be back ... maybe") |
| 00:48:03 | fowl | Varriount, idk what araq was smoking, you can definitely do unpacking in a for loop |
| 00:48:07 | fowl | let u = @[(1,2),(3,4)] |
| 00:48:07 | fowl | for a,b in items(u): |
| 00:49:24 | * | brson joined #nimrod |
| 00:55:12 | * | xenagi joined #nimrod |
| 00:58:38 | Varriount | Well that's interesting... |
| 00:59:01 | Varriount | Isn't a single threaded program only able to utilize one CPU core for computation at any one time? |
| 01:01:55 | * | q66 quit (Quit: Leaving) |
| 01:22:28 | Varriount | You know, there are times when a goto would be /really/ helpful |
| 01:31:47 | njoejoe | my first attempt at a macro doesn't work yet. not sure what all the problems are, but I think one is that the macro needs to replace the line it is working on: https://gist.github.com/jots/1de3c8af82f884c1ae1a |
| 01:39:21 | Varriount | njoejoe: What is it that you want the macro to do? |
| 01:40:35 | njoejoe | var1:int, var2:string,var3:float = line.split(",") # place data into vars and coerce into proper types. |
| 01:40:36 | EXetoC | assignment unpacking |
| 01:41:05 | njoejoe | but as you can see i have no idea what i'm doing :-) |
| 01:41:12 | Varriount | njoejoe: We already have tuple unpacking, you know. |
| 01:41:29 | EXetoC | it's limited |
| 01:41:59 | EXetoC | not that I said assignment rather than initialization |
| 01:42:35 | reactormonk | Varriount, like? |
| 01:42:56 | Varriount | reactormonk: What do you mean? |
| 01:43:03 | reactormonk | Varriount, when do you want a goto? |
| 01:43:11 | EXetoC | *note |
| 01:43:18 | njoejoe | i do not know about this tuple unpacking |
| 01:43:36 | Varriount | reactormonk: At one point during the procedure I'm writing. Although I've gotten past the point of needing this. |
| 01:44:06 | Varriount | njoejoe: "var (x, y) = (1, 2)" |
| 01:46:52 | njoejoe | Varriount: but that won't work in a loop right? i want the var statement before the loop. plus now i kind of like the idea of coercing the strings into proper types, perhaps it's too much... |
| 01:47:21 | * | flaviu joined #nimrod |
| 01:51:08 | flaviu | njoejoe: Have you discovered dumpTree? |
| 01:51:17 | Varriount | njoejoe: Well, the first thing you should know about macros is that you should try to resist the urge to just stringify and re-parse stuff. Working with the AST directly is usually better. |
| 01:51:48 | flaviu | Varriount: In this case, working with the AST is better, I like using strings for macro codegen |
| 01:52:09 | Varriount | njoejoe: And you're right, the unpacking won't work with already declared variables. |
| 01:55:03 | njoejoe | i will look into working with AST after dinner |
| 01:55:42 | Varriount | njoejoe: So what you want is to unpack a sequence of strings into their proper representations, like int's or such. |
| 01:56:17 | Varriount | njoejoe: I have some suggestions that may help. Ping me when you get back. |
| 02:00:06 | flaviu | njoejoe: I don't think that syntax is going to work. You might have to settle for `(a: foo, b: bar) := asd` |
| 02:11:09 | * | brson quit (Ping timeout: 252 seconds) |
| 02:14:00 | * | Jesin quit (Quit: Leaving) |
| 02:16:09 | * | Jesin joined #nimrod |
| 02:52:35 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 02:59:47 | * | brihat quit (Ping timeout: 265 seconds) |
| 03:04:45 | flaviu | njoejoe: I have to go to sleep, but https://gist.github.com/11360767 should do what you'd like, as soon as I can figure out the (compiler?) bugs |
| 03:04:49 | * | flaviu quit (Quit: Leaving.) |
| 03:05:27 | * | Varriount|Mobile quit (Remote host closed the connection) |
| 03:07:15 | fowl | hm |
| 03:08:45 | * | Skrylar joined #nimrod |
| 03:08:58 | fowl | njoejoe, if you want to run that ^ the fix is to change line 5 to " result = newStmtList(newLetStmt(tempVar, b))" |
| 03:14:56 | * | Demos quit (Read error: Connection reset by peer) |
| 03:31:49 | * | Jesin quit (Quit: Leaving) |
| 03:35:02 | reactormonk | gotta say, make is rather useful sometimes - except for compiling ^^ |
| 03:49:15 | * | BitPuffin joined #nimrod |
| 04:08:15 | * | darithorn quit (Ping timeout: 276 seconds) |
| 04:11:11 | * | darithorn joined #nimrod |
| 04:15:40 | * | darithorn quit (Ping timeout: 265 seconds) |
| 04:17:15 | * | brihat joined #nimrod |
| 04:18:20 | * | njoejoe quit (Quit: Page closed) |
| 04:36:27 | * | bbodi joined #nimrod |
| 04:39:32 | BitPuffin | Managed to get nimrod mentioned on a podcast \o/ https://www.youtube.com/watch?feature=player_detailpage&v=bdqLQHeuigs#t=6293 |
| 04:40:01 | * | bbodi quit (Client Quit) |
| 05:34:06 | * | brihat left #nimrod (#nimrod) |
| 05:36:11 | * | isenmann joined #nimrod |
| 07:41:32 | * | bbodi joined #nimrod |
| 08:21:50 | * | Mat3 joined #nimrod |
| 08:22:00 | Mat3 | G'Day |
| 08:22:16 | bbodi | good day! |
| 08:22:47 | Mat3 | hello bbodi |
| 08:23:58 | Mat3 | just build version 0.9.4 and the sources compile out-of-the-box, nice work ! |
| 08:41:38 | Araq | that's the least we could do, really ;-) |
| 08:42:41 | BitPuffin | Araq: are you happy with me now? :D |
| 08:44:12 | dom96 | BitPuffin: Do they have IRC logs? I'm curious what went on in that IRC channel when they mentioned Nimrod |
| 08:44:48 | BitPuffin | dom96: not sure I asked in their channel for you |
| 08:48:51 | dom96 | brb |
| 08:49:16 | milosn | hmmm I posted my weekend's work in Nimrod to our ReviewBoard tool :), if we are lucky Nimrod will be integral part of the INTERNET soon, generating master DNS zone file for .LA TLD |
| 08:49:25 | milosn | good morning by the way |
| 08:49:26 | milosn | :) |
| 08:52:49 | BitPuffin | milosn: dude, that wolud be awesome |
| 08:54:22 | milosn | BitPuffin: its not as exciting as ive made it look :D ... its 250 line script ... but its cool anyways |
| 08:54:28 | milosn | lets see what boss says :P |
| 08:57:02 | BitPuffin | milosn: well it's still nice :) |
| 09:09:22 | EXetoC | you should port linux to nimrod |
| 09:11:45 | dom96 | milosn: that's still awesome. What does the script do? |
| 09:12:58 | * | Mat3 quit (Ping timeout: 240 seconds) |
| 09:13:33 | dom96 | BitPuffin: any reply? |
| 09:14:46 | BitPuffin | dom96: yeah, NSA |
| 09:19:08 | dom96 | The NSA won't help me :\ |
| 09:21:26 | BitPuffin | dom96: you should call them and ask |
| 09:21:33 | BitPuffin | dom96: GCHQ probably has the logs as well |
| 09:21:45 | BitPuffin | dom96: and they are probably more likely to help you than NSA since you live in the uk |
| 09:21:50 | BitPuffin | and the podcast is a UK podcast |
| 09:22:03 | dom96 | BitPuffin: They're probably spying on me right now anyway, if they could help me they would have already :P |
| 09:27:43 | milosn | dom96: it generates bind zone file from sqlite DB :) ... its a weird arragement we have where we make our customers be in charge of actuall zone generation ... so we supply them portable DB and tool to generate the zone |
| 09:28:11 | milosn | so its like, they are in charge, but they really are not ... but makes them happy |
| 09:28:23 | dom96 | hah |
| 09:28:25 | milosn | but gov-s love thinking they are in charge |
| 09:28:34 | milosn | .LA is laos |
| 09:28:52 | milosn | we market it as Los Angeles :) |
| 09:29:03 | dom96 | yeah, I just looked it up and was reading about Laos. |
| 09:29:06 | * | milosn works for DNS registry |
| 09:29:43 | dom96 | From the pictures it looks very nice. |
| 09:30:17 | milosn | dunno never been there, we just sent them one 1U server where they "generate" the zone :D |
| 09:30:51 | dom96 | oh hah. Where are you from then? |
| 09:31:06 | milosn | i am serbian, but i am in London now |
| 09:31:24 | dom96 | cool |
| 09:31:55 | dom96 | Is the company in charge of that TLD based in London then? |
| 09:32:03 | milosn | yup |
| 09:32:19 | * | Mat3 joined #nimrod |
| 09:32:34 | milosn | i mean ... we run it, Laos gov is in charge :) |
| 09:32:44 | milosn | they even generate the zone :P |
| 09:32:45 | milosn | :D |
| 09:33:06 | BitPuffin | milosn: ah how long are you staying in london? |
| 09:33:30 | milosn | BitPuffin: dunno, till the end of time? :) |
| 09:33:40 | milosn | BitPuffin: i live here now, in UK last 8 years |
| 09:35:33 | BitPuffin | ah haha |
| 09:35:34 | BitPuffin | cool |
| 09:44:20 | * | faassen joined #nimrod |
| 10:05:34 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 10:27:28 | Mat3 | ciao |
| 10:27:33 | * | Mat3 quit (Quit: Verlassend) |
| 10:47:32 | * | EXetoC joined #nimrod |
| 10:58:24 | * | nande quit (Remote host closed the connection) |
| 11:38:09 | milosn | heh |
| 11:38:53 | milosn | now i have strange problem, app which takes 3-4 seconds to execute on arch linux and debian ... takes more than 1min on centos6 |
| 11:38:56 | milosn | :) |
| 11:39:22 | milosn | mind you i had to do this: |
| 11:39:24 | milosn | ln -sf /lib64/libpcre.so.0 /lib64/libpcre.so.1 |
| 11:39:37 | milosn | centos6 has wrong version of PCRE |
| 11:40:00 | milosn | could that be the cause of the slowness? |
| 11:42:58 | Araq | yes. you should ensure you use a version of PCRE that has its JIT enabled |
| 11:57:39 | EXetoC | when do you not want that? |
| 11:58:59 | EXetoC | all these compile-time flags |
| 12:02:24 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 12:19:41 | milosn | Araq: hmmm thats a show stopper ... |
| 12:20:01 | milosn | i cant have this app run a minute, and i cant package my own libpcre |
| 12:20:03 | milosn | :( |
| 12:20:33 | milosn | hmmmm |
| 12:20:53 | * | faassen quit (Remote host closed the connection) |
| 12:21:13 | dom96 | maybe you could use pegs instead of the re module? |
| 12:25:17 | bbodi | do default parameters work on methods? |
| 12:28:13 | dom96 | try it and see |
| 12:29:13 | bbodi | :) I asked it because it seems it does not work |
| 12:29:40 | bbodi | The original methos is called, not the overloader |
| 12:32:12 | dom96 | i see |
| 12:32:24 | dom96 | in that case i don't know |
| 12:32:34 | dom96 | i never had a need for methods |
| 12:33:50 | bbodi | is there any other way I can handle inheritance in Nimrod? |
| 12:33:55 | Araq | milosn: you can package your own libpcre but it's a bit of work |
| 12:34:30 | Araq | I used to merge all its .c files into a single file and do {.compile: "pcre_merged.c".} |
| 12:35:07 | Araq | you might need to patch pcre.nim, but it's not hard and I'll accept patches |
| 12:38:03 | Araq | bbodi: make a bug report, but it's likely you're simply doing it wrong :P |
| 12:42:09 | milosn | Araq: ill have a look, depends how large is PCRE ... if its dozens od C source files ... urgh |
| 12:42:20 | milosn | s/od/of |
| 12:45:02 | Araq | well you can also use multiple {.compile.} statements of course |
| 12:47:09 | milosn | Araq: ill have to have a look when i get home tonight |
| 12:50:47 | Araq | hey if it means nimrod is used in production for DNS registry, I'll even do it myself :P |
| 12:50:58 | Araq | it's not hard, just boring |
| 12:51:57 | milosn | :) |
| 12:58:09 | Araq | bbodi: I usually use closures instead of methods when I need dynamic binding |
| 12:59:29 | bbodi | yeah, I saw examples in the compiler where tuples[func1, func2] is used for these purposes, but how can I connect data with functions? (so using the this ptr) |
| 13:01:42 | Araq | a "closure" is already a pair (env, func) |
| 13:02:00 | Araq | "env" "connects the data with the function" |
| 13:02:16 | Araq | in other words you capture what you need |
| 13:02:50 | bbodi | hm, got it, I like the Idea :) |
| 13:03:09 | bbodi | then why methods were introduced? for convience? |
| 13:03:18 | milosn | Araq: so i can just merge 92 PCRE C files into one file? no modification required? |
| 13:03:25 | * | milosn looking at PCRE source |
| 13:03:35 | milosn | ive never done this, and my C is crap |
| 13:05:15 | milosn | it kinda explains my interest in nimrod :P |
| 13:05:16 | milosn | :) |
| 13:13:04 | * | Jesin joined #nimrod |
| 13:18:04 | * | BitPuffin joined #nimrod |
| 13:22:42 | * | darkf quit (Quit: Leaving) |
| 13:26:33 | dom96 | would be nice to get a native regex implementation for Nimrod. |
| 13:30:51 | milosn | dom96: thinking short-term ... what Araq suggested could be the way out for me |
| 13:30:57 | milosn | :) |
| 13:33:04 | bbodi | then why methods were introduced? for convience? |
| 13:34:33 | * | [1]Endy joined #nimrod |
| 13:35:59 | * | [2]Endy joined #nimrod |
| 13:39:01 | * | [1]Endy quit (Ping timeout: 252 seconds) |
| 13:52:05 | * | Jesin quit (Quit: Leaving) |
| 13:57:08 | OrionPK | dom96 regex at compile time |
| 13:57:15 | OrionPK | dom96 pre-compiled w/ macros |
| 13:57:28 | dom96 | yes, that too. |
| 13:57:57 | OrionPK | did you see that rust article? |
| 13:58:40 | OrionPK | http://blog.burntsushi.net/rust-regex-syntax-extensions |
| 13:58:44 | dom96 | yep |
| 14:25:46 | milosn | Araq: its not PCRE ... ive copied over libpcre.so.3 from my debian box and removed symlink i made for libpcre.so.1 -> libpcre.so.0 |
| 14:26:00 | * | bbodi quit () |
| 14:26:02 | milosn | it could be sqlite thats crapping out |
| 14:28:36 | milosn | hmm centos6 has 3.6.20 and debian is on 3.7.13 |
| 14:37:01 | * | menscrem joined #nimrod |
| 14:43:55 | * | q66 joined #nimrod |
| 14:43:55 | * | q66 quit (Changing host) |
| 14:43:56 | * | q66 joined #nimrod |
| 14:56:05 | * | Skrylar quit (Ping timeout: 264 seconds) |
| 15:59:41 | * | untitaker quit (Ping timeout: 255 seconds) |
| 16:03:15 | * | DAddYE joined #nimrod |
| 16:05:53 | * | untitaker joined #nimrod |
| 16:36:32 | * | darithorn joined #nimrod |
| 16:37:12 | * | Jesin joined #nimrod |
| 16:42:15 | * | uvelichitel joined #nimrod |
| 16:42:34 | * | Jesin quit (Quit: Leaving) |
| 17:04:42 | * | Demos joined #nimrod |
| 17:22:00 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 17:23:29 | menscrem | Hi, all. How to make a formatted output? |
| 17:26:48 | fowl | menscrem, check the strutils module, `%` and format functions |
| 17:30:44 | * | Varriount|Mobile joined #nimrod |
| 17:32:21 | menscrem | Where to look for clues format? or they are the same as in С? |
| 17:36:02 | fowl | http://build.nimrod-lang.org/docs/strutils.html#%,string,openArray[string] |
| 17:37:56 | menscrem | fowl: Thanks, did not notice |
| 17:37:57 | EXetoC | it's limited. you might have to call procs like formatFloat for example, but this might improve in the future |
| 17:39:05 | * | Matthias247 joined #nimrod |
| 17:39:38 | menscrem | EXetoC: than it's limited? |
| 17:41:05 | dom96 | For most things you can just use $ |
| 17:41:22 | EXetoC | what do you mean? it's fine in general, but doesn't yet have all the things that printf has |
| 17:42:15 | uvelichitel | fowl: What does mean 'build.' prefix in your link? I investigate http://nimrod-lang.org/documentation.html by now |
| 17:42:58 | uvelichitel | What means http://build.nimrod-lang.org/docs ? |
| 17:43:03 | EXetoC | it's for the latest compiler build, rrather than the latest release |
| 17:43:26 | uvelichitel | EXetoC: Thanks |
| 17:43:27 | EXetoC | but 0.9.4 was recently released so you won't find many differences atm |
| 17:44:36 | * | Skrylar joined #nimrod |
| 17:53:37 | Varriount|Mobile | echo + strutils |
| 17:53:50 | Varriount|Mobile | Er, strutils.format |
| 17:54:56 | * | BitPuffin joined #nimrod |
| 18:09:59 | fowl | hmm |
| 18:10:31 | fowl | reading an example X program, it uses BUFSIZ, i only found BUFSIZE in the x headers, i wonder if its ok to use >_> |
| 18:13:00 | * | Jesin joined #nimrod |
| 18:16:55 | reactormonk | fowl, I would ask somewhere on freenode |
| 18:17:23 | fowl | this is freenode |
| 18:17:49 | EXetoC | he got you there! |
| 18:17:52 | reactormonk | http://docs.purescript.org/en/latest/ <- any way we can salvage that webpage for the nimrod docs? |
| 18:23:33 | dom96 | Somebody who is bored should write a comprehensive Nimrod tutorial. |
| 18:25:26 | reactormonk | dom96, what would you take as sample to orient it on? |
| 18:26:50 | dom96 | reactormonk: not sure what you mean |
| 18:27:12 | fowl | the tutorials are already comprehensive |
| 18:27:24 | reactormonk | dom96, ^ |
| 18:27:34 | reactormonk | I think the documentation could use a search |
| 18:28:48 | dom96 | After looking at it now I guess the content is good enough. |
| 18:32:08 | reactormonk | any way to access function names, arguments, etc. via JS in the doc? Aka dump it to a .json file? |
| 18:32:17 | * | Demos quit (Read error: Connection reset by peer) |
| 18:32:57 | dom96 | It would be nice to see an example oriented tutorial though. |
| 18:33:34 | dom96 | The current tutorial doesn't teach anything about the standard lib |
| 18:34:28 | reactormonk | so you want more examples in the documentation? |
| 18:37:02 | dom96 | No, I want something similar to this: http://rustbyexample.com |
| 18:38:47 | * | brson joined #nimrod |
| 18:40:20 | * | Demos joined #nimrod |
| 18:40:20 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 18:47:28 | reactormonk | neat |
| 18:53:20 | * | Varriount|Mobile quit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) |
| 19:03:42 | * | Matthias247 joined #nimrod |
| 19:09:48 | EXetoC | meep |
| 19:10:32 | fowl | interesting syntax |
| 19:10:34 | fowl | unpacking a struct |
| 19:10:50 | fowl | let Point(x: my_x, y: my_y) = somepoint |
| 19:11:14 | fowl | * let Point{x: my_x, y: my_y} = somepoint |
| 19:18:45 | * | io2 joined #nimrod |
| 19:19:58 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 19:22:04 | Varriount | fowl: Is that from any language in particular? |
| 19:23:38 | fowl | Varriount, rust |
| 19:23:43 | dom96 | fowl: You should be able to write a macro to do that. |
| 19:24:06 | fowl | dom96, but its dreadful |
| 19:24:09 | fowl | almost c-like |
| 19:24:31 | fowl | you have to dig into the expression to find that you'll end up with variables my_x and my_y |
| 19:25:28 | * | Matthias247 joined #nimrod |
| 19:25:40 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 19:26:11 | fowl | dom96, OS module could use a function to get the clipboard contents, dont you think? |
| 19:27:39 | dom96 | fowl: gradha's genieos package has that |
| 19:28:06 | dom96 | looks like he only implemented it for Mac OS X though. |
| 19:28:23 | * | Matthias247 joined #nimrod |
| 19:28:48 | fowl | lol. Bill Gates’ Microsoft Corp. announced on Saturday that Internet Explorer versions 6 through 11 are all vulnerable to a glitch that when properly exploited can give hackers remote access to a victim’s computer. |
| 19:29:13 | dom96 | What do you guys think about D's and Rust's macros requiring a ! in their name? |
| 19:30:00 | fowl | it is silly |
| 19:30:03 | Varriount | dom96: Nimrod's first draft enhancement proposal -> https://github.com/Araq/Nimrod/wiki/Nimrod-Enhancement-Proposal-%231 |
| 19:30:58 | fowl | dom96, thanks |
| 19:31:01 | dom96 | Varriount: Cool. Anything I can do to persuade you to work on fsmonitor? |
| 19:31:18 | Varriount | dom96: Help me get this path normalization routine finished. |
| 19:31:36 | dom96 | fowl: I was reading through here: http://www.reddit.com/r/programming/comments/2441r9/syntax_extensions_and_regular_expressions_for_rust/ |
| 19:31:59 | dom96 | Apparently Walter Bright is "strongly against AST macros." |
| 19:32:24 | Varriount | dom96: https://gist.github.com/Varriount/11381792 |
| 19:32:38 | dom96 | Varriount: Sure, I'll give it a try. |
| 19:33:15 | reactormonk | dom96, aww |
| 19:33:49 | Varriount | dom96: You want fsmonitor to leverage the new async stuff, correct? |
| 19:33:54 | dom96 | Varriount: yeah |
| 19:34:25 | dom96 | Varriount: You'll probably run into bugs anyway so it won't take much of your time heh |
| 19:39:29 | dom96 | Varriount: One of your while loops is indented with 4 spaces instead of 2 |
| 19:40:03 | dom96 | (But that's not the issue) |
| 19:42:32 | Varriount | dom96: *sigh* it may be that my tactic for path normalization is too complicated, and a less efficient method would work instead. If you feel that the procedure has no hope of working, I'd at least like a path normalization procedure some other way (possibly based off of whatever boost, python, ruby, etc do) |
| 19:43:18 | dom96 | I think you've over-complicated it a bit. |
| 19:43:32 | dom96 | There is no need for two while loops. |
| 19:43:40 | Varriount | Ah, yes there is. |
| 19:43:58 | Varriount | the inner one keeps on scanning the path until it runs out of tokens. |
| 19:44:16 | Varriount | Otherwise boundaries get added between path tokens. |
| 19:44:28 | dom96 | Let me try to come up with an implementation. |
| 19:44:34 | reactormonk | Varriount, why do you need path normalization? |
| 19:44:52 | reactormonk | and can't you ask the OS for that? |
| 19:45:03 | Varriount | reactormonk: Copying stuff, and I need to figure out if two possibly nonexistant paths are equal. |
| 19:45:49 | reactormonk | Varriount, what about symlinks? |
| 19:46:32 | dom96 | what about cmpPaths? |
| 19:46:58 | reactormonk | Varriount, http://linux.die.net/man/3/realpath |
| 19:47:25 | dom96 | oh, I thought that used some OS call. |
| 19:47:26 | Varriount | reactormonk: Realpath only works on existing paths. |
| 19:47:40 | EXetoC | wrapping shit is so fun |
| 19:47:52 | reactormonk | shit sandwitch? |
| 19:48:37 | Demos | I was under the impression that the complexity of path normalization pretty much is unbounded |
| 19:49:58 | dom96 | python has both a normpath and a realpath |
| 19:56:01 | Demos | right, but they probably do not work 100% of the time |
| 19:56:41 | * | io2 quit (Ping timeout: 252 seconds) |
| 19:58:37 | * | io2 joined #nimrod |
| 20:01:30 | dom96 | Varriount: https://gist.github.com/dom96/11382471 |
| 20:02:03 | dom96 | requires more testing but should work |
| 20:02:27 | EXetoC | reactormonk: code and stuff |
| 20:06:30 | Varriount | dom96: Thanks. Now I can sleep easily tonight. (Really, this problem has been keeping me awake at night) |
| 20:09:28 | dom96 | Not until you get fsmonitor working :P |
| 20:10:07 | * | flaviu joined #nimrod |
| 20:10:30 | renesac | dom96, what if I have a file called '...something'? |
| 20:10:56 | dom96 | renesac: lol, that's why I said "requires more testing" |
| 20:14:59 | Varriount | dom96: What do you think of the NEP? |
| 20:15:32 | Varriount | It's small yet, but hopefully I can squeeze enough information out of the community to make it useful. |
| 20:17:08 | dom96 | renesac: fixed |
| 20:19:48 | dom96 | Varriount: I like it. |
| 20:19:53 | dom96 | I made a little addition |
| 20:21:34 | dom96 | Varriount: You should add code examples like in the PEP. |
| 20:22:15 | flaviu | Varriount: Link? |
| 20:22:34 | dom96 | The indentation section in the PEP is especially important IMO. I always wonder whether I am indenting my proc params correctly when they span multiple lines |
| 20:22:45 | Varriount | dom96: Can you give me a brief explanation of how async works? |
| 20:22:47 | dom96 | flaviu: https://github.com/Araq/Nimrod/wiki/Nimrod-Enhancement-Proposal-%231 |
| 20:22:50 | Varriount | flaviu: https://gist.github.com/Varriount/11381792 |
| 20:23:43 | flaviu | Thanks, I was looking for the NEP |
| 20:23:51 | dom96 | Varriount: Every async proc returns a PFuture[T]. |
| 20:24:37 | dom96 | Varriount: A PFuture is a type which holds a value of type T which can be read some time in the future. |
| 20:25:19 | dom96 | It could be instantaneously or a couple of minutes from now. |
| 20:25:57 | dom96 | A PFuture has a callback which you can set with the 'callback=' setter. |
| 20:25:59 | Varriount | dom96: Like, say, a handle? |
| 20:26:11 | dom96 | This callback will be called whenever the future completes. |
| 20:26:37 | dom96 | That does not mean that the future completed successfully though. |
| 20:26:49 | dom96 | It may have completed with an exception, you can use 'failed' to determine that. |
| 20:27:04 | dom96 | Varriount: As the value? Sure. |
| 20:27:19 | * | Varriount quit (Read error: Connection reset by peer) |
| 20:27:48 | * | Varriount joined #nimrod |
| 20:27:50 | * | cark quit (Read error: Connection reset by peer) |
| 20:28:08 | Varriount | dom96: I'm trying to figure out how to integrate Window's readDirectoryChanges call with asyncio. |
| 20:28:10 | dom96 | Varriount: check out the irc logs if you didn't get my latest message |
| 20:28:59 | Varriount | dom96: The two main methods are using IO completion ports, and callback routines. |
| 20:29:37 | dom96 | Take a look at how recv is implemented: https://github.com/Araq/Nimrod/blob/devel/lib/pure/asyncdispatch.nim#L354 |
| 20:30:16 | dom96 | you may need to export some things which are not exported |
| 20:30:35 | dom96 | Also I focused on getting the sockets to work so you may need to generalise the stuff a bit. |
| 20:31:42 | dom96 | The way the low level stuff works is that you allocate a PCustomOverlapped type. |
| 20:32:00 | dom96 | Set its data field to your own TCompletionData which includes a callback you specify |
| 20:32:23 | dom96 | and that callback will then be fired once the call you made finishes |
| 20:32:39 | dom96 | You will likely need to preallocate a buffer for the data that you are requesting |
| 20:35:14 | dom96 | Looking at the Win API docs the format is very similar to how I call recv etc. |
| 20:35:21 | dom96 | lpBuffer is your buffer |
| 20:37:18 | dom96 | Most of the work is with wrapping all the filters and other little pieces related to readDirectoryChanges |
| 20:37:46 | Varriount | Should we keep the Monitor object? |
| 20:38:14 | dom96 | First write a separate windows specific fsmonitor and then we can figure out how to merge them |
| 20:38:36 | dom96 | or perhaps we will even have a single high level module which imports the posix-specific and windows-specific fs monitors |
| 20:39:01 | dom96 | In any case, focus on getting it to work. Worry about the API later. |
| 20:41:15 | Varriount | dom96: Does any of the new async stuff use io completion ports? |
| 20:41:22 | * | flaviu quit (Quit: Leaving.) |
| 20:41:29 | dom96 | yeah, all of it. |
| 20:41:33 | Varriount | :D |
| 20:42:01 | Varriount | dom96: Can a future 'callback' multiple times? |
| 20:42:12 | dom96 | no |
| 20:42:32 | dom96 | a future cannot complete multiple times |
| 20:42:48 | dom96 | and the callback only is invoked when the future completes |
| 20:43:02 | * | pdewacht left #nimrod (#nimrod) |
| 20:49:06 | renesac | I don't like the NEP url: the '#' translates as %23 so it is difficult to see what NEP number it is |
| 20:49:11 | renesac | ^^' |
| 20:49:22 | Varriount | renesac: Feel free to change it. |
| 20:49:26 | Varriount | Or complain to github. |
| 20:50:12 | Varriount | dom96: Just a heads up, I probably won't be finished with this soon. I have exams next week, so will be studying most of this week. |
| 20:50:36 | dom96 | Varriount: That's ok. I should be studying too heh. |
| 20:50:56 | dom96 | Varriount: When do your exams finish? |
| 20:51:10 | Varriount | The 10th of May |
| 20:51:34 | Varriount | Or at least, that's when my classes are officially over. I can't remember exactly when my last exam is. |
| 20:51:40 | dom96 | so you're basically done with uni after that until september-ish? |
| 20:52:05 | Varriount | Yes, although I'm trying to get a job, and not be a lazy layabout. |
| 20:53:17 | renesac | maybe change the title to simple "NEP-0001" like python |
| 20:53:36 | dom96 | I think "NEP-1" is fine. |
| 20:53:40 | renesac | and maybe put the name of the NEP on the url |
| 20:53:46 | dom96 | no need for the leading zeros |
| 20:53:51 | renesac | right |
| 20:53:55 | Demos | Varriount: I just finished my last exam today! I am taking a hard (and compressed) physics class in the spring though |
| 20:54:21 | dom96 | My last exam is on the 12th of June :( |
| 20:54:23 | EXetoC | Araq: so you think that clang can be useful for automatic translation? there was a tool that generated xml but it was unreliable and they discontinued it eventually |
| 20:54:29 | Varriount | Demos: You're probably smarter than I am. I'm struggling in Calculus 1 |
| 20:54:48 | renesac | https://github.com/Araq/Nimrod/wiki/NEP-1 |
| 20:55:22 | Demos | I struggled all the way through calc I and II. And I barely passed the lasy physics class I took |
| 20:55:30 | Varriount | Hm. Should we have double line breaks after procedures, like python? |
| 20:55:37 | Varriount | Or just single ones? |
| 20:55:46 | renesac | the defacto standard is single ones |
| 20:55:58 | renesac | araq likes line density |
| 20:55:58 | Demos | turns out that for the big requirements (even physics) there is no need to actually understand the material, you just memorize stuff. |
| 20:56:19 | Demos | I use no break between related procs (like overloads) and one blank between unrelated ones |
| 20:56:39 | Demos | I put in soemthing like #{{{ comment about the next batch of procs for some stuff as well |
| 20:56:44 | Varriount | dom96: I open up selectors.nim and get "TODO: Docs" |
| 20:57:02 | fowl | lol |
| 20:57:02 | Varriount | :3 |
| 20:57:09 | fowl | TODOC |
| 20:57:25 | dom96 | You likely wouldn't want to use selectors anyway :P |
| 20:58:47 | Varriount | Hm. Supposedly the best and most simple way to have non-blocking file changes on windows is to use ReadDirectoryChangesW and IO completion ports. |
| 21:01:29 | * | [2]Endy quit (Ping timeout: 264 seconds) |
| 21:01:41 | dom96 | of course |
| 21:02:10 | * | menscrem quit (Quit: Page closed) |
| 21:02:44 | Varriount | dom96: Does that ayncio and await stuff handle the actual backend stuff, like IOCP, kqueue, etc, or is that left up to the implementation? |
| 21:02:52 | Varriount | *other implementations |
| 21:03:15 | Varriount | Sorry for the questions. Right now I'm trying to figure out how everything is going to fit together. |
| 21:03:23 | dom96 | you will have to worry about it when implementing fsmonitor |
| 21:03:37 | dom96 | but it's transparent as far as the user is concerned |
| 21:04:04 | dom96 | The selectors module implements epoll + select (and will implement kqueue) |
| 21:04:27 | dom96 | the asyncdispatcher then builds on top of that |
| 21:04:38 | dom96 | except on Windows where it uses IOCP |
| 21:07:37 | Varriount | dom96: If fsmonitor on windows is going to use IOCP, I'm going to need some way to get the current IO completion port that may be in use. |
| 21:07:47 | Varriount | There can only be one IOCP per thread. |
| 21:08:24 | dom96 | there is a getGlobalDispatcher proc |
| 21:08:30 | Varriount | Unless of course, worker threads are created for the file monitors.. |
| 21:09:18 | dom96 | you'll need to export some fields I guess |
| 21:09:39 | dom96 | well, actually. You should use 'register' |
| 21:13:32 | dom96 | and export verifyPresence and use it |
| 21:41:24 | OrionPK | hullo boys |
| 21:41:51 | dom96 | konichiwa |
| 21:43:49 | Varriount | dom96: Any ideas on porting fixes that would appease both Araq and you? |
| 21:44:30 | * | BitPuffin quit (Ping timeout: 276 seconds) |
| 21:44:43 | dom96 | Varriount: nope |
| 21:44:59 | Araq | hi Varriount |
| 21:45:05 | Varriount | Hi Araq |
| 21:45:17 | Araq | help micklat with his high level python wrappers |
| 21:45:37 | Varriount | Um.. ok... *looks at dom96* |
| 21:46:16 | Varriount | Araq: What about fsmonitor support for windows? |
| 21:46:38 | dom96 | Varriount: Maybe I misunderstood your question |
| 21:46:51 | dom96 | are you asking what fixes to port to 0.9.4? |
| 21:47:25 | Varriount | dom96: No, I'm asking about the porting technique. The current plan is to git cherrypick fixes from devel to master, which you seemed unhappy about. |
| 21:48:05 | dom96 | oh, well it's still a nope |
| 21:48:09 | dom96 | I haven't done any research into it |
| 21:50:44 | EXetoC | are there no decent libs that allow you to spend less time gluing platform-specific stuff together (polling stuff and what have you)? |
| 21:51:26 | Varriount | EXetoC: You mean, for the stdlib? |
| 21:53:40 | * | cark joined #nimrod |
| 21:53:58 | EXetoC | yes but from the point of view of a core dev. you've already taken care of a lot of this painful stuff :-) |
| 21:55:28 | Varriount | EXetoC: If you're talking about file change monitoring, the problem is that, at least on Windows, there are about 8 different ways to do it, because of the various API combinations that you can use. |
| 21:56:04 | Varriount | Also, we haven't actually taken care of file monitoring yet. |
| 21:56:48 | * | Jesin quit (Ping timeout: 240 seconds) |
| 21:56:49 | Varriount | I mean, I *just* got file information retrieval finished, which should be a boon for the standard library in the future. |
| 21:57:00 | * | cark quit (Read error: Connection reset by peer) |
| 21:58:14 | OrionPK | cant wait to port my stuff over to the new asyncio module ;) |
| 21:58:41 | * | petrus joined #nimrod |
| 21:59:04 | * | cark joined #nimrod |
| 22:00:08 | EXetoC | Varriount: so then it's a matter of finding some lib that uses the best approach, but that's easier said than done I guess |
| 22:01:24 | dom96 | hi petrus |
| 22:03:03 | EXetoC | are there any good ways to find out? a well-categorized lib database perhaps |
| 22:04:58 | Araq | hi petrus welcome |
| 22:08:38 | petrus | Hello, I am just lurking here while I am reading about nimrod. |
| 22:12:34 | * | Jesin joined #nimrod |
| 22:14:47 | * | io2 quit () |
| 22:15:19 | dom96 | petrus: No worries, let us know if you have any questions :) |
| 22:17:47 | dom96 | Varriount: Surely there aren't that many combos? |
| 22:19:53 | petrus | Thanks. I've just finished the Dr Dobb's article on nimrod. I am impressed. |
| 22:20:46 | EXetoC | Varriount: I'm just looking around. I've found this so far http://www.pjsip.org/pjlib/docs/html/ |
| 22:26:59 | * | BitPuffin joined #nimrod |
| 22:36:59 | * | petrus quit (Quit: WeeChat 0.4.3) |
| 22:39:12 | * | Jesin quit (Ping timeout: 240 seconds) |
| 22:48:04 | Varriount | EXetoC: http://qualapps.blogspot.com/2010/05/understanding-readdirectorychangesw.html |
| 22:50:19 | EXetoC | Varriount: lovely |
| 22:51:37 | Varriount | EXetoC: And of course, I have to abstract an interface and somehow get it to work with await and async stuff. |
| 22:53:29 | * | milosn_ joined #nimrod |
| 22:54:24 | * | milosn quit (Ping timeout: 240 seconds) |
| 22:54:51 | Varriount | Hi milosn_, make any progress on that app? |
| 22:56:46 | * | Jesin joined #nimrod |
| 23:03:43 | * | cark quit (Read error: Connection reset by peer) |
| 23:04:25 | * | Jesin quit (Ping timeout: 252 seconds) |
| 23:08:42 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 23:13:35 | Skrylar | its in my usual erratic style, but here is a thing: https://github.com/Skrylar/skTypeface |
| 23:13:49 | Skrylar | i should get in the habit of putting zlib licenses on those repos actually :/ |
| 23:20:30 | Demos | does the typeface stuff /really/ need to be a GC'd ref |
| 23:22:39 | Demos | can c2nim deal with "inline" without being in cpp mode? |
| 23:23:13 | Demos | and is {.inline.} a hint or a command? |
| 23:25:31 | Varriount | Demos: A hint. |
| 23:25:46 | EXetoC | the manual says that |
| 23:26:49 | * | uvelichitel quit (Quit: Textual IRC Client: www.textualapp.com) |
| 23:28:16 | Demos | thanks, I am a lazy man |
| 23:29:12 | Demos | I am c2nimming stb-image, a 200MB image loading library is too much for me |
| 23:29:20 | Varriount | Skrylar: Doesn't Github allow you to pick a license on repository creation? |
| 23:29:50 | Demos | Varriount: sure, but you still need to license each file individually and make sure the babel stuff is in order |
| 23:29:56 | Varriount | Demos: You know that we have wrappers for DevIL and Freeimage, right? |
| 23:30:12 | Demos | I am using freeimage now |
| 23:30:22 | Demos | look at the author on that wrapper :D |
| 23:30:55 | Demos | stb is a good library and it means totally eliminateing a native dep |
| 23:31:12 | Varriount | And DevIL? |
| 23:31:31 | Demos | not maintained. And I dont really like the opengl style API |
| 23:32:48 | * | darkf joined #nimrod |
| 23:33:58 | EXetoC | translations aren't perfect, but hopefully you'll get it to work |
| 23:34:23 | Demos | it is written in fairly standard C |
| 23:34:45 | Skrylar | Demos: do you have a better way :( |
| 23:34:51 | Demos | than what? |
| 23:34:59 | BitPuffin | Demos: pretty sure devil is maintained |
| 23:34:59 | Skrylar | I use a GC ref because i use methods |
| 23:35:17 | BitPuffin | Varriount: hint: allegro |
| 23:35:20 | BitPuffin | it has it all :D |
| 23:35:33 | Demos | dont use methods, once you figure the platform you know all the functions to call |
| 23:35:44 | Skrylar | Demos: if you have a better idea i'll listen, my points of contention is that the typeface system is not set in stone |
| 23:35:50 | EXetoC | note the remark about deps |
| 23:35:51 | Skrylar | nothing *stops* you from having both GDI and FreeType |
| 23:36:39 | Skrylar | I pondered about having the default typesystem be typedef'd in to existence instead of ref'd |
| 23:37:00 | Skrylar | then de-method the typeface code |
| 23:37:12 | Demos | BitPuffin: I dont want everything, although replaceing cairo with something not autotools based is appealing |
| 23:37:15 | Skrylar | but then if you use gdi and freetype fonts, you have to ferry along both :/ |
| 23:37:28 | Demos | but I /really/ like cairo as a library |
| 23:37:34 | Demos | the build system is just annoying |
| 23:37:36 | Skrylar | does cairo not have a cmake file? |
| 23:37:44 | Demos | nope |
| 23:37:46 | BitPuffin | Demos: well okay it doesn't have *everything* |
| 23:37:53 | BitPuffin | Demos: but it has just the stuff you need |
| 23:37:59 | BitPuffin | and nothing more |
| 23:38:04 | BitPuffin | dat sweetspot |
| 23:39:15 | Varriount | Demos: Well, I guess the more image loading libraries, the merrier. |
| 23:39:39 | Varriount | Although, that reminds me, how would one go about using a JIT compiler in Nimrod? |
| 23:40:26 | Demos | does it have masking and compositing ops? |
| 23:40:36 | Demos | what about support for OpenGL 4 |
| 23:41:30 | BitPuffin | Demos: it supports whatever opengl version you can load afaik |
| 23:41:36 | BitPuffin | on your system |
| 23:46:45 | BitPuffin | Demos: compositing I dunno haven't tried using it for that |
| 23:46:54 | Demos | did we ever get an align pragma |
| 23:47:24 | BitPuffin | and it depends on what you mean by compositing I guess, do you mean 3d compositing that you do with deferred rendering or just ilke drawing 2d stuff blended or whatever |
| 23:47:49 | BitPuffin | I assume you mean multiply and add etc |
| 23:47:56 | BitPuffin | and blend and so on |
| 23:48:32 | BitPuffin | http://alleg.sourceforge.net/a5docs/refman/graphics.html#blending-modes |
| 23:49:19 | Demos | right but those set the GPU hardware to the given operator, not nessassarly what I want |
| 23:49:24 | Demos | anywant I like cairo |
| 23:51:54 | BitPuffin | Demos: well I'm not saying that you have to use it |
| 23:52:00 | BitPuffin | Demos: just that I will kill you otherwise |
| 23:52:03 | BitPuffin | no I'm just kidding xD |
| 23:56:28 | Demos | does each item in a "case" statement start a new scope |
| 23:56:31 | Demos | unlike c? |
| 23:58:52 | * | Jesin joined #nimrod |