| 00:00:45 | Araq | I dunno why you want to "override" things when in fact you can simply edit the code instead |
| 00:01:36 | Araq | do this! no I changed my mind, do that! # hard |
| 00:01:40 | Araq | do that! # easy |
| 00:02:49 | reactormonk | edit all of system.nim? |
| 00:03:09 | reactormonk | ... and the inclusions |
| 00:04:54 | Araq | I already said how it should be done |
| 00:04:56 | Araq | split system.nim into system/intops.nim, system/stringops.nim etc. |
| 00:04:57 | Araq | and then include what you do support |
| 00:04:59 | Araq | it's quite some work though :P |
| 00:05:25 | reactormonk | you think that's the best way? |
| 00:05:52 | Araq | for embedded, yeah |
| 00:06:02 | reactormonk | ok, let's do that |
| 00:06:05 | Araq | but tbh I'm not sure that can work |
| 00:06:11 | reactormonk | why? |
| 00:06:26 | Araq | the number of switches system.nim supports is large |
| 00:06:35 | Araq | and there are overlapping things etc. |
| 00:06:45 | * | q66 quit (Remote host closed the connection) |
| 00:06:48 | Araq | but we should try |
| 00:06:56 | reactormonk | let's see |
| 00:07:08 | reactormonk | call it interfaces/stringops.nim? ;> |
| 00:07:22 | Araq | there already is a system/ dir |
| 00:07:29 | reactormonk | yeah, but it's getting full |
| 00:07:50 | reactormonk | screw that? |
| 00:08:36 | Araq | dunno, make a sys/ directory then :P |
| 00:09:03 | Araq | we'll probably merge it into system/ and pull other things out of system/ |
| 00:09:22 | Araq | the gc stuff could become its own dir, for instance |
| 00:11:08 | reactormonk | I assume `new` is heap? |
| 00:11:23 | Araq | yeah |
| 00:15:23 | NimBot | Araq/Nimrod 1cbf7e4 Simon Hafner [+0 ±4 -0]: some patches concerning signals and standalone OS |
| 00:15:23 | NimBot | Araq/Nimrod 8a9a55a Simon Hafner [+0 ±1 -0]: added "standalone" to possible OS options |
| 00:15:26 | reactormonk | oh fuck |
| 00:15:30 | reactormonk | that didn't go well |
| 00:15:42 | reactormonk | Araq, could you kill the last two patches? |
| 00:15:50 | apotheon | oopsie |
| 00:16:12 | Araq | gah |
| 00:16:29 | Araq | why can't you? |
| 00:16:54 | reactormonk | got it |
| 00:17:52 | NimBot | Araq/Nimrod c880189 Simon Hafner [+0 ±1 -0]: added "standalone" to possible OS options |
| 00:18:09 | Araq | is that a revert? |
| 00:18:21 | reactormonk | nope, I overwrite it. |
| 00:18:37 | Araq | I demanded code review ... |
| 00:18:47 | reactormonk | yeah, I know. I kicked it again. |
| 00:19:37 | Araq | hmm true |
| 00:19:48 | Araq | very well then, I should sleep now |
| 00:19:53 | reactormonk | sorry about the history rewrite :-) |
| 00:21:16 | Araq | it's alright but you should work on a branch anyway |
| 00:21:40 | Araq | nimbuild got cool branch support; 'master' is supposed to be stable now |
| 00:22:25 | reactormonk | ok |
| 00:22:40 | Araq | name the branch "standalone" ;-) |
| 00:22:42 | Araq | good night |
| 00:22:54 | reactormonk | cya |
| 00:27:02 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 00:36:17 | dom96 | That's odd. |
| 00:36:47 | dom96 | git pull is now failing on the test machines because git wants to know the user.email and user.name |
| 00:41:10 | dom96 | oh well, fixed. |
| 00:45:29 | reactormonk | is `setLen` always on the heap or can you modify seq length on the stack? |
| 00:47:09 | dom96 | good night |
| 01:01:47 | fowl | reactormonk: seqs are hidden reference types, always on the heap afaik |
| 01:34:02 | * | Trix[a]r_za is now known as Trixar_za |
| 01:38:04 | fowl | Dominik is a high caliber C expert who loves pushing code. Dominik is a fulltime hacker who seems to work best in the late evening. |
| 01:38:14 | fowl | http://osrc.dfm.io/dom96 |
| 01:38:18 | fowl | :p |
| 01:48:17 | * | fowl quit (Ping timeout: 256 seconds) |
| 01:51:24 | reactormonk | C expert? lulz. |
| 01:59:41 | * | fowl joined #nimrod |
| 02:07:14 | reactormonk | fowl, are strings hidden reference as well? |
| 02:08:06 | fowl | i think so |
| 02:08:53 | reactormonk | hm |
| 02:45:35 | reactormonk | would it be possible to add random examples to the homepage? |
| 04:03:33 | * | ARCADIVS joined #nimrod |
| 04:13:00 | * | OrionPK quit (Read error: Connection reset by peer) |
| 04:42:14 | * | vegai joined #nimrod |
| 05:25:03 | reactormonk | Araq, oh god, that stuff is cascading |
| 05:26:30 | reactormonk | so far, I see a) seq operations b) sets c) strings d) repr, depends on c e) alloc stuff, maybe linked to f) GC g) exceptions |
| 05:26:48 | reactormonk | I have no idea yet how the dependencies are |
| 05:59:51 | * | silven joined #nimrod |
| 06:19:37 | * | fowl quit (Ping timeout: 246 seconds) |
| 06:20:43 | Araq | hi vegai, welcome! |
| 06:24:40 | vegai | hi |
| 06:28:40 | * | Trixar_za is now known as Trix[a]r_za |
| 06:28:52 | reactormonk | Araq, sup ;-) |
| 06:29:56 | reactormonk | Araq, any way to undefine something? |
| 06:53:03 | * | fowl joined #nimrod |
| 07:12:22 | * | shevy quit (Remote host closed the connection) |
| 07:22:48 | Araq | reactormonk: no |
| 07:23:05 | reactormonk | Araq, any plans to do so? |
| 07:24:05 | Araq | no |
| 07:24:10 | reactormonk | kk |
| 07:24:18 | reactormonk | is my listing above somewhat accurate? |
| 07:25:15 | Araq | sure but then I don't know the dependencies either |
| 07:25:36 | reactormonk | let's find out |
| 07:27:00 | reactormonk | strings are heap-based? |
| 07:27:05 | reactormonk | are cstrings as well? |
| 07:27:23 | Araq | cstrings are C strings, they live where you chose them to live |
| 07:27:33 | reactormonk | good |
| 07:27:39 | Araq | Nimrod's strings are heap based |
| 07:27:59 | reactormonk | good |
| 07:53:20 | fowl | Mutable variables are too pretty. IMO immutability should be syntactically and semantically preferred, with mutable variables only used in rare circumstances. |
| 07:53:50 | reactormonk | fowl, kinda scala mentality |
| 07:54:14 | fowl | i dont get this "this isnt language X, make it more like language X" mentality |
| 07:54:34 | reactormonk | fowl, except it won't ever target the JVM ;-) |
| 07:55:08 | fowl | thats not what the homepage says |
| 07:55:33 | fowl | o wait yes it does |
| 07:56:00 | fowl | Forward declarations. I spend my days writing C++, and I'll happily admit that I spend very little time actually worrying about forward declaration in reality. So it's completely irrational, but yet: this limitation doesn't belong in a modern language. |
| 07:56:39 | fowl | i guess he doesnt worry about them because he writes the header first then implements? how do you write c++ without forward declarations |
| 07:57:02 | reactormonk | http://nimrod-code.org/ <- needs a link |
| 07:58:50 | reactormonk | ... to the new page |
| 07:59:11 | fowl | what new page? |
| 07:59:26 | reactormonk | http://nimrod-code.org/news.html |
| 07:59:45 | fowl | its in the header |
| 07:59:49 | fowl | home, news, docs, download, |
| 08:00:51 | reactormonk | ok, I mean the page should be linked to http://nimrod-code.org/index.html |
| 08:25:35 | Araq | bbl |
| 10:18:38 | dom96 | "Dominik is a high caliber C expert who loves pushing code." :D |
| 10:19:02 | dom96 | And yet I haven't pushed a single line of C code :P |
| 10:19:14 | fowl | i do c too |
| 10:19:34 | fowl | i wonder if ive accidentally pushed nimcache or something |
| 10:19:54 | dom96 | "It seems�from their activity streams�that Billingsly and Araq are probably friends or at least virtual friends. With this in mind, it's worth noting that araq is less of a whiner." |
| 10:19:56 | dom96 | hahah |
| 10:21:28 | fowl | With this in mind, it's worth noting that araq speaks more languages. |
| 10:21:38 | fowl | seems to say something different every time i refresh |
| 10:21:59 | dom96 | huh, meh. That's silly. |
| 10:22:12 | dom96 | or maybe all of those are actually true ;P |
| 10:22:23 | fowl | With this in mind, it's worth noting that araq has a less consistent weekly schedule. |
| 10:23:51 | fowl | one time it said i was a champion Rubyist, but not as good a Rubyist as <someotherguy> =( |
| 10:27:10 | fowl | night all |
| 10:27:33 | dom96 | bye fowl |
| 10:58:46 | * | q66 joined #nimrod |
| 11:26:13 | * | __ponce joined #nimrod |
| 11:26:36 | Araq | yay __ponce is back |
| 11:27:29 | __ponce | I felt the reddit hype directing towards here |
| 11:28:08 | Araq | yeah ... it's getting crowded in here :P |
| 11:31:49 | __ponce | I'm curious about your sample code here http://pastebin.com/Md0aCnME how do you know it happen at compile-time? |
| 11:32:08 | __ponce | is it "static foreach" or compile-time execution? |
| 11:32:27 | Araq | it is "static foreach" |
| 11:32:43 | Araq | it's not a real loop, it merely looks like one |
| 11:32:57 | __ponce | very cool |
| 11:33:27 | Araq | you can also iterate over 2 objects at once with it: |
| 11:33:33 | Araq | for x, y in pairs(a, b): |
| 11:33:44 | Araq | if x != y: return false |
| 11:33:51 | Araq | return true |
| 11:33:57 | Araq | would be '==' for tuples |
| 11:35:01 | Araq | er |
| 11:35:08 | Araq | s/pairs/fields |
| 12:11:24 | * | zahary_ joined #nimrod |
| 12:28:13 | dom96 | __ponce: nice to see you submitted news about Nimrod to HN again. When I submitted it I got 0 points. |
| 12:29:00 | dom96 | But hey, whatever gets it to the front page :) |
| 12:29:02 | __ponce | well there is a bit of luck too |
| 12:29:28 | dom96 | yeah, timing it seems sometimes is everything. |
| 13:15:57 | * | ARCADIVS quit (Quit: WeeChat 0.3.8) |
| 14:08:46 | * | Trix[a]r_za is now known as Trixar_za |
| 14:27:03 | * | fowl quit (Ping timeout: 256 seconds) |
| 14:36:00 | * | rgrinberg joined #nimrod |
| 14:41:08 | dom96 | hello rgrinberg |
| 14:45:09 | rgrinberg | dom96: |
| 14:45:10 | rgrinberg | hi |
| 14:45:15 | rgrinberg | oops :D |
| 14:46:36 | dom96 | welcome to #nimrod :) |
| 14:46:56 | rgrinberg | thanks, installing nirmod right now :D |
| 14:47:10 | rgrinberg | looks like an interesting language. is tehre a vim mode? |
| 14:47:16 | dom96 | cool. |
| 14:47:59 | dom96 | There is indeed: https://github.com/zah/nimrod.vim |
| 14:49:07 | rgrinberg | dom96: sweet |
| 15:16:54 | * | Trixar_za is now known as Trix[a]r_za |
| 17:47:33 | * | fowl joined #nimrod |
| 17:48:36 | * | Trix[a]r_za is now known as Trixar_za |
| 18:05:34 | * | Reiser quit (Ping timeout: 240 seconds) |
| 18:09:44 | reactormonk | rgrinberg, slightly better maintained than the emacs mode :-/ |
| 18:09:58 | reactormonk | dom96, is that on the website btw? |
| 18:10:23 | dom96 | reactormonk: what? The availability of vim mode? |
| 18:10:28 | * | Trixar_za is now known as Trix[a]r_za |
| 18:10:39 | reactormonk | Araq, how come only some of the pages are of the new layout? |
| 18:10:42 | reactormonk | dom96, yup |
| 18:11:04 | dom96 | reactormonk: It's not, no. |
| 18:11:29 | reactormonk | dom96, maybe add it to the FAQ? |
| 18:11:56 | dom96 | reactormonk: Well, it's already in the "Unofficial FAQ" on github. |
| 18:12:06 | reactormonk | dom96, where is the official FAQ? |
| 18:12:14 | dom96 | But yeah, I guess it would be useful in the official FAQ |
| 18:12:31 | dom96 | http://www.nimrod-code.org/question.html |
| 18:12:32 | reactormonk | or just link to https://github.com/Araq/Nimrod/wiki/Editor-Support in the official FAQ |
| 18:14:37 | dom96 | yeah |
| 18:15:48 | reactormonk | http://sprunge.us/MKBX good? |
| 18:16:45 | dom96 | Ask Araq ;) |
| 18:17:27 | rgrinberg | reactormonk: good to know, usually it's the other way around :D |
| 18:19:15 | reactormonk | rgrinberg, I'm editing some more specific functionality than more of the general one, see https://github.com/Tass/kwin-minor-mode |
| 18:19:58 | reactormonk | the lines in question: https://github.com/Tass/kwin-minor-mode/blob/master/kwin.el#L123-L125 |
| 18:28:49 | * | fowl quit (Ping timeout: 248 seconds) |
| 18:31:54 | * | Trix[a]r_za is now known as Trixar_za |
| 18:41:22 | * | fowl joined #nimrod |
| 19:04:14 | * | Reisen joined #nimrod |
| 19:27:41 | dom96 | well it seems it's almost the end of our ride on the front page of reddit. |
| 19:28:05 | dom96 | Earned at least 10 new "stargazers" on github though :) |
| 19:29:47 | * | Trixar_za is now known as Trix[a]r_za |
| 19:30:43 | comex | meh |
| 19:30:49 | comex | maybe I should pay attention to this channel after years of neglect :) |
| 19:31:05 | comex | did you ever improve the compiler speed? :P |
| 19:34:53 | Araq | comex: I got --symbolfiles to work |
| 19:35:10 | Araq | but it's broken again for 0.9.2 :P |
| 19:35:22 | dom96 | comex: you should help us advertise nimrod! |
| 19:35:46 | Araq | bootstrapped in0.02s or so when it worked |
| 19:36:26 | comex | cool, fix it :) |
| 19:37:04 | Araq | yeah I will definitely |
| 19:37:35 | Araq | otherwise compile times used to be 1s for bootstrapping and now it's 2.7s on this machine :P |
| 19:37:46 | Araq | so we're getting worse and worse |
| 19:37:48 | comex | i still haven't gotten around to making my pet language :( |
| 19:38:04 | Araq | on the other hand, it also needs to compile more code |
| 19:38:16 | Araq | that makes it hard to say |
| 19:38:34 | Araq | it went from 45K LOC to over 60K iirc |
| 19:40:19 | dom96 | comex: Well? How about tweeting about Nimrod? |
| 19:41:18 | comex | heh, most of my followers are not programmers |
| 19:41:49 | comex | you'd think i'd get more response when i tweet things, considering my number of followers, but i don't get that much anymore :p |
| 19:41:52 | rgrinberg | are nimrod's variant types are tagged variants or just dumb enums? |
| 19:42:21 | Araq | tagged variants |
| 19:42:32 | Araq | enum + union if you want to call it that way |
| 19:42:54 | Araq | it uses runtime checking as opposed to compile time checking that you access a valid field |
| 19:43:03 | Araq | I know, I know, it's BAD for marketing |
| 19:43:19 | Araq | it's however very sweet for the compiler itself and the resulting expressivity |
| 19:43:55 | Araq | I suppose it's another blog post away to debunk it :P |
| 19:43:59 | dom96 | comex: Out of the 200k that you have i'm sure at least 1% are programmers :P |
| 19:45:14 | dom96 | Araq: So how about that blog then? |
| 19:45:16 | rgrinberg | Araq: what kind of expressivity do you gain? |
| 19:45:34 | Araq | lot of unless you have dependent typing |
| 19:46:23 | Araq | most examples I have in mind are not text book compatible |
| 19:46:32 | rgrinberg | text book incompatible is fine for me |
| 19:47:22 | rgrinberg | i just have a hard time imagining the difference with say ml's variants |
| 19:48:07 | Araq | const |
| 19:48:09 | Araq | skipForDiscardable = {nkIfStmt, nkIfExpr, nkCaseStmt, nkOfBranch, |
| 19:48:10 | Araq | nkElse, nkStmtListExpr, nkTryStmt, nkFinally, nkExceptBranch, |
| 19:48:12 | Araq | nkElifBranch, nkElifExpr, nkElseExpr, nkBlockStmt, nkBlockExpr} |
| 19:48:13 | Araq | proc ImplicitlyDiscardable(n: PNode): bool = |
| 19:48:15 | Araq | var n = n |
| 19:48:16 | Araq | while n.kind in skipForDiscardable: n = n.lastSon |
| 19:48:18 | Araq | result = isCallExpr(n) and n.sons[0].kind == nkSym and |
| 19:48:20 | Araq | sfDiscardable in n.sons[0].sym.flags |
| 19:48:22 | Araq | recently added to the compiler :P |
| 19:48:34 | Araq | it takes a while to explain it |
| 19:50:10 | Araq | hmm maybe I should have started differently |
| 19:51:26 | rgrinberg | first i should probably figure out the pattern matching syntax in nimrod :D |
| 19:52:08 | rgrinberg | "source code filters" oh god this reminds me of using perl back in the day... |
| 19:52:46 | Araq | I invented it and then later figured Perl has it too :P |
| 19:52:55 | Araq | but don't worry, it's very rarely used |
| 19:53:15 | Araq | and when it is used, it's the right tool for the job IMO |
| 19:55:26 | * | rgrinberg rushes to port Acme::Bleach to nimrod |
| 20:08:59 | rgrinberg | reading the faq, i'm curious as to why a jvm backend seems impossible? |
| 20:09:10 | rgrinberg | does it mean an efficient backend? |
| 20:09:15 | rgrinberg | specifically |
| 20:09:56 | Araq | yeah |
| 20:10:06 | Araq | and it pains me to say it |
| 20:10:28 | Araq | but nowadays with the typed arrays JS is better target than the JVM or at least quickly becoming one |
| 20:10:35 | rgrinberg | is it the absence of value types? |
| 20:10:42 | Araq | yes |
| 20:10:44 | rgrinberg | i see JS is always "hip" to target |
| 20:11:15 | Araq | JS is the final proof for "worse is better" |
| 20:11:19 | rgrinberg | i'm sure i can google this but what's teh state of |
| 20:11:29 | rgrinberg | 1) a build system for nimrod projects |
| 20:11:35 | rgrinberg | 2) package management |
| 20:11:39 | rgrinberg | 3) parsing/lexing tools |
| 20:11:57 | Araq | 3) none that I'm aware of unfortunately |
| 20:12:02 | Araq | 2) Babel |
| 20:12:17 | Araq | 1) mostly unnecessary since the it's all integrated into the compiler |
| 20:12:40 | fowl | i wrote a really simple make-like |
| 20:13:34 | rgrinberg | I see, will check out babel |
| 20:14:23 | fowl | https://gist.github.com/fowlmouth/3607822 |
| 20:16:41 | rgrinberg | fowl: Thanks, nimrod code looks pretty clean |
| 20:17:18 | fowl | i am actually cleaning it up a bit, havent looked at this in a while and spotted a bug |
| 20:18:13 | rgrinberg | give it a home more worthy than a gist |
| 20:24:14 | reactormonk | Araq, http://sprunge.us/MKBX good? |
| 20:25:32 | Araq | why not copy the answer that's on the wiki? |
| 20:25:57 | Araq | and remove this "C compilation fails" crap question |
| 20:26:04 | Araq | that hasn't been an issue since years |
| 20:26:07 | reactormonk | Araq, redundant information? |
| 20:26:23 | Araq | yeah but it avoids a click for the user |
| 20:26:32 | dom96 | Araq: IMO it's better to link to a version which will always be kept up to date. |
| 20:26:48 | reactormonk | Araq, this one? Execution of GCC fails (Windows) |
| 20:26:51 | dom96 | Actually, I would do both. |
| 20:26:53 | Araq | it's up to date except that other editors will follow |
| 20:27:01 | Araq | reactormonk: yes. |
| 20:27:02 | dom96 | Provide a nice summary of the editors and provide the link to the wiki. |
| 20:27:12 | Araq | don't make the user click |
| 20:27:55 | * | amarsahinovic joined #nimrod |
| 20:28:07 | dom96 | hello amarsahinovic |
| 20:28:18 | reactormonk | Araq, kk |
| 20:28:22 | amarsahinovic | hi :) |
| 20:28:50 | reactormonk | Araq, so shorten the github wiki? |
| 20:29:12 | Araq | hi amarsahinovic, welcome |
| 20:29:32 | Araq | reactormonk: don't make the user click, I don't care about the github wiki that much |
| 20:29:34 | reactormonk | Araq, what's that format? |
| 20:29:41 | Araq | RST |
| 20:30:12 | amarsahinovic | thanks Araq |
| 20:33:51 | reactormonk | Araq, why not markdown? :-) |
| 20:34:02 | Araq | markdown is a subset of RST |
| 20:34:12 | Araq | for all practical concerns |
| 20:35:21 | reactormonk | except the hyperlinks |
| 20:35:49 | NimBot | Araq/Nimrod a41b953 Simon Hafner [+0 ±1 -0]: add FAQ about editor support |
| 20:35:49 | NimBot | Araq/Nimrod 6adc2e5 Simon Hafner [+0 ±1 -0]: removed GCC FAQ - not an issue anymore |
| 20:35:49 | NimBot | Araq/Nimrod 4d4c4b3 Simon Hafner [+0 ±1 -0]: better editor support FAQ |
| 20:36:24 | reactormonk | hm, too much of a habit to push stuff, sorry |
| 20:36:27 | reactormonk | will branch more. |
| 20:37:01 | Araq | it's fine |
| 20:37:18 | reactormonk | https://github.com/Araq/Nimrod/blob/4d4c4b350566a13b51f1cd7e258b8434bf73876f/web/question.txt#L82 <- fine? |
| 20:38:12 | Araq | yes, maybe we should remove the unsupported compilers in the table |
| 20:38:33 | reactormonk | good, let's see if I can split the system.nim into meaningful sections |
| 20:38:44 | Araq | branch for that! |
| 20:39:06 | reactormonk | sure |
| 20:39:27 | reactormonk | did so already |
| 20:39:49 | NimBot | Araq/Nimrod 837e514 Araq [+0 ±2 -0]: fixed typos in the manual; kept trimcc tool up to date |
| 20:39:49 | NimBot | Araq/Nimrod fd29062 Araq [+0 ±2 -0]: Merge branch 'master' of github.com:Araq/Nimrod |
| 20:40:18 | NimBot | Araq/Nimrod a0e3e33 Simon Hafner [+0 ±1 -0]: removed unsupported compilers from the FAQ |
| 20:40:54 | amarsahinovic | I was just checking nimrod (and jester), and I created a simple app which just sends json response, to compare nimrod to my go (beego framework to be exact) version, and nimrod seems to be almost 3 times as fast. So I came here to suggest that you submit your version to this benchmark https://github.com/TechEmpower/FrameworkBenchmarks a little bit of exposure for nimrod can't hurt :) |
| 20:43:14 | Araq | amarsahinovic: thank you |
| 20:44:16 | apotheon | I figured out why the Nimrod port maintainer for FreeBSD isn't here: there's no FreeBSD port of Nimrod. |
| 20:45:07 | Araq | apotheon: I used to run an old version on FreeBSD |
| 20:45:56 | dom96 | amarsahinovic: That's nice to hear. How exactly does your app code look like? I have heard of this FrameworkBenchmarks thing and was thinking about submitting but I wanted to get Nimrod/jester as fast as possible first. In fact just a ~day before the release of 0.9.2 I have committed a patch for the SCGI module which makes it a lot more efficient. I have also ran some benchmarks and in the 'wrk' benchmark Nimrod performs better than Go whereas using weigh |
| 20:45:56 | dom96 | ttp Go performs better. Jester still however has many areas for improvement and I will definitely implement those ASAP. |
| 20:46:00 | * | zahary joined #nimrod |
| 20:46:42 | dom96 | we used to have a netbsd builder |
| 20:47:01 | dom96 | but it started failing due to some path problems IIRC |
| 20:53:35 | amarsahinovic | dom96: http://pastebin.com/fpJx7FBU here is the code for jester and go version, and benchmark results from ab |
| 20:54:52 | * | apotheon twiddles his thumbs while something downloads. |
| 20:55:05 | apotheon | "I'm downloading!" is the new "I'm compiling!" |
| 20:56:07 | fowl | the go version sends a lot more bytes |
| 20:56:23 | amarsahinovic | yeah, I just saw that too |
| 20:56:38 | dom96 | indeed, also the Nimrod version is not async. |
| 20:56:55 | dom96 | So it will not handle concurrent requests well. |
| 20:57:08 | amarsahinovic | :facepalm: |
| 20:57:46 | amarsahinovic | I benchmarked the wrong url for Go |
| 20:57:54 | amarsahinovic | it seems that they are the same |
| 20:58:07 | amarsahinovic | sorry guys :) |
| 20:58:13 | dom96 | Did you compile the Nimrod version with -d:release? |
| 20:58:39 | amarsahinovic | yeah, I get around 2k requests per second for both on average |
| 20:58:51 | amarsahinovic | although nimrod jumps from 1.6k to 2k |
| 20:59:09 | amarsahinovic | and the byte size is the same now |
| 21:01:40 | dom96 | Yeah, btw. The httpserver module which jester uses is very much unoptimised, using it in async mode won't buy you much. |
| 21:02:41 | dom96 | And I optimised the scgi module first because that is how nimforum and nimbuild are deployed (both use jester and communicate with nginx through SCGI) |
| 21:03:24 | dom96 | Your Go app on the other hand spawns multiple threads, so it's a bit unfair :P |
| 21:05:13 | amarsahinovic | yeah, it does, but even with that, nimrod/jester are not far behind |
| 21:05:54 | dom96 | indeed, that shows just how efficient Nimrod really is :) |
| 21:06:02 | amarsahinovic | yeah |
| 21:06:53 | amarsahinovic | and it seems like a nice language, especially since it looks a lot like Python, which is a good thing for me :) |
| 21:07:09 | dom96 | That's exactly what attracted me to it in the first place :) |
| 21:07:19 | apotheon | At what point do the build instructions for Unix require root? |
| 21:07:39 | dom96 | apotheon: ./install |
| 21:07:51 | apotheon | ./build.sh |
| 21:07:51 | apotheon | bin/nimrod c koch |
| 21:07:51 | apotheon | ./koch boot -d:release |
| 21:07:57 | apotheon | I don't see ./install in there. |
| 21:08:11 | dom96 | oh sorry, you said build instructions. |
| 21:08:20 | dom96 | I don't think it's required at all. |
| 21:08:37 | dom96 | except if you want to install it to /usr/bin |
| 21:08:41 | amarsahinovic | dom96: you should submit your benchmark even if you don't manage to get all the optimizations you wanted, perhaps only the json benchmark part for now |
| 21:08:43 | apotheon | hrm |
| 21:08:53 | apotheon | I guess I'm not sure what exactly is going on with these instructions. |
| 21:09:39 | dom96 | amarsahinovic: hrm, perhaps. But I would rather give Nimrod a good position from the start. |
| 21:09:51 | dom96 | apotheon: What's the problem? |
| 21:10:24 | apotheon | I have no idea what those steps I quoted actually *do*, specifically, so I'm not sure that'll give me a working install. |
| 21:10:51 | apotheon | Oh, there's another step after it. |
| 21:11:10 | apotheon | I guess "koch install [dir]" is where it'd require root, then. |
| 21:11:55 | dom96 | releases use an install.sh to do installation, whereas to install the latest from git you would use ./koch install |
| 21:12:23 | dom96 | ./build.sh builds the C sources (contained in a csources.zip file in the git repo) |
| 21:12:36 | Araq | don't install it, just add it to your $PATH |
| 21:12:41 | apotheon | In my case, I guess that'd probably be "./koch install /usr/local/bin". |
| 21:12:45 | dom96 | you then build koch with 'bin/nimrod c koch' |
| 21:12:57 | dom96 | and ./koch boot bootstraps the compiler. |
| 21:15:09 | apotheon | Araq: Why not install it? |
| 21:15:18 | apotheon | That's what /usr/local/bin is for. |
| 21:17:17 | Araq | why not install it? because updating is easier then |
| 21:18:11 | Araq | plus no matter how hard you try to convince me of the opposite, distributing a single program all over the file hierarchy is absurd |
| 21:19:30 | apotheon | uhh |
| 21:19:34 | Araq | I don't care if you like to mount only /bin to debug your OS etc. |
| 21:19:58 | Araq | it's 2013 and you can use a live CD/DVD instead |
| 21:19:59 | apotheon | Does the install do something other than copy a binary to the appropriate place? |
| 21:20:33 | apotheon | Is there a bunch of stuff that gets spread around somewhere. |
| 21:20:50 | Araq | sure, the stdlib goes into /usr/lib or whatever |
| 21:21:23 | NimBot | nimrod-code/nimbuild 6595937 Dominik Picheta [+0 ±1 -0]: Builder: ``git clean`` is not used to remove all untracked files |
| 21:21:37 | dom96 | damn, that was supposed to be "now" |
| 21:23:05 | apotheon | Wait -- do you mean that you think I should leave everything dumped in the git checkout, and symlink the binary to something in my path? |
| 21:23:08 | * | apotheon boggles. |
| 21:23:30 | apotheon | Maybe I won't play with the current git head, and will just use the release after all. That's kinda crazy. |
| 21:25:17 | apotheon | Git checkout gone. Starting over with the .zip. |
| 21:33:01 | dom96 | amarsahinovic: Here are my benchmark results if you're interested: web.go vs. jester: https://gist.github.com/dom96/01bcbb4c668a27cd4fb0 |
| 21:40:15 | amarsahinovic | On my machine, I get 1909.30 req/sec for web.go and 1935.81 req/sec for jester |
| 21:44:14 | reactormonk | amarsahinovic, statistical abnormalities |
| 21:49:07 | amarsahinovic | full results: http://pastebin.com/C1PHd2GF |
| 21:50:13 | amarsahinovic | and results vary from 1.2k req/sec to sometimes almost 2.5k req/sec for both web.go and jester |
| 22:00:02 | * | Trix[a]r_za is now known as Trixar_za |
| 22:20:08 | * | zahary quit (Quit: Leaving.) |
| 22:25:09 | * | amarsahinovic quit (Quit: Leaving.) |
| 22:35:57 | * | OrionPK joined #nimrod |
| 23:00:14 | * | Raynes joined #nimrod |
| 23:00:24 | Raynes | Good afternoon good sirs. |
| 23:00:31 | dom96 | hello Raynes |
| 23:00:40 | dom96 | What brings you here? |
| 23:00:59 | Raynes | I have a question. |
| 23:01:19 | Raynes | And the question is very likely the result of my not having read much documentation at all and being lazy and deciding to just ask first rather than read. |
| 23:01:53 | Raynes | So, Nimrod has first class functions. How do 'procs' fit in with this? What is a proc vs a function, and why aren't they the same thing? |
| 23:03:52 | dom96 | A 'proc' is short for 'procedure' and 'procedure' is a synonym for 'function'. |
| 23:04:20 | Raynes | So they are the same thing? I can define a proc and then pass it around by name to other procs as arguments? |
| 23:04:36 | dom96 | Yeah |
| 23:05:04 | reactormonk | Raynes, in case you encounter it, a method is a late-bound function |
| 23:05:06 | Raynes | What's the story behind choosing to call them procs as opposed to the commonly accepted and well known 'function' |
| 23:05:20 | reactormonk | Raynes, pascal iirc |
| 23:05:25 | dom96 | ^ |
| 23:05:54 | Raynes | So the name was taken from pascal? |
| 23:06:09 | dom96 | AFAIK the name 'function' is functional, whereas the name 'procedure' is procedural which is what pascal and by extension Nimrod primarily is. |
| 23:06:18 | reactormonk | Raynes, yep |
| 23:06:31 | reactormonk | dom96, oh, we have some functional stuff too, like map |
| 23:06:34 | Raynes | So, procs in Pascal are *not* first class functions. |
| 23:06:38 | reactormonk | haven't seen any monads though |
| 23:06:42 | reactormonk | ... should add some |
| 23:06:46 | Raynes | So it seems odd to use the name when it doesn't fit. :( |
| 23:06:48 | reactormonk | Raynes, maybe, I don't know. |
| 23:07:15 | dom96 | Raynes: It's just a name, why does Python use 'def', why not 'func'? |
| 23:07:25 | dom96 | or 'sub' |
| 23:07:34 | Raynes | Well, because 'def' makes sense. :p |
| 23:07:47 | dom96 | how so? |
| 23:08:12 | Raynes | Because you're defining something and giving it a name. |
| 23:08:47 | Raynes | Nimrod could have also used 'def', I imagine. |
| 23:08:56 | reactormonk | Raynes, believe me, language semantics is more important than syntax |
| 23:09:05 | Raynes | *shrug* |
| 23:10:08 | Raynes | I just think that names are important and proc is a confusing one, given that it doesn't really make sense in the context of first class functions. But hey, that's just imo. |
| 23:10:59 | dom96 | I think it makes perfect sense; like I said 'procedure' is synonymous to 'function'. |
| 23:10:59 | reactormonk | Raynes, I have stated the exact same argument, but that's too founded in the language itself. Can't change that. |
| 23:12:11 | Raynes | Okay, but I disagree. Function means something to people. |
| 23:12:26 | fowl | so they used to be called subroutines |
| 23:12:29 | Raynes | But it obviously isn't going to change, so I really just wanted to know rationale. |
| 23:12:38 | reactormonk | perl still has `sub` ;-) |
| 23:12:39 | Raynes | I'm not advocating for a major language change. |
| 23:13:24 | reactormonk | Raynes, the history is that the nimrod compiler was boostrapped in pascal - or a subset thereof. Later converted to nimrod. |
| 23:14:26 | Raynes | Thanks guys! |
| 23:16:48 | reactormonk | Raynes, what's your editor of choice? |
| 23:17:08 | Raynes | Vim or Emacs depending on which day of the week it is. |
| 23:17:14 | reactormonk | ^^ |
| 23:17:46 | reactormonk | there's nimrod support for both of them |
| 23:20:56 | rgrinberg | in OCaml there's no syntax distinction between declaring variables or functions :D |
| 23:21:12 | reactormonk | rgrinberg, they're slightly more functionally oriented |
| 23:21:42 | rgrinberg | well i'd argue any language with first class functions doesn't benefit too much from having 2 different syntaxes to bind a name to a value |
| 23:21:49 | rgrinberg | but it's a minor thing so who cares |
| 23:50:46 | Raynes | That's true. |
| 23:51:09 | Raynes | It doesn't really concern me though. |
| 23:51:36 | Raynes | I think it makes sense to have different syntax for defining functions and values because you also have var vs let for defining immutable vs mutable things. |
| 23:51:49 | fowl | rgrinberg: what are the two syntaxes you speak of (if you're saying nimrod has this) |
| 23:52:14 | Raynes | var, let for variables and values vs proc for functions. |
| 23:52:40 | fowl | it doesnt make sense to use var for functions because functions can be overloaded |
| 23:52:46 | Raynes | In Haskell, for example, they're defined the same way. But in Haskell there is no distinction between values, functions, variables, etc. There is exactly one kind of thing: an immutable value. |
| 23:52:58 | Raynes | Well, so can Haskell functions. It's a matter of syntax. |
| 23:53:10 | Raynes | And Nimrod's syntax does not fit this scheme of things. |
| 23:53:13 | Raynes | Which is fine! :D |
| 23:53:25 | fowl | var myfunc = proc(a, b: int): int = a + b |
| 23:54:46 | dom96 | fowl: To put it in a more haskell-ish way, it would be something like: var myfunc(a, b: int): int = a + b |
| 23:54:56 | dom96 | which is basically s/proc/var/ lol |
| 23:58:55 | Raynes | Anyways, I think Nimrod is far closer to Scala than it is to Haskell, ML-languages, etc. |
| 23:59:09 | Raynes | So the way it does things makes sense, even if I furiously despise the word 'procedure' |