www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - exe file size

reply huurd <hurd 163.com> writes:
I use dwt+dwtx, a hello word exe size is 22M, after I use upx the size is
800kb.  

exe file appears to be a lot of meaningless repeat, how to remove it?
Nov 13 2008
next sibling parent Kagamin <spam here.lot> writes:
huurd Wrote:


 I use dwt+dwtx, a hello word exe size is 22M, after I use upx the size is
800kb.  
 
 exe file appears to be a lot of meaningless repeat, how to remove it?


You can't.
Nov 13 2008
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
huurd Wrote:

 I use dwt+dwtx, a hello word exe size is 22M, after I use upx the size is
800kb.  
 exe file appears to be a lot of meaningless repeat, how to remove it?


The best strategy is probably to change the compiler a little so it avoids
putting some of that stuff there in the first place :-)

Bye,
bearophile
Nov 13 2008
prev sibling next sibling parent "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Thu, 13 Nov 2008 12:07:57 +0200, huurd <hurd 163.com> wrote:


 I use dwt+dwtx, a hello word exe size is 22M, after I use upx the size  
 is 800kb.

 exe file appears to be a lot of meaningless repeat, how to remove it?


It shouldn't be so big without debug info. Check your compilation options  
and make sure you're not including symbols (not passing -g when linking).

-- 
Best regards,
  Vladimir                          mailto:thecybershadow gmail.com
Nov 13 2008
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
huurd wrote:

 I use dwt+dwtx, a hello word exe size is 22M, after I use upx the size is
800kb.  
 
 exe file appears to be a lot of meaningless repeat, how to remove it?


If you're using DSSS, try with oneatatime=false . THis will probably 
reduce it to 5-7M
Nov 13 2008
prev sibling next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
huurd wrote:

 I use dwt+dwtx, a hello word exe size is 22M, after I use upx the size is
800kb.  
 
 exe file appears to be a lot of meaningless repeat, how to remove it?


<joke> use a program like upx </joke>
Nov 13 2008
prev sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello huurd,


 I use dwt+dwtx, a hello word exe size is 22M, after I use upx the size
 is 800kb.
 
 exe file appears to be a lot of meaningless repeat, how to remove it?
 



