www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 0.121

reply "Walter" <newshound digitalmars.com> writes:
Focus is on fixing compiler issues, especially the bugs introduced with
0.120.

http://www.digitalmars.com/d/changelog.html
Apr 15 2005
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <d3pc4b$19cp$1 digitaldaemon.com>, Walter says...

Focus is on fixing compiler issues, especially the bugs introduced with
0.120.



Phobos already has a file "ti_delegate.d" with a class named "TypeInfo_D" in it,
while .121 defines a new class "TypeInfo_Delegate" in "object.d."  Is one of
these classes misnamed, or is one defunct?


Sean
Apr 15 2005
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
In article <d3pc4b$19cp$1 digitaldaemon.com>, Walter says...

Focus is on fixing compiler issues, especially the bugs introduced with
0.120.



Oops, and a related question.  Phobos already had a file called "ti_ptr.d" with
a class named "TypeInfo_P" in it.  This seems to conflict with the new
TypeInfo_Pointer.  Which one is defunct?


Sean
Apr 15 2005
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <d3pc4b$19cp$1 digitaldaemon.com>, Walter says...

Focus is on fixing compiler issues, especially the bugs introduced with
0.120.



Same with "ti_C.d" class name "TypeInfo_C" for "TypeInfo_Class."

I'm going to back off on moving to .121 for now.  I'm not sure what to update.


Sean
Apr 15 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:d3pk26$1fai$1 digitaldaemon.com...

 In article <d3pc4b$19cp$1 digitaldaemon.com>, Walter says...

Focus is on fixing compiler issues, especially the bugs introduced with
0.120.



 Same with "ti_C.d" class name "TypeInfo_C" for "TypeInfo_Class."



Replying to all your posts, yes, they are both needed.
Apr 15 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <d3pn80$1hu9$1 digitaldaemon.com>, Walter says...

"Sean Kelly" <sean f4.ca> wrote in message
news:d3pk26$1fai$1 digitaldaemon.com...

 In article <d3pc4b$19cp$1 digitaldaemon.com>, Walter says...

Focus is on fixing compiler issues, especially the bugs introduced with
0.120.



 Same with "ti_C.d" class name "TypeInfo_C" for "TypeInfo_Class."



Replying to all your posts, yes, they are both needed.



Thanks.  Are they both for the same type?  The implementation for these pairs of
classes seems almost identical in each case.


Sean
Apr 15 2005
parent "Walter" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:d3poe7$1im2$1 digitaldaemon.com...

 In article <d3pn80$1hu9$1 digitaldaemon.com>, Walter says...

"Sean Kelly" <sean f4.ca> wrote in message
news:d3pk26$1fai$1 digitaldaemon.com...

 In article <d3pc4b$19cp$1 digitaldaemon.com>, Walter says...

Focus is on fixing compiler issues, especially the bugs introduced













0.120.



 Same with "ti_C.d" class name "TypeInfo_C" for "TypeInfo_Class."



Replying to all your posts, yes, they are both needed.



 Thanks.  Are they both for the same type?  The implementation for these




 classes seems almost identical in each case.



One is generic, the other isn't. I'll probably try to merge the two.
Apr 15 2005
prev sibling next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d3pc4b$19cp$1 digitaldaemon.com...

 Focus is on fixing compiler issues, especially the bugs introduced with
 0.120.

 http://www.digitalmars.com/d/changelog.html



ah, you sneaky devil. You started messing with the Exception inheritence 
tree! Do you have plans for the rest? :-)
Apr 15 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d3psac$1kr7$1 digitaldaemon.com...

 ah, you sneaky devil. You started messing with the Exception inheritence
 tree! Do you have plans for the rest? :-)



Well, SysError really was embarassingly bad. I have no other plans on it at
the moment.
Apr 15 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d3q02q$1nad$1 digitaldaemon.com...

 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d3psac$1kr7$1 digitaldaemon.com...

 ah, you sneaky devil. You started messing with the Exception inheritence
 tree! Do you have plans for the rest? :-)



 Well, SysError really was embarassingly bad. I have no other plans on it 
 at
 the moment.



ok. I have a silly question about SysError, though. The code in dmd-120 had 
hard-coded strings that mapped the same input error codes to the same 
strings on all platforms. Like you say that won't work since the error codes 
aren't the same on different platforms. But why can't SysError on linux call 
strerror? The error codes fed to the function are platform-dependent and the 
resulting string is platform-dependent but the purpose of the function (map 
a platform-dependent error code to a platform-dependent string) is 
platform-independent. So off the top of my head I'd think a linux version 
using strerror would be ok.
Apr 15 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d3q1a9$1o1o$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:d3q02q$1nad$1 digitaldaemon.com...

 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d3psac$1kr7$1 digitaldaemon.com...

 ah, you sneaky devil. You started messing with the Exception










 tree! Do you have plans for the rest? :-)



 Well, SysError really was embarassingly bad. I have no other plans on it
 at
 the moment.



 ok. I have a silly question about SysError, though. The code in dmd-120




 hard-coded strings that mapped the same input error codes to the same
 strings on all platforms. Like you say that won't work since the error




 aren't the same on different platforms. But why can't SysError on linux




 strerror?



