Re: float equality

[Walter Bright]

Jonathan M Davis wrote:

Regardless, I'm glad that I don't generally have to do much in the way of math-
centric programming.


Why not? I enjoyed it.

Re: 64bit phobos on Windows?

[Johannes Pfau]

Andrej Mitrovic wrote:
>On 2/20/11, Trass3r  wrote:
>>> I'm very interested in trying out GDC with D2 on Win32. I fear
>>> compiling GDC is gonna be tricky though. Has anyone had success with
>>> it? Hand me a few tips before I venture into the unknown, please!
>>> (and if I'm successful I'll upload the binaries somewhere, maybe on
>>> sourceforge).
>>
>> You need msys and MinGW.
>> https://bitbucket.org/goshawk/gdc/wiki/MinGWCompile
>>
>
>Got that, and I was just reading that page.
>But I'm confused about several things.
>
>The guide mentions the latest working version:
>D2.020 r167:6f2adfcabae6 GCC 4.3.5
>
>Then it mentions we need a newer version of TDM-GCC:
>TDM GCC 4.5.0
>I'm guessing this one will just be used to compile GCC+GDC. Got that
>installed.
>
>It mentions patch files:
>"For GCC 4.3.X, fixes out of memory bug."
>And has a link to this:
>"gcc-4.4.0-20080731-pex-win32.patch"
>
>Is that patch file for the 3.x series, for the memory bug? And which
>GCC sources, the one from TDM-GCC, 4.3.x series or not?
I guess it should apply to the TDM sources and the GCC sources. The
bugzilla entry says that problem has been fixed in 2008. So if you use
gcc 4.5.x sources you shouldn't need that patch anymore.
>Then it references TDM patches, but they're not links to patch files
>they're just plain text:
>"TDM-GCC patches."
>* [buildsys.patch] Minor build system hacks for Cygwin and mSYS
>* [ehstatic.patch] Allow exceptions from DLLs without shared GCC
> libraries
>* [headerpath.patch] Correctly detect backslashes as path
>separators in include paths
>* [make-rel-pref.patch] A patch to fix make_relative_prefix()
>semantics and a little-encountered relocation bug
>* [make-temp-file.patch] A patch to fix make_temp_file() semantics
>and a little-encountered environment bug
>
>So what's up with those?
Those are in the TDM-GCC sources
http://sourceforge.net/projects/tdm-gcc/files/Sources/TDM%20Sources/gcc-4.5.1-tdmsrc-1.zip/download
(In fact the tdm sources consist of only these patches and
buildscripts). Maybe it would even make sense to apply all patches from
tdm, I'm not sure if it could cause any problems.
>I can't find the TDM-GCC 4.3.5 sources on the TDM website, the latest
>in the 4.3.x series I could find is 4.3.3-tdm-1:
>http://sourceforge.net/projects/tdm-gcc/files/Sources/TDM%20Sources/Previous/
>
>Then later in the guide it links to a completely different website
>with GCC sources:
>http://gcc.cybermirror.org/releases/
As the TDM sources are only patches you also need the upstream gcc
sources located there. You then have to patch these sources with the
tdm patches.
>
>This is quite a mess! :D

I remember I got it working half a year ago, but since then many
things changed and I'm not sure if gdc even compiles on windows
now. I'd try to start with a 32 bit version first, because 64bit mingw
will likely cause even more problems.
-- 
Johannes Pfau


signature.asc
Description: PGP signature

Re: Optional module names export list

[Dmitry Olshansky]

On 20.02.2011 3:48, spir wrote:

On 02/20/2011 12:46 AM, bearophile wrote:
In a Python module if you define a name with a starting underscore, 
that name will be private to that module, and it will not be imported 
if a command "from module_name import *" is used:


class Name1: pass
def name2(): pass
_private_name3 = 3
name4 = 4

In Python there is another optional way to specify the list of names 
imported: if a module (or package __init__.py code) defines a list 
named __all__, it is taken to be the list of module names that should 
be imported when a "from package import *" command is used.


So from this module you will not import name2 and _private_name3:

class Name1: pass
def name2(): pass
_private_name3 = 3
name4 = 4
__all__ = ["Name1", "name4"]


In Haskell there is a similar way to list the names to export from a 
module, this module exports the name1, Name2, name3, ... names only:


module Foo(name1, Name2, name3, ...) where
-- module contents here


Several other languages have a similar feature.

In a D module you add a "private" beside each global name you don't 
want to export from a module. (Maybe you are also allowed to use a 
"private:" at the module top, and then add a "public" to each of the 
names you want to export, but this doesn't look so safe, because you 
may miss a "public:" lost in the middle of the module code).


For a safer management of exported names, in D it may be useful an 
optional way to explicitly list (probably at the top of the module) 
the module names exported. A possible syntax is similar to the 
Haskell one:


module foo(name1, name2, Name3, ...);

Bye,
bearophile


I would love such a feature. In fact, I think
import foo;
should launch
Error: module 'foo' does not define exported symbols.
if, actually, 'foo' does not...



 foo may have module constructors/destructors... Anyway why would it 
export nothing / what's wrong about it?


And by the way we have, in fact,  very reasonable module system + 
protection from function hijacking.
I just can't stand all this talk about *explicitness* where it's *not* 
needed.

Let's retype all of imported symbols, let's retype all of exported symbols.
Then let's retype all of imported symbols we are going to use...
That's all is inferior try at protect from function (symbol) hijacking 
by use of programmer convention.. never worked.

And only for the sake of 'some other language have it', I'm not buying it.

--
Dmitry Olshansky

Re: 64bit phobos on Windows?

[Johannes Pfau]

Andrej Mitrovic wrote:
>On 2/20/11, Trass3r  wrote:
>>> I'm very interested in trying out GDC with D2 on Win32. I fear
>>> compiling GDC is gonna be tricky though. Has anyone had success with
>>> it? Hand me a few tips before I venture into the unknown, please!
>>> (and if I'm successful I'll upload the binaries somewhere, maybe on
>>> sourceforge).
>>
>> You need msys and MinGW.
>> https://bitbucket.org/goshawk/gdc/wiki/MinGWCompile
>>
>
>Got that, and I was just reading that page.
>But I'm confused about several things.
>
>The guide mentions the latest working version:
>D2.020 r167:6f2adfcabae6 GCC 4.3.5
>
>Then it mentions we need a newer version of TDM-GCC:
>TDM GCC 4.5.0
>I'm guessing this one will just be used to compile GCC+GDC. Got that
>installed.
>
>It mentions patch files:
>"For GCC 4.3.X, fixes out of memory bug."
>And has a link to this:
>"gcc-4.4.0-20080731-pex-win32.patch"
>
>Is that patch file for the 3.x series, for the memory bug? And which
>GCC sources, the one from TDM-GCC, 4.3.x series or not?
>
>Then it references TDM patches, but they're not links to patch files
>they're just plain text:
>"TDM-GCC patches."
>* [buildsys.patch] Minor build system hacks for Cygwin and mSYS
>* [ehstatic.patch] Allow exceptions from DLLs without shared GCC
> libraries
>* [headerpath.patch] Correctly detect backslashes as path
>separators in include paths
>* [make-rel-pref.patch] A patch to fix make_relative_prefix()
>semantics and a little-encountered relocation bug
>* [make-temp-file.patch] A patch to fix make_temp_file() semantics
>and a little-encountered environment bug
>
>So what's up with those?
>
>I can't find the TDM-GCC 4.3.5 sources on the TDM website, the latest
>in the 4.3.x series I could find is 4.3.3-tdm-1:
>http://sourceforge.net/projects/tdm-gcc/files/Sources/TDM%20Sources/Previous/
Then the TDM-GCC patches for 4.3.3 also work for the upstream source
version 4.3.5. This is quite common, if patches for older versions work
fine with new upstream releases, there are often no new patches
released.
>
>Then later in the guide it links to a completely different website
>with GCC sources:
>http://gcc.cybermirror.org/releases/
>
>This is quite a mess! :D


-- 
Johannes Pfau


signature.asc
Description: PGP signature

Re: O(N) Garbage collection?

[Simen kjaeraas]

Nick Sabalausky  wrote:


Ahh, I was confusing "gene" with "chromosome" (and probably still got the
exact number wrong ;) ).


That you did. Humans have 23 chromosome pairs. But now you know!


--
Simen

Re: 64bit phobos on Windows?

[Anders F Björklund]

Iain Buclaw wrote:

I wish someone released prebuilt versions.

Compiling GCC on Windows is a PITA.


Windows is a PITA, period.

I tried using it as an everyday OS the other week. Something that I will never 
try
again any time soon...


Fortunately one can run MinGW on other platforms, even if compiling for
Windows. By using Wine, one doesn't even have to run it on Windows...

# on Mac OS X:
$ x86_64-w64-mingw32-gdmd -m32 hello.d
$ wine hello.exe
Hello, World!

However, the 64-bit version of Wine doesn't work everywhere just yet
and the 64-version of Phobos for Windows had lots of issues as well.


So I didn't make a new prebuilt version for MinGW GCC 4.5.0 just yet...
(which is identical to FSF GCC 4.5.0 afaik, no MinGW patches necessary)

But the GCC 3.4.5* version is still on http://gdcwin.sourceforge.net/
Nobody volunteered to make a D2 version, and there's no GDC release yet.

* 
http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/GCC/Version3/Current%20Release_%20gcc-3.4.5-20060117-3/




Someone mentioned GDC on Win64. Someone has done it for D1, but I didn't bother
merging half of the patches I was given. Mostly because they were too
invasive/half complete. But that it can be done (minimally) is reassuring.


I made a GDC for Win64 MinGW during holidays, since I didn't want to
start the new year with the same old 32-bit compilers as in 2007...

http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=125675

It was able to run Hello World (Phobos), and Hello World (wxWidgets*)
but I didn't bother patching it more than that. And lucky I didn't!

* http://wxd.sourceforge.net/Hello.html


Once those two were running 64-bit on all three platforms, I stopped.

But I _could_ make a Win32 version of MinGW GCC 4.5.0* and DMD 1.064 ?

* 
http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/GCC/Version4/gcc-4.5.0-1/


64-bit versions for Mac OS X 10.6 and Fedora 14 are already available.


To make a Win64 version, one need to change compiler from MinGW.org
to http://mingw-w64.sourceforge.net/ but otherwise straight-forward:

http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler
http://sourceforge.net/apps/trac/mingw-w64/wiki/Native%20Win64%20compiler

--anders

Re: float equality

