Re: dmd 2.065 beta 1 #2
On 2014-01-22 01:19, Leandro Lucarella wrote: Why not use semver? http://semver.org/ 2.65.0-b1 2.65.0-rc1 2.65.0 2.65.1 Then you would have versions number looking like this: 3.0.0 4.0.0 5.0.0 If we don't want to add a fourth digit. -- /Jacob Carlborg
Re: dmd 2.065 beta 1 #2
El 22/01/14 02:06, Andrew Edwards ha escrit: > On 1/21/14, 6:02 PM, Jordi Sayol wrote: >> El 21/01/14 23:29, Brad Anderson ha escrit: >>> #.###.~b# ==> 2.065.b1 // beta >>> #.###.~rc# ==> 2.065.rc1 // release candidate >>> #.###.0 ==> 2.065.0 // initial release >>> #.###.# ==> 2.065.1 // hotfix >> >> On Debian, "2.065.rc1" is bigger than "2.065.0", so if >> "dmd_2.065.rc1-0_amd64.deb" is installed and you try to upgrade to >> "dmd_2.065.0-0_amd64.deb", system will answer something like "You have >> installed a newer version". >> >> No problem if these deb packages are for internal use and test, but not for >> a public download. >> >> $ dpkg --compare-versions "2.065.0" gt "2.065.rc1" && echo "Bigger" || echo >> "Not bigger" >> > > Apparently the same problem exists on FreeBSD. The first solution that comes > to mind is to prefix the qualifiers for betas and release candidates with a > tilde. As such: > > 2.065~b1 > 2.065~rc1 > > or: > > 2.065.~b1 > 2.065.~rc1 > > This solution works on both Ubuntu and FreeBSD but I'm not sure it is the > right one. Suggestions are welcomed. I prefer: 2.65~b1 2.65~rc1 because "2.65.0" and "2.65" are bigger than "2.65~rc1", regardless if "qualifier" number is present or not in final release version. I think that, as much as possible, we should use exactly the same version string for all installers, zip, deb, rpm, dmg, etc. So if there is no problem on OSX, Windows, etc. I propose this versioning scheme: #.#~b# ==> 2.65~b1 // beta #.#~rc# ==> 2.65~rc1 // release candidate #.#.# ==> 2.65.0 // initial release #.#.# ==> 2.65.1 // hotfix -- Jordi Sayol
Re: dmd 2.065 beta 1 #2
On Wednesday, 22 January 2014 at 08:25:05 UTC, Jordi Sayol wrote: I prefer: 2.65~b1 2.65~rc1 because "2.65.0" and "2.65" are bigger than "2.65~rc1", regardless if "qualifier" number is present or not in final release version. I think that, as much as possible, we should use exactly the same version string for all installers, zip, deb, rpm, dmg, etc. So if there is no problem on OSX, Windows, etc. I propose this versioning scheme: #.#~b# ==> 2.65~b1 // beta #.#~rc# ==> 2.65~rc1 // release candidate #.#.# ==> 2.65.0 // initial release #.#.# ==> 2.65.1 // hotfix Please, this has been discussed to death already. Nobody care what anybody prefers. Unless you have an actual reason to ask for a format change (fit better with current packaging systems for instance) please restrain yourself.
Re: dmd 2.065 beta 1 #2
On 2014-01-21 23:22, Andrew Edwards wrote: ftp://ftp.digitalmars.com/dmd.2.065.b1.zip I manged to open this with the zip moulde in Tango now :) The previous beta failed. ftp://ftp.digitalmars.com/dmd.2.065.b1.dmg The installer is old. The text contains links to D1. The content seem to be correct though. How are you building the installer. -- /Jacob Carlborg
Re: dmd 2.065 beta 1 #2
El 22/01/14 09:31, deadalnix ha escrit: > On Wednesday, 22 January 2014 at 08:25:05 UTC, Jordi Sayol wrote: >> I prefer: >> >> 2.65~b1 >> 2.65~rc1 >> >> because "2.65.0" and "2.65" are bigger than "2.65~rc1", regardless if >> "qualifier" number is present or not in final release version. >> >> I think that, as much as possible, we should use exactly the same version >> string for all installers, zip, deb, rpm, dmg, etc. >> So if there is no problem on OSX, Windows, etc. I propose this versioning >> scheme: >> >> #.#~b# ==> 2.65~b1 // beta >> #.#~rc# ==> 2.65~rc1 // release candidate >> #.#.# ==> 2.65.0 // initial release >> #.#.# ==> 2.65.1 // hotfix > > Please, this has been discussed to death already. Nobody care what anybody > prefers. Unless you have an actual reason to ask for a format change (fit > better with current packaging systems for instance) please restrain yourself. > Please, if you don't like this proposed change based on a real problem on Debian and not on my "prefers", refute it with arguments but do not tell me that I should keep quiet. -- Jordi Sayol
Re: So, You Want To Write Your Own Programming Language?
On 2014-01-22 05:29, Walter Bright wrote: http://www.reddit.com/r/programming/comments/1vtm2l/so_you_want_to_write_your_own_language_dr_dobbs/ From the article: "Regex is just the wrong tool for lexing and parsing." I'm wonder why is there so many books about implementing compilers that spends, usually, quite a large chapter about regular expressions? -- /Jacob Carlborg
Re: So, You Want To Write Your Own Programming Language?
Walter Bright: http://www.reddit.com/r/programming/comments/1vtm2l/so_you_want_to_write_your_own_language_dr_dobbs/ Thank you for the simple nice article. The poisoning approach. [...] This is the approach we've been using in the D compiler, and are very pleased with the results.< Yet, even in D most of the error messages after the first few ones are often not so useful to me. So perhaps I'd like a compiler switch to show only the first few error messages and then stop the compiler. Automated documentation generator. [...] Before Ddoc, the documentation had only a random correlation with the code, and too often, they had nothing to do with each other. After Ddoc, the two were brought in sync.< And now the situation is even better, we have documentation unittests and the function arguments are verified to be in sync with their ddoc comment. Probably there's some space for further improvements. One semantic technique that is obvious in hindsight (but took Andrei Alexandrescu to point out to me) is called "lowering."< In Haskell the GHC compiler goes one step further, it translates all the Haskell code into an intermediate code named Core, that is not the language of a virtual machine, it's still a functional language, but it's simpler, lot of the syntax differences between language constructs is reduced to a much reduced number of mostly functional stuff. My general rule is if the explanation for what the function does is more lines than the implementation code, then the function is likely trivia and should be booted out.< In Haskell there's a standard module named Prelude, it's imported on default and defined lot of functions, etc of general use. Most functions in it are only few lines long (often 2-3 lines long, with some functions up to 10-13 lines long). Bonus: the cute idea of a language for students: http://www.iro.umontreal.ca/~felipe/IFT2030-Automne2002/Complements/tinyc.c (On Reddit I seem to see some comments, like structs not allowing constructors?) Bye, bearophile
Re: So, You Want To Write Your Own Programming Language?
On Wednesday, 22 January 2014 at 10:36:31 UTC, Jacob Carlborg wrote: I'm wonder why is there so many books about implementing compilers that spends, usually, quite a large chapter about regular expressions? I wonder about that too. For anything halfway useful regex has too much limitations. Wich you only find out in later chapter or pretty soon in your parser :D
Re: So, You Want To Write Your Own Programming Language?
On Wednesday, 22 January 2014 at 04:29:05 UTC, Walter Bright wrote: http://www.reddit.com/r/programming/comments/1vtm2l/so_you_want_to_write_your_own_language_dr_dobbs/ "A good syntax needs redundancy in order to diagnose errors and give good error messages." This is also true of natural languages. The higher the redundancy, the easier it is to guess or reconstruct what a person tried to say (in a noisy environment) or write (if the message gets messed up somehow). Texts in highly inflectional languages (like German) can be "recovered" with higher accuracy than texts in English. If grammatical relations are no longer expressed by inflectional endings (as is often the case in English), the word order is crucial. "The dog bit the man." In Latin and German you can turn the statement around and still know who bit who(m). Over the centuries, natural languages have reduced redundancy, but there are still loads of redundancies e.g. "two cats" (it would be enough to say "two cat", which some languages actually do, see also "a 15 _year_ old girl). Syntax is getting simplified due to the fact that the listener "knows what we mean", e.g. "buy one get one free". I wonder to what extent languages will be simplified one day. But this is a topic for a whole book ...
Re: dmd 2.065 beta 1 #2
On 2014-01-21 23:22, Andrew Edwards wrote: Due to building an packaging requirements and a need to address the concerns of the community, I changed the naming convention for this and all future releases. The following is our new naming convention: major.minor.qualifier Examples follow: #.###.b# ==> 2.065.b1 // beta #.###.rc# ==> 2.065.rc1 // release candidate #.###.0 ==> 2.065.0 // initial release #.###.# ==> 2.065.1 // hotfix Consequently, the name for the previously announced beta has changed. Additionally, installers were prepared and made available. They are as follows: ftp://ftp.digitalmars.com/dmd.2.065.b1.zip Regression: https://d.puremagic.com/issues/show_bug.cgi?id=11966 -- /Jacob Carlborg
Re: So, You Want To Write Your Own Programming Language?
On Wednesday, 22 January 2014 at 04:29:05 UTC, Walter Bright wrote: http://www.reddit.com/r/programming/comments/1vtm2l/so_you_want_to_write_your_own_language_dr_dobbs/ Great article!
Re: So, You Want To Write Your Own Programming Language?
Chris: "A good syntax needs redundancy in order to diagnose errors and give good error messages." I'd like to measure this statement experimentally: are error messages in Go and Scala any worse because of the optional use of semicolons? My initial supposition is that the answer is negative. Bye, bearophile
Re: dmd 2.065 beta 1 #2
On 1/22/14, 3:38 AM, Jacob Carlborg wrote: On 2014-01-21 23:22, Andrew Edwards wrote: ftp://ftp.digitalmars.com/dmd.2.065.b1.dmg The installer is old. The text contains links to D1. The content seem to be correct though. How are you building the installer. That might be the case. I'm following the instructions here: https://github.com/D-Programming-Language/installer/tree/master/osx Last update was over 9 months ago.
Re: So, You Want To Write Your Own Programming Language?
On Wednesday, 22 January 2014 at 04:29:05 UTC, Walter Bright wrote: http://www.reddit.com/r/programming/comments/1vtm2l/so_you_want_to_write_your_own_language_dr_dobbs/ Great article. I was surprised that you mentioned lowering positively, though. I think from DMD we have enough experience to say that although lowering sounds good, it's generally a bad idea. It gives you a mostly-working prototype very quickly, but you pay a heavy price for it. It destroys valuable semantic information. You end up with poor quality error messages, and counter-intuitively, you can end up with _more_ special cases (eg, lowering ref-foreach in DMD means ref local variables can spread everywhere). And it reduces possibilities for the optimizer. In DMD, lowering has caused *major* problems with AAs, foreach. and builtin-functions, and some of the transformations that the inliner makes. It's also caused problems with postincrement and exponentation. Probably there are other examples. It seems to me that what does make sense is to perform lowering as the final step before passing the code to the backend. If you do it too early, you're shooting yourself in the foot.
Re: dmd 2.065 beta 1 #2
Andrew Edwards, el 21 de January a las 20:06 me escribiste:
> On 1/21/14, 6:02 PM, Jordi Sayol wrote:
> >El 21/01/14 23:29, Brad Anderson ha escrit:
> >> #.###.~b# ==> 2.065.b1 // beta
> >> #.###.~rc# ==> 2.065.rc1 // release candidate
> >> #.###.0 ==> 2.065.0 // initial release
> >> #.###.# ==> 2.065.1 // hotfix
> >
> >On Debian, "2.065.rc1" is bigger than "2.065.0", so if
> >"dmd_2.065.rc1-0_amd64.deb" is installed and you try to upgrade to
> >"dmd_2.065.0-0_amd64.deb", system will answer something like "You have
> >installed a newer version".
> >
> >No problem if these deb packages are for internal use and test, but not for
> >a public download.
> >
> >$ dpkg --compare-versions "2.065.0" gt "2.065.rc1" && echo "Bigger" || echo
> >"Not bigger"
> >
>
> Apparently the same problem exists on FreeBSD. The first solution
> that comes to mind is to prefix the qualifiers for betas and release
> candidates with a tilde. As such:
>
> 2.065~b1
> 2.065~rc1
>
> or:
>
> 2.065.~b1
> 2.065.~rc1
>
> This solution works on both Ubuntu and FreeBSD but I'm not sure it
> is the right one. Suggestions are welcomed.
There is a fairly popular de-facto standard for versioning: semver. Yes,
it is incompatible with Debian (and I guess FreeBSD) but you can make
it compatible by just changing one character ("-" -> "~").
Since apparently a version naming scheme is needed, does anyone have
a good reason NOT to use a standard that's easily adaptable to several
popular distributions?
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
Re: So, You Want To Write Your Own Programming Language?
On Wednesday, 22 January 2014 at 11:59:30 UTC, bearophile wrote: I'd like to measure this statement experimentally: are error messages in Go and Scala any worse because of the optional use of semicolons? My initial supposition is that the answer is negative. Error messages in SML are either really neat or catastrophic.
Re: dmd 2.065 beta 1
On Tuesday, 21 January 2014 at 20:48:27 UTC, Andrew Edwards wrote: On 1/21/14, 2:20 PM, Dejan Lekic wrote: Can we *please* have a well-established, useful, naming scheme for tags and packages? 2.064beta3, 2.064beta4, 2.064.2, 2.065-b1... Are you as frustrated as me? I was just in the process of addressing this. Based on recent issues with using the packaging scripts, I've changed the naming convention as follows: #.###.b#// beta #.###.rc# // release candidate #.#.0 // release #.#.# // hotfix (where last # != 0) That should solve any issues you may have. That is absolutely briliant Andrew! Now we can use my SPEC file to build new DMD RPMs whenever there is a new release (tag) on GitHub!
Re: So, You Want To Write Your Own Programming Language?
On Wednesday, 22 January 2014 at 10:38:40 UTC, bearophile wrote: In Haskell the GHC compiler goes one step further, it translates all the Haskell code into an intermediate code named Core, that is not the language of a virtual machine, it's still a functional language, but it's simpler, lot of the syntax differences between language constructs is reduced to a much reduced number of mostly functional stuff. Same story is with Erlang as far as I know.
Re: dmd 2.065 beta 1 #2
On 2014-01-22 13:16, Andrew Edwards wrote: That might be the case. I'm following the instructions here: https://github.com/D-Programming-Language/installer/tree/master/osx Last update was over 9 months ago. I just noticed an error in the Makefile. I'll create a pull request. -- /Jacob Carlborg
Re: dmd 2.065 beta 1 #2
I'm getting deprecation warnings inside std.datetime to use "any" instead of "canFind". Also DMD now warns about using FP operators, such as <>=, for detecting NaN's. What's the rationale for this? One issue with this is that isNaN cannot be used for CTFE. There is also a build issue that sometimes occurred at the same place in 2.064 in the form of template instantiation failures and now produces linker errors: https://github.com/rejectedsoftware/vibe.d/issues/458 Finally, I'm getting some "recursive alias" errors that I managed to circumvent in previous releases. I'm going to run dustmite on these two and create bugzilla issues.
Re: dmd 2.065 beta 1 #2
On 2014-01-22 13:16, Andrew Edwards wrote: That might be the case. I'm following the instructions here: https://github.com/D-Programming-Language/installer/tree/master/osx Last update was over 9 months ago. https://github.com/D-Programming-Language/installer/pull/44 -- /Jacob Carlborg
Re: dmd 2.065 beta 1 #2
On 2014-01-21 23:22, Andrew Edwards wrote:
Due to building an packaging requirements and a need to address the
concerns of the community, I changed the naming convention for this and
all future releases.
I'm getting some regressions when compiling Tango. I filed one bug
report but having trouble creating a reduced test case for the other one.
The error I get is:
Regex.d(2524): Error: associative array key type TagIndex does not have
'const int opCmp(ref const TagIndex)' member function
Regex.d(3676): Error: template instance tango.text.Regex.TDFA!dchar
error instantiating
Regex.d(4420):instantiated from here: RegExpT!char
Regex.d(4407): Error: tdfa_t.Command is used as a type
Regex.d(4420): Error: template instance tango.text.Regex.RegExpT!char
error instantiating
TagIndex looks like this:
struct TagIndex
{
uint tag, index;
}
And it's used in an associative array:
uint[TagIndex] registers;
--
/Jacob Carlborg
Re: std.signal : voting results
The new std.signal is IMHO far better than the old one. Why not simply replace it, and then look forward to future improvements?
Re: So, You Want To Write Your Own Programming Language?
On Wednesday, 22 January 2014 at 10:38:40 UTC, bearophile wrote: Walter Bright: http://www.reddit.com/r/programming/comments/1vtm2l/so_you_want_to_write_your_own_language_dr_dobbs/ Thank you for the simple nice article. The poisoning approach. [...] This is the approach we've been using in the D compiler, and are very pleased with the results.< Yet, even in D most of the error messages after the first few ones are often not so useful to me. So perhaps I'd like a compiler switch to show only the first few error messages and then stop the compiler. Could you give an example? We've tried very hard to avoid useless error messages, there should only be one error message for each bug in the code. Parser errors still generate a cascade of junk, and the "cannot deduce function from argument types" message is still painful -- is that what you mean? Or something else?
Re: std.signal : voting results
On Wednesday, 22 January 2014 at 14:18:15 UTC, Dejan Lekic wrote: The new std.signal is IMHO far better than the old one. Why not simply replace it, and then look forward to future improvements? Guys, were are you was a few days ago when voting still was open?! Dicebot, can we continue voting at least 1-2 weeks? It looks like we finally have interest to the `std.signal` module.
Re: std.signal : voting results
ilya-stromberg píše v St 22. 01. 2014 v 14:38 +: > On Wednesday, 22 January 2014 at 14:18:15 UTC, Dejan Lekic wrote: > > The new std.signal is IMHO far better than the old one. Why not > > simply replace it, and then look forward to future improvements? > > Guys, were are you was a few days ago when voting still was open?! > > Dicebot, can we continue voting at least 1-2 weeks? It looks like > we finally have interest to the `std.signal` module. +1
Re: std.signal : voting results
On Wednesday, 22 January 2014 at 14:38:48 UTC, ilya-stromberg wrote: On Wednesday, 22 January 2014 at 14:18:15 UTC, Dejan Lekic wrote: The new std.signal is IMHO far better than the old one. Why not simply replace it, and then look forward to future improvements? Guys, were are you was a few days ago when voting still was open?! Dicebot, can we continue voting at least 1-2 weeks? It looks like we finally have interest to the `std.signal` module. No. I am not adjusting procedure post-factum and when evaluating actual results single "No" vote from Phobos core team (Andrei) outweights few extra "Yes" votes anyway. We can schedule another review / voting relatively soon though, assuming Robert is still willing to push for it.
Re: std.signal : voting results
Am Wed, 22 Jan 2014 14:18:14 + schrieb "Dejan Lekic" : > The new std.signal is IMHO far better than the old one. Why not > simply replace it, and then look forward to future improvements? Phobos has a very strict "don't break backwards compatibility rule". IMHO too strict, but that's the way it is. This also means we can't add code if we already know it will have to be modified in not backwards compatible ways in the future. Also the Phobos quality standards must apply to new modules, otherwise those standards are useless. Modules older than these rules and the review process (signals, xml) are (unfortunately) special and I'd just remove those completely, but there can't be any exceptions for new modules. (Thinking of documentation here for example. It's not a problem if a module doesn't pass the review on the first time btw. Just fix the problems and add it to the review queue again)
Re: So, You Want To Write Your Own Programming Language?
On 1/22/2014 4:53 AM, Don wrote: On Wednesday, 22 January 2014 at 04:29:05 UTC, Walter Bright wrote: http://www.reddit.com/r/programming/comments/1vtm2l/so_you_want_to_write_your_own_language_dr_dobbs/ Great article. I was surprised that you mentioned lowering positively, though. I think from DMD we have enough experience to say that although lowering sounds good, it's generally a bad idea. It gives you a mostly-working prototype very quickly, but you pay a heavy price for it. It destroys valuable semantic information. You end up with poor quality error messages, and counter-intuitively, you can end up with _more_ special cases (eg, lowering ref-foreach in DMD means ref local variables can spread everywhere). And it reduces possibilities for the optimizer. In DMD, lowering has caused *major* problems with AAs, foreach. and builtin-functions, and some of the transformations that the inliner makes. It's also caused problems with postincrement and exponentation. Probably there are other examples. It seems to me that what does make sense is to perform lowering as the final step before passing the code to the backend. If you do it too early, you're shooting yourself in the foot. On the other hand, the lowering of loops to for uncovered numerous bugs, and the lowering of scope to try-finally made it actually implementable and fairly bug-free.
Re: So, You Want To Write Your Own Programming Language?
On 1/22/2014 3:40 AM, Chris wrote: Syntax is getting simplified due to the fact that the listener "knows what we mean", e.g. "buy one get one free". I wonder to what extent languages will be simplified one day. But this is a topic for a whole book ... There was this article recently: http://www.onthemedia.org/story/yesterday-internet-solved-20-year-old-mystery/ about how english is so redundant one can write sentences using just the first letter of each word, and it is actually understandable.
Re: So, You Want To Write Your Own Programming Language?
Don: Could you give an example? We've tried very hard to avoid useless error messages, there should only be one error message for each bug in the code. Parser errors still generate a cascade of junk, and the "cannot deduce function from argument types" message is still painful -- is that what you mean? Or something else? There are situations where I see lots and lots of error messages caused by some detail that breaks the instantiability of for some function from std.algorithm. While trying to find you an example, I have found and filed this instead :-) https://d.puremagic.com/issues/show_bug.cgi?id=11971 Bye, bearophile
Re: So, You Want To Write Your Own Programming Language?
Am 22.01.2014 14:28, schrieb Dejan Lekic: On Wednesday, 22 January 2014 at 10:38:40 UTC, bearophile wrote: In Haskell the GHC compiler goes one step further, it translates all the Haskell code into an intermediate code named Core, that is not the language of a virtual machine, it's still a functional language, but it's simpler, lot of the syntax differences between language constructs is reduced to a much reduced number of mostly functional stuff. Same story is with Erlang as far as I know. Most likely due to its Prolog influence, which also does it.
Re: std.signal : voting has begun
Le 22/01/2014 08:43, Jacob Carlborg a écrit : On 2014-01-21 21:10, Xavier Bigand wrote: We use std.signals on DQuick, signals are critical for a GUI system, but there is no advanced GUI library written completely in D for the moment. For the moment DQuick still have a long way to do before really needing something better. What does the current std.signals offer that plain delegates don't? It's easier to manipulate when you have many connections.
Syncing files without a dynamic DNS service with D, Gmail and cURL
I figured I would share this project here since I wrote it in D and this is a D forum! I basically built two small programs to send and get a computer's IP using gmail as the static source. It would've been simpler to implement with some shell scripts, but I wanted to get practice using other d compilers and using the curl c bindings. A small writeup and source are below. Blog post detailing the project: http://genericprogrammingblog.blogspot.com/2014/01/avoiding-dynamic-dns-using-d-curl-and.html Code source: https://github.com/genericProgramming/ipsync.git
Re: std.signal : voting results
On Wednesday, 22 January 2014 at 15:44:07 UTC, Johannes Pfau wrote: Phobos has a very strict "don't break backwards compatibility rule". IMHO too strict, but that's the way it is. This is also the reason why I would have voted "no" if I made it in time. Documentation and implementation can be fixed later, but we would have had to support a borderline-broken API (with regards to type stringification) for the foreseeable future. David
Re: So, You Want To Write Your Own Programming Language?
On 1/22/14 4:53 AM, Don wrote: On Wednesday, 22 January 2014 at 04:29:05 UTC, Walter Bright wrote: http://www.reddit.com/r/programming/comments/1vtm2l/so_you_want_to_write_your_own_language_dr_dobbs/ Great article. I was surprised that you mentioned lowering positively, though. I think from DMD we have enough experience to say that although lowering sounds good, it's generally a bad idea. It gives you a mostly-working prototype very quickly, but you pay a heavy price for it. It destroys valuable semantic information. You end up with poor quality error messages, and counter-intuitively, you can end up with _more_ special cases (eg, lowering ref-foreach in DMD means ref local variables can spread everywhere). And it reduces possibilities for the optimizer. In DMD, lowering has caused *major* problems with AAs, foreach. and builtin-functions, and some of the transformations that the inliner makes. It's also caused problems with postincrement and exponentation. Probably there are other examples. It seems to me that what does make sense is to perform lowering as the final step before passing the code to the backend. If you do it too early, you're shooting yourself in the foot. There's a lot of value in defining a larger complex language in terms of a much simpler core. This technique has been applied successfully by a variety of languages (Java and Haskell come to mind). For us, I opine that the scope statement would've had a million subtle issues if it weren't defined in terms of try/catch/finally. My understanding is that your concern is related to the stage at which lowering is performed, which I'd agree with. Andrei
Re: std.signal : voting results
On 1/22/14 6:57 AM, Dicebot wrote: We can schedule another review / voting relatively soon though, assuming Robert is still willing to push for it. That would be great, and thanks Robert for being so gracious about it all. Going forward the best way to improve Phobos is to ratchet quality by keeping a high standard. I do understand that can be frustrating since there's stuff _in there_ that is worse off than what's proposed. Andrei
Re: So, You Want To Write Your Own Programming Language?
On 1/22/2014 3:21 PM, Andrei Alexandrescu wrote: My understanding is that your concern is related to the stage at which lowering is performed, which I'd agree with. I also think we did a slap-dash job of it, not that the concept is wrong.
Re: Syncing files without a dynamic DNS service with D, Gmail and cURL
On 1/22/14 12:15 PM, Ben wrote: I figured I would share this project here since I wrote it in D and this is a D forum! I basically built two small programs to send and get a computer's IP using gmail as the static source. It would've been simpler to implement with some shell scripts, but I wanted to get practice using other d compilers and using the curl c bindings. A small writeup and source are below. Blog post detailing the project: http://genericprogrammingblog.blogspot.com/2014/01/avoiding-dynamic-dns-using-d-curl-and.html Code source: https://github.com/genericProgramming/ipsync.git http://www.reddit.com/r/programming/comments/1vvdbm/avoiding_dynamic_dns_using_d_curl_and_gmail/ Don't forget to post around noon PST for maximum impact. Andrei
Re: Syncing files without a dynamic DNS service with D, Gmail and cURL
On Thursday, 23 January 2014 at 02:12:20 UTC, Andrei Alexandrescu wrote: On 1/22/14 12:15 PM, Ben wrote: I figured I would share this project here since I wrote it in D and this is a D forum! I basically built two small programs to send and get a computer's IP using gmail as the static source. It would've been simpler to implement with some shell scripts, but I wanted to get practice using other d compilers and using the curl c bindings. A small writeup and source are below. Blog post detailing the project: http://genericprogrammingblog.blogspot.com/2014/01/avoiding-dynamic-dns-using-d-curl-and.html Code source: https://github.com/genericProgramming/ipsync.git http://www.reddit.com/r/programming/comments/1vvdbm/avoiding_dynamic_dns_using_d_curl_and_gmail/ Don't forget to post around noon PST for maximum impact. Andrei Thanks, that's good to know!
Re: dmd 2.065 beta 1 #2
On Wednesday, 22 January 2014 at 03:34:40 UTC, Andrew Edwards wrote: On 1/21/14, 5:22 PM, Andrew Edwards wrote: Note: An installer is not yet prepared for Windows. It is now added: ftp://ftp.digitalmars.com/dmd-2.065.b1.exe This of course is relying on the zip file getting uploaded to downloads.dlang.org. You could use the digitalmars urls for betas, I suppose, since those don't end up on the download site anyway. The url template is just a bit further down in the file.
Re: std.signal : voting results
We can schedule another review / voting relatively soon though, assuming Robert is still willing to push for it. Well, I am definitely motivated now that there is some reaction. Although my wife is currently giving birth, so can't really estimate how soon I will get to it, but then I will definitely incorporate the review comments I agree with. There are some I don't agree with or which are not totally clear, I am going to summarize them in a new thread. I hope the people raising them will still be around then. Best regards, Robert
