Re: modulus redux
Andrei Alexandrescu Wrote:
[...]
The multiplicative expressions are multiplication (\ccbox{a * b}),
division (\ccbox{a / b}), and remainder (\ccbox{a \% b}). They
operate on numeric types only. The result type of either of these
operations is same as the type of \ccbox{true ? a : b}
(see~\S~\ref{sec:conditional-operator}).
Isn't (true?a:b) always (a)?
TomD
Re: minimal evaluation
downs Wrote: [...] .. Wait. Did I just read that right - when an argument is null, isNull returns *false*? What the hell? At least that is what he had written. Seems to be a case of double negation is still a negation, an idiom quite common here in Bavaria. Not in programming, though. :-) Ciao TomD
Re: minimal evaluation
Qian Xu Wrote:
Hi All,
Is minimal evaluation always enabled in D?
I want to write a function IsNull(), so that I can check the precondition as
follows:
 if (isNull(foo) ||
   isNull(foo.getBar) ||
   isNull(foo.getBar.getBar2)
 {
  return false;
 }
 // normal code goes here
If an argument is null, the IsNull() will return false. Internally it will
be logged to console as well.
Make it return true then. An or is true when it hits the first
true expression.
Ciao
TomD
Re: Link Problem
TomD Wrote: After a couple of miniutes googling around this seems to be a bug in ld. Some aritlcles from 2007 or so recommend to downgrade to binutils 2.15 from 2.16. *If* your installed binutils is 2.16, you may give it a try. Ciao Tom After a bit harder googling I found http://www.cygwin.com/ml/binutils/2007-09/msg00096.html ** On Wed, Sep 05, 2007 at 12:19:05PM -0500, Albert Chin wrote: [about references to local symbols in discarded sections causing a link error] Is the behavior in binutils-2.17+ correct? Well, the linker can't guarantee to fix up the reference to point to the proper location in the kept section. Just considering the linker in isolation, I think it warrants an error. However, I thought this gcc bug had been fixed long ago, but if this is occurring with 4.0.2, perhaps we ought to downgrade the error to a warning again. (I'm assuming that the reference was from C++ code rather than assembly, and that your .a was actually compiled with 4.0.2) If so, how do we work around this issue? Pass --noinhibit-exec to the linker. HTH, Ciao TomD
Re: Link Problem
After a couple of miniutes googling around this seems to be a bug in ld. Some aritlcles from 2007 or so recommend to downgrade to binutils 2.15 from 2.16. *If* your installed binutils is 2.16, you may give it a try. Ciao Tom
Re: Link Problem
davidl Wrote: [...] You're sure that's a linking problem? GDC only use DMD frontend, so if it's a linking problem it should be ld's. LD seems to behave absurdly that it expects to resolve symbols. e.g. a.o provides symbol c, and b.o needs symbol c you'd better feed ld with: b.o a.o not a.o b.o dmd also uses gcc (and hence ld) as linker, so if it is an ld problem, it'll stay. The behavior you mention above is only true for library files, AFAIK, not for objects. You should have all objects before the libraries, though. Ciao TomD
Re: Link Problem
Qian Xu Wrote:
[...]
I tried the following command
gdc -Wl,--start-group Foo.o Foo2.o Bar/Foo3.o Bar/Foo4.o -Wl,--end-group
-o main -Ltango/lib -lgtango
But it still does not work. The same problem.
The following is a dump of the actual error message
--
build_trunk_build_1926/build_componenttest.out-`.text._D5tango4util10collection4impl16AbstractIterator80__T16AbstractIteratorTC9timetable6common3src10controller6entity7Vehicle7VehicleZ16AbstractIterator9remainingMFZk'
referenced in section
`.text.__t24__D5tango4util10collection4impl16AbstractIterator80__T16AbstractIteratorTC9timetable6common3src10controller6entity7Vehicle7VehicleZ16AbstractIterator9remainingMFZk[__t24__D5tango4util10collection4impl16AbstractIterator80__T16AbstractIteratorTC9timetable6common3src10controller6entity7Vehicle7VehicleZ16AbstractIterator9remainingMFZk]'
of
build/boost/timetable/common/src/controller/importer/ImportVehicleController_1.o:
defined in discarded section
`.text._D5tango4util10collection4impl16AbstractIterator80__T16AbstractIteratorTC9timetable6common3src10controller6entity7Vehicle7VehicleZ16AbstractIterator9remainingMFZk[_D5tango4util10collection4impl16AbstractIterator80__T16AbstractIteratorTC9timetable6common3src10controller6entity7Vehicle7VehicleZ16AbstractIterator9remainingMFZk]'
of
build/boost/timetable/common/src/controller/importer/ImportVehicleController_1.o
build_trunk_build_1926/build_componenttest.out:collect2: ld returned 1 exit
status
--
As far as I can say from the error, ld discards a section. I just cannot
understand why.
The info file of ld says:
***
3.6.7 Output Section Discarding
---
The linker will not create output sections with no contents. This is
for convenience when referring to input sections that may or may not be
present in any of the input files. For example:
.foo : { *(.foo) }
will only create a `.foo' section in the output file if there is a
`.foo' section in at least one input file, and if the input sections
are not all empty. Other link script directives that allocate space in
an output section will also create the output section.
Somehow, section ._D5tango4util10collection4impl16AbstractIterator80
(tango.util.collection.impl.AbstractIterator timetable.commonSource...)
get discarded.
Is there anything weird with this thing, e.g. inlined but referenced
in an external modulue? Can you rebuild all without optimization?
Ciao
TomD
(PS: Thanks to Fawzi, I did not know the grouping command
of ld)
Re: State of Play
ValeriM Wrote: [...] No. It's not stable. Try to build last Tango and DWT releases with D1.041 and you will get the problems. But not because of D1.0. It is because of the Tango team introducing a couple of breaking changes. Frank is working on updating DWT (or has even fixed that already, not sure) That is the causes a lot of people ask such questions. And I too. Not because D1.0 dead-end. But because I can't understand what is stable toolset and how long it would be stable. D+Tango+DWT is a good example. Yeah, but that is life. At some point you need to change APIs, and then you need to revise the downstream libraries. That takes some time. This no question of dead-end. Ciao TomD
Re: Benchmark of try/catch
bearophile Wrote: [...] And I'd also like to know why using printf changes the situation so much. After a first glimpse with profiling the difference is that printf pulls in stdarg, whereas writfln doesn't. Which means we replace one oddity with another. Ciao Tom D.
Re: Response files
Frank Benoit Wrote: [...] This seems to be enough, however, 32k/64k are not. There is a related bug, because the dmd response file workaround is not working with 64k, see http://d.puremagic.com/issues/show_bug.cgi?id=2705 Just out of curiosity: With which kind of project do you hit this limit? Ciao Tom
Re: GUI Design (DWT) with XML
Bill Baxter Wrote: [...] I was hoping you might get some comments on this. Bad timing, together with Walter adding the backend sources :-) It seems to me a lot of people like the idea of XML files to configure a gui. I'm not a big fan of XML, so hard for me to get excited on that score. Also if I'm going to use a text-file gui description thing, I'm probably only going to use it because some GUI tool was able to spit it out for me automatically. If I have to write the text file, I don't see how it's all that much of an improvement over just writing the GUI code to begin with. Of course once you have the load/save of GUI layouts worked out, it's just a simple matter of making a GUI to create the layouts after that. You are perfectly right here. The whole concept was done with glade in mind. I like the idea of separating form and function. For me personally, using xemacs in XML mode is already GUI enough Other question I have is -- doesn't SWT already have something for creating GUI layouts? Hmm, nothing that Frank so far commented about. Ciao TomD
GUI Design (DWT) with XML
Hi, I have uploaded xwt to http://demmer.kilu.de/Software/xwt_20090305.zip This is an extensible library that parses the XML description of a GUI. It is based on DWT, the SWT port to D, and Tango. In theory, it should run unaltered on Win32 and Linux, and one day also on OSX. The basic idea is to wrap all widgets into a class that implements a configure method for each widget. During load of the XML tree, the widget tree is built in parallel. I have included a couple of examples, so you get the idea. Feedbackbug reports welcome. Ciao TomD
Re: exe file size
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: - #!/bin/bash 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