22M is distastefully huge for a hello world example using dwt and dwtx :(. 
 Like other's suggested, maybe debug info is getting compiled in due to a 
-g switch. 

The file size still may end up being several megabytes, though, even without 
the debug info.  This is more of an annoyance, than a hindrance. DWT has 
a lot to offer; so most people end up coping with the size issue, especially 
if they know they can use something like upx to squeeze things tight.

I can't exactly remember what the cause of this is, but I think it has
something 
to do with scads of "hidden" D symbols (moduleinfo?) produced by the D compiler 
for projects that have a combination of (1) tons of modules and (2) many 
interdependencies amongst modules such that even a small project ends up 
linking in ALL (or nearly so) classes from the framework.  This, unfortunately, 
is one of DWT's weaknesses.  I wish the language could help DWT by fixing 
that, but I don't know if that is possible.  Other alternatives that might 
help reduce the problem (I think) is integrating multiple modules into one 
file...but that tends to hinder the whole idea of organization and namespace 
clarity. If DWT were to do this, it would also break import compatibility 
with SWT.  There are a few reasons why this approach is not desirable.

But I hear you.  I really don't like unnecessary bloat either.  It would 
be great if we had some super smart tools that could pair things down a bit.

-JJR
Nov 13 2008
next sibling parent reply huurd <hurd 163.com> writes:
I use The -O -release -inline , the size si 20M, there is no -g.
Nov 13 2008
next sibling parent reply huurd <hurd 163.com> writes:
the disassemble file is a lot repeat like "ADD [EAX],AL";
Nov 13 2008
parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Thu, Nov 13, 2008 at 10:41 PM, huurd <hurd 163.com> wrote:

 the disassemble file is a lot repeat like "ADD [EAX],AL";


That's just 0s.
Nov 13 2008
parent reply Kagamin <spam here.lot> writes:
Jarrett Billingsley Wrote:


 On Thu, Nov 13, 2008 at 10:41 PM, huurd <hurd 163.com> wrote:

 the disassemble file is a lot repeat like "ADD [EAX],AL";


 
 That's just 0s.


Hmm... Are they 4kb-long, I wonder?
Nov 14 2008
parent Frank Benoit <keinfarbton googlemail.com> writes:
Kagamin schrieb:

 Jarrett Billingsley Wrote:
 

 On Thu, Nov 13, 2008 at 10:41 PM, huurd <hurd 163.com> wrote:

 the disassemble file is a lot repeat like "ADD [EAX],AL";


 That's just 0s.


 
 Hmm... Are they 4kb-long, I wonder?


What does that mean? Are those stuffed space that gets disassembled like
that. Or could be a hint to a bug in codegen?
Nov 14 2008
prev sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello huurd,


 I use The -O -release -inline , the size si 20M, there is no -g.
 



Ouch. :(   I know dwt + dwtx pulls in a lot of modules.  I'm afraid this 
has been a niggling bother to me too, since I help port dwt, but I know there 
is no simple solution for this.

BTW, is this on Linux or windows?  If you are using linux, try using the 
"strip" command on the binary.  It should make it much smaller.

If not, well... the emphasis on dwt development right now is stability,
completion 
(as in porting), and close tracking of the SWT version.  Finding ways to 
make it smaller may be in the future (I've suggested such in prior posts), 
but doing so will be inextricably tied to the compiler/linker/language
technology 
and what these are able to do to reduce the footprint.  If these don't change 
somehow, there's little that can be done, other than make the oh-so annoying 
statement "Well, hey! These days, memory is so cheap and computers are so 
powerful that it really doesn't matter anymore" ;-).  Somehow, that isn't 
very convincing, I know :-) 

Upx is the best option for now, I guess. 800 kb isn't all that bad, actually.

-JJR
Nov 13 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Nov 14, 2008 at 2:38 PM, John Reimer <terminal.node gmail.com> wrote:

 Hello huurd,


 I use The -O -release -inline , the size si 20M, there is no -g.



 Ouch. :(   I know dwt + dwtx pulls in a lot of modules.  I'm afraid this has
 been a niggling bother to me too, since I help port dwt, but I know there is
 no simple solution for this.

 BTW, is this on Linux or windows?  If you are using linux, try using the
 "strip" command on the binary.  It should make it much smaller.

 If not, well... the emphasis on dwt development right now is stability,
 completion (as in porting), and close tracking of the SWT version.  Finding
 ways to make it smaller may be in the future (I've suggested such in prior
 posts), but doing so will be inextricably tied to the
 compiler/linker/language technology and what these are able to do to reduce
 the footprint.  If these don't change somehow, there's little that can be
 done, other than make the oh-so annoying statement "Well, hey! These days,
 memory is so cheap and computers are so powerful that it really doesn't
 matter anymore" ;-).  Somehow, that isn't very convincing, I know :-)
 Upx is the best option for now, I guess. 800 kb isn't all that bad,
 actually.


I think the build time of dwt apps is a much bigger issue right now
than the size of exes.  The size of exes can be reduced using hacks
like upx, but there is no fix for the long build times as far as I
know.

--bb
Nov 13 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Hello Bill,



 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.
 
 --bb
 



Totally agree.  The size is just an annoyance.  But currently the build times 
are pretty bad.  Recently, I've been frustrating over this especially while 
working on the Browser port.  Everytime I want to test a fix, I have to
recompile... 
which takes ages.  This seems to be partly due to the dsss dependency (recent 
version is sloooow).  I've been thinking of adding some sort of shell script 
or "make" file to see if this can be improved... at least for sanities' sake. 
:-(

-JJR
Nov 13 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Nov 14, 2008 at 3:55 PM, John Reimer <terminal.node gmail.com> wrote:

 Hello Bill,



 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.

 --bb



 Totally agree.  The size is just an annoyance.  But currently the build
 times are pretty bad.  Recently, I've been frustrating over this especially
 while working on the Browser port.  Everytime I want to test a fix, I have
 to recompile... which takes ages.  This seems to be partly due to the dsss
 dependency (recent version is sloooow).  I've been thinking of adding some
 sort of shell script or "make" file to see if this can be improved... at
 least for sanities' sake. :-(

 -JJR


Build times with the new dsss push me way past the sanity point, so
I've gone back to 0.76, which I think may have never been released.  I
think I built it myself from sources.

Build times with 0.76 are just barely tolerable with my app.  But my
colleague was telling me today that he wants to do his work on a
small, non-DWT test app instead of the main app because the build
times are too frustrating for him.

If I were forced to use the latest DSSS, I'd defnitely be trying to do
whatever I could to improve the build times, including using "make" if
that's what it took.

Hmm... Now that dmd -v will spit out all the modules imported, it
might be possible to use that to create a makefile (or a make.deps for
use by a makefile) automatically.

--bb
Nov 13 2008
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello Bill,


 On Fri, Nov 14, 2008 at 3:55 PM, John Reimer <terminal.node gmail.com>
 wrote:
 

 Hello Bill,
 

 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.
 
 --bb
 


 Totally agree.  The size is just an annoyance.  But currently the
 build times are pretty bad.  Recently, I've been frustrating over
 this especially while working on the Browser port.  Everytime I want
 to test a fix, I have to recompile... which takes ages.  This seems
 to be partly due to the dsss dependency (recent version is sloooow).
 I've been thinking of adding some sort of shell script or "make" file
 to see if this can be improved... at least for sanities' sake. :-(
 
 -JJR
 


 Build times with the new dsss push me way past the sanity point, so
 I've gone back to 0.76, which I think may have never been released.  I
 think I built it myself from sources.
 
 Build times with 0.76 are just barely tolerable with my app.  But my
 colleague was telling me today that he wants to do his work on a
 small, non-DWT test app instead of the main app because the build
 times are too frustrating for him.
 
 If I were forced to use the latest DSSS, I'd defnitely be trying to do
 whatever I could to improve the build times, including using "make" if
 that's what it took.
 
 Hmm... Now that dmd -v will spit out all the modules imported, it
 might be possible to use that to create a makefile (or a make.deps for
 use by a makefile) automatically.
 
 --bb
 



Frank uses 0.75, but I can't get it to work with Tango svn... But it did 
appear to be much quicker than 0.78.  

I noticed just doing a dmd *.c on a DWT directory compiles things pretty 
fast... so that's why I was considering a shell script or make file.  The 
only thing I'd miss is the installation and automatic library creation features 
of dsss.  But I need the speed more.

The dmd -v option has actually been available for quite awhile (a couple 
years?).  "jake", a build tool Kris threw together a year or two ago, makes 
good use of dmd -v import list to do some blazingly fast compiles on windows.

Awhile ago, I had considered porting "jake" to linux (it's C source but with 
win32 functions).  I may have another look at doing that.  DWT really needs 
it.

-JJR
Nov 14 2008
parent reply TomD <t_demmer nospam.web.de> writes:
John Reimer Wrote:
[...]
My quickfix:
----- Snip ----







for d in `find $1 -type d`; do
    cd $d
    ls *.d >/dev/null 2>/dev/null
    if [ $? == 0 ] ; then
        rm -f Makefile
        echo "SRC=" `ls *.d` > Makefile
        echo 'OBJ=   $(SRC:.d=$(OBJEXT))' >> Makefile
        echo '%.obj: %.d' >> Makefile
        echo -e '\t $(DC) $(DCSYSFLAGS) $(DCFLAGS) -c $<' >> Makefile
        echo 'all: $(OBJ)' >> Makefile
        echo 'clean:'  >> Makefile
        echo -e '\t rm $(OBJ)' >> Makefile
        
        hasd=1
    else
        hasd=0
    fi
    cd - > /dev/null
    if [ $hasd == 1  ] ; then
        echo make -C $d all
    fi
---- snap ---
Nov 14 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Hello TomD,


 John Reimer Wrote:
 [...]
 My quickfix:
 ----- Snip ----







 for d in `find $1 -type d`; do
 cd $d
 ls *.d >/dev/null 2>/dev/null
 if [ $? == 0 ] ; then
 rm -f Makefile
 echo "SRC=" `ls *.d` > Makefile
 echo 'OBJ=   $(SRC:.d=$(OBJEXT))' >> Makefile
 echo '%.obj: %.d' >> Makefile
 echo -e '\t $(DC) $(DCSYSFLAGS) $(DCFLAGS) -c $<' >> Makefile
 echo 'all: $(OBJ)' >> Makefile
 echo 'clean:'  >> Makefile
 echo -e '\t rm $(OBJ)' >> Makefile
 hasd=1
 else
 hasd=0
 fi
 cd - > /dev/null
 if [ $hasd == 1  ] ; then
 echo make -C $d all
 fi
 ---- snap ---



Thanks for the example.  I've avoided makefiles in the past because, despite 
their power and flexibility, they are too complicated for what amounts to 
a fairly simple task in most cases.  Granted, once they are created for a 
project, there shouldn't be much need to fiddle with them more.

Anyway, I'll keep your sample above in mind if I go this route.  Thanks. :)

-JJR
Nov 14 2008
parent reply TomD <t_demmer nospam.web.de> writes:
John Reimer Wrote:
[...]

 Thanks for the example.  I've avoided makefiles in the past because, despite 
 their power and flexibility, they are too complicated for what amounts to 
 a fairly simple task in most cases.  Granted, once they are created for a 
 project, there shouldn't be much need to fiddle with them more.
 
 Anyway, I'll keep your sample above in mind if I go this route.  Thanks. :)
 
 -JJR


What I have learned this weekend is "don't try to be smart when brute force
is just enough".
The following script is the fastest way to rebuild dwt on linux:
-----

DMD=/opt/dmd/bin/dmd
DMDFLAGS="-debuglib=tango-base-dmd -defaultlib=tango-base-dmd"
DMDFLAGS=$DMDFLAGS" -I/opt/dmd/import"
DMDFLAGS=$DMDFLAGS" -version=Tango -version=Posix -L-tango-user-dmd"
DMDFLAGS=$DMDFLAGS" -O -release"

WBD=`pwd`
DMDFLAGS="-I$WBD $DMDFLAGS"

echo "Compile command:"
echo $DMD $DMDFLAGS -c -op
find dwt -iname \*.d | xargs $DMD $DMDFLAGS -c -op
echo "done compiling, build libdwt.a"
find dwt -name \*.o | xargs ar -svr libdwt.a
----
That takes 27s on my Laptop. I used to do the same directorywise,
that takes about 1m15s. Looks like the best strategy for a build
tool is to first grab the names of the files to recompile and then
give it to one instance of dmd to compile all of them at once. Unfortunately,
the -v switch  does not help when invoking dmd like this.

Ciao
Tom
Nov 16 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Sun, Nov 16, 2008 at 6:01 PM, TomD <t_demmer nospam.web.de> wrote:

 John Reimer Wrote:
 [...]

 Thanks for the example.  I've avoided makefiles in the past because, despite
 their power and flexibility, they are too complicated for what amounts to
 a fairly simple task in most cases.  Granted, once they are created for a
 project, there shouldn't be much need to fiddle with them more.

 Anyway, I'll keep your sample above in mind if I go this route.  Thanks. :)

 -JJR


 What I have learned this weekend is "don't try to be smart when brute force
 is just enough".
 The following script is the fastest way to rebuild dwt on linux:
 -----

 DMD=/opt/dmd/bin/dmd
 DMDFLAGS="-debuglib=tango-base-dmd -defaultlib=tango-base-dmd"
 DMDFLAGS=$DMDFLAGS" -I/opt/dmd/import"
 DMDFLAGS=$DMDFLAGS" -version=Tango -version=Posix -L-tango-user-dmd"
 DMDFLAGS=$DMDFLAGS" -O -release"

 WBD=`pwd`
 DMDFLAGS="-I$WBD $DMDFLAGS"

 echo "Compile command:"
 echo $DMD $DMDFLAGS -c -op
 find dwt -iname \*.d | xargs $DMD $DMDFLAGS -c -op
 echo "done compiling, build libdwt.a"
 find dwt -name \*.o | xargs ar -svr libdwt.a
 ----
 That takes 27s on my Laptop. I used to do the same directorywise,
 that takes about 1m15s. Looks like the best strategy for a build
 tool is to first grab the names of the files to recompile and then
 give it to one instance of dmd to compile all of them at once. Unfortunately,
 the -v switch  does not help when invoking dmd like this.


This agrees with the conventional wisdom for using dsss, which is to
turn the oneatatime option to off.  I believe that causes dmd to be
called once with all the dependent files as args.

--bb
Nov 16 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Hello Bill,


 On Sun, Nov 16, 2008 at 6:01 PM, TomD <t_demmer nospam.web.de> wrote:
 

 John Reimer Wrote:
 [...]

 Thanks for the example.  I've avoided makefiles in the past because,
 despite
 their power and flexibility, they are too complicated for what
 amounts to
 a fairly simple task in most cases.  Granted, once they are created
 for a
 project, there shouldn't be much need to fiddle with them more.
 Anyway, I'll keep your sample above in mind if I go this route.
 Thanks. :)
 
 -JJR
 


 What I have learned this weekend is "don't try to be smart when brute
 force
 is just enough".
 The following script is the fastest way to rebuild dwt on linux:
 -----

 DMD=/opt/dmd/bin/dmd
 DMDFLAGS="-debuglib=tango-base-dmd -defaultlib=tango-base-dmd"
 DMDFLAGS=$DMDFLAGS" -I/opt/dmd/import"
 DMDFLAGS=$DMDFLAGS" -version=Tango -version=Posix -L-tango-user-dmd"
 DMDFLAGS=$DMDFLAGS" -O -release"
 WBD=`pwd`
 DMDFLAGS="-I$WBD $DMDFLAGS"
 echo "Compile command:"
 echo $DMD $DMDFLAGS -c -op
 find dwt -iname \*.d | xargs $DMD $DMDFLAGS -c -op
 echo "done compiling, build libdwt.a"
 find dwt -name \*.o | xargs ar -svr libdwt.a
 ----
 That takes 27s on my Laptop. I used to do the same directorywise,
 that takes about 1m15s. Looks like the best strategy for a build
 tool is to first grab the names of the files to recompile and then
 give it to one instance of dmd to compile all of them at once.
 Unfortunately,
 the -v switch  does not help when invoking dmd like this.


 This agrees with the conventional wisdom for using dsss, which is to
 turn the oneatatime option to off.  I believe that causes dmd to be
 called once with all the dependent files as args.
 
 --bb
 



An update:  

I'm back to using dsss successfully with acceptable build times.   I followed 
a setup similar to Frank's and managed to install dsss 0.75 correctly such 
that it builds a dwt-based project in approximately 38 seconds (with -gc 
flag active).  For debug/test builds, I avoid building the dwt library itself 
and simply reference the dwt directory as a source library while compiling 
the test project.  With a slight adjustment to the etc/rebuild/dmd-tango-posix 
config file, I'm now content with the ease of building sample projects via 
dsss.

Incidentally, I was originally doing all this on a linux distribution installed 
in a virtual machine (VirtualBox originally, then Vmware) which probably 
slowed the build times further.  I have since moved to using colinux under 
Windows XP which has proved to be a delight to work under.  For those
interested, 
there are a couple of linux distribution projects that use colinux as there 
base.  It basically allows you to run linux and linux programs full speed 
as a win32 service.  X windows programs can run seemlessly with win32 apps 
by using XMing which is installed as part of the package.  The apps run very 
fast since they are not being run inside a virtual machine!

Here's the link to just one of the colinux distribtuions (based on Ubuntu, 
the one I am currently using):

http://www.andlinux.org/

And here's a link that list a few other options:

http://colinux.wikia.com/wiki/Installation_out_of_the_box

You should still have a fair bit of RAM to run coLinux.  I've got 1 GB on 
my laptop, but 2+ GB probably would be better.

-JJR
Nov 29 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
John Reimer wrote:

 Hello Bill,
 

 On Sun, Nov 16, 2008 at 6:01 PM, TomD <t_demmer nospam.web.de> wrote:


 John Reimer Wrote:
 [...]

 Thanks for the example.  I've avoided makefiles in the past because,
 despite
 their power and flexibility, they are too complicated for what
 amounts to
 a fairly simple task in most cases.  Granted, once they are created
 for a
 project, there shouldn't be much need to fiddle with them more.
 Anyway, I'll keep your sample above in mind if I go this route.
 Thanks. :)

 -JJR


 What I have learned this weekend is "don't try to be smart when brute
 force
 is just enough".
 The following script is the fastest way to rebuild dwt on linux:
 -----

 DMD=/opt/dmd/bin/dmd
 DMDFLAGS="-debuglib=tango-base-dmd -defaultlib=tango-base-dmd"
 DMDFLAGS=$DMDFLAGS" -I/opt/dmd/import"
 DMDFLAGS=$DMDFLAGS" -version=Tango -version=Posix -L-tango-user-dmd"
 DMDFLAGS=$DMDFLAGS" -O -release"
 WBD=`pwd`
 DMDFLAGS="-I$WBD $DMDFLAGS"
 echo "Compile command:"
 echo $DMD $DMDFLAGS -c -op
 find dwt -iname \*.d | xargs $DMD $DMDFLAGS -c -op
 echo "done compiling, build libdwt.a"
 find dwt -name \*.o | xargs ar -svr libdwt.a
 ----
 That takes 27s on my Laptop. I used to do the same directorywise,
 that takes about 1m15s. Looks like the best strategy for a build
 tool is to first grab the names of the files to recompile and then
 give it to one instance of dmd to compile all of them at once.
 Unfortunately,
 the -v switch  does not help when invoking dmd like this.


 This agrees with the conventional wisdom for using dsss, which is to
 turn the oneatatime option to off.  I believe that causes dmd to be
 called once with all the dependent files as args.

 --bb


 
 
 An update: 
 I'm back to using dsss successfully with acceptable build times.   I 
 followed a setup similar to Frank's and managed to install dsss 0.75 
 correctly such that it builds a dwt-based project in approximately 38 
 seconds (with -gc flag active).  For debug/test builds, I avoid building 
 the dwt library itself and simply reference the dwt directory as a 
 source library while compiling the test project.  With a slight 
 adjustment to the etc/rebuild/dmd-tango-posix config file, I'm now 
 content with the ease of building sample projects via dsss.
 
 Incidentally, I was originally doing all this on a linux distribution 
 installed in a virtual machine (VirtualBox originally, then Vmware) 
 which probably slowed the build times further.  I have since moved to 
 using colinux under Windows XP which has proved to be a delight to work 
 under.  For those interested, there are a couple of linux distribution 
 projects that use colinux as there base.  It basically allows you to run 
 linux and linux programs full speed as a win32 service.  X windows 
 programs can run seemlessly with win32 apps by using XMing which is 
 installed as part of the package.  The apps run very fast since they are 
 not being run inside a virtual machine!
 
 Here's the link to just one of the colinux distribtuions (based on 
 Ubuntu, the one I am currently using):
 
 http://www.andlinux.org/
 
 And here's a link that list a few other options:
 
 http://colinux.wikia.com/wiki/Installation_out_of_the_box
 
 You should still have a fair bit of RAM to run coLinux.  I've got 1 GB 
 on my laptop, but 2+ GB probably would be better.
 
 -JJR


