Re: [Issue 2472] New: Delegates are not lvalue.
> dmd output: > Error: &a.foo is not an lvalue Second bug on the same snippit of code, this error message lacks source file and line number info. I didn't try the code to see if it's just missing from the report or if dmd fails to include it.
[Issue 2473] New: Linux system install instructions incorrect
http://d.puremagic.com/issues/show_bug.cgi?id=2473 Summary: Linux system install instructions incorrect Product: D Version: 1.036 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: www.digitalmars.com AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The instructions here: http://www.digitalmars.com/d/2.0/dmd-linux.html Say that you can do a system-wide install of dmd with the following * copy dmd.conf to /etc/ * copy dmd to /usr/local/bin * copy *.a to /usr/local/lib However, if dmd.conf is in /etc, then dmd appears to search for files relative to /etc when encountering [EMAIL PROTECTED] rather than relative to the dmd binary. So the default [EMAIL PROTECTED]/../lib in dmd.conf needs to be changed to [EMAIL PROTECTED]/../usr/local/lib (or just -L-L/usr/local/lib). The path to the phobos src will also be wrong if dmd.conf is in /etc. The instructions should probably say for a system install to do a "cp -r dmd/src/phobos /usr/local/src" Then dmd.conf should say -I/usr/local/src/phobos Instructions-wise probably the easiest thing is just to tell users to put dmd.conf in /usr/local/bin instead of /etc. Then the paths in dmd.conf don't need to be changed (as long as you also copy src/phobos to /usr/local/src in addition to following the other instructions). If it's not acceptable to recommend putting dmd.conf in /usr/local/bin, then the next best thing would be to bundle a dmd.system.conf with correct system install paths, and instruct users to copy that one to /etc/dmd.conf instead of the regular dmd.conf, when doing a system-wide install. --
[Issue 2472] Delegates are not lvalue.
http://d.puremagic.com/issues/show_bug.cgi?id=2472 --- Comment #1 from [EMAIL PROTECTED] 2008-11-25 16:15 --- while this works well: auto dlg = &a.foo; auto f_ptr = dlg.funcptr; --
[Issue 2472] New: Delegates are not lvalue.
http://d.puremagic.com/issues/show_bug.cgi?id=2472
Summary: Delegates are not lvalue.
Product: D
Version: 1.036
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
class A
{
void foo()
{
}
}
int main()
{
auto a = new A;
auto x = (&a.foo).funcptr;
}
dmd output:
Error: &a.foo is not an lvalue
--
[Issue 1959] Internal error: eh.c 41
http://d.puremagic.com/issues/show_bug.cgi?id=1959 --- Comment #5 from [EMAIL PROTECTED] 2008-11-25 13:22 --- Ran into this on Linux with DMD 2.20. I'm working on isolating the piece of code that's the problem, but it's definitely still a problem. --
[Issue 1977] Relax warnings for implicit narrowing conversions caused by promotions
http://d.puremagic.com/issues/show_bug.cgi?id=1977 --- Comment #19 from [EMAIL PROTECTED] 2008-11-25 09:17 --- (In reply to comment #18) > > A better problem to spend energy on is the signed <-> unsigned morass. We've > > discussed that many times and could not come up with a reasonable solution. > > For > > now, D has borrowed the C rule "if any operand is unsigned then the result > > is > > unsigned" leading to the occasional puzzling results known from C and C++. > > Eliminating those fringe cases without losing compatibility with C and C++ > > is a > > tough challenge. > > Indeed. Without promoting to a larger type, I think you are forced to take > this course of action. When adding an int to a uint, who wants it to wrap > around to a negative value? I can't think of a better solution. > You just did in fact. Your idea with defining some internal types is very similar to one of the promising solutions we've been exploring for resolving signedness of arithmetic operations. I will in fact stop here and paste the rest of my message to the main newsgroup because it's of general interest and segues away from this bug report. --
[Issue 1977] Relax warnings for implicit narrowing conversions caused by promotions
http://d.puremagic.com/issues/show_bug.cgi?id=1977 --- Comment #18 from [EMAIL PROTECTED] 2008-11-25 09:02 --- (In reply to comment #17) > > And most believe that: > > > > byte b2 = b + b; > > > > should produce b2 == -128 without error, and should be equivalent > > semantically > > to: > > > > byte b2 = b; > > b2 += b; > > > > We don't want adding 2 bytes together to result in a byte result in all > > cases, > > only in cases where the actual assignment or usage is to a byte. > > Well the "most" part doesn't quite pan out, and to me it looks like the > argument fails here. For one thing, we need to eliminate people who accept > Java > and C#. They would believe that what their language does is the better thing > to > do. Just because people use a language, doesn't mean they agree with every decision. In searching for this issue on C# blogs and message boards, the overwhelming majority prefers no error to the oversafe current implementation. The defenders of the current rules invariably use the case of adding two bytes together and assigning to an integer, their argument being that if you have the result of adding two bytes be a byte, then the integer result is a truncated byte. If we eliminate that case from contention, as my solution has done, I think you'd be hard pressed to find anyone who thinks the loss of data errors are still needed in the cases such as the one that spawned this discussion. > Also, C and C++ are getting that right by paying a very large cost - of > allowing all narrowing integral conversions. I believe there is a reasonable > level of agreement that automatic lossy conversions are not to be encouraged. > This puts C and C++ behind Java and C# in terms of "getting it right". I agree, general narrowing conversions should be failed. It's just in the case of where arithmetic has artificially promoted the result where we disagree. > > > What if we defined several 'internal' types that were only used by the > > compiler? > > > > pbyte -> byte promoted to an int (represented as an int internally) > > pubyte -> ubyte promoted to an int > > pshort -> short promoted to an int > > pushort -> ushort promoted to an int > > etc... > > IMHO not enough rationale has been brought forth on why this *should* be > implemented. It would make D implement an arcane set of rules for an odd, if > any, benefit. Probably, it isn't that critical to the success of D that this be implemented. If I had to choose something to look at, this probably wouldn't be it. This is just one of those little things that seems unnecessary and annoying more than it is blocking. It shows up seldom enough that it probably isn't worth the trouble to fix. But I have put my solution forth, and as far as I can tell, you didn't find anything wrong with it, and that's about all I can do. > A better problem to spend energy on is the signed <-> unsigned morass. We've > discussed that many times and could not come up with a reasonable solution. > For > now, D has borrowed the C rule "if any operand is unsigned then the result is > unsigned" leading to the occasional puzzling results known from C and C++. > Eliminating those fringe cases without losing compatibility with C and C++ is > a > tough challenge. Indeed. Without promoting to a larger type, I think you are forced to take this course of action. When adding an int to a uint, who wants it to wrap around to a negative value? I can't think of a better solution. --
[Issue 1692] Abstract class dynamic creation bug
http://d.puremagic.com/issues/show_bug.cgi?id=1692 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #1 from [EMAIL PROTECTED] 2008-11-25 08:06 --- *** Bug 2453 has been marked as a duplicate of this bug. *** --
[Issue 2453] It is possible to create instances of abstract classes with ClassInfo.create
http://d.puremagic.com/issues/show_bug.cgi?id=2453 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from [EMAIL PROTECTED] 2008-11-25 08:06 --- *** This bug has been marked as a duplicate of 1692 *** --
[Issue 1768] CTFE: cant ~= an array literal to an unitinitialized array
http://d.puremagic.com/issues/show_bug.cgi?id=1768 --- Comment #8 from [EMAIL PROTECTED] 2008-11-25 06:48 --- For what it's worth, I can also confirm that this is fixed. --
[Issue 2293] access instance members from inside delegates
http://d.puremagic.com/issues/show_bug.cgi?id=2293 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #2 from [EMAIL PROTECTED] 2008-11-25 04:24 --- Works by design. In D1 nested delegates aren't closures and using them after enclosing function exits results in undefined behavior. this is accessed through frame pointer. --
