| 00:05:21 | * | FromGitter quit (Ping timeout: 240 seconds) |
| 00:06:11 | * | endragor joined #nim |
| 00:06:28 | * | oprypin quit (Ping timeout: 256 seconds) |
| 00:11:00 | * | endragor quit (Ping timeout: 265 seconds) |
| 00:16:21 | * | Lord_Nightmare quit (Ping timeout: 255 seconds) |
| 00:17:28 | * | craigger quit (Ping timeout: 240 seconds) |
| 00:21:12 | * | Lord_Nightmare joined #nim |
| 00:23:49 | * | oprypin joined #nim |
| 00:24:12 | * | craigger joined #nim |
| 00:26:25 | * | avsej quit (Ping timeout: 256 seconds) |
| 00:28:33 | * | oprypin quit (Ping timeout: 264 seconds) |
| 00:28:42 | * | avsej joined #nim |
| 00:28:42 | * | avsej quit (Changing host) |
| 00:28:42 | * | avsej joined #nim |
| 00:28:46 | * | BlaXpirit joined #nim |
| 00:29:09 | * | BlaXpirit is now known as oprypin |
| 00:31:16 | * | FromGitter joined #nim |
| 00:32:22 | * | arnetheduck joined #nim |
| 00:34:36 | FromGitter | <drewp> @phrmoy i was surprised how easy it is to segfault if you don't construct objects right. i was expecting the compiler to mostly tell me about those errors. Otherwise after a few days to get it going on my ESP32 chip, i'm pretty uninterested in writing C again. |
| 00:36:00 | FromGitter | <phrmoy> Thanks for sharing @drewp! |
| 00:37:20 | FromGitter | <drewp> https://github.com/drewp/oled/tree/master/src |
| 00:39:33 | FromGitter | <phrmoy> for the windows install, do I still need to Nim's tools separately or running ```finish.exe``` will do? |
| 00:53:12 | FromGitter | <phrmoy> alright so I ran ```koch nimble``` and ```koch tools```, anything else to be done? |
| 00:53:42 | FromGitter | <phrmoy> we should make the windows installation a bit easier, maybe I can help with that |
| 00:54:50 | shashlick | you should try choosenim |
| 00:55:27 | shashlick | otherwise there's just koch boot -d:release and koch tools -d:release |
| 00:55:49 | FromGitter | <phrmoy> choosenim? |
| 00:56:12 | shashlick | https://github.com/dom96/choosenim |
| 00:56:34 | FromGitter | <phrmoy> aaa wasnt aware of that |
| 00:56:40 | FromGitter | <phrmoy> was following website instructions |
| 01:01:05 | shashlick | are you using 32-bit or 64-bit gcc - choosenim doesn't work with 64-bit yet |
| 01:01:30 | FromGitter | <phrmoy> oh i installed the 64-bit version |
| 01:01:53 | FromGitter | <phrmoy> my manual installation so far seems ok |
| 01:02:39 | shashlick | ya if it works, no reason to switch, but worth knowing about choosenim for the future |
| 01:03:43 | FromGitter | <phrmoy> agreed, thank you |
| 01:06:38 | FromGitter | <phrmoy> what is ```distrohelper```? |
| 01:07:32 | shashlick | oprypin: you around? |
| 01:09:12 | * | S1tiSchu joined #nim |
| 01:10:50 | FromGitter | <phrmoy> hm should there be a ```%USERPROFILE%\.nimble\bin``` directory after installation? I don't have one. |
| 01:12:30 | shashlick | https://github.com/nim-lang/nimble#installation |
| 01:12:44 | * | S1t1Schu quit (Ping timeout: 260 seconds) |
| 01:18:12 | FromGitter | <phrmoy> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ac6cad4270d7d370899a1cd] |
| 01:18:15 | FromGitter | <phrmoy> ;(( |
| 01:19:10 | * | SenasOzys quit (Read error: Connection reset by peer) |
| 01:19:19 | shashlick | what was the command you ran? |
| 01:19:35 | FromGitter | <phrmoy> `````` |
| 01:19:50 | FromGitter | <phrmoy> my ```gcc``` is on the ```$PATH``` |
| 01:19:59 | * | SenasOzys joined #nim |
| 01:20:08 | FromGitter | <phrmoy> but surely there not ```mingw``` in ```dist``` |
| 01:22:05 | shashlick | ok, not sure what's going on - how did you download nim? git clone or a zip? |
| 01:22:24 | FromGitter | <phrmoy> zip file from the website |
| 01:22:59 | FromGitter | <phrmoy> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ac6cbf36d7e07082bc3a122] |
| 01:23:13 | FromGitter | <phrmoy> so, i guess i shoudnt worry about it then since it's on path? |
| 01:23:32 | FromGitter | <phrmoy> it happens after I say y to the above |
| 01:25:44 | shashlick | so why were you running koch if you downloaded the binary build? |
| 01:28:31 | FromGitter | <phrmoy> trying to follow the instructions as given |
| 01:28:46 | FromGitter | <phrmoy> don't what im supposed to do, only what im reading |
| 01:28:52 | shashlick | which instructions are you following? |
| 01:29:16 | FromGitter | <phrmoy> the websites, and those given in the install file |
| 01:31:49 | FromGitter | <phrmoy> alright so I compiled but there is no bin in .nimble |
| 01:32:01 | FromGitter | <phrmoy> so I am going to create that manually and add it to the PATH |
| 01:32:19 | shashlick | ok I see what you're saying - you did koch nimble |
| 01:36:17 | * | max3 joined #nim |
| 01:37:22 | FromGitter | <phrmoy> just curious why do we need to rename nimble to something like nimble1? |
| 01:37:40 | FromGitter | <phrmoy> hopefully that's for the install |
| 01:38:45 | shashlick | so here's the thing - nimble.exe is already available in the ZIP you downloaded |
| 01:38:50 | shashlick | it's already in the bin directory |
| 01:39:11 | shashlick | so there was no need to koch nimble - per the install.txt, you only need to do that for the source based install |
| 01:39:28 | FromGitter | <phrmoy> I see |
| 01:40:36 | shashlick | anyway, welcome to Nim :) |
| 01:44:57 | FromGitter | <phrmoy> Thank you!;) |
| 02:09:07 | * | leorize joined #nim |
| 02:38:26 | * | dddddd quit (Remote host closed the connection) |
| 02:44:16 | * | xkapastel quit (Quit: Connection closed for inactivity) |
| 02:45:57 | * | SenasOzys quit (Ping timeout: 260 seconds) |
| 03:15:38 | * | athenot quit (Ping timeout: 265 seconds) |
| 03:17:51 | * | athenot joined #nim |
| 03:28:53 | * | smt quit (Read error: Connection reset by peer) |
| 03:34:13 | FromGitter | <sivakon> @shashlick Actually I am trying to create a wrapper for MxNet for DeepRL with GYM with HTTP API. |
| 03:38:47 | shashlick | nice |
| 03:47:32 | * | endragor joined #nim |
| 03:47:40 | FromGitter | <gogolxdong> How to transform between JsonNode and NimNode? |
| 03:57:47 | shashlick | not sure how you got there - how do you get json working in a macro? |
| 04:00:16 | FromGitter | <sivakon> The `c2nim` tool currently does not support `,`. I have enums in my header file. How do I get c2nim to work around it. |
| 04:02:46 | shashlick | @sivakon: can you post a snippet or point to the header you are trying to process? |
| 04:03:18 | * | xkapastel joined #nim |
| 04:07:20 | FromGitter | <sivakon> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ac6f278e3d0b1ff2ca829f6] |
| 04:20:13 | FromGitter | <sivakon> That `enum` has to be rewritten. |
| 04:33:22 | * | mwbrown quit (Ping timeout: 264 seconds) |
| 04:34:06 | * | mwbrown joined #nim |
| 04:35:07 | * | libman_ joined #nim |
| 04:35:08 | shashlick | ya, you typically need to change up code a bit for c2nim to get through |
| 04:35:28 | FromGitter | <sivakon> Yep. What do you have in mind> |
| 04:36:08 | shashlick | on second thought, it's C++ so you run "c2nim --cpp file" |
| 04:36:30 | FromGitter | <sivakon> Oh. Let me check |
| 04:36:42 | shashlick | it works that way |
| 04:38:30 | * | yglukhov joined #nim |
| 04:42:58 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 04:46:45 | FromGitter | <sivakon> I got a different error now. |
| 04:46:48 | FromGitter | <sivakon> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ac6fbb82b9dfdbc3a5f21e8] |
| 04:46:56 | FromGitter | <sivakon> Error: '(' expected |
| 04:50:22 | * | leorize quit (Ping timeout: 265 seconds) |
| 04:54:18 | shashlick | I don't think c2nim understands operator overloading yet, you'd need to rename operator< to something else for c2nim to deal with it |
| 04:57:43 | FromGitter | <sivakon> But then I have to look at every `<` and check whether if it's overloaded one or not |
| 04:58:26 | FromGitter | <sivakon> Thanks anyways, I am tempted towards Arraymancer. |
| 05:04:54 | * | ketralnis joined #nim |
| 05:30:05 | * | S1tiSchu quit (Remote host closed the connection) |
| 05:30:18 | * | miran joined #nim |
| 05:30:30 | * | S1tiSchu joined #nim |
| 05:37:09 | * | leorize joined #nim |
| 05:44:07 | * | nsf joined #nim |
| 05:51:44 | FromGitter | <phrmoy> oh are u guys really doing a c2nim? |
| 05:51:48 | FromGitter | <phrmoy> how awesome is that! |
| 05:57:55 | * | leorize quit (Ping timeout: 256 seconds) |
| 06:04:16 | * | xkapastel quit (Quit: Connection closed for inactivity) |
| 06:06:07 | * | miran quit (Quit: Konversation terminated!) |
| 06:11:02 | * | aguspiza joined #nim |
| 06:12:18 | * | leorize joined #nim |
| 06:15:53 | * | max3 quit (Quit: Connection closed for inactivity) |
| 06:20:36 | FromGitter | <phrmoy> "To call a procedure that returns a value just for its side effects and ignoring its return value, a discard statement must be used. Nim does not allow silently throwing away a return value:" |
| 06:20:54 | FromGitter | <phrmoy> Can't I just pass void as the return type? Would I still have to discard that? |
| 06:22:08 | FromGitter | <phrmoy> that seems to work, I did not have to use discard |
| 06:22:16 | FromGitter | <phrmoy> to ignore the returned value |
| 06:30:04 | FromGitter | <narimiran> @phrmoy `proc foo(a: int) = echo a` can be "discarded" without any statements |
| 06:32:44 | FromGitter | <phrmoy> hm ok, one of the tutorials im reading seem to infer that you need to discard them (at least that's how it read to me) |
| 06:32:45 | FromGitter | <phrmoy> thanks! |
| 06:40:04 | FromGitter | <narimiran> if you had `proc foo(a: int): int = 10*a` (a proc which returns a value), then you would need to discard it |
| 06:53:41 | * | yglukhov joined #nim |
| 06:58:27 | * | athenot quit (Ping timeout: 265 seconds) |
| 07:01:27 | * | athenot joined #nim |
| 07:24:23 | FromGitter | <phrmoy> I see, that makes more sense, so we are saying is that if we are returning a value, we can't just ignore it, we must discard it. |
| 07:28:29 | FromGitter | <narimiran> yep |
| 07:29:16 | FromGitter | <narimiran> @dom96 you here maybe? |
| 07:38:33 | * | xkapastel joined #nim |
| 07:54:22 | * | aguspiza quit (Ping timeout: 264 seconds) |
| 07:58:01 | FromGitter | <phrmoy> finished my first tutorial, Nim is the bomb! |
| 08:01:32 | * | SenasOzys joined #nim |
| 08:02:41 | * | athenot_ joined #nim |
| 08:04:23 | FromGitter | <narimiran> indeed it is :) |
| 08:04:27 | * | athenot quit (Ping timeout: 260 seconds) |
| 08:10:33 | * | SenasOzys quit (Ping timeout: 264 seconds) |
| 08:15:25 | * | sendell joined #nim |
| 08:30:52 | * | jaco60 joined #nim |
| 08:49:37 | * | rauss quit (Ping timeout: 256 seconds) |
| 08:59:42 | FromGitter | <narimiran> i'm having a problem with `doAssertRaises`, if somebody has an experience how to test if something fails some asserts - i have couple of questions |
| 09:03:22 | * | Vladar joined #nim |
| 09:03:56 | Araq | never used it |
| 09:05:43 | FromGitter | <narimiran> Araq: haha, ok, dom96 told me to use it to test if something raises an error - but it seems to be not very good for testing (examples to follow) |
| 09:06:52 | FromGitter | <narimiran> ```code paste, see link``` ⏎ ⏎ the first example should raise the `AssertionError`, but the second shouldn't. and this passes. [https://gitter.im/nim-lang/Nim?at=5ac738ac2b9dfdbc3a60158e] |
| 09:07:51 | FromGitter | <narimiran> (first example should raise it after a fix in `strutils`, currently is broken) |
| 09:08:02 | Araq | so? |
| 09:08:19 | Araq | obviously this works but doesn't run the 2nd discard line |
| 09:08:33 | FromGitter | <alehander42> I think I used `expect` ⭕ |
| 09:08:44 | Araq | think about it please. |
| 09:08:58 | Araq | the first line raises the exception, the doAssertRaises is happy |
| 09:09:06 | Araq | the 2nd line is not run. |
| 09:09:34 | FromGitter | <narimiran> remove the first line, run just with the second - doAssertRaises is still happy (and i think it shouldn't be) |
| 09:09:35 | FromGitter | <nathandaly> Hey `envVars.add(key & "=" & $value)` I have a seq and I want create a string (for a command) `value` could be a string or an int, this works `echo envName & " = " & $envValue`. The error I get is `SIGSEGV: Illegal storage access. (Attempt to read from nil?)` |
| 09:10:40 | Araq | usually you don't have "could be a string or an int", you have "string" instead |
| 09:11:11 | FromGitter | <nathandaly> it's reading vals from a json file |
| 09:11:17 | FromGitter | <nathandaly> port number isn't wrapped in quotes |
| 09:12:12 | Araq | ok |
| 09:12:12 | FromGitter | <narimiran> Araq if you're happy with `doAssertRaises` happiness, i'll just ignore it and send my fix :) |
| 09:12:59 | Araq | I'm looking at its implementation |
| 09:13:00 | FromGitter | <dom96> You should have two doAssertRaises there... |
| 09:13:13 | Araq | and AssertionError cannot be handled by doAssertRaises :D |
| 09:13:15 | Araq | XD |
| 09:13:29 | Araq | becaues it raises that when nothing it raised ... |
| 09:13:46 | FromGitter | <narimiran> @dom96 it's not a problem to have two of them, the problem is that it is happy when there was no assertion error |
| 09:13:52 | * | dddddd joined #nim |
| 09:13:59 | Araq | it's just a bug, not hard to fix |
| 09:14:26 | FromGitter | <dom96> Tbh this is a bit messy |
| 09:14:53 | FromGitter | <dom96> If you're using assert then it will disappear in release mode |
| 09:14:59 | FromGitter | <dom96> And then your tests will fail |
| 09:15:06 | FromGitter | <narimiran> yeah, if i change it to `doAssertRaises(ValueError)` then it is not happy when there's no value error |
| 09:15:10 | Araq | this code needs to use a bool flag instead of raising an Assertion... |
| 09:15:15 | FromGitter | <narimiran> i'm using `doAssert` |
| 09:15:41 | FromGitter | <dom96> If you're using doAssert then you may as well raise an exception |
| 09:15:48 | Araq | no. |
| 09:15:53 | FromGitter | <narimiran> i currently have `doAssert(sub.len > 0, "Sub must not be an empty string.")` |
| 09:16:11 | FromGitter | <dom96> Why not? |
| 09:16:11 | FromGitter | <narimiran> if you have a better option to raise this, let me know |
| 09:16:23 | Araq | well it's debatable but usually the stdlib doesn't raise ValueError for programmer bugs |
| 09:16:35 | FromDiscord | <--HA--> @nathandaly how did you create your seq? I only started looking at nim a few days ago so I probably don't know what I'm talking about but that error you got reminds me of what I saw when I left out the @[] in my seq declaration. When I use something like this I could add to sequences: var stringseq: seq[string] = @[] |
| 09:16:43 | Araq | and AssertionError is not catchable, strictly speaking |
| 09:17:06 | FromGitter | <dom96> Yeah ok |
| 09:17:27 | FromGitter | <GULPF> @Araq how come that semfold.nim uses saturated arithmetic? wouldn't it make more sense to raise an error if the constant folding overflows? |
| 09:18:04 | Araq | I think it only uses it to compute the range types |
| 09:18:07 | FromGitter | <dom96> If you're happy to pay the price of an extra check then the doAssert is fine |
| 09:18:11 | Araq | a feature we got rid of |
| 09:18:24 | Araq | thinking about it |
| 09:18:39 | Araq | it should probably do nothing to the string |
| 09:19:00 | Araq | not die with an AssertionError |
| 09:19:16 | FromGitter | <dom96> Read my comments please |
| 09:19:18 | FromGitter | <narimiran> should i raise an error (which one?) instead of asserting? |
| 09:19:26 | Araq | I'm sure Aporia and friends call 'replace' without checking for the empty string |
| 09:19:26 | FromGitter | <dom96> Split asserts too |
| 09:20:11 | Araq | but then you have to add the "if x != "": replace()" to make it not crash |
| 09:20:23 | Araq | you might as well make that the behaviour of 'replace' |
| 09:20:41 | FromGitter | <dom96> It was never a problem in practice |
| 09:20:54 | FromGitter | <dom96> Pretty sure it leads to infinite loops |
| 09:20:57 | Araq | I bet it crashes my NimEdit :P |
| 09:21:00 | FromGitter | <dom96> So we would have noticed |
| 09:21:03 | FromGitter | <narimiran> my first solution was to just return the original string if `sub` is `""`, but people said it might be better to raise/assert (https://github.com/nim-lang/Nim/pull/7509) |
| 09:21:04 | Araq | the infinite loops are horrible |
| 09:21:15 | Araq | but turning it into a nop makes much sense |
| 09:21:50 | FromGitter | <dom96> Consistency with split is good |
| 09:22:14 | Araq | so fix split too while we're at it |
| 09:23:33 | FromGitter | <narimiran> also to have a check in split? ok. but what should be the wanted behaviour? returning the original or raising something? |
| 09:23:44 | Araq | return the original. |
| 09:24:03 | FromGitter | <dom96> Please read the original discussion around split |
| 09:24:10 | Araq | these asserts only mean I need to protect the call at the callsite |
| 09:24:17 | FromGitter | <dom96> There might be a good reason why this was done |
| 09:24:51 | FromGitter | <narimiran> ok, i'll wait until you two have the same opinion :) (this might take a while? :D :D) |
| 09:25:49 | FromGitter | <narimiran> btw, while we're at it, do you prefer `if sub.len == 0` or `if sub == ""`? (so i don't have to change it later :) ) |
| 09:26:05 | Araq | too lazy to read it, reason was probably "Python does it this way" |
| 09:27:22 | Araq | to which I say, "copying bad design is not good design" |
| 09:28:05 | Araq | if sub.len == 0 is preferred |
| 09:29:37 | Araq | nimgrep also doesn't validate its calls to 'replace' |
| 09:45:01 | yglukhov | Is anyone aware of the case when combining exceptions and async yields incorrect runtime behavior? |
| 09:46:39 | dom96 | Here is the relevant PR https://github.com/nim-lang/Nim/pull/5125 |
| 09:47:24 | FromGitter | <narimiran> PR submitted: https://github.com/nim-lang/Nim/pull/7521 |
| 09:47:58 | * | xkapastel quit (Quit: Connection closed for inactivity) |
| 09:48:52 | dom96 | Do link to your previous PR like I just did for reference :) |
| 09:49:05 | dom96 | yglukhov: Are you using 'try' |
| 09:49:06 | dom96 | ? |
| 09:49:26 | * | hal1 joined #nim |
| 09:49:28 | Araq | dom96, that doesn't add any new insights |
| 09:49:48 | dom96 | Araq: Yeah, but it's worth a look |
| 09:50:19 | FromGitter | <narimiran> @dom96 ok, will do next time |
| 09:51:11 | yglukhov | dom96: yes. I just want to know the possible runtime bugs when using try:except: win async code. I've found only this one: https://github.com/nim-lang/Nim/issues/2650, but that seems to be "finally:" problem. |
| 09:52:21 | dom96 | yglukhov: If you want reliable error checking with async, then use an if statement https://nim-lang.org/docs/asyncdispatch.html#asynchronous-procedures-handling-exceptions |
| 09:53:05 | yglukhov | dom96: yes, that's not what I'm asking about. I wonder if there are any code samples that demonstrate unreliability :) |
| 09:54:26 | dom96 | None that I'm aware of |
| 09:55:19 | * | xet7 joined #nim |
| 09:55:21 | yglukhov | got it, thanks. Please toss those at me in case you find any. |
| 09:56:18 | * | leorize quit (Quit: WeeChat 2.1) |
| 09:56:19 | yglukhov | dom96: but why do you think that try:except: is unreliable? =) |
| 09:56:39 | dom96 | because it doesn't match normal try semantics |
| 09:56:54 | dom96 | it performs a transformation that moves yields out of the try |
| 09:56:56 | dom96 | and does it poorly |
| 09:57:29 | FromGitter | <narimiran> @dom96 how do i add that check to the template `splitCommon`? what should be returned/yielded? |
| 09:59:21 | dom96 | narimiran: Wait until we decide what should be done. Otherwise you'll be editing back and forth :) |
| 10:00:02 | dom96 | Although to answer your question: I think you can just 'return' in that template |
| 10:00:28 | FromGitter | <narimiran> haha ok, i'll go grab some lunch and wait for the situation to settle :) |
| 10:01:28 | Araq | well 'replace' should be a nop, I don't care about split, I don't call split directly with user supplied input anywhere |
| 10:02:28 | dom96 | Araq: Can't we copy another language's behaviour? |
| 10:02:41 | Araq | no because I know better. |
| 10:03:18 | Araq | in fact, I don't use split, split is a code smell. |
| 10:04:23 | dom96 | I think copying Python's behaviour makes sense |
| 10:04:36 | hal1 | Hello again. My goal is to add a setLastModificationTime proc to os. I was talking from discord yesterday. For the call to the windows api SetFileTime function I need variables of type FILETIME. I would like the proc to accept a Time type from times though. Can I add a toWinFileTime to Time, like there is toUnix, does that seem like a good idea? |
| 10:05:39 | hal1 | that would return a FILETIME |
| 10:06:10 | Araq | >>> "abc".replace("", "def") |
| 10:06:10 | Araq | 'defadefbdefcdef' |
| 10:06:43 | dom96 | hal1: I think you can do: time.toUnix().unixTimeToWinTime() |
| 10:08:41 | hal1 | I tried that, it returns an int64. The FILETIME type consists of two DWORD (int32) dwLowDateTime and dwHighDateTime that are basically the int64 split into two halfs as far as I see it. |
| 10:09:14 | dom96 | hal1: So you'll have to split the int64 :) |
| 10:09:30 | hal1 | yes, so the result from time.toUnix().unixTimeToWinTime() would require further conversion and I was not clear on where to best do that |
| 10:09:33 | * | SenasOzys joined #nim |
| 10:10:15 | dom96 | I would say, just do it in the setLastModificationTime function |
| 10:10:21 | hal1 | not something to add to time but to do in the new os.setFileModificationTime? |
| 10:10:22 | dom96 | It should be fairly trivial |
| 10:10:24 | hal1 | ok |
| 10:17:45 | hal1 | I remember now why I struggled with it yesterday. You can not call time.toUnix().unixTimeToWinTime() just like that. toUnix returns an int64 and unixTimeToWinTime expects a CTime which is a not public type from times. |
| 10:17:56 | hal1 | import times |
| 10:17:59 | hal1 | import winlean |
| 10:18:01 | hal1 | let wint = getTime().toUnix().unixTimeToWinTime() |
| 10:18:03 | hal1 | echo wint |
| 10:18:17 | hal1 | time.nim(4, 30) Error: type mismatch: got <int64> |
| 10:18:19 | hal1 | but expected one of: |
| 10:18:21 | hal1 | proc unixTimeToWinTime(time: CTime): int64 |
| 10:18:22 | Araq | check how winlean.nim does it |
| 10:18:23 | hal1 | expression: unixTimeToWinTime(toUnix(getTime())) |
| 10:19:06 | hal1 | there the linux time is multiplied and added to by two constants for the conversion |
| 10:19:43 | dom96 | https://github.com/nim-lang/Nim/blob/master/lib/pure/times.nim#L57 |
| 10:19:51 | dom96 | I think these should be exported |
| 10:20:05 | dom96 | Otherwise you can only guess how to use unixTimeToWinTime |
| 10:20:10 | FromGitter | <GULPF> `unixTimeToWinTime`and `winTimeToUnixTime` are messy because previously `posix.Time` and `times.Time` was the same type. They should probably be replaced with proper conversion procs for `posix.Time` and `winlean.FILETIME` in the future. |
| 10:21:12 | FromGitter | <nathandaly> @FromIRC Thanks I was missing the `= @[]` Is there general started documentation? |
| 10:22:50 | FromGitter | <nathandaly> Is there general started documentation? a lot of the examples aren't basic mistake prevention :) |
| 10:24:00 | dom96 | nathandaly: https://nim-lang.org/docs/tut1.html#advanced-types-sequences |
| 10:26:48 | hal1 | they could be exported or if there was something that gave a winlean.FILETIME as result that would be good yes. That was why I thought if a toWinFileTime for time made sense. How should I best proceeed with this? Can I change unixTimeToWinTime to accept int64 and return winlean.FILETIME? |
| 10:28:01 | hal1 | Sorry, got to go for a bit. I'll read answers when I return. |
| 10:30:18 | * | floppydh_ quit (Remote host closed the connection) |
| 10:31:10 | * | floppydh_ joined #nim |
| 10:33:24 | FromGitter | <GULPF> @hal1 Don't change it, it might break stuff. I'd suggest adding `proc toFILETIME(t: Time): FILETIME` and `fromFILETIME(ft: FILETIME): Time`to the times module. |
| 10:35:07 | FromGitter | <GULPF> and then unixTimeToWinTime can be deprecated |
| 10:41:46 | FromGitter | <tim-st> @dom96 do you heard of this behaviour: https://github.com/2vg/mofuw/issues/31 (the same happens for jester minimal example) is it normal? |
| 10:45:10 | * | leorize joined #nim |
| 10:49:56 | dom96 | GULPF: Are we sure that Win time is only used for this FILETIME structure? |
| 10:50:19 | dom96 | I would suggest keeping things simple, we can fix this unixTimeToWinTime thing later |
| 10:51:09 | dom96 | To be honest, I don't think low-level structures like FILETIME belong in the times module |
| 10:52:29 | dom96 | tim-st: yeah, I dunno, there are some problems to do with memory usage |
| 10:52:33 | dom96 | I'm not sure how to solve them |
| 10:52:53 | FromGitter | <tim-st> ok, thanks. Does it happen on unix too? |
| 10:54:44 | FromGitter | <tim-st> I will test it later in vm, I have the feeling it is because of async |
| 11:09:23 | dom96 | yes |
| 11:09:39 | dom96 | If you can figure out the reason it happens that would be awesome :) |
| 11:14:19 | Araq | ping shashlick |
| 11:17:38 | * | leorize quit (Quit: WeeChat 2.1) |
| 11:18:32 | * | vlad1777d joined #nim |
| 11:21:46 | * | NimBot joined #nim |
| 11:22:57 | * | vlad1777d quit (Ping timeout: 240 seconds) |
| 11:23:29 | FromGitter | <krux02> it's a bit off topic, but the author of the famous WAT screencast made all his commercial screencasts free until 10.4.2018 (10th of April) https://www.destroyallsoftware.com/screencasts/catalog |
| 11:32:14 | skelett2 | Is there a way to make the nim compiler automatically detect the missing type in `can_fail` so that `err("fail")` works? https://files.skelett.io/test.nim |
| 11:33:25 | skelett2 | I'm trying to implement something similiar to the `Result` type from rust |
| 11:35:06 | FromGitter | <krux02> skelett2: the common naming scheme for the enum would be ResultKind, not ResultType, because the result type is already `Result` |
| 11:35:26 | dom96 | skelett2: No, Nim can't infer those types currently |
| 11:35:55 | skelett2 | krux02: changed, thanks! |
| 11:36:41 | skelett2 | dom96: that's unfortunate. Thanks! |
| 11:36:45 | dom96 | although hrm |
| 11:36:51 | FromGitter | <krux02> well the result type is usually the type of result, so you can make it a method |
| 11:36:59 | FromGitter | <krux02> result.fail("err") |
| 11:37:16 | FromGitter | <krux02> but the problem is that then you have to specify the error type |
| 11:37:38 | dom96 | strange that `result.err("fail")` doesn't work |
| 11:37:58 | dom96 | krux02: there should be no need for methods |
| 11:38:22 | dom96 | Araq: Thoughts ^ ? |
| 11:38:22 | FromGitter | <krux02> dom96: well I think I accidentially swapped err and fail |
| 11:38:59 | skelett2 | `Error: in expression 'result.err("fail")': identifier expected, but found 'result.err'` |
| 11:39:25 | FromGitter | <krux02> I would make the result type without a generic type in the error though |
| 11:39:37 | FromGitter | <krux02> I would just create an error type that handles errors well. |
| 11:40:26 | dom96 | skelett2: I would say this is a bug, at the very least the error message should be better |
| 11:40:37 | FromGitter | <krux02> I think the error is one of the rare cases where I would accept a ref type |
| 11:40:41 | FromGitter | <narimiran> @dom96 @Araq is there a consensus regarding `split` and `replace`regarding empty string parameter? returning the original string or raising an error? (or should i leave to you two to sleep on it?) |
| 11:40:58 | FromGitter | <krux02> so that you can create a list of errors each containing their root cause |
| 11:41:15 | dom96 | krux02: sure, there are many ways to design it. But the author wants to emulate Rust |
| 11:41:42 | FromGitter | <krux02> that's true though |
| 11:41:54 | dom96 | skelett2: Please report it: https://github.com/nim-lang/Nim/issues/ |
| 11:42:28 | FromGitter | <krux02> this is a good use case for the `Nothing` type |
| 11:42:36 | FromGitter | <krux02> that doesn't exist in Nim |
| 11:43:39 | skelett2 | I'm trying to narrow that bug down to a minimal case |
| 11:44:24 | dom96 | skelett2: awesome, thanks |
| 11:45:09 | * | rokups joined #nim |
| 11:51:01 | * | athenot_ quit (Ping timeout: 245 seconds) |
| 11:52:13 | * | athenot joined #nim |
| 11:52:28 | skelett2 | Ok problem seems to be that the member of the object is called the same as a function |
| 11:53:19 | skelett2 | so `<obj>.foo` can either be the `<obj>.foo` or `foo(<obj>` |
| 11:53:55 | skelett2 | => it's ambiguous |
| 11:56:14 | skelett2 | s/the same as a function/the same as a function accepting an instance of this object as first argument/ |
| 11:56:36 | FromGitter | <krux02> http://ix.io/172a |
| 11:57:02 | FromGitter | <krux02> skelett2: I could get a bit further, but still no solution |
| 11:58:20 | skelett2 | cool idea! |
| 12:00:26 | dom96 | skelett2: Ahh yes, so all you need to do is rename the field :) |
| 12:00:33 | dom96 | Definitely needs a better error message |
| 12:00:34 | dom96 | please report it |
| 12:00:38 | Araq | no need |
| 12:00:45 | Araq | I just fixed the error message |
| 12:01:49 | FromGitter | <krux02> skelett2: when you come over to gitter, your s/../../ substitution would actually change your comment in the past instead of sending it |
| 12:05:37 | dom96 | krux02: and none of us on IRC would see it |
| 12:06:04 | FromGitter | <krux02> ¯\_(ツ)_/¯ |
| 12:10:13 | Araq | never mind report it properly, this is not easy to solve |
| 12:10:22 | Araq | other error messages get worse with my fix :P |
| 12:11:17 | skelett2 | https://github.com/nim-lang/Nim/issues/7523 |
| 12:15:10 | Araq | ty |
| 12:18:05 | * | nsf quit (Quit: WeeChat 2.0.1) |
| 12:33:42 | FromGitter | <krux02> Araq: should I also create a identName proc? It would be analog to symName |
| 12:34:27 | FromGitter | <krux02> I would really like to call it then just `proc name(arg: NimNode)`, but sadly that function is already taken |
| 12:35:30 | FromGitter | <tim-st> @dom96 I tried different gcs when I use your jester example with `--gc:v2` the server crashes after ~15 requests with `SIGSEGV: Illegal storage access. (Attempt to read from nil?)`. Should every gc work with jester? |
| 12:36:49 | dom96 | perhaps Araq can answer that |
| 12:37:18 | FromGitter | <tim-st> ok |
| 12:38:53 | Araq | tim-st: well v2 is supposed to be stable. it crashes bootstrapping though :-( |
| 12:39:58 | FromGitter | <krux02> just a random thought about GC. when I last thought why is disliked GC so much, it was not that GC did only do harm. One issue was the GC always was a global thing that lived undermined everything. It could be tweaked, but only globally for a specific program. And that is a pretty bad situation when one module says "set the GC to A" and the other module said "set the GC to B". |
| 12:40:16 | FromGitter | <krux02> So thread local GC is really a good thing. |
| 12:40:21 | * | max3 joined #nim |
| 12:41:08 | FromGitter | <krux02> it would be best if the GC woul not be a compiler setting, but a thread thing. |
| 12:41:29 | Araq | think about the codegen implications and you know why we don't do that |
| 12:42:05 | FromGitter | <krux02> wel I have no idea about the codegen implications, but now that you remind me of it, yea you are right |
| 12:42:06 | dom96 | We really need something to help diagnose memory leaks |
| 12:42:27 | FromGitter | <tim-st> @araq ok thanks |
| 12:42:45 | dom96 | Is it possible to get a memory dump of a running application and then look for duplicated values? |
| 12:42:47 | FromGitter | <krux02> but it would really be cool |
| 12:42:51 | dom96 | Maybe that could help us find what is leaking? |
| 12:43:09 | FromGitter | <krux02> dom96: where do you have a memory leak? |
| 12:43:17 | Araq | for leaks we have some mechanisms, dumpNumberOfInstances() |
| 12:43:33 | dom96 | krux02: in the forum, nimbot, etc. |
| 12:43:45 | dom96 | Any program that uses async leaks |
| 12:44:00 | Araq | oh, wasn't aware it's that bad :P |
| 12:44:05 | FromGitter | <krux02> well gcc has some tools for that, too |
| 12:44:19 | FromGitter | <krux02> there is the address sanitizer |
| 12:44:22 | Araq | but SSL leaks memory |
| 12:44:27 | FromGitter | <krux02> and valgrind |
| 12:44:40 | Araq | most leaks I've seen are in the stdlib |
| 12:44:57 | FromGitter | <tim-st> @krux02 try a jester minimal example, I'm not sure if that's normal but with each ten times I press F5 in browser on localhost it eats 80kb memory and size grows in memory |
| 12:46:00 | dom96 | problem is that it takes a long time to get the memory up |
| 12:46:07 | dom96 | days of uptime |
| 12:46:09 | dom96 | if not weeks |
| 12:46:24 | Araq | again, SSL wrapper leaks memory |
| 12:46:30 | Araq | and HTTPS is everywhere |
| 12:46:38 | FromGitter | <tim-st> I didnt use ssl (I think) |
| 12:46:56 | dom96 | Araq: I doubt that's it |
| 12:48:57 | Araq | that is a leak that only shows up after weeks |
| 12:49:06 | Araq | probably there are others though :P |
| 12:49:55 | FromGitter | <krux02> I am pretty sure the compiler leaks, too. but it doesn't become a problem because the compiler just quits and the memory is free again |
| 12:54:00 | skelett2 | with which gcs do the leaks happen? |
| 12:54:05 | Araq | nimsuggest doesn't leak though. at least not in the tests that I did with it |
| 12:54:44 | Araq | the compiler itself disables the mark&sweep step in order to run faster :P |
| 12:55:08 | Araq | also by its nature it can only "leak" memory. |
| 12:55:11 | dom96 | I've seen people complaining about high nimsuggest memory usage |
| 12:55:22 | Araq | high memory usage != leak |
| 12:55:26 | dom96 | True |
| 12:55:36 | dom96 | Currently using 300MB on my system |
| 12:55:41 | hal1 | In preparation for an eventual pull request should I make changes based on the devel branch? |
| 12:55:47 | dom96 | hal1: yep |
| 12:56:01 | * | floppydh_ quit (Remote host closed the connection) |
| 12:56:12 | Araq | but yeah, I wouldn't write the compiler in this way anymore... takes up too much memory, too little control over it too |
| 12:56:50 | * | floppydh_ joined #nim |
| 12:58:05 | FromGitter | <tim-st> @ skeIett2 I don't know if that's called a memory leak or if it's normal for a webserver to consume 80kb per ten times F5 in browser and dont free it. But if that's not normal then all that I tried and v2 crashed |
| 12:58:40 | dom96 | 80kb isn't much |
| 12:59:01 | FromGitter | <tim-st> yes, but shouldnt they free it after some minutes? |
| 12:59:18 | FromGitter | <tim-st> otherwise my webserver could only server the fist x users |
| 13:00:29 | dom96 | Use 'wrk' on it |
| 13:00:37 | dom96 | That will hit it with thousands of requests |
| 13:00:49 | FromGitter | <tim-st> ok, will try, thanks |
| 13:01:51 | FromGitter | <tim-st> Though I'm interested, what is stored at all in the memory (when I just ship out "hello world") besides possible tcp connection keep alive? |
| 13:03:03 | hal1 | I'm following the instructions on compiling right now. Once that is done and after I changed for example times.nim will a ./koch boot be enough to build that changed version? |
| 13:03:21 | dom96 | Many things, the file descriptors for the TCP connections and the event loop, buffers for the sockets |
| 13:04:27 | FromGitter | <tim-st> ok, thanks. I thought only on tcp syn flood information of this size stays in memory and not on regular calls |
| 13:04:32 | FromGitter | <krux02> dom96: I just looked up this pattern to find memory leaks from Eskil Steenberg |
| 13:05:20 | * | leorize joined #nim |
| 13:05:48 | FromGitter | <krux02> he has a macro that replaces every instance of malloc with his own allocation that stores along with the allocation the line and the file where the allocation happens. that means whenever there is some leaked memory it can be tracked down to where it leaked. |
| 13:06:00 | FromGitter | <krux02> but that is a patter from C. I don't know how that applies to Nim |
| 13:06:11 | Araq | Nim's GC does that, check its source code |
| 13:06:25 | dom96 | If Nim's GC does that, then how can I enable this thing? |
| 13:06:26 | FromGitter | <krux02> cool |
| 13:06:32 | Araq | but dumpNumberOfInstances works better |
| 13:06:50 | dom96 | what's dumpNumberOfInstances? |
| 13:07:07 | Araq | compile with -d:nimTypeNames |
| 13:07:17 | Araq | and then it's a proc you can call at runtime from time to time |
| 13:07:23 | Araq | and see where things grow |
| 13:07:44 | Araq | documented in the wiki |
| 13:07:59 | FromGitter | <krux02> that is pretty cool |
| 13:08:10 | Araq | but our wiki is not an article by Eskil Steenberg, so *shrug* :P |
| 13:08:25 | dom96 | But it's by the great Andreas Rumpf |
| 13:08:28 | FromGitter | <krux02> Araq: should I give NimIdent the same treatment as NimSym? |
| 13:08:31 | dom96 | :) |
| 13:08:35 | Araq | lol |
| 13:08:45 | dom96 | Okay, I will play around with this later |
| 13:08:46 | Araq | krux02: I think so |
| 13:09:02 | FromGitter | <krux02> then I will do it. |
| 13:22:37 | hal1 | dom96: sorry about all the questions, I have not actually done a pull request before. Could you give me some pointers perhaps? I made a very small change in times so that CTime type is exported. That allows one to use this for example: CTime(getTime().toUnix()).unixTimeToWinTime() |
| 13:23:08 | hal1 | Would it be ok to put that in a PR so I know how that process works or is it too much hassle for such a small thing? |
| 13:29:27 | dom96 | You can start off by committing this change to a new branch |
| 13:29:42 | dom96 | Creating a PR then is just the click of a button on GitHub |
| 13:30:00 | dom96 | (Before you can push the changes though, you'll need to have forked the repo) |
| 13:36:12 | * | floppydh_ quit (Quit: WeeChat 2.1) |
| 13:38:42 | euantor | `dumpNumberOfInstances` is indeed very useful. I've used it in the past and it's really helpful |
| 13:42:25 | hal1 | dom96: Thanks. Does the branch name matter or is there a naming schema I should be aware of? |
| 13:42:39 | dom96 | hal1: nope, name it whatever you wish |
| 13:42:53 | dom96 | best names are descriptive though |
| 13:43:30 | hal1 | the PR can consist of multiple commits in the end? |
| 13:44:02 | def- | yes |
| 13:44:21 | FromGitter | <GULPF> @hal1 @dom96 I really don't think we should export CType. @hal1 don't need to fix this mess in this PR, just copy the logic from `unixTimeToWinTime`to os.nim for now. Having to do `CTime(getTime().toUnix()).unixTimeToWinTime()` is not sane |
| 13:45:22 | dom96 | GULPF: Let's be aware of hal1's time, we can always fix this later. |
| 13:46:31 | FromGitter | <GULPF> that's why I said he doesn't need to fix it |
| 13:46:59 | dom96 | yeah, but asking to make constant changes will get tiring :) |
| 13:47:20 | hal1 | Oh I'm happy to work on this. Excited to contribute something to a project, no need to worry about my time. If you have patience with me to guide me to what to do I'm glad to do it. |
| 13:47:38 | dom96 | In that case, listen to GULPF :) |
| 13:49:02 | hal1 | GULPF: there is however the issue that if I duplicate the unixTimeToWinTime in os that I need two constants which are also not exported |
| 13:49:06 | hal1 | const |
| 13:49:09 | hal1 | epochDiff = 116444736000000000'i64 |
| 13:49:11 | hal1 | rateDiff = 10000000'i64 # 100 nsecs |
| 13:49:22 | hal1 | are used to convert the time from one system to the other |
| 13:51:13 | FromGitter | <GULPF> You can copy those over as well. I'll write a PR later to fix the code duplication |
| 13:52:08 | hal1 | Alright. Out of interest how would you fix that, what is the correct or better way to do it? |
| 13:53:12 | Araq | import winlean? |
| 13:53:39 | * | athenot_ joined #nim |
| 13:53:52 | FromGitter | <GULPF> Well what we need are procs for converting `Time`->`FILETIME` and `FILETIME`->`Time` |
| 13:54:21 | dom96 | I think it's subject to debate whether these should be exposed in the times module |
| 13:54:41 | dom96 | The FILETIME structure is a windows-specific and low-level structure. |
| 13:55:05 | * | athenot quit (Ping timeout: 265 seconds) |
| 13:55:08 | FromGitter | <GULPF> yes but they need to be somewhere, and both times.nim and os.nim needs the `FILETIME`->`Time` proc |
| 13:55:21 | dom96 | why does times need it? |
| 13:56:20 | FromGitter | <GULPF> for getting the current time. I don't remember how it does it now, but it in my sub second resolution PR it gets the current time as a FILETIME |
| 13:57:19 | Araq | FILETIME belongs in winlean.nim |
| 13:57:32 | FromGitter | <GULPF> the type yes |
| 13:58:13 | Araq | and the helpers too |
| 13:58:16 | dom96 | yeah |
| 13:58:20 | dom96 | both the type and the helpers |
| 13:58:32 | dom96 | FILETIME is used in epochTime |
| 13:58:33 | dom96 | https://github.com/nim-lang/Nim/blob/devel/lib/pure/times.nim#L1361 |
| 13:58:33 | FromGitter | <GULPF> but winlean can't import times without a circular dependency, so it can't defined a `FILETIME`->`Time` proc |
| 13:59:07 | dom96 | So it needs to return some other type |
| 13:59:07 | Araq | winlean should not import times |
| 13:59:16 | dom96 | times module shouldn't export such a low-level procedure |
| 13:59:37 | Araq | winlean is for the Win API, the Win API doesn't depend on our times.nim |
| 13:59:50 | Araq | there is a clear hierarchy here |
| 13:59:54 | FromGitter | <GULPF> oh I agree that winlean shouldn't import times |
| 14:00:45 | dom96 | Actually, I think CTime should also defined in posix and winlean |
| 14:00:56 | FromGitter | <GULPF> CTime is in posix |
| 14:01:01 | FromGitter | <GULPF> it's the same type as posix.Time |
| 14:01:08 | dom96 | and then you can define a helper to convert from FILETIME to CTime in winlean |
| 14:01:27 | * | SenasOzys quit (Ping timeout: 260 seconds) |
| 14:01:31 | FromGitter | <GULPF> we don't want FILETIME->CTime, because that's not a lossless conversion |
| 14:01:46 | FromGitter | <GULPF> CTime is in seconds, FILETIME is in hectonanoseconds |
| 14:02:01 | FromGitter | <GULPF> Time is in seconds now, but in nanoseconds after my PR |
| 14:02:27 | * | endragor quit (Remote host closed the connection) |
| 14:02:38 | FromGitter | <GULPF> we could have `FILETIME` -> tuple[unix seconds, nanoseconds] in winlean I suppose |
| 14:03:23 | dom96 | I think that would be better |
| 14:05:02 | FromGitter | <GULPF> yes I think that's the best option |
| 14:05:11 | hal1 | apart from the FILETIME issue, shouldn't it be possible to run some version of time.toUnix().unixTimeToWinTime()? CTime is not defined in winlean, and not exported in times but unixTimeToWinTime expects it as parameter type |
| 14:05:44 | * | endragor joined #nim |
| 14:06:27 | FromGitter | <GULPF> I'd rather see that unixTimeToWinTime gets deprecated. CTime shouldn't be a part of the times api |
| 14:06:42 | * | SenasOzys joined #nim |
| 14:09:11 | hal1 | Could a proc also be added to winlean that works the other way unix seconds -> FILETIME? And if so, do you mind if I give that a try? |
| 14:10:18 | * | endragor quit (Ping timeout: 260 seconds) |
| 14:10:53 | hal1 | then time.toUnix() (from times, it returns a int64) could be the input for that proc in winlean that returns a FILETIME from unixtime? |
| 14:11:19 | FromGitter | <GULPF> that sounds fine, but do it with unix seconds + nanoseconds so it's still easy when Time gets nanosecond resolution |
| 14:11:45 | hal1 | like your tuple example just the other way around |
| 14:11:55 | FromGitter | <GULPF> e.g proc toFILETIME(unix: seconds, ns: nanoseconds): FILETIME |
| 14:12:00 | hal1 | right |
| 14:12:25 | FromGitter | <GULPF> *unix: int64, nanoseconds: int |
| 14:17:18 | * | noonien joined #nim |
| 14:28:53 | FromGitter | <tim-st> @dom96 I now tested it using wrk and it seems to work quite good (it uses quickly ~25mb ram, but after this never more), so probably everything is good, thanks for your help |
| 14:31:47 | * | craigger quit (Quit: bye) |
| 14:31:55 | * | craigger joined #nim |
| 14:32:08 | * | rauss joined #nim |
| 14:50:15 | * | miran joined #nim |
| 14:57:40 | hal1 | what is an easy way to see the bit represantion of an int? |
| 15:00:21 | FromGitter | <mratsim> bit or byte? |
| 15:00:51 | hal1 | bit would be best |
| 15:01:47 | FromGitter | <mratsim> for bit representation you will have to fiddle with masking and shr like here: https://github.com/mratsim/chirp8/blob/master/src/cpu.nim#L245 |
| 15:01:53 | FromGitter | <mratsim> this unpack bits from a byte |
| 15:02:18 | FromGitter | <mratsim> for byte representation you just need to castarray[8, byte (yourint) |
| 15:02:43 | FromGitter | <mratsim> urgh gitter ate my brackets ... |
| 15:02:59 | hal1 | thank you |
| 15:03:04 | FromGitter | <mratsim> cast to array\[8, byte\] your integer for byte representation |
| 15:05:15 | FromGitter | <alehander42> :D |
| 15:05:26 | FromGitter | <alehander42> gitter loves brackets |
| 15:10:29 | hal1 | sorry I thought I got that with the array but I didn't. I also can't find the documentation for cast atm |
| 15:14:28 | FromGitter | <mratsim> it’s in the system module |
| 15:14:41 | FromGitter | <mratsim> It’s raining RFCs :O |
| 15:15:13 | FromGitter | <mratsim> cast\newType\ (old_variable) |
| 15:15:50 | FromGitter | <mratsim> it’s hidden because it’s unsafe and very low-level |
| 15:18:16 | * | nsf joined #nim |
| 15:20:25 | FromGitter | <narimiran> `testnewType (old_variable)` |
| 15:20:47 | FromGitter | <narimiran> nope, doesn't like brackets even inside of a code block |
| 15:20:49 | * | Trustable joined #nim |
| 15:21:20 | hal1 | ah, got it: cast[array[8, byte]](myint) |
| 15:23:32 | * | tiocavera joined #nim |
| 15:23:32 | * | tiocavera quit (Changing host) |
| 15:23:32 | * | tiocavera joined #nim |
| 15:23:32 | * | rockcavera is now known as Guest35261 |
| 15:23:32 | * | Guest35261 quit (Killed (karatkievich.freenode.net (Nickname regained by services))) |
| 15:23:32 | * | tiocavera is now known as rockcavera |
| 15:47:24 | * | yglukhov quit (Read error: Connection reset by peer) |
| 15:47:58 | * | yglukhov joined #nim |
| 15:49:17 | * | aguspiza joined #nim |
| 15:52:07 | * | miran quit (Quit: Konversation terminated!) |
| 15:54:19 | * | xkapastel joined #nim |
| 15:55:49 | * | miran joined #nim |
| 15:55:57 | dom96 | mratsim: hal1: If I understand correctly, you can also just use toBin: https://nim-lang.org/docs/strutils.html#toBin,BiggestInt,Positive |
| 15:58:24 | FromGitter | <mratsim> oh I didn’t know about that one |
| 16:03:10 | dom96 | Some really awesome results for @2vg's web framework: https://github.com/tbrand/which_is_the_fastest/issues/101#issuecomment-379293774 |
| 16:04:14 | * | leorize quit (Ping timeout: 276 seconds) |
| 16:05:04 | dom96 | Beating everything except cpp_evhtp |
| 16:05:12 | dom96 | I really need to get httpbeast finished :) |
| 16:05:40 | * | leorize joined #nim |
| 16:07:45 | * | leorize quit (Client Quit) |
| 16:09:49 | Araq | cool |
| 16:10:12 | Araq | speaking of which ... my new toy project should finally be packedjson.nim |
| 16:10:43 | FromGitter | <alehander42> wow mofuw is cool, finally beating crystal at those web games :D |
| 16:10:50 | FromGitter | <alehander42> the README is brilliant haha |
| 16:12:33 | dom96 | Araq: Not translating system shock to Nim? :( |
| 16:17:55 | Yardanico | dom96, it would be awesome if mofuw would have roughly the same results without unsafe operations ;) |
| 16:18:04 | shashlick | hey araq - just catching up here, saw your message |
| 16:18:17 | Yardanico | but it's very impressive |
| 16:18:58 | dom96 | Yardanico: hrm, true |
| 16:19:14 | Yardanico | faster than rust/go and all other languages :D |
| 16:19:20 | dom96 | But nonetheless, impressive |
| 16:19:43 | dom96 | hope @2vg won't be dissuaded if I work on httpbeast :) |
| 16:19:55 | dom96 | Always better to have two fast http servers than just one |
| 16:19:59 | Yardanico | yeah |
| 16:28:08 | dom96 | So, let's see what I can get done on httpbeast today |
| 16:28:29 | dom96 | Hope my dissertation doesn't suffer too much as a result |
| 16:29:02 | * | aguspiza quit (Ping timeout: 260 seconds) |
| 16:31:12 | * | sendell quit (Remote host closed the connection) |
| 16:32:25 | miran | ...famous last words |
| 16:33:28 | Araq | shashlick: where is your gist about Nim's potential versioning again? |
| 16:34:23 | Araq | dom96: meh, it's system shock, not system shock *2* |
| 16:34:30 | shashlick | https://gist.github.com/genotrance/4e4158909972617082dc223b2bb0b2f0 |
| 16:34:48 | dom96 | Araq: hah |
| 16:38:16 | Araq | shashlick: mind to make that an RFC? |
| 16:39:31 | shashlick | Sure, both or just trunk based? |
| 16:39:48 | dom96 | Which do you suppose is faster for a simple hello world benchmark: keeping a cache of common requests and responses (with all the expiration logic that comes with this approach) or not doing that? |
| 16:40:43 | dom96 | shashlick: Make an RFC but link to that gist instead of embedding it. |
| 16:41:29 | shashlick | Ok cool |
| 16:48:48 | dom96 | meh, getting rid of the caching |
| 16:48:52 | FromGitter | <mratsim> @dom96 Your question triggered the following keywords in my head: “memoization”, “LRU cache”, “Look-up tables” …. |
| 16:52:26 | * | krux02 joined #nim |
| 16:57:40 | Araq | just forget about the cache and optimize it properly :P |
| 16:58:36 | dom96 | that's what I'm doing :) |
| 17:01:37 | shashlick | RFC created - https://github.com/nim-lang/Nim/issues/7527 |
| 17:05:44 | dom96 | of course, wrk, curl and chrome all send HTTP requests differently |
| 17:07:10 | * | dom96 wonders why browsers are sending crap after the \c\r |
| 17:11:17 | dom96 | oh! |
| 17:11:30 | FromGitter | <Varriount> ? |
| 17:11:46 | dom96 | Bug in my code :) |
| 17:13:30 | dom96 | I'm finding myself reaching for unsafe Nim too |
| 17:14:13 | FromGitter | <krux02> what is unsafe in your code? |
| 17:14:16 | FromGitter | <krux02> race condition |
| 17:14:24 | FromGitter | <krux02> nil dereference? |
| 17:14:31 | dom96 | use of 'addr' |
| 17:14:47 | FromGitter | <krux02> well the use of "addr" is not per se unsafe |
| 17:15:08 | dom96 | Any usage of 'ptr', 'addr', 'cast' is unsafe |
| 17:15:26 | dom96 | It's the unsafe subset of Nim |
| 17:15:31 | dom96 | Doesn't matter if the code is proven to be safe |
| 17:15:32 | FromGitter | <krux02> in c you do that all day long, and people write good software with it (of course also a lot of crap) |
| 17:16:02 | FromGitter | <krux02> I am not sure if there is a "safe" subset in Nim |
| 17:16:16 | FromGitter | <krux02> I mean Nim doesn't prevent you from race conditions like rust does |
| 17:16:57 | FromGitter | <krux02> also nim has lot's of nil ref types |
| 17:17:08 | FromGitter | <krux02> I don't think ref are much safer than ptr types |
| 17:17:44 | FromGitter | <krux02> the only thing ref's do is they free the memory, when the object is not referenced anymore, but apart from that there is nothing they provide |
| 17:17:54 | * | aguspiza joined #nim |
| 17:19:31 | FromGitter | <krux02> don't assume you are safe, just because you don't use "ptr" "addr" and "cast" |
| 17:20:39 | Araq | there is a memory safe subset of Nim and 'nil' doesn't introduce memory unsafety otherwise C# and Java are "unsafe" too and that's simply not a useful definition |
| 17:21:13 | dom96 | 'ref' is significantly safer than 'ptr' |
| 17:22:36 | dom96 | Also, I'm fairly sure Nim offers similar race condition protections as Rust |
| 17:24:38 | FromGitter | <tim-st> @dom96 which gc was used for compilation for the results you linked? I remember that I read on an other benchmark page markAndSweep was determined to be best for this with nim |
| 17:25:04 | dom96 | tim-st: no idea, probably default |
| 17:25:12 | FromGitter | <tim-st> ok |
| 17:27:39 | * | nsf quit (Quit: WeeChat 2.0.1) |
| 17:27:55 | * | leorize joined #nim |
| 17:32:56 | Araq | use-after-free -- impossible with 'ref', possible with 'ptr'. |
| 17:33:01 | dom96 | ugh, I can't seem to set max fds on macOS |
| 17:33:51 | FromGitter | <krux02> Araq: true, but that doesn't make ref safe |
| 17:33:57 | FromGitter | <krux02> you can still have race conditions |
| 17:35:26 | FromGitter | <krux02> my argument is, you still have to know what you are doing, no matter if you use ref or ptr. I think I can pretty much avoid use after free. I don't claim to be perfect here, but I did that mistake already often enough. |
| 17:35:43 | FromGitter | <krux02> also pointer into a seq and then appending to the seq |
| 17:35:49 | dom96 | My god Apple, https://blog.dekstroza.io/ulimit-shenanigans-on-osx-el-capitan/ :'( |
| 17:37:36 | dom96 | Yeah, I'm just going to give up on that lol |
| 17:39:57 | FromGitter | <krux02> dom96: where does nim provide race condition checks similar to rust? |
| 17:40:20 | dom96 | gc safety |
| 17:40:24 | dom96 | You can't share memory between threads |
| 17:40:33 | FromGitter | <krux02> well you can |
| 17:40:38 | FromGitter | <krux02> createShared |
| 17:40:42 | dom96 | hehe |
| 17:40:46 | dom96 | And what does that create? |
| 17:40:47 | dom96 | A 'ptr' |
| 17:41:09 | dom96 | i.e. it's unsafe |
| 17:43:14 | FromGitter | <krux02> and what happens when you pass a ref from thread to thread? |
| 17:43:19 | dom96 | it gets copied |
| 17:43:19 | FromGitter | <krux02> I never tried it |
| 17:43:36 | FromGitter | <krux02> the ref or the value behind the ref? |
| 17:43:52 | dom96 | the object behind the ref |
| 17:45:06 | FromGitter | <krux02> well I actually did't know that |
| 17:45:21 | FromGitter | <krux02> maybe I should try to create a thread now |
| 17:46:58 | FromGitter | <wu-lee> On this topic, how well does nim support immutable data? i.e. enforcing it, as well as supporting persistent (i.e. data-sharing) datastructures? |
| 17:50:45 | * | SenasOzys quit (Ping timeout: 264 seconds) |
| 17:51:03 | FromGitter | <krux02> well arguments (when you don't use ref types) are by default immutable |
| 17:51:14 | FromGitter | <krux02> so it encourages not to mutate data |
| 17:54:30 | FromGitter | <wu-lee> But refs are pretty unavoidable, no? |
| 17:55:20 | dom96 | What makes you think that? |
| 17:56:50 | * | SenasOzys joined #nim |
| 17:57:04 | FromGitter | <wu-lee> If you want to define a sharing datastructure, for instance. Or use polymorphism. |
| 17:58:26 | FromGitter | <wu-lee> But I'd be very happy to be proved wrong :) |
| 17:58:28 | dom96 | You can achieve polymorphism using generics too |
| 17:58:30 | FromGitter | <mratsim> Are there shared immutable data structure? |
| 17:59:12 | FromGitter | <krux02> well all immutable datastructures can be safely shared |
| 17:59:35 | FromGitter | <krux02> the problem is that Nim doesn't help you with "immutable" datastructure |
| 17:59:35 | FromGitter | <wu-lee> Clojure's datatypes are all immutable, I believe based on fancy stuff like finger trees, typically. But a simple case is a linked list, as in lisp. |
| 17:59:56 | FromGitter | <mratsim> https://github.com/vegansk/nimfp |
| 18:00:02 | FromGitter | <wu-lee> Two lists can share the same tail. |
| 18:00:09 | FromGitter | <krux02> @wu-lee but clujure is a lisp and that has other problems, for example bad memory layout. |
| 18:00:44 | FromGitter | <krux02> they say they have a performance penalty factor of 4 compared to other languages |
| 18:00:51 | FromGitter | <wu-lee> @krux02 - as may be, that's besides the point really |
| 18:00:58 | FromGitter | <krux02> yea it is |
| 18:01:02 | FromGitter | <mratsim> Basically if you can prevent people from dereferencing your ref object, you can be immutable. |
| 18:01:55 | dom96 | hrm, unittest module doesn't really support async tests :) |
| 18:01:59 | FromGitter | <mratsim> otherwise for ref Nim only allows shallow immutability, if you search in the forum for that, you will see a couple of my posts talking about shallow immutability, write-tracking and stuff like this |
| 18:02:18 | FromGitter | <mratsim> with a reference to some feature requests |
| 18:02:21 | FromGitter | <krux02> @mratsim I think you can provide a getter fuction that returns an object by value that is stored on the shared heap |
| 18:02:39 | FromGitter | <wu-lee> Am I right to think that nim doesn't copy the content of refs passed as (non var) parameters? |
| 18:02:59 | FromGitter | <mratsim> var are not copied either |
| 18:03:06 | FromGitter | <wu-lee> i.e. like `const &` in C++ |
| 18:03:08 | FromGitter | <krux02> ``proc getImmutableObject(): ObjectType = objptronsharedheap[] |
| 18:03:30 | FromGitter | <mratsim> Nim only copies primitive types or array with a size less than 3 words. |
| 18:03:41 | FromGitter | <krux02> yes and the return values are also not copied as long as you don't assign them to a variable |
| 18:03:46 | * | xkapastel quit (Quit: Connection closed for inactivity) |
| 18:03:59 | FromGitter | <wu-lee> useful to know... |
| 18:04:08 | FromGitter | <tim-st> @dom96 When I tested the webservers (e.g. jester) some hours ago I saw only one cpu is used. Wouldnt it be better to use all cpus or atleast 2? |
| 18:04:21 | dom96 | tim-st: yes, it would. I'm working on that now. |
| 18:04:42 | FromGitter | <tim-st> Do you know how information is shared between multiple cpus? |
| 18:04:50 | FromGitter | <tim-st> Python uses tcp sockets for this :( |
| 18:05:12 | dom96 | tim-st: channels |
| 18:05:30 | FromGitter | <tim-st> I mean that could have slow down, or is it better than the python way? |
| 18:05:50 | dom96 | you can also share memory, but that's unsafe |
| 18:05:54 | dom96 | (for now at least) |
| 18:06:01 | FromGitter | <tim-st> ok, thanks |
| 18:06:08 | FromGitter | <krux02> until now `ref` types are like `std::shared_ptr` but now I know they are not |
| 18:06:36 | FromGitter | <wu-lee> Are immutable refs ever going to be supported in nim? |
| 18:06:45 | FromGitter | <krux02> `ref` types are not to share objects with threads and therefore are therefore not std::shared_ptr |
| 18:07:00 | FromGitter | <krux02> @wu-lee I don't think so |
| 18:07:07 | FromGitter | <krux02> but you don't need to |
| 18:07:30 | FromGitter | <krux02> you can just use the underlying value type to make make the type immutable |
| 18:07:44 | FromGitter | <krux02> I also don't want c++ const madness in nim |
| 18:07:52 | FromGitter | <wu-lee> @krux02 - got an example? |
| 18:08:14 | FromGitter | <wu-lee> C++ const madness comes partly from allowing mixed const/mutable fields |
| 18:08:39 | FromGitter | <k0pernicus> Immutable references are great to share between threads - Rust, for example, makes the thing easily, and it gives you safety when you are working with multi-threaded programs |
| 18:08:55 | FromGitter | <wu-lee> @k0pernicus - precisely my point |
| 18:09:02 | FromGitter | <k0pernicus> @krux02 I am interested for an example too :-) |
| 18:09:14 | * | flyx quit (Quit: ZNC - http://znc.in) |
| 18:10:27 | FromGitter | <krux02> hmm, I wonder how to get generically the object type of a ref type |
| 18:10:36 | FromGitter | <krux02> these ref types are everywhere |
| 18:11:16 | dom96 | k0pernicus: If you use Nim's channels then the 'ref' will be copied across to the other thread |
| 18:11:55 | FromGitter | <wu-lee> @krux02 I've been trying to work out how to do that, passing refs as non-ref to ensure immutability, but I am scared of creating incomplete types and shooting my foot |
| 18:12:10 | FromGitter | <krux02> hmm incomplete types? |
| 18:13:43 | FromGitter | <wu-lee> @krux02 given `a : ref RootObj = TypeA.new` and `a2: ref RootObj` then a2[] = a[] won't copy all the fields of `TypeA` |
| 18:14:00 | krux02 | I am struggling myself right now to get the object type from a ref type |
| 18:14:04 | dom96 | wu-lee: why do you need this? |
| 18:15:09 | FromGitter | <wu-lee> I'm trying to understand what's possible with nim. I like the typesafety, but want the thread-safe immutability @k0pernicus refers to. |
| 18:16:23 | krux02 | http://ix.io/177T |
| 18:18:48 | krux02 | http://ix.io/177W |
| 18:20:25 | FromGitter | <mratsim> Relevant discussion/feature request: https://github.com/nim-lang/Nim/issues/6793 |
| 18:20:31 | FromGitter | <wu-lee> @krux02 that's more or less what I've been doing |
| 18:21:31 | FromGitter | <wu-lee> Been tying myself in knots a bit, tho, reaching the limits of my newbie Nim know-how. |
| 18:21:40 | FromGitter | <mratsim> And maybe one day we will get data: https://nim-lang.org/araq/writetracking.html, plus tehre is also the borrow checker hum “lent” checker: https://github.com/nim-lang/Nim/wiki/Destructors |
| 18:21:52 | FromGitter | <mratsim> not data -> that |
| 18:30:08 | Araq | meh I can enable write tracking for 'func' so that you guys can play with it |
| 18:31:52 | * | flyx joined #nim |
| 18:32:05 | FromGitter | <wu-lee> Write tracking is interesting. I believe Clojure solves the const-ness "wart" problem by making *everything* const (as does Haskell). |
| 18:32:35 | FromGitter | <krux02> yea but everything const, I don't bevieve in it |
| 18:32:41 | Araq | clojure gives you immutable data structures, you can use these in Nim too |
| 18:32:44 | FromGitter | <krux02> mutability is necessary |
| 18:32:50 | Araq | doesn't require language support. |
| 18:34:37 | FromGitter | <wu-lee> mutability isn't necessary, apparently. or not in the large. but you have to give some things up, and the consequences are things like, you have to use recursion instead of loops, and some other stuff C programmers would consider batshit |
| 18:35:22 | FromGitter | <wu-lee> but i gather there are big gains in provably correct code, thread safety, etc. |
| 18:35:37 | Araq | not only C programmers, every CPU ever built also considers it batshit |
| 18:35:43 | Araq | ;-) |
| 18:36:14 | FromGitter | <wu-lee> @Araq indeed :) |
| 18:37:26 | hal1 | dom96: toBin looks perfect |
| 18:38:57 | FromGitter | <wu-lee> I think the grand plan is to find a way to compile immutable languages down to CPU-friendly code, minus the bat shit, but still retaining the FP rigor |
| 18:47:31 | * | xkapastel joined #nim |
| 18:51:21 | * | nsf joined #nim |
| 18:57:42 | * | natrys joined #nim |
| 18:59:49 | Widdershins | @wu-lee that's the dream |
| 19:01:30 | dom96 | oh my goodness, why is running processes so difficult :( |
| 19:04:59 | Araq | is this really correct, https://github.com/nim-lang/Nim/pull/7415 ? |
| 19:05:13 | subsetpark | Something I've never understood: if i have an expression like `when (callback is proc(x, y: string)):` - do the names x and y matter? |
| 19:05:30 | subsetpark | Will that not type-match for a procedure declared `proc(y, z: string)`? |
| 19:06:46 | Araq | the names are only for readability |
| 19:06:53 | Araq | they don't affect type checking |
| 19:06:53 | subsetpark | Ok, that's what I've been assuming |
| 19:22:03 | FromGitter | <wu-lee> given a `ref RootObj` can I discover the type of the object it is referencing? (my experiments with typetraits etc. suggest not..) |
| 19:22:39 | FromGitter | <wu-lee> and if I can discover the type, can I then initialise a new ref of the same type? |
| 19:25:12 | FromGitter | <krux02> I think you can |
| 19:25:19 | * | krux02 quit (Remote host closed the connection) |
| 19:59:53 | FromGitter | <mratsim> @wu-lee I understand where you’re coming from, my first language was Haskell, but there are some stuff that are just a pain to do with immutability |
| 20:00:39 | FromGitter | <mratsim> In high performance computing for example you need to control memory allocation very carefully. Embedded device too. |
| 20:31:07 | * | rokups quit (Quit: Connection closed for inactivity) |
| 20:46:04 | Araq | so many open PRs ... |
| 20:53:08 | FromGitter | <k0pernicus> @mratsim I don’t think @wu-lee requests *only* immutability - he asked for a way to pass immutable references in threads :-) |
| 20:55:49 | Yardanico | Araq, https://github.com/nim-lang/Nim/pull/7191 so you will fully remove PHP backend in the near future? |
| 20:56:39 | * | hal1 quit (Quit: WeeChat 1.4) |
| 20:57:57 | * | shashlick quit (Remote host closed the connection) |
| 20:58:14 | * | shashlick joined #nim |
| 21:00:11 | * | natrys quit (Quit: natrys) |
| 21:04:21 | FromGitter | <mratsim> It will be moved to stdlib/php :P |
| 21:09:05 | dom96 | we'll get a COBOL backend next :P |
| 21:10:27 | FromGitter | <k0pernicus> @dom96 I was hoping for brainfuck... |
| 21:11:19 | dom96 | I'm still waiting for someone to make a Brainfuck -> Nim AST macro "compiler" :) |
| 21:16:53 | * | xkapastel quit (Quit: Connection closed for inactivity) |
| 21:20:32 | FromGitter | <data-man> Snowball -> Nim. Then we will have a stemming library. |
| 21:22:30 | Araq | I ported the stemmers for English and German once from Snowball |
| 21:22:45 | Araq | Yardanico, yeah. |
| 21:23:04 | Araq | what's up with that exponentiation operator mess? |
| 21:24:48 | * | Vladar quit (Quit: Leaving) |
| 21:24:52 | Araq | so we have 2 PRs dealing with the same, both wrong in their own ways? |
| 21:28:36 | Widdershins | is there an order-of-operations snafu right now? |
| 21:30:28 | * | jaco60 quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 21:32:48 | * | shashlick quit (Quit: WeeChat 2.1) |
| 21:33:07 | * | shashlick joined #nim |
| 21:35:24 | Araq | Widdershins, what do you mean? |
| 21:38:54 | dom96 | Does unlikely vs. likely actually do much? |
| 21:39:12 | dom96 | I suppose I should check the asm to be sure |
| 21:39:28 | FromGitter | <Varriount> dom96: It can affect how the backend compiler emits branching code. |
| 21:39:50 | FromGitter | <Varriount> Though, it might be more effective if a specific processor is targeted, rather than a general architecture. |
| 21:41:29 | * | miran quit (Quit: Konversation terminated!) |
| 21:41:52 | * | shashlick quit (Quit: WeeChat 2.1) |
| 21:42:09 | * | shashlick joined #nim |
| 22:04:42 | Widdershins | Araq: you were talking about some "exponentiation operator mess", what's the dealio? i'm unfamiliar :) |
| 22:15:40 | * | xkapastel joined #nim |
| 22:16:04 | * | mwbrown quit (Quit: Exiting) |
| 22:16:12 | * | shashlick quit (Quit: WeeChat 2.1) |
| 22:16:21 | dom96 | haha |
| 22:16:22 | dom96 | GC Warning: Repeated allocation of very large block (appr. size 1930674176) |
| 22:16:25 | dom96 | Achievement unlocked? |
| 22:17:11 | * | shashlick joined #nim |
| 22:19:29 | dom96 | Amazing how much damage a missing `i.inc` can cause |
| 22:19:49 | dom96 | At least macOS managed to survive even after it allocated 19gb of RAM |
| 22:20:04 | dom96 | My Mac only has 16 so that's quite a feat |
| 22:20:46 | * | mwbrown joined #nim |
| 22:35:37 | * | xet7 quit (Quit: Leaving) |
| 22:37:14 | Widdershins | i count that as 1.9 billion, not 19 billion |
| 22:37:43 | Widdershins | slightly under 1.8GiB |
| 22:39:01 | Araq | dom96, there is no such GC warning. do you use Boehm? |
| 22:39:37 | dom96 | Araq: I am :) |
| 22:39:56 | Araq | cheater |
| 22:41:11 | dom96 | lol how? |
| 22:41:38 | dom96 | In case anyone wants to look for more optimisation opportunities :) https://github.com/dom96/httpbeast/blob/master/src/httpbeast.nim |
| 22:41:45 | dom96 | It's pretty much complete now |
| 22:41:51 | dom96 | GET and POST works |
| 22:41:58 | dom96 | That's all that is needed really :P |
| 22:42:39 | dom96 | Looks like the need for 'import times' is gone |
| 22:45:33 | dom96 | boehm and default GC are pretty similar on mac |
| 22:45:55 | dom96 | My results keep varying between 60k req/s and 70k req/s |
| 22:46:09 | dom96 | It annoys me that I can't tell for sure which is better |
| 22:46:42 | * | nsf quit (Quit: WeeChat 2.0.1) |
| 22:48:16 | Araq | you need to disable hardware interrupts for reliable benchmark results |
| 22:48:23 | * | Araq is kidding |
| 22:49:20 | dom96 | Now this is interesting |
| 22:49:57 | FromDiscord | <2vg> awesome. httpbeast will work quite efficiently…! |
| 22:51:15 | shashlick | dom96: how's httpbeast different from jester |
| 22:51:31 | dom96 | Araq: As soon as I use an {.async.} proc for my onRequest proc memory usage rises with no sign of slowing down |
| 22:51:42 | dom96 | shashlick: httpbeast is an http server, jester is a web framework |
| 22:52:24 | dom96 | Araq: newFuture() for each request doesn't grow memory |
| 22:52:39 | dom96 | so there must be something inside the async transformation doing it |
| 22:53:25 | shashlick | Oh ok, so how is it different from httpserver then :) |
| 22:53:42 | dom96 | you mean the asynchttpserver stdlib module? |
| 22:53:48 | shashlick | Yep |
| 22:54:11 | dom96 | It's built with speed in mind :) |
| 22:55:25 | dom96 | and it doesn't support Windows |
| 22:56:18 | * | rockcavera quit (Remote host closed the connection) |
| 22:57:48 | * | athenot_ quit (Remote host closed the connection) |
| 22:58:13 | * | athenot joined #nim |
| 22:58:48 | dom96 | yay, awesome that I was able to just copy the code emitted by the async macro |
| 22:59:00 | dom96 | The 'not' isn't being rendered properly though ;) |
| 22:59:41 | shashlick | Ya I'm just curious how is it architecturally different since speed is on everyone's minds these days |
| 23:00:31 | shashlick | Good design guidelines for other nimmers looking for the same thing |
| 23:02:37 | dom96 | shashlick: It uses the system's event loop directly |
| 23:02:49 | dom96 | https://github.com/dom96/httpbeast/blob/master/src/httpbeast.nim#L123 |
| 23:02:57 | dom96 | There is no async await usage in the "hot" parts |
| 23:03:29 | * | endragor joined #nim |
| 23:08:01 | * | endragor quit (Ping timeout: 265 seconds) |
| 23:08:38 | FromDiscord | <2vg> why not use TCP_NODELAY? ;) |
| 23:09:09 | shashlick | Ok any chance of porting the improvements back into stdlib |
| 23:11:34 | dom96 | So it appears that raising an exception thousands of times and then catching it is the reason for the memory leak |
| 23:11:49 | FromGitter | <Varriount> dom96: Is Windows support unfeasible? Or just not implemented? |
| 23:11:59 | dom96 | Varriount: just not implemented |
| 23:12:06 | dom96 | I doubt I'll focus on it |
| 23:14:48 | dom96 | 2vg: TCP_NODELAY huh? I'll need to read up on taht :) |
| 23:14:49 | dom96 | *that |
| 23:15:31 | * | Trustable quit (Remote host closed the connection) |
| 23:16:03 | * | yglukhov quit (Remote host closed the connection) |
| 23:16:36 | * | yglukhov joined #nim |
| 23:21:09 | * | yglukhov quit (Ping timeout: 256 seconds) |
| 23:21:53 | dom96 | For those interested: https://github.com/nim-lang/Nim/issues/7532 |
| 23:38:37 | * | craigger quit (Quit: bye) |
| 23:42:26 | FromGitter | <Varriount> dom96: What was thie fix? |
| 23:42:51 | FromDiscord | <2vg> likely ? |
| 23:44:22 | * | craigger joined #nim |
| 23:56:38 | * | icebattl1 quit (Quit: leaving) |