Thanks for introducing me to coLinux! Sadly, no 64-bit support yet, 
otherwise I would be installing it as I write this. That's a very 
awesome project.
Nov 29 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Hello Robert,


 


 Thanks for introducing me to coLinux! Sadly, no 64-bit support yet,
 otherwise I would be installing it as I write this. That's a very
 awesome project.
 



Yep, no problem.  I don't know if 64-bit is in the pipe for colinux, but 
that would certainly make it more awesome for sure :-). Probably something 
to keep one's eye on.

The only slight frustration right now for me is that I failed to get eclipse 
3.4 working, so I can't put descent to good use. ;)
I don't know what the problem is, but it might have something to do with 
my Java configuration.  Oh well.

-JJR
Nov 30 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
John Reimer wrote:

 Hello Robert,
 


 Thanks for introducing me to coLinux! Sadly, no 64-bit support yet,
 otherwise I would be installing it as I write this. That's a very
 awesome project.


 
 
 Yep, no problem.  I don't know if 64-bit is in the pipe for colinux, but 
 that would certainly make it more awesome for sure :-). Probably 
 something to keep one's eye on.
 
 The only slight frustration right now for me is that I failed to get 
 eclipse 3.4 working, so I can't put descent to good use. ;)
 I don't know what the problem is, but it might have something to do with 
 my Java configuration.  Oh well.
 
 -JJR


