| 00:01:32 | * | Guest31831 quit (Quit: Leaving) |
| 00:06:00 | EXetoC | Skrylar: see beep |
| 00:06:13 | Skrylar | skrylar is not robot |
| 00:06:21 | * | Skrylar awaits insertion of floppy diskette |
| 00:06:54 | EXetoC | http://www.urbandictionary.com/define.php?term=beep&defid=582119 |
| 00:06:59 | EXetoC | and meep is that muppet dude |
| 00:09:26 | Skrylar | -.- |
| 00:09:36 | Skrylar | I made the compiler segfault itself. |
| 00:13:23 | flaviu | Isn't the PEG `&(\n/^)` equivalent to the regex `^`? It refuses to match anything but the input start. |
| 00:14:55 | * | io2 quit () |
| 00:16:33 | runvnc | dom96: is there a way to process a request through a route, but have jester just not close the socket? |
| 00:16:47 | runvnc | I am putting some requests in a redis queue that gets handled by another process |
| 00:17:17 | runvnc | and I get like a callback from my little queue module |
| 00:18:15 | dom96 | use sendHeaders |
| 00:18:20 | dom96 | IIRC the socket won't get closed then |
| 00:18:32 | runvnc | is that all? awesome |
| 00:19:00 | runvnc | I have been trying to do this with httpserver but I really need all the stuff you put in jester so I had to revise that idea |
| 00:19:23 | dom96 | hrm, well i'm looking at the source and it looks like I'm wrong |
| 00:19:25 | runvnc | and I can get the socket from response.client maybe |
| 00:20:48 | dom96 | I could have sworn I added this :\ |
| 00:20:57 | runvnc | I was thinking maybe if I could get the socket out of the response and then just hack on a new TCAction type to say don't close |
| 00:21:22 | dom96 | yeah, well I think that TCActionRaw shouldn't close the socket. |
| 00:21:26 | dom96 | So just use that. |
| 00:21:40 | dom96 | Should be a fairly easy change. |
| 00:21:55 | runvnc | you think I need to change jester, or can I set response.data from my program |
| 00:22:35 | dom96 | you need to change jester |
| 00:23:05 | runvnc | ok thanks |
| 00:23:23 | * | zielmicha quit (Quit: Connection closed for inactivity) |
| 00:23:36 | dom96 | You should be able to do: if resp.data.action != TCActionRaw: on line 341 |
| 00:24:03 | dom96 | Argh, nah. The resp will be out of scope. |
| 00:24:13 | dom96 | You can create a var similar to the 'matched' |
| 00:24:18 | dom96 | and set it in routeReq |
| 00:24:33 | * | dom96 should really reevaluate this excessive use of templates in Jester |
| 00:24:45 | runvnc | ok thanks |
| 00:25:23 | runvnc | I just have to grab breakfast and then I will try to figure it out don't tell me the whole thing please |
| 00:25:24 | runvnc | heh |
| 00:28:58 | renesac | https://github.com/Araq/Nimrod/blob/7778e79f24a1da4dccfeacc0e9936b171fd1eb74/tests/misc/tinout.nim |
| 00:29:13 | renesac | <-- why int literals can't be passed to procs expecting 'var' parameters? |
| 00:30:04 | Skrylar | renesac: because 'var' implies the input is mutable, a literal is not mutable |
| 00:30:32 | renesac | well... but it isn't an imutable variable either |
| 00:30:49 | Skrylar | literals are immutable |
| 00:30:52 | renesac | it is not like a person reading that code will assume I wanted to change what '3' means in the code |
| 00:31:30 | EXetoC | I've wanted the ability to introduce vars at the actual call site |
| 00:31:31 | renesac | put a gap in the integer range |
| 00:31:39 | Skrylar | well when you say '3' its going either in to .STATIC space or getting shoved in registers directly, so changing it is either not possible (static pages are read-only) or silly |
| 00:31:46 | EXetoC | but I don't think I reported that |
| 00:32:07 | Skrylar | i get to track down why this rectangle packer ICEs :/ |
| 00:32:11 | renesac | but literals could go in a different static space |
| 00:32:18 | Skrylar | "var rect: Rectangle[T]" # ICE |
| 00:32:41 | renesac | so this expression could be calculated at compile time |
| 00:34:47 | renesac | or at least the compiler declare a 'var x = 3' for you in those cases |
| 00:41:16 | renesac | I also wanted to reuse the parameter variables when doing calculations, w/o having to came up with a new name and declare a var with that new name |
| 00:41:33 | EXetoC | I don't think it matters what the rvalue is. it's just a syntactic shortcut |
| 00:41:57 | renesac | and probably go around the rest of the function replacing the parameter name by the new var name |
| 00:42:52 | renesac | at least give the option of marking 'var x' on the parameters line to make that parameter variable... |
| 00:42:58 | renesac | but alas, this is already token |
| 00:43:26 | renesac | why the current 'var x' isn't 'ref x'? |
| 00:43:26 | * | clovis quit (Quit: clovis) |
| 00:43:27 | EXetoC | variable? |
| 00:44:21 | renesac | yeah, like "proc foo(a,b: bool) = if a: b = true; (do the rest of the function)" |
| 00:44:29 | renesac | w/o changing b at call site |
| 00:44:57 | renesac | currently we need to define a new 'c' variable to do that |
| 00:44:59 | EXetoC | because ref means a traced GC-managed reference |
| 00:45:42 | EXetoC | I don't know what you mean |
| 00:45:44 | renesac | hum, there are procs that actually expect a 'ref'? |
| 00:45:54 | EXetoC | yes |
| 00:45:56 | renesac | EXetoC, what wasn't clear? |
| 00:46:30 | renesac | the snipped I gave don't compiles |
| 00:46:43 | renesac | but would be the most convenient behaviour |
| 00:46:46 | EXetoC | renesac: ok so you mean mutable without actually passing by reference |
| 00:47:01 | renesac | yeah, mutable but only inside the function |
| 00:50:24 | ScriptDevil | Small suggestion. Given all the metaprogramming that Nimrod can do, suggesting when false: for comments seems a bit of a let-down. Is there something else that people use for block-comments? |
| 00:50:53 | renesac | ScriptDevil, ctrl + shift + c |
| 00:51:18 | renesac | or the equivalent on your editor |
| 00:51:22 | ScriptDevil | renesac: Or M-; I know the editor shortcuts (Assuming you are talking about it) |
| 00:51:51 | ScriptDevil | I felt suggesting a hack like "when false:" in the tutorial isn't too neat. |
| 00:52:27 | renesac | that hack actually works better than C block comments |
| 00:52:31 | renesac | it is nestable |
| 00:52:43 | flaviu | In python, multiline comments are strings. That seems like a hack... |
| 00:52:58 | renesac | oh |
| 00:53:05 | renesac | nimrod supports that too |
| 00:53:14 | dom96 | You can also use: discard """ ... """ in Nimrod. |
| 00:53:14 | renesac | discard """ your comment """ |
| 00:53:45 | ScriptDevil | Yes, C-comments are not too good. |
| 00:53:50 | ScriptDevil | discard seems nice. |
| 00:56:35 | EXetoC | discard is necessary because values cannot be implicitly ignored |
| 00:56:57 | EXetoC | so it's just a literal that you're throwing away |
| 00:57:46 | dom96 | I think it would be nice to make """ """ an exception to that rule. |
| 00:57:53 | ScriptDevil | EXetoC: Yeah, it is fine. I don't want to complain too much, but it is just that I generally have non-docstring comments set to a color which has very low contrast to the BG-color. |
| 00:58:05 | ScriptDevil | But that is just my workflow. |
| 00:58:16 | dom96 | Although I would prefer a different multi-line comment syntax. |
| 00:58:53 | ScriptDevil | Several languages provide nestable block comments, Haskell {- -} and Ocaml (* *) |
| 00:59:06 | ScriptDevil | Or ruby =begin =end |
| 01:00:14 | ScriptDevil | Also, I am assuming that when false: still syntax checks the dead-code. Which is in itself something I wouldn't want for some temporary code I stashed away. |
| 01:00:36 | flaviu | ScriptDevil: IIRC it doesn't |
| 01:00:54 | renesac | or Lua --[==[ ]==] |
| 01:01:01 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 01:01:33 | renesac | (with zero to infinity '=') |
| 01:01:38 | ScriptDevil | renesac: That lua thing is a serious piece of work... I lol at the number of extra == it piles on :D |
| 01:02:02 | EXetoC | what about this? --[==[##[@@[$$[]$$]@@]##]==]-- |
| 01:02:31 | ScriptDevil | :o Don't tell me that is a real thing. I haven't done much Lua, but that is an eyesore if I have ever seen one. |
| 01:02:32 | renesac | everything inside the --[==[ ]==] is commented out |
| 01:02:41 | renesac | if it is lua |
| 01:02:56 | EXetoC | renesac: what do you mean? any repetition is optional? |
| 01:03:07 | EXetoC | ScriptDevil: nah |
| 01:03:09 | renesac | yes |
| 01:03:14 | renesac | the basic form is |
| 01:03:19 | renesac | --[[ ]] |
| 01:03:30 | renesac | but then you cant put a ]] inside it |
| 01:04:26 | renesac | but if you use --[=[ this comment contains ]] ]=] it allows the ]] inside the comment |
| 01:04:28 | * | ScriptDevil mumbles It is turtles all the way down... |
| 01:05:04 | renesac | you only need simetrical number of == for each comment level |
| 01:08:40 | * | CARAM quit (Remote host closed the connection) |
| 01:08:41 | * | ics joined #nimrod |
| 01:10:48 | * | XAMPP joined #nimrod |
| 01:24:41 | * | CARAM joined #nimrod |
| 01:29:26 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 01:31:31 | Skrylar | how do things keep getting stuck in my 3 key |
| 01:40:13 | * | xenagi joined #nimrod |
| 01:51:06 | * | CARAM quit (Remote host closed the connection) |
| 02:08:57 | ScriptDevil | Skrylar: You probably aren't looking for an answer. But it could be because it is right above "e" which is pressed most often. |
| 02:10:34 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 02:13:01 | Skrylar | ScriptDevil: probably. |
| 02:13:36 | Skrylar | Skrylar: though so far the problem happens most on flat membrane keyboards; my mechanicals don't do that |
| 02:18:14 | * | ScriptDevil quit (Quit: "Breakfast...") |
| 02:23:42 | * | q66 quit (Quit: Leaving) |
| 02:23:54 | fowl | fowl, you are pretty k00l |
| 02:24:00 | fowl | fowl, thanks man, i like you too |
| 02:28:09 | * | Demos joined #nimrod |
| 02:30:33 | renesac | https://gist.github.com/ReneSac/681bc1485ed2ccde6ecb <-- what is happening here? |
| 02:31:06 | fowl | renesac, you dont return anything from ++ |
| 02:31:38 | renesac | right, but then 'Error: expression '++ x' has no type (or is ambiguous)' |
| 02:32:03 | renesac | I must return a value? |
| 02:32:24 | fowl | renesac, since you dont return or use the result variable the result is 0 |
| 02:32:29 | renesac | yeah, I guess yes |
| 02:32:51 | renesac | ok, just put a discardable there |
| 02:32:59 | renesac | and it is all set |
| 02:33:26 | fowl | what exactly do you want here |
| 02:34:11 | renesac | https://gist.github.com/ReneSac/681bc1485ed2ccde6ecb <-- now it's working |
| 02:35:11 | Skrylar | fowl are you feeling underappreciated |
| 02:35:14 | fowl | o |
| 02:35:43 | renesac | but I can't turn it in a template: Error: expression 'inc(x, 1)' has no type (or is ambiguous) |
| 02:35:56 | renesac | (trying to hack around precedence rules XD) |
| 02:36:49 | * | Demos quit (Ping timeout: 240 seconds) |
| 02:37:29 | renesac | https://gist.github.com/ReneSac/681bc1485ed2ccde6ecb <-- gist updated |
| 02:38:52 | renesac | ok |
| 02:39:01 | renesac | just taking the return type off it |
| 02:39:26 | renesac | but then I can't use in expressions |
| 02:40:03 | renesac | and templates don't accept {.discardable.}... |
| 02:40:43 | fowl | templates wont help you change precedence |
| 02:40:58 | fowl | Skrylar, making fun of you |
| 02:41:11 | fowl | <Skrylar> Skrylar: though so far .. |
| 02:42:50 | Skrylar | :P |
| 02:43:13 | renesac | fowl, they just did |
| 02:43:14 | renesac | :D |
| 02:43:55 | renesac | https://gist.github.com/ReneSac/681bc1485ed2ccde6ecb |
| 02:44:04 | renesac | function call FTW! |
| 02:45:39 | * | renesac does a super villain laugh |
| 02:46:13 | fowl | renesac, just call myinc `++` and it works the same ... |
| 02:46:25 | fowl | renesac, that doesnt change precedence at all |
| 02:48:17 | renesac | strange, I thought it would do the * first |
| 02:48:36 | renesac | as + has lower precedence than * |
| 02:49:21 | fowl | unary vs binary |
| 02:49:22 | * | ics joined #nimrod |
| 02:49:52 | renesac | where this is described at the manual? |
| 02:50:50 | renesac | that unary operators have always the highest precedence? |
| 02:51:30 | fowl | nobody ever expects + 1 - 2 to mean +(-(1, 2)) |
| 02:52:22 | fowl | http://build.nimrod-lang.org/docs/manual.html#precedence |
| 02:58:35 | * | flaviu quit (Remote host closed the connection) |
| 03:01:42 | renesac | I don't see anything about unary there |
| 03:01:50 | renesac | only If the operator's relevant character is @ it is a sigil-like operator which binds stronger than a primarySuffix: @x.abc is parsed as (@x).abc whereas $x.abc is parsed as $(x.abc). |
| 03:02:17 | renesac | I guess it is a non-documented special case for + and - |
| 03:03:12 | renesac | and in the table "@" has the lowest, not the highest precedence, which is strange too |
| 03:03:24 | fowl | special case for + and - ? what |
| 03:03:30 | renesac | seems to contradict that phrase quoted |
| 03:03:37 | fowl | what makes you think this |
| 03:03:43 | renesac | fowl, please quote where the manual says that unary operator has higher precedence? |
| 03:03:47 | renesac | *. |
| 03:04:14 | renesac | and I just said in the last lines what makes me think this |
| 03:04:37 | renesac | (@, $ example, for example) |
| 03:05:13 | Skrylar | so i've isolated the ICE from earlier to a single line |
| 03:05:19 | Skrylar | all though i'm not sure why that causes an ice |
| 03:05:28 | fowl | renesac, you're asking for confirmation that unary and binary operations do not have the same precedence -- ? |
| 03:05:43 | fowl | how could they |
| 03:08:34 | runvnc | is there a way to prevent this proc from showing in the docs? I am only exposing it because a macro needs it |
| 03:08:41 | runvnc | er a template needs it |
| 03:09:01 | fowl | runvnc, dont export it, use bind instead |
| 03:09:21 | runvnc | ok thanks let me try that |
| 03:15:08 | runvnc | it keeps saying undeclared identifier |
| 03:15:13 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 03:15:43 | runvnc | see I am trying to use this macro in my program, its from another module, the macro uses this one proc from the module |
| 03:15:48 | runvnc | I mean template |
| 03:16:17 | runvnc | I will look at the manual about bind |
| 03:17:44 | * | CARAM joined #nimrod |
| 03:19:14 | runvnc | if I call it statusContent(response.client instead of response.client.statusContent( then it works |
| 03:19:14 | renesac | fowl, no: [00:03:43] <renesac> fowl, please quote where the manual says that unary operator has higher precedence |
| 03:19:19 | runvnc | so problem solved thanks |
| 03:19:31 | renesac | otherwise, I will assume: [00:02:17] <renesac> I guess it is a non-documented special case for + and - |
| 03:23:59 | fowl | renesac, its no skin off my nose if you want to believe your assumptions |
| 03:24:16 | renesac | it is undocumented, right? |
| 03:24:27 | fowl | it is not true |
| 03:24:42 | renesac | so, where the manual says something about it |
| 03:24:44 | fowl | you have a line of code that shows this behavior |
| 03:25:06 | fowl | how can the manual say anything thats undocumented? |
| 03:25:20 | renesac | ?? |
| 03:25:36 | renesac | if the manual don't say anything about unary operators precedence, then it is undocumented |
| 03:25:44 | fowl | oy |
| 03:26:09 | renesac | what 'oy' means? |
| 03:26:34 | fowl | an expression of dismay |
| 03:27:05 | renesac | For operators that are not keywords the precedence is determined by the following rules: |
| 03:27:07 | renesac | [... ] |
| 03:27:13 | renesac | Otherwise precedence is determined by the relevant character. |
| 03:27:57 | renesac | `++` don't fit in any of those previous rules, therefore it's precedence should be the same as the relevant character, acording to the manual |
| 03:28:21 | fowl | there is no special case for +/-, idk what you're talking about |
| 03:28:26 | renesac | and "An operator symbol's relevant character is its first character unless the first character is \ and its length is greater than 1 then it is the second character." |
| 03:28:44 | renesac | so `++` relevant character is + |
| 03:28:59 | renesac | which has a precedence level of 7 |
| 03:29:01 | renesac | lower than * |
| 03:29:11 | fowl | what is the issue anyways |
| 03:29:26 | renesac | so, acording to the manual `++` should evaluate after * |
| 03:29:43 | renesac | but that is not what happen |
| 03:29:44 | renesac | s |
| 03:29:46 | fowl | jesus |
| 03:30:14 | fowl | i cant help you with this renesac because i've already explained whats going on |
| 03:30:27 | renesac | you explained how it works |
| 03:30:39 | renesac | but the manual defines the precedence differently |
| 03:30:52 | renesac | what from I just quoted was wrong? |
| 03:31:45 | fowl | your understanding is wrong |
| 03:31:54 | renesac | where exactly? |
| 03:32:54 | renesac | bbl |
| 03:33:02 | * | renesac is now known as renesac|away |
| 03:37:29 | fowl | renesac|away, there is no operator that binds higher than binary expressions |
| 03:52:16 | * | nequitans_ joined #nimrod |
| 03:56:39 | Skrylar | interesting |
| 03:56:46 | Skrylar | even though i declare it as proc foo* [T] |
| 03:56:53 | Skrylar | if i call a specific form foo[int](self) |
| 03:57:06 | Skrylar | it tells me that function doesn't exist, and to try a non-generic form that doesn't exist |
| 03:57:27 | fowl | foo*[T] has no parameters |
| 03:57:48 | Skrylar | the full call is "method TryGet* [T](self: var MaxRectPacker[T]; width, height: T; outRectangle: var Rectangle[T]): bool =" |
| 03:58:00 | fowl | generic methods dont work |
| 03:58:11 | Skrylar | i changed it out for a proc and it still broke |
| 03:58:42 | Skrylar | Swap method with proc, remove the other method definition from another unit, same error |
| 03:58:55 | Skrylar | if I leave the [int] specifier off the proc call, it gives a read from nil ICE |
| 03:59:15 | fowl | id have to see the whole code |
| 04:01:24 | * | renesac|away is now known as renesac |
| 04:01:37 | renesac | I guess you mean unary expressions |
| 04:01:58 | Skrylar | fowl: one minute; i'll merge it back in to github |
| 04:02:10 | renesac | but then, what is this paragraph: "If the operator's relevant character is @ it is a sigil-like operator which binds stronger than a primarySuffix: @x.abc is parsed as (@x).abc whereas $x.abc is parsed as $(x.abc)." |
| 04:02:10 | renesac | ? |
| 04:02:25 | renesac | @ and $ aren't unary operators there? |
| 04:02:25 | fowl | renesac, no, i meant binary expressions |
| 04:02:32 | fowl | renesac, yes, they are. |
| 04:03:23 | renesac | so.. '.' is binary |
| 04:03:34 | renesac | and yet there are different behaviours |
| 04:04:01 | Skrylar | fowl: https://github.com/Skrylar/Skylight or more specifically skylight/maxrectpack.nim |
| 04:04:24 | renesac | and nowhere in the manual says that precedence rules only apply to binary operators |
| 04:04:26 | renesac | :/ |
| 04:04:52 | fowl | renesac, i cant help you, post on the forum or create an issue |
| 04:05:26 | Skrylar | i isolated it down to the crash being caused in TryGet, when you remove any code that tries to refer to a Rectangle[T] type it goes away |
| 04:05:50 | Skrylar | Judging by the errors when specifying the types on proc calls, the compiler isn't understanding that there is a generic type at play |
| 04:06:00 | Skrylar | so its trying to initialize Rectangle[nil] and failing |
| 04:06:42 | fowl | you still have it as a method |
| 04:06:42 | renesac | fowl, ok |
| 04:09:26 | Skrylar | thats the base code |
| 04:09:49 | Skrylar | i didn't plan on making 90 commits of every single line adjustment that still resulted in segfaults |
| 04:10:41 | Skrylar | 1) went in to binpack.nim, commented out tryget method, went back and renamed TryGet from method to proc, same issue |
| 04:11:19 | Skrylar | 2) changing the test to while TryGet[int](packer, 32, 32, outRect) results in crash |
| 04:11:41 | Skrylar | packer.TryGet[int](...) results in the compiler being confused but not ICE |
| 04:12:37 | fowl | yea thats not supported for explicit generic instantiation |
| 04:12:50 | fowl | you have to use f[t](x,y) not x.f[t](y) |
| 04:12:58 | Skrylar | see #2 |
| 04:14:12 | Skrylar | alright, i found the specific issue |
| 04:14:23 | Skrylar | generics can't have *any* methods against them (which sounds like a bug in itself) |
| 04:14:54 | Skrylar | is there already a bug report for that? it *really* shouldn't give ICEs for that if its intentional |
| 04:16:30 | fowl | idk |
| 04:16:49 | Skrylar | i made a todo to report it |
| 04:19:16 | Skrylar | nevermind. that didn't actually fix it |
| 04:19:28 | Skrylar | its apparently genuinely just botching the generic field |
| 04:37:46 | * | Mordecai joined #nimrod |
| 04:38:31 | * | Mordecai is now known as Guest23044 |
| 04:39:42 | * | psquid quit (Ping timeout: 252 seconds) |
| 04:42:03 | * | Skrylar sighs |
| 04:43:39 | Skrylar | time to rebuild the compiler in debug mode i guess |
| 04:47:16 | Skrylar | semGeneric -> addSonSkipIntLit -> skipIntLit |
| 04:50:12 | Skrylar | ... yep |
| 04:50:16 | Skrylar | fowl: well i think i found the problem |
| 04:50:38 | Skrylar | there's a part of the compiler that does "x.n != nil" but not "x != nil", yet calls the function with no argument |
| 04:56:14 | Skrylar | i'll have to bother Araq about it later |
| 04:56:35 | renesac | fill a bug report with what you said here |
| 04:56:40 | Skrylar | It looks like what I thought was happening is exactly whats happening; it's not parsing the [int] part |
| 05:07:04 | eximius | hey, what was the url to the 9.4 docs? build.nimrod-lang.org/..... |
| 05:09:33 | renesac | http://build.nimrod-lang.org/docs |
| 05:10:01 | eximius | 403 forbidden |
| 05:10:50 | renesac | http://build.nimrod-lang.org/docs/ |
| 05:11:15 | eximius | *facepalm* .... right. thanks. |
| 05:11:35 | renesac | that was my error too |
| 05:12:07 | eximius | np |
| 05:13:41 | renesac | bithacks.nim(44, 8) Error: type mismatch: got (uint32, int) |
| 05:13:42 | renesac | but expected one of: |
| 05:13:42 | renesac | bithacks.or(x: TSignedInt or TUnsignedInt, y: TSignedInt or TUnsignedInt): int |
| 05:14:07 | Skrylar | i think they both need to be the same |
| 05:14:16 | Skrylar | though that error is being derpy |
| 05:14:36 | renesac | yeah, I'm trying to work around that with my own `or` |
| 05:16:12 | renesac | but the compiler is being really stubborn.. |
| 05:16:30 | renesac | btw, the function declaration is: (x, y: distinct Tinteger) |
| 05:16:46 | renesac | for some reason, when I use distinct the TInteger is expanded |
| 05:18:32 | renesac | bithacks.or(x: T, y: U): T <-- no joy also |
| 05:18:41 | Skrylar | i'm not sure what thats supposed to be called now; we're not supposed to use TNames anymore |
| 05:19:50 | renesac | well, it is still called that in system.nim, apparently |
| 05:23:30 | Skrylar | bleh. i saw we have a event handler module based on PyEE |
| 05:23:38 | Skrylar | I don't think I like x.on("somestring", handler) personally |
| 05:24:53 | * | rveach_ quit (Ping timeout: 246 seconds) |
| 05:25:02 | Skrylar | Maybe its just me, but I rather like hard-typed signals and slots over string lookup table dispatches |
| 05:27:34 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 05:35:33 | * | ics joined #nimrod |
| 05:35:39 | * | xenagi quit (Remote host closed the connection) |
| 05:57:31 | * | brson quit (Ping timeout: 264 seconds) |
| 06:02:05 | renesac | Error: type mismatch: got (Array constructor[0..31, int]) but expected 'array[0..31, Byte]' |
| 06:02:06 | renesac | :/ |
| 06:02:53 | renesac | that is a combination of two bugs I already reported |
| 06:04:26 | Skrylar | you have to put byte(x) around every element |
| 06:04:32 | Skrylar | that works for arrays of uints |
| 06:05:58 | Skrylar | unfortunately the bug i reported earlier is a showstopper :( i'll have to find a different part of the project to work on in the interim :\ |
| 06:08:52 | renesac | well, I'm using int-sized array as a quicker work around (quicker in development time, not speed) |
| 06:10:34 | Skrylar | quicker than typing [byte(1), byte(2)..]? |
| 06:10:45 | Skrylar | I seem to remember Araq mentioning you can make a converter against the lit(int) type |
| 06:12:22 | * | brson joined #nimrod |
| 06:12:39 | fowl | nooo |
| 06:12:48 | fowl | Skrylar, you just need to annotate the first member |
| 06:13:00 | fowl | [1.byte, 2, 4, x, ..] |
| 06:13:18 | fowl | since every member is the same type |
| 06:17:13 | Skrylar | tell him that. :o |
| 06:18:06 | fowl | renesac, that^ |
| 06:18:24 | Skrylar | fowl: do you think signals and slots would work well in nimrod? |
| 06:18:32 | Skrylar | seems like a template should be able to do it |
| 06:19:12 | Skrylar | i think there are some really fancy ones that deal with weak references (Qt's?) but most of them are just a sequence |
| 06:19:15 | fowl | signals like sigint/hup/term ? |
| 06:19:20 | Skrylar | no, like Qt |
| 06:19:22 | fowl | i dont know what slots are |
| 06:19:40 | Skrylar | Qt signals and slots are basically an array of function pointers |
| 06:19:56 | fowl | ah im reading about them now |
| 06:19:58 | Skrylar | all though Qt has some smartness so when a QObject gets finalized it removes itself from signals IIRC |
| 06:20:35 | Skrylar | so you can do things like mywindow.onClosed.connect(doathing) |
| 06:20:57 | Skrylar | I saw the nimee module in stdlib, not sure i like it.. that just binds a string and a thinly typed pointer |
| 06:22:13 | fowl | the events module? |
| 06:23:54 | Skrylar | yeah |
| 06:24:03 | Skrylar | i peeked at the docs for it, wasn't really thrilled |
| 06:25:10 | Skrylar | I'm not thrilled with string-based event hookups, because you have to go and invoke a hash table every event; and the docs for events didn't mention if it runs them through normalize() first |
| 06:25:33 | Skrylar | Compared to a direct generic, which is going to skip the normalize/hash step |
| 06:26:48 | fowl | no hash table, it does a linear search |
| 06:27:13 | fowl | check out the source - it could definitely be optimized |
| 06:31:29 | renesac | 'for i in uint32.high - 100_000 .. uint32.high:' wraps around here |
| 06:31:45 | renesac | probably in an infinite loop |
| 06:31:50 | Skrylar | fowl: thats probably worse o_O |
| 06:31:58 | renesac | fowl, thanks, I forgot that |
| 06:32:47 | Skrylar | using compile-time funcs you could pre-hash the event strings, so as long as there was no collision you could have a really cheap linear search |
| 06:33:08 | Skrylar | then again, you could also just use a directly wired callback and its as cheap as it gets |
| 06:35:18 | renesac | anyone can reproduce that infinite loop? |
| 06:35:40 | renesac | Error: type mismatch: got (int literal(1), Byte) <-- even with 'converter toByte*(x: int{lit}): byte = x.byte' |
| 06:35:46 | renesac | :/ |
| 06:37:23 | renesac | the target function, of course: unsigned.+(x: T, y: T): T |
| 06:37:57 | renesac | going back to int, quicker than fixing all that |
| 06:40:31 | fowl | renesac, yes |
| 06:40:47 | fowl | renesac, i ran it in aporia and it locked up my whole system |
| 06:41:35 | renesac | should it give an infinite loop? |
| 06:42:18 | fowl | Skrylar, yea, going that route it is probably best to define eventID(name: static[string]): int and use a counter starting from 0 as your event-id |
| 06:42:33 | fowl | renesac, no, you found a bug |
| 06:43:08 | renesac | \o/ |
| 06:43:11 | renesac | :P |
| 06:43:28 | renesac | workaround for the moment: uint32.high - 100_000 .. uint32.high-1 |
| 06:44:36 | Skrylar | fowl: ultimately i don't want people dealing with events, but some system still has to be worked out |
| 06:44:45 | fowl | i bet thats a codegen problem, incrementing the var (which just rolled to 0) before you check to stop the loop or something |
| 06:44:59 | Skrylar | fowl: i would prefer that people make a set of actions that can be performed, and then the GUI uses those for buttons/hotkeys/etc |
| 06:45:12 | Skrylar | since it centralizes undo/redo actions, tooltips, names, recording logs |
| 06:45:18 | fowl | Skrylar, i found a page on qt's slots/signals, i wonder how much of this depends on their meta-info stuff |
| 06:45:30 | Skrylar | fowl: MOC is a workaround |
| 06:45:59 | * | brson quit (Ping timeout: 240 seconds) |
| 06:46:07 | Skrylar | fowl: basically, boost and clanlib have C++ signal/slots written in pure templates; but Qt has to cover compilers that aren't ideal and MOC lets them get away from relying on the compiler handling template magic |
| 06:46:26 | Skrylar | especially since Qt has been doing it since the 90s when the compilers were really crap |
| 06:47:20 | Skrylar | all though in Nimrod, it might be less than ideal because a signal to an object could make the GC decide to keep the object around |
| 06:48:05 | * | brson joined #nimrod |
| 06:55:23 | renesac | Skrylar, here what I was working: https://gist.github.com/ReneSac/ff983a857dd56209d3bb |
| 07:00:53 | * | grumio2 joined #nimrod |
| 07:06:09 | Skrylar | renesac: exporting unsigned might be a bit of a no-no |
| 07:06:33 | renesac | yeah, I wasn't sure about that either |
| 07:06:41 | renesac | but I thought it would't hurt |
| 07:06:55 | Skrylar | leave out the export line; import is fine though |
| 07:07:02 | fowl | renesac, have you tested your functions shl, shr, or, etc? i'm not sure they will work |
| 07:07:13 | Skrylar | people aren't meant to use unsigned unless they explicitly know what they are doing |
| 07:08:03 | renesac | fowl, I'm calling 'shl', etc, but I don't know are my functions the ones calledhow to test those functions |
| 07:08:25 | Skrylar | I think event hookup is going to be my next focus; I can't continue with the GL-based GUI directly until the bug i reported is fixed, but fiddling with event dispatch i can still do |
| 07:08:25 | renesac | Skrylar, if people are using a bithacks module, they probably want unsigned |
| 07:08:45 | renesac | many functions require unsigned inputs |
| 07:09:32 | renesac | (though I can soften this requirement in quite a few of them) |
| 07:10:00 | fowl | renesac, i think that by using distinct in that you have no way to call it |
| 07:10:36 | renesac | I thought that distinct in this case tells that U and T types can differ |
| 07:11:06 | fowl | no |
| 07:11:14 | fowl | t and u will be the same type actually |
| 07:14:14 | renesac | "Alternatively, the distinct type modifier can be applied to the type class to allow each param matching the type class to bind to a different type." |
| 07:14:37 | renesac | http://build.nimrod-lang.org/docs/manual.html#type-classes |
| 07:15:23 | renesac | though I'm not sure it works inside [], but it surely works as proc `**`(a, b: distinct Matrix): Matrix[a.type.T, a.type.M, b.type.N] = |
| 07:15:33 | renesac | (example given by zahary) |
| 07:19:06 | * | Endy joined #nimrod |
| 07:19:09 | fowl | ah |
| 07:19:20 | fowl | that makes sense |
| 07:19:32 | fowl | i guess it wouldnt be usable the other way |
| 07:23:08 | renesac | going to sleep |
| 07:23:38 | renesac | this module is already usable for me, but latter I will make a proper repository for it |
| 07:48:24 | * | brson quit (Ping timeout: 252 seconds) |
| 07:55:53 | * | rejuvyesh[away] quit (Ping timeout: 245 seconds) |
| 08:07:33 | Skrylar | i wonder how big of a pain it is to overlay cef on sdl |
| 08:13:38 | * | nequitans_ quit (Ping timeout: 240 seconds) |
| 08:24:49 | Araq | renesac: unary ops have higher precedence than binary ops and I think the manual mentions that |
| 08:24:59 | Araq | it's obvious from the grammar anyway :P |
| 08:32:04 | Skrylar | Araq: I broke your compiler again :( |
| 08:32:53 | Araq | I noticed |
| 08:34:01 | Araq | show stopping bug? |
| 08:34:38 | Skrylar | "yes" in that i can't work on that module without a serious workaround; it might be possible to hardcode the binpacker to use ints and cover it up with a typedef until the bug gets fixed |
| 08:34:49 | Skrylar | so probably just severe |
| 08:35:18 | Skrylar | I have no idea why the compiler is getting a nil instead of the type though |
| 08:36:42 | Araq | bug number? |
| 08:38:37 | Skrylar | #1007 |
| 08:41:32 | Araq | tried to rename your 'Set' procs? |
| 08:46:21 | Skrylar | I haven't tried that, no. |
| 08:46:46 | Skrylar | It does still happen when I make no function calls within TryGet though, just using the T type is enough to break it |
| 08:51:39 | Araq | gosh this openCL API is so full of bullshit |
| 08:51:47 | Skrylar | lol |
| 08:51:53 | Skrylar | i've never tried to use opencl |
| 08:51:57 | Araq | and it's in fact one of the better designed C APIs |
| 08:52:22 | Araq | pointers vs arrays, unsigneds, type unsafety everywhere |
| 08:52:40 | Skrylar | C doesn't really have typesafety though |
| 08:53:18 | Skrylar | IIRC if you put GCC in ansi mode it will still try to implicitly cast everything to ints |
| 08:53:41 | Araq | who cares, I'm not using C directly |
| 08:53:46 | Araq | I'm using Nimrod |
| 08:54:05 | Skrylar | In that case, suckass is a macro away from being hidden. </lisp> |
| 08:54:11 | Araq | C is for retarded masochists |
| 08:54:31 | Araq | and should have died decades ago |
| 08:55:16 | * | rejuvyesh[away] joined #nimrod |
| 08:55:30 | fowl | should have died? maybe, but it won't, its going to be around at least until the next leap in computing |
| 08:55:49 | Skrylar | then rust takes over because corporate backing |
| 08:55:52 | Skrylar | a new age of masochism and pain |
| 08:56:03 | Araq | fowl: problem is: that leap has happened 3x already ... |
| 08:56:10 | Araq | and it's still there |
| 08:56:36 | Araq | we really need a 'cOpenArray' which is more forgiving |
| 08:56:39 | fowl | c is the english of programming languages, sure it pisses you off that the past-tense of "run" is "ran" but there nothing you can do about it (because a global cabal of bankers runs the world) |
| 08:57:54 | Skrylar | C++ is the one i have beef with |
| 08:58:02 | Skrylar | straight C is useful in its place |
| 08:58:33 | Skrylar | there haven't been very many languages that fulfill the "readable assembly" goal that ANSI C is supposed to fulfil; most of them (even the 'systems' languages) have mandatory GC for instance |
| 08:58:50 | Skrylar | GCs aren't what you want in the middle of factory control code |
| 08:59:04 | runvnc | Personally I think the main thing holding back software engineering is source code |
| 08:59:08 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 08:59:17 | runvnc | lol |
| 08:59:30 | runvnc | not actually kidding |
| 08:59:36 | Skrylar | howso? i find auxillery means of inputting logic slower |
| 08:59:44 | Skrylar | i've used graph-based and event grid systems |
| 09:00:09 | Skrylar | Inform tries to do it as english but in reality is pigeon english |
| 09:00:25 | runvnc | By that statement I don't mean that there is a popular and practical general alternative to general purpose text-based programming languages |
| 09:00:53 | * | CARAM quit (Remote host closed the connection) |
| 09:01:02 | Skrylar | Smalltalk tried to be a mix of a class browser and source code |
| 09:01:17 | Skrylar | there's been people talk about Source Code In Database to auto-format source blobs for you |
| 09:01:24 | Araq | lets see, the common assembler has a more powerful macro system than C, supports checking for integer overflows, makes coroutines easy, ... hmm |
| 09:01:25 | fowl | Araq, if you could make openarray pass the array length as int it would cover c apis that pass around T*, int for arrays (once this is possible i would ask for another one that flips the order of arguments (like int argc, char**argv)) |
| 09:01:48 | fowl | pass it as cint* |
| 09:02:00 | Araq | I'd say C is a poor "portable assembler" |
| 09:02:15 | Skrylar | i don't think nasm output works on sparc |
| 09:02:27 | Skrylar | :P |
| 09:02:42 | Araq | Skrylar: yet I can easily invent a better portable assembler |
| 09:02:55 | Araq | I don't even need to try hard, it's obvious how to do that |
| 09:03:00 | Skrylar | an Araq version of li.no.lium? |
| 09:03:36 | Skrylar | I found using an assembler more painful just because its extremely unforgiving |
| 09:03:49 | Skrylar | and its easy to end up with a dozen different method call types |
| 09:04:26 | Araq | fowl: I'm thinking of pragma support to nail that |
| 09:04:56 | runvnc | well just one more comment about what I was trying to say, having a specific textual syntax as an underlying representation is limiting. |
| 09:04:58 | Skrylar | I'm not sure if the edge case of dealing with that kind of array merits compiler support personally |
| 09:05:22 | * | ics joined #nimrod |
| 09:05:35 | runvnc | there is only so much that an IDE can do within those constraints |
| 09:06:02 | Skrylar | runvnc: well, how many IDEs are living up to that though? |
| 09:06:12 | runvnc | well, its not even an underlying representation, it is THE representation except for some coloring and code folding or whatever |
| 09:06:15 | Skrylar | the only ones i've seen that really hit the edge of that is maybe SLIME |
| 09:07:05 | Skrylar | slime/emacs and lisp take you to the realm of hitting a key to eval the current statement, preview macro output / optimizer results, and shove code in to a running process |
| 09:07:15 | Skrylar | most of the IDEs *stop* at syntax coloring |
| 09:07:25 | runvnc | my point is that since the paradigm is a particular textual representation that is parsed, it limits the types of interactions and availability of different representations for programs |
| 09:07:31 | runvnc | and this is holding back software engineering |
| 09:07:49 | Skrylar | but are we even hitting those limits with most software? :/ |
| 09:07:53 | runvnc | the representation and interaction with the program is very critical |
| 09:08:08 | runvnc | we are not but it isnt because people aren't writing clever enough text editors skrylar |
| 09:08:15 | runvnc | it is because the paradigm is outdated |
| 09:08:17 | Skrylar | its like arguing for a bigger pixel bit depth than 16-bit, when most paint programs only support basic 12-color |
| 09:08:46 | runvnc | what I am saying is that we are using CGA and they have 3d HD now |
| 09:09:29 | Skrylar | what is the '3d HD' of programming? |
| 09:10:24 | Skrylar | We had image-based systems and people decided they hated those, and those dealt with an interesting set of problems |
| 09:10:38 | runvnc | programs with interactive representations, multiple ways of viewing the underyling program, non-textual representations that are more appropriate for the domains |
| 09:10:56 | Skrylar | so basically a good IDE with flow charts + generators |
| 09:11:03 | runvnc | absolutely not |
| 09:11:17 | Skrylar | "non-textual representations" |
| 09:11:40 | Skrylar | there are some state machine editors that do a very good job at visualizing that particular model and its transitions |
| 09:12:27 | Araq | unhandled exception: SUCCESS [EOpenCL] |
| 09:12:29 | Araq | lol |
| 09:12:34 | Skrylar | welp |
| 09:12:41 | Skrylar | Bugfix: Success is not failure. |
| 09:12:56 | runvnc | how many different types of interactive 2d and 3d representations do you know of skrylar |
| 09:12:56 | runvnc | are there say a half dozen |
| 09:12:56 | runvnc | a dozen |
| 09:12:56 | runvnc | maybe a thousand |
| 09:12:57 | runvnc | certainly there are more general purpose representations that would be useful for various types of programming interactions than you can think of off the top of your head |
| 09:13:09 | runvnc | lol |
| 09:13:53 | Skrylar | I've used a few attempts to replace source code. |
| 09:13:54 | runvnc | sure state machine editors, and all of the different ideas you had, and more general ones, as well as various different options for mapping to alternate syntaxes |
| 09:13:58 | Skrylar | I wouldn't say they are universally better. |
| 09:14:21 | Skrylar | Stuff like the RM2K event editor is great for sketching out NPC events, sure, but they're a nightmare for maintaining/growing |
| 09:14:27 | runvnc | of course I am not saying that any particular attempts to replace source code that you have used are universally better than text |
| 09:14:48 | Skrylar | what you want in some of those situations are closer to things like the Elder Scrolls Construction Kit which is essentially a database editor |
| 09:15:00 | runvnc | if you listen to what I am saying, it is quite clear that I am not advocating for any particular visual representation |
| 09:15:14 | Skrylar | I'm listening, but I haven't seen anything specific recommended |
| 09:15:40 | Skrylar | interactive, multiple ways and non-textual aren't really descriptive; all I can say is thats the kind of thing SCID was supposed to solve |
| 09:15:59 | Skrylar | you store the AST in a database, and the SCID client parlays that in to something meaningful |
| 09:16:02 | runvnc | I am specifically recommending that we create a new paradigm that redefines programming in a way that transcends single-syntax textual non-interactive representation |
| 09:16:39 | Skrylar | I wouldn't mind poking at a SCID system for nimrod, but that's not tool friendly (e.g. the database isn't git-able) |
| 09:16:46 | runvnc | ok skrylar something along the lines of this scid thing is the direction I think programming should go |
| 09:17:25 | runvnc | there is nothing about this general approach that precludes a textual or otherwise tool-friendly serialization |
| 09:17:45 | Skrylar | http://c2.com/cgi/wiki?SourceCodeInDatabase theres also a mention on wikipedia of an IBM attempt |
| 09:18:05 | runvnc | intentional software has a domain workbench with a projection editor |
| 09:18:09 | Skrylar | problem is that SCID is a move back in to image-based development which people for some reason don't want |
| 09:18:13 | runvnc | I think those types of tools are a step in the right direction |
| 09:18:39 | runvnc | I do not necessarily think those specific tools are practical for general purpose programming or that they have successfully created this new paradigm |
| 09:18:46 | Skrylar | you also have to have a stable storage AST |
| 09:18:54 | runvnc | well just to clarify |
| 09:19:09 | runvnc | with this new tool, I would definitely want to be able to represent program fragments using text |
| 09:19:25 | runvnc | and I envision that would be an integral aspect of program development still |
| 09:19:57 | runvnc | the problem is the definition of programming |
| 09:20:06 | runvnc | programmers do not use graphical user-friendly programs |
| 09:20:10 | runvnc | those programs are for users |
| 09:20:20 | runvnc | programmers write cryptic ascii text |
| 09:20:22 | fowl | seen this? http://peaker.github.io/lamdu/ |
| 09:20:29 | runvnc | that is the beginning and end of the definition of programming |
| 09:20:34 | fowl | you type into AST |
| 09:21:13 | runvnc | wow very interesting thanks no I had not seen that |
| 09:22:41 | runvnc | in fact, if the text you type into the computer overall isn't cryptic enough, you don't get credit for being a programmer |
| 09:22:58 | runvnc | its a 12-year-old's mentality |
| 09:23:01 | fowl | if its not cryptic then you have no job security |
| 09:23:17 | Skrylar | there is that |
| 09:23:37 | Skrylar | "good code = you're unimportant" and launch day = fired day probably doesn't convey a sense that we should be more productive |
| 09:23:57 | Skrylar | which is probably why tiny groups like Delphi and friends; they aren't writing against a boss and their time is more vaulable |
| 09:24:28 | runvnc | oh actually I did see that lamdu thing, just totallly forgot I had seen that particular one |
| 09:25:19 | Skrylar | I like the idea of an outlining editor |
| 09:25:23 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 09:25:25 | Skrylar | but i like outliners :( |
| 09:25:58 | Skrylar | especially with clones, since you can have the bug references and example code links grouped together |
| 09:26:39 | * | ics joined #nimrod |
| 09:27:17 | Skrylar | anyhow, i should probably try to minimize the segfault related to generics |
| 09:27:19 | * | grumio2 quit (Quit: Lost terminal) |
| 09:27:23 | Skrylar | zah was asking about it |
| 09:28:50 | Araq | Skrylar: yeah plase do so, I need to go |
| 09:28:52 | Araq | bbl |
| 09:29:24 | * | clovis joined #nimrod |
| 09:35:06 | * | grumio2 joined #nimrod |
| 09:35:44 | Skrylar | wut |
| 09:35:50 | Skrylar | I merged the files together and it works |
| 09:36:00 | Skrylar | So its a module boundary issue. Yay. |
| 09:37:17 | grumio2 | I have this window open in case I need to ask a question. But all your high-level discussion intimidates me to RTFM and solve my own problems. |
| 09:37:47 | fowl | lol |
| 09:37:49 | Skrylar | :( |
| 09:38:01 | fowl | grumio2, all joking aside the manual is pretty comprehensive, its a good resource |
| 09:38:20 | grumio2 | It's a good thing haha. It's worked so far. Yeah the manual is great. |
| 09:38:53 | * | [1]Endy joined #nimrod |
| 09:40:55 | clovis | Ok then, perhaps I should pose a question |
| 09:41:24 | clovis | What's the cost of exceptions that are not raised? |
| 09:41:54 | clovis | Most C++ compilers have zero-cost exceptions in the non-exceptional case. |
| 09:42:18 | * | Endy quit (Ping timeout: 240 seconds) |
| 09:42:18 | * | [1]Endy is now known as Endy |
| 09:43:42 | * | lanior quit (Quit: Page closed) |
| 09:43:53 | * | CARAM_ joined #nimrod |
| 09:44:08 | * | CARAM_ quit (Client Quit) |
| 09:44:27 | fowl | clovis, i guess it would be the cost of the allocation and subsequent garbage collection |
| 09:45:21 | clovis | fowl, hm. Is that a one-time cost or is it for each entered try-statement? |
| 09:45:37 | clovis | Suppose I call a try-statement in a loop.. |
| 09:47:12 | fowl | well |
| 09:47:26 | fowl | i doubt you would allocate an exception if you arent raising it |
| 09:47:33 | runvnc | clovis you know you can look at the generated c code in the nimcache folder right? |
| 09:48:11 | clovis | runvnc, I should do that. |
| 09:50:21 | runvnc | heh easier to just ask in here.. not for the faint of heart |
| 09:52:09 | grumio2 | lol. runvnc, see my earlier message |
| 09:52:38 | runvnc | heh |
| 10:01:47 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 10:02:21 | * | ics joined #nimrod |
| 10:02:28 | * | reloc0 joined #nimrod |
| 10:05:58 | clovis | Hm, unfortunatly there seems to be a cost for entering the try even though en exception isn't raised. |
| 10:06:32 | clovis | The setjmp C-function and some other stuff has to be set up. |
| 10:07:29 | clovis | This means that using exceptions in a loop will have a negative impact on performance |
| 10:11:27 | Skrylar | zahary: zahary_office: okay, minimized the code needed to cause the crash |
| 10:11:43 | Skrylar | Its definitely an issue with cross-module generics |
| 10:13:22 | zahary | Skrylar: put a link in the issue |
| 10:17:47 | clovis | Good news! If you compile to cpp instead of C then C++ exceptions are used instead of setjmp/longjmp. This means that the code will probably run faster |
| 10:18:42 | runvnc | clovis did you test what the performance impact actually is with the try in the loop |
| 10:18:49 | runvnc | like use a high resolution timer |
| 10:18:52 | runvnc | and do a simple test |
| 10:19:06 | clovis | No, there was a linker error for me. Perhaps c++ isn't fully supported yet |
| 10:19:14 | runvnc | try it with c |
| 10:19:14 | clovis | I only have Clang installed |
| 10:19:18 | runvnc | measure the performance impact |
| 10:19:42 | Skrylar | zahary: posted |
| 10:20:10 | runvnc | I would not assume that issue is an important optimization |
| 10:20:16 | fowl | clovis, how do you know c++ doesnt use set/longjmp? |
| 10:20:18 | runvnc | what are you optimizing clovis |
| 10:20:36 | runvnc | also clovis nimrod has flags for optimization |
| 10:20:37 | clovis | fowl. I know that LLVM has zero-cost exceptions |
| 10:20:58 | clovis | runvnc, right. I shall recompile the C-version with optimizations on |
| 10:21:10 | runvnc | but you would need to profile it for a specific use case |
| 10:21:19 | clovis | Of course |
| 10:21:21 | runvnc | to see whether that is actually an important issue for your optimization |
| 10:21:33 | runvnc | seems silly to assume its a problem |
| 10:21:33 | clovis | But setjmp/longjmp is always slower |
| 10:21:53 | clovis | Well, exceptions are used everywhere in nimrod |
| 10:22:03 | zahary | clovis: C++ should be supported, but we test it more rarely |
| 10:22:10 | zahary | if something doesn't work for you, post a bug |
| 10:22:18 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 10:22:58 | clovis | zahary. I think I read somewhere on the website that osx was not fully supported |
| 10:23:06 | zahary | the most typical linker error is that the C++ runtime is not linked - check if you are compiling with clang++ |
| 10:23:17 | clovis | I only have clang installed |
| 10:23:17 | zahary | I'm using osx most of the time |
| 10:23:20 | clovis | no gcc |
| 10:23:46 | zahary | same here |
| 10:23:51 | clovis | Hm. |
| 10:25:06 | clovis | I just installed nimrod from trunk source on github a couple of days ago, following the instructions |
| 10:25:17 | zahary | try adding this to the command linke —cc:clang++ |
| 10:25:29 | zahary | * line * |
| 10:26:53 | fowl | clovis, you are using the devel branch right? |
| 10:27:06 | clovis | fowl, yep |
| 10:28:23 | runvnc | clovis what is the exact linker error you received |
| 10:28:28 | * | Matthias247 joined #nimrod |
| 10:30:15 | clovis | runvnc, http://pastebin.com/pSpWJ0RU |
| 10:31:48 | zahary | yes, this is the error I was referring to |
| 10:32:27 | clovis | zahary. I see |
| 10:32:29 | zahary | didn't my suggestion fix it? |
| 10:32:56 | clovis | zahary, is that command line option for nimrod compiler? |
| 10:33:20 | zahary | yes, it can also go into your project or user config file |
| 10:33:31 | zahary | cc: "clang++" |
| 10:34:18 | zahary | there must be a problem with the default config and I'll take a look a bit later |
| 10:34:36 | fowl | so i tried doing ./koch boot -d:debug -o:nimrodd and that worked fine but the result binary was left in compiler/ not moved to bin |
| 10:35:15 | fowl | at least it worked though and now i have a debug build on hand |
| 10:35:59 | clovis | zahary. I'm probably a bit dense but I don't understand where to put the command line option. This didn't work: nimrod cpp -—cc:clang++ x008_exceptions.nim |
| 10:38:51 | zahary | I've reproduced the issue here after I deleted my user config - I can just wait for me to push a fix today |
| 10:39:21 | zahary | *you can* |
| 10:39:29 | clovis | zahary, thanks |
| 10:40:57 | clovis | I can do some measurements of the possible performance impact then of using exceptions in C vs C++ |
| 10:43:44 | clovis | I'm not aware of any implementation technique other than setjmp/longjmp in C. The C++ compiler does the corresponding at compile-time as well as a few allocations when the program is started. But not upon each time a try-block is entered. |
| 10:46:53 | * | ics joined #nimrod |
| 10:48:58 | Skrylar | the way the C++ compiler does it depends on how it feels |
| 10:49:08 | Matthias247 | clovis: afaik there are 2 common approaches. The one with setjmp/longjmp and another which generates alternate program flow pathes for each exception and stores them in unwind tables |
| 10:49:16 | Skrylar | on some platforms theres a side chain that gets appended to every time you enter a try block, so its not *that* different from setjmps |
| 10:52:58 | * | grumio2 quit (Read error: Connection reset by peer) |
| 10:53:25 | * | grumio2 joined #nimrod |
| 10:54:08 | Matthias247 | I've heard about up to a 25% performance hit from using exceptions and many (embedded) projects don't allow them therefore. But don't know how much truth is in there |
| 10:56:22 | clovis | Matthias247, some extra code has to be generated for unwinding that may take up some precious memory/cache |
| 10:58:16 | clovis | Cache should of course not be a problem. That (exceptional-) code would be placed somewhere off the hot code |
| 10:59:23 | fowl | i wonder what the least efficient way to do it is |
| 10:59:57 | clovis | fowl. return values perhaps |
| 11:00:26 | clovis | They have to be propagated up from all calls and checked at each level |
| 11:00:51 | clovis | Exceptions are great because you optimise for the non-exceptional case |
| 11:01:15 | Skrylar | you could always benchmark it |
| 11:01:40 | clovis | Skrylar. Yep. but first pick the low-haning fruit |
| 11:01:40 | Skrylar | i pasted the OnTime benchmark here where they wrote their own setjmp and found that it was more efficient than try/catch in C++, but that was done in '01 |
| 11:02:48 | clovis | On windows, 32bit? |
| 11:03:33 | clovis | VC++ 32bit does exceptions the bad way |
| 11:04:00 | Skrylar | http://www.on-time.com/ddj0011.htm here's their old article |
| 11:07:11 | Matthias247 | the mentioned projects use propagated error codes of course because they seem to be faster than exceptions for them and it's the only way you can do it without exceptions |
| 11:07:41 | Matthias247 | as far as I can see: Zero-cost-exceptions > error codes > classical exceptions |
| 11:09:36 | * | runvnc quit (Quit: Leaving) |
| 11:10:35 | clovis | Here's another article/blog post: http://mortoray.com/2013/09/12/the-true-cost-of-zero-cost-exceptions/ |
| 11:10:53 | clovis | Have to go. See you later |
| 11:10:54 | * | clovis quit (Quit: clovis) |
| 11:25:45 | * | EXetoC joined #nimrod |
| 11:32:15 | * | jbe joined #nimrod |
| 11:38:33 | dom96 | good morning |
| 11:41:12 | jbe | hello folks |
| 11:41:19 | dom96 | hi jbe |
| 11:42:11 | jbe | im trying to write a macro that takes an nkkCall expression as its parameter, and returns a statement list that uses the string representation of the name of the called proc/templ/whatever. I could not figure it out from the docs, am i missing something? |
| 11:42:55 | jbe | i mean, how do i get the name that was called? |
| 11:43:30 | dom96 | Use echo(treeRepr(node)) to see the AST node that was passed to the macro. |
| 11:43:39 | dom96 | You should be able to figure out how to get the name from that. |
| 11:43:51 | jbe | ok, thx |
| 11:44:31 | jbe | i'm trying to implement a haml-esque template syntax |
| 11:51:52 | fowl | you might use callsite() |
| 12:03:31 | dom96 | EXetoC: yo, you there? |
| 12:06:59 | EXetoC | dom96: yes |
| 12:07:37 | dom96 | EXetoC: Have you tested your Jester PR with the tests in jester's tests dir? |
| 12:13:07 | EXetoC | dom96: oh. no I haven't. that's an easy fix. so what were the considerations? did you think that maybe performance would be an issue in some cases? |
| 12:13:45 | EXetoC | or was it something else? |
| 12:14:20 | dom96 | Just wondering whether there are any hidden issues. |
| 12:14:31 | dom96 | Like code breaking. |
| 12:14:47 | dom96 | Can you test it for me? |
| 12:15:38 | EXetoC | the tests run at least, and I did use my patch for my own project, just that I didn't use that particular feature so I missed that |
| 12:16:12 | dom96 | well as long as they run then it's fine |
| 12:16:25 | EXetoC | I'll run the programs again anyway |
| 12:16:30 | dom96 | i'll revert it if bad things happen |
| 12:16:35 | NimBot | dom96/jester master aae03df EXetoC [+0 ±1 -0]: {.nimcall.} -> {.closure.} |
| 12:16:35 | NimBot | dom96/jester master dc6fbb5 Dominik Picheta [+0 ±1 -0]: Merge pull request #10 from EXetoC/proc-type-fix... 2 more lines |
| 12:17:00 | EXetoC | I was just about to update the branch |
| 12:17:08 | dom96 | with what? |
| 12:17:45 | EXetoC | dom96: with the missing instance of 'closure' |
| 12:18:14 | dom96 | huh. Where is this missing instance? |
| 12:18:15 | Skrylar | dom96: i was working on the GL-GUI earlier and.. broke the compiler again :F |
| 12:18:34 | EXetoC | j.routes.add... asynctest.nim |
| 12:19:36 | dom96 | You don't add routes manually. |
| 12:19:44 | dom96 | Where do you see that in asynctest.nim? |
| 12:21:04 | EXetoC | dom96: "jester.nim(489, 12) Error: type mismatch: got (seq[tuple[meth: TReqMeth, m: PMatch, c: TCallback]], tuple[TReqMeth, PMatch, proc (var TRequest, PResponse)])" |
| 12:21:56 | dom96 | You said the tests ran... |
| 12:23:59 | dom96 | It's ok, i'll fix it. |
| 12:24:15 | EXetoC | I wasn't being very clear |
| 12:24:19 | EXetoC | ok |
| 12:24:22 | * | BitPuffin joined #nimrod |
| 12:25:34 | dom96 | BitPuffin: We should play Civ V |
| 12:25:58 | NimBot | dom96/jester master d71898d Dominik Picheta [+0 ±1 -0]: Adds {.closure.} to getRe. |
| 12:31:48 | jbe | now i am getting a "not unused" error when i try to add more than one call to the statement list.. ideas? |
| 12:32:12 | * | Vendethiel- quit (Quit: q+) |
| 12:33:49 | jbe | wait, it must be a compiler bug.. adding a comment does the same |
| 12:34:13 | jbe | and that is not devel anyway |
| 12:37:10 | EXetoC | this might be relevant https://github.com/Araq/Nimrod/issues/889 |
| 12:37:22 | EXetoC | it's in devel. master was last updated about 2 months ago |
| 12:40:42 | * | q66 joined #nimrod |
| 12:40:42 | * | q66 quit (Changing host) |
| 12:40:42 | * | q66 joined #nimrod |
| 12:42:36 | dom96 | jbe: gist your code and the error message |
| 12:43:36 | jbe | dom96: it's probably the same bug. i'm trying devel first |
| 12:43:42 | dom96 | alright |
| 12:45:57 | * | darkf quit (Quit: Leaving) |
| 13:11:05 | * | hetman joined #nimrod |
| 13:14:23 | hetman | hi |
| 13:15:18 | hetman | I was wondering if macros allowed a way to achieve something similar to the template "bind" statement |
| 13:16:24 | dom96 | hello hetman |
| 13:16:34 | dom96 | I think there is a bindSym proc in the macros module which is similar. |
| 13:19:01 | jbe | how can i raise a compile time error from a macro? |
| 13:19:55 | hetman | awesome, I'll go take a look at that |
| 13:20:03 | jbe | i got it to work btw |
| 13:21:37 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 13:22:30 | dom96 | jbe: error("message") IIRC |
| 13:22:50 | EXetoC | dom96: is BitPuffin terrible at reading stuff before quitting or what? :p |
| 13:23:03 | jbe | ok |
| 13:31:16 | * | foodoo joined #nimrod |
| 13:36:52 | * | io2 joined #nimrod |
| 13:40:33 | Araq | hmm if we change the pragma's syntax we could use [] instead, this might cause less problems when we support braces for control flow. Not sure we want to support braces though. |
| 13:41:07 | * | hetman quit (Quit: Page closed) |
| 13:43:42 | dom96 | Araq: Nooo. Don't change the syntax. :( |
| 13:45:14 | Araq | changing things is good for marketing though |
| 13:45:38 | EXetoC | just let editors deal with alternative representations |
| 13:46:13 | Araq | EXetoC: nah this argument only holds when filwit makes it |
| 13:46:16 | jbe | oh god braces nooooo |
| 13:46:39 | Araq | "looks like shit but not if I add this particular piece of syntax highlighting..." |
| 13:47:33 | fowl | i think a braces grammar is a good idea |
| 13:47:50 | EXetoC | as in brackets everywhere, for the few people who really want that above anything |
| 13:47:50 | fowl | just keep it separate from the normal syntax |
| 13:49:10 | EXetoC | make it into an API or something |
| 13:49:30 | Araq | EXetoC: it already is an "API" in syntaxes.nim |
| 13:49:40 | dom96 | Do you know of any people that would use Nimrod if it had a braces syntax? |
| 13:49:48 | EXetoC | there you go :p |
| 13:50:40 | fowl | dom96, i know of people that would have to come up with a better reason to not use nimrod if it had braces |
| 13:50:54 | * | guth_ joined #nimrod |
| 13:51:32 | EXetoC | dom96: but that doesn't matter if you delegate that responsibility to editors |
| 13:51:40 | dom96 | I doubt we would convince those people. |
| 13:51:49 | fowl | yea |
| 13:51:51 | dom96 | They would just say "well, it still sucks because now you have two syntaxes" |
| 13:52:46 | EXetoC | even if it's up to the user to render the source code differently? |
| 13:52:48 | fowl | serious programmers dont place syntax on such a high pedestal anyways |
| 13:52:52 | EXetoC | maybe some people will complain still, who knows |
| 13:53:46 | dom96 | Well I am against this. |
| 13:53:52 | dom96 | Just so we're clear. |
| 13:54:36 | dom96 | There are more important things to do than worry about syntax. |
| 13:56:19 | Araq | hi guth_ welcome |
| 14:21:00 | jbe | i dont know if something like this exists already, but i tried hacking together a basic dsl for creating html and xml templates |
| 14:21:02 | jbe | https://github.com/jbe/niml |
| 14:21:24 | Araq | dude, watch my talk |
| 14:21:36 | jbe | i did |
| 14:22:00 | jbe | well, parts at least |
| 14:22:36 | Araq | yeah, 25 minutes is way too long to watch |
| 14:22:48 | Araq | more seriously "Under the hood, a NIML template is simply a proc that writes to a stream or socket, or anything else that has an implementation of write." |
| 14:22:50 | dom96 | what do all these operators mean? % vs. ~ for example. |
| 14:23:14 | jbe | % is tag with body, ~ is self-closing |
| 14:23:24 | Araq | you should call '&=' instead of 'write' |
| 14:23:31 | jbe | i would have liked % for both |
| 14:23:39 | jbe | Araq: why? |
| 14:23:57 | Araq | because it's the upcoming 'sink' operator |
| 14:24:27 | jbe | *scratches head |
| 14:25:05 | dom96 | Can you get a string out of it? |
| 14:26:11 | jbe | dom96: simple enough to implement at least |
| 14:26:24 | * | foodoo quit (Remote host closed the connection) |
| 14:26:50 | jbe | i used write as the base case for max efficiency |
| 14:27:50 | Araq | yeah and it's fine |
| 14:27:56 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 14:28:40 | jbe | i could write a "capture" template, that returns the wrapped niml as a string |
| 14:29:14 | jbe | i'm not sure how unbreakable the syntax is though |
| 14:30:59 | Araq | proc write(a: var string, b: string) = a.add(b) # problem solved |
| 14:38:09 | renesac | Araq, I was unable to find a mention to that in the manual |
| 14:39:17 | renesac | thus the bug report |
| 14:40:09 | Araq | yeah well, guess what I'll add it to the manual and close the bug |
| 14:42:29 | renesac | and I also found strange this paragraph about unary operators: "If the operator's relevant character is @ it is a sigil-like operator which binds stronger than a primarySuffix: @x.abc is parsed as (@x).abc whereas $x.abc is parsed as $(x.abc)." |
| 14:43:15 | renesac | and in the table @ has precedence of 1 and $ of 9 |
| 14:43:48 | renesac | I'm not sure if I'm misunderstanding things |
| 14:45:15 | Araq | the precedences are about *binary* operators |
| 14:45:28 | Araq | the sentence you quote is concerned with unary operators |
| 14:46:37 | OrionPK | mornin |
| 14:46:55 | jbe | Araq: did i understand correctly that something like stdout &= "str" will be valid in a future version? |
| 14:47:12 | Araq | jbe: yes |
| 14:47:27 | renesac | right, so this paragraph tells us that @ is a special case among unary operators? |
| 14:47:30 | jbe | great |
| 14:47:49 | Araq | renesac: correct |
| 14:48:43 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 14:48:45 | renesac | ok, now things make sense |
| 14:48:47 | renesac | :) |
| 14:53:32 | * | nequitans_ joined #nimrod |
| 15:07:10 | * | nequitans_ quit (Remote host closed the connection) |
| 15:08:08 | * | guth_ quit (Ping timeout: 245 seconds) |
| 15:17:35 | fowl | Skrylar, you around? |
| 15:28:22 | * | clovis joined #nimrod |
| 15:37:34 | fowl | signals implementation: https://gist.github.com/fowlmouth/9584728 |
| 15:38:38 | fowl | needs more pizazz |
| 15:39:09 | EXetoC | mmh pizza |
| 15:40:02 | jbe | dom96: i added string output to the niml example, using the &= operator and a shallow copy internally, so i guess it might work with jester now. i'd be happy to find a way to get rid of the ~operator though |
| 15:44:46 | EXetoC | fowl: gonna test it out in a Qt clone? |
| 15:48:26 | fowl | im going to try it with my entity system |
| 15:50:28 | fowl | how to add arguments... |
| 15:54:28 | EXetoC | fowl: the boost way ofc |
| 15:55:15 | EXetoC | A macro perhaps, but type variadics would be nice |
| 15:55:18 | fowl | i didnt look at boost |
| 15:56:00 | fowl | EXetoC, the problem is i dont want to create 9 generic types for up to 9 arguments |
| 15:57:08 | EXetoC | yeah that's what boost does |
| 15:57:10 | fowl | boost::signal<void ()> sig; |
| 15:57:10 | fowl | i dont think this is possible |
| 15:57:15 | EXetoC | or maybe they don't anymore because of C++11 |
| 15:59:03 | * | grumio2 quit (Quit: Leaving) |
| 15:59:22 | fowl | oh wow i can do var x: tx[proc: int] |
| 16:00:31 | EXetoC | right, proc type class |
| 16:01:11 | EXetoC | do you need return type reflection? |
| 16:01:55 | fowl | no |
| 16:02:05 | fowl | i dont think return variables should be allowed |
| 16:03:10 | EXetoC | I just realized that it's never done that way |
| 16:04:32 | EXetoC | except when it is |
| 16:04:36 | EXetoC | "boost::signal<float (float x, float y)> sig" |
| 16:04:42 | fowl | if you need to return something you should pass var seq[result-type] as an argument |
| 16:06:14 | dom96 | Now that we have a proper asyncio do you guys think we still need async support in the new 'net' module (which will replace the sockets module)? |
| 16:07:30 | EXetoC | returning an actual value does indeed seem pretty obscure |
| 16:07:46 | renesac | do we have any function to read/write bits (not bytes)? |
| 16:08:09 | renesac | I searched in the stream module and haven't found any |
| 16:08:51 | EXetoC | dom96: people can just use those two together, so I guess not |
| 16:10:28 | dom96 | Well, you will likely use one or the other. |
| 16:11:22 | renesac | fowl, I don't really know how this interface works, but return values are usually nicer, because type inference and not needing to declare a variable in a separate line |
| 16:11:37 | EXetoC | dom96: why doesn't that module just provide the core functionality that other modules can then use? |
| 16:11:56 | renesac | just my 2 cents tossed in the dark |
| 16:12:38 | EXetoC | renesac: I doubt it. just deal with int8 or bool |
| 16:13:15 | * | vendethiel joined #nimrod |
| 16:13:54 | renesac | for bool, return values are also nicer because you can use it directly inside a if clause, for example |
| 16:14:22 | EXetoC | renesac: but it seems really strange for something like a signal |
| 16:14:24 | renesac | but as I said, I don't know this interface or the way it is usually used |
| 16:14:43 | renesac | right... |
| 16:15:07 | dom96 | EXetoC: It will, but this functionality will be for sync sockets only. |
| 16:15:17 | dom96 | The async stuff is too tightly bound to the dispatcher. |
| 16:15:47 | fowl | renesac, how do you make sense of the value some connected slot returns? |
| 16:15:52 | dom96 | Some functions will be common though |
| 16:15:55 | dom96 | anyway brb |
| 16:16:37 | * | clovis quit (Quit: clovis) |
| 16:17:02 | renesac | I have no idea, but from what you are saying, it seems like return values are indeed a bad idea |
| 16:17:20 | renesac | sorry for butting in |
| 16:17:29 | fowl | its cool |
| 16:17:59 | renesac | I need to learn QT some day |
| 16:18:30 | fowl | thats the problem though, you have a bunch of connected components returning numbers and nothing to make sense of them, the only solution i can think of is to disallow return types, make the developer pass result: var seq[int] as a parameter, the connecting objects should fill up the result seq |
| 16:18:47 | EXetoC | dom96: so it's tightly coupled with sockets? |
| 16:19:50 | renesac | hum, so a seq[] organizes the result? |
| 16:20:45 | EXetoC | is that common? |
| 16:21:11 | fowl | renesac, its a container to catch the result from any connected component, what you want to do with the results is unknown to me |
| 16:21:13 | * | nolan_d left #nimrod (#nimrod) |
| 16:22:03 | fowl | renesac, as an example, in my component systems i usually have a calculateBB message that different components (physics, sprite) will use to calculate the bounding box |
| 16:25:57 | renesac | I don't really understood, but ok |
| 16:26:09 | renesac | now it seems I need to write a bit writing routine |
| 16:27:20 | EXetoC | so what's wrong with the types that I mentioned? |
| 16:30:25 | fowl | ? |
| 16:37:43 | * | nolan_d joined #nimrod |
| 16:40:46 | * | foodoo joined #nimrod |
| 16:42:32 | * | Mat3 joined #nimrod |
| 16:42:39 | Mat3 | hello |
| 16:55:27 | dom96 | EXetoC: It's tightly coupled with the dispatcher because of the way that IOCP works |
| 17:02:34 | dom96 | I then emulate that with epoll |
| 17:13:40 | * | rveach_ joined #nimrod |
| 17:14:24 | dom96 | hi rveach_ |
| 17:15:05 | rveach_ | hey |
| 17:27:03 | foodoo | proc recv(socket: TSocket; data: var string; size: int; timeout = - 1): int |
| 17:27:13 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 17:27:30 | * | vendethiel joined #nimrod |
| 17:27:57 | foodoo | From the sockets module. Has the string to be initialized to length =size? |
| 17:28:30 | dom96 | No, it just has to be initialised. |
| 17:28:33 | dom96 | var data = "" |
| 17:29:14 | foodoo | works. Thanks :) I had var mystring : string #before |
| 17:39:02 | foodoo | the keyword ̀pass ̀ in Python should be translated to ̀nil ̀ in Nimrod, correct? |
| 17:41:08 | Araq | foodoo: not anymore, it's an empty discard now |
| 17:42:53 | foodoo | So what would you write now instead of nil? Or does Nimrod allow empty blocks? |
| 17:47:19 | OrionPK | discard |
| 17:49:18 | foodoo | thanks |
| 17:50:32 | Mat3 | I think there exist no wrapper for the Gee library, right ? |
| 17:59:58 | * | brson joined #nimrod |
| 18:04:33 | Araq | Mat3: right |
| 18:09:04 | Mat3 | hi Araq |
| 18:21:09 | * | clovis joined #nimrod |
| 18:23:00 | * | Matthias247 joined #nimrod |
| 18:33:30 | foodoo | Araq: Out of curiosity: Did you consider Haskell-style function call syntax? Nimrod currently has a call syntax like this: fun param1, param2, param3. In Haskell you can call the function without the commas. |
| 18:34:32 | Araq | haskell is brutal to read even with practice |
| 18:34:41 | Araq | ymmv of course |
| 18:35:38 | * | Mat3 prefering Standard ML syntax |
| 18:35:54 | foodoo | Is ML similar to Haskell in that regard? |
| 18:36:25 | Mat3 | of course not in my opinion |
| 18:47:34 | Mat3 | with one exception: functional concatenation |
| 18:47:42 | Mat3 | you can write for example: |
| 18:48:10 | Mat3 | fun fib (0 | 1) = 1 |
| 18:48:36 | Mat3 | | fib n = fib (n-1) + fib (n-2) |
| 18:49:16 | Mat3 | and concatenate without needed closures?: |
| 18:50:15 | Mat3 | val res = par fib 42 |
| 18:50:24 | dom96 | I do like partial function application |
| 18:50:35 | dom96 | Haskell's syntax makes that very natural. |
| 18:55:10 | Mat3 | n < 2 | 1 :f n > 1 | n 1 - n 2 - + tail :g f g :fib <- like these style |
| 18:56:21 | Matthias247 | absolutely natural ;) |
| 18:56:49 | Matthias247 | (or absolutely unreadable?) |
| 19:00:17 | foodoo | You can write ugly code in any language |
| 19:00:51 | Mat3 | f(n) := n < 2: 1; g(n) := n > 1: tail [(n - 1) + (n - 2)]; fib(n) := f(g (n)) <- the same, only in infix notation, only with more noise and unneeded parentess |
| 19:01:31 | Mat3 | or in ML: |
| 19:02:25 | Mat3 | fun fib (0 | 1) = 1 | spawn (fib (n-1) + fib (n-2) |
| 19:02:49 | Mat3 | ) |
| 19:05:46 | foodoo | http://pastebin.com/8hNRnhWw would be naive Haskell |
| 19:06:17 | Mat3 | it's all about habit and unease in front of the unfamiliar - that's my point |
| 19:08:51 | NimBot | Araq/Nimrod devel 1c065b3 Zahary Karadjov [+0 ±1 -0]: grammar fix: allow free-standing expressions such as type(foo) is bar |
| 19:08:51 | NimBot | Araq/Nimrod devel e8a7366 Zahary Karadjov [+0 ±2 -0]: allow multi-line expressions using the dot operator... 10 more lines |
| 19:08:51 | NimBot | Araq/Nimrod devel 40d9443 Zahary Karadjov [+1 ±5 -0]: fix #715 again... 2 more lines |
| 19:08:51 | NimBot | Araq/Nimrod devel ff1c6d1 Zahary Karadjov [+0 ±3 -0]: fix #1001 |
| 19:08:51 | NimBot | 8 more commits. |
| 19:11:27 | Mat3 | n 2 < | 1; n 1 - n 2 - + tail :fib (that's a shorter defination which does the same) |
| 19:15:32 | Mat3 | anyhow, are there plans for a SIMD library ? |
| 19:20:57 | EXetoC | I think someone was messing about with some GCC intrinsics before |
| 19:25:48 | foodoo | The nimrod compiler says that the module ̀ssl̀̀ ̀ is deprecated. Which other module should be used instead? (The documentation of the ssl module doesn't say it's deprecated) |
| 19:26:18 | renesac | Mat3, https://gist.github.com/PhilipWitte/9316566 |
| 19:26:33 | * | rveach_ quit (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) |
| 19:28:14 | dom96 | foodoo: The sockets module supports ssl |
| 19:30:37 | foodoo | dom96: Thanks. Which function do I need to use to create an ssl socket? Is it also socket()? |
| 19:30:46 | dom96 | wrapSocket() |
| 19:31:48 | foodoo | That's not in the documentation |
| 19:32:48 | dom96 | Yeah, I guess the doc gen doesn't define 'ssl' |
| 19:33:18 | dom96 | https://github.com/Araq/Nimrod/blob/devel/lib/pure/sockets.nim#L319 |
| 19:33:59 | foodoo | Thanks. Should I consider the HTML documentation to be outdated? |
| 19:34:25 | dom96 | No, this is a bug. |
| 19:34:36 | dom96 | should only affect ssl stuff |
| 19:34:48 | dom96 | but check the date on the docs to be sure |
| 19:36:44 | Mat3 | renesac: thanks |
| 19:37:48 | renesac | it would be cool if someone made a full fledged nimrod wrapper, though |
| 19:37:59 | renesac | for SIMD stuff |
| 19:38:23 | Mat3 | I take it on my list |
| 19:40:09 | Mat3 | however, I am skeptical about the approach. Will this GCC extension work with other compilers (clang) ? |
| 19:40:41 | Araq | I think so, clang is quite compatible with gcc |
| 19:41:08 | Araq | mvsc is different of course |
| 19:44:39 | NimBot | Araq/Nimrod devel 14aee49 Zahary Karadjov [+0 ±1 -0]: fix #1007 |
| 19:45:13 | Araq | Skrylar: zahary is unstoppable :-) |
| 19:46:06 | zahary | :) such a short weekend |
| 19:46:24 | Mat3 | ok, an alternative would be using 64-bit integers: $01AC3E100FFFFF30 + 0000001000000020 for example (32 bit SIMD addition) |
| 19:46:46 | dom96 | Take tomorrow off work, it's St. Pats day in Ireland |
| 19:46:54 | Mat3 | this approach is flexible and compiler independent |
| 19:47:18 | Mat3 | or better library independent |
| 19:49:40 | Araq | Mat3: I don't think think this works for all the suff that SIMD supports |
| 19:54:06 | Mat3 | yes, it does not work well for floating point SIMD calculations, but for fixpoint and integer |
| 19:54:09 | Mat3 | ones |
| 19:57:03 | Mat3 | ciao |
| 19:57:09 | Araq | good night |
| 19:57:16 | foodoo | gn8 |
| 19:57:21 | * | Mat3 quit (Quit: Verlassend) |
| 20:00:34 | * | jbe quit (Quit: Leaving) |
| 20:05:19 | * | rejuvyesh[away] quit (Ping timeout: 264 seconds) |
| 20:11:36 | * | hasgfbv joined #nimrod |
| 20:12:26 | Araq | hi hasgfbv welcome |
| 20:12:40 | Araq | dom96: is there some kind of standard for babel directory structures? |
| 20:12:46 | hasgfbv | Hello there |
| 20:12:50 | Araq | src/ and examples/ ? |
| 20:13:36 | dom96 | Araq: rtfm :P |
| 20:14:05 | dom96 | The only standard is that private modules should be in a private dir |
| 20:14:12 | Araq | I haven't come so far in life by reading fucking manuals |
| 20:14:16 | dom96 | Just create your repo and i'll tell you if it's wrong :P |
| 20:14:45 | * | xenagi joined #nimrod |
| 20:14:52 | Araq | ok |
| 20:15:33 | * | Araq uses org.kronos.nimrod.opencl.source as a directory name |
| 20:19:13 | Araq | zahary: tests/generics/C/tforwardgeneric.nim (reSuccess -> reNimrodcCrash) |
| 20:20:55 | zahary | yeah, I noticed. to my credit, I fixed about 30 other regressed tests and this one I left for tomorrow |
| 20:22:55 | Araq | well I have no overview about the test results tbh |
| 20:23:24 | Araq | I'm waiting for varriount's patches to nimbuild |
| 20:23:47 | renesac | can I make an array of sets? |
| 20:24:03 | Araq | sure why not |
| 20:24:42 | renesac | ah, ok, found the alternative syntax for declaring sets |
| 20:24:52 | renesac | set[size], right? |
| 20:25:13 | Araq | I don't think so |
| 20:25:27 | Araq | if that works it's a bug |
| 20:26:21 | Araq | !addrepo nimrod-code opencl |
| 20:26:21 | NimBot | Access denied. |
| 20:26:25 | * | Endy quit (Read error: Operation timed out) |
| 20:26:26 | Araq | wtf |
| 20:26:39 | dom96 | hah |
| 20:26:44 | dom96 | He don't like you. |
| 20:26:46 | renesac | lol |
| 20:26:48 | dom96 | !users |
| 20:26:53 | hasgfbv | I'm sorry dave |
| 20:26:58 | * | dom96 can't even remember the commands |
| 20:27:02 | dom96 | !addrepo nimrod-code opencl |
| 20:27:02 | NimBot | Done. |
| 20:27:32 | renesac | proc typeEqualsAux(a, b: PType, s: var set[PType * PType]) <-- the * operator there confused me |
| 20:27:38 | renesac | so, it is set[Type]? |
| 20:27:40 | * | rejuvyesh[away] joined #nimrod |
| 20:27:53 | Araq | renesac: that's pseudo code |
| 20:27:58 | foodoo | does "\0" create a zero-byte within a string? |
| 20:28:09 | Araq | foodoo: yes |
| 20:28:27 | renesac | it is an example in the manual... |
| 20:28:29 | Araq | nimbot doesn't mention my push |
| 20:28:43 | Araq | renesac: no it's an *algorithm* in the spec |
| 20:28:54 | renesac | hum, right |
| 20:29:00 | Araq | but yes |
| 20:29:09 | Araq | others were confused before you |
| 20:29:16 | Araq | we should change the syntax |
| 20:29:47 | renesac | and describe how to declare a set w/o using the {} syntax |
| 20:31:47 | renesac | the 'set[Type]' syntax I got from the Case Statement part |
| 20:31:48 | renesac | is it right? |
| 20:34:31 | renesac | and what types of set I can put on an array? |
| 20:34:39 | renesac | or set[int] is a reference type? |
| 20:34:53 | renesac | all sets are reference types? |
| 20:38:34 | * | skyfex joined #nimrod |
| 20:38:35 | * | skyfex left #nimrod (#nimrod) |
| 20:38:37 | * | skyfex joined #nimrod |
| 20:39:27 | skyfex | Suggestion: Put a search-field in the upper right on the forum that just does a site: query on duckduckgo.com |
| 20:39:46 | skyfex | To silence some of the complaints about the forum |
| 20:40:28 | skyfex | I'm suggesting duckduckgo rather than google so people don't complain about being redirected to someone that tracks you |
| 20:40:37 | Araq | skyfex: alternative: I delete the complaints :P |
| 20:41:04 | Araq | that will show them why our forum is superior for us |
| 20:41:20 | Araq | (just kidding!) |
| 20:41:24 | skyfex | ^_^ |
| 20:42:17 | Araq | but yeah, it's the way to go |
| 20:42:29 | Araq | your suggestion, that is |
| 20:42:49 | dom96 | in my experience duck duck go doesn't give the best results. |
| 20:43:15 | skyfex | dom96: On a single site.. does it matter much? |
| 20:43:34 | renesac | does it index all nimrod forum pages? |
| 20:44:05 | skyfex | renesac: that's a good question.. I'd assume so, but I don't know |
| 20:44:48 | * | hasgfbv quit (Quit: Page closed) |
| 20:44:54 | Araq | we had people here who wanted to reuse our forum software, can't be that bad |
| 20:44:56 | skyfex | Wouldn't mind if it was Google either.. |
| 20:46:41 | renesac | and anyone can help me with the set's syntax and semantics? |
| 20:46:58 | renesac | I can improve the documentation latter |
| 20:48:08 | Araq | renesac: what's hard about them? the stdlib is full of them ... |
| 20:48:16 | Araq | the compiler too |
| 20:48:32 | Araq | it's still one of my favourite features, in fact |
| 20:49:54 | Araq | set[int] is not possible, the base type has to be a smallish ordinal type |
| 20:50:01 | Araq | sets are value types |
| 20:50:13 | Araq | type MyEnum = enum a, b, c |
| 20:50:27 | Araq | sizeof(set[MyEnum]) == 1 |
| 20:51:04 | Araq | the size is computed upfront to be able to hold {low(base)..high(base)} |
| 20:52:21 | renesac | in the stdlib they are mostly enum |
| 20:52:34 | renesac | can I pass a range as type? |
| 20:52:47 | renesac | constant, of course |
| 20:52:50 | Araq | range[a..b] IS a type |
| 20:53:09 | Araq | and yes you can pass that to 'set' |
| 20:53:23 | renesac | ok, so set[] is aways a bit array, unless I use the 'set' module |
| 20:53:48 | Araq | it's always a bit array, the set module exports TSet |
| 20:54:02 | renesac | oh, it will continue to be TSet? |
| 20:54:45 | Araq | good question |
| 20:56:20 | renesac | I would suggest set[] -> bitset[], TSet-> set[] |
| 20:56:35 | renesac | but then, most of set usage would be more verbose |
| 20:56:49 | renesac | and breaks backwards compatibility |
| 20:57:03 | Araq | TSet -> Hashset |
| 20:57:20 | renesac | yeah, that also works |
| 20:57:37 | Araq | this is no implementation detail anyway as it doesn't work without a proper 'hash' operation |
| 20:58:08 | renesac | well, one sure could use a log n tree... |
| 20:58:53 | renesac | but the performance characteristics are different, of course |
| 20:59:23 | Araq | a log n tree doesn't require a 'hash' proc |
| 20:59:44 | renesac | that was my point |
| 21:00:02 | Araq | ah ok |
| 21:00:18 | Araq | well the current TSet is a hash set and will continue to be so |
| 21:00:34 | renesac | that is fine |
| 21:00:54 | renesac | I support the Hashset rename |
| 21:00:59 | Araq | dom96: can you please add opencl to babel's package list? |
| 21:03:37 | foodoo | (Googling didn't yield any helpful results) How can I access command line arguments? |
| 21:04:16 | skyfex | Araq: How complete should a package be before adding to Babel? I've done parts of libusb, and I don't know if I'll complete it anytime soon |
| 21:05:40 | renesac | Araq, thanks for the help, I already saved the log to edit the manual latter |
| 21:06:13 | Araq | foodoo: os.paramStr(i), os.paramCount() or by the univerally hated parseopt module |
| 21:07:21 | foodoo | thanks. I was looking in the system module |
| 21:07:59 | Araq | skyfex: just mention is in the package description. if it's useful enough for you, it might be useful enough for somebody else |
| 21:08:06 | Araq | *mention it |
| 21:08:34 | NimBot | nimrod-code/packages master c7f06cf Dominik Picheta [+0 ±1 -0]: Add opencl. |
| 21:08:44 | NimBot | Araq/Nimrod devel 3d59c70 flaviut [+0 ±1 -0]: Add token position to `nimrod scan`... 2 more lines |
| 21:08:44 | NimBot | Araq/Nimrod devel 98cc618 Andreas Rumpf [+0 ±1 -0]: Merge pull request #1003 from flaviut/devel... 2 more lines |
| 21:08:45 | * | noam_ joined #nimrod |
| 21:09:13 | renesac | are sets faster than functions with optional parameters? |
| 21:09:28 | renesac | *functions with optional parameters passed as sets of enums |
| 21:09:29 | NimBot | Araq/Nimrod devel c3f0fce Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds example to likely/unlikely docstring. Refs #983. |
| 21:09:29 | NimBot | Araq/Nimrod devel 3ecca6e Andreas Rumpf [+0 ±1 -0]: Merge pull request #1000 from gradha/pr_adds_likely_example_983... 2 more lines |
| 21:09:52 | NimBot | Araq/Nimrod devel ce9798e Michał Zieliński [+0 ±1 -0]: Provide zlib version explicit on Linux.... 4 more lines |
| 21:09:52 | NimBot | Araq/Nimrod devel b1acca1 Andreas Rumpf [+0 ±1 -0]: Merge pull request #999 from zielmicha/zlib_abi_version... 2 more lines |
| 21:10:37 | renesac | "Merge pull request #1000" <-- \o/ |
| 21:11:03 | renesac | (the number is a bit misleading, but anyway) |
| 21:11:03 | Araq | true |
| 21:11:10 | Araq | let's celebrate! |
| 21:11:36 | Araq | next time I'll tell people we have over 1000 bug reports/feature requests/ pull requrests |
| 21:11:44 | * | noam__ quit (Ping timeout: 252 seconds) |
| 21:11:48 | Araq | so much for the "nobody uses nimrod" |
| 21:12:04 | renesac | and most of them closed! |
| 21:12:14 | renesac | an important detail |
| 21:12:15 | renesac | XD |
| 21:13:01 | dom96 | Let's just lie and say we've got 1000 PRs |
| 21:14:28 | Araq | renesac: I don't understand your question |
| 21:14:40 | Araq | which makes it kind of hard to answer |
| 21:14:46 | Araq | but let me try anyway: yes. |
| 21:15:09 | renesac | I tried to fix the start of the question in the second line |
| 21:15:57 | renesac | I think the optional parameters are a nicer interface, both for the library coder and for the user |
| 21:16:30 | renesac | especially when reading the docs, as enums are located at the top, and not all enums are aceptable for all functions |
| 21:16:50 | Araq | ah you mean a list of optional 'bool' parameters instead of the set[enum] way? |
| 21:16:56 | renesac | yes |
| 21:16:56 | EXetoC | . |
| 21:17:18 | Araq | well the set[enum] way is indeed faster |
| 21:17:51 | Araq | and I think it's somewhat cleaner than an ever growing list of optional parame |
| 21:17:53 | Araq | *params |
| 21:18:27 | Araq | the param style basically makes you use named parameters so that you don't screw up |
| 21:19:01 | renesac | maybe when you have many functions sharing the same optional parameters |
| 21:19:10 | renesac | otherwise, I don't see why it would be clearer |
| 21:19:16 | * | XAMPP quit (Excess Flood) |
| 21:19:24 | renesac | true |
| 21:19:44 | renesac | but with enums you also have to use the enum name, plus the prefix |
| 21:19:56 | * | XAMPP joined #nimrod |
| 21:19:56 | * | XAMPP quit (Changing host) |
| 21:19:56 | * | XAMPP joined #nimrod |
| 21:20:23 | Araq | renesac: for the stdlib you're perhaps right, it surely makes a difference in the compiler |
| 21:20:28 | Araq | where everything is recursive |
| 21:20:53 | Araq | and foo(a, b, flags) # recursive call tends to continue to work when you add another flag |
| 21:21:17 | renesac | hum |
| 21:22:08 | renesac | can the compiler optimize the functions with optional parameters to sets? |
| 21:22:12 | * | Matthias247 quit (Excess Flood) |
| 21:22:17 | renesac | or it would break the ABI? |
| 21:22:36 | * | Matthias247 joined #nimrod |
| 21:22:45 | Araq | there is no ABI when you don't specify a calling convention so yeah the compiler could do that |
| 21:23:10 | Araq | but again: |
| 21:23:35 | Araq | proc foo(flagA = false) |
| 21:23:41 | Araq | --> add another param |
| 21:24:00 | Araq | proc foo(flagA = false, flagB = false) |
| 21:24:37 | Araq | foo(flagA) # recursive call, d'oh! forgot to pass 'flagB' |
| 21:25:34 | Araq | vs. foo(flags) # recursive call, continues to work |
| 21:26:45 | renesac | would be interesting if one could call this function foo with foo({flagA, flagB}) |
| 21:26:58 | renesac | but then, optional parameters let you make parameters that are true by default.. |
| 21:27:07 | renesac | so this don't work so well... |
| 21:28:37 | Araq | btw the other common use case is set[char] |
| 21:28:57 | renesac | the idea would be a set could be expected at the first boolean parameter position, and this translated to the correct call by the compiler |
| 21:29:28 | renesac | but then, this could introduce obscure bugs with overloading... |
| 21:29:30 | EXetoC | renesac: no, only pure enumerators must be fully qualified |
| 21:29:37 | Araq | the idea requires a problem. but what's the problem? |
| 21:30:06 | renesac | wanting to make those recursive calls with a function that wasn't made with set parameters |
| 21:30:32 | renesac | well, you could write your own wrapper function, but too much effort probably |
| 21:30:52 | renesac | and that feature is also probably too much effort |
| 21:31:53 | renesac | and bring too many problems, it seems |
| 21:32:53 | Araq | argh, the mimetypes module is *OLD* |
| 21:33:10 | EXetoC | how come? |
| 21:33:18 | Araq | it should use a string case. this way no need for globals, no threading problems |
| 21:33:32 | * | runvnc joined #nimrod |
| 21:33:34 | Araq | I have to reject #1002 because of that |
| 21:34:13 | runvnc | just missed the problem with my 1002 |
| 21:34:21 | runvnc | probably shows on this logs page though |
| 21:34:34 | runvnc | yeah it does |
| 21:35:17 | runvnc | araq string case like case keyword, meaning a giant case with a different of for each mime type? |
| 21:35:25 | Araq | yeah |
| 21:35:43 | Araq | a 'case' instead of the current {:} ... oohhh big deal |
| 21:35:43 | skyfex | Oh, Araq, while working on the libusb stuff, i needed a "packed" pragma.. I added it to the compiler, should I commit it? |
| 21:36:03 | Araq | skyfex: er ... sure |
| 21:36:23 | Araq | you don't have write access, do you? |
| 21:36:40 | skyfex | Araq: No.. I meant pull request |
| 21:36:48 | Araq | ok good |
| 21:36:58 | runvnc | theoretically I should be able to do some search/replaces on the mimetypes module |
| 21:37:08 | Araq | runvnc: is #1002 from you? |
| 21:37:11 | runvnc | yes |
| 21:37:40 | runvnc | No biggie though because I need the redirect and stuff that dom already put in jester |
| 21:37:51 | runvnc | so I am not actually dependent upon that in httpserver now so |
| 21:37:58 | runvnc | but I will try to upgrade mimetypes |
| 21:38:02 | skyfex | Araq: But it assumes GCC/Clang (__attribute__((__packed__))).. Is that a problem? I think it might be different with other compilers |
| 21:38:05 | runvnc | so you can use the setcontenttype |
| 21:38:30 | Araq | runvnc: excellent thanks |
| 21:38:48 | Araq | though the 'case' solution doesn't support 'register' |
| 21:39:21 | Araq | should be solved with a user defined callback I think |
| 21:39:31 | Araq | that's invoked in the 'else' |
| 21:39:58 | Araq | lets clients deal with the problem |
| 21:40:14 | EXetoC | skyfex: well, VS is very common |
| 21:40:18 | runvnc | ok |
| 21:40:54 | Araq | skyfex: sure it's a problem, edit extccomp and make it a format string or something |
| 21:41:30 | Araq | and yes implement it for VS |
| 21:42:15 | skyfex | Araq: Cool, I'll do that |
| 21:43:07 | EXetoC | support for more compilers would be nice, but that's a start |
| 21:43:17 | EXetoC | though GCC and VS covers something like 99% of the users, right? |
| 21:43:52 | skyfex | I could take a quick look down the list, shouldn't take too long to google some or most of them |
| 21:45:53 | Araq | you can do that but only VS, clang, gcc and intel exist |
| 21:46:09 | Araq | the other C compilers are all effectively dead |
| 21:46:34 | Matthias247 | on desktop ;) |
| 21:46:45 | Araq | true |
| 21:47:03 | Matthias247 | I guess for embedded there are still things like KEIL around |
| 21:47:21 | Araq | Green Hills comes to mind |
| 21:50:17 | dom96 | Araq: If you change the mimetypes to a string case then we won't be able to read the mimetypes from /etc/mimetypes |
| 21:50:24 | skyfex | Araq: I also could use a bits pragma, which I remember you suggested I could do.. but I didn't need it bad enough, maybe later |
| 21:50:39 | Araq | dom96: do we do that? |
| 21:51:03 | Araq | skyfex: yeah well I already added 'union' and 'unchecked' :P |
| 21:51:05 | dom96 | No but I think that my plan originally. |
| 21:51:28 | Araq | that's not portable anyway |
| 21:51:35 | dom96 | Also, you will need 2 different lists |
| 21:51:51 | dom96 | One for getExt the other for getMimetype |
| 21:51:56 | Araq | no, but one direction will be slow |
| 21:52:19 | dom96 | one direction already is |
| 21:52:26 | Araq | we could also generate both from a macro |
| 21:52:31 | dom96 | oh but see, you can register mime types. |
| 21:52:48 | Araq | I saw and found a solution |
| 21:52:57 | Araq | read the logs completely :P |
| 21:53:39 | Araq | thread safety is more important than compatibility in this case |
| 21:54:29 | dom96 | I don't see the problem. The mimetypes db should be apart of the HttpServer object |
| 21:54:33 | dom96 | *a part |
| 21:54:58 | * | BitPuffin joined #nimrod |
| 21:57:10 | runvnc | dom96 re the finish ttyl thing I needed, this is what you mean right proc finish*(response: PResponse) |
| 21:57:29 | dom96 | runvnc: yeah |
| 21:59:22 | Araq | dom96: ah good point |
| 21:59:41 | Araq | this means it's not shared but then it is not as threadvar either |
| 22:00:14 | Araq | I still prefer the string case though |
| 22:00:22 | Araq | string cases rule |
| 22:00:24 | dom96 | I'll likely rewrite httpserver anyway |
| 22:01:17 | dom96 | So that proc sendFile(http: HttpServer, filename: string, mime: MimeDb) exists |
| 22:02:08 | dom96 | We could provide both a string case and the current implementation :P |
| 22:02:45 | dom96 | Then by default sendFile could use the more efficient string case. |
| 22:03:00 | * | foodoo quit (Quit: it works!) |
| 22:03:14 | dom96 | Maybe some macro magic would also allow it to be fast both ways. |
| 22:03:28 | dom96 | i.e. we'll get the macro to create two lists. |
| 22:05:49 | dom96 | Argh. Looks like I will need to rewrite the SSL code for IOCP |
| 22:05:55 | runvnc | ok so I would like everyone to be happy.. I can just close my pull request |
| 22:06:05 | runvnc | but still maybe ok to make a new version of mimetypes with a pull or what |
| 22:06:11 | runvnc | I can just put it in a gist I guess |
| 22:07:27 | * | skyfex quit (Quit: Computer has gone to sleep.) |
| 22:08:39 | Araq | runvnc: close it if you want to or fix it "properly" whatever that means |
| 22:09:09 | runvnc | lol I thought properly meant mimetypes with case |
| 22:09:29 | runvnc | but dom said all that stuff then I was confused |
| 22:09:41 | runvnc | I will do the mimetypes with case in case anyone wants to use it |
| 22:09:48 | runvnc | since I said I would |
| 22:10:31 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 22:14:34 | Araq | welll dom96 made good points |
| 22:14:43 | Araq | so I dunno |
| 22:15:45 | runvnc | ok well you guys let me know if you want me to close the pull request or make a mimetypes with string case |
| 22:15:57 | runvnc | otherwise its not a big priority for me and I will leave it to the big guns I guess |
| 22:16:47 | runvnc | also I don't even know where HttpServer is defined so heh |
| 22:18:04 | Araq | just close it and let think about it |
| 22:18:09 | Araq | *let us |
| 22:20:09 | runvnc | k |
| 22:21:54 | dom96 | runvnc: one more fix please |
| 22:21:59 | dom96 | take a look at my comment |
| 22:22:01 | runvnc | lol ok |
| 22:28:29 | * | darkf joined #nimrod |
| 22:29:09 | renesac | why sets have 'incl' instead of 'add'? |
| 22:29:27 | dom96 | I was wondering the same thing. |
| 22:29:43 | renesac | the operations are fundamentally different? |
| 22:30:33 | dom96 | Add implies being able to add the same value multiple times I guess |
| 22:30:51 | runvnc | math texts use language like include and exclude I think for sets |
| 22:32:16 | * | io2 quit () |
| 22:35:03 | Araq | tables have both add and incl and they are not aliases |
| 22:38:00 | renesac | http://build.nimrod-lang.org/docs/tables.html <-- this tables? |
| 22:38:32 | renesac | because I can't see any incl() there |
| 22:43:45 | * | EXetoC quit (*.net *.split) |
| 22:43:46 | * | cark quit (*.net *.split) |
| 22:43:46 | * | Matthias247 quit (*.net *.split) |
| 22:43:47 | * | xenagi quit (*.net *.split) |
| 22:43:48 | * | Guest23044 quit (*.net *.split) |
| 22:43:49 | * | nolan_d quit (*.net *.split) |
| 22:44:46 | * | Matthias247 joined #nimrod |
| 22:44:46 | * | xenagi joined #nimrod |
| 22:44:46 | * | nolan_d joined #nimrod |
| 22:44:46 | * | Guest23044 joined #nimrod |
| 22:56:10 | Araq | renesac: maybe it's only for the compiler's tables |
| 22:56:26 | Araq | the stdlib's tables uses []= vs add instead |
| 22:56:56 | * | cark joined #nimrod |
| 22:56:56 | * | EXetoC joined #nimrod |
| 23:02:35 | renesac | []= would be the incl()? |
| 23:05:00 | * | _fel1x quit (Ping timeout: 265 seconds) |
| 23:08:32 | Araq | yeah |
| 23:29:41 | * | Demos joined #nimrod |
| 23:48:15 | Skrylar | zahary: you know, the irony is i would have named it TRectangle, but someone told me we weren't doing that anymore :P |
| 23:58:42 | clovis | I'm not sitting on a TChair |
| 23:59:45 | runvnc | TChair probably wouldnt be very practical |
| 23:59:48 | runvnc | tend to fall over |