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
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.
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
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?
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
(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.
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
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...
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
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...
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
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...
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  
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...
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
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...
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
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...
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
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...
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
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.
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
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.
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
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.
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).
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
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?
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
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
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
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
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:
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
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
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
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:


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
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.
begin 666 func.d M8F]O;"!L875N8VA!;F1786ET*%-T<FEN9R!C;61L:6YE+"!V;VED(&1E;&5G M92P :%=R:71E4&EP93L-" E314-54DE465]!5%1224)55$53('-A.PT*"7-A M+FY,96YG=& /2!314-54DE465]!5%1224)55$53+G-I>F5O9CL-" ES82YB M4&EP92P )FA7<FET95!I<&4L("9S82P ,"DI>PT*"0EW<FET969L;B B1F%I M;&5D('1O(&-R96%T92!P:7!E("$B*3L-" D)<F5T=7)N(&9A;'-E.PT*"7T- M" D-" E35$%25%5024Y&3R!S:3L-" ES:2YC8B ](%-405)455!)3D9/+G-I M>F5O9CL-" ES:2YH4W1D26YP=70 /2!N=6QL.PT*"7-I+FA3=&1/=71P=70 M9%!I<&4 *3L-"B (" )0VQO<V5(86YD;&4H(&A7<FET95!I<&4 *3L-"B M(" )=W)I=&5F;&XH(D9A:6QE9"!T;R!C<F5A=&4 <')O8V-E<W, (2(I.PT* M:')E860I.PT*"4-L;W-E2&%N9&QE*&A7<FET95!I<&4I.PT*"0T*"49I;&4 M9FEL92 ](&YE=R!&:6QE*&A296%D4&EP92P 1FEL94UO9&4N26XI.PT*"7=H M:6QE*"%F:6QE+F5O9B I*7L-" D)4W1R:6YG(', /2!F:6QE+G)E861,:6YE M(#T ,#L- M=70)"0T*"0EL17)R;W( /2!'971,87-T17)R;W(H*3L)"0D-" D)8G)E86L[ M(&-H96-K(&EF('1H92!P<F]C8V5S<R!S=&EL;"!A8W1I=F4)"0D (" (" - M2VEL;"!T:&4 <')O8V-E<W,-" D)"51E<FUI;F%T951H<F5A9"AP:2YH5&AR ` end
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