It's impossible to run Eclipse under Windows and save to the linux drive 
(mounted under Windows, obviously)?



 Nov 30 2008



  parent  John Reimer <terminal.node gmail.com>  writes:


Hello Robert,


 John Reimer wrote:
 

 Hello Robert,
 

 Thanks for introducing me to coLinux! Sadly, no 64-bit support yet,
 otherwise I would be installing it as I write this. That's a very
 awesome project.
 


 Yep, no problem.  I don't know if 64-bit is in the pipe for colinux,
 but that would certainly make it more awesome for sure :-). Probably
 something to keep one's eye on.
 
 The only slight frustration right now for me is that I failed to get
 eclipse 3.4 working, so I can't put descent to good use. ;)
 I don't know what the problem is, but it might have something to do
 with
 my Java configuration.  Oh well.
 -JJR
 


 It's impossible to run Eclipse under Windows and save to the linux
 drive (mounted under Windows, obviously)?
 



Hmm... Actually, it should be possible in a different way.  During the install, 
colinux gets you to choose a windows directory to mount so that you have 
direct access (both read and write, if you want) from within colinux.  Kind 
of the opposite of what you are suggesting, but maybe I can make use of that 
somehow (although, I'm not sure linux will like building a project from the 
mounted ntfs partition).  

Even if I could access the linux partition directly, though, I'm not sure 
it would be very safe to have write access to an ext3-fs from windows.