Because there's a C strerror on Windows, indexed by C errno, and those
errno's don't line up with the Windows getLastError values. There are two
independent errno systems on Windows. I didn't think the two should be
conflated together. Some RTL's try to merge the two by having the Windows
values negated, but that strikes me as a too-confusing kludge as well.


 The error codes fed to the function are platform-dependent and the
 resulting string is platform-dependent but the purpose of the function




 a platform-dependent error code to a platform-dependent string) is
 platform-independent. So off the top of my head I'd think a linux version
 using strerror would be ok.



Since the linux code generating a C errno value will likely be under a
version(linux) anyway, it is no problem to just have it call strerror()
directly (as I fixed the routines in Phobos to do).
Apr 15 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 Since the linux code generating a C errno value will likely be under a
 version(linux) anyway, it is no problem to just have it call strerror()
 directly (as I fixed the routines in Phobos to do).



Does strerror return a char[]? Presumably one has to write
char*s  = strerror(err);
char[] ds = s[0 .. strlen(s)];
which is annoying when the Windows side has a nice function that returns a 
char[].
Apr 15 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d3q5oa$1smg$1 digitaldaemon.com...

 Since the linux code generating a C errno value will likely be under a
 version(linux) anyway, it is no problem to just have it call strerror()
 directly (as I fixed the routines in Phobos to do).



 Does strerror return a char[]? Presumably one has to write
 char*s  = strerror(err);
 char[] ds = s[0 .. strlen(s)];
 which is annoying when the Windows side has a nice function that returns a
 char[].



Take a look at std.file.
Apr 15 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d3qiqi$2c3o$1 digitaldaemon.com...

 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d3q5oa$1smg$1 digitaldaemon.com...

 Since the linux code generating a C errno value will likely be under a
 version(linux) anyway, it is no problem to just have it call strerror()
 directly (as I fixed the routines in Phobos to do).



 Does strerror return a char[]? Presumably one has to write
 char*s  = strerror(err);
 char[] ds = s[0 .. strlen(s)];
 which is annoying when the Windows side has a nice function that returns 
 a
 char[].



 Take a look at std.file.



For purposes of discussion std.file basically looks like
version(Windows) {
  class FooException {
     ...10 lines of code or so ...
     this(char[] x,uint errno) {
      this(x,sysErrorString(errno));
      ...
    }
  }
  ... Windows code ...
} else version (linux) {
  class FooException {
     ...same 10 lines of code as above ...
     this(char[] x,uint errno) {
      char* s = strerror(errno);
      this(x,<stringify>(s));
      ...
    }
  }
  ... Linux code ...
}

Naturally I'd prefer not to duplicate the definition of FooException in the 
different versions and instead have one definition that calls a common 
errno->string function (eg sysErrorString). It's cleaner IMO. But it's your 
call...
Apr 16 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d3r0cv$2nfb$1 digitaldaemon.com...

 Naturally I'd prefer not to duplicate the definition of FooException in




 different versions and instead have one definition that calls a common
 errno->string function (eg sysErrorString). It's cleaner IMO. But it's




 call...



But there can't be a common errno->string function, as C errno and Windows
errno coexist, but are different.
Apr 16 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 16 Apr 2005 20:07:24 -0700, Walter <newshound digitalmars.com>  
wrote:

 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d3r0cv$2nfb$1 digitaldaemon.com...

 Naturally I'd prefer not to duplicate the definition of FooException in




 different versions and instead have one definition that calls a common
 errno->string function (eg sysErrorString). It's cleaner IMO. But it's




 call...



 But there can't be a common errno->string function, as C errno and  
 Windows errno coexist, but are different.



What do you mean by "Windows errno"? Are you referring to GetLastError()?

AFAIK calling strerror(errno) on any OS produces the correct error string.
Calling FormatMessage on GetLastError, or WSAGetLastError produces the  
correct error string.

Regan
Apr 16 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opspczbht823k2f5 nrage.netwin.co.nz...

 On Sat, 16 Apr 2005 20:07:24 -0700, Walter <newshound digitalmars.com>
 wrote:

 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d3r0cv$2nfb$1 digitaldaemon.com...

 Naturally I'd prefer not to duplicate the definition of FooException in




 different versions and instead have one definition that calls a common
 errno->string function (eg sysErrorString). It's cleaner IMO. But it's




 call...



 But there can't be a common errno->string function, as C errno and
 Windows errno coexist, but are different.



 What do you mean by "Windows errno"? Are you referring to GetLastError()?



That's right. You see, we're already confused about which error number we're
talking about. That's why they can't be the same function <g>.


 AFAIK calling strerror(errno) on any OS produces the correct error string.
 Calling FormatMessage on GetLastError, or WSAGetLastError produces the
 correct error string.

 Regan
Apr 17 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Sun, 17 Apr 2005 10:51:45 -0700, Walter <newshound digitalmars.com>  
wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opspczbht823k2f5 nrage.netwin.co.nz...

 On Sat, 16 Apr 2005 20:07:24 -0700, Walter <newshound digitalmars.com>
 wrote:

 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d3r0cv$2nfb$1 digitaldaemon.com...

 Naturally I'd prefer not to duplicate the definition of FooException  







 the

 different versions and instead have one definition that calls a  







 errno->string function (eg sysErrorString). It's cleaner IMO. But  







 your

 call...



 But there can't be a common errno->string function, as C errno and
 Windows errno coexist, but are different.



 What do you mean by "Windows errno"? Are you referring to  
 GetLastError()?



 That's right. You see, we're already confused about which error number  
 we're talking about. That's why they can't be the same function <g>.



