Re: Mac OS X Installation
On Thu, 24 Jun 2010 01:29:53 -0500, Andrei Alexandrescu wrote: > > On 06/23/2010 11:52 PM, ch...@freshsources.com wrote: > > I have successfully installed D 2.0 on a number of Macs. However, the > > latest attempt yields the following error when I try to compile any file: > > > > object.d: Error: module object is in file 'object.d' which cannot be read > > import path[0] = /etc/../../src/phobos > > import path[1] = /etc/../../src/druntime/import > > > > As usual, I faithfully followed the instructions at > > > > http://www.digitalmars.com/d/2.0/dmd-osx.html > > > > Any ideas on how to fix this? Thanks. > > Hi, Chuck! > > Looks like the files aren't where they are supposed to be. Try this: > > head /etc/../../src/druntime/import/object.di > > Normally you should see the first ten lines of that file. If there's an > error, write back what the error message is. > > > Andrei Isn't /etc/../.. the root directory? That seems like an awfully incorrect place to the put the includes. I installed the druntime and phobos folders into /usr/local/include and then edited my /etc/dmd.conf accordingly. It seems to work pretty well, though it does require some setup.
Re: Errors in TDPL
I did not try to start a polemic, but to give something to think about. There
are more opinions on the matter and, as you may see, mine differs of yours. Is
not a tragedy.
However, I think one should be more aware when supporting habit per se.
Maybe adding "until" as an aliasing for "while not" would you seem more
acceptable? Or, at least, accepting "do{/* code */}aslongas(/*condition*/);" as
an alternative "do{/* code */}while(/*condition*/);" would be less disruptive?
That way, people could use "do/while", but this will open the door for "do/
aslongas", if this is considered suitable. This will also avoid ambiguous cases
like pointed out in this thread (i.e. the danger of interpreting "while(/
*condition*/;i++" as a ";" bug). This will break no compatibility.
Robustness of relying solely on the code indentation ("}while();" instead of
"while();") is not persuasive for me. Why dismissing an opportunity to avoid a
potential bug?
eles
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article
> Quality prevails over compatibility when the quality gain is deemed to
> exceed the problems incurred by losing compatibility.
> In this case, do-while works just fine. Lots of people are used to using it
> and have never even heard of repeat-until, having never used Pascal or any
> other language that used it. At this point, C's influence far outweights
> Pascal's.
> Also, AFAIK, do-while is not generally a major source of bugs. As such,
> while another construct might be better, since the current one isn't much of
> a problem, it's not worth breaking compatibility. If it were shown that do-
> while was a big problem, then it might be. But at this point, do-while works
> just fine, so it's not worth changing it.
> - Jonathan M Davis
Re: DMD Backend Long-term
bearophile Wrote: > Leandro Lucarella: > > Yes, I don't think "copying with 'cosmetic changes'" works, legally > > speaking. Otherwise everybody would be doing it. > > If 10% of changes is not legally enough, they LLVM dev can copy it and then > change the 15% of it or even 20%. There must exist a minimum amount of > differences between two blocks of code that allows them to be legally > considered different, otherwise GNU is worse than a software patent. > The GPL is not formulated in terms fraction of difference. It's formulated in terms of basement of work. If you don't base your work on another one, you have no need to copy it.
Re: Errors in TDPL
Can someone sanity check me on the code on pages 334-5? Does the method push really need !empty in its in contract? I might not be fully awake yet >< A...
Re: Errors in TDPL
Alix Pexton wrote: > Can someone sanity check me on the code on pages 334-5? > > Does the method push really need !empty in its in contract? > > I might not be fully awake yet >< > > A... It has to be an error. If you couldn't push onto an empty stack, then you'd never be able to put anything on the stack. - Jonathan M Davis
Re: Is it time for D1 to die of natural causes?
On Wed, 23 Jun 2010 19:53:33 +0200, Lutger wrote: > Do you > think D1 harms D2? I does in so far as people making libraries and wrappers don't support D2. I think getting Tango onto D2 would be a very positive step. Unfortunately, I don't think the maintainers are interested at all in this, the users of Tango wouldn't be, either, I'd imagine. So movement in that area has to come from D2 users, but I don't know from whom. As for myself, I have no interest whatsoever in porting a large library I do not use.
Re: Errors in TDPL
On 24/06/2010 09:09, Jonathan M Davis wrote: Alix Pexton wrote: Can someone sanity check me on the code on pages 334-5? Does the method push really need !empty in its in contract? I might not be fully awake yet>< A... It has to be an error. If you couldn't push onto an empty stack, then you'd never be able to put anything on the stack. - Jonathan M Davis That's what I thought, but it's there in the example over the page as well, so I though maybe I was missing something >< A...
Re: Errors in TDPL
Alix Pexton wrote: > On 24/06/2010 09:09, Jonathan M Davis wrote: >> Alix Pexton wrote: >> >>> Can someone sanity check me on the code on pages 334-5? >>> >>> Does the method push really need !empty in its in contract? >>> >>> I might not be fully awake yet>< >>> >>> A... >> >> It has to be an error. If you couldn't push onto an empty stack, then >> you'd never be able to put anything on the stack. >> >> - Jonathan M Davis > > That's what I thought, but it's there in the example over the page as > well, so I though maybe I was missing something >< > > A... I haven't look at it in detail yet, but it definitely looks like it's a copy-paste error, and it makes no sense for a push function to insist that something have already been pushed before you can push anything onto the stack. - Jonathan M Davis
Re: GUI Library for D2+Phobos
What is the recommended GUI library for D2+ Phobos for Windows/Linux? Looking at the Wiki4D GUI page shows a number of them but none appear to be fully released. DWT seems to be the official one, but AFAIK it's currently only for Tango (I've seen some attempts to port it to Phobos, I'll probably help if this is still active). I tried DFL once with D1 and it was fine. Currently the author states that it's not compatible with 2.046 (but you may try with 2.044). However, it's only for Windows. QtD looks very interesting, but I didn't manage to build it. Other users had same issue and noone wished to help, see QtD forums. The only GUI library which worked for me with D2 is GtkD. AM
Re: GUI Library for D2+Phobos
On 06/24/2010 02:08 AM, Graham Fawcett wrote: On Wed, 23 Jun 2010 23:30:16 +0200, Trass3r wrote: http://www.dsource.org/projects/qtd ! I would omit the exclamation mark for now. What's the story on the DMD patch in the QTD project? Can we expect to see this in a future DMD release, or is it a QTD-only thing? http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/ dmd.2.046.patch Graham The patch is an experiment. If we are not able to do without that "parent" trait, we will submit an enhancement request.
Re: GUI Library for D2+Phobos
On 06/24/2010 12:19 PM, Adrian Matoga wrote: QtD looks very interesting, but I didn't manage to build it. Other users had same issue and noone wished to help, see QtD forums. QtD has 1.5 active developers. It is being tested only on 32-bit WinXP and linux. The build system and the library itself are very likely to have issues on 64-bit OSes but I probably won't be able to test it there until QtD is stable on 32-bit. The guy who was responsible for the build system left quite a while ago and the original QtD author has a job which takes most of his time. So there are not many people who can help. Sorry.
Re: GUI Library for D2+Phobos
I don't have much time either but I might help testing on Win7 x64.
Re: is Expression, Type Identifier : TypeSpecialization
class one { }
class two : one { }
alias one ONE;
alias two TWO;
static if ( is(TWO T : ONE) )
writeln("test");
Is this a bug, or am I doing it wrong?
If it works without the aliases this is another strange alias bug.
Re: Is it time for D1 to die of natural causes?
SiegeLord Wrote: > Justin Johansson Wrote: > > > Now that Andrei's much anticipated publication of TDPL is out, is it > > time that D1 should now perish? > > > > My personal feeling is that by cremating D1, time and effort can then be > > better expended and focused on solidifying D2. > > > > Cheers > > Justin Johansson > > To whose benefit? You are advocating nerfing a good, stable, usable language > that has an excellent (de facto) standard library, excellent compilers (on > Linux, at least), 64 bit support, tons of libraries already written for it > etc, and replacing it with a buggy language, buggy standard library, buggy > linker, no 64 bit support and only a handful of libraries to support > developing in it. > > How do users benefit from your suggestion? I have scientific computing that > must be done *right now* as well as games I want to develop *right now* and I > don't want suffer the performance losses that come from DMD's substandard > optimizer (at least, relative to LLVM), as well as Phobos 2's abstractions > (although a better compiler might solve those issues) and not using 64 bits. > I just tried installing dmd2 on my 64 bit Linux box, and while it installed, > I couldn't compile "Hello World", since I have no 32 bit versions of 32 bit > pthread libraries installed. I am not going to install 32 bit versions of > every library I use in my C++ development to use them in D2, that is simply > unreasonable: I will use D1 instead. > > And I'm not worried about investing into D1 and then have my work be > obsolete: I am fully planning on porting my things to D2 *when* it becomes > better than or even as good as D1 for my purposes. It's easy to do... just > don't use too many deprecated features. > > D2 will only become the dominant version if it is actively better than D1, > not by making D1 "disappear." Users are not going to encounter those issues > and start spending their "time and effort" improving the standard library and > compiler tools, it isn't worth their time: they will go use a different > language instead. For D2's future's sake, that different language should be > D1. > Excellent points. I do believe, at the moment, D1 is used for real work, not D2. So idea of shooting D1 so half finished D2 could 'gain momentum' is idiotic one.
More on StringToken
It seems like the best way to go is to use dchar for strings (i.e. not have the struct as a template) as I need real characters for intersection purposes. When it comes to lookup, any input will need converting to dchars (I expect this can be done on the fly). In C++ you would use iterators to do this kind of input conversion. I don't know what the technique is in D. Regards, Ben
Re: I'd like to try D, but...
On 2010-06-23 15:42, Neal Becker wrote: My main interest is building python-callable modules (which I currently do with C++/boost::python). Problem is, D can't be used for this, because it can't produce shared libraries (except on i386). This is, as I understand it, because the D library/libraries are not built as PIC. This issue has been around for a _long_ time now. Is there any hope? Shared/dynamic libraries are working fine on Mac OS X with Tango. It also works with D2 with some modifications: http://d.puremagic.com/issues/show_bug.cgi?id=4080 -- /Jacob Carlborg
Re: is Expression, Type Identifier : TypeSpecialization
Trass3r Wrote:
> > class one { }
> > class two : one { }
> >alias one ONE;
> > alias two TWO;
> >static if ( is(TWO T : ONE) )
> > writeln("test");
> >
> > Is this a bug, or am I doing it wrong?
>
> If it works without the aliases this is another strange alias bug.
Do you mean the "alias one ONE; alias two TWO;" statements, or the missing T
alias? In the first case, If I comment out the two alias statements, it will
still compile. But that's not a bug, it's still syntactically correct (in that
case "ONE" and "TWO" don't exist, but the compiler won't complain about it).
In the second case, the aliased identifier doesn't need to be there unless we
want to use it, see form #2 of the is expressions near the bottom of the page:
http://www.digitalmars.com/d/2.0/expression.html
Re: GUI Library for D2+Phobos
On 2010-06-23 22:21, Jesse Phillips wrote: Mike James Wrote: What is the recommended GUI library for D2+ Phobos for Windows/Linux? Looking at the Wiki4D GUI page shows a number of them but none appear to be fully released. -=mike=- Personally I have had issue with GTKD and DWT. The only one I found to work out of the box was DFL, but it is Windows only. Otherwise I'm sure if you would be willing GTKD and DWT would love to have your assistance in supporting D2+Phobos. DWT would love that assistance. -- /Jacob Carlborg
Re: GUI Library for D2+Phobos
Max Samukha pisze: On 06/24/2010 12:19 PM, Adrian Matoga wrote: QtD looks very interesting, but I didn't manage to build it. Other users had same issue and noone wished to help, see QtD forums. QtD has 1.5 active developers. It is being tested only on 32-bit WinXP and linux. The build system and the library itself are very likely to have issues on 64-bit OSes but I probably won't be able to test it there until QtD is stable on 32-bit. The guy who was responsible for the build system left quite a while ago and the original QtD author has a job which takes most of his time. So there are not many people who can help. Sorry. Ok, so if I can help, tell what to do.
Re: More on StringToken
On Thu, 24 Jun 2010 11:35:50 +, Ben Hanson wrote:
> It seems like the best way to go is to use dchar for strings (i.e. not
> have the struct as a template) as I need real characters for
> intersection purposes. When it comes to lookup, any input will need
> converting to dchars (I expect this can be done on the fly).
>
> In C++ you would use iterators to do this kind of input conversion. I
> don't know what the technique is in D.
>
> Regards,
>
> Ben
import std.conv;
void charDoThing(charT)(charT[] stuff) {
dchar[] sameStuff = to!(dchar[])(stuff);
}
Re: More on StringToken
On 06/24/2010 06:35 AM, Ben Hanson wrote: It seems like the best way to go is to use dchar for strings (i.e. not have the struct as a template) as I need real characters for intersection purposes. When it comes to lookup, any input will need converting to dchars (I expect this can be done on the fly). In C++ you would use iterators to do this kind of input conversion. I don't know what the technique is in D. Regards, Ben like import std.array; string s; dchar first = s.front; dchar last = s.back; or import std.utf string s; int old_offset; int offset = stride(s, old_offset) dchar d = decode(s, old_offset + offset); ?
Re: More on StringToken
Ben Hanson wrote: It seems like the best way to go is to use dchar for strings (i.e. not have the struct as a template) as I need real characters for intersection purposes. When it comes to lookup, any input will need converting to dchars (I expect this can be done on the fly). In C++ you would use iterators to do this kind of input conversion. I don't know what the technique is in D. import std.range; auto s = "Hello world!"; s.front; // Returns dchars Is this what you want? -- Simen
Re: finding a circular dependency
On 06/21/2010 01:51 PM, Steven Schveighoffer wrote: I've been trying to get a modified version of std.process to compile (with Lars K's changes) for windows, and phobos finally compiled. So I built a little test program, compiled it, and I get the following error message: object.Exception: circular dependency in module std.stdio. Great. How did that happen? Being that I didn't write std.stdio, only modified it slightly (and certainly didn't change any imports), I haven't the foggiest where this problem is. Given that the runtime can prove there is a circular dependency, and apparently knows the names of the modules, how about showing me the cycle? :P I do not look forward to tracking this one down... -Steve Hey Steve, if you haven't found your cycle yet, could you send me the source code? My utility is a bit of a mess, but I think it's working now.
The future of DWT
I've recently been in contact with Frank Benoit, the original author of DWT (the tango version), and he says he has abandoned DWT (and D completely what it seems like). I think DWT is a great library and would hate to see it completely abandoned. I myself is currently updating the Mac version to 3.5.1 but having more and more trouble finding time to work on DWT. Therefore I'm now hoping that DWT could get some new contributors. The current status of DWT is: There are three ports available of DWT: Windows, Linux and Mac OS X. The Windows and Linux ports are at version 3.4. I'm currently in the progress of updating the Mac port from 3.5M3 to 3.5.1. There are four repositories, one for each port and one called DWT2. The DWT2 repository contains a work in progress on supporting both D1 with Tango and D2 with Phobos. Also all ports are now in the same repository, except for the Mac port which I haven't had the time yet to add to the DWT2 repository. There are also some other projects, DWT and Eclipse related, in the DWT2 repository, like JFace. So I'm now looking for developers to the help, mainly with the Windows and Linux ports, but also with the Mac port. What needs to be done is: * Updating all the ports to the latest SWT version, which currently is 3.5.2 (3.6 will soon be released) * Add the Mac port to the DWT2 repository * Port all code to D2 and Phobos * Make sure everything is up to date with latest compilers and libraries Additional things that can be done are: * Add additional ports (like WPF, 64bit versions) * Make DWT2 work with LDC (not sure if it works or not) * Finish porting the other projects in the DWT2 repository -- /Jacob Carlborg
Re: Errors in TDPL
Andrei Alexandrescu wrote: I mistakingly assumed D followed C in that regard. Given the argument stated in this thread (that absent semicolons require more context to be absorbed while reading), do you agree that D should make the semicolon required? Yes -- Simen
Re: finding a circular dependency
On Thu, 24 Jun 2010 10:27:29 -0400, Ellery Newcomer wrote: On 06/21/2010 01:51 PM, Steven Schveighoffer wrote: I've been trying to get a modified version of std.process to compile (with Lars K's changes) for windows, and phobos finally compiled. So I built a little test program, compiled it, and I get the following error message: object.Exception: circular dependency in module std.stdio. Great. How did that happen? Being that I didn't write std.stdio, only modified it slightly (and certainly didn't change any imports), I haven't the foggiest where this problem is. Given that the runtime can prove there is a circular dependency, and apparently knows the names of the modules, how about showing me the cycle? :P I do not look forward to tracking this one down... -Steve Hey Steve, if you haven't found your cycle yet, could you send me the source code? My utility is a bit of a mess, but I think it's working now. I did find it, and I will eventually incorporate my code which prints the cycle when it's found (it will be completely non-intrusive and not affect the startup performance unless a cycle is found). However, in trying to print the cycle, I've found a really disturbing bug that needs to be addressed first http://d.puremagic.com/issues/show_bug.cgi?id=4384 Also, equally disappointing, I found that the reason the cycle was added was to workaround a bug in dmd (specifically http://d.puremagic.com/issues/show_bug.cgi?id=3979). Without the code that creates the cycle, phobos doesn't compile. With the code, any program linked with phobos fails. Lovely... Great, I just gave myself more work when I was trying to just finish std.process! -Steve
Re: GUI Library for D2+Phobos
On Thu, 24 Jun 2010 05:19:48 -0400, Adrian Matoga wrote: What is the recommended GUI library for D2+ Phobos for Windows/Linux? Looking at the Wiki4D GUI page shows a number of them but none appear to be fully released. DWT seems to be the official one, but AFAIK it's currently only for Tango (I've seen some attempts to port it to Phobos, I'll probably help if this is still active). I tried DFL once with D1 and it was fine. Currently the author states that it's not compatible with 2.046 (but you may try with 2.044). However, it's only for Windows. QtD looks very interesting, but I didn't manage to build it. Other users had same issue and noone wished to help, see QtD forums. The only GUI library which worked for me with D2 is GtkD. AM DFL is working with 2.047.
Re: The future of DWT
On Thu, 24 Jun 2010 10:25:28 -0400, Jacob Carlborg wrote: Additional things that can be done are: * Add additional ports (like WPF, 64bit versions) Sadly, WPF is C# only, as far as I know.
is expression
Hey, in std.container, line 2623, I'm seeing static if (is(_store.insertBack(value))) The spec doesn't mention allowing expressions as far as I can remember, so what's the deal? Yes, the argument is ambiguous with type at parse time, but it has to get converted to an expression at some point. Is allowing expressions in is expression a definite keeper?
Re: is expression
On 06/24/2010 10:01 AM, Ellery Newcomer wrote: Hey, in std.container, line 2623, I'm seeing static if (is(_store.insertBack(value))) The spec doesn't mention allowing expressions as far as I can remember, so what's the deal? Yes, the argument is ambiguous with type at parse time, but it has to get converted to an expression at some point. Is allowing expressions in is expression a definite keeper? My mistake, a typeof should wrap the expression. Andrei
The status of D2
Now that TDPL has been published and is now out in the wild what is the status of D2. Have all the features added been settled and now D2 is in the debug phase? Are all future releases now of D2 just going to be bug fixes? Is it worthwhile to start a largish project in D2? The website makes out D2 to be 'experimental and possible unstable' but with all the work being done on it (and the book) surely this has moved on now. -=mike=-
Re: The status of D2
== Quote from Mike James (f...@bar.com)'s article > Now that TDPL has been published and is now out in the wild what is the > status of D2. > Have all the features added been settled and now D2 is in the debug phase? > Are all future releases now of D2 just going to be bug fixes? > Is it worthwhile to start a largish project in D2? > The website makes out D2 to be 'experimental and possible unstable' but with > all the work being done on it (and the book) surely this has moved on now. > -=mike=- The language per se is stabilized and in the debug phase. If you project is a library that won't have too many dependencies, the answer is yes, D2 is ready. On the other hand, Phobos is still in a state of flux to some degree (though I doubt there will be many breaking changes, especially non-trivial ones). Libraries for things like GUIs are even more in a state of flux. Therefore, I don't recommend writing a large-ish production application that needs to interact a lot with the outside world through libraries in D2 yet. A more self-contained but still non-trivial application like a compiler, a command line utility, or a scientific computing algorithm implementation, would be well suited to D2 as it stands now.
D1 is such a nice little language
In relation to the recently decease request: How much of D1 won't compile on D2? Is there a D1-to-D2 guide and how about a comparison chart? Is D2 worse as a first language, difficulty wise? Or is maybe the D2 safe subset a good first language?
Re: is expression
On 06/24/2010 10:02 AM, Andrei Alexandrescu wrote: On 06/24/2010 10:01 AM, Ellery Newcomer wrote: Hey, in std.container, line 2623, I'm seeing static if (is(_store.insertBack(value))) The spec doesn't mention allowing expressions as far as I can remember, so what's the deal? Yes, the argument is ambiguous with type at parse time, but it has to get converted to an expression at some point. Is allowing expressions in is expression a definite keeper? My mistake, a typeof should wrap the expression. Andrei Ah, very good. Maybe the compiler should bug out on expressions?
Re: is expression
Andrei Alexandrescu Wrote: > On 06/24/2010 10:01 AM, Ellery Newcomer wrote: > > Hey, > > > > in std.container, line 2623, I'm seeing > > > > static if (is(_store.insertBack(value))) > > > > The spec doesn't mention allowing expressions as far as I can remember, > > so what's the deal? Yes, the argument is ambiguous with type at parse > > time, but it has to get converted to an expression at some point. Is > > allowing expressions in is expression a definite keeper? > > My mistake, a typeof should wrap the expression. ...and this is exactly why we need meta.compiles(...) or something equivalent. That proposal had such an overwhelming backing by the community; what happened to it? There never was an official comment on it AFAIR. Such an addition should be fine even with TDPL out since it doesn't break anything, shouldn't it?
Re: Errors in TDPL
On Wed, 23 Jun 2010 11:51:40 -0500, Andrei Alexandrescu wrote: > On 06/23/2010 11:40 AM, Walter Bright wrote: >> Jonathan M Davis wrote: >>> Well, while I, personally, would put a semicolon there (it feels naked >>> to me without one), dmd doesn't actually seem to require it. But TDPL >>> says that the semicolon is required. So, it does appear to be an error >>> in the text. Of course, there's no helping his pet peeve regardless, >>> but the semicolon doesn't appear to be required. >> >> For reference for this discussion, the current grammar does not require >> it: >> >> http://www.digitalmars.com/d/2.0/statement.html#DoStatement >> >> The C grammar does require it: >> >> do statement while ( expression ) ; > > I mistakingly assumed D followed C in that regard. Given the argument > stated in this thread (that absent semicolons require more context to be > absorbed while reading), do you agree that D should make the semicolon > required? Absolutely. -Lars
Re: is Expression, Type Identifier : TypeSpecialization
You are right.
Even this doesn't work:
import std.stdio;
class one { }
class two : one { }
void main()
{
static if ( is(two T : one) )
writeln("test");
}
Additionally it's really strange dmd doesn't complain about TWO and ONE if
the aliases are omitted.
Seems like two distinct bugs to me.
File bug reports.
Re: is expression
On 06/24/2010 10:48 AM, Clemens wrote: Andrei Alexandrescu Wrote: On 06/24/2010 10:01 AM, Ellery Newcomer wrote: Hey, in std.container, line 2623, I'm seeing static if (is(_store.insertBack(value))) The spec doesn't mention allowing expressions as far as I can remember, so what's the deal? Yes, the argument is ambiguous with type at parse time, but it has to get converted to an expression at some point. Is allowing expressions in is expression a definite keeper? My mistake, a typeof should wrap the expression. ...and this is exactly why we need meta.compiles(...) or something equivalent. That proposal had such an overwhelming backing by the community; what happened to it? There never was an official comment on it AFAIR. Such an addition should be fine even with TDPL out since it doesn't break anything, shouldn't it? Yes, such an addition shouldn't interfere. Andrei
guide for building DMD/Phobos from SVN (on Linux)?
Hi folks, Is there a guide somewhere on building DMD/Phobos from SVN? I wanted to try my hand at fixing a few bugs, but I suspect the environment I built is broken. On a Linux box, I checked out dmd, druntime and phobos from SVN; twiddled the makefiles to fix paths; built them in that order; and set up my dmd.conf. Everything seems to work okay at first: a simple hello-world program compiles and executes properly. But if I compile it with '-unittest', I get a series of messages like this: /home/graham/dmd/druntime/trunk/src/core/thread.d(758): volatile statements deprecated; used synchronized statements instead Have I done something wrong? Any general pointers or advice? Thanks, Graham
Public code reviews of Phobos code
I encourage those of you who are interested in keeping score about Phobos and D in general to subscribe to the Phobos mailing list (http://lists.puremagic.com) or watch the NNTP stream off server news.gmane.org, newsgroup gmane.comp.lang.d.phobos. That way you get to see each commit separately, nicely formatted as a graphical diff. (Example: http://www.dsource.org/projects/phobos/changeset/1672) Feel free to comment on the commits; I'm sure I'm speaking on behalf of every committer that that would greatly help us improve our code. Andrei
Re: D1 is such a nice little language
strtr Wrote: > In relation to the recently decease request: > How much of D1 won't compile on D2? > Is there a D1-to-D2 guide and how about a comparison chart? There is a page that covers the language changes from D1 to D2[1] Which actually points to a Migration Page[2] which I have not seen before. > Is D2 worse as a first language, difficulty wise? > Or is maybe the D2 safe subset a good first language? I would say the only complication that would be an issue as a first language is the transitive cost, immutable. Even then these can be safely ignored. Understanding use of the standard library might be considered another issue, but it is common for tutorials to just gloss over the details and say "just do it this way for now." I think D2 is a much better language and D1 to be a language that can compete with other languages. D2 has the issue of limited library support, but if you're someone who needs an existing library D1 isn't likely to be your language with that library. I.e. someone new to the community who wants to get something done isn't likely to find what they need in D2 or D1. 1. http://www.digitalmars.com/d/2.0/features2.html 2. http://www.digitalmars.com/d/2.0/D1toD2.html
Re: Mac OS X Installation
"Justin Spahr-Summers" wrote in message news:mpg.268ca23b487143c5989...@news.digitalmars.com... > On Thu, 24 Jun 2010 01:29:53 -0500, Andrei Alexandrescu > wrote: >> >> On 06/23/2010 11:52 PM, ch...@freshsources.com wrote: >> > I have successfully installed D 2.0 on a number of Macs. However, the >> > latest attempt yields the following error when I try to compile any >> > file: >> > >> > object.d: Error: module object is in file 'object.d' which cannot be >> > read >> > import path[0] = /etc/../../src/phobos >> > import path[1] = /etc/../../src/druntime/import >> > >> > As usual, I faithfully followed the instructions at >> > >> > http://www.digitalmars.com/d/2.0/dmd-osx.html >> > >> > Any ideas on how to fix this? Thanks. >> >> Hi, Chuck! >> >> Looks like the files aren't where they are supposed to be. Try this: >> >> head /etc/../../src/druntime/import/object.di >> >> Normally you should see the first ten lines of that file. If there's an >> error, write back what the error message is. >> >> >> Andrei > > Isn't /etc/../.. the root directory? That seems like an awfully > incorrect place to the put the includes. > No, "/etc/../" is root. "/etc/../../" is "/.." (ie parent of root), which is nonsensical. --- Not sent from an iPhone.
Re: Mac OS X Installation
I wrote a simple script to automate my DMD installs. If the zipfile is named dmd.2.047.zip it will install the data into /opt/dmd-2.047 and then create the symbolic link /opt/dmd2 (I have /opt/dmd2/bin in my path). I also have it copy my dmd.conf from the previous install, since I'm not using the standard dmd.conf. I'll comment that line out in the script below: #!/bin/bash OSDIR=osx SRCDIR=`pwd` VERSION=$1 if [ -z "$1" ] then echo "Usage: $0 zipfile" exit 1 fi rm -fr dmd2 unzip dmd.$VERSION.zip pushd /opt sudo mkdir dmd-$VERSION cd dmd-$VERSION sudo cp -r $SRCDIR/dmd2/* . sudo ln -s $OSDIR/bin sudo ln -s $OSDIR/lib cd bin sudo chmod a+x dmd dumpobj obj2asm rdmd shell #sudo cp /opt/dmd2/bin/dmd.conf . cd /opt sudo rm dmd2 sudo ln -s dmd-$VERSION dmd2 popd
Re: guide for building DMD/Phobos from SVN (on Linux)?
The weird thing about building phobos is that it depends on druntime being accessible. I publish everything to /usr/local/include/d and /usr/local/lib. I have a script at the top-level of each SVN tree to take care of everything for me. Hopefully they'll clue you into what you're missing. Here's the druntime one: #!/bin/bash sudo rm -f /usr/local/include/d/object.* sudo rm -fr /usr/local/include/d/core pushd ./trunk make -fposix.mak popd sudo mkdir -p /usr/local/include/d/core sudo cp -f ./trunk/import/object.* /usr/local/include/d/. sudo cp -fr ./trunk/import/core/* /usr/local/include/d/core/. sudo cp -f ./trunk/lib/libdruntime.a /usr/local/lib/. And here's the phobos one: #!/bin/bash sudo rm -fr /usr/local/include/d/std sudo rm -fr /usr/local/include/d/etc pushd ./trunk/phobos make -flinux.mak DRUNTIME_PATH=/usr/local sudo rm -f /usr/local/lib/libphobos2.a popd sudo mkdir /usr/local/include/d/std sudo mkdir /usr/local/include/d/etc sudo cp -fr ./trunk/phobos/std/* /usr/local/include/d/std/. sudo cp -fr ./trunk/phobos/etc/* /usr/local/include/d/etc/. sudo cp -f ./trunk/phobos/generated/posix/release/libphobos2.a /usr/local/lib/. My dmd.conf looks like so: [Environment] DFLAGS=-I/usr/local/include/d -L-L/usr/local/lib
Re: Mac OS X Installation
Um, if your zipfile is named dmd.2.047.zip, run it as "dmdinstall 2.047" assuming the script file is named "dmdinstall".
Re: I'd like to try D, but...
Jacob Carlborg Wrote: > On 2010-06-23 15:42, Neal Becker wrote: > > My main interest is building python-callable modules (which I currently do > > with C++/boost::python). Problem is, D can't be used for this, because it > > can't produce shared libraries (except on i386). This is, as I understand > > it, because the D library/libraries are not built as PIC. > > > > This issue has been around for a _long_ time now. Is there any hope? > > Shared/dynamic libraries are working fine on Mac OS X with Tango. It > also works with D2 with some modifications: > http://d.puremagic.com/issues/show_bug.cgi?id=4080 Oops, I suppose I should take care of that ticket :-)
cent/ucent
This is one of the last dmd changes: http://www.dsource.org/projects/dmd/changeset/557 cent/ucent are probably easy to implement, their implementation can require little code on 64 bit systems, and operations done among them are probably fast on 64 bit systems. 128 bit unsigned numbers can represent: 340_282_366_920_938_463_463_374_607_431_768_211_455 Many normal programs don't overflow such numbers. A cent number can also be used to store safely the result of many operations done on 64 bit values. And generally I like the idea of having them... But while I know of few scientific computations situations where quadruple precision floating point numbers can be useful, in practice I don't know of situations where cent/ucent can be useful. One possible situation where ucent can be useful is to perform bitwise operations on 128-bits-wide SSE registers. But a good D compiler can use exactly the same CPU instructions when those operators are used among uint[4] fixed-sized arrays. So unless some significant application can be found, I suggest to not add cent/ucent. All features in the language need a purpose, adding useless things is bad. They can be kept among reserved keywords (as 'macro') for possible 128-bit CPUs. On the other hand instead of cent/ucent I have several situations (not related with cryptography) where I'd like in D a built-in "bint" or "bigint", that is the multi-precision integers (currently in a std.bigint module... well, the module was present in 2.046, I can't see it in Phobos of 2.047, I don't know why). Having it built-in allows for better multi-precision literals. (There are other number types that probably are more useful than cent/ucent, like a decimal floating point (IEEE standard 854-1987), useful for concurrency.) Bye, bearophile
Re: GUI Library for D2+Phobos
It seems to me that dfl is bold in a way. I built simple app with single window and the footprint about 1 mb. also it has a lot of dll dependencies. I compared it with winx C++ Gui library - footprint is about 50 k. -- -- Ruslan Mullakhmetov "Robert Jacques" сообщил(а) в новостях следующее:op.ves7c3lw26s...@sandford.myhome.westell.com... On Thu, 24 Jun 2010 05:19:48 -0400, Adrian Matoga wrote: What is the recommended GUI library for D2+ Phobos for Windows/Linux? Looking at the Wiki4D GUI page shows a number of them but none appear to be fully released. DWT seems to be the official one, but AFAIK it's currently only for Tango (I've seen some attempts to port it to Phobos, I'll probably help if this is still active). I tried DFL once with D1 and it was fine. Currently the author states that it's not compatible with 2.046 (but you may try with 2.044). However, it's only for Windows. QtD looks very interesting, but I didn't manage to build it. Other users had same issue and noone wished to help, see QtD forums. The only GUI library which worked for me with D2 is GtkD. AM DFL is working with 2.047.
Re: guide for building DMD/Phobos from SVN (on Linux)?
Hi Sean, On Thu, 24 Jun 2010 15:13:38 -0400, Sean Kelly wrote: > Here's the druntime one: > > > #!/bin/bash > sudo rm -f /usr/local/include/d/object.* sudo rm -fr > /usr/local/include/d/core pushd ./trunk > make -fposix.mak > popd > sudo mkdir -p /usr/local/include/d/core sudo cp -f > ./trunk/import/object.* /usr/local/include/d/. sudo cp -fr > ./trunk/import/core/* /usr/local/include/d/core/. sudo cp -f > ./trunk/lib/libdruntime.a /usr/local/lib/. > > > And here's the phobos one: > > > #!/bin/bash > sudo rm -fr /usr/local/include/d/std > sudo rm -fr /usr/local/include/d/etc > pushd ./trunk/phobos > make -flinux.mak DRUNTIME_PATH=/usr/local sudo rm -f > /usr/local/lib/libphobos2.a popd > sudo mkdir /usr/local/include/d/std > sudo mkdir /usr/local/include/d/etc > sudo cp -fr ./trunk/phobos/std/* /usr/local/include/d/std/. sudo cp -fr > ./trunk/phobos/etc/* /usr/local/include/d/etc/. sudo cp -f > ./trunk/phobos/generated/posix/release/libphobos2.a /usr/local/lib/. > > > My dmd.conf looks like so: > > > [Environment] > DFLAGS=-I/usr/local/include/d -L-L/usr/local/lib > Thank you! I haven't figured out what I was doing wrong yet, but using your build-scripts did the trick: my -unittest error is no more. Much appreciated! Graham
Re: The future of DWT
Is there any sense in developing DWT cause there are many others gui libraries for d as dfl, GtkD, QtD ??? -- -- Ruslan Mullakhmetov On Thu, 24 Jun 2010 10:25:28 -0400, Jacob Carlborg wrote: Additional things that can be done are: * Add additional ports (like WPF, 64bit versions) Sadly, WPF is C# only, as far as I know.
Re: Errors in TDPL
Does anyone else feel that the following is a fair clarification? Page 396 ... This means that communicating processors "forget" the exact order in which data was written: one tread writes x and then y and for a while another thread sees the new y but only the old x. vvv This means that communicating processors "forget" the exact order in which data was written: one tread writes to x and then to y and for a while another thread sees the new value of y but only the old value of x. ... Once I got my head around what is being claimed, I realised that it is correct as it appears, but it took me several reading to get there. It might just be because I'm a bit of a concurrency novice, but I'm sure I'm not the only one with a copy of tDPL ^^ A...
Re: The future of DWT
"theambient" wrote in message news:i00ct8$2ho...@digitalmars.com... > Is there any sense in developing DWT cause there are many others gui > libraries for d as dfl, GtkD, QtD ??? > Yes. DFL: Windows-only. GtkD: It's GTK. GTK is shit. QtD: AIUI, still needs work and some compiler improvements. Also, DWT could probably help people porting from Java. --- Not sent from an iPhone.
Intel Concurrent Collections for Haskell [OT]
>From the first blog post: >Well, it happens that the CnC notion of a step is a pure function. A step does >nothing but read its inputs and produce tags and items as output. This design >was chosen to bring CnC to that elusive but wonderful place called >deterministic parallelism. The decision had nothing to do with language >preferences. (And indeed, the primary CnC implementations are for C++ and >Java.) Yet what a great match Haskell and CnC would make! Haskell is the only >major language where we can (1) enforce that steps be pure, and (2) directly >recognize (and leverage!) the fact that both steps and graph executions are >pure.< Maybe a good enough implementation can be done in D2 too. http://software.intel.com/en-us/blogs/2010/05/27/announcing-intel-concurrent-collections-for-haskell-01/ http://software.intel.com/en-us/blogs/2010/06/01/a-tour-of-haskell-cnc-schedulers/ http://software.intel.com/en-us/blogs/2010/06/03/new-haskell-cnc-release-013-adds-parallel-for-loops/ http://software.intel.com/en-us/blogs/2010/06/07/parallel-performance-in-intel-concurrent-collections-for-haskell-an-in-depth-example/ Bye, bearophile
@property
As heard around these parts, a lot of people want property-style function calls to require the function to be declared with @property, like this: @property foo(); //getter @property foo(int); //setter foo; //getter foo = 13; //setter While this seems quite reasonable, in practice I and others feel this leads to confusion, especially the getter part. Mostly when the getter has no setter counterpart. D also lets us call no-argument functions without parentheses today, so for this to happen a lot of code needs to change. My suggestion is as follows; require @property for single-argument setters *only*. Make the silly writeln = 13; go away, but keep the "a b c".split;. This way, there can be no confusion about @property, and most code will go unchanged. I hope this was not too late a suggestion. :)
Re: @property
Pelle wrote: > As heard around these parts, a lot of people want property-style > function calls to require the function to be declared with @property, > like this: > > @property foo(); //getter > @property foo(int); //setter > > foo; //getter > foo = 13; //setter > > While this seems quite reasonable, in practice I and others feel this > leads to confusion, especially the getter part. Mostly when the getter > has no setter counterpart. D also lets us call no-argument functions > without parentheses today, so for this to happen a lot of code needs to > change. > > My suggestion is as follows; require @property for single-argument > setters *only*. Make the silly writeln = 13; go away, but keep the "a b > c".split;. This way, there can be no confusion about @property, and most > code will go unchanged. > > I hope this was not too late a suggestion. :) I thought that the whole point of @property was that it enabled the property-style function calls with no parens and that functions not labeled with @property had to be called with parens. - Jonathan M Davis
Re: @property
On 06/24/2010 10:25 PM, Jonathan M Davis wrote: Pelle wrote: As heard around these parts, a lot of people want property-style function calls to require the function to be declared with @property, like this: @property foo(); //getter @property foo(int); //setter foo; //getter foo = 13; //setter While this seems quite reasonable, in practice I and others feel this leads to confusion, especially the getter part. Mostly when the getter has no setter counterpart. D also lets us call no-argument functions without parentheses today, so for this to happen a lot of code needs to change. My suggestion is as follows; require @property for single-argument setters *only*. Make the silly writeln = 13; go away, but keep the "a b c".split;. This way, there can be no confusion about @property, and most code will go unchanged. I hope this was not too late a suggestion. :) I thought that the whole point of @property was that it enabled the property-style function calls with no parens and that functions not labeled with @property had to be called with parens. - Jonathan M Davis Also to disable writeln = 13; But I want to keep paren-less calls and remove silly call-as-assignment, except for when marked as to make sense.
Re: @property
Pelle wrote: > Also to disable writeln = 13; > > But I want to keep paren-less calls and remove silly call-as-assignment, > except for when marked as to make sense. As I understand it, the whole point of properties in general is that they allow you to exchange public member variables and functions without changing code that uses the class. By being able to change a public member variable into a function, you can do things later on like add code to validate what you're setting the variable to or you can make the property computed instead of having an actual member variable for that data. The fact that you can call all non-void single-arg functions and all void single-arg functions in D is purely a side-effect of the fact that property syntax was originally enabled in D by simply allowing all functions that matched the syntax of a property function - i.e. void single-arg and non- void no-arg functions - to be called without parens. This lead to people calling non-property functions as if they were properties - writeln being a prime example. Other than legacy, code I see _0_ benefit to allowing non-property functions to be called as if they were properties. They aren't properties and shouldn't be treated that way. Now, a programmer is free to use @property as they please in the code and can abuse it just like any other part of the language, but the whole point of being able to call functions without parens is in order to have property syntax for properties. I, for one, do _not_ think that non-property functions should be able to be called as if they were properties. - Jonathan M Davis
Re: @property
On Thu, 24 Jun 2010 16:21:37 -0400, Pelle wrote:
As heard around these parts, a lot of people want property-style
function calls to require the function to be declared with @property,
like this:
@property foo(); //getter
@property foo(int); //setter
foo; //getter
foo = 13; //setter
While this seems quite reasonable, in practice I and others feel this
leads to confusion, especially the getter part. Mostly when the getter
has no setter counterpart. D also lets us call no-argument functions
without parentheses today, so for this to happen a lot of code needs to
change.
How is this confusing? It's a read-only property. They are used in
countless design patterns.
Furthermore, how will allowing any no-arg function to be called without
parentheses *not* lead to confusion?
e.g.
struct File
{
bool open() {...}
}
File f;
if(f.open) // looks to me like a property saying whether f is open
if(f.open()) // looks to me like a function opening f.
Like it or not, the parentheses are part of the name of the
function/property, and to not be able to control whether parens are used
as an author of said function/property leaves me to answer unending
requests for changes to the API, such as "why don't you change open to
openFile to make it clear that it's a function." Hey, look, we're back
to Java's getX and setX, but in reverse! Wh!
With @property, I don't have to do that, because it's very obvious that
since open requires parentheses, it is effecting an action on f.
My suggestion is as follows; require @property for single-argument
setters *only*. Make the silly writeln = 13; go away, but keep the "a b
c".split;. This way, there can be no confusion about @property, and most
code will go unchanged.
@property is much better than the current situation, even for getters.
C#, python, I'm sure other languages, have worked fine for years with
explicit properties, this debate is non-existent there.
In a couple months after @property has been enforcing the parens rule,
nobody will think about this debate any more. The only pain is in undoing
the hack that is D's current properties.
-Steve
Re: @property
On 06/24/2010 10:45 PM, Steven Schveighoffer wrote:
How is this confusing? It's a read-only property. They are used in
countless design patterns.
The confusion isn't their existence, but rather deciding what is a
property and what is not.
Furthermore, how will allowing any no-arg function to be called without
parentheses *not* lead to confusion?
Note that many languages never require parentheses, and they're not
particularly confused.
struct File
{
bool open() {...}
}
File f;
if(f.open) // looks to me like a property saying whether f is open
if(f.open()) // looks to me like a function opening f.
Like it or not, the parentheses are part of the name of the
function/property, and to not be able to control whether parens are used
as an author of said function/property leaves me to answer unending
requests for changes to the API, such as "why don't you change open to
openFile to make it clear that it's a function." Hey, look, we're back
to Java's getX and setX, but in reverse! Wh!
With @property, I don't have to do that, because it's very obvious that
since open requires parentheses, it is effecting an action on f.
I feel this is a naming issue, not a @property-issue. Is the empty() of
a range a property? Is the save() a property? It's just up to anyone to
guess and argue either way.
@property is much better than the current situation, even for getters.
C#, python, I'm sure other languages, have worked fine for years with
explicit properties, this debate is non-existent there.
And paren-less function calls have worked fine for years in a bunch of
other languages. This debate is non-existent there as well.
In a couple months after @property has been enforcing the parens rule,
nobody will think about this debate any more. The only pain is in
undoing the hack that is D's current properties.
-Steve
The only hack is that calling by assigning works for all single-arg
functions.
Re: D1 is such a nice little language
== Quote from Jesse Phillips (jessekphillip...@gmail.com)'s article > strtr Wrote: > > In relation to the recently decease request: > > How much of D1 won't compile on D2? > > Is there a D1-to-D2 guide and how about a comparison chart? > There is a page that covers the language changes from D1 to D2[1] Which > actually points to a Migration Page[2] which I have not seen before. > > Is D2 worse as a first language, difficulty wise? > > Or is maybe the D2 safe subset a good first language? > I would say the only complication that would be an issue as a first language > is the transitive cost, immutable. Even then these can be safely ignored. Understanding use of the standard library might be considered another issue, but it is common for tutorials to just gloss over the details and say "just do it this way for now." > I think D2 is a much better language and D1 to be a language that can compete with other languages. D2 has the issue of limited library support, but if you're someone who needs an existing library D1 isn't likely to be your language with that library. I.e. someone new to the community who wants to get something done isn't likely to find what they need in D2 or D1. > 1. http://www.digitalmars.com/d/2.0/features2.html > 2. http://www.digitalmars.com/d/2.0/D1toD2.html Nice, I hadn't seen that D1toD2 one. Reads like it could be automated btw.
Re: @property
On 06/24/2010 10:43 PM, Jonathan M Davis wrote: Other than legacy, code I see _0_ benefit to allowing non-property functions to be called as if they were properties. They aren't properties and shouldn't be treated that way. Now, a programmer is free to use @property as they please in the code and can abuse it just like any other part of the language, but the whole point of being able to call functions without parens is in order to have property syntax for properties. I, for one, do _not_ think that non-property functions should be able to be called as if they were properties. - Jonathan M Davis The problem lies within the definition of what a property is and is not, as well as can and cannot be. A benefit to the current situation is that fewer parentheses means less line noise, and prettier code.
Re: @property
On 24/06/2010 22:15, Pelle wrote: A benefit to the current situation is that fewer parentheses means less line noise, and prettier code. That's only in your opinion and this discussion has been done to far beyond death. For gods sake just stop. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Re: @property
On Thu, 24 Jun 2010 17:11:08 -0400, Pelle wrote:
On 06/24/2010 10:45 PM, Steven Schveighoffer wrote:
How is this confusing? It's a read-only property. They are used in
countless design patterns.
The confusion isn't their existence, but rather deciding what is a
property and what is not.
That is an addendum to deciding the name of the function. Property-or-not
is a name decision, and is as arbitrary as deciding a good name for a
function.
Furthermore, how will allowing any no-arg function to be called without
parentheses *not* lead to confusion?
Note that many languages never require parentheses, and they're not
particularly confused.
D is of C lineage, and as such, should follow C's conventions -- parens
for functions, no parens for properties.
struct File
{
bool open() {...}
}
File f;
if(f.open) // looks to me like a property saying whether f is open
if(f.open()) // looks to me like a function opening f.
Like it or not, the parentheses are part of the name of the
function/property, and to not be able to control whether parens are used
as an author of said function/property leaves me to answer unending
requests for changes to the API, such as "why don't you change open to
openFile to make it clear that it's a function." Hey, look, we're back
to Java's getX and setX, but in reverse! Wh!
With @property, I don't have to do that, because it's very obvious that
since open requires parentheses, it is effecting an action on f.
I feel this is a naming issue, not a @property-issue. Is the empty() of
a range a property? Is the save() a property? It's just up to anyone to
guess and argue either way.
This is why you are confused -- @property *is* a naming issue. The
difference between the hackish D current syntax and the sane @property
syntax is that in hackish D, the caller gets to decide how to name the
function, which doesn't make any sense.
And the problem is precisely that it's anyone's guess. It should be up to
the author of the structure. It should *not* be up to the user of the
struct to 'guess'.
How about we get rid of case-sensitivity, so people who like to use all
caps can have their say in how they call your functions. Does it make any
sense? How about we allow spanish translations of english terms to be
used? How about just unambiguous prefixes? Any naming issue should be
decided by the author of the function so that 1) it's consistent
everywhere it's used and 2) the author is free to imply a meaning without
resorting to overly verbose text. To allow otherwise causes way more
confusion than some author who can't decide on whether something is a
property or not. I very seldom run into cases where the name of the
function is obvious, but whether to make it a property or not isn't. I
always consider the property/no-property question when deciding the name.
Empty is a perfect example -- property through and through.
Save is not as obvious, but that's because the author decided the name
without considering whether it should be a property. If it should be
considered a property, it should be a noun (not a hard rule, but it makes
more sense that way). I'd say something like 'copy' would look better as
a property. But IMO, save provides almost no utility so that leads to it
being hard to name. Blaming property syntax is not the way out.
@property is much better than the current situation, even for getters.
C#, python, I'm sure other languages, have worked fine for years with
explicit properties, this debate is non-existent there.
And paren-less function calls have worked fine for years in a bunch of
other languages. This debate is non-existent there as well.
Do those languages allow parentheses? Do they allow calling functions
with parameters without parentheses? If the convention is parentheses are
forbidden or always optional, it's less confusion, because you can't
assume anything from the parentheses or lack thereof. I don't see how we
are better off not being able to use parentheses to disambiguate semantic
meaning.
-Steve
Re: @property
My apologies if this ends up being sent twice. I'm having problems with my client at the moment. On Thursday, June 24, 2010 14:15:22 Pelle wrote: > On 06/24/2010 10:43 PM, Jonathan M Davis wrote: > > Other than legacy, code I see 0 benefit to allowing non-property > > functions to be called as if they were properties. They aren't > > properties and shouldn't be treated that way. Now, a programmer is free > > to use @property as they please in the code and can abuse it just like > > any other part of the language, but the whole point of being able to > > call functions without parens is in order to have property syntax for > > properties. I, for one, do not think that non-property functions > > should be able to be called as if they were properties. > > > > - Jonathan M Davis > > The problem lies within the definition of what a property is and is not, > as well as can and cannot be. > > A benefit to the current situation is that fewer parentheses means less > line noise, and prettier code. I really didn't think that there was much of question on that, but I guess that I was wrong. Everywhere that I've seen properties discussed, properties are values that could be either public member variables or have private member variables with getters and setters - the one extension being that that rather than having the property being stored in a member variable, it could be calculated (such as empty being calculated from size rather than stored separately). If it doesn't make sense for the property to be replaced with a getter function (if it's a readable property) and/or setter function (if it's a writeable property), then it's not a property. writeln() isn't a property because it makes no sense to replace it with a getter or setter. The same goes for save() or popFront() on a range. However, things like length() and empty() are properties because they could be replaced with functions like getLength() and isEmpty(). I really think that the main problem here is that any function that looked like property could previously be called like a property. Now, with the @property syntax, it becomes a matter of choice of the programmer. They are free to label properties with @property or mislabel non-properties with @property. There probably are a few functions out there where it would be unclear as to whether they should be a property or not, but for the most part, I don't see why there should be any confusion. Properties are basically a way to make getters and setters look like public member variables. - Jonathan M Davis
Re: @property
Steven Schveighoffer: > How about we get rid of case-sensitivity, so people who like to use all > caps can have their say in how they call your functions. Does it make any > sense? Case-insensitive languages make sense. In many natural languages written words usually mean the same thing regardless their case. In the same way, the "hello" word written with a blue pen means the same thing as "hello" written with a red pen. They are the same word. The same is true if you write "HELLO" or "Hello" or "hello", case is seen as the color of text, it doesn't change text meaning. For people that learn their first programming language I think that a caseless language is simpler to learn, because they need to learn one thing less (that writing "for" and "For" is not the same keyword as in the natural languages they know already). In practice in Pascal-like languages you don't write with random case like rEpEAT UNtiL, you keep an uniform case, it's a style, like Repeat or repeat in the whole program. Newbie Delphi programmers sometimes switch case in a single program. Case-insensitive languages are not so bad (more modern languages have invented ways to use the case in structured ways, so if you turn D into a case-insensitive language you will probably have some troubles. To avoid such troubles you need a language that is designed from the start to be case-insensitive). Bye, bearophile
The X Macro
http://www.drdobbs.com/blog/archives/2010/06/the_x_macro.html Even though D doesn't have a text macro preprocessor, this can be done using string mixins and a bit of CTFE.
Re: @property
On 06/24/2010 11:38 PM, Steven Schveighoffer wrote: This is why you are confused -- @property *is* a naming issue. The difference between the hackish D current syntax and the sane @property syntax is that in hackish D, the caller gets to decide how to name the function, which doesn't make any sense. And the problem is precisely that it's anyone's guess. It should be up to the author of the structure. It should *not* be up to the user of the struct to 'guess'. How about we get rid of case-sensitivity, so people who like to use all caps can have their say in how they call your functions. Does it make any sense? How about we allow spanish translations of english terms to be used? How about just unambiguous prefixes? Any naming issue should be decided by the author of the function so that 1) it's consistent everywhere it's used and 2) the author is free to imply a meaning without resorting to overly verbose text. To allow otherwise causes way more confusion than some author who can't decide on whether something is a property or not. I very seldom run into cases where the name of the function is obvious, but whether to make it a property or not isn't. I always consider the property/no-property question when deciding the name. Empty is a perfect example -- property through and through. Save is not as obvious, but that's because the author decided the name without considering whether it should be a property. If it should be considered a property, it should be a noun (not a hard rule, but it makes more sense that way). I'd say something like 'copy' would look better as a property. But IMO, save provides almost no utility so that leads to it being hard to name. Blaming property syntax is not the way out. Your argument seems to stem from the idea that @property is part of the name of a function, and that the () indicates some mutative action upon an object. Well, liking it or not I do not agree about the naming part, I see it more in the league of coding style and indentation. I totally allow users of my code to decide their variable names and indentation style. We always have constness and/or purity to imply lack of mutation. Is split a property? It doesn't mutate a string, and totally could be an instance variable for every given string, but isn't. It doesn't really feel property-like, but writing "a b c".split without parentheses works better than with them.
Re: The X Macro
http://www.reddit.com/r/programming/comments/ciq5w/the_x_macro/ I hope I don't screw up this time :D On Thu, 24 Jun 2010 17:10:35 -0500, Walter Bright wrote: http://www.drdobbs.com/blog/archives/2010/06/the_x_macro.html Even though D doesn't have a text macro preprocessor, this can be done using string mixins and a bit of CTFE. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: The future of DWT
i see. what'd you say about developing DFL and porting it to other platforms? but there is no connection with java in DFL as far as I know. -- -- Ruslan Mullakhmetov "Nick Sabalausky" wrote in message news:i00dnn$2j8...@digitalmars.com... "theambient" wrote in message news:i00ct8$2ho...@digitalmars.com... Is there any sense in developing DWT cause there are many others gui libraries for d as dfl, GtkD, QtD ??? Yes. DFL: Windows-only. GtkD: It's GTK. GTK is shit. QtD: AIUI, still needs work and some compiler improvements. Also, DWT could probably help people porting from Java. --- Not sent from an iPhone.
Re: The X Macro
On 06/24/2010 05:10 PM, Walter Bright wrote: Even though D doesn't have a text macro preprocessor, this can be done using string mixins and a bit of CTFE. an example, taken to horrible extremes: http://www.dsource.org/projects/dexcelapi/browser/trunk/src/dxl/biff/Enums.d
Re: @property
Jonathan M Davis wrote: > writeln() isn't a property because it makes no sense to replace it with a > getter or setter. The same goes for save() or popFront() on a range. > However, things like length() and empty() are properties because they > could be replaced with functions like getLength() and isEmpty(). Okay. After some thought, I recant what I said about save (but not the rest). It's _is_ a property (or at least a pseudo-property), but it's poorly named (as Steven has been saying). Personally, I would say that for a function to make sense as a property, you should be able to rewrite its name as a getter or setter and have it make sense - e.g. length as getLength(). save doesn't work as getSave(), so it's poorly named. Something like copy - therefore getCopy() as a getter - would make more sense. dup would be even better, but I'm not sure that that would work given how dup is already used with arrays. In any case, I'd say it's a pseudo-property rather than a property because it really isn't a property of the range. It's returning a copy of the range rather than any property of that range. It would make no sense whatsoever for save to be a member variable of the range. But it _does_ make sense to have a getter which returns a copy, so save is definitely one of those weird cases where something is a property, but it isn't. In this case, Andrei appears to have chosen for it to be a property. - Jonathan M Davis
Re: @property
On 06/25/2010 12:51 AM, Jonathan M Davis wrote: writeln() isn't a property because it makes no sense to replace it with a getter or setter. The same goes for save() or popFront() on a range. However, things like length() and empty() are properties because they could be replaced with functions like getLength() and isEmpty(). I don't think the rule applies universally. For example, .NET is full of functions starting with Set/Get that are not properties because they perform complex/lengthy computations or for some other washy reason.
Re: @property
Max Samukha wrote: > On 06/25/2010 12:51 AM, Jonathan M Davis wrote: > >> >> writeln() isn't a property because it makes no sense to replace it with a >> getter or setter. The same goes for save() or popFront() on a range. >> However, things like length() and empty() are properties because they >> could be replaced with functions like getLength() and isEmpty(). >> > > I don't think the rule applies universally. For example, .NET is full of > functions starting with Set/Get that are not properties because they > perform complex/lengthy computations or for some other washy reason. Well, that means that they probably decided that not only do properties have to essentially be nicer getters and/or setters but that they have to be at least close to as efficient as getting or setting a public member variable - likely at minimum requiring that they be O(1). Also, there are functions - particularly for getters - where it makes sense to start them with get or set but where they really aren't properties of the object - rather the object is fetching whatever you asked it to get rather than returning the value of one of its member variables. Still, there are bound to be cases that are a bit fuzzy. save is one example that we have in D already (aside from the naming issue). Naming functions can be a hard thing to do. But I think that the basic idea that a property is effectively a fancy member variable is the basic grounds for choosing whether a particular function counts as a property or not. As with many things, however, it's up to the programmer to decide exactly what to do in a given situation, and applying rules too strictly can cause other problems. - Jonathan M davis
Re: @property
Pelle: > Is split a property? It doesn't mutate a string, and totally could be an > instance variable for every given string, but isn't. It doesn't really > feel property-like, but writing "a b c".split without parentheses works > better than with them. "a b c".split() is better. Bye, bearophile
Re: The X Macro
Walter Bright: > Even though D doesn't have a text macro preprocessor, this can be done using > string mixins and a bit of CTFE. Static introspection to the rescue! :-) Bye, bearophile
Re: cent/ucent
bearophile wrote: This is one of the last dmd changes: http://www.dsource.org/projects/dmd/changeset/557 cent/ucent are probably easy to implement, their implementation can require little code on 64 bit systems, and operations done among them are probably fast on 64 bit systems. Whether it's implemented any time soon or not, I'd like the "feature" whereby trying to use cent/ucent is a _syntax_ error to be finally removed. In the current state of things, making code forward compatible is a nightmare, and the later it's left the less backward compatible any code using cent/ucent can expect to be. http://d.puremagic.com/issues/show_bug.cgi?id=785 Unfortunately it's now too late for libraries targeting D 1.0 to make use of it. But still, would it make sense to drop the fix into D1, given that there is still work to do on the spec anyway? Stewart.
Re: @property
Steven Schveighoffer Wrote:
> Save is not as obvious, but that's because the author decided the name
> without considering whether it should be a property. If it should be
> considered a property, it should be a noun (not a hard rule, but it makes
> more sense that way). I'd say something like 'copy' would look better as
> a property. But IMO, save provides almost no utility so that leads to it
> being hard to name. Blaming property syntax is not the way out.
Personally I think of a property as something that makes sense for you to "get"
something and to "set" something. Sure you might provide only one of those
options to control interaction, but I have a hard time seeing 'copy' as a
property since you wouldn't want to write:
a.copy = "this is a copy of a";
Now, on the other side of things, calling functions without parenthesis. I
don't have many issues with this except these points, and neither of these have
been resolved with the current situation.
* Allows ambiguous-looking code:
int delegate() foo() {
return delegate int(){ return 5; };
}
// Is this an int or a delegate?
auto x = foo();
// Is this a reference to foo, or a reference to the delegate returned by
foo?
auto y = &foo;
* Cannot use +=, -=, etc.
Re: The X Macro
Yao G. wrote: http://www.reddit.com/r/programming/comments/ciq5w/the_x_macro/ I hope I don't screw up this time :D Autobanned again, sigh.
std.functional.curry isn't
Hi folks,
The template "std.functional.curry(alias fun, alias arg)" claims to
"curry fun by tying its first argument to a particular value."
That is not currying; it is partial application. In particular, it is a
kind of partial application called a "left section," because the argument
provided is partially applied as the left-hand argument of the binary
function.
Partial application takes a binary function and a value, and returns a
unary function.
Currying takes a binary function and returns a unary function, which
returns a unary function.
Let [A,B]-> C be the type of binary functions taking arguments of types A
and B, and returning a value of type C. A unary function from B to C can
be written [B]->C.
left section: [ ([A,B]->C), A ] -> ([B] -> C).
right section: [ ([A,B]->C), B ] -> ([A] -> C).
curry: [ ([A,B]->C) ] -> ([A] -> ([B] -> C)).
The example in the std.functional documentation:
int fun(int a, int b) { return a + b; }
alias curry!(fun, 5) fun5;
assert(fun5(6) == 11);
If this were a real curry, you would write it like this:
int fun(int a, int b) { return a + b; }
assert(curry!(fun)(5)(6) == 11);
Confusing curring and partial application is a very common mistake. But
please rename this template in std.functional. It makes the
std.functional module look amateurish to have such an error.
I'd vote for "template partial(alias fun, alias arg)" and "template
partialR(alias fun, alias arg)" for left and right sections. It's
unlikely that you really need a "curry" template at all.
Regards,
Graham
Re: GUI Library for D2+Phobos
It seems to me that dfl is bold in a way. I built simple app with single window and the footprint about 1 mb. also it has a lot of dll dependencies. I compared it with winx C++ Gui library - footprint is about 50 k. Still smaller than wxWidgets' one, still less dependent than in VCL. I agree 1MB is quite a lot for a program that does nothing, but in my short experience with D even some tiny console apps easily grow to that limit.
Re: std.functional.curry isn't
On Thu, Jun 24, 2010 at 5:06 PM, Graham Fawcett wrote:
> Hi folks,
>
> The template "std.functional.curry(alias fun, alias arg)" claims to
> "curry fun by tying its first argument to a particular value."
>
> That is not currying; it is partial application. In particular, it is a
> kind of partial application called a "left section," because the argument
> provided is partially applied as the left-hand argument of the binary
> function.
>
> Partial application takes a binary function and a value, and returns a
> unary function.
>
> Currying takes a binary function and returns a unary function, which
> returns a unary function.
>
> Let [A,B]-> C be the type of binary functions taking arguments of types A
> and B, and returning a value of type C. A unary function from B to C can
> be written [B]->C.
>
> left section: [ ([A,B]->C), A ] -> ([B] -> C).
> right section: [ ([A,B]->C), B ] -> ([A] -> C).
> curry: [ ([A,B]->C) ] -> ([A] -> ([B] -> C)).
>
> The example in the std.functional documentation:
>
> int fun(int a, int b) { return a + b; }
> alias curry!(fun, 5) fun5;
> assert(fun5(6) == 11);
>
> If this were a real curry, you would write it like this:
>
> int fun(int a, int b) { return a + b; }
> assert(curry!(fun)(5)(6) == 11);
>
> Confusing curring and partial application is a very common mistake. But
> please rename this template in std.functional. It makes the
> std.functional module look amateurish to have such an error.
>
> I'd vote for "template partial(alias fun, alias arg)" and "template
> partialR(alias fun, alias arg)" for left and right sections. It's
> unlikely that you really need a "curry" template at all.
>
> Regards,
> Graham
>
Agreed. I brought up the same thing back when curry() was just an
example in the documentation of variadic templates.
--bb
Re: The X Macro
:'( On Thu, 24 Jun 2010 18:55:52 -0500, Walter Bright wrote: Yao G. wrote: http://www.reddit.com/r/programming/comments/ciq5w/the_x_macro/ I hope I don't screw up this time :D Autobanned again, sigh. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Question about the validness of code examples in the docs
Hi, I'm doing a review of the language reference documentation. What I've noticed in a lot of the example code is that it is not syntactically correct. Sometimes, this is wanted behavior. For example, take this Array Length code example: int[4] foo; int[] bar = foo; int* p = &foo[0]; // These expressions are equivalent: bar[] bar[0 .. 4] bar[0 .. $] bar[0 .. bar.length] p[0 .. $] // '$' is not defined, since p is not an array bar[0]+$// '$' is not defined, out of scope of [ ] bar[$-1]// retrieves last element of the array The goal of this example is to show that the dollar symbol is not available for pointers, or when it is outside the scope of the array. So the example should not compile. The above code won't compile, which was expected, but it won't compile for a number of different reasons: (1) Statement terminators are missing, (2) The expressions have no effect, "array[2];" doesn't mean anything to the compiler and it will complain about it, and finally (3) $ is undefined in those two expressions, just like noted in the comments This is a trivial example, but other examples have even worse broken syntax. In one code example taken from the docs, I got this little monster of an error message: foreach_test.d(38): Error: function object.AssociativeArray!(const(char)[],double).AssociativeArray.opApply (scope int delegate(ref const(char)[], ref double) dg) is not callable using argument types (int delegate(ref double __applyArg0, ref char[] __applyArg1)) foreach_test.d(38): Error: cannot implicitly convert expression (__foreachbody524) of type int delegate(ref double __applyArg0, ref char[] __applyArg1) to int delegate(ref double) With all of that said, the above Array Length example would then possibly look like this instead: int[4] foo; int[] bar = foo; int* p = &foo[0]; // These expressions are equivalent: writeln( bar[] ); writeln( bar[0 .. 4] ); writeln( bar[0 .. $] ); writeln( bar[0 .. bar.length] ); writeln( p[0 .. $] ); // '$' is not defined, since p is not an array writeln( bar[0]+$ ); // '$' is not defined, out of scope of [ ] writeln( bar[$-1] );// retrieves last element of the array Now the compiler would only complain about the undefined dollar sign, which is what the code example was trying to show in the first place. My question to Walter/Andrei and the community is, would you rather see compilable examples which show you the same errors (if any) as noted in the code comments, or leave the code examples as they were?
Re: std.functional.curry isn't
Graham Fawcett:
> If this were a real curry, you would write it like this:
> int fun(int a, int b) { return a + b; }
> assert(curry!(fun)(5)(6) == 11);
Right. Better to change the name.
Regarding std.functional, are the HOF adjoin(), compose() and pipe() useful? I
don't think I'll use compose() or pipe(). If not enough people find them
useful, then they can be removed.
There is something that instead I'd like added (that I am going to put as
request in Bugzilla, maybe later today):
Apply functionality is quite useful, as shown by this small Python program that
prints "1, 2":
def foo(x, y):
print x, y
tuple1 = (1, 2)
foo(*tuple1)
That star syntax of Python is equivalent to this, that works still in Python
2.x:
apply(foo, tuple1)
The star syntax can't be used in D, but a good apply() function can be useful
in D too. There the tuple is of course a std.typecons.Tuple.
Bye,
bearophile
Re: cent/ucent
Stewart Gordon: > Unfortunately it's now too late for libraries targeting D 1.0 to make > use of it. But still, would it make sense to drop the fix into D1, > given that there is still work to do on the spec anyway? D1 is mostly in debug mode now. In my opinion specs and other more complex jobs about D1 are going to be delayed indefinitely by Walter. So I think future changes to D1 will need to come from the community, like Tango users interested in keeping D1 alive. Bye, bearophile
Re: @property
On Thu, 24 Jun 2010 16:21:37 -0400, Pelle wrote: As heard around these parts, a lot of people want property-style function calls to require the function to be declared with @property, like this: @property foo(); //getter @property foo(int); //setter foo; //getter foo = 13; //setter While this seems quite reasonable, in practice I and others feel this leads to confusion, especially the getter part. Mostly when the getter has no setter counterpart. D also lets us call no-argument functions without parentheses today, so for this to happen a lot of code needs to change. My suggestion is as follows; require @property for single-argument setters *only*. Make the silly writeln = 13; go away, but keep the "a b c".split;. This way, there can be no confusion about @property, and most code will go unchanged. I hope this was not too late a suggestion. :) writeln = 13; doesn't compile, just so you know. ;)
Re: Mac OS X Installation
On Thu, 24 Jun 2010 13:30:31 -0400, Nick Sabalausky wrote: > > "Justin Spahr-Summers" wrote in message > news:mpg.268ca23b487143c5989...@news.digitalmars.com... > > On Thu, 24 Jun 2010 01:29:53 -0500, Andrei Alexandrescu > > wrote: > >> > >> On 06/23/2010 11:52 PM, ch...@freshsources.com wrote: > >> > I have successfully installed D 2.0 on a number of Macs. However, the > >> > latest attempt yields the following error when I try to compile any > >> > file: > >> > > >> > object.d: Error: module object is in file 'object.d' which cannot be > >> > read > >> > import path[0] = /etc/../../src/phobos > >> > import path[1] = /etc/../../src/druntime/import > >> > > >> > As usual, I faithfully followed the instructions at > >> > > >> > http://www.digitalmars.com/d/2.0/dmd-osx.html > >> > > >> > Any ideas on how to fix this? Thanks. > >> > >> Hi, Chuck! > >> > >> Looks like the files aren't where they are supposed to be. Try this: > >> > >> head /etc/../../src/druntime/import/object.di > >> > >> Normally you should see the first ten lines of that file. If there's an > >> error, write back what the error message is. > >> > >> > >> Andrei > > > > Isn't /etc/../.. the root directory? That seems like an awfully > > incorrect place to the put the includes. > > > > No, "/etc/../" is root. "/etc/../../" is "/.." (ie parent of root), which is > nonsensical. > > --- > Not sent from an iPhone. /etc is a soft link to /private/etc on all OS X systems I've seen. I also think /.. always refers to / on *nix, but I could be wrong there.
Re: std.functional.curry isn't
On 06/24/2010 07:06 PM, Graham Fawcett wrote: Hi folks, The template "std.functional.curry(alias fun, alias arg)" claims to "curry fun by tying its first argument to a particular value." That is not currying; it is partial application. [...] Confusing curring and partial application is a very common mistake. But please rename this template in std.functional. It makes the std.functional module look amateurish to have such an error. Hm, fine. The whole curry thing was an experiment that I put on hold because back then I couldn't support functions with any number of arguments, which puts a damp on enthusiasm. I suggest you to send a patch to bugzilla in case you have the time. Andrei
Re: std.functional.curry isn't
On 06/24/2010 07:37 PM, bearophile wrote:
Graham Fawcett:
If this were a real curry, you would write it like this: int
fun(int a, int b) { return a + b; } assert(curry!(fun)(5)(6) ==
11);
Right. Better to change the name.
I think it would be even better to redefine curry to do actual currying.
Regarding std.functional, are the HOF adjoin(), compose() and pipe()
useful? I don't think I'll use compose() or pipe(). If not enough
people find them useful, then they can be removed.
I'm finding them quite useful, particularly in conjunction with e.g. map.
Andrei
Re: @property
Max Samukha Wrote: > I don't think the rule applies universally. For example, .NET is full of > functions starting with Set/Get that are not properties because they > perform complex/lengthy computations or for some other washy reason. In .Net it is generally not a good idea to write a getter property that changes the object in any way (i.e. they should be written as pure read only). And why is that you ask? Because when you watch a object in the debugger the debugger extracts the object debug information by calling the these getter properties. So if the object properties are written badly and change the object, then by just adding that object to a watch window or hovering over it with the mouse will result in the corruption of the object. This can make for some very interesting debugging.
Re: cent/ucent
bearophile wrote: > This is one of the last dmd changes: > http://www.dsource.org/projects/dmd/changeset/557 > > cent/ucent are probably easy to implement, their implementation can > require little code on 64 bit systems, and operations done among them are > probably fast on 64 bit systems. > > 128 bit unsigned numbers can represent: > 340_282_366_920_938_463_463_374_607_431_768_211_455 > Many normal programs don't overflow such numbers. A cent number can also > be used to store safely the result of many operations done on 64 bit > values. And generally I like the idea of having them... > > But while I know of few scientific computations situations where quadruple > precision floating point numbers can be useful, in practice I don't know > of situations where cent/ucent can be useful. > > One possible situation where ucent can be useful is to perform bitwise > operations on 128-bits-wide SSE registers. But a good D compiler can use > exactly the same CPU instructions when those operators are used among > uint[4] fixed-sized arrays. > > So unless some significant application can be found, I suggest to not add > cent/ucent. All features in the language need a purpose, adding useless > things is bad. They can be kept among reserved keywords (as 'macro') for > possible 128-bit CPUs. > > On the other hand instead of cent/ucent I have several situations (not > related with cryptography) where I'd like in D a built-in "bint" or > "bigint", that is the multi-precision integers (currently in a std.bigint > module... well, the module was present in 2.046, I can't see it in Phobos > of 2.047, I don't know why). Having it built-in allows for better > multi-precision literals. > > (There are other number types that probably are more useful than > cent/ucent, like a decimal floating point (IEEE standard 854-1987), useful > for concurrency.) > > Bye, > bearophile cent and ucent are not currently implemented and have no need to be implemented at this point. They are reserved for when they will be deemed useful enough to implement (perhaps when we actually have 128-bit machines). In the meantime, I see no need to worry about it. They'll get implemented when it's appropriate. For now, we can just leave them as reserved and not worry about them. The fact that they exist makes it possible to implement them later without breaking backwards compatibility. - Jonathan M Davis
Re: std.functional.curry isn't
Andrei Alexandrescu: > I think it would be even better to redefine curry to do actual currying. Right. > I'm finding them quite useful, particularly in conjunction with e.g. map. Oh, OK. Then let's keep them :-) What do you think about the apply? Bye, bearophile
Re: cent/ucent
Jonathan M Davis: > cent and ucent are not currently implemented and Isn't changeset 557 showing some work to implement them? Bye, bearophile
Re: The X Macro
Yao G. wrote: :'( On Thu, 24 Jun 2010 18:55:52 -0500, Walter Bright wrote: Yao G. wrote: http://www.reddit.com/r/programming/comments/ciq5w/the_x_macro/ I hope I don't screw up this time :D Autobanned again, sigh. Why don't we just give up on reddit and go with http://news.ycombinator.com/ ?
Re: The X Macro
On 06/25/2010 07:10 AM, Walter Bright wrote:
http://www.drdobbs.com/blog/archives/2010/06/the_x_macro.html
Interesting technique that I haven't heard of. However one of my
friends, a lead programmer at Sega, says they use similar technique
extensively in C++; actually they avoid overusing it, as it slows down
compilation considerably.
And for this particular Color case, enum in D can have a base type:
enum Color: string {
RED = "red",
GREEN = "green",
BLUE = "blue",
}
writeln(Color.RED); // gives "red"
so we don't have that maintainance problem :-)
Re: Mac OS X Installation
"Justin Spahr-Summers" wrote in message news:mpg.268da2399e25e4f9989...@news.digitalmars.com... > On Thu, 24 Jun 2010 13:30:31 -0400, Nick Sabalausky wrote: >> >> No, "/etc/../" is root. "/etc/../../" is "/.." (ie parent of root), which >> is >> nonsensical. >> >> --- >> Not sent from an iPhone. > > /etc is a soft link to /private/etc on all OS X systems I've seen. I > also think /.. always refers to / on *nix, but I could be wrong there. Ahh, news to me.
Re: enforce()?
Lutger wrote: > Sean Kelly wrote: > >> Sean Kelly Wrote: >>> >>> While I've never worked on systems where lives hang in the balance, > > > I have >>> worked on systems where 100% uptime is required. I favor the Erlang > > > approach >>> where a system is a web of interconnected, redundant processes that > > > terminate >>> on errors. I've found this design an extremely hard sell in the > > > internet >>> server world though. The design takes more planning and people are > > > in too >>> much of a hurry. >> >> I should add that I'm hoping the message passing model in D will help >> encourage reliable system design. With thread isolation it should be > > pretty >> easy to move parts of a program into separate processes as need > > dictates. > > Can we look forward to seeing ipc supported in phobos via the same > interface in > the future? I really like the api you have created. Yes. The core send/receive API should work just fine for IPC, and it's definitely on the map. The greatest obstacle there is probably the need for a solid serialization/deserialization package in Phobos.
Re: The X Macro
On Thu, 24 Jun 2010 19:09:36 -0700, Walter Bright wrote: > Yao G. wrote: >> :'( >> >> On Thu, 24 Jun 2010 18:55:52 -0500, Walter Bright >> wrote: >> >>> Yao G. wrote: http://www.reddit.com/r/programming/comments/ciq5w/the_x_macro/ I hope I don't screw up this time :D >>> >>> Autobanned again, sigh. >> >> >> > Why don't we just give up on reddit and go with > http://news.ycombinator.com/ ? I prefer the reddit community, and the way reddit handles conversation threading. Perhaps you could email the Reddit guys and see why they keep getting autobanned?
Re: The X Macro
Bernard Helyer wrote: On Thu, 24 Jun 2010 19:09:36 -0700, Walter Bright wrote: Why don't we just give up on reddit and go with http://news.ycombinator.com/ ? I prefer the reddit community, and the way reddit handles conversation threading. Perhaps you could email the Reddit guys and see why they keep getting autobanned? I did - no reply.
Re: The X Macro
Yao G. wrote: http://www.reddit.com/r/programming/comments/ciq5w/the_x_macro/ Even with it banned, it has gotten 5 downvotes, so it must be lurkers here. Any downvoters care to say what's wrong with it?
