Re: Followed all installation instructions, still no luck (OS X 10.5)
Denis Koroskin wrote: On Mon, 27 Apr 2009 08:24:38 +0400, Steve Johnson wrote: One thing to try is calling the compiler and explicitly passing -I/usr/src/phobos (or whatever directory object.d is in) to it. Looks like that fixed it! Do I need to keep dmd.conf in /usr/etc then? Perhaps some other path? It looks like dmd can't find dmd.conf and didn't use it at all. I'm not sure dmd is looking for it in /usr/etc. The correct thing to do would be to find a proper place for dmd.conf and stop passing -I switch directly. Put it in the same directory as dmd
DMD Mac installation instruction
The installation instructions for dmd mac, at http://www.digitalmars.com/d/1.0/dmd-osx.html, says to put dmd.conf in /etc but it seems that it doesn't work. I recommend changing that to: put the dmd.conf in the same directory as dmd.
Re: Rebuild [Descent]
Dalin Sade wrote:
Everytime I try to configure Descent (or Eclipse) to compile programs with "rebuild", I
always get an error message that pops up when I try to compile. "Variable ${project_loc}
references empty selection", same with ${resource_loc}. Help?
Follow this guide:
http://www.dsource.org/projects/descent/wiki/CompilingPrograms
Then open the file you want to compile and make sure it's the "active"
on, you probably have to make sure that the editor view is selected and
not the project view. Run -> External Tools -> Rebuild.
Re: std.string and std.algorithm: what to do?
Andrei Alexandrescu wrote: dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article I'm not sure what needs to be done about the combo string + algorithm. There's quite some overlap, and also functions that have the same name in both modules (e.g. find()), which forces you to disambiguate. Should std.algorithm automatically recognize strings and proceed accordingly, should it just consider them straight arrays and leave everything else to std.string (risky!), or refuse to handle strings? I like the idea of automatically specializing on strings, at least on the surface. It's less to remember for the programmer, less annoying naming collisions, and stuff "just works". You get your generic std.algorithm stuff when you need it and your more optimized/variable length character encoding stuff when you need it without having to explicitly specify which one you want. Cool! So then how do I rename find, ifind, rfind, and irfind in std.string? Andrei Like others I think the names should be: find -> indexOf rfind -> lastIndexOf but I think the declaration should look like this: size_t indexOf (string s, dchar d, size_t start = 0) perhaps an argument for case sensitive also: size_t indexOf (string s, dchar d, size_t start = 0, bool caseSensitive = true)
Re: OT: on IDEs and code writing on steroids
Daniel Keep wrote: BCS wrote: Hello Brad, My other problem with IDE's, such as eclipse, is that it's such an all or nothing investment. You can't really just use part of it. You must buy in to it's editor, it's interface with your SCM, it's scriptures of indentation style, etc. Trying to deviate from any of it is such a large pain that it's just not worth it -- more so as the team working on a project gets larger. For VS, you might have a point. However for D, I use Descent and I haven't found any of those to be a problem. Getting people to agree on how to set it up I expect would be a bigger problem. Actually, Descent isn't perfect, either. For example, it mandates that cases in a switch MUST be aligned with the braces. What's more fun is that you can't override it until AFTER it's corrected YOU. Just file a ticket. Oh, and how it indents multiline function calls is completely retarded. And every time I try to autocomplete a templated function call, it insists on inserting ALL of the template arguments, even when they're supposed to be derived. That's been fixed now: http://www.dsource.org/projects/descent/changeset/1344 Don't get me wrong, I quite like Descent. But as soon as you try to make a program "smart", you're going to start getting it wrong. -- Daniel
Re: OT: on IDEs and code writing on steroids
grauzone wrote: Oh, and how it indents multiline function calls is completely retarded. And every time I try to autocomplete a templated function call, it insists on inserting ALL of the template arguments, even when they're supposed to be derived. This is why I don't like IDEs. Plus, every time you type something, stuff BLINKS around, grabbing your attention, saying I'M SO ANNOYING PLEASE DISABLE ME AS A FEATURE. Like documentation tooltips, auto completion hints, or "intelligent" indentation. It's ridiculous. When I hit a key, I want the text editor insert that key. Not do random stuff. How do Eclipse user deal with it? Not look at the screen when typing? I do look at the screen because I WANT to use those features. I don't try to work around them I try to use them instead. If there's a feature I don't like I disable it, you just have to configure the application in the way you like it. An application can't be configured from the beginning to satisfy all peoples needs.
Re: foreach (x; a .. b) and foreach_reverse (x; a .. b) should be disallowed for floats
Steven Schveighoffer wrote: On Sun, 17 May 2009 20:28:24 -0400, Andrei Alexandrescu wrote: Consider: foreach (x; 1.0 .. 4.1) writeln(x); foreach_reverse (x; 1.0 .. 4.1) writeln(x); This sucks. foreach with interval for floating-point types should be disallowed. foreach_reverse sucks in its own right, while you're looking for stuff to get rid of, I think it can be done better. foreach(x; 4 .. 1 ) should do a reverse interval (and looks way more readable). foreach(x; array.reverse) should iterate in reverse. for classes, using a method called reverse should work fine: foreach(x; myclass.reverse) Having to implement opApplyReverse is rediculous, and having a keyword like foreach_reverse is rediculous. Reverse isn't the only interesting iteration pattern, so why focus a whole keyword and syntax on that? -Steve I agree with that, but how would you differ foreach(x; array.reverse) from the array.reverse that modifies the array?
Re: Introspection - how?
Vincent wrote:
Hello, guys!
I have a question related D's introspection. I try to solve serialization task
(implementing JSON protocol)
and stuck at very start: getting all class' fields with types, names and
values. Just test code:
Thread d;
foreach(mi; d.classinfo.getMembers(null))
13: writefln(mi.name);
test.d(13): Error: function object.MemberInfo.name () does not match parameter
types ()
test.d(13): Error: mi.name can only be called on a mutable object, not
const(MemberInfo)
I'm confused with such strange error: what is a problem with using MemberInfo?
I just try to GET info, not WRITE!
Anybody have idea how to get info about members? (see task above)
Thanks.
You can use tupleof for classes and structs which returns a tuple
containing all the fields of the class/struct. The following code will
print the type, name and value of every field in the struct. BTW you can
change private fields with tupleof. This is tested dmd v1.043 and Tango.
struct Struct
{
private int i = 3;
private char c = 'a';
}
Struct s;
foreach (i, t ; typeof(Struct.tupleof))
{
const len = Struct.stringof.length;
const fieldName = Struct.tupleof[i].stringof[1 + len + 2 .. $];
const typeName = typeof(Struct.tupleof[i]).stringof;
Stdout.formatln("type: {0}", typeName);
Stdout.formatln("name: {0}", fieldName);
Stdout.formatln("value: {0}", s.tupleof[i]);
Stdout().newline;
}
type: int
name: i
value: 3
type: char
name: c
value: a
Why is !() need with default template arguments
If I have a class like this:
class Class (T = int) {}
Then why can't I use it like this:
auto c = new C;
I have to do this:
auto c = new C!();
Re: OT: on IDEs and code writing on steroids
dsimcha wrote: == Quote from Ary Borenszweig (a...@esperanto.org.ar)'s article dsimcha escribió: == Quote from Christopher Wright (dhase...@gmail.com)'s article Nick Sabalausky wrote: "Andrei Alexandrescu" wrote in message news:gus0lu$1sm...@digitalmars.com... I've repeatedly failed to figure out the coolness of C#, and would appreciate a few pointers. Or references. Or delegates :o). Outside of this group, I think most of the people considering C# really cool are people who are unaware of D and are coming to C# from Java. What's "cool" about C# is that it's like a less-shitty version of Java (and *had* good tools, although the newer versions of VS are almost as much of a bloated unresponsive mess as Eclipse - Which come to think of it, makes me wonder - If Java has gotten so fast as many people claim, why is Eclipse still such a sluggish POS?). Compare C# to D though and most of the coolness fades, even though there are still a handful of things I think D could still learn from C# (but there's probably more than a handful that C# could learn from D). Generics and reflection. Generics just hide a lot of casts, usually, but that's still quite useful. And autoboxing is convenient, though not appropriate for D. What the heck do you need generics for when you have real templates? To me, generics seem like just a lame excuse for templates. Yesterday doob reported a bug in Descent saying "when you compile your project and it references a user library that has errors, when you click on the console to jump to the error, it doesn't work". I said to him: I never thought a user library could have errors! How did this happen to you? He replied: "I found a bug in a template in Tango". That's why generics doesn't suck: if there's something wrong in them, the compiler tells you in compile-time. In D, you get the errors only when instantiating that template. Generics might not be as powerful as templates, but once you write one that compiles, you know you will always be able to instantiate it. Yes, but there are two flaws in this argument: 1. If you are only using templates like generics, you simply use a unit test to see if it compiles. If you're not doing anything fancy and it compiles for one or two types, it will probably compile for everything that you would reasonably expect it to. I used tango.text.xml.Document with wchar and dchar as the template type and in tango.text.xml.PullParser there were some functions that took char[] instead of T[] as the argument. http://www.dsource.org/projects/tango/ticket/1663 2. If you're doing something fancier, like metaprogramming, you have to just face the fact that this is non-trivial, and couldn't be done with generics anyhow. 3. As Bearophile alluded to, templates are really a clever hack to give you the flexibility of a dynamic language with the performance and compile time checking of a static language. This is done by moving the dynamism to instantiation time. Therefore, whereas in a dynamic language you pay at runtime in terms of the "here be monsters, this code may not be being used as the author intended and tested it", with templates you pay at instantiation time. However, IMHO this is orders of magnitude better than not having that flexibility at all. I personally can't figure out how people accomplish anything in static languages w/o templates. It's just too inflexible.
Re: [OT] Shell scripting compatibility
On 7/5/09 6:36 AM, Nick Sabalausky wrote: "Adam D. Ruppe" wrote in message news:mailman.5.1246741099.14071.digitalmar...@puremagic.com... On Sat, Jul 04, 2009 at 04:50:22PM -0400, Nick Sabalausky wrote: Can /bin/bash safely be expected to exist on all non-Windows systems that can compile D? Or is there something better for that? Any common cross-platform-scripting gotcha's to be aware of? I know on FreeBSD it is often in /usr/local/bin/bash (if it is installed at all), so you can't really rely on it being at /bin/bash. I don't really have a solution to cover the differences though. I guess you could write simple, minimal scripts and just use /bin/sh for best cross platform luck. That may work just fine in my case. I'm just using a batch-file (win) and a shell script (non-win) to launch rebuild to compile the real cross-platform, umm "script", that's written in D. And even then, only for the cases where the included precompiled versions are insufficient, such as on a non-x86 or a mac (my only mac isn't current anymore. and it's completely dead.). So it is fairly trivial script. So sh is typically in that location then? I know Unix doesn't really have a way (at least to my knowledge) to handle a script needing a particular interpreter that could be in different places on different machines without requiring the user to make a symlink or something. But I don't really need perfect. Good enough is good enough here :) #!/usr/bin/env bash but that requires env, I don't know if that's any better.
Re: [OT] Shell scripting compatibility
On 7/4/09 10:50 PM, Nick Sabalausky wrote: Can /bin/bash safely be expected to exist on all non-Windows systems that can compile D? Or is there something better for that? Any common cross-platform-scripting gotcha's to be aware of? What to watch out for when writing portable shell scripts: http://www.linux.com/archive/articles/34658
C compatibility
I've read posts in several threads complaining about the C compatibility, the latest was the % operator. Other complains are that you can use the C syntax for pointers, arrays and function pointers. Also the "Case range statement" thread that complained (among other things) about fall through in switch statements. Why not the drop this C compatibility in general case but still allow the C compatibility in extern (C) blocks? /Jacob Carlborg
Re: Reddit: why aren't people using D?
On 7/23/09 1:27 AM, Andrei Alexandrescu wrote: Walter Bright wrote: http://www.reddit.com/r/programming/comments/93jh5/ask_proggit_the_d_programming_language_looks/ I noticed some people complain about installation difficulties, is there progress on the community project for writing installer for the three major OSs? Andrei Yes: http://www.dsource.org/projects/dmd-installer I'm still waiting for Walter to add the osx installer to the dmd download page.
Re: OS X Installer
On 7/23/09 12:32 PM, Michel Fortin wrote:
On 2009-07-23 05:37:24 -0400, Jacob Carlborg said:
Yes: http://www.dsource.org/projects/dmd-installer
I'm still waiting for Walter to add the osx installer to the dmd
download page.
Speaking of that OS X DMD installer, are you sure installing it at
/usr/share/dmd/ is a good idea? Normally /usr/share is reserved for
architecture-independent data[1], not executable files. What about
/usr/local/dmd with symlinks in /usr/local/bin for executables
/usr/local/lib for phobos and druntime and /usr/local/man for man pages.
Or perhaps install /Library/D/{dmd,dmd2} so the files are more user
accessible and easy to change if you got the zip archive (/usr is a
hidden dir on Mac OS X).
If I'm not mistaken, both your D1 and D2 installer install at the same
location and they will overwrite each other. I'd much prefer if D2 and
D1 could coexist without having to go with a special installer or custom
installation instructions. Otherwise it'll be hard for me to offer the
choice between D1 and D2 in Xcode (and I certainly do want that choice
to be available).
Thoughts?
[1]: http://www.pathname.com/fhs/2.2/fhs-4.11.html
Sorry I haven't replied sooner I've been on vacation.
I looked at a gdc installer and looked where it placed the compiler and
did the same. I don't know where it's best to place the compiler.
/Jacob Carlborg
Re: OS X Installer
On 8/2/09 03:40, Michel Fortin wrote: On 2009-08-01 20:15:41 -0400, Sergey Gromov said: Here's a nice document about directory layout in UNIX-like OSes: http://www.pathname.com/fhs/pub/fhs-2.3.html I think MacOS should follow this layout at least in part. In particular /usr/local/ is used for locally installed packages which otherwise respect the standard directory structure found in / or /usr/. That is, binaries go into /usr/local/bin/, libraries in /usr/local/lib/ etc. If a package wants to keep its own structure it's supposted to go into /opt/, like /opt/dmd2/whatever. Well, given that this is Mac OS X we could also put this in /Library/D/dmd and /Library/D/dmd2, two directories which aren't hidden by the file browser. Then put symlinks in /usr/local/bin and /usr/local/lib pointing there. Users will then be able to upgrade without an installer by simply replacing the folder at /Library/D/dmd & dmd2 with a newly downloaded one. I think that's better than /opt, as /opt isn't present by default on Mac OS X, isn't hidden by the Finder when present (contrary to all other "UNIX" directories at the root) and thus would look a little out of place on the hard drive. And there's already /Library/Python, /Library/PHP and /Library/Ruby in that /Library directory to set a precedent. I think I like /usr/local best. /Library is used for resources: http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI "The Library directory is a special directory used to store application-specific and system-specific resources". What about /Applications?
Re: DIP6: Attributes
On 8/4/09 18:55, Steven Schveighoffer wrote:
On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Tue, 04 Aug 2009 09:45:51 -0400, grauzone wrote:
Steven Schveighoffer wrote:
don't think it's worth adding them until we can have full
reflection capabilities so we can get at elements of code and
therefore get the annotations associated with it. I see much more
usefulness for annotations as reflection hints than as a
replacement for keywords.
But we already have full reflection. It's called __traits. You can
build a serialization library or "proper" (user friendly?)
reflection on top of it.
I think you are the 1 millionth person to say it, and yet we still do
not have a "user friendly" reflection system. Why is that? You'd
think that if it could be done, somebody would have done it by now.
The reality is there's quite few of us. D is not in the stage where if
something could be done, somebody somewhere has done it or is working
on it.
That's understandable, nobody can expect a language as young as D to
have everything.
But in reality, I think the *theory* that everything is there to build a
reflection system is only proven when it actually happens. I'm sure when
the enterprising person or persons go to develop it, they will find
pieces missing from the static reflection system.
So my point is that adding annotations before reflection works and is
implemented makes little sense to me, because the usage of them will be
crippled by the fact that reflection isn't complete.
What I'd like to see is something like this possible:
void foo (int timeout, string bar, float f = 4.0);
void foo(int timeout);
call!(foo)("timeout=5,bar=\"hello\"");
Taking into account the default value of f, what the parameters are
named, and which overload to call. I could certainly do it with C#.
-Steve
You mean like this: http://tango.pastebin.com/m129241b0 ?
/Jacob Carlborg
Re: DIP6: Attributes
On 8/4/09 19:20, Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Tue, 04 Aug 2009 09:45:51 -0400, grauzone wrote:
Steven Schveighoffer wrote:
don't think it's worth adding them until we can have full
reflection capabilities so we can get at elements of code and
therefore get the annotations associated with it. I see much more
usefulness for annotations as reflection hints than as a
replacement for keywords.
But we already have full reflection. It's called __traits. You can
build a serialization library or "proper" (user friendly?)
reflection on top of it.
I think you are the 1 millionth person to say it, and yet we still
do not have a "user friendly" reflection system. Why is that? You'd
think that if it could be done, somebody would have done it by now.
The reality is there's quite few of us. D is not in the stage where
if something could be done, somebody somewhere has done it or is
working on it.
That's understandable, nobody can expect a language as young as D to
have everything.
But in reality, I think the *theory* that everything is there to build
a reflection system is only proven when it actually happens. I'm sure
when the enterprising person or persons go to develop it, they will
find pieces missing from the static reflection system.
Exactly. I'm absolutely sure there are quite a few things needed here
and there. I can assure you I'll push hard for those.
So my point is that adding annotations before reflection works and is
implemented makes little sense to me, because the usage of them will
be crippled by the fact that reflection isn't complete.
What I'd like to see is something like this possible:
void foo (int timeout, string bar, float f = 4.0);
void foo(int timeout);
call!(foo)("timeout=5,bar=\"hello\"");
Taking into account the default value of f, what the parameters are
named, and which overload to call. I could certainly do it with C#.
This is interesting. It means we'd need reflection for parameter names,
which currently does not exist.
Andrei
It kind of exists:
void foo (int bar);
const str = typeof(&func).stringof;
"str" will contain the parameter names. See:
http://tango.pastebin.com/m129241b0 for an example.
Re: DIP6: Attributes
On 8/5/09 00:22, Jacob Carlborg wrote:
On 8/4/09 18:55, Steven Schveighoffer wrote:
On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Tue, 04 Aug 2009 09:45:51 -0400, grauzone wrote:
Steven Schveighoffer wrote:
don't think it's worth adding them until we can have full
reflection capabilities so we can get at elements of code and
therefore get the annotations associated with it. I see much more
usefulness for annotations as reflection hints than as a
replacement for keywords.
But we already have full reflection. It's called __traits. You can
build a serialization library or "proper" (user friendly?)
reflection on top of it.
I think you are the 1 millionth person to say it, and yet we still do
not have a "user friendly" reflection system. Why is that? You'd
think that if it could be done, somebody would have done it by now.
The reality is there's quite few of us. D is not in the stage where if
something could be done, somebody somewhere has done it or is working
on it.
That's understandable, nobody can expect a language as young as D to
have everything.
But in reality, I think the *theory* that everything is there to build a
reflection system is only proven when it actually happens. I'm sure when
the enterprising person or persons go to develop it, they will find
pieces missing from the static reflection system.
So my point is that adding annotations before reflection works and is
implemented makes little sense to me, because the usage of them will be
crippled by the fact that reflection isn't complete.
What I'd like to see is something like this possible:
void foo (int timeout, string bar, float f = 4.0);
void foo(int timeout);
call!(foo)("timeout=5,bar=\"hello\"");
Taking into account the default value of f, what the parameters are
named, and which overload to call. I could certainly do it with C#.
-Steve
You mean like this: http://tango.pastebin.com/m129241b0 ?
/Jacob Carlborg
Forgot to say: this works in D1 with dmd, gdc and ldc.
/Jacob Carlborg
Re: OS X Installer
On 8/3/09 14:32, Anders F Björklund wrote:
Michel Fortin wrote:
I think I like /usr/local best.
I like /usr/local best too.
The objection (if any) was mostly about "/usr/local/dmd/osx/bin"
vs /usr/local/bin, but using /usr/local/{dmd,dmd2} should be OK.
I was thinking about using /usr/local/{dmd,dmd2} and then create
symlinks to /usr/local/bin. But that will create problems with the
dmd.conf because it also needs a symlink in /usr/local/bin and then the
conf file for dmd and dmd1 will conflict.
Library directory is a special directory used to store
application-specific and system-specific resources".
Indeed.
Such as the language extensions in /Library/Perl and /Library/Python
already mentioned, elsewhere in /usr/lib/perl5 and /usr/lib/python2.X
What about /Applications?
I thought that was for applications. DMD isn't an appliction, it's a
command-line tool.
And even if it was, it would probably go in /Developer anyway ?
Like /Developer/Applications/CodeBlocks.app does, for instance.
--anders
Re: OS X Installer
On 8/7/09 17:32, Anders F Björklund wrote:
Michel Fortin wrote:
The objection (if any) was mostly about "/usr/local/dmd/osx/bin"
vs /usr/local/bin, but using /usr/local/{dmd,dmd2} should be OK.
I was thinking about using /usr/local/{dmd,dmd2} and then create
symlinks to /usr/local/bin. But that will create problems with the
dmd.conf because it also needs a symlink in /usr/local/bin and then
the conf file for dmd and dmd1 will conflict.
The solution is to create a "symlink program" and drop it in
/usr/local/bin. I know it works; I wrote one to do just that:
#include
int main(unsigned int argc, char **argv) {
argv[0] = "/usr/local/dmd/osx/bin/dmd";
execv("/usr/local/dmd/osx/bin/dmd", argv);
}
I did that for my linux package, but used shell instead.
Then the dmd.conf was a link back to the real config file,
to /etc/dmd.conf for dmd and to /etc/dmd2.conf for dmd2...
/usr/bin/dmd2 -> /usr/libexec/dmd2/dmd
/usr/libexec/dmd2/dmd.conf -> /etc/dmd2.conf
Then the conf files didn't conflict anymore.
--anders
If I understand you correctly you have a symlink "/usr/bin/dmd2"
pointing to "/usr/libexec/dmd2/dmd" and then a symlink
"/usr/libexec/dmd2/dmd.conf" pointing to "/etc/dmd2.conf".
I can't see how that would work, correct me if I'm wrong: dmd will only
search for a conf file named dmd.conf in the same path as the dmd
executable, in /etc or in the user home directory.
dmd will not find the file in /etc because it's named "dmd2.conf". The
file "usr/libexec/dmd2/dmd.conf" will not work because the dmd.conf will
needs to be in the same directory as the symlink and not the actual
executable, this was the first I tried.
/Jacob Carlborg
D on the Objective-C runtime?
I've been thinking for a while what it would take to get D running on the Objective-C runtime, in other words a D object will actually be an objc object, kind of like MacRuby but for D. How difficult it would be, how much work, what needs to change, both the runtime and the compiler? And if it would be worth the trouble. The reason for this is to make it easier to interface with Mac OS X system libraries like Cocoa. /Jacob Carlborg
Re: D on the Objective-C runtime?
On 9/6/09 12:51, Michel Fortin wrote:
On 2009-09-06 06:10:03 -0400, Jacob Carlborg said:
I've been thinking for a while what it would take to get D running on
the Objective-C runtime, in other words a D object will actually be an
objc object, kind of like MacRuby but for D. How difficult it would
be, how much work, what needs to change, both the runtime and the
compiler? And if it would be worth the trouble.
The reason for this is to make it easier to interface with Mac OS X
system libraries like Cocoa.
It certainly could be done, but first you'd need a way to handle the
differences between Objective-C and D methods:
- Objective-C methods are of the form "setObject:forKey:", which is
difficult to map to D.
I was thinking you sill have to create bindings and use objc_msgSend and
friends. Or something like "extern (Objc) void foo (int arg1, int
arg2);" would automatically be converted to "objc_msgSend(this,
sel_registerName("foo:arg2"), arg1, arg2);".
- Objective-C methods do not support overloading.
"void foo (int arg1, int arg2)" could be transformed to "foo:arg2" or
similar.
- Objective-C class methods (equivalent to D static member functions)
are "virtual", this is used within Cocoa
This would be a problem.
- Objective-C 2.0 allows a default method implementation in protocols
(equivalent to D interfaces).
- Templates, exceptions?
D would use the the objc exceptions and add new exception classes where
necessary. Templates would probably be disallowed.
If all you wanted was to make D work using the Objective-C runtime (with
overloading), you could apply some special name mangling rules, but that
would make it pretty incompatible with anything really in Objective-C.
On the other side, you could change the D method syntax to disallow
overloading, use that colon-separated-multiple-part syntax, depend on
static methods being "virtual" (this pattern is used at some places in
Cocoa) and add the capability to interfaces to have default
implementations. but then it wouldn't really be D.
I do not want the colon-separated-multiple-part syntax. I don't want to
modify the compiler too much, I sill want it to be D but virtual static
methods could be an acceptable modification for example.
Another approach is my D/Objective-C bridge:
<http://michelf.com/projects/d-objc-bridge/>, which allows you to write
a bridged class like below. It needs D1 and is not multithreaded, only
can do classes (no protocols, no categories for now), but it works quite
well for what it does.
Yes I know about your D/objc bridge.
class AppController : NSObject {
/** Counter for window title in openWindow. */
uint windowCount;
this() {
super();
}
/** Open this application's website. */
void openWebsite(Object sender) {
auto a = NSAlert.alert("Cannot open web site.", "OK", null, null,
"The D/Objective-C bridge doesn’t have access to NSWorkspace yet, "
"so we cannot open a website. Displaying an alert works though. ;-)");
a.runModal;
}
/** Open a new window and put it on the center of the screen. */
void openWindow(Object sender) {
auto window = new NSWindow(NSMakeRect(20, 20, 300, 200),
NSTitledWindowMask + NSClosableWindowMask + NSMiniaturizableWindowMask +
NSResizableWindowMask,
NSBackingStoreType.BUFFERED, false);
window.title = "untitled "~ std.string.toString(++windowCount);
window.center();
window.makeKeyAndOrderFront(this);
}
// Objective-C binding for IB actions.
mixin IBAction!(openWindow);
mixin IBAction!(openWebsite);
// Overrides from NSApplication delegate.
bool openUntitledFile(NSApplication sender) {
openWindow(sender);
return true;
}
bool shouldTerminateAfterLastWindowClosed(NSApplication sender) {
return true;
}
// Objective-C bindings for the above delegate methods.
mixin ObjcBindMethod!(openUntitledFile, bool,
"applicationOpenUntitledFile:", NSApplication);
mixin ObjcBindMethod!(shouldTerminateAfterLastWindowClosed, bool,
"applicationShouldTerminateAfterLastWindowClosed:", NSApplication);
}
Re: D on the Objective-C runtime?
On 9/6/09 15:12, Michel Fortin wrote:
On 2009-09-06 08:32:43 -0400, Christopher Wright said:
Off topic, but this would be a good place for user-defined attributes.
Then you could write something like:
@IBAction void openWindow(Object sender) {}
Indeed... although IBAction isn't so bad as a mixin, it gets much worse
with ObjcMethod where it is necessary to list all the argument types to
allow resolving overloaded functions:
void doOneAndTwo(int i, int j) {}
mixin ObjcMethod(void, doOneAndTwo, "doOne:andTwo:", int, int);
That is actually not necessary. It would be sufficient with a template
taking an alias to the method (most of the times). Then you can build a
selector string out of the method name and the parameter names. To get
the types of the method you can use traits templates/functions available
both in phobos and tango. You would probably also need a template taking
an alias and a selector string when the above doesn't work.
This would work best with new methods when you can control the method
and parameter names and not with existing methods.
Compare to what could be done with a parametrized attribute:
@ObjcMethod("doOne:andTwo:") void doOneAndTwo(int i, int j);
That'd would be a lot more convenient, especially with interfaces for
which none of the mixin above can work (they insert some static struct
member to store the "attributes").
Re: D on the Objective-C runtime?
On 9/6/09 14:18, Michel Fortin wrote:
On 2009-09-06 07:52:27 -0400, Jacob Carlborg said:
On 9/6/09 12:51, Michel Fortin wrote:
On 2009-09-06 06:10:03 -0400, Jacob Carlborg said:
I've been thinking for a while what it would take to get D running on
the Objective-C runtime, in other words a D object will actually be an
objc object, kind of like MacRuby but for D. How difficult it would
be, how much work, what needs to change, both the runtime and the
compiler? And if it would be worth the trouble.
The reason for this is to make it easier to interface with Mac OS X
system libraries like Cocoa.
It certainly could be done, but first you'd need a way to handle the
differences between Objective-C and D methods:
- Objective-C methods are of the form "setObject:forKey:", which is
difficult to map to D.
I was thinking you sill have to create bindings and use objc_msgSend
and friends. Or something like "extern (Objc) void foo (int arg1, int
arg2);" would automatically be converted to "objc_msgSend(this,
sel_registerName("foo:arg2"), arg1, arg2);".
That doesn't scale very well. Overloading allows both "foo(int arg1, int
arg2)" and "foo(int arg1, float arg2)" to exist in the same scope, both
would become "foo:arg2:".
- Objective-C methods do not support overloading.
"void foo (int arg1, int arg2)" could be transformed to "foo:arg2" or
similar.
Yeah, but what if you have foo(int a) and foo(float a)? Then you need
some kind of name mangling:
foo(int a) becomes - fooInt:(int)a
foo(float a) becomes - fooFloat:(int)a
and now the two can exist at the same time in the same class.
- Objective-C class methods (equivalent to D static member functions)
are "virtual", this is used within Cocoa
This would be a problem.
- Objective-C 2.0 allows a default method implementation in protocols
(equivalent to D interfaces).
- Templates, exceptions?
D would use the the objc exceptions and add new exception classes
where necessary. Templates would probably be disallowed.
So now the base exception class is NSException?
If all you wanted was to make D work using the Objective-C runtime (with
overloading), you could apply some special name mangling rules, but that
would make it pretty incompatible with anything really in Objective-C.
On the other side, you could change the D method syntax to disallow
overloading, use that colon-separated-multiple-part syntax, depend on
static methods being "virtual" (this pattern is used at some places in
Cocoa) and add the capability to interfaces to have default
implementations. but then it wouldn't really be D.
I do not want the colon-separated-multiple-part syntax. I don't want
to modify the compiler too much, I sill want it to be D but virtual
static methods could be an acceptable modification for example.
Hum, I think if someone wanted to have Objective-C compatibility it'd be
better to just add a different syntax for declaring Objective-C classes
than to try to fit them within D classes, much like with Objective-C++.
Yeah, perhaps you're right, I was just thinking out loud.
Re: Derelict+Tango
On 9/6/09 21:05, Moritz Warning wrote:
On Sun, 06 Sep 2009 18:54:06 +, Moritz Warning wrote:
[..]
No rebuild rebuild required for this step.
On a second look,
I see that buildme.d uses bud (some older build tool for D).
I can tell you how I install derelict "by hand":
- download the trunk (zip archive is at http://www.dsource.org/projects/
derelict/browser/trunk)
- create an derelict directory
- move the contents from all trunk/Derelict*/derelict/*
directories into the new derelict directory we created before
- put the derelict directory next to your main.d
- add the code at the end of this post into your main.d
- rebuild main.d or xfbuild main.d
import derelict.sdl.sdl;
import derelict.sdl.image;
import derelict.opengl.gl;
import derelict.opengl.glu;
static this()
{
DerelictGL.load();
DerelictGLU.load();
DerelictSDL.load();
DerelictSDLImage.load();
if (SDL_Init(SDL_INIT_EVERYTHING)< 0)
{
throw new Exception("Failed to initialize SDL: " ~
fromStringz(SDL_GetError()));
}
// Enable key repeat so the player can keep a key down for moving
if (SDL_EnableKeyRepeat(SDL_DEFAULT_REPEAT_DELAY,
SDL_DEFAULT_REPEAT_INTERVAL))
{
throw new Exception("Failed to set key repeat: " ~
fromStringz(SDL_GetError()));
}
}
static ~this()
{
SDL_Quit();
// release GL, GLU and SDL's shared libs
DerelictGLU.unload();
DerelictGL.unload();
DerelictSDL.unload();
}
Or just using dsss: in the derelict directory run "dsss build && dsss
install"
/Jacob Carlborg
Re: Modern Windows GUI visual styles
On 9/9/09 11:19, Valery wrote: Recently I spent a few hours to find a way to enable a new styles of Windows XP controls from the code (without manual created external manifest files, resource files, ...). The only solution I found in DFL library and it looks quite complicated. Maybe should create that function at the level of the compiler or linker? There is no good solution for this problem. I was working on this for DWT and you somehow always need to have a manifest file. The problem is that windows doesn't load the correct dll and that's what the manifest file is for. You can look at the bottom of http://hg.dsource.org/projects/dwt-win/file/210994f12c4c/README.txt for a couple of options. If I remember correctly DFL creates a manifest file at runtime and then loads it. /Jacob Carlborg
Re: Function parameters name
You can also get the parameter names using .stringof, see
http://www.dsource.org/projects/dstep/browser/dstep/internal/Traits.d
for an example. This will also work in D1.
On 9/10/09 20:34, Julian wrote:
Hello,
I'm trying to obtain the parameters name of a function via __traits.
The patches are on bugzilla :
http://d.puremagic.com/issues/show_bug.cgi?id=3309
Could you please review this ?
Provided test case works.. but I actually have a problem with
FuncDeclaration->parameters being NULL when the function is declared in
another module.
The main idea is to build a small web framework going along the lines of :
class HelloResource
{
string show(in string username)
{
return "Hello, " ~ username;
}
}
(new ResourceMapper).connect!("/hello/{username}")(new HelloResource);
http://www.example.com/hello/Julian : `show` method would be called with
"Julian" being the `username` parameter.
class UsersResource
{
User[] show(in ushort offset, in ushort limit)
{
return [ user0, user1 ];
}
}
(new ResourceMapper).connect!("/users")(new UsersResource);
http://www.example.com/users?offset=0&limit=10 : `show` method would be
called with 0 being the `offset` parameter and 10 being the `limit`
parameter.
Thank you,
Julian.
Mixin a constructor ?
Is it supposed to possible to mixin a constructor? The code below
doesn't compile. The error: is "main.d(23): Error: constructor
main.A.this() does not match parameter types (int)
main.d(23): Error: expected 0 arguments, not 1"
template C ()
{
this (int i)
{
}
}
class A
{
mixin C;
this ()
{
}
}
void main ()
{
auto a = new A(3);
}
Re: Mixin a constructor ?
On 9/19/09 20:55, Christopher Wright wrote:
Jacob Carlborg wrote:
Is it supposed to possible to mixin a constructor? The code below
doesn't compile. The error: is "main.d(23): Error: constructor
main.A.this() does not match parameter types (int)
main.d(23): Error: expected 0 arguments, not 1"
A template mixin introduces a new scope. This is pretty annoying in some
cases. More often, it is convenient. Since the constructor is not in the
same scope as the class, it might be causing problems.
The problem only seems to be when I'm having constructors both in the
template and in the class.
If you didn't introduce a new scope by default, it'd be easy enough to
add it in the template or around the mixin:
template MixMeIn()
{
int imInUrScope;
{
int imOuttaUrScope;
}
}
Additionally, the difference would be easily detectable, because symbol
collision would cause the code to fail to compile. Unless the mixin adds
a function overload and you pass the address of the overload set
somewhere, and now you're passing the wrong overload...which is an old
problem for D, aggravated by D's property syntax, and unlikely to be
fixed soon.
Re: Video Codecs?
On 9/30/09 22:42, Benji Smith wrote: Does anybody know of any D libraries implementing or wrapping video codecs? I need to read video files (AVI or MPEG would be fine) using DIVX, XVID, or any other popular codec. In addition to playing those files in a media player control, I need to extract individual frames and perform various filtration and processing operations on them, for a computer vision project I'm about to start working on. I looked around at DSource but didn't find anything there. Any ideas? --benji There is rulesPlayer: http://www.dsource.org/projects/rulesplayer it uses MPlayer so I guess it has to have bindings to it but I don't know what you can do with MPlayer.
Uniform function call syntax
In the first D conference there was some talk about uniform function call syntax which allowed a.foo(x) and foo(a, x) to be interchangeable (just as we have now with arrays), what happened do that? Will it still happen? Except for the mentioned advantages in the talk I've found another use for it. When creating bindings to Objective-C it could be used to simulate categories which otherwise is quite hard simulate and doesn't scale well. The only way I found requires that the source is available of the class to add the methods to. I poked around in the DMD sources I found that it's really easy to add, just edit one line. However there is a problem it don't work for literals like 3.foo(), for that I think that parser needs to be modified. For those unfamiliar with Objective-C and categories: "A category allows you to add methods to an existing class—even to one to which you do not have the source", http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocCategories.html#//apple_ref/doc/uid/TP30001163-CH20-SW1 /Jacob Carlborg
Re: Uniform function call syntax
On 10/9/09 00:23, Nick Sabalausky wrote: "Jacob Carlborg" wrote in message news:halgto$1kc...@digitalmars.com... In the first D conference there was some talk about uniform function call syntax which allowed a.foo(x) and foo(a, x) to be interchangeable (just as we have now with arrays), what happened do that? Will it still happen? Yea, I find not having that to be a painful inconsistancy. Been hoping for that for a while. Except for the mentioned advantages in the talk I've found another use for it. When creating bindings to Objective-C it could be used to simulate categories which otherwise is quite hard simulate and doesn't scale well. The only way I found requires that the source is available of the class to add the methods to. I poked around in the DMD sources I found that it's really easy to add, just edit one line. Can you please post the file, line number, old line, new line, and dmd ver? Or submit a patch to bugzilla. That could be helpful for anyone who wants to look into this furthur. I've submitted a patch to bugzilla: http://d.puremagic.com/issues/show_bug.cgi?id=3382 However there is a problem it don't work for literals like 3.foo(), for that I think that parser needs to be modified. For those unfamiliar with Objective-C and categories: "A category allows you to add methods to an existing class—even to one to which you do not have the source", http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocCategories.html#//apple_ref/doc/uid/TP30001163-CH20-SW1 Do you know if that actually affects the class itself (like adds an entry to the vtable or , or something like that)? If not, that sounds like what C# calls extension methods, which are just like what D does with arrays (except that you have to actually declare the function to be an extension method - which I've been kind of on the fence about as to whether I like that or not).
Re: clear()
On 10/9/09 18:40, Andrei Alexandrescu wrote:
I'm talking with Sean and Walter about taking the first step towards
eliminating delete: defining function clear() that clears the state of
an object. Let me know of what you think.
One problem I encountered is that I can't distinguish between a default
constructor that doesn't need to exist, and one that was disabled
because of other constructors. Consider:
class A {}
class B { this(int) {} }
You can evaluate "new A" but not "new B". So it's legit to create
objects of type A all default-initialized. But the pointer to
constructor stored in A.classinfo is null, same as B.
Any ideas?
Andrei
How about this:
static if (is(typeof({
auto t = new T;
})))
Re: clear()
On 10/10/09 12:06, Denis Koroskin wrote:
On Sat, 10 Oct 2009 13:08:01 +0400, Max Samukha
wrote:
On Fri, 09 Oct 2009 21:50:48 +0200, Yigal Chripun
wrote:
On 09/10/2009 19:53, Max Samukha wrote:
On Fri, 09 Oct 2009 11:40:43 -0500, Andrei Alexandrescu
wrote:
I'm talking with Sean and Walter about taking the first step towards
eliminating delete: defining function clear() that clears the state of
an object. Let me know of what you think.
One problem I encountered is that I can't distinguish between a
default
constructor that doesn't need to exist, and one that was disabled
because of other constructors. Consider:
class A {}
class B { this(int) {} }
You can evaluate "new A" but not "new B". So it's legit to create
objects of type A all default-initialized. But the pointer to
constructor stored in A.classinfo is null, same as B.
Any ideas?
The notion of default constructor is not quite clear.
class A
{
this(int a = 22) {}
}
Should A be considered as having a default constructor?
class B
{
this(int) {}
}
Should passing int.init to B's constructor be considered default
construction? If yes, we could recreate B using the init value. But
then:
class C
{
this(int a) {}
this(int a, int b) {}
}
Which constructor to call? The one with fewer parameters? What if
there are overloaded constructors with identical number of parameters?
Should we explicitly mark one of the constructors as default?
I agree. classinfo.defaultConstructor should be replaced by an array of
all the constructors. Only when the array is empty you assume the
existence of the default compiler generated constructor.
I'd prefer complete runtime information for all members.
The problem is I do not understand what 'default constructor' and
'default construction' means in D for classes that have explicit
constructors with parameters. How to automatically construct this cl
ass:
class B
{
this(int a = 22) {}
}
?
For example, Object.factory will always return null for B, which is an
arbitrary limitation.
class C
{
this(int a) {}
}
For C, the "default constructor" should probably be generated like
this:
void C_ctor(C c)
{
c.__ctor(int.init);
}
etc.
Otherwise, I cannot see how one can reconstruct an instance of C in
'clear'.
obj.clear(42);
Wait, uniform function call syntax doesn't work with classes! Oh, well...
clear!(C)(obj, 42);
I've suggested to implement uniform function call syntax:
http://d.puremagic.com/issues/show_bug.cgi?id=3382
Re: dmd support for IDEs
On 10/11/09 11:56, Frank Benoit wrote: Walter Bright schrieb: They say that the productivity gains of D's improvements are overbalanced by the loss of productivity by moving away from an IDE. And what is it about an IDE that is so productive? If you use Eclipse for Java, you have: - Debugger in place - Automatic builder, compile on save * Jump to line from error list * Jump to declaration - Show JavaDoc in tooltip, even in autocompletion - Show hierarchy tree - Autocompletion - Quick assist, e.g. - assign ctor parameter to new field - extract selected text into local variable - Mark source portion, extract to method, the IDE evaluates the needed parameters and return value - ... There is so much more. But the main thing is, you are not only able to use grep and friends on the pure text level. With an IDE you have semantic support. This makes refactoring your code so much easier. You can say "rename this method" and it works, all references to this method are also altered. "Move this inner class to a top level class in that package", "Derive from that class, yes add the needed ctors". There is even an API to automate refactorings. I think Descent is the right way. But here, a port of DMD is directly integrated into the plugin. To put more manpower in this project would be the best way imo. I completely agree. I don't know if it would be better to have the parts of dmd that descent needs in a separate library to avoid porting half of dmd to java.
Re: dmd support for IDEs
On 10/11/09 16:32, Denis Koroskin wrote: On Sun, 11 Oct 2009 05:19:56 +0400, Walter Bright wrote: In my discussions with companies about adopting D, the major barrier that comes up over and over isn't Tango vs Phobos, dmd being GPL, debugger support, libraries, bugs, etc., although those are important. It's the IDE. They say that the productivity gains of D's improvements are overbalanced by the loss of productivity by moving away from an IDE. And what is it about an IDE that is so productive? Intellisense (Microsoft's word for autocompletion). So, while I'm not going to be writing an IDE, I figure that dmd can help. dmd already puts out .doc and .di files. How about putting out an xml file giving all the information needed for an IDE to implement autocompletion? There'd be one .xml file generated per .d source file. The nice thing about an xml file is while D is relatively easy to parse, xml is trivial. Furthermore, an xml format would be fairly robust in the face of changes to D syntax. What do you think? I believe it won't work. It will always be slow and incomplete. Instead, I would make it easier to embed DMD into an IDE: separate DMDFE from DMDBE, fix memory leaks, remove all the static data (so that code would be re-intrable and it could work in different threads in parallel), move most of DMD code into a DLL so that an IDE could dynamically link with it and whatever it pleases with the source code. In fact, that's what I do right now. I'm writing my own D IDE in my spare time (in D, of course). I already made a lot of progress and now it's time to start implementing source code analysis. First thing I did is I made complete D bindings for C++ code. It worked out quite well but it was leaking so badly that I dropped it. Instead, I started porting DMD entirely to D (except the backend, of course), and I already got some great results. A few simple programs compile and produce byte-perfect binaries. It's still in its early stages and there is a lot of work to do, but it will be finished soon (hopefully). It could probably become a part of an official distribution, eventually. :) If anyone is interested and is willing to test and/or help, I will gladly share my code. Sounds interesting, put it online somewhere.
Re: dmd support for IDEs
On 10/11/09 15:23, Ary Borenszweig wrote:
Walter Bright wrote:
In my discussions with companies about adopting D, the major barrier
that comes up over and over isn't Tango vs Phobos, dmd being GPL,
debugger support, libraries, bugs, etc., although those are important.
It's the IDE.
So, while I'm not going to be writing an IDE, I figure that dmd can
help. dmd already puts out .doc and .di files. How about putting out
an xml file giving all the information needed for an IDE to implement
autocompletion? There'd be one .xml file generated per .d source file.
What do you think?
What I think is that even with an xml representing the parse tree (maybe
with some semantic stuff resolved) it'll be still incomplete for a real
IDE (the kind of thing users expect from an IDE). You can see this
video, for example:
http://www.youtube.com/watch?v=KQbTT605ags
So you have:
---
module one;
class Foo(T) {
static if (is(T == class)) {
T property;
} else {
T someMethod() { return T.init; }
}
mixin(guessWhat!(T)());
}
---
You want to define an xml for that module that'll help IDEs. Can you
think what it'll look like?
Now the user writes in another module:
class Bar {
}
void x() {
auto foo = new Foo!(Bar)();
foo. <-- what does the IDE do here?
}
Now, the correct thing for the IDE to do is to suggest the field "Bar
property". How can the IDE do that just with an xml? It can't. It need
to perform some kind of semantic anlysis to Foo's argument to see if
it's a class, match the static if in the template, replace template
parameters, etc. It also needs to evaluate the string mixin.
Of course you could say "Bah, just show all the declarations inside the
template in the autocomplete", but that's wrong. That'll lead to files
that don't compile. You could ommit supporting autocompletion or other
nice features, but that's exactly the big features of D. If you don't
support that then it's like using Java or C# from within the IDE: you
could use the advanced features but the IDE won't help you. And in your
discussions with companies adopting D, I'm sure they were talking about
great IDEs like JDT Eclipse or Visual Studio, not just some tool that
helps you a little but not anymore when things get interesting.
Oh, and you need to have some kind of semantic analysis to know the type
of "auto foo". Again, maybe the IDE can be dummy and see "auto foo = new
Foo!(Bar)" and say "ok, foo's type is Foo!(Bar)", but then you have:
auto b = foo.property;
b. <-- and here?
// remember "property" is templated and depends on static analysis
// or the IDE could need to resolve alias this or other things
So... my opinion (like some others, I see) is to either ask things to
the compiler directly (but here the compiler lacks some info, like exact
source range positions), or to have a compiler (not a full-blown one,
just the front-end) built into the IDE, and that's what Descent is.
Unfortunately Descent is sometimes slow, sometimes buggy, but that's
normal: just a few people develop and maintain it (so I can see a
similarity with dmd here, where each day I see two or three new bugs
reported). If more people were into it, more unit tests were written
into it and, most of all, more people would use it, it'll get better.
I use it almost at a daily base and it works great. I can't remember the
last time it cashed.
Another problem that people see in Descent (maybe also JDT Eclipse and
Visual Studio0 is that it's huge, it consumes a lot of memory and they
don't want to open a huge tool just to hack some lines. My answer is:
memory performance can be improved (but not a lot), but since an IDE is
a huge tool it requires a lof from the computer. And an IDE is not meant
to be used to hack some lines, it's meant to help you write big project,
huge projects without getting lost in the amount of code.
So my bet would be to start supporting an existing IDE that integrates a
compiler into it. Updating it is easy: just port the diffs between DMD
versions. It's a huge job for one or two people, but if a lot of people
were involved it's not that much. Of course I'd recommend you to try
Descent since I'm one of it's creators and I do believe it can get
pretty good. :-)
Re: dmd support for IDEs
On 10/11/09 16:38, BLS wrote: On 11/10/2009 03:19, Walter Bright wrote: In my discussions with companies about adopting D, the major barrier that comes up over and over isn't Tango vs Phobos, dmd being GPL, debugger support, libraries, bugs, etc., although those are important. It's the IDE. They say that the productivity gains of D's improvements are overbalanced by the loss of productivity by moving away from an IDE. And what is it about an IDE that is so productive? Intellisense (Microsoft's word for autocompletion). So, while I'm not going to be writing an IDE, I figure that dmd can help. dmd already puts out .doc and .di files. How about putting out an xml file giving all the information needed for an IDE to implement autocompletion? There'd be one .xml file generated per .d source file. The nice thing about an xml file is while D is relatively easy to parse, xml is trivial. Furthermore, an xml format would be fairly robust in the face of changes to D syntax. What do you think? FANTASTIC! Give it a go. Despite the intention to support a D IDE ... I would make sense to establish this feature in D1 too. Imagine XML2D which may help to port D1 code to D2. I would further suggest to consider to output to Oracle Berkeley DB XML .. Having an XQuery-based access to D-sources.. I guess you can imagine what this could mean. There are a couple of D IDEs around. I think what people mean with there is no D IDE is simply : "We want a MS Visual Studio like IDE as part of the D tool chain" One download, that's it. I agree. But we need a platform independent IDE. Our Options : 1) Force Decent.. (Java/SWT) I think this the our best option now 2) Use gtkD, create the IDE in D. (the only usable platform independent GUI atm.) 3) Use QT and C++. Let's re-use and adapt QT Creator. Having QT as standard GUI toolkit for D means that we can also reuse the QT Designer. As far as I know neither Qt(d) or gtkD uses native controls on platforms other than linux, which to me is unacceptable. The look especially on mac. 4) Port entire eclipse to D, Frank Benoit (who started DWT, the tango version) was thinking of this. Bjoern
Re: dmd support for IDEs
On 10/11/09 21:38, Walter Bright wrote: Ary Borenszweig wrote: Walter Bright wrote: Denis Koroskin wrote: In fact, that's what I do right now. I think that's great. But it requires a lot of work (as of course you know). Good things require a lot of work. :) Of course. But getting something done and available in a short amount of time is also good! For example, some people say to me "why should I use D, when C++0x solves my issues with C++?" And I point out "how many more years are you willing to wait for C++0x, when D is here now?" [Setting aside for the moment the issue of whether C++0x really is better than D or not!] The point is, good enough now gets us further down the road of getting a user base large enough to justify the effort for a more comprehensive solution. I think descent is really good now. For example, if I have many miles to commute to work, the best choice is a car. But if I can't afford a car, or am too young to drive, a bike at least gets me there. Before I was 16 and could drive, a bike was very liberating for me, I rode it everywhere.
Re: dmd support for IDEs
On 10/11/09 20:58, Yigal Chripun wrote:
On 11/10/2009 15:23, Ary Borenszweig wrote:
Walter Bright wrote:
In my discussions with companies about adopting D, the major barrier
that comes up over and over isn't Tango vs Phobos, dmd being GPL,
debugger support, libraries, bugs, etc., although those are important.
It's the IDE.
So, while I'm not going to be writing an IDE, I figure that dmd can
help. dmd already puts out .doc and .di files. How about putting out
an xml file giving all the information needed for an IDE to implement
autocompletion? There'd be one .xml file generated per .d source file.
What do you think?
What I think is that even with an xml representing the parse tree (maybe
with some semantic stuff resolved) it'll be still incomplete for a real
IDE (the kind of thing users expect from an IDE). You can see this
video, for example:
http://www.youtube.com/watch?v=KQbTT605ags
So you have:
---
module one;
class Foo(T) {
static if (is(T == class)) {
T property;
} else {
T someMethod() { return T.init; }
}
mixin(guessWhat!(T)());
}
---
You want to define an xml for that module that'll help IDEs. Can you
think what it'll look like?
Now the user writes in another module:
class Bar {
}
void x() {
auto foo = new Foo!(Bar)();
foo. <-- what does the IDE do here?
}
Now, the correct thing for the IDE to do is to suggest the field "Bar
property". How can the IDE do that just with an xml? It can't. It need
to perform some kind of semantic anlysis to Foo's argument to see if
it's a class, match the static if in the template, replace template
parameters, etc. It also needs to evaluate the string mixin.
Of course you could say "Bah, just show all the declarations inside the
template in the autocomplete", but that's wrong. That'll lead to files
that don't compile. You could ommit supporting autocompletion or other
nice features, but that's exactly the big features of D. If you don't
support that then it's like using Java or C# from within the IDE: you
could use the advanced features but the IDE won't help you. And in your
discussions with companies adopting D, I'm sure they were talking about
great IDEs like JDT Eclipse or Visual Studio, not just some tool that
helps you a little but not anymore when things get interesting.
Oh, and you need to have some kind of semantic analysis to know the type
of "auto foo". Again, maybe the IDE can be dummy and see "auto foo = new
Foo!(Bar)" and say "ok, foo's type is Foo!(Bar)", but then you have:
auto b = foo.property;
b. <-- and here?
// remember "property" is templated and depends on static analysis
// or the IDE could need to resolve alias this or other things
So... my opinion (like some others, I see) is to either ask things to
the compiler directly (but here the compiler lacks some info, like exact
source range positions), or to have a compiler (not a full-blown one,
just the front-end) built into the IDE, and that's what Descent is.
Unfortunately Descent is sometimes slow, sometimes buggy, but that's
normal: just a few people develop and maintain it (so I can see a
similarity with dmd here, where each day I see two or three new bugs
reported). If more people were into it, more unit tests were written
into it and, most of all, more people would use it, it'll get better.
Another problem that people see in Descent (maybe also JDT Eclipse and
Visual Studio0 is that it's huge, it consumes a lot of memory and they
don't want to open a huge tool just to hack some lines. My answer is:
memory performance can be improved (but not a lot), but since an IDE is
a huge tool it requires a lof from the computer. And an IDE is not meant
to be used to hack some lines, it's meant to help you write big project,
huge projects without getting lost in the amount of code.
So my bet would be to start supporting an existing IDE that integrates a
compiler into it. Updating it is easy: just port the diffs between DMD
versions. It's a huge job for one or two people, but if a lot of people
were involved it's not that much. Of course I'd recommend you to try
Descent since I'm one of it's creators and I do believe it can get
pretty good. :-)
well put.
btw, given that we have a port of SWT for D, how hard would it be to
create our own native D version of eclipse?
Frank Benoit (who started DWT, the tango version) was think about this.
Quite a big part is already ported, SWT, JFace, Forms, OSGI and so on,
see: http://hg.dsource.org/projects/dwt2/file/88652073d1c2/ .
I think one of the biggest challenge to port is class loading, dynamic
libraries could work for this but we all know how well they work on windows.
Messages both in d.D.ide and d.D ?
Why do some messages show up both in d.D.ide and d.D?
Re: dmd support for IDEs
On 10/11/09 22:37, Denis Koroskin wrote: On Mon, 12 Oct 2009 00:36:01 +0400, Jacob Carlborg wrote: 4) Port entire eclipse to D, Frank Benoit (who started DWT, the tango version) was thinking of this. Bjoern What's the benefit? I believe it'll become even slower. Much slower. Maybe we could try to slim it down, remove things that aren't needed.
Re: Messages both in d.D.ide and d.D ?
On 10/11/09 23:15, Walter Bright wrote: Denis Koroskin wrote: On Mon, 12 Oct 2009 00:44:48 +0400, Jacob Carlborg wrote: Why do some messages show up both in d.D.ide and d.D? Because the Walter decided to post the topic to both newsgroups at once, and all the replies follow it (take a look at message header). I tried that as an experiment. Not sure if it was a good idea or not. Probably not. No it's just confusing, trying to follow one discussion in two newsgroups
Re: dmd support for IDEs
On 10/12/09 02:08, Jeremie Pelletier wrote: Lutger wrote: Jacob Carlborg wrote: ... As far as I know neither Qt(d) or gtkD uses native controls on platforms other than linux, which to me is unacceptable. The look especially on mac. Qt used to try and look like native controls, but now it uses them directly. It has pros and cons, Firefox too has the native look and feel without using the native controls, so it saves on the overhead of tons of GDI handles and can render the entire GUI in cairo. In the Mac version for a long time they used the older tabs from Mac OS X 10.4 or even older. That's the problem not using native controls, if the operating system change them it's a lot of more work to update your application.
Re: dmd support for IDEs
On 10/12/09 04:14, Chad J wrote: Jeremie Pelletier wrote: Lutger wrote: Jacob Carlborg wrote: ... As far as I know neither Qt(d) or gtkD uses native controls on platforms other than linux, which to me is unacceptable. The look especially on mac. Qt used to try and look like native controls, but now it uses them directly. It has pros and cons, Firefox too has the native look and feel without using the native controls, so it saves on the overhead of tons of GDI handles and can render the entire GUI in cairo. I actually rather dislike GTK from a user standpoint. It doesn't mesh well at all on my KDE linux setup. The file dialog is also a frequent source of annoyance, as it is different then everything else and seems to want to fight with me. Qt is much better at these things. Too bad we can't just make programs switch between GUI backends at will ;) Why not have a GUI toolkit available on almost all platforms that uses native controls just like DWT?
Re: Messages both in d.D.ide and d.D ?
On 10/12/09 14:02, language_fan wrote: Mon, 12 Oct 2009 13:32:00 +0200, Jacob Carlborg thusly wrote: On 10/11/09 23:15, Walter Bright wrote: Denis Koroskin wrote: On Mon, 12 Oct 2009 00:44:48 +0400, Jacob Carlborg wrote: Why do some messages show up both in d.D.ide and d.D? Because the Walter decided to post the topic to both newsgroups at once, and all the replies follow it (take a look at message header). I tried that as an experiment. Not sure if it was a good idea or not. Probably not. No it's just confusing, trying to follow one discussion in two newsgroups A proper NNTP client fully supports crossposting. There is no need to re- read the messages. Do you have any suggestions (available on mac)? I use Thunderbird now.
Re: dmd support for IDEs
On 10/12/09 14:11, language_fan wrote: Mon, 12 Oct 2009 14:02:11 +0200, Jacob Carlborg thusly wrote: On 10/12/09 04:14, Chad J wrote: Too bad we can't just make programs switch between GUI backends at will ;) Why not have a GUI toolkit available on almost all platforms that uses native controls just like DWT? The list of native platforms SWT supports is this: Win32 WPF (under development) AIX, FreeBSD, Linux, HP-UX, Solaris: Motif GTK+ Mac OS X: Carbon Cocoa QNX Photon Pocket PC As a FLTK2, Qt 3.x, Qt 4.x, Swing, and (forked) Harmonia user I fail to see how SWT is more native than the ones I develop for. All SWT applications look weird, unthemed, and have horrible usability issues in the file open/save dialogs. DWT brings another level of cruft above the "lightweight" SWT and performs badly. As a said previously SWT is more native because it uses the native GUI library available on the current platform, for windows (before vista) win32, osx cocoa and on linux gtk. It doesn't decide how a button should look, it doesn't try do draw a button that is similar to the natives, it just call the native library to draw the button. I don't know what you mean by "unthemed" but if you refer to that applications on windows don't get the winxp look you have the same problem if you create the application in c++ or c and uses win32. It's caused by an older dll is loaded as default and to get the winxp look you have to request it to load the newer dll with a manifest file. Welcome to dlls. If you have problems with the open/save dialogs in SWT either you will have the same problem in other native applications because it uses the native dialogs or there's a bug in SWT. DWT doesn't add any extra levels that SWT doesn't have. In fact it removes one, the jni wrappers. DWT is a complete port of SWT to D, with only native code.
Re: dmd support for IDEs
On 10/12/09 19:41, language_fan wrote:
Mon, 12 Oct 2009 18:54:25 +0200, Jacob Carlborg thusly wrote:
On 10/12/09 14:11, language_fan wrote:
Mon, 12 Oct 2009 14:02:11 +0200, Jacob Carlborg thusly wrote:
On 10/12/09 04:14, Chad J wrote:
Too bad we can't just make programs switch between GUI backends at
will ;)
Why not have a GUI toolkit available on almost all platforms that uses
native controls just like DWT?
The list of native platforms SWT supports is this:
Win32
WPF (under development)
AIX, FreeBSD, Linux, HP-UX, Solaris:
Motif
GTK+
Mac OS X:
Carbon
Cocoa
QNX Photon
Pocket PC
As a FLTK2, Qt 3.x, Qt 4.x, Swing, and (forked) Harmonia user I fail to
see how SWT is more native than the ones I develop for. All SWT
applications look weird, unthemed, and have horrible usability issues
in the file open/save dialogs. DWT brings another level of cruft above
the "lightweight" SWT and performs badly.
As a said previously SWT is more native because it uses the native GUI
library available on the current platform, for windows (before vista)
win32, osx cocoa and on linux gtk. It doesn't decide how a button should
look, it doesn't try do draw a button that is similar to the natives, it
just call the native library to draw the button.
The problem is, 99% of win32 users use the win32 gui toolkit on win32,
99% of osx users use cocoa, but on Linux/BSD maybe about 40% use gtk+. It
is not The native toolkit to use. I do not even have it installed on my
system.
I don't know what you mean by "unthemed" but if you refer to that
applications on windows don't get the winxp look you have the same
problem if you create the application in c++ or c and uses win32. It's
caused by an older dll is loaded as default and to get the winxp look
you have to request it to load the newer dll with a manifest file.
Welcome to dlls.
I mostly work on *nixen. The unthemed means that I do not have *any* gtk+
libraries installed anywhere so it defaults to the ugly default theme. To
me gtk+ does not have the native feel as I never see any application
written in it. Like I said, I only use { FLTK2, Qt 3.x, Qt 4.x, Swing,
and (forked) Harmonia}. I am sorry if you have trouble reading that.
Whenever an application comes with its own (statically linked) gtk+ libs,
it will look bad. I do not have any "control panel" to change the look
and feel of the gtk+ applications.
If you have problems with the open/save dialogs in SWT either you will
have the same problem in other native applications because it uses the
native dialogs or there's a bug in SWT.
Look, this is what I get on Win32:
http://johnbokma.com/textpad/select-a-file-dialog.png
on Linux:
http://www.matusiak.eu/numerodix/blog/wp-content/uploads/20050710-
kdefilechooser.png
on Java:
http://www.dil.univ-mrs.fr/~garreta/docJava/tutorial/figures/uiswing/
components/FileChooserOpenMetal.png
You can probably see something that I have started to call 'consistency'.
Almost the same buttons and layouts on every platform. I immediately know
how it works. The same design has been there since Windows 95, if I
recall correctly. This is what many people have learned to live with.
Now every time I see a gtk+/swt/dwt application I wonder where the heck
that unintuitive terrible piece of cr*p came:
http://book.javanb.com/swt-the-standard-widget-toolkit/images/0321256638/
graphics/14fig03.gif
Native? It might very well use native binaries on my platform, but the
native feel ends there.
Of course it will look strange when you use an application built on a
toolkit it isn't built for. Will have to wait for a Qt version.
Re: Specializing on Compile Time Constants
On 10/12/09 23:49, dsimcha wrote:
I'm working on a mathematical expression interpreter for D, which would allow
for closed form mathematical expressions to be specified as string literals at
runtime and be evaluated. For example:
MathExp myExpression = mathExp("x^2 + e^cos(-x) - 2 * sqrt(pi)", "x");
writeln(myExpression(2)); // Does exactly what you think it does.
I've found the syntax so convenient that I'd like to transparently specialize
it on strings known at compile time. The idea is that, when the expression is
hard-coded, you will still be able to use the MathExp interface, but your
expression will evaluate at the full speed of a statically compiled function.
Is there any way to test whether the value of an argument to a template
function is known at compile time and specialize on this?
Doesn't all values to a template have to be known at compile time
Re: Specializing on Compile Time Constants
On 10/12/09 23:55, dsimcha wrote:
== Quote from Jacob Carlborg (d...@me.com)'s article
On 10/12/09 23:49, dsimcha wrote:
I'm working on a mathematical expression interpreter for D, which would allow
for closed form mathematical expressions to be specified as string literals at
runtime and be evaluated. For example:
MathExp myExpression = mathExp("x^2 + e^cos(-x) - 2 * sqrt(pi)", "x");
writeln(myExpression(2)); // Does exactly what you think it does.
I've found the syntax so convenient that I'd like to transparently specialize
it on strings known at compile time. The idea is that, when the expression is
hard-coded, you will still be able to use the MathExp interface, but your
expression will evaluate at the full speed of a statically compiled function.
Is there any way to test whether the value of an argument to a template
function is known at compile time and specialize on this?
Doesn't all values to a template have to be known at compile time
No, I mean the *function* parameters of a template function.
Can't you pass the values as template arguments? Seems you working with
strings (and numbers?). mathExp!("x^2 + e^cos(-x) - 2 * sqrt(pi)", "x");
Note the ! after the function name.
Re: Eliminate assert and lazy from D?
On 10/13/09 08:21, Andrei Alexandrescu wrote:
Frank Benoit wrote:
Andrei Alexandrescu schrieb:
Right now, the language has enough power to express assert as a library
function, as opposed to a primitive construct. (See e.g. enforce.) I
think it would be good to relegate assert to object.d.
This also brings up "lazy", which seems to be quite botched. Are there
suggestions on how to replicate its functionality in a different way? I
even seem to recall lazy was discussed as a disadvantage in the recent
dialog on reddit, see
http://www.reddit.com/r/programming/comments/9qf8i/i_wrote_some_d_today_and_its_completely_blowing/
I personally believe it's useful to be able to pass an unevaluated
expression into a function, for example assert and enforce themselves
use that.
But let's open this for discussion: should assert and/or lazy be
removed? If not, why not? It yes, why? How can we replicate their
functionality?
Andrei
I have seen lazy only used in its own show case. In log functions. In
Tango too it is used in log functions. I use delegates as function
parameters often, but not lazy. This is because I may add parameters and
on the caller site, IMO it must be obvious, this expression is not
evaluated as others. Maybe it is acceptable to remove lazy and write
logging statements with delegate and the curly braces.
log({ "bla bla "~info });
std.contracts.enforce also uses it.
A related issue with passing arguments, that i think needs a better
solution in D are the variadic arg list. No magic param names and the
possibility to pass this list - or a slice of it - to another function.
I'm hoping that template variadics + arrays of Variant cover all needs.
Andrei
Templates don't work as virtual methods. Arrays of variants will
probably not interact well with C variadic functions.
Re: Get name of alias parameter at compile time?
On 10/14/09 06:36, dsimcha wrote:
Is there a way to get the name of an alias parameter at compile time? For
example:
void doStuff() {
// Do stuff.
}
void templ(alias fun)() {
writeln(fun.stringof); // Prints doStuff.
}
Do you want that to print "fun" instead of "doStuff"?
Re: Get name of alias parameter at compile time?
On 10/15/09 17:55, dsimcha wrote:
== Quote from Lutger (lutger.blijdest...@gmail.com)'s article
Denis Koroskin wrote:
On Thu, 15 Oct 2009 18:22:37 +0400, dsimcha wrote:
Jacob Carlborg Wrote:
On 10/14/09 06:36, dsimcha wrote:
Is there a way to get the name of an alias parameter at compile
time? For
example:
void doStuff() {
// Do stuff.
}
void templ(alias fun)() {
writeln(fun.stringof); // Prints doStuff.
}
Do you want that to print "fun" instead of "doStuff"?
No, the whole point is that I want to print "doStuff".
What's the big deal?
import std.stdio;
void doStuff() {
}
void templ(alias fun)() {
writeln(fun.stringof); // prints "main()"
}
void main()
{
templ!(main);
}
Works for both D1 and D2
I was a bit surprised too since the code dsimcha posted did exactly that.
However, change void doStuff() to void doStuff(int a) and you got an error.
I remembered hacking around that one, if anybody knows how to do it better
it would be good to know:
void doStuff(int a)
{
// Do stuff.
}
void templ(T...)()
if (T.length==1)
{
writeln( T.stringof[6..$-1] );
}
void main()
{
templ!doStuff();
}
Yeah, now that I look into it further, what you describe is exactly the problem.
The obvious way only works for functions w/o parameters. I simplified my
example
before I posted it and never bothered to test it.
Oh, that problem. Just use a function pointer and get the name of that
instead, like this:
http://www.dsource.org/projects/dstep/browser/dstep/internal/Traits.d
(functionNameOf at line 17)
Re: Get name of alias parameter at compile time?
On 10/15/09 18:06, Lutger wrote:
dsimcha wrote:
Yeah, now that I look into it further, what you describe is exactly the
problem.
The obvious way only works for functions w/o parameters. I simplified my
example before I posted it and never bothered to test it.
See my reply to my reply (sorry!) for a better way to make it work.
It is because of this I think:
void foo() {}
void bar(int) {}
void main()
{
writeln(foo.stringof); // ok
writeln(bar.stringof); // error: not callable using argument types ()
writeln(bar(1).stringof); // ok
}
It should be doable to make a template for getting the proper name of any
aliased function I think.
See my reply to dsimcha
dmd support for IDEs and the D tool chain
Here is my thoughts and what I think is needed to build a really good IDE and maybe get some attention from the enterprise. It's really not enough for the compiler to output some json for an IDE to use, the whole tool chain needs to be revised. Compiler: * Written in D * Supports all major platform * 32 and 64bit support * Doesn't have annoying bugs like forward reference errors and problem with the linker * Built with and IDE in mind * Can be built as a (dynamic)library * Can build dynamic libraries * Supports incremental builds * Has clearly separate components, especially the front- and back-end. * Has a license that allows it to be built into an IDE and/or shipped with an IDE * Basically something like LLVM + Clang Compiler or separate tool: * Automatically tracks all dependencies and builds the application/library (like DSSS) GUI library: * Written in D * Supports all major platforms (mac, linux, win) * Uses native controls (as much as possible) to draw its controls * Supports (de)serializing controls (Glade, nib) IDE: * Written in D * Be able to show syntax and semantic errors as you type * Autocompletion * Refactoring * Building * Supports incremental builds * Basically something like Eclipse JDT GUI builder: * Supports (de)serializing controls (Glade, nib) * Basically something like Interface Builder, Glade All of the above would be the most optimal. For example, everything don't have to be built in D but for building an IDE in D I think that it would be easier. What we have now and what I think is the closest match: Compiler: LDC * Missing most of the mentioned things * Needs better platform support * At least the back-end is built like this We have DSSS and xfbuilder (or what it's called) GUI library: DWT * There are some bugs in the mac version * Doesn't support (de)serializing controls * Not built in a D-way * Maybe too heavy IDE: Descent * Missing some features like refactoring * Only supports building using an external tool * Needs to improve the syntax and semantic errors * Needs to improve the performance if possible GUI builder: Interface Builder, Entice Designer, Glade, whatever Qt uses * To my knowledge none of the above supports a GUI library like the one mentioned Any comments, thoughts? /Jacob Carlborg
Re: dmd support for IDEs and the D tool chain
On 10/16/09 12:58, Tomas Lindquist Olsen wrote: On Fri, Oct 16, 2009 at 12:06 PM, Jacob Carlborg wrote: Here is my thoughts and what I think is needed to build a really good IDE and maybe get some attention from the enterprise. It's really not enough for the compiler to output some json for an IDE to use, the whole tool chain needs to be revised. Compiler: * Written in D * Supports all major platform * 32 and 64bit support * Doesn't have annoying bugs like forward reference errors and problem with the linker * Built with and IDE in mind * Can be built as a (dynamic)library * Can build dynamic libraries * Supports incremental builds * Has clearly separate components, especially the front- and back-end. * Has a license that allows it to be built into an IDE and/or shipped with an IDE * Basically something like LLVM + Clang Compiler or separate tool: * Automatically tracks all dependencies and builds the application/library (like DSSS) GUI library: * Written in D * Supports all major platforms (mac, linux, win) * Uses native controls (as much as possible) to draw its controls * Supports (de)serializing controls (Glade, nib) IDE: * Written in D * Be able to show syntax and semantic errors as you type * Autocompletion * Refactoring * Building * Supports incremental builds * Basically something like Eclipse JDT GUI builder: * Supports (de)serializing controls (Glade, nib) * Basically something like Interface Builder, Glade All of the above would be the most optimal. For example, everything don't have to be built in D but for building an IDE in D I think that it would be easier. What we have now and what I think is the closest match: Compiler: LDC * Missing most of the mentioned things * Needs better platform support * At least the back-end is built like this We have DSSS and xfbuilder (or what it's called) GUI library: DWT * There are some bugs in the mac version * Doesn't support (de)serializing controls * Not built in a D-way * Maybe too heavy IDE: Descent * Missing some features like refactoring * Only supports building using an external tool * Needs to improve the syntax and semantic errors * Needs to improve the performance if possible GUI builder: Interface Builder, Entice Designer, Glade, whatever Qt uses * To my knowledge none of the above supports a GUI library like the one mentioned Any comments, thoughts? /Jacob Carlborg GtkD supports Glade. Yes, but GtkD doesn't use native controls.
Re: dmd support for IDEs and the D tool chain
On 10/16/09 13:03, digited wrote: Jacob Carlborg Wrote: IDE: Descent Poseidon + xfBuild may do the job (but Poseidon needs work to run on linux and mac). Eclipse itself is too heavy and too java's. I totally forgot about Poseidon. It has already been ported to the new DWT library, I don't know if it's complete and if it's running.
Re: dmd support for IDEs and the D tool chain
On 10/16/09 14:27, Denis Koroskin wrote: On Fri, 16 Oct 2009 16:20:31 +0400, Ary Borenszweig wrote: Denis Koroskin wrote: On Fri, 16 Oct 2009 14:06:59 +0400, Jacob Carlborg wrote: Here is my thoughts and what I think is needed to build a really good IDE and maybe get some attention from the enterprise. It's really not enough for the compiler to output some json for an IDE to use, the whole tool chain needs to be revised. Compiler: * Written in D * Supports all major platform * 32 and 64bit support * Doesn't have annoying bugs like forward reference errors and problem with the linker * Built with and IDE in mind * Can be built as a (dynamic)library * Can build dynamic libraries * Supports incremental builds * Has clearly separate components, especially the front- and back-end. * Has a license that allows it to be built into an IDE and/or shipped with an IDE * Basically something like LLVM + Clang Compiler or separate tool: * Automatically tracks all dependencies and builds the application/library (like DSSS) GUI library: * Written in D * Supports all major platforms (mac, linux, win) * Uses native controls (as much as possible) to draw its controls * Supports (de)serializing controls (Glade, nib) IDE: * Written in D * Be able to show syntax and semantic errors as you type * Autocompletion * Refactoring * Building * Supports incremental builds * Basically something like Eclipse JDT GUI builder: * Supports (de)serializing controls (Glade, nib) * Basically something like Interface Builder, Glade All of the above would be the most optimal. For example, everything don't have to be built in D but for building an IDE in D I think that it would be easier. I can't agree more. Everything you wrote is in my TODO list, starting with a compiler, which already compiles most of the druntime (and hopefully will compile it fully by the end of this week). I'll release it to public as soon as Brad creates a project page at dsource. Is it a port of DMD? Because I think the main problem with above is that the front-end is not very good... I think it has a lot of evolved code and starting from scratch might be a good idea. Yes, it's a DMD port. Unfortunately, there is no other mature D front-end at present. Other folks are working on D compilers (dil, dang, ...) but the progress is very slow. Let us know when it's available
Re: dmd support for IDEs and the D tool chain
On 10/16/09 19:18, Lutger wrote: Jacob Carlborg wrote: Here is my thoughts and what I think is needed to build a really good IDE and maybe get some attention from the enterprise. It's really not enough for the compiler to output some json for an IDE to use, the whole tool chain needs to be revised. I think this list is what the toolchain might look like after it already has gotten some attention, not a requirement of what is needed. This is a cut-down list with some comments: Compiler: * Supports all major platform * 32 and 64bit support * Doesn't have annoying bugs like forward reference errors and problem with the linker * Can build dynamic libraries * Supports incremental builds Clearly many programming languages manage without a compiler written in their native language and I doubt clang is even used in enterprise context. As I said later in the message, that it would be the optimal and everything doesn't have to be built in D. Like D Clang is quite new and it doesn't need to be built like Clang just to attract the enterprise but I think it would be easier to build an IDE if the compiler was built more like Clang. BTW Clang is shipped with the Developer Tools on Mac. Compiler or separate tool: * Automatically tracks all dependencies and builds the application/library (like DSSS) We got this, dsss just has to be revived by someone. GUI library: * Supports all major platforms (mac, linux, win) * Uses native controls (as much as possible) to draw its controls * Supports (de)serializing controls (Glade, nib) Not sure it needs to be written in D. Many languages use bindings and wrappers just fine. We already have QtD, DWT, wxWindows, DFL and GtkD. One of those is a port (DWT) and one is native D (DFL). The GUI situation has been so rapidly improved, it's not an impediment anymore imho. GtkD doesn't use native controls, DFL is only for windows (last I checked). IDE: * Be able to show syntax and semantic errors as you type * Autocompletion * Refactoring * Building * Supports incremental builds * Basically something like Eclipse JDT Descent is probably the closest, in some aspects it even destroys C++ IDE's (compile time stuff) already. However one or two more IDE's or very good editors would likely help. This would be my shortlist: - a polished descent which supports D2 - dmd switch to ELF on windows and support for 64-bit there - dsss redux - gdc for embedded, also some more support from phobos for systems programming?
Re: dmd support for IDEs and the D tool chain
On 10/17/09 00:23, Christopher Wright wrote: Jacob Carlborg wrote: On 10/16/09 12:58, Tomas Lindquist Olsen wrote: GtkD supports Glade. Yes, but GtkD doesn't use native controls. A minor point, I think. Eclipse doesn't look very native and has widespread acceptance. It depends on what you're looking at. The SWT philosophy is something like this: Use controls that are available as native controls on as many platforms as possible. For example, if a control is available as native on 3 out of 4 platforms, use the native on the 3 platforms and emulate it on the fourth. If a control is only native on 1 out of 4 platforms don't include it in SWT. SWT also has some custom (non-native) controls like the tabs used by Eclipse.
Re: dmd support for IDEs and the D tool chain
On 10/17/09 04:22, Eric Suen wrote: "Lutger" wrote Jacob Carlborg wrote: Here is my thoughts and what I think is needed to build a really good IDE and maybe get some attention from the enterprise. It's really not enough for the compiler to output some json for an IDE to use, the whole tool chain needs to be revised. I think this list is what the toolchain might look like after it already has gotten some attention, not a requirement of what is needed. This is a cut-down list with some comments: Compiler: * Supports all major platform * 32 and 64bit support * Doesn't have annoying bugs like forward reference errors and problem with the linker * Can build dynamic libraries * Supports incremental builds Clearly many programming languages manage without a compiler written in their native language and I doubt clang is even used in enterprise context. Because of many programming language is not design for speed, there is no point to write a compiler in there native language. Even Java's compiler is writtern in Java, why not D? Compiler bootstrapping is very basic technique, A large proportion of programming languages are bootstrapped. It is nosense to write D compiler in C, that means the D language author does not want to use D language. Does Walter Bright use D for any projects himself? Regards, Eric I think it says somewhere on the digitalmars site that there is not much gain in porting an existing project to D but all new projects will be in D. DMDScript (ECMA 262 also know as JavaScript) is written in D.
Re: dmd support for IDEs and the D tool chain
On 10/17/09 07:06, Nick Sabalausky wrote: "Christopher Wright" wrote in message news:hbarno$188...@digitalmars.com... Jacob Carlborg wrote: On 10/16/09 12:58, Tomas Lindquist Olsen wrote: GtkD supports Glade. Yes, but GtkD doesn't use native controls. A minor point, I think. Eclipse doesn't look very native and has widespread acceptance. Probably not as minor as it might seem. I find eclipse ugly. And although I'd never really thought about it before, I have to admit, I think it *is* one of the many factors as to why it's always felt too "bloated" for my tastes. Yes eclipse looks ugly. It's quite hard to create a GUI that looks good and native on all platforms (if you don't use separate GUIs). Besides, I can think of things (lots of things, in fact) that are pure steaming piles of (well, one can guess), but even despite that have still managed to gain widespread acceptance.
Re: dmd support for IDEs and the D tool chain
On 10/17/09 10:31, Eric Suen wrote: "Christopher Wright" wrote Jacob Carlborg wrote: On 10/16/09 12:58, Tomas Lindquist Olsen wrote: GtkD supports Glade. Yes, but GtkD doesn't use native controls. A minor point, I think. Eclipse doesn't look very native and has widespread acceptance. SWT wrap native controls, and Eclipse is build on SWT, but for an application like Eclipse, use system provide native controls is no enough, you have to write some custom control. Here is the problem, Java developers just unable to write good looking GUI components or applications using any library, neither Swing nor SWT. for examples, Swing is really powerful GUI frameworks, Java2D is quite powerful, and Swing is very flexible, but most Swing applications are really ugly. I think Azureus looks quite native and if they haven't changed anything they're using SWT. Eclipse doesn't look very native because they using ugly tab for layout, you can change that by provide your owner theme. more than 99% controls in Eclipse are native controls... There is the link of custom theme for Eclipse: http://www.agpad.com/images/ide_m.png Eric
Re: No header files?
On 10/23/09 05:08, AJ wrote: "BCS" wrote in message news:a6268ffbc7d8cc213dc5fee...@news.digitalmars.com... Hello aJ, "BCS" wrote in message news:a6268ffbc158cc2111f3e3b...@news.digitalmars.com... Hello aJ, You sound angry that your feature is not a fit for my development process. I think the frustration here is that you seem to be saying that you can't do something in D that you want to do but we have yet to figure out what it is. No, not at all. I realized far back in this thread that I can develop in D as I do now in C++ (header files come first). The thread went on with people trying to convince me how wrong that process is (?). I'm still not clear on exactly what you plan on doing. "Traditional" (read C/C++ like) software development. If you plan on generating the function prototypes Nope. I plan on hand-crafting header files before I create any implementation files. in a .d file and filling out the bodies later, go for it. Oh, by "generating" (bad choice of word), you meant "writing". Yes I do. If you plan on hand writing the .di file Ooops! No I don't! Yes, I will be "modeling" via header files. and then writing the implementation in a .d file... ah... that's a bad idea (for one there is no error checking between a .di file and the implementation file). Now you get what I was saying above! Yes? O! You mean that .di files are NOT like C++ header files. I think I see what you mean. Other people have told me I could work the same way I currently do in C++, but apparently, there is a big paradigm shift in the development model between C++ and D. I never even considered that D meant changing the process. Very, very good info I am getting here. Maybe I asked too soon about a D IDE, as I can't invest as much time (brainpower actually) as required to get my mind around the "whole smear" right now. I may just concentrate on select features of D for now (as I have been doing). I can't see why it's so important for your development process to have the declaration and implementation of classes and methods in separate files. If you want a person to develop the declaration and another to do the implementation why not just use a .d file and write the methods with empty bodies and then hand over the file to the person how will do the implementation?
Re: IDE for D? Recommendations?
On 10/23/09 04:58, AJ wrote: Anyone have recommendations for which IDE to use to do an evaluation of D with? I don't need powerful capabilities as I'm just looking to write some code and get a feel for some things in D. A bundle would be great. Also, I think it would be fun to look at the libraries during the eval. "Eval" is too strong... I just wanna play around with D a little bit in my spare time. If I can't be up an running in less than an hour, including any reading necessary to get set up, I'll have to save it for another time. I definitely don't want to be at a commandline prompt. All comments/recommendations/opinions welcomed. (Thanks in advance). I would recommend using Eclipse with Descent: http://www.dsource.org/projects/descent
ICE: template.c:806: failed assertion `i < parameters->dim'
I have quite a big project and when I compile it I get this internal compiler error: template.c:806: failed assertion `i < parameters->dim'. I don't know what could cause that error so I don't know where to look in my code to try to produce a small test case and report an issue. I'm using quite a lot of templates, template mixins and string mixins. I'm using dmd v1.045, I also get the same error with the latest ldc with this backtrace: Assertion failed: (i < parameters->dim), function deduceFunctionTemplateMatch, file /Users/doob/development/d/ldc/ldc/dmd/template.c, line 816. 0 ldc 0x00bea798 llvm::sys::RWMutexImpl::writer_release() + 312 1 ldc 0x00beb231 llvm::sys::RemoveFileOnSignal(llvm::sys::Path const&, std::string*) + 1393 2 libSystem.B.dylib 0x955072bb _sigtramp + 43 3 libSystem.B.dylib 0x _sigtramp + 1789889903 4 libSystem.B.dylib 0x9557b23a raise + 26 5 libSystem.B.dylib 0x95587679 abort + 73 6 libSystem.B.dylib 0x9557c3db __assert_rtn + 101 7 ldc 0x000a0911 TemplateDeclaration::deduceFunctionTemplateMatch(Loc, Objects*, Expression*, Expressions*, Objects*) + 2129 8 ldc 0x000a11fa TemplateDeclaration::deduceFunctionTemplate(Scope*, Loc, Objects*, Expression*, Expressions*, int) + 250 9 ldc 0x00041981 CallExp::semantic(Scope*) + 1009 10 ldc 0x000942f2 ReturnStatement::semantic(Scope*) + 386 11 ldc 0x0009146f CompoundStatement::semantic(Scope*) + 191 12 ldc 0x00048c83 FuncDeclaration::semantic3(Scope*) + 1875 13 ldc 0x0009a8b6 TemplateInstance::semantic3(Scope*) + 182 14 ldc 0x000a26c0 TemplateInstance::semantic(Scope*) + 1440 15 ldc 0x00042844 CallExp::semantic(Scope*) + 4788 16 ldc 0x000942f2 ReturnStatement::semantic(Scope*) + 386 17 ldc 0x0009146f CompoundStatement::semantic(Scope*) + 191 18 ldc 0x00048c83 FuncDeclaration::semantic3(Scope*) + 1875 19 ldc 0x7b81 AttribDeclaration::semantic3(Scope*) + 113 20 ldc 0x000979e6 AggregateDeclaration::semantic3(Scope*) + 150 21 ldc 0x00064886 Module::semantic3(Scope*) + 166 22 ldc 0x0010185f main + 4223 23 ldc 0x4036 start + 54 24 ldc 0x0011 start + 18446744073709535249
Re: ICE: template.c:806: failed assertion `i < parameters->dim'
On 10/28/09 16:32, Don wrote: Jacob Carlborg wrote: I have quite a big project and when I compile it I get this internal compiler error: template.c:806: failed assertion `i < parameters->dim'. I don't know what could cause that error so I don't know where to look in my code to try to produce a small test case and report an issue. I'm using quite a lot of templates, template mixins and string mixins. Bugzilla 2229. Was fixed in DMD1.049. There have been about 60 ICE bugs fixed since 1.045. I want to find out what the regressions are that are stopping people from using the latest DMD -- it's time for the ICE age to end. Thanks, I'll try the latest DMD.
Re: ICE: template.c:806: failed assertion `i < parameters->dim'
On 10/28/09 16:32, Don wrote: Jacob Carlborg wrote: I have quite a big project and when I compile it I get this internal compiler error: template.c:806: failed assertion `i < parameters->dim'. I don't know what could cause that error so I don't know where to look in my code to try to produce a small test case and report an issue. I'm using quite a lot of templates, template mixins and string mixins. Bugzilla 2229. Was fixed in DMD1.049. There have been about 60 ICE bugs fixed since 1.045. I want to find out what the regressions are that are stopping people from using the latest DMD -- it's time for the ICE age to end. I haven't been using any later version because of various known regressions, I think they've been solved know. I tried to compile Tango trunk with DMD trunk and it failed with: /Users/doob/development/d/tango-trunk/build/user/../../user/tango/io/compress/BzipStream.d(270): Error: var has no effect in expression (w) It's returning a value in a void function. I don't know if it's a regression that hasn't been solved or if it's something wrong with Tango.
Re: GC Precision
On 10/29/09 11:47, bearophile wrote: dsimcha: A moving GC, one that doesn't stop the world on collection, and one that's fully precise including stack would be nice, but they're several orders of magnitude less important and would also have more ripple effects. I agree that here doing something simple now is better than doing nothing or doing something very refined in an unknown future. And in future things may be improved. In D objects are always managed by reference, and I think that most programs don't alter or cast such references to something else (objects allocated on memory specified by the programmer, and scoped objects allocated on the stack may be excluded from this). So I think that it can be safe to move objects, to compact the heap. The current implementation of toHash in Object does that: return cast(hash_t)cast(void*)this; So you may have 5 memory zones: - C heap. (The type system of the D compiler may see the C-heap pointers and D-heap pointers as two different types, as I have proposed in the past. So you need casts if you want to mix them, and the compiler can use the D moving heap in a safer way). - Pinned D heap for everything can't be moved, like structs managed by pointers (eventually a D compiler can infer at compile time that some structs too may be moved around, because their pointer is used only in clean ways (you don't need to introduce struct references for this)). I think SafeD modules will not use this heap a lot (but they can use unsafe modules that may use pinned objects. Is D safety transitive? I think it is not, so from a SafeD module you can call and use an unsafe module); - Old object generation managed with compaction (I think there's no need for the permanent objects zone in D); - Two "from" and "to" zones for the young generation, that don't use a true compaction strategy, young objects bounce between them; - New generation Eden where new object allocations happen managed as a memory arena. All this has the disadvantage of requiring a more complex GC, and probably requiring 2-4 times more RAM at runtime. It hopefully has the advantage of allowing new programmers, that have learnt Java at university, to program in almost like in Java. (I have found a not-synthetic Java benchmark program that converted to D is something like 18 times slower on LDC. I'll put the code in my site in the following days). Bye, bearophile
Re: Success! (Precisely)
On 10/30/09 06:08, dsimcha wrote: After a few evenings of serious hacking, I've integrated precise heap scanning into the GC. Right now, I still need to test it better and debug it, but it at least basically works. I also still need to write the templates to generate bit masks at compile time, but this is a simple matter of programming. A few things: 1. Who knows how to write some good stress tests to make sure this works? 2. I'm thinking about how to write the bitmask templates. In the next release of DMD, when static arrays are value types and returnable from functions, will they be returnable from functions in CTFE? 3. new only takes RTTI. It is not a template. Unless RTTI gets bitmasks in the format I created (which I'll document once I clean things up and release, but has only deviated slightly from what I had talked about here), stuff allocated using it won't be able to take advantage of precise heap scanning. The default bitmask, if none is provided, uses good (bad) old-fashioned conservative scanning unless the entire block has no pointers, in which case it isn't scanned. This means that we have all the more incentive to replace new with a template of some kind. 4. I solved the static array problem, but the solution required using up one of the high-order bits. We have at least one more to play with in my bitmask scheme, because I'm storing things by word offsets, not byte offsets, since the GC isn't supposed to work with misaligned pointers anyhow. This leaves one more bit before we start limiting T.sizeof to less than full address space (on 32-bit, where a word is 4 bytes). I think it needs to be reserved for pinning, in case a copying collector ever gets implemented. If we're willing to not let any precisely scanned object have a T.sizeof of more than half the address space (a ridiculously minor limitation; this does not limit the size of arrays, only the size of classes and the elements of an array), we could throw in a third bit for weak references. Would this be possible to use with D1 ?
Re: Success! (Precisely)
On 10/30/09 14:29, dsimcha wrote: == Quote from Jacob Carlborg (d...@me.com)'s article On 10/30/09 06:08, dsimcha wrote: After a few evenings of serious hacking, I've integrated precise heap scanning into the GC. Right now, I still need to test it better and debug it, but it at least basically works. I also still need to write the templates to generate bit masks at compile time, but this is a simple matter of programming. A few things: 1. Who knows how to write some good stress tests to make sure this works? 2. I'm thinking about how to write the bitmask templates. In the next release of DMD, when static arrays are value types and returnable from functions, will they be returnable from functions in CTFE? 3. new only takes RTTI. It is not a template. Unless RTTI gets bitmasks in the format I created (which I'll document once I clean things up and release, but has only deviated slightly from what I had talked about here), stuff allocated using it won't be able to take advantage of precise heap scanning. The default bitmask, if none is provided, uses good (bad) old-fashioned conservative scanning unless the entire block has no pointers, in which case it isn't scanned. This means that we have all the more incentive to replace new with a template of some kind. 4. I solved the static array problem, but the solution required using up one of the high-order bits. We have at least one more to play with in my bitmask scheme, because I'm storing things by word offsets, not byte offsets, since the GC isn't supposed to work with misaligned pointers anyhow. This leaves one more bit before we start limiting T.sizeof to less than full address space (on 32-bit, where a word is 4 bytes). I think it needs to be reserved for pinning, in case a copying collector ever gets implemented. If we're willing to not let any precisely scanned object have a T.sizeof of more than half the address space (a ridiculously minor limitation; this does not limit the size of arrays, only the size of classes and the elements of an array), we could throw in a third bit for weak references. Would this be possible to use with D1 ? The precise heap scanning would probably work, if the bit masks were generated manually, but I don't know if D1's templates are powerful enough to generate them. I had D2 in mind as a target, but I'll document the format once everything's cleaned up, tested, etc. and if someone wants to try to make it work on D1, they can. The only thing, though, is that D1 is supposed to be stable, and adding bit masks as an argument o GC.malloc might not fly. Then again, it would only be a lib change, probably in Tango. Furthermore, I made old-fashioned conservative scanning the default (a bit mask called conservativeBitMask is stored in the static data segment and is the default argument to GC.malloc) specifically to avoid breaking any compatibility at the source level. Ok, well I didn't think phobos would change so I was think about the possibility to add this to tango. It seems it's mostly a runtime thing but I may be wrong.
Re: scope(exit) considered harmful
On 11/8/09 11:46, Justin Johansson wrote:
Long ago in the days before D, I was used to commenting out code with one of
two idioms:
#if false
.. this code is not compiled
#endif
or
if (false) {
.. this code is compiled but not executed
}
and to turn stuff back on again:
#if true
.. this code is back on now
#endif
or
if (true) {
.. this code is back on now too
}
but in the D world beware the Ides of Scopes because if your curly
brace block with the true/false conditional contains a scope(exit)
you will get explainable but unexpected behaviour if this code
is enabled inside an if(true) block.
Gotcha.
If scope(exit) is meant to be some mechanism for saving try/finally
boiler-plate code, it is a can of worms, otherwise it is a can of
i-dont-know-what-it's-good-for.
To my way of thinking, and no doubt I should go back to remedial CS-101,
semantics of scope(exit) should related to function scope and not
curly-brace scope-statement scope.
Whilst an experienced coder (C/C++) and well understand what's
happening here in D, I feel compelled to say that this would have
to be a nightmare come true for newcomers to D.
My advice, stick to try/catch/finally and avoid D scope(exit) et. al.
-- Justin Johansson
The translation of "#if" to D is "static if" which does not introduce a
new scope.
Re: D Kernel Development
On 11/12/09 04:32, Jesse Robinson wrote: Just for fun and as a serious learning exercise, I'm developing a hobby kernel of sorts (L4 microkernel inspired) and since it's my play project I was thinking of using D to implement it. I know it'll have to be written in a strict subset of D, as most of the runtime will need to be stripped out anyway. I've done some basic research, stumbled upon XOMB OS (a small exokernel project written in D) but wanted some thoughts from people who may have much more insight into the internals of D. So a few questions: What exactly are the language features I can use at such a lower level? I know OOP stuff is out (or is it?), dynamic arrays, GC, lazy functions, etcetera. So that leaves structs, CTFE, contract programming, mixins, templates, AST macros, basically any compile time features, correct? I'm sure there are a few others I'm missing. I've been lurking for awhile, and last time I checked there were three different compilers. LDC looks to be the most promising. What are peoples' thoughts / experiences with the latest version of LDC? How large is D2's runtime? Is it even worth the time and effort to strip down a custom runtime for kernel use in the first place? In general things need to be fairly lean, so executable size is a concern. Oh, and thanks in advance! -Jesse Looking at was in the runtime (D1): Associative arrays opApply for strings switch most array related things cast exceptions + other tings
Re: D library projects
On 11/12/09 22:02, Walter Bright wrote: dsimcha wrote: It would be truly great if Tango could be used under a license with permissiveness equivalent to the Boost license. It would help mend a pretty significant rift in the D community that started over a minor technicality. Sean did a lot of searching, and found that the Boost license was the most permissive, so Phobos was relicensed with the Boost license. If Tango could dual license with Boost, this would slam-dunk solve the licensing issues once and for all. I hope the Tango team will consider this. It's being discussed here: http://www.dsource.org/projects/tango/forums/topic/786#3407
Re: D library projects : adopting Boost license
On 11/13/09 11:11, Yigal Chripun wrote: Don wrote: Yigal Chripun wrote: Robert Jacques wrote: On Fri, 13 Nov 2009 01:08:03 -0500, Yigal Chripun wrote: Robert Jacques wrote: The Apache 2.0 license requires attribution. It's therefore unsuitable for a standard library. From the website FAQ: " It forbids you to: redistribute any piece of Apache-originated software without proper attribution; use any marks owned by The Apache Software Foundation in any way that might state or imply that the Foundation endorses your distribution; use any marks owned by The Apache Software Foundation in any way that might state or imply that you created the Apache software in question. It requires you to: include a copy of the license in any redistribution you may make that includes Apache software; provide clear attribution to The Apache Software Foundation for any distributions that include Apache software. " excerpts from http://www.apache.org/licenses/LICENSE-2.0.html "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: 1. You must give any other recipients of the Work or Derivative Works a copy of this License; and 2. You must cause any modified files to carry prominent notices stating that You changed the files; and 3. You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and /quote my understanding of the above is that using tango in your code doesn't constitute as "Derivative Works". that means that _uesrs_ of Tango are not required to provide attribution. First, according to international copyright law (Berne convention), compiling source code creates a derivative work. (See http://en.wikipedia.org/wiki/ISC_License for some links) Second, 4.1 explicitly require you to provide the license with all distributions. Third, Apache's FAQ, which was written by lawyers, instruct users to include the license/attribution. Finally, the linking divide, allows you link together code licensed under different licensees. I believe the GPL also has a similar clause. It doesn't mean that if you distribute a compiled copy of the library (either explicitly as a dll/so or by statically linking it in) you don't have to include the Apache license. You just don't have to license your application which uses Tango under the Apache license. There was a large discussion a while back about this, and essentially there are only 2 licenses suitable for a standard library: Boost and zlib/libpng (And technically WTFYW). Ok, I ain't a layer so let's see if I understood you correctly: You're saying that if I write code using Tango, I can license *my* code with whatever I want. My source will require a tango dll to work and *that* dll must come with its apache 2.0 license file. That sounds completely reasonable to me. I don't get what the problem with this scheme of things. At the present time, D DLLs don't work with D apps. Only static linking works. And disallowing static linking is utterly ridiculous, anyway. Conditions 2 and 3 above are no problem. I'm a bit scared of 1, though. What does "give" mean? (It's not even "make available"). Sounds as though EVERY D app (even "Hello, world" apps) would need to include a license file for the standard library. I agree, supplying the stdlib license file with a hello, world executable would be very bad. Generally speaking, is static linking of the stdlib the right thing? I realize that's the only working option now, but when this is fixed (and it really should be fixed) would that still be the correct choice for the stdlib? For C the obvious answer is dynamic linking because the target machine will (almost) always have the stdlib/runtime. For D I'm not sure, static linking allows stand alone applications.
Re: Serialization + semantics of toString
On 11/13/09 00:13, aarti_pl wrote:
Andrei Alexandrescu pisze:
> But that being said, I'd so much want to start thinking of an actual
> text serialization infrastructure. Why develop one later with the
> mention "well use that stuff for debugging only, this is the real
stuff."
>
> Andrei
You might want to see my serialization library for D.
I think that it is worth noting as it manages to achieve the goal:
same data - completely different output. Because this output might be
defined by user in the way she wants, it seems that this can work
exactly the way toString should work.
It is achieved by using Archive classes which makes proper formatting,
and which are completely independent from data being printed. Initial
design is based on C++ Boost. I just extended concept a bit and adopted
it to D.
Basic interface for serialization is like this:
auto serializer = Serializer!(TextArchive);
//It might be also e.g.:
//auto serializer = Serializer!(JsonArchive);
auto input = new TransparentClass(-21, 2.11, "text1", 128, -127);
auto output = serializer.dump(input);
assert(serializer.load!(TransparentClass)(output) == input);
In case of transparent classes (every field is public) you don't need
any method inside of serialized class/struct.
In case of opaque classes there is enough to:
1. add mixin inside:
mixin Serializable;
or
2. add template method:
void describeUdt(T)(T arch) {
arch.describeStaticArray(array, array.stringof);
}
Or you could use arhc.typeof[i] to access/set the values (even private)
of a struct/class.
This is all what is necessary to print every possible class/struct in
whatever format you want.
Because of limitations of D I couldn't achieve serialization of classes
from base pointer. It was because of fact that template methods are not
virtual.
Recently I didn't have time to work on it, but if you think it's worthy
and eventually might be included in Phobos, I would be interested to
work on it further. But I would definitely need some code/concepts review.
Unfortunately there is rather poor documentation. But you can find a lot
of unit tests in examples directory.
It's Boost licensed so no worries :-)
BR
Marcin Kuszczak
(aarti_pl)
Re: Serialization + semantics of toString
On 11/13/09 15:17, Denis Koroskin wrote:
On Fri, 13 Nov 2009 17:11:54 +0300, Jacob Carlborg wrote:
On 11/13/09 00:13, aarti_pl wrote:
Andrei Alexandrescu pisze:
> But that being said, I'd so much want to start thinking of an actual
> text serialization infrastructure. Why develop one later with the
> mention "well use that stuff for debugging only, this is the real
stuff."
>
> Andrei
You might want to see my serialization library for D.
I think that it is worth noting as it manages to achieve the goal:
same data - completely different output. Because this output might be
defined by user in the way she wants, it seems that this can work
exactly the way toString should work.
It is achieved by using Archive classes which makes proper formatting,
and which are completely independent from data being printed. Initial
design is based on C++ Boost. I just extended concept a bit and adopted
it to D.
Basic interface for serialization is like this:
auto serializer = Serializer!(TextArchive);
//It might be also e.g.:
//auto serializer = Serializer!(JsonArchive);
auto input = new TransparentClass(-21, 2.11, "text1", 128, -127);
auto output = serializer.dump(input);
assert(serializer.load!(TransparentClass)(output) == input);
In case of transparent classes (every field is public) you don't need
any method inside of serialized class/struct.
In case of opaque classes there is enough to:
1. add mixin inside:
mixin Serializable;
or
2. add template method:
void describeUdt(T)(T arch) {
arch.describeStaticArray(array, array.stringof);
}
Or you could use arhc.typeof[i] to access/set the values (even
private) of a struct/class.
You mean .tupleof? Just tested and it really works (wow!), didn't know
about that. Thanks!
Yes, tupleof
Re: Serialization + semantics of toString
On 11/13/09 16:03, aarti_pl wrote:
Jacob Carlborg Wrote:
On 11/13/09 00:13, aarti_pl wrote:
Andrei Alexandrescu pisze:
> But that being said, I'd so much want to start thinking of an actual
> text serialization infrastructure. Why develop one later with the
> mention "well use that stuff for debugging only, this is the real
stuff."
>
> Andrei
You might want to see my serialization library for D.
I think that it is worth noting as it manages to achieve the goal:
same data - completely different output. Because this output might be
defined by user in the way she wants, it seems that this can work
exactly the way toString should work.
It is achieved by using Archive classes which makes proper formatting,
and which are completely independent from data being printed. Initial
design is based on C++ Boost. I just extended concept a bit and adopted
it to D.
Basic interface for serialization is like this:
auto serializer = Serializer!(TextArchive);
//It might be also e.g.:
//auto serializer = Serializer!(JsonArchive);
auto input = new TransparentClass(-21, 2.11, "text1", 128, -127);
auto output = serializer.dump(input);
assert(serializer.load!(TransparentClass)(output) == input);
In case of transparent classes (every field is public) you don't need
any method inside of serialized class/struct.
In case of opaque classes there is enough to:
1. add mixin inside:
mixin Serializable;
or
2. add template method:
void describeUdt(T)(T arch) {
arch.describeStaticArray(array, array.stringof);
}
Or you could use arhc.typeof[i] to access/set the values (even private)
of a struct/class.
It works exactly this way. In D1 it was not possible to access private members
with tupleof[], so there was a need for describe(). But even in D2 I think that
describe() should stay as it gives more flexibility for user.
It wasn't? When was that added? It works for me using gdc based on dmd
somewhere between 1.024 and 1.030.
Re: Developing a browser (Firefox) extension with D
On 11/18/09 05:03, Justin Johansson wrote: I'm just wondering for a moment if D might be a good vehicle for developing a browser extension for Firefox, or any other browser for that matter. Has anyone either considered doing, or has actually done, any browser extension development with D and have some thoughts or experience to share? Thanks for all feedback, Justin Johansson I think someone tried to do (or did) an extension for internet explorer using DWT.
Overload on opDispatch ?
Would it be a good idea to allow overloading on opDispatch to make the
following compile, what do you think?
import std.stdio;
class C
{
void opDispatch(string s, ARGS...) (ARGS args)
{
writefln("S.opDispatch('%s', %s)", s, typeof(args).stringof);
}
void foo (string s)
{
writeln("in asd");
}
}
void main()
{
C c = new C;
c.foo("bar"); // calls C.foo
c.foo("bar", "bar"); // calls C.opDispatch
c.foo(3); // calls C.opDispatch
}
Re: D2 GUI Libs
On 12/13/09 20:44, Eldar Insafutdinov wrote:
Nick Sabalausky Wrote:
"Nick Sabalausky" wrote in message
news:hg394f$mr...@digitalmars.com...
"Eldar Insafutdinov" wrote in message
news:hg2p87$2tt...@digitalmars.com...
1) You may know the concept of signals and slots in Qt. Consider the
following snippet:
class Test : QObject
{
mixin Signal!("signal_1(string)");
mixin Slot!("slot_1(string str)");
void slot_1(string str)
{
writefln("slot_1 invoked with ~ " str);
}
mixin Q_OBJECT;
}
In Qt objects, that inherit from QObject are capable of having signals
and slots and participate in connections. In the current scheme mixins of
Signal and Slot template mix some static information into the class. The
class is then scanned when Q_OBJECT template is mixed in and the proper
meta-information is generated to register signals and slots in the Qt
type system.
As you see, this declaration is a bit ugly. In particular defining a slot
requires to duplicate its signature in a mixin. What would really be
awesome is a mechanism allowing something like:
@Slot
void slot_1(string str)
{
writefln("slot_1 invoked with " ~ str);
}
I.e we need annotations. But I am not sure how this will work. One of the
possible solutions will be that @Slot expands into mixin Slot!(symbol,
AnnotationArg1, ...).
Oops, slight typo:
Try string mixins, something like this:
1. Rename Slot to _Slot.
2. Do this:
// Fixed:
template Slot(string decl, string body)
{
const string Slot = "
mixin _Slot!("~decl.stringof~");
void slot_1(string str)
{
"~body.stringof~"
}
";
}
class Test : QObject
{
mixin Signal!("signal_1(string)");
mixin( Slot!("slot_1(string str)", q{
writefln("slot_1 invoked with ~ " str);
}) );
mixin Q_OBJECT;
}
Thank you for suggestion, but while reducing redundancy it became even uglier!
I'll better stay with the current syntax.
To make it look a little better you can do like this:
template Slot (ReturnType, alias method, ARGS...)
{
// code
}
template Slot (alias method)
{
mixin Slot!(ReturnType!(method), method, ParameterTypeTuple!(method));
}
If the method is overloaded, use the first version, otherwise use the
second. Use them like this:
class Test : QObject
{
mixin Slot!(slot_1);
void slot_1(string str)
{
writefln("slot_1 invoked with ~ " str);
}
mixin Q_OBJECT;
}
Re: D2 GUI Libs
On 12/14/09 20:29, Jacob Carlborg wrote:
On 12/13/09 20:44, Eldar Insafutdinov wrote:
Nick Sabalausky Wrote:
"Nick Sabalausky" wrote in message
news:hg394f$mr...@digitalmars.com...
"Eldar Insafutdinov" wrote in message
news:hg2p87$2tt...@digitalmars.com...
1) You may know the concept of signals and slots in Qt. Consider the
following snippet:
class Test : QObject
{
mixin Signal!("signal_1(string)");
mixin Slot!("slot_1(string str)");
void slot_1(string str)
{
writefln("slot_1 invoked with ~ " str);
}
mixin Q_OBJECT;
}
In Qt objects, that inherit from QObject are capable of having signals
and slots and participate in connections. In the current scheme
mixins of
Signal and Slot template mix some static information into the
class. The
class is then scanned when Q_OBJECT template is mixed in and the
proper
meta-information is generated to register signals and slots in the Qt
type system.
As you see, this declaration is a bit ugly. In particular defining
a slot
requires to duplicate its signature in a mixin. What would really be
awesome is a mechanism allowing something like:
@Slot
void slot_1(string str)
{
writefln("slot_1 invoked with " ~ str);
}
I.e we need annotations. But I am not sure how this will work. One
of the
possible solutions will be that @Slot expands into mixin Slot!(symbol,
AnnotationArg1, ...).
Oops, slight typo:
Try string mixins, something like this:
1. Rename Slot to _Slot.
2. Do this:
// Fixed:
template Slot(string decl, string body)
{
const string Slot = "
mixin _Slot!("~decl.stringof~");
void slot_1(string str)
{
"~body.stringof~"
}
";
}
class Test : QObject
{
mixin Signal!("signal_1(string)");
mixin( Slot!("slot_1(string str)", q{
writefln("slot_1 invoked with ~ " str);
}) );
mixin Q_OBJECT;
}
Thank you for suggestion, but while reducing redundancy it became even
uglier! I'll better stay with the current syntax.
To make it look a little better you can do like this:
template Slot (ReturnType, alias method, ARGS...)
{
// code
}
template Slot (alias method)
{
mixin Slot!(ReturnType!(method), method, ParameterTypeTuple!(method));
}
If the method is overloaded, use the first version, otherwise use the
second. Use them like this:
class Test : QObject
{
mixin Slot!(slot_1);
void slot_1(string str)
{
writefln("slot_1 invoked with ~ " str);
}
mixin Q_OBJECT;
}
ReturnType and ParameterTypeTuple are available in std.traits, in Tango
they're in tango.core.Traits under slightly different names.
Re: Windows multi-threading performance issues on multi-core systems only
On 12/16/09 03:44, Michel Fortin wrote:
On 2009-12-15 19:49:43 -0500, dsimcha said:
== Quote from Simen kjaeraas (simen.kja...@gmail.com)'s article
Tested this on a Core 2 Duo, same options. OS is Windows 7, 64bit. It
scales roughly inverse linearly with number of threads:
163ms for 1,
364ms for 2,
886ms for 4
This is quite different from your numbers, though.
Yea, forgot to mention my numbers were on Win XP. Maybe Windows 7
critical
sections are better implemented or something. Can a few other people
with a
variety of OS's run this benchmark and post their numbers?
Core 2 Duo / Mac OS X 10.6 / 4 threads:
Crystal:~ mifo$ ./test
Set affinity, then press enter.
Bus error
Runs for about 18 seconds, then crashes. At first glance, it looks as if
the Thread class is broken and for some reason I get a null dereference
when a thread finishes. Great!
Anyway, I've done some sampling on the program while it runs, and each
of the worker thread spans about 85% of its time inside _d_monitorenter
and 11% in _d_monitorleave soon after starting the program, which later
becomes 88% and 7% respectively soon before the program finishes.
The funny things is that if I just bypass the GC like this:
void doAppending() {
uint* arr = null;
foreach(i; 0..1_000_000) {
arr = cast(uint*)realloc(arr, (uint*).sizeof * (i+1));
arr[i] = i;
}
// leak arr
}
it finishes (I mean crashes) in less than half a second. So it looks
like realloc does a much better job at locking it's data structure that
the GC.
It runs fine on Mac OS X 10.5 with dmd 2.037.
Re: D+Ubuntu+SDL_image said undefined reference
On 12/30/09 04:14, alisue wrote: Trass3r Wrote: Michael P. schrieb: How come you are not using something like rebuild or DSSS? don't forget xfBuild ;) Well... Because I haven't heard about them. I knew 'rebuild' and 'DSSS' but I thought it might be too old (For Mac OS X 10.4 I use Mac OS X 10.6 and Most of time when I try to use package for Mac OS X 10.4 they doesn't take a effort) DSSS works with Mac OS X 10.5 at lest. So I just decide to use Ant(for now using Makefile but in future) and build all of .d file in src directory and manually link to lib. I knew it stupid but could't find the way. What is the best way to do it. Is DSSS not too old? or xfBuild P.S. Well... Where can I find some tutorial things? I found some but too old and can't compile. P.S. Derelict... seem good I'll try.
opDispatch with template parameter and property syntax doesn't work
The following doesn't work, is it a known issue or should I report it.
class C
{
void opDispatch (string str, T) (T t) {}
}
class D
{
void opDispatch (string str) (int t) {}
}
C c = new C;
c.foo = 3; // doesn't work
c.foo(3); // works
D d = new D;
d.foo = 3; // works
Re: Compiler: Size of generated executable file
On 1/12/10 23:40, Walter Bright wrote: Steven Schveighoffer wrote: I hope this is not a permanent situation. Shared libraries (not necessarily DLLs) help reduce the memory usage of all the programs on the system that use the same libraries, and the footprint of the binaries. That would be reasonable once we can get libphobos installed on linux distributions. Right now, it's easier for users to not have to deal with version hell for shared libraries. Static linking of phobos does not impair using D, so it is a lower priority. The "DLL hell" versioning problem AFAIK is only on Windows, My experience is different. There are two C shared libraries in common use on Linux. If I link dmd to one, one group of dmd users gets annoyed, if I link with the other, the other half gets annoyed. There's no decent solution. My understanding of the "no shared library" problem of D was not that it was an anti-dll-hell feature but actually an unsolved problem with sharing the GC. If you are saying that even if someone solves the GC sharing problem that D still will produce mostly static exes, you might as well take D out back and shoot it now. I don't see any businesses using a language that is 15 years behind the curve in library production. If it were a problem that couldn't be solved, then there would be lots of languages that have that problem. It's true that nobody has spent the effort to do this. Anyone is welcome to step up and work on it. Hasn't that already been solved with ddl: http://www.dsource.org/projects/ddl/ On all your other points, I agree that installs these days are bigger more because of media than binaries. I do have a problem with that in some cases. I don't want my scanner driver software to install 500MB of crap that I will never use when all I want to do is scan documents with a simple interface. I don't need "skins" for my word processor or help videos on how to use my mouse. Just install the shit that does the work, and leave the rest of my hard drive alone :) Heh, dlls won't solve that problem. I upgraded Nero to support a new dvd drive, and what the heck, a 20Mb install turned into - 360Mb !!
Re: Compiler: Size of generated executable file
On 1/12/10 22:31, Steven Schveighoffer wrote: On Mon, 11 Jan 2010 22:24:06 -0500, Walter Bright wrote: Other languages do appear to have smaller executables, but that's often because the runtime library is dynamically linked, not statically linked, and is not counted as part of the executable size even though it is loaded into memory to be run. D's runtime library is still statically linked in for the pragmatic reason that static linking avoids the "dll hell" versioning problem for your customers. I hope this is not a permanent situation. Shared libraries (not necessarily DLLs) help reduce the memory usage of all the programs on the system that use the same libraries, and the footprint of the binaries. The "DLL hell" versioning problem AFAIK is only on Windows, and has nothing to do with using dlls, it has everything to do with retarded installers that think they are in charge of putting shared DLLs into your system directory (fostered by the very loose directory security model of Windows to begin with). My understanding of the "no shared library" problem of D was not that it was an anti-dll-hell feature but actually an unsolved problem with sharing the GC. If you are saying that even if someone solves the GC sharing problem that D still will produce mostly static exes, you might as well take D out back and shoot it now. I don't see any businesses using a language that is 15 years behind the curve in library production. If it were a problem that couldn't be solved, then there would be lots of languages that have that problem. Hasn't that already been solved with ddl: http://www.dsource.org/projects/ddl/ On all your other points, I agree that installs these days are bigger more because of media than binaries. I do have a problem with that in some cases. I don't want my scanner driver software to install 500MB of crap that I will never use when all I want to do is scan documents with a simple interface. I don't need "skins" for my word processor or help videos on how to use my mouse. Just install the shit that does the work, and leave the rest of my hard drive alone :) -Steve
Re: What's left to do for a stable D2?
On 1/22/10 17:21, Andrei Alexandrescu wrote:
Jason House wrote:
Jesse Phillips Wrote:
Jason House wrote:
Andrei's finishing his last TDPL chapter, Sean is updating
std.thread(?), and Walter's been fixing forward reference and CTFE
bugs. What's left?
This page[1] has been getting regular updates, so it should do a good
job answering the question.
1. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections
I believe most "future directions" will be D3 or beyond. I'm pretty
certain that Andrei wants TDPL to match D2. All but one chapter has
been written, and TDPL related bugs have gotten priority. There should
be very few feature changes between now and D2 finalization.
Andrei, Walter, Sean, can you comment?
You mean the list "Known D2.0, Language"? Here's what I think (Walter is
the ultimate go-to person):
# Operator overloading: opBinary!("+"), opUnary!("--"),
opIndexAssign!("*").
D2
# opDollar ( Bugzilla:3474).
D2
# Move complex and imaginary types from language into std.complex.
D2
# Fix the array stomping issue (T[new] was one proposal for this).
We have a design that partially resolves it. Steve Schveighoffer has
implemented it.
# Remove C-style declarations.
I don't think they'll be removed, but TDPL doesn't mention them.
# Remove typedef.
D2
# Remove struct initializers.
Dunno
# Remove floating point NCEG operators
D2
# Remove "length" from array index expressions ( Bugzilla:3474).
Dunno. Hope so! TDPL won't mention it, so it's real bad if the feature
stays,
Andrei
What about the uniform function call syntax ?
Re: What's left to do for a stable D2?
On 1/23/10 18:50, Andrei Alexandrescu wrote:
Jacob Carlborg wrote:
On 1/22/10 17:21, Andrei Alexandrescu wrote:
Jason House wrote:
Jesse Phillips Wrote:
Jason House wrote:
Andrei's finishing his last TDPL chapter, Sean is updating
std.thread(?), and Walter's been fixing forward reference and CTFE
bugs. What's left?
This page[1] has been getting regular updates, so it should do a good
job answering the question.
1.
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections
I believe most "future directions" will be D3 or beyond. I'm pretty
certain that Andrei wants TDPL to match D2. All but one chapter has
been written, and TDPL related bugs have gotten priority. There should
be very few feature changes between now and D2 finalization.
Andrei, Walter, Sean, can you comment?
You mean the list "Known D2.0, Language"? Here's what I think (Walter is
the ultimate go-to person):
# Operator overloading: opBinary!("+"), opUnary!("--"),
opIndexAssign!("*").
D2
# opDollar ( Bugzilla:3474).
D2
# Move complex and imaginary types from language into std.complex.
D2
# Fix the array stomping issue (T[new] was one proposal for this).
We have a design that partially resolves it. Steve Schveighoffer has
implemented it.
# Remove C-style declarations.
I don't think they'll be removed, but TDPL doesn't mention them.
# Remove typedef.
D2
# Remove struct initializers.
Dunno
# Remove floating point NCEG operators
D2
# Remove "length" from array index expressions ( Bugzilla:3474).
Dunno. Hope so! TDPL won't mention it, so it's real bad if the feature
stays,
Andrei
What about the uniform function call syntax ?
Far as I know it's already in, with bugs.
Andrei
I've not seen it being mentioned at all and I can't get it to work:
void foo (Object o) { }
void main ()
{
Object o = new Object;
o.foo();
}
Compiling the above with dmd trunk results in:
main.d(8): Error: no property 'foo' for type 'object.Object'
Looking at
http://www.dsource.org/projects/dmd/browser/trunk/src/expression.c#L6483
it seems it's not implemented.
Re: std.string will get the boot
On 1/29/10 18:36, Andrei Alexandrescu wrote: I plan a few improvements to Phobos that will improve string handling. Currently arrays of characters count as random-access ranges, which is not true for arrays of char and wchar. I plan to make std.range aware of that and only characterize char[] and wchar[] (and their qualified versions) as bidirectional ranges. Also, std.range will define s.front and s.back for strings to return the correctly decoded dchar. Naturally, s.popFront and s.popBack will yank an entire encoded character, which is what you want most of the time anyway. (You're still free to do s = s[1 .. $] if that's what you need.) These changes will have the great effect of enabling std.algorithm to work with strings correctly without any further impedance adaptation. (At some point I'd defined byDchar to wrap a string as a bidirectional range; it works, but of course it's much better without an intermediary.) Following that change, I plan to eliminate std.string entirely and roll all of its functionality into std.algorithm. This is because I noticed that I'd like many string functions to be available for other data types, and also because people who want to define their own non-UTF encodings can benefit of the support that UTF already has. I would keep std.string for string specific functions and perhaps publicly import std.algorithm. For exmaple functions like: tolower, icmp and toStringz. (As an example, startsWith or endsWith are very useful not only with strings, but general data as well.) A possible idea would be to move algorithms out of std.string and roll std.utf and std.encoding into std.string. That way std.string becomes something UTF-specific, which may be sensible. One problem I foresee is the growth of std.algorithm. It already has many things in it, and I fear that some user who just wants to trim a string may find it intimidating to browse through all that documentation. I wonder how we could break std.algorithm into smaller units (which is an issue largely independent from generalizing the algorithms now found in std.string). Perhaps it's time to start adding more packages than just the std. Make std.algorithm a package and try to split it into several modules. Any ideas are welcome. Andrei
Re: std.string will get the boot
On 1/29/10 22:18, Ali Çehreli wrote: Jacob Carlborg wrote: > I would keep std.string for string specific functions and perhaps > publicly import std.algorithm. For exmaple functions like: tolower, icmp > and toStringz. I've been thinking about characters lately and have realized that tolower, toupper, icmp, and friends should not be in a string library. Those functions need an "alphabet" to be useful; not language, nor locale... In fact, the character itself must have alphabet information. Otherwise a string like "ali & jim" cannot be converted to upper-case correctly(*) as "ALİ & JIM". And the word "correctly" there depends on each character's alphabet. Similarly, two characters that look the same cannot be compared for ordering. Comparing the 'x' of one alphabet to the 'x' of another alphabet is a meaningless operation. Ali I'm not sure I really understand this, probably because I don't know much about how Unciode works. I'm thinking out loud: If "i", as you have in "ali", have the corresponding "İ" as upper case wouldn't that be another character than the English "i"? If so, I'm not sure I see the problem. If not, I see the problem.
I'm getting a Bus Error with dmd 1.056
With some code I compile I get a Bus Error with dmd 1.056 on Mac OS X 10.5.7. Running dmd through gdb I get this output: Program received signal SIGTRAP, Trace/breakpoint trap. 0x8fe01010 in __dyld__dyld_start () (gdb) bt #0 0x8fe01010 in __dyld__dyld_start () Cannot access memory at address 0x4 I don't have a small test case (yet). The last version I know for sure that works is dmd 1.052 with a patch to make it work on Mac OS X 10.5. I'm using tango BTW, if it matters. Does anyone have any idea what can be wrong?
Re: Array operation for computing the dot product?
On 2/6/10 01:25, retard wrote:
Fri, 05 Feb 2010 16:03:22 -0800, Walter Bright wrote:
retard wrote:
Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:
retard wrote:
{protection-attr} == perhaps one of these
{public|protected|package|
private} - I have no effing clue what this does
It actually does the same thing as it does in C++ (with the addition
of package).
I see. I only noticed now that dmd actually does enforce this rule in
some cases. Unfortunately the rule is checked only statically when it
can be checked. If you access the object via base class or interface
type reference, a runtime check is not made unlike in c++.
There must be some misunderstanding here. There are no runtime access
checks in C++, it is all done statically at compile time.
Thanks. It seems I have been testing this with a buggy c++ compiler or
can't remember what was the problem previously. I now tried with gcc
4.4.3 and this is how D and C++ differ:
---
class Foo {
public:
void bar() {}
};
class Bar : private Foo {
};
int main() {
Foo *a = new Bar();
a->bar();
}
test.cpp: In function ‘int main()’:
test.cpp:10: error: ‘Foo’ is an inaccessible base of ‘Bar’
---
module m1;
class Foo {
public void bar() {}
}
class Bar : private foo {
}
module m2;
import m1;
void main() {
Foo a = new Bar();
a.bar();
}
// compiles and runs just fine
// Changing the 'Foo a = ...' into 'Bar a = ...' makes this an error
Is there any use to make the base class non public in D? I mean you will
also make the Object part inaccessible. Another thing to remove in D2?
Function with try/catch and no return statement
The following code does not cause a compile error:
int foo ()
{
try
int i;
catch (Exception)
throw new Exception("");
}
Wouldn't it be quite obvious for the compiler to see that there is no
return statement in the above function and give a compile error? The
same also happens with scope(failure).
Mac OS X 10.5.7 dmd 1.056.
Re: Function with try/catch and no return statement
On 2/6/10 16:19, Don wrote:
Jacob Carlborg wrote:
The following code does not cause a compile error:
int foo ()
{
try
int i;
catch (Exception)
throw new Exception("");
}
Wouldn't it be quite obvious for the compiler to see that there is no
return statement in the above function and give a compile error? The
same also happens with scope(failure).
Mac OS X 10.5.7 dmd 1.056.
It gives an error for me on Windows when compiled with -w. If it doesn't
on Mac, that's definitely a bug.
I does give an error if I compile with -w, but I think it should be an
error even without -w.
Re: "The last feature": overridable methods in interfaces
On 2/8/10 06:37, Andrei Alexandrescu wrote:
Walter has now implemented final methods in interfaces and also
contracts in interfaces, both of which I think are just awesome.
We figured that essentially he artificially disallows interfaces from
providing bodies for methods. I think that's a gratuitous limitation;
the only distinguishing quality of an interface is that it has no state.
Other than that, interfaces can always offer overridable functions that
by default offer functionality in terms of existing interface functions.
For example:
interface Stack(T)
{
void push(T);
void pop();
@property ref T top();
@property bool empty();
T belowTop()
{
auto t = top;
pop();
auto result = top;
push(t);
}
}
The default implementation of belowTop does a fair amount of work. A
particular implementation might just use that or override it with a more
efficient implementation.
Many more examples can be imagined, but I'm looking for a killer one, or
perhaps a killer counterexample (e.g. when would an interface-defined
method be really bad?)
Your thoughts welcome.
Andrei
I only see two differences with abstract classes: interfaces can't have
instance (and class?) variables and you can inherit from multiple
interfaces. Am I missing something? Is this really necessary? Isn't
abstract classes enough? Does this have similar problems (or the same)
as multiple inheritance?
/Jacob Carlborg
Re: "The last feature": scope structs
On 2/8/10 11:05, Walter Bright wrote: Lars T. Kyllingstad wrote: Though the feature seems useful, I worry about the asymmetry with scope classes. I think it will be very confusing to new D programmers that a scope class and a scope struct have very little to do with each other. I agree, except I more and more think that scope classes were a mistake. Structs with destructors are a much better solution, and wrapping a class inside a struct would give it RAII semantics. Scope class seems like a workaround in D1 because it doesn't got structs with constructors and destructors. If scope classes are up for removal shouldn't struct constructors be fixed to allow to do the same as class constructors? For example, allow empty parameter lists. /Jacob Carlborg
Re: "The last feature": overridable methods in interfaces
On 2/8/10 14:03, Andrei Alexandrescu wrote:
Jacob Carlborg wrote:
On 2/8/10 06:37, Andrei Alexandrescu wrote:
Walter has now implemented final methods in interfaces and also
contracts in interfaces, both of which I think are just awesome.
We figured that essentially he artificially disallows interfaces from
providing bodies for methods. I think that's a gratuitous limitation;
the only distinguishing quality of an interface is that it has no state.
Other than that, interfaces can always offer overridable functions that
by default offer functionality in terms of existing interface functions.
For example:
interface Stack(T)
{
void push(T);
void pop();
@property ref T top();
@property bool empty();
T belowTop()
{
auto t = top;
pop();
auto result = top;
push(t);
}
}
The default implementation of belowTop does a fair amount of work. A
particular implementation might just use that or override it with a more
efficient implementation.
Many more examples can be imagined, but I'm looking for a killer one, or
perhaps a killer counterexample (e.g. when would an interface-defined
method be really bad?)
Your thoughts welcome.
Andrei
I only see two differences with abstract classes: interfaces can't
have instance (and class?) variables and you can inherit from multiple
interfaces. Am I missing something? Is this really necessary? Isn't
abstract classes enough? Does this have similar problems (or the same)
as multiple inheritance?
I think lack of state is indeed the only difference. The multiple
inheritance bit makes all the difference, so I think abstract classes
are not enough. A designer who wants to define some methods in an
interface is forced at design time to choose an abstract class over an
interface, thus severely limiting clients.
Andrei
The obvious solution as I see it would have been using "regular"
interfaces and template mixins. But that fails since the mixed in
methods can't overload on the already present methods.
Have traits (http://en.wikipedia.org/wiki/Trait_%28computer_science%29)
ever been considered?
Re: A special treat
On 2/9/10 16:53, Steve Teale wrote: When D2 is 'frozen', as a special treat would it be possible for it to be able to generate object files that could be converted into shared libraries, and for Phobos to be a shared library to support same. I have tried every which way I can think of to create shared libraries using D. The closest I have come is with the old 1.030 GDC, and even with that there are problems. I've tried to describe the current situation in some detail on the blog section of myGDC-newbie page. It is too long to post on the newsgroup. The inability to do this is a real show-stopper for D on Linux, and unless things have got better since I last tried, the same can be said for Windows DLLs. Please! Steve I've compiled a couple of libraries as shared/dynamic libraries (including tango) using gdc on Mac OS X. I can't remeber I had any problems.