I was asking for clarification because windows has "errno" and  
"GetLastError" and you used the former to describe the latter. Bad Walter.  
:)

Regan
Apr 17 2005
prev sibling next sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d3sk8r$qgo$1 digitaldaemon.com...

 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d3r0cv$2nfb$1 digitaldaemon.com...

 Naturally I'd prefer not to duplicate the definition of FooException in




 different versions and instead have one definition that calls a common
 errno->string function (eg sysErrorString). It's cleaner IMO. But it's




 call...



 But there can't be a common errno->string function, as C errno and Windows
 errno coexist, but are different.



By errno I mean errno on Linux and GetLastError on Windows.
Apr 16 2005
prev sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d3sk8r$qgo$1 digitaldaemon.com...

 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d3r0cv$2nfb$1 digitaldaemon.com...

 Naturally I'd prefer not to duplicate the definition of FooException in




 different versions and instead have one definition that calls a common
 errno->string function (eg sysErrorString). It's cleaner IMO. But it's




 call...



 But there can't be a common errno->string function, as C errno and Windows
 errno coexist, but are different.



I'm not sure what you mean by different. They have different errors and 
numbers and strings but the concept of mapping an error code to a string is 
independent of all that. More specifically, instead of std.file looking like

version(Windows) {
  class FileException {
     ...10 lines of code or so ...
     this(char[] x,uint errno) {
      this(x,sysErrorString(errno));
      ...
    }
  }
  ... Windows code ...
} else version (linux) {
  class FileException {
     ...same 10 lines of code as above ...
     this(char[] x,uint errno) {
      char* s = strerror(errno);
      this(x,<stringify>(s));
      ...
    }
  }
  ... Linux code ...
}

it should look like

  class FileException {
     ...10 lines of code or so ...
     this(char[] x,uint errno) {
      this(x,sysErrorString(errno));
      ...
    }
  }
 ... rest of std.file ...

and sysErrorString looks like

char[] sysErrorString(int errno) {
  version (Windows) {
    .. content of existing std.windows.syserror ...
  } else {
      char* s = strerror(errno);
      return <stringify>(s);
  }
}

It's just taking the exact same code you have and rearranging it to avoid 
code duplication. Everything else in std.file is exactly the same. The 
Windows code passes the result of GetLastError to the FileException ctor and 
the Linux version passes getErrno(); Why have every module that wants to use 
a system error copy and paste code? It's begging for the errno->string 
abstraction IMO.
Apr 17 2005
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
The only problem being that sysErrorString deals with GetLastError codes  
on windows and errno codes on linux, but not errno codes on Windows which  
do not map to GetLastError codes and are returned for other things.

I have a plan. Gimme a little time to write and post it.

Regan

On Sun, 17 Apr 2005 14:21:11 -0400, Ben Hinkle <ben.hinkle gmail.com>  
wrote:

 "Walter" <newshound digitalmars.com> wrote in message
 news:d3sk8r$qgo$1 digitaldaemon.com...

 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d3r0cv$2nfb$1 digitaldaemon.com...

 Naturally I'd prefer not to duplicate the definition of FooException in




 different versions and instead have one definition that calls a common
 errno->string function (eg sysErrorString). It's cleaner IMO. But it's




 call...



 But there can't be a common errno->string function, as C errno and  
 Windows
 errno coexist, but are different.



 I'm not sure what you mean by different. They have different errors and
 numbers and strings but the concept of mapping an error code to a string  
 is
 independent of all that. More specifically, instead of std.file looking  
 like

 version(Windows) {
   class FileException {
      ...10 lines of code or so ...
      this(char[] x,uint errno) {
       this(x,sysErrorString(errno));
       ...
     }
   }
   ... Windows code ...
 } else version (linux) {
   class FileException {
      ...same 10 lines of code as above ...
      this(char[] x,uint errno) {
       char* s = strerror(errno);
       this(x,<stringify>(s));
       ...
     }
   }
   ... Linux code ...
 }

 it should look like

   class FileException {
      ...10 lines of code or so ...
      this(char[] x,uint errno) {
       this(x,sysErrorString(errno));
       ...
     }
   }
  ... rest of std.file ...

 and sysErrorString looks like

 char[] sysErrorString(int errno) {
   version (Windows) {
     .. content of existing std.windows.syserror ...
   } else {
       char* s = strerror(errno);
       return <stringify>(s);
   }
 }

 It's just taking the exact same code you have and rearranging it to avoid
 code duplication. Everything else in std.file is exactly the same. The
 Windows code passes the result of GetLastError to the FileException ctor  
 and
 the Linux version passes getErrno(); Why have every module that wants to  
 use
 a system error copy and paste code? It's begging for the errno->string
 abstraction IMO.
Apr 17 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d3u9er$25ev$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:d3sk8r$qgo$1 digitaldaemon.com...

 But there can't be a common errno->string function, as C errno and







 errno coexist, but are different.



 I'm not sure what you mean by different. They have different errors and
 numbers and strings but the concept of mapping an error code to a string




 independent of all that.



What are you going to do with Windows code that calls C's read() function?
Apr 17 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d3up2a$2isn$1 digitaldaemon.com...

 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d3u9er$25ev$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:d3sk8r$qgo$1 digitaldaemon.com...

 But there can't be a common errno->string function, as C errno and







 errno coexist, but are different.



 I'm not sure what you mean by different. They have different errors and
 numbers and strings but the concept of mapping an error code to a string




 independent of all that.



 What are you going to do with Windows code that calls C's read() function?



