Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:20:54 UTC, bearophile wrote: eles: Speaking about that, why DMD's source files are written in C++ but bear extension .c? You seem to appreciate for yourselves a freedom that he denies to others. Thank you for bringing that good example. Forbidding arbitrary extensions for D code, and enforcing a common standard name helps avoid mistakes like those .c extensions in the C++ sources, that numerous persons keep criticizing. The advantages of a standard suffix for D code are way larger than the disadvantages. A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth Well, then God created humans...
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 15:39:27 UTC, eles wrote: On Thursday, 31 October 2013 at 15:34:37 UTC, dennis luehring wrote: Am 31.10.2013 16:22, schrieb eles: On Thursday, 31 October 2013 at 15:13:20 UTC, dennis luehring wrote: Am 31.10.2013 16:01, schrieb eles: On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring wrote: Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring no problem :) so tell the story what would happen if D scripts will be without .d? is your Boss then more interested or can you introduce D-scripts then silently - what would happen? He won't really care as long as I don't ask him to modify his scripts to update the names of those used by me. The latter are already hard-coded in his and others. Yes, this has a solution: use of hardlinks (of identical-content, different name files). I already explained and acknowledged that in the very first post. But is cumbersome and unpleasant and bad for backup-ing. Why not simply rename .d to . then compile, rename back using a script? It might add a few extra seconds for very large projects but otherwise insignificant and should work most of the time. Basically you'll use the script or wrapper app instead of whatever compile you are using.
Re: Start of dmd 2.064 beta program
On Tuesday, 10 December 2013 at 09:44:38 UTC, Frustrated wrote: On Thursday, 31 October 2013 at 15:39:27 UTC, eles wrote: On Thursday, 31 October 2013 at 15:34:37 UTC, dennis luehring wrote: Am 31.10.2013 16:22, schrieb eles: On Thursday, 31 October 2013 at 15:13:20 UTC, dennis luehring wrote: Am 31.10.2013 16:01, schrieb eles: On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring wrote: Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring Why not simply rename .d to . then compile, rename back using a script? It might add a few extra seconds for very large projects but otherwise insignificant and should work most of the time. Basically you'll use the script or wrapper app instead of whatever compile you are using. You are overreacting to a maybe bad joke, but I must say that I really love the solution you propose. Is even better than the one with hardlinks. The only thing that I don't have yet is a third hand to keep the window open while my fifth foot is doing some tricks with the a crow's nest. This would be quite a workable workaround, don't you think?
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 17:09:09 UTC, Leandro Lucarella wrote: Craig Dillabaugh, el 31 de October a las 15:54 me escribiste: On Thursday, 31 October 2013 at 14:29:34 UTC, eles wrote: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: This seems like a bit of bikeshedding issue. It isn't bikeshedding at all, is a functional problem, is key to understand that before you keep discussing the issue :) Since when has understanding an issue been a requirement for discussing it? As evidence I point you to the comments section on just about any major news site :) I think I understand the implications of the current requirement that d source files end with .d. However there are some workarounds that, while certainly a pain, can be applied. Also, some commentators had valid reasons to keep that status quo. I can see systems full of files with .py extensions that are actually D files and with .rb files that are actually c++ files and so forth being a bit of a maintenance nightmare for the person that replaces you (like when you quit your job because the made you code in Python). My reason for posting originally was not so much that I didn't like the request, but simply to point out that whether D is a serious language, or a toy language, doesn't really hinge on this issue. All sorts of serious programming environments/tools have 'features' that may certain workflows a pain. By the way, I like your proposed solution.
Re: Start of dmd 2.064 beta program
On Saturday, 26 October 2013 at 22:35:14 UTC, eles wrote: On Saturday, 26 October 2013 at 21:11:02 UTC, Walter Bright wrote: On 10/26/2013 2:02 AM, eles wrote: On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright wrote: On 10/26/2013 12:42 AM, eles wrote: http://d.puremagic.com/issues/show_bug.cgi?id=11365 Thank you for considering it. I am amazed how such a simple issue is provoking unbelievable philosophic discussion attempting to find the best way to bite your own tail while running circles around a tree.
Re: Start of dmd 2.064 beta program
On Saturday, 26 October 2013 at 22:35:14 UTC, eles wrote: On Saturday, 26 October 2013 at 21:11:02 UTC, Walter Bright wrote: On 10/26/2013 2:02 AM, eles wrote: On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright wrote: On 10/26/2013 12:42 AM, eles wrote: Thank you for considering it. I cannot comment on the bugzilla, but frankly I do not like those comments at all. Why cannot I name my scripts like: script.no1 script.no2 script.no3 ? Must always use script_no1 or script_no1.d? What is this conservationism? You have a very nice way to cut a programmer's arms and legs and then yell at him why he does not run or swim faster. Just let the poor guy name the scripts how he really likes it. Speaking about that, why DMD's source files are written in C++ but bear extension .c? You seem to appreciate for yourselves a freedom that he denies to others.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:16:22 UTC, eles wrote: On Saturday, 26 October 2013 at 22:35:14 UTC, eles wrote: On Saturday, 26 October 2013 at 21:11:02 UTC, Walter Bright wrote: On 10/26/2013 2:02 AM, eles wrote: On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright wrote: On 10/26/2013 12:42 AM, eles wrote: You seem to appreciate for yourselves a freedom that he denies to others. And +1 for Leandro. The day that D was declared to serve some useful purpose is the day when D gave up the right to be just a toy. Hey! I work in production! Somebody hears that?
Re: Start of dmd 2.064 beta program
eles: Speaking about that, why DMD's source files are written in C++ but bear extension .c? You seem to appreciate for yourselves a freedom that he denies to others. Thank you for bringing that good example. Forbidding arbitrary extensions for D code, and enforcing a common standard name helps avoid mistakes like those .c extensions in the C++ sources, that numerous persons keep criticizing. The advantages of a standard suffix for D code are way larger than the disadvantages. Bye, bearophile
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:20:54 UTC, bearophile wrote: eles: Thank you for bringing that good example. Forbidding arbitrary extensions for D code, and enforcing a common standard name helps avoid mistakes like those .c extensions in the C++ sources, that numerous persons keep criticizing. The advantages of a standard suffix for D code are way larger than the disadvantages. In projects, not in scripts. C/C++ not used for scripts.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:16:22 UTC, eles wrote: On Saturday, 26 October 2013 at 22:35:14 UTC, eles wrote: On Saturday, 26 October 2013 at 21:11:02 UTC, Walter Bright wrote: On 10/26/2013 2:02 AM, eles wrote: On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright wrote: On 10/26/2013 12:42 AM, eles wrote: Thank you for considering it. I cannot comment on the bugzilla, but frankly I do not like those comments at all. Why cannot I name my scripts like: script.no1 script.no2 script.no3 ? Must always use script_no1 or script_no1.d? And maybe one day I have a lot of .py files that I intend to replace with D scripts TRANSPARENTLY for their user. Will D bow at me why I use the .py extension? Is D trying to shoot his own foot? It really seems to succeed quite well. My boss is right: is just a toy pretending to be serious. I am bitter about this.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. My boss is right: is just a toy pretending to be serious - maybe, maybe not - but not because of your stupid file extension comments It adds. Tell to my boss about that extensions and he will be grateful for you providing him ONE MORE REASON to laugh. At me.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:20:54 UTC, bearophile wrote: eles: Bye, bearophile Well, then allow just extension .d or NO EXTENSION, but consider files named like: script.no1 script.julia script.no5 just as being standard names without any extension (you may see for yourself that there is no extension since they lack the final .d). D is a wonderful language for which creators try hard to make the worst of tools.
Re: Start of dmd 2.064 beta program
Must always use script_no1 or script_no1.d? And maybe one day I have a lot of .py files that I intend to replace with D scripts TRANSPARENTLY for their user. Will D bow at me why I use the .py extension? Is D trying to shoot his own foot? It really seems to succeed quite well. My boss is right: is just a toy pretending to be serious. sorry, but this is a very stupid comment: 1. never ever was a language successful(or not) because of its file-extension behavior - maybe in your world 2. i hope there is no other tool around try to find/analyse/whatever real Python programs by using the extension - else you need to change that anyway 3. My boss is right: is just a toy pretending to be serious - maybe, maybe not - but not because of your stupid file extension comments thx
Re: Start of dmd 2.064 beta program
Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. My boss is right: is just a toy pretending to be serious - maybe, maybe not - but not because of your stupid file extension comments It adds. Tell to my boss about that extensions and he will be grateful for you providing him ONE MORE REASON to laugh. At me. question: why are you using D if 1. Python works for you 2. Python doesnt suffer from the BIG-BIG file-extension problem 3. your laughing Boss tells you D is a toy i don't get it better try to find a more experienced, serious Boss
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. My boss is right: is just a toy pretending to be serious better try to find a more experienced, serious Boss Do you offer yourself for his job? Maybe because I don't want to have a code base written in several languages? And seriously, about your former argument about the importance of the extension in being serious or not: accepting arbitrary extension was the reason for C++ doom? Seriously, I never hear somebody citing that the purpose why D exists is to correct the C++... file extension problem. I hear about a lot other reasons, but not this one.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. My boss is right: is just a toy pretending to be serious i don't get it You never wrote git extension scripts, isn't? Then write and you will get it.
Re: Start of dmd 2.064 beta program
File content should have nothing to do with extension, it is as good part of name as any other. Adding any extra meaning to it is just some DOS legacy.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. My boss is right: is just a toy pretending to be serious - maybe, maybe not - but not because of your stupid file extension comments It adds. Tell to my boss about that extensions and he will be grateful for you providing him ONE MORE REASON to laugh. At me. question: why are you using D if OH, I forgot to add: I HAAATE PYTHON. I do not care if it works. Assembler works! I hate it! I like D (the language, not the compiler ;). I *want* to use D. Why don't *you* use ASM? Go and write in machine code! IT WORKS!
Re: Start of dmd 2.064 beta program
Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. My boss is right: is just a toy pretending to be serious better try to find a more experienced, serious Boss Do you offer yourself for his job? Maybe because I don't want to have a code base written in several languages? And seriously, about your former argument about the importance of the extension in being serious or not: accepting arbitrary extension was the reason for C++ doom? just 0,001% of it - but a clear definition is always bettern then a floaty like you should use .d as extension
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:29:34 UTC, eles wrote: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. My boss is right: is just a toy pretending to be serious - maybe, maybe not - but not because of your stupid file extension comments It adds. Tell to my boss about that extensions and he will be grateful for you providing him ONE MORE REASON to laugh. At me. In my experience, when it comes to software development, bosses tend to have no clue what they are talking about anyway :o) So I would just laugh back at him/her (might keep that to myself though, depending on how secure I feel my job is). This seems like a bit of bikeshedding issue. You may have a strong preference for one option, apparently others feel differently. Is it really that big an issue? I don't think the quality of a language depends on its file naming conventions. I don't like the way Python uses whitespace .. but I still like the language. I agree the compiler shouldn't be adding anything to the supplied names, however if I understand the issue I see no real problem with requiring that D source files/scripts end with a .d extension. Finally, you've said a few times that D has crappy tooling. I am not sure how this file naming stuff has anything to do with that (other than superficial ways).
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh wrote: On Thursday, 31 October 2013 at 14:29:34 UTC, eles wrote: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: Finally, you've said a few times that D has crappy tooling. I am not sure how this file naming stuff has anything to do with that (other than superficial ways). Go to that bug report, read the very first message that Walter used to open the bug report, see about yourself, then come back here and tell me that the .d thing does not matter. It is the *very* reason for this debate. As to quote Walter's own understanding of the problem (unfortunately, the solution he proposed is bad): Thanks for the clear explanation. It makes a lot of sense.. Now, if you disagree with that, you disagree with Walter.
Re: Start of dmd 2.064 beta program
Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. My boss is right: is just a toy pretending to be serious better try to find a more experienced, serious Boss Do you offer yourself for his job? why should i?
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh wrote: clip This seems like a bit of bikeshedding issue. You may have a strong preference for one option, apparently others feel differently. Is it really that big an issue? I don't think the quality of a language depends on its file naming conventions. I don't like the way Python uses whitespace .. but I still like the language. clip Finally, you've said a few times that D has crappy tooling. I am not sure how this file naming stuff has anything to do with that (other than superficial ways). eles, seeing your post above, I guess my use of Python to justify my answer turns out to a bad choice on my part :o)
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:57:43 UTC, Craig Dillabaugh wrote: On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh eles, seeing your post above, I guess my use of Python to justify my answer turns out to a bad choice on my part :o) That's true. I hate using it, especially because I am still force to use it when writing tests because of its py.test module. I simply don't like it. I want pointers in my code.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring wrote: Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. My boss is right: is just a toy pretending to be serious better try to find a more experienced, serious Boss Do you offer yourself for his job? why should i? Then don't tell me what I should feel to do about my job. 'Cause you don't deserve other answer than why should I?
Re: Start of dmd 2.064 beta program
Am 31.10.2013 16:01, schrieb eles: On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring wrote: Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. My boss is right: is just a toy pretending to be serious better try to find a more experienced, serious Boss Do you offer yourself for his job? why should i? Then don't tell me what I should feel to do about my job. 'Cause you don't deserve other answer than why should I? i don't see any chance/strategy to get D in your current development - so if you don't want to code Python (I WANT pointers) anymore - try to find a job where you can write C/C++ or D - or else your need (and real hard interest to get your Boss in the Boart) for D seems to be not big enough - i would quit my job very fast if someone forces me to write Python code most of the time - thats all
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:45:46 UTC, Dicebot wrote: File content should have nothing to do with extension, it is as good part of name as any other. Adding any extra meaning to it is just some DOS legacy. When I first came to Linux I was wondering how the OS knows it should execute some file that wasn't bearing the .exe/.com extensions. And who tells the OS this is an executable file? How could Linux know it without the .exe or .com at the end? Well, I was DOSwashed.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:58:33 UTC, eles wrote: On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh wrote: Go to that bug report, read the very first message that Walter used to open the bug report, see about yourself, then come back here and tell me that the .d thing does not matter. It is the *very* reason for this debate. As to quote Walter's own understanding of the problem (unfortunately, the solution he proposed is bad): Thanks for the clear explanation. It makes a lot of sense.. Now, if you disagree with that, you disagree with Walter. I read the bug report, and the ensuing comments. It just seems that some people involved don't agree, but opinion appears to be split. Having Walter apparently on your side can't hurt though. I can see why you like having the ability to process an arbitrarily named file as a D source file, but some of the counter-arguments have some merit. Furthermore, reading the Bugzilla entry, it seems there as many who support your idea as those who disagree. I could also argue that this issue is a with git requiring a 'git-' suffix on its scripts without providing users with some means of overriding the file naming convention (maybe this is already possible, I have only minimal git experience)! Really, I can see why you want the suggested change, I am just surprised at the level of importance you seem to be ascribing to it.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 15:13:20 UTC, dennis luehring wrote: Am 31.10.2013 16:01, schrieb eles: On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring wrote: Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring i don't see any chance/strategy to get D in your current development - so if you don't want to code Python (I WANT pointers) anymore - try to find a job where you can write C/C++ or D - or else your need (and real hard interest to get your Boss in the Boart) for D seems to be not big enough - i would quit my job very fast if someone forces me to write Python code most of the time - thats all Frankly, just stop advising me to take a new job. It is the kind of advice that I really find intrusive and unbearable. I do critical software and is 90% C. Is for embedded devices that are great chances that you already used. I use Python for py.test because it is the company policy and tradition, but I am not forced to like Python. Let's keep the discussion in the terms of languages, not personal problems. I would never allow myself to tell you what you should do with your car, house, job or life. BTW, my boss is very kind and nice, but he is concerned about how the tools would increase productivity. It is he who is responsible for the budget in front of, guess it, his boss. Otherwise, no, I would simply quit D instead of my job. And this neither, I don't want to do it. Please, stop advising me in matters that I consider should remain of my personal competence.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 15:22:41 UTC, Craig Dillabaugh wrote: On Thursday, 31 October 2013 at 14:58:33 UTC, eles wrote: On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh Really, I can see why you want the suggested change, I am just surprised at the level of importance you seem to be ascribing to it. Maybe because it is a real problem? Usually, those who take such matters lightly never really encounter them. And it is easy to give advice about somebody's else teeth ache. You know, the usual: c'mon, you scream too hard, it *cannot* hurt that much. Well, this is true, it does not hurt anyone, except the one who really has his teeth broken. But the others are quite insensitive to it. That's the story about the .d suffix.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 15:22:41 UTC, Craig Dillabaugh wrote: On Thursday, 31 October 2013 at 14:58:33 UTC, eles wrote: On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh wrote: Furthermore, reading the Bugzilla entry, it seems there as many who support your idea as those who disagree. If you are sick about to die in an hospital, would you like the medical treatment for you to be established through a majority vote involving the whole city population, or on the professional doctors that *really know* what your health problem is about? Just ask the question: how many of you expressing advice did you really encounter this problem and felt about it? It is so easy to offer advice about things that do not really hurt you, but only others.
Re: Start of dmd 2.064 beta program
Am 31.10.2013 16:22, schrieb eles: On Thursday, 31 October 2013 at 15:13:20 UTC, dennis luehring wrote: Am 31.10.2013 16:01, schrieb eles: On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring wrote: Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring i don't see any chance/strategy to get D in your current development - so if you don't want to code Python (I WANT pointers) anymore - try to find a job where you can write C/C++ or D - or else your need (and real hard interest to get your Boss in the Boart) for D seems to be not big enough - i would quit my job very fast if someone forces me to write Python code most of the time - thats all Frankly, just stop advising me to take a new job. It is the kind of advice that I really find intrusive and unbearable. no problem :) so tell the story what would happen if D scripts will be without .d? is your Boss then more interested or can you introduce D-scripts then silently - what would happen?
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 15:34:37 UTC, dennis luehring wrote: Am 31.10.2013 16:22, schrieb eles: On Thursday, 31 October 2013 at 15:13:20 UTC, dennis luehring wrote: Am 31.10.2013 16:01, schrieb eles: On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring wrote: Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring no problem :) so tell the story what would happen if D scripts will be without .d? is your Boss then more interested or can you introduce D-scripts then silently - what would happen? He won't really care as long as I don't ask him to modify his scripts to update the names of those used by me. The latter are already hard-coded in his and others. Yes, this has a solution: use of hardlinks (of identical-content, different name files). I already explained and acknowledged that in the very first post. But is cumbersome and unpleasant and bad for backup-ing.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 15:22:41 UTC, Craig Dillabaugh wrote: On Thursday, 31 October 2013 at 14:58:33 UTC, eles wrote: On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh wrote: I could also argue that this issue is a with git requiring a 'git-' suffix on its scripts without providing users with some means of overriding the file naming convention (maybe this is already possible, I have only minimal git experience)! BTW, git is not requiring a git- suffix, but a git-prefix. It does not matter for git what the git-name here script extension (or name) use. It matters to the one typing git commands, because he has to type: git name here in order for git to invoke git-name here behind. I really don't feel like git is doing anything bad here or it should change. It matters, however, if one is allowed to type: git tellmethelotterynumbers instead of being forced to type git tellmethelotterynumbers.d You see, the latter version will give you the numbers spelled as: 16.d, 32.d, 18.d, 5.d, 11.d and 22.d Or, it happens, the state lottery won't deny you the prize because, guess, the real numbers that were extracted were 16, 32, 18, 5, 11 and 22.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 16:12:44 UTC, eles wrote: On Thursday, 31 October 2013 at 15:22:41 UTC, Craig Dillabaugh wrote: On Thursday, 31 October 2013 at 14:58:33 UTC, eles wrote: On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh wrote: Or, it happens, the state lottery won't deny you the prize *will :P
Re: Start of dmd 2.064 beta program
dennis luehring, el 31 de October a las 15:28 me escribiste: Must always use script_no1 or script_no1.d? And maybe one day I have a lot of .py files that I intend to replace with D scripts TRANSPARENTLY for their user. Will D bow at me why I use the .py extension? Is D trying to shoot his own foot? It really seems to succeed quite well. My boss is right: is just a toy pretending to be serious. sorry, but this is a very stupid comment: 1. never ever was a language successful(or not) because of its file-extension behavior - maybe in your world 2. i hope there is no other tool around try to find/analyse/whatever real Python programs by using the extension - else you need to change that anyway 3. My boss is right: is just a toy pretending to be serious - maybe, maybe not - but not because of your stupid file extension comments I think even when the wording isn't the best, what he says is true. Sometimes is hard to sell the language when things that are so trivial and fundamental (as letting file names have arbitrary names, at least for scripts) not only are broken, but are justified by the community. That's definitely not serious and discouraging. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Hey you, don't tell me there's no hope at all Together we stand, divided we fall.
Re: Start of dmd 2.064 beta program
Craig Dillabaugh, el 31 de October a las 15:54 me escribiste: On Thursday, 31 October 2013 at 14:29:34 UTC, eles wrote: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. My boss is right: is just a toy pretending to be serious - maybe, maybe not - but not because of your stupid file extension comments It adds. Tell to my boss about that extensions and he will be grateful for you providing him ONE MORE REASON to laugh. At me. In my experience, when it comes to software development, bosses tend to have no clue what they are talking about anyway :o) So I would just laugh back at him/her (might keep that to myself though, depending on how secure I feel my job is). This seems like a bit of bikeshedding issue. It isn't bikeshedding at all, is a functional problem, is key to understand that before you keep discussing the issue :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Es erróneo pensar que el repollo es una afirmación de personalidad del volátil, es una verdura, es una verdura. -- Ricardo Vaporeso
Re: Start of dmd 2.064 beta program
Am 31.10.2013 17:44, schrieb Leandro Lucarella: dennis luehring, el 31 de October a las 15:28 me escribiste: Must always use script_no1 or script_no1.d? And maybe one day I have a lot of .py files that I intend to replace with D scripts TRANSPARENTLY for their user. Will D bow at me why I use the .py extension? Is D trying to shoot his own foot? It really seems to succeed quite well. My boss is right: is just a toy pretending to be serious. sorry, but this is a very stupid comment: 1. never ever was a language successful(or not) because of its file-extension behavior - maybe in your world 2. i hope there is no other tool around try to find/analyse/whatever real Python programs by using the extension - else you need to change that anyway 3. My boss is right: is just a toy pretending to be serious - maybe, maybe not - but not because of your stupid file extension comments I think even when the wording isn't the best, what he says is true. Sometimes is hard to sell the language when things that are so trivial and fundamental (as letting file names have arbitrary names, at least for scripts) not only are broken, but are justified by the community. That's definitely not serious and discouraging. sorry for my wording - but pressure sentence like My boss is right: is just a toy pretending to be serious aren't fair also
Re: Start of dmd 2.064 beta program
dennis luehring, el 31 de October a las 18:25 me escribiste: Am 31.10.2013 17:44, schrieb Leandro Lucarella: dennis luehring, el 31 de October a las 15:28 me escribiste: Must always use script_no1 or script_no1.d? And maybe one day I have a lot of .py files that I intend to replace with D scripts TRANSPARENTLY for their user. Will D bow at me why I use the .py extension? Is D trying to shoot his own foot? It really seems to succeed quite well. My boss is right: is just a toy pretending to be serious. sorry, but this is a very stupid comment: 1. never ever was a language successful(or not) because of its file-extension behavior - maybe in your world 2. i hope there is no other tool around try to find/analyse/whatever real Python programs by using the extension - else you need to change that anyway 3. My boss is right: is just a toy pretending to be serious - maybe, maybe not - but not because of your stupid file extension comments I think even when the wording isn't the best, what he says is true. Sometimes is hard to sell the language when things that are so trivial and fundamental (as letting file names have arbitrary names, at least for scripts) not only are broken, but are justified by the community. That's definitely not serious and discouraging. sorry for my wording - but pressure sentence like My boss is right: is just a toy pretending to be serious aren't fair also Let's see if this makes both sides happy: https://github.com/D-Programming-Language/dmd/pull/2700 (I still don't see any reason to enforce any extension, ever, but this at least fixes the more pressing issue, hopefully with less resistance) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- UNA ARTISTA HACE JABONES CON SU PROPIA GRASA LUEGO DE UNA LIPOSUCCION -- Crónica TV
Re: Start of dmd 2.064 beta program
On Friday, 25 October 2013 at 20:24:48 UTC, Walter Bright wrote: On 10/25/2013 6:15 AM, eles wrote: Breaking peoples' build scripts and makefiles is not nice :-) On the same grounds, you could recommend them dmc. Provide, at least, a flag that passes the file without name change, for example: dmd -ntest will really pass test file and not test.d. Why working so hard to do a good language if you work even harder to provide the worst of tooling?
Re: Start of dmd 2.064 beta program
On Friday, 25 October 2013 at 15:57:27 UTC, Namespace wrote: On Friday, 25 October 2013 at 13:24:12 UTC, eles wrote: On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright When was decided to add this? I would love it, but I cannot remember that this was decided. Well, like many other ideas of its kind, Walter expressed sympathy for it, then fall into oblivion... Unfortunately, D puts a lot of effort in doing great things, but all the nice nuts and bolts that would make our life easire and require no more than one LOC change in dmd's source tend to be forgotten. Somebody complained about lack of vision in D development. Don't be upset on me, but I really feel the same. People come, tried to do things... and left.
Re: Start of dmd 2.064 beta program
On 10/26/2013 12:42 AM, eles wrote: Provide, at least, a flag that passes the file without name change, for example: dmd -ntest will really pass test file and not test.d. I'm curious why naming the file test.d is an issue?
Re: Start of dmd 2.064 beta program
On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright wrote: On 10/26/2013 12:42 AM, eles wrote: I'm curious why naming the file test.d is an issue? Case: This forces scrpts to bear the .d extension. For example, if you write a script on Linux named git-test and you put at the top: #!rdmd rdmd will pass its name to dmd, and dmd will try to compile... git-test.d, which does not exist. Now, you have either to rename the git-test into git-test.d, or to create a hardlink named git-test.d that points towards git-test so that dmd finally gets satisfied its .d hungriness. The solution with the hardlink carries the well-known burdness of redundancy, let's not even say its idiot and makes back-up-ing a mess. OTOH, renaming the original script into git-test.d has the undesirable effect wrt to git software. git uses some nice convention that you can extend its command list by writing your own git-command1, git-command2 scripts and they are invoked automatically by git when you type: git command1 (this will invoke git-command1) etc. The problem with being forced to rename git-command1 into git-command1.d is that, afterwards, you have to type the following command for git: git command1.d (in order to have the git-command1.d invoked, as git-command1 simply does not exist or, if it would exist, dmd would be blind about it). SO, you cannot type git command1 and to have a git-command1 script invoked, because git won't search for git-command1.d, while dmd won't compile git-command1. So you need both git-command1 and git-command1.d doing the same thing, just to be able to type git command1 (not even say that this allows you to invoke, also git comman1.d, which is ugly and undesired redundancy). Now, immagine yourself having to type: git checkout.d . git commit.d git log.d instead of git checkout . git commit git log and tell me that .d is not an issue. Please have a look at the original thread that I linked and you'll see the problem. What use for scripting in D if I am unable to do some simple scripts because of the compiler?
Re: Start of dmd 2.064 beta program
On 10/26/2013 2:02 AM, eles wrote: On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright wrote: I'm curious why naming the file test.d is an issue? Case: Thanks for the clear explanation. It makes a lot of sense. Let me think about it for a bit.
Re: Start of dmd 2.064 beta program
On 10/26/2013 2:02 AM, eles wrote: On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright wrote: On 10/26/2013 12:42 AM, eles wrote: I'm curious why naming the file test.d is an issue? Case: http://d.puremagic.com/issues/show_bug.cgi?id=11365
Re: Start of dmd 2.064 beta program
On Saturday, 26 October 2013 at 21:11:02 UTC, Walter Bright wrote: On 10/26/2013 2:02 AM, eles wrote: On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright wrote: On 10/26/2013 12:42 AM, eles wrote: http://d.puremagic.com/issues/show_bug.cgi?id=11365 Thank you for considering it.
Re: Start of dmd 2.064 beta program
On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote: http://ftp.digitalmars.com/dmd2beta.zip Current list of regressions: It is a specific reason why this is kept?: http://forum.dlang.org/thread/ohduisigpwdiqhpde...@forum.dlang.org#post-btwbpwgluzyxmhphwebp:40forum.dlang.org
Re: Start of dmd 2.064 beta program
On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote: http://ftp.digitalmars.com/dmd2beta.zip Current list of regressions: http://d.puremagic.com/issues/buglist.cgi?query_format=advancedbug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED And the famous int[$] x = [1,2,3]; to declare static arrays and force the compiler to compute the length?
Re: Start of dmd 2.064 beta program
On Friday, 25 October 2013 at 13:24:12 UTC, eles wrote: On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote: http://ftp.digitalmars.com/dmd2beta.zip Current list of regressions: http://d.puremagic.com/issues/buglist.cgi?query_format=advancedbug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED And the famous int[$] x = [1,2,3]; to declare static arrays and force the compiler to compute the length? When was decided to add this? I would love it, but I cannot remember that this was decided.
Re: Start of dmd 2.064 beta program
On 10/25/2013 6:15 AM, eles wrote: It is a specific reason why this is kept?: http://forum.dlang.org/thread/ohduisigpwdiqhpde...@forum.dlang.org#post-btwbpwgluzyxmhphwebp:40forum.dlang.org Breaking peoples' build scripts and makefiles is not nice :-)
Re: Start of dmd 2.064 beta program
On 24 October 2013 07:44, Iain Buclaw ibuc...@ubuntu.com wrote: On 24 October 2013 02:29, Walter Bright newshou...@digitalmars.com wrote: Beta 3: http://ftp.digitalmars.com/dmd.2.064.beta.3.zip I suppose I better start opening a branch in gdc for the new release Noticed this in meld, the readme.txt file is different in the beta zip for the frontend. Don't know how you managed it... https://github.com/D-Programming-Language/dmd/blob/master/src/readme.txt -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Start of dmd 2.064 beta program
Beta 3: http://ftp.digitalmars.com/dmd.2.064.beta.3.zip
Re: Start of dmd 2.064 beta program
Why not just copy what Linus does with the Linux kernel. Different people in charge of different parts of the compiler. Pull requests should go to the correct person, who then makes a pull request that goes to the main line. On Mon, Oct 21, 2013 at 12:31 PM, Leandro Lucarella l...@llucax.com.arwrote: Andrei Alexandrescu, el 18 de October a las 11:45 me escribiste: - We do not have any defined release timeline. When is it time to start prepping for a release? It's up to Walter's arbitrary decision for when this happens, he doesn't even talk to the community or contributors on whether it's a good time for a beta phase (maybe there's a huge or disruptive new pull request that's planning to be merged and a beta should be delayed). I understand how that can be a bother. Walter figures the time is ripe for a new release when we have enough compelling features and fixes. I'll try to make the appropriate announcements in the future prior to deciding on starting a beta. Just a brief comment about this: sometimes regularity could be better than tons of new features/bugfixes. Walter scrambled to implement UDAs in a rush and breaking protocol in order to win a corporate D user, Remedy Games. It was a major, exceptional event. Would you have preferred the protocol to have been followed at the cost of Remedy? That's not the entire story. Back then Walter still push changes to the repo himself. That was the main problem, and fortunately it finally changed. He did that all the time in the past, UDAs wasn't an exception, but it had a high impact back then because Walter was the only one not going through the review process, it so felt doubly unfair. So when I have a few free minutes, I try to take a look at the extant pull requests - really, any would do. I try to pull in those that are meaningful and uncontroversial. I agree I could probably spend more time on carefully analyzing interactions between pulls, but that's time I can't afford. I think the alternative is merging one, wait for the autotester, merge another and wait for the autotester, and so on. I would be more annoying having to wait for every test, but there is really no rush to make a bunch in one go. I think it would be extremely helpful to have some help from the autotester to auto-merge too. Like marking a pull request as approved so the auto-tester merges it automatically when it passes the test. Dreaming? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- o_O parakenotengobarraespaciadora o_O aver o_O estoyarreglandolabarraporkeserompiounapatita
Re: Start of dmd 2.064 beta program
On 22 October 2013 08:35, Rory McGuire rjmcgu...@gmail.com wrote: Why not just copy what Linus does with the Linux kernel. Different people in charge of different parts of the compiler. Pull requests should go to the correct person, who then makes a pull request that goes to the main line. The thing is, there are too few components of D that make it work. Take DMD for example, you've got: backend, glue, front-end, ctfe. You could probably stretch it out further into port, target, lexer/parse, template, speller, cppmangle/mangle, hdrgen. But these are small and on their own don't get many changes to. Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Start of dmd 2.064 beta program
On Saturday, 19 October 2013 at 11:39:08 UTC, Iain Buclaw wrote: It has been about 3 months since the last release of the D front-end implementation. Three years experience and carrying out over 100 merges into GDC tells me that each time the development cycle starts edging towards it's fourth month, it makes things an absolute nightmare, in both the time consumed merging in the changes, and with time spent tracking down bug reports for unittests/testsuite cases that test backend code generation - with 2.060, 2.061 and 2.063 being the worst releases I have ever had to deal with - before 2.060 the release schedule (if it even qualifies as a 'schedule') was anywhere between 1-2 months. And a big +1 to that as well. Can't merges be done without release at your discretion in a separate branch or repo? If you keep track of it monthly, then you would have less to merge at the time of release.
Re: Start of dmd 2.064 beta program
On Friday, 18 October 2013 at 20:29:29 UTC, Andrej Mitrovic wrote: On 10/18/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: As a simple start, did you consider announcing the beta yourself? I didn't, because I disliked the current model and tied my hands when I saw the new beta was out due to the sum of frustrations which I've listed. This will change if the situation improves, of course. Anyone can tweet #dlang @D_programming, and in all likelihood we and many others would retweet. Good. I'll certainly start to build a better online presence, including tweeting, and I should start blogging too (there's plenty to blog about w.r.t. D). I can't be the pot calling the kettle black. Idea: We can use Twittwer API to automaticly publish a news like new betta. I did it via PHP for Drupal, and it wasn't so difficult. So, we can create a package build process. It creates new betta, publish announcement in the D forum, in the D homepage, in the D dowload page and in the D twitter.
Re: Start of dmd 2.064 beta program
Am Fri, 18 Oct 2013 11:45:27 -0700 schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org: - We do not have any defined release timeline. When is it time to start prepping for a release? It's up to Walter's arbitrary decision for when this happens, he doesn't even talk to the community or contributors on whether it's a good time for a beta phase (maybe there's a huge or disruptive new pull request that's planning to be merged and a beta should be delayed). I understand how that can be a bother. Walter figures the time is ripe for a new release when we have enough compelling features and fixes. I'll try to make the appropriate announcements in the future prior to deciding on starting a beta. Why is everyone here so obsessed with feature based releases? Quoting Iain's post from 30.8: It has been about 3 months since the last release of the D front-end implementation. Three years experience and carrying out over 100 merges into GDC tells me that each time the development cycle starts edging towards it's fourth month, it makes things an absolute nightmare, in both the time consumed merging in the changes, and with time spent tracking down bug reports for unittests/testsuite cases that test backend code generation - with 2.060, 2.061 and 2.063 being the worst releases I have ever had to deal with - before 2.060 the release schedule (if it even qualifies as a 'schedule') was anywhere between 1-2 months. Even a rough schedule (We try to release a new frontend version every 2 months) would help. Would it have been the end of the world if we just released 2.064 two months ago and 2.065 now? But what's worse: If we keep making feature based releases then the criteria for release should be documented by those making the decision. It's as simple as writing two sentences on a wiki page. Right now I don't have any clue why the 'time is ripe' now and not 2 months ago, or one month ago, or in two weeks... It seems like Walter is just flipping a coin every month (I don't say it is like that - but it looks like that because there's no information on the release criteria) And btw: 5 months between releases is just way too long for users as well. Although the features Walter envisioned for 2.064 may not have been ready 2 months ago we could have shipped many bug fixes two months earlier.
Re: Start of dmd 2.064 beta program
Am 18.10.2013 20:45, schrieb Andrei Alexandrescu: Walter and I frequently think of ways to gently steer people toward working on specific items. Votes, categorization, discussions are of limited impact. On occasion we've emailed major contributors directly and asked politely but point blank if they could look into an issue (sometimes something they had an expertise in, or even an issue they had caused). The rate of success has been very low. People still love working on things, just not on the things they're told to. I think you should continue to do that. Even if it only has a small sucess rate. I for example wouldn't have noticed that the stack trace code I submitted into druntime did cause long startup times for D-Programms that are run directly from the root of a disk drive if Walter wouldn't have send me the e-mail with the bug in it. After the e-mail I even fixed the bug ;-) Kind Regards Benjamin Thaut
Re: Start of dmd 2.064 beta program
On Oct 19, 2013 10:11 AM, Johannes Pfau nos...@example.com wrote: Am Fri, 18 Oct 2013 11:45:27 -0700 schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org: - We do not have any defined release timeline. When is it time to start prepping for a release? It's up to Walter's arbitrary decision for when this happens, he doesn't even talk to the community or contributors on whether it's a good time for a beta phase (maybe there's a huge or disruptive new pull request that's planning to be merged and a beta should be delayed). I understand how that can be a bother. Walter figures the time is ripe for a new release when we have enough compelling features and fixes. I'll try to make the appropriate announcements in the future prior to deciding on starting a beta. Why is everyone here so obsessed with feature based releases? Quoting Iain's post from 30.8: It has been about 3 months since the last release of the D front-end implementation. Three years experience and carrying out over 100 merges into GDC tells me that each time the development cycle starts edging towards it's fourth month, it makes things an absolute nightmare, in both the time consumed merging in the changes, and with time spent tracking down bug reports for unittests/testsuite cases that test backend code generation - with 2.060, 2.061 and 2.063 being the worst releases I have ever had to deal with - before 2.060 the release schedule (if it even qualifies as a 'schedule') was anywhere between 1-2 months. Even a rough schedule (We try to release a new frontend version every 2 months) would help. Would it have been the end of the world if we just released 2.064 two months ago and 2.065 now? But what's worse: If we keep making feature based releases then the criteria for release should be documented by those making the decision. It's as simple as writing two sentences on a wiki page. Right now I don't have any clue why the 'time is ripe' now and not 2 months ago, or one month ago, or in two weeks... It seems like Walter is just flipping a coin every month (I don't say it is like that - but it looks like that because there's no information on the release criteria) And btw: 5 months between releases is just way too long for users as well. Although the features Walter envisioned for 2.064 may not have been ready 2 months ago we could have shipped many bug fixes two months earlier. And a big +1 to that as well. Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Start of dmd 2.064 beta program
On 2013-10-17 22:35, Andrej Mitrovic wrote: - Walter is still not tagging the beta releases by the file name (it's always dmd2beta.zip). I've complained about this several times and IIRC someone else did as well at dconf (maybe I'm remembering wrong though). They should at least be named as dmd2_064_beta1.zip, dmd2_064_beta2.zip. And all of them should always be available for download (including visibility on the download page), so people who do not use Git or build manually from master can quicky check whether a regression was introduced in a specific beta version. Please make it dmd.2_064_beta1.zip and dmd.2_064_beta2.zip instead. This will automatically make it compatible with DVM. The important thing here is dmd.whatever. So that's what I'm protesting about. Agree with everything you said. -- /Jacob Carlborg
Re: Start of dmd 2.064 beta program
On Friday, 18 October 2013 at 06:36:43 UTC, Jacob Carlborg wrote: On 2013-10-17 22:35, Andrej Mitrovic wrote: - Walter is still not tagging the beta releases by the file name (it's always dmd2beta.zip). I've complained about this several times and IIRC someone else did as well at dconf (maybe I'm remembering wrong though). They should at least be named as dmd2_064_beta1.zip, dmd2_064_beta2.zip. And all of them should always be available for download (including visibility on the download page), so people who do not use Git or build manually from master can quicky check whether a regression was introduced in a specific beta version. Please make it dmd.2_064_beta1.zip and dmd.2_064_beta2.zip instead. This will automatically make it compatible with DVM. The important thing here is dmd.whatever. IIRC, Walter wanted that file to always be named dmd.zip or dmd2.zip or whatever, in order to allow a permanent download link, while guaranteeing the file to be the latest version of the tool. In this case, I think the best compromise is simply to have the latest version download-able either as dmd2.zip and as dmd2.version.zip.
Re: Start of dmd 2.064 beta program
On 10/17/2013 11:45 PM, deadalnix wrote: Also, when NOT using the unittest flag, a lot of my code do not compile, symbol _D6object15__T7reserveTyaZ7reserveFNaNbNeKAyamZm is missing. See: http://d.puremagic.com/issues/show_bug.cgi?id=11284
Re: Start of dmd 2.064 beta program
On 10/18/13, eles e...@eles.com wrote: IIRC, Walter wanted that file to always be named dmd.zip or dmd2.zip or whatever, in order to allow a permanent download link, while guaranteeing the file to be the latest version of the tool. This is the wrong approach. There should be a latest_beta file which holds the name of the latest beta zip. Then automatic download tools can read this file before attempting to download the beta. And for everyone else who manually downloads, they should be able to see what the latest version is on the website. This isn't a novelty approach, many open-source libraries host their sources in a tarball on an FTP server with a LATEST file. Speaking of which, insisting on using .zip files is another beef I have with Walter. The whole everyone on Windows is stuck in the 90s mentality is plain wrong, especially for programmers. 7zip (or Peazip or whatever) should be part of every modern programmer's toolbox. If you've tried to investigate some source code of an open-source library in the last 15 years you must have ran into the issue of having to open tarballs, or more specifically non-zip/non-rar archives. I just can't believe there would still be programmers that use Winzip or the lousy built-in Windows unzipper.
Re: Start of dmd 2.064 beta program
On 10/18/13 7:08 AM, Andrej Mitrovic wrote: On 10/18/13, eles e...@eles.com wrote: IIRC, Walter wanted that file to always be named dmd.zip or dmd2.zip or whatever, in order to allow a permanent download link, while guaranteeing the file to be the latest version of the tool. This is the wrong approach. There should be a latest_beta file which holds the name of the latest beta zip. Correct, the latest beta is a link to the actual numbered file. Speaking of which, insisting on using .zip files is another beef I have with Walter. The whole everyone on Windows is stuck in the 90s mentality is plain wrong, especially for programmers. 7zip (or Peazip or whatever) should be part of every modern programmer's toolbox. I don't think that makes a large difference. Probably the better thing to do is trimming the contents of the archive. I'll come back with a reply to the longer message. Andrei
Re: Start of dmd 2.064 beta program
Am 18.10.2013 09:33, schrieb deadalnix: On Friday, 18 October 2013 at 07:21:47 UTC, Walter Bright wrote: On 10/17/2013 11:45 PM, deadalnix wrote: Also, when NOT using the unittest flag, a lot of my code do not compile, symbol _D6object15__T7reserveTyaZ7reserveFNaNbNeKAyamZm is missing. See: http://d.puremagic.com/issues/show_bug.cgi?id=11284 I blasted everything from dmd/druntime/phobos and my own project and recompiled everything from master for D projects and then my project is compiled with the new dmd, everything with the same flag. I highly doubt that this fit into cases 1 to 4 as you mention. I'll however double check with that in mind. That also doesn't explain why I get a closure bug (frame pointer or frame content is corrupted) when compiling with unittest. The code that fail isn't even unittested ! I have a similar issue than yours. The symbol that is missing for me is not even contained within any version or debug block. See: http://d.puremagic.com/issues/show_bug.cgi?id=11280 Kind Regards Benjamin Thaut
Re: Start of dmd 2.064 beta program
On Friday, October 18, 2013 08:57:00 Andrei Alexandrescu wrote: Speaking of which, insisting on using .zip files is another beef I have with Walter. The whole everyone on Windows is stuck in the 90s mentality is plain wrong, especially for programmers. 7zip (or Peazip or whatever) should be part of every modern programmer's toolbox. I don't think that makes a large difference. Probably the better thing to do is trimming the contents of the archive. The #1 reason why zip has got to go is symlinks. The shared libraries for Linux in the zip are messed up, because you can't put symlinks in the zip file. We really need to have OS-specific archives with the Linux one being something like .tar.gz or .tar.bz2. - Jonathan M Davis
Re: Start of dmd 2.064 beta program
On 10/18/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I don't think that makes a large difference. Probably the better thing to do is trimming the contents of the archive. Right, but this is more general. He also dislikes non-zip archives in bugzilla attachments.
Re: Start of dmd 2.064 beta program
On 18 Oct 2013 19:45, Jonathan M Davis jmdavisp...@gmx.com wrote: On Friday, October 18, 2013 08:57:00 Andrei Alexandrescu wrote: Speaking of which, insisting on using .zip files is another beef I have with Walter. The whole everyone on Windows is stuck in the 90s mentality is plain wrong, especially for programmers. 7zip (or Peazip or whatever) should be part of every modern programmer's toolbox. I don't think that makes a large difference. Probably the better thing to do is trimming the contents of the archive. The #1 reason why zip has got to go is symlinks. The shared libraries for Linux in the zip are messed up, because you can't put symlinks in the zip file. We really need to have OS-specific archives with the Linux one being something like .tar.gz or .tar.bz2. - Jonathan M Davis Quite simply zip is not the correct format. Zip is normally only used to distribute windows specific versions of software. Does it even support executable permissions?
Re: Start of dmd 2.064 beta program
This is a good list of things that we could and should improve. Getting all minded to perfection would be difficult, but definitely worth living into. I appreciate your enthusiasm for and involvement in D. At the top level a few simple realities need to be understood. First, there is no OSS community that doesn't have its annoyances. I've been a direct participant to one other and am lurking on the forums of three more. Some are led by juntas of mini-tyrants; some are unnecessarily snooty; some are consumed by intestine fighting, politics, and horse-trading; and so on. Second, some of your points revolve around the fact that Walter and myself are not as good as we should at certain tasks and roles, such as build master, PR person, manager, and operational officer. The general argument pattern revolves around I/we told Walter/Andrei several times they need to do X, and they forget/ignore/do it badly. Clearly Walter is a self-confessed mediocre build czar at best. But he's doing it because, although there is no shortage of suggestions on how he should be doing it, nobody has the time and inclination to actually _be_ the build czar (which is entirely understandable). Within a traditional organization where people are paid to work on a certain project, the solution would be simple and obvious - Walter would be relieved of the roles he doesn't excel in, and left to focus on those he's really good at. Other people would fill in duties and responsibilities such as preparing betas, sending them out for testing, announcing them, etc. Within our current organizational landscape, where nobody is paid to work on D (not _with_ D) except for myself, addressing issues such as we should have a better build master is much more difficult to address. Third, for what it's worth, here's what I believe are the top issues with D today: 1. Nobody is being paid to work on D (aside from me since recently, and on work that would benefit my employer). 2. D is not backed up solidly by a large engineering organization. 3. We are unable to review and accept contributions at the rate they are arriving. I tend to ask myself how various proposals for improving our process address these three key points. I believe your list effects mostly (3), albeit not directly. More answers inline. - We do not have any vision or major plans ahead for the language. Currently we're stuck in a bug-driven development environment, where bugs are arbitrarily picked off of bugzilla and fixed. But there's no major plans ahead, e.g. let's plan to fix these X major bugs for some upcoming release. We can't force people to work on X or Y, but if they're in a visual place and marked important and scheduled to be fixed, this will give an incentive for contributors to work on these problems. Walter and I frequently think of ways to gently steer people toward working on specific items. Votes, categorization, discussions are of limited impact. On occasion we've emailed major contributors directly and asked politely but point blank if they could look into an issue (sometimes something they had an expertise in, or even an issue they had caused). The rate of success has been very low. People still love working on things, just not on the things they're told to. We've added the preapproved tag - take a look: http://d.puremagic.com/issues/buglist.cgi?quicksearch=preapproved. A couple have opened pull requests, which have not yet received reviews yet (which is not my or Walter's fault as much as a larger community issue that we need to fix, see (3) above). Most don't. You yourself didn't find the time to update a task you volunteered on. That said, it's entirely possible a formula for success does exist. Looking forward to proposals, like improving the visuals of bugs to be fixed. What I think is obvious is that solution involving more work for Walter and myself are unlikely to work well, for the simple reason we are both impatiently waiting for the sun to rise every day to do more work on D. - We do not have any defined release timeline. When is it time to start prepping for a release? It's up to Walter's arbitrary decision for when this happens, he doesn't even talk to the community or contributors on whether it's a good time for a beta phase (maybe there's a huge or disruptive new pull request that's planning to be merged and a beta should be delayed). I understand how that can be a bother. Walter figures the time is ripe for a new release when we have enough compelling features and fixes. I'll try to make the appropriate announcements in the future prior to deciding on starting a beta. - We do not have a defined timeline for the beta testing period. How long before we decide that the beta has been tested for long enough before a release is made? Again, it's up to Walter's decision. We are generally aiming for two weeks, but it sometimes gets longer because of the impending regressions.
Re: Start of dmd 2.064 beta program
On 10/18/2013 12:33 AM, deadalnix wrote: I highly doubt that this fit into cases 1 to 4 as you mention. I'll however double check with that in mind. I want to know about any other cases, so please investigate. That also doesn't explain why I get a closure bug (frame pointer or frame content is corrupted) when compiling with unittest. The code that fail isn't even unittested ! Right, that sounds like some thing else.
Re: Start of dmd 2.064 beta program
On 10/18/2013 11:17 AM, Rory McGuire wrote: Does it even support executable permissions? Yes, it does.
Re: Start of dmd 2.064 beta program
On 18 Oct 2013 21:00, Walter Bright newshou...@digitalmars.com wrote: On 10/18/2013 11:17 AM, Rory McGuire wrote: Does it even support executable permissions? Yes, it does. Nice. It's there any particular reason you prefer zip? I guess it's irrelevant what the current format is if we start using Nick's builder.
Re: Start of dmd 2.064 beta program
I get bitten by it locally too: if there's a test with an inaccurate sql query with time formatted as string, the sql server doesn't always compute it, because the default human-readable time format is taken from the current locale, and to parse it one first has to guess the format itself, which is quite difficult in a heterogeneous system. DATE '2013-10-12' is the date October 12th to most SQL parsers. Locales and NLS in SQL have bitten me many times until I learned this.
Re: Start of dmd 2.064 beta program
On 10/18/2013 12:14 PM, Rory McGuire wrote: Nice. It's there any particular reason you prefer zip? It's easy and works on all platforms. I also point out that, for all platforms supported, when we do a release we also build a custom download package for each platform in that platform's preferred format. If these are inadequate, then bug reports need to be filed and pull requests issued for the package building scripts. I expect that managing all this should be the responsibility of the Build Czar, which is an open position. I guess it's irrelevant what the current format is if we start using Nick's builder. What I prefer is that all the packages are built automatically and daily by Brad's autotester, and that this process is controlled by scripts checked into github and that anyone who wishes to improve it can issue pull requests against it, and the Build Czar makes sure the process is working.
Re: Start of dmd 2.064 beta program
On 10/18/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: nobody has the time and inclination to actually _be_ the build czar (which is entirely understandable). Building something should be a command on the command-line. The whole issue is about currently having a person in place of a tool. You yourself didn't find the time to update a task you volunteered on. You mean https://github.com/D-Programming-Language/dmd/pull/2235 ? I'll get back to it soon. We'll look into it, but this harkens back to the simple dynamics mentioned above. That is essentially a request for Walter to change the way he does releases, and people tend to get set in their ways and have difficulty finding the time to stop and change things when there are so many other things vying for their attention. The best solution here is if Nick (or someone else) would _be_ the build manager using those great tools that Nick wrote. Like I said before, it's a command, you don't need a manager to do it, you need a reliable tool. $ make_build is all it takes. This manager and czar nonsense is really a corporate way of solving issues. I can see how you might have gotten used to that when you have people on a payroll that you can easily asign to a task. Even if ultimately it's beneficial for having a tool in place of a person, a company might decide against it if it can hammer the nail right away and make the problem go away (until the problem comes walking back). We're programmers, we should rely on tools for automated tasks. And I want this not because I'm an automation freak (I'm not), but precisely because Walter has screwed up the zip package many times before. Hence, if Walter is the one who is currently in control, why doesn't he interact with Nick to ease into using a build tool rather than use some X number of scripts that he keeps on his PC only? As a simple start, did you consider announcing the beta yourself? I didn't, because I disliked the current model and tied my hands when I saw the new beta was out due to the sum of frustrations which I've listed. This will change if the situation improves, of course. Anyone can tweet #dlang @D_programming, and in all likelihood we and many others would retweet. Good. I'll certainly start to build a better online presence, including tweeting, and I should start blogging too (there's plenty to blog about w.r.t. D). I can't be the pot calling the kettle black. Also, did you consider submitting a pull request for placing the beta announcement on the homepage? Good idea, and it's something I can work on. But I hope you understand this isn't really about you or Walter not doing these things yourself, but rather the fact that you didn't seem to recognize this as being a problem. I've mentioned the build/release issue many times, and now we finally have a pull request that could make this problem go away. Just as I thought the problem was being resolved, Walter announced the new beta. So clearly he still doesn't see the pull request as being important. Probably that's a good thing to do, and easy enough. I don't think it would push the needle significantly. But that's just the thing. The things I've listed are what pushed the needled too much to the left for me. Small improvements like this are great, and they add up. Otherwise people (like me) will keep complaining about small issues, which collect and add up to the frustration. We can't have a phone conversation with the community. Why do you even need these phone conversations related to D or decision making? The community has an insane number of intelligent people who can contribute to resolving issues. Then, your first three points complain about a lack of leadership, and in the same breath you complain about there being too much of it. Lack of leading the community and the development process, not lack of decision making. Walter scrambled to implement UDAs in a rush and breaking protocol in order to win a corporate D user, Remedy Games. It was a major, exceptional event. Would you have preferred the protocol to have been followed at the cost of Remedy? This is what doesn't inspire me at all. So in the future when company X decides it wants some feature in the language you're saying we should not follow the protocol like we do for all the other user-requested features? Because the news of company X using D will create headlines? I agree that's a problem. Probably what would help would be more quality reviews and pulls by our members with commit rights, of whom you are one. I don't see what this has to do with not understanding Git basics. If I merge more pull requests it isn't going to improve Walter's knowledge of Git. Also, I tend to review pull requests which I actually understand (doing otherwise would be counter-productive). Sometimes I fall behind track because I also want to work on some of my own D projects. I know we're all very busy, but I didn't say Walter didn't want to review
Re: Start of dmd 2.064 beta program
On 10/18/2013 1:29 PM, Andrej Mitrovic wrote: But I hope you understand this isn't really about you or Walter not doing these things yourself, but rather the fact that you didn't seem to recognize this as being a problem. I've mentioned the build/release issue many times, and now we finally have a pull request that could make this problem go away. Just as I thought the problem was being resolved, Walter announced the new beta. So clearly he still doesn't see the pull request as being important. As I've posted elsewhere, I want very much to have the package build process to be a single command. I want Brad's autotester to build those packages as part of its regular build/test runs. I'd like Brad, Nick, Jordi, Jacob, and anyone else involved with the installers to get together to get this done. As to why I didn't do this for the beta zip - because the install package builders break with every new release, and for the initial beta I just wanted to see where we were with the regressions - and there's a lot of work to do just to fix those, before getting to a release candidate. We do need a Build Czar, because the install builds break every time, due to things like failure to update the manifests, new build targets, new features, etc. Somebody has to be responsible for getting all the scripts tested and working again - which is also why I want this to be part of the autotester, so problems will show up sooner. (And heck, just building the zip file exposed a lot of breakage.)
Re: Start of dmd 2.064 beta program
On Friday, October 18, 2013 15:31:05 Walter Bright wrote: We do need a Build Czar, because the install builds break every time, due to things like failure to update the manifests, new build targets, new features, etc. Somebody has to be responsible for getting all the scripts tested and working again - which is also why I want this to be part of the autotester, so problems will show up sooner. (And heck, just building the zip file exposed a lot of breakage.) I would suggest making a very prominent post about this in the newsgroup - that you want a build czar. If you make it clear that the position needs to be filled, and that it's your intention to offload that work to the build czar, then someone may step up to do it - especially if they're unhappy with the current process. Most of the push on that thus far has been towards trying to get you to change what you're doing, and I'm not sure that it's clear enough to everyone that you're ready and willing to have someone else shoulder those responsibilities. And without that being clear, I think that it's a lot less likely for someone to step up and offer to do it. We _have_ had some folks step up to start working on some of it (e.g. Nick with the zip file generation), so maybe making it clear that the position is open and that we want it filled will make it so that someone like that will step up and do it. Sometimes the problem isn't finding someone who's ready and willing but rather making it clear what's needed so that someone who's already ready and willing knows what they can do to help. - Jonathan M Davis
Re: Start of dmd 2.064 beta program
On 17 Oct 2013 00:40, bearophile bearophileh...@lycos.com wrote: Walter Bright: I'll go have myself flogged, then. But please be gentle and use something soft, like a fake snow leopard tail: Surely having to deal with c++ whenever Walter works on dmd is punishment enough :D.
Re: Start of dmd 2.064 beta program
On 2013-10-16 23:16, Jonathan M Davis wrote: Yes, but after Andej did the great changelog for 2.063, Walter publicly admitted that he had been wrong about the changelog. Andrej showed Walter that it _is_ worth doing something more than just a list of bugzilla issues. So, I would assume that whatever Andrej is unhappy with Walter for is something else. Andrej wrote: I'm wondering whether there will be the nifty changelog like it was for 2.063? Andrej? :D We'll see if someone else volunteers to do it. I'm not doing it out of protest. http://forum.dlang.org/thread/l3chnd$1mvs$1...@digitalmars.com?page=4#post-mailman.2221.1381889714.1719.digitalmars-d-announce:40puremagic.com I interpreted that as he originally created the changelog out of protest to Walter's claim that it's not necessary. -- /Jacob Carlborg
Re: Start of dmd 2.064 beta program
On 10/16/13, Brad Roberts bra...@puremagic.com wrote: That's not a what, that's a who. - We do not have any vision or major plans ahead for the language. Currently we're stuck in a bug-driven development environment, where bugs are arbitrarily picked off of bugzilla and fixed. But there's no major plans ahead, e.g. let's plan to fix these X major bugs for some upcoming release. We can't force people to work on X or Y, but if they're in a visual place and marked important and scheduled to be fixed, this will give an incentive for contributors to work on these problems. - We do not have any defined release timeline. When is it time to start prepping for a release? It's up to Walter's arbitrary decision for when this happens, he doesn't even talk to the community or contributors on whether it's a good time for a beta phase (maybe there's a huge or disruptive new pull request that's planning to be merged and a beta should be delayed). - We do not have a defined timeline for the beta testing period. How long before we decide that the beta has been tested for long enough before a release is made? Again, it's up to Walter's decision. Having a defined release cycle and a beta testing period will ultimately be beneficial for everyone. People who are busy can rearrange their schedule to make free time and ensure they have enough time to test a beta compiler on their projects, and contributors to D can prepare for a cycle of days or weeks where they can rapidly work on reducing regressions and polish everything up for the release (e.g. writing an elaborate changelog). - We do not have a proper release system. Nick Sabalausky has been working hard on one[1], but Walter seems to have completely ignored it. It would have been a terrific opportunity to try and make it work for this release. What better way to test it than to test it on a release? - The betas are still not visible. The homepage makes no notes on a new beta being available, the download page does not list the betas either, and AFAICT there's no RSS feed either. The social media groups are not notified either (neither Andrei's nor Walter's twitter feed make a mention of a new beta being out, the same applies to https://twitter.com/D_Programming or the #dlang hash tags). To top it all off, you cannot post to the dmd-beta newsgroups from the D Forums, you have to separately register to this mailing list. If we want user feedback on betas we absolutely must make the betas visible and give an opportunity for people to post feedback. - Walter is still not tagging the beta releases by the file name (it's always dmd2beta.zip). I've complained about this several times and IIRC someone else did as well at dconf (maybe I'm remembering wrong though). They should at least be named as dmd2_064_beta1.zip, dmd2_064_beta2.zip. And all of them should always be available for download (including visibility on the download page), so people who do not use Git or build manually from master can quicky check whether a regression was introduced in a specific beta version. - I still sigh when I hear about Walter and Andrei having private phone conversations, or any kind of decision is made behind-the-scenes rather than publicly where the community has a say in it. Walter's implementation of UDAs directly in master which lead to having a deprecated syntax even though nobody used this syntax is what comes to mind. - Both Walter and Andrei not following the rules and making novice mistakes w.r.t Git and Github. Walter still seems to struggle with basic usage of git, where people continually have to re-explain what's wrong and how to fix an issue. I'm sorry, but if someone bought the Git book years ago and is still struggling with *concepts* then no amount of hand-guiding is going to help. And Andrei doing things like merging a dozen pull requests at once, with complete disregard to the fact that merging to master means other pulls could easily break (and so master can be broken). You cannot make so many merges unless you're absolutely sure each pull request does not interfere with another. - Back to Walter, a few weeks ago he merged a pull request over night, without regard to the pull request not being fully tested by the test machines. The result? Master was broken **for the entire next day**. Nobody knew which commit broke master, so nothing was done until Walter came back to Github the next day and started reverting his pulls. In the meantime the entire day was wasted because nobody's pull request could get green. Luckily it was a sunday, so there weren't too many complaints. But I could have easily merged a few pulls that day (as it happens I like to do things on a sunday), and as a result we would have a smaller pull queue. -- There's just many things that are going plain wrong here, and a lot of promises are always made but ultimately never delivered (whether it's about breaking changes or an improved development process -- again think about scheduling bug fixes
Re: Start of dmd 2.064 beta program
On Wednesday, 16 October 2013 at 17:41:37 UTC, deadalnix wrote: Hum I have several regression is SDC's test suite. I have to investigate more to fix the code or submit bug report. It looks related to AA. What are the changes that affect AA in this new release ? It turns out that is is a closure bug. Sadly, this involve compiling SDC completely and run it on some test data. I can repro consistently, but it seems really hard to get a small repro. I just moved to the US, and am quite busy especially since the gvt shutdown have complicated things quite a bit. Anyway, It is unlikely that I'll have a redux in the next ~2 weeks. I'm not how we should proceed here, but the bug seems serious to me (the worst kind : everything compile fine, bug the codegen is bogus).
Re: Start of dmd 2.064 beta program
On 10/16/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: What are you protesting against? Walter.
Re: Start of dmd 2.064 beta program
On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote: http://ftp.digitalmars.com/dmd2beta.zip Current list of regressions: http://d.puremagic.com/issues/buglist.cgi?query_format=advancedbug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED This isn't a release candidate, in particular the documentation needs work, but we need to shake the tree for any undetected regressions. Further beta announcements go in the dmd-beta mailing list. Note that this release contains: 29 enhancements 307 dmd bugs fixed 14 druntime bugs fixed 73 phobos bugs fixed Hum I have several regression is SDC's test suite. I have to investigate more to fix the code or submit bug report. It looks related to AA. What are the changes that affect AA in this new release ?
Re: Start of dmd 2.064 beta program
On Wednesday, 16 October 2013 at 13:34:04 UTC, Andrej Mitrovic wrote: On 10/16/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: What are you protesting against? Walter. The last change log was awesome. I vote to get rid of Walter. :)
Re: Start of dmd 2.064 beta program
On 10/16/13 6:33 AM, Andrej Mitrovic wrote: On 10/16/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: What are you protesting against? Walter. That's not a what, that's a who. Would you please elaborate on the what and why? I haven't seen any obstructionism coming from anyone in terms of repeating the previous style for this releases notes.
Re: Start of dmd 2.064 beta program
On Wednesday, 16 October 2013 at 20:19:17 UTC, Brad Roberts wrote: That's not a what, that's a who. Would you please elaborate on the what and why? I haven't seen any obstructionism coming from anyone in terms of repeating the previous style for this releases notes. Originally Walter thought it was enough to just list the bugzilla issues. -- /Jacob Carlborg
Re: Start of dmd 2.064 beta program
On Wednesday, October 16, 2013 22:28:41 Jacob Carlborg wrote: On Wednesday, 16 October 2013 at 20:19:17 UTC, Brad Roberts wrote: That's not a what, that's a who. Would you please elaborate on the what and why? I haven't seen any obstructionism coming from anyone in terms of repeating the previous style for this releases notes. Originally Walter thought it was enough to just list the bugzilla issues. Yes, but after Andej did the great changelog for 2.063, Walter publicly admitted that he had been wrong about the changelog. Andrej showed Walter that it _is_ worth doing something more than just a list of bugzilla issues. So, I would assume that whatever Andrej is unhappy with Walter for is something else. - Jonathan M Davis
Re: Start of dmd 2.064 beta program
On Wednesday, 16 October 2013 at 20:28:42 UTC, Jacob Carlborg wrote: On Wednesday, 16 October 2013 at 20:19:17 UTC, Brad Roberts wrote: That's not a what, that's a who. Would you please elaborate on the what and why? I haven't seen any obstructionism coming from anyone in terms of repeating the previous style for this releases notes. Originally Walter thought it was enough to just list the bugzilla issues. -- /Jacob Carlborg He was proved wrong and IIRC correctly quite graciously admitted defeat.
Re: Start of dmd 2.064 beta program
On 10/16/13 2:16 PM, Jonathan M Davis wrote: On Wednesday, October 16, 2013 22:28:41 Jacob Carlborg wrote: On Wednesday, 16 October 2013 at 20:19:17 UTC, Brad Roberts wrote: That's not a what, that's a who. Would you please elaborate on the what and why? I haven't seen any obstructionism coming from anyone in terms of repeating the previous style for this releases notes. Originally Walter thought it was enough to just list the bugzilla issues. Yes, but after Andej did the great changelog for 2.063, Walter publicly admitted that he had been wrong about the changelog. Andrej showed Walter that it _is_ worth doing something more than just a list of bugzilla issues. So, I would assume that whatever Andrej is unhappy with Walter for is something else. Oh that was it? I recall Walter and I discussing two unrelated issue (null pointers and VMs) where I sort of reversed my view and admitted I considered my previous opinions wrong. He mentioned the changelog, and said boy was I wrong about that! So Andrej consider yourself vindicated, in public and in private. Andrei
Re: Start of dmd 2.064 beta program
On Wednesday, 16 October 2013 at 20:28:42 UTC, Jacob Carlborg wrote: On Wednesday, 16 October 2013 at 20:19:17 UTC, Brad Roberts wrote: That's not a what, that's a who. Would you please elaborate on the what and why? I haven't seen any obstructionism coming from anyone in terms of repeating the previous style for this releases notes. Originally Walter thought it was enough to just list the bugzilla issues. -- /Jacob Carlborg http://forum.dlang.org/thread/ko84eb$1kfo$1...@digitalmars.com
Re: Start of dmd 2.064 beta program
On 10/16/2013 6:33 AM, Andrej Mitrovic wrote: On 10/16/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: What are you protesting against? Walter. I'll go have myself flogged, then.
Re: Start of dmd 2.064 beta program
Walter Bright: I'll go have myself flogged, then. But please be gentle and use something soft, like a fake snow leopard tail: http://img.photobucket.com/albums/v310/musta.surma/Hpim4850.jpg Bye, bearophile
Re: Start of dmd 2.064 beta program
On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote: http://ftp.digitalmars.com/dmd2beta.zip Current list of regressions: http://d.puremagic.com/issues/buglist.cgi?query_format=advancedbug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED This isn't a release candidate, in particular the documentation needs work, but we need to shake the tree for any undetected regressions. Further beta announcements go in the dmd-beta mailing list. Note that this release contains: 29 enhancements 307 dmd bugs fixed 14 druntime bugs fixed 73 phobos bugs fixed I want to thank you and also especially Kenji who has been crazy fast at fixing the regressions I have encoutered. Now everything work, and several bug I was hitting in 2.063 are fixed. Good job !
Re: Start of dmd 2.064 beta program
On 2013-10-15 07:16, deadalnix wrote: This is for that very reason that I prefers to work with timestamps UTC as much as possible. No timzone hell, no format hell, no nothing. Just convert from user input directly, and convert back to text just before output. Agree. Always work with universal standards internally in your applications. Be it time, date, encodings or whatever. Then convert to and from local formats, as early as possible on input and as late as possible for output. -- /Jacob Carlborg
Re: Start of dmd 2.064 beta program
On Mon, 14 Oct 2013 23:13:25 +0200 monarch_dodra monarchdo...@gmail.com wrote: On Monday, 14 October 2013 at 13:25:23 UTC, Benjamin Thaut wrote: I'm also getting random missing symbol linker errors with both dmd 2.063.2 and dmd 2.064. But only on 32-bit windows. On 64-bit windows it works fine. This is really frustrating... I've encountered this too. I'll try to reduce, but the test case isn't easy. I've been bit by a similar (same?) issue. What I didn't realize is that DMD *doesn't* pass the LIB directories (from sc.ini) into optlink. Optlink *itself* reads sc.ini. So if the optlink being run isn't in the same directory as dmd.exe, then optlink may end up grabbing the wrong sc.ini and therefore the wrong Phobos as well. Hence, weird linker errors for Win32. Relevant issue: http://d.puremagic.com/issues/show_bug.cgi?id=10729
Re: Start of dmd 2.064 beta program
On 2013-10-13 00:16, Walter Bright wrote: http://ftp.digitalmars.com/dmd2beta.zip Current list of regressions: Another one: http://d.puremagic.com/issues/show_bug.cgi?id=11268 -- /Jacob Carlborg
Re: Start of dmd 2.064 beta program
Am 14.10.2013 23:19, schrieb Walter Bright: On 10/14/2013 6:25 AM, Benjamin Thaut wrote: I'm also getting random missing symbol linker errors with both dmd 2.063.2 and dmd 2.064. But only on 32-bit windows. On 64-bit windows it works fine. This is really frustrating... Is it possible you are linking together code compiled with different command line -version or -debug switches? I dind't change anything on the build setup. And it worked with dmd 2.062. Is there now different mangeling depending on the -version and -debug statements?
Re: Start of dmd 2.064 beta program
On 10/15/2013 1:50 AM, Benjamin Thaut wrote: Am 14.10.2013 23:19, schrieb Walter Bright: On 10/14/2013 6:25 AM, Benjamin Thaut wrote: I'm also getting random missing symbol linker errors with both dmd 2.063.2 and dmd 2.064. But only on 32-bit windows. On 64-bit windows it works fine. This is really frustrating... Is it possible you are linking together code compiled with different command line -version or -debug switches? I dind't change anything on the build setup. And it worked with dmd 2.062. Is there now different mangeling depending on the -version and -debug statements? dmd now assumes that templates instantiated by a library module are actually in the library. But if code is turned on and off with -version or -debug command line switches, and different switches are used to compile the library than the importer, then the templates instantiations may not be in the library.
Re: Start of dmd 2.064 beta program
Am 15.10.2013 11:25, schrieb Walter Bright: On 10/15/2013 1:50 AM, Benjamin Thaut wrote: Am 14.10.2013 23:19, schrieb Walter Bright: On 10/14/2013 6:25 AM, Benjamin Thaut wrote: I'm also getting random missing symbol linker errors with both dmd 2.063.2 and dmd 2.064. But only on 32-bit windows. On 64-bit windows it works fine. This is really frustrating... Is it possible you are linking together code compiled with different command line -version or -debug switches? I dind't change anything on the build setup. And it worked with dmd 2.062. Is there now different mangeling depending on the -version and -debug statements? dmd now assumes that templates instantiated by a library module are actually in the library. But if code is turned on and off with -version or -debug command line switches, and different switches are used to compile the library than the importer, then the templates instantiations may not be in the library. The funny thing is, its not a template. Nothing fancy at all. Just a struct with two members. And the linker complains that the __init member of that struct is missing. Error 42: Symbol Undefined _D6thBase6plugin8ScanPair6__initZ Also the library and importer are compiled with exactly the same -debug and -version switches. I did setup a dustmite reduce process but its going to take a few hours for that to complete. Kind Regards Benjamin Thaut
Re: Start of dmd 2.064 beta program
On 10/15/13 7:15 PM, Andrej Mitrovic wrote: On 10/13/13, Tourist grava...@gravatar.com wrote: I'm wondering whether there will be the nifty changelog like it was for 2.063? Andrej? :D We'll see if someone else volunteers to do it. I'm not doing it out of protest. What are you protesting against? Andrei
