El 26/07/15 a les 15:55, Martin Nowak via Digitalmars-d-announce ha escrit:
> BTW, I'd like to phase out the fat 50-60MB combined zip, and add tar.xz/gz for linux/freebsd/osx.

Is it not better to use 7z format? It has more compression ratios than gz/bz2, and they can be easily handled on Windows.

On Sun, Jul 26, 2015 at 20:13:09 +0200, Jordi Sayol via Digitalmars-d-announce wrote:
> El 26/07/15 a les 15:55, Martin Nowak via Digitalmars-d-announce ha escrit:
> > BTW, I'd like to phase out the fat 50-60MB combined zip, and add tar.xz/gz for linux/freebsd/osx.
> 
> Is it not better to use 7z format? It has more compression ratios than gz/bz2, and they can be easily handled on Windows.

7z and xz are the same compression algorithm (LZMA), but xz works with
tar (it works in streaming mode).

--Ben

On 07/26/2015 08:13 PM, Jordi Sayol via Digitalmars-d-announce wrote:
> Is it not better to use 7z format? It has more compression ratios than gz/bz2, and they can be easily handled on Windows.

xz is 7-zip same entropy encoding.

On 07/26/2015 11:13 PM, anonymous wrote:
> 
> Is std.expermimental.allocator planned for 2.068 ?
> I see it's still not merged and we already almost in August.

We're trying hard here to meet some deadlines, so things are really simple. If something is ready (reviewed, tested, documented, and merged into stable) it'll end up in a release, otherwise it'll end up in the next release (only 2 month later).

We can't postpone indefinitely just b/c every other person is trying to push through their particular interests.

On Monday, 27 July 2015 at 09:04:08 UTC, Martin Nowak wrote:
> On 07/26/2015 11:13 PM, anonymous wrote:
>> 
>> Is std.expermimental.allocator planned for 2.068 ?
>> I see it's still not merged and we already almost in August.
>
> We're trying hard here to meet some deadlines, so things are really simple. If something is ready (reviewed, tested, documented, and merged into stable) it'll end up in a release, otherwise it'll end up in the next release (only 2 month later).
>
> We can't postpone indefinitely just b/c every other person is trying to push through their particular interests.

fair enough. 2.069 release it is then ;)

-- Stephan

On Monday, 27 July 2015 at 11:30:09 UTC, extrawurst wrote:
> On Monday, 27 July 2015 at 09:04:08 UTC, Martin Nowak wrote:
>> On 07/26/2015 11:13 PM, anonymous wrote:
>>> 
>>> Is std.expermimental.allocator planned for 2.068 ?
>>> I see it's still not merged and we already almost in August.
>>
>> We're trying hard here to meet some deadlines, so things are really simple. If something is ready (reviewed, tested, documented, and merged into stable) it'll end up in a release, otherwise it'll end up in the next release (only 2 month later).
>>
>> We can't postpone indefinitely just b/c every other person is trying to push through their particular interests.
>
> fair enough. 2.069 release it is then ;)
>
> -- Stephan

I thought the next release was to switch to ddmd and wasn't supposed to add a bunch of new features?

On Monday, 27 July 2015 at 09:04:08 UTC, Martin Nowak wrote:
> On 07/26/2015 11:13 PM, anonymous wrote:
>> 
>> Is std.expermimental.allocator planned for 2.068 ?
>> I see it's still not merged and we already almost in August.
>
> We're trying hard here to meet some deadlines, so things are really simple. If something is ready (reviewed, tested, documented, and merged into stable) it'll end up in a release, otherwise it'll end up in the next release (only 2 month later).
>
> We can't postpone indefinitely just b/c every other person is trying to push through their particular interests.

I can understand that. But releases tend to be several months away. And not just two. So this is a bit frustrating.

Joseph

