View previous topic :: View next topic |
Author |
Message |
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Sun Feb 06, 2005 3:05 am Post subject: |
|
|
JJR wrote: | Thinking this through a little more:
This new notation is actually an excellent answer to << and >>. It also appears to improve on the get and put methods. I think if this gains enough support, you may be able to finally ditch the shift operators.
It's a win, win. |
Agreed. But I suspect some C++ folks may prefer to retain the iostream syntax regardless. In truth, supporting that syntax has been somewhat beneficial to Mango, since it forces one to think of alternate solutions to the inevitable issues.
While we're on the subject, there are two such issues with the iostream syntax right now. One is related to the limit of one argument per opShr/opShl operator. The other is related to flush(), in that one has to kinda' switch syntax for a moment. Problems, problems ... |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Sun Feb 06, 2005 3:07 am Post subject: |
|
|
I'll think about the CR for a bit. Since it's late, that probably means I'll sleep on that thought (and dream?).
I'm stuck at work anyway for the next few shifts. Nice to have a network to plug into in such situations!
I'll check into dsource again in the morning... or, uh, /later/ in the morning.
I think you're on the right track, though, Kris.
- John R. |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Sun Feb 06, 2005 3:18 am Post subject: |
|
|
JJR wrote: | I'll think about the CR for a bit. Since it's late, that probably means I'll sleep on that thought (and dream?).
I'm stuck at work anyway for the next few shifts. Nice to have a network to plug into in such situations!
I'll check into dsource again in the morning... or, uh, /later/ in the morning.
|
Cool!
Bit of a bummer about the back-to-back shifts, but at least you won't have to commute ...
Vaguely amusing to reflect on how the 'net has infiltrated the lives of so many in just a decade. It's certainly convenient! |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Sun Feb 06, 2005 9:39 pm Post subject: |
|
|
kris wrote: |
Cheers! The style is somewhat unique to the D language (if you ignore Lisp ...), and it's kinda' growing on me - cleaner than the other syntax, as you noted. Perhaps we should give the format a name, so we can refer to it in further discussion; how about whisper, or psssst?
|
Heh, "whisper" works, now that I use it a few times.
I'm still mulling over details of CR. No huge brain flashes yet, although work tends to get in the way with those.
I'm thinking the global CR might just do for now. It's sure hard to beat for simplicity. Don't know what other option would work ATM beyond adding it to a special global enum class type with a severely abreviated name, term.CR, code.CR, op.CR, or esc.CR (bad examples, I know). But that almost brings us back to the problem of excessive verbosity.
Global CR may be the way to go.
- John R. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Mon Feb 07, 2005 3:10 am Post subject: |
|
|
Hey Kris,
You're update works great on win32. Could you update the linux makefile for the changes also? I'm not sure how many files have changed. I fixed the Stdio.d -> Stdin.d and Stdout.d, but there seems to be other files to add/remove in the makefile.
Thanks,
John R. |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Mon Feb 07, 2005 12:35 pm Post subject: |
|
|
JJR wrote: | Hey Kris,
You're update works great on win32. Could you update the linux makefile for the changes also? I'm not sure how many files have changed. I fixed the Stdio.d -> Stdin.d and Stdout.d, but there seems to be other files to add/remove in the makefile.
|
Hi John;
The linux makefile in SVN appears to be correct (it has the Stdio change). Was there something else broken? The make files have diverged in some respects, because I have all the deployment crap within the win32 version. I should probably move that out into a seperate file, eh?
- Kris |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Mon Feb 07, 2005 12:48 pm Post subject: |
|
|
No, it was my fault this time. For some reason my linux.make file was not overwritten on the svn update (probably because I made some local changes). I backed it up by renaming it and redid the svn update to get the correct replacement. That worked, but it still wouldn't compile because, at some point, I had messed with Socket.d. This caused the svn Socket.d to be merged with my changes, further messing things up. Once again the fix was to remove my Socket.d and update again. Phew! Now all things compile.
Sorry about that. It's just that darn golden screwdriver, you know!
Thanks for checking,
John R. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Mon Feb 07, 2005 1:20 pm Post subject: |
|
|
I've compiled lineio.d example on Linux, and it worked perfectly. I'm liking the "whisper" notation more all the time. As a bonus, the linux executable is 303,942 bytes verses the win32 versions 424,136 bytes.
- John R. |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Mon Feb 07, 2005 2:11 pm Post subject: |
|
|
JJR wrote: | I've compiled lineio.d example on Linux, and it worked perfectly. I'm liking the "whisper" notation more all the time. As a bonus, the linux executable is 303,942 bytes verses the win32 versions 424,136 bytes. |
Ack! That's kinda' big. Is that with debug symbols, and so on? Oh - I suppose all the tokenizer stuff is loaded for lineio.d - oh well.
The reason for seperating Stdin from Stdout was to remove the tokenizer overhead. Last night I also removed the implicit dependencies on printf/scanf, to reduce the footprint substantially (if Walter finally removes the printf call from within Object.d). But that's not checked in yet.
Glad you like "whisper" |
|
Back to top |
|
|
csauls
Joined: 27 Mar 2004 Posts: 278
|
Posted: Mon Feb 07, 2005 2:28 pm Post subject: |
|
|
Thought I would semi-belatedly jump in and say this "whisper" syntax of yours looks rather nice. On the subject of formatting, maybe you could use something like this:
Code: |
void report(IWriter writer) {
writer ("Transaction #") (this.number, "length:5 pad:0 align:right") ;
}
|
The basic idea is that instead of "opCall(int x)" you have "opCall(int x, char[] fmt = "")" so that you could imbed formatting codes by giving an optional second parameter to the, er, whisper. The syntax of such formatting codes could be anything, I know my example was pretty explicit.
And also, on the subject of CR, since IWriter.cr() returns 'this' couldn't I do something like:
Code: |
writer (foo) (bar) .cr() (someOther) .cr() ;
|
_________________ Chris Nicholson-Sauls |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Mon Feb 07, 2005 4:04 pm Post subject: |
|
|
csauls wrote: | Thought I would semi-belatedly jump in and say this "whisper" syntax of yours looks rather nice. On the subject of formatting, maybe you could use something like this:
Code: |
void report(IWriter writer) {
writer ("Transaction #") (this.number, "length:5 pad:0 align:right") ;
}
|
The basic idea is that instead of "opCall(int x)" you have "opCall(int x, char[] fmt = "")" so that you could imbed formatting codes by giving an optional second parameter to the, er, whisper. The syntax of such formatting codes could be anything, I know my example was pretty explicit.
And also, on the subject of CR, since IWriter.cr() returns 'this' couldn't I do something like:
Code: |
writer (foo) (bar) .cr() (someOther) .cr() ;
|
|
Your format notion is an interesting one, Chris. I had been thinking along the lines of using meta-output for controlling format (a bit like CR), but that was just a half-baked notion. Consider this, though: using more than one parameter effectively relegates <</>> to outcast status, since that supports just one argument per operator.
I'd like to maintain a seperation, if we can, between the basic output functionality and the formatted variety. The reasons are twofold: (a) code size (b) the ability to augment or replace the formatting with something of ones own design. This is partly why Mango.io has the IReadable/IWritable mechanisms, such that one can bind their own classes directly to the IO sub-system.
One other fly in the ointment is that only a few IWriter implementations need to support such formatting. DisplayWriter and TextWriter come to mind, yet the binary Writer, EndianWriter, PickleWriter and so on do not. I have some difficulty juggling those contrasting requirements, and those of Writers not yet devised. Hence, there's a certain "path of least resistance" effect going on in Mango.io, where pretty-printing is considered to be an extension. The trade-off is trying to find a way whereby simple formatting jobs do not become an exercise in verbosity
Your second example is perfectly valid. Some might be bothered about the juxtaposition of differing styles, but using dot-notation is certainly one alternative to meta-variables (such as CR).
Good ideas! Any others? |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Mon Feb 07, 2005 4:09 pm Post subject: |
|
|
csauls wrote: | Thought I would semi-belatedly jump in and say this "whisper" syntax of yours looks rather nice. On the subject of formatting, maybe you could use something like this:
Code: |
void report(IWriter writer) {
writer ("Transaction #") (this.number, "length:5 pad:0 align:right") ;
}
|
|
If you have a formatter for doing the above, I'd certainly like to try and bolt it into Mango.io |
|
Back to top |
|
|
csauls
Joined: 27 Mar 2004 Posts: 278
|
Posted: Mon Feb 07, 2005 7:05 pm Post subject: |
|
|
I hear what you're saying about a second parameter causing trouble, and you make a good point. As for that formatter... well its really just CSS style (sans-semi-colon but I was just in a hurry) so it shouldn't be hard to do. Although later I thought it would be easy to use the same formatting strings as Phobos' std.format uses. If you really just want to give me something to do, then I'll try writing that CSS style formatter, just for kicks. _________________ Chris Nicholson-Sauls |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Mon Feb 07, 2005 8:06 pm Post subject: |
|
|
csauls wrote: | As for that formatter... well its really just CSS style (sans-semi-colon but I was just in a hurry) so it shouldn't be hard to do. Although later I thought it would be easy to use the same formatting strings as Phobos' std.format uses. If you really just want to give me something to do, then I'll try writing that CSS style formatter, just for kicks. |
That would be great!
One thing to consider in this realm is ICU. There's some pretty fancy formatting exposed by that library, including locale-specifics (externalized) and even numeric "spell-out" format; far beyond what printf et. al. are capable of. In addition, the ICU stuff also parses each of the formats it can print, and with respect to locale idioms. See the documentation for some of the C++ classes here: http://www-124.ibm.com/icu/apiref
This is partly why I've put very limited effort into coming up with formatting options for Mango (just a printf wrapper, which could simply be extended to Walter's format() method).
Of course, ICU is all wchar[]. There's plenty of room for other good formatting libraries |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Mon Feb 07, 2005 9:39 pm Post subject: |
|
|
I updated the old TextFormat class to use opCall, so it's a tad more concise:
Code: | TextFormat format = new TextFormat (256);
Stdout (format("?d green bottles", 10)); |
Should it use Walter's format() function instead of printf ? |
|
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
|