Re: DVM - D Version Manager
On 2011-01-26 23:46, Michel Fortin wrote: On 2011-01-26 15:24:56 -0500, Jacob Carlborg d...@me.com said: /bin/sh is not a symlink on Mac OS X. I guess I just can try to use sh instead of bash. But should it output this? $ /bin/sh --version GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0) Copyright (C) 2007 Free Software Foundation, Inc. $ This is on Mac OS X 10.6.6. I have no idea. Perhaps it will run bash in a mode which is compatible with sh. -- /Jacob Carlborg
Re: DVM - D Version Manager
Am 27.01.2011 13:05, schrieb Jacob Carlborg: On 2011-01-26 23:46, Michel Fortin wrote: On 2011-01-26 15:24:56 -0500, Jacob Carlborg d...@me.com said: /bin/sh is not a symlink on Mac OS X. I guess I just can try to use sh instead of bash. But should it output this? $ /bin/sh --version GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0) Copyright (C) 2007 Free Software Foundation, Inc. $ This is on Mac OS X 10.6.6. I have no idea. Perhaps it will run bash in a mode which is compatible with sh. Or just in normal mode, like linux distributions have been done for ages (and some still do). bash *is* compatible with sh (= everything that runs in sh runs in bash), but sh is not compatible with bash (= bash has features that other sh-compliant shells don't have and that are not required by the corresponding POSIX standard).
A few improvements to SortedRange
I just committed a few improvements to phobos' SortedRange, notably adding various search policies and improving the existing routines. These changes will be rolled out in the next dmd release. Until then, feel free to suggest any improvements. https://github.com/D-Programming-Language/phobos/commit/b6aabf2044001ea61af15834dcec5855680cf209 http://d-programming-language.org/cutting-edge/phobos/std_range.html#SearchPolicy http://d-programming-language.org/cutting-edge/phobos/std_range.html#SortedRange Andrei
Re: A few improvements to SortedRange
Andrei: I just committed a few improvements to phobos' SortedRange, notably adding various search policies and improving the existing routines. These changes will be rolled out in the next dmd release. Until then, feel free to suggest any improvements. That SearchPolicy will be enough for maniacs too (it just lacks optional galloping sound effects), very good Andrei :-) Bye, bearophile
Re: A few improvements to SortedRange
On 1/27/11 12:43 PM, bearophile wrote: Andrei: I just committed a few improvements to phobos' SortedRange, notably adding various search policies and improving the existing routines. These changes will be rolled out in the next dmd release. Until then, feel free to suggest any improvements. That SearchPolicy will be enough for maniacs too (it just lacks optional galloping sound effects), very good Andrei :-) Bye, bearophile In fact I implemented it because many large-scale algorithms (such as n-way merge or intersection) use galloping search as a primitive. One nice perk is that having galloping search available allowed me to improve equalRange, which is often of use in casual applications. Right now equalRange is arguably better than all other implementations I've seen because once it found one element that's inside the equal range, it performs galloping searches to the left and to the right to find the limits of that range. Other implementations I've seen use straight binary search for finding those limits, which I think is inferior because most often the limits of the equal range are close to the found point. Andrei
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
Vladimir Panteleev wrote: On Wed, 26 Jan 2011 23:22:34 +0200, Don nos...@nospam.com wrote: Vladimir Panteleev wrote: On Wed, 26 Jan 2011 06:33:35 +0200, Don nos...@nospam.com wrote: I think this is a fallacy. It only applies if you (1) *completely disallow* any centralisation -- which I don't think ever happens in practice! What about the Linux kernel? There's Linus's git repo, and lots of repos maintained by others (e.g. Linux distros). The other distros are not a superset of Linus's repo, they have their own branches with various project-specific patches and backports. Git was written for this specifically. Yes, but each distro has a trunk, in which all commits are ordered by time. There's always an official version of every branch. Ordered by time of what? Time of merging into the branch? That's not very useful, is it? They can't be ordered by time of authorship, for certain. Official is technically meaningless in a DVCS, because no repository is holy by design (otherwise it wouldn't be really distributed). Yes, in theory that's true. In practice, I don't believe it. Just because you're using a DVCS doesn't mean you have no project organisation whatsoever. There's always going to be a repository that the release is made from. If the maintainer of a repository becomes MIA, anyone can take over without any problems. and (2) demand that cloning a repository be an entirely read-only operation (so that the repository doesn't know how many times it has been cloned) and (3) demand that the revision numbers behave exactly as they do in svn. Then you're suggesting that the commit identifiers basically contain the clone history? Yes, I think it could be done that way. Identifier would be composed of clonenumber+commitnumber. Where it is the location of the original change. Yes, there are difficulties with this scheme, but I think they are the same challenges as for implementing merges on a centralised VCS such as Subversion. I don't think there's anything insurmountable. Then a clone of a clone of a clone of a clone needs four clone numbers, plus a revision number. It'd look something like 5:1:2:1:1056. No. Just one repository number, and one revision number. You just need to be sensible in how the clone numbers are assigned. That's easy. Basically every repository has a number of clone numbers it can assign. Every clone gets a subset of that range. Dealing with the situation when the range has run out is a bit complicated, but quite doable, and there are steps you can take to make it a very rare occurence. I'm not have almost zero interest in this stuff, so I won't say any more. I'm really just commenting that it's not difficult to envisage an algorithm which makes exposing a random hash unnecessary.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
Bill Baxter wbax...@gmail.com wrote in message news:mailman.977.1296083661.4748.digitalmars-d-annou...@puremagic.com... Mercurial gives every revision two numbers: Is that the kind of thing you're wanting? Yea, and that's pretty much the original thing I was saying: It's nice that Hg seems to have it, but Git doesn't appear to be particularly interested in it.
Re: D Programming Language source (dmd, phobos, etc.) has moved to github
On Thu, Jan 27, 2011 at 1:13 PM, Nick Sabalausky a@a.a wrote: Bill Baxter wbax...@gmail.com wrote in message news:mailman.977.1296083661.4748.digitalmars-d-annou...@puremagic.com... Mercurial gives every revision two numbers: Is that the kind of thing you're wanting? Yea, and that's pretty much the original thing I was saying: It's nice that Hg seems to have it, but Git doesn't appear to be particularly interested in it. I think it's very handy for all the reasons you said. I don't think I've every had to use a big hex string when dealing with mercurial. Maybe once or twice max. Most of the stuff you do with repo history as an individual developer is all about the local copy of the tree on your system. Globally unique identifiers aren't needed for that. It looks like Bzr does something similar. Not sure why Git hasn't gotten this particular nicety. --bb
Re: DVM - D Version Manager
Jacob Carlborg wrote: On 2011-01-26 21:04, Jérôme M. Berger wrote: You cannot. You need to modify the environment for the current shell, which is the shell that the user is currently using (no matter what else may or may not be installed on the system). This has two consequences: - You need to have some code that is run when the shell starts (i.e. from .bashrc, .zshrc or .kshrc). That code will define the proper aliases and/or functions (at the time being, this is mostly the dvm function in dvm.sh (*)). This can be accomplished by having a different version of this file for each shell; Is it possible to detect what shell is running and then load the correct version? Since each shell sources a different file on startup, you can source the correct version from the startup file. On installation, the SHELL environment variable should tell you which shell is used. - You need to generate the contents of $dvm_result_path in a format that the shell will understand. The easiest way to do that is probably to define a few extra functions in dvm.sh to enable setting environment variables in a portable way and handle additional requirements (like builtin hash -r which is definitely a bash-ism). Then generate the $dvm_result_path using these functions instead of the normal shell syntax. The contents of $dvm_result_path will only export one variable. Do not you need to call builtin hash -r each time you change the path (I do not know since I am not a bash user)? If not, why do you need to call it in __dvm_setup_environment? Jerome (*) BTW, I hope you do not add the full contents of dvm.sh nor a source dvm.sh in .bashrc the way it is now. Otherwise, a misconfiguration may prevent the user from starting a shell! OK, how else can I do the same thing? BTW this is how RVM (Ruby Version Manager) works, where I got the idea from. The whole RVM is written in shell script and it's sourced in .bashrc. Remove the call to exit and wrap the rest of the file in a if [[ ! -z $dvm_prefix ]] ; then ... So the file will look like: ==8-- if [[ -z $dvm_prefix ]] ; then if [[ -n $HOME ]] ; then dvm_prefix=$HOME/. else echo No \$dvm_prefix was provided and echo $(id | \sed -e's/^[^(]*(//' -e 's/).*//') has no \$HOME defined. fi fi if [[ ! -z $dvm_prefix ]] ; then ... fi --8== Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: D Programming Language source (dmd, phobos,etc.) has moved to github
Nick Sabalausky wrote: Bill Baxter wbax...@gmail.com wrote in message news:mailman.977.1296083661.4748.digitalmars-d-annou...@puremagic.com... Mercurial gives every revision two numbers: Is that the kind of thing you're wanting? Yea, and that's pretty much the original thing I was saying: It's nice that Hg seems to have it, but Git doesn't appear to be particularly interested in it. Of course, Git does not have it! Svn has it so it *must* be a bad idea ;) Jerome PS: FWIW, I agree with you. Plus, there is another use case where sequential number are very useful: each time you want to operate on a past revision in your own repository (e.g hg up n or hg diff -r n), it is much easier to designate that revision with a sequential number than with the hash. -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: dlist for phobos
Andrei: I'm also undecided on what to do about sealing, and again language improvements (preventing escapes of references) could lead to improved designs. Language improvements need to be understood, desired, designed, and then implemented and debugged, so what kind of syntax and semantics are you thinking about? Bye, bearophile
Re: Is D still alive?
spir:
Sorry, but you are wrong on this. I understand this sounds unsafe, but no.
Most
languages, I guess, just do that without any worry. In particular, I have
frequented python and Lua mailing lists for years without even reading once
about this beeing a misfeature (and indeed have never run into a bug because
of
this myself). It is simply the right semantics in 99.999% cases.
Thank you for raising this topic again. I have raised it probably more than one
year ago, and all people around here were against this. This is not unsafe,
it's actually safer than the current D behaviour. Python designers don't think
this is a badly designed part of Python, they think this is as desired, and I
too have never seen people complain about this being a bad or bug prone design.
An example of Python code:
s = abcdefg
upper = 20
s2 = s[2 : upper]
assert s2 == cdefg
Equivalent D2 code, if you forget to use the min() you are doomed:
import std.algorithm: min;
void main() {
string s = abcdefg;
int upper = 20;
string s2 = s[2 .. min($, upper)];
assert(s2 == cdefg);
}
The saturating nature of Python slice bounds is a safety net that's useful to
avoid some troubles. The only good thing of the D2 design is that it performs
less tests at runtime (it has no need to call min() in general), this is a bit
positive in a system language, but in this case it has a cost in safety.
Bye,
bearophile
Re: Hot for dmd 64bit
Killing D (at least for me) is the limit choices for compiling on 64-bit Linux with D2 and preferably Phobos instead of Tango. I do think GDC is the most stable D2 x64 solution at the moment. Especially since you're on Linux it shouldn't be too hard to compile it (while it still is a PITA on Windows)
Re: Is D still alive?
Wed, 26 Jan 2011 14:39:08 -0500, Steven Schveighoffer wrote: I will warn you, once you start using D, you will not want to use something else. I cringe every day when I have to use PHP for work. Nice trolling.
Re: Is D still alive?
Wed, 26 Jan 2011 15:35:19 -0500, Steven Schveighoffer wrote: I'd suggest to anyone looking to use D for something really big to try and prove out how well D will perform for you by coding up bits of your whole project that you think will be needed. Hopefully, you can do everything without hitting a mercy bug and then you can write your full project in it. I think this reveals a lot about D. You still need to prove things. Or maybe the community members in general aren't very good developers; they can't see the potential of this language. The fact is, no matter what language you choose, if it isn't a complete joke, you can finish the project. (I'm assuming the community members here won't be writing any massive projects which are not possible to do in C++ or PHP or Java.) I don't see any need to prove how well Haskell works. Even though it's a avoid success at all costs experimental research language. It just works. I mean to the extent that I'm willing to go with these silly test projects that try to prove something.
Re: Is D still alive?
Wed, 26 Jan 2011 14:09:25 -0800, Walter Bright wrote: Trass3r wrote: But once you had a test drive, you just can't get out anymore. I've had more than one longtime C++ expert tell me that after using D for a while, then for work reasons get forced back into C++, just find themselves cringing every time they edit it. I also got brainwashed by the C++ advocates years ago. However, I didn't need D to see how terrible writing C++ is. C++ sure is a powerful language and sometimes a necessary evil, but you don't really need very strong doses of more recent languages to see how much nicer everything else is.
Re: Is D still alive?
Wed, 26 Jan 2011 23:33:54 +0100, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Yep, those were to reasons that lured me to learn Java. However, those were not the reasons to learn D. The main reasons were RAII and Design by Contract. Even funnier, it took D about 9 years to fix the main bug in DbC (contract inheritance).
Re: Hot for dmd 64bit
Thu, 27 Jan 2011 06:32:58 +, dwilson wrote: Beside praying and pestering, what can we D non-experts do to help get a stable 64-bit dmd available? Killer D features are strings, slick built in dynamics arrays, no headers files to keep in sync, and the other nice features often praised by others. I'm not sure yet that D is my favorite language, but it's in the list of top three. Killing D (at least for me) is the limit choices for compiling on 64-bit Linux with D2 and preferably Phobos instead of Tango. My setup, for reasons I haven't investigated deeply, can't run 32-bit anything, and I do intend to work on huge arrays of data, a few GB in RAM. As for Phobos, it's obviously more Mars-related than Tango :) Didn't Walter say about one year ago that it only takes 1-2 months to finish the 64-bit port.
Re: Git Contributors Guide (Was: Re: destructor order)
On Thu, 27 Jan 2011 00:26:22 +0200, Ulrik Mikaelsson ulrik.mikaels...@gmail.com wrote: The way I will show here is to gather up your changes in a so-called bundle, which can then be sent by mail or attached in a bug-tracker. First, some terms that might need explaining. Many open-source projects that use git use patches generated by the format-patch command. Just type git format-patch origin. Unless you have a LOT of commits, patches are better than binary bundles, because they are still human-readable (they contain the diff), and they also preserve the metadata (unlike diffs). You can even have git e-mail these patches to the project's mailing list. The second and following patches are sent as a reply to the first patch, so they don't clutter the list when viewed in threading mode. http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html http://www.kernel.org/pub/software/scm/git/docs/git-send-email.html -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
DMD for FreeBSD
Hello! I'm slowly heading towards Free(PC)BSD (from Linux) and wonder what is the status of dmd2 there? http://www.digitalmars.com/d/1.0/dmd-freebsd.html page speaks only about 32bit dmd1 for fbsd-7.1, while the ports page at FreeBSD site lists 'dmd2-2.051' with the D 2.0 compiler, not officially validated for FreeBSD note. What does it mean? Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D still alive?
retard Wrote: Or maybe the community members in general aren't very good developers; they can't see the potential of this language. The fact is, no matter what language you choose, if it isn't a complete joke, you can finish the project We have a lot of talented people in this community who've created awesome projects, I don't think it's a lack of skills. Sometimes you hit bugs you just can't workaround. In my case these included forward reference bugs where a simple exchange the declarations didn't work cause of cross-references and a nasty corrupt stack frame bug I couldn't reduce.
Re: Is D still alive?
Am 27.01.2011 01:41, schrieb spir: On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. Denis What about a[1.. min(x, $)]. (min from std.alorithm)? Mafi
Re: Hot for dmd 64bit
Didn't Walter say about one year ago that it only takes 1-2 months to finish the 64-bit port. He probably meant 1~2. :) This is quite common for programmers, no?
Re: Is D still alive?
On 01/27/2011 04:06 AM, Jonathan M Davis wrote: Clearly, if you think that not being strict about indices is a good idea, you're either dealing with very different circumstances than I have and/or you're coding very differently. Regardless, since it's trivial to create a wrapper that does what you want, I don't think that there's any reason to change how slicing works. I would agree with you be reasoning in pure air (I mean without having used both semantic versions). But concrete experience (of a huge number of programmers) in widely used programming languages demonstrate the opposite. Slice /upper/ bound checking is an idea that looks good in theory but is not in practice. Denis -- _ vita es estrany spir.wikidot.com
Re: Is D still alive?
On 01/27/2011 01:24 PM, Mafi wrote: Am 27.01.2011 01:41, schrieb spir: On 01/26/2011 11:33 PM, Trass3r wrote: For me, D's killer features were string handling (slicing and appending/concatenation) and *no header files*. (No more header files!! Yay!!!). But auto is fantastic too though, I get sooo much use out of that. Getting rid of the pointer crap (proper arrays, bounds checking, classes as reference types,...) is definitely among the top 10 on my list. Same here. But I would prefere slicing not to check upper bound, rather just extend to the end. Or have a slicing variant do that. Denis What about a[1.. min(x, $)]. (min from std.alorithm)? Yes, that's it. Denis -- _ vita es estrany spir.wikidot.com
Re: const(Object)ref is here!
On 21/12/2010 19:17, Andrei Alexandrescu wrote: On 12/21/10 12:19 PM, Steven Schveighoffer wrote: On Tue, 21 Dec 2010 13:10:12 -0500, Bruno Medeiros brunodomedeiros+spam@com.gmail wrote: On 06/12/2010 19:00, Jonathan M Davis wrote: On Monday, December 06, 2010 05:41:42 Steven Schveighoffer wrote: On Mon, 06 Dec 2010 04:44:07 -0500, spirdenis.s...@gmail.com wrote: On Mon, 6 Dec 2010 00:31:41 -0800 Jonathan M Davisjmdavisp...@gmx.com wrote: toString() (or writeFrom() or whatever it's going to become) guess it was writeTo() ;-) but writeFrom is nice as well, we should find some useful use for it It was proposed as writeTo, but I'm not opposed to a different name. I have no problem with writeTo(). I just couldn't remember what it was and didn't want to take the time to look it up, and the name isn't as obvious as toString(), since it's not a standard name which exists in other languages, and it isn't actually returning anything. Whether it's to or from would depend on how you look at it - to the given delegate or from the object. But writeTo() is fine. Once it's used, it'll be remembered. I don't think it's entirely fine. It should at least have string/String somewhere in the name. (I mentioned this on the other original thread, although late in time) First, I'll say that it's not as important to me as it seems to be to you, and I think others feel the same way. writeTo seems perfectly fine to me, and the 'string' part is implied by the char[] parameter for the delegate. Changing the name to contain 'string' is fine as long as: 1) it's not toString. This is already established as returning a string in both prior D and other languages. I think this would be too confusing. 2) it's short. I don't want writeAsStringTo or something similar. What did you have in mind? -Steve Conversion to text should be called toText. That makes the essence of the function visible (it emits characters) without tying the representation of the text. Andrei I don't understand this point. The representation of the text is tied, it's going to be char[] ( aka UTF-8). Unless you were planning to have overloads of toText, but that sounds like an awful idea. -- Bruno Medeiros - Software Engineer
Re: const(Object)ref is here!
On 21/12/2010 18:19, Steven Schveighoffer wrote: On Tue, 21 Dec 2010 13:10:12 -0500, Bruno Medeiros brunodomedeiros+spam@com.gmail wrote: On 06/12/2010 19:00, Jonathan M Davis wrote: On Monday, December 06, 2010 05:41:42 Steven Schveighoffer wrote: I have no problem with writeTo(). I just couldn't remember what it was and didn't want to take the time to look it up, and the name isn't as obvious as toString(), since it's not a standard name which exists in other languages, and it isn't actually returning anything. Whether it's to or from would depend on how you look at it - to the given delegate or from the object. But writeTo() is fine. Once it's used, it'll be remembered. I don't think it's entirely fine. It should at least have string/String somewhere in the name. (I mentioned this on the other original thread, although late in time) First, I'll say that it's not as important to me as it seems to be to you, and I think others feel the same way. writeTo seems perfectly fine to me, and the 'string' part is implied by the char[] parameter for the delegate. Changing the name to contain 'string' is fine as long as: 1) it's not toString. This is already established as returning a string in both prior D and other languages. I think this would be too confusing. 2) it's short. I don't want writeAsStringTo or something similar. What did you have in mind? -Steve Sorry for the long delay in replying.. I don't have any specific favorite name. Could be writeString, asString, stringWrite, ouputString, even toString (despite a different signature from other languages), etc. Or a similar name with Text instead of String, as Andrei suggested (although I'm not 100% sure about that last one). It's just that I would prefer the String connotation to be implied in the function name, not just implied in the parameter (makes the code clearer, in a somewhat subjective opinion). And also to not take up the writeTo overload in all Objects ever, as some might want to use that overload name for their own stuff. -- Bruno Medeiros - Software Engineer
Re: Paralysis of analysis
On 14/12/2010 19:30, Andrei Alexandrescu wrote: On 12/14/10 1:19 PM, so wrote: Could you please elaborate the disadvantages part? Thanks! Whatever empty() does, it must be called against an already-allocated reference to an Array. Phew... That seems quite acceptable. For a moment, when I read your original words: - Containers must be dynamically allocated to do anything - even calling empty requires allocation. it almost reads as you saying that any and each call to empty requires an allocation... :S -- Bruno Medeiros - Software Engineer
Re: Paralysis of analysis -- the value/ref dilemma
On 15/12/2010 17:05, spir wrote:
On Wed, 15 Dec 2010 09:56:36 -0600
Andrei Alexandrescuseewebsiteforem...@erdani.org wrote:
Optimization (or pessimization) is a concern, but not my primary one. My
concern is: most of the time, do you want to work on a container or on a
copy of the container? Consider this path-of-least-resistance code:
void fun(Container!int c) {
...
c[5] += 42;
...
}
Question is, what's the most encountered activity? Should fun operate on
whatever container it was passed, or on a copy of it? Based on extensive
experience with the STL, I can say that in the overwhelming majority of
cases you want the function to mess with the container, or look without
touch (by means of const). It is so overwhelming, any code reviewer in
an STL-based environment will raise a flag when seeing the C++
equivalent to the code above - ironically, even if fun actually does
need a copy of its input! (The common idiom is to pass the container by
constant reference and then create a copy of it inside fun, which is
suboptimal.)
I do agree.
When a container is passed as parameter
* either it is a value in meaning and should be left unchanged (-- so that the compiler
can pass it as constant reference)
* or it means an entity with identity, it makes sense to change it, and it
should be implemented as a ref.
What I'm trying to fight is beeing forced to implement semantics values as
concrete ref elements. This is very bad, a kind of conceptual distortion (the
author of XL calls this semantic mismatch) that leads to much confusion.
As someone who takes conceptual cleanliness very seriously, I had to
chime in, as I don't quite agree with your points.
Example of semantic distinction:
Take a palette of predefined colors (red, green,..) used to draw visual widgets. In
the simple case, colors are plain information (=values), and the palette (a
collection) as well. In this case, every widget holds its own subset of colors used
for each part of itself. Meaning copies. Chenging a given color assigned to a
widget should does not affect others.
Now, imagine this palette can be edited live by the user, meaning redefining the components of
re, green,... This time, the semantics may well be that such changes should aaffect all widgets, including
already defined ones. For this, the palette must be implemented as an entity, and each as well.
But the reason for this is that the palette does not mean the same thing at all: instead of information about
an aspect (color) of every widget, we have now a kind of container of color _sources_. Instead of color
values, the widget fields point to kinds of paint pots; these fields should not be called color.
[It is not always that simple to find real-world metaphors helping us and correctly
understand what we have to model and write into programs. A program's world is not at all
reality, not even similar to it, even in the (minority of) cases where it models reality.
In this case, color is misleading.]
In the first case, palette must be a value, in the second case it must be a
ref. There is no way to escape the dilemma about having value or ref
collections. Conceptually, we absolutely need both. Again the ref/value
semantic duality is independant from data types. If the language provides one
kind only, we have to hack, to cheat with it.
The discussion here is simply what should be the common, default case.
Who said we can't have both? What's the justification for If the
language provides one kind only, we have to hack, to cheat with it. ??
Also, the things you say about collections being ref or value is badly
worded. First of all, considering a collection on its own, there is no
right answer to whether the collection /should/ have value or reference
semantics. The statement is meaningless.
Only when a collection is associated with some other object does this
question make sense. Is the collection part-of/owned-by the object, or
it is merely referenced by it? So taking your example, does a Widget
each have their own Palette of Colors, or is there only one common
Palette? The answer depends on your domain, this is a modeling/design
problem, not a language design one.
The only thing the language should strive for is being able to
represent/code both possible designs as well as possible (in a clear
way, less bug prone, etc.).
--
Bruno Medeiros - Software Engineer
Re: Git Contributors Guide (Was: Re: destructor order)
2011/1/27 Vladimir Panteleev vladi...@thecybershadow.net: On Thu, 27 Jan 2011 00:26:22 +0200, Ulrik Mikaelsson ulrik.mikaels...@gmail.com wrote: The way I will show here is to gather up your changes in a so-called bundle, which can then be sent by mail or attached in a bug-tracker. First, some terms that might need explaining. Many open-source projects that use git use patches generated by the format-patch command. Just type git format-patch origin. Unless you have a LOT of commits, patches are better than binary bundles, because they are still human-readable (they contain the diff), and they also preserve the metadata (unlike diffs). You can even have git e-mail these patches to the project's mailing list. The second and following patches are sent as a reply to the first patch, so they don't clutter the list when viewed in threading mode. True. The only problem with this, I think, is getting the patch out from web-based mail-readers. Key-parts of the metadata about the commit lies in the mail-header, which might not always be easily accessible in web-readers. Also, send-email is for some reason no longer included in the git-version that comes with Ubuntu 10.10. Perhaps it's been removed in later versions of git.
Re: improvement request - enabling by-value-containers
Sorry for the long delay in replying.
On 22/12/2010 12:04, Simon Buerger wrote:
On 21.12.2010 18:45, Bruno Medeiros wrote:
On 09/12/2010 21:55, Simon Buerger wrote:
From a pragmatic viewpoint you are right, copying containers is rare.
But on the other hand, classes imply a kind of identity, so that a set
is a different obejct then an other object with the very same elements.
Yeah, classes have identity, but they retain the concept of equality.
So what's wrong with that? Equality comparisons would still work the
same way as by-value containers.
Identity is wrong, because if I pass th set {1,2,3} to a function, I
would like to pass exactly these three values, not some mutable object.
This may imply that the function-parameter should be const, which is
probably a good idea anyway. I want it to be mutable, I want to use
out/ref, the same way as with the simple builtin-types.
I don't understand this, it doesn't seem to make sense. You say you
don't want the set to be some mutable object, yet also say you want
it to be mutable. Does it refer to something else? I don't get it.
Assuming just this text: Identity is wrong, because if I pass th set
{1,2,3} to a function, I would like to pass exactly these three values,
not some mutable object.
Then pass in some unmodifiable collection. Hard to suggest a better
alternative without a concrete example.
That feels wrong from an aesthetical or mathematical viewpoint.
Aesthetics are very subjective (I can say the exact same thing about
the opposite case). As for a mathematical viewpoint, yes, it's not
exactly the same, but first of all, it's not generally a good idea to
strictly emulate mathematical semantics in programming languages. So
to speak, mathematical objects are immutable, and they exist in a
magical infinite space world without the notion of execution or
side-effects. Trying to model those semantics in a programming
language brings forth a host issues (most of them
performance-related). But more important, even if you wanted to do
that (to have it right from a mathematical viewpoint), mutable
by-value containers are just as bad, you should use immutable data
instead.
You might be right that modeling mathematics is not perfect, at least in
C/C++/D/java. Though the functional-programming is fine with it, and it
uses immutable data just as you suggested. But I'm aware that thats not
the way to go for D.
Anyway, though total math-like behavior is impossible, but with
Why is it not the way to go for D?
Why is total math-like behavior is impossible ?
Furthermore, if you have for example a vector of vectors,
vector!int row = [1,2,3];
auto vec = Vector!(Vector!int)(5, row);
then vec should be 5 rows, and not 5 times the same row.
Then instead of Vector use a static-length vector type, don't use a
container.
Maybe you want to change that stuff later on, so static-length is no
option. Following example might demonstrate the problem more clearly. It
is intended to init a couple of sets to empty.
set!int[42] a;
version(by_reference_wrong):
a[] = set!int.empty; // this does not work as intended
version(by_reference_correct):
foreach(ref x; a)
x = set!int.empty;
version(by_value):
//nothing to be done, already everything empty
Obviously the by_value version is the cleanest.
Not the best comparison, since the by_reference_correct version could be
improved to something like:
applyFill(a, set!int.empty) // if the last parameter is lazy
or
applyFill(a, { set!int.empty }) // otherwise, param is delegate instead
but in any case this is just a very specific example. What about the
other cases where by value could would be more verbose than by
reference? (particularly when you want to avoid needless copies)
Replacing set!int.empty with new set!int doesnt change the
situation,but make it sound only more weird in my ears: new vector?
what was wrong with the old one? and I dont want _an_ empty set, I
want _the_ empty set. Every empty set is equal, so there is only one.
The only way to truly solve this problem for you is to use by-value
containers, and actually use them with value semantics all the time (ie,
don't turn them into by-ref by passing pointers or other references to
them) !
...Well, this does contradict a bit what I originally said that how can
anyone think this is a good idea? But note that I was talking about
within the context of C++. If you use by-value containers in the
described above (with actually value semantics usage) you will be sooner
or later incurring heavy performance costs such that it's no longer a
good idea to be using C++ in the first place.
--
Bruno Medeiros - Software Engineer
Re: More on the necessity and difficulty of a package management system
On 2011-01-27 00:06, Adam D. Ruppe wrote: D's deployment is helped a lot by being compiled. We could just use native package systems (deb, rpm; whatever works for C works for D too) and/or static linking to ease the case of pushing something to a live server with zero* outside dependencies. That basically only works for Linux. On Mac OS X there is Macports but you would have to install that. On Windows there is no package management system available. Even if there was a package management system available on all three platforms you would still need to deploy to all these three. * Well, one: libc I guess. But that's pretty easy to manage. Of course, compiling is another story. I said my piece in a recent thread, so I won't argue that again :) -- /Jacob Carlborg
Re: Git Contributors Guide (Was: Re: destructor order)
On 2011-01-26 23:26, Ulrik Mikaelsson wrote: ** GUI-alternative **: I find gitk to be immensely useful to review things before submitting or publishing them. It allows all sorts of niceties, reviewing both changes and snapshotted trees from history, comparing revisions and following changes to a single file. For anyone using Mac OS X I recommend gitx (http://gitx.frim.nl/). -- /Jacob Carlborg
Re: Is D still alive?
You mean that if you give an index which is too large, it just uses $ instead? That sounds seriously bug-prone to me. I'd much rather that it blew up and thus told me that my program had a bug in it rather than silently trying to work. Sorry, but you are wrong on this. I understand this sounds unsafe, but no. Most languages, I guess, just do that without any worry. In particular, I have frequented python and Lua mailing lists for years without even reading once about this beeing a misfeature (and indeed have never run into a bug because of this myself). It is simply the right semantics in 99.999% cases. Isn't the real reason for this that bounds-checking is usually completely turned-off in release-builds? Sounds like something that could noticeably degrade runtime-performance for array-intensive code?
Re: Is D still alive?
Ulrik Mikaelsson: Isn't the real reason for this that bounds-checking is usually completely turned-off in release-builds? Bounds checking is turned off in release builds mostly because: 1) DMD is not able to infer remove most bound checks at compile-time as the latest Oracle VM are able to do; 2) and because Walter Co. believe such analysis isn't able to remove most bound checks anyway (I have not seen this hypothesis confirmed yet). Sounds like something that could noticeably degrade runtime-performance for array-intensive code? The safety net we are talking about is present only at the right bound of a slicing syntax (it's not performed in normal array indexing), and it consists in a single min(x, $) operation, that's one branch. So it slows down code, but only a bit. And in many of such situations you probably need to add a min(x, $) manually in the code anyway, so the overhead is limited. Bye, bearophile
Re: Is D still alive?
On Thursday, January 27, 2011 01:34:04 bearophile wrote:
spir:
Sorry, but you are wrong on this. I understand this sounds unsafe, but
no. Most languages, I guess, just do that without any worry. In
particular, I have frequented python and Lua mailing lists for years
without even reading once about this beeing a misfeature (and indeed
have never run into a bug because of this myself). It is simply the
right semantics in 99.999% cases.
Thank you for raising this topic again. I have raised it probably more than
one year ago, and all people around here were against this. This is not
unsafe, it's actually safer than the current D behaviour. Python designers
don't think this is a badly designed part of Python, they think this is as
desired, and I too have never seen people complain about this being a bad
or bug prone design.
An example of Python code:
s = abcdefg
upper = 20
s2 = s[2 : upper]
assert s2 == cdefg
Equivalent D2 code, if you forget to use the min() you are doomed:
import std.algorithm: min;
void main() {
string s = abcdefg;
int upper = 20;
string s2 = s[2 .. min($, upper)];
assert(s2 == cdefg);
}
The saturating nature of Python slice bounds is a safety net that's useful
to avoid some troubles. The only good thing of the D2 design is that it
performs less tests at runtime (it has no need to call min() in general),
this is a bit positive in a system language, but in this case it has a
cost in safety.
I don't think that you stand much chance of convincing a crowd using a system
programming language that having the compiler adjust your out of bound indices
to be in bounds is good idea. While it may be a great idea in some
circumstances, it generally smacks of lax programming. And since it makes
slicing more expensive, it would be a feature that would definitely need to
pull
its weight. And I don't see how it possibly could. It's trivial to add a
function which will return a slice which is laxly sliced in the manner that
you're looking for. And using min as you're showing isn't exactly hard.
Yes, you may get bugs when porting code from Python, but I don't think that
porting Python code has ever been one of the major concerns of D's language
design. Really, it's the silently breaking stuff when porting C and C++ code
which has been the concern.
What we have is efficient, and I expect that most people around here think that
it's the correct solution. If you want lax slicing, it's easy to get by using
min or a wrapper function. So, I see no reason to make any language changes -
not to mention it would likely conflict with TDPL to make such a change.
- Jonathan M Davis
Re: Is D still alive?
Honestly, I think this would just encourage writing sloppy code.
Using min(x, $) explicitly informs the reader of the code of exactly
what happens. It's harder to tell when it's implicit. Not only that,
but it can introduce bugs in your code - because while you might use
any upper bound, you're still not allowed to index beyond the length
of the array. Imagine this could was accepted by DMD:
void main()
{
auto userArgs = [foo]; // runtime arguments by some user input
auto firstTwo = userArgs[0..2]; // accepted by the new language change,
// implicitly
changes 2 to min(2, $)
// more code here
firstTwo[1] = test; // oops!
}
Re: dlist for phobos
On 1/27/11 3:25 AM, bearophile wrote: Andrei: I'm also undecided on what to do about sealing, and again language improvements (preventing escapes of references) could lead to improved designs. Language improvements need to be understood, desired, designed, and then implemented and debugged, so what kind of syntax and semantics are you thinking about? Bye, bearophile ref returns should be guaranteed to never escape. Andrei
Re: Is D still alive?
On Thursday, January 27, 2011 09:47:44 bearophile wrote: Ulrik Mikaelsson: Isn't the real reason for this that bounds-checking is usually completely turned-off in release-builds? Bounds checking is turned off in release builds mostly because: 1) DMD is not able to infer remove most bound checks at compile-time as the latest Oracle VM are able to do; 2) and because Walter Co. believe such analysis isn't able to remove most bound checks anyway (I have not seen this hypothesis confirmed yet). Sounds like something that could noticeably degrade runtime-performance for array-intensive code? The safety net we are talking about is present only at the right bound of a slicing syntax (it's not performed in normal array indexing), and it consists in a single min(x, $) operation, that's one branch. So it slows down code, but only a bit. And in many of such situations you probably need to add a min(x, $) manually in the code anyway, so the overhead is limited. Personally, I have _never_ needed to add a min call like that. So, while _you_ may think that it's a common thing to do (and it may be that it is in your code), that doesn't mean that that's generally true. - Jonathan M Davis
Re: const(Object)ref is here!
On 1/27/11 9:33 AM, Bruno Medeiros wrote: On 21/12/2010 19:17, Andrei Alexandrescu wrote: On 12/21/10 12:19 PM, Steven Schveighoffer wrote: On Tue, 21 Dec 2010 13:10:12 -0500, Bruno Medeiros brunodomedeiros+spam@com.gmail wrote: On 06/12/2010 19:00, Jonathan M Davis wrote: On Monday, December 06, 2010 05:41:42 Steven Schveighoffer wrote: On Mon, 06 Dec 2010 04:44:07 -0500, spirdenis.s...@gmail.com wrote: On Mon, 6 Dec 2010 00:31:41 -0800 Jonathan M Davisjmdavisp...@gmx.com wrote: toString() (or writeFrom() or whatever it's going to become) guess it was writeTo() ;-) but writeFrom is nice as well, we should find some useful use for it It was proposed as writeTo, but I'm not opposed to a different name. I have no problem with writeTo(). I just couldn't remember what it was and didn't want to take the time to look it up, and the name isn't as obvious as toString(), since it's not a standard name which exists in other languages, and it isn't actually returning anything. Whether it's to or from would depend on how you look at it - to the given delegate or from the object. But writeTo() is fine. Once it's used, it'll be remembered. I don't think it's entirely fine. It should at least have string/String somewhere in the name. (I mentioned this on the other original thread, although late in time) First, I'll say that it's not as important to me as it seems to be to you, and I think others feel the same way. writeTo seems perfectly fine to me, and the 'string' part is implied by the char[] parameter for the delegate. Changing the name to contain 'string' is fine as long as: 1) it's not toString. This is already established as returning a string in both prior D and other languages. I think this would be too confusing. 2) it's short. I don't want writeAsStringTo or something similar. What did you have in mind? -Steve Conversion to text should be called toText. That makes the essence of the function visible (it emits characters) without tying the representation of the text. Andrei I don't understand this point. The representation of the text is tied, it's going to be char[] ( aka UTF-8). Unless you were planning to have overloads of toText, but that sounds like an awful idea. Could be wchar or dchar. Andrei
Re: Is D still alive?
Andrej Mitrovic:
Honestly, I think this would just encourage writing sloppy code.
I don't believe this, on the other hand I believe the current behaviour is
bug-prone.
Using min(x, $) explicitly informs the reader of the code of exactly
what happens.
Right. The problem is that in some cases you may forget to add that min(x, $).
It's harder to tell when it's implicit.
Slicing syntax is used all the time in both Python and D code, so the Python
and D programmers learn quickly and keep in mind what it does. Implicit
behaviours are a problem when they are uncommon things, or library functions,
etc, much less when they are built-in safety nets you use every five lines of
code :-)
Not only that,
but it can introduce bugs in your code - because while you might use
any upper bound, you're still not allowed to index beyond the length
of the array.
Writing hundreds of thousands of lines of Python code I've seen that the
saturating semantics we are talking about is not bug-prone (in fact it avoids
some bugs).
Imagine this could was accepted by DMD:
void main()
{
auto userArgs = [foo]; // runtime arguments by some user input
auto firstTwo = userArgs[0..2]; // accepted by the new language change,
// implicitly
changes 2 to min(2, $)
// more code here
firstTwo[1] = test; // oops!
}
Programmers just quickly learn that indexes and slices have a bit different
semantics.
Bye,
bearophile
Re: Is D still alive?
This *code* was accepted, not *could*.
Re: Is D still alive?
Jonathan M Davis: I don't think that you stand much chance of convincing a crowd using a system programming language that having the compiler adjust your out of bound indices to be in bounds is good idea. Technically here we are talking about slicing bounds, and not indexes. But you are right, there's no hope I will change minds here. On the other hand my duty is to show the ideas I believe are right/better, because I care for this language. Bye, bearophile
Re: Is D still alive?
On 1/27/11, bearophile bearophileh...@lycos.com wrote: Programmers just quickly learn that indexes and slices have a bit different semantics. Right, programmers can easily adapt to slightly different semantics in related areas of the language, I mean C++ is known for being very easy to learn for exactly that reason. (Sarcasm alert!).
Re: Purity
On 17/12/2010 09:41, Don wrote: bearophile wrote: http://www.reddit.com/r/programming/comments/enajl/purity_in_d_language/ Bye, bearophile Nice. BTW you're incorrectly attributing some things to me. Although I recently championed the 'weakly pure' idea, I think Bruno made the original proposal. Well, kinda... I started the thread which described the original proposal in detail, and described how it was actually sound and potentially useful: http://www.digitalmars.com/d/archives/digitalmars/D/Idea_partially_pure_functions_70762.html But the idea itself didn't originate from me, it was derived from something you said, (or at least inspired by something you said): I want to conceptualize an idea that has been briefly mentioned in the previous pure discussions (by Don I think?), but has not been explicitly brought into attention. -- Bruno Medeiros - Software Engineer
Re: Is D still alive?
Am 27.01.2011 19:25, schrieb bearophile: Programmers just quickly learn that indexes and slices have a bit different semantics. And I guess this holds true for programmers used to python as well? So they should have no problem with learning to use foo = blah[i..min($,i+n)] instead of foo = blah[i..(i+n)] ;-) Bye, bearophile Cheers, - Daniel
Re: Purity
On 17/12/2010 07:42, bearophile wrote: http://www.reddit.com/r/programming/comments/enajl/purity_in_d_language/ Bye, bearophile pure functions are contravariant (a subset) with impure functions Nope, there is a mistake here, it is the other way around: pure functions are covariant with impure functions. This is even mentioned in the beginning of the article: a pure function: [...] - Is covariant with an impure function; -- Bruno Medeiros - Software Engineer
Re: Hot for dmd 64bit
On 1/27/2011 1:32 AM, dwilson wrote: Beside praying and pestering, what can we D non-experts do to help get a stable 64-bit dmd available? Killer D features are strings, slick built in dynamics arrays, no headers files to keep in sync, and the other nice features often praised by others. I'm not sure yet that D is my favorite language, but it's in the list of top three. Killing D (at least for me) is the limit choices for compiling on 64-bit Linux with D2 and preferably Phobos instead of Tango. My setup, for reasons I haven't investigated deeply, can't run 32-bit anything, and I do intend to work on huge arrays of data, a few GB in RAM. As for Phobos, it's obviously more Mars-related than Tango :) When 64-bit dmd arrives for Windows, what will be used for a linker? Will optlink be ported also?
Re: Purity
On 17/12/2010 14:39, Don wrote:
1
Another inaccuracy (really an omission) is that a weakly pure function
is just like a pure function but cannot be memoized. In fact, it
cannot be optimized in any way like strongly pure functions can.
2
This actually ties together nicely with my first point -- a pure
function that returns a mutable pointer must be weakly pure.
A function which has immutably pure parameters can undergo *some*
optimisation, even if the return value is a mutable pointer.
For example, if the parameters are identical for both calls, you can do
a deepdup of the first return value instead of calling the function again.
Are you sure? If I understood you correctly, that doesn't seem to be the
case. Consider for example:
string[] func(string arg) pure {
string elem2 = blah.idup;
return [ arg, elem2 ];
}
The compiler *cannot* know (well, looking at the signature only of
course) how to properly deepdup the result from the first return value,
so as to give the exact same result as if func was called again.
Apologies if this has been discussed in some thread further ahead.
--
Bruno Medeiros - Software Engineer
Re: Hot for dmd 64bit
Am 27.01.2011 19:56, schrieb Eric Poggel: On 1/27/2011 1:32 AM, dwilson wrote: Beside praying and pestering, what can we D non-experts do to help get a stable 64-bit dmd available? Killer D features are strings, slick built in dynamics arrays, no headers files to keep in sync, and the other nice features often praised by others. I'm not sure yet that D is my favorite language, but it's in the list of top three. Killing D (at least for me) is the limit choices for compiling on 64-bit Linux with D2 and preferably Phobos instead of Tango. My setup, for reasons I haven't investigated deeply, can't run 32-bit anything, and I do intend to work on huge arrays of data, a few GB in RAM. As for Phobos, it's obviously more Mars-related than Tango :) When 64-bit dmd arrives for Windows, what will be used for a linker? Will optlink be ported also? If it will depend on optlink it will probably take ages until a win64 version is ready, because optlink is (mostly) written in assembler.. I guess it would be smart to output object files compatible to the windows port of the gnu linker (from MingW), so this can be used and you can link in object files from GCC/MinGW (otherwise DMC would need a 64bit port as well - don't know if that is planned).
Re: Hot for dmd 64bit
I guess it would be smart to output object files compatible to the windows port of the gnu linker (from MingW), so this can be used and you can link in object files from GCC/MinGW (otherwise DMC would need a 64bit port as well - don't know if that is planned). I think dmc uses the very same backend dmd does. But a change to COFF would indeed be great.
Re: Purity
On 18/12/2010 08:52, spir wrote:
On Fri, 17 Dec 2010 02:42:14 -0500
bearophilebearophileh...@lycos.com wrote:
http://www.reddit.com/r/programming/comments/enajl/purity_in_d_language/
Bye,
bearophile
I take the opportunity to question the def of weakly pure.
-1- How can this even compile?
pure append (ref int[] a, int i) {a ~= i;}
The _only_ task of this func is to change state.
It is best not to think of D's pure as saying the function is pure in
the traditional sense (side-effect free), but rather to say the
side-effects are confined to the function's parameters only (and the
state/data that is transitively reachable from them).
The key benefit of this is that it allows the *caller* of such pure
function to determine which subset of state/data *may* change by a call
to such function.
--
Bruno Medeiros - Software Engineer
Re: Hot for dmd 64bit
When 64-bit dmd arrives for Windows, what will be used for a linker? Will optlink be ported also? We recently had a thread if a linker called UniLink could be a solution.
Re: D vs C++
On 26/12/2010 05:45, bearophile wrote: Walter Bright: I thought the idea that break and continue were bad died about 25 years ago. Pascal didn't allow them, and pretty much everyone hated the workaround of having to use flag variables. You need to add some shades of grey to your palette. break, continue and goto are bad, and it's better to limit their usage. Ehh?! Awww man, not this crap again... (http://www.digitalmars.com/d/archives/digitalmars/D/The_singleton_design_pattern_in_D_C_and_Java_113474.html#N115036) -- Bruno Medeiros - Software Engineer
Re: DMD for FreeBSD
Gour wrote: Hello! I'm slowly heading towards Free(PC)BSD (from Linux) and wonder what is the status of dmd2 there? http://www.digitalmars.com/d/1.0/dmd-freebsd.html page speaks only about 32bit dmd1 for fbsd-7.1, while the ports page at FreeBSD site lists 'dmd2-2.051' with the D 2.0 compiler, not officially validated for FreeBSD note. What does it mean? It means that a couple people are using D2 on FreeBSD, by compiling the sources themselves, but I haven't got to making an official release on it yet.
Re: Hot for dmd 64bit
retard wrote: Didn't Walter say about one year ago that it only takes 1-2 months to finish the 64-bit port. Yeah, well, I work on a lot of other stuff at the same time. The most recent distraction was the move to github.
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
On 26.01.2011 21:52, Walter Bright wrote: Trass3r wrote: Walter Bright Wrote: Dmitry Olshansky wrote: Well, anyway I can mail him and hope that he will do it just out of curiosity, what's yours relevant email then? May I just as well tell him that you are interested in it or anything? My offer is if there is something specific about the OMF files generated that I can explain to him, I'd be happy to do so. My mail is walter followed by digitalmars.com. Any news here? No, I have not heard anything. I've got their detailed report on the sample object file, and relayed it to Walter. Something related to D's stance on TLS it seems. With me being middle man all this can take some extra time, but I don't mind. The end result may still well worth it. -- Dmitry Olshansky
Re: Is D still alive?
retard wrote: I also got brainwashed by the C++ advocates years ago. However, I didn't need D to see how terrible writing C++ is. C++ sure is a powerful language and sometimes a necessary evil, but you don't really need very strong doses of more recent languages to see how much nicer everything else is. What D unique shows is, however, that one can do C++ like things without the C++ issues, in other words, the problems C++ has are not necessary in order to get the powerful things C++ can do.
Re: Is D still alive?
retard wrote: The main reasons were RAII and Design by Contract. Even funnier, it took D about 9 years to fix the main bug in DbC (contract inheritance). The reason that took so long was that few people were using DbC effectively, so it was a low priority. I originally had high hopes that DbC would produce dramatic improvements in code quality, but the real world results were disappointing.
Re: Is D still alive?
On 1/27/11 1:26 PM, Walter Bright wrote: retard wrote: I also got brainwashed by the C++ advocates years ago. However, I didn't need D to see how terrible writing C++ is. C++ sure is a powerful language and sometimes a necessary evil, but you don't really need very strong doses of more recent languages to see how much nicer everything else is. What D unique shows is, however, that one can do C++ like things without the C++ issues, in other words, the problems C++ has are not necessary in order to get the powerful things C++ can do. Well put. BTW I'm glad to see retard back in action. A small debate of bearophile about bounds checking and whatnot, Bruno doing his monthly bulk answering to posts, retard being down on D... it all starts looking like a good day on digitalmars.D :o). Andrei
Re: DMD for FreeBSD
On Thu, 27 Jan 2011 11:21:59 -0800 Walter Bright newshou...@digitalmars.com wrote: It means that a couple people are using D2 on FreeBSD, by compiling the sources themselves, but I haven't got to making an official release on it yet. Ohhh, that's great...it means the OS is not forgotten. :-) Thank you! Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: DMD for FreeBSD
Gour wrote: On Thu, 27 Jan 2011 11:21:59 -0800 Walter Bright newshou...@digitalmars.com wrote: It means that a couple people are using D2 on FreeBSD, by compiling the sources themselves, but I haven't got to making an official release on it yet. Ohhh, that's great...it means the OS is not forgotten. :-) No. Actually, I like FreeBSD a lot.
Re: Purity
Bruno Medeiros brunodomedeiros+spam@com.gmail wrote:
string[] func(string arg) pure {
string elem2 = blah.idup;
return [ arg, elem2 ];
}
The compiler *cannot* know (well, looking at the signature only of
course) how to properly deepdup the result from the first return value,
so as to give the exact same result as if func was called again.
Could you please elucidate, as I am unsure of your reasoning for saying
the compiler cannot know how to deepdup the result.
--
Simen
Re: Is D still alive?
Walter:
The reason that took so long was that few people were using DbC effectively,
so it was a low priority. I originally had high hopes that DbC would produce
dramatic improvements in code quality, but the real world results were
disappointing.
After many years and many failed hopes, I think there is no silver bullet in
programming, so maybe nothing is able to produce dramatic improvements in code
quality.
But even if this is true, some things are able to improve coding a bit, like
unit testing, a well semantically defined language, syntax coloring, quick
compile-run cycles, OOP for certain kinds of programs, DbC, and so on. Each of
such things improve the situation only a little, but such improvements pile up
and most programmers when have tried them don't want to go back to miss those
things.
I have learnt to know and use DbC on D, and while it has not caused dramatic
improvements in my code, I like to use it now and then, it has found some of
the bugs in my code and more. I am appreciating D DbC enough that sometimes I
miss it when I write Python code, so sometimes when I write OOP Python code, I
add home-made class invariants and I call them manually from methods. In one
situation this has allowed me to finish some hairy Python code in a very tight
time schedule.
Regading D implementation of DbC I'd like:
- DMD to use a not-release build of Phobos when I compile my D code in
not-release build (or some similar solution). So Phobos will be free to use
asserts instead of enforce in many more situations (even if not in all
situations). This will allow more inlining, allow to use nothrow tags more
frequently, and avoid some performance problems currently present (confirmed by
timings and profiling) in Phobos caused by enforces;
- To see some acceptable solution for the old (pre-state) problem. On this
there are some ideas, but I don't think there is some accepted proposal yet.
This is not an indispensable feature of DbC, but it allows to increase its
power and applicability significantly enough (and designers of C#4 DbC has
found ways to solve this problem, so I presume there is some way to solve it in
D too);
- To see some Bugzilla DbC bugs removed. One or more of them is related to how
const/immutable badly interacts with the result return value used by
out(result){}.
Bye and thank you,
bearophile
Re: Unilink - alternative linker for win32/64, DMD OMF extensions?
I've got their detailed report on the sample object file, and relayed it to Walter. Something related to D's stance on TLS it seems. With me being middle man all this can take some extra time, but I don't mind. The end result may still well worth it. Hope so too.
Re: dlist for phobos
Andrei Alexandrescu napisał: ref returns should be guaranteed to never escape. Should meaning they're not guaranteed now? I'm curious in what scenarios they escape. -- Tomek
Re: dlist for phobos
On 1/27/11 4:48 PM, Tomek Sowiński wrote: Andrei Alexandrescu napisał: ref returns should be guaranteed to never escape. Should meaning they're not guaranteed now? I'm curious in what scenarios they escape. Any function can take the address of a reference (either a ref parameter or the result of another function) and squirrel it away. Andrei
Re: dlist for phobos
Andrei Alexandrescu napisał: On 1/27/11 4:48 PM, Tomek Sowiński wrote: Andrei Alexandrescu napisał: ref returns should be guaranteed to never escape. Should meaning they're not guaranteed now? I'm curious in what scenarios they escape. Any function can take the address of a reference (either a ref parameter or the result of another function) and squirrel it away. Jeez.. I must've had some brain-warp that I didn't think of r.front :-) But is just banning taking addresses of ref parameters and return values going to solve the problem? Sounds delusively simple... -- Tomek
Re: dlist for phobos
On 2011-01-27 17:52:27 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
On 1/27/11 4:48 PM, Tomek Sowiński wrote:
Andrei Alexandrescu napisał:
ref returns should be guaranteed to never escape.
Should meaning they're not guaranteed now? I'm curious in what
scenarios they escape.
Any function can take the address of a reference (either a ref
parameter or the result of another function) and squirrel it away.
Even in @safe mode? Being able to take the address of a ref in non-safe
code seems normal to me.
That said, you don't need to take the address of anything to escape a ref:
ref int test() {
int i;
return pass(i);
}
ref int pass(ref int i) {
return i;
}
Now, consider that instead of 'int i' you have a container with
deterministic destruction:
ref int test() {
Container!int a;
return a[0];
}
Same problem.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: immutable
Trass3r napisał: But thank you for the answer, I have filed the bug. Rats, I've filed one too ;) http://d.puremagic.com/issues/show_bug.cgi?id=5492 We found it over a year ago :) http://d.puremagic.com/issues/show_bug.cgi?id=3534 -- Tomek
Re: Is D still alive?
bearophile wrote: Walter: The reason that took so long was that few people were using DbC effectively, so it was a low priority. I originally had high hopes that DbC would produce dramatic improvements in code quality, but the real world results were disappointing. After many years and many failed hopes, I think there is no silver bullet in programming, so maybe nothing is able to produce dramatic improvements in code quality. But even if this is true, some things are able to improve coding a bit, like unit testing, a well semantically defined language, syntax coloring, quick compile-run cycles, OOP for certain kinds of programs, DbC, and so on. Each of such things improve the situation only a little, but such improvements pile up and most programmers when have tried them don't want to go back to miss those things. Unit testing has produced a dramatic improvement in coding.
Re: Is D still alive?
Walter Bright napisał: bearophile wrote: Walter: The reason that took so long was that few people were using DbC effectively, so it was a low priority. I originally had high hopes that DbC would produce dramatic improvements in code quality, but the real world results were disappointing. After many years and many failed hopes, I think there is no silver bullet in programming, so maybe nothing is able to produce dramatic improvements in code quality. But even if this is true, some things are able to improve coding a bit, like unit testing, a well semantically defined language, syntax coloring, quick compile-run cycles, OOP for certain kinds of programs, DbC, and so on. Each of such things improve the situation only a little, but such improvements pile up and most programmers when have tried them don't want to go back to miss those things. Unit testing has produced a dramatic improvement in coding. Yes, it's big. Funny that it's not really a technical change but a cultural one -- D just leaves no excuses to even the most stone-age programmers not to test their code. -- Tomek
Re: Is D still alive?
Tomek Sowiński wrote: Walter Bright napisał: bearophile wrote: Walter: The reason that took so long was that few people were using DbC effectively, so it was a low priority. I originally had high hopes that DbC would produce dramatic improvements in code quality, but the real world results were disappointing. After many years and many failed hopes, I think there is no silver bullet in programming, so maybe nothing is able to produce dramatic improvements in code quality. But even if this is true, some things are able to improve coding a bit, like unit testing, a well semantically defined language, syntax coloring, quick compile-run cycles, OOP for certain kinds of programs, DbC, and so on. Each of such things improve the situation only a little, but such improvements pile up and most programmers when have tried them don't want to go back to miss those things. Unit testing has produced a dramatic improvement in coding. Yes, it's big. Funny that it's not really a technical change but a cultural one -- D just leaves no excuses to even the most stone-age programmers not to test their code. I was talking about this with Andrei the other day. D's focus on making it easy to do things the right way has paid off handsomely, though this is not at all obvious from reading a feature list. It only becomes clear when you use it for a while, and then try to go back to the way you were doing things before. I think one of the reasons DbC has not paid off is it still requires a significant investment of effort by the programmer. It's too easy to not bother.
Re: Is D still alive?
On 1/28/11, Walter Bright newshou...@digitalmars.com wrote: I think one of the reasons DbC has not paid off is it still requires a significant investment of effort by the programmer. It's too easy to not bother. Another way to look at it is that programmers are enjoying the safety of using regular D so much as to not even think about using DbC. The language does guarantee a lot more than C++. The irony here is that C++ is the one that desperately needs integrated DbC, and yet D, the safer language, is the one providing DbC for free. :p In other words, we get the candy and the cake.
Re: Is D still alive?
On 1/27/11 8:02 PM, Walter Bright wrote: Tomek Sowiński wrote: Walter Bright napisał: bearophile wrote: Walter: The reason that took so long was that few people were using DbC effectively, so it was a low priority. I originally had high hopes that DbC would produce dramatic improvements in code quality, but the real world results were disappointing. After many years and many failed hopes, I think there is no silver bullet in programming, so maybe nothing is able to produce dramatic improvements in code quality. But even if this is true, some things are able to improve coding a bit, like unit testing, a well semantically defined language, syntax coloring, quick compile-run cycles, OOP for certain kinds of programs, DbC, and so on. Each of such things improve the situation only a little, but such improvements pile up and most programmers when have tried them don't want to go back to miss those things. Unit testing has produced a dramatic improvement in coding. Yes, it's big. Funny that it's not really a technical change but a cultural one -- D just leaves no excuses to even the most stone-age programmers not to test their code. I was talking about this with Andrei the other day. D's focus on making it easy to do things the right way has paid off handsomely, though this is not at all obvious from reading a feature list. It only becomes clear when you use it for a while, and then try to go back to the way you were doing things before. Although this might as well be true, I generally try to avoid such arguments. The problem with it is it's non-falsifiable (http://en.wikipedia.org/wiki/Falsifiability) so it has a certain stench coming with it. I've seen such a claim in Go fora: you know, once you get to really use Go, you won't feel the need for generics. Meh. I try to _never_ use such an argument. If I'm to convince anyone that D rocks, it won't be by means of unfalsifiable statements. It will be by showing code that knocks your socks off. The kind of code that makes you think: If I'm to write that in language X, I need to give away desirable traits A, B, and C. Damn! I think one of the reasons DbC has not paid off is it still requires a significant investment of effort by the programmer. It's too easy to not bother. One issue with DbC is that its only significant advantage is its interplay with inheritance. Otherwise, scope() in conjunction with assert works with less syntactic overhead. So DbC tends to shine with large and deep hierarchies... but large and deep hierarchies are not that a la mode anymore. Andrei
Re: Is D still alive?
On 01/27/2011 05:41 PM, Walter Bright wrote: Unit testing has produced a dramatic improvement in coding. agreed. unit testing (maybe with dbc, I don't remember) was the only reason I noticed issue 5364.
Re: Is D still alive?
Andrej Mitrovic: Another way to look at it is that programmers are enjoying the safety of using regular D so much as to not even think about using DbC. This may be a case of Risk homeostasis: http://en.wikipedia.org/wiki/Risk_homeostasis But maybe it's mostly a matter of getting used to D. Once you get used to a safer language, you want even more and something better. You want the frosting too on your cake :-) And probably D is not the end of the line in the evolution of C-derived languages. There is space for improvements, like having notnull reference types, typestates, etc. For example, it will be interesting to see where the Rust language goes. Bye, bearophile
Re: Is D still alive?
Andrei Alexandrescu wrote: On 1/27/11 8:02 PM, Walter Bright wrote: I was talking about this with Andrei the other day. D's focus on making it easy to do things the right way has paid off handsomely, though this is not at all obvious from reading a feature list. It only becomes clear when you use it for a while, and then try to go back to the way you were doing things before. Although this might as well be true, I generally try to avoid such arguments. The problem with it is it's non-falsifiable (http://en.wikipedia.org/wiki/Falsifiability) so it has a certain stench coming with it. I've seen such a claim in Go fora: you know, once you get to really use Go, you won't feel the need for generics. Meh. I try to _never_ use such an argument. If I'm to convince anyone that D rocks, it won't be by means of unfalsifiable statements. I agree it's a worthless argument to use to try and convince people to give D a try. But for experienced D users, it is an interesting point. It will be by showing code that knocks your socks off. The kind of code that makes you think: If I'm to write that in language X, I need to give away desirable traits A, B, and C. Damn! I think one of the reasons DbC has not paid off is it still requires a significant investment of effort by the programmer. It's too easy to not bother. One issue with DbC is that its only significant advantage is its interplay with inheritance. Otherwise, scope() in conjunction with assert works with less syntactic overhead. So DbC tends to shine with large and deep hierarchies... but large and deep hierarchies are not that a la mode anymore. Yes, you might be right.
Re: Is D still alive?
On Thursday 27 January 2011 19:29:59 Walter Bright wrote: Andrei Alexandrescu wrote: One issue with DbC is that its only significant advantage is its interplay with inheritance. Otherwise, scope() in conjunction with assert works with less syntactic overhead. So DbC tends to shine with large and deep hierarchies... but large and deep hierarchies are not that a la mode anymore. Yes, you might be right. I generally end up using unit tests to verify that stuff works correctly and then throw exceptions on bad input. So while I like having DbC built in, I don't end up using it all that much. It's prim,arily invariant that I end up using though, and that's harder to do inside of the member functions. - Jonathan M Davis
Re: Is D still alive?
Andrei: One issue with DbC is that its only significant advantage is its interplay with inheritance. Otherwise, scope() in conjunction with assert works with less syntactic overhead. So DbC tends to shine with large and deep hierarchies... but large and deep hierarchies are not that a la mode anymore. Have you tried to use class invariants manually? It's easy to forget its calls, and the calls clutter the code, and are not handy to write. So I don't agree. Bye, bearophile
Re: Hot for dmd 64bit
Will try it. I had tried gdc in December, but had some sort of trouble with it, and moved on to trying ldc rather than fuss with it much. Perhaps it's worth a little more fuss to get running.
Re: Is D still alive?
the problems C++ has are not necessary in order to get the powerful things C++ can do. That thought makes me happy!
Re: array of elements of various sybtypes
spir: Maybe, but (in this case) array literals are OK. The are not OK. They need to use the lowest common supertype, and in this case they aren't doing it. If this is too much hard or unsafe or ambiguous to do, then D array literals need some syntax to allow the programmer to specify the missing semantics in a nice way. Bye, bearophile
Re: github syntax hilighting
On 2011-01-26 23:10, Andrej Mitrovic wrote: On 1/26/11, Jacob Carlborgd...@me.com wrote: It takes about 10 seconds to get syntax highlighting at the bottom of the file in TextMate. Takes half a second in Scite, and in Vim I'm not noticing any delays. Incidentally I think I've seen the longest line count per file in Vim's codebase (close to 100k if my memory serves me right). I would guess it takes 10 seconds because it processes the file as a whole. I would guess vim doesn't do that, but I don't know. -- /Jacob Carlborg
Re: array of elements of various sybtypes
On 01/27/2011 03:54 AM, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 18:33:45 -0500, spir denis.s...@gmail.com wrote: On 01/26/2011 07:23 PM, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 12:27:37 -0500, spir denis.s...@gmail.com wrote: auto ts = cast(T0[])[t1, t2]; Nope, refused for the same reason (tried to construct [t1,t2] before casting it). Hm.. maybe that only works on array literals with all literal elements. I expected the cast to affect the type the compiler is expecting. For example, this works: cast(ubyte[])[1,2]; // without cast typed as int[] Yes, but with [1,2] the compiler has no difficulty to create the initial array in the first place ;-) With [t1,t2], it fails in that very first task, before even having a chance to redefine the whole array's type. I believe there should be a way to tell the array literal this is the type you should be. Yes, exactly; I superficially thought specifying it explicitely on the left of '=' would do the job, just like you cast(T[]). But Jonathan is right in saying in any case the array literal must be interpratable first. If that's not possible, then it needs to be added. If it's expected the cast should work, then I'd file a bug against it. Yop, but I don't even see the shadow of a solution ;-) Denis -- _ vita es estrany spir.wikidot.com
Re: array of elements of various sybtypes
On 01/27/2011 03:59 AM, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 18:28:12 -0500, Jonathan M Davis jmdavisp...@gmx.com wrote: I believe that it's supposed to take the common type of t1 and t2 and make the result an array of that type. So, assuming that the common type is T0, then it should work. However, it's not currently implemented that way. You could always create a bug report so that it doesn't get lost (assuming that no such report already exists). Object could also be the common type. Very true. When there exists multiple possibilities, and none of the possibilities are types being passed to the array literal, I think it just gives up (D usually gives up in the face of ambiguity, instead of possibly making the wrong decision). That's OK. But the problem here appears that there is no way to *force* it to make the right decision. Yes, that's what I meant in another post. We should have a way to hint the compiler about intended common type /before/ it even tries to contruct an initial array value (which else fails). But I have no idea how; should be a syntactic trick. There is no literal-typing pattern in D, instead the compiler always performs type induction from the form. I'd like to see cast(T0[])[...] work, I think that should solve the problem. See /before/ above (cast applies on already constructed value). The only alternative is, I guess, when the compiler initially fails to find a common type, to have it look for a hint by interpreting the target; then explicit array var typing would work: T0[] ts = [t1, t2]; But it seems to me rather complicated. (There are many different situations in which literals may appear). -Steve -- _ vita es estrany spir.wikidot.com
Re: array of elements of various sybtypes
On 01/27/2011 05:05 AM, Steven Schveighoffer wrote: On Wed, 26 Jan 2011 22:10:58 -0500, Jonathan M Davis jmdavisp...@gmx.com wrote: On Wednesday 26 January 2011 18:59:50 Steven Schveighoffer wrote: On Wed, 26 Jan 2011 18:28:12 -0500, Jonathan M Davis jmdavisp...@gmx.com I'd like to see cast(T0[])[...] work, I think that should solve the problem. It probably doesn't for the exact same reason that the assignment didn't do it. The expression is evaluated and _then_ it's cast. So, if the expression isn't valid in and of itself, it fails. This works: cast(ubyte[])[1,2,3] // creates an array of 3 ubytes So clearly cast has an effect on the type of the array literal in that case. I'm not sure why this works and the other doesn't, [1,2,3] is valid! [t1,t2] is not if one of the elements' type is not implicitely convertible to the other. In your example cast applies to an already constructed array. (Hope you see what I mean) but we definitely need something that allows one to control the array type of a literal. Yop! But this hint has to belong to the literal notation syntax itself. Not anything (like cast ot to!) that applies afterwards. In D1, the array could be typed by casting the first element (the first element was always used as the type of the array). In D2 we no longer can control the type of the array that way, we need some way to do it. Works in D2. If any element is of the inteded common type, then all goes fine. But I'm not satisfied with that trick. We cast an element instead of typing the array literal. It's just a side-effect. (But I'll go with it as of now.) It probably can be done in the case of classes by casting an element to the desired type, but it seems rather hoaky to require two different methods of typing an array literal depending on what kinds of data are in the array. Plus, casting one element does not mean another element doesn't override it. It's better IMO to say I want this array to be T0[] and let the compiler fail if it can't cast all the elements rather then have the compiler do oh, one of these is Object, so I'm actually going to re-type this as Object[]. Agreed. Denis -- _ vita es estrany spir.wikidot.com
Re: array of elements of various sybtypes
On 01/27/2011 05:40 AM, Andrej Mitrovic wrote:
On 1/27/11, Steven Schveighofferschvei...@yahoo.com wrote:
I'm not sure why this works and the other doesn't, but we
definitely need something that allows one to control the array type of a
literal.
pragma helps in discovering what DMD does sometime. This will error
out but it will give some useful info:
pragma(msg, typeid( [1,2,cast(ubyte)3] ));
error: [1,2,cast(int)cast(ubyte)3] ,D11TypeInfo_Ai6__initZ
So it forces a cast back to int again.
But we can use a postfix to set an unsigned type for the whole array:
writeln(typeid( [1,2,3u] )); // uint[]
And we can select a string type with a postfix, but we can't use a cast:
void main()
{
writeln(typeid( [ad, b, c] ));// works
writeln(typeid( [cast(dchar)a, b, c] )); // doesn't work,
// Error: incompatible types for ((cast(dchar)a) ? (b)): 'dchar'
and 'string'
}
The latter fails because because you did an error. Indeed D cannot cast a
/string/ of immutable chars to a char type.
writeln(typeid( [cast(immutable(dchar)[])a, b, c] ));
// immutable(dchar)[][]
But your remark is valid: 'd' is a typing hint that belonds to the literal
notation itself; not something that applies afterward on an already created
thing. We need something similar to /initially/ type arrays literals. By
analogy, the only thing I can imagine is postfixing the (element type) to the
literal:
auto ts = [t1, t2]T0;
But it's not really beautiful ;-)
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Interface problems
26.01.2011 16:54, Steven Schveighoffer пишет:
This is hardly a solution. He wants to do value comparison, not
identity comparison.
The real fix is to make interface assume it is an Object, so it can be
implicitly cast to Object, and find another way to implement COM
interfaces. The COM interface hack is way outdated and extremely
harmful, esp. on OS' who *don't use COM*! I can't see how the
benefits it has outweigh the problems it causes.
The recent discussion in D group about destructor order brought me to
yet another question about interfaces.
Currently, functions that should accept classes as parameters, e.g.
clear(), accept interfaces as well:
void clear(T)(T obj) if (is(T == class)) // note the constraint
{ /*...*/ }
interface I {}
class A : I {}
void main()
{
I a = new A; // note that typeof(a) is I, not A
clear(a);
}
This compiles. But raises a question: how come? If it is assumed that a
reference to interface is not necessarily a D class instance, then it
shouldn't. The fact that it compiles even more ambiguates the purpose
and usage of interfaces.
I agree with Steven. Having a support for COM, CORBA and so on in the
language is great, but wouldn't it be better to specify it explicitly?
Maybe solidify the usage of 'extern' keyword?
interface D {} // instances are guaranteed to be D Objects
extern interface E {} // instances may or may not be D Objects (COM and
alike)
I mean, it's already there in the language and is described in
'Interfacing to C++' in the documentation. Though currently, extern
interfaces are accepted by is(T == class) constraint as well.
Re: github syntax hilighting
On 1/27/11, Jacob Carlborg d...@me.com wrote: I would guess it takes 10 seconds because it processes the file as a whole. I would guess vim doesn't do that, but I don't know. I haven't thought of that! Actually Vim's syntax highlighting 'algorithm' is customizable. You can set it up to try highlighting the entire file, or it can do some magic and scan backwards N lines to figure out how to highlight the entire screen. Afaik the D syntax highlighting script doesn't scan the entire file at once, which probably explains the speed. :)
Re: github syntax hilighting
Jacob Carlborg Wrote: On 2011-01-26 23:10, Andrej Mitrovic wrote: On 1/26/11, Jacob Carlborgd...@me.com wrote: It takes about 10 seconds to get syntax highlighting at the bottom of the file in TextMate. Takes half a second in Scite, and in Vim I'm not noticing any delays. Incidentally I think I've seen the longest line count per file in Vim's codebase (close to 100k if my memory serves me right). I would guess it takes 10 seconds because it processes the file as a whole. I would guess vim doesn't do that, but I don't know. -- /Jacob Carlborg Yep, Vim's highlighting is set up to sync on comments, though there is more it could do, this does a pretty good job.
Re: array of elements of various sybtypes
On 1/27/11, spir denis.s...@gmail.com wrote: The latter fails because because you did an error. Indeed D cannot cast a /string/ of immutable chars to a char type. writeln(typeid( [cast(immutable(dchar)[])a, b, c] )); // immutable(dchar)[][] My bad! :) This is what I should have typed: writeln(typeid( [cast(dstring)a, b, c] )); By analogy, the only thing I can imagine is postfixing the (element type) to the literal: auto ts = [t1, t2]T0; But it's not really beautiful ;-) Well, I wasn't implying that we need a special postfix syntax for custom types (honestly, at this stage any feature request gets shot down and buried 6 feet under by the D town sheriff and his deputy). Maybe all that needs changing is the compiler so it can at least try to find a common type.
Re: Interface problems
26.01.2011 16:54, Steven Schveighoffer пишет:
This is hardly a solution. He wants to do value comparison, not
identity comparison.
The real fix is to make interface assume it is an Object, so it can be
implicitly cast to Object, and find another way to implement COM
interfaces. The COM interface hack is way outdated and extremely
harmful, esp. on OS' who *don't use COM*! I can't see how the
benefits it has outweigh the problems it causes.
The recent discussion in D group about destructor order brought me to
yet another question about interfaces.
Currently, functions that should accept classes as parameters, e.g.
clear(), accept interfaces as well:
void clear(T)(T obj) if (is(T == class)) // note the constraint
{ /*...*/ }
interface I {}
class A : I {}
void main()
{
I a = new A; // note that typeof(a) is I, not A
clear(a);
}
This compiles. But raises a question: how come? If it is assumed that a
reference to interface is not necessarily a D class instance, then it
shouldn't. The fact that it compiles even more ambiguates the purpose
and usage of interfaces.
I agree with Steven. Having a support for COM, CORBA and so on in the
language is great, but wouldn't it be better to specify it explicitly?
Maybe solidify the usage of 'extern' keyword?
interface D {} // instances are guaranteed to be D Objects
extern interface E {} // instances may or may not be D Objects (COM and
alike)
I mean, it's already there in the language and is described in
'Interfacing to C++' in the documentation. Though currently, extern
interfaces are accepted by is(T == class) constraint as well.
Second this thought. Interface IMHO are far too basic for a functionality tweak.
Would also like to understand the way to raise such requests and take them to
their logical conclusion.
Regards
Mandeep
Re: Interface problems
On 01/27/2011 09:27 PM, Mandeep Singh Brar wrote:
26.01.2011 16:54, Steven Schveighoffer пишет:
This is hardly a solution. He wants to do value comparison, not
identity comparison.
The real fix is to make interface assume it is an Object, so it can be
implicitly cast to Object, and find another way to implement COM
interfaces. The COM interface hack is way outdated and extremely
harmful, esp. on OS' who *don't use COM*! I can't see how the
benefits it has outweigh the problems it causes.
The recent discussion in D group about destructor order brought me to
yet another question about interfaces.
Currently, functions that should accept classes as parameters, e.g.
clear(), accept interfaces as well:
void clear(T)(T obj) if (is(T == class)) // note the constraint
{ /*...*/ }
interface I {}
class A : I {}
void main()
{
I a = new A; // note that typeof(a) is I, not A
clear(a);
}
This compiles. But raises a question: how come? If it is assumed that a
reference to interface is not necessarily a D class instance, then it
shouldn't. The fact that it compiles even more ambiguates the purpose
and usage of interfaces.
I agree with Steven. Having a support for COM, CORBA and so on in the
language is great, but wouldn't it be better to specify it explicitly?
Maybe solidify the usage of 'extern' keyword?
interface D {} // instances are guaranteed to be D Objects
extern interface E {} // instances may or may not be D Objects (COM and
alike)
I mean, it's already there in the language and is described in
'Interfacing to C++' in the documentation. Though currently, extern
interfaces are accepted by is(T == class) constraint as well.
Second this thought. Interface IMHO are far too basic for a functionality tweak.
Would also like to understand the way to raise such requests and take them to
their logical conclusion.
Regards
Mandeep
There is bugzilla: d.puremagic.com/issues. You can create enhancement
requests there along with bugreports.
Nested function declarations
This D2 code:
import std.math: sqrt;
void main() {
double sqrt();
double result = sqrt(9.0);
}
Generates the errors:
test.d(4): Error: function test.main.sqrt () is not callable using argument
types (double)
test.d(4): Error: expected 0 arguments, not 1 for non-variadic function type
double()
What is the purpose of nested function declarations in D? Is it a good idea to
just disallow them?
Bye and thank you,
bearophile
Re: Nested function declarations
What is the purpose of nested function declarations in D? Is it a good idea
to just disallow them?
In theory they may be used to define mutually recursive nested functions, like
in this example, but in practice this is not allowed:
import std.stdio: writeln;
void main() {
// Hofstadter Female and Male sequences
int M(int);
int F(int n) {
return n ? n - M(F(n - 1)) : 1;
}
int M(int n) { // test.d(11): Error: declaration M is already defined
return n ? n - F(M(n - 1)) : 0;
}
foreach (i; 0 .. 100)
writeln(F(i));
}
Bye,
bearophile
Re: Nested function declarations
Well, you might be linking to an external function /and/ don't want
the function to be visible at module scope:
void main() {
extern(C) double func(); // linked from some C library..
double result = func();
}
You don't have to worry too much about your first example, it might
compile but it won't link:
import std.math: sqrt;
void main() {
double sqrt();
double result = sqrt();
}
Error 42: Symbol Undefined _D12externalTest4mainFZv4sqrtMFZd
--- errorlevel 1
Re: Nested function declarations
bearophile bearophileh...@lycos.com a écrit dans le message de news:
iht0ha$2avd$1...@digitalmars.com...
This D2 code:
import std.math: sqrt;
void main() {
double sqrt();
double result = sqrt(9.0);
}
Generates the errors:
test.d(4): Error: function test.main.sqrt () is not callable using
argument types (double)
test.d(4): Error: expected 0 arguments, not 1 for non-variadic function
type double()
--- This one compiles, but does not link:
import std.math: sqrt;
void main()
{
double sqrt(double x);
double result = sqrt(9.0);
}
--- And this one compiles and links ok.
import std.math: sqrt;
void main()
{
double sqrt(double x) {return 1.0; }
double result = sqrt(9.0);
}
So, with the appropriate prototype it compiles, but
there is a conflict with the sqrt() already defined in Phobos.
Problem with Sorting
Hi,
I am facing the following problems with sorting. .
module testSort;
import std.stdio;
import std.algorithm;
class testcl {
public string name;
this(string na) { name=na; }
public string toString() {
return name;
}
public int opCmp(testcl b) {
return name b.name ? -1: 1;
}
}
int main(string[] args) {
testcl a = new testcl(args[1]);
testcl b = new testcl(args[2]);
testcl[] arr = [a,b];
writeln(arr);
sort!(ab)(arr);
writeln(arr);
return 0;
}
I get the following input when i run this program as:
./testSort te2 test2
[te2, test2]
[test2, te2]
./testSort test1 test2
[test1, test2]
[test2, test1]
which is as desired.. But randomly with a few strings it gives me a range
violation as:
./testSort test2 te1
[test2, te1]
core.exception.RangeError@std.algorithm(5293): Range violation
./testSort() [0x80599d6]
./testSort() [0x8050ca6]
./testSort() [0x8052b26]
./testSort() [0x804d39d]
./testSort() [0x804d2a8]
./testSort() [0x804ce3a]
./testSort() [0x8049919]
./testSort() [0x8050e66]
./testSort() [0x8050dc0]
./testSort() [0x8050eaa]
./testSort() [0x8050dc0]
./testSort() [0x8050d66]
/lib/libc.so.6(__libc_start_main+0xe7) [0x139ce7]
./testSort() [0x8049751]
The problem gets corrected if i write the comparison function as :
public int opCmp(testcl b) {
if(name == b.name) return 0;
return name b.name ? -1: 1;
}
I could not get the problem with the above code.
Thanks
Mandeep
Re: Problem with Sorting
On Thursday 27 January 2011 20:30:47 Mandeep Singh Brar wrote:
Hi,
I am facing the following problems with sorting. .
module testSort;
import std.stdio;
import std.algorithm;
class testcl {
public string name;
this(string na) { name=na; }
public string toString() {
return name;
}
public int opCmp(testcl b) {
return name b.name ? -1: 1;
}
}
int main(string[] args) {
testcl a = new testcl(args[1]);
testcl b = new testcl(args[2]);
testcl[] arr = [a,b];
writeln(arr);
sort!(ab)(arr);
writeln(arr);
return 0;
}
I get the following input when i run this program as:
./testSort te2 test2
[te2, test2]
[test2, te2]
./testSort test1 test2
[test1, test2]
[test2, test1]
which is as desired.. But randomly with a few strings it gives me a range
violation as:
./testSort test2 te1
[test2, te1]
core.exception.RangeError@std.algorithm(5293): Range violation
./testSort() [0x80599d6]
./testSort() [0x8050ca6]
./testSort() [0x8052b26]
./testSort() [0x804d39d]
./testSort() [0x804d2a8]
./testSort() [0x804ce3a]
./testSort() [0x8049919]
./testSort() [0x8050e66]
./testSort() [0x8050dc0]
./testSort() [0x8050eaa]
./testSort() [0x8050dc0]
./testSort() [0x8050d66]
/lib/libc.so.6(__libc_start_main+0xe7) [0x139ce7]
./testSort() [0x8049751]
The problem gets corrected if i write the comparison function as :
public int opCmp(testcl b) {
if(name == b.name) return 0;
return name b.name ? -1: 1;
}
I could not get the problem with the above code.
Well, of course the first version doesn't work. opCmp is supposed to return 0
if
the values are equal, and it doesn't do that. opCmp returns a value 0 if the
first value is less than the second, 0 if they're equal, and a value 0 if the
first value is greater than the second value.
Also, the signature for opCmp on classes is supposed to be
int opCmp(Object o)
It's supposed to take Object. I'm surprised that it works at all the way that
it
is.
And since you're comparing strings, your opCmp can just use std.string.cmp to
compare them.
- Jonathan M Davis
