On Mon, Mar 8, 2010 at 14:22, Steven Schveighoffer <schveiguy@yahoo.com>wrote:

> The shrinkToFit name is not my favorite, anyone care to submit a better name?  minimize is out because it has connotations of math already.
>

minCapacity
minimizeCapacity
shrinkCapacity
shrink (just shrink)
releaseCapacity
compacify
fitCapacity
minFit???
reduceToFit
contract
minify
adjust



Philippe

> The linux version comes in the zip right along side dmd.
> 

Indeed. Even the OSX folder contains obj2asm. The windows version is missing.

On Mon, 08 Mar 2010 15:56:14 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Steven Schveighoffer wrote:
>> On Mon, 08 Mar 2010 14:49:33 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> bearophile wrote:
>>>> Andrei Alexandrescu:
>>>>
>>>>> Sorry, this stays.
>>>>  Then I'm not going to use the Phobos printing in all my future D2
>>>> programs. As I was not using it in D1. I'm not going to change idea
>>>> on this.
>>>>
>>>>> (e.g. the comma may be a decimal point in some languages, so is
>>>>> [1,2] in a German locale an array of double with one value or two?<
>>>>>
>>>>  In German you need no space after the comma, and there's no [] after
>>>> and before it. So [1, 2] is not a floating point value in German.
>>>>
>>>>> Why one space?<
>>>>  Because that's they way people print things in natural languages.
>>>> It's a convention, you know. And it's a good one. It tells apart the
>>>> FP numbers and it's the minimal.
>>>>
>>>>> It's the most neutral thing I could think of. Why no brackets?
>>>>> Because of minimalism. You can very easy add them if you want
>>>>> them.<
>>>>  The purpose of things like the square brackets is to give a less
>>>> ambiguous textual representation of the most common data structures
>>>> (array and strings are the most common after numbers). So you put ""
>>>> or '' around strings and [] to know what you are printing.
>>>
>>> Your choice of leading/trailing symbols and of separators makes 'to' friendlier for printing e.g. debug strings. My choice makes it a primitive for text serialization. I'm not 100% sure which is the more frequent use and therefore which is the most appropriate as a default, but I'm leaning towards the latter.
>>  No it doesn't.
>>  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]]
>>  That is almost completely unambiguous (you still have to account for literal commas or brackets), whereas you have a multitude of choices with the first version.
>
> I said a primitive for serialization, not a serialization infrastructure. So the basic idea is that you use "to" in conjunctions with your own routines to serialize things. "to" imposes no policy. Using "[", ", ", and "]" is policy.

Reading the documentation, it appears that setting the policy means simply passing delimiters to the "to" function.  That means that for every call to "to", you specify the policy if it differs from the default.  Since the default is not useful for serialization and confusing for printing, why would anyone use the default policy (aside from the obvious "because it's annoying")?  If you don't use the default policy, why have a default, why not require the policy for each call?

>> The thing is, friendlier for text-based serialization is almost identical to friendlier for printing.  In fact, friendlier for text-based serialization should have even more annotations to escape delimiters.
>>  In fact, I find the defaults you defined not useful in most cases.  Printing or serializing, I want to see the delimiters for the arrays, elements, and subarrays.
>
> You can choose them no problem. std.conv gives you mechanism, you choose the policy.

I can choose the policy for each call, that is not going to look very good, and be very tedious to write.  Plus it's not recursive (this would actually be a huge problem if using to for serialization):


import std.stdio;
import std.conv;
void main()
{
    int[][] x = new int[][](2, 2);
    writeln(to!string(x, "[", ",", "]"));
}

outputs [0 0,0 0]

I would expect [[0,0],[0,0]]

I'll also point out that AAs have a default policy that is much more reasonable.

-Steve

Trass3r wrote:
>> The linux version comes in the zip right along side dmd.
>>
> 
> Indeed. Even the OSX folder contains obj2asm. The windows version is missing.

The best thing is, on Linux you can use binutils objdump just fine. I'm sure OSX has tools to inspect object files as well. Only on Windows, you're having a bad time: almost nothing can understand digitalmars-omf.