[Jonathan M Davis]

On Sunday 20 February 2011 01:20:34 Walter Bright wrote:
> Jonathan M Davis wrote:
> > Regardless, I'm glad that I don't generally have to do much in the way of
> > math- centric programming.
> 
> Why not? I enjoyed it.

There's way too much to worry about. I don't _want_ to have to be worrying 
about 
rounding error and that sort of thing. I generally want to do whatever 
calculations I need to do for a particular task and be done with it. Math 
doesn't interest me enough for me to want to deal with it more than I have to 
to 
solve a particular problem. I find the fact that you have to worry about losing 
precision with floating point values and that they can't even represent all of 
the values in their range horrific. It's a fact of life, and you have to deal 
with it, but it sure isn't pretty.

- Jonathan M Davis

Re: Stupid little iota of an idea

[Nick Sabalausky]

"Don"  wrote in message 
news:ijmndc$3e5$1...@digitalmars.com...
> Nick Sabalausky wrote:
>>
>> I like "interval", too.
>>
>> I do think the name "iota" is a nice extra reason to just use a..b or 
>> a..b:c like you say. It also makes it clear that it's a series of 
>> discrete values rather than a true mathematical range, since that's 
>> exactly how foreach already uses a..b: as a series of discrete values.
>
> I don't like interval at all, because I don't think it includes the notion 
> of 'stepping'. An interval is just, everything from A to B, without 
> necessarily specifying how you reach everything in that interval. Whereas 
> iota includes the stepping.
> (I would like to see intervals in the language, but just as an [a,b] 
> pair).
>
> OTOH iota() is unintuitive to me, and I do keep reading it as itoa().
> Sadly I don't have any better suggestions.

I do agree that 'interval' is inaccurate because it doesn't imply stepping, 
but I still find 'iota' to be more inaccurate, it just means "a small 
amount", it carries no notion of range or endpoints or anything like that.

Re: Do findSplit, findSplitBefore, and findSplitAfter make until unnecessary?

[Tomek Sowiński]

Jonathan M Davis napisał:

> Does anyone have a good reason why the findSplit* functions don't make until 
> obsolete and unnecessary?

Until is lazy, findSplit* are not.

-- 
Tomek

Re: [OT] Webpage design and "Name That Color!"

[spir]

On 02/20/2011 03:53 AM, Nick Sabalausky wrote:

I've been updating the docs for my Goldie project in preparation of a new
release, and figured the they looked a bit...sterile, so I've tweaked the
CSS a bit. And, well, I think I've stumbled upon a heisencolor...(or a
heisenhue, rather)

Without reading any replies or "cheating" by inspecting the pixels in a
paint program, take a look at this screenshot:

http://www.semitwist.com/download/goldie0.4docBeta.png

...and reply with what color you think the background looks like (the main
background, not the
sidebar). And whether or not you like it would be helpful, too, of course.
And, strange as this may sound, reply again if you end up changing your mind
on what color it looks like.

I don't think the weirdness is from my CRT monitor (yea, yea, it's a CRT,
"join the 21st century" etc...), because I've checked on someone's LCD and
noticed the same effect.

Secondarily, any other comments on the page would be appreciated, too. I'm
not much of an artist or graphic designer. This NG does seem to be a good
place to get many different opinions on a webpage's design. FWIW, I think I
may increase the font size slightly and darken the BG colors a tad.


I see it as a very light cold color (blue-green). But this may be due to my own 
bg color (surrounding your pic) which is a very dark brown (thus, rather warm).
And yes, darkening it (more than a bit) would probably be a good idea (as said 
by Jonathan, looks dirty). You can also give a hue to the fg colors; using the 
same one as for the bg always fits; then, you can use a distinct (possibly 
opposite) hue to set an alternate fg color, such as for frames, titles, whatever.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: DMD and 64-bit

[Russel Winder]

On Sat, 2011-02-19 at 15:28 -0800, Walter Bright wrote:
> Russel Winder wrote:
> > Am I correct in assuming that DMD generates 32-bit by default and that
> > for 64-bit you have to give the -m64 option?
> > 
> > Is the eventual plan to use the natural word length of the platform as
> > the default, i.e. 32-bit on 32-bit and 64-bit on 64-bit, with the option
> > to force something different using the -m option à la GCC?
> 
> Yes, but not yet.

Cool, and understandable.  64-bit support needs to be shaken down more
and available on Windows as well as Linux, before any thought of having
a policy of generating for the platform.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: [OT] Webpage design and "Name That Color!"

[Simen kjaeraas]

Nick Sabalausky  wrote:

...and reply with what color you think the background looks like (the  
main background, not the sidebar). And whether or not you like it

would be helpful, too, of course.


Dirty light gray. It's easy on the eyes, and provides good contrast. I
like it.


--
Simen

compile dmd 2.052 under Windows XP (32bit) -- error !

[David Wang]

Sorry, I think I should post my question here except "digitalmars.D.bugs".

I've installed dmc and dmd2 by the "dinstaller.exe" from
http://ftp.digitalmars.com/dinstaller.exe

After finished, I downloaded the latest dmd, druntime and phobos from github.com

When I try to compile the dmd source through the command:
"make -f win32.mak release", I got many errors, please view as follows:
--
.

freebsd.mak:532: warning: ignoring old commands for target `gcov'
solaris.mak:602: warning: overriding commands for target `zip'
freebsd.mak:602: warning: ignoring old commands for target `zip'
win32.mak:40: warning: overriding commands for target `.c.obj'
win32.mak:40: warning: ignoring old commands for target `.c.obj'
win32.mak:43: warning: overriding commands for target `.asm.obj'
win32.mak:43: warning: ignoring old commands for target `.asm.obj'
win32.mak:50: warning: overriding commands for target `release'
win32.mak:50: warning: ignoring old commands for target `release'
win32.mak:57: warning: overriding commands for target `trace'
win32.mak:57: warning: ignoring old commands for target `trace'
win32.mak:60: warning: overriding commands for target `dmd'
solaris.mak:97: warning: ignoring old commands for target `dmd'
win32.mak:66: warning: overriding commands for target `debdmd'
win32.mak:66: warning: ignoring old commands for target `debdmd'
win32.mak:162: warning: overriding commands for target `dmd.exe'
win32.mak:162: warning: ignoring old commands for target `dmd.exe'
win32.mak:175: warning: overriding commands for target `msgs.h'
win32.mak:175: warning: ignoring old commands for target `msgs.h'
win32.mak:175: warning: overriding commands for target `msgs.c'
win32.mak:175: warning: ignoring old commands for target `msgs.c'
win32.mak:175: warning: overriding commands for target `sj1041.msg'
win32.mak:175: warning: ignoring old commands for target `sj1041.msg'
win32.mak:175: warning: overriding commands for target `sj1036.msg'
win32.mak:175: warning: ignoring old commands for target `sj1036.msg'
win32.mak:175: warning: overriding commands for target `sj1031.msg'
win32.mak:175: warning: ignoring old commands for target `sj1031.msg'
win32.mak:178: warning: overriding commands for target `msgsx.exe'
win32.mak:178: warning: ignoring old commands for target `msgsx.exe'
win32.mak:182: warning: overriding commands for target `elxxx.c'
win32.mak:182: warning: ignoring old commands for target `elxxx.c'
win32.mak:182: warning: overriding commands for target `cdxxx.c'
win32.mak:182: warning: ignoring old commands for target `cdxxx.c'
win32.mak:182: warning: overriding commands for target `optab.c'
win32.mak:182: warning: ignoring old commands for target `optab.c'
win32.mak:182: warning: overriding commands for target `debtab.c'
win32.mak:182: warning: ignoring old commands for target `debtab.c'
win32.mak:182: warning: overriding commands for target `fltables.c'
win32.mak:182: warning: ignoring old commands for target `fltables.c'
win32.mak:182: warning: overriding commands for target `tytab.c'
win32.mak:182: warning: ignoring old commands for target `tytab.c'
win32.mak:186: warning: overriding commands for target `impcnvtab.c'
win32.mak:186: warning: ignoring old commands for target `impcnvtab.c'
win32.mak:190: warning: overriding commands for target `id.h'
win32.mak:190: warning: ignoring old commands for target `id.h'
win32.mak:190: warning: overriding commands for target `id.c'
win32.mak:190: warning: ignoring old commands for target `id.c'
win32.mak:199: warning: overriding commands for target `total.sym'
win32.mak:199: warning: ignoring old commands for target `total.sym'
win32.mak:202: warning: overriding commands for target `impcnvtab.obj'
win32.mak:202: warning: ignoring old commands for target `impcnvtab.obj'
win32.mak:205: warning: overriding commands for target `iasm.obj'
win32.mak:205: warning: ignoring old commands for target `iasm.obj'
win32.mak:208: warning: overriding commands for target `bcomplex.obj'
win32.mak:208: warning: ignoring old commands for target `bcomplex.obj'
win32.mak:211: warning: overriding commands for target `aa.obj'
win32.mak:211: warning: ignoring old commands for target `aa.obj'
win32.mak:214: warning: overriding commands for target `bit.obj'
win32.mak:214: warning: ignoring old commands for target `bit.obj'
win32.mak:217: warning: overriding commands for target `blockopt.obj'
win32.mak:217: warning: ignoring old commands for target `blockopt.obj'
win32.mak:220: warning: overriding commands for target `cg.obj'
win32.mak:220: warning: ignoring old commands for target `cg.obj'
win32.mak:223: warning: overriding commands for target `cg87.obj'
win32.mak:223: warning: ignoring old commands for target `cg87.obj'
win32.mak:226: warning: overriding commands for target `cgcod.obj'
win32.mak:226: warning: ignoring old commands for target `cgcod.obj'
win32.mak:229: warning: overriding commands for target `cgcs.obj'
win32.mak:229: warning: ignoring old commands for targe

Re: compile dmd 2.052 under Windows XP (32bit) -- error !

[Brad Roberts]

win32.mak is only intended for use with the digitalmars version of make, not 
gnu make.  It's shipped with both dmd and dmc.