On Saturday, 25 July 2015 at 12:21:19 UTC, Martin Nowak wrote:
> Second beta for the 2.068.0 release.
>
> http://downloads.dlang.org/pre-releases/2.x/2.068.0/ http://ftp.digitalmars.com/
>
> Also available on Travis-CI as dmd-2.068.0-b2.
>
> The changelog (http://dlang.org/changelog.html#2.068.0) contains a list
> of all fixed issues that will be included in 2.068.0.
> A description of library and language changes is still upcoming.
>
> This beta comes with 27 dmd, 2 druntime, and 4 phobos fixes.
>
> https://github.com/D-Programming-Language/dmd/compare/v2.068.0-b1...v2.068.0-b2 https://github.com/D-Programming-Language/druntime/compare/v2.068.0-b1...v2.068.0-b2 https://github.com/D-Programming-Language/phobos/compare/v2.068.0-b1...v2.068.0-b2
>
> Please report any bugs at https://issues.dlang.org.
>
> -Martin

Sorry for the following rant but I am frustrated by the poor quality of support for Windows 64 development.

<rant>

Will the change over to DDMD finally make Win64 a fully supported platform? And will I finally be able to build the most recent code snapshot without having to get a Win64 build toolchain setup (Win64 is not really supported for DMD development: [2])?

I just wasted a lot of time again trying to get Win64 set up on a machine I had to wipe. I had it working for 2.067.1 somehow but was never able to duplicate that on other machines I have. The information at [1] is outdated. Neither the Windows 7 nor 8.1 SDK install a linker for me now for some reason. I had to install VS 2015 to get a 64-bit linker. This fixed the linker not found post installation issue. But then I got a LIBCMT.lib not found issue. I copied it and other library files to the D installation lib64 subdirectory (I couldn't figure out what to modify in the sc.ini file; tried various modifications). Now I am getting a cryptic LNK4229 error that makes no sense to me. At this point I quit.

I shouldn't have to modify the sc.ini file at all to get any of this working. This is after using the Windows installer and when I use the -m64 compilation switch.

By way of comparison, I can download other languages and run their installer. After that everything just works: linker included. Why do I have to install a MS toolchain just to get 64-bit linking for DMD?

I like D a lot. I have been using it for a while. But I have always had trouble with Win64 development. I need that platform for my work. But I will have to dev on Linux again just for 64-bit support. And hope that this can finally get fixed. Although I am real close to just walking away on this one.

</rant>

Hope this can be fixed.

Thanks

Joseph

[1] http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_(COFF-compatible)
[2] http://wiki.dlang.org/Building_DMD -- Windows - step by step

On Monday, 27 July 2015 at 18:58:33 UTC, Joseph Cassman wrote:
>
> Sorry for the following rant but I am frustrated by the poor quality of support for Windows 64 development.
>
> <rant>
>

I understand that frustration. I had some modest problems getting it to work with -m64 on my home computer. However, I had bigger problems getting Visual D to work. Eclipse wouldn't work with the Java installed on my work computer. Coedit wouldn't install on my work computer either (I'm not sure how much this is Coedit's fault though, works fine at home). I think at home I'm just going to virtualize a Linux session. I can dual-boot the machine, but I always find it a hassle if I'm in the middle of doing something in Windows and want to play around with D.

On Monday, 27 July 2015 at 20:43:38 UTC, jmh530 wrote:
> On Monday, 27 July 2015 at 18:58:33 UTC, Joseph Cassman wrote:
>>
>> Sorry for the following rant but I am frustrated by the poor quality of support for Windows 64 development.
>>
>> <rant>
>>
>
> I understand that frustration. I had some modest problems getting it to work with -m64 on my home computer. However, I had bigger problems getting Visual D to work. Eclipse wouldn't work with the Java installed on my work computer. Coedit wouldn't install on my work computer either (I'm not sure how much this is Coedit's fault though, works fine at home). I think at home I'm just going to virtualize a Linux session. I can dual-boot the machine, but I always find it a hassle if I'm in the middle of doing something in Windows and want to play around with D.

Yeah, pretty much the unfortunate conclusion I came to as well.

Joseph