| 00:01:07 | * | Boscop quit (Ping timeout: 245 seconds) |
| 00:04:39 | * | c74d joined #nimrod |
| 00:05:44 | flaviu | I wrote a library to parse urls a while ago, if anyone who's working on the requests library cares. |
| 00:05:51 | flaviu | https://gist.github.com/68a49263688c47f5bc2f |
| 00:09:04 | Joe_knock | flaviu: Can you jump to #openssl quickly? We seem to be making progress |
| 00:11:24 | * | dts quit (Read error: Connection reset by peer) |
| 00:12:36 | * | dom96 quit (Excess Flood) |
| 00:13:41 | * | dom96 joined #nimrod |
| 00:14:57 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:15:52 | * | vendethiel quit (Ping timeout: 255 seconds) |
| 00:18:04 | ldlework | Wait for ssl do I need to compile nim itself with support? |
| 00:19:25 | flaviu | Nope, just your program |
| 00:19:37 | ldlework | flaviu: is it just --ssl? |
| 00:19:44 | flaviu | -d:ssl |
| 00:19:55 | ldlework | ah |
| 00:21:52 | ldlework | This is why I like explicit exports |
| 00:21:59 | ldlework | In the httpclient there is a symbol CVerifyNone |
| 00:22:05 | ldlework | how can I know where it comes from |
| 00:24:36 | EXetoC | I don't they should be used when it's obvious, but I've noticed that almost no one qualifies symbols |
| 00:26:20 | ldlework | its a bad trend, we should enforce a culture early |
| 00:28:39 | ldlework | so uh... |
| 00:29:17 | ldlework | flaviu: Joe_knock Araq https://gist.github.com/dustinlacewell/060bb0d3f7eee1c0ad4c |
| 00:29:44 | ldlework | flaviu: there was never any bug at all |
| 00:29:53 | ldlework | client verification -is- implemented in our http client :) |
| 00:29:57 | flaviu | Just poor defaults? |
| 00:30:03 | ldlework | yes, check the gist |
| 00:30:05 | ldlework | :P |
| 00:31:05 | * | vendethiel joined #nimrod |
| 00:31:41 | Joe_knock | you guys left without saying thank you :( |
| 00:32:47 | ldlework | pfff |
| 00:32:54 | ldlework | he didn't help at all :P |
| 00:33:23 | flaviu | ldlework: So? He tried to help, and was very patient. |
| 00:33:29 | ldlework | Agreed there |
| 00:34:11 | Joe_knock | If the error gets repaired over the next few days, I'm going to make a PR in a comment saying "Thank you to byte_bucket from ##openssl for helping fix this issue" |
| 00:35:14 | Joe_knock | That's the least we can do. |
| 00:36:46 | ldlework | There is no error |
| 00:36:51 | ldlework | :/ |
| 00:36:57 | Joe_knock | So it works? |
| 00:37:01 | ldlework | Yeah, it does |
| 00:37:14 | Joe_knock | Where did that error come from? |
| 00:37:22 | ldlework | What are you talking about? |
| 00:37:34 | Joe_knock | okay, I mean that "issue", not error, from the Issue opened on GH |
| 00:37:54 | ldlework | Joe_knock: a user who didn't read the documentation, who fooled us all into thinking our software was worse than it really is? |
| 00:38:18 | Joe_knock | aah :-/ |
| 00:38:23 | Joe_knock | :'D |
| 00:39:01 | ldlework | Well I guess technically defaultSSLContext isn't documented |
| 00:39:09 | Joe_knock | I recall him mentioning that we shouldn't roll our own http client and instead use something like libcurl. |
| 00:39:25 | Joe_knock | Is there any reason why we aren't doing that? |
| 00:39:30 | ldlework | I think he was trying to give advice in a situation where we clearly didn't even know what we were asking |
| 00:39:47 | flaviu | Yeah, libcurl seems pretty easy to use. Not sure how it'd interact with async |
| 00:40:08 | ldlework | Gues |
| 00:40:10 | ldlework | Guys |
| 00:40:16 | ldlework | We haven't rolled our own |
| 00:40:36 | flaviu | we haven't? |
| 00:40:39 | ldlework | Our socket module correctly (as least as far as this issue goes) utilizes openssl directly to do certificate verification |
| 00:40:50 | flaviu | That's rolling our own.. |
| 00:40:55 | ldlework | er..no? |
| 00:41:09 | flaviu | Openssl is nearly impossible to use securly |
| 00:41:32 | flaviu | He isn't referring to the actual TLS implementation, he's referring to the difficulty of using openssl properly. |
| 00:41:34 | * | ldlework steps out of the twilight zone and lets you guys have that philosophical discussion |
| 00:41:58 | ldlework | flaviu: using libcurl solves literally nothing whatsoever |
| 00:42:21 | Joe_knock | ldlework: So had we used libcurl, we'd be using a layer between openssl and the actual cert verification |
| 00:42:24 | Joe_knock | *? |
| 00:42:28 | ldlework | We use openssl for tls at the transport layer! |
| 00:42:32 | ldlework | It has nothing to do with http |
| 00:42:43 | ldlework | libcurl is a red herring and has confused you |
| 00:42:55 | flaviu | http://curl.haxx.se/libcurl/c/https.html |
| 00:43:07 | flaviu | libcurl would simplify things considerbly |
| 00:43:09 | * | ldlework facepalms |
| 00:43:23 | flaviu | I suppose I'm misunderstanding what you mean? |
| 00:43:35 | ldlework | flaviu: okay and what is our solution for non-http network applications that need tls support |
| 00:43:43 | ldlework | how does -libcurl- help us ? |
| 00:43:55 | ldlework | our httpclient doesn't implement tls -at all- |
| 00:43:58 | ldlework | our sockets module does |
| 00:44:05 | ldlework | because tls is a transport security layer |
| 00:44:08 | ldlework | and has nothing to do with http |
| 00:44:14 | ldlework | or libcurl, an http client library |
| 00:44:15 | Joe_knock | that makes sense |
| 00:44:16 | * | ldlework swirls |
| 00:44:18 | flaviu | Oh, I see what you mean. |
| 00:44:26 | ldlework | hehe okay |
| 00:44:44 | ldlework | we are correctly using openssl, for at least certificate hostname verification |
| 00:44:52 | Joe_knock | libcurl would corner us if we wanted non-http apps |
| 00:45:04 | ldlework | (in the sockets module) |
| 00:45:11 | ldlework | (which everything else is built upon) |
| 00:45:24 | Joe_knock | ldlework: as far as those 2 open issues on github goes, can we safely say they are "closable" ? |
| 00:45:29 | ldlework | Well |
| 00:45:41 | ldlework | I think so, he didn't give a different example for the chain verification |
| 00:45:50 | ldlework | so while it looks right in the code, we don't have a differentiating test case |
| 00:46:10 | flaviu | Are we disabling all the stupid encryption algorithms like DES and Dual_EC_DRBG? |
| 00:46:38 | Joe_knock | Well I don't know if Araq is here or not, but I think these high priority issues have been considerably solved (or close to solving now). |
| 00:47:02 | ldlework | flaviu: I think that any legitimate language should at some point have a proprietary security company audit their security libraries |
| 00:47:33 | ldlework | None of us are qualified to say whether everything is good |
| 00:47:55 | Joe_knock | So 1.0.0 would be a good point to have this audit done. |
| 00:47:59 | flaviu | Yeah, but we can at least fix the low-hanging problems |
| 00:48:10 | ldlework | flaviu: we could just make things worse |
| 00:48:22 | ldlework | you have no idea if you're interpreting advice you're reading correctly |
| 00:48:39 | ldlework | or if there are unmentioned considerations that contextualize the advice that you don't know |
| 00:49:05 | flaviu | Disabling DES and Dual_EC_DRBG will not make things worse. Dual_EC_DRBG is clearly backdoored, and DES was only half-terrible in the early 90s, these days it thoroughly broken. |
| 00:49:29 | ldlework | flaviu: are they even enabled? |
| 00:50:36 | flaviu | I'm not sure |
| 00:51:12 | willwillson | ldlework: did you try your httpclient gist with a site that has a valid certificate? |
| 00:52:39 | ldlework | ohshit! |
| 00:54:44 | Joe_knock | taram dish! |
| 00:56:22 | flaviu | 'TLSv1+HIGH:!SSLv2:RC4+MEDIUM:!aNULL:!eNULL:@STRENGTH' looks good as a cipher list |
| 00:56:59 | flaviu | It doesn't have any horrible stuff like DES, but it still supports windows XP, Iran, North Korea, and Cuba |
| 00:58:09 | ldlework | Hmm |
| 00:58:12 | ldlework | what a useless error |
| 00:58:44 | flaviu | nm, it doesn't support those countries. The RC4 key length must be <= 64 for it to be legal to export there |
| 00:59:35 | * | Puffin joined #nimrod |
| 00:59:58 | ldlework | yeah no idea anymore, because its a generic error |
| 01:01:26 | Joe_knock | ldlework: So where are we now? |
| 01:01:54 | ldlework | Joe_knock: looks like if you turn validation on it rejects valid certificates |
| 01:02:00 | ldlework | But the error is a generic rejection |
| 01:02:02 | ldlework | so I have no clue |
| 01:02:40 | Joe_knock | but we have deduced that our implementation is in sockets.nim, so we know that something is "possibly" wrong there. |
| 01:02:40 | * | flaviu quit (Read error: Connection reset by peer) |
| 01:04:08 | ldlework | hmm |
| 01:04:14 | dom96 | The reason we are not using libcurl is because we don't want to depend on it. |
| 01:04:18 | dom96 | and I hate dependencies. |
| 01:04:24 | dom96 | I skimmed the discussion. |
| 01:04:37 | * | flaviu joined #nimrod |
| 01:04:46 | flaviu | Where is `ErrErrorString()` even defined? |
| 01:04:52 | dom96 | I hope you guys are not considering writing your own SSL lib though? :P |
| 01:05:22 | flaviu | dom96: I'm 99% sure that "rolling your own" means rolling your own usage of openssl |
| 01:05:30 | dom96 | Joe_knock: https://github.com/dom96/jester/blob/new-async/tests/newtest.nim |
| 01:06:42 | flaviu | Yeah, I can't find a definition for ErrErrorString anywhere. |
| 01:06:50 | * | Puffin is now known as BitPuffin |
| 01:07:04 | Joe_knock | Perhaps if we let in the use of libcurl for now, we can at least have SSL running for http (which will be big for 1.0 and web apps built in nim) |
| 01:07:26 | dom96 | we already have SSL running for HTTP |
| 01:07:33 | flaviu | dom96: Not very well though. |
| 01:07:39 | flaviu | No hostname verification is done. |
| 01:08:02 | dom96 | Then it's time to fix that. |
| 01:08:19 | flaviu | https://github.com/iSECPartners/ssl-conservatory/blob/master/openssl/everything-you-wanted-to-know-about-openssl.pdf |
| 01:08:33 | Joe_knock | perhaps flaviu and ldlework shouldn't have left the openssl channel that quickly :'D |
| 01:08:44 | Joe_knock | dom96: thanks for sharing that link |
| 01:08:54 | dom96 | Sure. |
| 01:09:00 | flaviu | It's clear how openssl works, I hate to ask questions without doing my research |
| 01:09:05 | dom96 | btw guys |
| 01:09:14 | dom96 | Now that I am not around as much on IRC |
| 01:09:27 | dom96 | Please email me if you have questions about the stuff I wrote. |
| 01:09:31 | dom96 | like httpclient |
| 01:09:35 | dom96 | jester |
| 01:09:38 | dom96 | async |
| 01:09:40 | dom96 | and the like |
| 01:09:53 | dom96 | or tweet at me |
| 01:10:23 | dom96 | (my contact info is available at http://picheta.me/aboutme.html) |
| 01:14:43 | rpag | dom96, why are you leaving irc, it's the only medium worthwhile |
| 01:14:58 | dom96 | i'm not leaving |
| 01:15:17 | dom96 | I'm just busier than usual so I don't have as much time to be active on it. |
| 01:15:32 | Joe_knock | IRC can become time-consuming. |
| 01:15:58 | rpag | less annoying than twitter though |
| 01:16:05 | Joe_knock | I shall sign up to the forum tomorrow, so hopefully you have email notifications available on it, dom96 |
| 01:16:12 | flaviu | `let defaultSSLContext = newContext(verifyMode = CVerifyNone)`, wtf |
| 01:17:37 | dom96 | Joe_knock: no email notifications there unfortunately |
| 01:18:19 | ldlework | dom96: so, if you turn on peer verification with the httpclient, it rejects every certifiate, like google.com, etc |
| 01:19:24 | flaviu | Because a certificate store isn't configured |
| 01:19:55 | ldlework | That could be why but I don't see any api exposed for it |
| 01:20:09 | ldlework | the SSLContext takes a cert and key file but that's for listening sockets |
| 01:20:31 | EXetoC | Joe_knock: lots of noise |
| 01:20:59 | flaviu | openssl has `int SSL_CTX_load_verify_locations(SSL_CTX *ctx, const char *CAfile, const char *CApath);` |
| 01:21:05 | flaviu | but it looks like nim doesn't expose it |
| 01:21:16 | EXetoC | and things have to be repeated all the time |
| 01:21:28 | ldlework | flaviu: cool lets try that |
| 01:21:43 | flaviu | I can't find a simple, cross-platform way to get the OS certificate store. I think it'd be best to ship mozilla's with the installer |
| 01:22:36 | Joe_knock | EXetoC: Are repeat posts cleaned up/merged? |
| 01:23:19 | Joe_knock | flaviu: Why don't we focus on primary support for the dominant OSes we use? Or are we being liberal with all OS support? |
| 01:23:58 | flaviu | Joe_knock: Have fun, but it looks like libcurl also decided that was too much work. |
| 01:24:05 | flaviu | http://curl.haxx.se/docs/caextract.html |
| 01:24:44 | Joe_knock | so depending on libcurl makes us depend on mozilla :'D |
| 01:24:47 | Joe_knock | haha |
| 01:24:58 | EXetoC | Joe_knock: talking about IRC |
| 01:25:18 | flaviu | I'm not saying we should depend on libcurl. I'm just saying that they looked at the problem, and decided the easiest path was to distribute their own. |
| 01:25:36 | ldlework | flaviu: where is it on ubuntu |
| 01:26:58 | * | BitPuffin quit (Ping timeout: 255 seconds) |
| 01:27:09 | Joe_knock | EXetoC: That is true. |
| 01:27:11 | flaviu | I don't have any clue, sorry. try `find . -name *.crt` |
| 01:28:23 | ldlework | Nice! |
| 01:28:25 | ldlework | flaviu: that works |
| 01:29:11 | * | flaviu quit (Read error: Connection reset by peer) |
| 01:29:41 | Joe_knock | I get some certs in .mozilla ? |
| 01:29:45 | ldlework | ah darn it |
| 01:29:55 | ldlework | now it accepts the invalid cert |
| 01:30:15 | ldlework | I added |
| 01:30:17 | ldlework | discard SSL_CTX_load_verify_locations(newCTX, "/etc/ssl/certs/ca-certificates.crt", "/usr/share/ca-certificates"); |
| 01:30:21 | ldlework | to line 331 in sockets.nim |
| 01:30:51 | * | flaviu joined #nimrod |
| 01:32:26 | flaviu | The second argument can be nil, but it lets a self-signed cert through for me too. |
| 01:32:39 | flaviu | Oh, I see the problem |
| 01:33:11 | flaviu | The cert is fine! It's for the wrong domain, and we haven't implemented checking for domain |
| 01:34:31 | flaviu | There is identical code in `pure/sockets.nim` and `pure/net.nim`.. |
| 01:37:17 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 01:39:36 | * | BitPuffin joined #nimrod |
| 01:57:18 | * | vendethiel joined #nimrod |
| 01:57:53 | * | Joe_knock quit (Quit: Leaving) |
| 01:58:32 | * | willwillson quit (Remote host closed the connection) |
| 02:02:41 | * | darkf joined #nimrod |
| 02:15:20 | * | Demos joined #nimrod |
| 02:16:24 | * | brson quit (Ping timeout: 244 seconds) |
| 02:19:19 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 02:21:35 | * | vendethiel joined #nimrod |
| 02:24:13 | * | q66 quit (Quit: Leaving) |
| 02:24:45 | * | superfunc joined #nimrod |
| 02:25:23 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 02:28:44 | superfunc | hey everybody |
| 02:37:32 | flaviu | hey superfunc |
| 02:44:25 | * | vendethiel quit (Ping timeout: 258 seconds) |
| 02:47:28 | * | superfunc_ joined #nimrod |
| 02:47:51 | * | saml_ joined #nimrod |
| 02:49:13 | * | superfunc quit (Ping timeout: 246 seconds) |
| 02:49:13 | * | superfunc_ is now known as superfunc |
| 02:53:20 | * | vendethiel joined #nimrod |
| 02:56:38 | * | saml_ quit (Ping timeout: 250 seconds) |
| 03:10:38 | * | saml_ joined #nimrod |
| 03:15:25 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 03:19:28 | * | saml_ quit (Ping timeout: 255 seconds) |
| 03:19:53 | * | kapil__ joined #nimrod |
| 03:20:38 | ldlework | flaviu: did you come up with a patch? |
| 03:21:43 | flaviu | ldlework: Not quite. I expect part of my patch to be rejected, and we need to figure out how we're going to distribute the certificates. |
| 03:22:04 | flaviu | ldlework: https://github.com/Araq/Nimrod/issues/782 |
| 03:23:28 | ldlework | cool |
| 03:25:41 | ldlework | I was just thinking of a website that features neat uses of the macro system, like DSL's and such |
| 03:26:20 | flaviu | gist.github.com? :P |
| 03:26:56 | ldlework | Not great for indexing, etc |
| 03:27:17 | * | enquora quit (Quit: enquora) |
| 03:31:37 | * | Var|Mobile quit (Ping timeout: 240 seconds) |
| 03:31:59 | * | saml_ joined #nimrod |
| 03:32:16 | * | vendethiel joined #nimrod |
| 03:32:46 | ldlework | flaviu: what if you made a static github-pages website that used the github api to retrieve and create a gallery from files in the same repo but on the main branch :P |
| 03:34:43 | ldlework | hmm I suppose you wouldn't need to do that |
| 03:34:43 | flaviu | ldlework: If it used javascript, it'd be terrible for search engines. But github pages would work great. |
| 03:35:10 | flaviu | Just have people send PRs, and github would automatically render and deploy the pages. |
| 03:35:13 | ldlework | yeah |
| 03:35:18 | * | EXetoC quit (Ping timeout: 256 seconds) |
| 03:36:08 | flaviu | I like to create an organization for this sort of stuff so that I get a cleaner url. |
| 03:36:16 | ldlework | do we have a nim organization yet? |
| 03:36:34 | flaviu | Yes, nim-code |
| 03:37:00 | ldlework | flaviu: I'm thinking we include a tiny script, so that when you add your page, you run the script, it generates a json file which drives some javascript so you can say, organize the examples by tag |
| 03:37:10 | flaviu | But I want to make an org for a org-name.github.io url |
| 03:37:15 | ldlework | You know |
| 03:37:21 | flaviu | yes, javascript could be used to make the page more dynamic |
| 03:37:23 | ldlework | Github is totally cool about giving people usernames they deserve |
| 03:37:25 | ldlework | seriously |
| 03:37:38 | flaviu | huh? |
| 03:37:45 | ldlework | github.com/nim/ hasn't ever done any activity |
| 03:37:56 | ldlework | they would totally give us nim if we asked |
| 03:38:17 | flaviu | Why would we want it? |
| 03:38:19 | ldlework | when I asked for one, they replied in a day |
| 03:38:25 | ldlework | why wouldn't we? |
| 03:38:36 | flaviu | Because Nim is a project, not a user |
| 03:38:43 | ldlework | what? |
| 03:39:12 | ldlework | I'm saying they would give us the 'nim' namespace for the organization |
| 03:39:15 | ldlework | if we simply asked |
| 03:40:05 | flaviu | I don't see the point, but I have no control over Nim's direction anyway. |
| 03:40:23 | * | saml_ quit (Ping timeout: 264 seconds) |
| 03:40:25 | flaviu | "nim-snippets"? |
| 03:40:57 | ldlework | nimblets |
| 03:41:10 | flaviu | Already taken |
| 03:41:46 | flaviu | Clever though |
| 03:42:18 | ldlework | nimlets is available, but it doesn't seem as good |
| 03:43:12 | ldlework | ah its not so bad |
| 03:43:14 | ldlework | nimlets |
| 03:43:46 | flaviu | What's the pun there? |
| 03:44:07 | ldlework | there is none, its just short and memorable |
| 03:44:10 | ldlework | 'scriptlets' |
| 03:45:15 | flaviu | Ok, sounds good |
| 03:49:43 | ldlework | What I like about this, is we can set a style guide for what kind of tags are good |
| 03:49:58 | ldlework | so we can keep the number low and congruent |
| 03:52:42 | ldlework | flaviu: how do you think it should work? |
| 03:53:35 | flaviu | There is a special header with tags and such |
| 03:54:04 | ldlework | the 'compile' script recurses the filesystem, and creates a json map? |
| 03:54:08 | flaviu | User creates a PR, if the PR is merged, a build tool takes all the header info and condenses it into one javascript object. |
| 03:54:10 | flaviu | yep |
| 03:54:25 | ldlework | we should implement that in Nim |
| 03:54:28 | ldlework | using nimr |
| 03:55:10 | flaviu | Sure, why not. I use wercker for nim-by-example, perhaps we can use that |
| 03:55:26 | ldlework | I mean come on :P |
| 03:55:41 | ldlework | flaviu: we should make it so each file is a compile-able and runnable nim example |
| 03:55:53 | ldlework | so the meta-data goes into nim comments at the top or something? |
| 03:56:06 | ldlework | that way you can clone the repo and try stuff out |
| 03:56:37 | flaviu | I guess that'd work, although there would be less friction if we just directly used markdown |
| 03:57:10 | flaviu | instead of parsing nim to html, just parse markdown to html |
| 03:57:46 | ldlework | I mean |
| 03:57:56 | ldlework | we can just do something extremely simple |
| 03:58:05 | ldlework | a convention where the very first line is a list of tags |
| 03:58:10 | ldlework | what else is needed? |
| 03:58:32 | ldlework | that way, I can clone the repo, and run the example I just looked at with nim c -r theexample.nim |
| 03:58:33 | ldlework | that's huge |
| 03:58:55 | ldlework | people don't need markdown for their examples do they? |
| 03:59:12 | flaviu | No, you're right. I was thinking about allowing more explaination |
| 03:59:14 | ldlework | We should just have nim code, with explanations in comments |
| 03:59:30 | flaviu | but people can just manually wrap their comments, it's not that bad. |
| 03:59:36 | ldlework | yeah |
| 03:59:56 | ldlework | It'll get people into the nim code quicker, etc |
| 04:00:03 | flaviu | http://nimlets.github.io/ doesn't work for you, does it? |
| 04:00:14 | ldlework | nope |
| 04:00:14 | * | j3rky joined #nimrod |
| 04:01:11 | flaviu | anyway, good night. I added you to the organization btw |
| 04:01:25 | ldlework | o/ |
| 04:05:53 | * | flaviu quit (Ping timeout: 264 seconds) |
| 04:38:17 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 04:46:51 | * | gmpreussner joined #nimrod |
| 04:47:07 | * | vendethiel joined #nimrod |
| 04:47:35 | * | j3rky quit (Ping timeout: 264 seconds) |
| 04:52:42 | * | superfunc quit (Quit: Connection closed for inactivity) |
| 04:54:13 | * | edayo_ joined #nimrod |
| 05:03:21 | ldlework | Is there a way to get nim to read from stdin? |
| 05:08:37 | ldlework | odd, I can't do: self.setrule(self.ruleno() - 1) |
| 05:08:38 | ldlework | ? |
| 05:09:18 | ldlework | nevermind |
| 05:23:41 | * | gmpreussner quit (Quit: Konversation terminated!) |
| 05:24:03 | * | edayo_ quit (Quit: Leaving) |
| 05:32:33 | * | j3rky joined #nimrod |
| 05:33:03 | * | Demos quit (Read error: Connection reset by peer) |
| 05:40:20 | * | c74d quit (Remote host closed the connection) |
| 05:45:10 | * | BlaXpirit joined #nimrod |
| 05:45:22 | * | dts joined #nimrod |
| 05:53:25 | * | c74d joined #nimrod |
| 05:53:35 | * | darkf_ joined #nimrod |
| 05:54:47 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 05:55:19 | * | darkf quit (Ping timeout: 258 seconds) |
| 05:56:33 | * | vendethiel joined #nimrod |
| 06:04:57 | * | j3rky quit (Quit: Konversation terminated!) |
| 06:05:16 | * | darkf joined #nimrod |
| 06:07:12 | * | darkf_ quit (Ping timeout: 258 seconds) |
| 06:09:16 | * | c74d quit (Remote host closed the connection) |
| 06:13:24 | * | c74d joined #nimrod |
| 06:17:53 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 06:20:00 | * | vendethiel joined #nimrod |
| 06:36:51 | * | brson joined #nimrod |
| 06:51:25 | * | c74d quit (Remote host closed the connection) |
| 06:53:13 | * | skyfex quit (Quit: (null)) |
| 06:53:44 | * | skyfex joined #nimrod |
| 06:55:44 | * | c74d joined #nimrod |
| 07:04:04 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 07:16:33 | * | vendethiel joined #nimrod |
| 07:17:13 | * | c74d quit (Remote host closed the connection) |
| 07:19:17 | * | gokr_ quit (Ping timeout: 240 seconds) |
| 07:20:52 | * | brson quit (Quit: leaving) |
| 07:21:30 | * | c74d joined #nimrod |
| 07:21:59 | * | gokr_ joined #nimrod |
| 07:24:15 | * | dts is now known as dts|pokeball |
| 07:35:03 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 07:38:17 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 07:44:40 | * | vendethiel joined #nimrod |
| 07:49:42 | * | gokr_ quit (Read error: Connection reset by peer) |
| 07:52:40 | * | gokr_ joined #nimrod |
| 08:10:42 | * | c74d quit (Remote host closed the connection) |
| 08:12:40 | gokr | Morning! |
| 08:13:26 | gokr | ldlework: Reading from stdin works fine for me, however, readAll does not, at least not on win32. |
| 08:13:56 | ldlework | gokr: I mean streaming code into the compiler through a pipe on the commandline |
| 08:14:09 | ldlework | cat foo.nim | nim c -r -- |
| 08:14:14 | ldlework | something like that |
| 08:14:51 | * | c74d joined #nimrod |
| 08:17:16 | dts|pokeball | does that make much sense for a compiler though? |
| 08:17:20 | dts|pokeball | to read from stdin? |
| 08:18:27 | gokr | ldlework: blimp that I wrote can be used as a filter with git |
| 08:18:32 | gokr | AFAIK git pipes into it. |
| 08:18:54 | ldlework | hey how do I reverse a sequence or iterate it backwards? |
| 08:19:07 | gokr | I used "allinput = readAll(stdin)" and that worked fine, but not on win32 |
| 08:19:57 | gokr | This had to do with how readAll first tries to find size of "the file" and it fails on win32. But fix was simple, I just plucked out the readAllBuffer proc from system.nim (IIRC) and used it without that "find size trick". |
| 08:20:09 | gokr | I should create an issue for that btw. |
| 08:21:47 | gokr | ldlework: In algorithm module you find reverse() |
| 08:21:55 | ldlework | gokr: does that work on sets? |
| 08:22:06 | gokr | Eh, waf? |
| 08:22:28 | ldlework | gokr: I want to iterate a set backwards somehow |
| 08:22:31 | ldlework | err |
| 08:22:33 | ldlework | sorry |
| 08:22:35 | ldlework | seq |
| 08:22:37 | ldlework | :( |
| 08:22:39 | ldlework | its late |
| 08:22:56 | * | dts|pokeball is now known as dts |
| 08:23:12 | gokr | If a parameter has type openarray - a seq works fine. |
| 08:23:30 | gokr | I really should publish my seq article. |
| 08:23:41 | ldlework | neat |
| 08:24:37 | gokr | openArray is a bit of an "odd bird" but I interpret it as "a type I can use only for parameters - and then it will work fine for both array and seq". |
| 08:25:12 | gokr | So basically, any time you declare a parameter as seq, you may probably really want to use openArray. |
| 08:25:20 | gokr | I guess. |
| 08:26:09 | gokr | ldlework: You also have reversed() (not the "d") |
| 08:26:32 | ldlework | I have built a basic windowing system for libtcod |
| 08:26:44 | gokr | reverse is destructive, reversed gives you a reversed copy. I like that btw, similar to Smalltalk naming. |
| 08:30:10 | gokr | In Smalltalk we have do: and reverseDo: - in Nim ... perhaps we could make "reverse iterators" in Nim too. |
| 08:31:04 | ekarlso- | does nimrod feel like python ? |
| 08:33:24 | * | c74d quit (Remote host closed the connection) |
| 08:34:00 | gokr | So people sometimes say. I am a Smalltalker, so I compare with that. |
| 08:35:08 | gokr | It doesn't feel like Smalltalk though, that would be a "stretch" to say the least. But it does have lots of "dynamic taste" although being a fast efficient statically typed language. |
| 08:35:38 | gokr | It also feels like a very strong "foundation" for evolving it further. |
| 08:36:11 | gokr | I mean, adding more behaviors to core types like seq etc, is very easy. |
| 08:37:41 | * | c74d joined #nimrod |
| 08:37:51 | gokr | ekarlso-: Did you see my articles I have written recently? |
| 08:37:55 | gokr | Might be of interest. |
| 08:38:08 | Araq | ekarlso-: at one point you need to install it and use it |
| 08:38:54 | ekarlso- | Araq: :P |
| 08:39:01 | ekarlso- | doing rust atm (: |
| 08:39:08 | Araq | it's a super python without the warts :P |
| 08:39:20 | Araq | for instance, we have multi line lambdas |
| 08:39:23 | ekarlso- | https://github.com/ekarlso/rust-dns/ |
| 08:39:28 | Araq | and non broken scoping |
| 08:39:29 | ekarlso- | maybe i'll do the same for nim |
| 08:41:17 | Araq | ha |
| 08:41:27 | Araq | I open a random file |
| 08:41:39 | Araq | as expected it's full of "unwrap!" |
| 08:42:34 | Triplefox | rust is an exciting! language |
| 08:44:31 | Araq | and this is exactly what happens when you totally ignore usage statistics |
| 08:44:50 | * | bjz joined #nimrod |
| 08:44:55 | Araq | how many times to I need to be reminded that "unwrap" is a macro? |
| 08:46:15 | Araq | this is language design driven by fear which I loathe |
| 08:46:15 | ekarlso- | Araq: not my problem that it's like that :/ |
| 08:48:39 | gokr | ekarlso-: Araq critiques Rust, not you :) |
| 08:48:46 | ekarlso- | gokr: heh :p |
| 08:48:49 | ekarlso- | Araq: how does one easily install nim ? |
| 08:49:06 | gokr | ekarlso-: The best I would say is to install from source. |
| 08:49:27 | gokr | And *not* install it - just keep the clone where it is, and add "nim" to your path. |
| 08:49:39 | gokr | ekarlso-: What platform are you on? |
| 08:49:58 | ekarlso- | ubuntu :p |
| 08:50:01 | gokr | Great |
| 08:50:07 | gokr | So, see http://goran.krampe.se/category/nim/ |
| 08:50:21 | gokr | Especially: http://goran.krampe.se/2014/10/15/bootstrapping-nim/ |
| 08:50:45 | gokr | But... that is a detailed article basically summing up the 10 lines you need to run to bootstrap it - described at the download page. |
| 08:51:13 | ekarlso- | no built deb's yet ? :P |
| 08:51:40 | gokr | There may ... be, but its easier following different branches like this. |
| 08:52:14 | gokr | And also - Nim finds everything relative to the location of the binary "nim" (the compiler). |
| 08:52:29 | gokr | Thus, its easier if you don't move it to some... /usr/local/bin yadda |
| 08:52:45 | gokr | If its kept in the clone's "bin" dir, then it finds libraries etc in the clone. |
| 08:53:48 | * | c74d quit (Remote host closed the connection) |
| 08:54:08 | gokr | I generally also like debs - but... for programming tools like this, I find it nicer to have the clone and build from it. Especially since its so easy. |
| 08:54:13 | * | bjz_ joined #nimrod |
| 08:54:25 | ekarlso- | :p |
| 08:54:32 | ekarlso- | i guess it changes once it's stable :p |
| 08:54:46 | * | bjz quit (Read error: Connection reset by peer) |
| 08:54:57 | * | bjz_ quit (Read error: Connection reset by peer) |
| 08:55:16 | gokr | ldlework: Regarding reverse iteration of a "set" (yeah, I know, a typo) I think they actually have an order since its a bit set, the iterator in system.nim should be easily copied and modified to run in reverse :) :) |
| 08:55:48 | gokr | And generally, all those core iterators seem trivial to copy and create reverse variants of. |
| 08:55:49 | * | bjz joined #nimrod |
| 08:56:26 | gokr | I am guessing things like this would be put in say sequtils etc |
| 08:57:35 | gokr | ekarlso-: There are instructions on how you can install it too, but... not many seem to use it that way. :) |
| 08:59:17 | * | c74d joined #nimrod |
| 08:59:49 | * | Trustable joined #nimrod |
| 09:00:00 | * | Trustable quit (Read error: Connection reset by peer) |
| 09:01:06 | * | Trustable joined #nimrod |
| 09:02:33 | Araq | ekarlso-: older releases have ubuntu packages |
| 09:03:36 | Araq | but I don't see the point. software installation on unix like systems is inherently broken IMO |
| 09:04:32 | * | bjz quit (Ping timeout: 256 seconds) |
| 09:04:37 | * | bjz_ joined #nimrod |
| 09:07:39 | * | dts is now known as dts|pokeball |
| 09:08:19 | gokr | Araq: Still... in *practice* it works quite well in Debian/Ubuntu. |
| 09:08:37 | dts|pokeball | <Araq> but I don't see the point. software installation on unix like systems is inherently broken IMO |
| 09:08:40 | dts|pokeball | care to expand? |
| 09:09:00 | gokr | Simply because of all the man power making it work. |
| 09:09:28 | Araq | gokr: that's exactly the way to put it. |
| 09:09:34 | Araq | it works by brute force |
| 09:09:37 | gokr | (while I was chatting I ran an upgrade btw, Ubuntu evidently upgraded a whole slew of apps) |
| 09:10:11 | Araq | dts|pokeball: well spreading everything over the file system and then needing software to manage this mess is completely backwards |
| 09:10:12 | gokr | So... I agree with you that splitting stuff up like that, all over, is definitely less than "neat". But still, it works. Can't be denied. |
| 09:10:29 | dts|pokeball | Araq, meh... i guess so |
| 09:11:13 | Araq | when I say "doesn't work" I usually mean "works much less effective than an existing alternative solution" :P |
| 09:11:14 | gokr | Is it Arch that keeps it all in one place? Never played with it. |
| 09:12:08 | gokr | But I used Lunar Linux for some years, and some things are clearly lacking IMHO. Lunar tools actually were slicker in some parts, like for example easily showing history on a given package. |
| 09:12:43 | gokr | (clearly lacking in apt I mean) |
| 09:12:58 | * | uber quit (Quit: bye) |
| 09:13:48 | gokr | Lunar tracked all files that was installed by using... that tool that tracks all files created, can't remember what its called. That was neat. |
| 09:13:53 | * | vendethiel quit (Ping timeout: 258 seconds) |
| 09:15:06 | ekarlso- | do you have to use .unwrap() all the time in nim as well ? |
| 09:15:28 | * | c74d quit (Remote host closed the connection) |
| 09:15:48 | * | MightyJoe quit (Ping timeout: 258 seconds) |
| 09:16:32 | gokr | Ehm, what's unwrap? :) |
| 09:17:00 | ekarlso- | :p |
| 09:17:02 | ekarlso- | hah |
| 09:17:06 | ekarlso- | is there a intro thing ? |
| 09:17:17 | gokr | Araq: Gobolinux uses one directory per app and has redesigned the filesystem layout. But.. I thought it was some other distro that did that too. |
| 09:17:35 | gokr | Yeah, 1 sec |
| 09:17:57 | gokr | http://nimrod-by-example.github.io |
| 09:18:09 | gokr | http://learnxinyminutes.com/docs/nim |
| 09:18:41 | gokr | And http://nim-lang.org/documentation.html of course, has two tutorials etc |
| 09:19:31 | gokr | My articles also explore OO and some other things, so not written primarily as tutorials, they are probably quite nice to get started too. |
| 09:19:38 | * | c74d joined #nimrod |
| 09:22:49 | gokr | Ah, NixOS is similar. |
| 09:22:56 | * | Etheco joined #nimrod |
| 09:28:20 | ekarlso- | gawd, so many languages :P |
| 09:30:57 | * | c74d quit (Remote host closed the connection) |
| 09:38:10 | * | MightyJoe joined #nimrod |
| 09:39:40 | * | c74d joined #nimrod |
| 09:40:10 | * | rpag quit (Quit: Leaving) |
| 09:41:48 | * | johnsoft quit (Ping timeout: 250 seconds) |
| 09:42:02 | * | johnsoft joined #nimrod |
| 09:45:11 | * | vendethiel joined #nimrod |
| 09:45:19 | * | rpag joined #nimrod |
| 09:45:52 | * | c74d quit (Remote host closed the connection) |
| 09:48:43 | gokr | ekarlso-: Ah, unwrap - I googled it. Yeah, its because Rust (and Go) has IMHO insane primitive error handling. |
| 09:49:04 | gokr | Nim has a decent regular exception model. |
| 09:49:18 | ekarlso- | oh, even more lovely! |
| 09:49:19 | gokr | It doesn't shove itself down your throat like the one in Java though. |
| 09:49:35 | gokr | yes, its a big, big plus for Nim. |
| 09:49:43 | gokr | I have an article brewing on that too :) |
| 09:50:24 | gokr | One very cool thing that Nim has - but AFAIK its still finding its full set of use cases - is "effect tracking". |
| 09:51:03 | * | khmm joined #nimrod |
| 09:51:10 | gokr | This mechanism can be applied to exceptions, so you can declare that a proc must never raise say some Exception. |
| 09:51:32 | gokr | Then the compiler will track and statically verify that you don't accidentally call something that calls something that.... may raise that. |
| 09:53:18 | gokr | Araq can correct me if I am wrong, I haven't used this yet, but its a very slick system AFAICT. It means you can maintain control in libraries - without getting into the insane situation of checked exceptions in Java. |
| 09:54:03 | * | bjz_ quit (Quit: Textual IRC Client: www.textualapp.com) |
| 09:54:16 | * | c74d joined #nimrod |
| 09:54:27 | * | bjz joined #nimrod |
| 09:57:12 | * | khmm quit (Ping timeout: 258 seconds) |
| 10:02:01 | * | khmm joined #nimrod |
| 10:06:47 | ekarlso- | 2so, does nim have anything like http://crates.io ? |
| 10:07:15 | dom96 | No, just https://github.com/nim-lang/packages |
| 10:07:30 | ekarlso- | :/ |
| 10:08:20 | * | c74d quit (Remote host closed the connection) |
| 10:10:57 | dom96 | ekarlso-: Why so sad? You could be the one to create a crates.io for Nim ;) |
| 10:11:06 | dom96 | Wouldn't that be a fun project? |
| 10:11:52 | gokr | Its just a web frontend, right? |
| 10:12:22 | dom96 | I think they also store the packages on their server. |
| 10:12:26 | gokr | Slightly... annoyed with the trend to come up with funny words for everything. crate... sigh. |
| 10:13:27 | * | c74d joined #nimrod |
| 10:14:51 | ekarlso- | :P |
| 10:14:56 | ekarlso- | what name for nim haha ? : |
| 10:29:15 | dom96 | packages.nim-lang.org? :P |
| 10:31:53 | gokr | Yeah, I think packages are an ok name for... eh, packages. |
| 10:31:57 | gokr | :) |
| 10:32:27 | dom96 | I agree :D |
| 10:33:01 | gokr | Not that I am a total conservative, but it just gets a bit out of hand it seems. |
| 10:34:04 | ekarlso- | is there db libs for nim ? |
| 10:34:35 | gokr | Araq: Stumbled onto this, gives internal error in compiler: echo(@[1,2].map(proc(x: int): string = $x)) |
| 10:35:08 | gokr | Araq: And yes, I know, its not a string, but it shouldn't give an internal error, right? And I think it worked earlier. |
| 10:35:43 | gokr | It seems to be a regression - there was some edit around there in compiler a few days back. |
| 10:35:52 | gokr | ekarlso-: There are, but I haven't used them. |
| 10:36:16 | gokr | ekarlso-: http://nimrod-lang.org/lib.html |
| 10:37:53 | ekarlso- | k |
| 10:38:25 | gokr | dom96: Btw, really like the simplicity in nimble, so we should take care of keeping it simple. Some federation mechanism would be neat though. |
| 10:40:48 | ekarlso- | nim.io ? :p |
| 10:44:35 | gokr | Register!!! :) |
| 10:45:18 | ekarlso- | meh :p |
| 10:45:27 | gokr | Araq: I am fairly sure echo worked earlier (the implicit $ working) for results from map. It works now if I do echo($(..)) of course |
| 10:46:14 | * | bjz quit (Read error: Connection reset by peer) |
| 10:46:33 | * | bjz joined #nimrod |
| 10:52:46 | * | vendethiel quit (Ping timeout: 256 seconds) |
| 10:54:09 | * | dom96_ joined #nimrod |
| 10:54:26 | dom96_ | gokr: Thanks. I am definitely intending on keeping it as simple as possible. |
| 10:59:48 | * | gokr about to publish my seq article... :) |
| 11:13:51 | * | vendethiel joined #nimrod |
| 11:17:31 | * | Araq0 joined #nimrod |
| 11:17:57 | Araq0 | gokr_: well please create a bug report for it |
| 11:18:23 | gokr | yeah |
| 11:18:39 | Araq0 | and yeah, I changed how 'echo' works internally |
| 11:20:42 | Araq0 | bbl |
| 11:20:44 | * | Araq0 quit (Client Quit) |
| 11:23:12 | * | BlaXpirit joined #nimrod |
| 11:25:38 | * | dts|pokeball quit (Ping timeout: 256 seconds) |
| 11:26:14 | gokr | Hot off the press: http://goran.krampe.se/2014/12/03/nim-seq/ |
| 11:26:16 | gokr | :) |
| 11:39:24 | * | flaviu joined #nimrod |
| 11:41:29 | * | EXetoC joined #nimrod |
| 11:42:04 | * | flaviu quit (Remote host closed the connection) |
| 11:42:19 | * | flaviu joined #nimrod |
| 11:57:26 | * | flaviu quit (Ping timeout: 250 seconds) |
| 11:58:41 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 12:00:14 | * | vendethiel joined #nimrod |
| 12:11:24 | * | kapil__ quit (Quit: Connection closed for inactivity) |
| 12:22:08 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 12:23:34 | * | vendethiel joined #nimrod |
| 12:41:41 | * | Araq0 joined #nimrod |
| 12:42:40 | Araq0 | gokr_: nice but you really need to split up the code IMO |
| 12:42:56 | Araq0 | or maybe change your syntax highlighting colors |
| 12:43:03 | Araq0 | it's somewhat hard to read |
| 12:44:11 | gokr | Really? This time I didn't bother splitting and commenting in the article - just dumped the code to get it out there. |
| 12:44:29 | gokr | The color scheme is ok on my laptop screen - but it may be too dark for other screens? |
| 12:45:16 | dom96_ | I think it's fine. |
| 12:45:35 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 12:48:35 | gokr | I think its the default scheme for Octopress. |
| 12:50:19 | gokr | http://ethanschoonover.com/solarized |
| 12:50:36 | Araq0 | it's blue with different blue on blue and control chars are white |
| 12:50:44 | Araq0 | it's horrible |
| 12:51:50 | Araq0 | it needs much more contrast |
| 12:55:19 | Araq0 | also and that's of course not your fault: the "in" in "for ... in" is not an operator |
| 12:55:29 | Araq0 | but gets highlighted as such |
| 12:56:00 | Araq0 | that's exactly what happens when you get category happy with syntax highlighting without having a smart parser |
| 12:57:09 | Araq0 | which is why I prefer to have much fewer categories when it comes to syntax highlighting, but the rest of the world disagrees with me, of course |
| 12:57:44 | * | kostya_ joined #nimrod |
| 12:58:20 | gokr | I was just happy that I could use "nimrod" for code :) |
| 12:59:49 | EXetoC | I did replace that foreground color with something lighter from the palette when using solarized |
| 13:00:18 | Araq0 | also 'var' is not highlighted, but 'let' is |
| 13:00:28 | Araq0 | what kind of highlighter is that? |
| 13:00:41 | EXetoC | but is that even the default foreground? |
| 13:01:31 | EXetoC | right, comments, and a lot of them |
| 13:03:52 | Araq0 | and 'from' and 'import' are highlighted differently still |
| 13:04:40 | Araq0 | my guess is that it comes from C where #include is a preprocessor directive and thus special |
| 13:10:22 | * | kapil__ joined #nimrod |
| 13:12:41 | * | khmm quit (Ping timeout: 272 seconds) |
| 13:17:05 | * | khmm joined #nimrod |
| 13:20:45 | * | BitPuffin joined #nimrod |
| 13:22:41 | * | vendethiel joined #nimrod |
| 13:23:43 | EXetoC | stuffing a variant object in a table gives me a C error about an undeclared symbol. do you know if something similar has been reported? |
| 13:24:30 | EXetoC | one such bug was closed 6 days ago. I'll update the compiler |
| 13:26:36 | * | untitaker quit (Ping timeout: 264 seconds) |
| 13:31:51 | * | untitaker joined #nimrod |
| 13:44:37 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 13:53:57 | * | gokr_ quit (Ping timeout: 240 seconds) |
| 13:53:57 | EXetoC | there's another bug though, regarding recursive variant types |
| 13:54:32 | * | gokr_ joined #nimrod |
| 14:06:43 | * | vendethiel joined #nimrod |
| 14:06:50 | * | darkf quit (Read error: Connection reset by peer) |
| 14:07:26 | * | darkf joined #nimrod |
| 14:09:41 | * | khmm quit (Ping timeout: 272 seconds) |
| 14:15:35 | Araq0 | EXetoC: report it |
| 14:16:33 | EXetoC | I have |
| 14:23:21 | * | quasinoxen quit (Ping timeout: 244 seconds) |
| 14:28:05 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 14:28:06 | * | gokr_ quit (Read error: Connection reset by peer) |
| 14:28:26 | * | quasinoxen joined #nimrod |
| 14:28:56 | * | gokr_ joined #nimrod |
| 14:31:26 | * | vendethiel joined #nimrod |
| 14:36:05 | Araq0 | ty |
| 14:47:48 | * | darkf quit (Read error: Connection reset by peer) |
| 14:48:16 | * | darkf joined #nimrod |
| 14:57:25 | * | khmm joined #nimrod |
| 15:03:17 | * | khmm quit (Ping timeout: 240 seconds) |
| 15:06:21 | * | khmm joined #nimrod |
| 15:10:14 | * | khmm quit (Remote host closed the connection) |
| 15:11:15 | * | khmm joined #nimrod |
| 15:13:12 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 15:15:00 | * | darkf quit (Quit: Leaving) |
| 15:15:21 | * | vendethiel joined #nimrod |
| 15:27:02 | * | dts joined #nimrod |
| 15:31:24 | * | kapil__ quit (Quit: Connection closed for inactivity) |
| 15:32:37 | * | BitPuffin quit (Ping timeout: 258 seconds) |
| 15:36:49 | * | zio_tom78 joined #nimrod |
| 15:37:00 | zio_tom78 | Hi to everybody |
| 15:37:12 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 15:39:31 | zio_tom78 | Sorry, a silly question: I need to use ntoh on 64-bit integers. It seems that the standard library only provides ntohs (16-bit) and ntohl (32-bit). Does it exist, or should I implement one? |
| 15:39:56 | zio_tom78 | (I import the "sockets" library to have ntohs and ntohl) |
| 15:40:50 | * | vendethiel joined #nimrod |
| 15:41:32 | EXetoC | zio_tom78: see the endians module |
| 15:43:41 | * | BlaXpirit-UA joined #nimrod |
| 15:43:55 | * | BlaXpirit-UA quit (Client Quit) |
| 15:44:16 | * | BlaXpirit-UA joined #nimrod |
| 15:46:12 | zio_tom78 | EXetoC: Wow, thanks a lot! That's exactly what I was looking for! |
| 15:46:43 | * | BlaXpirit quit (Ping timeout: 252 seconds) |
| 15:49:39 | * | dts quit (Ping timeout: 252 seconds) |
| 15:55:53 | Trustable | gokr, thanks for another good article :) http://goran.krampe.se/2014/12/03/nim-seq/ |
| 15:56:09 | * | BitPuffin joined #nimrod |
| 16:03:07 | * | vendethiel quit (Ping timeout: 255 seconds) |
| 16:10:26 | * | vendethiel joined #nimrod |
| 16:18:59 | * | dts joined #nimrod |
| 16:19:08 | * | dts is now known as dts|pokeball |
| 16:23:36 | * | gokr quit (Quit: Leaving.) |
| 16:34:03 | * | gour joined #nimrod |
| 16:35:37 | * | gokr joined #nimrod |
| 16:36:10 | * | zio_tom78 quit (Ping timeout: 256 seconds) |
| 16:36:37 | * | gokr_ quit (Ping timeout: 240 seconds) |
| 16:52:41 | * | gokr1 joined #nimrod |
| 16:53:05 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 16:54:34 | * | Matthias247 joined #nimrod |
| 17:02:24 | Araq0 | http://forum.nim-lang.org/t/650 |
| 17:02:32 | * | vendethiel joined #nimrod |
| 17:05:34 | * | gour_ joined #nimrod |
| 17:06:31 | * | gour quit (Quit: Konversation terminated!) |
| 17:07:42 | * | gour_ is now known as gour |
| 17:11:12 | gokr1 | Trustable: Thanks! |
| 17:12:12 | ldlework | gokr1: just read it, agreed; great article |
| 17:12:28 | ldlework | Do we have a good dictionary too? |
| 17:13:21 | gokr1 | Its in the... tables module |
| 17:13:36 | gokr1 | http://nimrod-lang.org/tables.html |
| 17:14:00 | ldlework | ew 'bnot' |
| 17:17:56 | * | quasinoxen quit (Read error: Connection reset by peer) |
| 17:19:03 | Araq0 | ldlework: don't want to waste ~ for this really |
| 17:19:18 | Araq0 | as it's so uncommon in Nim code |
| 17:19:32 | Araq0 | (we have typed bitsets instead) |
| 17:19:44 | ldlework | Yeah but once you put 'bnot' into the language... |
| 17:20:16 | Araq0 | well just make some noise on the forum about it |
| 17:20:43 | EXetoC | < 1.0 and all that |
| 17:21:22 | Araq0 | well I don't pull these improvements out of my ass. these things produced bugs |
| 17:23:14 | Araq0 | in the real world. |
| 17:24:14 | Araq0 | note that most complaints are not about the real world, but about some fantasy land ("I can imagine this feature to cause bugs") |
| 17:25:34 | * | Stefan_Salewski joined #nimrod |
| 17:25:43 | * | vendethiel quit (Ping timeout: 245 seconds) |
| 17:26:32 | Stefan_Salewski | OK, latest glib 2.40.2 wrapper is on github now, https://github.com/StefanSalewski |
| 17:27:23 | * | khmm quit (Ping timeout: 245 seconds) |
| 17:29:05 | Stefan_Salewski | This does not include GObject, I think I will keep them separate. GObject will follow, GDK3/GTK3 needs some fixes for new naming scheme stll and some cleanup, will follow... |
| 17:29:26 | * | Stefan_Salewski quit (Client Quit) |
| 17:29:27 | Araq0 | Stefan_Salewski: yay! thanks a lot! please add them to Nimble/Babel |
| 17:29:36 | ldlework | Can someone point me to where the "Strong Spaces" thing is described? |
| 17:29:47 | Araq0 | it's somewhere in the manual |
| 17:29:55 | ldlework | ok |
| 17:31:11 | * | vendethiel joined #nimrod |
| 17:31:20 | ldlework | heh that does seem like a bad idea |
| 17:32:35 | EXetoC | it's graet |
| 17:32:58 | ldlework | hmm big thumbs down over here, I think |
| 17:33:19 | Araq0 | well it's opt-in, so don't complain :P |
| 17:33:30 | Araq0 | I still love it though |
| 17:34:03 | gokr1 | So Stefan is making a full Gtk3 binding? That's very neat. |
| 17:34:03 | ldlework | Yeah, asking humans to count spaces |
| 17:34:06 | ldlework | That's going to be popular |
| 17:34:37 | Araq0 | i+4 * 4 |
| 17:34:49 | Araq0 | who counts for this? |
| 17:34:55 | Araq0 | it's obvious |
| 17:35:02 | ldlework | yay for minimal examples |
| 17:35:23 | ldlework | Who types two spaces? |
| 17:35:28 | ldlework | i+4 * 4 |
| 17:35:31 | ldlework | is more likely |
| 17:35:34 | Araq0 | still obvious |
| 17:35:44 | ldlework | With this absolute minimal example, you're right |
| 17:36:03 | Araq0 | echo $foo # common gotcha |
| 17:36:10 | Araq0 | # but: works with strong spaces |
| 17:36:32 | ldlework | # except nobody can explain why until looking at the language spec |
| 17:36:40 | gokr1 | Hmm... so people arguing for it will say "its neat, and its optional". But ... heh, if I read someone elses code, and it uses this. Hmmm. Sorry, don't like. |
| 17:37:20 | EXetoC | unless maybe someone is using 0, 1 and 2 spaces in the same expression |
| 17:37:35 | gokr1 | It doesn't really sound like "principle of least surprise". Rather the opposite. |
| 17:37:40 | EXetoC | I don't know why you would allow that, but on one does that really |
| 17:38:05 | Araq0 | ldlework: so? I need to look at the spec for the operator precedence table *now* |
| 17:38:28 | Araq0 | for strong spacs, I don't |
| 17:38:43 | ldlework | Of course you do, they still have precedence in equal spacing |
| 17:38:43 | EXetoC | gokr1: for experienced users or new users? |
| 17:38:46 | gokr1 | Don't want to sound like a whiner... but this was something important we needed? To save typing some parens? |
| 17:39:20 | ldlework | Just one more thing to make sure I don't typo |
| 17:39:27 | ldlework | What an incredibly hard thing to debug |
| 17:39:39 | ldlework | off-by-one-space errors |
| 17:39:44 | ldlework | fun |
| 17:40:14 | * | willwillson joined #nimrod |
| 17:40:15 | EXetoC | they are not rare then? |
| 17:40:48 | ldlework | EXetoC: that's hardly the point, its going to vary from author to author |
| 17:41:06 | ldlework | And even if you don't mean to use them, if they ever become a part of the language, it will just be a prolific thing |
| 17:41:11 | ldlework | even if you intend to use it or not |
| 17:41:24 | ldlework | always use one space, to avoid the feature, except when you accidentally dont |
| 17:42:01 | ldlework | changing call semantics! |
| 17:42:03 | ldlework | crazy |
| 17:43:09 | Araq0 | *shrug* it's just another of Nim's features that's ahead of its time |
| 17:43:16 | Araq0 | perhaps by a decade |
| 17:43:23 | gokr1 | Ehm. |
| 17:43:30 | ldlework | Because humans will be better at tedium then. |
| 17:43:52 | ldlework | And come to learn to love debugging subtle bugs that have nothing to do with their implementation but the language itself. |
| 17:43:55 | gokr1 | If it's about pleasing math people - then go "full retard" and do something like Fortress or something. |
| 17:43:55 | ldlework | I see your point. |
| 17:43:55 | EXetoC | I find it easy to parse. most people don't? |
| 17:44:09 | ldlework | EXetoC: its extremely subtle |
| 17:44:23 | Araq0 | gokr1: it's about pleasing *me*, I like it |
| 17:44:24 | ldlework | And tedious |
| 17:44:54 | EXetoC | but the optionality is the problem, and so people shouldn't use it in production code imo, because then you need to remember if it has been enabled |
| 17:44:58 | gokr1 | I like simplification. I like small languages. I don't like featuritis. |
| 17:45:08 | gokr1 | EXetoC: Agreed. |
| 17:45:15 | ldlework | parenthesis are not even a problem that anyone asked to be fixed |
| 17:45:25 | EXetoC | I would like at least some of these rules to make it into the language if we are to keep the command syntax. otherwise it just gets in the way |
| 17:45:28 | ldlework | I've literally never heard anyone in any context ever complain about parens being used to specify precedence |
| 17:45:40 | gokr1 | If its not optional, then I guess one can learn to be used to it. But being optional... it can come up and BITE whenever it pleases. |
| 17:46:19 | gokr1 | ldlework: People tend to make fun of Smalltalk because you need to write "3 + (4 * 5)" |
| 17:46:28 | EXetoC | just recommend that people use it only for the purpose of testing |
| 17:46:46 | gokr1 | But Smalltalkers appreciate the simple rules of precedence and can live with a paren here and there. |
| 17:46:48 | ldlework | Strong Spaces is totally going to be a thing Nim becomes known for |
| 17:46:59 | Araq0 | as I said, this all fantasy arguments |
| 17:47:05 | Araq0 | try it, report it doesn't work |
| 17:47:14 | ldlework | Araq0: no doubt it does what it says |
| 17:47:45 | gokr1 | Araq0: I don't think the real problem is understood until we have lots of Nim code - and a bit of it uses this here and there. And most of it does not. |
| 17:48:03 | * | ldlework looks at his own Nim code and sees varying usage of space in callsites and arithmatic statements |
| 17:48:25 | ldlework | let me go visually insepct every line of Nim code I ever wrote :) |
| 17:48:35 | Araq0 | gokr1: the question is: how do we get experience with the feature otherwise? |
| 17:49:00 | Araq0 | how do *you* implement experimental features in a programming language? |
| 17:49:03 | gokr1 | Araq0: At the same time, I like "new thinking" and radical shit. I just don't like corner cases, featuritis etc |
| 17:49:32 | ldlework | I'm definitely all for clever new language things that make my life easier, yeah |
| 17:49:49 | Araq0 | making it optional for now and see what's eventually out there is the only way to gain these insights IMO |
| 17:50:47 | gokr1 | Araq0: Well, ok, I can buy that. Where exactly is this enabled btw, if you use it? |
| 17:50:52 | ldlework | Araq0: could you potentially live with a Nim where this feature doesn't make the cut? |
| 17:51:01 | Araq0 | ldlework: yes. |
| 17:51:25 | EXetoC | gokr1: probably only in the module containing the directory |
| 17:51:47 | Araq0 | gokr1: I want koch.nim to use it :-) |
| 17:51:51 | EXetoC | since that's where you define it, rather than with a nim argument |
| 17:52:01 | gokr1 | So its at the top of a module or? |
| 17:52:18 | Araq0 | the #! is only valid as the first line |
| 17:52:48 | ldlework | Forums could use search, but I bet that's hard |
| 17:53:15 | gokr1 | "parser directive"... is that described somewhere? |
| 17:53:17 | willwillson | didn't you see the post where some guy implemented it? |
| 17:53:24 | EXetoC | Araq0: if everyone would want to kill it with fire, would something be done about "echo $foo" still? |
| 17:53:46 | Araq0 | you could even make your editor mark the code with some different background color when it encounters #! strongSpaces, but by then we should consider to remove the feature |
| 17:53:49 | * | vendethiel quit (Ping timeout: 255 seconds) |
| 17:53:54 | willwillson | ldlework: http://forum.nimrod-lang.org/t/622 |
| 17:53:57 | EXetoC | ldlework: the new forum has it. it'll go live soon I think |
| 17:54:08 | ldlework | :D |
| 17:54:10 | EXetoC | there we go |
| 17:54:29 | ldlework | willwillson: I'm just starting to try to use the forum more |
| 17:55:10 | gokr1 | willwillson: I have a hard time remembering to keep track of pull sources of info. Like web forums. |
| 17:55:44 | EXetoC | use rss |
| 17:55:58 | EXetoC | I'll go do that now |
| 17:56:04 | Araq0 | EXetoC: hrm, yeah I guess we can support 'echo $foo' but not 'i+1 * 3' |
| 17:57:00 | * | vendethiel joined #nimrod |
| 17:57:07 | Araq0 | ldlework: btw you're wrong, people do complain about having to use () all the time, I certainly do |
| 17:57:21 | ldlework | You're the first I've seen |
| 17:57:28 | Araq0 | in Delphi you're stuck with if (a = b) and (c = d) then ... |
| 17:57:44 | ldlework | When typing a mathematical expression: A) type parens at the speed of thought B) spend extra minutes sitting there tinkering with space formatting |
| 17:58:20 | Araq0 | except that I enjoy the formating anyway, because () is not really readable either when nested |
| 17:58:31 | ldlework | When reading a mathematical expression: A) interpret parens at the speed of reading B) spend extra minutes parsing visually ambiguous spacing |
| 17:58:32 | gokr1 | It's kinda funny, but I use *less* parens in Smalltalk than other languages (not the other way around) since in Smalltalk I trivially understand the precedence. In most other languages I always "make sure". |
| 17:58:36 | Araq0 | it's exactly the old {} vs indentation argument |
| 17:58:48 | EXetoC | well I don't find it difficult |
| 17:59:16 | Araq0 | it's just that by now many people can accept indentation based syntaxes (many still cannot) |
| 17:59:17 | EXetoC | has this been discussed on the forums? if so, what percentage of people disagreed? |
| 17:59:22 | ldlework | Give some non-trivial examples |
| 17:59:38 | gokr1 | Araq0: Either way, keep up the good work. We can see how it pans out. |
| 17:59:38 | EXetoC | Araq0: very true |
| 18:00:12 | ldlework | (-b + sqrt(b * b - 4 * a * c)) / (2 * a); |
| 18:00:19 | ldlework | This is trivially parsable with the eye |
| 18:00:28 | Araq0 | and it continues to work |
| 18:00:32 | gokr1 | One issue is of course that people tend to have different "styles" when it comes to spacing in these expressions. |
| 18:00:47 | ldlework | Araq0: how does it look with the parens removed? |
| 18:00:56 | gokr1 | Some really like to fluff it up with spaces between every little thing. |
| 18:01:29 | gokr1 | Perhaps we should just go "all the way" and move to "rendered code" :) |
| 18:01:34 | EXetoC | but wouldn't x*y+z be the same as x * y + z? |
| 18:02:17 | gokr1 | Ok, gotta go - I am freezing my hands off (in an ice rink) and time to play badminton :) cya guys |
| 18:02:45 | * | milosn quit (Ping timeout: 272 seconds) |
| 18:03:18 | ldlework | Does anyone want to give the Strong Spaces version of, (-b + sqrt(b * b - 4 * a * c)) / (2 * a); |
| 18:04:02 | Araq0 | ldlework: well it's the same |
| 18:04:10 | Araq0 | but you can write it as: |
| 18:04:26 | Araq0 | -b+sqrt(b * b - 4 * a * c) / 2*a |
| 18:04:49 | * | gokr1 quit (Quit: Leaving.) |
| 18:05:02 | Araq0 | or as -b+sqrt(b*b - 4*a*c) / 2*a |
| 18:05:02 | * | q66 joined #nimrod |
| 18:05:21 | ldlework | Okay let me ask around |
| 18:06:06 | * | kostya_ quit (Remote host closed the connection) |
| 18:06:36 | Araq0 | ldlework: we can even go so far to make it an error when + and * and the spaces disagree: a+b * 3 # invalid |
| 18:06:55 | Araq0 | but I don't think it's necessary |
| 18:07:45 | ldlework | Araq0: wouldn't the whole point be to be able to squish a plus b together to override the precedence of the multiplication? |
| 18:07:59 | EXetoC | hm |
| 18:09:01 | Araq0 | ldlework: yes, but + and * are not my primary concern. I long for the feature for | and & and % |
| 18:09:27 | Araq0 | which means more special casing of course ... |
| 18:11:12 | * | vendethiel quit (Quit: q+) |
| 18:11:18 | * | Demos joined #nimrod |
| 18:11:34 | * | vendethiel joined #nimrod |
| 18:12:00 | Araq0 | "foo $#"&"bar $#" % [a, b] |
| 18:12:28 | Araq0 | vs: "foo " & "bar $#"%[a] |
| 18:14:06 | Araq0 | putting () is babysitting the compiler when it ignores the spacing; then the compiler doesn't look at the code the way I do |
| 18:20:37 | * | milosn joined #nimrod |
| 18:21:13 | ldlework | heh, from the initial impressions in some public places, I don't think I need to worry about whether strong spaces will be popular or not |
| 18:22:15 | Araq0 | lol, as if I don't know |
| 18:23:56 | ekarlso- | hmm not many gh hits for nim vs rust |
| 18:24:57 | EXetoC | it wasn't long ago that the language was renamed |
| 18:25:05 | ekarlso- | rly ? |
| 18:25:12 | * | jhc76 quit (Quit: Leaving) |
| 18:26:03 | Araq0 | ekarlso-: rust is backed by mozilla, Nim has no chance against it. but who cares as long as we can get a community big enough? |
| 18:26:14 | ldlework | In #python-offtopic a guy was raving about Rust (which I also really like too) |
| 18:26:25 | ldlework | And I was like "I've love Rust but I've been writing Nim" |
| 18:26:30 | ldlework | Ohh what's that, he asks |
| 18:26:43 | ldlework | So I show him some simple Nim code implementing a basic state machine |
| 18:26:55 | ldlework | He's like Oh let me try to implement that in Rust |
| 18:27:01 | ldlework | 40 minutes later... |
| 18:27:07 | ldlework | "I think I'll need unsafe for this" |
| 18:27:31 | ldlework | Rust is cool, but it has heavy cognitive costs, imo |
| 18:28:05 | Araq0 | I don't mind the cognitive costs, I mind the language design by fear |
| 18:28:25 | ldlework | I definitely don't want to spend time thinking about how to express my design in the language |
| 18:28:36 | ldlework | I've already spent too much time thinking about that design in the first place |
| 18:28:58 | ldlework | Anytime I waste not inputting solved design in my head, into compilable code in my editor, is time squandered |
| 18:29:42 | Araq0 | you cannot use C++ for decades and then design a language. it doesn't work, you will fear everything. ;-) |
| 18:29:43 | ldlework | Nim is incredibly good at not having odd constructs that stop me and make me think too much about how to use them in the first place |
| 18:29:53 | ldlework | So I hope it keeps up with that |
| 18:30:15 | Araq0 | well the design is pretty frozen, look at the list of upcoming changes |
| 18:30:25 | Araq0 | these are all minor things |
| 18:30:52 | ldlework | Yeah definitely, I'm more just speaking emotionally than remarking on anything specific |
| 18:31:03 | ldlework | I have written more code in the last few weeks than I have in several months |
| 18:35:00 | ekarlso- | just see theres a bigger community in rust but i guess thats much due to moz |
| 18:35:41 | ldlework | ekarlso-: its no surprise |
| 18:37:49 | Araq0 | ekarlso-: yeah but again, afaict Nim will become big enough to sustain an ecosystem. Nobody switches from C# to Java just because Java's ecosystem is bigger. |
| 18:38:13 | Araq0 | you only need to become big enough, you don't have to conquer the world |
| 18:39:50 | Araq0 | Python is also much larger than Ruby but I can find a Ruby library for everything I need. Well that's my impression at least, I don't use Ruby. |
| 18:40:25 | EXetoC | true |
| 18:50:42 | Demos | Yeah, nim does a really good job of getting out of the way, feels a little like C in that reguard |
| 18:51:33 | * | Trustable quit (Remote host closed the connection) |
| 18:51:50 | ekarlso- | i really like to have libs for most stuff |
| 18:54:20 | EXetoC | yeah well |
| 18:58:14 | * | Varriount joined #nimrod |
| 18:59:55 | * | hguux_ quit (Read error: Connection reset by peer) |
| 19:00:13 | Araq0 | ekarlso-: the library situation is not bad and improving |
| 19:01:37 | ldlework | EXetoC: you should write an article on how you performed the libtcod wrapping |
| 19:01:43 | * | superfunc joined #nimrod |
| 19:01:46 | ldlework | as a guide for others who want to write additional wrappers |
| 19:01:55 | ldlework | seems like it was a good usecase, multiple files, etc |
| 19:01:57 | * | hguux_ joined #nimrod |
| 19:02:09 | EXetoC | at least most of the people who are making things publically available seem to be writing libs |
| 19:03:09 | Varriount | Araq: Which is better: "type Bar = object of ref Foo" or "type Bar = ref object of Foo"? |
| 19:03:12 | EXetoC | ldlework: what about that c2nim article? |
| 19:03:28 | ldlework | EXetoC: its good but doesn't really fill in all the details |
| 19:03:56 | ldlework | EXetoC: mentioning the transformations you had to make to the source and so on would provide a lot more insight than just 'hey there's a thing called c2nim' and some mere mentions that transformations were made |
| 19:04:06 | ldlework | Its a good very high-level article |
| 19:07:12 | Araq0 | Varriount: well these don't do the same |
| 19:07:28 | Araq0 | your first Bar is an object, your second a 'ref object' |
| 19:07:46 | ldlework | Araq0: where is the best explanation of all those things you can put after = |
| 19:07:51 | Araq0 | inheritance is only allowed for 'ref object' because the underlying object type might be anonymous |
| 19:08:08 | Araq0 | thanks to the Foo = ref object notation |
| 19:09:00 | Araq0 | ldlework: I don't know what kind of advice you seek |
| 19:09:28 | ldlework | Araq0: like, object, ref object, ref T, object of T, and so on |
| 19:09:37 | Araq0 | there is not much when it comes to types, it either creates an alias or a new type |
| 19:09:54 | Araq0 | 'ref object', 'object', 'distinct' and 'enum' create new types |
| 19:10:04 | Araq0 | all other introduce type aliases |
| 19:11:02 | Araq0 | when you use 'of' you enable inheritance, otherwise 'object' is really just a C struct |
| 19:11:27 | Araq0 | there are a couple of pragmas that influence it too, but the .pure, final stuff is mostly obsolete |
| 19:11:45 | Araq0 | (we're quite bad at updating old code) |
| 19:13:17 | Araq0 | there is lots of code out there that uses .inheritable when it really should not |
| 19:13:29 | Araq0 | it should use 'of RootObj' instead |
| 19:13:44 | EXetoC | oh, it was renamed |
| 19:13:56 | EXetoC | nm |
| 19:14:25 | Araq0 | unless you are me and know what you're doing and you really need .inheritable without 'of RootObj' :P |
| 19:15:31 | EXetoC | I always forget to add byCopy to C types |
| 19:16:56 | ldlework | I wish sometimes that Nim would implicitly cast between int types for me |
| 19:17:04 | ldlework | Specially when working with C api's |
| 19:18:23 | EXetoC | implicit casting is only allowed when there's no chance of information loss |
| 19:18:43 | ldlework | yeah :( |
| 19:21:01 | Araq0 | EXetoC: byCopy is rarely necessary though. most C APIs pass pointers to structs and these are safe either way |
| 19:21:23 | Araq0 | but I guess c2nim should add it anyway |
| 19:21:48 | ldlework | What's the difference between int and cint? |
| 19:21:59 | EXetoC | the type is often opaque when that's the case |
| 19:22:31 | Araq0 | ldlework: I can feel your pain but a special .lenient pragma would be yet another thing people will complain about |
| 19:22:54 | ldlework | Araq0: maybe if it were restricted to just the wrapper modules? |
| 19:23:03 | Varriount | ldlework: In nim, sizeof(Int) == sizeof(Pointer), |
| 19:23:11 | ldlework | Araq0: so when you generate a binding, it exposes normal ints on the Nim side and converts them to cint on the C side or something |
| 19:23:14 | Araq0 | "what do you mean? that is 2 languages in one!" |
| 19:23:20 | EXetoC | documented in the system module |
| 19:23:31 | Araq0 | "I can imagine that it is a bad idea and error prone" |
| 19:23:50 | Araq0 | "There should be only one way to do things" |
| 19:24:36 | Araq0 | essentially the arguments that I got for 'strongSpaces' :P |
| 19:24:49 | ldlework | Araq0: I think I'm more thinking like something you can do in the dynlib definitions to say, "hey expose this as an int but convert to and from cint" |
| 19:24:52 | Varriount | Araq0: I like strongspaces |
| 19:25:35 | ldlework | Varriount: as in the legitimately speed up your rendering and visual perception of nested expressions? |
| 19:25:38 | EXetoC | ldlework: isn't this a case of just saving a couple of characters though? which we discussed before |
| 19:25:51 | ldlework | EXetoC: over the entire program though |
| 19:26:09 | ldlework | I have .cint's everywhere |
| 19:26:11 | Varriount | ldlework: Yep. And they make custom operators more pragmatic. |
| 19:26:20 | Araq0 | ldlework: what we can do however |
| 19:26:29 | Araq0 | is introduce a module with converters |
| 19:26:37 | Araq0 | so you can do: import lenient |
| 19:26:49 | Araq0 | and then int will be converted to cint |
| 19:27:05 | Araq0 | so thankfully no language feature is required, in fact |
| 19:27:07 | Araq0 | but |
| 19:27:28 | Araq0 | people don't care because the "stdlib IS THE LANGUAGE" |
| 19:28:12 | Varriount | I don't think that... |
| 19:28:13 | ldlework | Araq0: can you make strongspaces a module thing too? |
| 19:28:17 | ldlework | :) |
| 19:28:21 | Araq0 | ldlework: he he he, no. |
| 19:29:10 | EXetoC | so some people have lousy opinions. who would have thought :p |
| 19:37:07 | Araq0 | ldlework: we could introduce lisp like reader macros and perhaps than strongSpaces can be implemented as a library |
| 19:37:18 | Araq0 | but Lisp like reader macros are evil |
| 19:42:34 | Varriount | Araq: Couldn't template filters be used to make reader macros? |
| 19:45:08 | Varriount | Araq: Also, what are your thoughts on multiple inheritance? |
| 19:45:21 | Araq0 | Varriount: i like it, but it's hard to implement |
| 19:46:23 | Araq0 | the arguments I heard against it all apply to some extend to single inheritance |
| 19:46:48 | ldlework | multiple-inheritance with explicit resolution is not bad |
| 19:46:51 | Araq0 | and interfaces+SI is worse than MI for the simple reason that it makes people choose where no choice is necessary |
| 19:47:06 | ldlework | Basically Stateful Traits |
| 19:47:16 | Araq0 | ldlework: yep |
| 19:47:17 | ldlework | or Explicit Mixins |
| 19:47:45 | Araq0 | last time I checked MI is also more efficient than Java-like interfaces + SI |
| 19:47:45 | ldlework | Araq0: its too bad you didn't start this project 10 years ago |
| 19:47:54 | ldlework | I could have written a lot more software by now :) |
| 19:49:13 | Araq0 | I don't like inheritance at all really, but if you're into it, you might as well use MI, I don't see the problem |
| 19:49:58 | Varriount | Araq: Pluggable objects? |
| 19:50:11 | Araq0 | but as I said, it's hard to implement and we have enough work to do |
| 19:54:07 | * | brson joined #nimrod |
| 19:55:51 | wan | Talking about lenient (might be related), when I want to do `var a: tuple[x, y: float32] = (1.0'f32, 1.5'f32)` and NOT have the 'f32 suffixes (these become really cumbersome when defining matrices etc), would it allow it or is there some better way to achieve it? |
| 19:58:11 | Araq0 | wan: well I don't know. you can already omit the tuple definition |
| 19:59:20 | wan | Well that was a short example, I am actually using vectors and matrix types already defined |
| 19:59:46 | wan | And for OpenGL you need float32 |
| 19:59:51 | Varriount | Hm.. Technically, you can already implement MI via value types and pointer casting |
| 20:00:12 | Varriount | Although you can't do virtual inheritance |
| 20:01:05 | Araq0 | wan: your best option is a macro |
| 20:01:38 | wan | Hmm, okay, I'll do that then. Thanks |
| 20:01:40 | Araq0 | toF(1, 2, 3) --> (1.0'f32, 2.0'f32, 3.0'f32) |
| 20:01:58 | Araq0 | in fact |
| 20:02:04 | Araq0 | you should go crazy: |
| 20:02:14 | Araq0 | toF"1 2 3; 2 3 4" # matrix |
| 20:02:23 | Araq0 | toF"1 2 4.0 2" # vector |
| 20:02:28 | wan | Ha, interesting |
| 20:03:19 | Araq0 | and submit it to the opengl wrapper |
| 20:03:21 | * | Boggart joined #nimrod |
| 20:03:22 | wan | losing the `,` in matrix initialization might make it more readable |
| 20:03:30 | wan | macro it is |
| 20:04:10 | wan | it might however be beneficial outside of opengl too |
| 20:04:26 | Araq0 | yeah, it should be put in its own module for sure |
| 20:06:26 | Araq0 | hi Boggart welcome |
| 20:07:02 | Boggart | Hello |
| 20:07:03 | wan | Araq0: I want to use parseExpr in the macro body, right? |
| 20:07:08 | Boggart | I'm having trouble getting c2nim to work on this file, errors are at the bottom. I'd appreciate any help: http://pastebin.com/ESxagsPb |
| 20:07:52 | Boggart | It complains of a missing bracket, when the bracket is further along in the line, same with the missing ; error |
| 20:08:34 | Araq0 | wan: do you? I usually don't |
| 20:08:53 | Araq0 | but hrm |
| 20:08:58 | Araq0 | yeah, it makes sense here |
| 20:09:17 | wan | oh right, "1 1.1 2" is not a valid nim expression, it won't give me the thing I want |
| 20:09:24 | wan | or would it? |
| 20:10:07 | Araq0 | no, but it's a 'split' away |
| 20:10:27 | Araq0 | Boggart: #def WINAPI and read c2nim's docs please |
| 20:11:16 | Araq0 | c2nim is stupid, but helps with the grunt work once you learned its pecularities |
| 20:14:55 | * | Mat4 joined #nimrod |
| 20:14:59 | Mat4 | hi all |
| 20:15:04 | Araq0 | servus |
| 20:15:14 | Mat4 | hi Araq |
| 20:18:55 | Araq0 | Mat4: you promised us a C compiler iirc |
| 20:19:07 | ldlework | lol |
| 20:20:41 | Boggart | Thanks Araq0 |
| 20:23:53 | Mat4 | Araq0: I'm working on it (the prefered 8cc is quite buggy so I abandoned a port, working now porting TCC which I've found more stable) |
| 20:24:42 | Araq0 | Mat4: remember that it only needs to be able to parse what Nim emits really and we can tweak that output |
| 20:25:12 | Araq0 | though .emit will suffer a bit then |
| 20:25:47 | dts|pokeball | so is nim ever going to be a compiler that actually generates an exe or is the plan to usually have it compile to c*? |
| 20:28:37 | Araq0 | dts|pokeball: native codegen will come eventually, but not before 2.0 |
| 20:28:50 | ldlework | Are there any examples of the graphics module laying around? |
| 20:28:52 | dts|pokeball | 1.0 just came out right? |
| 20:28:58 | Araq0 | nope |
| 20:29:05 | dts|pokeball | oops |
| 20:29:24 | EXetoC | ldlework: yes, in the module itself |
| 20:29:29 | ldlework | orly |
| 20:29:31 | ldlework | btw |
| 20:29:38 | ldlework | the docs should link to the source |
| 20:30:03 | Araq0 | ldlework: we had that feature but it broke and gradha isn't here to fix it |
| 20:30:26 | ldlework | EXetoC: oh cool thanks I found it |
| 20:30:30 | Araq0 | had to disable it for 0.9.6, really annoying |
| 20:31:08 | Mat4 | dts|pokeball: The plan is to port a C compiler to Nim so the language does not depend on it any more |
| 20:31:26 | dts|pokeball | :D |
| 20:31:26 | dts|pokeball | which c compiler? |
| 20:31:46 | Mat4 | as written, I'm working on a port of TCC |
| 20:32:07 | dts|pokeball | is there a public repo for it? because i would love to help with that |
| 20:32:47 | Mat4 | that would be great :) http://bellard.org/tcc/ |
| 20:33:49 | dts|pokeball | in this version, are you porting the source of the compiler to nim, or just the input accepted? |
| 20:34:29 | ldlework | The inability to figure out where names come from because of the import system is truly the most annoying thing |
| 20:34:32 | Araq0 | bbl |
| 20:34:35 | * | Araq0 quit (Quit: Page closed) |
| 20:35:18 | Mat4 | I have written a backend and IL representation already before (that's the part the author does not finished). Now I'm porting the source to Nim |
| 20:35:35 | dts|pokeball | nice |
| 20:37:23 | ldlework | EXetoC: hmm, I have libsdl-ttf2.0-0 installed but I get could not load: libSDL_ttf.so(|.1|.0) |
| 20:38:46 | Mat4 | dts|pokeball; Wait until I'm upload my work on friday, then just pick up one of the C sources left (and please inform me on which file you work so we do not duplicate efforts) |
| 20:39:08 | * | flaviu joined #nimrod |
| 20:39:44 | dts|pokeball | ok |
| 20:39:47 | Mat4 | it is not much work, I have only not much spare? time for it |
| 20:40:00 | Mat4 | so thanks |
| 20:41:36 | dts|pokeball | i love compiler development, so this is like christmas for me |
| 20:41:58 | dts|pokeball | nim still uses TFile right? not File? |
| 20:42:49 | ldlework | I'm so confused |
| 20:45:25 | EXetoC | ldlework: so you have SDL 1 and not SDL 2? |
| 20:45:56 | ldlework | EXetoC: I have SDL 2 fairly sure |
| 20:46:17 | EXetoC | I meant the other way around |
| 20:46:31 | ldlework | I have SDL 2 yeah |
| 20:48:06 | ldlework | I have both apparently |
| 20:48:29 | ldlework | It seems to link to SDL fine |
| 20:48:34 | ldlework | it fails when linking to ttf |
| 20:48:41 | ldlework | EXetoC: ^ |
| 20:49:05 | EXetoC | SDL_ttf then |
| 20:49:37 | ldlework | EXetoC: there is no such thi |
| 20:50:01 | ldlework | The only thing that exists on the internet as far as I can see is a thing called "SDL_ttf 2.0" |
| 20:50:10 | ldlework | ubuntu has no non-2 ttf package |
| 20:50:20 | ldlework | and the ttf project's website doesn't offer a non-2 package or source |
| 20:51:02 | EXetoC | http://www.libsdl.org/projects/SDL_ttf/release/ |
| 20:52:14 | ldlework | EXetoC: so I'm supposed to install 1.2? |
| 20:52:41 | EXetoC | didn't you say there was an ubuntu package for SDL_ttf 1 too? |
| 20:52:57 | dts|pokeball | so i realized what python reminds me of. fortran and python mixed together |
| 20:53:15 | dts|pokeball | so i realized what nim** reminds me of. fortran and python mixed together |
| 20:53:27 | ldlework | EXetoC: libsdl-ttf2.0-0 - TrueType Font library for Simple DirectMedia Layer 1.2, libraries |
| 20:53:30 | ldlework | is the only library in my repos |
| 20:54:35 | * | Trustable joined #nimrod |
| 20:55:11 | EXetoC | the so file must have another name then |
| 20:56:15 | ldlework | I also have libfreetype6 and libfreetype6-dev installed and I ttf 1.2 wont compile |
| 20:56:34 | ldlework | *** Unable to find FreeType library (http://www.freetype.org/) |
| 20:56:42 | ldlework | Its definitely installed :( |
| 20:57:04 | dom96 | ldlework: maybe the filename in the wrapper is wrong? |
| 20:57:31 | EXetoC | libSDL_ttf.so(|.1|.0) |
| 20:58:00 | EXetoC | check the file list for the package |
| 20:58:06 | EXetoC | you could just create a symlink |
| 20:58:23 | ldlework | I did create a symlink |
| 20:58:27 | ldlework | you know it does say "Couldn't load" |
| 20:58:30 | ldlework | rather than "couldn't find" |
| 20:59:08 | EXetoC | oh yes, those helpful error messages |
| 20:59:20 | ldlework | https://gist.github.com/dustinlacewell/a61f67b2c189ec228f9f |
| 20:59:27 | ldlework | are my ttf symlinks, etc |
| 20:59:57 | ldlework | woah |
| 21:00:07 | ldlework | modifying sdl_ttf.nim to point directly at the symlink target made it work |
| 21:00:09 | ldlework | dafuq |
| 21:00:11 | * | tinAndi joined #nimrod |
| 21:00:44 | ldlework | does it not work against symlinks? |
| 21:00:58 | EXetoC | but now it's pointing to the lib for SDL 2, I think |
| 21:01:22 | EXetoC | I don't know if it matters |
| 21:02:26 | ldlework | EXetoC: if I hard code sdl_ttf.nim to use libSDL2_ttf-2.0.so.0.10.2 |
| 21:02:27 | ldlework | it works |
| 21:02:38 | ldlework | if I hardcode sdl_ttf.nim to use a symlink pointing at that, it fails |
| 21:04:11 | EXetoC | create a hard copy then |
| 21:05:33 | ldlework | doesn't work |
| 21:05:44 | Araq | ldlework: you can also use --dynlibOverride:SDL_ttf and link against SDL_tff.a |
| 21:05:57 | Araq | or libSDL_tff.a or whatever it's called |
| 21:06:04 | EXetoC | how can it not? |
| 21:06:37 | EXetoC | don't make a hard copy of the symlink |
| 21:06:45 | ldlework | EXetoC: I didn't |
| 21:06:49 | EXetoC | :o |
| 21:07:02 | EXetoC | I don't think you should have to run ldconfig in this case |
| 21:07:08 | EXetoC | but try to run it as root |
| 21:07:22 | EXetoC | and try again |
| 21:08:12 | Araq | the SDF_ttf dependency really sucks, I remember I wasn't able to find the DLL either |
| 21:08:25 | Araq | and 2.0 is not compatible, as usual |
| 21:10:22 | ldlework | EXetoC: https://gist.github.com/dustinlacewell/0075e75f66e53c19dc20 |
| 21:10:44 | ldlework | If I update sdl_ttf.nim to point directly at libSDL2_ttf-2.0.so.0.10.2 everything works fine |
| 21:11:00 | ldlework | I agree that this makes no sense, but that is the actual shell transcript |
| 21:11:39 | Araq | maybe 2.0 is compatible enough? |
| 21:12:39 | ldlework | They are the same file |
| 21:12:56 | ldlework | I hardlinked libSDL_ttf.so to libSDL2_ttf-2.0.so.0.10.2 |
| 21:13:06 | ldlework | But the binary only executes when I'm linked directly to libSDL2_ttf-2.0.so.0.10.2 |
| 21:13:09 | Mat4 | Araq: Probably you will find similar problems with Allegro |
| 21:13:55 | Araq | Mat4: well we simply need to port to 2.0 properly, I hope |
| 21:14:04 | Araq | and then it will be stable for another decade |
| 21:14:14 | * | Araq really likes that SDL moves slowly |
| 21:14:25 | * | ldlework forks Nim for now. |
| 21:14:50 | Araq | ldlework: why? you can add a pattern instead with | |
| 21:15:01 | ldlework | Araq: for my specific lib version? |
| 21:15:07 | Araq | yeah |
| 21:15:10 | ldlework | Doubt we want that ... |
| 21:15:14 | Araq | you're on ubu, right? |
| 21:15:49 | ldlework | yeah |
| 21:16:12 | ldlework | Is there a way to query ld for where it is getting a library from? |
| 21:16:31 | ldlework | Maybe I have a libSDL_ttf.so somewhere in an earlier path so the hardlink isn't found |
| 21:16:35 | ldlework | I'll name it something unique |
| 21:17:06 | ldlework | could not load "wtf.so" |
| 21:17:18 | ldlework | why the fuck not, its a hard-link to the thing you just linked to fine |
| 21:17:26 | * | willwillson left #nimrod (#nimrod) |
| 21:17:35 | Araq | as I said, you can use --dynlibOverride and take the C route |
| 21:17:46 | * | willwillson joined #nimrod |
| 21:18:04 | Araq | of building against "shared" libraries |
| 21:19:06 | * | AMorpork is now known as AFKMorpork |
| 21:20:08 | ldlework | That just makes the linker fail to find implementations of TTF's functions |
| 21:20:53 | flaviu | Araq: Can you comment on https://github.com/Araq/Nimrod/issues/782 ? |
| 21:21:25 | flaviu | Particularly the stuff at the bottom, feel free to ignore the patch for now. |
| 21:24:58 | * | quasinoxen joined #nimrod |
| 21:25:01 | Araq | dom96 needs to review the patch |
| 21:25:11 | Araq | I know nothing about these things |
| 21:25:22 | Araq | looks fine to me though |
| 21:25:36 | ldlework | Araq: using that string | syntax how can I specify that part of the string is optional? |
| 21:25:38 | ldlework | (foo|) |
| 21:25:40 | ldlework | ? |
| 21:25:46 | Araq | yes |
| 21:25:52 | ldlework | ha that worked |
| 21:25:53 | * | milosn quit (Ping timeout: 252 seconds) |
| 21:25:56 | ldlework | okay I'll submit a patch to fix this |
| 21:26:07 | Araq | great |
| 21:26:16 | Araq | flaviu: I commented |
| 21:26:35 | dom96 | Araq: flaviu: that looks really annoying. |
| 21:26:40 | dom96 | Is the cacert really necessary? |
| 21:26:48 | dom96 | doesn't the OS have it somewhere? |
| 21:26:49 | flaviu | dom96: Yes. |
| 21:27:00 | flaviu | No to the last question on linux |
| 21:27:29 | flaviu | Yes on windows, but as everyone knows, the windows apis are really excellent /s |
| 21:29:07 | flaviu | No on mac it looks like |
| 21:30:13 | * | gokr_ joined #nimrod |
| 21:30:17 | Araq | flaviu: can't tell if you're serious |
| 21:30:39 | Araq | I can't possibly have convinced you |
| 21:30:49 | flaviu | wrt the windows api comment? no, I'm not serious |
| 21:31:32 | flaviu | I saw uppercase types and hungarian notation and I was instantly convinced to run away. |
| 21:32:11 | * | gokr quit (Ping timeout: 244 seconds) |
| 21:33:26 | Araq | good. |
| 21:34:28 | Araq | as a programmer you shouldn't care about documentation or stability when you instead can focus on superficial ugliness |
| 21:34:49 | * | gour quit (Quit: Konversation terminated!) |
| 21:35:09 | ldlework | At least we agree |
| 21:35:12 | EXetoC | flaviu: so, systems hungarian? |
| 21:35:29 | flaviu | Araq: Exactly! |
| 21:35:29 | flaviu | Seriously though, the windows APIs aren't the best documented either. |
| 21:36:00 | Araq | it works so much better than posix it's not even funny, but feel to disagree |
| 21:36:38 | ldlework | https://github.com/Araq/Nimrod/pull/1702 |
| 21:37:21 | ldlework | Yeah I love userland api's that let me patch arbitrary memory |
| 21:37:24 | ldlework | Window's is good for that |
| 21:37:28 | flaviu | I don't want to start a flame war, so I don't disagree. |
| 21:37:39 | flaviu | *won't |
| 21:38:02 | Araq | ldlework: stuck with windows 95? |
| 21:38:17 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 21:38:32 | ldlework | Araq: this was true until vista |
| 21:39:05 | ldlework | I spent around 3 years in black-hat reverse enginering circles and I learned just how bad the WinAPI is from that perspective |
| 21:39:22 | ldlework | In terms of writing applications, its not bad, if a bit verbose but linux is the same way, really |
| 21:39:40 | Araq | *shrug* it's not that any OS written in fucking C is secure anyway |
| 21:39:51 | ldlework | Araq: agreed |
| 21:40:59 | Mat4 | Araq: the Windows API is certainly better structured, but it is much more extensive than POSIX |
| 21:42:32 | Araq | it's not good, it's horrible. it's just that Posix is worse. |
| 21:43:01 | Araq | and objectively maintaining Nim for Posix is more work than the windows specific parts |
| 21:43:30 | Araq | oh so execvpe doesn't run with ulibC |
| 21:43:51 | Araq | etc. |
| 21:45:55 | * | Jesin quit (Quit: Leaving) |
| 21:46:38 | * | saml quit (Quit: Leaving) |
| 21:47:01 | Mat4 | it's the same problem as with ANSI C (and it's standard libraries in all of there inconsistencies) |
| 21:47:40 | * | saml joined #nimrod |
| 21:48:45 | Araq | flaviu: http://www.reddit.com/r/linux/comments/2o1r3w/the_impact_of_the_linux_philosophy/cmj6ulc |
| 21:49:42 | * | Jesin joined #nimrod |
| 21:49:55 | flaviu | Araq: I really don't want to get involved in this flame war yet again |
| 21:50:06 | * | milosn joined #nimrod |
| 21:50:11 | Araq | no my neither |
| 21:50:12 | Araq | *me |
| 21:50:16 | Araq | hence the link |
| 21:50:23 | Araq | they discussed it out for us ;-) |
| 21:50:53 | * | enquora joined #nimrod |
| 21:51:50 | ldlework | I agree with this guy, |
| 21:51:52 | ldlework | The problem with dbus is that it's way too complicated and hidden to be useful to write against for everyday tasks, and so it completely ruins the competent/empowered users scheme that *nix used to have. There are professionals who can deal with dbus, and everyone else, as opposed to "you automate your environment by pasting the way you would do it by hand into a file, and sprinkling variables and control |
| 21:51:54 | ldlework | structures around it." |
| 21:51:56 | ldlework | You're learning and using a heavyweight application library (or fucking dbus-send+qdbus) and/or picking up an obscene amount of domain knowledge and writing more boilerplate than your actual program logic to talk to things via dbus because even the documentation[1] says the API is too hideous to use directly. |
| 21:52:29 | Araq | I find it remarkable that this comes from *reddit/linux* |
| 21:53:32 | flaviu | Anyway, all this is really off topic |
| 21:53:51 | Araq | outch, yeah |
| 21:54:42 | * | gokr joined #nimrod |
| 21:55:46 | Demos | ldlework, that paragraph could describe COM as well... |
| 21:56:12 | ldlework | Demos: COM is in no way taking what we already do by hand, droping a few variables and control structures and going on with life |
| 21:56:23 | ldlework | not by a long shot, in any context or universe |
| 21:56:39 | Demos | that was not my point |
| 21:56:48 | flaviu | Demos, ldlework: It's off-topic, it'd be better if we avoided controversial issues like this. |
| 21:57:03 | Demos | COM is learning a huge library to do fairly simple things |
| 21:57:08 | Demos | anyway, programming is hard |
| 21:57:15 | ldlework | Demos: oh well, then sure I agree with you there :) |
| 21:57:28 | ldlework | Demos: the paragraph was a dig on dbus as linux adopting the microsoft model |
| 21:58:03 | Demos | piping around text never seems to work that great except in really simple examples |
| 21:58:11 | Araq | flaviu is right, we have #nimrod-offtopic |
| 21:58:12 | Mat4 | hmm, I think it's more DDL oriented ;) |
| 21:58:13 | Demos | like piping things into grep is nice |
| 21:59:47 | * | dts|pokeball quit (Ping timeout: 258 seconds) |
| 22:02:47 | Demos | what is DDL? |
| 22:02:47 | dom96 | flaviu: it's in /etc/pki/tls/certs/ca-bundle.crt on Linux from what I can see. |
| 22:02:55 | dom96 | I'm sure Mac OS X has something similar. |
| 22:03:08 | dom96 | Please figure out where to get it on Windows too. |
| 22:03:35 | flaviu | dom96: Odd, but I don't have a /etc/pki/tls/certs on my system :) |
| 22:03:51 | flaviu | Windows uses the wincrypto api or something |
| 22:04:11 | dom96 | What about /usr/share/ssl/certs/ca-bundle.crt ? |
| 22:04:19 | flaviu | nope |
| 22:04:58 | flaviu | /usr/share/apps/kssl/ca-bundle.crt, /usr/share/ncat/ca-bundle.crt |
| 22:04:59 | Mat4 | Demos: One predecessor of the COM Interface (I think it was introduced with Windows 1) |
| 22:05:22 | ldlework | How do I actually write something of the form, graphics.[]=(sur: PSurface, x: int, y: int, col: Color) |
| 22:05:34 | ldlework | s[x, y] = col |
| 22:05:36 | ldlework | ? |
| 22:06:01 | dom96 | flaviu: Looks like it's distro dependent :( |
| 22:06:45 | flaviu | yep |
| 22:07:19 | ldlework | If so, it doesn't seem to work |
| 22:07:25 | Mat4 | Demos: also known as DDI (if I remembered correctly) |
| 22:07:30 | ldlework | oh |
| 22:08:40 | dom96 | flaviu: argh. SSL sure is annoying. |
| 22:09:09 | ldlework | EXetoC: with the graphics module I am trying to do, surf.s.pixels[0, 0] = colBlack |
| 22:09:34 | ldlework | oh |
| 22:09:40 | ldlework | just access the surface like a sequence |
| 22:11:41 | Araq | s[x,y] = col should work, ldlework |
| 22:11:46 | ldlework | Araq: yeah |
| 22:11:57 | ldlework | who else thinks we need "for i in 50" |
| 22:12:21 | flaviu | ldlework: What's that supposed to mean? |
| 22:12:30 | ldlework | "for i in 0..49" |
| 22:12:30 | willwillson | for i in 0..50: ? |
| 22:12:33 | ldlework | just like the array syntax |
| 22:12:48 | willwillson | can't you already do that? |
| 22:12:55 | flaviu | meh, too implicit for me. 0..49 isn't that bad |
| 22:12:59 | Araq | I think you can do: iterator `<` (x: int): int = ... |
| 22:13:05 | Araq | for i in <50: |
| 22:13:07 | ldlework | flaviu: more implicit than [50, int] ? |
| 22:13:09 | ldlework | why? |
| 22:13:38 | Araq | ldlework: try my suggestion please |
| 22:13:41 | flaviu | ldlework: Because people expect arrays to work like that. C does it that way. |
| 22:13:49 | ldlework | Araq: now I have to include that in every Nim progject |
| 22:13:54 | tinAndi | Mat4: DDE with windows 2 then OLE with windows 3 and COM and COM+ after this |
| 22:14:07 | Araq | ldlework: no. first you have to try it |
| 22:14:16 | willwillson | flaviu: what do you think about the last answer on: http://stackoverflow.com/questions/10095676/openssl-reasonable-default-for-trusted-ca-certificates for windows/ mac? |
| 22:14:38 | ldlework | Araq: "for i in <50" doesn't work |
| 22:14:41 | Mat4 | tinAndi: thanks |
| 22:14:50 | Araq | dom96, flaviu I think we should ship that certificate stuff on our own |
| 22:15:04 | Araq | ldlework: well you have to defined this iterator first |
| 22:15:12 | willwillson | also here are some default locations on linux: http://mercurial.selenic.com/wiki/CACertificates |
| 22:15:14 | dom96 | Araq: I disagree. |
| 22:15:22 | flaviu | willwillson: `etc/ssl/certs/ca-certificates.crt` doesn't exist on my system, and I bet I have the most modern version of linux here. |
| 22:15:26 | ldlework | Araq: that's exactly what I mean by having to include it - even if it works, I'll just end up using 0..n-1 |
| 22:15:38 | willwillson | flaviu: what are you using? |
| 22:16:06 | flaviu | willwillson: actually sorry. It does show up, I was just using the wrong query |
| 22:16:37 | flaviu | Well, I agree with dom96 and you now. Better to use the system's certs. |
| 22:16:46 | dom96 | Good. |
| 22:17:02 | flaviu | It's better for those using corporate proxies and such too |
| 22:17:18 | dom96 | Add a function called "findCertDir" |
| 22:17:22 | dom96 | and set it as the default cert path |
| 22:17:40 | dom96 | *findCertFile |
| 22:17:44 | flaviu | dom96: it doesn't work that way. You have to use weird APIs on both mac and windows. |
| 22:17:52 | Araq | ldlework: well guess what. we might include it. |
| 22:17:53 | dom96 | So use them. |
| 22:18:25 | * | superfunc quit (Ping timeout: 255 seconds) |
| 22:18:49 | Araq | well findCertFile surely should check the distro then |
| 22:19:03 | dom96 | nah |
| 22:19:05 | Araq | just document which distros are supported |
| 22:19:08 | dom96 | Just go through alist |
| 22:19:14 | dom96 | *a list |
| 22:19:15 | Araq | oh yeah |
| 22:19:22 | Araq | that's better lol |
| 22:19:23 | dom96 | Distro detection isn't trivial. |
| 22:19:32 | Araq | uname -a ? |
| 22:20:12 | dom96 | That tells you nothing about the distro. |
| 22:20:19 | flaviu | dom96: yes it does |
| 22:20:28 | flaviu | but why do we need to detect distros? |
| 22:20:47 | dom96 | No it doesn't. |
| 22:21:01 | dom96 | I don't see any mention of Ubuntu on my laptop. |
| 22:21:01 | flaviu | "3.17.4-1-ARCH" |
| 22:21:08 | dom96 | That's your kernel name. |
| 22:21:23 | dom96 | What if you compile it yourself? |
| 22:21:29 | dom96 | It won't say "ARCH" then |
| 22:21:29 | Araq | just make sure it works on ubuntu, people using other distros are used to the fact that nothing works anyway *cough* |
| 22:21:49 | tinAndi | :) |
| 22:22:08 | flaviu | dom96: actually, yes it will, but the distro isn't important anyway |
| 22:23:04 | Araq | dom96 is right though, just try random directories and remember that the axiom of choice is not be questioned |
| 22:23:23 | dom96 | flaviu: I guess it depends what you compile it on. |
| 22:23:29 | dom96 | I have a 'generic' kernel. |
| 22:24:26 | willwillson | mine says: "3.17.1-1-custom-will" ;D |
| 22:25:09 | Araq | willwillson: I don't think so, Tim. |
| 22:25:20 | flaviu | Anyway, the distro doesn't really matter. |
| 22:30:13 | ldlework | Araq: nice |
| 22:30:15 | Mat4 | by the way: Have someone tried compiling Nim with one of the BSD's ? |
| 22:30:30 | Mat4 | sorry, for one of the BSD's |
| 22:30:42 | Araq | ldlework: hum? |
| 22:31:49 | ldlework | Araq: home improvement reference |
| 22:32:13 | dom96 | Mat4: It worked when I tried it, but that was a long time ago. |
| 22:32:14 | Araq | ah, I was unsure how it's in english |
| 22:32:14 | flaviu | Mat4: Yes. Nim is in openbsd's ports repo |
| 22:33:05 | ldlework | Araq: you watch Home Improvement in a different language?! |
| 22:33:13 | Mat4 | nice |
| 22:33:37 | Araq | ldlework: lol, sure |
| 22:34:01 | ldlework | Araq: what is "I don't think so, Tim" in the language you watch it in? |
| 22:34:24 | Araq | "Das glaube ich nicht, Tim" |
| 22:38:08 | Araq | I didn't even know it's "Home improvement" in english, lol |
| 22:38:19 | Araq | I always thought it's "tool time" |
| 22:38:55 | ldlework | lol |
| 22:39:04 | ldlework | Tool Time is the name of his TV show on the show |
| 22:39:09 | Araq | yeah I know |
| 22:39:29 | Araq | willwillson: got your nick from this show? |
| 22:39:55 | willwillson | Araq: nah, that must be why I didn't get the reference |
| 22:40:24 | Araq | ah sorry. at least ldlework got it. |
| 22:41:10 | willwillson | is it a good show? |
| 22:42:02 | * | Mat4 left #nimrod (#nimrod) |
| 22:42:39 | Araq | I think so, yeah |
| 22:43:33 | Araq | but I have a weakness for crap on TV, so ask somebody else :P |
| 22:44:16 | willwillson | might have to find out who this willwillson character is now :D |
| 22:45:11 | Araq | it's the neighbor whose mouth you never ever can see |
| 22:45:21 | Araq | and who always knows everything |
| 22:45:31 | Araq | like flaviu |
| 22:45:43 | Araq | (no offense!) |
| 22:45:56 | flaviu | :/ |
| 22:45:58 | * | tinAndi quit (Quit: ChatZilla 0.9.91 [Firefox 34.0/20141125180439]) |
| 22:46:24 | Demos | I tried getting nim working on openBSD and it did not work, must have been added to ports later |
| 22:46:30 | Araq | flaviu: no, I'm serious. I happen to know your age. you're a genius. |
| 22:46:30 | Demos | I know there is a FreeBSD port though |
| 22:47:02 | flaviu | Demos: Probably, I've never been able to keep then straight |
| 22:48:00 | Demos | there are a lot of people working on nim that I suspect will show up in 15 years making 10x more than I will be ... |
| 22:48:27 | Araq | I remember pulling some PRs for BSD |
| 22:48:32 | Araq | so it *should* work |
| 22:48:40 | Araq | Demos: what's your problem? |
| 22:48:58 | Demos | my problem is I tried it like a year ago |
| 22:49:05 | Demos | I may have written some of those PRs |
| 22:49:20 | Araq | nah that was kazmodan |
| 22:49:46 | * | BlaXpirit-UA quit (Quit: Quit Konversation) |
| 22:50:01 | Araq | or perhaps kokozedman |
| 22:50:09 | flaviu | Araq: I don't want complaints, I just don't want offensive comments. |
| 22:50:31 | Demos | yeah, I know I fixed something or other but never got the full toolchain working (like babel and whatnot) |
| 22:52:17 | Araq | flaviu: I am serious, but since it's IRC and it comes from me, I can understand you cannot believe me |
| 22:52:51 | flaviu | ok, text really conveys emotions poorly |
| 22:53:08 | flaviu | thanks! |
| 22:53:53 | Araq | you're welcome |
| 22:57:43 | * | superfunc joined #nimrod |
| 22:59:08 | * | perturbation joined #nimrod |
| 23:03:39 | * | gokr_ quit (Quit: IRC for Sailfish 0.8) |
| 23:05:06 | * | EXetoC quit (Quit: WeeChat 1.0.1) |
| 23:05:52 | wan | willwillson: your nick make me think of another character, wilson wilson from Utopia |
| 23:08:14 | wan | ldlework: have you solved your sdl problem? Are you using the sdl or sdl2 wrapper? |
| 23:08:35 | ldlework | wan, all we needed was to support libSDL_ttf's new binary name format |
| 23:08:41 | ldlework | I submitted a pull request |
| 23:10:04 | Araq | btw can anybody confirm https://github.com/Araq/Nimrod/issues/1701 ? |
| 23:10:16 | Araq | I think I fixed that before 0.9.6 |
| 23:10:22 | Araq | but could be wrong |
| 23:11:00 | Araq | ldlework: you got feedback for your PR |
| 23:13:42 | perturbation | Anyone experienced with Ruby and has some time for testing? I'm making progress on the pygments -> rouge lexer port for Nim, but I'd appreciate a 2nd set of eyes / sanity checking if possible. |
| 23:13:52 | wan | ldlwork: ah ok. I am using sdl2, so I wondered which was affected and why |
| 23:14:10 | perturbation | in particular, it's *really* a one-to-one port of the pygments lexer, so it's probably very un-ruby-way-ish |
| 23:14:28 | perturbation | (not done yet, but progress is one the NimLexer branch of https://github.com/singularperturbation/rouge) |
| 23:16:24 | ldlework | Araq: updated |
| 23:20:52 | * | superfunc quit (Ping timeout: 246 seconds) |
| 23:21:45 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 23:22:16 | * | EXetoC joined #nimrod |
| 23:23:30 | * | kmcguire joined #nimrod |
| 23:23:31 | Araq | perturbation: I cannot see any nim(rod).rb |
| 23:23:38 | Araq | hi kmcguire welcome |
| 23:23:51 | kmcguire | hey |
| 23:24:34 | perturbation | it's not in the master branch - check NimLexer. Should be under lib/rouge/lexers/nim.rb |
| 23:25:16 | ldlework | hi kmcguire |
| 23:25:37 | perturbation | https://github.com/singularperturbation/rouge/blob/NimLexer/lib/rouge/lexers/nim.rb |
| 23:26:20 | * | vendethiel joined #nimrod |
| 23:33:31 | Araq | perturbation: add 'defer' already to the list of keywords |
| 23:41:30 | Araq | perturbation: I also cannot stand that 'import from include' is special. just add these to the keywords list. |
| 23:41:50 | Araq | some for OPWORDS but dom96 disagrees, so it's fine |
| 23:41:50 | * | dts|pokeball joined #nimrod |
| 23:42:56 | * | BitPuffin joined #nimrod |
| 23:43:19 | perturbation | thanks Araq |
| 23:43:30 | Araq | and if you want my opinion which I can't imagine but not deny myself either: |
| 23:43:55 | Araq | https://github.com/singularperturbation/rouge/blob/NimLexer/lib/rouge/lexers/nim.rb shows Ruby is a much better language than Python. |
| 23:45:50 | perturbation | I would agree with that, but I always liked Perl more than Python anyway, and Ruby feels like a cleaner Perl to me. |
| 23:48:51 | ldlework | Araq: why does it show that? |
| 23:49:40 | Araq | ldlework: because it's DSL friendly |
| 23:50:19 | * | Trustable quit (Quit: Leaving) |
| 23:51:47 | ldlework | you can do some neat things with `with` but yeah, point |
| 23:51:51 | Demos | I am getting really annoyed at python for having from blarg import * be broken |
| 23:51:54 | Demos | and not do what you want |
| 23:53:22 | Araq | Demos: lol, what do you mean? |
| 23:53:40 | Araq | people complain about Nim's import not working like Python's |
| 23:54:07 | Demos | from mod import * works like a textual include (more or less) not like just importing all the things in the module |
| 23:54:18 | ldlework | Demos: err, what |
| 23:54:20 | Demos | and I think it is transitive |
| 23:54:21 | Araq | ah, yeah |
| 23:54:21 | ldlework | that's not what it does at all |
| 23:54:29 | Demos | well it is transitive |
| 23:54:31 | Araq | no Demos is right, ldlework |
| 23:54:40 | ldlework | transitive? |
| 23:54:43 | Araq | it copies stuff into the current namespace |
| 23:54:50 | Demos | and being transitive is one of the main issues of the textual include method |
| 23:54:55 | ldlework | it imports all top-level names in the module |
| 23:55:05 | ldlework | it does not copy text or do anything textual |
| 23:55:12 | Araq | it doesn't import really |
| 23:55:18 | Araq | from foo import bar |
| 23:55:21 | ldlework | I have no idea what distinction you're making |
| 23:55:21 | Demos | ldlework, x = b and b = c -->x = c] |
| 23:55:27 | Araq | foo.bar(x) # doesn't work |
| 23:55:34 | ldlework | Araq: you haven't imported foo |
| 23:55:38 | ldlework | you have imported bar |
| 23:55:55 | ldlework | import foo; foo.bar(x) |
| 23:56:04 | ldlework | It literally manipulates a dictionary |
| 23:56:06 | Demos | ldlework, more importantly if one module says from thing import * and another does from thatmod import * the second module gets all of thing as well |
| 23:56:11 | Demos | which is not cool at all |
| 23:56:19 | Araq | fair enough, but it surely is a gotcha, ldlework |
| 23:56:21 | ldlework | If you understand that each module is a dictionary |
| 23:56:29 | ldlework | This would be expected behavior |
| 23:56:38 | ldlework | Demos: and Nim's situation is worse |
| 23:56:41 | Demos | so I have to list EVERY SINGLE THING that I use, or deal with writing pointless qualified names everywhere |
| 23:56:55 | ldlework | Demos: yeah, that situation, is literally worse in Nim |
| 23:57:08 | Demos | right, but even if expected, it is not convenient |
| 23:57:09 | Araq | no, it isn't |
| 23:57:17 | Araq | Nim is perfect |
| 23:57:19 | ldlework | lol |
| 23:57:34 | Araq | it is not transitive unless you beg for it via 'export' |
| 23:57:36 | ldlework | At least with Python, I can figure out where a name comes from without having to qualify |
| 23:57:48 | ldlework | In Nim, I have to grep my filesystem like an asshole |
| 23:57:49 | Demos | nim's module system is quite good. It avoids scary pitfalls while not having to qualify things or anything |
| 23:58:12 | Demos | ldlework, you can use IDE tools |
| 23:58:18 | ldlework | Demos: oh yeah which ones? |
| 23:58:24 | Demos | I think even the vim plugins supports it |
| 23:58:25 | ldlework | the one's that don't exist, or the one's that are currently broken? |
| 23:58:28 | Demos | and the VS one does |
| 23:58:34 | Demos | or the command line idetools command |
| 23:58:38 | ldlework | broken |
| 23:58:47 | Demos | nope |
| 23:58:49 | Demos | working |
| 23:58:51 | Demos | just not serve |
| 23:59:01 | Demos | and not terribly easy to use |
| 23:59:24 | ldlework | Anyway |
| 23:59:38 | ldlework | If Nim let me import everything related to a type I would never mention the import system again |