| 00:00:03 | Araq | ldlework: ok, but again, what is really the problem in practice? |
| 00:00:16 | Araq | what evil symbols does "import pegs" give you? |
| 00:00:18 | flaviu | ldlework: I don't like the lack of qualifiers too much either, but it's necessary for UFCS |
| 00:00:24 | ldlework | Araq: dude |
| 00:00:33 | ldlework | You can already imagine the potential problem |
| 00:00:44 | ldlework | We don't need to pretend you're not capable of imagining naming conflicts |
| 00:00:54 | ldlework | To make me do work to explain something obvious to anyone |
| 00:01:03 | Demos | so the thing is that naming conflicts are OK |
| 00:01:20 | Araq | oh really? overloading disambiguation deals with most of them anyway |
| 00:01:22 | ldlework | Yeah I love naming something else because I alreay import that name even though I don't want it |
| 00:01:24 | Demos | if you don't use the conflicting symbol then everything works, if you do the compiler will force you to qualify |
| 00:01:45 | Araq | ldlework: in contrast to what you may think |
| 00:02:03 | Araq | I used Dephi's module system and Python's and Ada's and C#'s |
| 00:02:15 | Araq | and a couple of worse module systems |
| 00:02:24 | ldlework | I don't think Python's import system is a model, at all |
| 00:02:32 | * | kmcguire quit (Ping timeout: 244 seconds) |
| 00:02:36 | Araq | and I copied Delphi's and improved upon it because it works best in practice |
| 00:02:36 | ldlework | I have a practical problem, that isn't a practical problem for you |
| 00:02:46 | ldlework | It isn't "it isn't like Python" either |
| 00:03:17 | ldlework | I just want my import system to be useful, to help me figure things out, to be explicit, to be a reverse interfae for the module |
| 00:03:35 | ldlework | The import system doesn't seem helpful at all |
| 00:03:44 | ldlework | It seems "convient for simple cases" |
| 00:03:59 | Araq | I just want my mouse cursor to tell me where a symbol comes from when I really need to know |
| 00:04:10 | Araq | and if that doesn't work, I go and fix my broken tooling |
| 00:04:38 | ldlework | Yes, design prefaced on the idea that tooling serves deficits is always what they teach in design school |
| 00:04:57 | ldlework | "Ah that's okay Johnny, the tooling will make up for it." |
| 00:05:03 | ldlework | "Ah phew, thanks prof!" |
| 00:05:16 | Demos | the number of times I have thought "wow where does this symbol come from" is not a question I tend to ask unless I want to actually see that place, in which case I kinda need tools anyways |
| 00:05:23 | Araq | tooling is essential anyway, whether you admit it or not |
| 00:05:30 | Araq | nobody programs in Notepad |
| 00:05:47 | ldlework | Demos: Sorry I forgot to have the same values and experience as you |
| 00:05:56 | Araq | just because Eclipse is broken beyond repair doesn't mean that we should get rid of tools |
| 00:05:58 | Demos | People do program without real IDE assists in languages that are not java or c# |
| 00:06:10 | Demos | esp in c and c++ |
| 00:06:24 | ldlework | Anyway |
| 00:06:31 | Araq | your Vim with 50+ plugins is an IDE already |
| 00:06:32 | ldlework | I will continue to explicitly import everything |
| 00:06:45 | Araq | you don't admit it, but it is what it is |
| 00:06:46 | ldlework | Because its clearly the Right Thing to do |
| 00:06:49 | Demos | ldlework, imo required qualifications are noise in like 85% of cases, so I prefer to omit them |
| 00:06:59 | Araq | same for Emacs |
| 00:06:59 | Demos | and you can qualify stuff in nim if you like |
| 00:07:21 | ldlework | Araq: using a programmable editor doesn't magically snap into existence support for your favorite language |
| 00:07:25 | Araq | anybody else uses Visual Studio or Lazarus or <insert IDE here> anyway |
| 00:07:32 | Demos | Araq, but go-to-definition works pretty rarely (ctags) and completion works almost never |
| 00:07:52 | Araq | ldlework: that's why we try to provide 'idetools' |
| 00:08:03 | Araq | with a command line interface for every editor to interface to |
| 00:08:12 | Araq | granted, it doesn't work good enough for now |
| 00:08:31 | Araq | but it will be and optimizing for Notepad is simply downright broken language design |
| 00:08:44 | Araq | just look at Rust with its obsession to mark macros with ! |
| 00:09:04 | Araq | that's designing for the 70ies, right here |
| 00:09:11 | Demos | more importantly I want to see what the code does when I read it, not where it comes from |
| 00:09:21 | ldlework | Demos: that is just a trite thing to say |
| 00:09:28 | ldlework | the code I want to know what it does, it consists of other code |
| 00:09:35 | ldlework | other code I might not be familiar |
| 00:09:39 | ldlework | voila, you're going somewhere else |
| 00:09:54 | ldlework | Let's stop trying to make really bad arguments for implicit over explicit |
| 00:10:03 | Araq | no, you don't want this for simple reaon that you don't want *full qualification* in Java either |
| 00:10:04 | Demos | right, and sometimes I care about that code, but god knows that I won't read all of it, or even most, without some kind of go-to-definition tool |
| 00:10:33 | Araq | nobody wants full qualification anywhere, it's absurd |
| 00:10:35 | ldlework | I don't want to qualify things in the code |
| 00:10:42 | ldlework | I want to qualify where things come from |
| 00:11:00 | ldlework | I don't want to write mod.foo at all |
| 00:11:26 | ldlework | Anyway, nim supports "from foo import bar" so its fine |
| 00:11:36 | ldlework | Its just annoying that it doesn't import methods on that thing is all |
| 00:11:39 | Araq | that view is literally just a CTRL+E away really |
| 00:12:01 | Araq | the compiler can render the AST for you with full qualifications everywhere |
| 00:12:09 | ldlework | But it makes sense since methods really have nothing to do with the type other than taking it as the first param |
| 00:12:17 | ldlework | so I see why Nim makes no effort to do such a thing |
| 00:15:33 | Araq | IMO 'import' perfectly fits Nim's philosophy |
| 00:16:00 | Araq | which is: be optimistic, pessimism only leads to Java/Go |
| 00:16:23 | ldlework | meh |
| 00:16:54 | Araq | you can't design a language with pessimism |
| 00:17:11 | Araq | got an "if"? omg, somebody will nest it 100 levels deep |
| 00:17:25 | Araq | so let's restrict it to 3 levels |
| 00:17:37 | Demos | does go do that? |
| 00:17:43 | Araq | programmers are helped by arbitrary restrictions |
| 00:18:02 | Araq | Demos: no, but it should |
| 00:18:21 | flaviu | Araq: Please no. |
| 00:19:21 | Araq | "yeah, I will import everything, types disambiguate and if not, I can always ask the programmer for qualification" |
| 00:19:36 | Araq | works perfectly fine IME |
| 00:20:02 | ldlework | except you could just support, import, from import *, and from import name; and still have exactly the same freedom |
| 00:20:29 | ldlework | Its just not compelling of an argument when other better equivalences are true for the same predicate |
| 00:20:29 | Araq | not really. |
| 00:20:37 | ldlework | yeah really |
| 00:20:41 | ldlework | its a superset of your functionality |
| 00:21:03 | Araq | oh really? from foo import `+`, `mod`, etc |
| 00:21:19 | ldlework | I don't get your implied point |
| 00:21:30 | Araq | 'from' doesn't work that well for Nim |
| 00:21:37 | ldlework | why? |
| 00:22:32 | ldlework | I hoped you would say "doesn't really work that well" |
| 00:22:38 | ldlework | and I would say "really, why?" |
| 00:22:47 | flaviu | ldlework: Because you don't want to do "1 foo.`+` 3" |
| 00:22:48 | ldlework | and we would keep up a subtle overuse of really going for as long as possible |
| 00:22:57 | Araq | because it's tedious for user defined operators |
| 00:23:14 | Araq | ok, so special case them, I hear you saying |
| 00:23:36 | Araq | but it's not as simple, operators are nothing special in Nim |
| 00:23:37 | ldlework | I was going to say, for someone who wants the explicit import I really don't think they are going to mind some backtics |
| 00:23:51 | ldlework | And it still supports your current default behavior |
| 00:23:56 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:24:05 | ldlework | so who cares what people tedium's for people who asked for something you wont use anyway? |
| 00:24:15 | Araq | I cannot follow |
| 00:24:22 | ldlework | yeah my grammar is breaking down |
| 00:24:28 | Araq | you're free to enslave yourself by using 'from' |
| 00:24:38 | Araq | but don't suggest it should be the default |
| 00:24:38 | ldlework | thanks :P |
| 00:24:44 | ldlework | Oh it shouldn't be the default |
| 00:25:00 | ldlework | though I think that "import foo" should just import foo.. |
| 00:25:17 | Araq | from foo import nil # does exacly that |
| 00:25:18 | ldlework | and "from foo import *" or something like it should "import everything, YOLO" |
| 00:25:26 | ldlework | Araq: oh cool |
| 00:25:31 | Araq | though people want a nicer syntax for that feature |
| 00:25:44 | ldlework | refer foo |
| 00:25:50 | ldlework | nah too close to ref |
| 00:26:02 | ldlework | "just foo please" |
| 00:27:14 | Araq | your optimizing your code's readability for people with broken tools |
| 00:27:40 | ldlework | you're |
| 00:27:44 | Araq | and yes, I am painfully aware these arguments would hold more water if Nim's tooling weren't as broken as it currently is |
| 00:27:46 | ldlework | you need more tooling for your irc |
| 00:27:51 | * | ldlework sticks out tongue |
| 00:27:55 | Araq | yup |
| 00:28:01 | ldlework | Anyway |
| 00:28:09 | ldlework | I wont complain about the imports anymore, its fine |
| 00:28:25 | ldlework | and not as it "FORGET IT IS FINE" |
| 00:28:39 | ldlework | and "no really, its fine" |
| 00:29:40 | ldlework | that is, if you merge, https://github.com/Araq/Nimrod/pull/1702 |
| 00:30:01 | NimBot | Araq/Nimrod devel c2b36a0 Dustin Lacewell [+0 ±1 -0]: Adds some flexibility to the lib name of SDL_ttf to allow for newer distributions |
| 00:30:01 | NimBot | Araq/Nimrod devel 51d2096 Dustin Lacewell [+0 ±2 -0]: Update the pattern to prefer the old version |
| 00:30:01 | NimBot | Araq/Nimrod devel 04820ca Andreas Rumpf [+0 ±2 -0]: Merge pull request #1702 from dustinlacewell/sdl_ttf_linker_update... 2 more lines |
| 00:30:16 | ldlework | woot |
| 00:30:48 | EXetoC | and it shall be done |
| 00:32:03 | ldlework | looks like a whitespace change to sockets.nim got added too |
| 00:32:16 | ldlework | I'm a failure. |
| 00:32:25 | Araq | yeah I noticed but i couldn't be bothered |
| 00:32:59 | Araq | it's Uncle Bob's job to complain about that |
| 00:33:12 | Araq | he's making good money with these things |
| 00:33:14 | ldlework | Eh, its reflective of my professionalism |
| 00:33:45 | Araq | also he can play the drums and knows about why Smalltalk failed. |
| 00:33:50 | Araq | cool guy. |
| 00:34:00 | Araq | I will piss on his grave. |
| 00:36:57 | dom96 | Araq: I find the way you use the word "massage" to describe code cringy sometimes. |
| 00:37:54 | Araq | dom96 er ... what? when did I use that? |
| 00:38:10 | dom96 | "smileyFrmt: string ## How to massage the smiley filename." |
| 00:39:11 | ldlework | I think using 'massage' to refer to mutating data, or refactoring code, or even workarounds is pretty conventional/colloquial |
| 00:40:10 | Araq | XD |
| 00:40:39 | Araq | lol I don't remember this |
| 00:42:18 | Araq | dom96: omg, leave this comment as it is. it's hilarious. |
| 00:50:07 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 00:54:15 | * | vendethiel joined #nimrod |
| 01:02:12 | * | kmcguire joined #nimrod |
| 01:15:39 | * | Etheco quit (Read error: Connection reset by peer) |
| 01:17:12 | * | vendethiel quit (Ping timeout: 258 seconds) |
| 01:20:01 | * | vendethiel joined #nimrod |
| 01:20:29 | Varriount | Araq: What does "Object constructor needs an object type" mean? |
| 01:21:11 | Araq | it means Foo(x: 1, y: 2) doesn't work when Foo is not an object or a 'ref object' |
| 01:25:20 | Varriount | Ah, that's why it wasn't working for a tuple. |
| 01:26:22 | flaviu | "Error: for a 'var' type a variable needs to be passed" |
| 01:26:34 | reactormonk | flaviu, pretty much that. |
| 01:26:51 | flaviu | But the type signature doesn't seem to require a var. |
| 01:26:58 | Varriount | Araq: Any chance that error could be rewritten into something a bit less confusing, such as "Object contructor only works for object and ref object types"? |
| 01:26:59 | reactormonk | O.o |
| 01:27:17 | Varriount | flaviu: Da code? |
| 01:27:30 | flaviu | `line.substr(2).strip.add("\n")` |
| 01:27:45 | Araq | Varriount: i don't see any difference but make a PR |
| 01:27:47 | flaviu | `line` is a `string`, no var. |
| 01:28:06 | Araq | pretty sure 'add' takes a 'var string' |
| 01:28:19 | Araq | even if the types sometimes lie in system.nim |
| 01:28:50 | Araq | you should use '&' instead |
| 01:29:11 | flaviu | hmm, ok. But vim is highlighting the wrong place |
| 01:42:57 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 01:45:40 | Varriount | Araq: How do you create global variables that can be worked with during compile-time again? |
| 01:47:10 | willwillson | compileTime pragma? |
| 01:49:03 | Varriount | willwillson: Thats only for procedures.. I think? |
| 01:49:15 | willwillson | Varriount: works on vars aswell I believe |
| 01:49:35 | willwillson | Varriount: although, doesn't the manual say procedures only? |
| 01:50:21 | Varriount | willwillson: Yes. |
| 01:50:42 | Varriount | so.. "var i: int {.compileTime.}"? |
| 01:50:44 | willwillson | well: var test {.compileTime.} = 0 seems to work ;-) |
| 01:51:03 | * | vendethiel joined #nimrod |
| 01:52:44 | willwillson | your example would be: var i {.compileTime.}: int |
| 01:54:45 | Varriount | willwillson: Maybe you can help me with this: https://gist.github.com/Varriount/5d6b3905d98eabf1f2b7 |
| 01:55:23 | willwillson | Varriount: yeah, sure, I'll have a look (can't promise I can fix anything though ;D) |
| 01:55:30 | Varriount | I'm trying to generate a tuple-like subscript accessor, but I'm running into problems. |
| 02:08:10 | willwillson | Varriount: sorry, that has me stumped. |
| 02:10:52 | * | bjz quit (Ping timeout: 258 seconds) |
| 02:11:06 | Varriount | willwillson: No worries, it's only a spare-time thing |
| 02:11:14 | willwillson | I'm not sure it is possible to return multiple types with a return type of any is it? |
| 02:13:50 | * | NimBot_ joined #nimrod |
| 02:14:08 | * | NimBot quit (Remote host closed the connection) |
| 02:34:24 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 02:37:17 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 02:39:10 | * | vendethiel joined #nimrod |
| 02:40:07 | * | q66 quit (Quit: Leaving) |
| 02:48:22 | * | brson quit (Ping timeout: 250 seconds) |
| 02:59:46 | onionhammer | Varriount static: ? |
| 03:02:11 | * | Boscop_ quit (Read error: Connection reset by peer) |
| 03:02:20 | Varriount | onionhammer: Howso? |
| 03:02:30 | * | Boscop_ joined #nimrod |
| 03:07:53 | * | kapil__ joined #nimrod |
| 03:11:55 | flaviu | Macro? |
| 03:13:14 | Varriount | flaviu: But then I have the problem of how to get the type fields. |
| 03:13:50 | Varriount | Of course, I could have the user specify the fields, but I would rather make that optional |
| 03:15:54 | Varriount | 'genSubscriptAccessor(typ: typedesc)' |
| 03:18:35 | flaviu | peano arithmetic with types? :P |
| 03:23:21 | Varriount | flaviu: Huh? |
| 03:23:41 | flaviu | A[A[A[Nil]]] = 3 |
| 03:23:45 | flaviu | A[Nil] = 1 |
| 03:25:03 | flaviu | inc(i) == A[i] |
| 03:25:45 | Varriount | I still don't see how that's useful to my problem. |
| 03:26:29 | flaviu | Well, to solve your problem you need a way of incrementing an integer and checking for equality |
| 03:26:45 | flaviu | Peano numbers fit both those criteria |
| 03:27:12 | flaviu | Although I can't figure out how to check for equality atm |
| 03:27:32 | flaviu | `typedesc1 == typedesc2` fails to compile |
| 03:27:46 | Varriount | Yeah. |
| 03:28:17 | flaviu | What is a typedesc, underneath? |
| 03:28:55 | Varriount | flaviu: Eh, a compiler magic thing |
| 03:29:20 | Varriount | It's probably represented as an int by the VM (or not, who knows) |
| 03:30:04 | flaviu | Well, I got it to do arithmatic |
| 03:30:12 | Varriount | How? |
| 03:30:13 | flaviu | import typetraits and name equality |
| 03:30:28 | Varriount | flaviu: Isn't this abuse of types? |
| 03:30:36 | * | BitPuffin joined #nimrod |
| 03:30:38 | flaviu | lol |
| 03:30:48 | flaviu | What are types for if not to be abused? |
| 03:30:53 | flaviu | You should see the haskellers! |
| 03:32:26 | Varriount | What I really need is a 'members' procedure in the typetraits module. |
| 03:32:42 | flaviu | https://gist.github.com/91f27569b8755370507c |
| 03:33:09 | flaviu | All you have to do now is overcome the trivial "type mismatch: got (string) but expected 'int'" :P |
| 03:33:12 | flaviu | Have fun! |
| 03:35:00 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 03:36:20 | Varriount | flaviu: That's.. diabolical |
| 03:37:27 | flaviu | Don't blame me, mathematicians are a clever bunch! |
| 03:39:26 | flaviu | any = distinct auto |
| 03:39:31 | ldlework | Have you guys seen the compile-time brainfuck implementation written against Rust's type system? |
| 03:39:33 | flaviu | That's our problem here. |
| 03:40:05 | ldlework | Like, literally the type-system itself runs the brainfuck implementation |
| 03:40:14 | ldlework | Rust's type system is turing complete |
| 03:41:00 | Varriount | ldlework: Hm, but how understandable is the type system? |
| 03:41:25 | ldlework | Varriount: it takes people months to get started with Rust |
| 03:41:30 | ldlework | so probably not very |
| 03:41:32 | flaviu | It looks like peano arithmetic is can be made equivalent to a turing machine |
| 03:46:06 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 03:49:46 | * | vendethiel joined #nimrod |
| 03:55:09 | ldlework | gar macros are just so effing cool |
| 03:59:27 | flaviu | ldlework: I got all the boring stuff for nimlets done! |
| 03:59:37 | ldlework | flaviu: wat |
| 04:00:37 | flaviu | I got the build system running, and I wrapped the necessary C libraries. |
| 04:04:05 | flaviu | anyway, good night all. |
| 04:04:15 | ldlework | so many type annotation... :( |
| 04:06:25 | onionhammer | Varriount static: blocks run at compile time |
| 04:06:49 | onionhammer | so a var declared in there would be @ compile time |
| 04:08:53 | * | flaviu quit (Ping timeout: 264 seconds) |
| 04:10:01 | * | enquora quit (Quit: enquora) |
| 04:13:42 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 04:15:28 | * | vendethiel joined #nimrod |
| 04:18:25 | * | willwillson quit (Ping timeout: 255 seconds) |
| 04:29:30 | kmcguire | hey guys i have taken a little interest in nim and was wondering how come it does not use LLVM? |
| 04:29:38 | Varriount | onionhammer: And yet, we have the {.compileTime.} pragma... |
| 04:30:15 | Varriount | Really, I'd like a good way to unify all these compile-time syntax structures |
| 04:38:18 | * | BitPuffin joined #nimrod |
| 04:43:19 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 04:59:27 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 05:06:19 | perturbation | kmcguire: you can use clang as the compiler (vs. gcc, VS, etc.) but you are right in that nim doesn't target llvm bitcode. IIRC targeting LLVM as a back end is not as easy to implement(?), though you'd have to ask Araq about that. |
| 05:07:40 | * | endou_ joined #nimrod |
| 05:09:24 | * | endou quit (Ping timeout: 258 seconds) |
| 05:10:03 | * | vendethiel joined #nimrod |
| 05:12:18 | * | kmcguire quit (Quit: Lost terminal) |
| 05:22:19 | * | perturbation quit (Quit: Leaving) |
| 05:29:00 | * | j3rky joined #nimrod |
| 05:37:05 | * | j3rky quit (Quit: Konversation terminated!) |
| 05:40:52 | * | brson joined #nimrod |
| 05:52:55 | * | vendethiel quit (Ping timeout: 255 seconds) |
| 06:01:04 | * | vendethiel joined #nimrod |
| 06:16:46 | * | Demos quit (Read error: Connection reset by peer) |
| 06:27:26 | * | BitPuffin joined #nimrod |
| 06:29:36 | * | bjz joined #nimrod |
| 06:32:36 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 06:46:58 | * | bitcrusher joined #nimrod |
| 06:53:27 | * | BlaXpirit joined #nimrod |
| 07:05:23 | * | khmm joined #nimrod |
| 07:07:05 | * | bjz quit (Ping timeout: 264 seconds) |
| 07:11:40 | * | khmm quit (Ping timeout: 256 seconds) |
| 07:16:24 | * | khmm joined #nimrod |
| 07:43:57 | * | BlaXpirit quit (Read error: Connection reset by peer) |
| 08:16:11 | * | brson quit (Read error: Connection reset by peer) |
| 08:16:12 | * | BitPuffin joined #nimrod |
| 08:20:42 | * | BitPuffin quit (Ping timeout: 245 seconds) |
| 08:21:44 | * | brson joined #nimrod |
| 08:22:03 | ekarlso- | gokr: around ? |
| 08:37:16 | * | Trustable joined #nimrod |
| 08:45:42 | * | brson quit (Ping timeout: 245 seconds) |
| 08:48:57 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 08:53:13 | * | vendethiel joined #nimrod |
| 08:54:27 | * | khmm quit (Ping timeout: 245 seconds) |
| 09:00:14 | gokr | here |
| 09:01:19 | * | khmm joined #nimrod |
| 09:09:07 | ldlework | gokr: how can I make a new instances of a thing defined as, |
| 09:09:09 | ldlework | TRect* = tuple[x, y, width, height: int] |
| 09:11:12 | * | darkf_ joined #nimrod |
| 09:11:12 | gokr | I guess... x = (x: 10, y: 0 ...etc ) |
| 09:11:17 | gokr | Or? |
| 09:11:45 | gokr | I think tutorial1 shows tuple syntax, and IIRC its like that. |
| 09:14:50 | * | darkf quit (Ping timeout: 258 seconds) |
| 09:14:55 | * | darkf_ is now known as darkf |
| 09:16:05 | gokr | ekarlso-: Only around a little bit :) |
| 09:16:14 | gokr | Going to the bath house with my daughter soon |
| 09:16:55 | * | BitPuffin joined #nimrod |
| 09:21:52 | * | BitPuffin quit (Ping timeout: 244 seconds) |
| 09:22:36 | * | vendethiel quit (Ping timeout: 244 seconds) |
| 09:25:32 | * | gour joined #nimrod |
| 09:27:41 | * | vendethiel joined #nimrod |
| 09:46:35 | * | bjz joined #nimrod |
| 09:52:47 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 09:59:34 | * | vendethiel joined #nimrod |
| 10:12:59 | * | darkf_ joined #nimrod |
| 10:16:33 | * | darkf quit (Ping timeout: 258 seconds) |
| 10:19:18 | * | darkf_ is now known as darkf |
| 10:25:56 | * | Boscop__ joined #nimrod |
| 10:27:21 | * | gour_ joined #nimrod |
| 10:27:22 | * | khmm quit (Ping timeout: 245 seconds) |
| 10:28:31 | * | Boscop joined #nimrod |
| 10:28:31 | * | Boscop quit (Changing host) |
| 10:28:31 | * | Boscop joined #nimrod |
| 10:29:13 | * | Boscop_ quit (Ping timeout: 255 seconds) |
| 10:30:11 | * | gour quit (Ping timeout: 252 seconds) |
| 10:31:07 | * | Boscop__ quit (Ping timeout: 245 seconds) |
| 10:31:29 | * | khmm joined #nimrod |
| 10:41:10 | * | BlaXpirit joined #nimrod |
| 10:54:20 | * | Boggart quit (Quit: Leaving) |
| 11:05:43 | * | BitPuffin joined #nimrod |
| 11:05:49 | * | zio_tom78 joined #nimrod |
| 11:06:08 | zio_tom78 | Hi to everybody |
| 11:07:08 | * | q66 joined #nimrod |
| 11:24:50 | * | vendethiel quit (Ping timeout: 244 seconds) |
| 11:27:52 | * | flaviu joined #nimrod |
| 11:32:23 | * | vendethiel joined #nimrod |
| 11:42:49 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 11:46:12 | * | gour_ is now known as gour |
| 11:47:23 | zio_tom78 | Hi guys, is there any way to change the CSS stylesheet used by "nim doc"? |
| 11:48:49 | * | johnsoft quit (Ping timeout: 244 seconds) |
| 11:49:58 | * | bjz quit (Remote host closed the connection) |
| 11:50:30 | * | bjz joined #nimrod |
| 11:51:30 | * | johnsoft joined #nimrod |
| 11:51:56 | dom96 | zio_tom78: there is, but it's not easy. |
| 11:52:08 | dom96 | flaviu: Did you get a reply from filwit about the new doc design? |
| 11:52:25 | flaviu | dom96: Nope, no replies yet |
| 11:53:20 | * | q66 quit (Quit: Leaving) |
| 11:56:01 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 11:57:50 | * | flaviu quit (Ping timeout: 256 seconds) |
| 12:00:03 | * | Etheco joined #nimrod |
| 12:00:49 | * | zio_tom78 quit (Ping timeout: 258 seconds) |
| 12:03:34 | * | vendethiel joined #nimrod |
| 12:03:45 | * | AFKMorpork is now known as AMorpork |
| 12:07:34 | * | gour quit (Quit: Konversation terminated!) |
| 12:10:43 | * | gour joined #nimrod |
| 12:14:32 | * | bjz quit (Read error: Connection reset by peer) |
| 12:14:54 | * | bjz joined #nimrod |
| 12:15:29 | * | Araq0 joined #nimrod |
| 12:15:42 | Araq0 | huh? it's pretty easy to change the CSS |
| 12:15:58 | Araq0 | just edit your nimdoc.cfg or provide a special one for your project |
| 12:25:05 | * | bjz quit (Ping timeout: 264 seconds) |
| 12:25:53 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 12:31:05 | * | bjz joined #nimrod |
| 12:35:38 | * | gour quit (Quit: Konversation terminated!) |
| 12:36:21 | * | gour joined #nimrod |
| 12:40:27 | * | gour quit (Client Quit) |
| 12:40:57 | * | gour joined #nimrod |
| 13:10:01 | * | gour quit (Quit: Konversation terminated!) |
| 13:10:33 | * | gour joined #nimrod |
| 13:24:57 | * | untitaker quit (Ping timeout: 240 seconds) |
| 13:31:41 | * | untitaker joined #nimrod |
| 13:33:10 | EXetoC | Error: invalid type: 'Table[Format, tuple[headerSize: int, maxDataSize: int, fixedDataSize: bool]] |
| 13:33:44 | Araq0 | Format is a 'var T'? |
| 13:36:24 | EXetoC | Araq0: an enum, and I'm trying to create a const table: "const T = {fmtPositiveFixint: (headerSize: 1, ...), ...}.toTable" |
| 13:37:10 | EXetoC | the enum type has holes, but I can make it an array with a workaround |
| 13:37:35 | Araq0 | er |
| 13:37:49 | Araq0 | you know very well 'object' cannot be used in a 'const' section for now |
| 13:37:56 | EXetoC | I'm doing sophisticated things as always. there are about 35 enumerators, and I'd like to reduce repetition a little |
| 13:38:14 | Araq0 | you even reported a feature request for it! |
| 13:38:30 | Araq0 | (and I agree btw, we should really support that) |
| 13:41:03 | EXetoC | ok good. I can't remember many details about all the bugs I've reported |
| 13:41:22 | EXetoC | I wonder if I can use compileTime for this. I need to do lookups at compile-time |
| 13:43:49 | Araq0 | you should be able to use a .compileTime var/let, yeah |
| 13:45:34 | * | gokr quit (Quit: Leaving.) |
| 13:51:04 | EXetoC | that with static parameters does work |
| 13:51:25 | * | BitPuffin joined #nimrod |
| 14:04:18 | EXetoC | I've been wanting to ensure that every enumerator appears at least once in a given block. it's just a little difficult when there are holes, but it seems like a great way to ensure that interfaces are up-to-date |
| 14:12:33 | * | kostya joined #nimrod |
| 14:15:08 | * | gokr joined #nimrod |
| 14:17:28 | * | willwillson joined #nimrod |
| 14:19:27 | * | zio_tom78 joined #nimrod |
| 14:19:50 | zio_tom78 | Sorry guys, my connection dropped and I lost the last messages |
| 14:20:00 | Araq0 | EXetoC: not sure I can follow. a 'case' over the enum ensures statically that every value is handled |
| 14:20:17 | Araq0 | even if the enum has holes for C interop |
| 14:21:17 | Araq0 | zio_tom78: PLEASE improve our CSS |
| 14:21:26 | zio_tom78 | Araq0: thanks for your answer, I wasn't aware of the presence of nimdoc.cfg |
| 14:21:52 | zio_tom78 | I'm not an expert of CSS, I just put together something to have a nicer layout |
| 14:22:07 | Araq0 | the config is excessive and complete, you can modify pretty much everything |
| 14:22:21 | zio_tom78 | I saved the .html documentation from Nim's site on my laptop and modified every CSS by hand |
| 14:22:22 | zio_tom78 | (blush) |
| 14:22:53 | zio_tom78 | I was looking at the IRC logs, filwit did an impressive job on the documentation |
| 14:22:58 | EXetoC | Araq0: "ensureCompleteCoverage(EnumType): statements...", which requires iteration, but it's another minor issue. it was just a thought |
| 14:24:27 | Araq0 | zio_tom78: yeah but he disappeared and we don't even know if he's still alive |
| 14:27:18 | zio_tom78 | Araq0: That's a pity, he said he was almost done |
| 14:29:43 | Araq0 | yeah indeed. I hope he is well. |
| 14:29:47 | Araq0 | bbl |
| 14:29:51 | * | Araq0 quit (Quit: Page closed) |
| 14:32:03 | zio_tom78 | If you're curious, here's how my CSS looks: http://jsfiddle.net/zio_tom78/jy6fhyf1/embedded/result/ |
| 14:32:23 | zio_tom78 | It's just aesthetics, the DIVs and everything else in the HTML have been left unchanged |
| 14:33:20 | EXetoC | I was also thinking about ways to expand something like this: "of x, y: p(casevalue)" to "of x: p(casevalue) of y: p(casevalue)" where 'p' could be "proc p(e: static[EnumType])" :-) |
| 14:33:24 | EXetoC | A user macro might do |
| 14:35:40 | gokr | zio_tom78: Looks neat |
| 14:39:41 | zio_tom78 | gokr: Thanks! |
| 14:56:04 | * | dom96_ quit (Ping timeout: 255 seconds) |
| 14:57:40 | * | gour_ joined #nimrod |
| 15:01:03 | * | gour quit (Ping timeout: 250 seconds) |
| 15:05:35 | * | BlaXpirit joined #nimrod |
| 15:07:31 | * | willwillson quit (Ping timeout: 244 seconds) |
| 15:13:42 | * | gokr quit (Ping timeout: 264 seconds) |
| 15:14:14 | * | vendethiel quit (Ping timeout: 244 seconds) |
| 15:16:44 | * | dom96_ joined #nimrod |
| 15:17:11 | * | vendethiel joined #nimrod |
| 15:17:26 | dom96_ | zio_tom78: Did you perhaps find a link to filwit's version of the docs? |
| 15:18:40 | * | j3rky joined #nimrod |
| 15:19:47 | * | gour_ quit (Quit: Konversation terminated!) |
| 15:20:14 | * | gour joined #nimrod |
| 15:32:07 | zio_tom78 | Yes, by digging the IRC logs (thanks, Google!) I was able to find this: http://reign-studios.net/philipwitte/nimrod/docs/docs.htm |
| 15:32:15 | zio_tom78 | and this: http://reign-studios.net/philipwitte/nimrod/design2-docs.png |
| 15:32:22 | zio_tom78 | (See http://build.nimrod-lang.org/irclogs/25-08-2014.html) |
| 15:35:21 | * | gokr joined #nimrod |
| 15:39:49 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 15:40:46 | * | vendethiel joined #nimrod |
| 15:43:15 | * | darkf quit (Quit: Leaving) |
| 15:44:36 | wan | !seen filwit |
| 15:44:36 | NimBot | filwit was last seen on Thu Oct 2 03:54:30 2014 quitting with message: Quit: Leaving |
| 15:45:59 | wan | last activity on github: 2 nov |
| 15:46:07 | wan | he might just be really busy |
| 15:46:56 | EXetoC | shiny |
| 15:47:35 | EXetoC | I'm looking forward towards the type categorization |
| 15:49:32 | * | gokr left #nimrod (#nimrod) |
| 15:50:20 | dom96_ | Could somebody maybe work towards that design in the screenshot? |
| 15:51:24 | * | kapil__ quit (Quit: Connection closed for inactivity) |
| 15:53:13 | * | quasinoxen quit (Ping timeout: 255 seconds) |
| 15:55:03 | * | j3rky quit (Ping timeout: 244 seconds) |
| 15:55:12 | * | quasinoxen joined #nimrod |
| 16:05:00 | * | AMorpork is now known as BuyingMorpork |
| 16:08:58 | * | willwillson joined #nimrod |
| 16:18:57 | * | Amrykid quit (Ping timeout: 265 seconds) |
| 16:21:48 | * | Amrykid joined #nimrod |
| 16:24:05 | * | asterite joined #nimrod |
| 16:25:37 | * | khmm quit (Ping timeout: 240 seconds) |
| 16:30:12 | zio_tom78 | Sorry, gotta go. Thanks to everybody and cheers |
| 16:30:15 | * | zio_tom78 left #nimrod ("ERC Version 5.3 (IRC client for Emacs)") |
| 16:30:38 | * | c74d quit (Remote host closed the connection) |
| 16:48:17 | * | Joe_knock joined #nimrod |
| 16:48:17 | * | Joe_knock quit (Changing host) |
| 16:48:17 | * | Joe_knock joined #nimrod |
| 16:50:35 | Joe_knock | Did the OpenSSL issue get fixed yet? |
| 16:55:25 | * | dom96_ quit (Ping timeout: 246 seconds) |
| 16:55:45 | * | BuyingMorpork is now known as AMorpork |
| 16:56:37 | willwillson | Varriount: I came up with this: https://gist.github.com/cowboy-coders/1f3a6fbace89c4a2cf66 . Don't know if it is any good! |
| 17:09:24 | willwillson | Joe_knock: Not yet joe, issues are still open. |
| 17:09:54 | * | def- quit (Ping timeout: 240 seconds) |
| 17:11:31 | * | asterite left #nimrod (#nimrod) |
| 17:16:06 | * | def- joined #nimrod |
| 17:21:59 | * | brson joined #nimrod |
| 17:24:56 | ldlework | good morning |
| 17:26:15 | EXetoC | hola |
| 17:31:15 | ldlework | EXetoC: I started a small game framework built up around graphics |
| 17:31:22 | ldlework | graphics module that is |
| 17:32:26 | * | Araq0 joined #nimrod |
| 17:32:52 | EXetoC | great |
| 17:34:02 | ldlework | I'm calling it nimple |
| 17:34:04 | ldlework | :) |
| 17:37:44 | * | brson quit (Quit: leaving) |
| 17:37:56 | * | brson joined #nimrod |
| 17:38:24 | EXetoC | pronounced as nipple? |
| 17:39:06 | ldlework | like simple |
| 17:39:31 | EXetoC | that would be more approriate |
| 17:42:06 | Araq0 | a library that does graph plotting would be more useful |
| 17:42:10 | * | q66 joined #nimrod |
| 17:42:47 | Araq0 | we have a couple of nimgame frameworks, but afaict game programmers like to roll their own unless it's a decedent 3d engine |
| 17:43:03 | * | brson quit (Quit: leaving) |
| 17:43:17 | * | brson joined #nimrod |
| 17:43:49 | Araq0 | also where is my COM support library? |
| 17:48:28 | * | dom96_ joined #nimrod |
| 17:50:45 | * | Araq0 quit (Quit: Page closed) |
| 17:51:13 | * | brson quit (Ping timeout: 264 seconds) |
| 17:58:44 | * | brson joined #nimrod |
| 18:01:44 | * | kostya quit (Remote host closed the connection) |
| 18:02:29 | * | gour quit (Quit: Konversation terminated!) |
| 18:02:51 | * | gour joined #nimrod |
| 18:08:15 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 18:16:27 | * | vendethiel joined #nimrod |
| 18:21:56 | * | enquora joined #nimrod |
| 18:25:23 | * | enquora quit (Remote host closed the connection) |
| 18:26:55 | * | enquora joined #nimrod |
| 18:27:25 | * | gour is wondering what is the credibility for this article (http://en.wikipedia.org/wiki/Devuan) to be in wikipedia in comparison with e.g. Nim(rod) |
| 18:31:51 | * | enquora quit (Remote host closed the connection) |
| 18:32:03 | Joe_knock | softpedia is a recognized news/tech site |
| 18:32:27 | * | enquora joined #nimrod |
| 18:33:05 | Araq | so who agrees with dom96 that we need to release 0.10.2 before 1.0? |
| 18:33:40 | Joe_knock | There's a 0.10.1 release? |
| 18:33:55 | Araq | that's what devel says |
| 18:34:04 | Araq | we follow the odd/even versioning scheme |
| 18:34:16 | Araq | odd numbers are in development versions |
| 18:35:37 | Joe_knock | If the current goal to get to 1.0 is bug cleanup, then it doesn't really help having a 0.10.2 that is just a cleanup of 20-50 bugs |
| 18:36:10 | Araq | it's not about the number of fixed bugs |
| 18:36:49 | Araq | 0.10.2 is the big break release which renames the language to Nim and uses --cs:partial |
| 18:36:55 | gour | Joe_knock: it's a strange policy. there is e.g. blog post by 'established' it author about nim, but that does not help |
| 18:37:01 | * | superfunc joined #nimrod |
| 18:38:21 | willwillson | I agree with dom96 on this one. Release 0.10.2, get more feedback, and hopefully get a more polished 1.0 (I imagine this is when loads of people will come flocking to Nim) |
| 18:38:29 | Joe_knock | gour: I have a strategy to fix the issues we're having with the overlords at wikipedia. Although personally, I don't think I've ever read up about a language in wikipedia |
| 18:39:17 | gour | Joe_knock: i did about several ones...many people simply jump there to check it out. i agree, not the most important, but still... |
| 18:39:29 | Joe_knock | willwillson: Nim gets a ton of upvotes on hacker news each time something about is posted, but the growth of the language seems organic (with or without it) |
| 18:40:35 | ldlework | I tell everyone I know about it, a few times a day |
| 18:44:33 | * | Matthias247 joined #nimrod |
| 18:47:34 | EXetoC | ldlework: did you not find any other issues with nim-libtcod? |
| 18:47:38 | NimBot | Araq/Nimrod devel 898501d Dominik Picheta [+0 ±1 -0]: Moved smiliey format to config hash table. |
| 18:47:56 | Araq | bah |
| 18:48:17 | Araq | sure let's have more configuration |
| 18:48:30 | ldlework | EXetoC: it works really well |
| 18:48:39 | Araq | who can rename files these days |
| 18:48:57 | EXetoC | ldlework: ok |
| 18:49:11 | ldlework | EXetoC: I know what you're getting at and I'm sorry |
| 18:49:14 | Araq | dom96_, dom96: where are the tests for the future module? |
| 18:49:50 | EXetoC | ldlework: I think I know what you're getting at, but it's no hurry |
| 18:49:55 | EXetoC | :-p |
| 18:50:01 | ldlework | ^_^ |
| 18:50:12 | Araq | I think I don't understand anything |
| 18:50:33 | ldlework | Araq: finally, you listen to us |
| 18:50:43 | ldlework | :) |
| 18:51:01 | Araq | well I got it now |
| 18:51:51 | Araq | drinking this much beer yesterday was not my mistake. my mistake is that I didn't drink today. |
| 18:52:24 | willwillson | is some of your best coding done whilst under the influence? |
| 18:53:55 | Araq | it doesn't affect my coding abilities in any way, I think |
| 18:54:24 | Araq | it's like driving a car |
| 18:56:31 | willwillson | ^^ |
| 18:56:32 | EXetoC | isn't fmt a more common abbreviation of format? |
| 18:56:50 | EXetoC | are you trying to be all unixy and stuff? :p |
| 18:58:00 | Araq | I don't think our naming guideline mentions 'format' |
| 18:58:12 | Araq | so everything is fine |
| 19:02:32 | EXetoC | c(:)|< |
| 19:03:23 | * | drewsrem joined #nimrod |
| 19:03:59 | Matthias247 | Araq: did you try to reach the ballmer peak? |
| 19:04:40 | Araq | nah, I succeeded :P |
| 19:04:44 | Araq | hi drewsrem welcome |
| 19:05:00 | drewsrem | Araq, hey |
| 19:05:46 | EXetoC | more metaprogramming, moooore! |
| 19:05:54 | Matthias247 | http://xkcd.com/323/ for the unknowing ones ;) |
| 19:10:07 | ldlework | EXetoC: want to try Nimple? I have some examples. |
| 19:10:08 | * | superfunc quit (Read error: Connection reset by peer) |
| 19:11:11 | ldlework | https://github.com/dustinlacewell/nimple |
| 19:11:21 | ldlework | you can just do: nim c -r examples/automata.nim |
| 19:11:30 | ldlework | or any of the other examples |
| 19:12:23 | ldlework | This is what a minimal example looks like, https://github.com/dustinlacewell/nimple/blob/master/examples/square.nim |
| 19:14:36 | ldlework | I wonder if I should organize a Nim game-programming competition |
| 19:20:10 | EXetoC | I'm busy trying to see what kind of code the compiler chokes on |
| 19:20:32 | ldlework | EXetoC: ok |
| 19:21:00 | * | letsgodoge joined #nimrod |
| 19:21:22 | Araq | hi letsgodoge welcome |
| 19:21:27 | letsgodoge | thanks |
| 19:21:40 | Araq | do no thank me, I'm a bot |
| 19:21:47 | ldlework | lies |
| 19:21:53 | ldlework | I'm having a hard time with mutually referential types |
| 19:21:57 | ldlework | existing in different modules |
| 19:22:13 | Araq | well that's simply not possible |
| 19:22:13 | letsgodoge | Is there a proc that takes a command and args like osproc.execProcess but returns the status code? |
| 19:22:29 | Araq | letsgodoge: yeah |
| 19:22:35 | Araq | but I forgot its name |
| 19:22:37 | ldlework | Araq: right, its forcing me to do wierd things like creating 4 different types, etc |
| 19:22:50 | ldlework | Araq: are forward type declarations hard? |
| 19:23:02 | Araq | ldlework: usually you can use generics or "RootRef" to get around the limitation |
| 19:23:16 | ldlework | Araq: I don't know anything about that. Is it documented? |
| 19:23:34 | ldlework | Also how would generics solve it? |
| 19:24:09 | Araq | it's somewhere on the forum ... |
| 19:24:27 | ldlework | I kinda wish there was just a namespace/module scope |
| 19:24:54 | Araq | I planned a 'submodule' feature once for guys like you |
| 19:25:16 | Araq | but dom96 said he will leave Nim for good if it gets into the language, lol |
| 19:26:29 | ldlework | Araq: just kinda like, files can do something like module "foo": and then everything under that gets put into module "foo" regardless of where stuff comes from filewise |
| 19:26:30 | EXetoC | and we need him, right? |
| 19:26:44 | ldlework | and a first takes place where what is in what modules is determined |
| 19:26:52 | ldlework | then things proceed as normal |
| 19:27:05 | Araq | so you want 'include'? |
| 19:27:16 | Araq | that already exists |
| 19:27:21 | ldlework | so the order of parsing of files does have anything to do with import dependencies |
| 19:27:44 | ldlework | because the file parsing leads to building what's in the modules *then* the modules are compiled or whatever |
| 19:27:44 | Araq | or maybe you want 'export' ? |
| 19:28:23 | ldlework | foo.nim: module: type Foo: blah: Bar |
| 19:28:33 | ldlework | err |
| 19:28:40 | ldlework | foo.nim: module "foo": type Foo: blah: Bar |
| 19:28:49 | * | letsgodoge quit (Quit: Leaving.) |
| 19:28:53 | ldlework | bar.nim module "foo": type Bar asdf: int |
| 19:29:29 | ldlework | IE, the importabe module "foo" is built up of Foo and Bar, before dependneies and actual types start getting created and so on |
| 19:29:35 | Araq | I don't understand it but I don't like it |
| 19:30:02 | ldlework | IE, the order in which the files are loaded from disk has no consequence on whether something is yet available to be used in a struct field or whatever |
| 19:30:05 | * | ldlework shrugs |
| 19:30:07 | ldlework | K |
| 19:30:13 | * | letsgodoge joined #nimrod |
| 19:30:45 | Araq | so essentially you don't like the requirement of forward declarations |
| 19:30:53 | Araq | that's a common complaint |
| 19:31:03 | ldlework | basically, you consturct the "foo" module first by concating any files that have module "foo" in them |
| 19:31:07 | ldlework | after all the modules are built |
| 19:31:12 | ldlework | then you compile the "main" module |
| 19:31:16 | ldlework | which might import from other modules |
| 19:31:28 | ldlework | but at this point, the modules all exist in memory rather than be represented by files |
| 19:31:35 | ldlework | so "foo" module is built up of different files |
| 19:31:40 | Araq | ah so you want c#'s partial |
| 19:31:49 | ldlework | Basically, just Rust's modules |
| 19:31:59 | Araq | well as I said, use 'include' for that |
| 19:32:01 | ldlework | Which lets you build up modules across files as a first pass |
| 19:32:08 | ldlework | then I can do "import foo" |
| 19:32:16 | ldlework | and get everything from that ethereal 'module' |
| 19:32:31 | Araq | that's sounds dangerous. I can imagine programmers will abuse it. |
| 19:32:39 | ldlework | dangerous how? |
| 19:32:52 | ldlework | It simply abstracts the conceptualization of the module, out from the file metaphor |
| 19:33:03 | Araq | I'm not serious. |
| 19:33:09 | ldlework | ok |
| 19:33:27 | ldlework | "You can put all your types in the same file. After all, if they are recursive why do you want to split them apart?" |
| 19:33:28 | Matthias247 | I think rust modules pretty much suck |
| 19:33:38 | Matthias247 | because of the exact file == module problem |
| 19:33:44 | ldlework | ... |
| 19:33:53 | ldlework | Rust... doesn't have that problem |
| 19:34:07 | ldlework | Nim does. |
| 19:34:14 | bjz | Matthias247: more that they are pretty crude compared to ML :) |
| 19:35:03 | Matthias247 | rust has a problem. Every time you create a new file you also have a new module |
| 19:35:08 | Matthias247 | wheether you want that or not |
| 19:35:10 | Araq | ldlework: you still haven't explained why 'include' doesn't solve your problem |
| 19:35:15 | Matthias247 | and I think it's terrible |
| 19:35:46 | ldlework | Matthias247: I think you're wrong dude |
| 19:35:56 | ldlework | Rust modules are defined by the mod{ } clauses |
| 19:36:01 | Matthias247 | nope, I'm not |
| 19:36:07 | ldlework | You can build any module, from any combination of files |
| 19:36:16 | ldlework | http://rustbyexample.com/mod.html |
| 19:36:30 | Matthias247 | you build a module wihtout a file but not a file without a module |
| 19:36:56 | * | Boggart joined #nimrod |
| 19:36:57 | ldlework | Matthias247: ah you're saying if you abstain from crafting modules with mod, it just defaults to each file being a module? |
| 19:37:43 | * | Boggart quit (Client Quit) |
| 19:37:43 | Matthias247 | ldlework: no. It's that you can't import a file without having another mod {} from it created implicitely |
| 19:39:02 | Matthias247 | say you want a module which contains 5 classes that are deeply interacting with each other (needing access to private data). You can't spread those into 5 files in Rust |
| 19:39:16 | Matthias247 | like you would do with C++/C#/Java/... |
| 19:41:14 | ldlework | Matthias247: dude |
| 19:41:30 | ldlework | maybe you're just ignoring me showing you evidence that this isn't the case in Rust |
| 19:41:41 | ldlework | mod allows you to forumalte ethereal modules from disparate files |
| 19:42:11 | ldlework | You can even create nested modules this way |
| 19:42:13 | Matthias247 | mod allows to define multiple modules in one file |
| 19:42:27 | Matthias247 | but not to define one module from multiple files |
| 19:42:47 | bjz | Matthias247: for that you reexport |
| 19:42:58 | Matthias247 | if a.rs defines mod a{} and b.rs defines mod b{} and a.rs includes b.rs you get mod a.b |
| 19:43:15 | Matthias247 | bjz: that doesn't help you with privacy problems |
| 19:43:33 | Matthias247 | what friend in C++ and internal visibility in Java/C# does |
| 19:43:45 | Matthias247 | and doen't tell me that those are never needed |
| 19:44:47 | ldlework | Matthias247: I think I understand what you're saying now |
| 19:45:09 | ldlework | Araq: is this the forum post you meant, http://forum.nimrod-lang.org/t/296 ? |
| 19:45:59 | Araq | ldlework: indeed |
| 19:46:27 | Araq | how did you manage to find it? |
| 19:46:45 | Araq | the forum has no search feature ! |
| 19:46:58 | Araq | you cannot possibly use that thing called "search machine"?! |
| 19:47:09 | EXetoC | I've heard of those |
| 19:48:42 | letsgodoge | what type is stdin in nim |
| 19:49:11 | EXetoC | see the system module, or the generated documentation |
| 19:49:17 | Matthias247 | ldlework: good ;) |
| 19:49:40 | letsgodoge | thanks EXetoC |
| 19:51:45 | Araq | letsgodoge: system.File |
| 19:53:20 | * | gokr_ joined #nimrod |
| 19:53:28 | EXetoC | Araq: where should interfaces for both arrays/sequences be defined? to we use sequtils for array utils too? |
| 19:53:48 | Araq | yeah I think so |
| 19:57:13 | ldlework | Araq: google |
| 19:58:29 | * | flaviu__ joined #nimrod |
| 19:58:36 | flaviu__ | Varriount: I've got it! |
| 19:58:36 | EXetoC | the idea is to have an interface for inserting and extracting arbitrary types from an int8 buffer, and with overflow checks |
| 19:58:58 | flaviu__ | Allocate the field on the heap and return a `pointer` |
| 19:59:26 | flaviu__ | Ugly, but it'll work. |
| 20:00:00 | * | flaviu__ quit (Client Quit) |
| 20:09:39 | * | gour quit (Quit: Konversation terminated!) |
| 20:13:03 | Joe_knock | In terms of which language/s we are directly competing with, which ones do you guys primarily see as languages we are competing with? |
| 20:13:38 | Araq | Rust, D and Go for the simple reason that others constantly compare us with them |
| 20:15:52 | Joe_knock | Those are other upcoming languages. What about the more entrenched ones? Are we targeting C++ guys or trying to lure in Python/Ruby people? |
| 20:18:11 | ldlework | Joe_knock: I really feel like there is a legitimate comparison to be made to C# in some ways but I don't think other people find it a useful comparison |
| 20:18:44 | ldlework | Its like Vala but not a joke. |
| 20:19:06 | * | brson quit (Ping timeout: 264 seconds) |
| 20:23:56 | Araq | Joe_knock: Nim targets the programmers who care about their end users ... |
| 20:24:58 | Araq | fast easily deployable executables |
| 20:25:43 | Araq | and for the other programmers we have a macro system :P |
| 20:25:51 | Joe_knock | lol |
| 20:29:02 | ldlework | fast easily deployable executables?! |
| 20:30:09 | Araq | ldlework: why do you disagree? |
| 20:31:52 | ldlework | The prize of "easily deployable executables" goes to Golang which will happily statically compile say libtcod and friends so my users don't have to worry it right? |
| 20:32:17 | ldlework | I'm probably ignorant on this topic |
| 20:32:18 | Araq | only if you don't care about binary sizes |
| 20:32:30 | ldlework | Who would? space and bandwidth is cheap |
| 20:32:38 | ldlework | we want easy deployment |
| 20:33:05 | Joe_knock | Do we have an sql-lite lib? |
| 20:33:35 | reactormonk | Joe_knock, I think so |
| 20:34:03 | Araq | ldlework: *shrug*, there are embedded systems |
| 20:34:14 | ldlework | Araq: where you're probably not depending on such libs |
| 20:34:23 | ldlework | Araq: and in the case you need to deploy some app and a dep |
| 20:34:29 | ldlework | who cares if its one binary or two, its the same size |
| 20:34:48 | Araq | Golang produces significantly large executables iirc |
| 20:34:53 | Araq | *larger |
| 20:35:35 | Araq | and with its excessive reflection they will never get what Nim easily does with --deadCodeElim |
| 20:40:55 | ldlework | Araq: did you say whether implementing forward type declarations is hard ? |
| 20:42:32 | ldlework | Also am I right in observing that |
| 20:42:37 | ldlework | if I have modules a, b, c |
| 20:42:42 | ldlework | each of which implement A, B, C |
| 20:42:48 | ldlework | and B refers to A |
| 20:42:53 | ldlework | and C refers to B |
| 20:43:05 | ldlework | that for C to do something to B's reference of A |
| 20:43:11 | Araq | no, you will get your forward declarations |
| 20:43:11 | ldlework | I need to import from a? |
| 20:43:16 | ldlework | Araq: okay :) |
| 20:43:34 | Araq | I've given up to teach you guys good software design |
| 20:43:52 | ldlework | Right now in the case of A<=>B, I'm having to write an AController that I actually pass to B |
| 20:44:34 | ldlework | Araq: I'd be willing to hear how to remodel things if you wanted to hear about what I'm trying to build |
| 20:45:12 | Araq | you don't want to hear how I model game data structures |
| 20:46:19 | ldlework | Araq: is the reason why this stuff works the way it does, because Nim literally compiles as it goes? |
| 20:46:45 | Araq | not really, but it's a common misconception |
| 20:46:52 | * | flaviu joined #nimrod |
| 20:47:11 | ldlework | Araq: also, would an altnative to forward declarations be like a first pass where Nim first just figures out what top-level things are being declared by the project |
| 20:47:23 | ldlework | IE, it doesn't try to parse anything about fields or proc implementations, etc |
| 20:47:30 | ldlework | Just what types and procs are defined? |
| 20:47:49 | ldlework | then it can resolve dependencies |
| 20:48:13 | Araq | yeah that's a way to do it |
| 20:48:25 | ldlework | Is there a fundamental badness to that |
| 20:48:39 | Araq | it's a pita |
| 20:48:49 | ldlework | I see |
| 20:48:50 | Araq | proc p(x: type(q)) |
| 20:48:56 | Araq | proc q(x: type(p)) |
| 20:50:06 | ldlework | Hmm but it seems like you have the part figured out where, which one do you compile first? |
| 20:50:20 | ldlework | Because you support that as long as they are together in the same type declaration |
| 20:50:37 | ldlework | So it seems more like a lexical preparsing thing, rather than, 'how do we compile p before q and vice versa' |
| 20:51:21 | Araq | well D does what you describe and it took a decade to get it reasonably stable |
| 20:51:26 | flaviu | ldlework: How would macros and templates interact with all this? |
| 20:51:37 | ldlework | I feel like it should just consider the whole project as one big type clause |
| 20:51:48 | ldlework | flaviu: well don't macros get expanded |
| 20:51:51 | Araq | and D doesn't have macros |
| 20:51:52 | ldlework | and then what we talked about happens? |
| 20:52:11 | Araq | also it produces weird error messages |
| 20:52:12 | flaviu | ldlework: But it can't be a preprocessing phase like you suggested |
| 20:52:21 | ldlework | I mean it seems 'already solved' for types in the same type clause |
| 20:52:25 | ldlework | so whatever happens for that type clause |
| 20:52:29 | Araq | where you're like "huh? why does the compiler complain *here*?" |
| 20:52:45 | ldlework | where it says "Okay I see we have two types, let me not freak out that A refers to B and I haven't compiled B yet" |
| 20:52:57 | flaviu | ldlework: But I'm 99% sure you can't embed code generation in the middle of a type clause. |
| 20:53:00 | ldlework | I don't really understand how applying that strategy to the project as whole |
| 20:53:07 | ldlework | represents a differnet problem |
| 20:53:29 | Araq | well you already understand this it's then a global non-modular analysis |
| 20:54:15 | ldlework | I feel like people will end up just foward declaring everything |
| 20:54:29 | ldlework | and we'll end up with Nim styles where the top of each file is essentially an .h |
| 20:54:47 | ldlework | Just so you don't even have to think about this problem, because well everything is forward decalred as style |
| 20:55:10 | Araq | the problem is real, but Haskell and F# have it too and nobody complains because Haskell is perfect |
| 20:55:36 | EXetoC | Araq: how often do you have to forward declare? |
| 20:55:54 | ldlework | EXetoC: anytime the compiler runs into a reference that hasn't be previous compiled, right? |
| 20:56:21 | ldlework | so mutually referring types, procs that refer to procs further down in the file and so on |
| 20:56:44 | EXetoC | just looking for an estimate. I haven't had to do it that many times yet, but my code bases are kind of small |
| 20:57:03 | flaviu | How would https://gist.github.com/11259d39ad850088541a work with a pre-processing phase? |
| 20:57:56 | * | brson joined #nimrod |
| 20:57:57 | EXetoC | it's a little annoying, but I'm not making good use of bookmarks and so on |
| 20:58:21 | flaviu | ldlework: I actually agree with you, forward declarations ideally should not be necessary. How it'd actually be implemented is the real problem. |
| 20:58:23 | EXetoC | you really need a mark plugin for vim |
| 20:58:37 | Araq | EXetoC: not often and when I do, it makes me aware of a mutual dependency which is a good thing |
| 20:58:38 | ldlework | registers, 'test', 'genFoo' are names that exist (whatever they are) |
| 20:59:03 | flaviu | ldlework: test() requires that a field or proc `foo` exist. |
| 20:59:11 | ldlework | flaviu: just that the name exists |
| 20:59:33 | flaviu | I don't understand what you're saying. |
| 20:59:45 | ldlework | flaviu: it just remembers that 'test' and 'genFoo' are -things- |
| 20:59:46 | Araq | EXetoC: contrary to popular belief, recursions can be hard to get right |
| 20:59:57 | ldlework | then it renders the macros in order |
| 21:00:04 | ldlework | so it hits genFoo, and tries to expand it |
| 21:00:17 | ldlework | genFoo doesn't require any non-existing things so it compiles |
| 21:00:27 | ldlework | then it hits `test`'s invocation |
| 21:00:30 | ldlework | foo exists at this point |
| 21:00:34 | ldlework | so `test` also expands |
| 21:02:26 | * | Mat4 joined #nimrod |
| 21:02:34 | flaviu | ldlework: https://gist.github.com/54a0e82995b36cdeaf78 |
| 21:02:36 | Mat4 | hi all |
| 21:03:01 | flaviu | Wait, I guess that strategy would work there too. |
| 21:03:02 | ldlework | flaviu: this is not valid nim code |
| 21:03:23 | flaviu | ldlework: It would be if forward declarations were optional. |
| 21:03:23 | ldlework | oh |
| 21:03:32 | ldlework | flaviu: right I see what you're doing |
| 21:03:37 | ldlework | yeah, this is the actual challenging example |
| 21:03:42 | ldlework | and I do think the pass would work here too |
| 21:04:03 | ldlework | I mean, insofar as "rembmer that things exist before you compile" means anything |
| 21:04:07 | Mat4 | hiow can I translate C preprocessor declarations like '#ifdef __i386__' to Nim ? |
| 21:04:11 | * | drewsrem quit (Quit: Leaving) |
| 21:04:11 | ldlework | I have no fucking clue how compilers and shit work |
| 21:04:30 | ldlework | Mat4: "when" ? |
| 21:04:47 | Araq | Mat4: depends, but for this case 'when defined(i386)' |
| 21:04:54 | Mat4 | thanks |
| 21:05:12 | flaviu | Mat4: and system.hostCPU is available if you need a string |
| 21:05:43 | flaviu | I guess you could do `when hostCPU == "i386"` |
| 21:05:56 | Araq | speaking of which |
| 21:06:07 | Araq | Varriount thinks these should become enums |
| 21:06:15 | Araq | and I agree |
| 21:07:08 | flaviu | It'd add some type safety to it, it's not a bad idea |
| 21:08:18 | flaviu | ldlework: A compiler is simply "text -> (ast ->)* target" |
| 21:08:26 | ldlework | 'simply' |
| 21:08:28 | ldlework | :) |
| 21:08:32 | flaviu | ;) |
| 21:09:16 | Araq | ldlework: even if your scheme ultimately does work out somehow, it's min a full year of my time to get it reasonably stable |
| 21:10:08 | ldlework | Araq: which is fine because forward type delcarations are coming a lot sooner and those fine |
| 21:10:14 | ldlework | ...right |
| 21:10:16 | ldlework | :) |
| 21:10:21 | Araq | right. |
| 21:10:47 | ldlework | It kind of seems like that system is really just an automatic forward declaration system |
| 21:11:14 | flaviu | https://gist.github.com/94b064f08247bb8203df is even more pathological. First, forward declare obvious symbols. Then expand macros. Then run another forward-declaration pass. |
| 21:11:24 | flaviu | And think of macro-generating macros :O |
| 21:12:10 | Araq | flaviu: maybe it's just a fixpoint iteration |
| 21:12:39 | Araq | but it's not worth the trouble for 1.0 and neither for 2.0 |
| 21:13:19 | flaviu | I'm not familiar with "fixed point iteration". Does that mean to repeat the process until it becomes stable and stops changing? |
| 21:13:33 | Araq | exactly |
| 21:14:33 | Araq | find the x so that x = f(x) |
| 21:15:00 | flaviu | ok, makes sense. |
| 21:15:18 | flaviu | is there a way to apply a macro on a whole module? |
| 21:16:18 | Araq | only if you put the whole module into mymacro: ... |
| 21:17:48 | * | johnsoft quit (Ping timeout: 245 seconds) |
| 21:18:02 | Araq | or you do parseStmt(slurp"foo.nim") |
| 21:20:46 | * | johnsoft joined #nimrod |
| 21:21:03 | Araq | ldlework: so how should the syntax look like for forward decls? |
| 21:21:29 | Araq | type Foo = ref module.Bar # <- resolve later, but know it's a 'ref'? |
| 21:21:49 | Araq | we need to do it like C/C++ |
| 21:22:15 | Araq | we require a ptr/ref indirection so that the compiler can do *some* things with it |
| 21:37:33 | * | shevy joined #nimrod |
| 21:37:49 | shevy | when will you guys move to #nim? :D |
| 21:38:12 | Araq | nobody knows |
| 21:38:17 | Araq | this year |
| 21:38:25 | shevy | hehe |
| 21:38:46 | Joe_knock | We could register #nim for now |
| 21:42:12 | * | brson quit (Quit: leaving) |
| 21:42:30 | * | brson joined #nimrod |
| 21:47:18 | * | brson quit (Ping timeout: 264 seconds) |
| 22:01:10 | flaviu | I think dom's already got #nim |
| 22:01:35 | shevy | more action here on #nimrod |
| 22:01:54 | flaviu | yes. |
| 22:03:33 | reactormonk | Joe_knock, I asked Araq for the channel forward, he said not yet |
| 22:03:56 | shevy | let's fight the splitters on #nim! |
| 22:04:08 | Joe_knock | Where we work from doesn't matter too much, it's just to block trolls |
| 22:04:08 | shevy | like #ruby vs. #ruby-lang ! |
| 22:04:26 | flaviu | I think that he just needs to have a chat with staff, and they can set up the redirect |
| 22:04:32 | Araq | reactormonk: well we still haven't released Nim |
| 22:04:45 | reactormonk | shevy, apeiros apparently has op in one of them but had to promise not to merge them. |
| 22:05:04 | reactormonk | Araq, your choice when to do it. |
| 22:06:37 | shevy | X-mas release! |
| 22:07:53 | flaviu | reactormonk: Nope, dom96 owns both the channels |
| 22:08:10 | flaviu | reactormonk: nm, I misunderstood |
| 22:08:16 | reactormonk | flaviu, it's not like he'll run amok anytime soon |
| 22:09:44 | * | bjz quit (Ping timeout: 256 seconds) |
| 22:09:45 | Joe_knock | If sqlite is in the libs, do I need an adapter for it? |
| 22:10:05 | * | brson joined #nimrod |
| 22:10:50 | flaviu | Joe_knock: I use the sqlite module without knowing what an "adapter" is, so I guess you don't. |
| 22:11:12 | Joe_knock | awesome flaviu |
| 22:11:14 | Joe_knock | thanks |
| 22:14:57 | Joe_knock | flaviu: Is there an ORM in Nim? |
| 22:15:37 | onionhammer | you can override the dot operator Joe_knock |
| 22:15:41 | flaviu | I've heard people talking about making one, I'm not sure if someone's published one yet. |
| 22:15:41 | flaviu | SQL is quite fun to play with though. |
| 22:16:05 | onionhammer | mydatabaseobject.mycolumn could translate to mydatabaseobject["mycolumn"] :p |
| 22:16:16 | Joe_knock | I'm going to be hijacking code from the todo app someone already wrote then. |
| 22:16:17 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 22:18:54 | Araq | not sure I want an ORM or simply check the SQL at compile time |
| 22:19:52 | * | Mat4 quit (Remote host closed the connection) |
| 22:20:56 | Joe_knock | an ORM will be *slower*, but useful for people using Jester to build small things quickly. |
| 22:21:53 | EXetoC | bacon |
| 22:23:33 | Araq | dunno. I always ended up dumping the ORM |
| 22:24:05 | Araq | IO is not something you can reasonably abstract over |
| 22:24:30 | Joe_knock | Luckily a TODO has already been written, this is helping my small project. |
| 22:24:41 | Araq | it *matters* when something is written to the DB |
| 22:26:07 | Joe_knock | How much performance will smaller projects really need? |
| 22:26:19 | Araq | it's not about performance |
| 22:26:35 | Araq | it's about correctness and predictability |
| 22:26:47 | Araq | but go ahead, ORMs are cool |
| 22:27:40 | Joe_knock | Araq: don't get cross :P |
| 22:27:47 | Araq | just because I personally prefer to work differently doesn't mean you shouldn't do it! |
| 22:29:50 | * | Araq talks to much |
| 22:31:05 | Araq | what? we do have system.currentSourcePath()? |
| 22:31:34 | * | Mat4 joined #nimrod |
| 22:32:19 | * | enquora quit (Quit: enquora) |
| 22:35:44 | * | Mat4 sad, only view lines without obvious flaws, bugs because of side effects or assumptions about undefined compiler behaviours (inclusive buffer overflows) |
| 22:48:03 | Araq | Joe_knock: want to know how I'd do an ORM? |
| 22:48:34 | Araq | Mat4: you're sad because you cannot see code with flaws? |
| 22:51:22 | Joe_knock | I'm keen to know, although I'm currently stuck on trying to figure out how to port these procs to routes |
| 22:51:28 | Joe_knock | Araq: ^ |
| 22:52:28 | Mat4 | Araq: I'm tired because of these damn, braind****** bloddy sh** sources full of obvious errors in these dam* C compiler crap |
| 22:52:36 | Araq | ask the database for the model, generate Nim code. not necessarily with the macro system since we currently cannot cache these things easily |
| 22:52:47 | EXetoC | heh |
| 22:52:48 | Araq | Mat4: tiny C is a bitch, yeah |
| 22:53:13 | * | Mat4 sitting here 5 hours after work only bug fixing all kind of errors |
| 22:54:13 | ldlework | EXetoC: let me know if you get time to look at nimple |
| 22:54:21 | ldlework | flaviu: so what's the status of nimlets? |
| 22:54:39 | Joe_knock | onionhammer: Would it be possible to call a proc inside a route? |
| 22:54:44 | flaviu | ldlework: I'm not too sure how the discount wrapper I found works, so I'm re-wrapping it. |
| 22:54:48 | Araq | and even more important: what IS a nimlet? |
| 22:54:55 | ldlework | what's a discount wrapper? |
| 22:55:05 | ldlework | Araq: a self-contained example of Nim code |
| 22:55:16 | ldlework | Araq: we created nimlets.github.io |
| 22:55:20 | ldlework | well |
| 22:55:25 | ldlework | flaviu: did |
| 22:55:43 | flaviu | ldlework: heh. http://www.pell.portland.or.us/~orc/Code/discount/ |
| 22:56:28 | ldlework | hmm, so we're going with markdown? |
| 22:56:52 | willwillson | I thought, by "discount", you meant poor quality :D |
| 22:57:16 | ldlework | I don't think so, Tim. |
| 22:57:26 | flaviu | ldlework: hmm? |
| 22:57:41 | ldlework | flaviu: I thought the files were going to be actually nim source files |
| 22:57:48 | flaviu | Yes, they are going to be nim files |
| 22:57:57 | ldlework | alright I'll just see what you come up with :) |
| 22:57:59 | flaviu | https://github.com/nimlets/nimlets.github.io/blob/master/snippets/test.nim |
| 22:58:07 | flaviu | That's essentially what I want to target. |
| 22:58:11 | ldlework | ah |
| 22:58:14 | ldlework | that's legit |
| 22:58:35 | ldlework | then you'll generate an html file from that markdown and embed the code in a syntax highlighted form? |
| 22:58:37 | ldlework | ;) |
| 22:58:44 | flaviu | yes, that's the plan |
| 22:58:52 | ldlework | that's gonna be pretty badass honestly |
| 22:59:39 | * | letsgodoge left #nimrod (#nimrod) |
| 23:01:33 | Joe_knock | This is getting tricky rather quickly. Time to find a template engine |
| 23:02:49 | ldlework | Joe_knock: working on Jester? |
| 23:03:13 | EXetoC | see the forums |
| 23:03:17 | * | brson quit (Ping timeout: 240 seconds) |
| 23:03:43 | Joe_knock | ldlework: yeah. I'm taking code from the current todo app and making a nice RESTful type todo app |
| 23:05:27 | onionhammer | Joe_knock nimble install templates |
| 23:05:47 | Araq | er guys |
| 23:05:56 | Araq | if you're enjoying these things |
| 23:06:06 | Araq | how about improving the docgen instead? |
| 23:07:24 | * | perturbation joined #nimrod |
| 23:07:45 | onionhammer | Joe_knock yes you can install a proc inside a route |
| 23:08:20 | Joe_knock | onionhammer: What about calling a proc within a route but keeping them separate? |
| 23:08:40 | onionhammer | what? |
| 23:09:32 | Joe_knock | Let me demonstrate |
| 23:11:28 | EXetoC | ldlework: maybe in a week or so |
| 23:12:21 | Joe_knock | onionhammer: https://pastee.org/787sh |
| 23:12:58 | Joe_knock | of course, there is missing HTML that I can add there |
| 23:13:29 | onionhammer | afaik resp is going to be expecting a string.. |
| 23:13:38 | onionhammer | not a ref TTodo |
| 23:14:00 | onionhammer | it looks like you're thinking too hard about it |
| 23:14:34 | Joe_knock | I'm trying to apply DRY here and do a cookie-cutter |
| 23:17:35 | Joe_knock | Unless I can "call" the proc when a get / request is made |
| 23:17:57 | * | gokr_ quit (Ping timeout: 240 seconds) |
| 23:18:10 | * | dts|pokeball quit (Ping timeout: 258 seconds) |
| 23:18:47 | onionhammer | why wouldn't you call it when the request is made? |
| 23:19:02 | ldlework | Just implement $ for TTodo |
| 23:19:07 | ldlework | and stop using T/P prefixes |
| 23:19:17 | onionhammer | agreed.. |
| 23:19:43 | onionhammer | but I woudlnt do $ for TTodo, I would have separation between your "view" and your "model" |
| 23:19:52 | ldlework | Sure fine |
| 23:19:54 | ldlework | :) |
| 23:19:58 | ldlework | $ is the view |
| 23:21:05 | ldlework | Not a very featureful view... but still |
| 23:21:07 | ldlework | hehe |
| 23:22:19 | Joe_knock | I'm a bit lost now. What does $ mean? |
| 23:23:01 | ldlework | Joe_knock: $ is the 'convert this thing to a string' operator |
| 23:23:31 | onionhammer | Joe_knock maybe like this : https://gist.github.com/onionhammer/edf5f064797a5bae1292 |
| 23:24:02 | onionhammer | Idlework the point is that you could have multiple views that use the same model |
| 23:24:16 | onionhammer | i.e. an "update" view or a "delete" view or a "deleteconfirm" view etc |
| 23:24:23 | Mat4 | ciao |
| 23:24:33 | * | Mat4 left #nimrod (#nimrod) |
| 23:25:14 | * | Trustable quit (Quit: Leaving) |
| 23:26:17 | wan | my view of ORMs is that they always end up looking like and needing to reimplement SQL in their own way |
| 23:27:03 | ldlework | onionhammer: sure, $ is just one, simple view - you're still hardcoding a view so its literally the same thing with a different proc name |
| 23:27:33 | onionhammer | in my example it could be $ instead of "view", sure |
| 23:27:56 | onionhammer | but in more sophisticated code you may not want to use that pattern |
| 23:28:31 | wan | Joe_knock: I prefer having a module that abstracts the db and I create a simple API for the model, like https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Nimrod/nawak/model_postgre.nim |
| 23:30:50 | Joe_knock | wan: What is the performance output for the benchmark now? |
| 23:32:01 | willwillson | and when is the next round taking place? :D |
| 23:32:04 | wan | We'll see next round. Jester will probably drop, as the json route in async is slower than the previous version |
| 23:32:21 | wan | I have no idea when, it was supposed to be at the end of july |
| 23:32:25 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 23:32:45 | Joe_knock | darn, I thought we'd go above Java in the next round |
| 23:33:36 | * | AMorpork is now known as AFKMorpork |
| 23:33:53 | wan | I expect good results for nawak with the multiple queries, fortunes and updates. json and plaintext are not good, cause nawak+Mongrel2 has more layers |
| 23:34:12 | wan | so it has an low upper bound for these two |
| 23:35:11 | wan | *more layers than all the other frameworks like go and so that don't use a front-end server |
| 23:37:15 | wan | I think we'll be quite close to java for multiple queries, fortunes and updates |
| 23:37:45 | Araq | this whole thing is stupid. we picked the hardest route one can possibly pick and then lose in the benchmarks |
| 23:37:59 | wan | hardest route? |
| 23:38:05 | Joe_knock | wan: I didn't even know there was another web framework for Nim :( |
| 23:38:32 | wan | it's experimental, some stuff are missing |
| 23:38:38 | Araq | so, we implemented async+await via macros and which uses closure iterators all over the place which puts high pressure on the GC |
| 23:38:38 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 23:38:47 | ldlework | onionhammer: I agree |
| 23:39:05 | Araq | and the result is a framework that pleasing on the eye and nice to use |
| 23:39:20 | Araq | but not optimized for performance really except that it's "async" |
| 23:40:04 | * | brson joined #nimrod |
| 23:40:20 | wan | async is important if you don't have a front-end server and if you only want to run `nb of cores` threads |
| 23:40:20 | Joe_knock | Araq: Are you referring to Jester? |
| 23:40:37 | Araq | I'm refering to Jester + our async core |
| 23:41:06 | wan | but nawak gets away without using async because it uses lots of threads |
| 23:41:18 | Joe_knock | I would think performance is one of the critical things we should be winning at and not losing to Java |
| 23:41:18 | onionhammer | Araq so whats the plan to resolve that? |
| 23:42:04 | Araq | what we could have done instead: |
| 23:42:08 | Araq | port fast async C stuff over to Nim and call it a day |
| 23:42:32 | wan | the best bet is porting lwan |
| 23:42:38 | wan | it's super fast |
| 23:42:42 | wan | and clean implementation |
| 23:43:00 | Araq | --> wins the benchmarks and nobody cares if the code under the hood uses malloc or GC |
| 23:43:19 | wan | however you'd have to pay attention when trying to have the db pool correct |
| 23:43:29 | ldlework | Araq: you're a reasonable guy |
| 23:43:33 | Araq | or picothreads with inline assembler to swap stacks |
| 23:44:48 | wan | the json and plaintext tests are not useful anyway. I asked for the benchmarks page to be changed to single query by default |
| 23:45:12 | Joe_knock | I think JSON tests are fair |
| 23:45:32 | wan | they do measure something, like overhead |
| 23:45:48 | Araq | I can easily speed up our Json parser by on order of magnitude |
| 23:45:58 | ldlework | they measure your json lib in addition to your server, its dumb |
| 23:46:00 | Joe_knock | wan: Is your framework more Flask, less Sinatra? |
| 23:46:01 | wan | however they don't measure a performance you're gonna get on a website. Because all websites use the database |
| 23:46:04 | ldlework | why benchmark something you can swap out? |
| 23:46:19 | ldlework | here, let me write a json module that returns exactly the expected output, statically |
| 23:46:25 | ldlework | tada, bye bye overhead of that test |
| 23:46:48 | wan | Joe_knock: I don't really know Sinatra, Flask is my reference point |
| 23:47:15 | Joe_knock | oh, so the benchmark is calling it raw. I should've said "JSON test is fair called from a standard NoSQL DB" |
| 23:47:20 | wan | Araq: there is no json parsing test yet |
| 23:47:27 | Araq | oh ok |
| 23:47:28 | wan | only json output |
| 23:47:41 | wan | and I used a custom stuff for that |
| 23:47:44 | Araq | well i can speed up generating json too |
| 23:47:46 | wan | it takes a tuple as imput |
| 23:47:49 | wan | input* |
| 23:49:05 | wan | ldlework: the rules are that it should happen at runtime, otherwise it doesn't measure a difference between json and plaintext |
| 23:49:26 | Joe_knock | If that is the case with the benchmark, then screw it. As long as the frameworks outperform *some* of the other competitive languages, nim will be very useful for web apps |
| 23:51:27 | wan | Araq: I don't mind you optimizing json stuff (it would help in https://github.com/kostya/benchmarks), but it wouldn't impact techempower's bench. However you might concentrate on other more important stuff |
| 23:51:53 | Araq | indeed, I'm not doing these things |
| 23:53:12 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 23:53:13 | * | Etheco quit (Quit: Leaving) |
| 23:54:03 | wan | Joe_knock: my goal was to have something that beats ruby, python, node and gets as close as I can to other compiled stuff without being too long to implement, while having a really clean flask-like look |
| 23:54:27 | wan | *and beats php |
| 23:55:08 | Araq | wan: btw did you port your code to Nim 0.10.x ? |
| 23:55:36 | wan | I don't mind that other languages have fast frameworks, they can look horrible to get there (example: cpoll) |
| 23:55:48 | Joe_knock | interesting wan, I seem to be a bit misplaced on Sinatra/Jesters way of doing things |
| 23:55:49 | wan | Araq: yes, it should be |
| 23:56:29 | Araq | I don't even know that our low level solution would look horrible |
| 23:56:39 | * | vendethiel joined #nimrod |
| 23:57:05 | Araq | my gut feeling is that we can polish that quite a bit with templates |
| 23:57:07 | wan | I'm more talking about the framework's user point of view |
| 23:57:17 | Araq | yeah, me too |
| 23:59:03 | Araq | on the other hand ... we might get a region based way of doing memory management soon and then we can win with our high level stuff too |
| 23:59:25 | wan | because async closures would be a lot faster? |
| 23:59:36 | Araq | yeah |