On 2/20/2011 4:29 AM, David Wang wrote:
> Sorry, I think I should post my question here except "digitalmars.D.bugs".
> 
> I've installed dmc and dmd2 by the "dinstaller.exe" from
> http://ftp.digitalmars.com/dinstaller.exe
> 
> After finished, I downloaded the latest dmd, druntime and phobos from 
> github.com
> 
> When I try to compile the dmd source through the command:
> "make -f win32.mak release", I got many errors, please view as follows:
> --
> .
> 
> freebsd.mak:532: warning: ignoring old commands for target `gcov'
> solaris.mak:602: warning: overriding commands for target `zip'
> freebsd.mak:602: warning: ignoring old commands for target `zip'
> win32.mak:40: warning: overriding commands for target `.c.obj'
> win32.mak:40: warning: ignoring old commands for target `.c.obj'
> win32.mak:43: warning: overriding commands for target `.asm.obj'
> win32.mak:43: warning: ignoring old commands for target `.asm.obj'
> win32.mak:50: warning: overriding commands for target `release'
> win32.mak:50: warning: ignoring old commands for target `release'
> win32.mak:57: warning: overriding commands for target `trace'
> win32.mak:57: warning: ignoring old commands for target `trace'
> win32.mak:60: warning: overriding commands for target `dmd'
> solaris.mak:97: warning: ignoring old commands for target `dmd'
> win32.mak:66: warning: overriding commands for target `debdmd'
> win32.mak:66: warning: ignoring old commands for target `debdmd'
> win32.mak:162: warning: overriding commands for target `dmd.exe'
> win32.mak:162: warning: ignoring old commands for target `dmd.exe'
> win32.mak:175: warning: overriding commands for target `msgs.h'
> win32.mak:175: warning: ignoring old commands for target `msgs.h'
> win32.mak:175: warning: overriding commands for target `msgs.c'
> win32.mak:175: warning: ignoring old commands for target `msgs.c'
> win32.mak:175: warning: overriding commands for target `sj1041.msg'
> win32.mak:175: warning: ignoring old commands for target `sj1041.msg'
> win32.mak:175: warning: overriding commands for target `sj1036.msg'
> win32.mak:175: warning: ignoring old commands for target `sj1036.msg'
> win32.mak:175: warning: overriding commands for target `sj1031.msg'
> win32.mak:175: warning: ignoring old commands for target `sj1031.msg'
> win32.mak:178: warning: overriding commands for target `msgsx.exe'
> win32.mak:178: warning: ignoring old commands for target `msgsx.exe'
> win32.mak:182: warning: overriding commands for target `elxxx.c'
> win32.mak:182: warning: ignoring old commands for target `elxxx.c'
> win32.mak:182: warning: overriding commands for target `cdxxx.c'
> win32.mak:182: warning: ignoring old commands for target `cdxxx.c'
> win32.mak:182: warning: overriding commands for target `optab.c'
> win32.mak:182: warning: ignoring old commands for target `optab.c'
> win32.mak:182: warning: overriding commands for target `debtab.c'
> win32.mak:182: warning: ignoring old commands for target `debtab.c'
> win32.mak:182: warning: overriding commands for target `fltables.c'
> win32.mak:182: warning: ignoring old commands for target `fltables.c'
> win32.mak:182: warning: overriding commands for target `tytab.c'
> win32.mak:182: warning: ignoring old commands for target `tytab.c'
> win32.mak:186: warning: overriding commands for target `impcnvtab.c'
> win32.mak:186: warning: ignoring old commands for target `impcnvtab.c'
> win32.mak:190: warning: overriding commands for target `id.h'
> win32.mak:190: warning: ignoring old commands for target `id.h'
> win32.mak:190: warning: overriding commands for target `id.c'
> win32.mak:190: warning: ignoring old commands for target `id.c'
> win32.mak:199: warning: overriding commands for target `total.sym'
> win32.mak:199: warning: ignoring old commands for target `total.sym'
> win32.mak:202: warning: overriding commands for target `impcnvtab.obj'
> win32.mak:202: warning: ignoring old commands for target `impcnvtab.obj'
> win32.mak:205: warning: overriding commands for target `iasm.obj'
> win32.mak:205: warning: ignoring old commands for target `iasm.obj'
> win32.mak:208: warning: overriding commands for target `bcomplex.obj'
> win32.mak:208: warning: ignoring old commands for target `bcomplex.obj'
> win32.mak:211: warning: overriding commands for target `aa.obj'
> win32.mak:211: warning: ignoring old commands for target `aa.obj'
> win32.mak:214: warning: overriding commands for target `bit.obj'
> win32.mak:214: warning: ignoring old commands for target `bit.obj'
> win32.mak:217: warning: overriding commands for target `blockopt.obj'
> win32.mak:217: warning: ignoring old commands for target `blockopt.obj'
> win32.mak:220: warning: overriding commands for target `cg.obj'
> win32.mak:220: warning: ignoring old commands for target `cg.obj'
> win32.mak:223: warning: overriding commands for target `cg87.obj'
> wi

Re: float equality

[bearophile]

Walter:

> There's a total lack of evidence for that.

MISRA-C standard disallows the equality among FP values. I presume they have 
some serious evidence for their choices, but I don't know such evidence. Today 
MISRA-C is one of the most serious attempts at fixing the holes in C language 
to write more reliable code for the industry. MISRA-C standard is sometimes 
extreme and I don't suggest to follow everything they say, but I suggest to not 
totally ignore what it says about many C features.


> 1. Roundoff error is not of a fixed magnitude.

I meant to replace the nude FP equality with a function that has the shared 
number of mantissa bits as third required argument. And then perform the normal 
FP equality using the "is" operator.

Regarding FP rounding errors, eventually it will be good to add to Phobos2 a 
library for Interval FP arithmetic, with trigonometric functions too, etc:
http://en.wikipedia.org/wiki/Interval_arithmetic

Bye,
bearophile

Re: Mac OSX std.datetime / Posix daylight variable

[Michel Fortin]

On 2011-02-20 00:11:11 -0500, Jonathan M Davis  said:


Posix defines the tzset function along with a few helper items. From the Linux
man page:

extern int daylight;
extern long timezone;
extern char *tzname[2];
void tzset(void);

It seems that while these _are_ Posix, not all Posix systems declare 
all of them

(which baffles me, but that's the way it goes it seems). tzset seem pretty
universal, and I believe that tzname is essentially universal, but I'm not so
sure about the others.

Currently, std.datetime uses tzset, tzname, and daylight on all Posix systems.
It appears that for some reason, daylight is not declared on FreeBSD (
http://d.puremagic.com/issues/show_bug.cgi?id=5616 ). What I want to confirm is
that this is _not_ a problem on Mac OS X.

As I understand it, std.datetime has been working just fine on Mac OS X, which
would indicate that daylight _is_ declared on Mac OS X. Can anyone 
confirm this?

If it is indeed the case, I'd like to have daylight added to druntime (where it
belongs) for OSX. But if it's not actually on OSX, then we definitely 
don't want

to declare it there.


time.h has daylight in the Mac OS X 10.6 SDK:

extern int daylight;

--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: DMD versions

[Jérôme M. Berger]

Russel Winder wrote:
> On Fri, 2011-02-18 at 13:20 +, Lars T. Kyllingstad wrote:
>> On Fri, 18 Feb 2011 08:08:46 -0500, Steven Schveighoffer wrote:
>>
>>> On Fri, 18 Feb 2011 07:56:46 -0500, Matthias Pleh 
>>> wrote:
>>>
>>>
 There is the special Token __VERSION__ which gives an integer.

 http://www.digitalmars.com/d/2.0/lex.html


>>> That works ;)  I looked on the "conditional compilation" page.
>>>
>>> -Steve
>> Also, there's std.compiler, which "decodes" the information in 
>> __VERSION__.
>>
>> http://www.digitalmars.com/d/2.0/phobos/std_compiler.html
> 
> Sadly (perhaps), when I said programmatically, I actually meant from
> Python.  So gcc has the -v option giving output that can be "parsed" to
> find the version number.  javac has the -version option, as does
> groovyc. OCaml has a -version option.  gdc has a -v option. I could go
> on.  dmd seemingly has no option for delivering a version number.  Which
> is sad.
> 
Note that the “right way” (tm) to get the gcc (or gdc) version is
to use the “-dumpversion” option, whose output contains only the
version.

Jerome
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature

Re: float equality

[spir]

On 02/20/2011 06:17 AM, Jonathan M Davis wrote:

On Saturday 19 February 2011 20:46:50 Walter Bright wrote:

bearophile wrote:

Walter:

That'll just trade one set of problems for another.


But the second set of problems may be smaller :-)


There's a total lack of evidence for that. Furthermore,

1. Roundoff error is not of a fixed magnitude.

2. A user may choose to ignore roundoff errors, but that is not the
prerogative of the language.

3. What is an acceptable amount of roundoff error is not decidable by the
language.

4. At Boeing doing design work, I've seen what happens when engineers
ignore roundoff errors. It ain't pretty. It ain't safe. It ain't correct.


Honestly, the more that I learn about and deal with floating point numbers, the
more I wonder why we don't just use fixed point. Obviously that can be a bit
limiting for the size of the number (on either side of the decimal) -
particularly in 32-bit land - but with 64-bit numbers, it sounds increasingly
reasonable given all of the issues with floating point values. Ideally, I
suppose, you'd have both, but the CPU specifically supports floating point (I
don't know about fixed point), and I don't think that I've ever used a language
which really had fixed point values (unless you count integers as fixed point 
with
no digits to the right of the decimal).


I don't see how fixed point would solve common issues with floats. Would you 
expand a bit on this?


For me, the source of the issue is inaccurate and unintuitive "translations" 
from/to decimal and binary. For instance (using python just for example):



0.1

0.10001

0.7

0.69996

0.3

0.2

To solve this, one may use rationals (representing 0.1 by 1/10) or decimals 
(representing decimal digits, each eg by half a byte). Both are costly, indeed.

I may ignore some other points, solved by fixed point arithmetics.

Denis
--
_
vita es estrany
spir.wikidot.com

Re: Mac OSX std.datetime / Posix daylight variable

[Jonathan M Davis]

