| View previous topic :: View next topic |
| Author |
Message |
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
 Posted: Mon May 22, 2006 3:55 pm Post subject: |
 |
|
The template errors following the 'scope' thing are bogus ... that always seems to happen when there's one error, and there are templates involved somewhere ~ once the initial problem is fixed, the template errors all go away.
To get around the scope() problem, you might just comment-out that line? |
|
| Back to top |
|
 |
Carlos
Joined: 19 Mar 2004
Posts: 396
Location: Canyon, TX
|
| Posted: Mon May 22, 2006 5:54 pm Post subject: |
|
|
| kris wrote: | The template errors following the 'scope' thing are bogus ... that always seems to happen when there's one error, and there are templates involved somewhere ~ once the initial problem is fixed, the template errors all go away.
To get around the scope() problem, you might just comment-out that line? |
... and replace it with a try {} finally {}
I'm going to try that. |
|
| Back to top |
|
|
Carlos
Joined: 19 Mar 2004
Posts: 396
Location: Canyon, TX
|
| Posted: Mon May 22, 2006 7:53 pm Post subject: |
|
|
What I did to make it compile:
mango/io/FileSystem.d, lines 172 and 184: std.c.linux.linux changed to posix.
mango/sys/Epoch.d, ~ line 483: added
extern (C) static int timezone;
extern (C) static int daylight;
Without them (esp. timezone), tzMinutes doesn't compile. However, while the time and date reported by Epoch are correct, the timezone is not (I get GMT0000).
-OT-
This whole thing with retrieving the correct full time (see my problems with Phobos in digitalmars.D.bugs) is driving me crazy. Surely, I haven't needed it as of late, but it's there and I can't believe no one else has had any problems with std.date or mango.sys.Epoch. I'm starting to believe that I'm really losing my mind about it. Is it a coding problem? A platform support problem (i.e., no OS correctly supports all time zones)? I don't think it's a configuration problem, because I'm not doing anything forbidden by the OS, but since nobody else is having problems, I'm starting to second guess myself...
Sorry, I had to get it out of my system.
PS: since I know you're going to ask, with my proposed "fix" in Epoch.d, the localtime example prints:
Mon May 22 20:48:37 GMT0000 2006
Correct date and time, wrong time zone. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon May 22, 2006 8:45 pm Post subject: |
|
|
| Carlos wrote: | What I did to make it compile:
mango/io/FileSystem.d, lines 172 and 184: std.c.linux.linux changed to posix. |
For which compiler? The recent dmd I have still uses std.c.linux.linux ...
| Carlos wrote: | mango/sys/Epoch.d, ~ line 483: added
extern (C) static int timezone;
extern (C) static int daylight;
Without them (esp. timezone), tzMinutes doesn't compile. However, while the time and date reported by Epoch are correct, the timezone is not (I get GMT0000).
|
That's odd, because they were there originally, and had to be commented out on Jan 20th (for linux). I need to get to the bottom of this 
Which OS and which compiler are you using, Carlos?
| Carlos wrote: |
-OT-
This whole thing with retrieving the correct full time (see my problems with Phobos in digitalmars.D.bugs) is driving me crazy. Surely, I haven't needed it as of late, but it's there and I can't believe no one else has had any problems with std.date or mango.sys.Epoch. I'm starting to believe that I'm really losing my mind about it. Is it a coding problem? A platform support problem (i.e., no OS correctly supports all time zones)? I don't think it's a configuration problem, because I'm not doing anything forbidden by the OS, but since nobody else is having problems, I'm starting to second guess myself...
Sorry, I had to get it out of my system.
PS: since I know you're going to ask, with my proposed "fix" in Epoch.d, the localtime example prints:
Mon May 22 20:48:37 GMT0000 2006
Correct date and time, wrong time zone. |
hehe 
On linux, the timezone seems to be a pain in the buttocks. More often than not, the linker hooks you up with some C-lib value that is always set to zero. I don't know much about how the OS sets this (via some config file somewhere), but got it operational on Ubuntu ... |
|
| Back to top |
|
|
Carlos
Joined: 19 Mar 2004
Posts: 396
Location: Canyon, TX
|
| Posted: Mon May 22, 2006 9:33 pm Post subject: |
|
|
| kris wrote: | | Carlos wrote: | What I did to make it compile:
mango/io/FileSystem.d, lines 172 and 184: std.c.linux.linux changed to posix. |
For which compiler? The recent dmd I have still uses std.c.linux.linux ... |
GDC 0.17, Mac OS X 10.4.6. The module is std.c.darwin.darwin, aliased to "posix" in mango.sys.OS, and that's what I think should be used all over the place.
| kris wrote: | | Carlos wrote: | mango/sys/Epoch.d, ~ line 483: added
extern (C) static int timezone;
extern (C) static int daylight;
Without them (esp. timezone), tzMinutes doesn't compile. However, while the time and date reported by Epoch are correct, the timezone is not (I get GMT0000).
|
That's odd, because they were there originally, and had to be commented out on Jan 20th (for linux). I need to get to the bottom of this
Which OS and which compiler are you using, Carlos?
| Carlos wrote: |
-OT-
This whole thing with retrieving the correct full time (see my problems with Phobos in digitalmars.D.bugs) is driving me crazy. Surely, I haven't needed it as of late, but it's there and I can't believe no one else has had any problems with std.date or mango.sys.Epoch. I'm starting to believe that I'm really losing my mind about it. Is it a coding problem? A platform support problem (i.e., no OS correctly supports all time zones)? I don't think it's a configuration problem, because I'm not doing anything forbidden by the OS, but since nobody else is having problems, I'm starting to second guess myself...
Sorry, I had to get it out of my system.
PS: since I know you're going to ask, with my proposed "fix" in Epoch.d, the localtime example prints:
Mon May 22 20:48:37 GMT0000 2006
Correct date and time, wrong time zone. |
hehe
On linux, the timezone seems to be a pain in the buttocks. More often than not, the linker hooks you up with some C-lib value that is always set to zero. I don't know much about how the OS sets this (via some config file somewhere), but got it operational on Ubuntu ... |
I'm not trying linux or windows at this time, so I couldn't tell. With Phobos, I couldn't get a correct result on linux when I tried (or windows). Maybe you could try Mango with different timezones and see how that goes? |
|
| Back to top |
|
|
Carlos
Joined: 19 Mar 2004
Posts: 396
Location: Canyon, TX
|
| Posted: Mon May 22, 2006 9:36 pm Post subject: |
|
|
I almost forgot: I had to comment out line 76 in mango/io/ServerSocket.d:
setAddressReuse (socketReuse);
Because at runtime I get: "Error: Unable to set socket option: Invalid argument". I had to do the same with Mango 2.0.
--
Ok, now that I have a working trunk, is this how I should do the original example?
| Code: |
auto ia = new InternetAddress (port);
auto server = new TextServerSocket (ia);
auto client = server.accept ();
auto reader = new TextReader (new NumericParser (new LineIterator (client)), new UnicodeExporter!(char) ());
|
I'm sorry but, are you kidding me? Worst is, I don't even know if that's going to work.
Why, because TextServerSocket isn't working yet: when you call TextServerSocket.createSocket, it calls TextSocketConduit.create, which in fact is SocketConduit.create, which in turn calls SocketConduit.allocate. Down there (line 173) what's created is a SocketConduit, not a TextSocketConduit, so I keep getting "Error: text/binary mismatch between Reader and Buffer". |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon May 22, 2006 9:47 pm Post subject: |
|
|
| Carlos wrote: | | Maybe you could try Mango with different timezones and see how that goes? |
I have ~ on Win32 and Ubuntu. It appeared to work fine on both. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon May 22, 2006 9:51 pm Post subject: |
|
|
| Carlos wrote: | I almost forgot: I had to comment out line 76 in mango/io/ServerSocket.d:
setAddressReuse (socketReuse);
Because at runtime I get: "Error: Unable to set socket option: Invalid argument". I had to do the same with Mango 2.0. |
So you're on OS-X? That at least explains some of the difficulties, in that none of this is ever tested on a Mac. Can you perhaps dig up the appropriate SocketOpt variation for doing this on the Mac, please? |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon May 22, 2006 9:57 pm Post subject: |
|
|
| Carlos wrote: | Ok, now that I have a working trunk, is this how I should do the original example?
| Code: |
auto reader = new TextReader (new NumericParser (new LineIterator (client)), new UnicodeExporter!(char) ());
|
I'm sorry but, are you kidding me? Worst is, I don't even know if that's going to work.
|
I've no idea why anyone would wish to do such a thing with a socket
*sigh* ~ I'll fix the obvious mistake in ServerSocket and check it in ... |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon May 22, 2006 10:19 pm Post subject: |
|
|
While I'm figuring out how to fix this, why do you need a Reader on the socket? If you just want to extract lines from it, the earlier example will facilitate nicely:
| Code: |
foreach (line; new LineIterator (socket.accept))
// do something with char[] 'line' |
It's the Reader/Writer pair which check for binary/text mismatches ~ Iterators don't give a damn, although they perhaps should? |
|
| Back to top |
|
|
Carlos
Joined: 19 Mar 2004
Posts: 396
Location: Canyon, TX
|
| Posted: Tue May 23, 2006 6:38 am Post subject: |
|
|
| kris wrote: | | Carlos wrote: | I almost forgot: I had to comment out line 76 in mango/io/ServerSocket.d:
setAddressReuse (socketReuse);
Because at runtime I get: "Error: Unable to set socket option: Invalid argument". I had to do the same with Mango 2.0. |
So you're on OS-X? That at least explains some of the difficulties, in that none of this is ever tested on a Mac. Can you perhaps dig up the appropriate SocketOpt variation for doing this on the Mac, please? |
It's going to take a while: I had never seen SocketOpt before, I don't know what it does, etc., etc. I'm gonna try, though.
| kris wrote: | | Carlos wrote: | Ok, now that I have a working trunk, is this how I should do the original example?
| Code: |
auto reader = new TextReader (new NumericParser (new LineIterator (client)), new UnicodeExporter!(char) ());
|
I'm sorry but, are you kidding me? Worst is, I don't even know if that's going to work.
|
I've no idea why anyone would wish to do such a thing with a socket |
I take it as "this is the wrong way to create a TextReader from a Conduit". What is the right way, then? In previous versions it was just "new TextReader(conduit,new LineToken)" or something like that. I can't find a simple way to do with the new code.
| kris wrote: | | *sigh* ~ I'll fix the obvious mistake in ServerSocket and check it in ... |
Ok, thanks.
| kris wrote: | While I'm figuring out how to fix this, why do you need a Reader on the socket? If you just want to extract lines from it, the earlier example will facilitate nicely:
| Code: |
foreach (line; new LineIterator (socket.accept))
// do something with char[] 'line' |
It's the Reader/Writer pair which check for binary/text mismatches ~ Iterators don't give a damn, although they perhaps should? |
I'd prefer to have a Reader so I don't have to create objects over and over again. Besides, it just seems weird to have to use foreach to read just a single line (IMO). Oh, and remember that it's reading and writing lines, FWIW. |
|
| Back to top |
|
|
Carlos
Joined: 19 Mar 2004
Posts: 396
Location: Canyon, TX
|
| Posted: Tue May 23, 2006 8:09 am Post subject: |
|
|
| kris wrote: | While I'm figuring out how to fix this, why do you need a Reader on the socket? If you just want to extract lines from it, the earlier example will facilitate nicely:
| Code: |
foreach (line; new LineIterator (socket.accept))
// do something with char[] 'line' |
It's the Reader/Writer pair which check for binary/text mismatches ~ Iterators don't give a damn, although they perhaps should? |
I still think TextReader would be better suited, but LineIterator seems to work just fine. Thanks again. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Tue May 23, 2006 10:47 am Post subject: |
|
|
| Carlos wrote: | | kris wrote: | While I'm figuring out how to fix this, why do you need a Reader on the socket? If you just want to extract lines from it, the earlier example will facilitate nicely:
| Code: |
foreach (line; new LineIterator (socket.accept))
// do something with char[] 'line' |
It's the Reader/Writer pair which check for binary/text mismatches ~ Iterators don't give a damn, although they perhaps should? |
I still think TextReader would be better suited, but LineIterator seems to work just fine. Thanks again. |
Sure ... no problem
Readers and writers are intended for fixed, formatted, IO. As such, the Reader will throw an exception if it does not find what it expects (this allows it to be more efficient than it would otherwise be).
On the other hand, Iterators are for reading "loosly structured" data, where the incoming format is in the "go look for a terminator" style. Thus, with an Iterator, you end up in a test and get loop rather than a simple get. Reading lines seems more suited to the Iterator style, plus, it allows for simpler handling of unicode differences. |
|
| Back to top |
|
|
Carlos
Joined: 19 Mar 2004
Posts: 396
Location: Canyon, TX
|
| Posted: Tue May 23, 2006 12:20 pm Post subject: |
|
|
| kris wrote: | Readers and writers are intended for fixed, formatted, IO. As such, the Reader will throw an exception if it does not find what it expects (this allows it to be more efficient than it would otherwise be).
On the other hand, Iterators are for reading "loosly structured" data, where the incoming format is in the "go look for a terminator" style. Thus, with an Iterator, you end up in a test and get loop rather than a simple get. Reading lines seems more suited to the Iterator style, plus, it allows for simpler handling of unicode differences. |
Too bad there is no writing equivalent to Iterators. Anyway, I'm ok with reading with Iterators now. It's the inability to write text what's bugging me... hehe... |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Tue May 23, 2006 12:33 pm Post subject: |
|
|
BTW: if you just want a single line of input, then you can dispense with the foreach() and instead do a get() on the LineIterator instance. This will simply wait until there's either a line available in the input or an eof is encountered. The foreach() is just a wrapper around get(). Oh, and you can reuse a LineIterator instance via the various set...() methods.
I thought about having an output equivalent of Iterator, but couldn't come up with anything compelling. If you have some ideas, please make them known
Currently there's at least three (layered) ways to output content to a conduit, from lowest level to highest:
* conduit.write()
* buffer.append()
* writer.put()
The latter handles various conversion as necessary (including unicode conversion), whereas the former two are simple unformatted output using void[] arguments. If you don't need conversion, the former two are more appropriate, with the middle (buffered) one probably being the right balance for common designs. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
