Re: D Conference 2012 - postponed until 2013
On Tuesday, 26 June 2012 at 18:12:03 UTC, Walter Bright wrote: On 6/26/2012 8:41 AM, Jonathan M Davis wrote: On Tuesday, June 26, 2012 16:24:24 Dejan Lekic wrote: On 26/06/12 10:17, deadalnix wrote: Le 23/06/2012 22:50, Walter Bright a écrit : Due to there not being sufficient time left to get enough speakers lined up. That is sad. But hopefully, I'll probably be able to participate in 2013. Seattle is too damn far... :( Well, no matter where you pick, it's too far for someone. The Astoria location enables us to keep the registration costs low, without compromising. It's a great location. Walter, I've never been there, but from your word I've no doubt that the Astoria is a nice venue. However, for anyone outside the continental US, this location makes the statement that we're not terribly interested in having you attend: we'll make you take at least two flights (not so many international connections to Portland) or even three (if you don't live near a major air hub in your own country), and then hire a car (there go the savings you got with the cheap registration cost) to drive for 2+ hours after you get off your international flight. Even from a hub location in Europe, this will typically mean 15 or more hours between the airports, plus an unfamiliar drive through Oregon. That's quite a demand on attendees. Astoria is a niche location. If you want to broaden your audience, I think a more mainstream location would generate more interest internationally, and perhaps even domestically. For example, even just Portland itself, but perhaps better--and I know it's unoriginal--Silicon Valley or US East Coast. Thanks, Michael PS Is there an announce mailing list where one can sign up to get information about the 2013 conference?
Re: Coming Soon: Stable D Releases!
On 16/07/12 09:51, Adam Wilson wrote: As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos. So what is a stable release? A stable release is a complete build of DMD, DRuntime, and Phobos that ONLY includes the latest bug-fixes and non-breaking enhancements to existing features. It will not include, new features, breaking enhancements, and any other code that the core development team may be working on. I'm not actually sure what this means. I fear that it may be motivated by an inaccurate assessment of the current situation. The existing instability comes almost entirely from Phobos, not from the compiler. Historically there have been very few instances where you might want to choose an older compiler in preference to the latest release. As I've said before, the one time when a language change caused *massive* instability was in the attempt to move AAs from language to library -- even though that wasn't even supposed to affect existing code in any way. The other thing that typically causes regressions is fixes to forward-reference bugs. Historically, addition of new language features has NOT caused instability. What has been true is that features have been added to the compiler before they were really usable, but they have not broken existing code. Fairly obviously the 64 bit compiler was quite buggy when initially released. But even that massive change wasn't much more buggy than the library AAs! So I am not sure that you can correctly guess where instability will come from. In summary -- I would not expect your stable DMD to be very different from the normal DMD. Phobos is where the instability issue is.
Re: D Conference 2012 - postponed until 2013
On 7/24/2012 1:04 AM, Michael Kerrisk wrote: However, for anyone outside the continental US, this location makes the statement that we're not terribly interested in having you attend: we'll make you take at least two flights (not so many international connections to Portland) or even three (if you don't live near a major air hub in your own country), and then hire a car (there go the savings you got with the cheap registration cost) to drive for 2+ hours after you get off your international flight. Even from a hub location in Europe, this will typically mean 15 or more hours between the airports, plus an unfamiliar drive through Oregon. That's quite a demand on attendees. Astoria is a niche location. If you want to broaden your audience, I think a more mainstream location would generate more interest internationally, and perhaps even domestically. For example, even just Portland itself, but perhaps better--and I know it's unoriginal--Silicon Valley or US East Coast. How about Seattle? Thanks, Michael PS Is there an announce mailing list where one can sign up to get information about the 2013 conference? You can follow D_Programming on twitter.
Re: Coming Soon: Stable D Releases!
On Monday, 16 July 2012 at 19:35:47 UTC, Andrei Alexandrescu wrote: I agree this would be more direct. But I fail to see how Walter cherry-picking stuff is basically no additional work, whereas Adam doing essentially the same is an unenviable amount of labor. The difference is Walter (and other developers) knows his changes intimately. The whole point of dlang-stable is to deliver bug-fixes more quickly. To make this work developers should fix bugs in separate branch, and do separate commit (IIUC, which I'm not quite sure). So it's virtually zero effort on their side. On the other hand, Adam must look at this code really closely. Now add to the picture other developers whom changes Adam will need to examine too. All of his D-love energy will be consumed by maybe 5 developers. And I don't understand what benefits are (given zero effort for developers). This doesn't scale. At some point number of the compiler developers will be 100 times then it is now. And that will require 100 times more Adams to handle the stream. Besides, if Walter is at the same time doing things and deciding their category may work worse than a small team making the assessment by consensus. That (few people reviewing same patches) would scale even worse. B.t.w. how does Linux kernel people handle this ?
Re: pfft 0.1
jerro: I haven't talked to Andrei or others about changing it, but I am willing to write a patch that changes the API, if it would be decided that would be the best thing to do. Given your willingness to work, and the days since you wrote that, maybe we have to write this little proposal again in the main D newsgroup. Bye, bearophile
Re: pfft 0.1
On 7/20/12 8:02 PM, jerro wrote: On Friday, 20 July 2012 at 23:36:37 UTC, bearophile wrote: Is it worth changing the Phobos API to something similar to this API? Pfft already includes an API that is compatible with the Phobos one (pfft.stdapi). But I don't think it makes any sense to change the Phobos API to something like pfft.pfft. The main difference between the two is that std.numeric.Fft uses interleaved format for sequences of complex numbers and pfft.pfft uses a split format. Interleaved format is more convenient in most cases and I think it's more intuitive too. The FFT in Phobos also works on ranges, while pfft.pfft only works on aligned arrays. The only reason the pfft.pfft works the way it does is that it is supposed to be an interface to the underlying implementation with no loss of performance and that is how the implementation works. Even if the implementation in Phobos did use split format, I think it would still be better to use interleaved format for the API. It's just about 30% slower and I think that a nice API is more important for the standard library than a 30% difference in speed. This all is very interesting. Even considering all potential issues and incompatibilities, it might be great to look into integrating Fft into Phobos. Do you think it would work to add it as a high-speed alternative with different format and alignment requirements? Offhand I'd think someone using the FFT is generally interested in speed, and a 30% margin is sensible since the algorithm might be most of some applications' run time. There is one more important difference in the API between std.numeric.Fft and pfft.pfft. With Phobos you can use one instance of Fft for all sizes and types. With pfft.pfft, the Fft class is parametrized with a floating point type and you need a different instance for each size. I think what Phobos does in this case is wrong. The fact that one class works on all floating point types results in very poor precision when the data consists of doubles or reals. I guess that precomputed tables are stored as floats. You could only fix that by saving them as reals, but that would probably hurt performance quite a lot. The fact that one instance can be used for multiple sizes would be a problem if we wanted to change an implementation since not all FFT implementation can use one precomputed table for different data sizes. Do you think Phobos can be fixed in a backwards-compatible way (e.g. provide a template and alias it to the old name)? Andrei
Re: D Conference 2012 - postponed until 2013
On Tue, 24 Jul 2012 02:12:05 -0700, Walter Bright newshou...@digitalmars.com wrote: On 7/24/2012 1:04 AM, Michael Kerrisk wrote: However, for anyone outside the continental US, this location makes the statement that we're not terribly interested in having you attend: we'll make you take at least two flights (not so many international connections to Portland) or even three (if you don't live near a major air hub in your own country), and then hire a car (there go the savings you got with the cheap registration cost) to drive for 2+ hours after you get off your international flight. Even from a hub location in Europe, this will typically mean 15 or more hours between the airports, plus an unfamiliar drive through Oregon. That's quite a demand on attendees. Astoria is a niche location. If you want to broaden your audience, I think a more mainstream location would generate more interest internationally, and perhaps even domestically. For example, even just Portland itself, but perhaps better--and I know it's unoriginal--Silicon Valley or US East Coast. How about Seattle? Seattle has MANY more international connections than Portland (source: I am a certified commercial multi-engine pilot in the Seattle area.) Airlines with direct international flights From Europe and Asia to Seattle: All Nippon Airways Asiana Airlines British Airways Condor Delta Air Lines (primarily to Asia) Emirates EVA Air Hainan Airlines Icelandair Korean Air Lufthansa Airlines United Airlines (primarily to Asia) For the European D users, Lufthansa and British Airways have the best flight schedules and most frequencies. Although if you aren't located near a hub city for these airlines you will still have to make one connection. For Asian D users, you're options are wide open. NOTE: I am not attempting to advocate one location over the other as I live in Seattle and can drive to Astoria, it's actually quite a fun drive. I am merely pointing out that for international arrivals, Sea-Tac probably IS the better option. Thanks, Michael PS Is there an announce mailing list where one can sign up to get information about the 2013 conference? You can follow D_Programming on twitter. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Coming Soon: Stable D Releases!
On Tue, 24 Jul 2012 01:50:02 -0700, Don Clugston d...@nospam.com wrote: On 16/07/12 09:51, Adam Wilson wrote: As a result of the D Versioning thread, we have decided to create a new organization on Github called dlang-stable. This organization will be responsible for maintaining stable releases of DMD, DRuntime, and Phobos. So what is a stable release? A stable release is a complete build of DMD, DRuntime, and Phobos that ONLY includes the latest bug-fixes and non-breaking enhancements to existing features. It will not include, new features, breaking enhancements, and any other code that the core development team may be working on. I'm not actually sure what this means. I fear that it may be motivated by an inaccurate assessment of the current situation. The existing instability comes almost entirely from Phobos, not from the compiler. Historically there have been very few instances where you might want to choose an older compiler in preference to the latest release. As I've said before, the one time when a language change caused *massive* instability was in the attempt to move AAs from language to library -- even though that wasn't even supposed to affect existing code in any way. The other thing that typically causes regressions is fixes to forward-reference bugs. Historically, addition of new language features has NOT caused instability. What has been true is that features have been added to the compiler before they were really usable, but they have not broken existing code. Fairly obviously the 64 bit compiler was quite buggy when initially released. But even that massive change wasn't much more buggy than the library AAs! So I am not sure that you can correctly guess where instability will come from. In summary -- I would not expect your stable DMD to be very different from the normal DMD. Phobos is where the instability issue is. There are three issues we are trying to address: The first and largest issue is the long and variable periods between DMD releases. By the end of the 2.060 Beta period there will have been at least 3.5 months since 2.059. And while for the people who can use Git HEAD this may not be a problem, there are MANY who, for whatever reason, must use the released versions. For them the 314 resolved issues and dozens of regressions fixed are a tantalizingly out of reach. The second issue is the root of the first. Much of the delay was caused by Walter starting to work on COFF. Which brings up the second point of contention in the community, a significant number of bugs are typically introduced when this new work is introduced precisely because it's not ready, and the effort required to make it stable would significantly delay the release, which loops back to the first problem of release cadence. Yes, D is more stable than ever, but we keep breaking it to push bugfix builds because the community starts to get restless without bugfixes. Which is the whole reason this stable project got started. The third is the result of the first two. The slow release cadence combined with the requirement to push new features along side bug-fixes is seriously holding back the growth of the D community. There is a feeling out here that D is lurching unsteadily forward when it should be smoothly accelerating and most of this feeling is rooted in the prior two causes. This has a very corrosive effect on the community and particularly their willingness to contribute. The goal of dlang-stable is to provide the primary development team (you!) with the ability to release whenever you feel a new feature or enhancement is stable enough to be released WITHOUT having to worry about the ever growing number of bugfixes that are backlogged in with the new features. We are trying to reduce the bugfix pressure so that you can focus on delivering high-quality code when it's ready. The community WANTS these new features, but we CAN'T wait 3.5 months (or more!) for the bugfixes that are baked in with them. We have to provide BOTH. That is dlang-stable. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: pfft 0.1
This all is very interesting. Even considering all potential issues and incompatibilities, it might be great to look into integrating Fft into Phobos. Do you think it would work to add it as a high-speed alternative with different format and alignment requirements? Offhand I'd think someone using the FFT is generally interested in speed, and a 30% margin is sensible since the algorithm might be most of some applications' run time. If we were integrating pfft into Phobos, it would be best to replace the current implementation completely. Pfft already includes an API that is Phobos compatible (it deinterleaves and copies the input to an internal buffer and then interleaves the result and copies it to the output buffer when it's done). This interface is slower than the in place, split format interface, but is still a lot faster than the current Phobos implementation if SIMD operations are available. I guess it wouldn't hurt to also add split format, in place functions which would require aligned arrays for those who need every bit of performance. Do you think Phobos can be fixed in a backwards-compatible way (e.g. provide a template and alias it to the old name)? After thinking about it a bit I think that it would be best to solve this using lazy initialization. Users probably don't care that much whether the internal data is computed in the or just before computing the first transform. That way the API doesn't need to be changed.
Re: pfft 0.1
Nice work. Just did the usual advertising in HN and Reddit, http://news.ycombinator.com/item?id=4286257 http://www.reddit.com/r/programming/comments/x2tt8/pfft_a_fast_fourier_transform_written_in_d/ -- Paulo Thanks.
