Bernard Helyer wrote:
> 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:

Hmm, I never noticed it being slow at all. I wonder what's going on.

> 
> `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?

Yes, it's because I don't have a similar group of stuff I can bundle for Linux.

On 9-mar-10, at 18:56, Steven Schveighoffer wrote:

> 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\"]"

well the thing is again str vs repr (string, or representation), repr should output something that is basically valid D code that reproduces the same value, whereas str not, what should to! do?

>> 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.

then I find it much better to base everything on something like my
	void writeOut(T,S...)(void delegate char[]sink, T object,S formatting)
that outputs to a sink, so that you can have output without memory
allocation.
(well my version is little more complex because I want to accept also
other stuff not just a sink http://github.com/fawzi/blip/blob/master/blip/io/BasicIO.d
  )

If you want a single string you can easily write helpers like
	T[] collectAppender(T)(void delegate(void delegate(T[]))
appender,char[] buf=null)
or similar ( http://github.com/fawzi/blip/blob/master/blip/container/GrowableArray.d
  ) that convert sink based stuff to a single string.

I think that that design is very efficient and clean, well I have to admit that I *hate* toString and methods that convert stuff to string, because they are unnecessarily inefficent.

> 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.

as I said serialization is a different beast (at least what I want from serialization), and the "how" should be in the target serializer, the serialization function should given enough information to the serializer, so that it might serialize how it pleases to him (in particular meaningful labels should be given for serialization to json,xml,...).

Fawzi

On 2010-03-09 20:15:44 +0100, Fawzi Mohamed <fawzi@gmx.ch> said:

[...]

> some html spam

sorry about that...

On 10/03/10 07:54, Walter Bright wrote:
>>
>
> Hmm, I never noticed it being slow at all. I wonder what's going on.

Obviously, I can't tell from here, but I can tell you what my system says obliquely.

It spends that minute at 100% CPU, and about 100 megs resident (which it allocates quickly, and then hovers about at). It isn't spending a lot (almost none,
AFAICT via iotop, it just does its reading and writing in a couple of big chunks) doing IO.

On 10/03/10 08:57, Bernard Helyer wrote:
> On 10/03/10 07:54, Walter Bright wrote:
>>>
>>
>> Hmm, I never noticed it being slow at all. I wonder what's going on.
>
> Obviously, I can't tell from here, but I can tell you what my system
> says obliquely.
>
> It spends that minute at 100% CPU, and about 100 megs resident (which it
> allocates quickly, and then hovers about at). It isn't spending a lot
> (almost none,
> AFAICT via iotop, it just does its reading and writing in a couple of
> big chunks) doing IO.

And of course, as you can see, it spends an atypical amount of time in kernel space. Large blocking syscall?

Bernard Helyer wrote:
> On 10/03/10 08:57, Bernard Helyer wrote:
>> On 10/03/10 07:54, Walter Bright wrote:
>>>>
>>>
>>> Hmm, I never noticed it being slow at all. I wonder what's going on.
>>
>> Obviously, I can't tell from here, but I can tell you what my system
>> says obliquely.
>>
>> It spends that minute at 100% CPU, and about 100 megs resident (which it
>> allocates quickly, and then hovers about at). It isn't spending a lot
>> (almost none,
>> AFAICT via iotop, it just does its reading and writing in a couple of
>> big chunks) doing IO.
> 
> And of course, as you can see, it spends an atypical amount of time in kernel space. Large blocking syscall?

It's a mystery. The only I/O it does is merely read the file.

On Tue, Mar 9, 2010 at 11:29, grauzone <none@example.net> wrote:

> 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.
>

enableStomping?
recycle?

Anyway IANANES (I'm not a native English speaker), so I'll let Steven
decide.


   Philippe

Nick Treleaven wrote:
> 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 ;-)

Not any more!

"Philippe Sigaud" <philippe.sigaud@gmail.com> wrote in message news:mailman.119.1268166534.4461.digitalmars-d-announce@puremagic.com...
> On Tue, Mar 9, 2010 at 11:29, grauzone <none@example.net> wrote:
>
>> 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.
>>
>
> enableStomping?
>

placeUnderFoot?

Steven Schveighoffer, el  8 de marzo a las 14:57 me escribiste:
> 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]]

What about [1, 2]?

> 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.

It's not too hard to be completely unambiguous. Just print the stuff in a way that is parseable for D:

["hello \"world\"", "nice \\"]
[1, 2, 3]
[1.0, 2.0, 3.0]

Thiis is good for both serialization and debugging (it' unambiguous, mandatory for serialization, and a littl verbose but clear for debugging). And if sometime in the future we get a D parser in the stdlib, deserialization is trivial =).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------