| 00:01:28 | * | bogen1 quit (Quit: Leaving.) |
| 00:01:29 | dom96 | good night |
| 00:01:50 | * | bogen joined #nimrod |
| 00:02:48 | * | q66 joined #nimrod |
| 00:03:29 | imjoe | goodnight |
| 00:05:55 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 00:09:34 | imjoe | in bigbreak branch, it created both a nim and and a nimrod executable in bin. which is the one to run? |
| 00:10:53 | * | noam_ joined #nimrod |
| 00:13:45 | bogen | imjoe: check timestamps. I presume nim. |
| 00:14:03 | * | fowl quit (Ping timeout: 272 seconds) |
| 00:14:23 | * | noam quit (Ping timeout: 268 seconds) |
| 00:16:51 | imjoe | nim is the newest. i'll go with that one |
| 00:17:45 | bogen | nimrod is the one used for bootstrapping, that has not been fixed yet |
| 00:19:52 | imjoe | also, one slight correction for the readme. line 35 says: |
| 00:19:56 | imjoe | $ git clone --depth 1 git://github.com/nim-code/csources |
| 00:19:56 | imjoe | |
| 00:20:10 | imjoe | should be $ git clone --depth 1 git://github.com/nimrod-code/csources |
| 00:20:20 | imjoe | nim-code doesn't exist |
| 00:21:03 | imjoe | has nimrod been renamed to nim? I much prefer nim :-) |
| 00:26:18 | bogen | imjoe: yes, the upcoming release includes a rename |
| 00:26:25 | bogen | nimrod --> nim |
| 00:28:26 | * | Jesin quit (Quit: Leaving) |
| 00:28:45 | bogen | the readme is correct, albeit premature, the nim-code repo has not been created yet |
| 00:28:50 | * | Jesin joined #nimrod |
| 00:30:14 | bogen | things are in flux right now |
| 00:36:20 | * | Jesin quit (Quit: Leaving) |
| 00:36:47 | * | Jesin joined #nimrod |
| 00:56:47 | imjoe | hmm. i wonder if i installed "bigbreak" wrong. now when compiling code i get lib/system.nim(2441, 19) Error: redefinition of 'fileHandle' |
| 01:05:38 | imjoe | line 2441 looks like {.deprecated: [fileHandle: getFileHandle].} |
| 01:05:38 | imjoe | |
| 01:07:05 | * | darkf joined #nimrod |
| 01:20:21 | bogen | they are experimenting with partial case sensitivity |
| 01:20:41 | bogen | which may be breaking things from what I've heard |
| 01:20:42 | imjoe | commenting out that line gets me farther. but now undefined reference to `dlclose' etc... i wonder if it's because I have older version of nimrod and this new one installed in a different location. |
| 01:20:57 | bogen | "bigbreak" is named appropiately |
| 01:21:03 | imjoe | ha |
| 01:21:04 | bogen | I'm not using that branch |
| 01:21:18 | bogen | I'm using the devel branch, which as been stable for me |
| 01:21:54 | imjoe | yeah i want to try async ssl which dom96 says is only on bigbreak right now |
| 01:22:19 | EXetoC | dlclose? I recall seeing a recent dynlib commit. is that relevant? |
| 01:24:06 | EXetoC | well the name of dlclose never changed, and that was 20 hours ago |
| 01:35:42 | * | demilichsd quit (Ping timeout: 245 seconds) |
| 01:41:48 | * | xenagi joined #nimrod |
| 01:52:11 | * | BlameStross left #nimrod (#nimrod) |
| 01:55:01 | * | Sht0 joined #nimrod |
| 02:02:34 | * | vezzy joined #nimrod |
| 02:07:01 | * | xenagi quit (Quit: Leaving) |
| 02:09:49 | * | q66 quit (Quit: Leaving) |
| 02:28:58 | * | fowl joined #nimrod |
| 02:33:33 | * | flaviu joined #nimrod |
| 03:06:09 | * | saml_ joined #nimrod |
| 03:16:04 | * | shiv joined #nimrod |
| 03:29:22 | * | fowl quit (Ping timeout: 240 seconds) |
| 03:51:10 | * | darkf quit (Read error: Connection reset by peer) |
| 03:51:36 | * | darkf joined #nimrod |
| 03:59:03 | * | fowl joined #nimrod |
| 04:23:35 | * | flaviu quit (Ping timeout: 272 seconds) |
| 04:25:59 | * | fowl quit (Ping timeout: 268 seconds) |
| 04:26:01 | imjoe | so giving up on bigbreak for now. switched to "devel" tried to compile this crawler: https://gist.github.com/dom96/10009691 and error: |
| 04:26:10 | imjoe | lib/pure/asyncdispatch.nim(947, 7) Error: 'cb' is not GC-safe |
| 04:26:10 | imjoe | |
| 04:27:04 | imjoe | strikeout night |
| 04:29:25 | Onionhammer | imjoe compile with --threadAnalysis:off |
| 04:31:04 | imjoe | bingo! thanks Onionhammer I have no idea what that does, but it makes it work :-) |
| 04:35:05 | Onionhammer | as i understand it, thread analysis isnt necessary if u arent doing multi-threaded things, but async operations might be multi threaded |
| 04:35:24 | Onionhammer | but probably arent in ur case |
| 04:43:41 | * | bjz quit (Read error: Connection reset by peer) |
| 04:43:59 | * | bjz joined #nimrod |
| 05:31:19 | * | shiv quit (Ping timeout: 246 seconds) |
| 05:47:42 | imjoe | if anyone has ideas on how to make this web getter thing work, I'm all ears: https://gist.github.com/anonymous/8b8f952f304ec96ba188 |
| 05:59:51 | * | saml_ quit (Quit: Leaving) |
| 06:11:57 | * | Sht0 quit (Ping timeout: 245 seconds) |
| 06:26:52 | * | Jesin quit (Quit: Leaving) |
| 06:49:27 | * | BlaXpirit joined #nimrod |
| 07:08:27 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 07:08:42 | * | BlaXpirit joined #nimrod |
| 07:22:00 | * | fowl joined #nimrod |
| 07:26:32 | * | fowl quit (Ping timeout: 245 seconds) |
| 07:27:07 | * | gkoller joined #nimrod |
| 08:27:01 | * | gkoller quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 08:35:54 | * | gkoller joined #nimrod |
| 08:37:04 | * | Matthias247 joined #nimrod |
| 08:59:02 | Araq | imjoe: you have to call runForever() or waitFor main() |
| 08:59:37 | Araq | asyncftpclient.nim and and asynchttpserver have 'isMainModule' sections you can look at |
| 09:08:27 | * | vissborg quit (Remote host closed the connection) |
| 09:10:23 | * | vissborg joined #nimrod |
| 09:14:56 | Araq | bbl |
| 09:34:37 | * | io2 joined #nimrod |
| 09:35:49 | * | gkoller quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 09:45:51 | dom96 | hi |
| 10:02:38 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 10:12:52 | * | eigenlicht_ quit (Ping timeout: 240 seconds) |
| 10:56:14 | * | vendethiel- is now known as vendethiel |
| 11:09:58 | * | Trustable joined #nimrod |
| 11:15:36 | NimBot | Araq/Nimrod bigbreak cda457c Dominik Picheta [+0 ±1 -0]: Fixes osproc on Windows. |
| 11:17:45 | Araq | hi dom96. what did you fix? |
| 11:18:01 | dom96 | Something I broke. |
| 11:19:41 | Araq | what did you break? |
| 11:20:17 | dom96 | readFile/writeFile |
| 11:20:22 | dom96 | I changed its signature. |
| 11:20:35 | Araq | ah |
| 11:20:40 | dom96 | from a 'var int32' to a 'ptr int32' |
| 11:20:51 | dom96 | because I needed to pass nil to it |
| 11:21:07 | * | gkoller joined #nimrod |
| 11:23:07 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 11:49:23 | * | saml_ joined #nimrod |
| 11:56:39 | * | saml_ quit (Ping timeout: 246 seconds) |
| 12:09:28 | * | saml_ joined #nimrod |
| 12:09:39 | * | eigenlicht_ joined #nimrod |
| 12:25:16 | * | noam_ is now known as noam |
| 12:27:10 | * | gkoller quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 12:32:51 | * | Ven joined #nimrod |
| 12:54:01 | * | q66 joined #nimrod |
| 13:18:00 | * | flaviu joined #nimrod |
| 13:19:17 | * | darkf quit (Quit: Leaving) |
| 13:22:55 | Trustable | dom96, next version of my Aporia PR is out :) |
| 13:23:15 | * | flaviu quit (Quit: Leaving.) |
| 13:32:58 | * | kunev joined #nimrod |
| 13:37:33 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 13:38:46 | dom96 | Trustable: awesome, thanks |
| 13:39:08 | Araq | Trustable: one feature that I *really* need is "search for word" (aka respect word boundaries) |
| 13:39:26 | Araq | regexes are not convenient enough for that (\b) |
| 13:42:24 | Trustable | Araq: I don't use such a search function. Do you mean the function "Match only a whole word" (like in Geany)? |
| 13:45:14 | dom96 | Trustable: I think you should just use an array in place of a Table for the shortcut key mappings |
| 13:45:22 | dom96 | Sorry, that just occurred to me now. |
| 13:46:49 | Trustable | Can arrays be associative? |
| 13:46:57 | Araq | Trustable: yeah, "match only a whole word" |
| 13:48:12 | dom96 | Also, what about my other comments? |
| 13:48:44 | dom96 | Getting rid of the code that you commented out for example in the cfg module. |
| 13:49:07 | Trustable | dom96: All issues you mentioned should be fixed. |
| 13:52:46 | Trustable | dom96: What kind of array should I use for the key mapping? Are there associative arrays? |
| 13:52:57 | dom96 | https://github.com/nimrod-code/Aporia/pull/54/files#diff-49b7c78f60adb536eb98d26f7c7ca6d6R287 |
| 13:53:03 | dom96 | You've got commented out code still in there |
| 13:53:09 | dom96 | and also you're silently ignoring that error. |
| 13:53:46 | dom96 | also your old shortcut key mapping code is still in the utils module I think |
| 13:54:16 | dom96 | Trustable: array[MaxShortcutKeyVal, string] |
| 13:56:58 | Trustable | dom96: my files are not committed, sry |
| 13:57:31 | dom96 | np |
| 13:58:22 | Trustable | dom96: it's no updated |
| 13:58:24 | Trustable | *now |
| 14:03:00 | dom96 | What about this? https://github.com/nimrod-code/Aporia/pull/54/files#r16999523 |
| 14:03:35 | dom96 | I know that we support key modifiers now but it would still be nice to have all this stuff under its own section. |
| 14:03:58 | dom96 | And you still haven't fixed this: https://github.com/nimrod-code/Aporia/pull/54/files#diff-49b7c78f60adb536eb98d26f7c7ca6d6R289 |
| 14:04:43 | dom96 | The only way that error can happen is if Aporia is doing something it's not supposed to be doing, I want to know when that happens. |
| 14:06:47 | Trustable | dom96: I will change it |
| 14:07:00 | dom96 | https://github.com/nimrod-code/Aporia/pull/54/files#diff-456c5aab7b3f0fbb350c6c1a23a9b424R534 s/shortbut/shortcut/ |
| 14:08:07 | dom96 | And that's it I think. |
| 14:09:09 | Trustable | oops :D |
| 14:14:34 | dom96 | hrm |
| 14:14:40 | dom96 | babelpath on devel doesn't seem to work |
| 14:20:21 | * | kunev quit (Ping timeout: 264 seconds) |
| 14:28:29 | dom96 | Trustable: ok, I tested your changes a bit and they seem to work well. The settings window needs to have a higher width though. |
| 14:28:46 | dom96 | But I can adjust that, it's probably a Windows only issue. |
| 14:30:43 | NimBot | Araq/Nimrod bigbreak bd542eb Dominik Picheta [+0 ±3 -0]: Fixes httpclient SSL issue. Implements unbuffered SSL recv. Ref #1487. |
| 14:40:26 | * | shiv joined #nimrod |
| 14:52:44 | EXetoC | will "assert(not x)" always require the parentheses? |
| 14:52:47 | Trustable | dom96: I continue now. What can I use as replacement for "hasKey()" for an array? |
| 14:53:57 | EXetoC | one could just conveniently add '== false' to the end instead |
| 15:01:14 | Trustable | dom96: I have fixed my mistakes. But when arrays are fixed length, it's not suited for the key lookup table. |
| 15:01:56 | EXetoC | can't use one of the hash map types? |
| 15:02:03 | Trustable | dom96: Please test what window size on Windows is required. |
| 15:02:05 | EXetoC | or a seq or something |
| 15:03:13 | Trustable | EXetoC: I use hash tables currently. |
| 15:14:32 | dom96 | Trustable: Isn't there a fixed amount of keys? |
| 15:15:34 | Trustable | dom96: yes, about 300 keys |
| 15:16:42 | dom96 | for hasKey you could check if keyLookupArray[i] == "" ? |
| 15:16:56 | dom96 | or nil even |
| 15:17:05 | dom96 | then you don't have to init every element |
| 15:17:23 | dom96 | but yeah, if there is a fixed amount of keys then using a fixed length array shouldn't be a problem right? |
| 15:17:53 | Trustable | dom96, it is a problem, becaues the keyval is guint, I don't want to have an array so bug |
| 15:17:55 | Trustable | *big |
| 15:18:19 | dom96 | oh. I see. |
| 15:18:36 | dom96 | in that case just leave it as it is |
| 15:18:42 | Trustable | ok |
| 15:18:54 | Trustable | now all issues should be cleared |
| 15:19:30 | dom96 | Ok, i need to head out for a bit. But i'll take a look once I come back. Thanks. |
| 15:19:34 | Trustable | only the window size needs to be changed |
| 15:19:51 | Trustable | dom96: alright |
| 15:33:33 | * | kunev joined #nimrod |
| 15:35:12 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 15:35:13 | EXetoC | so it's a sparse list then? |
| 15:35:38 | EXetoC | and not successive numbers |
| 15:42:00 | * | vendethiel joined #nimrod |
| 15:45:20 | * | kunev quit (Quit: leaving) |
| 15:49:46 | Trustable | EXetoC: yes |
| 15:54:57 | * | Jehan_ joined #nimrod |
| 16:02:56 | imjoe | having trouble trying to use regex: https://gist.github.com/anonymous/c3c334cdd4d04b8c8199 I guess I'm doing it wrong |
| 16:06:10 | * | Francisco quit (Ping timeout: 260 seconds) |
| 16:06:22 | EXetoC | imjoe: are you not trying to match the whole string now? |
| 16:06:24 | * | Francisco joined #nimrod |
| 16:07:05 | imjoe | EXetoC: I'm trying to capture "testing" (anything after "are:") |
| 16:07:06 | EXetoC | is 'find' what you want? |
| 16:07:35 | * | Ven joined #nimrod |
| 16:07:44 | EXetoC | or a .* or something at the start |
| 16:08:33 | * | JehanII joined #nimrod |
| 16:08:54 | EXetoC | but the second .* is too eager |
| 16:09:12 | * | Jehan_ quit (Read error: Connection reset by peer) |
| 16:11:59 | imjoe | EXetoC: but then wouldn't it just capture too much? It's not capturing anything. same regex works in other languages. also not sure why i need to use \\s instead of \s to match whitepace |
| 16:11:59 | EXetoC | I'm trying to figure out how to match everything except a newline now |
| 16:12:45 | EXetoC | imjoe: I think that's because it's not a raw string literal |
| 16:17:16 | EXetoC | var rregex = re(r".*are:\s+([^\n]*).*",{reMultiLine,reDotAll}) ? |
| 16:18:21 | imjoe | yes! thanks! |
| 16:20:00 | imjoe | after I learn so more, I want to make a macro that lets str =~ /regex/mi work... {reMultiLine, etc} annoy me :-) |
| 16:23:31 | EXetoC | just a template that takes a string literal representing the options should be fine. perhaps a string{lit} or something, and then it can be validated at compile-time |
| 16:45:02 | * | flaviu joined #nimrod |
| 16:54:18 | EXetoC | should be quite easy |
| 16:57:57 | imjoe | easy for you :-P |
| 17:00:09 | dom96 | hey imjoe |
| 17:00:15 | dom96 | did you ever get asynchttpclient working? |
| 17:00:34 | EXetoC | it's not rocket science either way. you'd do something like "template x(stuff..., opts: string{lit}): stmt" |
| 17:00:47 | dom96 | I can help you get bigbreak working if you'd like |
| 17:02:28 | imjoe | hey dom96 , no i got sidetracked. I'm not quite understanding how to get the dispatcher started and then start reading from stdin like in this gist https://gist.github.com/anonymous/8b8f952f304ec96ba188 |
| 17:02:50 | imjoe | also not sure if "sleep" also stops the async tasks (i hope not) |
| 17:03:35 | dom96 | I suppose for your use case being able to read stdin asynchronously would help. |
| 17:03:48 | EXetoC | "static: for x in string: assert.." and then you also construct the set and finally generate the call |
| 17:03:57 | dom96 | or can you give your application the list of URLs ahead of time? |
| 17:04:16 | dom96 | sleep does, what you want is sleepAsync |
| 17:04:43 | dom96 | You can start the dispatcher in two ways: via runForever or waitFor. |
| 17:04:45 | imjoe | it could be in the billions of urls and piped in from another process... |
| 17:06:24 | dom96 | imjoe: Would the memory consumption be too big if you read stdin first, stored the URLs into a seq and then perform the requests on the URLs in the seq? |
| 17:07:02 | EXetoC | mmap? |
| 17:07:48 | imjoe | maybe, not sure, but i was hoping to make this part of a pipelined process, so it's getting urls from another process and then as it gets them, it's writing to stdout which yet another process reads |
| 17:08:53 | dom96 | ok, well I can certainly implement async stdin reading for you. |
| 17:10:04 | imjoe | ah, async stdin reading. let me try to wrap my head around that. |
| 17:14:20 | dom96 | imjoe: What OS are you on btw? |
| 17:14:32 | imjoe | linux |
| 17:14:58 | * | willwillson joined #nimrod |
| 17:15:13 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 17:34:14 | * | Sh00ck joined #nimrod |
| 17:36:52 | Sh00ck | Hi guys :) How can i cross compile from Windows to Macosx (as example)? Its not that easy yet right...? |
| 17:39:57 | dom96 | That indeed doesn't sound easy. |
| 17:40:19 | dom96 | Start by checking how to cross-compile C code from Windows to Macosx |
| 17:40:29 | Sh00ck | kk ty, will check that out |
| 17:40:36 | * | Matthias247 joined #nimrod |
| 17:52:23 | * | jasondotstar joined #nimrod |
| 17:56:38 | * | gkoller joined #nimrod |
| 18:02:42 | NimBot | Varriount/NimLime master 59c5c48 Erik O'Leary [+0 ±2 -0]: Fixed highlighting of procs with implicit return type |
| 18:04:28 | * | xenagi joined #nimrod |
| 18:08:13 | * | gkoller quit (Quit: Textual IRC Client: www.textualapp.com) |
| 18:08:52 | NimBot | Varriount/NimLime master 9d4660c Erik O'Leary [+0 ±2 -0]: Added 'await' keyword |
| 18:09:46 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 18:11:55 | dom96 | await ain't a keyword :P |
| 18:12:31 | Onionhammer | :P |
| 18:12:41 | Onionhammer | but it looks prettier if it's highlighted dom96 |
| 18:12:49 | Onionhammer | dom96 where did you add the result for waitfor |
| 18:13:48 | Onionhammer | dom96 gotta maintain NimLime as the best editing experience for Nim |
| 18:13:52 | Onionhammer | :p |
| 18:14:06 | Onionhammer | what with the sudden activity on aporia |
| 18:14:24 | dom96 | lol |
| 18:14:48 | dom96 | waitFor should now return T |
| 18:14:56 | dom96 | the T in Future[T] |
| 18:14:57 | Onionhammer | in bigbreak only? |
| 18:15:25 | Onionhammer | you know what would be cool? if 'await' was an implicit 'waitfor' in non-async procs :P |
| 18:16:47 | dom96 | yes |
| 18:17:04 | dom96 | I don't want to conflate their meanings. |
| 18:17:13 | Araq | that's actually quite simple to do, Onionhammer |
| 18:17:28 | Onionhammer | i thnk it would simplify usage a lot |
| 18:17:40 | Onionhammer | it makes sense IMO, think about it |
| 18:18:12 | Onionhammer | then you could do a "await main()" at the very top of the stack |
| 18:18:29 | Onionhammer | "waitFor main()" is kinda ugly |
| 18:20:32 | Araq | well it's easy to do but I think dom96 is right |
| 18:20:46 | Araq | it's clearer to distinguish between these two |
| 18:21:47 | Onionhammer | when would it matter? |
| 18:23:10 | Onionhammer | they're functionally the same, the difference is how the compiler treats the words in different contexts, I dont think its a big risk |
| 18:23:18 | Onionhammer | functionally is the wrong word.. |
| 18:23:42 | Onionhammer | functional in terms of semantics |
| 18:24:02 | Onionhammer | semantically speaking, the programmer wants to 'await' a response |
| 18:24:15 | Onionhammer | whether its asynchronous or not depends on the context |
| 18:24:32 | Onionhammer | dom96 how come PFuture.value isnt public? |
| 18:25:28 | Onionhammer | oh i see. "read". that's not a great name for it imo |
| 18:25:31 | dom96 | Depending on the context is IMO too subtle. |
| 18:26:21 | Onionhammer | dom96 just try it, you might like it :P |
| 18:28:06 | dom96 | and what if I want to waitFor inside an async proc? |
| 18:28:23 | Onionhammer | then you type waitfor :P |
| 18:31:26 | dom96 | no, I type waitFor always |
| 18:31:59 | Onionhammer | thatd be a matter of style |
| 18:42:29 | * | fowl joined #nimrod |
| 18:52:00 | dom96 | I think that people may already have trouble with waitFor because it only ensures that the dispatcher is polled as long as the future you give it has not finished. |
| 18:52:17 | dom96 | That doesn't mean that there aren't futures which haven't completed still waiting. |
| 18:53:15 | NimBot | Araq/Nimrod bigbreak cb8a25b Dominik Picheta [+0 ±1 -0]: Added asyncfile.readLine and async stdin/out/err. Ref #1487. |
| 18:53:32 | dom96 | imjoe: There you go. I haven't tested it on Linux but it should work :) |
| 18:54:32 | * | kunev joined #nimrod |
| 18:56:31 | Onionhammer | dom96 that would be a programmer error i think |
| 18:56:40 | Onionhammer | dom96 not coallescing those futures into 1 |
| 18:57:11 | dom96 | Onionhammer: Yes, well it makes me nervous. |
| 18:57:46 | Onionhammer | *shrug* |
| 18:57:51 | dom96 | It's definitely a gotcha. |
| 18:58:39 | dom96 | Especially because you simply don't know whether the async procs you are executing are not awaiting all the async procs that they are executing. |
| 18:59:10 | dom96 | But we'll see if it becomes a problem. |
| 18:59:24 | * | JehanII quit (Read error: Connection reset by peer) |
| 18:59:35 | * | Jehan_ joined #nimrod |
| 19:00:14 | imjoe | thanks dom96! I have to step out for 30mins but then will try getting bigbreak to work on my machine and let you know how it goes. if you could tweak my gist to show how to use it, that would be super awesome ;-) |
| 19:00:29 | dom96 | imjoe: sure, i'm writing an example right now. |
| 19:16:47 | * | willwillson quit (*.net *.split) |
| 19:16:50 | * | vendethiel quit (*.net *.split) |
| 19:16:50 | * | eigenlicht_ quit (*.net *.split) |
| 19:16:50 | * | untitaker quit (*.net *.split) |
| 19:16:50 | * | comex quit (*.net *.split) |
| 19:22:10 | * | comex joined #nimrod |
| 19:25:14 | dom96 | Turns out reading stdin asynchronously on Windows is not as easy as I thought it would be. |
| 19:27:17 | * | JehanII joined #nimrod |
| 19:27:18 | * | Jehan_ quit (Read error: Connection reset by peer) |
| 19:29:18 | * | willwillson joined #nimrod |
| 19:29:18 | * | vendethiel joined #nimrod |
| 19:29:18 | * | eigenlicht_ joined #nimrod |
| 19:29:18 | * | untitaker joined #nimrod |
| 19:29:19 | * | JehanII quit (Read error: Connection reset by peer) |
| 19:29:23 | * | Jehan_ joined #nimrod |
| 19:31:20 | Araq | dom96: nobody cares about reading from stdin asyncronously :-) |
| 19:31:53 | dom96 | Araq: imjoe does? |
| 19:32:47 | dom96 | But perhaps I should just tell him to use sockets instead. |
| 19:33:44 | dom96 | In any case, this may work on Linux: https://gist.github.com/dom96/d562c44836de7b7428b3 |
| 19:34:01 | dom96 | But I suggest creating a server socket instead. |
| 19:34:14 | dom96 | For better portability. |
| 19:35:44 | * | Varriount joined #nimrod |
| 19:35:51 | Varriount | Bloop |
| 19:36:06 | dom96 | bbs |
| 19:40:16 | * | gelumelu joined #nimrod |
| 19:40:23 | * | Fx00F joined #nimrod |
| 19:41:09 | Varriount | Hello gelumelu |
| 19:41:50 | * | willwillson quit (Ping timeout: 252 seconds) |
| 19:43:39 | Fx00F | hi |
| 19:43:49 | Fx00F | is there a parser combinator for nimrod? |
| 19:44:06 | * | willwillson joined #nimrod |
| 19:45:48 | dom96 | Fx00F: I don't think so. Closest thing we have is the parseutils module. |
| 19:45:58 | Varriount | Fx00F: Or the PEG module |
| 19:47:38 | imjoe | trying to install bigbreak again. did: ./koch install /home/joe/nimbb and got: |
| 19:47:41 | imjoe | nim cc -r -d:useLibzipSrc tools/niminst/niminst --var:version=0.9.5 scripts compiler/nim.ini |
| 19:47:41 | imjoe | sh: 1: nim: not found |
| 19:47:41 | imjoe | |
| 19:48:07 | dom96 | just add the nimrod directory to your PATH |
| 19:48:17 | Fx00F | or symlink nim to nimrod |
| 19:48:45 | Fx00F | unless nim is another tool |
| 19:48:46 | imjoe | ok |
| 19:50:53 | EXetoC | they are the same, but a rename of the language is coming up |
| 19:51:59 | fowl | i have mingw and msys installed now |
| 19:52:30 | fowl | EXetoC nimrod is getting renamed? |
| 19:52:31 | imjoe | it worked! running your gist dom96. It says: Requesting 0x7f38d8fc5110"http://google.com/" etc, but never gets to: echo("Got resp: ", resp.status) |
| 19:53:06 | EXetoC | fowl: yes |
| 19:53:22 | EXetoC | someone on the forums did complain about the lack of announcement for certain thing |
| 19:53:24 | EXetoC | s |
| 19:53:58 | dom96 | imjoe: oh damn. |
| 19:54:10 | dom96 | imjoe: Can you use sockets instead of stdin? :P |
| 19:54:53 | imjoe | maybe. so async code cannot be part of a pipeline on the commandline? |
| 19:55:05 | flaviu | dom96: why would you want async stdin? |
| 19:55:21 | flaviu | It'll always degrade to synchronous stdin |
| 19:55:40 | dom96 | flaviu: Because I don't want to block waiting on user input? |
| 19:55:48 | dom96 | how so? |
| 19:56:14 | flaviu | Since your program will likely not go as fast the other steps: you can't beat cat in performance unless you're doing something trivial |
| 19:56:27 | flaviu | so you'll always have a full buffer or whatever |
| 19:56:37 | dom96 | imjoe: no, or at least not yet. Getting it to work on Windows seems to be quite some work. As for linux: I don't know. |
| 19:56:42 | imjoe | flaviu: I'm trying to do this: https://gist.github.com/anonymous/8b8f952f304ec96ba188 read lines, get data (limited to x concurrency) and send to next stage of pipeline |
| 19:57:01 | fowl | EXetoC, the only place i look is the channel topic |
| 19:57:02 | flaviu | Commandline tools also usually block on user input - its used for confirmation and such |
| 19:57:40 | dom96 | yeah, I think using sockets is the right way to go here. |
| 19:58:21 | flaviu | imjoe: Ah, I see. I don't think that async waiting on stdin will be useful |
| 19:58:39 | flaviu | unless I'm misunderstanding |
| 19:59:14 | dom96 | it could be useful, you could have a web server which accepts stdin input |
| 19:59:18 | dom96 | to control it for example |
| 19:59:25 | flaviu | dom96: Put control in a thread |
| 19:59:42 | flaviu | I'm pretty sure that async is for millions of concurrent connections or something |
| 19:59:55 | flaviu | you can have 1000 threads without issues on pretty much all OSes |
| 20:00:32 | dom96 | It's nice to have unity. |
| 20:01:29 | dom96 | Threads a lot of complexity. |
| 20:01:34 | dom96 | *Threads add |
| 20:01:45 | flaviu | and async doesn't? lol |
| 20:01:52 | * | Fx00F quit (Ping timeout: 240 seconds) |
| 20:01:58 | * | comex is now known as dumbex |
| 20:02:23 | flaviu | Just lock on a settings hashmap, very little complexity there. I'm sure there are many readers, one writer optimized datastructures for that |
| 20:02:48 | * | Fx00F joined #nimrod |
| 20:03:06 | dom96 | Sure it is. But you are suggesting threads and async; that's twice the complexity than async alone. |
| 20:03:45 | flaviu | sorry then, I'm not really familiar with how async works |
| 20:05:28 | dom96 | But no, it's a good suggestion. |
| 20:05:44 | dom96 | With channels it may work quite well. |
| 20:06:18 | imjoe | I haven't used threads in nim. could I have the async dispatcher in one thread and then read stdin on the main thread and somehow push it to the dispatcher thread? |
| 20:06:21 | flaviu | yeah, single writer multiple readers is trivial, since pointer assignment is trivial |
| 20:06:31 | flaviu | s/is trivial/is atomic/ |
| 20:06:52 | * | Fx00F quit (Ping timeout: 240 seconds) |
| 20:07:07 | Trixar_za | I take by the Araq's activity on Github, that he's not just planning on changing the channel name, but the nimrod as a whole :P |
| 20:07:22 | * | shiv quit (Ping timeout: 246 seconds) |
| 20:07:33 | dom96 | imjoe: I think keeping the dispatcher in the main thread is the way to go. |
| 20:10:39 | dom96 | imjoe: I'll try to create an example. |
| 20:11:27 | * | kunev quit (Quit: leaving) |
| 20:14:13 | imjoe | thanks dom96. reading about threads now. |
| 20:16:04 | Araq | flaviu: not that anything you could say would make it less ridiculous, but what are the reasons why overflow hbox cannot be fixed? |
| 20:18:01 | flaviu | Say you have an object that is 1.01 * \pagewidth. How do you propose that be dealt with? |
| 20:18:37 | Araq | overflow the page of course. nobody ever prints out anything with latex for sure |
| 20:19:12 | Araq | hence ABI word does the same ... uh wait ... nothing else does this |
| 20:19:47 | flaviu | overfull hbox means exactly that, it overflows the page |
| 20:20:08 | Araq | irony too subtle? |
| 20:20:16 | flaviu | I guess so |
| 20:20:48 | flaviu | seriously though, how do you want that dealt with? |
| 20:21:43 | dom96 | Araq: tryRecv seems to be blocking D: |
| 20:23:27 | Araq | flaviu: it should break up the lines in a suboptimal way in order to not overflow the hbox |
| 20:24:27 | Araq | dom96: indeed ... the implementation is brain dead |
| 20:24:36 | Araq | can you fix it? |
| 20:24:45 | dom96 | later |
| 20:24:50 | dom96 | it's not important right now |
| 20:25:18 | Araq | instead of 'lockChannel' which uses acquireSys it should use tryAcquireSys |
| 20:27:18 | Araq | somebody should explain to shiv how the module system works ... (forum) |
| 20:27:54 | Varriount | Araq: I'll do it. |
| 20:28:02 | flaviu | Araq: It seems like they've decided that its the user's responsibitity to make sure their words aren't insane. |
| 20:29:03 | Araq | flaviu: you're wrong. this issue comes up for *everybody* who uses the tool. |
| 20:29:09 | Varriount | Has csources been fixed yet? |
| 20:29:19 | Araq | Varriount: I tried. can you check please? |
| 20:29:25 | * | vezzy quit (Ping timeout: 272 seconds) |
| 20:29:39 | Varriount | Araq: Tried with the csources, or tried explaining to shiv? |
| 20:29:55 | flaviu | Araq: Odd, I've written ~34 pages on my longest document, and had 3-4 very minor overfull hboxes, which were caused by very long equations |
| 20:31:32 | flaviu | Anyway, \setlength{\emergencystretch}{25em} works on my pathalogical example, but I think I'd prefer a margin overrun over what it does |
| 20:33:29 | Araq | if margin overruns are fine, why do you even have a margin? makes no sense to me. |
| 20:33:50 | Araq | Varriount: I'm speaking of the csources |
| 20:33:55 | flaviu | Because 1em isn't going to ruin anything, and you should catch this stuff while revising |
| 20:34:25 | Araq | and do what? change the content so that it follows form? |
| 20:34:50 | flaviu | Yes, add manual hyphenation points, figure out why you have that giant equation inline |
| 20:35:48 | dom96 | Well. Turning on threads seems to screw up async. |
| 20:36:54 | dom96 | Araq: Any ideas why that might be? osLastError returns 0. |
| 20:37:32 | Araq | dom96: I'm thinking about it |
| 20:38:23 | dom96 | I removed all thread code: https://gist.github.com/dom96/fdd6318d3415489b4333 |
| 20:38:41 | Varriount | Araq: csources is fixed for Win64 |
| 20:38:45 | dom96 | It works, but as soon as I get compile with --threads:on I get OS errors. |
| 20:38:53 | dom96 | s/get// |
| 20:39:08 | Araq | dom96: do you use TLS emulation? |
| 20:39:58 | dom96 | no |
| 20:40:32 | dom96 | enabling it doesn't change anything |
| 20:40:46 | dom96 | disabling it does |
| 20:40:47 | dom96 | interesting |
| 20:40:52 | dom96 | so I was using it |
| 20:44:41 | * | vezzy joined #nimrod |
| 20:44:42 | Varriount | Anyone tested building from csources on Linux yet? |
| 20:44:48 | Varriount | Hi vezzy? |
| 20:44:54 | Varriount | *. |
| 20:46:02 | dom96 | and that causes even more strange issues... |
| 20:46:07 | * | dom96 gives up |
| 20:46:43 | dom96 | imjoe: You can try this on Linux if you want, it may work: https://gist.github.com/dom96/5ce32a47395e887158d9 |
| 20:46:49 | Varriount | Araq: Which branch is the website generated from? I want to remove that "Starting with 0.9.4, we now advise people to build directly from github" line. |
| 20:46:50 | dom96 | If not just use sockets. |
| 20:47:09 | dom96 | Varriount: do it in bigbreak |
| 20:47:31 | Varriount | dom96: But editing the website is not a breaking change. |
| 20:47:53 | dom96 | Fine, then do it in devel. |
| 20:48:16 | Araq | Varriount: it's generated from master, but these are static pages |
| 20:48:27 | Araq | we need to manually copy them around |
| 20:48:28 | imjoe | thanks dom96 ! It is getting the data. let me try and throw a zillion urls at it |
| 20:48:39 | imjoe | it doesn't work on windows? |
| 20:48:43 | dom96 | nope |
| 20:49:02 | flaviu | imjoe: Wget not doing it for you? :P |
| 20:52:03 | Varriount | Araq: So I take it the name change is set-in-stone, no going back? |
| 20:56:39 | Araq | Varriount: yes. why? |
| 20:56:51 | * | Francisco quit (Ping timeout: 255 seconds) |
| 20:57:14 | Varriount | Araq: Just pondering about the responses to the name change on the forum. |
| 20:57:44 | Varriount | Araq: Speaking of which, should I create a thread on the forum listing the major future changes? |
| 20:57:57 | Varriount | And/Or a news announcement? |
| 21:01:06 | Araq | Varriount: well I need to be the one who writes the announcement, I think |
| 21:03:34 | * | Fr4n joined #nimrod |
| 21:04:14 | Jehan_ | I think the name change is not going to be a big issue overall. |
| 21:04:45 | Jehan_ | --cs:partial and dropping the T/P prefixes are a bigger deal. |
| 21:04:50 | dom96 | yes, 'nim' is similar enough to Nimrod. |
| 21:06:09 | Varriount | I don't expect much anger against dropping the T/P prefixes, except where it's relevant to the case sensitivity change. |
| 21:07:19 | Araq | Jehan_: speaking of which there is an interesting issue with "nimrod pretty" |
| 21:07:38 | Jehan_ | Araq: What kind of issue? |
| 21:07:45 | Varriount | Comment handling? |
| 21:08:17 | Jehan_ | Varriount: Yeah. I think a lot of people may not fully appreciate the need of having cs:partial as a result of the prefix change. |
| 21:08:53 | Araq | when it does s/PFoo/Foo/ and then in the same line s/PBar/Bar/ the column of PBar changed if PBar comes after PFoo in the original line |
| 21:09:46 | Araq | but not if it comes before |
| 21:10:22 | Araq | do this multiple times and you need some kind of seq to store how the columns changed |
| 21:11:12 | Jehan_ | I see, but how does this matter? Visual layout? |
| 21:11:51 | Araq | well for now if the tool cannot find the identifier where it's ought to be, it doesn't do the replacement |
| 21:12:01 | Jehan_ | Oh, I see. |
| 21:12:22 | Jehan_ | I hadn't realized it was doing that. |
| 21:12:47 | Jehan_ | Speaking of layout, I've found an issue with strongspaces. |
| 21:13:05 | Araq | ha, do you think I update ~100_000 loc by hand? :P |
| 21:13:26 | Jehan_ | When you have a multi-line construct (e.g., matrices), then strongspaces and alignment may not be compatible. |
| 21:14:04 | Jehan_ | Araq: Eh, I wasn't assuming you were doing it manually; I was surprised that the tool needed to track source coordinates. |
| 21:14:34 | Araq | rendering back the AST does not work, been there, tried that |
| 21:15:10 | Jehan_ | Araq: Hmm. I see. |
| 21:15:23 | imjoe | dom96: I tweaked your gist a bit to limit concurrency: https://gist.github.com/anonymous/9efd723eeb5be56e98c1 for some reason it seems to be blocking or slow or something especially if i increase concurrency to 100. looking into why that might be |
| 21:15:32 | Araq | it misses valuable things like \t vs \0x09 and even multiple empty lines should be kept etc. |
| 21:15:48 | imjoe | but it is getting the data! :-) and I thank you for that! |
| 21:16:02 | Jehan_ | For source-to-source translation tools I generally store the whitespace that precedes a lexical token along with the token. |
| 21:16:20 | Trixar_za | Oh right. Time to follow the Tao of IRC |
| 21:16:37 | dom96 | imjoe: That's good. Try playing with sleepAsync maybe. |
| 21:17:07 | Araq | Jehan_: also 'git diff' is an issue when the tool changes too much |
| 21:17:15 | dom96 | imjoe: with the amount of time you sleep that is |
| 21:17:57 | Jehan_ | In what way is git diff an issue? Git uses a binary delta compression algorithm internally, not a line-by-line diff? |
| 21:18:32 | Jehan_ | You'll "see" a lot of diffs with "git diff", but that's unavoidable for such a large change. |
| 21:19:56 | Araq | Jehan_: it doesn't matter what algorithms git uses |
| 21:20:13 | Araq | proc foo(a, b: int; |
| 21:20:15 | Jehan_ | Araq: Then I'm afraid I'm not following you? |
| 21:20:19 | Araq | c: string) |
| 21:20:25 | Araq | becomes for instance: |
| 21:20:31 | Araq | proc foo(a, b: int; |
| 21:20:40 | Araq | c: string) |
| 21:20:54 | Araq | and then that's not a renaming |
| 21:20:59 | Jehan_ | Hmm. I still don't quite see the problem? |
| 21:21:04 | Araq | so it's annoying |
| 21:21:33 | dom96 | are you saying that git diff shouldn't show indentation changes? |
| 21:22:03 | Araq | I'm saying nimfix shouldn't touch anything more than strictly necessary |
| 21:22:54 | NimBot | nimrod-code/Aporia master c090a59 Simon Krauter [+0 ±5 -0]: Moved keyboard shortcuts to settings... 2 more lines |
| 21:22:54 | NimBot | nimrod-code/Aporia master 7efed95 Simon Krauter [+0 ±5 -0]: New function "Delete line(s)" and other changes... 15 more lines |
| 21:22:54 | NimBot | nimrod-code/Aporia master 4f18e58 Simon [+0 ±1 -0]: Fix regression bug |
| 21:22:54 | NimBot | nimrod-code/Aporia master 5d5816e Simon Krauter [+0 ±5 -0]: Another update to the first PR |
| 21:22:54 | NimBot | 5 more commits. |
| 21:23:27 | dom96 | Trustable: I merged it. Thank you for you hard work! |
| 21:23:28 | Trixar_za | Dare I ask what we're talking about? I assume nimfix is like an auto-debugger. |
| 21:23:57 | Trustable | dom96: thx for merging it :) |
| 21:24:03 | Onionhammer | it's a code formatter iirc |
| 21:24:35 | NimBot | nimrod-code/Aporia master d3106e1 Dominik Picheta [+0 ±1 -0]: Disable threadAnalysis to compile with gcsafe stuff. |
| 21:24:41 | Araq | Trixar_za: it modifies your code so that it uses the new names |
| 21:25:15 | Trixar_za | Ah, like the python 2 to python 3 converter |
| 21:25:24 | Araq | yeah, that fits |
| 21:29:25 | Trixar_za | I may be a bit slow today. Already had a really weird discussion with someone and it took me a while (and major paradigm shift) to figure out what he meant. I kept calling Deism a religion. It's not. It's a religious view. |
| 21:29:41 | EXetoC | auto-debugger? I sure would like one of those |
| 21:29:50 | Trixar_za | So my brain fuse is a little blown :P |
| 21:29:53 | Araq | EXetoC: lol |
| 21:30:13 | dom96 | EXetoC: Just write a genetic algorithm and let it run for a billion years. |
| 21:30:39 | Trixar_za | EXetoC: I could write one for you - it will probably just make your code worse, but that's what debuggers do anyway, right? :P |
| 21:30:54 | EXetoC | dom96: maybe only a 1000 years with one of them quantum computers |
| 21:31:19 | Araq | Jehan_: well what problems do you see wrt T/P cs:partial changes? |
| 21:32:25 | Jehan_ | Araq: Well, I expect that there will be issues when people are using the unprefixed names in their own code. |
| 21:32:38 | Jehan_ | I don't see how that can be avoided, though. |
| 21:33:27 | Jehan_ | Personally, I'd put out a final stable version without the prefix changes and a separate stable version with them. |
| 21:33:42 | EXetoC | but partial implies case-sensitive first letter |
| 21:33:46 | Jehan_ | So that people can still use the old version for a while without everything breaking. |
| 21:34:04 | Araq | that's the 0.9.6 vs 0.10.0 idea, yeah |
| 21:34:12 | Jehan_ | ExetoC: Doesn't help if someone defines a type "Table" in their own code and imports tables, too. |
| 21:35:05 | Jehan_ | As a matter of fact, I've done that myself. |
| 21:35:19 | Jehan_ | Only as a wrapper to avoid the prefixes, though, so it doesn't hurt me. |
| 21:36:05 | Araq | interesting how great the dislike for these really is :-) |
| 21:36:49 | Jehan_ | Araq: It may be habit. |
| 21:37:06 | Araq | I don't really see them and when I see them, the ref vs value type distinction makes sense |
| 21:38:01 | Jehan_ | As I said, it may be habit. People generally have acquired certain practices over the years, and it's hard to get rid of them. |
| 21:38:01 | Araq | took me *months* to figure out C#'s DateTime is a struct |
| 21:39:24 | Araq | but hey, I'm the guy arguing for proper IDE support, so using prefixes to patch over missing tooling is certainly a weak argument |
| 21:39:52 | Jehan_ | Heh. :) |
| 21:40:12 | * | ics joined #nimrod |
| 21:40:51 | Jehan_ | I generally try to follow the maxim "when in Rome, do as the Romans do" when it comes to programming languages. |
| 21:41:17 | Jehan_ | But even so, I occasionally struggle with certain idioms. |
| 21:42:06 | * | untitaker quit (Ping timeout: 252 seconds) |
| 21:42:24 | Jehan_ | On the plus side, I'm happy that Nim(rod)'s style guide lines follow my personal preference of using two spaces for indentation. :) |
| 21:42:34 | * | xenagi quit (Quit: Leaving) |
| 21:42:36 | Jehan_ | It's the little things … :) |
| 21:43:12 | * | Onionhammer prefers 4 |
| 21:43:15 | Onionhammer | easier to read ;) |
| 21:44:14 | imjoe | Jehan_: I see what you did there :-) |
| 21:44:32 | EXetoC | yeah, and you shouldn't cram a million things into a single line anyway |
| 21:44:34 | Jehan_ | Onionhammer: There was actually a study in the 1980s, according to which 2 spaces was on average slightly more readable than 4. |
| 21:44:48 | Onionhammer | sure :p |
| 21:44:57 | Onionhammer | to people that are used to 2 spaces maybe |
| 21:44:58 | Jehan_ | That said, it has nothing to do with readability for me anymore, and all with decades of built-up muscle memory. |
| 21:45:14 | Araq | I also thought many people coming from FPC/Delphi would switch to Nim and they don't mind the prefixes. Interestingly this didn't happen at all afaict. the Pascal people actually *like* Pascal's syntax |
| 21:45:20 | Onionhammer | the text editor does the indentation for me |
| 21:45:37 | Onionhammer | if i had to type out every space i'd use 2 spaces too |
| 21:45:57 | EXetoC | it does for me because my vision is a little blurry when looking at monitors and I'd rather not strain my eyes too much |
| 21:46:03 | Jehan_ | Onionhammer: Also use autoindent, but you sometimes still have to adjust spacing manually. |
| 21:46:25 | EXetoC | no one else seems to have that problem though |
| 21:46:26 | Jehan_ | Araq: I also prefer a Pascal syntax (well, actually, Eiffel/Modula/Ada style). |
| 21:46:39 | imjoe | i want my editor to background color each indent level with a slightly different shade |
| 21:46:50 | EXetoC | some editors can |
| 21:47:12 | Jehan_ | Mind you, it's not a strong preference, and a Pythonesque syntax has its advantages, too. |
| 21:47:28 | * | untitaker joined #nimrod |
| 21:48:00 | Jehan_ | I've never been happy with C-style syntax, though, and I don't know why. |
| 21:50:29 | Araq | Jehan_: well Eiffel's is much better than Ada's which is better than Pascal's |
| 21:51:09 | Triplefox | i like both python and pascal syntax, i'm least happy with C-style |
| 21:51:17 | EXetoC | it was quite difficult to figure out the layout when I used two-space indents for my html templates, because you end up with quite a messy tree |
| 21:51:21 | Jehan_ | Araq: I mean the comb-style "if … then … else … end" structure as opposed to "if … then begin … end else begin … end" |
| 21:52:21 | Araq | Jehan_: yeah, I know |
| 21:52:22 | * | BlaXpirit quit (Ping timeout: 245 seconds) |
| 21:52:23 | Jehan_ | Speaking of C syntax, the one thing that I know I'm unhappy with is having type names before variables. |
| 21:52:43 | Araq | yeah, I never get used to that |
| 21:53:02 | Jehan_ | When I'm looking for a variable, it helps if the name always starts in the same vertical column (modulo white space). |
| 21:53:03 | Araq | the whole thing is backwards just to save one keyword |
| 21:53:21 | Jehan_ | With C declarations, I have to find the end of the type part to see where the variable name begins. |
| 21:53:50 | Araq | not to mention int (*fn)(int *) |
| 21:54:00 | Triplefox | i think my main issue is really just with the pointer syntax |
| 21:54:01 | Jehan_ | Heh. Yes. |
| 21:54:15 | Jehan_ | Though that's rare enough that it doesn't bother me much. |
| 21:54:25 | Jehan_ | Any language has its oddities. |
| 21:54:36 | Araq | Jehan_: it's rare for people |
| 21:54:37 | Jehan_ | I'm more concerned with stuff that I have to deal with 90% of the time. |
| 21:54:44 | Araq | it's incredibly common for c2nim |
| 21:54:54 | Araq | and then c2nim gets confused and dies |
| 21:55:05 | Jehan_ | Araq: Or any program that generates C code. |
| 21:55:18 | Araq | and people don't use c2nim because it's "obviously broken" |
| 21:55:38 | Jehan_ | That was always one of the most annoying parts of writing an X-to-C compiler. |
| 21:58:31 | Araq | no the most annoying part is the broken confusing type system where int* [10] sometimes is int* except when it's not |
| 21:59:54 | Araq | that you can only forward declare structs doesn't help either |
| 22:00:11 | Araq | makes the type generation algorithm quite hard |
| 22:01:18 | Onionhammer | araq when is there going to be some effort put into fixig up idetools? |
| 22:01:49 | Jehan_ | Araq: Yeah, generating type declarations was what I meant. |
| 22:02:27 | Araq | Onionhammer: I'm extracting "nimide" into its own tool but apart from that nothing is planned in the immediate future |
| 22:02:42 | Onionhammer | oh that'll be nice |
| 22:03:00 | Araq | I hope this encourages people to contribute and improve it |
| 22:03:24 | Onionhammer | well it'd be nice to be able to use the CaaS |
| 22:06:08 | Araq | well for CaaS to properly work, the whole compiler needs to be fuzzy about everything |
| 22:06:30 | Araq | "best effort" is really what you want for an IDE |
| 22:11:01 | Trixar_za | Araq: I don't think it's so much liking the syntax as being used to it. Familiarity breeds comfort. Even if something is better by being more efficient, but is too different from what is considered the familiar way of doing something, it will almost always be rejected as not being user friendly. |
| 22:11:05 | Araq | Jehan_: oh I didn't really get your strongSpaces example. can you gist it an example please? |
| 22:11:18 | Jehan_ | Araq: Sure. Give me a second. |
| 22:11:45 | * | darkf joined #nimrod |
| 22:12:29 | Araq | Trixar_za: I'm very familiar to pascal's syntax but after thousands of lines I started to hate it ;-) but in general you're right. |
| 22:13:45 | Trixar_za | I'd cite my own reaction to having to use space instead of tabs (even though it's against python's own pep8) and the use of echo instead of print when I first started with nimrod ;P |
| 22:14:07 | Araq | Varriount: please test if 'master' is broken like http://forum.nimrod-lang.org/t/549 suggests it is |
| 22:14:34 | Jehan_ | Very simple, made-up example: https://gist.github.com/rbehrends/92e42a676fd223aec461 |
| 22:14:57 | * | flaviu quit (Ping timeout: 264 seconds) |
| 22:15:15 | Araq | Jehan_: ah that's what you mean |
| 22:15:49 | Araq | yeah a very good point |
| 22:16:01 | Jehan_ | Haven't actually encountered it in Nimrod yet, but my day job involves Computer Algebra, where such stuff is common. |
| 22:16:45 | Araq | well a different alignment character comes to mind |
| 22:16:57 | Araq | we could support _ for that purpose |
| 22:17:19 | Jehan_ | Huh? |
| 22:17:32 | Araq | __ x*x |
| 22:17:41 | Jehan_ | Hmm. |
| 22:17:47 | Araq | but it's ugly |
| 22:17:59 | Araq | and not common |
| 22:18:56 | Araq | another problem is that some people prefer foo (a, b) over foo(a, b) |
| 22:18:56 | * | Jehan_ quit (Read error: Connection reset by peer) |
| 22:19:03 | * | JehanII joined #nimrod |
| 22:19:20 | JehanII | I really need to get my wireless fixed. |
| 22:19:28 | * | JehanII is now known as Jehan_ |
| 22:19:56 | EXetoC | well that's more typing so it's fine :p |
| 22:20:46 | Jehan_ | I'm honestly not quite sure what problem strong spaces are supposed to fix, I have to say. |
| 22:22:09 | Araq | echo $a # common gotcha |
| 22:22:45 | Araq | a|b & c should be parsed as I write it |
| 22:22:55 | Araq | this is really nice for DSLs |
| 22:23:56 | Trixar_za | Night guys |
| 22:24:00 | Araq | good night |
| 22:27:37 | Onionhammer | night |
| 22:29:10 | Onionhammer | some way of specifying that you want to use strong spaces would be nice... I'm really not sure i like the idea |
| 22:29:26 | Jehan_ | Araq: I can see that, but I don't see the problem with using parentheses. |
| 22:30:12 | Araq | Jehan_: well the point of using precedences is to get rid of parentheses |
| 22:30:19 | Jehan_ | Onionhammer: I think I would be mostly concerned with people doing the wrong thing by mistake. |
| 22:30:39 | Jehan_ | Araq: Yeah, but it's something that you can overdo (IMHO). |
| 22:30:52 | Araq | Onionhammer: well for now it's opt-in via a toplevel #! strongSpaces |
| 22:30:54 | Onionhammer | exactly |
| 22:31:05 | Jehan_ | You don't want LISP, of course, but I don't see a reason to avoid them religiously. |
| 22:31:15 | Onionhammer | Jehan_ thats exactly what im worried about, they accidentally use an extra space |
| 22:31:18 | Onionhammer | Araq good to hear |
| 22:32:15 | Araq | Jehan_: fair enough but I prefer spaces over a strict precedence table that the manual contains and nobody remembers |
| 22:32:35 | Jehan_ | Araq: I generally think there are way too many precedence levels in most languages. |
| 22:33:04 | Araq | it's really like using indentation instead of 'end', whitespace matters to people so it should matter to the compiler |
| 22:33:11 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 22:33:13 | Jehan_ | Pascal and Smalltalk erred towards the other extreme, but C is overdoing it, too. |
| 22:42:01 | * | Jehan_ quit (Quit: Leaving) |
| 22:47:50 | * | dumbex is now known as comex |
| 22:48:02 | * | gelumelu quit (Quit: Page closed) |
| 22:49:29 | Varriount | Araq: Is 'master' the default branch? |
| 22:49:54 | Araq | it's the branch we advertise as "really stable" |
| 22:50:33 | Varriount | No, I mean, if I clone the github repo without checking out a branch afterwards, what branch is the repository on by default? |
| 22:51:47 | EXetoC | devel |
| 22:52:16 | * | Sh00ck quit () |
| 23:01:52 | Varriount | Araq: ping |
| 23:02:06 | Araq | pong |
| 23:02:31 | Varriount | Araq: Master fails to build - there's an error about not explicity importing the widestr module |
| 23:03:18 | Varriount | https://gist.github.com/Varriount/0be398cbd597c29d6cff |
| 23:04:02 | Araq | build *from what*? |
| 23:04:10 | Varriount | csources |
| 23:05:02 | Araq | ah yeah, makes even sense |
| 23:05:51 | Varriount | You know, we could just have csources contain branches corresponding to branches in the nimrod repository. |
| 23:06:15 | Araq | yeah ... that would have been a really good idea |
| 23:08:05 | Araq | can you do that? |
| 23:08:23 | Araq | it's simply reversing and pushing the changes into different branches instead |
| 23:08:30 | * | Jehan_ joined #nimrod |
| 23:08:47 | * | saml_ quit (Remote host closed the connection) |
| 23:08:49 | Varriount | Uh.. I can try.. |
| 23:09:23 | Varriount | Araq: I just hope git doesn't explode or something |
| 23:09:26 | Jehan_ | You can just point the various branches at new commits. |
| 23:10:00 | Varriount | Jehan_: And how would I do that exactly? I have an idea of what to do, but nothing specific. |
| 23:10:17 | * | fowl quit (Ping timeout: 272 seconds) |
| 23:10:35 | Varriount | Also, I assume that re-writing history is acceptable? People really shouldn't be forking the csources repository in any case. |
| 23:12:22 | Jehan_ | You won't be rewriting history, you'll just be renaming/moving branches. |
| 23:12:32 | Jehan_ | In Git, branches are nothing but pointers to commits. |
| 23:12:50 | Jehan_ | What you have to be careful about is not having a commit that's not being pointed to by a named branch. |
| 23:15:29 | Jehan_ | See https://github.com/rbehrends/csources (I think I've got the branches in the right places). |
| 23:15:50 | Jehan_ | What you do: |
| 23:16:10 | Jehan_ | git checkout -b bigbreak origin/master |
| 23:16:23 | Jehan_ | git checkout -b devel 7d454fb |
| 23:16:33 | Jehan_ | git branch -d master |
| 23:16:44 | Jehan_ | git checkout -b master 0a6e575 |
| 23:17:00 | Jehan_ | I think the revision numbers are correct, but please verify. |
| 23:17:08 | Jehan_ | Then: git push -f |
| 23:17:22 | Jehan_ | The -f will allow you to reorganize the branch structure. |
| 23:17:48 | imjoe | dom96: I took out the threads and modified the script to actually bring down a list of domains to webget against. I don't know why results don't start coming back until all createRequest()'s have been issued. It's more pronounced with larger numbers: |
| 23:17:51 | imjoe | https://gist.github.com/anonymous/20608afe2d168dc872e3 |
| 23:19:11 | Jehan_ | Some more information about git and rewriting history: |
| 23:19:27 | Jehan_ | Rewriting history will not in and of itself lose you data. |
| 23:19:44 | Jehan_ | Data loss occurs when the inevitable garbage collection happens and commits are unreachable. |
| 23:20:54 | Jehan_ | Git looks for any commits that aren't referenced by a branch directly and don't have any descendants that are referenced by a branch, either. |
| 23:21:09 | Jehan_ | Such commits are considered unreachable and subject to garbage collection. |
| 23:21:19 | Jehan_ | There are a couple of safeguards: |
| 23:21:45 | Jehan_ | First, there's a grace period (two weeks by default) during which recent commits won't get GCed. |
| 23:22:09 | Jehan_ | Second, Git maintains a reflog - a history of references to visited commits, basically. |
| 23:22:23 | Jehan_ | As long as a commit is referenced by the reflog, directly or indirectly, it's also safe. |
| 23:22:45 | Jehan_ | Unreachable commits are removed from the reflog after 30 days, so that's the other grace period. |
| 23:23:20 | Jehan_ | So, the trick is to keep commits alive by always having a branch pointing at them, directly or indirectly. |
| 23:23:59 | Jehan_ | This means that it's safe, for example, to have bigbreak point to the current master. It's just a different name, but will still keep it alive. |
| 23:25:03 | Jehan_ | Renaming branches would still be a pain in a regular repository, because then suddenly all downstream repos would get confused with respect to their recent changes. But since csources is basically a glorified FTP server, that's no big deal. |
| 23:39:04 | * | xenagi joined #nimrod |
| 23:47:45 | NimBot | Araq/Nimrod bigbreak 1cdb802 Araq [+0 ±3 -0]: changed comment handling (breaking change) |
| 23:47:45 | NimBot | Araq/Nimrod bigbreak 0e50784 Araq [+0 ±5 -0]: Merge branch 'bigbreak' of https://github.com/Araq/Nimrod into bigbreak |
| 23:47:45 | NimBot | Araq/Nimrod bigbreak 428ee0c Araq [+0 ±1 -0]: changed comment handling (breaking change); part 2 |
| 23:48:56 | * | Varriount gasps |
| 23:48:56 | * | Matthias247 joined #nimrod |
| 23:49:03 | * | Matthias247 quit (Client Quit) |
| 23:50:27 | * | filwit joined #nimrod |
| 23:50:41 | Araq | hey filwit |
| 23:50:59 | filwit | hey Araq |
| 23:51:01 | * | xenagi quit (Quit: Leaving) |
| 23:51:07 | Araq | I found out we have docjson command |
| 23:51:28 | filwit | lol, nice discovering things in your own language :) |
| 23:51:35 | Araq | so you can use that and transform the output to whatever you like |
| 23:51:44 | * | Trustable quit (Quit: Leaving) |
| 23:51:48 | Araq | without changing anything ... perhaps |
| 23:52:00 | filwit | okay, thanks for the heads up. Will give it a look. |
| 23:52:03 | willwillson | in tools/nimgrep.nim there is a case sensitivity issue with the identifier, Version, on line 15 |
| 23:52:18 | Varriount | willwillson: On the bigbreak branch? |
| 23:52:59 | Araq | Varriount: yes. |
| 23:54:29 | Onionhammer | Araq i totally added that json command |
| 23:54:30 | Onionhammer | :P |
| 23:54:36 | Onionhammer | araq i seem to recall you not supporting it at the time |
| 23:54:56 | Varriount | Perhaps we should name it the oniondoc command |
| 23:55:07 | Araq | Onionhammer: just wait until filwit tries to use it |
| 23:55:19 | Onionhammer | yeah oniondoc |
| 23:55:21 | Araq | and then wait for the complaints |
| 23:55:21 | Onionhammer | i like that |
| 23:55:52 | Araq | and then, my friend, I will say: "welcome to my world" :P |
| 23:55:54 | Onionhammer | I added it for NimLime varriount |
| 23:56:17 | filwit | it depends, it might be better to just hack on the existing docgen. Will see soon. |
| 23:56:38 | Araq | filwit: have a look at 'nimfix' |
| 23:57:19 | Araq | it's a new command that uses the compiler |
| 23:57:44 | Araq | as opposed to a new command within the compiler |
| 23:57:44 | filwit | Onionhammer: read logs, concerning 'await' as keyword.. I've been thinking about making a highligher regex for NimKate that will highlight any word followed by whitespace then commands as a "action" (keyword) |
| 23:57:55 | filwit | Araq: okay |
| 23:59:15 | filwit | Onionhammer: the regex is pretty straight forward, but I'm not sure everyone would appreciate all their bracketless commands looking like keywords... then again, it would mean that special case macros would stand out (await, spawn, etc) without the need for specific support in the scheme |
| 23:59:44 | filwit | bracketless calls** |