Have users deal with it themselves. IMO each platform has a "natural" 
platform-specific set of error codes and a code->string mapping function. 
Everything else requires the user calling the right function by hand (which 
is no worse than what's in dmd-121). As long as sysErrorString documents 
what it does on each platform the only downside would be if someone doesn't 
know what error codes they have or if a system doesn't have any natural 
choice of codes or mapping (in which case one can say sysErrorString isn't 
supported on that platform).
Apr 18 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:d40u2o$1jho$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:d3up2a$2isn$1 digitaldaemon.com...

 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d3u9er$25ev$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:d3sk8r$qgo$1 digitaldaemon.com...

 But there can't be a common errno->string function, as C errno and







 errno coexist, but are different.



 I'm not sure what you mean by different. They have different errors and
 numbers and strings but the concept of mapping an error code to a










 is

 independent of all that.



 What are you going to do with Windows code that calls C's read()







 Have users deal with it themselves. IMO each platform has a "natural"
 platform-specific set of error codes and a code->string mapping function.
 Everything else requires the user calling the right function by hand




 is no worse than what's in dmd-121). As long as sysErrorString documents
 what it does on each platform the only downside would be if someone




 know what error codes they have or if a system doesn't have any natural
 choice of codes or mapping (in which case one can say sysErrorString isn't
 supported on that platform).



D is supposed to be able to interface directly with C. So on one platform
calling standard C routines, one will use errno and use sysErrorString.
Then, the *exact same code* on Windows will fail mysteriously at runtime.
Apr 19 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
 D is supposed to be able to interface directly with C. So on one platform
 calling standard C routines, one will use errno and use sysErrorString.
 Then, the *exact same code* on Windows will fail mysteriously at runtime.



True, though I would expect that if the user wants to just call standard C 
routines they should use strerror instead of sysErrorCode. Why would they 
switch and start using a non-C routine to handle their standard C error? 
It's debatable whether more bugs will be introduced due to code duplication 
(and the code rot it turns into) like FileException than by calling 
sysErrorString by accident. If you don't like putting the version switch in 
sysErrorString at least put it into FileException so that isn't so much 
copy/paste of code.
Apr 19 2005
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 15 Apr 2005 21:18:50 -0700, Walter <newshound digitalmars.com>  
wrote:

 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d3q1a9$1o1o$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message
 news:d3q02q$1nad$1 digitaldaemon.com...

 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d3psac$1kr7$1 digitaldaemon.com...

 ah, you sneaky devil. You started messing with the Exception










 tree! Do you have plans for the rest? :-)



 Well, SysError really was embarassingly bad. I have no other plans on  




 at
 the moment.



 ok. I have a silly question about SysError, though. The code in dmd-120




 hard-coded strings that mapped the same input error codes to the same
 strings on all platforms. Like you say that won't work since the error




 aren't the same on different platforms. But why can't SysError on linux




 strerror?



 Because there's a C strerror on Windows, indexed by C errno, and those
 errno's don't line up with the Windows getLastError values. There are two
 independent errno systems on Windows.



True, this is a pain.


 I didn't think the two should be
 conflated together. Some RTL's try to merge the two by having the Windows
 values negated, but that strikes me as a too-confusing kludge as well.



Why is it confusing?
People should never refer to the error codes by number, but rather by  
defined name eg.

ENOENT - No such file or directory
EEXIST - File exists

Also from MSDN docs on GetLastError... "Error codes are 32-bit values (bit  
31 is the most significant bit). Bit 29 is reserved for  
application-defined error codes; no system error code has this bit set. If  
you are defining an error code for your application, set this bit to one.  
That indicates that the error code has been defined by an application, and  
ensures that your error code does not conflict with any error codes  
defined by the system."

Assuming we decide not to merge them the soln appears to be to have a  
System(Error/Exception) to handle errno using strerror situations and  
Windows(Error/Exception) to handle GetLastError/WSAGetLastError using  
FormatMessage situations.

Regan
Apr 16 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 16 Apr 2005 21:51:22 +1200, Regan Heath <regan netwin.co.nz> wrote:

 Also from MSDN docs on GetLastError... "Error codes are 32-bit values  
 (bit 31 is the most significant bit). Bit 29 is reserved for  
 application-defined error codes; no system error code has this bit set.  
 If you are defining an error code for your application, set this bit to  
 one. That indicates that the error code has been defined by an  
 application, and ensures that your error code does not conflict with any  
 error codes defined by the system."



Sorry. Meant to say that we could use bit 29 for defining the errno  
values. The re-define the range for user defined errors for D.

Regan
Apr 16 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 16 Apr 2005 22:14:22 +1200, Regan Heath <regan netwin.co.nz> wrote:

 On Sat, 16 Apr 2005 21:51:22 +1200, Regan Heath <regan netwin.co.nz>  
 wrote:

 Also from MSDN docs on GetLastError... "Error codes are 32-bit values  
 (bit 31 is the most significant bit). Bit 29 is reserved for  
 application-defined error codes; no system error code has this bit set.  
 If you are defining an error code for your application, set this bit to  
 one. That indicates that the error code has been defined by an  
 application, and ensures that your error code does not conflict with  
 any error codes defined by the system."



 Sorry. Meant to say that we could use bit 29 for defining the errno  
 values. The re-define the range for user defined errors for D.



