D users will be interested in the updated import libraries and uuid.lib.

http://www.digitalmars.com/changelog.html

Walter Bright wrote:
> D users will be interested in the updated import libraries and uuid.lib.
> 
> http://www.digitalmars.com/changelog.html
> 

The link for the CD upgrade is missing:
http://www.digitalmars.com/download/freecompiler.html

-DavidM

In article <dqdi4s$n10$1@digitaldaemon.com>, David Medlock says...
>
>Walter Bright wrote:
>> D users will be interested in the updated import libraries and uuid.lib.
>> 
>> http://www.digitalmars.com/changelog.html
>> 
>
>The link for the CD upgrade is missing: http://www.digitalmars.com/download/freecompiler.html
>
>-DavidM

This version of the. compiler is missing from the ftp site. Lastest version available is still 8.45.

Fixed.

> Fixed.

Actually, the CD update (cd846.zip) is still missing.

-- 
--  Jerry van Dijk
--  Leiden, Holland
--
--  In case of headache, follow the instructions on the aspirin bottle: --  "Take two tablets" and "Keep away from children".

Walter Bright wrote:
> D users will be interested in the updated import libraries and uuid.lib.
> 
> http://www.digitalmars.com/changelog.html

Thanks, Walter.

Unfortunately, the tgamma() function is still not completely right, in both DMC and DMD. It's only really accurate to double precision. Interestingly, lgamma() is correct.

With the  version of tgamma I've included in dsource.org in mathextra/etcgamma, the following test passes:

  const real SQRT_PI = 1.77245385090551602729816748334114518279754945612238L;
  assert(feqrel(etcgamma.tgamma(0.5L), SQRT_PI) == real.mant_dig);

(ie, it is corect to the full 64 bits at this point!) but

 assert(feqrel(std.math.tgamma(0.5L), SQRT_PI) == real.mant_dig);

fails -- it is correct to "only" 56 bits. I wonder if there's an inadvertant conversion to 'double' in there somewhere?

There's a certain amount of black humour in this -- it is *much* easier to get this stuff right in D, than in C. I think you should consider implementing the C library in D, rather than vice-versa <g>.

Seriously, with the known problems with NaNs in most C++ compilers, and the lack of accuracy guarantees in the C math functions, in the longer term, D is likely to better off minimising its dependence on C.
If pow() is often implemented incorrectly, there's no chance with anything more complicated.

Hi,

Walter Bright wrote:

> D users will be interested in the updated import libraries and uuid.lib.
> 
> http://www.digitalmars.com/changelog.html
> 
> 
> 
> 


Using cd847.

I'm getting "Internal error: cod2 4221".


- this specific file was compiling with cd845
  (although was taking too much time to compile)

- debug compiling is ok


Any hints?

--
Regards,
Hakki Dogusan

"Hakki Dogusan" <dogusanh@tr.net> wrote in message news:dr2e3i$20iu$1@digitaldaemon.com...
> Using cd847.
>
> I'm getting "Internal error: cod2 4221".
>
>
> - this specific file was compiling with cd845
>   (although was taking too much time to compile)
>
> - debug compiling is ok
>
>
> Any hints?

Just the usual <g>:

http://www.digitalmars.com/bugs.html

Hi,

Walter Bright wrote:
> "Hakki Dogusan" <dogusanh@tr.net> wrote in message news:dr2e3i$20iu$1@digitaldaemon.com...
> 
>>Using cd847.
>>
>>I'm getting "Internal error: cod2 4221".
>>
>>
>>- this specific file was compiling with cd845
>>  (although was taking too much time to compile)
>>
>>- debug compiling is ok
>>
>>
>>Any hints?
> 
> 
> Just the usual <g>:
> 
> http://www.digitalmars.com/bugs.html
> 
> 
> 

I tried a little "the usual way", not succedeed.

Then changed compile switch from "-o+space" to "-o" and
problem is solved!

--
Regards,
Hakki Dogusan