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: Facebook is using D in production starting today
On Saturday, 12 October 2013 at 12:08:03 UTC, Todor wrote: On Friday, 11 October 2013 at 05:11:49 UTC, Walter Bright wrote: On 10/10/2013 10:05 PM, Nick Sabalausky wrote: Awesome! Great bragging rights for D :) It's the first battle signaling the end of Middle Earth, and the rise of the Age of D. The old guard will be sailing to the Grey Havens soon. They're taking the Hobbits to Isengard! Actually, I think this development is akin to the March of the Ents. They spend a long time thinking and are slow to rouse ... but when they are roused ... :-P https://www.youtube.com/watch?v=h5YwMpSN6CU
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: Mono-D 0.5.4.1 - Build, completion other fixes + Unittests via rdmd
On Wed, Oct 16, 2013 at 2:21 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 10/16/13 5:38 AM, Bruno Medeiros wrote: On 08/10/2013 14:18, Alexander Bothe wrote: Are there any plans/tricks/hacks on how to get programs built with dmd debuggable with gdb? Then we also could release the addin for Windows as well! (Afaik I asked the same question some time ago, but well, perhaps something did change over the time :-)) I was wondering the same as well... But from the lack of answers I think not much can be done? :/ What are the matters involved? I did get basic debugging sessions working, but I forgot whether it was dmd or gdc. Andrei on OSX, lldb has better support than gdb.
Re: code.dlang.org now supports categories and search - license information now required
On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig wrote: There has been another important change that requires existing packages to be updated: All packages must now have the fields description and license present to be published. The license field has to be set according to the specification [1]. All existing branches and version tags stay unaffected by this requirement and are still available. This change has been done to prepare for an automated validation of license terms in complex dependency hierarchies. This may be an important feature as the number of available packages grows, which is why this requirement has been introduced now as early as possible. [1]: http://code.dlang.org/package-format#licenses A little addition: allow use full license name, not only short name: `BSL-1.0` or `Boost Software License 1.0` `AFL-3.0` or `Academic Free License 3.0` It simplify creation of human-readable license name. Add `public domain` license. Add abbility to add the array with licenses: license: [BSL-1.0, AFL-3.0, public domain] I think it's better than license: BSL-1.0 or AFL-3.0 or public domain
Re: code.dlang.org now supports categories and search - license information now required
Am 17.10.2013 11:55, schrieb ilya-stromberg: On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig wrote: There has been another important change that requires existing packages to be updated: All packages must now have the fields description and license present to be published. The license field has to be set according to the specification [1]. All existing branches and version tags stay unaffected by this requirement and are still available. This change has been done to prepare for an automated validation of license terms in complex dependency hierarchies. This may be an important feature as the number of available packages grows, which is why this requirement has been introduced now as early as possible. [1]: http://code.dlang.org/package-format#licenses A little addition: allow use full license name, not only short name: `BSL-1.0` or `Boost Software License 1.0` `AFL-3.0` or `Academic Free License 3.0` It simplify creation of human-readable license name. How about letting the registry display the full name, but keep the short name for package descriptions? Having a single compact name reduces the chances for errors or ambiguities and reduces the amount of mapping code that is needed when reasoning about licenses. My initial idea was to fuzzy match licenses and also allow alternatives like GPLv2 instead of GPL-2.0, but in the end it just increases the potential for mistakes. Add `public domain` license. Will do. Add abbility to add the array with licenses: license: [BSL-1.0, AFL-3.0, public domain] I think it's better than license: BSL-1.0 or AFL-3.0 or public domain There will still be the need to specify or later, so this will only make it partially more structured. I'm a little undecided on this one.
Re: code.dlang.org now supports categories and search - license information now required
On Thursday, 17 October 2013 at 10:07:40 UTC, Sönke Ludwig wrote: Am 17.10.2013 11:55, schrieb ilya-stromberg: On Thursday, 17 October 2013 at 09:33:46 UTC, Sönke Ludwig wrote: There has been another important change that requires existing packages to be updated: All packages must now have the fields description and license present to be published. The license field has to be set according to the specification [1]. All existing branches and version tags stay unaffected by this requirement and are still available. This change has been done to prepare for an automated validation of license terms in complex dependency hierarchies. This may be an important feature as the number of available packages grows, which is why this requirement has been introduced now as early as possible. [1]: http://code.dlang.org/package-format#licenses A little addition: allow use full license name, not only short name: `BSL-1.0` or `Boost Software License 1.0` `AFL-3.0` or `Academic Free License 3.0` It simplify creation of human-readable license name. How about letting the registry display the full name, but keep the short name for package descriptions? Having a single compact name reduces the chances for errors or ambiguities and reduces the amount of mapping code that is needed when reasoning about licenses. My initial idea was to fuzzy match licenses and also allow alternatives like GPLv2 instead of GPL-2.0, but in the end it just increases the potential for mistakes. OK, maybe you are right. Add `public domain` license. Will do. Add abbility to add the array with licenses: license: [BSL-1.0, AFL-3.0, public domain] I think it's better than license: BSL-1.0 or AFL-3.0 or public domain There will still be the need to specify or later, so this will only make it partially more structured. I'm a little undecided on this one. We can use `+` to indicate or later: license: [BSL-1.0+, AFL-3.0+, public domain] I think it will be clear.
Re: code.dlang.org now supports categories and search - license information now required
Am 17.10.2013 12:14, schrieb ilya-stromberg: Add abbility to add the array with licenses: license: [BSL-1.0, AFL-3.0, public domain] I think it's better than license: BSL-1.0 or AFL-3.0 or public domain There will still be the need to specify or later, so this will only make it partially more structured. I'm a little undecided on this one. We can use `+` to indicate or later: license: [BSL-1.0+, AFL-3.0+, public domain] I think it will be clear. Fair enough, that should work. But one potential issue just occurred to me. What if a product is licensed under multiple licenses that must _all_ apply? That would basically be MPL-2.0 and Apache-1.0 instead of or. This is something that happens quite frequently when code is taken from multiple projects or when the license was changed, but some files were under foreign copyright.
Re: code.dlang.org now supports categories and search - license information now required
But one potential issue just occurred to me. What if a product is licensed under multiple licenses that must _all_ apply? That would basically be MPL-2.0 and Apache-1.0 instead of or. This is something that happens quite frequently when code is taken from multiple projects or when the license was changed, but some files were under foreign copyright. A lot of projects have per-file license specifics.
Re: code.dlang.org now supports categories and search - license information now required
On Thursday, 17 October 2013 at 10:39:45 UTC, Sönke Ludwig wrote: But one potential issue just occurred to me. What if a product is licensed under multiple licenses that must _all_ apply? That would basically be MPL-2.0 and Apache-1.0 instead of or. This is something that happens quite frequently when code is taken from multiple projects or when the license was changed, but some files were under foreign copyright. It's impossible. For example, GPL-2.0 and GPL-3.0 are incompatible. So, if user requires both GPL-2.0 AND GPL-3.0, it means that we have invalid license items. So, we should provide only OR modifier, not AND. And I agree with ponce: we should provide a per-file license specifics, it should solve your problem.
Re: code.dlang.org now supports categories and search - license information now required
Am 17.10.2013 13:42, schrieb ilya-stromberg: On Thursday, 17 October 2013 at 10:39:45 UTC, Sönke Ludwig wrote: But one potential issue just occurred to me. What if a product is licensed under multiple licenses that must _all_ apply? That would basically be MPL-2.0 and Apache-1.0 instead of or. This is something that happens quite frequently when code is taken from multiple projects or when the license was changed, but some files were under foreign copyright. It's impossible. For example, GPL-2.0 and GPL-3.0 are incompatible. So, if user requires both GPL-2.0 AND GPL-3.0, it means that we have invalid license items. So, we should provide only OR modifier, not AND. And I agree with ponce: we should provide a per-file license specifics, it should solve your problem. If you have per-file differences, then this in fact means that both licenses need to be obeyed when using the package. If those licenses are incompatible, that's a problem of the package combining them - it's basically unusable then. But going a per-file way is by-far too detailed. It's hard enough to assure proper per-package licensing and keeping license comments up to date, but this will IMO just result in chaos. Also, while GPL 2 and 3 may not be compatible, there are other licenses which are compatible, but one is not a superset of the other.
Re: code.dlang.org now supports categories and search - license information now required
On Thursday, 17 October 2013 at 12:06:49 UTC, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that
both licenses need to be obeyed when using the package. If
those licenses are incompatible, that's a problem of the
package combining them - it's basically unusable then. But
going a per-file way is by-far too detailed. It's hard enough
to assure proper per-package licensing and keeping license
comments up to date, but this will IMO just result in chaos.
Also, while GPL 2 and 3 may not be compatible, there are other
licenses which are compatible, but one is not a superset of the
other.
OK, understand your position. May be just provide special syntax
for this cases, for example:
license: [{BSL-1.0, MIT}]
Re: code.dlang.org now supports categories and search - license information now required
On 10/17/13, Sönke Ludwig slud...@outerproduct.org wrote: Having a single compact name reduces the chances for errors Speaking of which, if I forget to add the license to a package file is there any way to get this information from the server? I mean like a page saying that my package was rejected because it's missing X or Y, rather than having to guess whether the package file is bad or the server is just temporarily overloaded. Personally I think it would be better if we had a dub publish command, which would then error back if the server rejects the package, rather than make this whole process automated based on searching github (I assume this is how the dub server works now).
Re: code.dlang.org now supports categories and search - license information now required
Am 17.10.2013 14:13, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 12:06:49 UTC, Sönke Ludwig wrote:
If you have per-file differences, then this in fact means that both
licenses need to be obeyed when using the package. If those licenses
are incompatible, that's a problem of the package combining them -
it's basically unusable then. But going a per-file way is by-far too
detailed. It's hard enough to assure proper per-package licensing and
keeping license comments up to date, but this will IMO just result in
chaos.
Also, while GPL 2 and 3 may not be compatible, there are other
licenses which are compatible, but one is not a superset of the other.
OK, understand your position. May be just provide special syntax for
this cases, for example:
license: [{BSL-1.0, MIT}]
It would have to be still valid JSON. So something like
license: {or: [{and: [BSL-1.0, MIT]}, GPL-2.0]}
would work. But that is hardly more practical than
license: BSL-1.0 and MIT or GPL-2.0
With the advantage of not requiring operator precedence, though.
Re: code.dlang.org now supports categories and search - license information now required
Am 17.10.2013 14:25, schrieb Andrej Mitrovic: Personally I think it would be better if we had a dub publish command, which would then error back if the server rejects the package, rather than make this whole process automated based on searching github (I assume this is how the dub server works now). dub publish sounds like something that may considerably increase the complexity of the command line tool, especially in the long term, and it also increases the coupling to the public registry, whereas now it just needs a very small HTTP API that can be fulfilled by any HTTP file server. So I'd rather want to avoid that if possible.
Re: code.dlang.org now supports categories and search - license information now required
Am 17.10.2013 14:25, schrieb Andrej Mitrovic: On 10/17/13, Sönke Ludwig slud...@outerproduct.org wrote: Having a single compact name reduces the chances for errors Speaking of which, if I forget to add the license to a package file is there any way to get this information from the server? I mean like a page saying that my package was rejected because it's missing X or Y, rather than having to guess whether the package file is bad or the server is just temporarily overloaded. Personally I think it would be better if we had a dub publish command, which would then error back if the server rejects the package, rather than make this whole process automated based on searching github (I assume this is how the dub server works now). When you log in on the website and then go to My packages, you'll see a table of all packages along with excerpts of possible errors. You can then click on each package to see the full list of errors. There is also a button to trigger a manual update after changes now, so that the usual uncertain wait is not necessary anymore.
Re: code.dlang.org now supports categories and search - license information now required
On Thursday, 17 October 2013 at 12:27:02 UTC, Sönke Ludwig wrote:
Am 17.10.2013 14:13, schrieb ilya-stromberg:
On Thursday, 17 October 2013 at 12:06:49 UTC, Sönke Ludwig
wrote:
If you have per-file differences, then this in fact means
that both
licenses need to be obeyed when using the package. If those
licenses
are incompatible, that's a problem of the package combining
them -
it's basically unusable then. But going a per-file way is
by-far too
detailed. It's hard enough to assure proper per-package
licensing and
keeping license comments up to date, but this will IMO just
result in
chaos.
Also, while GPL 2 and 3 may not be compatible, there are other
licenses which are compatible, but one is not a superset of
the other.
OK, understand your position. May be just provide special
syntax for
this cases, for example:
license: [{BSL-1.0, MIT}]
It would have to be still valid JSON. So something like
license: {or: [{and: [BSL-1.0, MIT]}, GPL-2.0]}
would work. But that is hardly more practical than
license: BSL-1.0 and MIT or GPL-2.0
With the advantage of not requiring operator precedence, though.
We can use or as default. So, your example:
license: [{and: [BSL-1.0, MIT]}, GPL-2.0]
Yes, the example
license: BSL-1.0 and MIT or GPL-2.0
looks better, but what about more complex cases:
license: BSL-1.0 and MIT or GPL-2.0 and BSL-1.0
What does it mean?
Re: code.dlang.org now supports categories and search - license information now required
On 2013-10-17 14:33, Sönke Ludwig wrote: dub publish sounds like something that may considerably increase the complexity of the command line tool, especially in the long term, and it also increases the coupling to the public registry, whereas now it just needs a very small HTTP API that can be fulfilled by any HTTP file server. So I'd rather want to avoid that if possible. You could have something like this: dub publish git-tag Should be much difference compare to how it works now. It would just trigger the server to look for that tag, instead of doing it automatically. -- /Jacob Carlborg
Re: code.dlang.org now supports categories and search - license information now required
On 2013-10-17 11:33, Sönke Ludwig wrote: There has been another important change that requires existing packages to be updated: All packages must now have the fields description and license present to be published. The license field has to be set according to the specification [1]. All existing branches and version tags stay unaffected by this requirement and are still available. Perhaps add the license: Apple Public Source License. This can be useful for creating bindings to Apple specific libraries. Is there a corresponding license for Microsoft? -- /Jacob Carlborg
Re: code.dlang.org now supports categories and search - license information now required
Am 17.10.2013 15:26, schrieb Jacob Carlborg: On 2013-10-17 14:06, Sönke Ludwig wrote: If you have per-file differences, then this in fact means that both licenses need to be obeyed when using the package. Not necessarily. There can be two completely separated targets, that don't share any code. I don't know if that's possible in Dub, but in theory it would be. Not necessarily, but possibly, so it probably has to cope with it. One possibility to handle your example would be to make different sub packages for the two targets.
Re: code.dlang.org now supports categories and search - license information now required
On Thursday, 17 October 2013 at 13:31:06 UTC, Jacob Carlborg wrote: On 2013-10-17 11:33, Sönke Ludwig wrote: There has been another important change that requires existing packages to be updated: All packages must now have the fields description and license present to be published. The license field has to be set according to the specification [1]. All existing branches and version tags stay unaffected by this requirement and are still available. Perhaps add the license: Apple Public Source License. This can be useful for creating bindings to Apple specific libraries. Is there a corresponding license for Microsoft? Yes: Microsoft Public License (Ms-PL) Microsoft Reciprocal License (Ms-RL) http://en.wikipedia.org/wiki/Shared_source
Re: code.dlang.org now supports categories and search - license information now required
Am 17.10.2013 15:28, schrieb Jacob Carlborg: On 2013-10-17 14:33, Sönke Ludwig wrote: dub publish sounds like something that may considerably increase the complexity of the command line tool, especially in the long term, and it also increases the coupling to the public registry, whereas now it just needs a very small HTTP API that can be fulfilled by any HTTP file server. So I'd rather want to avoid that if possible. You could have something like this: dub publish git-tag Should be much difference compare to how it works now. It would just trigger the server to look for that tag, instead of doing it automatically. Well, the other issue with that is that there is no guarantee that the server can fulfill the request in a timely manner. It may be busy getting information about other packages/tags/branches which makes it impossible to get direct feedback. What about an e-mail notification, though? Seems like the most natural channel.
Re: code.dlang.org now supports categories and search - license information now required
The only license JSON that looks valid is the string. Simple bracketing will suffice for complex licenses. On 17 Oct 2013 16:05, Sönke Ludwig slud...@outerproduct.org wrote: Am 17.10.2013 15:28, schrieb Jacob Carlborg: On 2013-10-17 14:33, Sönke Ludwig wrote: dub publish sounds like something that may considerably increase the complexity of the command line tool, especially in the long term, and it also increases the coupling to the public registry, whereas now it just needs a very small HTTP API that can be fulfilled by any HTTP file server. So I'd rather want to avoid that if possible. You could have something like this: dub publish git-tag Should be much difference compare to how it works now. It would just trigger the server to look for that tag, instead of doing it automatically. Well, the other issue with that is that there is no guarantee that the server can fulfill the request in a timely manner. It may be busy getting information about other packages/tags/branches which makes it impossible to get direct feedback. What about an e-mail notification, though? Seems like the most natural channel.
Re: code.dlang.org now supports categories and search - license information now required
On Thursday, 17 October 2013 at 13:26:06 UTC, Jacob Carlborg wrote: On 2013-10-17 14:06, Sönke Ludwig wrote: If you have per-file differences, then this in fact means that both licenses need to be obeyed when using the package. Not necessarily. There can be two completely separated targets, that don't share any code. I don't know if that's possible in Dub, but in theory it would be. I have an example of such a thing, but honestly I don't think dub should go that much far. Just providing the superset of what licenses a package _might_ fall under is already useful.
Re: code.dlang.org now supports categories and search - license information now required
On 2013-10-17 15:44, Sönke Ludwig wrote: Not necessarily, but possibly, so it probably has to cope with it. One possibility to handle your example would be to make different sub packages for the two targets. What's happens then with the main/super package, in regards to licensing? -- /Jacob Carlborg
Re: code.dlang.org now supports categories and search - license information now required
On 2013-10-17 15:53, Sönke Ludwig wrote: Added APSL-2.0 (Apple Public Source License) and MS-PL (Microsoft Public License). Cool, thanks. -- /Jacob Carlborg
Re: code.dlang.org now supports categories and search - license information now required
Am 17.10.2013 16:59, schrieb Jacob Carlborg: On 2013-10-17 15:44, Sönke Ludwig wrote: Not necessarily, but possibly, so it probably has to cope with it. One possibility to handle your example would be to make different sub packages for the two targets. What's happens then with the main/super package, in regards to licensing? It's independent as long as it doesn't explicitly add the submodules as dependencies. If it does add them, it would have to add both licenses. But other packages can still only reference a sub package if they want.
Re: code.dlang.org now supports categories and search - license information now required
Am 17.10.2013 17:02, schrieb Sönke Ludwig: Am 17.10.2013 16:59, schrieb Jacob Carlborg: On 2013-10-17 15:44, Sönke Ludwig wrote: Not necessarily, but possibly, so it probably has to cope with it. One possibility to handle your example would be to make different sub packages for the two targets. What's happens then with the main/super package, in regards to licensing? It's independent as long as it doesn't explicitly add the submodules as dependencies. If it does add them, it would have to add both licenses. But other packages can still only reference a sub package if they want. s/only reference a/just reference a single/
Re: code.dlang.org now supports categories and search
Am 16.10.2013 21:01, schrieb Sönke Ludwig: The DUB package registry [1] has finally gained support for the text and category based search of packages. There is also a category for D standard library candidate modules, as has been suggested recently. If you already have any registered packages, please log in and add the proper categories to each of them (My packages - click on package name). Should there be no exact category match, and that specific category is likely to have multiple entries in the future, please make a corresponding pull request against the category file [2] on GitHub. It's still all a little rough around the edges. Any bugs can be reported on the issue tracker [3] or discussed in the forum [4]. [1]: http://code.dlang.org [2]: https://github.com/rejectedsoftware/dub-registry/blob/master/categories.json [3]: https://github.com/rejectedsoftware/dub-registry/issues [4]: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/ Now also with JavaScript support for switching categories and alphabetic sorting.
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).
