The new DWT2
Now there is the new hg repository for DWT2. DWT2 is like dwt-win/linux/addons, but the folders are organized in the original directory structure of the Eclipse sources. This also means the packages are again like the original. DWT.CENTER = SWT.CENTER import dwt.widgets.Button; = import org.eclipse.swt.widgets.Button; This makes future porting of more files and versions much more easier. I started to make dwt2 compilable also for D2+Phobos. Support for D1+Tango will certainly stay. The repositories dwt-win/linux/addons/samples will stay and i will support them with bug fixes for a while. But I plan to do my future work in DWT2. Get it with Mercurial (hg) Version Control software: First get: hg clone http://hg.dsource.org/projects/dwt2 To get later changes from the server hg pull -u To build you need Rake, that is the Ruby make tool and is part of a standard Ruby installation. Also DMD needs to be in the path environment variable.
Re: The new DWT2
I'll be trying it out for dmd 2.. how far along is it at the moment?
Re: The new DWT2
Saaa schrieb: I'll be trying it out for dmd 2.. how far along is it at the moment? At the moment the refactoring is complete for D1+Tango. The 'base' tree compiles also for D2+Tango and i am working on the swt tree. But compile means really just compile. There is implementation work needed for Phobos. Please see also my posting: DWT2 D2+Phobos help needed
Re: The new DWT2
Frank Benoit wrote: Now there is the new hg repository for DWT2. DWT2 is like dwt-win/linux/addons, but the folders are organized in the original directory structure of the Eclipse sources. This also means the packages are again like the original. DWT.CENTER = SWT.CENTER import dwt.widgets.Button; = import org.eclipse.swt.widgets.Button; Wow, that's like twelve extra characters. I did want to try this out, but I already have gtkd, and that lets me just import gtk.Button. It shouldn't be too hard to write a script that would generate files of the type: module dwt.Button; public import org.eclipse.swt.widgets.Button;
Re: The new DWT2
Christopher Wright pisze: Wow, that's like twelve extra characters. I did want to try this out, but I already have gtkd, and that lets me just import gtk.Button. It shouldn't be too hard to write a script that would generate files of the type: module dwt.Button; public import org.eclipse.swt.widgets.Button; But SWT re-brand seems to be the better choice after all. I use Descent so I even don't type 1 character. Cheers
Re: The new DWT2
torhu wrote: On 21.03.2009 14:08, Christopher Wright wrote: Frank Benoit wrote: Now there is the new hg repository for DWT2. DWT2 is like dwt-win/linux/addons, but the folders are organized in the original directory structure of the Eclipse sources. This also means the packages are again like the original. DWT.CENTER = SWT.CENTER import dwt.widgets.Button; = import org.eclipse.swt.widgets.Button; Wow, that's like twelve extra characters. I did want to try this out, but I already have gtkd, and that lets me just import gtk.Button. It's a bit annoying, but seems like the right thing to do. I'll probably just type it once for each file, then use my editor's 'duplicate line' feature for the rest. That's what I've been doing already anyway. It's well motivated from a development standpoint. I don't see what it contributes, otherwise.
Re: Cristian Vlasceanu and D for the .NET platform
Using ArraySegment's under the hood is kind of is what I am doing now; one interesting edge case is when you want to call functions written in other .NET languages (one main idea behind this project is to allow interoperability between D and other languages, and leverage existing frameworks rather than reinvent the wheel). If you pass a slice to a foreign function that mutates elements in the array, it will not work as expected, because non-D code has no knowledge of slices. The work-around is to construct a temporary array out of the slice, but any changes that the called function makes to that temp array will be lost. This can be remedied by having the compiler generate post-call code that commits the changes back into the original array. It may work but is not efficient. Currently I content myself with just issuing a compiler warning / error when such a situation is detected. Cheers, Cristian BCS a...@pathlink.com wrote in message news:78ccfa2d3bc0a8cb6ed48908f...@news.digitalmars.com... Reply to Walter, http://www.reddit.com/r/d_language/comments/838lf/cristian_vlasceanu_a nd_d_for_the_net_platform/ His comments on array slicing are interesting. Seems to me the solution should be to have *all* dynamic arrays be ArraySegment as all dynamic arrays under DMD are a slices of the full memory space.
Re: Descent 0.5.4 released
Had a few problems with descent and PATH. Maybe it was something else but could it maybe be that you need to logout for eclipse to see changes in the PATH? Yes, probably. I'm not sure. I mean log out of XP. Because normally you only need to restart the program. A well, it works now. I'm happy again :D Well things seem to be working now but I miss poseidons syntax colourscheme. Is it possible to have different colours per keyword(group)? What's a keyword group? You can change the colors, but you'd change all of the keywords to another color (except return: you can color returns with a different color, useful to see all exit paths of a function). Poseidon has 7 (custom) groups of keywords which have different colours. eg. import=orange, static=green, void=blue, this=purple To me it makes source much easier to navigate.
DWT2 Windows building error
On Sat, 21 Mar 2009 09:57:32 +0100 Frank Benoit keinfarb...@googlemail.com wrote: Now there is the new hg repository for DWT2. DWT2 is like dwt-win/linux/addons, but the folders are organized in the original directory structure of the Eclipse sources. This also means the packages are again like the original. DWT.CENTER = SWT.CENTER import dwt.widgets.Button; = import org.eclipse.swt.widgets.Button; This makes future porting of more files and versions much more easier. I started to make dwt2 compilable also for D2+Phobos. Support for D1+Tango will certainly stay. The repositories dwt-win/linux/addons/samples will stay and i will support them with bug fixes for a while. But I plan to do my future work in DWT2. Get it with Mercurial (hg) Version Control software: First get: hg clone http://hg.dsource.org/projects/dwt2 To get later changes from the server hg pull -u To build you need Rake, that is the Ruby make tool and is part of a standard Ruby installation. Also DMD needs to be in the path environment variable. Rake building error: ...dwt2Rake base --trace (in .../dwt2) ** Invoke base (first_time) ** Execute base Building base/src dmd @...dwt2\rsp ...dwt2\base\src\java\lang\wrappers.d(15): Error: identifier 'equals_t ' is not defined ...dwt2\base\src\java\lang\wrappers.d(15): Error: equals_t is used as a type ...dwt2\base\src\java\lang\wrappers.d(15): function java.lang.wrappers .ArrayWrapperT!(byte).ArrayWrapperT.opEquals of type void(Object o) overrides bu t is not covariant with object.Object.opEquals of type int(Object o) ...dwt2\base\src\java\lang\wrappers.d(15): function java.lang.wrappers .ArrayWrapperT!(byte).ArrayWrapperT.opEquals does not override any function ...dwt2\base\src\java\lang\wrappers.d(69): template instance java.lang .wrappers.ArrayWrapperT!(byte) error instantiating rake aborted! compile error .../dwt2/rakefile:83:in `block (2 levels) in buildTree' ...Ruby/lib/ruby/1.9.1/rake.rb:981:in `call' ...Ruby/lib/ruby/1.9.1/rake.rb:981:in `sh' ...Ruby/lib/ruby/1.9.1/rake.rb:1065:in `sh' .../dwt2/rakefile:75:in `block in buildTree' .../dwt2/rakefile:69:in `chdir' .../dwt2/rakefile:69:in `buildTree' .../dwt2/rakefile:116:in `block in top (required)' ...Ruby/lib/ruby/1.9.1/rake.rb:613:in `call' ...Ruby/lib/ruby/1.9.1/rake.rb:613:in `block in execute' ...Ruby/lib/ruby/1.9.1/rake.rb:608:in `each' ...Ruby/lib/ruby/1.9.1/rake.rb:608:in `execute' ...Ruby/lib/ruby/1.9.1/rake.rb:574:in `block in invoke_with_call_chain ' ...Ruby/lib/ruby/1.9.1/monitor.rb:190:in `mon_synchronize' ...Ruby/lib/ruby/1.9.1/rake.rb:567:in `invoke_with_call_chain' ...Ruby/lib/ruby/1.9.1/rake.rb:560:in `invoke' ...Ruby/lib/ruby/1.9.1/rake.rb:2012:in `invoke_task' ...Ruby/lib/ruby/1.9.1/rake.rb:1990:in `block (2 levels) in top_level' ...Ruby/lib/ruby/1.9.1/rake.rb:1990:in `each' ...Ruby/lib/ruby/1.9.1/rake.rb:1990:in `block in top_level' ...Ruby/lib/ruby/1.9.1/rake.rb:2029:in `standard_exception_handling' ...Ruby/lib/ruby/1.9.1/rake.rb:1984:in `top_level' ...Ruby/lib/ruby/1.9.1/rake.rb:1963:in `block in run' ...Ruby/lib/ruby/1.9.1/rake.rb:2029:in `standard_exception_handling' ...Ruby/lib/ruby/1.9.1/rake.rb:1960:in `run' ...Ruby/bin/rake.bat:39:in `main' \src\dwt2Rake swt (in /src/dwt2) Building org.eclipse.swt.win32.win32.x86/src src\dwt2\org.eclipse.swt.win32.win32.x86\src\org\eclipse\swt\internal\C ompatibility.d(15): module File cannot read file 'java\io\File.d' rake aborted! compile error /dwt2/rakefile:83:in `block (2 levels) in buildTree' (See full trace by running task with --trace) my environment: Ruby Windows 1.91, Rake 0.83 Tango 0.99.7, Revision:4052, last changed date:2008-10-30 DMD 1.037 -- yidabu dyuyan.s...@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/
Re: The new DWT2
Christopher Wright schrieb: It's well motivated from a development standpoint. I don't see what it contributes, otherwise. there are existing naming conflicts of packages. org.eclipse.swt = dwt that was the start. Well then, rename all other swt to dwt also. So we have SWT = DWT SWTError = DWTError SWTException = DWTException SWTEventObject = DWTEventObject SWTEventListener = DWTEventListener then there are the packages from jface. Oh the first problem. org.eclipse.jface where to map those. Ok, have all the future packages from org.eclipse in dwtx, dwtx to be an abbreviation for org.eclipse org.eclipse.jface = dwtx.jface ... Oh, oh, now there is org.eclipse.osgi and org.osgi, now it gets a bit ugly. You see, where this is going to? All those renaming produce work in comparing versions and updates. A porting project like this needs lots of comparing and merging. It produces work for me, the developer. And I think my time is the most valuable resource the dwt project has. And really, I see not what those renaming contribute. Instead, when the original namings are used, examples and snippets can be used without or less change, that is a contribute for the user.
Re: DWT2 Windows building error
yidabu schrieb: Rake building error: dwt2Rake base --trace (in .../dwt2) ** Invoke base (first_time) ** Execute base Building base/src dmd @...dwt2\rsp dwt2\base\src\java\lang\wrappers.d(15): Error: identifier 'equals_t ' is not defined dwt2\base\src\java\lang\wrappers.d(15): Error: equals_t is used as a type ... Ruby Windows 1.91, Rake 0.83 Tango 0.99.7, Revision:4052, last changed date:2008-10-30 DMD 1.037 for dwt2 i use the tango 0.99.8 ( see svn tags/releases/0.99.8), there the type equals_t is defined in object.di. For dmd i use 1.041.
Re: Library for Linear Algebra?
Trass3r wrote: BCS schrieb: http://www.dsource.org/projects/mathextra This project contains BLADE, I didn't test it myself cause the author stated on Wed Oct 17, 2007 that there are still some fairly large issues to work out and there haven't been any updates to it since May 2008. I abandoned it largely because array operations got into the language; since then I've been working on getting the low-level math language stuff working. Don't worry, I haven't gone away! http://www.dsource.org/projects/lyla This seems to be something I should look further into. Though it is abandoned as well :( That's a real pity, having a good scientific computation library is crucial for D being used at universities. You know, Matlab is fine for writing clean, intuitive code, but when it comes to real performance requirements it totally sucks (damn Java ;) )
Re: new D2.0 + C++ language
Christopher Wright wrote: I was pulling numbers out of my ass. That's what I assumed. I'm a game developer. I use GC. 0.1 seconds out of every ten is a small amount to pay for the benefits of garbage collection in most situations. GC is useless for resource management. RAII solves the resource management problem, in C++ and D2. GC is a performance optimization on top of that. If the GC isn't faster than simple reference counting, then it serves no purpose, because you could use RAII with reference counting for the same effect. (No, I don't consider circular references a problem worth discussing.) -- Rainer Deyke - rain...@eldwood.com
Re: Response files
Walter Bright Wrote: Frank Benoit wrote: DMD 1.041 on windows does support response files, that is a file containing arguments. On Linux dmd does not understand that. The windows response files date back to the problem DOS/Windows had with only a very short command line length was allowed. So the arguments were put into a file instead. It's probably a good idea to do it for Linux, too. Ick. Why? Command files are hacks for Window's shortcomings. Why spread such hacks across all platforms? The linux command line is already well adapted to handle this kind of thing.
Re: eliminate writeln et comp?
Christopher Wright wrote: Daniel Keep wrote: When was the last time you had to put this in your GCC-compiled programs? Portions of this program Copyright (C) Free Software Foundation. Uses glibc. Executable code resulting from compilation is not a work derived from GCC. glibc is extremely difficult to link statically and is distributed under the LGPL, so no copyright notice is necessary. If dmd had good support for dynamic linking, this wouldn't be nearly as much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it can't be applied to the runtime. I think you're missing my point. I'm saying that a standard library shouldn't require you to insert legal disclaimers or attribution notices into your program or its documentation. A standard library should be be as invisible as possible in this regard. -- Daniel
Re: new D2.0 + C++ language
Weed пишет: Hi! I want to offer the dialect of the language D2.0, suitable for use where are now used C/C++. Main goal of this is making language like D, but corresponding zero-overhead principle like C++: at least to something like this idea? )
Re: Response files
Jason House schrieb: Walter Bright Wrote: Frank Benoit wrote: DMD 1.041 on windows does support response files, that is a file containing arguments. On Linux dmd does not understand that. The windows response files date back to the problem DOS/Windows had with only a very short command line length was allowed. So the arguments were put into a file instead. It's probably a good idea to do it for Linux, too. Ick. Why? Command files are hacks for Window's shortcomings. Why spread such hacks across all platforms? The linux command line is already well adapted to handle this kind of thing. Because, imagine you set up a build process for your application. Why should i have to care about that difference in my 'makefile', 'rakefile', ... whatever ?
Re: new D2.0 + C++ language
Piotrek пишет: Weed pisze: Weed пишет: Hi! I want to offer the dialect of the language D2.0, suitable for use where are now used C/C++. Main goal of this is making language like D, but corresponding zero-overhead principle like C++: at least to something like this idea? ) The idea could be ok but have you written a compiler or specification? My experience in the creation of the compilers is reduced to half-read book Compilers: Principles, Techniques, and Tools. It was easier to write the differences from D, as fully to specification - I hoped that receive point to some fundamental problems, but there seems all to be good (excluding holy war about GC, of course) Or is it wishful thinking like let's make the language that's productive to the skies while faster than asm? ;) No. ) I'm not suggesting anything new, it is suggested that all the time-tested things.
Re: eliminate writeln et comp?
Daniel Keep wrote: Christopher Wright wrote: Daniel Keep wrote: When was the last time you had to put this in your GCC-compiled programs? Portions of this program Copyright (C) Free Software Foundation. Uses glibc. Executable code resulting from compilation is not a work derived from GCC. glibc is extremely difficult to link statically and is distributed under the LGPL, so no copyright notice is necessary. If dmd had good support for dynamic linking, this wouldn't be nearly as much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it can't be applied to the runtime. I think you're missing my point. I'm saying that a standard library shouldn't require you to insert legal disclaimers or attribution notices into your program or its documentation. A standard library should be be as invisible as possible in this regard. -- Daniel Right. It's invisible with glibc because you link to it dynamically, and because everyone installs it by default. Druntime has neither of these advantages.
Re: Response files
Jason House schrieb: Walter Bright Wrote: Frank Benoit wrote: DMD 1.041 on windows does support response files, that is a file containing arguments. On Linux dmd does not understand that. The windows response files date back to the problem DOS/Windows had with only a very short command line length was allowed. So the arguments were put into a file instead. It's probably a good idea to do it for Linux, too. Ick. Why? Command files are hacks for Window's shortcomings. Why spread such hacks across all platforms? The linux command line is already well adapted to handle this kind of thing. Even in cygwin, there seems to be a 32k limit on the command line. On Linux you can find out that limit with getconf ARG_MAX (=2097152 on my linux box) 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
Re: new D2.0 + C++ language
Piotrek: (of course there are bugs but when I write something in D I'm so glad I don't have to to do it in something else). D is surely not a puzzle language :-) http://prog21.dadgum.com/38.html Well, writing D templates in functional style and lot of string mixins is a puzzle (even if they are less puzzles than some things you have to do in Forth). AST macros too can become puzzles, but I think if well designed they can be more natural to use than the current templates string mixins. Bye, bearophile
Re: new D2.0 + C++ language
Rainer Deyke wrote: Christopher Wright wrote: I was pulling numbers out of my ass. That's what I assumed. I'm a game developer. I use GC. 0.1 seconds out of every ten is a small amount to pay for the benefits of garbage collection in most situations. GC is useless for resource management. RAII solves the resource management problem, in C++ and D2. GC is a performance optimization on top of that. If the GC isn't faster than simple reference counting, then it serves no purpose, because you could use RAII with reference counting for the same effect. (No, I don't consider circular references a problem worth discussing.) I believe Python is using reference counting with a garbage collector, with the collector intended to solve the circular reference problem, so apparently Guido van Rossum thinks it's a problem worth discussing. And my opinion of reference counting is, if it requires no programmer intervention, it's just another garbage collector. Reference counting would probably be a win overall if a reference count going to zero would only optionally trigger a collection -- you're eliminating the 'mark' out of 'mark and sweep'. Though I would still demand a full mark-and-sweep, just not as often. Nontrivial data structures nearly always have circular references.
Re: new D2.0 + C++ language
Weed wrote: Piotrek пишет: Weed pisze: Weed пишет: Hi! I want to offer the dialect of the language D2.0, suitable for use where are now used C/C++. Main goal of this is making language like D, but corresponding zero-overhead principle like C++: at least to something like this idea? ) The idea could be ok but have you written a compiler or specification? My experience in the creation of the compilers is reduced to half-read book Compilers: Principles, Techniques, and Tools. It was easier to write the differences from D, as fully to specification - I hoped that receive point to some fundamental problems, but there seems all to be good (excluding holy war about GC, of course) I inferred from your original post that you had written such a compiler. I think probably the first thing to do, if you are serious about this, is to choose one essential feature of your dialect and implement that. Then there will be something concrete to discuss. That isn't the normal modus operandi around here, but there doesn't seem to be much support for your suggestions. I think this might be less to do with your ideas and more that I can't really envision what you're talking about and how code would look with your dialect.
Returning a struct by reference
Hi there!
I'm quite new at D and I'm still just playing with it, but there is a thing
that I find currently missing. Sometimes, I'd like to be able to return a
struct by reference and not by value. For example, in the following example:
struct Position {
float x;
float y;
}
class Object {
private Position m_position;
public Position position() {
return m_position;
}
}
I'd like to be able to write things like this: myObject.position.x = 43 to
actually change the position of the object. But right now, since position is
a struct, it is returned by value and not by reference, and then the previous
instruction won't change the position of the object, but it will work on a copy
of the position field.
Here is the solutions that I can see to this problem:
- Returning a pointer to the position: public Position *position() { ... },
but I'd like to keep my code as free from pointers as possible.
- Make Position a class and not a struct. That could be a solution, but
then, when I'll do things like Position pos = object.position; pos.x = 43;,
it will effectively change the position of the object, which I wouldn't like
with this syntax.
Actually, I'd like to be able to do a thing like this:
public ref Position position() {
return m_position;
}
which would be the equivalent form to passing structs by reference in a
parameter.
Is there a way to do this in D?
Regards,
Simon
Re: [OT]new D2.0 + C++ language
bearophile pisze:
Piotrek:
(of course there are bugs but when I write something in D
I'm so glad I don't have to to do it in something else).
D is surely not a puzzle language :-)
http://prog21.dadgum.com/38.html
Haha, I found good discussion on reddit
http://www.reddit.com/r/programming/comments/7vnm0/puzzle_languages/
Just couple of nice citations:
J language expample:
meanf=: 1 : '(0.255.])@:.@(m (+/ % #)@,;.3 ])2'
boxf=: 1 : '(0.255.])@:.@((2 2$m) (+/ % #)@,;.3 ])2'
pc=: .:([: 2 0 1|: 256 256 256#:)
inter=: ( [: , 2(({. , (+/%#))\) )1
inter2=: ([: (@inter pc) |:)^:2
fit=: [: .`./ ,
fit1=: [: .`./ (,~ (,~ -))~
histogram=: : @ (#/.~) @ (i...@#@[ , I.)
Does it look like the Matrix?
And the the one made me laugh the most:
CSS is the puzzliest puzzle that I ever puzzled
Every one should try CSS :D
Cheers
Re: eliminate writeln et comp?
Christopher Wright wrote: Daniel Keep wrote: Christopher Wright wrote: Daniel Keep wrote: When was the last time you had to put this in your GCC-compiled programs? Portions of this program Copyright (C) Free Software Foundation. Uses glibc. Executable code resulting from compilation is not a work derived from GCC. glibc is extremely difficult to link statically and is distributed under the LGPL, so no copyright notice is necessary. If dmd had good support for dynamic linking, this wouldn't be nearly as much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it can't be applied to the runtime. I think you're missing my point. I'm saying that a standard library shouldn't require you to insert legal disclaimers or attribution notices into your program or its documentation. A standard library should be be as invisible as possible in this regard. -- Daniel Right. It's invisible with glibc because you link to it dynamically, and because everyone installs it by default. Druntime has neither of these advantages. I'm not talking about distribution of the actual library machine code, I'm talking about the LEGAL ISSUES. Tango's license apparently requires you to explicitly include attribution for Tango in your program. This means it's possible to naively compile Hello, World with Tango, distribute it and break the law. That glibc uses dynamic linking is immaterial: that there is no way to avoid the legal issues with Tango no matter what you do is the point I'm trying to make. -- Daniel
Re: Returning a struct by reference
Simon TRENY wrote:
Hi there!
I'm quite new at D and I'm still just playing with it, but there is a thing
that I find currently missing. Sometimes, I'd like to be able to return a
struct by reference and not by value. For example, in the following example:
struct Position {
float x;
float y;
}
class Object {
private Position m_position;
public Position position() {
return m_position;
}
}
I'd like to be able to write things like this: myObject.position.x = 43 to actually
change the position of the object. But right now, since position is a struct,
it is returned by value and not by reference, and then the previous instruction won't
change the position of the object, but it will work on a copy of the position field.
Here is the solutions that I can see to this problem:
- Returning a pointer to the position: public Position *position() { ... },
but I'd like to keep my code as free from pointers as possible.
- Make Position a class and not a struct. That could be a solution, but then, when
I'll do things like Position pos = object.position; pos.x = 43;, it will effectively
change the position of the object, which I wouldn't like with this syntax.
Actually, I'd like to be able to do a thing like this:
public ref Position position() {
return m_position;
}
which would be the equivalent form to passing structs by reference in a
parameter.
Is there a way to do this in D?
Yes. Make the variable public.
class Object {
Position position;
}
This code is even simpler than your's above. Incredible, isn't it?
Regards,
Simon
Re: Returning a struct by reference
Simon TRENY wrote: Ok, but then, what if I'd like to make the variable read-only? i.e. preventing the user from writing things like this: myObject.position = pos2; So... you're rejecting a solution on the basis that it prevents you from doing the exact opposite of what you want to do? *boggle* -- Daniel
Re: Returning a struct by reference
grauzone Wrote:
Simon TRENY wrote:
Hi there!
I'm quite new at D and I'm still just playing with it, but there is a thing
that I find currently missing. Sometimes, I'd like to be able to return a
struct by reference and not by value. For example, in the following example:
struct Position {
float x;
float y;
}
class Object {
private Position m_position;
public Position position() {
return m_position;
}
}
I'd like to be able to write things like this: myObject.position.x = 43 to
actually change the position of the object. But right now, since position
is a struct, it is returned by value and not by reference, and then the
previous instruction won't change the position of the object, but it will
work on a copy of the position field.
Here is the solutions that I can see to this problem:
- Returning a pointer to the position: public Position *position() { ...
}, but I'd like to keep my code as free from pointers as possible.
- Make Position a class and not a struct. That could be a solution, but
then, when I'll do things like Position pos = object.position; pos.x =
43;, it will effectively change the position of the object, which I
wouldn't like with this syntax.
Actually, I'd like to be able to do a thing like this:
public ref Position position() {
return m_position;
}
which would be the equivalent form to passing structs by reference in a
parameter.
Is there a way to do this in D?
Yes. Make the variable public.
class Object {
Position position;
}
This code is even simpler than your's above. Incredible, isn't it?
Ok, but then, what if I'd like to make the variable read-only? i.e.
preventing the user from writing things like this:
myObject.position = pos2;
Regards,
Simon
Re: Returning a struct by reference
Simon TRENY wrote:
grauzone Wrote:
Simon TRENY wrote:
Hi there!
I'm quite new at D and I'm still just playing with it, but there is a thing
that I find currently missing. Sometimes, I'd like to be able to return a
struct by reference and not by value. For example, in the following example:
struct Position {
float x;
float y;
}
class Object {
private Position m_position;
public Position position() {
return m_position;
}
}
I'd like to be able to write things like this: myObject.position.x = 43 to actually
change the position of the object. But right now, since position is a struct,
it is returned by value and not by reference, and then the previous instruction won't
change the position of the object, but it will work on a copy of the position field.
Here is the solutions that I can see to this problem:
- Returning a pointer to the position: public Position *position() { ... },
but I'd like to keep my code as free from pointers as possible.
- Make Position a class and not a struct. That could be a solution, but then, when
I'll do things like Position pos = object.position; pos.x = 43;, it will effectively
change the position of the object, which I wouldn't like with this syntax.
Actually, I'd like to be able to do a thing like this:
public ref Position position() {
return m_position;
}
which would be the equivalent form to passing structs by reference in a
parameter.
Is there a way to do this in D?
Yes. Make the variable public.
class Object {
Position position;
}
This code is even simpler than your's above. Incredible, isn't it?
Ok, but then, what if I'd like to make the variable read-only? i.e.
preventing the user from writing things like this:
myObject.position = pos2;
Then you write a getter that simply returns the field by value.
The D compiler will (hopefully) inline the getter function, so there
shouldn't be a disadvantage in performance.
Note: I think D2.0 wants to introduce ref-returns at some point in the
future.
Regards,
Simon
Re: Returning a struct by reference
Daniel Keep Wrote:
Simon TRENY wrote:
Ok, but then, what if I'd like to make the variable read-only? i.e.
preventing the user from writing things like this:
myObject.position = pos2;
So... you're rejecting a solution on the basis that it prevents you from
doing the exact opposite of what you want to do?
*boggle*
-- Daniel
Here is a complete example of what I'd like to achieve:
struct Position {
private float m_x;
private float m_y;
public float x() {
return m_x;
}
public void x(float x) {
m_x = x;
EmitSignal(changed);
}
public float y() {
return m_y;
}
public void y(float y) {
m_y = y;
EmitSignal(changed);
}
}
class Object {
private Position m_position;
public this() {
m_position.CallOnSignal(changed, onPositionChanged);
}
//This syntax is not working
public ref Position position() {
return m_position;
}
public void onPositionChanged() {
writeln(Position Changed!!);
}
}
With this fictional code, I could write things like:
object.position.x = 14; and the object will be aware that its position has
changed.
Making the position-variable public will lead the user to be able to do
things like this:
object.position = pos2; and then, the object won't be aware that its position
has changed. And this is a problem for me.
I hope it's clearer now
Re: Returning a struct by reference
grauzone Wrote:
Simon TRENY wrote:
grauzone Wrote:
Simon TRENY wrote:
Hi there!
I'm quite new at D and I'm still just playing with it, but there is a
thing that I find currently missing. Sometimes, I'd like to be able to
return a struct by reference and not by value. For example, in the
following example:
struct Position {
float x;
float y;
}
class Object {
private Position m_position;
public Position position() {
return m_position;
}
}
I'd like to be able to write things like this: myObject.position.x = 43
to actually change the position of the object. But right now, since
position is a struct, it is returned by value and not by reference, and
then the previous instruction won't change the position of the object,
but it will work on a copy of the position field.
Here is the solutions that I can see to this problem:
- Returning a pointer to the position: public Position *position() { ...
}, but I'd like to keep my code as free from pointers as possible.
- Make Position a class and not a struct. That could be a solution,
but then, when I'll do things like Position pos = object.position; pos.x
= 43;, it will effectively change the position of the object, which I
wouldn't like with this syntax.
Actually, I'd like to be able to do a thing like this:
public ref Position position() {
return m_position;
}
which would be the equivalent form to passing structs by reference in a
parameter.
Is there a way to do this in D?
Yes. Make the variable public.
class Object {
Position position;
}
This code is even simpler than your's above. Incredible, isn't it?
Ok, but then, what if I'd like to make the variable read-only? i.e.
preventing the user from writing things like this:
myObject.position = pos2;
Then you write a getter that simply returns the field by value.
The D compiler will (hopefully) inline the getter function, so there
shouldn't be a disadvantage in performance.
If I add a getter-property that returns the field by value, the following
instruction object.position.x = 12; won't modify the position of the object,
but will only modify the returned copy of the position, right?
That's actually why I'd like to have a getter that returns the field by
reference and not by value.
Note: I think D2.0 wants to introduce ref-returns at some point in the
future.
Regards,
Simon
Re: [OT]new D2.0 + C++ language
Piotrek:
Haha, I found good discussion on reddit
On the other hand, D too for me becomes a puzzle language when I use many
string mixins or templates in functional-style. D macros will possibly improve
that situation some.
J language expample:
K language seems worse to me, this is a full raytracer that saves in pgm (in
C++ it's about 120 lines of code written in normal style):
http://www.nsl.com/k/ray/ray.k
U:{x%_sqrt x _dot x}
S:{[r;s]:[0d:_sqr[s 1]+_sqr[b:v _dot r 1]-v _dot v:s[0]-*r;0i;0t:b+e:_sqrt
d;0i;0u:b-e;u;t]}
I:{[r;h;o]:[~4:*o;:[~S[r;*o]*h;h;h _f[r]/o 1];~h[0]l:S[r]o;h;(l;U
r[0]-o[0]-l*r 1)]}
T:{[r;o;d;z;l]:[0i=*h:I[r;z]o;0.;~0g:h[1]_dot l;0.;0i=*I[(r[0]+(r[1]**h)+d*h
1;-l);z]o;-g;0.]}
N:{[n;o;i]0{x+T[(0 0 -4.;U(i+(y%4)-n%2),n);o;_sqrt 2^-42;0i,,3#0.]U -1 -3
2.}/+4_vs!16}
R:{[k;n]P5\n,(5:n,n),\n255\n,_ci _.5+15.9375*N[n*1.;C[k;0 -1 0.]1.]'+|@[n
_vs!n*n;0;|:]}
C:{[k;c;r]:[k=1;(c;r);((c;r*3);(,(c;r)),C[k-1;;r%2]'+c+-3 3[2_vs 2 3 6
7]*r%_sqrt 12)]}
\t q:R[3]32
temp.pgm6:q
\C:\\Program Files\\IrfanView\\i_view32.exe temp.pgm
APL-like languages are a dead-end...
Bye,
bearophile
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: Returning a struct by reference
Sat, 21 Mar 2009 09:55:13 -0400, Simon TRENY wrote:
//This syntax is not working
public ref Position position() {
return m_position;
}
D2 supports this.
D1 won't, ever. I think.
Re: Returning a struct by reference
Simon TRENY wrote:
Daniel Keep Wrote:
Simon TRENY wrote:
Ok, but then, what if I'd like to make the variable read-only? i.e.
preventing the user from writing things like this:
myObject.position = pos2;
So... you're rejecting a solution on the basis that it prevents you from
doing the exact opposite of what you want to do?
*boggle*
-- Daniel
Here is a complete example of what I'd like to achieve:
struct Position {
private float m_x;
private float m_y;
public float x() {
return m_x;
}
public void x(float x) {
m_x = x;
EmitSignal(changed);
}
public float y() {
return m_y;
}
public void y(float y) {
m_y = y;
EmitSignal(changed);
}
}
class Object {
private Position m_position;
public this() {
m_position.CallOnSignal(changed, onPositionChanged);
}
//This syntax is not working
public ref Position position() {
return m_position;
}
public void onPositionChanged() {
writeln(Position Changed!!);
}
}
With this fictional code, I could write things like:
object.position.x = 14; and the object will be aware that its position has
changed.
Making the position-variable public will lead the user to be able to do
things like this:
object.position = pos2; and then, the object won't be aware that its position
has changed. And this is a problem for me.
But if position is returned as ref, this still could happen. The
returned value is still assignable, and because it's a ref, overwriting
it is like overwriting m_position directly. As far as I see, your
position()-getter just emulates a public field. Including overwriting by
assignment.
Now D2.0 has const. If position() would return a const object, this kind
of unwanted overwriting couldn't happen. This improves correctness,
because uncatched changes or changes to temporaries can't happen. But
then again, the setters in the Position struct wouldn't work, because
the struct is const (as far as I understand the const system). This
means returning the field as a const ref wouldn't help.
Also, how is this EmitSignal() working? What happens if you write:
Position p = object.position;
p.x = 14; //EmitSignal() calls what?
p is simply a bit-copy of the struct returned by the getter, and
EmitSignal() has no way to check if it's still supposed to notify class
Object. (All solutions I can come up with sound really hairy and hackish.)
Maybe you're better off with Position as a class instead of a struct.
Even when you use D2.0's const/opAssign/copy-ctor/post-blit/ref-return
features.
Looking forward to the replies pointing out that D2.0 actually allows to
implement exactly what you want, and how this is done.
I hope it's clearer now
Re: eliminate writeln et comp?
Daniel Keep wrote: I'm not talking about distribution of the actual library machine code, I'm talking about the LEGAL ISSUES. Tango's license apparently requires you to explicitly include attribution for Tango in your program. This means it's possible to naively compile Hello, World with Tango, distribute it and break the law. Sorry to use you as the source to enter the thread, Daniel. Tango DOES NOT IN ANY WAY require you to put attribution into your program. That is a choice you as a user would make entirely on your own by choosing to use Tango licensed under the BSD (which is quite possible because this license is better suited for use alongside the GPL). However, the AFL does not put such a restriction on your binaries, and (unless you use the GPL for your code) the AFL is the license most users should use. This is also noted on the license page (it was probably not clear enough, I hope it is now). http://dsource.org/projects/tango/wiki/LibraryLicense For current or prospective contributors; you are completely and entirely entitled to relicense your own code to whichever license you wish, however these should also include the AFL and BSD when used in Tango. To change the license to something else at this point (for instance to Apache 2.0 only), would be a major undertaking, but something that we may consider to do at a later point. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango #D: larsivi Dancing the Tango
Please integrate build framework into the compiler
1. compiler know in what situation a file need to be recompiled Consider the file given the same header file, then the obj file of this will be required for linking, all other files import this file shouldn't require any recompilation in this case. If a file's header file changes, thus the interface changes, all files import this file should be recompiled. Compiler can emit building command like rebuild does. I would enjoy: dmd -buildingcommand abc.d responsefile dmd @responsefile I think we need to eliminate useless recompilation as much as we should with consideration of the growing d project size. 2. maintaining the build without compiler support costs
Re: Returning a struct by reference
Hello Simon,
If I add a getter-property that returns the field by value, the
following instruction object.position.x = 12; won't modify the
position of the object, but will only modify the returned copy of the
position, right?
That's actually why I'd like to have a getter that returns the field
by reference and not by value.
That is correct. Reference returns are on the todo list. For now this Hack
should work.
struct S { float x; float y; }
class C
{
S s
class C_S { void x(float v){ s.x=v; } void y(float v){ s.y=v; } }
C_S pos() { return new C_S(); }
}
Re: for in D versus C and C++
Sean Kelly wrote: == Quote from Walter Bright (newshou...@digitalmars.com)'s article Sean Kelly wrote: Sounds like HTTP/HTML. The best I've come up with so far for parsing that stuff is to have the lexer actually return tokens representing whitespace in some instances. It's totally ridiculous. When you see ad-hoc designs like that, it's obvious the designer has no experience with compilers. It's why every programmer should take a basic course in compiler design g. I very much agree. In fact, I'd go so far as to say that my compiler design course was the single most valuable CS course I took while in college. It's amazing how many problems I encounter have something to do with parsing or language translation. It's also amazing how many crappy parsers there are out there for these same tasks. Clearly, compiler design doesn't get as much attention as it should in undergrad CS. Sometimes I need to have a command line UI in a program. Such programs usually have 5 to 10 commands, with their parameters. One command per line. So far I have tested and split the command line with regular expressions, because using a parser generator has felt like shooting mosquitos with a shotgun. What would your strategy be?
Re: Response files
Jason House wrote: Ick. Why? Command files are hacks for Window's shortcomings. Why spread such hacks across all platforms? The linux command line is already well adapted to handle this kind of thing. gcc already supports it. There's apparently a demand for it.
Re: Response files
Frank Benoit wrote: Because, imagine you set up a build process for your application. Why should i have to care about that difference in my 'makefile', 'rakefile', ... whatever ? I use different makefiles for Windows, Linux, and OSX. It's easier than tearing my few strands of hair out trying to figure out how to remove system differences.
Re: for in D versus C and C++
Georg Wrede wrote: Sometimes I need to have a command line UI in a program. Such programs usually have 5 to 10 commands, with their parameters. One command per line. So far I have tested and split the command line with regular expressions, because using a parser generator has felt like shooting mosquitos with a shotgun. What would your strategy be? If it's 5 or 10, you can get by with ad-hoc. But if you find yourself repeatedly fixing bugs in the parsing, it's time to consider a more principled approach.
Re: for in D versus C and C++
Walter Bright wrote: Georg Wrede wrote: Sometimes I need to have a command line UI in a program. Such programs usually have 5 to 10 commands, with their parameters. One command per line. So far I have tested and split the command line with regular expressions, because using a parser generator has felt like shooting mosquitos with a shotgun. What would your strategy be? If it's 5 or 10, you can get by with ad-hoc. But if you find yourself repeatedly fixing bugs in the parsing, it's time to consider a more principled approach. I've found that once I created one lexer it could be re-used pretty easily for other languages too. And recursive descent parsers are trivial to write. It may be overkill for command-line parameters, but for anything remotely structured it's generally worth using.
Re: Response files
Walter Bright schrieb: Frank Benoit wrote: Because, imagine you set up a build process for your application. Why should i have to care about that difference in my 'makefile', 'rakefile', ... whatever ? I use different makefiles for Windows, Linux, and OSX. It's easier than tearing my few strands of hair out trying to figure out how to remove system differences. Right, this is because of such stuff. With dmd acting the same, it would be one step easier. On the other hand, separated build scripts are against DRY.
Re: Response files
Jason House jason.james.ho...@gmail.com wrote in message news:gq2dv9$2vn...@digitalmars.com... Walter Bright Wrote: Frank Benoit wrote: DMD 1.041 on windows does support response files, that is a file containing arguments. On Linux dmd does not understand that. The windows response files date back to the problem DOS/Windows had with only a very short command line length was allowed. So the arguments were put into a file instead. It's probably a good idea to do it for Linux, too. Ick. Why? Command files are hacks for Window's shortcomings. Why spread such hacks across all platforms? The linux command line is already well adapted to handle this kind of thing. Sometimes command lines get too long to keep typing (obviously). You *could* solve that with a shell/batch script, but then that would be specific to a particular shell/OS. As long as the app you're using is reasonably cross-platform, then a response file is completely shell/OS-agnostic. Response files may have originated as a workaround, but that doesn't mean they didn't turn out to have additional benefits.
Re: Response files
Walter Bright wrote: Frank Benoit wrote: Because, imagine you set up a build process for your application. Why should i have to care about that difference in my 'makefile', 'rakefile', ... whatever ? I use different makefiles for Windows, Linux, and OSX. It's easier than tearing my few strands of hair out trying to figure out how to remove system differences. ...NOT. Andrei
Re: eliminate writeln et comp?
On 2009-03-21 14:23:51 +0100, Daniel Keep daniel.keep.li...@gmail.com said: Christopher Wright wrote: Daniel Keep wrote: Christopher Wright wrote: Daniel Keep wrote: When was the last time you had to put this in your GCC-compiled programs? Portions of this program Copyright (C) Free Software Foundation. Uses glibc. Executable code resulting from compilation is not a work derived from GCC. glibc is extremely difficult to link statically and is distributed under the LGPL, so no copyright notice is necessary. If dmd had good support for dynamic linking, this wouldn't be nearly as much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it can't be applied to the runtime. I think you're missing my point. I'm saying that a standard library shouldn't require you to insert legal disclaimers or attribution notices into your program or its documentation. A standard library should be be as invisible as possible in this regard. -- Daniel Right. It's invisible with glibc because you link to it dynamically, and because everyone installs it by default. Druntime has neither of these advantages. I'm not talking about distribution of the actual library machine code, I'm talking about the LEGAL ISSUES. Tango's license apparently requires you to explicitly include attribution for Tango in your program. This means it's possible to naively compile Hello, World with Tango, distribute it and break the law. That glibc uses dynamic linking is immaterial: that there is no way to avoid the legal issues with Tango no matter what you do is the point I'm trying to make. -- Daniel This is bullshit, if you look at the header of c stdio.h you extremely likely to find exactly the same disclaimer (at least I did find it). If in your program you have an about and copyright, or you have documentation to it, then yes you should credit the inclusion of tango if you use the BSD license. If you want to avoid this then you should use the AFL license (which yes is incompatible with GPLv2). This if looking more and more like FUD. Fawzi
Re: Please integrate build framework into the compiler
I don't really understand what you mean. But if you want the compiler to scan for dependencies, I fully agree. I claim that we don't even need incremental compilation. It would be better if the compiler would scan for dependencies, and if a source file has changed, recompile the whole project in one go. This would be simple and efficient. Here are some arguments that speak for this approach: - A full compiler is the only piece of software that can build a correct/complete module dependency graph. This is because you need full semantic analysis to catch all import statements. For example, you can use a string mixin to generate import statements: mixin(import bla;). No naive dependency scanner would be able to detect this import. You need CTFE capabilities, which require almost a full compiler. (Actually, dsss uses the dmd frontend for dependency scanning.) - Speed. Incremental compilation is godawfully slow (10 times slower than to compile all files in one dmd invocation). You could pass all changed files to dmd at once, but this is broken and often causes linker errors (ask the dsss author for details lol). Recompiling the whole thing every time is faster. - Long dependency chains. Unlike in C/C++, you can't separate a module into interface and implementation. Compared to C++, it's as if a change to one .c file triggers recompilation of a _lot_ of other .c files. This makes incremental compilation really look useless. Unless you move modules into libraries and use them through .di files. I would even go so far to say, that dmd should automatically follow all imports and compile them in one go. This would be faster than having a separate responsefile step, because the source code needs to be analyzed only once. To prevent compilation of imported library headers, the compiler could provide a new include switch for library code. Modules inside library include paths wouldn't be compiled. Hell, maybe I'll even manage to come up with a compiler patch, to turn this into reality.
Re: Please integrate build framework into the compiler
Andrei Alexandrescu wrote:
grauzone wrote:
I don't really understand what you mean. But if you want the compiler
to scan for dependencies, I fully agree.
I claim that we don't even need incremental compilation. It would be
better if the compiler would scan for dependencies, and if a source
file has changed, recompile the whole project in one go. This would be
simple and efficient.
That's precisely what rdmd does.
This looks really good, but I couldn't get it to work. Am I doing
something wrong?
--- o.d:
module o;
import tango.io.Stdout;
void k() {
Stdout(foo).newline;
}
--- u.d:
module u;
import o;
void main() {
k();
}
$ rdmd u.d
/tmp/u-1000-20-49158160-A46C236CDE107E3B9F053881E4257C2D.o:(.data+0x38):
undefined reference to `_D1o12__ModuleInfoZ'
/tmp/u-1000-20-49158160-A46C236CDE107E3B9F053881E4257C2D.o: In function
`_Dmain':
u.d:(.text._Dmain+0x4): undefined reference to `_D1o1kFZv'
collect2: ld returned 1 exit status
--- errorlevel 1
rdmd: Couldn't compile or execute u.d.
$ dmd|grep Compiler
Digital Mars D Compiler v1.041
Andrei
Re: Please integrate build framework into the compiler
dsimcha wrote: == Quote from grauzone (n...@example.net)'s article I claim that we don't even need incremental compilation. It would be better if the compiler would scan for dependencies, and if a source file has changed, recompile the whole project in one go. This would be simple and efficient. I'm surprised that this could possibly be more efficient than incremental compilation, but I've never worked on a project large enough for compile times to be a major issue, so I've never really looked into this. Maybe incremental compilation could be faster, but dmd has a bug that forces tools like dsss/rebuild to use a slower method. Instead of invoking the compiler once to recompile all modules that depend from changed files, it has to start a new compiler process for each file. If incremental compilation were removed from the spec, meaning the compiler would always know about the whole program when compiling, I assume (correct me if I'm wrong) that would mean the following restrictions could be removed: 1. std.traits could offer a way to get a tuple of all derived classes, essentially the opposite of BaseTypeType. 2. Since DMD would know about all derived classes when compiling the base class, it would be feasible to allow templates to add virtual functions to classes. IMHO, this would be an absolute godsend, as it is currently a _huge_ limitation of templates. 3. For the same reason, methods calls to classes with no derived classes could be made directly instead of through the vtable. And you could do all kinds of interprocedural optimizations. Of course, these restrictions would still apply to libraries that use .di files. If incremental compilation is actually causing more problems than it solves anyhow, it would be great to get rid of it along with the annoying restrictions it creates. It seems Microsoft thought the same. C# goes without incremental compilation. But for now, D's build model is too similar to C/C++ as that you'd completely remove that ability.
Re: Please integrate build framework into the compiler
Hello grauzone, I would even go so far to say, that dmd should automatically follow all imports and compile them in one go. This would be faster than having a separate responsefile step, because the source code needs to be analyzed only once. To prevent compilation of imported library headers, the compiler could provide a new include switch for library code. Modules inside library include paths wouldn't be compiled. Adding that without a way to turn it off would kill D in some cases. I have a project where DMD uses up 30% of the available address space compiling one module. If I was forced to compile all modules at once, it might not work, end of story. That said, for many cases, I don't see a problem with having that feature available.
Re: Response files
Andrei Alexandrescu wrote: Walter Bright wrote: Frank Benoit wrote: Because, imagine you set up a build process for your application. Why should i have to care about that difference in my 'makefile', 'rakefile', ... whatever ? I use different makefiles for Windows, Linux, and OSX. It's easier than tearing my few strands of hair out trying to figure out how to remove system differences. ...NOT. Well... that's a bit D centric. :-) 'Round here we say maassa maan tavalla, which is probably something like When in Rome, do like the Romans do. Makefiles aren't just a C(++) thing. Unix has a culture of its own, Windows (I wouldn't say have a culture, but still) does it another way. So do we import the Unix way to Windows or the other way around? I'd go with the Romans in Rome. If there were a vote (outside of this NG!!) with D users, probably there are more folks who write in D /and/ in C or another language /on their own/ OS, than folks who write D apps (big enough to need makefiles) for both Windows and Linux.
Re: Please integrate build framework into the compiler
dsimcha wrote: 1. std.traits could offer a way to get a tuple of all derived classes, essentially the opposite of BaseTypeType. 2. Since DMD would know about all derived classes when compiling the base class, it would be feasible to allow templates to add virtual functions to classes. IMHO, this would be an absolute godsend, as it is currently a _huge_ limitation of templates. 3. For the same reason, methods calls to classes with no derived classes could be made directly instead of through the vtable. This is only if there is no dynamic linking.
Re: Please integrate build framework into the compiler
grauzone wrote: - Long dependency chains. Unlike in C/C++, you can't separate a module into interface and implementation. Compared to C++, it's as if a change to one .c file triggers recompilation of a _lot_ of other .c files. This makes incremental compilation really look useless. Unless you move modules into libraries and use them through .di files. You can use interfaces for this, though that is not always possible.
Re: Response files
Georg Wrede wrote: 'Round here we say maassa maan tavalla, which is probably something like When in Rome, do like the Romans do. Makefiles aren't just a C(++) thing. Unix has a culture of its own, Windows (I wouldn't say have a culture, but still) does it another way. So do we import the Unix way to Windows or the other way around? I'd go with the Romans in Rome. If there were a vote (outside of this NG!!) with D users, probably there are more folks who write in D /and/ in C or another language /on their own/ OS, than folks who write D apps (big enough to need makefiles) for both Windows and Linux. There is no standard for makefiles, I've run across dozens of different make programs that use different syntax and have different extensions. So, if you're going to have the same makefile across systems, you have to start with finding a make program that is fairly identical across those systems. Then you have the \ vs / problems. Some people assure me that Windows now works flawlessly with /, but that simply isn't so. I keep running into odd cases where it doesn't, so I don't use / on Windows. File name case sensitivity differs. The command line utilities called by makefiles differ in their names, switches, and how they work. .o on Linux, .obj on Windows. nothing on Linux, .exe on Windows. .a on Linux, .lib on Windows. It just goes on and on. You could try and parameterize all of it, but then the makefile becomes an inscrutable mess. You could have scripts generate makefiles, embed scripts in the makefiles, etc., but is this really worthwhile? It's just a makefile. I spend almost zero time on them. I like them simple even if that means they're more verbose.
Re: eliminate writeln et comp?
Lars Ivar Igesund wrote: Daniel Keep wrote: I'm not talking about distribution of the actual library machine code, I'm talking about the LEGAL ISSUES. Tango's license apparently requires you to explicitly include attribution for Tango in your program. This means it's possible to naively compile Hello, World with Tango, distribute it and break the law. Sorry to use you as the source to enter the thread, Daniel. Tango DOES NOT IN ANY WAY require you to put attribution into your program. That is a choice you as a user would make entirely on your own by choosing to use Tango licensed under the BSD (which is quite possible because this license is better suited for use alongside the GPL). However, the AFL does not put such a restriction on your binaries, and (unless you use the GPL for your code) the AFL is the license most users should use. This is also noted on the license page (it was probably not clear enough, I hope it is now). http://dsource.org/projects/tango/wiki/LibraryLicense For current or prospective contributors; you are completely and entirely entitled to relicense your own code to whichever license you wish, however these should also include the AFL and BSD when used in Tango. To change the license to something else at this point (for instance to Apache 2.0 only), would be a major undertaking, but something that we may consider to do at a later point. I read http://dsource.org/projects/tango/wiki/LibraryLicense. I am sorry to say, the page /still/ is not /clear/ enough. (As of Mar 22, 00:24 UTC.) The first bullets establish the intent, yes. But everything after that is actually... worthless. What the page should instead say, is /in terms understandable to/ *anybody*, explain what you have to do if you incorporate Tango in your software, or if you make another library that depends on Tango. Even if this includes awkward things (like having to have a constant string in the binary, mentioning Tango in the About menu item, or whatever else), it should be stated in layman-understandable terms. Currently, words like encumbrance, phrases like provides broad rights etc. only make the prospective reader run away in frustration. Just state what you want, in language that can be understood at First Reading, without asking your mother. Or both of you having an IQ of 170+. I'm not surprised that Don and others are getting second thoughts about contributing. A /clear/ stance to these issues makes everybody's (contributors, users, OS distributors, even app vendors) life easier. And, therefore, increases the popularity of Tango.
Re: Please integrate build framework into the compiler
grauzone wrote:
Andrei Alexandrescu wrote:
grauzone wrote:
I don't really understand what you mean. But if you want the compiler
to scan for dependencies, I fully agree.
I claim that we don't even need incremental compilation. It would be
better if the compiler would scan for dependencies, and if a source
file has changed, recompile the whole project in one go. This would
be simple and efficient.
That's precisely what rdmd does.
This looks really good, but I couldn't get it to work. Am I doing
something wrong?
--- o.d:
module o;
import tango.io.Stdout;
void k() {
Stdout(foo).newline;
}
--- u.d:
module u;
import o;
void main() {
k();
}
$ rdmd u.d
/tmp/u-1000-20-49158160-A46C236CDE107E3B9F053881E4257C2D.o:(.data+0x38):
undefined reference to `_D1o12__ModuleInfoZ'
/tmp/u-1000-20-49158160-A46C236CDE107E3B9F053881E4257C2D.o: In function
`_Dmain':
u.d:(.text._Dmain+0x4): undefined reference to `_D1o1kFZv'
collect2: ld returned 1 exit status
--- errorlevel 1
rdmd: Couldn't compile or execute u.d.
$ dmd|grep Compiler
Digital Mars D Compiler v1.041
Should work, but I tested only with D2. You may want to pass --chatty to
rdmd and see what commands it invokes.
Andrei
Re: new D2.0 + C++ language
Sat, 21 Mar 2009 00:59:22 -0600, Rainer Deyke wrote: GC is useless for resource management. I think this is an overstatement. It's only abstract write buffers where GC really doesn't work, like std.stream.BufferedFile. In any other resource management case I can think of GC works fine.
Re: Response files
Walter Bright wrote: Georg Wrede wrote: 'Round here we say maassa maan tavalla, which is probably something like When in Rome, do like the Romans do. Makefiles aren't just a C(++) thing. Unix has a culture of its own, Windows (I wouldn't say have a culture, but still) does it another way. So do we import the Unix way to Windows or the other way around? I'd go with the Romans in Rome. If there were a vote (outside of this NG!!) with D users, probably there are more folks who write in D /and/ in C or another language /on their own/ OS, than folks who write D apps (big enough to need makefiles) for both Windows and Linux. There is no standard for makefiles, I've run across dozens of different make programs that use different syntax and have different extensions. So, if you're going to have the same makefile across systems, you have to start with finding a make program that is fairly identical across those systems. Then you have the \ vs / problems. Some people assure me that Windows now works flawlessly with /, but that simply isn't so. I keep running into odd cases where it doesn't, so I don't use / on Windows. File name case sensitivity differs. The command line utilities called by makefiles differ in their names, switches, and how they work. dmd's flags are the same. Other than that, you only need to configure how files are deleted and how the C compiler is invoked. .o on Linux, .obj on Windows. OBJSUFFIX_win32 = .obj OBJSUFFIX_linux = .o ... OS = linux ... ... file$(OBJSUFFIX_$(OS)) ... nothing on Linux, .exe on Windows. See above. .a on Linux, .lib on Windows. See above. It just goes on and on. No. At some point it stops and you are gained by understanding where OS matters for your product and how. You could try and parameterize all of it, but then the makefile becomes an inscrutable mess. You could have scripts generate makefiles, embed scripts in the makefiles, etc., but is this really worthwhile? It's just a makefile. I spend almost zero time on them. I like them simple even if that means they're more verbose. This is because you don't really need to. I work on Phobos a fair amount, and I don't want to update four-odd places whenever I add a module. There is something to be said about once and only once. I've overhauled Phobos' makefile twice, and every time I've been gained by it. And again this brings a basic disagreement I have about making a hodge-podge of particular cases instead of searching the higher ground of proper abstraction. More code in makefiles doesn't necessarily improve things quite a lot. druntime has a lot of makefiles; apparently every single blessed thing has a makefile dedicated to it. But that complicates things without benefit. Andrei
Re: Please integrate build framework into the compiler
在 Sun, 22 Mar 2009 04:19:31 +0800，grauzone n...@example.net 写道: I don't really understand what you mean. But if you want the compiler to scan for dependencies, I fully agree. I claim that we don't even need incremental compilation. It would be better if the compiler would scan for dependencies, and if a source file has changed, recompile the whole project in one go. This would be simple and efficient. This may not be true. Consider the dwt lib case, once you tweaked a module very little(that means you do not modify any interface connects with outside modules and code that could possible affect modules in the same packages), the optimal way is dmd -c your_tweaked_module link all_obj That's much faster than regenerating all other object files. Yes, feed them all to DMD compiles really fast. Writing all object files to disk costs much time. And your impression of incremental compilation seems to be misguided by the rebuild and dsss system. Rebuild takes no advantage of di files, thus it have to recompile everytime even in the situation that the module based on all other di files unchanged. I posted several blocking header generation bugs in DMD and with fixes. Just so little change that dmd can generate almost all header files correctly. I tested tango, dwt, dwt-addons. Those projects are very big and some take advanced use of templates. So the header generation building strategy is really not far away. Little self-promotion here, and in case Walter misses some of them: http://d.puremagic.com/issues/show_bug.cgi?id=2744 http://d.puremagic.com/issues/show_bug.cgi?id=2745 http://d.puremagic.com/issues/show_bug.cgi?id=2747 http://d.puremagic.com/issues/show_bug.cgi?id=2748 http://d.puremagic.com/issues/show_bug.cgi?id=2751 In c++, a sophisticated makefile carefully build .h dependencies of .c files. Thus, once .h files are updated, then .c files which are based on them need to be recompile. This detection can be made by comparison of old .di files and new .di files by testing their equality.
Re: new D2.0 + C++ language
Sergey Gromov wrote: I think this is an overstatement. It's only abstract write buffers where GC really doesn't work, like std.stream.BufferedFile. In any other resource management case I can think of GC works fine. OpenGL objects (textures/shader programs/display lists). SDL surfaces. Hardware sound buffers. Mutex locks. File handles. Any object with a non-trivial destructor. Any object that contains or manages one of the above. Many of the above need to be released in a timely manner. For example, it is a serious error to free a SDL surface after closing the SDL video subsystem, and closing the SDL video subsystem is the only way to close the application window under SDL. Non-deterministic garbage collection cannot work. Others don't strictly need to be released immediately after use, but should still be released as soon as reasonably possible to prevent resource hogging. The GC triggers when the program is low on system memory, not when the program is low on texture memory. By my estimate, in my current project (rewritten in C++ after abandoning D due to its poor resource management), about half of the classes manage resources (directly or indirectly) that need to be released in a timely manner. The other 50% does not need RAII, but also wouldn't benefit from GC in any area other than performance. -- Rainer Deyke - rain...@eldwood.com
‘final’ variables: an alternative defini tion and its usefulness.
I propose to enhance the concept of ‘final’ to variables in order fill a
much needed place in the current type system. Final variables would be
transitive (a.k.a. deep), a super-type of non-final, assignable only at
declaration and apply only to references. Essentially, it would be a
references only version of ‘const’. Despite this similarity, it is
orthogonal to both the immutable-mutable-const and the shared-local-scope
(a.k.a. shared-heap-stack) type trees. The primary reasons for proposing
yet another type qualifier is bug 2095 and the lack of an equivalent of
‘const’ for the shared-local-scope storage type system.
Regarding Bug 2095
Bug 2095 occurs because a reference to a reference type is implicitly
convertible to a reference to a reference super-type. i.e.
class A {}
class B : A {}
B[] b = new B[10];
A[] a = b; // Practically, this is really important
a[0] = new A();// But allowing this causes bugs, since b has also
changed
Now, the implicit conversion of B[] to A[] is really important for subtype
and all functions operating on arrays of the super-type in order to avoid
casting left, right and center. However, if the implicitly converted
super-type array is assigned to, and then the original array is accessed,
random code execution can occur. Similarly, immutability can be
circumvented.
Final solves this problem by providing an alternative implicit conversion
of B[] to final A[]. E.g.
final A[] fa = b; // Still valid, and mutability/storage isn’t changed.
a[0] = new A(); // But now this is a compile time error.
Regarding shared-local-scope
The storage type system, consisting of shared, local and scope provides
many correctness and performance advantages. However, akin to mutable and
immutable there is no safe way to cast between them. This is an undesired
situation as it would require three separate variants of most functions.
The currently allowed implicit conversion between local and scope has
resulted in functions being prevented from returning explicit scope types.
However, a scope object can still escape, resulting in bugs.
Final references can not escape a scope as they can only be assigned at
declaration. Thus, final scope and final local may be implicitly casted
between themselves and either may be implicitly casted to final shared.
(The reason final shared may not be implicitly casted to final local or
final scope is that member variables will be protected by memory fences
and thus are accessed differently at the machine level)
Regarding Transitivity
Though bug 2095 would require arrays of array, etc to be implicitly
converted to final in a transitive manner, complete transitivity is not
required and represents a limitation on the actual objects. It is the need
to guarantee that final variables can not result in an object escaping its
scope that motivates full transitivity. In a situation where the storage
type of member variables and member returns is dictated by an object’s own
storage type, the implicit casting of final-storage-types results in the
member variable and return storage types to become unknown, necessitating
the implicit casting of them to final and thus transitivity.
Additional ‘final’ restrictions
Functions whose return type is final may result an object’s escape. This
can occur only when the returned object is final or scope. While returning
scope types is already illegal, but returning a final object may be needed
and logically valid. However, as a potentially dangerous operation
explicit casting should be required for final types. Another possible
escape could occur when final member variables are assigned during
construction and explicit casts should again be required.
Re: Response files
Andrei Alexandrescu wrote: More code in makefiles doesn't necessarily improve things quite a lot. druntime has a lot of makefiles; apparently every single blessed thing has a makefile dedicated to it. But that complicates things without benefit. In theory, each thing in druntime with a makefile is actually a standalone project, but since they're built together for the current distribution I agree it's overcomplicated. Regarding DM's make program, I'd be happy if it simply accepted rules with wildcards (ie. %.o : %.d). That would eliminate basically all the differences between the Win32 and Posix makefiles in druntime.
Re: Response files
Andrei Alexandrescu wrote: .o on Linux, .obj on Windows. OBJSUFFIX_win32 = .obj OBJSUFFIX_linux = .o ... OS = linux ... ... file$(OBJSUFFIX_$(OS)) ... I hadn't thought of using macros to generate macros. It's a good idea.
Re: Please integrate build framework into the compiler
My rdmd doesn't know --chatty. Probably the zip file for dmd 1.041 contains an outdated, buggy version. Where can I find the up-to-date source code? Another question, rdmd just calls dmd, right? How does it scan for dependencies, or is this step actually done by dmd itself?
Re: Please integrate build framework into the compiler
Little self-promotion here, and in case Walter misses some of them: http://d.puremagic.com/issues/show_bug.cgi?id=2744 http://d.puremagic.com/issues/show_bug.cgi?id=2745 http://d.puremagic.com/issues/show_bug.cgi?id=2747 http://d.puremagic.com/issues/show_bug.cgi?id=2748 http://d.puremagic.com/issues/show_bug.cgi?id=2751 If it's about bugs, it would (probably) be easier for Walter to fix that code generation bug, that forces dsss/rebuild to invoke a new dmd process to recompile each outdated file separately. This would bring a critical speedup for incremental compilation (from absolutely useless to relatively useful), and all impatient D users with middle sized source bases could be happy. In c++, a sophisticated makefile carefully build .h dependencies of .c files. Thus, once .h files are updated, then .c files which are based on them need to be recompile. This detection can be made by comparison of old .di files and new .di files by testing their equality. This sounds like a really nice idea, but it's also quite complex. For example, to guarantee correctness, the D compiler _always_ had to read the .di file when importing a module (and not the .d file directly). If it doesn't do that, it could accidentally use information that isn't included in the .di file (like code when doing inlining). This means you had to generate the .di files first. When doing this, you also had to deal with circular dependencies, which will bring extra headaches. And of course, you need to fix all those .di generation bugs. It's actually a bit scary that the compiler not only has to be able to parse D code, but also to output D source code again. And .di files are not even standardized. It's perhaps messy enough to deem it unrealistic. Still, nice idea.
Re: Response files
Walter Bright wrote: Andrei Alexandrescu wrote: .o on Linux, .obj on Windows. OBJSUFFIX_win32 = .obj OBJSUFFIX_linux = .o ... OS = linux ... ... file$(OBJSUFFIX_$(OS)) ... I hadn't thought of using macros to generate macros. It's a good idea. I confess I also hadn't until the third iteration of the Phobos makefile. Andrei
Re: Please integrate build framework into the compiler
grauzone wrote: My rdmd doesn't know --chatty. Probably the zip file for dmd 1.041 contains an outdated, buggy version. Where can I find the up-to-date source code? Hold off on that for now. Another question, rdmd just calls dmd, right? How does it scan for dependencies, or is this step actually done by dmd itself? rdmd invokes dmd -v to get deps. It's a interesting idea to add a compilation mode to rdmd that asks dmd to generate headers and diff them against the old headers. That way we can implement incremental rebuilds without changing the compiler. Andrei
Licences issues with d runtime
Deep in the 'eliminate writeln et comp?' thread there's been a recent discussion about the confusion over Tango licences. In particular, regarding the desire that the standard library shouldn't require binary 'copies' (a.k.a. every single executable compiled using it) from publishing/containing the library's licence. (And specifically, trying to understand the AFL) Anyways, I recently checked D2, and about half the druntime files are in BSD (which require publication) while the other half are in the zlib/libpng/Phobos licence (which doesn't). This is a serious legal obligation which isn't in the primary DMD licence or readme. Would it be possible for the licence in druntime to be unified? (If not, a more prominent notice would be appreciated) Thank you.
Re: The new DWT2
torhu wrote: On 21.03.2009 14:08, Christopher Wright wrote: Frank Benoit wrote: Now there is the new hg repository for DWT2. DWT2 is like dwt-win/linux/addons, but the folders are organized in the original directory structure of the Eclipse sources. This also means the packages are again like the original. DWT.CENTER = SWT.CENTER import dwt.widgets.Button; = import org.eclipse.swt.widgets.Button; Wow, that's like twelve extra characters. I did want to try this out, but I already have gtkd, and that lets me just import gtk.Button. It's a bit annoying, but seems like the right thing to do. I'll probably just type it once for each file, then use my editor's 'duplicate line' feature for the rest. That's what I've been doing already anyway. It's well motivated from a development standpoint. I don't see what it contributes, otherwise.
Re: DWT2 Windows building error
yidabu schrieb: Rake building error: dwt2Rake base --trace (in .../dwt2) ** Invoke base (first_time) ** Execute base Building base/src dmd @...dwt2\rsp dwt2\base\src\java\lang\wrappers.d(15): Error: identifier 'equals_t ' is not defined dwt2\base\src\java\lang\wrappers.d(15): Error: equals_t is used as a type ... Ruby Windows 1.91, Rake 0.83 Tango 0.99.7, Revision:4052, last changed date:2008-10-30 DMD 1.037 for dwt2 i use the tango 0.99.8 ( see svn tags/releases/0.99.8), there the type equals_t is defined in object.di. For dmd i use 1.041.
DSSS verbose mode?
Is there a verbose mode for DSSS to see which commands it actually executes? The dsss.conf is simply name=lyla [lyla] [test.d] I'm getting some linker errors that don't come up when compiling manually with dmd (using the lyla lib created by dsss, just passing it to dmd along with test.d). OPTLINK (R) for Win32 Release 8.00.1 Copyright (C) Digital Mars 1989-2004 All rights reserved. D:\dmd\windows\bin\..\lib\phobos.lib(gc) Offset 3A7F2H Record Type 0091 Error 1: Previous Definition Different : _D3std2gc12__ModuleInfoZ D:\dmd\windows\bin\..\lib\SNN.lib(fputwc) Offset 09794H Record Type 00C3 Error 1: Previous Definition Different : _putwc D:\dmd\windows\bin\..\lib\SNN.lib(fgetwc) Offset 09043H Record Type 00C3 Error 1: Previous Definition Different : _getwc
How to reduce compile times?
I'm using dsss (with dmd under Linux) to compile my project, and build/compile times are reaching unacceptable highs. What are some tips to speed up the build process? For example, I could imagine that heavy use of templates and CTFE slows the compiler down. Maybe string mixins with CTFE on the module level are most expensive: here, the compiler has to do heavy weight semantic analysis every time a module is imported from another module (maybe even recursively). But I don't really know; it depends too much on how the compiler works internally. Without some kind of build profiler, I have no clue what is actually causing slow downs. It's like groping in the dark! The only thing that comes near to this seems to be to insert a pragma(msg, blabla) at random points in your modules. Then you recompile the project and count how many times the message is outputted. Actually, the whole issue seems to boil down to reducing module dependencies. But then again, your main module recursively depends from _all_ used modules in your project. What I personally found useful in practice is to reduce the number of interdependent modules by separating them into interface and implementation modules, e.g. by using delegates or inheritance. Then you can hide the implementation from most modules by removing the static dependencies. But this only works in some cases, and is always inconvenient. PS: another thing that possibly would bring a speed gain would be to make dsss compile the whole project in one run, instead of invoking a new dmd process for each source file. How do I need to change the rebuild configuration to achieve this?
Re: DSSS verbose mode?
The closest thing that I know is dsss build -v
Re: DSSS verbose mode?
grauzone schrieb: The closest thing that I know is dsss build -v Thanks, that's what I needed. The cause seems to be that it uses dsss/include/d but links to the libraries in the dmd directory. test.d = test_lyla + D:\dmddwt\dsss\bin\rebuild.exe -Idsss_imports\ -I. -S.\ -ID:\dmddwt\dsss\include\d -SD:\dmddwt\dsss\lib\ -ID:\dmddwt\dsss\include\d -SD:\dmddwt\dsss\lib -oqdsss_objs\D -Slib -llcblas -llatlas test.d -oftest_lyla D:\dmd\windows\bin\..\lib\phobos.lib(gc) Offset 3A7F2H Record Type 0091 Error 1: Previous Definition Different : _D3std2gc12__ModuleInfoZ
Re: How to reduce compile times?
grauzone wrote: PS: another thing that possibly would bring a speed gain would be to make dsss compile the whole project in one run, instead of invoking a new dmd process for each source file. How do I need to change the rebuild configuration to achieve this? oneatatime = [yes|no] You want 'no'. This will occasionally produce issues with ModuleInfo not being defined with some dmd versions, I think. Or something like that.
Re: How to reduce compile times?
Christopher Wright wrote: grauzone wrote: PS: another thing that possibly would bring a speed gain would be to make dsss compile the whole project in one run, instead of invoking a new dmd process for each source file. How do I need to change the rebuild configuration to achieve this? oneatatime = [yes|no] You want 'no'. This will occasionally produce issues with ModuleInfo not being defined with some dmd versions, I think. Or something like that. Yes, this causes random linker errors. What I need is to make dsss completely recompile the project, even if only a single source file was modified. This way, no errors should occur, and it would still be faster than with oneatatime=yes. (Damn that crappy support for incremental compilation.)
Re: How to reduce compile times?
On 21.03.2009 19:50, grauzone wrote: Christopher Wright wrote: grauzone wrote: PS: another thing that possibly would bring a speed gain would be to make dsss compile the whole project in one run, instead of invoking a new dmd process for each source file. How do I need to change the rebuild configuration to achieve this? oneatatime = [yes|no] You want 'no'. This will occasionally produce issues with ModuleInfo not being defined with some dmd versions, I think. Or something like that. Yes, this causes random linker errors. Those errors shouldn't happen if you compile one file at a time, I believe. On the other hand, dsss' incremental compilation feature never seems to work for me. What I need is to make dsss completely recompile the project, even if only a single source file was modified. This way, no errors should occur, and it would still be faster than with oneatatime=yes. (Damn that crappy support for incremental compilation.) I use bud, which builds everything with a single run of dmd, but uses incremental compilation. If I get linker errors, I just run my cleanup script and try again. Or add -full to bud's command line.
Re: How to reduce compile times?
Jarrett Billingsley wrote: On Sat, Mar 21, 2009 at 2:50 PM, grauzone n...@example.net wrote: What I need is to make dsss completely recompile the project, even if only a single source file was modified. This way, no errors should occur, and it would still be faster than with oneatatime=yes. -full Sorry for being so helpless, but where do I add this to the rebuild configfile? Also, I noticed that dsss build -full seems to be the way to pass this flag on the command line. But the project is recompiled even when no file was modified at all. This is not good: it should only recompile if something has changed.
Re: How to reduce compile times?
I use bud, which builds everything with a single run of dmd, but uses incremental compilation. If I get linker errors, I just run my cleanup script and try again. Or add -full to bud's command line. In my case, this practically always causes linker errors. Of course I don't know why.
Re: How to reduce compile times?
On Sat, 21 Mar 2009 15:44:41 +0100, grauzone wrote: I'm using dsss (with dmd under Linux) to compile my project, and build/compile times are reaching unacceptable highs. out of curiosity, how much code do you actually have? im using D for something with ~12,000 lines of code right now, spread among 40 files or so, with a somewhat excessive use of CTFE and templates all over. a full rebuild takes about 5 seconds with incremental builds taking 1 or 2 seconds in most cases. i just wanted to know what excessively high means P.S. using dmd 1.036, rebuild 0.78, phobos, linux
Re: How to reduce compile times?
Brian wrote: On Sat, 21 Mar 2009 15:44:41 +0100, grauzone wrote: I'm using dsss (with dmd under Linux) to compile my project, and build/compile times are reaching unacceptable highs. out of curiosity, how much code do you actually have? im using D for something with ~12,000 lines of code right now, spread among 40 files or so, with a somewhat excessive use of CTFE and templates all over. a full rebuild takes about 5 seconds with incremental builds taking 1 or 2 seconds in most cases. i just wanted to know what excessively high means P.S. using dmd 1.036, rebuild 0.78, phobos, linux 65906 physical lines of code (+ some Tango .di imports + some small external libraries), maybe 200+ files, takes 1m10s to build when using normal dsss. With -full and oneatatime=no, compile time goes down to 6-7 seconds. It's not that template- and CTFE-heavy. Incremental builds can take relatively long (depending where the changed files are in the dependency tree), and it's really annoying.
Re: How to reduce compile times?
grauzone wrote: Jarrett Billingsley wrote: On Sat, Mar 21, 2009 at 2:50 PM, grauzone n...@example.net wrote: What I need is to make dsss completely recompile the project, even if only a single source file was modified. This way, no errors should occur, and it would still be faster than with oneatatime=yes. -full Sorry for being so helpless, but where do I add this to the rebuild configfile? Also, I noticed that dsss build -full seems to be the way to pass this flag on the command line. But the project is recompiled even when no file was modified at all. This is not good: it should only recompile if something has changed. http://svn.dsource.org/projects/arclib/trunk/arclib/arc/dsss.conf buildflags = -full
Re: What is the sate of LDC?
Georg Wrede: bearophile wrote: [...] despite LDC looks like the best bet for the close future of D. Would you care to elaborate? I know very little about compilers, so it's better for you to ask similar questions to LDC developers or other people. Most people around here seems to know much more than me about compilers of C-like languages. So my opinion isn't much reliable, but if you want to know it: I think LLVM backend is currently unfinished (no exceptions on Win) but it's being developed strongly enough, and eventually it will surely have exceptions. DMD back-end is very old, developed very little, and usually it doesn't produce much efficient executables, compared to other compilers (Despite LLVM produces code that most of the times is slower than code produced by GCC, LDC already usually produces code faster than DMD, and probably it will get better). LLVM is also open source. So to me it seems LDC has a future more open than DMD. (Eventually I'd like to see a project like dlang, a D clang-like front-end for LLVM written in D, replace LDC, but this will require a ton of work. So it's mostly a dream now). Bye, bearophile
[Issue 2752] std.xml does not encode CData correctly
http://d.puremagic.com/issues/show_bug.cgi?id=2752 --- Comment #1 from ben+dm...@bagi.us 2009-03-21 10:07 --- Created an attachment (id=293) -- (http://d.puremagic.com/issues/attachment.cgi?id=293action=view) Return correct representation of CData section --
[Issue 2753] New: Cannot declare pointer to function returning ref
http://d.puremagic.com/issues/show_bug.cgi?id=2753
Summary: Cannot declare pointer to function returning ref
Product: D
Version: 2.025
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: bugzi...@digitalmars.com
ReportedBy: jlqu...@optonline.net
ref int c() { static int a=2; return a; }
ref int function() d = c; // line 8
foo.d(8): variable foo.d only parameters or foreach declarations can be ref
Type inference, however, is able to figure it out:
ref int c() { static int a=2; return a; }
auto d = c; // whee
Correctly reporting the issue from bug 2735
--
[Issue 2753] Cannot declare pointer to function returning ref
http://d.puremagic.com/issues/show_bug.cgi?id=2753 s...@iname.com changed: What|Removed |Added CC||s...@iname.com Keywords||spec --- Comment #1 from s...@iname.com 2009-03-21 17:34 --- The problem seems to be an ambiguity in the grammar: is it ref (int function()) or (ref int) function()? Maybe we need a bracket notation for ref like we have for const and invariant. Note that, if we have both this and the notation proposed in bug 1961, ref and inout would no longer be synonyms. --
[Issue 2754] New: The error message regarding implicit conversion to shared doesn't mention shared in the message.
http://d.puremagic.com/issues/show_bug.cgi?id=2754
Summary: The error message regarding implicit conversion to
shared doesn't mention shared in the message.
Product: D
Version: 2.022
Platform: PC
OS/Version: Windows
Status: NEW
Keywords: diagnostic
Severity: trivial
Priority: P3
Component: DMD
AssignedTo: bugzi...@digitalmars.com
ReportedBy: sandf...@jhu.edu
Error: cannot implicitly convert expression (new A) of type hello.A to A
v.s. the corresponding immutable error:
Error: cannot implicitly convert expression (new A) of type hello.A to
immutable(A)
Test case:
class A {}
void foo( shared A y ) {}
void main() {
foo(new A());
}
P.S. D 2.026 isn't available yet as an option in bugzilla.
--