Having a really bad typing day.. "The re-define the range .." -> "Then  
re-define .."

Regan
Apr 16 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opspbkbwa523k2f5 nrage.netwin.co.nz...

 On Fri, 15 Apr 2005 21:18:50 -0700, Walter <newshound digitalmars.com>
 wrote:

 I didn't think the two should be
 conflated together. Some RTL's try to merge the two by having the







 values negated, but that strikes me as a too-confusing kludge as well.



 Why is it confusing?
 People should never refer to the error codes by number, but rather by
 defined name eg.

 ENOENT - No such file or directory
 EEXIST - File exists



Because then people have to remember that there are two different errno's in
the SysError, and that the negative ones are the negation of what Windows
documents them to be. Those programmers who need to know what the error
number is are probably not going to be too happy to find out they have to
negate it. It'll inevitably get negated the wrong number of times, and the
result will be irritating bugs.

Philosophically, I'm strongly opposed to fixing the operating system API. If
D does, then D has the onerous and impossible task of re-documenting the OS
interface (instead of just referring to the docs written by the OS vendor).
I'll agree that the Windows designers should have been accommodating with
the C errno and come up with a getLastErrno() that will coexist with it. But
they didn't, and so it is what it is.
Apr 16 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 16 Apr 2005 20:21:59 -0700, Walter <newshound digitalmars.com>  
wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opspbkbwa523k2f5 nrage.netwin.co.nz...

 On Fri, 15 Apr 2005 21:18:50 -0700, Walter <newshound digitalmars.com>
 wrote:

 I didn't think the two should be
 conflated together. Some RTL's try to merge the two by having the







 values negated, but that strikes me as a too-confusing kludge as well.



 Why is it confusing?
 People should never refer to the error codes by number, but rather by
 defined name eg.

 ENOENT - No such file or directory
 EEXIST - File exists



 Because then people have to remember that there are two different  
 errno's in
 the SysError, and that the negative ones are the negation of what Windows
 documents them to be. Those programmers who need to know what the error
 number is are probably not going to be too happy to find out they have to
 negate it. It'll inevitably get negated the wrong number of times, and  
 the
 result will be irritating bugs.

 Philosophically, I'm strongly opposed to fixing the operating system  
 API. If
 D does, then D has the onerous and impossible task of re-documenting the  
 OS
 interface (instead of just referring to the docs written by the OS  
 vendor).
 I'll agree that the Windows designers should have been accommodating with
 the C errno and come up with a getLastErrno() that will coexist with it.  
 But
 they didn't, and so it is what it is.



Ok, fair enough, how about if I write some code to show how I believe it  
can be done, and you comment on that.

Regan
Apr 16 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
------------2igF2tOYaIY9BeLfX8SOzm
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
Content-Transfer-Encoding: 8bit

On Sun, 17 Apr 2005 16:11:05 +1200, Regan Heath <regan netwin.co.nz> wrote:

 On Sat, 16 Apr 2005 20:21:59 -0700, Walter <newshound digitalmars.com>  
 wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opspbkbwa523k2f5 nrage.netwin.co.nz...

 On Fri, 15 Apr 2005 21:18:50 -0700, Walter <newshound digitalmars.com>
 wrote:

 I didn't think the two should be
 conflated together. Some RTL's try to merge the two by having the







 values negated, but that strikes me as a too-confusing kludge as  




 Why is it confusing?
 People should never refer to the error codes by number, but rather by
 defined name eg.

 ENOENT - No such file or directory
 EEXIST - File exists



 Because then people have to remember that there are two different  
 errno's in
 the SysError, and that the negative ones are the negation of what  
 Windows
 documents them to be. Those programmers who need to know what the error
 number is are probably not going to be too happy to find out they have  
 to
 negate it. It'll inevitably get negated the wrong number of times, and  
 the
 result will be irritating bugs.

 Philosophically, I'm strongly opposed to fixing the operating system  
 API. If
 D does, then D has the onerous and impossible task of re-documenting  
 the OS
 interface (instead of just referring to the docs written by the OS  
 vendor).
 I'll agree that the Windows designers should have been accommodating  
 with
 the C errno and come up with a getLastErrno() that will coexist with  
 it. But
 they didn't, and so it is what it is.



 Ok, fair enough, how about if I write some code to show how I believe it  
 can be done, and you comment on that.



Ok, so what do you think of this solution?
Other peoples input would be appreciated also.

Regan
------------2igF2tOYaIY9BeLfX8SOzm
Content-Disposition: attachment; filename=syserror.d
Content-Type: application/octet-stream; name=syserror.d
Content-Transfer-Encoding: 8bit

module lib.syserror;

private import std.string;
private import std.c.stdarg;
private import std.c.stdlib;

