| 00:07:51 | * | desophos quit (Remote host closed the connection) |
| 00:12:58 | * | desophos joined #nim |
| 00:17:25 | * | desophos quit (Ping timeout: 250 seconds) |
| 00:18:25 | * | fredrik92 quit (Read error: Connection reset by peer) |
| 00:48:30 | * | gokr quit (Ping timeout: 276 seconds) |
| 00:52:05 | * | Demon_Fox quit (Quit: Leaving) |
| 01:07:07 | * | BitPuffin|osx quit (Ping timeout: 260 seconds) |
| 01:22:17 | * | saml_ quit (Quit: Leaving) |
| 01:23:55 | * | chrisheller quit (Remote host closed the connection) |
| 01:24:15 | * | chrisheller joined #nim |
| 01:27:37 | * | chrisheller quit (Read error: Connection reset by peer) |
| 01:54:16 | * | desophos joined #nim |
| 01:54:36 | * | chrisheller joined #nim |
| 01:58:42 | * | ludocode quit (Remote host closed the connection) |
| 02:28:05 | * | brson quit (Quit: leaving) |
| 02:49:57 | * | izi quit (Quit: Leaving) |
| 03:37:46 | * | vendethiel joined #nim |
| 03:41:47 | * | Demon_Fox joined #nim |
| 03:44:52 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 03:52:47 | * | darkf quit (Ping timeout: 250 seconds) |
| 04:10:02 | * | Guest70507 joined #nim |
| 04:11:28 | * | GangstaCat quit (Quit: Leaving) |
| 04:20:11 | * | nsf quit (Ping timeout: 244 seconds) |
| 04:37:31 | * | Guest70507 quit (Quit: Guest70507) |
| 04:39:39 | * | ludocode_ joined #nim |
| 04:44:33 | * | ludocode_ is now known as ludocode |
| 05:00:59 | * | nsf joined #nim |
| 05:01:26 | * | darkf joined #nim |
| 05:07:57 | * | InfinityBear joined #nim |
| 05:08:02 | InfinityBear | Quick question |
| 05:08:11 | InfinityBear | Nim compiles to .exe without .dll's?? |
| 05:08:27 | * | endragor joined #nim |
| 05:36:04 | vegansk | InfinityBear, you mean without external dependencies? |
| 05:36:56 | InfinityBear | yes |
| 05:38:13 | InfinityBear | vegansk, |
| 05:38:22 | vegansk | it depends. if you will use impure libraries or wrappers, you will need .dll/.so/.dynblib. but if you will use pure libraries, in 90% cases, you don't |
| 05:38:40 | InfinityBear | ok |
| 05:38:41 | vegansk | it's just like in c/c++ |
| 05:39:29 | InfinityBear | ok |
| 05:50:02 | Varriount | InfinityBear: It also depends on the compiler you use. On Windows, MinGW links to msvcrt.dll, while vcc links to msvcrtX.dll, where X is the version number linked against. |
| 05:50:30 | Varriount | Personally, I disagree with MinGW's choice, but w/e |
| 05:52:34 | InfinityBear | Varriount, so on windows will it make a .dll? |
| 05:52:38 | InfinityBear | well not make, require? |
| 05:52:58 | InfinityBear | or is it part of the C++ runtime that you have to install :p |
| 05:53:13 | Varriount | InfinityBear: It's the C/C++ runtime |
| 05:53:22 | InfinityBear | yes, i know that. |
| 05:53:38 | InfinityBear | Will I be required to install the runtime or will it link against the one that always comes with windows. |
| 05:54:09 | Varriount | InfinityBear: Again, depends on the compiler and settings. |
| 05:54:15 | InfinityBear | ok |
| 05:54:50 | Varriount | MinGW links against msvcrt.dll, which is the runtime that's supposed to *only* be used by the system |
| 05:55:14 | Varriount | vcc links against one of the msvcXXX.dll runtimes |
| 05:57:34 | Varriount | InfinityBear: If you want to link to a specific C runtime using mingw, this link looks promising: https://sourceforge.net/p/mingw-w64/mailman/message/31072870/ |
| 06:08:57 | * | InfinityBear quit (Ping timeout: 246 seconds) |
| 06:15:56 | * | McSpiros joined #nim |
| 06:22:04 | * | endragor_ joined #nim |
| 06:25:45 | * | endragor quit (Ping timeout: 250 seconds) |
| 06:40:37 | * | endragor_ quit (Remote host closed the connection) |
| 06:40:56 | * | patariki joined #nim |
| 06:41:05 | * | endragor joined #nim |
| 06:44:01 | * | patariki left #nim (#nim) |
| 06:47:26 | * | gunn quit (Ping timeout: 248 seconds) |
| 06:57:38 | endragor | If a procedure returns `var` value, and I assign the value to a variable (var a = theProc()), should modifying the variable modify the returned reference? |
| 07:16:06 | * | yglukhov joined #nim |
| 07:20:33 | yglukhov | Araq: do i add a skipHidden to types.nim that does the same as skipConv except only for nkHiddenStdConv, nkHiddenSubConv? |
| 07:20:53 | * | gokr joined #nim |
| 07:25:47 | vegansk | yglukhov, hi! please look at my comment here: https://gist.github.com/vegansk/68af805063e50f0d673caa00efbce2d0 |
| 07:27:14 | * | Trustable joined #nim |
| 07:48:24 | * | girvo quit (Ping timeout: 244 seconds) |
| 08:12:51 | * | dorei joined #nim |
| 08:30:40 | * | fredrik92 joined #nim |
| 08:32:01 | * | Demon_Fox quit (Quit: Leaving) |
| 08:38:07 | Varriount | endragor: The way to imagine a 'var' parameter is as a pointer to the actual location of the variable (usually on the stack). |
| 08:39:51 | fredrik92 | some languages also call that By-Reference-Parameters (and some use sth. like a 'ref' keyword for that) |
| 08:50:03 | endragor | Varriount: I understand that, I was asking about the expected behaviour. Right now `theProc() = 3` changes the original value, but `var a = theProc(); a = 3` doesn't. |
| 08:50:29 | endragor | fredrik92: I was asking about var return value, not var parameter |
| 08:50:30 | * | coffeepot joined #nim |
| 08:50:53 | fredrik92 | andragor, ah, my bad... |
| 08:50:56 | Varriount | endragor: Could you provide a code snippet? |
| 08:53:10 | endragor | Varriount: sure: https://gist.github.com/endragor/ca3d81deac5d82e92a46480d80176d6d |
| 08:54:35 | Varriount | endragor: I can see *why* it works that way, at least from a practical perspective, but not from a language perspective. |
| 08:56:57 | Varriount | endragor: I never quite understood how var return types were supposed to work, when references work perfectly well. |
| 09:00:39 | endragor | I think at some point `var` return value might had been added to support operators so that you can write `table[x] = y`. On the other hand, that is also possible by defining `[]=`. Not sure which appeared first and whether there is an actual use case for var return value - it's quite confusing now and acts inconsistently with iterators |
| 09:05:22 | Varriount | endragor: From a purely programmatic perspective, var return types sound very hard to produce for anything other than straightforward expressions. |
| 09:05:45 | Varriount | I mean, when you consider the code backend and memory safety and everything. |
| 09:07:24 | Varriount | endragor: Have you worked with term-rewriting macros at all? |
| 09:07:56 | endragor | Varriount: in practice? no |
| 09:12:03 | Varriount | endragor: I think the basic principle of var types is that they aren't transitive across assignments (I think that's the proper term). |
| 09:14:16 | Varriount | A type doesn't retain it's 'var' characteristic across assignments, much like you can assign a var to a `let` expression. |
| 09:14:54 | * | desophos quit (Read error: Connection reset by peer) |
| 09:16:01 | endragor | Varriount: I understand the point, thanks. I also understood from the beginning why it was done this way. It's still somewhat unclear why var return values exist at all, it's hard to think of a use case |
| 09:16:11 | * | t4nk125 joined #nim |
| 09:16:36 | t4nk125 | hi |
| 09:16:47 | Varriount | Hello t4nk125 |
| 09:16:57 | fredrik92 | Hi, there! :) |
| 09:17:03 | dom96 | hi guys |
| 09:17:11 | t4nk125 | Hello Varriount |
| 09:17:52 | flyx | endragor: you could do `var val = addr(table.mget(1)); val[] = 42 |
| 09:17:55 | dom96 | endragor: var return values are useful when you want a mutable string for example. |
| 09:18:18 | flyx | (well at least I think that would work) |
| 09:18:32 | dom96 | if you're assigning a new value then it's not really useful, but when you're modifying a value then it is. |
| 09:18:53 | dom96 | In your gist you're using int, so say you wanted to call `inc` on that int then the mget() is useful. |
| 09:19:25 | dom96 | But when you assign an mget'ed value to a variable, it gets copied. |
| 09:22:44 | * | enthus1ast quit (Ping timeout: 260 seconds) |
| 09:24:26 | endragor | dom96: thanks, yeah inc/dec is nice for that case (although you probably usually want to do some checks on the value before/after doing inc/dec). And what's with the mutable string? Is there something else you need except `[]=` and alike? |
| 09:24:30 | * | t4nk125 quit (Ping timeout: 250 seconds) |
| 09:25:10 | dom96 | endragor: strings are mutable, in many cases I want to append data to them with `add`. |
| 09:25:36 | * | flyx tested it. you can do addr(table.mget(1)). this obviously wouldn't work if the return value wasn't var |
| 09:27:07 | endragor | dom96: yes, right, and what about var return value? `add` doesn't return anything |
| 09:27:33 | dom96 | endragor: not sure what you mean |
| 09:28:00 | endragor | dom96: you began with saying "var return values are useful when you want a mutable string for example". I was trying to understand what exactly you meant by that :) |
| 09:28:50 | dom96 | I meant that if you have a Table[string, string] and you want to append some data to one of the values in that table, you can do something like this: table.mget("foo").add("blah") |
| 09:29:58 | endragor | dom96: ah, I see, thanks |
| 09:32:29 | flyx | using a var return value will also be faster for large data structures, because they do not need to be copied. but you'd probably use refs for those anyway. |
| 09:36:30 | endragor | flyx: that's true. but only if you need to change one field of the structure. and in practice I feel it happens rare that you change values stored somewhere without doing some work with those values before or after changing them. |
| 09:37:48 | flyx | endragor: well for that case, you can still use the addr() method. |
| 09:39:09 | dom96 | keep in mind though that using 'addr' is unsafe |
| 09:39:18 | endragor | flyx: yeah, with the addr hack you can do all you want, but it's a hack :) |
| 09:39:47 | flyx | I think it is intentionally clumpsy to handle because you should think about what you're doing when you use it. even C++, which uses „var“ values for a lot of things, you need to explicitly specify that you want to keep the „var“ when you assign it to another variable. |
| 09:40:39 | endragor | you can also use things like addr/cast to directly access memory of data structures like hash tables without `var` return values |
| 09:41:34 | flyx | endragor: I think casting is much lower level than addr. addr still gives you type safety. |
| 09:42:49 | endragor | not memory safety though - GC loses track of where that addr goes to. I mean both those features are something not recommended to do anyway. |
| 09:45:02 | flyx | I'd rather say you can use it if you „know what you're doing“. if the Table does not go out of scope while juggling around with the ptr var, nothing bad will happen. |
| 09:45:41 | flyx | but I wouldn't use it unless it provides a real benefit |
| 09:46:47 | * | PMunch joined #nim |
| 10:09:27 | * | ekarlso- quit (Ping timeout: 276 seconds) |
| 10:13:56 | * | desophos joined #nim |
| 10:18:22 | * | desophos quit (Ping timeout: 252 seconds) |
| 10:22:46 | * | arnetheduck joined #nim |
| 10:23:56 | * | ekarlso joined #nim |
| 10:45:50 | * | yglukhov quit () |
| 10:49:44 | * | girvo joined #nim |
| 10:56:59 | * | girvo quit (Ping timeout: 244 seconds) |
| 10:57:47 | * | yglukhov joined #nim |
| 11:00:17 | * | elrood joined #nim |
| 11:41:03 | * | BitPuffin joined #nim |
| 11:53:56 | * | girvo joined #nim |
| 11:55:18 | * | krux02 joined #nim |
| 11:56:36 | cheatfate | dom96, why you are marking my issues with os/arch specific :((( |
| 11:57:01 | cheatfate | nobody cares about os/arch specific issues |
| 11:59:55 | federico3 | ...why? |
| 12:01:13 | cheatfate | federico3, it was a joke :) |
| 12:01:36 | federico3 | :) |
| 12:06:52 | * | girvo quit (Ping timeout: 260 seconds) |
| 12:12:46 | * | gokr quit (Ping timeout: 252 seconds) |
| 12:13:10 | * | zahary quit (Read error: Connection reset by peer) |
| 12:13:28 | * | zahary joined #nim |
| 12:18:32 | * | enthus1ast joined #nim |
| 12:33:36 | * | vegansk is now known as veganskaway |
| 12:44:11 | cheatfate | dom96, i think i finished my notification library and currently i'm looking in asyncdispatch.nim |
| 12:44:47 | cheatfate | and there a problem, because asyncdispatch.nim is for some reason works and designed to work only with sockets |
| 12:46:01 | cheatfate | my library can work with sockets/pipes/signals/processes/timers/user events |
| 12:46:29 | cheatfate | and i think with file descriptors too |
| 12:52:27 | dom96 | I'm certain it can be made to work with those |
| 12:52:48 | dom96 | asyncdispatch support file descriptors |
| 12:52:57 | dom96 | via asyncfile |
| 12:54:09 | cheatfate | dom96, i think we need to invent some kind of framework |
| 13:02:00 | niv | i have a question: why does this do "new result" here? isnt the result object allocated automagically? https://github.com/nim-lang/Nim/blob/a61d5e466beb8dc5efeb4a96511c8162fe16f38c/lib/pure/logging.nim#L157 |
| 13:02:29 | * | girvo joined #nim |
| 13:03:24 | * | lcm337 quit (Quit: Page closed) |
| 13:03:44 | cheatfate | niv, you need to allocate "ref object" objects |
| 13:04:02 | cheatfate | but you can use result = ConsoleLogger() it will do the same |
| 13:04:04 | niv | oh, otherwise the ref is something akin to nullptr? |
| 13:04:28 | cheatfate | yep its nil[null] otherwise |
| 13:04:37 | niv | im pretty new to nim still. dug into it a few months back and wrote some code, but forgot all i learned really. what always confused me was newString() vs "" |
| 13:05:01 | niv | i have been using newString() to explicitly allocate a buffer to pass to a importc function |
| 13:05:33 | cheatfate | "" do the same as newString() |
| 13:07:10 | niv | yes, but not if i do newString(128) to allocate 129 bytes for str.cstring, right? |
| 13:09:16 | cheatfate | niv, i think you can get more info/examples in http://rosettacode.org |
| 13:10:01 | niv | cheers |
| 13:12:00 | * | McSpiros quit (Ping timeout: 250 seconds) |
| 13:14:18 | * | darkf quit (Quit: Leaving) |
| 13:15:21 | * | girvo quit (Ping timeout: 276 seconds) |
| 13:17:24 | * | thotypous joined #nim |
| 13:23:34 | * | fredrik92 quit (Read error: Connection reset by peer) |
| 13:31:11 | * | gokr joined #nim |
| 13:49:39 | * | coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 14:04:04 | * | izi joined #nim |
| 14:11:17 | * | girvo joined #nim |
| 14:14:45 | * | fredrik92 joined #nim |
| 14:23:16 | * | girvo quit (Ping timeout: 264 seconds) |
| 14:29:08 | * | alexsystemf_ joined #nim |
| 14:38:54 | * | pregressive joined #nim |
| 14:42:45 | * | McSpiros joined #nim |
| 14:56:45 | * | McSpiros quit (Quit: Page closed) |
| 14:58:52 | * | arnetheduck quit (Ping timeout: 252 seconds) |
| 15:01:20 | * | pregressive quit (Read error: Connection reset by peer) |
| 15:02:18 | * | pregressive joined #nim |
| 15:07:58 | * | dorei quit (Quit: Page closed) |
| 15:11:59 | * | InfinityBear joined #nim |
| 15:19:45 | * | girvo joined #nim |
| 15:29:25 | elrood | nim docset for dash/zeal up at https://www.dropbox.com/sh/7jdv2e8zdr03dfz/AADlSvHZ5IRehieM--J1c4Dxa?dl=0 |
| 15:32:19 | * | girvo quit (Ping timeout: 248 seconds) |
| 15:39:08 | dom96 | elrood: maybe you could document how you generated that in the wiki? |
| 16:04:39 | federico3 | dom96: what is this XXTEA algorithm in nimble? :-/ |
| 16:05:05 | dom96 | dunno, why? |
| 16:07:19 | * | vendethiel joined #nim |
| 16:08:29 | federico3 | 1) XXTEA does not seem to be that secure https://en.wikipedia.org/wiki/XXTEA 2) it's implemented in Nim instead of using a well known, well tested library 3) there is no mention of any security review of the implementation |
| 16:11:06 | * | GangstaCat joined #nim |
| 16:15:28 | * | pregressive quit (Remote host closed the connection) |
| 16:15:45 | dom96 | federico3: Package repositories (or at least package repositories which don't belong to system package managers) don't typically vet packages for criteria like the ones your described. |
| 16:16:10 | federico3 | (technically, some do.) |
| 16:16:54 | * | InfinityBear quit (Ping timeout: 246 seconds) |
| 16:16:59 | dom96 | I'm sure some do, yes. But most don't, and we really don't have the resources to spend time validating packages in such a way. |
| 16:17:04 | federico3 | ...and given the size of the repository and that PRs are required to commit to it, it would be quite easy to reject or remove packages |
| 16:17:50 | dom96 | But why is it an issue? Just don't use it if you don't trust it. |
| 16:19:16 | federico3 | it's an issue only if there's an expectation that the packages in Nimble match some basic criteria :) |
| 16:20:03 | dom96 | Currently they don't, we have such a low amount of packages that I am just accepting all of them :P |
| 16:20:17 | federico3 | if the list is not being curated at all, please put a big warning on https://github.com/nim-lang/packages/blob/master/README.md |
| 16:22:04 | * | yglukhov quit (Ping timeout: 240 seconds) |
| 16:22:06 | federico3 | "such a low amount of packages" -> I see your point, but I'm not sure that keeping all sort of packages around (especially broken/obsolete ones) help grow the community - it can discourage people |
| 16:22:09 | * | brson joined #nim |
| 16:28:15 | * | girvo joined #nim |
| 16:29:45 | * | brson quit (Ping timeout: 244 seconds) |
| 16:30:31 | * | brson joined #nim |
| 16:32:32 | krux02 | dom96: A low amount of packages can also be the reason to be able to check all of them |
| 16:33:07 | dom96 | federico3: feel free to go through the list of packages and pick out ones which are broken/obsolete :) |
| 16:35:55 | * | brson quit (Ping timeout: 244 seconds) |
| 16:36:31 | elrood | a reasonably automated and easy to use way to mark packages as outdated or broken shouldn't be that hard to set up, and it would benefit the language as a whole tremendously |
| 16:36:35 | federico3 | I'll send a PR for the readme file |
| 16:36:45 | * | brson joined #nim |
| 16:37:10 | federico3 | elrood: https://github.com/nim-lang/packages/blob/master/.travis.yml#L20 |
| 16:38:12 | * | desophos joined #nim |
| 16:38:34 | * | niv quit (Ping timeout: 240 seconds) |
| 16:38:38 | dom96 | The package repository already contains tags for each package. |
| 16:38:54 | dom96 | I would prefer to tag things "unsafe" or "obsolete" or whatever instead of removing them. |
| 16:39:14 | dom96 | Although you might find that the authors of those packages are not too happy to have their package's deemed unsafe :P |
| 16:41:07 | * | girvo quit (Ping timeout: 248 seconds) |
| 16:41:09 | elrood | i still remember how dsource for d slowly turned into a pile of bitrot, discouraging any newcomers and people searching for a comprehensible list of usable libraries. no way of telling how many people dismissed d or any comparable project for similar causes, it would be a shame if nim stumbled into the same trap unnecessarily |
| 16:42:03 | * | niv joined #nim |
| 16:46:42 | elrood | federico3, that's nice as the very bare minimum, but not sufficient at all. the very least one should aim for is a list stating the last time a package was updated, and a way to comment or vote on its status |
| 16:49:12 | federico3 | +1 elrood, and ideally travis CI could test if the packages are compatible with the latest Nim release. |
| 16:57:18 | dom96 | Which is why we need a dedicate Nimble packages website. |
| 16:57:46 | niv | left-pad.nim plz |
| 16:58:07 | dom96 | lol |
| 16:58:51 | federico3 | :D |
| 16:59:05 | dom96 | Pretty sure strutils.indent already does it's job |
| 16:59:09 | niv | also can i badger you about when you might be working on jester again? |
| 16:59:14 | federico3 | dom96: a website? |
| 16:59:24 | * | brson quit (Quit: leaving) |
| 16:59:45 | dom96 | niv: good question :) |
| 17:00:03 | niv | i dont expect instant gratification, im just being whingy about the global exception handler thing |
| 17:00:07 | dom96 | niv: Hopefully soon, I haven't worked on it in a long time. |
| 17:00:25 | dom96 | federico3: like npmjs.com or hackage |
| 17:00:27 | niv | i had a brief look at the code but this whole macro/route/template business is a bit wooshy for me |
| 17:02:17 | federico3 | urgh npm /o\ |
| 17:03:11 | * | desophos quit (Remote host closed the connection) |
| 17:04:14 | * | desophos joined #nim |
| 17:04:28 | * | enthus1ast1 joined #nim |
| 17:05:53 | * | enthus1ast quit (Ping timeout: 244 seconds) |
| 17:06:20 | dom96 | niv: I'll see about adding a global exception handler today, but can't make any promises. Are there any other things you would like to see in Jester? |
| 17:07:02 | niv | really just a way to capture exceptions for individual requests and return custom data instead of the precooked 500 string |
| 17:07:13 | * | yglukhov joined #nim |
| 17:07:18 | niv | you dont have to hurry on my account, i was just being badgery |
| 17:07:33 | niv | the next big item on the wishlist would be middlewares but thats much more involved |
| 17:07:33 | * | yglukhov quit (Remote host closed the connection) |
| 17:08:03 | niv | [rack actually does error handling with middlewares too, but its not neccessary i guess just for that] |
| 17:08:05 | * | yglukhov joined #nim |
| 17:09:23 | * | enthus1ast1 quit (Ping timeout: 248 seconds) |
| 17:10:31 | niv | dom96: if youre curious, here's my hacky code where im using jester :) https://gist.github.com/niv/444a1f5fb7f14c2e761f3145cbdc5d8f |
| 17:10:40 | * | Jesin quit (Quit: Leaving) |
| 17:11:13 | niv | you can see how im using excpetions to validate arguments in authenticateServer, but right now jester just 500s instead of giving a proper error |
| 17:11:16 | dom96 | niv: A more important thing I think is to finally release Jester 0.1, it's been release-less for far too long... |
| 17:12:31 | * | yglukhov quit (Ping timeout: 252 seconds) |
| 17:12:40 | dom96 | yeah, jester is designed to show the stack trace in the browser. |
| 17:13:07 | niv | thats not something you want to show up on api consumers though |
| 17:13:21 | * | desophos quit (Remote host closed the connection) |
| 17:16:44 | * | pregressive joined #nim |
| 17:19:02 | niv | actually, middlewares shouldnt even be hard to do |
| 17:19:09 | niv | hmm. |
| 17:24:09 | * | pregressive quit (Remote host closed the connection) |
| 17:26:33 | * | silven quit (Ping timeout: 244 seconds) |
| 17:27:21 | * | silven joined #nim |
| 17:30:50 | * | brson joined #nim |
| 17:31:19 | niv | dom96: adding middlewares would probably be the best way for global exception handlers too |
| 17:31:52 | dom96 | I have a feeling that both may involve implementing a similar thing |
| 17:32:07 | niv | should be really easy, just wrap the actual handler call with the call chain. then support addMiddleware() that pushes a handler onto a seq |
| 17:32:40 | niv | i can stub out some pseudocode if you want to start off |
| 17:33:09 | dom96 | sure, that would be helpful. Would also like to see the usage you envision |
| 17:33:20 | dom96 | just some code showing how you will use the middlewares |
| 17:33:47 | * | alexsystemf_ quit (Quit: Connection closed for inactivity) |
| 17:37:23 | * | girvo joined #nim |
| 17:50:00 | * | girvo quit (Ping timeout: 246 seconds) |
| 17:53:50 | niv | dom96: https://gist.github.com/niv/8c214f65743c7909c1686b51fa9213a3 example code typed down in a hurry. imactually late for something so i have to run, but i'll be around tomorrow again if you want to chat about it |
| 17:55:45 | niv | im not too sure on how to do the custom request data. cant very well have it untyped i guess, but it needs to be flexible - for example, a request mixing in it's JsonNode representation somehow |
| 17:58:06 | * | Jesin joined #nim |
| 18:01:07 | * | endragor quit (Read error: Connection reset by peer) |
| 18:02:14 | * | endragor joined #nim |
| 18:04:44 | * | Jesin quit (Quit: Leaving) |
| 18:13:28 | * | endragor_ joined #nim |
| 18:14:40 | * | Jesin joined #nim |
| 18:15:45 | * | InfinityBear joined #nim |
| 18:16:40 | * | endragor quit (Ping timeout: 244 seconds) |
| 18:17:26 | * | yglukhov joined #nim |
| 18:17:39 | * | endragor_ quit (Ping timeout: 246 seconds) |
| 18:19:22 | * | boopsiesisaway is now known as boopsies |
| 18:26:01 | * | anp1 joined #nim |
| 18:31:17 | * | McSpiros joined #nim |
| 18:32:09 | * | pregressive joined #nim |
| 18:45:05 | * | desophos joined #nim |
| 18:45:11 | * | Matthias247 joined #nim |
| 18:46:12 | * | pregressive quit (Ping timeout: 276 seconds) |
| 18:46:17 | * | girvo joined #nim |
| 18:48:29 | * | pregressive joined #nim |
| 18:49:45 | dom96 | So guys, myself and Araq have been working on this for the past two days. We thought that we should ask what you think before publishing it everywhere. We've started a Bountysource Salt campaign: https://salt.bountysource.com/teams/nim |
| 18:50:16 | * | desophos quit (Ping timeout: 264 seconds) |
| 18:58:58 | * | McSpiros quit (Quit: Page closed) |
| 18:59:17 | * | McSpiros joined #nim |
| 19:00:30 | * | pregressive quit (Remote host closed the connection) |
| 19:01:32 | McSpiros | Hey Dom. I think this will be good for Nim of it picks up, even a little |
| 19:02:17 | * | desophos joined #nim |
| 19:02:40 | dom96 | hey McSpiros, glad you think so :) |
| 19:03:20 | McSpiros | is it live now? |
| 19:03:53 | dom96 | yeah, although it's only available through that URL really. |
| 19:04:00 | * | desophos quit (Remote host closed the connection) |
| 19:04:04 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 19:04:16 | dom96 | McSpiros: have you read through it, anything you think we could improve in the text? |
| 19:05:01 | McSpiros | Yes i did, but give me a moment to check it again and see if I can come up with anything |
| 19:05:26 | dom96 | Brilliant, thank you |
| 19:06:09 | * | pregressive joined #nim |
| 19:06:33 | niv | first blood! |
| 19:06:47 | * | desophos joined #nim |
| 19:07:37 | dom96 | niv: Thank you! :D |
| 19:08:53 | * | desophos quit (Remote host closed the connection) |
| 19:09:12 | niv | :) |
| 19:09:24 | McSpiros | aah, you beat me to it :) |
| 19:09:37 | * | desophos joined #nim |
| 19:09:52 | McSpiros | dom i think the text is pretty clear |
| 19:10:07 | dom96 | McSpiros: Great :) |
| 19:10:12 | dom96 | Thank you for reading |
| 19:10:17 | dom96 | and for the donations! |
| 19:10:23 | McSpiros | and well written, i can't think of anything that could be improved there |
| 19:10:26 | niv | 10/10 would read again |
| 19:11:18 | dom96 | niv: hah |
| 19:11:58 | * | enthus1ast joined #nim |
| 19:14:01 | dom96 | Now to edit some HTML to put this on the front page of nim-lang.org |
| 19:14:32 | McSpiros | i guess 2nd place isn't that bad :) |
| 19:16:51 | * | niv sniggers |
| 19:17:58 | McSpiros | :) |
| 19:18:37 | niv | now that i spent $5, i demand 24/7 personal support |
| 19:18:55 | * | pregressive quit (Read error: Connection reset by peer) |
| 19:20:03 | McSpiros | niv: It is only fair after all |
| 19:20:11 | Araq | hey niv. what can I do for you? |
| 19:20:19 | niv | yes, $5 buys like three cups of ramen |
| 19:20:31 | dom96 | hello niv, me and Araq are both at your service. |
| 19:20:36 | dom96 | :P |
| 19:20:38 | McSpiros | hahah |
| 19:20:45 | * | niv grins evilly |
| 19:21:08 | Araq | for $5 I shall tell you why your favorite OS is garbage. |
| 19:21:24 | niv | whats wrong with nimOS?! |
| 19:21:33 | Araq | it doesn't exist. |
| 19:21:40 | niv | hence its crap? |
| 19:21:53 | Araq | yup. it's vaporware. |
| 19:25:47 | * | yglukhov quit (Remote host closed the connection) |
| 19:31:44 | * | Jesin quit (Quit: Leaving) |
| 19:33:03 | * | Varriount quit (Ping timeout: 240 seconds) |
| 19:35:58 | * | BitPuffin quit (Ping timeout: 248 seconds) |
| 19:43:05 | * | Varriount joined #nim |
| 19:43:40 | * | McSpiros quit (Quit: Page closed) |
| 19:43:47 | niv | Araq: so why is osx garbage then? |
| 19:44:06 | * | McSpiros joined #nim |
| 19:44:28 | * | yglukhov joined #nim |
| 19:45:05 | niv | having a really hard time deciding on my favourite os. im pretty sure i think myself they're all garbage, but i use them anyways |
| 19:45:30 | Araq | because it's based on this "document based" philosophy but underneath is Unix which is based on processes. so there is a mismatch and spanning multiple processes is much easier than writing a program that can deal with multiple documents |
| 19:45:59 | Araq | and there are all kind of things that don't work. for example 'fork' doesn't work with Cocoa. |
| 19:46:13 | niv | oh, and resource forks. a great idea, 20 years ago |
| 19:46:50 | Araq | IMHO 'fork' is a horrible interface. |
| 19:47:48 | niv | yeah, ive never seen it used in anything but server daemons |
| 19:52:33 | niv | i'll ask next month then why linux is gargabe |
| 19:52:38 | niv | garbage. words. |
| 19:53:38 | Araq | because it doesn't run Starcraft 2. |
| 19:54:17 | krux02 | actually with wine starcraft 2 does work on linux (I've heared it, not tested it) |
| 19:54:49 | niv | i have win10 on my desktop, works fine for gaming :) |
| 19:55:14 | krux02 | I have arch linux, works fine for playing indie games |
| 19:55:23 | krux02 | btw: stop gaming start playing |
| 19:55:26 | Araq | krux02: IME nothing works fine with wine. but maybe it got better. |
| 19:55:53 | niv | krux02: whats the difference? |
| 19:56:30 | * | desophos quit (Remote host closed the connection) |
| 19:57:17 | krux02 | niv: I think there is no real difference, but I have the impression gaming is used, when playing games is taken seriosly, like meeting regularly and doing training and complaining about that other people do not enouch in the guild etc |
| 19:57:25 | krux02 | and playing is when it's just about having fun |
| 19:57:35 | niv | ugh no. :) not what i meant at all |
| 19:58:46 | krux02 | Araq: let's say in wine there are things that work well, but you should better not expect it. |
| 19:59:34 | niv | i tried wine on my macbook for some light 3d apps and none worked. i figured its very chipset-dependent |
| 19:59:41 | niv | the newer intel ones seem not too great |
| 19:59:54 | * | desophos joined #nim |
| 20:00:15 | krux02 | I use it for windows xp time games |
| 20:00:19 | krux02 | works mostly |
| 20:00:44 | krux02 | or better said, often |
| 20:02:29 | niv | i'd rather play natively to get best perf and compatibility |
| 20:02:53 | krux02 | yes but sadly windows is not always the best option to play windows games |
| 20:03:00 | krux02 | especially when time goes by |
| 20:03:31 | krux02 | There are games that work on wine, that don't work on windows anymore |
| 20:04:02 | niv | youre not supposed to play old games, you need to buy the newest yearly installment for best experience |
| 20:05:02 | cheatfate | Araq, and what is your favourite OS now? :) |
| 20:06:23 | cheatfate | or maybe OS philosophy? |
| 20:10:00 | krux02 | how about templeos |
| 20:12:16 | Araq | cheatfate: Windows XP :-) |
| 20:13:57 | cheatfate | windows 2000 was much better than xp :) |
| 20:17:46 | * | pregressive joined #nim |
| 20:21:04 | * | mat4 joined #nim |
| 20:21:10 | mat4 | hello |
| 20:21:26 | krux02 | mat4: hello |
| 20:21:39 | * | pregressive quit (Client Quit) |
| 20:22:46 | * | desophos quit (Remote host closed the connection) |
| 20:23:49 | mat4 | hi krux02 |
| 20:24:16 | krux02 | ask your question |
| 20:24:55 | Araq | krux02: mat4 is just a friendly Nim user. he doesn't join to ask questions. he knows everything. |
| 20:25:41 | mat4 | not everything of course |
| 20:27:31 | * | Jesin joined #nim |
| 20:28:05 | Araq | I still don't understand your threaded interpreters ;-) |
| 20:28:16 | Araq | black magic. |
| 20:31:58 | * | desophos joined #nim |
| 20:37:28 | cheatfate | threaded interpreters? interesting |
| 20:37:36 | mat4 | there misuse the branch-target buffer of out-of-order superscalar processors for static branch prediction, eleminating the call overhead |
| 20:39:26 | krux02 | aha, now I get it |
| 20:44:00 | mat4 | it works quite well and reduce the whole dispatch overhead to less than two cycles in the current version |
| 20:44:08 | mat4 | (Intel Core i3) |
| 20:44:11 | dom96 | The bountysource campaign is live on http://nim-lang.org now. Still fighting caching though (anybody got any tips regarding caching and nginx btw?) |
| 20:47:44 | dom96 | Oh well, I guess it's just Firefox being overly silly about caching. |
| 20:51:37 | cheatfate | dom96, what you want to cache? |
| 20:52:00 | dom96 | I think I need to once and for all set up caching properly. |
| 20:53:13 | cheatfate | dom96, http caching, static files caching, dynamic content caching? |
| 20:53:30 | dom96 | cheatfate: static files |
| 20:54:24 | federico3 | dom96: https://github.com/nim-lang/packages/pull/340 https://github.com/nim-lang/packages/pull/339 :) |
| 20:56:25 | yglukhov | dom96: nim doesnt have a description when viewed in the list on the front page: https://salt.bountysource.com |
| 20:58:02 | * | Jesin quit (Quit: Leaving) |
| 20:58:11 | dom96 | yglukhov: hrm, there doesn't appear to be a way to set that |
| 20:58:48 | yglukhov | dom96: somehow its set for other projects though =) |
| 20:58:50 | cheatfate | dom96, do you want to implement caching in jester or with nim? |
| 21:00:25 | dom96 | cheatfate: I'm setting up caching for nim-lang.org (which runs on nginx) |
| 21:00:41 | dom96 | I think I did it anyway, just a matter of setting correct 'Expires' options |
| 21:01:19 | dom96 | yglukhov: Seems like a Bountysource bug ;) |
| 21:01:52 | * | InfinityBear quit (Ping timeout: 252 seconds) |
| 21:02:57 | cheatfate | dom96, ahh ok |
| 21:04:22 | yglukhov | dom96, its kinda unfortunate that only nim subjected to that bug =). maybe you should ping their support team? |
| 21:05:14 | dom96 | yglukhov: Was just about to do that :) |
| 21:05:22 | yglukhov | cool! |
| 21:07:32 | dom96 | in fact, just asked #bountysource |
| 21:07:39 | dom96 | IRC support ftw |
| 21:08:09 | mat4 | just noticed, the LXDE project name is even wrong written (LXLE) |
| 21:15:38 | dom96 | yglukhov: Fixed :) |
| 21:15:54 | dom96 | Turns out that field was in the ordinary bountysource team settings page |
| 21:15:56 | dom96 | not the salt one |
| 21:16:34 | yglukhov | yay! =) |
| 21:17:54 | niv | dom96: alright, done being busy with less important stuff. did you have a chance to check over my "document"? |
| 21:19:49 | dom96 | hah |
| 21:20:50 | dom96 | Still gotta finish some stuff |
| 21:21:01 | * | Demon_Fox joined #nim |
| 21:28:16 | dom96 | niv: ok, where is this document of yours? |
| 21:28:42 | niv | [19:53:50] <niv> dom96: https://gist.github.com/niv/8c214f65743c7909c1686b51fa9213a3 example code typed down in a hurry. imactually late for something so i have to run, but i'll be around tomorrow again if you want to chat about it |
| 21:28:43 | niv | [19:55:45] <niv> im not too sure on how to do the custom request data. cant very well have it untyped i guess, but it needs to be flexible - for example, a request mixing in it's JsonNode representation somehow |
| 21:30:56 | * | BitPuffin|osx joined #nim |
| 21:32:44 | * | yglukhov quit (Remote host closed the connection) |
| 21:33:49 | * | ^aurora^ joined #nim |
| 21:34:26 | dom96 | niv: doing next.call in every middleware callback would still be verbose, but I'm sure there is a way to automate that |
| 21:34:39 | dom96 | looks good, but I don't think i'll get a chance to implement it today |
| 21:34:51 | dom96 | wanted to at least do some work on Nim in Action today :) |
| 21:34:54 | niv | the point is something akin to "yield", so the middlewhere can decide where (pre/middle/post/wrap) and if at all to call the next |
| 21:35:14 | niv | the actual syntax i wrote is broken ofc, since im a shrub |
| 21:36:29 | * | kevin__ joined #nim |
| 21:36:46 | niv | not sure how else you could do it and keep the same functionality |
| 21:36:59 | dom96 | I'll have to see how it's done in Sinatra et al. |
| 21:37:28 | * | kevin__ is now known as nivek |
| 21:37:38 | niv | dom96: https://github.com/rack/rack/blob/master/lib/rack/server.rb#L342 |
| 21:39:14 | niv | its a bit more involved in rack, since it builds a tree of separate apps (which you can use atomically or as a chain i guess), but the principle is the same |
| 21:40:36 | dom96 | but in there it's just returning a boolean to determine whether to call the next middleware right? |
| 21:41:22 | * | desophos quit (Remote host closed the connection) |
| 21:43:02 | niv | its returning the full response all the way down the chain. each middleware can edit the response, or omit/replace it |
| 21:43:40 | Araq | sounds like you're reinventing function calls. |
| 21:44:18 | niv | well yes, its a nested call chain of functions |
| 21:44:56 | enthus1ast | maybe you could add a (digital) copy of "Nim in Action" ? : ) |
| 21:45:26 | Araq | niv: jester supports function calls because Nim does. ;-) |
| 21:45:45 | niv | what are you on about? |
| 21:46:03 | niv | this is about adding a middleware stack, however it looks, to jester. it cant be done the way it is now |
| 21:46:13 | Araq | why not? |
| 21:46:29 | niv | because jester needs to call our middlewares for each request and wrap them |
| 21:46:36 | niv | it cant be done from inside the routing |
| 21:46:40 | dom96 | enthus1ast: to jester? :) |
| 21:47:07 | enthus1ast | dom96: is someone is supporting the bountysource campain |
| 21:47:09 | enthus1ast | if |
| 21:47:36 | dom96 | enthus1ast: wish I could, that would require some agreement with my publisher |
| 21:47:52 | dom96 | enthus1ast: but you know, you could always just buy a copy |
| 21:50:15 | * | boopsies is now known as boopsiesisaway |
| 21:52:56 | * | couven92 joined #nim |
| 21:56:52 | * | fredrik92 quit (Ping timeout: 252 seconds) |
| 22:00:22 | krux02 | I just found out that the typeinformation of sets and enums get completely compiled away, that makes it a bit harder to support those types in debuggers |
| 22:03:00 | mat4 | hmm, do you use the Gnu debugger ? |
| 22:03:09 | mat4 | (alias gdb) |
| 22:03:29 | Araq | krux02: ha, I noticed that too |
| 22:05:42 | Araq | krux02: we can change the C codegen for that, but it's unclear what to produce |
| 22:05:52 | Araq | since C doesn't know about sets at all |
| 22:05:54 | krux02 | typedefs should be fine |
| 22:06:42 | krux02 | c doesn't know, but there should if there is some naming convention for typedefs, the debugger can know |
| 22:07:42 | krux02 | typedef NU8 myenum_Enum |
| 22:08:10 | Araq | ah yeah. |
| 22:08:18 | Araq | that's a good solution. |
| 22:08:34 | krux02 | typedef UN16 myenum_Set |
| 22:10:30 | mat4 | well, I think such naming conventions are debugger specific (just to note I don't use gdb for example) |
| 22:11:52 | krux02 | mat4: gdb doesn't know those conventions either, but I can teach gdb to know them |
| 22:12:18 | krux02 | lldb should be able to do the same |
| 22:15:18 | mat4 | also it can be assumed the generated machine code which access thouse data representations is always characteristic, so I'm using an assembler level debugger and just insert some assembler code to identify there addresses. This procedere I found easier than extend some configuration files |
| 22:16:19 | * | anp1 doubts this works at optimized code |
| 22:18:12 | krux02 | who is talking through the server? |
| 22:18:36 | mat4 | anp1: works well, the x86 opcode CC for example is not optimized away for both GCC and Clang |
| 22:19:28 | mat4 | (there is also the possibility to declare such insertions as volatile) |
| 22:20:10 | anp1 | obviously not CC, but normal operations |
| 22:20:46 | anp1 | there's also the possibility to generate dwarf debug info |
| 22:21:13 | mat4 | yes of course |
| 22:21:44 | anp1 | with the advantage that there's no impact on run time |
| 22:23:00 | * | McSpiros quit (Quit: Page closed) |
| 22:26:52 | * | gunn joined #nim |
| 22:33:04 | * | izi quit (Quit: Leaving) |
| 22:33:46 | * | darkf joined #nim |
| 22:38:36 | * | desophos joined #nim |
| 22:40:40 | * | mat4 quit (Quit: Leaving) |
| 22:42:55 | * | desophos quit (Ping timeout: 250 seconds) |
| 22:46:39 | * | Trustable quit (Quit: Leaving) |
| 22:51:01 | * | desophos joined #nim |
| 22:56:22 | * | krux02 quit (Quit: Verlassend) |
| 22:59:15 | * | desophos quit (Remote host closed the connection) |
| 23:05:46 | * | girvo quit (Quit: leaving) |
| 23:05:50 | * | desophos joined #nim |
| 23:07:07 | * | elrood quit (Quit: Leaving) |
| 23:08:18 | * | couven92 quit (Quit: Bedtime! Good Night to all! :)) |
| 23:27:37 | * | anp1 quit (Ping timeout: 260 seconds) |
| 23:40:04 | dom96 | Let's see how HN reacts to a link to our Bountysource campaign :) |