| 00:03:49 | * | rnrwashere quit (Ping timeout: 246 seconds) |
| 00:04:57 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
| 00:06:20 | noonien | xomachine[m]: hello, sorry for disturbing you. i appear to have found a bug in nesm, http://vpaste.net/Gd9FY seems to produce erroneous code: http://vpaste.net/9hgD3 (notice Bar is a 64byte array, and it's being encoded as a 32byte) |
| 00:11:16 | * | ftsf joined #nim |
| 00:27:38 | * | rnrwashere joined #nim |
| 00:32:13 | * | rnrwashere quit (Ping timeout: 276 seconds) |
| 00:35:56 | * | cyberjpn joined #nim |
| 00:37:20 | * | rnrwashere joined #nim |
| 00:38:02 | * | stefanos82 quit (Remote host closed the connection) |
| 00:51:54 | * | dddddd quit (Remote host closed the connection) |
| 01:05:36 | * | cyberjpn quit (Ping timeout: 250 seconds) |
| 01:13:42 | noonien | hmm, can i have functions that return a compile-time constant? |
| 01:14:05 | noonien | and replace the function calls with the computed constant |
| 01:16:28 | leorize | noonien: yes, but you could just use the constant directly, no? |
| 01:17:05 | noonien | well, i'd rather not, the constant is actually the result of a function call, which i want to be called at compiletime |
| 01:18:12 | noonien | something of the sorts: `proc serlializedSize[T](data: T): int = const size = T.serialize.len; size` |
| 01:18:57 | noonien | i never want the fuction to run at runtime |
| 01:19:39 | noonien | hmm, i think the compileTime pragma is what i'm looking for |
| 01:19:44 | leorize | nope |
| 01:20:24 | leorize | that pragma is not for such usage, but for macro helper procs |
| 01:21:07 | * | zielmicha__ quit (Ping timeout: 240 seconds) |
| 01:21:37 | noonien | hmm |
| 01:22:13 | leorize | you can write the function as you just did above |
| 01:22:55 | * | l1x quit (Ping timeout: 276 seconds) |
| 01:23:07 | noonien | do i need to do `const size = ..; size`? can i just do `T().serialize.len` instead? |
| 01:24:05 | leorize | it depends |
| 01:24:25 | leorize | but using a const is a sure bet |
| 01:24:50 | leorize | also don't forget to annotate the function with `{.inline.}` |
| 01:25:19 | noonien | great, thanks! |
| 01:28:07 | * | zielmicha__ joined #nim |
| 01:28:36 | * | theelous3_ quit (Ping timeout: 258 seconds) |
| 01:30:31 | * | rockcavera quit (Remote host closed the connection) |
| 01:34:21 | noonien | hmm, actually, can i call a proc on a type? for example, given `type Foo = object ..`, can i have a proc which i can call like: `Foo.bar`? |
| 01:36:53 | * | rnrwashere quit (Remote host closed the connection) |
| 01:37:46 | * | rnrwashere joined #nim |
| 01:39:00 | * | rnrwashere quit (Remote host closed the connection) |
| 01:39:12 | * | rnrwashere joined #nim |
| 01:39:59 | leorize | noonien: yes, make it take the first param of type `typedesc[Foo]` |
| 01:41:07 | noonien | hmm, what about http://vpaste.net/bhlWW ? |
| 01:41:27 | * | zielmicha__ quit (Ping timeout: 268 seconds) |
| 01:45:08 | leorize | that wouldn't work for `int` |
| 01:45:21 | leorize | change it to T: typedesc[object] |
| 01:45:35 | noonien | oh, nice! |
| 01:45:53 | * | ftsf quit (Quit: Leaving) |
| 01:46:23 | noonien | hmm, i'm getting `..../nim-0.19.4/lib/pure/endians.nim(57, 24) Error: cannot 'importc' variable at compile time` now |
| 01:46:40 | leorize | also you should use the `result` variable where possible |
| 01:46:55 | leorize | noonien: looks like .serialize can't be used in compile time :p |
| 01:47:28 | noonien | yes, it's calling bigendian |
| 01:47:34 | * | zielmicha__ joined #nim |
| 01:47:42 | noonien | however, i think this might be a bug in `endians` actually |
| 01:47:53 | * | l1x joined #nim |
| 01:48:41 | leorize | then you could fix it :) |
| 01:48:59 | noonien | this appears to be the culprit: https://github.com/nim-lang/Nim/blob/v0.19.4/lib/pure/endians.nim#L57 |
| 01:49:40 | noonien | i don't see why any of those defines should be defined at compile time |
| 01:51:11 | leorize | the endians library depends on the C compiler it seems |
| 01:51:22 | leorize | for performance reasons I believe |
| 01:51:35 | noonien | only when useBuiltinSwap is true |
| 01:52:20 | leorize | except for the fact that it's true for the majority of C compiler supported by Nim :p |
| 01:52:46 | noonien | sure, but at compile time, a VM is used to execute the code |
| 01:53:16 | leorize | yea, but the `define`s set by the backend still exists |
| 01:53:36 | noonien | yes, that seems to be the actual issue |
| 01:53:50 | noonien | is there a define that says i'm in the nim VM? |
| 01:53:54 | leorize | add a `when nimvm:` |
| 01:54:00 | noonien | perfect! |
| 01:54:57 | leorize | I don't know if cstring work at compile time though :p |
| 01:56:41 | * | rockcavera joined #nim |
| 01:58:18 | noonien | how can i test a modification in a stdlib file? if a library is one that imports the said file |
| 01:59:04 | leorize | put it in a folder then add a `--lib:/path/to/folder` to the cmdline |
| 01:59:09 | leorize | I've never tried that though |
| 02:00:16 | * | banc quit (Quit: Bye) |
| 02:01:23 | leorize | or you could use Nimscript's patchFile https://nim-lang.github.io/Nim/nimscript#patchFile%2Cstring%2Cstring%2Cstring |
| 02:02:32 | noonien | --lib seems to have worked, thanks! |
| 02:02:56 | noonien | `lib/pure/endians.nim(13, 6) Error: illegal context for 'nimvm' magic`, heh |
| 02:03:35 | * | Snircle quit (Quit: Textual IRC Client: www.textualapp.com) |
| 02:05:09 | noonien | this being endians.nim: http://vpaste.net/1Adqi |
| 02:10:02 | leorize | https://nim-lang.github.io/Nim/manual#statements-and-expressions-when-nimvm-statement |
| 02:10:09 | leorize | looks like you can't just do it like that :p |
| 02:10:42 | noonien | yeah, hehe |
| 02:16:24 | * | arecaceae quit (Remote host closed the connection) |
| 02:16:42 | * | arecaceae joined #nim |
| 02:17:56 | * | cyberjpn joined #nim |
| 02:21:23 | * | banc joined #nim |
| 02:24:38 | * | rnrwashere quit (Remote host closed the connection) |
| 02:28:42 | noonien | i've created an issue: https://github.com/nim-lang/Nim/issues/11157 |
| 02:28:52 | noonien | i'm unsure what a fix entails |
| 02:41:19 | * | vlad1777d quit (Ping timeout: 246 seconds) |
| 02:43:04 | * | rnrwashere joined #nim |
| 03:01:14 | * | rnrwashere quit (Remote host closed the connection) |
| 03:16:48 | * | cyberjpn quit (Quit: WeeChat 2.4) |
| 03:19:42 | disruptek | ah, i think i finally understand the proposal for exceptions; it's just about throwing consts so that there's no alloc, right? |
| 03:22:28 | * | arecaceae quit (Remote host closed the connection) |
| 03:22:47 | * | arecaceae joined #nim |
| 03:24:14 | * | zielmicha___ joined #nim |
| 03:24:45 | * | zielmicha__ quit (Ping timeout: 258 seconds) |
| 03:24:46 | * | zielmicha___ is now known as zielmicha__ |
| 04:29:59 | * | nsf joined #nim |
| 04:36:20 | * | arecaceae quit (Remote host closed the connection) |
| 04:36:39 | * | arecaceae joined #nim |
| 04:41:36 | * | narimiran joined #nim |
| 04:57:46 | * | cyberjpn joined #nim |
| 05:06:06 | * | cyberjpn quit (Ping timeout: 250 seconds) |
| 05:21:16 | * | kapil____ joined #nim |
| 05:51:28 | * | solitudesf joined #nim |
| 06:25:27 | * | PMunch joined #nim |
| 06:28:45 | * | Sargun quit (Changing host) |
| 06:28:45 | * | Sargun joined #nim |
| 06:29:49 | * | krux02 joined #nim |
| 07:00:00 | * | gmpreussner quit (Quit: kthxbye) |
| 07:00:04 | * | cyberjpn joined #nim |
| 07:00:12 | * | jjido joined #nim |
| 07:04:45 | * | gmpreussner joined #nim |
| 07:05:06 | Araq | mratsim: I don't remember, nnkVarTuple seemed better |
| 07:06:12 | FromGitter | <mratsim> @noonien, use a static result, a {.compileTime.} pragma or wrap the function call in static() |
| 07:06:33 | Araq | don't use a 'static result' |
| 07:06:36 | FromGitter | <mratsim> nnkVarTuple takes over the Let/Var section though |
| 07:06:53 | Araq | static result is an accidentical feature |
| 07:07:28 | FromGitter | <mratsim> curiously it works, given static history it's a feat :p |
| 07:07:42 | FromGitter | <mratsim> and it even works better that {.compileTime.} pragma :p |
| 07:12:57 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 07:15:50 | * | jjido joined #nim |
| 07:17:34 | Araq | well .compileTime was designed for something else, maybe that's why |
| 07:22:33 | * | cyberjpn quit (Ping timeout: 245 seconds) |
| 07:27:32 | * | cyberjpn joined #nim |
| 07:29:16 | * | ibutra joined #nim |
| 07:35:25 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 07:43:01 | FromGitter | <jrfondren> http://johnblue.cattailcreek9.com/knights/ is pretty cool but the shameless opponent pretends to be "thinking" forever when it runs out of moves. |
| 07:44:26 | FromGitter | <jrfondren> what's the point of generated code being (c) 2018 Andreas Rumpf ? |
| 07:46:29 | FromGitter | <jrfondren> ah there's a forum post. |
| 07:47:46 | narimiran | `"b2" is not a recognized move.` - oh cmon, use `.toLower` |
| 07:48:43 | FromGitter | <jrfondren> I also didn't like the @[] in array output. That's like Python programs with u'pseudojson', u'output' |
| 07:49:32 | FromGitter | <jrfondren> pretty cool to deploy little terminal programs to the web though. I was just looking through `nimble list` |
| 07:50:04 | narimiran | @jrfondren "the shameless opponent pretends to be "thinking" forever when it runs out of moves." - hm, i just got "YOU WON! The AI is out of moves." |
| 07:50:18 | FromGitter | <mratsim> @zacharycarter had his game engine running in webassembly at one point |
| 07:50:21 | FromGitter | <jrfondren> must've hit a bug then. |
| 07:50:33 | FromGitter | <jrfondren> my opponent got stuck in the top-right corner |
| 07:50:52 | FromGitter | <mratsim> This is still the coolest Nim web demo: https://hookrace.net/nimes/ |
| 07:51:18 | * | xet7 joined #nim |
| 07:58:49 | * | matic joined #nim |
| 08:04:15 | PMunch | mratsim, huh, that is pretty cool |
| 08:04:43 | PMunch | That's one thing I was thinking of for the playground, allowing you to compile to JS and then embed that JS in the browser |
| 08:07:23 | FromGitter | <mratsim> Yeah I finished my proof of concept neural network compiler =) in less than 1000 lines :P - https://github.com/mratsim/compute-graph-optim/blob/master/e11_DSL_compiler_seq.nim |
| 08:09:56 | * | matic quit (Quit: Leaving) |
| 08:10:36 | * | matic joined #nim |
| 08:12:59 | * | ibutra quit (Quit: Textual IRC Client: www.textualapp.com) |
| 08:13:11 | * | ibutra joined #nim |
| 08:13:23 | * | floppydh joined #nim |
| 08:13:26 | * | ibutra quit (Client Quit) |
| 08:13:37 | * | ibutra joined #nim |
| 08:17:21 | * | matic quit (Quit: Leaving) |
| 08:25:00 | * | cyberjpn quit (Ping timeout: 250 seconds) |
| 08:44:14 | * | slugm joined #nim |
| 08:58:51 | * | ibutra quit (Ping timeout: 250 seconds) |
| 09:08:55 | * | Vladar joined #nim |
| 09:11:55 | * | floppydh quit (Quit: WeeChat 2.4) |
| 09:28:33 | * | vlad1777d joined #nim |
| 09:42:55 | * | luis__ joined #nim |
| 09:44:46 | * | floppydh joined #nim |
| 09:50:09 | * | ibutra joined #nim |
| 09:54:36 | * | floppydh quit (Quit: WeeChat 2.4) |
| 09:55:34 | * | floppydh joined #nim |
| 09:59:16 | * | ibutra quit (Ping timeout: 258 seconds) |
| 10:06:57 | * | cyberjpn joined #nim |
| 10:14:34 | * | luis__ quit (Ping timeout: 246 seconds) |
| 10:16:59 | * | MD87_ joined #nim |
| 10:18:17 | * | stefanos82 joined #nim |
| 10:18:36 | * | sg-james[m]1 joined #nim |
| 10:18:36 | * | serialdev[m]1 joined #nim |
| 10:19:42 | * | MD87 quit (Ping timeout: 252 seconds) |
| 10:19:43 | * | jugash[m] quit (Ping timeout: 252 seconds) |
| 10:19:44 | * | serialdev[m] quit (Ping timeout: 252 seconds) |
| 10:19:44 | * | sg-james[m] quit (Ping timeout: 252 seconds) |
| 10:19:46 | * | MD87_ is now known as MD87 |
| 10:20:08 | * | jugash[m] joined #nim |
| 10:22:32 | * | slugm quit (Ping timeout: 268 seconds) |
| 10:23:14 | * | dom96 quit (Ping timeout: 255 seconds) |
| 10:23:44 | * | slugm joined #nim |
| 10:27:27 | * | dom96 joined #nim |
| 10:27:27 | * | dom96 quit (Changing host) |
| 10:27:27 | * | dom96 joined #nim |
| 10:36:17 | * | JappleAck quit (Remote host closed the connection) |
| 10:50:16 | * | clyybber joined #nim |
| 10:53:05 | clyybber | mratsim: \p/ |
| 10:53:10 | clyybber | \o/ |
| 10:54:30 | clyybber | I love the way you use SIMD instructions |
| 10:57:21 | FromGitter | <liquid600pgm> so I just went to test out my freetype wrapper, and apparently FT_Library is not defined |
| 10:59:16 | FromGitter | <liquid600pgm> oh, it seems #include FT_FREETYPE_H doesn't get written to ft2build.h |
| 10:59:19 | FromGitter | <liquid600pgm> strange |
| 11:04:45 | * | dddddd joined #nim |
| 11:05:26 | FromGitter | <liquid600pgm> I'll go back to the separate header file approach, because it worked |
| 11:21:34 | * | theelous3_ joined #nim |
| 11:38:28 | * | rnrwashere joined #nim |
| 11:43:15 | * | Intensitea quit (Remote host closed the connection) |
| 11:43:40 | * | rnrwashere quit (Ping timeout: 276 seconds) |
| 11:43:58 | * | clyybber quit (Quit: WeeChat 2.4) |
| 11:46:33 | * | slugm_ joined #nim |
| 11:46:40 | * | slugm quit (Read error: Connection reset by peer) |
| 11:57:13 | * | lritter joined #nim |
| 12:11:08 | * | solitudesf quit (Ping timeout: 244 seconds) |
| 12:13:55 | * | cyberjpn quit (Ping timeout: 246 seconds) |
| 12:17:56 | * | cyberjpn joined #nim |
| 12:18:19 | * | solitudesf joined #nim |
| 12:24:50 | * | Snircle joined #nim |
| 12:38:35 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 12:39:15 | * | slugm__ joined #nim |
| 12:39:45 | * | slugm_ quit (Read error: Connection reset by peer) |
| 12:44:32 | * | xace quit (Ping timeout: 255 seconds) |
| 12:46:21 | * | rockcavera quit (Remote host closed the connection) |
| 12:48:30 | * | Minimisthupper joined #nim |
| 12:50:21 | * | rockcavera joined #nim |
| 12:53:38 | * | Minimisthupper quit (Quit: Mutter: www.mutterirc.com) |
| 12:55:25 | FromGitter | <liquid600pgm> oh great, now Nim doesn't work at all |
| 12:55:32 | FromGitter | <liquid600pgm> I'm getting a ton of the same linker error |
| 12:56:06 | FromGitter | <liquid600pgm> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ccae8e64b4cb471d994f3cb] |
| 12:56:35 | FromGitter | <liquid600pgm> same thing happens when I try to reinstall Nim using `choosenim update devel` |
| 12:56:56 | FromGitter | <liquid600pgm> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ccae918b4700e023d0c8d8b] |
| 12:57:10 | FromGitter | <liquid600pgm> there's a *ton* of those errors |
| 13:00:38 | Zevv | g /c |
| 13:00:52 | FromGitter | <liquid600pgm> ? |
| 13:01:09 | Zevv | mistype |
| 13:01:56 | Zevv | EWRONWINDOW, also |
| 13:04:09 | leorize | liquid600pgm: have you tried clearing the nimcache? |
| 13:11:24 | * | rnrwashere joined #nim |
| 13:12:24 | FromGitter | <liquid600pgm> leorize: that helped, thank you! |
| 13:12:32 | * | JappleAck joined #nim |
| 13:15:17 | FromGitter | <liquid600pgm> strange that clearing the nimcache helps with so many problems, but it makes sense when you're switching distros |
| 13:15:43 | * | vlad1777d quit (Ping timeout: 244 seconds) |
| 13:16:37 | * | rnrwashere quit (Ping timeout: 276 seconds) |
| 13:43:56 | * | theelous3_ quit (Ping timeout: 255 seconds) |
| 13:56:06 | * | drewr quit (Quit: ERC (IRC client for Emacs 26.1)) |
| 13:56:54 | * | nsf quit (Quit: WeeChat 2.4) |
| 13:57:51 | FromGitter | <mratsim> nimcache needs to be cleaned when you switch from C to C++ compilation, the symbolds get broken |
| 13:58:28 | FromGitter | <mratsim> if you don't use the C/C++ FFI at all there is no issue but otherwise it can breaks with dumb errors that don't help you at all |
| 13:58:57 | FromGitter | <alehander42> @dom96 why do actually nim people use nim servers for their web frameworks , e.g. you decided to write httpbeast |
| 13:59:34 | FromGitter | <alehander42> what i mean is, instead of wrapping c servers etc (I expect there are very fast c servers suitable/usable for wrapping?) |
| 14:00:15 | FromGitter | <mratsim> Maybe like Haskell people use Haskell web servers? :p |
| 14:00:16 | FromGitter | <alehander42> is it just because it's fun to write one in nim? (i am asking from the point of a hypothetical web framework author: who cares that his nim framework would have nice Nim DSL + speed) |
| 14:00:31 | FromGitter | <alehander42> @mratsim ^ |
| 14:01:09 | FromGitter | <alehander42> i assume framework X would mostly expose a nim server thin wrapper API and a more high level webframework API |
| 14:01:19 | FromGitter | <mratsim> but C is a unhelpful language to write a webserver in, as backend though with a higher level language on top it might be good. |
| 14:01:27 | FromGitter | <alehander42> so people wouldn't care about the language the server is written in |
| 14:01:38 | FromGitter | <alehander42> well, it might be rust |
| 14:01:50 | FromGitter | <mratsim> yes it can be rust as well |
| 14:01:57 | FromGitter | <alehander42> my point is that probably there are 10s of fast/relatively stable servers in those langs |
| 14:02:40 | FromGitter | <mratsim> I gues your question boils down to "Why Nim when there are C, C++, Python, Ruby, ..." ;) |
| 14:02:55 | FromGitter | <alehander42> so if i write a new nim web framework, and i care only for its web-app-related api + speed, does it matter what lang is the server i add by default |
| 14:03:09 | FromGitter | <mratsim> I didn't wrap any C/C++ for ML because I found it more fun to write in NIm |
| 14:03:15 | FromGitter | <mratsim> and do it from scratch |
| 14:03:43 | FromGitter | <alehander42> well not entirely: it boils down to "can i get a very nimish web framework and reuse a c/rust server thanks to awesome interop in the same time) |
| 14:11:19 | * | slugm__ quit (Remote host closed the connection) |
| 14:11:44 | * | slugm__ joined #nim |
| 14:12:53 | FromGitter | <mratsim> yes, but if you want to learn how to write a web framework, you will learn more by doint it from scratch |
| 14:14:21 | FromGitter | <mratsim> so it also depends on your time-to-market needs or hobby/prod status |
| 14:14:36 | * | cgfuh joined #nim |
| 14:16:08 | FromGitter | <alehander42> absolutely, but if your goal is to get a robust/fast framework out and focus on its higher level features, that might be overeng |
| 14:16:31 | FromGitter | <alehander42> i'd argue that a web server is a separate project, i'd guess that most popular frameworks start on existing servers |
| 14:16:43 | FromGitter | <alehander42> (but it's great for learning of course) |
| 14:17:37 | FromGitter | <arnetheduck> code that wasn't written with integration in mind will be hard to integrate regardless of the "other" language.. just like code that wasn't written with a "library" mindset will be hard to reuse even within a language.. adding a language barrier simply adds a few more constraints and tradeoffs to play with (conversion tax, non-common feature usage etc).. |
| 14:19:12 | * | Vladar quit (Remote host closed the connection) |
| 14:22:22 | * | PMunch quit (Remote host closed the connection) |
| 14:23:01 | FromGitter | <alehander42> i agree, but i'd still guess that "wrap and expose a thin nim api on top of a nice c/c++ server and then reuse this for my whole framework" |
| 14:23:23 | FromGitter | <alehander42> would take less time/effort than "write my own server which handles all kinds of protocols quickly and correctly" |
| 14:24:09 | FromGitter | <alehander42> and some servers should've been written with integration in mind (so they shouldn't be too hard to somehow reuse) |
| 14:24:13 | Zevv | But everyone is free to make that mistake a few times in their careers |
| 14:25:23 | FromGitter | <alehander42> it's not even a mistake, nim needs its own servers, just assume i am a "i want to write a web framework and just focus on that just the web stuff" guy |
| 14:27:23 | Zevv | that was tongue-in-cheek, but yeah: Nim needs its own servers, but it's just plain hard. You start from scratch and you have to catch up with the well-known-projects which have undergone wide scale evolution and testing for years, even decades |
| 14:27:49 | FromGitter | <mratsim> Most new languages were merketed with their webservers: Crystal, Elm, Elixir |
| 14:27:59 | FromGitter | <mratsim> marketed* |
| 14:28:13 | FromGitter | <alehander42> hm, i am not sure |
| 14:28:14 | Zevv | And still the world runs Apache and Nginx and lighttpd |
| 14:28:17 | FromGitter | <alehander42> elm is mostly a client language? |
| 14:28:26 | FromGitter | <alehander42> i'd guess elixir reuses erlang's servers |
| 14:28:47 | FromGitter | <mratsim> Elixir was all about phoenix and being Ruby on Rails v2 |
| 14:28:59 | FromGitter | <mratsim> yes sorry about Elm, apparently it's a DSL for webapps |
| 14:29:55 | FromGitter | <alehander42> but that's the point |
| 14:30:08 | FromGitter | <alehander42> i think phoenix reuses erlang's otp framework |
| 14:30:13 | FromGitter | <alehander42> (or some other servers) |
| 14:30:45 | FromGitter | <mratsim> you can py2nim django ;) |
| 14:30:46 | FromGitter | <alehander42> i would define a pure nim web framework, but i would base its default server on <otherlang> server |
| 14:31:18 | FromGitter | <alehander42> i can rb2nim rails mamy hehe |
| 14:31:34 | FromGitter | <mratsim> oh, I wasn't aware of that :P |
| 14:31:41 | FromGitter | <mratsim> Needs cr2nim as well :p |
| 14:31:48 | Zevv | why does a web framework have to be tightly coupled to a server? |
| 14:32:07 | FromGitter | <mratsim> foo deploy --> done ;) |
| 14:32:13 | FromGitter | <mratsim> very sexy in documentations |
| 14:32:58 | FromGitter | <mratsim> but you're right |
| 14:32:59 | FromGitter | <alehander42> of course it should be able to support different servers, but you'd still want to make sure it works very quickly with at least one |
| 14:33:17 | FromGitter | <alehander42> and that e.g. its async model works well with it, use it for benchmarks etc |
| 14:34:07 | Zevv | My common deployment is just the async http server and ngix proxying/loadbalancing at the front door, serves me well. |
| 14:35:43 | FromGitter | <alehander42> hm, but doesnt nginx => asynchttp server add a bit of overhead |
| 14:36:02 | FromGitter | <alehander42> would it make sense to directly run your code as a nginx plugin?(i was told that's another approach) |
| 14:37:03 | Zevv | Well, the overhead is true - you're basically parsing and verifying incoming HTTP twice. SCGI is a good second choice |
| 14:38:07 | Zevv | But running inside nginx is a pita - you can't just compile an ngix plugin standalone without having the ngix source available IIRC |
| 14:38:49 | Zevv | and what's the semantics for running inside Nginx? How does that integrate with Nim's async and ioselectors? |
| 14:39:21 | FromGitter | <alehander42> good questions, it's mostly an example i haven't researched it |
| 14:39:24 | Zevv | Youre tied to the rules of the server you're running in. Can you just spawn a lot of threads? Can you block for a second? |
| 14:39:40 | FromGitter | <alehander42> well i'd say it's a tradeoff |
| 14:39:58 | FromGitter | <alehander42> but i wouldn't say you're tied: you can have some capabilities |
| 14:40:00 | * | drewr joined #nim |
| 14:40:03 | FromGitter | <alehander42> disabled for some servers |
| 14:42:03 | Zevv | true, it's always a tradeoff. But the problem is that once you start making a framework, you're never finished. Apache started out as a web server, and look what's inthere: a zillion modules doing a zillion things. Then Nginx comes along and does all these zillion things from the start, basically making apache-done-right. If you now come up with your own frame work, people will be complaining: Hey you don't |
| 14:42:09 | Zevv | have feature X and Y and Z |
| 14:42:43 | Zevv | I'd say, pick a proper interface that plugs into other frame works and advertise that |
| 14:43:08 | Zevv | Too bad SCGI fell out of the stdlib |
| 14:43:27 | FromGitter | <mratsim> well, everything starts lean and in a niche and as it grows popular people requests and hopefully implement more and more features until you become the behemoth you were challenging when you just started. |
| 14:43:37 | FromGitter | <mratsim> hopefully that will be Nim story :P |
| 14:43:48 | Zevv | hehe |
| 14:43:51 | * | xace joined #nim |
| 14:45:02 | * | shashlick quit (Ping timeout: 250 seconds) |
| 14:54:14 | FromGitter | <alehander42> yeah well i really think of something way lighter |
| 14:54:20 | FromGitter | <alehander42> like sinatra / jester / flask etc |
| 14:54:52 | FromGitter | <alehander42> which just works well with a very fast server (but can support others as well) |
| 14:57:22 | * | shashlick joined #nim |
| 15:04:08 | * | Minimisthupper joined #nim |
| 15:15:26 | * | rnrwashere joined #nim |
| 15:17:03 | * | kapil____ joined #nim |
| 15:23:20 | FromGitter | <mratsim> Currently what seem to be popular are web compiler to serve static pages. Like: hugo, metalsmith, gatsby, jekyll and whatnot |
| 15:24:09 | * | floppydh quit (Quit: WeeChat 2.4) |
| 15:24:57 | FromGitter | <alehander42> hey @PMunch what would be cool is to also be able to easily benchmark stuff on the playground: e.g. compare one/two snippets (adding the benchmark code internally) |
| 15:25:09 | FromGitter | <alehander42> saw a crystal benchmark and thought of it |
| 15:25:14 | FromGitter | <alehander42> @mratsim yeah good idea |
| 15:25:23 | FromGitter | <alehander42> that's something that is also very useful to be supported |
| 15:28:36 | FromGitter | <mratsim> bonus point if we can build a Nim doc framework on top :P |
| 15:34:52 | FromGitter | <mratsim> @alehander42 there is no C/C++/low-level language entry here: https://github.com/danistefanovic/build-your-own-x#build-your-own-web-server |
| 15:36:06 | FromGitter | <dom96> @alehander42 that sounds way out of the scope of the playground |
| 15:39:23 | FromGitter | <dom96> @mratsim *cough* https://github.com/dom96/ipsumgenera |
| 15:39:28 | FromGitter | <arnetheduck> vm environments are notoriously bad for benchmarking, fwiw |
| 15:40:11 | FromGitter | <dom96> Yeah. That too |
| 15:40:34 | FromGitter | <mratsim> for my benchmarking needs, a godbolt plugin would be better than actual benches. |
| 15:41:05 | FromGitter | <mratsim> > To set up ipsum you first need to install nimrod's nimble package manager. ⏎ @dom96 nimrod? what is this 2014? :P |
| 15:44:51 | * | Snircle quit (Read error: Connection reset by peer) |
| 15:44:52 | * | rnrwashere quit (Remote host closed the connection) |
| 15:45:29 | * | Snircle joined #nim |
| 15:45:30 | * | rnrwashere joined #nim |
| 15:50:05 | * | rnrwashere quit (Ping timeout: 250 seconds) |
| 15:55:44 | * | Trustable joined #nim |
| 15:57:34 | * | def- quit (Quit: -) |
| 15:57:45 | * | ng0 joined #nim |
| 16:00:32 | * | def- joined #nim |
| 16:03:03 | * | thomasross quit (Remote host closed the connection) |
| 16:07:20 | * | krux02 quit (Remote host closed the connection) |
| 16:08:43 | * | rnrwashere joined #nim |
| 16:25:10 | * | rnrwashere quit (Remote host closed the connection) |
| 16:26:51 | * | rnrwashere joined #nim |
| 16:32:02 | * | rnrwashere quit (Remote host closed the connection) |
| 16:33:57 | * | rnrwashere joined #nim |
| 16:36:21 | * | rnrwashere quit (Remote host closed the connection) |
| 16:54:19 | FromDiscord_ | <Grey> hi everyone, nice to meet you all |
| 16:54:27 | FromGitter | <mratsim> hey grey |
| 16:57:14 | FromDiscord_ | <Grey> I'm very new to Nim, was wondering if anyone can share some insight with HttpClient timeouts. How long does everyone normally set this to? |
| 16:57:14 | FromDiscord_ | <Grey> ```nim |
| 16:57:14 | FromDiscord_ | <Grey> proc newHttpClient(userAgent = defUserAgent; maxRedirects = 5; |
| 16:57:14 | FromDiscord_ | <Grey> sslContext = getDefaultSSL(); proxy: Proxy = nil; timeout = -1): HttpClient {...} |
| 16:57:14 | FromDiscord_ | <Grey> ``` |
| 17:01:48 | * | rnrwashere joined #nim |
| 17:04:53 | FromGitter | <mratsim> probably need to ping @dom96 on that, he is the one who wrote jester |
| 17:06:43 | * | rnrwashere quit (Ping timeout: 276 seconds) |
| 17:06:48 | FromGitter | <alehander42> that's fair |
| 17:07:01 | FromGitter | <alehander42> benchmarking needs a better env |
| 17:10:05 | FromGitter | <mratsim> @Grey Since the web people are not connected, I suggest you use whatever is suggested in low-level API documentation, for http Nim is just a thin wrapper over windows/linux/mac API |
| 17:11:06 | shashlick | client timeouts are best stolen from established apps - https://stackoverflow.com/questions/13582409/http-client-timeout-and-server-timeout |
| 17:11:17 | * | slugm_ joined #nim |
| 17:13:31 | * | slugm__ quit (Ping timeout: 246 seconds) |
| 17:15:27 | * | cyberjpn quit (Ping timeout: 245 seconds) |
| 17:24:19 | * | jjido joined #nim |
| 17:25:20 | * | kapil____ quit (Quit: Connection closed for inactivity) |
| 17:25:22 | * | JappleAck quit (Quit: Closing object) |
| 17:30:05 | * | JappleAck joined #nim |
| 17:49:23 | * | jjido quit (Remote host closed the connection) |
| 17:49:34 | * | jjido joined #nim |
| 17:53:09 | * | Jesin quit (Quit: Leaving) |
| 17:56:50 | * | Jesin joined #nim |
| 17:57:33 | livcd | alehander42: sooo...are you going to write a killer webserver in Nim ? |
| 17:59:04 | * | rockcavera quit (Remote host closed the connection) |
| 18:02:40 | * | Snircle quit (Read error: Connection reset by peer) |
| 18:03:11 | * | Snircle joined #nim |
| 18:03:42 | FromGitter | <alehander42> nooo |
| 18:03:48 | FromGitter | <alehander42> that's @dom96's job |
| 18:04:54 | narimiran | another small benchmark waiting to be optimized.... https://github.com/sstadick/bioinfo_benchmarks |
| 18:05:29 | * | rockcavera joined #nim |
| 18:05:32 | FromGitter | <alehander42> i just want to write a framework .. or more likely to inspire somebody else to write more web frameworks |
| 18:07:22 | livcd | alehander42: is not the webserver more needed atm ? Maybe I am mistaken but httpbeast only works on Linux ? (and osx?) |
| 18:08:36 | FromGitter | <kayabaNerve> I actually need to integrate a web server with my project |
| 18:13:33 | * | vlad1777d joined #nim |
| 18:16:00 | FromGitter | <kaushalmodi> today I came across an interesting Nim/C interface problem .. how do I importc and exportc the same function from C? |
| 18:16:36 | FromGitter | <kaushalmodi> I need to get a function from a .so, and I can do that using importc just fine. But I also need to export that same function in the Nim compiled .so |
| 18:17:23 | FromGitter | <kaushalmodi> workaround is to create a wrapper fn in Nim that simply calls that imported fn and I exportc that wrapper fn, but it's ugly as I need to name that wrapper fn something different |
| 18:18:30 | leorize | kaushalmodi: this is C, your namespace is really limited, and there's no mangling |
| 18:19:01 | leorize | you can't importc then exportc the same thing due to symbol collision |
| 18:19:20 | FromGitter | <kaushalmodi> ok, so looks like wrapper is the way to go |
| 18:19:43 | FromGitter | <kaushalmodi> alternative of course is that the 3rd party application uses both .so's (the original and the Nim compiled) |
| 18:19:49 | leorize | but why would you need to do that? can't you just link the other library? |
| 18:19:57 | shashlick | why couldn't you importc with a different nim name |
| 18:20:10 | FromGitter | <kaushalmodi> shashlick: I tried that but didn't work |
| 18:20:20 | shashlick | but in C both imported and exported name will be the same |
| 18:20:21 | shashlick | okay |
| 18:20:27 | FromGitter | <kaushalmodi> the original fn name has already take up the namespace it seems |
| 18:20:40 | leorize | yea, C namespace is a delicate thing |
| 18:21:21 | shashlick | maybe by splitting into 2 procs but in different files or something |
| 18:21:52 | leorize | that wouldn't change a thing, you'd still need to link to that importc function |
| 18:22:08 | leorize | and that basically brings the other library namespace to yours |
| 18:22:21 | FromGitter | <kaushalmodi> shashlick: wait, it worked! i.e importc'ing using a different name |
| 18:22:33 | FromGitter | <kaushalmodi> and then creating a wrapper with the original fn name and exportcing that |
| 18:22:54 | FromGitter | <kaushalmodi> looks like I was creating wrapper in the same file last time I tried |
| 18:23:20 | FromGitter | <kaushalmodi> this time, the original fn Foo is imported using Bar in one file and in another file, I create a wrapper fn Foo calling Bar |
| 18:23:45 | leorize | why would you need to jumps through hoops like that? |
| 18:24:03 | leorize | you could just link both library like every other software... |
| 18:24:21 | FromGitter | <kaushalmodi> well, putting the wrapper in the same file worked too .. |
| 18:24:35 | shashlick | amusing that C didn't mix up the linking like leorize mentioned |
| 18:24:43 | FromGitter | <kaushalmodi> leorize: mine is not a software company :P |
| 18:25:04 | FromGitter | <kaushalmodi> I'd like to keep things simple .. like if you are using Foo nim library, use just foo.so |
| 18:25:05 | leorize | I mean every other software as in every other software? :p |
| 18:25:36 | leorize | shashlick: which is weird, unless you're using `{.dynlib.}` ofc |
| 18:25:50 | FromGitter | <kaushalmodi> I am using dynlib |
| 18:26:15 | leorize | and that's how you got away with it :p |
| 18:27:47 | leorize | I wouldn't count too much on `{.dynlib.}` though |
| 18:28:16 | leorize | got some really unpleasant namespace collision with nimrtl on Haiku |
| 18:28:23 | FromGitter | <kaushalmodi> that lib is in LD_LIBRARY_PATH |
| 18:28:38 | FromGitter | <kaushalmodi> summary of what I learned could work: ⏎ ⏎ ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ccb36d52e2caa1aa6f91dfb] |
| 18:29:25 | leorize | it works, until you do this: `--dynlibOverrideAll -l:'-lfoo'` |
| 18:29:53 | leorize | ^ that's how most software on posix-like system is linked |
| 18:33:51 | FromGitter | <kaushalmodi> I see! |
| 18:34:21 | FromGitter | <kaushalmodi> thanks for that. I'll document that locally |
| 18:34:41 | FromGitter | <kaushalmodi> I doubt that I'll ever use dynlibOverrideAll, but it's good to know about it |
| 18:58:37 | shashlick | @dom96 - https://github.com/nim-lang/nimble/pull/645 |
| 19:25:39 | * | rockcavera quit (Remote host closed the connection) |
| 19:44:28 | FromGitter | <mratsim> @narimiran, well I'm betting that line.split is slowness culprit: var vals = line.split('\t') |
| 19:44:36 | FromGitter | <mratsim> sorry: https://github.com/sstadick/bioinfo_benchmarks/blob/master/count_lines_nim.nim#L6 |
| 19:44:54 | narimiran | @mratsim how would you do it? |
| 19:45:24 | FromGitter | <mratsim> the issue of line.split is that it's allocating an seq[string] string are also GC allocated |
| 19:45:58 | FromGitter | <mratsim> so when we loop over each line we are allocating and collecting seq[string] over and over again |
| 19:46:10 | narimiran | well, if you're not interested in strings, just their number, then it is easy and fast (`c += line.count('\t') + 1`) :) |
| 19:46:22 | FromGitter | <mratsim> the first optim would be to have a mutable vals buffer |
| 19:47:00 | FromGitter | <mratsim> and you SetLen = 0 in between calls and for loop append |
| 19:47:10 | FromGitter | <mratsim> i.e. basically reimplementing line.split |
| 19:47:15 | narimiran | :) |
| 19:47:35 | FromGitter | <mratsim> basically this measures GC overhead |
| 19:47:59 | narimiran | btw, `--newruntime` showed 25% speedup on my machine for the original code |
| 19:48:57 | FromGitter | <mratsim> and this kind of natural way of interacting with strings is usually very inefficient, hence why strutils could need a refactor |
| 19:49:14 | FromGitter | <mratsim> well thanks to Nim mutable string you can always go low-level |
| 19:50:06 | * | thomasross joined #nim |
| 19:50:55 | FromGitter | <mratsim> one day I'll learn more about string optimisation when I have to parse languages and texts for text neural net and implement fast text parsers but for now I'm happy with tensors, images and SIMD :p |
| 19:51:13 | * | nsf joined #nim |
| 19:51:44 | * | lritter quit (Quit: Leaving) |
| 19:52:26 | narimiran | hehe |
| 19:52:59 | narimiran | i'm/we're still waiting for your article/blogpost about all the magic you do ;) |
| 20:03:58 | * | narimiran quit (Ping timeout: 246 seconds) |
| 20:07:27 | * | nsf quit (Quit: WeeChat 2.4) |
| 20:12:19 | * | theelous3_ joined #nim |
| 20:14:05 | * | cgfuh quit (Quit: WeeChat 2.3) |
| 20:30:08 | FromGitter | <alehander42> i think a similar string api which the language/lib impl is able to optimize should be possible |
| 20:30:42 | FromGitter | <alehander42> i am not a fan of "write your string handling in this particular crafty way which happens to be good for 2019 computers" |
| 20:31:10 | FromGitter | <alehander42> it should be possible for one to naturally express algorithms and still get almost max speed |
| 20:35:39 | federico3 | shashlick: if you want binary builds for many architectures (including various ARM) for choosenim you can grab the built Debian packages. It will have only releases and not devel |
| 20:41:31 | shashlick | @federico3: where can I find these? |
| 20:42:48 | federico3 | https://packages.debian.org/sid/nim -> Architecture -> https://packages.debian.org/sid/amd64/nim/download for example |
| 20:43:06 | shashlick | i was planning on adding more builds to choosenim CI eventually so that releases become easier going forward - similar to nightlies |
| 20:44:33 | * | slugm_ quit (Remote host closed the connection) |
| 20:44:45 | shashlick | did you have any feedback on the new nightlies arm builds? |
| 20:45:18 | federico3 | shashlick: or you can use the global redirector e.g https://deb.debian.org/debian/pool/main/n/nim/nim_0.19.4-1_{archname}.deb <-- replace archname |
| 20:47:08 | FromGitter | <liquid600pgm> I'm getting a strange error in nimsuggest (not Nim itself) which is related to nimterop: ⏎ ⏎ `````` [https://gitter.im/nim-lang/Nim?at=5ccb574c8446a6023eb61b07] |
| 20:47:22 | FromGitter | <liquid600pgm> ```code paste, see link``` [https://gitter.im/nim-lang/Nim?at=5ccb575a5b3f941aa5cf2bd1] |
| 20:49:38 | shashlick | Looks like some paths issue |
| 20:49:58 | FromGitter | <liquid600pgm> I'm getting the same thing when I try to reinstall nimterop |
| 20:50:19 | FromGitter | <liquid600pgm> what's cc1plus? |
| 20:51:25 | shashlick | It is the c++ compiler part of gcc |
| 20:51:32 | FromGitter | <liquid600pgm> nevermind, I didn't have a C++ compiler installed (fresh openSUSE install) |
| 20:52:35 | * | xet7 quit (Quit: Leaving) |
| 21:04:59 | * | Trustable quit (Remote host closed the connection) |
| 21:16:01 | * | jjido quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 21:27:58 | * | rnrwashere joined #nim |
| 21:29:05 | FromGitter | <mratsim> lol |
| 21:30:19 | FromGitter | <mratsim> @alehander42, Yes I agree, we should make ergonomic usage efficient and avoid having to use assembly :p |
| 21:30:40 | FromGitter | <mratsim> @narimiran: yeah I know :P |
| 21:55:17 | * | rnrwashere quit (Remote host closed the connection) |
| 22:05:27 | * | solitudesf quit (Ping timeout: 245 seconds) |
| 22:13:03 | * | ng0 quit (Quit: Alexa, when is the end of world?) |
| 22:23:42 | * | rnrwashere joined #nim |
| 22:24:12 | * | cyberjpn joined #nim |
| 22:48:38 | * | Snircle_ joined #nim |
| 22:48:38 | * | Snircle quit (Read error: Connection reset by peer) |
| 22:48:52 | * | jasper_ joined #nim |
| 22:57:20 | * | Jesin quit (Quit: Leaving) |
| 22:58:07 | * | leorize quit (Remote host closed the connection) |
| 22:58:39 | * | leorize joined #nim |
| 22:59:00 | * | Jesin joined #nim |
| 23:03:45 | * | theelous3_ quit (Ping timeout: 246 seconds) |
| 23:15:26 | * | vlad1777d quit (Ping timeout: 252 seconds) |
| 23:16:04 | * | Hexeratops joined #nim |
| 23:24:53 | * | smitop joined #nim |