Jump to page: 1 2
Thread overview
DMD 0.112 release
Jan 27, 2005
Walter
Jan 27, 2005
Dejan Lekic
Jan 27, 2005
Thomas Kuehne
Jan 27, 2005
Walter
Jan 27, 2005
pragma
Jan 27, 2005
Walter
Jan 27, 2005
Rod Haper
Jan 27, 2005
John Demme
Jan 27, 2005
Walter
Jan 31, 2005
Burton Radons
Jan 31, 2005
Walter
Feb 01, 2005
Ivan Senji
Feb 01, 2005
Walter
Feb 01, 2005
Ivan Senji
January 27, 2005
Some much requested goodies in Phobos.

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



January 27, 2005
Walter wrote:

> Some much requested goodies in Phobos.
> 
> http://www.digitalmars.com/d/changelog.html

I've updated the source RPM to match this:
http://www.algonet.se/~afb/d/dmd-0.112-4.nosrc.rpm

In release number 4 of the RPMS, I have added a
new "/usr/lib/libphobos-debug.a", that is the
same as the regular phobos library but *without*
the -release (and thus: with contracts enforced)
I couldn't add -g, since that just gives errors,
and -debug printed a lot of "_moduleCtor" cruft.
(So I just went with the usual -O for DFLAGS)

The specfile is available for browsing too:
http://www.algonet.se/~afb/d/dmd.spec


The unittest fails on format(734), same as always:
http://www.digitalmars.com/d/archives/digitalmars/D/bugs/2500.html

>     s = std.string.format(1.67, " %A ", -1.28, float.nan);
>     assert(s == "1.67 -0X1.47AE147AE147BP+0 nan");

BTW; You can run the phobos unittest automatically
when building the RPM, by using: --with unittest


But as far as I can tell, the -gt tracing
now seems to work just fine on Linux too...

http://www.digitalmars.com/d/dcompiler.html:
> -gt
>     add trace profiling hooks (not supported under linux)

I updated the dmd.1 manual page to correct this:
http://www.algonet.se/~afb/d/d-manpages/

--anders

PS.
http://www.digitalmars.com/d/changelog.html#new0112
> Note: This is a library only change,
> the dmd executables are still at 0.111.

Isn't this just bound to get *very* confusing later ?
Or is Phobos now a separate entity from regular DMD ?
January 27, 2005
Anders, i've encountered some problems during the building process (RPM). I
haven't had time to check why it happens. Here is copy/paste + information
about GCC on my machine:
../stlsoft/stlsoft_null.h: In function `const recls::recls_fileinfo_t*
recls::FileInfo_Allocate(size_t)':
../stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const
stlsoft::NULL_v&)' is private
recls_fileinfo_unix.cpp:237: error: within this context
../stlsoft/stlsoft_null.h: In function `void recls::FileInfo_Release(const
recls::recls_fileinfo_t*)':
../stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const
stlsoft::NULL_v&)' is private
recls_fileinfo_unix.cpp:256: error: within this context
../stlsoft/stlsoft_null.h: In function `recls::recls_rc_t
recls::FileInfo_Copy(const recls::recls_fileinfo_t*, const
recls::recls_fileinfo_t**)':
../stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const
stlsoft::NULL_v&)' is private
recls_fileinfo_unix.cpp:277: error: within this context
make[1]: *** [recls_fileinfo_unix.o] Error 1
make[1]: Leaving directory
`/home/share/dejan/redhat/tmp/dmd-0.112/dmd/src/phobos/etc/c/recls'
make: *** [etc/c/recls/recls_api.o] Error 2
fel: Dålig slutstatus från /home/dejan/var/redhat/tmp/rpm-tmp.770 (%build)


RPM-byggfel:
    Dålig slutstatus från /home/dejan/var/redhat/tmp/rpm-tmp.770 (%build)

dejan@gnu ~/var/redhat/dmd
$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk
--host=i386-redhat-linux
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)


-- 
...........
Dejan Lekic
  http://dejan.lekic.org

January 27, 2005
Dejan Lekic wrote:

> Anders, i've encountered some problems during the building process (RPM).

It built OK on Fedora Core 1, that's about all I know.

You can use the old SRPM, if you just want to package
DMD and Phobos and not rebuild anything like in rel 4.
http://www.algonet.se/~afb/d/dmd-0.111-3.nosrc.rpm

--anders
January 27, 2005
In article <ctab84$1eui$1@digitaldaemon.com>, Walter says...
>
>Some much requested goodies in Phobos.
>
>http://www.digitalmars.com/d/changelog.html
>

Quoth the manual:
> export void MyDLL_Initialize(void* gc)
> {
>     printf("MyDLL_Initialize()\n");
>     std.gc.setGCHandle(gc);
>     _minit();
>     _moduleCtor();
> //  _moduleUnitTests();
> }

Thank you, thank you, thank you, thank you Walter.  This is possibly the best all-round solution available.

Now all developers have to be aware of are autstanding v-table pointers (and delegates) into dll address space, in case of unloading a library at runtime.

One question remains though.  Is MyDLL_Initialize called for *every* process attach for the dll, or just the first time?  I'm curious since if it's not every time, there could be problems with one GC being responsible for all memory parceled out from a dll that is used by multiple processes.  Is this the case, or am I missing something?

Also, it looks like you also illustrated how to fix that pesky stdio bug on dll unload (Sorry if I missed this in the bugs newsgroup, its news to me) :