I'll have to think about this one.  Would be nice if I could just get Eclipse 
working.  :-)  In the meantime, it's easy enough just to use some other editor 
(gedit for now) along with the commandline.

-JJR



 Nov 30 2008



prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


Bill Baxter wrote:

 On Fri, Nov 14, 2008 at 3:55 PM, John Reimer <terminal.node gmail.com> wrote:

 Hello Bill,



 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.

 --bb


 Totally agree.  The size is just an annoyance.  But currently the build
 times are pretty bad.  Recently, I've been frustrating over this especially
 while working on the Browser port.  Everytime I want to test a fix, I have
 to recompile... which takes ages.  This seems to be partly due to the dsss
 dependency (recent version is sloooow).  I've been thinking of adding some
 sort of shell script or "make" file to see if this can be improved... at
 least for sanities' sake. :-(

 -JJR


 
 Build times with the new dsss push me way past the sanity point, so
 I've gone back to 0.76, which I think may have never been released.  I
 think I built it myself from sources.
 
 Build times with 0.76 are just barely tolerable with my app.  But my
 colleague was telling me today that he wants to do his work on a
 small, non-DWT test app instead of the main app because the build
 times are too frustrating for him.
 
 If I were forced to use the latest DSSS, I'd defnitely be trying to do
 whatever I could to improve the build times, including using "make" if
 that's what it took.
 
 Hmm... Now that dmd -v will spit out all the modules imported, it
 might be possible to use that to create a makefile (or a make.deps for
 use by a makefile) automatically.
 
 --bb


