| 00:07:46 | * | dhasenan quit (Remote host closed the connection) |
| 00:08:28 | Araq | test |
| 00:08:41 | * | dhasenan joined #nim |
| 00:09:12 | shalabh | works |
| 00:09:46 | Araq | indeed |
| 00:11:45 | * | banister joined #nim |
| 00:12:13 | * | reem joined #nim |
| 00:13:47 | * | reem quit (Remote host closed the connection) |
| 00:15:56 | * | fizzbooze quit (Ping timeout: 272 seconds) |
| 00:17:33 | * | ehaliewicz quit (Remote host closed the connection) |
| 00:25:31 | shalabh | random thought: one of nim's biggest strengths is metaprogramming, however that is not mentioned that often in blogs etc. |
| 00:28:16 | def- | shalabh: hm, i think i did a bit of metaprogramming in 2 of my posts |
| 00:28:57 | def- | and i hope the ideas page was more fleshed out after we put some more work into it |
| 00:30:06 | * | shalabh quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 00:31:07 | Araq | ugh do we really need thread local storage emulation for GCC on windows? |
| 00:31:33 | Araq | somebody should check if we can get rid of this now |
| 00:31:54 | * | shalabh joined #nim |
| 00:32:42 | shalabh | def-:your articles are great, btw. |
| 00:32:50 | shalabh | and the ideas page looks pretty good! |
| 00:32:52 | def- | thanks |
| 00:33:18 | shalabh | def-:what I meant was, if you look around and read nim articles, or the homepage, you might not notice the metaprogramming power. |
| 00:36:13 | Araq | good night |
| 00:36:23 | shalabh | good night |
| 00:36:57 | * | Outlande1 joined #nim |
| 00:38:49 | * | Outlander quit (Ping timeout: 264 seconds) |
| 00:41:17 | shalabh | how do i rebuild Nim after git pull? |
| 00:41:24 | def- | ./koch boot -d:release |
| 00:41:30 | shalabh | hm, did that |
| 00:41:32 | def- | that should be documented |
| 00:41:35 | shalabh | maybe 0.10.2 is the latest |
| 00:41:52 | shalabh | def-: that would be useful in the 'how i start' article |
| 00:42:04 | def- | oh, you'll have to checkout the devel branch and bootstrap from there |
| 00:42:28 | shalabh | can't install c2nimUnsatisfied dependency: nim (>= 0.10.3) |
| 00:42:28 | shalabh | ok |
| 00:42:36 | def- | shalabh: right, totally forgot |
| 00:42:53 | * | kniteli quit (Quit: Leaving) |
| 00:43:40 | * | kniteli joined #nim |
| 00:43:47 | * | reem joined #nim |
| 00:48:50 | * | reem quit (Remote host closed the connection) |
| 00:54:00 | * | Menche joined #nim |
| 00:58:10 | * | fizzbooze joined #nim |
| 00:59:01 | * | shalabh quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 01:05:57 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 01:12:10 | * | infinity0_ joined #nim |
| 01:12:10 | * | infinity0_ quit (Changing host) |
| 01:12:10 | * | infinity0_ joined #nim |
| 01:12:10 | * | infinity0 is now known as Guest56195 |
| 01:12:10 | * | Guest56195 quit (Killed (weber.freenode.net (Nickname regained by services))) |
| 01:12:10 | * | infinity0_ is now known as infinity0 |
| 01:15:12 | * | reem joined #nim |
| 01:21:36 | * | banister quit (Read error: Connection reset by peer) |
| 01:35:19 | * | gsingh93 quit (Ping timeout: 264 seconds) |
| 01:41:09 | * | Outlande1 quit (Ping timeout: 244 seconds) |
| 01:41:46 | * | banister joined #nim |
| 01:41:55 | * | banister quit (Max SendQ exceeded) |
| 01:43:13 | * | Outlander joined #nim |
| 01:46:52 | * | darkf joined #nim |
| 01:50:24 | * | gsingh93 joined #nim |
| 01:52:29 | * | banister_ joined #nim |
| 01:52:35 | * | banister_ quit (Max SendQ exceeded) |
| 02:05:35 | * | chemist69_ joined #nim |
| 02:08:55 | * | chemist69 quit (Ping timeout: 264 seconds) |
| 02:12:48 | * | fizzbooze quit (Ping timeout: 265 seconds) |
| 02:14:48 | darithorn | nim was complaining about invalid indentation when the problem was with a semi-colon. O.o |
| 02:15:51 | * | fizzbooze joined #nim |
| 02:34:14 | * | Trustable quit (Remote host closed the connection) |
| 02:34:59 | * | saml_ joined #nim |
| 02:36:04 | * | johnsoft quit (Ping timeout: 245 seconds) |
| 02:36:24 | * | johnsoft joined #nim |
| 03:10:11 | * | reem quit (Remote host closed the connection) |
| 03:17:14 | * | reem joined #nim |
| 03:34:29 | * | reem quit (Remote host closed the connection) |
| 03:37:29 | * | brson quit (Quit: leaving) |
| 03:48:13 | * | reem joined #nim |
| 04:16:03 | * | Demon_Fox_ joined #nim |
| 04:16:13 | * | Demon_Fox quit (Ping timeout: 252 seconds) |
| 04:36:54 | * | Menche quit (Ping timeout: 245 seconds) |
| 04:41:51 | * | Menche joined #nim |
| 04:43:09 | * | fizzbooze quit (Quit: WeeChat 1.1.1) |
| 04:44:08 | * | kuzy000_ joined #nim |
| 04:44:25 | * | Outlander quit (Quit: leaving) |
| 05:00:46 | * | kuzy000_ quit (Remote host closed the connection) |
| 05:10:30 | * | brson joined #nim |
| 05:13:17 | fowl | def-, you can move the macro outside as a compiletime function for parseenum |
| 05:43:33 | * | Menche quit (Quit: Leaving) |
| 05:52:37 | * | rkj-b joined #nim |
| 05:54:52 | * | rkj-b quit (Client Quit) |
| 06:08:52 | * | saml_ quit (Remote host closed the connection) |
| 06:33:32 | * | girvo quit (Quit: leaving) |
| 06:34:47 | * | bjz joined #nim |
| 06:37:09 | * | gsingh93 quit (Ping timeout: 250 seconds) |
| 06:55:11 | * | sillesta joined #nim |
| 06:57:59 | * | brson quit (Read error: Connection reset by peer) |
| 06:58:34 | * | Menche joined #nim |
| 07:00:45 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 07:17:59 | * | chemist69_ quit (Quit: WeeChat 1.1.1) |
| 07:18:09 | * | chemist69 joined #nim |
| 07:19:33 | * | infinity0 quit (Ping timeout: 252 seconds) |
| 07:20:30 | * | Demon_Fox_ quit (Quit: Leaving) |
| 07:21:33 | * | reem quit (Remote host closed the connection) |
| 07:22:43 | * | reem joined #nim |
| 07:23:33 | * | infinity0 joined #nim |
| 07:25:02 | * | reem quit (Remote host closed the connection) |
| 07:32:49 | * | reem joined #nim |
| 07:34:57 | * | darithorn left #nim ("Leaving") |
| 07:36:46 | * | reem quit (Remote host closed the connection) |
| 07:37:40 | * | reem joined #nim |
| 07:39:35 | * | reem quit (Remote host closed the connection) |
| 07:42:59 | * | reem joined #nim |
| 07:44:10 | * | zahary joined #nim |
| 07:45:34 | * | reem quit (Remote host closed the connection) |
| 07:47:15 | * | filwit joined #nim |
| 07:48:05 | filwit | whoohoo! my NimKate colors are working great in Aporia and are better than ever :D |
| 07:49:26 | filwit | damn, fuzzbuzz isn't around, I was hoping to drop him a note |
| 07:52:43 | * | reem joined #nim |
| 07:56:08 | * | reem quit (Remote host closed the connection) |
| 07:58:07 | * | nulpunkt joined #nim |
| 07:58:23 | * | reem joined #nim |
| 08:05:21 | * | filwit quit (Quit: Leaving) |
| 08:10:18 | * | bjz joined #nim |
| 08:21:06 | * | bjz quit (Ping timeout: 246 seconds) |
| 08:33:50 | * | BlaXpirit joined #nim |
| 08:43:11 | * | chemist69 quit (Quit: WeeChat 1.1.1) |
| 08:53:16 | * | bjz joined #nim |
| 09:01:36 | * | chemist69 joined #nim |
| 09:08:12 | * | tumult joined #nim |
| 09:08:20 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 09:10:08 | * | BlaXpirit joined #nim |
| 09:27:01 | * | reem quit (Remote host closed the connection) |
| 09:33:37 | * | infinity0 quit (Ping timeout: 245 seconds) |
| 09:34:02 | * | onionhammer quit (Ping timeout: 245 seconds) |
| 09:38:03 | * | reem joined #nim |
| 09:38:43 | * | infinity0 joined #nim |
| 10:07:38 | * | Trustable joined #nim |
| 10:28:24 | * | reem quit (Remote host closed the connection) |
| 10:31:07 | * | reem joined #nim |
| 10:33:36 | * | MajorWork joined #nim |
| 10:35:48 | * | MajorWork quit (Client Quit) |
| 10:35:57 | * | reem quit (Ping timeout: 265 seconds) |
| 10:36:08 | * | MajorWork joined #nim |
| 10:37:08 | * | MajorWork quit (Remote host closed the connection) |
| 10:37:19 | * | MajorWork joined #nim |
| 10:37:24 | * | sillesta quit (Ping timeout: 265 seconds) |
| 10:37:43 | * | MajorWork quit (Remote host closed the connection) |
| 10:37:52 | * | TennisMajor joined #nim |
| 10:38:23 | * | TennisMajor quit (Client Quit) |
| 10:38:35 | * | jm116__ joined #nim |
| 10:38:59 | * | jm116__ quit (Changing host) |
| 10:38:59 | * | jm116__ joined #nim |
| 10:43:05 | novist | im nearly done with my macro constructor thing. not sure what else could be improved. i would love to hear some opinions: http://forum.nim-lang.org/t/703/4#5519 |
| 10:52:50 | Araq | "Debugging was a big problem for me." why do have people trouble with debugging? |
| 10:53:16 | Araq | I keep hearing this complaint but I cannot see why it's painful |
| 10:54:28 | novist | there is nothing to debug with |
| 10:54:39 | novist | not everyone is gdb wizard |
| 10:54:54 | novist | people are used to modern debuggers integrated into IDE.. |
| 10:56:07 | novist | and honestly... its easier to live without autocomplete in IDE than without debugger. even learning process becomes so much easier when one can swiftly inspect state of program |
| 10:56:41 | Araq | ? there are lots of frontends for gdb ... |
| 10:57:12 | novist | will they walk through nim src code? |
| 10:57:14 | Araq | novist: new_ident_node("new") should be bindSym"new" |
| 10:57:23 | Araq | why wouldn't they? |
| 10:57:47 | novist | i have no idea how it works, figured if its compiled through c then one would be debugging c, not nim |
| 10:58:26 | novist | whats the difference between bindSym and ident? |
| 10:58:49 | Araq | ident is dirty: |
| 10:58:57 | Araq | var new = 0 # ooopps |
| 10:59:32 | Araq | now your macro picks my int var named 'new' |
| 11:00:13 | novist | i see. i just implemented w/e ast was dumped to me by dump_tree hehe |
| 11:00:48 | Araq | same applies to your 'compiles' usage and other things |
| 11:02:02 | Araq | but 'init' is tricky, you need bindSym("init", brForceOpen) |
| 11:02:27 | Araq | correct macros are hard to write ;-) |
| 11:03:16 | novist | so it seems.. i tried to look for way to make it into template but so far does not seem like it could work |
| 11:03:30 | Araq | nope, cannot work |
| 11:04:06 | Araq | but we could at least improve the documentation and make 'ident' calls not as easy to write ... |
| 11:04:12 | novist | although with bindSym on init i get compat.nim(17, 16) Error: undeclared identifier: 'init' |
| 11:04:42 | novist | yeah moving init before macro fixes it |
| 11:04:42 | Araq | yeah that's unfortunate, I think you need to intoduce a dummy init |
| 11:05:34 | novist | dummy being template too i suppose? |
| 11:07:29 | Araq | nah, moving init before the macro is fine |
| 11:08:16 | Araq | btw there is --debuginfo --lineDir:on |
| 11:08:28 | Araq | and then the debugger knows about Nim source code |
| 11:08:45 | Araq | it's not perfect but perfectly workable |
| 11:08:55 | Araq | in my experience |
| 11:09:51 | Araq | but in my experience debuggers fail anyway when you go beyond toys as the support for *conditional* breakpoints and watchpoints etc is just too weak |
| 11:10:42 | Araq | in contrast to debuggers, IDE tools like "goto definition" do scale |
| 11:10:57 | Araq | so I think our priorities are exactly right |
| 11:12:23 | novist | one thing i noticed about conditional breakpoints is that they are slow. so even if they work i rarely use them.. adding bit of code with condition and normal breakpoint inside works just fine hehe |
| 11:16:12 | novist | i imagine dummy proc should be like this: proc init_proxy[T](self: var T, args: varargs[expr]) |
| 11:16:29 | novist | there T is object type. but how can i "unpack" varargs passing to real init()? |
| 11:17:07 | novist | init(self, **args) is something i would write in python in such case |
| 11:22:46 | * | dumdum joined #nim |
| 11:27:10 | Araq | novist: unpacking has to be done in the macro |
| 11:27:52 | Araq | novist: exactly but when you add an 'if' in your code for debugging, you might as well add 'echo' and 'writeStackTrace()' |
| 11:28:47 | novist | sure, but then you cant step through the code and inspect state carefully. adding if/echo after every statement is just not practical |
| 11:29:42 | novist | im pretty sure you can get away without needing that too much, but everyone's skills are different. most of people dont write programming language written in same programming language if you know what i mean ;) |
| 11:29:52 | Araq | I guess I suck at steppig through. it takes too much time to decided whether to step *over* a proc call or step *into* it |
| 11:29:58 | Araq | *to decide |
| 11:30:35 | Araq | also this is all backwards anyway, what a real debugger should do is to go back in time |
| 11:30:50 | Araq | there are a couple of research debuggers that can do that |
| 11:30:56 | novist | you know such things exist actually ;) |
| 11:31:15 | Araq | but last time I checked they were still unusable |
| 11:31:16 | novist | i saw vmware people demo such thing, you run app, let it crash, then can debug saved vm state |
| 11:32:04 | wb | iirc MSVS made an attempt at that with the C# debugger, not sure how far it went |
| 11:32:08 | novist | IDA can do similar thing too, but no memory is available for inspection, just registers |
| 11:32:39 | fowl | novist, you can pass varargs[expr] to a macro |
| 11:32:53 | fowl | but its unusable from a template |
| 11:33:20 | novist | i have a macro, see it at http://forum.nim-lang.org/t/703/4#5519 |
| 11:33:28 | Araq | fowl: does the types API work for you now? |
| 11:33:28 | novist | i would love to keep existing syntax because it is most simple |
| 11:33:52 | novist | just cant figure out how to make that init_proxy so it calls real init |
| 11:34:19 | novist | cant define a proxy for every available constructor signature |
| 11:36:12 | fowl | Araq, i havent tried it much |
| 11:39:59 | novist | actually with or without bindSym on init i cant declare "var init = 1" in same scope where init proc is. if i put it under block macro still picks up proc, not declared integer. so i guess its good? |
| 11:42:25 | Araq | well there is some logic in the compiler to prevent the 'var init = 1' case, but it's still a hack with newIdentNode |
| 11:43:16 | fowl | i've found that this is the only way to access varargs[expr] usefully from a template https://gist.github.com/fowlmouth/fc0eae2bb228c888006e |
| 11:44:27 | fowl | maybe a splat operator could be made with that |
| 11:50:01 | novist | Araq: would you support adding to stdlib operator "+" and "+=" overloads for string/char concatenation? |
| 11:50:27 | def- | novist: & and &=/add? |
| 11:51:25 | novist | yeah i know of them, but they dont feel natural for people without delphi/pascal background |
| 11:51:32 | novist | since most of other sane languages use + |
| 11:51:38 | novist | not talking about php here.. its not sane :| |
| 11:52:32 | def- | I like them more than + and I never used delphi/pascal before. For me it just removes the confusion of whether someone is mathematically adding or concatenating strings |
| 11:54:02 | novist | well in my mind & is bitwise operation which makes no sense at all. and adding string to other string is like tieing strings together |
| 11:54:22 | novist | anyway would there be any harm to have both? atm +/+= for strings/chars are not overloaded |
| 11:54:36 | novist | cant think of what harm it would do to have both |
| 11:54:58 | def- | var x = someNumber + someOtherNumber |
| 11:55:16 | def- | now you have to check what type someNumber and someOtherNumber are before understanding what's happening there |
| 11:55:26 | fowl | Araq, gettype would be perfect if it could read object types |
| 11:56:16 | fowl | i'm going to put it to use in entoody |
| 12:00:05 | ruzu | ms just mit-licensed their coreclr, and i just git cloned it and built it without a hitch on linux. the world is upside down. |
| 12:00:12 | novist | def-: this reminds me argument for hungarian notation. while its true its not convincing because most of the time its pretty clear what types are. even more so with modern IDEs (which dont support nim yet :() |
| 12:00:50 | flaviu | novist: Honestly I was in the same place re. gdb. But it's really not that bad, I just had to memorize ~5 commands and I could just look everything else up. |
| 12:00:57 | novist | ruzu: i read there even was a period of build passing on linux and failing on windows. world is certainly upside down lol |
| 12:01:34 | novist | flaviu: i agree job gets done. but with debugger like in VS it gets done 10 times faster. thats all.. |
| 12:03:07 | novist | imo gdb: https://encrypted-tbn3.gstatic.com/images?q=tbn:ANd9GcSgX9XMb9p_7VIR97iT2nGDle7mQAalbhfAwYQYSR6xvU2ppg9T28bVBCEk and gdb + IDE: https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcRB8NpFrGnhT9ElD-BX5VH0f4IBmWbHUXK7tWuIzg6P508AYujJMNNfnqk |
| 12:03:18 | flaviu | heh. |
| 12:03:36 | novist | i know people are spoiled these days.. |
| 12:03:44 | flaviu | Well, I simply don't make mistakes. That helps me avoid most the hassle of debugging. :P |
| 12:03:56 | novist | easier said than done :D |
| 12:04:09 | * | Matthias247 joined #nim |
| 12:04:25 | novist | hey i got you another argument for need of easy debugger: programmers are lazy and it drives innovation. should we not be lazy we would not need programming languages at all :D |
| 12:04:34 | ruzu | if you watch the "handmade hero" video series, the host is making a game in c+emacs, using visual studio for just the debugging :p |
| 12:05:18 | novist | yeah thats pretty much last piece vim/emacs still dont rly have and its a shame |
| 12:05:32 | tumult | IDE support + debugging is something that will have to come eventually to hit "mainstream" coders. IDE support is okay with what we have but when we have instant code completion and IDE based debugging there'll be a very low barrier of entry to people. |
| 12:05:35 | TEttinger | ruzu, coreclr builds on linux? damn |
| 12:05:42 | TEttinger | can it run anything? |
| 12:06:07 | ruzu | i think it should run just about anything, but i don't have anything to run, lol |
| 12:06:35 | novist | its core, not full .NET stack |
| 12:06:41 | novist | stdlib is limited |
| 12:06:44 | novist | if any |
| 12:07:28 | novist | mono and M$ are pals now though, i bet we gonna see real nice .NET for linux in the future |
| 12:07:41 | novist | i even heard some hopes for visual studio port to linux, that would be sick.. |
| 12:08:07 | novist | if world keeps being upside down in 5 years we gonna see that port and russia take over ukraine lol :| |
| 12:08:30 | ruzu | i wonder if it's this new ceo has anything to do with this, or if that's a coincidence |
| 12:09:03 | flaviu | Lets move this into #nim-offtopic, it isn't really related to nim |
| 12:09:04 | def- | Hm, I can't write my own "inc" implementation and expect `..` to work? |
| 12:24:40 | * | Jehan_ joined #nim |
| 12:26:31 | * | TEttinger quit (Ping timeout: 256 seconds) |
| 12:37:10 | * | akiradeveloper joined #nim |
| 12:47:05 | wb | Personally i don't mind that nim has poor IDE support, it's better than a situation like C# or Java where the language is essentially unusable without a huge IDE |
| 12:48:45 | * | akiradeveloper quit () |
| 12:49:53 | nulpunkt | Hi, can anyone explain this: https://gist.github.com/nulpunkt/190fdbe491672c4fd99d |
| 12:50:07 | nulpunkt | I fail to see why I'm passing the wrong number of arguments in the first example |
| 12:50:42 | novist | resp($o) |
| 12:50:53 | novist | operator precedence is kicking you in the nuts |
| 12:51:03 | nulpunkt | :) |
| 12:51:37 | nulpunkt | so, resp $o is read as resp $ o -> 2 args |
| 12:52:05 | tumult | wb: personally I agree, and I don't mind not having a debugger either right now, but it sure would be nice to have fast code completion 'cos for a newbie, then you don't have to look stuff up all the time in the libraries (or your own code). Not tried sublime code completion tho, only Aporia's. |
| 12:52:07 | nulpunkt | and resp "" & $o is read like resp(`&`("", $(o))) |
| 12:53:30 | * | pafmaf joined #nim |
| 12:53:41 | novist | wb tumult since nim is aiming at gamedev i wonder how manu people would undertake writing entire game in a notepad without solid debugging experience. but wb is right, it could be much worse but isnt. imagine c++ w/o debugging like in qtcreator or vs. that would be painful |
| 12:54:51 | novist | tumult: i think resp $o actually does something like `$`(resp, o) |
| 12:54:58 | wb | tumult: Yeah, code completion is important for a lot of people. Personally i turn it off even in IDEs that have it though: i take it as a challenge to write very consistent and memorable identifiers so I don't have to look anything up. I might just be a weirdo though. |
| 12:54:59 | novist | but ofc operator $ does not take two arguments |
| 12:57:21 | tumult | i am actually writing a toy game/AI project in nim! wb I too write descriptive identifiers, I'm more talking about, say, if I've got a seq being able to press '.' to see all the stuff i can do with a seq without having to look it up |
| 12:58:02 | novist | you wont avoid docs in nim though |
| 12:58:12 | novist | since some things become available only when you import certain modules |
| 12:58:13 | tumult | for a newb this just makes it easier to get going, then you remember those things later on. |
| 12:58:34 | wb | Yeah, that's helpful. Especially with Nim's multimethods, it's easy to forget if you've overloaded something for a type or not. |
| 13:00:30 | tumult | novist: of course, and the nim docs are really good imho, plus I love how most modules have 'when ismainmodule' code so you can see use examples. I'm not saying it's necessary, just more productive. Saves having to stop your flow and look things up, or not even knowing about things to look them up and reinventing the wheel |
| 13:01:37 | novist | yeah its pretty neat, though i personally just grep nim stdlib folder and have few main modules open most of the time so i can look things up. archaic but works :D |
| 13:02:34 | tumult | I feel the same applies to debugging: you can get by with echos & stack traces but there's nothing quite like being able to place a breakpoint on running code to inspect things. |
| 13:03:15 | tumult | my solution has been to collect examples of common stuff in nim in one 'example.nim' unit and refer to that |
| 13:15:18 | tumult | I'll wager a lot of it comes from what you're used to though, I'm a Delphi programmer so I'm used to big, cumbersome IDEs! |
| 13:16:35 | dumdum | I am from big IDEs world too, and so far in nim its been a non problem |
| 13:17:14 | Triplefox | my recurring experience with nim is that i feel like i'm writing something sloppy...but it works pretty quickly and i can read it...so... |
| 13:17:51 | tumult | yeah despite being used to an IDE I use Aporia and get along really well in it |
| 13:27:34 | emilsp | vim and nim is a match made in heaven, it's obvious really. |
| 13:27:53 | wb | Is there a nim wrapper out there for a cross-platform networking library? The enet wrapper is linux-only. |
| 13:32:19 | * | pafmaf quit (Quit: This computer has gone to sleep) |
| 13:41:35 | * | infinity0 quit (Remote host closed the connection) |
| 13:41:51 | * | infinity0 joined #nim |
| 13:47:25 | * | banister joined #nim |
| 13:47:35 | * | banister quit (Max SendQ exceeded) |
| 13:52:59 | novist | what does "Error: illegal capture 'e'" mean? code: result = new_ref Bval(data.substr(e + 1, e + length)) where e is var int proc param, data is string. works if data.substr(e + 1, e + length) is assigned to variable and then passed to Bval().. interestingly i can not reproduce it outside of this proc |
| 13:57:29 | * | saml_ joined #nim |
| 14:04:30 | Araq | novist: you cannot capture a 'var T' in a closure as that would be unsafe |
| 14:04:47 | Araq | novist: and omg no, + is not concatenation |
| 14:05:01 | Araq | btw Delphi uses +, I copied & from Modula 3 :P |
| 14:05:28 | novist | heh, i always assume delphi/pascal is root of all evil :D |
| 14:05:45 | novist | hmm yeah i see.. if it was real solution it would evaluate prior to handling bval |
| 14:05:54 | novist | since its macro hack guess it cant work this way |
| 14:07:51 | * | pafmaf joined #nim |
| 14:10:23 | * | mpthrapp joined #nim |
| 14:10:28 | def- | wb: the networking modules in the stdlib itself are cross-platform |
| 14:11:27 | wb | Yeah, i mean something like raknet or enet |
| 14:12:01 | novist | anyone know if it is possible to provide explicit implementation generic? maybe my logic is flawed but i expect something similar like c++ templates. |
| 14:14:20 | Araq | generics are quite like C++ templates (for better or worse) |
| 14:15:55 | novist | so if i forward-declare "proc test[T](arg: T)" how would i write specific implementation where T=int? |
| 14:16:51 | * | sillesta joined #nim |
| 14:17:34 | Araq | novist: don't forward declare generics. that currently doesn't work at all |
| 14:20:31 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 14:20:53 | novist | im trying here to think of something more workable for that macro. thought maybe with generics i could do something like var a = init[ref Type](...) |
| 14:23:09 | * | BlaXpirit joined #nim |
| 14:32:54 | * | saml_ quit (Quit: Leaving) |
| 14:33:59 | * | darkf quit (Quit: Leaving) |
| 14:39:41 | flaviu | novist: I think that `when arg is int:` should work, not sure though. |
| 14:40:40 | flaviu | .eval proc foo[T](val: T) =; when val is int:; echo "int"; else:; echo "other"; foo(1) |
| 14:40:43 | Mimbus | flaviu: eval.nim(5, 5) Error: invalid indentation |
| 14:41:09 | flaviu | .eval proc foo[T](val: T) =; when val is int:; echo "int"; else:; echo "other"; foo(1) |
| 14:41:12 | Mimbus | flaviu: int |
| 14:43:48 | Araq | fowl: that's exactly what getType supports? |
| 14:46:12 | * | Jehan_ quit (Quit: Leaving) |
| 14:47:13 | * | mpthrapp quit (Remote host closed the connection) |
| 14:48:42 | * | BlaXpirit-UA joined #nim |
| 14:50:42 | * | onionhammer joined #nim |
| 14:51:26 | * | BlaXpirit quit (Ping timeout: 256 seconds) |
| 14:53:10 | novist | flaviu: my goal is to fake constructors so it wont work |
| 14:53:24 | novist | everyone must be able to define their own constructor with arbitrary param length |
| 14:54:41 | * | mpthrapp joined #nim |
| 15:05:01 | * | dom96_ joined #nim |
| 15:15:48 | * | mpthrapp quit (Remote host closed the connection) |
| 15:20:57 | * | mpthrapp joined #nim |
| 15:25:55 | * | irrequietus joined #nim |
| 15:29:59 | flaviu | I'm not sure what you mean. Can you post an example of your target API? |
| 15:31:12 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 15:36:08 | * | OderWat joined #nim |
| 15:37:59 | Araq | hi OderWat welcome |
| 15:38:21 | OderWat | Hi Araq ... was reading the logs last night and thought I should not be to shy of you guys! |
| 15:38:53 | OderWat | and: Hi @ all :) |
| 15:39:03 | dom96_ | hey OderWat :) |
| 15:44:54 | * | irrequietus quit (Ping timeout: 246 seconds) |
| 15:50:43 | * | dom96_ quit (Quit: Page closed) |
| 15:50:50 | * | zahary quit (Quit: Leaving.) |
| 15:57:25 | * | OderWat quit (Quit: Textual IRC Client: www.textualapp.com) |
| 15:57:41 | * | OderWat joined #nim |
| 15:59:22 | Varriount | Hi OderWat |
| 16:00:07 | OderWat | Hi Varriount & dom96_ .. can you verify that I now use the registered nickname? |
| 16:02:23 | Varriount | Yep. You're logged in. |
| 16:02:36 | Varriount | You can use /whois <name> |
| 16:03:06 | OderWat | ty... didn't use an IRC client for about 20? years :) |
| 16:04:52 | Varriount | OderWat: Don't know if you noticed, but I replied to your post in the NimLime thread. |
| 16:13:09 | OderWat | yes I saw that. tracking some nim related stuff in our companies slack as I am very interested in putting it into production. |
| 16:14:02 | OderWat | I fiddled with the sublime syntax files but ran into problems because I just have some meta knowledge about it. I used them in CodeRunner too but they don't really work there. |
| 16:15:17 | OderWat | I think the embedding other languages blocks are what confuses me and the more simple software reading them :) |
| 16:28:57 | * | irrequietus joined #nim |
| 16:31:09 | * | OderWat quit (Quit: Textual IRC Client: www.textualapp.com) |
| 16:31:29 | * | OderWat joined #nim |
| 16:36:09 | * | irrequietus quit () |
| 16:44:28 | Araq | OderWat: you still need to document we allow {} in case branches in our spec ... ;-) |
| 16:46:33 | * | pafmaf quit (Quit: Verlassend) |
| 16:49:16 | OderWat | I would prefer to document some cool enum when behavior too :-P |
| 16:50:09 | OderWat | That said. It was cool to look into the guts of the compiler! |
| 16:58:20 | Araq | well there are a couple of bugs (440!) left that you can look into ... ;-) |
| 17:02:31 | OderWat | Actually I was looking into some of them. |
| 17:13:08 | * | jholland joined #nim |
| 17:18:10 | * | tumult quit (Ping timeout: 246 seconds) |
| 17:22:09 | * | OderWat is now known as OderWat[away] |
| 17:30:28 | * | brson joined #nim |
| 17:33:01 | * | OderWat[away] is now known as OderWat |
| 17:36:11 | OderWat | hmm.. is that automatically changing nickname on away a good thing or more an annoyance to the other people in the channel? |
| 17:40:08 | flaviu | It might get you kicked on other channels, but I don't really care. I filter that sort of thing anyway. |
| 17:40:20 | * | gsingh93 joined #nim |
| 17:44:55 | * | jm116__ quit (Quit: Leaving) |
| 17:45:11 | mpthrapp | Hey, quick question about the graphics library. I'm trying to use fillSurface, but I can't figure out how to pass it a color. I tried using one of the constants in the color module. Do I need to import color in my main .nim? |
| 17:51:44 | mpthrapp | Nevermind, figured it out. Now I just need to figure out how to actually get stuff to display. |
| 18:14:26 | * | Demos joined #nim |
| 18:20:04 | * | Jehan_ joined #nim |
| 18:30:01 | * | Jehan_ quit (Quit: Leaving) |
| 18:32:06 | * | OderWat is now known as OderWat[away] |
| 18:44:14 | * | sillesta quit (Remote host closed the connection) |
| 18:45:50 | * | OderWat[away] is now known as OderWat |
| 18:48:27 | * | dumdum quit (Ping timeout: 256 seconds) |
| 18:53:22 | * | pafmaf joined #nim |
| 18:55:44 | mpthrapp | Could I possibly get someone to take a look at this code? I'm getting a segfault, and I'm not sure why. https://bpaste.net/show/64cb76ab4df8 Thanks. |
| 18:57:46 | def- | mpthrapp: you have to initialize decoded |
| 18:57:56 | mpthrapp | Ohhhh, duh. :P |
| 18:58:16 | def- | mpthrapp: decoded = "" should work |
| 18:58:49 | def- | oh, and you count too far in bytes |
| 18:59:20 | * | BlaXpirit-UA quit (Quit: Quit Konversation) |
| 19:00:13 | mpthrapp | I fixed those, but I'm still not having any luck. :/ https://bpaste.net/show/6dff72a4305e |
| 19:00:30 | def- | mpthrapp: you create "bytes" of a size, then add new elements |
| 19:00:39 | def- | so the first elements in "bytes" are all nullpointers |
| 19:00:55 | mpthrapp | Oh, so instead of .add, I should be doing bytes[x]? |
| 19:01:06 | def- | or create an empty sequence, then you can add to it |
| 19:01:29 | mpthrapp | def-: If I wanted to go the route of adding, do I just not call newSeq first? |
| 19:01:43 | def- | then the seq is not initialized! |
| 19:02:01 | def- | you can call newSeq with 0 as size, or just do "bytes = @[]" |
| 19:02:10 | mpthrapp | Ahhh, okay. Thanks! |
| 19:03:23 | def- | I'm not sure what your code is supposed to do though |
| 19:03:25 | mpthrapp | Perfect, that worked. |
| 19:03:52 | mpthrapp | def-: I'm just working through some programming challenges to get used to the nim syntax. I didn't add the cast to char yet. |
| 19:03:59 | def- | ok |
| 19:04:07 | mpthrapp | def-: It should take a string of binary and convert it to text. |
| 19:15:42 | * | OderWat is now known as OderWat[away] |
| 19:18:14 | * | BlaXpirit joined #nim |
| 19:24:59 | * | NimBot joined #nim |
| 19:28:48 | Varriount | OderWat[away]: We use a plugin that makes writing syntax files a bit easier - it converts the json language files to yaml, then back again. |
| 19:39:16 | def- | Can handle 1.5 million HTTP requests per second in Nim! (all just returning "Hello World"): https://github.com/def-/nim-http-speedup |
| 19:45:09 | Araq | def-: :O what did you do to get these numbers? |
| 19:45:53 | def- | Araq: i used the epoll module directly and start a bunch of threads |
| 19:46:48 | Araq | oh you threw away the stdlib ... yay |
| 19:46:52 | def- | indeed :P |
| 19:47:09 | def- | now have to get these speedups into the stdlib |
| 19:47:30 | def- | oh, and also running it on a 16 core machine helps |
| 19:52:57 | onionhammer | def- awesome !! :) |
| 19:53:06 | * | alexruf joined #nim |
| 19:53:20 | onionhammer | now write a nice web library for it ;) |
| 19:54:00 | * | Mat4 joined #nim |
| 19:54:02 | Mat4 | hello |
| 19:55:08 | def- | onionhammer: I'd prefer to make the existing asynchttpserver faster now |
| 19:55:22 | onionhammer | def- still though, jester is slow |
| 19:55:30 | onionhammer | def- but yeah thats a better use of tim e;) |
| 19:56:05 | onionhammer | need kqueue and iocp support as well |
| 19:56:30 | dom96 | iocp is already implemeneted |
| 19:56:35 | dom96 | *implemented |
| 19:56:43 | onionhammer | right |
| 19:56:46 | onionhammer | but how does it perform |
| 19:56:51 | dom96 | making asynchttpserver faster is definitely the way to go |
| 19:58:54 | def- | i believe asynchttpserver is mostly slow because of string allocations, copies and future allocations |
| 19:59:04 | Mat4 | I think the current sources can get optimized in many directions |
| 20:01:15 | dom96 | I haven't had a chance to optimise either Jester or asynchttpserver at all yet so I'm sure there are many ways one can optimise them. |
| 20:03:24 | * | filwit joined #nim |
| 20:04:43 | Araq | dom96: don't worry, you did an impressive piece of work. I just hope we can speed it up without changing the API ... but I don't see how that's possible :-/ |
| 20:07:00 | Araq | given that jester is all macro based, I think we can keep jester's API and optimize the heck out of it, but I don't see how that's possible for asyncnet and stuff |
| 20:07:16 | dom96 | I don't see what alternative we have to the current API |
| 20:07:52 | def- | not returning strings and futures would be nice |
| 20:08:14 | filwit | dom96: hey man, when you get a chance take a look at the Aporia PR updates |
| 20:08:24 | def- | Ideally for performance I'd want to pass in a string and have it filled |
| 20:08:33 | Araq | def-: yeah but you have no control over .closure iterators' memory allocations |
| 20:08:39 | flaviu | People make fun of rust for constantly breaking backwards compatibility now, but in five years they'll forget all about it. |
| 20:08:53 | flaviu | sorry, brb |
| 20:09:05 | Araq | flaviu: what has this to do with anything? |
| 20:09:58 | * | fizzbooze joined #nim |
| 20:10:12 | Araq | def-: and the compiler cannot move the closures to the stack as they all escape |
| 20:10:18 | filwit | Araq: id like your input on the aporia PR as well, whenever you have time to play with it |
| 20:10:45 | Araq | filwit: I hope you based them on the new-suggest branch |
| 20:10:59 | dom96 | def-: How would you know when the string is filled? |
| 20:11:16 | def- | dom96: when the future is completed |
| 20:11:39 | filwit | Araq: I didn't, but it's style changes only so it should conflict |
| 20:11:50 | dom96 | def-: You would need the string to be allocated for the life time of the future anyway |
| 20:12:02 | dom96 | filwit: Might take a while, very busy right now. |
| 20:12:04 | dom96 | bbl |
| 20:13:00 | filwit | Araq, dom96: no rush, I'm on mobile right now anyways |
| 20:19:21 | * | OderWat[away] is now known as OderWat |
| 20:23:20 | * | aidanh quit (Ping timeout: 264 seconds) |
| 20:25:31 | * | aidanh joined #nim |
| 20:29:41 | Mat4 | I want to return an anonymous function for generating a set of procedures as interface dependent of some initial parameters given. How can that be done in Nim ? |
| 20:31:43 | Araq | pretty much like you describe it: |
| 20:32:01 | Araq | proc factory(x: int): proc (): int = |
| 20:32:14 | Araq | result = proc (): int = x |
| 20:32:40 | Araq | let constant3 = factory(3) |
| 20:32:55 | Araq | echo constant3() # 3! amazing, isn't it? |
| 20:33:06 | Mat4 | yes, it is ! |
| 20:36:22 | Mat4 | now the returned function need only generate a set of procedures |
| 20:38:15 | Mat4 | probably I can use a loop for that |
| 20:44:09 | Araq | dom96: actually looking at asynchttpserver there is lots of room for optimization |
| 20:44:23 | Araq | without changing the API |
| 20:47:19 | def- | Araq: any good ideas? |
| 20:47:29 | dom96 | Araq: Yeah, like I said, I have not optimised at all yet. |
| 20:47:36 | dom96 | I have many ideas. |
| 20:49:23 | dom96 | Rewriting asynchttpserver to use the selectors module on Unix is one idea |
| 20:50:40 | dom96 | asynchttpserver is actually not that bad considering that cppsp gets 26k req/s vs. asynchttpserver's 12k req/s |
| 20:54:28 | dom96 | Araq: I am also curious what your ideas are. |
| 20:54:31 | def- | This looks like a nice c http library: https://github.com/h2o/h2o |
| 20:55:03 | def- | http2 seems to give quite a speedup as well |
| 20:56:24 | Araq | dom96: there are lots of small inefficiencies everywhere that add up |
| 20:56:50 | * | alexruf quit (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 20:56:57 | dom96 | Yeah. Optimising it should be easy, it is a very small HTTP server. |
| 20:57:22 | * | johnsoft quit (Ping timeout: 245 seconds) |
| 20:57:28 | * | alexruf joined #nim |
| 20:58:18 | Araq | and then you still use too many 'await' to "not block" |
| 20:58:25 | * | Guest6923 joined #nim |
| 20:58:43 | Araq | my gut feeling is that 'await' is not as cheap as you think it is |
| 20:59:08 | Araq | since it returns control to the dispatcher |
| 20:59:29 | * | mpthrapp quit (Remote host closed the connection) |
| 20:59:36 | Araq | a bit of bulk processing can go a long way here |
| 21:00:01 | Mat4 | Araq: I think the way to go for the Nim version is simply using some when blocks and return an array of procedure pointers |
| 21:00:43 | Araq | Mat4: that's good but i have no idea what you are talking about. |
| 21:01:40 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 21:02:29 | dom96 | Araq: There is no alternative to 'await' AFAIK |
| 21:03:44 | def- | dom96: so we always need a cascade of 5 await calls? |
| 21:03:53 | Mat4 | I'm porting a function from Forth. These declaration (word) compile a word chich compiles a set of words dependent of initial parameters |
| 21:04:54 | dom96 | def-: It depends on your control flow, potentially yes. |
| 21:05:11 | Mat4 | ^which |
| 21:08:04 | dom96 | Would be interesting to see just how slow they are. |
| 21:13:24 | Araq | dom96: since headers*: StringTableRef is wrong anyway, I'm not sure we should optimize it without breaking the API |
| 21:17:06 | Araq | and when we break the API we surely can make it faster. For instance, you give a full Request object with parsed headers etc to the callback |
| 21:17:35 | Araq | when the callback will most likely won't give a shit about these things |
| 21:19:13 | dom96 | sure, let's optimise for the benchmark case, not the sane case :P |
| 21:19:25 | dom96 | The callback actually will care about it. |
| 21:19:36 | Araq | really? |
| 21:20:19 | * | Menche quit (Quit: Leaving) |
| 21:23:51 | dom96 | Araq: yeah |
| 21:24:00 | dom96 | it contains the headers |
| 21:24:02 | dom96 | the client socket |
| 21:24:03 | dom96 | etc |
| 21:24:35 | * | reem joined #nim |
| 21:24:47 | * | Matthias247 joined #nim |
| 21:24:51 | dom96 | but that's easy to optimise |
| 21:25:08 | dom96 | we can provide a way to specify a callback which doesn't take it |
| 21:25:39 | * | kniteli quit (Ping timeout: 250 seconds) |
| 21:27:35 | dom96 | Araq: You could do that with generics right? |
| 21:28:13 | dom96 | proc (request: Request): Future[void] {.closure,gcsafe.} | proc (): Future[void] {.closure,gcsafe.} |
| 21:28:33 | * | didlybom joined #nim |
| 21:28:38 | dom96 | then use `when callback is CallbackWithReq` etc |
| 21:28:50 | didlybom | Hi |
| 21:29:00 | dom96 | hi didlybom |
| 21:29:15 | didlybom | hi dom96! :-) |
| 21:29:44 | didlybom | sorry I had to leave so suddenly yesterday. Kids cannot wait sometimes :-) |
| 21:30:33 | Araq | dom96: meh ... let's just compile jester into the low level stuff that def- used |
| 21:30:47 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 21:30:50 | didlybom | anyway, I'm continuing on my quest to make a small telnetclient module |
| 21:31:23 | didlybom | I have some trouble understanding the documentation of the threads module |
| 21:32:23 | didlybom | In particular, I don't understand the use of the TArg that can be passed to the thread |
| 21:32:39 | * | filwit quit (Quit: Bye) |
| 21:33:23 | def- | didlybom: you can see here how to pass an argument when creating a thread: https://github.com/def-/nim-unsorted/blob/master/diningphilosophers.nim#L43 |
| 21:34:22 | dom96 | Araq: Yeah, let's make jester exclusively fast. Anybody else who wants to have a fast HTTP server can write their own :P |
| 21:35:28 | dom96 | Araq: There will always be some slowdown because of abstractions, you can even see that cppsp is much slower than raw epoll. |
| 21:35:41 | Araq | dom96: it's easier to optimize high level code. |
| 21:36:00 | dom96 | def-'s benchmarks are also a bit unfair IMO |
| 21:36:03 | Araq | in fact this whole problem is not unlike building a lexer generator |
| 21:36:33 | dom96 | It doesn't check what data it got from the client for example. |
| 21:37:33 | OderWat | i need a 0.9.6.. I checked it out but how can I build it? |
| 21:37:34 | didlybom | def-: thank you, but I do not understand why you must call "mythread[SOMETYPE].createThread(SOMEPROC, VAR_OF_SOMETYPE)" rather than "mythread.createThread(SOMEPROC, VAR_OF_SOMETYPE)" |
| 21:38:20 | def- | didlybom: i'm not doing that |
| 21:38:20 | didlybom | that is, why is "[SOMETYPE]" in "mythread[SOMETYPE]" necessary? |
| 21:38:42 | def- | didlybom: it's "threads[i]" where i is the index of the thread |
| 21:39:16 | didlybom | def-: yes, I understand, but threads[i] is a variable of type TThread[Phylosopher] |
| 21:39:42 | didlybom | ah |
| 21:39:47 | * | kniteli joined #nim |
| 21:40:14 | didlybom | I guess that is how createThread knows the type of the arguments that must be passed to the thread proc? |
| 21:40:56 | def- | yes |
| 21:41:38 | Araq | OderWat: dunno, I think we tagged the csources as well. but why do you need 0.9.6? |
| 21:41:42 | didlybom | def-: I see |
| 21:42:09 | dom96 | OderWat: You need 0.9.6 C sources: nim-lang.org/download/nimrod_0.9.6.zip |
| 21:42:37 | OderWat | I wanna see the differences in AST on 0.9.6 and 0.10.3 because I am looking into emerald (html template stuff) and it seems that this expects another ast structure |
| 21:42:40 | dom96 | didlybom: What are you using threads for? |
| 21:43:27 | didlybom | I am making a small interactive telnet console |
| 21:43:29 | OderWat | there are 0.9.4 csources I try them |
| 21:43:38 | didlybom | akin to python's interact method |
| 21:44:03 | didlybom | a thread reads from the telnet socket and another reads lines from the console and writes to it |
| 21:44:42 | didlybom | dom96: I used threads because that is what I first found on the standard library, but I see there is a threadpool, there is parallel, spawn... all of these seem related but I'm not sure what to use when |
| 21:45:19 | dom96 | I would try using async stuff for that. |
| 21:46:34 | def- | dom96: i have problems optimizing the async stuff, i guess i don't understand it well enough |
| 21:46:50 | didlybom | dom96: you mean the asyncnet module? |
| 21:47:27 | dom96 | didlybom: yep. Not sure if you can read from the console asynchronously yet. Perhaps asyncfile will work for that purpose. |
| 21:47:48 | dom96 | def-: Any way I could help? |
| 21:48:02 | didlybom | dom96: why not use threads? |
| 21:48:42 | * | sillesta joined #nim |
| 21:48:43 | * | alexruf quit (Quit: Textual IRC Client: www.textualapp.com) |
| 21:48:50 | def- | dom96: I'm trying to have an async recvLineInto proc that gets passed a var string and puts its result into it |
| 21:51:10 | dom96 | didlybom: You won't have to deal with race conditions. |
| 21:51:40 | didlybom | dom96: can you be a bit more explicit? |
| 21:52:14 | OderWat | @Araq / @dom96 ty.. I got it compiled and also found the problem: ImportStmt vs StmtList .. I guess I keep a 0.9.6 for reference :) |
| 21:52:18 | dom96 | didlybom: I guess for your use case threads are fine. I find async far simpler. |
| 21:52:44 | dom96 | def-: right, you won't be able to do that because closures can't capture var params. |
| 21:52:48 | didlybom | dom96: I see. I will check that out |
| 21:53:12 | def- | dom96: then i tried to use a cstring but that didn't work either |
| 21:53:20 | didlybom | dom96: anyway, I'd still like to learn how to use threads, and understand the difference with threadpool, parallel, spawn, etc |
| 21:53:50 | didlybom | for example, is it possible to tell creatThread to call a procedure that receives a var parameter? |
| 21:54:00 | def- | didlybom: i suspect no |
| 21:54:01 | didlybom | or is that unsafe? |
| 21:54:28 | Araq | unsafe and doesn't compile |
| 21:54:55 | didlybom | araq: yes, I saw it does not compile. I thought I was doing something wrong :P |
| 22:00:24 | def- | dom96: well, there goes my main optimization idea then |
| 22:03:28 | didlybom | araq: BTW, why is the thread type called TThread? Isn't it supposed to be called Thread now? |
| 22:04:48 | Araq | didlybom: did you find its API helpful? no? there you go. we update the name when we have a better api design |
| 22:06:43 | dom96 | def-: try getting rid of the Request allocation. |
| 22:06:53 | dom96 | Araq is usually right about these things :P |
| 22:07:07 | def- | dom96: what request allocation? |
| 22:07:18 | didlybom | Araq: I found the [TArg] part in most thread functions a little confusing. But other than that I guess it is simple enough |
| 22:07:41 | Araq | var request = newRequest() |
| 22:07:42 | Araq | request.hostname = address |
| 22:07:44 | Araq | assert client != nil |
| 22:07:45 | Araq | request.client = client |
| 22:07:58 | Araq | newRequest set hostname to "" |
| 22:08:11 | Araq | and then this string is immediately thrown away |
| 22:08:28 | def- | Hm, I'm still trying to optimize asyncnet before looking into asynchttpserver |
| 22:08:36 | dom96 | https://github.com/Araq/Nim/blob/devel/lib/pure/asynchttpserver.nim#L156 |
| 22:08:47 | Araq | parseProtocol raises an exception |
| 22:09:04 | Araq | but Nim's try produces a setjmp in C |
| 22:09:14 | Araq | so ... don't do that here |
| 22:09:23 | didlybom | Araq: I'm more confused by the fact there is threads but also threadpool, so I don't really know what to use |
| 22:09:43 | didlybom | Araq: It seems that there are many ways to do similar things? |
| 22:09:56 | Araq | didlybom: well the TThread is the low level abstraction, threadpool is built on top of it |
| 22:10:16 | Araq | usually you want to use the threadpool |
| 22:10:50 | Araq | if request.headers.hasKey("Expect"): |
| 22:10:51 | Araq | if request.headers["Expect"] # 2 hash table lookups where only 1 is necessary |
| 22:10:54 | dom96 | def-: I think a pool of Futures is a good idea |
| 22:11:07 | didlybom | Araq: I see, thank you. Maybe this could be said on the thread module documentation itself? i.e. point to threadpool instead? |
| 22:11:14 | dom96 | optimising recvLine would likely yield most improvements too |
| 22:11:19 | dom96 | in asyncnet |
| 22:11:43 | Araq | didlybom: sure |
| 22:12:40 | Araq | let kv = parseHeader(headerLine) |
| 22:12:41 | Araq | request.headers[kv.key] = kv.value # StringTableRef should optimize this via AST based overloading, but doesn't |
| 22:13:20 | Araq | request.url = parseUri(path) # you can do that lazily on demand, though it's hard to imagine the callback won't look at the URL |
| 22:14:02 | Araq | assert request.body.len == contentLength # this really should be at least doAssert given its security implications |
| 22:14:36 | didlybom | Araq: an additional problem is that "threads" is the third module on the nim standard library documentation page, right after system and unsigned |
| 22:14:55 | didlybom | It is even "built-in", you don't even need to import it |
| 22:15:12 | * | ruzu quit (Read error: Connection reset by peer) |
| 22:15:24 | didlybom | someone looking for using threads (or parallelism) in nim will find threads first and likely try to use it as I did |
| 22:15:31 | Araq | didlybom: yeah cause it has to. but surely these are all good points |
| 22:15:47 | * | ruzu joined #nim |
| 22:15:52 | Mat4 | the documentation seem to be somewhat spartanic. Would it be a good idea to set up a wiki for example so interested persons can work on it or better extend the documentation at demand ? |
| 22:16:00 | Araq | case reqMethod.normalize |
| 22:16:01 | Araq | of "get", "post", "head", "put", "delete", "trace", "options", "connect", "patch": # compiler should optimize 'case x.normalize' but doesn't :-/ |
| 22:16:36 | didlybom | Araq: ok. Maybe the same could be said of the selectors module? That is, that there is little reason to use it given that there is a net and an asyncnet module... |
| 22:16:36 | flaviu | <Araq> flaviu: what has this to do with anything? |
| 22:16:36 | flaviu | Worrying too much about backwards compatibility is counterproductive. |
| 22:18:25 | def- | Mat4: pull requests would work too, won't they? |
| 22:18:43 | Mat4 | I don't know |
| 22:19:18 | didlybom | Araq: BTW, I find that nim's doc tool is amazing. It is so easy to document your code and generate nice, good looking documentation for it! :-D |
| 22:19:33 | didlybom | It is amazing how many things you guys have gotten just right! |
| 22:20:17 | * | Menche joined #nim |
| 22:21:10 | Araq | really? I thought it's from hell because it isn't based on Shpinx, but then Sphinx is from hell too because it doesn't use github flavored markdown |
| 22:22:53 | Mat4 | oO |
| 22:23:13 | * | shalabh joined #nim |
| 22:23:27 | shalabh | def-:around? |
| 22:23:31 | def- | shalabh: hi |
| 22:23:42 | shalabh | from the 'how i start' article |
| 22:23:44 | shalabh | $ export PATH=$PATH:$your_install_dir/bin >> ~/.profile |
| 22:23:46 | fowl | <Araq> fowl: that's exactly what getType supports? |
| 22:23:49 | shalabh | note that doesn't actually modify the file |
| 22:23:57 | Araq | didlybom: thank you. :-) |
| 22:24:05 | def- | shalabh: eh, i forgot an echo? |
| 22:24:12 | fowl | Araq, how do you mean? |
| 22:24:30 | def- | that's sad, I'll fix it. thanks, shalabh |
| 22:24:36 | shalabh | right, in the other export too |
| 22:24:52 | def- | I should have tested my shell code and not just the nim one i guess |
| 22:25:17 | shalabh | def-:it actually works, because of the 'export' |
| 22:25:23 | shalabh | the 'source ..' doesn't do anything |
| 22:25:24 | dom96 | flaviu: I disagree.] |
| 22:25:27 | shalabh | but it's not persistent |
| 22:25:33 | shalabh | confused me for a bit |
| 22:25:39 | def- | shalabh: right |
| 22:31:25 | Araq | fowl: it returns an nnkObjectTy you can traverse that contains the fields and their types |
| 22:31:44 | Araq | and for case objects even the 'case' structure (untested though) |
| 22:34:44 | fowl | Araq, it returns typedesc[bar] |
| 22:34:56 | fowl | are there tests somewhere? |
| 22:35:23 | Araq | well yes, you need to access n[1] to get the 'bar' |
| 22:35:38 | Araq | and then invoke getType() on the 'bar' again to get its "body" |
| 22:36:18 | Araq | isn't that obvious from the docs? ;-) |
| 22:37:23 | Araq | getType returns a shallow view on the type graph, you need to call it multiple times to get a bigger picture. this has been done this way to prevent endless recursions |
| 22:38:07 | dom96 | def-: You could get rid of a single allocation of Future here: https://github.com/Araq/Nim/blob/devel/lib/pure/asynchttpserver.nim#L156 |
| 22:38:14 | dom96 | oops, wrong link: https://github.com/Araq/Nim/blob/devel/lib/pure/asyncnet.nim#L202 |
| 22:39:31 | def- | dom96: how so? |
| 22:40:05 | Araq | dom96: yes. how so? |
| 22:40:41 | fowl | Araq, ok i'll have to play with this |
| 22:42:11 | Mat4 | ciao |
| 22:42:19 | * | Mat4 quit (Quit: Verlassend) |
| 22:44:12 | flaviu | dom96: Have you profiled yet? |
| 22:44:38 | def- | flaviu: the asynchttp stuff? I have |
| 22:45:10 | flaviu | def-: yep, have you found any clear hotspots? |
| 22:45:24 | dom96 | Araq: def-: Hrm. It's not as easy as I thought. |
| 22:45:28 | def- | about 50% of the time is string copies, string allocations and object allocations, but all over the place |
| 22:45:48 | dom96 | Araq: def-: You could probably turn it into a template similar to this one: https://github.com/Araq/Nim/blob/devel/lib/pure/asyncnet.nim#L160 |
| 22:45:50 | Araq | flaviu: http://c2.com/cgi/wiki?UniformlySlowCode |
| 22:46:09 | flaviu | def-: Well, looking at the call stack would take the guesswork out of it. |
| 22:48:28 | shalabh | strings should rarely be copied in web apps. python strings are immutable so performant systems just append the strings to a list that is joined at the end. |
| 22:49:56 | Araq | shalabh: you can mark a string shallow() in Nim to do that. and I think that's just what we need here in strategic places |
| 22:50:19 | shalabh | ah cool. why is it called shallow()? |
| 22:50:28 | dom96 | Araq: any ideas where we could do that? |
| 22:50:33 | shalabh | and not frozen() or immutable() etc |
| 22:50:57 | Araq | shalabh: because we cannot check for that easily, unfortunately |
| 22:51:19 | flaviu | Araq: How's progress on assignment operators? |
| 22:51:37 | Araq | in particular x[i] = 's' doesn't trigger any barrier we could use to ensure immutability |
| 22:51:42 | def- | flaviu: http://ddnet.tw/valgrind-asynchttp.png |
| 22:51:53 | Araq | flaviu: non-existing |
| 22:52:57 | Araq | shalabh: that said, string concatenation is quite fast since Nim's strings are mutable ;-) |
| 22:53:14 | Araq | sux when you pass them around like crazy though |
| 22:56:47 | Araq | dom96: well you have to be careful to not setLen(s, 0) (aka "reuse the buffer") when you use shallow() so it's not obvious when and how to use it |
| 22:59:28 | shalabh | Araq:right but many web apps can't write to the final outpu string directly. just the way they are designed, you first build smaller chunks, then join them to form larger chunks, and so on. |
| 22:59:37 | shalabh | that pattern will cause many copies in nim |
| 22:59:59 | shalabh | but if there was a 'stringtree' type or something that would be better for generating these pages. |
| 23:00:21 | Araq | ropes are in the stdlib and they suck ;-) |
| 23:00:50 | shalabh | dont need that complexity |
| 23:00:58 | * | xkpe joined #nim |
| 23:00:59 | shalabh | just a list of strings will do with some special operators I guess |
| 23:00:59 | dom96 | def-: Could you try this and see if it makes any difference? https://gist.github.com/dom96/87d6caea0b9977e47082 |
| 23:01:05 | shalabh | seq of string |
| 23:01:17 | shalabh | so instead of generated new strings, you just create seq of strings |
| 23:01:31 | Araq | shalabh: so instead of 'var string' you pass a 'var seq[string]' ? doesn't help in Nim |
| 23:01:33 | shalabh | and joining two seq of strings is easy |
| 23:01:52 | shalabh | why not? |
| 23:01:54 | flaviu | How about using copy-on-write strings instead of copy-on-assignment. |
| 23:02:13 | Araq | flaviu: hard to do with the current codegen, but otherwise an excellent idea |
| 23:02:45 | flaviu | Araq: I never said it had to be supported by the compiler. It'll work fine as a library. |
| 23:03:07 | shalabh | Araq:with 'var seq[string]', the strings wont be copied, only the references will, right? |
| 23:03:22 | flaviu | shalabh: Nope, string is like seq[char] |
| 23:03:41 | Araq | shalabh: because 'var string' is not the problem here and when you cannot have 'var string' due to API design constraints you cannot have 'var seq[string]' either |
| 23:05:27 | shalabh | I was trying to suggest optimizations for reducing string copying. Not sure what API design contraints there are. |
| 23:05:58 | dom96 | def-: Possibly might not even work, haven't tested it :P |
| 23:06:04 | shalabh | anyway, I'm sure you're aware of many options. |
| 23:09:22 | def- | dom96: yield only allowed in an iterator |
| 23:09:22 | def- | hm, wait |
| 23:09:22 | def- | dom96: works, but doesn't change much performance wise |
| 23:09:22 | def- | from 17435 to 17594 requests/second |
| 23:09:51 | * | reem quit (Remote host closed the connection) |
| 23:10:05 | dom96 | hmm. |
| 23:10:19 | dom96 | I guess removing futures doesn't have that much of an impact on the performance then. |
| 23:10:36 | Araq | no, that's pretty good |
| 23:10:58 | Araq | there are no huge gains possible when you have uniformly slow code |
| 23:11:05 | Araq | :P |
| 23:11:08 | dom96 | I can't tell if that's significant or just random change. |
| 23:11:26 | dom96 | Araq: ...righhttt? |
| 23:11:28 | def- | dom96: doesn't seem to be random, i ran it a few times |
| 23:11:42 | Araq | 100 requests per second more is not random |
| 23:12:36 | def- | I'd like to make a few strings shallow |
| 23:12:53 | dom96 | yeah, try it. |
| 23:13:02 | def- | not sure where and how |
| 23:13:22 | dom96 | Araq: I suppose a pool of futures will help dramatically. |
| 23:14:07 | * | didlybom quit (Ping timeout: 246 seconds) |
| 23:15:09 | dom96 | async templates too :P |
| 23:15:47 | dom96 | I wonder if my async macro is the biggest in Nim's history. |
| 23:15:55 | Triplefox | "futures" makes me think "market-driven programming?" |
| 23:18:29 | Araq | dom96: don't think so |
| 23:18:38 | Araq | quite sure I debugged bigger ones |
| 23:19:22 | dom96 | Araq: when was the last time you looked at the async macro? |
| 23:19:55 | dom96 | I guess 306 lines isn't that large. |
| 23:20:02 | dom96 | It feels large though. |
| 23:20:03 | Araq | er ... never mind I confused it with your => macro :P |
| 23:20:14 | dom96 | hah |
| 23:22:34 | xkpe | how can I do a range of unsigned numbers? this code gives me a compilation error: for i in 0'u .. 99'u: |
| 23:22:47 | def- | xkpe: import unsigned? |
| 23:25:25 | * | sillesta quit (Ping timeout: 265 seconds) |
| 23:25:33 | xkpe | def- thanks, it worked, but then i'm not sure if i'm doing something wrong |
| 23:25:42 | def- | xkpe: why? |
| 23:26:37 | xkpe | i can declare uint variables without that include, is it just ranges that don't work? |
| 23:27:16 | onionhammer | dom96 why not break up the logic a bit :P |
| 23:27:18 | def- | that's normal, most procs for unsigned are just in this module: http://nim-lang.org/unsigned.html |
| 23:27:21 | onionhammer | 300 line long macro? :P |
| 23:27:28 | dom96 | onionhammer: It is broken up |
| 23:27:46 | dom96 | I counted the compile-time procs too. |
| 23:27:52 | onionhammer | ah |
| 23:28:42 | Araq | I wonder how much slower these macros are in the old VM |
| 23:28:48 | dom96 | Also if you want to learn about macros you should take a look at it, I documented the exact code it produces at each stage of when a new AST node is created. |
| 23:31:17 | onionhammer | cool, but Im pretty comfortable w/ macros :) |
| 23:39:06 | * | reem joined #nim |
| 23:42:58 | * | fizzbooze quit (Ping timeout: 256 seconds) |
| 23:43:41 | * | reem quit (Ping timeout: 256 seconds) |
| 23:46:08 | * | pafmaf quit (Quit: This computer has gone to sleep) |
| 23:46:56 | * | reem joined #nim |
| 23:55:42 | * | Trustable quit (Remote host closed the connection) |
| 23:57:31 | * | shalabh quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