Steven Schveighoffer wrote:
> On Mon, 08 Mar 2010 15:56:14 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Steven Schveighoffer wrote:
>>> On Mon, 08 Mar 2010 14:49:33 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>>
>>>> bearophile wrote:
>>>>> Andrei Alexandrescu:
>>>>>
>>>>>> Sorry, this stays.
>>>>>  Then I'm not going to use the Phobos printing in all my future D2
>>>>> programs. As I was not using it in D1. I'm not going to change idea
>>>>> on this.
>>>>>
>>>>>> (e.g. the comma may be a decimal point in some languages, so is
>>>>>> [1,2] in a German locale an array of double with one value or two?<
>>>>>>
>>>>>  In German you need no space after the comma, and there's no [] after
>>>>> and before it. So [1, 2] is not a floating point value in German.
>>>>>
>>>>>> Why one space?<
>>>>>  Because that's they way people print things in natural languages.
>>>>> It's a convention, you know. And it's a good one. It tells apart the
>>>>> FP numbers and it's the minimal.
>>>>>
>>>>>> It's the most neutral thing I could think of. Why no brackets?
>>>>>> Because of minimalism. You can very easy add them if you want
>>>>>> them.<
>>>>>  The purpose of things like the square brackets is to give a less
>>>>> ambiguous textual representation of the most common data structures
>>>>> (array and strings are the most common after numbers). So you put ""
>>>>> or '' around strings and [] to know what you are printing.
>>>>
>>>> Your choice of leading/trailing symbols and of separators makes 'to' friendlier for printing e.g. debug strings. My choice makes it a primitive for text serialization. I'm not 100% sure which is the more frequent use and therefore which is the most appropriate as a default, but I'm leaning towards the latter.
>>>  No it doesn't.
>>>  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]]
>>>  That is almost completely unambiguous (you still have to account for literal commas or brackets), whereas you have a multitude of choices with the first version.
>>
>> I said a primitive for serialization, not a serialization infrastructure. So the basic idea is that you use "to" in conjunctions with your own routines to serialize things. "to" imposes no policy. Using "[", ", ", and "]" is policy.
> 
> Reading the documentation, it appears that setting the policy means simply passing delimiters to the "to" function.  That means that for every call to "to", you specify the policy if it differs from the default.

I think it also means that you write your function that calls "to" inside, and use your function throughout.

> Since the default is not useful for serialization and confusing for printing, why would anyone use the default policy (aside from the obvious "because it's annoying")?  If you don't use the default policy, why have a default, why not require the policy for each call?

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

>>> The thing is, friendlier for text-based serialization is almost identical to friendlier for printing.  In fact, friendlier for text-based serialization should have even more annotations to escape delimiters.
>>>  In fact, I find the defaults you defined not useful in most cases.  Printing or serializing, I want to see the delimiters for the arrays, elements, and subarrays.
>>
>> You can choose them no problem. std.conv gives you mechanism, you choose the policy.
> 
> I can choose the policy for each call, that is not going to look very good, and be very tedious to write.

Write your own function and call it.

> Plus it's not recursive (this would actually be a huge problem if using to for serialization):
> 
> 
> import std.stdio;
> import std.conv;
> void main()
> {
>     int[][] x = new int[][](2, 2);
>     writeln(to!string(x, "[", ",", "]"));
> }
> 
> outputs [0 0,0 0]
> 
> I would expect [[0,0],[0,0]]
> 
> I'll also point out that AAs have a default policy that is much more reasonable.

I guess that should be changed too :o).


Andrei

Andrei Alexandrescu:
> > I'll also point out that AAs have a default policy that is much more reasonable.
> 
> I guess that should be changed too :o).

-.-

Bye,
bearophile

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

On Mon, 08 Mar 2010 16:42:54 -0500, Philippe Sigaud <philippe.sigaud@gmail.com> wrote:

> On Mon, Mar 8, 2010 at 14:22, Steven Schveighoffer <schveiguy@yahoo.com>wrote:
>
>> The shrinkToFit name is not my favorite, anyone care to submit a better
>> name?  minimize is out because it has connotations of math already.
>>
>
> minCapacity
> minimizeCapacity
> shrinkCapacity
> shrink (just shrink)
> releaseCapacity
> compacify
> fitCapacity
> minFit???
> reduceToFit
> contract
> minify
> adjust
>
>
>
> Philippe

compact

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


-- 
Best regards, Alexander Suhoverhov
	mailto: alexander@suhoverhov.selfip.net

Robert Jacques wrote:
> On Mon, 08 Mar 2010 16:42:54 -0500, Philippe Sigaud <philippe.sigaud@gmail.com> wrote:
> 
>> On Mon, Mar 8, 2010 at 14:22, Steven Schveighoffer <schveiguy@yahoo.com>wrote:
>>
>>> The shrinkToFit name is not my favorite, anyone care to submit a better
>>> name?  minimize is out because it has connotations of math already.
>>>
>>
>> minCapacity
>> minimizeCapacity
>> shrinkCapacity
>> shrink (just shrink)
>> releaseCapacity
>> compacify
>> fitCapacity
>> minFit???
>> reduceToFit
>> contract
>> minify
>> adjust
>>
>>
>>
>> Philippe
> 
> compact

Many of these names (including shrinkToFit) suggest that memory usage is reduced by freeing the left over memory after the array. This is not true: the function just enables stomping of the memory past the slice passed to the function.

It's a very specialized and dangerous function (but still may be critical for good performance), and maybe it should rather have a more convoluted/long name than a simple one.