Implementing std.log

[Jacob Carlborg]

On 2011-05-09 21:18, Andrei Alexandrescu wrote:
> On 5/9/11 1:48 PM, Jacob Carlborg wrote:
>> On 2011-05-09 19:58, Andrei Alexandrescu wrote:
>>> On 5/9/11 12:24 PM, Jacob Carlborg wrote:
>>>> I
>>>> have a function that gets the path of the current process:
>>>>
>>>> http://dsource.org/projects/tango/attachment/ticket/1536/process.d
>>>>
>>>> This links to a file attached to a Tango ticket but don't worry, I've
>>>> written the whole file myself and I intend to change the license to the
>>>> Boost License. It's written with D1 (obviously) but it's very easy to
>>>> port to D2, the only dependencies are C functions.
>>>>
>>>> Feel free to port it to D2 and use it in you're logging library if you
>>>> want to.
>>>
>>> I looked over the code, it's quite nice and clean. If you or anyone else
>>> would want to create a github pull request, the function would be a
>>> valuable addition to std.process. Thanks Jacob for offering the code to
>>> Phobos!
>>>
>>> What I think should change:
>>>
>>> * Provide two overloads, one that attempts to reuse a buffer and one
>>> that always returns a new string:
>>>
>>> char[] getProcessPath(char[] buf) { ... }
>>> static if (is(typeof(getProcessPath(null)) == char[]))
>>> {
>>> string getProcessPath() { return assumeUnique(getProcessPath(null)); }
>>> }
>>
>> Not sure I understand this.
>
> The static if actually refers to the next point, which implies that
> getProcessPath(char[]) may not exist on some systems.
>
> The idea behind having two functions is to give a string to people who
> just want a string without messing with buffers and all. The string has
> the nice property that nobody can trample on it later.
>
>> Ok, I'll see if I can find the time to create a pull request out of
>> this. In what module should I put the function?
>
> It looks like core.runtime already allows fetching the process path
> name, so you need to figure out what the added value of your function is.
>
>
> Andrei

Are you referring to core.runtime.Runtime.args? That is not completely 
reliable because:

* You can start a new process, with exec, and then pass in whatever you 
want as the first argument to the process.

* If you start an application via a symlink wouldn't that refer to the 
symlink instead of the actual executable?

* Also if you're running an application in a bundle on Mac OS X it would 
refer to the bundle and not the actual executable, if I recall correctly.

-- 
/Jacob Carlborg