Walter Bright wrote:
> Trass3r wrote:
>>> obj2asm tells the tale. (obj2asm is an incredibly useful tool, I
>>> don't know why nobody uses it.)
>>>
>>
>> Maybe because it's not free (and not much advertised). obconv also
>> supports disassembling various object file formats + conversion
>> between them and it's open source:
>> http://www.agner.org/optimize/#objconv
>>
>> obj2asm might provide something fancy that objconv doesn't but its
>> page doesn't show anything that would justify paying 10$.
> 
> At first glance, obj2asm will pretty-print the codeview debug info in the object file, and will mix source lines with corresponding assembler lines.
> 
> Obj2asm also comes with a bunch of other utilities, any one of which is worth the $15 if you need them:
> 
> ◦chmod Change/list file attributes
> ◦coff2omf Convert COFF object and lib files to OMF
> ◦diff Compare text files
> ◦diffdir Compare directory trees
> ◦dump Dump files
> ◦dumpexe Dump executable files
> ◦dumpobj Dump object files
> ◦flpyimg Read/Write floppy disk image
> ◦grep Search files for strings
> ◦libunres Scan libraries for unresolved externals
> ◦makedep Makefile dependency generator
> ◦obj2asm Object file disassembler
> ◦patchobj Patch object files
> ◦smake Advanced make program
> ◦whereis Search for files
> 
> http://www.digitalmars.com/ctg/obj2asm.html

Why not give them out to free?
Especially coff2omf seems to be critical, if you want D to be a success.

On 2010-03-09 09:09:51 +0100, Alexander Suhoverhov <alexander@suhoverhov.selfip.net> said:

> 
> 
> Steven Schveighoffer  at "Mon, 08 Mar 2010 15:23:51 -0500" wrote:
>  SS> On Mon, 08 Mar 2010 15:12:24 -0500, bearophile <bearophileHUGS@lycos.com> wrote:
>  >> Steven Schveighoffer:
>  >>> Tell me how you would parse the following text serialization string for a
>  >>> string[]:
>  >>>
>  >>> hello world how are you
>  >>>
>  >>> What if it was a string[][]?
>  >>>
>  >>> Compare that to:
>  >>>
>  >>> [hello world, [how are, you]]
>  >>
>  >> You are missing something:
>  >>
>  >> ["hello world", ["how are", "you"]]
>  SS> For completely unambiguous, yes.  But still, I find often that quotes are more noise than
>  SS> they are worth when just doing simple printouts.  What we  want is the most useful
>  SS> default.
> 
> Commas are even more noise than than quotes. erlang:
> 
> [{app, "app1"}, {user, "user1"}, {score, 123456}, {date, 5000000}, {misc, "foo"}]
> 
> But if you just drop commas:
> 
> [{app "app1"} {user "user1"} {score 123456} {date 5000000} {misc "foo"}]
> 
>  SS> -Steve

For a basic output one can discuss what is better, but in general, for a serialization approach I feel that the basic approach of the discussion is flawed.
A much better approach (that for example I did use in my serialization routines) is following the C++ philosophy that these details are handled by the target stream, not by the function sending the data.
For example I have implemented two serializers, one that serializes to json (with [,]""), and one that serializes to a binary format.
You write just one function, and then you can (even at runtime) change the details on the output, even from textual to binary, without changing anything in the serialization functions.
You don't want to write a different serialization function for each format, or go around hunting for all calls to add " to strings...

Now in my serialization routines I have a couple of design choices that maybe not everybody would share, but that I like:
- it is possible to get a meta information describing what will be serialized *before* serializing (this helps in dumping the meta information once at the beginning, and then serialize arrays with minimal overhead in binary mode, but makes serializing slightly more complex.
- it if possible (and not too difficult) to write serialization routines fully by hand, without any template, something very useful for objects that need special serialization. This method can also be fully customized.

< shameless bug promotion>
By the way as I have some horrible code due to http://d.puremagic.com/issues/show_bug.cgi?id=3472 and similar bugs in mixing interfaces and templates, I had written a much nicer version only to find out that it did not work...
</ shameless bug promotion>

I am transitioning the whole i/o in blip to a more abstract model based on simple delegates (sink/readers) that should make it easier to use it with either phobos or tango or any other source, but at the moment the input part still requires tango InputStreams (output part already transitioned).

Fawzi

On Mon, 08 Mar 2010 17:52:25 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:


> Printing values with spaces between them is entirely fine for e.g. all numbers.
>

You know what, you are right.  Why should phobos cater to people wanting to print something as arcane as a string array, or a multi-dimensional array.  People have no business using such constructs, they should be punished by having to write their own routines.

It's all one-dimensional arrays of numbers for me from now on!

-Steve

On 09/03/10 09:12, Walter Bright wrote:
>
> obj2asm tells the tale. (obj2asm is an incredibly useful tool, I don't
> know why nobody uses it.)

Maybe a minor quibble, but obj2asm is really slow. If I'm going to disassemble something, I am never going to reach for obj2asm:

`ds` is a dmdscript testscript.d executable:

[~]$ time objdump -d ~/bin/ds >ds.s

real	0m1.139s
user	0m0.912s
sys	0m0.052s
[~]$ time obj2asm ./bin/ds >ds.s  # If you pass an absolute path (starts with '/'), obj2asm tries to interpret it as an argument. >_<

real	0m55.809s
user	0m11.009s
sys	0m31.094s


And out of curiosity, why do you charge for it on Windows, but provide it on Linux for free? Because the rest of the utilities are fairly windows-centric?

On Tue, 09 Mar 2010 03:09:51 -0500, Alexander Suhoverhov <alexander@suhoverhov.selfip.net> wrote:

>
>
> Steven Schveighoffer  at "Mon, 08 Mar 2010 15:23:51 -0500" wrote:
>  SS> On Mon, 08 Mar 2010 15:12:24 -0500, bearophile <bearophileHUGS@lycos.com> wrote:
>  >> Steven Schveighoffer:
>  >>> Tell me how you would parse the following text serialization string for a
>  >>> string[]:
>  >>>
>  >>> hello world how are you
>  >>>
>  >>> What if it was a string[][]?
>  >>>
>  >>> Compare that to:
>  >>>
>  >>> [hello world, [how are, you]]
>  >>
>  >> You are missing something:
>  >>
>  >> ["hello world", ["how are", "you"]]
>  SS> For completely unambiguous, yes.  But still, I find often that quotes are more noise than
>  SS> they are worth when just doing simple printouts.  What we  want is the most useful
>  SS> default.
>
> Commas are even more noise than than quotes. erlang:
>
> [{app, "app1"}, {user, "user1"}, {score, 123456}, {date, 5000000}, {misc, "foo"}]
>
> But if you just drop commas:
>
> [{app "app1"} {user "user1"} {score 123456} {date 5000000} {misc "foo"}]

If you are used to writing code, you should be used to having commas.  The two major use cases for 'to!string' are debugging and maybe serialization, both programmer tasks.  Plus, in your examples, you have quotes for strings.  That negates the need for commas, but I don't know if having 'to' convert strings to having quotes only for arrays makes sense.  Outputting an array should be a recursive thing.  At the very least, we need either a non-whitespace separator or quotes to delineate strings.  Brackets are a must to see the separation for multi-dimensional arrays.

-Steve

On 9-mar-10, at 13:00, Steven Schveighoffer wrote:

> On Tue, 09 Mar 2010 03:09:51 -0500, Alexander Suhoverhov <alexander@suhoverhov.selfip.net 
> > wrote:
>
>>
>>
>> Steven Schveighoffer  at "Mon, 08 Mar 2010 15:23:51 -0500" wrote:
>> SS> On Mon, 08 Mar 2010 15:12:24 -0500, bearophile <bearophileHUGS@lycos.com 
>> > wrote:
>> >> Steven Schveighoffer:
>> >>> Tell me how you would parse the following text serialization  
>> string for a
>> >>> string[]:
>> >>>
>> >>> hello world how are you
>> >>>
>> >>> What if it was a string[][]?
>> >>>
>> >>> Compare that to:
>> >>>
>> >>> [hello world, [how are, you]]
>> >>
>> >> You are missing something:
>> >>
>> >> ["hello world", ["how are", "you"]]
>> SS> For completely unambiguous, yes.  But still, I find often that quotes are more noise than
>> SS> they are worth when just doing simple printouts.  What we  want is the most useful
>> SS> default.
>>
>> Commas are even more noise than than quotes. erlang:
>>
>> [{app, "app1"}, {user, "user1"}, {score, 123456}, {date, 5000000}, {misc, "foo"}]
>>
>> But if you just drop commas:
>>
>> [{app "app1"} {user "user1"} {score 123456} {date 5000000} {misc "foo"}]
>
> If you are used to writing code, you should be used to having commas.  The two major use cases for 'to!string' are debugging and maybe serialization, both programmer tasks.  Plus, in your examples, you have quotes for strings.  That negates the need for commas, but I don't know if having 'to' convert strings to having quotes only for arrays makes sense.  Outputting an array should be a recursive thing.  At the very least, we need either a non-whitespace separator or quotes to delineate strings.  Brackets are a must to see the separation for multi-dimensional arrays.
>
> -Steve

I don't know, I have something similar writeOut(sink,type,formatting...), which is more flexible and efficient, not just to string.
That is supposed to write out something for the user (no serialization), and well it does not put "", but it does put "," in arrays, but I can understand other choices (matlab for example has no commas).
For dictionaries ":" and "," is nice I think.
It really come down to the meaning of to!(x), if it should be without loss then one should have enough information to recover the original value.
That is possible also without commas, but C/D  programmers are used to them... lisp, or other functional languages programmers might feel more at home with spaces... both are possible.
I find it slightly funny that D would choose spaces, but in the end any convention works

Fawzi

On Sun, 07 Mar 2010 22:54:12 -0800, Walter Bright wrote:

> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.041.zip

Great, thanks :)

BTW on this page: http://www.digitalmars.com/d/2.0/operatoroverloading.html

The 'Index Operator Overloading' link text at the top is duplicated for the link to the 'Slice Operator Overloading' section ;-)