On Sunday 20 February 2011 04:53:03 Michel Fortin wrote:
> On 2011-02-20 00:11:11 -0500, Jonathan M Davis  said:
> > Posix defines the tzset function along with a few helper items. From the
> > Linux man page:
> > 
> > extern int daylight;
> > extern long timezone;
> > extern char *tzname[2];
> > void tzset(void);
> > 
> > It seems that while these _are_ Posix, not all Posix systems declare
> > all of them
> > (which baffles me, but that's the way it goes it seems). tzset seem
> > pretty universal, and I believe that tzname is essentially universal,
> > but I'm not so sure about the others.
> > 
> > Currently, std.datetime uses tzset, tzname, and daylight on all Posix
> > systems. It appears that for some reason, daylight is not declared on
> > FreeBSD ( http://d.puremagic.com/issues/show_bug.cgi?id=5616 ). What I
> > want to confirm is that this is _not_ a problem on Mac OS X.
> > 
> > As I understand it, std.datetime has been working just fine on Mac OS X,
> > which would indicate that daylight _is_ declared on Mac OS X. Can anyone
> > confirm this?
> > If it is indeed the case, I'd like to have daylight added to druntime
> > (where it belongs) for OSX. But if it's not actually on OSX, then we
> > definitely don't want
> > to declare it there.
> 
> time.h has daylight in the Mac OS X 10.6 SDK:
> 
> extern int daylight;

Okay. Thanks for the confirmation. I've now added it to druntime for Mac OS X.

- Jonathan M Davis

Re: float equality

[Jonathan M Davis]

On Sunday 20 February 2011 05:21:12 spir wrote:
> On 02/20/2011 06:17 AM, Jonathan M Davis wrote:
> > On Saturday 19 February 2011 20:46:50 Walter Bright wrote:
> >> bearophile wrote:
> >>> Walter:
>  That'll just trade one set of problems for another.
> >>> 
> >>> But the second set of problems may be smaller :-)
> >> 
> >> There's a total lack of evidence for that. Furthermore,
> >> 
> >> 1. Roundoff error is not of a fixed magnitude.
> >> 
> >> 2. A user may choose to ignore roundoff errors, but that is not the
> >> prerogative of the language.
> >> 
> >> 3. What is an acceptable amount of roundoff error is not decidable by
> >> the language.
> >> 
> >> 4. At Boeing doing design work, I've seen what happens when engineers
> >> ignore roundoff errors. It ain't pretty. It ain't safe. It ain't
> >> correct.
> > 
> > Honestly, the more that I learn about and deal with floating point
> > numbers, the more I wonder why we don't just use fixed point. Obviously
> > that can be a bit limiting for the size of the number (on either side of
> > the decimal) - particularly in 32-bit land - but with 64-bit numbers, it
> > sounds increasingly reasonable given all of the issues with floating
> > point values. Ideally, I suppose, you'd have both, but the CPU
> > specifically supports floating point (I don't know about fixed point),
> > and I don't think that I've ever used a language which really had fixed
> > point values (unless you count integers as fixed point with no digits to
> > the right of the decimal).
> 
> I don't see how fixed point would solve common issues with floats. Would
> you expand a bit on this?
> 
> For me, the source of the issue is inaccurate and unintuitive
> "translations"
> 
> from/to decimal and binary. For instance (using python just for example):
> >>> 0.1
> 
> 0.10001
> 
> >>> 0.7
> 
> 0.69996
> 
> >>> 0.3
> 
> 0.2
> 
> To solve this, one may use rationals (representing 0.1 by 1/10) or decimals
> (representing decimal digits, each eg by half a byte). Both are costly,
> indeed. I may ignore some other points, solved by fixed point arithmetics.

It may be that you would still end up with situations where two values that you 
would think would be the same aren't due to rounding error or whatnot. However, 
with a fixed point value, you wouldn't have the problem where a particular 
value 
could not be held in it even if it's within its range of precision. As I 
understand it, there are a number of values which cannot be held in a floating 
point and therefore end up being rounded up or down simply because of how 
floating points work and not because there the precision isn't high enough.

It's definitely true however, that using fractions would be much more accurate 
for a lot of stuff. That wouldn't be particulary efficient though. Still, if 
you're 
doing a lot of math that needs to be accurate, that may be the way to go.

- Jonathan M Davis

Simple .d file passed in -m32 model, but failed in -m64 model. Why?

[David Wang]

Thank you Brad Roberts, at first I remove MinGW's PATHs in my system, and then
I successfully compiled the DMD, then I added back the MinGW's PATHs to the
system.  :-)


But, when I in Linux (Fedora 14 X86_64) system, I compiled a simple d file in
32bit model and 64 bit model I got different results.

Details:
1). test.d source:
=
import std.stdio;



void main()

{

writeln("Under 32bit model & 64bit model: \n");



int[] months = new int[12];

months = [99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99];



writeln("Original months array value: \n", months,
"\n\n=");



writeln("start to bind in turn:");

foreach (i, ref e; months)

{



writeln("index i = ", i, ", \"looked \'in\' array\" value e = ", e);



e = i + 1;



writeln("temp i = ", i, ", temp e = i + 1 = ", e);

writeln("months array: ", months);

writeln("used i = ", i, ", and used e = ", e, "\n");



}



writeln("finished binding...");

writeln("=\n\nFinal months array value: \n", months);




}
=

2). I compile it using the command:
[David@Ocean ~]$ dmd -m32 test.d
And I successfully got the result "test" file.

3). I compile it using the command:
[David@Ocean ~]$ dmd -m64 test.d
And I got the error:
"test.d(18): Error: cannot implicitly convert expression (i + 1LU) of type
ulong to int"

Why the same source file shows different results?
How to fix this problem?

Waiting for kindly help.

Daivd.

Re: Simple .d file passed in -m32 model, but failed in -m64 model. Why?

[David Nadlinger]

On 2/20/11 3:25 PM, David Wang wrote:

Why the same source file shows different results?


Because the array index »i« in your foreach loop is of type size_t, 
which is uint (32 bit wide) on x86_32 and ulong (64 bit wide) on x86_64.


By the way, using D2, a shorter way to initialize the array would just 
be »auto months = array(iota(1,13))«.


David

Re: [OT] Webpage design and "Name That Color!"

[Jacob Carlborg]

On 2011-02-20 03:53, Nick Sabalausky wrote:

I've been updating the docs for my Goldie project in preparation of a new
release, and figured the they looked a bit...sterile, so I've tweaked the
CSS a bit. And, well, I think I've stumbled upon a heisencolor...(or a
heisenhue, rather)

Without reading any replies or "cheating" by inspecting the pixels in a
paint program, take a look at this screenshot:

http://www.semitwist.com/download/goldie0.4docBeta.png

...and reply with what color you think the background looks like (the main
background, not the
sidebar). And whether or not you like it would be helpful, too, of course.
And, strange as this may sound, reply again if you end up changing your mind
on what color it looks like.


On one of my screens it looks like beige and on the other one it looks 
like beige with a hint of read. I don't like it.


--
/Jacob Carlborg

Re: Mac OSX std.datetime / Posix daylight variable

[Jacob Carlborg]

On 2011-02-20 13:53, Michel Fortin wrote:

On 2011-02-20 00:11:11 -0500, Jonathan M Davis  said:


Posix defines the tzset function along with a few helper items. From
the Linux
man page:

extern int daylight;
extern long timezone;
extern char *tzname[2];
void tzset(void);