version(Windows) {
	import std.c.windows.windows;
	
	uint ERROR_NOT_ENOUGH_MEMORY = 8;

	enum ERRNO : uint {
		EZERO		= 0,
		
		EPERM           = 1,
		ENOENT          = 2,
		ESRCH           = 3,
		EINTR           = 4,
		EIO             = 5,
		ENXIO           = 6,
		E2BIG           = 7,
		ENOEXEC         = 8,
		EBADF           = 9,
		ECHILD          = 10,
		EAGAIN          = 11,
		ENOMEM          = 12,
		EACCES          = 13,
		EFAULT          = 14,
		EBUSY           = 16,
		EEXIST          = 17,
		EXDEV           = 18,
		ENODEV          = 19,
		ENOTDIR         = 20,
		EISDIR          = 21,
		EINVAL          = 22,
		ENFILE          = 23,
		EMFILE          = 24,
		ENOTTY          = 25,
		EFBIG           = 27,
		ENOSPC          = 28,
		ESPIPE          = 29,
		EROFS           = 30,
		EMLINK          = 31,
		EPIPE           = 32,
		EDOM            = 33,
		ERANGE          = 34,
		EDEADLK         = 36,
		ENAMETOOLONG    = 38,
		ENOLCK          = 39,
		ENOSYS          = 40,
		ENOTEMPTY       = 41,
		EILSEQ          = 42,
		
		LAST		= 43,
		OFFSET		= (1<<29),
		CUSTOM		= OFFSET+LAST
	}
}

version(linux) {
}

version(freebsd) {
}

extern(C) int* _errno();

abstract class SystemException : Exception
{
	private uint _errorCode;
	
	this(char[] msg)
	{
		super(msg);
	}
	
	this(uint code)
	{	
		_errorCode = code;
		super(systemErrorString(_errorCode));
	}
	
	uint errorCode()
	{
		return _errorCode;
	}
}

class ErrnoException : SystemException
{
	this()
	{
		this(*_errno());
	}
	
	this(uint code)
	{	
		super(code|ERRNO.OFFSET);
	}
	
	override final uint errorCode()
	{
		return _errorCode & ~ERRNO.OFFSET;
	}
}

class WindowsException : SystemException
{
	this()
	{
		this(GetLastError());
	}
	
	this(uint code)
	{	
		super(code);
	}
}

/* This is how the socket one would work
class SocketException : SystemException
{
	this()
	{
		this(WSAGetLastError());
	}
	
	this(uint code)
	{	
		super(code);
	}
}
*/

char[] systemErrorString(ERRNO code)
{
	return systemErrorString(cast(uint)code|ERRNO.OFFSET);
}

char[] systemErrorString(uint code)
{
	if (code & ERRNO.OFFSET) {
		code &= ~ERRNO.OFFSET;
		
		if (code == ERRNO.ENOMEM) return "not enough memory";
		else {
			char* pemsg;
			uint r;

			pemsg = strerror(code);
			r = strlen(pemsg);
			/* Remove \r\n from error string */
			if (pemsg[r-1] == '\n') r--;
			if (pemsg[r-1] == '\r') r--;
			return pemsg[0..r].dup;
		}
	}

	version(Windows)
	{
		char[] text;
		
		if (code == ERROR_NOT_ENOUGH_MEMORY) return "not enough memory";
		else {
			LPVOID lpMsgBuf;
			DWORD r;

			r = FormatMessageA( 
				FORMAT_MESSAGE_ALLOCATE_BUFFER | 
				FORMAT_MESSAGE_FROM_SYSTEM | 
				FORMAT_MESSAGE_IGNORE_INSERTS,
				null,
				code,
				MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default language
				cast(LPTSTR)&lpMsgBuf,
				0,
				null 
			);
			/* Remove \r\n from error string */
			if (r >= 2) r -= 2;
			text = (cast(char *)lpMsgBuf)[0..r].dup;
			LocalFree(cast(HLOCAL)lpMsgBuf);
		}
		
		return text;
	}
	
	return null;	
}

unittest {
	SystemException se;
	
	se = new ErrnoException();
	assert(se.errorCode == ERRNO.EZERO);
	assert(se.toString() == systemErrorString(ERRNO.EZERO));
	
	se = new ErrnoException(ERRNO.EEXIST);
	assert(se.errorCode == ERRNO.EEXIST);
	assert(se.toString() == systemErrorString(ERRNO.EEXIST));
	
	se = new WindowsException();
	assert(se.toString() == systemErrorString(cast(uint)0));
	
	se = new WindowsException(5);
	assert(se.toString() == systemErrorString(cast(uint)5));
}

------------2igF2tOYaIY9BeLfX8SOzm--
Apr 17 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opspc69zdb23k2f5 nrage.netwin.co.nz...

 Ok, so what do you think of this solution?
 Other peoples input would be appreciated also.



I appreciate the effort you've put into this.

What's wrong with the setup in 0.121 Phobos? Why try to force a merge? Code
that will generate a C errno is always going to be very different from code
that generates a Windows getLastError(). Keep them parallel and distinct,
and there shouldn't be any confusion about it.

Your method reserves the 'CUSTOM' value range. What if the user's
application needs a custom value range? They can't use D. What if a D app
links to a C dll that uses those values? It'll fail in mysterious ways.
Apr 17 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Sun, 17 Apr 2005 11:09:32 -0700, Walter <newshound digitalmars.com>  
wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opspc69zdb23k2f5 nrage.netwin.co.nz...

 Ok, so what do you think of this solution?
 Other peoples input would be appreciated also.



 I appreciate the effort you've put into this.



No problem.


 What's wrong with the setup in 0.121 Phobos?



Everyone who wants to return a system error code/string has to copy the  
code you've used in FileException (for example). Not too onerous, but not  
perfect.

Did you see the thread on exception chaining?

The idea was Exception would have a constructor like:
   this(char[] msg, Object cause) {
   }

Allowing any exception to refer to a previous exception as the cause of  
the current exception.