On 03/09/2010 05:53 AM, Steven Schveighoffer wrote:
> On Mon, 08 Mar 2010 17:52:25 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>
>> Printing values with spaces between them is entirely fine for e.g. all
>> numbers.
>>
>
> You know what, you are right. Why should phobos cater to people wanting
> to print something as arcane as a string array, or a multi-dimensional
> array. People have no business using such constructs, they should be
> punished by having to write their own routines.
>
> It's all one-dimensional arrays of numbers for me from now on!
>
> -Steve

and formatted in hex

Ellery Newcomer wrote:
> On 03/09/2010 05:53 AM, Steven Schveighoffer wrote:
>> On Mon, 08 Mar 2010 17:52:25 -0500, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>
>>> Printing values with spaces between them is entirely fine for e.g. all
>>> numbers.
>>>
>>
>> You know what, you are right. Why should phobos cater to people wanting
>> to print something as arcane as a string array, or a multi-dimensional
>> array. People have no business using such constructs, they should be
>> punished by having to write their own routines.
>>
>> It's all one-dimensional arrays of numbers for me from now on!
>>
>> -Steve
> 
> and formatted in hex

In wake of printing multi-dimensional arrays, I agree that start and end delimiters should be present by default. If delimiters are present, it only makes sense to make the array look like a D array, so the ", " becomes an acceptable proposition.

