Re: Lumen will be a part of the KDE 4.13 Release
On Thursday, 20 February 2014 at 14:16:51 UTC, David wrote: Lumen, the DCD plugin for Kate/KDevelop will be included in the KDE 4.13 release: http://kate-editor.org/2014/02/20/lumen-a-code-completion-plugin-for-the-d-programming-language/ Oh boy oh boy. I'm using Kate daily to code in D (I don't like full-blown IDEs). Having better D support in Kate would be wonderful! Thank you David!
Re: Artwork Design (suggestions)
Following Walter's suggestion, I've updated the design for better byDsign. Now it includes the official D logo. http://wendlerchristoph.wordpress.com/designs-for-d/ I'm still not 100% happy with the proportions and exact positions of things, so I want to tweak it a bit in the next couple of days. Next I will tackle the make the switch idea and see how it works out with the logo.
Formal review of std.lexer
x-post from http://forum.dlang.org/post/aiipgaqyddjijpjiu...@forum.dlang.org
Re: Dgame 0.3.2
On Friday, 21 February 2014 at 07:36:46 UTC, ed wrote: On Thursday, 20 February 2014 at 23:42:29 UTC, Namespace wrote: [snip] That's nice to hear! I would be glad if you could share your level so I can post it on the website. :) Sorry, missed this. I'd rather not hand it over in its current form, it is pure hack and not exemplary D/Dgame code :D If I get the chance over the next week I'll clean it up and post it. Cheers, ed On second thoughts, it isn't worth cleaning up. It is what it is and I leave it up to you to decide if it's too messy to put up on the website :D I've dumped it on github here: https://github.com/lyrebirdsw/dinvaders Cheers, ed
Re: Dgame 0.3.2
On Friday, 21 February 2014 at 14:03:35 UTC, ed wrote: On Friday, 21 February 2014 at 07:36:46 UTC, ed wrote: On Thursday, 20 February 2014 at 23:42:29 UTC, Namespace wrote: [snip] That's nice to hear! I would be glad if you could share your level so I can post it on the website. :) Sorry, missed this. I'd rather not hand it over in its current form, it is pure hack and not exemplary D/Dgame code :D If I get the chance over the next week I'll clean it up and post it. Cheers, ed On second thoughts, it isn't worth cleaning up. It is what it is and I leave it up to you to decide if it's too messy to put up on the website :D I've dumped it on github here: https://github.com/lyrebirdsw/dinvaders Cheers, ed Why not, I like it. It gives a nice retro feeling. :) Simple but good images. I had to adjust a few things, to make it work on Windows (you used an ulong for array indexing - dmd 2.064.2 on windows seems not to like it.)
Dconf Hotel?
Last year, at the conference, after the sessions everyone met up at the Aloft hotel near Facebook's HQ to have passionate and fruitful discussions about D and I think a lot of good came out of it. As someone who was NOT staying at Aloft (and who was fortunate enough to have a speaker taxiing me around, thanks Ali!), I made it a point to try and stay this year at the location that would allow me to engage in the discussions and just be able to walk to my bed (I was in no shape to drive at least one of those nights, thanks again Ali!). I know that Andrei is now living in the area, and he was the one who picked Aloft. I'm assuming Andrei's house is likely not the new location ;) Where is the hot spot this year going to be? I want to book soon :) -Steve
Re: Dconf Hotel?
Steven Schveighoffer wrote in message news:op.xbm0zbffeav7ka@stevens-macbook-pro.local... I know that Andrei is now living in the area, and he was the one who picked Aloft. I'm assuming Andrei's house is likely not the new location ;) Where is the hot spot this year going to be? I want to book soon :) Afterparty and Andrei's house, every night.
Re: Dconf Hotel?
On Friday, 21 February 2014 at 16:49:34 UTC, Daniel Murphy wrote: Afterparty and Andrei's house, every night. http://imgur.com/W5AMy0P
Re: early alpha of D REPL
On 02/14/2014 03:33 PM, Tourist wrote: Looks like you're being sarcastic. What I meant is that sending comments twice disconnects the server. I can reproduce it every time. Looks like a bug to me. Please file bug reports. https://github.com/MartinNowak/drepl/issues https://github.com/MartinNowak/drepl/commit/7ec687ba342a04bff040630957bb10876d0ebb78 https://github.com/MartinNowak/drepl/commit/3eb953e91b29546a89c222cb4f9e8b9341dc1a47
https everywhere
dlang.org and dconf.org now support https, https://dlang.org https://dconf.org Note that this is a self-signed certificate, and so when you first access it you'll get a dire warning from your browser.
Re: https everywhere
On Fri, 21 Feb 2014 12:35:10 -0800, Dicebot pub...@dicebot.lv wrote: On Friday, 21 February 2014 at 20:34:12 UTC, Walter Bright wrote: dlang.org and dconf.org now support https, https://dlang.org https://dconf.org Note that this is a self-signed certificate, and so when you first access it you'll get a dire warning from your browser. Why can't free startssl certificate be used? It probably has to do with the fact that the NSA owns every Root Signing Key in the world. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Re: https everywhere
On Friday, 21 February 2014 at 20:34:12 UTC, Walter Bright wrote: dlang.org and dconf.org now support https, https://dlang.org https://dconf.org Note that this is a self-signed certificate, and so when you first access it you'll get a dire warning from your browser. Why can't free startssl certificate be used?
Re: https everywhere
On Fri, 21 Feb 2014 12:42:10 -0800, Dicebot pub...@dicebot.lv wrote: On Friday, 21 February 2014 at 20:39:28 UTC, Adam Wilson wrote: It probably has to do with the fact that the NSA owns every Root Signing Key in the world. And how it is relevant? Not like we are speaking about security here - nothing sensitive is transferred from dlang.org; using self-signed certificates for public pages is just weird. I agree, it's not exactly welcoming due to how browsers handle them. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Re: https everywhere
On Friday, 21 February 2014 at 20:40:24 UTC, Walter Bright wrote: Why can't free startssl certificate be used? I never heard of it. https://www.startssl.com/?app=1
Re: https everywhere
On Friday, 21 February 2014 at 20:39:28 UTC, Adam Wilson wrote: It probably has to do with the fact that the NSA owns every Root Signing Key in the world. And how it is relevant? Not like we are speaking about security here - nothing sensitive is transferred from dlang.org; using self-signed certificates for public pages is just weird.
Re: https everywhere
On 2/21/2014 12:35 PM, Dicebot wrote: On Friday, 21 February 2014 at 20:34:12 UTC, Walter Bright wrote: dlang.org and dconf.org now support https, https://dlang.org https://dconf.org Note that this is a self-signed certificate, and so when you first access it you'll get a dire warning from your browser. Why can't free startssl certificate be used? I never heard of it.
Re: https everywhere
22-Feb-2014 00:34, Walter Bright пишет: dlang.org and dconf.org now support https, https://dlang.org https://dconf.org Good idea. Note that this is a self-signed certificate, and so when you first access it you'll get a dire warning from your browser. That gets horribly wrong. With this kind of stuff we'd just scare away new users. Surely a CA signed SSL cert doesn't cost that much to ignore it. -- Dmitry Olshansky
Re: https everywhere
On Fri, 21 Feb 2014 12:40:29 -0800, Walter Bright newshou...@digitalmars.com wrote: On 2/21/2014 12:35 PM, Dicebot wrote: On Friday, 21 February 2014 at 20:34:12 UTC, Walter Bright wrote: dlang.org and dconf.org now support https, https://dlang.org https://dconf.org Note that this is a self-signed certificate, and so when you first access it you'll get a dire warning from your browser. Why can't free startssl certificate be used? I never heard of it. I don't think they allow it for anything other than personal use though. -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Re: https everywhere
On Friday, 21 February 2014 at 20:35:12 UTC, Dicebot wrote: On Friday, 21 February 2014 at 20:34:12 UTC, Walter Bright wrote: dlang.org and dconf.org now support https, https://dlang.org https://dconf.org Note that this is a self-signed certificate, and so when you first access it you'll get a dire warning from your browser. Why can't free startssl certificate be used? The whole certification principle is about how much you trust who sign the certificate. I trust digital mas much more than startssl.
Re: https everywhere
On Friday, 21 February 2014 at 20:46:05 UTC, Adam Wilson wrote: On Fri, 21 Feb 2014 12:40:29 -0800, Walter Bright newshou...@digitalmars.com wrote: Why can't free startssl certificate be used? I never heard of it. I don't think they allow it for anything other than personal use though. Nope, they can be used for any purpose. All they do is verify you own the domain in question (not do the more rigorous confirmation of actual identity). For $59.90 Walter could get a class 2 organization verification for Digital Mars and do code signing so we can get rid of that scary message when people run the installer. We use StartSSL for our code signing and website SSL and are happy with it.
Re: https everywhere
On Fri, 21 Feb 2014 15:55:02 -0500, deadalnix deadal...@gmail.com wrote: On Friday, 21 February 2014 at 20:35:12 UTC, Dicebot wrote: On Friday, 21 February 2014 at 20:34:12 UTC, Walter Bright wrote: dlang.org and dconf.org now support https, https://dlang.org https://dconf.org Note that this is a self-signed certificate, and so when you first access it you'll get a dire warning from your browser. Why can't free startssl certificate be used? The whole certification principle is about how much you trust who sign the certificate. I trust digital mas much more than startssl. The problem is not who deadalnix trusts, it's who the browser trusts. I agree with others here, it should not be self-signed. It should be either unencrypted, or a trusted CA certificate. -Steve
Re: https everywhere
On Friday, 21 February 2014 at 20:55:04 UTC, deadalnix wrote: On Friday, 21 February 2014 at 20:35:12 UTC, Dicebot wrote: On Friday, 21 February 2014 at 20:34:12 UTC, Walter Bright wrote: dlang.org and dconf.org now support https, https://dlang.org https://dconf.org Note that this is a self-signed certificate, and so when you first access it you'll get a dire warning from your browser. Why can't free startssl certificate be used? The whole certification principle is about how much you trust who sign the certificate. I trust digital mas much more than startssl. Wrong. Don't confuse PGP with SSL, latter has nothing to do with trust in its current form.
Re: https everywhere
On 2/21/2014 12:57 PM, Brad Anderson wrote: For $59.90 Walter could get a class 2 organization verification for Digital Mars and do code signing so we can get rid of that scary message when people run the installer. We use StartSSL for our code signing and website SSL and are happy with it. Would that work for all the websites? I.e. digitalmars.com, dlang.org, etc., or would it be a separate charge for each?
Re: https everywhere
On Friday, 21 February 2014 at 21:37:39 UTC, Walter Bright wrote: On 2/21/2014 12:57 PM, Brad Anderson wrote: For $59.90 Walter could get a class 2 organization verification for Digital Mars and do code signing so we can get rid of that scary message when people run the installer. We use StartSSL for our code signing and website SSL and are happy with it. Would that work for all the websites? I.e. digitalmars.com, dlang.org, etc., or would it be a separate charge for each? The one cost and you could cover everything. StartSSL is novel in that all they do is verify your identity then let you generate as many certificates as you want. Most other CAs charge on a per certificate basis. I'm pretty happy with StartSSL apart from their terrible website.
Re: https everywhere
On 2/21/14, 12:34 PM, Walter Bright wrote: dlang.org and dconf.org now support https, https://dlang.org https://dconf.org Note that this is a self-signed certificate, and so when you first access it you'll get a dire warning from your browser. At this point I'm just repeating what others have already said, but self-signed is seriously unprofessional. It's worse than not having https from a reputation standpoint.
Re: https everywhere
On Friday, 21 February 2014 at 21:37:39 UTC, Walter Bright wrote: Would that work for all the websites? I.e. digitalmars.com, dlang.org, etc., or would it be a separate charge for each? Any certificate is tied to domain or masked domain. Covering both *.digitalmars.com and *.dlang.org with same certificate is impossible.
Re: https everywhere
On 2/21/2014 4:39 PM, Brad Anderson wrote: On Friday, 21 February 2014 at 21:37:39 UTC, Walter Bright wrote: Would that work for all the websites? I.e. digitalmars.com, dlang.org, etc., or would it be a separate charge for each? The one cost and you could cover everything. StartSSL is novel in that all they do is verify your identity then let you generate as many certificates as you want. Most other CAs charge on a per certificate basis. I'm pretty happy with StartSSL apart from their terrible website. This is true (I do it on my server, hosting a couple domains ATM). However, unless they've changed it since I last looked, you can't do subdomains (other than www.*) with their free cert.
Re: Dvorm, now with more pop!
This is great! Can't wait to check it out. (^_-)b
Re: https everywhere
On 2/21/2014 3:57 PM, Brad Anderson wrote: For $59.90 Walter could get a class 2 organization verification for Digital Mars and do code signing so we can get rid of that scary message when people run the installer. We use StartSSL for our code signing and website SSL and are happy with it. I think it's pretty much standard practice in the Windows world to ignore that warning. I've seen very little software that does bother with that code signing.
Re: https everywhere
On 2/21/2014 3:55 PM, deadalnix wrote: On Friday, 21 February 2014 at 20:35:12 UTC, Dicebot wrote: On Friday, 21 February 2014 at 20:34:12 UTC, Walter Bright wrote: dlang.org and dconf.org now support https, https://dlang.org https://dconf.org Note that this is a self-signed certificate, and so when you first access it you'll get a dire warning from your browser. Why can't free startssl certificate be used? The whole certification principle is about how much you trust who sign the certificate. I trust digital mas much more than startssl. Self-signed certs *can't* be trusted to be from the party they claim to be from. Anyone can generate a self-signed cert claiming to be Digital Mars.
Re: Dconf Hotel?
On 2/21/14, 6:49 PM, Daniel Murphy wrote: Steven Schveighoffer wrote in message news:op.xbm0zbffeav7ka@stevens-macbook-pro.local... I know that Andrei is now living in the area, and he was the one who picked Aloft. I'm assuming Andrei's house is likely not the new location ;) Where is the hot spot this year going to be? I want to book soon :) Afterparty and Andrei's house, every night. If you want to do the 1h10m commute one way each night... :o) Aloft is the best candidate for the unofficial hangout spot. Andrei
Re: https everywhere
On Friday, 21 February 2014 at 21:50:21 UTC, Nick Sabalausky wrote: On 2/21/2014 3:57 PM, Brad Anderson wrote: For $59.90 Walter could get a class 2 organization verification for Digital Mars and do code signing so we can get rid of that scary message when people run the installer. We use StartSSL for our code signing and website SSL and are happy with it. I think it's pretty much standard practice in the Windows world to ignore that warning. I've seen very little software that does bother with that code signing. I think it's ignored by users like you and I but at my work we'd get worried calls from our customers thinking our installer was unsafe so we ended up adding code signing.
Re: https everywhere
On Friday, 21 February 2014 at 21:44:19 UTC, Dicebot wrote: On Friday, 21 February 2014 at 21:37:39 UTC, Walter Bright wrote: Would that work for all the websites? I.e. digitalmars.com, dlang.org, etc., or would it be a separate charge for each? Any certificate is tied to domain or masked domain. Covering both *.digitalmars.com and *.dlang.org with same certificate is impossible. This doesn't apply because StartSSL lets you create as many certificates as you want.
Re: https everywhere
On Friday, 21 February 2014 at 22:52:46 UTC, Brad Anderson wrote: On Friday, 21 February 2014 at 21:44:19 UTC, Dicebot wrote: On Friday, 21 February 2014 at 21:37:39 UTC, Walter Bright wrote: Would that work for all the websites? I.e. digitalmars.com, dlang.org, etc., or would it be a separate charge for each? Any certificate is tied to domain or masked domain. Covering both *.digitalmars.com and *.dlang.org with same certificate is impossible. This doesn't apply because StartSSL lets you create as many certificates as you want. Yes, of course, but it won't be the same certificate. Walters question was about paid verified certificates.
Re: https everywhere
On 2/21/14, 3:43 PM, Adam Wilson wrote: On Fri, 21 Feb 2014 12:42:10 -0800, Dicebot pub...@dicebot.lv wrote: On Friday, 21 February 2014 at 20:39:28 UTC, Adam Wilson wrote: It probably has to do with the fact that the NSA owns every Root Signing Key in the world. And how it is relevant? Not like we are speaking about security here - nothing sensitive is transferred from dlang.org; using self-signed certificates for public pages is just weird. I agree, it's not exactly welcoming due to how browsers handle them. Read what the browser says. Look at the information the browser displays the certificate. What then is the problem???
Re: https everywhere
On 2/21/14, 3:35 PM, Dicebot wrote: On Friday, 21 February 2014 at 20:34:12 UTC, Walter Bright wrote: dlang.org and dconf.org now support https, https://dlang.org https://dconf.org Note that this is a self-signed certificate, and so when you first access it you'll get a dire warning from your browser. Why can't free startssl certificate be used? We could use a Free StartSSL certificate if that gives any benefit over a self-signed certificate.
Re: https everywhere
On 2/21/14, 3:55 PM, deadalnix wrote: On Friday, 21 February 2014 at 20:35:12 UTC, Dicebot wrote: On Friday, 21 February 2014 at 20:34:12 UTC, Walter Bright wrote: dlang.org and dconf.org now support https, https://dlang.org https://dconf.org Note that this is a self-signed certificate, and so when you first access it you'll get a dire warning from your browser. Why can't free startssl certificate be used? The whole certification principle is about how much you trust who sign the certificate. I trust digital mas much more than startssl. :-)
Re: https everywhere
On Friday, 21 February 2014 at 22:59:39 UTC, Dicebot wrote: On Friday, 21 February 2014 at 22:52:46 UTC, Brad Anderson wrote: On Friday, 21 February 2014 at 21:44:19 UTC, Dicebot wrote: On Friday, 21 February 2014 at 21:37:39 UTC, Walter Bright wrote: Would that work for all the websites? I.e. digitalmars.com, dlang.org, etc., or would it be a separate charge for each? Any certificate is tied to domain or masked domain. Covering both *.digitalmars.com and *.dlang.org with same certificate is impossible. This doesn't apply because StartSSL lets you create as many certificates as you want. Yes, of course, but it won't be the same certificate. Walters question was about paid verified certificates. Walter's question is about whether the paid StartSSL verification I mentioned would let him cover all of those things for a single price (which it would). Not about whether a single certificate could be made to cover all of those things.
Re: https everywhere
On 2/21/14, 3:40 PM, Walter Bright wrote: On 2/21/2014 12:35 PM, Dicebot wrote: On Friday, 21 February 2014 at 20:34:12 UTC, Walter Bright wrote: dlang.org and dconf.org now support https, https://dlang.org https://dconf.org Note that this is a self-signed certificate, and so when you first access it you'll get a dire warning from your browser. Why can't free startssl certificate be used? I never heard of it. Neither have I... I know there is www.cacert.org but as far as I know their certs are still not integrated in the browser SSL store.
Re: Dgame 0.3.2
On Friday, 21 February 2014 at 14:32:00 UTC, Namespace wrote: On Friday, 21 February 2014 at 14:03:35 UTC, ed wrote: On Friday, 21 February 2014 at 07:36:46 UTC, ed wrote: On Thursday, 20 February 2014 at 23:42:29 UTC, Namespace wrote: [snip] That's nice to hear! I would be glad if you could share your level so I can post it on the website. :) Sorry, missed this. I'd rather not hand it over in its current form, it is pure hack and not exemplary D/Dgame code :D If I get the chance over the next week I'll clean it up and post it. Cheers, ed On second thoughts, it isn't worth cleaning up. It is what it is and I leave it up to you to decide if it's too messy to put up on the website :D I've dumped it on github here: https://github.com/lyrebirdsw/dinvaders Cheers, ed Why not, I like it. It gives a nice retro feeling. :) Simple but good images. OK cool, use it however you like :) I had to adjust a few things, to make it work on Windows (you used an ulong for array indexing - dmd 2.064.2 on windows seems not to like it.) Yes, it had very little testing but hopefully you find a use for it. On a side note, the author in the code is Stewart but it is still me :). It is my middle name, which the auto-header vim script grabs from the login. Cheers, ed (stewart)
Re: Dgame 0.3.2
On Friday, 21 February 2014 at 23:26:58 UTC, ed wrote: On Friday, 21 February 2014 at 14:32:00 UTC, Namespace wrote: On Friday, 21 February 2014 at 14:03:35 UTC, ed wrote: On Friday, 21 February 2014 at 07:36:46 UTC, ed wrote: On Thursday, 20 February 2014 at 23:42:29 UTC, Namespace wrote: [snip] That's nice to hear! I would be glad if you could share your level so I can post it on the website. :) Sorry, missed this. I'd rather not hand it over in its current form, it is pure hack and not exemplary D/Dgame code :D If I get the chance over the next week I'll clean it up and post it. Cheers, ed On second thoughts, it isn't worth cleaning up. It is what it is and I leave it up to you to decide if it's too messy to put up on the website :D I've dumped it on github here: https://github.com/lyrebirdsw/dinvaders Cheers, ed Why not, I like it. It gives a nice retro feeling. :) Simple but good images. OK cool, use it however you like :) I had to adjust a few things, to make it work on Windows (you used an ulong for array indexing - dmd 2.064.2 on windows seems not to like it.) Yes, it had very little testing but hopefully you find a use for it. On a side note, the author in the code is Stewart but it is still me :). It is my middle name, which the auto-header vim script grabs from the login. Cheers, ed (stewart) I just saw it up on the website, very cool, thanks :)
Re: https everywhere
On Friday, 21 February 2014 at 23:12:32 UTC, Brad Anderson wrote: Walter's question is about whether the paid StartSSL verification I mentioned would let him cover all of those things for a single price (which it would). Not about whether a single certificate could be made to cover all of those things. Then please disregard my obviously wrong answer :)
Re: https everywhere
On Friday, 21 February 2014 at 23:10:12 UTC, Jan Knepper wrote: On 2/21/14, 3:40 PM, Walter Bright wrote: On 2/21/2014 12:35 PM, Dicebot wrote: On Friday, 21 February 2014 at 20:34:12 UTC, Walter Bright wrote: dlang.org and dconf.org now support https, https://dlang.org https://dconf.org Note that this is a self-signed certificate, and so when you first access it you'll get a dire warning from your browser. Why can't free startssl certificate be used? I never heard of it. Neither have I... I know there is www.cacert.org but as far as I know their certs are still not integrated in the browser SSL store. Just going to throw this out there, but GlobalSign offers free wildcard certificates to open source projects. GlobalSign's root is in the standard CA stores. Might be worth checking out. https://www.globalsign.com/ssl/ssl-open-source/ Disclaimer: I am a GlobalSign reseller, but I have nothing to gain from their free certificate offers.
Re: https everywhere
Brad Anderson, el 21 de February a las 21:39 me escribiste: On Friday, 21 February 2014 at 21:37:39 UTC, Walter Bright wrote: On 2/21/2014 12:57 PM, Brad Anderson wrote: For $59.90 Walter could get a class 2 organization verification for Digital Mars and do code signing so we can get rid of that scary message when people run the installer. We use StartSSL for our code signing and website SSL and are happy with it. Would that work for all the websites? I.e. digitalmars.com, dlang.org, etc., or would it be a separate charge for each? The one cost and you could cover everything. StartSSL is novel in that all they do is verify your identity then let you generate as many certificates as you want. Most other CAs charge on a per certificate basis. I'm pretty happy with StartSSL apart from their terrible website. I use the free certificates and it works very nicely! -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- No existe nada más intenso que un reloj, ni nada más flaco que una bicicleta. No intenso como el café, ni flaco como escopeta. -- Ricardo Vaporeso
Re: https everywhere
Nick Sabalausky, el 21 de February a las 16:47 me escribiste: On 2/21/2014 4:39 PM, Brad Anderson wrote: On Friday, 21 February 2014 at 21:37:39 UTC, Walter Bright wrote: Would that work for all the websites? I.e. digitalmars.com, dlang.org, etc., or would it be a separate charge for each? The one cost and you could cover everything. StartSSL is novel in that all they do is verify your identity then let you generate as many certificates as you want. Most other CAs charge on a per certificate basis. I'm pretty happy with StartSSL apart from their terrible website. This is true (I do it on my server, hosting a couple domains ATM). However, unless they've changed it since I last looked, you can't do subdomains (other than www.*) with their free cert. No, you can use any subdomain, you can't use wildcards, but you can get as many subdomains as you want. To use several subdomains in one server, your server must support SNI[1], but any modern webserver should support it. [1] https://en.wikipedia.org/wiki/Server_Name_Indication -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- De las generaciones venideras espero, nada más, que vengan. -- Ricardo Vaporeso
Re: https everywhere
On 2/22/2014 12:09 AM, Leandro Lucarella wrote: Nick Sabalausky, el 21 de February a las 16:47 me escribiste: On 2/21/2014 4:39 PM, Brad Anderson wrote: On Friday, 21 February 2014 at 21:37:39 UTC, Walter Bright wrote: Would that work for all the websites? I.e. digitalmars.com, dlang.org, etc., or would it be a separate charge for each? The one cost and you could cover everything. StartSSL is novel in that all they do is verify your identity then let you generate as many certificates as you want. Most other CAs charge on a per certificate basis. I'm pretty happy with StartSSL apart from their terrible website. This is true (I do it on my server, hosting a couple domains ATM). However, unless they've changed it since I last looked, you can't do subdomains (other than www.*) with their free cert. No, you can use any subdomain, you can't use wildcards, but you can get as many subdomains as you want. To use several subdomains in one server, your server must support SNI[1], but any modern webserver should support it. [1] https://en.wikipedia.org/wiki/Server_Name_Indication I've tried to get a subdomain cert from them, but their system complained that I already had a cert from them for the same domain.
Re: https everywhere
On 2/21/2014 5:50 PM, Brad Anderson wrote: On Friday, 21 February 2014 at 21:50:21 UTC, Nick Sabalausky wrote: On 2/21/2014 3:57 PM, Brad Anderson wrote: For $59.90 Walter could get a class 2 organization verification for Digital Mars and do code signing so we can get rid of that scary message when people run the installer. We use StartSSL for our code signing and website SSL and are happy with it. I think it's pretty much standard practice in the Windows world to ignore that warning. I've seen very little software that does bother with that code signing. I think it's ignored by users like you and I but at my work we'd get worried calls from our customers thinking our installer was unsafe so we ended up adding code signing. Perhaps so. Although FWIW, there's also a *lot* of average-joe users (I personally know far too many) who flat-out *refuse* to read any word that ever appears on their screen. These retards^H^H^H^H^H^H^Hpeople^H^H^H^H^H^Hworthless wastes of carbon view words as things to be immediately shoo'ed away in a frenzy of mindless clicking and How do I make this go away?!?!? (Me: Uhh, make what...well What does it say? The Retard: I dunno. I didn't read it. [silently:]FFFCCCK YOOOUUU). To be perfectly honest I actually *am* genuinely surprised to hear of the existence of retards who actually *do* read words on screens. Sounds almost like a paradise of geniuses compared to the bullshit I've always had to put up with.
Re: Repost: make foreach(i, a; range) just work
On Friday, 21 February 2014 at 02:34:30 UTC, Jesse Phillips wrote: I don't see enough benefit for making this a language feature. foreach(i, v1, v2; tuple(0,1).repeat(10).enumerate) writeln(i, \t, v1, \t, v2); This works today! And once enumerate is part of Phobos it will just need an import std.range to use it. This.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Thursday, 20 February 2014 at 20:26:40 UTC, Russel Winder wrote: On Mon, 2014-02-17 at 22:19 +, ponce wrote: […] Granted code bloat is a real thing and you _might_ have instruction cache problems, but the problem only ever show itself […] Code bloat in what sense? Go is founded on static compilation so as to avoid the dynamic library binding problem. So executable are 5 to 100MB which is code blat in my book. On the other hand they don't have library versioning problems which is the bane of Posix. I meant it in the sense of actual slowdown related to binary size, or impossibility to fit a program on some embedded hardware.
Re: Implement the unum representation in D ?
On Friday, 21 February 2014 at 05:21:53 UTC, Frustrated wrote: I think though adding a repeating bit would make it even more accurate so that repeating decimals within the bounds of maximum bits used could be represented perfectly. e.g., 1/3 = 0.... could be represented perfectly with such a bit and sliding fp type. With proper cpu support one could have 0.... * 3 = 1 exactly. I believe that the repeating decimals, or better, repeating binary fractions, will hardly be more useful than a rational representation like p/q. The reason is, if we take a reciprocal 1/q and represent it as a binary, decimal, or other fixed-base fraction, the representation is surely periodic, but the upper bound on the length of its period is as high as q-1, and it is not unlikely to be the exact bound. For example, at http://en.wikipedia.org/wiki/Binary_number#Fractions , note that the binary fraction for 1/11 has period 10, and for 1/13 the period is 12. Thus repeating decimal for a fraction p/q will take up to q-1 bits when we store it as a repeating decimal, but log(p)+log(q) bits when stored as a rational number (numerator and denominator). Ivan Kazmenko.
Re: Implement the unum representation in D ?
On Thursday, 20 February 2014 at 23:43:18 UTC, Nordlöw wrote: The unum variable length encoding is very similar to how msgpack packs integers. See msgpack-d on github for a superb implementation in D. msgpack-d is indeed a great library that makes serialization almost instant to implement. I implemented CBOR another binary encoding scheme and it was obvious CBOR brings nothing over msgpack, it even did worse with integer encoding.
Re: Preflight of DUB 0.9.21 (RC 5)
Am 20.02.2014 21:38, schrieb Jordi Sayol: El 20/02/14 17:04, Sönke Ludwig ha escrit: Hopefully the final release candidate has been uploaded. The new RPM package could need some testing: http://code.dlang.org/files/dub-0.9.21-0.rc.5.x86_64.rpm http://code.dlang.org/download dub rc5 binaries properly tested on Debian 6. New rpm package properly tested on Fedora 14, Fedora 18 and OpenSUSE 12.4 Thanks a lot for testing! I'll tag this as a release if nothing else happens until then. Will be a rpm 32-bit version? Yes, should be no problem, but I'd like to load that off to the next version together with an outstanding automation issue (the RPM still needs to be uploaded manually in contrast to all the other files) and an improved download page layout.
Re: Ada conference, Ada and Spark
On Thursday, 20 February 2014 at 08:03:47 UTC, Paulo Pinto wrote: [cut] I have been following Ada at FOSDEM for the last years, and its use seems to be increasing in Europe for safety critical systems, mainly thanks to C and C++ issues. Maybe this is an area where D could be pushed as well. I don't think so: given that D is C++ done right, it would require many (unlikely to happen) changes to become an interesting alternative for Ada: for example changing the semantic of integers! That said, one question I should ask to Rust devs is why they didn't base Rust on Ada given their goals.. renoX
Re: Repost: make foreach(i, a; range) just work
On Thu, 20 Feb 2014 16:30:42 -, Justin Whear
jus...@economicmodeling.com wrote:
On Thu, 20 Feb 2014 13:04:55 +, w0rp wrote:
More importantly, this gets in the way of behaviour which may be
desirable later, foreach being able to unpack tuples from ranges.
I would like if it was possible to return Tuple!(A, B) from front() and
write foreach(a, b; range) to interate through those thing, unpacking
the values with an alias, so this...
foreach(a, b; range) {
}
... could rewrite to roughly this. (There may be a better way.)
foreach(_someInternalName; range) {
alias a = _someInternalName[0];
alias b = _someInternalName[1];
}
Tuple unpacking already works in foreach. This code has compiled since
at least 2.063.2:
import std.stdio;
import std.range;
void main(string[] args)
{
auto tuples = [a, b, c].zip(iota(0, 3));
// unpack the string into `s`, the integer into `i`
foreach (s, i; tuples)
writeln(s, , , i);
}
Does this work for more than 2 values? Can the first value be something
other than an integer?
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Correct comparison of signed type with unsigned type (and vice versa)
On Thursday, 20 February 2014 at 20:52:23 UTC, Xinok wrote: The following statement prints false: writeln(-1 uint.max); I don't see this as a bug, this is exactly what I expect from a language with intact C integer semantics. This came up in another topic recently. I think this is silly and an unnecessary source of bugs (it's bitten me before and presumably many others as well). I'm making a proposal to add an extra check so that comparisons of signed with unsigned types is always correct. Simply, if the signed type is negative, it is by default less than the unsigned value. That subtly breaks C compatiblity. Others have suggested disallowing comparing a signed type with an unsigned type. I think this is a better solution. Currently in C the unsigned vs signed operations all follow the same rules. If you do this, would you also disallow unsigned vs signed addition, subtraction, divide? I feel this would make porting C code much longer, and it's already quite a bit of work.
Re: Correct comparison of signed type with unsigned type (and vice versa)
On Thursday, 20 February 2014 at 22:52:55 UTC, Meta wrote:
I can't think of any C code that would rely on such behaviour,
but I think it'd just be safer all-around to make it an error.
Eg this optimization:
if ((unsigned int)(a - min) (max - min)) // only one
comparison instead of two
{
}
And there is many C codes relying on unsigned promotion, since
signed overflow in C99 is undefined behaviour. The easiest way to
force an operation is then to use one cast.
Re: Repost: make foreach(i, a; range) just work
My current thinking:
- I still think adding index to range foreach is a good idea.
- I realise that scheme #2 isn't workable.
- I still like scheme #1 over tuple expansion as it avoids all the issues
which make scheme #2 unworkable.
- enumerate is not as flexible as many people seem to think.
On Fri, 21 Feb 2014 02:34:28 -, Jesse Phillips
jesse.k.phillip...@gmail.com wrote:
On Thursday, 20 February 2014 at 11:15:14 UTC, Regan Heath wrote:
I am posting this again because I didn't get any feedback on my idea,
which may be TL;DR or because people think it's a dumb idea and they
were politely ignoring it :p
I certainly have wanted counts of the range iteration, but I do believe
it becomes too complex to support and that even if we state 'i' is to
represent a count and not an index, people will still want an index and
expect it to be an index of their original range even though it makes no
possible sense from the perspective of iterating over a different range
from the original.
I don't understand how this is complex to support? It's simple. It's a
count, not an index unless the range is indexable. If people are going to
expect an index here, they will expect one with enumerate as well - and
are going to be equally disappointed. So, they need to be aware of this
regardless.
I also don't find myself needing to count iterations very often, and I
believe when I do, it is because I want to use that count as an index
(possibly needing to add to some global count, but I don't need it
enough to remember).
The justification for this change is the same as for enumerate.
It is common enough to make it important, and when it happens it's
frustrating enough that it needs fixing.
My specific example didn't want an index, or rather it wanted an index
into the result set which I believe is just as common if not more common
than wanting an index into the source - especially given that they are
often the same thing.
For example, I find myself using an index to control loop behaviour, most
often for detecting the first and last iterations than anything else. A
counter will let you do that just as well as an index.
Scheme 1)
As Marc said, ails backwards-compatibility. A change like this will
never exist if it isn't backwards compatible. There are very few changes
which will be accepted if backwards compatibility isn't preserved.
Sure. I personally find this idea compelling enough to warrant some
breakage, it is simple, powerful and extensible and avoids all the issues
of optional indexes with tuple expansion. But, I can see how someone
might disagree.
Scheme 2)
However, if a type is given and the type can be unambiguously matched
to a single tuple component then do so.
double[string] AA;
foreach (string k; AA) {} // k is key
While probably not common, what if one needed to switch key/value
string[double] AA;
or something similar, the type system no longer helps. But again, this
seems pretty much uneventful.
Perhaps I wasn't clear, this would work fine:
string[double] AA;
foreach (string v; AA) {} // v is value
foreach (double k; AA) {} // k is key
or am I missing the point you're making?
foreach (i, k, v; AA.byPairs.enumerate) {}
foreach (i, k, v; AA) {} // better
Bringing this back to range iteration:
foreach(i, v1, v2; tuple(0,1).repeat(10))
writeln(i, \t,v1, \t,v2);
Later the range gets a new value, the foreach would still compile but be
wrong:
foreach(i, v1, v2; tuple(0,1,2).repeat(10))
writeln(i, \t,v1, \t,v2);
With enumerate, there is an error.
foreach(i, v1, v2; tuple(0,1,2).repeat(10).enumerate)
writeln(i, \t, v1, \t, v2);
Error: cannot infer argument types
Sure, this is an issue with having the optional index/count variable,
which is not something foreach with enumerate allows. This is another
reason I prefer scheme #1, you never have this issue no matter what.
foreach(i, v1, v2; tuple(0,1).repeat(10).enumerate)
writeln(i, \t, v1, \t, v2);
This works today! And once enumerate is part of Phobos it will just need
an import std.range to use it.
I don't believe this works today. My understanding of what is currently
supported is..
foreach(index, value; array) { }
foreach(value; range) { }// no support for index/count
foreach(key, value; tuple) { } // no support for index/count
And, my understanding of enumerate is that it simply creates a tuple from
an index and a range value, taking it from the range foreach case above,
to the tuple foreach case.
This is not extensible to more than 2 values. In fact, it's pretty
limited until we get full built-in tuple expansion support.
To test this understanding I pulled down the source for enumerate and
coded this up:
import std.stdio;
import std.range;
import std.typecons;
..paste enumerate here.. // line 5
void main()
{
Re: Repost: make foreach(i, a; range) just work
On Fri, 21 Feb 2014 10:02:43 -, Regan Heath re...@netmail.co.nz
wrote:
On Thu, 20 Feb 2014 16:30:42 -, Justin Whear
jus...@economicmodeling.com wrote:
On Thu, 20 Feb 2014 13:04:55 +, w0rp wrote:
More importantly, this gets in the way of behaviour which may be
desirable later, foreach being able to unpack tuples from ranges.
I would like if it was possible to return Tuple!(A, B) from front() and
write foreach(a, b; range) to interate through those thing, unpacking
the values with an alias, so this...
foreach(a, b; range) {
}
... could rewrite to roughly this. (There may be a better way.)
foreach(_someInternalName; range) {
alias a = _someInternalName[0];
alias b = _someInternalName[1];
}
Tuple unpacking already works in foreach. This code has compiled since
at least 2.063.2:
import std.stdio;
import std.range;
void main(string[] args)
{
auto tuples = [a, b, c].zip(iota(0, 3));
// unpack the string into `s`, the integer into `i`
foreach (s, i; tuples)
writeln(s, , , i);
}
Does this work for more than 2 values? Can the first value be something
other than an integer?
Answered this myself. What is supported is:
foreach(key, value; tuple) { }
But, what is not supported is more than 2 values.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Repost: make foreach(i, a; range) just work
On Thu, 20 Feb 2014 17:09:31 -, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Thu, 20 Feb 2014 11:07:32 -0500, Regan Heath re...@netmail.co.nz
wrote:
Only if the compiler prefers opApply to range methods, does it?
It should. If it doesn't, that is a bug.
The sole purpose of opApply is to interact with foreach. If it is masked
out, then there is no point for having opApply.
Thanks.
So, if we had this support which I am asking for:
foreach(index, value; range) { }
And, if someone adds opApply to that range, with a different type for the
first variable then an existing foreach (using index, value) is likely to
stop compiling due to type problems.
This seems acceptable to me.
There is an outside chance it might keep on compiling, like if 'i' is not
used in a strongly typed way, i.e. passed to a writefln or similar. In
this case we have silently changed behaviour.
Is this acceptable?
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Formal review of std.lexer
http://wiki.dlang.org/Review/std.lexer This is follow-up by Brian to his earlier proposal (http://wiki.dlang.org/Review/std.d.lexer). This time proposed module focuses instead on generic lexer generation as discussed in matching voting thread. Docs: http://hackerpilot.github.io/experimental/std_lexer/phobos/lexer.html Code: https://github.com/Hackerpilot/Dscanner/blob/master/stdx/lexer.d Example topics to evaluate during review: - Feasibility of overall design and concept - Quality of documentation - Consistency with existing Phobos modules - Overall quality of implementation Initial review will end on March the 8th.
Re: Correct comparison of signed type with unsigned type (and vice versa)
On Thursday, 20 February 2014 at 20:52:23 UTC, Xinok wrote: Others have suggested disallowing comparing a signed type with an unsigned type. I think this is a better solution. Yes, it will add a small bit of overhead, but I believe it's more important for code to be correct than to be fast. I totally agree. However, since we need correct code, we need way more features than this. I was surprised to find out that we don't have any SafeInt type in D... I was sure someone had made it but I wasn't able to find it anywhere. My ideal int type: -Has an equivalent of NaN, meaning it doesn't have 0 initialization which is somewhat bug-prone. -Is able to signal errors like overflow/division by zero, would be nice if throwing could be avoided. -Signed, but can be flagged as 0 only, and signals an error if it gets assigned a negative value. -Some extra features that are surely awesome but I'm forgetting right now. Any takers? Man, I wish I had time :S
Re: Why is int implicitly convertible to ulong?
The specific problem here was when working with std.json.
std.json distinguishes between UINTEGER and INTEGER, so I had
code like
static if(is(T : ulong)) {
// must be UINTEGER
} else static if(is(T : long)) {
// can be either INTEGER or UINTEGER
}
I've since found out about isSigned and isUnsigned, still it was
mighty confusing for me that the first case was selected for
signed types.
Re: Formal review of std.lexer
On Friday, 21 February 2014 at 12:12:17 UTC, Dicebot wrote: http://wiki.dlang.org/Review/std.lexer First of all, thank you for the great work. This is a very important project. I'll begin with reviewing the documentation. Summary Some simple explanation of the terminology and concepts would be nice. At least a link to Wikipedia. Create the string array costants for your language. Typo (costants) Examples: An inline complete example of a very simple language would be nice. A lexer for D is available here. Although good to have, this is too much to take in all at once, for documentation purposes. A lexer for Lua is available here. Nary a comment in sight. This might serve as the example lexer if only it was better commented. The comments can be copy-pasted from the module documentation, even that would make the code much easier to grok. Template Parameter Definitions What does this mean? Parameters to what template? Can this section be moved to inside the documentation of Lexer, and Lexer be moved to the first documented symbol in the file? A function that serves as the default token lexing function. For most languages this will be the identifier lexing function. Should the function signature and contracts be explained here? This function must return bool and take a single size_t argument representing the number of bytes to skip over before looking for a separating character. I think it's better to describe the signature in D syntax rather than English. A listing of tokens whose value is variable, such as whitespace, identifiers, number literals, and string literals. No mention of how the list is represented (is it an array? what type of elements should the array have? how are the array values used?), the reader is left to figure that out from the example below. Template for determining the type used for a token type. Selects the smallest unsigned integral type that is able to hold the value staticTokens.length + dynamicTokens.length + possibleDefaultTokens.length. For example if there are 20 static tokens, 30 dynamic tokens, and 10 possible default tokens, this template will alias itself to ubyte, as 20 + 30 + 10 ubyte.max. Should this be documented? I understand that this will be instantiated only once, by std.lexer. Utility declarations should preferably be at the end of the module, so that they appear last in the documentation. Generates the token type identifier for the given symbol. There are two special cases: Are these magic constants necessary? Why not declare them as enums? In all cases this template will alias itself to a constant of type IdType. This template will fail at compile time if symbol is not one of the staticTokens, dynamicTokens, or possibleDefaultTokens. Style nit: D symbols should be wrapped in the $D(...) macro. == overload for the the token type. Is it really necessary to document opEquals? But since it's here: how does it interact with extraFields? The Column number at which this token occurs. There was a lot of bikeshedding regarding the correct terminology to use when adding -vcolumns to DMD ( https://github.com/D-Programming-Language/dmd/pull/3077 ). I think the documentation should at least mention what exactly it is counting. A function that serves as the default token lexing function. For most languages this will be the identifier lexing function. What should the function's name be? How will it interact with Lexer? (It's not clear that this refers to the defaultTokenFunction parameter, especially after the previous list item, popFront, is a different piece of the puzzle.) The documentation for Lexer's arguments seem to be thrown all around the module. I suggest to document them only once, all in Lexer's DDoc, add example signatures, and move Lexer to the top of the module. Examples: struct CalculatorLexer I think this should be expanded into a full, well-documented example featured in the module DDoc. _popFront(); Where did that come from? Perhaps you meant Lexer's DDoc to say which should call this mixin's _popFront(), and the DDoc escaped the _ character? If so, why not use a named mixin to disambiguate instead of _? struct LexerRange; struct StringCache; These are thoroughly documented, but will they be used by anything other than std.lexer?
Re: Ada conference, Ada and Spark
On Friday, 21 February 2014 at 10:01:41 UTC, renoX wrote: On Thursday, 20 February 2014 at 08:03:47 UTC, Paulo Pinto wrote: [cut] I have been following Ada at FOSDEM for the last years, and its use seems to be increasing in Europe for safety critical systems, mainly thanks to C and C++ issues. Maybe this is an area where D could be pushed as well. I don't think so: given that D is C++ done right, it would require many (unlikely to happen) changes to become an interesting alternative for Ada: for example changing the semantic of integers! That said, one question I should ask to Rust devs is why they didn't base Rust on Ada given their goals.. renoX That is easy to answer, I doubt they could with their rule of not having more than 5 characters per keyword. :) -- Paulo
Re: Ada conference, Ada and Spark
On Friday, 21 February 2014 at 12:56:32 UTC, Paulo Pinto wrote: That is easy to answer, I doubt they could with their rule of not having more than 5 characters per keyword. :) Wait, what? REALLY? What kind of rule is that. ahahahha... are they stuck to the 70's? :D
Re: Why is int implicitly convertible to ulong?
On Friday, February 21, 2014 12:41:07 Hannes Steffenhagen wrote:
The specific problem here was when working with std.json.
std.json distinguishes between UINTEGER and INTEGER, so I had
code like
static if(is(T : ulong)) {
// must be UINTEGER
} else static if(is(T : long)) {
// can be either INTEGER or UINTEGER
}
I've since found out about isSigned and isUnsigned, still it was
mighty confusing for me that the first case was selected for
signed types.
Well, it is using : - which means implicit conversion, which is always
something that you should be careful with in generic code. Technically,
something like
struct S
{
ulong ul;
alias ul this;
}
would match it as well, and depending on what the code inside the static if is
like, it might work, but there's also a good chance that it wouldn't. Using
is(T == ulong) if you want to require that it be exactly ulong, or
isUnsigned!T if you want any unsigned integral type. Using implicit conversion
in generic code _can_ be useful, but you need to be _very_ careful with it.
- Jonathan M Davis
Re: Correct comparison of signed type with unsigned type (and vice versa)
On 20/02/2014 20:52, Xinok wrote: Others have suggested disallowing comparing a signed type with an unsigned type. Yes, that solution is pre-approved: https://d.puremagic.com/issues/show_bug.cgi?id=259 I think that's a very important bug to solve.
Re: Ada conference, Ada and Spark
On Friday, 21 February 2014 at 13:08:37 UTC, Francesco Cattoglio wrote: On Friday, 21 February 2014 at 12:56:32 UTC, Paulo Pinto wrote: That is easy to answer, I doubt they could with their rule of not having more than 5 characters per keyword. :) Wait, what? REALLY? What kind of rule is that. ahahahha... are they stuck to the 70's? :D Yes really, http://forum.dlang.org/post/glnafbocwjodiwrqw...@forum.dlang.org I just cannot find the Reddit thread any longer.
Re: Repost: make foreach(i, a; range) just work
On Fri, 21 Feb 2014 06:21:39 -0500, Regan Heath re...@netmail.co.nz
wrote:
On Thu, 20 Feb 2014 17:09:31 -, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Thu, 20 Feb 2014 11:07:32 -0500, Regan Heath re...@netmail.co.nz
wrote:
Only if the compiler prefers opApply to range methods, does it?
It should. If it doesn't, that is a bug.
The sole purpose of opApply is to interact with foreach. If it is
masked out, then there is no point for having opApply.
Thanks.
So, if we had this support which I am asking for:
foreach(index, value; range) { }
And, if someone adds opApply to that range, with a different type for
the first variable then an existing foreach (using index, value) is
likely to stop compiling due to type problems.
This seems acceptable to me.
I think any type that does both opApply and range iteration is asking for
problems :) D has a nasty way of choosing all or nothing for overloads,
meaning it may decide this is a range or this is opApply, but if you
have both, it picks one or the other.
I'd rather see it do:
1. can I satisfy this foreach using opApply? If yes, do it.
2. If not, can I satisfy this foreach using range iteration?
This may be how it works, I honestly don't know.
There is an outside chance it might keep on compiling, like if 'i' is
not used in a strongly typed way, i.e. passed to a writefln or similar.
In this case we have silently changed behaviour.
Is this acceptable?
Adding opApply is changing the API of the range. If the range does
something different based on whether you use the range interface or
opApply, then this is a logic error IMO.
The easiest thing is to just not use opApply and range primitives together
:) One separation I like to use in my code is that you use opApply on a
container, but range primitives on a range for that container. And a
container is not a range.
-Steve
Re: Preflight of DUB 0.9.21 (RC 5)
On Thu, 2014-02-20 at 17:04 +0100, Sönke Ludwig wrote: Hopefully the final release candidate has been uploaded. The new RPM package could need some testing: http://code.dlang.org/files/dub-0.9.21-0.rc.5.x86_64.rpm http://code.dlang.org/download The 64-bit Tarball for Linux works for me on Debian Unstable. Haven't had chance to test other things yet. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: switch()
On 2/16/14, Manu turkey...@gmail.com wrote:
requiring an empty 'default: break;' line at the end is annoying and noisy.
Guys, I keep seeing this line being mentioned but you don't actually
have to type break:
-
void main()
{
int x;
switch (x)
{
case 1:
break;
// this works fine
default:
}
}
-
Re: Repost: make foreach(i, a; range) just work
On Fri, 21 Feb 2014 14:29:37 -, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Fri, 21 Feb 2014 06:21:39 -0500, Regan Heath re...@netmail.co.nz
wrote:
On Thu, 20 Feb 2014 17:09:31 -, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Thu, 20 Feb 2014 11:07:32 -0500, Regan Heath re...@netmail.co.nz
wrote:
Only if the compiler prefers opApply to range methods, does it?
It should. If it doesn't, that is a bug.
The sole purpose of opApply is to interact with foreach. If it is
masked out, then there is no point for having opApply.
Thanks.
So, if we had this support which I am asking for:
foreach(index, value; range) { }
And, if someone adds opApply to that range, with a different type for
the first variable then an existing foreach (using index, value) is
likely to stop compiling due to type problems.
This seems acceptable to me.
I think any type that does both opApply and range iteration is asking
for problems :) D has a nasty way of choosing all or nothing for
overloads, meaning it may decide this is a range or this is opApply,
but if you have both, it picks one or the other.
I'd rather see it do:
1. can I satisfy this foreach using opApply? If yes, do it.
2. If not, can I satisfy this foreach using range iteration?
This may be how it works, I honestly don't know.
There is an outside chance it might keep on compiling, like if 'i' is
not used in a strongly typed way, i.e. passed to a writefln or
similar. In this case we have silently changed behaviour.
Is this acceptable?
Adding opApply is changing the API of the range. If the range does
something different based on whether you use the range interface or
opApply, then this is a logic error IMO.
The easiest thing is to just not use opApply and range primitives
together :) One separation I like to use in my code is that you use
opApply on a container, but range primitives on a range for that
container. And a container is not a range.
Makes sense to me. :)
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Repost: make foreach(i, a; range) just work
Steven Schveighoffer wrote in message news:op.xbmyjnnzeav7ka@stevens-macbook-pro.local... I'd rather see it do: 1. can I satisfy this foreach using opApply? If yes, do it. 2. If not, can I satisfy this foreach using range iteration? This may be how it works, I honestly don't know. It is.
Re: More Illuminating Introductory Code Example on dlang.org
On Wednesday, 12 February 2014 at 20:49:54 UTC, Nordlöw wrote: On Wednesday 19:th of Februari I'm giving my first talk on D for my fellow collegues at my consultant firm office HiQ, Linköping, Sweden. If any of you are in the neighbourhood please let me know and I will invite you. The lecture will most likely be held in Swedish. I couldn't make it. How did it go?
Re: Repost: make foreach(i, a; range) just work
On Friday, 21 February 2014 at 11:12:54 UTC, Regan Heath wrote:
- enumerate is not as flexible as many people seem to think.
Only seeing the enumerate missing the ability to optionally add
an index, but if you aren't adding an index you don't need
enumerate.
On Fri, 21 Feb 2014 02:34:28 -, Jesse Phillips
jesse.k.phillip...@gmail.com wrote:
I don't understand how this is complex to support? It's
simple. It's a count, not an index unless the range is
indexable. If people are going to expect an index here, they
will expect one with enumerate as well - and are going to be
equally disappointed. So, they need to be aware of this
regardless.
You've provided 3 schemes to support this feature. This suggest
there are several right ways to bring this into the language,
while you prefer 1 someone may prefer 3.
At least with enumerate one will need to go to the documentation
which explains enumerate doesn't provide an index... I haven't
actually reviewed the docs.
I also don't find myself needing to count iterations very
often, and I believe when I do, it is because I want to use
that count as an index (possibly needing to add to some global
count, but I don't need it enough to remember).
The justification for this change is the same as for enumerate.
It is common enough to make it important, and when it happens
it's frustrating enough that it needs fixing.
I disagree. Enumerate is satisfactory (since it isn't in Phobos I
can see it as frustrating).
For example, I find myself using an index to control loop
behaviour, most often for detecting the first and last
iterations than anything else. A counter will let you do that
just as well as an index.
I wonder if there is a change to the algorithm which would allow
you to not need the first/last iteration. I think this is the
main reason I don't need a count, I've learned different ways to
solve a problem. Which is beneficial since it leads to chaining
functions instead of relying on foreach.
Sure. I personally find this idea compelling enough to warrant
some breakage, it is simple, powerful and extensible and avoids
all the issues of optional indexes with tuple expansion. But,
I can see how someone might disagree.
Yes, I understand. But D is at a stage in its life when not every
little detail can be polished. Believe me, D has other areas
which need polishing but can't be.
string[double] AA;
or something similar, the type system no longer helps. But
again, this seems pretty much uneventful.
Perhaps I wasn't clear, this would work fine:
string[double] AA;
foreach (string v; AA) {} // v is value
foreach (double k; AA) {} // k is key
or am I missing the point you're making?
if AA is changed to a double[string], then your value loop
iterates on keys and your key loop iterates on values.
foreach(i, v1, v2; tuple(0,1).repeat(10).enumerate)
writeln(i, \t, v1, \t, v2);
This works today! And once enumerate is part of Phobos it will
just need an import std.range to use it.
I tested all my claims about enumerate. You need it to import
std.traits or else is(Largest(...)) will always be false.
Re: Ada conference, Ada and Spark
On Friday, 21 February 2014 at 14:27:48 UTC, Paulo Pinto wrote: On Friday, 21 February 2014 at 13:08:37 UTC, Francesco Cattoglio wrote: On Friday, 21 February 2014 at 12:56:32 UTC, Paulo Pinto wrote: That is easy to answer, I doubt they could with their rule of not having more than 5 characters per keyword. :) Wait, what? REALLY? What kind of rule is that. ahahahha... are they stuck to the 70's? :D Yes really, http://forum.dlang.org/post/glnafbocwjodiwrqw...@forum.dlang.org I just cannot find the Reddit thread any longer. That is not true, Rust has several keywords that are more than 5 characters, such as 'continue'. The full list is here: http://static.rust-lang.org/doc/master/rust.html#keywords . It is true that they prefer short keywords over long ones. It used to be the case that 'loop' could mean 'continue' but people found it confusing so it was fixed.
Re: Repost: make foreach(i, a; range) just work
On Fri, 21 Feb 2014 15:35:44 -, Jesse Phillips
jesse.k.phillip...@gmail.com wrote:
You've provided 3 schemes to support this feature. This suggest there
are several right ways to bring this into the language, while you
prefer 1 someone may prefer 3.
Ignore the 3 schemes they were just me thinking about how what I actually
want will affect built in tuple expansion etc.
I want just 1 thing to change (at this time), an index added to foreach
over ranges so that it matches arrays, e.g.
foreach(index, value; range) { }
The code change is likely quite literally just adding an int to the
foreach handler for ranges, passing it to the foreach body, and
incrementing it afterwards. That's it, well, plus the front end code to
bind the variable.
All I am suggesting is that we take what we currently have:
foreach([index, ]value; array) { }
foreach(value; range) { }
foreach(key, value; tuple) { }
and make this possible too:
foreach([index, ]value; range) { }
string[double] AA;
or something similar, the type system no longer helps. But again, this
seems pretty much uneventful.
Perhaps I wasn't clear, this would work fine:
string[double] AA;
foreach (string v; AA) {} // v is value
foreach (double k; AA) {} // k is key
or am I missing the point you're making?
if AA is changed to a double[string], then your value loop iterates on
keys and your key loop iterates on values.
No, I was actually suggesting a change here, the compiler would use type
matching not ordering to assign the variables. So because 'v' is a
string, it is bound to the value not the key.
foreach(i, v1, v2; tuple(0,1).repeat(10).enumerate)
writeln(i, \t, v1, \t, v2);
This works today! And once enumerate is part of Phobos it will just
need an import std.range to use it.
I tested all my claims about enumerate. You need it to import std.traits
or else is(Largest(...)) will always be false.
Thanks! Ok, so how is this working? ahh, ok I think I get it. enumerate
returns a range, whose values are Tuples of index/value where value is
also a tuple so is flattened, and then the whole lot is flattened into the
foreach.
So, while the range foreach only supports:
foreach(value; range) { }
value in this case is a flattened tuple of (index, v1, v2, ...)
Yes?
I had completely forgotten about tuple flattening.
I don't think this affects what I actually want to change, we can have:
foreach(index, value; range) { }
and still flatten tuples into value, you would simply have to provide one
extra variable to get an index.
Make sense?
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Repost: make foreach(i, a; range) just work
On Fri, 21 Feb 2014 09:58:58 -0500, Daniel Murphy yebbliesnos...@gmail.com wrote: Steven Schveighoffer wrote in message news:op.xbmyjnnzeav7ka@stevens-macbook-pro.local... I'd rather see it do: 1. can I satisfy this foreach using opApply? If yes, do it. 2. If not, can I satisfy this foreach using range iteration? This may be how it works, I honestly don't know. It is. Good, thank you for checking! -Steve
Re: Why is int implicitly convertible to ulong?
On 02/21/2014 04:41 AM, Hannes Steffenhagen wrote:
The specific problem here was when working with std.json.
std.json distinguishes between UINTEGER and INTEGER, so I had code like
static if(is(T : ulong)) {
// must be UINTEGER
} else static if(is(T : long)) {
// can be either INTEGER or UINTEGER
}
I've since found out about isSigned and isUnsigned, still it was mighty
confusing for me that the first case was selected for signed types.
I have something like the following in an experimental std.json code
that converts to JSONValue.
Since std.json uses long for the value, I attempt to detect data loss
when the value is a large ulong:
JSONValue to(Target : JSONValue, T)(T value)
{
/* ... */
} else static if (is (T : long)) {
static if (is (T == ulong)) {
enforce(value = long.max,
format(Data loss: %s %s cannot fit a long.,
T.stringof, value));
}
json.type = JSON_TYPE.INTEGER;
json.integer = value;
} else static if (is (T : real)) {
Ali
Re: Formal review of std.lexer
On Friday, 21 February 2014 at 12:12:17 UTC, Dicebot wrote: http://wiki.dlang.org/Review/std.lexer This is follow-up by Brian to his earlier proposal (http://wiki.dlang.org/Review/std.d.lexer). This time proposed module focuses instead on generic lexer generation as discussed in matching voting thread. Docs: http://hackerpilot.github.io/experimental/std_lexer/phobos/lexer.html Code: https://github.com/Hackerpilot/Dscanner/blob/master/stdx/lexer.d Thanks for all the work Brian. Read through the previous threads about the development of this code (links at the bottom) and I can see a lot of effort has gone into it. So the following comments may come across as uninformed, but hopefully they will be helpful. 1. StringCache is a custom hash table. It looks like it's primary role is to reduce some sort of duplication. Hash tables, though, are difficult to get right. So perhaps could a benchmark comparison be made against the built-in HT to show what savings it brings? Since it is in the public interface should its payload also be public? Although it is built using GC.malloc how about the in-the-works std.allocator module? Perhaps a version 1 could use GC.malloc but if a later PR could make it possible to use a custom allocator that would be nice. 2. I like the fact that a range interface is provided. I realize that the previous discussions stipulated the use of ubyte to avoid encoding work during scanning. The reasoning about performance makes sense to me. That being the case, could a code example be provided showing how to use this module to scan a UTF-8 encoded string? Even if this is going to focus only on scanning code files, the D language spec allows for arbitrary Unicode in a code file. How is this possible? (I have a general idea, just looking for some explicit code sample help). 3. I tried to understand the reason for and usage of the extraFields parameter in TokenStructure but couldn't figure it out. Could some more explanation of its intent and usage be provided? 4. Do you want the commented-out pragma statement left over on line 601? 5. Should the template TokenId perhaps be something like generateTokenId instead? I am not sure what an Id for a token means. Is it an integral hash value? Had difficulty seeing how it ties in with the concept of value in the header documentation. If this is a numerical hash of a string token, why is the string still stored and used in tokenStringRepresentation? I probably am missing something big but couldn't the number be used to represent the string everywhere, saving on time and space? 6. I tried but had difficulty understanding the difference between the four token types -- staticTokens, dynamicTokens, possibleDefaultTokens, tokenHandlers -- provided as arguments to Lexer. What is a token that has a value that changes versus a token that does not change? I am not sure where to put my token definitions. 7. Just thinking about using the module and I would like to use it to make a scanner for xml, json, csv, c/c++, etc. I wasn't able to figure out how to do so, however. The initial code example is nice. But could some additional guidance be provided? Also, I wasn't sure how to make use of a lexer once created. The documentation focuses well on how to initialize a Lexer but could some guidance also be provided on how to use one past initialization? 8. Andrei's trie search (http://forum.dlang.org/thread/eeenynxifropasqcu...@forum.dlang.org?page=4#post-l2nm7m:2416e1:241:40digitalmars.com) seemed like a really interesting idea. And I saw in that thread you continued with his ideas. Does this module incorporate that work? Or was it less performant in the end? 9. I ran dmd -cov against the module and got zero percent unit test coverage. Perhaps adding some test code will help clarify usage patterns? You have put a lot of work into this code so I apologize if the above comes across as picking it apart. Just some questions I had in trying to make use of the code. Hopefully some of it is helpful. Joseph Other related posts http://forum.dlang.org/thread/jsnhlcbulwyjuqcqo...@forum.dlang.org http://forum.dlang.org/thread/dpdgcycrgfspcxenz...@forum.dlang.org http://forum.dlang.org/thread/eeenynxifropasqcu...@forum.dlang.org
Re: Correct comparison of signed type with unsigned type (and vice versa)
On Friday, 21 February 2014 at 10:45:50 UTC, ponce wrote: I don't see this as a bug, this is exactly what I expect from a language with intact C integer semantics. I didn't call it a bug. I said that it's prone to causing bugs. That subtly breaks C compatibility. Personally, I wish we would drop some of the C semantics and allow the language evolve. In it's place, add a function attribute which would enable C semantics for the sake of migrating code. Currently in C the unsigned vs signed operations all follow the same rules. If you do this, would you also disallow unsigned vs signed addition, subtraction, divide? Unfortunately, those operations don't have such simple solutions. D is a statically typed language and the compiler simply can't predict what the resultant type should be. However, comparisons do have a simple fix with minimal overhead.
Re: Implement the unum representation in D ?
On Friday, 21 February 2014 at 09:04:40 UTC, Ivan Kazmenko wrote: I believe that the repeating decimals, or better, repeating binary fractions, will hardly be more useful than a rational representation like p/q. Yeah, in retrospect I would say that a binary layout like: numberator length | +- | numerator | divisor Might be a stronger solution, or at least one which offers different advantages over what we have today. It still wouldn't be able to represent pi accurately, since it isn't a rational number, but I wouldn't be surprised if a rational number exists that could be represented than can be represented in IEEE format.
Re: Ada conference, Ada and Spark
On Friday, 21 February 2014 at 17:25:48 UTC, Francesco Cattoglio wrote: On Friday, 21 February 2014 at 15:57:32 UTC, Thiez wrote: That is not true, Rust has several keywords that are more than 5 characters, such as 'continue'. The full list is here: http://static.rust-lang.org/doc/master/rust.html#keywords . It is true that they prefer short keywords over long ones. I knew there was no hard-coded limit, but this try to keep keywords short sounds really stupid to me. No offence to designers, but I really don't think we should save some spar characters in 2014... I do all my coding on a remote SSH, but still I have plenty of screen space to spare ;) My first glance: priv instead of private... bleah! At least it's clear enough mut... what is this? mutable, mutex, perhaps mute? impl could be several different things, too, but I guess it's implements And continue being a different keyword some time ago. In the end they changed it. Tons of discussions and stuff; was it worth saving 3 characters, after all? I hope their standard library is at least WAY more verbose... Otherwise I pity casual Rust programmers :D Depends on how often and where you write those keywords. mut seems to be quite common and even in D I would not like 'reference' more than 'ref', especially since it is used in parameter lists.
Re: Ada conference, Ada and Spark
On Friday, 21 February 2014 at 14:27:48 UTC, Paulo Pinto wrote: On Friday, 21 February 2014 at 13:08:37 UTC, Francesco Cattoglio wrote: On Friday, 21 February 2014 at 12:56:32 UTC, Paulo Pinto wrote: That is easy to answer, I doubt they could with their rule of not having more than 5 characters per keyword. :) Wait, what? REALLY? What kind of rule is that. ahahahha... are they stuck to the 70's? :D Yes really, http://forum.dlang.org/post/glnafbocwjodiwrqw...@forum.dlang.org I just cannot find the Reddit thread any longer. Obviously, there is no rule in Rust that keywords have no more than 5 letters (return, extern, ...) but the designers favor short keywords, maybe a bit much for my taste. OTOH, I prefer their preference for favoring immutability and expression oriented style to D's statement oriented preference. The latest version of Ada tries to fix Ada a bit in this regard http://www.ada-auth.org/standards/12rat/html/Rat12-1-3-2.html but it's a bit late. I'm glad to hear that Ada use is increasing somewhere, but I don't see it in any market I look at. The Rust designers are targetting C and C++ users, with a different vision than Walter and Andrei's as to what constitutes C++ done right, and some specific applications, like Servo. -- Brian
Re: Formal review of std.lexer
On 2014-02-21 18:06, Andrei Alexandrescu wrote: Can we please defer this by one week? Just make the review period one week longer. -- /Jacob Carlborg
Re: Ada conference, Ada and Spark
On Friday, 21 February 2014 at 15:57:32 UTC, Thiez wrote: That is not true, Rust has several keywords that are more than 5 characters, such as 'continue'. The full list is here: http://static.rust-lang.org/doc/master/rust.html#keywords . It is true that they prefer short keywords over long ones. I knew there was no hard-coded limit, but this try to keep keywords short sounds really stupid to me. No offence to designers, but I really don't think we should save some spar characters in 2014... I do all my coding on a remote SSH, but still I have plenty of screen space to spare ;) My first glance: priv instead of private... bleah! At least it's clear enough mut... what is this? mutable, mutex, perhaps mute? impl could be several different things, too, but I guess it's implements And continue being a different keyword some time ago. In the end they changed it. Tons of discussions and stuff; was it worth saving 3 characters, after all? I hope their standard library is at least WAY more verbose... Otherwise I pity casual Rust programmers :D
Re: Formal review of std.lexer
On 2/21/14, 2:12 PM, Dicebot wrote: http://wiki.dlang.org/Review/std.lexer This is follow-up by Brian to his earlier proposal (http://wiki.dlang.org/Review/std.d.lexer). This time proposed module focuses instead on generic lexer generation as discussed in matching voting thread. Docs: http://hackerpilot.github.io/experimental/std_lexer/phobos/lexer.html Code: https://github.com/Hackerpilot/Dscanner/blob/master/stdx/lexer.d Example topics to evaluate during review: - Feasibility of overall design and concept - Quality of documentation - Consistency with existing Phobos modules - Overall quality of implementation Initial review will end on March the 8th. Can we please defer this by one week? Thanks, Andrei
Re: Repost: make foreach(i, a; range) just work
On Fri, 21 Feb 2014 10:02:43 +, Regan Heath wrote:
On Thu, 20 Feb 2014 16:30:42 -, Justin Whear
jus...@economicmodeling.com wrote:
On Thu, 20 Feb 2014 13:04:55 +, w0rp wrote:
More importantly, this gets in the way of behaviour which may be
desirable later, foreach being able to unpack tuples from ranges.
I would like if it was possible to return Tuple!(A, B) from front()
and write foreach(a, b; range) to interate through those thing,
unpacking the values with an alias, so this...
foreach(a, b; range) {
}
... could rewrite to roughly this. (There may be a better way.)
foreach(_someInternalName; range) {
alias a = _someInternalName[0];
alias b = _someInternalName[1];
}
Tuple unpacking already works in foreach. This code has compiled since
at least 2.063.2:
import std.stdio;
import std.range;
void main(string[] args)
{
auto tuples = [a, b, c].zip(iota(0, 3));
// unpack the string into `s`, the integer into `i`
foreach (s, i; tuples)
writeln(s, , , i);
}
Does this work for more than 2 values? Can the first value be something
other than an integer?
R
Yes to both questions. In the following example I use a four element
tuple, the first element of which is a string:
import std.stdio;
import std.range;
void main(string[] args)
{
auto tuples = [a, b, c].zip(iota(0, 3), [1.2, 2.3, 3.4], ['x',
'y', 'z']);
foreach (s, i, f, c; tuples)
writeln(s, , , i, , , f, , , c);
}
Compiles with dmd 2.063.2
Re: Ada conference, Ada and Spark
Am 21.02.2014 16:57, schrieb Thiez: On Friday, 21 February 2014 at 14:27:48 UTC, Paulo Pinto wrote: On Friday, 21 February 2014 at 13:08:37 UTC, Francesco Cattoglio wrote: On Friday, 21 February 2014 at 12:56:32 UTC, Paulo Pinto wrote: That is easy to answer, I doubt they could with their rule of not having more than 5 characters per keyword. :) Wait, what? REALLY? What kind of rule is that. ahahahha... are they stuck to the 70's? :D Yes really, http://forum.dlang.org/post/glnafbocwjodiwrqw...@forum.dlang.org I just cannot find the Reddit thread any longer. That is not true, Rust has several keywords that are more than 5 characters, such as 'continue'. The full list is here: http://static.rust-lang.org/doc/master/rust.html#keywords . It is true that they prefer short keywords over long ones. It used to be the case that 'loop' could mean 'continue' but people found it confusing so it was fixed. What I was arguing in that old thread was things like pub vs public, mut vs mutable and so on. I have a strong ML background as my university teachers were quite found of ML and we had a few courses using Caml Light. So I do like Rust and my issue back then was why to short those keywords and similar. Then again as I come from Pascal family of languages and always liked a bit verbosity, instead of the write only way of C. -- Paulo
Re: Implement the unum representation in D ?
On Friday, 21 February 2014 at 07:42:36 UTC, francesco cattoglio wrote: On Friday, 21 February 2014 at 05:21:53 UTC, Frustrated wrote: I think though adding a repeating bit would make it even more accurate so that repeating decimals within the bounds of maximum bits used could be represented perfectly. e.g., 1/3 = 0.... could be represented perfectly with such a bit and sliding fp type. With proper cpu support one could have 0.... * 3 = 1 exactly. By having two extra bits one could represent constants to any degree of accuracy. e.g., the last bit says the value represents the ith constant in some list. This would allow very common irrational constants to be used: e, pi, sqrt(2), etc... Unfortunately maths (real world maths) isn't made by common constants. More, such a repeating bit should become a repeating counter, since you usually get a certain number of repeating digits, not just a single one. I disagree. Many computations done by computers involve constants in the calculation... pi, e, sqrt(2), sqrt(-1), many physical constants, etc. The cpu could store these constants at a higher bit resolution than standard, say 128 bits or whatever. For floating points, the 3rd last bit could represent a repeating decimal or they could be used in the constants for common repeating decimals. (since chances are, repeated calculations would not produce repeating decimals) Things like those are cool and might have their application (I'm thinking mostly at message passing via TCP/IP), but have no real use in scientific computation. If you want good precision, you might as well be better off with bignum numbers. Simply not true. Maple, for example, uses constants and can compute using constants. It might speed up the calculations significantly if one could compute at the cpu level using constants. e.g. pi*sqrt(2) is just another constant. 2*pi is another constant. Obviously there is a limit to the number of constants one can store but one can encode many constants easily without storage. (where the index itself is used as the value) Also, the cpu could reduce values to constants... so if you have a fp value that is 3.14159265. or whatever, the cpu could convert this to the constant pi since for all purposes it is pi(even if it is just an approximation or pi - 1/10^10). Basically the benefit of this(and potential) outweigh the cost of 1 bit out of 64-bits. I doubt anyone would miss it. In fact, probably no real loss NaN could be a constant, in which case you would have only one rather than the 2 billion or whatever you have now).
Re: Repost: make foreach(i, a; range) just work
On Friday, 21 February 2014 at 16:41:00 UTC, Regan Heath wrote:
and make this possible too:
foreach([index, ]value; range) { }
I understand the user interface is simple, but you created 3
statements about how it could be achieved and work/not work with
the existing setup. Each have their positives and negatives, it
would not make sense to just choose one and hope it all works
out.
if AA is changed to a double[string], then your value loop
iterates on keys and your key loop iterates on values.
No, I was actually suggesting a change here, the compiler would
use type matching not ordering to assign the variables. So
because 'v' is a string, it is bound to the value not the key.
And string is the key, double[string] is not the same as
string[double].
Also string[string], ambiguous yet common.
There are many things to consider when adding a feature, it is
not good to ignore what can go wrong.
Thanks! Ok, so how is this working? ahh, ok I think I get it.
enumerate returns a range, whose values are Tuples of
index/value where value is also a tuple so is flattened, and
then the whole lot is flattened into the foreach.
Sounds like you understand it, seams foreach will flatten all
tuples.
I don't think this affects what I actually want to change, we
can have:
foreach(index, value; range) { }
and still flatten tuples into value, you would simply have to
provide one extra variable to get an index.
Make sense?
Yes, but I'm saying we don't need it because
foreach(index, value; range.enumerate) { }
is good enough. Not perfect, but good enough.
Re: More Illuminating Introductory Code Example on dlang.org
On Wednesday, 12 February 2014 at 20:49:54 UTC, Nordlöw wrote: What do you think, fellow D programmers? What are the odds of getting a color-enabled terminal output? We could try to produce some simple ascii art :D
Re: Formal review of std.lexer
On Friday, 21 February 2014 at 17:15:41 UTC, Jacob Carlborg wrote: On 2014-02-21 18:06, Andrei Alexandrescu wrote: Can we please defer this by one week? Just make the review period one week longer. This. There is no real rationale behind existing default review period so extending it until March the 15th won't cause any issues.
Re: Formal review of std.lexer
Does this mean that you're finally getting approval to release your lexer generator? On Friday, 21 February 2014 at 17:06:23 UTC, Andrei Alexandrescu wrote: Can we please defer this by one week? Thanks, Andrei
Re: Implement the unum representation in D ?
On Friday, 21 February 2014 at 19:12:39 UTC, Frustrated wrote: Simply not true. Maple, for example, uses constants and can compute using constants. You are mixing symbolic calculus and numerical computations. The two are completely unrelated. Basically the benefit of this(and potential) outweigh the cost of 1 bit out of 64-bits. Unless I'm completely mistaken, what you are proposing is basically creating a tagged union type. It's pretty much unrelated from the unum proposed by the PDF.
Re: Ada conference, Ada and Spark
On 21 February 2014 20:00, Tobias Pankrath tob...@pankrath.net wrote: Depends on how often and where you write those keywords. mut seems to be quite common and even in D I would not like 'reference' more than 'ref', especially since it is used in parameter lists. I think Rust's pub, priv and fn are just silly. But I don't mind mut. However it might've been nicer if you didn't have to write let mut but just mut. What made Rust a no-go for me was when I tried to write a generic sort. I still can't figure out how to swap two elements in an array (vector). The implementation in their std lib for swap has an unsafe block... (And I don't want a GC or RC requirement for the array.)
Re: Implement the unum representation in D ?
On Friday, 21 February 2014 at 19:59:36 UTC, Francesco Cattoglio wrote: On Friday, 21 February 2014 at 19:12:39 UTC, Frustrated wrote: Simply not true. Maple, for example, uses constants and can compute using constants. You are mixing symbolic calculus and numerical computations. The two are completely unrelated. Basically the benefit of this(and potential) outweigh the cost of 1 bit out of 64-bits. Unless I'm completely mistaken, what you are proposing is basically creating a tagged union type. It's pretty much unrelated from the unum proposed by the PDF. Yes, I mentioned that would could extend floating points to include other representations that are more efficient and reduce errors and such.
Re: Implement the unum representation in D ?
On Friday, 21 February 2014 at 09:04:40 UTC, Ivan Kazmenko wrote: On Friday, 21 February 2014 at 05:21:53 UTC, Frustrated wrote: I think though adding a repeating bit would make it even more accurate so that repeating decimals within the bounds of maximum bits used could be represented perfectly. e.g., 1/3 = 0.... could be represented perfectly with such a bit and sliding fp type. With proper cpu support one could have 0.... * 3 = 1 exactly. I believe that the repeating decimals, or better, repeating binary fractions, will hardly be more useful than a rational representation like p/q. The reason is, if we take a reciprocal 1/q and represent it as a binary, decimal, or other fixed-base fraction, the representation is surely periodic, but the upper bound on the length of its period is as high as q-1, and it is not unlikely to be the exact bound. For example, at http://en.wikipedia.org/wiki/Binary_number#Fractions , note that the binary fraction for 1/11 has period 10, and for 1/13 the period is 12. Thus repeating decimal for a fraction p/q will take up to q-1 bits when we store it as a repeating decimal, but log(p)+log(q) bits when stored as a rational number (numerator and denominator). No, you are comparing apples to oranges. The q is not the same in both equations. The number of bits for p/q when p and q are stored separately is log[2](p) + log[2](q). But when p/q is stored as a repeating decimal(assuming it repeats), then it is a fixed constant dependent on the number of bits. So in some cases the rational expression is cheaper and in other cases the repeating decimal is cheaper. e.g., .1 in theory could take 1 bit to represent wile 1/9 takes 1 + 4 = 5. (the point being is that the rational representation sometimes takes way more bits than the repeating decimal representation, other times it doesn't. Basically if we use n bits to represent the repeating decimal we can't represent repetitions that require more than n bits, in this case a rational expression may be cheaper. If we use some type of compression then rational expressions would, in general, be cheaper the larger n is. e.g., 1/9 takes 5 bits to represent as as a rational faction(4 if we require the numerator to be 1). 0.1 takes 1 bit to represent in theory but for n bits, it takes n bits. e.g., 1/9 = /10^8 = 0.000111... in decimal. Which takes 6 bits to store(000111). If n was large and fixed then I think statistically it would be best to use rational expressions rather than repeating decimals. But rational expressions are not unique and that may cause some problems with representation... unless the cpu implemented some algorithms for reduction. 1/9 = 10/90 but 10/90 takes way more bits to represent than 1/9 even though they represent the same repeating decimal and the repeating decimals bits are fixed. In any case, if the fpu had a history of calculations it could potentially store the calculations in an expression tree and attempt to reduce them. e.g., p/q*(q/p) = 1. A history could also be useful for constants in that multiplying several constants together could produce a new constant which would not introduce any new accumulation errors.
Future of D on alternate platforms
How difficult is it to port D code to future projects on alternate platforms(mainly coming from win) and, if needed be, a compiler for those platforms? At this point, I'm wondering how difficult code I'm writing for windows will be to port to, say, the iOS, mac, arm, and more likely, embedded systems such as the tigerSharc, etc. I've heard many times the LLVM compiler mentioned in the forums and it seems to be able to compile D code to any platform the compiler supports(but somehow independent of D... maybe it compiles it to an intermediate language?). My goal at this point is to use D on windows to create some algorithmic software and then potentially port it to some embedded system with minimal rewrite of the core code. e.g., I don't want to have to rewrite the algorithms in C and use the compiler tools for that system. If that was the case there is little reason to use D in the first place. Obviously there is no magic compiler that will do it all. I'm curious though as to the possibility. In 2 years could one expect D to be more widely used on other systems? I see people already getting D started on ARM and iOS so it seems feasible that in the near future it would be relatively easy to port the code(obviously there are functional differences due to the OS but I'm talking about the cpu issues at this point).
Re: More Illuminating Introductory Code Example on dlang.org
On Friday, 21 February 2014 at 16:06:04 UTC, NVolcz wrote: On Wednesday, 12 February 2014 at 20:49:54 UTC, Nordlöw wrote: On Wednesday 19:th of Februari I'm giving my first talk on D for my fellow collegues at my consultant firm office HiQ, Linköping, Sweden. If any of you are in the neighbourhood please let me know and I will invite you. The lecture will most likely be held in Swedish. I couldn't make it. How did it go? It went great! At least four of them said they will start hacking D as soon as they get the time. I will be holding more lectures in Linköping if I get the chance. Here's a reference to my lecture notes: https://drive.google.com/file/d/0BySO22MoUSXDZlBsVzllX1hsWjg/edit?usp=sharing Please correct anything if you get the chance. There's also the Facebook group Software Craftsmanship Group Linköping you could follow at https://www.facebook.com/groups/493309790788180/ /Per
