| 00:00:02 | OrionPK | that'd be interesting |
| 00:00:18 | OrionPK | also if you add an integrated debugger I would use the shit out of it :p |
| 00:00:28 | * | Varriount puts his Critiquing Glasses on, and opens up asyncio2.nim |
| 00:00:51 | dom96 | Aporia2 will probably be proprietary then :P |
| 00:00:51 | Varriount | >:D |
| 00:01:12 | * | dom96 readies his fork for stabbing Varriount |
| 00:01:50 | Varriount | I thought we were getting rid of the type prefixes? |
| 00:02:13 | dom96 | Yeah, but that hasn't happened yet. |
| 00:02:43 | * | darkf joined #nimrod |
| 00:04:09 | dom96 | There is still so much to do :\ |
| 00:04:38 | EXetoC | bacon |
| 00:18:55 | Matthias247 | Varriount, OrionPK: I added a link to the plugin there, so that the next person doesn't take the wrong one :) https://github.com/Araq/Nimrod/wiki/Editor-Support |
| 00:20:12 | * | darkf_ joined #nimrod |
| 00:20:43 | * | brson quit (Ping timeout: 260 seconds) |
| 00:20:46 | * | darkf quit (Disconnected by services) |
| 00:20:48 | * | darkf_ is now known as darkf |
| 00:20:58 | OrionPK | cool |
| 00:20:59 | OrionPK | afk |
| 00:21:15 | Matthias247 | gn8 |
| 00:21:20 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:21:28 | OrionPK | u german? |
| 00:24:36 | Varriount | dom96: On a serious note, are you open to suggestions for the new asyncio stuff? |
| 00:25:08 | Varriount | I've only read a bit, and the code looks very well written, however there are some things that could be optimized/commented upon |
| 00:25:14 | dom96 | Varriount: Sure. |
| 00:25:30 | dom96 | I'm mostly too tired to code now so I feel like discussing things. |
| 00:25:38 | Varriount | Same here |
| 00:26:00 | Varriount | dom96: Really though, I'm really impressed at the amount of work you put into this stuff. |
| 00:26:20 | Varriount | I'm too indecisive when it comes to API building :P |
| 00:26:42 | dom96 | thanks :) |
| 00:27:21 | dom96 | I still haven't decided myself if I like everything the way it is. |
| 00:27:44 | Varriount | Are there any plans to seperate the futures aspect of asyncio into another module? |
| 00:27:48 | dom96 | Relying on macros seems risky. I found 3 already. |
| 00:27:55 | dom96 | *3 issues |
| 00:28:14 | Varriount | (I don't know if that's feasable, I"m just throwing the idea out there) |
| 00:28:30 | dom96 | Sure, it's feasible. Haven't thought about it much yet though. |
| 00:28:45 | dom96 | Araq will be creating his own future-like type. |
| 00:29:02 | dom96 | I would like the two to be unified but it doesn't seem that will be possible. |
| 00:30:08 | Varriount | Or at least, not possible given the time-frame |
| 00:30:11 | NimBot | nimrod-code/nimbuild master d91e022 Dominik Picheta [+0 ±1 -0]: Test results diff is now gisted and the URL of the gist is announced. |
| 00:31:59 | NimBot | dom96/jester master 79862b6 Dominik Picheta [+0 ±1 -0]: Fixes compilation problems when SSL is enabled. |
| 00:35:02 | NimBot | nimrod-code/nimbuild master 9d5ff33 Dominik Picheta [+1 ±0 -0]: Added website.nimrod.cfg |
| 00:43:07 | NimBot | dom96/jester master 23eff32 Dominik Picheta [+0 ±1 -0]: Fixes compilation problems when ssl is enabled properly. |
| 00:50:54 | dom96 | Varriount: Any other feedback? |
| 00:52:54 | Varriount | dom96: Hm. Mostly stylistic stuff. |
| 00:55:18 | dom96 | well, in that case I may as well watch Top Gear. |
| 00:55:44 | Varriount | dom96: I feel that the windows api tradition of using long argument names is something that should be avoided |
| 00:56:00 | * | ddl_smurf_ joined #nimrod |
| 00:56:27 | Varriount | Also, why cast the windows connectEx pointer to a procedure every time connectEx is called? |
| 00:58:59 | * | ddl_smurf quit (Ping timeout: 272 seconds) |
| 00:58:59 | * | ddl_smurf_ is now known as ddl_smurf |
| 00:59:02 | * | brson joined #nimrod |
| 01:00:52 | dom96 | I don't think that has any effect on performance. |
| 01:01:44 | Varriount | It's also an eyesore. |
| 01:04:17 | NimBot | Araq/Nimrod devel 7ef6aae Zahary Karadjov [+0 ±1 -0]: fix argument_parser |
| 01:04:17 | NimBot | Araq/Nimrod devel 9df7b1c Zahary Karadjov [+1 ±2 -0]: fix #188 |
| 01:04:17 | NimBot | Araq/Nimrod devel 4510eb9 Zahary Karadjov [+2 ±31 -0]: Merge branch 'devel' of gh:/Araq/Nimrod into devel |
| 01:04:17 | NimBot | Araq/Nimrod devel 8a87ba3 Zahary Karadjov [+1 ±8 -0]: quite messy implementation of generic lambdas, needs reworking; fixes #715 |
| 01:05:10 | * | Varriount wonders how zahary is going to allow generic lambdas to be passed around. |
| 01:06:59 | zahary | it should be called inferred lambdas really |
| 01:07:14 | zahary | the generic types in the signature are figured out by the compiler |
| 01:09:29 | zahary | if we allow lambdas to be passed to object accepting procs (as it is in C++) then it's also possible to not collapse the lambda to a unified run-time type and to have "real" generic lambdas |
| 01:17:48 | * | carum joined #nimrod |
| 01:25:57 | * | zahary quit (Quit: Leaving.) |
| 01:37:09 | * | brson_ joined #nimrod |
| 01:37:27 | * | brson quit (Ping timeout: 265 seconds) |
| 01:44:35 | renesac | Error: type mismatch: got (int literal(0), uint32) but expected one of: [...] unsigned.<=(x: T, y: T): bool |
| 01:44:38 | renesac | :/ |
| 01:45:16 | renesac | uints are almost unusable... |
| 01:46:55 | EXetoC | not really. use a uint32 literal (0u32) |
| 01:47:18 | renesac | not happening if my code is supposed to be generic |
| 01:47:39 | * | carum quit (Remote host closed the connection) |
| 01:47:51 | * | carum joined #nimrod |
| 01:47:54 | * | carum quit (Remote host closed the connection) |
| 01:48:06 | renesac | ok, aparently I can do "0.T" |
| 01:48:07 | * | carum joined #nimrod |
| 01:49:33 | renesac | maybe I should report those bugs... |
| 01:52:38 | EXetoC | bugs? I don't know |
| 01:52:59 | EXetoC | I guess you'll find out if you report it |
| 01:53:26 | renesac | a literal 0 should be converted to uint32 in this situation, acording do the manual |
| 02:01:53 | EXetoC | I can't even test that as I get "Error: ordinal type expected" |
| 02:02:43 | EXetoC | but it's the fact that the procs are generic that causes a problem I think. I'll ask Araq about that tomorrow, because I have some relevant patches |
| 02:06:06 | renesac | uint32 is an ordinal type IIRC |
| 02:06:29 | renesac | at least on 64bit nimrod |
| 02:07:03 | dom96 | No, IIRC only signed ints are ordinal. |
| 02:08:49 | EXetoC | Araq: so my float patches worked? maybe I missed what you told me to do. I'll try with devel |
| 02:11:20 | EXetoC | this seems relevant, so it's too bad I get that error message. will try again tomorrow |
| 02:11:27 | EXetoC | bye |
| 02:12:37 | renesac | TOrdinal* = int|int8|int16|int32|int64|bool|enum|uint8|uint16|uint32 |
| 02:12:44 | renesac | from system.nim |
| 02:13:35 | renesac | the only problem is uint64 (and thus, maybe uint), because uint64.high > int64.high |
| 02:13:53 | EXetoC | it fails for me with any unsigned type |
| 02:14:28 | EXetoC | I don't think TOrdinal is relevant, but the type class in unsigned might. bug? I guess so |
| 02:16:02 | renesac | another thing that don't work: "let x:byte = 1; let y:int = 1 + x" |
| 02:16:10 | renesac | and should |
| 02:17:29 | renesac | this I already reported here, but haven't created a issue yet (I tried to fix it myself, but failed because I couldn't define the priority of the conversions) |
| 02:17:55 | * | vendethiel quit (Quit: q+) |
| 02:19:03 | renesac | the compiler become confused between calling a function for int64 or uint64 when receiving a uint8 argument |
| 02:19:13 | renesac | as uint8 could now be converted to both |
| 02:19:37 | EXetoC | isn't the manual referring to simpler cases only? "let x: int8 = 1" for example |
| 02:20:07 | renesac | "In Nimrod only widening type conversion are implicit:" |
| 02:20:19 | renesac | those are widening type conversions |
| 02:20:37 | renesac | "Automatic type conversion is performed in expressions where different kinds of integer types are used: the smaller type is converted to the larger." |
| 02:21:45 | EXetoC | anyway, it's problematic if the language doesn't handle this in a special way, since the operators are procs |
| 02:23:04 | renesac | well, this should be treated at the same place that treats int16 to convert to int when needed |
| 02:23:17 | renesac | that works now |
| 02:23:20 | * | carum quit (Remote host closed the connection) |
| 02:27:18 | EXetoC | echo(5000i8) > 5000 |
| 02:29:41 | EXetoC | "5000i8.type is typedesc[int8]" > true |
| 02:30:06 | renesac | oh, I thought your first line was a comparison |
| 02:30:43 | EXetoC | I don't know what's going on |
| 02:31:03 | renesac | lol |
| 02:31:20 | renesac | the native type zoo is all broken |
| 02:32:10 | renesac | let x = 5000u8 |
| 02:32:10 | renesac | echo (x) #> 136 |
| 02:32:38 | renesac | ideally, the compiler should forbid this declaration as out of range |
| 02:33:11 | EXetoC | that's still 5000 for me. are you on devel? |
| 02:33:16 | renesac | yes |
| 02:33:31 | renesac | but I got 5000 when I echoed directly |
| 02:33:56 | EXetoC | ah, yes |
| 02:36:34 | EXetoC | something must've gone horribly wrong not long ago, but this is the devel branch after all |
| 02:39:11 | renesac | you are gonna open a issue? |
| 02:42:58 | * | carum joined #nimrod |
| 02:43:01 | EXetoC | I might, tomorrow |
| 02:46:50 | EXetoC | where are the failing tests? |
| 02:47:08 | EXetoC | perhaps a PR that adds a couple of those might be good enough |
| 02:48:15 | EXetoC | I mean, tests that are expected to fail |
| 02:50:40 | EXetoC | nevermind |
| 03:23:39 | * | dmac quit (Ping timeout: 260 seconds) |
| 03:23:45 | Varriount | We just need an int128 :/ |
| 03:24:23 | * | dmac joined #nimrod |
| 03:28:00 | * | carum quit (Remote host closed the connection) |
| 03:28:48 | * | carum joined #nimrod |
| 03:33:33 | * | carum quit (Client Quit) |
| 03:36:48 | * | aftershave_ joined #nimrod |
| 03:52:34 | * | aftershave_ quit (Quit: Computer has gone to sleep.) |
| 04:01:51 | renesac | Varriount, this only solves the uint/uint64 ordinal issue, and an int65 is sufficient for that |
| 04:02:31 | renesac | or a float128 that is more useful for other things, or a bigint |
| 04:44:53 | renesac | wow, this is bizarre: Error: ambiguous call; both system.-=(x: var T, y: T) and system.-=(x: var T, y: T) match for: (int literal(32), int literal(1)) |
| 04:47:14 | renesac | let me recompile my compiler... |
| 04:53:11 | renesac | same error, I will try to make a minimum working example |
| 04:54:02 | renesac | ohh, it was because I was trying to operate on a const |
| 04:54:36 | renesac | a less WTF-inducing error would be welcome... |
| 05:05:29 | * | carum joined #nimrod |
| 05:11:13 | Varriount | renesac: It might seem surprising, but giving good error messages can be tricky |
| 05:11:45 | Varriount | Mainly because, when the compiler does come across an error, there could be many things that are the cause. |
| 05:12:26 | renesac | yeah, I understand |
| 05:12:49 | renesac | but I wanted to understand how the compiler come up with that error message above |
| 05:12:50 | renesac | XD |
| 05:23:14 | * | carum quit (Remote host closed the connection) |
| 05:25:26 | Varriount | renesac: You want bizarre, try making macros |
| 05:25:50 | Varriount | renesac: Like this -> https://gist.github.com/Varriount/9045180 |
| 05:27:14 | renesac | I can't compile that code here |
| 05:27:33 | renesac | but yeah... I imagine that macros may give weirder messages |
| 05:27:58 | renesac | I'm more afraid if using macros can be that hard too |
| 05:28:57 | renesac | this is often an argument against allowing macros in a language... |
| 05:29:25 | Varriount | renesac: But they allow a high degree of flexibility |
| 05:29:41 | renesac | yeah, w/o doubt |
| 05:29:45 | Varriount | renesac: It generates 3 procs given the definition of one proc |
| 05:31:29 | renesac | I'm starring at a quite redundant case statement, but I think only a macro could remove that redundancy w/o impacting the performance |
| 05:33:14 | renesac | and that is not a good idea, of course |
| 05:37:02 | Varriount | renesac: Oddly enough, most of the macro I pasted is simply replacing types, and converting them |
| 05:37:18 | Varriount | The problem is that there's quite a bit of corner cases |
| 05:37:34 | Varriount | renesac: Are you sure you need the optimization? |
| 05:38:41 | renesac | well, it is for math.nim |
| 05:39:01 | renesac | https://gist.github.com/ReneSac/cdac881c6fbd3920d653 <-- here |
| 05:39:12 | renesac | araq would tell me to forget unsigned ints, of course |
| 05:39:15 | renesac | XD |
| 05:40:16 | Varriount | Unfortunately, as much as he may hate them, unsigned ints are just going to happen. |
| 05:41:19 | Varriount | renesac: I'm fairly sure the compiler could probably optimize something |
| 05:42:37 | Varriount | renesac: I myself am debating whether I should slash half of the logic in the macro I posted, and just make users use conversion templates :/ |
| 05:44:45 | renesac | like joining two `case` statements one following another? |
| 05:45:08 | Varriount | renesac: You would be amazed at the optimizations compilers make. |
| 05:45:46 | renesac | yeah, but sometimes they can't prove things that are obvious to the programmer, and then can't optimize |
| 05:46:43 | renesac | and I don't think they would optimize a series of `if`into a `case` |
| 05:46:45 | Varriount | renesac: Where exactly is the inefficient code? |
| 05:47:03 | renesac | ? |
| 05:47:26 | Varriount | renesac: In that snippet, what's inefficient? |
| 05:47:36 | renesac | nothing, only the code size |
| 05:47:58 | renesac | lots of repetitions |
| 05:48:32 | renesac | I will have to break up this case statement to reduce the redundancy |
| 05:48:32 | Varriount | Well, you could use a template, which is no-where near as complicated as a macro. |
| 05:49:00 | renesac | a template can mess inside a 'case'? |
| 05:49:15 | renesac | I couldn't think about a way to use template |
| 05:49:17 | renesac | in this case |
| 05:49:27 | renesac | pun not intended... |
| 05:53:40 | * | carum joined #nimrod |
| 05:58:23 | Varriount | Hi carum |
| 05:58:40 | renesac | and I can put "return" inside a template? |
| 05:58:54 | renesac | for the function calling the template return? |
| 05:58:54 | carum | 'lo |
| 05:59:14 | Varriount | renesac: Yes, but the return will work in the calling procedure, not the template |
| 05:59:24 | renesac | right |
| 06:00:02 | renesac | well, tomorrow I will try to build a template then |
| 06:00:25 | renesac | repeating 6 times the same line of code isn't pretty |
| 06:01:15 | renesac | (4 times if I divide the case statement in two) |
| 06:02:19 | renesac | good night |
| 06:02:25 | * | renesac is now known as renesac|away |
| 06:04:28 | * | carum quit (Remote host closed the connection) |
| 06:05:38 | * | isenmann joined #nimrod |
| 06:05:44 | * | carum joined #nimrod |
| 06:14:51 | * | brson_ quit (Ping timeout: 245 seconds) |
| 06:15:35 | * | brson joined #nimrod |
| 06:26:43 | * | vbtt joined #nimrod |
| 06:35:02 | vbtt | hello |
| 06:35:26 | vbtt | dom96 you around? |
| 06:37:11 | vbtt | btw, I read the article Araq posted: http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/ |
| 06:41:20 | vbtt | was not convincing. the basic argument seems to be "you don't know which function will call yield" - this is bogus. |
| 06:41:53 | vbtt | you do know which functions can call yield. and even if you don't it's easily fixed by a no_yield wrapper of some sort. |
| 06:42:24 | vbtt | why would anyone want to live in callback hell is beyond me. coroutines enable much clearer code. |
| 06:46:09 | vbtt | having said that, I admit what nimrod has - isolated heap threads with asyncio - is superior to shared heap coroutines in golang. |
| 06:46:15 | vbtt | *far superior. |
| 06:47:38 | vbtt | The only reason I'm looking for full coroutines is because it allows me to run fewer threads to utilize all cpus effectively. |
| 06:54:58 | vbtt | today to handle multiple requests, I could spin up a large number of threads (e.g. 40 threads on a 4-cpu box) |
| 06:55:06 | vbtt | then each thread sleeps when waiting for io. |
| 06:55:59 | vbtt | with full coroutines, I only spin up 4 threads, one for each cpu. and when doing io, only the coroutine handling the request sleeps, while the thread can run another coroutine. |
| 06:56:22 | vbtt | the latter system scales better (i.e not upper bound on number of in-flight requests) |
| 06:58:27 | Varriount | vbtt: I'm around :3 |
| 06:58:30 | vbtt | anyway, isolated heaps are really good. so is manual gc invocation. |
| 06:58:34 | vbtt | hi Varriount |
| 06:58:51 | vbtt | i just wanted to talk to dom96 about asyncio. |
| 06:59:00 | Varriount | vbtt: I was under the impression that coroutines worked in a single thread. |
| 06:59:02 | vbtt | but glad to know someone is listening. |
| 06:59:21 | vbtt | Varriount:correct - but you can have multiple threads, each with multiple coroutines. |
| 06:59:40 | Varriount | Oh, I see |
| 07:00:34 | vbtt | not migration coroutines across threads is also a very good idea. |
| 07:01:20 | vbtt | it's good for both - avoiding race conditions as well as providing better control over latency. |
| 07:01:39 | Varriount | I'm assuming you meant 'now' instead of 'not' |
| 07:01:55 | vbtt | i meant not. |
| 07:02:11 | vbtt | we don't want a coroutine to jump from one thread to another. |
| 07:02:22 | Varriount | Ah, yes |
| 07:02:31 | vbtt | firstly, threads have isolated heap so not sure how feasible that is anyway. |
| 07:02:44 | vbtt | but also - it ensures that only one coroutine is mutating the shared state. |
| 07:02:57 | vbtt | so two threads are never mutating the same shared state. |
| 07:03:53 | Varriount | vbtt: If you want to review something, you can look over dom96's new asyncio code |
| 07:05:25 | vbtt | Varriount:do you know where it is? in devel? |
| 07:05:44 | Varriount | vbtt: Yes. Oh, but I need your opinion on something first |
| 07:06:32 | Varriount | So, I'm currently developing a macro for winlean.nim, that generates 3 wrapper procedures out of one wrapper procedure |
| 07:07:25 | vbtt | ok |
| 07:07:59 | Varriount | The macro generates 2 procedures that directly wrap a windows api call, and adjusts the names and parameter types to wrap either the ansi or unicode version of the call |
| 07:08:29 | Varriount | The differences between these 2 procedures is name only - GetEnvironmentA and GetEnvironment |
| 07:08:41 | Varriount | The thrid procedure is special though |
| 07:09:19 | Varriount | When built using unicode API's, the macro generates a third procedure that automatically converts strings to wide strings |
| 07:10:24 | Varriount | About half of the code in my macro is dedicated to generating this procedure |
| 07:11:04 | Varriount | The question I ask is this: should I remove the generation of this conversion procedure, and replace it with conversion operators? |
| 07:11:26 | Varriount | Operators that convert a string to a wide string if the unicode api is selected |
| 07:12:28 | vbtt | the third procedure calls one of the other two, i hope? |
| 07:12:51 | Varriount | Yes |
| 07:13:20 | Varriount | Here's the winlean code, with the macro -> https://gist.github.com/Varriount/9045180 |
| 07:14:45 | vbtt | so if i understand correctly, you generate f() that takes wide string and fx() that takes strings, converts then and then calls f() |
| 07:14:54 | Varriount | Yes. |
| 07:15:32 | Varriount | The alternative is creating some conversion procedure, say, toWinString(s: string): WinString |
| 07:15:42 | vbtt | right |
| 07:16:15 | vbtt | well if nimrod mostly uses strings, it is best to make it easy to pass strings to the functions. |
| 07:16:56 | vbtt | is there a way to do auto conversion in nimrod? |
| 07:17:31 | Varriount | vbtt: Well, aside from the macro I made, there are converter procs, however they are applied globally |
| 07:18:25 | vbtt | ideally there would be just one function that accepts both strings or wide-strings. |
| 07:18:34 | vbtt | and does the conversion as appropriate. |
| 07:18:37 | vbtt | not sure if that's possible. |
| 07:19:00 | Varriount | vbtt: Not without a much more complicated macro, or a converter. |
| 07:19:07 | vbtt | the problem is return values too - if a function returns a wide string, now do you need another version to return strings? |
| 07:19:41 | Varriount | Araq doesn't like the idea of using a converter, I know that much. |
| 07:20:01 | vbtt | you mean conversion operator? |
| 07:20:15 | Varriount | No, a converter procedure |
| 07:20:22 | vbtt | it's a pain to always type the conversion operator everywhere. |
| 07:20:47 | * | skyfex quit (Quit: Computer has gone to sleep.) |
| 07:21:12 | vbtt | yeah i definitely don't like a conversion procedure - it's even more of a pain to use it everywhere. |
| 07:21:24 | Varriount | http://nimrod-lang.org/manual.html#convertible-relation |
| 07:22:06 | Varriount | Look at the code block before assignment compatibility |
| 07:23:20 | vbtt | in this case, i like implicit conversion if it's doable. |
| 07:23:35 | * | gour joined #nimrod |
| 07:23:53 | vbtt | because, it's precisely what the programmer wants (i.e. you won't get any accidental bugs) and makes his life easier by not explicitly doing conversions back and forth. |
| 07:25:06 | Varriount | vbtt: Thanks for your input. Sorry for taking up your time. |
| 07:25:06 | vbtt | if you implement toWinString, will it have to be called explicitly? |
| 07:25:24 | vbtt | glad to offer feedback. |
| 07:25:38 | Varriount | Yes, it would have to be caled explicitly |
| 07:26:27 | Varriount | versus the macro generated proc that converts its string args to wide strings |
| 07:26:37 | Varriount | Anyway, I have to get to bed. Goodnight |
| 07:26:44 | vbtt | ok, good night. |
| 07:27:21 | vbtt | in summary i think implicit-conversion is better than multiple-function-definitions is better than explicit-conversion |
| 07:41:38 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 07:43:25 | * | runvnc joined #nimrod |
| 07:43:37 | runvnc | hello |
| 07:44:33 | runvnc | is there a way to get jester to work asynchronously, like if I put a sleep(5) in a route and call it 5 times concurrently, I want them to all come back in 5 seconds, not 25 |
| 07:44:40 | runvnc | is there an example of how to do that |
| 07:45:04 | runvnc | jester is very awesome other than that |
| 07:47:15 | runvnc | or maybe I should use nits or the build in http server |
| 07:47:56 | runvnc | built in |
| 07:48:29 | runvnc | I'm going to do a test with httpserver |
| 07:57:05 | runvnc | hm. maybe if I just do io it wont block everything |
| 08:00:29 | * | carum quit (Remote host closed the connection) |
| 08:02:35 | vbtt | runvnc: sorry no idea. |
| 08:02:52 | runvnc | hey vbtt |
| 08:02:56 | vbtt | runvnc:perhaps asyncio has a sleep which doesn't call the system sleep so it doesn't block the whole thread. |
| 08:03:07 | vbtt | total speculation here. |
| 08:03:19 | runvnc | I am just wondering generally how people do web servers that need to handle multiple requests simultaneously |
| 08:03:49 | runvnc | if I do like a long http request instead of sleep inside of my tests, maybe it will be able to handle the requests at the same time right |
| 08:03:59 | runvnc | i will look in asyncio for that sleep |
| 08:04:05 | vbtt | runvnc: run multiple threads |
| 08:05:21 | runvnc | asyncio doesnt have a sleep. I dont actually need to sleep anyway |
| 08:05:32 | vbtt | runvnc:using asyncio you should also be able to handle multiple requests concurrently, but dom96 can confirm that. |
| 08:05:58 | runvnc | vbtt I have a feeling that the built in http server may be constructed on top of asyncio |
| 08:05:58 | vbtt | runvnc: i understand you're just simulating a long request using sleep() |
| 08:06:04 | runvnc | and perhaps also jester |
| 08:06:20 | vbtt | asyncio is new, not sure what the plan for the built in http server and jester is. |
| 08:06:22 | runvnc | so let me do another test using a long http client request in my handler rather than a sleep |
| 08:06:54 | vbtt | but dom96 wrote jester and also asyncio I believe. |
| 08:15:53 | runvnc | hm I found something in jester tests/asynctest.nim |
| 08:24:00 | * | dmac quit (Ping timeout: 265 seconds) |
| 08:25:33 | runvnc | ok so that didnt seem to make a difference |
| 08:25:39 | runvnc | trying threads like you said heh |
| 08:27:24 | vbtt | threads will work of course. |
| 08:27:41 | vbtt | keep a thread pool - that should work fine. |
| 08:27:52 | runvnc | is there a module for a thread pool |
| 08:27:56 | vbtt | not sure :/ |
| 08:28:02 | vbtt | i'm new to nimrod. |
| 08:32:27 | * | [Pete_27] quit (Remote host closed the connection) |
| 08:37:49 | vbtt | Araq:I got nimweb working. Had to tag on a --path:. at the end for it to work. |
| 08:48:45 | vbtt | Araq:sent you a PR with website updates. |
| 09:10:15 | * | zahary_ quit (Quit: ~ Trillian Astra - www.trillian.im ~) |
| 09:10:33 | * | zahary joined #nimrod |
| 09:20:58 | Araq | vbtt: thanks |
| 09:21:27 | * | skyfex joined #nimrod |
| 09:21:31 | Araq | vbtt: I came to the same conclusion btw. All that he's missing is a 'lock' statement for 'yield' :-) |
| 09:22:09 | vbtt | yeah, explicit yield is just not the same as preemptive threads. |
| 09:22:58 | vbtt | nimrod's effect system can perhaps be made to enforce no_yield function annotation. |
| 09:23:06 | vbtt | which means there is no overhead at runtime. |
| 09:23:44 | * | zahary_ joined #nimrod |
| 09:25:36 | * | skyfex quit (Ping timeout: 245 seconds) |
| 09:26:33 | zahary_ | runvnc, asyncio should have timers that are the async equivalent of sleep; maybe dom96 haven't added them yet, but they are certainly possible withing the new framework |
| 09:26:58 | runvnc | thanks zahary |
| 09:27:08 | runvnc | so say I needed to do an http get request |
| 09:27:16 | runvnc | inside of my handler |
| 09:27:43 | runvnc | so when somebody GETs /hello I go and download google.com or something |
| 09:27:46 | runvnc | and then send them that |
| 09:27:55 | runvnc | so if I want to have five of those going at the same time |
| 09:28:07 | runvnc | five requests coming in, five requests out to google |
| 09:28:11 | runvnc | simultaneously |
| 09:28:15 | runvnc | ? |
| 09:28:17 | runvnc | asyncio? |
| 09:28:26 | runvnc | is there an http get in asyncio |
| 09:28:45 | runvnc | I figured out mostly how to do this with threads |
| 09:29:21 | zahary_ | yes, asyncio is a good fit for that. I'm not sure what is available so far, but I can comment how it's supposed to work |
| 09:30:16 | * | gour quit (Quit: WeeChat 0.4.2) |
| 09:30:31 | zahary_ | if all 5 requests are triggered from the same client request, then you'll use an async get that returns a future object - you get 5 of these futures in parallel, then you wait for their "union" to complete. |
| 09:30:55 | runvnc | hm. in the asyncio module I did not see futures or http get |
| 09:31:07 | Araq | vbtt indeed the effect system works nicely here |
| 09:31:09 | runvnc | it says something about other modules implementing async stuff using asyncio |
| 09:31:29 | zahary_ | something like this. |
| 09:31:29 | zahary_ | var r1 = get("www.google.com") |
| 09:31:29 | zahary_ | var r2 = get("www.yahoo.com") |
| 09:31:29 | zahary_ | let (g, y) = await r1 & r2 |
| 09:31:47 | runvnc | zahary where is the documentation for these future http get and await |
| 09:31:53 | runvnc | or is that not implemented yet |
| 09:31:55 | zahary_ | if you don't want to fire multiple request from the same handler, then it's easier; you just await the single request |
| 09:32:07 | zahary_ | dom96 is currently actively working on this stuff |
| 09:32:17 | runvnc | can I actually use await |
| 09:32:20 | Araq | runvnc: jester supports async operations, ftp and sending via http are available, not sure about httpclient |
| 09:32:26 | vbtt | zahary_: can i do let g = await r1 | r2 # either r1 or r2 |
| 09:32:36 | Araq | this works today, what zahary_ describes is in development |
| 09:33:19 | * | CarpNet joined #nimrod |
| 09:34:19 | runvnc | sending via http meaning http post and wait for it to return, without blocking everything? |
| 09:34:26 | runvnc | is there an example of how to do that |
| 09:34:31 | zahary_ | vbtt, yes; but the syntax is going to be different, because r1 and r2 can possible return different things - you cannot collapse them to a single variable; look up GO's select statement for a hint of the required syntax |
| 09:34:58 | vbtt | ok |
| 09:36:06 | vbtt | zahary_: will I be able do a single select on multiple outgoing request, incoming connections, and timers ? |
| 09:36:58 | zahary_ | in theory it's possible, better ask dom96 about his implementation plans |
| 09:37:04 | Araq | runvnc: you could check out how nimbuild or the forum are implemented |
| 09:37:48 | runvnc | ok.. and those dont use threads then, but asyncio? thanks, I will look at them |
| 09:39:07 | Araq | nimbuild uses threads but only for control of external processes |
| 09:39:47 | runvnc | ok I will stop asking dumb questions now |
| 09:39:57 | runvnc | just one last question. is there a thread pool module |
| 09:40:11 | Araq | there is actors.nim but don't use it, it sucks |
| 09:40:24 | runvnc | the threads example has an array |
| 09:40:26 | runvnc | of threads |
| 09:40:41 | Araq | yeah, that's the way to go |
| 09:40:58 | runvnc | maybe I can recycle a thread at a certain index when it is done |
| 09:40:59 | runvnc | or something |
| 09:41:58 | runvnc | or I can push my request data into a queue that the threads read |
| 09:42:08 | runvnc | I do need to run external processes |
| 09:42:19 | runvnc | I will look aat nimbuild and the forum thank you |
| 09:43:19 | Araq | threads + TChannel works fine if you know their limitations |
| 09:43:48 | * | gour joined #nimrod |
| 09:57:30 | Araq | zielmicha-cloud_: you use 'noStackFrame' incorrectly and since nobody uses it correctly, I'll remove/rename this feature |
| 09:58:01 | Araq | we already had 1 hard to track down bug because of it |
| 10:08:47 | runvnc | https://github.com/nimrod-code/nimforum/blob/master/forum.nim it looks like basic jester stuff. so if 5 people do a /threadActivity.xml at the same time, does this somehow allow those requests to be served simultaneously? |
| 10:14:53 | Araq | runvnc: I think so, but ask dom96 when he's around |
| 10:15:09 | runvnc | ok thanks |
| 10:16:52 | * | vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 10:16:54 | * | io2 joined #nimrod |
| 10:23:34 | * | brson quit (Quit: leaving) |
| 11:08:15 | * | ddl_smurf quit (Read error: Connection reset by peer) |
| 11:13:55 | * | BitPuffin joined #nimrod |
| 11:18:22 | runvnc | doesnt seem to have any magic way to automatically put every route handler in some async thing or thread. does support scgi so maybe he set it up with multiple forum processes each listening on a different port and nginx doing a round-robin somehow |
| 11:18:41 | gour | BitPuffin: do you use nimrod on freebsd? |
| 11:19:19 | gour | BitPuffin: i mean any issue seeing that https://github.com/Araq/Nimrod/issues/620 is still open? |
| 11:19:24 | BitPuffin | gour: I did |
| 11:19:28 | BitPuffin | gour: but then it didn't work |
| 11:19:46 | gour | BitPuffin: i installed it yesterday, but did not have time to play much |
| 11:20:01 | gour | it's in ports now |
| 11:20:41 | BitPuffin | gour: Yeah okay |
| 11:20:53 | BitPuffin | gour: well I did try it in a vm not too many weeks ago and then it seemed to work |
| 11:22:17 | * | skyfex joined #nimrod |
| 11:22:35 | gour | otoh, considering lisp's influence on nimrod, i'd really be thanksful to hear Araq's (dis)likes of langs like dylan/julia |
| 11:26:39 | * | skyfex quit (Ping timeout: 260 seconds) |
| 11:51:30 | dom96 | runvnc: Async gets handled by the scgi module, I don't spawn multiple processes for the forum. |
| 11:51:51 | runvnc | dom ok I was trying to use it in scgi |
| 11:52:01 | runvnc | does scgi spawn multiple processes or threads or something? |
| 11:52:24 | dom96 | httpserver also implements an async interface but it's currently a bit broken |
| 11:52:40 | dom96 | runvnc: no, it all runs in a single thread. |
| 11:53:01 | runvnc | dom with the current scgi forum implementation, if two people try to pull a big thread, one of them will block and wait for the data to come out of the db and be formatted to html right? |
| 11:53:26 | dom96 | Yes, data from database is not pulled out asynchronously. |
| 11:54:00 | runvnc | I am trying to just use a regulat httpserver or jester with a thread, but in my handlerequest or route handler, the connection is always closed, even though it seems like I am able to pass my socket into the thread |
| 11:54:13 | runvnc | as soon as I get out of my handlerequest the socket is closed |
| 11:54:35 | runvnc | trying to make it a pointer or something because I think the socket is getting garbage collection or something |
| 11:55:51 | dom96 | handleRequest automatically closes the socket IIRC |
| 11:55:55 | runvnc | I am able to send in 5 requests to my server at the same time and they all download with http client in parallel, but it returns instantly |
| 11:56:00 | dom96 | Jester wasn't designed for threads. |
| 11:56:23 | runvnc | how can I make an httpserver with a thread with a handlerequest or equiv that doesnt close the socket immediately |
| 11:56:26 | BitPuffin | I know run arch as a server os instead lol |
| 11:56:29 | BitPuffin | now* |
| 11:58:57 | runvnc | does asynchttpserver also close the socket after the handlerequest |
| 11:59:06 | runvnc | maybe I can just use sockets or asyncio or something |
| 11:59:11 | dom96 | yes |
| 11:59:19 | dom96 | Why do you want threads so badly? |
| 11:59:31 | BitPuffin | dom96: webscale is the BOMB |
| 11:59:37 | runvnc | there are two things I want to happen in my route handlers or whatever |
| 11:59:56 | runvnc | one is to make a REST api call to a third party service |
| 12:00:00 | runvnc | or multiple services actually |
| 12:00:11 | runvnc | the other thing which may or may not happen before or after that api call |
| 12:00:20 | runvnc | is to do a shell exec and wait for the output |
| 12:00:35 | runvnc | I have it making threads and runnign my api call |
| 12:00:41 | runvnc | just closes the socket too soon |
| 12:00:53 | runvnc | so maybe I can use asyncio or regular sockets module |
| 12:06:05 | runvnc | dom96 if you have an idea of how I can do that without threads |
| 12:06:17 | runvnc | maybe I should use cgi or something |
| 12:12:59 | dom96 | I'm not sure how tbh. |
| 12:13:07 | dom96 | I guess you will need to hack jester. |
| 12:13:52 | dom96 | although hrm |
| 12:14:02 | runvnc | https://github.com/Araq/Nimrod/blob/devel/lib/pure/asyncio.nim |
| 12:14:10 | runvnc | at the end it has a testAcdept thing |
| 12:14:18 | runvnc | testAccept |
| 12:14:26 | runvnc | when mainmodule |
| 12:14:31 | runvnc | maybe I can copy that and change it |
| 12:14:56 | runvnc | and instead of testread I pass a pointer or reference or something to the pasyncsocket to my thread or something |
| 12:15:45 | dom96 | hrm? Are you planning on rewriting jester? |
| 12:15:57 | runvnc | no too lazy to rewrite jester to use asyncio |
| 12:15:59 | runvnc | and not smart enough |
| 12:16:05 | runvnc | I think I am gonna do what I just wrote above |
| 12:16:14 | dom96 | well I'm not sure what you mean |
| 12:16:16 | runvnc | I dont really have to have all of the nice routing and path and other stuff jester does |
| 12:16:25 | runvnc | maybe it wont work what I said |
| 12:16:36 | runvnc | do you see towards the bottom of that file where it says testaccept and testread |
| 12:16:37 | dom96 | ahh, so you will write your own jester-like module? |
| 12:16:50 | runvnc | I am going to import asyncio |
| 12:17:02 | runvnc | and then copy the stuff in whem mainmodule |
| 12:17:08 | runvnc | and edit testread to create a thread |
| 12:17:19 | runvnc | and pass the socket into it |
| 12:17:26 | runvnc | I think |
| 12:17:30 | Araq | gour: dylan is dead afaict and when I looked at it it used a Lisp-like data representation which sucks for systems programming. I can't comment on Julia. |
| 12:17:37 | runvnc | or maybe it will just send a message to an existing thread over a channel |
| 12:23:47 | * | awestroke joined #nimrod |
| 12:40:09 | NimBot | nimrod-code/nimbuild master 775dec3 Dominik Picheta [+0 ±1 -0]: Add extra newline to test results diff. |
| 12:42:24 | * | [Pete_27] joined #nimrod |
| 12:57:12 | gour | Araq: thank you. i see there is some endeavour to revive dylan...even to provide qt bindings soon. as far as julia, i believe you agree that it's reasonable to expect that nimrod's native code generator should produce better/quicker code than julia's jit? |
| 12:59:32 | Araq | should, but sometimes JITs are faster, I don't think LLVM's is particularly good though |
| 13:03:17 | gour | in any case, not much speed gain to be achieved with nimrod being already so fast |
| 13:10:58 | gour | Araq: is there some potential student to work on qt bindings for gsoc? |
| 13:11:46 | dom96 | gour: We still don't know if we've been accepted. |
| 13:11:50 | Araq | gour: I think not yet, but I'm much more concerned that we're not accepted for gsoc |
| 13:13:18 | gour | Araq: but it's not decided yet, right? decision is on 24th |
| 13:15:40 | dom96 | Yes. |
| 13:23:12 | * | skyfex joined #nimrod |
| 13:26:54 | Araq | hi skyfex |
| 13:27:12 | Araq | what's the status of the exception handling bugs? ;-) |
| 13:28:13 | * | skyfex quit (Ping timeout: 272 seconds) |
| 13:43:44 | gour | Araq: see http://article.gmane.org/gmane.comp.lang.julia.devel/13684 |
| 13:52:59 | Araq | gour: so? I can't say I disagree with the guy |
| 13:57:25 | gour | Araq: i am thinking about this part: "Static compilation will not change the execution speed." |
| 13:58:12 | Araq | gour: for Julia's design with its multi-methods everywhere that is quite likely |
| 13:58:33 | * | darkf quit (Quit: Leaving) |
| 13:59:08 | gour | Araq: ahh, that's interesting. thank you |
| 14:24:08 | * | brihat quit (Read error: Operation timed out) |
| 14:25:45 | * | brihat joined #nimrod |
| 15:23:59 | * | skyfex joined #nimrod |
| 15:28:06 | * | skyfex quit (Ping timeout: 245 seconds) |
| 15:43:00 | * | [1]Endy joined #nimrod |
| 16:33:44 | * | vendethiel joined #nimrod |
| 16:41:46 | EXetoC | I still don't like this whole float64 situation. it might make sense from an implementation standpoint, but only in this point and time, so I'm pretty sure that it's a source of confusion |
| 16:41:54 | EXetoC | was it an implementation issue that triggered this change? |
| 17:06:59 | Araq | EXetoC: the "float is currently float64 but its own type and the stdlib only cares about float but not about float64 or vice versa" was too confusing |
| 17:07:24 | Araq | so it was changed that float64 is an alias for float |
| 17:07:40 | Araq | bbl |
| 17:09:42 | * | skyfex joined #nimrod |
| 17:13:25 | * | Demos joined #nimrod |
| 17:17:15 | * | vendethiel quit (Quit: q+) |
| 17:18:24 | * | vbtt joined #nimrod |
| 17:18:45 | EXetoC | I didn't think it was confusing. I do think it is now though |
| 17:19:07 | EXetoC | did users actually claim it was confusing? if so, then I wonder if they had read that part of the manual |
| 17:23:37 | BitPuffin | dom96: hmm weird |
| 17:23:45 | BitPuffin | dom96: doesn't seem like redirect is working |
| 17:24:23 | BitPuffin | get "/": |
| 17:24:24 | BitPuffin | redirect("/redirected") |
| 17:24:36 | BitPuffin | redirect.nim(7, 2) Error: internal error: expr(skTemplate); unknown symbol |
| 17:24:37 | BitPuffin | No stack traceback available |
| 17:24:58 | dom96 | compiler bug |
| 17:25:05 | dom96 | it seems |
| 17:25:05 | BitPuffin | :/ |
| 17:26:51 | EXetoC | BitPuffin: what do you think about the current situation with float and float64? weren't you involved in the process? |
| 17:28:15 | dom96 | BitPuffin: You can just do what the template does manually as a workaround |
| 17:29:09 | BitPuffin | dom96: true |
| 17:29:14 | EXetoC | I mostly just remember supposed compiler bugs, and I think you encountered issues regarding float/float64 overloads being considered equal |
| 17:29:16 | BitPuffin | EXetoC: what do you mean |
| 17:29:31 | BitPuffin | can't remember lol |
| 17:30:16 | EXetoC | BitPuffin: ok but what about float64 + float64 -> float? rather than float64 + float64 -> float64, which I think makes more sense, even though float and float64 might be of the same size |
| 17:30:40 | * | vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 17:31:33 | * | Demos quit (Quit: leaving) |
| 17:32:37 | renesac|away | EXetoC: implicit conversion to a (possibly) smaller type on addition? |
| 17:32:41 | * | renesac|away is now known as renesac |
| 17:33:44 | EXetoC | renesac: not exactly http://build.nimrod-lang.org/docs/manual.html#pre-defined-floating-point-types |
| 17:34:07 | renesac | what was not exact? |
| 17:35:25 | EXetoC | float is assumed to always be >= float64 though, apparently, but at this point in time it's always float64 |
| 17:35:53 | EXetoC | so float64 + float64 *might* yield float64 instead in the future. that's just a minor point of confusion |
| 17:36:06 | renesac | where is this written in the manual? |
| 17:36:26 | renesac | I thought float may be float32 if it is faster in the target processor (eg: arm, a gpu, etc) |
| 17:36:47 | EXetoC | nowhere I think |
| 17:37:08 | renesac | I'm lost |
| 17:39:03 | renesac | only a comment: in the math.nim there are lots of functions that call C functions that expect a double (what the C defines as double in the machine) |
| 17:39:05 | EXetoC | "I am not sure what to do for ARM etc which prefers float32 for performance. I guess people can introduce their own "fastFloat" aliases." |
| 17:39:20 | EXetoC | so is the manual wrong then? |
| 17:39:43 | renesac | where is this quote from? |
| 17:39:53 | EXetoC | https://github.com/Araq/Nimrod/pull/583 |
| 17:46:03 | * | aftershave_ joined #nimrod |
| 17:46:07 | dom96 | BitPuffin: Please report that issue. |
| 17:46:19 | BitPuffin | dom96: yeah I will |
| 17:47:43 | renesac | yeah, I'm with ventor3000, I don't like the plataform-dependent type having a smaller name... |
| 17:48:37 | renesac | it leads to people writing plataform dependent behaviour in bad places |
| 17:49:30 | renesac | I like D naming: "int, long, size_t, float, double, quad, etc" |
| 17:58:31 | gour | is there in nimrod something like julia's coroutines? |
| 17:58:57 | EXetoC | that's just a case of some people not knowing the language well enough. they need to know a thing or to before they can care about fixed sizes and such |
| 17:59:47 | EXetoC | either way, the issue I've been discussing is the fact that float64 + float64 calls `+`(x, y: float): float, so it's not really relevant is it? |
| 18:01:39 | * | aftershave_ quit (Quit: Computer has gone to sleep.) |
| 18:05:07 | EXetoC | like I said, float is basically the biggest type then, in which the manual needs to be updated. the point is that the interface in system.nim might be confusing |
| 18:05:45 | * | vendethiel joined #nimrod |
| 18:17:36 | * | carum joined #nimrod |
| 18:40:42 | * | aftershave_ joined #nimrod |
| 18:44:26 | * | Matthias247 joined #nimrod |
| 18:44:51 | NimBot | Araq/Nimrod devel 51af4c2 Zahary Karadjov [+0 ±2 -0]: fix #807 |
| 18:47:02 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 18:49:59 | dom96 | zahary: Join #nimbuild |
| 18:52:27 | Matthias247 | I recoginized nimrod-lang.org is missing a link to Github. Somebody should add that :-) |
| 18:52:51 | dom96 | Matthias247: The website is in the repo, you're welcome to make a PR |
| 18:53:34 | Matthias247 | dom96: I think it should be prominent and with an Icon. And I'm not able to do icons :-) |
| 18:55:44 | Varriount | Meep! |
| 18:56:27 | Varriount | gour: Nimrod has closure iterators |
| 18:56:38 | Varriount | gour: Coroutines are planned, I think |
| 18:59:41 | * | carum quit (Remote host closed the connection) |
| 19:05:58 | * | carum joined #nimrod |
| 19:25:07 | * | zahary quit (Quit: Leaving.) |
| 19:28:02 | gour | Varriount: for 1.0? otoh, i must say julia looks as nice language as well |
| 19:28:34 | Varriount | gour: Not necessarily after 1.0 |
| 19:29:03 | Varriount | gour: Coroutines are planned as a possible GSoC project, if nimrod gets accepted. |
| 19:29:13 | gour | ahh, ok |
| 19:30:02 | gour | is 0.9.3 behind the schedule? |
| 19:34:21 | Matthias247 | gour: I think julia is interesting, but for another domain |
| 19:34:31 | Matthias247 | I would see it as a Matlab replacement |
| 19:34:47 | Matthias247 | fast scientifical somputing |
| 19:38:34 | gour | Matthias247: maybe atm, but it has capacity to become 'general purpose' language |
| 19:38:35 | * | carum quit (Remote host closed the connection) |
| 19:39:01 | * | micklat joined #nimrod |
| 19:39:13 | Matthias247 | gour: everybody gives itself that attribute nowadays. From Go over Haskell to Javascript ;) |
| 19:40:43 | gour | Matthias247: that's true but many also advertises as 'system? languages, like D, Rust, Nimrod |
| 19:42:26 | Matthias247 | which are not that much when you see how big the market is ;) |
| 19:43:40 | gour | :-) |
| 19:45:23 | EXetoC | is that from worst to best? |
| 19:45:53 | Matthias247 | he, maybe his answer depends on the IRC channel? :) |
| 19:46:53 | gour | i'm neither in #rust nor in #D ;) |
| 19:49:56 | bstrie | EXetoC: nah, it's like the olympic podium: gold medal in the center :) |
| 19:50:16 | EXetoC | huehue |
| 19:51:48 | * | BitPuffin joined #nimrod |
| 19:51:51 | Matthias247 | bstrie: but gold cannot corrode, so rust can't be gold |
| 19:52:02 | Matthias247 | and nimrod has the golden crown logo? :) |
| 19:52:18 | bstrie | Matthias247: I was trying to work that in somehow but got distracted |
| 19:59:02 | * | xtagon joined #nimrod |
| 20:00:28 | * | zahary joined #nimrod |
| 20:18:12 | renesac | EXetoC, I finally compiled the integer conversion problems in a github issue: https://github.com/Araq/Nimrod/issues/936 |
| 20:18:28 | * | Varriount|Mobile joined #nimrod |
| 20:26:47 | * | Demos joined #nimrod |
| 20:33:35 | * | aftershave_ quit (Quit: Textual IRC Client: www.textualapp.com) |
| 20:33:51 | * | aftershave_ joined #nimrod |
| 20:35:23 | * | aftershave_ quit (Client Quit) |
| 20:37:47 | * | circ-user-97jC3 joined #nimrod |
| 20:39:23 | * | circ-user-97jC3 is now known as nequitans |
| 20:40:40 | nequitans | Hi everybody, I'm super excited about Nimrod! |
| 20:41:18 | * | Trixar_za leaves nequitans alone in a room with the source code |
| 20:42:05 | nequitans | I was wondering: does there exist or are there any plans for numerics and plotting libraries by anyone? In either case, I think "numrod" would be a nice name :) |
| 20:45:25 | renesac | I would also like that, but your best bet right now would be the python bindings: https://github.com/micklat/NimBorg/blob/master/nimborg/py/test/test_pylab.nim |
| 20:46:43 | Araq | hi nequitans welcome. I planned a plotting library built on top of nim's graphics module but of course I never find the time |
| 20:47:08 | renesac | (those high level python bindings are new and still under development) |
| 20:47:44 | Demos | anyone know if there is a progmatic interface to GNUplot? |
| 20:47:48 | Demos | could use that |
| 20:48:06 | Demos | also I thought a lot of what numpy did was provide high speed data structures |
| 20:48:42 | renesac | Demos, and vector operations on them |
| 20:49:14 | renesac | and then, there is the entire ecosystem that uses those data strucutures |
| 20:49:43 | renesac | plus pandas, that offers data frames and other higher level data structures compatible with numpy |
| 20:50:04 | Demos | well presumably one could use SSE/MMX/whatever intrinsics in nimrod. Our linear algebra library (linagl) does not use em yet though. Are data frames like haskell's lenses? |
| 20:50:28 | renesac | I don't know haskell, but they are like R data frames |
| 20:50:58 | Demos | I dont know python but I know nimrod's data structures are quite fast. Depends on the specific data structure in terms of how easy/hard nimpy interop would be |
| 20:51:11 | renesac | http://pandas.pydata.org/pandas-docs/stable/10min.html |
| 20:51:53 | nequitans | @renesac: thanks! could be useful right away @Araq I'd be interested in thoughts/progress/contributing there. The template and macro structure could lend itself to some very nice syntaxes for numerical code |
| 20:52:07 | Demos | for the kind of data analysis people do in R/Matlab I am not sure nimrod is really that much better than pyton. I mean matlab is really slow. |
| 20:52:33 | Demos | *python |
| 20:52:38 | Demos | but what do I know right :D |
| 20:52:41 | renesac | well, julia was created because python wasn't fast enought for some tasks |
| 20:52:52 | Demos | yeah. As was Cython I guess |
| 20:53:11 | renesac | yeah, cython has other uses outside the scientific comunity though |
| 20:53:24 | Demos | right |
| 20:55:44 | renesac | there is no reason nimrod can't compete with those two too, other than manpower |
| 20:56:23 | renesac | though those high level python bindings are a nice shortcut |
| 20:56:25 | Demos | this is true |
| 20:56:57 | renesac | ping micklat: for performance, we should implement something like this; |
| 20:56:58 | renesac | http://docs.cython.org/src/userguide/memoryviews.html |
| 20:57:16 | renesac | for python interop |
| 20:57:56 | Demos | but I wanted to point out that it is not really a scripting language. And memory views look pretty much like arrays with demensional indexing functions. Kinda like Direct3D/OpenGL textures |
| 20:58:12 | Demos | or like what you get with Eigen or Blitz++ |
| 20:59:27 | renesac | Demos, btw, you asked other day what was the dificulty adding two numbers in python: http://stackoverflow.com/questions/13334218/where-are-operators-mapped-to-magic-methods-in-python |
| 21:00:19 | renesac | that is the overhead of interpreting a dynamic typed language |
| 21:01:44 | Demos | heh yeah |
| 21:05:29 | * | [1]Endy quit (Ping timeout: 272 seconds) |
| 21:05:33 | nequitans | @renesac -- I agree about the competition. I think nimrod has a # of advantages over python/cython. for example, expressivity: in python more language level modifications are required for performant code with a desired syntax. |
| 21:09:31 | renesac | yeah, and don't forget nirmod hability to define new operators |
| 21:10:36 | renesac | python is winning over R/Matlab by being a better all around language |
| 21:11:29 | renesac | nimrod could win this way too |
| 21:21:29 | skyfex | Isn't numpy an interface to LAPAC and BLAS? |
| 21:23:33 | nequitans | And, to me, nimrod has couple of compelling modern languages. Over Scala, there's no dependency on the JVM (which has caused me performance problems in the past) as well as the fact that library *design* seems less complex (Scala has a very interesting and complex way to integrate static types with functional and object-oriented programming, but it can make library design difficult). I think Rust makes the memory management a little too complex, whic |
| 21:23:57 | nequitans | *compelling features when compared to other modern languages |
| 21:24:02 | skyfex | I think it would be best to do "numrod" as an interface to LAPACK/BLAS as well.. |
| 21:24:23 | * | tinAndi joined #nimrod |
| 21:24:31 | renesac | skyfex, the thing is, there is a whole ecosystem based on numpy arrays in python |
| 21:24:48 | renesac | from machine learning, statmodels, etc |
| 21:24:57 | nequitans | I don't have any experience with Julia, though |
| 21:25:06 | renesac | me neither |
| 21:25:16 | micklat | renesac: take a peek near the end here: https://github.com/micklat/NimBorg/blob/master/nimborg/py/test/test_linalg.nim |
| 21:25:26 | skyfex | nequitans: I've looked a tiny bit on Julia.. it looks pretty cool, and seems to be catching on very fast despite being very beta |
| 21:25:45 | skyfex | They're using it in MIT courses |
| 21:27:21 | renesac | micklat, oh, cool |
| 21:27:27 | renesac | I'm not sure if I like the api though |
| 21:28:11 | micklat | suggest away |
| 21:28:54 | renesac | I don't have any sugestion right now, but it looks very low-level |
| 21:29:02 | skyfex | Maybe it would make sense to interface Nimrod to Julia libraries.. Julia and Nimrod seems quite similar, but I don't have too much experience with Julia |
| 21:29:09 | nequitans | ack -- sorry to bring up a compiler message, but I thought it might ring a bell to anyone who has used the nimborg bindings: |
| 21:29:20 | nequitans | nimborg/py/low_level.nim(1649, 18) Error: type mismatch: got (string, global_symbols: bool) but expected one of: dynlib.LoadLib(path: string): TLibHandle dynlib.LoadLib(): TLibHandle |
| 21:29:58 | nequitans | Is getting rid of global_symbols=true OK? |
| 21:31:31 | * | awestroke quit (Remote host closed the connection) |
| 21:31:39 | micklat | nequitans: I'll take a look |
| 21:32:13 | micklat | I remember now: global_symbols is a flag I added to loadLib |
| 21:32:20 | micklat | I needed it to make scipy work |
| 21:32:31 | micklat | but apparently my PR didn't get pulled into nimrod yet |
| 21:32:34 | gour | someone on the julia-devel wrote today that his experience is that julia provides 1.2x performance in comparison with C |
| 21:32:39 | nequitans | @skyfex one of my friends who has played a little with Julia mentioned that a couple of issues are it has mandatory garbage collection, the startup time is big, and that currently it doesn't produce executables -- but as far as bindings, it may be interesting |
| 21:33:12 | gour | nequitans: executables will come, according to devs |
| 21:33:25 | nequitans | @gour noted |
| 21:33:58 | micklat | nequitans: if you remove global_symbols=true, nimborg will work but scipy will not |
| 21:34:22 | micklat | or you can pull this version of nimrod and rebuild your compiler: https://github.com/micklat/Nimrod |
| 21:34:32 | nequitans | @micklat thanks for letting me know! I'd like scipy to work, so I'll rebuild the compiler |
| 21:34:43 | micklat | are you on windows or linux? |
| 21:37:02 | micklat | well, g'night |
| 21:37:05 | * | micklat quit (Remote host closed the connection) |
| 21:37:42 | * | brson joined #nimrod |
| 21:38:45 | tinAndi | hallo, are there any resources with examples for using the winapi (gui) with nimrod? |
| 21:39:49 | dom96 | https://github.com/Araq/Nimrod/blob/devel/examples/wingui.nim |
| 21:39:53 | dom96 | But that isn't much. |
| 21:43:01 | tinAndi | soory, i meant except 'wingui.nim' ;) |
| 21:44:55 | * | Varriount-Mobile joined #nimrod |
| 21:48:00 | * | Mat3 joined #nimrod |
| 21:48:03 | Mat3 | hi all |
| 21:48:36 | * | Varriount|Mobile quit (Ping timeout: 245 seconds) |
| 21:48:40 | Araq | hi Mat3 |
| 21:48:51 | tinAndi | can i use {.procvar.} for windows callbacks? (okay, i could test it, but it would be nice to have some more info...) |
| 21:48:56 | * | Varriount pushes his clone out of the way. |
| 21:49:25 | * | Varriount-Mobile quit (Remote host closed the connection) |
| 21:49:49 | Varriount | tinAndi: Actually, you might/should use regular procs |
| 21:50:07 | Varriount | the only thing that matters with window api callbacks, iirc, is the calling convention |
| 21:50:43 | Mat3 | hi Araq |
| 21:57:53 | * | gour quit (Quit: WeeChat 0.4.2) |
| 22:00:43 | nequitans | Araq: what inspired you to develop Nimrod? Seems to hit a sweet spot of efficiency, expressivity, and simplicity. Also, does it/do you plan for it to target the llvm directly or in other words, does targeting the llvm directly have any potential advantages? |
| 22:04:03 | Araq | nequitans: lots of reasons for creating nimrod |
| 22:05:45 | Araq | iirc I wanted to show that |
| 22:06:41 | Araq | a) dynamic binding as default is a stupid idea that's not nearly as often necessary as people think it is |
| 22:07:57 | Araq | b) Java's productivity gains over C++ are all due to having a GC, the "clean OO" paradigm has nothing to do with it |
| 22:08:31 | tinAndi | Varriount: Thank you, but i think I'am not ready for nimrod. registerclassex want's a struct where one member is a pointer to WNDPROC. I got to do some more basics with nimrod... |
| 22:09:20 | Varriount | tinAndi: If you think so. |
| 22:09:20 | Araq | c) Lisp style metaprogramming doesn't require a homoiconic syntax nor dynamic typing |
| 22:16:26 | * | tinAndi quit (Quit: ChatZilla 0.9.90.1 [Firefox 27.0.1/20140212131424]) |
| 22:16:36 | nequitans | Araq: thanks! |
| 22:24:13 | skyfex | Araq: The finally statement C generation is a bitch :P |
| 22:24:55 | Mat3 | sorry, what means 'a bitch' in these context ? |
| 22:25:28 | Trixar_za | That it's spiteful like a female dog |
| 22:29:48 | * | vbtt joined #nimrod |
| 22:30:09 | Mat3 | English is such a colourful language |
| 22:30:14 | Mat3 | hi vbtt |
| 22:31:36 | vbtt | Hi Mat3 |
| 22:32:16 | skyfex | Mat3: This is what I'm working on: https://github.com/Araq/Nimrod/issues/688 |
| 22:32:58 | skyfex | I know what the C codegen does wrong.. but it's a bit hard to understand why it's doing it |
| 22:34:43 | skyfex | But that's worries for another day.. |
| 22:34:50 | Matthias247 | can't the freestanding finally translated into a try {} finally {} block with the everything after finally in the try block? |
| 22:35:31 | skyfex | Matthias247: That's precisely what it does actually |
| 22:35:36 | Matthias247 | ah, ok |
| 22:35:57 | Matthias247 | I find the freestanding finally feature very cool. But the naming is bit ambigous, as #908 shows |
| 22:36:28 | skyfex | Indede |
| 22:36:51 | Matthias247 | coming from c++/java/etc. I expected 908 to do exactly what happens and never thought the finally could not realted to the try/except before |
| 22:37:04 | vbtt | If i come across a finally.. how can u tell if it is freestanding |
| 22:37:15 | skyfex | Matthias247: Actually bug #688 can be produced without the freestanding finally, just by rewriting the same way the compiler does |
| 22:37:59 | Araq | nequitans: I have a pro/cons list of llvm vs C which I should post somewhere I guess |
| 22:38:21 | Araq | from time to time I re-evaluate it |
| 22:38:31 | Araq | but llvm never wins :P |
| 22:38:36 | nequitans | Araq: noted. Thought there might not be a tweet-length answer to that question :) |
| 22:38:43 | Matthias247 | D the same feature, but calls it scope(exit) stmt |
| 22:39:13 | vbtt | Yeah and go Lang has defer |
| 22:39:17 | skyfex | Araq: I'd be very curious about the details there, let me know if you write it |
| 22:39:42 | Mat3 | Araq: I'm not a fan of LLVm either |
| 22:40:23 | Demos | at the very least using C means that if you have a C compiler booting the nimrod compiler is impressively fast |
| 22:40:38 | Demos | and more people have a C compiler than the LLVM libs |
| 22:40:48 | Araq | skyfex: if you're stuck with a bug, we have lots of other things to do |
| 22:40:59 | Araq | don't get stuck and frustrated |
| 22:41:07 | Matthias247 | Demos: oh yes, Nimrod compiler-compiling is about 100x faster than rust compiler-compiling |
| 22:41:08 | Araq | work on something else then ;-) |
| 22:42:35 | vbtt | I was really surprised how fast nimrod compiled itself. |
| 22:42:59 | Matthias247 | me too |
| 22:46:10 | * | Demos quit (Read error: Connection reset by peer) |
| 22:46:58 | Varriount | Araq: Sent a PR |
| 22:46:59 | Mat3 | skyfex: I trapped into a similar problem coding my VM in C. It is easy to let C compiler generating wrong code in this context |
| 22:48:14 | Mat3 | as the standards seem to be very unspecific in C programmers would say minor details |
| 22:48:45 | Matthias247 | C compiler standards for exceptions? :) |
| 22:50:10 | Mat3 | branch dependent handling of function epilogs for example |
| 22:50:28 | Mat3 | get some sleep, ciao |
| 22:50:36 | * | Mat3 quit (Quit: Verlassend) |
| 22:51:06 | skyfex | Araq: For now it's slighly more of a fun puzzle.. And I've been working on something else cool on the side to help me debug as well (XML output of each pass, with different CSS stylesheets to help look at the AST in different ways) |
| 22:52:16 | Araq | meh, I mostly use n.renderTree |
| 22:52:27 | Araq | must easier than looking at the raw AST |
| 22:53:24 | skyfex | Araq: Ah, didn't actually know about that module yet |
| 22:53:54 | Varriount | skyfex: It's built into one of the compiler modules. astalgo.nim I think |
| 22:54:52 | skyfex | Varriount: Thanks, astalgo.nim I knew about, renderer.nim is new to me |
| 22:55:51 | * | zahary1 joined #nimrod |
| 23:00:03 | * | Varriount looks at renderer.nim |
| 23:00:51 | skyfex | getting some sleep too, baibai |
| 23:01:06 | * | BitPuffin quit (Ping timeout: 245 seconds) |
| 23:01:13 | * | skyfex quit (Quit: Lingo - http://www.lingoirc.com) |
| 23:02:04 | * | Kooda quit (Remote host closed the connection) |
| 23:02:14 | * | BitPuffin joined #nimrod |
| 23:04:28 | NimBot | Araq/Nimrod devel 23f1ae1 vocalbit [+0 ±2 -0]: Add two news items to website. |
| 23:04:28 | NimBot | Araq/Nimrod devel 4a389d0 vocalbit [+0 ±1 -0]: Fix website news formatting and grammar to be consistent. |
| 23:04:28 | NimBot | Araq/Nimrod devel 009a0d2 vocalbit [+0 ±1 -0]: Make ticker puntuation consistent. |
| 23:04:28 | NimBot | Araq/Nimrod devel b022887 Andreas Rumpf [+0 ±2 -0]: Merge pull request #934 from vocalbit/devel... 2 more lines |
| 23:08:12 | * | vbtt quit (Quit: Bye) |
| 23:08:26 | * | vbtt joined #nimrod |
| 23:08:35 | vbtt | thanks Araq |
| 23:08:46 | * | io2 quit () |
| 23:08:51 | vbtt | funny it took me 3 cls for a simple change.. |
| 23:12:01 | * | Kooda joined #nimrod |
| 23:12:53 | Araq | 3 cls? |
| 23:12:56 | Araq | what's cls? |
| 23:18:50 | dom96 | commit lines? |
| 23:21:12 | vbtt | change list |
| 23:21:22 | vbtt | i guess i call a commit a cl |
| 23:22:31 | EXetoC | I'm afraid it hasn't caught on yet :> |
| 23:22:53 | Varriount | I just call a commit a commit |
| 23:22:53 | vbtt | heh it's old terminology. |
| 23:23:28 | vbtt | http://en.wikipedia.org/wiki/Revision_control |
| 23:24:07 | * | tinAndi joined #nimrod |
| 23:25:37 | vbtt | 'commit' used to be a verb |
| 23:25:56 | vbtt | changelist or changeset is a noun. |
| 23:29:45 | * | oxful quit (Ping timeout: 265 seconds) |
| 23:30:58 | Varriount | Whats the difference between a "ref object of TObject" and a "ref object of PObject"? |
| 23:31:13 | * | tinAndi quit (Quit: ChatZilla 0.9.90.1 [Firefox 27.0.1/20140212131424]) |
| 23:35:16 | vbtt | ref of PObject sounds like pointer to a pointer. |
| 23:35:22 | vbtt | i.e. double indirection. |
| 23:35:52 | vbtt | ref of TObject is pointer to the object |
| 23:36:01 | vbtt | hmm |
| 23:36:06 | vbtt | perhaps I shouldn't say pointer. |
| 23:36:20 | dom96 | 'of' means inheritance |
| 23:37:03 | * | oxful joined #nimrod |
| 23:37:57 | Araq | vbtt: 'ref object' is often used but then you don't have a name for the 'object' itself so 'of' can take a pointer and then strips it away to get the underlying value type |
| 23:39:32 | Varriount | Araq: So.. whats the difference between "ref object of TObject" and "ref object of PObject"? |
| 23:39:36 | vbtt | didn't get it but never mind. will re-read later. |
| 23:39:49 | NimBot | Araq/Nimrod devel c993d46 Araq [+0 ±1 -0]: nil->discard |
| 23:39:49 | NimBot | Araq/Nimrod devel 4e5b7ee Araq [+0 ±1 -0]: fixes #922 |
| 23:39:49 | NimBot | Araq/Nimrod devel 2f06970 Araq [+0 ±1 -0]: fixes #923 |
| 23:39:49 | NimBot | Araq/Nimrod devel 2f24475 Araq [+1 ±1 -0]: fixes #926 |
| 23:39:49 | NimBot | 4 more commits. |
| 23:40:06 | Araq | Varriount: there is none |
| 23:40:38 | Araq | "ref object of PObject" is supported for convenience when the TObject has no name |
| 23:51:48 | * | filwit joined #nimrod |
| 23:52:02 | filwit | hey Araq, you still awake? |
| 23:52:27 | filwit | you fixed my macro bug with a recent code push, thanks mate |
| 23:53:44 | filwit | i gotta look at how you did it, but I just wanted to let you know now everything works with my macros on devel without my changes |
| 23:54:38 | filwit | i was putting off making a pull-request until i could ask you about the changes I made to get around it, but looks like you took care of it |
| 23:55:09 | Araq | good to hear |
| 23:55:23 | Araq | but tstringinterp is my new hard test case |
| 23:55:24 | filwit | now i don't have any Nimrod PR's under my belt though.. gotta go find an easy bug to fix on the list or something soon |
| 23:55:39 | Araq | ha, nothing is easy |
| 23:56:10 | filwit | yeah, i know. let me take a look at your code changes. you going to be around for the next 10 mins? |
| 23:56:24 | Araq | ok |
| 23:56:31 | filwit | i want to know if my fixes where similar to what you did, one sec |
| 23:57:09 | filwit | nope.. |
| 23:57:14 | filwit | hmmm.. |
| 23:59:07 | * | darkf joined #nimrod |
| 23:59:15 | filwit | pretty sure this fix was probably what changed it: https://github.com/Araq/Nimrod/issues/926 |
| 23:59:32 | filwit | anyways, i'll take a look at your changes and see what you did |