I'm unsure about strings - should "to" go all gung-ho on quoting and escaping quotes etc.? That's a bit odd. Consider:

auto str = to!string("hello world");

I'd expect the call to be an identity application that makes str equal to "hello world". So far so good. Then say I convert with "to" an array of strings to a string:

auto str2 = to!string(["hello world"]);

Now str2 is "\"hello world\"", i.e. has an extra pair of quotes. So "to" applied to an array does not always use "to" applied to each element of the array - it has a completely different behavior. I wonder whether that's a desirable behavior.

(For the record, I agree that there are ambiguities if the quotes are not added and escaped etc. I just wonder whether that should be part of "to"s charter.)

Another thing that's unclear to me is whether writeln and "to" should be defined such that

write(to!string(stuff))

and

writeln(stuff)

produce the same text. Currently that's the general plan, but I wonder whether we should change the approach.


Andrei

On Tue, 09 Mar 2010 12:33:01 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> In wake of printing multi-dimensional arrays, I agree that start and end delimiters should be present by default. If delimiters are present, it only makes sense to make the array look like a D array, so the ", " becomes an acceptable proposition.

That's great!

> I'm unsure about strings - should "to" go all gung-ho on quoting and escaping quotes etc.? That's a bit odd. Consider:
>
> auto str = to!string("hello world");
>
> I'd expect the call to be an identity application that makes str equal to "hello world". So far so good. Then say I convert with "to" an array of strings to a string:
>
> auto str2 = to!string(["hello world"]);
>
> Now str2 is "\"hello world\"", i.e. has an extra pair of quotes.

I think you mean "[\"hello world\"]"

> So "to" applied to an array does not always use "to" applied to each element of the array - it has a completely different behavior. I wonder whether that's a desirable behavior.

I would say no.  I guess you could make the argument that strings are already arrays treated specially, but I don't think it adds much to put the quotes there.  Plus, it allows simpler code and documentation, you can define the conversion of an array as a purely recursive function, even if it may not be implemented that way.

Note that ranges should convert identically to arrays, making arrays special would make things odd.

> Another thing that's unclear to me is whether writeln and "to" should be defined such that
>
> write(to!string(stuff))
>
> and
>
> writeln(stuff)
>
> produce the same text. Currently that's the general plan, but I wonder whether we should change the approach.

I like that, it shows consistency.  If you want to change the format, you can via to's parameters.  But the most useful defaults should be the same in writeln.

Even though to is a way to get a crude serialization function, I don't know if it will be sufficient or efficient for a serious serialization library (i.e. I don't think it's worth making 'to' that smart).  But it is sufficient as a debug tool, it just needs better defaults.

-Steve