I suggest people to try rdmd out. It comes with the standard 
distribution and I'd want to improve it based on feedback.

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

Andrei



 Nov 14 2008



 next sibling parent  Max Samukha <samukha voliacable.com.removethis>  writes:


On Fri, 14 Nov 2008 02:04:55 -0600, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:


Bill Baxter wrote:

 On Fri, Nov 14, 2008 at 3:55 PM, John Reimer <terminal.node gmail.com> wrote:

 Hello Bill,



 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.

 --bb


 Totally agree.  The size is just an annoyance.  But currently the build
 times are pretty bad.  Recently, I've been frustrating over this especially
 while working on the Browser port.  Everytime I want to test a fix, I have
 to recompile... which takes ages.  This seems to be partly due to the dsss
 dependency (recent version is sloooow).  I've been thinking of adding some
 sort of shell script or "make" file to see if this can be improved... at
 least for sanities' sake. :-(

 -JJR


 
 Build times with the new dsss push me way past the sanity point, so
 I've gone back to 0.76, which I think may have never been released.  I
 think I built it myself from sources.
 
 Build times with 0.76 are just barely tolerable with my app.  But my
 colleague was telling me today that he wants to do his work on a
 small, non-DWT test app instead of the main app because the build
 times are too frustrating for him.
 
 If I were forced to use the latest DSSS, I'd defnitely be trying to do
 whatever I could to improve the build times, including using "make" if
 that's what it took.
 
 Hmm... Now that dmd -v will spit out all the modules imported, it
 might be possible to use that to create a makefile (or a make.deps for
 use by a makefile) automatically.
 
 --bb


I suggest people to try rdmd out. It comes with the standard 
distribution and I'd want to improve it based on feedback.

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

Andrei


I'd use it if it worked on Windows. I'd also like to see in rdmd the
feature of rebuild that enables generation of fully qualified names
for doc files. Thanks!



 Nov 14 2008



prev sibling next sibling parent reply BLS <nanali notthatwanadoo.fr>  writes:


Andrei Alexandrescu Wrote:


 Bill Baxter wrote:

 On Fri, Nov 14, 2008 at 3:55 PM, John Reimer <terminal.node gmail.com> wrote:

 Hello Bill,



 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.

 --bb


 Totally agree.  The size is just an annoyance.  But currently the build
 times are pretty bad.  Recently, I've been frustrating over this especially
 while working on the Browser port.  Everytime I want to test a fix, I have
 to recompile... which takes ages.  This seems to be partly due to the dsss
 dependency (recent version is sloooow).  I've been thinking of adding some
 sort of shell script or "make" file to see if this can be improved... at
 least for sanities' sake. :-(

 -JJR


 
 Build times with the new dsss push me way past the sanity point, so
 I've gone back to 0.76, which I think may have never been released.  I
 think I built it myself from sources.
 
 Build times with 0.76 are just barely tolerable with my app.  But my
 colleague was telling me today that he wants to do his work on a
 small, non-DWT test app instead of the main app because the build
 times are too frustrating for him.
 
 If I were forced to use the latest DSSS, I'd defnitely be trying to do
 whatever I could to improve the build times, including using "make" if
 that's what it took.
 
 Hmm... Now that dmd -v will spit out all the modules imported, it
 might be possible to use that to create a makefile (or a make.deps for
 use by a makefile) automatically.
 
 --bb


 
 I suggest people to try rdmd out. It comes with the standard 
 distribution and I'd want to improve it based on feedback.
 
 http://www.digitalmars.com/d/2.0/rdmd.html
 
 Andrei


Hi , 
atm I am not at home but I have a nice Windows popen() emulation  based on
windows pipes, so not exactly the same, but imo good enough. I can send you the
sources when I am back in france. Or just google for popen windows pipes. would
be a nice to have rdmd as windoxs too
björn
fighting with different kezbqrd lqouts 



 Nov 14 2008



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


BLS wrote:

 Andrei Alexandrescu Wrote:
 

 Bill Baxter wrote:

 On Fri, Nov 14, 2008 at 3:55 PM, John Reimer <terminal.node gmail.com> wrote:

 Hello Bill,



 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.

 --bb


 Totally agree.  The size is just an annoyance.  But currently the build
 times are pretty bad.  Recently, I've been frustrating over this especially
 while working on the Browser port.  Everytime I want to test a fix, I have
 to recompile... which takes ages.  This seems to be partly due to the dsss
 dependency (recent version is sloooow).  I've been thinking of adding some
 sort of shell script or "make" file to see if this can be improved... at
 least for sanities' sake. :-(

 -JJR


 Build times with the new dsss push me way past the sanity point, so
 I've gone back to 0.76, which I think may have never been released.  I
 think I built it myself from sources.

 Build times with 0.76 are just barely tolerable with my app.  But my
 colleague was telling me today that he wants to do his work on a
 small, non-DWT test app instead of the main app because the build
 times are too frustrating for him.

 If I were forced to use the latest DSSS, I'd defnitely be trying to do
 whatever I could to improve the build times, including using "make" if
 that's what it took.

 Hmm... Now that dmd -v will spit out all the modules imported, it
 might be possible to use that to create a makefile (or a make.deps for
 use by a makefile) automatically.

 --bb


 I suggest people to try rdmd out. It comes with the standard 
 distribution and I'd want to improve it based on feedback.

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

 Andrei


 Hi , 
 atm I am not at home but I have a nice Windows popen() emulation  based on
windows pipes, so not exactly the same, but imo good enough. I can send you the
sources when I am back in france. Or just google for popen windows pipes. would
be a nice to have rdmd as windoxs too
 björn
 fighting with different kezbqrd lqouts 


