| 00:00:07 | runvnc | buildpack |
| 00:00:30 | DAddYE | buildpack yes |
| 00:00:55 | DAddYE | at EOD I'm more retarded than usual |
| 00:00:56 | DAddYE | :d |
| 00:19:23 | * | vbtt quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 00:21:13 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 00:36:40 | BitPuffin | Araq: I think you'll like the let's play I just started :) |
| 00:37:40 | * | lanior joined #nimrod |
| 00:37:54 | lanior | runvnc: hi |
| 00:38:02 | runvnc | Hello |
| 00:38:20 | lanior | i did some benchmarks for you |
| 00:39:18 | lanior | do you remember our dispute about 80k RPS per core? |
| 00:40:00 | * | io2 quit () |
| 00:43:17 | runvnc | I think we were arguing about various things and not both arguing about the same thing at the same time |
| 00:43:23 | runvnc | I don't really want to fight about it |
| 00:43:43 | runvnc | What I thought you were saying was that particular benchmark page was all single core measurements |
| 00:43:48 | runvnc | which I would dispute |
| 00:43:54 | runvnc | but I don't want to argue about it anymore |
| 00:44:28 | lanior | oh thats definitely not true |
| 00:44:28 | runvnc | but if you made a benchmark just for me then certainly please link to it |
| 00:44:46 | runvnc | ok I don't want to argue about benchmarks in here |
| 00:44:56 | runvnc | we can try the offtopic channel maybe |
| 00:45:11 | lanior | we can discuss jester perfomance) |
| 00:45:24 | runvnc | I have to get something to eat |
| 00:45:27 | runvnc | sure |
| 00:45:37 | runvnc | I was not able to measure jester properly with the wrk tool |
| 00:45:46 | runvnc | wrk didnt like jester's output on my computer |
| 00:47:35 | lanior | Looks like jestil still lacking Keep-Alive support |
| 00:48:37 | lanior | ab gives me the same result with and without -k flag |
| 00:50:50 | runvnc | you can see all the code https://github.com/dom96/jester/blob/master/jester.nim starting with that plus like two other files imported |
| 00:51:03 | runvnc | does a lot for how short it is |
| 00:53:47 | lanior | On my machine it can produce 48k Hello worlds per second |
| 00:53:54 | lanior | Not bad at all |
| 00:55:31 | lanior | Comparing to 45.5k using my toy server without keep-alive support |
| 00:55:41 | lanior | And 65.5k if you are using it |
| 00:57:20 | runvnc | great |
| 00:59:06 | lanior | Node.JS - 12k RPS with keep-alive |
| 01:00:29 | lanior | And the same number without it |
| 01:00:57 | lanior | Look like it doesnt support it too or it requires some additional configuration |
| 01:01:17 | lanior | Or V8 speed is bottleneck |
| 01:04:30 | runvnc | yes of course v8 is a bottleneck there is a lot of overhead |
| 01:04:44 | runvnc | but node.js servers will do cluster mode on multiple processors out of the box |
| 01:05:21 | runvnc | but the reason I am using Nimrod and not node is because I needed to lose the overhead for a certain server agent that I was building |
| 01:06:06 | lanior | And some stunning numbers with G-WAN |
| 01:06:14 | lanior | 47k without keep-alive |
| 01:06:19 | lanior | And 272k with it |
| 01:07:26 | lanior | But I am not sure its not cheating |
| 01:07:41 | lanior | i have specified 1 worker thread but it still spawns multiple process or threads |
| 01:08:34 | lanior | And it give the same numbers without that command line option so we can divide it by 4 |
| 01:09:51 | lanior | Which gives us 68k RPS. Pretty similar to my web server |
| 01:10:29 | lanior | And that thing makes me happy because it means coroutines are not a bottleneck |
| 01:12:01 | runvnc | gwan looks interesting |
| 01:12:18 | runvnc | I wonder if there would be a way to create a nimrod wrapper for gwan or something like that |
| 01:12:27 | lanior | but many people said its butty |
| 01:12:29 | lanior | buggy* |
| 01:12:34 | lanior | and its closed-source |
| 01:13:00 | runvnc | k nvm |
| 01:13:05 | lanior | you can get same speed with nimrod why you are interested in gwan? |
| 01:14:46 | lanior | having two paths in webserver (sync and async) doesnt seems to be a good idea |
| 01:15:18 | lanior | source code looks like a mess |
| 01:19:41 | lanior | you said you are using Nimrod for some real server. Are you using blocking or nonblocking API? |
| 01:27:32 | runvnc | I'm using jester |
| 01:27:44 | runvnc | I think its blocking |
| 01:27:53 | runvnc | but the performance isn't important for me |
| 01:28:04 | runvnc | anyway I am running multiple processes fed by a queue |
| 01:28:16 | runvnc | I dont need to serve a lot of traffic just some long requests |
| 01:28:38 | * | brson quit (Ping timeout: 240 seconds) |
| 01:28:44 | lanior | How many processes do you use? |
| 01:30:27 | * | Demos joined #nimrod |
| 01:30:43 | * | brson joined #nimrod |
| 01:32:07 | runvnc | 1 right now still testing some basic things |
| 01:35:01 | lanior | why you are using jester if your processes are fed by a message queue? |
| 01:35:31 | lanior | I thought message queue == background work |
| 01:41:58 | Demos | if I have proc foo(func: proc(tup: tuple[a: distinct auto])) is there a way to access the type of a in foo or do I ned to pull it out and write proc foo[T](func: proc(tup: tuple[a: T]))? |
| 01:44:52 | runvnc | because I need basic stuff in jester. |
| 01:47:21 | Araq | Demos: the latter I'm afraid |
| 01:47:50 | Araq | btw the type API's design is finished ... now somebody needs to implement it |
| 01:56:15 | lanior | Araq: can you show it? |
| 01:56:57 | Araq | lol no ... |
| 01:57:35 | NimBot | Araq/Nimrod devel fca57e5 Araq [+0 ±1 -0]: c2nim knows about arrray[N, T] |
| 01:57:35 | NimBot | Araq/Nimrod devel 904b18e Araq [+0 ±1 -0]: improved docs about strongSpaces |
| 01:57:35 | NimBot | Araq/Nimrod devel d33854b Araq [+0 ±1 -0]: bugfix: reprEnum for enums with negative values |
| 01:57:35 | NimBot | Araq/Nimrod devel b6368ad Araq [+0 ±1 -0]: added mapMem/unmapMem to memfiles; untested |
| 01:57:35 | NimBot | 2 more commits. |
| 01:58:15 | lanior | Araq: there is no paper/wiki page describing planned API? |
| 01:58:40 | Araq | exactly. there are only some notes |
| 01:58:45 | lanior | Araw: I definitely cant implement it but I used Go/D reflection a lot so I can make a comparison. |
| 01:59:16 | Araq | ok but the comparison is most meaningless |
| 01:59:28 | lanior | I can spot missing stuff |
| 01:59:35 | Araq | the type API is type introspection at compile time for the macro system |
| 02:00:00 | Araq | *mostly meaningless |
| 02:00:01 | lanior | D has compile-time instrospection as well |
| 02:00:10 | Demos | so typetraits will have more than two procs :D |
| 02:04:01 | Araq | of the 2 procs 1 has never been implemented in the new vm :P |
| 02:05:29 | lanior | Can we construct PNimrodNode inside a macro and get it type as if it was evaluated in caller scope? |
| 02:06:15 | Araq | no as this is inherently unsound |
| 02:06:38 | Araq | and yes I know I'm the only one here who cares about soundness |
| 02:07:09 | lanior | why it is unsound? |
| 02:10:17 | Araq | I take it back, that could work |
| 02:11:37 | Araq | er ... |
| 02:11:51 | Araq | why "as evaluated in caller scope"? |
| 02:12:29 | Araq | so the macro constructs seq[int] but you shadowed 'seq' in the caller scope? |
| 02:12:36 | lanior | Example: TArticle.findOne(@slug != ""), findOne is a macro |
| 02:12:52 | lanior | I and I want to get type(TArticle.slug) |
| 02:13:09 | lanior | And make some decisions based on it |
| 02:13:32 | Araq | that's not PNimrodNode *construction* in a macro |
| 02:14:16 | lanior | I'm using immediate macro |
| 02:14:40 | Araq | that's bad |
| 02:14:42 | lanior | So passed Expr is not bound to any symbol if I understand it correctly |
| 02:17:42 | lanior | The only way I found so far is to generate AST containing all ifs |
| 02:17:46 | lanior | Like two-level macro |
| 02:17:47 | Araq | that will work without immediate soon if it doesn't already |
| 02:18:20 | lanior | But it will lead to exponential growth of code size |
| 02:18:45 | Araq | ah you are that guy |
| 02:18:51 | Araq | did you report that? |
| 02:19:08 | lanior | not yet |
| 02:19:18 | lanior | That guy? |
| 02:19:19 | Araq | I've never seen exponentail growth, very interesting ;-) |
| 02:19:38 | lanior | IT's not a bug, its just a side of this approach |
| 02:19:45 | Araq | (with nimrod's macro system) |
| 02:20:10 | lanior | Maybe I am not right |
| 02:21:47 | lanior | Non-immediade macro do semantic checks on its arguments, am i right? |
| 02:22:07 | Araq | yeah but for 'expr' a special rule is planned |
| 02:23:46 | lanior | Well this is not a big problem if my workaround is working |
| 02:23:55 | Araq | sorry need to sleep now |
| 02:23:56 | Araq | good night |
| 02:24:02 | lanior | bye |
| 02:40:23 | comex | Araq: i think rust is more complicated because statements are expressions, so a 'statement list' might be an if block |
| 02:41:32 | comex | or match |
| 02:42:04 | comex | sometimes you'd want to yield something from one of those, sometimes not, but no actual return statements need apply |
| 02:49:53 | * | grumio2 joined #nimrod |
| 02:52:35 | lanior | comex: but it is still easier than ruby because it wont let you accidentally add return value to the function |
| 02:52:42 | comex | and yes, i bandwagon |
| 02:53:05 | comex | there are reasons to like rust, though |
| 02:53:43 | lanior | like CT checked memory safety |
| 02:53:56 | lanior | but it has weird syntax |
| 02:54:12 | comex | well, that without GC, non-nullable by default, immmutable by default |
| 02:54:15 | comex | *mm |
| 02:54:17 | comex | and i like the syntax |
| 02:55:15 | lanior | non-nullable by default is one of the part of it |
| 02:55:26 | comex | well, i certainly like that |
| 02:55:42 | lanior | one of the best part* |
| 02:56:51 | comex | anyway, i'm pretty annoyed that my new favorite language has the exact same issue with incremental compilation as my old favorite language :p |
| 02:57:17 | lanior | let me guess. D? |
| 02:58:48 | comex | no, rust and nimrod |
| 02:59:27 | comex | d... i might try it, but i want to stick to one at a time |
| 03:00:38 | lanior | nimrod has problems with incremental compilation? |
| 03:01:14 | comex | well, it did when i was using it |
| 03:04:36 | comex | it parsed all source files for every compile |
| 03:05:08 | comex | rust is.. well, usually used in this way too, and it's really slow |
| 03:07:55 | grumio2 | whereas you want it to only parse the source files that changed? |
| 03:08:15 | lanior | D compiler shows that full recompilation can be really fast |
| 03:08:31 | lanior | It has fastest compiler I saw so far |
| 03:09:51 | * | Skrylar joined #nimrod |
| 03:09:56 | Skrylar | Meep! |
| 03:14:21 | comex | mm.. not that i don't like fast compilation (I do), but incremental compilation really isn't that hard... i'm just a bad programmer |
| 03:14:51 | comex | and other people apparently don't care much about compile time |
| 03:16:23 | Skrylar | evidently the C++ people who make extensive use of scripting languages disagree with that statement, as do people in the games industry who rage when someone changes a base class that causes 30 minute rebuilds |
| 03:17:15 | Skrylar | that said, what was the topic on incremental compilation? |
| 03:17:29 | lanior | preprocessor-based import is a problem |
| 03:18:08 | comex | well, clang is working on modules, which afaik includes saner incremental compilation (no more preprocessor import) |
| 03:18:34 | comex | Skrylar: i'm complaining about rust and possibly nimrod (i'm out of date)'s lack of support for it |
| 03:18:53 | Skrylar | nimrod is supposed to support it |
| 03:19:12 | Skrylar | nimrod --symbolFiles:on |
| 03:19:29 | * | brson quit (Ping timeout: 240 seconds) |
| 03:19:30 | comex | oh well, maybe i should change languages again |
| 03:20:10 | Skrylar | 1) nimrod has something like that (currently experimental) 2) most immature languages lack it |
| 03:20:28 | Skrylar | doesn't Go still do whole program compilation? |
| 03:20:49 | Skrylar | and Rust can incremental compile but only at the crate/lib level |
| 03:20:53 | lanior | yeah but it is fast enough to do that |
| 03:21:10 | comex | dunno, but i do not want to use Go for several reasons |
| 03:21:14 | lanior | incremental compilation is a problem if you want to do cross-module optimization |
| 03:21:23 | Skrylar | lanior: symbol files are supposed to fix that |
| 03:21:28 | comex | no, it's not. what he said |
| 03:21:49 | comex | and you want some kind of global cache anyway because you want to avoid duplicating generic instantiation |
| 03:22:09 | Skrylar | the only language i'm aware of that uses shared generics is Ada |
| 03:22:57 | comex | and yeah, so far my plan is to use crates of like 2 files each, but i have a feeling that's going to make full compile times bad |
| 03:23:09 | lanior | Skrylar: and c++ with exported templates? |
| 03:23:30 | Skrylar | lanior: is that standardized (+ implemented)? |
| 03:23:54 | lanior | c++11: extern template class std::vector<MyClass>; |
| 03:24:12 | Skrylar | oh, the mythical C++ Next :\ |
| 03:24:31 | lanior | Its fully implemented by at least one compiler |
| 03:25:07 | Skrylar | also, comex, the statement about cross module optimization and that rust can compile a module to a lib do not resolve each other |
| 03:25:53 | comex | huh? |
| 03:26:03 | comex | i am tired, but what do you mean? |
| 03:26:03 | Skrylar | If you use a dynamic library (and you will, because static libs plump up Rust's compiler time) then it can't optimize across those boundaries very well. Under a static library, the LLVM underneath can do some cross module optimizations |
| 03:26:36 | comex | no, llvm can only do it if you use *lto*, which is drastically slow |
| 03:27:00 | lanior | comex: anyway you wants language-level LTO |
| 03:27:02 | comex | however, it's not much worse than C++ |
| 03:27:44 | comex | which also can't generally inline across file boundaries |
| 03:28:06 | * | brson joined #nimrod |
| 03:28:20 | Skrylar | nimrod basically compiles it all in together, dead code eliminates everything (somewhat like delphi/fpc smartlink), shares generics, inlines, etc. Symbol files are intended to solve the compile time issues by letting it pre-cache the outputs AFAIK |
| 03:28:24 | lanior | comex: it can if you keep information from semantic stage until link-time |
| 03:28:46 | comex | aka lto, rust also supports llvm's lto, they are both slow |
| 03:30:35 | Skrylar | i wouldn't mind better support for shared libraries, but those are somewhat pathological in practice outside of C |
| 03:31:08 | Skrylar | GCs don't tend to work, so two libs that use a GC tend to not interface with each other and cause over-allocation of RAM |
| 03:32:16 | comex | good thing rust uses no GC |
| 03:32:34 | lanior | they moved it into library |
| 03:33:01 | comex | iirc, at the moment the library "Gc" never actually deallocates anything |
| 03:33:03 | comex | maybe they fixed it by now |
| 03:33:15 | lanior | you can still you it with std:cell AFAIK |
| 03:33:24 | comex | anyway, it's clearly not going to be used by much code |
| 03:33:53 | Skrylar | what? rust used a GC until 0.9 |
| 03:34:34 | comex | yes, but from what i've seen they're moving sharply away from it |
| 03:34:52 | Skrylar | the devel docs still mention managed pointers, though they're nonfunctional |
| 03:35:03 | Skrylar | and yes, they replaced it with an exorbinantly painful set of template soup |
| 03:35:39 | comex | yeah, mutability with Rc/Gc sounds a little too annoying now |
| 03:36:27 | Skrylar | I tried to write a GUI library in Rust. Rc<RefCell<Type>> is ugly, and even after aliasing to actually use it requires ugliness like let temp = x.copy().borrow_mut(); x.blah // i am very very readable i assure you |
| 03:36:45 | Skrylar | apparently the sprockets people were having issues with getting a DOM to work as well |
| 03:37:17 | comex | guess it's still evolving, for better or worse |
| 03:37:37 | Skrylar | their macros are also sharply inferior :) |
| 03:37:51 | comex | the way to do a vector drastically changed recently |
| 03:38:11 | comex | they are procedural now, you knwo |
| 03:38:19 | Skrylar | they went through with the [blah] -> Vec<Annoyance>? |
| 03:38:20 | comex | but no type information and stuff |
| 03:38:35 | comex | yep, and currently you can't even do a[0] rather than *a.get(0) |
| 03:38:53 | comex | i think that's getting fixed |
| 03:39:52 | Skrylar | i'm happy with nimrod. Rust is silly calling itself 0.9 when they're still making wide-sweeping changes that break everything |
| 03:40:29 | comex | perhaps... |
| 03:40:33 | Skrylar | "0.9" implies "almost done" and "0.10" is like web 2.0 stupidity |
| 03:40:38 | * | Demos_ joined #nimrod |
| 03:40:50 | Skrylar | but thats not an objective criticism, just me ranting |
| 03:41:04 | comex | 0.10 is hardly a new concept... |
| 03:42:04 | Demos_ | honestly version numbers are really just for sorting |
| 03:42:26 | comex | linux 0.11 was released in 1994... |
| 03:42:42 | Demos_ | linux 3.11 for workspaces :D |
| 03:43:13 | comex | anyway, can nimrod macros read external files? |
| 03:43:13 | Demos_ | comex so rust's GC is currently taking the PHO route |
| 03:43:15 | comex | i think rust ones can :P |
| 03:43:20 | comex | PHO? |
| 03:43:26 | Demos_ | *PHP |
| 03:43:39 | Demos_ | and comex staticRead and staticExec should do the trick |
| 03:43:47 | Skrylar | comex: staticExec |
| 03:43:53 | Demos_ | also known as slurp and gorge |
| 03:44:07 | Skrylar | Not that I really appreciate compilers that have behavior outside of themselves :/ |
| 03:44:18 | Skrylar | especially without an explicit --yes-do-potentially-bad-things flag |
| 03:44:35 | comex | afaik rust macros have the arguably saner property of basically being rust loaded into the compiler rather than some weird hybrid with the program code |
| 03:44:46 | comex | but i haven't actually tried them, just heard about them |
| 03:44:56 | Skrylar | rust macros are a crippled subset of rust |
| 03:45:06 | Skrylar | nimrod macros have direct AST access |
| 03:45:25 | Skrylar | they're more like what we'd call a template |
| 03:45:30 | Demos_ | Skrylar, well sure. But if you don't let the compiler do nasty stuff you just end up using something like autotools |
| 03:45:39 | comex | no, those are the old macros |
| 03:45:43 | comex | the new ones are rust code |
| 03:45:48 | Skrylar | Demos_: keyphrase, "without --do-bad-things" flag |
| 03:46:19 | * | Demos quit (Ping timeout: 245 seconds) |
| 03:46:27 | comex | https://github.com/mozilla/rust/issues/12178 |
| 03:46:30 | comex | example |
| 03:46:30 | Demos_ | eagh, I really don't care. Like the compiler is already totally dependent on the system |
| 03:47:07 | Skrylar | Demos_: it became important earlier when they were talking about automatically compiling babel packages and it came up that to do so safely requires hypervising |
| 03:47:20 | Demos_ | oh. Good point |
| 03:47:35 | comex | building c has long involved executing arbitrary commands written in a makefile |
| 03:47:44 | Demos_ | I would go for the approach of just having the default be the user interactively signing off on the bad thigns |
| 03:48:01 | Demos_ | like what makepkg does |
| 03:48:04 | lanior | Skrylar: it requires it anyway because of potential security bugs in compiler |
| 03:48:05 | Skrylar | i suggested Vagrant because you can set up a script to spawn a new linux box, apply the security restrictions on the box, and then go |
| 03:48:08 | lanior | like stack overflow and so |
| 03:48:20 | lanior | you can use linux containers |
| 03:48:22 | Demos_ | Skrylar vargant is so overkill |
| 03:48:56 | lanior | try docker.io |
| 03:49:01 | lanior | its dead simple to use |
| 03:49:23 | Demos_ | it is also not the write tool for installing packages |
| 03:49:30 | Demos_ | *right |
| 03:49:36 | comex | plus, use cases for cloud compiling frequently involve running the compiled code, especially "try" sites |
| 03:49:44 | comex | so you need a sandbox anyway |
| 03:49:51 | Demos_ | oh we are talking about cloud compileing,, never mind then |
| 03:49:52 | lanior | but it wont cover compilation for windows |
| 03:49:55 | Skrylar | Demos_: i hadn't heard of the other :) |
| 03:50:06 | lanior | anyway you need virtualization |
| 03:50:19 | comex | plus, not being able to run, say, python scripts to generate code is dumb. so no, compiling should not be a safe activity |
| 03:50:27 | Skrylar | oh they're not for cloud computing, its because they were talking about being able to see if compiler updates broke mass amounts of public code |
| 03:50:37 | Demos_ | comex well you should generate code with macros |
| 03:51:09 | Demos_ | also, some kind of binary libraries could be neat, but also probably insanely hard |
| 03:51:10 | lanior | how fast is compile time execution comparing to native code? |
| 03:51:22 | lanior | it was a problem for me in D lang |
| 03:51:23 | Demos_ | I have heard "faster than python" |
| 03:51:41 | comex | i wonder if rust JITs it |
| 03:51:55 | lanior | we can probably make luajit target |
| 03:52:06 | comex | yesterday i was working on some (admittedly silly) preprocessing which is too slow for python |
| 03:52:06 | Demos_ | we could, but it will not happen |
| 03:52:17 | lanior | why? |
| 03:52:26 | Demos_ | because it is a ton of work for no benifit |
| 03:52:27 | comex | i ended up using node.js, because rust's text handling currently sucks |
| 03:52:36 | Skrylar | ... hrm |
| 03:52:40 | comex | which is a major problem... |
| 03:52:42 | Demos_ | in most cases if you can use luajit you can just compile to C |
| 03:52:53 | Skrylar | Maybe not, Demos_. We don't have gotos |
| 03:53:06 | comex | in particular, no regular expression support in the standard library, lolwtf |
| 03:53:10 | lanior | nope |
| 03:53:12 | Skrylar | Compiling to lua isn't really harder than to JS |
| 03:53:22 | Demos_ | yeah I know. But why bother? |
| 03:53:23 | lanior | I thought about using nimrod as a scripting language |
| 03:53:23 | Skrylar | the question is what do we get out of it, aside from using it for CTFE |
| 03:53:34 | Skrylar | Demos_: interactive development |
| 03:53:50 | Skrylar | emit nimrod to lua, change luajit code insitu, carry on |
| 03:53:52 | Demos_ | why not just use vm2 and the REPL |
| 03:54:02 | lanior | vm2 has jit compiler? |
| 03:54:06 | Skrylar | because luajit is extremely high performance and written by a genius? |
| 03:54:15 | lanior | Skrylar: exactly |
| 03:54:18 | Skrylar | well, a jit genius |
| 03:54:25 | comex | though, with rust i know there is a lot of active development and this will probably get resolved soon, and the thing i really want (parser library) may or may not exist or be easy to install, but Cargo is coming to make package management work |
| 03:54:40 | Skrylar | not to poop on Araq, it's just that vm2 was checked in recently and luajit is in industrial use |
| 03:54:41 | comex | so i have high hopes, basically |
| 03:55:09 | Skrylar | but Demos_ asked for a use case, and i provided one :) |
| 03:55:39 | Demos_ | I just don't like what I have seen of rust. There is a lot of syntax noise, I don't like the object model, and I am not convinced linear types are all that great |
| 03:55:54 | fowl | Skrylar, araq was going to use luajit then decided to write a new vm |
| 03:56:26 | comex | (i think package management is incredibly important, just look at the crap people do in C++) |
| 03:56:32 | Skrylar | oh, i saw the epitome of horror earlier |
| 03:56:38 | Skrylar | reading the maptool wiki |
| 03:56:45 | Demos_ | comex babel is pretty good, a bit rough but OK |
| 03:57:13 | comex | Demos_: i like linear types, in C++ too |
| 03:57:20 | comex | although the implementation in C++ is incredibly stupid |
| 03:57:25 | Demos_ | unique_ptr? |
| 03:57:27 | lanior | but does it support installing modules from archives? |
| 03:57:29 | Skrylar | tell me when you get scared: 1) It runs on Java. 2) They use a custom macro language which was bolted on over time. 3) They use java's half-baked HTML renderer for styled displays. 4) Old Java HTML renderer scripted with custom macro language with a massive amount of weird restrictions |
| 03:57:51 | lanior | distributing packages through Git is not a fun thing if you have big repos |
| 03:58:10 | Skrylar | Oh and 5) Lists are strings that get strtok'd every time you parse it, TCL7-style |
| 03:58:15 | * | Skrylar shudders |
| 03:58:17 | Demos_ | lanior this is true. babel does support installing from a directory, so installing from a zip should not be hard to support |
| 03:58:33 | comex | yes, sometimes it's useful to move away from part of an existing object or something, so it's good for move constructors to leave the old object in a good state. that is *not* an excuse for there being no way at all to check if you accidentally used a local variable after moving it |
| 04:00:26 | lanior | Demos_: and is would be good to use better compression algo than deflate |
| 04:00:30 | lanior | like LZMA or so |
| 04:00:43 | Demos_ | anyway my problem with linear types is that they are only good when the ownership model is very simple. In those cases manual management is usually not /that/ hard, and as soon as you get more complex you really want a gc or shared_ptrs |
| 04:00:58 | Demos_ | yeah, we could use whatever |
| 04:01:28 | comex | i think that shared_ptr/gc is almost never actually needed |
| 04:01:36 | lanior | any plans for building public web package list like pypi? |
| 04:01:52 | Demos_ | comex, sure. You /can/ do trees with unique_ptrs, but it is really annoying |
| 04:02:06 | Skrylar | define better, lanior |
| 04:02:14 | Demos_ | lanior we will have one shortly I think, there is a pull request to add it to the library docs |
| 04:02:15 | Skrylar | Deflate is cheap, LZMA is not |
| 04:02:38 | lanior | comex: GC is a must if are using immutable data structures like ropes |
| 04:02:52 | Skrylar | When considering a compression algorithm, you have to consider the RAM/CPU and final disk size. For example LZMA produces smaller files, but RAR is more *efficient* for the size it produces |
| 04:02:56 | Demos_ | also nimrod's GC can sometimes be advantageous if you don't actually want stuff to be immediately destructed |
| 04:03:25 | comex | lanior: i said almost never, not never :P |
| 04:03:40 | lanior | Skrylar: but you cant produce RAR files without proprietary archiver |
| 04:03:47 | Skrylar | lanior: its just an example |
| 04:03:57 | Skrylar | IIRC deflate is also efficient if you trade off time/size |
| 04:04:15 | lanior | but we should only consider decompression time |
| 04:04:52 | Skrylar | well if you're prioritizing the content host, you want the smallest. in that case LZMA is probably the best free option |
| 04:05:03 | Demos_ | nobody cares for libraries. We really just want compatible files, maybe with the ability to navigate the archive without decompressing |
| 04:05:18 | comex | just use zip like everyone else |
| 04:05:37 | lanior | im prioritizing for installation speed |
| 04:05:39 | Skrylar | zip uses deflate, which is what lanior was complaining about |
| 04:05:58 | comex | (jar, docx, odt, python eggs, chrome extensions, god knows how many other things) |
| 04:06:01 | Demos_ | again, nobody cares. libraries are rarely al that big |
| 04:06:15 | Demos_ | and zlib is everywhere and easy to deal with |
| 04:06:38 | Skrylar | i wonder how complex the SDK for that is |
| 04:06:41 | Skrylar | LZMA |
| 04:07:11 | comex | it's not. i've used xz utils, it has a zlib-like api |
| 04:07:20 | comex | and then you just do .tar.xz like unix |
| 04:07:25 | lanior | I guess you are right |
| 04:07:31 | Skrylar | yeah, i was going to say that 'tar' is a very easy format to parse |
| 04:07:32 | Demos_ | copying pacman is usually a good idea |
| 04:07:42 | Skrylar | zip is actually easy to parse, but tar is even easier |
| 04:08:10 | lanior | any plans for shipping precompiled libraries? |
| 04:08:12 | Skrylar | and i have seen the difference between tar.xz and tar.bz to be significant (50kb or more, depending on lib size) |
| 04:08:30 | Skrylar | which is not important on its own; it becomes important when you figure most people's internet use is now metered |
| 04:09:00 | comex | i'd contest 'most' |
| 04:09:23 | Skrylar | most of the euros i know talk about their hardcaps, and AT&T has softcaps they bill extra for |
| 04:09:29 | Skrylar | anyway |
| 04:09:37 | Skrylar | maybe i'll look at the xz source code later |
| 04:10:19 | comex | only if you download over mobile networks, and even then, a few hundred kb is nothing to the youtube videos people usually watch on those things :p |
| 04:11:13 | Skrylar | i want to say the 7z format is wonky to parse, but i don't have any experience with it |
| 04:11:27 | comex | me neither |
| 04:11:39 | * | Demos joined #nimrod |
| 04:12:00 | Skrylar | i think most of the people who use renamed .zips do so because zlib ports are ubiquitous and you can get zip file editors off the shelf |
| 04:12:13 | Skrylar | kind of like how HTML is kinda terrible for a lot of uses but people still use it |
| 04:12:25 | Skrylar | because of ubiquity |
| 04:12:48 | Demos | but zip is not painful |
| 04:12:55 | lanior | even Windows XP has built-in support for zip |
| 04:12:59 | Demos | like it is just a bit bigger, no need for fancy compression |
| 04:13:09 | Skrylar | lanior: ... technically it does |
| 04:13:14 | Skrylar | I'm not sure how they managed to screw it up so bad |
| 04:13:36 | lanior | well it always works for me |
| 04:13:40 | Skrylar | I have not seen a worse deflate routine than XP and 7's decompressor |
| 04:13:55 | Skrylar | It does the job, yes, its just inexplicably slow at it |
| 04:14:15 | lanior | but i used it only for decompression |
| 04:14:22 | Demos | lanior: and this is why we do not need a fancy compression algo |
| 04:15:34 | lanior | sounds reasonably |
| 04:15:56 | Skrylar | well its not realy a big deal |
| 04:16:03 | Skrylar | worst comes to worse .. support both? |
| 04:16:34 | Skrylar | as long as you implement it through a clean interface its no big deal |
| 04:20:00 | lanior | https://github.com/Araq/Nimrod/pull/998 - this PR seems to cover only package list |
| 04:20:30 | lanior | is would be nice to have something like `babel publish` which will publish new version of the package to the list |
| 04:20:36 | Demos | yeah |
| 04:21:25 | lanior | Is it scheduled? Any plans or discussion on that question? |
| 04:26:31 | Demos | there are some plans, but right now you need to make a pr. You should fork babel and start hacking! It sounds like you have some good ideas |
| 04:27:14 | * | Demos_ quit (Quit: Textual IRC Client: www.textualapp.com) |
| 04:29:08 | lanior | well I am still a nimrod newbie so it would take to study language and babel codebase |
| 04:30:43 | Demos | babel is as good a place to start as any |
| 04:31:29 | lanior | right now I am trying to build ORM for Nimrod |
| 04:31:54 | lanior | because I primarily interested in Nimrod as a replacement for python/django |
| 04:33:36 | Skrylar | Hmm, that might be easy to do at the low level |
| 04:33:46 | Skrylar | I should probably bug araq about annotation support |
| 04:33:56 | lanior | nope |
| 04:34:05 | lanior | i will do it django-way |
| 04:34:26 | Skrylar | i like annotation support because there are certain times it works well with macros |
| 04:34:44 | lanior | type system can't express all required constraints |
| 04:35:00 | * | brson quit (Quit: leaving) |
| 04:35:05 | Skrylar | i'd have to disagree with that, unless you have crazy restraints |
| 04:35:06 | lanior | custom setters/getters seems to be a better idea for me |
| 04:35:16 | lanior | max string length is pretty common |
| 04:35:18 | * | brson joined #nimrod |
| 04:35:30 | Skrylar | it can do a considerable amount of it, though a bigger problem is the TAny interface can't identify a specific type as i understand it |
| 04:35:42 | Skrylar | it knows what an Object is, but it doesn't know that the object is actually X type |
| 04:36:07 | Skrylar | of course I could be completely wrong and the any interface has some secret voodoo with generics to allow exactly that |
| 04:36:14 | lanior | I want all checks to happen at compile-time |
| 04:36:32 | Demos | max string length can be done using the type system I think |
| 04:36:47 | Skrylar | custom setters would be the most robust, yeah |
| 04:37:04 | Demos | but I know nothing about ORM so you should ignore me |
| 04:37:12 | Skrylar | you could probably write a macro so you had an easy way of invoking common constraints |
| 04:37:39 | lanior | but you definetily can't run regexp check |
| 04:37:53 | Skrylar | ... actually... |
| 04:38:01 | Skrylar | distinct type + macro implementation of assignment |
| 04:38:05 | Skrylar | CTFE regexp |
| 04:38:05 | lanior | using type system? |
| 04:38:19 | Skrylar | but that only applies to regexping literals |
| 04:38:36 | lanior | well regexp check is about runtime values |
| 04:39:07 | Skrylar | AFAIK you can use proc, template or macro to implement any function; and since nimrod operators are just funny named functions, you could implement the compile-time check that way |
| 04:39:08 | lanior | making nice looking DSL for queries seems to be the hardest part |
| 04:39:22 | lanior | yeah I know |
| 04:39:35 | Skrylar | all though the downside is creating types that are only meant to be used in a single struct, unless the constraints common occurances its silliness |
| 04:39:51 | lanior | I can just use private fields |
| 04:39:55 | * | brson_ joined #nimrod |
| 04:40:25 | lanior | https://docs.djangoproject.com/en/dev/topics/db/models/#fields |
| 04:40:28 | Skrylar | now you have me curious |
| 04:40:32 | lanior | that is my aim |
| 04:42:38 | * | brson quit (Ping timeout: 240 seconds) |
| 04:43:05 | lanior | is there any support for inline testing? |
| 04:43:21 | Skrylar | two options; unit test module and doAssert |
| 04:43:35 | Skrylar | let me grab one of my github files that has it as an example |
| 04:44:08 | Demos | people often use "when isMainModule" to write some tests, doAssert is probably a better option atm, unittest has some issues |
| 04:44:18 | Skrylar | https://github.com/Skrylar/Skylight/blob/master/skylight/maxrectpack.nim uses unittest, though that module has some ankle biting problems |
| 04:44:25 | Skrylar | it does give you the neat color coded list of passed tests though |
| 04:44:48 | lanior | how does when isMainModule thing work? |
| 04:45:17 | Skrylar | nimrod c myfile.nim # myfile is the main module |
| 04:45:20 | lanior | i thought its a compile-time if statement |
| 04:45:26 | Demos | it is |
| 04:45:26 | Skrylar | yes |
| 04:45:28 | lanior | can I use it to test all modules? |
| 04:45:31 | lanior | at once |
| 04:45:38 | Demos | but isMainModule is true when you pass that file to the compiler |
| 04:45:41 | Skrylar | you can choose when isDefined("unittest") instead |
| 04:46:06 | Skrylar | then when you do a -d:unittest build it should include them |
| 04:46:15 | Skrylar | i use 'when isMainModule' because i unit test modules by compiling them directly |
| 04:48:05 | * | brson_ is now known as brson |
| 04:48:14 | lanior | so there is no standardized test runner? |
| 04:55:42 | runvnc | when isMainModule is the standard |
| 04:56:05 | Demos | well there is the unittest module, and if you code your tests seperately from your implementation files than you can run them as you would any other programs. when isMainModule is more for quick sanity checks, not large test suites |
| 04:56:39 | Demos | that said it may be possible to like descend through the directory tree and run all the tests |
| 04:56:44 | lanior | but I cannot test private stuff with external test suit right? |
| 04:57:11 | lanior | yes, that is what I was asking about |
| 04:57:14 | Demos | actually if you include the file instead of importing it then.... |
| 04:57:41 | lanior | magic command like `tester run_all_tests` |
| 04:58:15 | * | Endy joined #nimrod |
| 04:58:26 | Demos | something like that would be good, but it would require looking at all the source files |
| 04:58:48 | Demos | actually... can macros import modules? |
| 05:01:01 | lanior | is there any good tutorial for nimrod? |
| 05:01:24 | Demos | not really. There is the tutorial on the site to get you started |
| 05:01:36 | lanior | its more like feature showcase |
| 05:01:41 | Demos | hehe |
| 05:02:01 | lanior | now i will complaint about documentation |
| 05:02:21 | Demos | most of the features come from someplace else, like generics are very similar to C++/D templates, macros are lispish, and so on |
| 05:02:31 | lanior | its... not really terrible, but not as good as it should be |
| 05:02:48 | lanior | documentation for system module is almost useless |
| 05:03:04 | * | grumio2 quit (Quit: Lost terminal) |
| 05:03:13 | Demos | I use the index a lot. Do keep in mind that we have a grand total of zero full time devs. |
| 05:03:28 | Demos | also keep in mind we love documentation related pull requests |
| 05:03:43 | lanior | its nearly impossible to stop interesting stuff (like staticRead) in that HUGE list |
| 05:04:19 | lanior | it mixes stuff I dont care about (like tons of overloads for standard operators) with cool magic functions like compile |
| 05:05:03 | lanior | next thing, standard library looks like a collections of random modules |
| 05:05:13 | lanior | most of them should be a separate package |
| 05:05:37 | lanior | like DB-related stuff |
| 05:06:04 | lanior | yes it works, yes its easy to use, but it covers only simple stuff |
| 05:06:28 | lanior | such modules tends to evolves faster than language |
| 05:07:01 | lanior | I think its better to keep them separately |
| 05:07:10 | Demos | lanior: look at the development docs |
| 05:07:12 | Demos | not the release docs |
| 05:07:20 | Demos | a lot of packages were moved into babel recently |
| 05:07:35 | lanior | can you give me a link please? |
| 05:08:29 | lanior | found it |
| 05:08:42 | Demos | http://build.nimrod-lang.org/docs/overview.html |
| 05:08:48 | lanior | it would be better to have direct link on the website |
| 05:09:19 | Demos | this is true |
| 05:09:53 | Demos | remind me never to pay $10 for a flash drive ever again |
| 05:11:37 | * | Raynes joined #nimrod |
| 05:29:22 | * | DAddYE joined #nimrod |
| 05:29:35 | * | Endy quit (Ping timeout: 252 seconds) |
| 05:38:52 | Demos | if I have like subdir/module.nim and subdir/module2.nim is there any way to write like import module2 in module. So I can lift the files out to another project? |
| 05:41:36 | fowl | Demos, that works, try it |
| 05:42:46 | Demos | really I had problems a bit ago |
| 05:46:19 | * | brson quit (Ping timeout: 245 seconds) |
| 05:52:04 | Demos | seems to work... hrm |
| 05:52:26 | Demos | maybe before I was having problems with scope in my macros |
| 05:53:00 | * | brson joined #nimrod |
| 06:02:38 | lanior | how can i produce compile-time error outside of macro? |
| 06:05:08 | lanior | https://gist.github.com/anonymous/e67b6ae4c65396445bbe - this fails with `Error: cannot generate code for 'error'` |
| 06:05:18 | * | OrionPK quit (Read error: Operation timed out) |
| 06:05:29 | * | Demos quit (Ping timeout: 245 seconds) |
| 06:09:43 | fowl | lanior, error pragma |
| 06:10:09 | fowl | lanior, or static: error("blah") |
| 06:11:11 | lanior | thanks |
| 06:40:58 | * | DAddYE quit (Remote host closed the connection) |
| 06:41:25 | * | DAddYE joined #nimrod |
| 06:46:03 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 06:50:58 | * | DAddYE joined #nimrod |
| 07:10:21 | NimBot | nimrod-code/packages master 619ae29 Billingsly Wetherfordshire [+0 ±1 -0]: Update packages.json |
| 07:34:29 | Skrylar | I find it incredibly suspicious that 5.16 "rounds" to 516 |
| 07:49:02 | * | DAddYE quit (Remote host closed the connection) |
| 07:49:28 | * | DAddYE joined #nimrod |
| 07:54:12 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 08:10:17 | Skrylar | I wonder why new(x, finalizer) requires an existing X when the finalizer applies to the type oO |
| 08:10:53 | Skrylar | oh. it just has a screwball return type |
| 08:33:09 | Skrylar | fowl: i'm a bit concerned as i've noticed destructors are not run after a finalizer |
| 08:34:33 | Skrylar | if you make a destructor, it does run if the item is made on the stack. if made via new, it will not. if made with a finalizer, it will not run at the end of a program unless you put in a spare GCFullCollect |
| 08:35:33 | Skrylar | Which is a minor concern to me because backrefs involve making a weak cyclic reference :/ I'm guessing that if an object has been marked for collection but the finalizer is not yet run, then the memory is still "valid" in a sense the program won't necessarily crash if you call a method on it |
| 08:35:38 | Skrylar | though it might do a lot of stupidity |
| 08:43:27 | * | Kooda joined #nimrod |
| 08:47:30 | * | brson quit (Quit: leaving) |
| 08:49:59 | * | DAddYE joined #nimrod |
| 08:54:37 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 09:19:17 | * | q66 joined #nimrod |
| 09:19:27 | * | q66 quit (Changing host) |
| 09:19:27 | * | q66 joined #nimrod |
| 09:24:22 | Araq | oh not the new(x, finalizer) again |
| 09:24:41 | Skrylar | Araq: not it causing bugs or not people complaining about it? |
| 09:24:45 | Araq | Skrylar: yes, sometimes I provide features that are very useful before they reach perfection, spare me |
| 09:25:16 | Skrylar | Araq: Its okay. I made a test case and a bug report about it. :P |
| 09:25:35 | Araq | as if we don't have a bug report about that already |
| 09:25:51 | Skrylar | at least its productive whining :B |
| 09:26:19 | Araq | comex: the 'stmt list' principle easily extends to 'if' and 'match' |
| 09:26:39 | Araq | you just have to push the "void context information" up the AST |
| 09:27:00 | Araq | for nimrod it's more complex thanks to 'result' |
| 09:27:41 | Araq | there are also other solutions like '{' triggers a void context, '=' triggers a real expression |
| 09:27:53 | Araq | fn foo()-> int = 3 |
| 09:28:02 | Araq | fn foo()-> int { ret 3 } |
| 09:28:14 | Araq | no need for semicolons here |
| 09:28:59 | Araq | it's a trivial language design problem when you made your homework ... |
| 09:31:54 | Araq | Skrylar: you must not invoke GCUnref when you never did GCRef |
| 09:32:23 | Skrylar | Araq: i also did a version with no unrefs, the finalizer doesn't run at all |
| 09:32:31 | Araq | so? |
| 09:32:44 | Skrylar | kinda want the finalizers to run :\ |
| 09:33:17 | Araq | GCFullCollect() might not work because 'x' and 'y' are still on the stack as bit patterns somehow |
| 09:33:30 | Araq | the stack is marked conservatively |
| 09:33:58 | Araq | I guess we really need GCFreeEverything |
| 09:35:00 | Skrylar | what i was trying to test is that if an object has a signal mapped to a slot, it would get a back reference to the signal so that when it was finalized it would drop the connection |
| 09:35:16 | Araq | put 'main' in a loop and see what happens |
| 09:35:35 | Araq | the Gc might still have bugs when it comes to cycles |
| 09:36:18 | Araq | Skrylar: for weak references see the forum how to do them |
| 09:36:34 | Skrylar | is there a search button on that forum yet :) |
| 09:36:51 | Araq | no |
| 09:40:02 | Skrylar | okay, put main in a 1..100 loop and gnuplot'd it |
| 09:40:23 | Skrylar | weirdly it just starts collecting cycles until it hits four, then the rest of the test it obeys |
| 09:40:35 | Skrylar | always leaves one cycle present |
| 09:40:56 | Araq | as I said weird stack location |
| 09:41:03 | Araq | keeps 1 thing alive |
| 09:42:44 | Skrylar | i'll amend my notes for it |
| 09:42:49 | Araq | btw what do you do in the finalizer that needs to be done at program shutdown? |
| 09:43:02 | Skrylar | it doesn't, i was just testing to make sure they ran as expected |
| 09:43:15 | Skrylar | in that particular case the finalizer just removes itself from a list of listeners |
| 09:43:37 | Araq | that's nasty |
| 09:43:51 | Araq | lists of listeners suck too |
| 09:44:00 | Araq | backrefs suck |
| 09:44:13 | Araq | convoluted control flow sucks |
| 09:44:30 | Araq | just say no and use an event queue :P |
| 09:44:33 | Skrylar | the Qt-way does it in an object's destructor, and usually the destructor for a qobject is handled by its parent so it tends to never be seen |
| 09:45:14 | Skrylar | I'm not hugely thrilled by event queues for a few reasons; one of which *might* be solvable with some CTFE magic |
| 09:45:51 | Araq | the callbacky style is essentially not provable correct |
| 09:46:03 | Araq | *cannot be proved to be correct |
| 09:47:24 | Skrylar | what i was considering on the event pump branch of research was using a compile-time incrementer to guarantee each event ever defined to have a unique ID, so there is never a "use BLAH_LAST+14" situation |
| 09:48:06 | Skrylar | I know that wxWidgets has a fairly nice way of defining the event map, at least as far as being able to just tell it "on this do that" |
| 09:48:21 | Araq | btw how does delphi do it? |
| 09:48:34 | Skrylar | list of listeners, no backref cleanup |
| 09:48:55 | Skrylar | the backrefs are optional, Qt just sneaks them in so that a signal can never crash the program |
| 09:49:05 | Skrylar | Delphi "events" are basically the same idea but without safety |
| 09:49:18 | Araq | btw don't take me seriously |
| 09:49:26 | Araq | I'm not telling you what to do |
| 09:49:45 | Skrylar | Qt also tends to treat slots as plain function calls, with a special QEvent::sender() if you really want the parent, while Delphi tends to treat events as "this callback must be like this" |
| 09:50:35 | Araq | (it is however true that when you need to *verify* software many things you learned simply do not work) |
| 09:50:41 | Skrylar | what interests me with the Qt approach is that there are times you can just wire a button press directly in to another control's specific triggers, so there is no "callback just to run this function" situation |
| 09:52:54 | Skrylar | What I was considering was adding a branch so that the first slot goes to a callback pointer and the seq is left uninitialized until its needed, and since signals can be put on the stack it means that until the list is needed it doesn't get alloc'd. |
| 09:53:02 | Skrylar | As for event queues, I have a few ideas worth testing |
| 09:53:19 | Skrylar | It ought to be possible to bury the more disgusting parts with some small macros |
| 09:53:34 | Araq | yeah |
| 09:53:41 | Araq | I need to go, bbl |
| 09:53:43 | Skrylar | be safe |
| 10:09:14 | * | q66 quit (Quit: Leaving) |
| 10:23:51 | * | q66 joined #nimrod |
| 10:42:53 | * | silven quit (Ping timeout: 246 seconds) |
| 10:48:20 | * | io2 joined #nimrod |
| 11:00:01 | NimBot | Araq/Nimrod devel 448cf0e Araq [+0 ±4 -0]: fixes #1010 |
| 11:37:18 | dom96 | 'morning |
| 11:46:18 | * | Trimsty joined #nimrod |
| 11:57:40 | Araq | hi dom96 |
| 11:57:58 | Araq | if you don't mind, special case reIgnored "still ignored" |
| 11:58:37 | Araq | but it's super low priority |
| 12:01:13 | dom96 | good because I would rather work on async instead. |
| 12:04:50 | Araq | issue #1023 is great fun |
| 12:04:58 | Araq | the vm's register allocated screws up |
| 12:05:04 | Araq | *allocator |
| 12:10:10 | * | runvnc quit (Quit: Leaving) |
| 12:59:36 | * | silven joined #nimrod |
| 13:01:20 | BitPuffin | Araq: Currently uploading but in about 340 minutes you'll be able to watch this http://youtu.be/HvC61WMRGQ4 |
| 13:04:30 | * | psquid quit (Quit: work) |
| 13:18:11 | * | Endy joined #nimrod |
| 13:24:49 | * | noam quit (Ping timeout: 240 seconds) |
| 13:39:11 | * | [1]Endy joined #nimrod |
| 13:41:19 | * | Endy quit (Ping timeout: 245 seconds) |
| 13:41:19 | * | [1]Endy is now known as Endy |
| 13:50:30 | * | psquid joined #nimrod |
| 13:55:21 | * | noam joined #nimrod |
| 14:00:17 | * | [1]Endy joined #nimrod |
| 14:01:17 | * | eximius quit (*.net *.split) |
| 14:01:20 | * | comex quit (*.net *.split) |
| 14:01:23 | * | tumak_ quit (*.net *.split) |
| 14:01:24 | * | bstrie quit (*.net *.split) |
| 14:01:26 | * | musicalchair quit (*.net *.split) |
| 14:01:43 | * | tumak joined #nimrod |
| 14:01:55 | * | comex joined #nimrod |
| 14:01:56 | * | bstrie joined #nimrod |
| 14:02:00 | * | musicalchair joined #nimrod |
| 14:03:31 | * | Endy quit (Ping timeout: 245 seconds) |
| 14:03:31 | * | [1]Endy is now known as Endy |
| 14:06:28 | * | eximius joined #nimrod |
| 14:06:46 | dom96 | hi eximius |
| 14:09:55 | * | darkf quit (Quit: Leaving) |
| 14:16:26 | * | BitPuffin quit (Excess Flood) |
| 14:16:42 | * | BitPuffin joined #nimrod |
| 14:18:29 | * | Skrylar quit (Ping timeout: 270 seconds) |
| 14:19:07 | * | Skrylar joined #nimrod |
| 14:31:53 | * | lanior quit (Ping timeout: 245 seconds) |
| 15:06:16 | * | askatasuna joined #nimrod |
| 15:08:33 | * | Demos joined #nimrod |
| 15:23:46 | * | zahary joined #nimrod |
| 15:26:15 | * | awestroke joined #nimrod |
| 15:41:08 | * | q66 quit (Ping timeout: 252 seconds) |
| 15:49:17 | * | q66 joined #nimrod |
| 15:49:29 | * | q66 quit (Changing host) |
| 15:49:29 | * | q66 joined #nimrod |
| 16:19:21 | * | Demos_ joined #nimrod |
| 16:19:42 | * | Demos_ quit (Client Quit) |
| 16:19:57 | * | Demos_ joined #nimrod |
| 16:33:45 | fowl | Skrylar, please write a gc test for slotted objects https://github.com/fowlmouth/signals.nim/blob/master/examples/ex1.nim |
| 17:01:51 | * | askatasuna quit (Ping timeout: 245 seconds) |
| 17:04:11 | * | q66 quit (Ping timeout: 252 seconds) |
| 17:06:32 | * | q66 joined #nimrod |
| 17:24:18 | * | Demos_ quit (Read error: Connection reset by peer) |
| 17:28:40 | comex | Araq: i don't see how it extends to "if" and "match" if it depends on "return", but if blocks which are not used as expressions don't use return |
| 17:29:09 | comex | i guess it doesn't matter since you can tell locally that the result isn't being used |
| 17:29:31 | comex | but... if you don't have a special case for it, you would have a type error if the branches didn't match up, no good |
| 17:30:49 | * | Demos quit (Ping timeout: 240 seconds) |
| 17:34:42 | * | seagoj joined #nimrod |
| 17:43:53 | * | flaviu joined #nimrod |
| 18:14:44 | * | seagoj quit (Ping timeout: 246 seconds) |
| 18:20:19 | * | Demos joined #nimrod |
| 18:29:33 | * | Demos quit (Remote host closed the connection) |
| 18:50:18 | * | Endy quit (Ping timeout: 240 seconds) |
| 18:51:27 | Araq | comex: you propagate the types of the branches and perform a merge; the "merge type" is then the type of the if expression |
| 18:51:46 | Araq | so void|int becomes void |
| 18:52:08 | Araq | of course it's less confusing when you demand explicit 'discard' statements ;-) |
| 18:55:00 | EXetoC | BitPuffin: Is your video supposed to be private? |
| 18:56:20 | fowl | which is better |
| 18:56:23 | fowl | MIT or BSD license |
| 18:56:34 | Araq | MIT because there is only 1 version |
| 18:56:39 | Araq | BSD has 2 or more |
| 18:56:58 | NimBot | nimrod-code/packages master e944150 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds number_files command. |
| 18:56:58 | NimBot | nimrod-code/packages master 06d395c Billingsly Wetherfordshire [+0 ±1 -0]: Merge pull request #51 from gradha/pr_adds_number_files_command... 2 more lines |
| 19:07:35 | dom96 | Araq: I've been wondering whether it's a good idea to put the large TSocket object (which is currently in sockets.nim) into the sockets2 module (which is meant to contain low-level sockets operations) |
| 19:08:03 | dom96 | If I do that then the net module can truly only contain high-level procs. |
| 19:08:46 | Araq | hmm not sure but don't touch the old sockets module |
| 19:08:47 | dom96 | But the fact that some procs in sockets2 will work on the TSocket and some on the TSocketHandle may be weird. |
| 19:08:57 | Araq | yeah |
| 19:09:10 | Araq | sockets2 should only be about the socket handles |
| 19:09:45 | dom96 | ok |
| 19:10:09 | Araq | do we have a better name for that btw? |
| 19:10:17 | Araq | rawsockets perhaps? |
| 19:10:27 | Araq | barebonessockets |
| 19:10:32 | Araq | lowlevelsockets |
| 19:10:45 | Araq | socketsmotherfucker |
| 19:11:17 | dom96 | dunno |
| 19:11:22 | dom96 | socketsll? |
| 19:11:33 | Araq | rawsockets is good I think |
| 19:12:04 | dom96 | ok |
| 19:12:50 | dom96 | In that case I think I will use that convention for the async stuff too |
| 19:13:02 | Araq | yeah good |
| 19:13:05 | dom96 | btw |
| 19:13:22 | dom96 | It would be nice if there was some symbol which is replaced by the current module name. |
| 19:13:46 | dom96 | Otherwise I have to potentially rename a lot of stuff when renaming modules. |
| 19:13:46 | Araq | hmm ok |
| 19:14:00 | Araq | added it to my todo |
| 19:14:06 | dom96 | awesome |
| 19:14:35 | Araq | thisModule? |
| 19:14:43 | fowl | thisModule! |
| 19:14:50 | Araq | thisRoutine? |
| 19:14:54 | Araq | thisLine? |
| 19:15:09 | dom96 | Also, need a different name for asyncio2 I guess |
| 19:15:17 | Araq | meh I'll go with the ascii art __MODULE__ |
| 19:15:56 | Araq | or perhaps ____MODULE____, you can never have enough underscores |
| 19:16:38 | dom96 | Needs to be more noticeable \\***__MODULE__***// |
| 19:16:39 | Araq | system.thisModule # refers to the current module, lol |
| 19:17:02 | Araq | yeah it's likely the most important symbol everywhere |
| 19:17:27 | dom96 | anyway, suggest a better name for asyncio2 please |
| 19:17:33 | Araq | editors shouldn't even display the other text when there is __MODULE__ in the file |
| 19:18:28 | Araq | asyncio2 is really high level, right? |
| 19:18:43 | dom96 | it's as high level as net |
| 19:19:03 | Araq | net_async ? |
| 19:19:17 | dom96 | It's not sockets specific. |
| 19:19:23 | dom96 | oh wait |
| 19:19:26 | dom96 | it is lol |
| 19:19:38 | dom96 | That may be a problem... |
| 19:20:02 | Araq | asyncio2 should be named asyncio2 until we get the API right |
| 19:20:11 | Araq | which we will once enough people use it |
| 19:20:18 | Araq | so for now asyncio2 is fine I guess |
| 19:21:08 | dom96 | Perhaps I should put the global dispatcher thread var in the low-level async module |
| 19:21:19 | dom96 | which is currently called asyncdispatch |
| 19:21:44 | dom96 | Then we can have asyncnet, asyncfile etc |
| 19:21:58 | Araq | yeah why not |
| 19:22:40 | dom96 | Also, should I separate the futures stuff into a separate module? |
| 19:23:00 | Araq | no |
| 19:25:42 | Araq | dom96: feature request for aporia: a history of searched terms |
| 19:25:52 | Araq | scrollable with the UP/DOWN keys |
| 19:26:13 | dom96 | Araq: Create an issue |
| 19:27:42 | BitPuffin | EXetoC: currently yeah |
| 19:27:56 | BitPuffin | or well |
| 19:28:00 | BitPuffin | will make public now |
| 19:28:00 | Araq | BitPuffin upload complete? |
| 19:28:38 | BitPuffin | it's up |
| 19:28:39 | BitPuffin | http://youtu.be/HvC61WMRGQ4 |
| 19:29:48 | dom96 | BitPuffin: shannel |
| 19:29:54 | dom96 | :P |
| 19:29:55 | BitPuffin | dom96: gem |
| 19:30:31 | dom96 | You should create like video tutorials teaching people Nimrod. |
| 19:30:51 | BitPuffin | dom96: it'sa planned probably |
| 19:33:02 | dom96 | hrm, I should play that game |
| 19:33:07 | * | BitPuffin quit (Remote host closed the connection) |
| 19:33:19 | * | nil42 joined #nimrod |
| 19:33:26 | * | BitPuffin joined #nimrod |
| 19:33:29 | dom96 | hi nil42 |
| 19:33:29 | Araq | hi nil42 welcome |
| 19:33:58 | nil42 | Hello! I've just started experimenting with Nimrod. |
| 19:34:12 | EXetoC | good! |
| 19:35:19 | BitPuffin | dom96: you should |
| 19:38:09 | Araq | zahary: pong if you want to know the cause for #1023. pretty interesting bug |
| 19:55:12 | * | nil42 left #nimrod (#nimrod) |
| 20:07:31 | EXetoC | has anyone noticed any OpenGL-related breakages? I ran my app for the first time in a month or two, and I have no idea why the text isn't rendered all of a sudden. it's just a black rectangle |
| 20:08:56 | Araq | EXetoC: yeah a recent pull request changed GlHandle's type or something |
| 20:13:54 | fowl | EXetoC, ran it, or recompiled it |
| 20:19:18 | NimBot | Araq/Nimrod devel 7b26f16 Araq [+1 ±2 -0]: fixes #1023 |
| 20:19:32 | Araq | I objected but the guy said the opengl changes are fine |
| 20:22:54 | fowl | Araq, it does look like all those funcs should take glUInt |
| 20:23:41 | Araq | fowl: since we broke code already, please fix it |
| 20:30:15 | EXetoC | Araq: that shouldn't be the issue |
| 20:30:18 | EXetoC | fowl: recompiled |
| 20:32:16 | EXetoC | I'm using a beta driver now so that might be the culprit. Not that I'm doing anything fancy |
| 20:39:34 | fowl | Araq, not sure how to fix it, it should be replaced with gluint |
| 20:48:49 | * | BitPuffin quit (Read error: Connection reset by peer) |
| 20:49:27 | * | BitPuffin joined #nimrod |
| 20:49:36 | fowl | EXetoC, do you use shaders? |
| 20:50:58 | Araq | BitPuffin: gah that's nasty do a speed run |
| 20:53:27 | EXetoC | fowl: yeah I'm using GL3 |
| 20:55:37 | BitPuffin | Araq: but I haven't played it before |
| 20:55:41 | BitPuffin | Araq: and I'm scared :'( |
| 20:55:46 | Araq | lol |
| 20:56:10 | BitPuffin | I did cut in one place though |
| 20:56:20 | BitPuffin | when I was just sitting around waiting for the alarm to pass |
| 20:56:21 | Araq | BitPuffin: which character class do you play? |
| 20:56:55 | fowl | EXetoC, do you check glGetError |
| 20:57:45 | BitPuffin | Araq: I think I accidentally picked marine when I wanted to play the one that does hacking |
| 20:57:59 | BitPuffin | just because I thought the paths corresponded |
| 20:58:02 | Araq | marine is easiest |
| 20:58:05 | Araq | hacker is moderate |
| 20:58:10 | Araq | psi guy is hardest |
| 20:58:12 | BitPuffin | so middle would give me the hacking |
| 20:58:24 | BitPuffin | like in the tutorial |
| 20:58:26 | BitPuffin | but nop |
| 21:00:14 | EXetoC | fowl: no but I will |
| 21:00:47 | EXetoC | I need to import unsigned just to be able to compare GLenum values. oh well |
| 21:01:33 | Araq | EXetoC: put the stuff from unsigned.nim to system.nim and make a pull request |
| 21:01:52 | Araq | unsigned.nim should remain as empty module so almost no code breaks |
| 21:02:17 | BitPuffin | Araq: I think it might work out though |
| 21:02:18 | Araq | enough people complained about this so lets change it |
| 21:02:34 | BitPuffin | Araq: with marine I get basic fighting stats and from there I can build up my hacking |
| 21:02:35 | Araq | BitPuffin: what do you mean? |
| 21:02:48 | Araq | yeah sure |
| 21:02:58 | Araq | you can also become a psi guy later |
| 21:03:04 | Araq | it doesn't matter that much |
| 21:03:21 | Araq | what's the difficulity you chose? |
| 21:06:34 | BitPuffin | Araq: started with impossible and then changed to hard when I realized it was impossible |
| 21:06:49 | BitPuffin | they fucking one hit you with impossible :( |
| 21:07:13 | Araq | hmm I made it up to level 2 or 3 with impossible |
| 21:07:22 | Araq | and then lost interest |
| 21:08:11 | Araq | speed runs usually are done with impossible |
| 21:08:29 | Araq | so it's certainly possible but you need to know all the tricks and bugs |
| 21:10:51 | * | tmaynard joined #nimrod |
| 21:11:12 | Araq | hi tmaynard welcome |
| 21:11:53 | BitPuffin | yeah haha |
| 21:11:57 | BitPuffin | but I'm not gonna speed run |
| 21:12:00 | BitPuffin | it's about the immersion |
| 21:12:11 | tmaynard | Greetings. |
| 21:12:24 | dom96 | BitPuffin: You should code an AI to beat System Shock 2 instead |
| 21:12:31 | dom96 | Then do a commentary on what the AI does. |
| 21:13:43 | BitPuffin | lol |
| 21:13:51 | EXetoC | another fun weekend project |
| 21:14:03 | BitPuffin | that's what god is doing |
| 21:14:04 | dom96 | "It appears my AI is starting at this rather boring wall" |
| 21:14:05 | BitPuffin | with me |
| 21:14:09 | dom96 | *staring |
| 21:14:13 | BitPuffin | I'm just software that god wrote |
| 21:14:15 | BitPuffin | lol |
| 21:15:27 | Araq | seriously ... bug #1011 is embarrassing |
| 21:15:48 | Araq | and in the code responsible for it it says "XXX implement this" |
| 21:16:18 | BitPuffin | lol |
| 21:16:40 | Araq | which means it's been like that since forever and hardly anybody complained about it |
| 21:16:47 | EXetoC | Araq: I don't know why I complained this time of all times. |
| 21:17:19 | EXetoC | didn't someone suggest moving the types to unsigned also? is that feasible? |
| 21:17:49 | Araq | EXetoC: no that breaks too much code for no benefit |
| 21:17:54 | * | Trimsty quit (Quit: Trimsty) |
| 21:21:46 | dom96 | Araq: Perhaps we should get a test which fails as long as there is an "XXX" or "TODO" in the compiler's source? :P |
| 21:21:58 | BitPuffin | hahaha |
| 21:22:00 | BitPuffin | yeah |
| 21:22:02 | BitPuffin | seriously do it |
| 21:22:22 | Araq | dom96: we're already not releasing anything anymore |
| 21:22:34 | Araq | :-/ |
| 21:22:35 | EXetoC | it'll only delay 0.9.4 by a month or so. no problem |
| 21:24:29 | flaviu | There's a single, lone TODO in c2nim/cparse.nim. Does anyone want to change it to a XXX? :P |
| 21:24:56 | dom96 | nah, every XXX should be changed to TODO instead. |
| 21:25:25 | * | tmaynard quit (Quit: Page closed) |
| 21:25:34 | Araq | no, XXX is the standard |
| 21:26:17 | dom96 | Not in my source code :P |
| 21:26:18 | BitPuffin | XXX is like WARNING THIS NEEDS TO BE FIXED |
| 21:26:22 | EXetoC | I've mostly seen TODO in the wild |
| 21:26:27 | BitPuffin | whereas TODO is more like, this could be done cleaner |
| 21:26:36 | BitPuffin | or would be nicer if we added this |
| 21:26:41 | BitPuffin | in my eyes |
| 21:26:51 | Araq | I use XXX because it reminds me of porn |
| 21:27:14 | dom96 | Araq secretely dreams of being a porn producer. |
| 21:27:59 | BitPuffin | -.- |
| 21:29:02 | flaviu | Is there an issue less important than this to bikeshed over? :P |
| 21:30:02 | dom96 | Oh plenty. For example I am deeply concerned about the lack of ASCII porn in Nimrod's source code. |
| 21:30:10 | dom96 | The compiler should rely on it for its happiness. |
| 21:30:11 | BitPuffin | Araq: was it **typ that was an array or just * |
| 21:30:28 | Araq | hmm fixing this bug might break code |
| 21:30:34 | * | BitPuffin is asking Araq because he is the only one who can code here |
| 21:30:42 | * | OrionPK joined #nimrod |
| 21:30:52 | Araq | BitPuffin: * means pointer. but it is often used for arrays |
| 21:31:03 | dom96 | Araq: Check how many tests it breaks then. |
| 21:31:04 | BitPuffin | Araq: aight, so for a [][] I should do ** ? |
| 21:31:07 | fowl | lol |
| 21:31:24 | Araq | BitPuffin: yes |
| 21:31:28 | BitPuffin | oki |
| 21:31:30 | BitPuffin | tyvm |
| 21:31:42 | BitPuffin | then it is how I thought it was :D |
| 21:33:21 | Araq | dom96: want me to use a different branch for the fix? |
| 21:34:23 | dom96 | Araq: Sure, if you want. |
| 21:34:47 | * | dom96 wonders why Varriount's builder's are down |
| 21:35:04 | Varriount | Hm? they are? |
| 21:35:11 | dom96 | yes |
| 21:35:17 | Varriount | Error: unhandled exception: The system cannot find the file specified. |
| 21:35:29 | Varriount | That's the error that's in the builder console. |
| 21:35:50 | dom96 | Could you fix it please? |
| 21:40:10 | dom96 | Araq: hrm. This is weird. Compiling oids fails with --threads:on |
| 21:40:20 | dom96 | stdlib_oids.o:stdlib_oids.c:(.text+0x853): undefined reference to `__atomic_add_fetch' |
| 21:40:34 | Araq | are you on windows? |
| 21:40:36 | dom96 | ye |
| 21:40:38 | dom96 | s |
| 21:40:45 | dom96 | known bug? |
| 21:41:05 | Araq | it's no bug |
| 21:41:25 | Araq | we need to update gcc for windows |
| 21:41:42 | Araq | so that GCC knows about atomic ops |
| 21:41:54 | dom96 | I see |
| 21:42:33 | EXetoC | Araq: I guess we'll just document the problems associated with unsigned types then |
| 21:43:18 | dom96 | I know I asked this before, but can we allow ifs in object variants? |
| 21:43:43 | Araq | you mean as a shortcut for 'case'? |
| 21:43:46 | dom96 | yes |
| 21:44:30 | Araq | we can but I won't before 1.0 is out |
| 21:44:47 | dom96 | ok |
| 21:44:55 | dom96 | I'll create an issue for it anyway |
| 21:45:05 | dom96 | Maybe i'll implement it for fun. |
| 21:45:09 | Araq | mark it as feature request |
| 21:45:14 | dom96 | indeed, will do. |
| 21:45:28 | EXetoC | fowl: Now to figure out what's triggering "invalid operation" |
| 21:45:46 | EXetoC | we should turn these constants into enumerators |
| 21:46:46 | Araq | EXetoC: unfortunately that's always lots of work as C never was designed with static typing in mind |
| 21:48:33 | EXetoC | shouldn't be too hard in this case, but I'll think about it some more |
| 21:49:10 | EXetoC | hopefully I can get my error checking macro to work now. Time to try my luck with useFFI again |
| 21:49:39 | Araq | useFFI is still broken |
| 21:49:47 | EXetoC | d'oh |
| 21:50:17 | Araq | and I'm not sure I want to provide it anymore |
| 21:51:23 | Araq | it scares me |
| 21:52:30 | Araq | it also creates a nimrod dialect ("oh you need to bootstrap with -useFFI to be able to compile this piece of code") |
| 21:53:19 | dom96 | But then how will you provide an FFI for the VM? |
| 21:53:21 | EXetoC | I thought it would be unconditionally included at some point |
| 21:53:44 | EXetoC | anyway, the symbol is not actually invoked in the macro |
| 21:55:54 | dom96 | ooh, this is really cool: http://www.wei-wang.com/ExplainGitWithD3 |
| 21:56:18 | EXetoC | so it shouldn't be needed |
| 21:59:20 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 21:59:46 | NimBot | Araq/Nimrod devel f3ecc78 Araq [+0 ±3 -0]: fixes #1006 |
| 22:00:18 | EXetoC | I'm getting some other error when it's a template rather than a macro |
| 22:01:33 | EXetoC | "let x = call" doesn't work if 'call' (an expr) evaluates to 'void'. is it possible to deal with that currently? |
| 22:01:43 | fowl | Araq, there is a lot of cool stuff that will impossible without ffi |
| 22:02:17 | NimBot | Araq/Nimrod devel 57c2a8d Araq [+0 ±1 -0]: fixes wrong commit |
| 22:02:27 | EXetoC | probably in some way that isn't straightforward |
| 22:02:56 | Araq | fowl: like? |
| 22:03:45 | EXetoC | with some macro magic perhaps, but then I'll hit that (seemingly unrelated) FFI error again |
| 22:04:11 | Araq | I think the stuff in os.nim and math.nim should get special treatment and that's about it; useFFI introduces simply too many problems for now |
| 22:05:56 | dom96 | If getting rid of useFFI partially eases the pain then do it. But hopefully you will bring it back at some point? |
| 22:07:14 | * | BitPuffin joined #nimrod |
| 22:07:17 | Araq | dunno, I still think in the long run LLVM might finally give us runC_code(char* code) and we can use the C backend |
| 22:07:45 | Araq | BitPuffin: I'm closing but #1020 ok? |
| 22:08:01 | BitPuffin | Araq: which one was it? |
| 22:08:14 | Araq | unicode comma |
| 22:08:14 | fowl | Error: cannot 'importc' variable at compile time |
| 22:08:15 | dom96 | Araq: Is that on their todo list? |
| 22:08:49 | Araq | dom96: last time I asked them they said it would be hard and quite some work |
| 22:09:01 | BitPuffin | Araq: sure |
| 22:09:02 | Araq | but in the meantime their got their own linker and stuff |
| 22:09:19 | BitPuffin | I even had some warnings today about unicode spaces lol |
| 22:09:21 | BitPuffin | in C |
| 22:11:47 | Araq | maybe you should use a sane OS or something |
| 22:12:09 | Araq | if only there was an OS that takes the "operating" part in OS seriously |
| 22:13:12 | Araq | so now I know the name of the OS I'll eventually create: WOS -- the "working operating system" |
| 22:15:34 | fowl | Araq, i think the order push'd pragmas apply to procedures is wrong. pragmas that are on the proc should come first |
| 22:16:54 | Araq | "come first" as in "Processed last so they can overwrite stuff"? |
| 22:17:18 | fowl | yea |
| 22:18:13 | Araq | the general "push" has lots of problems |
| 22:18:19 | Araq | why did we introduce it? |
| 22:18:44 | fowl | it makes wrappers less noisy |
| 22:19:06 | Araq | the original push only supported a limited number of features and told you when it doesn't support the feature |
| 22:19:25 | Araq | the new push is unreliable |
| 22:20:01 | Araq | .push raises: [] doesn't work either |
| 22:20:47 | Araq | fowl: that's only a problem when you don't use c2nim though |
| 22:21:35 | dom96 | I think we should have {.add dynlib: lib.} and {.del dynlib.} instead. |
| 22:21:47 | dom96 | Instead of this push & pop business. |
| 22:21:59 | Araq | that's hardly any better, dom96 |
| 22:22:04 | dom96 | or perhaps 'set' instead of 'add' |
| 22:22:16 | Araq | {.pragma mypragma, dynlib: lib, cdecl, etc.} |
| 22:22:22 | Araq | is better though |
| 22:22:33 | Araq | and doesn't have these problems |
| 22:22:40 | dom96 | You still have to add it to each proc though... |
| 22:23:00 | dom96 | How about we add some matching mechanism? |
| 22:23:06 | Araq | macrovoodoo: |
| 22:23:10 | Araq | proc foo() |
| 22:23:13 | fowl | Araq, what comes out of c2nim needs to be cleaned up anyways, the wrapper looks better when its proc x(); proc y(); .. |
| 22:23:13 | Araq | proc bar() |
| 22:23:31 | dom96 | {.match proc, dynlib: lib, cdecl, ...} |
| 22:23:48 | dom96 | {.match object, ...} |
| 22:24:11 | Araq | dom96: that's much better than 'push' for the user but as error prone to implement |
| 22:25:05 | Araq | instead of 'match', 'annotate' reads nicer I think |
| 22:25:12 | Araq | {.annotate proc, dynlib...} |
| 22:25:41 | dom96 | yeah |
| 22:25:49 | dom96 | Why is it error prone? |
| 22:26:21 | fowl | push is fine as it is it just needs one fix that i can see |
| 22:27:01 | Araq | fowl: 'push' should only allow for a certain list of pragmas |
| 22:27:09 | fowl | proc foo (f: proc(){.cdecl.}) it shouldn't apply anything to f, or at least not things that dont make sense (dynlib/header/importc) |
| 22:27:35 | Araq | well that's simply a bug |
| 22:27:46 | Araq | 'f' is no proc so 'push' shouldn't affect it |
| 22:27:52 | BitPuffin | Araq: :P |
| 22:27:59 | Araq | 'f' has a proc type but that's different |
| 22:31:53 | NimBot | Araq/Nimrod devel 3c0f8ec Dominik Picheta [+0 ±1 -0]: Asyncio2 doc improvements. Changed recvLine's behaviour.... 5 more lines |
| 22:31:53 | NimBot | Araq/Nimrod devel ccbd4c9 Dominik Picheta [+0 ±1 -0]: Clean up IP address code in net module. |
| 22:31:53 | NimBot | Araq/Nimrod devel efe3104 Dominik Picheta [+0 ±4 -0]: Copied most blocking socket operations to the net module. |
| 22:31:53 | NimBot | Araq/Nimrod devel 7f7e917 Dominik Picheta [+3 ±1 -2]: Many renames. Created high level asyncnet module. |
| 22:32:43 | dom96 | Araq: https://github.com/Araq/Nimrod/blob/devel/lib/pure/asyncnet.nim |
| 22:33:00 | dom96 | Happy with that API? |
| 22:33:33 | Araq | dom96: it's error prone because if I forget things, things break silently, like .push raises: [] |
| 22:33:57 | Araq | which is not supported but the compiler doesn't complain and so people think their code is exception safe |
| 22:34:17 | dom96 | Isn't that trivial to fix? |
| 22:34:38 | dom96 | Just check whether the pragma is supported and refuse to compile if it's not. |
| 22:34:39 | Araq | no |
| 22:34:45 | Araq | oh yeah |
| 22:35:01 | Araq | when defined(ssl): # no! let's use useSSL instead |
| 22:35:27 | EXetoC | when compiles(echo(call)) |
| 22:35:29 | EXetoC | that'll do :> |
| 22:35:35 | dom96 | no, lets create a way to distinguish between defined vars and things defined on the cmd line. |
| 22:36:06 | dom96 | I mean, yeah. I can change it. |
| 22:36:13 | dom96 | But we should do that anyway. |
| 22:36:30 | Araq | yeah |
| 22:36:40 | Araq | but that breaks code in subtle ways |
| 22:36:47 | EXetoC | some timing. that has nothing to do with what you said |
| 22:37:03 | Araq | proc AsyncSocket vs proc newSocket ? |
| 22:37:16 | dom96 | newSocket isn't exported |
| 22:37:23 | dom96 | how does it break code? |
| 22:37:32 | dom96 | EXetoC: huh? |
| 22:37:33 | Araq | hmm well it should be newAsyncSocket |
| 22:37:43 | EXetoC | dom96: nvm |
| 22:37:45 | Araq | or at least asyncSocket with a small a |
| 22:38:02 | EXetoC | "glTexStorage2D(GLtexture2D, 32, fmt.GLenum, size.w.cint, size.h.cint)" ok so I guess that broke at some point |
| 22:38:02 | dom96 | ahh right |
| 22:38:10 | dom96 | Well, it's 'socket' in net |
| 22:38:14 | dom96 | and in sockets |
| 22:38:38 | dom96 | Perhaps I should get rid of this convention. |
| 22:38:54 | dom96 | or should i? |
| 22:40:31 | Araq | if we make TSocket Socket and keep --cs:none then we'll get into trouble |
| 22:41:14 | Araq | it should be 'socket' because of posix but newAsyncSocket |
| 22:41:21 | Araq | I think |
| 22:41:24 | Araq | ## If the socket is disconnected in the middle of a line (before ``\r\L`` |
| 22:41:26 | Araq | ## is read) then line will be set to ``""``. |
| 22:41:27 | Araq | ## The partial line **will be lost**. |
| 22:41:33 | Araq | is that really good design? |
| 22:41:42 | dom96 | I'm glad you noticed that. |
| 22:41:47 | dom96 | I thought about this for a while. |
| 22:42:00 | Araq | if we redesign the API, shouldn't we always add \C\L and call it a day? |
| 22:42:24 | dom96 | That scenario is pretty rare I think. |
| 22:42:31 | Araq | though it sucks to have to do chop(line) |
| 22:42:33 | dom96 | And what can you do with partial data anyway? |
| 22:42:42 | dom96 | It breaks your protocol. |
| 22:43:00 | Araq | that depends on the protocol though |
| 22:43:09 | Araq | partial data can be useful |
| 22:43:23 | dom96 | Can you give me an example of a protocol where it is useful? |
| 22:43:54 | Araq | logging via http |
| 22:44:00 | dom96 | The current recvLine in sockets.nim simply gives the partial line. |
| 22:44:13 | Araq | partial error message in the log is still useful |
| 22:44:17 | dom96 | And no code broke yet because of that AFAIK |
| 22:44:38 | dom96 | Only the headers are read line by line in HTTP |
| 22:44:52 | dom96 | And if you get half a header what are you going to do with it? |
| 22:45:11 | Araq | make the example "logging by *some* protocol" |
| 22:45:18 | dom96 | hah |
| 22:45:40 | dom96 | You always tell me to ignore some scenarios which may exist. |
| 22:46:08 | dom96 | So now you better give me a concrete example instead of "some protocol" |
| 22:46:19 | dom96 | This depends on how popular these protocols are. |
| 22:46:33 | dom96 | You still have plenty of options open to you. |
| 22:46:59 | Araq | I don't see 'recvLine' being only useful for common protocols |
| 22:47:00 | dom96 | And if such protocols are rare then we should keep that behaviour. |
| 22:47:18 | Araq | recvLine is protocol agnostic |
| 22:47:36 | Araq | so it shouldn's assume "partial lines who cares about these" |
| 22:48:03 | dom96 | Well if you want partial lines then we need to have \c\L at the end. |
| 22:48:12 | dom96 | Otherwise there is no way to tell. |
| 22:48:16 | dom96 | But this will lead to bugs. |
| 22:48:17 | * | brson joined #nimrod |
| 22:48:26 | dom96 | And I would prefer to have a return enum. |
| 22:48:30 | dom96 | Which will force people to check. |
| 22:48:57 | dom96 | In that case we can have two versions then. |
| 22:49:23 | dom96 | Although they can't have the same name... |
| 22:49:28 | dom96 | bleh |
| 22:49:47 | fowl | is udp possible with new async stuff? |
| 22:50:00 | dom96 | Not yet. |
| 22:51:08 | Araq | why don't partial lines raise an exception? |
| 22:51:59 | dom96 | That's a solution I didn't think of. |
| 22:52:04 | dom96 | I can do that. |
| 22:52:24 | dom96 | And I can create a custom exception which includes the partial line. |
| 22:53:07 | flaviu | Hmm, there is an ICE when the compiled program run fails |
| 22:53:53 | zahary | dom96: do you plan to add support for timers in the asyncdispatcher module soon? they are the equivalent of the sleep call in the async world |
| 22:54:05 | flaviu | You aren't supposed to get a stack trace for something like that right? |
| 22:54:15 | zahary | the file system monitor could be hooked to the dispatcher as well |
| 22:54:35 | dom96 | zahary: Yes, I will add all that later. |
| 22:54:46 | dom96 | Sockets are my priority. |
| 22:54:53 | zahary | cool |
| 22:58:25 | Araq | can somebody on a mac please fix: https://github.com/Araq/Nimrod/issues/965 |
| 23:00:27 | NimBot | Araq/Nimrod devel 8dbd5d0 Araq [+0 ±1 -0]: fixes #994 |
| 23:00:27 | NimBot | Araq/Nimrod devel eaf4ff7 Araq [+3 ±2 -2]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
| 23:00:41 | dom96 | zahary: What do you think of it currently? Is this what you had in mind? |
| 23:00:49 | EXetoC | "compiles(echo(call))" is this the best we got right now for checking whether or not something evaluates to 'void'? |
| 23:01:31 | Araq | when call() is void ? |
| 23:01:44 | Araq | not sure if that works though |
| 23:03:31 | EXetoC | Araq: no it doesn't. by 'something' I meant 'expr' |
| 23:03:43 | EXetoC | well, whatever works is fine |
| 23:05:44 | Araq | fowl: btw what do you think of 'existsAsFile' and 'existsAsDir'? uglier than 'fileExists'? |
| 23:07:15 | zahary | sure dom96, look great. where is dispatcher.poll defined btw? |
| 23:07:31 | dom96 | asyncdispatch |
| 23:07:45 | zahary | EXetoC: foo() is void soulds like something that I should implement :) |
| 23:08:25 | * | xenagi joined #nimrod |
| 23:11:15 | EXetoC | zahary: well, you'd just do 'foo' in this case |
| 23:11:32 | EXetoC | </nitpick> |
| 23:12:36 | fowl | Araq, way ugly |
| 23:18:11 | * | darkf joined #nimrod |
| 23:39:58 | NimBot | nimrod-code/babel master c451d20 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds support for git submodules during clone. |
| 23:39:58 | NimBot | nimrod-code/babel master 948cf91 Dominik Picheta [+0 ±1 -0]: Merge pull request #34 from gradha/pr_support_git_submodules... 2 more lines |