Using that, making a SystemException class, passing that as the cause  
would make future use of SystemException really easy i.e.

//if errno is to be used
new FooBarException("foobar failed", new ErrnoException());

//if GetLastError is to be used
new FooBarException("foobar failed", new WindowsException());

//if WSAGetLastError is to be used
new FooBarException("foobar failed", new  
WindowsException(WSAGetLastError()));



 Why try to force a merge?



Actually, you have a point, there is no need to merge the error codes to  
achieve the stuff above. Let me try again.



 Code that will generate a C errno is always going to be very different  
 from
 code that generates a Windows getLastError(). Keep them parallel and  
 distinct,
 and there shouldn't be any confusion about it.



Ok. I believe I have an idea in mind. One thing I will mention is that  
part of my intent was to have a common base class allowing you to catch  
both ErrnoException and WindowsException problems as SystemException,  
allowing system independant catch calls, eg.

try {
}
catch(SystemException e) {
}



 Your method reserves the 'CUSTOM' value range. What if the user's
 application needs a custom value range? They can't use D.



'CUSTOM' is the range intended for users to use. I've never defined custom  
error codes so I wasn't sure how to give an example of how to use 'CUSTOM'.



 What if a D app
 links to a C dll that uses those values? It'll fail in mysterious ways.



Wouldn't the DLL have to expose the error codes and error strings, or  
provide it's own method for getting an error string from an error code? If  
so, I'd imagine a new D <DLLNAME>Exception class would be written to  
handle them. eg.

class <DLLNAME>Exception : Exception {
   this(uint code)
   {
     super(<dll_function_to_get_error_string>(code));
   }
}

Regan
Apr 17 2005
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
------------YCwrGmyxDCSXWf53wZihIa
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15
Content-Transfer-Encoding: 8bit

Here is attempt #2, or is it #3.

Goals:
- Provide a base class SystemException that can be caught to catch all OS  
level exceptions regardless of OS.
- Make handling of system error codes easy for future exception writers.
- Provide both errno and GetLastError handling (on windows).
- Don't merge error codes for errno and GetLastError handling (on windows).

It is intended these classes be used with exception chaining. eg.

throw new FooException("custom text", new ErrnoException());
throw new FooException("custom text", new WindowsException());

Regan
------------YCwrGmyxDCSXWf53wZihIa
Content-Disposition: attachment; filename=syserror.d
Content-Type: application/octet-stream; name=syserror.d
Content-Transfer-Encoding: 8bit

module lib.syserror;

private import std.string;
private import std.c.stdarg;
private import std.c.stdlib;

extern(C) int* _errno();

class SystemException : Exception
{
	uint errorCode;
	
	this(uint code, char[] msg)
	{
		errorCode = code;
		super(msg);
	}
}

class ErrnoException : SystemException
{
	this()
	{
		this(*_errno());
	}
	
	this(uint code)
	{	
		super(code, errnoErrorString(code));
	}
}

version (Windows) {
	private import std.c.windows.windows;
	uint ERROR_NOT_ENOUGH_MEMORY = 8;
	uint ENOMEM = 12;
	
	class WindowsException : SystemException
	{
		this()
		{
			this(GetLastError());
		}

		this(uint code)
		{	
			super(code, windowsErrorString(code));
		}
	}

	/* This is how a socket one could be defined
	class SocketException : WindowsException
	{
		this()
		{
			super(WSAGetLastError());
		}

		this(uint code)
		{	
			super(code);
		}
	}
	*/
}

version (linux) {
	//uint ENOMEM = ?;
	
	/* This is how a socket one could be defined
	class SocketException : ErrnoException
	{
		this()
		{
			super();
		}
		
		this(uint code)
		{
			super(code);
		}
	}
	*/
}

char[] errnoErrorString()
{
	return errnoErrorString(*_errno());
}

char[] errnoErrorString(uint code)
{
	if (code == ENOMEM) return "not enough memory";
	else {
		char* pemsg;
		uint r;

		pemsg = strerror(code);
		r = strlen(pemsg);
		/* Remove \r\n from error string */
		if (pemsg[r-1] == '\n') r--;
		if (pemsg[r-1] == '\r') r--;
		return pemsg[0..r].dup;
	}
	return null;
}

version(Windows)
{
	char[] windowsErrorString()
	{
		return windowsErrorString(GetLastError());
	}
	
	/*
	char[] socketErrorString()
	{
		return windowsErrorString(WSAGetLastError());
	}
	*/
	
	char[] windowsErrorString(uint code)
	{
		char[] text = null;
		
		if (code == ERROR_NOT_ENOUGH_MEMORY) return "not enough memory";
		else {
			LPVOID lpMsgBuf;
			DWORD r;

			r = FormatMessageA( 
				FORMAT_MESSAGE_ALLOCATE_BUFFER | 
				FORMAT_MESSAGE_FROM_SYSTEM | 
				FORMAT_MESSAGE_IGNORE_INSERTS,
				null,
				code,
				MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default language
				cast(LPTSTR)&lpMsgBuf,
				0,
				null 
			);
			/* Remove \r\n from error string */
			if (r >= 2) r -= 2;
			text = (cast(char *)lpMsgBuf)[0..r].dup;
			LocalFree(cast(HLOCAL)lpMsgBuf);
		}
		
		return text;
	}
}