A cursory search does not yield the holy grail, so I'll be grateful if 
you followed up, preferably with a nicely packaged implementation :o). 
Thanks!

Andrei



 Nov 14 2008



prev sibling next sibling parent  John Reimer <terminal.node gmail.com>  writes:


Hello Andrei,


 Bill Baxter wrote:
 

 On Fri, Nov 14, 2008 at 3:55 PM, John Reimer
 <terminal.node gmail.com> wrote:
 

 Hello Bill,
 

 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.
 
 --bb
 


 Totally agree.  The size is just an annoyance.  But currently the
 build times are pretty bad.  Recently, I've been frustrating over
 this especially while working on the Browser port.  Everytime I want
 to test a fix, I have to recompile... which takes ages.  This seems
 to be partly due to the dsss dependency (recent version is sloooow).
 I've been thinking of adding some sort of shell script or "make"
 file to see if this can be improved... at least for sanities' sake.
 :-(
 
 -JJR
 


 Build times with the new dsss push me way past the sanity point, so
 I've gone back to 0.76, which I think may have never been released.
 I think I built it myself from sources.
 
 Build times with 0.76 are just barely tolerable with my app.  But my
 colleague was telling me today that he wants to do his work on a
 small, non-DWT test app instead of the main app because the build
 times are too frustrating for him.
 
 If I were forced to use the latest DSSS, I'd defnitely be trying to
 do whatever I could to improve the build times, including using
 "make" if that's what it took.
 
 Hmm... Now that dmd -v will spit out all the modules imported, it
 might be possible to use that to create a makefile (or a make.deps
 for use by a makefile) automatically.
 
 --bb
 


 I suggest people to try rdmd out. It comes with the standard
 distribution and I'd want to improve it based on feedback.
 
 http://www.digitalmars.com/d/2.0/rdmd.html
 
 Andrei
 



Interesting.  I never thought of rdmd for this purpose.  I'll see what if 
it can help here.  Thanks for the suggestion. :-)

-JJR



 Nov 14 2008



prev sibling  parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Andrei Alexandrescu wrote:


 I suggest people to try rdmd out. It comes with the standard 
 distribution and I'd want to improve it based on feedback.
 
 http://www.digitalmars.com/d/2.0/rdmd.html


http://dsource.org/projects/phobos/browser/trunk/tools/rdmd.d

For the portable version of rdmd you would want to replace
version(linux) with version(Unix), like done for rdmd 1.0:

http://dgcc.svn.sourceforge.net/viewvc/dgcc/trunk/d/rdmd.d?view=markup

--anders



 Nov 15 2008



prev sibling  parent reply Lutger <lutger.blijdestijn gmail.com>  writes:


Bill Baxter wrote:
...

 Build times with the new dsss push me way past the sanity point, so
 I've gone back to 0.76, which I think may have never been released.  I
 think I built it myself from sources.
 
 Build times with 0.76 are just barely tolerable with my app.  But my
 colleague was telling me today that he wants to do his work on a
 small, non-DWT test app instead of the main app because the build
 times are too frustrating for him.
 
 If I were forced to use the latest DSSS, I'd defnitely be trying to do
 whatever I could to improve the build times, including using "make" if
 that's what it took.
 
 Hmm... Now that dmd -v will spit out all the modules imported, it
 might be possible to use that to create a makefile (or a make.deps for
 use by a makefile) automatically.
 
 --bb


I didn't notice dsss has such a large overhead, is this due to dsss parsing
the whole source, or has it something to do with how it compiles
applications? If it is the latter, perhaps that's amenable with some
configuration?

Dsss does multicore builds, that probably cancels out the overhead on my
machine.



 Nov 30 2008



  parent  John Reimer <terminal.node gmail.com>  writes:


Hello lutger,


 Bill Baxter wrote:
 ...

 Build times with the new dsss push me way past the sanity point, so
 I've gone back to 0.76, which I think may have never been released.
 I think I built it myself from sources.
 
 Build times with 0.76 are just barely tolerable with my app.  But my
 colleague was telling me today that he wants to do his work on a
 small, non-DWT test app instead of the main app because the build
 times are too frustrating for him.
 
 If I were forced to use the latest DSSS, I'd defnitely be trying to
 do whatever I could to improve the build times, including using
 "make" if that's what it took.
 
 Hmm... Now that dmd -v will spit out all the modules imported, it
 might be possible to use that to create a makefile (or a make.deps
 for use by a makefile) automatically.
 
 --bb
 


 I didn't notice dsss has such a large overhead, is this due to dsss
 parsing the whole source, or has it something to do with how it
 compiles applications? If it is the latter, perhaps that's amenable
 with some configuration?
 
 Dsss does multicore builds, that probably cancels out the overhead on
 my machine.
 



I'm not sure what the reason is, but I imagine the re-parsing is only part 
of it because dsss 0.75 is actually pretty fast (compared to release 0.78).

I think I remember Gregor suggesting that performance could be improved (or 
at least dsss could be simplified) if he had access to a new feature in the 
dmd compiler ("-ignore" flag: ignore unsupported pragmas).  That feature 
was added several versions ago, but I think Gregor has been too busy to make 
use of it.  I can't remember how using this flag could fix things for dsss, 
though.  The answer lies somewhere in posts from earlier this year.

-JJR



 Nov 30 2008



prev sibling  parent reply Jeffrey Rennie <surferjeff excite.com>  writes:


