| 00:29:59 | * | fowl joined #nimrod |
| 00:37:17 | * | fowl_ joined #nimrod |
| 00:39:01 | * | fowl quit (Ping timeout: 248 seconds) |
| 00:58:10 | * | fowl_ quit (Ping timeout: 272 seconds) |
| 00:59:43 | * | algoban quit (Quit: Leaving.) |
| 01:21:31 | * | fowl joined #nimrod |
| 04:17:56 | * | OrionPK quit (Read error: Connection reset by peer) |
| 05:53:36 | * | fowl quit (Read error: Connection reset by peer) |
| 05:56:52 | * | fowl joined #nimrod |
| 06:05:20 | * | fowl quit (Ping timeout: 272 seconds) |
| 06:27:49 | * | fowl joined #nimrod |
| 07:56:09 | * | xcombelle joined #nimrod |
| 08:03:53 | * | benedek joined #nimrod |
| 08:05:03 | benedek | Hello |
| 08:05:39 | benedek | I just noticed that strutils's "formatBiggestFloat" implementation uses a fixed buffer size which it calls "c_sprintf" on. |
| 08:06:15 | benedek | If you give a too large "precision" parameter, it's not checked and the program can crash. |
| 08:09:09 | benedek | As far as I know it's a better practice to have a dynamic buffer, but at least "snprintf" could be used (although I'm not sure if every platform has that). |
| 08:18:16 | benedek | Should I put up an issue on GitHub? |
| 08:35:27 | fowl | benedek: yea if you have an example that it will break on |
| 08:37:21 | benedek | Okeydokey |
| 08:46:18 | benedek | Done. |
| 09:51:54 | * | benedek quit (Quit: Leaving) |
| 10:01:50 | * | algoban joined #nimrod |
| 12:17:06 | * | xcombelle quit (Remote host closed the connection) |
| 13:40:42 | * | fowl quit (Ping timeout: 272 seconds) |
| 14:08:09 | * | q66 joined #nimrod |
| 14:13:56 | NimBot | Araq/Nimrod 94a131d Araq [+0 ±5 -0]: first steps to the new parser/grammar |
| 14:13:56 | NimBot | Araq/Nimrod 637bed9 Araq [+0 ±6 -0]: next steps for the new parser/grammar |
| 14:13:56 | NimBot | Araq/Nimrod 8f76108 Araq [+0 ±2 -0]: next steps for the new parser |
| 14:13:56 | NimBot | Araq/Nimrod d999171 Araq [+0 ±4 -0]: new parser works |
| 14:13:56 | NimBot | Araq/Nimrod c47b84f Araq [+0 ±4 -0]: new parsing scheme is documented |
| 14:47:05 | reactormonk | Araq, what's the advantage of the new parser? |
| 14:48:32 | * | xcombelle joined #nimrod |
| 15:08:58 | Araq | reactormonk: the new parser uses a slightly easier way to deal with indentation, has different bugs than the old one ;-) but provides more flexibility for further growth |
| 15:09:23 | Araq | for instance: |
| 15:09:26 | Araq | proc p() |
| 15:09:31 | Araq | {.pragmas here.} |
| 15:09:36 | Araq | is now supported |
| 15:10:10 | Araq | also the grammar is now embedded in comments and extracted into grammar.txt |
| 15:10:18 | Araq | so that it's way easier to keep up to date |
| 15:10:58 | dom96 | hello |
| 15:11:58 | Araq | hi dom96 |
| 15:12:07 | Araq | nimbuild couldn't checkout the branch ... |
| 15:12:33 | dom96 | :\ |
| 15:14:52 | dom96 | oh cool |
| 15:14:59 | dom96 | But it added it to the database all ok it seems |
| 15:19:50 | dom96 | I see the problem. |
| 15:20:29 | Araq | easy to fix? |
| 15:20:33 | dom96 | yeah |
| 15:21:35 | Araq | good please do so, I wonder how many tests the new parser breaks :P |
| 15:22:12 | Araq | I did check most of the stdlib though |
| 15:24:28 | NimBot | nimrod-code/nimbuild 9289111 Dominik Picheta [+0 ±1 -0]: Builder: ``git pull`` should be performed before changing branch. |
| 15:34:54 | NimBot | nimrod-code/nimbuild 5e5f137 Dominik Picheta [+0 ±1 -0]: Builder: Must restore to a branch, otherwise git pull fails. |
| 15:44:43 | dom96 | There we go, all fixed. |
| 15:44:55 | Araq | excellent, thanks |
| 15:53:13 | reactormonk | Contributors are like developers yet play an ancillary role in a project's lifecycle. Perhaps the contributor sent in a bug fix, or added some important documentation. A healthy open source project will likely have more contributors than developers. :-) |
| 16:02:47 | * | benedek joined #nimrod |
| 16:13:46 | * | benedek quit (Read error: Connection timed out) |
| 16:14:09 | * | benedek joined #nimrod |
| 16:17:19 | Araq | hi benedek |
| 16:18:40 | benedek | Hi Araq, I saw your comment to the recent issue :) |
| 16:24:39 | * | XAMPP quit (Ping timeout: 260 seconds) |
| 16:37:00 | reactormonk | Araq, maybe add in which commit it has changed. |
| 16:37:45 | Araq | well I don't know, I'm too lazy to look it up |
| 16:38:11 | Araq | git's hashes really are suboptimal for human beings :P |
| 16:38:28 | reactormonk | it's better to know where to test. |
| 16:43:40 | Araq | fyi: http://forum.dlang.org/thread/[email protected]#post-iaswdyjqbxyxvtlqljeq:40forum.dlang.org |
| 16:44:26 | dom96 | whoa deja vu |
| 16:45:11 | * | benedek quit (Quit: Got to go) |
| 16:45:22 | dom96 | oh but someone mentioned Nimrod. |
| 16:56:29 | dom96 | Araq: I like your answer |
| 16:59:42 | Araq | yay thanks |
| 17:06:11 | * | Madison joined #nimrod |
| 17:06:11 | * | Madison quit (Changing host) |
| 17:06:11 | * | Madison joined #nimrod |
| 17:06:38 | Araq | welcome algoban, Reiser |
| 17:07:01 | Reiser | Araq: It's been a while, thanks |
| 17:08:36 | reactormonk | somehow no one uses emacs here :-/ |
| 17:08:48 | * | Madi joined #nimrod |
| 17:09:06 | Araq | emacs is a great OS, but a shitty editor, they say, reactormonk ;-) |
| 17:09:17 | reactormonk | Araq, that's why I use evil |
| 17:09:40 | reactormonk | http://developers.slashdot.org/story/13/02/16/0251239/evil-almost-full-vim-implementation-in-emacs-reaches-10 |
| 17:10:34 | Reiser | That is insane |
| 17:11:09 | Araq | reactormonk: I hope you're kidding |
| 17:11:17 | reactormonk | Araq, hell no |
| 17:11:30 | reactormonk | now I have org-mode and vim keybindings. |
| 17:11:35 | Reiser | Does it support vimscript? The plugin ports suggest it doesn't |
| 17:11:52 | reactormonk | Reiser, no? it's elisp all through. It's only the keybindings. |
| 17:12:08 | Reiser | Sham |
| 17:12:09 | Reiser | e |
| 17:12:35 | reactormonk | for vimscript emulator, you'd have to reimplement all of vim on top of emacs |
| 17:12:38 | * | Madison quit (Ping timeout: 255 seconds) |
| 17:12:48 | Reiser | That's what I was hoping for rofl |
| 17:13:29 | reactormonk | why? |
| 17:13:45 | reactormonk | if you prefer python, you could also try sublime ;-) |
| 17:14:09 | Reiser | Because if I could just drop my .vim/ onto emacs, and have exactly what I have now, but with everything emacs has, then I could justify trying to learn to use emacs |
| 17:14:24 | reactormonk | ask in #emacs for equivalent libraries |
| 17:14:34 | Reiser | Exactly, I don't want to have to do that |
| 17:14:37 | Reiser | I'm comfortable in vim |
| 17:15:52 | Reiser | I just happened to learn vim first, don't have the energy to do it again |
| 17:16:05 | * | Madi is now known as Madison |
| 17:16:26 | * | Madison quit (Changing host) |
| 17:16:27 | * | Madison joined #nimrod |
| 17:21:06 | dom96 | I don't have the energy to learn vim or emacs which is why I'm creating my own text editor :P |
| 17:23:18 | reactormonk | Reiser, org-mode is worth it |
| 17:24:22 | Reiser | reactormonk: There's a vim plugin for it it seems |
| 17:24:56 | * | reactormonk quit (Read error: Operation timed out) |
| 17:26:21 | apotheon | I spent a little time learning to use emacs, and the end result was that I could do some of the stuff I do in vi, and could probably (with a lot more learning) do *all* the stuff I do in vi, but all if it was harder. |
| 17:26:41 | apotheon | . . . so I gave up on emacs and promptly forgot pretty much everything I had learned. |
| 17:27:24 | Araq | my fear is VIM would make me unlearn all the shortcuts that work everywhere else ;-) |
| 17:27:31 | Reiser | Rofl, I did try reading about how modes worked in emacs and even that seemed overly complex to me |
| 17:28:07 | Reiser | Araq: I can understand that, I already use vi anywhere I have an option, zsh etc |
| 17:28:17 | Reiser | So that I don't have to make the mental context switch all the time |
| 17:31:05 | apotheon | Araq: I just make sure "everywhere else" uses the same shortcuts. |
| 17:31:22 | Araq | plus I don't believe an editor created for some weird archaic baud limitations can be convenient to use :P |
| 17:31:49 | apotheon | Basically all shells have a vi editing mode; both Xombrero and Firefox+Pentadactyl provide excellent vi-like interface experiences for web browsing; et cetera. |
| 17:31:49 | Reiser | Araq: You'd be amazed |
| 17:32:07 | Reiser | The only time I've ever found it inconvenient |
| 17:32:22 | Reiser | Is when I used another system with vim compiled with stupid flags, and something I'm used to existing is now gone |
| 17:33:05 | Reiser | Which is basically how I feel with every other editor I use that's not vim now |
| 17:34:32 | dom96 | I believe that advanced text editing features should be implemented alongside traditional controls. |
| 17:34:46 | dom96 | The only thing that emacs/vim manages to do for me is to irritate me. |
| 17:35:41 | Araq | making me press ESC is not user friendly |
| 17:35:45 | dom96 | I like to learn in small steps, not change my habits completely. Which is what those editors require. |
| 17:36:37 | * | reactormonk joined #nimrod |
| 17:36:39 | Reiser | Esc is annoying, but the benefits that come from it are worth it |
| 17:36:52 | Reiser | There's nothing stopping you from adding 3 or 4 lines to .vim to have it stay in insert mode and behave like any other editor |
| 17:37:13 | Reiser | But then there's not much point, and I guess anyone who does that is going to be annoyed that vim doesn't do that by default |
| 17:37:28 | Araq | *shrug* typing is not a bottleneck for me anyway |
| 17:37:49 | dom96 | Even in its raw form, vim behaves very differently to modern text editors. |
| 17:37:57 | apotheon | Araq: Using vi-like editors for maximum value involves reorienting how you think about editing. It's not that you have to press ESC to do some stuff, and the rest of the time it's a "normal" text editor: it's actually a highly advanced text processing system that allows you to enter a text-entry mode until you hit ESC. |
| 17:38:07 | dom96 | One of the things I found annoying is that the cursor will not be saved where you left it. |
| 17:38:11 | dom96 | It will move as you scroll. |
| 17:38:27 | Araq | yeah |
| 17:38:31 | Reiser | I don't think vim really fixes typing bottlenecks, It's movement and large text changes that you want from it |
| 17:38:37 | Reiser | Also I'm not sure what you mean by the cursor movement? |
| 17:38:51 | Araq | that's deadly for those of us who use the cursor as a reminder where to go back to |
| 17:39:08 | dom96 | exactly. |
| 17:39:15 | apotheon | Reiser: Maybe he's talking about the cursor going to the beginning of the line when using Ctrl-D or something like that. |
| 17:39:24 | Reiser | Yeah if you're using a cursor you don't want to be using vim, at all |
| 17:39:39 | dom96 | What i'm talking about if the cursor always staying in your viewport. |
| 17:39:42 | dom96 | *is |
| 17:40:00 | Reiser | Ah I see, as in, you might scroll down a ton, but hitting a will jump back up and type where you left it |
| 17:40:03 | apotheon | Oh, that. |
| 17:40:09 | Reiser | a key* |
| 17:40:11 | apotheon | Weird. |
| 17:40:32 | Reiser | Yeah I can see why you would want that, I wouldn't mind having that behaviour somehow |
| 17:40:37 | apotheon | dom96: There are ways to see a different part of the document than where you have your cursor, without scrolling the buffer with the cursor in it. |
| 17:40:38 | Reiser | I use marks to get what you're talking about |
| 17:40:50 | apotheon | Marks work, too. |
| 17:40:59 | Reiser | But It's definitely not the nicest solution to have to hit `. every time you want to go back to where you left your editing cursor |
| 17:41:14 | dom96 | Yeah. I know. But that requires a change of habit. |
| 17:41:18 | Reiser | Yeah it does |
| 17:41:27 | apotheon | Reiser: Why isn't that a good solution? |
| 17:41:55 | Reiser | apotheon: well the whole selling point of vim is do more with less keys, this is one of those cases where you need more keys to do something |
| 17:42:10 | Reiser | Every other editor you just type, vim needs you to jump back to your mark |
| 17:42:11 | apotheon | Reiser: Otherwise you have to use a mouse, which is much worse than just hitting two keys. |
| 17:42:19 | apotheon | err, one key |
| 17:42:31 | Reiser | apotheon: It's worse than that, It's not about the mouse |
| 17:42:31 | apotheon | Oh, I see. |
| 17:42:38 | apotheon | The typing-jump-thing. |
| 17:42:39 | Reiser | If you are typing say, in the () on line 45 |
| 17:42:45 | Reiser | And you scroll down 200 liens to check something |
| 17:42:58 | Reiser | And you want to be able to just start typing and have the editor immediately writing where you left your cursor |
| 17:43:03 | apotheon | For that, use buffer tricks so you can see both at the same time. |
| 17:43:03 | Reiser | That's not an easy motion in vim |
| 17:43:10 | Reiser | But happens automatically in pretty much any other editor |
| 17:44:39 | apotheon | I'd rather hit a key to get back than have to use the mouse to scroll down in the first place. Context-switching is murder on flow. |
| 17:51:23 | Araq | ESC is almost a context switch too IME |
| 17:52:23 | apotheon | Are we playing horseshoes? |
| 17:52:45 | apotheon | It's only a context-switch if you're using vi primarily as an editor, and only reluctantly as a text-processing system. |
| 17:53:28 | Araq | *shrug* I use scripts for text processing ... |
| 17:57:12 | apotheon | That's appropriate for robotically repeated tasks. |
| 17:58:11 | apotheon | More specifically, vi-like editors offer guided text processing capabilities with an efficient interface, as opposed to predefined fire-and-forget text processing task automation bundles. |
| 17:59:42 | Araq | what would that be? I can only think of search&replace with confirmation ;-) |
| 18:02:30 | apotheon | What would what be? |
| 18:03:03 | apotheon | Guided text processing? Efficient interface? Task automation bundles? What, exactly? |
| 18:03:18 | Araq | what's a "guided text processing capability"? please give an example |
| 18:03:46 | Reiser | Araq: most used shortcuts for me are text selection, two keys to delete an entire block of code, another two to move to the function definition and be adding a new argument, three of four keys to insert a string at the beginning of every element in an array |
| 18:03:53 | Reiser | Those kinds of things are what keep me around at least |
| 18:04:09 | apotheon | text processing where you decide in the moment exactly what you want it to do while still being able to rely on automation to abstract away the tedious details of accomplishing the task |
| 18:04:30 | apotheon | e.g. combining two lines of text |
| 18:04:34 | apotheon | . . . and more complex stuff |
| 18:06:27 | Araq | Reiser: I see; that requires the editor to understand the programming language though |
| 18:06:41 | apotheon | not necessarily |
| 18:06:44 | Reiser | Araq: you are right, but vim comes with a folder of plugin/s that understand most languages |
| 18:06:49 | Reiser | For nimrod, you would have to write one |
| 18:06:52 | Reiser | That's a pain |
| 18:06:54 | apotheon | depends on the specific tasks |
| 18:06:56 | Reiser | but only one person has to |
| 18:07:10 | Araq | Reiser: there is a vim plugin for nimrod maintained by a core dev |
| 18:07:18 | Reiser | Araq: then what's the complaint? ;p |
| 18:07:36 | Reiser | There's also a ton of selections that aren't language specific which are just as help ful |
| 18:07:43 | apotheon | Typing "/main(" doesn't require the editor to understand the programming language, for instance. |
| 18:07:49 | apotheon | d% doesn't either |
| 18:07:56 | Reiser | like 'select inside some [] brackets', and even without knowing about C, vim doesn't need to know C to understand 'select inside {}', which you could use to do the |
| 18:07:59 | Reiser | move about functions I mentioned above |
| 18:08:35 | Araq | apotheon: that's not quite correct, the 'main' could be in a string literal |
| 18:08:49 | Araq | of course it could be that you do want to see that occurance too |
| 18:09:06 | Reiser | To be fair |
| 18:09:07 | apotheon | Araq: type n next |
| 18:09:08 | Reiser | If you're doing /main( |
| 18:09:15 | Reiser | You're probably making life way too hard on yourself |
| 18:09:21 | apotheon | Reiser: that too |
| 18:09:21 | Reiser | when you can use ctags |
| 18:09:23 | Reiser | and jump straight to it |
| 18:09:32 | Araq | it's a "find code" vs. "find text" issue |
| 18:09:37 | Reiser | and ctags will definitely be looking at the main definition |
| 18:09:41 | apotheon | I haven't learned ctags yet, but it's on my todo list. |
| 18:09:55 | apotheon | I was talking about language-nonspecific ways to do things, though. |
| 18:10:10 | Reiser | I think |
| 18:10:20 | Reiser | Any editor that tries to do everything non language specific is going to fail |
| 18:10:30 | apotheon | no doubt |
| 18:10:45 | Reiser | If your complaint is vim can't find main without knowing what language It's looking at |
| 18:10:46 | Araq | Reiser: I'm not really complaining, just wondering what features are worthwhile to steal for Aporia |
| 18:10:48 | apotheon | Still . . . vi offers better coverage with language-nonspecific approaches than anything else I've seen. |
| 18:10:57 | Reiser | Then you're asking for some god-tier level understanding of text |
| 18:11:17 | apotheon | Araq: If you're not willing to "steal" modal editing, you've eliminated most of what makes vi excellent. |
| 18:11:54 | Reiser | apotheon: true, and the fact you can achieve 'find main' with some degree of accuracy is |
| 18:11:59 | Reiser | pretty proving of why It's good |
| 18:12:00 | Araq | apotheon: yeah but then if we steal that we may as well stop developing aporia and switch over to vi instead |
| 18:12:16 | Reiser | Because you can hit gD and vim does a really |
| 18:12:18 | Reiser | really good job |
| 18:12:22 | Reiser | of finding definitions specifically |
| 18:12:24 | Reiser | without knowing the language |
| 18:12:37 | apotheon | Araq: That's why I'm not developing Aporia! |
| 18:16:48 | Reiser | Not trying to make out like vim is the best thing ever here by the way, just that the pain of modal switching is worth it |
| 18:16:58 | Reiser | if you use the mode for what It's for |
| 18:17:36 | apotheon | I don't really notice any pain, maybe because it's far less than the pain of other editors' imposed context switching models. |
| 18:17:46 | Reiser | I think most people who dno't use vim regularly only ever exit to normal mode to save or open a new file, makes me wonder why |
| 18:17:59 | Reiser | Distro maintainers don't include a vimrc with Ctrl+W or something bound to save and input mode by default |
| 18:18:13 | Reiser | I don't think anyone would mind except people who actually use vim, who will have 600MB .vim/'s anyway |
| 18:18:17 | apotheon | Honestly, pretty much all editors -- all of them anyone would be likely to want to use, anyway -- are modal. Most just aren't explicitly modal. |
| 18:18:41 | apotheon | There's text-field mode, and menu mode, and search-and-replace mode, and so on. |
| 18:19:02 | apotheon | In addition to having to change the modes of use when doing these things, you also have to change the interface you use, though. |
| 18:19:28 | Reiser | apotheon: that's what I'm getting it, I think if vim was input mode by default, with Ctrl+* bound to reasonable things that people expect |
| 18:19:33 | Reiser | people would have a lot less problem with vim |
| 18:19:48 | apotheon | Reiser: One of Vim's annoying problems is the fact it calls command mode "normal mode". It confuses things. |
| 18:19:59 | Reiser | Rofl |
| 18:20:26 | Reiser | Been using vim like, 3 years, and I've never had an editor discussion before, this is like the most pointless conversation ever |
| 18:20:36 | Reiser | But I can see the fun |
| 18:20:48 | apotheon | heh |
| 18:20:51 | Reiser | At least, not a serious one |
| 18:21:50 | Reiser | Sublime's pretty nice, just to change the focus a bit |
| 18:22:15 | apotheon | meh |
| 18:26:21 | apotheon | I'm gradually teaching my SigO to get the most out of vi-like editors. She uses Vim, but not terribly optimally at the moment. |
| 18:27:22 | apotheon | Unfortunately for her, she has to use some Oracle-oriented tools at work, which kinda interferes with her learning process for Vim. |
| 18:27:58 | apotheon | She can get away with using SciTE at work sometimes, but it doesn't get much better than that. |
| 18:36:57 | * | Madison is now known as MadiKitty |
| 18:42:51 | Araq | hrm the old parser allowed: |
| 18:42:56 | Araq | newButton(onClick = proc(b: PButton) = |
| 18:42:57 | Araq | var requestomat = 12 |
| 18:42:59 | Araq | ) |
| 18:43:10 | Araq | the new one requires: |
| 18:43:14 | Araq | newButton(onClick = proc(b: PButton) = |
| 18:43:16 | Araq | var requestomat = 12 |
| 18:43:19 | Araq | ) |
| 18:43:35 | Araq | any opinions? |
| 18:44:22 | * | MadiKitty quit (Quit: Leaving) |
| 18:44:57 | dom96 | hrm, I think that's fine. |
| 18:45:05 | Araq | it breaks code though |
| 18:45:17 | Araq | and it seems easy to support the old style |
| 18:45:17 | * | fowl joined #nimrod |
| 18:45:39 | Araq | hey fowl, please read what I just wrote in the logs |
| 18:45:42 | apotheon | I prefer the second version, so I don't have much of an opinion, I guess. |
| 18:46:20 | Araq | well surely the 2nd version is nicer |
| 18:46:42 | apotheon | Some people would disagree with that, but I'm not sure how much they should be enabled. |
| 18:47:33 | Araq | meh, I'm trying to support the old way, we can deprecate it later |
| 18:47:50 | Araq | deprecation warnings are much nicer than breaking code |
| 18:47:59 | dom96 | Can you add a deprecation warning easily? |
| 18:48:15 | Araq | dom96: looks like it, yeah |
| 18:48:29 | dom96 | go for it then |
| 18:49:07 | * | Madison joined #nimrod |
| 18:49:07 | * | Madison quit (Changing host) |
| 18:49:07 | * | Madison joined #nimrod |
| 19:01:17 | reactormonk | Araq, so you reworked the indentation parsing? |
| 19:01:49 | Araq | yeah |
| 19:02:16 | Araq | I also invented new operators for specifying a grammar ;-) |
| 19:02:28 | Araq | I figured EBNF is a pita |
| 19:03:06 | reactormonk | which parts? |
| 19:03:26 | Araq | 1.) no higher order rules |
| 19:03:46 | Araq | 2.) lack of useful operators like / and ^* |
| 19:31:15 | apotheon | Araq: I agree, by the way, about deprecation vs. breakage. |
| 19:44:08 | * | Madison quit (Quit: Leaving) |
| 19:45:36 | * | xcombelle quit (Remote host closed the connection) |
| 20:04:44 | NimBot | Araq/Nimrod e144b8b Simon Hafner [+0 ±1 -0]: added toSeconds and fromSeconds to times. fixes #334 |
| 20:04:44 | NimBot | Araq/Nimrod 1e9ff02 Araq [+49 ±2 -0]: added manyloc test suite; --path now relative to project dir if not absolute |
| 20:04:45 | NimBot | Araq/Nimrod 321e32d Araq [+0 ±1 -0]: Merge pull request #384 from Tass/master... 3 more lines |
| 20:04:45 | NimBot | Araq/Nimrod 1ec2e11 Dominik Picheta [+0 ±1 -0]: Fixed incorrect drawing of rectangles by graphics.drawRect. |
| 20:04:45 | NimBot | Araq/Nimrod e0b592a Dominik Picheta [+0 ±6 -0]: Fixed recvLine deprecation warnings. |
| 20:06:48 | dom96 | looks like NimBot needs to include the branch in the commit notifications |
| 20:07:03 | Araq | indeed |
| 20:10:10 | reactormonk | what happend to the GSoC? |
| 20:10:23 | Araq | you didn't push me enough |
| 20:12:12 | reactormonk | gone thne |
| 20:26:50 | fowl | Araq: i dont see a difference in the examples |
| 20:26:58 | fowl | the newbutton() ones |
| 20:27:29 | fowl | the irc logs should probably be <tt>'d |
| 20:27:53 | fowl | assuming indentation was lost |
| 20:28:58 | Araq | fowl: hrm, well it's about the final closing ) |
| 20:29:24 | fowl | does it have to be lined up with the opening one now |
| 20:29:25 | Araq | but anyway, I kept backwards compatibility so it should be fine now |
| 20:29:50 | Araq | lol |
| 20:30:04 | Araq | hrm the old parser allowed: |
| 20:30:08 | fowl | i like to close nests of parens like ) ) ) so they line up with opening and closing columns |
| 20:30:31 | Araq | newButton(onClick = proc(b: PButton) = |
| 20:30:32 | Araq | var requestomat = 12 |
| 20:30:34 | Araq | ) |
| 20:30:39 | Araq | the new one prefers: |
| 20:31:21 | Araq | newButton(onClick = proc(b: PButton) = |
| 20:31:23 | Araq | var requestomat = 12 |
| 20:31:24 | Araq | ) |
| 20:32:37 | fowl | will this still work https://gist.github.com/fowlmouth/53262795290d4327ae21 |
| 20:34:31 | Araq | good question |
| 20:38:07 | fowl | hey I tested if this worked right but could you verify |
| 20:38:17 | fowl | type PObject = ref TObject |
| 20:38:30 | fowl | type PSubObj = ref object of PObject |
| 20:38:58 | fowl | ^ will actually make TSubObj inherit from TObject |
| 20:39:12 | Araq | that's the intention yes |
| 20:39:32 | fowl | cool |
| 20:48:50 | reactormonk | dom96, btw, add http://developer.github.com/v3/repos/statuses/ to the build farm? |
| 20:51:44 | dom96 | yeah, it's on my todo list. Although building all pull requests may prove quite costly. |
| 21:09:50 | * | Madison joined #nimrod |
| 21:09:50 | * | Madison quit (Changing host) |
| 21:09:51 | * | Madison joined #nimrod |
| 21:10:43 | Araq | sometimes I wish to inhibit nimbuilds auto building feature |
| 21:11:08 | Araq | maybe it can check for "(nimbuild:off)" in the commit message? :P |
| 21:15:07 | * | Trix[a]r_za is now known as Trixar_za |
| 21:20:24 | Araq | fowl: your gist still parses |
| 21:21:45 | dom96 | Araq: I think I should just make it build at some set time. |
| 21:21:59 | dom96 | Araq: And allow you to force a build maybe |
| 21:23:08 | Araq | hrm |
| 21:23:23 | Araq | that might make things worse |
| 21:23:33 | Araq | I'm now used to not do anything after a push |
| 21:23:39 | dom96 | lol |
| 21:52:58 | * | Madison quit (Quit: Leaving) |
| 22:08:41 | JStoker | dom96: I do think building all pull requests would be a rather good idea. (You could possibly adjust your code so that it prioritises builds which are to the master or whatever, and queue pull requests up when there's nothing else due. Don't know how hard that'd be, but you know. :-)) Just my two pennies. :) :p |
| 22:25:27 | * | algoban quit (Ping timeout: 252 seconds) |
| 22:32:37 | dom96 | JStoker: Yeah, well the problem is that running the full test suite takes quite a long time. Doing it for each pull request could be too much. Especially if a pull request changes something small. |
| 22:33:56 | * | Trixar_za is now known as Trix[a]r_za |
| 22:34:05 | JStoker | That's the reasoning behind only doing it if there's not anything more important to build... That being said, I'm not sure on what you've got in terms of CI, so I don't know if it's possible for you to have it suspend the tests if there's something more important. |
| 22:34:56 | JStoker | dom96: One potential solution may be just wait a hour or so. If it's something small (and they prod you in here, or whatever) and you do merge it already, then it's not really a problem. |
| 22:35:32 | JStoker | dom96: I'd personally say just go for it, it's not as if your CPU power can run out. |
| 22:38:35 | dom96 | Indeed. I've already considered many solutions. |
| 22:38:44 | fowl | dom96: im hung up on this component lib on how to handle communication between components |
| 22:39:08 | dom96 | Currently one of the builder runs on my linode so it would be preferable it if doesn't use 400% CPU constantly. |
| 22:39:29 | fowl | use `nice`? |
| 22:39:40 | JStoker | dom96: nice it down a tonne? |
| 22:40:01 | * | OrionPK joined #nimrod |
| 22:40:07 | JStoker | oh, well done fowl :p |
| 22:40:18 | JStoker | dom96: And, reboot your linode so that it can use 800% CPU! :D |
| 22:41:01 | JStoker | dom96: Unsure how the build system is setup, but if it reacts nicely to SIGSTOP/SIGCONT, those may be a good method of a hackish "pause/resume" thing. <naive> |
| 22:41:02 | dom96 | Still, I would be afraid that Linode might get angry because of the high CPU usage. |
| 22:41:20 | JStoker | dom96: eh, there's not /that/ many pull requests done for nimrod though, is there? |
| 22:41:39 | JStoker | dom96: How long do the CI tests take? Hours? Days? Weeks? :3 |
| 22:41:50 | dom96 | Not currently. But the amount will increase. |
| 22:41:55 | dom96 | A lot i'm sure. |
| 22:42:30 | dom96 | ~15 minutes. |
| 22:42:49 | dom96 | That's together with bootstrapping. |
| 22:42:49 | JStoker | dom96: Linode will go tell you if you're being abusive (Possibly want to send a ticket in advance just so they know, although i doubt they care), so I wouldn't worry too much about that. |
| 22:43:18 | dom96 | I could also just move the x86 builder onto the gcc farm. |
| 22:43:20 | JStoker | That's really not that bad, heh. As long as you don't have more than a pull request every 20m or so, it shouldn't be too much of a burden. |
| 22:43:43 | JStoker | Indeed, if you find it's too much for one machine, poke someone else to set one up and share the load! |
| 22:44:19 | dom96 | But other arrangements may need to be made for personal builders, like gradha's builder. |
| 22:44:29 | dom96 | Which runs on his macbook. |
| 22:44:39 | * | Madison joined #nimrod |
| 22:44:47 | dom96 | I'm sure he would not like for it to be constantly compiling things. |
| 22:45:56 | JStoker | Indeed, possibly make it so that people can say "I don't want to compile pull requests" or whatever. Or tell him to just nice it down, or whatever. I don't know. :-) |
| 22:46:06 | Araq | dom96: I'm already making the tests larger instead of making ever more tests |
| 22:46:21 | Araq | because I don't want them to take more than 15 minutes |
| 22:51:12 | dom96 | fowl: About your component lib. Got any more info? |
| 22:51:31 | dom96 | Araq: What do you think about JStoker's suggestions? |
| 22:56:03 | Araq | SIGSTOP/SIGCONT is hackish and I can't see what it does solve |
| 22:56:21 | Araq | you already have a nice state machine for the builder |
| 22:56:24 | * | Madison quit (Quit: Leaving) |
| 22:56:51 | JStoker | It's only as a "pause the current build" or whatever (I have *ZERO* idea what your build system is like, or any of that, so I highly expect there's a better solution!) to build a more important commit or whatever. |
| 22:56:57 | JStoker | If there's a better way, use that! (Please! :p) |
| 22:57:35 | dom96 | I think it would be fine to just finish building whatever build is currently running. |
| 22:58:03 | JStoker | That's also a perfectly valid solution too! :) |
| 23:02:12 | Araq | meh ... it should wait for 10 minutes to make sure no other request is coming |
| 23:02:38 | Araq | however it may be forced with some nimbot command |
| 23:03:16 | JStoker | Yeah, that's a decent solution. |
| 23:08:22 | dom96 | good night |
| 23:08:30 | Araq | same here, good night |
| 23:08:31 | fowl | dom96: waaaitt |
| 23:08:52 | dom96 | fowl: go on then! :P |
| 23:09:19 | fowl | https://gist.github.com/fowlmouth/5439372 |
| 23:11:51 | Araq | fowl: you need to learn about the new object constructors |
| 23:12:13 | Araq | new result; result.x = x; result.y = y is old fashioned ;-) |
| 23:12:24 | fowl | whats the new way |
| 23:12:27 | Araq | result = CPos(x: x, y: y) |
| 23:12:43 | fowl | that will allocate a new one too? |
| 23:13:19 | Araq | it will invoke 'new' for a ref type, yes |
| 23:13:41 | fowl | neat |
| 23:14:40 | Araq | I don't like your 'ref' happiness though ;-) |
| 23:14:49 | dom96 | argh, I'm not sure I can help you. Maybe Araq can :P |
| 23:15:02 | Araq | CPos has 2 floats, no need to make that 'ref object' |
| 23:15:19 | dom96 | bye |
| 23:15:32 | Araq | I'm not sure what you mean |
| 23:15:43 | Araq | but it looks to me you simply want to use methods? |
| 23:16:01 | Araq | method draw(e: PEntity) = assert false |
| 23:16:30 | fowl | Araq: i need it for other components where i need inheritance |
| 23:16:41 | Araq | method draw(c: PCarl) = # draw the circle |
| 23:17:25 | fowl | Araq: i dont want to write code for individual entities, having a CCircular and CPos is all you need to be draw as a circle |
| 23:20:29 | Araq | method draw(x) = moveTo(x.position); draw(x.rendr) |
| 23:20:35 | Araq | I dunno |
| 23:21:01 | fowl | are there generic methods now? |
| 23:21:06 | Araq | yeah |
| 23:21:12 | fowl | :O that is probably what i want |
| 23:21:20 | Araq | perhaps |
| 23:21:30 | fowl | method draw(some: CRenderable; entity: A; R: sdl2.PRenderer) |
| 23:22:12 | Araq | generic instantiation for methods had some semantic issue that I can'r remember |
| 23:22:47 | Araq | but it should work |
| 23:26:25 | fowl | method draw(some: CRenderable; entity: A; R: sdl2.PRenderer) |
| 23:26:35 | fowl | er |
| 23:29:09 | fowl | its not working right https://gist.github.com/fowlmouth/5439372 the default draw() is getting called |
| 23:29:43 | fowl | wait lemme update nimrod>_> |
| 23:30:01 | Araq | the problem is that draw for CCircular is not instantiated |
| 23:30:21 | Araq | and so can't participate in the dynamic call |
| 23:30:38 | Araq | you need to instantiate it explicitly and then it should work |
| 23:30:45 | Araq | I know it's ugly |
| 23:31:04 | Araq | but it seems far worse to instantiate every possible method "just because" |
| 23:31:24 | fowl | how do I do that? discard draw[CCircular] ? |
| 23:31:59 | Araq | yeah it's worth a try *cough* |
| 23:33:58 | fowl | need another pragma >_> |
| 23:34:24 | fowl | {.instantiateIrregardless.} |
| 23:34:46 | Araq | I'll think about the problem again :-) |
| 23:34:58 | Araq | looks pretty hard to solve thouhg |
| 23:35:01 | Araq | *though |
| 23:35:25 | Araq | c++ doesn't support virtual templatized functions either |
| 23:36:55 | Araq | however, how do that component stuff work? |
| 23:37:15 | Araq | you've got rectangles and circles and then what? |
| 23:37:54 | Araq | how many of these primitives even have an algorithm how to draw it? |
| 23:38:38 | fowl | well i've been reading a lot of c++ example systems and it looks like they abuse templates and static vars to do stuff like entity.getComponent<CPos>.doStuffWithIt.. |
| 23:39:17 | fowl | Araq: they describe a behavior so they could be used to handle input or do things with packets |
| 23:39:55 | Araq | sounds like a poor man's "fields" iterator to me :P |
| 23:42:58 | Araq | oh btw please checkout the newparser branch and see if that new parser compiles your code :-) |
| 23:43:13 | Araq | I know it still parses keineschweine :-) |
| 23:44:29 | Araq | good night |
| 23:45:46 | fowl | ok |
| 23:45:47 | fowl | night |
| 23:56:46 | * | Madison joined #nimrod |
| 23:56:46 | * | Madison quit (Changing host) |
| 23:56:46 | * | Madison joined #nimrod |