Implementing std.log

[Andrei Alexandrescu]

On 5/10/11 3:22 AM, Jacob Carlborg wrote:
> 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.

I see. I'll defer ultimate decision on adding getProcessPath to Sean and 
Walter. Probably with a little experimentation to clarify motivation, 
getProcessPath is a worthy addition.


Thanks,

Andrei