Re: Jumping on the bandwagon - DDCPU-16
My latest issue with Java is the trend to add annotations instead of keywords, like @Override, or the new type annotations like @NotNull and so on. Its slowly going to annotation hell. It was never clear for me why use annotations instead of proper keywords. Yes, annotations are supposed to be a kind of meta-language but, then, why to make those part of a language? If they are intended to be part of the language, they should be proper keywords, no more, no less.
Re: Growing pains
On Thursday, 3 May 2012 at 14:50:09 UTC, Andrei Alexandrescu wrote: Just letting you all know we're working on the frustrating and increasingly frequent Load at xx.xx, try again later errors when reading this forum through NNTP. They are caused by a significant growth spurt in newsgroup readership that occurred in recent times. We are working with our provider to fix these issues. Thanks, Andrei I don't know if someone was working on the NNTP server this morning, but it was really, really bad for a couple of minutes. I got XHR error and nothing else. Then it wen't back to normal.
Re: Return by 'ref' problems...
On 05/05/12 01:32, Manu wrote: On 4 May 2012 21:51, Artur Skawina art.08...@gmail.com mailto:art.08...@gmail.com wrote: On 05/04/12 15:57, Manu wrote: Yeah I really hate this too. I'd like to see const(T) strictly enforced, considering the potential for ambiguity in other situations. But I'm still stuck! :( How can I do what I need to do? If 'auto' is not an option: alias ref const(S) function() FT; FT fp; (it's needed for things like 'extern (C)' too) Huzzah! This is indeed the solution! I haven't seen another solution that works. now I just need to make sure I generate a unique name for the alias... I don't think this is needed for extern (C), I declare extern (C) function pointers all the time without any trick..? void f(extern (C) int function(double) a); artur
Re: Growing pains
On Saturday, 5 May 2012 at 06:04:51 UTC, SomeDude wrote: I don't know if someone was working on the NNTP server this morning, but it was really, really bad for a couple of minutes. I got XHR error and nothing else. Then it wen't back to normal. 20 mn later, it's slow again.
Re: Why typedef's shouldn't have been removed :(
And for those who couldn't care less about Windows, I should also note that it's impossible to distinguish between size_t and uint, etc. On Saturday, 5 May 2012 at 05:25:29 UTC, Maxim Fomin wrote: On Saturday, 5 May 2012 at 05:02:48 UTC, Mehrdad wrote: Now it's impossible to figure out whether a ParameterTypeTuple contains an HWND versus an HGDIOBJ or whatever... this should really be fixed... Features like this: typedef int type = 5; type var; var.init; // is 5 AFAIK are also lost.
Re: Why typedef's shouldn't have been removed :(
(Sorry that wasn't meant to be directed at you, I just happened to click reply on your post) On Saturday, 5 May 2012 at 05:25:29 UTC, Maxim Fomin wrote: On Saturday, 5 May 2012 at 05:02:48 UTC, Mehrdad wrote: Now it's impossible to figure out whether a ParameterTypeTuple contains an HWND versus an HGDIOBJ or whatever... this should really be fixed... Features like this: typedef int type = 5; type var; var.init; // is 5 AFAIK are also lost.
Re: GSOC Linker project
Am 04.05.2012 20:26, schrieb Steven Schveighoffer: On Fri, 04 May 2012 13:54:38 -0400, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 5/4/12, foobarf...@bar.com wrote: How about augmenting the object format so that libraries would be self contained and would not require additional .di files? Is this possible optlink by e.g. adding special sections that would be otherwise ignored? How would you use a library you don't even have the interface to? I mean if you can't even look at the API in your editor.. that'd be insane. Ever heard of Java? -Steve ever heard about Turbo Pascal (and delphi) got this feature since turbo pascal 4 around 1987 and turbo pascal and delphi are extremely fast native compilers without any Java, .Net magic
Re: Integer overflow and underflow semantics
On 05-05-2012 07:32, Era Scarecrow wrote: On Saturday, 5 May 2012 at 04:57:48 UTC, Alex Rønne Petersen wrote: Hi, I don't think the language really makes it clear whether overflows and underflows are well-defined. Do we guarantee that for any integral type T, T.max + 1 == T.min and T.min - 1 == T.max? This is relevant in particular for GDC and LDC since they target a lot of weird architectures. Any systems that implement a carry flag likely works exactly like that. Carry flag is set or cleared after a math operation, allowing you to extend the size of your integer any level you want, like in oh the 6502? Might look something like this: Been a while but you should get the idea clc ;clear carry loop_here: mov ax, [bx] adc [dx], ax inc bx inc dx dec cx cmp cx, 0 jne loop_here ;if carry after this point then... jc overflow_warning Right, but the question was whether the language guarantees what I described. C and C++ don't, and IMO, we should strive to fix that. -- - Alex
Re: GSOC Linker project
Am 05.05.2012 09:06, schrieb dennis luehring: Am 04.05.2012 20:26, schrieb Steven Schveighoffer: On Fri, 04 May 2012 13:54:38 -0400, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 5/4/12, foobarf...@bar.com wrote: How about augmenting the object format so that libraries would be self contained and would not require additional .di files? Is this possible optlink by e.g. adding special sections that would be otherwise ignored? How would you use a library you don't even have the interface to? I mean if you can't even look at the API in your editor.. that'd be insane. Ever heard of Java? -Steve ever heard about Turbo Pascal (and delphi) got this feature since turbo pascal 4 around 1987 and turbo pascal and delphi are extremely fast native compilers without any Java, .Net magic an more up-to-date example can be seen using the freepascal compiler and its ppdump tool: http://www.freepascal.org/tools/ppudump.var and turbo pascal gots even since 1987 a very good package system like a Java Jar file - you can just integrate compiled pascal sources (.pas - .tpu) into something called .tpl file (turbo pascal library) the freepascal compiler got something similar called .ppl these technologies are damn good and invented so long before - but sometimes totaly unknown to all the obj-file-linker-guys
Re: Integer overflow and underflow semantics
On Saturday, 5 May 2012 at 07:10:28 UTC, Alex Rønne Petersen wrote: Right, but the question was whether the language guarantees what I described. C and C++ don't, and IMO, we should strive to fix that. I can't see why it wouldn't, unless the compiler adds in checks and changes it's behavior or the assembler does it's own quirky magic. The bit patterns of how they end up are pretty fixed, it's just how we interpret them. I know before when i needed to know if it overflowed and simulated the carry flag, i ended up using a larger type of int. (This was for a custom multiple precision unsigned ints) Of course now that I think about it, if anything ends up using MMX for it's registers, the rules do change a little. MMX don't overflow if I remember right, they just cap/truncate to the Max/Min. Since it's intended more for multimedia... If the compiler uses those, I can't tell you what would happen.
Re: Integer overflow and underflow semantics
On 05-05-2012 10:23, Era Scarecrow wrote: On Saturday, 5 May 2012 at 07:10:28 UTC, Alex Rønne Petersen wrote: Right, but the question was whether the language guarantees what I described. C and C++ don't, and IMO, we should strive to fix that. I can't see why it wouldn't, unless the compiler adds in checks and changes it's behavior or the assembler does it's own quirky magic. The bit patterns of how they end up are pretty fixed, it's just how we interpret them. It all depends. GCC (and thus GDC) can target very exotic architectures where any assumptions may not, for whatever reason, hold true. This is a language design issue more than it's a how does architecture X or compiler Y work issue. An interesting problem with undefined behavior for integer overflow and underflow in C/C++ is that optimizers are basically free to do anything with regards to them, and often do whatever is more convenient for them. I know before when i needed to know if it overflowed and simulated the carry flag, i ended up using a larger type of int. (This was for a custom multiple precision unsigned ints) Of course now that I think about it, if anything ends up using MMX for it's registers, the rules do change a little. MMX don't overflow if I remember right, they just cap/truncate to the Max/Min. Since it's intended more for multimedia... If the compiler uses those, I can't tell you what would happen. Right, but it's not so much about what *would* happen as much as it is about what *should* happen. ;) -- - Alex
Re: GSOC Linker project
On 2012-05-05 00:39, H. S. Teoh wrote: It's often impossible to debug something if you don't get to see what the compiler sees. I suppose you could argue that leaving out function bodies and stuff amounts to the same thing, but at least the language's interface for a function is the function's signature. When you have a .di file, you're guaranteed that all public declarations are there, and you can see exactly what they are. Of course, IF ddoc can be guaranteed to produce exactly what's in a .di file, then I concede that it is sufficient this purpose. If the compiler can extract the .di files from an object file so can other tools. I don't see the problem. -- /Jacob Carlborg
Re: Return by 'ref' problems...
On 5 May 2012 09:09, Artur Skawina art.08...@gmail.com wrote:
On 05/05/12 01:32, Manu wrote:
On 4 May 2012 21:51, Artur Skawina art.08...@gmail.com mailto:
art.08...@gmail.com wrote:
On 05/04/12 15:57, Manu wrote:
Yeah I really hate this too. I'd like to see const(T) strictly
enforced, considering the potential for ambiguity in other situations.
But I'm still stuck! :(
How can I do what I need to do?
If 'auto' is not an option:
alias ref const(S) function() FT;
FT fp;
(it's needed for things like 'extern (C)' too)
Huzzah! This is indeed the solution! I haven't seen another solution
that works. now I just need to make sure I generate a unique name for the
alias...
I don't think this is needed for extern (C), I declare extern (C)
function pointers all the time without any trick..?
void f(extern (C) int function(double) a);
Hmm, actually, this makes me question my code...
struct Thing
{
extern (C) void function() funcPtr;
}
Have I declared a pointer to an extern(C) function, or have I declared an
extern(C) variable funcPtr that is a regular D-call function?
extern(C) variables only really make sense in the global scope, where they
would have C-style name mangling applied...
Re: Integer overflow and underflow semantics
On 5 May 2012 11:42, Alex Rønne Petersen xtzgzo...@gmail.com wrote:
On 05-05-2012 10:23, Era Scarecrow wrote:
On Saturday, 5 May 2012 at 07:10:28 UTC, Alex Rønne Petersen wrote:
Right, but the question was whether the language guarantees what I
described. C and C++ don't, and IMO, we should strive to fix that.
I can't see why it wouldn't, unless the compiler adds in checks and
changes it's behavior or the assembler does it's own quirky magic. The
bit patterns of how they end up are pretty fixed, it's just how we
interpret them.
It all depends. GCC (and thus GDC) can target very exotic architectures
where any assumptions may not, for whatever reason, hold true. This is a
language design issue more than it's a how does architecture X or compiler
Y work issue.
An interesting problem with undefined behavior for integer overflow and
underflow in C/C++ is that optimizers are basically free to do anything
with regards to them, and often do whatever is more convenient for them.
With regard to code-gen on such colourful architectures, would stating a
defined behaviour for overflow/underflow affect the common case where an
over/underflow did not occur?
Short of an architecture that causes hardware exception on over/underflow,
I suspect that it would interfere with the common case (additional code
generated around every add/sub/etc to handle the overflow behaviour), and
on such an architecture, every single numerical integer operation would
become inefficient.
I believe this is why C doesn't define the behaviour, because C is still
effectively a macro language, and shouldn't produce 'unexpected'
inefficient code. ('unexpected' from the perspective of the architecture
you're targeting)
I would personally rather see it remain undefined like C, but with
convention approved by common/conventional architectures where cross
platform porting is likely to occur.
Re: Integer overflow and underflow semantics
On 05-05-2012 12:25, Manu wrote:
On 5 May 2012 11:42, Alex Rønne Petersen xtzgzo...@gmail.com
mailto:xtzgzo...@gmail.com wrote:
On 05-05-2012 10 tel:05-05-2012%2010:23, Era Scarecrow wrote:
On Saturday, 5 May 2012 at 07:10:28 UTC, Alex Rønne Petersen wrote:
Right, but the question was whether the language guarantees
what I
described. C and C++ don't, and IMO, we should strive to fix
that.
I can't see why it wouldn't, unless the compiler adds in checks and
changes it's behavior or the assembler does it's own quirky
magic. The
bit patterns of how they end up are pretty fixed, it's just how we
interpret them.
It all depends. GCC (and thus GDC) can target very exotic
architectures where any assumptions may not, for whatever reason,
hold true. This is a language design issue more than it's a how
does architecture X or compiler Y work issue.
An interesting problem with undefined behavior for integer overflow
and underflow in C/C++ is that optimizers are basically free to do
anything with regards to them, and often do whatever is more
convenient for them.
With regard to code-gen on such colourful architectures, would stating a
defined behaviour for overflow/underflow affect the common case where an
over/underflow did not occur?
Short of an architecture that causes hardware exception on
over/underflow, I suspect that it would interfere with the common case
(additional code generated around every add/sub/etc to handle the
overflow behaviour), and on such an architecture, every single numerical
integer operation would become inefficient.
I don't know of a single architecture (out of the ones on
dlang.org/version.html and many others) that doesn't signal
overflow/underflow somehow (or obey the rules I described in the OP).
I believe this is why C doesn't define the behaviour, because C is still
effectively a macro language, and shouldn't produce 'unexpected'
inefficient code. ('unexpected' from the perspective of the architecture
you're targeting)
Right, but C was designed many, many years ago. :)
I would personally rather see it remain undefined like C, but with
convention approved by common/conventional architectures where cross
platform porting is likely to occur.
Do a grep for \.min and \.max in Phobos and you'll notice a lot of
places actually depend on the current x86 behavior (wrapping on overflow
and underflow). I don't think we can afford to make the same mistake C
and C++ did.
While I did say that this is a language design issue, it's also a matter
of pragmatism - does any real world architecture that D could possibly
target actually *not* obey the aforementioned rules? I don't know of any
that doesn't.
--
- Alex
Re: Integer overflow and underflow semantics
Alex Rønne Petersen: I don't think the language really makes it clear whether overflows and underflows are well-defined. Do we guarantee that for any integral type T, T.max + 1 == T.min and T.min - 1 == T.max? This is relevant in particular for GDC and LDC since they target a lot of weird architectures. In a good system language I'd like to see something better than what's present in C#. So I'd like the language to offer the programmer the choice of 3 or 4 different semantics in integral operations: 1) A shared standard semantics that overflows, as in Java; 2) A semantics that overflows, that adapts to the fastest available on the CPU, as in C; 3) Shared standard overflows with unsigned values and run-time errors when a signed value overflows (or goes out of its range). 4) Run-time errors when every signed or unsigned value overflows (or goes out of its range), as in Ada. Bye, bearophile
Re: Why typedef's shouldn't have been removed :(
Mehrdad: Now it's impossible to figure out whether a ParameterTypeTuple contains an HWND versus an HGDIOBJ or whatever... this should really be fixed... typedef is a quite useful feature, but the one present in D was unsound/broken, especially in presence of OOP. Fixing language features is hard (people didn't seem to understand that typedef is not meant to be used with classes), once their semantics is defined, it's quite hard to fix it. But adding features to D/Phobos is much simpler. So once there is a clear and sound design for what this feature has to do and its semantics, I expect to see in D a way to do the same things. Currently the Typedef in Phobos is more broken than the built-in typedef. Here the Ada language is a good reference to copy from. So the idea of removing typedef was good iff we eventually have something good to replace it. Bye, bearophile
Re: Integer overflow and underflow semantics
On 05-05-2012 13:06, bearophile wrote: Alex Rønne Petersen: I don't think the language really makes it clear whether overflows and underflows are well-defined. Do we guarantee that for any integral type T, T.max + 1 == T.min and T.min - 1 == T.max? This is relevant in particular for GDC and LDC since they target a lot of weird architectures. In a good system language I'd like to see something better than what's present in C#. So I'd like the language to offer the programmer the choice of 3 or 4 different semantics in integral operations: 1) A shared standard semantics that overflows, as in Java; 2) A semantics that overflows, that adapts to the fastest available on the CPU, as in C; 3) Shared standard overflows with unsigned values and run-time errors when a signed value overflows (or goes out of its range). 4) Run-time errors when every signed or unsigned value overflows (or goes out of its range), as in Ada. Bye, bearophile Good point. The wrapping rule described in my OP should be the default IMO. Then perhaps the other modes could be activated with an @attribute of sorts? -- - Alex
Static versus dynamic binding of in contracts again - trying to set things straight
http://d.puremagic.com/issues/show_bug.cgi?id=6857
It seems we can't all be agreed on how it should be.
It seems part of the problem is that there are two views on the essence of an in contract
in an OOP context:
(a) it is part of the API of the class and, as such, a specification to which any user of
the class must conform
(b) it is a means of verifying that the target object can handle the input being passed
into it
Current D takes view (b), by checking the in contract according to the actual class of the
object - dynamic binding. Several of us (myself included) have argued on the basis of
view (a), that it should be checked according to the compile-time type of the object
reference - static binding.
So far, there have been arguments both ways.
Arguments in favour of static binding:
s1. A user of a class A, in the general case, doesn't know whether something of type A is
a plain A or something of some subclass of A. This is part of the OO principle of
encapsulation. As such, it doesn't make sense for the class user to rely on the widened
preconditions in subclasses it doesn't know about. (But see d3.)
s2. As such, it helps detect more bugs in code that uses a class of which programmers are
likely to create subclasses.
s3. Obeys the Liskov substitution principle.
s4. Consistency with the inability of a base class user to call methods that exist only in
a derived class. If a subclass introduces a new method, that new method doesn't exist
from the base class's point of view. In the same way, if a subclass introduces new legal
arguments to a method, those new legal arguments don't exist from the base class's point
of view.
Arguments in favour of dynamic binding:
d1. It's part of how overriding is meant to work, per OO principles. A method call is
resolved through the virtual method table of the object's actual class. (But this is
based on the premise that an in contract is just another method. Which it isn't. An in
contract is a specification of what is a legal call of a method, quite a different concept
from the method itself, which provides functionality to the class.)
d2. Bertrand Meyer's book explains why this is the way in which it must work. (But the
truth of this claim has been challenged.)
d3. It allows inputs not allowed by the base class contract to be passed in under
controlled conditions - conditions in which some other method is defined from whose return
value the legality of some input can be determined. Example provided by Walter himself:
class A {
void foo(int x) in { assert(x 0); } body {}
int bar() { return 1; }
}
class B : A {
void foo(int x) in { assert(x -2); } body {}
int bar() { return -1; }
}
void fizzbuzz(A a) {
a.foo(bar());
}
(While I can see this being useful, it doesn't change the fact that fizzbuzz is asking the
class A, not the class B, for the method foo. And the A.foo contract could just as well
have been written
in { assert(x 0 || x == bar()); }
thereby causing the call to conform according to view (a) above, hence (d4 aside) enabling
static binding to be considered without this getting in the way.)
d4. Now that D behaves in this way, there is going to be code out there that does
something like the example in d3. Changing to static binding would break this code. (This
seems the one argument for dynamic binding that I'm inclined to agree with.)
deadalnix has pointed out that design of OOP doesn't say anything about contracts. In
which case any claim that the whole OOP paradigm takes either view (a) or view (b) is
nonsense.
Maybe what's needed is a clarification in the spec of which concept of an in contract
(view (a), view (b) or something else) D intends to implement.
If (a), then we need static binding. But how do we deal with the code breakage pointed
out in d4?
If (b), then we need to stick with the current dynamic binding. And people taking view
(a) will still complain about it. But a clear spec on the issue would at least be
something to which people complaining about (a) can be pointed.
Stewart.
Re: GSOC Linker project
On Friday, 4 May 2012 at 22:38:27 UTC, H. S. Teoh wrote: On Sat, May 05, 2012 at 12:07:16AM +0200, foobar wrote: On Friday, 4 May 2012 at 21:11:22 UTC, H. S. Teoh wrote: Exactly. And while we're at it, *really* strip unnecessary stuff from .di files, like function bodies, template bodies, etc.. That stuff is required by the compiler, not the user, so stick that in the object files and let the compiler deal with it. The .di file should be ONLY what's needed for the user to understand how to use the library. T You contradict yourself. The purpose of di files *is* to provide the compiler the required info to use the binary object/library. If you want human readable docs we already have DDoc (and other 3rd party tools) for that. If you don't like the default HTML output (I can't fathom why) you can easily define appropriate macros for other output types such as TeX (and PDF via external converter), text based, etc.. HTML is a stupid format, and ddoc output is not very navigable, but that's beside the point. I prefer to be reading actual code to be 100% sure that ddoc isn't leaving out some stuff that I should know about. All it takes is for somebody to leave out a doc comment and a particular declaration becomes invisible. (For example, std.uni was next to useless before I discovered that it actually had functions that I needed, but they didn't show up in dlang.org 'cos somebody failed to write doc comments for them.) I've seen too many commercial projects to believe for a moment that documentation is ever up-to-date. It depends on the library authors to provide ddoc output formats in a sane, usable format. Whereas if the compiler had a standardized, uniform, understandable format in well-known code syntax, that's a lot more dependable. It's often impossible to debug something if you don't get to see what the compiler sees. I suppose you could argue that leaving out function bodies and stuff amounts to the same thing, but at least the language's interface for a function is the function's signature. When you have a .di file, you're guaranteed that all public declarations are there, and you can see exactly what they are. Of course, IF ddoc can be guaranteed to produce exactly what's in a .di file, then I concede that it is sufficient this purpose. T This all amounts to the issues you have with the current implementation of DDoc which I agree needs more work. The solution then is to fix/enhance DDoc. Doxygen for instance has a setting to output all declarations whether documented or not, thus addressing your main point. The projects you speak of I assume are written in C/C++? Those tend to have poor documentation precisely because people assume the header files are enough. C/C++ requires you to install a 3rd party doc tool and learn that tool's doc syntax - effort that people are too lazy to invest. In the Java world the syntax is standardized, the tool comes bundled with the compiler, all tools speak it and IDEs will even insert empty doc comment for you automatically. Frankly it takes effort to *not* document your code in this setting. D provides DDoc precisely because it strives to provide the same doc friendly setting as Java.
Re: GSOC Linker project
Am 04.05.2012 19:54, schrieb Andrej Mitrovic: On 5/4/12, foobarf...@bar.com wrote: How about augmenting the object format so that libraries would be self contained and would not require additional .di files? Is this possible optlink by e.g. adding special sections that would be otherwise ignored? How would you use a library you don't even have the interface to? I mean if you can't even look at the API in your editor.. that'd be insane. Delphi does this since ages!
Re: Why typedef's shouldn't have been removed :(
On 2012-05-05 05:02:44 +, Mehrdad wfunct...@hotmail.com said:
Now it's impossible to figure out whether a ParameterTypeTuple contains
an HWND versus an HGDIOBJ or whatever...
this should really be fixed...
It should be fixed indeed. Perhaps HWND should be defined more like this:
struct HWND { void *handle; }
Or if you want it to implement some kind of inheritance scheme:
struct HANDLE { void *ptr; }
struct HWND { HANDLE handle; alias handle this; }
That's still a lot better than typedef since you can control what
operations are allowed on the type. For instance, you can't multiply
two handles with the struct definition, with typedef you could.
My only fear is that this might not work play well with the C calling
convention (or Window's in this case). If that's the case, then it's a
good argument for having a separate language construct.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Why typedef's shouldn't have been removed :(
mixin template TypeDef(Type, string name, Type init)
{
mixin(`struct `~name~` { public alias _impl this; private Type
_impl = init; };`);
}
unittest
{
mixin TypeDef!(int, `MyInt`, 5);
MyInt mi;
assert(typeid(myInt) != typeid(int));
assert(mi == 5);
}
On Sat, May 5, 2012 at 3:09 PM, bearophile bearophileh...@lycos.com wrote:
Mehrdad:
Now it's impossible to figure out whether a ParameterTypeTuple contains an
HWND versus an HGDIOBJ or whatever...
this should really be fixed...
typedef is a quite useful feature, but the one present in D was
unsound/broken, especially in presence of OOP. Fixing language features is
hard (people didn't seem to understand that typedef is not meant to be used
with classes), once their semantics is defined, it's quite hard to fix it.
But adding features to D/Phobos is much simpler. So once there is a clear
and sound design for what this feature has to do and its semantics, I expect
to see in D a way to do the same things. Currently the Typedef in Phobos is
more broken than the built-in typedef. Here the Ada language is a good
reference to copy from. So the idea of removing typedef was good iff we
eventually have something good to replace it.
Bye,
bearophile
--
Bye,
Gor Gyolchanyan.
Re: Static versus dynamic binding of in contracts again - trying to set things straight
Le 05/05/2012 14:46, Stewart Gordon a écrit :
d2. Bertrand Meyer's book explains why this is the way in which it must
work. (But the truth of this claim has been challenged.)
http://se.ethz.ch/~meyer/publications/computer/contract.pdf
The extract of the book covering that specific point is available here.
Meyer explain HOW thing work and then how this behavior provide some
benefices. Careful reading of the passage show that BOTH behavior we are
talking here provide such benefices. This reading isn't going to
conclude the discussion.
Additionally, Meyer state that the in contract is a constraint for the
caller. This is an argument in favor of view (a).
I do think EIFFEL implementation provide less benefices than the
proposed new behavior.
I plan to contact Meyer himself to discuss the subject.
d3. It allows inputs not allowed by the base class contract to be passed
in under controlled conditions - conditions in which some other method
is defined from whose return value the legality of some input can be
determined. Example provided by Walter himself:
class A {
void foo(int x) in { assert(x 0); } body {}
int bar() { return 1; }
}
class B : A {
void foo(int x) in { assert(x -2); } body {}
int bar() { return -1; }
}
void fizzbuzz(A a) {
a.foo(bar());
}
The fizzbuzz function here is flawed. bar doesn't provide any guarantee
on its return value. foo expect fizzbuzz to provide a parameter with
certain properties.
fizzbuzz is unable to ensure it is doing its part of the contract.
Correct alternative are either :
- adding an out contract on A.bar to ensure that the value returned is
above 0 and so can be safely passed to foo. This solution make B.bar
invalid, but fizzbuzz now is able to honor its part f the contract.
- adding a new condition to A.foo's in contract to accept bar's return
value. This also require that A.bar is made pure.
- fizzbuzz is rewritten to ensure that the value returned by bar is
valid according to foo's contract. The only contract that fizzbuzz knows
about is A.foo and so it should apply criteria on that one. It means
that B.bar's return valus will be discarded by fizzbuzz and it will not
call a.foo in case of a being an instance of B.
d4. Now that D behaves in this way, there is going to be code out there
that does something like the example in d3. Changing to static binding
would break this code. (This seems the one argument for dynamic binding
that I'm inclined to agree with.)
As seen above, cases where things risk to break is exactly what we want.
Contract is supposed to break bad code ASAP.
deadalnix has pointed out that design of OOP doesn't say anything about
contracts. In which case any claim that the whole OOP paradigm takes
either view (a) or view (b) is nonsense.
After some thinking, I want to make a stronger point.
A good guideline in OOP is to hide implementation. A contract is an
agreement between the caller and the callee, and so, mustn't be hidden
in any way. It certainly exclude the contract as being part of the
implementation.
view (b) imply that the in contract is part of the implementation (ie,
can the provided implementation handle that input or not). OOP don't say
anything about contracts, but view (b) is breaking encapsulation, and
encapsulation is an OOP principle.
Maybe what's needed is a clarification in the spec of which concept of
an in contract (view (a), view (b) or something else) D intends to
implement.
The spec is very explicit on that point. view (b) is the specified one.
But I think it is an error.
If (a), then we need static binding. But how do we deal with the code
breakage pointed out in d4?
Breaking flawed code is a benefit, not an issue.
Re: Static versus dynamic binding of in contracts again - trying to set things straight
On 05/05/2012 15:07, deadalnix wrote: snip http://se.ethz.ch/~meyer/publications/computer/contract.pdf The extract of the book covering that specific point is available here. Meyer explain HOW thing work and then how this behavior provide some benefices. Careful reading of the passage show that BOTH behavior we are talking here provide such benefices. This reading isn't going to conclude the discussion. Exactly. Moreover, I noticed that you quoted portions of it on BZ, including Yet, because of dynamic binding, A may subcontract the execution of r to B, and it is B’s contract that will be applied. There seems to be an unfounded assumption here: that a compiler will necessarily implement contract checking as part of the method body. Really, there's no explanation of it is B’s contract that will be applied there. Contract checking happens before and is conceptually separate from method execution. Additionally, Meyer state that the in contract is a constraint for the caller. This is an argument in favor of view (a). That is indeed what it seems to be saying. Among other things: A precondition violation indicates a bug in the client (caller). The caller did not observe the conditions imposed on correct calls. snip The fizzbuzz function here is flawed. bar doesn't provide any guarantee on its return value. foo expect fizzbuzz to provide a parameter with certain properties. Taken the words out of my mouth there. fizzbuzz is not using the class B. It is using the class A. Going by view (a), since foo(-1) is not a legal call according to A's API - and moreover, A's API makes no guarantees that foo(bar()) generally will be a legal call - the code is incorrect. I agree with the rest of your points as well. snip Maybe what's needed is a clarification in the spec of which concept of an in contract (view (a), view (b) or something else) D intends to implement. The spec is very explicit on that point. view (b) is the specified one. But I think it is an error. snip Where is it addressed? Stewart.
Re: Broken newsgroup threading (was: Re: An observation)
On Sat, May 05, 2012 at 01:00:40AM -0400, Jeff Nowakowski wrote: On 05/03/2012 06:07 AM, Tobias Pankrath wrote: Does the D newsgroup have broken threading in mutt? In my client threading breaks often because some answers starts new thread etc. makes the hole thing useless. The broken threading is caused by the Mailman newsgroup to mailing list gateway, as described in this post: http://forum.dlang.org/post/akftpzpkwuoqmfzij...@dfeed.kimsufi.thecybershadow.net Ahhh, that explains so much. Thanks for pointing this out! I was looking briefly at this issue recently, as it was getting annoying to follow the large threads in my newsreader, and it seems to me that the Mailman stance of changing the Message-ID is wrong. [...] I found two Mailman bug reports with patches regarding this issue: https://bugs.launchpad.net/mailman/+bug/266263 https://bugs.launchpad.net/mailman/+bug/496233 I may or may not follow up on this with the Mailman folks. If somebody else wants to feel free. Is there any chance we can apply these patches to the D forums? Or are we stuck with a default Mailman installation? T -- It always amuses me that Windows has a Safe Mode during bootup. Does that mean that Windows is normally unsafe?
Re: GSOC Linker project
On Fri, May 04, 2012 at 02:39:00PM -0700, Adam Wilson wrote: On Fri, 04 May 2012 14:12:16 -0700, H. S. Teoh hst...@quickfur.ath.cx wrote: [...] Exactly. And while we're at it, *really* strip unnecessary stuff from .di files, like function bodies, template bodies, etc.. That stuff is required by the compiler, not the user, so stick that in the object files and let the compiler deal with it. The .di file should be ONLY what's needed for the user to understand how to use the library. [...] I've written code to do this, but apparently it breaks Phobos in the autotester. I can't get it to break Phobos on my local machine so I'm at a loss as how to fix it. Maybe you can help? The code is here: https://github.com/LightBender/dmd.git [...] Sorry for taking so long to respond, been busy. Got some time this morning to cloned your repo and built dmd, then rebuilt druntime and phobos, and got this error from phobos: ../druntime/import/core/sys/posix/sys/select.di(25): function declaration without return type. (Note that constructors are always named 'this') ../druntime/import/core/sys/posix/sys/select.di(25): no identifier for declarator __FDELT(int d) ../druntime/import/core/sys/posix/sys/select.di(27): function declaration without return type. (Note that constructors are always named 'this') ../druntime/import/core/sys/posix/sys/select.di(27): no identifier for declarator __FDMASK(int d) make[1]: *** [generated/linux/release/32/libphobos2.a] Error 1 make: *** [release] Error 2 Looks like the bug only triggers when you rebuild druntime before rebuilding phobos. Hope this helps. Let me know if you want me to test anything else. T -- Freedom: (n.) Man's self-given right to be enslaved by his own depravity.
What should array() return for const/immutable ElementTypes?
The title says it all – currently, std.array.array() is broken for (some) ranges of const/immutable elements. Fixing it is not hard, but the question is: Should it always return an array of (head-)mutable elements (since it allocates a copy anyway), or should it preserve constness of the element type? The latter is maybe be the more »consistent« behavior, as the return type would always just be ElementType!Range[], but has the disadvantage that if you actually wanted to construct a mutable array from an immutable range, you'd have to cast away immutable (with unclear semantics), whereas getting an immutable array with the first implementation would just require assumeUnique() (for most ranges, array() is not going to be strongly pure). I have a fix ready, but will hold back the pull request until it is clear which semantics we want. Thanks, David
Re: GSOC Linker project
On Sat, May 05, 2012 at 09:51:40AM -0700, H. S. Teoh wrote:
On Fri, May 04, 2012 at 02:39:00PM -0700, Adam Wilson wrote:
On Fri, 04 May 2012 14:12:16 -0700, H. S. Teoh
hst...@quickfur.ath.cx wrote:
[...]
Exactly. And while we're at it, *really* strip unnecessary stuff from
.di files, like function bodies, template bodies, etc.. That stuff is
required by the compiler, not the user, so stick that in the object
files and let the compiler deal with it. The .di file should be ONLY
what's needed for the user to understand how to use the library.
[...]
I've written code to do this, but apparently it breaks Phobos in the
autotester. I can't get it to break Phobos on my local machine so I'm
at a loss as how to fix it. Maybe you can help? The code is here:
https://github.com/LightBender/dmd.git
[...]
Sorry for taking so long to respond, been busy. Got some time this
morning to cloned your repo and built dmd, then rebuilt druntime and
phobos, and got this error from phobos:
../druntime/import/core/sys/posix/sys/select.di(25): function declaration
without return type. (Note that constructors are always named 'this')
../druntime/import/core/sys/posix/sys/select.di(25): no identifier for
declarator __FDELT(int d)
../druntime/import/core/sys/posix/sys/select.di(27): function declaration
without return type. (Note that constructors are always named 'this')
../druntime/import/core/sys/posix/sys/select.di(27): no identifier for
declarator __FDMASK(int d)
make[1]: *** [generated/linux/release/32/libphobos2.a] Error 1
make: *** [release] Error 2
[...]
Oh, and here's the snippet from the offending file
(core/sys/posix/sys/select.di):
--SNIP--
private
{
alias c_long __fd_mask;
enum uint __NFDBITS = 8 * __fd_mask.sizeof;
extern (D) auto __FDELT(int d); // this is line
25
extern (D) auto __FDMASK(int d);// this is line
27
}
--SNIP--
Looks like the problem is caused by the auto, perhaps?
T
--
Lottery: tax on the stupid. -- Slashdotter
[Feature Request] Adding to D lang set built-in
Dear, i hope i will got some answer from druntime/phobos dev . A set is an array of unique element: set( 1, 5, 7, 1, 7) give this array = [1, 5, 7] Currently in D the hack it is to use an associative array with any value. byte[size_t] a = [ 1:0, 5:0, 7:0, 1:0, 7:0 ]; then it is easy to have a set in D just add a syntax or a built-in where use associative array without using value. I hope really this little feature and seem really easy to add thanks a lot for your great works
Re: [Feature Request] Adding to D lang set built-in
I think a much more realistic suggestion would be to add it to phobos as a struct, which wraps this no-value AA solution. On Sat, May 5, 2012 at 9:14 PM, bioinfornatics bioinfornat...@fedoraproject.org wrote: Dear, i hope i will got some answer from druntime/phobos dev . A set is an array of unique element: set( 1, 5, 7, 1, 7) give this array = [1, 5, 7] Currently in D the hack it is to use an associative array with any value. byte[size_t] a = [ 1:0, 5:0, 7:0, 1:0, 7:0 ]; then it is easy to have a set in D just add a syntax or a built-in where use associative array without using value. I hope really this little feature and seem really easy to add thanks a lot for your great works -- Bye, Gor Gyolchanyan.
Re: What should array() return for const/immutable ElementTypes?
David Nadlinger: Should it always return an array of (head-)mutable elements (since it allocates a copy anyway), or should it preserve constness of the element type? Ideally the most useful result is a mutable one that is implicitly castable to immutable if the mapping function is pure. But I don't know if this is always possible. Bye, bearophile
Re: [Feature Request] Adding to D lang set built-in
There's a few ways to implement your own Sets right now, if needed. You found one way (using the built in AAs), but that's not all. * You could use Array!bool (which efficiently stores bools) to store whether integers are in or out of your set. * You can use std.container's redBlackTree to make a set which would work better if your items are objects or you're dealing with a sparse array. There's probably a few other extremely simple methods, but those are the two I had on the top of my head. I'm not really sure having a particular Set in the library would be all that useful. Generally, if I want a set, I have a particular idea of how one should be implemented for my particular data.
Re: Why typedef's shouldn't have been removed :(
How do you fix it for size_t and uint, etc.?
On Saturday, 5 May 2012 at 13:01:08 UTC, Michel Fortin wrote:
On 2012-05-05 05:02:44 +, Mehrdad wfunct...@hotmail.com
said:
Now it's impossible to figure out whether a ParameterTypeTuple
contains an HWND versus an HGDIOBJ or whatever...
this should really be fixed...
It should be fixed indeed. Perhaps HWND should be defined more
like this:
struct HWND { void *handle; }
Or if you want it to implement some kind of inheritance scheme:
struct HANDLE { void *ptr; }
struct HWND { HANDLE handle; alias handle this; }
That's still a lot better than typedef since you can control
what operations are allowed on the type. For instance, you
can't multiply two handles with the struct definition, with
typedef you could.
My only fear is that this might not work play well with the C
calling convention (or Window's in this case). If that's the
case, then it's a good argument for having a separate language
construct.
Re: Why typedef's shouldn't have been removed :(
See my version.
On Sat, May 5, 2012 at 10:20 PM, Mehrdad wfunct...@hotmail.com wrote:
How do you fix it for size_t and uint, etc.?
On Saturday, 5 May 2012 at 13:01:08 UTC, Michel Fortin wrote:
On 2012-05-05 05:02:44 +, Mehrdad wfunct...@hotmail.com said:
Now it's impossible to figure out whether a ParameterTypeTuple contains
an HWND versus an HGDIOBJ or whatever...
this should really be fixed...
It should be fixed indeed. Perhaps HWND should be defined more like this:
struct HWND { void *handle; }
Or if you want it to implement some kind of inheritance scheme:
struct HANDLE { void *ptr; }
struct HWND { HANDLE handle; alias handle this; }
That's still a lot better than typedef since you can control what
operations are allowed on the type. For instance, you can't multiply two
handles with the struct definition, with typedef you could.
My only fear is that this might not work play well with the C calling
convention (or Window's in this case). If that's the case, then it's a good
argument for having a separate language construct.
--
Bye,
Gor Gyolchanyan.
Re: Why typedef's shouldn't have been removed :(
The one with TypeDef? That's not how it's defined though. On Saturday, 5 May 2012 at 18:31:44 UTC, Gor Gyolchanyan wrote: See my version.
Re: Why typedef's shouldn't have been removed :(
The effect is the same. You have a new type with a new init, that behaves the same way. On Sat, May 5, 2012 at 10:38 PM, Mehrdad wfunct...@hotmail.com wrote: The one with TypeDef? That's not how it's defined though. On Saturday, 5 May 2012 at 18:31:44 UTC, Gor Gyolchanyan wrote: See my version. -- Bye, Gor Gyolchanyan.
Re: What should array() return for const/immutable ElementTypes?
On Saturday, 5 May 2012 at 17:48:34 UTC, bearophile wrote:
Ideally the most useful result is a mutable one that is
implicitly castable to immutable if the mapping function is
pure. But I don't know if this is always possible.
Implicit conversion to immutable would only work if array() is
strongly pure, but this would require the passed in range type to
have no non-immutable indirections (besides needing a pure
implementation of array(), which is currently not the case due to
appender, but this can be fixed). OTOH, I think it _could_ work
for ranges operating on originally immutable data, but it seems
like it doesn't typecheck in today's DMD/Phobos:
———
auto array(Range)(Range r)
if (isIterable!Range !isNarrowString!Range)
{
alias Unqual!(ForeachType!Range) E;
E[] result;
foreach (e; r) result ~= e;
return result;
}
void main() {
immutable x = [1, 2, 3];
immutable y = array(filter!a == 3(x));
}
———
David
Re: Why typedef's shouldn't have been removed :(
Er, the point is, there are functions ALREADY using size_t, and I need to figure out which parameters those are. On Saturday, 5 May 2012 at 18:42:05 UTC, Gor Gyolchanyan wrote: The effect is the same. You have a new type with a new init, that behaves the same way. On Sat, May 5, 2012 at 10:38 PM, Mehrdad wfunct...@hotmail.com wrote: The one with TypeDef? That's not how it's defined though. On Saturday, 5 May 2012 at 18:31:44 UTC, Gor Gyolchanyan wrote: See my version.
Re: Why typedef's shouldn't have been removed :(
well, there's no solution to it of the alias is in use, no matter what alternatives are. On Sat, May 5, 2012 at 10:43 PM, Mehrdad wfunct...@hotmail.com wrote: Er, the point is, there are functions ALREADY using size_t, and I need to figure out which parameters those are. On Saturday, 5 May 2012 at 18:42:05 UTC, Gor Gyolchanyan wrote: The effect is the same. You have a new type with a new init, that behaves the same way. On Sat, May 5, 2012 at 10:38 PM, Mehrdad wfunct...@hotmail.com wrote: The one with TypeDef? That's not how it's defined though. On Saturday, 5 May 2012 at 18:31:44 UTC, Gor Gyolchanyan wrote: See my version. -- Bye, Gor Gyolchanyan.
Re: True disposable objects (add Finalized! assertion)
On Fri, 04 May 2012 21:07:20 +0200, Steven Schveighoffer schvei...@yahoo.com wrote: On Fri, 04 May 2012 14:50:06 -0400, Simen Kjaeraas simen.kja...@gmail.com wrote: I believe the idea was that it'd blow up if you use it unwisely. clear might do that, but if you're unlucky, it'll 'work' just fine, giving you problems later. clear zeros out the vtable, so it's highly unlikely it just works. Final functions still work, as they don't need the vtable.
Re: Return by 'ref' problems...
On 05/05/12 12:10, Manu wrote:
On 5 May 2012 09:09, Artur Skawina art.08...@gmail.com
mailto:art.08...@gmail.com wrote:
On 05/05/12 01:32, Manu wrote:
On 4 May 2012 21:51, Artur Skawina art.08...@gmail.com
mailto:art.08...@gmail.com mailto:art.08...@gmail.com
mailto:art.08...@gmail.com wrote:
On 05/04/12 15:57, Manu wrote:
Yeah I really hate this too. I'd like to see const(T) strictly
enforced, considering the potential for ambiguity in other situations.
But I'm still stuck! :(
How can I do what I need to do?
If 'auto' is not an option:
alias ref const(S) function() FT;
FT fp;
(it's needed for things like 'extern (C)' too)
Huzzah! This is indeed the solution! I haven't seen another solution
that works. now I just need to make sure I generate a unique name for the
alias...
I don't think this is needed for extern (C), I declare extern (C)
function pointers all the time without any trick..?
void f(extern (C) int function(double) a);
The compiler won't directly accept void f(extern (C) int function(double) a)
when declaring
or defining the function, so the extra alias step is necessary, like in your
'ref' case.
Hmm, actually, this makes me question my code...
struct Thing
{
extern (C) void function() funcPtr;
}
Have I declared a pointer to an extern(C) function, or have I declared an
extern(C) variable funcPtr that is a regular D-call function?
extern(C) variables only really make sense in the global scope, where they
would have C-style name mangling applied...
alias extern (C) void function() F;
F f1;
extern (C) F f2;
'f1' is a D pointer a C function, 'f2' is a C pointer to C function (ie f2's
name isn't mangled).
extern (C) void function() f3;
f3 is a C pointer to C function (think 'extern (C) { void function() f3; }').
alias void function() DF;
extern (C) DF f4;
f4 is a C pointer to a D function.
I'd stick to the alias method for every case where the difference actually
matters...
artur
Re: Why typedef's shouldn't have been removed :(
On Saturday, 5 May 2012 at 18:43:41 UTC, Mehrdad wrote: Er, the point is, there are functions ALREADY using size_t, and I need to figure out which parameters those are. Out of curiosity, why would you need to know which parameters are size_t? True, size_t is either uint or ulong and you can't really know for sure if you have a uint or ulong and it was actually a size_t ... but why would you need to know?
Re: Why typedef's shouldn't have been removed :(
That's *such* a lame question...
Even if I _couldn't_ tell you a reason, that'd still be a lame
question, because the *entire point* of reflection is to access
type information information about the program... if for nothing
other than printing it out for the user.
But it's more than that: it's the same darn reason why you need
to distinguish between
void* and HWND -- it's an ERROR!
In other words, this must NOT compile!
auto call(F, T...)(F func, T args) { return func(args); }
void test(uint) { }
void main() { call!(typeof(test), size_t)(test, 1); }
If you're still asking why shouldn't it compile then you should
look up what type safety means.
On Saturday, 5 May 2012 at 21:24:50 UTC, Chris Cain wrote:
On Saturday, 5 May 2012 at 18:43:41 UTC, Mehrdad wrote:
Er, the point is, there are functions ALREADY using size_t,
and I need to figure out which parameters those are.
Out of curiosity, why would you need to know which parameters
are size_t? True, size_t is either uint or ulong and you can't
really know for sure if you have a uint or ulong and it was
actually a size_t ... but why would you need to know?
Re: Why typedef's shouldn't have been removed :(
On Saturday, 5 May 2012 at 23:41:52 UTC, Mehrdad wrote:
That's *such* a lame question...
Even if I _couldn't_ tell you a reason, that'd still be a lame
question, because the *entire point* of reflection is to access
type information information about the program... if for nothing
other than printing it out for the user.
But it's more than that: it's the same darn reason why you need
to distinguish between
void* and HWND -- it's an ERROR!
In other words, this must NOT compile!
auto call(F, T...)(F func, T args) { return func(args); }
void test(uint) { }
void main() { call!(typeof(test), size_t)(test, 1); }
If you're still asking why shouldn't it compile then you
should
look up what type safety means.
That doesn't compile on x86_64.
The point of size_t is to be the native word-sized integer for
the platform, and it does exactly that.
Re: nginx reverse proxy for vibe tutorial
On Friday, 4 May 2012 at 11:54:04 UTC, David wrote:
* using `try_files`, nginx complains that you can't use
proxy_pass
inside a named location (like `@vibe`), which means you can't
use
try_files to serve arbitrary static files, hence the massive
list of
extensions.
why not doing:
root /path/to/static
location / {
try_files $uri @app_proxy
}
location @app_proxy {
...
}
I tried that, nginx complained endlessly about it. I'm not sure
why and I would prefer to use that version.
Also, I need to make an adjustment to my configuration, the
$body_bytes_sent doesn't work the way I thought, so you actually
need to do
server {
...
proxy_set_body $request_body;
...
// Remove proxy_set_header Content-length... line
}
Re: Why typedef's shouldn't have been removed :(
On Saturday, May 05, 2012 20:43:40 Mehrdad wrote: Er, the point is, there are functions ALREADY using size_t, and I need to figure out which parameters those are. In what situation would it matter? If you're writing the code yourself, then you have access to the function and can see that it's a size_t, so any code that you write which interacts with it will then be written to use size_t. If you're using compile-time reflection, then you'll get uint or ulong, depending on the architecture, but then uint or ulong is what you _need_ for that architecture, so using uint or ulong at that point would be correct. As far as I can tell, the fact that it was originally a size_t would be irrelevant at that point. - Jonathan M Davis
Re: Why typedef's shouldn't have been removed :(
The point of size_t is to be the native word-sized integer for
the platform
Native word-sized integer is such a blurry term, but of course
you
wouldn't know this without understanding why C has a gazillion
native integer types... (hint: if you're trying to justify
these with today's x86 processors, you're already on the wrong
track)
The point of size_t is for it to be able to represent the size of
something. That's all.
The point of sizediff_t is for it to be able to represent the
difference between two size_t's. That's all.
The point of ptrdiff_t is for it to be able to represent the
difference between two pointers. That's all.
Those three need NOT be the same size on the same machine, and
they need NOT be the same as the fastest integers on any
platform.
That's the whole point of std.stdint, in case you hadn't heard of
it.
That doesn't compile on x86_64.
I can't tell if you're missing my point or what...
In case that was unclear:
* I'm saying that shouldn't compile on *ANY* platform.
What you're saying is like saying dchar[] function() should be
interchangeable with uint[] function() just because they're the
same data on the same
platform.
Or like saying class Bar { } and class Foo { } should be
interchangeable because there's no actual difference between them.
Or like saying HWND function() and HANDLE function() and
void* function() should be
interchangeable because they're all the same anyway.
Kind of silly IMO.
Re: Why typedef's shouldn't have been removed :(
I understand you're frustrated, but you don't need to be so
hostile. I agree with most of what you've said on this thread.
And just because I made a short comment doesn't mean I don't know
about std.stdint, sizediff_t, etc. My point was to say that
size_t is supposed to be the size of the architecture's word. I
said nothing about it being the fastest type or even whether it
was useful . I would be very interested if you have a better
solution for the integer typing/naming problem.
There definitely needs to be way to define a type that can't
implicitly cast to its base type. The problem is that the
original typedef did do implicit casting away, and that has
potential to cause confusion when porting from C or D1. I don't
see that as much of a problem, but others might.
On Sunday, 6 May 2012 at 02:25:54 UTC, Mehrdad wrote:
The point of size_t is to be the native word-sized integer for
the platform
Native word-sized integer is such a blurry term, but of course
you
wouldn't know this without understanding why C has a gazillion
native integer types... (hint: if you're trying to justify
these with today's x86 processors, you're already on the wrong
track)
The point of size_t is for it to be able to represent the size
of
something. That's all.
The point of sizediff_t is for it to be able to represent the
difference between two size_t's. That's all.
The point of ptrdiff_t is for it to be able to represent the
difference between two pointers. That's all.
Those three need NOT be the same size on the same machine, and
they need NOT be the same as the fastest integers on any
platform.
That's the whole point of std.stdint, in case you hadn't heard
of
it.
That doesn't compile on x86_64.
I can't tell if you're missing my point or what...
In case that was unclear:
* I'm saying that shouldn't compile on *ANY* platform.
What you're saying is like saying dchar[] function() should be
interchangeable with uint[] function() just because they're
the same data on the same
platform.
Or like saying class Bar { } and class Foo { } should be
interchangeable because there's no actual difference between
them.
Or like saying HWND function() and HANDLE function() and
void* function() should be
interchangeable because they're all the same anyway.
Kind of silly IMO.
Re: Why typedef's shouldn't have been removed :(
On Sunday, 6 May 2012 at 03:15:01 UTC, Matt Peterson wrote: I understand you're frustrated, but you don't need to be so hostile. You're completely right... I apologize about that, it was completely my fault. I've indeed been pretty frustrated at this typedef nonsense (and the like), since it's made something otherwise elegant become something very annoying and time-wasting. To @Chris Cain as well, my response there was rather hostile too -- my apologies about that as well. I agree with most of what you've said on this thread. And just because I made a short comment doesn't mean I don't know about std.stdint, sizediff_t, etc. My point was to say that size_t is supposed to be the size of the architecture's word. I said nothing about it being the fastest type or even whether it was useful . I would be very interested if you have a better solution for the integer typing/naming problem. Right, but what I was saying was that that *isn't* what it's meant to be! It's just a *size* type, not a *word* of any kind... (think about systems with interleaving pointers, for example, x86 with segmentation -- the notion of a word isn't so obvious anymore, when denoting sizes) There definitely needs to be way to define a type that can't implicitly cast to its base type. The problem is that the original typedef did do implicit casting away, and that has potential to cause confusion when porting from C or D1. I don't see that as much of a problem, but others might. Yeah, I still don't understand what the potential to cause confusion was. Was it *actually* causing a significant problem, or was it just a potential problem?
Re: Why typedef's shouldn't have been removed :(
On Sunday, 6 May 2012 at 03:28:32 UTC, Mehrdad wrote: Right, but what I was saying was that that *isn't* what it's meant to be! It's just a *size* type, not a *word* of any kind... (think about systems with interleaving pointers, for example, x86 with segmentation -- the notion of a word isn't so obvious anymore, when denoting sizes) Yeah, figuring out what to name something is always a challenge, and the huge variety and complexity of modern, and even not-so-modern processors doesn't help at all. There definitely needs to be way to define a type that can't implicitly cast to its base type. The problem is that the original typedef did do implicit casting away, and that has potential to cause confusion when porting from C or D1. I don't see that as much of a problem, but others might. Yeah, I still don't understand what the potential to cause confusion was. Was it *actually* causing a significant problem, or was it just a potential problem? The issue is if someone new to D2 is porting code from C or D1, they would get all kinds of weird errors caused by using typedef instead of D2's alias and trying to do math or expecting implicit casting to work. But D2 is a different language, with different syntax and semantics. Anyone expecting copied C to just work in D2 is expecting a miracle, but that's not to say we can't try to make it as easy as possible. IMO, alias is a much better name than typedef, which is quite generic because technically any struct, class, or even function declaration is defining a new type. But adding a new keyword is ugly, assuming you can think of a good one, so typedef is probably the best choice. The only other alternative is reusing existing keywords, but I can't even think of a good choice. Does any of static/const/immutable/etc. alias sound good to anyone?
Problem about multi-thread programming
Hello everyone! I'm learning D and trying to write some sample code in D. I wrote: http://codepad.org/K4xQOREZ It compiles well with dmd 2.0.59, but I got an error when running: object.Error: Access Violation Any one help? Thanks.
Re: Problem about multi-thread programming
What's in console?
Re: c C deimos
On Saturday, 5 May 2012 at 10:53:59 UTC, Alex Rønne Petersen wrote: Small was always the convention. Not sure why mysql uses a big letter. Huh? ZeroMQ, ncurses, systemd, libmediainfo, libev, liblzma, libevent, OpenSSL, libexif, libsndfile and portaudio all use a capital »C« as directory name – and if anything, this has been »the convention«, as Walter's initial OpenSSL repo also used this variant. Not that it would matter, though, the directory only serve the purpose of documenting which exact version of the C headers was used to create the translation… David
Re: Problem about multi-thread programming
On Saturday, 5 May 2012 at 09:28:34 UTC, Tongzhou Li wrote: On Saturday, 5 May 2012 at 09:16:04 UTC, Kagamin wrote: What's in console? object.Error: Access Violation Expected output: 12341234123 PS: Line 13 should be: write(Idx); By default, everything is TLS (thread local) ... so, cv[0] will be null in main even though another thread set it to something else. Adding __gshared in front of Condition[4] cv; on line 7 will make it not crash with the Access Violation. However, I highly recommend you read the concurrency chapter in the DPL book: http://www.informit.com/articles/article.aspx?p=1609144
Re: undefined reference - Derelict2
On Saturday, 5 May 2012 at 23:42:36 UTC, sergeiV wrote: After succesful building of the Derelict libraries using: 'make -flinux.mak DC=dmd', I am unable to compile the provided example code: http://svn.dsource.org/projects/derelict/branches/Derelict2/doc/index.html They look like linker problems to me. rdmd test.d -Iinclude/Derelict2/import/ test.o:(.data+0x10): undefined reference to `_D8derelict6openal2al12__ModuleInfoZ' test.o:(.data+0x18): undefined reference to `_D8derelict6opengl2gl12__ModuleInfoZ' test.o: In function `_Dmain': test.d:(.text._Dmain+0x3d): undefined reference to `_D8derelict6openal2al10DerelictALC8derelict6openal2al16DerelictALLoader' test.d:(.text._Dmain+0x61): undefined reference to `_D8derelict6opengl2gl10DerelictGLC8derelict6opengl2gl16DerelictGLLoader' collect2: ld returned 1 exit status --- errorlevel 1 gdc gave an different kind of error: include/Derelict2/import/derelict/util/compat.di:64: Error: identifier 'c_long' is not defined Using a makefile generated errors similar to those for (r)dmd. dmd 2.059 derelict2 630 Solved, missed -of: rdmd -Iinclude/Derelict2/import/ -Linclude/Derelict2/lib/libDerelictAL.a -Linclude/Derelict2/lib/libDerelictUtil.a -ofderelict_test test.d
Re: undefined reference - Derelict2
On Sunday, 6 May 2012 at 01:23:48 UTC, sergeiV wrote: On Saturday, 5 May 2012 at 23:42:36 UTC, sergeiV wrote: After succesful building of the Derelict libraries using: 'make -flinux.mak DC=dmd', I am unable to compile the provided example code: http://svn.dsource.org/projects/derelict/branches/Derelict2/doc/index.html They look like linker problems to me. rdmd test.d -Iinclude/Derelict2/import/ test.o:(.data+0x10): undefined reference to `_D8derelict6openal2al12__ModuleInfoZ' test.o:(.data+0x18): undefined reference to `_D8derelict6opengl2gl12__ModuleInfoZ' test.o: In function `_Dmain': test.d:(.text._Dmain+0x3d): undefined reference to `_D8derelict6openal2al10DerelictALC8derelict6openal2al16DerelictALLoader' test.d:(.text._Dmain+0x61): undefined reference to `_D8derelict6opengl2gl10DerelictGLC8derelict6opengl2gl16DerelictGLLoader' collect2: ld returned 1 exit status --- errorlevel 1 gdc gave an different kind of error: include/Derelict2/import/derelict/util/compat.di:64: Error: identifier 'c_long' is not defined Using a makefile generated errors similar to those for (r)dmd. dmd 2.059 derelict2 630 Solved, missed -of: rdmd -Iinclude/Derelict2/import/ -Linclude/Derelict2/lib/libDerelictAL.a -Linclude/Derelict2/lib/libDerelictUtil.a -ofderelict_test test.d This is ofcourse enough: rdmd -Iinclude/Derelict2/import/ -oftest test.d (rdmd -Iinclude/Derelict2/import/ test.d FAILS) Could anybody explain why an output file specification is necessary? Or is this a bug?
Re: Problem about multi-thread programming
On Saturday, 5 May 2012 at 17:03:00 UTC, Chris Cain wrote: On Saturday, 5 May 2012 at 09:28:34 UTC, Tongzhou Li wrote: On Saturday, 5 May 2012 at 09:16:04 UTC, Kagamin wrote: What's in console? object.Error: Access Violation Expected output: 12341234123 PS: Line 13 should be: write(Idx); By default, everything is TLS (thread local) ... so, cv[0] will be null in main even though another thread set it to something else. Adding __gshared in front of Condition[4] cv; on line 7 will make it not crash with the Access Violation. However, I highly recommend you read the concurrency chapter in the DPL book: http://www.informit.com/articles/article.aspx?p=1609144 Thanks. Now it works fine with gdc, but still prints nothing with dmd. It seems that cv[0].notify() on line 29 affects nothing at all when using dmd2 :(
[Issue 4583] PIC code not working: EBX register set incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=4583 --- Comment #8 from github-bugzi...@puremagic.com 2012-05-04 23:00:44 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/2a5385345c17a65f8280efab1674c23bde3df68e fix Issue 4583 - PIC code not working: EBX register set incorrectly -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6199] [GSoC] Postblit not called when returning a reference to a by-value function.
http://d.puremagic.com/issues/show_bug.cgi?id=6199 --- Comment #2 from SomeDude lovelyd...@mailmetrash.com 2012-05-04 23:01:01 PDT --- See also related issue 5737 and issue 8045 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4583] PIC code not working: EBX register set incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=4583 --- Comment #9 from github-bugzi...@puremagic.com 2012-05-04 23:01:16 PDT --- Commit pushed to phobos-1.x at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/df21e384a4207e6f888b5abed0f7b3298a2d0320 fix Issue 4583 - PIC code not working: EBX register set incorrectly -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4583] PIC code not working: EBX register set incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=4583 --- Comment #10 from github-bugzi...@puremagic.com 2012-05-04 23:02:33 PDT --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/39c0a6ec5e2d1ae412d5d60834feb8ab610b090e fix Issue 4583 - PIC code not working: EBX register set incorrectly -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4583] PIC code not working: EBX register set incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=4583 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4583] PIC code not working: EBX register set incorrectly
http://d.puremagic.com/issues/show_bug.cgi?id=4583 --- Comment #11 from github-bugzi...@puremagic.com 2012-05-04 23:02:48 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ca53f96c09be934c51b2ea1d91c277639181cfec fix Issue 4583 - PIC code not working: EBX register set incorrectly -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8045] Postblit should be called on function call initilalizer that returns ref
http://d.puremagic.com/issues/show_bug.cgi?id=8045 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Kenji Hara k.hara...@gmail.com 2012-05-04 23:30:37 PDT --- (In reply to comment #1) Isn't this a duplicate of issue 5737 and issue 6199 ? There are currently 12 open bugs concerning postblit. I suspect some are duplicates, but I'm not sure which. http://d.puremagic.com/issues/buglist.cgi?query_format=advancedchfield=resolutionshort_desc=Postblitchfieldvalue=FIXEDbug_severity=regressionbug_severity=blockerbug_severity=criticalbug_severity=majorbug_severity=normalbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDversion=D2short_desc_type=allwordssubstrcomponent=DMDcomponent=druntimecomponent=Phobosresolution=---product=D Thanks. You are right. I'll mark this as a dup of issue 5737. *** This issue has been marked as a duplicate of issue 5737 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5737] postblit not called for locals initialized from ref functions
http://d.puremagic.com/issues/show_bug.cgi?id=5737 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||k.hara...@gmail.com --- Comment #2 from Kenji Hara k.hara...@gmail.com 2012-05-04 23:30:37 PDT --- *** Issue 8045 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5737] postblit not called for locals initialized from ref functions
http://d.puremagic.com/issues/show_bug.cgi?id=5737 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, wrong-code Platform|Other |All OS/Version|Linux |All --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-05-04 23:31:21 PDT --- https://github.com/D-Programming-Language/dmd/pull/927 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6199] [GSoC] Postblit not called when returning a reference to a by-value function.
http://d.puremagic.com/issues/show_bug.cgi?id=6199 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, wrong-code OS/Version|Windows |All --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-05-04 23:32:00 PDT --- https://github.com/D-Programming-Language/dmd/pull/927 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8046] New: simd.d needs some documentation
http://d.puremagic.com/issues/show_bug.cgi?id=8046 Summary: simd.d needs some documentation Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: worksonmymach...@gmail.com --- Comment #0 from Sean Cavanaugh worksonmymach...@gmail.com 2012-05-05 00:16:11 PDT --- Several of the enums in core/simd.d are not named after real opcodes so translating documentation from the intel processor manual is a bit confusing. For example: LODSS and STOSS are really forms of MOVSS. Are the arguments switched for either of these vs the MOVSS? This needs to be noted. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8047] New: important opcodes missing from core/simd.d
http://d.puremagic.com/issues/show_bug.cgi?id=8047 Summary: important opcodes missing from core/simd.d Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: worksonmymach...@gmail.com --- Comment #0 from Sean Cavanaugh worksonmymach...@gmail.com 2012-05-05 00:31:58 PDT --- There are a number of opcodes that are missing, but some are far more critical than others, more or less listed here in order of most important first: missing store instructions (and some loads) STOSS STOSD STOAPS STOAPD STOD STOQ (there are a few others scattered in the enum table) movemask (critical for doing branching tests against simd registers): MOVMSKPD MOVMSKPS missing comparisons CMPPS CMPPD CMPSD CMPSS missing conversions CVTPS2PI CVTSD2SI CVTSI2SD CVTSI2SS CVTSS2SI CVTTPD2PI CVTTPS2PI CVTTSD2SI CVTTSS2SI -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2356] array literal as non static initializer generates horribly inefficient code.
http://d.puremagic.com/issues/show_bug.cgi?id=2356 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords|patch | --- Comment #10 from Kenji Hara k.hara...@gmail.com 2012-05-05 00:42:06 PDT --- Pull #375 was not sufficient, so removed 'patch' keyword. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: [Issue 6857] Precondition contract checks should be statically bound.
On Saturday, 5 May 2012 at 05:57:31 UTC, Don wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #46 from Don clugd...@yahoo.com.au 2012-05-04
22:58:38 PDT ---
(In reply to comment #45)
(In reply to comment #44)
But going by comment 26, there is no breakage of correct OOP
behaviour
involved. So how is this relevant?
This has already been covered. We're going in circles.
Walter, you haven't understood this at all. None of us have
claimed that the
program ever gets into a wrong state.
Let me try another way.
Given a module which consists of:
--
struct F {
void foo(int n) in { assert( n 0); } body {}
}
void xyzzy(F f)
{
f.foo(-1);
}
--
A theorem prover, or even a compiler that did basic range
checking for
preconditions, should raise an error at compile time. Not at
run time when it's
actually called with an F, but at compile time. Nothing
controversial there.
Now, change F from a struct to a class. We believe that the
code should still
fail to compile.
Why would one expect the same behavior after changing the struct
to a class? The call to foo in the case of struct is statically
bound. f.foo *cannot* be bound to any other function than the one
declared in F, so it is *always* safe for compiler/theorem prover
to statically check the precondition.
Classes are a different story because of dynamic binding. There
will be cases where compiler/theorem prover will be able to
determine the static type at compile time and detect the error
early. Otherwise, it is obvious that the precondition must be
checked on the dynamic type at run-time.
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #47 from Walter Bright bugzi...@digitalmars.com 2012-05-05 02:02:48 PDT --- (In reply to comment #46) Now, change F from a struct to a class. We believe that the code should still fail to compile. A theorem prover could not produce a compile time error, because it could not prove that f is actually an F, and not of a class derived from F. OOP is runtime polymorphism, not compile time. A struct type is fundamentally different from a class type. And lastly, your request is quite different from Example #1, which is asserting that the contract for A.foo() must always pass, even if it's calling B.foo(). I know I sound like a broken record, but please read Meyer's book. He shows how the behavior of contracts is a derived consequence from OOP principles. It is not a separate invention with separate rules. Hence it is not a matter of belief - it is a matter of proof. --- Comment #48 from Walter Bright bugzi...@digitalmars.com 2012-05-05 02:03:05 PDT --- (In reply to comment #46) Now, change F from a struct to a class. We believe that the code should still fail to compile. A theorem prover could not produce a compile time error, because it could not prove that f is actually an F, and not of a class derived from F. OOP is runtime polymorphism, not compile time. A struct type is fundamentally different from a class type. And lastly, your request is quite different from Example #1, which is asserting that the contract for A.foo() must always pass, even if it's calling B.foo(). I know I sound like a broken record, but please read Meyer's book. He shows how the behavior of contracts is a derived consequence from OOP principles. It is not a separate invention with separate rules. Hence it is not a matter of belief - it is a matter of proof. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #47 from Walter Bright bugzi...@digitalmars.com 2012-05-05 02:02:48 PDT --- (In reply to comment #46) Now, change F from a struct to a class. We believe that the code should still fail to compile. A theorem prover could not produce a compile time error, because it could not prove that f is actually an F, and not of a class derived from F. OOP is runtime polymorphism, not compile time. A struct type is fundamentally different from a class type. And lastly, your request is quite different from Example #1, which is asserting that the contract for A.foo() must always pass, even if it's calling B.foo(). I know I sound like a broken record, but please read Meyer's book. He shows how the behavior of contracts is a derived consequence from OOP principles. It is not a separate invention with separate rules. Hence it is not a matter of belief - it is a matter of proof. --- Comment #48 from Walter Bright bugzi...@digitalmars.com 2012-05-05 02:03:05 PDT --- (In reply to comment #46) Now, change F from a struct to a class. We believe that the code should still fail to compile. A theorem prover could not produce a compile time error, because it could not prove that f is actually an F, and not of a class derived from F. OOP is runtime polymorphism, not compile time. A struct type is fundamentally different from a class type. And lastly, your request is quite different from Example #1, which is asserting that the contract for A.foo() must always pass, even if it's calling B.foo(). I know I sound like a broken record, but please read Meyer's book. He shows how the behavior of contracts is a derived consequence from OOP principles. It is not a separate invention with separate rules. Hence it is not a matter of belief - it is a matter of proof. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: [Issue 6857] Precondition contract checks should be statically bound.
Please reply on bugzilla, replying here is most likely to be overlooked.
[Issue 2389] void* vs. object type overloading fails for null giving bad error message
http://d.puremagic.com/issues/show_bug.cgi?id=2389 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2012-05-05 02:27:38 PDT --- Now produces: foo.d(10): Error: function foo.C.opIndexAssign called with argument types: ((typeof(null),int)) matches both: foo.C.opIndexAssign(void* _param_0, int _param_1) and: foo.C.opIndexAssign(C _param_0, int _param_1) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #49 from Stewart Gordon s...@iname.com 2012-05-05 04:40:48 PDT --- (In reply to comment #47) (In reply to comment #46) Now, change F from a struct to a class. We believe that the code should still fail to compile. A theorem prover could not produce a compile time error, because it could not prove that f is actually an F, and not of a class derived from F. You have completely ignored the whole point of this request, which has been explained to you by four of us several times over. OOP is runtime polymorphism, not compile time. A struct type is fundamentally different from a class type. Runtime polymorphism is about overriding behaviour, not overriding legality. And lastly, your request is quite different from Example #1, which is asserting that the contract for A.foo() must always pass, even if it's calling B.foo(). What are you talking about? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #50 from deadalnix deadal...@gmail.com 2012-05-05 05:04:07 PDT ---
(In reply to comment #33)
(In reply to comment #32)
(In reply to comment #30)
fizzbuzz() clearly has a bug. It will fail if given an A which isn't
actually a
B.
Exactly. fizzbuzz is calling a method of A, not a method of B. As such, as
I've already said, it must conform to A's API, but it is failing to do so.
First off, if fizzbuzz() is passed an A, then it will (correctly) fail.
Where's
the bug in the contract design? Secondly, the -1 may not be a literal, it may
be a value computed from B, as in:
class A {
void foo(int x) in { assert(x 0); } body {}
int bar() { return 1; }
}
class B : A {
void foo(int x) in { assert(x -2); } body {}
int bar() { return -1; }
}
void fizzbuzz(A a) {
a.foo(bar());
}
So, clearly is NOT required that a.foo(arg) pass A.foo's contract.
The design of OOP and contracts is sound. Correct programs will pass, and
incorrect programs will fail. I don't see any corner cases otherwise.
This piece of code is good for an horror museum.
If bar is a valid argument for foo, then A should have the following definition
:
class A {
void foo(int x) in { assert(x 0); } body {}
int bar() out(result) { assert( result 0); } body { return 1; }
}
And, with such a definition, out contract would prevent B.bar to return -1 .
BTW, I found this PDF on Meyer's website :
se.ethz.ch/~meyer/publications/computer/contract.pdf . It seems that he decided
to publish the part of the book that is relevant to us online. I'm reading it
right now.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #51 from deadalnix deadal...@gmail.com 2012-05-05 06:22:21 PDT --- (In reply to comment #49) Runtime polymorphism is about overriding behaviour, not overriding legality. This is, indeed, the whole essence of the problem. (In reply to comment #48) And lastly, your request is quite different from Example #1, which is asserting that the contract for A.foo() must always pass, even if it's calling B.foo(). I'm afraid this explains why we are not getting anywhere in this discussion. The whole proposal is, and have always been that one. Read again example code I've posted and which check is performed in which case. I have read Mayer's document about contract and OOP, and I want to comment here the explanations given by Meyer himself. Quoted passage are from the book. Mayer have a very similar example to the one I gave above. You have classes A and B inheriting from A. A define a method r with an in contract, that B override. A variable u of type A is used in method X. You can map as this : r = foo, u = a and X = fizzbuzzA « To ascertain the properties of the call u.r, the author of X can only look at the contract for r in A. Yet, because of dynamic binding, A may subcontract the execution of r to B, and it is B’s contract that will be applied. » Here, Meyer is stating HOW thing work before it explain WHY. Hence, the whole stuff is to show how this specific implementation satisfy certain properties. Let see what are these properties and what is the situation with the new proposed behavior. « How do you avoid “fooling” X in the process? There are two ways B could violate its prime contractor’s promises: - B could make the precondition stronger, raising the risk that some calls that are correct from x’s viewpoint (they satisfy the original client obligations) will not be handled properly. » I omitted the second one as it is about out contract so off topic here. the constraint expressed here is respected by both current solution, and proposed solution. « None of this, then, is permitted. But the reverse changes are of course legitimate. A redeclaration may weaken the original’s precondition or it may strengthen the postcondition. » Again, both proposals allow this. « Redeclaration. for all the power it brings to software development. is not a way to turn a routine into something completely different. The new version must remain compatible with the original specification. although it may improve on it. The noted rules express this precisely. » Meyer is right. His rules express this. But proposed rules express this too. He then conclude « In this way. the new precondition is guaranteed to be weaker than or equal to the originals, and the new postcondition is guaranteed to be stronger than or equal to the originals. » Again according to Meyer's argumentation, both behavior are corrects. It appears (and I have read the chapter several times to make sure I'm not missing something) that Meyer's doesn't provide any argument about our special case here. I'm sorry, but this reading can't close the discussion. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #52 from Andrei Alexandrescu and...@metalanguage.com 2012-05-05 08:54:17 PDT --- (In reply to comment #51) I'm sorry, but this reading can't close the discussion. I think it does. The proposed behavior does not allow this: None of this, then, is permitted. But the reverse changes are of course legitimate. A redeclaration may weaken the original’s precondition or it may strengthen the postcondition. Changes of either kind mean that the subcon- tractor does a better job than the original contractor-which there is no reason to prohibit. Doing a better job is succeeding where the parent method would have failed its precondition. It all boils down to the fact that it's natural to have methods that can't work in the parent but do work in the child. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #53 from deadalnix deadal...@gmail.com 2012-05-05 08:58:21 PDT ---
(In reply to comment #52)
(In reply to comment #51)
I'm sorry, but this reading can't close the discussion.
I think it does. The proposed behavior does not allow this:
None of this, then, is permitted. But the reverse changes are of course
legitimate. A redeclaration may weaken the original’s precondition or it may
strengthen the postcondition. Changes of either kind mean that the subcon-
tractor does a better job than the original contractor-which there is no
reason
to prohibit.
And indeed, it is not prohibited.
Doing a better job is succeeding where the parent method would have failed its
precondition. It all boils down to the fact that it's natural to have methods
that can't work in the parent but do work in the child.
It is stated (quoting myself) that :
« fizzbuzzB(B b) {
b.foo(); // (A.foo OR B.foo)'s in contract is valid
} »
Which exactly the behavior you talk about.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8048] New: Missing head function in std.net.curl
http://d.puremagic.com/issues/show_bug.cgi?id=8048 Summary: Missing head function in std.net.curl Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: repeate...@gmail.com --- Comment #0 from Masahiro Nakagawa repeate...@gmail.com 2012-05-05 09:24:06 PDT --- std.net.curl provides get, post, del, options, trace and connect functions corresponding to HTTP method. Why does not provide head function? I want head function to create a network library. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 --- Comment #54 from Stewart Gordon s...@iname.com 2012-05-05 09:21:02 PDT --- (In reply to comment #52) Doing a better job is succeeding where the parent method would have failed its precondition. It all boils down to the fact that it's natural to have methods that can't work in the parent but do work in the child. And to take advantage of this, one would deal with the child directly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8036] Zero-length static array of structs with elaborate destructor as struct or class field is rejected
http://d.puremagic.com/issues/show_bug.cgi?id=8036 --- Comment #2 from github-bugzi...@puremagic.com 2012-05-05 13:37:02 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/785e7d608035d79ba5eafc812ae102e18d5fd53d fix Issue 8036 - Zero-length static array of structs with elaborate destructor as struct or class field is rejected https://github.com/D-Programming-Language/dmd/commit/9f807fb3c119f6ddeebd141c7b7eda53253a4716 Merge pull request #926 from 9rnsr/fix8036 Issue 8036 - Zero-length static array of structs with elaborate destructor as struct or class field is rejected -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7995] regression(2.059): D runtime initialization from C fails on OSX in 2.059, worked in 2.058
http://d.puremagic.com/issues/show_bug.cgi?id=7995 --- Comment #2 from Jacob Carlborg d...@me.com 2012-05-05 14:04:01 PDT --- Pull request: https://github.com/D-Programming-Language/druntime/pull/205 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6857] Precondition contract checks should be statically bound.
http://d.puremagic.com/issues/show_bug.cgi?id=6857 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | Severity|enhancement |normal --- Comment #55 from Walter Bright bugzi...@digitalmars.com 2012-05-05 17:27:24 PDT --- Mea culpa. I read Meyer's book again. Chapter 16.1 Cutting out the middleman pg. 575 says: A client of MATRIX must satisfy the original (stronger) precondition, and may only expect the original (weaker) postcondition; even if its request gets served dynamically by NEW_MATRIX it has no way of benefiting from the broader tolerance of inputs and tighter precision of results. To get this improved specification it must declare the matric to be of type NEW_MATRIX, thereby losing access to other implementations represented by descendants of MATRIX that are not also descendants of NEW_MATRIX. (MATRIX is the base class, NEW_MATRIX is the derived class.) So I'm reopening it as a normal bug. Unfortunately, I do not currently see a reasonable way of implementing this. Fortunately, as is it does not inhibit correct programs, it only accepts some invalid ones. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8051] New: alias member not accessible
http://d.puremagic.com/issues/show_bug.cgi?id=8051
Summary: alias member not accessible
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ellery-newco...@utulsa.edu
--- Comment #0 from Ellery Newcomer ellery-newco...@utulsa.edu 2012-05-05
18:48:23 PDT ---
but it should be. dmd 2.059.
the code:
struct s{
union A{
int i;
}
A a;
alias a.i i;
}
template FIELD_OFFSET(T, string field){
enum FIELD_OFFSET = cast(size_t) mixin((cast(T*)null). ~ field);
}
void main(){
pragma(msg, FIELD_OFFSET!(s,i));
}
the fireworks:
test.d(9): Error: struct test.s 'i' is not a member
test.d(9): Error: struct test.s member i is not accessible
test.d(9): Error: this for i needs to be type A not type s
test.d(12): Error: template instance test.FIELD_OFFSET!(s,i) error
instantiating
cast(ulong)(__error).i
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
