Re: Andrei's Google Talk
On Sat, 7 Aug 2010 01:19:03 -0400, Nick Sabalausky a...@a.a wrote: Jesse Phillips jessekphillip...@gmail.com wrote in message news:i3hr7p$1s...@digitalmars.com... Steven Schveighoffer Wrote: I wouldn't mind the current docs, but I'd like to have some document to know what tags are defined and what they mean (like a ddocdoc), and how to define new tags. Maybe this already exists? My two comments are, shouldn't paragraphs be handled with a blank line? YES. And along those exact lines, may I say I'm a big fan of the Natural Docs approach. IMO, comments should be [*easily*] readable *before* being run through a doc generator, not just after. Of course, in that regard (not to mention writeability) DDoc beats the snot out of C#'s horrid XML comments (I've never understood MS's enormous obsession with XML), but DDoc still has that same fundamental problem. Just in case you haven't seen this page before: http://www.charlespetzold.com/etc/CSAML.html ;)
Re: Phobos-compatible license on Google Code?
On Sat, 31 Jul 2010 17:06:26 +0100, div0 d...@sourceforge.net wrote: On 31/07/2010 03:50, Justin Spahr-Summers wrote: Yes, thank you. I misworded my original question. I was hoping to host on Google Code, because it's been the most reliable and functional (free) project hosting I've found, and I'd love to entertain hopes of eventually submitting the code as a Phobos module. Try: http://www.xp-dev.com/ They do every CVS system under the sun and don't bitch about licenses for open source projects. I was happy enough with the service to actually pay for it. It's certainly tempting, but the fact that they don't offer Mercurial without payment is a bit off-putting to me.
Phobos-compatible license on Google Code?
Google Code allows selection from the following licenses for new projects: Apache License 2.0 Artistic License/GPL Eclipse Public License 1.0 GPL v2 GPL v3 LGPL MIT License Mozilla Public License 1.1 New BSD License Obviously, the GNU licenses are out of the question (listed only for completeness). But of the rest, are any compatible with the Boost license used for Phobos? Dual-licensing is always an option too, but certainly a lot uglier.
Re: Phobos-compatible license on Google Code?
On Sat, 31 Jul 2010 02:47:30 + (UTC), retard r...@tard.com.invalid wrote: Fri, 30 Jul 2010 21:41:44 -0500, Justin Spahr-Summers wrote: Google Code allows selection from the following licenses for new projects: Apache License 2.0 Artistic License/GPL Eclipse Public License 1.0 GPL v2 GPL v3 LGPL MIT License Mozilla Public License 1.1 New BSD License Obviously, the GNU licenses are out of the question (listed only for completeness). But of the rest, are any compatible with the Boost license used for Phobos? Dual-licensing is always an option too, but certainly a lot uglier. They're all compatible with Phobos. The point was to make Phobos as compatible as possible with various kinds of other licenses. What you probably wanted to know is whether code contributions to Phobos can be licensed under these licenses. They probably want to use the same license (Boost in this case), if possible. Yes, thank you. I misworded my original question. I was hoping to host on Google Code, because it's been the most reliable and functional (free) project hosting I've found, and I'd love to entertain hopes of eventually submitting the code as a Phobos module.
Re: string initialization question.
On Fri, 30 Jul 2010 11:35:15 -0400, Steven Schveighoffer schvei...@yahoo.com wrote: On Fri, 30 Jul 2010 11:24:41 -0400, dcoder dco...@devnull.com wrote: Hello. Is there anyway in D to convenient fill a string variable with a char say X times? So, I'd like to do something like: string divider( size, '-');// C++ notation. $divider = '-' x $size;// perl notation. I thought I could do the following: const char divider[rowstr.length] = '-'; but the compiler complains about not having a constant integer expression. thanks. It's most likely complaining about rowstr.length not being a constant, not the '-'. This works: const char divider[5] = '-'; If you want to allocate a new array on the heap with '-' in it, I think there is a way, but I'm not sure how to do it. I'm pretty sure there's a runtime function to do it. -Steve Something like this will work on the heap: char[] divider = new char[5]; divider[] = '-';
Re: poll about delete
On Tue, 27 Jul 2010 11:36:19 -0700, Jonathan M Davis jmdavisp...@gmail.com wrote: At minimum, we should have a list of features which are still in dmd but which are (or should be) deprecated so that we know what not to use (along with actually deprecating everything that's supposed to be deprecated but not yet outright removed). Agreed! I only know which language features to avoid because I lurk in the newsgroups. Programmers new to D have no idea what's scheduled for deprecation. This kind of list has been suggested multiple times, but I strongly believe that someone with a hand in the language itself (e.g., Andrei) should just take 30 minutes one day and compile an authoritative reference.
Re: Single alias this
On Sun, 25 Jul 2010 10:53:51 -0400, bearophile
bearophileh...@lycos.com wrote:
Deokjae Lee:
//interfaces first, base class last
class Foo : I1, I2, Base {}
This doesn't compile.
I didn't know the order of base class and interfaces matter.
If not already present, that looks good for Bugzilla.
That's as specified in the language spec:
http://digitalmars.com/d/2.0/class.html#BaseClassList
You could argue that it shouldn't be that way, but it's correct behavior
as the language stands now.
Re: Grokking concurrency, message passing and Co
On Mon, 12 Jul 2010 00:03:53 +0200, BLS windev...@hotmail.de wrote: On 11/07/2010 21:29, Philippe Sigaud wrote: I tried this because I was reading an article on Scala's actors, where they talk about millions of actors. I guess they are quite different. Google for fibers or have a look at the dreactor project on dsource. Tango has fiber support (afaik). hth bjoern Phobos2 has a Fiber class in core.thread as well.
Re: Any special linking for _NSGetExecutablePath on OSX?
On Thu, 8 Jul 2010 19:24:52 -0400, Nick Sabalausky a...@a.a wrote: I need to use OSX's _NSGetExecutablePath, and I've declared it: extern(C) int _NSGetExecutablePath(char* buf, uint* bufsize); I don't have access to a OSX box to test it on ATM, so I need to know: Is there anything I need to tell the linker (like, anything special I need to explicitly link in) in order to get that to work, or should it just work? (ie, is whatever library is needed for that already linked by default?) I haven't used the function before, but after looking it up really quickly, that declaration looks good to go. Since it's part of the dynamic linker, I can't imagine that a library would have to be linked in for it to work.
Re: mangle
On Fri, 02 Jul 2010 08:41:45 -0400, Steven Schveighoffer schvei...@yahoo.com wrote: On Thu, 01 Jul 2010 23:03:31 -0400, Justin Spahr-Summers justin.spahrsumm...@gmail.com wrote: On Thu, 1 Jul 2010 19:34:09 -0700, Jonathan M Davis jmdavisp...@gmail.com wrote: On Thursday, July 01, 2010 19:13:02 Rainer Deyke wrote: On 7/1/2010 19:32, Jonathan M Davis wrote: By the way, why _does_ D mangle its names? What's the advantage? I understood that C++ does it because it was forced to back in the days when it was transformed into C code during compilation but that it's now generally considered a legacy problem that we're stuck with rather than something that would still be considered a good design decision. So, why did D go with name mangling? It certainly makes stuff like stack traces harder to deal with. I've never heard of any advantage to name mangling, only disadvantages. Because DMD is stuck with a C-age linker. Well, I guess that it just goes to show how little I understand about exactly how linking works when I don't understand what that means. After all, C doesn't using name mangling. Does that mean that name mangling it meant as a namespacing tool to ensure that no D function could possibly have the same linking name as a C function? - Jonathan M Davis C doesn't require mangling because functions can't be overloaded. To make D (or C++) compatible with C linkers, symbol names need to be unique, so functions with identical names but different types need to be represented with different symbols. This isn't really the reason for mangling. The issue is that the C linker requires symbols to be the same as source symbols. That is, made up only of A-Z,a-z,0-9 and _. I'd much rather see symbol names like this: foo(int,string) than fooIvS45whatever -Steve Right, but that's only an issue because of overloaded types. C suffers no such problems because a symbol with a given name is guaranteed to be unique within the same translation unit.
Re: D: An Up and Coming Embedded Software Language
On Thu, 01 Jul 2010 17:54:54 -0400, bearophile bearophileh...@lycos.com wrote: Michel Fortin: I sure hope it will. In the meanwhile, more and more code is being written in (or ported to) D2 which is potentially missing 'override' everywhere. Wouldn't it be better to do this sooner rather than later? Both Walter and Andrei want it, so it's a matter of time. It doesn't even need to be implemented, because this test is already present in the compiler: I generally suggest D programmers to compile their code with the -w (warnings), it helps catch some bugs and it forces you to use override. And even if some D2 code lacks override, you need a very short place add a hundred missing override in a large program. Bye, bearophile Object not being const correct is probably a blocker for mandatory use of override: http://d.puremagic.com/issues/show_bug.cgi?id=1824 I compile with -w, and trying to write correct overrides for toString(), toHash(), etc. is a pain.
Re: mangle
On Thu, 1 Jul 2010 19:34:09 -0700, Jonathan M Davis jmdavisp...@gmail.com wrote: On Thursday, July 01, 2010 19:13:02 Rainer Deyke wrote: On 7/1/2010 19:32, Jonathan M Davis wrote: By the way, why _does_ D mangle its names? What's the advantage? I understood that C++ does it because it was forced to back in the days when it was transformed into C code during compilation but that it's now generally considered a legacy problem that we're stuck with rather than something that would still be considered a good design decision. So, why did D go with name mangling? It certainly makes stuff like stack traces harder to deal with. I've never heard of any advantage to name mangling, only disadvantages. Because DMD is stuck with a C-age linker. Well, I guess that it just goes to show how little I understand about exactly how linking works when I don't understand what that means. After all, C doesn't using name mangling. Does that mean that name mangling it meant as a namespacing tool to ensure that no D function could possibly have the same linking name as a C function? - Jonathan M Davis C doesn't require mangling because functions can't be overloaded. To make D (or C++) compatible with C linkers, symbol names need to be unique, so functions with identical names but different types need to be represented with different symbols.
Re: A module comprehensive template-specialization
On Sun, 27 Jun 2010 18:51:35 +0200, Matthias Walter
xa...@xammy.homelinux.net wrote:
Hi list,
I tried to write a traits class comparable to iterator_traits in C++ STL
or graph_traits in Boost Graph Library in D 2.0, but failed to do so via
template specialization which is put into different modules. Putting
everything into one module interferes with extensibility. I tried the
following:
== Module a ==
| module a;
|
| template Base (T)
| {
| alias T Base;
| }
== Module b ==
| module b;
|
| import a;
|
| template Base(T: T*)
| {
| alias Base !(T) Base;
| }
== Main module ==
|
| import a, b;
|
| int main(char[][] args)
| {
| alias Base !(int*) foo;
|
| return 0;
| }
The error message is:
bug.d(8): Error: template instance ambiguous template declaration
b.Base(T : T*) and a.Base(T)
Can I handle this in another way (like making the template a conditional
one)?
best regards
Matthias Walter
I believe this is intended behavior, as it prevents template hijacking
and the like. Using alias to import the two templates into the same
scope might help, though I'm not sure exactly how it should be done.
On another note, though, have you looked at __traits() and std.traits?
Re: Mac OS X Installation
On Thu, 24 Jun 2010 01:29:53 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 06/23/2010 11:52 PM, ch...@freshsources.com wrote: I have successfully installed D 2.0 on a number of Macs. However, the latest attempt yields the following error when I try to compile any file: object.d: Error: module object is in file 'object.d' which cannot be read import path[0] = /etc/../../src/phobos import path[1] = /etc/../../src/druntime/import As usual, I faithfully followed the instructions at http://www.digitalmars.com/d/2.0/dmd-osx.html Any ideas on how to fix this? Thanks. Hi, Chuck! Looks like the files aren't where they are supposed to be. Try this: head /etc/../../src/druntime/import/object.di Normally you should see the first ten lines of that file. If there's an error, write back what the error message is. Andrei Isn't /etc/../.. the root directory? That seems like an awfully incorrect place to the put the includes. I installed the druntime and phobos folders into /usr/local/include and then edited my /etc/dmd.conf accordingly. It seems to work pretty well, though it does require some setup.
Re: Mac OS X Installation
On Thu, 24 Jun 2010 13:30:31 -0400, Nick Sabalausky a...@a.a wrote: Justin Spahr-Summers justin.spahrsumm...@gmail.com wrote in message news:mpg.268ca23b487143c5989...@news.digitalmars.com... On Thu, 24 Jun 2010 01:29:53 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 06/23/2010 11:52 PM, ch...@freshsources.com wrote: I have successfully installed D 2.0 on a number of Macs. However, the latest attempt yields the following error when I try to compile any file: object.d: Error: module object is in file 'object.d' which cannot be read import path[0] = /etc/../../src/phobos import path[1] = /etc/../../src/druntime/import As usual, I faithfully followed the instructions at http://www.digitalmars.com/d/2.0/dmd-osx.html Any ideas on how to fix this? Thanks. Hi, Chuck! Looks like the files aren't where they are supposed to be. Try this: head /etc/../../src/druntime/import/object.di Normally you should see the first ten lines of that file. If there's an error, write back what the error message is. Andrei Isn't /etc/../.. the root directory? That seems like an awfully incorrect place to the put the includes. No, /etc/../ is root. /etc/../../ is /.. (ie parent of root), which is nonsensical. --- Not sent from an iPhone. /etc is a soft link to /private/etc on all OS X systems I've seen. I also think /.. always refers to / on *nix, but I could be wrong there.
Re: String Literal Docs
On Mon, 21 Jun 2010 15:20:16 -0500, Ellery Newcomer ellery- newco...@utulsa.edu wrote: Are your diagrams solely concerned with the lexer? Because I have a (messy) parser grammar which I'm a bit more confident about if you're interested. I can't speak for Alix, but I would absolutely be interested. I'm working on an Objective-D preprocessor and my parsing still has lots of holes, even besides the stuff I have marked to-do. A strict reading of the website has already turned up a few inaccuracies.
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
On Tue, 22 Jun 2010 09:17:57 -0400, Adam Ruppe
destructiona...@gmail.com wrote:
What you guys are saying makes enough sense. switch will always be a
series of labels and jumps in my mind, but I can deal with this.
One note that I think is the main reason people find fallthrough
confusing: they hit tab once too many times.
switch(a) {
case 10:
case 20: // obvious fallthrough, no break directly above it
break; // obvious break - same indentation as the case, just like
braces would be
case 30:
}
I notice a lot of other people indent the break further than the case,
which is something I only do if the break is not the last statement
(which means it is probably indented twice, being inside an if or
something.)
Oh well.
I would argue the exact opposite. I think it's not immediately clear
what's associated with each case label in the example given. It's a
matter of personal preference, though, in the end. I leave labels (both
for switches and goto) at the left-most position of their enclosing
block:
switch (a) {
case 5:
case 10:
break;
default:
;
}
void main () {
goto doSomething;
doSomething:
writeln(foobar);
}
But I know there will probably be lots of people who dislike that as
well. :P
Re: main.d(61): Error: temp_[i_] isn't mutable
On Sun, 20 Jun 2010 12:01:31 + (UTC), Ben Hanson ben.han...@tfbplc.co.uk wrote: == Quote from Justin Spahr-Summers (justin.spahrsumm...@gmail.com)'s string is actually an alias for immutable(char)[] (and similarly for the other string types), so its contents are not modifiable, though its length can be adjusted and contents appended. If you need to be able to modify the characters, just use char[] instead. You can then use the .idup property to get a string afterward. I'm converted temp_ to CharT[] as suggested, but the conversion back to a string is failing: _charset = temp_.idup; main.d(76): Error: cannot implicitly convert expression (_adDupT(( D58TypeInfo_AT4main14__T5regexTAyaZ18basic_string_token5CharT6__initZ),cast (string)temp_)) of type immutable(CharT)[] to string Sorry I missed this on the first run through. Since you're using typedef to create your CharT type, it will create a type independent from all the others, meaning no implicit casts to or from it. alias is the equivalent to a C/C++ typedef, and that should fix the compilation error.
Re: main.d(61): Error: temp_[i_] isn't mutable
On Sat, 19 Jun 2010 17:30:26 + (UTC), Ben Hanson
ben.han...@tfbplc.co.uk wrote:
Here's the complete source:
module main;
import std.algorithm;
import std.string;
template regex(StringT)
{
struct basic_string_token
{
bool _negated = false;
StringT _charset;
typedef typeof(StringT.init[0]) CharT;
enum size_t MAX_CHARS = CharT.max + 1;
this(const bool negated_, ref StringT charset_)
{
_negated = negated_;
_charset = charset_;
}
void remove_duplicates()
{
_charset.sort;
_charset = squeeze(_charset);
}
void normalise()
{
if (_charset.length == MAX_CHARS)
{
_negated = !_negated;
_charset.clear();
}
else if (_charset.length MAX_CHARS / 2)
{
negate();
}
}
void negate()
{
CharT curr_char_ = MAX_CHARS == 256 ? 0x80 : 0;
StringT temp_;
size_t curr_ = 0;
size_t end_ = _charset.length;
size_t i_ = 0;
_negated = !_negated;
temp_.length = MAX_CHARS - end_;
while (curr_ end_)
{
while (_charset[curr_] curr_char_)
{
temp_[i_] = curr_char_;
++curr_char_;
++i_;
}
++curr_char_;
++curr_;
++i_;
}
for (; i_ MAX_CHARS; ++i_)
{
temp_ ~= curr_char_;
++curr_char_;
}
_charset = temp_;
}
};
}
int main(char[][]argv)
{
regex!(string).basic_string_token token_;
token_._charset = cccbba;
token_.remove_duplicates();
token_.negate();
return 0;
}
Can anyone explain the error 'main.d(61): Error: temp_[i_] isn't
mutable'? Can I use pointers instead like the C++ code? What's the
best approach for maximum efficiency in D (pointers would make the
conversion easier to, I guess).
Thanks,
Ben
string is actually an alias for immutable(char)[] (and similarly for
the other string types), so its contents are not modifiable, though its
length can be adjusted and contents appended. If you need to be able to
modify the characters, just use char[] instead. You can then use the
.idup property to get a string afterward.
Re: Is there ANY chance we can fix the bitwise operator precedence rules?
On Fri, 18 Jun 2010 20:17:09 -0700, Jonathan M Davis jmdavisp...@gmail.com wrote: I, for one, _want_ case statements to be able to fall through. It would be horribly painful in many cases if they couldn't. Now, requiring a separate statement like fallthrough or somesuch instead of break might not be a bad idea, but requiring that each case end with a break would seriously restrict the usefulness of switch statements. I agree. But the basic idea is to do extra work if you're doing something unusual, and falling through is unusual. Certainly a good principle and one that D holds to for the most part - certainly far better than many other languages. Follow the principle too much, though, and you end up in the Ruby (more specifically, Rails) camp. It's amazing when you don't need to do something unusual, but *man* have I had problems trying to do what I want with Rails. That said, having used C for a significant period of time, I'm well aware of the fall-through semantics and use it from time to time, but I wouldn't be opposed to removing implicit fall-through from the language. Fall-through doesn't strike me as a big issue in and of itself, but dogmatic languages aren't fun to work with either.
Re: ERROR - cannot implicitly convert expression (s) of type int[3u] to int*
On Fri, 18 Jun 2010 01:25:32 -0400, Chick Corea chick.zco...@gmail.com wrote: Those are the result of code that I pulled directly from the D v1 docs from http://www.digitalmars.com/d/1.0/arrays.html Specifically, the code is this. int* p; int[3] s; int[] a; p = s; p = a; I can't speak as to why the D2 code doesn't work, but this example in the documentation is flat out wrong. To assign a D array to a pointer, you must use the .ptr property, so that the correct code is actually: int* p; int[3] s; int[] a; p = s.ptr; p = a.ptr; Hope this clears things up.
Re: ERROR - cannot implicitly convert expression (s) of type int[3u] to int*
On Fri, 18 Jun 2010 08:41:17 -0700, Justin Spahr-Summers justin.spahrsumm...@gmail.com wrote: On Fri, 18 Jun 2010 01:25:32 -0400, Chick Corea chick.zco...@gmail.com wrote: Those are the result of code that I pulled directly from the D v1 docs from http://www.digitalmars.com/d/1.0/arrays.html Specifically, the code is this. int* p; int[3] s; int[] a; p = s; p = a; I can't speak as to why the D2 code doesn't work, but this example in the documentation is flat out wrong. To assign a D array to a pointer, you must use the .ptr property, so that the correct code is actually: int* p; int[3] s; int[] a; p = s.ptr; p = a.ptr; Hope this clears things up. I followed up last night, but my post didn't show up until this morning. Sorry for the redundant answer! :X
Re: Signed word lengths and indexes
On Thu, 17 Jun 2010 02:46:13 -0400, Kagamin s...@here.lot wrote: Walter Bright Wrote: Easy. offset should be a size_t, not an unsigned. I've hit the bug using size_t at the right side of a+=-b (array length). It's just a long was at the left side (file offset). Such code should actually work in 64bit system and it fails in 32bit. MS compiler reports such portability issues with a warning, I believe. This sounds more like an issue with file offsets being longs, ironically. Using longs to represent zero-based locations in a file is extremely unsafe. Such usages should really be restricted to short-range offsets from the current file position, and fpos_t used for everything else (which is assumably available in std.c.stdio).
Re: Signed word lengths and indexes
On Thu, 17 Jun 2010 03:27:59 -0400, Kagamin s...@here.lot wrote: Justin Spahr-Summers Wrote: This sounds more like an issue with file offsets being longs, ironically. Using longs to represent zero-based locations in a file is extremely unsafe. Such usages should really be restricted to short-range offsets from the current file position, and fpos_t used for everything else (which is assumably available in std.c.stdio). 1. Ironically the issue is not in file offset's signedness. You still hit the bug with ulong offset. How so? Subtracting a size_t from a ulong offset will only cause problems if the size_t value is larger than the offset. If that's the case, then the issue remains even with a signed offset. 2. Signed offset is two times safer than unsigned as you can detect underflow bug (and, maybe, overflow). The solution with unsigned values is to make sure that they won't underflow *before* performing the arithmetic - and that's really the proper solution anyways. With unsigned offset you get exception if the filesystem doesn't support sparse files, so the linux will keep silence. I'm not sure what this means. Can you explain? 3. Signed offset is consistent/type-safe in the case of the seek function as it doesn't arbitrarily mutate between signed and unsigned. My point was about signed values being used to represent zero-based indices. Obviously there are applications for a signed offset *from the current position*. It's seeking to a signed offset *from the start of the file* that's unsafe. 4. Choosing unsigned for file offset is not dictated by safety, but by stupidity: hey, I lose my bit! You referred to 32-bit systems, correct? I'm sure there are 32-bit systems out there that need to be able to access files larger than two gigabytes. I AM an optimization zealot, but unsigned offsets are plain dead freaking stupid. It's not an optimization. Unsigned values logically correspond to disk and memory locations.
Re: Signed word lengths and indexes
On Thu, 17 Jun 2010 10:00:24 +0200, Don nos...@nospam.com wrote: (D has introduced ANOTHER instance of this with the ridiculous operator. byte b = -1; byte c = b 1; Guess what c is! ) 127, right? I know at least RISC processors tend to have instructions for both a logical and algebraic right shift. In that context, it makes sense for a systems programming language.
Re: Signed word lengths and indexes
On Thu, 17 Jun 2010 06:41:33 -0400, Kagamin s...@here.lot wrote: Justin Spahr-Summers Wrote: 1. Ironically the issue is not in file offset's signedness. You still hit the bug with ulong offset. How so? Subtracting a size_t from a ulong offset will only cause problems if the size_t value is larger than the offset. If that's the case, then the issue remains even with a signed offset. May be, you didn't see the testcase. ulong a; ubyte[] b; a+=-b.length; // go a little backwards I did see that, but that's erroneous code. Maybe the compiler could warn about unary minus on an unsigned type, but I find such problems rare as long as everyone working on the code understands signedness. or seek(-b.length, SEEK_CUR, file); I wouldn't call it a failure of unsigned types that this causes problems. Like I suggested above, the situation could possibly be alleviated if the compiler just warned about unary minus no-ops. Like a couple others pointed out, this is just a lack of understanding of unsigned types and modular arithmetic. I'd say that any programmer should have such an understanding, regardless if their programming language of choice supports unsigned types or not. 2. Signed offset is two times safer than unsigned as you can detect underflow bug (and, maybe, overflow). The solution with unsigned values is to make sure that they won't underflow *before* performing the arithmetic - and that's really the proper solution anyways. If you rely on client code to be correct, you get security issue. And client doesn't necessarily use your language or your compiler. Or he can turn off overflow checks for performance. Or he can use the same unsigned variable for both signed and unsigned offsets, so checks for underflow become useless. What kind of client are we talking about? If you're referring to contract programming, then it's the client's own fault if they fiddle around with the code and end up breaking it or violating its conventions. With unsigned offset you get exception if the filesystem doesn't support sparse files, so the linux will keep silence. I'm not sure what this means. Can you explain? This means that you have subtle bug. 3. Signed offset is consistent/type-safe in the case of the seek function as it doesn't arbitrarily mutate between signed and unsigned. My point was about signed values being used to represent zero-based indices. Obviously there are applications for a signed offset *from the current position*. It's seeking to a signed offset *from the start of the file* that's unsafe. To catch this is the case of signed offset you need only one check. In the case of unsigned offsets you have to watch underflows in the entire application code even if it's not related to file seeks - just in order to fix issue that can be fixed separately. Signed offsets can (truly) underflow as well. I don't see how the issue is any different. 4. Choosing unsigned for file offset is not dictated by safety, but by stupidity: hey, I lose my bit! You referred to 32-bit systems, correct? I'm sure there are 32-bit systems out there that need to be able to access files larger than two gigabytes. I'm talking about 64-bit file offsets which are 64-bit on 32-bit systems too. In D's provided interface, this is true, but fseek() from C uses C's long data type, which is *not* 64-bit on 32-bit systems, and this is (I assume) what std.stdio uses under-the-hood, making it doubly unsafe. As to file size limitations there's no difference between signed and unsigned lenghts. File sizes have no tendency stick to 4 gig value. If you need to handle files larger that 2 gigs, you also need to handle files larger than 4 gigs. Of course. But why restrict oneself to half the available space unnecessarily? I AM an optimization zealot, but unsigned offsets are plain dead freaking stupid. It's not an optimization. Unsigned values logically correspond to disk and memory locations. They don't. Memory locations are a *subset* of size_t values range. That's why you have bound checks. And the problem is usage of these locations: memory bus doesn't perform computations on the addresses, application does - it adds, subtracts, mixes signeds with unsigneds, has various type system holes or kludges, library design issues, used good practices etc. In other words, it gets a little bit complex than just locations. Bounds checking does alleviate the issue somewhat, I'll grant you that. But as far as address computation, even if your application does none, the operating system still will in order to map logical addresses, which start at 0, to physical addresses, which also start at 0. And the memory bus absolutely requires unsigned values even if it needs to perform no computation itself.
Re: Minimize lock time
On Thu, 10 Jun 2010 12:42:09 +0200, Simen kjaeraas
simen.kja...@gmail.com wrote:
Kagamin s...@here.lot wrote:
Let's consider the following code:
synchronized(syncRoot)
{
if(condition)opSuccess();
else writeln(possibly,slow);
}
Suppose the else close doesn't need to be executed in lock domain and
can be slow. How to minimize lock time here?
synchronized(syncRoot)
{
if(condition)opSuccess();
else goto Lwrite;
}
Lwrite: writeln(possibly,slow);
We can do this... but...
A flag, as has been mentioned, would work.
Other solutions that might work:
synchronized(syncRoot)
{
if (condition)
{
opSuccess();
return;
}
}
writeln(possibly,slow);
do
{
synchronized(syncRoot)
{
if (condition)
{
opSuccess();
break;
}
}
writeln(possibly, slow);
All good suggestions. synchronized(), in general, just doesn't scale
very well (though no fault of D's). If you're doing very complex things,
you might have better luck with a semaphore of some kind. As always,
though, avoiding the need for synchronization is best.
Re: Minimize lock time
On Thu, 10 Jun 2010 02:54:37 -0400, Kagamin s...@here.lot wrote:
Let's consider the following code:
synchronized(syncRoot)
{
if(condition)opSuccess();
else writeln(possibly,slow);
}
Suppose the else close doesn't need to be executed in lock domain and can be
slow. How to minimize lock time here?
synchronized(syncRoot)
{
if(condition)opSuccess();
else goto Lwrite;
}
Lwrite: writeln(possibly,slow);
We can do this... but...
A common pattern is to use a boolean flag:
bool success;
synchronized (syncRoot)
{
success = (condition);
}
if (success) opSuccess();
else writeln(possibly, slow);
Re: Variant[string] assoc array -- runtime error
On Sun, 06 Jun 2010 03:11:45 -0400, Robert Jacques sandf...@jhu.edu
wrote:
On Sun, 06 Jun 2010 02:35:16 -0400, Graham Fawcett fawc...@uwindsor.ca
wrote:
Hi folks,
Is this a new bug or a known one?
// bad.d
import std.variant;
void main() {
Variant b = something;
Variant[string] table;
table[hello] = b; // line 6
}
With DMD 2.043, this compiles, but at runtime I get:
core.exception.rangeer...@bad(6): Range violation
Graham
I've run into a similar bug before, but as a quick search in bugzilla
didn't turn up anything. (it looks like I forgot to file a bug report for
it) Anyways, I'd recommend filing it:
http://d.puremagic.com/issues/enter_bug.cgi
There's http://d.puremagic.com/issues/show_bug.cgi?id=2451 (that's
bitten me before).
Re: Marketing of D - article topic ideas?
On Sun, 6 Jun 2010 22:42:42 + (UTC), dsimcha dsim...@yahoo.com
wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
D is an extremely powerful language, but when I read complaints and sighs
about
other languages, few seem to know that these problems are solved with D.
Essentially, we have a marketing problem.
One great way to address it is by writing articles about various aspects of
D
and how they solve problems, like
http://www.reddit.com/r/programming/comments/cb14j/compiletime_function_execution_in_d/
which was well received on reddit.
Anyone have good ideas on topics for D articles? And anyone want to stand
up and
write an article?
They don't have to be comprehensive articles (though of course those are
better), even blog entries will do.
This probably won't be replied to because I'm starting a new sub-thread in a
mature discussion, but I wonder if we could write about the advantages and
disadvantages of duck typing vs. static typing, comparing Python vs. Java at
first, then bring D into the picture to show how, to a greater extent than C++
templates or C#/Java generics, it solves may of the problems of static typing
without introducing the pitfalls of duck typing.
Here's a simple example of something that would be awkward to impossible to do
efficiently in any other language:
/**Finds the largest element present in any of the ranges passed in.\
*/
CommonType!(staticMap!(ElementType, T)) largestElement(T...)(T args) {
// Quick and dirty impl ignoring error checking:
typeof(return) ret = args[0].front();
foreach(arg; args) {
foreach(elem; arg) {
ret = max(elem, ret);
}
}
return ret;
}
Do this in C++ - FAIL because there are no variadics. (Yes, C++1x will have
them, but I might die of old age by the time C++1x exists.)
Do this in any dynamic language - FAIL because looping is so slow that you
might
die of old age before it executes. Besides, who wants to do computationally
intensive, multithreaded work in a dynamic language?
Do this in Java - FAIL because arrays are primitives, not Objects and
variadics
only work with Objects. You can't easily make an array of arrays because the
elements of args may be different but related types (e.g. int, float).
Seems like that example could be done fairly easily with Objective-C.
Granted, it won't have the raw performance of D, but it might be
worthwhile to point it out, since it (or rather, its superset on top of
C) is duck typed.
If someone were to create Objective-D, I think I'd die of happiness.
Re: need clarification: will typedef, C struct initialization, etc.
On Tue, 01 Jun 2010 06:05:50 +0800, Lionello Lunesu l...@lunesu.remove.com wrote: On 1-6-2010 5:38, Andrei Alexandrescu wrote: On 05/31/2010 03:54 PM, bearophile wrote: Andrei Alexandrescu: typedef is gone. *mewls* I have shown here some examples of typedef usage, and I'll keep posting few more in future. I'd like to pull it back from the grave and keep it :-) It's wasted time. typedef is gone. Andrei :(( I also miss typedef. I thought D had a great opportunity to fix it. Take something like the Windows headers. It mostly consists of typedefs for handles and whatnot. Without typedef you'd have to use alias and type safety is out of the windows. So what would be the way to translate those Windows headers? Create a unique struct for each old typedef? With alias this, and a ctor? Well, if that's the way to do it now, why not make typedef a shortcut for exactly that!? I'm a fan of typedef, personally, but the example you mentioned *would* be solved using just an alias. 'alias' provides the same functionality as C/C++'s 'typedef' and more.
Re: need clarification: will typedef, C struct initialization, etc.
On Mon, 31 May 2010 23:31:18 -0300, Leandro Lucarella llu...@gmail.com
wrote:
Justin Spahr-Summers, el 31 de mayo a las 16:41 me escribiste:
On Tue, 01 Jun 2010 06:05:50 +0800, Lionello Lunesu
l...@lunesu.remove.com wrote:
On 1-6-2010 5:38, Andrei Alexandrescu wrote:
On 05/31/2010 03:54 PM, bearophile wrote:
Andrei Alexandrescu:
typedef is gone.
*mewls* I have shown here some examples of typedef usage, and I'll
keep posting few more in future. I'd like to pull it back from the
grave and keep it :-)
It's wasted time. typedef is gone.
Andrei
:((
I also miss typedef. I thought D had a great opportunity to fix it.
Take something like the Windows headers. It mostly consists of typedefs
for handles and whatnot. Without typedef you'd have to use alias and
type safety is out of the windows.
So what would be the way to translate those Windows headers? Create a
unique struct for each old typedef? With alias this, and a ctor? Well,
if that's the way to do it now, why not make typedef a shortcut for
exactly that!?
I'm a fan of typedef, personally, but the example you mentioned *would*
be solved using just an alias. 'alias' provides the same functionality
as C/C++'s 'typedef' and more.
I think he talks about this difference:
alias int a1;
alias int a2;
typedef int t1;
typedef int t2;
void fa(a2 a) {}
void ft(t2 t) {}
void main() {
a1 a = 5;
fa(a); // --- compiles fine
t1 t = 10;
ft(t); // --- error
Understood, but he mentioned translating C headers. D's 'typedef' has no
ready equivalent in C or C++.
Re: Containers I'd like to see in std.containers
On Mon, 31 May 2010 00:32:44 +0200, Simen kjaeraas simen.kja...@gmail.com wrote: Rainer Deyke rain...@eldwood.com wrote: Any container that supports pushing and popping on one end can be used as a stack. Any container that supports pushing on one end and popping on the other can be used as a queue. I don't think either of these need their own container type. There are other concerns than simply what works. First of all is readability - having containers called queue and stack makes code easier to understand, even if this is done with a simple alias. There might also be a concern about efficiency, as there is a difference in how fast different containers can push and pop. This strikes me as a reason to actually not provide such aliases. Even for stacks and queues, there are tradeoffs involved in the selection of containers. For instance, vectors and linked lists can both service for a stack implementation, but they have rather different performance and memory characteristics. Similarly for deques implemented with arrays or doubly-linked lists.
Re: dcollections 1.0 and 2.0a beta released
On Mon, 24 May 2010 11:01:06 -0400, Steven Schveighoffer schvei...@yahoo.com wrote: It's done all the time in Java and .NET. For example, A GUI listbox widget exposes its elements as an array of elements, which implement the List interface. You don't ever see the implementation or need it. Granted Java and .NET have less problems than C++ and D with binary compatibility, since the function tables are dynamic, but the potential is there for D to make binary compatibility possible with interfaces. Cocoa (NeXT's/Apple's framework for Objective-C) uses a very successful and well-thought-out delegation pattern, whereby GUI elements representing large amounts of data, like table views, have delegates (not in the D sense of the word) that provide them with the actual contents. Granted, Objective-C's runtime is much more dynamic than D, but a simplified version of such a pattern could still work in D. After all, user interfacing is typically where dynamism is more important than speed.
Re: Tango Phobos
On Sun, 02 May 2010 18:25:07 -0400, Jeff Nowakowski j...@dilacero.org wrote: On 05/02/2010 05:01 PM, Walter Bright wrote: Yes, this is the one and only time I did that. Maybe it was a really bad idea, and something we can point to in the future as why it shouldn't be done again. What do you think? I suppose you're asking you to the community, but anyways: Yes, it was a really bad idea. You should restore the posts of others without them having to opt-out of having their posts deleted. Yes, it is a good example of why it shouldn't be done again. Note that the post from Lars you deleted shed lots of light and no heat on the matter. The subject of moderation has been discussed many times. I believe open discussion and free speech is worth dealing with the occasional heated discussions. I don't see what changed in this instance to make you reverse your policy, except for your personal involvement. That wasn't the real Lars, nor his actual post. It was blatant trolling; just look at the name.
Re: metaprogramming question
On Mon, 19 Apr 2010 07:28:09 +0200, Philippe Sigaud
philippe.sig...@gmail.com wrote:
On Mon, Apr 19, 2010 at 05:21, Justin Spahr-Summers
justin.spahrsumm...@gmail.com wrote:
You can use some expression tuple magic to accomplish something like
that:
bool check(alias func, EL ...)() {
GError* err;
bool ok = func(EL, err);
if (!ok)
throw new Exception((*err).message);
return ok;
}
// used like:
check!(fooXXX, arg1, ..., argN);
But in this case, you need to know the ELs at compile-time. You can make
them run-time values that way:
bool check(alias func, EL ...)(EL el) {
GError* err;
bool ok = func(el, err);
if (!ok)
throw new Exception((*err).message);
return ok;
}
// used like:
check!fooXXX(arg1, ..., argN);
Yes, sorry. That's what I was trying to do originally, but I couldn't
quite spit it out. Indeed, templating the actual arguments is a horrible
idea.
Re: Patches, bottlenecks, OpenSource
On Thu, 15 Apr 2010 15:41:20 -0400, bearophile bearophileh...@lycos.com wrote: Don: And really, D doesn't need many people working on the DMD compiler. I agree, it's like having many people working around a dead corpse trying to revive it. Better use the time to adopt gcc and llvm back-ends at their best, keeping in mind, while designing D, that there are features that those back-ends have and the dmd back-end doesn't have that it will be good to add to the language. Simple example: refusing computed gotos because they are a lot of work to implement is not a justification that holds if both gcc and llvm already implement them and allow the front-end to just use them in a simple enough way. Bye, bearophile I like DMD, personally, and I've liked the benchmarks that I've seen of it (although lack of PowerPC support saddens me). GCC is a behemoth according to anyone who's ever done any work with it, and I like DMD's official status... even if LDC (for instance) were to become the official D compiler, the D compilation is so dependent on the LLVM system that it'd probably eventually run into issues like what Apple had with GCC not doing what they wanted; in Apple's case, they started a new project (clang, for those not familiar) so they could have solid control over the codebase. As far as computed gotos, I think Walter explains somewhere on the D website that D should be an easy language for compiler writers to implement. I don't know the relative implementation difficulty of computed gotos, but I think the rationale for minimizing features actually in the compiler itself is sound. Reduces feature creep and all that good stuff.
Re: Benchmarking in D
On Sun, 11 Apr 2010 10:27:58 +0200, Chris Mueller ruu...@googlemail.com wrote: Hi everyone, I would like to benchmark some of my D routines for performance testing and like to compare it with some alternative implementations in e.g. time and memory consumption. I'm not really experienced in this field and want to ask if someone can share his knowledge. Are there some tools providing by the operating system to look at the performance of a process? Are there any libraries in D that can help? Chris There's the benchmark() function in Phobos: http://www.digitalmars.com/d/2.0/phobos/std_date.html#benchmark Don't know if that's what you're really looking for, though.
Re: value range propagation for logical OR
On Sat, 10 Apr 2010 12:01:45 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Consider: byte c = a | b; Say you already know min_a, max_a, min_b, and max_b. How do you compute min_c and max_c? I thought of it for a bit and it seems quite tricky. Thanks, Andrei It seems like it would use the lowest minimum and the highest maximum of the two... that's what I personally would find most natural, given the semantics of bitwise OR, but maybe I'm just way off base.
Re: Confused about class equality
On Tue, 06 Apr 2010 23:35:01 -0400, strtr st...@spam.com wrote: Justin Spahr-Summers Wrote: Hmm, that is pretty weird. Are you doing any casts anywhere, or any pointer arithmetic/tricks? A search for cast didn't show any related casts. Do you maybe know another thing to check? I do throw references around and there are a lot of implicit casts to extended interfaces. Without actual explicit casting, I don't know how it'd be possible to invoke behavior like that. Maybe an object of class X getting implicitly converted to interface A and then explicitly cast to class Y? It'd have to be pretty convoluted.
Re: bstring
On Tue, 06 Apr 2010 11:50:36 -0700, Ali Çehreli acehr...@yahoo.com wrote: Justin Spahr-Summers wrote: 'string' to me represents a contiguous run of valid *characters* (i.e., the data has meaning and representation in and of itself)... not strictly enforced by D, of course, but that's how the type is used. If by character you mean code unit, yes. string characters are UTF-8 code units in D and have meanings by themselves only if they are one-byte UTF-8 sequences. Ali Sorry, yes. I'm not very familiar with Unicode terminology, but I do know that strings don't always contain valid Unicode sequences, and that's what I meant.
Re: Confused about class equality
On Tue, 06 Apr 2010 22:41:43 -0400, strtr st...@spam.com wrote:
Justin Spahr-Summers Wrote:
I think he said that he has two distinct object references, but the
value stored in the object(s) changes by changing either one.
In other words, we'd need to see the code.
I've added this exact sequence:
if( c1 !is null )
{
c1.value = 1;
if( c2 !is null )
{
c2.value = 2;
if( c1 !is c2 )
{
c1.value = 3;
assert(c2.value == 2 );
}
c2.value = 0;
}
c1.value = 0;
}
To my understanding this should never fails, yet it does.
AssertError Failure
Hmm, that is pretty weird. Are you doing any casts anywhere, or any
pointer arithmetic/tricks?
The only thing that I can think of is that you might've somehow
unintentionally fooled the compiler/runtime by coercing some types
somewhere.
If not, it might comprise a valid bug report.
Re: bstring
On Mon, 5 Apr 2010 18:48:58 -0400, Michel Fortin michel.for...@michelf.com wrote: Lately I've been using the type immutable(ubyte)[] a lot to pass around binary data of various kinds. In a couple of places now, to save some typing, I'm using this alias: alias immutable(ubyte)[] bstring; Would that make a worthy addition to the other standard string formats defined in object.o? Or am I the only one who is using this type a lot? I use it quite a lot too, but I'm not sure if making it (effectively) a language keyword is the right approach. I mean, I use mutable byte strings probably just as often. The fact that ubytes are really just arbitrary data I think somewhat diminishes the usefulness of a keyword; to compare, 'string' to me represents a contiguous run of valid *characters* (i.e., the data has meaning and representation in and of itself)... not strictly enforced by D, of course, but that's how the type is used. Apologies if this came out rather disjointed.
Re: Comparing Two Type Tuples
On Mon, 5 Apr 2010 15:47:10 + (UTC), BCS n...@anon.com wrote:
Hello Justin Spahr-Summers,
On Mon, 5 Apr 2010 02:59:15 + (UTC), BCS n...@anon.com wrote:
Hello Daniel,
Heya ppl!
I was wondering how could I write a function that takes two Type
Tuples as arguments and returns true if they are match.
Could anyone help me with this?
Thanks!
here is my untested vertion:
template Compare(T...)
{
template With(U...)
{
static if(T.length != U.lenght) const bool With = false;
else static if(T.length == 0) const bool With = true;
else static if(is(T[0] == U[0])) const bool With =
Compare!(T[1..$]).With!(U[1..$]);
else const bool With = false;
}
}
use like: Compare!(int, float, myStruct).With(alias1,alias2,typeArg)
Definitely a lot cleaner. I'm curious, though... is there a reason to
avoid is(T == U)?
I dind't know it worked?
It seemed to when I tested the snippet that I sent, but it might've just
been luck of the draw, and in reality fail silently on certain edge
cases. I'm really not sure.
Re: Comparing Two Type Tuples
On Sun, 4 Apr 2010 21:05:49 + (UTC), Daniel Ribeiro Maciel
danielmac...@gmail.com wrote:
Heya ppl!
I was wondering how could I write a function that takes two Type
Tuples as arguments and returns true if they are match.
Could anyone help me with this?
Thanks!
You can really only pass a single type tuple to a template, but you can
work around it by passing a length and then comparing two parts of a
combined tuple. For instance:
import std.stdio;
import std.typetuple;
void compare(uint LEN, TL ...) () {
writefln(%s, is(TL[0 .. LEN] == TL[LEN .. $]));
}
void main() {
alias TypeTuple!(int, double, char[]) tupleA;
alias TypeTuple!(int, double, char[]) tupleB;
alias TypeTuple!(int, double, char*) tupleC;
compare!(tupleA.length, tupleA, tupleB);
compare!(tupleA.length, tupleA, tupleC);
}
will output true then false.
Re: @pinned classes
On Thu, 01 Apr 2010 05:27:55 -0400, bearophile
bearophileh...@lycos.com wrote:
Justin Spahr-Summers:
I think the D2 spec puts restrictions on what you can do with GC-
allocated pointers (can't convert them to integers, can't perform
arithmetic on them outside of their bounds, etc.), and I think they're
restrictive enough that a copying garbage collector could work with no
changes to compliant code.
Without annotations here the compiler has to find by itself that instances of
this class is harder to move:
import std.c.stdio: printf;
class Foo {
int x;
int* ptrx;
this(int xx) {
this.x = xx;
this.ptrx = (this.x);
}
}
void main() {
auto f = new Foo(10);
printf(%d %d\n, f.x, *f.ptrx);
auto p = f.ptrx;
}
Bye,
bearophile
But shouldn't the GC know the size of Foo instances? It seems like it
should be able to rewrite any GC-managed pointers that point to 'f' or
anywhere inside it.
Re: @pinned classes
On Wed, 31 Mar 2010 22:59:08 -0400, bearophile
bearophileh...@lycos.com wrote:
Thinking more about some of the things I've recently written to Mike S, I
think the situation of the D GC can be improved not teaching the D type
system how to tell apart three types of pointers, but introducing the @pinned
for classes:
@pinned class Foo {}
Unpinned memory can be moved, allowing a generational moving GC, that's
efficient.
All objects instantiated from a unpinned class are unpinned. This is a little
limiting (you can think of allowing both pinned and unpinned instances) but
this keeps the situation simpler for the compiler and the programmer.
With unpinned classed Java/C# programmers can program in D in a style similar
to the one they are used too in their languages. This is good.
Classes are unpinned on default (the opposite of the current situation) to
maximize the amount of unpinned objects.
The @pinned attribute can't be used with structs and enums, they are always
pinned becasue Java programmers don't use them, they are usually used for
performance in a lower level way, and because they don't have a virtual table
pointer that the GC can use, etc.
Normal unpinned classes can't contain pointers to their fields or to unpinned
memory, in a transitive way. They can contain pointers to pinned memory.
In system (unsafe) modules you can of course cast a unpinned class referent
to a pointer, but this is nearly, because the GC can move the class in memory
in any moment. It can be useful for a short time if you disable the GC.
Pinned classes act as now, they can contain pointers to their fields too.
The GC can move around unpinned objects and must keep in place the pineed
ones, the GC has to modify the references to unpinned classes (references on
the stack, inside other objects, etc), to update them to their new positions.
Probably enums can't contain references to unpinned memory, to keep things
tidy.
This can be a compile error, prbably Bar too has to be unpinned:
class Foo {}
@pinned class Bar: Foo {}
I'm sure I'm forgetting several things :-)
Bye,
bearophile
I think the D2 spec puts restrictions on what you can do with GC-
allocated pointers (can't convert them to integers, can't perform
arithmetic on them outside of their bounds, etc.), and I think they're
restrictive enough that a copying garbage collector could work with no
changes to compliant code.
- Justin Spahr-Summers
