| 00:02:14 | * | Kingsquee joined #nim |
| 00:04:03 | * | strcmp1 joined #nim |
| 00:05:57 | * | strcmp2 quit (Ping timeout: 255 seconds) |
| 00:19:16 | * | OnO quit (Quit: ZNC - 1.6.0 - http://znc.in) |
| 00:21:22 | * | strcmp2 joined #nim |
| 00:23:18 | * | strcmp1 quit (Ping timeout: 246 seconds) |
| 00:23:50 | * | ozra quit (Quit: Page closed) |
| 00:30:11 | * | OnO joined #nim |
| 00:32:19 | * | Kingsquee quit (Quit: http://i.imgur.com/EsXzoum.png) |
| 00:35:19 | * | strcmp1 joined #nim |
| 00:38:21 | * | strcmp2 quit (Ping timeout: 255 seconds) |
| 00:45:30 | * | tmm1 quit (Read error: Connection reset by peer) |
| 00:49:33 | * | opal joined #nim |
| 01:00:42 | * | opal left #nim (#nim) |
| 01:08:18 | * | chemist69 joined #nim |
| 01:11:06 | * | chemist69_ quit (Ping timeout: 240 seconds) |
| 01:18:57 | * | strcmp2 joined #nim |
| 01:21:11 | * | brson quit (Ping timeout: 264 seconds) |
| 01:21:39 | * | strcmp1 quit (Ping timeout: 252 seconds) |
| 01:22:17 | * | ano joined #nim |
| 01:24:25 | * | barosl joined #nim |
| 01:33:42 | * | CryptoToad quit (Quit: Leaving) |
| 01:49:32 | * | strcmp1 joined #nim |
| 01:52:50 | * | strcmp2 quit (Ping timeout: 272 seconds) |
| 02:04:06 | * | strcmp2 joined #nim |
| 02:08:06 | * | strcmp1 quit (Ping timeout: 244 seconds) |
| 02:34:26 | * | strcmp1 joined #nim |
| 02:35:22 | * | tmm1 joined #nim |
| 02:37:36 | * | strcmp2 quit (Ping timeout: 264 seconds) |
| 02:50:02 | * | strcmp2 joined #nim |
| 02:52:34 | * | strcmp1 quit (Ping timeout: 250 seconds) |
| 03:04:41 | * | strcmp1 joined #nim |
| 03:08:35 | * | strcmp2 quit (Ping timeout: 264 seconds) |
| 03:15:28 | * | nchambers is now known as SpruceZeusWhos |
| 03:16:21 | * | SpruceZeusWhos is now known as SprucePooseZeus |
| 03:17:49 | * | SprucePooseZeus is now known as nch |
| 03:23:24 | * | strcmp1 quit (Ping timeout: 272 seconds) |
| 03:36:19 | * | darkf joined #nim |
| 03:40:05 | * | nch is now known as nchambers |
| 04:30:10 | * | mal`` quit (Read error: Connection reset by peer) |
| 04:38:30 | * | mal`` joined #nim |
| 04:52:07 | * | vendethiel joined #nim |
| 05:02:19 | * | opal joined #nim |
| 05:14:02 | * | opal left #nim (#nim) |
| 05:33:23 | * | barosl quit (Quit: Leaving) |
| 05:33:49 | * | barosl joined #nim |
| 05:34:07 | Varriount_ | Araq: Now that we have an installer generation build for the buildbots, what should I focus on next? |
| 05:34:29 | * | Varriount_ is now known as Varriount |
| 05:37:23 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 05:47:04 | * | vendethiel joined #nim |
| 06:07:50 | * | vendethiel quit (Ping timeout: 260 seconds) |
| 06:12:41 | * | tmm1 quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 06:25:33 | * | onionhammer quit (Ping timeout: 250 seconds) |
| 06:25:34 | * | silven quit (Ping timeout: 250 seconds) |
| 06:25:43 | * | silven joined #nim |
| 06:27:24 | * | onionhammer joined #nim |
| 06:27:47 | * | nande joined #nim |
| 06:29:00 | * | bjz joined #nim |
| 06:39:13 | * | Ven joined #nim |
| 06:40:47 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 06:55:50 | * | bjz joined #nim |
| 06:58:06 | * | Ven quit (Read error: Connection reset by peer) |
| 06:58:39 | * | Ven joined #nim |
| 06:59:20 | * | Kingsquee joined #nim |
| 07:01:15 | * | Ven quit (Read error: Connection reset by peer) |
| 07:01:29 | * | Ven joined #nim |
| 07:03:18 | * | Ven quit (Read error: Connection reset by peer) |
| 07:03:25 | * | Ven joined #nim |
| 07:05:36 | * | Ven quit (Read error: Connection reset by peer) |
| 07:05:37 | * | Ven_ joined #nim |
| 07:07:33 | * | Ven_ quit (Read error: Connection reset by peer) |
| 07:08:04 | * | Ven joined #nim |
| 07:13:32 | * | xaai joined #nim |
| 07:13:44 | xaai | hello? |
| 07:16:22 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 07:16:39 | * | Ven joined #nim |
| 07:25:03 | * | xaai quit (Quit: Page closed) |
| 07:29:19 | * | Ven_ joined #nim |
| 07:29:31 | * | Ven quit (Read error: Connection reset by peer) |
| 07:31:31 | * | Ven_ quit (Read error: Connection reset by peer) |
| 07:31:41 | * | Ven joined #nim |
| 07:33:07 | * | Ven quit (Read error: Connection reset by peer) |
| 07:33:38 | * | Ven joined #nim |
| 07:35:09 | * | Ven quit (Read error: Connection reset by peer) |
| 07:35:35 | * | Ven joined #nim |
| 07:36:37 | * | Ven quit (Read error: Connection reset by peer) |
| 07:40:01 | * | Ven joined #nim |
| 07:58:55 | * | Ven quit (Read error: Connection reset by peer) |
| 07:59:02 | * | Ven_ joined #nim |
| 07:59:33 | * | Trustable joined #nim |
| 08:02:22 | * | Ven_ quit (Read error: Connection reset by peer) |
| 08:02:29 | * | Ven joined #nim |
| 08:04:10 | * | Ven quit (Read error: Connection reset by peer) |
| 08:04:33 | * | Ven joined #nim |
| 08:06:25 | * | bjz_ joined #nim |
| 08:06:51 | * | bjz quit (Ping timeout: 250 seconds) |
| 08:21:54 | * | bjz_ quit (Ping timeout: 250 seconds) |
| 08:22:49 | * | bjz joined #nim |
| 08:22:51 | Araq | "The ``ftpclient`` module is now deprecated in favour of the ``asyncdispatch`` module." |
| 08:23:31 | Araq | er ... I don't think so. but maybe in favour of asyncftpclient? |
| 08:27:36 | * | coffeepot joined #nim |
| 08:40:57 | * | Ven quit (Read error: Connection reset by peer) |
| 08:41:20 | * | Ven joined #nim |
| 08:43:24 | * | Ven quit (Read error: Connection reset by peer) |
| 08:43:25 | * | Ven_ joined #nim |
| 08:45:06 | * | Ven_ quit (Read error: Connection reset by peer) |
| 08:45:29 | * | Ven joined #nim |
| 08:50:12 | cncl | i found a bug in pasecfg but i haven't yet built nim from source for myself, so i can run any tests to see if i'm breaking something else by fixing it |
| 08:50:17 | cncl | sorry, parsecfg |
| 08:51:56 | cncl | https://github.com/nim-lang/Nim/blob/devel/lib/pure/parsecfg.nim#L260 |
| 08:52:17 | cncl | it will fails to parse something like MyNumber=-500 |
| 08:54:06 | Araq | workaround: mynumber="-500" |
| 09:32:14 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 09:37:40 | dom96 | Araq: where do you see that? |
| 09:39:46 | * | coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 09:41:06 | Araq | already update it. in news.txt |
| 09:41:10 | Araq | *updated it. |
| 09:41:13 | * | Ven joined #nim |
| 09:41:20 | * | Arrrr joined #nim |
| 09:41:38 | * | coffeepot joined #nim |
| 09:42:50 | Araq | I also patched nimble to compile with "nim devel" |
| 09:43:19 | NimBot | nim-lang/Nim devel 4548c1a rbmz [+0 ±1 -0]: added all/any/allIt/anyIt with tests and inline documentation... 2 more lines |
| 09:43:19 | NimBot | nim-lang/Nim devel 61df6dd Dominik Picheta [+0 ±1 -0]: Merge pull request #3440 from rbmz/sequtils... 2 more lines |
| 09:43:55 | NimBot | nim-lang/Nim devel c6d653f Adam Strzelecki [+0 ±1 -0]: readme.md: Open builder page from its status icon... 3 more lines |
| 09:43:55 | NimBot | nim-lang/Nim devel 8e0a103 Dominik Picheta [+0 ±1 -0]: Merge pull request #3438 from nanoant/patch/readme-link-to-builders... 2 more lines |
| 09:44:19 | dom96 | Araq: yeah, I saw that, thanks. |
| 09:45:10 | Araq | also I'm breaking tables.[] |
| 09:45:27 | Araq | will write a forum post about it once the tests pass |
| 09:52:17 | * | strcmp1 joined #nim |
| 10:13:08 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 10:15:56 | * | ibeex joined #nim |
| 10:22:47 | * | nande quit (Remote host closed the connection) |
| 10:27:25 | Araq | hi ibeex welcome |
| 10:27:45 | Varriount | Araq: How is tables.[] being broken? |
| 10:28:03 | Araq | raises KeyError exception |
| 10:28:12 | Araq | use getOrDefault for the old behaviour |
| 10:28:47 | Araq | compile with -d:nimTableGet to make the compiler list where you used tables.[] |
| 10:29:16 | Araq | works really well. I'm updating the stdlib and once the tests pass, will merge it into devel |
| 10:34:29 | * | Kingsquee quit (Quit: http://i.imgur.com/EsXzoum.png) |
| 10:49:38 | * | elrood joined #nim |
| 11:08:56 | * | strcmp1 quit () |
| 11:11:24 | * | Ven joined #nim |
| 11:20:15 | * | cryzed quit (Ping timeout: 246 seconds) |
| 11:23:10 | * | cryzed joined #nim |
| 11:28:56 | * | razaaa joined #nim |
| 11:47:16 | * | chemist69 quit (Quit: WeeChat 1.3) |
| 11:54:27 | Arrrr | Could not be added a proc to get Option[T] ? |
| 12:01:49 | Araq | I still don't like Option[T] and still see no benefit. |
| 12:14:18 | reactormonk | Arrrr, got some code here that would do it but it's still slightly buggy... |
| 12:14:50 | reactormonk | Araq, Option is basically C-style error handling, so without overhead, but enforced by the type system. |
| 12:16:10 | Araq | no. it has more overhead, both at runtime and syntactically |
| 12:17:40 | Araq | and at the end of the day an empty string is just as invalid as the None branch and so you end up doing something like: |
| 12:18:16 | Araq | if a.get("key").isnone or a.get("key").access == "": ... |
| 12:18:36 | reactormonk | a try/except is even more overhead |
| 12:19:28 | Araq | yes, but I got reports that [] returning a default value is error prone and it departs from how the scripting languages do it |
| 12:20:13 | Araq | so now [] does what the scripting languages do and as a nice bonus we can have a var version of [] that behaves identically |
| 12:20:42 | Araq | this means we also get rid of 'mget', so be happy. |
| 12:21:54 | reactormonk | So there's the choice between Option or an exception? |
| 12:22:19 | Araq | no [] always raises an exception, getOrDefault is the old [] |
| 12:22:27 | * | golak joined #nim |
| 12:22:55 | Arrrr | For primitives or structs i'd rather have option |
| 12:23:46 | reactormonk | I'm talking about design - either have it throw an exception or Option. And I assume Option is cheaper runtime than exceptions. |
| 12:23:55 | reactormonk | Probably compiletime too. |
| 12:24:14 | Araq | exception is more convenient to use, that's why we have them. |
| 12:24:38 | Araq | array[idx] doesn't return an Option either, it raises IndexError instead. |
| 12:26:10 | Araq | Arrrr: tell me a good name and we can easily add it to options.nim |
| 12:26:53 | Arrrr | for proc(table, key): Option ? |
| 12:26:58 | Araq | yes |
| 12:27:18 | reactormonk | get ? |
| 12:27:50 | Araq | a bit too generic. |
| 12:27:55 | Arrrr | Yeah, i would say get unless you want it to be more explicit |
| 12:28:16 | Arrrr | 'optionOf' |
| 12:29:07 | Araq | tab.choose("key") ? |
| 12:29:10 | reactormonk | get is what's used in scala |
| 12:29:27 | reactormonk | "choose" means one random element - ruby |
| 12:29:38 | Arrrr | i'd say choose is not less generic than get, but more rare |
| 12:29:38 | Araq | yeah, choose ain't good. |
| 12:29:56 | Arrrr | 'getOption' |
| 12:30:03 | Araq | 'asOption' |
| 12:30:14 | reactormonk | asOption is basically Some(x) |
| 12:30:18 | Araq | 'optional' |
| 12:30:25 | Araq | tab.optional"key" |
| 12:30:36 | Arrrr | ok |
| 12:31:06 | reactormonk | tab.maybe("key") ? |
| 12:31:35 | Arrrr | that's ok too |
| 12:37:19 | reactormonk | I still don't see why exceptions are more convenient to use. a) you don't handle them, then they might crash your whole programs b) you handle them with three more lines of code |
| 12:40:40 | Arrrr | I can see a exception block is more readable, but i dont know about the performance cost. |
| 12:43:50 | coffeepot | tab.select ? |
| 12:44:12 | reactormonk | An exception breaks the type checking to a certain degree - the java people tried to solve that with checked exceptions and you know the results |
| 12:46:44 | Arrrr | The optimal approach would be the functional one, you pass two functions, one in case there is a result, and the other in case there is not. |
| 12:46:57 | Arrrr | But of course, is not cheap |
| 12:47:03 | Arrrr | or at least free |
| 12:55:58 | onionhammer | hey araq |
| 12:56:02 | onionhammer | i got a fun one for you |
| 12:56:17 | onionhammer | https://www.reddit.com/r/programming/comments/3ofxy6/nim_programming_language/cvxub5c?context=3 |
| 12:56:19 | onionhammer | :P |
| 13:05:09 | * | Ven_ joined #nim |
| 13:06:01 | * | Ven quit (Read error: Connection reset by peer) |
| 13:06:02 | * | BitPuffin joined #nim |
| 13:13:06 | reactormonk | Arrrr, I guess I should have pushed my tables update for "get", eh, tool ate. |
| 13:13:09 | reactormonk | s/ate/late/ |
| 13:16:43 | * | Jesin joined #nim |
| 13:18:22 | * | Ven_ quit (Ping timeout: 265 seconds) |
| 13:24:21 | Araq | reactormonk: we solve it with our effect system and you don't seem to be aware. it works really well. IMO. |
| 13:25:25 | * | ibeex quit (Read error: Connection reset by peer) |
| 13:25:54 | Araq | also handing an exception is O(1) lines of code vs O(function call depth) for the return type handling. |
| 13:25:59 | * | ibeex joined #nim |
| 13:26:10 | OnO | what is this AppVeyor thing? 3rd CI? |
| 13:26:21 | Araq | CI for Windows. |
| 13:26:57 | OnO | ahh.. coz it doesn't work |
| 13:27:19 | Araq | yeah, not sure. worked for a short amount of time. |
| 13:27:29 | Araq | need to ask tmm when he's back |
| 13:29:44 | Araq | oh yay. more merge conflicts... |
| 13:30:41 | * | golak quit (Quit: Lost terminal) |
| 13:31:22 | OnO | btw. I made PR for defaulting to stderr and extending terminal module to work with both stdout & stderr https://github.com/nim-lang/Nim/pull/3441 |
| 13:31:30 | OnO | doing final testing of it |
| 13:33:23 | Araq | oh ffs, git is stupid. can I tell it to use *my* version of this thing? |
| 13:34:49 | OnO | git checkout --theirs or --ours |
| 13:35:10 | OnO | it is basically reversed, --ours is the one in the repo, --theirs is the one you are merging |
| 13:35:54 | Araq | like server/client for X11, huh? |
| 13:36:48 | OnO | yeah, depends what side of the fence you are at |
| 13:37:21 | OnO | I guess, --ours is "ours" in your case if you are merging foreign PRs |
| 13:37:57 | Araq | well I surely know what 'mine' is. |
| 13:39:39 | OnO | haha |
| 13:41:12 | OnO | Varriount, Araq, tmm1: you know that Travis CI works both on Linux and OS X and this AppVeyor thing on Windows, so basically we can drop whole buildbot custom infrastructure and use these 2 directly integrated with GitHub |
| 13:41:32 | OnO | I checked Travis is supposed to have ARM gcc too |
| 13:42:15 | * | Sornaensis quit (Excess Flood) |
| 13:43:07 | * | Sornaensis joined #nim |
| 13:43:30 | Araq | oh god ... now nothing works -.- |
| 13:44:21 | Araq | git merge undid all my changes. |
| 13:44:31 | OnO | btw. I recommend doing rebase rather than normal merge, it is easier and makes history linear |
| 13:44:42 | Araq | I did rebase. |
| 13:44:48 | OnO | hmm... then weird |
| 13:46:00 | Araq | well I still have the other branch that works |
| 13:46:31 | Araq | I merged my working branch into devel |
| 13:46:39 | Araq | and then did 'git pull --rebase' |
| 13:46:50 | Araq | and now it's all gone |
| 13:47:20 | reactormonk | Araq, I see your point about the effects system. I assume you can remove a raises from the callstack via exception handling. O(function call depth) is more like O(data structure depth). That's where flatMap comes in, but I think the effects should handle it. |
| 13:51:04 | Araq | git branch |
| 13:51:06 | Araq | * (no branch, rebasing devel) |
| 13:51:09 | Araq | aha |
| 13:52:10 | reactormonk | Araq, git reflog |
| 13:52:30 | Araq | git snowden? |
| 13:53:49 | reactormonk | more like git nsa |
| 13:54:00 | reactormonk | It knows everything you've done. |
| 13:55:31 | Araq | well I did git rebase --abort and git pull origin devel |
| 13:55:44 | reactormonk | that should kill a lot. |
| 13:55:49 | Araq | and now it's "green" again with god knows what version of these files |
| 13:57:22 | reactormonk | git show HEAD should tell you what the last commit changed |
| 13:57:30 | reactormonk | I've heard sourcetree isn't too bad either |
| 14:17:09 | * | saml joined #nim |
| 14:18:57 | * | pregressive joined #nim |
| 14:32:13 | NimBot | nim-lang/Nim devel 63f9385 def [+1 ±11 -0]: Rename mget to `[]`... 7 more lines |
| 14:32:13 | NimBot | nim-lang/Nim devel 4a471d8 def [+0 ±1 -0]: Don't use deprecated intsets.empty |
| 14:32:13 | NimBot | nim-lang/Nim devel d8b0edc Araq [+1 ±11 -0]: Merge branch 'mget' of https://github.com/def-/Nim into def--mget... 8 more lines |
| 14:32:13 | NimBot | nim-lang/Nim devel 2fda95a Araq [+0 ±9 -0]: added getOrDefault; bootstrapping works again |
| 14:32:13 | NimBot | 3 more commits. |
| 14:57:11 | * | jaco60 joined #nim |
| 15:05:12 | * | ibeex quit (Quit: Textual IRC Client: www.textualapp.com) |
| 15:10:33 | * | joelmo joined #nim |
| 15:26:22 | * | strcmp1 joined #nim |
| 15:28:00 | * | BitPuffin quit (Ping timeout: 255 seconds) |
| 15:30:51 | * | cryzed quit (Ping timeout: 246 seconds) |
| 15:32:37 | * | cryzed joined #nim |
| 15:36:33 | * | razaaa quit (Ping timeout: 255 seconds) |
| 15:41:23 | * | xet7_ joined #nim |
| 15:43:35 | * | xet7 quit (Ping timeout: 250 seconds) |
| 16:08:07 | * | Ven joined #nim |
| 16:10:13 | * | strcmp2 joined #nim |
| 16:11:19 | * | xet7_ is now known as xet7 |
| 16:12:34 | * | brson joined #nim |
| 16:13:00 | * | strcmp1 quit (Ping timeout: 264 seconds) |
| 16:15:20 | * | Jesin quit (Quit: rebooting) |
| 16:19:49 | * | Jesin joined #nim |
| 16:21:18 | * | Ven quit (Read error: Connection reset by peer) |
| 16:21:55 | * | Ven joined #nim |
| 16:22:58 | * | coffeepot quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 16:25:37 | * | Ven quit (Client Quit) |
| 16:31:24 | * | pregressive quit (Remote host closed the connection) |
| 16:31:48 | * | pregressive joined #nim |
| 16:32:42 | * | xet7 quit (Remote host closed the connection) |
| 16:33:10 | * | xet7 joined #nim |
| 16:33:57 | * | tmm1 joined #nim |
| 16:35:36 | * | cryzed quit (Ping timeout: 246 seconds) |
| 16:36:43 | tmm1 | good morning |
| 16:38:14 | * | cryzed joined #nim |
| 16:47:21 | * | Ven joined #nim |
| 16:49:31 | * | Ven quit (Client Quit) |
| 16:50:06 | * | Ven joined #nim |
| 16:57:59 | * | Matthias247 joined #nim |
| 16:58:53 | * | Ven_ joined #nim |
| 16:58:57 | * | Ven quit (Read error: Connection reset by peer) |
| 17:04:26 | * | silven quit (Ping timeout: 240 seconds) |
| 17:04:41 | * | silven joined #nim |
| 17:05:58 | * | Ven_ quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 17:18:08 | * | boopsiesisaway is now known as boopsies |
| 17:18:48 | * | iamd3vil joined #nim |
| 17:23:40 | * | iamd3vil left #nim (#nim) |
| 17:26:39 | * | cryzed quit (Ping timeout: 240 seconds) |
| 17:28:49 | * | cryzed joined #nim |
| 17:34:46 | * | vendethiel joined #nim |
| 17:35:53 | Araq | tmm1: hey. |
| 17:36:51 | Araq | AppVeyor is red. what's up with that? |
| 17:37:12 | * | pregressive quit (Remote host closed the connection) |
| 17:58:35 | tmm1 | red where? |
| 17:58:36 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 17:59:04 | tmm1 | the config isn't merged yet so its only running tests on the one branch |
| 17:59:10 | tmm1 | all the other branches will fail right away |
| 18:02:09 | * | joelmo quit (Quit: Connection closed for inactivity) |
| 18:04:44 | * | vendethiel joined #nim |
| 18:04:51 | * | BitPuffin joined #nim |
| 18:09:03 | tmm1 | Araq: how do i fix this failure https://ci.appveyor.com/project/Araq/nim/build/1.0.33#L2667 |
| 18:13:27 | OnO | tmm1: I am thinking we could enable Travis for OSX and try to use Linux ARM, how do I test that? you just enable Travis CI on your fork? or there's anything else |
| 18:14:02 | tmm1 | i had osx enabled before, it's not hard to do |
| 18:14:16 | tmm1 | just need to customize the build instructions and make them handle both platforms |
| 18:14:25 | tmm1 | you can create a branch, edit the travis.yml and open a PR |
| 18:14:31 | tmm1 | the PR will kick off the builds using your new config |
| 18:14:45 | * | irrequietus joined #nim |
| 18:15:22 | OnO | sounds good, can travis be used to build binary packages as well? (eg. tar.bz) |
| 18:17:13 | tmm1 | you can do whatever but you'll need to figure out where to upload them |
| 18:20:12 | OnO | maybe straight back to GitHub releases? https://developer.github.com/v3/repos/releases/#upload-a-release-asset |
| 18:22:46 | tmm1 | don't think you want a new release for every single build |
| 18:22:53 | tmm1 | esp for those on random forks and branches |
| 18:25:40 | Araq | tmm1: strange, how come it works on linux? |
| 18:25:45 | Araq | seems to be a regression |
| 18:25:47 | tmm1 | *shrug* |
| 18:28:54 | * | strcmp2 quit (Ping timeout: 260 seconds) |
| 18:32:36 | OnO | tmm1: http://docs.travis-ci.com/user/deployment/releases/ it can be programmed to upload only for tags, and that really makes sense to me, since tagging version will automatically trigger builds and upload for all platforms |
| 18:32:55 | tmm1 | yea that would work, appveyor can do that as well |
| 18:34:35 | OnO | okay let's ditch then the external buildbot :) |
| 18:34:56 | OnO | tmm1: is appveyor comaptible with .travis.yml ? |
| 18:35:18 | * | pregressive joined #nim |
| 18:35:24 | tmm1 | no |
| 18:35:41 | * | irrequietus quit () |
| 18:35:55 | * | irrequietus joined #nim |
| 18:35:58 | tmm1 | there's a PR open with a appveyor.yml |
| 18:36:04 | * | irrequietus quit (Remote host closed the connection) |
| 18:36:12 | OnO | I can't see any configuration file inside a repo, is it stored somewhere outside? |
| 18:36:31 | OnO | ahhh... okay, I though it was merged already coz I can see failing appveyor on some of my PR :) |
| 18:37:52 | tmm1 | there's still a bunch of failing tests on windows, and i don't have experience with or access to a windows machine to fix them |
| 18:38:45 | * | strcmp1 joined #nim |
| 18:39:59 | * | strcmp1 quit (Remote host closed the connection) |
| 18:40:41 | * | strcmp1 joined #nim |
| 18:41:38 | dom96 | OnO: better to upload them to our server IMO |
| 18:46:48 | * | brson quit (Ping timeout: 272 seconds) |
| 18:48:19 | * | strcmp2 joined #nim |
| 18:50:01 | * | strcmp3 joined #nim |
| 18:52:05 | * | strcmp1 quit (Ping timeout: 250 seconds) |
| 18:52:14 | Varriount | Araq, dom96: Are we switching entirely to cloud-based solutions? If so, then there's little reason for me to be working on the buildbots |
| 18:53:32 | * | strcmp2 quit (Read error: Connection reset by peer) |
| 19:01:14 | Araq | Varriount: well I'm skeptical of these cloud based solutions |
| 19:06:27 | Varriount | Araq: Howso? |
| 19:11:11 | OnO | IMHO maintaining 2 CI solutions that do essentially the same is waste of effort, or maybe there's any benefit of that? |
| 19:12:23 | * | BitPuffin quit (Read error: Connection reset by peer) |
| 19:13:37 | * | darkf quit (Quit: Leaving) |
| 19:16:41 | * | Arrrr quit (Quit: WeeChat 1.2) |
| 19:19:36 | Varriount | While I don't mind a simple Travis CI instance for testing pull requests (which is something buildbot can't do yet), there doesn't seems to be any single CI service that offers all the platforms we currently target. |
| 19:20:28 | * | ozra joined #nim |
| 19:22:34 | OnO | single not, but Travis covers all Linux + OSX, and appveyor does Windows |
| 19:22:58 | tmm1 | that still leaves arm, and 32-bit linux |
| 19:23:01 | dom96 | I would say that having both build bots and CI solutions can't hurt. |
| 19:23:18 | tmm1 | i think it makes sense to continue to use buildbot for the other platforms |
| 19:23:21 | dom96 | would be nice if we could just host our own builders for travis |
| 19:23:28 | dom96 | I have access to lots of platforms |
| 19:23:34 | Varriount | Not to mention FreeBSD (Once we actually get the build process running for that running) |
| 19:23:53 | OnO | tmm1: Travis has gcc arm cross compilers, but yes there's no arm testing |
| 19:24:08 | OnO | this is a weakness |
| 19:24:34 | * | nim-buildbot quit (Quit: buildmaster reconfigured: bot disconnecting) |
| 19:26:38 | tmm1 | why does buildbot say everything is green when tests are failing on windows? |
| 19:26:42 | * | nim-buildbot quit (Client Quit) |
| 19:27:03 | * | smodo joined #nim |
| 19:27:13 | OnO | now it looks kinda dead |
| 19:27:23 | tmm1 | i'm getting 502s http://buildbot.nim-lang.org/test-data/windows-x32-builder/7f4f37eaa20ea8aa5cf8c34e497aaa8245c590b3/testresults-651.html |
| 19:27:38 | Varriount | That's because I'm updating the buildbot |
| 19:27:47 | Varriount | -_- |
| 19:27:55 | OnO | Varriount: omg I thought you decided to tear it down ;P |
| 19:28:03 | Varriount | Not yet. |
| 19:28:20 | Varriount | tmm1: If I made it so that the buildbot failed on broken tests, there would never be any successes. |
| 19:28:26 | Varriount | Er, successful builds |
| 19:28:50 | tmm1 | the tests should all be passing on linux |
| 19:29:18 | Varriount | Araq: Should I have builds fail if there are non-passing tests? |
| 19:29:24 | OnO | yeah, I am just debating, I am neither convinced we should ditch it |
| 19:29:52 | tmm1 | imho that's the whole point of tests, if there's regressions they should be bright red and in your face and prevent you from merging any code that breaks them |
| 19:30:00 | Araq | Varriount: eventually. |
| 19:30:00 | tmm1 | but that requires they be green in the first place |
| 19:30:38 | * | brson joined #nim |
| 19:30:43 | tmm1 | Varriount: you could do it for the linux builds atleast |
| 19:32:38 | Araq | IMO the testing should just look at the diff to figure out regressions. there is no reason to have 100% green tests all the time. that's just a burden on everybody |
| 19:33:05 | Araq | right now we have a threading test that occasionally does fail because of buffering races |
| 19:33:37 | Araq | so sometimes a \n is at the wrong place. now what? stop working on the important stuff and disable this test? |
| 19:33:54 | Araq | but then it is disabled for good |
| 19:34:09 | Varriount | I do have a script that buildbot can run to compare test results, however I'm trying to figure out how to integrate it with the IRC bot. |
| 19:35:19 | Varriount | OnO: The buildbot site is back up. |
| 19:36:50 | tmm1 | if there's one known failure you can re-run the tests, or merge despite it being red because you know better |
| 19:37:08 | tmm1 | but atleast it should be red so you know something failed |
| 19:37:15 | tmm1 | instead of regressions building up without anyone noticing |
| 19:38:14 | Araq | well detecting regressions is important. but why don't our tools do that? |
| 19:38:41 | Araq | instead they are all based on the idea that the previous state was 100% green which is totally arbitrary. |
| 19:38:52 | Araq | so track the previous state properly. |
| 19:38:57 | Araq | problem solved. |
| 19:39:20 | reactormonk | Araq, but every test's gotta run111!!!! |
| 19:42:21 | tmm1 | while we're at it the tools should fix our bugs and write our features for us too |
| 19:45:33 | * | Sembei quit (Quit: WeeChat 1.4-dev) |
| 19:49:55 | Araq | tmm1: but it's not science fiction what I'm talking about. testament already does exactly that, that's why it uses a database... |
| 19:51:03 | Varriount | I will say that using a more... lightweight configuration system would be nice. |
| 19:51:30 | * | Varriount looks at the ~600 line configuration file for buildbot |
| 19:51:58 | Araq | Varriount: that's why you should write Nim programs, not "configurations" |
| 19:52:24 | Varriount | Araq: I do. Well, I write Python scripts. |
| 19:52:31 | reactormonk | Varriount, or nimscript. |
| 19:53:15 | Varriount | Araq: Using scripts dependant on the program that your trying to test is as bad as circular dependancies. |
| 19:53:38 | Varriount | For one thing, it means keeping a second, stable copy of Nim in the environment. |
| 19:53:47 | * | brson quit (Quit: leaving) |
| 19:54:01 | * | brson joined #nim |
| 19:54:32 | Araq | I don't get your point. I don't remember a regression that kept testament from compiling |
| 19:55:19 | Araq | and keeping a stable Nim around is as much effort as keeping a stable Python around. |
| 19:55:40 | Araq | except for the fact that Nim is not even 1.0 yet, ok. |
| 19:56:22 | * | strcmp1 joined #nim |
| 19:58:21 | Varriount | Araq: Except that if there's a second Nim in the environment, you get all sorts of fun with having to switch between executables, PATH variable trickery, and module dependancies. |
| 19:59:21 | * | strcmp3 quit (Ping timeout: 255 seconds) |
| 19:59:34 | Araq | well you can rename your stable nim.exe to python4.exe |
| 20:00:12 | Araq | nim.exe doesn't care what it is called. |
| 20:01:31 | Varriount | Araq: Here. After this Saturday (which is when my Cisco certification exam is) I'll work on simplifying the buildbot configuration via Nimscript |
| 20:02:20 | Varriount | Or wait, can Nimscript run subprocesses? |
| 20:02:26 | Araq | yes |
| 20:05:08 | * | SianaGearz joined #nim |
| 20:05:22 | SianaGearz | ohai nimmers. sup? |
| 20:06:07 | * | nim-buildbot quit (Quit: buildmaster reconfigured: bot disconnecting) |
| 20:06:20 | Araq | working on 0.12.0 |
| 20:07:54 | SianaGearz | thanks, benevolent dictator. just decided to check out nim for the first time, and was curious whether nim has a mechanism to deal with iterator invalidation, use-after-free, and similar kinds of typical c++ codebase faults. |
| 20:09:16 | Varriount | SianaGearz: I think it's called "garbage collection" |
| 20:09:19 | SianaGearz | i mean obviously nobody writes faulty code in the first place... except sometimes... but it has the propensity to become such with time. |
| 20:10:43 | Araq | so why haven't you moved to Ada four decades ago then? |
| 20:11:09 | Varriount | Araq: ? |
| 20:11:36 | SianaGearz | i wasn't alive 4 decades ago. 3 decades ago, spectrum basic and assembler was all i could have -.- |
| 20:12:00 | SianaGearz | Varriount: garbage collection would be roughly 1/3rd of a solution. it stops things from crashing, but if you're modifying something that you think you have a reference to but the owner no longer has, the garbage collector keeping it alive removes the crash... |
| 20:12:07 | SianaGearz | but doesn't alert to an underlying bug. |
| 20:16:12 | SianaGearz | i was being sarcastic in the statement "nobody writes faulty code" :) because fact of the matter is, 10 years in, the bugs are definitely there, and they have to have come from somewhere -.- |
| 20:16:34 | Araq | well iterators work differently. memory management works differently. the synax is different too. |
| 20:16:59 | Araq | 'var T' works differently from 'T&' |
| 20:17:51 | Araq | Nim is not D. we don't improve C++. we know Modula 3 always was the saner design to start with. |
| 20:19:00 | SianaGearz | i am not familiar with ada and modula. i used to be very familiar with Delphi a couple decades back, but it was anything but sane really apropos memory management. |
| 20:19:31 | SianaGearz | it was easy to create temporaries in expressions that couldn't be cleaned up at all and would leak. |
| 20:21:20 | Araq | yup. hence we have a GC. |
| 20:21:52 | SianaGearz | i AM familiar with D, i am excited for Rust approach to lifetime and memory management, and i was considering making something in either Rust or Nim. |
| 20:23:02 | SianaGearz | that something being a prototype open-world racing game engine with about a few hundred megabytes of stuff in RAM, and 99.9% 60fps and never more than single frame drops. |
| 20:24:13 | SianaGearz | if i did it in D, i would have a really hard time avoiding GC and GC kicking in would mean 100ms thereabouts, with their current improvements. with boehm, it would be a lot more. |
| 20:24:49 | Araq | with Nim it would be 0.5ms or something. |
| 20:25:28 | SianaGearz | which is really, really good. indeed reported high GC performance is what made me interested in the first place. |
| 20:26:44 | SianaGearz | another thing that keeps me interested is that it compiles via C or C++ compiler, and has potentially small RAM footprint even with GC, which means i could even use it for Dreamcast (Renesas SH-4 CPU) for which i have gcc, but no llvm port. |
| 20:27:16 | Araq | depends on what you do to it though, but I always thought people who can create an AAA game can pay me to make the cycle detector incremental. which currently can kill your framerates. |
| 20:28:36 | SianaGearz | i'm not AAA, i won't have any publishing money behind me, things will look like crap and will probably be open-sourced. |
| 20:29:41 | SianaGearz | look like crap, play like crap, no matter, if it runs fast enough while putting enough crappy crap on screen, i'm happy enough. |
| 20:31:17 | SianaGearz | well since you're apparently in a snarky mood, i'll let you work Araq. don't really want to distract you. |
| 20:31:22 | Varriount | Or you can just avoid cyclic references. |
| 20:31:35 | SianaGearz | that is mostly the plan, Varriount. |
| 20:31:41 | Varriount | SianaGearz: He's usually like this at this time of day. |
| 20:31:41 | Araq | I'm annoyed by the latest regression. |
| 20:36:50 | Araq | SianaGearz: I wouldn't worry about D's GC or Nim's or Rust's lack of a GC. I would try out all three and see where it gets me. At the end of day you need to avoid allocations for all 3 to get really good performance out of your system. |
| 20:37:43 | Araq | and if you avoid allocations, you have to reuse your objects. and to reuse it needs to be mutable ... |
| 20:39:51 | Araq | and sometimes wonder whether Nim's Natural and subrange data types help software quality moreso than Rust's lifetime annotations |
| 20:40:00 | reactormonk | Araq, couldn't you use the effects system to optimize a map T -> T to mutate the objects instead? |
| 20:40:53 | SianaGearz | Problem with "try out all 3" is that it'll take 9 months instead of 3 :) |
| 20:40:54 | * | strcmp2 joined #nim |
| 20:41:23 | SianaGearz | substitute random numbers here, i think i'm off by an order of magnitude. |
| 20:41:53 | SianaGearz | but i think i'll end up with about 200 000 lines of code thereabouts. |
| 20:42:11 | Araq | reactormonk: that's an optimization that's only available for Haskell right now. |
| 20:42:25 | Araq | (as far as I know, anyway) |
| 20:43:24 | Araq | SianaGearz: that's a fair point but Unreal 4 uses a GC and at least Quake 2 had the same performance with Boehm. |
| 20:43:46 | * | strcmp1 quit (Ping timeout: 260 seconds) |
| 20:44:21 | Araq | now Q2 doesn't allocate much each frame. |
| 20:44:50 | reactormonk | Araq, ah neat, didn't know they can do that. |
| 20:45:24 | SianaGearz | Araq: if you bolt Boehm onto a C or C++ codebase which is correct and stays within memory bounds, Boehm will NEVER kick in, thus its performance is irrelevant. |
| 20:45:41 | Araq | exactly. |
| 20:45:47 | SianaGearz | i mean a codebase which actually eventually frees all it allocates. |
| 20:46:20 | Araq | well my point is: they optimized the heck out of it and afterwards the GC was meaningless anyway |
| 20:47:11 | Araq | so you can say "ok, there was no advantage to having a GC" |
| 20:47:28 | Araq | but also "ok, no harm was done having a GC" |
| 20:47:41 | SianaGearz | you could use GC in those cases as leak detector essentially. but not as a solution to any given fundamental issue. |
| 20:49:05 | SianaGearz | and i'm not a team of people who will "optimize the heck out of everything". if i was superhuman, i could have just stuck to C++ like i did the last 12 years :) |
| 20:51:31 | Araq | well you can start with a streamlined design and save a couple of optimization iterations. "streamlined" design here means: modern hardware hates you and your allocations. do not allocate, reuse your stuff. |
| 20:52:00 | * | strcmp1 joined #nim |
| 20:53:23 | SianaGearz | well this is how games used to be written, with fixed size pools. but it is an extra effort because it hampers reuse of existing code that was written outside such considerations. Bullet physics library is going to allocate, certainly. and in some cases you're trading allocations for copying. |
| 20:53:25 | * | smodo quit (Ping timeout: 250 seconds) |
| 20:53:40 | * | strcmp2 quit (Ping timeout: 265 seconds) |
| 20:53:43 | SianaGearz | and it was before you had to dynamically load your objects and land tiles. |
| 20:54:19 | SianaGearz | another impediment is that if my project is to have any (limited form of) success at all, it needs in-game editor. |
| 20:54:28 | SianaGearz | again not exactly something you write without allocations. |
| 20:54:56 | SianaGearz | yer olde games relied on baked memory images where they'd just walk pointer offsets and fix them up. |
| 20:55:19 | Araq | I'm talking about the difference of |
| 20:55:25 | Araq | while true: |
| 20:55:38 | Araq | let a = returnsSomethingNew() |
| 20:55:40 | Araq | and |
| 20:55:48 | Araq | var a = returnsSomethingNew() |
| 20:55:51 | Araq | while true: |
| 20:55:56 | Araq | reuse(a) |
| 20:56:21 | Araq | it doesn't mean you have to avoid allocations in your code altogether. |
| 20:56:54 | Araq | it's essentially loop invariant code motion that the compilers still cannot do for you |
| 20:57:17 | Araq | Rust cannot do it, Nim cannot do it, D cannot do it. |
| 20:57:31 | Araq | unfortunately, of course. |
| 20:58:00 | * | nim-buildbot quit (Quit: buildmaster reconfigured: bot disconnecting) |
| 20:58:08 | SianaGearz | I am very well aware of that, thank you. |
| 20:58:27 | SianaGearz | i am very aware. but libraties are not very helpful to reducing allocations. STL isn't, Boost isn't. They all allocate. |
| 20:58:45 | cazov_ | but with stl you can write your own allocator! |
| 20:59:15 | Araq | ok, I'm sorry then. |
| 20:59:18 | * | Varriount pushes cazov_ back into his box. |
| 21:00:09 | Araq | feels very good though. usually it's the other way round and people tell me things I already know. |
| 21:01:22 | Araq | (and there are few things that I dislike more ;-) ) |
| 21:01:36 | SianaGearz | When two people tell each other things they both already know, it usually means they talk past each other. |
| 21:01:56 | SianaGearz | i bet you didn't think of that before? |
| 21:04:10 | Araq | no, I consider it a deep lack of respect. |
| 21:05:17 | SianaGearz | Have i displayed any lack of respect towards you? Well except that one time i called you "snarky". |
| 21:05:58 | Araq | no, not you. but just today reactormonk explained to me what an Option[T] is ... *cough* |
| 21:06:40 | reactormonk | >:) |
| 21:07:52 | SianaGearz | Araq: do you want me to tickle reactormonk for you? |
| 21:09:00 | SianaGearz | he will rue the day when he experiences my tickle of ultimate TORTURE. |
| 21:09:09 | strcmp1 | lol |
| 21:09:22 | SianaGearz | Mwahahahahah. |
| 21:09:51 | * | yglukhov joined #nim |
| 21:09:53 | Araq | SianaGearz: back to Nim. we have TR macros and I'm working on making the effect system eliminate the GC at compile-time to a large extend, but don't hold your breath |
| 21:10:45 | Araq | the loop invariant code motion I'd like to have is still science fiction... |
| 21:11:32 | * | Gonzih joined #nim |
| 21:11:59 | * | Gonzih quit (Remote host closed the connection) |
| 21:12:04 | SianaGearz | i heard of Nim's term rewriting, but so far i have a hard time imagining how i should find them helpful. i'll think more about them. |
| 21:16:58 | * | Varriount_ joined #nim |
| 21:18:04 | * | CryptoToad joined #nim |
| 21:18:33 | * | Varriount quit (Ping timeout: 255 seconds) |
| 21:19:06 | Araq | well it can rewrite x.toLower == y.toLower into compareIgnoreCase(x, y) for example, saving you allocations |
| 21:24:02 | SianaGearz | Which begs the question, why would i write the former in the first place. Right, because i was absent minded or forgot. |
| 21:24:20 | SianaGearz | But if i was absent-minded, what are the odds that i find that i tend to do that and introduce a rewriter later? |
| 21:25:19 | SianaGearz | And if i do, why don't i simply rewrite all those occasions? |
| 21:26:12 | SianaGearz | I don't actually mind malloc, there are plenty of REALLY fast malloc implementations. jemalloc is awesome, tcmalloc is good, and tbb malloc is supposed to be swift too. |
| 21:26:47 | SianaGearz | When things are freed quickly upon allocation, no sane malloc worth its salt fragments either. |
| 21:28:25 | SianaGearz | If i have a 200 000 line codebase, how do i comb it with a fine toothed comb to find that i'm not triggering a mark-and-sweep cycle and fix every potential occasion? |
| 21:28:46 | SianaGearz | I know that i probably shouldn't be particularly scared of M&S in Nim. |
| 21:29:02 | SianaGearz | It's more of a general observation. |
| 21:31:34 | SianaGearz | Most of the code will (unfortunately) almost never be read once it is written, or only skimmed over, unless a very tiresome analysis of some dependent code demonstrates that that code has an issue to be investigated. |
| 21:31:59 | SianaGearz | At which point, a lot of hours would be lost. |
| 21:32:45 | Araq | sorry but it doesn't "beg the question" at all. optimizers are specializers. you expose some simpler interface with fewer core constructs to the user and then optimize the special cases rather than burdening the user with it. |
| 21:33:24 | Araq | the example TR rule would be added to our stdlib |
| 21:33:54 | Araq | and speed up *your* code. |
| 21:36:38 | Araq | regarding your "very fast mallocs exist now". I disagree. they are all quite bad because they have to support a fine-grained 'dealloc' operation |
| 21:37:06 | * | boopsies is now known as boopsiesisaway |
| 21:37:58 | Araq | rather than focussing on bulk operations |
| 21:38:16 | SianaGearz | You speak of performance, but performance issues are somewhat easy to detect using a profiler. The problem that i find most frustrating in big software is maintaining correctness, even across somewhat absent-minded edits where the rest of the codebase hasn't been carefully considered. |
| 21:39:44 | SianaGearz | Also i don't even care about average performance very much as much as i care about worst-case performance. And when M&S cycle takes 100ms, that makes every line of code suspicious instead of any given section. So how would i deal with that? |
| 21:40:53 | SianaGearz | You tell me to be vigilant up front and throughout, but i'm not that perfect. |
| 21:41:02 | Araq | I speak of performance because that's what you brought up. now it's suddenly "correctness". |
| 21:41:15 | Araq | and now it's also WCET |
| 21:42:30 | SianaGearz | My apologies, it has always been WCET. I haven't worded myself clearly enough. |
| 21:44:21 | Araq | when a M&S cycle takes 100ms that's bad, but it can also mean it only takes this long every 5 minutes which might be acceptable for a game. I'm not saying it's a good thing, but productivity advantages can justify it. |
| 21:45:53 | Araq | IMHO games are not about WCET at all. |
| 21:45:58 | SianaGearz | And perhaps malloc isn't as optimal as better allocation strategies. but i ship a TERRIBLE malloc abusing application with TCmalloc, one which is universally not quite fast enough at what it's trying to do, and malloc ends up not being as much as a blip on my profiles at all. |
| 21:46:58 | SianaGearz | Of course with Windows allocator, 10% of time would be spent in malloc/free, so there's that :) |
| 21:48:51 | SianaGearz | i think it depends on the genre. i mentioned racing games because 1- or 2-frame stalls end up being very decisive and painfully noticeable if they happen at just the wrong moment. |
| 21:49:28 | SianaGearz | that actually goes for any sufficiently twitchy genre. |
| 21:50:06 | Araq | well real WCET is about "missed a dealine? - people die." ;-) |
| 21:50:40 | SianaGearz | yeah well when shipping on Windows you can't have REAL REAL WCET anyway, so i'm not going to be that anal. |
| 21:50:48 | Araq | not about "missed a deadline in 1 out of 1000 cases? some gamer is annoyed" |
| 21:51:48 | Araq | there is a reason why most people don't develop software pretending they are NASA |
| 21:54:55 | SianaGearz | So... you're telling me that i should just accept GC stalls? Why don't i ship with Mono compiled against Boehm! Half a second every minute is alright, i'm going to ba annoyed, users are going to be annoyed, but it's OK because nobody really died. |
| 21:55:31 | * | bjz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 21:55:58 | Araq | no, I'm asking you for realistic requirements. |
| 21:56:53 | * | Trustable quit (Remote host closed the connection) |
| 21:57:18 | Araq | it's not about worst cases when it's really about statistical acceptable performance. |
| 22:01:19 | Araq | honest question: how do you deal with network latencies in a racing game? |
| 22:02:40 | * | pregressive quit () |
| 22:02:57 | SianaGearz | dead reckoning. you create an illusion that when two people start at the same time and move at the same speed, that they are at the same position. |
| 22:03:59 | SianaGearz | you can use current lateral offset of other players that you received (but which obviously lies in the past) but you can dead reckon their position along the track. |
| 22:06:38 | SianaGearz | the player predominantly concentrates on making his racing line (this part depends on local performance) and he adjusts his racing line to positions and actions of other players. |
| 22:08:45 | SianaGearz | when there's latency spikes, collisions should probably be disabled, and the other player can be adjusted visually to be really close but not colliding. it's fakery. |
| 22:08:56 | SianaGearz | because if you don't, the players will see unforeseen collisions. |
| 22:15:57 | Araq | argh. |
| 22:16:02 | * | Araq found the bug. |
| 22:16:22 | SianaGearz | huggies! |
| 22:16:32 | Araq | no idea why this works on linux, makes no sense. tmm1 are you sure this thing is setup properly? |
| 22:17:01 | tmm1 | yea pretty certain |
| 22:17:14 | tmm1 | that test passes for me locally on my mac too |
| 22:17:14 | Araq | it is really nothing OS specific. |
| 22:17:25 | * | vendethiel quit (Ping timeout: 256 seconds) |
| 22:17:50 | SianaGearz | i'm curious too! |
| 22:20:56 | * | elrood quit (Quit: Leaving) |
| 22:21:39 | Araq | tobjconstr2.nim? |
| 22:21:50 | Araq | just to be sure, it's the 2, not the 1. |
| 22:22:46 | tmm1 | yep |
| 22:23:53 | tmm1 | hmm i tried again just now and its failing |
| 22:25:34 | * | bjz joined #nim |
| 22:25:39 | Araq | well it has no 'output' specification, so it only tests that it compiles |
| 22:25:59 | Araq | and compilation results are cached |
| 22:26:48 | Araq | however, the cache shouldn't be active when the produced C code changed |
| 22:28:11 | Araq | but a misbehaving cache would explain it, cause it's a recent regression |
| 22:28:41 | tmm1 | i see it failing on the travis build too, and its still green |
| 22:28:51 | tmm1 | so i guess --pedantic is indeed broken on linux as well |
| 22:28:57 | tmm1 | or its intermittent somehow |
| 22:29:12 | tmm1 | both travis and appveyor should be starting from a clean cache, since its a fresh vm |
| 22:29:47 | tmm1 | `nimble update` is also breaking now, with key not found: Transfer-Encoding |
| 22:30:01 | tmm1 | httpclient issue it seems |
| 22:30:21 | Araq | that's my changes to tables.[] :-( |
| 22:30:36 | Araq | but indeed I didn't touch httpclient |
| 22:30:48 | * | bjz quit (Ping timeout: 250 seconds) |
| 22:32:28 | SianaGearz | It helps to have turning be REALLY slow and cumbersome at high speed, so players have to slow down a lot in corners and latency issues become minor. |
| 22:35:17 | * | bjz joined #nim |
| 22:39:03 | Araq | tmm1: does the travis testing build run in parallel already? |
| 22:43:06 | tmm1 | no |
| 22:43:20 | tmm1 | it just runs koch test all --pedantic |
| 22:44:35 | Araq | er ... |
| 22:44:43 | Araq | 'koch tests' is really weird |
| 22:46:08 | Araq | anyway, you're doing it wrong. |
| 22:46:17 | Araq | koch test --pedantic all |
| 22:46:23 | Araq | it the right command. |
| 22:46:42 | Araq | Usage: |
| 22:46:44 | Araq | tester [options] command [arguments] |
| 22:46:56 | Araq | the arguments are passed over to the nim compiler... |
| 22:47:13 | Araq | or to the final test program? who knows |
| 22:47:44 | * | bjz quit (Ping timeout: 265 seconds) |
| 22:48:07 | tmm1 | that explains the strange behavior |
| 22:50:16 | Araq | ah, the options are passed to the spec section and can be accessed via $options. how useful. (not!) |
| 22:51:11 | Araq | why does 'koch test' build yet another version of the compiler? |
| 22:51:45 | Araq | makes little sense. |
| 22:52:12 | Araq | can travis do what I do and call testament directly? |
| 22:57:20 | NimBot | nim-lang/Nim devel f4bfa07 Araq [+0 ±1 -0]: updated httpclient to use tables.getOrDefault |
| 22:57:20 | NimBot | nim-lang/Nim devel a40ace6 Araq [+0 ±2 -0]: fixes regression: tobjconstr2 test works again |
| 22:57:56 | * | NimBot joined #nim |
| 22:58:58 | tmm1 | Araq: it could, but wouldn't it be better to fix koch |
| 22:59:01 | tmm1 | since buildbot uses that too |
| 22:59:13 | tmm1 | currently we build the compiler ~7 times per CI run |
| 22:59:15 | tmm1 | it makes no sense |
| 23:02:01 | Araq | ok, but I don't know who relies on this koch behaviour. |
| 23:02:38 | Araq | seems to have been done on purpose so that it tests the fresh compiler and not the one /usr/bin |
| 23:03:11 | * | Varriount_ quit (Ping timeout: 264 seconds) |
| 23:04:24 | tmm1 | the comment is pretty confusing |
| 23:04:31 | tmm1 | i guess it passes -opt:speed which might be good but i dunno |
| 23:05:09 | * | Varriount joined #nim |
| 23:08:30 | tmm1 | i don't care, what do you want me to change the command to? |
| 23:08:31 | Araq | -d:release does that too |
| 23:08:59 | Araq | tests\testament\tester --pedantic all |
| 23:09:29 | tmm1 | ok but i have to compile tester first |
| 23:09:48 | * | Varriount quit (Ping timeout: 250 seconds) |
| 23:10:01 | tmm1 | so should i just use nim c -r tests/testament/tester --pedantic all |
| 23:12:08 | Araq | I'd use 2 steps. |
| 23:12:14 | Araq | takes up less RAM then |
| 23:12:33 | tmm1 | do i need this taintmode or to use cc |
| 23:12:35 | tmm1 | like koch does |
| 23:13:35 | Araq | taintmode is good, 'cc' doesn't matter |
| 23:13:59 | Araq | I don't think 'c' will mean anything but 'cc' anytime soon |
| 23:14:42 | Araq | but fyi 'cc' means "compile to C" and 'c' means "compile with the default codegen" |
| 23:20:11 | tmm1 | got it |
| 23:20:18 | tmm1 | is it necessary to run both koch boot and koch boot -release |
| 23:20:28 | tmm1 | each boot invocation does 3 compiles |
| 23:21:14 | Araq | it's not necessary but I don't know what we should do instead |
| 23:21:28 | Araq | it's certainly a good stress test |
| 23:21:38 | tmm1 | ok |
| 23:22:04 | Araq | bootstrapping requires 3 runs and we want both a debug and a release build |
| 23:27:14 | * | saml_ joined #nim |
| 23:31:25 | tmm1 | undeclared routine: 'actionTable |
| 23:31:28 | tmm1 | new regression as well |
| 23:33:08 | Araq | ha, just noticed it too. |
| 23:36:10 | Araq | [] now returns the 'proc' by var which is uncommon |
| 23:37:31 | * | brson quit (Ping timeout: 265 seconds) |
| 23:45:27 | * | rollo joined #nim |
| 23:48:26 | * | strcmp2 joined #nim |
| 23:49:18 | * | strcmp2 quit (Client Quit) |
| 23:50:06 | * | strcmp1 quit (Ping timeout: 244 seconds) |
| 23:51:34 | * | brson joined #nim |
| 23:57:03 | * | yglukhov quit (Remote host closed the connection) |