John Reimer wrote:

 Hello Bill,
 
 

 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.

 --bb


 
 
 Totally agree.  The size is just an annoyance.  But currently the build 
 times are pretty bad.  Recently, I've been frustrating over this 
 especially while working on the Browser port.  Everytime I want to test 
 a fix, I have to recompile... which takes ages.  This seems to be partly 
 due to the dsss dependency (recent version is sloooow).  I've been 
 thinking of adding some sort of shell script or "make" file to see if 
 this can be improved... at least for sanities' sake. :-(
 
 -JJR
 
 


Naturally, for some of us, .exe size is more important.  Specifically, 
for those of us building software that will be downloaded by users at home.

But then again, I always build GUIs using native libraries--WTL on Win32 
and Objective-C on Mac--so I'm likely not a DWT customer anyway.



 Nov 14 2008



  parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com>  writes:


On Fri, Nov 14, 2008 at 10:46 AM, Jeffrey Rennie <surferjeff excite.com> wrote:

 John Reimer wrote:

 Hello Bill,



 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.

 --bb



 Totally agree.  The size is just an annoyance.  But currently the build
 times are pretty bad.  Recently, I've been frustrating over this especially
 while working on the Browser port.  Everytime I want to test a fix, I have
 to recompile... which takes ages.  This seems to be partly due to the dsss
 dependency (recent version is sloooow).  I've been thinking of adding some
 sort of shell script or "make" file to see if this can be improved... at
 least for sanities' sake. :-(

 -JJR


 Naturally, for some of us, .exe size is more important.  Specifically, for
 those of us building software that will be downloaded by users at home.

 But then again, I always build GUIs using native libraries--WTL on Win32 and
 Objective-C on Mac--so I'm likely not a DWT customer anyway.


I'm pretty sure DWT uses the underlying native GUI APIs.  At least it
looked that way when I saw it demonstrated.



 Nov 14 2008



  parent  John Reimer <terminal.node gmail.com>  writes:


Hello Jarrett,


 On Fri, Nov 14, 2008 at 10:46 AM, Jeffrey Rennie
 <surferjeff excite.com> wrote:
 

 John Reimer wrote:
 

 Hello Bill,
 

 I think the build time of dwt apps is a much bigger issue right now
 than the size of exes.  The size of exes can be reduced using hacks
 like upx, but there is no fix for the long build times as far as I
 know.
 
 --bb
 


 Totally agree.  The size is just an annoyance.  But currently the
 build times are pretty bad.  Recently, I've been frustrating over
 this especially while working on the Browser port.  Everytime I want
 to test a fix, I have to recompile... which takes ages.  This seems
 to be partly due to the dsss dependency (recent version is sloooow).
 I've been thinking of adding some sort of shell script or "make"
 file to see if this can be improved... at least for sanities' sake.
 :-(
 
 -JJR
 


 Naturally, for some of us, .exe size is more important.
 Specifically, for those of us building software that will be
 downloaded by users at home.
 
 But then again, I always build GUIs using native libraries--WTL on
 Win32 and Objective-C on Mac--so I'm likely not a DWT customer
 anyway.
 


 I'm pretty sure DWT uses the underlying native GUI APIs.  At least it
 looked that way when I saw it demonstrated.
 



Yes, it does so on all platforms (GTK on Linux, win32/64 API on Windows, 
Cocoa on Mac).  That's the main principle behind SWT and the deciding factor 
for us choosing to port it :).  This is what differentiates it from other 
Java frameworks like Swing.  In D, the size appears to be a result of both 
the SWT design (and shear size of the project) and the compiler/linker
implementation.

-JJR



 Nov 14 2008



prev sibling  parent  yidabu <yidabu.spam gmail.com>  writes:


On Fri, 14 Nov 2008 02:14:23 +0000 (UTC)
John Reimer <terminal.node gmail.com> wrote:


 Hello huurd,
 

 I use dwt+dwtx, a hello word exe size is 22M, after I use upx the size
 is 800kb.
 
 exe file appears to be a lot of meaningless repeat, how to remove it?
 


 
 
 22M is distastefully huge for a hello world example using dwt and dwtx :(. 
  Like other's suggested, maybe debug info is getting compiled in due to a 
 -g switch. 
 
 The file size still may end up being several megabytes, though, even without 
 the debug info.  This is more of an annoyance, than a hindrance. DWT has 
 a lot to offer; so most people end up coping with the size issue, especially 
 if they know they can use something like upx to squeeze things tight.
 
 I can't exactly remember what the cause of this is, but I think it has
something 
 to do with scads of "hidden" D symbols (moduleinfo?) produced by the D
compiler 
 for projects that have a combination of (1) tons of modules and (2) many 
 interdependencies amongst modules such that even a small project ends up 
 linking in ALL (or nearly so) classes from the framework.  This,
unfortunately, 
 is one of DWT's weaknesses.  I wish the language could help DWT by fixing 
 that, but I don't know if that is possible.  Other alternatives that might 
 help reduce the problem (I think) is integrating multiple modules into one 
 file...but that tends to hinder the whole idea of organization and namespace 
 clarity. If DWT were to do this, it would also break import compatibility 
 with SWT.  There are a few reasons why this approach is not desirable.
 
 But I hear you.  I really don't like unnecessary bloat either.  It would 
 be great if we had some super smart tools that could pair things down a bit.
 
 -JJR
 


I use dsss 0.75 to build static dwt-win library.
use dmd + gnu make to build binary.

It's small binary size. only issue is it takes more times to build a static
library.



-- 
yidabu <yidabu.spam gmail.com>
http://www.dsource.org/projects/dwin

D ÓïÑÔ-ÖÐÎÄ(D Chinese):
http://www.d-programming-language-china.org/
http://bbs.d-programming-language-china.org/
http://dwin.d-programming-language-china.org/
http://scite4d.d-programming-language-china.org/



 Nov 14 2008