It seems that while these _are_ Posix, not all Posix systems declare
all of them
(which baffles me, but that's the way it goes it seems). tzset seem
pretty
universal, and I believe that tzname is essentially universal, but I'm
not so
sure about the others.

Currently, std.datetime uses tzset, tzname, and daylight on all Posix
systems.
It appears that for some reason, daylight is not declared on FreeBSD (
http://d.puremagic.com/issues/show_bug.cgi?id=5616 ). What I want to
confirm is
that this is _not_ a problem on Mac OS X.

As I understand it, std.datetime has been working just fine on Mac OS
X, which
would indicate that daylight _is_ declared on Mac OS X. Can anyone
confirm this?
If it is indeed the case, I'd like to have daylight added to druntime
(where it
belongs) for OSX. But if it's not actually on OSX, then we definitely
don't want
to declare it there.


time.h has daylight in the Mac OS X 10.6 SDK:

extern int daylight;


All those four mentioned above is available both on Mac OS X 10.5 and 10.6.

--
/Jacob Carlborg

Re: Feature request: "noexport" keyword

[Steven Schveighoffer]

On Sun, 20 Feb 2011 02:19:39 -0500, Bekenn  wrote:

The "export" keyword is a protection attribute, along with "private",  
"package", "protected", and "public".  This means that it can be used  
with the same syntax as any of those other attributes; for instance, if  
creating a D "header" for an existing Windows DLL file, you might do  
something like this:


export extern (Windows):
void func1();
int func2();
...

This notation is convenient when dealing with a very large existing  
library; it avoids pointless repetition, and there's no need to keep  
track of a closing end brace (as there would be with the scoped version).


The problem here is that there is no way to cancel an export attribute.  
  Whereas the other protection attributes can be overridden either  
locally:


public:
void func1();
package int func2();

...or globally:

public:
void func1();
package:
int func2();

...or with a scoped declaration, there is no way to specify that a given  
symbol should *not* be exported once the "export:" version is used, or  
inside a scoped export section.


A "noexport" keyword would be useful in these situations, if for  
instance you want to add very small convenience functions that are  
intended to be inlined and are not actually exported members of the DLL:


export extern (Windows):
void func1();
int func2();
	const(char)* func3(int arg1, int arg2, const(char)* arg3, float arg4,  
int arg5, void* arg6);
	noexport const(char)* simpleFunc3(arg3, arg5, arg6) { return func3(0,  
0, arg3, 3.14, arg5, arg6);

void func4();
...

Currently, to get the same effect, you have to either declare  
simpleFunc3 above the export: line, use a scoped export block, or put  
simpleFunc3 in an entirely different file.  None of these provide the  
same level of convenience.


What do you guys think?


I think static should override export.  But in any case, attributes are  
universally applicable in multiple ways (including using scope braces).   
This would probably solve your problem:


extern (Windows):
export {
  void func1();
  void func2();
  const(char)* func3(int arg1, int arg2, const(char)* arg3, float arg4,  
int arg5, void* arg6);

  void func4();
  ...
}

const(char)* simpleFunc3(arg3, arg5, arg6) { return func3(0, 0, arg3,  
3.14, arg5, arg6);

Re: GC.forget() (Was: O(N) Garbage collection?)

[Steven Schveighoffer]

On Sat, 19 Feb 2011 22:39:10 -0500, Nick Sabalausky  wrote:


"bearophile"  wrote in message
news:ijpkh8$232r$1...@digitalmars.com...

dsimcha:


Yeh, I rebuilt the same model in my head over the past few hours (like
you, I had a good mental model of the GC at one point but have slowly
forgotten it).


For serious D programmers having such model in the head is so important
that I'd like a short page with such explanations & pseudocode in the D
site :-)



I seem to remember finding out at one point (the hard way) that arrays of
primitives are scanned for pointers unless you explicitly tell the GC  
not to
do so (for each array). A long time ago, this caused me major headaches  
when
I tried to write a batch processing tool for image files. I never  
actually

verified this, but my understanding was that the file and image data
contained false pointers that prevented the data from completed images  
from
being collected. So the program just happily kept munching away at more  
and

more memory (and presumably, more false pointers) with each image until
after only a fairly small number of files it ground to a sputtering halt
under the weight of its own memory footprint.


This is not correct.  Arrays of value-elements (builtins or custom structs  
with no pointers in them, the compiler records this in the TypeInfo) are  
marked NO_SCAN when the array is constructed.


Here are the two problems I know of:

1. You can have a struct with sparse pointers in it, an array of such  
structs would not be marked NO_SCAN.  This means, even the non-pointer  
parts are scanned as pointers.  For example:


struct Bad
{
   void *pointer;
   int[1024] data;
}

the data member is scanned in addition to the pointer member.  This can  
create false hits on the heap, keeping those blocks alive.


IMO, this problem is not very significant -- those types of aggregates are  
uncommon.


2. A large value-element array is kept in memory because of false  
pointers.  There are several types of memory that are *always* considered  
pointers.  This means you always have false pointers laying around, even  
if you never allocate any heap data.  For example, stack data is always  
considered to contain all pointers.  As well as global and TLS data.  I  
think even the proposed "precise" scanning patches for D's GC in bugzilla  
do not address stack or global space.


This is a bigger problem.  If you, for example, allocate a 200MB array, in  
a 4GB address space, that's 1/20th the total address space.  The chances  
that a false pointer somewhere in the stack or TLS or globals "points" at  
that data is 1/20.


If you don't explicitly delete such arrays, and stop pointing at them,  
that memory is now leaked.  If you start allocating more of them, you are  
now even more likely to have false pointers.


This second issue I think is much more likely to happen.  I proposed at  
one point that we should have a library construct that aids in freeing  
such chunks of memory deterministically to try and avoid this problem.  I  
don't think it was well received, but I can't really remember.


-Steve

Re: 64bit phobos on Windows?

[Andrej Mitrovic]

If I get this thing working I'll post binaries and a batch/shell
script that does all the work automatically. I really don't understand
the point of using MSYS and then writing a 2-page guide even though
MSYS has a working shell interpreter. 

Re: Feature request: "noexport" keyword

[Bekenn]

On 2/19/2011 11:30 PM, Nick Sabalausky wrote:

"Bekenn"  wrote in message
news:ijqffm$6lk$1...@digitalmars.com...
I'm not 100% certain, but I think this should already do what you want:

export extern (Windows):
void func1();
int func2();

public:
void func3();
void func4();






Hmm... I think you may be right.  I hadn't considered that, but it makes 
sense.  I was thinking that the "export" attribute was independent of 
the other protection attributes, which would introduce an asymmetry: 
private, package, and public could each be overridden by supplying a 
different protection attribute, but export couldn't be overridden. 
However, thinking about it, a "private export" wouldn't make much sense 
(and "export" is listed as a protection attribute, right along with the 
others), so I guess they must all be mutually exclusive.


I just tested this by trying to compile a module with the following line:

public export void func();

The compiler rejects it with the message "redundant protection 
attribute."  I think that pretty clearly settles this issue.

Re: float equality

[Kevin Bealer]

== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
...
> It may be that you would still end up with situations where two values that 
> you
> would think would be the same aren't due to rounding error or whatnot. 
> However,
> with a fixed point value, you wouldn't have the problem where a particular 
> value
> could not be held in it even if it's within its range of precision. As I
> understand it, there are a number of values which cannot be held in a floating
> point and therefore end up being rounded up or down simply because of how
> floating points work and not because there the precision isn't high enough.
>
> It's definitely true however, that using fractions would be much more accurate
> for a lot of stuff. That wouldn't be particulary efficient though. Still, if 
> you're
> doing a lot of math that needs to be accurate, that may be the way to go.
>
> - Jonathan M Davis

Floating point numbers are a good compromise for a lot of purposes, but yeah 
they
are limited.  Here are some ways to open up the limits a bit...

(First some math for those who haven't gone down this path...)

The reason that fixed point does better than floating is that fixed point 
classes
use base ten and floating point uses base 2.  In base two, all fractions that 
have
a denominator of a power of 2 can be represented (e.g. 3/16) exactly, and all 
others
can't.

Fixed point solves this for numbers like .1 or .0003 because the denominator is 
a
power of ten.  Ten is 5*2 and the way it works is that any denominator that is 
a power
of two times a power of ten can be represented exactly.

So you're good for .01 or .039028 because these are (1/100) and 
(39028/100).  But
neither fixed point nor floating can represent something like 1/3 or 1/11 
exactly.

If you used base 3, then 1/3 would be perfectly representable but 1/2 would not 
be.
I think this is why the ancients used 360 degrees in a circle... you can 
represent
a lot of common fractions as parts of 360, including 1/2, 1/3, 1/4, 1/5, 1/6, 
1/8.
But still not 1/7 or 1/11.

How to solve this problem?

You can define a type like this:

struct Rational {
// represents numerator over denominator
... (various arithmetic methods and operators)...

long numerator;
long denominator;
}

(Lots of people have written classes like this, maybe even for D. ;)

If you've taken high school math and CS 101 you can write the methods here, and 
then
you can represent any fraction.  This is a better way to go for a lot of 
problems if
you need exactness, but its a bit slower.

This isn't perfect though ... if you try to add the numbers 1/2, 1/3 
1/100
you will eventually find the denominator overflows -- you can check for this and
'reduce' the fraction (remove common divisors from top and bottom) periodically,
but eventually you will even get an irreducable fraction and you will need, 
again,
to compromise and give away some precision.  The simplest way to do this 
compromise
is probably to divide the top and bottom number by 2, try to reduce again, and 
then
try the operation again (repeat until the operation doesn't overflow).  (Maybe 
there
is a better way though.)

For some problems the precision loss will never happen -- for example if you are
adding dollars and cents represented as (x/100) then the denominator never needs
to get bigger than 100.  If you need to compute mortgage payments it might get a
little bigger... but I'm not sure if it will ever overflow for this case.

Another source of compromise is when a number is really big or small, for 
example
a number like 2^200 or 1/2^200 can be represented in a 'double' but would 
overflow
a Rational as defined above.

You can delay the compromise a bit by using a struct like this:

struct Rational2 {
// represents the number numerator / (denominator ^ exponent)
// adjust integer types to taste
long numerator;
long denominator;
long exponent;
};

This lets you go much further, and represent truly astonishingly large and small
numbers.  It complicates the math in the arithmetic operators a bit though.
Eventually, even this version will lose precision as the fraction still becomes
irreducable if there are a unique set of prime factors in the denominator.  So
this can represent much larger ranges than double or real, but I think it still
can't represent 1/2*1/3*1/1000_000_000 exactly.

Now... what if you wanted to avoid the compromise completely?

You could switch to this:

struct {
BigInt numerator;
BigInt denominator;
};

Bingo -- no compromise.  Two down sides to this:

1. You trade off memory for accuracy as the BigInts grow over time, assuming
the fraction is irreducable.

2. It's slower -- BigInt objects are essentially byte strings and even things
like addition require a function call and looping.

This is a pretty flexible solution though.  However, numbers like pi and 'e'
can't be represented as a rational number at all, so you are still stuck if
you want to d

Re: 64bit phobos on Windows?

[Andrej Mitrovic]

cc1d.exe crashed after an hour of building.

Right, I'll stop trying now.

Re: DMD and 64-bit

[Don]

Steven Schveighoffer wrote:

On Sat, 19 Feb 2011 19:21:05 -0500, Nick Sabalausky  wrote:


"Jonathan M Davis"  wrote in message
news:mailman.1787.1298108224.4748.digitalmar...@puremagic.com...

On Saturday 19 February 2011 01:12:25 Russel Winder wrote:
> Am I correct in assuming that DMD generates 32-bit by default and that
> for 64-bit you have to give the -m64 option?
>
> Is the eventual plan to use the natural word length of the platform as
> the default, i.e. 32-bit on 32-bit and 64-bit on 64-bit, with the 
option

> to force something different using the -m option à la GCC?

32 bit is the default for now. I don't know what Walter intends to do in
the
long run. If it were like gcc, then the default platform would be the
platform
which the compiler is built for (which is exactly what it's doing right
now),
but as far as I know, Walter has no plans to port dmd to x86_64.

So, for now 32 bit is the default. It may or may not change later to be
the
platform that you're building on. Ideally though, it would be like 
gcc and

we'd
actually get a 64 bit version of dmd at some point.


I don't mean this as "anti-64bit" trolling, just a genuine question, but
what would be the point of a 64-bit build of DMD? (Note: I'm talking 
about

host, not target). Just to compile projects that have (on the order of)
gigabytes of source?


This just sparked a thought of curiosity -- CTFE runs in the compiler, 
and if the compiler is 32-bit, does this mean that 64-bit builds execute 
CTFE functions in 32-bits during compilation?


No. The functions haven't been compiled at that point. CTFE happens in 
the front end, whereas the differences between 64 and 32 bits only 
happens in the back end. CTFE works on the syntax tree level.


 If so, are there any 
reprecussions?  Thinking about it, everything is really dictated by the 
type system (which should be properly 64-bit), and for CTFE, the code 
used to execute isn't important, it's really just the result, right?


Yes, the type system takes care of everything.

Re: 64bit phobos on Windows?

[Iain Buclaw]

== Quote from Andrej Mitrovic (andrej.mitrov...@gmail.com)'s article
> cc1d.exe crashed after an hour of building.
> Right, I'll stop trying now.

Mutters something about needing to compile gmp, mpfr (and probably mpc for 4.5)
before attempting to build gdc on Windows.

Re: 64bit phobos on Windows?

[Andrej Mitrovic]

No I did that. And I've patched GCC 3.4.5.

This step causes the crash at the end: make STAGE1_CFLAGS="-g3 -O0"
2>&1 | tee build.log

Log:
checking If /gdc/dev/build/gcc/./gcc/gdc -B/gdc/dev/build/gcc/./gcc/
-L/gdc/dev/build/gcc/i686-pc-mingw32/winsup/mingw
-L/gdc/dev/build/gcc/i686-pc-mingw32/winsup/w32api/lib -isystem
/gdc/dev/gcc-4.3.5/winsup/mingw/include -isystem
/gdc/dev/gcc-4.3.5/winsup/w32api/include -B/mingw/i686-pc-mingw32/bin/
-B/mingw/i686-pc-mingw32/lib/ -isystem /mingw/i686-pc-mingw32/include
-isystem /mingw/i686-pc-mingw32/sys-include can compile D sources...
no
configure: error: can't compile D sources!
make[1]: *** [configure-target-libphobos] Error 1
make[1]: Leaving directory `/gdc/dev/build/gcc'
make: *** [all] Error 2

Maybe I'm just missing another step.

Do I have to apply the TDM-GCC patches over the GCC source downloaded
from http://gcc.cybermirror.org/releases/ ? The thing is, I can't find
the 3.4.5 release of TDM-GCC, which should have the patches:
http://sourceforge.net/projects/tdm-gcc/files/Sources/TDM%20Sources/Previous/

Re: Do findSplit, findSplitBefore, and findSplitAfter make until unnecessary?

[Andrei Alexandrescu]

On 2/20/11 12:20 AM, Jonathan M Davis wrote:

With the most recent release, we got findSplit, findSplitBefore, and 
findSplitAfter
in std.algorithm, which are all very useful and cool. However, in light of what
they can do, I'm wondering if we really need std.algorithm.until? It seems to me
that the findSplit* functions give you that functionality, and I see no reason 
to
keep until around long term if it's not really giving us something that the
findSplit* functions aren't.

Does anyone have a good reason why the findSplit* functions don't make until
obsolete and unnecessary?

- Jonathan M Davis


until is lazy, findSplit* are eager.

Andrei

O(N) GC: The patch

[dsimcha]

http://d.puremagic.com/issues/show_bug.cgi?id=5623

I've found a way to speed up the GC massively on large heaps without 
excessive ripple effects.  Technically it's still O(N), but with about a 
hundred fold smaller constant in the case of large heaps with most stuff 
not scanned.  Now, I think the O(N) (where N is the total size of the 
heap) term has such a small constant that it's for almost all practcal 
purposes the GC is O(S) (where S is the size of the scanned portion of 
the heap).  It also no longer has any O(N^2) pathological case (which I 
had discovered while reading the code).


So far all unittests for Phobos, dstats and 
std.parallelism/parallelfuture pass with this enabled.  Please test some 
other code so we can wring out the corner cases in time for the next 
release.


Basically all I did was diverge the Pool struct slightly into large and 
small object sub-varieties.  The large object sub-variety is used to 
allocate objects of at least a page.  It only stores gcbits at page-size 
offsets, and tracks the offsets of B_PAGEPLUS bins from the nearest 
B_PAGE bin so that they can be found in O(1).


I also added a field to the Pool struct so that the number of free pages 
in a pool can be tracked in O(1).  This should drastically lessen the 
time it takes to perform large allocations on large heaps.  Right now a 
free memory region is found by a linear search through the pools in the 
case of large allocations.  Unfortunately, I don't see any easy way to 
fix this.  This patch at least allows short circuiting a large number of 
pools, if there isn't enough free space in the whole pool, let alone 
contiguous space.


Here are the benchmarks with this patch enabled.

Collected a 10 megabyte heap in 0 milliseconds.
Collected a 50 megabyte heap in 0 milliseconds.
Collected a 250 megabyte heap in 1 milliseconds.
Collected a 500 megabyte heap in 0 milliseconds.
Collected a 1000 megabyte heap in 1 milliseconds.
Collected a 5000 megabyte heap in 3 milliseconds.
Collected a 1 megabyte heap in 6 milliseconds.
Collected a 3 megabyte heap in 16 milliseconds.
Collected a 5 megabyte heap in 26 milliseconds.

Re: Stupid little iota of an idea

[Justin Bogner]

Don  writes:
> I don't like interval at all, because I don't think it includes the
> notion of 'stepping'. An interval is just, everything from A to B,
> without necessarily specifying how you reach everything in that
> interval. Whereas iota includes the stepping.
> (I would like to see intervals in the language, but just as an [a,b] pair).
>
> OTOH iota() is unintuitive to me, and I do keep reading it as itoa().
> Sadly I don't have any better suggestions.

Woudn't "step" be fairly appropriate? It does generate a step function
after all.

Re: float equality

[Walter Bright]

Jonathan M Davis wrote:
There's way too much to worry about. I don't _want_ to have to be worrying about 
rounding error and that sort of thing. I generally want to do whatever 
calculations I need to do for a particular task and be done with it. Math 
doesn't interest me enough for me to want to deal with it more than I have to to 
solve a particular problem. I find the fact that you have to worry about losing 
precision with floating point values and that they can't even represent all of 
the values in their range horrific. It's a fact of life, and you have to deal 
with it, but it sure isn't pretty.


But that's true of any calculation you do, once you get past symbolic math.

It's like if you're cutting wood and do not take into account the width of the 
saw blade. The parts won't fit together right.


I was once on a hot rod forum where a guy was making a mold in order to cast his 
own intake manifold. I suggested to him that he had to make the mold larger than 
the actual part, in order to account for the shrinkage of hot aluminum down to 
room temperature. I calculated by about 1/2 inch. He thought I was an idiot, and 
ignored me. His manifold came out too small by half an inch.

Re: O(N) GC: The patch

[Steven Schveighoffer]

On Sun, 20 Feb 2011 15:19:24 -0500, dsimcha  wrote:


http://d.puremagic.com/issues/show_bug.cgi?id=5623

I've found a way to speed up the GC massively on large heaps without  
excessive ripple effects.  Technically it's still O(N), but with about a  
hundred fold smaller constant in the case of large heaps with most stuff  
not scanned.  Now, I think the O(N) (where N is the total size of the  
heap) term has such a small constant that it's for almost all practcal  
purposes the GC is O(S) (where S is the size of the scanned portion of  
the heap).  It also no longer has any O(N^2) pathological case (which I  
had discovered while reading the code).


So far all unittests for Phobos, dstats and  
std.parallelism/parallelfuture pass with this enabled.  Please test some  
other code so we can wring out the corner cases in time for the next  
release.


Basically all I did was diverge the Pool struct slightly into large and  
small object sub-varieties.  The large object sub-variety is used to  
allocate objects of at least a page.  It only stores gcbits at page-size  
offsets, and tracks the offsets of B_PAGEPLUS bins from the nearest  
B_PAGE bin so that they can be found in O(1).


I also added a field to the Pool struct so that the number of free pages  
in a pool can be tracked in O(1).  This should drastically lessen the  
time it takes to perform large allocations on large heaps.  Right now a  
free memory region is found by a linear search through the pools in the  
case of large allocations.  Unfortunately, I don't see any easy way to  
fix this.  This patch at least allows short circuiting a large number of  
pools, if there isn't enough free space in the whole pool, let alone  
contiguous space.


Here are the benchmarks with this patch enabled.

Collected a 10 megabyte heap in 0 milliseconds.
Collected a 50 megabyte heap in 0 milliseconds.
Collected a 250 megabyte heap in 1 milliseconds.
Collected a 500 megabyte heap in 0 milliseconds.
Collected a 1000 megabyte heap in 1 milliseconds.
Collected a 5000 megabyte heap in 3 milliseconds.
Collected a 1 megabyte heap in 6 milliseconds.
Collected a 3 megabyte heap in 16 milliseconds.
Collected a 5 megabyte heap in 26 milliseconds.


Those numbers look really promising!  I will examine your patch and see if  
I can think of anything in the array appending that would be affected by  
it.


-Steve

Re: float equality

[Walter Bright]

bearophile wrote:

There's a total lack of evidence for that.


MISRA-C standard disallows the equality among FP values. I presume they have
some serious evidence for their choices, but I don't know such evidence.
Today MISRA-C is one of the most serious attempts at fixing the holes in C
language to write more reliable code for the industry. MISRA-C standard is
sometimes extreme and I don't suggest to follow everything they say, but I
suggest to not totally ignore what it says about many C features.


MISRA is not suggesting having the language silently default to approximate 
equality.

Re: float equality

[Walter Bright]

Jonathan M Davis wrote:
It may be that you would still end up with situations where two values that you 
would think would be the same aren't due to rounding error or whatnot. However, 
with a fixed point value, you wouldn't have the problem where a particular value 
could not be held in it even if it's within its range of precision. As I 
understand it, there are a number of values which cannot be held in a floating 
point and therefore end up being rounded up or down simply because of how 
floating points work and not because there the precision isn't high enough.


That happens with decimal representations, too, just with a different set of 
numbers.


It's definitely true however, that using fractions would be much more accurate 
for a lot of stuff. That wouldn't be particulary efficient though. Still, if you're 
doing a lot of math that needs to be accurate, that may be the way to go.


The set of irrational numbers cannot (by definition) be represented by a ratio.

For example, the square root of 2.

Re: float equality

[Walter Bright]

Kevin Bealer wrote:

You could switch to this:

struct {
BigInt numerator;
BigInt denominator;
};

Bingo -- no compromise.


It cannot represent irrational numbers accurately.

Re: compile dmd 2.052 under Windows XP (32bit) -- error !

[Walter Bright]

David Wang wrote:

Why my doc version is ver 8.42n ?
It should be 8.52c when I download it from
http://ftp.digitalmars.com/Digital_Mars_C++/Patch/dm852c.zip, right ?


http://www.digitalmars.com/faq.html#version

Re: 64bit phobos on Windows?

[Andrej Mitrovic]

Now I've tried GCC v3.4.5, applied gcc-4.4.0-20080731-pex-win32.patch,
applied the TDM GCC 3.4.5 patches, and I get the same thing:

---
cc1d.exe - Application Error
---
The application failed to initialize properly (0xc005). Click on
OK to terminate the application.
---
OK
---

Re: tooling quality and some random rant

[Walter Bright]

nedbrek wrote:

Hope that helps,


Thanks, this is great info!

Re: Feature request: "noexport" keyword

[Nick Sabalausky]

"Bekenn"  wrote in message 
news:ijrjh2$20sv$1...@digitalmars.com...
> On 2/19/2011 11:30 PM, Nick Sabalausky wrote:
>> "Bekenn"  wrote in message
>> news:ijqffm$6lk$1...@digitalmars.com...
>> I'm not 100% certain, but I think this should already do what you want:
>>
>> export extern (Windows):
>> void func1();
>> int func2();
>>
>> public:
>> void func3();
>> void func4();
>>
>>
>>
>
>
> Hmm... I think you may be right.  I hadn't considered that, but it makes 
> sense.  I was thinking that the "export" attribute was independent of the 
> other protection attributes, which would introduce an asymmetry: private, 
> package, and public could each be overridden by supplying a different 
> protection attribute, but export couldn't be overridden. However, thinking 
> about it, a "private export" wouldn't make much sense (and "export" is 
> listed as a protection attribute, right along with the others), so I guess 
> they must all be mutually exclusive.
>
> I just tested this by trying to compile a module with the following line:
>
> public export void func();
>
> The compiler rejects it with the message "redundant protection attribute." 
> I think that pretty clearly settles this issue.

Yea. Actually I just happened to be reading the section about protection 
attributes in Andrei's "The D Programming Language" book just the other day, 
and the way it talked about them indicated they were all mutually-exclusive. 
Were it not for that, I probably would have made the same assumption as you. 
Not sure why, though, because as you say, "private/protected export" doesn't 
seem to make much sence.

Re: Feature request: "noexport" keyword

[Nick Sabalausky]

"Nick Sabalausky"  wrote in message 
news:ijs2f1$5ri$1...@digitalmars.com...
> "Bekenn"  wrote in message 
> news:ijrjh2$20sv$1...@digitalmars.com...
>> On 2/19/2011 11:30 PM, Nick Sabalausky wrote:
>>> "Bekenn"  wrote in message
>>> news:ijqffm$6lk$1...@digitalmars.com...
>>> I'm not 100% certain, but I think this should already do what you want:
>>>
>>> export extern (Windows):
>>> void func1();
>>> int func2();
>>>
>>> public:
>>> void func3();
>>> void func4();
>>>
>>>
>>>
>>
>>
>> Hmm... I think you may be right.  I hadn't considered that, but it makes 
>> sense.  I was thinking that the "export" attribute was independent of the 
>> other protection attributes, which would introduce an asymmetry: private, 
>> package, and public could each be overridden by supplying a different 
>> protection attribute, but export couldn't be overridden. However, 
>> thinking about it, a "private export" wouldn't make much sense (and 
>> "export" is listed as a protection attribute, right along with the 
>> others), so I guess they must all be mutually exclusive.
>>
>> I just tested this by trying to compile a module with the following line:
>>
>> public export void func();
>>
>> The compiler rejects it with the message "redundant protection 
>> attribute." I think that pretty clearly settles this issue.
>
> Yea. Actually I just happened to be reading the section about protection 
> attributes in Andrei's "The D Programming Language" book just the other 
> day, and the way it talked about them indicated they were all 
> mutually-exclusive. Were it not for that, I probably would have made the 
> same assumption as you. Not sure why, though, because as you say, 
> "private/protected export" doesn't seem to make much sence.
>

Keep in mind though, I have *no* idea how "extern(...)" fits in to all of 
this.

Re: float equality

[spir]

On 02/20/2011 09:43 PM, Walter Bright wrote:

Jonathan M Davis wrote:

It may be that you would still end up with situations where two values that
you would think would be the same aren't due to rounding error or whatnot.
However, with a fixed point value, you wouldn't have the problem where a
particular value could not be held in it even if it's within its range of
precision. As I understand it, there are a number of values which cannot be
held in a floating point and therefore end up being rounded up or down simply
because of how floating points work and not because there the precision isn't
high enough.


That happens with decimal representations, too, just with a different set of
numbers.


It's definitely true however, that using fractions would be much more
accurate for a lot of stuff. That wouldn't be particulary efficient though.
Still, if you're doing a lot of math that needs to be accurate, that may be
the way to go.


The set of irrational numbers cannot (by definition) be represented by a ratio.

For example, the square root of 2.


This is true, indeed. The difference with decimals and/or rationals is that the 
set of (exactly) representable numbers is the one of numbers that look like 
'finite' to us, like 0.1 (which cannot be represented using binary floats, 
whatever the size). In addition, rationals allow carrying representations 
across computations without creating unnecessary rounding errors at each step. 
Is there any plan for them in D2 in the future?
The question of irrationals exists, for sure, but it's not a trap since we 
cannot ignore/forget they are not representable. (same for infinite rationals 
like 1/3)


Denis
--
_
vita es estrany
spir.wikidot.com

Linking COFF and OMF

[Dmitry Olshansky]

I just took a stab at linking together different object formats with 
UniLink.
Well, it just works(tm).  So I may suggest to anyone having to link with 
precompiled COFF static libs on windows to try it out.


For starters I just replaced most of my kernel32.lib, shell32.lib etc 
with Microsoft SDK  latest COFF import lib variants and
then built and linked winsamp.d from the DMD examples dir. Of course, 
that broke optlink linkage.
Then I tried it with static libs, so I produced simplistic static lib 
with MinGW gcc:


#include 
int AddInt(int i1, int i2)
{
return i1 + i2;
}
void PrintInt(int a)
{
printf("%d\n",a);
}

and linked with this module:

import std.stdio;
extern(C) int AddInt(int a,int b);
extern(C) int PrintInt(int a);
void main(){
assert(AddInt(3,5) == 8);
PrintInt(42);
writeln("Works?");
}

All passed as expected. (It took renaming lib from *.a to *.lib but 
that's it!)

I guess it linked printf with DMC's printf in snn.lib though,
so there might be some problems with foreign RTLs when one goes too far.


P.S. I know I sound like a freaking promoter ;)

--
Dmitry Olshansky

Re: 64bit phobos on Windows?

[Jérôme M. Berger]

Andrej Mitrovic wrote:
> No I did that. And I've patched GCC 3.4.5.
> 
> This step causes the crash at the end: make STAGE1_CFLAGS="-g3 -O0"
> 2>&1 | tee build.log
> 
> Log:
> checking If /gdc/dev/build/gcc/./gcc/gdc -B/gdc/dev/build/gcc/./gcc/
> -L/gdc/dev/build/gcc/i686-pc-mingw32/winsup/mingw
> -L/gdc/dev/build/gcc/i686-pc-mingw32/winsup/w32api/lib -isystem
> /gdc/dev/gcc-4.3.5/winsup/mingw/include -isystem
> /gdc/dev/gcc-4.3.5/winsup/w32api/include -B/mingw/i686-pc-mingw32/bin/
> -B/mingw/i686-pc-mingw32/lib/ -isystem /mingw/i686-pc-mingw32/include
> -isystem /mingw/i686-pc-mingw32/sys-include can compile D sources...
> no
> configure: error: can't compile D sources!
> make[1]: *** [configure-target-libphobos] Error 1
> make[1]: Leaving directory `/gdc/dev/build/gcc'
> make: *** [all] Error 2
> 
> Maybe I'm just missing another step.
> 
There should be a file named “config.log” in “/gdc/dev/build/gcc”
with more information on the error.

Jerome
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature

Re: float equality

[Jérôme M. Berger]

Kevin Bealer wrote:
> == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
> ...
>> It may be that you would still end up with situations where two values that 
>> you
>> would think would be the same aren't due to rounding error or whatnot. 
>> However,
>> with a fixed point value, you wouldn't have the problem where a particular 
>> value
>> could not be held in it even if it's within its range of precision. As I
>> understand it, there are a number of values which cannot be held in a 
>> floating
>> point and therefore end up being rounded up or down simply because of how
>> floating points work and not because there the precision isn't high enough.
>>
>> It's definitely true however, that using fractions would be much more 
>> accurate
>> for a lot of stuff. That wouldn't be particulary efficient though. Still, if 
>> you're
>> doing a lot of math that needs to be accurate, that may be the way to go.
>>
>> - Jonathan M Davis
> 
> Floating point numbers are a good compromise for a lot of purposes, but yeah 
> they
> are limited.  Here are some ways to open up the limits a bit...
> 
> (First some math for those who haven't gone down this path...)
> 
> The reason that fixed point does better than floating is that fixed point 
> classes
> use base ten and floating point uses base 2.  In base two, all fractions that 
> have
> a denominator of a power of 2 can be represented (e.g. 3/16) exactly, and all 
> others
> can't.
> 
> Fixed point solves this for numbers like .1 or .0003 because the denominator 
> is a
> power of ten.  Ten is 5*2 and the way it works is that any denominator that 
> is a power
> of two times a power of ten can be represented exactly.
> 
Wrong. There is nothing that says fixed-point uses a power of ten.
Actually, I do a lot of work on embedded platforms without a FPU and
with slow integer division (and to a lesser extent multiplication).
Non-integer numbers are represented in fixed point (to work around
the lack of FPU) using base 2 (so that adjustments only require a
bitwise shift). Of course, this means that 0.1 cannot be represented
exactly...

Jerome
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature

Re: float equality

[Walter Bright]

spir wrote:

Is there any plan for them in D2 in the future?


If you want to work on a library module that supports them, please have a go!

Hidden links for Language Reference on d-programming-language.org

[Tyro[a.c.edwards]]

The links for Documentation: Language Reference gets hidden when you 
click on any of the following four items:


o   Lexical
o   Templates
o   Inline Assembler
o   Documentation Comments

- Andrew

Re: 64bit phobos on Windows?

[Iain Buclaw]

== Quote from Andrej Mitrovic (andrej.mitrov...@gmail.com)'s article
> Now I've tried GCC v3.4.5, applied gcc-4.4.0-20080731-pex-win32.patch,
> applied the TDM GCC 3.4.5 patches, and I get the same thing:
> ---
> cc1d.exe - Application Error
> ---
> The application failed to initialize properly (0xc005). Click on
> OK to terminate the application.
> ---
> OK
> ---

I (think) these are the (roughly followed) instructions that got me passed that
very same memory error. https://bitbucket.org/goshawk/gdc/wiki/MinGWCompile

Never managed to build phobos though. Deduced that something was not quite right
with the build environment, but too useless at being a developer on Windows to
figure out just why..

Re: float equality

[bearophile]

Walter:

> MISRA is not suggesting having the language silently default to approximate 
> equality.

Right. But I am not suggesting that, in what I have suggested there is nothing 
silent :-)

Given:
double x, y;

I have suggested in D:
x == y  => syntax error.
x is y   => the same FP equality as today.
some syntax(x, y, how_much_to_approximate) => approximate equality.

Bye,
bearophile

Re: Hidden links for Language Reference on d-programming-language.org

[Tyro[a.c.edwards]]

On 2/21/2011 7:47 AM, Tyro[a.c.edwards] wrote:

The links for Documentation: Language Reference gets hidden when you
click on any of the following four items:

o Lexical
o Templates
o Inline Assembler
o Documentation Comments

- Andrew


By the way you cannot get to the list by clicking on Language Reference 
(http://d-programming-language.org/language-reference.html).

Re: 64bit phobos on Windows?

[Andrej Mitrovic]

I'm sorry for hijacking this topic guys. :p

I am getting somewhere though. GDC changeset 475, using GCC 4.5.0 with
applied TDM-GCC 4.5.0 patches, with built gmp, mpc and mpftr. The
Windows build documentation needs an update (I'll fix it myself given
the chance).

I've gotten build errors after:
make STAGE1_CFLAGS="-g3 -O0" 2>&1 | tee build.log

this time its Phobos:
../../../../gcc-4.5.0/libphobos/rt/fpmath.d
../../../../gcc-4.5.0/libphobos/rt/fpmath.d: In function 'signbit':
../../../../gcc-4.5.0/libphobos/rt/fpmath.d:1:0: internal compiler
error: in build_ref_for_offset_1, at tree-sra.c:1405
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [rt/fpmath.o] Error 1
make[3]: Leaving directory `/gdc/dev/build/gcc/i686-pc-mingw32/libphobos'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/gdc/dev/build/gcc/i686-pc-mingw32/libphobos'
make[1]: *** [all-target-libphobos] Error 2
make[1]: Leaving directory `/gdc/dev/build/gcc'
make: *** [all] Error 2

I guess I should file a bug report with the full log.

Re: 64bit phobos on Windows?

[Andrej Mitrovic]

K, I've reported the bug.

Re: O(N) GC: The patch

[Jason House]

Sounds promising. How does it effect other cases? Some typical GC-heavy 
benchmark? Lots of smaller no scan objects that are just under your 
optimization threshold?

dsimcha Wrote:

> http://d.puremagic.com/issues/show_bug.cgi?id=5623
> 
> I've found a way to speed up the GC massively on large heaps without 
> excessive ripple effects.  Technically it's still O(N), but with about a 
> hundred fold smaller constant in the case of large heaps with most stuff 
> not scanned.  Now, I think the O(N) (where N is the total size of the 
> heap) term has such a small constant that it's for almost all practcal 
> purposes the GC is O(S) (where S is the size of the scanned portion of 
> the heap).  It also no longer has any O(N^2) pathological case (which I 
> had discovered while reading the code).
> 
> So far all unittests for Phobos, dstats and 
> std.parallelism/parallelfuture pass with this enabled.  Please test some 
> other code so we can wring out the corner cases in time for the next 
> release.
> 
> Basically all I did was diverge the Pool struct slightly into large and 
> small object sub-varieties.  The large object sub-variety is used to 
> allocate objects of at least a page.  It only stores gcbits at page-size 
> offsets, and tracks the offsets of B_PAGEPLUS bins from the nearest 
> B_PAGE bin so that they can be found in O(1).
> 
> I also added a field to the Pool struct so that the number of free pages 
> in a pool can be tracked in O(1).  This should drastically lessen the 
> time it takes to perform large allocations on large heaps.  Right now a 
> free memory region is found by a linear search through the pools in the 
> case of large allocations.  Unfortunately, I don't see any easy way to 
> fix this.  This patch at least allows short circuiting a large number of 
> pools, if there isn't enough free space in the whole pool, let alone 
> contiguous space.
> 
> Here are the benchmarks with this patch enabled.
> 
> Collected a 10 megabyte heap in 0 milliseconds.
> Collected a 50 megabyte heap in 0 milliseconds.
> Collected a 250 megabyte heap in 1 milliseconds.
> Collected a 500 megabyte heap in 0 milliseconds.
> Collected a 1000 megabyte heap in 1 milliseconds.
> Collected a 5000 megabyte heap in 3 milliseconds.
> Collected a 1 megabyte heap in 6 milliseconds.
> Collected a 3 megabyte heap in 16 milliseconds.
> Collected a 5 megabyte heap in 26 milliseconds.

Re: 64bit phobos on Windows?

[bearophile]

Andrej Mitrovic:

> I'm sorry for hijacking this topic guys. :p
> 
> I am getting somewhere though. GDC changeset 475, using GCC 4.5.0 with
> applied TDM-GCC 4.5.0 patches, with built gmp, mpc and mpftr. The
> Windows build documentation needs an update (I'll fix it myself given
> the chance).

If you are interested, this is the GCC I use (I use the binary versions, but 
below there are sources too):
http://nuwen.net/mingw.html

Bye,
bearophile

Re: O(N) GC: The patch

[bearophile]

Jason House:

> How does it effect other cases?

I have asked for the timings for a small benchmark, and the results are good 
(see the issue in Bugzilla).

Bye,
bearophile

Comparison vector ops

[bearophile]

Are comparison operators too going vectorial?

void main() {
int[5] a1, a2, a3;
bool[5] b1, b2;
ubyte[5] u1, u2;

a1 = [1, 2, 3, 4, 5];
a2 = [5, 2, 1, 4, 4];

b1 = a1[] > 3;
assert(b1 == [false, false, false, true, true]);
u1 = a1[] > 3;
assert(u1 == [0, 0, 0, 1, 1]);

b2 = a1[] > a2[];
assert(b2 == [false, false, true, false, true]);
u2 = a1[] > a2[];
assert(u2 == [0, 0, 1, 0, 1]);

a3 = max(a1[], a2[]);
assert(a3 == [5, 2, 3, 4, 5]);

assert(pack(a1, a1[] > 3) == [4, 5]);
}

Vectorial comparisons are common in NumPy code:
https://github.com/paulnasca/paulstretch_python/raw/master/paulstretch_stereo.py


If you take a look at the AVX instructions you get ideas for some other 
vectorial operations beside just the comparison ones, like vectorial loops:
http://software.intel.com/file/33301

A useless example:

void main() {
int[5] a0 = [0, 0, 0, 0, 0];
int[5] a = [1, 2, 3, 4, 5];
while (a[] > 0)
a[] = min(a[] - 1, a0[]);
assert(a0[] == a[]);
}

Bye,
bearophile

Re: float equality

[Kevin Bealer]

== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> Kevin Bealer wrote:
> > You could switch to this:
> >
> > struct {
> > BigInt numerator;
> > BigInt denominator;
> > };
> >
> > Bingo -- no compromise.
> It cannot represent irrational numbers accurately.

True but I did mention this a few lines later.

Kevin

Re: Feature request: "noexport" keyword

[Bernard Helyer]

On Sun, 20 Feb 2011 16:50:25 -0500, Nick Sabalausky wrote:
> Keep in mind though, I have *no* idea how "extern(...)" fits in to all
> of this.

The linkage is separate to the access and will continue when you change 
from export to public.

Re: float equality

[Walter Bright]

Kevin Bealer wrote:

== Quote from Walter Bright (newshou...@digitalmars.com)'s article

Kevin Bealer wrote:

You could switch to this:

struct {
BigInt numerator;
BigInt denominator;
};

Bingo -- no compromise.

It cannot represent irrational numbers accurately.


True but I did mention this a few lines later.


I guess I'm not seeing the point of representing numbers as ratios. That works 
only if you stick to arithmetic. As soon as you do logs, trig functions, roots, 
pi, etc., you're back to square one.

Re: float equality

[dsimcha]

On 2/20/2011 11:32 PM, Walter Bright wrote:

Kevin Bealer wrote:

== Quote from Walter Bright (newshou...@digitalmars.com)'s article

Kevin Bealer wrote:

You could switch to this:

struct {
BigInt numerator;
BigInt denominator;
};

Bingo -- no compromise.

It cannot represent irrational numbers accurately.


True but I did mention this a few lines later.


I guess I'm not seeing the point of representing numbers as ratios. That
works only if you stick to arithmetic. As soon as you do logs, trig
functions, roots, pi, etc., you're back to square one.


You, my friend, have obviously never used a computer algebra system (my 
favorite is Maxima) at all seriously.  I'm not saying it's a practical 
solution in the context of this discussion, but it is a possible 
solution in a lot of cases.  Basically, if you can't compute something 
exactly, you do the math symbolically (but programmatically) for as long 
as possible.  You convert to a floating point number only when it's 
explicitly asked for.

Re: float equality

[Walter Bright]

dsimcha wrote:
You, my friend, have obviously never used a computer algebra system (my 
favorite is Maxima) at all seriously.  I'm not saying it's a practical 
solution in the context of this discussion, but it is a possible 
solution in a lot of cases.  Basically, if you can't compute something 
exactly, you do the math symbolically (but programmatically) for as long 
as possible.  You convert to a floating point number only when it's 
explicitly asked for.


I do understand that if you have a full symbolic representation, you can do so 
with zero losses. But Kevin's proposal was not that, it was for a ratio 
representation.


All it represents symbolically is division. There are plenty of other 
operations.

Re: Linking COFF and OMF

[Trass3r]

I guess it linked printf with DMC's printf in snn.lib though,
so there might be some problems with foreign RTLs when one goes too far.


Can we replace snn with the other RTL?

Re: Linking COFF and OMF

[Don]

Trass3r wrote:

I guess it linked printf with DMC's printf in snn.lib though,
so there might be some problems with foreign RTLs when one goes too far.


Can we replace snn with the other RTL?


In 2.052 several of the most complicated dependencies on snn.lib (those 
relating to exception handling) were removed. I don't know how many more 
DMC-specific ones there are, but using another snn.lib might be possible 
now.

Re: float equality

[Kevin Bealer]

== Quote from Walter Bright (newshou...@digitalmars.com)'s article
...
> I do understand that if you have a full symbolic representation, you can do so
> with zero losses. But Kevin's proposal was not that, it was for a ratio
> representation.
>
> All it represents symbolically is division. There are plenty of other 
> operations.

I'm just answering the original poster's question.  You're right though -- it's 
not
a complete numerical system, (and I don't propose it for inclusion in the 
language
or even necessarily the library.)

I had two goals:

1. To solve the basic problem the original poster was asking -- if you are 
working
with simple decimals and arithmetic you can get completely accurate 
representations
this way.  For some cases like simple financial work this might work really 
well.
e.g. where float would not be because of the slow leak of information with each
operation.  (I assume real professional financial work is already done using a
(better) representation.)

2. To explain why the 'simple' task of representing something like .1 wasn't as 
easy
as it looks.  In other words, why the people who designed float weren't just 
brain
dead.  I think they really knew what they were doing but it shocks most people 
at
first that a modern computer can't do what they see as grade school arithmetic.

I think for some purposes though, lossless domain specific representations can
be a good tool -- if you can represent a problem in a way that is lossless you 
can
maybe do better calculations over long series than working with 'double' and 
taking
the accuracy hit.  This is necessarily an application specific technique though.

Kevin