Re: DCD: Autocomplete without the IDE
On 2013-09-07 13:23, David wrote: I wrote the Kate/Kwrite/Kdevelop Plugin. I recommend you to let the server running all the time anyways (start it with X e.g.), since processing phobos alone takes quite some time. If you power up the editor you don't wanna wait a few minutes until DCD is done and can answer the requests. Also, if you start multiple sessions, you want only one server running (the K* Plugin won't start multiple servers anyways because it has a fixed port). Ok. As long as there won't be any conflicts or extra processing of files not used. -- /Jacob Carlborg
Re: new DIP47: Outlining member functions of aggregates
On Saturday, 7 September 2013 at 17:00:08 UTC, Walter Bright wrote: Outlining of member functions is the practice of placing the declaration of a member function in the struct/class/union, and placing the definition of it at global scope in the module or even in another module. http://wiki.dlang.org/DIP47 Parameter names need not match. I can't wait to implement a static code analysis rule that yells at people for not having them match. If there is a default parameter value, it may only appear in the member function declaration. Shouldn't they match? @safe/@trusted/@system, private/package/public/export access, linkage and storage classes are as set in the declaration, overriding any in effect for the definition. Again. Someone will create a static code analysis tool that warns about this. Why allow it in the language?
Re: DIP45: fixing the dllimport/dllexport issue
On 07.09.2013 14:47, Benjamin Thaut wrote: I propose that we add a command-line-paramter to the compiler (windows only) which actually enables dllexport. So all behavior described in the DIP will be enabled by default, but to actually make it mark symbols with dllexport you have to specifiy a additional command-line-parameter. We could call it -dll or something. I don't think the issue is Windows specific, symbol visibility in the GNU toolchain is also bound to the declaration. I remember seeing public (visibility=default) symbols exported from static libraries on OSX.
Re: new DIP47: Outlining member functions of aggregates
On 08/09/13 15:40, Walter Bright wrote: On 9/7/2013 9:46 PM, Jonathan M Davis wrote: On an implementation note, I don't think that #5 is strong enough. I think that it should be an outright error if there is a difference between the declaration and definition rather than giving one precedence over the other. I'll point out that C++ has equivalent behavior, and it has not resulted in any complaints I've ever heard. When you outline a C++ member function, you do not need to add 'static', 'private', 'virtual', and in fact you cannot add the latter two. Here's one. It's one of the things that I don't like about C/C++ as it doubles the work required in code maintenance. One of the things that I like about D is that forward references aren't required and this seems to me to be introducing a feature that was only ever in C/C++ to make forward references possible (which is why I tolerated it). In summary, you've gotten rid of the need for this type of duplication so why would you introduce it? Peter
Re: new DIP47: Outlining member functions of aggregates
Am 08.09.2013 07:48, schrieb Iain Buclaw:
On Sep 8, 2013 5:55 AM, dennis luehring dl.so...@gmx.net wrote:
Am 07.09.2013 19:00, schrieb Walter Bright:
Outlining of member functions is the practice of placing the declaration
of a
member function in the struct/class/union, and placing the definition of
it at
global scope in the module or even in another module.
http://wiki.dlang.org/DIP47
Parameter names need not match.
please don't do this - that will nearly kill any easy way of finding the
implementation,
That depends on your coding style and is not necessarily true. Eg: I put
function names at the start of the line.
int
foo_bar ()
{
}
So all global functions are easily grep'able ('^foo_bar').
Same thing is also done with C++ outlined members ('^Class::foo_bar') and I
could see myself adopting the same for D aggregate methods too.
Regards
im talking about Parameter names need not match.
so it will become hard to find the same overload of a method if someone
else writes int a, int b in declaration and int pa, int pb in
implementation - and the only benefit is beeing compatible with c/c++ -
that will introduce another point in all D-coding-style guides around
the world not to rename parameter in implementation
Re: new DIP47: Outlining member functions of aggregates
On Sunday, 8 September 2013 at 04:32:36 UTC, Daniel Murphy wrote: Walter Bright newshou...@digitalmars.com wrote in message news:l0fm2o$2uat$1...@digitalmars.com... Outlining of member functions is the practice of placing the declaration of a member function in the struct/class/union, and placing the definition of it at global scope in the module or even in another module. http://wiki.dlang.org/DIP47 I am strongly opposed to this DIP. I think it brings a little slice of C++ hell to D. This change will result in manually-synchronized duplication. The argument that IDEs can deal with this automatically is irrelevant, because they currently can't and are unlikely to do so any time soon. The main motivation for this seems to be that you can't get a clear overview of a class from looking at the raw source code. I propose a much simpler solution to this: ** Introduce compiler-checked (via warnings) class summary documentation. ** This solves the problem - an overview of the class is available in the raw source code, and enabling the warning will prevent them from getting out of sync. Let's solve a documentation issue with documentation improvements. This generated documentation solution seems like the best approach.
Re: new DIP47: Outlining member functions of aggregates
On 8 September 2013 07:14, dennis luehring dl.so...@gmx.net wrote:
Am 08.09.2013 07:48, schrieb Iain Buclaw:
On Sep 8, 2013 5:55 AM, dennis luehring dl.so...@gmx.net wrote:
Am 07.09.2013 19:00, schrieb Walter Bright:
Outlining of member functions is the practice of placing the declaration
of a
member function in the struct/class/union, and placing the definition of
it at
global scope in the module or even in another module.
http://wiki.dlang.org/DIP47
Parameter names need not match.
please don't do this - that will nearly kill any easy way of finding the
implementation,
That depends on your coding style and is not necessarily true. Eg: I put
function names at the start of the line.
int
foo_bar ()
{
}
So all global functions are easily grep'able ('^foo_bar').
Same thing is also done with C++ outlined members ('^Class::foo_bar') and
I
could see myself adopting the same for D aggregate methods too.
Regards
im talking about Parameter names need not match.
so it will become hard to find the same overload of a method if someone else
writes int a, int b in declaration and int pa, int pb in implementation -
and the only benefit is beeing compatible with c/c++ - that will introduce
another point in all D-coding-style guides around the world not to rename
parameter in implementation
I was talking about Parameter names need not match too... I disagree
that mismatched parameter names makes things hard to find, and by way
of example, I just search for the function. I never say right, I
need to find this implementation and grep for the parameter list in
the declaration...
Regards
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
Re: new DIP47: Outlining member functions of aggregates
On 9/7/2013 11:08 PM, Peter Williams wrote: In summary, you've gotten rid of the need for this type of duplication so why would you introduce it? I believe that is covered in the Rationale section of the dip.
Re: Enum alias members: yay or nay?
On Sunday, September 08, 2013 14:45:21 Daniel Murphy wrote:
Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message
news:mailman.980.1378598947.1719.digitalmar...@puremagic.com...
enum MouseAction
{
press,
release,
alias click = press, // does not reset the counter!
double_click, // equals release + 1
}
Does the alias member feature pull its weight? Or is it overkill and
we should drop it?
Honestly, it seems like overkill to me.
I can understand it would be an annoying bug to hit, but I doubt it would be
that common.
Two strategies that will prevent this bug are:
1) Put the 'alias' members directly after the member they reference
2) Put the 'alias' members at the end
Agreed. Both of those easily avoid this problem, and I would have argued that
the examples which ran into this problem were bad practice precisely because
they didn't do either of these two. Personally, I would argue that an enum
that is intended to be have the same value as another should pretty much
always be listed right after the one it shares a value with.
- Jonathan M Davis
Re: DIP45: fixing the dllimport/dllexport issue
Am 08.09.2013 06:19, schrieb deadalnix: On Saturday, 7 September 2013 at 21:41:01 UTC, Benjamin Thaut wrote: I don't agree if that statement. If you have three libs. lib1, lib2 and lib3. And lib2 and lib3 link statically against lib1 you are going to get linker errors because both lib2 and lib3 contain the symbols of lib1. And you don't have any options to avoid that (unless you got into the source of lib1 and remove all export attributes, which might not even be possible because you don't have the source) And you should have an error, especially is you pass object from one side to the other. typeid won't match (which will create a mess in the runtime), and worse, struct layout may not match (hello memory corruption). If the problem is that big, we can still have a -noexport flag or something, but that doesn't seems really safe to me. But only assuming that you are passing around objects of that type. I see a dll as a module of encapsulation. If the library is only unsed internally nothing of its dependencies should get exported. Because if they are your users might rely on the fact that they are, and from that point on you have to garantuee that all those additional exported functions from your dependencies stay in your library, even if you don't need the dependency anymore.
Re: DIP45: fixing the dllimport/dllexport issue
Am 27.08.2013 12:12, schrieb Benjamin Thaut: The current behaviour of export is not sufficient to create a shared runtime on windows. Its alos not working very well in a few other cases. For background information please read the links provided in the DIP. This DIP tries to solve the problem by imitating the proven preprocessor techniques used in C/C++ to create windows dlls. Destroy. Kind Regards Benjamin Thaut There is yet another problem to be solved. What should happen with tempaltes? Does it make sense to export templates? What happens if a template class marked with export gets instanciated in different DLLs using the same template arguments? Should the TypeInfo objects match? Should templates be exportable in generall? In C++ the only thing I needed so far was exporting static members of templated classes. So the different instances of the template can work on the same data. Kind Regards Benjamin Thaut
Re: DIP45: fixing the dllimport/dllexport issue
Am 08.09.2013 09:33, schrieb Benjamin Thaut: Am 27.08.2013 12:12, schrieb Benjamin Thaut: The current behaviour of export is not sufficient to create a shared runtime on windows. Its alos not working very well in a few other cases. For background information please read the links provided in the DIP. This DIP tries to solve the problem by imitating the proven preprocessor techniques used in C/C++ to create windows dlls. Destroy. Kind Regards Benjamin Thaut There is yet another problem to be solved. What should happen with tempaltes? Does it make sense to export templates? What happens if a template class marked with export gets instanciated in different DLLs using the same template arguments? Should the TypeInfo objects match? Should templates be exportable in generall? In C++ the only thing I needed so far was exporting static members of templated classes. So the different instances of the template can work on the same data. Kind Regards Benjamin Thaut Good question. Not sure how Ada, Modula-3, Eiffel, Delphi, MLton solve the issue, even though their generic capabilities are not as powerfull. -- Paulo
Re: Enum alias members: yay or nay?
On 9/8/13 8:08, Andrej Mitrovic wrote:
I've recently ran into a bug that was very hard to track down for me.
I've had a good set of unittests, but I kept getting the wrong results
out of my functions, which was very bizarre.
To boil it down, when you introduce a member in an enum which
initializes itself to another member of that enum, the next member
after it will be initialized to + 1 of the previous member. So:
enum E
{
a,
b = a,
c
}
Here, a equals 0, b equals 0 as well, and c equals b + 1, so it's 1.
There's nothing problematic here.
The real problem appears when you need to make sure each member is
unique, except for any members which are either convenience members or
are deprecated members (there's no deprecated member feature
yet[2]).
Here's an example:
enum MouseAction
{
///
press,
///
release,
/** Convenience - equal to $(D press). */
click = press,
///
double_click,
}
Notice how introducing the convenience member has re-set the enum
initializer counter, meaning double_click will be equal to (click +
1), which is really (press + 1), which becomes (1). But (1) is also
the intializer for release, so by mistake I made double_click
equal release, and hence my bug.
So to work around this, I thought about introducing an alias feature to enums:
enum MouseAction
{
press,
release,
alias click = press, // does not reset the counter!
double_click, // equals release + 1
}
The alias member would not re-set the counter and instead the next
non-alias member would initialize itself to the previous non-alias
member + 1.
This would also lend itself well with the deprecated keyword, where
we could add deprecated aliases for old enum members when we want to
rename the members. For example, if you want to rename a Phobos enum
you can currently do :
enum SpanMode
{
shallow,
deep,
depth = deep; /// $(RED Deprecated, please use .deep)
breadth,
}
I won't deny the possibility of human error here, but I don't think it's
worth complicating the language for this case. It's easily fixed by
putting the 'alias' after the 'good' enum value.
The case for 'deprecate' is much stronger, though. It's impossible to
deprecate enum values now.
Re: new DIP47: Outlining member functions of aggregates
Am 08.09.2013 08:46, schrieb Iain Buclaw: im talking about Parameter names need not match. so it will become hard to find the same overload of a method if someone else writes int a, int b in declaration and int pa, int pb in implementation - and the only benefit is beeing compatible with c/c++ - that will introduce another point in all D-coding-style guides around the world not to rename parameter in implementation I was talking about Parameter names need not match too... I disagree that mismatched parameter names makes things hard to find, and by way of example, I just search for the function. I never say right, I need to find this implementation and grep for the parameter list in the declaration... i work as a independed refactorig/bug hunter developer on big team (30+ developers) big projects (1Mio LOC+) - i need to do that most of the time - i like D for beeing better refactorable/readable in the long run (years) of projects different people - different needs
Re: new DIP47: Outlining member functions of aggregates
On Sunday, 8 September 2013 at 06:47:14 UTC, Walter Bright wrote: On 9/7/2013 11:08 PM, Peter Williams wrote: In summary, you've gotten rid of the need for this type of duplication so why would you introduce it? I believe that is covered in the Rationale section of the dip. IMHO the rationale of the proposal il pretty weak: - You can't have a 1:1 correspondence with translated C++ code, so the translation barrier can be lower. - You can't read _easily_ the code. The first is not a problem, if it is true that D avoidance of duplication is better than C++ way of doing that stuff (and that's a C++ problem, as Peter suggested). I would also add that I don't think at all that this is a concrete translation barrier: usually I start copying and pasting the C++ header in the D code, and then filling the methods translating from the cpp part one after another. The second point is more subtle, as we are talking about an easy _navigation_ in the code in the editor, we are talking about being able to gain a sense of familiarity with foreign code? The former is something that should not impact over the language at all (alas, C++ navigation, back and forth between header and implementation is a mess), The latter resolved by D with DDOC, which it is perfectible BUT is _today_ a wonderful tool for strangers: the D library section on DLang site is there to prove it. You have at a glance all the definitions, documented and in sync with the last compilation. What is missing from that? - Paolo Invernizzi
Re: Move VisualD to github/d-programming-language ?
On Saturday, 7 September 2013 at 23:31:20 UTC, Walter Bright wrote: On 9/7/2013 4:22 PM, Flamaros wrote: I hope to see MonoD on github/d-programming-language too if it's the case of VisualD. MonoD is definitely a contender for that. But let's take a moment to digest VisualD before we overreach! Mono-D is an amazing piece of software, with a first-class parser and suggestion engine. But the most valuable part of the project is Alexander Bothe, a tireless enhancer of the product and a person very responsive to user problems that may arise now and then... Strongly advised - Paolo Invernizzi
Re: new DIP47: Outlining member functions of aggregates
I'm against it. More important than such a gimmick are the many open bugs, auto ref, AA, scope, etc. And don't forget the implementation of the virtual keyword.
Re: Move VisualD to github/d-programming-language ?
On Sunday, 8 September 2013 at 01:53:02 UTC, Jonathan M Davis wrote: I have no problem with it, though since I'm not likely to ever use it or contribute to it, I'm not sure that I particularly care one way or the other. I have no problem with people using IDEs and they can be nice, but I'm always a bit stumped by how important many people think they are and how they don't seem to think that they can function without them. People can function without them, they just choose not to :-) Put it this way: when I code in D, I regularly have to look up documentation to find out what functions are available and what arguments a function has. I don't think I've ever done that in C++ or C# using Visual Studio. And don't get me started on the debugging experience.
Re: new DIP47: Outlining member functions of aggregates
On Sunday, 8 September 2013 at 09:15:52 UTC, Namespace wrote: I'm against it. More important than such a gimmick are the many open bugs, auto ref, AA, scope, etc. And don't forget the implementation of the virtual keyword. +1
Re: Enum alias members: yay or nay?
2013/9/8 Jonathan M Davis jmdavisp...@gmx.com On Sunday, September 08, 2013 14:45:21 Daniel Murphy wrote: Honestly, it seems like overkill to me. I can understand it would be an annoying bug to hit, but I doubt it would be that common. Agreed. I also agree that the compiler enhancement is overkill. Kenji Hara
Re: Enum alias members: yay or nay?
On Sunday, 8 September 2013 at 09:43:02 UTC, Kenji Hara wrote:
I also agree that the compiler enhancement is overkill.
Kenji Hara
Let's not throw this away quite yet: There is *another*
fundamental difference:
enum S
{
a,
b = a,
}
This creates an enum with *two* entries.
enum S
{
a,
alias b = a,
}
This would create an enum with a *single* entry, which can be
accessed via two different names.
*This*, in itself, I think is a good idea. It helps distinguish
between an enum that has multiple entries, some of which have
the same values and an enum whose entry 'a' can also be refered
to as 'b', fo rconvenience.
For starters, the distinction would be self documenting.
Second, once you involve things like `EnumMembers`, it becomes a
pretty interesting distinction to make.
I for one support this proposal (but not necessarilly for the
counter proposal: I think it is a nice plus, but not an
essential feature).
Re: Merge pull request #593 from dawgfoto/dynamicLoading
Most awesome
Re: new DIP47: Outlining member functions of aggregates
On Sunday, 8 September 2013 at 09:24:52 UTC, Michael wrote: On Sunday, 8 September 2013 at 09:15:52 UTC, Namespace wrote: I'm against it. More important than such a gimmick are the many open bugs, auto ref, AA, scope, etc. And don't forget the implementation of the virtual keyword. +1 I strongly dislike DIP47, I found many unintended discrepancies in our C code-base at work... precisely because of lax rules, even cases with wrong linkage as result! Parameter names need not match. If there is a default parameter value, it may only appear in the member function declaration. This forces indexing of source and jump to declaration features in the IDE, the current way is more friendly to simpler text-editors, the problem which DIP47 is trying to solve is anyway solved by IDE:s Class View feature etc. i.e. For people using IDE:s(class view, or ddoc) nothing changes with DIP47. For people using plain editors, DIP47 makes it worse. Even if DIP47 is implemented, I hope this feature is strongly discouraged in the standard library.
Re: D Lang Socket Programming Example
On Friday, 6 September 2013 at 21:02:09 UTC, Ali Çehreli wrote:
On 09/06/2013 01:47 PM, Savsak wrote:
Hi Friends,
Socket programming with the D programming language is the
most simple
way how to do it
For example, the sample with Tango, but not by phobos
How do I do this with a simple, but phobos
import tango.io.Stdout;
import tango.net.Socket;
import tango.net.ServerSocket;
import tango.net.SocketConduit;
int main() {
Socket server = new Socket(AddressFamily.UNIX,
SocketType.STREAM,
ProtocolType.IP);
while(true) {
Socket client = server.accept();
char[1024] buffer;
client.receive(buffer);
Stdout.format(The client said'{}'., buffer);
client.shutdown(SocketShutdown.BOTH);
client.detach();
}
return 0;
}
Here is a Phobos translation:
import std.stdio;
import std.socket;
void main() {
Socket server = new TcpSocket();
server.setOption(SocketOptionLevel.SOCKET,
SocketOption.REUSEADDR, true);
server.bind(new InternetAddress(8080));
server.listen(1);
while(true) {
Socket client = server.accept();
char[1024] buffer;
auto received = client.receive(buffer);
writefln(The client said:\n%s, buffer[0.. received]);
enum header =
HTTP/1.0 200 OK\nContent-Type: text/html;
charset=utf-8\n\n;
string response = header ~ Hello World!\n;
client.send(response);
client.shutdown(SocketShutdown.BOTH);
client.close();
}
}
Ali
P.S. Note that there is also the D.learn newsgroup.
P.P.S. This question came up on two separate Turkish D forums
recently:
http://ddili.org/forum/post/10063
http://forum.ceviz.net/d-dili/127048-ddili-socket-okuma-veri-gonderme-quotnon-blocking-i-oquot.html
Thanks acehreli
In the example you give, but I receive this error during
compilation.
savsak:~ savsak$ dmd /Users/savsak/Desktop/test.d
ld: library not found for -lphobos2
collect2: ld returned 1 exit status
--- errorlevel 1
slice based on base and width
I find myself writing the following a lot: a[base..base+width] to get the slice starting at 'base' of width 'width'. In verilog, we select members of a vector/array in three ways a[c : d] //D: a[c .. d+1] a[c +: d] //D: a[c .. c+d] a[c -: d] //D: a[c-d .. c] Borrowing a bit from verilog, could we make two new operators, maybe +.. and -.. that allow us to do the same? I could then write e.g. a[base+..width] instead of the more verbose a[base..base+width]
Re: Move VisualD to github/d-programming-language ?
On 08/09/13 06:26, Paul Jurczak wrote: Right on target. If D wants to achieve some level of visibility for Windows C++ developers, Visual Studio presence is crucial. We are talking about a huge chunk of market share here! Disclosure: I have to use Visual Studio in work for my clients. I don't. :-) I used Visual Studio for a couple of years, about 10 years ago -- these days I work with vim and the Linux command line. But there's no sense in not recognizing the importance of Visual Studio as a software development tool.
Re: new DIP47: Outlining member functions of aggregates
Wouldn't this style be an acceptable compromise instead? with
both declaration and definition 100% identical.
struct S
{
// member function declarations
static int mfunc1(int a, int b = 5) pure;
static int mfunc2(int a, int b = 5) pure;
static int mfunc3(int a, int b = 5) pure;
// member function definitions
static int mfunc1(int a, int b = 5) pure
{
}
static int mfunc2(int a, int b = 5) pure
{
}
static int mfunc3(int a, int b = 5) pure
{
}
}
Re: slice based on base and width
a[c -: d] //D: a[c-d .. c] I think this should be a[c -: d] //D: a[c-d+1 .. c+1], e.g. a[5 -: 2] == [a[4], a[5]]
dmd2 mac os x compilation problem
Hi Friends,
dmd2 files downloaded at this address.
I took the files to the destination directory in this way.
/usr/dmd2
/usr/dmd2/bin
/usr/dmd2/lib
/usr/dmd2/man
/usr/dmd2/src
edited config file.
[Environment]
DFLAGS=-I/usr/dmd2/src/phobos -I/usr/dmd2/src/druntime/import
-L/usr/dmd2/lib
A simple example code.
import std.stdio;
void main()
{
writeln(Hello World);
}
Giving this error when I want to compile.
ld: library not found for -lphobos2
collect2: ld returned 1 exit status
--- errorlevel 1
needed to do to solve this problem?
.dmg file in the destination directory and the installation does
not want to set up.
sincerely.
Re: new DIP47: Outlining member functions of aggregates
On 09/08/2013 06:46 AM, Jonathan M Davis wrote: If I had to vote though, I'd vote against this, because I think that it's a bad paradigm, and I don't want to deal with it. +1
Re: new DIP47: Outlining member functions of aggregates
08-Sep-2013 09:00, Jonathan M Davis пишет: On Saturday, September 07, 2013 10:00:05 Walter Bright wrote: Outlining of member functions is the practice of placing the declaration of a member function in the struct/class/union, and placing the definition of it at global scope in the module or even in another module. http://wiki.dlang.org/DIP47 Actually, for those who really want this sort of thing, why don't they just use .di files? At that point, you're doing basically the same thing that C++ does anyway (which is part of why I hate .di files). What benefit over that do we really get by adding this feature? And speaking of IDEs, they easily grow a simple feature - press some short-cut and it would display what dmd -H of the current file looks like. No need to bend the language backwards. - Jonathan M Davis -- Dmitry Olshansky
Re: new DIP47: Outlining member functions of aggregates
On Sunday, 8 September 2013 at 10:59:34 UTC, Robert Schadek wrote:
On 09/08/2013 06:46 AM, Jonathan M Davis wrote:
If I had to vote though, I'd vote against this, because I
think that
it's a bad paradigm, and I don't want to deal with it.
+1
+1
Also issues mentioned by Manu are easily solvable:
DI files and/or DDOC + remove one level of indentation after
class:
---
class Foo
{
void foo()
{
writeln(hello world);
}
}
---
;)
Re: Move VisualD to github/d-programming-language ?
On Sun, 2013-09-08 at 00:35 +0200, Paulo Pinto wrote: […] Well, if you want a production quality multi-platform IDE the only options are InteliJ and Eclipse, both of which are not that well received by most C and C++ guys. The target audience for D. That is my humble opinion, regarding the type of tooling I expect from an IDE. Or write a D specific platform IDE? LiteIDE for Go is really, rather good, and way better than the Go mode for Eclipse. Similar things happen in Python-land. Eclipse/Pydev or strip down Aptana; ItelliJ IDEA or strip down PyCharm are fine, but Wing IDE 101 and Ninja IDEA are actually better. Sadly, it seems that one IDE all languages is an inferior solution to one language one IDE. And why is the target audience for D only C and C++ people? Surely the target audience for D is any programmer wanting a native code executable. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Move VisualD to github/d-programming-language ?
Am 08.09.2013 13:24, schrieb Russel Winder: On Sun, 2013-09-08 at 00:35 +0200, Paulo Pinto wrote: […] And why is the target audience for D only C and C++ people? Surely the target audience for D is any programmer wanting a native code executable. Because many of us are actually aware of compilers that produce native code for our languages, even if they are not the default way to use them. To make it more clear, the ML family of languages, Pascal family of languages, even JVM and .NET environments have native compilers available. You just have to look for them. Additionally anyone that could move to more productive languages already did. So it only remains the C and C++ developers, that either by religion or lack of alternatives, are stuck in their world. The ones that are stuck by religion, will eventually disappear, given enough time. So we are left with the ones that cannot move on due to lack of alternatives, hardware constraints or whatever the issue might be. -- Paulo
Re: Move VisualD to github/d-programming-language ?
On 08/09/13 13:24, Russel Winder wrote: And why is the target audience for D only C and C++ people? Surely the target audience for D is any programmer wanting a native code executable. They're not the _only_ target audience but they're surely the _main_ target audience. Users of higher-level languages have presumably made the choice that systems-level performance is not their priority. That said, I think there's a clear case for D to be made to people who currently have an Other language plus C toolchain. I love D for the fact that it lets you use the high-level constructions of languages like Python but you can also drill down to systems level to optimize performance _without changing language_.
Re: dmd2 mac os x compilation problem
On 9/8/13 18:56, Batuhan Göksu batuhango...@gmail.com wrote:
Hi Friends,
dmd2 files downloaded at this address.
I took the files to the destination directory in this way.
/usr/dmd2
/usr/dmd2/bin
/usr/dmd2/lib
/usr/dmd2/man
/usr/dmd2/src
edited config file.
[Environment]
DFLAGS=-I/usr/dmd2/src/phobos -I/usr/dmd2/src/druntime/import
-L/usr/dmd2/lib
A simple example code.
import std.stdio;
void main()
{
writeln(Hello World);
}
Giving this error when I want to compile.
ld: library not found for -lphobos2
collect2: ld returned 1 exit status
--- errorlevel 1
needed to do to solve this problem?
.dmg file in the destination directory and the installation does not
want to set up.
sincerely.
Can you try with -m64? You might only have the 64-bit phobos library.
L.
Re: Move VisualD to github/d-programming-language ?
On Sunday, 8 September 2013 at 11:24:32 UTC, Russel Winder wrote: And why is the target audience for D only C and C++ people? Surely the target audience for D is any programmer wanting a native code executable. I think that D visibility isn't enough for the moment to be able to convince Java or C# dev to take a look in. Those developers that build work oriented applications certainly also wait for much bigger frameworks than phobos in this actual state. The c++ developers are used to develop a lot of thing from scratch and use tiny libraries for specifics things. It will certainly take years before seeing much developers coming from Java or C# to D.
Re: dmd2 mac os x compilation problem
On Sun, 08 Sep 2013 12:56:09 +0200 Batuhan Göksu batuhango...@gmail.com wrote: [Environment] DFLAGS=-I/usr/dmd2/src/phobos -I/usr/dmd2/src/druntime/import -L/usr/dmd2/lib I'm not on Posix ATM, but I think that last arg is supposed to be: -L-L/usr/dmd2/lib
Re: slice based on base and width
On Sunday, 8 September 2013 at 10:53:23 UTC, Øivind wrote: a[c -: d] //D: a[c-d .. c] I think this should be a[c -: d] //D: a[c-d+1 .. c+1], e.g. a[5 -: 2] == [a[4], a[5]] try a[base][0..width]
Re: new DIP47: Outlining member functions of aggregates
On 2013-09-07 17:00:05 +, Walter Bright newshou...@digitalmars.com said:
Outlining of member functions is the practice of placing the
declaration of a member function in the struct/class/union, and placing
the definition of it at global scope in the module or even in another
module.
http://wiki.dlang.org/DIP47
About placing the definition in another module, you say that the
definition when outlined in another module would have private access to
the private members of the module of declaration. Does that mean that
the definition has access to the private members of two modules at the
same time, the one it is declared in and the one it is defined in? That
seems strange to me.
I find it strange that pure/const/immutable/shared/nothrow need to
match, yet static does not. Beside this being the way it works in C++
(presumably because static at global scope has another meaning
inherited from C), I see no reason for this. In C++ I often find myself
wondering whether a function has access to the member variables and I
have to find the definition in the header file, which is inconvenient.
Static being part of the definition seems to only make sense.
About parameter names, I think it'd be better if they were forced to
match. Mismatches are a code smell to me: if you reverse the meaning of
two parameters with the same type while refactoring, you must be sure
the public interface and the implementation still agree. I guess you
could allow the declaration to omit the parameter names in which case
the definition could add a name, but don't allow *different* names,
it's pointless and it can easily hide a bug.
I think it's fine that default values for parameters don't have to be
repeated, but it'd be nice if they *could* because it enables
copy-pasting of the declarations. The compiler would of course have to
check that both expressions are identical.
I'd like to make a suggestion. If one goal is effectively to allow the
implementation of a function to live in a separate file from its
declaration, then we already have a mechanism for that: .di files. So
I'd like to suggest this: allow a .d file to import its corresponding
.di file. Then the .d file should only contain the missing definitions
for what's declared in the hand-crafted .di file. That'd remove the
dubious semantics of making the definition part of another module and
would also allow outlining of global functions. And it also matches
better the C++ model of header/implementation files.
Also, I'd allow outlining only for this specific case where a .di file
is imported by a .d file. This way you know for sure when you see a
declaration without the definition in a .di file that this declaration
is in the corresponding .d file and not anywhere else, making it easier
to hunt it down.
Example:
// test.di
module test;
class A {
void foo(int a, int b);
}
// test.d
import module test; // import declarations from the .di file
void A.foo(int a, int b) {
// member function definition
}
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
Re: slice based on base and width
On 2013-09-08, 14:02, Chang Long wrote: On Sunday, 8 September 2013 at 10:53:23 UTC, Øivind wrote: a[c -: d] //D: a[c-d .. c] I think this should be a[c -: d] //D: a[c-d+1 .. c+1], e.g. a[5 -: 2] == [a[4], a[5]] try a[base][0..width] That throws safety out the window for one. If you want safety and no new language features, this should work: a[base..$][0..width] -- Simen
Re: dmd2 mac os x compilation problem
On Sunday, 8 September 2013 at 12:00:22 UTC, Nick Sabalausky wrote: On Sun, 08 Sep 2013 12:56:09 +0200 Batuhan Göksu batuhango...@gmail.com wrote: [Environment] DFLAGS=-I/usr/dmd2/src/phobos -I/usr/dmd2/src/druntime/import -L/usr/dmd2/lib I'm not on Posix ATM, but I think that last arg is supposed to be: -L-L/usr/dmd2/lib Yes, it should be -L-L (double checked right now in my OS X). - Paolo
Re: new DIP47: Outlining member functions of aggregates
On 9/8/13, Michel Fortin michel.for...@michelf.ca wrote: So I'd like to suggest this: allow a .d file to import its corresponding .di file. This is actually what Andrei proposed as well.
Re: dmd2 mac os x compilation problem
On Sunday, 8 September 2013 at 10:56:11 UTC, Batuhan Göksu wrote: .dmg file in the destination directory and the installation does not want to set up. What errors do you get using the installer? - /Jacob Carlborg
Re: Enum alias members: yay or nay?
On 9/8/13, Daniel Murphy yebbl...@nospamgmail.com wrote: Two strategies that will prevent this bug are: 1) Put the 'alias' members directly after the member they reference 2) Put the 'alias' members at the end There is another strategy, which I currently use, is to explicitly initialize all enums. As for #1 or #2, that won't work for me, because I want the alias to be in a location that makes sense in the documentation, this is why click is right above double_click, triple_click, etc.
Re: Enum alias members: yay or nay?
On 9/8/13, monarch_dodra monarchdo...@gmail.com wrote:
enum S
{
a,
alias b = a,
}
This would create an enum with a *single* entry, which can be
accessed via two different names.
Yeah I've thought about this separately from that enhancement, I think
this feature *alone* would help to avoid issues with duplicate enum
members, e.g. where you're generating a switch case table via
EnumMembers. You can use NoDuplicates to for this, but it still
doesn't change that the following fails:
enum E
{
a,
b = a
}
void main()
{
static assert(is(E.a == E.b)); // fails
}
This may or may not be an issue.. Also, currently we don't have a way
to get the length of enum members except via EnumMembers, but if we
ever implemented E.length then maybe the alias behavior could be
useful.
Re: D Lang Socket Programming Example
It won't work. (This is why my project uses IP sockets for local communication, even on Linux) That has already been fixed in the version of Phobos on Github (I've marked it as fixed now, didn't know about that issue on bugzilla before).
Re: new DIP47: Outlining member functions of aggregates
On Saturday, 7 September 2013 at 17:00:08 UTC, Walter Bright wrote: Outlining of member functions is the practice of placing the declaration of a member function in the struct/class/union, and placing the definition of it at global scope in the module or even in another module. http://wiki.dlang.org/DIP47 I'm absolutely against this DIP. This proposal is just going back to the hell of header files again. Why on earth would you emulate C/C++ when D was supposed to be designed taking into account lessons learned from them. This is unnecessary complexity added for the sake of a few programmers who can't get out of C++ mode. I think you need to have a good hard think about *why* header files were introduced into those early languages and then consider if that reason is still valid. Personally i don't think it is. Java and C# do just fine without this. Seriously, this goes against everything you learn as a programmer, nothing should ever be typed twice and then to say that the declaration and implementation could be different just boggles my mind?!?! Great more work! If implemented, i will never used this feature and i will never deal with code that uses it either. I choose D *purely* because it didn't have this header file nonsense. If i find in future i start seeing more and more of this style of D code i would just move on to use something else that doesn't have all this extra baggage and work associated with it. Just because Manu brings it up randomly you decide to create a DIP? In reality this is a documentation issue. Which has already been addressed by DDOC or *.di files. If data exists in one form, and it is needed in another, that's work a computer should do. Not a human! IDE's also give you numerous tools to get class overviews and such. If you are suggesting that you also need these class overviews in code to be viewed on github etc, just use comments. They are as arbitrary and simpler to implement. Honestly this DIP is going backwards, i was under the impression D was going forwards! I am so disappointed.
Re: new DIP47: Outlining member functions of aggregates
On Sunday, 8 September 2013 at 12:46:49 UTC, Gary Willoughby wrote: This proposal is just going back to the hell of header files again. It has nothing to do with header files. Or real header file problems. Seriously, this goes against everything you learn as a programmer, nothing should ever be typed twice and then to say that the declaration and implementation could be different just boggles my mind?!?! Great more work! It is no different from overriding `interface` methods in class. From the code structure point of view, declaration is interface. Implementation is implementation. Keeping those separate may sometimes/often be useful. That said, I am strongly against permissive rules proposed in this DIP. It should be similar to overriding rules - any smallest difference between to signatures and program stops compiling. Otherwise it is maintenance hell.
Re: dmd2 mac os x compilation problem
On Sunday, 8 September 2013 at 12:00:22 UTC, Nick Sabalausky wrote: On Sun, 08 Sep 2013 12:56:09 +0200 Batuhan Göksu batuhango...@gmail.com wrote: [Environment] DFLAGS=-I/usr/dmd2/src/phobos -I/usr/dmd2/src/druntime/import -L/usr/dmd2/lib I'm not on Posix ATM, but I think that last arg is supposed to be: -L-L/usr/dmd2/lib Thank you, Nick Sabalausky Now seamlessly compiling.
Re: new DIP47: Outlining member functions of aggregates
P.S. In general I'd love to have feature feature proposed in DIP47 but its importance is very, _very_ low, right now it is probably the least important DIP in the whole list.
Re: new DIP47: Outlining member functions of aggregates
08-Sep-2013 16:02, Michel Fortin пишет:
On 2013-09-07 17:00:05 +, Walter Bright newshou...@digitalmars.com
said:
Outlining of member functions is the practice of placing the
declaration of a member function in the struct/class/union, and
placing the definition of it at global scope in the module or even in
another module.
http://wiki.dlang.org/DIP47
About placing the definition in another module, you say that the
definition when outlined in another module would have private access to
the private members of the module of declaration. Does that mean that
the definition has access to the private members of two modules at the
same time, the one it is declared in and the one it is defined in? That
seems strange to me.
Same here. This was the ugliest point.
[snip]
I'd like to make a suggestion. If one goal is effectively to allow the
implementation of a function to live in a separate file from its
declaration, then we already have a mechanism for that: .di files. So
I'd like to suggest this: allow a .d file to import its corresponding
.di file. Then the .d file should only contain the missing definitions
for what's declared in the hand-crafted .di file. That'd remove the
dubious semantics of making the definition part of another module and
would also allow outlining of global functions. And it also matches
better the C++ model of header/implementation files.
Also, I'd allow outlining only for this specific case where a .di file
is imported by a .d file. This way you know for sure when you see a
declaration without the definition in a .di file that this declaration
is in the corresponding .d file and not anywhere else, making it easier
to hunt it down.
Example:
// test.di
module test;
class A {
void foo(int a, int b);
}
// test.d
import module test; // import declarations from the .di file
void A.foo(int a, int b) {
// member function definition
}
With this suggestion it finally becomes sane.
--
Dmitry Olshansky
Re: slice based on base and width
On Sunday, 8 September 2013 at 12:08:50 UTC, Simen Kjaeraas wrote: On 2013-09-08, 14:02, Chang Long wrote: On Sunday, 8 September 2013 at 10:53:23 UTC, Øivind wrote: a[c -: d] //D: a[c-d .. c] I think this should be a[c -: d] //D: a[c-d+1 .. c+1], e.g. a[5 -: 2] == [a[4], a[5]] try a[base][0..width] That throws safety out the window for one. If you want safety and no new language features, this should work: a[base..$][0..width] Thanks Still a little verbose, but at least you don't have to type the same things twice. I guess the double slice will be optimized into a single one at least for release mode, so there should be no performance degredation?
Re: D Lang Socket Programming Example
On Sunday, 8 September 2013 at 10:42:22 UTC, Savsak wrote: Thanks acehreli In the example you give, but I receive this error during compilation. savsak:~ savsak$ dmd /Users/savsak/Desktop/test.d ld: library not found for -lphobos2 collect2: ld returned 1 exit status --- errorlevel 1 Your dmd installation is broken. Please tell how have you set it up to get any fixing suggestions ;)
Re: new DIP47: Outlining member functions of aggregates
On Sunday, 8 September 2013 at 12:53:11 UTC, Dicebot wrote: Seriously, this goes against everything you learn as a programmer, nothing should ever be typed twice and then to say that the declaration and implementation could be different just boggles my mind?!?! Great more work! It is no different from overriding `interface` methods in class. From the code structure point of view, declaration is interface. Implementation is implementation. Keeping those separate may sometimes/often be useful. That said, I am strongly against permissive rules proposed in this DIP. It should be similar to overriding rules - any smallest difference between to signatures and program stops compiling. Otherwise it is maintenance hell. Well you've just argued against your first paragraph there. The issue is (as you recognise) the extra complexity introduced with having a declaration and an implementation both of which could be different and/or not clear how they relate. But it goes further than that. If this DIP is implemented and you are working with code written like this you now have to change the code in two places when you want to update a method. Also you now have to find the implementation or declaration which is a total pain when not using an IDE. You now have more files. Longer compilation times. All for what? Not using -D on the command line? Come on! This is entirely different to how overloading works because in that scenario you are explicitly saying in your code this method overrides the parent (or interface) with this one that matches that signature exactly. There is no duplication, it's explicit overriding which is different. Also could you give me any examples of where keeping the declaration separate to the implementation is sometimes/often useful. Because IMHO it only adds work and Java and C# do just fine. I don't think Walter realises how much of a plus point it is for D to not have this 'feature'. I mean if this was implemented and code started appearing written in this style (as it will) why would people choose D over C++ to get stuff done when they both offer the same headaches now?
Re: Add support implicit conversion between types
On 2013-09-07, 15:19, ilya-stromberg wrote: On Saturday, 7 September 2013 at 13:02:39 UTC, Simen Kjaeraas wrote: It's a bit weird in D though, as operators are instance methods, and opImplicitRightCast (or opImplicitCastFrom, which is the name used in discussions before, see WalterAndrei.pdf from back when dinosaurs roamed the earth) should definitely not be an instance method but a static one. That said, I belive opImplicitCastFrom is The Right Solution™. It's explicit, it's a bit ugly, but not so much it hurts. Yes, opImplicitCastFrom looks better. I didn't know about WalterAndrei.pdf file. Can you give me a link to the file? It's intresting to read. http://s3.amazonaws.com/dconf2007/WalterAndrei.pdf It's from the D conference back in 2007, as the URL indicates. opImplicitCastFrom is mentioned on page 22. It's kinda interesting to see what was happening back then and how things have progressed. -- Simen
Re: new DIP47: Outlining member functions of aggregates
Am 08.09.2013 15:11, schrieb Gary Willoughby:
On Sunday, 8 September 2013 at 12:53:11 UTC, Dicebot wrote:
Seriously, this goes against everything you learn as a programmer,
nothing should ever be typed twice and then to say that the
declaration and implementation could be different just boggles my
mind?!?! Great more work!
It is no different from overriding `interface` methods in class. From
the code structure point of view, declaration is interface.
Implementation is implementation. Keeping those separate may
sometimes/often be useful.
That said, I am strongly against permissive rules proposed in this
DIP. It should be similar to overriding rules - any smallest
difference between to signatures and program stops compiling.
Otherwise it is maintenance hell.
Well you've just argued against your first paragraph there. The issue is
(as you recognise) the extra complexity introduced with having a
declaration and an implementation both of which could be different
and/or not clear how they relate. But it goes further than that. If this
DIP is implemented and you are working with code written like this you
now have to change the code in two places when you want to update a
method. Also you now have to find the implementation or declaration
which is a total pain when not using an IDE. You now have more files.
Longer compilation times. All for what? Not using -D on the command
line? Come on!
This is entirely different to how overloading works because in that
scenario you are explicitly saying in your code this method overrides
the parent (or interface) with this one that matches that signature
exactly. There is no duplication, it's explicit overriding which is
different.
Also could you give me any examples of where keeping the declaration
separate to the implementation is sometimes/often useful. Because IMHO
it only adds work and Java and C# do just fine.
I don't think Walter realises how much of a plus point it is for D to
not have this 'feature'. I mean if this was implemented and code started
appearing written in this style (as it will) why would people choose D
over C++ to get stuff done when they both offer the same headaches now?
Not only Java and C#, but any other language with module support, even
the ones that have native compilers by default.
The ones that offer interface definitions, like Delphi, Modula-{2,3}, ML
family among many others, have a model that D already offers via the .di
files.
So I also agree this is a step backwards.
--
Paulo
Re: new DIP47: Outlining member functions of aggregates
On Sunday, 8 September 2013 at 13:11:01 UTC, Gary Willoughby
wrote:
That said, I am strongly against permissive rules proposed in
this DIP. It should be similar to overriding rules - any
smallest difference between to signatures and program stops
compiling. Otherwise it is maintenance hell.
Well you've just argued against your first paragraph there. The
issue is (as you recognise) the extra complexity introduced
with having a declaration and an implementation both of which
could be different and/or not clear how they relate.
Not really. Issue is cognitive load of matching definition and
declaration if they are allowed to be out of sync.
But it goes further than that. If this DIP is implemented and
you are working with code written like this you now have to
change the code in two places when you want to update a method.
Also you now have to find the implementation or declaration
which is a total pain when not using an IDE.
I consider it a minor inconvenience for a certain structural gain.
This is entirely different to how overloading works because in
that scenario you are explicitly saying in your code this
method overrides the parent (or interface) with this one that
matches that signature exactly. There is no duplication, it's
explicit overriding which is different.
overloading != overriding. I am speaking about overriding. From
the maintenance point of view this two snippets are identical:
---
interface A
{
void foo();
}
class A_prim : A
{
void foo() { }
}
---
class A
{
void foo();
}
void A.foo()
{
}
---
Same amount of duplication, same amount of information available
for compiler verification.
Also could you give me any examples of where keeping the
declaration separate to the implementation is sometimes/often
useful. Because IMHO it only adds work and Java and C# do just
fine.
I have never worked on any reasonably large Java/C# code base.
But it C++ once amount of entities grows large enough clear
interface overview in header files is basically only way to get
familiar quickly with sources.
As I have already said it is good for same reasons interfaces are
good - easier to abstract away information you shouldn't be aware
of when working in large teams.
I don't think Walter realises how much of a plus point it is
for D to not have this 'feature'. I mean if this was
implemented and code started appearing written in this style
(as it will) why would people choose D over C++ to get stuff
done when they both offer the same headaches now?
I don't think it will matter at all. As it was mentioned, usage
of such feature tends to be private business of certain project -
it won't propagate to yours if you don't use it.
And you really underestimate issues of C++ that force programmers
to seek other languages. Separation of definition and declaration
won't probably be even in top 50.
Re: new DIP47: Outlining member functions of aggregates
On Sunday, 8 September 2013 at 12:46:49 UTC, Gary Willoughby wrote: I'm absolutely against this DIP. This proposal is just going back to the hell of header files again. Why on earth would you emulate C/C++ when D was supposed to be designed taking into account lessons learned from them. This is unnecessary complexity added for the sake of a few programmers who can't get out of C++ mode. I think you need to have a good hard think about *why* header files were introduced into those early languages and then consider if that reason is still valid. Personally i don't think it is. Java and C# do just fine without this. Seriously, this goes against everything you learn as a programmer, nothing should ever be typed twice and then to say that the declaration and implementation could be different just boggles my mind?!?! Great more work! If implemented, i will never used this feature and i will never deal with code that uses it either. I choose D *purely* because it didn't have this header file nonsense. If i find in future i start seeing more and more of this style of D code i would just move on to use something else that doesn't have all this extra baggage and work associated with it. Just because Manu brings it up randomly you decide to create a DIP? In reality this is a documentation issue. Which has already been addressed by DDOC or *.di files. If data exists in one form, and it is needed in another, that's work a computer should do. Not a human! IDE's also give you numerous tools to get class overviews and such. If you are suggesting that you also need these class overviews in code to be viewed on github etc, just use comments. They are as arbitrary and simpler to implement. Honestly this DIP is going backwards, i was under the impression D was going forwards! I am so disappointed. I totally agree (stating this just in case number of votes matters).
Re: new DIP47: Outlining member functions of aggregates
I have never worked on any reasonably large Java/C# code base. But it C++ once amount of entities grows large enough clear interface overview in header files is basically only way to get familiar quickly with sources. This is a job for the *documentation* and if documentation is automatically generated (which it is, see '-D') then this argument is moot. I don't think it will matter at all. As it was mentioned, usage of such feature tends to be private business of certain project - it won't propagate to yours if you don't use it. Except when dealing with books, tutorials, third party libraries, pull requests, etc... I dismay.
Re: new DIP47: Outlining member functions of aggregates
On Sunday, 8 September 2013 at 12:34:06 UTC, Andrej Mitrovic wrote: On 9/8/13, Michel Fortin michel.for...@michelf.ca wrote: So I'd like to suggest this: allow a .d file to import its corresponding .di file. This is actually what Andrei proposed as well. +42
Re: new DIP47: Outlining member functions of aggregates
On Sunday, 8 September 2013 at 15:09:31 UTC, Gary Willoughby wrote: This is a job for the *documentation* and if documentation is automatically generated (which it is, see '-D') then this argument is moot. Documentation is tool to help with cross-project learning. I have never seen one used internally inside the same project. It simply does not work that way, not even close in convenience to matching source organization. Takes more time, uses different information representation other than plain code, is not applicable in some contexts (i.e. git log). Built-in IDE tools are generally better for that but, as I have already said, I am not aware of a single one that does it conveniently enough. Except when dealing with books, tutorials, third party libraries, pull requests, etc... That applies to any other possible feature that may or may not exist in D. What I do mean though is that you shouldn't care how third-party library is organized - for you it remains same import statement and documentation investigation that requires to change nothing in your code flow even if third-party library uses this feature and you do not.
Re: new DIP47: Outlining member functions of aggregates
On Sunday, 8 September 2013 at 15:14:51 UTC, deadalnix wrote: On Sunday, 8 September 2013 at 12:34:06 UTC, Andrej Mitrovic wrote: On 9/8/13, Michel Fortin michel.for...@michelf.ca wrote: So I'd like to suggest this: allow a .d file to import its corresponding .di file. This is actually what Andrei proposed as well. +42 That is why I had a feeling I have already seen it somewhere :)
Re: new DIP47: Outlining member functions of aggregates
On Sunday, 8 September 2013 at 13:00:11 UTC, Dmitry Olshansky
wrote:
08-Sep-2013 16:02, Michel Fortin пишет:
[Snip]
Example:
// test.di
module test;
class A {
void foo(int a, int b);
}
// test.d
import module test; // import declarations from the .di
file
void A.foo(int a, int b) {
// member function definition
}
With this suggestion it finally becomes sane.
+1
Re: new DIP47: Outlining member functions of aggregates
On 2013-09-08, 12:46, Tove wrote:
Wouldn't this style be an acceptable compromise instead? with both
declaration and definition 100% identical.
struct S
{
// member function declarations
static int mfunc1(int a, int b = 5) pure;
static int mfunc2(int a, int b = 5) pure;
static int mfunc3(int a, int b = 5) pure;
// member function definitions
static int mfunc1(int a, int b = 5) pure
{
}
static int mfunc2(int a, int b = 5) pure
{
}
static int mfunc3(int a, int b = 5) pure
{
}
}
The problem here is the compiler does not enforce that all
definitions are present in the declaration list. Apart from that, I
feel this is the correct solution to the problem.
--
Simen
Re: new DIP47: Outlining member functions of aggregates
On 2013-09-07, 19:00, Walter Bright wrote:
Outlining of member functions is the practice of placing the declaration
of a member function in the struct/class/union, and placing the
definition of it at global scope in the module or even in another module.
http://wiki.dlang.org/DIP47
I like the idea, but I feel the DIP is missing some info:
- What happens to UDAs? Do I need to declare them both places?
- Why no nested classes/structs?
- How do outlined ctors/dtors look?
- How does it look in practice? Is this how it works:
// foo.d:
module foo;
class Foo {
int bar();
}
//foo_impl.d:
module foo;
import foo;
int Foo.bar() {
return 3;
}
- Do the module names have to be the same?
- Do I have to import the 'header' module in the implementation modules?
- If the module names don't have to be the same:
Can I implement the functions in any package? Sub-package? Only
the same package?
Also, I disagree with these points:
- Parameter names should match. I can accept nameless parameters in the
declaration, but otherwise they should match. Anything else is an
invitation for things to go out of sync.
- Default parameter values - either disallow them or enforce that they
are the same in both places.
- Implementation in a module different from the declaration. .di files
provide all the good stuff here, without sending you on a wild goose
chase through all your files for that one function your resident
junior programmer hid away inside the implementation of a completely
different class.
Lastly, I want more examples - is this the same for structs and classes?
Interfaces? Can I spread the function definitions over several modules?
All in all, I would currently vote against.
As an aside, I do like the idea of having a nice list of member
functions that is statically compared to those actually implemented.
This could however be done in different ways. My favorite would be
something along these lines:
class Foo {
interface {
float bar(int n) const;
Foo clone();
static int qux(); // Compile-time error on this line: declared
// function with no implementation.
}
float bar(int n) const {
return 0.0;
}
Foo clone() {
return this;
}
static int baz() { // Compile-time error on this line: undeclared
// function with implementation.
return 2;
}
}
For the sake of fueling discussion, I have created a DIP with this
suggestion:
http://wiki.dlang.org/DIP48
--
Simen
new DIP48: Interface specifications for aggregate types
In response to Walter's DIP47 I have created my own take on what I see as the main problem: http://wiki.dlang.org/DIP48 Destroy! -- Simen
Re: new DIP48: Interface specifications for aggregate types
On Sunday, 8 September 2013 at 18:13:52 UTC, Simen Kjaeraas wrote: In response to Walter's DIP47 I have created my own take on what I see as the main problem: http://wiki.dlang.org/DIP48 Destroy! Personally I find this practice of creating a competing DIP to be very annoying. This was specifically outlined in the first DIP: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1 A DIP should represent a problem the community wants to resolve and not just a specific resolution to a problem. This allows the DIP to be a central hub for any given problem. If a resolution is radically different from the current state of the DIP, an alternative DIP could be created as a sub page, e.g. under /DIPs/DIP1/Alternatives/Alt1?. The DIP should be created in its entirety such that it could replace the current DIP through simple copy and past. By creating separate DIPs and new forum posts, the discussion is segregated instead of being a progression to a solution. How is one to know that these two DIPs are to address the same problem: Outline Member Functions of Aggregates Interface specifications for aggregate types
Re: new DIP48: Interface specifications for aggregate types
On Sunday, 8 September 2013 at 18:13:52 UTC, Simen Kjaeraas wrote: In response to Walter's DIP47 I have created my own take on what I see as the main problem: http://wiki.dlang.org/DIP48 Destroy! I like it but would prefer @interface instead of interface Since using interface in this way, reminds me too much of nameless struct:s/union:s.
Re: Move VisualD to github/d-programming-language ?
On 08/09/13 01:22, Flamaros wrote: I hope to see MonoD on github/d-programming-language too if it's the case of VisualD. One thing that could help with MonoD would be if it could effectively support more than the most recent stable version of MonoDevelop. Version 3.0 is still the one used in many Linux distros. (4.0 is currently in the proposed updates for Ubuntu 13.10, which means it'll probably be the default by the time 13.10 is released.) If VisualD can support VS 2010, 2011 and 2013, it's surely possible for MonoD to do something similar. I recognize that the developer has provided an Ubuntu PPA for the latest MonoDevelop among other resources, but it's preferable not to oblige users to add extra archives to their distro.
Re: new DIP47: Outlining member functions of aggregates
On Saturday, 7 September 2013 at 17:00:08 UTC, Walter Bright wrote: Outlining of member functions is the practice of placing the declaration of a member function in the struct/class/union, and placing the definition of it at global scope in the module or even in another module. http://wiki.dlang.org/DIP47 I am against this proposal. The rationale does not convince me we would be getting enough value out of solving this problem. 1. Converting C++ to D This is the strongest argument. Maybe the issue identified here is solved with partial classes (see C#). 2. Having an outline of the code DDOC already provides this! And any such limitations should be fixed. This point has several supporting points. a. An IDE is not always available to fold code I never do this, I hate code folding. b. People read their code just as much in github commits, merge/diff windows, emails/chat, etc. And? I could see some value having a summary for signature changes/additions when reviewing commits. For merges this proposal just adds one more line of conflict to deal with. Brining up emails would suggest that you want someone to write down their class signature; instead of having them go to that much work I'd rather ask them to generate the docs and email them to me. Chat, well I think that is a lost cause (I haven't had any code sent to me over chat that I had been glad to have received over chat) I believe requiring the programmer to keep function prototypes in sync is a mistake. I also don't think having this be optional is addressing the issue of those that are for it. When C/C++ programmers talk of the problems header files, they talk of the problems cause by textual replacements and compiled header files. When everyone who doesn't program in C/C++ talk of the problems of header files, they talk about the troubles of writing prototypes twice. By providing this feature as an optional statement, you'll be left with Manu and his team using it, an no one else touching it (Sorry Manu, you're the only one I've seen with a strong conviction for it, I know others will use it too). I realize that we want to make it as painless as possible for Remedy to switch from C++ to D (along with the rest of the game developers). I'm also really glad about the changes which have come from their use/insistence. However I think this is mostly a superficial change which will result in a divide in the community much like @property.
Re: new DIP47: Outlining member functions of aggregates
On 9/8/13, Jesse Phillips jesse.k.phillip...@gmail.com wrote: I realize that we want to make it as painless as possible for Remedy to switch from C++ to D (along with the rest of the game developers). FWIW I don't think this has anything to do with Remedy (afaik Manu doesn't work there anymore).
Re: Move VisualD to github/d-programming-language ?
Just for the sake of completeness: mono is *detested* and considered even more inacceptable than java by many linux and (even more) *BSD users. Actually I *did* try the eclipse D IDE thing ... and found it to match my (utterly negative) perception of java (which has pretty nothing to do with the D ide and pretty everything with eclipse). Concerning Mono-D I heard about it and respect the efforts of the creator(s) ... but never even looked at it (and never will until hell freezes). I vaguely remember seeing colleagues work with Visual$$ on Windoze and they looked happy and productive to me. For a reason: Visual$$ seems to serve quite nicely the needs and expectations of those developing on Windoze. For fairness sake: It's next to impossible to do the same (as Visual$$) on linux/BSD due to complexity and a fractured eco system. Gnome and QT/kde basically are religious issues and no matter which one one chooses one will have a large audience refusing it. Besides both are monstrous (and more often than not meet resistance or at the very minimum reluctance on the Windoze side). Fox and fltk are nice little thingies but not up to (todays) par lacking even functionality like printing. And so on. That's quite regrettable, considering that we have a quite nice editor engine (Scintilla), quite good a debugger, and quite good compilers for pretty every language around. That said, maybe my first reaction was too harsh. After all, it's not D's job to solve the linux gui troubles. Having GDC with GDB working and some editors and even IDEs more or less working with D, I see that I should walk back a little and agree with the proposal (of this thread). A+ -R
Re: Move VisualD to github/d-programming-language ?
On 7 September 2013 22:57, Ramon s...@thanks.no wrote: On Saturday, 7 September 2013 at 20:02:37 UTC, Paulo Pinto wrote: Am 07.09.2013 21:55, schrieb Peter Alexander: On Saturday, 7 September 2013 at 19:39:21 UTC, Russel Winder wrote: Sadly, Visual Studio is a huge player in the game. Make the connection :-) Why sadly? It's a fantastic product. The only thing I don't like is the reliance on Visual Assist and ReSharper for refactoring features that other IDEs offer out of the box. -- Paulo I'm both pro and against it. Pro because VisualD seems to be (Pardon me, I don't work on Windoze and didn't work with it but trust Windoze D users opinion on that) an excellent solution and supporting nicely what seems to be *the* IDE in Windoze world. Love it or hate it, we call it Windows here. Against because we need a solution for *all* major platforms (Lx32, Lx64, *BSD, apple, w32,w64) and I'm worried that this resolution here might lead to a So, we *do* have an IDE. Case closed attitude. Why not cross-platform instead of *just* the major platforms? :o) -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Move VisualD to github/d-programming-language ?
On 8 September 2013 22:00, Ramon s...@thanks.no wrote: Just for the sake of completeness: mono is *detested* and considered even more inacceptable than java by many linux and (even more) *BSD users. Swings in roundabouts. Also depends what you mean by detest and inacceptable... From an ethical viewpoint, I think most of it is FUD that still lingers from back when there was confusion over what Microsoft was going to do C# (there was for a long time fear that it would drive all free C# implementations underground). But all that mist has been cleared for a while, and I don't believe this represents the overall view of users/developers - except for those who are still stuck in 2008 mindset. Mono/C# as a language may be detested for technically sound reasons however... Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: D Lang Socket Programming Example
On Sunday, 8 September 2013 at 10:42:22 UTC, Savsak wrote: ... In the example you give, but I receive this error during compilation. savsak:~ savsak$ dmd /Users/savsak/Desktop/test.d ld: library not found for -lphobos2 collect2: ld returned 1 exit status --- errorlevel 1 To help dicebot and others to help you it would be useful to copy the output of the following two commands: cat /etc/dmd.conf find /usr -name 'libphobos2*' (Please note the *single* ticks (rather than ) to not have your shell resolve it. Also note that probably /usr/lib would be more efficient as search path but using /usr can also catch exotic cases like /usr/share). If your installation is OK you will find the paths told by the find command to match those in /etc/dmd.conf. Here is an example of a working installation: $ find /usr -name 'libphobos2*' /usr/lib/x86_64-linux-gnu/libphobos2.so /usr/lib/x86_64-linux-gnu/libphobos2.a /usr/lib/i386-linux-gnu/libphobos2.so /usr/lib/i386-linux-gnu/libphobos2.a /usr/lib/i386-linux-gnu/libphobos2.so.0.2 --- $ cat /etc/dmd.conf // ... some comment lines .. [Environment] DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib/i386-linux-gnu -L-L/usr/lib/x86_64-linux-gnu -L--no-warn-search-mismatch -L--export-dynamic HtH -R
Re: Move VisualD to github/d-programming-language ?
On Sunday, 8 September 2013 at 21:08:59 UTC, Iain Buclaw wrote: ... Against because we need a solution for *all* major platforms (Lx32, Lx64, *BSD, apple, w32,w64) and I'm worried that this resolution here might lead to a So, we *do* have an IDE. Case closed attitude. Why not cross-platform instead of *just* the major platforms? :o) Because I have saved at least some crumbs of being realistic *g I'm btw. *not* against Visual$$ and I *do* know and respect that it has a lot of happy and productive followers. MS has definitely done something quite right there. My point isn't Ignore Visual$$! Hehe but rather Please, make sure to have happy linux and BSD users, too!. On Sunday, 8 September 2013 at 21:21:37 UTC, Iain Buclaw wrote: On 8 September 2013 22:00, Ramon s...@thanks.no wrote: Just for the sake of completeness: mono is *detested* and considered even more inacceptable than java by many linux and (even more) *BSD users. Swings in roundabouts. Also depends what you mean by detest and inacceptable... I'm, afraid it has shown to be quite senseless to resolve such issues by analysing and discussing adjectives. From an ethical viewpoint, I think most of it is FUD that still lingers from back when there was confusion over what Microsoft was going to do C# (there was for a long time fear that it would drive all free C# implementations underground). But all that mist has been cleared for a while, and I don't believe this represents the overall view of users/developers - except for those who are still stuck in 2008 mindset. Then let me inform you from a practical viewpoint that I'm not stupid and ignorant enough to automatically refuse anything from MS just because it's from MS. I don't like them and I don't trust them a nanometer but I recognize (even publicly) and respect when they do something well - like Visual$$. I'm btw. also advising clients in ca. 85% of cases to forget about Linux on the desktop and to use Windoze. My reasons to paranoically avoid Windoze for *myself* are not political or religious but purely pragmatic. tl;dr One is grossly mistaken when seeing myself as linux-taliban like anti-MS. I've talked to Miguel in person and I have solid reasons to not consider or touch Mono. Kindly note that I'm not fudding or preaching against it - I simply state that I and many others will not, no matter matter what, touch it. Mono/C# as a language may be detested for technically sound reasons however... Indeed. And those reasons might sometimes even be related to Mono. A+ -R
Re: new DIP47: Outlining member functions of aggregates
I'm opposed to this DIP. It's aimed solely at aiding readability, but having two ways to do something usually detracts from readability. I don't see the point.
Re: new DIP48: Interface specifications for aggregate types
On 2013-09-08, 20:28, Jesse Phillips wrote: On Sunday, 8 September 2013 at 18:13:52 UTC, Simen Kjaeraas wrote: In response to Walter's DIP47 I have created my own take on what I see as the main problem: http://wiki.dlang.org/DIP48 Destroy! Personally I find this practice of creating a competing DIP to be very annoying. This was specifically outlined in the first DIP: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1 A DIP should represent a problem the community wants to resolve and not just a specific resolution to a problem. This allows the DIP to be a central hub for any given problem. If a resolution is radically different from the current state of the DIP, an alternative DIP could be created as a sub page, e.g. under /DIPs/DIP1/Alternatives/Alt1?. The DIP should be created in its entirety such that it could replace the current DIP through simple copy and past. By creating separate DIPs and new forum posts, the discussion is segregated instead of being a progression to a solution. How is one to know that these two DIPs are to address the same problem: Outline Member Functions of Aggregates Interface specifications for aggregate types Very good point, and perhaps we should be doing DIPs differently. Or perhaps the whole system is a bit wrong, in that the problem and the solution are presented alongside one another. If instead the problem was explained on the top, and suggested solutions discussed independently below (or even on separate pages). The way it is now, I for one feel that the DIP is the creator's property and should not be edited. -- Simen
Re: Move VisualD to github/d-programming-language ?
On 9/8/13, Ramon s...@thanks.no wrote: Fox and fltk are nice little thingies but not up to (todays) par lacking even functionality like printing. Printing seems like something that should be in a separate library, and maybe the GUI library would provide a nice interface over its functionality. I've no idea, but are there no such cross-platform libraries around?
Re: new DIP48: Interface specifications for aggregate types
I don't like DIP47, but I think I like this less. The original DIP this is competing against at least has some sense of familiarity. This is some weird new thing, and neither DIP really does anything meaningful.
Re: Move VisualD to github/d-programming-language ?
On Sun, 08 Sep 2013 23:00:17 +0200 Ramon s...@thanks.no wrote: Visual$$ on Windoze Let's stick to grown-up words here. I'm not a fan of MS or Win either, but every time you write Windoze or spell something with $ it does nothing to hurt MS/Win and only makes you and other Posix users look like immature brats.
Re: Enum alias members: yay or nay?
On 9/8/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Does the alias member feature pull its weight? Or is it overkill and we should drop it? Anyway after some more thought I think it's overkill, since not resetting the counter could be just as confusing as resetting it.
Re: Move VisualD to github/d-programming-language ?
On Saturday, 7 September 2013 at 19:05:03 UTC, Walter Bright wrote: Recent threads here have made it pretty clear that VisualD is a critical piece of D infrastructure. (VisualD integrated D usage into Microsoft Visual Studio.) Andrei, myself and Rainer (VisualD's champion) are all in agreement on this. What do you think? This is a great idea! On Saturday, 7 September 2013 at 19:26:11 UTC, Peter Alexander wrote: Then it should be here: http://dlang.org/download.html That's the most important change that needs to be made. This too. Having VisualD listed in the github project and on the dlang.org website is a great step forward. I think it moves from having an IDE as some thing you can use, that some guy made for the language, to being an officially endorsed IDE for the language.
Re: Need help to finish DMD zip/7z release generator (alpha release)
On Fri, 6 Sep 2013 17:59:41 -0400 Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Fri, 06 Sep 2013 08:45:29 +0200 Jacob Carlborg d...@me.com wrote: On 2013-09-05 22:07, Nick Sabalausky wrote: I've decided I'm going to add proper support for 32-bit-only and 64-bit-only via optional cmdline flags. That should make a lot of things easier and help mitigate difficulties with multilib. Yeah, that's will make things a lot easier. Ok, I've just added optional switches --only-32 and --only-64. But I'm heading out right now so I didn't test it very well, and the --combine-* flags currently ignore the new non-multilib archives generated by those switches. I'll probably be able to take care of those later tonight, but hopefully this should make things easier. The --combine-* flags now handle the 32-bit-only and 64-bit-only archives correctly. I've also adjusted it to clone using the git protocol, and automatically fallback to https if that fails.
Re: Move VisualD to github/d-programming-language ?
On Sunday, 8 September 2013 at 21:47:59 UTC, Andrej Mitrovic wrote: On 9/8/13, Ramon s...@thanks.no wrote: Fox and fltk are nice little thingies but not up to (todays) par lacking even functionality like printing. Printing seems like something that should be in a separate library, and maybe the GUI library would provide a nice interface over its functionality. I've no idea, but are there no such cross-platform libraries around? For some reason, probably to follow the situation on Windoze, printing is considered to belong to or at least to be very tightly coupled with the GUI. Technically speaking MS has solved printing by drawing to a special canvas, which is somewhat unfortunate but actually not that bad conceptionally. In part the problem is also to do with linux going another way that is smart, too, by somewhat decoupling printing and going for postcript. Unfortunately this approach is quite different from Windoze (which still happens to own around 95% of the desktops) and also shows troublesome in a world of GDI printers (for many of which drivers exist nowadays in linux, too). From developers point of view the Windows approach probably looks more natural and desirable; after all printing, at least often, *is* just drawing on another target (paper rather than screen) and, more importantly, postscript is more at the driver side than on the creation side. tl;dr printing should be part of or at least reachable through the gui system. On Sunday, 8 September 2013 at 21:47:59 UTC, Nick Sabalausky wrote: On Sun, 08 Sep 2013 23:00:17 +0200 Ramon s...@thanks.no wrote: Visual$$ on Windoze Let's stick to grown-up words here. I'm not a fan of MS or Win either, but every time you write Windoze or spell something with $ it does nothing to hurt MS/Win and only makes you and other Posix users look like immature brats. Let's stick to the freedom of expressing oneself any (polite) way one sees fit as long as it's easily understandable. For the uninitiated: '$' often indicates a placeholder in nixnux world. With a friendly smile - the brat. A+ -R
Re: Move VisualD to github/d-programming-language ?
On 08/09/13 23:21, Iain Buclaw wrote: From an ethical viewpoint, I think most of it is FUD that still lingers from back when there was confusion over what Microsoft was going to do C# (there was for a long time fear that it would drive all free C# implementations underground). But all that mist has been cleared for a while, and I don't believe this represents the overall view of users/developers - except for those who are still stuck in 2008 mindset. I think there was a legit fear that if C# got a sufficient foothold in the Linux ecosystem, it'd provide a means for Microsoft to take everyone down via patent lawsuits. It's still theoretically a risk, but I think strategically Microsoft seems to have reconsidered that approach.
Re: Enum alias members: yay or nay?
On 9/7/2013 9:45 PM, Daniel Murphy wrote: tl;dr I don't think this justifies a new feature. A lint rule, absolutely. A warning, possibly. But not a new feature. I agree with the reasoning of the others here - not worth it.
Re: Enum alias members: yay or nay?
On Sunday, 8 September 2013 at 23:24:32 UTC, Walter Bright wrote: On 9/7/2013 9:45 PM, Daniel Murphy wrote: tl;dr I don't think this justifies a new feature. A lint rule, absolutely. A warning, possibly. But not a new feature. I agree with the reasoning of the others here - not worth it. It seems my last message got lost, but I reached the same conclusion: Anyway after some more thought I think it's overkill, since not resetting the counter could be just as confusing as resetting it.
Re: slice based on base and width
On 9/8/2013 6:03 AM, Øivind wrote: That throws safety out the window for one. If you want safety and no new language features, this should work: a[base..$][0..width] Thanks Still a little verbose, but at least you don't have to type the same things twice. I guess the double slice will be optimized into a single one at least for release mode, so there should be no performance degredation? Try it and see. If it isn't, feel free to file an enhancement request for the optimizer!
Re: Move VisualD to github/d-programming-language ?
On Sunday, 8 September 2013 at 22:37:00 UTC, Ramon wrote: On Sunday, 8 September 2013 at 21:47:59 UTC, Andrej Mitrovic wrote: On 9/8/13, Ramon s...@thanks.no wrote: Fox and fltk are nice little thingies but not up to (todays) par lacking even functionality like printing. Printing seems like something that should be in a separate library, and maybe the GUI library would provide a nice interface over its functionality. I've no idea, but are there no such cross-platform libraries around? For some reason, probably to follow the situation on Windoze, printing is considered to belong to or at least to be very tightly coupled with the GUI. Technically speaking MS has solved printing by drawing to a special canvas, which is somewhat unfortunate but actually not that bad conceptionally. In part the problem is also to do with linux going another way that is smart, too, by somewhat decoupling printing and going for postcript. Postscript is/was the industry standard, so of course Linux, Unix, FreeBSD and most other OSs support it, including windows. The special canvas in windows is really just another GDI render target. Cairo works in a similar way, producing device independent output that can then be used with different renderer targets, including Postscript, PDF, etc. G.
WindowsAPI - Problem with DECLARE_HANDLE definition
It has just come to my attention that there's a problem with the DECLARE_HANDLE template
in the Win32 bindings.
This is the definition in MinGW:
#define DECLARE_HANDLE(n) typedef struct n##__{int i;}*n
And this is the definition in our bindings:
package template DECLARE_HANDLE(string name, base = HANDLE) {
mixin (struct ~ name ~ {
~ base.stringof ~ h;
alias h this;
});
}
which when mixed in becomes something like
struct HWND {
HANDLE h;
alias h this;
}
The idea behind this was to effectively create a taxonomy of handle types, each implicitly
convertible to handle types higher up the chain. This was straightforward when we had
typedefs.
The problem is that null no longer works. How to fix? Ideas that come to mind:
1. Define a hierarchy of dummy classes for the handle types. No actual objects will exist
of these types, but since classes are reference types they can be set to null.
But there's a nasty bug lurking in this: if somebody tries to compare handles using ==, it
will dereference the pointer, and look in vain for the vtable and the opEquals method
defined therewithin ... cue major chaos.
2. Do 1, but use pointers to these classes as the handle types.
class HANDLE_ {}
alias const(HANDLE_)* HANDLE;
class HWND_ : HANDLE_ {}
alias const(HWND_)* HWND;
This would avoid the dereferencing behaviour. It's to be hoped that all Windows
programmers know that, although handles are declared as pointer types, they cannot
meaningfully be dereferenced. But what would the GC do, especially given that there are
two levels of indirection neither of which points to an appropriate memory location?
Moreover, will defining classes in the bindings cause object code to be generated for
them, which the program will later rely on in order to link? This is something I am
trying to get rid of completely.
3. Keep the current implementation, but implement an enum member NULL in each handle type,
like this:
struct HWND {
HANDLE h;
alias h this;
enum HWND NULL = cast(HWND) 0;
}
Programmers still can't use null, but writing HWND.NULL might be acceptable as the next
best thing.
4. Abandon this hierarchy idea and just define DECLARE_HANDLE the same way as the MinGW C
headers do.
What do people think we should do?
Stewart.
--
My email address is valid but not my primary mailbox and not checked regularly. Please
keep replies on the 'group where everybody may benefit.
Re: Enum alias members: yay or nay?
On Sunday, September 08, 2013 12:08:07 monarch_dodra wrote:
On Sunday, 8 September 2013 at 09:43:02 UTC, Kenji Hara wrote:
I also agree that the compiler enhancement is overkill.
Kenji Hara
Let's not throw this away quite yet: There is *another*
fundamental difference:
enum S
{
a,
b = a,
}
This creates an enum with *two* entries.
enum S
{
a,
alias b = a,
}
This would create an enum with a *single* entry, which can be
accessed via two different names.
*This*, in itself, I think is a good idea. It helps distinguish
between an enum that has multiple entries, some of which have
the same values and an enum whose entry 'a' can also be refered
to as 'b', fo rconvenience.
For starters, the distinction would be self documenting.
Second, once you involve things like `EnumMembers`, it becomes a
pretty interesting distinction to make.
But then things get weird, because EnumMembers wouldn't return everything, and
presumably final switch wouldn't have every member. It's not necessarily a bad
idea, but I think that it would have to be thought through very thoroughly,
and ultimately, I'm not sure that it's all that valuable.
The main feature that enums lack that would be nice would be the ability to
deprecate their members (presumably with the intention of replacing them with
new names). Aliases of some kind might be beneficial there, but again, I think
that it all would have to be thought through quite thoroughly. And ultimately,
it might be that it's just better to deprecate the entire enum at once and
come up with a new name, much as that's often not what you want to do, because
you just want to rename some of the values rather than replace the whole
thing.
So, all in all, I think that any changes to enums along these lines really
need to be thought through carefully before we consider doing anything, and
whatever changes we make would have to pull their weight (which Andrej's
suggestion doesn't do - and he seems to now agree with us on that).
- Jonathan M Davis
Re: new DIP47: Outlining member functions of aggregates
On 9/8/13 5:33 AM, Andrej Mitrovic wrote:
On 9/8/13, Michel Fortin michel.for...@michelf.ca wrote:
So I'd like to suggest this: allow a .d file to import its corresponding
.di file.
This is actually what Andrei proposed as well.
I have to say I was a lot more in favor of the proposal before this thread.
The problem as I see it has two facets:
1. Code duplication
2. Modularity and logistics
Regarding (1), we currently force duplication of the entire class
layout. My understanding is that this is the way it's done:
// file acme.di
class A {
int x;
double y;
void fun();
}
// file acme.d
// cannot import acme.di
class A {
int x;
double y;
void fun() { ... }
}
The fact that acme.d cannot import acme.di is an unforced error of
embarrassing proportions and consequence. That should be fixed yesterday
no matter how we proceed otherwise.
The problem with acme.d not having access to acme.di is that any error
in duplicating the layout of A (e.g. swapping x and y or adding some
other members etc) will have undefined behavior, and there is no
reasonable way for the compiler to check against that.
Assuming that bug is fixed, the problem of duplication remains - all
state of the class must be duplicated.
(I also suspect constructors might need to be white-boxed (i.e.
available in the .di) for raw/cooked typechecking, but I'm not sure.)
If we go with DIP47, the duplication of state goes away. However we have
a distinct problem - modularity, which segues into (2).
Allowing out-of-module implementations of individual methods poses
additional modularity problems. Consider:
// file acme.di
class A {
int x;
double y;
void fun();
}
private int a;
private void gun();
// file acme.d
// assume we solve the import problem
import acme;
void A.fun() { gun(); a = 42; }
If A.fun() were defined inside acme.di, it would have access to gun()
and a. Defining it outside asks the question - do we allow such access,
or not?
Intuitively the body of a method should not be all too sensitive to
where it's placed, so that argues in favor of visibility.
D's module system has always favored a file-granular approach, e.g.
private stuff is module-private. This notion of spilling private access
outside the file into methods defined in various other files works
against that nice tenet.
So it looks there's no obvious and obviously good solution. Probably the
first one is more sensible.
Andrei
Re: Move VisualD to github/d-programming-language ?
On Sep 8, 2013 11:49 PM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 08/09/13 23:21, Iain Buclaw wrote: From an ethical viewpoint, I think most of it is FUD that still lingers from back when there was confusion over what Microsoft was going to do C# (there was for a long time fear that it would drive all free C# implementations underground). But all that mist has been cleared for a while, and I don't believe this represents the overall view of users/developers - except for those who are still stuck in 2008 mindset. I think there was a legit fear that if C# got a sufficient foothold in the Linux ecosystem, it'd provide a means for Microsoft to take everyone down via patent lawsuits. It's still theoretically a risk, but I think strategically Microsoft seems to have reconsidered that approach. Both the C# specification ( http://www.ecma-international.org/publications/standards/Ecma-334.htm ) and the common language infrastructure (CLI) ( http://www.ecma-international.org/publications/standards/Ecma-335.htm ) have been standardised for some time now, so that aspect is safe from Microsoft. It is worth noting that not all C# modules are covered by CLI - such as the cryptography library. Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: new DIP47: Outlining member functions of aggregates
On 08/09/13 22:46, Gary Willoughby wrote: On Saturday, 7 September 2013 at 17:00:08 UTC, Walter Bright wrote: Outlining of member functions is the practice of placing the declaration of a member function in the struct/class/union, and placing the definition of it at global scope in the module or even in another module. http://wiki.dlang.org/DIP47 I'm absolutely against this DIP. This proposal is just going back to the hell of header files again. Why on earth would you emulate C/C++ when D was supposed to be designed taking into account lessons learned from them. This is unnecessary complexity added for the sake of a few programmers who can't get out of C++ mode. I think you need to have a good hard think about *why* header files were introduced into those early languages and then consider if that reason is still valid. Personally i don't think it is. Java and C# do just fine without this. Seriously, this goes against everything you learn as a programmer, nothing should ever be typed twice and then to say that the declaration and implementation could be different just boggles my mind?!?! Great more work! If implemented, i will never used this feature and i will never deal with code that uses it either. I choose D *purely* because it didn't have this header file nonsense. If i find in future i start seeing more and more of this style of D code i would just move on to use something else that doesn't have all this extra baggage and work associated with it. Just because Manu brings it up randomly you decide to create a DIP? In reality this is a documentation issue. Which has already been addressed by DDOC or *.di files. If data exists in one form, and it is needed in another, that's work a computer should do. Not a human! IDE's also give you numerous tools to get class overviews and such. If you are suggesting that you also need these class overviews in code to be viewed on github etc, just use comments. They are as arbitrary and simpler to implement. Honestly this DIP is going backwards, i was under the impression D was going forwards! I am so disappointed. Well said. Peter
Re: Move VisualD to github/d-programming-language ?
On 09/09/13 02:03, Iain Buclaw wrote: Both the C# specification ( http://www.ecma-international.org/publications/standards/Ecma-334.htm ) and the common language infrastructure (CLI) ( http://www.ecma-international.org/publications/standards/Ecma-335.htm ) have been standardised for some time now, so that aspect is safe from Microsoft. It is worth noting that not all C# modules are covered by CLI - such as the cryptography library. Given recent revelations, I'm not sure that crypto library should be used anyway ... :-)
Re: new DIP47: Outlining member functions of aggregates
On Sun, Sep 08, 2013 at 02:53:10PM +0200, Dicebot wrote: On Sunday, 8 September 2013 at 12:46:49 UTC, Gary Willoughby wrote: [...] Seriously, this goes against everything you learn as a programmer, nothing should ever be typed twice and then to say that the declaration and implementation could be different just boggles my mind?!?! Great more work! It is no different from overriding `interface` methods in class. From the code structure point of view, declaration is interface. Implementation is implementation. Keeping those separate may sometimes/often be useful. [...] I agree that declaration is interface, and implementation is implementation, and that it's good to separate them. What I *don't* agree with is that the interface should be *manually* maintained. There is absolutely no reason, in this day and age, that something so trivial as extracting the interface *automatically* and *reliably* by the compiler, can't be done. Therefore, the *real* solution to this problem is to fix the compiler's .di output to give a proper overview of the class *automatically*, and nicely pretty-printed. Manu has already said that the whole motivation behind wanting this sort of interface/implementation separation was to be able to tell what a class does at a glance. Well guess what? If we clean up the current messy .di generation to produce something decent, then all you have to do is to run dmd -H, and you have your at-a-glance version of the class. No unnecessary complication of the language, no maintenance nightmare, no code duplication, very little implementation effort, and 100% reliable because the .di file is generated straight from the implementation, and therefore by definition is correct. *This* is the correct solution to Manu's issue, IMO. DIP47 is approaching it from a completely wrong angle. Please, let's not go back to the C++ way. We've abandoned that a long time ago, and for good reason. That bridge should've been burned already. T -- INTEL = Only half of intelligence.
Re: new DIP48: Interface specifications for aggregate types
On Sun, Sep 08, 2013 at 08:13:33PM +0200, Simen Kjaeraas wrote: In response to Walter's DIP47 I have created my own take on what I see as the main problem: http://wiki.dlang.org/DIP48 [...] I don't see this as a fundamentally better or different solution than DIP47, which I already vote against. I believe the correct solution to this issue is auto-generation of interface from implementation. We should simply fix dmd's .di generation so that it is usable as a class-at-a-glance interface file. No language change is necessary. T -- You have to expect the unexpected. -- RL
Re: WindowsAPI - Problem with DECLARE_HANDLE definition
On 9/9/2013 8:52 AM, Stewart Gordon wrote: What do people think we should do? Eliminate declare handle and alias all HANDLE types to void*.
