Re: dmd 2.057 release
On 2011-12-15 22:28, Don wrote: On 15.12.2011 21:34, Jacob Carlborg wrote: On 2011-12-15 20:25, Walter Bright wrote: On 12/15/2011 4:16 AM, Jacob Carlborg wrote: I wonder if we can list breaking changes in a separate sections in the changelog. Any bug fix is a breaking change - code can and does depend on bugs (often inadvertently). In this particular case it could just have been a design decision that has changed. And BTW, deprecating typdef can't be considered a bug fix, that would be perfect for a list of breaking changes. Deprecating typedef is in the list of changed features, not in the list of fixed bugs. Choosing which list things go in is sometimes a bit arbitrary, though. Occasionally in the changelog, major breaking changes were shown in red. That hasn't happened for ages. Yes, I noticed typedef in the list, but in this case it would have been nice if it had its own section in the list. I know that typedef has been "deprecated" for a while but I had no idea it would be official in this release. -- /Jacob Carlborg
Re: Programming Windows D Examples are now Online!
On 6/21/11, Andrej Mitrovic wrote: > This is a translation project of Charles Petzold's Programming Windows > (5th edition) book code samples. > > Currently over 120 code samples have been translated into D, with only > a few modules remaining. > > Everything else you need to know is in the Readme file: > https://github.com/AndrejMitrovic/DWinProgramming > > The examples were tested on fresh installs of XP and Win7 with the > only dependency being DMD v2.053 and an NT operating system. I hope > everyone will be able to build these examples without too much > trouble. *crosses fingers* > Update: The cool news is that most samples now build via GDC, you will need to download the latest GDC (there's a new one from a few hours ago), from: https://bitbucket.org/goshawk/gdc/downloads (tested with https://bitbucket.org/goshawk/gdc/downloads/gcc-4.6.1-tdm-1-gdc-7e22befef29c-20111215.7z). You will also need to install Perl (GDMD is still a perl script) and copy the gdmd.bat batch file to GDC's bin dir. There's also a couple of new samples unrelated to the book.
Re: dmd 2.057 release
On 15.12.2011 21:34, Jacob Carlborg wrote: On 2011-12-15 20:25, Walter Bright wrote: On 12/15/2011 4:16 AM, Jacob Carlborg wrote: I wonder if we can list breaking changes in a separate sections in the changelog. Any bug fix is a breaking change - code can and does depend on bugs (often inadvertently). In this particular case it could just have been a design decision that has changed. And BTW, deprecating typdef can't be considered a bug fix, that would be perfect for a list of breaking changes. Deprecating typedef is in the list of changed features, not in the list of fixed bugs. Choosing which list things go in is sometimes a bit arbitrary, though. Occasionally in the changelog, major breaking changes were shown in red. That hasn't happened for ages.
Re: New homepage design of d-p-l.org is now live.
On 2011-12-14 10:55:26 +, Robert Clipsham said: On 14/12/2011 10:12, Andrei Alexandrescu wrote: On 12/12/11 7:46 PM, Stewart Gordon wrote: On 06/12/2011 05:44, Andrei Alexandrescu wrote: http://d-p-l.org Andrei Why does it have an HTML 4.01 doctype but then go on to use XHTML syntax??? Stewart. I wouldn't know. What needs to be done? Andrei http://validator.w3.org/check?uri=http%3A%2F%2Fwww.d-programming-language.org%2F&charset=%28detect+automatically%29&doctype=Inline&group=0 ( http://goo.gl/pxtQE - the same link, just in case the above one gets wrapped and doesn't work) Basically, xHTML uses , html uses or depending on the tag. The rest of the issues are with non-standard tags, eg and I think. HTML 5 says and are equivalent and both valid for elements that are not expected to have a closing tag. What happens in practice, with any HTML version, is that browsers just ignore the "/". Maybe using the HTML 5 doctype will make the validator happier (although it might start to complain about other things): -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: dmd 2.057 release
On 2011-12-15 20:25, Walter Bright wrote: On 12/15/2011 4:16 AM, Jacob Carlborg wrote: I wonder if we can list breaking changes in a separate sections in the changelog. Any bug fix is a breaking change - code can and does depend on bugs (often inadvertently). In this particular case it could just have been a design decision that has changed. And BTW, deprecating typdef can't be considered a bug fix, that would be perfect for a list of breaking changes. -- /Jacob Carlborg
Re: dmd 2.057 release
On 12/15/2011 6:31 AM, Adrian wrote: Am 15.12.2011 12:31, schrieb Stephan: On 15.12.2011 12:02, Adrian wrote: - for the crash to happen the project has to be compiled with the switches -noboundscheck and -deps="bug.dep". if you omit one of them the crash wont show. sounds like this one i encountered last release already: http://d.puremagic.com/issues/show_bug.cgi?id=6951 yes looks pretty much the same. Its total weired, because it seems to depend on code which is elsewhere. How about adding your bug.zip to that report?
Re: dmd 2.057 release
On 12/15/2011 4:16 AM, Jacob Carlborg wrote: I wonder if we can list breaking changes in a separate sections in the changelog. Any bug fix is a breaking change - code can and does depend on bugs (often inadvertently).
Re: libffi-d: D binding to libffi
On 15-12-2011 09:14, Alex Rønne Petersen wrote: Hi Andrej, Sorry for the late response (for some reason, my news reader had marked this thread as read). > There's a few DLL's floating around for libffi, however none of them > seem to have the symbol "ffi_prep_cif_var" which seems to be needed > for variadic functions. > > I can version variadic support out and compile your bindings, the > tests will work fine on win32. > I've also tried compiling libffi on my own but had no success. ffi_prep_cif_var doesn't seem to be available in any Windows builds (Cygwin, MinGW, or otherwise) of libffi for whatever reason. I'll version it out on Windows for now, as you suggested. I haven't managed to get a MinGW build of libffi working so far, but I did manage to get one working under Cygwin. Build libffi like this: $ ./configure --enable-static=yes --enable-shared=no $ make Now you should have i686-pc-cygwin/.libs/libffi.a. You'll also need your Cygwin installation's libgcc.a: $ cd i686-pc-cygwin/.libs $ ar -r libffi.a /lib/gcc/i686-pc-cygwin/4.5.3/libgcc.a Now you need to convert the .a to an OMF .lib. You'll need objconv.zip from this page: http://www.agner.org/optimize/ $ objconv -fomf -nu libffi.a libffi.lib libffi.lib should now be linkable with DMD. (I long for the day DMD doesn't use OMF.) > I can make a pull with the import lib, the DLL (it's only 99KB), and > the versioned out sections, if you'd like that. I prefer keeping the binaries out of Git for various portability, licensing, etc issues. That being said, I think we could upload .libs/.dlls as downloads on the GitHub page. The question is whether we should put .libs or .dlls there? Personally, I think .libs are easier to work with when using DMD. Thanks for the input! - Alex Correction: It seems as though that function has disappeared on my Linux system! It has most probably been deprecated entirely, so I have just removed it from libffi-d. - Alex
Re: dmd 2.057 release
Sounds offset-dependent. I bet if you added and removed instructions in the
right place you could reduce it a lot further.
Sent from my iPhone
On Dec 15, 2011, at 3:02 AM, Adrian
wrote:
> Am 14.12.2011 18:57, schrieb Walter Bright:
>> On 12/14/2011 6:59 AM, Adrian wrote:
>>> I have a strange crash of the new dmd 2.057 compiler.
>>
>> I can't do anything without a reproducible test case.
>
> I tried to reduce the problem as much as possible and found out the
> following:
>
> - I have include a bug.bat which shows the commandline I used.
>
> - for the crash to happen the project has to be compiled with the
> switches -noboundscheck and -deps="bug.dep". if you omit one of them
> the crash wont show.
>
> - the module btree.d has to be compiled with the project, even if it is
> not referenced from main.d. if it is not in the command line - no crash
>
> - if you comment out the first writeln("Hello D-World!") in main() - no
> crash
>
> - if you comment out the other two writeln(..) in main() - no crash
>
>
> hope you can reproduce it on another system - it sounds too odd to me
> and if it is not reproducible on another system I feel a bit crazy.
>
> Adrian.
>
Re: dmd 2.057 release
Am 15.12.2011 12:31, schrieb Stephan: > On 15.12.2011 12:02, Adrian wrote: >> - for the crash to happen the project has to be compiled with the >> switches -noboundscheck and -deps="bug.dep". if you omit one of them >> the crash wont show. > > sounds like this one i encountered last release already: > > http://d.puremagic.com/issues/show_bug.cgi?id=6951 yes looks pretty much the same. Its total weired, because it seems to depend on code which is elsewhere.
Re: dmd 2.057 release
On 2011-12-15 08:43, Jonathan M Davis wrote: The names of bug reports are frequently not particularly informative, and even if they are, they frequently don't contain the necessary information to understand the effects of fixing the bug. If you want to actually know what's really being fixed, you frequently have to actually read all of the bug reports rather than looking at their titles. - Jonathan M Davis I wonder if we can list breaking changes in a separate sections in the changelog. -- /Jacob Carlborg
Re: dmd 2.057 release
On 2011-12-15 08:43, Jonathan M Davis wrote:
On Thursday, December 15, 2011 08:19:39 Jacob Carlborg wrote:
On 2011-12-14 18:00, Jonathan M Davis wrote:
On Wednesday, December 14, 2011 12:11:03 Jacob Carlborg wrote:
On 2011-12-14 11:10, Walter Bright wrote:
On 12/14/2011 1:59 AM, Jacob Carlborg wrote:
What happened to arrays in this release:
void foo (Object[] a) {}
class Foo {}
void main ()
{
Foo[] b;
foo(b);
}
The above code fails with the following message:
main.d(54): Error: function main.foo (Object[] a) is not callable
using argument
types (Foo[])
main.d(54): Error: cannot implicitly convert expression (b) of
type
Foo[] to
Object[]
Have I missed something, I can't find this in the changelog?
I don't remember if there was a bugzilla entry for it, but it's the
object slicing problem. The thing is, main() expects b to be an
array of Foo's. If foo() replaces one of the array elements with an
Object, then b is no longer an array of Foo's, and can crash.
I think it would be good if it's in the changelog, even if there is no
bugzilla entry for it.
It's the first dmd bug on the list:
http://d.puremagic.com/issues/show_bug.cgi?id=2095
- Jonathan M Davis
I see, thanks. I was search for "array" on the changelog page.
The names of bug reports are frequently not particularly informative, and even
if they are, they frequently don't contain the necessary information to
understand the effects of fixing the bug. If you want to actually know what's
really being fixed, you frequently have to actually read all of the bug reports
rather than looking at their titles.
- Jonathan M Davis
Yeah, I guess.
--
/Jacob Carlborg
Re: dmd 2.057 release
On 15.12.2011 12:02, Adrian wrote: - for the crash to happen the project has to be compiled with the switches -noboundscheck and -deps="bug.dep". if you omit one of them the crash wont show. sounds like this one i encountered last release already: http://d.puremagic.com/issues/show_bug.cgi?id=6951
Re: libffi-d: D binding to libffi
Hi Andrej, Sorry for the late response (for some reason, my news reader had marked this thread as read). > There's a few DLL's floating around for libffi, however none of them > seem to have the symbol "ffi_prep_cif_var" which seems to be needed > for variadic functions. > > I can version variadic support out and compile your bindings, the > tests will work fine on win32. > I've also tried compiling libffi on my own but had no success. ffi_prep_cif_var doesn't seem to be available in any Windows builds (Cygwin, MinGW, or otherwise) of libffi for whatever reason. I'll version it out on Windows for now, as you suggested. I haven't managed to get a MinGW build of libffi working so far, but I did manage to get one working under Cygwin. Build libffi like this: $ ./configure --enable-static=yes --enable-shared=no $ make Now you should have i686-pc-cygwin/.libs/libffi.a. You'll also need your Cygwin installation's libgcc.a: $ cd i686-pc-cygwin/.libs $ ar -r libffi.a /lib/gcc/i686-pc-cygwin/4.5.3/libgcc.a Now you need to convert the .a to an OMF .lib. You'll need objconv.zip from this page: http://www.agner.org/optimize/ $ objconv -fomf -nu libffi.a libffi.lib libffi.lib should now be linkable with DMD. (I long for the day DMD doesn't use OMF.) > I can make a pull with the import lib, the DLL (it's only 99KB), and > the versioned out sections, if you'd like that. I prefer keeping the binaries out of Git for various portability, licensing, etc issues. That being said, I think we could upload .libs/.dlls as downloads on the GitHub page. The question is whether we should put .libs or .dlls there? Personally, I think .libs are easier to work with when using DMD. Thanks for the input! - Alex
Re: dmd 2.057 release
Am 15.12.2011 07:50, schrieb Adrian: > Am 14.12.2011 18:57, schrieb Walter Bright: >> On 12/14/2011 6:59 AM, Adrian wrote: >>> I have a strange crash of the new dmd 2.057 compiler. >> >> I can't do anything without a reproducible test case. > > If you want, I can sent you the whole source. Its nothing real > important, because I am playing around with D and porting some code to test. > > Adrian. I am little step forward. It has to do with the option for array bounds checking. When disabled dmd crashes, when enabled not. Therefor the debug version worked and the release not.