[DllMain]
"There isn't much to do here.  The only oddity is the setting of
std.d.stdio._fcloseallp to null. If this is not set to null, the C runtime will
flush and close all the standard I/O buffers (like stdout, stderr, etc.)
shutting off further output. Setting it to null defers the responsibility for
that to the caller of the DLL."

Again, you have my sincerest thanks for this (badly needed) update.


- EricAnderton at yahoo
January 27, 2005
In article <ctb1ka$2bj6$1@digitaldaemon.com>, Dejan Lekic says...
>
>
>Anders, i've encountered some problems during the building process (RPM). I
>haven't had time to check why it happens. Here is copy/paste + information
>about GCC on my machine:
>../stlsoft/stlsoft_null.h: In function `const recls::recls_fileinfo_t*
>recls::FileInfo_Allocate(size_t)':
>../stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const
>stlsoft::NULL_v&)' is private
>recls_fileinfo_unix.cpp:237: error: within this context
>../stlsoft/stlsoft_null.h: In function `void recls::FileInfo_Release(const
>recls::recls_fileinfo_t*)':
>../stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const
>stlsoft::NULL_v&)' is private
>recls_fileinfo_unix.cpp:256: error: within this context
>../stlsoft/stlsoft_null.h: In function `recls::recls_rc_t
>recls::FileInfo_Copy(const recls::recls_fileinfo_t*, const
>recls::recls_fileinfo_t**)':
>../stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const
>stlsoft::NULL_v&)' is private
>recls_fileinfo_unix.cpp:277: error: within this context
>make[1]: *** [recls_fileinfo_unix.o] Error 1
>make[1]: Leaving directory
>`/home/share/dejan/redhat/tmp/dmd-0.112/dmd/src/phobos/etc/c/recls'
>make: *** [etc/c/recls/recls_api.o] Error 2
>fel: Dålig slutstatus från /home/dejan/var/redhat/tmp/rpm-tmp.770 (%build)

open file phobos/etc/c/stlsoft/stlsoft_null.h

goto line 194 and declare
"NULL_v(const stlsoft::NULL_v&)" as public. This is problem shows up with some
GCC versions but doesn't show up with others.

Thomas


January 27, 2005
"Anders F Björklund" <afb@algonet.se> wrote in message news:ctaigr$1n2h$1@digitaldaemon.com...
> PS.
> http://www.digitalmars.com/d/changelog.html#new0112
> > Note: This is a library only change,
> > the dmd executables are still at 0.111.
>
> Isn't this just bound to get *very* confusing later ?
> Or is Phobos now a separate entity from regular DMD ?

It's confusing no matter what. I don't want to rebuild the binaries just to change the version number. But soon enough I'll update the compiler anyway <g>.


January 27, 2005
"pragma" <pragma_member@pathlink.com> wrote in message news:ctb2gl$2dh3$1@digitaldaemon.com...
> In article <ctab84$1eui$1@digitaldaemon.com>, Walter says...
> >
> >Some much requested goodies in Phobos.
> >
> >http://www.digitalmars.com/d/changelog.html
> >
>
> Quoth the manual:
> > export void MyDLL_Initialize(void* gc)
> > {
> >     printf("MyDLL_Initialize()\n");
> >     std.gc.setGCHandle(gc);
> >     _minit();
> >     _moduleCtor();
> > //  _moduleUnitTests();
> > }
>
> Thank you, thank you, thank you, thank you Walter.  This is possibly the
best
> all-round solution available.

You're welcome.

> Now all developers have to be aware of are autstanding v-table pointers
(and
> delegates) into dll address space, in case of unloading a library at
runtime.

You'll get a nice seg fault if you refer to anything in the dll address space after unloading <g>. (This doesn't apply to dynamically allocated data, this will be fine after the dll is unloaded.)

> One question remains though.  Is MyDLL_Initialize called for *every*
process
> attach for the dll, or just the first time?  I'm curious since if it's not
every
> time, there could be problems with one GC being responsible for all memory parceled out from a dll that is used by multiple processes.  Is this the
case,
> or am I missing something?

The way DLLs work on Win32 makes this no problem - each process that loads a DLL puts it in its own process address space. It effectively works like a seperate instance of a DLL is loaded for each process, they won't step on each other and won't need to be aware of each others' existence. The old 16 bit DLL system had to worry about this, 32 bit ones do not.

> Also, it looks like you also illustrated how to fix that pesky stdio bug
on dll
> unload (Sorry if I missed this in the bugs newsgroup, its news to me) :
>
> [DllMain]
> "There isn't much to do here.  The only oddity is the setting of
> std.d.stdio._fcloseallp to null. If this is not set to null, the C runtime
will
> flush and close all the standard I/O buffers (like stdout, stderr, etc.) shutting off further output. Setting it to null defers the responsibility
for
> that to the caller of the DLL."
>
> Again, you have my sincerest thanks for this (badly needed) update.
>
>
> - EricAnderton at yahoo


January 27, 2005
> From "What's New for D 0.112":
>
>         The -gt profiler  now works under Linux.


Thank you, Walter.  Much appreciated!
January 27, 2005
Great!  Is doing Linux SO's on your list for pre-1.0?  (please say yes)

Thanks for the profiler.  I've been wanting this for awhile.  Can't wait to try it.

John

Walter wrote:
> Some much requested goodies in Phobos.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> 
> 
« First   ‹ Prev
1 2