unittest {
	SystemException se;
	uint EEXIST = 17;
	
	se = new ErrnoException();
	assert(se.errorCode == 0);
	assert(se.toString() == errnoErrorString(0));
	
	se = new ErrnoException(EEXIST);
	assert(se.errorCode == EEXIST);
	assert(se.toString() == errnoErrorString(EEXIST));
	
	se = new WindowsException();
	assert(se.toString() == windowsErrorString(0));
	
	se = new WindowsException(5);
	assert(se.toString() == windowsErrorString(5));
}

------------YCwrGmyxDCSXWf53wZihIa--
Apr 17 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opspebv4zg23k2f5 nrage.netwin.co.nz...

 Your method reserves the 'CUSTOM' value range. What if the user's
 application needs a custom value range? They can't use D.



 'CUSTOM' is the range intended for users to use.



Yes. Not for systems tools like D <g>.
Apr 17 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Sun, 17 Apr 2005 15:50:47 -0700, Walter <newshound digitalmars.com>  
wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opspebv4zg23k2f5 nrage.netwin.co.nz...

 Your method reserves the 'CUSTOM' value range. What if the user's
 application needs a custom value range? They can't use D.



 'CUSTOM' is the range intended for users to use.



 Yes. Not for systems tools like D <g>.



Yep. Which is why I redefined it to not include the values I needed for  
errno values.

Regan
Apr 17 2005
prev sibling next sibling parent reply "Shawn Liu" <liuxuhong.cn gmail.com> writes:
I still encounter a runtime error "Stream is not seekable". But the apps 
compiled with V0.119 don't encounter that.

Shawn

"Walter" <newshound digitalmars.com> :d3pc4b$19cp$1 digitaldaemon.com...

 Focus is on fixing compiler issues, especially the bugs introduced with
 0.120.

 http://www.digitalmars.com/d/changelog.html
Apr 15 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
Can post or send me some reproduction steps?
thanks
-Ben

"Shawn Liu" <liuxuhong.cn gmail.com> wrote in message 
news:d3qcgi$21vo$1 digitaldaemon.com...

I still encounter a runtime error "Stream is not seekable". But the apps 
compiled with V0.119 don't encounter that.
Apr 16 2005
parent reply "Shawn Liu" <liuxuhong.cn gmail.com> writes:
File file = new File(hReadPipe, FileMode.In);
 while(!file.eof()){
  String s = file.readLine();
  if(s.length  == 0 )
   break;
  callback(s);
 }
 file.close();

Maybe this occured at file.readLine();


"Ben Hinkle" <ben.hinkle gmail.com> :d3r7i4$2sm4$1 digitaldaemon.com...

 Can post or send me some reproduction steps?
 thanks
 -Ben

 "Shawn Liu" <liuxuhong.cn gmail.com> wrote in message
 news:d3qcgi$21vo$1 digitaldaemon.com...

I still encounter a runtime error "Stream is not seekable". But the apps
compiled with V0.119 don't encounter that.
Apr 16 2005
parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
Ah, Dave Fladebo also noticed pipe input streams weren't working and I 
forgot to look into it. sorry about that!

"Shawn Liu" <liuxuhong.cn gmail.com> wrote in message 
news:d3rg18$149$1 digitaldaemon.com...

 File file = new File(hReadPipe, FileMode.In);
 while(!file.eof()){
  String s = file.readLine();
  if(s.length  == 0 )
   break;
  callback(s);
 }
 file.close();

 Maybe this occured at file.readLine();


 "Ben Hinkle" <ben.hinkle gmail.com> :d3r7i4$2sm4$1 digitaldaemon.com...

 Can post or send me some reproduction steps?
 thanks
 -Ben

 "Shawn Liu" <liuxuhong.cn gmail.com> wrote in message
 news:d3qcgi$21vo$1 digitaldaemon.com...

I still encounter a runtime error "Stream is not seekable". But the apps
compiled with V0.119 don't encounter that.
Apr 16 2005
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:

 Focus is on fixing compiler issues, especially the bugs introduced with
 0.120.
 
 http://www.digitalmars.com/d/changelog.html



"Abstract class methods now cause the class to be abstract."

That's always worked in my experience.  So what's changed?

"Fixed a bug in the Windows version of seek() with files larger than 
uint.sizeof."

How strange that something would ever have been written that worked only 
on files up to 4 bytes....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Apr 18 2005
next sibling parent "Walter" <newshound digitalmars.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:d40ns9$1dji$1 digitaldaemon.com...

 Walter wrote:
 "Abstract class methods now cause the class to be abstract."

 That's always worked in my experience.  So what's changed?



A couple of the abstract_nn cases in Dstress.
Apr 18 2005
prev sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
 "Fixed a bug in the Windows version of seek() with files larger than 
 uint.sizeof."

 How strange that something would ever have been written that worked only 
 on files up to 4 bytes....



hehe. you're right. I sent that to Walter and didn't even realize how silly 
that is. I should have said uint.max, of course. :-P
Apr 18 2005
prev sibling parent Vathix <vathix dprogramming.com> writes:
"Walter" <newshound digitalmars.com> wrote in news:d3pc4b$19cp$1
 digitaldaemon.com:


 Focus is on fixing compiler issues, especially the bugs introduced with
 0.120.
 
 http://www.digitalmars.com/d/changelog.html
 



Would be nice if deprecated aliases were added for renamed things so that 
the old names will still work for awhile.
Apr 20 2005