www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Adding expandTilde to phobos' std.path

reply Grzegorz Adam Hankiewicz <gradhanews ya.com> writes:
I didn't know exactly how unit tests are performed for private
functions, so in the end I decided to not make any for them (though
I would). Contribution is public domain to be included in the
lib. Tell me if it will go in or no, or you want to make changes.

I couldn't persuade ddoc to generate two examples. Putting the
dashed line between the two seems to be understood as "end of
examples", which discards the second example as preformatted and
highlighted text.  It would be better for html formatting with
CSS if the separator could be specified between both, since each
example could be boxed individually.

With this function now it would be possible to use -Dd~/something
and have it work as expected.
Jan 08 2006
next sibling parent reply Chris Lajoie <ctlajoie___remove___this___ ___gmail.com> writes:
Grzegorz Adam Hankiewicz wrote:
 I didn't know exactly how unit tests are performed for private
 functions, so in the end I decided to not make any for them (though
 I would). Contribution is public domain to be included in the
 lib. Tell me if it will go in or no, or you want to make changes.
 
 I couldn't persuade ddoc to generate two examples. Putting the
 dashed line between the two seems to be understood as "end of
 examples", which discards the second example as preformatted and
 highlighted text.  It would be better for html formatting with
 CSS if the separator could be specified between both, since each
 example could be boxed individually.
 
 With this function now it would be possible to use -Dd~/something
 and have it work as expected.

certainly no offense intended, but wouldn't it be easier to eliminate the extra step and just attach the revised file? instead of posting diffs (and whatever the other one is.. CVS diff I think). as a user I'd just like to see the code you wrote. Chris
Jan 09 2006
parent Grzegorz Adam Hankiewicz <gradhafakedontuse ya.com> writes:
The Mon, 09 Jan 2006 12:21:01 -0700, Chris Lajoie wrote:
 certainly no offense intended, but wouldn't it be easier to eliminate 
 the extra step and just attach the revised file?

Diffs are to make Walter's job easier. Besides, I've just seen the new .143 release, and it's there so you can try now yourself.
Jan 14 2006
prev sibling parent reply Grzegorz Adam Hankiewicz <gradhafakedontuse ya.com> writes:
Walter, I would like you to explain the change you did to
combineCPathWithDPath. There you have:

    // Create our own copy, as lifetime of c_path is undocumented
    char[] cp = c_path[0 .. end].dup;

    // Do we append something from path?
    if (char_pos < path.length)
        cp ~= path[char_pos .. length];

    return cp;

I don't understand your comment about the lifetime of c_path. Is it
because it's a char instead of const char?  AFAICS, in both cases
the char comes from memory which won't go away, or will it?

And then, there's not much lifetime either for
combineCPathWithDPath. Wouldn't it be the same to rewrite that
block as:

    // Do we append something from path?
    if (char_pos < path.length)
        return c_path[0 .. end] ~ path[char_pos .. length];
    else
        return c_path[0 .. end].dup;

Is (should be?) any of the blocks more optimal in terms of internal
memory copies? Will the compiler optimise the second block better
because the duplication of c_path happens in the same statement
where the appending of path?

What would be the best way to find out with the compiler? How would
I find out what asm is being produced? Even if I don't know asm,
I would expect the optimal block to be shorter, right?
Jan 15 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Grzegorz Adam Hankiewicz" <gradhafakedontuse ya.com> wrote in message 
news:pan.2006.01.15.13.26.57.290795 ya.com...
 Walter, I would like you to explain the change you did to
 combineCPathWithDPath. There you have:

    // Create our own copy, as lifetime of c_path is undocumented
    char[] cp = c_path[0 .. end].dup;

    // Do we append something from path?
    if (char_pos < path.length)
        cp ~= path[char_pos .. length];

    return cp;

 I don't understand your comment about the lifetime of c_path. Is it
 because it's a char instead of const char?  AFAICS, in both cases
 the char comes from memory which won't go away, or will it?

As I recall, in one case it was a pointer to memory returned from getenv(), which doesn't document the lifetime of it. For the other case c_path was potentially a pointer to memory that was later explicitly free'd by the function.
 And then, there's not much lifetime either for
 combineCPathWithDPath. Wouldn't it be the same to rewrite that
 block as:

    // Do we append something from path?
    if (char_pos < path.length)
        return c_path[0 .. end] ~ path[char_pos .. length];
    else
        return c_path[0 .. end].dup;

No, because if char_pos==length, then c_path[0..end] is possibly returned, and no copy is made, although the current implementation of internal/gc/gc._d_arraycat() will always dup it. To future proof the code, it shouldn'd assume that ~ will always make a copy.
 Is (should be?) any of the blocks more optimal in terms of internal
 memory copies? Will the compiler optimise the second block better
 because the duplication of c_path happens in the same statement
 where the appending of path?

 What would be the best way to find out with the compiler? How would
 I find out what asm is being produced? Even if I don't know asm,
 I would expect the optimal block to be shorter, right?

The compiler doesn't control allocations, the runtime library does. Check out the routines in internal/gc/gc.d
Jan 15 2006